Diskussion:IVS-Architekturprinzipien

Intelligent Transport Systems

• are intelligent applications in the field of transport, transport and mobility that can be used by the ITS end-user as an ITS service and enable ITS end-users with more comprehensive information to use transport networks in a safer, more coordinated and "smarter" way (see the status and framework conditions for Intelligent Transport Systems ITS in Germany 2010[1]).
• use information and communication technologies (ICT) in road transport and at the interfaces with other modes of transport to collect,transmit, process and exchange traffic-related data and information (see ITS Law).
• are not allowed to use the word intelligence in the sense of artificial intelligence (AI), but must be understood in the sense of business intelligence. Intelligence is a synonym for information and insights gained by collecting and evaluating data and information with the aim of enabling the end-user of ITS to make better strategic and/or operational decisions with regard to his or her objectives, or, from the operator's point of view, to exercise a special effect on end-users of ITS in such a way that they orient their behaviour towards the operator's objectives.

ITS architecture - the architecture of intelligent transport systems

ITS architecture essentially deals with not only the functional, technical and economic realisation but above all the creative planning of ITS and ITS services. ITS architecture is hereby based on overarching policies and aims of the “builder-owners”.

In this respect, the core competence of an ITS architect goes beyond a simple knowledge of how to realise ITS and ITS services and lies primarily in the creation of an ITS architecture based on suggestions and characteristics of features of ITS architecture that correspond to the policies and aims of the builder-owner, or they develop their own ideas on this.

The ITS architecture pyramid

The “ITS System Architectures” working group of the Road and Transportation Research Association (FGSV) has suggested that ITS architects use the “ITS pyramid” described and substantiated below as a suitable meta-model and methodological aid for a well-organised and understandable representation and description of ITS services (see Notes on Structuring a Framework Architecture for Intelligent Transport Systems (ITS) in Germany – Necessity and Methodology, FGSV No. 305[2]).

The ITS architecture pyramid with 5 levels

The ITS architecture pyramid

• consists of five layers, which together cover the potentially possible scope within which an ITS architecture can be considered and shown.
• represents the structure of ITS services so as to be able to better identify, classify and correlate their properties by means of this.
• provides the semantics for the ITS business models needed to describe ITS services.

The ITS architecture pyramid contains the following layers:

The policy/strategy level describes...

• the goals of ITS and ITS services (creation of added value) in the form of a policy,
• how, i.e. in which way the ITS goals are to be achieved (strategy).

The processes level describes and identifies...

• which ITS roles are involved in the creation of added value with the help of ITS,
• how the ITS roles interpret ITS goals and ITS strategy for themselves as a business case,
• how the ITS added value/ITS benefits are generated by means of the cooperation/relationship between the ITS roles and operationalized in ITS business processes.

The information structures level describes and identifies ...

• which ITS information contributes to the creation of ITS added value, and
• how this is structured.

The IT services level and IT infrastructure level describe ...

• how the ITS information can be generated, and
• how/where it is provided.

The ITS architecture pyramid can be used in all phases of a content-related discussion on all relevant aspects of ITS and ITS services. Above all, demands for an altered understanding of roles can be identified and specified using the ITS architecture pyramid. The ITS architecture pyramid can always convey the logical context, particularly if distributed ITS services are to be realised.

Instances of ITS architecture

The “Notes on Structuring a Framework Architecture for Intelligent Transport Systems (ITS) in Germany – Necessity and Methodology, FGSV No. 305” differentiate between three instance levels for ITS architectures.

Instance levels of ITS architecture

The ITS framework architecture...

• specifies ITS design elements as architectural modules (TOGAF: building blocks) and defines terms and their corresponding semantics (ITS glossary).
• specifies design principles, on the basis of which the ITS architect is to proceed when planning and realising ITS services.

AnITS reference architecture...

• specifies the concepts for an ITS service category (ITS service family) for the scope of a specific ITS domain predetermined by the ITS framework architecture.

The ITS architecture of real ITS services...

• is the actual implementation of relevant ITS reference architectures down to the last level of detail in a concrete application case.

The number of ITS reference architectures is basically unlimited. In the present project network for lots 1- 4, ITS reference architectures have been developed for three ITS service categories in lots 2 to 4, namely:

• Lot 2: Continuous traffic information private traffic
• Lot 3: Cross-organisational traffic management
• Lot 4: Multi-modal travel information

Features of ITS architecture to implement ITS architecture

Implementation of ITS architecture

ITS architecture concepts that are formulated by features of ITS architecture and their semantics and that should uniformly determine the character and nature of ITS services have to be developed for the implementation of ITS architecture. The entirety of ITS architecture concepts could be called the ITS architecture school.

For example, if “interoperability” is a stylistic feature of the ITS architects/ITS architecture school, the architectural feature “interoperability” will turn up again in all parts of the ITS object of reflection in a wide variety of manifestation.

The ITS architecture school that is represented by the ITS framework architecture predominantly implements political objectives. However, because “clever” politics always incorporates the interests of the basis too, the "received opinion" also reflects the builder-owner’s interest in real ITS services through the permanent incorporation of stakeholders and ITS actors (see also“Open ITS” as a main idea).

Concept instantiation to specify ITS architecture

Going Meta

The methodology of concept instantiation, in other words the transfer and representation of ITS architecture concepts with their semantics (see too the model basis for comprehensibility), starting from the ITS framework architecture, through the ITS reference architecture, right down to ITS architectures for real ITS services.

• The ITS framework architecture (meta-meta model of the real world) structures, describes semantically and ultimately substantiates the architectural concepts necessary for the ITS architecture of ITS services through the suggestion of corresponding features of ITS architecture.
• ITS reference architectures (meta-models of the real world) specify the architectural concepts of the ITS framework architecture for a category of ITS services.
• ITS architectures for real ITS services (models of the real world) further specify and implement the architectural concepts of the ITS framework architecture for a real ITS service that has already been specified for a category of ITS services.

