Step 2 – Selection process I

Evaluating the strengths and weaknesses of the candidates identified in the previous step with the criteria developed in the theoretical procedure (3.2.3.1.2) results in Table A.1.

Based on this evaluation the following candidates will not be considered in the next step:

Zachman Framework is excluded in this step because it does not really provide an ap-proach to develop an architecture structure or individual viewpoints but only a grid in which one can sort the architecture elements that are already there. Additionally, Zach-man Framework allows to identify the still missing parts of an architecture but it does not give any advice or procedure on how to develop the missing links. To cover these aspects, it is necessary to return to other approaches that offer these procedures. Therefore, the

Zachman Framework rather serves as complement to other architecture methodologies.

It is excluded in this step but still should be considered in the more specific description of the architecture in section 3.3 as its strengths certainly lie in the mature and practically approved generic structure.

Gartner Frameworkis excluded in this step. Although Gartner is rather famous and fre-quently mentioned in the context of enterprise architecture it is not a methodology of its own but rather stands for guided implementations of customized existing architecture frameworks.

ISO 42010is excluded in this step. The standard provides an abstract description of aspects that need to be considered when designing an architecture including a conceptual model of an architectural description. The conceptual model depicted in Figure 3.4 is extensive and provides important structural aspects for an architecture. Therefore, the meta-model from ISO 42010 will be considered in the more specific description of the architecture in section 3.3.

Regarding the procedure to develop an architecture, the standard only gives a brief list of steps that need to be taken when designing an architecture according to the framework described in the standard. ISO 42010 is very generic and leaves most of the aspects to the user and does not give any advices and procedures. In combination with a more detailed guidebook ISO 42010 might be a valuable source. In this context it is seen as the source of basic principles that need to be followed when developing an architecture – though it is not capable of supporting the design process.

ISO 14813 is excluded in this step. The standard provides a valuable description of dif-ferent viewpoints but like ISO 42010 lacks a detailed description of a methodology how to apply the standard to develop an architecture. Nevertheless, the standard shall be consid-ered in later steps as the aspects on viewpoints might serve as input to design a complete list of viewpoints in the modification phase of the finally selected model.

3.2.4.1.3. Step 3 – Selection process II

Evaluating the strengths and weaknesses of the candidates remaining from the previous step with the second set of criteria developed in the theoretical procedure (3.2.3.1.3) leads to the results summarized in Table A.2.

FRAMEis excluded in this step because it does not ensure that different versions or im-plementations of the architecture model are interoperable. FRAME allows to modify its structure to the regional users needs. Unfortunately, the changes made to the structure for this modifications lead to the loss of compatibility of the different framework instances.

One key aspect of C-ITS will be that there will be a growing number of various individual implementations before a single architecture might be mandated for all implementations.

Though interoperability between different implementations is required as especially the mobile ITS Stations in the C-ITS context get in touch with different regional implementa-tions.

For Germany the FGSV analyzed the possibility to develop the national German ITS archi-tecture based on the structures propose by FRAME [FGSV AA 3.1.4, 2012]. They mainly criticized that FRAME only uses an implicit business process and that its details are not transparent to the user, that the functions in FRAME are not completely designed in a modular way so that they only can be reused partially, that FRAME already provides a

Figure 3.4.: ISO 42010 Conceptual Model of architectural description [2007]

fixed assignment of modules to technical subsystems what leads to a loss of flexibility and that the data model and data structures do not conform to the current state of the art.

Although FRAME is excluded in this step for the reasons described above its general con-cept shall be considered in the description of the overall architecture. FRAME with its first attempts on creating an architecture model with modular structures from which the real systems can be constructed like out of a toolbox is a rather crucial aspect that will be picked up (in 3.2.6 and section 4.1) and refined (in section 5.1).

ISO 10746is excluded in this step because the architecture model does not include differ-ent levels of abstraction which will be needed in this context. Though ISO 10746 provides very valuable input for the description of viewpoints, these aspects shall be included in the subsequent discussions (3.3) although ISO 10746 is not selected here.

TOGAFfinally is selected as core methodology for designing the framework for a C-ITS ar-chitecture methodology. Though TOGAF was not explicitly applied to C-ITS so far the se-lection process carved out several reasons for selecting TOGAF amongst which are the

ap-plicability to distributed systems (without a specific focus on the characteristics of C-ITS) and the interoperability of different realizations of the TOGAF methodology.

Like previously stated valuable aspects from other analyzed methodologies – partially not addressed in the selected methodology (TOGAF) – will be incorporated when designing the C-ITS architecture methodology.

3.2.4.1.4. Step 4 – Derive levels and layers from selected architecture models and