Forum: railml.common » Suggested refined definitions and extension to organizationalUnits

Home » railML newsgroups » railml.common » Suggested refined definitions and extension to organizationalUnits (CO:organizationalUnits)

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Mon, 10 February 2020 15:25

Torben Brand
Messages: 165
Registered: March 2016

Senior Member

For a clearer use of organisational units the Norwegian railway sector recommends to further refine the existing definitions to make them more clear and to introduce on extension.
There are 8 fixed types of organisations in railML2:
• infrastructureManager
• vehicleManufacturer
• vehicleOperator
• customer
• railwayUndertaking
• operationalUndertaking
• concessionaire
• contractor

We suggest extending railML2.5 with a new sub element/type "vehicleOwner" and to allow extensions with <any> element.

I tried to find some background information in the forum, but only found this string without any clear definitions: https://www.railml.org/forum/index.php?t=msg&th=348& goto=1102&#msg_1102

We would like to ask the community how they define the 8 types of organisations. To start the discussion, we suggest the following definition improvements of the terms:

organisationalUnits
Semantics:
Container element for pre-defining organizational units, that will be referred from within the railML file.
Organisational units are railway related organisations that can be a government authority, local authority, corporation, enterprise, public company, private company, undertaking/body or other legal entity.
Each element may be used several times for several entries, as e.g. a network may be divided into areas with different infrastructure managers, and as within the network there will usually move vehicles from different producers. Every element entry within this container has, at least, an attribute name plus an attribute id. It can be addressed via this id from certain other places within the railML®-file
Notes:
Note that as in railML2 the type of organisation is declared by the element. So, you need to register the same organisation in each relevant element if it has more than one role.

infrastructureManager
Semantics:
An organisation that is responsible for establishing and maintaining railway infrastructure, which may also include the management of infrastructure control and safety systems. The functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or undertakings.
Via code it can be linked to the codelist infrastructureManagers.xml, where numerous infrastructure managers are listed.

vehicleManufacturer
Semantics: An organisation that produces railway vehicles.

vehicleOperator
Semantics: An organisation responsible for operating the railway vehicle on behalf of a railway undertaking (usually as a sub-contractor).

Customer
Semantics: An organisation that orders transportation service from a railway undertaking. The customer can have exclusive transportation ownership rights (concessions) or operate on open access.

railwayUndertaking
Semantics: An organisation, licensed according to applicable legislation, which principal business is to provide services for the transport of goods and/or passengers by rail with a requirement that the undertaking must ensure traction and is commercially responsible for the service.

operationalUndertaking
Semantics: An organisation responsible for the operational performance of a railway undertakings service (usually as a sub-contractor). Examples are organisations responsible for catering, cleaning or vehicle maintenance.

Concessionaire
Semantics: A <railwayUndertaking> that has received and operates under a concession from a <customer>.

Forum note: As this is over specific and the UC is not clear, we suggest deprecating this element. If there is a need for the contract status between customer or railway undertaking, that should be mapped in a separate construct.

Contractor
Semantics: Any relevant organisation not fitting to the other sub elements of <organisationalUnits>

vehicleOwner [new]
Semantics: An organisation which purpose is to make railway vehicles available for railway undertakings.

Report message to a moderator

Thu, 13 February 2020 13:49

Thomas Nygreen
Messages: 78
Registered: March 2008

Member

Dear Torben,
Dear all,

I don't know why Torben's link did not become clickable, so I'll try to post it again, as well as the related trac issue:
Forum: https://www.railml.org/forum/index.php?t=msg&goto=1102
Trac: https://trac.railml.org/ticket/178

I have not found any further context, and in the old forum thread a "vehicleOwner" value was also suggested, but it was apparently not included at the end. Are there anyone in the community who can provide (best practice) examples of current usage? Would Torben's suggestions break any current functionality?

In addition to Torben's suggested changes, I would as if we really need both <railwayUndertaking>, <vehicleOperator> and <operationalUndertaking>. I propose to also deprecate at least one of the last two. Again, please comment!

Best,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Thu, 26 March 2020 13:33

Dirk Bräuer
Messages: 313
Registered: August 2008

Senior Member

Dear Thomas, Torben and all others,

some time ago I agreed to read the documentation [1] of DB Netz AG (German Infrastructure Manager) on their planned Slot ordering data format concerning how they use what in railML would be "organisationalUnits". Here a short summary (with my own additions and translation):

