ISO/TS 24315-1:2025

Technical
Specification
ISO/TS 24315-1
First edition
Intelligent transport systems —
2025-03
Management of electronic traffic
regulations (METR) —
Part 1:
Vocabulary
Systèmes de transport intelligents — Gestion des règles de
circulation sous forme électronique —
Partie 1: Vocabulaire
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 .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Jurisdictional terms .1
3.2 Data terms .3
3.2.1 General data terms .3
3.2.2 Discrepancy state terms .5
3.2.3 Rule publication terms .6
3.2.4 Rule state terms .6
3.2.5 METR information state terms .8
3.2.6 Rule representation terms.8
3.2.7 Rule announcement terms .9
3.2.8 Rule projected longevity terms .9
3.2.9 Rule terms related to supporting data .9
3.2.10 Rule relevancy terms .10
3.2.11 Distribution terms .10
3.3 METR architectural terms .11
3.3.1 METR role terms . . .11
3.3.2 METR system terms .16
3.3.3 METR services .17
3.3.4 METR user terms .18
3.4 Transport terms .18
3.5 Trustworthiness terms .19
Bibliography .21
Index .22

iii
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 document 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.

iv
Introduction
0.1  System overview
The ISO 24315 series on the management of electronic traffic regulations (METR) is intended to provide
users access to geo-specific, trustworthy, timely, authoritative and machine-interpretable rules relating to
traffic and transport, 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.2  Purpose
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 them to:
a) interact safely with other road users;
b) follow instructions from law enforcement organizations and those authorized to direct traffic;
c) maintain smooth and safe flow of traffic; and
d) comply with other rules enacted to support legislative policies (such as environmental protection, noise,
height and weight restrictions, and societal aspects such as market days, fiestas, pedestrian zones,
[1]
etc.).
METR is designed to provide a reference framework for the trustworthy distribution of electronic versions
of legal traffic rules. The content and application of these traffic rules is outside of the scope of standards
and specifications on METR.
0.3  Flow of information
The general flow of METR information is illustrated in Figure 2 and is described below the figure.

v
Figure 2 — METR flow of information
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.
0.4  Graphical overview
Figure 3 provides an overview of the data and devices included within the scope of the METR environment.

vi
Key
A freight rules
B kerbside usage rules
C ride sharing rules
D micromobility rules
E vulnerable road user (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
various communications and networks infrastructure
roadside communication unit
METR user system
Figure 3 — METR streetscape
0.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).
vii
b) Electronic rules can be distributed through a wide-area distribution mechanism or a local distribution
mechanism.
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 will lead to virtually all persistent rules being 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.
These two combinations are typical use cases only. METR supports every possible combination of
characteristics a) – c) and addresses how discrepancies can be reported and resolved.
In addition, supporting data can 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; Figure 3 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 – 2 of automation), automated driving systems (ADS, i.e. Levels 3 – 5 of automation), 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 Figure 3, 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.6  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. Within the
ISO 24315 series, this framework will be defined at a relatively high level and will support both regional
adaptation and customization, as well as the use of legacy protocols and data formats, as depicted in Figure 4.
Figure 4 — METR three-tier framework

viii
a) International Standards: ISO documents are developed to address global stakeholder needs. Other
international organizations (e.g. UNECE) also play a role in standards development and implementation
policies. The first edition of the ISO 24315 series provides a framework based on the ISO-specified
systems engineering methodology, as defined by ISO/IEC/IEEE 29148. It consists of a Vocabulary (this
document), 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 will need to be interpreted and adapted for
regional use to provide complete interoperability (i.e. including syntactic interoperability).
b) Regional interoperability: Each region (e.g. EU, Japan, Republic of Korea) may extend and adapt the
ISO 24315 series based on their specific needs and environment to provide cross-border interoperability
within their region. The METR reference architecture is refined to provide regional implementation
guidance. For example, in the EU, METR can eventually become part of the National Access point (NAP).
[3] [4] [5] [6] [7]
Furthermore, legacy data formats including TN-ITS, DATEX II, TPEG2, TransModel, TMDD,
[8]
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 (i.e. the whole
ISO 24315 series).
c) National and local policies: Translating and adapting International Standards and regional
interoperability agreements is achieved at the national level and can even be handled at local levels.
Operations, funding and governance are determined nationally, locally, or both. Legal implications of
electronic rules provided through METR are defined nationally or locally. Many locations are starting
this digitalization of the rules at an informative supplemental level, rather than at a regulatory level.
0.7  Document overview
The purpose of this document is to define METR-specific terms used throughout the ISO 24315 series. This
document has been prepared according to the rules set forth in ISO 704.
This document has been developed by ISO/TC 204, Intelligent transport systems, in coordination with many
experts from countries around the world. It is designed to be sufficiently generic to be 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 guidance in their operations.
For additional terms relevant to the ITS domain, which can help in the understanding of this document, see
ISO/TS 14812 and ISO/IEC/IEEE 24765.

