Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!

You are here

How to Create an ITS Architecture?

There are two ways to create ITS architectures, either starting from nothing or by modifying an existing ITS architecture. Both approaches are directly related to the type of architecture from which they will be created (which could be either a “model” architecture such as the US National ITS Architecture or a framework architecture such as the European FRAME Architecture).

There has been much experience with ITS research, development and deployment - which is captured in two widely used architectures that exist today. The US and FRAME architectures have evolved with ITS over the past 20 years. Both have been refined to keep pace with ITS development and deployment in the two regions – and domestic and international standards have been developed, based on them. It would be very expensive to approach a new architecture development starting "from nothing". Adapting or adopting ITS functional definition from existing architectures offers a cost effective approach for a new architecture definition provided that the local user needs, institutional set-up and transport context (such as the package of user services, modal choices and traffic mix) are addressed. These may vary considerably from the assumptions inherent in either the US or FRAME Architectures.

The two ways of creating an architecture (start from nothing or adapt an existing architecture) share a common starting point. This is the description of the services that the ITS deployment is to provide - which has to be reflected in the ITS architecture. The process can be summarised as follows:

Service Descriptions -> User Needs -> Functional Definition -> Physical Partitioning -> Communications -> Linkages to Standards.

Operational concepts /Operational requirements

In the process shown above, any detailed concepts about how the services are to be delivered will be part of the “User Needs”. They are often referred to as “operational concepts” and “operational requirements” and are constraints that need to be applied in the ITS implementation process following the creation of the ITS architecture. Examples are a service “must be available all day every day (i.e. 24/7)”, or a service “must be available in the same way everywhere”. To highlight their importance these concepts are best captured in a Concept of Operations (ConOps) document that contains descriptions of how the services will actually work. To do this, the document requires inputs from some of the architecture viewpoints created later on in the ITS architecture creation process. So whilst creation of the ConOps document may be started early on in this process, it cannot be completed until nearer its end. (See Next Steps)

Describing the services

Describing the services that the ITS implementation is to provide is the first and most important step in the creation of ITS architectures. It is the foundation for all subsequent architecture development activities. (See Resources)

Consultation with Stakeholders

Generating the description of each service is best started by having a dialogue between the architecture team and those who want the service provided – usually referred to as stakeholders and who may be any of the following:

  • those responsible for traffic management and road network operations
  • those who "use" ITS services such as travellers and organisations that move people and goods as part of their businesses
  • government departments and agencies for whom ITS services can be a means of implementing government transport, social (accessibility and inclusivity) or environmental policies
  • organisations for whom the provision of a new ITS related travel service is a way of enhancing and expanding their businesses
  • manufacturers of ITS components, who want to broaden their product range and see an opportunity to do this through providing new vehicle or mobility related services

The process of engaging with stakeholders involves a sequence of activities:

  • Initial Outreach: to raise awareness of the project and identify the stakeholder community
  • Meetings: with the stakeholders to understand their requirements and where possible develop consensus on operational needs and supporting ITS deployments, producing what are called stakeholder aspirations
  • Ongoing Dialogue: to support architecture development and review project deliverables

The development team will need to meet key stakeholders, either individually, or as a group such as "road users", or a "quality circle." (See Planning and Reporting)

Another group to be consulted with be policy makers so that the services the ITS architecture provides will support national and regional policies. (See Why create an ITS architecture?) If a "vision" statement for the ITS implementation has been produced – those who developed it will need to be consulted. Another alternative is to select stakeholders by what they do (their function) – such as:

  • police, emergency services and road operators who are all involved in responses to incidents
  • port authorities, goods transport operators and road operators who are all involved in managing the movement of goods to and from ports
  • a relevant group of commercial businesses – for example toll road operators, information service providers or car park operators

At these meetings just asking the attendees what ITS services they would like to see may not produce any real detail on the services the stakeholders want, from which the stakeholder aspirations can be produced. Often more will be achieved by discussing what each stakeholder does, any problems they currently have (for example delivering policy outcomes or developing user services) and how they see their activities will develop in the future. A useful question to ask is “what will be the organisation's main activities in 3-5 years' time?” This type of question will focus discussion on what ITS features or facilities are desirable in the future.

The architecture team will need to be represented by at least 2 people - one to lead the discussion and the other to take notes. Each meeting should be planned to last long enough to explore the issues in depth (often between half a day and a whole day depending on the number of attendees). How many meetings will be needed depends on the number of stakeholders and whether the team meets them individually or in groups. The advantages of either option are:

  • meeting individually – provides an opportunity for frank and open discussion which may touch on matters of a sensitive nature
  • meeting in groups - is an opportunity for interaction between stakeholders and for developing a common understanding of what the ITS deployment is about – to reach agreement on its scope and essential requirements – and each party’s roles and responsibilities

