Business model prototyping for intelligent transport systems: a service-dominant approach

Full text

Business Model Prototyping for
Intelligent Transport Systems
A Service-Dominant Approach
Case Study for
Praktijkproef Amsterdam Fase 2
deelproject Zuidoost
Konstantinos Traganos, MSc
Eindhoven University of Technology (TU/e)
Prof.dr.ir. Paul Grefen
Eindhoven University of Technology (TU/e)
Aafke den Hollander, MSc
Municipality of Amsterdam, Praktijkproef Amsterdam
Dr. Oktay Türetken
Eindhoven University of Technology (TU/e)
Dr.ir. Rik Eshuis
Eindhoven University of Technology (TU/e)
Date: February 3rd, 2015

2
Contents
1 Introduction .................................................................................................................................... 4
1.1 Purpose ................................................................................................................................... 4
1.2 Context .................................................................................................................................... 4
1.3 Objectives ................................................................................................................................ 5
1.4 Structure ................................................................................................................................. 5
2 Business Model Design ................................................................................................................... 6
2.1 Introduction ............................................................................................................................ 6
2.2 Service-Dominant Business Model Radar ............................................................................... 7
2.3 Stakeholder Analysis ............................................................................................................... 8
3 Business Model Blueprints ............................................................................................................ 12
3.1 Approach ............................................................................................................................... 12
3.2 Business Model Radars ......................................................................................................... 12
3.2.1 Business Model 1 – Ultimate Event Experience ............................................................ 12
3.2.2 Business Model 2 – Stress-free Event Journey ............................................................. 14
3.2.3 Business Model 3 – Free Ride Amsterdam Event ......................................................... 16
4 Business – System Architecture mapping ..................................................................................... 19
4.1 ITS NL - System Architecture ................................................................................................. 19
4.1.1 Physical View – High Level with building blocks ........................................................... 20
4.2 Mapping for Business Model 2 ............................................................................................. 24
References ............................................................................................................................................ 29
Appendix A: BASE/X Framework ........................................................................................................... 30
A.1 Introduction .......................................................................................................................... 30
A.2 Business Design in BASE/X .................................................................................................... 30
A.3 Tooling in BASE/X business design ........................................................................................ 31
A.3.1 Graphical Annotation of Business Model Radar ........................................................... 33
Appendix B: Participants per workshop ................................................................................................ 35
Appendix C: Business Models – Results of Workshops ........................................................................ 36
C.1 Workshop 1 – Ultimate Event Experience ............................................................................ 36
C.2 Workshop 2 – Stress-free Event Journey .............................................................................. 37
C.3 Workshop 3 – Free Ride Amsterdam Event .......................................................................... 39
Appendix D: Original Sketches of Business Model Radars .................................................................... 41
Appendix E: Description of elements of Physical view ......................................................................... 44

3
Appendix F: Business – System Architecture mapping for BM 1 and BM 3 ......................................... 48
F.1 Mapping for Business Model 1 ............................................................................................. 48
F.2 Mapping for Business Model 3 ............................................................................................. 50
Appendix G: Contributors ..................................................................................................................... 54

4
1 Introduction
In this introduction, we set the scene of this document. First, we state the purpose of it. Next, we
discuss the context of the project and its objectives. Finally, we end this introduction with an outline
of the structure of the rest of this document.
1.1 Purpose
The current document introduces the approach for designing multi-sided, service-dominant business
models for Intelligent Transport Systems (ITS). This approach has been applied in three workshops
for the Praktijkproef Amsterdam Zuidoost project
1
. The purpose of these workshops was to arrive at
prototype business models for traffic management around large events in the Amsterdam South-
East region. In the workshops, most of the relevant stakeholders have participated. This report
presents the followed approach and the designed business model blueprints, which are based on the
results of these workshops. Also, a mapping of a business model to a system architecture of an ITS is
described for further deployment of business solutions.
1.2 Context
The mobility of people and goods suffers from delays, unreliability, lack of safety and air pollution,
especially in metropolitan areas. On the other hand, the demand for mobility is growing faster than
the available infrastructure. The development and deployment of Intelligent Transport Systems (ITS)
reduces traffic and number of accidents, leads to lower vehicle emission levels and improves quality
of life. In addition, the benefits of ITS are motivating both developed and developing countries to
invest in these technologies instead of spending huge amounts on transportation network
expansion.
Various governmental, academic and industrial stakeholders are in the process of describing a
shared vision on this new approach and first practical steps toward this goal should be taken.
Concurrently with the technology investments, investigations are carried on how various business
models can be applied to enable financial feasible roll out of traffic management services.
In the Netherlands, many ITS projects are being developed. Praktijkproef Amsterdam (PPA) is one of
them. The Amsterdam Practical Trial (PPA) is a trial aimed at reducing traffic congestion in the
Amsterdam region. It is a unique, large-scale pilot involving the innovative use of both in-car and
roadside technologies. Road users receive personalized travel advice in the car, to enable them to
make the best choice for their journey. Traffic lights and electronic displays respond in a coordinated
manner to traffic jam predictions. This enables road users to reach their destination faster and
provides them reliable travel times.
The Netherlands is a global trailblazer in collaborating to deliver public services. In PPA, the public,
private, science and technology sectors work together in an innovative fashion to create solutions
for improved accessibility in regions with high traffic volumes. Demonstrable cost-effectiveness will
enable national and international applications, and open up opportunities for Dutch businesses.
PPA is split in two phases. Phase 1 consists of two parts:
1
www.praktijkproefamsterdam.nl

5
- Testing of the integration of the proactive, automated traffic management system. The trial
is taking place on the western side of the A10 ring road west, junctions S101 (Nieuwe
Hemweg) to S107 (Henk Sneevlietweg).
- In Car system offering personalized journey information: traffic lights and feeder lights on
entry slip roads and traffic lights are providing a coordinated response to traffic jam
predictions. Two consortia will start with In Car services testing: Arcadis/VID under the
name “Amsterdam Mobiel” and ARS/TNO under the name “Amsterdam Onderweg”. Road-
users, trial participants, will receive current traffic and parking information in their cars and
will use this information to choose their best route (In Car services testing).
In Phase 2 the project is split to three subprojects, PPA Noord, PPA West and PPA Zuidoost. They
contribute to the integration of the proactive, automated traffic management system and the In Car
system offering personalized journey information. PPA Zuidoost focuses on improving individual in-
car advises by utilizing data gathered by road-side systems in the south-east part of Amsterdam
during large scale events.
1.3 Objectives
Given the current situation of the PPA Zuidoost project, where a number of (prototype) technologies
is being tested, many parties with different roles and responsibilities are involved, and even the
(non-)functional requirements are not clear yet, the question is “how to achieve a clear overview of
all the stakeholders and their collaborations in an operational business model”. Therefore, one of
the objectives of the project is to design blueprints business models with the use of a structured
framework.
Eindhoven University of Technology (TU/e), with the help of industry, has developed such a
framework, called BASE/X
2
, which is partially used for the design of service-dominant business
models, as we explain in Business Model Design.
1.4 Structure
In Business Model Design we discuss how business can be designed in a service-dominant world by
introducing the BASE/X framework. We focus on a specific component of the framework that
provides a conceptual tool for designing business models. In this chapter, we also present a
stakeholder analysis in order to provide a structure for the long list of parties taking part in the
transport and mobility domain. In Business Model Blueprints, we present a number of business
model blueprints as examples of the deployment of ITS applications, based on the results of the
three workshops in which first attempts of designing business model prototypes were made. Finally,
in we describe how a business model can be mapped to a system architecture of an ITS.
2
BASE/X is the acronym for Business Agility through Service Engineering in a Cross-Organizational Setting.

6
2 Business Model Design
This chapter introduces the service-dominant logic in the transportation domain and presents, in
Service-Dominant Business Model Radar, a structured method to design high-level business models.
In Stakeholder Analysis, a stakeholder taxonomy of the ITS domain is presented.
2.1 Introduction
The transport and mobility business domain is currently transitioning towards a service-dominant
business setting. Before the transition, business settings used to be centered on the delivery of
products or stand-alone services. After the transition, they will be centered on the provisioning of
solution-oriented, integrated services to customers (either business organizations or individual
consumers). Services may require the deployment of products, but these products become part of
the delivery channel of services, not the focal point themselves. Ownership of products becomes a
less relevant issue. The emphasis shifts from the value of the individual product or service to the
value of the use of the product or service in an integrated context – the so-called value-in-use. A
representative example of such a value-in-use is the transition from leasing a car (asset) to the
provisioning of integrated mobility solutions, including public transportation, flexible work offices,
etc. for a hassle-free relocation.
This transition though has consequences for the very basic characteristics of doing business. First,
customers expect coherent solutions, not stand-alone solution fragments. Thus, solution-oriented
services are of a complex nature that requires the integration of the capabilities of multiple service
providers. This introduces the necessity of explicitly managed business networks, in which traditional
mobility and transport service providers, equipment providers, authorities, and user organizations
collaborate to co-create the value-in-use. Second, customer-driven requirements to solution-
oriented services will evolve much faster than requirements to the underlying products. Rapid
developments in information and transport technology will further reinforce this process. Thus,
managing agility in service delivery will be a key factor in the market position of a service provider.
Third, managing service complexity and business agility requires a tight integration between the
structure of business strategy and models on the one hand and the structure of business operation
and information management on the other hand. It is not only about what transport or mobility
service to sell, but also about how to get it delivered.
Performing the transition to service-dominant business and managing its consequences is a
formidable task for any non-trivial business organization. Taking a traditional top-down, business-
strategy-to-operations approach will be too slow in the current fast pace of market developments.
Taking a quick-win, opportunity-driven, bottom-up approach will result in isolated implementations
and chaos in integration efforts. A visionary, industry-strength approach is required that is
completely tuned to the service-dominant transition and that has the very basics of service business
at its core. BASE/X is such an approach.
BASE/X is a business engineering framework for service-dominant business, i.e., business that puts
service management at the forefront of its design and operation. It covers the entire spectrum from
high-level business strategy definition to business information system architecture design. For the
purposes of the current document, we focus only on the business design aspect of the framework
and more specific on the design of business models. A small introduction of BASE/X is presented in
Appendix A: BASE/X Framework, while more information can be found in the full documentation of
the framework in [1].

