Michael Baranek Chief Innovation Manager, DB Systel GmbH
Felix Schwarz Telematics Engineer, Fela Management AG
Olivier Magne Head of Telematics, Saphymo
September 24 was a significant milestone in the evolution of data handling and communications systems on the European rail network, when Railion Deutschland and T-Systems Enterprise Services announced in Berlin that they had agreed to adopt a new open-standards messaging protocol for all future telematics applications.
OptiSMS is the first concrete result of an international research programme aimed at defining a generic standard protocol to support data exchange between telematics servers and remote equipment. It will enable train operators and infrastructure managers to source their IT systems from different suppliers, and permit the suppliers to invest in developing further products based around a high degree of compatibility.
The Open Telematics Interface project was launched in 2007 by the ICT Innovation Centre at DB Systel GmbH, working with Fela Management AG of Switzerland and Saphymo of France which provides IT services to Fret SNCF.
A major driver behind the project is the liberalisation of the European rail freight market, which is forcing operators to take an international perspective. The technical challenges to interoperability are well known: different traction power supplies, gauges, signalling systems and national regulations. The situation in the IT sector is less widely reported, but here too a lack of compatibility between national systems makes the tracking of cross-border movements very difficult or impossible.
Given a moderate level of investment, modern telematics systems should be able to support a significant improvement in quality, and supplying data on location, loading and safety status for all vehicles. It should be possible for any operator to track an individual wagon throughout its journey across Europe, closing the ‘logistics gap’ and avoiding the problem of unsupervised movements which currently give road hauliers an advantage. But with multiple players involved in most movements, it is vital to have an open exchange of data.
To date, we believe that telematics have only fulfilled a small part of their potential — probably a result of poor performance with the early systems. But many telematics applications in the rail freight sector are now stable, and offer a high level of reliability. Increased acceptance will see the wider introduction of IT into operational processes, which in turn will lead to further evolution, both in terms of the equipment on the vehicles and the integration of data systems between operators.
One critical issue is that most telematic systems today rely on proprietary or company-specific protocols. These are primarily oriented towards optimising the use of carrier technology such as GSM-SMS as well as easy handling of specific message types. Using a bit-oriented communication of user data, the message types are tightly linked to the functional applications within each individual system.
For the potential user, considerable effort is needed to adapt these proprietary protocols to their specific functional requirements and map them onto the business logic, which means time must be invested in co-ordination and/or re-engineering. If a user wants to integrate systems from multiple suppliers, he may have to negotiate special agreements for exchanging protocols, and then plan for intensive functional and integration testing. But this is not unusual — it is quite a common requirement.
Identify the interfaces
The OPTI project team believes that the next generation of telematics systems not only needs to meet operational requirements on reliability and running times, but should also to be developed as ‘open systems’ with standardised interfaces. The first step was to focus on a standard ‘air interface protocol’ together with the establishment of minimal standards for systems compatibility.
If European market leaders in the rail freight sector can agree common telematics standards, it should open the way to much wider deployment. At the same time, competition between suppliers will push the technical development and bring new business-specific applications. From the user perspective, having multiple vendors is important, both to ensure attractive prices and guarantee support over the life of the investment.
In practice, the interface issue comes down to two questions: which interfaces should be considered, and what are the requirements for standardisation?
In the simplest terms, there are two main categories of interface for data exchange in telematics systems (Fig 1). One is between the mobile equipment and the central communications and database server, and the second between the server and the end user — which is where the available information is processed to generate business value.
In terms of the actual transport connections, the industry will only adopt telecommunication networks that meet worldwide standards. The first interface could be a terrestrial standard like GSM or a satellite-based system like Orbcomm. For the second layer, standards like ISDN, X25 or X75 could be used, and no further standardisation is needed at this level.
The remaining question focuses on the protocols for the data to be transmitted. By standardising, or making available publicly the format of data contents, it becomes possible to embed the system into existing IT environments or connect them to third-party systems.
Software tools already available in the market, such as vehicle location, freight management and billing systems, rely on such protocols, so again and again the suppliers are being asked to open their proprietary protocols for their customers. As the publication of proprietary protocols is not efficient and does not promise to be future-proof, the project partners began to develop a standard interface specification.
Set the requirements
The project team decided to disregard existing proprietary protocols and pursue a completely new approach, which we believe will be future-proof. Besides optimising the data transmission to reduce communications costs, a logical separation of the protocol from the data transport layer is essential. Another requirement was to make the standardised interface free of license fees, so that it could be used by anyone.
Reviewing the market identified a clear trend. While projects implemented so far have relied on GSM-SMS for data transport, future development is moving towards package-oriented data transfer using GSM-GPRS.
This encouraged us to focus initially on terrestrial communications networks. However, the defined ‘communication stack layering’ (Fig 2) has been designed in such a way that future developments in communications technology which honour the OSI layer model can be used. This explicitly includes satellite-based data transfer systems.
A range of different communication scenarios and strategies was considered to formulate the likely requirements for the transport layer. This produced a series of fundamental requirements, grouped into two categories:
Basic: the communication between the mobile units and the central server must be energy-efficient and effective with respect to data volume.
Functional: the point-to-multipoint mobile unit has to be able to communicate with different server partners, and in return the mobile unit must be reachable through different servers. The unit has to transmit information and data promptly, and for ‘always-on’ systems: any mobile unit must be contactable promptly on demand.
Central to the definition of the generic protocol is the use of elements, which have a unique ID and one or more attributes. These range from ‘basic’, ‘complex’ and ‘fixed’ elements up to ‘dynamic complex’ and ‘user-defined’ elements. It was also necessary to define rules for element manipulation, request functions and communication control elements.
The development of the Standard Message Structure (optiSMS) is only the first step in the process, but it is nevertheless a major step towards the evolution of open standards for railway telematics. With the first operator and supplier now signed up to use the standards, we hope that other potential users will also adopt the new industry standard.
