In2Rail – Toward seamless connectivity

IN2RAIL¹ is a Horizon 2020² project aiming to lay the foundations for a resilient, consistent, cost-efficient, high capacity European network by delivering important building blocks that will enable the unlocking of the innovation potential that exists in the future Shift 2Rail³ programme. In2Rail was financed under the European Union’s Horizon 2020 research and innovation programme.

In2Rail is one of the lighthouse projects of Shift 2Rail and will contribute to Innovation Programmes 2 and 3. Specifically, In2Rail will explore innovative technologies and the resulting concepts embedded in a systems framework where infrastructure, information management, maintenance techniques, energy, and engineering are integrated, optimised, shared and exploited.

In2Rail is structured around three technical sub-projects: Smart Infrastructure, Intelligent Mobility Management, and Rail Power Supply and Energy Management.

The In2Rail consortium includes more than 50 partners covering all areas of railway expertise: system integrators, manufacturers, infrastructure managers, maintenance railway suppliers and research institutes and universities from across Europe.

The focus of the Intelligent Mobility Management (I2M) sub-project is on the issue of digitalisation. How can we improve the utilisation, availability and usability of the combined rail transport resources, by means of computer-based support systems?

Digitalisation as such is nothing new in the railway sector. For practically all areas of operation, there are computerised systems available of variable maturity, ranging from computer-based interlockings, which have been commonplace for more than 30 years, to systems for analysing asset diagnostics which have emerged over the last few years. We have computer systems for timetabling, traffic management, energy management, asset maintenance, rolling stock inventory, crew rostering etc. What is missing is an efficient, automated and standardised way for these systems to cooperate, as one ecosystem.

Addressing this problem is also in line with establishing the Digital Single Market, identified as one of the 10 top priorities for the present European Commission. The public confidence in the railway is under pressure in many countries. Among the reasons are deficiencies caused by poor communication between the different stakeholders of the transport system.

Our proposal, the In2Rail platform, offers a solution by defining:

• An Application Framework where independently developed components can be integrated to form one Traffic Management System (TMS)
• An Integration Layer where TMS and other services can share data in a publish/
  subscribe pattern, thereby making full use of all available information.

A communication platform alone is not enough, however. The various applications, coexisting in the Integration Layer, also need to share a common language – also known as a Canonical Data Model (CDM).

There are several standardised data models that already exist in the railway sector – RINF, TAF/TAP TSI and ETCS Language to name a few. What most of these have in common is that they were designed to solve a specific problem. RINF describes the infrastructure, TAF/TAP TSIs are for data exchange between railway undertakings and infrastructure managers, and ETCS defines data needed by an on-board ATP. The result is that they have quite different views of the same reality. For example, all three models need to refer to geographic positions in the railway topology. Yet they do it in different ways, making them incompatible with each other. Identifying every position as a distance from a balise group is very practical for the ATP, but useless as a basis for an infrastructure register.

When defining the In2Rail CDM, we wanted to take a different approach, starting with a structured breakdown of the entities of the railway system (including physical entities such as wayside assets and vehicles, as well as logical entities such as timetables and traffic restrictions). Then add to each type of entity whatever data attributes that may be of interest to any application in the overall system context. That way, the data model will be structured according to real world objects and relations, instead of the needs of the foreseen services. Based on the CDM, data provider services know where to place their output, and data consumers know where to find it. Providers and consumers become loosely coupled, as they do not need any knowledge of each other’s internal data representation. This simplifies maintaining and upgrading applications independently. One application may ‘think’ in RINF and another in ETCS, but over the Integration Layer, they both ‘speak’ CDM.

A question stood out from this: Would we have to perform data modelling from scratch, or is there previous standardisation work that we could leverage from? We soon found that the railML.org⁴ initiative shared the same view of an application independent exchange format (see Figure 1). With the evolution of railML version 3, compliant to the UIC defined RailTopoModel (RTM), further steps are being taken towards a structure that aligns well with our view. The fact that railML versions 1 and 2 are widely accepted by many actors in the railway sector contributed to making railML 3 a natural choice as a basis for our CDM.

Figure 1: railML as a Canonical Data Model

However, railML as it stands today will not fulfil our needs. The use cases which drive the evolution of railML does not to-date include TMS, which is the core service for I2M. In particular, data which changes dynamically in real-time is not covered (for example, positions of trains, status of train routes etc.).

To close this gap, collaboration between railML.org and the In2Rail project has been established, where In2Rail will provide new use cases to railML, and also interactively participate in modelling these use cases for upcoming railML releases. That way, most if not all of the In2Rail CDM will be covered by railML. Symbiotically, we will create a stronger common standard.

The first priority in this collaboration is to establish some fundamental modelling principles:

Model Driven Architecture

This principle is essentially already covered by the ‘One UML’ approach agreed between railML.org and the UIC’s RTM expert group. The idea is that the core model is to be a platform independent model, defined in a UML class diagram. From this, a number of platform specific models can be derived. The XML representation which railML defines is one such model. Internally in the In2Rail platform, we plan to instead use Google Protocol Buffers for more efficient real-time data exchange. Other applications may have other needs of implementing data representations, or even generate software source code. All such derivations will still follow the conceptual definitions made in the core model.

Structure for expandability and divisibility

We cannot hope to cover all present and future needs of all railway-related systems in the first common model release. Instead, we will aim to create a structure where data from additional use cases can be easily added according to an established pattern, without disrupting the existing definitions. Equally important is to be able to structure the complete model, for example by namespaces or modules. Application developers should not be concerned about model complexity outside the needs of their individual applications.

Common modelling concepts

Common base types, which will be difficult to change later, needs to be agreed. In particular, this applies to data that cut across many different entities, such as data related to positioning and network navigation. Syntax for cross referencing between objects also needs to be established.

The ambition is to continue this collaboration not only during the In2Rail project, but throughout the Shift 2Rail programme. Several of the upcoming or already started Shift 2Rail projects are stakeholders in the CDM, and will contribute to a richer content by defining new use cases. Figure 2 illustrates the preliminary road map.

Figure 2: In2Rail CDM evolution road map

It will be a considerable step forward if the In2Rail platform and an evolved railML standard can create communication between existing railway support systems more efficiently. But perhaps even more important in the long-term is how this setup can support innovation. When all significant data related to the railway operation is made available in a structured way, it will be possible to develop completely new applications, without changing the existing ones. We hope to see services emerging tomorrow that exceed our imagination today.

Biography

Martin Karlsson is a Technical Expert at Bombardier Transportation within the Rail Control Solutions division in Gothenburg, Sweden. He was awarded a Master of Science in Engineering Physics from Chalmers University of Technology in 1985. Martin joined Bombardier (then Adtranz) in 1996 and was the technical lead in several of the company’s ‘world firsts’ such as Moving Block (1999), ERTMS Regional (2012) and ERTMS Level 3 (2014). Martin has been working as System Architect for CTC/ TMS systems since 2013.

Dr Stefan Wegele studied Mechanical Engineering at the Technical University of Braunschweig until 1999. Afterwards he worked on optimisationbased dispatching systems as a Researcher at the same university. Since 2012 Stefan has been a Software Architect for Traffic Management Systems at Siemens AG in Germany.

References

1. www.in2rail.eu
2. https://ec.europa.eu/programmes/horizon2020/
3. https://shift2rail.org/
4. www.railml.org