prEN 12896-4

SLOVENSKI STANDARD
01-februar-2026
Javni prevoz - Referenčni podatkovni model - 4. del: Spremljanje delovanja in
nadzor
Public transport - Reference data model - Part 4: Operations monitoring and control
Öffentlicher Verkehr - Referenzdatenmodell - Teil 4: Betriebsüberwachung und
Steuerung
Transports publics - Modèle de données de référence - Partie 4 : suivi et contrôle de
l’exploitation
Ta slovenski standard je istoveten z: prEN 12896-4
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2025
ICS 35.240.60 Will supersede EN 12896-4:2019
English Version
Public transport - Reference data model - Part 4:
Operations monitoring and control
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Referenzdatenmodell - Teil 4:
Partie 4 : suivi et contrôle de l'exploitation Betriebsüberwachung und Steuerung
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 12896-4:2025 E
worldwide for CEN national Members.

prEN 12896-4:2025 (E)
Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 6
3.1 Terms and definitions . 6
3.2 Abbreviations . 6
4 General information . 7
5 Operations monitoring and control . 7
5.1 Introduction . 7
5.2 Dated operational plans . 8
5.2.1 Principles . 8
5.2.2 Vehicle work production components . 9
5.2.3 Dated vehicle service . 12
5.2.4 Call . 12
5.2.5 Dated call . 14
5.2.6 Implementation of dated plans . 14
5.2.7 Production plan . 14
5.3 Resource detection and monitoring . 16
5.3.1 Limits . 16
5.3.2 Functions related to the monitoring process . 16
5.3.3 Resources to be monitored . 17
5.3.4 Vehicle detecting . 18
5.4 Monitored operations . 19
5.4.1 Monitored services . 19
5.4.2 Vehicle monitoring . 20
5.4.3 Monitored passing times . 21
5.4.4 Other monitored situations . 23
5.4.5 Expected and registered situation . 24
5.5 Control actions . 24
5.5.1 General. 24
5.5.2 Vehicle control actions . 26
5.5.3 Elementary journey control actions . 30
5.5.4 Composite journey control actions . 32
5.5.5 Interchange control actions . 33
5.6 Operational events . 35
5.7 Operational messages . 36
5.8 Situation description . 38
5.9 Vehicle occupancy . 40
5.10 Deck occupancy . 41
5.11 Monitored facilities . 42
Annex A (normative) Data dictionary . 45
Annex B (informative) Data model evolution . 76
Annex C (informative) Mapping to DATEX-II and SIRI (SX and FM). 78
Annex D (informative) Significant technical changes between this document and the previous
edition . 87
Bibliography . 88

