Viriato MoD - Partial Coverage: Solving challenges using microscopy in medium-term timetabling

Introduction

In both medium-term and long-term timetabling1, it is generally the case that not all microscopic infrastructure data is available. The reasons for this are as follows:

• Long-term timetabling is characterised by the condition that the underlying infrastructure has not yet been fully determined. In this case it is the very purpose of a timetable to formulate the requirements for the future infrastructure in a top-down approach, without the need to include all microscopic details: “First the timetable, then the infrastructure”.
• Although medium-term timetabling differs from long-term timetabling in that the infrastructure is generally given, i.e. no additional updates to the infrastructure are to be expected because of the timetable development process, nevertheless the timetable is based on infrastructure updates that have not yet been implemented. For these updates the microscopic data is often not yet available in the systems used for network wide planning.

The advantages of a macroscopic or mesoscopic infrastructure model2 when compared to a microscopic model are well understood for these planning phases and have been demonstrated in many projects. However, there are important aspects in medium-term3 timetabling that deal with the operational feasibility of a timetable and where conflict detection between trains is needed. In some circumstances, conflict detection based on general separation times may be adequate. However, in cases with dense traffic on complex topologies, the results from such an approach are generally not sufficient. In such cases it would be preferable to use microscopic conflict detection in medium-term timetabling.

In this article, we present advancements in Microscopy-on-Demand (MoD) that allow microscopic calculations to be performed in medium-term planning. We call this functionality “Partial Coverage”. By this we emphasise that microscopic infrastructure is only available for a partial area of the network, or that the infrastructure in the macroscopic client and the microscopic server do not exactly match.

But before we dive deeper into the implementation of these improvements, we want to discuss some of the underlying and motivating factors behind our solution approach.

Infrastructure data availability challenges in timetabling

In rail operations, the availability of precise microscopic infrastructure data is an essential requirement for digitalisation and automation and is a fundamental component of modern system architectures for traffic management. Providing this data at a high level of quality across the complete network on a daily basis is a challenging and critical process and architecture component of modern dispatching systems.

In the annual and short-term timetabling process infrastructure managers in most European countries use microscopic data in their planning process. Microscopic running time calculation and conflict detection are applied in annual timetable planning to help ensure the operational feasibility of the timetable.

This dual use of microscopic infrastructures, for both operations and in capacity allocation, increases the data management complexity considerably. There are questions to be answered, such as whether the same data source should be used for annual timetabling and for traffic management, what kind of temporal data model is used, and which abstraction mechanisms are available for the different use cases?

In any case, most railway infrastructure managers seek to keep well-maintained, network-wide microscopic infrastructure databases. The time-consuming and labour-intensive data maintenance work (acquisition, quality control, updating, etc.) is justified by the crucial role this data plays in ensuring high operational quality. But the high level of effort needed is also a reason why this data is generally only systematically maintained in the operational and short-term areas, usually no longer than 18 months before operation.

For longer planning horizons, the accuracy of this data declines and therefore the practical value is no longer certain. Consequently, functionality based on microscopic details is no longer available.

Conventional approaches to conflict detection in medium-term timetabling

There is a range of approaches to deal with this situation in medium-term planning. What follows is a list of typical strategies from different European countries:

• No conflict detection is used at all, or at the most, global separation times in the planning rules are used to check the result. The advantage of this approach lies in its simplicity and efficiency. However, it can be inadequate for bottleneck-analysis, planning of capacity-optimised concepts and planning in complex topologies.
• Mesoscopic and similar abstractions: In this category, an abstract and simplified conflict model is used (e.g. using train-type dependent headway and separation times or an abstract resource allocation model). The benefit of this approach is a lightweight and efficient data model requiring less data and its associated maintenance for cases such as the construction of timetables or analyses including robustness and capacity KPI’s over a large area. But the mesoscopic conflict model also requires high quality data sources, albeit with lower data resolution than a microscopic model. The management of this data is still time-consuming and non-trivial. In cases where the mesoscopic model is based on the transformation of a microscopic source, the dependency on microscopic data persists. An additional consideration is the fact that the results generated in complex network situations may not have the same acceptance level by stakeholders as microscopic analyses, regardless of the validity of this assessment.
• Selective analysis in a microscopic system: Macroscopic timetables are exported to microscopic systems to determine their feasibility. To do this, a matching microscopic infrastructure must be set up in the microscopic system. The main disadvantage of this approach is the excessive costs associated with switching between systems and models. As a result, this step is usually only carried out selectively on a limited perimeter at the end of a timetable planning concept. There is no iterative procedure in which findings from the review can be incorporated early and repeatedly into the medium-term timetable planning concept.

