Towards Seamlessly Integrated Cyber-Physical Intelligent Transportation Systems of Systems

Abstract

The proliferation of mobile devices, wearables, and connected vehicles has resulted in many dynamic mobility applications that offer isolated and segregated services covering different needs of the transportation system such as advanced traveller information, smart parking management, and integrated dynamic transit services. A contemporary challenge in novel smart city initiatives is to amalgamate sensors, services, and city infrastructure into integrated intelligent transportation systems of systems where isolated applications are seamlessly combined to render integrated mobility services to stakeholders and end users. The integrated intelligent transportation systems of systems promise richer and more efficient interactions of distributed cyber-physical components that monitor and control regional transportation activities. In this paper, we discuss the notion of the cyber-physical intelligent transportation systems of systems highlighting their characteristics and fundamental research challenges. The paper also proposes a conceptual framework to help drive the design and implementation of such systems and demonstrates how this framework can be used to enable an integrated advanced traveller information system within the Greater Toronto Area.

Full text

ITS World Congress 2017 Montreal, October 29 – November 2
1
Paper ID #AM-SP0845
Towards Seamlessly Integrated Cyber-Physical Intelligent
Transportation Systems of Systems
Mohamed Elshenawy1*, Baher Abdulhai2, Mohamed El-Darieby3
1. Department of Civil Engineering, University of Toronto, Canada.
Email: mohamed.elshenawy@mail.utoronto.ca
Tel: +1 416-671-4810
2. Department of Civil Engineering, University of Toronto, Canada.
3. Software Systems Engineering, University of Regina.
Abstract
The proliferation of mobile devices, wearables, and connected vehicles has resulted in many dynamic
mobility applications that offer isolated and segregated services covering different needs of the
transportation system such as advanced traveller information, smart parking management, and integrated
dynamic transit services. A contemporary challenge in novel smart city initiatives is to amalgamate sensors,
services, and city infrastructure into integrated intelligent transportation systems of systems where isolated
applications are seamlessly combined to render integrated mobility services to stakeholders and end users.
The integrated intelligent transportation systems of systems promise richer and more efficient interactions
of distributed cyber-physical components that monitor and control regional transportation activities. In this
paper, we discuss the notion of the cyber-physical intelligent transportation systems of systems highlighting
their characteristics and fundamental research challenges. The paper also proposes a conceptual
framework to help drive the design and implementation of such systems and demonstrates how this
framework can be used to enable an integrated advanced traveller information system within the Greater
Toronto Area.
KEYWORDS:
Smart cities, Regional Transportation Applications, Cyber-Physical Systems
1- Introduction
Recent advancements in sensing, computation and communication technologies and the advent of cloud
computing and the Internet of Things (IoT) (1) have resulted in the emergence of a new paradigm of
comprehensive urban mobility applications that offer an efficient, extensible and cost-effective replacement
of traditional centralized infrastructure management approaches (2-4). These emerging applications are
characterized by an extensive number of physical devices (e.g. sensors, controllers, etc.) and cyber
components (e.g. web services) that are employed to monitor and manage city infrastructure. Examples of
these applications include cooperative decentralized traffic control (5-7), smart parking management
systems (8-10), applications to improve cyclists’ riding experience (11), applications to improve transit users’
experience (12), and mobility-as-a-service applications (13).
Unlike traditional standalone intelligent transportation systems (ITS) applications, which collect information
from a limited number of sensors deployed and maintained by individual agencies, modern and future ITS
applications embrace more adaptive data collection mechanisms that leverage the rich set of sensors
embedded in vehicles, passengers’ handheld devices, and infrastructure. According to the vision of the
Urban Internet of Thing (IoT) (1), these sensors will be accessible through a unified, interconnected
network. In such an environment, and due to the massive number of available sensors and cyber services,
there is an increasing need to design better coordination mechanisms that allow these fragmented
components to be integrated in intelligent transportation Systems of Systems (SoS) application that act
seamlessly to improve the utilization of existing transportation infrastructure. For instance, a multi-modal
regional traveller information system, which supports multiple categories of travellers, is an SoS application
that involves several provincial, municipal and possibly private agencies and integrates various data
sources, multiple communication media and multiple device types (in-vehicle, portable smartphones, etc.).
Another example is a regional incident and emergency management system that requires a wide
collaboration amongst different agencies, in real-time, to address public safety hazards promptly.
Seamless integration of dispersed ITS cyber-physical components to construct cyber-physical Intelligent
Transportation Systems of Systems (CP-ITSoS) increases the level of complexity of designing such

