SIST-TS CEN/TS 17370:2026

• Abstract:

  The OpRa scope is the definition of a minimum set of Public Transport raw data needed to enable PT quantitative analysis.; OpRa does not go into the domain of service quality measurement and reporting: service quality analysis will use data provided by OpRa, but quality definition remains a contractual level issue between a Public Transport Authority and a Public Transport Operator or an operator’s internal choice for a purely private service. OpRa reports unbiased actual data (i.e. measured or observed), described and aggregated in a shared and understandable way.; OpRa focuses mainly on observed/measured and registered information, i.e. information which cannot be changed anymore in the future. This information is mainly an output of the domain “operations monitoring & control" as defined by Transmodel.; Based on the actual service, including delays and cancelled vehicle journeys, etc., OpRa considers the recorded reality of operation, either through individual observed and registered data at a given sampling interval (raw data) or in an aggregate way (indicators) and provides the data exchange format.; The approach documented in detail in this document is coherent with EU Directive 2010/40. It relates to the Article 4 of the Delegated Regulation EU 2017/1926 [16], as regards the historic data. OpRa proposes to complement NeTEx (dedicated to the static scheduled information), for the historic data, based on the underlying conceptual data reference model Transmodel EN 12896, similarly to the requirement of the Delegated Regulation EU 2017/1926 referring to the static scheduled information2.

• Status: Published
• Public Enquiry End Date: 12-Aug-2026
• Publication Date: 29-Oct-2026
• ICS: 03.220.99 - Other forms of transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ITC - Information technology
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 28-Oct-2026
• Due Date: 02-Jan-2027
• Completion Date: 30-Oct-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

• Replaces: SIST-TP CEN/TR 17370:2019 - Public transport - Operating raw data and statistics exchange
• Effective Date: 01-Dec-2026
• Refers: SIST EN 12896-8:2026 - Public transport - Reference data model - Part 8: Management information & statistics
• Effective Date: 07-Oct-2026

SIST-TS CEN/TS 17370:2026 is the Slovenian adoption of the CEN draft Technical Specification on public transport operating raw data and statistics exchange (OpRa). It specifies an XML-based data exchange format and API for sharing a minimum set of raw and aggregated operational data for quantitative analysis in public transport. The standard is aimed at public transport authorities, operators and system providers that need agreed data for planning, monitoring, service analysis and reporting.

What does SIST-TS CEN/TS 17370:2026 specify?

SIST-TS CEN/TS 17370:2026 specifies how public transport operational raw data and statistics are structured, identified and exchanged. Its scope is the exchange of observed, measured and registered operational information, and it explicitly keeps service quality definition and reporting outside the standard, leaving that to contracts or local decisions.

The document is organized as a technical specification with clauses on scope, references, terms, XML notation, compatibility with existing standards, regulatory links, reference data, use cases, conceptual and physical data models, message exchange, XML schemas, common XML structures and indicators. Annex A provides the sample network used for the worked examples.

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

What are the key requirements of SIST-TS CEN/TS 17370:2026?

SIST-TS CEN/TS 17370:2026 requires implementers to exchange operational data in a shared structure that is compatible with Transmodel and NeTEx. In practice, this means systems must not just send values - they must also send the surrounding references, validity and context needed for the receiving system to interpret the data correctly.

• Clause 1 - scope and data focus: the standard is centred on raw and aggregated operational data for quantitative analysis, such as observed run times, delays, cancellations and passenger load. For users, that means the data is intended for operational analysis and planning, not for defining service quality targets.

• Clauses 5 and 14 - XML notation and common structures: the document defines how XML elements, attributes, references and table-based structure descriptions are written. This matters because implementers need a common reading of element names, multiplicity, data types and relationships when building interfaces.

• Clause 8 - reference data, identifiers and namespaces: OpRa uses explicit rules for object identification beyond system borders, including participant identification and participant pair identification. This matters in practice because both sides of an exchange must agree which namespace and identifier scheme applies, especially for shared objects such as lines, stops, directions and vehicle features.

• Clause 8.5 - data formats: the document specifies formats for date and time, time zones, georeferences and national language text elements. That allows systems to exchange operational records without ambiguity in timestamps, locations or multilingual text.

• Clause 9 - use cases and prioritization: the standard is built from use cases grouped into service offer, service demand, service externality, service economy and service efficiency. The use case analysis is large - 88 use cases in total - and gives implementers a clear view of which data items support each analysis task.

• Clauses 10 and 11 - conceptual and physical data models: OpRa defines a conceptual UML model and a physical XML Schema Definition (XSD) model, including prepared data levels, statistics, service dimensions, fleet dimensions, passenger counts, service intensity, delayed and early journeys, cancelled journeys, versioning, validity and responsibility. For implementers, this is the core mapping guide from transport concepts to actual exchange files and API payloads.

