Management Information and Statistics

Management Information and Statistics
EN12896 – 8

The data model part supporting management information and statistics provides some additional data descriptions which may be needed apart from the information elements already included in the scheduling, operations management and control, passenger information and fare management sub-models. Statistical information may of course be provided for any object of interest that is included in the company's specific data model and for which information is recorded in a database, whether for the company management or for other organisational units.
However, some additional information needs and sources are necessary, which cannot be derived from the model parts mentioned above and are specifically related to the evaluation of the operational process, especially to the evaluation of the current timetable and the comparison between the scheduled performance and actual performance. These include:

  • events and recordings describing the actual course of vehicle journeys and the resulting service performance;
  • the actual status of the planned and advertised interchanges and the resulting service quality;
  • recordings of the actual use of the service offer, i.e. actual passenger rides and trips.

What is the purpose of the Management Information and Statistics data model ?

The “Public Transport Reference Data Model– Part 8: Management Information and Statistics” describes how to structure data which refers either

  • to the planning stages (e.g. timetables, run times, driver rosters etc.) and/or
  • to the daily actual production,

and which is registered for different purposes, in particular to build indicators.
An indicator is a set of data (calculated or measured) which may be either qualitative or quantitative and may be used to provide information on the status or on the quality of a service or a function.
A calculation process that generates the indicators is characterised by:

  • a formula describing the method to calculate indicators that are based on other indicators and/or on a set of raw data,
  • an aggregation frame describing a data structure within which the data values are grouped and used for a formula to provide an indicator,
  • the granularity determining the smallest unit(s) in a calculation process which generates indicator(s).

This process may be schematically presented as follows:

Example of indicator calculation: calculation of the length of a tram network by operator.
Input (raw data set): length of the projection of ROUTE LINKs (see EN 12896-2) on the infrastructure;
Aggregation frame: set of ROUTE LINKs that make up the tram network;
Granularity: grouping by operator;
Formula: calculates the sums of the length of each item in the aggregation frame;
Calculator: executes the formula for each operator;
Indicator (delivery): set of total lengths of the network (by operator).
Transmodel defines data semantics and structures of the raw data used to provide indicators.

Indicators vs. Transmodel data structures

The OpRa group (Operating Raw Data and Statistics, CEN TC278 WG3 SG10) developed a technical report (CEN TR 17370) presenting different types of Use Cases which describe processes to calculate or derive indicators out of raw data.

The following Use Cases and related indicators (listed in the OpRa Technical Report) are covered by the data models provided by Transmodel:

Service dimensions: information needed to evaluate the dimension of the service in terms of number of lines, journeys, available seats, etc;

Commercial speed: information needed to evaluate the commercial speed of the fleet;

Service spatial coverage: information relevant to the characteristics of the service offer in terms of spatial coverage of the territory where the service is performed;

Service temporal coverage: information relevant to the characteristics of the service offer in terms of temporal coverage of the territory where the service is performed;

Service interchange nodes: information relevant to the characteristics of the service offer to evaluate the interchanges at specific PLACEs;

O/D zones connections:  information relevant to the characteristics of the service demand to evaluate connections among different ZONEs;

O/D matrix: information relevant to the characteristics of the service demand to evaluate movement of passengers among different ZONEs;

O/D zones moving cause: information relevant to the characteristics of the service demand needed to evaluate movement causes of passengers among different ZONEs (School, work, etc);

Demand dimensions: information relevant to the characteristics of the service demand to evaluate the number of passengers that use the public transport service;

Load factor: information relevant to the characteristics of the service demand to evaluate the load of VEHICLEs;

Service performed distance: information needed to calculate the performed distance.

Is there any particular mechanism to represent raw data log?

Raw data is captured and may be registered. In this context Transmodel uses the concepts: ENTITY, LOGGABLE OBJECT, LOG ENTRY and LOG.
The concept of ENTITY is introduced in EN12896-1. It represents any data instance to be managed in an operational version management system. When several data sources coexist, an ENTITY has to be related to a given DATA SOURCE in which it is defined.
A LOGGABLE OBJECT is an entity for which LOG ENTRies may be made. It is considered as a TRANSMODEL VIEW, i.e. it represents selected properties of one or more ENTITIEs being monitored/observed for significant events and changes of state.
The LOG ENTRY pattern records a change of state or a transaction against a LOGGABLE OBJECT.
The LOG ENTRies are triggered by EVENTs and may be grouped together in any kind of storage to form a LOG. EVENTs may affect the existence (e.g. creation or activation or deactivation) or state of an ENTITY (e.g. modification). The state changes of the ENTITY can be recorded as specialisations of LOG ENTRY.

When an EVENT has spatial attributes, it becomes a LOCATED EVENT and has geographical attributes that can refer to:

  • the ZONE in which the LOCATED EVENT is located,
  • the POINT where the LOCATED EVENT occurs,
  • the LINK on which the LOCATD EVENT is located.

Examples of data records described in Transmodel  

Transmodel presents explicitly several cases of 'raw data logs', i.e. data structures that take into account records of data. In this context, data models use concepts introduced in other Transmodel parts, in particular in  EN 12896- 4 to 6.

Records of service & vehicle performance events: record of events related to the performance of vehicle journeys, in particular service journeys, on each day of their operation;

Recorded passing times: record of the actual passing time of a vehicle (as OBSERVED PASSING TIME). It refers to a given MONITORED VEHICLE JOURNEY and is recorded at a particular POINT);

Recorded stops: record when a vehicle actually stops at a SCHEDULED STOP POINT and opens the doors to allow passengers to board or alight;

Record of boarding and alighting: record of the number of alighting and boarding passengers at a defined SCHEDULED STOP POINT;

Recording of impeded time: record of situations and time where the vehicle is not moving, due to congestion for instance;

Status of planned interchanges: record of INTERCHANGE STATUS data;

Records of disturbances: any disturbance affecting operations may be recorded in the entity OPERATIONAL EVENT. The main types of OPERATIONAL EVENTs are ALARMs (these may either be logged manually or recorded automatically when a system detects a threshold is exceeded) and INCIDENTs (often recorded in a logbook);

Recorded passenger trips: record of the actual consumption of the transport services by travellers (regardless of the means used to collect this information).

Indicators and raw data needed

The different Use Cases are determining particular indicators, however, the methods to calculate/derive an indicator may differ, in particular, they may rely on different equipment or on different raw data sets. As a consequence, for the same indicator, different data structures may be needed, depending on the context and the method chosen.
Transmodel discusses two examples of Use Cases to show how the generic LOGGABLE OBJECT model relates to the data structure underpinning the process of indicator calculation:
  • Actual journey performance,
  • Actual service demand.
The 'actual service demand' example is presented below. This Use Case corresponds to the OpRa Use Case 'demand dimensions' and provides the indicator passenger counts.
Transmodel describes the following situations:
  • passenger counts based on boarding and alighting counts,
  • passenger counts based on counting devices,
  • passenger counts based on access control.
In each situation, a different set of data is needed and therefore 3 different data models are proposed.
BOARDING BASED PASSENGER COUNT indicator calculation may rely on a simple process:
  • the number of boarding passengers is added to and
  • the number of alighting passengers subtracted
from the total number of passengers in the VEHICLE operating a particular DATED VEHICLE JOURNEY.
The process of vehicle monitoring consists of collecting all available data related to a vehicle carrying out a MONITORED VEHICLE JOURNEY. It is explained in EN12896-4 that various types of situations may be monitored: the position of a vehicle on the network, vehicle stopping, passengers alighting, etc Any monitored data is recorded through a VEHICLE MONITORING activity. Instances of this entity are called VEHICLE MONITORING LOG ENTRies (see EN12896-4).

VEHICLE MONITORING may consist of the observation of:
  • RECORDED STOP: the actual stopping time of the VEHICLEs at SCHEDULED STOP POINTs
  • BOARDING AND ALIGHTING: the numbers of passengers boarding and alighting at a SCHEDULED STOP POINT during a RECORDED STOP.
Further aggregations of BOARDING BASED PASSENGER COUNT are possible: per LINE, per OPERATOR, etc.
Passenger counts may be based on the counts of “validations” based on the concept of VALIDATION ENTRY and FARE PRODUCT parameters (see EN12896-5).
VALIDATION ENTRY represents the result of the comparison between one or several control results and the theoretical access right controlled.
The access right controlled is present on the validated travel document, which represents the consumed FARE PRODUCT.

The recorded VALIDATION ENTRies may be of several types, for instance:
  • PASSENGER CHECK IN/OUT ENTRY, representing the recording the check in/out of a passenger at a barrier or validation point at the start/end of a journey;
  • FARE TRIP ACTIVATION ENTRY, recording the initiation of the consumption of access rights by a passenger making a trip, for example by means of marking a TRAVEL DOCUMENT using a ticket validator machine;
  • PASSENGER WAY POINT ENTRY, recording a passenger checking in at a way point while in a trip so as to indicate travel by a specific itinerary;
  • CONTROL PASSENGER TRIP ENTRY:, recording the control of the consumption of access rights by the inspection of a TRAVEL DOCUMENT by a TRAVEL DOCUMENT CONTROLLER. May include marking (cancellation) of the TRAVEL DOCUMENT.

The ONBOARD DEVICE BASED PASSENGER COUNT is an indicator that specialises the VEHICLE DETECTING (see EN12896-4) and connects it to the JOURNEY ACCOUNTING (using the relations through the DATED VEHICLE JOURNEY and JOURNEY).
The relation to the LINE and to the OPERATING DAY is displayed to illustrate the possibility of filtering this indicator per LINE or per OPERATING PERIOD.

What use Cases are beyond the scope of Transmodel V6?

The following Use Cases defined by OpRa are not covered by the data structures of Transmodel:

Fleet dimensions: this function considers all the information to calculate the dimension of the fleet (number and type of vehicles, etc.);

Service safety: this function considers all the information to evaluate the safety of the PT service in terms of accidents occurred, etc;

Service pollution emissions: this function considers all the information to evaluate environment impacts due to the emission of pollutants;

Service incoming funds; this function considers all the information to calculate the economy aspects of the PT service (public funds, revenues from sold tickets, etc.);

Service costs: this function considers all the information to calculate expenses to maintain and to sustain the PT Service;

PT organisation dimensions: this function considers all the information to calculate the characteristics of a PT organisation (such as number of employees, etc.).

Driver Management

Driver Management
EN12896 – 7

This part of the reference data model describes all the information that is necessary to schedule (logical) drivers to work the blocks and duties necessary to provide the defined service offer to the passengers.
The process of ordering driver duties into sequences in order to obtain a balanced work share among the driving personnel over the planning period, and to keep the resulting work time in harmonization with legal regulations and internal agreements between drivers and the company management, is known as rostering. The reference data model offers a model part covering the information needs associated with some classical rostering methods, widely used in European countries. There may, however, be other (particularly more advanced, dynamic) methods applied in some cases, which would probably need additional or other entities than described in the rostering part of the reference data model.
The personnel disposition domain of the reference data model covers the data needs of the relevant driver management functions with respect to the two major tasks of

  • Assigning physical drivers to the logical drivers identified in the scheduled duty plan;
  • Recording the performance of drivers on the actual day of operation.

The assignment of drivers for the actual operating day to the duty plan set up for the whole planning period is usually done in a staged procedure. The assignment will mostly start from default assignments for the whole period in question, which can be continuously overridden by changes and adjustments due to regular absences of drivers from work, changes initiated by drivers according to their preferences or by the control staff according to operational needs. Short-term adjustments may become necessary to balance unplanned absences and other circumstances principally not known in advance.
Records to document the actual driver activities are usually taken to control the driver performance and compare it with the original plan, and to prepare these data in a suitable way for wage accounting. This mainly refers to the specification of the time worked by each driver on the individual day for each type of activity, and some additional classifications, which may result in appropriate modifications of the amount to be paid for the recorded activity in question.

Physical drivers, logical drivers and driver duties

In the first stages of the planning process there are no direct references to the physical drivers that shall actually perform the duties, but rather to a theoretically available driver resource for an OPERATING DAY, foreseen to be monitored and called LOGICAL DRIVER.
The DRIVER entity describes a physical driver, who is an EMPLOYEE of the public transport company whose usual work is to drive a public transport vehicle.

An overview on the different concepts related to the description of the work of the drivers are presented in the figure below:

Driver DUTies and their components: DUTY PART, STRETCH, BREAK, SPELL, PAUSE will be defined in the following pages.
To cover the scheduled SERVICE JOURNEYs at minimum cost driver DUTIEs are determined and this process is called driver scheduling. Driver scheduling concerns LOGICAL DRIVERs. Many parameters have to be taken into account during this process (e.g. the maximum length of driving time allowed without a break) in order to give drivers fair workloads, which comply with the law and with the agreements made between the operators and driver unions.
A DUTY describes the work to be performed by a driver on a particular DAY TYPE.
It may require specific TYPEs OF QUALIFICATION. A DUTY may be a SPARE DUTY, in which case no specific work has yet been assigned to it, or an ASSIGNED DUTY, which is composed of a hierarchy of components.

A DUTY PART is a continuous part of a driver DUTY during which the driver is under the management of the company and may include BREAKs.
A BREAK is a period of time within a DUTY PART during which the driver is not responsible for a vehicle and can rest, usually at a BREAK FACILITY.

A STRETCH is a period of a driver's DUTY during which the driver is continuously working without a BREAK but that may include PAUSEs during which the driver remains responsible for the vehicle.

A SPELL is a continuous period in a STRETCH, when a driver is on duty on one vehicle or performing one other type of work.
A DRIVING SPELL is a SPELL that is performed continuously on the same vehicle (i.e. the same BLOCK). A DRIVING SPELL is bordered by two actual reliefs, which are organised on appropriate RELIEF OPPORTUNITies (see EN12896-3). These RELIEF OPPORTUNITies are points in time and space (at RELIEF POINTs , see EN12896-2) in the same particular BLOCK.
NON-DRIVING SPELLs are either STAND-BYs (tactical reserve) or TASKs, such as taking buses through a wash, training session, social activity etc.
DUTies are of a particular DUTY TYPE.
A CONTINUOUS DUTY is a classification of a DUTY, in terms of working hours within the day comprising a single period of paid work.
A SPLIT DUTY is a classification of a DUTY, in terms of working hours comprising several time bands separated in different DUTY PARTs by periods of unpaid time.

