Integration of legacy ITS

The integration of various legacy ITS architectures in the structures developed in part 1 and 2 first of all requires a detailed analysis of those systems to identify structural com-monalities. A huge contribution to this activity is made by the work that was done in the so called Matrix report [Lotz et al., 2012]. The methodology as well as its results de-scribed in the report are the fundamental basis for handling the integration of legacy ITS requirement. The conclusions are reflected in the proposed migration concept for legacy ITS (3.4.1.2).

3.4.1.1. Analysis of legacy ITS – The Matrix report

The Matrix report [Lotz et al., 2012] developed by BASt did a thorough analysis of different ITS service implementations in Germany. Therefore, the report selected one representative ITS service as example: traffic information with hazard location warning. The traffic infor-mation service on hazard location warning informs the driver about relevant hazardous

spots on his route, like black ice or oil spill. Already today multiple implementations of such a traffic information service exist in parallel in different domains.

Although it appears to be cheaper and simpler to implement the service only in one sin-gle domain the currently followed approach of multiple implementations in different do-mains has severe benefits: this approach is per definition redundant, what increases its fail-safeness. Additionally it allows the road operator (or service provider) to get in touch with the user through various channels, as not every user has the same media available.

Therefore, the architectural consolidation of the different implementation variations is a core task and challenge in traffic management. The fusion is supposed to set aside the currently existing silos and realize the transformation to cooperative ITS.

Based on the example of the traffic information service on hazard location warning the Reference Architectures of the different domains that provide this service were analyzed.

The domains discussed in the report were legacy ITS with classical roadside telematics ser-vices, traffic information services (public and private), autonomous vehicle systems, and different implementation variations of cooperative ITS. Each of the domains focuses on a specific technology to realize the selected service. By force of historical circumstances dis-tinct and independent architectures were developed for the individual domains.

The Matrix report describes for the selected service in all individual domains the orga-nizational, functional and technical processes. Therefore a general structure originally de-veloped by the organization TISA (Traveller Information Services Association) was used, the so-called TISA value chain [TISA Executive Office, 2012]. The value chain describes the necessary steps from the detection of the original event to the final presentation to the end user, including the main process steps ’Detection’, ’Evaluation’ and ’Presentation’.

NOTE: The terms ’Detection’, ’Evaluation’ and ’Presentation’ are used here with their IT related meanings: Detection comprises all aspects of gathering information e.g. induction loops, video detection, floating car data (Input). Evaluation comprises all aspects of evaluation and informa-tion processing (Process). Presentainforma-tion comprises all aspects of making the results available to the receiver e.g. presentation on variable message signs, on the radio or Human Machine Interface (HMI) as well as providing the results as new input to other systems (Output). In IT this principle is also knows as IPO model: Input-Process-Output.

The real-world implementations of the selected service traffic information on hazard lo-cation in the different domains were mapped to the abstracted TISA value chain to obtain comparable descriptions of the organizational, functional and technical aspects (example see Figure 3.14, all descriptions in Lotz et al. [2012]). The individual descriptions comprise summaries of the single process steps, the corresponding responsible actor as well as a short description of the interfaces between the process steps with the utilized communica-tion media as well as the implemented protocol standard.

The standardized descriptions of the individual implementations in the different domains finally were aligned and transferred in a single matrix like overview for better comparabi-lity of the individual aspects (see Figure 3.15).

The results summarized in Figure 3.15 show the different options determined in the analy-sis of the different implementations of the traffic information service road hazard warning

Figure 3.14.: Example from Matrix report – description of organizational, functional and technical process for classical traffic management – other examples in the BASt report [Lotz et al., 2012]

Figure 3.15.: Summary of results from Matrix report [Lotz et al., 2012]

(example in Figure 3.14). The structure of the results in Figure 3.15 is predetermined by the structure and elements of the TISA value chain. Both for the individual process steps (Detection, Evaluation, Presentation) as well as the communication between the steps a large variety of options is used in the different implementations. (Organizational aspects originally described as a separate element in the individual descriptions (see Figure 3.14) were merged with the descriptions of the process steps (Figure 3.15)).

Having a closer look on the results in Figure 3.15, the summary shows as well, that par-tially different domains already make use of similar organizational, functional and techni-cal elements – without actually sharing them but implementing them in multiple instanti-ations, each in a different domain. Example for this is the evaluation of the raw data – on an abstract and general level it only differs in the responsible actors. (Though individual algorithms might be in use by the different actors, the product of the evaluation step, e.g.

decision that the raw data describes a hazardous location, is the same.)

Advancing this finding leads to the conclusion that a more efficient implementation with the same variety of individual systems, addressing the same service, should make use of synergies coming from shared use of individual modules and interfaces.

Beyond that, single modules and interfaces in such a synergetic structure can be replaced and updated more easily – and not only for one specific implementation. This might re-duce costs and facilitate the up-to-date-ness of the system as a whole.

In addition, the previous conclusion in combination with the matrix representation evi-dently leads to the finding, that there might be much more options for cooperation and sharing of modules between different domains than already implemented nowadays. The result may be new organizational, functional and technical structures to realize the re-spective service.

Therefore, the core conclusion from the matrix report transferred to this thesis regarding integration of legacy ITS is that a modular design of modules and interfaces would be beneficial. It enables a large variety of options for integrating existing systems and techno-logies and additionally allows for a huge number of new combinations of the modular elements – supporting the development and implementation of new services.

3.4.1.2. Migration concept for legacy ITS

The conclusion from the Matrix report [Lotz et al., 2012] that most of the legacy ITS analy-zed in the report already can be subdivided into modular elements is an essential finding that shall be considered when providing a proposal for a migration concept for legacy ITS.

The partition of legacy ITS resulting in suitable modules is the first step for integrating those systems in the (new) overall C-ITS architecture. The partition in this context respects the proposed structures and interfaces of the (new) overall architecture. Applying this subdivision to the legacy ITS architecture leads to modules which easily can be integrated into the new architecture.

Besides the adjustment of the legacy ITS architecture to the new overall architecture it is as well possible that in an early design phase of the new overall architecture the existing

structures and interfaces from legacy ITS are considered and included in the new architec-ture description. Usually, new systems are developed based on existing systems – hence it partially makes sense that core architectural characteristics are adopted. In this case mi-gration from a legacy ITS architecture, which is transformed to a modular structure, to the new overall architecture is even easier.