Data Model

The detailed description of the interface starts with the definition of the data model. It re-sembles the information flow within the service which in turn can be modeled with a state machine. Like previously stated, it is possible to develop a generic description for the data model which later can be realized in various technologies. But although the term generic is used here, the data model usually is region specific, normally it is not required to have an internationally valid data model that incorporates all region specific, platform specific data models. Respecting such a requirement only increases the complexity without a significant benefit. The focus of the data model in this Reference Architecture is Europe and Germany.

In general, a data model is tailored to specific services, their use cases and their require-ments. Therefore, it is not possible to provide right from the beginning of any implementa-tion an all-time valid and complete data model. Examining and describing all the services and use cases implemented in the analyzed system and incorporating their requirements and needs in the data model allows to develop a complete data model for this snap-short.

Ideally, single elements of the data model might be (re-)used in different use cases. Over-all, the data model needs to be designed in a way that it allows for future extensions when new services need to be integrated or new technologies require modifications.

In turn, no completely new data model shall be developed only because the existing data model does not yet cover specific new technologies, use cases or services. Usually, there is at least some partial overlap that serves as basis for the necessary extensions.

Both aspects together lead to the conclusion that the description of the data model in the Reference Architecture is rather about developing a suitable generic and platform inde-pendent structure out of existing and implemented data models while considering the new and additional requirements of C-ITS.

The idea of defining platform independent models originally was proposed in the Model Driven Architecture developed by The Open Group [2016]. The Model Driven Architec-ture states that a generic (platform independent) data model can be mapped to different (platform specific) data models by using Model Transformation Languages.

For the generic data model of the overall C-ITS architecture data models from existing ITS need to be considered and partially even integrated. Applying this requirement on the data model implies that modifications of the existing data models may be necessary to incorporate the characteristics of the generic (platform independent) data model. It is not possible to develop a generic data model on top of several platform specific data models without modifying any of the existing data models.

NOTE: Of course, one of the possible platform specific models might serve as blueprint for the platform independent model and therefore no severe modifications of this specific model will be necessary.

The mapping from the platform independent model that will be developed for the C-ITS architecture to the platform specific data models, e.g. already existing data models, is

de-Figure 7.13.: Platform Independent Model of the data model and example for its transfer to platform specific encodings

picted in Figure 7.13. The required modifications and changes of the existing data models are implied with the shaded boxes.

The analysis in the Top Down and Bottom Up Approach showed that existing data models already cover a variety of different use cases. Partially, different data models for the same type of service implemented with different technologies are existing. Often, no harmoni-zation did take place so far as this is a rather difficult task: the different data models were developed completely independent with a slightly different focus, often due to different underlying technologies. Some activities on harmonizing core data models were initia-ted, e.g. EASYWAY spend some efforts on aligning DATEX II and TPEG. Recently it was agreed to possibly extend those harmonizing activities with the existing C-ITS data model developed in ETSI (Common Data Dictionary [ETSI 102 894-2, 2013]).

From the data models identified in the Top Down and Bottom Up Approach the following will be considered for the generic description of the C-ITS data model:

• DATEX [DATEX II, n.d.] – largely in use in communication between traffic control centres, covers already a large number of use cases; harmonization activities with TPEG

• TPEG [ISO 18234, 2013; ISO 21219, 2014] – largely in use in the traffic information field, covers a large number of use cases; harmonization activities with DATEX II

• CDD [ETSI 102 894-2, 2013] – especially used by the vehicle industry for the C-ITS communication; harmonization with DATEX II under discussion, partially harmo-nized with TPEG

• TLS [BASt, 2012] – largely in use in the infrastructure side implementations, so far no harmonization activities

• IVI [ISO 19321, 2015] – currently developed dictionary for in-vehicle information, mainly to be used in C-ITS for the communication from infrastructure to vehicles,

complementing both the CDD from ETSI and the existing legacy ITS data dictionaries like DATEX, TPEG. The data dictionary is currently standardized in TS 19321.