7
2.2 Service-Dominant Business Model Radar
A business model is a set of assumptions about how an organization will create value for all its
stakeholders. The design of a business model is done by using tools like the Business Model Canvas
(BMC) [2]. However, approaches like this are typically not focusing on service-dominant business and
are organization-centric, not network-centric. Therefore, we use here a tool that has a service-
dominant starting point, called Service Dominant Business Model Radar (SDBM/R) (We use in this
document an adapted version of the conceptual tool that was initially proposed in [3]).
The Service-Dominant Business Model Radar (SDBMR) uses as a central aspect the notion of Co-
created Value-in-Use which defines what is the proposed co-creation proposition in terms of the
solution to the customer’s problem or customer’s experience. Three concentric circles are framing
this value-in-use. The first one is the Actor Value Proposition, which defines a value proposition to
co-create value by a co-creation actor to the solution for the benefit of the same or other actor
within the ecosystem. Co-Production Activity is the next element defining any activities that each
actor performs in the business for achieving the co-creation of value. In the business model, we have
also to define the Benefits/Costs as the financial and non-financial gains/expenses of the co-creation
actor participating in the value co-creation. Finally, we have the co-creation actors represented as
radial regions covering all con-centric circles. These actors are the Focal Organization, Core and
Enriching Partners and of course the Customer. The Focal Organization defines the role of co-
creation actor that proposes the business model and participates actively in the solution or
experience. A Core Partner defines the role of co-creation actor as a partner that participates
actively in core of the solution or experience while an Enriching Partner element defines the role of
co-creation actor as a partner that participates actively in enriching the solution or experience.
The elements that are discussed above are shown in the radar of Figure 1.

8
Figure 1 Service Dominant Business Model Radar
2.3 Stakeholder Analysis
The provisioning of mobility solutions involves many role categories with actors who play a direct or
indirect role in multi-sided business models. In this section we present the main stakeholders of
traffic-related applications in the frames of PPA Zuidoost project, starting from high-level general
categories and specifying underneath more specific actors. Examples of actors are given only for
illustrative purposes and these actors are of course not the only ones that can play a specific role in a
business model.
In a large-scale project like PPA-Zuidoost, the list of stakeholders is rather exhaustive and the first
step is to put some structure in that list. Two main dimensions are used to classify stakeholders:
Public – Private stakeholders and Service Providers – Service Consumers. However, while the first
dimension is rather mutually excluding, the second dimension can contain overlappings, i.e. an actor
can play a dual role, either a service provider or a service consumer, depending on a specific
business model.
The classification list is as follows:
GOVERNMENT BODY/POLICY MAKER & REGULATION: Represents the stakeholders that are
defining the policies and are monitoring the compliance with the regulation and legislation related
to the services. These parties are mainly service providers but in some cases can be considered as
service consumers.
- Country/Ministry (RWS)/Province/Municipality/Sub-city: the hierarchy of public administration for
defining policies, providing grants and funding ITS services.
- Traffic Manager/Road Operator: supervises the traffic management of an area (i.e. a city or a
highway) and is responsible for its optimization.

9
- Police/Enforcement: monitoring authority and certification of violations of the “Code of the Road”
and related law collections. It includes P.S.A.P. (Public Safety Answering Point), that is the collection
center for emergency calls and rescue.
- Certification body: entity that certificates the adherence and compliance of products and services
with standards and technical guidelines.
- Public Transport: Train/Metro/Bus/Tram Operators like NS/GVB/Connexxion/EBS.
- Auxiliary body: For instance Ambulances or Fire brands that in some cases require priority on a
road.
TRAFFIC SERVICE PROVIDER: Represents the stakeholders that are contractually providing the
service(s) directly or indirectly from the producers to the consumer(s). A Traffic Service Provider is
the main interlocutor with the users. Usually a software/technological company or a navigation
provider acts as a service provider. However, it could also be a different stakeholder, for example a
private company owned by a consortium of cities of a region.
USER/CONSUMER: Represents the stakeholders who are perceived as users of the service (public,
commercial or private) and who are willing to pay the service provider for the service(s).
- Individual road user: the real final individual user of the road network, either a driver or a
vulnerable road user like a pedestrian or a cyclist, or a service. A distinguish between event visitors
and non-event visitors to include users who may face traffic problems but are not travelling to an
event (An extra distinction can be made for ITS-road users and non-ITS road users in order to take
into account in some business scenarios any user who is not equipped with ITS-enabled devices).
- Transport Company: we distinguish between fleet managers, actors who manage a number of
vehicles, such as busses, emergency vehicles, trucks or taxi and truck drivers (including also bus
drivers, taxi drivers etc.).
TECHNOLOGY SUPPLIER: Represents the stakeholders that are supporting the producers of the
functionality of the service(s) or the service provider with the necessary technology and devices. It
can be any actor providing devices, hardware platforms, software applications, consulting services to
all the other actors involved in the services like:
- Road Side Unit (RSU) provider: provides complete RSUs and in some cases has the task to install
and maintain the RSUs in the road infrastructure.
- Road Sensor provider: provides any type of sensor (e.g. camera, speed sensor, location module,
actuators) to be connected or integrated in a RSU in order to capture real data and information.
- On-Board Unit (OBU) provider: provides the OBUs to the car/truck maker or to retrofit installer in
aftermarket scenarios.
- Vehicle maker: represents the role of a maker of every kind of vehicle (cars, trucks, buses,
ambulances, fire-fighters vehicles, etc.).
- IT provider: provides hardware (HW) and (SW) support for Back-Office operations.
SERVICE ENABLER: Represents the stakeholders that are supporting the service provider with
necessary services and contents.
- Content provider: finds and creates content (traffic data, information, basic services) to build useful
services to end users (e.g. POI on maps).
- Connectivity provider: provides the SIM card/module to be inserted into the OBU and RSU,
connectivity services to users and other actors, other value-added services like Location or identity
management.
- Broker: a facilitator between a seller of a service and a consumer by providing an integrated
platform for mobility services.
EVENT LOCATION PROVIDER: Represents the stakeholders who own or hire facilities for event
hosting.

10
- Stadium provider: responsible (either owner or lessee) of a stadium that can hold an event (such as
a concert, sport event, etc.).
- Hall provider: responsible (either owner or lessee) of a (music) hall which can hold a music concert
or an exhibition.
- Cinema/Theatre provider: responsible (either owner or lessee) of a cinema/theatre.
EVENT ORGANIZER: Represents those stakeholders who organize events and eventually gather
people in a specific area or location.
- Sports events organizer
- Music events organizer
- Exhibitions organizer
RETAILER: Represents the stakeholders who provide facilities for accommodation or any leisure
activities, attracting people in specific areas.
- Hotel
- Restaurant/Café
- Shopping Mall/Shop: any owner of a shop, either individual or part of a large shopping mall in an
area.
PARKING OPERATOR: Represents the stakeholders that own, manage and provide parking facilities
and services. It can be either public actors, private business actors or both.
ADVERTISER: Represents the stakeholder(s) that are advertising their services/products through the
provisioning of ITS applications and may finance any of these applications in specific business
models.
Note that a specific actor can play multiple roles in the same or different business models. For
example, a company as a specific actor can act as a navigation provider and the traffic content
provider in the same or in different business models.
Placing these roles and actors in a two-dimensions matrix, we have the following Figure 2. The
vertical layers distinguish stakeholders between Service Providers and Service Consumers, while the
horizontal layers separate them between Public and Private ones. The main categories are
represented as rounded rectangles, covering one or two layers (i.e. service provider-service
consumer or public-private). More specific actor types are included in each of these rectangles and
in turn a few examples of parties that can play these roles are shown for illustrative reasons.

11
Stakeholder
Private Public
Service Provider Service Consumer
Government body
Country
RWS
Province
Municipality
Subcity
Traffic Manager/Road Operator
Police
Netherlands
Noord-Holland
Amsterdam / Ouderamstel
Amsterdam South-East
Event Location Provider
Stadium Amsterdam Arena
Hall Heineken Music Hall / Ziggo Dome
Event Organizer
Concert Mojo / Rocket
Match KNVB
Retailer
Hotel
Restaurant/Cafe
Mall/Shop
Parking Operator
Individual Road User
Event Visitor
Non-event visitor
Transport Company
Fleet Manager
Truck Driver
Service Enabler
Content
Provider
Connectivity
Provider
Traffic Service Provider
Private Consortium
Navigation Provider
Technology Provider
Road Sensor Provider
OBU Provider
Vehicle Maker
HD Traffic / Flitsmeister /
Google /Social Media
GSM / SIM Card
RSU Provider Vialis / Siemens
TomTom
Traffic Info Provider
NDW
AWNB
Software Company
Auxiliary body Ambulance / Fire brand
Public Transport NS / GVB / Connexxion / EBS
Certification Body
Cinema/Theater
Public Area
Q-Park
Private garage
Advertiser
IT Provider
Exhibition
Broker
Figure 2 Stakeholders Taxonomy

12
3 Business Model Blueprints
With the aim to design a set of business model radars as perceived by the domain experts, three 2-
hours sessions were held at Municipality of Amsterdam, on 29th and 30th of October 2014. The lists
of participants per workshop are presented in Appendix B: Participants per workshop. In this
chapter, we discuss in Approach the approach followed during the workshops and present in
Business Model Radars the business model blueprints which are based on the results produced
during the workshops.
3.1 Approach
With the help of experts from TU/e, the mobility domain experts were guided in the design of
blueprint business models based on business scenarios related to PPA Zuidoost project.
- The first step was to define the co-created value-in-use of a customer’s problem/solution.
- Upon agreement, the identification of the two main actors was the next step, namely the
focal organization that orchestrates the activities and the customer who is the main
consumer of the service-solution.
- Next step in the process was to include all main partners, core and/or enriching, that
contribute to the proposed value-in-use. For each of these actors, the “actor value
proposition” ring of the radar had to be filled.
- The ring of “co-production activity” was skipped during the workshop mainly due to time
constraints.
- Final step was to identify the costs and benefits per actor (monetary on non-monetary). The
“+” symbol was used to indicate a benefit, while a “-” indicates a cost. How a benefit of an
actor incurs cost for another actor is represented by the use of the same color (more
explanations about the graphical annotation of the radar can be found in A.3.1 Graphical
Annotation of Business Model Radar).
3.2 Business Model Radars
Based on the results of the workshops (which can be seen in Appendix C: Business Models – Results
of Workshops), we processed the ideas of the participants in order to complete the business model
radars. The results are presented in this section.
3.2.1 Business Model 1 – Ultimate Event Experience
The identified value-in-use of this business model is the Ultimate Event Experience for visitors of an
event in the area of Amsterdam Zuidoost. An Event Organizer can play the role of a focal
organization with the experience they have in the event content. They undertake the role to
orchestrate all related activities among all actors of the business models and of course to arrange
any content contract. The customer is the Mass Event Visitor who is part of a crowd coming to the
area. An Event Location Provider is a core partner since most of the events are held in specific
premises/facilities. Their coproduction activities are both providing the location and sub-
orchestrating activities among actors, aiding in that way the Event Organizer. A Transport Facilities
Provider will enrich the value-in-use by providing easy access to the event. This role includes all
types of transportation, like train, bus, tram and even a parking operator. Note here that an event