When all the meetings have been completed the architecture team will need to produce a report that describes each of the services the stakeholders want (Service Descriptions) included in the ITS implementation. The end result must be an agreed set of service descriptions that the stakeholders are prepared to endorse through their commitment to supporting the ITS implementation.

"start From Nothing"

This approach creates the ITS architecture as something new, starting only from the service descriptions produced in conjunction with the stakeholders. This approach is not recommended for the following reasons:

  • based on experience with other ITS architectures, considerable resources will be needed, such as 3 person years of effort spread over a 2 year period
  • the ITS architecture may not be compatible with other ITS architectures currently known to be in use around the world
  • although the ITS architecture can be created with "standard" tools such as Microsoft WORD, VISIO and Access, it will be difficult to properly check it for consistency, so a specialist tool will be needed at extra cost
  • experience from many other ITS architectures has shown that the Process Oriented Methodology is best suited to ITS architectures (see ISO TR26999) - which may require some training for those involved to become familiar with its way of working, though its rules are "obvious"

There are a few specialist software tools available for ITS architecture creation. The two most widely used are probably System Architect from IBM and the Mega Process business modelling tool from Mega International.

adapt an existing ITS Architecture

Starting from an existing ITS architecture is normally the best way to create a new ITS architectures It builds on the experience gained from the creation of the existing ITS architecture – with the benefit of assistance being available from one or more sources if needed. There are two widely used options for creating ITS architectures in this way:

An ITS architecture that has been developed for one set of circumstances can be adapted and used as a starting point for other ITS architectures elsewhere if the circumstances are similar. For example an ITS Architecture created for one region might be successfully adapted to another region with suitable modifications. In general the ITS architecture development process follows the sequence:

Service Descriptions -> User Needs -> Functional Definition -> Physical Partitioning -> Communications -> Linkages to Standards.

The “operational concepts” and “operational requirements” explained above should be included in the user needs and will be important in the later steps in the ITS implementation process. They should also be covered by the Operations document. (See Next Steps)

The above process applies to any the creation of any ITS architecture. FRAME and the US Architecture both provide inputs to each of these process steps in different ways. Where the starting point is the:

  • US National ITS Architecture – its Turbo Architecture tool can be used to create variants of ITS architecture. There are 300 examples of its use as a starting point for customising ITS architectures
  • European FRAME Architecture - its Selection Tool enables a single set of functionality (called a functional viewpoint) to be created from the FRAME User Needs Descriptions. From this selection of one or more physical viewpoints can be created containing the same functionality but possibly in different physical locations

Advice to Practitioners

Before a choice can be made between the two starting points, it is important to have discussed and answered the following questions:

  • has the scope of the ITS implementation been discussed with the main stakeholders? As a minimum, the outlines of the service descriptions should be created to clarify what the stakeholders are expecting to be delivered
  • has it been decided how the ITS architecture will be used? For example is it for a one-off ITS implementation and if so - is it likely that it will be expanded in the future - either by adding new services or expanding the geographic coverage?
  • is it going to be an ITS architecture from which other ITS architectures will be created, and if so how much control is to be exercised over the customised ITS architectures that are derived?

The answers to these questions will help to decide which method is to be used to create the ITS architecture. Whatever the answers, use caution if the "Start From Nothing" approach is used because it will require a heavy commitment of resources over a long period of time without the benefit provided by an existing ITS community.

Choosing between the two options to “Adapt an existing ITS architecture” is a balance between the following issues:

  • US Architecture – easy to use as a “model” architecture requiring little or no knowledge of the technical detail behind the ITS architecture creation process; but adapting it to incorporate local variations and/or completely new ITS services is not something that many users can do easily (See Using the US Architecture)
  • FRAME Architecture – requires a more intimate knowledge of the technical aspects of how to create an ITS architecture, but is very flexible and can be adapted to include local variations or new services if users follow the detailed guidance that is provided (See Using the FRAME Architecture)

If the services described by the stakeholders have a "US flavour" then the US National ITS Architecture is the obvious starting point – particularly if it is used for a single ITS implementation. In this case it is only the content of the services that is the deciding factor.

If there is not a good match between the services selected by the stakeholders and the US User Services or Service Packages, then the FRAME Architecture is a better starting point as it will be easier to adapt.

Issues for Developing Economies

Developing economies may have little or no existing ITS components or communications. This means that the ITS architecture will be describing what can be viewed as a "greenfield" ITS implementation. It is tempting to think that the best way forward is to adopt the "From Nothing" approach. This is not necessarily true for reasons of cost, complexity and the lack of support from an existing ITS architecture user community.

Further Information

A case study is available on the design of the Abu Dhabi Integrated Transportation Information and Navigation System “i-TINS".(See Case study)

Reference sources

No reference sources found.