EN 12896-1:2026

• Abstract:

  This document incorporates data structures used by all other data domains of Transmodel. It is composed of the following data packages:; - versions and validity;; - responsibility;; - generic framework;; - reusable components;; - explicit frames referring to generic data.; The data structures represented in this part are either generic patterns that can be explicitly reused in other domains (e.g., a generic model for version frames, a generic grouping mechanism, etc.) or are referenced by different other parts (e.g., service calendar model).; 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 present in the main document, together with their definitions (normative);; - Annex B, indicating the data model evolutions (informative),; - Annex C, presenting the Transmodel development history (informative),; - Annex D, describing all conventions, methodology and notations for conceptual modelling (informative),; - Annex E, providing a clear overview to help readers understand the core principles, structure, and purpose of Transmodel (informative),; - Annex F, providing information on the Functional domains and Modes of operation (informative).; - Annex G, providing details of the significant technical changes between this document and EN 12896-1:2015 (informative).

• Status: Published
• Publication Date: 30-Jun-2026
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: CEN/TC 278 - Road transport and traffic telematics
• Drafting Committee: CEN/TC 278/WG 3 - Public transport (PT)
• Current Stage: 6060 - Definitive text made available (DAV) - Publishing
• Start Date: 01-Jul-2026
• Due Date: 22-Sep-2026
• Completion Date: 01-Jul-2026
• Directive: 2016/797/EU - Directive (EU) 2016/797 of the European Parliament and of the Council of 11 May 2016 on the interoperability of the rail system within the European Union (Text with EEA relevance)
• Ref Project: SIST EN 12896-1:2026 - Public transport - Reference data model - Part 1: Common concepts

• Replaces: EN 12896-1:2016 - Public transport - Reference data model - Part 1: Common concepts
• Effective Date: 19-Jun-2024
• Referred By: CEN/TR 18359:2026 - Public transport – Common Glossary
• Effective Date: 30-Sep-2026
• Referred By: EN 12896-7:2026 - Public transport - Reference data model - Part 7: Driver management
• Effective Date: 25-Aug-2026
• Referred By: EN 12896-4:2026 - Public transport - Reference data model - Part 4: Operations monitoring and control
• Effective Date: 25-Aug-2026
• Referred By: EN 12896-5:2026 - Public transport - Reference data model - Part 5: Fare management
• Effective Date: 25-Aug-2026
• Referred By: EN 12896-3:2026 - Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
• Effective Date: 25-Aug-2026
• Referred By: EN 12896-2:2026 - Public transport - Reference data model - Part 2: Public transport network
• Effective Date: 15-Jul-2026
• Referred By: EN 12896-10:2022 - Public transport - Reference data model - Part 10: Alternative Modes
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 15531-1:2007 - Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 16614-6:2024 - Public transport - Network and timetable exchange (NeTEx) - Part 6: European Passenger Information Accessibility Profile
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 17402:2020 - Intelligent transport systems - Urban ITS - Use of regional traffic standards in a mixed vendor environment
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 16614-1:2020 - Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 16614-4:2020 - Public transport - Network and Timetable Exchange (NeTEx) - Part 4: Passenger Information European Profile
• Effective Date: 08-Jul-2026
• Referred By: CEN/TS 16614-1:2014 - Public transport - Network and Timetable Exchange (NeTEx) - Part 1: Public transport network topology exchange format
• Effective Date: 08-Jul-2026
• Referred By: EN 15531-1:2015 - Public transport - Service interface for real-time information relating to public transport operations - Part 1: Context and framework
• Effective Date: 08-Jul-2026

EN 12896-1:2026 is the CEN European Standard for Transmodel Part 1, the common concepts part of the public transport reference data model. It specifies the shared conceptual data model used across the other Transmodel data domains, covering versioning and validity, responsibility, generic framework structures, reusable components, and explicit frames. It is intended for organisations that specify, design, develop, acquire, integrate, or operate public transport information systems and interfaces.

What does EN 12896-1:2026 specify?

EN 12896-1:2026 specifies the common concepts that other parts of Transmodel reuse. Its scope is the shared data structures used by all other Transmodel data domains, so it acts as the base layer for the wider public transport reference model.

The document groups those shared structures into five data packages:

