UC:IL:InterlockEngineeringForSignallingWithinJBV
Interlock engineering for signalling within JBV Subschema: Interlocking Reported by: Jernbaneverket | |||
| |||
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 schema for both capacity simulations and transfer of correct data when engineering signalling systems. JBV would like in the future to use this railML® schema 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 schema will be dependent on the interlocking. If such a schema 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