LeadRU
de: Führendes/Koordinierendes EVU
en: leading or coordinating RU

Responsible Applicant
de: Besteller, Vertragspartner
en: ordering contractor (not necessarily a RU)

ResponsibleRU
de: die Zugfahrt durchführendes EVU
en: RU operating the train

PlanningIM
de: fahrplanerstellendes EIU
en: IM creating (responsible for) the timetable

ResponsibleIM
de: für die betriebliche Durchführung der Zugfahrt verantwortliches EIU; Eigentümer der Infrastruktur
en: IM responsible for operating the train = owner of infrastructure

DB Netze says this is harmonised with ERA concerning TAF/TAP. So this may be general. But I think it still could change
only time can show how other IM use this. So far, I would regard it as a German view.

What I miss is:
- No distinguishing between "ResponsibleRU" (as above), RU which owns the vehicle(s) and RU which contributes the driver.

I don't know whether this helps us, but we should keep it in mind because there is a chance that this will become "best practice" in the catchment area of ERA. May be it's ok if we produce an "assign-list" of railML values to these German/ERA values? May be a list which can be extended later with values or best practice of other countries?

Can anybody prepare this?

Best regards,
Dirk.

[1] DB Netze: Dokumentation der Schnittstelle des Bestellsystems der DB Netz für EVU-Systeme. Gültig ab Netzfahrplan 2024. Version 4.1.1, last update 25.02.2020.

Report message to a moderator

Thu, 26 November 2020 06:46

Thomas Nygreen
Messages: 78
Registered: March 2008

Member

Dear all,

We have a new trac ticket for this request: https://trac.railml.org/ticket/435

In addition to adding the <vehicleOwner> elements requested by Norway, it would be natural to add an <owner> child of the rolling stock vehicle <classification> element.

One thing I noted when looking at the current implementation is that the different types of organisational units are very restricted with key/keyref constraints. Specifically, the vehicle operator classification in RS can only reference a vehicleOperator, not a railwayUndertaking. The consequence is that some organisations have to be specified multiple times, one time for each role. This is hard to change without breaking minor version compatibility, so we will have to live with it in railML 2.

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Thu, 26 November 2020 16:29

Christian Rößiger
Messages: 63
Registered: March 2015

Member

Hello everyone,

in general, I agree that there is currently no possibility in railML to
indicate an owner of the vehicles of a <trainPart> and would therefore
support an extension.

Am 26.11.2020 um 06:46 schrieb Thomas Nygreen:
> Dear all,
>
> We have a new trac ticket for this request:
> https://trac.railml.org/ticket/435
>
> In addition to adding the <vehicleOwner> elements requested
> by Norway, it would be natural to add an <owner> child of
> the rolling stock vehicle <classification> element.

I would rather implement only one of the <vehicleOwner> references below
<trainPart> or <vehicle> and instead of both.

The reference to a <vehicleOwner> from a <trainPart> has the problem
that a <trainPart> may consist of vehicles with different owners, but
only one <vehicleOwner> can be specified per <trainPart>. In this case
separate <trainPart>s would have to be created for each owner. This is
not a new problem, however, but applies analogously to the existing
<vehicleOperator> reference of the <trainPart>.

Defining the <owner> directly at the <vehicle> avoids this problem, but
separate <vehicle>s would have to be defined for all owners of a vehicle
class. In order not to specify too much redundant data, the physical
data of the vehicle and the <owner> or <operator> assignments could be
defined as separate <vehicle>s and mutually referenced with the
attribute 'vehicleFamilyRef' (see example below).

I would prefer the second variant because it seems to be more flexible.
In this case one could consider to declare the <vehicleOperator> element
of the <trainPart>s as deprecated.

Best Regards
Christian Rößiger

--- Example ---

<vehicle id='veh_1' description='This is the physical vehicle class'
speed='160', length='22.50'>
<classification>
<manufacturer vehicleManufacturerRef='vm_1' manufacturerType='XX.XX' />
</classification>
</vehicle>

<vehicle id='veh_2' description='first owner, first operator'
vehicleFamilyRef='veh_1'>
<classification>
<operator vehicleOperatorRef='vop_1' operatorClass='YY.YY' />
<owner ownerRef='vow_1' />
</classification>
</vehicle>

<vehicle id='veh_3' description='second owner, second operator'
vehicleFamilyRef='veh_1'>
<classification>
<operator vehicleOperatorRef='vop_2' operatorClass='ZZ.ZZ' />
<owner ownerRef='vow_2' />
</classification>
</vehicle>

