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.
The staffing level is the number of people required to operate and manage the ITS implementation so that the services are delivered. It needs to be calculated in two ways:
How these two totals are calculated will depend on a combination of the following nine factors:
Not all of these factors will be relevant to every ITS implementation – but those that are will determine the maximum staff requirements needed.
The scope and content of the services provided by the ITS implementation will determine the skills that staff will require to possess in order to operate and manage it. Also the level of responsibility to be assigned to each member of staff will be another factor that determines the level of skill. The ideal member of staff will need to possess the following skills:
If the organisation that operates and manages the ITS implementation decides to carry out its own maintenance activities, then a new set of skills will be needed. These will be more technical and may cover such things as component replacement, component repair and software maintenance. Candidates for these staff positions will either need to have had specialist training, or to be provided with it when they start work. Such training will almost always be available from hardware and software component suppliers, but in the case of software may also be available from other organisations.
The maintenance of the communications networks is often best provided by the communications network provider(s). On occasions access will be needed to their premises and/or equipment, some of which may be used by other network customers. It is often useful to have staff capable of diagnosing communications problems, so that the network provider can be contacted and given some vital information about the possible nature of the problem.
Getting people with the skills in ITS as described above may be difficult. There may be several options to resolve this issue, but two of the most obvious are:
Of the two, the first is the short-term solution and may be initially cheaper. In the longer term, training local people is the answer, even if it is more expensive initially. There are many organisations that offer suitable training, and sometimes it can be included in the contracts for suppliers and/or system integrators. Many of them will provide the training either at their own premises, or in the location where ITS is being implemented. The acquisition of experience in communications is probably best as an issue for the communications providers to resolve.
The organisations that operate and manage ITS systems and services can each decide to do some or all of their own maintenance or sub-contract it to other organisations. The increasing complexity of ITS implementations and the services that they provide tends to promote the idea of using sub-contractors.
Advances in the technologies found in the system components and communications networks used by ITS implementations have reduced their need for regular maintenance. The days of frequent periodic maintenance activities for hardware and equipment are fast going and are being replaced by a philosophy summed up by the expression, "if it isn't broken, don't fix it".
Modern day roadside equipment will normally only need occasional replacement of light sources and sensors. Even this is declining with light sources now operating at low voltages. In other respects the trend is for maintenance activities to only be needed following the effects of extreme weather conditions, such as extremes of temperature flooding and high winds. There are some exceptions to this trend, such as mechanical barriers at car parks or bridges, and equipment in tunnels that will need extra safety checks that will need to be carried out on a regular basis.
Control centre and communications equipment is following the trend towards little or no maintenance activities. When anything does go wrong the tendency is to replace rather than repair.
The one exception to the "if it isn't broken, don't fix it" mantra is software which is often updated periodically, either because problems have been found or to include improvements. This is particularly important for any components that will be connected to the Internet, as they must be protected by sophisticated firewalls and software to prevent unauthorised access. Whenever software changes are made Configuration Management (CM) needs to be employed to ensure that the changes are managed and that it is possible to revert to the unchanged version if problems arise.
Except for the large organisations that often manage ITS implementations in cities and across states, provinces or nations, it is usual to employ sub-contractors to carry out maintenance activities. These sub-contractors may be specialist maintenance organisations, or the component suppliers, particularly for roadside components.
Whatever form of sub-contractor is used, the scope and content of their activities must be defined in a contract, sometimes called a Service Level Agreement (SLA). The SLA must define such things as what is to be maintained, the hours and days during which the sub-contractor must attend to a reported fault, the response time for a reported fault, how long a repair can take, at what point must a replacement component be fitted, spare stock holdings, plus the competence and availability of the sub-contractor's staff. A cost structure must also be included, to either fix a price for each activity, or fix an overall price for all maintenance activities. SLA's usually only operate for a fixed period of time (2-5 years) and will need to be renewed when the time has expired, often through a tender submission process.
The possible exceptions to the use of sub-contractors for maintenance activities are large cities, or other geographic areas for which the scale of the ITS implementation is large, particularly in terms of the amount of hardware used. In these instances the amount of maintenance work required will make the recruitment and training of specialist hardware maintenance staff, providing a stock of spares and a repair facility, a benefit to the organisation operating and managing the ITS implementation. Sometimes the organisations in adjacent areas can combine their maintenance activities to benefit from not using sub-contractors.
Software maintenance is usually different because even in a large ITS implementation there is not the same quantity as there is for hardware, and understanding, modifying and replacing it is more complex. For example, the software for a typical urban traffic control system may have between 250,000 and 500,000 lines of code, which will take a software engineer several months to fully comprehend before any changes can be made. Therefore it is better to get the software supplier(s) to maintain what they have supplied.
It is likely that in most countries it will be maintenance of hardware and communications links that will need to be provided, as software maintenance is almost always best to its suppliers.
One way for a developing country to proceed is for ITS maintenance to be done by the component suppliers and communications providers. Quite often a period of maintenance can be included as part of their supply contracts. All the provisos about such things as Service Level Agreement (SLA's) mentioned previously need to be included. Items such as maintenance equipment and spare parts should be stored locally. How the spare parts are provided is something that has to be negotiated as part of the maintenance contract(s). If the service providers take responsibility for ensuring that sufficient spare parts are available it can sometimes be a question of balancing a possible reduction in the cost of maintenance against the greater freedom to change contractors at the end of the maintenance period.
Other factors to be born in mind when negotiating maintenance contracts include what local presence the maintenance contractor(s) will have, and to what extent the contractor(s) will employ local people. The latter can be very important. For the long-term future of the ITS implementation it will be advantageous if the local employees acquire the training to give them the technical skills needed to carry out the maintenance activities.