Home » railML newsgroups » railml.rollingstock » Harmonization with infrastructure aspects
Harmonization with infrastructure aspects [message #1210] Thu, 05 January 2012 13:25 Go to next message
Susanne Wunsch railML is currently offline  Susanne Wunsch railML
Messages: 0
Registered: January 2020
Dear Jörg and all interested in this thread,

wish you all a Happy new year and all the best for your business and
family. :-)

Carsten provided a very comprehensive suggestion for more detailed
definition of speed changes in the "Infrastructure" subschema. There are
some topics that are also met in the "Rollingstock" subschema. That's
the reason I ask here for any comments.

Susanne Wunsch <coord(at)commonrailmlorg> writes:
> "Carsten Weber" <weber(at)irfpde> writes:
>> <xs:element name="axleLoad" minOccurs="0" maxOccurs="1">
>> <xs:annotation>
>> <xs:documentation>If any vehicle at the trains has a load at an axle
>> higher than this value this speed limit has to be used.</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>
> Good idea. I would propose it as an attribute and bind it to the railML
> type "tWeightTons".
>
> What is Jörg von Lingens opinion (as Rollingstock coordinator) about the
> terminus? Rollingstock already uses "axleLoad" and "axleWeight" for some
> related information.

Should we name the axle weight/load restriction for a speed profile
"axleWeight" or "axleLoad"?

>> <xs:element name="tiltingAngle" minOccurs="0" maxOccurs="1">
>> <xs:annotation>
>> <xs:documentation>Tilting parameters for which this speed profile is
>> calculated.</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>
> Good idea. I would spend a child element <tilting> for this and the
> following kind of information. The attribute "angle" could be bound to
> the railML type "tAngleDegQuadrant" for allowing 0° to 90°.
>
> Does a speedProfile covers only one tilting angle value or a range of
> values or some single values?
>
>> <xs:element name="tiltingSpeed" minOccurs="0" maxOccurs="1">
>> <xs:annotation>
>> <xs:documentation>Tilting parameters for which this speed profile is
>> calculated.</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>
> The terminus "speed" may be a bit misleading. I suppose, that is not
> related to the "train speed" but to the "rate/speed of tilting", that
> means the value of tilting degrees per second. I would call this
> attribute "rate". Are there any other ideas?
>
> This attribute may be bound to the railML type "tSpeedDegreesPerSecond".
>
> There is another kind of information related to the tilting that comes
> to my mind: the method of tilting. It could go into an attribute
> "method" that is bound to an enumeration of "active", "passive",
> "rollCompensation", "unknown", "other:anything".
>
> There is already a type "tTilting" in the rollingstock subschema. We
> should coordinate these tilting issues with Jörg von Lingen (as
> rollingstock coordinator).

Maybe we could reuse the "tTilting" type from rollingstock providing the
attributes "maxTiltingAngle", "actuation" and "tiltingSpeed" for the
speed profiles.

>> <xs:element name="monitoringSystems" type="rail:eMonitoringSystems"
>> minOccurs="0">
>> <xs:annotation>
>> <xs:documentation>One of the listed monitoring systems has to be used
>> by the trainPartSequence to use this speed profile.</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>> <xs:complexType name="eMonitoringSystems">
>> <xs:sequence>
>> <xs:element name="MonitoringSystem" type="rail:tNationalSytemsType"
>> minOccurs="1" maxOccurs="unbounded">
>> <xs:annotation>
>> <xs:documentation>type = tNationalSystemsType; Maybe it should be
>> changed to a reference to a new base element monitoring system which would
>> be referenced by vehicles, trainPartSequences, speedProfiles and
>> trackElements. But also the defined types can be used as a
>> key.</xs:documentation>
>> </xs:annotation>
>> </xs:element>
>> </xs:sequence>
>> </xs:complexType>
>
> That is an interesting idea. It touches Trac Ticket #111 [1].
>
> railML currently requires heavy repetition of obviously equal data
> applying the <trainProtectionElement> in <ocsElements>. Thomas Albrecht
> already pointed it out in 2009. [2] But a change of this structure
> requires a non-downward-compatible change, that we may do with next
> major release according to our release policy. See also Trac ticket #23
> [3].
>
> If it would be a blocking issue, we may mark the current element as
> "deprecated" and allow for a "definition list"/"library"/"catalog" of
> train protection elements inside the <infrastructure> element.
>
> <trainProtectionSystem id="tpsLZB" name="LZB"
> description="Linienförmige Zugbeeinflussung" xml:lang="de"
> type="LZB" medium="inductive" monitoring="continuous"/>
>
> Along the <track> we could define the <trainProtectionElement>
> refering to one of the "definition list elements".
>
> The same way we could refer to various train protection systems from
> within a <speedProfile>.
>
> Does this approach also work for different ETCS levels?
>
> This issues should be harmonized with the rollingstock implementation
> (tNationalSystemsType). Contact: Jörg von Lingen.

