Home » railML newsgroups » railml.rollingstock » Defining data group "leadingVehicle"
Defining data group "leadingVehicle" [message #1195] Fri, 03 September 2010 14:29 Go to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 26
Registered: November 2011
Junior Member
Dear RailML-Users,

to define vehicles some informations need to be filled in only for leading
vehicles.
So at the moment some data is grouped in monitoring as a child of engine
data.
It would be useful to create a new element "leadingVehicle" at the same
level like wagon, engine and classification.
So the information of driversCab, etcs, nationalSystem, trainRadio,
otherEquipment and the accousticSignaller could be arranged there.

<!--
-->
<!-- +-
-->
<!-- +-
-->
<!-- +-
-->
<!-- +-
-->
<!-- +-
-->
<!-- +- acousticSignaller -->
<!---->
<xs:complexType name="eLeadingVehicle">
<xs:complexContent>
<xs:extension base="rail:tMonitoring">
<xs:sequence>
<xs:element name="driversCab" type="rail:tDriversCabType" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>data about each drivers cab of the
vehicle</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="etcs" type="rail:eETCS" minOccurs="0">
<xs:annotation>
<xs:documentation>capabilities with respect to European Train Control
System</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="nationalSystem" type="rail:tNationalSystem"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>list of installed national train protection/control
systems</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="trainRadio" type="rail:eTrainRadio" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>list of installed train radio systems for
communication</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="otherEquipment" type="rail:tOtherEquipment"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>list of other (non-safety) installed train
equipment</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="acousticSignaller" type="rail:tAcousticSignaller"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>data about each drivers cab of the
vehicle</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

The data of brakes should be moved to the wagon and the data of
loadLimitMatrix would be helpful in wagon -> goods.

Informations about driven rack systems should also be positioned a the end
of ePropulsion in rollingstock.xsd

<xs:element name="rackTraction" type="rail:tRackTractionType" minOccurs="0">
<xs:annotation>
<xs:documentation>data about rack traction equipment of the
vehicle</xs:documentation>
</xs:annotation>
</xs:element>

There the type has to be defined in rollingstockTypes.xsd as seen to be seen
below:
< !--********************************************************* -- >
<!-- rackTraction -->
< !--********************************************************* -- >
<xs:complexType name="tRackTractionType">
<xs:annotation>
<xs:documentation>description of any installed rack traction
equipment</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref="rail:aRackTraction"/>
</xs:complexType>
<xs:attributeGroup name="aRackTraction">
<xs:attribute name="number" type="rail:tCounter" use="optional">
<xs:annotation>
<xs:documentation>number of cog wheels on the vehicle</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="rackSystem" type="rail:tRackSystemType" use="required">
<xs:annotation>
<xs:documentation>kind of rack system used</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="resilentCogWheel" type="xs:boolean" use="optional">
<xs:annotation>
<xs:documentation>flag, wheter the cog wheel(s) is(are) resilently
suspended</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:attributeGroup>

Also a new type for coupling should be defined in rollingstock.xsd:

<xs:element name="coupling" type="rail:tCoupling" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>data about couplings of the vehicle</xs:documentation>
</xs:annotation>
</xs:element>

That means an addition of rollingstockTypes.xsd as follows:

< !--********************************************************* -- >
<!-- Coupler -->
< !--********************************************************* -- >
<xs:complexType name="tCoupling">
<xs:annotation>
<xs:documentation>container for descriptive data of the vehicle
coupling</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref="rail:aCoupling"/>
</xs:complexType>
<xs:attributeGroup name="aCoupling">
<xs:attribute name="couplingName" type="rail:tGenericName" use="required">
<xs:annotation>
<xs:documentation>name of coupling</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="couplingHeight" type="rail:tLengthMM" use="optional">
<xs:annotation>
<xs:documentation>coupling level above top of rail</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="pullingForce" type="rail:tForceNewton" use="optional">
<xs:annotation>
<xs:documentation>maximum force to be used for pulling vehicles with this
type of coupling</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="pushingForce" type="rail:tForceNewton" use="optional">
<xs:annotation>
<xs:documentation>maximum force to be used for pushing vehicles with this
type of coupling</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:attributeGroup>

The attributeGroup aVehicle should get additional entries for
"lineClassification" and a state of the vehicle data
(rollingstockTypes.xsd).
This state should give the data user a hint to the validity of the vehicle
data.
<xs:attribute name="lineClassification"
type="rail:tLineClassificationType">
<xs:annotation>
<xs:documentation>defined line classification for this
vehicle</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="state" type="rail:tVehicleState">
<xs:annotation>
<xs:documentation>usability of the vehicle</xs:documentation>
</xs:annotation>
</xs:attribute>

< !--********************************************************* -- >
<!-- VehicleState -->
< !--********************************************************* -- >
<xs:simpleType name="tVehicleState">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="theoreticalModell"/>
<xs:enumeration value="feasibilityStudy"/>
<xs:enumeration value="manufactorOfferOrInOperation"/>
<xs:enumeration value="rightOfContinuance"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
Every propulsion system should have a name (at the beginning) to handle it
easier (rollingstockTypes.xsd).

<xs:attribute name="name" type="rail:tGenericName" use="optional">
<xs:annotation>
<xs:documentation>short name of this type of
propulsion</xs:documentation>
</xs:annotation>
</xs:attribute>pleType>

Also an information about the activation of the propulsion system should be
defined there (rollingstockTypes.xsd):

<xs:attribute name="activationStandstill" type="xs:boolean">
<xs:annotation>
<xs:documentation>propulsion system can be activated only in
standstill</xs:documentation>
</xs:annotation>
</xs:attribute>

The attribute named gearRatio as child element of tGear
(rollingstockTypes.xsd) should be used "optional".

In addition to the rotationMassFactor (aWagon in rollingstockTypes.xsd) an
"additonalRotationMass" should be available as tWeightTons:

<xs:attribute name="additionalRotationMass" type="rail:tWeightTons">
<xs:annotation>
<xs:documentation>additional mass for increased running resistance by
rotating masses of non-motored axles</xs:documentation>
</xs:annotation>
</xs:attribute>

I miss the bearingType in the attributeGroup "aWagon". Maybe it could be
added at the end of the attribute group as follows:

<xs:attribute name="bearingType" type="rail:tBearingType">
<xs:annotation>
<xs:documentation>describes the type of the bearing used for calculating
vehicle resistance</xs:documentation>
</xs:annotation>
</xs:attribute>
And the enumeration tBearingType as follows:

< !--********************************************************* -- >
<!-- bearingType -->
< !--********************************************************* -- >
<xs:simpleType name="tBearingType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="rollerBearing"/>
<xs:enumeration value="plainBearing"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="rail:tOtherEnumerationValue"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>

In ePassenger it should be possible to define more than one Gangway.

The attribute position inside the attributeGroup aGangway should be used as
optional.

It would also be helpful to define the geometric size of the gangway inside
of this attribute group. Here is an idea:

<xs:attribute name="floorLevel" type="rail:tLengthMM" use="optional">
<xs:annotation>
<xs:documentation>height of gangways floor above top of
rail</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="gangwayHeight" type="rail:tLengthMM" use="optional">
<xs:annotation>
<xs:documentation>height of gangway for passenger use</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="gangwayWidth" type="rail:tLengthMM" use="optional">
<xs:annotation>
<xs:documentation>width of gangway for passenger use</xs:documentation>
</xs:annotation>
</xs:attribute>

The enumeration tGangwayDesignType should get an extension by "sigI" and
"sigII".

The type tTilting should be defined as follows:

< !--********************************************************* -- >
<!-- Tilting -->
< !--********************************************************* -- >
<xs:complexType name="tTilting">
<xs:annotation>
<xs:documentation>data for tilting mechanism of passenger
cars</xs:documentation>
</xs:annotation>
<xs:attributeGroup ref="rail:aTilting"/>
</xs:complexType>
<xs:attributeGroup name="aTilting">
<!-- Carsten -->
<xs:attribute name="actuation" type="rail:tTiltingActuationType"
use="required">
<xs:annotation>
<xs:documentation>way of actuating the carbody tilting
(active/passive)</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="maxTiltingAngle" type="rail:tAngleDegQuadrant">
<xs:annotation>
<xs:documentation>maximum tilting angle in degrees</xs:documentation>
</xs:annotation>
</xs:attribute>
<!-- /Carsten -->
<xs:attribute name="tiltingSpeed" type="rail:tSpeedDegreesPerSecond">
<xs:annotation>
<xs:documentation>speed of changing the tilting angle in degrees per
second</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:attributeGroup>

I also added an attribute "loadArea" above the volume inside of the
attributeGroup "aGoods".

I hope it is not too much for one post.

Thanks.

Carsten.
Re: Defining data group "leadingVehicle" [message #1196 is a reply to message #1195] Sun, 12 September 2010 16:12 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 59
Registered: May 2011
Member
On 03.09.2010 14:29, Carsten Weber wrote:
> Dear RailML-Users,
>
> to define vehicles some informations need to be filled in only for leading
> vehicles.
> So at the moment some data is grouped in monitoring as a child of engine
> data.
> It would be useful to create a new element "leadingVehicle" at the same
> level like wagon, engine and classification.
> So the information of driversCab, etcs, nationalSystem, trainRadio,
> otherEquipment and the accousticSignaller could be arranged there.
>

There are quite some situations taking advantage of the proposed new
substructure "leadingVehicle". However, it violates the principles of data
hierarchy used in rolling stock data.

It is the intention to provide a data structure for the technical data and
characteristics of any rolling stock independent of the particular use case of a
train running in the network. "leadingVehicle" is an expression of such a
particular use case as a vehicle becomes a leading one only on a particular
train configuration.

The original idea of "engine" was put in all data of the active parts
(propulsion etc) one would find in any loco. The child "monitoring" is, however,
morphodite being in locos and non-driven cars with drivers cab.

The "wagon" shall take all data related to the interior and its equipment, which
is not related to the propulsion.

The question is whether such a radical structure change is really useful?
--
Mit freundlichen Grüßen/Best regards,
-------------------------------------
Jörg von Lingen
Re: Defining data group "leadingVehicle" [message #1197 is a reply to message #1196] Tue, 28 September 2010 10:11 Go to previous messageGo to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 26
Registered: November 2011
Junior Member
"Joerg von Lingen" <joergvon_lingendd(at)t-onlinede> schrieb im Newsbeitrag
news:i6i65j$5qi$1(at)sifaivifhgde...
> On 03.09.2010 14:29, Carsten Weber wrote:
>> Dear RailML-Users,
>>
>> to define vehicles some informations need to be filled in only for
>> leading
>> vehicles.
>> So at the moment some data is grouped in monitoring as a child of engine
>> data.
>> It would be useful to create a new element "leadingVehicle" at the same
>> level like wagon, engine and classification.
>> So the information of driversCab, etcs, nationalSystem, trainRadio,
>> otherEquipment and the accousticSignaller could be arranged there.
>>
>
> There are quite some situations taking advantage of the proposed new
> substructure "leadingVehicle". However, it violates the principles of data
> hierarchy used in rolling stock data.
>
> It is the intention to provide a data structure for the technical data and
> characteristics of any rolling stock independent of the particular use
> case of a
> train running in the network. "leadingVehicle" is an expression of such a
> particular use case as a vehicle becomes a leading one only on a
> particular
> train configuration.
>
I think there is a missunderstanding. The data group "leadingVehicle" should
include all the data which is relevant when the vehicle is used as a leading
vehicle. It is of course not possible to define in the vehilce data, that
this vehicle is a leading vehicle in the current formation of the train.
This is not the intention to define the "leadingVehicle" data group.

Best regards.

Carsten
Re: Defining data group "leadingVehicle" [message #1200 is a reply to message #1195] Fri, 22 October 2010 08:03 Go to previous messageGo to next message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 59
Registered: May 2011
Member
With respect to the proposed restructuring two potential variants were presented on RailML meeting
on 19. October 2010. Refer
http://www.railml.org/web/index.php/veranstaltungsarchiv.htm l?file=tl_files/railML.org/documents/events/slides/2010-10-1 9_ifb_lingen-rollingstock.pdf

This shall be part of a future version 3.0 of the schema. Please review the proposals and provide
any feedback. Thanks.

Carsten Weber wrote:
> Dear RailML-Users,
>
> to define vehicles some informations need to be filled in only for leading
> vehicles.
> So at the moment some data is grouped in monitoring as a child of engine
> data.
> It would be useful to create a new element "leadingVehicle" at the same
> level like wagon, engine and classification.
> So the information of driversCab, etcs, nationalSystem, trainRadio,
> otherEquipment and the accousticSignaller could be arranged there.
>
--
Mit freundlichen Grüßen/Best regards,
-------------------------------------
Jörg von Lingen
Re: Defining data group "leadingVehicle" [message #1201 is a reply to message #1200] Fri, 22 October 2010 11:12 Go to previous messageGo to next message
Carsten Weber is currently offline  Carsten Weber
Messages: 26
Registered: November 2011
Junior Member
Dear RailML-Users,

I would prefer the first proposal.
The second proposal assumes a drivers cab as a requirement for a leading
vehicle.
There are cases, where leading vehicles do not have a drivers cab.
You can see an example at
http://www-users.rwth-aachen.de/christoph.schmitz2/signale/s ignale_rwe.html
(german only).
But there are also other examples like fully automated underground trains.

In both cases I would like to rename "otherEquipment" to "deadManControl" or
adding "deadManControl" and keeping "otherEquipment" free for other cases
like "EBuLa".

Best regards.

Carsten Weber
Re: Defining data group "leadingVehicle" [message #1202 is a reply to message #1201] Wed, 03 November 2010 09:15 Go to previous message
Joerg von Lingen is currently offline  Joerg von Lingen
Messages: 59
Registered: May 2011
Member
Carsten Weber wrote:
> There are cases, where leading vehicles do not have a drivers cab.
> You can see an example at
> http://www-users.rwth-aachen.de/christoph.schmitz2/signale/s ignale_rwe.html
> (german only).
> But there are also other examples like fully automated underground trains.

Just two comments:
1) First scenario with pushed mining trains - no cab on leading vehicle but also no ATP equipment or
so, just an ordinary freight car with battery head lights

2) Second scenario with automated underground trains - at least most of such vehicles have an
auxiliary drivers position instead for shunting purpose

--
Mit freundlichen Grüßen/Best regards,
-------------------------------------
Jörg von Lingen
Previous Topic: Data for maintenance intervals - info needed
Next Topic: Wording of weight attributes
Goto Forum:
  


Current Time: Sat Jul 22 14:55:32 CEST 2017