Business Models and Service Applications for Traffic Management
Brahmananda Sapkota
1
, Marten van Sinderen
1
and Boris Shishkov
2
1
EWI – University of Twente, Drienerlolaan 5, Enschede, The Netherlands
2
IICREST, 53 Iv. Susanin Str., Sofia, Bulgaria
Keywords: Business Modeling, Service-oriented Architecture, Web Services, Traffic Management.
Abstract: Managing traffic becomes more and more dependent on ICT – Information and Communication
Technology, in general and particularly on ICT services support. Safety, pollution, congestion, and travel
time are all important concerns that point to needs for improving traffic management and realizing this
would concern the supportive services (including ICT services). Technology-independent functionality
models are not only needed for better understanding the (used and/or desired) (IT) services and discussing
them of full value with both developers and users but also for establishing appropriate traceability that
would allow updating the underlying technology accordingly based on desired updates in the service
support. That is why business models and service applications need to be considered together. Hence, in
addressing service applications for traffic management, we would emphasize on the crucial role of business
process analysis and technology-independent modeling. Further, service applications relate to corresponding
ICT-based service platforms that provide relevant support – in the case of traffic management, it would be
for example: localized monitoring and management of traffic and environmental information collected from
various information sources such as sensors, surveillance cameras, and weather stations. Such information
should be made available through the services in order to increase reusability, loose coupling and
management of different information and their analysis. With regard to this, two significant challenges
relate to service discovery and interoperability. This paper, reporting research in progress, emphasizes not
only on service applications (particularly for traffic) and relations to business modeling, but also on the
challenges mentioned above. In this way, we present some visions on how to better benefit from business
models and IT services, for usefully improving traffic management, partially exemplifying this.
1 INTRODUCTION
The use of Information and Communication
Technology (ICT) is increasingly proliferating in
transport vehicles. It is applied to support the main
functions like car management and supporting the
driver to navigate the vehicle from A to B. We begin
to see intelligent systems using sensors and actuators
to prevent accidents, for example when the car is
approaching other cars too closely. Other
applications include information systems like
navigators to guide the driver to their destination
taking traffic information into account. Other ICT
systems are there to entertain the travelers with
music and/or video movies. The above mentioned
functionalities have been developed independently
of each other: car sensors, engine management,
traffic information systems, entertainment, and
telecommunications. A number of these
developments are currently specific to the car
manufacturer and therefore the brand of the car. In
near future, cars (of different brands) will be able to
exchange information (FIATS-M, 2012).
Nevertheless, with more and more cars appearing in
urban streets due to commuting and increasing
transportation needs, we experience severe traffic
jams, especially during peak hours resulting to: (i)
increasing CO2 emissions; (ii) people spending
more time in traffic jams; (iii) wasting of fuel; (iv)
stress levels increasing with drivers. Managing
traffic in a better way is thus crucially important
currently.
Managing traffic itself becomes in turn more and
more dependent on ICT services support. Safety,
pollution, congestion, and travel time (as mentioned
before in this section) are all important concerns that
point to needs for improving traffic management and
realizing this would concern the supportive services
(including ICT services). Technology-independent
functionality models are not only needed for better
165
Sapkota B., van Sinderen M. and Shishkov B.
Business Models and Service Applications for Traffic Management.
DOI: 10.5220/0004462401650169
In Proceedings of the Second International Symposium on Business Modeling and Software Design (BMSD 2012), pages 165-169
ISBN: 978-989-8565-26-6
Copyright
c
 2012 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

