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.

Standards Harmonisation

Standards Harmonisation

This page summarises Standard harmonisation aspects of Transmodel v6.0.

The harmonisation work has involved comparison and analysis of other standards with Transmodel over a period of time, with the resulting modifications being integrated into a number of different areas of Transmodel, including some enhancements to the core Common Concepts model (for example, adding an abstract ROLE MODEL, and an abstract SECURITY LIST MODEL).

The requirements for additional harmonisation have been especially intensive in two particular areas:

  • Harmonisation of the Passenger Information Model (Part 6 of Transmodel v6.0). This is a natural consequence of this module being concerned with the mapping of Transmodel data elements to other APIs and formats.
  • Harmonisation of the Fare & Validation Models (Part 5 of Transmodel v6.0). This is primarily because the Fares part of Transmodel has been extensively revised to meet new requirements from the CEN NeTEx format and other related conceptual standards (see below) – reflecting developments in modern ticketing technology.

The harmonisation work to compare different standards demonstrates the value and power of Transmodel as conceptual tool for the analysis and comparison of different representations of PT data, even if they use different terminology.

  • A comparison of NeTEx and Google’s General Transit Feed Specification (GTFS) provides an especially good example of this. Some notes are included in this report.
  • A further presentation to show the strategic use of Transmodel for harmonising UK standards was developed and delivered to the British Standards Institute.

Figure 1 shows Transmodel as the basis for a family of interoperable data standards.

To download the “Report on Standards Harmonisation” click here.

Figure 1 – Transmodel related standards