ISO/FDIS 17978-2

ISO/TC 22/SC 31
Secretariat: DIN
Date: 2025-082026-01-06
Road vehicles — Service-oriented vehicle diagnostics (SOVD) — —
Part 2:
Use cases definition
Véhicules routiers – — Diagnostic Véhicule Orienté Services, (SOVD) — —
Partie 2: Définition des cas d’usage
FDIS stage
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'sISO’s member body in the country of the requester.
ISO Copyright Officecopyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: + 41 22 749 01 11
Email: E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland.
ii
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Use cases . 2
5.1 General . 2
5.2 Use case 01 – Discover SOVD server(s) . 3
5.3 Use Case 02 – Discover entities . 4
5.4 Use case 03 – Authenticate and authorize SOVD clients . 4
5.5 Use case 04 – Read fault(s) and/or its details from an entity . 5
5.6 Use case 05 – Delete fault(s) of an entity . 5
5.7 Use case 06 – Read data resources . 6
5.8 Use case 07 – Write data items . 6
5.9 Use case 08 – Control operations . 7
5.10 Use case 09 – Read and write configurations. 7
5.11 Use case 10 – Control software updates . 8
5.12 Use case 11 – Handle bulk data . 9
5.13 Use case 12 – Control logging and retrieve logs . 10
5.14 Use case 13 – Control communication logging . 12
5.15 Use case 14 – Manage and execute scripts . 13
5.16 Use case 15 – Manage triggers and subscriptions . 14
5.17 Use case 16 – Query an online capability description . 16
5.18 Use case 17 – Provide an offline capability description . 16
Bibliography . 17

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 documentdocuments 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'sISO’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 22, Road vehicles, Subcommittee SC 31, Data
communication.
A list of all parts in the ISO 17978 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
The introduction of high performance computers (HPCs (High Performance Computers) in vehicles is
associated with changes in the classical electronic and electrical vehicle architecture. Besides classical
distributed embedded electronic control unit (ECU (Electronic Control Unit) ) architectures, domain-based or
zone-based architectures are also available. These architectures also extend beyond the physical vehicle.
This extends the focus from checking hardware to also checking the functionality of applications. It requires
the recording of data such as memory usage, processor load, and the number of active services, as well as the
collection of log and trace files.
These topics result in challenges regarding the management of the vehicle life cycle. Some aspects to be
considered are:
— — faster release and update cycles;
— — increased requirements such as data protection and cybersecurity;
— — state-of-the-art diagnostic application programming interface (API (Application Programming
Interface) using current information technologies.
The ISO 17978 series defines an API which standardizes the methods for:
— — discovering the SOVD capabilities;
— — performing diagnostics;
— — (re-)configuring and re-programming;
— — allowing the introduction of new functionalities.
Figure 1Figure 1 shows the open systems interconnection (OSI (Open Systems Interconnection) layers of the
ISO 17978 series.
v
vi
Key
a
communicationCommunication protocol.
b
networkNetwork technology depending on E/E vehicle network architecture.
Figure 1 — OSI layers of SOVD
vii
DRAFT International Standard ISO/FDIS 17978-2:2025(en)

Road vehicles — Service-oriented vehicle diagnostics (SOVD) — —
Part 2:
Use cases definition
1 Scope
This document gives an overview of the service-oriented vehicle diagnostics (SOVD) use cases. Each use case
consists of name, inputs, outputs, a description and examples.
Use cases are described in an abstracted form to be independent of the underlying technologies.
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 17987-1,
ISO 17978-1, Road vehicles — Service-oriented vehicle diagnostics (SOVD) — Part 1: General information,
definitions, rules and basic principles
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 17978-1 apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— — ISO Online browsing platform: available at https://www.iso.org/obp
— — IEC Electropedia: available at https://www.electropedia.org/
4 Abbreviated terms
API application programming interface
app application
ID identifier
IP internet protocol
MIME multipurpose internet mail extensions
Further abbreviations as defined in ISO 17978-1 are also applied in this document.
5 Use cases
5.1 General
An SOVD entity is an instance, internal or external to the vehicle with which an SOVD client can interact. An
SOVD entity can be:
— — a component (e.g. an electronic control unit, smartphone used to unlock the vehicle),
— — an app (e.g. a software application),
— — an area (e.g. powertrain) or
— — a function (representing a functional view).
1 1)
SOVD entities are defined in ISO 17978-3:— , , 5.3. They can be physical, functional or logical.
NOTE 1 System-specific names for entities are not defined in the ISO 17987 series.
NOTE 2 To maintain readability, the use case descriptions and the examples in Clause 5Clause 5 cover only the
successful answers to requests. ISO 17978-3:—, 5.8 describes also the responses to various error conditions. Use case
specific responses for error conditions are mentioned in the respective API definitions clauses.
NOTE 3 Depending on a use-case an entity can describe different perimeters.
NOTE 4: The entity perimeter is defined by the ExVe (Extended Vehicleextended vehicle) manufacturer for each use
case.
For detailed examples and descriptions, please refer to ISO 17978-3.

First edition under preparation. Stage at the time of publication: ISO/DIS 17987-3:2025.
1)
First edition under preparation. Stage at the time of publication: ISO/PRF 17987-3:2026.

Key
Use case
Figure 2 — Term dependencies
Figure 2Figure 2 shows how use cases can be used for use case clusters as defined in the ISO 20077 series. The
SOVD use cases described in this document can be used to contribute to those use case clusters.
5.2 Use case 01 – Discover SOVD server(s)
Table 1Table 1 defines the use case 01 – Discover SOVD server(s).
Table 1 — Use case 01 – Discover SOVD server(s)
Title Use case 01 – Discover SOVD server(s)
Goal Discover which SOVD servers are available and thus prepare for communicating with them.
— — Prerequisite: the SOVD server and client are in the same IP subnet. Both have valid
Input
IP addresses.
NOTE 1 How this is achieved is not in scope of ISO 17978 series.
— — The client issues commands to check for:
— — servers supporting SOVD,;
— — their corresponding SOVD interfaces (IP hostname and port).
Output If applicable, the SOVD server replies with the identity of the vehicle, the access URL and the IP
address and port. The SOVD server might also reply with error information.
Description The SOVD client (tester) issues a request to the local IP subnet. Available SOVD servers identify
themselves and provide their communication details on request.
This use case is basic as a pre-step for finding SOVD servers and establishing SOVD
communication. Therefore, it is mandatory to be implemented.
NOTE 2 This use case applies only to a scenario where the SOVD server is located in the
same IP subnet as the tester/client.
Examples Request: Which server(s) in the current subnet support SOVD?
Response: Instance names ABC123456789-1; ABC123456789-2 …
Request: Which port does SOVD use on the server "ABC123456789-1"?
Response: SOVD can be reached at ABC123456789.local.:9999
5.3 Use Case 02 – Discover entities
Table 2Table 2 defines the use case 02 – Discover entities.
Table 2 — Use Case 02 – Discover entities
Title Use Case 02 – Discover entities
Goal Discover which entities and resources are available.
— — API call to discover entities
Input
— — Type of entities to be discovered (e.g. component, area or app)
— — Available entities of the requested type
Output
— — Information if request was not successful
Description The SOVD client (tester) requests a list of entities which match a given type.
In the response, a list of URIs pointing to the entities is provided.
Examples Request: Get available components
Response: List containing available components
5.4 Use case 03 – Authenticate and authorize SOVD clients
Table 3Table 3 defines the use case 03 – authenticateAuthenticate and authorize SOVD clients.
Table 3 — Use case 03 – Authenticate and authorize SOVD clients
Title Use case 03 – Authenticate and authorise SOVD clients
Goal Enable an authorization and validation process to protect the resources of any accessible entity
in a vehicle against misuse of features while accessing an SOVD server.
Input Authentication and authorization information
— — E.g. token which can be attached to SOVD requests
Output
— — Information if request was not successful
Description An authorization server (which might be located in a backend) authenticates the SOVD client
and issues, e.g. an access token representing the access level of the SOVD client. The access
token is validated by the SOVD server when making an API request.
NOTE A variant of this without a backend server is also available but not explained
here for the purpose of readability.
5.5 Use case 04 – Read fault(s) and/or its details from an entity
Table 4Table 4 defines the use case 04 – Read fault(s) and/or its details from an entity.
Table 4 — Use case 04 – Read fault(s) and/or its details from an entity
Title Use case 04 – Read fault(s) and/or its details from an entity
Goal Retrieve faults which have been detected by an entity and which match given filter parameters.
If requested, provide details for a fault (e.g. environment data).
— — API call to read faults or fault details
Input
— — Entity
— — Filter parameters like status, severity, scope
— — List of faults matching the given query
Output
— — Details for a fault (if requested)
— — Fault metadata like status, name, translation id, etc.
— — Meta information (if requested)
— — Information if request was not successful
Description The SOVD client (tester) requests a list of faults which have been detected by a specific entity.
The client can provide filter parameters (see input) which are used for narrowing down the list
of results. The SOVD client (tester) can also request the details for a given fault code.
In the response, a list of matching faults or the fault detail information is provided (see output).
Examples Request: Get the faults of the component “camera” which have set the status “active”
Response: A list with the faults matching the given criteria
Request: Get the details for fault 123E in entity AdvancedLaneKeeping
Response: Detailed information on the fault 123E
5.6 Use case 05 – Delete fault(s) of an entity
Table 5Table 5 defines the use case 05 – Delete fault(s) of an entity.
Table 5 — Use case 05 – Delete fault(s) of an entity
Title Use case 05 – Delete fault(s) of an entity
Goal Delete all fault entries or a singular fault entry of an entity
— — API call to delete faults
Input
— — Fault entry (if only one fault shall be deleted)
Output Success or information if request was not successful
Description The SOVD client (tester) requests to delete all fault entries or a singular fault entry in one entity.
The response contains information on whether this was successful or not.
Examples Request: Delete the faults in the component “Camera”
Response: Success
Request: Delete the fault “modelMissing” in the app “AdvancedLaneKeeping“
Response: Success
5.7 Use case 06 – Read data resources
Table 6Table 6 defines the use case 06 – Read data resources.
Table 6 — Use case 06 – Read data resources
Title Use case 06 – Read data resources
Goal Read different data items from an entity. Multiple or singular items might be read at a time.
— — API call to read data items
Input
— — Entity
— — The identifier for the data item(s) to be read
— — Values of the data items
Output
— — Meta information (if requested)
— — Information if request was not successful
Description The SOVD client (tester) requests data values to be read.
In the response, the values are provided.
Examples Request: Get the data for the “RearWindows“ of the app “WindowControl”
Response: Values of the data items matching the request criteria
5.8 Use case 07 – Write data items
Table 7Table 7 defines the use cas
...