The DUTY TYPE indicates the time profile of the DUTies for rostering purposes.
At the beginning or at the end of a DUTY, a DUTY PART, a STRETCH or a SPELL, a fixed time may be allowed to perform certain activities to prepare for, or to complete the work regularly assigned to this element. These activities may include signing on or off, controlling the vehicle condition, cleaning or refuelling the vehicle, controlling the amount of cash, etc.
A TIME ALLOWANCE is a fixed paid time allowed to perform certain activities to prepare for or to complete the work assigned either to a BLOCK, a DUTY , a DUTY PART, a STRETCH or a SPELL.

The driver scheduling process takes also into account the times necessary for drivers to get to the starting point and to return from the finishing point of their spells of work.
A DRIVER TRIP (which may be associated with a TRIP PATTERN, see EN12896-6) is a planned non-driving movement of a driver within a DUTY PART between two TIMING POINTs that may include using one or several VEHICLE JOURNEYs on vehicles driven by other drivers.
A DRIVER TRIP TIME is the time allowed for a driver to cover a particular DRIVER TRIP during a specified TIME BAND.

A coherent set of DUTies to which the same set of VALIDITY CONDITIONs have been assigned builds a DRIVER SCHEDULE FRAME.
A DRIVER SCHEDULE FRAME represents the theoretical work of a group of LOGICAL DRIVERs.

Driver rostering

Duty plans are often presented in form of a cyclic matrix, where LOGICAL DRIVERs are assigned in turn to each DUTY of a cycle (hence the term “rostering”).
There are numerous different rostering methods applied in companies over European countries.
The rostering part of the conceptual data model has to be considered as a reference basis for companies working with one of the conventional rostering methods that have been taken into account in the model design.
Two main families of methods for this task are described in detail in EN12896-7 (based on the concepts of either ROSTER CYCLE or ROSTER DESIGN, see Roster Cycle Model and Roster Design Model).
A ROSTER MATRIX is a table showing the duty plan for a certain period of time and for a number of LOGICAL DRIVERs, into which the relevant DUTies to be worked will be entered.
A REST is a representation of a day off for a driver.
An example of a ROSTER MATRIX is represented in the figure below

The most classical rostering practice is to first assign a DUTY TYPE or a REST day to each theoretical day in the components of a ROSTER MATRIX.

After a decision has been made on how to structure the input for the rostering process (i.e. the DUTies, differentiated by their type), either by means of a ROSTER CYCLE or by ROSTER DESIGNs, and after the design of ROSTER MATRIces, the assignment of DUTies will be made. This assignment is aimed at obtaining a satisfying pattern of DUTies for each driver, during the planning period covered by the matrix.

DRIVER ASSIGNMENT is defined as an assignment of an EMPLOYEE to a ROW/DRIVER in a ROSTER MATRIX for a specified OPERATING DAY.
As a summary, the Roster Matrix Model provides the different entities contributing to the design of a ROSTER MATRIX.

DESIGN WEEK ELEMENT and ROSTER CYCLE ELEMENT refer to the 2 rostering methods (relying on either ROSTER CYCLE or on ROSTER DESIGNs) taken into account in the reference data model and described in more detail in EN 12896-7.

Driver work accounting

DUTY and DRIVER data are extensively used as input for accounting functions within a company so that the correct DRIVER payments can be calculated and attributed to relevant COST CENTREs.
DRIVER activity log can be used to prepare information on the DRIVERs’ work time.
An account is created for each EMPLOYEE (e.g. DRIVER), which will include the sum of time worked during a defined ACCOUNTING PERIOD. This account consists of ACCOUNT ENTRies for each OPERATING DAY.
An ACCOUNT ENTRY sums up the actual time worked by one EMPLOYEE during one OPERATING DAYfor a specified COST CENTRE.

An ACCOUNT ENTRY is a record of aggregated ACTIVITY LOG ENTRY data per TYPE OF WAGE, EMPLOYEE and COST CENTRE for one OPERATING DAY that is used to transfer information on duties actually worked by drivers to an external accounting system.
A WAGE INCREASE for special aggravations having occurred during the work may be assigned to an ACCOUNT ENTRY.

Driver control actions

CONTROL ACTIONs are actions resulting from a decision taken by the controller causing an amendment of the operation planned in the PRODUCTION PLAN (reference version of daily activity). PRODUCTION PLAN and CONTROL ACTIONs are introduced in EN12896-4. In particular VEHICLE CONTROL ACTIONs, i.e. control actions affecting the LOGICAL VEHICLE are discussed there in detail.

CONTROL ACTIONs that directly affect the drivers are DRIVER CONTROL ACTION. They are affecting a LOGICAL DRIVER.

LOGICAL DRIVER CREATION action consists of creating a completely new LOGICAL DRIVER (e.g. reserve resource) and possibly assigning a work plan to this LOGICAL DRIVER.
A LOGICAL DRIVER CANCELLATION action consists of removing a LOGICAL DRIVER from the PRODUCTION PLAN. The work assigned to it may remain unassigned for a while.
A CHANGE OF DRIVER action consists of removing, at a certain point in time and space (in principle, at a RELIEF POINT), all work assigned to a LOGICAL DRIVER and of assigning it to another LOGICAL DRIVER.

Passenger Information

Passenger Information
EN12896 – 6

The reference data model covering the domain of Passenger Information not only describes the data needed for applications providing passengers with relevant information on planned and actual services, but also the data resulting from the planning and control processes which may result in service modifications which also may be of interest to the public. Consequently, the passenger information data model includes data components which go far beyond the ‘static’ planned timetable, the main source for classical timetable information (but one that does not take into account dynamic and operational issues).
These additional concepts include:

  • passenger information facilities and their utilisation for passenger queries;
  • detailed descriptions of all the conceptual components of a passenger trip, as possibly needed by an interactive passenger information system when answering a passenger query;
  • basic definitions of run times and wait times needed to calculate trip duration;
  • planned, predicted, and actual passing times of journeys at individual stops;
  • service modifications decided by the schedulers or the control staff, resulting in changes of the vehicle journeys and blocks, compared to the original plan.

All types of passenger information use various elements of the topological network definition (such as the lines) and of the journeys which form the service offer (including run and wait times, and other fundamental definitions). Geographical information may also be provided in some cases, if corresponding application systems are available. Specific types of passenger queries may be related to fares, where the relevant information elements are included in the fare management sub-model of the reference data model (EN12896-5).
Thus, the information basis for passenger information systems is widely spread over the whole reference data model, and so this nominal ”passenger information” data model covers only those elements and are not explicitly included in, other parts of the model. It includes views that can be derived from the data in other parts of the reference mode, most notably a trip itinerary model representing an extract of service journey and interchange data covering a specific trip at a specific time.

Provision of information to passengers

Information for passengers can be communicated to the passengers using a wide variety of equipment, such as:

  • printed material such as leaflets at stops, information booklets, etc.;
  • passive terminals, such as displays at stop points or onboard vehicles, delivering information on planned or actual service, e.g. information on the arrival times;
  • interactive terminals, delivering information on request regarding planned or actual service, such as home internet terminals, personal mobile devices, an information desk terminal operated by the staff, etc.

In spite of this variety of media and techniques, some common data features are relevant as common characteristics of the provided information, in particular:

  • spatial information,
  • line and destination information,
  • general annotation information provided as footnotes.

Although there are a number of different types of passenger information, it is timetable information that is of principal interest, both in the form of general timetables and personalised trip plans.
Transmodel provides a generic model for a query and response delivery with which to deliver data from a model to client applications. Detailed models for specific queries/responses, conforming to the generic query/response model and showing which reference model elements are relevant for different types of functional query, are described in an informative annex.
Trip planning queries are of primary importance for interactive information, and the contents of the information delivered by such queries is modelled in particular by the Passenger Trip Model.

Static and dynamic information presented to the public

Public transport network vs. infrastructure network

The network is often represented on a background map, which describes the area served by public transport (e.g. city map). It is also common to show a projection of various parts of a PASSENGER TRIP on a map.
The map with its layers or spatial features is typically provided separately by a map server that integrates and renders geographical information system (GIS) data.
Transmodel provides a general mechanism to model the correspondence between different layers of spatial information, called a PROJECTION (for more information on PROJECTIONs see EN12896-2).
In order to display the PT layer data onto the map layer a projection as a sequence of spatial coordinates must be provided to the application. This can be done, for instance, by LINK PROJECTION of the ROUTE LINKs on INFRASTRUCTURE LINKs.

Schematic representation of the public transport network

A very simple representation of a PT network consists in drawing a schematic description of each SERVICE PATTERN on a straight line, with all SCHEDULED STOP POINTs marked on that line at the same distance from each other. This is a purely topological representation of a JOURNEY PATTERN (or a SERVICE PATTERN) as an ordered sequence of points.
Some additional information may be added to this simple representation, e.g. LINEs with which an interchange is proposed at particular SCHEDULED STOP POINTs may be indicated or FARE SECTIONs.
If the LINE includes more than two ROUTEs, in particular when there are diverging branches, other linear forms are necessary. A SCHEMATIC MAP (See EN12896-1) can be used to provide a coloured line-based representation, including branches.
Most of the lines of a network will have an advertised destination, generally known to the passengers and displayed on the vehicle (i.e. on the headsign) and also used in the information material. This destination is not necessarily the name of the final destination (e.g. the name of the last POINT IN JOURNEY PATTERN). Such headings may be described consistently by the entity DESTINATION DISPLAY (see Line & Route MODEL, EN12896-2), which may also have different variants for use in different contexts and media (DELIVERY VARIANT).
The entity NOTICE allows human readable text annotations describing exceptions and other arbitrary conditions to be provided for informational purposes as attachments for a LINE, a JOURNEY PATTERN, SERVICE JOURNEY, FARE PRODUCT, etc. The information may be usable for passenger or driver information.

A timetable is an end product of the scheduling process. It gives the scheduled PASSING TIME (in general, departure times) for all VEHICLE JOURNEYs, on all SCHEDULED STOP POINTs, for one or possibly several DAY TYPEs.
Although the ‘timetable’ is a very well-known and important concept, it is not described in the data model as an inherent entity, because it contains only derived data; a TIMETABLE FRAME represents such an assembly and can be used to organise journeys into named sets with a particular validity that can be rendered in tabular form. The process of computing timetable information (in particular the passing times) is described in detail in EN12896-3. The GROUP OF JOURNEYs element can be used to create subsets of journeys with similar properties (e.g. same direction, service pattern, etc) to guide the efficient rendering of a timetable into a tabular format.

Passing times

Any theoretical PASSING TIME at a point may be derived from the underlying scheduling information. However, in real implementations, this data will often be pre-calculated and stored.
The PASSING TIMEs that are the results of the scheduling process for publishing in a timetable are called TIMETABLED PASSING TIMEs (see EN12896-3).
The PASSING TIMEs that are computed on a specific OPERATING DAY are called DATED PASSING TIME. This entity has several subtypes, described in EN12896-3:


When organising data for efficient exchange and presentation to the passenger, it is sometime useful to rearrange it in views that may be denormalised, or that may include additional derived data.
In particular a CALL, defined as a view that brings together data relating to the individual visit to a POINT IN JOURNEY PATTERN in a VEHICLE JOURNEY assembles information held variously on a POINT IN JOURNEY PATTERN and related entities, grouping planned estimated and observed arrival times and departure times in convenient CALL PARTs, and referencing ancillary information such as the DESTINATION DISPLAY and NOTICEs for the POINT IN PATTERN (for further details see EN 12896-3).

Frequency-based services

Where services are very frequent (typically less than every 10 minutes) it is often the practice not to publish specific passing times for the stops on a timetable, but rather simply to indicate a frequency of service (for example, “every 5-8 minutes”). This may be represented by a TEMPLATE SERVICE JOURNEY which gives the service pattern that is followed, and a FREQUENCY GROUP that gives the expected intervals – see EN12896-3.

Trip Description Models

Modern computer-aided travel tools assist potential travellers in preparing their trips, particularly in answering specific TRIP REQUESTs. Such a trip planning function identifies the origin and destination places of an intended trip and proposes one or several TRIP solutions.
The Trip Description Models describe the trips and fares that passengers may make on transport networks, in particular public transport, but possibly also including legs made by car, cycle, walking, ride sharing or other private modes.
A TRIP is defined as a part of a TRIP PATTERN describing the movement of a passenger from one PLACE of any sort to another. A TRIP may consist of one or more consecutive LEGs having some common characteristics.
A TRIP PATTERN describes complete spatial movement of a passenger from an origin PLACE to a destination PLACE, using public transport vehicles and other modes, including possibly walking and non-public transport legs, done for a specific TRIP REASON.
A TRIP PATTERN may consist of one or more consecutive TRIPs.

A LEG is the principal component of a TRIP PATTERN.
Each LEG describes a movement of a user in a single vehicle, or using a single other mode such as walking, cycling, or driving. LEGs may be of different types (PT RIDE LEG, ACCESS LEG, PT CONNECTION LEG, OTHER LEG, etc.) depending upon the mode of transport used to make them. In particular:
  • A PT RIDE LEG is that part of a passenger trip taken on a single PT vehicle, from one SCHEDULED STOP POINT to another. A PT RIDE LEG is carried out on only one JOURNEY PATTERN;
  • An ACCESS LEG describes a non-public transport LEG made between an arbitrary origin or destination PLACE and a SCHEDULED STOP POINT, when accessing public transport.
  • A PT CONNECTION LEG describes details of the interchange made from one SERVICE JOURNEY to another over a CONNECTION between two SCHEDULED STOP POINTs.
  • An OTHER LEG can be used to describe a leg on another mode of transport (for example by car) making up a trip, from an origin PLACE to a destination PLACE. The origin and destination may be a SCHEDULED STOP PLACE or some other type of place such as an ADDRESSABLE PLACE, POINT OF INTEREST, etc.

