Functional Viewpoints – Bottom Up Approach

The functional viewpoint is frequently addressed in project architectures. Therefore, a huge basis exists for the Bottom Up part of the approach. Details will not be completely repeated here – only the common denominators and core aspects are quoted.

FRAMEprovides three viewpoints that actually provide functional descriptions of the system, the functional, information and communication viewpoint. In FRAME the func-tional viewpointconsist of functions (services) that create the ITS Application or Service [Jesty and Bossom, 2010]. The functional architecture [Bossom et al., 2009] is based on user needs which were derived from the stakeholder aspirations as a first step when mod-eling the FRAME architecture. The user needs are used to identify the required services whereas each individual service might be split up into further details for the description of the functional viewpoint. The FRAME Browsing Tool [Frame, 2011] provides a large set of both user needs and corresponding services, including their subdivision in smaller elements and details. The FRAME Browsing Tool comprises as well Cooperative Services which were developed in close cooperation with the projects CVIS, SafeSpot and Coopers.

Unfortunately the selected services no longer match the currently discussed Day 1 Appli-cations in C-ITS (see section 7.2.2).

Apart from the functions, data flows are part of the FRAME functional viewpoint, they link the individual functions with each other and with the actors. The FRAME Browsing Tool already provides a static mesh of data flows between FRAME specific functions. Rather technical is thecommunication viewpointthat comprises the requirements for communi-cation between physical units in each locommuni-cation [Jesty and Bossom, 2010]. It describes the

2description of all eight phases of the ADM can be found in [The Open Group, 2011b,a]

Figure 3.9.: FRAME architecture development process [Frame, n.d.b]

communication links needed to support the exchange of information between different parts of the system via physical data flows (which are described in the physical architec-ture). FRAME provides a detailed analysis for a selection of services in D3.2 [KAREN, 2000b]. The results of the analysis include a collection of requirements and characteristics of the physical communication channel for individual communication links. The docu-ment concludes with a short summary on existing data exchange standards.

There are links between the individual viewpoints similar to what was described for ODP and the FGSV pyramid. FRAME provides a specific architecture design process (Fig-ure 3.9) that originally starts from user needs (not covered by a viewpoint of its own), then describes the functional viewpoint, from which the physical viewpoint is derived (see description of the Technical Viewpoint (3.3.2.3)) which in turn is the basis for the Commu-nication Viewpoint.

One viewpoint that is only rarely mentioned in the context of FRAME is theInformation viewpoint, it defines the information that is used, its attributes and relationships [Jesty and Bossom, 2010]. The Information Viewpoint is not included in the ’classical’ FRAME process diagram for the development of an architecture (Figure 3.9) but was mentioned by the FRAME developers to be eminent for a complete architecture description [Jesty and Bossom, 2010].

Apart from the FRAME Browsing Tool, which provides demonstrative visualizations of the services and functions, their structure as well as the underlying data flows and physi-cal structure, FRAME additionally developed the so physi-called FRAME Selection Tool [Frame, 2012] which allows the user to feed the tool with its own requirements and tailor the FRAME structure specific to its own needs. If necessary it is as well possible to include new requirements, functions, data flows and information objects. Unfortunately the con-cept behind FRAME was not designed in a way that modified or extended versions of the basic FRAME architecture are still interoperable. Changes to the pre-set structure provided by the Selection Tool require modifications of the hard-coded architecture structure being the basis of the Selection Tool.

One core functional architecture description developed by the three C-ITS projects CVIS, Safespot, COOPERS in close cooperation with the experts working on FRAME and the COMeSafety project was standardized in ISO / CEN and ETSI: TheCommunication Ref-erence Architecturefor ITS ([ISO 21217, 2009] and [ETSI 302 665, 2010], both standards are consistent). The standardized Communication Reference Architecture is the basis for the description of communication in C-ITS, though the possible communication technologies are not solely C-ITS focused. Core element in the standard is the so-called ITS Station, a functional entity specified by the ITS Station Reference Architecture [ETSI 302 665, 2010, Definitions]. The standard describes for this ITS Station a communication stack with four horizontal and two vertical layers (see Figure 3.10). Its different elements can easily be mapped to the ISO OSI (Open System Interconnection) Stack [ISO / IEC 7498-1, 1996].

