ISO/DTS 24315-4

• Abstract:

  The management of electronic traffic regulations (METR) provides trustworthy, authoritative, machine-interpretable, transport-related rules for using the road network. This document defines the requirements for each of the component systems that make up the METR system of systems (SoS), including the METR regulation system, METR distribution system, METR consumer system, and METR discrepancy handling system

• Status: Not Published
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 19 - Mobility integration
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 26-Aug-2026
• Completion Date: 26-Aug-2026

• Consolidates: ISO/IEC 23009-1:2022 - Information technology — Dynamic adaptive streaming over HTTP (DASH) — Part 1: Media presentation description and segment formats
• Effective Date: 31-Jan-2026

Overview

ISO/DTS 24315-4:2026 is a key standard in the ISO 24315 series, focusing on the management of electronic traffic regulations (METR) within intelligent transport systems (ITS). This fourth part, developed by ISO/TC 204, details system-level requirements (SysR) for each component system that forms the METR system of systems (SoS). By defining how electronic traffic regulations are created, distributed, consumed, and maintained, this standard establishes an authoritative framework for trustworthy, machine-interpretable road rules that support next-generation road safety and automation.

The standard covers requirements for component systems, including:

• METR Regulation System (MRS) - for creating and signing digital rules
• METR Distribution System (MDS) - for distributing rules to users
• METR Consumer System (MCS) - for interpreting and using the rules
• METR Discrepancy Handling System (MDHS) - for reporting and resolving inconsistencies

With the adoption of ISO/DTS 24315-4, authorities, system developers, and manufacturers gain a robust foundation to ensure interoperability, safety, and compliance in the evolving landscape of digital transportation.

Key Topics

ISO/DTS 24315-4 addresses essential aspects required for effective management of digital road regulations, including:

• Machine-Interpretable Traffic Rules: Requirements for electronic representations of traffic regulations that are digitally signed and securely distributed.
• System of Systems Architecture: Definition of component subsystems (regulation, distribution, consumer, discrepancy handling) and their roles within the METR SoS.
• Information Flow: Detailed requirements for information exchange between subsystems, including reporting discrepancies, distributing rules, application status, and more.
• Deployment Flexibility: Guidance for global, regional, and local adaptation, supporting customization and legal implementation as per jurisdictional needs.
• Interoperability: Reference to existing ITS standards and protocols to maximize compatibility and data exchange across regions.
• Security and Trustworthiness: Secure handling, digital signatures, and authentication to ensure the integrity and authority of distributed transit regulations.
• Geo-specific Rules: Application of GIS and GNSS for accurate location-based rule enforcement.

Applications

The METR system-level requirements present practical value for a wide array of transport stakeholders:

• Automated Driving Systems: Enabling vehicles (automation Levels 1-5) to access the latest legally binding road rules and respond accordingly.
• Driver Information Systems: Supplying up-to-date rule information to driver assistance platforms (Level 0+) to enhance situational awareness and compliance.
• Connected Vehicle Ecosystems: Supporting communication between infrastructure and vehicles for smoother, safer traffic management.
• Public Agencies and Infrastructure Managers: Providing tools to digitalize and disseminate local and regional transport policies efficiently.
• Discrepancy Reporting and Resolution: Facilitating feedback from vehicles and users to ensure regulatory data aligns with roadside reality, bolstering accuracy.
• Smart Mobility and Urban Management: Integrating with policies for environment, access, construction zones, public transport, micromobility, and more.

By implementing ISO/DTS 24315-4, agencies and industry players contribute to safer, interoperable, and more intelligent transport infrastructures, streamlining digital rule adoption worldwide.

Related Standards

ISO/DTS 24315-4 aligns and interoperates with a suite of international and regional standards, promoting consistency across intelligent transport systems:

• ISO/TS 24315-1: Vocabulary for management of electronic traffic regulations.
• ISO/TS 24315-2: Operational concept for METR.
• CEN ISO/TS 24315-3: METR system of systems requirements and architecture.
• ISO/TS 14812: ITS vocabulary.
• ISO/IEC/IEEE 24765: Systems and software engineering vocabulary.
• NIST 800-53 Rev 5: Security and privacy controls for information systems.
• CEN/TS 17268, CEN/TS 16157-11 (DATEX-II), ISO 21219 (TPEG2), EN 12896 (Transmodel), TMDD, WZDx: Data exchange formats and domain standards supporting ITS and traffic management.

ISO/DTS 24315-4 serves as a foundational document for harmonizing electronic rule management in intelligent transport systems, enabling global digital mobility innovation.