The overall Trip Model is as follows:

A PT CONNECTION LEG is a part of a TRIP PATTERN corresponding to the movement of a passenger transferring from one SERVICE JOURNEY to another, made over a CONNECTION from one SCHEDULED STOP POINT to another, and possibly following a specific NAVIGATION PATH (a designated path between two places, see EN12896-2).
The PT CONNECTION LEG may be characterised by the type of guarantee offered for a given connection.
PATH GUIDANCEs can be used to provide step by step instructions for following the path through the PT CONNECTION LEG, if necessary, referring to signage modelled as part of the SITE description, as well as headings, turn instructions and level changes computed from the path.

PATH LINK IN SEQUENCE is a step of a NAVIGATION PATH indicating traversal of a particular PATH LINK as part of a recommended route (for more details see Site Model, Path & Navigation Path Model provided in EN 12896-2).
A passenger TRIP may be a part of a wider pattern of TRAVEL, made for different reasons. For example, a passenger might make a trip to deliver their children to school, then another to proceed to work. The wider pattern can be captured as a TRAVEL, a set of trips for a given TRAVELLING ENTITY, made for a specific TRIP REASON.
A TRAVEL may also be used to assemble a collection of alternative TRIP PATTERNs that all satisfy the same TRAVEL SPECIFICATION, so as to present a selection of alternative routes to a customer. Data from multiple TRAVEL instances can be summarised as a TRAVEL FLOW for statistical purposes.

Some examples of simple travel specifications:
  1. Simple trip from one bus stop to another
    TRIP PATTERN [TRIP REASON= go to work] is composed of a PT TRIP composed of one PT RIDE LEG [MODE = bus]
  2. Walk to a bus stop, catch the bus, walk to the shop
    TRIP PATTERN [TRIP REASON= go shopping] is composed of a PT TRIP composed of an ACCESS LEG [MODE = walk] followed by a PT RIDE LEG [MODE = bus], followed by an ACCESS LEG [MODE = walk].
  3. 3. Walk to the station, catch the train, cross town in a taxi, take the second train, walk to the meeting centre may be represented by a TRIP PATTERN [TRIP REASON= business trip] composed of:
    a PT TRIP composed of an ACCESS LEG [MODE = walk], a PT RIDE LEG [MODE = rail], an ACCESS LEG [MODE = walk]
    a NON-PT TRIP composed of an OTHER LEG [MODE = taxi]
    a PT TRIP composed of an ACCESS LEG [MODE = walk], a PT RIDE LEG [MODE = rail], an ACCESS LEG [MODE = walk].
The TRIP DURATION Model specifies how long a trip will take. It provides additional information for the Passenger Trip Model.
A mean PASSENGER RUN TIME can be specified for the time to travel each leg of a PT TRIP, and a MEAN PASSENGER WAIT TIME can be specified for the average wait time at each stop. These can be used to compute an overall travel time.
Where a specific VEHICLE JOURNEY is cited an exact time can be calculated from the PASSING TIMES.
Several concepts in the diagram below are presented and discussed in detail in EN 12896-3.

It may be useful to monitor the actual status of the service in real-time against the planned TRIP in order to be able to inform the passenger of any delays.
TRIP PATTERN MONITORING is the action of monitoring a passenger movement in real-time to provide progress information for a passenger.
A MONITORED TRIP describes the monitoring of an individual planned TRIP. It is made up of MONITORED LEGs; each MONITORED LEG can relate a specific PT RIDE LEG to a specific MONITORED VEHICLE JOURNEY in order to derive progress information.
Observed and estimated PASSING TIMEs may be represented for the user as MONITORED LEG CALLs for each stop of interest on the journey. The MONITORED LEG CALLs may have separate MONITORED LEG PARTs for the arrival (MONITORED LEG ARRIVAL) and departure (MONITORED LEG DEPARTURE) steps. MONITORED TRIP may itself be part of a sequence of trips constituting a MONITORED TRIP PATTERN.

MONITORED LEG PROGRESS provides the relative progress of a passenger along a LEG (current distance along a LEG, time at which LEG started or /ended, etc).
To describe the fares available for a trip, the Passenger Fare Offer Model includes a PT FARE OFFER, defining an available fare for a specific PT RIDE LEG in a PT TRIP or for the whole PT TRIP, or for the whole TRIP PATTERN. The fare may be restricted to particular products and conditions as described by SPECIFIC PARAMETER ASSIGNMENTS, related to the OFFERED TRAVEL SPECIFICATION (a set of parameters giving details of the intended consumption of access rights (e.g. origin and destination of a travel, class of travel, etc.)).
The diagram below reminds several concepts defined and discussed in EN12896-5, in particular:
  • TARIFF representing a particular instance of a fare structure;
  • VALIDABLE ELEMENT: a sequence or set of FARE STRUCTURE ELEMENTs, grouped together to be validated in one go;
  • FARE PRODUCT: an immaterial marketable element (access rights, discount rights, etc.), classified by the payment method and the account location: pre-payment with cancellation (throw-away), pre-payment with debit on a value card, pre-payment without consumption registration (pass), post-payment etc.;
  • SALES OFFER PACKAGE: a package offered for sale as a whole, consisting of one or several FARE PRODUCTs.

A PT FARE OFFER describes a FARE PRODUCT and its PRICE available for a particular PT TRIP or PT RIDE LEG.
For further explanations of the concepts related to the fares see EN12896-5.

Passenger information equipment

Delivery of passenger information through any form of device is described by the entity PASSENGER INFORMATION EQUIPMENT (a generic class of information device), which may be passive (for example a printed timetable), active (for example a display), or interactive (for example a kiosk terminal supporting trip planning).
A LOGICAL DISPLAY is a set of data that can be assembled for assignment to a physical PASSENGER INFORMATION EQUIPMENT or to a logical channel such as web or media.

For more detailed discussion see EN12896-2.

Passenger Information requests

The Query Model uses a common framework comprising an abstract query made up of a request/response pair. It describes common query constructs used by all the different query types and provides an abstract template which can be populated by specific requests.

An Informative part of EN 12896-6 provides examples of Passenger Information (PI) REQUEST Models and indicate how the Transmodel data elements relate to APIs and web services that deliver transport data to the end user, for example journey planners, fare engines, etc. The models give guidance as to which Transmodel elements are relevant for typical passenger information queries, and to identify useful query criteria.
The figure below presents different types of PI REQUESTs and PI DELIVERies considered (see the Informative Annex E of EN 12896-6).

A TRIP REQUEST is used to request trip plans from a journey planning engine. The Trip Request can be used both for single-trips and for multi-point trips that go via several way points.
Transmodel gives an indicative set of parameters commonly found in trip planners, but others are possible and might be added to the filters to select or bias the results.
Below is an example of a Trip Query Model and the associated TRIP DELIVERY providing as result one or more TRIP PATTERNs.

Annex D of EN12896-6 provides a table with (approximate) equivalences between:

  • the SIRI (Service Interface for Real-time Information, EN 15531 series) functional services
  • the OADJP (Open API for Distributed Journey Planning, CEN/TS 17118:2017) functional services

and the Transmodel Request model.

Fare Management

Fare Management
EN12896 – 5

The fare management data model aims at a generic description of the data objects and elements needed to support functions such as defining of the tariff structures, fare products and their parameters; operating sales, validating the consumption and charging customers. Tariff structures and products can be complex and there are differences in how these functions and their underlying data structures are handled in different European countries, and even between the public transport operators within one country - it is notable that historically there have been little attempt to standards fares across all modes.

Faced by such a degree of complexity and diversity in the concepts to be taken into account, in order define a single fare management data model capable of covering as many existing solutions and practices as possible, a careful separation of concerns is required, together with some novel modelling abstractions. The resulting fare management data model concentrates on the abstract, generic concepts that form the core of any fare system, independently of how these abstract concepts are implemented by a set of concrete fare products (e.g. tickets or passes) offered for sale to the public.

The starting point for the description of these fundamental concepts is the definition of theoretical access rights, based on use of network and temporal elements. These can be combined to form immaterial fare products, which are linked to travel documents in order to form sales packages to be sold to passengers. Controls may be applied to these travel documents to validate the utilisation of the public transport system. Price components are linked to the access rights, fare products and sales packages: they are used to calculate the price to be paid by a customer for a specific consumption (e.g. sale on a vending machine, debiting a value card, post-payment).


The Fare Management model covers mainly the planning and operational stages of use:
  • definition of the fare offers, information on fares and prices in the planning stage
  • operational processes, such as sales, control and validation of access rights.
Transport usage information through the registration of fare-related data is also modelled.

However, not all the functional aspects of the planning and operational stage are taken into account in the reference model. Data requirements for the following domains are only partly covered:
Sales organisation:
  • Management of the sales network (not covered, some basic retail and distribution elements relevant for passenger information are included).
  • Sales operations, including fulfilment (partly covered).
  • Management of customers (partly covered).
  • Collecting funds or accounting (not covered).
  • Pricing parameters specification (partly covered).
  • Exact price calculation (not covered).
Consumption control:
  • Access right validation & control (covered).
  • Fraud management and revenue protection measures (partly covered).
  • Collection and aggregation of consumption data (partly covered).
The implementation of Transmodel as an XML schema within the Technical Specification NeTEx (TS 16614-3) covers the planned fares offer including information on fare offers and prices, i.e. concerns the planning stage.
The data model for the Fare Management domain incorporates the following data packages:
  • Fare Structure Description
  • Access Rights Description
  • Pricing
  • Sales Description
  • Customer & Sales Transaction
  • Fare Roles
  • Validation and Control
  • Explicit Frames
As in all other domains the model represents the data needed for the different processes; in this case, it is concerned with functional domains such as sales, distribution, retail, traveller information on available fare products, control of access rights and validation.
In other words, the modelling addresses what information elements are needed and not how the information is processed.
The fare offer data domain splits further into sub-domains corresponding to well identified data packages as described above: Fare Structure Description, Access Rights Description (Access Rights Rules & Fare Products), Pricing and Sales Offer Description.

Often there is a simple one-to one correspondence between the network, the fare structure, the access rights, and the products offered. For example, a product giving use of a zone or zones in a zonal system, or to go between an origin and destination in a point-to-point tariff system. Such fare structures are relatively trivial to describe. Here we consider a slightly more complex example that serves to illustrate the distinctions between network elements, access rights and products.
The following example considers a number of different access rights to use different elements of Public Transport that could be combined within one or more fare products:
  1. The operator of a Public Transport system offers travel on public transport services within a zonal fare system covering a city. The same set of tariff zones apply to both bus and metro but there are slightly different constraints on travelling by each separate mode:
    • The bus trip allows travel between any bus stop within the named zones, with unlimited transfers between different bus lines during a specified time interval.
    • The metro trip allows travel through a specified number of zones.
    • A bus trip may be followed by a metro trip (in that order only).
  2. Parking stakeholders (with their own fare structure) may define an access right:
    • parking for up to 3 hours.
  3. A joint Public Transport + Parking product might offer the following access rights:
    • parking up to 3 hours followed by a bus/metro 2-zones trip.
This requires the product definition to impose a sequence of use of the access rights and furthermore, to place usage limitations on this sequence (that is, a passenger must use the access rights in a particular order and may not be allowed to use certain rights without previously having consuming another).
A fare product, called in this example Ticket t+++, could combine the right to use all the above access rights.

For this example, we assume that Ticket t+++ is prepaid before use. However, the same access rights may be used in several FARE PRODUCTs, e.g. pre-paid (materialised on a paper ticket and paid before use), post-paid (materialised on a smartcard) and post-paid using a debit card or bank credit card and charged to account).
A FARE PRODUCT is defined in Transmodel as an immaterial marketable element (access rights, discount rights, etc.), specific to a CHARGING MOMENT, which provides a classification of FARE PRODUCTs according to the payment method and the account location (and thus having different contractual terms for the passenger as to obligations and financial risk). For example, pre-payment with cancellation (throw-away), pre-payment with debit on a value card, pre-payment without consumption registration (pass), post-payment etc.
A distinction is also made in Transmodel between
  • the access right to a service,
  • the corresponding products offered to the public (e.g. pre-paid or post-paid fare products) and
  • the materialisation of a fare product on a medium when sold to the public.
A SALE OFFER PACKAGE is used to describe the materialisation of one or more FARE PRODUCT(s) on a specific media or TYPE OF TRAVEL DOCUMENT.
The same product may be used in different offers with differentiated pricing for different media and distribution channels. Thus our prepaid Ticket t+++ described in the example above, might be offered both as a paper ticket “Ticket t+++ classic” and as an app “Ticket t+++ mobile” and on a smartcard “eTicket t+++”.

Fare Structures and Tariffs

As a general classification, the following broad types of tariff structures are commonly found in public transportation:
  • Space-related fares: these may be flat or progressive, and may be zonal or interval-based, point-to point, etc. Interval based fares may be based on simple distances, numbers of stages, numbers of zones, etc.
  • Time-related fares: depending upon time-intervals, may be flat, progressive, etc
  • A combination of the two (e.g. fare structure elements are defined for zones and for time-intervals).
The main components of a fare structure are FARE STRUCTURE ELEMENTs.

A TARIFF is a particular instance of a fare structure that groups together the individual elements as a named group with common validity and other properties.
In terms of data model concepts, the description of access rights is organised in a hierarchy of three levels:
  • FARE STRUCTURE ELEMENTs (corresponding to one or more CONTROLLABLE ELEMENT).
  • VALIDABLE ELEMENTs (corresponding to one or more FARE STRUCTURE ELEMENT).
The basic component of a fare structure (FARE STRUCTURE ELEMENT) is defined as a sequence or set of CONTROLLABLE ELEMENTs to which rules for limitation of access rights and calculation of prices (fare structure) are applied.
A CONTROLLABLE ELEMENT is the smallest controllable element of public transport consumption throughout which any particular VALIDITY PARAMETER ASSIGNMENT remains valid.

