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

You are here

What is ITS Architecture?

The term "ITS architecture" literally means, "System Architecture for Intelligent Transport Systems". As a system architecture it provides a view of how an Intelligent Transport System (ITS) implementation will look from a system design perspective. ITS architectures are primarily about data exchange and the control instructions that pass between the different ITS components and the external interfaces (operators, stakeholders and other systems). It needs to reflect the real-world constraints that operate on transport agencies and the requirements these impose on the ITS implementation. Examples are interoperability between the participating agencies and the retention of information control by the respective agencies.

An ITS architecture may show where existing organisational structures need to be modified and changed – perhaps quite radically – in order to deliver the desired ITS services. An example is a traffic control centre (TCC) that may need to exchange data with another TCC or a traveller information centre (TIC), possibly across national or language boundaries. Defining the content and minimum performance specification for this transaction matters a great deal. The ITS architecture enables the performance specification to be defined to achieve the required level of interconnection and interoperability. The choice of which specific technologies are best to use in response is a matter for the system designer.

It is not possible to present a complex system in a way that can convey all the information about the system in an understandable manner. This is reflected in an ITS architecture, where multiple viewpoints, depicting different levels of detail and different types of information are used. These viewpoints might include:

  • the logic (or functionality) of the system describing how various items of data should flow and be processed (the “logical” or “functional” viewpoint)
  • how the ITS functionality will reside in the physical components of the system (the “physical” viewpoint)
  • what communications are needed between the physical components – and between the outside world and the physical components (the “communications” viewpoint)
  • how the system components, communications and responsibilities are to be assigned to providers and recipients of the ITS services (the “organisational” viewpoint)

Along with development of an architecture for ITS there are other analysis requirements to consider – among them:

  • how the components and communications might be deployed (the deployment plan) (See Formulating a Programme)
  • what the costs of deployment are likely to be, and how these will be off-set by benefits (a cost/benefit analysis) (See Project Appraisal)
  • a study of the risks affecting the whole implementation and delivery of the ITS services (a risk analysis)
  • It is often important to define the system boundary to show what is outside the specific ITS implementation but important for some of the functional components - for example the financial institutions, such as banks, in the case of toll payment or electronic ticketing

Levels of ITS architecture

ITS architectures can be divided into two levels: high-level architectures and low-level architectures. This is not something that is peculiar to ITS – the distinction applies to the use of system architectures in general.

In the context of Intelligent Transport Systems, a high level architecture is the conceptual design that defines the structure and/or behaviour of the system. It specifies the functionality needed to provide ITS user services – the specifications are technology independent and the selection of individual components and communications are left open. This technology independence means that suppliers have freedom to choose a technical solution that is most appropriate for the client, whilst still complying with the overall architecture.

Low-level (or component) architectures, by contrast, contain the actual designs for hardware, software, data exchange and communications. They define more narrowly the technologies required including the use of ITS standards. (See ITS Standards) A low-level architecture could be developed by the commissioning body, if they have the expertise, but it is more common for design specifications to be developed from a high-level architecture by the systems integrator or system supplier. (See Systems Engineering)

High-level ITS Architectures

High level ITS architectures are developed to ensure that component systems can be successfully integrated and that the ITS deployment satisfies certain objectives – namely it:

  • is planned in a logical manner
  • meets the desired performance levels
  • is easy to manage, maintain and extend
  • delivers the desired performance and satisfies user expectations

They have the following characteristics:

  • they describe the function, role and performance requirements of the components and the communications links that enable data exchange;
  • they take account of the world outside the specific ITS deployment which will consist of some or all of the following:
    • other systems
    • users of ITS services – for mobility of people and goods
    • system operators – who manage and maintain the components and communications
    • they can often highlight where new technology may be needed and make the case for carrying out research

The creation of a high level ITS architecture with optimal system configuration requires the analysis of a number of different – but crucial – aspects of the proposed deployment, as follows:

  • a logical (or functional) viewpoint – what functionality is needed to deliver the services that the ITS architecture supports?
  • a physical viewpoint – what system components are needed to deliver the required functionality, and how can these components be grouped together and co-located?
  • a communications viewpoint – how does the choice and distribution of functionality in system components and component locations impact on the overall communications requirements?
  • an organisational viewpoint – what organisational structure is needed to manage and operate the ITS implementation and how does this fit in with what already exists?
  • a deployment plan – how are components and communications to be deployed, taking account of how many existing system components can be re-used?
  • a cost/benefit analysis – to estimate the cost of supply and installation of components and communications, offset against the value of benefits from the deployment of ITS
  • a risk analysis – to evaluate the areas of risk associated with the deployment, and who will be responsible for their mitigation