• versions and validity
• responsibility
• generic framework
• reusable components
• explicit frames referring to generic data

The standard is organised as a normative main document plus annexes. Annex A is normative and contains the data dictionary and attribute tables for the concepts in the main document. The remaining annexes are informative and give background, modelling guidance, historical context, and change information.

Annex	What it covers
Annex A	Data dictionary and attribute tables for all concepts in the main document
Annex B	Data model evolutions
Annex C	Development history of Transmodel
Annex D	Conventions, methodology, and notations for conceptual modelling
Annex E	Overview of the core principles, structure, and purpose of Transmodel
Annex F	Functional domains and modes of operation
Annex G	Significant technical changes between this document and EN 12896-1:2015

In practice, this part is the common foundation for later Transmodel parts. That matters because implementers can reuse the same model patterns instead of redefining version control, organisations, locations, or time-based structures in each domain.

What are the key requirements of EN 12896-1:2026?

EN 12896-1:2026 sets out the common modelling structures that make the rest of Transmodel consistent. The most important content is in Clauses 5 and 6, with Annex A providing the definitions and attribute tables that support the model.

Versions and validity

Clause 5.2 defines the versioning and validity framework, including Generic Entity, Generic Versioning, Generic Version Frame, Generic Validity, Generic Delta, and Generic Type of Value. In practice, this is the part to use when data must be versioned, dated, or compared over time.

That matters for schedule updates, network changes, equipment updates, or any public transport data that has a lifecycle. It helps a system distinguish current data from past or future data and track changes in a controlled way.

Responsibility and organisation

Clause 5.3 covers Generic Responsibility, Responsibility Role, and Generic Organisation. This gives Transmodel a common way to represent who is accountable for data, decisions, or services.

For organisations, this is useful when different actors share a data set or a process, such as an authority, operator, or service provider. It supports clear assignment of roles, which is important for governance, interface ownership, and audit trails.

Explicit frames

Clause 5.4 defines explicit frames such as Composite Frame, General Frame, Resource Frame, and Service Calendar Frame. These frames are the packaging mechanism for groups of related data.

In practice, frames help separate data into exchangeable blocks. That makes interfaces easier to design and maintain because a system can send or receive a defined frame instead of a loose set of unrelated objects.

Generic framework model

Clause 5.5 is the broad shared modelling toolkit. It includes location systems, grouping, points and links, link sequences, zones and features, layers, projection, place, path and navigation, assignment, loggable object, event, security list, accessibility, alternative text, and views.

This matters because many later Transmodel parts depend on the same location and navigation concepts. For a reader implementing the standard, this clause is the core reference for how common spatial and structural data are represented once and reused across domains.

Reusable components

Clause 6 defines reusable components that can appear in any Transmodel functional package. The main groups are Transport Mode, Transport Submode, Transport Mode of Operation, place and organisation components, time element models, vehicle types, vehicles and fleets, equipment, message models, and general elements.

The time element models are especially practical:

• Service Calendar models temporal characteristics such as DAY TYPEs, OPERATING DAYs, and SERVICE CALENDARs
• Availability Condition models standardized validity conditions
• Transfer Times specifies times for making a transfer between services

For day-to-day implementation, these models help keep timetable, availability, and transfer logic consistent across systems.

Vehicle, equipment, and message structures

Clause 6.5 covers vehicle-related models such as Vehicle Type, Train Types, Train Element Type, Fleet Equipment, Deck Plan, Seating Plan, Seat Affinity, and Deck Path. Clause 6.6 covers Vehicle, Fleet, and Train Composition. Clause 6.7 covers equipment models such as Facility, Generic Equipment, Actual Vehicle Equipment, Energy Equipment, Spot Equipment, Vehicle Passenger Equipment, and Deck Sensor Equipment.

These clauses matter when a system needs to describe rolling stock, onboard layout, passenger facilities, or energy-related equipment in a structured way. Clause 6.8 adds a reusable message model, and Clause 6.9 adds general-purpose elements such as Alternative Name, Service Restriction, Environmental Properties, Booking Arrangements, Check Constraint, and Schematic Map.

What terms does EN 12896-1:2026 define?