Examples (see § 1.3) show the usefulness to 'chain' access rights related to different fare structures, as in a multimodal, multi-service environment combined (joint) fare products granting access to services to which access rules are determined by several organisational entities are often proposed to the public.. For example, a fare product may include the access to a car park, followed by the access to a museum, or a discount for travellers using a car park and then public transport. If the fare structure of these two components is different (e.g. flat fares for public transport and price based on duration of stay for car parking), they will be described by two different FARE STRUCTURE ELEMENTs. The discount is granted only when the validation process recognises that both have been consumed in sequence.

A sequence or set of FARE STRUCTURE ELEMENTs, grouped together to be validated in one go is called a VALIDABLE ELEMENT (A FARE STRUCTURE ELEMENT, dedicated to being consumed as such, is identical to a VALIDABLE ELEMENT).
A VALIDABLE ELEMENT may, for example, indicate the consumption rights of a PREASSIGNED FARE PRODUCT (specifying a particular trip).

A key point to grasp is that a VALIDABLE ELEMENT in effect represents the allowed set of choices (conform to the access right rules within a particular fare structure) from which a user may select for a particular step in the journey, rather than one particular single combination of such choices. Thus, continuing with our example, if the access rights are for zone A, or zone B, or a combination of the two (A+B), each with a different price, then the VALIDABLE ELEMENT may be specified using FARE STRUCTURE ELEMENTs that specify the various zone combinations which may be selected. This selection may be multidimensional – for example for a season pass there might both be a selection of zones, and a selection of time periods associated with a given VALIDABLE ELEMENT through the appropriate FARE STRUCTURE ELEMENTs. When a user comes to purchase a product (see later) a selection is made in each required dimension of the tariff structure.
As already mentioned in §1.3 above, a FARE PRODUCT is an immaterial marketable element (access rights, discount rights, etc.), specific to a CHARGING MOMENT (i.e. the payment method and the account location: pre-payment with cancellation (throw-away), pre-payment with debit on a value card, pre-payment without consumption registration (pass), post-payment etc).
So, the CHARGING MOMENT is a classification of FARE PRODUCTs according to the payment method and the account location. This means that to the "access right to the metro network" may correspond to three separate FARE PRODUCTs:
  • a pre-paid one: materialised e.g. by a throw-away ticket
  • a pre-paid one with a debit on a value card
  • a post-paid one: amount debited on a bank card.

Continuing with the example from earlier, the access right '3 hours parking followed by a trip on the bus or metro within 1 to 3 zones' is an example of a sequence of 2 access rights originating from 2 different fare structures, used in a certain order (parking followed by public transport trip) and required to be validated together.

This access right may be pre-paid or post-paid, i.e. may correspond to 2 different FARE PRODUCTs. To be noted, that the different access right elements are related to their PRICE determined through pricing algorithms (see also §6.4 below).
A FARE PRODUCT may need another FARE PRODUCT to be used, for instance an ENTITLEMENT PRODUCT, defined as a precondition to access a service or to purchase a FARE PRODUCT issued by an organisation that may not be a PT operator (e.g. military card).

Distance-based fare structure

The most common fare structure rules are space-based, or more precisely, distance-based. The three main types are respectively:

  • progressive (based on intervals), a GEOGRAPHICAL INTERVAL specifying access rights within the range of this interval: 0-5 km, 4-6 zones etc.;
  • graduated depending on a distance covered during the trip; the distance is computed using a certain unit, the most classical being the distance in kilometres, the number of fare sections (or zones) or the number of stop points. Such a graduation unit is described by the entity GEOGRAPHICAL UNIT;
  • using zones or sections; a TARIFF ZONE is a view of a ZONE, specifically defined for fare calculation; a FARE SECTION is another type of fare structure parameter: it is a subdivision of a JOURNEY PATTERN, consisting of consecutive SCHEDULED STOP POINTs in that JOURNEY PATTERN;

Some of these types may be combined together. The entity GEOGRAPHICAL STRUCTURE FACTOR makes it possible to combine two simple structures into a complex factor. It is identified by a GEOGRAPHICAL UNIT, describing the used graduation unit, and by either a GEOGRAPHICAL INTERVAL (specifying access rights for the FARE STRUCTURE ELEMENTs within the range of this interval: 0-5 km, 4-6 zones etc) or a DISTANCE MATRIX ELEMENT (a cell of an origin-destination matrix for TARIFF ZONEs or SCHEDULED STOP POINTs, expressing a fare distance for the corresponding trip: value in km, number of fare units etc.).

Main components of a time-based tariff structure

The time-based fare structures are described in a similar way to the space-based structures. The entity TIME INTERVAL describes intervals of time (0-1 hour, 1-3 hours, etc.) during which a certain fare is applied to FARE STRUCTURE ELEMENTs. A graduated time-based structure will be defined using a specified TIME UNIT (e.g. days, hours or minutes).

Both types of structures may be combined into TIME STRUCTURE FACTORs. This allows for instance to specify a fare per hour spent, which varies depending on the range of days spent.

Modelling access right rules

To model a 'fare', Transmodel uses the concept of an 'access right' to a service rather than 'pricing' or 'tarification' rules. Transmodel distinguishes between:

  • 'access rights' to a service which are represented by a set of rules (determined by a range of parameters) and related to the fare structure and
  • 'prices' which are applied to the 'access rights'.

This approach allows the combination of different rules and a flexible assignment of different parameters.

It is possible, for example to express the following rules (using the different types of parameters):

  • the access right is valid on all bus network LINEs except for LINE 278 and LINE 66’ or
  • the access right to zone 4 is not valid between 2 a.m. – 4 a.m.
Access rights are specified using an ACCESS RIGHT PARAMETER ASSIGNMENT, which allows specific access rights to be associated with fare structure components using a variety of ‘validity parameters’, each specifying which access rights may be consumed.
Access right limitation rules may be complex and involve several combinations of parameters and conditions. These rules may be expressed as logical propositions with logical operators (and, or, exclusive or). This means that different types of combinations of groups of parameters have to be taken into account and that the ACCESS RIGHT PARAMETER ASSIGNMENT is a multiple (or composite) assignment.

Access right rules may concern different components of a fare structure (e.g. FARE STRUCTURE ELEMENT, DISTANCE MATRIX ELEMENT, GROUP OF DISTANCE MATRIX ELEMENTs), products (e.g. FARE PRODUCT, SALES OFFER PACKAGE) or other elements (e.g. VALIDABLE ELEMENT, or CONTROLLABLE ELEMENT) in order to specify the specific rights that are granted or need to be validated.

The validity parameters that may be assigned with an ACCESS RIGHT PARAMETER ASSIGNMENT can be considered as being of two main categories:
  • TEMPORAL VALIDITY PARAMETERs reflecting temporal limitations, for example: DAY TYPE or OPERATING DAY on which the assignment applies, the TIMEBANDs during which the assignment applies, the VALIDITY CONDITION or AVAILABILITY CONDITION restricting the assignment.
  • SCOPING VALIDITY PARAMETERs, reflecting mainly spatial limitations, for example: which OPERATORs or GROUPs of OPERATORs, which VEHICLE MODEs and submodes, which LINEs, GROUPs OF LINEs or NETWORKs, which TARIFF ZONEs, FARE SECTIONs, which SCHEDULED STOP POINTs may be used, etc.
Fare products may also be subject to conditions as to eligibility (who may purchase a fare, adult child, senior, etc) or commercial terms (can it be exchanged, refunded, replaced etc) and other considerations.
A USAGE PARAMETER is another type of parameter linked to the actual usage of the access rights (e.g. particular user profiles, luggage allowance, booking possibility, necessary to provide a particular entitlement, etc.).
The figures below show how some of the parameters are instantiated, taking an example of the access right : 'valid on 1 to 3 zones, for bus network x operated by B, with different price according to whether the user is an adult, child or a student, transfers are allowed up to 30 minutes'


A distinction can be made between the following types of sales-related fare information:
  • sales offer: what is proposed to customers for sale,
  • travel specification; the travel choices the user wishes to make,
  • sales transaction: the record of the purchase event, including what was purchased (and how it was paid for).
  • customer purchase: the particulars of what was actually purchased and whether it has been consumed or not.
A SALES OFFER PACKAGE represents a package to be sold as a whole, consisting of one or several FARE PRODUCTs materialised thanks to one or several TRAVEL DOCUMENTs. The FARE PRODUCTs may be either directly attached to the TRAVEL DOCUMENTs, or may be reloadable on the TRAVEL DOCUMENTs.
A SALES TRANSACTION is a record of a sale of a SALES OFFER PACKAGE, which is distributed by one or more DISTRIBUTION CHANNELs. The purchase may require the selection of specific tariff elements and usage fare parameters out of all those available in the product or products.
The CUSTOMER PURCHASE PACKAGE is the result of an individual purchase of a SALES OFFER PACKAGE by a TRANSPORT CUSTOMER, giving access rights chosen from those offered by one or more FARE PRODUCTs in the offer, materialised as one or several TRAVEL DOCUMENTs.
A TRAVEL DOCUMENT is a particular physical evidence to be held by a passenger, (ticket, card, etc..) allowing the determination of the right to travel or to consume joint-services. It may comprise just a token associated with an online account, or some form of representation of the access rights. Sometimes, the TRAVEL DOCUMENT may be used by the customer as means of payment (e.g. a smartcard with an electronic purse allowing the consumption of access rights). In some cases, especially with Account Based Ticketing, there is no proper TRAVEL DOCUMENT issued: the means of payment (e.g. a credit card) plays the role of a TRAVEL DOCUMENT during the consumption.
The TYPE OF TRAVEL DOCUMENT specifies the nature of the TRAVEL DOCUMENT which can be created for a specific SALES OFFER PACKAGE. An instance of the TRAVEL DOCUMENT will be created when the SALES OFFER PACKAGE is purchased, its contents being represented by a CUSTOMER PURCHASE PACKAGE.

The Sales Transaction model is modularised into a number of sub-models:
  • The Fare Contract MODEL describes identified CUSTOMERs and their CUSTOMER ACCOUNTs and FARE CONTRACTs. The Customer Payment Means MODEL and the Customer Eligibility MODEL describe additional aspects of CUSTOMER ACCOUNTs.
  • The Retail MODEL identifies RETAIL CONSORTIUMs, ORGANISATIONs that sell products, and RETAIL DEVICEs used to sell products.
  • The Sales Transaction MODEL records sales of SALES OFFER PACKAGEs. TRAVEL SPECIFICATION ENTRYs describe each specific selection of theoretical fare elements for an individual SALES TRANSACTION.
  • The Sales Debit MODEL describes the different types of debit which may occur during the purchase and after sales of fare products (e.g. refund, exchange).
  • The SALES TRANSACTION FRAME model describes the elements used to group sales data for exchange, such as SALES TRANSACTIONs, CUSTOMER PURCHASE PACKAGEs, TRAVEL DOCUMENTs, etc.
An overview is presented below:

Certain aspects of the retailing networks that sell fare products are relevant for control purposes, and also for the provision of passenger information. The groups of approved organisations who may sell products are represented as RETAIL ORGANISATIONs; these may be any of the specific types of organisation (OPERATOR, AUTHORITY, TRAVEL AGENT, etc.) found in the reference model, who fulfil a FARE PRODUCT RETAILER ROLE.
A RETAIL CONSORTIUM is a legally incorporated ORGANISATION with two or more members that undertake the sale of certain products. It registers RETAIL DEVICEs able to sell FARE PRODUCTS and issue TRAVEL DOCUMENTs.
The RETAIL CONSORTIUM maintains SECURITY LISTs of valid and invalid RETAIL, along with those of CUSTOMERs, CUSTOMER CONTRACTs and TRAVEL DOCUMENTs.

The data model includes a set of pricing entities, which provide the factors necessary to calculate the price. Specific algorithms are responsible for applying the local price calculation rules to this basic data, but which are not themselves modelled in detail.
Prices may thus either be distributed as a set of base prices and the pricing parameters, or as fully resolved derived prices for every required fare structure element and access right.
The method used to derive a price from another price can be indicated on the price by a PRICING RULE, which can include a discount applied (DISCOUNTING RULE) and limits as to the minimum and maximum prices to be charged that are in effect (LIMITING RULE), as well as recording any tax applied. Any FARE PRICE may be calculated by PRICING RULEs, in particular discounts may be calculated using specific DISCOUNTING RULEs.

Ticketing equipment

TICKETING EQIPMENT (introduced in EN12896-2) is a specialization of PASSENGER EQUIPMENT for ticketing.

A RETAIL DEVICE is a specialisation of the TICKETING EQUIPMENT used to sell FARE PRODUCTs. Its identity can be used to record fulfilment and support security processes.
A RETAIL DEVICE is also SECULITY LISTABLE, i.e. an entity capable of being placed on a SECURITY LIST.

Control and Validation

Control is the checking of a passenger’s entitlement to consume access rights, e.g. at the start or during a trip and involves checking that the customer has an appropriate ticket and marking it as used (‘cancellation’). Multiple controls may be made on a passenger during a trip.
A control process is thus an elementary action of collecting data on the rights attached to the TRAVEL DOCUMENT being controlled and comparing it against equivalent parameters describing the actual inspection context (location, time, specific train, etc.) in order to validate it.
Validation is the verification that an access right is valid, has been consumed and that this consumption was allowed. It uses the results of one or several consecutive controls and with media centric and account based ticketing systems, may trigger the charge to the customer for the trip.
Validation is based on the comparison between the rights attached to a FARE PRODUCT stored on a TRAVEL DOCUMENT and the data collected through previous controls, characterising the actual situation. In the event that access rights are not valid, a penalty may be incurred by the traveller. In interoperable systems, validation is important for accounting between different networks.
Possible consequences of these processes are:
  • Offence, registration on security lists, etc
  • Debit
  • Possibly marking of the travel document and/or contract
  • Preparation of data for registration in the back office
An overview of the different aspects and stages of the control/validation processes and main data concepts involved are presented below.

Fare Management Events end Log Entries

