Standard for implementation
Link functions vs. data
The domain of Public Transport may be described in terms of functions or functional areas. One of the problems related to the definition of a domain in terms of the functional areas is to be independent from the organisational aspects of Public Transport companies and from time aspects.
The functional areas defined in Transmodel can be understood as objectives of the system being defined.
Twenty eight (28) functional areas have been identified by Transmodel, as shown in the following table:
Not all functional areas have been studied during the development of Transmodel (shaded areas are outside the scope of Transmodel). For some of the studied functional areas the data necessary has been defined for all functions in such a functional area (Y). Some areas are only partly covered (P) by the data model, which means that all data are described for some of the functions only.
Transmodel area number Transmodel area name
Covered by Transmodel
1 Study passenger behaviour and determine the demand
2 (Re)design the network
3 Plan the service to be offered
P
4 Define a fare policy P
5 Plan detailed timetables
Y
6 Schedule vehicle blocks Y
7 Schedule driver duties Y
8 Prepare driver rosters Y
9 Manage drivers Y
10 Manage vehicles P
11 Perform and control the driving process Y
12 Plan and organise passenger information
13 Provide passenger information on the planned service Y
14 Provide passenger information on the actual service Y
15 Plan maintenance work
16 Plan and process maintenance orders
17 Control maintenance work
18 Manage incidents P
19 Analyse maintenance actions
20 Manage material P
21 Organise sales P
22 Operate sales P
23 Validate/check and charge Y
24 Manage money transactions
25 Manage statistical results P
26 Manage personnel P
27 Define marketing policy
28 Improve and maintain the relation with the public
Table 1: Functional areas identified by Transmodel
Transmodel documentation provides indications as regards the functional coverage of each functional area.
Conceptual model vs. implementation
Transmodel describes the domain of public transport in terms of data structures for a range of functional areas in an implementation-independent way.
This means in particular, that Transmodel may be implemented as a data repository (data base, e. DDL schema) or used for the exchange of data (definition of a data exchange format, e.g. XML). (See figure below, source NeTEx – 1).
In any case, for the design of a data base or of a data exchange format, if intended to be derived from Transmodel, the steps are as follows:
- Retrieval of a submodel A (in UML) from Transmodel corresponding to a particular functional objective
- Decision as to the choice of a particular target implementation type (e.g. XML)
- Design of a physical model corresponding to A and dedicated to a target implementation type (UML for XML implementation)
- Development of an XML schema.
Currently, the standard implementations target an XML data exchange format.
A cross reference between the Transmodel Parts (representing clusters of functional areas) and the implementation standards NeTEx, SIRI, OJP, OpRa is summarized below.
Link Transmodel vs. derived standard implementations: Transmodel ecosystem
The following table shows the interactions between Transmodel parts 1-10 (developed within SG4 of CEN TC278 WG3 ) and the Transmodel-based implementation standards developed as well within CEN TC278 WG3 subgroups (SG7 for SIRI, SG8 for OJP, SG9 for NeTEx, SG10 for OpRa).
| Part | Functional area | Exchange Format | ||
|---|---|---|---|---|
| 1 | Common Concepts | NeTEx | ||
| 2 | Public Transport Network | NeTEx | ||
| 3 | Timing Information and Vehicle Scheduling | NeTEx | ||
| 4 | Operations Monitoring and Control | SIRI | ||
| 5 | Fare Management | NeTEx | ||
| 6 | Passenger Information | SIRI NeTEx OJP | ||
| 7 | Driver Management | |||
| 8 | Management Information and Statistics | OpRa | ||
| 9 | Informative Documentation | |||
| 10 | Alternative Modes | NeTEx |
Table 2: The different parts of Transmodel and the linked standard
This figure shows Transmodel as the basis for a family of interoperable data standards, including National Standards. And a basis for the development and implementation of national standards.
SIRI
SIRI is a CEN Technical Specification that provides a European interface standard for exchanging information about the planned, current or projected performance of real-time public transport operations between different computer systems.
NeTEx
NeTEx is a CEN Technical Specification for exchanging Public Transport schedules and related data. It is divided into several parts, each covering a functional subset of the CEN Transmodel for Public Transport Information:
OJP
OJP is a CEN Technical Specifcation which defines a schema for establishing an open API for Distributed Journey Planning that can be implemented by any local, regional or national journey planning system in order to exchange journey planning information with any other participating local, regional or national journey planning system.
OpRa
OpRa is an CEN initiative with main focus on the identification of Public Transport raw data to be exchanged, gathered and stored in order to support Study and Control of Pubic Transpoprt Service.
Links between the Transmodel documents and the implementation standards
In this table you can find the different links between the Transmodel published documents and the published parts of the implementation standards in the Transmodel eco-system. Each published document is linked to an official standard that can be identified by his CEN number.
Transmodel EN12896 NeTEx SIRI OJP OpRa CoRom
Part 1: Common Concepts – EN 12896-1 Public Transport Network topology (CEN TS 16614-1)
Part 2: Public Transport Network – EN 12896-2 Public Transport Network topology (CEN TS 16614-1)
Part 3: Timing Information and Veh. Scheduling – EN 12896-3 Scheduled Timetables (CEN TS 16614-2)
Part 4: Operations Monitoring and Control – EN 12896-4 see SIRI Context and framework (EN 15531-1)
Communications infrastructure (EN 15531-2)
Functional service interfaces (EN 15531-3)
Functional service interfaces: Facility Monitoring (CEN TS 15531-4)
Functional service interfaces: Situation Exchange (CEN TS 15531-5)
Control Actions (CEN TS15531-6)
Part 5: Fare Management (Tarifs) – EN 12896-5 Fare information (CEN TS 16614-3)
Part 5: Fare Management (Sales) – EN 12896-5 project started 2023
Part 5: Fare Management (Validation&Control) – EN 12896-5
Part 6: Passenger Information – EN 12896-6 see OJP & PI profiles Open API for distributed journey planning CEN TS 17118
Part 7: Driver Management – EN 12896-7
Part 8: Management Information and Statistics – EN 12896-8 see OpRa Operational Raw data and statistics exchange – (CEN TR TR17370:2019)
continuation started 2024
Part 9: informative documentation – TR 12896-9
Part 10: Alternative modes – EN 12896-10 Alternative Modes API (CEN TS 16614-5)
| NeTEx Profiles | SIRI Profiles |
|---|---|
| Part 4: European Passenger Information Profile (EPIP) CEN/TS 16614-4:2017 | Passenger Real Time Information European Profile (EPIP-RT) 15531-7 |
| Part 6: European Passenger Accessibility Profile (EPIAP) CEN/TS 16614-6:2024 | |
| Part 7: European Fares Profile – ongoing |