Section 5                                  gives a general introduction to the context of Intelligent Transport Systems and the categories that form the bulk of the Sections of this Guide/.

This Section (Section 7 - ITS Architecture) provides a more formal description of ITS and its interrelationships 

s7 ICIP arch fig 3.PNG

7.      ITS Architecture

7.1  Introduction and scope

The main intent of this section is to offer a panorama of standard ITS architectures to readers interested in using those standards in real life projects. This section does not intend to cover all possible ITS standards, which are dealt with somewhere else, rather to show what an ITS architecture standard can be used for and how. The section mostly deals with functional standards; however, some information about non-functional characteristics, such as cybersecurity, and about some internationally recognised tools, is given.

7.2   Actors in ITS Architecture

The term “actor” in systems architecture means "a role played by a user or any other system that interacts with the subject.” [b7.3] [Source ISO 19501  ̶  Unified Modeling Language (UML)]

"An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject." [b7.76]

"Actors may represent roles played by human users, external hardware, or other subjects. Actors do not necessarily represent specific physical entities but merely particular facets (i.e., “roles”) of some entities that are relevant to the specification of its associated use cases. A single physical instance may play the role of several different actors and a given actor may be played by multiple different instances." [b7.76]


7.2.1   Architectures for ITS systems


ITS architectures therefore describe (and in some cases specify) the relationships between actors, and describe (and in some cases specify) their roles and in some cases specify their actions and interactions involved in providing ITS services, and, from a different perspective (or ‘view’ as architecture jargon tends to call it), may also describe the elements of an ITS system.


7.2.2   Use of architecture models


A simple definition of the term architecture could be “a set of objects and the rules to combine them to make systems”. While this definition is surely not exhaustive, yet it is effective in the majority of cases where the design of a system is to be expressed, to state both what a system has to do (example: call for tenders), and what a system does (example: tenders).

The term system, in its turn, can be used whenever an entity that is intended to perform some task(s) may be seen not just as a single monolithic object, rather as made of multiple interacting objects [1], so that the rules, the interactions, the roles and the responsibilities that govern those objects can be exposed or imposed.

It is not the intent here to explain the advantages of “architected” systems, both in terms of analysis and design and in terms of maintenance and evolution, which is even more evident in the case of ITS systems, where heterogeneity of components and devices is the general norm. What is argued here is the advantage of having standard architectures. A standard architecture is a document, or a series of documents, that allows describing the architecture of a system by using agreed and understood (hence, standardised) terms and concepts. An object can therefore claim conformance to a standard architecture if it can be fully described by using the concepts and the terms defined in that architecture. This ensures that, at least in principle, different objects conforming to the same architecture can be “put together” to build complex systems. While, differently from other types of standards, compliance of an object to an architecture cannot be generally proven (no formal test cases can be defined), yet conformity to an architecture can be declared and used in procurement.

[1] The term includes human beings.

7.2.3   More than one architecture for the same system


Depending on the point of view a system is seen from, different objects and different rules can be observed, so that different architectures may be devised. For example, if one sees an Electronic Tolling System from the point of view of its legal constituents, a drawing such as that in Figure 7.1 may be useful to show the general architecture of the roles in such a system.


Figure 7.1 Roles in a tolling environment (from EN/ISO 17573-1:2020)


In Figure 7.1, ovals represent entities playing roles (or actors), while arrows represent their interactions. That kind of architecture, commonly referred to as Enterprise viewpoint architecture, is then detailed by listing the responsibilities pertaining to each role, and the way each actor playing a role fulfils their responsibilities by exchanging information with other actors. A system conformant to one of the roles identified in Figure 7.1 fulfils the responsibilities stated in the architecture for that role, and it shall do so by interacting with other systems by means of the information exchanges the architecture imposes.

However, if one looks at the same tolling system from an engineering point of view, where physical objects and their interactions are seen, the standards that rule information exchanges among physical objects (sub-systems) in the system can be shown in an architectural diagram like that in Figure 7.2.


Figure 7.2 An engineering architecture for Electronic Tolling Systems


The diagram in Figure 7.2 is not a detailed view of the interaction (arrow) drawn in Figure 1 between the toll charger role and the toll service provider role, rather it represents a completely different view of (a part of) the system, where other objects of different kind are shown (physical objects vs. roles and responsibilities), and it is aimed at, e.g., specifying which standards a system compliant to a given specification must implement, not just the exchanged type of information (the “how” with respect to the “what”).

7.2.4   Views of an ITS system and related architectures    Views of an ITS system

According to the Open Distributed Processing reference model (ISO/IEC 10746-1, see bibliography [b7.1]), a generalised distributed system can be fully described from 5 different views, corresponding to 5 different specification languages which in turn enable building 5 different models/architectures (the following list is reported here from ISO/IEC 10746-1):

  1. The Enterprise viewpoint, which is concerned with the purpose, scope and policies governing the activities of the specified system within the organization of which it is a part;

  2. The Information viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

  3. The Computational viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

  4. The Engineering viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information;

  5. The Technology viewpoint, which is concerned with the kinds of information handled by the system and constraints on the use and interpretation of that information.


One most important aspect of the above listed viewpoints is that they are not hierarchically nor functionally layered, like, e.g., the OSI layers. For example, when describing a functional interface between two interacting objects (a computational view) in an ITS system described as a set of interacting actors playing different roles (enterprise view), it may be useful if the components of that interface were shown with their respective roles and responsibilities, so giving an enterprise view of those computational objects.