Comment: 2nd and 3rd <vehicle> do reference the 1st one which contains
the physical data. 2nd and 3rd <vehicle> serve only as assignment of a
certain <operator> and <owner> to a physical vehicle class.

--
iRFP e. K. · Institut für Regional- und Fernverkehrsplanung
Hochschulstr. 45, 01069 Dresden
Tel. +49 351 4706819 · Fax. +49 351 4768190 · www.irfp.de
Registergericht: Amtsgericht Dresden, HRA 9347

Report message to a moderator

Fri, 27 November 2020 06:02

Joerg von Lingen
Messages: 149
Registered: May 2011

Senior Member

Dear all,

as I am not timetable specialist I don't see the need of having the vehicle owner in TT.

In my opinion the vehicle owner is something rather static which is related to the vehicle (the property). Of course, a
formation of vehicles might consist of vehicles of different owners.
In TT I would see only the need to know the trainPart operator, which might be different from the owner and which might
be more dynamic than the ownership.

This reflects the typical market situation of
a) Rolling stock leasing companies (ROSCOs) giving lease to operators
b) Train operating companies (TOCs) operating the train service

--
Regards,
Jörg von Lingen - Rollingstock Coordinator

Report message to a moderator

Wed, 09 December 2020 12:39

Milan Wölke
Messages: 150
Registered: April 2007

Senior Member

I agree with Jörg and Christian. Seems to me that vehicleOwner is better placed on the vehicle level than on the timetable. Would that work for you @Torben Brand?

Best regards, Milan

Milan Wölke – Timetable scheme coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

Report message to a moderator

Thu, 14 January 2021 15:18

Torben Brand
Messages: 165
Registered: March 2016

Senior Member

Yes, I agree with Thomas, Christian, Jörg and Milans comments in this post,
placing the reference to the <vehicleOwner> on the vehicle level as a new <owner> sub element under <classification> as described very well in Christians example above.

Report message to a moderator

Thu, 14 January 2021 15:30

Torben Brand
Messages: 165
Registered: March 2016

Senior Member

Thank you Dirk for providing the DB Netz list of types of "organisational units" for slot ordering.

I have also received documentation from ERA for the definition of organisational units for TAF/TAP. Thank you Stefan Jugelt for providing the information!

NB! This forum post was initially meant to only define the exisiting organisational Units terms in railML2 in a more precise manner. This new information bellow can lead to a complete redesign of the organisational units. This is not a bad thing. But I reccomend doing this in railML3.