ix
Technical Specification ISO/TS 24315-1:2025(en)
Intelligent transport systems — Management of electronic
traffic regulations (METR) —
Part 1:
Vocabulary
1 Scope
The management of electronic transport regulations (METR) provides a means for METR users to obtain
trustworthy, authoritative, machine-interpretable, publicly available and transport-related information
for the use of the road network, in order to provide safer and more efficient, sustainable, comfortable, and
equitable transport services.
The scope of METR includes both rules that are relatively static (e.g. static speed limits) as well as those that
are dynamic (e.g. variable speed limits, signalized intersections). Where appropriate, METR incorporates
existing documents (e.g. ISO/TS 19091 for signalized intersections).
This document defines terms specific to the ISO 24315 series on the management of electronic transport
regulations.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
ISO and IEC maintain terminological 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/
3.1 Jurisdictional terms
3.1.1
campus
private campus
private grounds
jurisdictional area (3.1.5) with a jurisdictional entity (3.1.7) who is the owner of the area but excluding
transport facilities (3.4.4) managed by the local government
EXAMPLE 1 A point of interest (e.g. airport, university, business park, industrial area, shopping centre) that
manages its own transport infrastructure (3.4.5) separately from that managed by the local government. In this case,
the point of interest and its own transport system are a part of the campus.
EXAMPLE 2 A point of interest (e.g. airport, university, business park, industrial area, shopping centre) that
includes transport infrastructure that is managed by the local government. In this case, the government-managed
transport infrastructure is a governmental area (3.1.3) while the campus is represented by the remainder of the area.
Note 1 to entry: The term "private grounds" is used in some countries; however, since campuses can be owned by
governmental entities (especially airports, military bases, public universities, etc.), the term "campus" is preferred.

3.1.2
defined area
jurisdictional area (3.1.5) or sub-area (3.1.9)
3.1.3
governmental area
transport-related, jurisdictional area (3.1.5) whose only jurisdictional entities (3.1.7) are governmental
entities
EXAMPLE A subway station owned by a governmental entity is a governmental area.
Note 1 to entry: The boundaries of a jurisdictional area can include or exclude geofenced areas to indicate which
jurisdictional entities have authority over transport facilities (3.4.4) as necessary.
3.1.4
jurisdiction
legal power to issue rules (3.2.1.13) of behaviour for a defined area (3.1.2)
Note 1 to entry: An entity of a jurisdiction that has competency over a particular subject matter is called a "responsible
legal authority".
3.1.5
jurisdictional area
territory for which a jurisdictional entity (3.1.7) has the power to define rules (3.2.1.13) of behaviour
Note 1 to entry: A jurisdictional area can include non-contiguous locations.
3.1.6
jurisdictional boundary
territorial limit associated with a jurisdictional area (3.1.5)
Note 1 to entry: A geofence can be used to electronically represent a jurisdictional boundary.
3.1.7
jurisdictional entity
jurisdictional authority
person or organization who has jurisdiction (3.1.4)
EXAMPLE A city government.
Note 1 to entry: In the case of a geopolitical jurisdiction, the jurisdictional entity is typically the recognized government
for the territory; in the case of a campus (3.1.1), the jurisdictional entity is typically the landowner.
Note 2 to entry: A jurisdictional entity assigns its authority to one or more rule makers (3.3.1.23), which may be itself
(e.g., the individual owner or a campus) or other divisions of the entity (e.g., police department, traffic department).
Note 3 to entry: For a definition of the term "person", see ISO/TS 14812:2022, 3.1.1.6.
3.1.8
region
territory within which METR users (3.3.1.16) expect to operate relatively seamlessly
EXAMPLE European Common Market, North American Free Trade Area, Japan.
Note 1 to entry: Regions are typically bounded by physical, political or other boundaries that limit the flow of traffic.
3.1.9
sub-area
defined area (3.1.2) entirely within a jurisdictional area (3.1.5)
Note 1 to entry: Sub-areas can be defined as their own distinct jurisdictional areas or as areas that have a consistent
level of support for METR data throughout.

