Home » railML newsgroups » railML.infrastructure » Question from T. Graffagnino from SBB
| Question from T. Graffagnino from SBB [message #177] |
Fri, 29 September 2006 11:30  |
Daniel Huerlimann
Messages: 17
Registered: September 2004
|
Junior Member |
|
|
Dear group
I am posting this question of behalf of Thomas Graffagnino from SBB.
Regards
Dani Huerlimann
------------------------------------
Hello
I am new to RailML and didn't find any in depth explanation
about the Infrastructure Schema v 1.00. On a "Studienarbeit"
"Modellierung einer Eisenbahn-Infrastruktur in RailML" from Mr
Fries, I found interesting informations which are sadly not
actual anymore...
I am particularly interested in coding "Fahrbegriffe"-signal
aspects, "Freigabepunkte"-release points and
"Zugnummermeldepunkten"-train number transmission points (free
englisch translations). In the document of Mr Fries are the
following elements described:
Element <signal>
Element <disposition>
Element <clearTrackContrElements>
Element <trackCircuitBorder>
Element <axleCounter>
I would like to use them in a correct manner but I didn't found
any further description of these elements which would avoid a
misuse-
Could any one help ?
Has anyone any document describing the Infrastructure Schema a
little more in depth ?
Has anyone example of how to use it correctly ?
Thank you in advance.
Best Regards from Switzerland
Thomas Graffagnino
SBB AG, I-BF
--
============================================================ ==
Eidg. Technische Hochschule Zuerich
Swiss Federal Institute of Technology Zurich
Inst. for Transportation Planning and Systems
CH - 8093 Zurich, Switzerland
Dr. Daniel Huerlimann¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý ¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý
Phone: + 41 1 633 27 38
Fax: + 41 1 633 10 57¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý
E-Mail: huerlimann(at)ivtbaugethzch¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý¬Ý
WWW: http://www.ivt.baug.ethz.ch, http://www.opentrack.ch
============================================================ ==
-- =======
-- --
|
|
|
|
| Re: Question from T. Graffagnino from SBB [message #178 is a reply to message #177] |
Thu, 05 October 2006 09:40  |
Volker Knollmann
Messages: 32
Registered: October 2003
|
Member |
|
|
On 29.09.2006 10:24, GRAFFAGNINO THOMAS wrote:
> In the document of Mr Fries are the following elements described:
>
> Element <signal>
> Element <disposition>
> Element <clearTrackContrElements>
> Element <trackCircuitBorder>
> Element <axleCounter>
>
> I would like to use them in a correct manner but I did'nt found any
> further description of these elements- Could you help ?
The elements <disposition>, <clearTrackContrElements> and
<axleCounter> are not part of the current infrastructure schema. IIRC
they were part of a former version, which was used at the time Mr.
Fries wrote his thesis.
The <trackCircuitBorder> describes a joint of two track circuits: one
track circuit ends, the next one starts. Since railML intends to use
loooong <track>-elements, one <track> can span multiple track circuits
and therefore, an elements is required to define the joint (or the
border) between two track circuits. That's <trackCircuitBorder>.
It uses the common attributes of every element (ID, relative position
along the <track>, absolute position, etc) and has an additional
attribute describing the electrical isolation between the rails at the
position of the joint. The isolation joint position can be "none", "left",
"right" or "both". As usual, "left" and "right" are seen in nominal
direction (rising mileage).
By the way: axle counters can be modeled using the sibling element of
<trackCircuitBorder>, which is <trainDetector>. Just set
"axleCounting" to "True" and (optionally) set "detectionObject" to
your specific needs and you're done.
The <signal>-element is a little bit more complex. I'll just give you
a typical example to start with. If you need more information about specific
attributes or details of <signal>, please send a more specific query
to the news group. Here's an example for a signal:
<signals>
<signal elemID="21004" pos="0.100" dir="down" type="combined"
function="home" sigSystem="Ks" virtual="false"/>
<signal elemID="21005" pos="3.100" dir="up" type="combined"
function="blocking" sigSystem="Ks" virtual="false"/>
<signal elemID="21006" pos="3.100" dir="down" type="combined"
function="blocking" sigSystem="Ks" virtual="false"/>
<signal elemID="21007" pos="4.100" dir="down" type="distant"
function="blocking" sigSystem="Ks" virtual="false"/>
<signal elemID="21008" pos="8.900" dir="up" type="distant"
function="home" sigSystem="Ks" virtual="false"/>
<signal elemID="21009" pos="9.900" dir="up" type="combined"
function="home" sigSystem="Ks" virtual="false"/>
</signals>
All signals use the Ks-System ("Kombinationssignal", similar to the
swiss N-Signals), which is indicated by 'sigSystem="Ks"'. None of the
signals is virtual (virtual signals can belong to shadow stations, for
example. Or they represent the start or end signal of a trainroute,
where no physical signal exists).
"pos" indicates the relative position along the parent <track>. Most
of the signals are combined main and distant signals
('type="combined"'), but two are pure distant signals
('type="distant"'). The attribute "function" defines whether a signal
is normal block signal, an entry signal ("home") or an exit signal
("exit").
> Would you have any document describing the Infrastructure Schema a
> little more in depth ? Do you have any .xml example where these
> elements are used ?
Yes and no ;-)
I'm planning for months to make some internal documentations and
specifications containing railML-data suitable and available for
public, but I didn't manage to really DO that up to now... (shame on
me).
But I hope, that this posting will ease your start with railML a litle
bit. Don't hesitate to ask more questions! ;-)
Best regards from Braunschweig,
Volker Knollmann
--
Dipl.-Ing. Volker Knollmann
Coordinator RailML-Infrastructure
Phone: +49 (0) 351 295-3461, Fax: -3402
German Aerospace Center (DLR)
Institute of Transportation Systems
Lilienthalplatz 7, D-38108 Braunschweig
|
|
|
|
|
|
| Re: Question from T. Graffagnino from SBB [message #180 is a reply to message #179] |
Thu, 05 October 2006 12:14 |
Daniel Huerlimann
Messages: 17
Registered: September 2004
|
Junior Member |
|
|
Dear group
Again, I am posting of behalf of Thomas Graffagnino from SBB.
Regards
Dani Huerlimann
_____________________________________
Thank you very much for your answer which is very helpfull.
You mentionned the possiblity to define the signal system with
'sigSystem="Ks"' for example. I have 2 further question:
- What are the names of the different type of sigSystem which are to be
commonly used ?
- 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 ?
Thank you in advance and best regards, Thomas Graffagnino.
_____________________________________
In article <eg2qdu$hql$1(at)sifaivifhgde>,
Volker Knollmann <coordinfrastructure(at)railmlorg> wrote:
> On 05.10.2006 09:40, Volker Knollmann wrote:
>> Coordinator RailML-Infrastructure
>> Phone: +49 (0) 351 295-3461, Fax: -3402
> ^^^^^
>
> Uuups, had to much contact with Dresden in the last time, so a little
> type occured in the footer. To contact me, please dial
>
> Phone: +49 (0) 531 295-3461, Fax: -3402
>
> Sorry for any inconvenience and confusion,
> Volker Knollmann
--
============================================================ ==
Eidg. Technische Hochschule Zuerich
Swiss Federal Institute of Technology Zurich
Inst. for Transportation Planning and Systems
CH - 8093 Zurich, Switzerland
Dr. Daniel Huerlimann¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬? ¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?
Phone: + 41 1 633 27 38
Fax: + 41 1 633 10 57¬?¬?¬?¬?¬?¬?¬?¬?¬?¬?
E-Mail: huerlimann(at)ivtbaugethzch¬?¬?¬?¬?¬?¬?¬?
WWW: http://www.ivt.baug.ethz.ch, http://www.opentrack.ch
============================================================ ==
-- =======
-- --
|
|
|
|
| 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
|
|
|
|
Goto Forum:
Current Time: Wed Apr 24 14:12:30 CEST 2024
|
Members
Search
Help
Login
Home
