Road Network Operations
& Intelligent Transport Systems
A guide for practitioners!

You are here

Systems Integration

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.

Methods for Systems Integration

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.

System Architecture

Standardisation is a considerable step in order to achieve integration of various systems. However, as the complexity of the entire spectrum of services offered increases it becomes considerably more difficult to determine just where to standardise and to what level. In order to make this transparent throughout the system and to aid the network operator in figuring out what components are vital, a system architecture approach is important. This clarifies the relation between various actors and how they interact through whatever channels in order to provide the required services. This helps the road network operator to see the relation between various services, giving them a better approach to their integration efforts. (See ITS Architecture)

Implementation Strategies

Integrating various systems is an effective approach to network operations. There are, however, issues that need to be addressed.

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.


Reference sources

No reference sources found.

Other pages