3.2 Data terms
3.2.1 General data terms
3.2.1.1
advisory
rule (3.2.1.13) that provides a safety recommendation as established by a regulator (3.3.1.21)
Note 1 to entry: While not having the full force of law, violating an advisory can have legal implications, especially in
the case of vehicular collisions.
3.2.1.2
crowd-sourced data
supporting data (3.2.1.17) from multiple external sources that are not signed by any jurisdictional entity
(3.1.7) associated with the current location
EXAMPLE 1 Ice detected by multiple sources that are not signed by the local jurisdictional entity (3.1.7).
EXAMPLE 2 Data reported from sensors near the roadside but not signed by the local jurisdictional entity (3.1.7).
Note 1 to entry: Crowd-sourced data can include any combination of infrastructure-sourced (3.2.1.7) and peer-sourced
(3.2.1.11) data.
3.2.1.3
data category
class of data that is described by a set of specified characteristics
EXAMPLE Speed limit rules (3.2.1.13) for motor vehicles within a specified jurisdictional area (3.1.5).
Note 1 to entry: A data category is described by a set of characteristics. The term "rule set" (3.2.1.15) is used to describe
the rules that are currently contained in the data category.
Note 2 to entry: For a definition of the term "data", see ISO/IEC/IEEE 24765:2017, 3.985.
3.2.1.4
discrepancy
detected inconsistency in METR information (3.2.1.10)
3.2.1.5
guidance
rule (3.2.1.13) that provides valuable information as established by a regulator
Note 1 to entry: Regulators sometimes wish to provide additional information to travellers to ensure efficient
operations. For example, a regulator can adopt a detour and provide information about the detour route to travellers.
3.2.1.6
highway code
vehicle code
set of legislation that defines general transport-related rules (3.2.1.13) and assigns specific authorities to
rule makers (3.3.1.23) and enforcers (3.3.1.12)
Note 1 to entry: The highway code includes rules for vehicle operation [e.g. rules of the road (3.2.1.16)], driver licencing,
vehicle registration, vehicle inspection, insurance, etc. as well as establishing the legal basis for other rule makers to
issue regulations (3.2.1.12), advisories (3.2.1.1), warnings and guidance (3.2.1.5).
Note 2 to entry: The term used for the highway code varies by jurisdictional area (3.1.5) but is frequently "highway
code" or "vehicle code".
3.2.1.7
infrastructure-sourced data
supporting data (3.2.1.17) from an external source that has a fixed or portable location, including Internet servers
EXAMPLE 1 Current speed limit for a variable speed limit system as transmitted by a central or roadside system.

