Once the ITS implementation is complete, the system components and communications links have to be operated and maintained. This will enable the services to be delivered as required by the stakeholders and for maintenance work to be carried out to ensure that of the services delivery can continue. Operations and maintenance does not just happen – plans must be put in place so that what needs to be done is understood and the appropriate resources are available to do it. (See System Maintenance)
The short video about the work of the Swedish Transport Administration provides some useful points for justifying the use of ITS, from one of the leading European implementers. It is not so much the technical solutions that are highlighted as the philosophy and the inclusion of tasks such as maintenance, which is highlighted for good reason.
Because ITS implementations are diverse it is not possible to describe one solution that will fit all of them but there are common issues that need to be considered so that solutions can be found for the individual circumstances. Establishing the areas of operational responsibility is best done by considering them under the three headings of managerial, geographic and technical.
Determining how much management will be needed to deliver the services that the ITS implementation is providing is best done by considering some of the following issues:
The need to consider some or all of these issues depends on the scope of the services being provided, but the above are examples of some of the more common issues that are likely to arise.
The assignment of responsibility within the management organisation depends on its structure, which will vary from one ITS implementation to another but must be agreed before ITS is implemented to avoid and potential embarrassing situations later. Sometimes the organisation will have been created specifically for the ITS implementation, but on other occasions responsibility for ITS will have been acquired in addition to its existing portfolio of responsibilities.
Some ITS implementations will be large enough to cover several geographic areas, such as the states or provinces within a nation, regions within a state, or districts of a city. The issue is whether management of the services will be centralised at national, state or city level, or distributed to smaller geographical units, within the state, region or city district.
If responsibility for service management is distributed then the relationships between these organisations will be important and must take account of local differences that may impact on ITS operations, such as:
How issues like the above are accommodated depends on the scope and content of the ITS services and the organisational structures both within each geographic area and at the higher (national, state or city) level. It is important to enable them to be discussed and procedures/actions agreed by all those who will be involved before the ITS implementation has been completed.
The allocation of technical responsibilities will be slightly different for system components and communications. If everything works correctly, then it does not matter too much. Only when a component or a communications link fails or performs in an unexpected way does it become important. Inevitably, this will occur at some point in the life cycle of any ITS implementation and it is important to consider in advance its likely impact.
The question of who has technical responsibility for any mal-performance of ITS lies in deciding where the "design responsibility” rests. This can be done by looking to see where the methodology and/or technology to be used in a component or communications link is defined and allocating the responsibility to whoever created that definition. The most common examples are:
It is best to ensure the "design responsibility" rests with the organisation that is most appropriate to carry it – the one that is most likely to have the capability to resolve any issues as and when they arise.
For system components design responsibility should be placed with the suppliers. For example, if the control centre terminals have to give users access to the ITS applications and also enable them to do office tasks (for example, word processing and answering e-mails), the component specification should state these requirements and say this must be included in the design of the terminals. The specification should not define the operating system, processor, memory and other features as this is in effect defining the design of the terminal and shifts responsibility for any problems to those that wrote the specification.
A similar approach is needed for the communications requirements. They should not say that a packet switched network operating at a particular speed must be used. Instead they should define parameters such as how much data is to be transmitted, how often, with what reliability, expected transmission duration, which parts of the links are on mobile devices, the level of security that is required and the resilience needed to combat unauthorised access. Such a specification will also be much easier to test, since these are verifiable parameters.
In addition to the scope and content of the services provided by the ITS implementation, the need for relationships with other organisations will depend on the environment in which the services will operate. The environment will be defined by the geographic coverage and by the number of organisations involved. (See Integrated Strategies)
Some ITS implementations will provide services in several geographic areas. If the services in each area are to be operated and managed by different organisations, then unless the areas are completely separate, meaning that the road traffic conditions in one area have no effect on those in other areas, relationships – such as operating agreements – will need to be established between them. The scope of these relationships will be based on such factors as whether the need to co-operate is a regular occurrence or only under particular circumstances. (See Planning and Reporting)
It is also possible that some of the services that are provided in the same geographic area will be operated and managed by different organisations. For example, services related to Public Transport and tolling will often be provided by their own organisations. In these instances, the way in which their operations can inter-act with each other and with other service providers needs to be defined and act as the basis for the relationships. It may be necessary to develop detailed operating agreements between the different organisations. So for example, how should the road network operator respond to requests for vehicle priority from the Public Transport organisation? Another classic example of the need for relationships between organisations is where the road network uses a lifting bridge to cross a waterway that is managed by a port authority – how is the need for the bridge to open for vessels and closed to vehicles to be managed?
Finally the issue of the participation of the Police and/or other law enforcement agencies in road network operations will need to be addressed. In some countries the two are distinct, whilst in others it is the Police Force (or sometimes a dedicated part of it) that operates and manages the road network. If the road network operation and the Police Force are separate organisations then the relationship needs to define what the co-operation will be and how it will be implemented. For example can the road network operator report traffic offences, or to what extent can some of the data from the traffic control centre (for example, CCTV images) be used as the basis for the successful prosecution of offenders? (See Policing / Enforcement)
In countries with very little experience of implementing ITS, it could be difficult to set up the "environment" to operate and deliver the services. The "environment" will be defined by the organisations involved and how the responsibilities are allocated between them. To some extent this depends on the structure of the existing organisations and the relationships they have with each other. It may be necessary to create one or more new organisations, structures and relationships for the ITS implementation. The important point is to create an organisational structure that avoids un-necessary conflicts between organisations, whilst ensuring proper management of their activities.
For example, in some geographic areas, it is the Police that provide whatever road traffic management is currently in place. The issue to be resolved is, should they continue to do this in the ITS implementation, and if not, when and how should they interact with the organisation that will be responsible for the traffic management service(s)? There is no one universally applicable mechanism that will resolve this issue, but whatever is put in place must be recorded so that once agreed, there is no further dispute about the role of each organisation and who is responsible for what, when and where.
The probable route to achieving what has been described above, is to buy-in external expertise either directly or through consultants. If this route is followed it will be advantageous to visit ITS implementations that have used the proposed source of expertise and/or consultants and to discuss how the organisational relationships work. It is also worth remembering that sometimes what works for one country or culture will not work for another.