13
visitor can choose one type of such a provider, i.e. either parking operator for those coming by car or
public/private transport for the rest. A Transport Info Provider will add access transparency by
providing real time transportation information. This information can be generated by reliable, real
time raw data that are gathered by a Transport Data Provider, e.g. a Road Operator.
The main benefit for the customer will be a concentrated joy and good memories from the
experience of visiting the event he/she desired to, while on the other hand he/she has to sacrifice
his/her time. In monetary terms, this will incur an integrated passport ticket, including both the
event ticket price and any transportation/parking tickets (we assume that the Event Organizer will
charge for any transportation/parking service so the event visitor does not have to care for any extra
tickets).
The integrated passport ticket is paid to the Event Organizer, while in turn they have to pay any
content fees (e.g. artists/music bands) and fees for renting the location of the event. We assume
also that the transportation/parking services are sub-orchestrated by the Event Location Provider, so
the Event Organizer has to pay access fees to them.
The Event Location Provider will receive the location renting and access fees, but they have to pay
the Transportation Facilities Provider for the access fees. These include any public/private transport
ticket or parking ticket for car visitors. Of course, the event will incur additional operational costs.
The Transport Facilities Provider (public/private transport company or parking operator) will receive
the access fees from the Event Location Provider. As another benefit from the upfront information
on how visitors will travel to the event, is the insight in traffic flow in a specific area, in a specific
time range. Their main costs, apart from the operational costs, are the fees they have to pay to the
Transport Data Provider for real time traffic data. We can also make the assumption that they pay a
fixed subsidy to the Transport Information Provider who for example provides a website/mobile
application for transport information without any advertisement support.
The Transport Information Provider will receive the fixed subsidy we mentioned above (presuming
that this is the main source they earn money from). To provide their services however, they have to
pay for real time traffic data from the Transport Data Provider and of course they incur any IT
infrastructure costs.
The Transport Data Provider will receive the fees for the real time traffic data they provide to other
stakeholders as mentioned above. Their main costs are infrastructure costs which will probably be
increased due to the happening of events.
The business model radar is presented in Figure 3.

14
Figure 3 Business Model 1 - Ultimate Event Experience
3.2.2 Business Model 2 – Stress-free Event Journey
Event visitors want to have a good time and positive experience without having to care much about
transportation and any event related issues. A business model with a Stress-free Event Journey
value-in-use will contribute to that direction. We focus, however, in this business model on visitors
by car, making an explicit separation from a business model for visitors by public transport means.
The Event Organizer undertakes the role to orchestrate the other parties like the Private Traffic
Manager who provides easy access to the event, the Event Location Provider, who provides comfort,
the Municipality, who contributes to a metropolitan atmosphere and provides accessibility, the
Parking Provider, who provides parking services so the visitor does not have to care about his car
while enjoying his favorite music band, the Road Authority who provides reliable and safe traveling
to the event. Retailers are also part of the business model since they contribute to customer’s
experience with pre- and post-event convenience (shopping, eating, etc.). Apart from people who
are visiting an event, we care also about those who are using the same road network and visit the
area around Amsterdam Zuidoost during the event, adding liveliness to the area, the Non-Event
Visitors.

15
The main coproduction activities of the Event Organizer, except the orchestration, are the
arrangements of any content contract and the provision of upfront information to other
stakeholders since they have the data for the exact number of visitors.
A Private Traffic Manager undertake the role to gather traffic data, both from Road Authorities and
floating car data, and provide an traffic management and enhanced traffic information to road users
on how to reach the event venue.
The Event Location Provider provides the venue facilities while the Municipality of Amsterdam has
to perform marketing activities to promote the area and provide traffic management during an
event. The Parking Provider has the task of providing parking services while the Road Authority
provides the road infrastructure, traffic data and manages the traffic with their expertise. The role of
the Retailer is rather obvious, to sell their products to people visiting their store.
The Event Visitor will take advantage of the provided solutions when visiting an event and
experience the metropolitan atmosphere. On the other hand, he will pay the ticket for the event, the
parking costs, service fees for the traffic information he gets and any other money in the shops/bars
he will visit.
The Event Organizer will receive the ticket fees and also will increase their reputation by providing a
stress-free experience. To do so, they have to pay rent to the Event Location Provider and of course
pay for the organization of the event (the artists, etc.).
The Private Traffic Manager has to pay Road Authorities in order to get traffic data. On the other
hand, they charge road users for the enhanced traffic information they provide (service can be
charged on a per-contract basis or on a fixed yearly fee). We make here the assumption that in-
vehicle traffic information is provided to the customers of Event Organizer who are the Event
Visitors. In this case, Non-Event visitors are being charged for any service.
To be part of this business model and reap the benefits, like increased reputation and venue fees,
the Event Location Provider has to increase its operational costs for providing more and of better
quality services.
The Municipality of Amsterdam will increase its reputation as being a city with high accessibility and
nice atmosphere in busy events areas. The reputation will consequently attract more visitors, help to
reduce any economic damage and the deployed intelligent transport systems will further decrease
operational costs. However, they traffic management they have to perform will incur some costs.
The benefits for the Parking Operator are the parking fees that they get from car visitors. Their
monetary costs are any extended operational costs.
The Road Authority will also benefit of that business model since such a solution will help them meet
their targets on traffic management. Moreover, they get fees from the traffic data they sell to the
Private Traffic Manager. Traffic management costs are still there but intelligent transport systems
will eventually lead to reduced operational costs.
Regarding the Retailers, the turnover is an issue that needs further financial analysis whether it will
be positive or negative. This is because the spending of the event visitors may be equilibrated by the
fact that less people who are not visiting the event will go for shopping, drink or dinner during the
event in order to avoid the crowd. The same goes for the reputation of these stores. On the other
hand, Retailers have to spend more on extended operational costs in case it requires to stay open
for extra hours due to an event.

16
Finally, for Non-Event Visitors, the advanced traffic solutions will help them in the accessibility to the
area and the experience of the metropolitan atmosphere. However they will have to endure the
nuisance that the event visitors cause. And of course, non-event spendings should be counted as
their main monetary costs.
One main remark we can make about this business model is that it is close to the current situation
with the respect to the roles that the identified stakeholders play. Moreover, we can say that actors
are loosely connected and are not tied so much to the focal organization, as was the case in the first
business model of the Ultimate Event Experience, in which the idea of an integrated passport ticket
required a more explicit and better orchestration of actors.
The business model radar is presented in Figure 4.
Figure 4 Business Model 2 – Stress-free event journey for Car visitors
3.2.3 Business Model 3 – Free Ride Amsterdam Event
The idea for this business model is rather extreme since it proposes a “free ride” to an event to
those who plan their arrival by car at a much earlier time than the beginning of the event. The term
free refers to free parking (or even fuel consumption coupons, however in that case we should
consider gas station owners as co-creation actors). With that scenario traffic jams will be reduced

17
and many stakeholders need to contribute. A Mobility Broker is the focal organization offering
integration and being the central point of contact. They are responsible to orchestrate not only
traffic-related actors, but also the visitors who wish to book a ticket for an event. A Parking Provider
will simply provide parking services for an easy car disposal while the Road Authority provides the
road infrastructure and traffic management before and after the event for a reliable trip. Retailers
are also involved in the business models, contributing to pre and post experience by selling products
to people coming to the area. The Event Organizer will provide the content while the Event Location
provide will contribute to a comfortable stay before, during and even after the event.
The main benefit for the visitor is of course the “free ride” (free parking) and the concert experience
as well. Their non-monetary costs are their flexibility and the sacrifices in their time schedule since
they need to be there at given times to exploit the “free ride”. The event incurs a ticket fee and any
non-event spendings that visitors make especially due to the fact that they arrive much earlier.
The Mobility Broker will get variable kickback fees from the Event Organizer, the Event Location
Provider and the Retailers since these stakeholders will advertise themselves in the broker. Another
monetary benefit is the ticket fees since we made the assumption that they orchestrate the booking
of the ticket for the visitors. On the other hand, the broker will pay the “free ride” as parking fees to
the Parking Operator for providing parking services to its customers. They will also have to expose
the data for number of visitors to Retailers to let them estimate any changes on their turnover.
Parking Providers are expecting an increase in the demand due to the fact that more people will
desire to exploit the “free ride”. However, this demand may lead to capacity constraints and to
extended operational costs.
For the Road Authority, the main benefit is that the expected reduced traffic congestions will help
them meet their traffic management targets (monetary and non-monetary). On the downside, they
have to get and manipulate the traffic data and still have to perform the necessary traffic
management.
Retailers will benefit from the “free-ride” business model in terms of increased popularity, higher
turnover since people will spend more hours before the event and have the advantage of estimating
people’s attendance from data got from the Mobility Broker. However, they need to pay kickback
fees to the broker and extend their operational costs.
The Event Organizer and the Event Location provider will also benefit from the proposed solution
and will expect an increase in popularity and subsequently in their turnover. They also have to pay
kickback fees to the Mobility Broker to advertise their services and facilities. Moreover, for the Event
Location Provider, extended operational costs should be taken into account.
The business model radar is presented in Figure 5.

18
Figure 5 Business Model 3 – Free ride Amsterdam event

