The simplified methodology for creating an ITS Architecture from the European ITS Framework Architecture is illustrated in the figure below.

Methodology of the European ITS Framework Architecture

Source: own elaboration on the basis of the FRAME Team materials

Stakeholder Aspirations

Stakeholder Aspirations are statements that express the expectations and desires of the various stakeholders for the services that the ITS implementation will provide. They should be written by the stakeholders, but experience has shown that help is often needed from the architecture team.

European ITS Framework Architecture – User Needs

It is normal to find that the Stakeholder Aspirations will have been written in a variety of styles. Sometimes they can also be obscure and inconsistent. It is thus necessary to re-write them in a consistent manner that is suitable for the next stage in the process. The result is a set of User Needs that express the Stakeholder Aspirations in a consistent and stylised manner whose meaning is clear and whose properties are testable.

European ITS Framework Architecture – Functional View

A Functional View (sometimes called a Logical View) shows the functionality that will be required to fulfil the User Needs, and hence the Stakeholder Aspirations. When using the European ITS Framework Architecture the Functional View is shown as Data Flow Diagrams that contain functions, data stores and terminators, and the data that flows between them. Each of these is provided with its own description which, in the case of functions, includes statements explaining what they do. Since the European ITS Framework Architecture comprises a Functional View that satisfies all of its User Needs, the architecture team only has to select those parts of it that serve the User Needs that have been mapped to the Stakeholder Aspirations.

European ITS Framework Architecture – Physical View

Once the Functional View is complete, the architecture team allocates each item of functionality to a location, either within a sub-system, or within a module that is part of a sub-system. Once this has been completed the component (sub-system or module) specifications can be created from the definitions of the functions and data stores contained within them.

European ITS Framework Architecture – Organisation View

The Organisational Viewpoint is usually a derivative of the Physical Viewpoint. It is used to show the organisations that will own, and/or operate, and/or maintain the Sub-systems and Modules in the Physical Viewpoint. This is very useful for highlighting the relationships between different organisations and any conflicts that may arise. It can also be used to look at how data will have to be, or could be, shared between organisations.

Communications View

A consequence of allocating the functionality to sub-systems (and modules), is that it is immediately clear which Functional Data Flows lie within a sub-system (or module), and which pass between one sub-system and another, or between one module and another. Those that pass between sub-systems or modules make up the Physical Data Flows, and represent a communication channel between sub-systems, and/or between modules.

Since sub-systems are, by definition, located in different places (e.g. in a traffic management centre, at the road side, in a vehicle) it is possible to produce communications specifications by analysing the contents of each Physical Data Flow. This analysis may elicit that an existing Standard may be used for the communications. Alternatively it can be used as the basis for defining a new Standard if the need for one can be agreed.



Source: , the FRAME Team materials ,


We will reply to your message in 48 hours.



Log in with your credentials

Forgot your details?