ISO/TR 24315-2:2025

Technical
Report
ISO/TR 24315-2
First edition
Intelligent transport systems —
2025-10
Management of electronic traffic
regulations (METR) —
Part 2:
Operational concepts (ConOps)
Systèmes de transport intelligents — Gestion des règles de
circulation sous forme électronique —
Partie 2: Concepts opérationnels
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 1
5 Current system or situation . 2
5.1 General .2
5.2 Background, objectives and scope .3
5.2.1 Background .3
5.2.2 Objectives .3
5.2.3 Scope of application .4
5.3 Operational policies and constraints .4
5.3.1 Policies .4
5.3.2 Constraints .5
5.4 Description of the current situation .5
5.4.1 General .5
5.4.2 Terminators .6
5.4.3 Processes .9
5.4.4 Data flows .10
5.4.5 Additional stakeholders .10
5.4.6 Data details . 12
5.5 Modes of operation for the current situation . 15
5.6 User classes and other involved personnel .16
5.6.1 General .16
5.6.2 Users subject to rules .16
5.6.3 Entities that establish rules.17
5.6.4 Third party entities .18
5.7 Support environment . . .18
5.7.1 General .18
5.7.2 Sources of support .19
6 Justification for and nature of changes . .20
6.1 General . 20
6.2 Justification of changes . 20
6.2.1 General . 20
6.2.2 Evolving transport environment . 20
6.2.3 Discrepancy reports .21
6.3 User need statements . 23
6.3.1 Trustworthiness needs. 23
6.3.2 User needs . 35
6.3.3 Rule maker needs . 44
6.3.4 Third party needs: auditing . 48
6.4 Priorities . 48
6.5 Deferred user needs . . 48
6.5.1 General . 48
6.5.2 User needs deferred to a future release . 49
6.5.3 User needs considered but not included . 49
6.6 Assumptions and constraints . 49
6.6.1 Assumptions . 49
6.6.2 Constraints .51
7 Concepts for the proposed system .52
7.1 General .52

iii
7.2 Background, objectives, and scope .52
7.3 Operational policies and constraints .52
7.3.1 Policies .52
7.3.2 Constraints .52
7.4 Description of the proposed system .52
7.4.1 Overview .52
7.4.2 Terminators . 54
7.4.3 Processes . 54
7.4.4 Data flows . 56
7.5 Modes of operation .57
7.5.1 General .57
7.5.2 Normal mode .57
7.5.3 Degraded mode . 58
7.5.4 Fallback mode . 58
7.6 User classes and other involved personnel . 58
7.7 Support environment . . . 58
7.7.1 General . 58
7.7.2 Rule discovery service . 58
7.7.3 Service registration and discovery service .59
7.7.4 Security service .59
7.7.5 Technology services .59
7.7.6 METR certification .59
7.7.7 Maintenance .59
7.7.8 Enforcement .59
7.7.9 Academic research and advocacy.59
8 Summary of impacts .60
8.1 Operational impacts . 60
8.2 Organizational impacts. 60
8.3 Impacts during development . 60
9 Analysis of the proposed system . 61
9.1 Benefits .61
9.2 Disadvantages and limitations .61
9.3 Alternatives considered .61
Annex A (informative) Operational scenarios .62
Annex B (informative) Data flow diagram conventions . 76
Annex C (informative) Tentative categories for METR information.77
Bibliography .80

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO’s adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 278,
Intelligent transport systems, in accordance with the Agreement on technical cooperation between ISO and
CEN (Vienna Agreement).
A list of all parts in the ISO 24315 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
0.1  System overview
0.1.1  General
The ISO 24315 series is intended to provide users access to geo-specific, trustworthy, timely, authoritative,
machine-interpretable, traffic and transport related rules enacted by jurisdictional entities, including those
who define rules for campuses (i.e. private grounds). This is conceptually shown in Figure 1.
Figure 1 — METR concept
0.1.2  Purpose
Management of electronic traffic regulations (METR) is designed to assist developers and manufacturers of
driving automation systems (i.e. automation levels 1-5) and driver information systems (including those at
automation level 0) to electronically obtain traffic rules to better enable:
a) interacting safely with other road users;
b) following instructions from law enforcement organizations, and those authorized to direct traffic;
c) maintaining smooth and safe flow of traffic;
d) complying with other rules enacted to support legislative policies (such as environmental protection,
noise, manage height and weight restrictions, and societal aspects such as market days, fiestas,
[8]
pedestrian zones) .
METR is designed to provide a reference framework for the trustworthy distribution of electronic versions
of legal traffic rules, however content and application of the traffic rules is outside of the scope of the METR
standards and specifications.
0.1.3  Flow of information
The general flow of METR information is illustrated in Figure 2 and subsequently described.