EXAMPLE 2 Time of dusk as reported by a source from the Internet.
EXAMPLE 3 Data reported from roadside sensors (authorized or not).
Note 1 to entry: Infrastructure-sourced data can be jurisdiction-sourced (3.2.1.8) or crowd-sourced (3.2.1.2).
3.2.1.8
jurisdiction-sourced data
supporting data (3.2.1.17) that is from an external source and is signed by a jurisdictional entity (3.1.7)
associated with the current location
EXAMPLE 1 Current speed limit for a variable speed limit system.
EXAMPLE 2 Notice from an emergency vehicle that it is responding to a call.
EXAMPLE 3 Data reported from authorized roadside sensors.
Note 1 to entry: Jurisdiction-sourced data can be infrastructure-sourced (3.2.1.7) or peer-sourced (3.2.1.11).
3.2.1.9
jurisdictional vocabulary
listing of key terms used within rules (3.2.1.13) issued by a jurisdictional entity (3.1.7) along with their
associated definitions
3.2.1.10
METR information
any information provided by a METR distribution system (3.3.2.7) to a METR consumer system (3.3.2.5)
3.2.1.11
peer-sourced data
supporting data (3.2.1.17) from an external source that is designed to operate when mobile
EXAMPLE 1 Notice from an emergency vehicle that it is responding to a call.
EXAMPLE 2 Ice detected by another vehicle.
Note 1 to entry: Peer-sourced data can be crowd-sourced (3.2.1.2) or jurisdiction-sourced (3.2.1.8).
3.2.1.12
regulation
rule (3.2.1.13) having the force of law that is established by a regulator (3.3.1.21)
3.2.1.13
rule
information regarding allowed or recommended behaviour as established by a rule maker (3.3.1.23) for its
jurisdictional area (3.1.5)
Note 1 to entry: The jurisdictional area can be a campus (3.1.1).
Note 2 to entry: The primary focus of METR (3.3.2.3) is to provide rules that relate to transport users.
Note 3 to entry: Rules include rules of the road (3.2.1.16), regulations (3.2.1.12), advisories (3.2.1.1) and guidance
(3.2.1.5).
3.2.1.14
rule order
traffic regulation order
legally recognized document that officially specifies one or more rules (3.2.1.13)
Note 1 to entry: A rule order can be associated with meta-data that activates or de-activates all rules defined within
the order. For example, a rule maker (3.3.1.23) can define an order containing multiple rules that can be made active
(3.2.4.1) or inactive (3.2.4.4) as a single unit.

3.2.1.15
rule set
aggregation of rules (3.2.1.13) coupled with shared meta-data
Note 1 to entry: Meta-data can identify the freshness period (3.2.5.2), a unique identifier, and other useful information.
Note 2 to entry: The term "rule set" can be applied to legal rules (3.2.6.2), electronic rules (3.2.6.1) sent from a METR
regulation system (3.3.2.9) to a METR distribution system (3.3.2.7), electronic rules distributed by a METR distribution
system, or other scenarios, each defining different sets for its own purposes.
3.2.1.16
rules of the road
component of the highway code (3.2.1.6) that specifies foundational rules (3.2.1.13) for the operation of
vehicles
3.2.1.17
supporting data
data provided by a source other than the METR system of systems (3.3.2.10) that can impact the interpretation
of a rule (3.2.1.13)
Note 1 to entry: Supporting data can be categorized into vehicle-sourced (3.2.1.19), infrastructure-sourced (3.2.1.7),
crowd-sourced (3.2.1.2) and user-sourced (3.2.1.18) data.
Note 2 to entry: Supporting data often changes more frequently than the freshness periods (3.2.5.2) defined for METR
information (3.2.1.10).
Note 3 to entry: Supporting data can affect the applicability of a rule (e.g. the current time affects the applicability
of a time-based rule), can provide parameters for a rule (e.g. the current speed limit for a variable speed limit rule),
or provide additive, redundant, or inconsistent information (e.g. an on-board system can detect road signs that the
interpreter needs to consider in addition to the METR information).
Note 4 to entry: For a definition of the term "data", see ISO/IEC/IEEE 24765:2017, 3.985.
3.2.1.18
user-sourced data
supporting data (3.2.1.17) provided by the human user of the system
EXAMPLE Reporting that snow tires are installed.
3.2.1.19
vehicle-sourced data
supporting data (3.2.1.17) provided by built-in equipment
EXAMPLE 1 Current time.
EXAMPLE 2 Windshield wiper status.
3.2.2 Discrepancy state terms
3.2.2.1
confirmed discrepancy
discrepancy (3.2.1.4) that has been investigated with the result that a change in METR information (3.2.1.10)
and/or traffic control device(s) (3.4.1) were deemed to be warranted
3.2.2.2
detected discrepancy
discrepancy (3.2.1.4) that has been identified but not detected
Note 1 to entry: Discrepancies can be detected by users or by any of the component systems of METR (3.3.2.3).

