| Elements of supervisory control system [message #3789] |
Fri, 21 November 2025 10:56  |
Xenia Augustin
Messages: 1
Registered: June 2025
|
Junior Member |
|
|
Dear railML interlocking community,
I'm Xenia, a system engineer at SBB and new to the railML team at SBB. My focus is on interlockings and control systems, and I'd appreciate your advice on modeling operator stations in our control system with railML.
At SBB we use a supervisory control system that remotely operates interlockings. In this control system, we work with "stations": the area that is visible and operable for a single operator. A single interlocking can be operated from several operator stations. Along a line, multiple consecutive areas may be controlled by the same interlocking, yet from the control-system perspective each area has its own station (see attached schematic). For our use case it's important to assign every interlocking asset (e.g., switches, signals, level crossings) to the station from which it is operated.
We see IL:controller as a good fit to represent the operator-station concept. By definition of the railML 3 wiki, IL:controller is a "container with reference to connected interlockings and system assets controlled by this operational terminal." Our idea is to reference the interlocking via controlledInterlocking and to list the assets operated from the station via controlledSystemAsset, so each operator station explicitly holds the subset of assets it controls.
Questions:
1. The wiki appears to discourage assigning assets to IL:controller that are already assigned to an interlocking. In our situation, the station area is not equivalent to the interlocking's overall area; not every station operates all assets of the interlocking. Would it be acceptable to explicitly list the relevant subset per station using controlledSystemAsset, even though those assets also belong to a controlled interlocking?
2. If explicit controlledSystemAsset lists are not recommended, what modeling pattern would you suggest to capture an operator station that controls only a subset of an interlocking's assets? Is there a preferred grouping or reference mechanism?
3. Are there cardinality constraints in railML 3.x (interlocking) that affect this (for example, may the same asset be referenced by multiple IL:controller elements)?
4. Have others modeled operator areas/stations in a similar way? Any best practices or pitfalls to be aware of?
Looking forward to your inputs and discussion,
Xenia Augustin and Silvan Gruber
SBB Swiss Railways
|
|
|
|
| Re: Elements of supervisory control system [message #3856 is a reply to message #3789] |
Sat, 03 January 2026 05:19  |
Jörg von Lingen
Messages: 114
Registered: March 2016
|
Senior Member |
|
|
Dear Xenia,
yes, the Controller element is seen as the operator place for interlockings (SignalBox, RBC). But there is not only 1:1 relation to an interlocking as several controller might be used to control it - one at a time. In order to allow the control of a part of an interlocking from one controller railML uses the asset PermissionZone. The latter is just a list of elements belonging to this zone. There is a 1:1 reference from the SignalBox to the PermissionZone and vice versa. It might be useful to add this concept also for RBC.
1./2. This would require the use of PermissionZone.
3. Controller - SignalBox [m:1]
SignalBox - TrackAsset/SystemAsset [m:n] with extendOfControl as only one SignalBox shall be the master
SignalBox - PermissionZone [1:n]
PermissionZone - TrackAsset/SystemAsset [1:n]
4. Unfortunately no example yet in railML. However, Hitachi uses a similar concept in their engineering data.
Best regards,
Joerg v. Lingen - Interlocking Coordinator
|
|
|
|
Members
Search
Help
Login
Home
