National foreword

This British Standard is the UK implementation of EN 12896‑8:2026. It supersedes BS EN 12896‑8:2019, which is withdrawn.

The UK participation in its preparation was entrusted to Technical Committee EPL/278, Intelligent transport systems.

A list of organizations represented on this committee can be obtained on request to its committee manager.

Contractual and legal considerations

This publication has been prepared in good faith, however no representation, warranty, assurance or undertaking (express or implied) is or will be made, and no responsibility or liability is or will be accepted by BSI in relation to the adequacy, accuracy, completeness or reasonableness of this publication. All and any such responsibility and liability is expressly disclaimed to the full extent permitted by the law.

This publication is provided as is, and is to be used at the recipient’s own risk.

The recipient is advised to consider seeking professional guidance with respect to its use of this publication.

This publication is not intended to constitute a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of the Standards Policy and Strategy Committee on 31 October 2026.

This European Standard was approved by CEN on 28 September 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 foreword

This document (EN 12896‑8:2026) has been prepared by Technical Committee CEN/TC 278 “Intelligent transport systems”, 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 March 2027, and conflicting national standards shall be withdrawn at the latest by March 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‑8:2019.

Annex C provides details of the significant technical changes between this document and EN 12896‑8: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 series, 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.

For information on the conventions, methodology, and notations for conceptual modelling and the core principles of Transmodel, refer to EN 12896‑1.

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

The present document is composed of the following data packages:

Indicators;
Reusable components;
Explicit frames for statistics
Query.

This document itself is composed of the following parts:

