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

7.2.4.1    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.

​

​

7.2.4.2   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.

​

​

​

7.2.4.3   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

7.2.5.1   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.

​

7.2.5.2   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.

​

​

​

​

​

7.2.5.3   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]).

​

​

​

7.2.5.4   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).

​

​

​

7.2.5.5   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.

​

​

7.2.5.6   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]).

​

​

​

7.2.5.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.

​

​

​

7.2.5.8   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.

​

7.3.1.1   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 COOPERS, CVIS 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.

​

​

​

7.3.1.2   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].

​

​

7.3.1.3   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.

​

​

​

​