Each element in the ITS Station Reference Architecture can be described by various other standards. Some examples are given in the standard itself (see Figure 3.11)

The architecture structure from the standard was implemented in various C-ITS projects, elements from within the layers were developed, implemented, improved and standar-dized. A lot of this work was done under the umbrella of the standardization mandate M/453 ([European Commission - Enterprise and Industry Directorate General, 2009]

han-Figure 3.10.: ETSI EN 302 665 Communication Architecture – ITS Station Reference Archi-tecture [ETSI 302 665, 2010]

dled by CEN and ETSI, details on results in the final report to the mandate from CEN and ETSI [CEN / ISO and ETSI, 2013]). Some very prominent examples are:

• Application layer: Basic Set of Applications [ETSI 102 637-1, 2010], various applica-tion standards

• Facilities layer: Cooperative Awareness Basic Service [ETSI 302 637-2, 2014], Decen-tralized Environmental Notification Basic Service [ETSI 302 637-3, 2014], Local Dy-namic Map [ETSI 102 863, 2011], Common Data Dictionary [ETSI 102 894-2, 2013]

• Networking & Transport Layer: GeoNetworking Protocol series [ETSI 102 636-1, 2010], [ETSI 102 636-2, 2010]

• Access Layer: European Profile on ITS G5 [ETSI 202 663, 2009], CEN / ISO Dedicated Short Range Communication (DSCR) (e.g. [CEN 12834, 2003; CEN 12795, 2003; CEN 12253, 2004])

• Management Layer: Congestion Management [ETSI 102 687, 2011]

• Security Layer: Security Architecture [ETSI 102 940, 2012]

As can be seen from the examples above the ITS Station architecture provides a frame for many different aspects of an ITS architecture, therefore the standard has actually a rather prominent role in C-ITS. Though it is named Communication Reference Architec-ture the examples embedded in the frame (see list above) show that the scope of ETSI TS 302 665 is definitively broader than communication only: e.g. the application layer com-prises standards that actually describe different services and applications (functions), the facility layer includes the data dictionary.

Figure 3.11.: Example elements of the ITS Station Reference Architecture [ETSI 302 665, 2010]

Besides the aspects discussed in the Communication Reference Architecture, another core element of the functional architecture that is used in different project architectures is the Common Data Dictionaryfor C-ITS [ETSI 102 894-2, 2013] specified by ETSI. The Com-mon Data Dictionary (CDD) includes the data model for various C-ITS applications and therefore matches the principles of the TOGAF Data architecture or the ODP Information viewpoint. The CDD is basis for the standards which are part of the Communication Ref-erence Architecture, e.g. the Cooperative Awareness Message (CAM) and Decentralized Environmental Notification Message (DENM) standards. Both are elements of the Facility layer and specify the corresponding C-ITS messages based on the CDD.

Figure 3.12.: Need for harmonization of data dictionaries [Lin, 2012]

Apart from the ETSI CDD other data dictionaries and data models do exist in ITS: DATEX (Data exchange specifications for traffic management and information) II [CEN 16157-4, 2014] is widely used by road operators for communication between traffic control cen-tres. TPEG (Traffic and travel information via transport protocol experts group) (ISO 18234 [2013] and 21219 [2014] series) provides a data dictionary for traffic information services.

Activities were started by the European EASYWAY project to harmonize the DATEX II and TPEG data dictionaries as both worlds are getting closer to each other. Interoperability was first demonstrated at the ITS Europe Congress in Lyon in 2011 [Lin, 2012]. Similar activities probably will become necessary in the future for the C-ITS CDD: on the one hand, the road operator and service provider will in the future transmit its information not only in the al-ready existing DATEX II and TPEG messages but as well as C-ITS messages (CAM, DENM, in the future additional message formats) (Figure 3.12 – RDSTMC (Radio Data System

-Traffic Message Channel) and RSU (Road Side Unit) level). On the other hand, the vehicle or user will receive messages in multiple formats based on different data dictionaries (Fig-ure 3.12 – vehicle level). To prevent conflicts caused by contradicting information aligned data dictionaries are an important prerequisite.

If no harmonization takes place at least an agreement on how to map the structures from one data dictionary to the other needs to be made to allow for system boundary transition and interoperability when the different systems operate in the same area and target the same user.