vi
Key
a
METR starts with rule makers defining and enacting rules that are relevant to transport users.
b
Each legal rule is translated into a METR rule, which is a secure, standardized electronic representation that includes
a digital signature of the rule signing organization.
c
METR rules are collected for a geographic area(s) and specific scope(s).
d
Rules are distributed to METR users based on their needs.
e
METR users become aware of the METR rules, verify their authenticity, and respond appropriately.
f
As needed, METR users can submit discrepancy reports to a discrepancy handler for investigation and correction.
Figure 2 — METR flow of information

0.1.4  Graphical overview
Figure 3 provides an overview of the data and devices included within the scope of the METR environment.

vii
Key
A freight rules
B kerbside usage rules
C ride sharing rules
D micromobility rules
E VRU rules
F public transport rules
G rules for automated driving systems
H driving rules
I lane use rules
J public-area mobile robot rules
K road work rules
L pre-announced rules with subset of emergent rules and/or supporting data
M emergent rules and/or supporting data
1 various communications and network infrastructure
2 roadside communication unit
3 METR user system
Figure 3 — METR streetscape
0.1.5  Rule distribution
Electronic traffic rules and their distribution have three orthogonal characteristics that are often confused
with one another.
a) Electronic rules can be pre-announced (i.e. known and publicized well in advance of the user’s need)
or emergent (i.e. publicized and needed while previously obtained pre-announced rules are still
considered fresh).
b) Electronic rules can be distributed through a wide-area distribution mechanism or a local distribution
mechanism.
viii
c) Electronic rules can be pulled by users well in advance of their need or pushed to users as special
conditions necessitate.
It is expected that the characteristics of METR users and the limitations on data capacities for local
distribution mechanisms mean that virtually all persistent rules will be pre-announced and distributed
from a wide-area distribution source, likely using a pull mechanism. However, any emergent rule that is
activated while previously distributed pre-announced rules are still considered fresh will require a push
mechanism, often from a local distribution source. It is important to note that those two combinations are
only typical use cases and that METR supports every possible combination of these three characteristics
and addresses how discrepancies can be reported and resolved.
In addition, supporting data may provide context to the rules and can be transmitted by wide-area
communication systems, roadside units, other vehicles, or on-board devices.
The rules cover virtually any rule related to surface transport systems; the graphic depicts rules for freight
vehicles, kerbside usage, ride sharing, micromobility operations, vulnerable road users (VRUs), public
transport usage, driving (i.e. human-in-the-loop, including driver support systems, which represent levels
1 and 2 of automation), automated driving systems (ADS, i.e. automation levels 3-5), lane usage, public-area
mobile robots (PMRs), and road works. This information needs to be available and conveyed to all transport
users including nomadic devices, PMRs, and vehicles equipped with driving automation systems (i.e. levels
1-5 of automation). Although not shown in the diagram, METR is also intended to be flexible enough to
support rules relating to the use of ferries, passenger rail (e.g. trams, subways, and inter-city rail), and off-
road environments.
0.2  Framework adaptation
METR is defined through the ISO 24315 series, which provides a comprehensive framework for the
interoperable digitalization, distribution, and management of electronic traffic regulations. This framework
will be defined at a relatively high-level and will support both regional adaptation and customization, as
well as the use of non-METR protocols and data formats, as depicted in Figure 4.
Figure 4 — METR three-tier framework