3.2.2.3
rejected discrepancy
discrepancy (3.2.1.4) that has been investigated but with the result that no change was deemed to be
warranted
Note 1 to entry: A discrepancy report (3.3.1.9) can be erroneously caused by a temporary vehicle obstruction of a
conventional traffic control device (3.4.1).
3.2.2.4
reported discrepancy
detected discrepancy (3.2.2.2) that has been transmitted to a discrepancy handler (3.3.1.8)
3.2.2.5
resolved discrepancy
confirmed discrepancy (3.2.2.1) that has been fully corrected
3.2.2.6
suspected discrepancy
discrepancy (3.2.1.4) that has been reported to a METR regulation system (3.3.2.9) for investigation
3.2.3 Rule publication terms
3.2.3.1
observable rule
rule (3.2.1.13) that is posted (3.2.3.2) and able to be perceived by those affected
3.2.3.2
posted rule
rule (3.2.1.13) that is publicized (3.2.3.4) to those affected using conventional traffic control devices (3.4.1)
3.2.3.3
public record
information that travellers are expected to know without posted rules (3.2.3.2)
3.2.3.4
publicized rule
rule (3.2.1.13) that is announced to the public
3.2.3.5
unobservable rule
rule (3.2.1.13) that is posted (3.2.3.2) but not able to be perceived by a significant portion of those affected
Note 1 to entry: An unobservable rule can potentially not be perceived properly for a number of reasons, for example
damage, fading, snow accumulation, obstructions, graffiti or removal.
3.2.3.6
unposted rule
rule (3.2.1.13) that is publicized (3.2.3.4) to those affected primarily through means other than
conventional traffic control devices (3.4.1)
Note 1 to entry: Unposted rules are documented within the public record (3.2.3.3).
3.2.4 Rule state terms
3.2.4.1
active rule
rule (3.2.1.13) that is implemented (3.2.4.3) and presently in effect
Note 1 to entry: A rule can be active during certain hours of the day or upon other defined conditions.
Note 2 to entry: Rules are only enforced when active.

3.2.4.2
approved rule
rule (3.2.1.13) that has been approved by a rule maker (3.3.1.23) with a future inception time (3.2.4.5)
3.2.4.3
implemented rule
rule (3.2.1.13) that has an inception time (3.2.4.5) in the past and a termination time (3.2.4.10) either
undefined or in the future
Note 1 to entry: An implemented rule can be active (3.2.4.1), inactive (3.2.4.4) or overridden (3.2.4.6).
Note 2 to entry: Responsible legal authorities can define transition periods [e.g. as required for the installation of
conventional traffic control devices (3.4.1)] when rules are implemented or rescinded (3.2.4.8) and the enforceability of
the rules during these transition periods.
3.2.4.4
inactive rule
rule (3.2.1.13) that is enacted (3.2.4.3) but not presently in effect
Note 1 to entry: A rule can be not in effect during certain hours of the day.
Note 2 to entry: A rule cannot be enforced while it is inactive.
Note 3 to entry: Guidance (3.2.1.5) information that is not applicable at certain times (e.g. detour that is in effect during
certain hours) can be designated as "inactive" during those times.
3.2.4.5
inception time
point in time at which a rule (3.2.1.13) can first become applicable whenever all defined conditions are met
Note 1 to entry: After the inception time, the rule becomes implemented and may be active (3.2.4.1), inactive (3.2.4.4)
or overridden (3.2.4.6).
Note 2 to entry: Rules can be associated with grace periods that occur after the inception time.
3.2.4.6
overridden rule
rule (3.2.1.13) that is enacted (3.2.4.3) but temporarily nullified or replaced
Note 1 to entry: It is expected that an override will eventually terminate, even if the expected termination time
(3.2.4.10) is unknown.
Note 2 to entry: The item that is temporarily nullified is termed to be “overridden” and the item that it is replaced with
is termed to be “overriding”.
Note 3 to entry: The replacement can be null.
3.2.4.7
proposed rule
rule (3.2.1.13) that is not yet approved by the rule maker (3.3.1.23)
3.2.4.8
rescinded rule
rule (3.2.1.13) that has a termination time (3.2.4.10) in the past
3.2.4.9
revoked rule
rule (3.2.1.13) that has been retroactively designated as never being legally enforceable
EXAMPLE An electronic no parking rule can be revoked if it is discovered that the electronic version incorrectly
identified the applicable times to be 03:00 to 20:00 when the actual rule identifies the applicable times to be 08:00 to 20:00.
Note 1 to entry: A rule that is revoked indicates that the rule ought never to have been enacted.

