Home » railML newsgroups » railml.interlocking » New area types for railML 3.3
Re: New area types for railML 3.3 [message #3210 is a reply to message #3196] Wed, 13 March 2024 13:38 Go to previous messageGo to previous message
Terje Nordal is currently offline  Terje Nordal
Messages: 17
Registered: December 2023
Junior Member
Dear Jörg,

This sounds very good. Adding keyLockInState and levelCrossingInState makes sense based on the refrenced forum post from Heidrun.

On the topic of referring to a trigger detector for CESA, I think it depends on what railML want to include in the standard. As I mentioned, the detector in this case would typically be a bit outside of the railway system itself, such as a fire alarm. Since that configuration is possible in our signalling system, directly effecting the state of an Emergency Stopping Area I think it also makes sense to add the possibility to model it in railML. However, are the current definitions in IL:detectorInState sufficient to do so? How would a fire alarm (or a similar detector) fit into that definition?

Best regards,
Terje Nordal

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Previous Topic: Attribute "trainNumberField@elementNumber" Datatype
Next Topic: Reuse IL:SignalBox for Object controllers
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sun Feb 15 03:39:05 CET 2026