• Clauses 12 and 13 - message exchange and services: OpRa uses request-response and subscription mechanisms, with HTTP/1.1 and XML content, and it defines services such as publication, discovery and delivery. This matters because system design must support both immediate queries and notification-style exchanges, not only file transfer.

• Clause 15 - indicators: the document defines indicator families for service dimensions, fleet dimensions, capacity, passenger counts, service intensity, delayed and early vehicle journeys, cancelled journeys and contextual indicators. This gives readers a structured way to request and interpret aggregated operational measures instead of raw event streams.

What terms does SIST-TS CEN/TS 17370:2026 define?

SIST-TS CEN/TS 17370:2026 uses a set of domain terms and abbreviations that are central to implementation and data exchange.

• OpRa - Operating raw data and statistics exchange, the standard’s exchange framework for public transport operational data.
• API - Application programming interface, the service interface used for machine-to-machine exchange.
• SIRI - Service Interface for Real-time Information, the procedure and schema family that OpRa reuses for message exchange.
• NeTEx - Network and Timetable Exchange, the standard basis used here for network topology and scheduled timetable structures.
• Transmodel - The public transport reference data model used as the conceptual basis for OpRa semantics and data reuse.
• OPERATING DAY - the operational day for transport process control, which may differ from a calendar day and can extend past midnight.
• IndicatorFrame - the container used to exchange indicators together with their validity conditions and scope.
• ParticipantRef - the general-purpose namespace reference used to identify the information provider in exchanges.

Who uses SIST-TS CEN/TS 17370:2026?

SIST-TS CEN/TS 17370:2026 is used by public transport authorities, public transport operators and system providers that need to exchange operational data in a consistent way. The document also addresses travel information service providers and other stakeholders named in the regulatory context around multimodal travel information services.

In practice, users apply the standard to:

• exchange observed operational data for planning and analysis
• compare planned, expected and actual service performance
• build indicators for service intensity, passenger load, delays and cancellations
• support service monitoring, control and post-operation statistics
• share data between authority, operator and system platforms with agreed identifiers and formats

What changed in SIST-TS CEN/TS 17370:2026 from the previous edition?

SIST-TS CEN/TS 17370:2026 supersedes CEN/TR 17370:2019. Compared with the earlier report, this edition develops OpRa into a technical specification with a defined XML exchange format and API, a larger use-case catalogue, and a detailed conceptual and physical data model.

The document also adds structured coverage of message exchange, services and XML schemas, and it expands the treatment of indicators, versioning, validity, responsibility and operating days. Annex A provides a worked sample network to support the examples used throughout the document.

Which standards are used with SIST-TS CEN/TS 17370:2026?

SIST-TS CEN/TS 17370:2026 is built around several companion standards and linked documents.

• EN 12896-8 - provides the Transmodel basis for management information and statistics, and supplies the terms and definitions used in the document.
• CEN/TS 16614-1 - contributes the NeTEx network topology basis used in the exchange model.
• CEN/TS 16614-2 - contributes the NeTEx scheduled timetables basis used in the exchange model.
• EN 15531-2 - provides the SIRI message exchange procedure, including request-response and publish-subscribe behaviour.
• EN 15531-3 - provides the XML element notation style used to present interface structures.
• EN 13816 - is used as the service quality compatibility reference when the standard discusses quality measurement frameworks.
• EN 15140 - is used as the compatibility reference for measurement methods and recommendations for delivered service quality.

What does the SIST-TS CEN/TS 17370:2026 document contain?

SIST-TS CEN/TS 17370:2026 contains the notation rules for XML elements, the compatibility discussion with Transmodel and service quality standards, and the rules for reference data and namespaces. It then develops a use-case catalogue, a conceptual UML data model and a physical XML/XSD model for OpRa.

The document also includes message-exchange rules for request-response and subscriptions, service definitions, common XML structures, indicator families and worked examples. Many sections are supported by tables, model diagrams, XML examples and example payload structures so that implementers can map the concepts into system interfaces and test data exchanges.

SLOVENSKI STANDARD
01-december-2026
Nadomešča:
SIST-TP CEN/TR 17370:2019
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: CEN/TS 17370:2026
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.

CEN/TS 17370
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
September 2026
TECHNISCHE SPEZIFIKATION
ICS 35.240.60; 03.220.99
English Version
Public transport - Operating raw data and statistics
exchange
Öffentlicher Verkehr - Betriebliche Rohdaten und
statistischer Austausch
This Technical Specification (CEN/TS) was approved by CEN on 21 September 2026 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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

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
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
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
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
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
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

European foreword
This document (CEN/TS 17370:2026) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document supersedes CEN/TR 17370:2019.
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 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.
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.

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 ma
...