NeTEx: how to link a ServiceJourney to an Equipment ID?

[clairecarnot]

Hello,

I have a modelling question about the NeTEx Transport Plan.

I would like to link each service in my NeTEx Transport Plan to its equipment.

In my business model:

• a service is identified by: operator + train number + departure date;
• an equipment represents the vehicle composition of the transport mode used for that service (for example, for a train: a sequence of carriages, each with a specific seat layout). Each equipment has a unique identifier.

I cannot figure out which NeTEx structure I should use to link these two objects in the Transport Plan.
Without this link, this information is lost as soon as I import or export a transport plan in NeTEx format.

So my questions are:

1. Where should I publish the catalog of these equipment IDs (recommended file/frame)?
2. What linking chain is expected to connect services to their equipment IDs (e.g. ServiceJourney -> ... -> Equipment, or another pattern)?

Thank you very much!

[skinkie]

What you describe as equipment is not Equipment (Elevator, Escalator, etc.) in the NeTEx terminology. You want to describe the relationship towards a specific Vehicle.

In the VehicleScheduleFrame a relationship is made via Blocks between the generic VehicleType (a vehicle of the same group, with the same properties) or a Train.

NeTEx does allow for a direct relationship between a VehicleJourney (and ServiceJourney) and a specific Vehicle via VehicleRef. But keep in mind that would entail that the plan likely denormalises all journeys, into individual instances, and is not something you would find in travel information or ease of use within a journey planner.

[clairecarnot]

Hello,

Thank you for your answer !

You are right, I think we can make 2 simple additions to get the info (cf Netex_11_Rail_CompoundTrain.xml):
ServiceJourney -> TrainRef
ResourceFrame -> vehicleTypes + Train (with the ID of the vehicule (='equipment' in our terminology))
cf simplified structure :

<frames>
  <ResourceFrame>
    <vehicleTypes>
      <Train id="12345"/>
    </vehicleTypes>
  </ResourceFrame>

  <TimetableFrame>
    <vehicleJourneys>
      <ServiceJourney>
        <TrainRef ref="12345">
      </ServiceJourney>
    </vehicleJourneys>
  </TimetableFrame>
</frames>

It would be a simple way not to lose the vehicule info between import/export. I keep in mind the warning about multiplicating the ServiceJourneys though.
Thanks again and have a nice day !

[skinkie]

Just understand if you do it in the way you write here above. Your ServiceJourney and TrainRef are always connected. This may not be the case, therefore the Block relation allows you to schedule the composition independently. If it is the case the example is really good, because now a journey planner can always trust the assigned Train, regardless of vehicle scheduling.

[hfjelstad]

I would like to join in, because this is a very complicated issue. I will try my best to contribute without confusing to much =P

I would recommend ServiceJourney <- "LinkingObject(s)" -> Vehicle
In Norway we use ServiceJourney <- DatedServiceJourney -> TrainBlock -> Train / CompoundTrain

DatedServiceJourney / DatedVehicleJourney id represent the whole "operator + train number + departure date"
There are often two types of train number, either the operational trainnumber (PrivateCode) and the commercial trainnumber (PublicCode)

I could help with making a valid example if you had a concrete case or i can strip down a Norwegian one

[clairecarnot]

Hello,

Of course, I would gladly take any help! 😄

I am not entirely sure what kind of example to provide when you say “if you had a concrete case”. Maybe we could directly look at a Norwegian example, and that might make things clearer?

To give you more context:

We are currently following the European + French profiles.
Our use case is more operational-oriented than passenger-information-oriented, which is why the association between services and rolling stock is important for us.

So my original request was to understand how to make a simple and direct link between a service and the rolling stock operating it, because this information is currently missing from our NeTEx imports/exports. But I do not have a predefined idea of how this should be modelled.

