Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Stakeholders involved in deploying ITS require an appreciation of how the ITS enabling technologies can work together as a system. Not only is it important to secure the necessary performance of the component systems individually, but it is also necessary to ensure that they interface with one another effectively, and integrate them together as a total system.
An ITS Architecture is a conceptual framework (or structure) to guide the deployment of ITS. It is a formal specification of requirements that defines in detail:
ITS architecture provides a rational basis for specifying the design of equipment and performance requirements – which is necessary for procurement, installation and the development of operational procedures. The architecture is not a definitive design but is a functional representation of the ITS deployment which will be developed into a detailed design taking account of choices available – for equipment, software systems and other technologies. The role of ITS architecture in the ITS implementation process is shown in the diagram below.
The discipline of developing an architecture allows stakeholders to gain an appreciation of the issues associated with ITS deployments, how they will work in practice and what organisational implications they will have. It makes it possible to provide a view of what the ITS services will look like to key stakeholders, including service users. Creating an ITS architecture enables stakeholders to understand better their various perspective in relation to an ITS deployment - such as:
All this can – and should – be done before work begins to procure, design, develop and deploy any of the components and communications that will be required. An important benefit of creating the ITS architecture is that many modifications to the design of the ITS implementation can be anticipated as a result of the systematically working through the requirements. This means that the need for changes can be identified and accommodated at an early stage in the implementation process which means they can be achieved at much less cost than if they were made later on, when some parts have been designed, produced, tested and installed.
An ITS architecture can be created for any road transport agency that is planning an investment in ITS for any geographic area, such as a nation, region, state, county, province or city. The ITS architecture will be based on a close analysis of how the chosen services are to operate together and interface with one another, leading to a set of high-level statements about the system requirements that are independent of the final design and technology choices.
Examples of the services that ITS can be used to provide for road network operations are:
In the past, ITS deployments were often installed to provide just one or two services for travellers and the movement of goods on the road network. Most of these services worked independently without any communications or data sharing between them. The continuous evolution of ITS has meant that its stakeholders have come to expect that a number of often complex services to manage, gather data and to provide information about the road network can be operated simultaneously within an ITS implementation. While there are risks of conflict between what is needed to provide these services, there are significant opportunities to maximise benefits by integrating them so that they work in synergy. ITS architecture (or system architecture for ITS to use its more correct name) provides the best tool for planning, defining, and integrating all the things needed to create and deploy, or implement ITS so that a combination of several services can be provided.
The development of an ITS architecture usually begins with a consensus building process involving multiple stakeholders focused on the ITS-based services that are to be provided. Thus, the resultant architecture represents a consensus among the users, service providers, and transport agencies expressed in common terms, definitions, boundaries, priorities and expectations among the stakeholders who will later be making independent, but now consistent and mutually supportive, decisions.
In summary the ITS architecture will define, for all concerned the physical entities and the data flows that connect them together to form an integrated system. ITS architecture analysis also provides support for the planning and implementation of integrated ITS, including a deployment programme, an organisational viewpoint, cost/benefit and risk analysis studies.
ITS architectures are developed from a set of user needs and user services defined through consultations with users and stakeholders. Thus, the architecture ensures that the ITS to be implemented is responsive to the needs of all stakeholders, rather than implementing technology for technology’s sake.
The ITS architecture will also show clearly and unambiguously the key processes which require standardised interfaces, especially for communications and data exchanges. It is common practice for the physical interfaces between architecture subsystems to be aligned with ITS and industry standards. By defining the different physical entities and the data that has to flow between them, the architecture provides the context for the identification of the most appropriate standards. Based on the interface definitions and an analysis of operational needs, user requirements and hardware/software specifications, the architecture can help identify whether existing standards can be used or if new standards need to be developed at local, regional, national, or international level.
The design and implementation of standardised ITS components and subsystems in conformance with the ITS architecture will stimulate an open market in equipment and software supply, permit economies of scale, ensure consistency of data and information, encourage investment, and help to ensure interoperability.
A good ITS architecture will consider failure modes and support logical steps to achieve graceful degradation of system performance under abnormal conditions. It will also identify transport policies that need be out in place and any assumptions made about who plays what role in the ITS implementation. This allows joint decisions between partners to be made in concert, reducing the risk of one organisation making wrong guesses as to what other organisations are going to do. By facilitating the identification of the most appropriate standards to be used, the ITS architecture also reduces the risk of de facto or proprietary standards perpetuated by the dominant manufacturers.
ITS needs to be integrated into the local or regional transportation plan. An ITS architecture supports this integration by enabling all involved to identify the intended relationships between ITS and conventional transportation plans and solutions. It can also add substance to those plans through the definition of what is required to provide which services and the priority for their implementation.
ITS architectures are used to describe how user services should be provided. This includes the data to be collected, what processing the data will need, where that processing should take place, what data should be shared between the components, plus where and when the resulting information is to be made available to users, other ITS deployments and vehicle fleet and logistics managers. In this way the architectures provides a versatile platform from which component, communications and software can be developed.
ITS architectures provide a framework for system expansion and technological upgrades so that systems can be adapted as stakeholder expectations change and ITS technology evolves. New services or wider geographic coverage can be added without expensive re-engineering or retrofits, provided always that the development is compatible and consistent with the architecture. A completely new ITS user service or a major revision to the service specification will most likely require a re-evaluation and modification to the architecture.
Print