ITS World Congress 2017 Montreal, October 29 – November 2
2
applications, compared to traditional monolithic systems. Added requirements for managing enormous
amount of interactions among heterogeneous resources and the dynamic nature of the CP-ITSoS implies
that the behaviour of its constituent components shall vary according to the dynamics of the transportation
network and based on the requirements specified by its concerned stakeholders. Therefore, enabling such
system requires formal and consistent methods that manage complex interactions among sensors, city
processes, and city infrastructure while allowing transportation stakeholders to govern these interactions
and achieve their shared objectives.
This paper discusses the characteristics and implementation challenges of the CP-ITSoS applications and
proposes a conceptual framework to help drive the design and development of such applications. The
proposed framework defines three pillars to 1) coordinate and integrate dispersed cyber-physical
components; 2) provide higher order mashed ITS services, and 3) facilitate collaboration, coordination, and
knowledge sharing across different city stakeholders. The paper describes the operation of these pillars
using a demonstrating example that implements a regional Advanced Traveler Information System (ATIS)
within the Greater Toronto Area (GTA). The rest of the paper is organized as follows: Section 2 presents
the characteristics of a CP-ITSoS and its key functional requirements. Section 3 presents the fundamental
needs to construct and maintain collaborative ITS applications using the CP-ITSoS approach. Section 4
discusses the high-level components of the three-pillar framework and how these components interact to
support the dynamic provisioning of ITS applications. Section 5 demonstrates the applicability of the
framework by using it to enable a regional ATIS services within the GTA. Conclusions and future work are
summarized in Section 6.
2- Characteristics of A Cyber-Physical Intelligent Transportation System of Systems
The main thrust behind the development of a CP-ITSoS is the desire to achieve synergy among existing
cyber-physical components while avoiding the development of a large and complex monolithic system from
scratch. Large-scale monolithic systems require extensive resources to design and build and can therefore
be cost-prohibitive, not mention being hard to maintain, upgrade or extend over time. Therefore, the
implementation of a SoS requires some principle characteristics that distinguish their operation from large
monolithic systems. These characteristics are defined by Mark Maier (14), and they are suggested by other
several studies (15-17), to identify the foundational requirements for enabling such systems. The SoS
characteristics are:
1. Operational and Managerial Independence of the SoS elements, also referred to as autonomy (15),
which implies that constituent components shall exist to provide functionalities and deliver integrated
services independent of the SoS. In other words, constituent components shall be constructed and
maintained whether or not the SoS is developed. Boardman and Sauser (15) also suggest that
constituent elements should have the liberty to join or abandon the SoS at their discretion and on a
cost-benefit basis.
2. Evolutionary Development, which means that the development of a SoS shall evolve over time and
that the functionalities and key components of a SoS can be modified or extended according to the
requirements and experiences of concerned stakeholders.
3. Emergent, which indicates that a SoS shall enable functionalities that cannot be offered by any of its
constituent components.
4. Geographic Distribution, which implies that a SoS shall integrate distributed and decentralised
components.
Example: Using an ITSoS to Provide Regional Traveller Information Services
Consider, for the purpose of illustration, an ATIS that provides end-to-end real-time planning and monitoring
of multi-modal citizens’ travel itineraries in the context of a smart city. Such SoS relies on interacting cyber-
physical components that reflect the dynamics of urban transportation networks, their elements, and
surrounding environment. Figure 1 shows a possible scenario for an ATIS that can be provisioned according
to users’ contexts. The scenario is based on a detailed specification of the service defined by the Canadian
ITS architecture. The figure shows the different tasks of the provisioned system and the corresponding
information required to be provided to end users, as defined by the national ITS architecture for Canada.
The “Pre-Trip Travel Information” task, for example, requires informing travellers about several road
conditions’ elements such as incident, road construction, speeds, transit, and traffic data. Providing such

ITS World Congress 2017 Montreal, October 29 – November 2
3
information requires the interaction of several distributed SoS components, from different municipalities and
stakeholders, to provide real-time information about potential modes and routes according to users’
preferences.
Enabling the automatic provisioning of such SoS application requires:
1. A mechanism by which stakeholders can publish their distributed cyber-physical components and
declare their roles and interfaces. The mechanism shall support the independent operation and
maintenance of published cyber-physical components and shall enable their communication via a
reliable infrastructure;
2. A consistent methodology by which stakeholders can specify their common objectives, analyse
required tasks, and formulate their integrated operations. The methodology shall allow stakeholders
to add, remove, and adjust their design based on their experiences;
3. A mechanism by which the SoS can discover published cyber-physical components and combine them
according to the predefined functional requirements and execution rules, to deliver integrated services
that cannot be provided by any of the SoS’s constituent components alone.
3- The basic needs to achieve seamlessly Integrated ITS applications
According to the above discussion and the motivational example, one can identify the following three needs
to enable a seamlessly integrated CP-ITSoS:
1) The Need for Semantic Interoperability
Incompatible data models, data formats, communication protocols, and service implementation
technologies limit the intrinsic interoperability among the composed services and sensors and reduces the
end-to-end integrity of the shared information across the different applications and the outcomes of the
shared services. Such incompatibility mandates the development of common knowledge representation,
interoperability standards and implementation guidelines to ensure the portability of sensors and services
across the different platforms. ITS standards (18) and the ITS architecture (19) address the syntactical
aspects of interoperability by defining formal structures and communication protocols through which cyber-
physical entities can communicate and exchange data. Standards and the ITS architecture, however, do
not offer mechanisms to interpret the various interactions among the ITSoS objects, the meaning of the
shared data and information, and the role of these interactions in producing the final output of the ITSoS.
Therefore, there is a need to enable a higher level of semantic interoperability that allows the CP-ITSoS to
Traveller Information
Pre-Trip Travel
Information
En-Route Driver
Information
Route Guidance and
Navigation
Ride Matching And
Reservation Traveller Services
PTTI shall provide travellers with
Available Services Information on
travel, for their use.
PTTI shall provide the capability for
users to access the Current Situation
Information on transportation systems.
PTTI shall include a Trip Planning
Service.
Real-time information provided by PTTI
shall include the current status of any
accidents or incidents.
Real-time information provided by
PTTI shall include the current
condition of any road construction.
Real-time information provided by PTTI
shall include any currently
recommended alternate routes.
Real-time information provided by PTTI
shall include the current speeds on
specific routes.
Real-time information provided by
PTTI shall include current parking
conditions in key areas.
Figure 1 Route Guidance and Navigation in Advanced Traveller Information System

