prEN 12896-7

SLOVENSKI STANDARD
01-februar-2026
Javni prevoz - Referenčni podatkovni model - 7. del: Upravljanje voznega osebja
Public transport - Reference data model - Part 7: Driver management
Öffentlicher Verkehr - Referenzdatenmodell - Teil 7: Fahrermanagement
Transports publics - Modèle de données de référence - Partie 7 : Gestion des
conducteurs
Ta slovenski standard je istoveten z: prEN 12896-7
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-7:2019
English Version
Public transport - Reference data model - Part 7: Driver
management
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Referenzdatenmodell - Teil 7:
Partie 7 : Gestion des conducteurs Fahrermanagement
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-7:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms, definitions and abbreviations . 4
3.1 Terms and definitions . 4
3.2 Abbreviations . 5
4 General information . 5
5 Driver Management . 5
5.1 Introduction . 5
5.2 Driver . 6
5.3 Driver scheduling . 6
5.3.1 General remarks . 6
5.3.2 Duties . 7
5.3.3 Driver trips . 15
5.3.4 Driver schedule frame . 18
5.4 Rostering . 18
5.4.1 General remarks . 18
5.4.2 Roster matrices . 19
5.4.3 Roster cycles . 22
5.4.4 Roster designs . 24
5.4.5 Roster assignments . 25
5.5 Personnel disposition (informative) . 26
5.5.1 Introduction . 26
5.5.2 Driver assignments . 26
5.5.3 Driver accounting . 29
5.5.4 Accounting the drivers’ work . 31
5.6 Driver control actions . 32
5.6.1 General. 32
5.6.2 Logical driver creation . 33
5.6.3 Logical driver cancellation . 33
5.6.4 Change of driver . 33
Annex A (normative) Data Dictionary . 34
A.1 Introduction . 34
A.2 Data Dictionary – Driver Management . 34
Annex B (informative) Data Model Evolutions . 49
B.1 General. 49
B.2 Diagrams with additional concepts and relationships with other Parts . 49
B.3 Diagrams with additional relationships . 49
Annex C (informative) Significant technical changes between this document and the
previous edition . 50
Bibliography . 51
European foreword
This document (prEN 12896-7: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 supersedes EN 12896-7:2019
This document is part of the European standard EN 12896, known as “Transmodel”. This European
standard is a series of documents that comprises of the following ones:
- 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.
Annex C provides details of the significant technical changes between this document and EN 12896-
7:2019
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 is composed of the following data packages:
— Driver;
— Driver Schedule;
— Rostering;
— Personnel Disposition;
— Driver Control Action.
This document itself 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, providing details of the significant technical changes between this document and EN 12896-
7: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
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
relief
person taking the place of another person as responsible for a certain task (such as driving a bus)
3.2
roster
plan showing turns of duty or leave for individuals in an organization
3.2 Abbreviations
API Application Programming Interface
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IFOPT Identification of Fixed Objects in Public Transport
ISO International Standards Organisation
IT Information Technology
NeTEx Network and Timetable Exchange
PT Public Transport
OJP Open API for Distributed Journey Planning
OpRa Operating Raw Data and statistics exchange
SIRI Service Interface for Real-time Information
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
4 General information
The following standards series 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 [11–17] – Service interfaces for real-time public transport operations.
⦁ CEN/TS 16614 Series (NeTEx) [18–23] – Network and timetable data exchange, including passenger
information and accessibility.
⦁ CEN/TS 17118 [24] – Open API for distributed journey planning.
5 Driver Management
5.1 Introduction
The description of driver management is divided into three main parts.
The first main part concerns driver scheduling, in essence creating the day-type related driver schedules
where the required work is divided into duties that represents a set of work to be performed by one
driver on one day.
The second main part concerns rostering, describing how the driver duties are ordered into sequences,
according to some chosen method, to obtain a starting point for a balanced work share among the
personnel over the planning period.
The third main part is the personnel disposition, describing how physical drivers are assigned to do the
work of a logical driver. This part also covers the recording of driver performance.
Additionally, there are clauses concerning driver, driver trip and driver control actions.
5.2 Driver
Figure 1 – Driver MODEL
The DRIVER entity describes a physical driver, who is an EMPLOYEE (see EN 12896-1, Public transport -
Reference data model - Part 1: Common concepts) of the public transport organisation. A DRIVER may
have one or more QUALIFICATIONs of different TYPEs OF QUALIFICATION, for example driving licences
for different categories of vehicle, accessibility assistance training, etc.
Note that in the first stages of the planning process there are no direct references to the DRIVER (i.e. the
physical driver). Instead, a theoretical LOGICAL DRIVER is used during planning. And, later on, there will
be a separate assignment of which DRIVER (physical driver) shall perform the duties specified for a
certain LOGICAL DRIVER.
5.3 Driver scheduling
5.3.1 General remarks
Driver scheduling involves the construction of driver DUTies to cover the scheduled SERVICE JOURNEYs
(see EN 12896-3, Public transport - Reference data model - Part 3: Timing Information and Vehicle
Scheduling) at minimum cost. This process shall also give DRIVERs fair workloads, which comply with
the law and with the agreements made between the company and, for example, driver unions. There are
numerous parameters, such as maximum length of driving time allowed without a break, which will be
essential input for the driver scheduling algorithm. These are not included in the reference model,
because they do not have a complex structure or relationships to the data model entities but are simple
values.
In many cases, BLOCKs (see EN 12896-3, Public transport - Reference data model - Part 3: Timing
Information and Vehicle Scheduling) will already be compiled before the start of the driver scheduling
process and will be used as input. However, schedulers do not always want to work in that order; the
model allows DUTies to be entered into the system before pieces of vehicle work have been assigned to
them.
5.3.2 Duties
5.3.2.1 Duties components
Figure 2 – Simplified overview of the main concepts in a duty in relation to a driver
A DUTY describes a day’s work for a LOGICAL DRIVER on one DAY TYPE. 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.
Operators and applications use various DUTY component levels. The reference model includes more
levels than any one organisation is likely to want, to support these existing ways of structuring the data.
Some of these levels may only be used within the driver scheduling package and will not be needed in an
organisation database. They are included in the model because they explain the relationships between
entities that will be in such an organisation database.
Figure 3 – Duty MODEL
An ASSIGNED DUTY may be divided into one or two (or sometimes even more) DUTY PARTs, which are
each bounded by sign on and sign off. A DUTY consisting of two DUTY PARTs is commonly known as a
“split” duty. A DUTY PART is a continuous period during which the driver is under the responsibility of
the OPERATOR (see EN 12896-1, Public transport - Reference data model - Part 1: Common concepts). In
many organisations, a DUTY PART is therefore a continuous paid period as well.
As a DUTY PART may last a relatively long time, they often include breaks planned for driver resting. Each
DUTY PART is composed of one or several STRETCHes, which are continuous period of work not
interrupted by any BREAK. A BREAK shall therefore follow a STRETCH and is included in the
corresponding DUTY PART.
Figure 4 – Duty Stretch MODEL
Each STRETCH is composed of one or several SPELLs. A SPELL describes a period during which the same
main activity is to be performed (e.g. driving a vehicle, stand-by period etc.). SPELLs are subdivided into
DRIVING SPELLs and NON-DRIVING SPELLs.
5.3.2.2 Driving spells
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 EN 12896-3, Public transport - Reference data model - Part 3: Timing Information
and Vehicle Scheduling). These RELIEF OPPORTUNITies are points in time and space (at RELIEF POINTs
– see EN 12896-2, Public transport - Reference data model - Part 2: Public transport network topology)
in the same particular BLOCK.
In principle, the first DRIVING SPELL covering a BLOCK starts with a relief involving only the driver taking
charge of the vehicle from the PARKING POINT (see EN 12896-2, Public transport - Reference data model
- Part 2: Public transport network topology). By contrast, the last DRIVING SPELL covering a BLOCK
involves only the last driver. In between, reliefs concern both a relieved driver and a relieving driver.
The RELIEF OPPORTUNITY entity, relating a BLOCK to a DRIVING SPELL, is a crucial concept to associate
the work of LOGICAL VEHICLEs (vehicle schedules) and the work of LOGICAL DRIVERs (driver
schedules). In a real implementation, those RELIEF OPPORTUNITies that are chosen for actual reliefs may
be flagged as being related to an actual DRIVING SPELL. However, other (unused) RELIEF
OPPORTUNITies may remain of interest for real-time control, in case of duty modification.
The VEHICLE JOURNEYs (and SPECIAL SERVICEs) to be covered by each DRIVING SPELL can be derived
from the other data. A DRIVING SPELL is bounded by two RELIEF OPPORTUNITies on the same BLOCK.
All the VEHICLE JOURNEYs in that BLOCK, between the start and the end RELIEF OPPORTUNITies, will
be driven by the driver who has to work that DRIVING SPELL.
Some relief opportunities are organised during a VEHICLE JOURNEY, at an intermediate RELIEF POINT.
In such a case, only a part of the journey belongs to each (relieved or relieving) DRIVING SPELL. In a real
implementation, such characteristics may be implemented using redundant JOURNEY PARTs (see EN
12896-3, Public transport - Reference data model - Part 3: Timing Information and Vehicle Scheduling).
DRIVING SPELLs may include PAUSEs planned in the covered BLOCK, after a VEHICLE JOURNEY (see EN
12896-3, Public transport - Reference data model - Part 3: Timing Information and Vehicle Scheduling).
5.3.2.3 Breaks and pauses
Drivers cannot work continuously for long periods of time and shall be given BREAKs. The length of work
periods without any BREAK, as well as the length of BREAKs, is a matter of legal requirement and
agreement between the organisation and the unions.
A BREAK is defined as a period of time, during which the driver is still under the responsibility of the
organisation (and normally still paid), devoted only to resting.
BREAKs are identified by the STRETCH of work that they follow. BREAKs shall be arranged at a TIMING
POINT (see EN 12896-2, Public transport - Reference data model - Part 2: Public transport network
topology) where there is a BREAK FACILITY, with toilets and where meals and other refreshments may
be available. The place of a BREAK FACILITY is often at a RELIEF POINT where another driver relieves
the driver. In some cases, the driver may have to walk to another TIMING POINT, which is near to the
RELIEF POINT and is a more suitable place to stay during a BREAK (for example a service area in a
pedestrian zone).
BREAKs are deliberately built into the DUTies. PAUSEs, on the contrary, are spare times at the end of
VEHICLE JOURNEYs which usually arise as a result of the vehicle scheduling process, but which may also
be used as rest or refreshment time by drivers. A PAUSE can be organised if, for instance, the VEHICLE
(see EN 12896-1, Public transport - Reference data model - Part 1: Common concepts) has a planned long
waiting time at a PARKING POINT far from the centre of the city. In such a case, it is wiser to plan a PAUSE
than to organise a relief. In some cases, PAUSEs may also be planned deliberately. They may be taken in
a BREAK FACILITY, but the driver remains responsible for the VEHICLE during the PAUSE.
5.3.2.4 Time allowance and fill-in times