prEN 12896-4:2025 (E)
European foreword
This document (prEN 12896-4:2025) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 12896-4:2019.
Annex D provides details of the significant technical changes between this document and
EN 12896-4:2019.
This document is part of the European Standard series EN 12896, known as “Transmodel”. This is a series
of documents that comprises the following parts:
— EN 12896-1, Public transport - Reference data model - Part 1: Common concepts
— EN 12896-2, Public transport - Reference data model - Part 2: Public transport network
— EN 12896-3, Public transport - Reference data model - Part 3: Timing information and vehicle
scheduling
— EN 12896-4, Public transport - Reference data model - Part 4: Operations monitoring and control
— EN 12896-5, Public transport - Reference data model - Part 5: Fare management
— EN 12896-6, Public transport - Reference Data model - Part 6: Passenger information
— EN 12896-7, Public transport - Reference data model - Part 7: Driver management
— EN 12896-8, Public transport - Reference data model - Part 8: Management information and statistics
— EN 12896-10, Public transport – Reference data model – Part 10: Alternative modes
Together these documents create Transmodel version 6.2 and thus replace Transmodel V6.0.
In addition to the nine normative Parts of this European Standard, a Technical Report (Public Transport
– Reference Data Model – Informative Documentation) was published in 2016 under the reference
CEN/TR 12896-9. It provides additional information to help those implementing projects involving the
use of Transmodel. It is intended that this Technical Report will be extended and republished as soon as
all the normative parts are revised.
The split into several documents is intended to ease the task of users interested in particular functional
domains. It corresponds to the modularisation of Transmodel into functionally related parts, each made
up of distinct UML packages and subpackages that describe a particular aspect of public transport. The
NeTEx UML model follows the same modularisation, allowing a direct mapping from the conceptual
model to the implementation.
For information on the conventions, methodology and notations for conceptual modelling, for a clear
overview to help understand the core principles, structure and purpose of Transmodel, and for
information on the Functional domains and Modes of operation, refer to EN 12896-1.
1 Scope
This document incorporates the following main data packages:
— Dated Production Components;
— Call;
— Dated Call;
— Production Plan;
— Detecting & Monitoring;
— Situation;
— Messaging;
— Control Action;
— Operational Event & Incident;
— Facility Monitoring & Availability;
— Occupancy.
It is composed of the following parts:
— main document representing the data model for the concepts shared by the different domains
covered by Transmodel (normative);
— Annex A containing the data dictionary and attribute tables, i.e. the list of all the concepts presented
in the main document together with their definitions (normative);
— Annex B presenting the model evolution (informative);
— Annex C detailing the mapping to DATEX-II and SIRI (informative).
— Annex D, providing details of the significant technical changes between this document and
EN 12896-4:2019 (informative).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN 12896-1, Public transport - Reference data model - Part 1: Common concepts
prEN 12896-4:2025 (E)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
relief
person taking the place of another person as responsible for a certain task (such as driving a bus)
3.2 Abbreviations
API Application Programming Interface
AVM Automatic Vehicle Monitoring
AVMS Automated Vehicle Management System
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IFOPT Identification of Fixed Objects in Public Transport
ISO International Organization for Standardization
IT Information Technology
NeTEx Network and Timetable Exchange
PT Public Transport
PTO Public Transport Operator
OJP Open API for Distributed Journey Planning
OpRa Operating Raw Data and statistics exchange
SIRI Service Interface for Real-time Information
SIRI— FM Service Interface for Real-time Information Facility Monitoring (see CEN/TS 15531-4)
SIRI— SX Service Interface for Real-time Information Situation Exchange (see CEN/TS 15531-5)
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
VDV Verband Deutscher Verkehrsunternehmen (Germany)
WGS World Geodetic Standard
4 General information
The following standards are based on the Transmodel conceptual data model for public transport domain
to provide a harmonized, interoperable, and consistent approach for public transport data, service
interfaces, and journey planning across Europe:
— EN 15531 series [10] to [16] – Service interfaces for real-time public transport operations.
— CEN/TS 16614 series (NeTEx) [17] to [22] – Network and timetable data exchange, including
passenger information and accessibility.
— CEN/TS 17118 [23] – Open API for distributed journey planning.
5 Operations monitoring and control
5.1 Introduction
The operational management of public transport is classically divided into two distinct phases:
— a “tactical planning” phase, consisting of designing and building a reference schedule (described in
EN 12896-2, Public transport - Reference data model - Part 2: Public transport network and
EN 12896-3, Public transport - Reference data model - Part 3: Timing Information and Vehicle
Scheduling); 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”.
Note that in the first phase, the “tactical planning” phase, data are typically handled on a macroscopic
level describing significant parts of the intended operation as complete sets of coherent data. It is possible
to prepare multiple complete sets of coherent data in parallel, reflecting different planning strategies on
a higher level, with one such set selected to be the base for the operation on a certain day for a certain
scope. In this case, the concept of organizing data into VERSION FRAMEs (as described in EN 12896-1,
Public transport - Reference data model - Part 1: Common concepts) is useful as it provides a mechanism
to work with, and choose between, coherent sets of data at a higher level for pre-selected scopes.
In the second phase, the “real-time control” phase, the higher-level plan is already partly in operation;
the movement of real-world passengers, vehicles and personnel has already started, and the current plan
cannot easily be replaced in its entirety with a different pre-prepared plan. Instead, changes to
compensate for disturbances of different kinds need to be applied gradually and individually, taking the
current position of personnel and vehicles into consideration. In this case the VERSION FRAME concept
is of less relevance.
The data collected during real time operations is a constant source of information related to the
theoretical reference schedules and is thus likely to be used as feedback to adapt them. The boundary
between these two phases (tactical planning and real-time control) is, in most cases, fixed arbitrarily. It
may take place at the beginning of the operating day, two days in advance, when the drivers are rostered,
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.
The reference schedule is optimized to fit specified service quality objectives (e.g. frequency, punctuality,
crowding or interchange management) whilst respecting operational constraints (e.g. constraints due to
driver or vehicle management). However, it can only define an optimal plan in average operating
conditions. When these average conditions are no longer present (e.g. because of disturbances such as
change in traffic conditions, failures, incidents, etc.), it becomes necessary to carry out “control actions”,
to compensate for the service deterioration.
prEN 12896-4:2025 (E)
It is commonly accepted that real-time control aims to relate operations to the reference schedule.
However, if the situation is far from the average conditions, then the reference schedule is no longer a
standard to be respected; in this case only the service quality objectives remain, guiding the control
actions, modifying the reference schedule, and possibly resulting in a complete rescheduling.
Modern public transport networks are equipped with automated tools able to facilitate real-time control,
usually named Automatic Vehicle Monitoring systems (AVMS). The main functions of an AVMS in the
control process are:
— locating vehicles, with regard to the PT network and possibly to the infrastructure;
— controlling tolerance thresholds with respect to the service objectives, in order to help the controller
in the detection of disturbances and to help the driver maintain the timetable or headway;
— controlling data and voice exchanges, for information of controllers, drivers and passengers;
— handling of (technical or operational) alarms;
— providing assistance for the design of control actions;
— computing data for traveller information (e.g. estimated passing times);
— various activation functions (e.g. traffic light priority); and
— collecting data for statistical purposes (e.g. observed run times).
The modelling requirements imply distinguishing some important abstract concepts, in particular:
— physical resources (e.g. a particular driver) and logical resources (e.g. a theoretical anonymous
vehicle); and
— various states of the work plan, particularly the latest valid work plan (e.g. as ordered by the
controller), the monitored situation (e.g. as monitored by the AVMS) and the expected situation (as
forecasted, from the monitored situation and the plans).
5.2 Dated operational plans
5.2.1 Principles
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 (see SERVICE CALENDAR described in EN 12896-1, Public transport - Reference
data model - Part 1: Common concepts) and the PROPERTies OF DAY assigned to each OPERATING DAY.
The composition of dated plans is rather similar to the composition of plans for day types (see in
particular Dated Journey Model in EN 12896-2, Public transport - Reference data model - Part 2: Public
transport network and EN 12896-3, Public transport - Reference data model - Part 3: Timing Information
and Vehicle Scheduling). However, they include a lot of information that cannot be planned easily on a
regular basis: occasional special services, results of the personnel disposition process (in particular
planned rest days or other absences), etc.
Figure 1 — Dated Production Components MODEL (overview)
Dated plans are constantly updated according to the available information. It is a common practice to
freeze and store a conventional version of such a plan, a short time before the beginning of the
OPERATING DAY. This version represents the PRODUCTION PLAN (see 5.2.7), serving as a reference for
the production follow-up. Drivers are often rostered according to such a PRODUCTION PLAN. Moreover,
the data transferred to the AVMS application is usually extracted from the PRODUCTION PLAN. During
the OPERATING DAY, further modifications (CONTROL ACTIONs) occur, due to various events affecting
the operations (failures, delays, absences, etc.).
Most monitoring systems constantly record a “latest valid plan”, which reflects all modifications to the
operational plan that have been entered and validated up to now. This dynamic plan forms, in particular,
the basis to inform the drivers, to adapt their driving to the plan.
5.2.2 Vehicle work production components
5.2.2.1 Dated journeys and special services
There are many reasons which lead to modification of the operational plan in the short-term: special
events; changes in the road infrastructure; incidents; etc. Some DATED 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 sometimes not modified, instead the changes are applied using CONTROL ACTIONs for the appropriate
OPERATING DAYs.
prEN 12896-4:2025 (E)
Figure 2 — Vehicle Work Production Components MODEL
The entity DATED VEHICLE JOURNEY describes a vehicle journey planned for one specific OPERATING
DAY.
A NORMAL DATED VEHICLE JOURNEY is a pre-planned DATED VEHICLE JOURNEY. Thus, it is based on a
VEHICLE JOURNEY constructed during the scheduling process, and that is planned to be run on the
OPERATING DAY in question according to its DAY TYPE. If there is no disturbance in the service, these
normal journeys will be an exact image of the theoretical plan, applied to the specific OPERATING DAY.
However, short-term modifications may be applied to these journeys, for instance when the controller
decides to let a vehicle turn before the terminus. This means that the last part of the vehicle’s current
journey is cancelled as well as the first part of the vehicle’s next journey in the other direction. One way
of doing this is by applying two PARTIAL JOURNEY CANCELLATION control actions (see 5.5.3.5). Such
CONTROL ACTIONs update the latest valid plan and produce modified versions of the relevant DATED
VEHICLE JOURNEYs.
Additional DATED VEHICLE JOURNEYs may be included in the PRODUCTION PLAN for an OPERATING
DAY by applying the JOURNEY CREATION control action (see 5.5.3.2). Such EXTRA DATED VEHICLE
JOURNEYs could be created from scratch, or by duplication of an existing journey with modification of
the departure time, for instance. Sometimes EXTRA DATED VEHICLE JOURNEYs are based on existing
JOURNEY PATTERNs. An EXTRA DATED VEHICLE JOURNEY may, for instance, correspond to a
reinforcement of the service, or result from a complete rescheduling.
There are also situations when EXTRA DATED VEHICLE JOURNEYs are created to complement a DATED
VEHICLE JOURNEY that is already running, but that will not be completed due to mechanical failures or
large delays of the originally assigned vehicle. Sometimes such a replacement EXTRA DATED VEHICLE
JOURNEY that is working the latter JOURNEY PARTs of the planned VEHICLE JOURNEY can be run at the
same time as the original vehicle is still working to complete the first JOURNEY PARTs of the same
planned VEHICLE JOURNEY.
A DATED VEHICLE JOURNEY serves one JOURNEY PATTERN. Any NORMAL DATED VEHICLE JOURNEY
for which the working pattern has not been modified by a CONTROL ACTION will serve the JOURNEY
PATTERN of its parent VEHICLE JOURNEY. In case of modification, the new JOURNEY PATTERN of the
DATED VEHICLE JOURNEY is specified either by a reference to an existing JOURNEY PATTERN exactly
matching the modification, or by a description of the relative modifications in relation to the original
JOURNEY PATTERN. The same applies to EXTRA DATED VEHICLE JOURNEYs; they can be described with
a reference to an existing JOURNEY PATTERN that matches the intended JOURNEY PATTERN exactly, or
by a reference to an existing JOURNEY PATTERN in combination with a description of relative
modifications in relation to this JOURNEY PATTERN.
The classification of JOURNEY PATTERNs through TYPE OF JOURNEY PATTERN may include some
categories of occasional JOURNEY PATTERNs, to be used only by extra or modified DATED VEHICLE
JOURNEYs (e.g. for occasionally shortened or deviated routes).
The entity DATED VEHICLE JOURNEY has an attribute ‘departure time’. In case of a NORMAL DATED
VEHICLE JOURNEY, this time will be the same as for the parent VEHICLE JOURNEY, unless modifications
of this departure time have been ordered.
DATED SPECIAL SERVICEs are created following the same principles. Regular services will be derived
from a SPECIAL SERVICE planned for a DAY TYPE. In most cases, DATED SPECIAL SERVICEs will be extra
(occasional) special services, valid only for the considered OPERATING DAY.
5.2.2.2 Dated blocks
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 (see EN 12896-3, Public transport - Reference data model - Part 3: Timing Information
and Vehicle Scheduling).
Most of the DATED BLOCKs will be identical to an existing BLOCK, possibly with some modifications.
These DATED BLOCKs are called NORMAL DATED BLOCKs, with a relationship with the parent BLOCK.
If an extra journey is planned, this may invoke the need for a new vehicle to come from a garage, in which
case a complete new (extra) DATED BLOCK is created from scratch.
A DATED BLOCK shall in principle include DATED VEHICLE JOURNEYs or DATED SPECIAL SERVICEs.
When a NORMAL DATED BLOCK is generated, it includes the journeys and services present in the planned
(reference) BLOCK.
However, there may be changes during the OPERATING DAY and the complete set of DATED VEHICLE
JOURNEYs, normal and extra, presently or historically, included in certain DATED BLOCKs. It may be
possible to deduce, by checking the VEHICLE WORK ASSIGNMENT CONTROL ACTIONs, which LOGICAL
VEHICLEs are related to which DATED BLOCKs and DATED VEHICLE JOURNEYs.
In common with the DATED VEHICLE JOURNEY, a DATED BLOCK has a specific identifier (ID), in addition
to the OPERATING DAY foreign key.
5.2.2.3 Dated vehicle journey interchanges
The entity DATED VEHICLE JOURNEY INTERCHANGE describes an INTERCHANGE between two DATED
VEHICLE JOURNEYs (see EN 12896-3, Public transport - Reference data model - Part 3: Timing
Information and Vehicle Scheduling). Often it is the result of a planned SERVICE JOURNEY INTERCHANGE
or the application of an INTERCHANGE RULE, but it can also be the result of a CONTROL ACTION.
Short-term modifications may be applied to DATED VEHICLE JOURNEY INTERCHANGEs, for instance
when the controller decides to extend the time span that the distributor VEHICLE should wait for the
feeder VEHICLE, cancels a DATED VEHICLE JOURNEY INTERCHANGE or adds a new DATED VEHICLE
JOURNEY INTERCHANGE to the PRODUCTION PLAN for an OPERATING DAY.
prEN 12896-4:2025 (E)
5.2.3 Dated vehicle service
In addition to the DATED BLOCK that represents the work of a logical vehicle on a particular OPERATING
DAY from the time it leaves a PARKING POINT after parking until its next return to park at a PARKING
POINT, there is also a concept that allows the operators to distinguish additional sequences of DATED
BLOCKs starting and ending in a garage (i.e. the end points shall be GARAGE POINTs). Such a DATED
VEHICLE SERVICE PART may be composed, for instance, of two DATED BLOCKs, separated by a parking
period spent, without any driver, at a PARKING POINT which is not a GARAGE POINT (e.g. parking periods
at off-peak hours for buses, at a parking point in the city).
The whole work of a LOGICAL VEHICLE for an OPERATING DAY is described by a DATED VEHICLE
SERVICE, composed of one or several DATED VEHICLE SERVICE PARTs.