The French profile does not seem settled on this topic yet : it contains very limited information regarding vehicules (= our 'equipment'). I asked the same question on their GitHub about how to model this, and they redirected me towards 'VehicleType' and 'Train' elements, which is very simple and direct, but might evolve with their next version.
They did not mention 'VehicleScheduleFrame' (but as I understand it, there are no specialized frames yet for this profile), 'Block' elements, 'DatedServiceJourney', or 'DatedVehicleJourney'.
So this is why I initially went for the simplest approach, although I am not sure it is the best one :)

[hfjelstad]

🚂 Rolling Stock — Linking Services to Trains

1. 🎯 Introduction

vehicle /ˈviːɪk(ə)l/ noun
A thing used for transporting people or goods, especially on land, such as a car, lorry, or cart.
— Oxford English Dictionary

In railway NeTEx, a "vehicle" is not a single atomic thing. A train departing Bergen for Oslo may consist of an electric locomotive, four passenger carriages, a rest car, and three additional coaches — all coupled together into a single formation that operates as one unit.

This guide explains how NeTEx models this reality: from the abstract service the passenger sees, through the dated operational assignment, down to the physical composition of the train.

In this guide you will learn:

• 🔗 The full linking chain from ServiceJourney to physical rolling stock
• 🚃 How Train, CompoundTrain, and TrainElement model formations
• 📦 How TrainBlock and TrainBlockPart assign formations to journeys
• 🎫 Train identity: PublicCode vs Operational Train Number
• 📋 A complete validated XML example based on real Norwegian rail data

---

2. 🔗 The Full Linking Chain

The path from "passenger sees departure at 06:19" to "locomotive El 18 + 9 carriages" traverses several objects across multiple frames:

graph TD
  %% ── TimetableFrame ──────────────────────────────────────────
  subgraph TimetableFrame["🕐 TimetableFrame"]
    SJ["<b>ServiceJourney</b><br/><i>Train 60 BRG→OSL</i><br/>pattern + times"]
    DSJ["<b>DatedServiceJourney</b><br/><i>Train 60 on 2026-04-14</i>"]
  end

  %% ── VehicleScheduleFrame ────────────────────────────────────
  subgraph VehicleScheduleFrame["📦 VehicleScheduleFrame"]
    TB["<b>TrainBlock</b><br/><i>Block for train 60</i><br/>StartTime · EndTime<br/>StartPoint · EndPoint"]
    TBP["<b>TrainBlockPart</b><br/>order=1"]
  end

  %% ── ResourceFrame ──────────────────────────────────────────
  subgraph ResourceFrame["🔧 ResourceFrame · vehicleTypes/"]
    CT["<b>CompoundTrain</b><br/><i>Full consist</i>"]
    T1["Train: El 18 Vest<br/><i>locomotive</i>"]
    T2["Train: Coaches 1–4<br/><i>A7, B7, BC7, B7</i>"]
    T3["Train: Hvilevogn<br/><i>rest car</i>"]
    T4["Train: Coaches 5–8<br/><i>FR7, B7, B7</i>"]
    TE["<b>TrainElement</b><br/>engine · carriage"]
  end

  %% ── Links ──────────────────────────────────────────────────
  DSJ -->|ServiceJourneyRef| SJ
  DSJ -->|"<b>TrainBlockRef</b>"| TB
  TB -->|blockParts| TBP
  TBP -->|"<b>CompoundTrainRef</b>"| CT
  CT -->|"order=1"| T1
  CT -->|"order=2"| T2
  CT -->|"order=3"| T3
  CT -->|"order=4"| T4
  T1 -->|TrainElementRef| TE
  T2 -->|TrainElementRef| TE
  T3 -->|TrainElementRef| TE
  T4 -->|TrainElementRef| TE

Loading

Summary Table

Object	Frame	Role	Key References
ServiceJourney	TimetableFrame	Pattern + times (template)	JourneyPatternRef, LineRef, parts/JourneyPart
DatedServiceJourney	TimetableFrame	Date-specific instance	ServiceJourneyRef, OperatingDayRef, TrainBlockRef
TrainBlock	VehicleScheduleFrame	Vehicle duty (reusable template)	StartPointRef, EndPointRef, blockParts
TrainBlockPart	(inside TrainBlock)	Segment with one formation	CompoundTrainRef, journeyParts
CompoundTrain	ResourceFrame	Full train consist	components/TrainInCompoundTrain
Train	ResourceFrame	Logical sub-unit (e.g. coach set)	components/TrainComponent
TrainElement	ResourceFrame (vehicles/)	Single physical wagon/engine	TrainElementType

