A Three-Pillar Methodology and Framework for Seamlessly … · 2017-11-01 · ii A Three-Pillar...
193
A Three-Pillar Methodology and Framework for Seamlessly Integrated Cyber-Physical Intelligent Transportation System of Systems by Mohamed Mostafa Ata El shenawy A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy Department of Civil Engineering University of Toronto © Copyright by Mohamed Elshenawy 2017
Transcript of A Three-Pillar Methodology and Framework for Seamlessly … · 2017-11-01 · ii A Three-Pillar...
A Three-Pillar Methodology and Framework for Seamlessly Integrated Cyber-Physical Intelligent
Transportation System of Systems
by
Mohamed Mostafa Ata El shenawy
A thesis submitted in conformity with the requirements for the degree of Doctor of Philosophy
Department of Civil Engineering University of Toronto
© Copyright by Mohamed Elshenawy 2017
ii
A Three-Pillar Methodology and Framework for Seamlessly Integrated Cyber-Physical Intelligent
Transportation System of Systems
Mohamed Elshenawy
Doctor of Philosophy
Civil Engineering Department
University of Toronto
2017
Abstract
Novel smart city initiatives rely on information and communications technologies to manage
mobility in metropolitan areas. 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 systems such as advanced traveller
information, smart parking management, and integrated dynamic transit services. The majority of
these applications focus on solving a single problem; hence they offer limited support to provide
regional, multi-modal, and multi-jurisdictional services capable of meeting the rising expectations
of travellers. A contemporary challenge in intelligent transportation systems (ITS) is to
amalgamate sensors, services, and city infrastructure into an integrated intelligent transportation
system of systems where isolated applications are seamlessly combined to render integrated
mobility services to stakeholders and end users. The integrated system of systems provides a
unifying framework to support the dynamic formulation of regional ITS processes in response to
different situational changes.
This thesis proposes a three-pillar coordination and integration framework that supports day-to-
day intelligent transportation operations in smart cities in the context of Internet of Things (IoT).
iii
The first pillar of the framework is the Ontological Semantic Knowledge Representation (OSKR)
pillar, which provides a consistent and machine-understandable representation of coordinated
cyber-physical components using a four-tier ontological model of: (1) abstract ITS processes based
on the Canadian ITS Architecture, (2) web services, (3) ITS sensors and (4) transportation
infrastructure. The second pillar is the Integrated Service Planning (ISP) pillar which specifies,
based on the collaboration of stakeholders, the envisioned higher order intelligent transportation
operation and identifies its fundamental characteristics including scope, functionalities, and
interfaces. The third pillar of the framework is the real-time Integrated Service Execution (ISE)
pillar which enables the dynamic execution of abstract ITS tasks to ultimately provide integrated
higher order ITS services. The ISE pillar offers several functionalities to manage the heterogeneity
of shared cyber-physical components such as sharing contextual information, invoking services
and transforming messages. This thesis presents the three pillars of the framework and
demonstrates how these pillars can be used to enable the dynamic provisioning of advanced
traveller information services within the Greater Toronto Area.
iv
Acknowledgments
I would like to express my deepest gratitude to my supervisors Dr. Baher Abdulhai and Dr.
Mohamed El-Darieby for their guidance, encouragement, continuous support, and the profound
change they brought into my approach to life. I would also like to thank my committee members
for their insightful comments and valuable input: Professors Eric Miller, Mark Fox, and Ata Khan.
Pursuing a Ph.D. degree has been a life-changing journey for me, and I am grateful to the
wonderful individuals I have met and worked with during this journey.
Special thanks go to my colleagues Tamer Abdulazim, Toka Mostafa, Aya Aboudina, Islam
Kamel, Leila Dianat, Christopher Harding, Mehdi Nourinejad, and Soheil Shabestary who made
my time at UoT memorable. Also, I would like to thank Asmus Georgi for his help and support in
maintaining the ONE-ITS infrastructure; this work would not have been possible without his
valuable efforts. I am also grateful to the ONE-ITS development team; most notably Simon Xi and
Mohamed Abouelela for their contribution in developing the ONE-ITS portal.
Last but not the least, I would like to acknowledge the agencies which contributed to and supported
many of the research efforts conducted by the Toronto Intelligent Transportation Systems Centre
and Testbed at the University of Toronto. Special thanks go to CANARIE, Ontario Research Fund,
Ministry of Transportation Ontario, and the City of Toronto for their valuable contribution to this
research.
This thesis is dedicated to all the members of my family for their unconditional love and support
during happy and difficult times. I would like to thank my dad, Mostafa Elshenawy; my mom,
Amal Khalil; my sisters, Samar and Abir and my wife, Sarah Helal for everything they have done
for me.
v
Table of Contents
Acknowledgments .......................................................................................................................... iv
Table of Contents ............................................................................................................................ v
List of Tables ............................................................................................................................... viii
List of Examples ............................................................................................................................ ix
List of Figures ................................................................................................................................. x
Acronyms and Abbreviations ........................................................................................................ xi
1 Introduction ................................................................................................................................ 1
1.1 Research Problem ............................................................................................................... 4
1.1.1 Challenges of Achieving Seamless Integration in ITS Applications ...................... 6
1.2 Proposed Solution: A Framework to Support Seamless Coordination of Cyber-
Physical ITS ........................................................................................................................ 8
1.2.1 Pillar One: Ontological Semantic Knowledge Representation (OSKR) ................. 8
1.2.2 Pillar Two: Integrated Service Planning (ISP) ........................................................ 9
1.2.3 Pillar Three: Integrated Service Execution (ISE) ................................................... 9
1.2.4 Thesis Contributions ............................................................................................. 10
1.2.5 Assumptions .......................................................................................................... 10
1.3 Thesis Roadmap ................................................................................................................ 11
2 Literature Review ..................................................................................................................... 12
2.1 Interoperability .................................................................................................................. 15
2.2 Coordinated Planning ........................................................................................................ 16
2.3 Automatic Integration ....................................................................................................... 17
2.3.1 Integration of Cyber Entities ................................................................................. 17
2.3.2 Integration of physical entities .............................................................................. 22
3 Overview of the Three-Pillar Framework ................................................................................ 25
3.1 Characteristics of an ITSoS .............................................................................................. 25
vi
3.1.1 Demonstrating Example: Using an ITSoS to Provide Regional Traveller
Information Services ............................................................................................. 26
3.1.2 Requirements Analysis ......................................................................................... 28
3.2 Overview of the Three-Pillar Framework ......................................................................... 30
3.2.1 Pillar One: Ontological Semantic Knowledge Representation (OSKR) ............... 31
3.2.2 Pillar Two: Integrated Service Planning (ISP) ...................................................... 32
3.2.3 Pillar Three: Integrated Service Execution (ISE) ................................................. 33
4 Ontological Semantic Knowledge Representation (OSKR) .................................................... 36
4.1 Background ....................................................................................................................... 36
4.1.1 Resource Description Framework (RDF) ............................................................. 36
4.1.2 RDF Schema (RDFS) ........................................................................................... 37
4.1.3 The Web Ontology Language (OWL) .................................................................. 37
4.2 The ITSoS Ontology Development Methodology ............................................................ 38
4.3 ITSoS Ontology Objectives and Scope ............................................................................. 39
4.4 Competency Questions ..................................................................................................... 40
4.5 ITSoS Ontology Formalisation ......................................................................................... 42
4.5.1 An ontology for Abstract ITS Processes (OITSP) ................................................ 43
4.5.2 External Ontologies .............................................................................................. 46
4.6 ITSoS Ontologies Integration ........................................................................................... 52
4.7 Validating the ITSoS Ontology ........................................................................................ 55
Remarks on the Java Implementation of the ITSoS Model .............................................. 57
5 Integrated Service Planning (ISP) ............................................................................................ 58
5.1 Developing abstract ITS Applications Using the Coordination Framework .................... 58
5.1.1 Planning an ATIS application ............................................................................... 60
5.2 Implementation of the ITSoS Composer Module ............................................................. 65
5.2.1 The Hierarchical Task Networks Algorithm ......................................................... 66
5.2.2 Discovery Module ................................................................................................. 69
vii
5.2.3 Composing the ATIS services .............................................................................. 71
5.3 Computational Performance Evaluation ........................................................................... 76
6 Integrated Service Execution (ISE) .......................................................................................... 79
6.1 A High-level Overview of the ISE Engine ....................................................................... 79
6.2 Context Management ........................................................................................................ 81
6.2.1 Sensors’ Data Mapping ......................................................................................... 82
6.2.2 Context Annotation ............................................................................................... 84
6.3 Service Management ......................................................................................................... 87
6.3.1 Service Registry .................................................................................................... 87
6.3.2 Service Invocation ................................................................................................ 88
6.3.3 Message Validation ............................................................................................... 90
6.3.4 Other Functionalities ............................................................................................. 92
6.4 Service Portal .................................................................................................................... 92
6.5 Evaluation of the Coordination Framework ..................................................................... 94
6.5.1 Assessing the Framework Components against the ITSoS Requirements ........... 94
6.5.2 Implementation of a Culminating Proof-of-Concept ATIS Prototype ................. 96
7 Conclusions ............................................................................................................................ 103
7.1 Major Findings ................................................................................................................ 104
7.2 Research Contributions ................................................................................................... 106
7.3 Future Research .............................................................................................................. 107
References ................................................................................................................................... 109
Appendix A: Supplementary Information for Chapter 4 ............................................................ 124
Appendix B: Supplementary Information for Chapter 6 ............................................................ 159
Copyright Acknowledgements .................................................................................................... 181
viii
List of Tables
Table 3-1 The Intelligent Transportation SoS Requirements ....................................................... 28
Table 4-1 Sample SPARQL Query ............................................................................................... 56
Table 5-1 Key Services ................................................................................................................. 61
Table 5-2 Key Functional Requirements ...................................................................................... 62
Table 5-3 Interfaces ...................................................................................................................... 65
Table 5-4 ATIS Composition Using HTN .................................................................................... 73
Table 5-5 Testing the HTN Planning Algorithm .......................................................................... 77
Table 6-1 Framework Components versus the ITSoS Requirements ........................................... 95
Table 6-2 Key Services Used in the Proof-of-Concept Prototype Implementation ...................... 98
Table 6-3 Mapping the Inputs of the GTAPlannerService ........................................................... 98
Table 6-4 Mapping the Outputs of the GTAPlannerService ........................................................ 99
Table 6-5 Testing the ATIS Application .................................................................................... 101
ix
List of Examples
Example 6-1 Data Mapping/Transformation ................................................................................ 83
Example 6-2 JBossESB Service Definition ................................................................................. 89
Example 6-3 SOAP Request ......................................................................................................... 90
Example 6-4 Message Validation ................................................................................................. 91
x
List of Figures
Figure 3-1 Route Guidance and Navigation in Advanced Traveller Information System ........... 27
Figure 3-2 Coordination Methodology ......................................................................................... 31
Figure 4-1 The Four Components of the ITSoS Ontology. .......................................................... 42
Figure 4-2 Main Concepts of the Ontology for Abstract ITS Processes (OITSP) ........................ 44
Figure 4-3 Concepts Related to Virtual Organisations ................................................................. 46
Figure 4-4 Partial Representation of a Web Service ..................................................................... 48
Figure 4-5 Partial Representation of a Sensor .............................................................................. 49
Figure 4-6 Partial Representation of a Road Element .................................................................. 51
Figure 4-7 Partial Representation of a Transit Route ................................................................... 52
Figure 4-8 The Integrated Ontological Model .............................................................................. 53
Figure 4-9 A partial representation of a sensing service using the ITS-CPS ontological Model . 55
Figure 4-10 Knowledge Statements’ Frontend ............................................................................. 57
Figure 5-1 Development Process .................................................................................................. 58
Figure 5-2 ATIS Task Network .................................................................................................... 63
Figure 5-3 Performance Evaluation of the HTN-based Service Provisioning .............................. 78
Figure 5-4 Response Time as a Function of Discovery Variables ................................................ 78
Figure 6-1 A High-level Overview of the ISE Engine ................................................................. 80
Figure 6-2 An Annotation Example .............................................................................................. 85
Figure 6-3 On-board diagnostic (OBD) Units data ....................................................................... 86
Figure 6-4 A Sample ONE-ITS Portal Page ................................................................................. 93
xi
Acronyms and Abbreviations
AI Artificial Intelligence
APTS Advanced Public Transportation System
ATIS Advanced Traveller Information System
ATMS Advanced Traffic Management System
BPEL Business Process Execution Language
CBR Content-based routing
CoAP Constrained Application Protocol
COT City of Toronto
CVO Commercial Vehicles Operations
DL Description logics
DVP The Don Valley Parkway
ESB Enterprise Service Bus
GLOSA Green Light Optimized Speed Advisory
GTA Greater Toronto Area
GTHA Greater Toronto and Hamilton Area
GTFS General Transit Feed Specification
HTA Hierarchical Task Analysis
HTN Hierarchical Task Networks
ICT Information and communication technologies
IoS Internet of Services
IoT Internet of Thing
IRI Internationalized Resource Identifier
ISE Integrated Service Execution
ISP Integrated Service Planning
ITS Intelligent Transportation System
ITSoS Intelligent Transportation System of Systems
JMS Java Message Service
JSON JavaScript Object Notation
KB Knowledge Base
MQTT Message Queue Telemetry Transport
MTO Ministry of Transportation Ontario
NTCIP The National Transportation Communications for Intelligent Transportation
System Protocol
OASIS Organization for the Advancement of Structured Information Standards
OBD On-board diagnostic
OSKR Ontological Semantic Knowledge Representation
xii
OSM Open Street Map
OTN Ontology of Transportation Networks
OTP Open Trip Planner
PBF Protocol-buffer Binary Format
QEW Queen Elizabeth Way
QoC Quality of composition
QoS Quality of service
RDF Resource Description Framework
RDFS RDF Schema
REST Representational State Transfer
RFID Radio Frequency IDentification
RITIS Regional Integrated Transportation Information System
RPM Revolutions Per Minute
SOAP Simple Object Access Protocol
SoS System of Systems
SSN Semantic Sensor Network
TaaS Transportation as a Service
TMDD Traffic Management Data Dictionary
TTC Toronto Transit Commission
UDDI Universal Description, Discovery and Integration
WADL Web Application Description Language
WS-BPEL The Web Services Business Process Execution Language
WSDL Web Services Description Language
WSFL Web Services Flow Language
WSMO Web Service Modeling Ontology
XML eXtensible Markup Language
YRT York Region Transit
1
1 Introduction
The influence of information and communication technologies (ICT) on improving the efficiency
and effectiveness of city operations has increased significantly within the past few years. The
dramatically increasing rates of urbanisation (Dirks et al., 2010) and the need for more innovative
and integrated approaches to manage city resources have resulted in a wide variety of smart city
applications that augment elements of ICT to improve the efficiency, safety, and sustainability of
urban areas (Chourabi et al., 2012; Dobbs et al., 2013). Smart city applications support several city
services including transportation, public safety, healthcare, and waste management (Neirotti, De
Marco, Cagliano, Mangano, & Scorrano, 2014).
Among the many dimensions of a smart city, transportation is one of the most critical challenges
currently facing modern urban areas. Transportation provides mobility for people and goods and
is a significant factor in the economic growth and the national GDP. For example, the annual
costs of congestion to commuters in the Greater Toronto and Hamilton Area (GTHA) were
estimated, in 2008, at $3.3 billion (HDR Corporation, 2008). Overheads include increased travel
delays, increased vehicle operating costs, higher rates of vehicles’ emissions, increased rates of
accidents, and adverse economic impacts. Infrastructure solutions such as building new roads or
adding more lanes are expensive and time consuming. Moreover, such solutions are not always
feasible due to resource limitations and sustainability concerns. Therefore, smart cities’
applications are expected to play an influential role in improving the utilisation of existing
infrastructure under the overarching domain of Intelligent Transportation System (ITS) (F. Qu et
al., 2010).
Traditional ITS applications adopt stand-alone, centralised approaches where traffic information
is collected from a limited number of stationary field sensors (e.g. cameras and loop detectors) and
used to generate appropriate control actions to optimise local assets within the boundaries of each
municipality or jurisdiction. Locally managed assets and isolated decisions made by individual
agencies provide limited management capabilities to meet the ever-increasing transportation needs
of urban and metropolitan areas. Comprehensive ITS operations in larger metropolises often need
to cross the organizational boundaries where business processes enacted by different organizations
may interact.
2
Recent advancements in sensing, computation and communication technologies and the advent of
cloud computing and the Internet of Things (IoT) (Zanella et al., 2014) have resulted in the
emergence of a new paradigm of comprehensive urban dynamic mobility applications that offer
an efficient, extensible and cost-effective replacement of traditional centralised stand-alone
infrastructure management approaches. (Calabrese et al., 2015; N. Liu, 2011; Lu et al., 2014).
These emerging applications are characterised by an extensive number of physical devices (e.g.
sensors, controllers etc.) and cyber components (e.g. web services) employed to monitor, and
manage city infrastructure (Burke et al., 2006; Dobbs et al., 2013; S. Lee, Yigitcanlar, Han, &
Leem, 2008). Examples of these applications include infrastructure monitoring (Abdulazim et al.,
2013; Thiagarajan et al., 2009), cooperative decentralised traffic control (El-Tantawy et al., 2013;
Z. Qu et al., 2008; Rezaee et al., 2013), smart parking management systems (Mathur et al., 2010;
Pierce & Shoup, 2013; The San Francisco Municipal Transportation Agency, (SFMTA), 2013),
applications to improve cyclists’ riding experience (Eisenman et al., 2010), applications to improve
transit users’ experience (Zhou et al., 2012), and mobility-as-a-service applications (Sochor et al.,
2015).
A contemporary challenge to the ITS community is to amalgamate legacy and new ITS solutions
into an integrated intelligent transportation system of systems (ITSoS) capable of managing the
ever-increasing transportation needs more efficiently (J. M. Parker, 2010). Such integrated SoS
manages complex interactions among sensors, city processes, and city infrastructure to enable
isolated cyber-physical components to contribute to the integrated whole. For instance, a multi-
modal regional traveller information system, which supports multiple categories of travellers, is a
SoS that requires the involvement of several agencies (provincial, municipal and possibly private),
various data sources, multiple communication media and multiple device types (in-vehicle,
portable smartphones, etc.). Similarly, a regional incident and emergency management system
requires even wider collaboration, in real-time, amongst different agencies to address public safety
hazards promptly. Enabling such applications is limited due to many challenges including 1)
multiple incompatible systems owned and operated by various stakeholders, 2) heterogeneous data
sources, 3) managerial complexities, and 4) potentially competing objectives of the participating
organisations. These challenges inhibit larger, extensible, and possibly automated multi-
stakeholder collaboration.
3
Seamless integration of distributed ITS systems to create a more complex SoS requires a
comprehensive understanding of the various interacting ITS components at both the cyber and
physical levels including their role, their interfaces, and the type of information exchanged among
these components. The ITS architecture for Canada (Transport Canada, 2015) was developed to
support such integration by defining the information and communication requirements to create
interoperable regional ITS operations. Transportation authorities can use the architecture in
association with other software tools like the Turbo Architecture 1 to plan, define, and coordinate
their integrated ITS deployments. Architecture and related tools, however, do not specify a
systematic, flexible, extensible and automatable coordination methodology by which these
stakeholders can combine their existing ITS components and use them to compose higher-level
interoperable system of systems of ITS services that achieve their shared goals and objectives. As
a result, the majority of current coordination efforts occur on an ad-hoc and case-by-case basis.
This research presents a three-pillar framework to enable an ecosystem of interconnected cyber-
physical ITS sensors, services, and applications. The framework facilitates the formulation of SoS
intelligent transportation operations through three complementary pillars that address the
interoperability, integration and automation requirements for these operations. The first pillar is
the Ontological Semantic Knowledge Representation (OSKR) pillar, which provides a shared
conceptualization among collaborators by defining a reference ontological model and
computerised knowledge base, guided by the Canadian ITS architecture, that describe the key
concepts and relationships representing the various ITS operations. The second pillar is the
Integrated Service Planning (ISP) pillar, which allows stakeholders to define collaboration plans,
according to their cooperation objectives, to orchestrate the interactions among the different cyber
and physical components in response to certain situational changes. The third pillar is the
Integrated Service Execution (ISE) pillar, which automates the discovery and executions of series
of ITS services in hierarchical task networks and manages the heterogeneity of the interconnecting
components facilitating their interaction in a consistent and seamless manner. A prototype
implementation was developed as a proof-of-concept of the applicability of the framework linking
sensors, services and processes related to the advanced traveller information systems (ATIS)
within the Greater Toronto Area (GTA), Ontario. An ATIS use case was chosen because of its
1 http://www.iteris.com/itsarch/html/turbo/turbomain.htm
4
comprehensiveness yet relative simplicity compared to the more complex Advanced Traffic
Management Systems (ATMS) applications. The implementation of an ATIS focuses the research
effort on developing the methodology and the prototype platform which are the main targets of the
thesis. Multi-modal ATIS applications often cut across multiple organisations and jurisdictions
and require a variety of widely dispersed sensors and services and are hence suitable for the
research subject. Ongoing and future work, beyond the scope of this thesis, will generalise the
platform to wider transportation and ITS applications.
While it may be argued that existing services such as the one created by Google, for instance,
provide multi-modal ATIS, we aim beyond developing an ATIS or a single application as clarified
above. This research employs multiple ontologies for semantic knowledge representation of the
National ITS Architecture, multi-tier ITS services planning, automatic discovery and execution
using service decomposition and hierarchical task networks, all to furnish a methodology and
platform for ITSoS in a smart-city and Internet of Things (IoT) context. The ITSoS shall allow
other processes with other objectives to be added, removed, or modified and shall provide
functions that do not exist in any of its constituent components.
The rest of this chapter is organised as follows; Section 1.1 defines the research problem
illustrating the main difficulties hindering seamless integration of ITS components. Section 1.2
presents an overview of the three-pillar framework identifying its key assumptions. Section 1.3
illustrates the thesis structure and the relationships among its chapters.
1.1 Research Problem
ITS is an umbrella that includes several applications and user service bundles such as Advanced
Traffic Management System (ATMS), Advanced Traveller Information System (ATIS), Advanced
Public Transportation System (APTS), and Commercial Vehicles Operations (CVO). These user
service applications operate according to the following three-step model of actions:
(1) At the physical level, identify and acquire urban dynamics data required by city
applications from physical infrastructure sensors (Gubbi et al., 2013; Srivastava et al.,
2013), handheld devices, and from crowd-sourced devices (Campbell et al., 2008; Choujaa
& Dulay, 2010; W. Z. Khan et al., 2013).;
5
(2) At the cyber level, software components (referred to after this as services) transcend such
data in into contextual knowledge and situational awareness (Kostakos et al., 2009). One
expects a multitude of services (aka the Internet of Services (IoS)) enabling different
optimisations and translations of data collected; and
(3) Intelligently provision and deliver multi-stakeholder multi-jurisdictional smart city
applications to city citizens and system operators, and apply acquired knowledge to manage
and control the urban infrastructure.
A fundamental characteristic of cyber-physical ITS applications is their sensitivity to contextual
and situational changes in the surrounding environment. Hence, their architecture typically
involves components to acquire contextual information, characterise the current situation based on
collected information, and intelligently provision services based on the recognised states.
Integration of the cyber and physical entities of these applications, and due to the dynamicity of
the city, poses several challenges to the predictability of the system output, synchronisation of
system components, and the overall effectiveness of the system. Therefore, integration of ITS
applications has to rely on a unified model to collect, comprehend, and share contextual
information among the different applications.
Unlike traditional ITS applications, which collect information from a limited number of sensors
deployed and maintained by individual agencies, modern and future ITS applications aim to
improve the quantity and quality of sensing by embracing more adaptive data collection
mechanisms to 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) (Zanella
et al., 2014), these sensors will be accessible through a unified, interconnected network. In such
an environment, and due to the massive number of available sensors and services, manual selection
of the components suitable for a city operation is not feasible. Therefore, there is a need to design
better coordination schemes capable of performing the following tasks automatically (Perera et al.,
2014; Vermesan et al., 2011):
1) interpret the output data generated by various sensors or services;
2) provide rich streams of evidence, based on sensors’ data, to describe the contextual
situation of the different infrastructural elements;
6
3) share such contextual information among the various applications and platforms; and
4) facilitate seamless coordination of the various sensors and services based on the current
context.
The integration of cyber-physical components to construct an integrated ITSoS increases the level
of complexity, compared to monolithic systems, due to the added requirements for managing
complex interactions among heterogeneous resources. The integrated SoS should rely on
interoperability standards when communicating with any external entities to guarantee the
portability of their data collection, processing, and service rendering mechanisms. Furthermore,
the dynamic nature of the SoS implies that the behaviour of its constituent components varies
based on the changing requirements specified by concerned stakeholders to attain their goals.
Therefore, there is a necessity to define formal and consistent methods by which the stakeholders
can determine their objectives and integration requirements in a way that can be interpreted by the
SoS.
1.1.1 Challenges of Achieving Seamless Integration in ITS Applications
According to the above discussion, one can identify the following three needs to enable a
seamlessly integrated cyber-physical intelligent transportation SoS:
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 (U.S. Department
of Transportaion, ) and the ITS architecture address the syntactical aspects of interoperability by
defining formal structures and communication protocols through with 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
SoS.
7
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 SoS coordinated
operations.
3) The Need for Automatic Integration
The integration of legacy and modern ITS applications to form an integrated SoS poses the
following challenges:
Traditional municipal applications were developed with a focus on optimising 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. Such mechanisms enable automatic interpretation of the
data produced by each sensor or service, relationships among sensors, relationships among
sensors and transportation infrastructure, and interactions among physical and logical
components. The development of these 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 standardised
8
and jointly utilised by city stakeholders. They also require a shared understating of the
contextual information describing services, infrastructure components, city operations, and
city residents.
1.2 Proposed Solution: A Framework to Support Seamless Coordination of Cyber-Physical ITS
The objective of this research is to facilitate the development of interoperable operations among
transportation stakeholders by addressing the three needs of interoperability, coordinated planning,
and automatic integration discussed in the previous section. In particular, this work aims to provide
support for greater connectivity and integration of the various ITS sensors, services, and
applications, in which interoperable ITS operations can not only share data but also share
contextual information, functionalities, and processes. The major contribution of this thesis is a
three-pillar framework that merges dispersed ITS cyber-physical components into a seamlessly
integrated SoS that simplifies the process of constructing and maintaining collaborative ITS
applications. Rather than building complex and expensive mega systems, the framework allows
distributed ITS cyber-physical components to act as an integrated whole, hence enhancing the
flexibility and efficiency of creating interoperable and extensible ITS processes. The framework
has the following three pillars of operation:
1.2.1 Pillar One: Ontological Semantic Knowledge Representation (OSKR)
The Ontological Semantic Knowledge Representation (OSKR) pillar offers a shared basis of
conceptual understanding among stakeholders enabling them to avoid terminological confusions
while planning for their coordinated operations. The framework utilises a four-tier ontological
model that formally represents 1) abstract ITS processes based on the Canadian ITS Architecture,
2) ITS sensors, 3) web services, and 4) transportation network, to act as a common language that
describes the various SoS components. The model defines the interfaces of the constituent cyber-
physical components, their relationships, how they relate to city infrastructural elements, and their
role in the SoS processes. Examples of the questions answered by the model include: What are the
required ITS processes to respond to different situations? What goals is each process trying to
accomplish? What are the physical ITS components (e.g. sensors, control devices) required to
support an individual operation? What are the required ITS standards to support an ITS action?
9
What components does an organisation need to deploy to provide or improve a specified service
or process?
1.2.2 Pillar Two: Integrated Service Planning (ISP)
The Integrated Service Planning (ISP) pillar allows transportation stakeholders to collaboratively
define abstract ITS operations that combine different elements of the OSKR to orchestrate the
interactions among the different cyber-physical ITS components. The framework employs the
Hierarchical Task Networks (HTN) planning algorithm (Ghallab et al., 2004) which organises ITS
operations into hierarchies of tasks, referred to as task networks, that achieves a set of
collaborators’ goals. Collaborators create these task networks using abstract ITS processes,
represented by the OSKR, and use them to coordinate the interactions of the different cyber-
physical components in response to various situational changes. These plans are then used by the
framework to enable the integrated provisioning of the ITS services. An incident identification
abstract plan, for instance, can be decomposed to different subtasks such as collect traffic sensors’
data, process traffic data, and classify possible incidents. These tasks define several functional
requirements that should be implemented to satisfy the main goal of the operation.
1.2.3 Pillar Three: Integrated Service Execution (ISE)
The Integrated Service Execution (ISE) pillar enables, based on the task networks specified by the
ISP, the execution of the ITS operations to achieve stakeholders’ designated requirements. The
ISE provides a uniform means to discover, compose, monitor, and interact with a wide variety of
heterogeneous ITS sensors and services shared by ITS stakeholders. The framework relies on the
ISE pillar to support dynamic provisioning of ITS operations facilitating the communication
among the different cyber-physical components. Moreover, the ISE engine keeps track of running
ITS processes, their execution states, and the data associated with each process. Functionalities
offered by the ISE include service registry, service discovery, service invocation, service
composition, messaging infrastructure, and transaction management. For example, the ISE
executes the incident identification plan discussed above by 1) analysing the hierarchy of tasks to
select the first action, collect traffic data; 2) discover the service or services that implement this
action and retrieve required traffic information; 3) execute this service producing the output
required to continue running the operation; and 4) analyse the rest of the plan till all the other tasks,
process traffic data and classify possible incidents, are executed.
10
1.2.4 Thesis Contributions
The main contributions of this thesis are:
A three-pillar framework to support the development of ITSoS applications. The
framework creates a machine-understandable graph of semantically interlinked sensors,
services, and city infrastructure entities and provides tools to stitch on-the-fly
heterogeneous ITS sensors and services to dynamically execute intelligent transportation
SoS operations. The framework hides many of the underlying complexities typically
associated with the formulation of interoperable ITS processes such as message
transformation, proper selection of sensors and services, data interpretation, sharing
situational information, etc.
A four-tier ontology model that formally represents the various relationships within an
ITSoS. The thesis discusses the development of the ontology and highlights the concepts,
properties, and relationships used to characterise the different entities within the domain of
interest.
An integrated service execution engine (Elshenawy et al., 2015a; Elshenawy et al., 2015b)
that implements the key functionalities of the ISE pillar of the framework such as service
registry, service invocation, message transformation, and context management.
A prototype implementation to demonstrate the applicability of the framework. The
prototype employs the framework to services implement an advanced traveller information
SoS application within the Greater Toronto Area (GTA), Ontario.
1.2.5 Assumptions
The thesis assumes that ITS providers shall define their services, data types, and data flow
following the principles of the Canadian ITS architecture and that all services can be
described using WSDL, WADL or OWL-S languages. The thesis also assumes that
services’ and sensors’ communications are compliant or can be translated to the common
ITS standards’ specifications such as the National Transportation Communications for
Intelligent Transportation System Protocol (NTCIP) or IEEE 1512.
11
The thesis assumes that only interactions among cyber and physical components are
required to produce the output of the composite process. The thesis also assumes that all
services and applications are: a) implemented securely to prevent unauthorised or insecure
access to the service or the sensor; b) designed to cope with variances in the latency of the
different communication media and c) apply appropriate fault tolerance mechanisms to
handle unexpected failures.
1.3 Thesis Roadmap
Based on the above discussion, the thesis has been organised into the following chapters after the
introduction chapter:
Chapter 2 summarises the literature review of the state-of-the-art approaches addressing
interoperability and seamless integration of intelligent transportation systems. It also highlights
the key challenges and limitations in existing state-of-the-practice literature.
Chapter 3 presents the high-level components of the three-pillar framework and how these
components interact to support the dynamic provisioning of ITS applications.
Chapter 4 details the description of the ontological model and how the model can be employed to
create a graph of semantically interlinked ITS components.
Chapter 5 illustrates the process of formulating collaborative ITS processes using the example of
Advanced Traveller Information System (ATIS). The chapter demonstrates how stakeholders can
use the processes and functional requirements defined by the architecture to construct a
hierarchical task network governing the execution of the ITS operation.
Chapter 6 discusses the high-level design and operational aspects of the ISE pillar. The chapter
discusses the implementation of the Online Network Enabled Intelligent Transpiration System
(ONE-ITS) which acts as a single point of entry to the shared resources accessed by the
infrastructure.
Chapter 7 concludes the thesis with summarising the significant contributions and findings of the
thesis and listing possible future directions to improve the capabilities of the presented framework.
12
2 Literature Review
ITS applications have been employed by many transportation agencies and jurisdictions to provide
a better management of their resources and infrastructure. COMPASS2, for instance, is a freeway
traffic management system, developed by the Ministry of Transportation Ontario (MTO), to
manage incidents, traffic delays, and traffic congestion along the provincially maintained
highways such as 401, 400, and Queen Elizabeth Way (QEW). Information gathered from closed
circuit television cameras and vehicle detectors is sent to one or more traffic operations centres,
using fibre optic communication network, where it is analysed to produce traffic control signals.
Other examples include RESCUE3 in the City of Toronto, Houston TranStar4, Los Angeles
Regional Transportation Management Centre (LARTMC)5, and The Rhode Island Transportation
Management Centre6, to name a few.
Advances in sensing, computing, and communication technologies have resulted in a new wave of
ITS applications that augment cyber-physical elements to improve monitoring and management
of urban transportation systems. CarTel (Hull et al., 2006), an example of these applications,
employs a distributed mobile sensor computing system to gather, process, and visualise a range of
traffic and vehicular data such as traffic speeds, traffic delays, automotive diagnostic data, and
images from attached cameras. CarTel uses collected traffic data to infer situational information
about travel times, congested road elements, fuel consumption, and driving patterns. Another
example is Nericell (Mohan et al., 2008) which exploits smartphones’ sensors such as GPS,
accelerometer, and microphone to detect braking events, stop-and-go traffic, road bumps, and honk
sounds. Such information is useful to infer information about chaotic traffic conditions, drive
quality, and road conditions. Other examples include Waze7, VTrack (Thiagarajan et al., 2009),
2 http://www.mto.gov.on.ca/english/traveller/trip/compass.shtml
3 http://www.toronto.ca/rescu/
4 http://traffic.houstontranstar.org/
5 http://www.dot.ca.gov/dist07/travel/lartmc/
6 http://www.dot.ri.gov/travel/
7 https://www.waze.com/
13
Mobile Millennium (Bayen & Patire, 2011), and Inrix8 which use mobile phones to provide real-
time and predictive information about road conditions.
Another sub-domain of novel ITS applications is the cooperative decentralised traffic control (El-
Tantawy et al., 2013; Leontiadis et al., 2011; Z. Qu et al., 2008) which aims to optimise the
performance of traffic signals by coordinating their controllers. The Green Light Optimized Speed
Advisory (GLOSA) system, for instance, seeks to alleviate traffic congestion by reducing vehicles’
average stopping time at signalised intersection. GLOSA leverages Infrastructure-to-Vehicle (I2V)
communications channels to help drivers decrease their waiting times at intersections by providing
them with real-time messages about current traffic lights’ locations, traffic lights’ cycles intervals,
and recommended speeds. Another example is SignalGuru (Koukoumidis et al., 2012) which
utilises the cameras of windshield-mounted smartphones to detect the cycles of pre-timed and
adaptive traffic signals. Other studies (Dresner & Stone, 2008; Lee & Park, 2012) investigate the
coordination of autonomous and connected vehicles at intersections to avoid collisions, reduce
total travel time, and improve the overall performance of the network.
ParkNet (Mathur et al., 2010) utilises GPS traces and mobile sensing from over 500 taxicabs in
San Francisco to provide hourly-basis statistics about the utilisation of road-side parking spaces in
the downtown area. The information is valuable for parking management and parking enforcement
authorities to help them make better-informed decisions about the availability of parking spots and
possible locations of infringing vehicles. The authors showed that 536 vehicles equipped with
adequate sensing devices were sufficient to cover around 85% of the parking spaces in the
downtown area with average sampling intervals of 25 min. Another smart parking application is
ParkSense (Nawaz et al., 2013) which utilises smartphones and Wi-Fi access points to sense un-
parking situations by detecting drivers while returning to their parked vehicles. These applications
cover wider areas at a relatively lower cost compared to systems that rely on a limited number of
stationary sensors.
Other ITS applications include services to improve biking experiences (Eisenman et al., 2010;
Reddy et al., 2010) by sensing and sharing information about cyclists’ routes. BikeNet (Eisenman
et al., 2010), for instance, uses pedal sensors, tilt sensors, wheel sensors, metal sensors, sound
8 http://www.inrix.com/mobile.asp
14
sensors, and CO2 sensors to infer information about average speed, pedalling cadence, route
roughness, passing vehicles, noise, and level of carbon dioxide. ITS applications also include
services to improve transit riders’ experience such as NextBus (Schmier & Freda, 2002) which
uses GPS sensors located on transit vehicles to notify users of expected bus arrival time at each
transit stop. While NextBus relies on transit agencies to install and maintain the sensors, people-
centric approaches such as the one proposed by Zhou et al. (Zhou et al., 2012) uses passengers’
mobile phones to monitor transit routes and to estimate bus arrival time.
Real-time information collected from mobile and stationary sensors are typically used to provide
customised mobility services to citizens. Opportunity Knocks (Patterson et al., 2004), for instance,
uses real-time buses information and detected users’ travel patterns to alert passengers with
cognitive disabilities about certain situations like boarding a wrong bus. Another example is
OneBusAway (Ferris et al., 2009; Ferris et al., 2010), which leverages iPhone localisation
framework to provision customised and real-time information about transit routes. Path2Go
(Liping Zhang et al., 2011) provides personalised multimodal traveller information by using users’
current location, users’ detected activities, real-time bus information, locations of transit stations,
and trip itineraries. Other contextual information such as time-of-the-day, day-of-week, and
historical traffic conditions are used in (Letchner et al., 2009) to recommend routes based on users’
preferences. The mobility-as-a-service approach, presented in (Sochor et al., 2014; Sochor et al.,
2015), offers a set of customised multimodal transportation services such as carpooling, public
transit, car rental, and bike sharing based on citizens’ monthly subscriptions.
The majority of emerging ITS applications, as in the examples described above, rely on: 1)
acquiring large amounts of real-time urban informatics provided by interconnected sensors,
wearable devices, and smartphones (aka Internet of Thing (IoT)); 2) transcending acquired
information into knowledge and awareness of situational and contextual city dynamics; 3)
application of the acquired situational and contextual knowledge to intelligently deliver city
complex services (services that consume data, information and subservices from a multitude of
dispersed sources). Therefore, integration of multiple applications to form a more complex,
seamlessly integrated intelligent transportation SoS (ITSoS) capable of performing regional,
multimodal, multi-stakeholder and multi-jurisdiction ITS operations is highly desirable. Such
integration, however, poses several operational challenges that have been subjects of several
research studies within the past few years. This chapter focuses on the three key needs identified
15
in Chapter 1 which are interoperability, coordinated planning and automatic integration of cyber-
physical components.
2.1 Interoperability
To enable intrinsic interoperability among ITS sensors and services and to overcome the
limitations of incompatible data models and communication protocols, it is critical to rely on a set
of robust, well-developed standards. Standards allow ITS devices and applications to be portable,
in other words, devices can work and communicate effectively in a plug-and-play fashion. Besides,
using standards ensures consistency and compatibility, improves competitiveness in ITS products
market, and reduces training and maintenance costs. Therefore, the U.S. Department of
Transportation (USDOT) established the ITS Standards Program9 to support the development of
open ITS standards. Approximately 100 standards were developed defining messages and
information sharing protocols across ITS entities.
Standards are logically grouped into two categories; ITS Cooperative System Standards and ITS
Infrastructure Standards (Steve Sill et al., 2011). Cooperative System Standards define standards
related to the operation of connected vehicles such as IEEE 802.11p, IEEE 1609.x and SAE J2735.
Infrastructure Standards, on the other hands, are more related to infrastructure components such
as management centres, field devices, and controllers. Examples of the infrastructure standards
include NTCIP family of standards for Centre-to-Centre (C2C) and Centre-to-Field (C2F)
communications and APTA TCIP for transit communications. Other ITS standards include SAE
J2354 for advanced traveller information system (ATIS), ASTM E2665 for Archiving ITS-
Generated Traffic Monitoring Data, and IEEE 1512 standards for sharing information during
traffic incident response.
Recently, many efforts have focused on using ITS standards and web services to enable
collaboration and coordination among ITS applications. The Regional Integrated Transportation
Information System (RITIS) (Pack et al., 2008) is an example of such platforms. RITIS aims to
automate the processes of data sharing, dissemination, and archiving of traffic management data
in Virginia, Maryland, and Washington D.C. The system utilises eXtensible Markup Language
(XML), Traffic Management Data Dictionary (TMDD) and ATIS standards for sharing of regional
9 https://www.standards.its.dot.gov/
16
traffic data and traveller information. Another example is TRAC-IT (S. Barbeau et al., 2009),
which utilises web services to collect high-resolution travel behaviour information using GPS-
enabled phones. SOAP services and NTCIP are used by (Xin et al., 2010) to generate real-time
optimised signal plans to control the traffic along two arterials in New York City. Other examples
include using the web services to enable real-time incident information dissemination (Y. Wu et
al., 2011), high-resolution travel behaviour data collection (S. Barbeau et al., 2009), real-time
optimised signal control (Xin et al., 2010), and personalized information provision (S. J. Barbeau
et al., 2010).
InterCAD (S. Parker et al., 2012) is another example of a successful implementation of real-time,
standardised systems. InterCAD utilises web services and the IEEE 1512 standard to support
sharing of incident information among public safety organisations and traffic operators. IRSV (S.
Chen et al., 2010) adopts a service-oriented architecture to integrate bridges’ data from different
locations. Collected data is used to identify trends, analyse patterns and monitor bridges over time.
Web services have also been used in transit systems to enable transit trip planning based on real-
time information (Jariyasunant et al., 2010) and to provide users with personalised information
about their preferred routes (S. J. Barbeau et al., 2010). Another example is the LUTE framework
(Ferreira et al., 2010), which utilises the concepts of open GIS standards, service-oriented
architecture, and distributed geoprocessing services to enable information sharing and efficient
collaboration on land use, transportation, and environmental research.
Despite these efforts, interoperability of ITS products is still a challenging task. Institutional
barriers and the lack of efficient mechanisms to coordinate and manage physical/logical resources
in an autonomous manner limit the efficiency of many ITS deployments (Chourabi et al., 2012).
ITS standards define several data dictionaries that enable sharing information efficiently among
various ITS components. A missing foundational piece, however, is to formally represent these
components and their interactions in a way that allows automatic interpretation of their exchanged
information and functions, and hence, enables their automatic integration.
2.2 Coordinated Planning
National ITS architectures such as the ITS architecture for Canada (Transport Canada, 2015) were
introduced by Transport Canada to provide a common framework that guide the coordinated
planning and deployment of ITS systems nationwide. The main components of the architecture
17
are: 1) user services, which describe the role of the system from the user’s perspective; 2) logical
architecture, which defines the processes (activities or functions) that are required to satisfy the
user services and data flows exchanged among these processes; 3) physical architecture, which
defines the devices, actuators and subsystems that implement the logical processes; and 4) service
packages, which represent slices of the physical architecture that address specific ITS services
such as surface street control for instance.
The architecture defines thirty-seven user services and 101 service packages covering nearly all
the functionalities of ITS products such as traveller information, traffic management, public
transportation management, electronic payment, commercial vehicle operations, and emergency
management. These packages provide an excellent reference model describing the physical
architecture (field devices, controllers, management centres, etc.) and the logical architecture
(processes and information flows). The knowledge acquired by the architecture, however, is not
encoded in formal, machine-understandable format, and hence, it is not feasible to use the
architecture for automatic coordination of ITS cyber-physical entities. Furthermore, the
architecture does not suggest a method of analysing and realising the structure of interoperable
operations in terms of the goals, sub-goals, interfaces, key procedures required to attain the
designated goals, dependencies and inter-relationships among the key procedures and final outputs
of the operation.
2.3 Automatic Integration
2.3.1 Integration of Cyber Entities
Service Oriented Architecture SOA (Papazoglou et al., 2007; Weerawarana et al., 2005) is an
architectural pattern that allows stakeholders to expose and consume software functionalities in
the form of loosely coupled, self-described, and highly portable web services that can be accessed
via the internet. Hence, SOA provides a solution to many of the limitations of traditional
monolithic ITS systems. SOA relies on a stack of well-developed industry standards such as
Simple Object Access Protocol (SOAP), REST (Representational State Transfer), Web Services
Description Language (WSDL), Web Application Description Language (WADL) and Universal
Description, Discovery and Integration (UDDI) to provide interoperability and exchange
information among service providers in a decentralised, modular fashion.
18
The power of SOA lies in its ability to organise the execution of services into business workflows
providing means to build composite applications. Within business workflows, coordination among
web services is typically achieved via orchestration and choreography patterns (Peltz, 2003).
Orchestration refers to the control of a business process from a single party’s perspective, including
execution order, interaction among services, and business logic. Choreography, on the other hand,
describes the coordination among services from a global perspective including public message
exchange, rules of interaction, and collaboration protocols.
The Web Services Business Process Execution Language (WS-BPEL) (Weske, 2012) or in short
BPEL is an XML-based specification for describing the control actions required to achieve
orchestration among participating services. The standard was originally a conglomerate between
XLANG by Microsoft and Web Services Flow Language (WSFL) by IBM and was known as
BPEL4WS. In May 2003, version 1.1 was released and submitted to the Organization for the
Advancement of Structured Information Standards (OASIS) as a joint effort by Microsoft, IBM,
Siebel Systems, BEA, and SAP. Currently, the standard is well recognised in software
development, and many of the commercially available orchestration engines are supporting it.
Interactions among choreographically coordinated web services, on the other hand, is usually
described via the Web Services Choreography Description Language (WS-CDL)10 which defines,
from a neutral perspective, the observable behaviour, roles, and order of exchanged messages
without exposing the actual implementation of the services involved in the collaboration. The
standard is developed and supported by The World Wide Web Consortium (W3C).
2.3.1.1 Semantic Web Services
A crucial challenge in existing SOA implementations is to enable automatic services discovery
and composition with minimal user involvement (Papazoglou et al., 2007). Web services’
description languages are limited to syntactic specifications which hinder their ability to support
automatic service discovery, composition, and management (Benatallah et al., 2005; Casati &
Shan, 2001; S. A. McIlraith et al., 2001). Early attempts tried to address this limitation by using a
customised, non-standardized semantic layer on top of a service’s WSDL description to describe
the relationships among services in a machine-understandable manner. Medjahed et al. (Medjahed
10
https://www.w3.org/TR/ws-cdl-10/
19
et al., 2003), for instance, suggests a rule-based model to provide customised e-government
services to indigent citizens. Their platform consists of four main phases: In the first step, an XML-
based language called CSSL, defined by the authors, is used to provide a high-level specification
of the composite services. Composite services specifications are then fed to the next phase where
the corresponding composition plans are generated based on a matchmaking algorithm and
according to a set of selection rules. These plans are then sorted according to their quality of
composition (QoC) and sent to the last stage where a complete description of the composite plan
is produced. Another example is eFlow (Casati et al., 2000) which defines a framework to support
constructing dynamic workflows in highly dynamic environments. In eFlow, processes are
described using selection rules instead of actual services. When a service node starts, eFlow engine
invokes a service broker to execute the service selection rules and return appropriate services. By
separating service selection from process definition, services can be dynamically chosen based on
their availability and according to customer’s preferences.
The Web Ontology Language for Services OWL-S (Martin et al., 2007) was introduced to provide
general semantic specifications of web services defining their inputs, outputs, interdependencies,
and operations in a machine understandable manner. In OWL-S, knowledge about services is
divided into three main components; Service Profile, Service Model, and Service Grounding.
Service profile provides a high-level description of the service including its category, inputs,
outputs, preconditions, and effects. Information offered by the service model describes how the
service can be combined with other services to achieve certain goals. Composite services are
modelled as processes with predefined participants, process inputs, process outputs, preconditions,
and effects. OWL-S distinguishes three types of processes: atomic processes, which correspond
to actual services that can be invoked directly without further processing; simple processes, which
offer an abstraction mechanism to represent many processes that perform the same functionality;
and composite processes, which represent decomposable processes that describe an execution path
of one or more sub-processes. Service grounding provides information on how to access the service
including protocols, messages formats, addressing, etc.
The Web Service Modeling Ontology (WSMO) (Roman et al., 2005) is another meta-model to
describe semantic web services. The model introduces additional concepts such as ontologies and
mediators to facilitate integration with external ontologies. Furthermore, the model presents a set
of non-functional properties to describe the quality of service (QoS) attributes such as trust,
20
accuracy, scalability, and security. This thesis focuses on using OWL-S to represent web services.
In addition to its popularity, OWL-S offers a more intuitive extension mechanism that can be
adjusted to describe ITS applications. A detailed conceptual comparison of the WSMO and OWL-
S has been conducted in (Lara et al., 2004).
2.3.1.2 OWL-S based Service Discovery and Composition
Many research efforts focus on using OWL-S to select services automatically based on their profile
description. A semantic matching engine was introduced in (Paolucci et al., 2002) to match clients’
requests to services’ advertisements based on desired inputs and outputs of these services. Sirin et
al. (Sirin et al., 2003) utilised information on services’ profiles to build a semi-automatic
composition engine that only displays, as options, services whose outputs matches selected
service’s inputs. Users can incrementally construct customised workflows by selecting services
that produce their targeted outputs and then use the automatic selection tool iteratively to add more
services that can act as inputs to the selected services. Benatallah et al. (Benatallah et al., 2005)
used graph-based approach to determine services which cover most of the requesters’ needs. The
approach offers a more flexible matchmaking technique by recommending possible alternatives in
cases where an exact match is not feasible. A similar matchmaking algorithm that determines the
best matching services using graph-based approaches was presented in (Bellur & Kulkarni, July
2007).
More recent approaches to address the problem of automatic service discovery focus on estimating
non-functional user preferences such as accuracy, reliability, availability and security to improve
the quality of services’ selection. A trust-based approach was employed by Bansal et al. (Bansal
et al., 2010) to select services that best match client’s preferences. The presented approach uses a
degree centrality metric that estimates the trust ratings of published web services. The metric uses
the number of services’ direct links to enable such estimation. More direct links indicate more
popularity of the provider and hence better confidence in his published services.
A multi-criteria recommendation approach based on users’ rankings was introduced by Liu et
al.(L. Liu et al., 2011). The algorithm arranges users according to their preferences and uses the
collective cluster rankings to recommend services. Chen et al. (X. Chen et al., 2014) suggest a
location-aware service recommendation approach based on the assumption that users located in
the same region have similar preferences regarding their QoS requirements. The recommended
21
mechanism groups users based on their location into clusters, and use these clusters to predict the
QoS required for new users.
OWL-S based service composition has also been a subject of many research studies over the past
decade. Many of these efforts focus on using OWL-S service model to enable automatic web
services composition. McIlraith et al. (S. McIlraith & Son, 2002) extended GOLOG, a high-level
logic language developed at the University of Toronto, to provide, based on situation calculus,
adaptive and customizable service compositions in response to the different situational
information. The presented approach assumes that any users’ activities can be represented as
customizations of generic procedures that describe how web services shall interact with each other.
Another approach, which was introduced by Mokhtar et al. (Mokhtar, 2007), translates the OWL-
S service model into a finite state automata model that manages the interactions among services
using state transitions. A fast forward (FF) planning approach was employed by Klusch et al.
(Klusch et al., 2005) to compose services based on predefined planning goals that are described
using a Planning Domain Definition Language (PDDL) (M. Fox & Long, 2003). The FF planning
approach analyses the composition goals using the planning domain description and generates the
corresponding actions that achieve these goals while reacting to different situational changes.
Several studies suggest a Hierarchical Task Networks (HTN) planning approach to automating
OWL-S web services’ composition. HTN offers a robust framework to represent the knowledge
about complex processes due to the inherently hierarchical structure of these processes. An early
attempt to use HTN was presented by Wu et al. (D. Wu et al., 2003). In their approach, the authors
employed an HTN domain-independent planner named SHOP2 and used it to represent OWL-S
process models. The authors demonstrated, using a fictitious scenario, the effectiveness of their
approach and showed how different OWL-S control constructs could be translated into an HTN
domain description. Sohrabi et al. (Sohrabi & McIlraith, 2010) proposed a preference-based
approach to customise the HTN planning outcome according to a set of pre-defined regulations
and constraints defined by the users.
More recent automatic service composition approaches focus on addressing the issue of scalability
in highly dynamic composition scenarios. Paik et al. (Paik et al., 2014), for instance, proposed a
four-stage architecture based on HTN planning to enable nested and dynamic web services’
compositions. The first stage is the planning phase which transforms high-level goals and
22
composition properties into an abstract workflow that describes how these goals can be achieved.
Resulting workflow is then fed to the discovery phase where related services are allocated and
assigned to each step of the abstract workflow. Allocated services are then examined in the
selection phase to produce a concrete workflow that meets users’ requirements and achieves the
planning goals. The concrete workflow is then passed to the execution stage where actual services
are invoked.
Applying OWL-S based service discovery and composition mechanisms to manage services in
ITS applications poses some challenging questions regarding the semantics required to represent
the intelligent transportation systems, subsystems, and processes. It is required to design a new set
of tools that supports the reusability and sharing of ITS information and services among
transportation stakeholders. Within the domain of ITS, many compositions are formed manually
by querying different registries to locate the targeted services and then combining these services
in a particular order to formulate a process. This approach might be sufficient for fixed enterprise
environments where a limited number of services are executed in a fixed manner. However, in the
context of dynamic regional ITS applications where a large number of services have to be
combined automatically, more flexible discovery and composition methods are needed to enable
the construction of seamlessly integrated intelligent transportation SoS.
2.3.2 Integration of physical entities
The internet of things (IoT) (Ashton, 2009; Atzori et al., 2010) refers to the vision of creating a
ubiquitous network of interconnected smart objects that continuously acquire, process, and
interpret real-time information from their surrounding environment. Propelled by the recent
advances in sensing and communication technologies such as Radio Frequency IDentification
(RFID), wireless sensor networks, and 4G-LTE mobile networks, IoT is expected to play a
fundamental role in many smart cities’ applications such as healthcare, emergency management,
traffic congestion, waste management, and smart parking (Zanella et al., 2014). An essential
characteristic of the IoT paradigm is its ability to offer universal access to billions of
interconnected devices via consistent and standardised interfaces, and hence, it allows these
devices to communicate, share information and react autonomously to situational changes with
limited user intervention (Gubbi et al., 2013). Several standards and messaging protocols are
proposed to realise this vision such as the Constrained Application Protocol (CoAP) (Bormann et
23
al., 2012) and Message Queue Telemetry Transport (MQTT) (Hunkeler et al., 2008). A detailed
discussion of these protocols was presented by Al-Fuqaha et al. (Al-Fuqaha et al., 2015).
Several research proposals have been introduced to address the challenges of integrating IoT
elements automatically. Guinard et al. (Guinard et al., 2010) suggested using a lightweight SOA
approach to allow devices to advertise their capabilities with minimal registration overhead. The
approach offers dynamic searching and querying capabilities using a lightweight ontology that
describes the scope of sensing information, model number, firmware version, and the type of
messages exchanged by this sensor or device. Vlacheas et al. (Vlacheas et al., 2013) propose a
cognitive management framework that allocates sensors based on their level of relatedness to the
application requirements. The framework represents sensors as virtual objects that can be initiated,
mashed up, and terminated dynamically. The framework also defines a situational acquisition
component that gathers contextual information such as time of the day, day of the week, location,
and sensor availability to use it in combination with application requirements for more reliable
composition outcome.
Perera et al. (Perera et al., 2013) adopt a semantic-based sensor search approach to assist users
locating sensors that best fit their needs. Their approach differentiates between two categories of
user requirements: point-based requirements which refer to user needs that must be satisfied as
requested, and proximity-based requirements which may or may not be fulfilled based on the
availability of sensors. Sensors are ranked and displayed to users using Euclidean distance
indexing technique that calculates the distance between sensors’ characteristics and the proximity-
based requirements specified by users.
While the approaches mentioned above offer mechanisms to publish and locate sensors, they lack
a formal semantics to support ITS applications. Semantics provided by these methods lack the
capability to: 1) provide an interpretation of sensors’ data; 2) provide an explanation of the
relationships among devices; and 3) determine how these devices can improve the quality of
mobility services administered by the city. The STAR-CITY project (Lécué et al., 2014) tackles
these limitations by introducing a domain-specific ontology to support real-time and historical
aggregation of traffic data from heterogeneous data sources. The approach, however, does not rely
on the standardised representations of sensors and services, and hence it provides limited
interoperability support in large-scale systems.
24
The Semantic Sensor Network (SSN) ontology (Compton et al., 2012) overcomes part of these
limitations by defining a conceptual model to describe sensors, sensors’ deployment, and sensors’
observation data. SSN follows the Stimulus–Sensor–Observation ontology design pattern
(Janowicz & Compton, 2010) to represent the relationships among observation values and their
associated properties. Several research studies suggest SSN allows seamless integration of real-
time sensor data in complex systems (Henson et al., 2012; I. Khan et al., May 2015). Linked Stream
Middleware (Le-Phuoc et al., 2012), for instance, employ SSN to gather, process, and analyse data
from over 100,000 sensor data source. The ontology, however, does not provide the ability to
represent the relationships between sensors and the associated cyber components processing the
data produced by these sensors, and hence, the ontology offers a limited capability to represent
cyber-physical interactions.
This research introduces a coordination framework to manage cyber-physical interactions in ITS
applications. The framework takes into consideration the interpretation of the data produced by
each sensor and the relationships among sensors, city infrastructure, and city processes. The
originality of our approach lies in its ability to formulate, based on the Canadian ITS architecture,
dynamic processes that involve both physical and cyber components with minimal user
intervention. Furthermore, the approach offers mechanisms to coordinate ITS plans, gather and
share ITS contextual information among collaborating ITS entities, discover services, and execute
ITS operations to react to different situational changes.
25
3 Overview of the Three-Pillar Framework
Chapter 1 established the importance of achieving seamless coordination of cyber-physical ITS
resources and the need to effectively combine these resources to create an ITSoS capable of
performing regional, multi-modal, and multi-jurisdictional operations. This chapter discusses a
high-level analysis of the operational aspects of three-pillar framework illustrating the functional
requirements, fundamental design principles, and the baseline architecture. The chapter starts by
identifying the essential characteristics of a SoS to distinguish its operation from other monolithic
systems. The chapter then provides a demonstrating example of how a SoS can be employed to
provide regional advanced traveller information services highlighting its key functional
requirements. Finally, the chapter presents a high-level overview of the proposed three-pillar
framework featuring its design principles, core concepts and modules.
3.1 Characteristics of an ITSoS
The development of an ITSoS is a lynchpin to enabling integrated transportation operations that
allow ITS users to make better-informed decisions about transportation networks (Daniel
Delaurentis, Jan 1, 2005). The main thrust behind the development of an 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. This
research adopts the SoS characteristics defined by Mark Maier (Maier, 1998), also suggested by
other several studies (Boardman & Sauser, 2006; Gorod et al., 2008; Madni & Sievers, 2014), to
identify the foundational requirements for the coordination framework. These characteristics are:
1) Operational and Managerial Independence of the SoS elements, also referred to as
autonomy (Boardman & Sauser, 2006), which implies that constituent components
shall exist to provide functionalities and deliver 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 also suggest that constituent elements
should have the liberty to join or abandon the SoS at their discretion and on a cost-
benefit basis.
26
It is important in this regard to differentiate between the operational and managerial
independence of constituent SoS components, and their interdependency when
interacting within an SoS. While constituent SoS components shall be created and
maintained independently of the SoS, they must have common characteristics that
allow them to collaborate, communicate, and contribute to the integrated whole
(Baldwin & Sauser, 2009). That is, while constituent systems have the liberty to
belong to an SoS, they must fulfil stringent selection criteria that allow these systems
to intercommunicate. These characteristics define the interfaces, communication
channels, and abstract roles that constituent systems must possess to be able to work
together efficiently and achieve common goals.
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 can not be
offered by any of its constituent components.
4) Geographic Distribution, which implies that a SoS shall integrate distributed and
decentralised components.
3.1.1 Demonstrating Example: Using an ITSoS to Provide Regional Traveller Information Services
Consider, for the purpose of illustration, an Advanced Traveler Information SoS (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 3-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 information requires the interaction of several distributed
27
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,
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 3-1 Route Guidance and Navigation in Advanced Traveller Information System
28
to deliver integrated services that cannot be provided by any of the SoS’s constituent
components alone.
3.1.2 Requirements Analysis
The development of the requirements for the framework was guided by the four principal
characteristics of a SoS mentioned above, and by the needs of semantic interoperability,
coordinated planning, and automatic integration discussed earlier in Section 1.1.1. These
requirements, as depicted in Table 3-1, are categorised into the following three main groups:
Institutional Requirements, which define the role of the framework from ITS stakeholders’
point of view. Institutional requirements define the capabilities required to assist
stakeholders with the design and analysis of integrated SoS operations that achieve their
collaboration goals and objectives.
Operational Requirements, which enable the execution of integrated and interoperable SoS
applications similar to the demonstrating example discussed in Section 3.1.1. Operational
requirements enable seamless and automatic integration of cyber-physical components to
achieve stakeholders’ goals while fulfilling the other requirements for SoS operations.
Communication Requirements, which define the functions of the framework needed to
share information successfully among interacting components.
Table 3-1 The Intelligent Transportation SoS Requirements
1. 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.
29
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
SoS.
2. 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 decentralised architecture in which all the
constituent SoS components are managed and maintained independently from the SoS.
2-3. The framework shall allow SoS system administrators to add, remove, or modify
SoS 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.
3. Communication Requirements
3-1. The framework shall provide the messaging infrastructure required to share and
distribute information across distributed SoS 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.
30
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 SoS contextual
information among interacting cyber-physical components.
3.2 Overview of the Three-Pillar Framework
Based on the above discussion, coordination of ITS cyber-physical components 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 SoS applications through
stitching together sensors and services, provided by other types of business entities as
below, that interact seamlessly to achieve application providers’ goals.
ITS Service Providers: Service providers offer their software functionalities and IoT
sensors via an Everything-as-a-service paradigm (XaaS) (Banerjee et al., 2011) 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.
The three-pillar framework developed in this research fulfills the institutional, operational and
communication requirements, to realise the envisioned ITSoS. The integrative ITSoS fulfills these
requirements by defining three pillars of operation, highlighted in Figure 3-2. The pillars allow
seamless collaboration amongst ITS service and application providers to deliver integrated SoS
operations. The first pillar constructs an ontology that captures the main concepts and relationships
within the SoS 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 analysed, using the integrated
31
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 the three pillars of the framework highlighting the key modules and
design principles.
3.2.1 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 Dictionary11, 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 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
11
http://www.merriam-webster.com/
Figure 3-2 Coordination Methodology
32
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 acts as a common language
between ITS service providers, ITS application providers, and the SoS engine to represent complex
interactions among distributed ITS services and sensors in a machine-understandable format.
Furthermore, 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 summarised by Hickman et al.
(Hickman et al., 1996) such as social acceptability, flexibility, guide-ability, and
comprehensiveness. Chapter 4 provides a more detailed discussion of the ontological model
highlighting its core concepts and relationships.
3.2.2 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 Canadian Architecture, which analyses integrated SoS operations to
their fundamental requirements describing the operation of their constituent cyber-physical
components. 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 analysed to
their sub-components till the most primitive requirements (e.g. collect traffic data) are obtained
for each service. The execution engine, the third pillar of the framework, then uses these primitive
requirements to locate corresponding cyber-physical components satisfying the requirements.
The framework relies on the following two fundamental concepts to enable the ISP:
1) Virtual Organisations: A virtual organisation consists of a set of ITS stakeholders who
interact, collaborate, and share resources to achieve a common objective through
33
harnessing their collective intelligence (Pitt et al., 2013). The concept of virtual
organisations enables find-ability, and filtering of services and sensors based on the
community’s interests and preferences. ITS stakeholders may dynamically 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 organisations despite the heterogeneity
in their legacy software platforms and data models.
2) Hierarchical Task Networks: Hierarchical Task Networks (HTN) (Ghallab & Nau, 2004)
is an Artificial Intelligence (AI) planning technique that encodes the procedural knowledge
about the domain of interest into a hierarchy of tasks and decomposing methods. The
technique defines a set of conditions and ordering constraints that control the
decomposition of the different tasks. The HTN starts with an initial state and an initial task
that is required to be implemented. The planning process decomposes the initial task
analysing 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 organisation
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 analysed and
organised 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. The process of creating
abstract ITS plans is illustrated in Chapter 4.7 using the example of creating an ATIS operation.
3.2.3 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 service management
infrastructure to streamline the integrated execution of ITSoS services by enabling several
34
functionalities such as service discovery, selection, monitoring, and invocation. 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.
Another key component of the ISE pillar is the context management module, which enables the
dynamic execution of ITS operations according to the contextual information retrieved from ITS
sensors such as levels of congestion, visibility state, weather-state, etc. This research adopts Dey’s
definition (Dey & Abowd, 1999) of context which is “any information that can be used to
characterise the situation of an entity. An entity is a person, place, or object that is considered
relevant to the interaction between a user and an application, including the user and applications
themselves”. Context management, using Dey’s definition, includes any information that
describes entities relevant to SoS operations such as users, vehicles, and infrastructural elements.
The context management module involves three main operations to produce such information:
context gathering, context processing, and context dispatch.
In the gathering phase, raw data is aggregated from different sensors and devices and is pre-
processed, filtered and annotated to link it to its corresponding entities in the SoS. Aggregated
context is then analysed, in the processing phase, to infer higher implicit information about the
situational changes. The processing phase can be as simple as translating measurement data into
congestion levels, or it can be any of a myriad of more complex applications such as incident
detection (Abdulhai & Ritchie, 1999; Roy & Abdulhai, 2003), short-term traffic state prediction
(Abdulhai et al., 2002; Ma et al., 2015), traffic data fusion (Bachmann et al., 2012; Byon et al.,
2010), and mode detection (Byon et al., 2009). This information is then dispatched, in the final
phase, to update other functional entities of the ISE such as the service discovery module. This
thesis focuses primarily on the first and third stages of the context management component
illustrating how the module can be incorporated to facilitate sharing contextual information among
ITSoS constituent components. Context processing is kept at the simple level as the discussion and
the integration of complex context processing algorithms is beyond the scope of this thesis.
By incorporating the service and context management modules, the ISE pillar facilitates the
automatic execution of integrated SoS operations by performing the following functionalities: 1)
provide data mapping and transformation between different ITS cyber-physical modules; 2)
35
validate exchanged messages among ITS cyber components; 3) keep track of ITS services
published by ITS service providers; 4) annotate published services linking them to the ontological
model; 5) collect and annotate contextual data to control the execution of ITSoS plans; and 6)
orchestrate the execution of ITSoS operations in response to contextual changes. Chapter 6
discusses the operation of these modules and their role in enabling the coordination of ITS cyber-
physical components.
In closing of the chapter, it worthy to mention that the ATIS use case discussed above and used in
the development of our ITSoS 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. In fact, the development of the ITSoS aims beyond ITS all-together
and may encompass in the future other transportation activities such as transportation planning,
provision of Transportation as a Service (TaaS) and beyond. 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 SoS discussed in section 3.1. Ongoing and future
funded research work, beyond the scope of this thesis, will generalise the platform to wider
transportation and ITS applications.
36
4 Ontological Semantic Knowledge Representation (OSKR)
Chapter 4 discusses the details of the first pillar of the coordination framework, the Ontological
Semantic Knowledge Representation (OSKR), which formally represents abstract ITS processes,
services, sensors, and infrastructural elements to support the semantic interoperability requirement
of an integrated ITSoS. OSKR constructs a multi-tier ontology to represent the various interactions
within the ITSoS and hence it supports the automatic coordination and integration of its constituent
components. I first provide background highlighting the characteristics and capabilities of the
knowledge representation languages. I then discuss the development of the multi-tier ontology
highlighting the methodology, core concepts and relationships, external ontologies, integration
process, and evaluation.
4.1 Background
The implementation of a machine-understandable model of the ITSoS relies on the language
chosen to represent the knowledge of the ITS domain. Knowledge representation languages may
range from informal approaches, which model the domain as a list of terms with little or no
connections among them, to a full formal description that ultimately defines the concepts of the
domain, their attributes, relationships, and constraints (M. S. Fox et al., 1995; Uschold &
Gruninger, 2004). On the one end, informal approaches suffer from a high level of ambiguity
hindering the reasoning capabilities required to interpret the different relationships within the
model. On the other hand, there is a trade-off between the level of expressiveness and the efficiency
of the reasoning engines. Highly expressive languages, such as the first-order logic, can lead to
intractable reasoning problems. Other languages, such as description logics, which is a subset of
the first-order logic, offer more practical and more efficient reasoners (Staab & Studer, 2009). This
section discusses Resource Description Framework (RDF), RDF Schema (RDFS), and The Web
Ontology Language (OWL) as the most common knowledge description languages.
4.1.1 Resource Description Framework (RDF)
The Resource Description Framework (RDF) (Klyne et al., 2006) offers a general-purpose
language to annotate and describe resources in a machine-understandable format. The model
supports the incorporation of multiple metadata schemas, known as RDF vocabularies, to define
37
the various properties and relationships used in the knowledge representation. A resource in the
RDF model can be anything that exists in the domain of interest or the universe of discourse
required to be represented. Each resource is identified by a unique Internationalized Resource
Identifier (IRI) and a group of RDF statements defining the properties of this resource and how
this resource is related to other resources.
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
An RDF graph is a set of RDF statements where predicates act as edges connecting subjects and
objects (the nodes of the graph).
4.1.2 RDF Schema (RDFS)
The RDF Schema (RDFS) (Brickley & Guha, 2004) is an extension of the RDF that provides more
powerful modelling and abstraction capabilities by organizing RDF resources into a hierarchy of
classes. A class entity in RDFS represents a group of objects within the domain of interest that
share some common characteristics and are identified using the same set of properties. Instances
of class entities are resources that are connected to their corresponding classes using the rdf:type
property. A class entity can be a subclass of another class entity, which implies that all instances
of the child class are also instances of the parent class. Similarly, a subproperty relationship
indicates that all relationships represented by the child property have corresponding relationships
using the super property. Properties are typically described by a domain and a range which assert
the type of objects that can be described by these properties and the valid values that can be
associated with these object types.
4.1.3 The Web Ontology Language (OWL)
RDFS facilitates the representation of domain’s objects as a hierarchy of classes, however, the
constructs offered by RDFS, have a limited capability to represent many other characteristics such
as disjointedness and transitiveness. Furthermore, the vocabulary does not allow the definition of
38
composite classes using operations such as union, intersection and complement. The Web
Ontology Language (OWL) (Bechhofer, 2009) enables such capabilities by providing richer
semantics to support several modelling and reasoning functionalities.
OWL offers three main sublanguages (species) that differ in their expressiveness and
computational capabilities. OWL-Full is the most expressive form of OWL; it provides full
compatibility with RDF and RDFS. Such expressiveness, however, affects the computational
efficiency of the language and causes the reasoning to be intractable in some scenarios. In contrast
with OWL-Full, OWL-DL guarantees the computational decidability and completeness of the
reasoning functionalities by adding restrictions on the use of some constructs. For example, a
resource in OWL-DL cannot be a class and individual at the same time. OWL-DL supports
reasoning with description logics (DL), which is a requirement of many applications. The third
form of OWL sublanguages is OWL-Lite, which offers less expressive constructs compared to
OWL-DL, and it is typically used to describe simple models with simple constraints.
The integrated ITSoS ontology uses OWL-DL to express the concepts and relationships within the
ITSoS domain. The language provides sufficient level of expressiveness to support the various
reasoning features required by the framework while maintaining a reasonable computational
efficiency. The design of the model follows the linked data design principles defined by Tim
Berners-Lee (Berners-Lee, 2006) to create a semantic graph of interlinked sensors, services,
processes, and city infrastructures. Reasoning across the semantic data is supported using the
Apache Jena default OWL Reasoner which verifies whether the stored knowledge statements
violate any of the restrictions imposed by the ontology and if they contain any logical
contradictions as will be discussed later in section 4.7. The development of the ITSoS model is
illustrated in the following sections.
4.2 The ITSoS Ontology Development Methodology
The methodology for developing the ITSoS ontology involves the following five main steps
(Grninger & Fox, 1995; Staab & Studer, 2009):
1. Definition of the objectives, and scope, which is essential to specify the boundaries of the
ontology and identify its main features. It is also a necessary requirement to control the
39
ontology development process and guide the specification of the main concepts and
relationships.
2. Development of competency questions, which define the ontology requirements as a set of
inquiries that the ontology should answer. Hence, they are used to identify the level of
details required to represent the model and to evaluate if the resultant ontology satisfies
these domain representation requirements.
3. Ontology formalisation, which explicitly represents the concepts and relationships within
the domain of interest by coding them using the OWL-DL. This step involves 1) the
identification of existing ontologies that can be reused within the model; 2) development
of new concepts and relationships.
4. Integration, which combines all the concepts and relationships to create an integrated
ontology that represents the domain of interest.
5. Validating the ontology, which examines the resultant ontology to verify that it satisfies its
design objectives. The richness and the applicability of the ontology was verified using
the competency questions and real-world examples.
4.3 ITSoS Ontology Objectives and Scope
The intended use of the ontology in this research is to formally represent the concepts and
relationships necessary to support the automatic coordination and integration of ITS sensors and
services within an ITSoS. In particular, the ITSoS ontology focuses on achieving the following
objectives:
1. To facilitate sharing information about standardised ITS processes, defined by the
Canadian ITS architecture, among ITS service and application providers. The ontology
shall formally represent standardised processes, their data flows, and their implementing
physical systems in a machine-understandable format. Standardised ITS processes provide
a level of abstraction required to manage the heterogeneity of the various ITS cyber-
physical resources within an ITSoS.
40
2. To support automatic discovery of sensors based on their role as defined by the Canadian
ITS Architecture. The ontology shall represent sensors’ location, capabilities, observed
properties, and associated infrastructural elements (e.g. roads).
3. To support automatic discovery of services based on their role as defined by the Canadian
ITS architecture. The ontology shall represent services’ functionalities, inputs, outputs, and
accessing information.
4. To facilitate sharing contextual information among the various cyber-physical components
within ITSoS.
5. To support automatic composition of the cyber-physical components by linking them to
their corresponding standardised ITS processes and implementing physical packages.
6. To facilitate sharing information about virtual organisations representing their concerned
stakeholders, collaboration goals, and custom-built processes.
Creating a comprehensive ontology that formally represents all the possible attributes, properties,
and possible interactions within an ITSoS is beyond the scope of this and any single thesis. The
scope of this ontology is to capture the key concepts and relationships necessary to demonstrate
the operation of the coordination framework and to produce a proof-of-concept highlighting the
operation of the framework’s modules. Also, the ontology does not represent the properties and
interrelations of external entities interacting with an ITSoS such as vehicles, travellers, and
operators. These entities are represented using the concept of Terminators, discussed in Section
4.5.1.1, which represents all external entities providing inputs or receiving outputs from the ITSoS
operations.
4.4 Competency Questions
According to the demonstrating example, discussed in Chapter 3, and the objectives of the ITSoS
ontology discussed earlier in this chapter. The following sets of competency questions were
identified:
1) Questions regarding standardised ITS processes
What are the possible outputs of standardised ITS process?
41
What are the possible inputs of a standardised ITS process?
What goals is a standardised ITS process trying to accomplish?
What are the roles of stakeholders involved in a standardised ITS process?
What physical equipment packages implementing a standardised ITS process?
What are the functional requirements to satisfy a standardised ITS process?
What are the services that implement a standardised ITS process?
2) Questions regarding ITS sensors
What are the properties observed by an ITS sensor?
What are the features (e.g. road elements) monitored by an ITS sensor?
Which standardised ITS processes are supported by an ITS sensor?
What are the measuring capabilities (e.g. accuracy) of an ITS sensor?
Which sensors are deployed on a city infrastructural element (e.g. road element)?
What are the alternatives of an ITS sensor in case of failures to observe a property of an
infrastructural element?
3) Questions regarding ITS services
What are the inputs of an ITS service?
What are the outputs of an ITS service?
Which standardised processes require the execution of an ITS service?
What are the message protocols required to invoke an ITS service?
What are the alternatives of an ITS service in case of failures to implement a functional
requirement?
4) Questions regarding virtual organisations
What is the collaboration goal of a virtual organisation?
Who are the stakeholders collaborating on a virtual organisation?
What are the standardised ITS processes supporting collaboration goals of a virtual
organisation?
42
What are the services implementing standardised ITS functional requirements within the
scope of a virtual organisation?
Which deployed ITS sensors support the implementation of a standardised ITS functional
requirement within the scope of a virtual organisation?
4.5 ITSoS Ontology Formalisation
The ITSoS ontology reuses the Web Ontology Language for Services (OWL-S), and Semantic
Sensor Network (SSN), and Ontology of Transportation Networks (OTN) 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 answer the competency questions identified in the
previous section and according to the extensibility of their design. A missing major component,
however, is how to formally define abstract ITS processes that link these objects together in an
ITSoS. The ontology for abstract ITS processes (OITSP), which is developed from scratch in this
research and presented in the following section, provides such capability by offering an abstract
Figure 4-1 The Four Components of the ITSoS Ontology.
ITSoS Ontology
Web Services
Ontology (OWL-S)
Ontology of Transportation Networks
(OTN)
Semantic Sensor
Network (SSN)
Ontology for ITS
Processes (OITSP)
43
layer that connects distributed and heterogeneous cyber-physical components to facilitate their
automatic coordination within an 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 Chapter 5. Furthermore, the OITSP
allows the representation of virtual ITS organisations allowing them to link their goals and
operations to the ITS architecture. Figure 4-1 illustrates the four components of the ITSoS
ontology.
4.5.1 An ontology for Abstract ITS Processes (OITSP)
The basic role of the OITSP is to transform the knowledge represented by the ITS architecture into
a formal, machine-understandable format enabling the framework to interpret the abstract
connections among cyber-physical components and hence be able to combine them automatically
to achieve ITSoS goals. The OITSP formally defines general ITS processes describing their
characteristics and how their cyber-physical elements can be linked together. The ontology also
represents abstracts functionalities, categories, and different information flows associated with ITS
devices and services providing the abstraction required to integrate these components seamlessly.
4.5.1.1 Core Ontological Concepts
Similar to the National ITS Architecture for Canada, the OITSP defines two main concept
schemes, shown in Figure 4-2, the logical and physical architecture. The logical architecture
describes the specifications of logical standardised ITSoS processes that satisfy general
stakeholders’ goals, represented by user service requirements objects. These standardised
processes identify the inputs, outputs, and associated physical equipment packages required for
the implementation of stakeholders’ goals. Hence, the logical architecture offers a nexus between
stakeholders’ needs and their implementing ITS physical entities.
A process may include other interacting sub-processes identified via the is-part-of property. A
Traffic surveillance process, for instance, defines several interacting sub-processes such as
‘Process Traffic Sensor Data’, and ‘Process Environmental Sensor Data’. Logical processes
define standardised data Flows that represent conceptual data structures of the shared messages
among ITSoS cyber-physical components. These data flows represent the basis for mapping and
transforming different data structures communicated within the ITSoS by defining a reference data
44
model that all cyber-physical components can relate to. Each data flow is connected to a
terminator or a process entity using hasInFlow and hasOutFlow properties.
The physical architecture includes all concepts related to standardised implementations and
standardised physical deployments of ITS. A building block of these systems is an equipment
package which represents independent, self-contained deployment that implements logical ITSoS
processes and defines a set of functional requirements. Equipment packages define a set of
architecture flows that implement logical data flows using one or more ITS standards (Steve Sill
et al., 2011). Each architecture flow is characterised by a description, source entity, destination
entity, and architecture flow type.
A collection of equipment packages that implement a complete user service and satisfy all of its
user service requirements is called a service package. The ITS architecture defines thirty-seven
Logical Architecture
Physical Architecture
Data FlowProcess
Architecture FlowEquipment Package
Standard
Serv
ice
P
acka
ge User Service
User Service Requirement
requires
satisfies
has
has
relatedimplements
related
implements
Is-part-of
Is-part-of
Is-part-of
StakeholderStakeholder
Rolehas
Functional Requirement
defines
Is-part-of
involves
Terminator
has
has
Is part of
Figure 4-2 Main Concepts of the Ontology for Abstract ITS Processes (OITSP)
45
user services covering the needs of a broad range of ITS operations such as traveller information,
traffic control, and transit operations.
Equipment packages are classified, based on their functionalities, into four categories:
1. Centre Equipment Packages, which implement management and administration user
service requirements such as Traffic Information Dissemination package which
disseminates traffic data from management centres to media, traveller information systems,
and other entities;
2. Field Equipment Packages, which perform monitoring and control functionalities such as
the Roadway Incident Detection package which provides incident information based on the
data collected from traffic sensors;
3. Traveller Equipment Packages, which include packages owned and maintained by
travellers such as the Personal Location Determination Package which provides
information about traveller’s location using GPS-enabled devices such as smartphones; and
4. Vehicle Equipment Packages, which includes packages that reside in a vehicle such as the
Vehicle On-board Diagnostics System package which provides engine-related information
such as engine load, coolant temperature, etc.
Terminators represent external objects that interact with ITS processes as devices, travellers,
operators, and other systems. Similar to equipment packages, terminators are classified into: 1)
Centre Terminators such as external systems providing services that rely on transportation data
(e.g. public health systems); 2) Field Terminators such as field operators and inspectors; 3)
Traveller Terminators, which means the individuals using the transportation network; and 4)
Vehicle Terminators such as basic vehicles, transit vehicles, and commercial vehicles. As
mentioned earlier in this chapter, representation of the properties of process terminators is out of
the scope of this thesis. The OITSP focuses on capturing the interactions with these entities which
are represented by the architecture flows.
4.5.1.2 Concepts Related to Virtual Organisations
The ITSoS ontology defines additional concepts, highlighted in Figure 4-3, to facilitate sharing
knowledge about virtual organisations. Virtual organizations represent communities of interest
46
formed by ITS stakeholders to achieve a set of common objectives (collaboration goals).
Collaboration goals are described using two types of user requirements: standardised user
requirements which are established as part of the Canadian ITS Architecture; and extended user
requirements which are tailored requirements defined by stakeholders to represent committee-
specific objectives. Stakeholders may also define extended processes to describe their variations
of the standardised processes defined by the logical architecture and use these definitions to build
a customized SoS that achieves their objectives. The OWL representation of the OITSP ontology
is shown in Appendix A.
4.5.2 External Ontologies
In addition to the OITSP, the ITSoS ontology reuses three external ontologies to represent the web
services, sensors, and city infrastructure. The key concepts and relationships of the external
ontologies are discussed in the following sections.
4.5.2.1 Web Ontology Language for Services (OWL-S)
The three-pillar framework relies on the Web Ontology Language for Services (OWL-S) (Martin
et al., 2007) to represent the knowledge about cyber ITS components. OWL-S represent services
using the following three main perspectives:
Stakeholder
VirtualOrganisation
UserServiceRequirement
ExtendedProcess
CollaborationGoal
memberOfVirtualOrganisation
definesGoal
DefinesProcess
definesUserServiceRequirement
satisfiesUserServiceRequirement
describesGoal
Standardised User Requirement
ExtendedUserServiceRequirement
Figure 4-3 Concepts Related to Virtual Organisations
47
1. Service profile which provides a high-level specification of the service for advertisement
and discovery purposes. Attributes specified by the service profile include serviceName,
textDescription, serviceClassification, and contactInformation. Service profile also
describes the functionality of the services using hasInput, hasOutput, hasPrecondition, and
hasResult properties.
2. Service model which describes how a service is viewed from clients’ perspective. A service
model defines processes to represent how a service or a group of services can be invoked
and utilised. The functionality of a process is described by inputs, outputs, preconditions,
and results. Service model defines the following three forms of processes:
Atomic processes which represent activities that can be performed by invoking a
single service directly.
Composite processes which represent complex activities that require invocation of
multiple services and processes. A CompositeProcess object involves a control
structure such as sequence, split, and iterate that describes how the process
components are executed.
Simple processes which subsume a group of atomic or composite processes
performing similar functionalities. Simple processes are not executable and
typically used to support the automatic composition of services. They are linked to
their associated atomic and composite processes using realizedBy and expandsTo
properties.
Service grounding which represents the information necessary to invoke and
interact with the service such as communication and messages protocols.
Figure 4-4 shows a partial knowledge representation of a web service using OWL-S ontology. The
service, as shown in the figure, is described by an atomic process, LoadCurrentIncident; and it is
advertised by the service profile, IncidentListInquiry. The statements indicate that process requires
three input parameters incidentImpact, incidentType, and region and produces a list of incidents
as an output. The service supports a Web Services Description Language (WSDL) grounding,
48
incidentListWSDLGrounding, which specify parameters such as the URL of the WSDL document,
WSDL port, and WSDL messages.
4.5.2.2 Semantic Sensor Network (SSN)
The second external ontology is the Semantic Sensor Network (SSN) (Compton et al., 2012),
which provides a semantic description of the ITSoS sensors and their observations, deployments,
and systems. SSN follows the Stimulus-Sensor-Observation ontology pattern (Janowicz &
Compton, 2010), which improves the flexibility and extensibility of the ontology and makes it
applicable in various ITS applications. As the name indicates, the Stimulus-Sensor-Observation
pattern uses three main concepts to describe the characteristics of sensing devices. A stimulus
represents an event or a change in the environment, such as a change in temperature or magnetic
field amplitude, that initiates a sensing action. Sensors are the physical objects that detect these
stimuli and turn them into observations describing some properties of observed features. SSN
allows the description of sensors’ measuring capabilities such as accuracy, precision, and
frequency; energy aspects such as battery lifetime and operating power range; and the operation
restrictions of the device such as operating range and survival range.
The concept of property in the SSN ontology is utilized to enable sharing of contextual information
collected by the ITS sensors. Following Dey’s definition (Dey & Abowd, 1999) of context
InicdentListProfile
InicdentListInquiryServiceowls:presents
LoadCurrentIncidents
owls:describedBy
InicdentListWSDLGrounding
owls:supports
AtomicProcess
rdf:type
incidentImpact
incidentType owls:hasInput
owls:hasInput
incidentsListowls:hasOutput
WsdlAtomicProcessGrounding rdf:type
ServiceProfile
rdf:type
Service
rdf:type
region owls:hasInput
Figure 4-4 Partial Representation of a Web Service
49
discussed earlier in section 3.2.3, context is any information that can used to assess the situation
of an entity. Context is represented in this ontology as properties describing some features of
interest such as infrastructure elements, travellers, and vehicles. Properties are associated with
Sensor, Observation, and FeatureOfInterest objects using the observes, observedProperty, and
isPropertyOf relationships respectively. More information about using the concept of properties
to share contextual information will be discussed in Chapter 6.
Figure 4-5 shows an example of how the three-pillar framework uses SSN to represent an inductive
loop sensor. The knowledge statements shown in the figure indicates that the sensor is deployed
as part of the 400-Deployment which is deployed on the MTO-COMPASS platform covering the
400 series freeways in the Greater Toronto Area (GTA). The statements also show that the sensor
made a speed observation at a time specified through the observationResultTime property and
during a sample interval described by the observationSamplingTime property. The observation
describes the speed on Road_Element_Z, which is an instance of the FeatureOfInterest class.
4.5.2.3 Ontology of Transportation Networks (OTN)
Ontology of Transportation Networks (OTN) (Lorenz et al., 2005) specifies a set of classes and
properties to describe the different elements of a road network. The ontology follows the
Geographic Data Files (GDF) ISO specification (ISO, 2011) which conceptually describes various
Speed_Obsevation_Y
Inductive-loop Detector_X ssn:observedBy
Speed
ssn:observedProperty
Road_Element_Z
ssn:isPropertyOf
xx
ssn:observationSamplingTime
xx
ssn:observationResultTime
FeatureOfInterestrdf:type
Observation
rdf:type
Sensor
rdf:type
400-Deployment
ssn:hasDeployment
Deployment
rdf:type
MTO-COMPASS
deployedOnPlatform
Platformrdf:type
Figure 4-5 Partial Representation of a Sensor
50
aspects of transportation networks such as roads, railways, ferries, public transport systems,
parking areas, and administrative areas. The ontology defines the following three main classes to
describe transportation network elements:
The feature class includes all the transportation network subclasses such as road, ferry,
transit route, and airport area. Network subclasses are organised into three main themes
describing their categories: road networks, transit networks, and land coverage and use.
The geometric class describes the shape of an OTN feature using one of the following
subclasses:
o The node subclass represents a point or a single location on a map such as a
junction or an intersection and it is defined by three attributes: x, y, and z
representing its coordinates.
o The edge subclass represents a line between two nodes identified by start_at and
ends_at properties and it used to describe features such as road element, transit
route link, and ferry connection.
o The face subclass represents an area or a surface bounded by edges identified using
the bounding_Edge property and it used to represent features such as parking areas,
construction sites, and vegetated areas.
The transfer_point class defines features that serve as accessibility points to the road or
transit networks such as junctions and intersections. Accessible locations are described
using the is_Accessible_At property. A subclass of the accessible locations is the
Transfer_Service, which identifies places where the change of transportation mode is
permissible such as bus stations.
Figure 4-6 shows the knowledge representation of a road element within the City of Toronto
transportation network with the ontology concepts highlighted as coloured rectangles. The
knowledge statements indicate that Element_X, an object of class Road Element, has two properties
start_at and ends_at linking the object to its start and end junctions X_Start_Node and
X_End_Node. Element_X is also part of the Lake Shore Boulevard W, which is shown in the map
51
below the knowledge graph, and has a positive direction of traffic flow (i.e. traffic flows only from
the start node to end node).
OTN represents transit routes using six main concepts: Route_Link, Route_Section, Route, Line,
Public_Transport_Junction, Public_Transport_Point, and Stop_Area. A route is a transit service,
whether bus or rail, operating on a predetermined schedule. Routes are typically divided into a set
of route sections describing the main parts of the route. The basic building block of a route is the
route link, which represents a physical path between two adjacent public transport junctions. Same
route link might be associated with more than one route. Each route is defined by a starting stop,
ending stop, and a timetable maintaining all the necessary information about the schedule of that
route (e.g. departure time, average waiting time, etc.). Figure 4-7 shows of a partial knowledge
representation of transit bus line 29 Dufferin which is a service offered by Toronto Transit
Commission (TTC), as shown in the left side of the figure. The knowledge statements show that
the line contains a southbound route (29A) that operates between two transit junctions Wilson
Figure 4-6 Partial Representation of a Road Element
LAKE SHORE BLVD W
ELEMENT_X
contains
Roadrdf:type
Road Element
rdf:type
X_End_Node
X_Start_Node
starts_at
ends_at
Junction
rdf:type
rdf:type
Positive_direction
Direction_of_Traffic_Flow
rdf:type direction_of_Traffic_Flow
Road_and_Ferry_Featuresrdfs:subClassOf
52
station, and Dufferin Gate. Full represenation of the model contains three more routes: southbound
29B which operates from Lansdowne Avenue to Dufferin Gate, northbound 29A from Dufferin
Gate to Wilson, and northbound 29B operating between Dufferin Gate and Lansdowne Avenue.
Each Route is associated with a timetable entity which describes the scheduled arrival time at each
station, expected waiting time, duration to travel along the route, and validity period.
4.6 ITSoS Ontologies Integration
A simplified inclusion approach (Farquhar et al., 1997) was adopted to merge ontological concepts
and relationships, defined by the ontologies mentioned above, into a unified global ITSoS
ontology, as shown in Figure 4-8. The integration was first conducted using protégé which relies
on the Internationalized Resource Identifier (IRI) of each symbol to avoid the conflicts in the
merged terminologies. Resultant classes and properties, which are initially defined as separate and
disjoint, are then analysed to characterise the mapping relationships among the different classes.
The merging procedure involves the following three main integration steps:
Figure 4-7 Partial Representation of a Transit Route
53
1. Integrating the OTN and SSN ontologies into an extended ontology 𝑂′: The otn:Feature
class in the OTN ontology is defined as a subclass of the ssn:FeatureOfInterest class.
Consequently, OTN features such as road elements or bus stations represent SSN objects
whose properties can be observed using an ssn:Sensor object. Similarly, OTN feature
attributes such as otn:Average_Vehicle_Speed and otn:Travel_Time, describing the OTN
features, are defined as subclasses of the ssn:Property class. OTN properties such as
otn:accident and otn:direction_of_Traffic_Flow are defined as sub-properties of the
ssn:isPropertyOf.
2. Integrating the 𝑂′and the OITSP into an extended ontology 𝑂′′: The OITSP does not
represent actual devices or deployments. Instead, the ontology describes the functionalities
and categories of these deployments. Therefore, ssn:Device, and ssn:System SSN ontology
concepts are disjoint from other OITSP concepts such as its:Termintor and its:System.
While the SSN concepts describe actual devices or systems, the OITSP concepts describe
an abstraction of these devices and system. Integration of the two ontologies is achieved
by adding association properties to relate the SSN objects such as sensors, devices, and
systems to their corresponding ITS functional requirements, equipment packages, and
Figure 4-8 The Integrated Ontological Model
54
systems. The integrated ontology also defines a new property sharedBy to relate devices to
their ITS stakeholders.
3. Integrating the 𝑂′′and OWL-S ontologies into the final ITSoS ontological model: The class
of owls:SimpleProcess represents an abstraction to describe the functionality of atomic and
composite processes which is the same meaning of the its:Process concept. The concept of
its:Process, however, has a more limited scope as it describes processes within the ITS
domain only. Hence, the its:Process class is defined as a subclass of the
owls:SimpleProcess class. Consequently, the its:InputFlow and its:OutputFlow are defined
as subclasses of the owls:Parameter. Similar to step two, the integrated ontology uses the
sharedBy property to relate services to their ITS stakeholders and association properties to
link services to their corresponding functional requirements and OTN features. Sensing
services representing the output of SSN sensors are associated with their corresponding
sensing entities using hasSensor property.
The final ITSoS ontological model introduces three inferred concepts to support automatic
formulation of collaborative workflows among stakeholders. The role of the added concepts is to
express the shared ITS Resources, which can be services or devices, among stakeholders who are
members of an ITS virtual organization. Identification of shared resources allows better selection
of services and devices when composing an ITS workflow as discussed later in Chapter 4.7. The
three concepts are defined as follows:
𝑆ℎ𝑎𝑟𝑒𝑑𝑆𝑒𝑟𝑣𝑖𝑐𝑒
≡ 𝑜𝑤𝑙𝑠: 𝑆𝑒𝑟𝑣𝑖𝑐𝑒 ⊓ ∃𝑠ℎ𝑎𝑟𝑒𝑑𝐵𝑦. (𝑖𝑡𝑠: 𝑆𝑡𝑎𝑘𝑒ℎ𝑜𝑙𝑑𝑒𝑟
⊓ ∃𝑚𝑒𝑚𝑏𝑒𝑟 𝑂𝑓 𝑉𝑖𝑟𝑡𝑢𝑎𝑙 𝑂𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛. 𝑖𝑡𝑠: 𝑉𝑖𝑟𝑡𝑢𝑎𝑙𝑂𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛)
𝑆ℎ𝑎𝑟𝑒𝑑𝐷𝑒𝑣𝑖𝑐𝑒
≡ 𝑠𝑠𝑛: 𝐷𝑒𝑣𝑖𝑐𝑒 ⊓ ∃𝑠ℎ𝑎𝑟𝑒𝑑𝐵𝑦. (𝑖𝑡𝑠: 𝑆𝑡𝑎𝑘𝑒ℎ𝑜𝑙𝑑𝑒𝑟
⊓ ∃𝑚𝑒𝑚𝑏𝑒𝑟 𝑂𝑓 𝑉𝑖𝑟𝑡𝑢𝑎𝑙 𝑂𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛. 𝑖𝑡𝑠: 𝑉𝑖𝑟𝑡𝑢𝑎𝑙𝑂𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛)
𝑆ℎ𝑎𝑟𝑒𝑑𝑅𝑒𝑠𝑜𝑢𝑟𝑐𝑒
≡ (𝑜𝑤𝑙𝑠: 𝑆𝑒𝑟𝑣𝑖𝑐𝑒 ⊔ 𝑠𝑠𝑛: 𝐷𝑒𝑣𝑖𝑐𝑒) ⊓ ∃𝑠ℎ𝑎𝑟𝑒𝑑𝐵𝑦. (𝑖𝑡𝑠: 𝑆𝑡𝑎𝑘𝑒ℎ𝑜𝑙𝑑𝑒𝑟
⊓ ∃𝑚𝑒𝑚𝑏𝑒𝑟 𝑂𝑓 𝑉𝑖𝑟𝑡𝑢𝑎𝑙 𝑂𝑟𝑔𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛. 𝑖𝑡𝑠: 𝑉𝑖𝑟𝑡𝑢𝑎𝑙𝑂𝑟𝑔𝑎𝑛𝑖𝑧𝑎𝑡𝑖𝑜𝑛)
55
Figure 4-9 shows an example of how the integrated ITSoS model represents ITS cyber-physical
components. The knowledge statements indicate that an SSN:Sensor object, Loop_Detector_X,
which is shared by the Ministry of Transportation Ontario (MTO), observes the speed property of
a highway 401 road element. The statements also show that Loop_Dectector_X’s data can be
accessed through the Sensing_Service_Y, which receives startTime and endTime as inputs and
returns trafficData as an output. The knowledge statements also show that the service implements
a functional requirement for the Roadway_Basic _Surveillance equipment package which is to
collect, process, digitise, and send traffic sensor data.
4.7 Validating the ITSoS Ontology
The ITSoS ontology validation focused on the following criteria:
1. The richness of the model, which refers to the ability of the model to cover all the concepts
required to be represented within the domain of interest (Gómez‐Pérez, 2001; Staab &
Studer, 2009). The richness of the model was tested using the competency questions
identified in the second step of the ontology development process.
Sensing_Service_Y
Hwy401_Element 5951398
Functional_ReqCollect, process, digitize, and
send traffic sensor data (speed, volume, and occupancy)
implementsFunctionalRequirement
Roadway Basic Surveillance
definesFunctionalRequirement
MTO shares
Loop_Detector_X
hasSensor
ITS Operations
OTN OWL-S
Selected segment of
highway 401
SSN
Speed
observes
isPropertyOf
Sensing_Service_Y_Profile
presents
startTime
hasInput
endTime
trafficDatahasInput
hasOutput
Figure 4-9 A partial representation of a sensing service using the ITS-CPS ontological
Model
56
The questions were formulated as SPARQL queries and used to examine the ability of the
model to answer these questions. Table 1 shows an example question, its corresponding
query, and its answer. The query formulates the question about the possible outputs of the
“Collect Transit Operations Data” process, which has an IRI of http://one-
its.net/ITS_arch/pspec_6_6_1, by finding all that objects that are connected to this process
using the hasOutFlow relationship (IRI: http://one-its.net/ontologies/oitsp# hasOutFlow).
The query then finds the labels of these flows using the label relationship (IRI:
http://www.w3.org/2000/01/rdf-schema#label). The complete set of SPARQL queries is
shown in tables 1,2,3, and 4, Appendix A.
Table 4-1 Sample SPARQL Query
Question What are the possible outputs of the ‘Collect Transit Operations
Data’ process?
Corresponding
SPARQL Query
SELECT ?OutFlowName
WHERE
{
<http://one-its.net/ITS_arch/pspec_6_2_3>
<http://one-its.net/ontologies/oitsp# hasOutFlow>
?OutFlow .
?OutFlow
<http://www.w3.org/2000/01/rdf-schema#label>
?OutFlowName .
}
Answer OutFlowName
==========================
"transit_data_for_alerts"
"transit_data_for_centres"
"transit_data_for_trip_planning"
…..
2. Consistency, which refers to the possibility of the model to infer contradictory statements
from valid entries (Gómez‐Pérez, 2001). Consistency is automatically checked, using the
Apache Jena OWL reasoner12 and reported using the ValidityReport data structure. The
12
http://jena.apache.org/
57
reasoner uses an rule-based approach to generate the logical consequences of the ontology
axioms and it supports several OWL constructs such as domain, range, subClassOf,
subPropertyOf, and cardinality constructs; and
3. The usability of the model, which refers to the applicability of the model and its ability to
support the common reasoning functionalities at a realistic computational cost (Staab &
Studer, 2009). Usability and computational efficiency were evaluated by using the model
to support the coordination of ITS components to provide traveller information within the
GTA as will be explained in the following Chapters.
Remarks on the Java Implementation of the ITSoS Model
Apache Jena, an open source Java framework, was employed to populate the base ITSoS semantic
model which contains the standardised ITS operations defined by the Canadian ITS architecture.
These operations define 37 user services, 239 equipment packages, 633 processes, 5784 data flows,
and 559 architecture flows comprising 138000 knowledge statements. A user-friendly linked data
front end was implemented using pubby (Cyganiak & Bizer, 2008) to allow stakeholders to
navigate through the stored objects and relationships and assist them in planning their coordinated
ITSoS plans, as will be discussed in Chapter 5. Knowledge statements were stored using the Jena-
TDB triple store which enables the execution of SPARQL queries via the Fuseki SPARQL server.
Figure 4-10 shows a snapshot of an abstract process object, Provide Trip Planning Information to
Traveller, highlighting its label, and associated properties.
Figure 4-10 Knowledge Statements’ Frontend
58
5 Integrated Service Planning (ISP)
The second pillar of the coordination framework is the integrated services planning (ISP), which
allows ITS application providers to design abstract integrated ITSoS operations and specify how
cyber-physical components shall be combined to achieve their designated goals. The ISP involves
establishing a virtual organisation among concerned ITS application providers to collectively build
a consensus on the specifications of their design. Stakeholders define a hierarchy of general ITS
tasks describing the actions, conditions, and constraints governing the outcomes of their ITSoS
operations. This chapter presents a four-step process for creating abstract ITS plans for
collaborative ITS operations and shows how this process can be used to define an interoperable
ITSoS application based on the ATIS example presented in Chapter 3. The chapter also discusses
the implementation and performance evaluation of the service composition module which
transforms these abstract plans into a sequence of services that can be invoked by the ISE engine
of chapter 6.
5.1 Developing abstract ITS Applications Using the Coordination Framework
Using the framework to develop abstract ITS applications involves four main steps, shown in
Figure 5-1. The process begins with identifying the needs and scope of the application by
describing its fundamental characteristics such as relevant stakeholders, main categories of the
provided services, geographic boundaries, and targeted timeframe. Part of this step is to create a
Figure 5-1 Development Process
1) Define the Needs and Scope
2) Determine Key Services and Functional Requirements
3) Develop an Operational Procedure (Task Network Definition)
4) Define Terminators and Interfaces
59
virtual organisation that includes all involved ITS stakeholders participating in the collaboration
process. Members of the ITSoS virtual organisations are provided with a secured workspace,
through the ONE-ITS portal presented in Chapter 6 of this thesis, to study, comment, propose and
evaluate design alternatives. Each community creates a shared file repository where members of
the community can access and contribute technical documents, code samples, case studies and
other content.
The second step of the process is to establish a shared understanding of the fundamental tasks
conducted by the application. In particular, ITS application providers define ITS user services,
equipment packages, processes, and functional requirements that describe the basic structure of
the application. The framework facilitates the use of the linked data front end, presented earlier in
Chapter 4, and SPARQL queries to retreive information about abstract standardised ITS processes
and select these entities that satisfy their goals and objectives. The framewok also allows
stakeholders to extend the architecture by defining their own service requirements and processes
that abstract certain functionalities in their systems and deployments.
The third step of the process constructs the application’s task network which identifies the
dependencies between the different tasks and the order in which these tasks shall be executed. Key
services and functional requirements, identified in the second step, are analysed using a
Hierarchical Task Analysis (HTA) approach (Annett, 2003) to characterise the main tasks and
subtasks that should be considered in the operation. These tasks are organized in a hierarchy that
describes the standardised ITS processes involved in the application, conditions for triggering the
different tasks and processes, and the sequences in which these processes shall be executed. The
resultant task network defines the compound tasks, primitive tasks, decomposition methods,
conditions, and constraints in a form that can be processed by the service composition module
discussed in Section 5.2. Within the scope of this thesis, it is assumed that planners are responsible
for defining and analysing efficient acyclic and totally ordered ITSoS plans that achieve their
planning goals and objectives.
The last step of the process, which can also be conducted in parallel with the third step, defines the
terminators interacting with the application as well as the ITS standards and interfaces that
communicate messages between the consistent components of the ITSoS application. This step
also defines a list of application’s variables that the execution engine shall maintain to provide an
60
integrated ITS service. Defining terminators and interfaces is critical to identify the contractual
obligations of the ITSoS application towards external entities, and obligations of constituent
components towards themselves. Inappropriate identification of the ITS interfaces may have
serious repercussions on the automatic execution of the application and may cause incompatibility
issues among interacting components. The following section describes the four steps using an
ATIS example that is created according to the discussion in Chapter 3.
5.1.1 Planning an ATIS application
5.1.1.1 Identify needs and scope
The following objective, scope, and involved stakeholders were identified for the ITSoS
application:
Objective: The objective of the demonstrating example is to collect real-time traffic,
transit, and other route-related information and use it to provide integrated traveller
information services.
Scope: The operational procedure of the ITSoS application focuses on publicly available
traveller information services which are published in the Greater Toronto Area (GTA)
including the regions of Durham, York, Peel, and Halton in addition to the City of Toronto.
Involved Stakeholders: The case study focuses on the data available from the following
stakeholders: 1) Ministry of Transportation Ontario (MTO), 2) The City of Toronto (COT),
3) Toronto Transit Commission (TTC), 4) York Region Transit (Viva YRT), 5) Go Transit,
5) City of Brampton, 6) City of Burlington, 7) Durham Region Transit, 8) Oakville Transit,
and 9) City of Mississauga.
5.1.1.2 Determine Key Services and Functional Requirements
Abstract services and functional requirements for the application are defined according to the
needs and scope identified in the first step of the planning process. Determination of the key
services starts by choosing a set of standardised or extended user service requirements from the
61
ITSoS knowledge base that captures the needs of the application. These requirements are then used
to select a set of standardised or extended processes satisfying these requirements.
As indicated in Table 5-1, the demonstrating example has three central standardised processes,
defined by the Canadian ITS Architecture, that select multimodal routes (“Provide Multimodal
Route Selection”), collect data about selected routes (“Collect ISP Services Data”), and provide
the aggregated information to travellers (“Provide Traveller Personal Interface”).
Implementations of these processes are the “Infrastructure Provided Trip Planning”, “ISP
Traveller Data Collection” , and “Personal Trip Planning and Route Guidance” equipment
packages which define the functional requirements of these processes. Functional requirements
play a significant role in locating ITS services implementing the application’s processes as will be
explained later in Section 5.2.2. The complete Selected functional requirements and their
corresponding processes are shown in Table 5-2. These requirements were chosen according to
the publicly available data within the GTA.
Table 5-1 Key Services
User Service Requirements
1. “Traveller information module shall provide travellers with Available Services Information on travel,
for their use.”, requirement number 1.1.1.1 as defined by the Canadian ITS Architecture.
2. “Real-time information provided by a traveller information system shall include the current speeds on
specific routes”, requirement number 1.1.2.1.5 as defined by the Canadian ITS Architecture.
3. “Real-time information provided by a traveller information system shall include the current condition of
any road construction”, requirement number 1.1.2.1.3 as defined by the Canadian ITS Architecture.
4. “Traveller information system shall provide users with the latest available schedule adherence
information.”, requirement number 1.1.1.1.3 as defined by the Canadian ITS Architecture.
5. “Traveller information system shall provide the capability for User Access.”, requirement number 1.1.4
as defined by the Canadian ITS Architecture.
Processes
1. “Provide Multimodal Route Selection”, process number 6.6 as defined by the Canadian ITS
Architecture.
2. “Collect ISP Services Data”, process number 6.2 as defined by the Canadian ITS Architecture.
3. “Provide Traveller Personal Interface”, process number 6.8.3.3 as defined by the Canadian ITS
Architecture.
Equipment Packages
62
1. “Infrastructure Provided Trip Planning”
2. “ISP Traveller Data Collection”
3. “Personal Trip Planning and Route Guidance”
Table 5-2 Key Functional Requirements
Process Functional Requirements “Provide Multimodal Route
Selection.” 1- “The centre shall provide the capability to provide specific
pre-trip and enroute directions to travellers (and drivers),
including costs, arrival times, and transfer points.”
2- “The centre shall generate trips based on the use of more
than one mode of transport.”
3- “The centre shall use the preferences and constraints
specified by the traveller in the trip request to select the most
appropriate mode of transport.”
“Collect ISP Services Data” 1- “The centre shall collect, process, and store traffic and
highway condition information, including incident information,
detours and road closures, event information, recommended
routes, and current speeds on specific routes.”
2- “The centre shall collect, process, and store maintenance and
construction information, including scheduled maintenance and
construction work activities and work zone activities.”
3- “The centre shall collect, process, and store transit routes
and schedules, transit transfer options, transit fares, and real-
time schedule adherence information.”
7- “The centre shall collect, process, and store event
information.”
“Provide Traveller Personal
Interface” 1- “The personal traveller interface shall receive traffic
information from a centre and present it to the traveller.”
2- “The personal traveller interface shall receive transit
information from a centre and present it to the traveller.”
3- “The personal traveller interface shall receive event
information from a centre and present it to the traveller.”
4- “The personal traveller interface shall receive evacuation
information from a centre and present it to the traveller.”
5.1.1.3 Develop an Operational Procedure (Domain Definition)
Processes, which are identified in the second step, are organised into a task network, shown in
Figure 5-2, that specifies the operation of the application. The network has three types of nodes:
63
Compound Task nodes, which represents composite operations that require the interaction of
several constituent components; Primitive Task nodes, which represent standardised ITS
processes that can be directly replaced with executable ITS services (actions); and decomposition
methods, which represent the order, conditions, and constraints for decomposing compound tasks.
The formation of the network was guided by the framework suggested by Stanton (Stanton, 2006)
for conducting HTA. Figure 5-2 shows the task network that implements the key services described
above in Section 5.1.1.2, where the left-to-right arrows show the order of execution. The analysis
starts by the stating the overall goal of the application and then iteratively derive the sub-goal task
hierarchy that achieves this goal using the key services identified in the second step of the process.
Compound tasks are decomposed using one or more decomposition methods that specify 1) the
Provide Traveller Information
Collect ISP Services Data
provideInformationToTravellers
provideDynamicInfo
Provide Traveller with Personal Travel InformationProvide Multimodal Route Selection
a) Multimodal Mode Decomposition
Collect Transit Operations Data
b) Real-time Mode Decomposition (Auto Mode)
Collect ISP Services Data
Collect Transit Operations Data
provideTransitDynamicInfo
c) Real-time Mode Decomposition (Transit Mode)
Collect ISP Services Data
provideAutoDynamicInfo
Compound Task
Primitive Task
Collect Traffic Data
Decomposition Method
Collect Traffic Data
Collect Emergency Traveller Data
Collect Emergency Traveller Data
Collect Emergency Traveller Data
Figure 5-2 ATIS Task Network
64
conditions under which the task shall be decomposed, 2) the resulting sub-tasks, and 3) the order
in which these sub-tasks shall be performed.
As Figure 5-2 indicates, the main goal of the application is to “Provide Traveller Information” to
travellers, which is the first level of the hierarchy. The “Provide Traveller Information” task is
analysed, using the “provideInformationToTravellers” method to the three main subtasks:
“Infrastructure Provided Trip Planning”, “ISP Traveller Data Collection”, and “Personal Trip
Planning and Route Guidance”. Analyzing the “ISP Traveller Data Collection” process, as the
only compound task of level-two tasks, produces several processes to collect traffic, transit,
emergency, parking facilities and other miscellaneous traveller information. However, according
to the selected functional requirements in Section 5.1.1.2, the task focuses only on achieving three
subtasks “Collect Traffic Data”, “Collect Emergency Traveller Data”, and “Collect Transit
Operations Data”.
The network, as indicated in Figure 5-2, defines three decomposition methods to analyze the
“Collect ISP Services Data” task: “provideDynamicInfo”, “provideAutoDynamicInfo”, and
“provideTransitDynamicInfo”. The choice of the right method depends on the preferred mode of
the user. The “provideAutoDynamicInfo” decomposition method collects only traffic data if the
proferred mode is the driving mode. The “provideTransitDynamicInfo” decomposition method
collects transit data in case of the transit mode. The “provideDynamicInfo” decomposition collects
both traffic and transit data in case of the multimodal mode.
5.1.1.4 Define Terminators and Interfaces
5.1.1.4.1 Terminators
The application interacts with four main types of external entities: 1) Travellers, which are the end
users of the application; 2) Traffic Management Centre, which provides traffic-related informaion;
3) Transit Management Centre, which provides information related to transit operations; and 4)
Map Update Provider, which provides map data necessary to support routing services. According
to the scope and use cases defined earlier, the application interacts with Ministry of Transportation
Ontario (MTO) and City of Toronto (COT) as traffic management centres; Toronto Transit
Commission (TTC), Ontario's Inter-regional transit system (GO Transit), York Region Transit
(YRT), Brampton Transit, Oakville Transit, Durham Region Transit, Burlington Transit, and
65
Mississauga Transitway (MiWay) as transit management centres; and Open Street Map (OSM) as
the map update provider.
5.1.1.4.2 Interfaces
The application receives users’ requests in the form of a trip_route_request dataflow, which is
defined by the ITS architecture, and returns personal_traveller_information, also defined by the
architecture as an output. The application uses the General Transit Feed Specification (GTFS)13 to
exchange transit routes and schedules, the Protocol-buffer Binary Format (PBF) to exchange map
data, and XML/ JavaScript Object Notation (JSON) to exchange traffic sensors’ data.
Application’s variables are defined as trip_route_request, supplied_route,
traveller_personal_interactive_traffic_data, traveller-personal_interactive_transit_data,
traveller_personal_interactive_incident-information, and personal_traveller_information. A
complete list of the application’s interfaces defining the input and output specifications of each
compoent is shown in Table 5-3. These interfaces will be discussed in more details in section
5.2.3.
Table 5-3 Interfaces
Abstract Process Input Data Flow Output Data Flow
Provide Multimodal
Route Selection
trip_route_request supplied_route
Collect Traffic Data traffic_data_request_from_trip_planning traffic_data_for_
trip_planning
Collect Emergency
Traveller Data
incident_information_request_from_trip
_planning
incident_information_for
_trip_planning
Collect Transit
Operations Data
transit_data_request_from_trip_planning transit_data_for_trip
_planning
Provide Traveller with
Personal Travel
Information
traveller_personal_interactive_traffic_data
traveller_personal_interactive_transit_data
traveller_personal_interactive_incident
_information
personal_traveller
_information
5.2 Implementation of the ITSoS Composer Module
The ITSoS composer module, which is part of the integrated service execution engine discussed
in Chapter 6, transforms the abstract task networks discussed earlier into a sequence of actions that
13
https://developers.google.com/transit/gtfs/reference/
66
realise stakeholders’ objectives. The implementation of the ITSoS composer module relies on the
Hierarchical Task Networks (HTN) planning algorithm which is recommended by several research
studies composition (Hatzi et al., 2012; Ko et al., 2012; Rodriguez-Mier et al., July 2011; Sirin et
al., 2004; Sohrabi & McIlraith, 2010) to perform automatic service, which is described next.
5.2.1 The Hierarchical Task Networks Algorithm
HTN requires to define a description a planning domain that involves the following definitions
originated in (Ghallab et al., 2004) and modified to fit the needs of the coordination framework:
Definition 1: Operator
An operator 𝑜 is represented as an ordered pair 𝑜 = (𝑛𝑎𝑚𝑒(𝑜), 𝑝𝑟𝑒(𝑜)) in which:
• 𝑛𝑎𝑚𝑒(𝑜) is a syntactic expression of the form 𝑛(𝑥1, 𝑥2, … , 𝑥𝑟) specifying a unique name
(n) of the operator and a list of associated parameters(𝑥1, 𝑥2, … , 𝑥𝑟); and
• 𝑝𝑟𝑒 (𝑜) is a set of positive and negative atoms that describe the preconditions required to
be validated before applying the operator.
Definition 2: Compound Task
A compound task 𝑡 is an expression of the form 𝑡(𝑣1, 𝑣2, … . 𝑣𝑘) where 𝑡 is the task identifier and
𝑣1, 𝑣2, … . 𝑣𝑘 is a list of arguments passed as parameters to subtasks.
Definition 2: Primitive Task
A primitive task 𝑝𝑡 is a 4-tuple 𝑝𝑡 = (𝑛𝑎𝑚𝑒(𝑝𝑡), 𝑣(𝑝𝑡), 𝑠(𝑝𝑡), 𝑓(𝑝𝑡)) in which
• 𝑛𝑎𝑚𝑒(𝑝𝑡) is the name of the primitive task;
• 𝑣(𝑝𝑡) is a list of arguments that are required to passed as parameters to the primitive task.
• 𝑠(𝑝𝑡) is a set of variables representing the number of services that should be allocated to
achieve the primitive task. For instance, traffic data collection may require several services
from different traffic centres to update the current speed for each road segment of a
traveller’s itinerary; and
67
• 𝑓(𝑝𝑡) is a set of functional requirements necessary to be satisfied by the ITS service that
implements the primitive task.
Definition 3: Task Network
A task network is an acyclic digraph 𝑤 = (𝑈, 𝐸) in which 𝑈 is a set of task nodes (vertices) and
𝐸 is a set of arcs (ordered pairs of vertices) defining dependencies and ordering constraints of these
tasks.
Definition 4: Decomposition Method
A method is a 4-tuple 𝑚 = (𝑛𝑎𝑚𝑒(𝑚), 𝑡𝑎𝑠𝑘(𝑚), 𝑝𝑟𝑒(𝑚), 𝑠𝑢𝑏𝑛𝑒𝑡𝑤𝑜𝑟𝑘(𝑚)) in which:
• 𝑛𝑎𝑚𝑒(𝑚) is the name of the method;
• 𝑡𝑎𝑠𝑘(𝑚) is the non-primitive task required to be decomposed by the method;
• 𝑝𝑟𝑒(𝑚) is the set of conditions that validate the applicability of the decomposition method,
and;
• 𝑠𝑢𝑏𝑛𝑒𝑡𝑤𝑜𝑟𝑘(𝑚) is the set of subtasks composing task 𝑚.
Definition 6: HTN Planning Problem
An HTN planning problem is a 4-tuple 𝑃 = (𝑠, 𝑤, 𝑂, 𝑀) in which 𝑠 is the initial world state, 𝑤 is
an initial task network, 𝑂 is a set of available operators, and 𝑀 is a set of decomposition methods.
A solution of the planning problem is a list of operators that accomplish the initial task network
𝑤. The planning procedure is totally-ordered if every method belongs to 𝑀 is totally-ordered. The
decomposition of tasks occurs according to Algorithm 5-1.
Inputs of our implementation of the HTN algorithm, are:
68
Algorithm 5-1 HTN planning
69
1. ITS Knowledge Base (KB), which stores the knowledge statements representing the
relationships between the different entities according to the ITSoS ontology.
2. The World State (s), which are the propositions used to validate the network's constraints
and conditions. Initial states are created and maintained by the context management
module, described in Chapter 6, which manages the contextual information from the
distributed ITS sensors and share it among the various ITS applications and process. States
may also change as a result of invoking ITS services during the planning process.
3. Initial Task Network (w), which the overall goal of the application (e.g. Provide Traveller
Information).
4. Set of Methods (M), which are used to decompose compound tasks into their corresponding
subtasks (e.g. provideInformationToTravellers).
Starting with a non-empty initial task network 𝑤, the algorithm recursively and arbitrarily
analyses each task 𝑡 belongs to 𝑤. There are three different cases for t as follows:
If 𝑡 is an operator (an ITS service), the algorithm checks the applicability of the operator
given its preconditions and the state of the world. If the operator is applicable, the algorithm
invokes the service using the service execution engine (discussed in Chapter 6) and
removes it from the task network 𝑤. The state of the world is updated according to the
outputs of this service. The planning process continues using the new state and the new
task network.
If 𝑡 is a primitive task, the algorithm invokes the discovery module, discussed in the
following section, to allocate applicable ITS services that match the targeted functional
requirements. Discovered services are added to the task network as operators that are
required to be invoked.
If 𝑡 is a non-primitive task, the algorithm chooses an applicable HTN decomposition
method to analyze task 𝑡 and decompose it into its constituent sub-tasks. Resultant sub-
tasks are then added to the task network replacing the original task 𝑡.
5.2.2 Discovery Module
70
The objective of the discovery module is to scan the service registry (discussed in Chapter 6) to
allocate applicable ITS services required to satisfy the functional requirements of the general ITS
processes. The service discovery problem is solved using a backtracking algorithm (Russell et al.,
2003) with a set of variables 𝑣1, 𝑣2, … . . , 𝑣𝑛 representing the number of services to be allocated for
each process. Each variable 𝑣𝑖 has a domain of possible services 𝐷𝑆𝑖 that implements different
functional requirements. A service is valid if it does not violate any constraint 𝐶𝑗 belongs to the
Algorithm 5-2 Discovery Algorithm
71
constraints 𝐶 identified by collaborators and if it satisfies all the functional requirements F. As
shown in Algorithm 5-2.
The inputs of the discovery algorithm are:
Knowledge Base (KB), which stores the semantic relationships between the different
entities.
A set of functional requirements (F), which are required to be fulfilled.
The World State (s), which are the propositions representing the state of the world.
A set of Constraints (C), which defines the non-functional requirements that govern the
selection of the services such as accuracy and availability.
A set of variables (V), which represents entities for which services shall be allocated such
as road links and transit lines.
The algorithm systematically scans available services matching the functional requirement for
each variable. If the service is applicable (i.e., the service does not violate any of the conditions
given the current state of the world), the algorithm assigns the service to its corresponding entity.
Otherwise, the algorithm backtracks to check other services. A solution is considered complete if
there is a service allocated to each variable, otherwise the algorithm returns a failure.
5.2.3 Composing the ATIS services
Table 5-4 provide a step-by-step illustration of the service composition module using the ATIS
demonstrating example. Inputs to the module include the knowledge base, the traveller’s
trip_request, the task required to be decomposed (Provide-traveller-information), and the set of
decomposition methods discussed earlier in Section 5.1.1.3. The table shows the process variables
representing world state, the set of tasks to be decomposed (network), selected task to be analysed
or executed, and the action taken by the algorithm.
The application starts with empty variables, shown in step 0:
trip_request, which defines users’ contextual information such as origin, destination,
mode, preferences, constraints, etc.
72
supplied_route, which defines the possible routes to move users from their origins to their
destinations including route segments, route costs, and estimated arrival time.
traveller_personal_interactive_traffic_data, which defines the traffic state of each road
segment in the supplied_route.
traveller_personal_interactive_incident_information, which defines incidents, closures
and detours on each segment of the supplied_route.
traveller_personal_interactive_transit_data, which contains transit-related information
such as the deviations of transit vehicles from their predetermined schedules.
personal_traveller_information, which includes all the information that should be
communicated to travellers including the suggested route, traffic information, closures, and
transit information.
These variables follow the structure of the standardised ITS dataflows, defined by the Canadian
ITS Architecture, and they govern the composition and discovery processes by validating the
conditions and rules controlling the execution of composed services. They are also used to
formulate the parameters needed to invoke ITS services. Values of these variables are determined
by either subscribing to the different events published by the context management module, which
is presented in Chapter 6, or by calling the ITS web services as explained in this example. The
table shows the key data elements in each variable and their hierarchal structure, highlighted by
asterisks.
Upon receiving a request, the composition process starts to analyse initial task network, “Provide-
traveller-information”, and select an applicable method capable of analysing the task and apply
the selected method, provideInformationToTravellers , to decompose that task. Task network is
then updated, in step2, to include an ordered list of the subtasks defined by the decomposition
method. These subtasks are Provide-multimodal-route-selection, Collect-ISP- Services-Data, and
Provide-traveller-with-personal-travel-information. Since the first task, Provide-multimodal-
route-selection, is a primitive task, the algorithm invokes the service discovery module passing
the functional requirements to be implemented. The service discovery module responds by
returning the service satisfying the required functionalities, in this case OTP-planner-web-
73
service14, which is added to the task network. OTP is a multimodal trip planning service that will
be discussed later in Chapter 6.
The algorithm executes the service using the service execution engine, which will be discussed in
Chapter 6, and updates the application’s variables to include the supplied_route returned from the
service. Part of the supplied_route is the route_segment_list variable which provides a list of route
segments for which traffic and transit data shall be collected. The process continued analysing the
Collect-ISP-Services-Data task resulting in the Collect-traffic-data primitive task shown in Step
5. The algorithm invokes the service discovery module passing the appropriate functional
requirements and variables (route_segment_list in this case). The service discovery module
responds by returning is a list of services that implements the required functionality and add them
to the task network. The algorithm continues by executing these services, updating the process
variables, and analysing the rest of tasks until the final output is produced.
Table 5-4 ATIS Composition Using HTN
step Process Variables Network Selected Task Action
0 trip_request (empty)
supplied_route (empty)
traveller_personal_interac
tive_traffic_data (empty)
traveller_personal_interac
tive_transit_data (empty)
traveller_personal_interac
tive_incident_information
(empty)
personal_traveller_inform
ation (empty)
1 trip_request.
*origin.
*destination.
*preferences.
**modes.
**preferred_routes.
*constraints.
**number_of_transfers.
**special_needs.
Provide-traveller-
information.
Provide-traveller-
information.
Decompose the task using
provideInformationToTra
vellers method.
14
http://www.opentripplanner.org/
74
2 trip_request. Provide-multimodal-
route-selection.
Collect-ISP-services-
data
Provide-traveller-with-
personal-travel
information
Provide-
multimodal-route-
selection.
Discover Services the
implements the
provideMultimodalRoute-
Selection process using
the appropriate variables,
constraints, and functional
requirements defined by
the plan.
3 trip_request. OTP-planner-web-
service
Collect-ISP-services-
data
Provide-traveller-with
personal-travel-
information
OTP-planner-web-
service
Execute the service using
the trip_request data flow
and receive
supplied_route as a
response.
Remove the service from
the task list.
4 trip_request.
supplied_route.
* route_statistics.
* route_cost.
* route_list.
** route_segment_list.
*** identity.
*** mode.
***data.
**** start_point.
**** end_point.
****description.
****estimated_arrival_ti
me.
****estimated_travel_tim
e.
Collect-ISP-services-
data
Provide-traveller-
personal-interface
Collect-ISP-
services- data.
Decompose the task using
provideDynamicInfo
method. (assuming that
the user selects a multi-
modal option)
5 trip_request
supplied_route.
Collect-traffic-data.
Collect-emergency-
traveller-data
Collect-transit-
operations- data.
Provide-traveller-
personal-interface
Collect-traffic-data. Discover Services that
implements Collect-
traffic-data using the
appropriate variables,
constraints, and functional
requirements defined by
the plan.
6 trip_request
supplied _route.
GTATrafficService_
(route_segment_1)
GTATrafficService_
(route_segment_2)
….
GtaTrafficService_
(route_segment_n).
GTATrafficService
_ route_segment_1.
Execute the service using
the information of
route_segment_1 and
receive
traffic_data_for_trip_pla
nning as a response.
75
Manage-traffic-
routing.
Collect-transit-
operations- data.
Provide-traveller-
personal-interface
Remove the service from
the task list.
……….
6+n trip_request
supplied _route.
traffic_data_for_trip_plan
_planning (includes a
combined list of all road
segments)
Collect-emergency-
traveller-data
Collect-transit-
operations- data.
Provide-traveller-
personal-interface
Collect-
emergency-
traveller-data
Discover Services that
implement: Collect-
emergency- traveller-data
using the appropriate
variables, constraints, and
functional requirements
defined by the plan.
7+n trip_request
supplied _route.
traffic_data_for_trip_plan
ning
IncidentListInqRq,
route_segment_1.
IncidentListInqRq,
route_segment_n.
Collect-transit-
operations- data.
Provide-traveller-
personal-interface
IncidentListInqRq,
route_segment_1.
Execute the service using
the information of
route_segment_1 and
receive
incident_information_for
_trip_planning as a
response.
Remove the service from
the task list.
……….
8+2n trip_request
supplied _route.
traffic_data_for_trip_plan
_planning.
incident_information_for
_trip_planning (includes a
combined list of all road
segments)
Collect-transit-
operations- data.
Provide-traveller-
personal-interface
Collect-transit-
operations- data.
Discover Services that
implement: Collect-
transit-operations-data
using the appropriate
variables, constraints, and
functional requirements
defined by the plan.
9+2n trip_request
supplied _route.
traffic_data_for_trip_plan
_planning.
incident_information_for
_trip_planning
NextBus service
Provide-traveller-
personal-interface
NextBus service
Execute the service using
the
transit_data_request_fro
m_trip_planning, data
flow and receive
transit_data_for_trip_pla
nning as a response.
Remove the service from
the task list.
76
10+2n trip_request
supplied _route.
traffic_data_for_trip_plan
_planning.
incident_information_for
_trip_planning
transit_data_for_trip_plan
ning
Provide-traveller-
personal-interface
Provide-traveller-
personal-interface
Discover Services that
implement:
Provide-traveller-
personal-interface
11+2n trip_request
supplied _route.
traffic_data_for_trip_plan
_planning.
incident_information_for
_trip_planning
transit_data_for_trip_plan
ning
CreateTravellerInfoRe
sponse
CreateTravellerInf
oResponse
Execute the service using
the
traveller_personal_intera
ctive_traffic_data
traveller_personal_intera
ctive_transit_data
traveller_personal_intera
ctive_incident_informatio
n data flows and receive a
JSON response
(personal_traveller_infor
mation) that includes the
requested traveller
information.
Remove the service from
the task list.
12+2n trip_request
supplied _route.
current_road_network_sta
te.
roadway_detours_and_clo
sures
transit_vehicle_deviations
_details.
personal_traveller_inform
ation.
Produce the output of the
composition process
personal_traveller_infor
mation.
5.3 Computational Performance Evaluation
The performance of the ITSoS composer was evaluated using the standardised task networks
shown in Table 5-5. Although the complexity of the HTN algorithm has been previously analysed
in the literature (Erol et al., 1994; Kambhampati, 1995), this thesis focuses on assessing the
computational performance of the algorithm when being utilised to perform complicated ITS
operations such as these operations defined by the ITS architecture. Experiments were conducted
on an Intel Core i7-2600 processor with 8GB RAM running Linux 3.8.0 kernel (Ubuntu
distribution). The decomposition of each task occurs according to the standardised ITS operations
77
and assuming that all services are running (i.e. no failures). Response time is defined as the average
time taken by the HTN to calculate appropriate response actions. Calculation of the response time
does not reflect the duration required to call and execute the web services. Normalised response
time was obtained by dividing the mean response time by the mean response time needed to
generate a response plan of only one action (last entry of the table). The results show that the
average response time increases as the plan size (number of operators) increases. The algorithm,
as shown in Figure 5-3, is solvable in polynomial time.
The effect of increasing the number of discovery variables (e.g. road elements) was also
investigated to evaluate the performance of the composition framework. Using the standard “Route
Guidance and Navigation” user service, which includes 959 primitive tasks, the number of
discovery variables was changed between 1 and 80. Normalised response time was calculated for
each value. The results, shown in Figure 5-4, indicate that the response time increases linearly as
the number of discovery variables increases. Normalised response time increases about six times
for 80 discovery variables.
Table 5-5 Testing the HTN Planning Algorithm
Initial Task Plan Size Normalised Response
Time
Complete traveller information services 4770 80.64
Pre-trip travel information 1711 53.89
En-route driver information 495 32.72
Route guidance and navigation 959 57.43
Ride matching and reservation 709 47.52
Travel-related services and facilities 1370 50.58
Trip planning service 537 38.21
Provide information on current situational information on
transportation systems
519 45.17
Collect Traffic Data 9 4.58
Collect Highway Traffic information 1 1
78
Figure 5-3 Performance Evaluation of the HTN-based Service Provisioning
Figure 5-4 Response Time as a Function of Discovery Variables
0 20 40 60 80 100
0
1
2
3
4
5
6
7
Number of Variables
Re
spo
nse
Tim
e N
orm
aliz
ed
Effect of Increasing the number of discovery variables
79
6 Integrated Service Execution (ISE)
The last pillar of the coordination framework is the Integrated Service Execution (ISE) pillar which
facilitates the automatic integration of ITSoS operations by providing the infrastructure necessary
to manage the ITS cyber-physical components. The ISE allows stakeholders to add new services
and sensors, link them semantically to their corresponding components in the Canadian ITS
architecture, execute services, and exchange messages and contextual information among the
various components. This chapter discusses the development of the automatic and integrated
service execution engine used to execute the abstract coordinated ITS plans discussed in Chapter
5. The chapter starts by presenting an overview of the service execution engine highlighting its
principle components. The chapter then discusses the context management module which manages
the ITS physical components allowing gathering, processing, and distributing of contextual
information among ITSoS components. The chapter also discusses the implementation of the
service management module which supports the invocation and integration of ITS services (cyber
components). Finally, the chapter discusses the implementation of the Online Network Enabled
Intelligent Transpiration System (ONE-ITS) (Elshenawy et al., 2015a; Elshenawy et al., 2015b)
which serves as a single point of entry allowing end users, ITS service providers, and ITS
application providers to access the SoS applications, share cyber-physical resources, and
collaborate on providing interoperable operations.
6.1 A High-level Overview of the ISE Engine
Users, as shown in Figure 6-1, trigger the ISE engine by sending SoS services’ requests to the
ONE-ITS portal. These requests are forwarded to the corresponding ITSoS composer modules,
previously discussed in Chapter 5, to formulate, based on predefined abstract plans, a sequence of
actions that respond to these requests. The composer formulates these actions using the following
three components:
The context management module, which supports managing ITS physical resources by
offering facilities to gather, process, and dispatch contextual information collected from
ITS sensors. The context management module allows stakeholders to create ITS operations
80
that respond to situational changes in the surrounding environment without worrying about
which sensors shall be selected, how sensors’ data are processed, and how the context is
inferred. An ATIS system, for instance, would need to know the speed on a freeway
segment or on a parallel transit line, without having to be concerned about which sensors
provide such measurement or how they will communicate.
The Service Management module, which provides the functionalities to support managing
ITS services. The service management module introduces a level of abstraction that
provides a uniform and consistent access to the various ITS cyber resources. The module
offers many functionalities that facilitate the automatic invocation of ITS services such as
service registration, message validation, service monitoring, and service versioning. An
ATIS system, for instance, would need to invoke services that preform multimodal trip
Figure 6-1 A High-level Overview of the ISE Engine
81
planning functionalities using a systematic and consistent method that does not depend on
implementation-specific parameters and interfaces.
The Data Mapping/ Transformation module, which manages the communication with
shared resources, whether services or sensors, across the different ITS applications. Data
mapping plays a fundamental role in achieving seamless integration of ITS components by
providing a consistent interface to interact with the various cyber-physical entities. The
data mapping module will be discussed as part of the context management and service
management modules.
The ISE engine uses a shared messaging infrastructure, implemented using the Java Message
Service (JMS)15, which supports creating, sending, and receiving messages among distributed
cyber-physical components. JMS provides a transactional, reliable, and loosely coupled
communication medium that allows ITS cyber components to distribute messages in point-to-point
and publish-subscribe paradigms.
6.2 Context Management
The context management module facilitates sharing contextual information, collected by ITS
sensors, across the different ITSoS applications. The module aggregates sensed information from
registered ITS physical resources and uses it to trigger events that inform subscribed operations
about situational changes such as congestion and road closures. The scope of the context
management implementation in this research focuses on the framework-related functionalities
required to integrate sensors’ observations, link them to the ITSoS entities semantically, and share
collected contextual information among interacting constituent components. Future work can
enhance the context management module further to add functionalities to clean the data, identify
anomalies, capture trends, and recognise patterns, which is beyond the scope of this thesis.
A system administrator adds a new sensor to the SoS by creating a new ssn:Sensor object and
defines the sensor’s associated access parameters. Context gathering necessitates the following
two steps: 1) Mapping sensors’ data, to a unified data format that can be interpreted by the
aggregation and processing modules and 2) Context Annotation, which links sensors’ observation
15
http://docs.oracle.com/javaee/6/
82
semantically to their associated entities in the ITSoS ontological model. The following sections
describe these steps in more details.
6.2.1 Sensors’ Data Mapping
Sensors’ data mapping converts sensors’ data from publishers’ format to a unified format (ISE
sensors’ data format) that can be interpreted by the context management module. The
implementation of the data mapping functionality relies on the smooks16 framework which
supports a broad range of conversion operations such as XML to XML, CSV to XML, and Java to
XML. The framework also supports splitting messages and routeing them to multiple context
acquisition modules. Furthermore, it supports specifying validation rules to ensure that the data is
communicated in a correct format.
An example of data transformation is shown in Example 6-1. The table shows a sample sensor
output published by the Ministry of Transportation Ontario (MTO). The sensor detects passing
vehicles at two adjacent locations using two induction loops and uses the time difference between
the first and second detections to calculate the speed of the vehicle. The example shows part of the
input xml feed which describes the sensor’s outputs at a particular time period. As indicated in the
sensor’s sample input, the feed includes three measurements:
Occ: represents the fraction of the sampling time interval (∆𝑡) during which the sensed
location was occupied by a vehicle
Vol: represents the total number of vehicles (∆𝑁) passing the detector within ∆𝑡.
Spd: represents the average speed of the ∆𝑁 vehicles detected by the sensor.
These measurements are mapped, using the smooks configuration file shown in Example 6-1, into
ISE sensor observations that follow the ITSoS ontological model. As indicated in the sample, the
smooks configuration file uses XSLT (Clark, 1999) to transform xml feeds to corresponding xml
elements that can be interpreted by the ISE engine. As the configuration file shows, measurement
values are mapped into different xml elements that describe the observed property (speed), the unit
of measurement (km/hr), and sampling time interval. The mapping configuration file may also
16
http://www.smooks.org/
83
perform data conversions operation, similar to converting the periodNum value shown in the
example. The context management module uses the IRIs of the observed properties to link them
to their associated entities in the ITSoS knowledge base and hence update the contextual
information. The original input, configuration, and output files are shown in Appendix B, examples
1,2,3.
Example 6-1 Data Mapping/Transformation
Sample Input
<vdsDataSet>
<date>2014-01-15</date>
…. <vdsData>
<vdsId>1410</vdsId>
<contractId>QEWDE0490DWS</contractId>
<validThisPeriod>true</validThisPeriod>
<periodNum>1363</periodNum>
<technology>EVC</technology>
<occ>14</occ>
<vol>29</vol>
<spd>83</spd>
</vdsData>
…..
</vdsDataSet>
Smooks Configuration File
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.0.xsd">
<resource-config selector="vdsDataSet">
<resource type="xsl"> …..
<observation>
<date><xsl:value-of select="$date" /></date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>
<xsl:value-of select="number(periodNum)*20" />
</observation-result-time>
<sensor><xsl:value-of select="contractId" /></sensor>
<property>
http://ITS-CPS.net/transport/property/speed
</property>
<observation-value>
<value><xsl:value-of select="number(spd)" /></value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/speed/km-per-hr
</unit-of-measurement>
</observation-value>
</observation> …..
</resource>
</resource-config>
</smooks-resource-list>
84
Output of Smooks
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>QEWDE0490DWS</sensor>
<property>
http://ITS-CPS.net/transport/property/speed
</property>
<observation-value>
<value>83</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/speed/km-per-hr
</unit-of-measurement>
</observation-value>
</observation>
6.2.2 Context Annotation
Context annotation is the process through which sensors’ observations are linked to the ontological
model. The process attaches collected attributes, resulted from the sensors’ data mapping step, to
their associated entities represented by the ITSoS ontological model such as road elements and
transit routes. The implementation of the context annotation module uses Apache Jena17 to create
and update the knowledge statements describing the various entities interacting with the ITSoS.
The implemented module receives ISE sensors’ observations, produced by the sensors’ data
mapping module, and parses them to create SSN observation objects that describe the features of
interest. Figure 6-2 shows an example of how these observations are represented in the knowledge
base. An SSN observation Y, shown in the figure, is defined by an associated property object
(speed) and an associated sensor object (401DE0040DWE).
The semantic representation of sensors’ observations facilitates the use of semantic rules to infer
additional implicit relationships about sensor observations. An example of these relations is the
featureOfInterset property, shown as dashed line in Figure 6-2, which links any observation o,
observed by sensor s, to its associated infrastructural element f. The rule-based reasoning can infer
such property using the following rule:
17
https://jena.apache.org/
85
𝑓𝑒𝑎𝑡𝑢𝑟𝑒𝑂𝑓𝐼𝑛𝑡𝑒𝑟𝑒𝑠𝑡(𝑜, 𝑓) ← 𝑜𝑏𝑠𝑒𝑟𝑣𝑒𝑑𝐵𝑦(𝑜, 𝑥) ∧ 𝑜𝑓𝐹𝑒𝑎𝑡𝑢𝑟𝑒(𝑥, 𝑓)
The current implementation supports receiving sensors’ data in XML or JSON formats. Raw data
is transformed, using the mapping configuration files, and processed to generate contextual
attributes describing the various entities of the ITSoS system. Data is stored in temporary files for
specific periods, defined by the retention policy, to create hourly or daily aggregates. Raw data
SSN_Sensor: 401DE0040DWE
OTN_RoadElement: Element_X
OTN_Junction:Node_Y
OTN_Junction:Node_Z
otn:ends_at
OTN_Road:401-Highway
otn:contains
otn:direction_of_ traffic_flow
otn:starts-at
derived explicit
Positive Direction
attribute node
Longitude_Value
Latitude_Value
lon
gitu
de
latitude
SSN_Property: Speed
ssn:ofFeature
SSN_Observation: Speed_Observation_Y
ssn:observedBy
featureOfInterest
ssn:observedProperty
ssn:isPropertyOf
xxxxxobservationResultTime
SSN_SensorOutput:Sensor_output_Z
observationResult
hasValue xxxxxx
Figure 6-2 An Annotation Example
86
files are then compressed and archived for future reference. The context management module
supports distributing sensors’ observation, via JMS, using a publish-subscribe paradigm. The
context management module was used to collect information from the following sensors:
Loop detector data collected by the Ministry of Transportation Ontario and City of
Toronto: The data monitors some of the major highways in Ontario such as 400, 401, 404,
and QEW in addition to the Don Valley Parkway (DVP), Gardiner and Lakeshore
expressways. Sensors’ observations are preprocessed, using a moving average algorithm,
and used to characterise the state of highway elements by calculating the flow, speed, and
density. Registered sensors are shown in Figures B-1 and B-2, Appendix B. Samples of
their actual and preprocessed data is shown in Figures B-3, B-4.
GPS data produced by end users: The GPS data is collected from the users’ devices to
determine their current location. A sample vehicle trajectory is shown in Figure B-5,
Appendix B.
On-board diagnostic (OBD) Units data produced by users’ vehicles: Using an OBD
interface (ELM327 module), shown in Figure 6-3, allows the characterisation of additional
contextual information about vehicles such as vehicle speed, altitude, throttle position,
ambient temperature, and fuel consumption. The data is collected from a mobile
application that is connected, via Bluetooth, to an on-board diagnostic (OBD) unit installed
of users’ vehicles. A sample of the collected data is shown in Figure B-6, Appendix B.
Figure 6-3 On-board diagnostic (OBD) Units data
87
Incident data produced by the Ministry of Transportation Ontario: The data source provides
timely information about incidents in the Greater Toronto Areas such as location, start time,
and impact. A sample data is shown in Figure B-7, Appendix B.
Real-time Next Vehicle Arrival (NVAS) produced by the Toronto Transit Commission
(TTC): The data provides real-time information about transit vehicles such as current
location of a vehicle, expected arrival time of next vehicle at a transit stop, and average
waiting time at transit stops. A sample data is shown in Figure B-8, Appendix B.
6.3 Service Management
The service management module employs open standards such as SOAP and WSDL to provide a
uniform access to cyber resources supporting their automatic integration. Service management
offers different functionalities to control the execution of published ITS services allowing a
reliable request/response communication when invoking the services. The following sections
illustrate these functionalities of the service management modules highlighting their role in the
three-pillar framework.
6.3.1 Service Registry
A key functionality of the service management layer is the service registry which keeps track of
published ITS services and their communication channels (endpoints) to support their automatic
discovery and composition as discussed earlier in Chapter 5. Examples of OWL-S representations
are discussed in Sections 4.5.2.1 and 4.6. The registry allows stakeholders to publish and advertise
their services in an OWL-S format defining their profile, service grounding, and model. Services
are published by creating XML files that describe these services and their associated properties.
The registry module parses input XML files and generate the knowledge statements describing
these services.
The service registry defines some constraints that constituent services should meet to be part of
the ITSoS. These requirements ensure the ability of these services to interact, share information
and function effectively within the ITSoS. These requirements are:
88
1. Constituent ITSoS service must be associated with at least one functional requirement
using the satisfiesFunctionalRequirement property to connect it to one or more
standardised or extended ITS operations.
2. Inputs and outputs of constituent services must be mapped onto abstract ITSoS data flows
as defined by the ITSoS ontological model. Data mapping and transformation can be
performed using the smooks framework, as described earlier in Section 6.2.1, or by using
a wrapping action as it will be illustrated later when discussing the service invocation
module.
3. Constituent ITSoS services must use the same representation to describe the transportation
networks and any external SoS objects that interact with the ITSoS transportation networks.
For instance, the ITSoS proof-of-concept, described in Section 6.5.2, requires all
constituent services to use open street maps to describe traffic networks and GTFS to
describe transit networks.
6.3.2 Service Invocation
A second functionality of the service management layer is the service invocation which facilitates
the automatic execution of coordinated SoS plans by defining a uniform and protocol-independent
method for accessing heterogenous ITS services. The implementation of the invocation component
relies on the JBoss Enterprise Service Bus (ESB) 18 to provide the messaging infrastructure
necessary to enable such invocation. 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.
Each ITS service is wrapped as an ESB service that processes shared ESB messages through a
series of predefined actions known as action pipeline. The pipeline performs data transformation
operations to convert services’ inputs and outputs from publishers’ format to standardised data
flows that can be interpreted by the ITSoS composer. Example 6-2 shows an ESB wrapper of the
GTAStopsService which retrieves information about transit stops in the Greater Toronto Area. The
example shows the original Web Application Description Language (WADL) file describing the
18
http://jbossesb.jboss.org/
89
service and the corresponding ESB wrapper used in the ISE engine. The ESB uses the service
name (GTAStopsService), category (GTATransitService), and endpoints (transitGTAWebService)
to register the service in the service registry. The WSDL file describing the wrapping ESB service
is shown in Example 4, Appendix B.
As the example indicates, the service wrapper defines a message listener to receive invocation
messages from the ITSoS composer. The ITSoS composer invokes services 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 invocation processing action (GTAWSListenerAction). The action
processes the service request, calls the service, receives the output, and converts it to the
standardised ITS data flow that can be interpreted by ITSoS applications. To access a service, the
ITSoS composer issues a SOAP request, such as the request shown in Example 6-3. The ESB
receives the request and begins to verify WS-Security entries in the SOAP message using the
UsernameToken. If the WS-Security is verified, the ESB forwards the SOAP request to targeted
ITS service, which processes this request to produce the designated output.
Example 6-2 JBossESB Service Definition
Original Service Description (WADL file)
<application xmlns="http://wadl.dev.java.net/2009/02">
<doc xmlns:jersey="http://jersey.java.net/"
jersey:generatedBy="Jersey: 2.0-SNAPSHOT ${buildNumber}"/>
<resources base="http://www.one-its.net">
<resource path="otp/routers/gta/index/stops/{id}">
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" type="xs:int"
style="template" name="stopId"/>
<method name="GET" id="getStop">
<request/>
<response status="200">
<representation mediaType="application/json" />
</response>
</method>
....
</resource>
</resources>
</application>
ESB Wrapper (jboss-esb.xml)
90
<services>
<service
category="GTATransitService"
name="GTAStopsService"
description="Retrieves stored information about transit stops in the GTA
area">
<security moduleName="JBossWS"/>
<listeners>
<jms-listener name="transitGTAWebService"
busidref="transitGTATransitEsbChannel"
maxThreads="1"
/>
</listeners>
<actions inXsd="/request.xsd" outXsd="/response.xsd"
faultXsd="/fault.xsd" validate="true">
<action name="request-transform"
class="org.jboss.soa.esb.smooks.SmooksAction">
<property name="smooksConfig" value="/smooks-res.xml" />
</action>
<action name="action"
class="org.its.transit.stops.gta.GTAWSListenerAction"
process="processRequest"/>
</actions>
</service>
</services>
Example 6-3 SOAP Request
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:its="http://www.one-its.net/its"
xmlns:par="http://www.one-its.net/parameter"
xmlns:ptype="http://www.one-its.net/parameter-type">
<soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/oasis-wss-
wssecurity-secext-1.1.xsd">
<wsse:UsernameToken>
<wsse:Username>user</wsse:Username>
<wsse:Password>userPwd</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<its:inputs>
<ptype:transitStop>
<ptype:id>4:2313</ptype:id>
</ptype:transitStop>
</its:inputs>
</soap:Body>
</soap:Envelope>
6.3.3 Message Validation
91
A third functionality of the service management layer is the message validation which offers the
assertion mechanism required to validate the XML messages at the entry points of the ITSoS
constituent components. Message validation increases the flexibility and reliability of the
integrated ITS applications by forcing communicated XML messages to conform to specific XML
schema. Example 6-4 shows a message validation example of an incident retrieval service,
IncidentListInqRq, which is developed as part of the proof-of concept prototype discussed in
Section 6.5.2. ITS service providers define the validation XSD19 schemas, request.xsd and
response.xsd in this example, which are used to validate the attributes of the XML messages
communicated to and from the service. XML schemas define the data types, minimum and
maximum number of occurrences, the length of string values, enumerations, and upper and lower
limit of numerical values.
Example 6-4 Message Validation
ESB Configuration ( jboss-esb.xml)
<service
category="ITSIncidentServices"
name="IncidentListService"
description="Retrieves a list of road incident ">
…
<actions inXsd="/request.xsd" outXsd="/response.xsd" faultXsd="/fault.xsd" validate="true">
….
</actions>
</service>
XML Schema Definition (request.xsd)
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema id="IncidentUpdateInq"
xmlns="http://oneits.net/schemas/messages"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="http://oneits.net/schemas/messages"
targetNamespace="http://oneits.net/schemas/messages"
elementFormDefault="qualified">
<xs:include schemaLocation="PayloadTypes.xsd" />
<xs:element name="IncidentListInqRq">
<xs:complexType>
<xs:sequence>
<xs:element name="RegionId" type="xs:long" minOccurs="0" maxOccurs="1" />
<xs:element name="StartDttm" type="soaDateTime" minOccurs="0" maxOccurs="1" />
<xs:element name="EndDttm" type="soaDateTime" minOccurs="0" maxOccurs="1" />
<xs:element name="Type" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="Impact" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="StartNbr" type="xs:int" minOccurs="0" maxOccurs="1" />
<xs:element name="PageSize" type="xs:int" minOccurs="0" maxOccurs="1" />
<xs:element name="SortBy" type="xs:string" minOccurs="0" maxOccurs="1" />
19
https://www.w3.org/TR/xmlschema11-1/
92
<xs:element name="SortAscendant" type="xs:boolean" minOccurs="0" maxOccurs="1"
/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
6.3.4 Other Functionalities
Other functionalities include service monitoring and versioning which improve the governance of
ITSoS applications by managing the changes in the distributed ITS services. Service monitoring
collects usage information such as average processing time, number of requests, number of failed
messages, and average response time. The implementation relies on JBossESB to collect these
attributes and uses it in combination with customer ratings to determine the quality of the managed
services and hence improve their selection for integrated ITS operations. A screenshot of the
monitoring tool is shown in Appendix B, Example 5.
Service versioning manages the changes in the deployed services from one interface to another by
assuring that the service produces an appropriate response for old and new requests. Change
management is implemented by adding an ESB SOAPProxy action combined with a
transformation action and a content-based routeing action to the ESB wrapping service. The
SOAPProxy action supports loose coupling between services and their consumers by offering an
indirect way to access the service allowing the transformation of SOAP messages to an appropriate
format that can be processed by the service. Content-based routing (CBR) actions allow routing
SOAP messages to their appropriate destinations based on the content of these messages.
6.4 Service Portal
The ONE-ITS portal offers a uniform access to the ITSoS functionalities by allowing end users to
send requests and receive responses from the different ITSoS components. The portal leverages
LIFERAY20, an open source Java-based system, to provide authentication, personalization, and
content aggregation capabilities. ONE-ITS adopts a comprehensive security model, based on a
hierarchy of roles, to provide access control to information, resources and content shared by users
and providers. The portal provides a secure space to communicate, share resources, and collaborate
20
https://www.liferay.com/
93
on planning abstraction ITS plans. Furthermore, it acts as an interface to the ITS service providers
that allows them register their services and sensors and add them to the SoS.
Each page embeds some applications (portlets) that can be dynamically added by the page
administrator. Administrators can also customise portlets by changing their locations, background
colours, text styles, etc. Also, administrators can configure each portlet to allow different groups
of users to use it in different ways. All ONE-ITS portlets are 100% compliant implementations of
the Java Portlet Specification 2.0, JSR-286 (Hepper, 2008), and hence they can be managed by
any portlet container supporting this specification. Figure 6-4 shows the structure of the portal’s
pages.
ONE-ITS offers a diverse number of collaboration tools such as blogs, wikis, message boards,
chats, and instant messages that support building a community of interest among ITS collaborators.
Figure 6-4 A Sample ONE-ITS Portal Page
94
Users, who contribute to the community, have personalised accounts and profiles that hold their
personal identifiers such as a description of the user, the user's attributes, and photos (avatars), as
well as their professional profile including industrial technology experience, education and
technical interests. Community users can also create a personal page with vanity URL where they
can post content. They can also have file repositories for storing their contributed content. ONE-
ITS also includes other portlets that provide ITS cyber-physical management functionalities such
as adding, deleting, and monitoring sensors and services. Screenshots of the ONE-ITS portal is
shown in Appendix B- Figures 9, 10, 11.
6.5 Evaluation of the Coordination Framework
The evaluation of the coordination framework consists of two main activities. First, the
components of the framework were verified against the ITSoS requirements, presented in Chapter
3, to show the ability of these components to provide satisfactory solutions to the fundamental
challenges of ITSoS. Second, a proof-of-concept prototype has been implemented to demonstrate,
in principle, the feasibility and applicability of the framework and to verify that the framework can
implement ITSoS applications successfully.
6.5.1 Assessing the Framework Components against the ITSoS Requirements
The institutional, operational, and communication requirements for an ITSoS were checked, as
summarized and indicated in Table 6-1, against the principle components of the framework to
ensure that all the ITSoS requirements have been taken into consideration. The analysis shows
that all the requirements are implemented by one or more components of the framework, as
indicated in the following discussion:
The ITSoS ontology implements requirements 1.1 and 2.1 by defining the Ontology for
abstract ITS processes, defined in Section 4.5.1, along with the OWL-S and SSN
ontologies. Using these three ontologies, the ITSoS ontology provides the capability to
represent generalised ITSoS processes, their characteristics, and their associated ITS
components. Furthermore, the ITSoS ontology assists in achieving requirements 3.1 and
3.4 by defining the concepts required to share contextual information about infrastructural
95
elements of the transportation networks and how this information is related to the
interacting cyber-physical components.
The Hierarchical Task Analysis and the ITSoS composer provide the functionalities
required to define the operating procedure of integrated SoS applications and specify the
conditions that govern the dynamic behaviour of these applications. The two components
satisfy the ITSoS requirements 1.3, 1.4, and 2.3 by defining a consistent mechanism to
analyse, define, and execute SoS applications. The ITSoS composer also plays a significant
Table 6-1 Framework Components versus the ITSoS Requirements
Req
uir
emen
t
ITSo
S O
nto
logy
Hie
rarc
hic
al T
ask
An
alys
is
ITSo
S C
om
po
ser
Serv
ice
Dis
cove
ry
Co
nte
xt M
anag
emen
t
Serv
ice
Reg
istr
y
Serv
ice
Invo
cati
on
Mes
sage
Val
idat
ion
Mes
sagi
ng
Infr
astr
uct
ure
Dat
a M
app
ing
and
Tra
nsf
orm
atio
n
ON
E-IT
S P
ort
al
1.1
1.2
1.3
1.4
1.5
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.4
96
role in implementing requirements 2.4 and 3.3 by orchestrating the execution of the
distributed services involved in the ITSoS processes.
The ISE components (columns 4 to 10 in Table 6-1) offer the functionalities required to
implement requirements 2.2 and 2.4 by facilitating the discovery and integration of
decentralised ITSoS services, and by providing the message validation and transformation
functionalities needed for an effective interaction among these services. These components
also support the communication requirements 3.1, 3.2, 3.3, and 3.4 by offering the
messaging functionalities necessary to comply with these requirements.
The ONE-ITS portal implements the institutional requirement 1.2 by creating a secure
workspace, using a set of social portlets that allow stakeholders collaborate on the design
of their SoS applications. Furthermore, the portal in association with the service registry
component offer a consistent mechanism to publish and advertise services, and hence they
satisfy the institutional requirement 1.5. Finally, the ONE-ITS portal satisfies the
operational requirement 2.4 by exposing ITSoS integrated services’ endpoints.
6.5.2 Implementation of a Culminating Proof-of-Concept ATIS Prototype
A proof-of-concept prototype has been implemented to show the applicability of the framework
and to demonstrate its feasibility. The prototype uses the following services, also shown in Table
6-2, to implement the ATIS hierarchy of tasks discussed in Section 5.1.1:
The GTAPlannerService is a REST service, defined within the Open Trip Planner (OTP)
open source platform, that satisfies the three functional requirements, identified in Section
5.1.1.2, that are needed to perform the “Provide Multimodal Route Selection” process.
The IncidentListInqRq is a SOAP service, implemented within the ONE-ITS platform, that
collects planned and unplanned incidents’ information using the MTO open data21
published on the Ontario Government website.
21
https://www.ontario.ca/search/data-catalogue
97
The GTATrafficService is a service provided by the ONE-ITS portal that provides
information about the current speed on the GTA road segments. The service returns the
maximum allowable speed if no sensors are available.
The NextBusScheduleService is a NextBus service that returns the schedule information
for transit routes.
The GTAStopsService is an OTP service that provides information about transit stops such
as name, longitude, latitude, and transit vehicle type.
The NextBusPredictionsService is a NextBus service that predicts next bus arrival time at
transit stops.
Using the three-pillar framework to create an ITSoS application that integrates these services
involves the following steps:
1) Preparation of the distributed ATIS services:
Preparation of the ATIS services includes 1) the configuration of an OTP instance by loading the
street network, available from Open Street Map22, and transit networks, available from the transit
agencies identified in Section 5.1.1.1 such as TTC, YRT, and GO Transit, and 2) the
implementation of the ONE-ITS services to support the functionalities described earlier in Table
6-2. These services were implemented using the contract-first design approach in which services
are built by creating WSDL contracts as a first implementation step. Implementation steps are:
1. Defining XML messages: The structure of the XML messages communicated from and to
the service were defined as XML schema documents.
2. Defining a service Contract: Services’ contracts were defined as WSDL files, similar to
the one shown in Appendix B-Example 4.
22
http://www.openstreetmap.org/
98
3. Implementation of Services’ Endpoints: An endpoint is a java class, annotated using
@Endpoint annotation, that defines one or more methods to handle services’ requests. An
example of an endpoint is shown in Appendix B-Example 6.
4. Publishing the web service: A Web application ARchive (war) file is generated and
published on the ONE-ITS portal.
2) Creation of the ESB Wrappers:
Each service is wrapped as an ESB service, as explained earlier in Section 6.3.2, that defines
actions to transform and validate the data sent to, or received from the service. This step involves
defining the mapping configuration file needed to transform the inputs and outputs of each service
into standardised data flows that can be interpreted by the ITSoS. Table 6-3 and Table 6-4 shows
the mapping of the inputs and outputs of the GTAPlannerService.
Table 6-3 Mapping the Inputs of the GTAPlannerService
Conceptual data model (trip_route_request) OTP Interface
origin fromPlace
destination toPlace
Table 6-2 Key Services Used in the Proof-of-Concept Prototype Implementation
Service ITS Abstract Process Provider
GTAPlannerService Provide Multimodal Route
Selection
Open Trip Planner
(http://www.opentripplanner.org/)
IncidentListInqRq Collect Emergency Traveller
Data
ONE-ITS (http://www.one-its.net)
GTATrafficService Collect Traffic Data ONE-ITS (http://www.one-its.net)
NextBusMessagesService Collect Transit Operations Data NextBus
(http://www.nextbus.com/)
GTAStopsService Collect Transit Operations Data Open Trip Planner
NextBusPredictionsService Collect Transit Operations Data NextBus
(http://www.nextbus.com/)
99
departure_time time
arriveBy= false
desired_arrival_time time
arriveBy= true
preferences
preferred_routes preferredRoutes
modes mode
constraints
constraint_on_number_of_transfers maxTransfers
constraint_on_special_needs Wheelchair
Table 6-4 Mapping the Outputs of the GTAPlannerService
Conceptual data model (supplied_route) OTP Interface
route_cost duration
route ↔ itineraries
route_start_time startTime
route_statistics walkTime
transitTime
waitingTime
walkDistance
transfers
route_segment ↔ legs
route_segment_mode Mode
route_segment_data
route_segment_start_point from
route_segment_end_point to
route_segment_estimated_travel_time duration
route_segment_description Steps
route_segment_report_position_points legGeometry
100
3) Service Registry:
The ATIS services were defined as OWL-S entities, as discussed earlier in Section 6.3.1, that
formally represent their characteristics and associated functional requirements. The semantic
representation of these service facilitates their automatic discovery as discussed in Section 5.2.2.
4) Implementation of the ITSoS Composer:
The ITSoS composer implements the HTN and service discovery algorithms discussed in Chapter
5 to orchestrate the automatic execution of the ATIS services and produce the final output of the
SoS operation. The composer was implemented as a service that accepts users’ requests in the form
of a trip_route_request dataflow and returns personal_traveller_information as an output. The
ATIS application was tested using different set of inputs, depicted in Table 6-5, to demonstrate
the applicability and adaptability of the framework. The table shows the services executed in
response to car, transit, and multi-modal requests.
Concluding Remark
Based on the above self-evaluation and prototype implementation, the ITSoS platform provides a
comprehensive 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. Further, the ITSoS platform enables the collaborating stakeholders to
extend their services beyond the Canadian ITS architecture as their needs may require, a capability
that is new in the ITS domain. 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 ITSoS methodology and platform
developed in this research. Populating more applications in the ITSoS is the subject of ongoing
funded research at the University of Toronto that will conclude in 2019.
101
Table 6-5 Testing the ATIS Application
Request Services Route (by the OTP service)
origin = 43.77010, -79.39596
destination = 43.65968, -79.43184
Modes = CAR
GTAPlannerService
Network Entities
Elmwood Avenue - West
Wilfred Avenue – South
Sheppard Avenue East- East
Bayview Avenue – South
Highway 401 Collectors-
Southwest
Allen Road – South
Eglinton Avenue West-
West
Winona Drive - South
Lanark Avenue – West
Oakwood Avenue – South
Davenport Road – West
Dupont Street – West
Westmoreland Avenue –
South
Bloor Street West -West
Rusholme Road – South
Hepbourne Street -West
Havelock Street - North
Services:
GTATrafficService
IncidentListInqRq
102
origin =43.81967, -79.33022
destination =43.65943, -79.38789
Modes = WALK, TRANSIT
GTAPlannerService
Network Entities
TTC (route 53)
StopId="10138" (Steeles
Ave East at Ferrier St)
TTC (Line 1)
Stop Id= “14111” (Finch
Station - Southbound
Platform)
Services:
NextBusMessagesService
(for routes 53, 1)
GTAStopsService (for
stops 10138, 14111)
NextBusPredictionsService
(for stops 10138, 14111)
origin =43.80257, -79.39476
destination =43.68674, -79.39991
mode=CAR_PARK,WALK,TRANSIT
GTAPlannerService
Network Entities
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)
Services:
GTATrafficService
IncidentListInqRq
NextBusMessagesService
(for route 1)
GTAStopsService (stop
Number: 14111)
NextBusPredictionsService
(Stop Number: 14111)
103
7 Conclusions
The development of comprehensive, multimodal, and multi-jurisdictional ITS operations is a
complex process that involves the integration of multiple heterogeneous ITS resources owned and
maintained by several transportation stakeholders. Enabling such development through large
monolithic systems is laborious, expensive and encompasses several technical and managerial
complexities. Therefore, there is an urgent need to facilitate the design and implementation of
interconnected ITSoS that achieves the synergy among existing cyber-physical ITS components
and offers a more efficient and cost-effective alternative to large monolithic systems. The ITSoS
shall embrace efficient coordination mechanisms that allow the automatic selection and execution
of ITS components while overcoming the interoperability, communication and collaboration
barriers typically involved in such coordination.
Recent coordination efforts focus on using ITS standards and the national ITS architecture to guide
the planning and design of interoperable regional ITS operations. These efforts, however, provide
limited automation capabilities to support the automatic formulation of integrated ITSoS
applications. Current coordination mechanisms lack the existence of systematic and consistent
methods by which stakeholders can expose their existing resources, specify the characteristics of
their applications, and integrate dispersed cyber-physical ITS components. As a result, current
implementations of interoperable ITS applications employ ad hoc one-off procedures with limited
support for extensibility and adaptability. Further, the automation of formulating and executing
ITSoS is becoming increasingly important in the era of Internet of Things (IoT), smart cities and
the evolution of the concepts and applications of transportation as a service (TaaS), which all have
in the common the need for integrating extensive arrays of sensors and sensory information,
knowledge, and online services. In such contexts, a large monolithic ITS operation is out of the
question and an approach to integrate and extend existing resources into a SoS is paramount.
This research 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 components through three complementary pillars of operation that address the
needs for semantic interoperability, coordinated planning, and automatic integration. These pillars
are the Ontological Semantic Knowledge Representation (OSKR), the Integrated Service Planning
(ISP), and the Integrated Service Execution (ISE).
104
The OSKR pillar formally represents shared concepts and relationships within the ITSoS by
defining a reference four-tier ontological model, guided by the Canadian ITS architecture, to act
as a common language among ITS stakeholders and ITS services. The model employs four main
ontologies to represent the various entities and relationships within the ITSoS: 1) the ontology for
abstract ITS processes which formally represent the general functionalities performed by the
ITSoS as defined by the Canadian ITS Architecture; 2) the SSN which formally represent ITS
sensors; 3) the OWL-S which represents ITS services, and 4) OTN which represents road and
transit networks. OSKR, in essence, provides a machine-consumable semantic knowledge base of
ITS.
The ISP pillar employs HTA to allow stakeholders to specify their ITSoS applications including
their objectives, main procedures, shared messages, and the rules and policies governing the
execution of these applications. Collaborators use abstract ITS processes and functional
requirements, represented by the OSKR, to construct a hierarchy of tasks that achieve their
designated goals. Using the ISP to create abstract ITS plans involves four fundamental steps that
define the 1) needs and scope; 2) key services and functional requirements; 3) operational
procedure; and 4) terminators and interfaces.
The ISE pillar defines the functionalities required to orchestrate, discover, and monitor cyber-
physical resources that transform the abstract plans created by the ISP into a sequence of actions
that respond to users’ requests and situational changes. In particular, the ISE defines the
functionalities required to: 1) analyse the abstract plans into their primitive functional
requirements; 2) discover corresponding ITS resources that satisfy these requirements; and 3)
coordinate the ordering and execution of discovered ITS services to produce an output that
achieves the stakeholders’ objectives. The framework relies on the functionalities offered by the
ISE pillar to keep track of existing cyber-physical resources, how these resources are related to
abstract ITS processes, and how messages are communicated among the heterogeneous resources.
7.1 Major Findings
The ITS standards define the data structures and messaging protocols required to share information
among heterogeneous ITS cyber-physical resources. Hence, they provide a solution to the
syntactical barriers of achieving interoperability within an ITSoS. ITS standards, however, do not
overcome the semantic interoperability barriers that hinder the ability of the ITSoS to dynamically
105
compose its constituent components and interpret the various interactions and shared messages
among these components. Dynamic composition of ITS cyber-physical is a necessity to guarantee
the operational and managerial independence property of SoS elements while satisfying the overall
goal of the system.
The ITS architecture describes the main services, abstract processes, and physical equipment that
represent the constituent components of an ITSoS. The architecture, however, does not define
mechanisms by which actual ITS implementations and deployments can be associated with the
general procedures defined by the architecture. Therefore, there is a gap between the general
processes, as represented by the architecture, and the real processes developed by the
transportation jurisdictions and municipalities. Such a gap precludes the ability to use the
architecture in the planning of ITSoS applications and requires novel mechanisms to construct
plans that dynamically integrate existing cyber-physical resources.
The development of ITSoS applications requires several institutional, operational, and
communication requirements that assures the operational and managerial independence of
constituent components while maintaining the evolutionary nature of the system. Enabling such
SoS requires 1) a common model that formally represent involved cyber-physical components,
their interactions and relationships, and the functional models of the system; 2) a consistent method
by which stakeholders can use the reference model to define and adjust abstract ITSoS plans that
characterise stakeholders’ applications and their procedures; 3) a mechanism that executes abstract
ITSoS plans by composing and coordinating their constituent cyber-physical components.
The thesis suggests the use of semantic web technologies and OWL-DL to describe the classes and
properties of the ITSoS reference model and to support semantic annotation of distributed cyber-
physical resources to link them to their corresponding functionalities and processes defined by the
model. The thesis also suggests a four-tier reference model that acts as a common language
between collaborators to describe the operation of their coordinated ITSoS applications. The four-
tier model describes the abstract ITS processes used to define the general ITSoS plans, the web
services performing the processing functionalities, the sensors collecting the contextual data, and
the road and transit network within the scope of the application. Although the creation of a
comprehensive ontology that formally represents all the entities within the ITSoS domain is
106
beyond the scope of this thesis, the presented concepts and relationships represent the basic
constructs necessary to create ITSoS coordination plans.
The thesis illustrates, using an ATIS example, a methodology to construct coordinated abstract
plans using the ITSoS reference model. The presented methodology relies on HTA to provide a
consistent mechanism that identifies the goals, sub-goals, tasks, and conditions that characterise
the operational procedure of the ITSoS applications. Using HTA to define coordinated ITSoS plans
results in a formal description of the application that can be analysed and executed automatically
using the HTN planning algorithm, which is a tractable algorithm that runs in polynomial time.
The algorithm was employed to implement an ITSoS service composer module that analyses
ITSoS plans, discover services that implement these plans, and execute these services to generate
the final response of the application.
Finally, the thesis presents the architecture of the service execution engine, which supports the
automatic realisation of abstract ITSoS plans. A fundamental component in this architecture is the
service management module, which keeps track of existing services and provides the
functionalities necessary for their discovery and invocation such as service registry, message
validation, message routeing and service monitoring. Another key component is the context
management module, which gathers, processes, and dispatches ITSoS contextual information
among distributed services to support the dynamic formulation of ITSoS processes that respond to
certain situational changes such as congestions and road closures. The thesis discusses the key
functionalities of the service execution engine and demonstrates a possible implementation of
these modules.
7.2 Research Contributions
The main contributions of this thesis are the envisioning and provisioning of:
A three-pillar framework to support the planning and automatic execution of ITSoS
applications that merge independent and distributed ITS components, adapt to situational
and operational changes, and have the capability to grow over time. The thesis defines the
requirements for such framework and identifies the principle components that implement
these requirements.
107
An four-tier ontological model, based on the Canadian ITS Architecture, that semantically
interlinks abstract ITS processes, services, sensors, and infrastructural elements and creates
a reference model that formally describes the relationships among these entities in a
machine-understandable format. The thesis discusses the development of the model’s
ontology identifying the objectives, external ontologies, and integration steps. The model
formally captures the standardised ITS processes defined by the architecture and use them
to find the relationships among dispersed cyber-physical resources.
A four-step methodology to specify the operational procedure of abstract ITSoS plans. The
methodology employs HTA to construct hierarchal task networks that use the ontological
model to define the key services, functional requirements, and interfaces of the application.
An integrated service execution engine that supports the realisation of abstract ITSoS plans
by offering the messaging infrastructure required to link their distributed ITSoS
components. The engine also offers other functionalities such as service invocation,
message validation and context annotation to support the automatic coordination of these
components
A proof-of-concept prototype implementation that demonstrates the feasibility of the
framework by using it to implement an advanced traveller information SoS that integrates
multiple ATIS services within the Greater Toronto Area (GTA), Ontario.
7.3 Future Research
The presented framework forms a foundation for a more ambitious vision to enable more complex
coordination scenarios such as advanced traffic management, integrated multi-modal operations,
emergency management, and the provision of transportation as a service, to name a few. The
ambitious vision also includes the anticipated rapid proliferation of automated and connected
vehicles. Materialising this vision requires the integration of larger scale number and types of
sensors and complex services such as adaptive traffic signal control, freeway control, transit
priority, vehicle-2-vehicle and vehicle-2-infrastructure collaboration etc. Such services are often
large-scale systems in their own right, many of which may be proprietary hindering their
integration. Research is still in flux on how to provide such services in a plug-and-play fashion
using a myriad of ITS standards. Materialising the vision also requires the implementation of
108
reliability assurance mechanisms that monitor sensors and services along their life cycle to resolve
any inconsistencies resulting from unexpected failures in their operation. Such mechanisms control
the admission of new services or sensors, guarantee the performance and reliability of each
resource, and maintain records of resource usage information for accounting purposes.
Furthermore, there is a need to extend the ITSoS ontological model to represent other categories
of physical resources such as traffic signals, controllers and changeable message signs etc.
The proliferation of ITS service providers imposes increasing non-operational requirements of
reliability, security, and performance of the ITSoS composed services. Satisfying these
requirements mandate more advanced authentication and authorization mechanisms to control
access to sensors and services, more efficient fault tolerance mechanisms to handle failures
gracefully, and proactive security measures to improve the resiliency of critical infrastructure
components against cyber-attacks. This also includes the use of quality-of-service measures to
rank shared services and resources, optimal selection mechanisms to maximise the efficiency of
the coordinated processes, and more sophisticated approaches to assure the compatibility of the
composed components.
Modern ITS applications and services are data intensive applications that collect and process
massive amounts of structured, semi-structured and non-structured data formats produced by
heterogeneous sources. Management of such large contextual data sets requires a scalable
infrastructure that provides an on-demand and auto-scaling functionality based on applications’
needs to handle the variable amounts of data produced by sensor networks, connected vehicles,
smart phones and open datasets. Therefore, the implementation of the context management module
shall adopt a Big Data architecture to process and analyse acquired sensors’ data more efficiently.
Such implementation shall leverage the emerging sensing, wireless communication, and cloud
computing technologies to fulfill the demand for timely and accurate data analysis in a sustainable
manner.
109
References
Abdulazim, T., Abdelgawad, H., Habib, K., & Abdulhai, B. (2013). Using smartphones and sensor
technologies to automate collection of travel data. Transportation Research Record: Journal of
the Transportation Research Board, (2383), 44-52.
Abdulhai, B., Porwal, H., & Recker, W. (2002). Short-term traffic flow prediction using neuro-
genetic algorithms. ITS Journal-Intelligent Transportation Systems Journal, 7(1), 3-41.
Abdulhai, B., & Ritchie, S. G. (1999). Enhancing the universality and transferability of freeway
incident detection using a bayesian-based neural network. Transportation Research Part C:
Emerging Technologies, 7(5), 261-280.
Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., & Ayyash, M. (2015). Internet of
things: A survey on enabling technologies, protocols, and applications. IEEE Communications
Surveys Tutorials, 17(4), 2347-2376. doi:10.1109/COMST.2015.2444095
Ashton, K. (2009). That ‘internet of things’ thing. RFiD Journal, 22(7), 97-114.
Atzori, L., Iera, A., & Morabito, G. (2010). The internet of things: A survey. Computer Networks,
54(15), 2787-2805.
Bachmann, C., Abdulhai, B., Roorda, M., & Moshiri, B. (2012). Multisensor data integration and
fusion in traffic operations and management. Transportation Research Record: Journal of the
Transportation Research Board, (2308), 27-36.
Baldwin, W. C., & Sauser, B.Modeling the characteristics of system of systems. System of Systems
Engineering, 2009. SoSE 2009. IEEE International Conference On, Albuquerque, NM, USA. 1-6.
Banerjee, P., Friedrich, R., Bash, C., Goldsack, P., Huberman, B., Manley, J., . . . Veitch, A. (2011,
Everything as a service: Powering the new information economy. Computer, 44, 36-43.
doi:10.1109/MC.2011.67
Bansal, S. K., Bansal, A., & Blake, M. B. (2010). (2010). Trust-based dynamic web service
composition using social network analysis. Paper presented at the IEEE International Workshop
110
on: Business Applications of Social Network Analysis (BASNA), Bangalore, India. 1-8.
doi:10.1109/BASNA.2010.5730308
Barbeau, S., Labrador, M., Georggi, N., Winters, P., & Perez, R.TRAC-IT--A software
architecture supporting simultaneous travel behavior data collection & real-time location-based
services for GPS-enabled mobile phones. Proc. Nat’l Academy of Sciences’ Transportation
Research Board 88th Ann. Meeting,
Barbeau, S. J., Georggi, N. L., & Winters, P. L. (2010). Global positioning system integrated with
personalized real-time transit information from automatic vehicle location. Transportation
Research Record: Journal of the Transportation Research Board, 2143(1), 168-176.
Bayen, A. M., & Patire, A. D. (2011). Mobile millennium final report California Center for
Innovative Transportation, Institute of Transportation Studies, University of California, Berkeley.
Bechhofer, S. (2009). OWL: Web ontology language. Encyclopedia of database systems (pp.
2008-2009) Springer.
Bellur, U., & Kulkarni, R. (July 2007). (July 2007). Improved matchmaking algorithm for
semantic web services based on bipartite graph matching. Paper presented at the IEEE
International Conference on Web Services (ICWS 2007), Salt Lake City, Utah, USA. 86-93.
doi:10.1109/ICWS.2007.105
Benatallah, B., Hacid, M., Leger, A., Rey, C., & Toumani, F. (2005). On automating web services
discovery. The VLDB Journal, 14(1), 84-96.
Berners-Lee, T. (2006). Linked data-design issues. Retrieved from
http://www.citeulike.org/group/8357/article/3421195
Boardman, J., & Sauser, B.System of systems-the meaning of of. 2006 IEEE/SMC International
Conference on System of Systems Engineering, 6 pp.
Bormann, C., Castellani, A. P., & Shelby, Z. (2012). Coap: An application protocol for billions of
tiny internet nodes. IEEE Internet Computing, 16(2), 62.
111
Brickley, D., & Guha, R. V. (2004). RDF vocabulary description language 1.0: RDF schema.
Retrieved from https://www.w3.org/TR/rdf-schema/
Byon, Y., Abdulhai, B., & Shalaby, A. (2009). Real-time transportation mode detection via
tracking global positioning system mobile devices. Journal of Intelligent Transportation Systems,
13(4), 161-170.
Byon, Y., Shalaby, A., Abdulhai, B., & El-Tantawy, S.Traffic data fusion using SCAAT kalman
filters. Transportation Research Board 89th Annual Meeting, (10-2392)
Calabrese, F., Ferrari, L., & Blondel, V. D. (2015). Urban sensing using mobile phone network
data: A survey of research. ACM Computing Surveys (CSUR), 47(2), 25. Retrieved from
http://dl.acm.org/citation.cfm?id=2655691
Campbell, A. T., Eisenman, S. B., Lane, N. D., Miluzzo, E., Peterson, R. A., Lu, H., . . . Ahn, G.
(2008). The rise of people-centric sensing. Internet Computing, IEEE, 12(4), 12-21.
Casati, F., Ilnicki, S., Jin, L., Krishnamoorthy, V., & Shan, M.Adaptive and dynamic service
composition in eFlow. Advanced Information Systems Engineering, 13-31.
Casati, F., & Shan, M. (2001). Dynamic and adaptive composition of e-services. Information
Systems, 26(3), 143-163.
Chen, S., Wang, X., Vatcha, R., Dou, W., Lee, S., Chang, R., . . . Ribarsky, W.IRSV, an integrated
visual analytics bridge management system. Transportation Research Board 89th Annual Meeting,
(10-3632)
Chen, X., Zheng, Z., Yu, Q., & Lyu, M. R. (2014). Web service recommendation via exploiting
location and QoS information. IEEE Transactions on Parallel and Distributed Systems, 25(7),
1913-1924. doi:10.1109/TPDS.2013.308
Choujaa, D., & Dulay, N.Predicting human behaviour from selected mobile phone data points.
Proceedings of the 12th ACM International Conference on Ubiquitous Computing, 105-108.
112
Chourabi, H., Nam, T., Walker, S., Gil-Garcia, J. R., Mellouli, S., Nahon, K., . . . Scholl, H.
J.Understanding smart cities: An integrative framework. System Science (HICSS), 2012 45th
Hawaii International Conference On, 2289-2297.
Clark, J. (1999). XSL transformations (XSLT). Retrieved from https://www.w3.org/TR/xslt
Compton, M., Barnaghi, P., Bermudez, L., García-Castro, R., Corcho, O., Cox, S., . . . Taylor, K.
(2012). The SSN ontology of the W3C semantic sensor network incubator group. Web Semantics:
Science, Services and Agents on the World Wide Web, 17, 25-32.
doi:10.1016/j.websem.2012.05.003
Cyganiak, R., & Bizer, C. (2008). Pubby - a linked data frontend for SPARQL endpoints.
Retrieved from http://wifo5-03.informatik.uni-mannheim.de/pubby
Daniel Delaurentis. (Jan 1, 2005). (Jan 1, 2005). Understanding transportation as a system-of-
systems design problem. Paper presented at the 43rd AIAA Aerospace Sciences Meeting and
Exhibit, Reno, Nevada. , 1 doi:10.2514/6.2005-123
Dey, A. K., & Abowd, G. D.Towards a better understanding of context and context-awareness. In
HUC ’99: Proceedings of the 1st International Symposium on Handheld and Ubiquitous
Computing, 304-307.
Dirks, S., Gurdgiev, C., & Keeling, M. (2010). Smarter cities for smarter growth: How cities can
optimize their systems for the talent-based economy. IBM Institute for Business Value, Retrieved
from http://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=GBE03348USEN
Dobbs, R., Pohl, H., Lin, D. Y., Mischke, J., Garemo, N., Hexter, J., . . . Nanavatty, R. (2013).
Infrastructure productivity: How to save $1 trillion a year? McKinsey Global Institute,
Dresner, K., & Stone, P. (2008). A multiagent approach to autonomous intersection management.
Journal of Artificial Intelligence Research, 31, 591-656. doi:10.1613/jair.2502
Eisenman, S. B., Miluzzo, E., Lane, N. D., Peterson, R. A., Ahn, G., & Campbell, A. T. (2010).
BikeNet: A mobile sensing system for cyclist experience mapping. ACM Trans. Sen. Netw., 6(1),
6:1–6:39. doi:10.1145/1653760.1653766
113
Elshenawy, M., El-Darieby, M., & Abdulhai, B. (2015a). A Cyber–Physical–Social platform for
intelligent transportation systems. Cyber-physical systems: From theory to practice (pp. 283-294)
CRC Press.
Elshenawy, M., El-Darieby, M., & Abdulhai, B. (2015b). ONE-ITS: Strategy, architecture, and
software implementation of a Cyber–Physical–Social platform. Cyber-physical systems: From
theory to practice (pp. 297-306) CRC Press.
El-Tantawy, S., Abdulhai, B., & Abdelgawad, H. (2013). 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, 14(3), 1140-1150. doi:10.1109/TITS.2013.2255286
Erol, K., Hendler, J., & Nau, D. S.HTN planning: Complexity and expressivity. Aaai, Seattle,
Washington. , 94 1123-1128.
Farquhar, A., Fikes, R., & Rice, J. (1997). The ontolingua server: A tool for collaborative ontology
construction. International Journal of Human-Computer Studies, 46(6), 707-727.
Ferreira, J., Diao, M., Zhu, Y., Li, W., & Jiang, S. (2010). Information infrastructure for research
collaboration in land use, transportation, and environmental planning. Transportation Research
Record: Journal of the Transportation Research Board, 2183(-1), 85-93.
Ferris, B., Watkins, K., & Borning, A. (2009). Location-aware tools for improving public transit
usability. IEEE Pervasive Computing, (1), 13–19. Retrieved from
http://www.computer.org/csdl/mags/pc/2010/01/mpc2010010013-abs.html
Ferris, B., Watkins, K., & Borning, A.OneBusAway: Results from providing real-time arrival
information for public transit. Proceedings of the SIGCHI Conference on Human Factors in
Computing Systems, New York, NY, USA. 1807–1816. doi:10.1145/1753326.1753597
Fox, M., & Long, D. (2003). PDDL2. 1: An extension to PDDL for expressing temporal planning
domains. J.Artif.Intell.Res.(JAIR), 20, 61-124.
114
Fox, M. S., Barbuceanu, M., & Gruninger, M.An organisation ontology for enterprise modelling:
Preliminary concepts for linking structure and behaviour. Enabling Technologies: Infrastructure
for Collaborative Enterprises, 1995., Proceedings of the Fourth Workshop On, 71-81.
Ghallab, M., Nau, D., & Traverso, P. (2004). Automated planning theory and practice Elsevier.
Gómez‐ Pérez, A. (2001). Evaluation of ontologies. International Journal of Intelligent Systems,
16(3), 391-409.
Gorod, A., Sauser, B., & Boardman, J. (2008). System-of-systems engineering management: A
review of modern history and a path forward. IEEE Systems Journal, 2(4), 484-499.
Grninger, M., & Fox, M. S.Methodology for the design and evaluation of ontologies. Workshop
on Basic Ontological Issues in Knowledge Sharing, IJCAI-95,
Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of things (IoT): A vision,
architectural elements, and future directions. Future Generation Computer Systems, 29(7), 1645-
1660.
Guinard, D., Trifa, V., Karnouskos, S., Spiess, P., & Savio, D. (2010). Interacting with the soa-
based internet of things: Discovery, query, selection, and on-demand provisioning of web services.
Services Computing, IEEE Transactions On, 3(3), 223-235.
Hatzi, O., Vrakas, D., Nikolaidou, M., Bassiliades, N., Anagnostopoulos, D., & Vlahavas, I.
(2012). An integrated approach to automated semantic web service composition through planning.
IEEE Transactions on Services Computing, 5(3), 319-332. doi:10.1109/TSC.2011.20
Henson, C., Sheth, A., & Thirunarayan, K. (2012). Semantic perception: Converting sensory
observations to abstractions. IEEE Internet Computing, 16(2), 26-34. doi:10.1109/MIC.2012.20
Hepper, S. (2008). JSR 286: Portlet specification 2.0 Java Community Press.
Hickman, M., Weissenberger, S., & Dahlgren, J. (1996). Assessing the benefits of a national ITS
architecture. California Partners for Advanced Transit and Highways (PATH),
Hull, B., Bychkovsky, V., Zhang, Y., Chen, K., Goraczko, M., Miu, A., . . . Madden, S.CarTel: A
distributed mobile sensor computing system. Proceedings of the 4th International Conference on
115
Embedded Networked Sensor Systems, New York, NY, USA. 125–138.
doi:10.1145/1182807.1182821
Hunkeler, U., Truong, H. L., & Stanford-Clark, A.MQTT-S—A publish/subscribe protocol for
wireless sensor networks. Communication Systems Software and Middleware and Workshops,
2008. Comsware 2008. 3rd International Conference On, 791-798.
ISO. (2011). ISO 14825:2011 - intelligent transport systems -- geographic data files (GDF) --
GDF5.0. Retrieved from http://www.iso.org/iso/catalogue_detail.htm?csnumber=54610
Janowicz, K., & Compton, M.The stimulus-sensor-observation ontology design pattern and its
integration into the semantic sensor network ontology. Proceedings of the 3rd International
Conference on Semantic Sensor Networks
, Aachen, Germany. , 668 64–78.
Jariyasunant, J., Work, D. B., Kerkez, B., Sengupta, R., Bayen, A. M., & Glaser, S.Mobile transit
trip planning with real-time data. Transportation Research Board 89th Annual Meeting, (10-3748)
Kambhampati, S. (1995). A comparative analysis of partial order planning and task reduction
planning. ACM SIGART Bulletin, 6(1), 16-25. doi:10.1145/202187.202192
Khan, I., Jafrin, R., Errounda, F. Z., Glitho, R., Crespi, N., Morrow, M., & Polakos, P. (May 2015).
(May 2015). A data annotation architecture for semantic applications in virtualized wireless sensor
networks. Paper presented at the IFIP/IEEE International Symposium on Integrated Network
Management (IM), Ottawa, Canada. 27-35. doi:10.1109/INM.2015.7140273
Khan, W. Z., Xiang, Y., Aalsalem, M. Y., & Arshad, Q. (2013). Mobile phone sensing systems: A
survey. Communications Surveys & Tutorials, IEEE, 15(1), 402-427.
Klusch, M., Gerber, A., & Schmidt, M.Semantic web service composition planning with OWLS-
xplan. Proceedings of the AAAI Fall Symposium on Semantic Web and Agents, Arlington,
VA, USA.
Klyne, G., Carroll, J. J., & McBride, B. (2006). Resource description framework (RDF): Concepts
and abstract syntax. Retrieved from https://www.w3.org/TR/rdf11-concepts/
116
Ko, R. K. L., Lee, E. W., & Lee, S. G. (2012). Business-OWL (BOWL) - A hierarchical task
network ontology for dynamic business process decomposition and formulation. IEEE
Transactions on Services Computing, 5(2), 246-259. doi:10.1109/TSC.2011.48
Kostakos, V., Nicolai, T., Yoneki, E., O’Neill, E., Kenn, H., & Crowcroft, J. (2009).
Understanding and measuring the urban pervasive infrastructure. Personal and Ubiquitous
Computing, 13(5), 355-364.
Koukoumidis, E., Martonosi, M., & Peh, L. S. (2012). Leveraging smartphone cameras for
collaborative road advisories. IEEE Transactions on Mobile Computing, 11(5), 707-723.
doi:10.1109/TMC.2011.275
Lara, R., Roman, D., Polleres, A., & Fensel, D. (2004). A conceptual comparison of WSMO and
OWL-S. In L. (. Zhang, & M. Jeckle (Eds.), Web services (pp. 254-269) Springer Berlin
Heidelberg. Retrieved from http://link.springer.com/chapter/10.1007/978-3-540-30209-4_19
Lécué, F., Tallevi-Diotallevi, S., Hayes, J., Tucker, R., Bicer, V., Sbodio, M., & Tommasi, P.
(2014). Smart traffic analytics in the semantic web with STAR-CITY: Scenarios, system and
lessons learned in dublin city. Web Semantics: Science, Services and Agents on the World Wide
Web, 27–28, 26-33. doi:10.1016/j.websem.2014.07.002
Lee, J., & Park, B. (2012). Development and evaluation of a cooperative vehicle intersection
control algorithm under the connected vehicles environment. IEEE Transactions on Intelligent
Transportation Systems, 13(1), 81-90. doi:10.1109/TITS.2011.2178836
Leontiadis, I., Marfia, G., Mack, D., Pau, G., Mascolo, C., & Gerla, M. (2011). On the
effectiveness of an opportunistic traffic management system for vehicular networks. IEEE
Transactions on Intelligent Transportation Systems, 12(4), 1537-1548.
doi:10.1109/TITS.2011.2161469
Le-Phuoc, D., Nguyen-Mau, H. Q., Parreira, J. X., & Hauswirth, M. (2012). A middleware
framework for scalable management of linked streams. Web Semantics: Science, Services and
Agents on the World Wide Web, 16, 42-51. doi:10.1016/j.websem.2012.06.003
117
Letchner, J. M., Krumm, J. C., & Horvitz, E. J. (2009). Collaborative route planning for
generating personalized and context-sensitive routing recommendations Retrieved from
http://patft.uspto.gov/netacgi/nph-
Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-
bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F7610151
Liping Zhang, Gupta, S. D., Jing-Quan Li, Kun Zhou, & Wei-bin Zhang.Path2Go: Context-aware
services for mobile real-time multimodal traveler information. Intelligent Transportation Systems
(ITSC), 2011 14th International IEEE Conference On, 174-179.
Liu, L., Mehandjiev, N., & Xu, D. (2011). (2011). Multi-criteria service recommendation based
on user criteria preferences. Paper presented at the 77–84. doi:10.1145/2043932.2043950
Liu, N. (2011). Internet of vehicles: Your next connection. Huawei WinWin, 11, 23–28. Retrieved
from http://www.huawei.com/en/publications/winwin-magazine/11/HW_110848
Lorenz, B., Ohlbach, H. J., & Yang, L. (2005). Ontology of transportation networks. Retrieved
from http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.2953
Lu, N., Cheng, N., Zhang, N., Shen, X., & Mark, J. W. (2014). Connected vehicles: Solutions and
challenges. Internet of Things Journal, IEEE, 1(4), 289–299. Retrieved from
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6823640
Ma, T., Zhou, Z., & Abdulhai, B. (2015). Nonlinear multivariate time–space threshold vector error
correction model for short term traffic state prediction. Transportation Research Part B:
Methodological, 76, 27-47.
Madni, A. M., & Sievers, M. (2014). System of systems integration: Key considerations and
challenges. Systems Engineering, 17(3), 330-347.
Maier, M. W. (1998). Architecting principles for systems-of-systems. Systems Engineering, 1(4),
267-284. doi:AID-SYS3>3.0.CO;2-D
Martin, D., Burstein, M., McDermott, D., McIlraith, S., Paolucci, M., Sycara, K., . . . Srinivasan,
N. (2007). Bringing semantics to web services with OWL-S. World Wide Web, 10(3), 243-277.
doi:10.1007/s11280-007-0033-x
118
Mathur, S., Jin, T., Kasturirangan, N., Chandrasekaran, J., Xue, W., Gruteser, M., & Trappe, W.
(2010). (2010). ParkNet: Drive-by sensing of road-side parking statistics. Paper presented at the
Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services,
New York, NY, USA. 123–136. doi:10.1145/1814433.1814448
McIlraith, S. A., Son, T. C., & Zeng, H. (2001). Semantic web services. Intelligent Systems, IEEE,
16(2), 46-53.
McIlraith, S., & Son, T. C.Adapting golog for composition of semantic web services. Principles
of Knowledge Representation and Reasoning International Conference, 482-496.
Medjahed, B., Bouguettaya, A., & Elmagarmid, A. (2003). Composing web services on the
semantic web. The VLDB Journal, 12(4), 333-351.
Mohan, P., Padmanabhan, V. N., & Ramjee, R. (2008). (2008). Nericell: Rich monitoring of road
and traffic conditions using mobile smartphones. Paper presented at the Proceedings of the 6th
ACM Conference on Embedded Network Sensor Systems, New York, NY, USA. 323–336.
doi:10.1145/1460412.1460444
Mokhtar, S. B. (2007). Semantic middleware for service-oriented pervasive computing
Nawaz, S., Efstratiou, C., & Mascolo, C.ParkSense: A smartphone based sensing system for on-
street parking. Proceedings of the 19th Annual International Conference on Mobile Computing
& Networking, New York, NY, USA. 75–86. doi:10.1145/2500423.2500438
Pack, M. L., Bryan, J. R., & Steffes, A.Overview and status of regional integrated transportation
information system in the national capital region. Transportation Research Board 87th Annual
Meeting, (08-1299)
Paik, I., Chen, W., & Huhns, M. N. (2014). A scalable architecture for automatic service
composition. Services Computing, IEEE Transactions On, 7(1), 82-95.
Paolucci, M., Kawamura, T., Payne, T. R., & Sycara, K. (2002). Semantic matching of web
services capabilities. The semantic web — ISWC 2002 (pp. 333-347). Berlin, Heidelberg: Springer
Berlin Heidelberg. doi:10.1007/3-540-48005-6_26
119
Papazoglou, M. P., Traverso, P., Dustdar, S., & Leymann, F. (2007). Service-oriented computing:
State of the art and research challenges. Computer, 40(11), 38-45.
Parker, J. M. (2010). Applying a System of Systems Approach for Improved Transportation.
Surveys and Perspectives Integrating Environment and Society, 3(2) Retrieved from
https://sapiens.revues.org/1011
Parker, S., Sarma, B., Mishefske, J., King, D., Ran, B., & Noyce, D. A.InterCAD: Public safety
computer-aided dispatch to traffic operations advanced traffic management system data exchange.
Transportation Research Board 91st Annual Meeting, (12-2901)
Patterson, D. J., Liao, L., Gajos, K., Collier, M., Livic, N., Olson, K., . . . Kautz, H.Opportunity
knocks: A system to provide cognitive assistance with transportation services. In International
Conference on Ubiquitous Computing (UbiComp), 433-450.
Peltz, C. (2003). Web services orchestration and choreography. Computer, 36(10), 46-52.
Perera, C., Zaslavsky, A., Christen, P., Compton, M., & Georgakopoulos, D. (2013). (2013).
Context-aware sensor search, selection and ranking model for internet of things middleware. Paper
presented at the IEEE 14th International Conference on Mobile Data Management, Milan, Italy. ,
1 314-322. doi:10.1109/MDM.2013.46
Perera, C., Zaslavsky, A., Christen, P., & Georgakopoulos, D. (2014). Context aware computing
for the internet of things: A survey. Communications Surveys & Tutorials, IEEE, 16(1), 414-454.
Pierce, G., & Shoup, D. (2013). Getting the prices right: An evaluation of pricing parking by
demand in san francisco. Journal of the American Planning Association, 79(1), 67–81. Retrieved
from http://www.tandfonline.com/doi/abs/10.1080/01944363.2013.787307
Pitt, J., Bourazeri, A., Nowak, A., Roszczynska-Kurasinska, M., Rychwalska, A., Santiago, I. R.,
. . . Sanduleac, M. (2013). Transforming big data into collective awareness. Computer, 46(6), 40-
45. doi:10.1109/MC.2013.153
Qu, F., Wang, F., & Yang, L. (2010). Intelligent transportation spaces: Vehicles, traffic,
communications, and beyond. Communications Magazine, IEEE, 48(11), 136-142.
120
Qu, Z., Wang, J., & Hull, R. A. (2008). Cooperative control of dynamical systems with application
to autonomous vehicles. Automatic Control, IEEE Transactions On, 53(4), 894–911. Retrieved
from http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=4522625
Reddy, S., Shilton, K., Denisov, G., Cenizal, C., Estrin, D., & Srivastava, M. (2010). (2010).
Biketastic: Sensing and mapping for better biking. Paper presented at the Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, New York, NY, USA. 1817–1820.
doi:10.1145/1753326.1753598
Rezaee, K., Abdulhai, B., & Abdelgawad, H. (2013). 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, (2396), 10-18.
Rodriguez-Mier, P., Mucientes, M., & Lama, M.Automatic web service composition with a
heuristic-based search algorithm. IEEE International Conference on Web Services (ICWS),
Washington, USA. 81-88. doi:10.1109/ICWS.2011.89
Roman, D., Keller, U., Lausen, H., de Bruijn, J., Lara, R., Stollberg, M., . . . Fensel, D. (2005).
Web service modeling ontology. Applied Ontology, 1(1), 77-106. Retrieved from
http://content.iospress.com/articles/applied-ontology/ao000008
Roy, P., & Abdulhai, B. (2003). GAID: Genetic adaptive incident detection for freeways.
Transportation Research Record: Journal of the Transportation Research Board, (1856), 96-105.
Russell, S. J., Norvig, P., Canny, J. F., Malik, J. M., & Edwards, D. D. (2003). Artificial
intelligence: A modern approach Prentice hall Upper Saddle River.
Schmier, K. J., & Freda, P. (2002). Public transit vehicle arrival information system
Sirin, E., Hendler, J., & Parsia, B.Semi-automatic composition of web services using semantic
descriptions. Web Services: Modeling, Architecture and Infrastructure Workshop in ICEIS,
Angers, France. , 2003
Sirin, E., Parsia, B., Wu, D., Hendler, J., & Nau, D. (2004). HTN planning for web service
composition using SHOP2. Web Semantics: Science, Services and Agents on the World Wide Web,
1(4), 377-396. doi:10.1016/j.websem.2004.06.005
121
Sochor, J., Strömberg, H., & Karlsson, I. C. M. (2014). The added value of a new, innovative travel
service: Insights from the UbiGo field operational test in gothenburg, sweden. In R. Giaffreda, D.
Cagáňová, Y. Li, R. Riggio & A. Voisard (Eds.), Internet of things. IoT infrastructures (pp. 169-
175) Springer International Publishing.
Sochor, J., Strömberg, H., & Karlsson, I. C. M. (2015). Implementing mobility as a service:
Challenges in integrating user, commercial, and societal perspectives. Transportation Research
Record: Journal of the Transportation Research Board, 2536, 1-9. doi:10.3141/2536-01
Sohrabi, S., & McIlraith, S.Preference-based web service composition: A middle ground between
execution and search. International Semantic Web Conference, 713-729.
Srivastava, B., Rudy, R., XU, J., Miller, B., Giacomel, A., Wysmuller, S., . . . Parker, K.A general
approach to exploit available traffic data for a smarter city. 20th ITS World Congress,
Staab, S., & Studer, R. (2009). Handbook on ontologies (2nd ed. ed.). DE: Springer Verlag.
Stanton, N. A. (2006). Hierarchical task analysis: Developments, applications, and extensions.
Applied Ergonomics, 37(1), 55-79.
Steve Sill, Blake Christie, Ann Diephaus, Dan Garretson, Kay Sullivan, & Suzanne Sloan. (2011).
Intelligent transportation systems (ITS) standards program strategic plan for 2011–2014. final
report. US. Department of Transportation (USDOT), Final Report. FHWA-JPO-11-052,
The San Francisco Municipal Transportation Agency, (SFMTA). (2013). Parking sensor data
guide. Retrieved from http://sfpark.org
Thiagarajan, A., Ravindranath, L., LaCurts, K., Madden, S., Balakrishnan, H., Toledo, S., &
Eriksson, J.VTrack: Accurate, energy-aware road traffic delay estimation using mobile phones.
Proceedings of the 7th ACM Conference on Embedded Networked Sensor Systems, New York,
NY, USA. 85–98. doi:10.1145/1644038.1644048
Transport Canada. (2015). ITS architecture for canada version 2.0. Retrieved from
https://www.tc.gc.ca/eng/innovation/its-architecture.htm
122
U.S. Department of Transportaion.ITS standards program. Retrieved from
http://www.standards.its.dot.gov/
Uschold, M., & Gruninger, M. (2004). Ontologies and semantics for seamless connectivity. ACM
SIGMod Record, 33(4), 58-64.
Vermesan, O., Friess, P., Guillemin, P., Gusmeroli, S., Sundmaeker, H., Bassi, A., . . . Eisenhauer,
M. (2011). Internet of things strategic research roadmap. In O. Vermesan, & P. Friess (Eds.),
Internet of things-global technological and societal trends (pp. 9-52). Aalborg, Denmark: River
Publishers.
Vlacheas, P., Giaffreda, R., Stavroulaki, V., Kelaidonis, D., Foteinos, V., Poulios, G., . . .
Moessner, K. (2013). Enabling smart cities through a cognitive management framework for the
internet of things. Communications Magazine, IEEE, 51(6), 102-111.
Weerawarana, S., Curbera, F., Leymann, F., Storey, T., & Ferguson, D. F. (2005). Web services
platform architecture: SOAP, WSDL, WS-policy, WS-addressing, WS-BPEL, WS-reliable
messaging and more. Upper Saddle River, NJ, USA: Prentice Hall PTR.
Weske, M. (2012). Business process management architectures. Business process management
(pp. 333-371) Springer.
Wu, D., Parsia, B., Sirin, E., Hendler, J., & Nau, D.Automating DAML-S web services
composition using SHOP2. International Semantic Web Conference, Florida, USA. 195-210.
Wu, Y., An, S., Ma, X., & Wang, Y. (2011). Development of web-based analysis system for real-
time decision support on arterial networks. Transportation Research Record: Journal of the
Transportation Research Board, 2215(-1), 24-36. doi:10.3141/2215-03
Xin, W., Chang, J., Bertoli, B., & Mohamad, A.Integrated adaptive traffic signal control with real-
time decision support. Transportation Research Board 89th Annual Meeting, (10-3511)
Zanella, A., Bui, N., Castellani, A., Vangelista, L., & Zorzi, M. (2014). Internet of things for smart
cities. Internet of Things Journal, IEEE, 1(1), 22-32.
123
Zhou, P., Zheng, Y., & Li, M. (2012). (2012). How long to wait?: Predicting bus arrival time with
mobile phone based participatory sensing. Paper presented at the Proceedings of the 10th
International Conference on Mobile Systems, Applications, and Services, New York, NY, USA.
379–392. doi:10.1145/2307636.2307671
124
Appendix A: Supplementary Information for Chapter 4
Table 1: Queries regarding standardised ITS processes
What are the possible inputs of a
standardised ITS process?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT ?InFlowName WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net/ontologies/oitsp#hasInFlow> ?InFlow . ?InFlow <http://www.w3.org/2000/01/rdf-schema#label> ?InFlowName . }
What goals is a standardised ITS process
trying to accomplish?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT ?UserReqDesc WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net/ontologies/oitsp#satisfiesUserServiceRequirement> ?UserReq . ?UserReq <http://one-its.net/ontologies/oitsp#description> ?UserReqDesc . }
What are the roles of stakeholders
involved in a standardised ITS process?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT ?StakeholderRoleLabel WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net/ontologies/oitsp#involvesStakeholderRole> ? StakeholderRole . ?StakeholderRole <http://www.w3.org/2000/01/rdf-schema#label> StakeholderRoleLabel . }
What physical equipment packages
implementing a standardised ITS
process?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT ?PkgName WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net/ontologies/oitsp# implementedByEquipmentPackage> ?EquipPackage . ?EquipPackage <http://www.w3.org/2000/01/rdf-schema#label> ?PkgName . }
What are the functional requirements to
satisfy a standardised ITS process?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT DISTINCT ?FnRqDesc WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net /ontologies/oitsp #implementedByEquipmentPackage> ?EquipPackage . ?EquipPackage <http://one-its.net /ontologies/oitsp#definesFunctionalRequirement> ?FnRq . ?FnRq <http://www.w3.org/2000/01/rdf-schema#label> ? FnRqDesc . }
What are the services that implement a
standardised ITS process?
Process IRI : http://one-
its.net/ITS_arch/pspec_6_6_1
SELECT DISTINCT ?ServiceName WHERE { <http://one-its.net/ITS_arch/pspec_6_6_1> <http://one-its.net/ontologies/oitsp# implementedByEquipmentPackage > ?EquipPackage . ?EquipPackage <http://one-its.net/ontologies/oitsp# #definesFunctionalRequirement> ?FnRq .
125
?FnRq <http://one-its.net/ontologies/ITSOS#implementedByService> ?FnRqService . ?FnRqService <http://www.daml.org/services/owl-s/1.2/Service.owl#presentedBy> ?ServiceProfile . ?ServiceProfile <http://www.daml.org/services/owl-s/1.2/Profile.owl#serviceName> ?ServiceName . }
Table 2: Queries regarding ITS Sensors
What are the properties
observed by an ITS sensor?
Sensor IRI : http://one-
its.net/ITS_Sensor/401DW00
30DWT
SELECT ?PropertyName WHERE { <http://one-its.net/ITS_Sensor/401DW0030DWT> <http://purl.oclc.org/NET/ssnx/ssn#observes> ?Property . ?Property <http://www.w3.org/2000/01/rdf-schema#label> ?PropertyName . }
What are the features (e.g.
road elements) monitored by
an ITS sensor?
Sensor IRI : http://one-
its.net/ITS_Sensor/401DW00
30DWT
SELECT DISTINCT ?FeatureName WHERE { <http://one-its.net/ITS_Sensor/401DW0030DWT> <http://purl.oclc.org/NET/ssnx/ssn#observes> ?Property . ?Property <http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf> ?Feature . ?Feature <http://www.w3.org/2000/01/rdf-schema#label> ?FeatureName . }
Which standardised ITS
processes are supported by an
ITS sensor?
Sensor IRI : http://one-
its.net/ITS_Sensor/401DW00
30DWT
SELECT DISTINCT ?ProcessName WHERE { <http://one-its.net/ITS_Sensor/401DW0030DWT> <http://one-its.net/ontologies/ITSOS#associatedEquipmentPackage> ?EquipPackage . ?EquipPackage <http://one-its.net/ontologies/oitsp#implementsProcess> ?Process . ?Process <http://www.w3.org/2000/01/rdf-schema#label> ?ProcessName . }
What are the measuring
capabilities (e.g. accuracy) of
an ITS sensor?
Sensor IRI : http://one-
its.net/ITS_Sensor/401DW00
30DWT
SELECT DISTINCT ?ProcessName WHERE { <http://one-its.net/ITS_Sensor/401DW0030DWT> <http://one-its.net/ontologies/ITSOS#associatedEquipmentPackage> ?EquipPackage . ?EquipPackage <http://one-its.net/ontologies/oitsp#implementsProcess> ?Process . ?Process <http://www.w3.org/2000/01/rdf-schema#label> ?ProcessName . }
Which sensors are deployed
on a city infrastructural
element (e.g. road element)?
Sensor IRI : http://one-
its.net/ITS_Sensor/401DW00
30DWT
SELECT ?MeasurementCapabilityName WHERE { <http://one-its.net/ITS_Sensor/401DW0030DWT> <http://purl.oclc.org/NET/ssnx/ssn#hasMeasurementCapability> ?MeasurementCapability . ?MeasurementCapability <http://www.w3.org/2000/01/rdf-schema#label> ?MeasurementCapabilityName . }
126
What are the alternatives of
an ITS sensor in case of
failures to observe a property
of an infrastructural element?
Feature IRI : http://one-
its.net/ITS_Feature/eLement_
5951362
Property IRI : http://one-
its.net/ITS_Property/speed_p
roperty
Sensor IRI : http://one-
its.net/ITS_Sensor/401DE00
80DWC
SELECT ?SensorName WHERE { ?Sensor <http://purl.oclc.org/NET/ssnx/ssn#ofFeature> <http://one-its.net/ITS_Feature/eLement_5951362> . ?Sensor < http://purl.oclc.org/NET/ssnx/ssn#observes> < http://one-its.net/ITS_Property/speed_property> . ?Sensor <http://www.w3.org/2000/01/rdf-schema#label> ?SensorName . FILTER (?Sensor != <http://one-its.net/ITS_Sensor/401DE0080DWC>) }
Table 3: Queries regarding ITS Services
What are the inputs of an ITS service?
Service IRI : http://one-
its.net/ITS_Service/GTAIncidentService
SELECT DISTINCT ?InputName WHERE
{ <http://one-its.net/ITS_Service/GTAIncidentService> <http://www.daml.org/services/owl-s/1.2/Service.owl#presentedBy> ?ServiceProfile . ?ServiceProfile <http://www.daml.org/services/owl-s/1.2/Profile.owl#hasInput> ?ServiceInput ?ServiceInput <http://www.w3.org/2000/01/rdf-schema#label> ?InputName . }
What are the outputs of an ITS Service?
Service IRI : http://one-
its.net/ITS_Service/GTAIncidentService
SELECT DISTINCT ?OutputName WHERE
{ <http://one-its.net/ITS_Service/GTAIncidentService> <http://www.daml.org/services/owl-s/1.2/Service.owl#presentedBy> ?ServiceProfile . ?ServiceProfile <http://www.daml.org/services/owl-s/1.2/Profile.owl#hasOutput> ?ServiceOutput ?ServiceOutput <http://www.w3.org/2000/01/rdf-schema#label> ?OutputName . }
Which standardised processes require
the execution of an ITS service?
Service IRI : http://one-
its.net/ITS_Service/GTAIncidentService
SELECT ?ProcessName WHERE
{ <http://one-its.net/ITS_Service/GTAIncidentService> <http://www.daml.org/services/owl-s/1.2/Service.owl#describedBy> ?ServiceModel . ?ServiceModel <http://www.w3.org/2000/01/rdf-schema#label> ?ProcessName . }
What are the message protocols required
to invoke an ITS service?
Service IRI : http://one-
its.net/ITS_Service/GTAIncidentService
SELECT ?GroundingName WHERE
{ <http://one-its.net/ITS_Service/GTAIncidentService> <http://www.daml.org/services/owl-s/1.2/Service.owl#supportedBy> ?ServiceGrounding . ?ServiceGrounding <http://www.w3.org/2000/01/rdf-schema#label> ?GroundingName . }
What are the alternatives of an ITS
service in case of failures to implement
a functional requirement?
Service IRI : http://one-
its.net/ITS_Service/GTAIncidentService
Functional Req IRI: http://one-
its.net/ITS_arch/functional_Rq_168
SELECT ?ServiceName WHERE { ?Service <http://one-its.net/ontologies/ITSOS#implementsFunctionalRequirement> <http://one-its.net/ITS_arch/functional_Rq_168> . ?Service <http://www.daml.org/services/owl-s/1.2/Profile.owl#serviceName> ?ServiceName .
127
FILTER (?Service != < http://one-its.net/ITS_Service/GTAIncidentService>) }
Table 4: Queries regarding virtual organisations
What is the collaboration goal of
a virtual organisation?
VO IRI : http://one-
its.net/ITS_VO/ATIS_GTA
SELECT ?GoalDesc WHERE
{ < http://one-its.net/ITS_VO/ATIS_GTA> <http://one-its.net/ontologies/oitsp# describesCollaborationGoal> ?VOGoal . ?VOGoal <http://one-its.net/ontologies/ITSOS#description> ?GoalDesc . }
Who are the stakeholders
collaborating on a virtual
organisation?
VO IRI : http://one-
its.net/ITS_VO/ATIS_GTA
SELECT ?StakeholderName WHERE
{ < http://one-its.net/ITS_VO/ATIS_GTA> <http://one-its.net/ontologies/oitsp#hasMember> ?Stakeholders . ?Stakeholders <http://one-its.net/ontologies/oitsp#description> ? StakeholderName . }
What are the standardised ITS
processes supporting
collaboration goals of a virtual
organisation?
VO IRI : http://one-
its.net/ITS_VO/ATIS_GTA
SELECT ?ProcessName WHERE
{ < http://one-its.net/ITS_VO/ATIS_GTA> <http://one-its.net/ontologies/oitsp# describesCollaborationGoal > ?VOGoal . ?VOGoal <http://one-its.net/ontologies/oitsp#describedByUserServiceRequirement> ?UserServiceRq ?UserServiceRq <http://one-its.net/ontologies/oitsp#satisfyingProcess> ?Process ?Process <http://www.w3.org/2000/01/rdf-schema#label> ?ProcessName . }
What are the services
implementing standardised ITS
functional requirements within
the scope of a virtual
organisation?
VO IRI : http://one-
its.net/ITS_VO/ATIS_GTA
SELECT ?ServiceName WHERE
{ < http://one-its.net/ITS_VO/ATIS_GTA> <http://one-its.net/ontologies/oitsp# describesCollaborationGoal> ?VOGoal . ?VOGoal <http://one-its.net/ontologies/oitsp#describedByUserServiceRequirement> ?UserServiceRq ?UserServiceRq <http://one-its.net/ontologies/oitsp#satisfyingProcess> ?Process ?Process <http://one-its.net/ontologies/oitsp# implementedByEquipmentPackage > ?EquipPackage . ?EquipPackage <http://one-its.net/ontologies/oitsp #definesFunctionalRequirement> ?FnRq . ?FnRq <http://one-its.net/ontologies/ITSOS# implementedByService> ?FnRqService . ?FnRqService < http://www.daml.org/services/owl-s/1.2/Service.owl#presentedBy> ?ServiceProfile . ?ServiceProfile < http://www.daml.org/services/owl-s/1.2/ Profile.owl#serviceName> ?ServiceName . }
Which deployed ITS sensors
support the implementation of a
standardised ITS functional
requirement within the scope of a
virtual organisation?
SELECT ? SensorName WHERE
{ < http://one-its.net/ITS_VO/ATIS_GTA> <http://one-its.net/ontologies/oitsp #describesCollaborationGoal> ?VOGoal .
128
VO IRI : http://one-
its.net/ITS_VO/ATIS_GTA
?VOGoal <http://one-its.net/ontologies/oitsp#describedByUserServiceRequirement> ?UserServiceRq ?UserServiceRq <http://one-its.net/ontologies/oitsp#satisfyingProcess> ?Process ?Process <http://one-its.net/ontologies/oitsp# implementedByEquipmentPackage > ?EquipPackage . ?EquipPackage <http://one-its.net/ontologies/ITSOS# #associatedSensor> ?Sensor . ?Sensor <http://www.w3.org/2000/01/rdf-schema#label> ?SensorName . }
OITS OWL File
<?xml version="1.0"?>
<!DOCTYPE Ontology [
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY xml "http://www.w3.org/XML/1998/namespace" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
]>
<Ontology xmlns="http://www.w3.org/2002/07/owl#"
xml:base="http://www.one-its.net/ontologies/oitsp"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
ontologyIRI=" http://www.one-its.net/ontologies/oitsp"
versionIRI=" http://www.one-its.net/ontologies/oitsp/1.0.0">
<Prefix name="" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="owl" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
<Prefix name="xsd" IRI="http://www.w3.org/2001/XMLSchema#"/>
<Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdf-schema#"/>
<Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:comment"/>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">A
representation of the abstract ITS Processes</Literal>
</Annotation>
<Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">An ontology
for abstract ITS Processes</Literal>
</Annotation>
<Declaration>
<Class IRI="#ArchitectureFlow"/>
</Declaration>
<Declaration>
<Class IRI="#CollaborationGoal"/>
</Declaration>
<Declaration>
<Class IRI="#DataFlow"/>
</Declaration>
<Declaration>
<Class IRI="#EquipmentPackage"/>
129
</Declaration>
<Declaration>
<Class IRI="#EquipmentPackageType"/>
</Declaration>
<Declaration>
<Class IRI="#ExtendedEquipmentPackage"/>
</Declaration>
<Declaration>
<Class IRI="#ExtendedFunctionalRequirement"/>
</Declaration>
<Declaration>
<Class IRI="#ExtendedProcess"/>
</Declaration>
<Declaration>
<Class IRI="#ExtendedUserServiceRequirement"/>
</Declaration>
<Declaration>
<Class IRI="#FunctionalRequirement"/>
</Declaration>
<Declaration>
<Class IRI="#Process"/>
</Declaration>
<Declaration>
<Class IRI="#ServicePackage"/>
</Declaration>
<Declaration>
<Class IRI="#Stakeholder"/>
</Declaration>
<Declaration>
<Class IRI="#StakeholderRole"/>
</Declaration>
<Declaration>
<Class IRI="#Standard"/>
</Declaration>
<Declaration>
<Class IRI="#StandardisedEquipmentPackage"/>
</Declaration>
<Declaration>
<Class IRI="#StandardisedFunctionalRequirement"/>
</Declaration>
<Declaration>
<Class IRI="#StandardisedProcess"/>
</Declaration>
<Declaration>
<Class IRI="#StandardisedUserServiceRequirement"/>
</Declaration>
<Declaration>
<Class IRI="#Terminator"/>
</Declaration>
<Declaration>
<Class IRI="#TerminatorType"/>
</Declaration>
<Declaration>
<Class IRI="#UserService"/>
</Declaration>
<Declaration>
<Class IRI="#UserServiceRequirement"/>
</Declaration>
130
<Declaration>
<Class IRI="#VirtualOrganisation"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#FlowsFrom"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#FlowsTo"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#associatedWith"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#associatedWithProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesCollaborationGoal"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesExtended"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesExtendedEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesExtendedFunctionalRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesExtendedProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesExtendedUserServiceRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#definesFunctionalRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#describedByUserServiceRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#describesCollaborationGoal"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#destinationEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#destinationProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#equipmentPackageDefinedByStakeholder"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#extensionDefinedByStakeholder"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#functionalRequirementDefinedByStakeholder"/>
</Declaration>
<Declaration>
131
<ObjectProperty IRI="#goalOfVirtualOrganisation"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#has"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasArchitectureFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasDataFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasEquipmentPackageType"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasInArchitectureFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasInFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasMember"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasOutArchitectureFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasOutFlow"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasStakeholderRole"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasTerminatorType"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasType"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementedBy"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementedByEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementedByServicePackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implements"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementsProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementsUserService"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implemetedByProcess"/>
132
</Declaration>
<Declaration>
<ObjectProperty IRI="#involvesStakeholderRole"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isPartOf"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isPartOfProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isPartOfServicePackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isPartOfUserRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#isRequiredBy"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#memberOfVirtualOrganisation"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#processDefinedByStakeholder"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#related"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#requires"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#satisfiesUserServiceRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#satisfyingProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sourceEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sourceProcess"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#typeOf"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#typeOfEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#typeOfTerminator"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#userServiceRequirementDefinedByStakeholder"/>
</Declaration>
<Declaration>
<DataProperty IRI="#description"/>
</Declaration>
133
<Declaration>
<DataProperty IRI="#isBundle"/>
</Declaration>
<Declaration>
<DataProperty IRI="#isPrimitiveElement"/>
</Declaration>
<Declaration>
<DataProperty IRI="#isRequestFlow"/>
</Declaration>
<Declaration>
<DataProperty IRI="#isResponseFlow"/>
</Declaration>
<Declaration>
<DataProperty IRI="#standardDevelopmentOrganisation"/>
</Declaration>
<Declaration>
<DataProperty IRI="#standardGroup"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#CI"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#CentreEquipmentPackage"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#CentreTerminator"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Consumer"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Cycling"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#DRE"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#FieldEquipmentPackage"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#FieldTerminator"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Freight"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#ISP"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#MCO"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Parking"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#PublicSafety"/>
</Declaration>
<Declaration>
134
<NamedIndividual IRI="#RailRoads"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Toll"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Traffic"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#Transit"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#TravellerEquipmentPackage"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#TravellerTerminator"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#VehicleEquipmentPackage"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#VehicleTerminator"/>
</Declaration>
<Declaration>
<NamedIndividual IRI="#WAA"/>
</Declaration>
<SubClassOf>
<Class IRI="#ArchitectureFlow"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#related"/>
<Class IRI="#DataFlow"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#CollaborationGoal"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#goalOfVirtualOrganisation"/>
<Class IRI="#VirtualOrganisation"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#DataFlow"/>
<DataExactCardinality cardinality="1">
<DataProperty IRI="#isPrimitiveElement"/>
</DataExactCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#DataFlow"/>
<DataMaxCardinality cardinality="1">
<DataProperty IRI="#isRequestFlow"/>
</DataMaxCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#DataFlow"/>
<DataMaxCardinality cardinality="1">
<DataProperty IRI="#isResponseFlow"/>
</DataMaxCardinality>
</SubClassOf>
135
<SubClassOf>
<Class IRI="#EquipmentPackage"/>
<ObjectExactCardinality cardinality="1">
<ObjectProperty IRI="#hasEquipmentPackageType"/>
<Class IRI="#EquipmentPackageType"/>
</ObjectExactCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#ExtendedEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#ExtendedFunctionalRequirement"/>
<Class IRI="#FunctionalRequirement"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#ExtendedProcess"/>
<Class IRI="#Process"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#ExtendedUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#Standard"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#related"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#StandardisedEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#StandardisedFunctionalRequirement"/>
<Class IRI="#FunctionalRequirement"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#StandardisedProcess"/>
<Class IRI="#Process"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#StandardisedProcess"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#satisfiesUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#StandardisedUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#Terminator"/>
<ObjectExactCardinality cardinality="1">
<ObjectProperty IRI="#hasTerminatorType"/>
<Class IRI="#TerminatorType"/>
136
</ObjectExactCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#UserService"/>
<DataExactCardinality cardinality="1">
<DataProperty IRI="#isBundle"/>
</DataExactCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#UserServiceRequirement"/>
<ObjectMinCardinality cardinality="1">
<ObjectProperty IRI="#isRequiredBy"/>
<Class IRI="#UserService"/>
</ObjectMinCardinality>
</SubClassOf>
<SubClassOf>
<Class IRI="#UserServiceRequirement"/>
<DataMaxCardinality cardinality="1">
<DataProperty IRI="#description"/>
</DataMaxCardinality>
</SubClassOf>
<DisjointClasses>
<Class IRI="#ArchitectureFlow"/>
<Class IRI="#CollaborationGoal"/>
<Class IRI="#DataFlow"/>
<Class IRI="#FunctionalRequirement"/>
<Class IRI="#Process"/>
<Class IRI="#ServicePackage"/>
<Class IRI="#Stakeholder"/>
<Class IRI="#StakeholderRole"/>
<Class IRI="#Standard"/>
<Class IRI="#Terminator"/>
<Class IRI="#UserService"/>
<Class IRI="#UserServiceRequirement"/>
<Class IRI="#VirtualOrganisation"/>
</DisjointClasses>
<DisjointClasses>
<Class IRI="#ExtendedEquipmentPackage"/>
<Class IRI="#StandardisedEquipmentPackage"/>
</DisjointClasses>
<DisjointClasses>
<Class IRI="#ExtendedFunctionalRequirement"/>
<Class IRI="#StandardisedFunctionalRequirement"/>
</DisjointClasses>
<DisjointClasses>
<Class IRI="#ExtendedProcess"/>
<Class IRI="#StandardisedProcess"/>
</DisjointClasses>
<DisjointClasses>
<Class IRI="#ExtendedUserServiceRequirement"/>
<Class IRI="#StandardisedUserServiceRequirement"/>
</DisjointClasses>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#CI"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#EquipmentPackageType"/>
137
<NamedIndividual IRI="#CentreEquipmentPackage"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#TerminatorType"/>
<NamedIndividual IRI="#CentreTerminator"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Consumer"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Cycling"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#DRE"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#EquipmentPackageType"/>
<NamedIndividual IRI="#FieldEquipmentPackage"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#TerminatorType"/>
<NamedIndividual IRI="#FieldTerminator"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Freight"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#ISP"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#MCO"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Parking"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#PublicSafety"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#RailRoads"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Toll"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Traffic"/>
</ClassAssertion>
138
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#Transit"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#EquipmentPackageType"/>
<NamedIndividual IRI="#TravellerEquipmentPackage"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#TerminatorType"/>
<NamedIndividual IRI="#TravellerTerminator"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#EquipmentPackageType"/>
<NamedIndividual IRI="#VehicleEquipmentPackage"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#TerminatorType"/>
<NamedIndividual IRI="#VehicleTerminator"/>
</ClassAssertion>
<ClassAssertion>
<Class IRI="#StakeholderRole"/>
<NamedIndividual IRI="#WAA"/>
</ClassAssertion>
<SubObjectPropertyOf>
<ObjectProperty IRI="#FlowsTo"/>
<ObjectProperty abbreviatedIRI="owl:topObjectProperty"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#associatedWithProcess"/>
<ObjectProperty IRI="#associatedWith"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#definesExtendedEquipmentPackage"/>
<ObjectProperty IRI="#definesExtended"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#definesExtendedFunctionalRequirement"/>
<ObjectProperty IRI="#definesExtended"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#definesExtendedProcess"/>
<ObjectProperty IRI="#definesExtended"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#definesExtendedUserServiceRequirement"/>
<ObjectProperty IRI="#definesExtended"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#destinationEquipmentPackage"/>
<ObjectProperty IRI="#FlowsTo"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#destinationProcess"/>
<ObjectProperty IRI="#FlowsTo"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#equipmentPackageDefinedByStakeholder"/>
139
<ObjectProperty IRI="#extensionDefinedByStakeholder"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#functionalRequirementDefinedByStakeholder"/>
<ObjectProperty IRI="#extensionDefinedByStakeholder"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasArchitectureFlow"/>
<ObjectProperty IRI="#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasDataFlow"/>
<ObjectProperty IRI="#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasEquipmentPackageType"/>
<ObjectProperty IRI="#hasType"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasInArchitectureFlow"/>
<ObjectProperty IRI="#hasArchitectureFlow"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasInFlow"/>
<ObjectProperty IRI="#hasDataFlow"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasOutArchitectureFlow"/>
<ObjectProperty IRI="#hasArchitectureFlow"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasOutFlow"/>
<ObjectProperty IRI="#hasDataFlow"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasStakeholderRole"/>
<ObjectProperty IRI="#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasTerminatorType"/>
<ObjectProperty IRI="#hasType"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasType"/>
<ObjectProperty IRI="#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementedByEquipmentPackage"/>
<ObjectProperty IRI="#implementedBy"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementedByServicePackage"/>
<ObjectProperty IRI="#implementedBy"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementsProcess"/>
<ObjectProperty IRI="#implements"/>
</SubObjectPropertyOf>
140
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementsUserService"/>
<ObjectProperty IRI="#implements"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implemetedByProcess"/>
<ObjectProperty IRI="#implementedBy"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isPartOfProcess"/>
<ObjectProperty IRI="#isPartOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isPartOfServicePackage"/>
<ObjectProperty IRI="#isPartOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#isPartOfUserRequirement"/>
<ObjectProperty IRI="#isPartOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#processDefinedByStakeholder"/>
<ObjectProperty IRI="#extensionDefinedByStakeholder"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#sourceEquipmentPackage"/>
<ObjectProperty IRI="#FlowsFrom"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#sourceProcess"/>
<ObjectProperty IRI="#FlowsFrom"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#typeOf"/>
<ObjectProperty abbreviatedIRI="owl:topObjectProperty"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#typeOfEquipmentPackage"/>
<ObjectProperty IRI="#typeOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#typeOfTerminator"/>
<ObjectProperty IRI="#typeOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#userServiceRequirementDefinedByStakeholder"/>
<ObjectProperty IRI="#extensionDefinedByStakeholder"/>
</SubObjectPropertyOf>
<InverseObjectProperties>
<ObjectProperty IRI="#involvesStakeholderRole"/>
<ObjectProperty IRI="#associatedWithProcess"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#definesCollaborationGoal"/>
<ObjectProperty IRI="#goalOfVirtualOrganisation"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#equipmentPackageDefinedByStakeholder"/>
141
<ObjectProperty IRI="#definesExtendedEquipmentPackage"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#functionalRequirementDefinedByStakeholder"/>
<ObjectProperty IRI="#definesExtendedFunctionalRequirement"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#definesExtendedProcess"/>
<ObjectProperty IRI="#processDefinedByStakeholder"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#userServiceRequirementDefinedByStakeholder"/>
<ObjectProperty IRI="#definesExtendedUserServiceRequirement"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#implementedByEquipmentPackage"/>
<ObjectProperty IRI="#definesFunctionalRequirement"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#describedByUserServiceRequirement"/>
<ObjectProperty IRI="#describesCollaborationGoal"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasInArchitectureFlow"/>
<ObjectProperty IRI="#destinationEquipmentPackage"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasInFlow"/>
<ObjectProperty IRI="#destinationProcess"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#typeOfEquipmentPackage"/>
<ObjectProperty IRI="#hasEquipmentPackageType"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasMember"/>
<ObjectProperty IRI="#memberOfVirtualOrganisation"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#sourceEquipmentPackage"/>
<ObjectProperty IRI="#hasOutArchitectureFlow"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasOutFlow"/>
<ObjectProperty IRI="#sourceProcess"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#hasTerminatorType"/>
<ObjectProperty IRI="#typeOfTerminator"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#implementedByServicePackage"/>
<ObjectProperty IRI="#implementsUserService"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#implementsProcess"/>
<ObjectProperty IRI="#implemetedByProcess"/>
</InverseObjectProperties>
142
<InverseObjectProperties>
<ObjectProperty IRI="#requires"/>
<ObjectProperty IRI="#isRequiredBy"/>
</InverseObjectProperties>
<InverseObjectProperties>
<ObjectProperty IRI="#satisfyingProcess"/>
<ObjectProperty IRI="#satisfiesUserServiceRequirement"/>
</InverseObjectProperties>
<SymmetricObjectProperty>
<ObjectProperty IRI="#related"/>
</SymmetricObjectProperty>
<TransitiveObjectProperty>
<ObjectProperty IRI="#isPartOf"/>
</TransitiveObjectProperty>
<ObjectPropertyDomain>
<ObjectProperty IRI="#associatedWithProcess"/>
<Class IRI="#StakeholderRole"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesCollaborationGoal"/>
<Class IRI="#VirtualOrganisation"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesExtendedEquipmentPackage"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesExtendedFunctionalRequirement"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesExtendedProcess"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesExtendedUserServiceRequirement"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#definesFunctionalRequirement"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#describedByUserServiceRequirement"/>
<Class IRI="#CollaborationGoal"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#describesCollaborationGoal"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#destinationEquipmentPackage"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#destinationProcess"/>
<Class IRI="#DataFlow"/>
</ObjectPropertyDomain>
143
<ObjectPropertyDomain>
<ObjectProperty IRI="#equipmentPackageDefinedByStakeholder"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#functionalRequirementDefinedByStakeholder"/>
<Class IRI="#FunctionalRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#goalOfVirtualOrganisation"/>
<Class IRI="#CollaborationGoal"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasArchitectureFlow"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasDataFlow"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasEquipmentPackageType"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasInArchitectureFlow"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasInFlow"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasMember"/>
<Class IRI="#VirtualOrganisation"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasOutArchitectureFlow"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasOutFlow"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasStakeholderRole"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasTerminatorType"/>
<Class IRI="#Terminator"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementedByEquipmentPackage"/>
<Class IRI="#FunctionalRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementsProcess"/>
144
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementsUserService"/>
<Class IRI="#ServicePackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#involvesStakeholderRole"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#isPartOfProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#isPartOfServicePackage"/>
<ObjectUnionOf>
<Class IRI="#EquipmentPackage"/>
<Class IRI="#Terminator"/>
</ObjectUnionOf>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#isPartOfUserRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#isRequiredBy"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#memberOfVirtualOrganisation"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#processDefinedByStakeholder"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#related"/>
<ObjectUnionOf>
<Class IRI="#ArchitectureFlow"/>
<Class IRI="#DataFlow"/>
<Class IRI="#Standard"/>
</ObjectUnionOf>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#requires"/>
<Class IRI="#UserService"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#satisfiesUserServiceRequirement"/>
<Class IRI="#Process"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#satisfyingProcess"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
145
<ObjectProperty IRI="#sourceEquipmentPackage"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#sourceProcess"/>
<Class IRI="#DataFlow"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#typeOfEquipmentPackage"/>
<Class IRI="#EquipmentPackageType"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#typeOfTerminator"/>
<Class IRI="#TerminatorType"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#userServiceRequirementDefinedByStakeholder"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyRange>
<ObjectProperty IRI="#associatedWithProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesCollaborationGoal"/>
<Class IRI="#CollaborationGoal"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesExtendedEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesExtendedFunctionalRequirement"/>
<Class IRI="#FunctionalRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesExtendedProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesExtendedUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#definesFunctionalRequirement"/>
<Class IRI="#FunctionalRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#describedByUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#describesCollaborationGoal"/>
<Class IRI="#CollaborationGoal"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#destinationEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
146
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#destinationProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#equipmentPackageDefinedByStakeholder"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#functionalRequirementDefinedByStakeholder"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#goalOfVirtualOrganisation"/>
<Class IRI="#VirtualOrganisation"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasArchitectureFlow"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasDataFlow"/>
<Class IRI="#DataFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasEquipmentPackageType"/>
<Class IRI="#EquipmentPackageType"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasInArchitectureFlow"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasInFlow"/>
<Class IRI="#DataFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasMember"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasOutArchitectureFlow"/>
<Class IRI="#ArchitectureFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasOutFlow"/>
<Class IRI="#DataFlow"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasStakeholderRole"/>
<Class IRI="#StakeholderRole"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasTerminatorType"/>
<Class IRI="#TerminatorType"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
147
<ObjectProperty IRI="#implementedByEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#implementsProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#implementsUserService"/>
<Class IRI="#UserService"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#involvesStakeholderRole"/>
<Class IRI="#StakeholderRole"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#isPartOfProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#isPartOfServicePackage"/>
<Class IRI="#ServicePackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#isPartOfUserRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#isRequiredBy"/>
<Class IRI="#UserService"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#memberOfVirtualOrganisation"/>
<Class IRI="#VirtualOrganisation"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#processDefinedByStakeholder"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#requires"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#satisfiesUserServiceRequirement"/>
<Class IRI="#UserServiceRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#satisfyingProcess"/>
<Class IRI="#Process"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#sourceEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#sourceProcess"/>
<Class IRI="#Process"/>
148
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#typeOfEquipmentPackage"/>
<Class IRI="#EquipmentPackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#typeOfTerminator"/>
<Class IRI="#Terminator"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#userServiceRequirementDefinedByStakeholder"/>
<Class IRI="#Stakeholder"/>
</ObjectPropertyRange>
<DataPropertyDomain>
<DataProperty IRI="#isBundle"/>
<Class IRI="#UserService"/>
</DataPropertyDomain>
<DataPropertyDomain>
<DataProperty IRI="#isPrimitiveElement"/>
<Class IRI="#DataFlow"/>
</DataPropertyDomain>
<DataPropertyDomain>
<DataProperty IRI="#isRequestFlow"/>
<Class IRI="#DataFlow"/>
</DataPropertyDomain>
<DataPropertyDomain>
<DataProperty IRI="#isResponseFlow"/>
<Class IRI="#DataFlow"/>
</DataPropertyDomain>
<DataPropertyDomain>
<DataProperty IRI="#standardDevelopmentOrganisation"/>
<Class IRI="#Standard"/>
</DataPropertyDomain>
<DataPropertyDomain>
<DataProperty IRI="#standardGroup"/>
<Class IRI="#Standard"/>
</DataPropertyDomain>
<DataPropertyRange>
<DataProperty IRI="#description"/>
<Datatype abbreviatedIRI="xsd:string"/>
</DataPropertyRange>
<DataPropertyRange>
<DataProperty IRI="#isBundle"/>
<Datatype abbreviatedIRI="xsd:boolean"/>
</DataPropertyRange>
<DataPropertyRange>
<DataProperty IRI="#isPrimitiveElement"/>
<Datatype abbreviatedIRI="xsd:boolean"/>
</DataPropertyRange>
<DataPropertyRange>
<DataProperty IRI="#isRequestFlow"/>
<Datatype abbreviatedIRI="xsd:boolean"/>
</DataPropertyRange>
<DataPropertyRange>
<DataProperty IRI="#isResponseFlow"/>
<Datatype abbreviatedIRI="xsd:boolean"/>
</DataPropertyRange>
<DataPropertyRange>
149
<DataProperty IRI="#standardDevelopmentOrganisation"/>
<Datatype abbreviatedIRI="xsd:string"/>
</DataPropertyRange>
<DataPropertyRange>
<DataProperty IRI="#standardGroup"/>
<Datatype abbreviatedIRI="xsd:string"/>
</DataPropertyRange>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#CI</IRI>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">Community
Involvement</Literal>
</AnnotationAssertion>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#DRE</IRI>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">The Disaster
Response and Evacuation</Literal>
</AnnotationAssertion>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#ISP</IRI>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">Information
Service Provider</Literal>
</AnnotationAssertion>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#MCO</IRI>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">Maintenance
and Construction Operations</Literal>
</AnnotationAssertion>
<AnnotationAssertion>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<IRI>#WAA</IRI>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">Wide Area
Alert</Literal>
</AnnotationAssertion>
</Ontology>
ITSoS OWL File
<?xml version="1.0"?>
<!DOCTYPE Ontology [
<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" >
<!ENTITY xml "http://www.w3.org/XML/1998/namespace" >
<!ENTITY rdfs "http://www.w3.org/2000/01/rdf-schema#" >
<!ENTITY rdf "http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
]>
<Ontology xmlns="http://www.w3.org/2002/07/owl#"
xml:base="http://www.one-its.net/ontologies/ITSoS"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
150
ontologyIRI="http://www.one-its.net/ontologies/ITSoS"
versionIRI="http://www.one-its.net/ontologies/ITSoS/1.0.0">
<Prefix name="" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="owl" IRI="http://www.w3.org/2002/07/owl#"/>
<Prefix name="rdf" IRI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
<Prefix name="xsd" IRI="http://www.w3.org/2001/XMLSchema#"/>
<Prefix name="rdfs" IRI="http://www.w3.org/2000/01/rdf-schema#"/>
<Import>http://purl.oclc.org/NET/ssnx/ssn</Import>
<Import>http://www.pms.ifi.uni-muenchen.de/OTN</Import>
<Import>http://www.daml.org/services/owl-s/1.2/Grounding.owl</Import>
<Import>http://www.daml.org/services/owl-s/1.2/Service.owl</Import>
<Import>http://www.daml.org/services/owl-s/1.2/Profile.owl</Import>
<Import> http://www.one-its.net/ontologies/oitsp/1.0.0</Import> <Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:seeAlso"/>
<Literal xml:lang="en"
datatypeIRI="&rdf;PlainLiteral">https://www.w3.org/TR/vocab-ssn/</Literal>
</Annotation>
<Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:seeAlso"/>
<Literal xml:lang="en"
datatypeIRI="&rdf;PlainLiteral">https://www.w3.org/Submission/OWL-
S/</Literal>
</Annotation>
<Annotation>
<AnnotationProperty abbreviatedIRI="rdfs:label"/>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">An Intelligent
Transportation System of Systems</Literal>
</Annotation>
<Annotation>
<AnnotationProperty IRI="http://purl.org/dc/elements/1.1/creator"/>
<Literal xml:lang="en" datatypeIRI="&rdf;PlainLiteral">Mohamed
Elshenawy</Literal>
</Annotation>
<Declaration>
<Class IRI="#SharedDevice"/>
</Declaration>
<Declaration>
<Class IRI="#SharedResource"/>
</Declaration>
<Declaration>
<Class IRI="#SharedSensor"/>
</Declaration>
<Declaration>
<Class IRI="#SharedService"/>
</Declaration>
<Declaration>
<Class IRI="#VirtualOrganisationMember"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#associatedEquipmentPackage"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#associatedSensor"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#associatedService"/>
</Declaration>
151
<Declaration>
<ObjectProperty IRI="#hasSensor"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#hasService"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementedBySensor"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementedByService"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#implementsFunctionalRequirement"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sharedByStakeholder"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sharesResource"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sharesSensor"/>
</Declaration>
<Declaration>
<ObjectProperty IRI="#sharesService"/>
</Declaration>
<EquivalentClasses>
<Class IRI="#SharedDevice"/>
<ObjectIntersectionOf>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Device"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#sharedByStakeholder"/>
<Class IRI="#VirtualOrganisationMember"/>
</ObjectAllValuesFrom>
</ObjectIntersectionOf>
</EquivalentClasses>
<EquivalentClasses>
<Class IRI="#SharedResource"/>
<ObjectUnionOf>
<Class IRI="#SharedDevice"/>
<Class IRI="#SharedSensor"/>
<Class IRI="#SharedService"/>
</ObjectUnionOf>
</EquivalentClasses>
<EquivalentClasses>
<Class IRI="#SharedSensor"/>
<ObjectIntersectionOf>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#sharedByStakeholder"/>
<Class IRI="#VirtualOrganisationMember"/>
</ObjectAllValuesFrom>
</ObjectIntersectionOf>
</EquivalentClasses>
<EquivalentClasses>
<Class IRI="#SharedService"/>
<ObjectIntersectionOf>
152
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="#sharedByStakeholder"/>
<Class IRI="#VirtualOrganisationMember"/>
</ObjectAllValuesFrom>
</ObjectIntersectionOf>
</EquivalentClasses>
<EquivalentClasses>
<Class IRI="#VirtualOrganisationMember"/>
<ObjectIntersectionOf>
<Class IRI="http:// http://www.one-
its.net/ontologies/oitsp#Stakeholder"/>
<ObjectAllValuesFrom>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#memberOfVirtualOrganisation"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#VirtualOrganisation"/>
</ObjectAllValuesFrom>
</ObjectIntersectionOf>
</EquivalentClasses>
<SubClassOf>
<Class IRI="#SharedDevice"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Device"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#SharedSensor"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#SharedService"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</SubClassOf>
<SubClassOf>
<Class IRI="#VirtualOrganisationMember"/>
<Class IRI=" http://www.one-its.net/ontologies/oitsp#Stakeholder"/> </SubClassOf>
<SubClassOf>
<Class IRI="http://www.one-its.net/ontologies/oitsp#DataFlow"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Process.owl#Parameter"/>
</SubClassOf>
<SubClassOf>
<Class IRI="http://www.one-its.net/ontologies/oitsp#Process"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Process.owl#SimpleProcess"/>
</SubClassOf>
<SubClassOf>
<Class IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#Composite_Attributes"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Property"/>
</SubClassOf>
<SubClassOf>
<Class IRI="http://www.pms.ifi.uni-muenchen.de/OTN#Feature"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#FeatureOfInterest"/>
</SubClassOf>
<SubObjectPropertyOf>
153
<ObjectProperty IRI="#associatedEquipmentPackage"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#associatedWith"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#associatedSensor"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#associatedWith"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#associatedService"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#associatedWith"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasSensor"/>
<ObjectProperty IRI="http://www.one-its.net/ontologies/oitsp#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#hasService"/>
<ObjectProperty IRI="http://www.one-its.net/ontologies/oitsp#has"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementedBySensor"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#implementedBy"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementedByService"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#implementedBy"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#implementsFunctionalRequirement"/>
<ObjectProperty IRI="http://www.one-
its.net/ontologies/oitsp#implements"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#sharesSensor"/>
<ObjectProperty IRI="#sharesResource"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="#sharesService"/>
<ObjectProperty IRI="#sharesResource"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#accident"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#average_Vehicle_Speed"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
154
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#blocked_Passage"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#construction_Status"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#direction_of_Traffic_Flow"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#divider"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#emergency_Vehicle_Lane"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#form_of_Way"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#house_Number_Range"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#location_Reference"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#maximum_Height_Allowed"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#maximum_Length_Allowed"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
155
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#maximum_Number_of_Lanes"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#maximum_Total_Weight_Allowed"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#maximum_Width_Allowed"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#minimum_Number_of_Lanes"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#number_of_Lanes"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#road_Surface"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#special_Restriction"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#timetable"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-muenchen.de/OTN#toll"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#traffic_Jam_Sensitivity"/>
156
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<SubObjectPropertyOf>
<ObjectProperty IRI="http://www.pms.ifi.uni-
muenchen.de/OTN#validity_Period"/>
<ObjectProperty
IRI="http://purl.oclc.org/NET/ssnx/ssn#isPropertyOf"/>
</SubObjectPropertyOf>
<InverseObjectProperties>
<ObjectProperty IRI="#sharedByStakeholder"/>
<ObjectProperty IRI="#sharesResource"/>
</InverseObjectProperties>
<ObjectPropertyDomain>
<ObjectProperty IRI="#associatedEquipmentPackage"/>
<ObjectUnionOf>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectUnionOf>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#associatedSensor"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#associatedService"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#EquipmentPackage"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasSensor"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#hasService"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementedBySensor"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#FunctionalRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementedByService"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#FunctionalRequirement"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#implementsFunctionalRequirement"/>
<ObjectUnionOf>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectUnionOf>
</ObjectPropertyDomain>
157
<ObjectPropertyDomain>
<ObjectProperty IRI="#sharedByStakeholder"/>
<ObjectUnionOf>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectUnionOf>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#sharesSensor"/>
<Class IRI="http://www.one-its.net/ontologies/oitsp#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyDomain>
<ObjectProperty IRI="#sharesService"/>
<Class IRI="http://www.one-its.net/ontologies/oitsp#Stakeholder"/>
</ObjectPropertyDomain>
<ObjectPropertyRange>
<ObjectProperty IRI="#associatedEquipmentPackage"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#EquipmentPackage"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#associatedSensor"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#associatedService"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasSensor"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#hasService"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#implementedBySensor"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#implementedByService"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#implementsFunctionalRequirement"/>
<Class IRI="http://www.one-
its.net/ontologies/oitsp#FunctionalRequirement"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#sharedByStakeholder"/>
<Class IRI="http://www.one-its.net/ontologies/oitsp#Stakeholder"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
158
<ObjectProperty IRI="#sharesSensor"/>
<Class IRI="http://purl.oclc.org/NET/ssnx/ssn#Sensor"/>
</ObjectPropertyRange>
<ObjectPropertyRange>
<ObjectProperty IRI="#sharesService"/>
<Class IRI="http://www.daml.org/services/owl-
s/1.2/Service.owl#Service"/>
</ObjectPropertyRange>
</Ontology>
159
Appendix B: Supplementary Information for Chapter 6
Example 1: Sample XML Feed of Traffic Sensor devices
<?xml version='1.0' encoding='UTF-8'?>
<vdsDataSet>
<timeFrameNumber>1363</timeFrameNumber>
<date>2014-01-15</date>
<vdsData>
<vdsId>1410</vdsId>
<contractId>QEWDE0490DWS</contractId>
<validThisPeriod>true</validThisPeriod>
<periodNum>1363</periodNum>
<technology>EVC</technology>
<occ>14</occ>
<vol>29</vol>
<spd>83</spd>
</vdsData>
<vdsData>
<vdsId>941</vdsId>
<contractId>401DW0180DWC</contractId>
<validThisPeriod>true</validThisPeriod>
<periodNum>1363</periodNum>
<technology>EVC</technology>
<occ>6</occ>
<vol>15</vol>
<spd>99</spd>
</vdsData>
</vdsDataSet>
Example 2: Sample smooks configuration file
<?xml version='1.0' encoding='UTF-8'?>
<smooks-resource-list xmlns="http://www.milyn.org/xsd/smooks-1.0.xsd">
<resource-config selector="vdsDataSet">
<resource type="xsl">
<
160
http://www.one-
its.net/transport/traffic/sensors/measuring_capability/dual_loop_detec
tor
</measuring-capability>
<xsl:variable name="date" select="./date" />
<xsl:for-each select="./vdsData">
<observation>
<date><xsl:value-of select="$date" /></date>
<observation-sampling-time-sec>
20
</observation-sampling-time-sec>
<observation-result-time>
<xsl:value-of select="number(periodNum)*20" />
</observation-result-time>
<sensor><xsl:value-of select="contractId" /></sensor>
<property>
http://ITS-CPS.net/transport/property/speed
</property>
<observation-value>
<value><xsl:value-of select="number(spd)" /></value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/speed/km-per-hr
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date><xsl:value-of select="$date" /></date>
<observation-sampling-time-sec>
20
</observation-sampling-time-sec>
<observation-result-time>
<xsl:value-of select="number(periodNum)*20" />
</observation-result-time>
<sensor><xsl:value-of select="contractId" /></sensor>
<property>
http://ITS-CPS.net/transport/property/volume
</property>
<observation-value>
<value><xsl:value-of select="number(vol)" /></value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/volume/num-of-vehicles
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date><xsl:value-of select="$date" /></date>
<observation-sampling-time-sec>
20
</observation-sampling-time-sec>
<observation-result-time>
<xsl:value-of select="number(periodNum)*20" />
</observation-result-time>
<sensor><xsl:value-of select="contractId" /></sensor>
161
<property>
http://ITS-CPS.net/transport/property/detector_occupancy
</property>
<observation-value>
<value><xsl:value-of select="number(occ)" /></value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/occupancy/percentage
</unit-of-measurement>
</observation-value>
</observation>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
]]>
</resource>
<param name="is-xslt-templatelet">false</param>
</resource-config>
</smooks-resource-list>
Example 3: Sample output file
<?xml version='1.0' encoding='UTF-8'?>
<stakeholder>
http://ITS-CPS.net/transport/ontario/mto
</stakeholder>
<deployment>
http://ITS-CPS.net/transport/ontario/mto_hw401
</deployment>
<measuring-capability>
http://ITS-
CPS.net/transport/traffic/sensors/measuring_capability/dual_loop_detec
tor
</measuring-capability>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>QEWDE0490DWS</sensor>
<property>
http://ITS-CPS.net/transport/property/speed
</property>
<observation-value>
<value>83</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/speed/km-per-hr
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
162
<sensor>QEWDE0490DWS</sensor>
<property>
http://ITS-CPS.net/transport/property/volume
</property>
<observation-value>
<value>29</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/volume/num-of-vehicles
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>QEWDE0490DWS</sensor>
<property>
http://ITS-CPS.net/transport/property/detector_occupancy
</property>
<observation-value>
<value>14</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/occupancy/percentage
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>401DW0180DWC</sensor>
<property>
http://ITS-CPS.net/transport/property/speed
</property>
<observation-value>
<value>99</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/speed/km-per-hr
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>401DW0180DWC</sensor>
<property>
http://ITS-CPS.net/transport/property/volume
</property>
<observation-value>
<value>15</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/volume/num-of-vehicles
163
</unit-of-measurement>
</observation-value>
</observation>
<observation>
<date>2014-01-15</date>
<observation-sampling-time-sec>20</observation-sampling-time-sec>
<observation-result-time>27260</observation-result-time>
<sensor>401DW0180DWC</sensor>
<property>
http://ITS-CPS.net/transport/property/detector_occupancy
</property>
<observation-value>
<value>6</value>
<unit-of-measurement>
http://ITS-CPS.net/transport/unit/occupancy/percentage
</unit-of-measurement>
</observation-value>
</observation>
Example 4: ESB Service Description (WSDL file)
<wsdl:definitions
targetNamespace="http://soa.jboss.org/GTATransitService"
xmlns:esbns="http://www.one-its.net/its"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://soa.jboss.org/GTATransitService"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<wsdl:types>
<xs:schema targetNamespace="http://www.one-its.net/its"
version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="http://www.one-
its.net/GTA_Transit_Service/ebws/GTATransitService/GTAStopsService?wsd
l&resource=request.xsd"/>
</xs:schema>
<xs:schema targetNamespace="http://www.one-its.net/its"
version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="http://www.one-
its.net:8080/GTA_Transit_Service/ebws/GTATransitService/GTAStopsServic
e?wsdl&resource=response.xsd"/>
</xs:schema>
<xs:schema targetNamespace="http://www.one-its.net/its"
version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:include schemaLocation="http://www.one-
its.net/GTA_Transit_Service/ebws/GTATransitService/GTAStopsService?wsd
l&resource=fault.xsd"/>
</xs:schema>
</wsdl:types>
<wsdl:message name="GTAStopsServiceRes">
<wsdl:part element="esbns:outputs" name="out"/>
</wsdl:message>
<wsdl:message name="GTAStopsServiceFault1">
164
<wsdl:part element="esbns:itsFault" name="fault1"/>
</wsdl:message>
<wsdl:message name="GTAStopsServiceReq">
<wsdl:part element="esbns:inputs" name="in"/>
</wsdl:message>
<wsdl:portType name="GTAStopsServicePortType">
<wsdl:operation name="GTAStopsServiceOp">
<wsdl:input message="tns:GTAStopsServiceReq"
name="GTAStopsServiceReq"/>
<wsdl:output message="tns:GTAStopsServiceRes"
name="GTAStopsServiceRes"/>
<wsdl:fault message="tns:GTAStopsServiceFault1"
name="fault1"/>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="GTAStopsServiceBinding"
type="tns:GTAStopsServicePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="GTAStopsServiceOp">
<soap:operation soapAction=
"http://soa.jboss.org/GTATransitService/GTAStopsServiceOp"/>
<wsdl:input name="GTAStopsServiceReq">
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output name="GTAStopsServiceRes">
<soap:body use="literal"/>
</wsdl:output>
<wsdl:fault name="fault1">
<soap:fault name="fault1" use="literal"/>
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="GTAStopsServiceService">
<wsdl:port binding="tns:GTAStopsServiceBinding"
name="GTAStopsServicePortType">
<soap:address location="http://www.one-
its.net/GTA_Transit_Service/ebws/GTATransitService/GTAStopsService"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
Example 5: Service Monitoring Tool
165
Example 6: The Endpoint Implementation of the IncidentListInqRq Service
package net.oneits.soa.ws;
import java.io.ByteArrayInputStream;
import java.io.InputStream;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import javax.xml.datatype.DatatypeConfigurationException;
import net.oneits.domainobject.*;
import net.oneits.soa.core.BaseWSEndPoint;
import net.oneits.soa.gaid.GaidResult;
import net.oneits.soa.gaid.GaidResultRow;
import net.oneits.soa.msg.*;
import net.oneits.soa.service.IncidentService;
import org.springframework.ws.server.endpoint.annotation.Endpoint;
import org.springframework.ws.server.endpoint.annotation.PayloadRoot;
@Endpoint
public class IncidentInqEndPoint<createAutomaticIncidentDetectionRs> extends
BaseWSEndPoint {
private IncidentService incidentService;
final String IncidentListInqRq = "IncidentListInqRq";
final String IncidentVicinityCamerasInqRq =
"IncidentVicinityCamerasInqRq";
final String IncidentVicinityVdsesInqRq = "IncidentVicinityVdsesInqRq";
final String IncidentUpdatesInqRq = "IncidentUpdatesInqRq";
final String IncidentGetRq = "IncidentGetRq";
final String AutomaticIncidentDetectionRq =
"AutomaticIncidentDetectionRq";
public void setIncidentService(IncidentService incidentService) {
this.incidentService = incidentService;
}
@PayloadRoot(localPart = AutomaticIncidentDetectionRq, namespace =
MESSAGES_NAMESPACE)
public AutomaticIncidentDetectionRs
processAutomaticIncidentDetection(AutomaticIncidentDetectionRq request)
throws DatatypeConfigurationException {
166
AutomaticIncidentDetectionRs response =
objectFactory.createAutomaticIncidentDetectionRs();
InputStream
comparisonIncidentIS=(request.getComparsionIncidentFile()==null||request.getC
omparsionIncidentFile().length==0)?
null:new
ByteArrayInputStream(request.getComparsionIncidentFile());
InputStream
comparisonNormalIS=(request.getComparsionNormalFile()==null||request.getCompa
rsionNormalFile().length==0)?
null:new
ByteArrayInputStream(request.getComparsionNormalFile());
InputStream
segmaIS=(request.getSegmaFile()==null||request.getSegmaFile().length==0)?
null:new ByteArrayInputStream(request.getSegmaFile());
logger.info(" The requested time stamp =
"+request.getStartTimestamp());
GaidResult rs= null;
try{
if(request.getInputTestFile()!=null){
rs=
incidentService.processAutomaticIncidentDetectionByUploadedFile(
comparisonIncidentIS,comparisonNormalIS,new
ByteArrayInputStream(request.getInputTestFile())
,segmaIS,request.getStartTimestamp(),request.getIntervalSeconds());
}else{
rs= incidentService.processAutomaticIncidentDetectionByVds(
comparisonIncidentIS,comparisonNormalIS,segmaIS,request.getVdsDeviceId());
}
}catch(Throwable ex){
response.setErrorMessage(ex.getMessage());
return response;
}
for(GaidResultRow row:rs.getRows()){
DetectionLine line=new DetectionLine();
for(double a:row.getDetectionArray())
line.getItem().add(a);
line.setTimestep(row.getTimestep());
response.getDetectionArray().add(line);
}
response.setCorrectIncidentClassification(rs.getCorrectIncidentClassification
());
response.setCorrectNormalClassification(rs.getCorrectNormalClassification());
response.setDetectionRate(rs.getDetectionRate());
response.setFalseAlarmRate(rs.getFalseAlarmRate());
response.setFitness(rs.getFitness());
response.setGraph(rs.getGraph());
return response;
}
@PayloadRoot(localPart = IncidentListInqRq, namespace =
MESSAGES_NAMESPACE)
public IncidentListInqRs findIncidentList(IncidentListInqRq request)
throws DatatypeConfigurationException {
167
IncidentListInqRs response = objectFactory.createIncidentListInqRs();
Map<String, Object> searchBy =new HashMap<String, Object>();
if (request.getRegionId() != -1)
searchBy.put(ItsdIncident.propertyName.regionId,
request.getRegionId());
searchBy.put(ItsdIncidentUpdate.propertyName.impact,
request.getImpact());
searchBy.put(ItsdIncidentUpdate.propertyName.type,
request.getType());
searchBy.put(ItsdIncidentUpdate.propertyName.startDttm,
request.getStartDttm());
searchBy.put(ItsdIncidentUpdate.propertyName.endDttm,
request.getEndDttm());
String sortBy = request.getSortBy();
Boolean asend = request.getSortAscendant();
if (sortBy != null && asend != null) {
searchBy.put(CommonPropertyName.SORT_BY, sortBy);
searchBy.put(CommonPropertyName.ASENDENT, asend);
}
searchBy.put(CommonPropertyName.START_NBR, request.getStartNbr());
searchBy.put(CommonPropertyName.PAGE_SIZE, request.getPageSize());
List<ItsdIncident> items =
incidentService.findIncidentList(searchBy);
for (ItsdIncident item : items) {
Incident incident = newIncident(item);
if (incident != null)
response.getItem().add(incident);
}
return response;
}
@PayloadRoot(localPart = IncidentUpdatesInqRq, namespace =
MESSAGES_NAMESPACE)
public IncidentUpdatesInqRs findIncidentUpdateList(
IncidentUpdatesInqRq request) throws
DatatypeConfigurationException {
IncidentUpdatesInqRs response = objectFactory
.createIncidentUpdatesInqRs();
Map<String, Object> searchBy = new HashMap<String, Object>();
if (request.getUpdateDttm() == null) {
searchBy.put(ItsdIncidentUpdate.propertyName.incidentId, request
.getIncidentId());
List<ItsdIncidentUpdate> items = incidentService
.findIncidentUpdateList(searchBy);
for (ItsdIncidentUpdate item : items) {
IncidentUpdate incident = newIncidentUpdate(item);
if (incident != null)
response.getItem().add(incident);
}
} else {
ItsdIncidentUpdate item = incidentService
.findClosestIncidentUpdate(request.getIncidentId(),
request
168
.getUpdateDttm());
IncidentUpdate incident = newIncidentUpdate(item);
if (incident != null)
response.getItem().add(incident);
}
return response;
}
@PayloadRoot(localPart = IncidentVicinityCamerasInqRq, namespace =
MESSAGES_NAMESPACE)
public IncidentVicinityCamerasInqRs getIncidentVicinityCameras(
IncidentVicinityCamerasInqRq request)
throws DatatypeConfigurationException {
IncidentVicinityCamerasInqRs response = objectFactory
.createIncidentVicinityCamerasInqRs();
List<ItsdCamera> cameraList = incidentService.findCameraVicinity(
request.getIncidentId(),
new Long(request.getVicinityDiameter()));
for (ItsdCamera camera : cameraList)
response.getCamera().add(BeanUtil.createCameraObject(camera));
return response;
}
@PayloadRoot(localPart = IncidentVicinityVdsesInqRq, namespace =
MESSAGES_NAMESPACE)
public IncidentVicinityVdsesInqRs getIncidentVicinityVdses(
IncidentVicinityVdsesInqRq request)
throws DatatypeConfigurationException {
IncidentVicinityVdsesInqRs response = objectFactory
.createIncidentVicinityVdsesInqRs();
List<ItsdVDSFeed> vdsList = incidentService.findVdsVicinity(request
.getIncidentId(), new Long(request.getVicinityDiameter()));
for (ItsdVDSFeed vds : vdsList)
response.getVds().add(VdsInqEndPoint.newVdsFeed(vds));
return response;
}
@PayloadRoot(localPart = IncidentGetRq, namespace = MESSAGES_NAMESPACE)
public IncidentGetRs getIncidentDetails(IncidentGetRq request)
throws DatatypeConfigurationException {
IncidentGetRs response = objectFactory.createIncidentGetRs();
ItsdIncident obj = incidentService.findIncidentById(request
.getIncidentId());
response.setIncident(newIncident(obj));
return response;
}
private Incident newIncident(ItsdIncident itsdIncident) {
Incident incident = objectFactory.createIncident();
169
try {
incident.setId(itsdIncident.getId());
incident.setRegion(itsdIncident.getRegion().getName());
incident.setEvent(itsdIncident.getEventId());
IncidentUpdate iUpdate = newIncidentUpdate(itsdIncident
.getCurrentIncidentUpdate());
if (iUpdate == null)
return null;
incident.setCurrentUpdate(iUpdate);
incident.setJurisdiction(itsdIncident.getJurisdiction().getName());
return incident;
} catch (Throwable ex) {
logger.error("Failed to add incident " + itsdIncident.getId(),
ex);
return null;
}
}
private IncidentUpdate newIncidentUpdate(ItsdIncidentUpdate iiu) {
if (iiu == null)
return null;
IncidentUpdate iu = objectFactory.createIncidentUpdate();
try {
iu.populate(iiu);
return iu;
} catch (Throwable ex) {
logger.error("Failed to add incident update " + iiu.getId(), ex);
return null;
}
}
}
170
Figure B-1: MTO Sensors
171
Figure B-2: City of Toronto Sensors
Figure B-3: Loop detector data Sample
The figure shows the measurements recorded by a loop detector sensor (id: 401DE0030DWE) that
is installed on Highway 401. The data were recorded between 6:00 a.m. and 10:00 a.m. on July
09, 2014 and indicates a congestion occurred around 7:55 a.m. on that day.
172
173
Figure B-4: Loop detector data Sample (Preprocessed)
The figure shows the measurements shown in figure A-4 after the preprocessing stage.
174
Figure B-5: A Sample Vehicle Trajectory
Sample of the data reported by the GPS sensors. The data was collected by driving around 401 and
404 highways.
Figure B-6: Data Points as Reported by the ELM327 module
Sample of the data reported by the ELM327 module. The data was collected by driving around
several locations in the downtown Toronto.
Speed data
175
Preprocessed Speed Data
Engine Revolutions Per Minute (RPM) data
176
Processed Engine RPM data
177
Figure B-7: Incident Data
Figure B-8: Sample Transit Vehicles
Sample of the collected transit data. The data was collected during the AM peak hour (8:00 -9:00
AM) for four streetcars operating along the 504 transit route between Dundas West and Broadview
stations, Bloor-Danforth subway line.
178
Figure B-9: A social portlet- document library
179
Figure B-10: A technical portlet- Virtual Wall
180
Figure B-11: ONE-ITS Service
181
Copyright Acknowledgements
Portions of this thesis have been reproduced (with modifications) from the following published
material:
Elshenawy, M., El-Darieby, M., & Abdulhai, B. (2015a). A Cyber–Physical–Social platform for
intelligent transportation systems. Cyber-physical systems: From theory to practice (pp. 283-294)
CRC Press. Reproduced with permission of the Taylor and Francis Group LLC Books and the co-
authors (License Number: 3879341311477, Date: May 26, 2016).
Elshenawy, M., El-Darieby, M., & Abdulhai, B. (2015b). ONE-ITS: Strategy, architecture, and
software implementation of a Cyber–Physical–Social platform. Cyber-physical systems: From
theory to practice (pp. 297-306) CRC Press. Reproduced with permission of the Taylor and Francis
Group LLC Books and the co-authors (License Number: 3879341311477, Date: May 26, 2016)
