The case for a federated digital model of the rail system

One information source, a variety of data needs

Railway systems are comprised of concrete, steel, and many stakeholders, all of which require different types of information. Available information comes from an assortment of sources, from long-lived documents that are hard to maintain, to measurement streams that will soon lose relevance. A ‘single source of truth’ aggregating and dispatching reliable, up-to-date information would be an obvious benefit.

However, ‘single source’ does not necessarily translate to ‘central database’, and the very notion of database may not be entirely adequate. Managing and sharing knowledge about a railway system in operations involves additional technologies, some of which have widespread use – such as Unified Modelling Language (UML) – while others are emerging (such as ontologies). Above all, the key to success is cooperation.

Why use UML, and what is it?

Since the 1970s, databases have become the most widespread corporate IT resource, short of e-mailing. The most prominent feature of mature database technology is scalability vs data volumes, data flows, and the number of publishers and subscribers. However, professionals think more in terms taxonomies (tree-like structures) as used for classification of species or analytical accounts. Representing taxonomies feels contrived within databases but more natural in UML.

UML is a graphical language controlled by the Object Management Group (OMG) widely used for software definition. UML can be used as a bridge between domain experts and IT experts. UML class diagrams allow to capture concepts normally expressed in natural language such as ‘Eurobalise…’ (subject) ‘… is located at…’ (verb) ‘… Spot location’ (object). Another common reasoning aid is the generalisation, as in ‘active signals and boards are a kind of signal’. These sentences allow taxonomies to be created, very much like Linnaean classification of the natural kingdom.

While UML class diagrams are essentially descriptive, they can also be transformed into other languages that are more adapted to specific tasks such as RDF/OWL for semantics, XSD or JSON schema for data exchange, or into executable languages such as Java or C#.

From ARIANE, the SNCF railway domain model…

The ARIANE project was launched by RFF (now SNCF Réseau) in 2011 as part of a master plan for an infrastructure description repository where an object-oriented model based on a systemic and incremental approach was implemented.

The core of the ARIANE model is the rail network topology: all functional descriptions refer to it. Network assets, linear characteristics, operations (trains running, route interlocking, etc.), are added as and when required, without having to revisit the fundamentals and on an incremental basis. The model natively integrates the temporal dimension of infrastructure life and supports the management of multiple infrastructure evolution scenarios within the same instance of the same model. ARIANE therefore enables the definition of a model of an evolving infrastructure, in a multi-actor/contributor environment.

At the end of 2012, the first version of the model repository (GAIA) was born, serving publishers and subscribers via a RESTful API. Subsequently, a second master plan dealing with infrastructure capacity and train circulation was devised which led to ARIANE being expanded from infrastructure assets to include other parts of the railway system.

In 2014, possession programming and scheduling were added to the ARIANE workplan with other aspects on a wide variety of subjects, including measurements and alarms, or financials control of infrastructure projects. In parallel, various processes (path control, maintenance, etc) were also addressed. Since 2018, SNCF has been extending ARIANE to describe other aspects of infrastructure, such as physical objects (track subgrade, etc) and structural objects (BIM library equivalents). SNCF is currently mapping more domains, including supply chains, the environment and human resources.

…to RailSystemModel, an open UIC standard

The existence of a digital model of the rail system could benefit the whole sector. In 2014, in line with its mission, the UIC launched a project with the participation of several infrastructure managers and external technical support. The project was dubbed ‘RailTopoModel’ (RTM) in recognition of how pivotal railway network topology is as the model’s ‘skeleton’: the project was never envisioned to be limited to infrastructure. ARIANE was its main input.

RTM was first released by the UIC as International Railway Solution IRS30100 in 2016, then as RTM 1.1 in 2017. From version 1.2 onwards in 2021, it was subsequently re-branded as ‘RailSystemModel’ (RSM). Although topology did not lose relevance, the new name better conveyed the general intentions for the project.

RSM was, from its inception, released for free to the general public with no restriction on use. Its current version is published under the EUPL 1.2 license and leverages, where relevant, public standards from the likes of OGC, OMG, or W3C.

To achieve the vision of RSM as a generalist railway system model, its expansion favours collaboration over reinvention, from which cooperation with other initiatives materialised. For example, European research projects such as LinX4Rail or initiatives from the sector like EULYNX for signalling.

EULYNX Data Preparation model

The EULYNX consortium, comprised of European infrastructure managers, recognised the need to standardise the interfaces between interlocking and peripheral systems. To clarify how important this move would be, a comparison can be made with proprietary computer ports being replaced by USB, to return to the IT sector.

Another standardisation effort tackles the challenge of porting yard configuration information to the interlocking. A modern signalling system runs standard software for throwing points, calling routes, and issuing movement authorities to trains. This software implements national signalling rules that were previously implemented in relay and mechanical technology.

The benefit of a single model that represents signalling information in machine-readable format is obvious. The EULYNX Data Preparation (DP) cluster has created a UML model, which implements information requirements from Network Rail, Deutsche Bahn (DB), ProRail and other infrastructure managers.

A federated model made reality

Signalling requires the descriptions of the railways network to be accurate, while also being vital in other areas. In 2017, EULYNX (Data Preparation) and UIC started to collaborate, agreeing that:

• RSM would provide the common basis for infrastructure description
• EULYNX DP would take care of the signalling domain
• Dependencies between RSM and EULYNX models would be kept minimal and explicit.

This coordination proved to be feasible while equally not encroaching on either project’s autonomy. Further it fostered convergence on important matters (e.g., licensing, documentation, priority given to business concepts over data formatting details, etc).

Towards a larger federated model

Although they are at different stages of development, ARIANE, RSM and EULYNX DP are rising to the challenge of putting conceptual models to work that are implementable and platform- or project-independent. These models scale well to complexity and their conceptual orientation facilitates interfacing and extension.

These characteristics are essential qualities for forming a federated digital model of the railway system, while not falling into the trap of creating ‘a model to replace all models’. Encouraging clear responsibilities between domains and enforcing strong semantics allows agility in model development to be achieved while maintaining a cohesive federated digital model.

The immense digitalisation and standardisation efforts foreseen in the upcoming programme of Europe’s Rail Joint Undertaking (EU-Rail) would benefit from adopting convergent conceptual models and, where possible, bridging models by means of ontologies.