Figure 3 — Dated Vehicle Service MODEL
However, many users of the reference model will not implement these three levels (DATED BLOCK,
DATED VEHICLE SERVICE PART and DATED VEHICLE SERVICE) of activities. The concept of DATED
VEHICLE SERVICE is not strictly necessary, once the number of required vehicles has been optimized and,
in many situations, the distinction between DATED BLOCK and DATED VEHICLE SERVICE PART is not
useful. Therefore, in an organization data model, two or all three concepts may be merged in a single
concept (e.g. DATED BLOCK).
5.2.4 Call
Transmodel is in principle built out of elementary entities, not ones that are derived or aggregated. One
of the few exceptions to this rule is the CALL concept which provides a general view that simplifies the
grouping of some types of commonly used data.
Figure 4 — Call MODEL
A CALL is a Transmodel view that represents the aggregation of information referring to a VEHICLE
JOURNEY at a POINT IN JOURNEY PATTERN. This construction is introduced to provide a single object to
relate to, instead of having to use the double references to a VEHICLE JOURNEY and a POINT IN JOURNEY
PATTERN when conveying information that is specific for that combination. The aggregation concerns,
for instance, TIMETABLED PASSING TIMEs, NOTICEs, etc.
The concept can be further refined by separating data that is specific to the arrival or departure only by
using the Transmodel views ARRIVAL and DEPARTURE.
prEN 12896-4:2025 (E)
5.2.5 Dated call
Figure 5 — Dated Call MODEL
A DATED CALL is a Transmodel view that represents the aggregation of information referring to a DATED
VEHICLE JOURNEY at a POINT IN JOURNEY PATTERN. This construction, used in implementations such
as SIRI (see EN 15531-1, Public transport - Service interface for real-time information relating to public
transport operations - Part 1: Context and framework to [9]), is introduced to provide a single object to
relate to, instead of having to use the double references to a DATED VEHICLE JOURNEY and a POINT IN
JOURNEY PATTERN when conveying information that is specific for that combination. The aggregation
concerns, for instance, DATED PASSING TIMEs, NOTICEs, etc.
The concept can be further refined by separating data that is specific to the arrival or departure only by
using the Transmodel views DATED ARRIVAL and DATED DEPARTURE.
5.2.6 Implementation of dated plans
The reference model provides only a limited number of “dated” entities, mainly referring to vehicle
scheduling. The principles described above may be applied to numerous other concepts. In particular,
most operators will implement dated duties for personnel disposition. It is, for instance, a usual practice
to implement dated duties some days in advance, in order to facilitate the driver assignment work. The
generic scheme described for the management of versions (see EN 12896-1, Public transport - Reference
data model - Part 1: Common concepts) is useful to guide this implementation. The conceptual “dated”
entities may be implemented in various ways, for instance in replicating all VEHICLE JOURNEYs for each
OPERATING DAY, or only in recording exceptions and changes, etc.
5.2.7 Production plan
The PRODUCTION PLAN is a specific VERSION of the resource planning for a specific OPERATING DAY. It
represents a conventional image of one version of the latest valid plan, frozen at a point in time defined
by the user, according to local requirements (e.g. 2 days before the start of each OPERATING DAY, at 18:00
hrs.).
The following may be attached to a PRODUCTION PLAN:
— the logical resources assigned to work this plan (see 5.3.3);
— the dated components of the production: DATED VEHICLE JOURNEYs, DATED SPECIAL SERVICEs;
— the dated sets of activities assigned to the resources: DATED BLOCKs, dated driver duties, etc.;
— the various elementary plans and versions possibly associated to the dated PRODUCTION PLAN:
VEHICLE SCHEDULE VERSION, DRIVER SCHEDULE VERSION, TIMETABLE VERSION, etc.