ITS World Congress 2017 Montreal, October 29 – November 2
4
interpret the relationships among interacting components automatically as will be discussed later in section
4.
2) The Need for Coordinated Planning
The lack of formal and consistent methods to describe rules, conditions, and operational procedures of
coordinated cyber-physical components hinders the ability of ITS stakeholders to define the specifications
of their integration plans. Consequently, coordinated planning remains an ad hoc process that lacks
integrity, consistency and coherence. Novel approaches to enable collaboration among ITS stakeholders
and allow them to specify their policies, functional models and restrictions in a uniform and precise manner
are necessary to construct CP-ITSoS coordinated operations.
3) The Need for Automatic Integration
The integration of legacy and modern ITS applications to form an CP-ITSoS poses the following challenges:
• Traditional municipal applications were developed with a focus on optimizing local assets within
individual municipality/ jurisdiction/ department. Thus, most of these applications adopt a stand-alone,
siloed architecture with limited capability to exchange information. Overcoming such limitation
requires a methodology by which stakeholders can expose their existing functionalities in a modular
and self-contained services that can be published, discovered, and combined in various ways.
• The lack of intelligent and autonomous mechanisms to automatically discover and select IoT sensors
and cloud services. The development of such mechanisms requires a unified framework to represent
the myriad types of data, applications, sensors, and services.
• The lack of intelligent and autonomous mechanisms to compose and coordinate selected sensors and
services, and integrate them into different smart mobility applications owned and managed by
municipal governments (jurisdictions), end users (e.g., city residents or operators), local businesses,
and media outlets. Composition algorithms mandate new coordination approaches in which data
collection and analysis procedures are standardized and jointly utilized by city stakeholders. They also
require a shared understating of the contextual information describing services, infrastructure
components, city operations, and city residents.
4- A Three-pillar framework for seamlessly Integrated cyber-physical ITSoS
Requirements Analysis
The development of the requirements for the framework was guided by the four principal characteristics of
a SoS, and the needs of semantic interoperability, coordinated planning, and automatic integration
discussed above. The framework involves the following structure of business entities and functionalities:
• ITS Application / Operation Providers: These business entities provide applications in response to
requests from end users such as travellers on the road, police officers, and traffic operators.
Application providers provide integrated ITSoS applications through stitching together sensors and
services, offered by the ITS service providers discussed below, that interact seamlessly to achieve
application providers’ goals. Examples of these providers include federal, regional and private
organizations which provide integrated ITS solutions to end users.
• ITS Service Providers: Service providers offer their software functionalities and IoT sensors via an
Everything-as-a-service paradigm (XaaS) (20) that allows them to publish and manage their service
offerings according to predefined service level agreements. Provided services and sensors shall
conform to the ITS architecture guidelines and the ITS communication standards to assure syntactical
interoperability among interacting ITSoS components. Examples of service providers include local
municipalities which manage local assets within their boundaries and private organizations which are
specialized in providing ITS-related services such as routing, fleet management and traffic
management.
The requirements of the framework, as depicted in Table 1, are categorized into the following three main
groups:
• Institutional Requirements, which define the role of the framework from ITS service and application
providers’ point of view. Institutional requirements define the capabilities required to assist ITS
stakeholders with the design and analysis of integrated ITSoS operations that achieve their
collaboration goals and objectives.
• Operational Requirements, which enable the execution of integrated and interoperable ITSoS
applications similar to the demonstrating example discussed in the previous section. Operational
requirements enable seamless and automatic integration of cyber-physical components to achieve
stakeholders’ goals while fulfilling the other non-functional requirements for ITSoS operations.

