Digitalization in Rail Companies Needs Standards – Urgently!

Process digitalization on the one hand, manual data transfer to flanking systems on the other: Rail companies have now digitalized countless business processes. However, what is missing is becoming increasingly clear – the modeling of these individual building blocks into a powerful overall system. This in turn requires standards.

Many rail companies have an extensive list of digitalized processes at this point, for example

• Enterprise Resource Planning (ERP),
• personnel and duty scheduling,
• vehicle scheduling,
• timetabling,
• operational scheduling,
• customer information, and much more.

This has resulted in IT landscapes featuring numerous autonomous individual solutions with just as many media disruptions. These generate considerable frictional losses, for example when data is manually transferred to different systems several times in some cases, or previously independent inventory systems are manually synchronized at different times.

At the same time, the pressure is high: For instance, customer information relies on planning data that is always up to date – including, in this case, from a vehicle scheduling planning system operated during office hours only. The resulting rework costs time, places additional strain on staff who are already under significant pressure, and is highly prone to errors.

In this context, the amount of time and effort that companies have to spend on IT issues is increasing all the time. Those responsible complain that it is becoming increasingly difficult to concentrate on the actual core business of transporting passengers and goods. Thus, finding a way out is even more urgent. This way out lies in the creation of an overall IT system – with continuous processes through automated transitions.

Existing Standards Underdeveloped

As simple as this equation sounds in theory, its implementation is problematic in practice. This is because the digital solution modules can only be efficiently combined to form a large whole via standardized import and export interfaces. But this is precisely what most systems fail to offer. Existing standards, in turn, are not fully developed and cannot represent all operational requirements.

If these are not further developed, the danger of “self-sufficiency“ increases, leading to proprietary adaptation in the worst case.

One prominent example for which standards are lacking is the transmission of infrastructure data – which almost all IT systems in rail companies require – from the project planning of interlocking systems through maintenance and timetable planning. And even the systems that are important for operations, such as vehicle scheduling, control systems and passenger information, need infrastructure data; albeit in less detail.

Overall Context Missing

The fallout when individual systems lack an overall context is illustrated by the example of the timetable. The timetable is populated several times by different systems until it is used for scheduling purposes on the day of operation, making it increasingly complex. For example, rolling stock and personnel as well as information for passengers on the platform, on the train, and for various pieces of online information are assigned to planned journeys. Various target systems are responsible for this. This in turn means that content and special symbols, as well as languages for announcements and special texts, have to be prepared as appropriate in each case.

In addition, very different interfaces often need to be operated. This is because the vehicle fleets of rail transport companies are usually equipped with on-board information systems from various manufacturers. Maintaining these communication interfaces is time-consuming and costly.

In such an iterative data enhancement process, basic data modeling that is coordinated in detail between the system suppliers is even more important. Indeed, interoperability and thus the overall success of the project depend on it. This necessity becomes clear at the latest in more complex operating cases, such as multiple wing train operation.

Every interface in the rail system makes communication more complex.

Fit for the Future With Standards

The fact is that neither a uniform data model nor a standardized exchange format exists between all these systems.

Even existing standard interfaces such as railML (Railway Markup Language) or VDV allow too much leeway in modeling, which ultimately hinders fully automatic data exchange, even if it offers a high level of conformity. It is safe to say that a plug-and-play functionality is not achievable due to the complex system architecture in transport companies. However, the importance of standards that are applied comprehensively is increasing even more.

This is because they ensure a cross-system data flow, minimize necessary individual adaptations (e.g. custom tags for railML), while also ensuring the necessary modularity to be able to flexibly exchange or renew system components in the future.

Therefore, the advice from the experts is clear: Companies should actively promote the (further) development of standards in committees such as railML.

They are also well advised to rely on standards wherever possible and to define their use jointly with all system suppliers. Using the PSItraffic scheduling and customer information system, for example, the enhanced timetable data can be imported and processed on the operating day for operational scheduling.

Finally, to create an overall system, it is important that the networking of IT systems goes hand in hand with the adaptation of the company’s operational processes.

Digital and Networked

The digitalization of processes must urgently be followed by networking to form an overall system.

This is the only way to fully exploit the benefits of digitalization in the long term. For this to succeed, transport companies need to rely on data modeling and exchange standards, actively promote their further development in existing committees, and break away from the separation between planning and operational scheduling on the IT side.