ix
ISO standards are developed to address international stakeholder needs. Other international organizations
(e.g. UNECE) also play a role in standards development and implementation policies. The first set of ISO
documents of the ISO 24315 series provide a framework based on the ISO-specified systems engineering
methodology, as defined by ISO/IEC/IEEE 29148, and consist of a vocabulary, a concept of operations, a
reference architecture, and requirements for the METR system of systems (SoS). Subsequent documents
in the ISO 24315 series will define requirements for each component system within the METR SoS and
other requirements common to all component systems. The ISO 24315 series will promote semantic
interoperability, but it will need to be interpreted and adapted for regional use to provide complete
interoperability (i.e. including syntactic interoperability).
Each region (e.g. EU, Japan, Korea) customizes (e.g. extends, adapts) the ISO 24315 series based on their
specific needs and environment, as necessary to provide cross-border interoperability within their region.
The METR reference architecture is refined to provide regional implementation guidance. For example, in
Europe, METR can eventually become part of the National Access point (NAP). Furthermore, non-METR data
[7] [6] [2] [5] [9] [10]
formats including TN-ITS, DATEX-II, TPEG2, TransModel, TMDD, and WZDx can be refined to
support METR requirements or used as-is to deliver METR information to the extent that the data can be
supported (i.e. non-METR distribution). The preferred solution is to update these formats to conform to the
full set of METR trustworthiness requirements.
Translating and adapting international standards and regional interoperability agreements is achieved at
the national level and can even be done at local levels. Operations, funding and governance are determined
nationally, locally, or both. Legal implications of electronic rules provided through METR must be
defined nationally or locally. Many locations are starting this digitalization of the rules at an informative
supplemental level, rather than regulatory.
0.3  Document overview
The purpose of this document is to describe the operational concept (ConOps) for METR. A ConOps is a user-
oriented document that describes system characteristics for a proposed system from the users’ viewpoint.
It includes a description of the key stakeholders along with the processes and data flows required to fulfil
their responsibilities. It describes what the system will do (not how it will do it) and why (rationale). The
ConOps is used to communicate overall quantitative and qualitative system characteristics to the acquirer,
user, supplier, and other organizational elements (ISO/IEC/IEEE 29148). The ConOps is a critical tool in
building consensus among stakeholders.
This document is designed to assist the following stakeholders in understanding and validating the
proposed system:
a) transport users (e.g. vehicle users, micromobility users, and vulnerable road users);
b) transport infrastructure operators (e.g. traffic engineers, traffic managers and controllers, toll road
operators, parking facility operators);
c) maintenance and construction personnel (e.g. road crews, maintenance managers);
d) transport service operators (e.g. public transport agencies, delivery companies, ridesourcing
companies);
e) transport entity owners (e.g. municipalities, campus owners, fleet managers);
f) policy and rule-making entities (including elected officials, responsible legal authorities, and their staff);
g) enforcement personnel (e.g. law enforcement, lawyers, insurance companies);
h) manufacturers and developers (e.g. motor vehicle manufacturers, AMR manufacturers, driving
automation system developers);
i) technology specialists (e.g. ADS-equipped vehicle experts, location perception experts, video image
processing experts);
j) information support entities (e.g. map providers, navigation providers, traveller information providers); and

x
k) advocates (e.g. safety advocates, environmental advocates, disability rights advocates).
In addition, this document will assist stakeholders in verifying that the requirements, which will be
documented in subsequent parts of this document series, meet defined user needs.
This document has been developed by ISO/TC 204 in coordination with many experts from countries around
the world. It is designed to be sufficiently generic to be used as an international standard applicable to any
national or regional authority that wishes to adopt its processes.
System developers and system operators within authorities that adopt the METR model are advised to
become familiar with this document and use it as their guide in operations.