ITS World Congress 2017 Montreal, October 29 – November 2
5
• Communication Requirements, which define the functions of the framework needed to share
information successfully among interacting components.
Table 1 The Intelligent Transportation ITSoS Requirements
Institutional Requirements
1.1 - Formal definitions of shared concepts and relationships necessary to describe interoperable abstract ITS
processes and their specifications.
1.2 - A secure workspace that enables collaboration among involved stakeholders. Stakeholders need to
collaborate on defining work processes, share experiences and success stories, and build the consensus
needed to make decisions about collaborative operations.
1.3 - A consistent mechanism to specify scope, needs, functional requirements, interconnectivity, constraining
policies, and high-level operational scenarios of their integrated ITS operations.
1.4 - A consistent mechanism to adjust the behaviour of integrated ITS operations and to adapt successfully
to the changes in regional needs.
1.5 - A consistent mechanism to publish, advertise, and rate existing ITS functionalities in a way that makes
them interoperable with other components of the ITSoS.
Operational Requirements
2.1 - The framework shall define formally shared ITS components using standard terminologies and link these
components to their functional requirements as defined by the Canadian ITS Architecture.
2.2 - The framework shall adopt a decentralized architecture in which all the constituent ITSoS components
are managed and maintained independently from the ITSoS.
2.3 - The framework shall allow ITSoS system administrators to add, remove, or modify ITSoS processes when
needed.
2.4 - The framework shall formulate dynamically, using the abstract specifications of the ITS stakeholders,
integrated processes that respond properly to users’ requests or other triggering actions.
Communication Requirements
3.1 - The framework shall provide the messaging infrastructure required to share and distribute information
across distributed ITSoS components.
3.2 - The framework shall define a consistent method to invoke cyber-physical components, pass the required
input flows, and retrieve required output flows.
3.3 - The framework shall communicate the right information, at the right time, and in the right format suitable
for each cyber-physical component.
3.4 - The framework shall enable effective distribution of updated ITSoS contextual information among
interacting cyber-physical components.
An Overview of the Three-Pillar Framework
The three-pillar framework fulfills the institutional, operational and communication requirements, to realize
the envisioned ITSoS. The framework fulfills these requirements by defining three pillars of operation,
highlighted in Figure 2, to facilitate seamless collaboration amongst ITS service and application providers
to deliver integrated ITSoS operations. The first pillar constructs an ontology that captures the main
concepts and relationships within the ITSoS and serves as a common language to enable the semantic
interoperability amongst various interacting ITS cyber-physical components. The second pillar enables an
integrated service planning process in which various ITS application providers collaborate on defining the
needs, scope, key functional requirements, and interfaces required to build integrated plans that capture
their operational objectives. Constructed plans are then analyzed, using the integrated service execution
engine enabled by the third pillar, to select, orchestrate and invoke corresponding cyber-physical elements,
and produce the final designated output of the ITSoS operations. The following sections discuss an
overview of the framework highlighting the key modules and design principles. A detailed discussion of
these modules is beyond the scope of this paper.
Pillar One: Ontological Semantic Knowledge Representation (OSKR)
A key objective of the three-pillar framework is to enable semantic interoperability among ITS cyber-physical
components and allow these components to interact seamlessly within the SoS. Interoperability, according
to the Merriam-Webster Dictionary
1
, is defined as the “ability of a system to work with or use the parts or
equipment of another system”. The term is widely used in several engineering disciplines to refer to the
ability of two or more systems to communicate and share information using a common vocabulary. Although
1
http://www.merriam-webster.com/

ITS World Congress 2017 Montreal, October 29 – November 2
6
ITS standards and the ITS architecture define the protocols and data models required to support syntactic
interoperability within the ITSoS, supporting automatic coordination of cyber-physical resources requires a
higher level of semantic interoperability in which constituent components share a common understanding
of interacting modules, their roles, and their interfaces. The first pillar addresses semantic interoperability
by creating an ontological model that represents shared concepts and relationships within the ITSoS. The
model offers an abstraction layer, based on the Canadian ITS architecture, which formally describes the
nature of the various ITS cyber-physical components, their operations, and how these components can be
connected to achieve a common goal. Using the architecture as a basis to integrate ITS applications
achieves several benefits summarized by Hickman et al. (21) such as social acceptability, flexibility, guide-
ability, and comprehensiveness.
The ITSoS ontology reuses the Web Ontology Language for Services (OWL-S) (22), and Semantic Sensor
Network (SSN) (23), and Ontology of Transportation Networks (OTN)(24) to represent the ITS web services,
ITS sensors, and city infrastructural elements respectively. The selection of these ontologies was made
based on their abilities to satisfy requirements 1.1 and 2.1 identified earlier and according to the extensibility
Figure 2: Coordination Methodology
Figure 3: The Four Components of the ITSoS Ontology.

