How to Create an ITS Architecture?

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.

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.

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:

• use the US National ITS Architecture, which is a "model" architecture (See Using the US Architecture)
• use the European ITS Framework Architecture (often known as the "FRAME Architecture") (See Using the FRAME Architecture)

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