Note 2 to entry: There can be a period of time after a rule is revoked during which associated conventional traffic
control devices (3.4.1) are still present.
3.2.4.10
termination time
point in time at which a rule (3.2.1.13) became or is expected to become unenforceable
EXAMPLE A temporary daily parking restriction that is intended to be in effect daily from 07:00 to 19:00 and
ending 31 July would require a termination time of no earlier than 19:00 on 31 July.
3.2.5 METR information state terms
3.2.5.1
fresh METR information
METR information (3.2.1.10) that has a freshness period (3.2.5.2) that has not expired
EXAMPLE A rule set (3.2.1.15) that is downloaded can be designated as being fresh for one week. The data would
be considered outdated (3.2.5.3) after the one-week period.
Note 1 to entry: Emergent rules (3.2.7.1) can impact how fresh rules (3.2.1.13) are interpreted, including overriding them.
3.2.5.2
freshness period
duration during which an element of METR information (3.2.1.10) is considered accurate
Note 1 to entry: Receivers (3.3.1.20) can refresh their data prior to their expiration to avoid outdated METR information
(3.2.5.3).
3.2.5.3
outdated METR information
METR information (3.2.1.10) that has a freshness period (3.2.5.2) that has expired
3.2.6 Rule representation terms
3.2.6.1
electronic rule
representation of a rule (3.2.1.13) in a structured, digital format that can be readily processed by a computer
to determine the intent of the rule
3.2.6.2
legal rule
representation of a rule (3.2.1.13) as recorded in official records of the jurisdictional entity (3.1.7)
3.2.6.3
METR rule
electronic rule (3.2.6.1) that is produced and distributed in a trustworthy manner
Note 1 to entry: Digitized images do not meet this definition of electronic.
3.2.6.4
physical rule
representation of a rule (3.2.1.13) as presented in the field
EXAMPLE The speed limit as displayed on a speed limit sign.