main document representing the conceptual foundations and corresponding data model (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‑8:2019 (informative)

2 Normative references

3 Terms, definitions and abbreviations

3.1 Terms and definitions

3.2 Abbreviations

3.3 General information

4 Management Information and Statistics Domain

4.1 Introduction

Management information deals with functions analysing production data to evaluate the service quality or to take corrective measures in planning and managing operations. In public transport, for instance, the study of operational data (e.g. observed passing times, passenger load, delays and cancellations) collected during service operations is an input for strategic planning (e.g. how and when to amend the schedules), tactical planning (e.g. when to undertake a certain control action), quality follow-up, etc.

Management information uses therefore three main types of data:

data resulting from the planning stages, i.e. theoretical data on the production orders (e.g. timetables, target passing times, driver rosters, etc.);
data describing the daily actual production (e.g. observed passing times, actual number of passengers, number of late or cancelled journeys, etc.);
data aggregations and calculated statistics (late journey duration intervals, number and percentage of late and cancelled journey occurrences)

Advances in technology for data capture, exchange, storage and analysis make it possible to make these data available in operational and management information systems for use by a broad range of stakeholders, such as PT operators, authorities, system suppliers, and analysts. Consistent data structures make it easier to define interoperable queries and data exchanges for specific tasks such as performance monitoring, service quality assessment, delay and cancellation analysis, capacity and passenger-demand evaluation, operational control, reporting to authorities, and service planning and optimisation.

4.2 Data Preparedness Levels

4.3 Recording Service and Vehicle Performance Events

4.3.1 Introduction

The record of events related to the performance of vehicle journeys, in particular service journeys, on each day of their operation is an important source of information for management information. The main information to record is the following:

actual passing times at points along the route;
the number of passengers boarding and alighting and the time taken to do so;
the occurrence of impeded time;
interchange realisation;
the occurrence of disturbances.

The diagram below shows such recorded information that exist in Transmodel. Several use cases use the data from the diagram.

The Recorded Object MODEL (figure 2) for vehicle monitoring demonstrates how Transmodel supports the capture, storage, and association of operational data related to VEHICLE MONITORING. Key functionality of the model:

Vehicle monitoring events: the model can record monitored vehicle journeys, including their operational context (e.g., operating day, service journey, and vehicle journey references). Each monitored journey can be broken down into monitored legs and monitored trips, which are linked to trip patterns and stops.
Temporal and spatial data: the model can handle observed passing times, recorded stops, and interchange statuses, ensuring accurate timestamps and location references (e.g., places, zones).
Logging and traceability: all monitored activities can be logged through vehicle monitoring log entries and trip monitoring log entries, providing traceability for auditing and performance analysis.
Granularity and composition: the model allows hierarchical decomposition of journeys into legs and trips, supporting detailed monitoring at different levels of granularity.
Integration with service data: recorded objects should reference planned data such as service journeys, vehicle journeys, and stop points, enabling comparison between planned and actual operations.
Flexibility for operational adjustments: the model should accommodate real-time updates, such as boarding and alighting events, and interchange adjustments, to reflect actual passenger and vehicle behaviour.

However, according to user needs many other operating raw data may be recorded.

4.4 Statistical Concepts and Methods in OpRa

4.4.1 Introduction

OpRa conceptual model defines the statistical foundation for operational public transport data. It organizes how events (such as delays, cancellations, passenger counts, and service intensities) are systematically counted, aggregated, and analysed. The model introduces:

Counting: Classes for recording individual events (e.g., each delayed or cancelled journey, passenger boardings) and for aggregating these counts over defined scopes (e.g., per day, line, or network).
Aggregation: Mechanisms to summarize raw event data into meaningful indicators (e.g., total delays, mean delay, total cancellations, average passenger load).
Occurrence Analysis: Structures for tracking how often specific events (like delays or cancellations) happen, supporting both simple counts and more complex occurrence statistics (e.g., by cause or context).
Intervaling: Support for splitting data into intervals (such as delay duration bands or time periods), enabling analysis of distributions (e.g., how many journeys were delayed by 5–10 minutes vs. 10–20 minutes).
Filtering and Scoping: Tools for restricting statistics to specific fleets, lines, time periods, or operational contexts, ensuring relevant and comparable results.

These statistical constructs enable OpRa to provide standardized, comparable, and actionable management information for operators, authorities, and analysts, supporting both operational monitoring and strategic planning.

4.5 Conceptual data model

4.5.1 Introduction

OpRa’s schema design follows a model-driven architecture paradigm, where all data structures originate from formal UML conceptual models. These models capture the logical entities, relationships, and constraints required for operational public transport data analysis. The mapping from UML to XSD is manual but guided by a set of transformation rules and experiences from NeTEx and SIRI, still ensuring traceability between the conceptual specification and the physical schema.

This approach guarantees that any evolution or correction in the business semantics is reflected unambiguously in the technical implementation. Furthermore, model-driven design supports tool-assisted validation, code generation, and documentation, and facilitates future harmonization with other standards in the Transmodel family.

The OpRa conceptual data model (Figure 4) is split into four main groups, each defined as an UML package. There are 23 (sub)packages in total, with 65 classes defined locally inside that subtree, which are grouped in 30 class diagrams. Across the EA model, those classes appear 145 times in logical class diagrams.

The UML package structure organizes the OpRa data model into four major conceptual packages, each grouping related models for clarity and modularity.

EF Explicit Frame MODELs define the explicit frame containers used to exchange OpRa data. It is composed of RF Indicator Frame MODEL, PF Planned Frame MODEL, AF Actual Frame MODEL and CI Contextual Indicator Frame MODEL. Together these subpackages define the frame types that carry indicator data, planned service data, actual operational data and contextual indicator data within a coherent versioned exchange structure;.
ID Indicator MODELs is the main container for the operational indicator domain. It is structured into the subpackages CJ Cancelled Dated Vehicle Journeys MODELs, LJ Late Dated Vehicle Journeys MODELs, EX Expected Number of Passengers MODELs, PX Measured Number of Passengers MODELs, OC Offered Capacity MODELs, SD Service Dimensions Indicator MODELs, SI Service Intensity Indicators MODELs and FD Fleet Dimensions Indicators MODELs. These subpackages cover disruption indicators, passenger demand and measurement indicators, capacity indicators, service-performance indicators and fleet-related indicators. In the current UML model, the SD, OC and FD packages also contain dedicated UC Use Cases subpackages for use-case-oriented structuring;
RC Reusable Components MODELs define the common building blocks reused across the indicator packages. It is composed of DM Data Managed Object MODEL, which provides key-list and key-value structures for managed data objects, FS Filtering Support MODELs, which define reusable scope structures such as CALENDAR AWARE PT SCOPE and FLEET SCOPE, and GA Generic Aggregations MODELs, which define generic aggregation concepts such as OCCURRENCE, DURATION INTERVAL and DURATION DISTRIBUTION. These reusable components avoid duplication and ensure that the indicator models apply common semantics for identification, scoping and aggregation;
Finally, a complementary QM Query Models section provides structures for querying and reporting. Together, these packages create a layered architecture that supports monitoring, analysis, forecasting, and control of public transport services in alignment with Transmodel standards.

OpRa by default only provides references to the original data in a LOG ENTRY. This use of references has been used to help manage the size of data being transferred by OpRa. If the consuming system does not have access to the details of the original data, for example a PT SCOPE, then this data will need to be transferred separately.

When using OpRa the system participants will need to agree how and when concrete log objects or raw data are used.

Colour is used systematically in OpRa to help make the diagrams easier to understand. Elements from the same functional domain are mostly given the same default colour in all diagrams across all the different levels of abstraction and are based on those used in Transmodel. All new OpRa classes have red top triangle and blue borders with their scoped connector lines in the same blue colour.

Lines in red identify connections new in Transmodel v6.2.

Bibliography