---

3. 🚃 Train Composition Model

NeTEx uses a three-level hierarchy for train formations:

Level 1: TrainElement — The Physical Unit

A TrainElement represents a single indivisible unit: one locomotive, one carriage, one power car. It lives in ResourceFrame/vehicles/:

<TrainElement version="0" id="VYG:TrainElement:EL_18">
  <Name>Elektrisk lokomotiv type 18</Name>
  <TrainElementType>engine</TrainElementType>
</TrainElement>

<TrainElement version="0" id="VYG:TrainElement:B7-4">
  <Name>Personvogn type 7 B7-4</Name>
  <TrainElementType>carriage</TrainElementType>
</TrainElement>

Level 2: Train — A Logical Group

A Train groups one or more TrainElements into a coupled unit (e.g. a locomotive, a coach set, or a single railcar). It lives in ResourceFrame/vehicleTypes/:

<Train version="0" id="VYG:Train:18_V">
  <Name>El 18 Vest</Name>
  <Description>EL18 lok dedikert trafikkpakke 3 Vest</Description>
  <TypeOfFuel>electricity</TypeOfFuel>
  <components>
    <TrainComponent order="1" version="0" id="VYG:TrainComponent:18_V_1">
      <TrainElementRef ref="VYG:TrainElement:EL_18" version="0"/>
      <OperationalOrientation>backwards</OperationalOrientation>
    </TrainComponent>
  </components>
</Train>

Level 3: CompoundTrain — The Full Consist

A CompoundTrain composes multiple Trains into the actual formation running on the track. It is the object referenced by TrainBlockPart:

<CompoundTrain version="0" id="VYG:CompoundTrain:60_BRG-OSL">
  <Description>El 18 + 4 coaches + rest car + 3 coaches</Description>
  <components>
    <TrainInCompoundTrain order="1" version="0" id="VYG:TrainInCompoundTrain:60_1">
      <TrainRef ref="VYG:Train:18_V" version="0"/>
    </TrainInCompoundTrain>
    <TrainInCompoundTrain order="2" version="0" id="VYG:TrainInCompoundTrain:60_2">
      <TrainRef ref="VYG:Train:Coaches_1-4" version="0"/>
    </TrainInCompoundTrain>
    <TrainInCompoundTrain order="3" version="0" id="VYG:TrainInCompoundTrain:60_3">
      <TrainRef ref="VYG:Train:RestCar" version="0"/>
    </TrainInCompoundTrain>
    <TrainInCompoundTrain order="4" version="0" id="VYG:TrainInCompoundTrain:60_4">
      <TrainRef ref="VYG:Train:Coaches_5-7" version="0"/>
    </TrainInCompoundTrain>
  </components>
</CompoundTrain>

Note

The order attribute defines the physical position in the train from front to back. This is critical for seat reservation systems and platform positioning.

---

4. 📦 TrainBlock and TrainBlockPart

TrainBlock — The Operational Duty

A TrainBlock represents what a physical train set does on a journey. It is reusable across dates — the date binding comes from DatedServiceJourney's OperatingDayRef. It groups journey segments and defines when and where the duty starts and ends:

<TrainBlock version="0" id="VYG:TrainBlock:60_BRG-OSL">
  <StartTime>06:19:00</StartTime>
  <EndTime>13:05:00</EndTime>
  <StartPointRef ref="VYG:ScheduledStopPoint:BRG"/>
  <EndPointRef ref="VYG:ScheduledStopPoint:OSL"/>
  <blockParts>
    <TrainBlockPart order="1" version="0" id="VYG:TrainBlockPart:60_BRG-OSL_1">
      <CompoundTrainRef ref="VYG:CompoundTrain:60_BRG-OSL"/>
      <journeyParts>
        <JourneyPartRef ref="VYG:JourneyPart:60_BRG-OSL_1" version="0"/>
      </journeyParts>
    </TrainBlockPart>
  </blockParts>