Figure 5 – Time Allowance MODEL
At the beginning or at the end of a BLOCK, 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.
The total duration scheduled for preparation and finishing activities may, for each of the activities
mentioned above, be recorded as a TIME ACCOUNTABLE ACTIVITY using the attributes,
‘PreparationDuration’ and/or ‘FinishingDuration’.
Figure 6– Time Allowance VIEW
Most operators need to classify such times in a more detailed way. One or several TIME ALLOWANCEs
may be attached to a BLOCK, DUTY, a DUTY PART, a STRETCH or a SPELL. The TYPE OF ALLOWANCE
permits these times to be classified according to the specific local conditions, and to express whether the
TIME ALLOWANCE is applied at the beginning or at the end of the considered element.
FILL-IN TIMEs are similar to TIME ALLOWANCEs, but do not have any operational meaning. A FILL-IN
TIME is a period of time, after a DRIVING SPELL, during which a driver is not assigned to any precise
activity. It may be spent at a particular TIMING POINT. Such an extra time is allowed at the end of a SPELL
for it to come up to an agreed minimum. It may be also a spare time resulting from the driver scheduling
process.
The start and end times of any DUTY component shall embrace any attached ‘PreparationDuration’,
‘FinishingDuration’, TIME ALLOWANCE or FILL-IN TIME (see model diagram in subclause 5.3.1).
5.3.2.5 Start and end places of duty components
The start and end places of a DRIVING SPELL are RELIEF POINTs, which can be derived from the RELIEF
OPPORTUNITies bordering that DRIVING SPELL.
The place of a NON-DRIVING SPELL is to be specified at a particular TIMING POINT.
A STRETCH starts from the starting TIMING POINT of its first SPELL (a RELIEF POINT in case of DRIVING
SPELL). It ends at the finishing TIMING POINT of its last SPELL (except in case of FILL-IN TIME, which
may be spent at another TIMING POINT). A BREAK is taken at a POINT where there is a BREAK FACILITY.
The start place and the end place of a DUTY PART may be specified. They are often places where DRIVERs
sign on or off (e.g. the CREW BASE). Such places shall be TIMING POINTs, in order to allow the assignment
of standard times from or to these places. This may involve a category of TIMING POINTs that are not
dealing with vehicle scheduling, but only with driver scheduling. The start TIMING POINT of a DUTY PART
may be different from the starting point of its first STRETCH. Similarly, the end TIMING POINT may be
different from the point reached in the last STRETCH (or BREAK).
Differences in start and end points of DUTY components may result in necessary DRIVER TRIPs,
described in the following sub-clause.
5.3.2.6 Start and end times
After completion of the driver scheduling, any period of work included in a DUTY PART will be assigned
to a precise type of activity, as the payroll would likely be based on a classification of activities for the
most part. When the driver scheduling is complete, checks shall be operated to ensure that, during a DUTY
PART, any time is assigned to only one activity, without any gap or overlapping.
The reference model allows the fixing of start and end times for a STRETCH, for example, before its
components have been designed. These provisional times are stored as optional attributes. At the final
stage of the design, these times will be identical to the times derived from the component data. This is
sometimes a reason to create an arbitrary FILL-IN TIME, to fill a gap if a STRETCH should have a minimum
duration.
The start and end times of a DRIVING SPELL can be derived from the times of the RELIEF
OPPORTUNITies, at the start and end of that DRIVING SPELL. Such times represent the production start
and end times. The real start and end times are derived from these production times, with the addition
of any ‘PreparationDuration’, ‘FinishingDuration’ or TIME ALLOWANCE attached to the SPELL, before or
after its production period.
The start and end times of NON-DRIVING SPELLs are stored in the ‘StartTime’ and ‘EndTime’ mandatory
attributes for this entity.
The duration of a FILL-IN TIME is fixed by a mandatory attribute. If the end place of a DRIVING SPELL is
the same than the location fixed for the following FILL-IN TIME, the start time of the latter is the end time
of the SPELL. If not, the FILL-IN TIME starts at the end of the corresponding DRIVER TRIP.
Within a STRETCH, any period of time between two SPELLs (including, for instance, TIME ALLOWANCEs)
shall be allocated to a DRIVER TRIP or a FILL-IN TIME.
Start and end times of a STRETCH may be derived from the SPELLs, complemented by a possible FILL-IN
TIME at the end of the last SPELL. They shall also include any ‘PreparationDuration’, ‘FinishingDuration’
or TIME ALLOWANCE attached to the STRETCH.
The duration of a BREAK is fixed by a mandatory attribute. If the end place of a STRETCH is the same as
the location of the BREAK FACILITY, then the start time of the BREAK is the end time of the STRETCH. If
not, the BREAK starts at the end of the corresponding DRIVER TRIP.
Within a DUTY PART, any period of time between two STRETCHes, or between a STRETCH and a BREAK,
shall be allocated to a DRIVER TRIP.
The start time of a DUTY PART may be derived from the start time of the first STRETCH, taking into
account any ‘PreparationDuration’ or TIME ALLOWANCE attached to the start of this DUTY PART. It shall
also include a possible DRIVER TRIP time, if the TIMING POINT specified for the start of the DUTY PART
is different from the start place of the first STRETCH.
The end time of a DUTY PART may be derived from the end time of the last STRETCH, taking into account
any ‘FinishingDuration’ or TIME ALLOWANCE attached to the end of this DUTY PART. It shall also include
a possible DRIVER TRIP time, if the TIMING POINT specified for the end of the DUTY PART is different
from the end place of the last STRETCH.
In a real implementation, start and end times of all components will probably be specified by attributes,
most of them being redundant.
5.3.2.7 Organisational units
DUTies may be related to ORGANISATIONAL UNITs (see EN 12896-1, Public transport - Reference data
model - Part 1: Common concepts). The BLOCKs to be covered by these DUTies may also be related to an
ORGANISATIONAL UNIT. Constraints may well be needed; for example, to check that BLOCKs covered by
a DUTY are managed by the ORGANISATIONAL UNIT that is in charge of that DUTY.
5.3.2.8 Tasks
NON-DRIVING SPELLs are either STAND-BYs (tactical reserve) or TASKs, classified as a particular TYPE
OF TASK. This covers regular TASKs such as taking buses through a wash, training session, social activity
etc.
The short-term planning of drivers usually also requires other additional TYPEs OF TASK.
5.3.2.9 Type of qualification
A DUTY may specify certain TYPEs of QUALIFICATION (see EN 12896-1, Public transport - Reference data
model - Part 1: Common concepts) which should be possessed by an assigned DRIVER. These could
include a certain number of years of driving experience, special knowledge of a particular part of the
network, particular social or demographic characteristics, or other properties which may affect the
suitability of a DRIVER for a particular type of DUTY. Some organisations may, for example, want to assure
a special suitability for DUTies with school bus operation.
The necessary TYPEs of QUALIFICATION may be specified for each SPELL of driver work, taking into
account the individual activities included in the SPELL in question, or may be related to the whole DUTY.
The first case requires the management of TYPEs of QUALIFICATION on a rather detailed level. In the
second case, the duty manager will often have a choice among a limited number of defined TYPEs of
QUALIFICATION to be entered at DUTY level, reflecting the global needs for all activities in the lower-
level component parts of the DUTY.
5.3.2.10 Accounting factor
The work time of drivers may not always be paid evenly at the same rates. If this is the case, input
information needs to be recorded for particular component parts of DUTies, which will be needed for
wage accounting after the DUTies have actually been worked.
An ‘accounting factor’ may be defined using a corresponding ‘AccountingFactor’ attribute of DUTY PART,
STRETCH or SPELL. This factor gives the proportion of paid time in the components in question. It will
usually range from 0 to 1 and will actually be 1 in most cases. Alternatively, an ‘accounting time’ duration
may be specified instead of a factor, using the ‘AccountingTime’ attribute, if the organisation wants to
express the modified amount of time to be paid in terms of a lump sum.
The accounting factor is more relevant for BREAKs, PAUSEs and FILL IN TIMEs. These parts of a driver’s
work time are sometimes paid by a percentage less than 100. A DRIVER TRIP may also be not fully paid
in some cases. An accounting factor may therefore also be stored for a DRIVER TRIP.
If accounting factors are specified at different levels of the DUTY components hierarchy, the factor stored
against a DUTY PART or STRETCH will override all specifications given at lower levels but will not
override the accounting factor for a BREAK.
Accounting factors are not used to specify an increase of the wages as a result of particular aggravation
circumstances during work, or to give an additional bonus for overtime worked by the DRIVER. Entities
to describe these factors are introduced in subclause 5.5.3.4.
5.3.2.11 Duty types
DUTies shall be classified as being of a particular DUTY TYPE, which indicates their time profile for
rostering purposes. Rostering algorithms usually make an initial assignment of DUTies to LOGICAL
DRIVERs according to the DUTY TYPE, to give a spread of DUTies which is fair or agreed for each DRIVER.