EN 12896-1:2026 defines the core terminology used to read the model correctly. The following terms are central to the document:

• Conceptual data model - a description of a real-world domain in terms of entities, relationships, and attributes, independent of implementation.
• Data domain - a set of related data structures used together by a functional area or group of functions.
• Functional area - an activity grouping used to define the objectives and limits of the data model.
• Interoperability - the ability of systems to interact according to predefined interface rules.
• Public Transport (PT) - the transport domain to which the standard applies.
• Transmodel (TM) - the reference data model for public transport that this part belongs to.
• Automatic Vehicle Monitoring (AVM) - computer-aided support for monitoring and controlling vehicle operation in real time.

These terms matter because they define how to interpret the classes, packages, and diagrams in the rest of the document.

Who uses EN 12896-1:2026?

EN 12896-1:2026 is used by public transport organisations, authorities, operators, and software suppliers that work with information systems. Clause E.3 says it is a reference standard for organisations with an interest in public transport information systems, and that individual systems do not need to implement the whole model.

It is particularly relevant for people who specify, acquire, operate, design, develop, or supply systems for:

• database structures
• system interfaces
• integrated public transport information architectures
• modular products that need to work together
• interworking between organisations, such as a public authority and a transport operator

Annex F shows the functional scope in practice, including network and stop description, timing information and vehicle scheduling, operations monitoring and control, fare management, passenger information, personnel management, management information, multi-model operations, multiple operator environment aspects, and fleets and equipment.

What changed in EN 12896-1:2026 from the previous edition?

EN 12896-1:2026 supersedes EN 12896-1:2016. Annex G gives the significant technical changes between this document and EN 12896-1:2015.

Annex B also shows how the model has evolved, including:

• components consolidated from earlier Transmodel parts
• reusable message and publication scope models
• additions from Part 10, such as Transport Mode of Operation, Fleet, Fleet Equipment, and extended organisation and employee models
• functional changes added in this version of Transmodel

This tells readers that the current edition is not just a reprint of the earlier model. It reflects consolidation and extension of the common data framework.

What does the EN 12896-1:2026 document contain?

EN 12896-1:2026 contains the conceptual model structure for the common concepts part of Transmodel, together with the definitions that support it. The main body presents the shared packages for versions and validity, responsibility, explicit frames, generic framework, and reusable components.

The document also contains:

• a normative data dictionary and attribute tables in Annex A
• modelling conventions, methodology, and notation rules in Annex D
• an overview of Transmodel’s principles and purpose in Annex E
• functional-domain context in Annex F
• development history and evolution material in Annex B and Annex C
• a technical change summary in Annex G

It uses conceptual model sections, model overviews, and detailed class-style entries such as those for Service Calendar, Deck Plan, Vehicle Type, Notice, and Schematic Map. Those parts are meant for design, integration, specification, and exchange of public transport data, not for quoting implementation-specific values or formulas.

SLOVENSKI STANDARD
01-oktober-2026
Nadomešča:
SIST EN 12896-1:2017
Javni prevoz - Referenčni podatkovni model - 1. del: Splošni pojmi
Public transport - Reference data model - Part 1: Common concepts
Öffentlicher Verkehr - Datenreferenzmodell - Teil 1: Gemeinsame Konzepte
Transports publics - Modèle de données de référence - Partie 1: Concepts communs
Ta slovenski standard je istoveten z: EN 12896-1:2026
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.