understanding the (used and/or desired) (IT) services
and discussing them of full value with both
developers and users but also for establishing
appropriate traceability that would allow updating
the underlying technology accordingly based on
desired updates in the service support. That is why
business models and service applications need to be
considered together (Shishkov, 2011). Hence, in
addressing service applications for traffic
management, we would emphasize on the crucial
role of business process analysis and technology-
independent modeling. Further, service applications
relate to corresponding ICT-based service platforms
that provide relevant support – in the case of traffic
management, it would be for example: localized
monitoring and management of traffic and
environmental information collected from various
information sources such as sensors, surveillance
cameras, and weather stations. Such information
should be made available through the services in
order to increase reusability, loose coupling and
management of different information and their
analysis. With regard to this, two significant
challenges relate to service discovery and
interoperability.
This paper, reporting research in progress,
emphasizes not only on service applications
(particularly for traffic) and relations to business
modeling, but also on the challenges mentioned
above. In this way, we present some visions on how
to better benefit from business models and IT
services, for usefully improving traffic management,
partially exemplifying this.
The remaining of this paper is as follows:
Section 2 discusses IT services and also their
relation to business modeling. Section 3 discusses
the challenges as mentioned already. Section 4
outlines some envisioned solution directions.
Section 5 provides partial exemplification. Finally,
Section 6 contains the Conclusions.
2 IT SERVICES
In this section, we consider IT services in general
(broader) and web services, in particular (these are
those IT services which are delivered particularly
through Internet). Let’s nevertheless start from the
service concept: from an abstract point of view, a
service represents a piece of well-defined
functionality that is available at some network
endpoint and is accessible via various transport
protocols and specialization formats. The
functionalities provided by services cover a vast
spectrum reaching from low level features like
offering storage capabilities, over simple application
functions like changing a customer address, to
complex business processes like hiring a new
employee (Alonso, 2004).
The ability to create new ICT applications from
existing services, independently on who provides
these services, where they are provided, and how
they are implemented, would mean usefully utilizing
the service perspective in application development
(Van Sinderen, 2012). Such kind of application
development is innovative not only because the
application is not constructed from the scratch
(actually, this is true also for component-based
application development) but also because the
development itself is fully centered around the
desired end functionality to be consumed by users
(this leads to service compositions and hence
developers would no longer possess full control over
all software components that play roles in delivering
the application functionality). Hence, the application
development task (as considered in general) might
split into: (i) development of small software modules
delivering generic adjustable services to whoever
might be interested in using them, and (ii)
composition of complex functionalities, by using
available generic services. This all inspires new
middleware developments also (Shishkov, 2011).
Furthermore, in order to be of actual use, such
services would demand enabling technology
standards and some recent views of Papazoglou
(2008) appear to be actual in this respect.
Transportation protocols are to be mentioned firstly
because logically, web services’ relying on a
transportation protocol is crucial. Although not tied
to any specific transportation protocol, web services
build on ubiquitous Internet connectivity and
infrastructure to ensure nearly universal reach and
support. Hence, their mostly relying on HTTP (the
connection protocol that is used by web services and
browsers) and XML (a widely accepted format for
all exchanging data and its corresponding semantics)
looks logical. Having this as foundation, we have to
briefly discuss three core web service standards,
namely SOAP, WSDL, and UDDI: (i) SOAP
(Simple Object Access Protocol) is a simple XML-
based messaging protocol on which web services
rely in exchanging among themselves information.
SOAP implements a request/response model for
communication between interacting web services.
(ii) WSDL (Web Service Description Language) is a
language that specifies the inter-face of a web
service, providing to the requestors a description of
the service in this way. (iii) UDDI (Universal
Second International Symposium on Business Modeling and Software Design
166

Description, Discovery, and Integration) represents a
public directory that not only provides the
publication of online services but also facilitates
their eventual discovery. And finally, as part of the
web services composition, we need to introduce
some orchestration defining their control flows
(Alonso, 2004), such as sequential, parallel,
conditional, and so on, and to also determine
complex processes that would usually span many
parties. BPEL4WS (Business Process Execution
Language for Web Services) can usefully support
such composition activities. Finally, as the
collaboration among many parties (through their
web services) is concerned, a common observable
behavior (choreography) would often need to be de-
fined. CDL4WS (Choreography Description
Language for Web Services) can usefully support
such collaboration descriptions.
In SUMMARY: all those details related to IT
(Web) services essentially point to business analysis
and business modeling activities to be done as
‘background’.
3 CHALLENGES
As mentioned, two essential challenges with regard
to what has been discussed so far, are: (i) service
discovery; (ii) interoperability.
SERVICE DISCOVERY is of crucial
importance in identifying, composing, and
delivering a service but still here some issues have
not been convincingly resolved yet (Sapkota & Van
Sinderen, 2011). In an open environment, it is
difficult to support on-demand collaboration if the
published service descriptions are outdated
consequently providing incorrect information. This
difficulty escalates when service descriptions
contain limited information, i.e., some information
may be relevant to the discovery of services but
since this information depends on the runtime state,
it cannot be included in the service descriptions
(Van Sinderen, 2012). So, besides the “correctness”
(or “outdated information”) problem, we also have
the “state-dependency” (or “dynamic information”)
problem that leads to poor discovery results. For
more information on analyzing the service discovery
challenge, interested readers are referred to (Sapkota
& Van Sinderen, 2011).
SERVICE INTEROPERABILITY concerns
the ability of a service to collaborate with other
services (Van Sinderen, 2012). This requires that
different service ‘owners’ have to devise their
processes and agree on a shared universe of
discourse, such that their respective collaboration
goals can be fulfilled. Furthermore, it requires the
ability of exchanging information and of using the
information that has been exchanged in accordance
to the collaboration goals. If the collaboration is to
be supported by Information and Internet
Technology, underlying automated systems send and
receive messages containing user data to represent
the information. Communication protocols and data
formats are to be standardized to achieve syntactic
interoperability (exchange of data), and ontology
definitions and ontology languages have to be
developed to facilitate semantic interoperability
(interpretation of data). Hence, in order to achieve
interoperability, business requirements and
technology solutions have to be aligned.
4 SOLUTION DIRECTIONS
Taking all above in consideration, we can formulate
a strategic GOAL as follows: to design and develop
powerful and deployable service-oriented (road)
traffic management system able to support
individual mobility and network wide operations.
Fulfilling this goal is claimed to be non-trivial and
we have thus outlined several solution directions
whose justification is left beyond the scope of this
paper and whose further elaboration is considered as
future work:
- considering technology-independent
functionality models as ‘bridges’ between
user demands and technological
solutions;
- aligning technical solutions to the
existing standards for service discovery
and interoperability;
- balancing individual and group interests
through sophisticated rules and
regulations;
- aiming at solutions that are adequate with
regard to observing privacy and security.
5 EXAMPLE
In the current exemplification section, we would
consider a scenario presented at the FIATS-M’11
International Workshop (Sapkota, 2011):
Bob lives in the outskirt of Enschede with his
wife and two children. He is scheduled to have a
project meeting in Sofia at 11:00 PM on Friday. He
Business Models and Service Applications for Traffic Management
167

