Allow adding equipment to `VehicleType`

[Robbendebiene]

Currently only facilities can be assigned to a VehicleType (via VehicleType/facilities) but not equipment. Equipment requires a DeckPlan element (EquipableSpace) or Vehicle that references it (via actualVehicleEquipments).

In our opinion any equipment that can be assigned to a Vehicle like AccessVehicleEquipment or WheelchairVehicleEquipment, likewise make sense on a VehicleType. Therefore we propose adding the actualVehicleEquipments property from Vehicle to VehicleType in order to allow assigning equipment to a VehicleType.

Having VehicleType/actualVehicleEquipments containing EquipmentRef or Equipment also allows defining the equipment directly on the VehicleType indicating it is somewhere available on the vehicle. When using DeckPlan it can then additionally be referenced or "instantiated" by a particular EquipableSpace. Since a vehicle equipment is usually only used at one particular VehicleType and not throughout multiple, defining it on the VehicleType makes sense and also improves the portability of the VehicleType data.

Questions and remarks

• Would DeckPlan elements be able to reference equipment defined in a VehicleType as assumed above?

• What is the use case of VehicleTypeRef in ActualVehicleEquipmentGroup? Why can an equipment reference a VehicleType?

• There is a small naming inconsistency (same name but different content):

  • Vehicle/actualVehicleEquipments contains EquipmentRef or Equipment
  • EquipableSpaceGroup/actualVehicleEquipments contains ActualVehicleEquipment

  To be more consistent actualVehicleEquipments from Vehicle should be named vehicleEquipments following the existing placeEquipments property, but I suppose it is too late for this change.

[Robbendebiene]

TractiveElementType and TrailingElementType already have an equipments property. So it almost feels inconsistent that VehicleType doesn't.

Also a DeckPlan is referenced from a VehicleType but its elements can contain equipments (actualVehicleEquipments).

[Robbendebiene]

Just want to give a short comparison of the current status quo vs the proposal.
Consider the use case of depicting that a vehicle type has 3 steps in its entrance.

Status quo

<ResourceFrame version="any" id="ResourceFrame/id/1">
  <equipments>
    <AccessVehicleEquipment version="any" id="AccessVehicleEquipment/id/1">
      <NumberOfSteps>3</NumberOfSteps>
    </AccessVehicleEquipment>
  </equipments>

  <vehicleTypes>
    <VehicleType version="any" id="VehicleType/id/1">
      <ClassifiedAsRef ref="VehicleModel/id/1"></ClassifiedAsRef>
    </VehicleType>
  </vehicleTypes>

  <vehicleModels>
    <VehicleModel version="any" id="VehicleModel/id/1">
      <equipmentProfiles>
        <VehicleEquipmentProfileRef ref="VehicleEquipmentProfile/id/1"></VehicleEquipmentProfileRef>
      </equipmentProfiles>
    </VehicleModel>
  </vehicleModels>

  <vehicleEquipmentProfiles>
    <VehicleEquipmentProfile version="any" id="VehicleEquipmentProfile/id/1">
      <AccessVehicleEquipmentRef ref="AccessVehicleEquipment/id/1"></AccessVehicleEquipmentRef>
    </VehicleEquipmentProfile>
  </vehicleEquipmentProfiles>
</ResourceFrame>

Proposal

<ResourceFrame version="any" id="ResourceFrame/id/1">
  <vehicleTypes>
    <VehicleType version="any" id="VehicleType/id/1">
      <equipments>
        <AccessVehicleEquipment version="any" id="AccessVehicleEquipment/id/1">
          <NumberOfSteps>3</NumberOfSteps>
        </AccessVehicleEquipment>
      </equipments>
    </VehicleType>
  </vehicleTypes>
</ResourceFrame>

This is already possible for TractiveElementType and TrailingElementType.
The proposal also makes sense if combined with a DeckPlan, as the DeckPlan can then reference the equipment defined in the VehicleType.

The main argument against adding equipments seems to be that VehicleType is supposed to be used as a scheduling requirement. I still think this would work as the equipments could be seen as a requirement. Alternatively there could also be another element called EquipedVehicleType or ComplexVehicleType similar to SimpleVehicleType which holds the equipments.

[skinkie]

Within a VehicleType I feel you cannot speak of an Equipment (it is not specific). It would actually then be an Equipment_Type_ (does not exist yet).

[Robbendebiene]

This sounds like equipment is considered to be something unique that can only exist once in reality. This makes sense when thinking e.g. about an elevator that shall be monitored.

Does NeTEx really enforce this definition though? I always thought of equipments as a reusable component that can be "instantiated" or applied at different places. E.g. consider a train station with 5 elevators of the same kind. I would have defined just one LiftEquipment and then referenced it from the individual AccessSpaces that actually represent an element in reality.

Most likely I'm wrong, but if an equipment is a description of a single physical object that can only ever be used at one place in time, then I still don't understand how it works for DeckPlan elements or Tractive/TrailingElementType. In the DeckPlan examples the same equipment (e.g. SeatEquipment) is referenced multiple times. Not sure if the answer for DeckPlan is that every equipment is wrapped in an ActualVehicleEquipment.

[skinkie]

Entur wants the same kind of thing, because it was mentioned that 'reuse' is invalid.