FINAL DRAFT
Technical
Specification
ISO/TC 204
Intelligent transport systems —
Secretariat: ANSI
Management of electronic traffic
Voting begins on:
regulations (METR) —
2026-08-26
Part 4:
Voting terminates on:
2026-11-18
System-level requirements (SysR)
Systèmes de transport intelligents — Gestion des règles de
circulation sous forme électronique —
Partie 4: Exigences au niveau système
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 SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
Technical
Specification
ISO/TC 204
Intelligent transport systems —
Secretariat: ANSI
Management of electronic traffic
Voting begins on:
regulations (METR) —
Part 4:
Voting terminates on:
System-level requirements (SysR)
Systèmes de transport intelligents — Gestion des règles de
circulation sous forme électronique —
Partie 4: Exigences au niveau système
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 SUPPOR TING DOCUMENTATION.
© ISO 2026
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO-
ISO/CEN PARALLEL PROCESSING
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .vii
Introduction .viii
0.1 System overview .viii
0.1.1 General .viii
0.1.2 Purpose .viii
0.1.3 Flow of information .viii
0.1.4 Graphical overview . ix
0.1.5 Rule distribution .x
0.2 Framework adaptation . . xi
0.3 Document overview .xii
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 2
5 Overview . 3
5.1 General .3
5.2 Assumptions and dependencies .3
5.2.1 Customizing requirements .3
5.2.2 Internet-based communications .4
5.2.3 Vehicle communications .4
5.2.4 Geo-positioning rules .4
5.2.5 Leverage existing standards.4
5.2.6 Efficient data exchange.4
5.2.7 Additional requirements .4
5.3 Traceability conventions.4
5.4 External responsibilities .4
5.5 Presentation of requirements .4
5.6 Physical view .5
5.6.1 General .5
5.6.2 Physical view diagrams .6
6 Information flow requirements.13
6.1 Information flow: consolidated discrepancy report . 13
6.1.1 Purpose of consolidated discrepancy report . 13
6.1.2 Content of consolidated discrepancy report . 13
6.1.3 Source of consolidated discrepancy report . 13
6.1.4 Destination of consolidated discrepancy report .14
6.1.5 Security for consolidated discrepancy report .14
6.1.6 Instances of consolidated discrepancy report .14
6.2 Information flow: discrepancy report details .14
6.2.1 Purpose of discrepancy report details .14
6.2.2 Content of discrepancy report details .14
6.2.3 Source of discrepancy report details . 15
6.2.4 Destination of discrepancy report details . 15
6.2.5 Security for discrepancy report details. 15
6.3 Information flow: discrepancy suppression information . 15
6.3.1 Purpose of discrepancy suppression information . 15
6.3.2 Content of discrepancy suppression information .16
6.3.3 Source of discrepancy suppression information .16
6.3.4 Destination of discrepancy suppression information .16
6.3.5 Security for discrepancy suppression information.16
6.4 Information flow: local METR information for consumers .16
6.4.1 Purpose of local METR information for consumers .16
6.4.2 Content of local METR information for consumers .16

iii
6.4.3 Source of local METR information for consumers.17
6.4.4 Destination of local METR information for consumers .17
6.4.5 Security for local METR information for consumers .17
6.5 Information flow: METR application information .17
6.5.1 Purpose of METR application information .17
6.5.2 Content of METR application information .17
6.5.3 Source of METR application information .17
6.5.4 Destination of METR application information .17
6.5.5 Security for METR application information .18
6.6 Information flow: METR application status .18
6.6.1 Purpose of METR application status .18
6.6.2 Content of METR application status .18
6.6.3 Source of METR application status .18
6.6.4 Destination of METR application status .18
6.6.5 Security for METR application status . .18
6.7 Information flow: METR coordination .19
6.7.1 Purpose of METR coordination .19
6.7.2 Content of METR coordination .19
6.7.3 Source of METR coordination .19
6.7.4 Destination of METR coordination .19
6.7.5 Security for METR coordination .19
6.8 Information flow: METR device status . 20
6.8.1 Purpose of METR device status . 20
6.8.2 Content of METR device status . 20
6.8.3 Source of METR device status . 20
6.8.4 Destination of METR device status . 20
6.8.5 Security for METR device status . 20
6.9 Information flow: METR discrepancy report . . 20
6.9.1 Purpose of METR discrepancy report . 20
6.9.2 Content of METR discrepancy report . 20
6.9.3 Source of METR discrepancy report .21
6.9.4 Destination of METR discrepancy report .21
6.9.5 Security for METR discrepancy report .21
6.10 Information flow: METR emergent rule input .21
6.10.1 Purpose of METR emergent rule input .21
6.10.2 Content of METR emergent rule input.21
6.10.3 Source of METR emergent rule input . 22
6.10.4 Destination of METR emergent rule input. 22
6.10.5 Security for METR emergent rule input . 22
6.11 Information flow: METR feedback . 22
6.11.1 Purpose of METR feedback . 22
6.11.2 Content of METR feedback . . . 22
6.11.3 Source of METR feedback . 22
6.11.4 Destination of METR feedback . 22
6.11.5 Security for METR feedback . 23
6.12 Information flow: METR information . 23
6.12.1 Purpose of METR information . 23
6.12.2 Content of METR information . 23
6.12.3 Source of METR information . 23
6.12.4 Destination of METR information . 23
6.12.5 Security for METR information . 23
6.13 Information flow: METR information for consumers .24
6.13.1 Purpose of METR information for consumers .24
6.13.2 Content of METR information for consumers.24
6.13.3 Source of METR information for consumers .24
6.13.4 Destination of METR information for consumers .24
6.13.5 Security for METR information for consumers .24
6.14 Information flow: METR information signature request .24
6.14.1 Purpose of METR information signature request .24