The Generic Event model (introduced in EN12896-5, Annex B "Additional Common Concepts") represents interactions with a system by an external actor. An EVENT represents such an interaction, occurring on an OPERATING DAY and usually recorded in the system, having some consequences on one or more ENTITIEs. EVENTs may be classified as TYPE OF EVENTs.
The LOGGABLE OBJECT is a general-purpose mechanism allowing the recording of state of an object.
When an EVENT happens to a LOGGABLE OBJECT it is recorded as a LOG ENTRY.
A LOGGABLE OBJECT can have one or more timestamped LOG ENTRIES. LOG ENTRIES provide a detailed audit trail and may be processed to create summary statistics; they may be archived off- line.

In the context of Fare Management, the EVENTs may be either initiated variously by passengers taking PASSENGER TRAVEL EVENTs, CUSTOMER RETAIL EVENTs, CUSTOMER ACCOUNT EVENTs or CUSTOMER FULFILMENT EVENTs, or be initiated by fare control and Account Based Ticketing systems, represented by ACCOUNT PROCESSING EVENTs.

LOG ENTRies record EVENTs as different actors interact with the system. Different LOG ENTRies are relevant to different ticketing technologies, as summarised below.

As shown in the Event Model, EVENTs trigger LOG ENTRies, for instance, as shown in the Account Processing Event Model below.

Similar models describing in detail the link between the different fare management events and log entries are presented in EN12896-5. The diagram below describes the PASSENGER TRAVEL CONTROL EVENT and the associated LOG ENTRies.

Different roles of actors linked to the fare processes

To describe a fare process, a number of different roles are identified that may be associated with a given organisation. Some of these are relevant for services other than fares and ticketing, such as ACCOUNT PROVIDER ROLE, IDENTITY PROVIDER ROLE, MEDIA PROVIDER ROLE, MEDIUM APPLICATION OWNER ROLE, MEDIUM APPLICATION PROVIDER ROLE, PAYMENT PROVIDER ROLE, CUSTOMER SERVICE PROVDER ROLE.
Others are specific to fares, such as FARE PRODUCT OWNER ROLE, FARE PRODUCT RETAILER ROLE, FARE PRODUCT DISTRIBUTOR ROLE, etc. Extended distribution for rail may also involve FARE PRODUCT ISSUER and FARE PRODUCT ATTRIBUTOR ROLEs.
The ROLEs can be considered as specialisations of the general roles shown in the diagram below (EN12896-5, Annex B).

The generic model representing the assignment of responsibilities to an ORGANISATION or an ORGANISATION PART is presented in EN12896-1.
An overview of the Management Roles of an ORGANISATION is presented below.

The abstract class ORGANISATION ROLE, defined as a generic corporate role to provide or manage transport services, splits into concrete roles, among which into a range of roles related to fare management, as shown in the diagram below.
Most of these roles have extensively been described by ISO 24014-1 (Integrated Fare Management) and by the Full Service Model (cf. EN12896-5, Bibliography). Transmodel takes over the semantics of these roles, although, in some cases uses own terminology (role names).
Specific FARE ORGANISATION ROLEs are also defined and related to the relevant concepts of the Fare Model.
An ORGANISATION may have the responsibility to provide any kind of travel related service, i.e. fulfil the TRAVEL ORGANISATION ROLE.

The responsibility for the fare control process is shared between the SERVICE OPERATOR ROLE providing any automated barriers and other control equipment, and the TRAVEL DOCUMENT CONTROLLING ORGANISATION ROLE which undertakes control activities; the execution of inspection and other duties may be allocated to individual EMPLOYEEs performing a TRAVEL DOCUMENT CONTROLLER ROLE. The diagram below shows the link of these roles with the related data structures.

Operations Monitoring and Control

Operations Monitoring and Control
EN12896 – 4

The domain of operations monitoring and control concerns all activities related to the actual transportation process. It is also known as real-time control, or operations management.

The supply basis for each operating day is known as a production plan, composed of the planned work of each available resource (e.g. vehicles and drivers). It includes for instance all dated journeys planned on the considered day, including occasional services.

The transportation control process supposes a frequent detection of the operating resources (in particular vehicle identification and location tracking). Such collected information is compared to the planned data (e.g. work plan for a vehicle or a driver), thus providing a monitoring of these resources.

The monitored data is used for:

  • controlling the various resource assignments (e.g. vehicle assignment to a dated block);
  • assisting drivers and controllers to respect the plan (e.g. schedule adherence, interchange control);
  • alerting on possible disturbances (e.g. delay thresholds, incidents);
  • helping the design of corrective control actions according to the service objectives and overall control strategy; the model describes a range of such control actions (e.g. departure lag);
  • activation of various associated processes (e.g. traffic light priority, track switching);
  • passenger information on the actual service (e.g. automatic display of the expected waiting time at stop points); and
  • follow-up and quality statistics.

Dated production components

The operational management of public transport is classically divided into two distinct phases:
  • “tactical planning” phase, consisting of designing and building a reference schedule and
  • a further phase of adapting the reference schedule to the real operating conditions, in a plan that is constantly updated during the OPERATING DAY. This phase is known as “real-time control” and called here Operations Management and Control.
Operations require an operational plan for each OPERATING DAY. Such dated plans are elaborated in anticipated time, on a short-term horizon (a few days or possibly a few weeks before the day of operations) and frequently updated. They are usually derived from tactical plans for DAY TYPEs. The latter are assigned to OPERATING DAYs, according to rules taking into account the characteristics of the considered calendar (SERVICE CALENDAR) and the PROPERTies OF DAY assigned to each OPERATING DAY (see also EN12896-1).

Many reasons lead to modification of the operational plan in the short term: special events; changes in the road infrastructure; incidents; etc. Some VEHICLE JOURNEYs may be added or deleted, may use alternative or shortened ROUTEs and JOURNEY PATTERNs, occasional services may be added, etc. If these changes are only valid for one or a few days, the reference schedule for a DAY TYPE is not modified, but the changes are only stored for the appropriate OPERATING DAYs.
DATED VEHICLE JOURNEY describes a vehicle journey planned for one specific OPERATING DAY.

NORMAL DATED VEHICLE JOURNEYs are based upon a VEHICLE JOURNEY, as produced for a DAY TYPE by the scheduling process.
EXTRA DATED VEHICLE JOURNEYs may be created to complement a DATED VEHICLE JOURNEY that is already running.
DATED SPECIAL SERVICEs are created following the same principles. Regular services will be derived from a SPECIAL SERVICE planned for a DAY TYPE.
The changes made in the DATED VEHICLE JOURNEYs often generate changes in the BLOCKs planned for a DAY TYPE. Therefore, it is necessary to define DATED BLOCKs, which will be valid only on a specific OPERATING DAY.
A DATED VEHICLE JOURNEY may be subdivided into DATED JOURNEY PARTs. DATED JOURNEY PARTs may be using planned JOURNEY or may be created ad-hoc. One situation when this is of interest is when coupling or un-coupling trains.
An overview of the dated production components is provided in EN12896-4.
DATED JOURNEY PARTs are useful, for example, for the description of the coupling and uncoupling of trains.
Two trains T1001 and T2002 may operate on the same or different OPERATING DAYs and serve some common stations. Coupling and uncoupling may occur, so there may be
  • VEHICLE JOURNEYs operated by train T1001 serving stations A – B – C
  • VEHICLE JOURNEYs operated by Train N°2002 serving stations A – B – D coupled with T1001 between A and B and then uncoupled in B.

Coupling and uncoupling and thus the components of the DATED VEHICLE JOURNEYs depends upon the OPERATING DAY.
The concept of DATED JOURNEY PART is used to describe such situations.

Production plan

The boundary between tactical planning and real-time control is, in most cases, fixed arbitrarily (e.g. at the beginning of the OPERATING DAY, two days in advance, etc).
Such a limit is often marked by the freezing of a PRODUCTION PLAN which will be the reference for real-time control on a whole OPERATING DAY.
Several VERSION FRAMEs may be combined in a PRODUCTION PLAN (e.g. three VEHICLE SCHEDULE FRAMEs covered by one DRIVER SCHEDULE FRAME).

Resource detection and monitoring

It is important to distinguish between detection and monitoring, because a detected vehicle is not necessarily monitored if the available information is not sufficient to describe a monitored situation.
The basic objective of on-line control and of the systems aimed at assisting AVM is to monitor vehicles in order to implement various actions (follow-up of the service, corrective control actions, activation of passenger information devices or traffic light priorities, etc.). The detection in itself is not really a concern for the reference data model but is a tool to allow the monitoring to be done.
The process of detection consists of recognising a vehicle and assigning some data collected by the detection devices to it.
The detected data may be variable, according to the system capabilities, and multiple data of different types such as physical location, speed, direction, doors opened, occupancy etc. can be included in a VEHICLE DETECTING.
Each kind of data can be separately registered as a VEHICLE DETECTING LOG ENTRY and marked with the appropriate TYPE OF VEHICLE DETECTING.
VEHICLE DETECTING LOG ENTRY: a record of detected crude real time data that is recognized to be related with a certain VEHICLE.
The most classical detected information is the vehicle location, which may be:
  • a POINT (e.g. the vehicle passes an ACTIVATION POINT, such as a beacon),
  • a LINK (rail systems often detect the presence of a train on an INFRASTRUCTURE LINK), or
  • another location, e.g. described by coordinates.

The vehicle monitoring consists of computing all available data, in particular the latest valid plan and the data collected through the detection process.
VEHICLE MONITORING must be related to one LOGICAL VEHICLE. It is identified by this LOGICAL VEHICLE, and a ‘timestamp’ which describes the time of the monitored situation (at this point in time, the vehicle is recognised as operating this vehicle journey), rather than the time at which it is recorded.
It is occurring either on a
  • MONITORED VEHICLE JOURNEY: a journey that is monitored as being operated by a LOGICAL VEHICLE; or on a
  • MONITORED SPECIAL SERVICE: a special service that is monitored as being operated by a LOGICAL VEHICLE.
TYPE OF VEHICLE MONITORING describes various types of monitored situations.
A single VEHICLE MONITORING may also result in multiple, related VEHICLE MONITORING LOG ENTRies noting the observed passing time of a point and the calculation of estimated passing times at a number of later points for the same vehicle.

Control actions

A CONTROL ACTION is an action resulting from a decision taken by the controller causing an amendment of the operation planned in the PRODUCTION PLAN.
Thus, CONTROL ACTIONs may produce changes in the structure of the activities performed by different resources, e.g. modifications made on journeys cause modifications in the duration of a driver’s continuous work in the same vehicle.
The CONTROL ACTION may be of different types:
  • COMPOSITE JOURNEY CONTROL ACTION affecting a set of DATED VEHICLE JOURNEYs with a correlated set of adjustments:
  • DRIVER CONTROL ACTION affecting a LOGICAL DRIVER (described in EN12896-7).

JOURNEY CREATION action is an elementary action in which a completely new DATED VEHICLE JOURNEY is added to the latest valid plan. This action is often complemented by other actions (e.g. RESPACING).
FLEXIBLE JOURNEY ACTIVATION control action consists to activate DATED VEHICLE JOURNEYs with booking pre-conditions.
JOURNEY CANCELLATION action is an elementary action consisting of deleting a DATED VEHICLE JOURNEY from the latest valid plan. It is often complemented by other actions (e.g. RESPACING).

PARTIAL JOURNEY CANCELLATION is similar to JOURNEY CANCELLATION, with the difference that the complete DATED VEHICLE JOURNEY is not cancelled, only part of it. It can be seen as deleting part of a DATED VEHICLE JOURNEY from the last ordered plan. It can also be viewed as assigning a JOURNEY PATTERN that is a subset of the original JOURNEY PATTERN to a DATED VEHICLE JOURNEY, and thus being a special case of CHANGE OF JOURNEY PATTERN highlighting the reduction of service aspect.
CHANGE OF JOURNEY PATTERN action consists of assigning a different JOURNEY PATTERN (and the ROUTE supporting it) to a DATED VEHICLE JOURNEY from that which was originally planned. The modification may for instance consist of using an alternate ROUTE when some part of the normal ROUTE is blocked.
CHANGE OF JOURNEY TIMING action consists of changing one or several characteristics of a DATED VEHICLE JOURNEY related to several timing aspects, such as departure time of the journey from the first POINT IN JOURNEY PATTERN (the most frequent case), departure time of the journey from an intermediate POINT IN JOURNEY PATTERN, TIME DEMAND TYPE assigned to the journey etc.
  • RESPACING consisting in respacing departure times at one POINT after a journey or a vehicle has been added or cancelled, in order to preserve the regularity of intervals.
  • RESORPTION consisting in progressively resorbing a delay on one DATED VEHICLE JOURNEY by rescheduling the departure times at one POINT of the following journeys. It is a way of maintaining regular intervals after a disturbance on a particular journey.
  • DEPARTURE EXCHANGE consisting in permuting at one POINT the departure times of two or several DATED VEHICLE JOURNEYs.
  • DEPARTURE LAG consisting in gradually shifting a set of departures at one POINT. It allows a change of the timetable without abrupt variations in the intervals.

INTERCHANGE CONTROL ACTIONs are used when there is a need to make short-term changes to the current set of DATED VEHICLE JOURNEY INTERCHANGEs.

A DATED VEHICLE JOURNEY INTERCHANGE specifies that a certain DATED VEHICLE JOURNEY (the distributor) should wait for another specified DATED VEHICLE JOURNEY (the feeder) to arrive before departing from a shared stop even if the feeder is somewhat delayed. There will be a specified limit for how long the distributor must wait at the most.
  • VEHICLE ASSIGNMENT: action consisting in the assignment, or the cancellation of an assignment, of a physical VEHICLE to a LOGICAL VEHICLE. This assignment may be overridden by a further assignment.
  • VEHICLE WORK ASSIGNMENT: action consisting in the assignment, or the cancellation of an assignment, of a LOGICAL VEHICLE to a planned work, represented as DATED BLOCKs or as DATED VEHICLE JOURNEYs. This assignment may be overridden by a further assignment.
  • LOGICAL VEHICLE CREATION: action consisting in creating a completely new LOGICAL VEHICLE (e.g. reinforcement or replacement resource). It is often accompanied by a VEHICLE WORK ASSIGNMENT, in order to assign a work plan to the new resource.
  • LOGICAL VEHICLE CANCELLATION: action consisting in removing a LOGICAL VEHICLE from the PRODUCTION PLAN. The work assigned to it (DATED BLOCKs and DATED VEHICLE JOURNEYs) may remain unassigned for a while.
  • CHANGE OF VEHICLE: action consisting in removing, at a certain point in time and space, all work assigned to a LOGICAL VEHICLE and assigning it to another LOGICAL VEHICLE. Any CHANGE OF VEHICLE is completed by the appropriate VEHICLE WORK ASSIGNMENT. A CHANGE OF VEHICLE is often accompanied by one or two VEHICLE ASSIGNMENTs, replacing also the physical vehicles.