[JohanEntur]

In an inderect way, Robins work in these matters are on behalf of Entur.

I guess the issue is between "that equipment" contra "an equipment. If this is a distinction NeTEx needs to make, then all equipment should tend towards the same model, essentially a "vehicle" is "that equipment" with other equipment nested within it, and all those are of a "type", which is a broader description of the thing, i.e. "an equipment".

I know we probably dont want to equate vehicles to equipment, but if we were building from scratch, we could have asked "is vehicle = equipment", and if it is, or nearly is, then they need the same data structures to describe them.

thats just my thought here. the key for us is that we want to build registries, not just creat situational data.

[Robbendebiene]

Not sure if the answer for DeckPlan is that every equipment is wrapped in an ActualVehicleEquipment.

To answer my own question: If I interpret the documentation correctly then ActualVehicleEquipment is the way how DeckPlan tries to solve this "instance vs type" or "that equipment" vs "an equipment" problem.

<xsd:element name="ActualVehicleEquipment" type="ActualVehicleEquipment_VersionStructure" abstract="false" substitutionGroup="PassengerEquipment">
	<xsd:annotation>
		<xsd:documentation>An item of EQUIPMENT of a particular type actually available in an individual VEHICLE.</xsd:documentation>
	</xsd:annotation>
</xsd:element>

Any Equipment used by an ActualVehicleEquipment is considered to be a type, thus it can be reused. The ActualVehicleEquipment is then thought of as the instance of the referenced Equipment. However this instance ultimately is still bound to a VehicleType wherefore it is still not a true instance that could be referenced by SIRI. So this construct just helps to semantically distinguish between equipment instances and equipment types without creating EquipmentType elements for each individual equipment.

Essentially actualVehicleEquipments can be read as equipmentTypes or availableEquipment. So perhaps actualVehicleEquipments could be added to VehicleTypes.

[Robbendebiene]

This was discussed at the 2025-08-26 meeting. It was mentioned that:

• VehicleType is supposed to be something of a lower level of detail like "this is a low floor bus"
• VehicleType formulates a requirement for a ServiceJourney. E.g. "A Bus with length X is required" or "A Bus with a boarding height of X is required".

This raised the question why DeckPlanRef is part of VehicleType (which is a very detailed and specific information and not a typical requirement). This led to the suggestion of removing/deprecating DeckPlanRef and instead only allow the usage via DeckPlanAssignment.

It was argued that VehicleModel should be used for our requirement as they are more specific (e.g. Volvo Bus 8500LE) and provide the option to assign Equipments via EquipmentProfiles.
However currently VehicleModel does not contain a lot of properties. Most of the properties are related to ride-sharing vehicles like Range, FullCharge, CustomerServiceContactDetails. Likewise VehicleModelProfiles only include CarModelProfile and CycleModelProfile.

Things marked in red in the image below are not possible to model via VehicleModel and TransportType.

EDIT: Since TransportType acts more as a base type here one must reference something like VehicleType which obviously then provides all the missing properties.

To restate our requirement:
We need a detailed description of a vehicle (carriage, bus, ferry) type. In most cases this will map directly to a vehicle model. However there might be vehicle models that have been altered or upgraded e.g. because all the buses got equipped with an additional electrical ramp. So there can be a "Volvo Bus 8500LE" and a "Volvo Bus 8500LE with ramp"

[Robbendebiene]

Actually it is already possible to assign Equipments to a VehicleType. It's just the other way around than what we expected. If this is allowed, does it rely hurt to have actualVehicleEquipments on VehicleType?

[Aurige]

in addition to this discussion, @Robbendebiene pointed (in another discussion) that you an Equipment can ba assigned an a VEHICLE TYPE via the ActualVehicleEquipment, for example :

<equipments>
   <BedEquipment version="any" id="1"/>
   <ActualVehicleEquipment>
      <VehicleTypeRef ref="1"/>
      <BedEquipmentRef ref="1"/>
   </ActualVehicleEquipment>
</equipments>
<vehicleTypes>
  <VehicleType version="any" id="1"/>
</vehicleTypes>

Which is most probably a bug : that makes sense that a VEHICLE TYPE has an EQUIPMENT PROFILE (via MODEL for now), but an ACTUAL VEHICLE EQUIPMENT on a VEHICLE TYPE definitely sounds weird !

Futhermore, I checked the Vehicle, that has a actualVehicleEquipments which is of type equipments_RelStructure instead of actualVehicleEquipments_RelStructure (or just a ref to actualVehicleEquipments) .. Which is also "unexpected" and most probably a bug !

We definitely need to discuss clarify & clean this

[Robbendebiene]

@Aurige
If adding equipments to VehicleType is not an option, what about one of the following changes:

• Add properties from VehicleType like DeckPlanRef, Width, PropulsionType, capacities etc. to VehicleModel.
  You might say this can already be defined by assigning a VehicleType to a VehicleModel but this doesn't make sense if a VehicleType is just a broad category/classification while the VehicleModel represents the higher level of detail. There is currently no way to define detailed vehicle data without a VehicleType which in turn should not be used to describe detailed vehicle data.
• Allow assigning VehicleEquipmentProfiles to a VehicleType.