This intertwining of concepts and terms in the same “architectural” document, even in the same pages of it, can be untied if one is clear about which concepts belong in which viewpoint.

While it has been proven that the concepts defined in all above viewpoint languages do indeed cover all aspects of any distributed system so far conceived, yet when describing or designing real systems some concepts or even entire views may be omitted, not being essential to the purpose of the specification.   Combining the architectural views

As several different architectural views can be produced for the same system, the issue arises on how to ensure that those views are indeed coherent with each other. Although this can be argued as being the very essence of a system design, so not in the scope of standardisation, yet, in order to address these issues, ISO/IEC and the ITU-T started a joint project in 2004 that produced a standardised set of rules (see bibliography [b7.2]) on how to specify ODP systems using the Unified Modelling Language 2 (UML 2, see bibliography [b7.3]).

That standard defines a set of UML Profiles, one for each viewpoint language and one to express the correspondences between viewpoints, and an approach for structuring them according to the RM-ODP principles.   Designing architectures


A common principle of design is to avoid “re-inventing the wheel”. To help in ITS architectures design, a number of standard documents are available, such as (the following list does not intend to be exhaustive):

  • The ISO 14813 series of standards (see bibliography [b7.8], [b7.9] and [b7.10]) contains the specification of fundamental services, core architecture and descriptive requirements for architectures, for reference in the developing new architectures and comparing different ones;

  • The ISO 17419 series of standards (see bibliography [b7.33] and [b7.34]) specifies the architectural requirements and the rules to assign globally unique identifiers to ITS applications;

  • The ISO 14817 series of standards (see bibliography [b7.4], [b7.5] and [b7.6]) specifies how ITS relevant data shall be defined, maintained and referenced.

7.2.5   General frameworks   Context

An architectural framework is intended to give a general view of a whole application context, like, for example, public transport, or regulated freight vehicles, or electronic fee collection. As such, a framework is of outmost importance not just for understanding the context itself, rather for placing services, applications standards and products in their correct places and roles. From that, it comes necessarily that the more the context is general (from a single specific service to the whole of ITS), the more it is introductory and the less it is prescriptive. The following clauses examine application contexts for which standardized frameworks are available.   Public transport

In the field of public transport, more than in other ITS fields, procurement is heavily based on standards. The ISO 17185 series of standards is specifically set at a higher level and not aiming to harmonize currently available national and regional standards. Part 1 of ISO 17185 (see bibliography [b7.26]) intends to establish a basic solid foundation for surface public transport user information provision framework and is specifically limited to this scope to avoid conflict with those currently available regional standards.   Freight and intermodal transfer

Freight and intermodal transfer are heavily regulated, thus general frameworks that set up rules and roles are essential. A general framework for regulated vehicle is provided in the ISO 15638 series of standards, in particular in its Part 1 (see bibliography [b7.12]) and Part 3 (see bibliography [b7.13]). In the field of intermodal transfer, a general framework is provided in ISO TS 17187 (see bibliography [b7.15]).   Mobility integration and urban ITS


“Urban ITS”, in its restricted meaning, is intended as the use of ITS systems (and their architectures) in the urban environment. As such, one should not speak of a specific “urban ITS architecture”. However, coupling the urban environment with mobility integration raises issues on combining different and disparate architectures. As an example, one should think of multimodal travels (combining a rental vehicle with parking, urban public transport, and so on), where each leg of the travel belongs in a transportation environment that has its rules, roles, and architecture. One useful document regarding multimodal integration is the CEN TS 17413 (see bibliography [b7.11]) which defines a reference data model that allows integration of transportation modes into urban multimodal services (e.g. trip planning systems).   Automated driving

An important issue in the field of automated driving is setting up a common framework of terms and definitions. The document ISO PAS 22736 (see bibliography[b7.16]), published by ISO as a publicly available specification (PAS) from the society of automotive engineering (SAE), defines a taxonomy and definitions for terms related to automated driving.   Electronic fee collection