EN 12896-1
EUROPEAN STANDARD
NORME EUROPÉENNE
July 2026
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 12896-1:2016
English Version
Public transport - Reference data model - Part 1: Common
concepts
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Datenreferenzmodell - Teil 1:
Partie 1: Concepts communs Gemeinsame Konzepte
This European Standard was approved by CEN on 15 April 2026.

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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists 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.
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
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 12896-1:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
3.1 General information technology terms. 7
3.2 Domain-specific terms . 9
4 Abbreviations . 10
5 Common concepts domains . 11
5.1 Introduction to the common concepts . 11
5.1.1 General. 11
5.1.2 Core framework mechanisms . 11
5.1.3 Generic framework elements . 11
5.1.4 Reusable framework components . 12
5.2 Versions and validity . 15
5.2.1 Introduction . 15
5.2.2 Version and Validity – Model overview . 15
5.2.3 Generic Entity – Conceptual MODEL. 16
5.2.4 Generic Versioning . 16
5.2.5 Generic Version Frame . 17
5.2.6 Generic Validity – Conceptual MODEL . 19
5.2.7 Generic Delta – Conceptual MODEL . 19
5.2.8 Generic Type of Value – Conceptual MODEL . 20
5.3 Responsibility . 21
5.3.1 Introduction . 21
5.3.2 Responsibility – Model overview . 22
5.3.3 Generic Responsibility . 22
5.3.4 Responsibility Role – Conceptual MODEL . 23
5.3.5 Generic Organisation . 25
5.4 Explicit frames . 27
5.4.1 General. 27
5.4.2 Composite Frame – Conceptual MODEL . 27
5.4.3 General Frame – Conceptual MODEL . 28
5.4.4 Resource Frame – Conceptual MODEL . 28
5.4.5 Service Calendar Frame – Conceptual MODEL . 29
5.4.6 Other explicit frames . 30
5.5 Generic framework model . 31
5.5.1 Overview . 31
5.5.2 Generic framework - Overview . 31
5.5.3 Location Systems – Conceptual MODEL . 32
5.5.4 Generic Grouping . 33
5.5.5 Generic Points and Links . 34
5.5.6 Generic Point and Link Sequences . 37
5.5.7 Generic Zones and Features . 38
5.5.8 Generic Layer – Conceptual MODEL . 40
5.5.9 Generic Projection . 41
5.5.10 Generic Place – Conceptual MODEL . 46
5.5.11 Generic Path and Navigation MODEL – Conceptual Model . 46
5.5.12 Generic Assignment – Conceptual MODEL . 47
5.5.13 Generic Loggable Object – Conceptual MODEL . 48
5.5.14 Generic Event – Conceptual MODEL . 49
5.5.15 Generic Security List – Conceptual MODEL . 49
5.5.16 Generic Accessibility . 50
5.5.17 Alternative Text – Conceptual MODEL . 53
5.5.18 Generic Views – Conceptual MODEL . 54
6 Reusable Components . 54
6.1 General . 54
6.2 Reusable Components – Modes . 55
6.2.1 General . 55
6.2.2 Transport Mode – Conceptual MODEL . 55
6.2.3 Transport Submode – Conceptual MODEL . 55
6.2.4 The Transport Mode of Operation – Conceptual MODEL . 56
6.3 Reusable Components – Place & Organisation. 57
6.3.1 General . 57
6.3.2 Topographic Place – Conceptual MODEL. 58
6.3.3 Transport Organisation . 58
6.3.4 Additional Organisation – Conceptual MODEL . 60
6.3.5 Employee – Conceptual MODEL . 61
6.3.6 Role Models . 61
6.4 Reusable Components – Time Element Models . 67
6.4.1 Service Calendar . 67
6.4.2 Availability Condition – Conceptual MODEL . 69
6.4.3 Transfer Times – Conceptual MODEL . 70
6.5 Reusable Components – Vehicle Types . 71
6.5.1 General . 71
6.5.2 Vehicle Type – Conceptual MODEL . 71
6.5.3 Train Types – Conceptual MODEL . 72
6.5.4 Train Element Type – Conceptual MODEL . 74
6.5.5 Fleet Equipment – Conceptual MODEL . 75
6.5.6 Deck Plan - MODEL . 76
6.5.7 Seating Plan – Conceptual MODEL . 81
6.5.8 Seat Affinity – Conceptual MODEL . 82
6.5.9 Deck Path – Conceptual MODEL . 83
6.6 Reusable Components – Vehicles and Fleets . 84
6.6.1 Vehicle – Conceptual MODEL . 84
6.6.2 Fleet – Conceptual MODEL . 85
6.6.3 Train Composition – Conceptual MODEL . 86
6.7 Reusable Components – Equipment . 87
6.7.1 General . 87
6.7.2 Facility – Conceptual MODEL . 88
6.7.3 Generic Equipment – Conceptual MODEL . 88
6.7.4 Actual Vehicle Equipment – Conceptual MODEL . 89
6.7.5 Onboard Vehicle Recharging Equipment Profile – Conceptual MODEL . 90
6.7.6 Energy Equipment – Conceptual MODEL . 91
6.7.7 Spot Equipment – Conceptual MODEL . 92
6.7.8 Vehicle Passenger Equipment – Conceptual MODEL . 93
6.7.9 Deck Sensor Equipment – Conceptual MODEL . 94
6.8 Reusable Message Model . 95
6.8.1 General. 95
6.8.2 Notice – Conceptual MODEL . 95
6.8.3 Notice Assignment – Conceptual MODEL . 96
6.8.4 Message – Conceptual MODEL . 97
6.8.5 Publication Scope – Conceptual MODEL . 98
6.9 Reusable General Elements . 99
6.9.1 General. 99
6.9.2 Alternative Name – Conceptual MODEL . 99
6.9.3 Service Restriction – Conceptual MODEL . 99
6.9.4 Environmental Properties – Conceptual MODEL . 100
6.9.5 Booking Arrangements – Conceptual MODEL. 100
6.9.6 Check Constraint – Conceptual MODEL . 101
6.9.7 Schematic Map – Conceptual MODEL . 102
Annex A (normative) Data dictionary . 108
Annex B (informative) Data model evolution . 216
Annex C (informative) Transmodel development history . 219
Annex D (Informative) Conventions and Methodology for Conceptual Modelling . 227
Annex E (informative) Understanding transmodel . 250
Annex F (informative) Functional domains and Modes of operation . 255
Annex G (informative) Significant technical changes between this document and the
previous edition . 262
Bibliography . 263

