Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!
Within any single country or region, there are likely to be large differences between the set of ITS services useful for big cities and for rural areas. Many ITS applications (such as navigation and location based services) are market driven. In road network operations there are always key stakeholder groups, public authorities and private sector organisations with a part to play (for example - in motorway network management, traffic control and toll road operations). Each has different organisational areas of competence or responsibility (such as road safety, public transport, fleet logistics, policing and public security). Each has its own policy goals. Alongside there are the wider community objectives of improving road safety, transport efficiency and environmental quality. The process of stakeholder consultation is intended to take account of the bigger picture – to identify what ITS services are viable and how they should be implemented. This is outlined in the diagram below, which shows that the first step is to define the policy goals, and then identify the services that will support these goals. Stakeholders nominate the ITS services that will run either fully or partially within their own domains. These are then amalgamated to provide a set of services that have been jointly selected by all stakeholders.
The process of getting stakeholders involved should start by asking them to describe in their own words the services that they want the ITS deployment to include. In discussion these descriptions can then be modified so that they will support the policy goals. (See later more detailed section on "Describing the Services")(See How to Create One?) It can be very beneficial if this is done through a "stakeholder conference" so that the various groups can meet each other, discuss the options and understand each other's requirements. Often this will lead to the realisation that some of the services can be enhanced by exchanging data or information between different stakeholders.
For example, the highway network operators may be planning to deploy ITS for electronic tolling and automatic incident detection. This functionality can be adapted to give high-quality traffic and traveller information, with point-to-point journey times. An alliance between the network operators, toll road companies and the information service providers is needed to make this happen. The consortium will need to agree joint use of the ITS infrastructure, protocols for information exchange, and the data and information that they will use. All can be included in a common ITS architecture which serves the needs of all the partners.
Another example might involve the motorway network operators considering the use of ramp metering to maintain smooth traffic flow. An undesirable side effect can be long queues of vehicles that spill out onto the surrounding roads causing gridlock. Measures are needed to ensure that this does not happen. There may also be pressure to prioritise buses and coaches and other high-occupancy vehicles waiting on the ramp. The two network operators - for the motorways and the surrounding roads – need to design their traffic management policies and ITS deployments to minimise the conflict. This might involve some form of demand management with measures to encourage modal shift.
These examples emphasise the value of taking a broad view of the ITS deployment rather than each agency or organisation working in isolation. Collaborative working early on - to define the full scope of ITS deployment - means that changes can be made at relatively low cost before systems are designed and equipment has been purchased.
The benefits of creating and using ITS architectures depend on the different perspectives that stakeholders have: road network operators, transport service providers, suppliers.
The beneficiaries of ITS may be road authorities, road operating companies – who can benefit from ITS architectures in various ways:
Organisations that are concerned with the mobility of people and the movement of freight include national and local authorities and fleet operators concerned with intermodal transport – for whom ITS architectures provide the following benefits:
Suppliers may be component suppliers, communications providers or system integrators - for whom ITS architecture provides the following benefits:
An architecture approach can help all stakeholders to:
The risks of not carrying out the process of developing an ITS architecture may include:
If any of the risks are realised in practice, the costs involved in mitigating or correcting them will be significant. In some instances the only way forward is to "start again", and this time use an ITS architecture.
Despite all the benefits just described for developing an ITS Architecture, convincing the right people that creating and using ITS architectures is of benefit to ITS implementation is not always easy. There are several reasons for this, the most prominent of which is that ITS architectures are seen as a constraint on commercial suppliers and system integrators. In fact they may be more liberating than a constraint because they enable stakeholders to appreciate how the ITS implementation will appear to them and what it will do for them. ITS architectures also enable stakeholders to consider all the options for the ITS implementation, including choosing to use technologies that are a best match, or if they don't exist, incentivise some research to find them.
The process of creating and using ITS architectures enables stakeholders to be much clearer about the services they want from the proposed ITS deployment – what it will do and what it will look like. As a result there will be fewer "surprises" when the ITS implementation starts up. It will help to avoid negative comments such as "I didn't know it would do that", or "I wish it didn't do that", or "I wish it could ….".
The benefits of creating and using ITS architectures need to be "sold" to the right people, who are often referred to as "decision makers", meaning the people who decide that ITS will be implemented and that the finances will be made available to do it. In some instances a few of the stakeholders may also need to be convinced. So it is necessary to have a good "selling" pitch that can be tailored to suit each type of audience.
The use of ITS architectures in the ITS implementation process comes before any of the components or communications have been purchased or designed. This is because they do not contain any reference to technologies. In fact the component specifications and communications requirements produced from ITS architectures can be used as input to the procurement process. This is illustrated by the diagram below.
![[Figure 1] The use of ITS architectures in the ITS implementation process](/sites/rno/files/public/wysiwyg/import/systems-and-standards/1439900578html_html_m30bb4bb7.jpg "[Figure 1] The use of ITS architectures in the ITS implementation process")
Organisations use various terms for the procurement process – such as "Requests for Proposals", "Call for Tenders" or "Request for Solicitations". What is important is that the architecture is included in the contract documents and is used by suppliers, communications providers and system integrators when developing their proposals. This ensures that the specification for components and communications will deliver the ITS services described by the stakeholders.
As part of their bid responses - suppliers, communications providers and system integrators can be asked to illustrate their proposals with their own system, software, hardware, data and communications architectures, all of which are low-level or component architectures. Each one can be compared with the ITS architecture to make sure that they conform to requirements and show a good understanding of what the stakeholders want.
ITS architectures are also included in the systems engineering "V" model, as illustrated by the diagram below. (See Systems Engineering)
There are a few other architecture methodologies that are in use around the world, which are mentioned here for completeness. Probably the most common of these are Enterprise Architectures, the Open Group Architecture Framework (TOGAF) and Object Orientated/UML Architectures. All three approaches cover more than just the architecture and go into system implementation and maintenance.
An Enterprise Architecture is a well-defined practice that can be used by organisations to guide the development of their businesses. It considers the business to be an "enterprise" and is perhaps the successor to "business architectures" that use business process modelling techniques. The concept of an Enterprise Architecture is attributed to John Zachmann when he worked for IBM in the 1980's and was responsible for the "Zachmann Diagram". It has been developed and updated several times since by organisations such as the Enterprise Architecture Centre of Excellence (EACOE at http://www.eacoe.org). As far as is known, Enterprise Architectures have never been used for ITS implementations. The creation and use of ITS architectures does fit well with the Zachmann Diagram and is part "Business Model" and "System Model", with the preparation of the service descriptions being part of its "Scope" phase.
Another methodology that can be used for ITS implementation is TOGAF (The Open Group Architecture Framework – see http://www.togaf.org/). It is robust and used in many parts of the world, backed by a strong user community that offers professional certification for those that use it (TOGAF practitioners). TOGAF Architecture Development Methodology (ADM) divides architecture creation and use into several phases as shown in the figure below. The phases are similar to the steps shown in the figure on ITS architecture in the Systems Engineering "V" Model. (See Systems Engineering)
Some phases of TOGAF are not covered either by high-level ITS architectures or by low-level ITS component architectures. These additional phases can cover subsequent steps in the ITS implementation process, such as procurement, installation, and operation. Including these steps within the architecture has the advantage of delivering both the actual solution, as well as closing the loop and updating the ITS architecture.
More information about the use of TOGAF in the Australian National ITS Architecture project can be found at: http://www.austroads.com.au/road-operations/network-operations/national-its-architecture#
Object orientated methodology has been long established for software and system design and is almost always illustrated using the Unified Modelling Language (UML). So far as is known only two ITS architectures have adopted it: the ITS architecture developed by ISO TC204 in 1998 and the Australian ITS Architecture, which was developed a few years later. based on ISO.
The ISO ITS architecture has largely remained untouched since it was produced and may now be lacking in support for many of the ITS services used today. The Australian ITS Architecture was also little used. In the last few years, Australia has begun development of a new Australian National ITS Architecture. It is following the route taken by most High-Level ITS Architectures (See What is ITS Architectures?) that have been developed around the world and using the methodology described in this module.
It is probably true to say that the object orientated methodology is inappropriate for use by people outside of the IT industry since it requires practice to become familiar with it. This methodology is more appropriate for low level (or component level) ITS architectures that are used by system and software developers.
Many developing economies will have little or no experience of ITS. This means that there will be very few existing ITS deployments and where they do exist, they will often be standalone having no links with any other systems. Thus any new ITS implementation will be starting from what is virtually a "greenfield site". In this situation, creating and using ITS architectures is virtually a "must" since it provides the greatest opportunity for assessing all of the options for component and communications configurations. This should be done without the influences of suppliers and providers, who will inevitably be keen to sell their own products, but should take account of what standards are available, particularly for communications.
Creating and using ITS architectures will provide the opportunity to specify components and communications that will produce an ITS implementation that is "open" – one that uses open, or publicly available, standards to which anyone can conform. This will in turn widen the potential supplier and provider base, in other words make it easier for a broader range of companies to tender for the supply of components and the provision of communications. This will apply not only to the initial ITS implementation but also to future expansions and upgrades, thus avoiding the trap of being "locked into" a particular source of components and communications.
Print