Electronic fee collection can be realized with several technologies deployed in systems of varied complexity. A general framework to define EFC architectures is defined in  the three parts of EN ISO 17573, that includes a reference model ([b7.17]), a terminology ([b7.19], and common data definitions ([7.18]). The EFC terminology is synchronised with the general ITS terminology defined in ISO TS 14812 (see bibliography [b7.7]).   Disaster recovery

The theme of disaster recovery in ITS came into the standardisation arena after the Fukushima nuclear disaster, where it was clear that properly organised ITS services could have been very beneficial. Concepts matured during and after that experience are condensed in the technical report 19083-1 (see bibliography[b7.20]) that defines the general framework for ITS services in response to a disaster.   Green ITS

An ITS system might be designed with the explicit intent of supporting sustainability (“green” environment). A general framework and a list of use cases is given in ISO TR 20529-1 (see bibliography [b7.21]).

7.2.6   An architecture for each view?

As it can be expected from what stated above, most standard architecture documents provide concepts and terms belonging to more than one view, so that a rigorous analysis and classification of them is difficult, if not impossible, to pursue. Clause 7.3, however, tackles different aspects of ITS systems architecture design, and for each of them (coarsely bound to one or more viewpoints), addresses relevant ITS architecture standards. A summary of all standard architectural documents for different ITS application areas under different viewpoints is finally given in clause 7.7.

The following Clause 7.3 introduces a number of “architecture tools”, i.e., coherent sets of documents, handbooks, design principles, and software tools that have been developed in the last  several years to help ITS architecture developers.

7.3   ITS architecture tools

7.3.1   Introduction

Based on an already established set of ITS standards, a number of projects was established, some of which were implementation/demonstration oriented, like CVIS (se bibliography [7.60]), others were devoted to developing areas not covered by existing standards, and others were of a more general flavour.

In Europe, the Frame architecture (see bibliography [b7.62]) was created and first published by the EC funded project KAREN in October 2000. In the United States of America, the US Department of Transportation (DoT) created the Connected Vehicle Reference Implementation Architecture (CVRIA, see bibliography [b7.61]), which established a framework for the integration and standardization of connected vehicle technologies.

In more recent times, an agreement was signed between the European Commission and the US DoT to set up a common understanding and, possibly, a common ITS architecture, that led to the establishment of a series of Harmonisation Task Groups, which ultimately developed a common framework called HARTS. The results of HARTS have been incorporated recently in the American Architecture Reference for Cooperative and Intelligent Transportation Systems (ARC-IT. , see bibliography [b7.64]).

The following clauses provide the main characteristics of the mentioned architectures.   FRAME


The FRAME Architecture was intended to be used within a top-down approach to the planning and deployment of integrated ITS. The overall concept may, or may not, be represented in a formal (reference) model.  Since the creation of a reference model requires a number of decisions or choices to have been taken by those implementing and/or regulating ITS, the FRAME Architecture does not provide one.


The overall concept and the system structure should be described in a technology independent way so that, as technology evolves, higher level requirements remain unchanged. A distinctive feature of the FRAME Architecture is that it has been designed in terms of sub-sets, thus it is unlikely to be used in its entirety. Thus, the FRAME Architecture is not so much a model of integrated ITS, rather a framework from which specific models of integrated ITS can be created in a systematic and common manner.

The following Figure 7.3, taken from bibliography [b7.62], and copyrighted by the FRAME Forum, shows in essence the scope of FRAME.

The scope of FRAME. bibliography [b7.62] can be seen here: FRAME.


The FRAME Architecture covers a vast number of ITS areas, mostly corresponding to the application areas outlined in this Section and offers tools to help designing ITS systems. A concise description of the FRAME architecture can be found in a booklet referenced by bibliography [b7.63].


The FRAME Architecture in its latest version 4.1 contains the Cooperative Systems services and applications developed by the COOPERSCVIS and SAFESPOT FP6 Integrated Projects. This extension brings the total number of principal Functional Areas supported by the FRAME Architecture to nine, as shown in the following Figure 7.3.











Figure 7.3 FRAME functional areas




The FRAME Architecture is a large product with many thousands of elements. In addition, the Data Flow Diagrams developed within the architecture had to be organised in a hierarchical manner to make them better understandable. In order to provide a unified front end to the architecture, a FRAME Browsing Tool has been created that permits all the elements of the FRAME Architecture, and their interrelationships, to be viewed interactively using a standard HTML viewer. Thus, for example, it is possible to follow the passage of data from its collection by a particular functionality, through fusion and processing, to its eventual use in providing a service for the end users.

The FRAME Selection Tool has been created to enable users of FRAME to:

·     Create their own Functional Viewpoints subsets of the FRAME Architecture;

·     Create one or more Physical Viewpoints of each Function Viewpoint subset;

·     Create one or more Organisational Viewpoints of each Function Viewpoint subset;


The process of creating an ITS Architecture as a subset of the FRAME Architecture is summarised in the following Figure 7.4, taken from the Selection Tool manual.


Figure 7.4. FRAME subset creation


One technical limitation of the FRAME architecture is that it covers mostly a functional model of an ITS system, as other views are not developed significantly. More recent frameworks and architectures take into consideration also other views (Enterprise, Information, and Technical ODP viewpoints mostly) to provide a more comprehensive way of including, e.g., stakeholders’ concerns or availability of technical specifications in the overall description of an ITS system.   HARTS

HARTS (Harmonized Architecture Reference for Technical Standards) was the product of Harmonisation Task Group 7 (HTG7), which was part of a series of Harmonization Task Groups that  were created under an agreement originated in 2011 between the EC and the US with the goal of supporting “wherever possible, global open standards in order to ensure interoperability of cooperative systems worldwide and to preclude the development and adoption of redundant standards.”


One main outcome of HARTS is the so-called “ITS Service Packages”, that is, a set of service-oriented perspectives of ITS systems. For each service package, computational/engineering entities are shown with their interactions, as for example in the diagram in Figure 7.6, which shows a physical view (in ODP, Engineering viewpoint) of situation awareness service.











Figure 7.6. HARTS  diagram for situation awareness service



For each interaction, relevant standards to be used (Technology viewpoint entities) are indicated for three world regions (Europe, USA, Asia-Pacific). Figure 7.7 shows the list of standards relevant to the interaction between an RSE (roadSide Equipment) and a vehicle in the situation awareness service of Figure 7.6.


Figure 7.7 HARTS interaction between RSE and vehicle for situation awareness service



The solution allows selecting in the upper part of the diagram the different solutions adopted in the various regions of the globe, and shows which are the standards to be used in the various layers of the ITS station model. It also indicates, where appropriate, whether gaps have been detected that indicate needed standardisation activities.

HARTS covers all functional aspects of an ITS architecture, like FRAME, and extends it in the Technology and Engineering viewpoints of ODP. It, however, lacks a useful Enterprise framework.

The HARTS architecture and related tools are complete but are not been maintained any longer. HARTS is supposedly being integrated in the new version of ARC-IT. Reference to HARTS and related tools is in bibliography [b7.65].   ARC-IT

The US National ITS Reference Architecture, also known as the “Architecture Reference for Cooperative and Intelligent Transportation” or simply “ARC-IT” provides a common framework for planning, defining, and integrating intelligent transportation systems. ARC-IT is a reference architecture providing a common basis for planners and engineers with differing concerns to conceive, design and implement systems using a common language as a basis for delivering ITS, but does not mandate any particular implementation. ARC-IT offers tools for planning and designing ITS systems.

ARC-IT in its latest version (9.0) incorporates most of HARTS concepts and tools. It also covers significant Enterprise aspects, with the intent to answer to questions like, among others, the following:

  • Who is responsible for providing transportation-related user services?

  • Who is responsible for installation, operations and maintenance of ITS services, applications and devices?

  • What relationships need to exist between transportation operators to facilitate services between and within jurisdictions?

  • What relationships need to exist between the providers of services and the consumers of services?


To achieve these objectives, the ARC-IT Enterprise Model defines the following objects:

  • Enterprise Object: An organization or individual that is identifiable by its interactions with other Enterprise Objects and/or physical objects. An Enterprise Object may be a component of another larger Enterprise Object. Enterprise Objects may participate wholly or in part in other Enterprise Objects (e.g., a Device Developer is a component of Auto Manufacturer but also participates in Standards Body).

  • Resource: An asset that can support the achievement of enterprise objects. This may be a physical or virtual element and may be of limited availability. All physical objects are resources, but other resources may include policies and documents.

  • Relationship: Formal or informal coordination between Enterprise Objects, e.g. agreements, contracts, funding, expectations.

  • Role: The way in which an object participates in a relationship.


The relationships between Enterprises and between Enterprises and Resources are largely determined by Roles (e.g., owns, operates, develops, etc.).


Although the most complete ITS architectural framework to date, it has to be noted that ARC-IT is specifically designed for the United States of America environment, so it is based on choices that cannot be considered of a general nature. However Version 9 , as stated, makes specific effort to "internationalise" to give a more global perspective to the architecture.

7 arch Figure 1.png
7 Arch Figure 2v2.jpg
s7 ICIP Arch Fig 4.PNG
s7 ICIP arcg fig 5.PNG
s7 ICIP Arch Fig 6.PNG
s7 ICIP Arch Fig 7.PNG

7.4   Viewpoint specific architecture standards

7.4.1   Information structures and data architectures   Context

A data architecture is fundamental in understanding the syntax and semantics of data used in a given ITS area. Not all ITS areas define centralised data definitions and structures, leaving single technical standards the task of defining their data types. Data architectures and information structures roughly correspond to static Information viewpoint architectures in ODP modelling, while rules for the evolution of data belong in a dynamic Information viewpoint architecture. Those data architectures that are defined in standard documents are listed in the following clauses, grouped by application area. Beyond those, the ISO 14817-1 (see bibliography [b7.4]) gives general requirements for data definition, and ISO TS 19468 (see bibliography [b7.31]) defines a dynamic information schema for exchanging data between control centres. Finally, CEN/ISO TS 21184 (see bibliography [b7.47]) defines a global transport basic data model, hence a dynamic information architecture, to support data exchange between applications and the correct interpretation of data.   Probe data

In the area of probe data, the ISO TS 29284 (see bibliography [b7.22]) defines the subset of probe data related to events, while the ISO 22837 (see bibliography [b7.24]) defines the subset of probe data for wide area communication. ISO TS 25114 (see bibliography [b7.23]) defines a dynamic Information viewpoint architecture for reporting probe data.   Public transport

Public transport data definitions are catalogued in ISO TR 17185-2 (see bibliography [b7.27]) as a static information schema, as well as the interfaces to access them, while CEN TS 16614-1 (see bibliography [b7.28]) defines the format for exchanging public transport network topology information.   Emergency and enforcement

Procedures (models) for accessing emergency registers are given in EN ISO 24978 (see bibliography[b7.54]). A general landscape of ITS data, oriented towards the rules for data retention, is given in ISO TR 11769 (see bibliography [b7.29]). Finally, information for control and enforcement of regulated vehicles is defined in ISO TS 15638-13 (see bibliography [b7.30]).   Automated driving

The ISO PAS 22726-1 (see bibliography [b7.25]) proposes a model of static map data for automated driving.


7.5   Roles and responsibilities in ITS systems

7.5.1  Context


Having a clear view of the roles and the responsibilities in any ITS system allows understanding (or defining) the behaviour of the objects the system is made of. Not all application or service areas in ITS define a roles and responsibilities (enterprise) architecture. The following clauses present some ITS application areas where enterprise concepts have been defined in architecture standards.   ITS Cooperative systems (C-ITS)

For cooperative ITS systems, a basic architecture that defines roles and responsibilities, and has also been used by other architecture standards, is the EN ISO 17427-1 (see bibliography [b7.35]). That document generally defines roles as described by tasks, a behaviour and responsibilities associated with an actor, and services as functionalities to the system which require a defined set of data as input, process this data and deliver a defined output (process-oriented definition).   Electronic Fee Collection


Electronic fee collection has been one of the first ITS areas for which enterprise-concept base standards have been defined. In the now long life of EN/ISO 17573, its last two editions sported first the introduction of ODP concepts, then an alignment with the EN ISO 17427-1 that has shown how EFC concepts matched those of the general C-ITS framework. The latest edition of EN/ISO 17573 has also been split in three parts, where the first one (EN/ISO 17573-1 see bibliography  [b7.17]) defines, among others, the EFC enterprise architecture and its roles and responsibilities, the second document (EN/ISO TS 17573-2, see bibliography [b7.18]) contains the definitions of all EFC terms, and the third one (EN/ISO TS 17573-3, see bibliography  [b7.19]) formally defines the data types used in common in EFC standards.   Public Transport


In the public transport area, a number of standards have been produced where roles and responsibilities are defined. Worth of noting are EN ISO 24014-1 (see bibliography [b7.36]) that specifies the architecture of interoperable fare management systems, and the ISO TR 21724-1 (see bibliography [b7.37]), that describes the characteristics of a Common Transport Service Account System (CTSA). Although that document mainly describes a specific application, the objective of CTSA is to cover relevant transport services, the payment methods, the account types where the user of the service is charged for the service and that requires a more overall role and responsibilities model. Finally, a recently proposed Work Item (see bibliography [b7.38]) intends to synchronise terminology and role models across all public transportation standards.   Freight and intermodal transfer


In the area of freight transfer, the ISO 26683-1 (see bibliography [b7.39]) defines the overall context and architecture and also identifies the relevant standards.


7.6   ITS Services architecture

7.6.1   Context


Although the concept of service is rather slippery, and only defined is a precise way in the already cited EN ISO 17427-1 (see bibliography [7.35]), yet is commonly used in close contact with the concept of architecture. A starting point for identifying ITS services is ISO 14813-1 (see reference [7.8]), that identifies services and groups them by domains.   Probe data


In the area of probe data, services and service architecture are defined in ISO CD 19414 (see reference [7.40]).   ITS services for the persons


A number of ITS service are defined “for the persons”, perhaps to distinguish them from those that (apparently) seem to involve just vehicles and road infrastructures. While it is rather difficult to imagine a general architecture for that kind of services, yet some standards are there that define frameworks and use cases that can be considered as belonging in the architecture realm.

For example, ISO 17438-1 (see reference [7.42]) defines a general framework and use cases for indoor navigation using personal ITS stations. Also, a new work item to be started at the time this report is written (see reference [7.44]) will provide a framework and system overview for automated valet parking systems.   Green ITS


The framework of ITS services and applications for a sustainable environment (“green ITS”) is provided in ISO 20592-2 ( under development. see bibliography [b7.45]).   Freight and intermodal transfer


General framework of services and applications for regulated commercial freight vehicles are defined in ISO 15638-1 (see bibliography [b7.12]) and in IS 15638-6 (see bibliography[b7.14]). In the area of urban ITS, the CEN TS 17413 (see bibliography [b7.11]) defines models of ITS services.   Electronic Fee Collection


In the field of Electronic Fee Collection, the already cited EN/ISO 17573-1 (see bibliography[b7.17]) defines the services and the related interactions among EFC actors.   Automated driving


Use cases, services and general architecture in the field of automated driving are defined in ISO TR 23254 (see bibliography[b7.46]).


7.7   Design and implementation architectures

7.7.1   Context


Technical architectures are more in the realm of implementation than in that one of standardisation, and detailed computational views (object interactions and their interfaces) are in general dealt with specific standards, not just architecture ones. Technical standard documents dealing with interfaces usually cover a single interface at a time, so that they cannot be considered architecture documents. However, there are cases where groups of interfaces are tackled as wholes to, e.g., either ensure a consistent approach or to show mutual interactions and dependencies. These latter documents are computational architecture standards, and they are very useful for the design of complex ITS systems. Also, some “pure” engineering/technical architectures, where components distribution in a networked environment, together with their interface standards are defined, have been standardised to be of support to multiple application and service types, so that the following clauses, differently from the organisation in 7.1.4, 7.3.1, 7.4 and 7.5 above, deal with ITS objects and interfaces and with engineering architectures for general use, rather than for specific application areas.   ITS objects and interfaces

When transferring information between centres for ITS, the ISO 14827-1 (see bibliography [b7.49]) specifies the requirements for message definitions, while the ISO DIS 14827-3 (see bibliography [b7.48]) specifies the interfaces when XML is used.

In case of indoor navigation, the ISO DIS 17438-4 (see bibliography [b7.43]) specifies the interface requirements between personal or vehicle ITS station units and central ones.

The protocol architecture (procedures and data types) between traffic signal controllers and detectors is defined in the ISO 10711 (see bibliography  [b7.50]).

Finally, the already cited EN/ISO 17573-1 (see bibliography [b7.17]), that gives the overall architecture for Electronic Fee Collection systems, also specifies the high level interfaces between the entities herein defined.   Technical architectures

One basic technical architecture in ITS is the CEN ISO 21217 (see bibliography [bb7.51]), that specifies the model of a generic ITS station, upon which all C-ITS standards are based. The CEN ISO 21217 is a reference document to understand the scope and field of application of a huge number of IS standards, so it is of a paramount importance in ITS system design and procurement.

In the field of public transport, the CEN TS 13149-7 (see bibliography [7.41]) specifies the system and network architecture for vehicle scheduling and controlling.

A specialised technical framework is standardised in the CEN/ISO TS 21719-1 (see bibliography [b7.52]) for the personalisation of on board equipment.


7.8   The ITS architecture standards


The following Table 7.1 summarizes for all identified ITS areas the available architecture standards in the different viewpoints.


Table 1 – Architecture standards for ITS  areas


Table 7_1 220228.PNG

7.9   Cyber security

Security has a peculiar role in each architecture design, and it is often seen as a set of supporting functions, technologies and data exchanges rather than an architecture component. However, security in complex and distributed systems like ITS systems require architectures.

A set of guidelines on the usage of security standards in ITS systems is given in ISO TR 21186-3 (see bibliography [b7.55]).

A complete security framework for Electronic Fee Collection system is specified in EN ISO 19299 (see bibliography[b7.56]).

Not strictly belonging in the architecture field, yet worth of noting, are the ISO TR 12859 (see bibliography [b7.57]), which deals with privacy aspects in ITS, ISO 15638-4 (see bibliography [b7.58]), that gives the security requirements for freight regulated vehicles, and the ISO TR 17427-5 (under development, see bibliography [b7.59]), that lists common approached to security in cooperative systems.


7.10    Identification

7.10.1   Architectural frameworks


ITS architectures deal with interacting objects, and, to interact with each other, objects need to be identified. A principal means of identification in the ITS environment is AVI/AEI (Automatic Vehicle Identification/Automatic Equipment Identification). In order to define a common core of information that enables interacting ITS application to identify objects of interest, a common framework to achieve unambiguous identification has been designed and defined in the AVI/AEI Reference architecture and terminology (EN ISO 14814, [b7.66]). This architecture provides a reference structure which enables an unambiguous identification and also identifies the data constructs independently of specific communication protocols, in order to provide maximum interoperability.


Data structures are defined in this reference architecture by means of Abstract Syntax Notation 1 (ISO/IEC 8824 series, see bibliography  [b7.66], [b7.66], [b7.66] and [b7.70]) and its Encoding Rules (ISO/IEC 8825 series, see bibliography  [b7.71], [b7.72], [b7.73], [b7.74], [b7.75], [b7.76], [b7.77] and [b7.78]).


After publication of EN ISO 14814, the need arose of extending AEI for intermodal and multimodal systems architectures. This compatible extension of EN ISO 14814 is defined in the Intermodal goods transport architecture and terminology standard (EN ISO 17261, see bibliography [b7.81]) and describes the key sub systems, their associated interfaces and interactions and how they fit into system wide functions such as management, security and information flow.


In addition to these basic architectural standards, a number of documents have been published, to cover all aspects of automatic identification, that are briefly described in the following clauses.





7.10.2    System specifications (EN ISO 14815)


The System specifications standard (EN ISO 14815, see bibliography [b7.79]) enables users and suppliers of AVI/AEI systems to enable interoperability based on a DSRC link. For the transmission of data structure elements, Abstract Syntax Notation One (ASN.1) Packed Encoding Rules (PER) (ISO 8825-2, see bibliography [b7.72]) are used.




7.10.3    Numbering and data structure (EN ISO 14816)


The numbering and data structure standard (EN ISO 14816, see bibliography [b7.80]) provides for the assignment to vehicles and equipment of unique identification codes for ITS applications. These codes are maintained by the Netherlands Standardization Institute (NEN).


The basic data structures defined in the standard have been minimized in order to support systems using both active and passive On Board Equipment (OBE).





7.10.4    Numbering and data structures for intermodal goods transport (EN ISO 17262)

Numbering and data structures standard for intermodal goods transport (EN ISO 17262, see bibliography [b7.82]) allows unique or unambiguous positive identification of equipment, and to make that identification automatically. this International Standard defines data to achieve this particular objective.



The modelling of data is based on Abstract Syntax Notation One (ISO/IEC 8824, see bibliography [b7.66]). Data defined in this International Standard require a system for control and distribution of number series independent of the different AVI/AEI systems. This is required in order to avoid ambiguity and to provide the necessary level of security where appropriate. For this reason, the same registration authority defined in EN ISO 14816 applies.





7.10.5      System parameters for intermodal goods transport (EN ISO 17263)


The System parameters for intermodal goods transport standard (EN ISO 17263:2012, see bibliography [b7.83]) establishes an AEI system based on radio frequency technologies. It allows the transfer of the identification codes and further information about equipment and vehicles used in intermodal transport.



7.10.6   Automatic vehicle and equipment identification — Interfaces EN ISO 17264


The Interfaces for intermodal goods transport standard (EN ISO 17264, see bibliography [b7.84]) provides requirements for interoperable ITS transactions in an AVI/AEI context.


The standard specifies an application interface for AVI/AEI systems, based on standardized air interface protocols enabling interoperability between different AVI/AEI service providers.


7.11   Bibliography: S7  ̶ Architecture

[b7.1]    ISO/IEC 10746-1:1998, Information technology — Open Distributed Processing — Reference model: Overview

[b7.2]     ITU-T Rec. X.906|ISO/IEC 19793: Information technology - Open distributed processing - Use of UML for ODP system specifications"

[b7.3]     ISO/IEC 19505-1: Information technology — Object Management Group Unified Modeling Language (OMG UML) — Part 1: Infrastructure

[b7.4]     ISO 14817-1, Intelligent transport systems -- ITS central data dictionaries -- Part 1: Requirements for ITS data definitions

[b7.5]     ISO 14817-2, Intelligent transport systems -- ITS central data dictionaries -- Part 2: Governance of the Central ITS Data Concept Registry

[b7.6]     ISO 14817-3, Intelligent transport systems -- ITS data dictionaries -- Part 3: Object identifier assignments for ITS data concepts

[b7.7]      ISO 14812, Intelligent transport systems — Vocabulary

[b7.8]      ISO 14813-1:2015, Intelligent transport systems — Reference model architecture(s) for the ITS sector — Part 1: ITS service domains, service groups and services

[b7.9]      ISO 14813-5: Intelligent transport systems -- Reference model architecture(s) for the ITS sector -- Part 5: Requirements for architecture description in ITS standards

[b7.10]      ISO 14813-7: Intelligent transport systems -- Reference model architecture(s) for the ITS sector -- Part 7: ITS standards framework

[b7.11]      CEN TS 17413: Intelligent transport systems - Urban ITS - Models and definitions for new modes

[b7.12]      ISO 15638-1, Intelligent transport systems -- Framework for collaborative Telematics Applications for Regulated commercial freight Vehicles (TARV) -- Part 1: Framework and architecture

[b7.13]      ISO 15638-3, Intelligent transport systems -- Framework for collaborative telematics applications for regulated commercial freight vehicles (TARV) -- Part 3: Operating requirements, 'Approval Authority' procedures, and enforcement provisions for the providers of regulation

[b7.14]      ISO 15638-6, Intelligent transport systems -- Framework for collaborative Telematics Applications for Regulated commercial freight Vehicles (TARV) -- Part 6: Regulated applications

[b7.15]      ISO TS 17187, Intelligent transport systems -- Electronic information exchange to facilitate the movement of freight and its intermodal transfer -- Governance rules to sustain electronic information exchange methods

[b7.16]      ISO/SAE 22736, Intelligent transport systems -- Taxonomy and definitions for terms related to driving automation systems for on-road motor vehicles

[b7.17]      EN ISO 17573-1, Electronic fee collection -- Systems architecture for vehicle-related tolling -- Part 1: Reference model

[b7.18]      CEN ISO TS 17573-2, Electronic fee collection -- Systems architecture for vehicle-related tolling -- Part 2: Terminology

[b7.19]      CEN ISO TS 17573-3, Electronic fee collection -- Systems architecture for vehicle-related tolling -- Part 3: Data dictionary

[b7.20]      ISO TR 19083-1, Intelligent transport systems -- Emergency evacuation and disaster response and recovery -- Part 1: Framework and concept of operation

[b7.21]      ISO TR 20529-1, Intelligent transport systems -- Framework for green ITS (G-ITS) standards -- Part 1: General information and use case definitions

[b7.22]      ISO TS 29284:2012, Intelligent transport systems -- Event-based probe vehicle data

[b7.23]      ISO TS 25114:2010, Intelligent transport systems -- Probe data reporting management (PDRM)

[b7.24]      ISO 22837:2009, Vehicle probe data for wide area communications

[b7.25]      ISO 22726-1, Intelligent transport systems  Dynamic data and map database specification for connected and automated driving system applications  Part 1: Architecture and logical data model for harmonization of static map data

[b7.26]      ISO 17185-1:2014, Intelligent transport systems — Public transport user information — Part 1: Standards framework for public information systems

[b7.27]      ISO TR 17185-2:2015, Intelligent transport systems -- Public transport user information -- Part 2: Public transport data and interface standards catalogue and cross references

[b7.28]      CEN TS 16614-1, Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format

[b7.29]      ISO TR 11769:2010, Intelligent transport systems -- Communications access for land mobiles (CALM) -- Data retention for law enforcement

[b7.30]      ISO TS 15638-13:2015, Intelligent transport systems -- Framework for cooperative telematics applications for regulated commercial freight vehicles (TARV) -- Part 13: "Mass" information for jurisdictional control and enforcement

[b7.31]      ISO TS 19468, 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

[b7.32]      ISO 16461:2018, Criteria for privacy and integrity protection in probe vehicle information systems

[b7.33]      ISO 17419-1, Intelligent Transport Systems — Cooperative Systems — Globally unique identification

Note to entry:  Under Vienna Agreement: EN 17419:2018

[b7.34]      ISO 17419-3, Intelligent transport systems -- Identifiers -- Part 3: Architecture requirements for ITS-AID requests

[b7.35]      EN ISO 17427-1:2018, Intelligent Transport Systems — Cooperative Systems — Roles and responsibilities in the context of co-operative ITS based on architecture(s) for co-operative systems

[b7.36]      EN ISO 24014-1, Public transport -- Interoperable fare management system -- Part 1: Architecture

[b7.37]      ISO TR  21724-1, Intelligent transport systems -- Common transport service account systems -- Part 1: Framework and use cases

[b7.38]      ISO PWI 21733, Intelligent transport systems -- Public transport -- Synchronization of terminology and role models

[b7.39]      ISO 26683-1, Intelligent transport systems -- Freight land conveyance content identification and communication -- Part 1: Context, architecture and referenced standards

[b7.40]      ISO 19414:2019, Intelligent transport systems — Service architecture of probe vehicle systems

[b7.41]      CEN TS 13149-7, Public transport - Road vehicle scheduling and control systems - Part 7: System and network architecture

[b7.42]      ISO 17438-1, Intelligent transport systems -- Indoor navigation for personal and vehicle ITS station -- Part 1: General information and use case definition

[b7.43]      ISO DIS 17438-4, Intelligent transport systems -- Indoor navigation for personal and vehicle ITS station -- Part 4: Requirements and specification for interface between Personal/Vehicle and Central ITS stations

[b7.44]      ISO PWI 23374-1, Intelligent transport systems -- Automated valet parking systems (AVPS) -- Part 1: System overview and framework

[b7.45]      ISO 20592-2, Intelligent transport systems - Framework for Green ITS (G-ITS) standards - Part 2: Integrated mobile service applications

[b7.46]      ISO TR 23254, Intelligent transport systems -- Architecture -- Use cases and high-level reference architecture for connected, automated vehicles

[b7.47]      CEN/ISO TS 21184:2020, Cooperative intelligent transport systems (C-ITS) — Global transport data management (GTDM) framework

[b7.48]      ISO DIS 14827-3, Transport Information and control systems -- Data interfaces between centres for transport information and control systems -- Part 3: Data interfaces between centres for intelligent transport systems (ITS) using XML

[b7.49]      ISO 14827-1, Transport information and control systems -- Data interfaces between centres for transport information and control systems -- Part 1: Message definition requirements

[b7.50]      ISO 10711, Intelligent Transport Systems -- Interface Protocol and Message Set Definition between Traffic Signal Controllers and Detectors

[b7.51]      CEN/ISO 21217:2020, Intelligent transport systems — Station and communication architecture

[b7.52]      CEN/ISO TS 21719-1, Electronic fee collection -- Personalization of on-board equipment (OBE) -- Part 1: Framework

[b7.53]      ISO 24100:2010, Intelligent transport systems — Basic Principles for Personal Data Protection in Probe Vehicle Information Services

[b7.54]      EN ISO 24978:2009, Intelligent transport systems — ITS Safety and emergency messages using any available wireless media — Data registry procedures

[b7.55]      CEN TR 21186-3, Cooperative intelligent transport systems (C-ITS) - Guidelines on the usage of standards - Part 3: Security

[b7.56]      EN ISO 19299, Electronic fee collection -- Security framework

[b7.57]      ISO TR 12859, Intelligent transport systems -- System architecture -- Privacy aspects in ITS standards and systems

[b7.58]      ISO 15638-4, TARV -- Part 4: System security requirements

[b7.59]      ISO TR 17427-5, Cooperative ITS -- Part 5: Common approaches to security

[b7.60 ]    D.CVIS.3.3, Architecture and System Specifications, CVIS, WP3, Version 1.1, July 31st, 2007

[7b.61]      CVRIA,

[b7.62]      FRAME,

[b7.63]      The FRAME architecture and its action plan,

[b7.64]      ARC-IT,

[b7.65]      HARTS,  

[b7.66]      EN ISO 14814, Road transport and traffic telematics -- Automatic vehicle and equipment identification -- Reference architecture and terminology

[b7.67]     ISO/IEC 8824-1:2015, Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation — Part 1

[b7.68]     ISO/IEC 8824-2:2015, Information technology — Abstract Syntax Notation One (ASN.1): Information object specification — Part 2

[b7.69]     ISO/IEC 8824-3:2015, Information technology — Abstract Syntax Notation One (ASN.1): Constraint specification — Part 3


[b7.70]     ISO/IEC 8824-4:2015, Information technology — Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications — Part 4

[b7.71]     ISO/IEC 8825-1:2015, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) — Part 1