Events and messages

Transmodel considers the concept of OPERATIONAL EVENT, a specialisation of the generic EVENT for the purpose of the monitoring and control operations.
OPERATIONAL EVENT is defined as any event affecting the public transport operation (production follow-up, management of information or the technical functioning), occurring on an OPERATING DAY and recorded in the system. An OPERATIONAL EVENT is generally causing a CONTROL ACTION.

The main subtypes of OPERATIONAL EVENTs are
  • ALARMs: alerting the staff in charge of operations control on a probable dysfunction: operational threshold exceeded (e.g. delay), emergency call, failure, etc;
  • INCIDENTs: unforeseen EVENTs influencing the operation of the network;
One or several OPERATIONAL EVENTs may be recorded as being the cause of one or several CONTROL ACTIONs.
An OPERATIONAL EVENT may be the subject of an OPERATIONAL MESSAGE. An OPERATIONAL MESSAGE is defined as an information exchange between an EMPLOYEE (e.g. a controller), a LOGICAL DRIVER or a LOGICAL VEHICLE, used to inform about a CONTROL ACTION or an EVENT (see Operational Message Model in EN12896-4).

Evolution of the transport situations

SITUATION is defined as an incident or deviation affecting traffic or travel circumstances. It's specialisation - PT SITUATION - is defined as an incident or deviation affecting the planned PT operation.
RELATED SITUATIONs represent alternate or partial views of the same SITUATION.
A detailed and structured description of causes and consequences regarding a situation, is necessary for passenger information purposes.

SITUATION CAUSE (classified by SITUATION REASON) is an event or set of events inducing a change in public transport or traffic operation.
The origin of the incident or deviation information is described in the SITUATION SOURCE.
The part or parts of the public transport operation that are directly related to the PT SITUATION are represented by the PT SITUATION AFFECTED SCOPE.
  • DELAYs (description of deviations from the public transport timetable),
  • CASUALTIES (description of the number of persons that have been injured or died), or
  • EASEMENTs (description of temporary (fare) exceptions allowed because of disruptions),
which may also occur in a wider public transport scope as described by the PT SITUATION CONSEQUENCE SCOPE.
For example, a bus line that is not directly affected by the incident may still be indirectly affected because stranded passengers might use this bus line instead of their intended bus line, leading to crowding. There could also be passengers that normally change from this bus line to a bus line directly involved in the incident that need to know about the problem so that they can revise their trip accordingly.

The same structure of detailed situation, its causes and consequences, is used by SIRI Situation Exchange service (CEN/TS 15531-5:2016) and a similar structure is present in the DATEX II Situation Publication.

Monitoring of facilities

A MONITORED FACILITY represents a named amenity or capability where the state of availability is monitored.

Five different types of MONITORED FACILITies are identified:
  • A MONITORED PLACE EQUIPMENT FACILITY that is enabled by a PLACE EQUIPMENT such as an escalator or a lift;
  • A MONITORED LOCAL SERVICE FACILITY that is enabled by a LOCAL SERVICE such as porterage services at a station;
  • A MONITORED VEHICLE EQUIPMENT FACILITY that is enabled by an ACTUAL VEHICLE EQUIPMENT installed on board an individual vehicle such as a ramp or automatic doors;
  • A MONITORED VEHICLE JOURNEY FACILITY that relates to SERVICE FACILITY SETs such as “First Class Couchette with shower and 2 bunks” that are available for enhancing a VEHICLE JOURNEY; and
  • A MONITORED JOURNEY PART FACILITY that relates to SERVICE FACILITY SETs but that are available only on part of the VEHICLE JOURNEY.
It is of often of interest to assure that different facilities involved in public transport are currently available and/or whether a replacement facility is proposed.
First, it is of interest to know what FACILITY MONITORING METHOD is used for the monitoring. FACILITY MONITORING METHOD describes the method and circumstances used to monitor a facility such as manual or automatic, what is the frequency of monitoring , etc.
A FACILITY CONDITION describes a changed state of availability for a MONITORED FACILITY.
A FACILITY STATUS categorizes the change to availability of the facility, such as being removed, unavailable or only partially available.
A PLANNED REMEDY is a pre-prepared counter-measure to compensate a deviating FACILITY CONDITION, that could include utilizing an alternative FACILITY as a replacement.

A mechanism for exchanging information describing the current status of facilities is specified in CEN/TS 15531-5:2016.
An often asked question concerns the link between the facilities and the different types of equipment defined in Transmodel. The diagram below provides this link in the context of installed equipment, in particular at stops.

A more complete overview is provided in the figure below.

Common Concepts


The concept of VERSION is used for this. A VERSION is a group of operational data instances which share the same VALIDITY CONDITIONs. A version belongs to a unique VERSION FRAME and is characterised by a unique TYPE OF VERSION (which is a classification of VERSIONs.  E.g shareability of ENTITies between several versions).

A VERSION FRAME is a set of VERSIONS referring to a same DATA SOURCE and belonging to the same TYPE OF FRAME. A FRAME may be restricted by VALIDITY CONDITIONs.


Generic Version Model 

VERSIONS refer to data instances, as an ENTITY is defined as any data instance to be managed in an operational Version Management System. When several data sources coexist (multimodality and/or interoperability), an ENTITY has to be related to a given DATA SOURCE in which it is defined.

However, records of attribute changes may also be managed as shown in the diagram below, where DELTA is a  record of the detailed changes of a given ENTITY IN VERSION from one VERSION to the next one.  A DELTA contains pairs of attributes’ old values – new values.

generic data model

Generic Delta Model 

Validity Conditions

A VALIDITY CONDITION  is a condition used in order to characterise a given VERSION of a VERSION FRAME. A VALIDITY CONDITION consists of a parameter (an ENTITY e.g. date, or a VALIDITY TRIGGER i.e. a triggering event, etc.) and its type of application (expressed in the VALIDITY RULE PARAMETER e.g. for,  from,  until, etc.).


Generic Validity Model 

An  AVAILABILITY CONDITION is a VALIDITY CONDITION expressed in terms of temporal parameters and referring to DAY TYPEs.


Availability Condition Model


Transmodel data will be used in different environments that can have a complex organisational structure. For instance, information is planned, revised, forwarded, enriched, combined with other plans and forwarded again to the final user at some time. This process often involves several organisations or departments.

As different aspects of public transport could be handled by different organisation parts, and sometimes are subcontracted to third parties, it is often useful to describe who is responsible for a specific role, within the delivered data. Examples of RESPONSIBILITY ROLEs are: Data Origination, Data Augmentation, Data Aggregation, Planning, Operation, Control Centre (directive pt-management centre), Monitor Centre (only receiving and collecting data), Data IPR Ownership, Entity Legal Ownership, Scheduler, StopPointManager,, RoadManager, RoadDisplayManager, SubContractor, Travel Information ServiceProvider, etc.

(Generic Organisation Model, Responsibility Role Model).


Generic Organisation Model


Responsibility Role Model

A RESPONSIBILITY SET is a list of possible responsibilities over one or more ENTITies (IN VERSION), resulting from the process of the assignment of RESPONSIBILITY ROLEs (such as data origination, ownership, etc) on specific data (instances) to ORGANISATIONs or ORGANISATION PARTs. Each RESPONSIBILITY SET can contain one or more RESPONSIBILITY ROLE ASSIGNMENTs that allocate different types of RESPONSIBILITY ROLE to an ORGANISATION or a specific ORGANISATION PART.

RESPONSIBILITY SETs may be used at different levels of aggregation. It is possible to specify a different set for each different ENTITY.


Responsibility Role Model

The Generic ORGANISATION Model defines abstract ORGANISATION elements that can be used wherever there is a need to describe an organisation. It is extended with AUTHORITY, OPERATOR and other concrete organisation definitions specifically relevant for the transport domain.

An ORGANISATION PART of an ORGANISATION acts as an ORGANISATIONAL UNIT responsible for the determination of the PT Services, that need to be delivered in an OPERATIONAL CONTEXT often defined or limited to one TRANSPORT MODE or even to one VEHICLE MODE or SUBMODE of one of its DEPARTMENTs. This defines the actual involved OPERATING DEPARTMENT that will act as the serving OPERATOR directly in charge of operations, and, when a contractual link to an AUTHORITY exists, for the ordered services by the public transport AUTHORITY. The serving OPERATORs can be combined for executing this service in a GROUP OF OPERATORS (Generic Organisation Model, Transport Organisations Model).


Responsibility Role Model


Transport Organisations Model

Generic Framework

Points and Links

Topological descriptions of the spatial structure of a public transport network are generally built with points. Thus, an entity POINT is defined as the most basic entity of the network model. A POINT represents a 0-dimension node of the network. It marks the location of bus stops, parking places or other types of POINTs.

Between two POINTs of any type, a LINK may be defined to store spatial information (e.g. the distance a vehicle will cover crossing this link). LINKs represent 1-dimensional connections between POINTs. There must be no LINKs without one limiting POINT at each end. Two relationships between the POINT and the LINK entity specify the limiting POINTs of a LINK. A LINK is oriented from its start POINT to its end POINT.

Transmodel makes it possible to represent the network either as a graph of points or of arcs.

An ordered set of POINTs or LINKs is called a LINK SEQUENCE. These are the generic building blocks of the Public Transport network model. Their specialisations represent concrete special Public Transport objects, like scheduled stop points, routes, service links, etc.


Generic Point and Link Sequence Model

The LOCATION provides a representation of the basic coordinates of those entities that are located in space, for example, POINTs and LINKs and ZONEs. The location is dependent on the LOCATING SYSTEM used. Given a LOCATING SYSTEM, every POINT may be located in this system by a LOCATION. Transmodel uses a subset of the Open Geospatial Consortium’s Geographic Mark-up Language (OGC GML) schema to define coordinates (Location Model).

Topological ENTITIES used for describing a transport network can be grouped into different LAYERs i.e. user-defined GROUPs OF ENTITies, specified for a particular functional purpose, associating data referring to one particular LOCATING SYSTEM (Generic Layer Model).


Location Model


Generic Layer Model

Network data are submitted to VERSIONs and may be grouped to form coherent sets of data using the VERSION FRAME mechanism. VERSION FRAMEs allow data to be managed and exchanged as a coherent version, that is a set of instances (ENTITies IN VERSION) of different entity types that are consistent and correct as to referential integrity and other business semantics and so are suitable for use without extensive consistency checking, for example, by an importing application (Generic Version Model & Generic Version Frame Model).


Generic Version Model


Generic Version Frame Model

Link Sequences

The LINK SEQUENCE Model defines a set of POINTs and/or LINKs making up a path through a network.

It allows a path to be described as a sequence of points, a sequence of links, or both; both views are relevant for different use cases. Specialisations of LINK SEQUENCEs are for example ROUTE, JOURNEY PATTERN, TIMING PATTERN etc. and represent concrete Public Transport paths (Point and Link Sequenece Model).


Point and Link Sequence Model


Transmodel defines a generic GROUP OF ENTITIES as a set of ENTITies, grouped together according to a functional purpose (PURPOSE OF GROUPING).

A concrete example of a use of such grouping is a STOP AREA, that is a grouping of stops known to the public by a common name (Generic Grouping Model).

Other types of sets of entities than groupings are FRAMEs (Generic Version Frame Model) or LAYERs (Generic Layer Model).


Generic Grouping Model


Generic Layer Model

GROUPs OF POINTs, LINKs or LINK SEQUENCEs have a particular importance. A GROUP OF POINTS may be used to describe a central or complex station, consisting of all stops serving the whole area of this station, or any important interchange area. In such a case, the PURPOSE OF GROUPING of the GROUP OF POINTS will limit the grouped POINTs to a certain TYPE OF POINT. This allows one to use classical stop areas to describe limited sets of stops (e.g. a couple of bus stops close to the station). A GROUP OF POINTS may also be used to describe operational clusters, consisting of  POINTs of different types, e.g. located close to each other and/or operationally belonging to an object known by a particular name (e.g. train station, from the operational point of view).

A GROUP OF LINKs may be all LINKs in a tunnel, all LINKs in an urban area, etc.

A concrete GROUP OF LINK SEQUENCEs may be a LINE, i.e. a grouping of ROUTEs that is generally known to the public by a similar name or number (Explicit Grouping Possibilities Model).


Explicit Grouping Possibilities Model


A ZONE is a two-dimension object used in the network description (e.g. administrative area, tariff zone, flexible transport zone). ZONEs are classified according to a TYPE OF ZONE.

A ZONE may be defined by a GROUP OF POINTS belonging to the ZONE. For instance, a TARIFF ZONE used to define a zonal fare structure in a zone-counting or zone-matrix system may be composed of a set of stop points.A ZONE may also be defined as a geometric area, bordered by a LINK SEQUENCE (a polygon). In such a case, this LINK SEQUENCE has to be a closed one (i.e. the first and last POINTs IN LINK SEQUENCE must be a view of the same POINT). A ZONE may be recursive, and include other smaller ZONEs (Generic Zone Model).


Generic Zone Model

Point and Link Types

A TYPE OF POINT is defined as an entity to describe common roles played by a number of POINTs. Each POINT is functionally classified as being of one or more types, according to the specific information needs of a particular functional domain. Certain TYPEs of POINTs are regarded as important enough to be additionally represented by a separate concept. The most important of these are: the SCHEDULED STOP POINT, TIMING POINT, ROUTE POINT.