is occupied the entire day because of the kick-off
meeting of his recently acquired project on
Thursday. Because Bob is mostly busy with his work
(delivering lectures, attending meetings, and doing
research) during the weekdays, he spends his
weekend with his family as much as possible. When
his children know about his forthcoming trip to Sofia
on Friday, they were sad that they will not see him
during the weekend. So he promises his children that
he will return to take them to the world-famous
zoological garden in Emmen at the weekend.
He decides to travel Friday morning to Schiphol
where he will take an early flight to Sofia. Since
taking a train would not leave him enough time to
check in, he takes his car, which is equipped. with
Intelligent Route Planning (IRP) agent, radio and
Global Positioning System (GPS) devices.
He books the flight accordingly and downloads
his e-ticket to his smart phone. When the e-ticket is
downloaded, his smart phone recognizes it and
wirelessly communicates with an IRP agent installed
on his car. This agent communicates with the GPS
device installed on the car and determines the
required travel time to reach to Schiphol airport.
The IRP agent knows that Bob normally wants to
arrive at the airport 30 minutes before the normal
time as suggested by the airlines and thus calculates
the time Bob needs to start his journey. The IRP
agent communicates this information to Bob’s smart
phone. Bob’s mart phone then uses this information
and sets its alarm accordingly.
When he follows the route shown on his GPS
system, he suddenly encounters that the road is
blocked because of construction works. He then
ignores the advice that comes from the GPS system
and drives on a different road that is thus NOT
suggested by the GPS system. The GPS system
apparently does not know about this situation and
what Bob is doing because Bob is driving on a newly
constructed road; the GPS system keeps advising
Bob to take a U-turn if possible and Bob keeps
ignoring the advice and keeps driving using his own
instinct and sense of direction. After a while, the
GPS system recognizes the stretch of road that Bob
is driving and recalculates the route for Bob. The
route Bob has taken based on his own sense of
direction turns out to be a fast solution, especially in
early morning travel time. The IRP agent on his car
records this newly discovered route and updates the
map and broadcasts the plan to the passerby cars.
While on his way, the IRP agent installed on a
car coming from the opposite direction
communicates information of long jam of cars 10
KM ahead because of a recent accident to the IRP
agent installed on Bob’s car. The IRP agent then
communicates this information to the GPS system to
re-calculate the route.
When he is driving on the re-calculated route,
the IRP agent communicates with the Road-Side
Infrastructure (RSI) and finds out that the traffic
near the next junction where Bob has to turn right is
congested (the RSI can determine such a situation by
using information from loop detectors). The IRP
agent informs Bob to change the lane well in
advance. The IRP agent also predicts, based on the
current weather conditions, total number of current
road users and their average speed, that the joining
road ahead of the next junction could have black ice.
The IRP agent then informs Bob to drive at safe
speed to avoid a possible slippery road condition.
When Bob drives some 100 KM, the IRP agent
receives information from the RSI that there is a
poor visibility 20 KM ahead of the road and
schedules the light control system to brighten their
light calculating the time required to reach that spot.
When Bob passes the poor visibility area, the IRP
agent identifies that the visibility is OK and resets
the high to their original intensity through the light
control system.
When at parking lot at the airport, Bob’s car
recognises that his friend Dave is also at the airport,
and sends him an invitation for a coffee if he has
time. Dave replies with a call and they meet at a
nearby coffee shop. After having a chat with his
friend, Bob goes to check-in his flight and leaves for
Sofia.
After the meetings in Sofia, Bob returns to The
Netherlands. When he lands at the Schiphol airport,
he turns his smart phone on. His smart phone then
wirelessly communicates with the IRP Agent at his
car. The agent then communicates with the GPS
system and calculates the time required to reach his
home and informs his wife Alice about his arrival
time. Bob then continues his journey towards his
home following the route displayed on his GPS
system.
After driving 45KM, the road RSI communicates
to the radio device installed on his car that the road
further ahead is busy (which is expected because it
is a Friday night). The RPI agent receives this
information through the radio device installed on
Bob’s car and communicates with the GPS system to
recalculate the new route and new time required to
reach Bob’s home. It appears that Bob will arrive
home 30 minutes later than previously expected, the
IRP agent then informs Alice that Bob will be late by
30 minutes because of busy traffic.
Second International Symposium on Business Modeling and Software Design
168

