[railML3.1] Signal aspect changes and simulation [message #2658] |
Wed, 10 February 2021 09:40 |
Victor Collod
Messages: 2 Registered: February 2021
|
Junior Member |
|
|
Hello railML.org!
I'm part of a software development team at SNCF Réseau in charge of making OSRD, a work in progress open source railway infrastructure editor and simulator.
https://github.com/dgexsolutions/osrd-core
We're trying our best to build our tool so it can simulate any signalization system supported by railML, but we haven't yet figured out how to simulate a few things:
1. when a route is activated, some signals have to change aspect. where are these relations defined? is it what aspect relations are for? our understanding is that an aspect relation defines a link between two signals, yet we aren't sure about what makes signals change aspect in the first place
2. we need to be able to simulate distant signals, but the Simple Example Step-by-Step guide v11 says it's not supported yet: "However, with railML3.1 there can be currently no relation described between any main signal and distant signal
or repeater". Is it still true? If so, how do current simulators handle these cases?
3. is signalFunction relevant for the purpose of simulation?
A few things also felt odd when reading through SimpleExample:
1. rae01 is called "Cstadt RA1" but is at Bf Arnau
2. sig07 (69Va) seem to be a distant signal relaying sig04 (69A), but this link isn't specified anywhere, which seems to indicate distant signals indeed aren't supported. Is this intuition correct?
3. sig08 is switchable, yet not used anywhere in the interlocking description. What kind of signal is it?
Thanks for making railML, it's a cool thing for our community to have :)
If you believe railML or its partners may be interested in helping build OSRD, send us a message!
PS: what's the best way to contribute changes?
|
|
|
|
|
Re: [railML3.1] Signal aspect changes and simulation [message #2668 is a reply to message #2667] |
Wed, 24 February 2021 08:01 |
Joerg von Lingen
Messages: 149 Registered: May 2011
|
Senior Member |
|
|
Dear Victor,
within the interlocking schema part one can model the information needed to engineer an interlocking for a specific
station. However, the functions of an interlocking are not yet included.
Thus the handling of routes or signals depending on the situation are not part of the schema.
You may declare for a signal a @releaseDelay or for a routeEntry any nonReplacement sections. But what the interlocking
does with this information is beyond the schema.
--
Regards,
Jörg von Lingen - Rollingstock Coordinator
|
|
|