iv
6.14.2 Contents of METR information signature request .24
6.14.3 Source of METR information signature request .24
6.14.4 Destination of METR information signature request . 25
6.14.5 Security for METR information signature request . 25
6.15 Information flow: METR input . 25
6.15.1 Purpose of METR input . 25
6.15.2 Content of METR input . 25
6.15.3 Source of METR input . 25
6.15.4 Destination of METR input . 25
6.15.5 Security for METR input . 25
6.16 Information flow: METR management information . 25
6.16.1 Purpose of METR management information . 25
6.16.2 Content of METR management information . 26
6.16.3 Source of METR management information . . 26
6.16.4 Destination of METR management information . 26
6.16.5 Security for METR management information . 26
6.17 Information flow: signed METR information . 26
6.17.1 Purpose of signed METR information . 26
6.17.2 Content of signed METR information . 26
6.17.3 Source of signed METR information . 26
6.17.4 Destination of signed METR information . 26
6.17.5 Security for signed METR information .27
6.18 Information flow: system-generated discrepancy report .27
6.18.1 Purpose of system-generated discrepancy report.27
6.18.2 Content of system-generated discrepancy report .27
6.18.3 Source of system-generated discrepancy report .27
6.18.4 Destination of system-generated discrepancy report .27
6.18.5 Security for system-generated discrepancy report .27
6.19 Information flow: TCD discrepancy . 28
6.19.1 Purpose of TCD discrepancy . 28
6.19.2 Content of TCD discrepancy . 28
6.19.3 Source of TCD discrepancy. 28
6.19.4 Destination of TCD discrepancy . 28
6.19.5 Security for TCD discrepancy . 28
6.20 Information flow: TCD discrepancy status . 28
6.20.1 Purpose of TCD discrepancy status . 28
6.20.2 Content of TCD discrepancy status . 28
6.20.3 Source of TCD discrepancy status . 29
6.20.4 Destination of TCD discrepancy status . 29
6.20.5 Security for TCD discrepancy status . 29
6.21 Information flow: TCD status . 29
6.21.1 Purpose of TCD status . 29
6.21.2 Content of TCD status . 29
6.21.3 Source of TCD status . 30
6.21.4 Destination of TCD status . 30
6.21.5 Security for TCD status . 30
6.22 Information flow: unverified METR information . 30
6.22.1 Purpose of unverified METR information . 30
6.22.2 Content of unverified METR information . 30
6.22.3 Source of unverified METR information . 30
6.22.4 Destination of unverified METR information . 30
6.22.5 Security for unverified METR information. 30
6.23 Information flow: verified METR information .31
6.23.1 Purpose of verified METR information .31
6.23.2 Content of verified METR information .31
6.23.3 Source of verified METR information .31
6.23.4 Destination of verified METR information .31
6.23.5 Security for verified METR information .31

v
7 Functional object requirements .31
7.1 Common system-level METR requirements .31
7.1.1 METR Collection & Verification . .31
7.1.2 METR information verification .32
7.1.3 Coordination METR activities . 33
7.1.4 ITS-S unit requirements . 33
7.1.5 General requirements . 34
7.2 Additional MRS requirements . 34
7.2.1 Independent METR verification . 34
7.2.2 METR discovered rule management . 35
7.2.3 METR discrepancy management . 35
7.2.4 METR information approval .37
7.2.5 METR packaging and provisioning .37
7.2.6 METR translation . 39
7.3 Additional MDS requirements .41
7.3.1 METR emergent information distribution .41
7.3.2 METR repackaging and distribution .42
7.3.3 Radio frequency regulations .43
7.3.4 ITS management support .43
7.4 Additional MCS requirements .43
7.4.1 ITS management support .43
7.4.2 METR discrepancy reporting .43
7.4.3 METR reception . . . 44
7.4.4 METR verification .45
7.4.5 Other MCS requirements . .45
7.5 Additional MDHS requirements . 46
7.5.1 ITS management support . 46
7.5.2 METR discrepancy handling . 46
7.5.3 Consolidate discrepancy reports . 46
8 External dependencies . 47
8.1 Contextual functional objects .47
8.1.1 Data collection and provisioning .47
8.1.2 METR information adaptation .47
8.1.3 User device functions . 48
8.2 Actors . 48
8.2.1 Discrepancy handling system operators . 48
8.2.2 Maintenance and construction management centre . 49
8.2.3 Map providers . 49
8.2.4 METR auditor . 49
8.2.5 METR operator . 49
8.2.6 METR user . 50
8.2.7 Non-METR distribution centre . 50
8.2.8 Rule maker . 50
8.2.9 Rule implementation agent . 50
8.2.10 Rule signing agent . 50
8.2.11 Rule translation agent .51
8.2.12 Rule verification agent .52
8.2.13 Supporting data providers .52
8.2.14 Vehicles . 53
Annex A (informative) Deployment scenarios .54
Bibliography .57

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

