For any class of network operational issues there may be a number of possible technological solutions, with the possibility of conflicts between various methods and solutions. Also, with the rapid evolution of ITS technology and services, new and better applications are always on the horizon. Fine-tuning to a state-of-the-art single application at the moment may sacrifice the ability for the system to evolve in the future.
These issues can be summarised as integration issues. In general, we can think of two types of integration. One would be considered as horizontal integration, where the same service on different road networks is integrated into a single interoperable regional, national, (or even international) system. An example is the emergency call centres operated by some motoring organisations. Another approach would be a vertical integration of different services, perhaps involving different service providers, that would be integrated and offered as a single system, for example electronic payment systems that are inter-operable between different public transport, toll-road and car park operators.
The need for integration is apparent when considering the several problems that may occur by pursuing mono-function systems.
Various systems may rely on similar sets of data: Traffic volume data, accident data, and weather data may all be used in various ways by various services. It would be impractical and probably impossible for every service to create their own traffic data from scratch. Usually, it would be much more efficient to separate the data collection and create a platform or protocol for shared use, allowing for sharing between various systems. (See Vehicles & Roadways)
In many cases, many of these data already have only a single (or a small number of) source. Even in such cases, it would be too troublesome for that data source to deal with all service providers individually. Data sharing that allows for integration allows for higher flexibility and variety of services.
Fragmentation of Services: It would be troublesome for users to deal with separate systems or services whenever they journey into a different area. While network operation is aimed to facilitate mobility, the fragmentation of services might even hinder such mobility. It is much more convenient to be able to use the same system and services seamlessly among various geographical areas and jurisdictions. A system designed with such horizontal integration in mind greatly improves the utility of a service.
Issues of Human Machine Interface (HMI): Many services that enhance network operation require user interaction within the vehicle, often while driving. Lack of consideration for other systems would lead to a random assortment of proprietary displays and input devices, especially within the vehicle. The risk of driver distraction is very real, and as the number of interfaces within the vehicle increases, the risk of mis-operation and confusion would rise exponentially. Integrating various services could also integrate these interfaces into a more usable and understandable system. (See Engagement with ITS)
Development Cost: Many services require similar components, such as communication channels to and from the vehicle, or a common geographical database, or payment systems. If all services were developed separately, these similar components would have to be developed, tested and deployed independently, which is wasteful and time consuming.
Interference between systems is another important issue. Integrated systems, if properly tested and fielded, would decrease such risk by assuring that the integrated services work properly together.
Promotion of Competition: Assortment of uncoordinated individual services leads to the fragmentation of the market. This leads to less competition, which forbids the vendors to enjoy scale merit, causing higher unit costs and lower user acceptance.(See Competition and Procurement)
In summary, integrated functionality for Road Network Operation systems can provide the breadth and depth demanded by road users. It is incumbent on the organization responsible for network operations to take care that the system and service is based on state-of-the-art principles and uses new ITS-based techniques that are slotted in as they become available.
One way to promote integration between various systems and services is to design a completely integrated system at the outset. This allows for shared components, avoids redundancy, ensures interoperability, and can provide a high level of service from the start. (See ITS Architecture)
On the other hand, this approach also has its dangers. First, if the comprehensive system overlooks a wider interoperability issue the same risks as any other isolated system can occur. A comprehensive system for one city may become a non-interoperable isolated system within a larger context.
In addition, larger systems are inherently more complex, which requires longer lead-time to design and implement. For example, the Japanese national Electronic Toll Charge required a significant amount of preparation for its introduction, in order to ensure that the system could work throughout the country.
Another issue is how easy it will be to upgrade. By integrating systems too tightly within a comprehensive system, a modular upgrade of services may become difficult. It could also make the system difficult to maintain. A clear modular approach is very important.
Integration of Existing Systems: This is possible when the existing systems have some common components, in terms of data formats or hardware requirements. For example, Italy has managed to expand its ETC system in this manner, integrating and expanding existing systems into one seamless system. (See Analysis Steps)
In order to make integration of systems work, there must be significant amount of common components among various systems. One way to ensure this is to standardise the interfaces, or rely heavily on existing standards so that there are fewer problems concerning interoperability. For example some ITS systems use the TCP/IP communication protocol. This would allow for the potential of various other TCP/IP applications to interact with the ITS system in the long run.
Communication standards are the most obvious area of standardisation. Other areas might include the standardisation of digital map formats, data formats of traffic information, and so on.
Obviously, there are various levels of standardisation. What you want to standardise will depend largely on what kind of services you would like to integrate, now and in the future. (See ITS Standards)
Existing Standards versus New Standards: Sometimes it may prove that the existing data formats or communication protocols are not sufficient. Creating a generic and standard protocol or data exchange format, however, is not a trivial task, especially for network operation applications that are often mission critical. By integrating various services into a single communication protocol, for example, the system would have a single point of failure. The protocol needs to be extremely robust, and the testing that is required ensuring robustness can become difficult as the complexity and the importance of that module increases. In some cases, it makes sense to sacrifice the level of the service in order to achieve integration using an existing and proven standard, rather than trying to create an optimal one.
Obviously, many of the issues concerning integration are not purely technical, but rather institutional. The negotiation between players, the division of labour between the private and the public sectors, the issue of acceptance, all become extremely important in an operator’s decision process.
Plan Ahead: Achieving integration as a second thought may prove to be extremely difficult. Once a system is in place replacing it may involve enormous financial and political resistance. If there is any possibility of integrating various services in the future, if at all possible it should be included within various considerations from the beginning. (See Strategic Planning)
In addition, various efforts to bring the players together and reach an agreement require a significant amount of time. Road network operators need to allow time for that negotiation process. (See Inter-Agency Working)
Short Term and Long Term Benefits: An integrated system means that it may be difficult to optimise for a single application or service in the short run. Common and standardised protocols may not be the optimal solution for that particular service. For example, if you only want an ETC system for a single stretch of toll road it may not make sense to consider a common national system, may require a more complex system. It should prove beneficial in the long run, but just how far into the future may differ from place to place, and in the short run it would be easier and cheaper to introduce an off-the-shelf ETC system.
The planning horizon for each road operator will differ. It should, however, be noted that the decision to integrate your system (or not to) would also be affected by that horizon.
A working definition of interoperability when applied to ITS systems is:
The ability of ITS-based systems to provide services (data, information, and control commands) to other systems and to accept services from those other systems so that the inter-connected systems operate effectively together. Systems are interoperable when the ITS services are seamlessly provided in real-time including between different organisations and/or at different locations.
ITS interoperability is particularly important for integrated Road Network Operations and has relevance for the road user and the road network operator.
For a service to be interoperable three levels of interoperability must be addressed:
Where is interoperability needed?
Interoperability becomes an issue if a system is composed of both fixed and mobile subsystems. For example, on-board units in vehicles that travel across borders must be able to communicate with roadside equipment at different geographic locations.
The priority areas for interoperability are:
Traffic Management and Control: Cross border traffic management requires the exchange of traffic information among network operators and harmonised procedures for network management, for example where do adjacent network operators want to concentrate traffic flow? (See Data Communications)
Traffic and Traveller Information: Data originating from many different sources (roadside traffic sensors, traffic police data, user calls, traffic management centres) that are disseminated to the users by means of different systems (roadside VMS, radio, internet, on-board navigation equipment) must be harmonised in order to avoid conflicting information to drivers. For example, there should be convenient means available to the drivers to acquire traffic and travel updates in order to ensure seamless provision of TTI services across borders and consistency of the data and information provided to users. (See Information Exchange)
Electronic Fee Collection (EFC): Common EFC payment for cross-border travel requires on-board units that are able to communicate with transponders or road-side beacons at toll stations or at enforcement sites and it requires agreements between the toll operators about clearing procedures and security issues. (See Back Office Arrangements and Enforcement)
Incident and Emergency Handling: In emergencies, travellers should be able to call services with their own equipment (cellular phone, on-board emergency system) no matter in which country they travel, and the emergency services should be able to find the relevant information about the vehicle, the persons and freight carried no matter what the origin of the vehicle. Automatic emergency call systems such as Europe's emerging e-call system are designed to notify incidents and accidents as they occur directly to a designated control facility. (See Driver Services)
Cross Border Enforcement: It is important to ensure that the enforcement of road traffic violations can be applied effectively and fairly to all road users, in the context of improving road traffic safety. (See Enforcement Systems and Policing / Enforcement) The increase of inter-regional and international traffic calls for cross border enforcement solutions that are interoperable and adhere to the following principle wherever possible:
“…all actions in the enforcement chain up to the enforcement of any penalty should be conducted by relevant agencies in the Region/ State where the violation is committed. Enforcement of any penalty should be carried out by the Region/ State where the vehicle is registered.”
Cross border enforcement solutions need to address:
The disadvantages associated with interoperability are:
The benefits of interoperability are:
A particular issue for all interoperable systems is what to do about non-equipped users, specifically those vehicles that should use a service but do not carry the proper interoperable equipment. In some regions (as in the EU) the road network operator is obliged to ensure non-discrimination of foreign users and solutions must be offered to ensure that a manual procedure is offered for the same function.
Interoperability and standardisation are very important to guarantee a nationwide or even cross border functionality in road network operations and effective use of ITS. There are three institutional layers involved:
Governmental and inter-governmental layer: This covers harmonisation of the road traffic regulations and in particular the technical requirements for vehicles and on-board equipment through the Vienna convention on road vehicles, OECD regulations and EU directives, including harmonisation of driver education with respect to Human Machine Interface (HMI).
Standardisation: The key to interoperability is standardisation. Only when interfaces are standardised can the different subsystems inter-work to carry out a particular function. Standards must include test procedures so that equipment can be certified by the operators for interoperable use. (See ITS Standards)
For network operators the following standardisation bodies are of particular importance:
Business to business agreements: the vehicle manufacturers and the electronics industry have been working together for a long time towards the development of interoperable systems. However, there are business cases where a strong commercial interest exists for excluding competitors from entering an established system.