</TrainBlock>

Why TrainBlockPart?

A train's formation may change during a block (coupling/uncoupling at intermediate stations). Each TrainBlockPart represents a segment with a constant formation:

Block for train 601 (Oslo → Bergen):
  Part 1: Oslo → Hønefoss    (8 coaches)    ← CompoundTrainRef A
  Part 2: Hønefoss → Bergen  (6 coaches)    ← CompoundTrainRef B  (2 uncoupled)

Tip

If the formation doesn't change during the journey, a single TrainBlockPart is sufficient. This is the most common case.

---

5. 🎫 Train Identity — Commercial vs Operational

A train has two identities:

Identity	What	Where	Owner
Commercial (passenger-facing)	"Tog 60"	PublicCode on ServiceJourney	Timetable team
Operational (dispatch/infra)	"4060"	privateCodes/PrivateCode type="OperationalTrainNumber" on TrainBlockPart	Operations team

The operational train number (OTN) belongs on TrainBlockPart because:

• It can vary per segment (infrastructure boundaries, crew handover)
• It can vary per date (TrainBlock is day-specific)
• It is operational data (VehicleScheduleFrame), not public timetable data
• It binds naturally to the physical movement: "this formation, on this segment, on this day, is known as 4060"

<!-- TimetableFrame: passenger-facing identity -->
<ServiceJourney version="1" id="VYG:ServiceJourney:60-BRG_East">
  <Name>Tog 60</Name>
  <PublicCode>60</PublicCode>
  ...
</ServiceJourney>

<!-- VehicleScheduleFrame: operational identity per segment -->
<TrainBlockPart order="1" version="1" id="VYG:TrainBlockPart:60_BRG-OSL_1">
  <privateCodes>
    <PrivateCode type="OperationalTrainNumber">4060</PrivateCode>
  </privateCodes>
  <CompoundTrainRef ref="VYG:CompoundTrain:60_BRG-OSL" version="1"/>
  <journeyParts>
    <JourneyPartRef ref="VYG:JourneyPart:60_BRG-OSL" version="1"/>
  </journeyParts>
</TrainBlockPart>

Note

The NeTEx XSD also provides a dedicated TrainNumber object with ForAdvertisement/ForProduction. This adds indirection without value — PublicCode on ServiceJourney and privateCodes on TrainBlockPart cover both needs natively, at the correct ownership level, without coupling operational data into the public timetable.

---

6. Practical Example

The following example models a simplified version of Vy's train 60 (Bergen → Oslo S) on the Bergensbanen:

Scenario:

• Line F4 (Bergensbanen)
• Train number 60, Bergen → Oslo
• Formation: El 18 locomotive + 4 Type 7 coaches (A7, B7, BC7, B7) + 1 rest car (BFWL) + 3 more coaches (FR7, B7, B7)
• One operating day: 2026-04-14

Example_RollingStock.xml

[clairecarnot]

Hello !
Thanks a lot hfjelstad for the detailed feedback 😮
I did not have the time yet to to dig into it properly, but I’ll revisit it a little later - to be continued !

[atibaut]

To link a ServiceJourney to an Equipment ID in NeTEx, you would typically reference the Equipment element within the context of a ServiceFacilitySet or similar structure. The Equipment element is defined in the NeTEx schema as an item of equipment available at a location, which can be linked to a ServiceJourney through the relevant XML structure [E1].
In practical examples, you can see how facilities are defined, and equipment references are included within those facilities [E2].

[E1] https://github.com/TransmodelEcosystem/NeTEx/blob/v2.0/examples/standards/tap_tsi/TAP-SKDUPD-example2.xml
[E2] https://github.com/TransmodelEcosystem/NeTEx/blob/v2.0/xsd/netex_framework/netex_reusableComponents/netex_equipment_version.xsd

--NAPCORE Helpdesk