The actors of the TAF TSI are defined in the chapter 1.6 of the TAF TSI Technical document TAF TSI - ANNEX D.2 : APPENDIX C - REFERENCE FILES ( https://www.era.europa.eu/sites/default/files/filesystem/taf /technical_documents/baseline_2.5.0/era_technical_document_t af-td-103_d_2_appendix_c.pdf )

Here is the definition for the different types of actors addressed in the TAF TSI:

"COMPANY" ACTOR
Company identifies any actor in the transport chain, notably any Company, directly or indirectly involved in rail traffic or having a business relationship with one or more of such companies not being a customer. The definition of Company comprehends the following as defined in the TAF-TSI.
- Customer;
- IMPartner;
- NextResponsibleIM;
- NextResponsibleRU;
- Recipient;
- ResponsibleIM;
- ResponsibleRU,
- PreviousResponsibleRU;
- RUPartner;
- Sender.

It specialises the actor Partner.

1.6.3 "CUSTOMER" ACTOR
Customer is the entity which has issued the consignment note to the Lead RU.

1.6.4 "DELIVERY RU" ACTOR
The RU responsible for delivery to the customer It specialises the actor RailwayUndertaking.

1.6.5 "FLEETMANAGER" ACTOR
The fleet manager is the overall controller of a wagon fleet. Primarily a fleet manager controls the logistics of wagons (dispatching / disposition) from an operational and asset management point of view. It specialises the actor RollingStockActor.

1.6.6 "COMBINED TRANSPORT OPERATOR" ACTOR
Party which organises Intermodal transports. Intermodal transport is where the major part of the European journey is by rail and any initial and/or final leg is carried out by another transport mode. It specialises the actor Company.

1.6.7 "INFRASTRUCTURE MANAGER" ACTOR
Infrastructure Manager means anybody or undertaking that is responsible, in particular, for establishing and maintaining railway infrastructure. This may also include the management of infrastructure control and safety systems. The functions of the infrastructure manager on a network or part of a network may be allocated to different bodies or undertakings

1.6.8 "KEEPER" ACTOR
The entity, who being the owner or having the right to dispose of it, exploits a vehicle economically in a permanent manner as a means of transport and is registered as such in the Rolling Stock Register. A railway undertaking owning wagons equally has the role of keeper. It specialises the actor RollingStockActor.

1.6.9 "LEAD RU" ACTOR
Responsible RU, which organises and manages the transport line according to the customer's commitment. It is the single point of contact for the customer. If more than one Railway Undertaking is involved in the transport chain, the LRU is responsible for the co-ordination of the various Railway Undertakings. A customer may be especially for Intermodal transport an Intermodal service integrator. The LeadRU is a service integrator. It specialises the actor RailwayUndertaking.

1.6.10 "RESPONSIBLE RU" ACTOR
RU responsible for the current operation of the train It specialises the actor RailwayUndertaking.

1.6.11 "ORIGIN RU" ACTOR
The first RU in the rail transportation chain It specialises the actor RailwayUndertaking.

1.6.12 "RAILWAY UNDERTAKING" ACTOR
RailwayUndertaking is a company defined as any public or private undertaking, licensed according to applicable Community legislation, the principal business of which is to provide services for the transport of goods and/or passengers by rail (including shipping companies, covered by international railway tariffs). A requirement is that the undertaking shall ensure traction; this also includes undertakings which provide traction only.

1.6.13 "RESPONSIBLE IM" ACTOR
IM responsible for the train currently operating on its infrastructure It specialises the actor InfrastructureManager.

1.6.14 "NEXT RESPONSIBLE IM" ACTOR
Handover IM - It specialises the actor InfrastructureManager.

1.6.15 "NEXT RESPONSIBLE RU" ACTOR
RU responsible for the physical movement of the train after interchange It specialises the actor RailwayUndertaking.

1.6.16 "PUBLIC AUTHORITY" ACTOR
Authority as an applicant is a legalised authority having an interest in public transport services. Authority is a legalised institution having an interest in the transport.
It specialises the actor Applicant, OtherActor.

1.6.17 "PREVIOUS RESPONSIBLE RU" ACTOR
RU responsible for the physical movement of the train before the previous interchange. It specialises the actor RailwayUndertaking.

1.6.18 "TRANSIT RU" ACTOR
The RU who involved in the interchange
It specialises the actor RailwayUndertaking.

1.6.19 "TRANSPORT CUSTOMER" ACTOR
Defines the railway customer - the Consignor or Consignee in the case of the TSI-TAF.

1.6.20 "ROLLINGSTOCK ACTOR" ACTOR
The Keeper, Wagon Owner or Fleet Manager It specialises the actor Company.

1.6.21 "SERVICEI NTEGRATOR" ACTOR
Service Integrator organises the transport chain between Consignor and Consignee. The LeadRU is a ServiceIntegrator.
It specialises the actor Applicant, OtherActor.

1.6.22 "OTHER ACTOR" ACTOR
OtherActor involved in the Rail-Transport-Chain is any company or authority, directly or indirectly involved in rail traffic or having a business relationship with one or more of such companies.
It specialises the actor Partner.

1.6.23 "WORKSHOP" ACTOR
An approved organisation accredited to build, repair and/or maintain vehicles. It specialises the actor OtherActor.

Report message to a moderator

Mon, 01 February 2021 15:56

Thomas Nygreen
Messages: 78
Registered: March 2008

Member

Thank you, Torben, for providing this background. I see a potential and a need for a restructuring beyond just adding a vehicle owner, but that will be a railML 3 enhancement, as it would change the implementation too much for railML 2.

In line with the apparent consensus here, I have removed the new organizationalUnitBinding in TT from the proposed solution in the trac ticket and commited an update for the XSDs as a branch in SVN (diff available in trac when logged in).

Best regards,
Thomas

Thomas Nygreen – Common Schema Coordinator
railML.org (Registry of Associations: VR 5750)
Altplauen 19h; 01187 Dresden; Germany www.railML.org

[Updated on: Mon, 01 February 2021 15:57]

Report message to a moderator

Previous Topic:	Where to place a "comment" value?
Next Topic:	[all versions] Using sequences in XSD schemas

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Sun Nov 03 20:39:07 CET 2024