Examples of concept instantiation are:

The ITS framework architecture module	Use for the ITS reference architecture	Use for the ITS architecture of real ITS services
ITS service as a concept(principle of the ITS value-added chain/ITS value-added network)	Stereotype of ITS services (traffic information private traffic, cross-organisational traffic management and multi-modal traffic information)	Real ITS service (Google Maps, Dmotion traffic control for alternative routes, Deutsche Bahn travel information ...)
ITS role as a concept(as an add-on element for ITS value-added chains and networks)	Stereotypes of ITS actors (navigation service provider, public roads operator, transport company ...)	Real ITS actors (Google, Hessen Mobil/Office for Traffic Management Düsseldorf and Deutsche Bahn)
ITS added value as a concept (as a goal and result of the ITS value-added chains and networks)	Stereotypes of ITS added values (increased safety, improved efficiency, reduction of environmental impacts ...)	Real ITS parameters (number of deaths by accident, traffic jam balance, CO2 and NOX emissions)

However, the ITS architecture of a real ITS service does not necessarily have to comply with the ITS framework architecture and ITS reference architecture in all points. The breadth and depth of the ITS architecture concept instantiation are left to the discretion of the implementer. The evaluation of the ITS architecture and thus the benefit of a real ITS service is therefore left to the discretion of the user.

Quality of ITS architecture

Is there a “good” ITS architecture?

Constructive foresight is a desirable qualification of an ITS architect; it is something he/she either does or does not have. If they have it, they will use the freedom it offers to design ITS services so that the features of the current service to be implemented do not get in the way of one of the main goals of ITS architecture, insofar as they are aware of this, namely future possibilities for integration or extension.

An ITS reference architecture or the ITS architecture of a real ITS service are a “good” architecture if they transfer the features of the ITS framework architecture to the architecture of an ITS service category or a real ITS service true to the concept.

However, it should be remembered that “good” is an ideal. In other words,the ITS framework architecture is primarily an aid to orientation and assessment in a concrete application case so as to be able to understandably pursue the purpose of achieving a good architecture. Unavoidable deviations can then be identified, evaluated and in classified in an overall picture.

Combination of TOGAF concepts with the ideas of ITS architecture

Architecture domains of TOGAF

Architecture domains of TOGAF en.png

In order to make the discussion about terms and their semantics in the “ITS Architecture Road for Germany” project more objective and effective from the very outset, and to adjust this to the overarching objective of a consensual creation of an ITS framework architecture and three ITS reference architectures, the standardisation initiative TOGAF offer the meta-model of TOGAFG architecture domains arranged in layers with the aim of being able to describe the complex behaviour of companies on the basis of agreed (standardised) fundamental concepts (so-called base architectures) homogeneously in future under the key word corporate architecture.

This brings us full circle to the current idea of ITS architecture, which is characterised by the ITS architecture pyramid as a hierarchic regulating principle that can be portrayed on the layers of the layer model.

Important notice:

to find out more about TOGAF and the individual steps of the TOGAF ADM, an account has to be created on the “The Open Group” website (TOGAF-Login).

TOGAF architecture domains and the levels of the ITS pyramid

TOGAF is an extensive model and contains some very powerful concepts. In this respect, one particular issue in the development of the ITS framework architecture is first to identify TOGAF concepts that are actually relevant for the ITS architecture and then to transpose these to ITS and put them across in such a way that ITS experts see a genuine benefit in them, actually accept and internalise them in the form of ITS architecture in the sense of an “Open ITS” (theory meets practice).

Against this background, the methodological challenge of using TOGAF consists of:

• transposing the TOGAF concepts, in other words what TOGAF is structurally and semantically really about, associated with the TOGAF architecture domains shown to ITS architecture domains, and
• addressing, and interpreting for ITS, those levels and sub-levels of the TOGAF architecture domains that are in fact important for the ITS functionality and ITS behaviour through the use and adaptation of the TOGAF-ADM (quality over quantity).

Illustration of the TOGAF architecture domains on the levels of the ITS pyramid

Of course, it is obvious that only the most important levels/sub-levels of the ITS framework architecture and their areas can and must be addressed, i.e. precisely those that are important for the functionality and behaviour of ITS services. Put metaphorically, those sub-areas of in the TOGAF levels have to be identified for ITS services that can subsume general design goals for ITS architectures (ITS reference architectures, ITS architecture of real ITS services) to the general TOGAF goals. ITS goals in this sense are more specific than TOGAF goals. A conformity is given, for example, if features of an ITS goal can also be identified as features of a TOGAF goal.

Relationship between TOGAF and ITS

TOGAF on the whole stands for a semantic structure that relates the TOGAF-relevant concepts and hence provides a fundamental order for the overarching designs of TOGAF domains. Designs should improve or even enable types of cooperation between ITS actors in global contexts in the first place. Efficiency and effectiveness are hereby key quality features in the arrangement of design-related decisions.

There has as yet been no “sharp” definition of ITS. This means that ways have to be found for interpretations which allow an explanation of how a general TOGAF view of TOGAF concepts can be transposed or related to ITS concepts that is comprehensible for third parties. Conversely, it also has to be shown that the generally speaking more specific ITS concepts are relevant for TOGAF. In other words, it must be possible to verify that the focus of ITS design corresponds to the purpose of the TOGAF design.

An agreement should be reached, wherever possible, on the use of existing and proven standards and the concepts offered therein for the linguistic description of elements of the terminology and their presentation. This is the only way to objectify subjective issues, at least in the presentation.

Bibliography

<< Zurück zur Hauptseite