Resulting technical viewpoint

The technical viewpoint consists of the following core technical elements:

• vehicle system(s),

• nomadic devices like smartphones, navigation devices,

• roadside infrastructure like roadside units, traffic lights,

• central or backend infrastructure like traffic control centers,

• communication networks like cellular networks, fiber optic networks,

• cooperative elements amongst them ITS Stations and cooperative centres

The elements from the list above can be further subdivided into subsystems. Depending on the characteristics of the component and the level of detail this results in subsystems which provide the technical base for data collection, e.g. various sensors, evaluation i.e.

computing power, buffer etc. and presentation. Like described in detail for the functional viewpoint, this process can be executed iteratively (see Figure 7.5), leading to technical elements on the micro sensor and chip level.

For each technical element a state machine describing the possible state transitions can be defined. Especially these state machines address system states which are not covered by the process oriented description. Examples are activation and de-activation of components which are usually not part of the business process but eminent in the system description.

Apart from the selection of components and specific features, additionally structural choices are part of the technical viewpoint. That is on the one side the decision which technical components from which specific group are selected (e.g. vehicle / nomadic device vs.

infrastructure components like roadside units and traffic control centers) – this has im-plications on the design of the implementation scenario. On the other side this includes the determination how to assemble the selected components from a structural perspective.

Some components might be implemented both in a centralized or distributed way, one example are traffic control centers that might occur with a single instance or multiple, eventually connected instances. Apart from the two extreme poles all nuances in between are imaginable.

Crucial for the structural architecture decision in the technical viewpoint are the require-ments that need to be fulfilled when implementing a specific service. They might allow for different options – hence it is important to weigh the different options and consider organizational, strategic, financial, market-driven (only specific variations are available) and other arguments before making a decision. Additionally, structures from legacy ITS that need to be integrated might influence the design of the technical viewpoint.

Structural decisions have as well implications on other viewpoints – and the other view-points might influence the structural partition in the technical viewpoint: each technical component is closely linked to functional modules and organizational entities. Hence, the structural partition reflects organizational aspects like multiple actors implementing the same functional modules and functional aspects like centralized vs. distributed pre-processing or evaluation of data.

Accordingly, the variety of technical elements is supplemented with the structural archi-tecture options – leading to a multiplication of options from which the system archiarchi-tecture implementation can select.

7.3.4. Technical architecture with focus on urban implementation variations The recently published UR:BAN guideline [B ¨ohme et al., 2016] developed as well an ar-chitecture description with a similar but still different approach. Both approaches, the one described in this thesis and the one developed in the UR:BAN guideline, are leading to more or less the same structural architecture results. From an academic perspective this strengthens the resulting overall architecture and its elements described in this thesis, con-firming that the developed structures are stable and not heavily depending on one single approach to identify them.

The UR:BAN guideline has a strong focus on the practical implementation and the needs of the actors which actually have to realize these services. From this perspective, the guide-book is seen as very valuable contribution in the C-ITS community. Regarding the techni-cal viewpoint in a Reference Architecture, the experts in the UR:BAN project identified the same strong relationship between technical and organizational architecture like it is described in section 7.3.1.

The blueprint descriptions in the UR:BAN guidebook consists of three core options for the technical implementation which are called ’clusters’. They all can be traced back to the same generic dependencies between technical and organizational structures (Figure 7.14).

Each of the clusters may be realized in a centralized or decentralized approach.

The first cluster is characterized by a central traffic management system complemented by a traffic computer. The link between the distributed components in the field and the central backend are established either via legacy infrastructure or direct communication.

The second cluster is characterized by a traffic computer only, to which the distributed components are connected. Traffic management applications are not deployed.

The third cluster is characterized by the absence of any central traffic management unit, it is implemented in the so-called cloud-based example. In this case the external service provider (in the cloud) provides the traffic management or traffic computer infrastructure.

All three clusters alternatively can be deployed in decentralized scenarios. In this case stand-alone solutions in the field are realized which are directly linked to external service providers.

The guideline provides three sample implementation scenarios that realize the theoretical cluster options. The detailed description of each option allows the stakeholder to select the option that matches best its own technical / logical legacy structures and apply it in its own implementation.

