kSIST-TS FprCEN/TS 17370:2026

• Abstract:

  This project proposal addresses:; • the development of a data exchange format, based on Transmodel (EN12896) and NeTEx (CEN/TS 16614), focused on a minimum set of Public Transport raw data needed for quantitative analysis in public transport services. For instance, the elaboration of standardized operational data (e.g., observed run times, passenger load) 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.; • the development of a glossary for public transport aiming at assigning to each concept used in Public Transport, a unique “standard” term.; This project proposal develops a data exchange format and API, that will be documented in a Technical Specification (TS) focusing on the exchange of a minimum set of Public Transport raw data needed for quantitative analysis in public transport services.; The exchange protocol format will be based on NeTEx standard, in particular:; • CEN/TS 16614-1:2020 Network topology;; • CEN/TS 16614-2:2020 Scheduled Timetables;; Raw data identification and description will be compliant with Transmodel (EN 12896), with particular emphasis on Data Dictionary description and Part 8 Management Information Statistics.; OpRa will also develop a Public Transport unified glossary to harmonised terms and definitions from existing data dictionaries.

• Status: Not Published
• Public Enquiry End Date: 12-Aug-2026
• ICS: 03.220.99 - Other forms of transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 5520 - Unique Acceptance Procedure (UAP) (Adopted Project)
• Start Date: 03-Jun-2026
• Due Date: 21-Oct-2026
• Completion Date: 11-Jun-2026
• Directive: 2010/40/EU - Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport Text with EEA relevance
• Ref Project: CEN/TS 17370:2026 - Public transport - Operating raw data and statistics exchange

• Refers: oSIST prEN 12896-8:2026 - Public transport - Reference data model - Part 8: Management information & statistics
• Effective Date: 07-Oct-2026
• Revises: SIST-TP CEN/TR 17370:2019 - Public transport - Operating raw data and statistics exchange
• Effective Date: 20-May-2026

kSIST-TS FprCEN/TS 17370:2026 is a CEN Technical Specification for public transport (PT) operating raw data and statistics exchange. It specifies an XML-based data exchange format and application programming interface (API) for a minimum set of observed, measured and registered operational data, plus aggregated indicators, for quantitative analysis by PT authorities, operators and system providers. The document also standardises a PT glossary so the same operational concepts can be exchanged with one agreed term.

What does kSIST-TS FprCEN/TS 17370:2026 specify?

kSIST-TS FprCEN/TS 17370:2026 specifies a data exchange format and API for raw PT operational data and statistics used in quantitative analysis. It is about actual operating data - such as observed run times, passenger load and cancelled journeys - and about indicator-style summaries built from that data.

The scope keeps the focus on data that are already recorded and no longer change in the future. It also states that service quality definition and reporting are outside the scope, even though OpRa data can be used as an input to quality analysis.

The document is organised into clauses on scope, normative references, terms and definitions, XML notation, compatibility with existing standards, links to regulations, reference data, use cases, the conceptual Unified Modelling Language (UML) model, the physical data model, message exchange, services and XML schemas, common XML structures, and indicators. Annex A provides a sample network used in the examples.

Annex	What it covers
Annex A	A sample network used to illustrate the data generation and the examples, including distance table, estimated ridership, timetable, operational log and onboard device-based counting data

What are the key requirements of kSIST-TS FprCEN/TS 17370:2026?

Scope and data focus

Clause 1 limits kSIST-TS FprCEN/TS 17370:2026 to a minimum set of PT raw data for PT quantitative analysis. The standard centres on observed and registered information, including actual service, delays and cancelled vehicle journeys. In practice, this means users should treat OpRa as an exchange layer for factual operating data, not as a tool for changing or redefining the underlying service quality policy.

Clause 1 also says the approach is coherent with EU Directive 2010/40 and relates to the historic-data part of Delegated Regulation EU 2017/1926. That matters for organisations that need to align operational data exchange with multimodal travel information services (MMTIS) reporting or planning.

XML notation and data modelling