Other explicitly defined types are specialisations of the TIMING POINT: RELIEF POINT, PARKING POINT, GARAGE POINT (Vehicle & Crew Point Model) or points specifically dedicated to operations control: TRAFFIC CONTROL POINT, ACTIVATION POINT, BEACON POINT (Activation Model).


Main Network Points and Links Model


Vehicle & Crew Point Model


Activation Model

A SCHEDULED STOP POINT is a POINT where passengers can board or alight from vehicles.

A TIMING POINT is a POINT against which the timing information necessary to build schedules may be recorded.

Some operators may want to define run times between any pair of SCHEDULED STOP POINTs (related by a SERVICE LINK). In such a case, probably all SCHEDULED STOP POINTs of the network will also be classified as TIMING POINTs. Other companies will define run times only for a selection of SCHEDULED STOP POINTs: only these will be at the same time TIMING POINTs and SCHEDULED STOP POINTs.  The times related to the rest of the stops would then be derived by processing (e.g. interpolation). Some POINTs, such as garage entry or exit points that are TIMING POINTs only.

Transmodel defines three particular types of POINTs dedicated to Operations Monitoring and Control, namely: ACTIVATION POINT(a POINT where a control process is activated when a vehicle passes it), TRAFFIC CONTROL POINT (a POINT where the traffic flow can be influenced, e.g. where  traffic lights (lanterns), barriers, etc are present) and BEACON POINT (ACTIVATION POINT where a beacon or similar device to support the automatic detection of vehicles passing by is located).
ACTIVATION POINTs may be start/end of an ACTIVATION LINK.  (Activation Model).

ND Activation Model

Activation Links Model

Complex Objects

It is often necessary to define a group of objects of different types in a simpler representation, omitting the details. For instance, a train station composed of tracks, platforms, vending machines, etc., or a depot composed of halls, parking areas, lanes, maintenance facilities, etc., are viewed in some layers as single POINTs. This is described by the entity COMPLEX FEATURE (named by analogy with the GDF standard and usual GIS wording).A COMPLEX FEATURE is composed of one or more SIMPLE FEATUREs. A SIMPLE FEATURE is identical to an instance of either a POINT, a LINK, or a ZONE.

A COMPLEX FEATURE usually combines elements of different kinds such as POINTs, LINKs, ZONEs (each of them not necessarily of the same type), and even other COMPLEX FEATUREs. It should not be mixed up with a group of elements (e.g. GROUP OF POINTS), combining elements of one single type only, for example one GROUP OF LINKs may be all LINKs in a tunnel, which is not a COMPLEX FEATURE (Generic Feature Model).


Generic Feature Model

Layers and Projections

Topological ENTITIES used for describing a transport network can be grouped into different LAYERs. Each LAYER is associated with a one and only one LOCATING SYSTEM, and the entities belonging to the LAYER have a position within this LOCATING SYSTEM. Examples of layers include:

  • Infrastructure layer: describes road or rail network.
  • Route layer: describes route topology.
  • Service layer: describes network of stops served by routes.
  • Timing layer: describes location of timing points and times between them.

(Generic Layer Model).


Generic Layer Model

The mechanism for relating ENTITIES of one LAYER to ENTITIES of another LAYER is called projection. Projection can happen implicitly by transforming the entity position from the source LOCATION SYSTEM to the destination LOCATION SYSTEM. However, there are cases where such automatic transformation is not possible or practical, e.g. if a route needs to be displayed on a schematic map, there is no way of calculating the positions from the spatial coordinates. Transmodel therefore contains a mechanism for explicitly projecting (spatial) entities of one layer to another layer (Generic Projection Model).


Generic Projection Model

The functional views of the network are described as layers. A projection is a mechanism enabling the description of the correspondence between the different layers. This mapping between the layers is particularly useful when spatial data from different environments (sources, functional domains) have to be combined. An example of such a situation is the mapping of the public transport network on the road network or any other correspondence between coherent sets of topological objects often defined by different deparments of a company.

The POINT PROJECTION is used to project a point of a source layer to an ENTITY of the target layer. The target ENTITY can be a POINT or LINK, but not a ZONE. If the target of POINT PROJECTION is a link, the distance from the start of the link is set in POINT PROJECTION.

The LINK PROJECTION is used to project a LINK on one or more LINKs of another layer. As a precondition, the destination link must have one or more POINT ON LINK entities associated with it. The start and end point of the source link are projected on POINT ON LINK of the destination LINKs. An example of LINK projection might be the projection of a LINK between two stops to the LINKs of the road (or rail).

A ZONE PROJECTION involves a ZONE as source. The projected ZONE may be targeting either one POINT or one COMPLEX FEATURE.

The ZONE PROJECTION targeting a POINT expresses that the source ZONE is represented by a POINT in the target layer.The ZONE PROJECTION targeting a COMPLEX FEATURE means that the source ZONE belongs to the COMPLEX FEATURE described in the target layer.

A COMPLEX FEATURE PROJECTION involves a COMPLEX FEATURE as source. The projected COMPLEX FEATURE can be targeting another COMPLEX FEATURE or a POINT (Generic Projection Model).


Generic Projection Model


The accessibility of a site is described using an ACCESSIBILITY ASSESSMENT: this allows to express the accessibility either in terms of suitability for specific USER NEEDs – for example wheelchair, hearing impaired, vision impaired, lift-averse, etc. – using a SUITABILITY element, or in terms of ACCESSIBILITY LIMITATIONs, i.e. description of the limitations of a site to support a specific need, for example Wheelchair, Step free, Escalator free, Lift free or both.

Accessibility Model

Accessibility Model 


A PLACE is defined as a geographic place of any type which may be specified as the origin or destination of a trip. A PLACE may be of dimension 0 (a POINT), 1 (a road section) or 2 (a ZONE).

The PLACE model defines topographically significant places that a transport model may wish to describe.

It also allows the description of the possibility of connecting between them. ACCESS  indicates the physical (spatial) possibility for a passenger to access or leave the public transport system. This link may be used during a trip for:- the walking movement of a passenger from a PLACE (origin of the trip) to a SCHEDULED STOP POINT (origin of the PT TRIP), or- the walking movement from a SCHEDULED STOP POINT (destination of the PT TRIP) to a PLACE (destination of the trip) (Generic Place Model).


Generic Place Model

Reusable Components


Transmodel takes into account a variety of Public Transport MODEs (characterisation of the public transport operation according to the means of transport (bus, tram, metro, train, ferry, ship)). A distinction is made  between VEHICLE MODE and ACCESS MODE. The concept of MODE is refined into SUBMODE, a variant of a MODE, as for instance international or domestic rail (rail being the MODE).


Submode Model


In Transmodel, a DAY TYPE is defined as a combination of various different properties a day may have, and which will influence the transport demand and the running conditions (e.g. traffic flow for buses).

Any single condition that is relevant to the demand will be recorded as a particular PROPERTY OF DAY. For example, “workday”, “Sunday”, “school holiday”, “market day” would each be a PROPERTY OF DAY. A workday during school holidays, which is a market day, would be a DAY TYPE, formed with the combination of those three PROPERTies OF DAY.

The day of operation, considered from the point of view of the transportation process control, is described by the entity OPERATING DAY.The time limits of an OPERATING DAY will often deviate from the official date. One day of operation covers for instance the period from 2.00 a.m. to 1.59 a.m. the day after, the period from 0.00 to 1.59 on the second day being assigned to the operational day which started the day before.

The production planning requires that a DAY TYPE is assigned to each OPERATING DAY, which is frequently referred as a “transportation calendar” or – in The Conceptual Model – as a SERVICE CALENDAR


Service Calendar Model

The Validity Model allows conditions to be attached to elements as to when they are current or the circumstances in which they should be used. VALIDITY CONDITIONs can be attached to specific elements and also, through version frames, to whole sets of objects so that it is possible to be explicit about the exact conditions governing the coherence and relevance of data.

AVAILABILITY CONDITION is a specialization of VALIDITY CONDITION to specify precise temporal conditions. For example, an access to a station may be valid (it exists) but not available for some of the time (it is closed between 9 pm and 6 am). An AVAILABILITY CONDITION can be defined by specific DAY TYPEs and/or OPERATING DAYs. It may be further qualified by one or more of TIME BANDs.


A TOPOGRAPHIC PLACE is a type of PLACE providing the topographical context when searching for or presenting travel information, for example as the origin or destination of a trip. It may be of any size (e.g. County,City, Town, Village) and of different specificity (e.g. Greater London, London, West End, Westminster, St James’s). A TOPOGRAPHIC PLACE may be located within one or more COUNTRies. TOPOGRAPHIC PLACEs may overlap. They may also be contained inside another TOPOGRAPHIC PLACE.

ADDRESS is the descriptive data associated with a PLACE that can be used to describe the unique geographical context of a PLACE for the purposes of identifying it. May be refined as either a ROAD ADDRESS, a POSTAL ADDRESS or both (Topographic Place Model).


Topographic Place Model

Equipment and Facility

Transmodel defines a generic concept EQUIPMENT that specialises into

  • INSTALLED EQUIPMENT, an item of equipment either fixed (PLACE EQUIPMENT) or on board i.e. associated with vehicles (ACTUAL VEHICLE EQUIPMENT). PASSENGER EQUIPMENT may be either fixed or on-board. INSTALLED EQUIPMENT is materialised as opposed to a service (LOCAL SERVICE) considered as an immaterial equipment.
  • PLACE EQUIPMENT is described in a very detailed way through a range of concrete classes (cf. Part 2: Waiting & Luggage Equipment, Passenger Service Equipment, Ticketing Equipment, Access Equipment, Sign Equipment Models)
    • 1

      Generic Equipment Model


      Waiting & Luggage Equipment Model


      Passenger Service Equipment Model


      Ticketing Equipment Model


      Access Equipment Model


      Sign Equipment Model

Vehicle equipment is defined through the entity ACTUAL VEHICLE EQUIPMENT. Two types are particulary important for accessibility VEHICLE ACCESS EQUIPMENT and WHEELCHAIR VEHICLE EQUIPMENT.


EQUIPMENT is an item of equipment installed either fixed (PLACE EQUIPMENT)  or on-board vehicles (VEHICLE EQUIPMENT). A service (LOCAL SERVICE such as LEFT LUGGAGE, TICKETING SERVICE) is considered as immaterial equipment as well (Generic Equipment Model).

A named amenity available to the public at a SITE or on a SERVICE. A facility has no further properties other than a name. An EQUIPMENT or LOCAL SERVICE is used to describe the further properties provided as part of particular facility (Facility Model).


Facility Model

Vehicle Type and Train

The VEHICLE entity is used to describe the physical public transport vehicles available for short-term planning of operations and daily assignment (in contrast to logical vehicles considered for resource planning). Each VEHICLE must be classified as of a particular VEHICLE TYPE.

The VEHICLE TYPE Model represents a description of VEHICLES through their properties.


Vehicle type Model

A TRAIN is a VEHICLE TYPE composed of TRAIN ELEMENTs in a certain order, i.e. of wagons assembled together and propelled by a locomotive or one of the wagons.


Train Model

VEHICLE TYPE is a classification of public transport VEHICLEs according to the vehicle scheduling requirements: in mode and capacity (PASSENGER CARRYING REQUIREMENT, e.g. standard bus, double-deck, …), and/or as regards maneuvering capabilities (MANOEVRING REQUIREMENT), and/or according to the facilities available on the vehicle (FACILITY REQUIREMENT).


Vehicle type Model

Vehicle Scheduling

Chaining vehicle journeys into blocks of vehicle operations is one of the main functions of vehicle scheduling.

The corresponding entities and relationships included in the reference data model allow a comprehensive description of the data needs associated with this functionality, independently of the particular methods and algorithms applied by the different software systems.

A VEHICLE SERVICE is the workplan for a vehicle for a whole day, planned for a specific DAY TYPE

A BLOCK is the work of a vehicle from the time it leaves a PARKING POINT after parking until its next return to park at a PARKING POINT. Any subsequent departure from a PARKING POINT after parking marks the start of a new BLOCK.

A BLOCK includes, in particular, all VEHICLE JOURNEYs (SERVICE JOURNEYs and DEAD RUNs) planned for this period. It also may include SPECIAL SERVICEs. A pause may be added between two journeys or services. Linked to this concept is the concept of COURSE OF JOURNEYS: a part of a BLOCK composed of consecutive VEHICLE JOURNEYs defined for the same DAY TYPE, all operated on the same LINE.

Vehicles of the type TRAIN or COMPOUND TRAIN may be coupled or separated. For the corresponding journeys, COUPLED JOURNEYs or JOURNEY PARTs are created.

A BLOCK PART is a part of a BLOCK corresponding to the different JOURNEY PARTs of the VEHICLE JOURNEYs in a BLOCK.

One or several vehicle BLOCKs may be coupled together for a while. The entity COMPOUND BLOCK represents the work of a vehicle during the time it is coupled to one or more vehicles. If two different vehicles are coupled at a certain point (e.g. a terminus), a COMPOUND BLOCK is created from that instant on. If this COMPOUND BLOCK is joined by a third BLOCK, coupled later at another point, a new COMPOUND BLOCK is formed from that instant on. If one of the BLOCKs is separated before the COMPOUND BLOCK returns to the GARAGE, another COMPOUND BLOCK is formed, composed of the two BLOCKs corresponding to the coupled vehicles.

Timing Information

One of the main principles of Transmodel is to clearly distinguish the space-related concepts from the time-related concepts. The Reference Data model covers, on one hand, the topological aspects of the Public Transport Network and, on the other hand, time-related aspects.

The time-related concepts are presented in the Service Calendar Model (Part 1 – Common Concepts), Time Demand Type Model  (Part 2 – Tactical Planning Components)  and numerous timing information models (Part 3 – Timing Information and Vehicle Scheduling).

The Service Calendar Model is presented on the following diagram:


Time Demand Type Model is presented on the following diagram:


One of the many timing information models is Vehicle Journey Times Model:


See also FAQ "How does Transmodel define timetables?", which explains how are timetable information integrated into Timetable Frame Model.

The Tactical Planning Components Model provides reusable information about transport planning, such as spatial description of journey patterns and service patterns. Reusable journey patterns and service patterns are independent of actual operating times in scheduled journeys.