vii
Introduction
0.1 System overview
0.1.1 General
The ISO 24315 series on the management of electronic traffic regulations (METR) is intended to provide
users access to geo-specific, trustworthy, timely, authoritative, machine-interpret
...

ISO/TC 204
ISO/CD TSDTS 24315-4(en)
ISO/TC 204
Secretariat: ANSI
Date: 2026-08-11
Intelligent transport systems — Management of electronic traffic
regulations (METR) —
Part 4:
System-level requirements (SysR)
Systèmes de transport intelligents — Gestion des règles de circulation sous forme électronique —
Partie 4: Exigences au niveau système (SysR)
TTTTTTTTTThhhhhhhhhhiiiiiiiiiissssssssss d d d d d d d d d drrrrrrrrrraftaftaftaftaftaftaftaftaftaft i i i i i i i i i issssssssss s s s s s s s s s suuuuuuuuuubbbbbbbbbbmmmmmmmmmmiiiiiiiiiittttttttttttttttttttedededededededededed t t t t t t t t t toooooooooo     a pa pa pa pa pa pa pa pa pa pararararararararararallel vallel vallel vallel vallel vallel vallel vallel vallel vallel vooooooooootttttttttte e e e e e e e e e iiiiiiiiiinnnnnnnnnn I I I I I I I I I ISSSSSSSSSSOOOOOOOOOO,,,,,,,,,, C C C C C C C C C CEEEEEEEEEENNNNNNNNNN.

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
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms . 2
5 Overview . 3
5.1 General. 3
5.2 Assumptions and dependencies . 3
5.3 Traceability conventions . 4
5.4 External responsibilities . 5
5.5 Presentation of requirements . 5
5.6 Physical view . 5
6 Information flow requirements . 15
6.1 Information flow: consolidated discrepancy report . 15
6.2 Information flow: discrepancy report details . 16
6.3 Information flow: discrepancy suppression information . 17
6.4 Information flow: local METR information for consumers . 18
6.5 Information flow: METR application information . 19
6.6 Information flow: METR application status . 20
6.7 Information flow: METR coordination . 21
6.8 Information flow: METR device status . 22
6.9 Information flow: METR discrepancy report . 22
6.10 Information flow: METR emergent rule input . 24
6.11 Information flow: METR feedback . 24
6.12 Information flow: METR information . 25
6.13 Information flow: METR information for consumers . 26
6.14 Information flow: METR information signature request . 27
6.15 Information flow: METR input . 27
6.16 Information flow: METR management information . 28
6.17 Information flow: signed METR information . 29
6.18 Information flow: system-generated discrepancy report . 29
6.19 Information flow: TCD discrepancy . 30
6.20 Information flow: TCD discrepancy status . 31
6.21 Information flow: TCD status . 32
6.22 Information flow: unverified METR information . 33
6.23 Information flow: verified METR information . 33
7 Functional object requirements . 34
7.1 Common system-level METR requirements . 34
7.2 Additional MRS requirements . 37
7.3 Additional MDS requirements . 44
7.4 Additional MCS requirements . 46
7.5 Additional MDHS requirements . 48
8 External dependencies. 50
8.1 Contextual functional objects . 50
8.2 Actors . 51
Annex A (informative) Deployment scenarios . 56
iii
Bibliography . 60

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 documentsdocument 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).
Field Code Changed
Attention is drawnISO draws attention to the possibility that some of the elementsimplementation of this
document may beinvolve the subjectuse 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. Details of any patent rights identified during the development of the
document will be in the Introduction and/or on the ISO list of patent declarations received (see ).
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).
This is the first edition of ISO 24315-4.
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 on the management of electronic traffic regulations (METR(METR)) 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
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; and
d) complyingconforming 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,
[1]
pedestrian zones, etc.) .
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; and.
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
viii
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.
e) 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).
f) Electronic rules can be distributed through a wide-area distribution mechanism or a local distribution
mechanism.
g) 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 requireneed 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 (PMR), 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.
ix
Figure 4 — METR three-tier framework
GlobalInternational Standards: ISO standards 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 set of ISO documents of the ISO 24315 series provide a framework based on the ISO-specified
[2]
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 willaim to define requirements for each component system within the
METR SoS and other requirements common to all component systems. The ISO 24315 series willcan promote
x
semantic interoperability, but will needneeds to be interpreted and adapted for regional use to provide
complete interoperability (i.e. including syntactic interoperability).
Regional Interoperabilityinteroperability: 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 NAP.
[3] [4]
Furthermore, non-METR data formats including CEN/TS 17268:2018 (TN-ITS ), CEN/TS 16157-11 CEN
[5] [6]
EN/TS 16157-11 (DATEX-II ), ISO 21219 (series) (TPEG2 ), CEN EN 12896 (series) (TransModel),),
[7] [8]
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.
National & Local Policieslocal policies: Translating and adapting global 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 are defined nationally or locally. Many locations are starting this digitalization of the
rules at an informative supplemental level, rather than as regulatory. It is the responsibility of competent
regulatory authorities and existing approval frameworks to determine:
— terms and conditions for the use of METR information by on-board systems,
— the responsibilities of the driver and automated vehicles in relation to provided METR information, and
— the types of regulations (e.g. local, parking, temporary) that METR is intended to provide within a
jurisdictional area.
0.3 Document overview
The purpose of this document is to define formal requirements for each component of the METR system of
systems. This document has been developed by ISO/TC 204 in coordination with many experts from countries
around the world. ItThis document 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.
[11]
For an understanding of how the component METR systems form the METR SoS, see ISO/TS 24315-3 . The
[10]
operational concept for METR is provided in ISO 24315-2 .
Deployment scenarios can be found in Annex A.
xi
Intelligent transport systems — Management of electronic traffic
regulations (METR) —
Part 4:
System-level requirements (SysR)
1 Scope
This document defines the requirements for each of the component systems that make up the management of
electronic traffic regulations (METR) system of systems (SoS), including the (METR regulation system (MRS),
(), METR distribution system (MDS), (), METR consumer system (MCS),), and (METR discrepancy handling
system (MDHS).).
For an understanding of how the component METR systems form the METR SoS, see CEN ISO/TS 24315-
3:2025. The operational concept for METR is provided in .
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:2025, Intelligent transport systems — Vocabulary
ISO/TS 24315-1, Intelligent transport systems — Management of electronic traffic regulations (METR) — Part
1: Vocabulary
ISO/IEC/IEEE 24765:2017, Systems and software engineering — Vocabulary
CEN ISO/TS 24315-3:2025, Intelligent transport systems - Management of electronic traffic regulations (METR)
- Part 3: System of systems requirements and architecture (SoSR) (ISO/TS 24315-3:2025)
ISO/IEC/IEEE 24765, Systems and software engineering — Vocabulary
ISO/TS 24315-1, Intelligent transport systems — Management of electronic traffic regulations (METR) — Part
1: Vocabulary
NIST 800-53, Rev 5, Security and Privacy Controls for Information Systems and Organizations
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC/IEEE 24765:2017, ISO/TS
14812:2025, ISO/TS 24315-1 and the following 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
3.1
first-tier MDHS
METRfirst-tier management of electronic traffic regulations discrepancy handling system
management of electronic traffic regulations (METR) discrepancy handling system (MDHS) that provides
discrepancy information to another METR discrepancy handling systemMDHS
3.2
second-tier MDHS
METRsecond-tier management of electronic traffic regulations discrepancy handling system
management of electronic traffic regulations (METR) discrepancy handling system (MDHS) that receives
discrepancy information from another METR discrepancy handling systemMDHS
4 Symbols and abbreviated terms
ADS automated driving system
CV connected vehicle
DATEX-II Data Exchange specifications for traffic management and information
GIS geographic information system
GNSS global navigation satellite system
M&CMC maintenance and construction management centre
MCS METR consumer system
MDC METR distribution centre
MDHC METR discrepancy handling centre
MDHS METR discrepancy handling system
MDS METR distribution system
MDV METR distribution vehicle
METR management of electronic traffic regulations
MID METR input device
MRC METR regulation centre
MRS METR regulation system
MUD METR user device
NAP National Access Point
OBE on-board equipment
OEM original equipment manufacturer
PMR public-area mobile robot
RSE roadside equipment
SoS system of systems
SoSR system of systems requirement
SysR system-level requirements
TCD traffic control device
TMDD Traffic Management Data Dictionary
TN-ITS Transport Network - Intelligent Transport Systems
TPEG2 Transport Protocol Experts Group, Generation 2
TRO traffic regulation order
UNECE United Nations Economic Commission for Europe
VRU vulnerable road user
WZDx Work Zone Data Exchange
5 Overview
5.1 General
The METR SoSSoS is designed to provide electronic systems with the machine-readable rules that travellers
are required to follow. Provision of this rule information can be used directly by the receiving electronic
system and can also be displayed to travellers to indicate which rules are currently relevant. To achieve this,
the METR SoS provides a path and process to distribute the rules defined by rule-makers to METR users (e.g.
travellers), who are required to comply with the rules.
Some rules are dependent upon supporting data, which can provide parameters related to a rule (e.g. the
current speed limit for a variable speed limit system) or parameters that activate rules (e.g. the presence of
rain might result in a lower speed limit). The METR SoS is responsible for delivering rules entered by a
translator to (typically mobile) user systems. The user system is responsible for interpreting these rules along
with supporting data from other sources (e.g. visually observed rules, current traffic conditions, and other
factors) and providing the results to the user or modifying vehicle behaviour, as needed. The METR SoS also
includes the ability to report observations from the field back to the central office to ensure that the electronic
data store is consistent with the rules posted in the field.
[10] [11]
For more information, please refer to ISO 24315-2 and ISO/TS 24315-3 CEN ISO/TS 24315-3:2025 .
This document is presented in a format that is consistent with the guidance provided by ISO/IEC/IEEE
[2]
29148 for a system requirements document. Traceability from the requirements in this document to those
[11]
those contained in either this document or ISO/TS 24315-3 CEN ISO/TS 24315-3:2025 can be found in the
electronic supplements of this document provided at https://standards.iso.org/iso/ts/24315/-4/ed-1/en/.
5.2 Assumptions and dependencies
5.2.1 Customizing requirements
The requirements provided in this document are the minimum requirements for an implementation claiming
conformance to this standard. Implementations and the organizations operating implementations often need
to comply with additional requirements as defined by regional, national, or local authorities.
EXAMPLE 1 A regional entity can require METR consumer systems within their region to support non-repudiation.
EXAMPLE 2 A regional entity can require organizations that operate METR regulation systems to update security
credentials at a defined frequency.
EXAMPLE 3 An original equipment manufacturer can require its providers to support non-repudiation for
information exchanges.
5.2.2 Internet-based communications
The METR SoS will likely use the Internet and internet-enabled mobile telecommunication services for data
exchanges among its systems and with external systems. It is assumed that these systems:
a) offer mainstream broadband performance, which can provide sufficient bandwidth and latency
performance for the exchange of data among the centralized systems of METR;
b) offer 3G (or greater) cellular performance, which can provide sufficient bandwidth and latency
performance for the provision of the data to mobile users as defined in this document under most
conditions;
c) use mobile wireless internet connectivity, which can become unstable at any location; and
d) might not have connectivity available at some locations at any time.
5.2.3 Vehicle communications
METR User systems will likely need to use wireless communications to maintain their electronic maps and to
obtain supporting data.
5.2.4 Geo-positioning rules
The METR SoS will geo-position rules using readily accessible positioning technologies such as global
navigation satellite systems (GNSS) and geographic information systems (GIS). It is assumed that the
underlying systems are properly maintained with correction factors applied to produce accurate positioning.
5.2.5 Leverage existing standards
METR is one ITS service among many existing services with existing standards. It is assumed that METR
implementations will adopt and adapt existing ITS standards to the extent possible.
5.2.6 Efficient data exchange
Data exchanges are to be designed to be appropriately efficient for the communications environment for which
they are intended.
5.2.7 Additional requirements
Regions, nations, and other entities can define additional requirements on implementations and the
organizations that operate implementations.
5.3 Traceability conventions
Within the systems engineering process, every managed item (e.g. user need, requirement, design element,
etc.) should exist for a reason; these reasons are captured in different specifications and connected through
traceable links from one managed item to another. The types of traceability used to justify managed items
shall be as defined in CEN ISO/TS 24315-3:2025, 5.5.
5.4 External responsibilities
This document does not place requirements on data exchanges with entities external to the METR SoS, but
[10]
Clause 8 identifies responsibilities for the external entities per the ConOps ISO 24315-2[9 .
Field Code Changed
5.5 Presentation of requirements
As this document is primarily interested in establishing requirements for interoperability, many of the
requirements relate to information transfers (i.e. an information flow from a source to a destination). Rather
than duplicating text for each instance and each side of an information transfer, these requirements are
presented in Clause 6, once per information flow. Other requirements are presented in Clause 7.
The information flow requirements are presented with the following subclauses:
a) Definition: provides a reference to the clause in CEN ISO/TS 24315-3:2025 that defines the purpose and
contents of the information flow;
b) Content: identifies the data that is contained within the input/output;
c) Source: identifies the intended source of the flow, per the METR reference architecture and provides a
reference to the requirements or expectations of the source;
d) Destination: identifies the intended destination of the flow, per the METR reference architecture and
provides a reference to the requirements or expectations of the destination; and
e) Constraints: when needed, identifies any additional constraints that apply to the flow.
[11]
NOTE CEN ISO/TS 24315-3:2025 CEN ISO/TS 24315-3:2025 includes information flows that provide context for
the METR SoS but are not within the METR SoS itself. These flows are not discussed in this document other than listing
them as contextual flows in 5.6.
5.6 Physical view
5.6.1 General
This subsection provides the physical view of the METR system-level reference architecture from the
perspective of each component system. CEN ISO/TS 24315-3:2025 (METR SoSR ) provides similar diagrams
focused on major services rather than one system at a time.
The diagrams in this section include the following major element types:
a) Physical objects are represented as grey boxes with solid borders. Physical objects represent groups of
functional objects that are likely to be deployed in a single physical entity (e.g. computer system);
however, deployments are allowed combine or divide the physical objects of the reference architecture
to meet their deployment needs. Each physical object is described in Clause 8.
b) System objects are represented as grey boxes with dashed borders inside of physical objects. Darker grey
boxes represent system objects that are a part of the METR SoS while the lighter grey boxes represent
system objects outside of the METR SoS. METR System objects are used to clearly identify how the four
component METR systems defined by this reference architecture are likely to be deployed within physical
objects and the functional objects that they are likely to contain. Actual deployments may vary from this
reference architecture to meet their specific objectives. Each system object is described in 5.6.2 through
5.6.5 and includes a physical view diagram depicting the information transfers associated with the system
object.
c) Functional objects are represented as white boxes with solid borders inside of the physical objects.
Functional objects represent sets of related processes that are performed by a physical object to fulfil
aspects of an ITS service. The diagrams only identify functional objects that are relevant for the METR
service. Clause 7 defines formal requirements for those functional objects that are considered to be part
of a METR component system. Clause 8 describes other functional objects contained in the physical view
diagrams that are outside of the METR SoS but relevant to the METR service.
d) Information transfers are represented as arrows between physical objects. An information transfer
represents the exchange of an information flow from a source physical object to a destination physical
object. The requirements for each information flow are defined in Clause 6.
5.6.2 Physical view diagrams
5.6.2.1 METR regulation system
5.6.2.1.1 Overview
The METR regulation system (MRS) is responsible for creating, maintaining, and signing electronic versions
of transport-related rules, which will be provided to other components of the METR system of systems (SoS)
for distribution to METR users.
Figure 5 identifies the incoming and outgoing information flows for an MRS per the reference architecture.
Within the reference architecture, an MRS can exist in either a METR regulation centre or in a METR input
device, which represents any device used to remotely enter regulations. Deployment architectures may
choose to separate the functional objects of a MRS in other ways to accommodate deployment needs.
Key
centre
field
personal
vehicle
physical or functional object
METR system
flow outside the METR system
METR flow
Figure 5 — MRS physical view
5.6.2.1.2 MRS information transfers
The information transfers to and from the MRS include the following. Clause 6 provides the formal
specification for each referenced information flow.
a) CV RSE -> MID: METR application status
b) MDHC -> MRC: consolidated discrepancy report
c) MDHC -> MRC: discrepancy report details
d) MDHC -> MRC: system-generated discrepancy report
e) MDC -> MRC: system-generated discrepancy report
f) Maintenance and construction management centre (M&CMC ) -> MRC: TCD discrepancy status
g) M&CMC -> MRC: TCD implementation status
h) M&CMC -> MRC: TCD status
i) M&CMC -> MRC: system-generated discrepancy report
j) MID -> CV RSE: METR application information
k) MID -> MDC: METR device status
l) MID -> MDC: METR information
m) MID -> MDV : METR management information
n) MID <-> MRC: METR information
o) MID -> Rule signing agent: METR information signature request
p) MID -> Rule translation agent: METR feedback
q) MRC <-> Discrepancy Contact Centre: METR coordination
r) MRC <-> M&CMC: METR coordination
s) MRC -> M&CMC: METR information
t) MRC -> M&CMC: TCD discrepancy
u) MRC -> MDHC: discrepancy suppression info
v) MRC -> METR Discrepancy Handling Centre: METR information
w) MRC -> MDC: METR information
x) MRC -> Non-METR Distribution Centre: METR information
y) MRC <-> Other MRC: METR coordination
z) MRC <-> Other MRC (including a METR input device): METR information
aa) MRC <-> Other MRC: system-generated discrepancy report
bb) MRC -> Rule signing agent: METR information signature request
cc) MRC -> Rule translation agent: METR feedback
dd) MRC -> Rule verification agent: unverified METR information
ee) MUD -> MRC: METR discrepancy report
ff) Non-METR Distribution Centre -> MRC: system-generated discrepancy report
gg) Rule signing agent -> MID: signed METR information
hh) Rule signing agent -> MRC: signed METR information
ii) Rule translation agent -> MID: METR emergent rule input
jj) Rule translation agent -> MRC: METR emergent rule input
kk) Rule translation agent -> MRC: METR input
ll) Rule verification agent -> MRC: verified METR information
5.6.2.1.3 Contextual information transfers
The following information transfers shown in Figure 5 provide a broader context of how the system is
intended to work. While these transfers are important for the METR SoS to maintain trustworthy information,
the details of these interface details regarding these human-machine information transfers are not completely
addressed by the METR standards.
a) Rule implementation agent <-> M&CMC: TCD implementation update
b) Rule implementation agent <-> Rule verification agent: offline METR coordination
c) Rule signing agent <-> Rule translation agent: offline METR coordination
d) Rule translation agent <-> Rule verification agent: offline METR coordination
5.6.2.2 METR distribution system
5.6.2.2.1 Overview
A METR distribution system (MDS) is primarily responsible for distributing METR information to METR
consumer systems (MCSs) in an efficient manner. It obtains the information to be distributed from one or
more MRS. As the last point before distribution to consumers, the MDS also performs verification and
consistency checks across the rules in its database, to the extent possible.
Figure 2 identifies the incoming and outgoing information flows for a MDS per the reference architecture.
Within the reference architecture, a MDS can exist in a METR distribution centre, CV, RSE, or MDV. Deployment
architectures may opt for other configurations.
Key
centre
field
personal
vehicle
physical or functional object
METR system
METR flow
Figure 6 — MDS physical view
5.6.2.2.2 MDS information transfers
The information transfers to and from the MDS include the following. Clause 6 provides the formal
specification for each referenced information flow.
a) CV RSE -> MID: METR application status
b) CV RSE -> MUD: local METR information for consumers
c) MDC -> MUD: METR information for consumers
d) MDC -> MDC: system-generated discrepancy report
e) MDC <-> Other MDC: METR information
f) MDC <-> Other MDC: system-generated discrepancy report
g) MDV -> MUD: local METR information for consumers
h) MID -> CV RSE: METR application information
i) MID -> MDC: METR device status
j) MID -> MDC: METR information
k) MID -> MDV: METR management information
l) MRC -> MDC: METR information
5.6.2.2.3 Contextual information transfers
The following information transfers shown in Figure 2 provide a broader context of how the system is
intended to work. While these transfers are important for the METR SoS to maintain trustworthy information,
the details of these interface details regarding these human-machine information transfers are not completely
addressed by the METR standards.
a) CV RSE -> METR user device: supporting data
b) ITS roadway equipment -> CV RSE: field equipment status
5.6.2.3 METR consumer system
5.6.2.3.1 Overview
The MCS is responsible for registering for, obtaining, and verifying METR information from MDS and providing
this information for use via the METR user system. It may also be responsible for reporting any detected
discrepancies to a METR discrepancy handling system.
Figure 3 identifies the incoming and outgoing information flows for an MCS per the reference architecture.
Within the reference architecture, a MCS can exist in a METR user device, which can represent a number of
different physical objects such as a vehicle, a smartphone, or computer and includes users during a journey or
planning a journey.
Key
centre
field
personal
vehicle
physical or functional object
METR system
METR flow
Figure 7 — MCS physical view
5.6.2.3.2 MCS information transfers
The information transfers to and from the MCS include the following. Clause 6 provides the formal
specification for each referenced information flow.
a) CV RSE -> MUD: local METR information for consumers
b) MDC -> MUD: METR information for consumers
c) MDV -> MUD: local METR information for consumers
d) MUD -> MDHC: METR discrepancy report
e) MUD -> MRC: METR discrepancy report
5.6.2.3.3 Contextual information transfers
The following information transfers shown in Figure 3 provide a broader context of how the system is
intended to work. While these transfers are important for the METR SoS to maintain trustworthy information,
the details of these interface details regarding these human-machine information transfers are not completely
addressed by the METR standards.
a) METR user -> MUD: supporting user data
b) MUD -> METR user: user updates
c) Supporting data provider -> MUD: supporting data
5.6.2.4 METR discrepancy handling system
5.6.2.4.1 Overview
The METR discrepancy handling system (MDHS )) is responsible for receiving and consolidating discrepancy
reports from METR user devices and reporting this information to the appropriate MRS once conditions meet
locally defined policies.
Figure 4 identifies the incoming and outgoing information flows for an MDHS per the reference architecture.
Within the reference architecture, an MDHS exists as a stand-alone centre, but deployment architectures can
combine this functionality with other systems.
Key
c
...