European foreword
This document (EN 12896-1:2026) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport system”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by January 2027, and conflicting national standards shall
be withdrawn at the latest by January 2027.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes EN 12896-1:2015.
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-
1:2015
Annex D describes all conventions, methodology and notations for conceptual modelling, applicable to
the EN 12896 series.
Annex E provides a clear overview to help readers understand the core principles, structure, and purpose
of Transmodel.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: 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 the United
Kingdom.
1 Scope
This document incorporates data structures used by all other data domains of Transmodel. It is composed
of the following data packages:
- versions and validity;
- responsibility;
- generic framework;
- reusable components;
- explicit frames referring to generic data.
The data structures represented in this part are either generic patterns that can be explicitly reused in
other domains (e.g., a generic model for version frames, a generic grouping mechanism, etc.) or are
referenced by different other parts (e.g., service calendar model).
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
present in the main document, together with their definitions (normative);
- Annex B, indicating the data model evolutions (informative),
- Annex C, presenting the Transmodel development history (informative),
- Annex D, describing all conventions, methodology and notations for conceptual modelling
(informative),
- Annex E, providing a clear overview to help readers understand the core principles, structure,
and purpose of Transmodel (informative),
- Annex F, providing information on the Functional domains and Modes of operation
(informative).
- Annex G, providing details of the significant technical changes between this document and EN
12896-1:2015 (informative).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions.
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 General information technology terms
3.1.1.
attribute
property of an entity
3.1.2.
conceptual data model
admitted term
description of a real world domain in terms of entities, relationships and attributes, in an implementation
independent manner, which should provide a structure on which the rest of the development of an
application system can be based
3.1.3.
conceptual level
conceptual data model in the context of data modelling
3.1.4.
database
collection of data; often used in the sense of the physical implementation of a data model
3.1.5.
data domain
data structure (in this document, a part of the Reference data model for public transport) made up of data
related to each other, through the fact that there is a functional area or group of functions using this data
set as a whole
3.1.6.
data model
description of a real world domain in terms of data and relationships
3.1.7.
entity
object (data) that has its own existence (as opposed to an attribute)
3.1.8.
function
activity, or in this document, sub-activity of a functional area
3.1.9.
functional area
arbitrarily defined set of activities, used, in this European Standard, to define the objectives and limits of
the data model
3.1.10.
GDF database
database containing geographical information on the road network in a particular application area,
possibly including information on the location of public transport points, links and services (routes)
3.1.11.
interoperability
ability of (sub)systems to interact with other (sub)systems according to a set of predefined rules
(interface)
3.1.12.
logical data model
data design, that takes into account the type of database to be used, but does not consider means of
utilization of space or access
3.1.13.
logical denormalized model
relational data model that is not fully normalized, i.e., does not completely follow the normalization rules
and thus can be redundant
3.1.14.
logical level
logical data model in the context of data modelling
3.1.15.
relational data model
type of logical data model giving the information as series of tables (relations) and attributes
Note to entry: It will have the following characteristics: 1. all attribute values are atomic; 2. all “tuples”
(rows/occurrences) are distinct; 3. no part of the primary key may be null; 4. foreign key values will correspond to
an existing primary key in another relation or be null.
3.1.16.
object oriented data model
data structure expressed according to principles that allow for a direct implementation as an object-
oriented database, where information is represented in form of objects, i.e., respecting the principle of
encapsulation meaning in particular that each data is accessed or modified through operations (methods)
belonging to it
3.2 Domain-specific terms
NOTE Terms which are also used as the names of Transmodel ENTITies are not included here.
3.2.1.
fare management
all activities related to the collection of money from passengers
3.2.2.
management information
all activities allowing the company management to collect the information necessary to meet problem-
solving needs
Note to entry: Data of operational systems are filtered and aggregated for this purpose, and made available to the
user interactively, or in the form of pre-defined reports and summaries. Such functions are in principle related to
all functional areas of a company, with particular reference to the management of statistical results.
3.2.3.
operations monitoring and control / real-time control
all activities related to the transportation process, i.e., real-time functions related to the driving and
transportation of passengers according to given instructions, including the monitoring of the driving
process and its control in case of deviations, as well as all activities that support the driving process
(traffic light priority, track switching, bay selection, advance/delay advice etc.)
Note to entry: Such functions are often assisted by computer-aided tools, known as Automated Vehicle Monitoring
(AVM)
3.2.4.
passenger information
all activities related to informing the users either about the planned or about the actual transportation
services
3.2.5.
personnel disposition
all activities related to the mid-term and short-term management of drivers
3.2.6.
tactical planning / scheduling
all activities related to the tactical planning of transportation, split into vehicle scheduling, driver
scheduling, rostering
4 Abbreviations
API Application Programming Interface
AVM Automatic Vehicle Monitoring
CC Common Concepts
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
PTO Public Transport Operator
OJP Open Journey Planner
OpRa Operating Raw Data and statistics exchange
RC Reusable Component
SIRI Service Interface for Real-time Information
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
VDV Verband Deutscher Verkehrsunternehmen (Germany)
WGS World Geodetic Standard
5 Common concepts domains
5.1 Introduction to the common concepts
5.1.1 General
This section describes the common concepts and components (CC) of Transmodel that are shared by all
Transmodel functional parts. This data domain has three main aspects: a core framework, a set of generic
framework elements, and a set of reusable components.
5.1.2 Core framework mechanisms
The Core framework provides mechanisms for common aspects of all Transmodel objects that are
needed for effective data management and exchange, such as versioning, validity, grouping, and
responsibility tracking. The mechanisms, implemented through common super types and containers, and
specialised in the various Transmodel functional modules, can be understood and implemented
uniformly for all Transmodel components, rather than on an ad hoc basis. The framework splits into:
Versions and Validity model: describes the successive versions of data elements and the conditions to
be attached to elements to precisely know when they should be used:
— generic entity model;
— generic version model;
— generic version frame model;
— generic validity model;
— generic type of value model;
— generic delta model.
Responsibility model: describes the type of responsibility or role the different organisations may have
over the data:
— generic responsibility model;
— generic responsibility role model;
— generic organisation model.
5.1.3 Generic framework elements
Generic framework: describes a number of generic objects and representational mechanisms that are
not specific to transport but which are specialised or used by Transmodel transport related objects. This
part splits into:
— generic location model;
— generic grouping model;
— generic point and link model;
— generic point and link sequence model;
— generic section model;
— generic zone model;
— generic feature model;
— generic layer model;
— generic projection model;
— generic place model;
— generic path & navigation model;
— generic assignment model;
— generic loggable object model;
— generic event model.`
— generic security list model;
— alternative text model;
5.1.4 Reusable framework components
Reusable components: Certain common low-level components, for example TRANSPORT MODE,
SERVICE CALENDAR, DAY TYPE, etc. are not specific to any particular functional part of Transmodel but
are widely used in several different functional areas. Such components are defined centrally as part of
the common concepts.
The Reusable components models describe generic and reusable objects specific to public transport.
These are organised into a number of functional areas:
— Reusable mode models characterising the different transport modes;
— transport mode model;
— transport submode model;
— travel means model;
— transport mode of operation model;
— Reusable place & organisation models characterising the places and organisations related to in
public transport;
— topographic place model;
— topographic projection model;
— transport organisations model;
— additional organisations model;
— employee model;
— Reusable role models characterising the roles acted by organisations and individuals in public
transport;
— common role model;
— service organisation role model;
— administrative organisation role model;
— technology organisation role model;
— messaging role model;
— transport user role model;
— employee role model;
— Reusable time element models characterising commonly used temporal concepts;
— service calendar model;
— availability condition model;
— transfer timing model;
— Reusable vehicle type models characterising vehicle types;
— deck plan model;
— deck path model;
— seating plan model;
— seating affinity model;
— vehicle type model;
— fleet equipment profile model;
— train type model;
— train element type model;
— Reusable vehicle models characterising vehicles;
— vehicle model;
— fleet model;
— train composition model;
— Reusable equipment models characterising commonly used equipment concepts;
— facility model;
— generic equipment model;
— actual vehicle equipment model;
— energy equipment model;
— spot equipment model;
— deck sensor equipment model;
— vehicle passenger equipment model;
— recharging equipment model;
— Reusable message models characterising messages and their scope;
— notice model;
— notice assignment model;
— message model;
— publication scope model;
— Reusable general elements characterising low level features such as text annotations;
— alternative name model.
— service restriction model;
— environmental properties model;
— booking arrangements model;
— accessibility model;
— check constraint model;
— schematic map model;
The Explicit frames model describes the mechanisms useful to build coherent sets of versioned data.
Part 1 presents explicit frames for data from the common concepts domain.
— composite frame model;
— general frame model;
— resource frame model;
— service calendar frame model;
The present document is structured according to the model structure as shown above.
5.2 Versions and validity
5.2.1 Introduction
Information systems for public transport operation typically require the definition of many different
types of data, produced by different organisations or operating divisions, and are subject to a multistage
lifecycle; from planning through to production and realization in real-time. These data are continuously
evolving and are subject to a variety of different validity conditions as to when they are current, and as
to which data are needed for a particular purpose. Transmodel includes uniform version and validity
mechanisms to address these requirements; the mechanisms are part of the Transmodel framework and
that can be applied to all data elements throughout their various lifecycles.
The versioning model allows successive versions of data elements to be identified, allowing the fine-
grained identification of just those elements that have changed, and the auditing of changes. All
references can also be versioned so that for composite data sets that comprise a number of related
elements it is possible to be precise as to which version of each element is required. The versioning model
also allows schemes where the responsibility for maintaining different parts of the data is split among
several organisations and systems, each providing its partial data separately. In this case, references to
external data are not explicitly versioned, but instead the correct version of the different referenced
entities are deduced from validity conditions when combining the data.
A version frame mechanism provides a versionable container that allows a coherent set of related
elements to be managed as a set or exchanged. Since pragmatically actual systems that contain data to be
exchanged differ in the sophistication of their support for versioning, the mechanisms are designed so
that they may be used either just in a course-grained manner at the level of the whole data set, or if
support is available, in a more powerful way at the level of the individual data element.
The validity model allows conditions to be attached to elements as to when they are current or the
circumstances in which they should be used. Validity conditions can be attached to specific elements and
also, through version frames, to whole sets of objects so that it is possible to be explicit about the exact
conditions governing the coherence and relevance of data. This makes it possible for systems to express
the currency conditions for data they require and to describe the validity of data that is returned by a
system.
5.2.2 Version and Validity – Model overview
The versioning mechanisms are part of the core Transmodel framework, and are provided by a common
set of modules that are referenced by all other Transmodel modules. The fundamental models are
described in detail in the following sections.
— the ENTITY model describes the Transmodel basic object structure;
— the VERSION model adds in version control elements and attributes. VERSION FRAMES group
multiple instances of versions of entities that make up a coherent version set;
— the RESPONSIBILITY model adds in metadata for ENTITY ownership and roles for data
management;
— the VALIDITY package defines generic validity conditions for use in the framework;
— the DELTA package refers to the detailed changes of a given ENTITY IN VERSION from one
VERSION to the next one.
5.2.3 Generic Entity – Conceptual MODEL
The entity ENTITY represents an actual object instance of data present in an exchanged data set. An
ENTITY may represent any instance of a CLASS IN REPOSITORY, corresponding to an instance of the
object as stored in a specific database. All Transmodel objects are formal descendants of ENTITY.
CLASSes IN REPOSITORY can be grouped into sets of coherent versions using a CLASS IN FRAME. CLASS
IN REPOSITORY and CLASS IN FRAME are part of the Transmodel conceptual model and help to make
clear the difference between classes of objects effectively present in a repository (CLASS IN REPOSITORY)
and classes of objects grouped to be managed as a coherent set (e.g., to be exchanged). Instances of objects
are ENTITies, more precisely a repository may contain many versions of an ENTITY. The TYPE of ENTITY
defines a set of sub-categories that can be used to make arbitrary classifications of a specific ENTITY.
Thus, it is really a “category of ENTITY” rather a class or type. TYPE OF ENTITY is an abstract mechanism
that is present in Transmodel to indicate the possibility of categorization. Actual Transmodel objects
generally have a more specific categorization, e.g., TYPE OF POINT, etc. that specifies a category that is
specific to the ENTITY type.
Figure 1 – Generic Entity – Conceptual MODEL
5.2.4 Generic Versioning
5.2.4.1 Overview
The modelling of versions in Transmodel is in effect a version description model, not a model of a version
management system. It allows for fine grained versioning, and uses a uniform and generic approach that
can be used for any time of complex data object. This versioning mechanism is available on all Transmodel
elements, but not mandatory, thus allowing legacy systems without any versioning mechanism to use
Transmodel in a basic manner simply by omitting the detailed versioning attributes. In practice,
versioning will be often just done at an aggregate level and not that of the individual data instance.
Public transport data are in a permanent process of evolution; schedule and operational data typically
undergo a regular cycle of planning, distribution and execution, while reference data describing the
network, such as stop and line data, will change if the network or physical environment is modified. It is
therefore necessary to be able to organise data elements to support such a lifecycle, with multiple
versions of a given element being in use concurrently, and different assemblies of data referencing
different versions for different purposes. This is achieved in Transmodel with VERSIONs and VERSION
FRAMEs.
5.2.4.2 Generic Version – Conceptual MODEL
Each state of an object, or a set of objects, is called a VERSION. VERSIONs of an object may be consecutive
or competitive. Consecutive VERSIONs describe the successive states of an object, while competitive
VERSIONs describe an alternative version to use in particular circumstances, i.e., under specific VALIDITY
CONDITIONs (cf. Generic VALIDITY – conceptual model below). For example, there may be for a single
line at the same time competitive versions of the line; a simulated line (for planning work or for study),
and the operational line for particular operating periods.
The VERSION describes the identifier and purpose of a version state. The actual version state of the
objects is described by an instance of ENTITY IN VERSION. Thus, in a given repository or documents there
will be a single instance of each Transmodel ENTITY and one or multiple instances of ENTITY IN
VERSIONs for that ENTITY; these will be tried together by a common identifier and differentiated by
distinct VERSION identifiers. For example, an instance of the entity SCHEDULED STOP POINT may have
multiple SCHEDULED STOP POINT IN VERSION instances, etc.
The purpose of the VERSION may be categorised with an arbitrary classification using a TYPE OF
VERSION, for example planning, scheduled, operational, etc.

Figure 2 – Generic version – Conceptual MODEL
5.2.5 Generic Version Frame
VERSION FRAMEs allow data to be managed and exchanged as a coherent version, that is, a set of
instances (ENTITies IN VERSION) of different entity types that are consistent and correct as to referential
integrity and other business semantics and so are suitable for use without extensive consistency
checking, for example, by an importing application. A VERSION FRAME contains a list of specific versions
of an entity, that is, instances of ENTITY IN VERSION.
Th
...