The relationship between different system viewpoints and other important aspects of ITS deployment is illustrated by the diagram below.

Relationships between different ITS architecture viewpoints and other aspects of ITS deployment

The relationships shown in the diagram are bi-directional to illustrate how results from one one aspect may influence another. For example, as a result of creating the communications and/or organisational viewpoints it can sometime be necessary to modify the physical viewpoint.

To gain maximum benefit from a high-level architecture it should be developed before any work is done to procure the components and communications needed for the ITS deployment.

Low-level ITS Architectures

Low-level (or component) ITS architectures contain the actual designs and specifications for hardware, software, data exchange and communications. They define more narrowly the technologies required including the use of and the ITS related standards that are to be used particularly for interfaces and communications. (See ITS Standards) A low-level architecture could be developed by the commissioning body, if it has the expertise, but it is more common for design specifications to be developed from a high-level architecture by the systems integrator or system supplier (See Systems Engineering) and may not always be in the public domain.


There is an analogy between the different levels of ITS architecture and the architecture for a house. In both cases the architecture may have to be expressed in various forms to suit different audiences. For the house buyer, the architecture is initially used to show how the completed house will appear and the floor plan, for example room sizes and where the toilets are located. Once the homeowner is satisfied, more detail is added so that the construction workers are provided with drawings of walls, beams and columns including their precise dimensions. Similarly, the system architecture for an ITS deployment may be expressed in various forms that are mutually consistent. High-level ITS architecture provides stakeholders with views of how the ITS implementation will appear to them. Low-level ITS architectures expand this to include the technical details that enable equipment suppliers and system integrators to implement the services. The selection of a particular architectural form depends on how far the ITS concept has ben developed and the needs of the audience at hand. The idea of multiple architectural forms is consistent with the multiple viewpoints in the IEEE standard 1471-2000, “Recommended Practice for Architectural Description of Software-Intensive Systems.”

Advice to practitioners

There are two types of high level ITS architecture in common use around the world – which offer two basic but different approaches – a framework architecture and a ‘model’ architecture – both of which provide a basis for the development of ITS architectures that can be adapted to suit particular ITS implementations. Some of these ITS architectures can be specific to a class of ITS applications. This is because they support implementation of a specific service, such as traffic control centres, car park management, or public transport fleet management.

Framework ITS Architectures