Clause 5 defines how XML elements, attributes, relationships and tables are written in the document. It distinguishes between logical model concepts, physical XML identifiers, references and data types. For implementers, this is the reading rule for the schemas: it shows how a business concept becomes an XML element, how references are marked, and how type checking is intended to work.

Clauses 10 and 11 turn the use cases into a conceptual UML model and then into a physical XML Schema Definition (XSD) model. The model includes data preparedness levels - raw, cleansed and processed - and reuses Transmodel, NeTEx and SIRI concepts where possible. In practice, this gives developers both the business structure and the schema-level structure needed to build interoperable systems.

Reference data, identifiers and scope

Clause 8 sets out how OpRa handles reference data across system borders. It requires unambiguous identifiers and namespaces for objects such as lines, stop points, directions and vehicle features, and it also covers date and time, time zones, georeferences and national language text elements. This is what allows two systems to point to the same object without confusion.

Clause 8 also introduces participant identification and participant pair identification. That matters because the same exchange can involve one system, a pair of systems, or a chain of systems, and each needs a clear identifier scope for messages, subscriptions and data objects.

Use cases and indicator families

Clause 9 defines the use-case-driven structure of the standard. The document builds a catalogue of 88 use cases grouped into generic high level, service offer, service demand, service externality, service economy and service efficiency. For readers, this shows that OpRa is not a single report format but a framework that supports several operational and analytical questions.

Clause 15 then specifies the indicator families used in the exchange. It covers measurement units, vehicle capacity and load specification, aggregation instructions, service dimensions, fleet dimensions, capacity, passenger count indicators, expected passenger counts, service intensity, delayed and early vehicle journeys, cancelled journeys and contextual indicators. In practice, this is the part to check when deciding whether the standard carries the operational metric you need.

Message exchange and services

Clauses 12 and 13 define how OpRa messages are exchanged and organised into services. The standard uses request-response and publish-subscribe procedures, with HTTP (Hypertext Transfer Protocol) and XML for message transport and content. That means implementers can build both on-demand queries and notification-style services.

Clause 13 also lists the service groups and their request elements, including Publication Request, Discovery Request/Response, Delivery Request/Response, OpRa publication subscription and termination, and status checking. The same clause explains that common structures are reused across services through shared schema files, which helps keep implementations consistent.

Frames and operating days

Clause 14 defines the common XML structures, including the root Opra element, service request structure and frame handling. It names PlannedFrame, ActualFrame, IndicatorFrame and ContextualIndicatorFrame. In practice, these frames separate planned data, actual data and indicator payloads so systems can request and process them independently.

Clause 11.8 defines OPERATING DAY and explains that it may differ from a calendar day. This is important for overnight services and long-distance operations, because a journey can be tied to the day of operation rather than to a simple midnight-to-midnight calendar day.

What terms does kSIST-TS FprCEN/TS 17370:2026 define?

• OpRa - Operating raw data and statistic exchange, the exchange framework described by the document.
• Operating day - the operational day used in transport control, which may cross calendar-day boundaries.
• ParticipantRef - the general-purpose namespace used to identify a communicating system and scope its messages and subscriptions.
• IndicatorFrame - the XML frame that carries indicators and their validity conditions.
• PlannedFrame - the frame used for planned service data in an OpRa exchange.
• ActualFrame - the frame used for actual service data in an OpRa exchange.
• API - application programming interface, the service style used for OpRa exchanges over HTTP and XML.

Who uses kSIST-TS FprCEN/TS 17370:2026?

kSIST-TS FprCEN/TS 17370:2026 is used by PT authorities, PT operators, travel information service providers, infrastructure managers and system providers that need to exchange operational data. It is also relevant to organisations working on multimodal travel information services (MMTIS) and data-driven PT governance.

In practice, users apply it for schedule analysis, control actions, demand and capacity studies, quality follow-up, service offer analysis, service efficiency reporting and indicator exchange. Buyers and implementers would typically check it when they need a common PT data model rather than a one-off local interface.

What changed in kSIST-TS FprCEN/TS 17370:2026 from the previous edition?

kSIST-TS FprCEN/TS 17370:2026 supersedes CEN/TR 17370:2019.