The last point shows how microscopy is conventionally used in medium-term planning. It was this very high effort required for such an approach that led to the development of Microscopy-on-Demand, an architecture which allows the integration of the microscopic and the macroscopic worlds.

Microscopy-on-Demand: A quick recap

Microscopy-on-Demand (MoD) refers to a conceptual software architecture that SMA has specified and developed over the last few years. The architecture makes it possible to integrate the microscopic infrastructure model with the macroscopic infrastructure model for the specific tasks where microscopy is needed, i.e. running time calculation and conflict detection.

The implementation of MoD as a Viriato add-on module is based on a client-server-architecture, where the macroscopic system (i.e. Viriato) is the client and the microscopic services are provided by an external server. The microscopic server implementing the MoD API is delivered by a third-party microscopic system provider. A first successful implementation is the LaaS (LUKS as a service) system, which is provided by the company quattron. Additional implementations are currently under development, focussing on the requirements of selected geographic markets.

Partial coverage: A feasible and effective approach for microscopic conflict detection in medium-term timetabling

Overview

In the MoD data architecture, the microscopic infrastructure on the server-side is kept isolated from the macroscopic client. Due to the data isolation, the user can carry out infrastructure modifications in the macroscopic system without having to enter the same modification in the microscopic system. This applies to “simple cases” like entry and exit lines at the model boundaries, i.e. when the macroscopic infrastructure covers a larger perimeter than the microscopic infrastructure, as well as for “complex cases” when infrastructure changes are added only to the macroscopic infrastructure.

Examples of such changes are:

• Additional section tracks between nodes
• Additional tracks within a station
• Addition or removal of a station

Infrastructure changes such as these are quickly and easily incorporated into the macroscopic infrastructure and are immediately reflected in the timetable concepts.

Partial Coverage addresses the use case of how to use microscopic services in a restricted way when the macroscopic infrastructure and microscopic infrastructure differ.

Functional building blocks Partial Coverage consists of the following functional building blocks:

Server Side (Microscopic)

• Request Segmentation: Trimming request parts that are unknown in the microscopic model. Trimming can happen at the start, end or inside the request’s infrastructure.
• Microscopic Routing: of request segments

Client Side (Macroscopic)

• Structured Request/Response Comparison: Compare sent request data with received response data.
• Application Strategies: Provide different strategies on how to handle differences in requests and responses (see below for details).
• User Notifications: Detailed and structured notification of request/response differences and how the response is applied to the Viriato trains.

Application strategies

The implementation of “Partial coverage” was guided by taking a user-centered design approach. As an example, this can be seen in how the user can configure the behaviour of the application when structural differences are detected between the request and the response in a MoD calculation.

We can demonstrate this philosophy using the configuration of the application strategies for undertaking a running time calculation?.

The semantics of the application strategies are as follows:

The two following examples illustrate how application-strategies can be used differently depending on the context.

• A user wants to ensure that the train in Viriato uses infrastructure available in the microscopic server. They use the abort strategy: If there are any differences, they are only reported to them.
• A user makes infrastructure adjustments in Viriato and wants to get approximate running times from the microscopic server. They use the ignore strategy. They know there will be infrastructure differences, but they are ignored, and the running times are applied in a best effort manner to the timetable.

In summary, the user has a powerful, flexible, and robust mechanism at their disposal that simplifies the use of microscopic data in medium-term planning considerably and thus increases the quality, productivity, and acceptance in medium-term planning significantly.

Concluding Remarks

The explanations in this text describe why and how the MoD architecture and the Partial Coverage functionality are tailored for the application in medium-term timetabling. This is a highly relevant and pressing use case: the European Parliament has recently approved a regulation which aims to improve the use of rail infrastructure capacity. The text includes changes to the rules on the planning and allocation of railway infrastructure capacity. A detailed discussion of this topic has been given elsewhere and would go beyond the scope of this text. However, it should be stressed that the strengthening of medium-term timetabling executed by infrastructure managers will be a key element of this new framework. Besides the regulatory and procedural improvements, new methods and systems will be needed for adequate answers to demanding requirements. With MoD we have developed a well-designed, modern, and flexible solution reflecting the significance of medium-term timetabling as a key element in the capacity allocation process.

[1] Long-term timetabling and medium-term timetabling are often differentiated by the number of months before operation X in which the timetabling is done. E.g. > X-60 for long-term, X-60 – X-18 for medium-term planning.

[2] In short, a macroscopic model consists of simple nodes and edges, but contains no track information, a mesoscopic contains station tracks and section tracks, but no junctions, routes, signals, etc. For the sake of conciseness and without loss of generality we will use only the term macroscopic from now on.

[3] For the sake of conciseness, we will from now on use the term medium-term when an argument applies to both medium-term and long-term.

[4] In conflict detection, the same underlying principles apply, but the configuration is more restricted.??