ITS World Congress 2017 Montreal, October 29 – November 2
7
of their design. A missing major component, however, is how to formally define abstract ITS processes that
link these objects together in an ITSoS, that is, requirement 1.2. The ontology for abstract ITS processes
(OITSP) provides such capability by offering an abstract layer that connects distributed and heterogeneous
cyber-physical components to facilitate their automatic coordination within an CP-ITSoS. By providing an
abstract description of the various services and sensors, the OITSP facilitates defining general coordination
plans that combines different cyber-physical components as discussed later in the following section. Figure
3 illustrates the four components of the ITSoS ontology.
Pillar Two: Integrated Service Planning (ISP)
The second pillar allows ITS application providers to collaborate on the design and analysis of abstract ITS
operations by defining a consistent methodology to describe general ITS process specifications such as
inputs, outputs, and execution order without worrying about the proper selection of sensors and services
that implement these processes. Stakeholders define a hierarchy of generic tasks, using the Hierarchical
Task Analysis (HTA) approach (25), which analyzes integrated SoS operations to their fundamental
standardized requirements as defined by the ITS architecture. For instance, a function such as providing
traveller information, discussed in the demonstrating example, can be decomposed into smaller services
such as pre-trip information, en-route driver information, route guidance and navigation, etc. These services
are then analyzed to their sub-components till the most primitive requirements (e.g. collect traffic data) are
obtained for each service. Hierarchical task analysis combined with the National ITS architecture satisfy
the ITSoS requirements 1.3, 1.4, and 2.3 by defining a consistent mechanism to analyze, define, and
execute SoS applications. The execution engine, the third pillar of the framework, uses these primitive
requirements to locate corresponding cyber-physical components.
The framework relies on the following two fundamental concepts to enable the ISP:
1) Virtual Organisations: A virtual organization consists of a set of ITS stakeholders who interact,
collaborate, and share resources to achieve a common objective through harnessing their collective
intelligence (26). The concept of virtual organizations achieves the institutional requirement 1.2 by
allowing ITS stakeholders to create temporary VO for business partnerships between multiple
interested parties and maintain the VO only for the required business duration before dissolving it.
Partnerships involve managing multiple SoS processes within or across organizations despite the
heterogeneity in their legacy software platforms and data models.
2) Hierarchical Task Networks: Hierarchical Task Networks (HTN) (27) is an Artificial Intelligence (AI)
planning technique that encodes the procedural knowledge about the domain of interest into a
hierarchy of abstract tasks and decomposing methods. The technique defines a set of conditions
and ordering constraints that control the decomposition of the different tasks, hence it satisfies the
operational requirement 2.4. The HTN starts with an initial state and an initial task that is required
to be implemented. The planning process decomposes the initial task analyzing it to its applicable
primitive actions (operators) that accomplish the goal of this task while satisfying the conditions and
constraints governing the operation.
Using the framework to plan an ITSoS operation involves the creation of a virtual organization between
interested ITS stakeholders to collaborate on the planning process. Involved ITS stakeholders use a set of
socio-technical tools, provided by the coordination framework, to collaborate on defining the interoperable
ITS operations identifying the key functional requirements, processes, standards and interfaces. These
requirements are then analyzed and organized into a hierarchy of tasks that can be executed by the
execution engine. Task networks describe, in an abstract format, the activities associated with each
operation, their conditions, constraints, and the context-related requirements for their executions.
Pillar Three: Integrated Service Execution (ISE)
The third pillar of the framework is an integrated service execution engine, which orchestrates the dynamic
execution of integrated SoS operations. Services are modular and self-contained software components
with an ability to advertise their capabilities via a set of well-defined interfaces that enable their interaction
with other SoS components. The ISE offers a management infrastructure to streamline the integrated
execution of ITSoS services by enabling several functionalities such as service discovery, selection,
monitoring, and invocation which achieve requirements 1.5 and 2.2. The management infrastructure acts
as a glue stitching together distributed cyber and physical components to facilitate the execution of adaptive
workflows that respond automatically to varying situational changes. The ISE pillar facilitates the automatic
execution of integrated SoS operations by performing the following functionalities: 1) provide data mapping
and transformation functionalities between different ITS cyber-physical modules in a way that achieve
communication requirements 3.2; 2) transmit and validate messages across ITSoS cyber-physical

ITS World Congress 2017 Montreal, October 29 – November 2
8
components using a shared messaging infrastructure that achieves the communication requirement 3.1; 3)
keep track of registered ITSoS constituent components and their characteristics via a service management
module; 4) annotate published services linking them to the ontological model; 5) enables the dynamic
execution of ITSoS operations by sharing relevant contextual information, such as levels of congestion,
visibility state, and weather-state, through a context management module that satisfy communication
requirement 3.4; and 6) orchestrate, via the composer module, the execution of ITSoS operations in
response to contextual changes and coordinate the messages between cyber-physical components
according to communication requirement 3.3. 7) offers a uniform access to the ITSoS functionalities via the
portal module. Figure 4 shows the main components of the execution engine.
5- A Prototype Implementation
A proof-of-concept prototype was implemented to show the applicability of the framework and to
demonstrate its feasibility. The prototype uses the ITSoS concepts and methodology to implement an ATIS
within the GTA. The ATIS use case was chosen because of its comprehensiveness yet relative simplicity
compared to other more complex ITS user service bundles such as Advanced Traffic Management Systems
(ATMS). While it may correctly be argued that existing services such as the one created by Google, for
instance, provide multi-modal ATIS, our framework and system are generic to ITSoS and aim beyond ATIS.
Our focus is on the development of the methodology and the creation of the initial platform, which is to
evolve and its functionalities to emerge in accordance to the spirit of the characteristics of the ITSoS
discussed earlier.
Integrated systems include three main components: 1) The Open Trip Planner (OTP)
2
, an open source
platform that provides multimodal trip planning services; 2) The Online Network-Enabled Intelligent
Transportation Systems (ONE-ITS) (28), a software platform developed by the University of Toronto that
offers real-time information about road networks; and 3) the NextBus
3
which provides real-time transit
information. These systems offer different services that implement different functional requirements that are
related to ATIS applications such as PlannerService, an OTP REST service that offers multimodal route
planning capbilities; IncidentListInqRq, an ONE-ITS SOAP service that collects planned and unplanned
incidents’ information using the MTO open data
4
published on the Ontario Government website; and
NextBusPredictionsService, a Next Bus service that provides predictions of the next bus arrival times at
2
http://www.opentripplanner.org
3
https://www.nextbus.com
4
https://www.ontario.ca/search/data-catalogue
Figure 4: A High-level Overview of the ISE Engine
Services
Sensors
Messaging Infrastructure
Data Mapping /Transformation
Service Management
Context Management
Composer
Ontological Model
Portal