In general, the cluster structures described in the UR:BAN guideline corresponds to the generic logical-technical structure mentioned in section 7.3.1. It enables numerous imple-mentation options, the most prominent ones are illustrated with the three cluster descrip-tions.

7.4. Summary and Conclusion

The Reference Architecture is the element in the overall architecture that links the Frame-work and System Architecture. It provides a generic blueprint for domain specific imple-mentations and has a very close link to the Modular Construction System. The Reference

Figure 7.14.: Generic technical structure developed in UR:BAN project [B ¨ohme et al., 2016]

Architecture picks up the policies and strategic guidelines immanent in the Framework Architecture and transfers them to a generic but domain-specific description. On the other side, the generic description from the Reference Architecture is mapped to a (service) spe-cific System Architecture in which generic modules are selected and customized to the requirements of the System Architecture.

The generic blueprint (Reference Architecture) in the present chapter focuses on the do-main C-ITS – with the assumption that C-ITS is not only interpreted from a communica-tion technology perspective i.e. the use of ETSI ITS G5 but follows the generic definicommunica-tion in chapter 2 that emphasizes that C-ITS is about cooperation between stakeholders, the involvement of multiple stakeholders that together provide a specific service. The un-derlying communication is flexible and not fixed to a certain technology. The Reference Architecture developed in this chapter respects these requirements.

For the description of viewpoints, the two approaches presented in chapter 6 were

con-sulted. For the process oriented description plenty source material was available, the ad-ditional state machines were compiled in this thesis due to lack of existing descriptions.

The individual sections of this chapter address the different elements of the Reference Architecture i.e. the individual viewpoints. Section 7.1 comprises the organizational view-point, which was developed from scratch based on the Top Down and Bottom Up Ap-proach resulting in a generic description of roles and responsibilities that help to organize such a multi-stakeholder structure like it is characteristic for C-ITS. The functional view-point incorporates a large number of different aspects which are described in section 7.2.

Amongst them are business process that describe the system’s behaviour, modules that are required to realize the processes, (communication) interfaces to connect the different ele-ments and generic models for the data flows within the system. The technical viewpoint in section 7.3 offers various opportunities for an implementation of the organizational and functional aspects. It tries to provide a generic and abstract description of technical and physical structures.

As mentioned before, the Reference Architecture has a very close link to the Modular Con-struction System, hence, the preceding sections are in a tight relationship with chapter 5 and its subchapters. This chapter provides the framework and structure and some details of the Reference Architecture, the options from which the one actually developing the Sys-tem Architecture can select are all summarized in the Modular Construction SysSys-tem (some examples are given in Appendices E and F).

The process of selecting suitable elements is the transition from Reference to System Archi-tecture. This transition is usually called profiling – a profile for a specific implementation is designed and later implemented. For one single Reference Architecture multiple profiles will be available. As they are reusing the building blocks of the Reference Architecture (which are stored inside the Modular Construction System), this approach shall ensure and enable interoperability between different implementations (profiles). An example profile is given with the C-ITS Corridor System Architecture in chapter 8.

Germany

Concluding the whole approach of defining an overall C-ITS architecture as it was initially described in section 3.1 and with Figure 3.1, the results of the chapters 5 and 7 are finally applied in a real world example.

C-ITS is a rather new technology that was so far only implemented in various projects and field operational tests throughout Europe. But none of the projects developed a close to reality system. Lately, several C-ITS deployment initiatives started. Amongst them are the C-ITS Corridor from Rotterdam (Netherlands) via Frankfurt (Germany) to Vienna (Austria), the French SCOOP@F initiative, the Nordic Way initiative and the deployment activities in Czech republic.

The first one, originally started in 2012, was the C-ITS Corridor. It is as well the one with the most mature specifications. Hence, it will be used for the description of a real world practical example architecture. The subsequent sections describe the System Architecture for the German part of the C-ITS Corridor developed based on the theoretical and practical background described in chapter 3 to 7. Due to expert overlap both the description of the methodological aspects in this thesis and the description of the System Architecture are in line. The latest version of the architecture is available on the C-ITS Corridor Website [Cooperative ITS Corridor, n.d.].