There is a parallel unequal implementation of command-control-system
elements in railML.

* The Infrastructure subschema defines <trainProtectionElement>s,
<balise>s, <trainDetector>s and <trackCircuitBorder>s.

* The Rollingstock subschema defines <etcs> with
<specificTransmissionModule> and <nationalSystem> with the same
intentions partly using the same basic railML types.

I'm sure, we should harmonize this aspect regardless of the annoying
repetition effect in the Infrastructure subschema!

> [1] http://trac.assembla.com/railML/ticket/111
> [2]
> http://www.railml.org/web/index.php/previous-events.html?fil e=tl_files/railML.org/documents/events/slides/2009-10-06_tud resden_albrecht-interlocking.pdf
> [3] http://trac.assembla.com/railML/ticket/23

Thanks for any help and kind regards...
Susanne

--
Susanne Wunsch
Schema Coordinator: railML.common
Re: Harmonization with infrastructure aspects [message #1211 is a reply to message #1210] Thu, 02 February 2012 19:18 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 148
Registered: May 2011
Senior Member
Dear all,

it needed a long business trip to find time to look into the details of the
proposals. See answers below.

On 05.01.2012 13:25, Susanne Wunsch wrote:
> Dear Jörg and all interested in this thread,
>
> wish you all a Happy new year and all the best for your business and
> family. :-)
>
> Carsten provided a very comprehensive suggestion for more detailed
> definition of speed changes in the "Infrastructure" subschema. There are
> some topics that are also met in the "Rollingstock" subschema. That's
> the reason I ask here for any comments.
>
> Susanne Wunsch <coord(at)commonrailmlorg> writes:
>> "Carsten Weber" <weber(at)irfpde> writes:
>>> <xs:element name="axleLoad" minOccurs="0" maxOccurs="1">
>>> <xs:annotation>
>>> <xs:documentation>If any vehicle at the trains has a load at an axle
>>> higher than this value this speed limit has to be used.</xs:documentation>
>>> </xs:annotation>
>>> </xs:element>
>>
>> Good idea. I would propose it as an attribute and bind it to the railML
>> type "tWeightTons".
>>
>> What is Jörg von Lingens opinion (as Rollingstock coordinator) about the
>> terminus? Rollingstock already uses "axleLoad" and "axleWeight" for some
>> related information.
>
> Should we name the axle weight/load restriction for a speed profile
> "axleWeight" or "axleLoad"?
The term "axleLoad" is used only in RS. This is used together with
loadLimitMatrix containing permissible speeds in relation to axle loads.


>>> <xs:element name="tiltingAngle" minOccurs="0" maxOccurs="1">
>>> <xs:annotation>
>>> <xs:documentation>Tilting parameters for which this speed profile is
>>> calculated.</xs:documentation>
>>> </xs:annotation>
>>> </xs:element>
>>
>> Good idea. I would spend a child element <tilting> for this and the
>> following kind of information. The attribute "angle" could be bound to
>> the railML type "tAngleDegQuadrant" for allowing 0° to 90°.
>>
>> Does a speedProfile covers only one tilting angle value or a range of
>> values or some single values?
>>
>>> <xs:element name="tiltingSpeed" minOccurs="0" maxOccurs="1">
>>> <xs:annotation>
>>> <xs:documentation>Tilting parameters for which this speed profile is
>>> calculated.</xs:documentation>
>>> </xs:annotation>
>>> </xs:element>
>>
>> The terminus "speed" may be a bit misleading. I suppose, that is not
>> related to the "train speed" but to the "rate/speed of tilting", that
>> means the value of tilting degrees per second. I would call this
>> attribute "rate". Are there any other ideas?
>>
>> This attribute may be bound to the railML type "tSpeedDegreesPerSecond".
>>
>> There is another kind of information related to the tilting that comes
>> to my mind: the method of tilting. It could go into an attribute
>> "method" that is bound to an enumeration of "active", "passive",
>> "rollCompensation", "unknown", "other:anything".
>>
>> There is already a type "tTilting" in the rollingstock subschema. We
>> should coordinate these tilting issues with Jörg von Lingen (as
>> rollingstock coordinator).
>
> Maybe we could reuse the "tTilting" type from rollingstock providing the
> attributes "maxTiltingAngle", "actuation" and "tiltingSpeed" for the
> speed profiles.
It seems to me things are mixed up. If considering "tilting" within a speed
profile then it probably refers to the permissible speed with tilting function.
However, the "tiltingSpeed" in RS, which gives the of how quick the tilting is
de-/activated, is never related to the line speed. For rolling stock it is just
a physical characteristic of the tilting mechanism.

