Rationale

The rolling stock ontologies intends to represent various aspects of railway rolling stock, independently of each other:

1. rolling stock typology : vehicles, vehicle rakes, trainsets... => defined under "rolling stock typology"
2. trainset consist (= composition) : sequence and orientation of vehicles in a formation => "rolling stock consist" proposal, detailed below
3. rolling stock components : axles, wheels, couplers, brake pads... => in preparation
4. payloads : passengers, freight, containers... => referenced under "rolling stock typology", to be defined (as property sets) in another vocabulary
5. performance settings : effort vs. speed curves (traction and braking), resistance to forward movement, mass and rotating mass inertia ... => in preparation
6. geometry : "the left axle box of 2nd axle of wagon number 12345678 is 346m from the front of this running train and 45cm above top of rail", of interest for en route diagnosis => in preparation
7. adapters for ERA-TV and EVR are needed. In the future, these may be replaced by an adapter for the ERA Ontology.

The list of aspects can be expanded. Further analysis of use cases will show whether this is necessary.

The above aspects are made available at various business levels:

1. operations planning (functional level): "train IC94 is composed of three first-class, one dining, and seven second-class coaches, hauled by an electric locomotive"
2. manufacturing (technical level): "to serve ICxx trains, these are manufacturer Y catalogue entries (rolling stock types, in the sense of EU law): ..."
3. fleet inventory (physical level): reflecting actual vehicles or trainsets with a "chassis number" and/or an EVN.

These "levels" and their relationships are illustrated in the "rolling stock level" vocabulary. They would deserve a generalization.

Design goals

• each aspect and level shall be pairwise independent from others, as far as possible;
• each level will be able to document relevant aspects; operation planning will be less detailed, manufacturing (type) level much more so, and fleet inventory level even more so;
• each level will document its compatibility with a higher level, e.g. fitness of a manufactured type with respect to operational requirements, or conformity of a delivered vehicle with its type specifications;
• the ontology user will be able to freely combine, for each use case, the relevant set of aspects with the relevant set of levels;
• the ontology shall be kept minimal and open to extensions, in order to serve use cases not listed;
• the use cases contributing to the "core" of the ontology will be decided in the course of the MOTIONAL project.

Provided ontologies

Rolling stock typology

Link: https://cdm.ovh/rsm/rolling_stock/typology/

By "typology", we refer to "types" in their traditional British meaning: locomotives, wagons, etc. are types (not to be confused with types as in "register of vehicle types", that refer to manufacturing types or series).

The design of the typology rests on the fact that rolling stock types are identified according to several mutually independent features:

• motored or not (2 choices, leaving power source aside)
• nature of payload (2 types: passengers and freight, so 4 possible combinations)
• vehicles vs. vehicle formations (2 choices)
• etc.

which leaves room for 16 combinations, some having a name reflecting a concept, some not. Then, there are the odd ones (On Track Machines)... Any attempt to set up a "classical" tree-like structure (a taxonomy) rests on the choices for ordering the features, e.g. first branching differentiating the vehicles from formations, second differentiating the motorization, third branching according to the payload.

The proposed ontology (now v. 0.6) tries to reflect this way of thinking by separating rolling stock (vehicles and formations) from their features. The diagram below, while outdated (version 0.1), tells the general idea:

The proposal addresses composition on the left and features on the right. In the middle, you see the resulting classes embodying domain concepts and terminology such as "locomotive", "trainset", etc.

The list of concrete types (the classes in the middle) was deliberately kept flat, for the sake of simplicity, and also to avoid semantic errors. For instance, it would be tempting to state that a slave locomotive is a particular kind of locomotive, as the wording suggests. In reality, a slave locomotive is a locomotive without driving desk, so the "Liskov substitution principle" may fail: one cannot use a slave locomotive in lieu of a (conventional) locomotive, but only in addition.

Notes:

1. the diagram is "straight from Protégé desktop", using the OntoGraf plugin.
2. the arrows representing generalizations are reversed, compared to UML conventions. The general class is on the blunt side of the arrow, and the special class on the sharp side.
3. the ontology file includes extensive definitions, quoting TSIs whenever possible.

Substantial remarks:

1. the identification of types is not quite complete; EMU/DMU distinction for instance would require the formal description of energy sources (TBD).
2. heavy use is made of conjunctions (wrongly perceived as "multiple inheritance"): a wagon for instance is a vehicle AND is a thing designed for carrying freight. In other cases though, a restriction of a property value identifies the class (e.g. a trainset is a formation and has a fixed consist). Characterizing a concept by subclassing or by restricting a property value (with or without subclassing) is a matter of taste that is not easy to rationalize.
3. code implementations may interpret the conjunctions as classes (vehicle, formation) implementing interfaces (features are in fact property sets, and may translate to interfaces in the sense of Delphi, Java, or C# programming).

The diagram below reflects (hopefully) the current version:

Rolling Stock Levels

Rolling stock consist ("topology")

About order and orientation of vehicles and formations.

The narrative is illustrated by the following picture:

Notes:

• this is an object model (a sample trainset); vehicle and formation names (A, B, C … T, X) are arbitrary and alphabetic order is irrelevant
• Vehicle order and orientation are seen from a technical point of view. Running direction is another thing.

The proposed ontology can be illustrated (and simplified) as follows:

In short: any rolling stock has two distinct extremities. Rolling stock is partitioned into vehicles and formations (disjoint classes, it's either or). A formation is made of rolling stock (i.e. zero or more vehicles, and zero or more other formations). It has some rolling stock at its head, itself possibly followed by other rolling stock (a formation or a vehicle), etc. Each following, listed rolling stock is coupled with the preceding at a given extremity (not shown on this simplified diagram).

The complete diagram, using the GRAPHOL graphic language for OWL ontology representation, is as follows:

The added value of the simple "composite pattern" (using the includesRollingStock property, on the left) is disputable. It allows to disregard the ordering and orientation of rolling stock, e.g. for asset management purpose or operation planning. Also, it does not enforce any unicity condition, unlike the pattern involving ListedRollingStock.

IMPORTANT: you may wonder what happens with a given piece of rolling stock "X" in the inventory, once it becomes a member of a train composition. When "X" is included in the inventory, it gets a URI (unique resource identifier) and is known to be of class, say, coach. When "X" is then included in a train composition, it is likely to be the object of some hasNextRollingStock property and, if followed by another coach, it will also be the subject of another hasNextRollingStock property. Logically, it will then be identified as being of class ListedRollingStock (the domain and range of hasNextRollingStock), and more precisely ListedVehicle (the intersection of its original class, Vehicle, with hasNextRollingStock), in full coherence with all displayed properties. Meanwhile, the URI of "X" did not change. In object-oriented programming, where classes are generally types, moving an object from a type (Vehicle) to a subtype (Listed vehicle) may be more painful, involving a destructor call, a constructor call, and bespoke code to "transfer" the object with its accumulated properties. As in football, transfers come at a cost. With ontologies, we play softball instead.