ISO 14229-1:2026
(Main)Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
- Abstract
This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
- Status
- Published
- Publication Date
- 04-Jun-2026
- Technical Committee
- ISO/TC 22/SC 31 - Data communication
- Drafting Committee
- ISO/TC 22/SC 31/WG 2 - Vehicle diagnostic protocols
- Current Stage
- 6060 - International Standard published
- Start Date
- 05-Jun-2026
- Due Date
- 09-Oct-2026
- Completion Date
- 05-Jun-2026
ISO 14229-1:2026 is an International Standard from ISO for Unified diagnostic services (UDS) in road vehicles. It specifies the application-layer, data link independent diagnostic communication services that a tester can use to interact with an in-vehicle electronic control unit (ECU, server) for reading data, controlling functions, handling DTCs, managing security, and supporting programming.
What does ISO 14229-1:2026 specify?
ISO 14229-1:2026 specifies the application-layer requirements for diagnostic communication between a diagnostic tester (client) and an ECU (server) on a vehicle serial data link. The document is organized as general service and protocol conventions, then a series of functional units covering diagnostic management, data transmission, stored data transmission, input/output control, routines, upload and download, a security sub-layer, and non-volatile server memory programming.
The scope makes two practical limits clear. ISO 14229-1:2026 does not apply to non-diagnostic message transmission between ECUs, and it does not set implementation requirements for how a client is built inside an ECU/server.
| Annex | What it covers |
|---|---|
| Annex A | Global parameter definitions |
| Annex B | Diagnostic and communication management functional unit data parameter definitions |
| Annex C | Data transmission functional unit data parameter definitions |
| Annex D | Stored data transmission functional unit data parameter definitions |
| Annex E | Input output control functional unit data parameter definitions |
| Annex F | Routine functional unit data parameter definitions |
| Annex G | Upload and download functional unit data parameter definitions |
| Annex H | Examples for addressAndLengthFormatIdentifier parameter values |
| Annex I | Security access state chart |
| Annex J | Implementation for multiple client environments |
What are the key requirements of ISO 14229-1:2026?
Clause 6 defines the service model and the parameters that carry diagnostic data
ISO 14229-1:2026 uses OSI service conventions, with service primitives for request, indication, response, confirm, and the combined request-confirm and response-confirm forms. In practice, this is the document's message model: it defines how the client and server exchange diagnostic information, not the lower-layer transport itself.
Clause 6.4 defines the mandatory application-layer parameters such as A_Mtype, A_SA, A_TA, A_TA_Type, A_Result, A_Length, and A_Data, plus the optional A_AE remote address. For implementers, these are the fields that must be mapped into the diagnostic service interface and handled consistently by the client and server.
Clause 7 defines the protocol identifiers and the basic server response rules
ISO 14229-1:2026 assigns service identifiers (SID) to request and positive response messages, with bit 6 distinguishing the service type. The document also defines the negative response service identifier and the rules for server response behavior, including how the server handles supported services, subfunctions, and concurrent requests.
Clause 7.7 is important in real systems because it governs what happens when a request is already being processed, when a service uses a SubFunction parameter, and when requests arrive through physical or functional addressing. This is the part engineers use to determine whether a tester will get an immediate answer, a negative response, or must wait for a different service to finish.
Clause 8 defines the message layout conventions used by all services
ISO 14229-1:2026 standardizes request and positive response message structure, including the SubFunction value space and the suppressPosRspMsgIndicationBit (SPRMIB). SPRMIB lets a client request that a positive response be suppressed, while negative responses still follow the service rules.
Clause 8 also states that each service provides its own request and response data parameter definitions, supported negative response codes, and message flow examples. In practice, that means every service section gives the data fields, the allowed values, and example exchanges needed to build or test a diagnostic implementation.
Clause 9 covers diagnostic and communication management
ISO 14229-1:2026 defines the main control services used to start, stop, secure, or adapt a diagnostic session. These include DiagnosticSessionControl, ECUReset, SecurityAccess, CommunicationControl, Authentication, TesterPresent, ControlDTCSetting, ResponseOnEvent, and LinkControl.
The session rules matter operationally. The document distinguishes defaultSession, ProgrammingSession, extendedDiagnosticSession, and safetySystemDiagnosticSession, and it ties non-default sessions to a session timer that the client must keep active. It also states which services are allowed in default and non-default sessions, and it describes how SecurityAccess, Authentication, and communication control affect what the server may accept.
Clause 10 defines data transmission services
ISO 14229-1:2026 specifies how a client reads and writes data identifiers and memory, reads scaling data, requests periodic data, and defines dynamic data identifiers. It also covers WriteDataByIdentifier and WriteMemoryByAddress, which are the main services used when a tester or engineering tool has to modify ECU data.
This clause is where practical data access rules appear. It includes the negative response handling for cases such as invalid length, response too long, unsupported identifiers, secured data, and unsupported periodic scheduling, so it is the section to check before designing a test plan or troubleshooting a failed read/write operation.
Clause 11 defines stored data and DTC handling
ISO 14229-1:2026 includes ClearDiagnosticInformation and ReadDTCInformation. ReadDTCInformation covers multiple reporting modes, including DTC status masks, snapshot records, extended data, severity information, supported DTCs, permanent status, user defined memory, and WWH-OBD related reporting.
For service and quality teams, this clause is the main reference for what a tester can query after a fault occurs and what kind of diagnostic evidence the server can return. It is also where the document explains the different report types that support repair, verification, and post-service checks.
Clauses 12 to 16 add control, transfer, security, and programming functions
ISO 14229-1:2026 defines InputOutputControlByIdentifier, RoutineControl, RequestDownload, RequestUpload, TransferData, RequestTransferExit, RequestFileTransfer, SecuredDataTransmission, and the non-volatile server memory programming process. These clauses are the backbone for calibration, flashing, and controlled service actions.
Clause 15 introduces the security sub-layer and the SecuredDataTransmission service. Clause 16 then describes programming phases, the detailed programming sequence, server reprogramming requirements, software and data identification and fingerprints, and routine access during reprogramming. In practice, these clauses tell a tool supplier how to structure secure transfers and a vehicle manufacturer how to organize ECU software update behavior.
What terms does ISO 14229-1:2026 define?
- client - A function that is part of the tester and uses the diagnostic services.
- diagnostic channel - The dedicated transmission path from client to server for diagnostic communication.
- boot memory partition - The server memory area that contains the boot software.
- boot software - Software executed from a special server memory area to boot the ECU and perform server programming.
- service identifier (SID) - The byte value that encodes which diagnostic service is being called.
- negative response code (NRC_) - The code used in a negative response to show why a request was rejected or not accepted.
- suppressPosRspMsgIndicationBit (SPRMIB) - The bit that tells the server whether a positive response should be suppressed.
- ProgrammingSession - The diagnostic session that enables services needed for memory programming.
Who uses ISO 14229-1:2026?
ISO 14229-1:2026 is used by automotive diagnostic tool developers, ECU and server designers, vehicle manufacturers, and system suppliers. It is also used by calibration and flashing tool developers, workshop diagnostics teams, and test engineers who need to read vehicle data, control actuators, manage DTCs, run routines, or reprogram non-volatile memory.
The standard is especially relevant where a tool must work across different vehicle networks but use the same application-layer diagnostic behavior. It helps teams agree on request/response structure, security steps, session handling, and the meaning of negative responses before integration or validation.
What changed in ISO 14229-1:2026 from the previous edition?
ISO 14229-1:2026 is the fourth edition of ISO 14229-1.
Which standards are used with ISO 14229-1:2026?
ISO 14229-1:2026 refers to several companion standards and technical references that support its diagnostic and security behavior.
- ISO/IEC 7816-8 - Provides commands and mechanisms for security operations used in secure authentication contexts.
- ISO/IEC 9594-8 - Provides public-key and attribute certificate frameworks used for certificate-based authentication.
- ISO 14229-2 - Covers the session layer services used with the application-layer services in this part.
- IEEE 754-2008 - Supports floating-point arithmetic, relevant where numeric values are exchanged or interpreted.
- IEEE 1609.2 - Provides security services for vehicular applications and management messages.
- ITU-T X.690 - Provides BER, CER, and DER encoding rules used in certificate-related processing.
- RFC 5280 - Defines the X.509 public key infrastructure certificate and certificate revocation list profile.
- ISO/IEC 10731 - Underpins the OSI service conventions used in Clause 5.
- ISO 15031-5 / SAE J1979 - Appears in SID and positive response ranges for OBD-related services.
- ISO 26021-2 - Is referenced for some SecurityAccess values related to end-of-life activation of on-board pyrotechnic devices.
What does the ISO 14229-1:2026 document contain?
ISO 14229-1:2026 contains the general conventions for diagnostic services, then detailed service definitions for each functional unit. The body includes request and positive response message definitions, supported negative response codes, and message flow examples for services such as session control, security access, read/write operations, DTC handling, event reporting, and flashing.
It also contains protocol rules that are useful for implementation and testing, including server response behavior, request handling with and without SubFunction parameters, and handling of multiple concurrent requests. Several clauses include figures and tables for session state, response behavior, sampling, periodic scheduling, and NRC handling.
The annexes add the parameter dictionaries that make the service definitions usable in practice. Annex H gives examples for addressAndLengthFormatIdentifier values, Annex I gives the security access state chart, and Annex J addresses multiple client environments.
Relations
- Effective Date
- 28-Oct-2023
- Revises
ISO 14229-1:2020 - Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer - Effective Date
- 14-Oct-2023
Get Certified
Connect with accredited certification bodies for this standard
TÜV Rheinland
TÜV Rheinland is a leading international provider of technical services.
TÜV SÜD
TÜV SÜD is a trusted partner of choice for safety, security and sustainability solutions.
DEKRA Certification Inc.
DEKRA US certification services.
Sponsored listings
Frequently Asked Questions
ISO 14229-1:2026 is a standard published by the International Organization for Standardization (ISO). Its full title is "Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer". This standard covers: This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
This document specifies data link independent requirements of diagnostic communication services. These allow a diagnostic tester (client) to control diagnostic functions in an in-vehicle electronic control unit (ECU, server) such as an electronic fuel injection, automatic gearbox, anti-lock braking system, etc. connected to a serial data link embedded in a road vehicle. This document specifies diagnostic communication services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission, to read vehicle identification data and real-time sensor data, read and clear diagnostic information, control actuators, start/stop routines, and many more functions to assist in diagnosing the vehicle's electronic systems. This document does not apply to non-diagnostic message transmission on the vehicle's communication data link between two electronic control units. This document does not restrict an in-vehicle on-board tester (client) implementation in an ECU/server in order to utilize the diagnostic communication services on the vehicle's communication data link to perform bidirectional diagnostic data exchange. This document does not specify any implementation requirements.
ISO 14229-1:2026 is classified under the following ICS (International Classification for Standards) categories: 43.180 - Diagnostic, maintenance and test equipment. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 14229-1:2026 has the following relationships with other standards: It is inter standard links to ISO 14229-1:2020/Amd 1:2022, ISO 14229-1:2020. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
ISO 14229-1:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
International
Standard
ISO 14229-1
Fourth edition
Road vehicles — Unified diagnostic
2026-06
services (UDS) —
Part 1:
Application layer
Véhicules routiers — Services de diagnostic unifiés (SDU) —
Partie 1: Couche application
Reference number
© ISO 2026
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 .viii
Introduction .ix
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Symbols and abbreviated terms. 4
4.1 Symbols .4
4.2 Abbreviated terms .5
5 Conventions . 6
6 Application layer services . 6
6.1 General .6
6.2 Format description of application layer services .8
6.3 Format description of service primitives .8
6.3.1 General definition .8
6.3.2 Service request and service indication primitives .9
6.3.3 Service response and service confirm primitives .9
6.3.4 Service request-confirm and service response-confirm primitives .10
6.4 Service data unit specification .11
6.4.1 Mandatory parameters .11
6.4.2 Vehicle system requirements . 13
6.4.3 Optional parameters - A_AE, application layer remote address . 13
7 Application layer protocol . 14
7.1 General definition .14
7.2 A_PDU, application protocol data unit .14
7.3 A_PCI, application protocol control information .14
7.4 SID, service identifier. 15
7.5 A_NR_SID, Negative response service identifier .16
7.6 Negative response/confirmation service primitive .16
7.7 Server response implementation rules .16
7.7.1 General definitions .16
7.7.2 General server response behaviour .17
7.7.3 Request message with SubFunction parameter and server response behaviour .18
7.7.4 Request message without SubFunction parameter and server response
behaviour . 22
7.7.5 Pseudo code example of server response behaviour .24
7.7.6 Multiple concurrent request messages with physical and functional addressing . 25
8 Service description conventions .26
8.1 Service description . 26
8.2 Request message . 26
8.2.1 Request message definition . 26
8.2.2 Request message SubFunction parameter $Level (LEV_) definition .27
8.2.3 Request message data parameter definition . 29
8.3 Positive response message . 29
8.3.1 Positive response message definition . 29
8.3.2 Positive response message data parameter definition . 30
8.4 Supported negative response codes (NRC_) . 30
8.5 Message flow examples .31
9 Diagnostic and communication management functional unit .32
9.1 Overview .32
9.2 DiagnosticSessionControl (10 ) service .32
9.2.1 Service description .32
iii
9.2.2 Request message . 35
9.2.3 Positive response message .37
9.2.4 Supported negative response codes (NRC_) . 38
9.2.5 Message flow example(s) DiagnosticSessionControl – Start programmingSession . 38
9.3 ECUReset (11 ) service . 39
9.3.1 Service description . . 39
9.3.2 Request message . 39
9.3.3 Positive response message .41
9.3.4 Supported negative response codes (NRC_) .41
9.3.5 Message flow example ECUReset .42
9.4 SecurityAccess (27 ) service .42
9.4.1 Service description . .42
9.4.2 Request message . 44
9.4.3 Positive response message .45
9.4.4 Supported negative response codes (NRC_) . 46
9.4.5 Message flow example(s) SecurityAccess .47
9.5 CommunicationControl (28 ) service . 49
9.5.1 Service description . . 49
9.5.2 Request message . 49
9.5.3 Positive response message . 50
9.5.4 Supported negative response codes (NRC_) .51
9.5.5 Message flow example CommunicationControl (disable transmission of
network management messages) .51
9.5.6 Message flow example CommunicationControl (switch a remote network into
the diagnostic-only scheduling mode where the node with address 000A is
connected to) .52
9.5.7 Message flow example CommunicationControl (switch to application scheduling
mode with enhanced address information, the node 000A , which is connected
to a sub-network, is addressed) .52
9.6 Authentication (29 ) service . 53
9.6.1 Service overview . 53
9.6.2 Authentication with PKI Certificate Exchange (APCE) . 54
9.6.3 Authentication with Challenge-Response (ACR) .59
9.6.4 Common requirements . 63
9.6.5 Request message . 64
9.6.6 Positive response message .70
9.6.7 Supported negative response codes (NRC_) . 77
9.6.8 Message flow example(s) Authentication . 78
9.7 TesterPresent (3E ) service . 98
9.7.1 Service description . . 98
9.7.2 Request message . 99
9.7.3 Positive response message . 99
9.7.4 Supported negative response codes (NRC_) . 100
9.7.5 Message flow example(s) TesterPresent . 100
9.8 ControlDTCSetting (85 ) service . 101
9.8.1 Service description . 101
9.8.2 Request message . 101
9.8.3 Positive response message . 102
9.8.4 Supported negative response codes (NRC_) . 103
9.8.5 Message flow example(s) ControlDTCSetting . 103
9.9 ResponseOnEvent (86 ) service . 104
9.9.1 Service description . 104
9.9.2 Request message . 112
9.9.3 Positive response message . 118
9.9.4 Supported negative response codes (NRC_) . 121
9.9.5 Message flow example(s) ResponseOnEvent . 122
9.10 LinkControl (87 ) service . 136
9.10.1 Service description . . 136
9.10.2 Request message . 136
iv
9.10.3 Positive response message . 138
9.10.4 Supported negative response codes (NRC_) .138
9.10.5 Message flow example(s) LinkControl . 139
10 Data transmission functional unit .141
10.1 Overview .141
10.2 ReadDataByIdentifier (22 ) service .142
10.2.1 Service description . .142
10.2.2 Request message .142
10.2.3 Positive response message .143
10.2.4 Supported negative response codes (NRC_) . 144
10.2.5 Message flow example ReadDataByIdentifier . 146
10.3 ReadMemoryByAddress (23 ) service . 148
10.3.1 Service description . 148
10.3.2 Request message . 148
10.3.3 Positive response message . 149
10.3.4 Supported negative response codes (NRC_) . 150
10.3.5 Message flow example ReadMemoryByAddress. 151
10.4 ReadScalingDataByIdentifier (24 ) service . 153
10.4.1 Service description . 153
10.4.2 Request message .154
10.4.3 Positive response message .154
10.4.4 Supported negative response codes (NRC_) . 155
10.4.5 Message flow example ReadScalingDataByIdentifier . 157
10.5 ReadDataByPeriodicIdentifier (2A ) service . 160
10.5.1 Service description . . 160
10.5.2 Request message . 163
10.5.3 Positive response message . 163
10.5.4 Supported negative response codes (NRC_) . 164
10.5.5 Message flow example ReadDataByPeriodicIdentifier .167
10.6 DynamicallyDefineDataIdentifier (2C ) service . 177
10.6.1 Service description . . 177
10.6.2 Request message . 178
10.6.3 Positive response message . 182
10.6.4 Supported negative response codes (NRC_) . 182
10.6.5 Message flow examples DynamicallyDefineDataIdentifier . 183
10.7 WriteDataByIdentifier (2E ) service . 196
10.7.1 Service description . . 196
10.7.2 Request message . 196
10.7.3 Positive response message . 197
10.7.4 Supported negative response codes (NRC_) . 197
10.7.5 Message flow example WriteDataByIdentifier . 199
10.8 WriteMemoryByAddress (3D ) service .200
10.8.1 Service description . .200
10.8.2 Request message . 201
10.8.3 Positive response message . 202
10.8.4 Supported negative response codes (NRC_) . 203
10.8.5 Message flow example WriteMemoryByAddress .204
11 Stored data transmission functional unit .207
11.1 Overview . 207
11.2 ClearDiagnosticInformation (14 ) service . 207
11.2.1 Service description . . 207
11.2.2 Request message . 207
11.2.3 Positive response message .208
11.2.4 Supported negative response codes (NRC_) .208
11.2.5 Message flow example ClearDiagnosticInformation .210
11.3 ReadDTCInformation (19 ) service .210
11.3.1 Service description . .210
11.3.2 Request message . 221
v
11.3.3 Positive response message . 230
11.3.4 Supported negative response codes (NRC_) .246
11.3.5 Message flow examples – ReadDTCInformation.246
12 InputOutput control functional unit .275
12.1 Overview . 275
12.2 InputOutputControlByIdentifier (2F ) service . 275
12.2.1 Service description . . 275
12.2.2 Request message .276
12.2.3 Positive response message . 277
12.2.4 Supported negative response codes (NRC_) . 278
12.2.5 Message flow example(s) InputOutputControlByIdentifier . 279
13 Routine functional unit . 287
13.1 Overview .287
13.2 RoutineControl (31 ) service .288
13.2.1 Service description .288
13.2.2 Request message .289
13.2.3 Positive response message .290
13.2.4 Supported negative response codes (NRC_) . 291
13.2.5 Message flow example(s) RoutineControl .294
14 Upload download functional unit .297
14.1 Overview . 297
14.2 RequestDownload (34 ) service . 297
14.2.1 Service description . .297
14.2.2 Request message . 297
14.2.3 Positive response message .299
14.2.4 Supported negative response codes (NRC_) .299
14.2.5 Message flow example(s) RequestDownload . 301
14.3 RequestUpload (35 ) service . 301
14.3.1 Service description . . 301
14.3.2 Request message . 302
14.3.3 Positive response message . 303
14.3.4 Supported negative response codes (NRC_) .304
14.3.5 Message flow example(s) RequestUpload . 305
14.4 TransferData (36 ) service .306
14.4.1 Service description . .306
14.4.2 Request message .306
14.4.3 Positive response message . 307
14.4.4 Supported negative response codes (NRC_) .308
14.4.5 Message flow example(s) TransferData .310
14.5 RequestTransferExit (37 ) service . .310
14.5.1 Service description . .310
14.5.2 Request message . 311
14.5.3 Positive response message . 311
14.5.4 Supported negative response codes (NRC_) . 312
14.5.5 Message flow example(s) for downloading/uploading data . 313
14.6 RequestFileTransfer (38 ) service .319
14.6.1 Service description . .319
14.6.2 Request message . 320
14.6.3 Positive response message . 321
14.6.4 Supported negative response codes (NRC_) . 323
14.6.5 Message flow example(s) RequestFileTransfer . 325
15 Security sub-layer definition .327
15.1 General . 327
15.1.1 Purpose . 327
15.1.2 Security sub-layer description . 327
15.1.3 Security sub-layer access . . 328
15.1.4 General server response behaviour . 332
vi
15.2 SecuredDataTransmission (84 ) service .334
15.2.1 Service description . .334
15.2.2 Request message . 334
15.2.3 Positive response message for successful internal message . 336
15.2.4 Supported negative response codes (NRC_) . 338
15.2.5 Message flow example SecuredDataTransmission . 338
16 Non-volatile server memory programming process .341
16.1 General . 341
16.2 Programming phases . . 343
16.3 Detailed programming sequence .344
16.3.1 Programming phase #1 — Download of application software and/or application
data .344
16.4 Server reprogramming requirements . 353
16.4.1 Requirements for servers to support programming. 353
16.4.2 Software, data identification and fingerprints . 356
16.4.3 Server routine access . 357
16.5 Non-volatile server memory programming message flow examples . 357
16.5.1 General information . 357
16.5.2 Programming phase #1 — Pre-Programming step . 357
16.5.3 Programming phase #1 — Programming step . 358
16.5.4 Programming phase #1 — Post-Programming step . 362
Annex A (normative) Global parameter definitions . 363
Annex B (normative) Diagnostic and communication manageme
...