Figure 7 – Duty Type MODEL
SPLIT DUTY and CONTINUOUS DUTY are the main DUTY TYPEs. If a DUTY is made up of two DUTY PARTs,
then it shall be classified as SPLIT DUTY. If it is made up of only one DUTY PART, then it shall be classified
as a CONTINUOUS DUTY. Other DUTY TYPEs may be individually defined by an organisation to meet its
own particular needs (e.g. to allow for DUTies made up of three or more DUTY PARTs). In addition,
descriptions such as “early” or “late” may also classify them. The ranges of start and end times of any
DUTY TYPE can be described by relationships to the TIME BAND entity. The time range of the unpaid part
of a SPLIT DUTY may be described in the same way.
5.3.3 Driver trips
The driver scheduling process takes 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. Such a DRIVER TRIP will often be on
foot but may be on a VEHICLE JOURNEY driven by another driver. The time for these trips may depend
on the time of day. The entity DRIVER TRIP TIME allows for a set of times for each DRIVER TRIP. This
duration depends on a TIME BAND, in principle, but many organisations will just store one time per
DRIVER TRIP.
A RIDE IN DRIVER TRIP is a part of a DRIVER TRIP corresponding to the theoretical movement of a driver
on one and only one public transport vehicle, from one POINT IN JOURNEY PATTERN to another on a
JOURNEY PATTERN.
Figure 8 – Driver Trip MODEL
It is possible that a DRIVER TRIP might be complex and might involve waiting for infrequent VEHICLE
JOURNEYs. In this case, organisations might prefer to assess the time it will take by methods normally
used for passenger information queries. For this reason, DRIVER TRIP may be associated with a TRIP
PATTERN (see EN 12896-6,Public transport - Reference data model - Part 6: Passenger information).
The inclusion of DRIVER TRIPs within the DUTies may be necessary for various reasons: for example, the
starting relief of a DRIVING SPELL may be at a different RELIEF POINT than the end relief of the previous
one. The duration of such DRIVER TRIPs shall be included in the work plan of a DUTY. Their values will
be calculated according to standard times.
DRIVER TRIPs will be necessary when a driver is required to move:
— Between two SPELLS, i.e. from or to RELIEF POINTs (places of RELIEF OPPORTUNITies) or TIMING
POINTs (where a NON-DRIVING SPELL takes place);
— From or to the TIMING POINT where a FILL-IN TIME is spent;
— From the end point of a STRETCH (i.e. of a SPELL or of the added FILL-IN TIME) to the TIMING POINT
where a BREAK FACILITY is located;
— From a TIMING POINT where a BREAK FACILITY is located to the start of the next STRETCH;
— From the TIMING POINT where a DUTY PART starts (e.g. CREW BASE) to the TIMING POINT where
the first STRETCH (i.e. the first SPELL) starts (e.g. GARAGE POINT or another RELIEF POINT);
— From the last TIMING POINT of a STRETCH (e.g. RELIEF POINT) to the TIMING POINT where a DUTY
PART ends (assuming that a DUTY PART never ends with a BREAK).
Once the various components are fixed, their start and end places are known, and it is possible to retrieve
the required DRIVER TRIPs and their standard duration (DRIVER TRIP TIME).
Some operators may not want to manage standard times for any possible driver trip. Instead, they define
a global time used as lump sum for wage accounting to cover these access or return trips. Such a global
time may include the time spent by DRIVERs for their movement from home to work and vice versa. To
allow for such practices, there are optional attributes ‘DriverAccessDuration’ and ‘DriverReturnDuration’
in the DUTY PART entity. This practice is, in principle, separate from explicit DRIVER TRIPs. Therefore,
additional attributes to specify for instance the start time of a BREAK after a driver trip shall be added in
such a particular implementation.
5.3.4 Driver schedule frame
Figure 9 – Driver Schedule Frame MODEL
A DRIVER SCHEDULE FRAME is a coherent set of DUTies to which the same set of VALIDITY CONDITIONs
have been assigned. Typically, a DRIVER SCHEDULE FRAME represents the theoretical work of a group
of LOGICAL DRIVERs.
5.4 Rostering
5.4.1 General remarks
After completion of the driver scheduling, most operators carry out a long-term assignment of LOGICAL
DRIVERs to DUTies, in order to prepare the assignment of DRIVERs to these DUTies for each day of
operations of a given planning period. Such 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”). This
long-term plan is likely to be modified in the short-term.
The scheduled DUTies have to be assigned to the DRIVERs in a way that meets the legal restrictions and
any agreements made between the company and the driver unions. Furthermore, preferences expressed
by the DRIVERs themselves may be taken into account to a certain extent. Finally, the rostering process
aims at ensuring that, for any day, each DUTY is covered by a DRIVER.
In most cases, this is achieved through the definition of cyclic periods (of a certain number of days) and
of driver groups. Sets of daily DUTies are assigned to such a cycle, each set being worked in turn by a
DRIVER of a group. This ensures that the workload is distributed equally among DRIVERs, and that no
DRIVER works an unacceptable pattern of DUTY TYPEs (e.g. only SPLIT DUTies for many subsequent
days). A classical method for that distribution is to order the DUTies to be worked by a driver in a specific
sequence (driver roster) with respect to their DUTY TYPEs.
There are numerous different rostering methods applied in organisations over European countries. The
principles above apply to most of conventional methods. However, methods of driver management are
likely to evolve, including the development of new concepts fundamentally different from any classical
rostering schemes. New approaches more able to adapt to modern management principles and
differentiated DRIVER preferences will probably be tried and used by public transport organisations in
the coming years.
The reference model does not look to hinder any innovative development in the field of driver
management. The rostering part of the conceptual data model therefore has to be considered as a
reference basis for organisations working with one of the conventional rostering methods that have been
taken into account in the model design. It should only be used for information by users implementing
other methods, especially the most advanced.
However, this part of the reference model contains more entities than would ever be needed by any single
organisation using one of the conventional methods addressed by the model. Therefore, each
organisation may choose those parts of the rostering model that would satisfy the needs of the particular
rostering method they want to apply.
5.4.2 Roster matrices
Figure 10 – Roster Matrix Overview
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.
The rows of the matrix are associated with the drivers, and the columns are associated with the days of a
specified planning period. There are various ways of presenting a ROSTER MATRIX, and some
organisations may use this schema with the rows and columns swapped for example, but according to
the most common practice the rows of a ROSTER MATRIX are defined as the ROW/DRIVER entity and the
columns as the COLUMN/DAY entity.
A ROSTER ELEMENT, defined by one ROW/DRIVER and one COLUMN/DAY, is a cell of the matrix where
an individual DUTY will be entered. This DUTY will have to be worked by the driver corresponding to the
row, on the day associated with the column of the matrix.
Note that the DRIVER entity describes a physical driver, who is an EMPLOYEE of the public transport
organisation, in contrast to the ROW/DRIVER entity, which is a LOGICAL DRIVER in the planning process,
without any individual person attached to it. DRIVERs will be assigned to ROWs/DRIVERs at a later stage.
During the first steps of designing a ROSTER MATRIX, the COLUMNs/DAYs may continue to be qualified
only by an order. Before the matrix can be finalised, each COLUMN/DAY should be assigned to an
OPERATING DAY. It is necessary to take into account the days where less DUTies are needed. Therefore,
the assignment of OPERATING DAYs to DAY TYPEs is preferably shown on the matrix.
All DRIVERs working for the same organisation are not necessarily managed in the same ROSTER
MATRIX. Groups of DRIVERs may be defined, according to various parameters specific to the
organisation. For each group, a separate ROSTER MATRIX will be used for assigning sequences of DUTies
to the DRIVERs of this specific group. Thus, there may be more than one
...