xi
Technical Report ISO/TR 24315-2:2025(en)
Intelligent transport systems — Management of electronic
traffic regulations (METR) —
Part 2:
Operational concepts (ConOps)
1 Scope
The management of electronic transport regulations (METR) provides trustworthy, authoritative, machine-
interpretable, transport-related rules for using the road network.
This document describes the operational concept (ConOps) for METR in a format that is consistent with
ISO/IEC/IEEE 29148.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/TS 14812, Intelligent transport systems — Vocabulary
ISO/TS 24315-1, Intelligent transport systems — Management of electronic traffic regulations (METR) —
Part 1: Vocabulary
ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 24765, ISO/TS 14812,
and ISO/TS 24315-1 apply.
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/
4 Symbols and abbreviated terms
3G third-generation technology standard for broadband cellular
3GPP 3rd generation partnership project
4G fourth-generation technology standard for broadband cellular
5G fifth-generation technology standard for broadband cellular
ADS automated driving system
C-ITS cooperative intelligent transport systems

CCMS cooperative ITS credentials management system
CV RSU connected vehicle roadside unit
DDT dynamic driving task
DSRC dedicated short-range communications
FM frequency modulation
GNSS global navigation satellite system
HMI human-machine interface
ITS intelligent transport systems
LTE-V2X long-term evolution vehicle-to-everything
METR management of electronic traffic regulations
MUTCD manual on uniform traffic control devices
OBE on-board equipment
ODD operational design domain
OEM original equipment manufacturer
PMR public-area mobile robot
TCD traffic control device
TMDD traffic management data dictionary
TN-ITS transport network - intelligent transport systems
TPEG transport protocol experts group
UNECE United Nations Economic Commission for Europe
USDOT United States Department of Transportation
UTC universal coordinated time
Wi-Fi wireless network protocols
WP working party
5 Current system or situation
5.1 General
This clause describes the current situation that motivates the development of METR and provides readers
with an introduction to the problems that have led to the development of this document.
The “current system” described in this document is intended to represent the typical approach used to
distribute rules using traditional means (e.g. prior to electronic distribution), which is primarily through:
a) signage;
b) markings (e.g. pavement markings);

c) published information (e.g. local laws, driver manuals).
The description of the current system is not intended to reflect every approach used to distribute rules in
existence today.
5.2 Background, objectives and scope
5.2.1 Background
Even before Karl Friedrich Benz produced his first automobile in 1885, jurisdictional entities posted
transport-related rules, such as Figure 5.
[11]
Figure 5 — Fitche’s bridge warning sign, UK
The sign reads: “Notice ‒ To owners and drivers of traction engines. The bridge is insufficient to carry
weights beyond the ordinary traffic of the district.”
In fact, the world’s first traffic signal was installed in December 1868 outside the Houses of Parliament in
London. As travel speeds increased, the need for signage, pavement markings, and other rules increased
as well. By 1915 the City of Detroit started posting stop signs and by the early 1920s regional movements
began to standardize the types of signs and markings installed. Today, the signs and markings have largely
been standardized within each region of the world, with significant coordination among the regions (e.g.
most international symbols are consistent even when the shape of a warning sign is different.)
As technology continues to evolve, vehicles are becoming more intelligent and connected. With this evolution,
there is a need to provide machine-interpretable rules to information and automation systems, especially
driving automation systems, so that they can better comply with rules and ensure safe operations. There is
also a need to support the array of vehicles and users that are emerging, such as PMRs.
5.2.2 Objectives
Rules for the use of road transport are implemented for a variety of societal reasons including:
a) safety (e.g. requirements for taillights, speed limits, intersection controls, warnings);
b) efficiency (e.g. traffic signal logic, high occupancy vehicle lane restrictions, hard shoulder running rules);

