Home » railML newsgroups » railML.infrastructure » [railML 3] railway signal modeling (Need to discuss a way to represent railway signal aspects using railML 3.2)
Re: [railML 3] railway signal modeling [message #3098 is a reply to message #3063] Wed, 14 June 2023 18:18 Go to previous messageGo to previous message
Larissa Zhuchyi is currently offline  Larissa Zhuchyi
Messages: 37
Registered: November 2022
Member
Given the above clarification of Mr Nygreen (common coordinator of railML.org) and follow-up discussions of all the coordinators please provide your thoughts (agree, disagree, detailed answer) on these points.

The aim is to solve the distinction of the physical and the functional aspects of a signal. Functional aspects should go to the interlocking schema (see IL forum post [1]), while physical ones ‒ to the infrastructure.
Possible changes will be implemented in railML 3.3. Missing documentation will be added to railML 3.2 (railML 3.3 inherits).

Documentation for the schema.
(1) isAnnouncementSignal means that a train should announce itself (usually with a whistle, bell, or train horn) to warn about the train coming to e.g., level crossing. It does not mean that the signal announces the aspect of a following (main) signal.

Clarification for the wiki.
(2) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/@isSwitchable does not automatically mean light signal. Please use /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/signalConstruction/@type= "light" to represent light signals.
This is due to the fact that light signals can be non-switchable [2]. Also, semaphores can be switchable as well.

Changes of schema to implement in railML 3.3.
(3) @bell, @horn and @whistle flags should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isAnnouncementSignal.
(4) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isLevelCrossingSignal/@bell @whistle should be removed because covered by isAnnouncementSignal.
(5) @isShunting, @isRepeater flags should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isTrainMovementSignal.
(6) @type attribute with "main", "distant" enumeration should be added to /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isTrainMovementSignal.
(7) /railML/infrastructure/functionalInfrastructure/signalsIS/si gnalIS/isLevelCrossingSignal/@announcing should be deprecated because covered by isTrainMovementSignal of @type="distant".

Please provide your thoughts (agree, disagree, detailed answer) on these points.

[1] https://www.railml.org/forum/index.php?t=msg&goto=3097&a mp;#msg_3097
[2] https://www.railml.org/forum/index.php?t=msg&th=648& goto=2144&#msg_2144

Sincerely, Larissa Zhuchyi


Larissa Zhuchyi – Ontology Researcher
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Wed, 14 June 2023 18:25]

Report message to a moderator

 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Export linear location information for switch tip/left/right branch and crossings
Next Topic: [railML3.3] Signal combinations
Goto Forum:
  


Current Time: Sun Jun 16 05:24:01 CEST 2024