ISO/TS 19468:2019
(Main)Intelligent transport systems — Data interfaces between centres for transport information and control systems — Platform independent model specifications for data exchange protocols for transport information and control systems
Intelligent transport systems — Data interfaces between centres for transport information and control systems — Platform independent model specifications for data exchange protocols for transport information and control systems
This document defines and specifies component facets supporting the exchange and shared use of data and information in the field of traffic and travel. The component facets include the framework and context for exchanges, the data content, structure and relationships necessary and the communications specification, in such a way that they are independent from any defined technical platform. This document establishes specifications for data exchange between any two instances of the following actors: — Traffic Information Centres (TIC); — Traffic Control Centres/Traffic Management Centres (TCC/TMC); — Service Providers (SP). This document can be applied for use by other actors, e.g. car park operators. This document includes the following types of information: — the use cases and associated requirements, and features relative to different exchange situations; — the different functional exchange profiles; — the abstract elements for protocols; — the data model for exchange (informational structures, relationships, roles, attributes and associated data types required). In order to set up a new technical exchange framework, it is necessary to associate one functional exchange profile with a technical platform providing an interoperability domain where plug-and-play interoperability at technical level can be expected. The definition of such interoperability domains is not part of this document but can be found in other standards or technical specifications, e.g. ISO 14827‑3. This document is restricted to data exchange. Definition of payload content models is beyond the scope of this document.
Systèmes de transport intelligents — Interface de données entre centres pour les systèmes de commande et d'information des transports — Spécification du modèle indépendant de plateforme pour les protocoles d'échange de données pour les systèmes de commande et d'information des transports
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 19468
First edition
2019-10
Intelligent transport systems —
Data interfaces between centres for
transport information and control
systems — Platform independent
model specifications for data exchange
protocols for transport information
and control systems
Systèmes de transport intelligents — Interface de données entre
centres pour les systèmes de commande et d'information des
transports — Spécification du modèle indépendant de plateforme
pour les protocoles d'échange de données pour les systèmes de
commande et d'information des transports
Reference number
©
ISO 2019
© ISO 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2019 – All rights reserved
Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 4
5 Exchange modelling framework . 4
5.1 Overview . 4
5.2 Business scenarios and Functional Exchange Profile (FEP) . 5
5.3 Requirements, feature and exchange patterns . 5
5.4 Business scenario: Information delivery . 6
5.4.1 Overview . 6
5.4.2 Requirements . 8
5.4.3 Data delivery exchange pattern . 8
5.4.4 Specific exchange pattern specification PIM included in this document . 9
5.5 Business scenario: Collaborative ITS Service (CIS) . 9
5.5.1 Overview . 9
5.5.2 Data exchange enabling service request and feedback paradigm . . 9
5.5.3 Requirements .10
5.6 Exchange data model .10
5.7 Data exchange features .10
5.7.1 Context diagram .10
5.7.2 Features .11
6 Snapshot Pull .15
6.1 Overview .15
6.2 Exchange pattern messages definition.15
6.2.1 Overall presentation .15
6.2.2 Basic exchange pattern .16
6.2.3 Relevant exchange information in exchange data model .17
6.2.4 Exchange messages .17
6.3 Features implementation description .17
6.3.1 Overview .17
6.3.2 Subscription contract.17
6.3.3 Session .17
6.3.4 Information management .18
6.3.5 Data delivery .19
6.3.6 Self-description .19
6.3.7 Communication .19
6.3.8 Optimisation issues .20
7 Snapshot Push .20
7.1 Overview .20
7.2 Exchange pattern messages definition.21
7.2.1 Overview .21
7.2.2 Basic exchange pattern .21
7.2.3 Relevant exchange information in exchange data model .22
7.2.4 Exchange Messages .22
7.3 Features implementation description .23
7.3.1 Subscription contract.23
7.3.2 Session .23
7.3.3 Information management .23
7.3.4 Data delivery .24
7.3.5 Self-Description .24
7.3.6 Communication .24
7.3.7 Optimisation issues .25
8 Simple Push.25
8.1 Overview .25
8.2 Exchange pattern messages definition.26
8.2.1 Basic exchange pattern .26
8.2.2 Relevant exchange information from exchange data model .27
8.2.3 List of exchanged messages .28
8.3 Link monitoring and error management .28
8.4 Features implementation description .30
8.4.1 Overview .30
8.4.2 Subscription contract.30
8.4.3 Session .30
8.4.4 Information management .32
8.4.5 Data delivery .32
8.4.6 Self-Description .33
8.4.7 Communication .33
8.4.8 Optimisation issues .33
9 Stateful Push .33
9.1 Overview .33
9.2 Exchange pattern messages definition.34
9.2.1 Overview .34
9.2.2 Basic exchange pattern .34
9.2.3 Relevant exchange information from exchange data model .35
9.2.4 List of exchanged messages .36
9.3 Session status management .37
9.4 Features implementation description .39
9.4.1 Overview .39
9.4.2 Subscription contract.40
9.4.3 Session .40
9.4.4 Information management .42
9.4.5 Data delivery .42
9.4.6 Self-description .43
9.4.7 Communication .43
10 Publish Subscribe .43
10.1 Exchange architecture .43
10.1.1 Pattern description .43
10.1.2 The supplier .44
10.1.3 Client .45
10.2 Feature description .45
10.2.1 Overview .45
10.2.2 Subscription contract.45
10.2.3 Subscription .47
10.2.4 Information management .53
10.2.5 Data delivery .55
10.2.6 Communication and protocol .60
10.3 Publish-Subscribe Functional Exchange Profiles .60
10.3.1 Overview .60
10.3.2 Objectives .61
11 Other PIM definitions .61
Annex A (informative) Methodology presentation .62
Annex B (normative) Definition of requirements.64
Annex C (normative) Basic exchange data model and data dictionary .69
Annex D (informative) Introduction to communications and protocols .97
iv © ISO 2019 – All rights reserved
Annex E (informative) Major Functional Exchange Profile and exchange patterns for
information delivery .102
Annex F (informative) Data delivery background: Stateless and stateful information with
information life cycle management .104
Annex G (informative) Collaborative ITS services (CIS) background .106
Annex H (informative) Collaborative ITS services exchange patterns .119
Bibliography .120
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC
278, Intelligent transport systems (ITS), in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
vi © ISO 2019 – All rights reserved
Introduction
This document defines a common set of data exchange specifications to support the vision of a seamless
interoperable exchange of traffic and travel information across boundaries, including national, urban,
interurban, road administrations, infrastructure providers and service providers. Standardisation in
this context is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost
base, promotion of open marketplaces and many social, economic and community benefits to be gained
from more informed travellers, network managers and transport operators.
Especially in Europe, delivering transport policy in line with the White Paper issued by the European
Commission requires co-ordination of traffic management and development of seamless pan European
services. With the aim to support sustainable mobility in Europe, the European Commission has been
supporting the development of information exchange mainly between the actors of the road traffic
management domain for a number of years.
This document supports a methodology that is extensible.
To be able to successfully connect systems and start exchanging data, in an interoperable and easy
way, there is a need to describe and agree on how the exchange should be done. This is set out in a data
exchange specification. Data exchange in different scenarios can have different needs and requirements.
Therefore, several data exchange specifications can be needed.
Data exchange specifications need to address two main issues. First, they model the stakeholders
and actors involved in data exchange, each potentially in different roles, as well as abstract exchange
patterns for their interactions. Second, they select a suitable implementation platform and clearly
specify how the abstract scenarios and patterns are effectively implemented on this platform.
The following diagram in Figure 1 shows such an abstract communication scenario from the perspective
of a road operator who requires data exchange interfaces between the different components of its own
operational systems, either between centre side components or between centre and field devices, but
also to exchange information with other road operators or service providers.
Figure 1 — Abstract communication scenario
While the black links between centre side components and field devices may use a variety of
communication protocols, mostly depending on the physical link conditions, the vast majority
of other coloured links between centre-side components, internal to one organisation or external
to others, is based on an IP network and mostly use the TCP transport layer protocol (UDP is also
possible in a few cases).
Nevertheless, as the different colours indicate, they can very well have significantly different
requirements. Internal links (blue) can reside in one domain of trust, hence do not require protocols
compatible with security gateways. This can already be different for links to other road operators
(red) and will certainly not hold for links to other types of organisations, like service providers, via the
Internet (green).
While different security requirements offer the most striking and obvious example, there are more
criteria that can lead to different preferences on different types of links, e.g. scalability, robustness,
integration complexity.
In broad terms, the colours blue – red – green form a hierarchy from more internal, closely-coupled,
well-integrated systems towards external, loosely-coupled, and non-integrated systems. The
world of information and communication technology (ICT) offers a broad range of solutions for these
different scenarios, offering different advantages and disadvantages. It is obvious that the one-size-
fits-all principle will not provide the most efficient way of working here. Even on the highest level of
abstraction and inside the ICT domain itself, we already find a well-known battle of paradigms between
remote-procedure-call (RPC) type service specifications and RESTful architectures. The same clusters
of options are found in the domain of ITS standards, where for example the European standard for
the real-time information interface relating to public transport operations (SIRI – EN 15531 series)
introduces both concepts as complementary options: Publish-Subscribe and Request-Response.
As well, the ITS station architecture is not in contradiction with this document but is complementary
of what is defined in this document. According to the principles and the taxonomy defined in ISO 21217,
this document defines a conceptual notion of:
— How 2 central ITS (sub) stations could communicate to:
— deliver (application data units) information,
— negotiate functional service behaviour for collaborating traffic management functions (even if
this use case could not directly be matched to ISO 21217 as it is not about information delivery).
— How a Central ITS (sub) station could communicate to deliver information (application data units) to
another ITS station with the characteristics of a central ITS station.
This document specifies the process of defining the exchange characteristics by use case-driven feature
selection of relevant parameters for the relevant OSI layers as defined in ISO 21217. Two exchange
schemas are considered: Information delivery and Functional service negotiation between central ITS
stations.
The drafting of this document was guided by the following principles:
— Interoperability, such that different implementations can successfully engage in a data exchange
process;
— Support legacy implementations which are based on existing (exchange) specification, in order to
maximize investments already made by stakeholders;
— Address other user profiles, not only road operators, and thus make this document available to a
broader audience;
— Reuse of existing (communications) standards, in order to reduce implementation complexity and
take benefit of proven and already existent solutions for common ICT problems;
— Clear separation between the payload content and the exchange model.
The informative Annex A details the adopted methodology for defining this exchange Platform
Independent Model.
viii © ISO 2019 – All rights reserved
TECHNICAL SPECIFICATION ISO/TS 19468:2019(E)
Intelligent transport systems — Data interfaces between
centres for transport information and control systems
— Platform independent model specifications for data
exchange protocols for transport information and
control systems
1 Scope
This document defines and specifies component facets supporting the exchange and shared use of data
and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the data content, structure and
relationships necessary and the communications specification, in such a way that they are independent
from any defined technical platform.
This document establishes specifications for data exchange between any two instances of the
following actors:
— Traffic Information Centres (TIC);
— Traffic Control Centres/Traffic Management Centres (TCC/TMC);
— Service Providers (SP).
This document can be applied for use by other actors, e.g. car park operators.
This document includes the following types of information:
— the use cases and associated requirements, and features relative to different exchange situations;
— the different functional exchange profiles;
— the abstract elements for protocols;
— the data model for exchange (informational structures, relationships, roles, attributes and associated
data types required).
In order to set up a new technical exchange framework, it is necessary to associate one functional
exchange profile with a technical platform providing an interoperability domain where plug-and-play
interoperability at technical level can be expected. The definition of such interoperability domains is not
part of this document but can be found in other standards or technical specifications, e.g. ISO 14827-3.
This document is restricted to data exchange. Definition of payload content models is beyond the scope
of this document.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https: //www .iso .org/obp
— IEC Electropedia: available at http: //www .electropedia .org/
3.1
business scenario
high level description of the interactions that can exist within a system being analysed or between the
system and external entities (called actors) in terms of business functions
Note 1 to entry: See also use case (3.20).
3.2
client
entity that receives the information
Note 1 to entry: It is represented in the information delivery business scenario (3.1).
3.3
Functional Exchange Profile
FEP
selection of data exchange features for a particular business scenario (3.1)
3.4
HTTP server
software application that provides content to client applications by using the HTTP protocol
3.5
interoperability domain
pair of Functional Exchange Profile (FEP) (3.3) and platform selected for implementing a data exchange
subsystem
Note 1 to entry: Each Platform Specific Model (PSM) document defines an interoperability domain, which ensures
that two implementations of this PSM are interoperable and can successfully exchange payload.
3.6
payload content model
content model
UML definition of the data structures that can be used to describe travel and traffic information to be
exchanged in an exchange system
3.7
payload publication
payload
bundle of information that is exchanged between two exchange systems containing an instance of the
content model (3.6)
3.8
Platform Independent Model
PIM
document describing the abstract model of the standardised data exchange process in a platform-
independent way
Note 1 to entry: This definition is specific to this document.
2 © ISO 2019 – All rights reserved
3.9
Platform Specific Model
PSM
document providing the implementation details of a Functional Exchange Profile (FEP) (3.3) described
in a Platform Independent Model (PIM) (3.8) for a concrete platform
Note 1 to entry: This definition is specific to this document.
3.10
profile-to-platform mapping
act of defining an interoperability domain (3.5)
3.11
pub/sub
publish-subscribe pattern
3.12
pull exchange
exchange pattern where the exchange of information is originated by the client
3.13
push exchange
exchange pattern where the exchange of information is originated by the supplier (3.19)
3.14
simple push
push-based exchange pattern where that does not require state to be maintained
3.15
snapshot
set of data providing all of the last known state as opposed to providing partial changes
Note 1 to entry: This definition is specific to this document.
3.16
snapshot pull
pull-based exchange pattern where only the last snapshot version is exchanged
3.17
snapshot push
push-based exchange pattern where only the last snapshot version is exchanged
3.18
stateful push
push-based exchange pattern where data describing a communication session is maintained across
successive communication within that session
3.19
supplier
entity that provides the information
Note 1 to entry: It is represented in the information delivery business scenario (3.1).
3.20
use case
UC
set of operational interactions between entities (called actors) and a system to ease understanding the
main functions behind such interactions
4 Symbols and abbreviated terms
ASN.1 Abstract Syntax Notation One
BUC Business use case
HTTP Hypertext Transfer Protocol
ICT Information and Communication Technology
IP Internet Protocol
ITS Intelligent Transport Systems
MDA Model Driven Architecture
REST Representational State Transfer
RPC Remote Procedure Call
SOAP Simple Object Access Protocol
TCP Transmission Control Protocol
TMP Traffic Management Plan
UDDI Universal Description Discovery and Integration
UDP User Datagram Protocol
UML Unified Modeling Language
NOTE Specified in ISO/IEC 19505.
VMS Variable Message Sign
W3C World Wide Web Consortium
WSDL Web Service Definition Language
WSIL Web Services Inspection Language
WSS Web Services Security
XML eXtensible Markup Language
5 Exchange modelling framework
5.1 Overview
The model driven approach is chosen to describe exchange: this leads to describe exchange systems
by means of abstract models which are named Platform Independent Model (PIM), in which modelling
of exchange features is done by describing interaction among systems and subsystems as exchange
patterns. These interactions implement system capabilities as features which fulfil exchange
requirements requested by specific business scenarios which are used to specify specific uses of
exchange.
Since simple data exchange process is no longer sufficient for resolving all business needs, this
document encompasses more business functions as stakeholders consolidate their systems and look at
new ways to address the requests they encounter with the tools they already know and have in place.
4 © ISO 2019 – All rights reserved
5.2 Business scenarios and Functional Exchange Profile (FEP)
This document is based on business scenarios, i.e. a high-level description of the interactions that can
exist within a system being analysed or between the system and external entities (called actors) in
terms of business functions. It is derived from requirements a business scenario has on information as
well as technical parameters. FEPs are identified to ensure interoperable services with the restriction
of determining one FEP per business scenario for a specific technical platform. One FEP can support
more than one business scenario (see Figure 2).
Figure 2 — Business scenario and Functional Exchange Profile (FEP)
This version of the document addresses the following business scenarios:
— Information delivery,
— Collaborative ITS services (partly).
Other business scenarios can be developed in future versions using the same methodology.
5.3 Requirements, feature and exchange patterns
Requirements can vary depending on data exchange applications, i.e. use cases to be fulfilled, so there
are many reasons to consider or not any requirement based both on the gathering of data at supplier
system and the usage of the delivered data in the client.
Requirements address the following items:
— Information provision,
— Communications,
— Security,
— Financial aspects.
Exchange is defined through features which implement the information exchange and fulfils data
exchange requirements.
Depending on many possible exchange platforms considered for implementation, a subset of features
and relative requirements is possible to be implemented. To fulfil a set of requirements many platforms
are possible, but to be interoperable a client and a supplier shall implement the same platform with
the same pattern. Allowing a wide variety of possible exchange patterns, the best suitable for an
application is chosen, according to requirements the fulfilment of which is granted by the selected
exchange pattern.
Based on the requirements of a specific business scenario, a set of appropriate exchange features shall
be combined into a Functional Exchange Profile (FEP).
The following schema in Figure 3 represent the domains of PIM and PSM introducing exchange pattern
(EP) and Functional Exchange Profile (FEP).
Figure 3 — Business scenario and Functional Exchange Profile (FEP)
5.4 Business scenario: Information delivery
5.4.1 Overview
One of the most common applications of a data exchange system is the exchange of traffic and travel
information between two nodes. In such a scenario, one node acts as the supplier of the information
while the other acts as the intended receiver of that information, i.e. the client.
EXAMPLE It is done by using the form of publications, e.g. in the European DATEX II.
The data delivery business scenario considers the actors as defined in the following Figure 4:
6 © ISO 2019 – All rights reserved
Figure 4 — General data delivery business scenario actors
The following table provides the basic definitions for exchange:
Table 1 — Main definitions in exchange
Name Definition
Supplier system A system which gathers information (road information) which needs to be conveyed
to another system named client system. Examples of supplier systems are traffic
control centres or traffic information centres or service provider systems, gathering
road data from any available source they have.
Client system A system which needs to update its internal information based on information which
is available from another system named supplier. Examples of client systems are traf-
fic control centres or traffic information centres or service provider systems.
Exchange environment The set of components which enables information exchange among client systems
and supplier systems via a data exchange protocol.
Supplier The component of exchange environment which is devoted to providing data to client,
retrieving them from supplier system.
Client The component of exchange environment which is devoted to collecting data from
supplier, delivering them to the client system.
Road and traffic information is gathered in a system which is named “Supplier System” in case the
information it stores is needed to be transferred to another system, named “Client System”, for any
purpose.
The data delivery business scenario describes the exchange pattern and messages which are needed
to be exchanged among supplier and client systems besides the underneath technology and exchange
pattern. The purpose for which information is exchanged is not considered in this use case description.
As explained in the information delivery background in Annex F, any update of information status at
the supplier system shall be replicated to the client system via information delivery. The main objective
of information delivery is that information on the client system is updated exactly in the same way as it
is in the supplier system without any difference in information values and semantics.
“Exchange message” is defined as the data structure in which the information is coded to transfer
information in the exchange system from the supplier to the client.
Assuming Sc = Client status, Ss = Supplier status, exchange is a mean to have Sc equivalent to Ss,
Formally:
Ss → Information → Supplier → Exchange Message → Client → Information → Sc
i.e. client system status is updated in equivalent mode as supplier system status by means of data
delivery exchange messages between supplier and client.
Information delivery business scenario scope is implemented by selected exchange features which
enable this scope and other secondary requirements which are based on available features on
considered platforms and patterns.
1) Supplier system characterisation
— Shall provide data as input to the data exchange environment
— Is mandatory for the information data delivery process
2) Data exchange environment
— Shall be an environment supporting the exchange of information and data by mean of messages
— The supplier of data exchange system shall produce and transmit the messages (Notification)
— The client of data exchange system should receive and process the messages
3) Client system characterisation
— Shall receive traffic and travel related data fro
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...