What platform will it need?


Themes: Architecture; Communications

What is the "Platform" and why is it important?

 This section deals with one of the most underestimated aspects of ITS systems. Correct interfacing of systems can only occur if it has been properly planned for. It is all-too-often ignored or given minimal attention until procurement or even operation is well advanced, and the problems start to emerge during installation. By this stage, it would be very costly and/or time-consuming to resolve, or is considered so much trouble that the consequences are left to someone else to solve later and the problems are lived with.

The main “platform” elements for ITS are:  

  • The System Architecture, which provides a ‘blueprint’ of all the ITS systems and how they relate to each other
  • The Communications Architecture, which defines both how the systems and devices talk to each other, and the content of the information to be exchanged
  • The Data Model, which provides a consistent definition all data to be used in the transport entity
  • Interfaces, which define the physical connectivity between devices and the protocols used for information exchange
  • Standards, which ensure that both Vendors and Clients develop hardware and software in a common way, usually based on international industry consensus

The need for planned connectivity across systems and devices

An ITS System consists of much interconnected devices, software and information. The following are simplified examples of problems that regularly occur in real-life, and which are absolutely avoidable with just a little forward planning. These examples are included here to help the reader appreciate that these are not academic issues, but that they have real, immediate and avoidable cost and nuisance consequences.

1) Example 1: Different systems will be procured and installed in each bus that should communicate with each other via a central unit (e.g. the AVL system). The Client has not developed a comprehensive in-vehicle system architecture. The system is procured and contracts signed. The suppliers arrive at different times to install their equipment, and each has presumed to install in his own way. Each supplier requires every bus in the fleet to be made available for installation, and proceeds to install wiring and make connections, independent of the other. The buses are off the road on multiple occasions, multiple cuttings are made in the interior and mouldings, each supplier installs his own set of wiring, and cuts into the wiring of others where it is inconvenient to him. When the suppliers are finished, there are ongoing interference and non-functioning problems, there is no comprehensive diagram of all the wiring, and the Operator’s technicians must trace all wiring individually each time there is a fault.

This would have been avoided by developing a comprehensive wiring and communication diagram at the outset, requiring all suppliers to conform to them, and installing the wiring in a single go with ports/connections available for the individual suppliers when they install their equipment.

2) Example 2: It is decided to install in-vehicle information units to display and announce the next stop. The information units need to receive location data, and could receive it from either the AVL or the fare collection equipment. However, each device has only two output ports which are already utilised, the software in both the AVL and fare collection would require major rewriting in order to interface with a different device, and the information unit has a different communication protocol to the other two devices. As a result, the only solution left is to install another location device specifically for the information/display unit, at considerable expense.

This would have been easily avoided by foresight of what future devices might be installed (i.e. the system architecture), requiring that the supplier of the original equipment make provision for future devices and use standard protocols, and making it a condition of the procurement of the information/display units that they are compatible with the original equipment.

3) Example 3: Three devices in the vehicle (e.g. driver's console, in-vehicle location display, smart card reader) generate or use the data about the location of the vehicle and the route, and should share this information. The suppliers have each provided their own proprietary systems, using their concepts and software that they developed for other locations. When the Client tries to integrate the systems, it finds that they cannot share the location and route data because each has defined it differently, uses somewhat different naming/coding conventions and formats, and requiring different degrees of accuracy. The suppliers refuse to change their software since it would require fundamental restructuring, and as a result the three devices cannot share data in the manner intended.

This would have been avoided by developing a common data model, in which all of the data elements used by the bus company are listed and defined, and requiring the suppliers to conform to the Operator’s data model.

Platform elements for ITS

The main platform elements are briefly defined as:

1) The System Architecture maps out all of the foreseen elements of the ITS system, and how they relate to each other. It can be viewed as a ‘blueprint’ or a ‘road map’ of how ITS will be implemented at that entity or cluster of entities. It may be presented at multiple layers – functional, logical, physical, data, communication – all of which are consistent with each other. They allow the various systems and sub-systems to be designed and implemented within a consistent framework, and to interact with each other in a planned way. To the greatest extent possible, the System Architecture should provide for potential future additions to the ITS implemented in the initial phases.

2) The Communications Architecture identifies the means of transfer, the content and formats of information to be transmitted between different systems, devices, and functions.

3) The Data Model identifies all of the data elements associated with the ITS and IT applications in the entity. It defines them in a consistent way across all applications, including the structure of the data element, range/values, coding, attributes, association with other data elements, etc. This provides a standard reference for all developers so that every device, software, application and interface defines the data element in the same way. If devised and implemented correctly, it greatly facilitate data exchange and integration. There are existing data models for the public transport sector (e.g. TRANSMODEL) which can be utilised or adapted.

4) Interfaces are the points of contact and data exchange between devices and applications. In ITS, interfaces normally consist of physical, protocol and data exchange layers, which must be harmonised with each other. At the physical layer, the plugs, sockets or other connectors of one device must fit the other; or if using wireless communication, they must be able to operate on the same frequency. At the protocol layer, when one device is connected to another, there must be a means for one to recognise the other, initiate/allow them to communicate with each other, and handle the flow of information. At the data exchange layer, there must be sufficient common software and data formats so that the two devices can dialogue, follow approved command sequences, exchange the information and handle errors in a common way.

It is essential to use standardised interfaces for these main reasons:

  • Any device can communicate with any other device, as long as the interfaces and protocols are respected
  • It avoids being locked in to a single supplier
  • Devices/applications do not need to have physical and soft interfaces to cope with all eventualities
  • Most interfaces in the ITS domain are well established and backed by standard protocols or norms. These are proven, which minimises the technical and performance risks.
  • Most reputable suppliers already work to such standards or norms. It is much cheaper for them to use what exists than to develop new interfaces and software for each client.
  • For the Client, it is not necessary to write a complete new specification, only to reference the standard or norm

5) Standards. The ITS and communications sectors are now well supported by Standards. These standards reflect consensus within the industry sector (suppliers and users) on how a thing should be done and define it in a consistent logical and technical way.

Standards can be set at national or international level. International standards supersede national standards, and have the major advantage of being adopted by suppliers from a wide range of countries. The global international standard body is ISO, the European standard body is CEN. In the ITS domain, ISO and CEN work closely together and have reached a very high degree of alignment. Many of the relevant standards for ITS for public transport are dealt with in CEN TC (Technical Committee) 278 Working Group 3, although standards for multi-sector devices and services (e.g. telecommunications, GSM, smart cards, GIS/mapping) are dealt with by other standards bodies or TCs.

Accessing information

There are many excellent guidance and support materials available, including standards and interfaces. This is one area where most of what is needed is available free, and often with ‘self-serve’ tutorials, so the Client can at least have enough knowledge to open intelligent dialogue with the Suppliers. Further, most reputable suppliers are likely to prefer to use standards (for which they have already done the development work) than to develop tricky, time-consuming customised approaches for individual Clients.

You are here Guidance Design What platform will it need?