Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
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:
Along with development of an architecture for ITS there are other analysis requirements to consider – among them:
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 are developed to ensure that component systems can be successfully integrated and that the ITS deployment satisfies certain objectives – namely it:
They have the following characteristics:
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:
The relationship between different system viewpoints and other important aspects of ITS deployment is illustrated by the diagram below.
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 (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.”
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.
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 http://www.frame-online.net/). 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:
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 (www.iteris.com/itsarch/) is fixed and its use is obligatory if federal financial support for ITS deployment is sought. It defines:
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: http://ww.frame-online.net.
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:
The FRAME architecture (see http://www.frame-online.net) 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:
The US National ITS Architecture (http://www.iteris.com/itsarch/) 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.
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 about what is happening in the world outside that is relevant to the ITS implementation, arrives from many sources. (See: Basic 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.
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.
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.
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.
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.
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.
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.
Copies of the European ITS Framework (or FRAME) Architecture plus its documentation and tools can be obtained at http://www.frame-online.net/. 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 http://www.iteris.com/itsarch/. Copies of the US Connected Vehicle Reference Implementation Architecture (CVRIA – for Cooperative Systems/Connected Vehicles) plus its documentation and tools can be obtained at http://www.iteris.com/cvria/.
Print