A framework ITS architecture will use a set of user-led service specifications for different ITS applications that provide a flexible basis for further refinement and development. A framework approach is particularly suited to circumstances where a ‘top-down’ universal approach is not feasible. A framework ITS architecture provides the basis for stand-alone ITS master plans to be developed at the appropriate level (national, regional or local). It can also facilitate cross-border integration and an open market for interoperable ITS services and equipment. The best known example of a framework ITS architecture is the European ITS Framework Architecture (the FRAME Architecture - See A number of countries are using the FRAME Architecture as the starting point for their own national ITS architecture developments – these include Australia, Austria, Czech Republic, France, Hungary, Italy and Poland.

Framework ITS architectures have the following advantages:

  • it makes it possible to achieve the harmonious integration of systems by defining where common standards, norms and practices can be used
  • it prompts the resolution of important issues - such as stakeholder relationships and responsibilities for communications infrastructure provision
  • they can be easily developed and adapted to provide a framework ITS architecture in different national contexts
  • users can expand a framework ITS architecture to support additional services
  • they can be used to develop low-level ITS (or component) architectures that are adapted for particular ITS implementations – giving users the freedom to create their own component configurations and specify the associated communications networks
  • they can be used to explore alternative component configurations and associated communications networks - making it possible to investigate the options leading to an optimum ITS architecture for a particular deployment

‘model’ architecture

Many regions of the world have developed ‘model’ ITS architectures that are adapted to the needs and requirements of their region and institutional arrangements. They are generally more prescriptive in how ITS deployments must be rolled out when compared with a framework ITS architecture. They often contain a physical viewpoint that will define the components used to deliver the services the architecture is able to support. For example the USA’s National ITS Architecture ( is fixed and its use is obligatory if federal financial support for ITS deployment is sought. It defines:

  • the functions of the system and sub-system components
  • where these functions reside (at the roadside, in a traffic management centre, or in a vehicle)
  • the interfaces and information flows between subsystems
  • the communications requirements for the information flows in order to address the underlying user service requirements
  • where standardisation of equipment, interfaces and communications at the national level will bring benefits

Other regions which have, or are, considering developing ‘model’ national architectures include Canada, Chile, Japan, Korea and Mexico. Further information is available in the review of current ITS architecture in use and/or planned from around the world available from the "Library/Other Architecture Reports" page of the FRAME web site at:

ADAPTING ITS Architectures

A framework ITS architecture and a ‘model’ ITS architecture both provide a structure (or template) from which ITS architectures adapted for particular ITS deployment can be generated. This allows the user the flexibility to tailor the architecture for specific deployments without losing the benefit of its common features - such as the interfaces for system components and communications. Standard interfaces are very important for consistent systems integration and will have greater importance in the future with the advent of cooperative systems ("C-ITS" for short, and known as "connected vehicles" in the USA). This is because of the need for services to be delivered in the same way, everywhere within a region, for example the USA, Europe, Australia and Japan. They make the exchange of information possible at an affordable and effective level.

ITS architectures that are adapted and customised from a framework ITS architecture have the following characteristics:

  • they can either be used for a particular ITS implementation or as the basis for a series of ITS implementations that use some or all of a common set of functionality (such as regional or urban ITS deployments)
  • it is possible to modify the content and add functionality to support additional services before defining the physical viewpoint
  • although adding additional functionality is not difficult, it is often advantageous to enlist the help of specialist consultants
  • a tool will need to be provided to enable the framework ITS architecture to be adapted and this can simplify its use and application

The FRAME architecture (see is the best known examples of a framework ITS architecture being used as the 'master" for regional and urban ITS deployments across Europe and other countries, as well as European research projects.

ITS architectures that are customised from a 'model' ITS architecture have the following characteristics:

  • they can either be used for a particular ITS implementation or as the basis for a series of ITS implementations that use some or all of a common set of components and communications networks (such as regional or urban ITS deployments)
  • the content is more restricted in terms of its functionality although there may be limited options for varying the component configuration – for example the options for the communications network are restricted to what is compatible with the common specifications
  • as a result of the content being restricted, a 'model' ITS architecture cannot be easily expanded by its users to include previously unsupported services – this has to be done by specialist consultants
  • if not already available, a tool will need to be provided to enable the 'model' ITS architecture to be adapted and this can simplify its use and application

The US National ITS Architecture ( is probably the best known examples of a 'model' ITS architecture, being used as the ‘master’ for regional and urban ITS deployments in the USA, Canada, Chile, Israel and other countries.

Which type to use?

The choice of which particular ITS architecture development approach to use is dependent on the ultimate objective of the responsible authority or organisation – and will depend on how the ITS architecture is to be used and what is to be the starting point for its creation. In some cases the use of a 'model' ITS architecture is mandatory. For example in the USA, federal financing for ITS deployments is conditional on using of the National Architecture.

A framework ITS Architecture is generally more flexible than a 'model' ITS architecture – though both can be expanded to include extra and/or alternative services. Since framework ITS architectures are not prescriptive they can facilitate the search for an optimum component/communications solution to an ITS implementation. Using a framework ITS architecture requires some training from experts since its users need to understand the ITS architecture creation process and how to use it. (See Resources) A 'model' ITS Architecture is the least flexible since it contains restricted component configuration and communications specifications. But if no changes to the supported services are needed, they are often easier to use and do not require its users to be expert in the creation of an ITS architecture.

For economies in transition it is important to go back to basics to understand the scope for ITS to improve local transport problems and respond to user needs. These must be fully reflected in the ITS architecture’s design and specifications. This is necessary so that ITS deployments are planned and well suited to the local context. (See Deployment Strategies) It should be noted that a 'model' ITS architecture from one region may require considerable modification to adapt it so that it can be suitable for use elsewhere in other implementations of ITS.


ITS Architecture practitioners use many terms - a few are used more frequently than others. These include "component", "data", "information", and "communications" and it is necessary to make sure that everyone has the same understanding of how they are used. In addition, practitioners need to understand the difference between “logical” or “functional architecture” and “physical architecture”.


When considering an ITS Architecture, a "component" is a generalised term used for any constituent part of any ITS implementation that can be provided as an individual item. It can be considered to be a "building block" from which ITS implementations are assembled. It can be created from one or more "bits" of hardware or a combination of hardware and software. Sometimes a combined set of components will be called a "sub-system" of which there may be several in one ITS implementation.

Data and Information

Data about what is happening in the world outside that is relevant to the ITS implementation, arrives from many sources. (SeeBasic Info-structure and Data and Information)  It can represent the presence of a vehicle, data about a trip that a traveller wants to make, or details of goods and the origin and destination of their movements. The data can also be provided by other systems - such as data about the weather or details of services provided by non-road transport modes.

Information is the result of data that has been processed by one or more components within the ITS application. It can be traffic flow rates, traffic conditions, a trip plan, or details about a goods movement. It can also be the content of a variable message display and the "red/amber/green" indications at traffic signals.

Data Communications

The term "data communications" or sometimes "data communications link" is the term given to the mechanism through which data or information is transferred from one component to another - or between a component and something outside the ITS implementation. It can consist of one or more transmission media such as physical cable, wireless, microwave or infra-red - although their specific use may not be defined in the ITS architecture. Communications between people are enabled through an interface provided by a specialist component. For example an operator interface may provide access to several ITS services or traveller information may be provided by a variable message display.

Logical Architecture or Functional Viewpoint

The logical architecture or functional viewpoint depicts the functions of the ITS deployment and the associated data flows that take place between the internal components and those that link externally to people, data sources and other systems. This is defined in the formal descriptions of the services. Its development is used to identify common areas of functionality - so that the data can be shared across as many services as possible. The principle of "collect data once, share and use it many times" applies. The logical architecture is independent of any hardware or software approach.

Whilst all ITS Architectures have a logical architecture, the need to make it visible depends on the type of ITS architecture that is being created and how it is to be used. Generally speaking framework ITS Architectures need them, but customised ITS Architectures do not. How the logical architecture - or functional viewpoint - appears and is accessed will depend on which type of ITS architecture is used as the starting point for its creation.

Physical Architecture or Viewpoint

In the context of systems engineering, the physical architecture or viewpoint shows how the functionality defined by the logical architecture (or functional viewpoint) is to be distributed amongst the system components in different organisations and locations. It is not a detailed design, nor does it include details on specific numbers of systems or equipment at particular geographic locations. Responsibility for the ownership, operation and maintenance of the system components may also be divided between different organisations.

One of the advantages of using a framework ITS architecture (such as the European FRAME architecture) is the option of exploring alternative physical architectures whilst maintaining the same logical architecture. This makes it possible to arrive at an optimal distribution of functionality in response to local requirements.

Communications Architecture or Viewpoint

The communications architecture or viewpoint is created from the physical architecture and provides a more detailed specification of the data flows. It is at this point that the data flow characteristics are defined, such as how long the data transfer can take, how often, what security will be needed and how much data there is likely to be. The need for inter-operability can be assessed - for example enabling the same form of electronic payment to be used for all services. These detailed specifications enable a search to be made for suitable local, national or international communications standards. Existing standards should always be used wherever possible as this avoids the (sometimes lengthy) standards creation process and may make it possible to use existing telecommunications infrastructures. This means ITS deployments can take advantage of the rapid changes taking place in the telecommunications industry. Choice of communications will depend on what is available locally and the tariffs that can be negotiated with service providers. These issues need to be explored with the communications providers.

Organisational Architecture or Viewpoint

The organisational architecture or viewpoint is also created from the physical architecture and shows who will be responsible for the operation, maintenance and management of the components and communications links. It will also highlight the organisational structure that will be needed to support the ITS implementation so that it can be compared with what currently exists. This enables any changes that will be needed in organisational structure, roles and responsibilities to be described and then agreed by the stakeholders before the ITS implementation has begun.

System Boundary

This is an important but sometimes overlooked concept that defines the external boundaries of the ITS implementation - and where and in what form, interfaces are needed between the subsystems and the end users. As well as describing the interfaces it is also necessary to describe how the subsystems expect what is outside the ITS implementation to behave. An example of such an interface is the connection to a vehicle registration database held by the police or licensing authority which an ITS subsystem may need to access for the purposes of collecting electronic toll payments. For the ITS architecture the description of the database need only say what it is expected to do, e.g. provide contact information for a specific vehicle identity.

One important point to note is that end users that are human beings, e.g. travellers, system operators, transport planners and fleet managers, are always outside the system boundary. It is the input and output interfaces that are provided for their use that are inside the system boundary.


Further Information

Copies of the European ITS Framework (or FRAME) Architecture plus its documentation and tools can be obtained at The FRAME Architecture includes support for Cooperative Systems/Connected Vehicles.

Copies of the US National ITS Architecture plus its documentation and tools can be obtained at Copies of the US Connected Vehicle Reference Implementation Architecture (CVRIA – for Cooperative Systems/Connected Vehicles) plus its documentation and tools can be obtained at

Reference sources

IEEE Standards Association (2000) 1471-2000 IEEE Recommended Practice for Architectural Description for Software-Intensive Systems available for download at:

European ITS Framework Architecture (the FRAME Architecture) (See the FRAME web site:

US National ITS Architecture (See:

US Connected Vehicle Reference Implementation Architecture (CVRIA) (See