In most transport networks the scheduled journeys follow the same patterns of movement and the Tactical Planning Components Model allows these to be described as reusable components in their own right.

The elements defined in the Tactical Planning Components Model are subsequently used in the Journey Timing  Model  & Vehicle Journey Times Model to specify actual VEHICLE JOURNEYs at particular times (Vehicle Journey Model).

Two main tactical planning models are Journey Pattern Model and Service Pattern Model:



Transmodel as a generic model mainly considers elementary data concepts. A timetable is an aggregated data. Transmodel considers all elements available to design a timetable. These are represented in the Timetable Frame Model, the main concept being the VEHICLE JOUNEY and its timing.


A VEHICLE JOURNEY is the planned movement of a public transport vehicle on a DAY TYPE from the start point to the end point of a JOURNEY PATTERN on a specified ROUTE (Vehicle Journey Model).

Transmodel considers a journey as a purely time-related concept:  its attributes are times (Departure Time, Journey Duration). A VEHICLE JOURNEY is only linked to the topological object JOURNEY PATTERN.

The work of the vehicles necessary to provide the service offer advertised to the public consists of SERVICE JOURNEYs . DEAD RUNs are  unproductive VEHICLE JOURNEYs necessary to transfer vehicles where they are needed, mainly from the depot into service and vice versa (Service Journey Model).

Vehicle Journey Model and Service Journey Model are presented here:



Transmodel considers different concepts (Coupled Journey Model):

  • a COUPLED JOURNEY: A complete journey operated by a coupled train, composed of two or more VEHICLE JOURNEYs remaining coupled together all along a JOURNEY PATTERN. A COUPLED JOURNEY may be viewed as a single VEHICLE JOURNEY.
  • JOURNEY PARTs:A part of a VEHICLE JOURNEY created according to a specific functional purpose, for instance in situations when vehicle coupling or separating occurs.
  • A JOURNEY PART COUPLE: two JOURNEY PARTs of different VEHICLE JOURNEYs served simultaneously by a train set up by coupling their single vehicles.

Basically the following situations are possible:

Representation of journey timing as PASSING TIMEs (at specific points) derived from the  run times (times taken to traverse TIMING LINKs within the JOURNEY PATTERN related to the VEHICLE JOURNEY)

  • Consideration of  DEFAULT  run time : the default time taken by a vehicle to traverse a TIMING LINK for a specified TIME DEMAND TYPE (Time Demand Times Model)
  • Consideration of  JOURNEY PATTERN RUN TIME: the time taken to traverse a TIMING LINK in a particular JOURNEY PATTERN, for a specified TIME DEMAND TYPE. (Journey Pattern Times Model)
  • Consideration of specific run times for each particular VEHICLE JOURNEY (Vehicle Journey Times Model)
Representation of a  special behaviour of journeys
  • frequency based services (services runing with a regular interval  (every 10 min,  for example)
  • rhythmical services (runs all xxh10, xxh25 and xxh45, for example)

The diagram shows Journey Passing Times Model:


generic data model

Vehicle Journey Times Model

Strictly speaking Transmodel differentiates space-related concepts from time-related concepts.  So the PASSING TIMES are linked to vehicle journeys.

Two main types of PASSING TIMEs do exist:  a set of TIMETABLED PASSING TIMEs  is  linked to a VEHICLE JOURNEY  and a set of DATED PASSING TIMEs is linked to a DATED VEHICLE JOURNEY.

Several  considerations have then to be undertaken, to calculate the timing of a journey, based on a reference TIMING POINT belonging to the covered JOURNEY PATTERN where a ‘departure time’ is specified for the journey at this point, then run and wait times for the different TIMING LINKS (possibly depending on the TIME DEMAND TYPE) have to be considered to determine the PASSING TIMEs at TIMING POINTs . The PASSING TIMEs at stops which are not TIMING POINTs may be determined by interpolation.

Transmodel considers flexibility of services through the assignment of FLEXIBLE SERVICE PROPERTIES  to VEHICLE JOURNEYs (Flexible Service Model).


INTERCHANGE is the scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different SCHEDULED STOP POINTs (Interchange Model).

INTERCHANGE RULES describe conditions for considering JOURNEYs to meet or not to meet, specified indirectly: by a particular MODE, DIRECTION or LINE. Such conditions may alternatively  be specified directly, indicating the corresponding services. In this case they are either a SERVICE JOURNEY PATTERN INTERCHANGE or a SERVICE JOURNEY INTERCHANGE.

INTERCHANGE has to be differentiated from the concept of CONNECTION. Scheduled INTERCHANGEs represent  operational time constraints for journeys to meet . CONNECTION represent the spatial possibility for a passenger to change from one public transport vehicle to another to continue the trip.

The Interchange Model is presented here:


The tactical planning operations (linked to DAY TYPEs rather than to particular OPERATING DAYs) designs a PRODUCTION PLAN, which is a VERSION associating the production components for a specific OPERATING DAY. Data issued from reference plans for DAY TYPEs are implemented as dated objects for this specific OPERATING DAY. They are then modified according to specific requirements for this day or unexpected changes. A specific VERSION of this plan is frozen as a reference for production for the day in question.

See the Service Calendar Frame Model in the FAQ "How are the time-related aspects of a public transport network taken into account?" for more information about DAY TYPEs.

Network Description

Public Transport Network Topology

The model of the infrastructure network is very basic and simple in Transmodel, made of INFRASTRUCTURE POINTs and LINKs. It is used to represent specific operational constraints (restrictions) for public transport operation resulting from the characteristics of the INFRASTRUCTURE POINTs and LINKs and of VEHICLE TYPEs.The spatial detailed organisation of the infrastructure itself is described by other models and the data is usually provided by GIS data sets.


Infrastructure network Model

Restrictions, i.e. constraints resulting from the physical characteristics of the network are represented in Transmodel by a range of concepts: OVERTAKING POSSIBILITY, IMPOSSIBLE MANOEVRE, MEETING RESTRICTION, VEHICLE TYPE AT POINT. They may be relevant for the scheduling process, because vehicle journeys must be scheduled in a way to avoid such conflicting events.


Network restrictions Model

The term “itinerary” is ambiguous as different types of “itineraries” or “paths” may exist, depending on the purpose to be described: for passengers? for vehicles? along roads? along the rail network? a schematic view?  etc.

The ROUTE entity represents a conventional way of describing a path through the network, to be used by regular PT services (i.e. vehicles). A ROUTE is defined as an ordered list of located POINTs defining one single path through the road (or rail) network. A ROUTE may pass through the same POINT more than once.

ROUTE is a LINK SEQUENCE and must be built in a way that identifies a path without any ambiguity (Line & Route Model).


Line & Route Model

Other specialisations of a LINK SEQUENCE are used to define the work of vehicles: JOURNEY PATTERNs, SERVICE PATTERNs, TIMING PATTERNs (see All Journey Patterns Model).


All Journey Patterns Model

Passenger “paths” are called NAVIGATION PATHs (Navigation Path Model).


Navigation Path Model

A ROUTE is a LINK SEQUENCE, defined by an ordered sequence of (two or more) POINTs ON ROUTE. A ROUTE may pass through the same ROUTE POINT more than once, as in the case of a loop.

Transmodel defines a LINE as a grouping of ROUTEs that is generally known to the public by a similar name or number. These ROUTEs are usually very similar to each other from the topological point of view, being variants of a core route with some deviations only on certain parts.

In order to manage competition between operators or bus lines, PT authorities sometimes define ROUTING CONSTRAINTs, preventing passengers boarding or alighting from a vehicle under certain circumstances.

Several types of constraints are defined.

  • Zone based constraints are defined by a ROUTING CONSTRAINT ZONE. The ZONE may be defined by its contained SCHEDULED STOP POINTS or by its boundary points. ZONEs are usually used to express constraints like “If you board in this ZONE, then you can’t alight in the same ZONE”, or “only alighting is permitted in this ZONE”. The constraint applies to all the POINTs IN JOURNEY PATTERN of specific LINEs included in the ZONE.
  • A SERVICE EXCLUSION constraint expresses the fact that the service on a specific JOURNEY PATTERN (usually a flexible JOURNEY PATTERN) cannot operate when another (regular) service operates.
  • TRANSFER RESTRICTIONs are constraints that can be applied on a CONNECTION or INTERCHANGE between two SCHEDULED STOP POINTs, preventing or forbidding the passenger to make a transfer there.


Routing constraints Model

Transmodel does not have a separate model specifically for Flexible Transport Schemes (FTS), but has extra properties that can be used to describe FTS systems: FLEXIBLE POINT (LINK)  PROPERTIES enabling the definition of a FLEXIBLE ROUTE and a FLEXIBLE LINE.  Different types of FTS are considered:    Virtual line service, Flexible service with main route, Corridor service (Flexible service without main route), Fixed stop area-wide flexible service, Free area-wide flexible service, Mixed types of flexible service (not at POINT level) (Flexible Network Model describing Flexible Points, Links, Zones, Routes and Lines). For example:


Flexible Link, Point and Zone Model

A JOURNEY PATTERN is an ordered list of SCHEDULED STOP POINTs and TIMING POINTs on a single ROUTE, describing the pattern of working for public transport vehicles. A JOURNEY PATTERN may pass through the same POINT more than once (Journey Pattern Model).


Journey Pattern Model

In the domain of Passenger Information SERVICE PATTERNs are of particular importance, i.e.  the specialisation of a JOURNEY PATTERN made up only of (scheduled) STOP POINTs IN JOURNEY PATTERN.

Another concept in this context is also relevant: the SERVICE JOURNEY PATTERN, defined as the JOURNEY PATTERN for a (passenger carrying) SERVICE JOURNEY (Service Pattern Model).


Service Pattern Model

Several points, specifically dedicated to operations monitoring and control, are defined as specialisations of POINT: ACTIVATION POINT, BEACON POINT, GARAGE POINT, RELIEF POINT, PARKING POINT (Activation Model & Vehicle & Crew Point Model).


Activation Model


Vehicle & Crew Point Model

A part of a public transport network where the ROUTEs of several JOURNEY PATTERNs are going in parallel and where the synchronisation of SERVICE JOURNEYs may be planned and controlled with respect to commonly used LINKs and SCHEDULED STOP POINTs. COMMON SECTIONs are defined arbitrarily and need not cover the total lengths of topologically bundled sections (Common Section Model).


Common Section Model

The physical (spatial) possibility for a passenger to change from one public transport vehicle to another to continue the trip, determined by two SCHEDULED STOP POINTs (Service Connection Model). CONNECTION is a passenger view of a transfer.


Service Connection Model

INTERCHANGE is an operational constraint for a transfer: it is defined as the scheduled possibility for transfer of passengers between two SERVICE JOURNEYs at the same or different SCHEDULED STOP POINTs (Interchange Model).


Interchange Model


Transmodel tutorials  have been grouped and organized in the following main sections:

Technical User Support Organisation

Rationale of Transmodel

Public Transport is facing competition from ever-increasing private car transport and a general trend to a decreasing public transport demand. Most of the transport authorities in European countries express concerns about this evolution, leading to road congestion, air pollution, accidents, etc., and consider how they may reverse this negative trend by improving the public transport supply.

One of the main ways of improving the efficiency of a transport system and of individual operators is to develop the use of digitalised information and communication technologies and services (exchange and publication of information), to support both internal operations and communication with other service providers.

Transmodel is aimed at providing a reference for data structures, destined to be common to the public transport domain throughout the European Union.

Transmodel main characteristics and implementations

In order to be adapted to the evolution of software and hardware techniques, Transmodel, the Reference Public Transport Data Model, is technology independent: it refers to the conceptual level of data, which is known to be the more stable element of an information system.

The CEN/TS 16614, known as NeTEx, is the standard implementation of parts of Transmodel representing the planned (static) information and providing standard data formats for data exchanges using Transmodel data structures. EN 15531 (Service interface for real-time information relating to public transport operations, known as SIRI) is based on Transmodel and concerns dynamic information.

Transmodel-related actions

In order to keep Transmodel into a widely known and accepted standard, it is necessary in particular:

  • to promote the data model to public transport authorities and decision makers: to present its contents, evolution and usefulness [1], providing information on current implementations [2], its relationship to national standards and strategic investments [3];
  • to present the data model to software suppliers, to the technical staff of authorities/operators [4];
  • to present Transmodel to academic institutions that teach software engineering, transport engineering and transport management subjects to students [5] or engage in research in transport systems in order to use it as a systematically engineered example of large scale model driven design for information systems in a an important functional area: Transmodel provides a good example for teaching both general system design and transport specific concepts [6], as well as a proven semantic model of real-world transport systems for research purposes;
  • to improve/update/extend the model in order to keep it adapted to the reality of public transport in Europe and to harmonise it as far as possible with other related standards1, in particular, keep Transmodel up-to-date if an implementation standard (e.g. NeTEx, SIRI, etcetera) would submit a justified change request. A formal method allowing for conformity check is in this context particularly useful;
  • to produce detailed data model documentation.

The project team (PT0302) of CEN TC278 WG3 (Public Transport) subgroup 4 (Data Models) has dedicated considerable efforts to support all these objectives in the time period 2016-2019, producing Transmodel v 6.0 (EN 12896-1 to -8 and CEN/TR 12896-9).

Transmodel future

However, if Transmodel has to be kept alive, a Transmodel User Support Group should take care of it and its users continuing the actions described above.

The Programme Support Action (PSA) Data4PT 2020-2024 is meant to contribute to this objective [8].


  1. Transmodel at a glance
  2. Transmodel implementations
  3. Transmodel White paper, BIP Case Study
  4. Transmodel tutorial
  5. Transmodel Textbook for students
  6. Methodology used by Transmodel
  7. Standards harmonisation
  8. Organisation Groupe Support

Methodology used in Transmodel

For the definition of Transmodel, the object–oriented modelling notation UML 2 is used for describing, specifying, documenting and visualizing the conceptual data model.

For more details about the methodology used in Transmodel, you can download the following short guide: Use of UML in Transmodel.