ITS World Congress 2017 Montreal, October 29 – November 2
9
transit stops.
The steps to integrate these systems using the three-pillar framework can be summarized as follows:
1) Semantically represent constituent ATIS services
The first step of integrating the ATIS services mentioned above is to represent them semantically using the
ontological representation described in Section 4. Representation of the ATIS services in a machine-
understandable format using the ITSoS ontological model, the first pillar of the framework, allows their
automatic coordination by interpreting how these services are related to each other and how they are
related to the transportation infrastructure. Statements are triples of subjects, predicates, and objects.
Subjects can be either resources or anonymous entities (blank nodes) that are connected, via predicates,
to other resources or fixed values (such as decimals and strings) called objects. A predicate denotes the
name of a relationship or a property linking a subject and an object. For example, the following statement
states that sensor_A is linked to an object named RoadSpeed via a predicate observes:
Sensor_A observes RoadSpeed.
A knowledge graph is a set of statements where predicates act as edges connecting subjects and objects
(the nodes of the graph). Figure 5 shows an example of how the ITSoS ontological model represents
interacting services semantically. The knowledge statements indicate that the Planner service, an instance
of the OWL-S Service ontology class, implements a functional requirement defined by the Canadian ITS
architecture, which is to generate trips based on the use of more than one mode of transport. The service
defines, among others, fromPlace and toPlace as inputs and returns a set of possible itineraries as an
output. The knowledge statements also indicate that the service is associate with the Greater Toronto Area,
an instance of the OTN Feature ontology class.
Using these machine-understandable knowledge statements, it is possible to automatically interpret the
relationships among the different services, how they are related to the ITS architecture, and how they are
related to the transportation network. Similarly, ITSoS ontological model is used to represent ITS sensors
using the SSN ontology allowing the automatic interpretation of the measurements produced by these
sensors and how they are related to the execution of the ITS operations. The semantic model was created
and populated using Apache Jena, an open source Java framework. The model represents all the
standardized operations defined by the architecture which include 37 user services, 239 equipment
packages, 633 processes, 5784 data flows, and 559 architecture flows and use these operations to
semantically interlink distributed ITS services and sensors.
2) Integrated Service Planning
The prototype implements the abstract ITS hierarchy of tasks shown in Figure 6 which decomposes the
required ATIS process into the three main standardized ITS processes: “Infrastructure Provided Trip
Planner Service
GTAPlannerServiceProfile
presents
fromPlacetoPlace
hasInputhasInput
itineraries
hasOutput
The centre shall generate trips based on the
use of more than one mode of transport.
implementsFunctional
Requirement
InfrastructureProvidedTrip
Planning defines
GreaterTorontoArea associatedFeature
OWL-S EntitiesOTN Entities OITSP Entities
Figure 5: An example of Semantic Service Representation

ITS World Congress 2017 Montreal, October 29 – November 2
10
Planning”, “ISP Traveller Data Collection”, and “Personal Trip Planning and Route Guidance”. The network
defines one compound task, “ISP Traveller Data Collection” that collects traffic, emergency and transit data
according to the preferences defined by travellers and uses aggregated data to formulate the final response
of the ITSoS. The hierachy represents the output of the ISP pillar and it used by the ISE pillar to execute
the services.
3) Integrated Service Execution
The ITSoS composer employs the Hierarchical Task Networks (HTN) (27) algorithm to transforms the
abstract task networks discussed earlier into a sequence of actions that realize stakeholders’ objectives. A
key functionality of the ITSoS is the automatic discovery of services which uses a backtracking searching
algorithm to scan the knowledge statements discussed earlier and allocates available services that
implement the abstract functional requirements defined by the task network. The composer was
implemented as a service that accepts users’ requests in the form of the standardized ITS dataflow
trip_route_request and returns personal_traveller_information as an output. The execution engine relies on
the JBoss Enterprise Service Bus (JBoss ESB)
5
to provide the messaging infrastructure necessary to
enable such invocation. Each ITS service is wrapped as an ESB service that processes messages through
a series of predefined actions known as action pipeline. The pipeline performs data transformation, using
smooks
6
framework, to transform the inputs and outputs of each service into standardized data flows that
can be interpreted by the ITSoS. Input parameters such as origin, destination, and
constraint_on_number_of_transfers which are defined by the trip_route_request dataflow are mapped onto
fromPlace, toPlace, and maxTransfers which are used by the OTP planner service.
The ITSoS composer invokes ITSoS services, allocated by the discovery module, using the JBossESB
ServiceInvoker which handles the complexities involved in calling services by providing fail-over and
message resubmission capabilities. Services are invoked using the service name, service category, and
the message delivery mode (synchronous or asynchronous modes). Invocation messages are validated
and transformed using the action pipeline to convert them to the format that can be interpreted by the ITSoS
composer. ESB messages carry all the information required to invoke an ITS service such as addressing
information, input and output data objects, required service actions, security context, and any relevant
attachments. Table 2 shows an example query of the system in which the user specifies the origin,
destination and preferred mode. The ISE executes the planner service, which implement the “Provide
multimodal route selection” task, and use its output to obtain the recommended itinerary of the user. Based
on the user’s itinerary, the ISE discover and execute the other services that collect the information about
this route such as the traffic information service, incident inquiry, and NextBus services.
6- Conclusions and future work
This paprer discusses the concept of Cyber-Physical Intelligent Transportation Systems of Systems (CP-
ITSoS) as an approach to facilitate the design and implementation of regional, multimodal, and multi-
jurisdictional ITS applications by achieving the synergy among existing cyber-physical ITS components.
The paper presents a three-pillar framework to support the automated development of integrated ITSoS
applications. The framework facilitates the automatic coordination of dispersed ITS cyber-physical
5
http://jbossesb.jboss.org/
6
http://www.smooks.org/
Provide Traveller Information
Collect ISP Services
Data
provideInformationToTravellers
provideDynamicInfo
Provide Traveller with
Personal Travel Information
Provide Multimodal
Route Selection
Collect Transit
Operations Data
Collect Traffic
Data
Collect Emergency
Traveller Data
Figure 6: The Abstract ATIS Task Network