>>> <xs:element name="monitoringSystems" type="rail:eMonitoringSystems"
>>> minOccurs="0">
>>> <xs:annotation>
>>> <xs:documentation>One of the listed monitoring systems has to be used
>>> by the trainPartSequence to use this speed profile.</xs:documentation>
>>> </xs:annotation>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>> <xs:complexType name="eMonitoringSystems">
>>> <xs:sequence>
>>> <xs:element name="MonitoringSystem" type="rail:tNationalSytemsType"
>>> minOccurs="1" maxOccurs="unbounded">
>>> <xs:annotation>
>>> <xs:documentation>type = tNationalSystemsType; Maybe it should be
>>> changed to a reference to a new base element monitoring system which would
>>> be referenced by vehicles, trainPartSequences, speedProfiles and
>>> trackElements. But also the defined types can be used as a
>>> key.</xs:documentation>
>>> </xs:annotation>
>>> </xs:element>
>>> </xs:sequence>
>>> </xs:complexType>
>>
>> That is an interesting idea. It touches Trac Ticket #111 [1].
>>
>> railML currently requires heavy repetition of obviously equal data
>> applying the <trainProtectionElement> in <ocsElements>. Thomas Albrecht
>> already pointed it out in 2009. [2] But a change of this structure
>> requires a non-downward-compatible change, that we may do with next
>> major release according to our release policy. See also Trac ticket #23
>> [3].
>>
>> If it would be a blocking issue, we may mark the current element as
>> "deprecated" and allow for a "definition list"/"library"/"catalog" of
>> train protection elements inside the <infrastructure> element.
>>
>> <trainProtectionSystem id="tpsLZB" name="LZB"
>> description="Linienförmige Zugbeeinflussung" xml:lang="de"
>> type="LZB" medium="inductive" monitoring="continuous"/>
>>
>> Along the <track> we could define the <trainProtectionElement>
>> refering to one of the "definition list elements".
>>
>> The same way we could refer to various train protection systems from
>> within a <speedProfile>.
>>
>> Does this approach also work for different ETCS levels?
>>
>> This issues should be harmonized with the rollingstock implementation
>> (tNationalSystemsType). Contact: Jörg von Lingen.
>
> There is a parallel unequal implementation of command-control-system
> elements in railML.
>
> * The Infrastructure subschema defines <trainProtectionElement>s,
> <balise>s, <trainDetector>s and <trackCircuitBorder>s.
>
> * The Rollingstock subschema defines <etcs> with
> <specificTransmissionModule> and <nationalSystem> with the same
> intentions partly using the same basic railML types.
>
Before changing everything it shall be clear what is really intended. The
monitoring in RS describes the physical features of the trainborne equipment.
The trainProtectionSystem in IS lists the systems which can be used for this
line. This may include particular features. Any train protection within a speed
profile is just a reference "permissible speed"="protection system". There is no
need for further details in here.

> I'm sure, we should harmonize this aspect regardless of the annoying
> repetition effect in the Infrastructure subschema!
>
>> [1] http://trac.assembla.com/railML/ticket/111
>> [2]
>> http://www.railml.org/web/index.php/previous-events.html?fil e=tl_files/railML.org/documents/events/slides/2009-10-06_tud resden_albrecht-interlocking.pdf
>> [3] http://trac.assembla.com/railML/ticket/23
>
> Thanks for any help and kind regards...
> Susanne
>


--
Best regards,
Joerg v. Lingen

Rollingstock Coordinator
Previous Topic: Extension of "auxiliaryBrakes"
Next Topic: Re: roles
Goto Forum:
  


Current Time: Fri Mar 29 12:31:03 CET 2024