The railML® interlocking is in active development and is supposed to go into productive use with railML® 3. This subschema focuses on information that infrastructure managers typically maintain in signal plans and route locking tables. Main users of this schema are interlocking suppliers and simulators. Users presently copy configuration data manually from paper plans.
- Data preparation is the process of adapting a railway interlocking and signaling system to a specific yard. Errors in the data affect safety; it is all too obvious that a wrong signal aspect can cause terrifying accidents. This is why railway people invest much time and effort testing. A standard data exchange format will allow the automation of data transfer and reduce the number of errors by taking the human factor out of the loop. This will create higher levels of safety at substantially lower cost.
- Simulation programs compute the impact of interlocking and signal configuration on capacity. Things like shifting a signal, using a faster point drive or shortening blocks can have a significant impact. Simulation algorithms grow ever more potent and reach a level of accuracy where seconds matter. At present, the real-time behaviour of interlocking and signaling often is unknown. The railML® IL schema allows modelers to quickly absorb information about the interlocking systems such as timing behaviour and routes and analyze the impact on railway capacity.
The case for exchanging interlocking information in a uniform format is obvious.
The interlocking schema reuses much information captured in the infrastructure schema which keeps the interlocking schema lean.
The main element of this subschema is IL:interlocking. As the subschema is in development, there are no documented elements at present.
The policy of this wiki is to ducument the currently supported versions of railML®. As the IL-subschema has not yet been released, it is not documented here, except for this outline and a sample of IL-specific use cases that can be found under IL:UseCases.