ITS World Congress 2017 Montreal, October 29 – November 2
11
components through three complementary pillars of operation that address the needs for semantic
interoperability, coordinated planning, and automatic integration. The paper discusses the institutional,
operational, and communication requirements of the proposed framework highlighting the functionalities of
its three pillars. The paper also shows the applicability of the framework using a prototype implementation
that uses the framework to enable a multimodal traveller information system within the GTA.
Current prototype implementation provides a foundation and skeleton for the development and delivery of
multi-stakeholder ITSoS. Possible use cases are numerous and can be any combination of services
defined by the Canadian ITS architecture. The prototype use case illustrates how multiple services, that are
developed and offered by dispersed stakeholders, can be integrated to provide a multi-modal ATIS to end
users. This implementation demonstrates the utility of the framework to enable the coordination of multiple
services by describing their abstract tasks and functionalities. Future work will focus on using the framework
to enable more complex scenarios that integrate larger scale number and types of sensors and services to
support more complex coordination scenarios such as regional traffic and emergency management
operations.
ACKNOWLEDGEMENTS
The authors would like to thank funding and support from CANARIE, Ontario Research Fund and the
Ministry of Transportation Ontario (MTO) without which this work was not possible.
References
1. Zanella, A., N. Bui, A. Castellani, L. Vangelista, and M. Zorzi. Internet of Things for Smart Cities. Internet
of Things Journal, IEEE, Vol. 1, No. 1, 2014, pp. 22-32.
2. Calabrese, F., L. Ferrari, and V. D. Blondel. Urban Sensing using Mobile Phone Network Data: A Survey
of Research. ACM Computing Surveys (CSUR), Vol. 47, No. 2, 2015, pp. 25.
3. Liu, N. Internet of Vehicles: Your Next Connection. Huawei WinWin, Vol. 11, 2011, pp. 23–28.
4. Lu, N., N. Cheng, N. Zhang, X. Shen, and J. W. Mark. Connected Vehicles: Solutions and Challenges.
Internet of Things Journal, IEEE, Vol. 1, No. 4, 2014, pp. 289–299.
5. Rezaee, K., B. Abdulhai, and H. Abdelgawad. Self-Learning Adaptive Ramp Metering: Analysis of Design
Parameters on a Test Case in Toronto, Canada. Transportation Research Record: Journal of the
Transportation Research Board, No. 2396, 2013, pp. 10-18.
6. Cooperative Control of Dynamical Systems with Application to Autonomous Vehicles.
Table 2 Testing the ATIS Application
Request
Composed ITSoS Services
origin =43.80257, -79.39476
destination =43.68674, -79.39991
mode=CAR_PARK,WALK,TRANSIT
Route (by the OTP planner service)
Executed Services:
PlannerService
GTATrafficInfoService
IncidentListInqRq
NextBusMessagesService
GTAStopsService
NextBusPredictionsService
Network Entities Used in
the Discovery Process
Bayview Avenue – South
Newton Drive – West
Conacher Drive- South
Northwood Drive-West
Maxome Avenu- South
Wedgewood Drive-West
Willowdale Avenue-South
TTC (Line 1)
Stop Id= “14111” (Finch
Station - Southbound
Platform)