Which standards are used with kSIST-TS FprCEN/TS 17370:2026?

Standard	What it contributes
EN 12896-8	The normative reference listed for the document, and the source of the terms and definitions that apply
EN 12896 (series)	The common symbols and abbreviations, and the Transmodel conceptual basis
CEN/TS 16614-1:2020	NeTEx network topology basis
CEN/TS 16614-2:2020	NeTEx scheduled timetables basis
EN 15531-2	The SIRI message exchange procedure used for request-response and publish-subscribe patterns
EN 15531-3	The source of the tabular notation used to describe XML elements and structures
EN 13816:2002	The compatibility framework for service quality definition, targeting and measurement
EN 15140:2006	The compatibility framework for systems that measure delivered service quality

What does the kSIST-TS FprCEN/TS 17370:2026 document contain?

kSIST-TS FprCEN/TS 17370:2026 contains XML notation rules, compatibility notes, regulatory links, reference-data rules, a large use-case set, a conceptual UML model and a physical XSD-based model. It also includes detailed service definitions, common XML structures, frame-based exchange patterns and indicator families.

The document uses tables, figures, XML examples and worked use-case material to show how the data model is applied. Annex A adds a sample network so the examples can be read against a shared PT scenario.

SLOVENSKI STANDARD
01-julij-2026
Javni prevoz - Neobdelani operativni podatki in izmenjava statističnih podatkov
Public transport - Operating raw data and statistics exchange
Öffentlicher Verkehr - Betriebliche Rohdaten und statistischer Austausch
Ta slovenski standard je istoveten z: FprCEN/TS 17370
ICS:
03.220.99 Druge oblike transporta Other forms of transport
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.

FINAL DRAFT
TECHNICAL SPECIFICATION
FprCEN/TS 17370
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
May 2026
ICS Will supersede CEN/TR 17370:2019
English Version
Public transport - Operating raw data and statistics
exchange
Öffentlicher Verkehr - Betriebliche Rohdaten und
statistischer Austausch
This draft Technical Specification is submitted to CEN members for Vote. It has been drawn up by the Technical Committee
CEN/TC 278.
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 Technical Specification. It is distributed for review and comments. It is subject to change
without notice and shall not be referred to as a Technical Specification.

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. FprCEN/TS 17370:2026 E
worldwide for CEN national Members.