19
4 Business – System Architecture mapping
In this chapter we discuss the mapping between a business model and the system architecture of an
ITS with the goal to show how a business solution can be deployed by the use of technology. The
system architecture we use for the mapping is the Reference Architecture for Cooperative-ITS
applications in the Netherlands as designed per December 2014 by the DITCM
3
and agreed by
various stakeholders [4]. For each of the three complete business models blueprints of Business
Model Radars, we link the involved actors to specific elements of the system architecture, showing
who is owner/responsible of/for which element of an ITS. Activities as identified in the business
model radars are also mapped to architecture elements to make a more explicit connection between
business and technology.
First, we briefly present in ITS NL - System Architecture the ITS System Architecture that is used for
the mapping. Then, in Mapping for Business Model 2, we present the models for the business –
system architecture mapping for one of the complete business models (the most representative),
leaving the mapping of the other two business models to be found in Appendix F: Business – System
Architecture mapping for BM 1 and BM 3.
4.1 ITS NL - System Architecture
The objective of “Reference Architecture for Cooperative-ITS applications in the Netherlands”
project is to develop an ITS reference architecture consisting of a system architecture and business
aspects of an eco-system with stakeholders from public and private parties - in a Dutch context, i.e.
with knowledge of the existing role of the Dutch road operators and the roadside and traffic
management systems with e.g. loop detection, variable message signs, traffic light controllers (both
urban and highway access) and Traffic Management System (TMS) with their interface specifications.
The reference architecture should give guidance to future ITS deployment projects in the
Netherlands. To define that first release of the reference architecture, a number of projects were
selected as source for the ITS reference architecture for the Netherlands.
Regarding the system architecture, different views have been used to describe the elements of the
reference architecture. These are:
- Physical view: describes the sub-systems and the communication interfaces between these
sub-systems
- Functional view: describes the application objects (or functional components) that are
attached to the physical objects as well as abstract functions (processes) within application
objects and their logical interactions (data flows) between functions
- Communications view: describes the interfaces between the physical and functional
building blocks via a layered set of communications protocols that are required to support
communications among the sub-systems.
In the current project, we are focusing on the Physical View and more specific in high level models of
it since our goal is to provide a first kind of business – system architecture mapping.
3
http://www.ditcm.eu/

20
4.1.1 Physical View – High Level with building blocks
In the physical view the system architecture is depicted as a set of sub-systems that interact and
exchange information to support the ITS applications. Sub-systems are defined to represent the
major (physical) components of the connected vehicle environment. (Human) actors are treated as
external entities that interact with the system. The main categories are:
- Vehicle Driver: An actor driving in a vehicle. The vehicle is a motorized vehicle (car, bus,
truck) and not a vehicle of a vulnerable road user (bike, moped, motor).
- Vulnerable Road User (VRU): A VRU is a human actor like a pedestrian, cyclist or powered-
two-wheel driver (PTW); A motorcyclist is also an example of a PTW and is treated as a
vulnerable road user in specific road hazard situations with other cars.
- End User: A human actor who uses a product or service as an individual, i.e. not on behalf of
an organization.
- Road Operator: An actor responsible for the traffic management of a road network.
- Service Provider: An actor (organization) supplying services to one or more customers.
Customers are either other organizations, including government (B2B / B2G / G2B / G2G) or
end users (B2C / G2C). Typical examples of service providers are a Navigation Provider or a
Traffic Information Provider.
- Other: Any other actor that has interaction with the ITS or is interested in the deployed
applications.
These actors can be represented by the list of stakeholders presented in Stakeholder Analysis, a
subset of which is used in the business models blueprints.
An ITS as a black box with interacting actors is presented in Figure 6.
ITS system
Vehicle
driver
Service
Provider
OtherRoad
Operator
VRUEnd User
Figure 6 System architecture – Higher level
The physical view of system architecture is based on best common practice of previous ITS projects,
i.e. there is a split in physical layers for vehicle, roadside and central; in addition a support and a
traveller/vulnerable road user layer are added. The five “layers” are shown in Figure 7.