ITS World Congress 2017 Montreal, October 29 – November 2
12
7. El-Tantawy, S., B. Abdulhai, and H. Abdelgawad. Multiagent Reinforcement Learning for Integrated
Network of Adaptive Traffic Signal Controllers (MARLIN-ATSC): Methodology and Large-Scale Application
on Downtown Toronto. IEEE Transactions on Intelligent Transportation Systems, Vol. 14, No. 3, 2013, pp.
1140-1150.
8. Mathur, S., T. Jin, N. Kasturirangan, J. Chandrasekaran, W. Xue, M. Gruteser, and W. Trappe. ParkNet:
Drive-by Sensing of Road-Side Parking Statistics. In Proceedings of the 8th International Conference on
Mobile Systems, Applications, and Services, ACM, New York, NY, USA, 2010, pp. 123–136.
9. Pierce, G., and D. Shoup. Getting the Prices Right: An Evaluation of Pricing Parking by Demand in San
Francisco. Journal of the American Planning Association, Vol. 79, No. 1, 2013, pp. 67–81.
10. The San Francisco Municipal Transportation Agency, (SFMTA). Parking Sensor Data Guide. Sept 4,.
http://sfpark.org, Accessed April 22, 2016.
11. Eisenman, S. B., E. Miluzzo, N. D. Lane, R. A. Peterson, G. Ahn, and A. T. Campbell. BikeNet: A Mobile
Sensing System for Cyclist Experience Mapping. ACM Trans. Sen. Netw., Vol. 6, No. 1, 2010, pp. 6:1–
6:39.
12. Zhou, P., Y. Zheng, and M. Li. How Long to Wait?: Predicting Bus Arrival Time with Mobile Phone
Based Participatory Sensing. In Proceedings of the 10th International Conference on Mobile Systems,
Applications, and Services, ACM, New York, NY, USA, 2012, pp. 379–392.
13. Sochor, J., H. Strömberg, and I. C. M. Karlsson. Implementing Mobility as a Service: Challenges in
Integrating User, Commercial, and Societal Perspectives. Transportation Research Record: Journal of the
Transportation Research Board, Vol. 2536, 2015, pp. 1-9.
14. Maier, M. W. Architecting Principles for Systems‐of‐systems. In INCOSE International Symposium,
Wiley Online Library, 1996, pp. 565-573.
15. Boardman, J., and B. Sauser. System of Systems-the Meaning of Of. In 2006 IEEE/SMC International
Conference on System of Systems Engineering, IEEE, 2006, pp. 6 pp.
16. Gorod, A., B. Sauser, and J. Boardman. System-of-Systems Engineering Management: A Review of
Modern History and a Path Forward. IEEE Systems Journal, Vol. 2, No. 4, 2008, pp. 484-499.
17. Madni, A. M., and M. Sievers. System of Systems Integration: Key Considerations and Challenges.
Systems Engineering, Vol. 17, No. 3, 2014, pp. 330-347.
18. U.S. Department of Transportaion. ITS Standards Program. http://www.standards.its.dot.gov/,
Accessed 20/02, 2013.
19. Transport Canada. ITS Architecture for Canada Version 2.0. https://www.tc.gc.ca/eng/innovation/its-
architecture.htm, Accessed April 10, 2016.
20. Banerjee, P., R. Friedrich, C. Bash, P. Goldsack, B. Huberman, J. Manley, C. Patel, P. Ranganathan,
and A. Veitch. Everything as a Service: Powering the New Information Economy. Computer, Vol. 44, No.
3, 2011, pp. 36-43.
21. Hickman, M., S. Weissenberger, and J. Dahlgren. Assessing the Benefits of a National ITS Architecture.
California Partners for Advanced Transit and Highways (PATH), 1996.
22. Martin, D., M. Paolucci, S. McIlraith, M. Burstein, D. McDermott, D. McGuinness, B. Parsia, T. Payne,
M. Sabou, M. Solanki, N. Srinivasan, and K. Sycara. Bringing Semantics to Web Services: The OWL-S
Approach. , 2004, pp. 26-42.
23. Compton, M., P. Barnaghi, L. Bermudez, R. García-Castro, O. Corcho, S. Cox, J. Graybeal, M.
Hauswirth, C. Henson, A. Herzog, V. Huang, K. Janowicz, W. D. Kelsey, D. Le Phuoc, L. Lefort, M. Leggieri,
H. Neuhaus, A. Nikolov, K. Page, A. Passant, A. Sheth, and K. Taylor. The SSN Ontology of the W3C
Semantic Sensor Network Incubator Group. Web Semantics: Science, Services and Agents on the World
Wide Web, Vol. 17, 2012, pp. 25-32.
24. Lorenz, B., H. J. Ohlbach, and L. Yang. Ontology of Transportation Networks. , 2005.
25. Annett, J. Hierarchical Task Analysis. Handbook of Cognitive Task Design, Vol. 2, 2003, pp. 17-35.
26. Pitt, J., A. Bourazeri, A. Nowak, M. Roszczynska-Kurasinska, A. Rychwalska, I. R. Santiago, M. L.
Sanchez, M. Florea, and M. Sanduleac. Transforming Big Data into Collective Awareness. Computer, Vol.
46, No. 6, 2013, pp. 40-45.
27. Ghallab, M., D. Nau, and P. Traverso. Automated Planning Theory and Practice. Elsevier, 2004.
28. Elshenawy, M., M. El-Darieby, and B. Abdulhai. A Cyber–Physical–Social Platform for Intelligent
Transportation Systems. , 2015, pp. 283-294.