• OCIT [ODG, n.d.] – largely used in urban scenarios, e.g. for controlling and op-eration of traffic lights, currently the extension for urban C-ITS use cases is under discussion

• DELFI [DELFI, n.d.] – especially used in public transport use cases to exchange infor-mation on time tables and live departures between public transport service providers Of course, there are many other data models that might be included here but with focus on ITS and C-ITS the listed candidates above are the most prominent and widely used ones.

Although, the generic description of the data model is heavily depending on the use cases and services that are implemented. It needs to provide a close link to the functional mod-ules, the following rather general aspects need to be included in basically every data model for ITS and C-ITS services:

• location referencingboth of the raw data detected by sensors and the events deter-mined by the service. This might not only involve different map basis with different encoding schemes but as well rather abstract descriptions of the location e.g. roads with lanes. Additionally, it might be necessary to describe the location not only as a point but as well as a linear or polygon

• time stampsof the raw data, the event, the object generated out of the data model

• raw data elementsto describe the triggering event originally detected through sen-sors

• various elements to describe the results of the services (=event), this includes a list of differentevent typeswhich are detailed by different event type specific attributes

• quality information, quality levels and indicators of the respective data (applies to all processing stages)

• operational messages anderror codes

• meta information

The previous considerations lead to the conclusion that it is not possible to describe a ge-neric data model without a clear relation to a service. Both ITS and C-ITS enable a large number of possible services – developing a data model without omitting any service is not realistic.

The other possible way forward would be to combine the already existing data models mentioned above. Each of them already covers a large number of ITS services and serves the current need for data models in the respective field. But the combination of the dif-ferent data models is a rather complex task as the difdif-ferent data models cannot only be merged. Overlapping aspects need to be identified and harmonized. Partially, a clean-up might be necessary. Apart from that, the C-ITS specific requirements so far are only moderately reflected in those data models. Some harmonization activities already were

initiated, others are currently under consideration. The results of these activities ideally provide the generic data model for ITS and C-ITS. Currently, not even preliminary results are available – therefore this part needs to be complemented as soon as the outcomes are available.

The generic data model, developed in the context of the System Architecture for the C-ITS Corridor (see chapter 8), provides a first example on how such a data model for a specific system and its services (in C-ITS) might look like.

Closely linked to the data model is its encoding. The encoding basically comprises of a transfer syntax that allows to transfer the generic, platform independent description of the data model into an implementation specific description. The transfer syntax consists of a set of encoding rules that allow for the exchange of data in a structured way. It is still independent of machine architecture and implementation language.

Several options for encoding the content of the data model are available – which one is ac-tually selected is heavily depending on the requirements and boundary conditions of the implementations. The different encodings provide different characteristics e.g. in terms of required bandwidth for the transmission of the encoded payload.

Examples for possible encodings are ASN.1 (used in the ETSI CDD [ETSI 102 894-2, 2013]) with BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules) PER (Packet Encoding Roles), XER (XML Encoding Rules). Other alter-natives are XSD (transfer syntax for UML applied in DATEX II [CEN 16157-4, 2014]) or JSON.

As the transfer of the abstract data model in a specific encoding is implementation specific this is not addressed in the Reference Architecture but described in detail in the System Architecture (chapter 8).

7.2.3.3.2. Communication

For the description of the communication aspects different existing communication archi-tectures are available. Which one should be selected is heavily depending on the imple-mentation characteristics of the interface – what in turn is closely linked to the entities that are on each side of the interface and with which technologies they (usually) operate over their interfaces. The Reference Architecture description of the communication aspect of the interface provides a list of options from which the implementation in the System Ar-chitecture can select.

The architecture for the C-ITS specific wireless communication is described by the two Communication Reference architecture standards currently available [ISO 21217, 2009;

ETSI 302 665, 2010]. Both describe an almost identical framework for the communica-tion between so called ITS Stacommunica-tions. ISO 21217 and ETSI EN 302 665 both only provide a framework architecture, linked to the standards is a large list of potential implementation options for the different layers which are part of the communication stack.