FprCEN/TS 17370:2026 (E)
Contents       Page
European foreword . 8
Introduction . 9
1 Scope . 11
2 Normative references . 11
3 Terms and definitions . 11
4 Symbols and Abbreviations . 11
5 Notation of XML-Elements and XML-Structures . 12
5.1 General . 12
5.2 Display of XML Elements in the Text . 13
5.3 Display of Relationships . 13
5.4 Table Notation of XML Structures . 14
5.4.1 General . 14
5.4.2 Grouping . 15
5.4.3 Element Name . 15
5.4.4 Multiplicity & Choice (min:max) . 15
5.4.5 Data Type . 16
5.4.6 Explanation . 16
6 Compatibility with Existing Standards . 16
6.1 Compatibility with Transmodel. 16
6.1.1 General . 16
6.1.2 Data structure reuse . 17
6.2 Compatibility with EN 13816:2002 — Service Quality Definition, Targeting
and Measurement . 18
6.3 Compatibility with EN 15140:2006 — Basic requirements and
recommendations for systems that measure delivered service quality . 19
7 Links to regulations . 20
7.1 Introduction. 20
7.2 Data required by the MMTIS regulation . 20
7.2.1 General . 20
7.2.2 Observed Data . 20
7.2.3 Historic Data . 21
7.2.4 Key Performance Indicator . 21
8 Types of Reference Data Used in OpRa . 21
8.1 General . 21
8.2 Identification of Objects beyond system borders . 22
8.2.1 General . 22
8.2.2 Object identifiers and namespaces . 22
8.3 Participant (information provider) identification . 23
8.3.1 General . 23
8.3.2 Model . 23
FprCEN/TS 17370:2026 (E)
8.3.3 Namespace and Scope . 23
8.4 Participant pair identification (service participant pair code) . 23
8.4.1 General . 23
8.4.2 Model . 23
8.4.3 Namespace and Scope . 23
8.5 Data formats . 24
8.5.1 Date & time . 24
8.5.2 Time Zones . 24
8.5.3 Georeferences . 24
8.5.4 National language of text elements . 25
9 Use cases . 25
9.1 General . 25
9.2 Purpose . 25
9.3 Actors and use case categories . 25
9.3.1 Actors . 25
9.3.2 Use case categories . 26
9.3.3 Collection of use cases . 27
9.4 Prioritisation of Use Cases . 31
9.4.1 Prioritisation . 31
9.4.2 Worked examples . 31
9.4.3 Service Offer . 32
9.4.4 Service Demand . 35
9.4.5 Service Efficiency . 38
10 Conceptual UML data model for OpRa . 43
10.1 Data preparedness . 43
10.1.1 Preparedness level raw . 44
10.1.2 Preparedness level cleansed . 44
10.1.3 Preparedness level processed . 45
10.2 Statistics . 45
10.2.1 Distribution analysis support . 45
10.2.2 Distribution of duration type indicators . 46
10.3 UML Concepts Used in OpRa . 47
10.3.1 Model-driven architecture . 47
10.3.2 Explicit Frames . 49
10.3.3 Generic Information and Statistics. 52
10.3.4 Indicators . 56
10.3.5 Service dimensions . 59
10.3.6 Fleet dimensions . 61
10.3.7 Offered capacity . 63
10.3.8 Measured number of passengers . 66
10.3.8.1 General . 66
10.3.8.2 Number of Passengers (counting device) . 66
10.3.8.3 Number of Passengers (counts at stops) . 68
10.3.8.4 Number of Passengers (validated access) . 70
10.3.9 Expected number of passengers . 72
10.3.10 Service intensity . 74
FprCEN/TS 17370:2026 (E)
10.3.11 Delayed and early vehicle journeys. 75
10.3.12 Cancelled vehicle journeys . 79
10.3.13 Query Model . 82
11 Physical Data Model . 85
11.1 Introduction. 85
11.2 Open Implementation and Technology Use . 85
11.3 Summary of Modelling Approach . 85
11.4 Common OpRa Framework . 86
11.5 Implementing Transmodel framework features in OpRa . 87
11.6 Versions & Validity . 87
11.6.1 Introduction. 87
11.6.2 Version & Validity – Model Dependencies . 88
11.6.2.1 Generic ENTITY – Conceptual MODEL . 88
11.6.2.2 Generic Entity – Physical Model . 90
11.6.2.3 Generic Entity – Attributes and XSD. 91
11.6.2.4 TypeOfEntity – Model Element . 93
11.6.2.5 XML Examples for generic Entities . 94
11.6.3 Generic Version . 96
11.6.3.1 General . 96
11.6.3.2 Generic VERSION – Conceptual MODEL . 96
11.6.3.3 Generic Version – Physical Model . 97
11.6.3.4 Version – Attributes and XSD . 99
11.6.3.5 XML Examples of use of Versions . 106
11.6.4 Implementing relationships in NeTEx . 108
11.6.4.1 Entity identifiers and uniqueness . 108
11.6.4.2 Associations and Entity References . 108
11.6.4.3 Relationship metaclasses. 110
11.6.4.4 XML Examples of Relationships . 111
11.6.5 Generic Version Frame . 114
11.6.5.1 Generic VERSION FRAME – Conceptual MODEL . 114
11.6.5.2 Generic Version Frame – Physical Model . 119
11.6.5.3 Version Frame – Attributes and XSD . 121
11.6.5.4 XML Examples of Version Frames . 133
11.7 Responsibility . 137
11.7.1 Introduction. 137
11.7.2 Responsibility – Model Dependencies . 138
11.7.3 Generic Responsibility . 138
11.7.3.1 Generic Responsibility – Physical Model . 139
11.8 Operating Days . 140
12 Message Exchange . 141
12.1 General . 141
FprCEN/TS 17370:2026 (E)
12.2 Use of SIRI Procedure . 141
12.3 HTTP and REST . 142
12.4 Roles of Server and Client . 142
13 Services and XML Schemas . 143
13.1 General . 143
13.2 Services Provided . 143
13.3 XML Schemas Used Across Services . 143
13.4 Imported Schemas . 144
13.5 Problems and Error States When Operating OpRa Services . 144
13.5.1 General . 144
13.5.2 Error Codes from SIRI . 144
13.5.3 OpRa ErrorCondition . 145
13.5.4 General OpRa Problems . 146
14 Common XML Structures . 146
14.1 General . 146
14.2 Root Element Opra . 146
14.2.1 General . 146
14.2.2 Service Request Structure . 147
14.2.3 Frames . 147
14.3 Generic XML Issues . 148
14.3.1 Indicator-related base definitions . 148
14.3.2 Generic scope for indicators . 150
14.3.3 Fleet scope for indicators . 151
14.3.4 Additional indicator type-specific scopes . 152
14.4 OpRa Service Interface . 152
14.4.1 Introduction . 152
14.4.2 Protocols versus payload . 153
14.4.3 NeTEx Publication XSD schema . 154
14.5 OpRa Service Usage Profiles . 154
14.5.1 Introduction . 154
14.5.2 Service Usage Profile Modelling Approach . 155
14.5.2.1 General . 155
14.5.2.2 Generic OpRa Payload Delivery . 156
14.6 Sample network used in use cases . 157
14.7 FRAMEs within the exchange . 157
14.7.1 General . 157
14.7.2 PlannedFrame . 157
14.7.2.1 Introduction . 157
14.7.2.2 Requesting . 158
14.7.3 ActualFrame . 160
14.7.3.1 Introduction . 160
14.7.3.2 Requesting . 160
14.7.4 IndicatorFrame . 161
14.7.4.1 Introduction . 161
14.7.4.2 IndicatorFrame PreparednessLevel . 164
FprCEN/TS 17370:2026 (E)
14.7.4.3 Default scope . 164
14.7.5 ContextualIndicatorFrame . 164
15 Indicators. 165
15.1 Introduction. 165
15.2 General considerations . 165
15.2.1 Measurement units . 165
15.2.2 Vehicle capacity specification . 166
15.2.2.1 Example . 167
15.2.3 Vehicle load specification . 168
15.2.4 Aggregation Instructions . 170
15.3 Service Dimensions . 171
15.3.1 Introduction. 171
15.3.2 Discovery . 171
15.3.3 Requesting . 172
15.3.4 Payload . 173
15.3.5 Example . 175
15.4 Fleet Dimensions . 176
15.4.1 Introduction. 176
15.4.2 Discovery . 176
15.4.3 Requesting . 177
15.4.4 Payload . 178
15.4.5 Example . 178
15.5 Capacity . 179
15.5.1 Introduction. 179
15.5.2 Discovery . 179
15.5.3 Requesting . 180
15.5.4 Payload . 181
15.5.5 Example . 181
15.6 Passenger Count Indicators . 182
15.6.1 Introduction. 182
15.6.2 Onboard Device Based Passenger Counts . 183
15.6.2.1 General . 183
15.6.2.2 Discovery . 183
15.6.2.3 Requesting . 184
15.6.2.4 Payload . 185
15.6.2.5 Example . 186
15.6.3 Ticketing-Based Passenger Counts . 187
15.6.3.1 Introduction . 187
15.6.3.2 Discovery . 188
15.6.3.3 Requesting . 189
15.6.3.4 Payload . 190
15.6.3.5 Example . 192
15.6.4 External Passenger Counts . 194
15.6.4.1 Introduction . 194
FprCEN/TS 17370:2026 (E)
15.6.4.2 Discovery . 194
15.6.4.3 Requesting . 195
15.6.4.4 Payload . 196
15.6.4.5 Example . 196
15.6.5 Expected Passenger Counts . 197
15.6.5.1 Introduction . 197
15.6.5.2 Discovery . 197
15.6.5.3 Requesting . 198
15.6.5.4 Payload . 199
15.6.5.5 Example . 199
15.7 Service Intensity . 201
15.7.1 Introduction . 201
15.7.2 Discovery . 201
15.7.3 Requesting . 202
15.7.4 Payload . 203
15.7.5 Example . 205
15.8 Delayed and Early Vehicle Journeys . 206
15.8.1 Introduction . 206
15.8.2 Discovery . 206
15.8.3 Requesting . 207
15.8.4 Payload . 208
15.8.5 Example . 211
15.9 Cancelled Journeys . 212
15.9.1 Introduction . 212
15.9.2 Discovery . 213
15.9.3 Requesting . 213
15.9.4 Payload . 214
15.9.5 Example . 216
15.10 Contextual Indicators . 216
15.10.1 Introduction . 216
15.10.2 Discovery . 218
15.10.3 Requesting . 219
15.10.4 Payload . 219
15.10.5 Example . 220
Annex A (informative) Sample network . 221
A.1 Network . 221
A.1.1 Introduction . 221
A.1.2 Distance table . 222
A.1.3 Estimated ridership . 222
A.1.4 Timetable . 223
A.1.5 Operational log . 223
A.1.6 Onboard device-based counting data . 224
Bibliography . 225