3.2.7 Rule announcement terms
3.2.7.1
emergent rule
METR rule (3.2.6.3) created and implemented while previously distributed, pre-announced rule sets
(3.2.1.15) are still fresh (3.2.5.1)
EXAMPLE Immediately after downloading the current pre-announced rule set, the jurisdictional entity (3.1.7)
issues a new METR rule (3.2.6.3) that closes a lane on a road due to a vehicular collision.
Note 1 to entry: Emergent rules typically require alternate distribution mechanisms to ensure that METR users
(3.3.1.16) are notified in time to allow for operational decisions.
Note 2 to entry: Emergent rules can include both temporary (3.2.8.2) and persistent (3.2.8.1) rules (3.2.1.13).
3.2.7.2
pre-announced rule
METR rule (3.2.6.3) distributed through the normal periodic update mechanism
Note 1 to entry: Pre-announced rules do not require low-latency communications because they are distributed well
enough in advance so that all users with up-to-date rule sets (3.2.1.15) will have a copy of the rule (3.2.1.13).
Note 2 to entry: Pre-announced rules typically have relatively long freshness periods (3.2.5.2) but can be impacted by
emergent rules (3.2.7.1).
3.2.8 Rule projected longevity terms
3.2.8.1
persistent rule
rule (3.2.1.13) that does not have any expectation of a termination time (3.2.4.10)
Note 1 to entry: A variable rule (3.2.9.3), such as a variable speed limit, often consists of a persistent rule (e.g. a variable
speed limit applies to a specified stretch of a road) that is supplemented with supporting data (3.2.1.17) that identifies
the current speed limit in effect.
3.2.8.2
temporary rule
rule (3.2.1.13) that has or is expected to have a specified termination time (3.2.4.10)
3.2.9 Rule terms related to supporting data
3.2.9.1
condition-based rule
rule (3.2.1.13) that becomes active (3.2.4.1) based on explicitly stated conditions
EXAMPLE 1 “When workers present”.
EXAMPLE 2 “Dusk”.
EXAMPLE 3 "08:00 – 12:00".
Note 1 to entry: Condition-based rules can be based on multiple conditions.
Note 2 to entry: Time-based rules (3.2.9.2) (e.g. a parking rule that is only in effect during certain hours) are one type
of condition-based rules.
3.2.9.2
time-based rule
condition-based rule (3.2.9.1) where at least one condition is dependent on time
EXAMPLE 1 "08:00-12:00".
EXAMPLE 2 "Every Tuesday".
EXAMPLE 3 "June through July".
3.2.9.3
variable rule
rule (3.2.1.13) that contains a parameter whose value is dependent upon supporting data (3.2.1.17) issued by
a rule maker (3.3.1.23)
EXAMPLE 1 A speed limit that changes based on responsible legal authority decisions
EXAMPLE 2 A traffic signal, which changes states as determined by a traffic signal controller
Note 1 to entry: The supporting data can be generated by an automated system under the authority of the responsible
legal authority.
3.2.10 Rule relevancy terms
3.2.10.1
non-relevant rule
rule (3.2.1.13) that is not applicable to the METR user (3.3.1.16) within present circumstances
3.2.10.2
relevant rule
rule (3.2.1.13) applicable to the METR user (3.3.1.16) within present circumstances
3.2.11 Distribution terms
3.2.11.1
cyber location
set of one or more parameters that allow an electronic resource to be accessed in a secure manner through
indicated communication mechanisms
EXAMPLE 1 A universal resource locator (URL) with a public key.
EXAMPLE 2 A radio frequency and protocol details used for broadcasting information and authentication
credentials.
3.2.11.2
dissemination plan
plan for providing data to user systems
Note 1 to entry: A dissemination plan includes identification of the data covered by the plan, the mode of delivery (e.g.
via a centralized distribution system, local beacons, RSS feed) and the geographic area for dissemination.
3.2.11.3
localized distribution
dissemination of METR information (3.2.1.10) using wireless technologies with less than a 1-km range
EXAMPLE 1 WiFi.
EXAMPLE 2 LTE-V2X.
3.2.11.4
pulled distribution
dissemination of METR information (3.2.1.10) to a user based on a request or subscription
3.2.11.5
pushed distribution
dissemination of METR information (3.2.1.10) to a user based on general user registration or as a broadcast
to all users within range
3.2.11.6
wide-area distribution
dissemination of METR information (3.2.1.10) using wireless technologies with a range of greater than 1 km

3.3 METR architectural terms
3.3.1 METR role terms
3.3.1.1
adapter
role that is responsible for interpreting, fusing and adapting data provided by the receiver (3.3.1.20) and
supporting data providers (3.3.1.27) into a format that the METR user (3.3.1.16) can support
Note 1 to entry: Adapting data can result in another electronic format (e.g., translation among different electronic
interface standards) or to a human-machine interface format, as might be performed by a driver support system.
Note 2 to entry: The adapter can also provide discrepancies to a discrepancy reporter (3.3.1.9).
Note 3 to entry: For a definition of the term "role", see ISO/TS 14812:2022, 3.1.12.3.
Note 4 to entry: For a definition of the term "data", see ISO/IEC/IEEE 24765:2017, 3.985.
3.3.1.2
adjudicator
role that is responsible for making formal judgements on disputed matters related to rules (3.2.1.13)
Note 1 to entry: For a definition of the term "role", see ISO/TS 14812:2022, 3.1.12.3.
3.3.1.3
ancillary user
METR user (3.3.1.16) that is not a transport-related user (3.3.1.29)
EXAMPLE 1 Insurance company.
EXAMPLE 2 Lawyer.
EXAMPLE 3 Police officer.
Note 1 to entry: Ancillary users typically provide verification of the system or support transport users in their
transport needs.
3.3.1.4
authorized actor
rule implementer (3.3.1.22) that has received permission from a rule maker (3.3.1.24) to enable and disable
specific rules (3.2.1.13) as necessary
EXAMPLE A construction contractor can be granted the authority to close a specific lane of traffic at a specific
location within specified time constraints as the contractor deems necessary to ensure the safety of the public during
construction activities.
Note 1 to entry: Depending on the rule, legal environment, etc. "enabled" and "disabled" can equate to either
implemented (3.2.4.3) and rescinded (3.2.4.8) or active (3.2.4.1) and inactive (3.2.4.4).
3.3.1.5
c
...