DISRUPTION cannot always be avoided, and the annoyance caused by unexpected delays can be mitigated by the early provision of accurate real-time information, enabling passengers to re-plan their journeys and seek alternative connections.
Information on disruption comes from a number of sources within an operator’s planning and dispatch functions. In addition to common causes of disruption such as staff sickness, rolling stock shortages or high passenger volumes, operational decisions made by the infrastructure manager can also affect journeys and onward connections.
Initial reports of disruption typically originate from various IT systems, not all of which are operated by the rail operator itself. These include staff rostering systems, maintenance software, onboard systems on rolling stock, and control centres operated by the infrastructure manager or other train operators. And even though most relevant information is usually available on an IT system somewhere, it is often communicated manually such as by telephone.
Given these constraints and a dispersed IT infrastructure, it is very hard to ensure that all the necessary information is available to provide comprehensive passenger information in real time, including when incidents causing disruption are likely to be resolved. To enable this, all data must automatically be kept consistent in multiple individual systems. In this way, different timetable requirements can be met from a common basis.
The complex process of planning, delivering and controlling a train service gives rise to many different types of timetable, all of which depend on each other while meeting different purposes.
In regional rail operation in Germany, for example, the specified timetable is part of the contract between the public transport authority and the transport operator, with the authority setting out the services provided by the operator. As part of contract supervision, the actual provision of rail services is compared with the specified timetable. For services that are not specified by a transport authority, the operator’s own service planning department takes on this role.
While full auotomation of planning and dispatch is not feasible in the foreseeable future, more and more routine tasks can be supported by software.
Based on the specified timetable, the transport company creates an operational or working timetable, the main outcome of the operational planning process. As well as the specified train services, this timetable includes other train movements, such as empty workings to and from the workshops for maintenance. The operational timetable is the basis for more detailed planning, including vehicle working diagrams and crew duty rosters. The timetable also specifies the required train path, an important resource which must be requested, developed and allocated by the infrastructure manager. Allocated train paths become another form of timetable which must be taken into consideration.
These timetables are not suitable for passengers, who need concise information on train arrivals and departures at stations only. Passenger information is based on a public timetable that excludes purely operational stops (such as for crew changes), includes recovery time for late running, and is typically rounded to full minutes. It is also used for ticket sales and reservations. The public timetable is made available via the internet and mobile devices and is displayed in paper format, especially at stations.
Only after the train service is operated is the realised timetable known. It is a log of the actual times of events during a journey, such as arrivals and departures, recorded during operations. A comparison of the realised timetable with the planned timetable enables service quality to be measured, such as train punctuality. The contracting authority usually undertakes this task as part of contract supervision, but it also enables further analysis to improve service quality. Passengers can make use of the realised timetable to enforce their rights, such as compensation for late arrival. For passenger information purposes, the realised timetable can be used in real time to calculate the likely delay to a late service on the remainder of its journey.
So instead of a single timetable, there are a variety of schedules performing different but interdependent roles for the various stakeholders in the railway sector. At their centre is the operational timetable, which must serve the requirements of these parties as well as possible.
These individual requirements are met in a well-defined process and build on each other. Starting with the requirements defined by the contracting authority, operational planning takes place and train paths are ordered, before passenger information is provided and, finally, the plan is realised. The continuous flow of timetable data is a purely technical problem and can be easily solved with modern IT systems.
The process becomes challenging when requests are made to change the initially planned schedule, either from inside or outside the operator. Every day, railway companies have to deal with a multitude of events that require modifications to the timetable. Today, such changes are typically implemented by different people, depending on the time remaining until the event that has triggered the change. Especially for short-term changes to train dispatch, manual methods without software support are still the norm.
Different events require changes to different timetables. Infrastructure work with a lead time of only a few weeks or dispatch optimisation by the infrastructure operator will typically have a direct impact on train paths. The ordered timetable might change when additional services are ordered for special events, and a shortage of rolling stock or personnel requires the operational timetable to be modified. Most of these changes have a direct impact on the public timetable. Lastly, delays to preceding services or the time taken for passengers to change trains can cause delays.
Although the process to update timetables follows well-established steps from original planning onwards, each individual step is now more challenging, as the timetables are interconnected. Let us consider the modification of a single trip. Not only does this directly affect the current duties of the onboard personnel, but it can also have an impact on their later duties, for example if rest breaks cannot be taken. If the affected trip is part of a chain of connections, the alterations to these connections must be communicated via the public timetable. At the same time, train paths must be modified for all affected trips, which might lead to another iteration of changes. Unlike initial planning, all of this must be executed under time pressure.
Consistent data is crucial
To accomplish this task, it is crucial that all relevant information is readily available and up to date at every contributing workstation. As systems become more complex, and passengers become more demanding, relying on interpersonal communication is no longer feasible. Transport operators need consistent data flows that harmonise diverse information sources for separate applications. This integration should encompass applications from all areas that may impact operational procedures, including planning, train paths, personnel, vehicle dispatch and sales systems.
The availability of consistent data is essential for timely reaction to incidents by personnel, and provision should be made for automating this process. While full automation of planning and dispatch is not feasible in the foreseeable future, more and more routine tasks can be supported by software. At present, managing connections between train services is increasingly assisted and automated by software, providing for a substantial improvement in passenger satisfaction.
In addition to these trackside systems, onboard software installed on rolling stock should be integrated. As the system closest to the point of service delivery within a railway company, onboard systems are crucial to monitoring the status of operations in real time. To mitigate errors and delays, vehicle data must be collected and distributed automatically.
Simultaneously, drivers and onboard software need access to the most recent version of the operational timetable and train paths without delay. For passenger information purposes, displaying conflicting information on mobile devices and on-train displays leads to confusion and, eventually, frustration.
In control centres, the separation of dispatch from the provision of passenger information is still widespread. The operational timetable and the public timetable are synchronised by communication between members of staff. As well as producing inevitable delays in providing passenger information, this potentially leads to a growing divergence between the timetables.
If passenger information managers must as a priority support dispatch, as is common during major incidents or when there is a staff shortage, real-time passenger information might even be non-existent, severely impacting passenger satisfaction. Fully automatic data synchronisation, if done correctly, can mitigate these effects almost completely. This does not mean that providing passenger information should be done without a human presence. Individual announcements and additional display texts are vital, and human intervention must be possible and easy in every situation. In addition, full data synchronisation must not result in the publication of incomplete and inconsistent information that inevitably occurs during complex operating situations.
Synchronised data is also essential to facilitate collaboration between the various human participants in operational incidents. A cross-role incident management system helps to keep everyone on the same page, including personnel in the field or in other control centres. If it offers a common entry point to various systems, it allows for a fully cross-functional approach. Knowing that each action is automatically logged and circulated to all relevant parties allows for concentration on the most important tasks.
The quality of a control centre as well as of passenger information is determined by performance during major incidents where the workload is considerable. Although every person dealing with such an incident should be aware of the existence and importance of the different timetables and their versions, no one should be concerned with actively maintaining them during a major incident. One of the main purposes of modern IT systems is to relieve staff of these tasks, provide a common view through integration and close collaboration, and thus ease operations.
*Dr Christian Blome is chief product manager, Dr Bastian Kargoll, product manager, rail, and Dr Jonas Wernz, division manager, public transport operations development, at IVU Traffic Technologies.
