Note: This interview shares technical perspectives from a senior data manager at a major Western European Infrastructure Manager. The goal is to share best practices and common challenges facing the industry.
The "Industrial" Approach to RINF
For a small network, you might be able to maintain RINF data manually. For a major national network, that is impossible. Our guest explains that their RINF submission is regenerated from scratch every time.
"We are organized industrially. The RINF program takes data from our national databases—technical plans, signaling configurations, catenary systems—and converts it to the ERA format."
"At each run, we generate a brand new national RINF file. We connect to the source, convert, and publish. It’s the only way to manage the volume and change."
This aligns perfectly with Kapernikov's "Infra Data" philosophy: RINF should be a view on your data, not a separate data store that needs maintenance.
The Challenge of "Meso" Topology
The ERA model asks for "Operational Points" (OPs) and "Sections of Line" (SoLs). While this sounds simple, automating it from raw technical data is surprisingly difficult.
"We have the Micro level (signals, track circuits) and the Macro level (Line Liège-Oostend). The problem is the middle."
"A railway track is continuous. It goes from City A to City B. Defining exactly where the 'Station' ends and the 'Line' begins is subjective. We know where every signal is. But our database doesn't explicitly say 'This virtual line between signal X and Y is the border of the station.'"
The "Meso" level (Stations/Lines) aggregates the physical reality (Micro) into manageable chunks for Europe (Macro).
To automate this, you need rules. But with thousands of stations, each with different layouts, defining a rule that works everywhere is cost-prohibitive. This reflects a common tension in RINF 3.1: the desire for a "Meso" topology that aggregates the physical reality in a standardized way.
What is RINF actually for?
Our interviewee stressed the importance of scoping. Trying to make RINF do everything (timetabling, path allocation) risks making it do nothing well.
"For me, the tool's primary mission is physical compatibility. Can the steel of the wheel support the steel of the rail? Is the voltage compatible? Is there ETCS?"
"It gives the basic characteristics of the network. That is already massive. Trying to add timetabling or live path reservation into RINF is a mistake. Path allocation is an industrial process that requires much more than just static data."
On Deadlines and Pragmatism
With the March 2026 deadline looming, the sentiment is one of pragmatism. The shift to RDF, combined with new topology requirements, is a major undertaking—estimated at a full person-year of development just for the format conversion.
"Dates are there to create animation. Realistically, we will move forward incrementally. We have budgeted for RINF, but we also have to run the railway. We will deliver what is feasible, as we clarify the new model's requirements."
Key Takeaways
- • Automation is key: Don't edit RINF files. Generate them from your asset inputs.
- • Topology Boundaries are harder than Nodes: Knowing where assets are is easy (Micro). Deciding how to group them (Meso) is the hard part.
- • Focus on Compatibility: Keep the use case clear—checking if a train fits the track—to avoid scope creep.
Is your RINF data generated or manual?
Kapernikov helps Infrastructure Managers move to the "Data Factory" model.
Discuss Industrialization