FprCEN/TS 17370:2026 (E)
European foreword
This document (FprCEN/TS 17370: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 Vote on TS.
This document will supersede CEN/TR 17370:2019.
This document has been prepared under a standardization request addressed to CEN by the European
Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
Member States.
FprCEN/TS 17370:2026 (E)
Introduction
General
The Public Transport (PT) sector, particularly for Public Transport Operators (PTO) and Public
Transport Authorities (PTA), has identified the necessity to develop a data strategy, based on cost and
value, focusing on the strategic benefits of data. It is crucial that mobility stakeholders are not only able
to compete against potential new market entrants but also benefit from a suitable environment to
develop new business models and services. Public transport is becoming a data-enabled or data-driven
business and needs to answer different local conditions.
This led to the need to standardize data analysis in Public Transport, to understand formally how
information can be created as added value, and indicator calculation can facilitate moving from a
qualitative analysis of the PT service towards a quantitative one.
With this perspective in mind, OpRa (Operating raw data and statistics exchange) defines a minimum
set of Public Transport raw data needed as PT quantitative analysis enabling factor.

Transport modes
OpRa takes most public transport modes, except air transport, into account. This specifically includes
rail, bus, metro, tramway, trolleybus, ferry, coach, funicular railway, suspension railway, and rack
railway.
OpRa management information
Management information deals with functions analysing production data, in order to evaluate the
service quality or to take corrective measures in planning and managing operations. In PT, for instance,
the study of operational data (e.g. observed run times, passenger load) 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, two main types of data:
— data resulting from the planning stages, i.e. theoretical data on the production orders (e.g.
timetables, run times, driver rosters, etc.);
— data describing the daily actual production (e.g. observed passing times, actual number of
passengers, missed interchanges, modifications operated to the plan, etc).
Advances in technology, in particular high density data storage, allow the creation and retention of all
the necessary underlying data in production databases, against which the desired requests can be made
by PT managers. Consistent data structures for management data will make the design of such requests
easier, and offer the flexibility required to OpRa exchange PT raw data, enabling indicator calculation.
Raw data is identified according to specific use cases and, where applicable, defined and described in
Transmodel (EN 12896) compliant structures. In this perspective, the exchange will be performed using
similar NeTEx modalities, for compatibility reasons.

OpRa exchanging data modality
Similar to NeTEx, the primary software resource for implementing an OpRa interface is based on XML
schema.
Two main variants of the schema are available, each providing a different protocol for embedding the
same content model subschemas.
— Simple OpRa documents exchange (see NeTEx _publication.xsd): a schema to use with NeTEx
documents input or output by a system that are exchanged as files using FTP, email etc;
— OpRa document exchange using SIRI HTTP requests (see NeTEx_siri_SG.xsd): a schema that
embeds the OpRa elements in a sequence of HTTP messages that define r
...