Figure 6 — Production Plan MODEL
In some cases, all elements composing a PRODUCTION PLAN (e.g. VEHICLE JOURNEYs, driver duties,
BLOCKs, etc.) for a certain OPERATING DAY refer to the same DAY TYPE, but this is not a strict
requirement. For example, a VEHICLE JOURNEY worked on a “Friday” DAY TYPE may on certain
OPERATING DAYs be operated in parallel with a VEHICLE JOURNEY worked on a “Weekdays” DAY TYPE.
Several VERSION FRAMEs may be combined in a PRODUCTION PLAN (e.g. three VEHICLE SCHEDULE
FRAMEs covered by one DRIVER SCHEDULE FRAME).
The responsibility for operating and planning the operation may be divided among multiple parties, each
party providing different aspects and parts of the PRODUCTION PLAN. Different parts of the operation
are covered in different multiple parallel TIMETABLE FRAMEs, VEHICLE SCHEDULE FRAMEs and
DRIVER SCHEDULE FRAMEs that may be more or less independently maintained in different systems.
prEN 12896-4:2025 (E)
The scope of each of the respective VERSION FRAMEs from which the PRODUCTION PLAN is derived is
to be specified by the responsible parties in an unambiguous fashion. The scope for a TIMETABLE FRAME
is often a LINE, but could also be a GROUP OF LINES, a GARAGE (interpreted as all VEHICLE JOURNEYs
operated from that GARAGE), etc. The scope for a VEHICLE SCHEDULE FRAME is often the GARAGE
(interpreted as all BLOCKs for all VEHICLE JOURNEYs operated from that GARAGE), but could also be an
OPERATOR (interpreted as all BLOCKs for all VEHICLE JOURNEYs operated by that OPERATOR), etc.
The building rules of a PRODUCTION PLAN may include some VALIDITY CONDITIONs that are used to
select the correct VERSION of data for the respective VERSION FRAMEs.
It is not necessary that a certain VEHICLE SCHEDULE FRAME is restricted to refer only to VEHICLE
JOURNEYs from a single TIMETABLE FRAME, neither is it necessary that all VEHICLE JOURNEYs in a
certain TIMETABLE FRAME shall be included in BLOCKs from a single VEHICLE SCHEDULE FRAME.
Different parties may have different views on what they consider to be the scope of the PRODUCTION
PLAN, in essence the “VERSION FRAME” of the PRODUCTION PLAN.
For example, a regional PT authority might have a view that the complete tendered public transport
operation in the region is covered by a single PRODUCTION PLAN, thus involving a large number of
TIMETABLE VERSION FRAMEs, VEHICLE SCHEDULE FRAMEs and possibly also DRIVER SCHEDULE
FRAMEs.
At the same time an OPERATOR responsible for running part of that operation might focus only on the
subset of VEHICLE JOURNEYs, BLOCKs and driver duties worked by that same OPERATOR and consider
that as the scope for the PRODUCTION PLAN. Such a limitation can be useful to reduce the workload for
the OPERATORs AVMS.
5.3 Resource detection and monitoring
5.3.1 Limits
The on-line control of public transport operations involves collecting and computing data about the
resources used for these operations (mainly vehicles and crew).
In the present version of the reference model, the problem of vehicle monitoring is fully addressed,
whereas crew monitoring concerns are only treated to a limited extent.
5.3.2 Functions related to the monitoring process
Several main functions can be distinguished in the on-line vehicle control process:
— detection of a vehicle, which means collecting raw data about a vehicle (e.g. its current location or its
current speed);
— monitoring a vehicle, which means to ascertain relationships between a vehicle and data describing
(possibly partly) a planned transportation service (e.g. to monitor that a vehicle is operating a certain
SERVICE JOURNEY and is behind its schedule);
— computing forecasts on the service to come (e.g. to calculate estimated passing times);
— recording consolidated data about the service actually operated by each vehicle.
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.
However, the basic objective of on-line control and of the systems aimed at assisting this function (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.
AVM systems are able to represent the monitored situation, which reflects in principle the actual situation
at any time. One of the main interests for operators is to relate this situation (journey under way) to the
latest valid plan (journey supposed to be under way). However, some uncertainty may occur in this
relationship, due to technical failures or deviations from the normal route, for instance. Moreover, some
monitoring systems dedicated to passenger information may even ignore the theoretical plans.
Forecasting passing times is an essential function, in particular for passenger information. From the
information provided by the latest valid plan (or simply the PRODUCTION PLAN) and the monitored
situation, AVM and passenger information systems compute an estimated plan, providing for instance the
estimated passing times for the rest of the journey under way and possibly the following journey.
After completion of the operating day, the production follow-up process consists of consolidating a
realized production report. This is based on the data provided by the monitoring and by the recorded
control actions, completed or corrected by other information (such as reason for changing or comments),
in order to provide a report reflecting as precisely as possible the realized production.
The distinction between detection, monitoring, forecasts and recording is convenient for classical
operations and systems, for which the technical capabilities or the human behaviour may introduce some
uncertainty. In some public transport systems (notably automatic metro systems), these functions may
be merged in a single function, which represents a fully automated control of operations.
More generally, the above principles should be interpreted as examples of usual practices which will have
to be adapted to any particular situation.
5.3.3 Resources to be monitored
As described in EN 12896-3, Public transport - Reference data model - Part 3: Timing Information and
Vehicle Scheduling, it is often convenient for many functions to manage logical resources, instead of
physical resources. This is in particular the case for most monitoring functions, because they require to
distinguish:
— a logical (theoretical and anonymous) resource (e.g. a logical vehicle or a logical driver);
— a physical resource (e.g. a particular VEHICLE), to be assigned to a logical resource;
— a work plan (e.g. a DATED BLOCK composed of DATED VEHICLE JOURNEYs, or a “dated duty”).
In stable situations, the concept of logical resource does not have any concrete meaning. When a
PRODUCTION PLAN is validated and frozen, for instance, it is possible to assign physical VEHICLEs to
pieces of work plan (e.g. BLOCKs) directly. However, many modifications to the initial plan arise during
the day of operations, which are likely to complicate this simple assignment.
For instance, the physical VEHICLE to be monitored is not always known by the system. Some passenger
information systems monitor anonymous vehicles, collecting only data about the line and the covered
JOURNEY PATTERN, at a point where a vehicle is detected. A logical resource may be created and used in
the monitoring system before any assignment to a physical resource or a work plan. During the design of
a control action, a logical resource may have, provisionally, two contradictory work plans attached.
prEN 12896-4:2025 (E)
For these reasons, the concept of logical resource may be used at any stage of planning or operating the
services, with the meaning of an available anonymous resource. The reference model does not make
explicit such a concept for all stages. At the tactica
...