UC:IL:InterlockEngineeringForSignallingWithinJBV

Interlock engineering for signalling within JBV Subschema: Interlocking Reported by: Jernbaneverket

DRAFT railML® version TBD

For general information on use cases see UC:Use cases

Use case / Anwendungsfall

Interlock engineering for signalling within JBV; Stellwerkstechnik für die Signalisierung innerhalb von JBV

Description / Beschreibung

JBV intend to use this RailML interlocking scheme for both capacity simulations and transfer of correct data when engineering signalling systems. JBV would like in the future to use this RailML scheme for engineering of conventional signalling and ATP signalling as well as engineering of ERTMS.

The engineering process for JBV is as displayed in Figure 1. The base for the engineering is the overall operative rules and the overall technical design rules. These are compiled into the requirement specification. From these requirements the schematic layout and interlocking tables for a specific station are made, also taken operational requirements into consideration. After the layout and interlocking tables are finished, these are delivered to the supplier, and it is in this change of information we detect that lack in communication might occur. To standardize this information exchange would severely reduce risks that miscommunication occur, as well as risk that the system is misunderstood because of different signalling principles. The information from the supplier to JBV as the system is ready to could also be defined as a data exchange that would be useful to standardize. To digitalize this method would be beneficial to decrease cost and risk regarding human mistakes if information at any time is handled by humans.

The European Union has also required that all countries add their topology data into RINF(Railway infrastructure database). JBV has started this process, and it would be beneficial to link these two works together especially when gathering information regarding topology.

Future use case should handle integration towards 3D modelling for evaluation of e.g. sight distances.

Data Flows and Interfaces / Datenflüsse und Schnittstellen

This will show the interaction with data sources and sinks.

Information category	Origin (as of today)	Origin (possible in future)
Topology	Geografic models	railML schema
Track elements (signals, points, etc.	schematic plan/interlocking table	railML
Train routes	schematic layout/interlocking tables	railML schema
Speed profile	ATP plans	railML schema
Signal aspect realtions	interlocking tables	railML schema
Schematic plan of stations	schematic plan	railML schema
Schematic placement of boards	schematic board plan	railML schema
Timers	interlocking tables/relay drawings	relay drawings
Current installation of relays	relay drawings	railML schema
Gradient	ATP plans	railML schema
Braking curves	ATP plans
Installation of ATP balises
ATC plans	ATC plans
Placement of catenary	power supply plans	Power supply plans
Station categories

These points are needed for JBV to make a fully functional signalling system, and the knowledge about of how these are placed and work together is crucial to the systems functionality.

In the Norwegian track net the stations are classified into groups. To be able to select such a group and configure the toplogy would be useful.

Interference with other railML^® schemas / Interferenz mit anderen railML^®-Schemen

There is no description of this as of today.

If RailML is introduced, the system will need to be dependent on the infrastructure part, as the signalling system uses the elements in the infrastructure to ensure safety and make train routes. In Norway there are also dependencies between the infrastructure and the time table. That means that the train is not allowed to activate level crossings before the train routes is set based on the time table.

The timetable scheme will be dependent on the interlocking. If such a scheme is introduced the timetables might be dependent on the states of the interlocking to calculate the time used.

Characterizing Data / Charakterisierung der Daten

This section serves to specify the required data regarding certain aspects.

How often do the data change (update)?

The data change every time some work is done on a station or location along the line. There is a huge variation regarding how often the system will have to be updated.

How big are the data fragments to be exchanged (complexity)?

The most normal in Norway is that whenever a change is made to the signalling system, the entire station is updated. This is defined as one interlocking area in the conventional interlocking systems. There are most stations with two tracks in the Norwegian track net, although Oslo Central Station has 27 tracks and several branches of railway lines.

Which views are represented by the data (focus)?

• Signalling
• Schematic view of topology