Preview: New Use Cases for railML® 3.4
by Sharon Király (railML.org)
In 2026, railML.org celebrates two coinciding milestones: the release of the railML® schema version 3.4 at the 50th railML Conference. While the whole team continues to work avidly on both the conference preparation and schema development, we would like to provide our community with a sneak preview of the use cases newly implemented in railML 3.4.
In total, there are currently nine use cases under development set to be integrated in the upcoming version. These derive internally, from the project IDX4rail, and of course from the railML community. The general workflow of railML use case development has been explained in the 1st December 2025 News article.
The nine use cases are subjected to either the directing subschema Timetable or Infrastructure and sorted accordingly in this article. Other involved subschemas will be mentioned case by case.
Disclaimer: Please note that all use case names are still working titles and might be changed before the final release of railML® 3.4.
New Use Cases for Timetable
Replacement Service Planning (RPLS)
The use case RPLS has been derived from the railML community. Its purpose is to describe replacement services of any kind that are in place for cancelled trains or trains with reduced capacity. Possible target systems for this use case’s data include: timetable planning systems, bus service management systems, fleet planning systems, and reservation systems.
More information about the use case is available on the RPLS Wiki page.
Long Term Strategic Timetabling (LTST)
The use case LTST has been derived from the project ISO RailDax. In addition to Timetable, LTST is related to the subschemas Infrastructure, Interlocking, and Rolling Stock.
LTST utilizes timetable data that is provided usually two years in advance of operation. It may be applied to: infrastructure design and evaluation, socio-economic analyses, and service planning. More technical details and information about characterization of the data can be found on the LTST Wiki page.
Service Concept for a Tender (SCOT)
Like LTST, SCOT derived from the project ISO RailDax. SCOT is also related to the subschemas Infrastructure and Rolling Stock.
The use case SCOT serves as a timetable blueprint for when an authority issues a competition / call for proposals. This makes it easier for potential bidders to transcribe their own timetable systems to fit the call’s guidelines and to prepare the data using varying software tools. SCOT is applicable both to passenger and freight traffic, with a focus on the former. More information and technical details on SCOT can be found on the SCOT Wiki page.
Capacity Reservation for Tracks (CARE)
The use case CARE was proposed by the railML partner HaCon Ingenieurgesellschaft. With CARE, stationary capacity reservations of tracks can be represented, or, in other words, the usage of tracks that is not documented in any timetable. CARE may be applied to represent if track capacity has been booked (e.g. for parking), requested or cancelled.
More information on the use case is available on the CARE Wiki page.
New Use Cases for Infrastructure
Infrastructure Asset Status Representation (IASR)
The use case IASR has been created in the context of the project IDX4rail. IASR represents static information about railway infrastructure assets as well as dynamic information about their statuses. This information can then be fed to e.g. an Asset Management System or Maintenance Management System, to calculate the current traffic situation.
Detailed information on the characterization of data for this use case is available on the IASR Wiki page.
Track Geometry and Alignment (TRGE)
The use case TRGE is linked to the project IDX4rail as well. It facilitates exchange of information on alignment for one or more railways between (software) systems. TRGE deals with data directly related to the track, such as be track geometry, points of uneven elasticity, and track bed. This alignment data can stem from various sources like detailed surveys, CAD or BIM systems.
More information on practical application for TRGE and technical detail can be found on the TRGE Wiki page.
Automatic Train Operation Information (ATOI)
The use case ATOI has been submitted by the railML partner Hitachi Rail GTS Germany. This use case makes it possible to provide infrastructure data that is required for running an ATO (Automatic Train Operation) track side based on railML® data. For an overview on the data flow of ATOI as well as more technical details, consult the ATOI Wiki page.
Maintenance Planning for Infrastructure (MAPI)
Like IASR and TRGE, MAPI is also linked to IDX4rail. MAPI focuses the transfer of infrastructure data from an asset management source system to the maintenance planning system of the infrastructure manager.
More technical details as well as a chart of the data flow are available on the MAPI Wiki page.
Route Compatibility Check Input Data (RCCI)
The use case RCCI was submitted by the railML partner ÖBB Infrastruktur and has been spilt into two sub use cases (RCCI-a / RCCI-b) according to their focus on either the subschema Infrastructure or Rolling Stock.
RCCI allows for data transfer between systems to check whether any type of railway vehicle is compatible to pass a certain section of a route.
The Wiki page for RCCI is currently still under development.
If you would like to contribute to the development of these new use cases, feel free to contact the railML schema coordinators: Milan Hoffmann (Timetable), Christian Rahmig (Infrastructure) or Jörg von Lingen, PhD (Interlocking and Rolling Stock). Our working groups always welcome new members!