c) comfort (e.g. guidance information, including information about amenities);
d) mobility (e.g. parking restricted to travellers with disabilities);
e) sustainability (e.g. requirements for the use of catalytic converters, congestion charge zones).
The objective of METR is to provide travellers and their systems with trustworthy information, which will
assist society in fulfilling these goals.
5.2.3 Scope of application
Within the current situation, most established rules relate to the use of motor vehicles, largely because of
the safety implications involved. However, there are rules that relate to other modes, such as:
a) limitation on road use for pedestrians and cyclists;
b) prohibition of certain forms of micromobility on some facilities (e.g. “no skateboarding”);
c) pedestrian signals at intersections;
d) guidance to pedestrians on which direction to look when crossing the road;
e) sidewalk closures for construction activities; and
f) rules for the operation of PMRs.
The scope of rules considered in the design of METR includes all transport-related rules for using any portion
of a road network. This includes any pathway network designed for pedestrians, micromobility vehicles,
PMRs, motor vehicles, etc.
The METR design can also be applicable for other environments, even if they were not considered in the
above list.
NOTE The intent is that this document can support the distribution of the full breadth of rules; whether the full
breadth of rules are entered into a specific implementation will be determined by those implementing the system.
5.3 Operational policies and constraints
5.3.1 Policies
The typical current system is assumed to follow the following operational policies.
a) The set of rules that govern behaviour vary by location.
b) The set of rules that govern behaviour at a location can vary by time.
c) The set of rules that govern behaviour can vary based on external factors that can be monitored with
supporting data (e.g. environmental conditions).
d) Rules are made publicly available prior to becoming applicable.
e) The set of rules that apply at any given location and time are an aggregation of the active rules that have
been adopted by all jurisdictional entities that have jurisdiction (ISO 24315-1) over the location. For
example, a location on a campus might be subject to national and local rules in addition to any campus-
specific rules.
NOTE While the term “campus” is often used to refer to universities, the METR documentation uses a
broader meaning that includes any area excluding transport facilities managed by the local government. This
includes land owned by public and private universities, airports, hospitals, harbours, and any landowner with the
authority to impose rules.
f) All vehicles and travellers are aware of all rules that govern their behaviour.

g) All vehicles and travellers have confidence that the rules are trustworthy.
h) Rules are conveyed in a manner that minimizes distraction from other dynamic driving tasks.
i) Jurisdictions make rules publicly available using approved traffic control devices (TCDs), to the extent
reasonable (e.g. approved sign types, marking types, signal types).
j) Jurisdictions have competing demands that affect policies regarding how they make rules publicly
available, such as:
1) available budget;
2) sustainability concerns, such as a desire to minimize visual clutter along streets;
3) access to locations (e.g. physical or legal barriers).
5.3.2 Constraints
The typical system is assumed to have the following constraints.
a) Only appointed rule makers issue rules.
b) The applicable location for each rule does not extend beyond the jurisdictional boundaries of the
jurisdictional entity that the rule maker represents.
c) Rules issued by rule makers of overlapping jurisdictions specify precedence.
d) Rules clearly identify the times and conditions when they are active.
e) Rules support multi-lingual environments.
f) Approved rules can have a delayed inception time and/or a known termination time.
g) Jurisdictions are responsible for making rules publicly available prior to their enforcement.
5.4 Description of the current situation
5.4.1 General
5.4 provides an overview of how transport rules are distributed in an environment without METR
by identifying the primary functions performed, the data flows associated with each function, and the
assignment of functions to key stakeholders. Figure 6 provides an overview of the key functions and
relationships as a data flow diagram. The diagram conforms to the rules for Yourdon-Demarco data flow
[13]
diagrams, which are summarized in Annex B. Each terminator, process, and data flow is further explained
in 5.4.2, 5.4.3, and 5.4.4. 5.4.5 and 5.4.6 provide additional details about the other stakeholders and the data
identified in 5.4.3 and 5.4.4.

Key
process (external to METR)
data flow
data store
terminator
Figure 6 — Existing roles
5.4.2 Terminators
5.4.2.1 Rule maker
A rule maker represents an entity with the authority and responsibility to establish and maintain a defined
set of legal rules for a jurisdictional entity. This includes maintaining an updated, persistent record of the
rules, addressing impacts of new legal decisions and technologies [e.g. ensuring rules are updated as needed
to properly apply to automated driving systems (ADS)], and ensuring rules are unambiguous.
To ensure that the rules are unambiguous, all key characteristics of the rule are defined (e.g. where does it
apply, when does it apply, who does it apply to), key terms are defined (e.g. “TRUCKS”), and clauses containing
numerous conditions and/or limits are precisely constructed. Further, the rules need to be conveyed to the
travelling public, often in a busy and dynamic environment. This requires the rules to be clear and concise.
Most locations fall within a jurisdictional hierarchy as shown in Figure 7. For example, a particular location
might be in a campus parking lot (e.g. “Campus χ”), which is
...