| Harmonization with infrastructure aspects [message #1210] |
Thu, 05 January 2012 13:25  |
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
|
|
|
|
Members
Search
Help
Login
Home