The new road that Bob is driving now is
relatively empty ahead of him with just few cars
behind him. When he approaches Enschede, the IRP
agent communicates with the RSI and finds that an
ambulance is coming on the joining road at the
junction ahead and Bob will not be able to cross it
safely. The IRP agent then informs Bob to slow
down because the traffic light at the junction is
going to turn red because of the high priority vehicle
on the other road. When he starts decelerating, the
IRP agent communicates with the IRP agent on the
car behind Bob (which was out of the range of RSI
communication) and informs that Bob is
decelerating. The IRP agent on the car behind Bob
then informs his driver Tim to start decelerating to
avoid possible environmental pollution (noise, air)
and a possible collision because the car in front is
decelerating for some reason.
When the ambulance crosses the junction, RSI
broadcasts the message that it is going to turn the
traffic light to green because there are no other
vehicles on the joining road. The IRP agent informs
Bob to smoothly accelerate and move forward.
Finally, when Bob arrives at home, Alice is waiting
for him with a hot cup of coffee, he starts talking
with Alice while drinking his coffee.
Hence, a service platform is necessary, for
supporting communication between vehicles as well
as between vehicles and road infrastructure through
the concept of services orientation. The concept of
service orientation is used to integrate various types
of systems and services. It is also used for
supporting interoperation between these services and
systems. Furthermore, the service orientation allows
us to deploy services in the cloud to achieve
performance requirements such as scalability and
efficiency.
Such a service platform needs to provide support
for different communication protocols as well as
service descriptions. To support this requirement,
the service platform would provide a standard
communication interface which bridges the protocol
heterogeneity through the use of adapter. The
heterogeneity between service descriptions can be
handled by defining an intermediate description
language which can allows us to define mappings
without knowing the target description language.
The back-end information system infrastructure is
used to process the collected information and to
derive useful information or the composition of
services for the user.
In realizing all this, it is essential keeping full
consistency between:
(i) what is desired (from user perspective) and
(ii) what is delivered (from system perspective).
We find this example and the follow up discussion
as further justification of the claim that technology-
independent functionality models are to adequately
BRIDGE the gap between the two.
6 CONCLUSIONS
The contribution of this paper is two-fold:
(i) We establish and justify the role of
technology-independent functionality models,
especially with regard to the technical and
technological facilitation of (road) traffic.
(ii) Analyzing strengths and challenges
concerning IT services, we propose service-
oriented solution directions and provide
partial exemplification concerning our
proposed visions.
We plan to develop further these views,
elaborating them from a privacy/security
perspective. The reason is that, as according to our
view, without convincingly touching upon this, it
would not be possible to implement and deploy such
systems in at a larger scale.
REFERENCES
FIATS-M Home: http://www.fiats-m.org.
Shishkov, B.: Technology-Independent Functionality
Models for Road Traffic Systems. Proc.: FIATS-M’11
(2011).
Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web
Services, Concepts, Architectures and Applications.
Springer-Verlag, Berlin-Heidelberg (2004).
Van Sinderen, M.: Modeling Internet-Based Goal-
Oriented Enterprise Interoperability (Keynote
Lecture). Proc.: BMSD’12 (2012).
Papazoglou, M. P.: Web Services: Principles and
Technology. Pearson Pr. Hall (2008).
Sapkota, B. & M. Van Sinderen: Leveraging the Publish-
Find-Use Paradigm of SOA, Supporting Enterprise
Collaboration Across Organizational Boundaries.
Proc.: BMSD’11 (2011).
Sapkota, B.: An Adaptive Service Platform for Traffic
Management and Surveillance. Proc.: FIATS-M’11
(2011).
Business Models and Service Applications for Traffic Management
169