The architectures described in both standards have in their structure a very close link to the ISO OSI Standard [ISO / IEC 7498-1, 1996] but with a focus on C-ITS communication.

The layers defined in ISO 21217 and ETSI EN 302 665 can be matched to the layer and cross-layer structures of ISO OSI. The facility layer in the Communication Reference

archi-tecture corresponds to a generic description of the application layer, the presentation and session layer in ISO OSI. The network and transport layer in ISO 21217 and ETSI EN 302 665 resemble the network and transport layer in the ISO OSI model. The access layer in ISO 21217 and ETSI EN 302 665 correlate with the physical and data link layer in ISO OSI.

The security and management layer in all standards correspond to each other.

ISO 21217 and ETSI EN 302 665 are in their content rather equivalent although they refer to different sets of linked standards. The suite complementing ISO 21217 is also known as theCommunications in Cooperative Intelligent Transport Systems (CALM) Standardsseries [ESF GmbH, 2016]. Because no project or implementation initiative is known that imple-mented this set of standards recently – the last practical implementations were done in the projects CVIS, SAFESPOT and COOPERS which were all closed in 2010 – they are not considered in detail in this Reference Architecture description.

The ETSI Architecture described in EN 302 665 refers to a different set of standards. Some examples are given in ETSI 302 665 [2010], the full list of standards is constantly growing.

Depending on the needs within the community new standards are developed and integra-ted in the architecture framework.

Originally the communication reference architecture like it is described in ISO 21217 and ETSI EN 302 665 was supposed to be designed in a way that as well all existing legacy ITS communication might be realized based on these architectures. Discussions with ex-perts from the legacy ITS showed that this is not the case, although this is possible from a pure technical viewpoint. Both architecture standards originally were driven by the vehi-cle industry and were developed with a focus on these stakeholders’ requirements. Legacy ITS architectures from other domains and their characteristics were not taken into account.

The legacy ITS communication usually is based on ISO OSI derived communication stacks and makes use of IP (Internet Protocol)-based communication patterns. (Exceptions are old implementations of TLS. Implementations based on recent versions of TLS allow for IP-based communication as well.) Considered in the description of the Reference Archi-tecture are therefore as well the ISO OSI Standard extended with the specific layer 5-7 protocols.

The different systems from legacy ITS come along with their own traditional protocols usually residing in the layers 5-7 of the OSI stack. TLS has its own – both overIP and non-overIP capable – protocols and messages which are described in TLS [BASt, 2012].

Other popular protocols for legacy ITS are OCIT developed by the OCA (Open Traffic Sys-tem City Association e.V) organization and closely linked to the OTS protocol. RDS-TMC [FORCE 1 et al., 1999], a predecessor of TPEG [ISO 18234, 2013; ISO 21219, 2014] that is still widely in use today as well as DATEX II, are popular in the road operator and infrastruc-ture operator community.

The mentioned protocols are completely residing in the top layers of the ISO OSI archi-tecture. They are all running on top of various lower layer protocols included in the ISO OSI architecture. Which one is actually selected highly depends on the system and service requirements.

Examples for the available options are given in Table 7.3.

Layer Interface Interface

focus C-ITS (ETSI) focus legacy ITS Facility / OSI 5-7 CAM [ETSI 302 637-2, 2014],

DENM [ETSI 302 637-3, 2014], CDD [ETSI 102 894-2, 2013], In-Vehicle Information (IVI) [ISO

Network / OSI 4 User Datagram Protocol (UDP), Transmission Control Protocol (TCP), ITS-specific, others

TCP, UDP and others

Transport / OSI 3 Geo-Networking (ITS-specific), Internet Protocol version

Access / OSI 1-2 ITS G5, cellular networks, in-frared and others

Ethernet and others

Table 7.3.: Sample standards from the Communication Reference Architecture, both C-ITS and legacy ITS