[b7.72]     ISO/IEC 8825-2:2015, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) — Part 2


[b7.73]     ISO/IEC 8825-3:2015, Information technology — ASN.1 encoding rules: Specification of Encoding Control Notation (ECN) — Part 3


[b7.74]     ISO/IEC 8825-4:2015, Information technology — ASN.1 encoding rules: XML Encoding Rules (XER) — Part 4


[b7.75]     ISO/IEC 8825-5:2015, Information technology — ASN.1 encoding rules: Mapping W3C XML schema definitions into ASN.1 — Part 5


[b7.76]     ISO/IEC 8825-6:2015, Information technology — ASN.1 encoding rules: Registration and application of PER encoding instructions — Part 6


[b7.77]     ISO/IEC 8825-7:2015, Information technology — ASN.1 encoding rules — Part 7: Specification of Octet Encoding Rules (OER)


[b7.78]     ISO/IEC 8825-8:2015, Information technology — ASN.1 encoding rules — Part 8: Specification of JavaScript Object Notation Encoding Rules (JER)


[b7.79]     EN ISO 14815, Road transport and traffic telematics — Automatic vehicle and equipment identification — System specifications


[b7.80]     EN ISO 14816, Road transport and traffic telematics — Automatic vehicle and equipment identification — Numbering and data structure

[b7.81]     EN ISO 17261, Intelligent Transport Systems — Automatic vehicle and equipment identification — Intermodal goods transport architecture and terminology

[b7.82]     EN ISO 17262, Intelligent Transport Systems — Automatic vehicle and equipment identification — Numbering and data structures


[b7.83]     EN ISO 17263, Intelligent Transport Systems — Automatic vehicle and equipment identification — System parameters


[b7.84]     EN ISO 17264, Intelligent Transport Systems — Automatic vehicle and equipment identification — Interfaces

[b7.85]     OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, pp. 586–588"