| Re: Question from T. Graffagnino from SBB [message #181 is a reply to message #180] |
Thu, 05 October 2006 13:03  |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
On 05.10.2006 12:14, Thomas Graffagnino wrote:
> - What are the names of the different type of sigSystem which are to
> be commonly used ?
So far, we did not agree on a list of valid names. "sigSystem", as
many other attributes, are not very strongly typed (e. g. using
enumerations). This is one of the most important disadvantages of the
current schema version, which has to be fixed in future releases.
> - We would also have an ETCS L2 "Limit of Movement Authority"; would
> it be correct to have a main signal with 'sigSystem="ETCSL2"' for
> that ?
GOOD question! In fact, Heidrun Jost from Alcatel had a similar
question a few days ago during the last railML-Meeting.
I think, the way you mentioned looks fine. We agree on a certain
sigSystem-value and model the LOA as signal. Additionally, we should
set the "virtual"-flag, since the signal exists only logically, not
physically. The advantage of this solution is that
(simulation-)software, even if is not aware of ETCS, will handle the
LOA more or less correctly as a "real" signal.
The question Heidrun raised refers to the implementation of level
transitions. I guess that's an interesting point for SBB as well,
because as far as I know the ETCS-lines in Switzerland you use L0 and
L2. And strongly related to the modeling of level changes is the topic
of mode changes (e.g. from / to "unfitted", "staff responsible", etc).
I suggest to implement level changes either...
.... as track/trackElements/operationModeChanges/operationModeChange
with suitable values for "modeExecutive" and "modeLegislative"
(suggestions anyone??).
.... or as track/trackTopology/borders/border with an adapted
enumeration for the attribute "type".
Personally, I tend to the first possibilty, since a level change is
more an operational than a topological issue. But I'd like to hear the
pros and cons of other group members!
Regarding mode changes I'm not fully convinced whether it makes sense
to add them to a railML-file or not. They have a much more "dynamic"
character than level borders (e. g. the transition to OS depends on
the time and location the driver acknowledge the transition to OS). So
I'm in doubt to have such "dynamic" aspects in a "static"
infrastructure file.
I'm curious to hear the group's opinion about that!
Best regards,
Volker Knollmann
--
Dipl.-Ing. Volker Knollmann
Coordinator RailML-Infrastructure
Phone: +49 (0) 531 295-3461, Fax: -3402
German Aerospace Center (DLR)
Institute of Transportation Systems
Lilienthalplatz 7, D-38108 Braunschweig
|
|
|
|
Members
Search
Help
Login
Home