21
Central
Traveller / VRU
Vehicle
Roadside
Support
Figure 7 ITS Reference Architecture Physical View: Layers
1. Support layer: Sub-systems to support the overall system e.g. governance, test and certification
management and security and credentials management.
2. Central (or back-office) layer: Sub-systems to support connected vehicles, field and mobile
devices and to perform management and administration functions. The sub-systems in this layer
are typically virtual systems that can be aggregated together or geographically/functionally
distributed.
3. Roadside layer: Covers the ITS infrastructure on or along the physical road infrastructure, e.g.
surveillance or control devices (signal/lane control, ramp meters, or systems to supply
information to connected vehicles.
4. Vehicle layer: Covers the intelligent/cooperative on-board systems (advanced driver assistance /
safety systems, navigation, remote data collection or information). Also specific sub-systems for
fleet–type vehicles are included e.g. for signal priority, monitoring activities, fleet management or
passenger services.
5. Traveller or vulnerable road user (VRU) layer: Covers both “personal” devices (e.g. mobile
devices, navigation devices) and specific systems connected to vehicles of VRU’s or VRU’s itself
(e.g. tags).
The identified “building blocks” (physical objects or sub-systems) in the five layers are shown in
Figure 8.

22
Central
Traveller /
VRU
Vehicle
Roadside
Support
Roadside System
(RS)
Vehicle Pl atfom
(VEE)
Personal Infor mation
Device
Vehicle On-Board
Unit (OBU )
Vehicle VRU
Localization Sy stem
(V-VLS)
Roadside Unit
(RSU or RIS)
Service P rovider
Back-Offic e
(SP BO)
Data Provide r B ack-
Office (DP BO )
Traffic Mana gement
System (TM S)
Traffic Information
System (TIS)
VRU-OBU
Service Provide r
Exchange Sys tem
(SPES)
Remote Vehicle OBU
(R-OBU)
Governance Test & certif ication
Management
Security & c re dentials
Management
VRU Transpon der
(VRU-T)
Roadside VRU
Localization Sy stem
(R-VLS)
Communi ca tion
Provider Ba ck -Office
(CP BO)
Operational
Management
Remote VRU -OBU
Figure 8 ITS Reference Architecture Physical View: With Sub-systems
More information about the description of each of the building blocks can be found in Appendix E:
Description of elements of Physical view.
Adding now the connections and among the sub-elements for the support of identified ITS
applications, we get Figure 9.

23
Vehicle
Central
Traveler
Roadside
Roadside System
(RS)
Vehicle Platfom
(VEE)
Personal
Information Device
OBU
Service / Data
Provider BO
(SP / DP BO)
Comm. Provider
Back-Office (CP BO
or CIS)
Traffic
Management
System (TMS)
VRU-OBU
Service Provider
Exchange System
(SPES)
Remote Vehicle
OBU (R-OBU)
RSU or RIS
Traffic
Information
System (TIS)
Remote VRU-OBU VRU-Transponder
(VRU-T)
Vehicle VRU
Localization System
(V-VLS)
Roadside VRU
Localization System
(R-VRS)
Service Provider
Back-Office
(SP BO)
Support Governanc e
Test &
certification
Management
Security &
credentials
Management
Operational
Managem ent
Figure 9 ITS Reference Architecture Physical View: With interfaces among Sub-systems
The architecture models of Figure 8 and Figure 9 are used to map the actors and their main
activities, as identified per business model. Actors are linked to the main elements which perform
their activities. Figure 10 below shows an overview of the mapping. Actors of the radar are mapped
to actors of the ITS. Co-production activities are also mapped to descriptions of activities performed
by actors of an ITS. The other elements that are not directly mapped to the identified actors are
greyed for presentational reasons (they are needed though in a fully functional ITS, but
owned/managed by actors that are not part of a specific business model). Note here that in each
mapping, other important actors may be missing, owning crucial parts of an ITS. However, the aim of
the mapping is to show how the parties that contribute to a specific value in use of a business model
interact from a technology point of view.

24
Figure 10 Overview of business - system architecture mapping
4.2 Mapping for Business Model 2
The Business Model of a Stress-free event journey for car visitors as presented in Business Model 2 –
Stress-free Event Journey, is a representative business model for Amsterdam Zuidoost area, since
the most relevant stakeholders are included, performing common activities. We make use of this
business model to show in Figure 11 below how elements of the business model radar of Figure 4
(actors and activities) map to the physical view of an ITS architecture.

25
Non-Event Visitor
Traveller /
VRU
Vehicle
Event Visitor by Car
Roadside
Road Authority
Municipality
Event
Location Provider
Event Organizer
Retailer
Parking Operator
Central
Support
Roadside Sy stem
(RS)
Vehicle Platfo m
(VEE)
Personal Infor mation
Device
Vehicle On-Bo ard Unit
(OBU)
Vehicle VRU
Localization Syst em
(V-VLS)
Roadside Unit
(RSU or RI S)
Service Pro vider Back-
Office
(SP BO)
Data Provide r Back-
Office (DP BO)
Traffic Man agement
System (TMS)
Traffic Inform ation
System (TIS)
VRU-OBU
Service Provider
Exchange Sy stem
(SPES)
Remote Vehic le OBU
(R-OBU)
Governance T est & certification
Manageme nt
Security & c redentials
Manageme nt
VRU Transpond er
(VRU-T)
Roadside VRU
Localization Syst em
(R-VLS)
Communica tion
Provider Back- Office
(CP BO)
Operational
Management
Remote VRU-O BU
Manages Tra ffic
Manages Tra ffic
Provides infra
Drives ther e
Drives ther e
Gets there
Gets there
Provides par king info
Private Traffic
Manager
Provides traffic data
Sends/Receive s info
Access tra ffic state info
Provides upfront info
Provides upfront info
Provides traffic info
Manages traffic
Gathers float ing data
Figure 11 Business - System Architecture Mapping - Business Model 2
In the figure above, we see how Private Traffic Manager, Road Authority and Municipality are linked
to Traffic Management System (TMS) to provide traffic management, each from their own
perspective.
Private Traffic Manager requires access to Service Provider Back-Office (SP-BO) and Service Provider
Exchange System (SPES) to provide traffic information to event visitors. They also require access to
Roadside System (RS) to get traffic data and to Vehicle On-Board Unit (OBU) to gather floating
vehicle data.
Parking Operator provides information on the availability of parking slots in his facilities to Traffic
Information System (TIS) which can be further used from the TMS for traffic management.
One point to mention is the approach we followed to distinguish the actor “Non-Event Visitor”. We
distinguished that from those who may travel around the event venue by a car (vehicle) (and thus
linked to the Vehicle layer) and from those that are in the area as pedestrians or by bike (thus linked
to the Traveller/VRU layer).
The Support layer contains sub-elements that are not directly connected to sub-elements of other
layers but cover a full spectrum of activities and processes in them. Therefore, actors that are
relevant to components of the Support layer are linked to the whole layer with a dashed line, to

26
indicate that they are not linked explicitly to specific components of it. Since our purpose in this
project is to show a blueprint mapping, we leave the explicit mapping of that layer for further
elaboration.
Finally, one notices how actors like Event Organizer, Event Location Provider and Retailers are not
directly linked to any of the components of the architecture. We assumed in the business model that
they are informed upfront for the expected number of visitors but this is done only through the
Event Organizer’s systems.
By mapping now actors and their activities to the physical view in which connections of sub-
elements are presented, we get Figure 12:
Vehicle
Central
Traveler
Roadside
Support
Non-Event Visitor
Event Visitor by Car
Road Authority
Municipality
Event Organizer
Parking Operator
Manages T raffic
Manages Traffic
Provides in fra
Drives ther e
Drives ther e
Gets there
Provides par king info
Gets there
Roadside System
(RS)
Vehicle Platfom
(VEE)
Personal
Information Device
OBU
Service / Data
Provider BO
(SP / DP BO)
Comm. Provider
Back-Office (CP BO
or CIS)
Traffic
Management
System (TMS)
VRU-OBU
Service Provider
Exchange System
(SPES)
Remote Vehicle
OBU (R-OBU)
RSU or RIS
Traffic
Information
System (TIS)
Remote VRU-OBU VRU-Transponder
(VRU-T)
Vehicle VRU
Localization System
(V-VLS)
Roadside VRU
Localization System
(R-VRS)
Service Provider
Back-Office
(SP BO)
Governance
Test &
certification
Management
Security &
credentials
Management
Operational
Management
Private Traffic
Manager
Provides traffic info
Provides traffic info
Sends/Rec eives
info
Access traffic s tate info
Event
Location Provider
Retailer
Provides u pfront info
Provides u pfront info
Provides tr affic data
Manages traffic
Gathers floatin g data
Figure 12 Business - System Architecture Mapping with connections - Business Model 2

27
Actors, architecture elements and activities performed by these actors on the linked components are
presented in a tabular form below.
Table 1 Actors - Elements mapping for Business Model 2
Actor/Stakeholder
Architecture element
Activities
Event Organizer
None
Non ITS-related activities.
Private Traffic Manager
Communication Provider Back-
Office (CP BO)
The Private Traffic Manager uses CP BO to
get access at several communication layers
from other BO systems (like SP BO, TMS, TIS
etc.) to send and receive ITS information
to/from vehicles or other road users.
Roadside System
(RS)
Traffic state information from roadside
substations and traffic light controllers needs
to be gathered by the Private Traffic Manager
meaning that a link to RS is necessary.
Vehicle On-Board Unit (OBU)
Floating vehicle data are gathered from OBUs
for improved traffic management and traffic
information.
Traffic Management System
(TMS)
Private Traffic Manager can provide
enhanced traffic management through TMS.
Service Provider Back-Office
(SP BO)
The Private Traffic Manager uses SP BO to
support personal information services for, e.g.
navigation or traffic information applications
on OBU/PID.
Service Provider Exchange
System (SPES)
SPES is also used for traffic information
provisioning and for service authentication
and authorization purposes as well.
Event Visitor by Car
Vehicle On-Board Unit (OBU)
The driver uses the OBU of his vehicle to get
traffic/navigation information on how to get to
the venue of the event.
Event Location Provider
None
Non ITS-related activities. Informed by the
Event Location Provider through own (non-
ITS) systems.
Municipality
Governance
Municipality uses the Governance sub-system
for policy maker and regulations.
Traffic Management System
(TMS)
Provides traffic management through the
TMS.
Parking Operator
Traffic Information System (TIS)
The Parking Operator provides information on
the availability of parking slots in his facilities
to TIS which can be further used from the
TMS for traffic management.
Road Authority
Traffic Management System
(TMS)
Provides traffic management through the
TMS.
Roadside Unit (RSU or RIS)
Responsible for the road side infrastructure.
Data Provider Back-Office (DP
BO)
Provides traffic data to the Private Traffic
Manager.
Retailer
None
Non ITS-related activities. Informed by the
Event Location Provider through own (non-
ITS) systems.
Non-Event Visitor
Vehicle On-Board Unit (OBU)
The non-event visitor who drives around the
venue of the event uses the OBU of his
vehicle to get traffic information on how to
avoid traffic jams.
Personal Information Device
A VRU non-event visitor can either use a PID

28
VRU On-Board Unit (VRU-OBU)
or a VRU-OBU to get traffic information on
how to avoid traffic jams.
One note we can make here about the above linking of actors to components of an ITS and their
corresponding activities is that it may depict the current situation in traffic management domain, but
it does need to be followed for future developments. The most representative example may be the
link of a Private Traffic Manager to the Roadside System to gather traffic state information. The
trend in mobility domain is that all traffic related information can be gathered with Floating Car Data
(or Probe Vehicle Data) through Navigation Providers and consequently replace most of the roadside
infrastructure (or limiting to the legal minimum) [5]. Also, traffic management can be provided
through in-car (personalized) services by private parties, in addition to roadside traffic management
as performed by road authorities. Thus, in all these scenarios, actors have to link to new components
to get the information they require for provisioning their services.

29
References
[1]
P. Grefen, E. Lüftenegger, E. van der Linden and C. Weisleder, BASE/X Business Agility through
Cross-Organizational Service Engineering, Eindhoven University of Technology, 2014.
[2]
A. Osterwalder and Y. Pigneur, Business Model Generation, Wiley, 2010.
[3]
E. Lüftenegger, Service-Dominant Business Design, Eindhoven University of Technology, 2014.
[4]
M. v. Sambeek, F. Ophelders, T. Bijlsma, O. Türetken, R. Eshuis, K. Traganos and P. Grefen,
“Reference Architecture for C-ITS applications,” 2014.
[5]
C. J. van de Weijer and B. C. Rutten, “The fast-growing role of in-car systems in Traffic
Management,” TomTom, 2013.

30
Appendix A: BASE/X Framework
In this Appendix we present briefly the BASE/X framework which is used in the current document for
business model design in a service-dominant context. We introduce the framework in A.1
Introduction and discuss business design as part of it in A.2 Business Design in BASE/X.
Finally, in A.3 Tooling in BASE/X business design we present the conceptual tools in BASE/X
business design.
A.1 Introduction
BASE/X framework is a well-structured way to address the analysis and design of service-dominant
business. It covers the entire spectrum from high-level business strategy definition to business
information system architecture design, including elements like business model conception, business
service specification and business process modelling. The very core of BASE/X is the understanding
that to achieve truly agile service provisioning business, these elements cannot be treated in
isolation.
To capture networked, service-oriented business, BASE/X has two core business principles:
1. Business services and the value-in-use they deliver to customers are the primary building
blocks for contemporary business design and execution.
2. To deliver integrated business services as a solution to a customer, networks of
providers of basic services are required. Given the volatility of many markets, these
networks must be dynamic and explicitly orchestrated. Orchestration of networks is of
paramount importance.
To structure business organizations, BASE/X uses two core business engineering principles:
3. An explicit distinction is required between the stable essence of a business organization
and the agile market offerings of that organization. These two elements must be
explicitly co-engineered in business design.
4. An explicit distinction is required between business structures, organization structures,
and information technology structures. These three elements must be explicitly co-
engineered in operations design.
Here we present a few core concepts about the business design aspect of BASE/X, while more
information on the organization and IT platform design aspects can be found in the full
documentation of the framework in [1].
A.2 Business Design in BASE/X
Business design in BASE/X is based on the observation that we need the distinction between
business goals (the ‘what’ of business) and business operations (the ‘how’ of business) on the one
hand and the distinction between the stable essence of an organization and its agile market
offerings on the other hand. This leads to a model with four layers, as shown in Figure 13 below.

31
Figure 13 BASE/X Business Pyramids
As shown in the left side of the figure, the top half of the pyramid covers business goal engineering.
As shown in the right of the figure, the top layer contains the service-dominant business strategy.
This strategy describes the identity of an organization in a service-dominant market. The identity is
relatively stable over time: the strategy evolves. The second layer contains service-dominant
business models. Each business model describes a market offering in the form of an integrated,
solution-oriented complex service: they describe a concrete value-in-use. Business models follow
fluid market dynamics and are agile: they revolve – they are conceived, modified, and discarded as
required.
The bottom half of the pyramid covers business operations engineering. The bottom layer contains
business services, each of which contains a core service capability of the organization. As these
capabilities are related to the resources of the organization (covering both personnel and large-scale
technical infrastructures), they are relatively stable over time: they evolve. The third layer of the
pyramid contains the service compositions. Each composition is a combination of business services
to realize the service functionality required by a business model: they implement a concrete value-
in-use. The combination includes business services from the organization’s own set, but also
business services of partner organizations in a business network. As service combinations follow
business models, they are agile: they revolve with their associated business models.
A.3 Tooling in BASE/X business design
BASE/X offers more than the conceptual approach outlines above. It also offers a set of business
design tools for each of the four layers of the business pyramid:
 For strategy design, a service-dominant business strategy canvas is available. This canvas is
inspired by the well-known Business Model Canvas of [2], but focusses on the strategy level
in a service-dominant context.
 For business model design, a service-dominant business model radar is available. Like a
canvas, this tool is a template for business design. Unlike other business modeling tools, the
radar tool has network-centric business model design at its core (shown in its circular
design), allowing the composition of service design in multi-party business networks.
 For service composition design, models are available from established business process
management practice, applied in a service management context. These include both the
support of provider-managed service solutions and customer-managed service solutions.
 For business service design, models, templates and design criteria are available for the
creation of well-structured business service catalogs. These catalogs are the basis for the
agile creation of multi-party service compositions.

32
For merely illustrative reasons, an example business strategy canvas and business model radar are
shown below (taken from a service-dominant business design in the travel industry domain). The
business model radar shows one of the business models associated with the business strategy
modeled in the strategy canvas. Similar models can be constructed for business strategies and
business models in the transport and mobility domain, supporting a clear decoupling between long-
term strategic business design (e.g., including the development and deployment of core capabilities
based on complex, costly infrastructures) and medium-term tactic business design (covering the
development of multi-party collaboration and earning models).
Figure 14 Service Dominant Strategy Canvas for TraXP example

33
Figure 15 Service Dominant Business Model Radar for TraXP example
A.3.1 Graphical Annotation of Business Model Radar
In Service-Dominant Business Model Radar we introduced the main elements of the business model
radar (core, concentric rings and radial regions). Here, we explain some graphical notations for
understandability/readability reasons:
- The Customer is represented in the rightmost sector of the upper half part of the radar. The
full sector is colored with a bluish tinge, i.e. light blue. The name has also a dark bluish color
and is underlined.
- The Focal Organization is represented in the rightmost sector of the lower half part of the
radar. The full sector is colored with a reddish tinge, i.e. light red. The name has also a dark
reddish color and is underlined.
- The names of Core and Enriching Partners are written in a bluish color. Core Partners are
distinguished by underlining.
- The fields of “actor value proposition” and “actor coproduction activities” of all actors have
the same (e.g. bluish) color.
- Benefits are indicated by a “+” sign, while costs are indicated by a “-“ sign.
- For costs/benefits of each actor, the color of the text depends whether it is related to a
benefit/cost of another actor(s) or not.
o If the cost/benefit is independent to any other benefit/cost and is exclusive for the
actor, a default (e.g. dark blue) color is used.
o If a cost/benefit is related to a benefit/cost of another actor(s) that appear in the
radar, the same colors (not the default ones) are used. For instance, in the example
of Figure 15, the kickback fees as a benefit for TraXP has the same (green) color with

34
the kickback fees that Trasnsport, Accomondation and Insurance companies have to
pay to TraXP.
Note that other colorations can be used but there should be a consistency like described above.

35
Appendix B: Participants per workshop
Below we present the lists of participants per workshop.
Table 2 Session 1 (Wednesday, 29th October, 16.00 hr – 18.00 hr)
Name
Organization
Aafke den Hollander
Ingenieursbureau Amsterdam
Paul Grefen
Eindhoven University of Technology (TU/e)
Kostas Traganos
Eindhoven University of Technology (TU/e)
Marco Geresse
Amsterdam ArenA
Joris Feis
Trinite
Karin Ruben
Parkeergebouwen Amsterdam
Daniel van Motman
Gemeente Amsterdam , DIVV
Arnold Meijer
TomTom
Hans Kramer
Rijkswaterstaat
Giovanni Huisken
MapTM
Joost van Os
Stadsregio Amsterdam
Table 3 Session 2 (Thursday, 30th October, 10.00 hr – 12.00 hr)
Name
Organization
Aafke den Hollander
Ingenieursbureau Amsterdam
Paul Grefen
Eindhoven University of Technology (TU/e)
Kostas Traganos
Eindhoven University of Technology (TU/e)
Martin Cramer
Mojo
Ronald Fiolet
Ziggo Dome
Bep van der Molen
Villa ArenA
Maarten Egmond
Gemeente Amsterdam, Stadsregisseur
Henk Haverkamp
Stadsdeel Zuidoost
Table 4 Session 3 (Thursday, 30th October, 13.00 hr – 15.00 hr)
Name
Organization
Aafke den Hollander
Ingenieursbureau Amsterdam
Paul Grefen
Eindhoven University of Technology (TU/e)
Kostas Traganos
Eindhoven University of Technology (TU/e)
Annet van Veenendaal
Rijkswaterstaat
Harm Jan Mostert
Provincie Noord Holland
Luuk Verheul
Connecting Mobility

36
Appendix C: Business Models – Results of Workshops
Following the approach described in Approach, three blueprints business model radars were drawn
per workshop. The original models were interactively composed on large posters with the use of
post-its and can be seen in Appendix D: Original Sketches of Business Model Radars. Here we
present these radars in a digital format.
C.1 Workshop 1 – Ultimate Event Experience
The identified value-in-use of this business model is the Ultimate Event Experience for visitors of an
event in the area of Amsterdam Zuidoost. An Event Organizer can play the role of a focal
organization with the experience they have in the event content. The customer is the Mass Event
Visitor who is part of a crowd coming to the area. An Event Location Provider is a core partner since
most of the events are held in specific premises/facilities. Road Authorities, Transportation Providers
and Traffic Data Providers will enrich the value-in-use by providing easy access and relocation from
the visitor’s home place to the event venue.
The main benefit for the customer will be a concentrated joy and good memories from the
experience of visiting the event he/she desired to. Of course, this will incur an integrated passport
ticket, including both the event ticket price and any transportation tickets (we assume that the Event
Organizer will charge for any transportation service so the user does not have to care for any extra
tickets). The integrated passport ticket is paid to the Event Organizer, while in turn they have to pay
fees for renting the location of the event. The Event Location Provider will receive these renting fees.
For the Road Authority, the main benefit we foresee is the upfront travel information of the visitors
to a specific area, in specific time range. This will subsequently lead to better traffic management.
That information is also beneficial for the Traffic Data Provider for getting insight in future for similar
events.
The business model radar is presented in Figure 16.

37
Figure 16 Workshop 1 - Ultimate Event Experience
C.2 Workshop 2 – Stress-free Event Journey
Event visitors want to have a good time and positive experience without having to care much about
transportation and any event related issues. A business model with a Stress-free Event Journey
value-in-use will contribute to that direction. The Event Organizer undertakes the role to orchestrate
the other parties like the Event Venue provider, who provides comfort, the Road Authority who
provides quick access and safe traveling to the event, the Parking Operator who provides parking
services so the visitor does not have to care about his car while enjoying his favorite music band, the
Public Transport Provider and any Infrastructure Provider for traffic management. Retailers are also
part of the business model since they contribute to customer’s experience with pre- and post-event
convenience (shopping, eating, etc.). Apart from people who are visiting an event, we care also
about those who are using the same road network around Amsterdam Zuidoost, the Non-Event
Visitors.
The Event Visitor will take advantage of the provided solutions when visiting an event but he will pay
the ticket (including transportation and parking tickets) and any other money in the shops/bars he
will visit. The Event Organizer will receive the ticket fees and also will increase their reputation by
providing a stress-free experience. To do so, they have to pay rent to the Event Venue provider, pay
fees for parking services of their customers and any public transport tickets, and of course pay the

38
artist. To be part of this business model and reap the benefits, the Event Venue provider has to
increase its operational costs for providing more and of better quality services. The Road Authority
will also benefit of that business model since such a solution will increase the reputation of the city
and consequently attract more visitors and will reduce any operational costs. On the other hand,
their duty of providing reliable traffic management can be considered as their main cost. The
benefits for the Parking Operator are the parking fees that they get from the Event Organizer (who
gets them from Event Visitors) and the efficiency in their service provision through the upfront
information. However, this will incur extended operational costs. Regarding the Retailers, the
turnover is an issue that needs further financial analysis whether it will be positive or negative. This
is because the spending of the event visitors may be equilibrated by the fact that less people who
are not visiting the event will go for shopping, drink or dinner during the event in order to avoid the
crowd. The crowd will also result in more efforts to provide accessibility to that places
(shops/cafes/bars). Finally, for Non-Event Visitors, the advanced traffic solutions will help them in
the accessibility to the area, however they will have to endure the nuisance that the event visitors
cause.
The business model radar is presented in Figure 17.
Figure 17 Workshop 2 – Stress-free event journey

39
C.3 Workshop 3 – Free Ride Amsterdam Event
The idea for this business model is rather extreme since it proposes a “free ride” to an event to
those who plan their arrival by car at a much earlier time than the beginning of the event. The term
free refers to free parking (or even fuel consumption coupons, however in that case we should
consider gas station owners as co-creation actors). With that scenario traffic jams will be reduced
and many stakeholders need to contribute. A Mobility Broker is the focal organization who gets data
and services from Road Authority, Parking Provider, Event Location Provider, Event Organizer and
Retail, orchestrates them and serve the event visitor. Since the services are free, the cost for the
customer are non-monetary but in terms of flexibility and sacrifices in their time schedule. The
Mobility Broker will get kickback fees from the Event Organizer, the Event Location Provider and the
Retailers since these stakeholders will have an increased turnover from visitors who will spend their
money in activities before, during and after the event. However, the broker will pay fees to the
Parking Operator for providing parking services to its customers. For the Road Authority, the main
benefit is that they will decrease the operational costs for providing traffic management due to less
traffic jams. On the downside, they have to get and manipulate the traffic data.
The business model radar is presented in Figure 18.

40
Figure 18 Workshop 3 – Free ride Amsterdam event

41
Appendix D: Original Sketches of Business Model Radars
Below we include photographs of the original paper versions of the business model radars that were
sketched during the workshops.
Figure 19 Workshop 1 - Business Model Radar

42
Figure 20 Workshop 2 - Business Model Radar

43
Figure 21 Workshop 3 - Business Model Radar

44
Appendix E: Description of elements of Physical view
Below we present an explanation of the elements of the five layers of the Physical view of the
system architecture of an ITS (Figure 22), as described in [4].
Central
Traveller /
VRU
Vehicle
Roadside
Support
Roadside Syste m
(RS)
Vehicle Pl atfo m
(VEE)
Personal Infor mation
Device
Vehicle On-Boa rd
Unit (OBU)
Vehicle VRU
Localization System
(V-VLS)
Roadside Un it
(RSU or RIS )
Service Provide r
Back-Offic e
(SP BO)
Data Provide r Back-
Office (DP BO )
Traffic Mana gement
System (TM S)
Traffic Informa tion
System (TIS)
VRU-OBU
Service P rov ider
Exchang e System
(SPES)
Remote Veh icle OBU
(R-OBU)
Governance Te st & certification
Managem ent
Security & c re dentials
Management
VRU Transp onder
(VRU-T)
Roadside VRU
Localization Syst em
(R-VLS)
Communi ca tion
Provider Ba ck-Office
(CP BO)
Operational
Managem ent
Remote VRU -OBU
Figure 22 ITS Reference Architecture Physical View: With Sub-systems
At the support layer the following sub-systems are defined:
1. Governance system: A system from policy makers for regulations & enforcement of the ITS
system of environment / safety measures;
2. Test and certification management system: A system for registration of tested and certified
communication systems for ITS (safety) applications;
3. Security and credentials management system: A high-level aggregate representation of the
systems that enable trusted communications between mobile devices, roadside devices and
centers, and protect data from unauthorized access. This sub-system will be implemented as
an interconnected system of support applications that enable the secure distribution, use, and
revocation of trust;
4. Operational Management System: A system for operational processes like fault, performance
and configuration management of the sub-systems.
At the central layer the following sub-systems are defined:
1. Traffic Management System (TMS): A TMS is the functional back-office system of the
responsible road operator to enforce legal actions on urban or high-way road sections or
intersections based on real-time traffic data from loops, cameras, speed sensors, etc. or
actions by traffic controllers. The real-time data that flows from the Traffic Info System is
integrated and processed by the TMS (e.g. for incident detection), and may result in traffic
measures (e.g. traffic routing, dynamic speed limits) with the goal of improving safety and
traffic flow;

45
2. Traffic Information System (TIS)
4
: A Traffic Information System is the functional back-office
system of a road-operator to collect and process real-time traffic data from traffic data
systems (e.g. roadside sensor systems (loops, cameras) or connected vehicles) and to
distribute real-time and/or aggregated information on traffic state (speed, flow and travel
times) or road state to TMS or external systems like a Service Provider Back-Office (SP-BO). In
practice several distributed TIS from different road operators can be interconnected to a
central TIS (e.g. from NDW), which provides aggregated information for the Netherlands;
3. Service Provider Back-Office (SP BO): A generic back-office system of a service provider used
for the specific services of the SP to connected drivers or end-users to inform end-users or
other SP BO systems from providers. A SP BO can be used to support personal information
services for, e.g. navigation or traffic information applications on OBU/PID. A SP BO can also
be used to gather floating car data from OBU/PID;
4. Data Provider Back-Office (DP BO): A Data Provider BO system is a data system that collects
and fuses floating car data and real-time traffic data from roadside sensor systems to increase
insight in actual and expected traffic state (e.g. on traffic jams). The DS also distributes
enriched (aggregated) information on traffic state (speed, flow and travel times) to service
providers;
5. Communication Provider Back-Office (CP BO) or Central ITS System (CIS): A generic back-
office system of a communication provider used for access at several communication layers
from other BO systems (like SP BO, TMS, TIS etc.) to send and receive ITS information to/from
vehicles or other road users;
6. Service Provider Exchange System (SPES): an e-Market (“broker”) system for discovery and
exchange of ITS (end-user) services and ITS communication services; the SPES can support
functions like service discovery, service authentication, authorization, accounting (AAA) and
billing.
Other back-office systems can also be located at this layer depending on the type of application.
One example is a Fleet and Freight Management System which provides the capability for
commercial drivers and fleet-freight managers to receive real-time routing information and
access databases containing vehicle and/or freight equipment locations as well as carrier, vehicle,
freight equipment and driver information. Fleet and Freight Management Center also provides
the capability for fleet managers to monitor the safety and security of their commercial vehicle
drivers and fleet.
In the roadside (or field) area the following sub-systems are defined:
1. Roadside System (RS): Different types of existing roadside systems are identified:
a. Roadside Substation (RSS): a system deployed along high-ways and includes sensors
(loops), control logic and actuators. The system can run as a stand-alone closed loop
system i.e. run stand-alone local traffic control functions (e.g. traffic jam tail detection
and warning via Variable Message Signs) or can be controlled by the TMS;
b. Traffic Light Controller (TLC): a TLC is a specific type of roadside system. It includes the
input from loop detectors or other sensors, a control logic, and the actuation of the traffic
lights. A TLC can be run as a stand-alone closed-loop traffic control system. A TLC can also
be controlled by a central Traffic Management System, e.g. in green wave applications
between different TLC’s. A TLC is deployed on urban road or can be deployed at highway
access roads for access control;
4
A split is made between TMS and TIS. A TMS receives traffic information always via a TIS, and sends traffic
actuation measures always to external systems via a TIS. In real world a TMS consists of several building blocks
for traffic control.

46
2. Roadside Unit (RSU) or Roadside ITS System (RIS): A RSU/RIS is a cooperative roadside
communication system responsible for the two-way communication functionality at a part of a
road network (typically an intersection or a road section of 500m – 1km). This physical object
is responsible for implementing communication functionality in the roadside layer and
optionally also application functions. A RSU/RIS is part of the ITS reference architecture
standardised by the European Telecommunication Standards Institute (ETSI ITS). A RSU/RIS is
part of the roadside communication network with distributed radio units, and centralized
functions covered in the Communication Provider Back-Office.
In the vehicle area the following sub-systems are defined:
1. Vehicle Platform or Vehicle E/E system (VEE): The Vehicle Electrical and Electronic system
(E/E) system includes all in-car sensors (speed, lights, etc.) and actuators (brake, etc.). The
Vehicle Electrical and Electronic system provides sensor information (e.g. speed) from a
vehicle to an external Cooperative-ITS (C-ITS) system and optionally enables the
control/actuation (e.g. speed control) of that vehicle by an external system. The Vehicle E/E
must include safety measures to ensure the safe operation of the vehicle, independent of the
interaction between the Vehicle E/E and external sub-systems. A further differentiation can be
made per vehicle type, e.g. emergency vehicle, commercial vehicle or (public)
transport/transit vehicle;
2. Vehicle On-board Unit (OBU): An on-board unit is a sub-system attached to a car and needed
for driver assisted applications to inform / advise a driver via a HMI. The OBU provides the
vehicle-based processing, storage, and communications functions necessary to support
connected vehicle operations. The radio(s) supporting Vehicle-to-Vehicle (V2V) and Vehicle-
to-Infrastructure (V2I) communications are a key component of the Vehicle OBU. Four
different types of implementations are represented by the Vehicle OBU:
a. Vehicle Awareness Device – This is an aftermarket electronic device, installed in a vehicle
without connection to vehicle systems that is only capable of sending the basic safety
message over short-range communications. Vehicle awareness devices do not generate
warnings;
b. Aftermarket Device – This is an aftermarket electronic device, installed in a vehicle, and
capable of sending and receiving messages over a wireless communications link. The self-
contained device includes GPS, runs connected vehicle applications, and includes an
integrated driver interface that issues audible or visual warnings, alerts, and guidance to
the driver of the vehicle;
c. Retrofit Device – This is an electronic device installed in vehicles by an authorized service
provider, at a service facility after the vehicle has completed the manufacturing process
(retrofit). This type of device provides two-way communications and is connected to a
vehicle data bus to integrate the device with other on-board systems. Depending on
implementation, the device may include an integrated driver interface and GPS or
integrate with modules on the vehicle bus that provides these services;
d. Integrated System – This is a system of one or more electronic devices integrated into
vehicles during vehicle production. The Integrated System is connected to proprietary
data busses to share information with other on-board systems. The Integrated System
may include many control modules.
In retrofit and integrated implementations, the Vehicle OBU interfaces to other on-board
systems through a vehicle bus (e.g., Controller Area Network - CAN), represented as the
Vehicle Platform, this interface provides access to on-board sensors, monitoring and control
systems, and information systems that support connected vehicle applications. The vehicle
bus may also be the source for GPS location and time, and the access point for the vehicle's

47
driver-vehicle interface. Self-contained devices include an integrated GPS and driver interface
that supports direct visual, audible, or haptic interaction with the driver. The Vehicle OBU
includes the functions and interfaces that support connected vehicle applications for
passenger cars and trucks. Many of these applications (e.g., V2V Safety applications) apply to
all vehicle types including personal automobiles, commercial vehicles, emergency vehicles,
transit vehicles, and maintenance vehicles. The Vehicle OBU is used to model the common
interfaces and functions that apply to all of these vehicle types, i.e. also commercial, public
transport or emergency vehicles;
3. Remote Vehicle OBU (R-OBU): Remote Vehicle OBUs represents other vehicles that are
communicating with the host vehicle. This object provides a source and destination for
information transfers between connected vehicles. The host vehicle on-board unit,
represented by the Vehicle OBU physical object, sends information to, and receives
information from the Remote Vehicle OBUs to model all vehicle V2V communications.
At the traveller / VRU layer the following sub-systems are defined:
1. Personal Information Device (PID): A personal information device is typically a smartphone or
personal navigation device used by an end-user. The PID provides the capability for travellers
to receive formatted traveller information wherever they are. Capabilities include traveller
information, trip planning, and route guidance. It provides travellers with the capability to
receive route planning from the infrastructure at home, at work, or on-route using personal
devices that may be linked with connected vehicle on-board equipment. A PID might include
the communication functionality of a Personal ITS station, as specified in ETSI ITS
specifications;
2. VRU Vehicle OBU (VRU-OBU): an on-board unit is a sub-system attached to a VRU vehicle (e.g.
moped, electric bike) and needed for VRU assisted applications to inform / advise a driver via
a HMI;
3. VRU Transponder (VRU-T): a VRU transponder is part of a tag-based communication system.
A transponder can be active (i.e. with own battery, sending data at constant time intervals),
semi-passive (with own battery, sending message at request of an interrogator) or passive
tag/chip (without own battery, responding to interrogator request). The tags communicate
with an external interrogator, called VRU Localisation System, which can be integrated in a
vehicle (car, bus, truck) or in a roadside system:
 Vehicle VRU Localization System (V-VLS): A VRU Localization System is part of a tag-
based communication system.
 Roadside VRU Localization System (R-VLS): A VRU Localization System is part of a tag-
based communication system. The VRU transponder carried by a VRU, is an active (i.e.
with own battery) or passive tag/chip that can respond on an interrogation signal
(trigger) from the VRU Localisation System. A VRU Localization System can be integrated
in, e.g., a Traffic Light to detect the presence of a specific user, e.g. a person with a
disability.
The VRU transponder carried by a VRU, is an active (i.e. with own battery) or passive tag/chip
that can respond on an interrogation signal (trigger) from the VRU Localisation System. This
transponder is different from a VRU OBU system, since the transponder is only able to send a
limited amount of data (typically only ID and potentially some sensor values, and not able of self-
locating).

48
Appendix F: Business – System Architecture mapping for BM
1 and BM 3
For reasons of completeness, we present here the mapping for the complete business models 1 and
3.
F.1 Mapping for Business Model 1
Below we present how elements of the business model radar of Figure 3 (actors and activities) map
to the physical view of an ITS architecture.
Traveller /
VRU
Event
Location Provider
Event Organizer
Public/Private
Transport Facilities
Provider
VRU
Vehicle
Driver
Transport Info
Provider
Transport Data
Provider Parking Operator
Central
Provides reliable real time data
Provides real t ime travel info
Drives there
Vehicle
Provides trip
Provides par king info
Gets there
Roadside
Support
Roadside Sy stem
(RS)
Vehicle Platfo m
(VEE)
Personal Inform ation
Device
Vehicle On-Bo ard Unit
(OBU)
Vehicle VRU
Localization Syst em
(V-VLS)
Roadside Unit
(RSU or RIS)
Service Pro vider Back-
Office
(SP BO)
Data Provide r Back-
Office (DP BO)
Traffic Mana gement
System (TMS )
Traffic Inform ation
System (TIS)
VRU-OBU
Service Pro vider
Exchange Syst em
(SPES)
Remote Vehic le OBU
(R-OBU)
Governanc e Test & certif ication
Management
Security & cred entials
Management
VRU Transponde r
(VRU-T)
Roadside VRU
Localization Syst em
(R-VLS)
Communica tion
Provider Ba ck-Office
(CP BO)
Operational
Management
Remote VRU- OBU
Gets there
Provides par king info
Gathers traffic d ata Authenticat es/Authorizes services
Figure 23 Business - System Architecture Mapping - Business Model 1
Note here the split of the Mass Event Visitor to two actors, namely Vehicle Driver and VRU. This is
done because in the business model we included both car event visitors and those who travel by
public means of transport (or walk to the event venue).
Similarly, we split the Transport Facilities Provider to Parking Operator, who is responsible for
providing parking services and Public/Private Transport Facilities Provider who provides trip for
event visitors who do not take their vehicle to drive to the event venue.
By mapping now actors and their activities to the physical view in which connections of sub-
elements are presented, we get the following Figure 24:

49
Vehicle
Central
Traveler
Roadside
Support
Event
Location Provider
Event Organizer
Public/Private
Transport Facilities
Provider
VRU
Vehicle
Driver
Transport Info
Provider
Transport Data
Provider Parking Operator
Provides reliable real time data
Provides real t ime travel info
Drives ther e
Provides trip
Gets there
Provides p arking info
Roadside System
(RS)
Vehicle Platfom
(VEE)
Personal
Information Device
OBU
Service / Data
Provider BO
(SP / DP BO)
Comm. Provider
Back-Office (CP BO
or CIS)
Traffic
Management
System (TMS)
VRU-OBU
Service Provider
Exchange System
(SPES)
Remote Vehicle
OBU (R-OBU)
RSU or RIS
Traffic
Information
System (TIS)
Remote VRU-OBU VRU-Transponder
(VRU-T)
Vehicle VRU
Localization System
(V-VLS)
Roadside VRU
Localization System
(R-VRS)
Service Provider
Back-Office
(SP BO)
Governance
Test &
certification
Management
Security &
credentials
Management
Operational
Management
Gets there
Gathers traffic data
Authenticates /Authorizes services
Figure 24 Business - System Architecture Mapping with connections - Business Model 1
One point we have to stress on the above figure is that main components like Traffic Management
System (TMS) or Roadside Unit (RSU or RIS), which appear to be connective components among
layers, are greyed. As we had explained in Physical View – High Level with building blocks, these
elements are owned/managed by actors that do not appear in the business model. Needless to say
that they are required in the deployment of an ITS, having to think in that case who of the identified
actors can take responsibility of those or whether is better to include more actors in the business
model.
Presenting now actors, architecture elements and activities performed by these actors on the linked
elements in a tabular form, he get the following table:

50
Table 5 Actors - Elements mapping for Business Model 1
Actor/Stakeholder
Architecture element
Activities
Event Organizer
None
Non ITS-related activities.
Vehicle Driver
Vehicle On-Board Unit (OBU)
The driver uses the OBU of his vehicle
to get traffic/navigation information on
how to get to the venue of the event.
Vulnerable Road User
(VRU)
Personal Information Device
A VRU can either use a PID or a VRU-
OBU to get traffic/navigation
information on how to get to the venue
of the event.
VRU On-Board Unit (VRU-OBU)
Event Location Provider
Nonne
Non ITS-related activities
Parking Operator
Traffic Information System (TIS)
The parking operator provides
information on the availability of parking
slots in his facilities to TIS which can be
further used from the TMS for traffic
management.
Public/Private Transport
Facilities Provider
VRU On-Board Unit (VRU-OBU)
Since the main activity is to provide
transportation, we focus on the driver of
a transport means (e.g. bus) who uses
the OBU of his vehicle to get traffic
information regarding his route.
Transport Info Provider
Service Provider Back-Office (SP BO)
The traffic info provider uses back-
office systems to provide real time
travel information to its users.
Service Provider Exchange System
(SPES)
SPES is also used for traffic information
provisioning and for service
authentication and authorization
purposes as well.
Transport Data Provider
Data Provider Back-Office (DP BO)
The traffic data provider uses back-
office systems to manipulate and
provide reliable real time traffic data.
Roadside System (RS)
Traffic state information from roadside
substations and traffic light controllers
needs to be gathered by the Traffic
Data Provider, meaning that a link to
RS is necessary.
F.2 Mapping for Business Model 3
Below we present how elements of the business model radar of Figure 5 (actors and activities) map
to the physical view of an ITS architecture.

51
Central
Event Visitor
Road Authority
Mobility Broker
Event
Location Provider
Event OrganizerRetailer
Parking Operator
Vehicle
Roadside
Support
Roadside System
(RS)
Vehicle Platfo m
(VEE)
Vehicle On-Bo ard Unit
(OBU)
Vehicle VRU
Localization Syst em
(V-VLS)
Roadside Unit
(RSU or RIS)
Service Provider Back-
Office
(SP BO)
Data Provider B ack-
Office (DP BO)
Traffic Man agement
System (TMS)
Traffic Informat ion
System (TIS)
Service Pro vider
Exchange Syst em
(SPES)
Remote Vehic le OBU
(R-OBU)
Governance Test & certification
Management
Security & cred entials
Management
Roadside VRU
Localization Syst em
(R-VLS)
Communica tion
Provider Back- Office
(CP BO)
Operational
Management
Provides p arking info
Orchestrate s services
Manages tra ffic
Provides infra
Drives there
Provides servic es
Figure 25 Business - System Architecture Mapping - Business Model 3
In this business model we see that we do not have an explicit Service Provider for traffic information
or navigation services. The concept of the business model is that traffic jams will be avoided due to
the fact that visitors schedule their arrival to the event venue much earlier that the starting time of
the event. One assumption could be that the Mobility Broker could provide traffic information
services or this could be done through a subcontractor, like we did in in Mapping for Business Model
2 with the mapping of Business Model 2. However, we keep the business model simple and thus only
a few actors appear in the business – system architecture mapping.
By mapping now actors and their activities to the physical view in which connections of sub-
elements are presented, we get the following Figure 26.

52
Vehicle
Central
Roadside
Support
Event Visitor
Road Authority
Mobility Broker
Event
Location Provider
Event OrganizerRetailer
Parking Operator
Provides parking info
Orchestrate s services
Manages tra ffic
Provides infra
Drives ther e
Roadside System
(RS)
Vehicle Platfom
(VEE)
OBU
Service / Data
Provider BO
(SP / DP BO)
Comm. Provider
Back-Office (CP BO
or CIS)
Traffic
Management
System (TMS)
Service Provider
Exchange System
(SPES)
Remote Vehicle
OBU (R-OBU)
RSU or RIS
Traffic
Information
System (TIS)
Governance
Test &
certifica tion
Management
Security &
credential s
Management
Operational
Managem ent
Provides servic es
Figure 26 Business - System Architecture Mapping - Business Model 3
Actors, architecture elements and activities performed by these actors on the linked elements are
presented in a tabular form below.
Table 6 Actors - Elements mapping for Business Model 3
Actor/Stakeholder
Architecture element
Activities
Mobility Broker
Service Provider Exchange System
(SPES)
The mobility broker uses an e-Market
system to orchestrate services among
stakeholders (providing
authorization/authentication).
Service Provider Back-Office (SP BO)
A SP BO is also needed in order the
Mobility Broker can provide services to
its customers, event visitors and other
parties.
(Scheduled) Event
Visitor (by Car)
Vehicle On-Board Unit (OBU)
The driver uses the OBU of his vehicle
to get traffic/navigation information on
how to get to the venue of the event.
Parking Operator
Traffic Information System (TIS)
The parking operator provides
information on the availability of
parking slots in his facilities to TIS

53
which can be further used from the
TMS for traffic management.
Road Authority
Traffic Management System (TMS)
Provides traffic management through
the TMS
Roadside Unit (RSU or RIS)
Responsible for the road side
infrastructure.
Retailer
None*
Non ITS-related activities (could be
possibly linked to SPES to get
information on expected visitors/times
of arrivals).
Event Organizer
None*
Non ITS-related activities (could be
possibly linked to SPES to get
information on expected visitors/times
of arrivals).
Event Location Provider
None*
Non ITS-related activities (could be
possibly linked to SPES to get
information on expected visitors/times
of arrivals).
*Event Organizer, Event Location Provider and Retailer could possibly be linked to Service Provider
Exchange System (SPES) which is managed by the Mobility Broker. They can do so in order to have
access to information on how many visitors plan to visit the area and at what time slots. However,
we make the assumption that this information can be provided through own, non-ITS systems.

54
Appendix G: Contributors
The following people contributed to the completion of the work presented in this report.
Table 7 Contributors
Name
Organization
Hans Kramer
Rijkswaterstaat
Harry Ooststroom
Rijkswaterstaat
Ronald Adams
Rijkswaterstaat