UC:IL:InterlockEngineeringForSignallingWithinJBV

From wiki.railML.org
Jump to: navigation, search
Note.png This page is mirrored from page UC:IL:InterlockEngineeringForSignallingWithinJBV in the railML® 3 wiki.
Interlock engineering for signalling within JBV
Subschema: Interlocking
Reported by: Jernbaneverket
Stift.png                   (version(s) 2.4)
For general information on use cases see UC:Use cases

Use case / Anwendungsfall / Scénario d’utilisation

Interlock engineering for signalling within JBV; Stellwerkstechnik für die Signalisierung innerhalb von JBV; nom descriptif en Francais

Description / Beschreibung / Description

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.

IE use case.png

Data Flows and Interfaces / Datenflüsse und Schnittstellen / Flux de données et interfaces

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 / Interaction avec autres schemas railML®

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 / Caractérisation des données

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