ISO 17978-2:2026

Road vehicles — Service-oriented vehicle diagnostics (SOVD) — Part 2: Use cases definition

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.

Véhicules routiers — Diagnostic Véhicule Orienté Services (SOVD) — Partie 2: Définition des cas d’usage

General Information

• Status: Published
• Publication Date: 08-Apr-2026
• ICS: 01.040.43 - Road vehicle engineering (Vocabularies)
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22 - Road vehicles
• Drafting Committee: ISO/TC 22 - Road vehicles
• Current Stage: 6060 - International Standard published
• Start Date: 09-Apr-2026
• Due Date: 17-Apr-2026
• Completion Date: 09-Apr-2026

Overview

ISO 17978-2:2026 – Road vehicles - Service-oriented vehicle diagnostics (SOVD) - Part 2: Use Cases Definition is an international standard developed by ISO for the automotive sector. It defines and documents typical service-oriented vehicle diagnostics (SOVD) use cases, focusing on the abstract description of these diagnostic interactions. The use cases are presented in a manner that is independent of specific underlying technologies, enabling broad applicability and interoperability across various implementations.

This standard is part of the ISO 17978 series, which aims to standardize the diagnostic interface for modern road vehicles, especially in the context of evolving automotive electronics and high-performance computing architectures.

Key Topics

• SOVD Use Case Catalog
  The document outlines a comprehensive set of 17 use cases relevant to service-oriented diagnostics in road vehicles. Each use case includes its name, required inputs and outputs, descriptions, and contextual examples.

• Abstraction from Technology
  Use cases are described generically to ensure that they remain agnostic to the specific technology stack, allowing various manufacturers and developers to implement diagnostic solutions suitable for their systems.

• Diagnostic API Methodology
  The use cases cover a range of diagnostic operations, such as discovery, authentication, fault management, data read/write, software updates, and bulk data handling, reflecting a modern, API-driven approach.

• Support for Vehicle Lifecycle
  The standard supports critical lifecycle activities like configuration management, software updates, dynamic logging, and vehicle health monitoring, addressing the increasing complexity of connected and software-intensive vehicles.

Applications

ISO 17978-2:2026 facilitates the development and integration of advanced diagnostics in road vehicles using a service-oriented architecture (SOA). This is especially relevant for:

• OEMs and Suppliers
  Automotive manufacturers and suppliers developing ECUs, vehicle networks, and diagnostics platforms benefit from a consistent, abstracted set of use cases for in-vehicle and external diagnostics.

• Tool Developers
  Providers of diagnostic tester tools and aftersales service equipment can implement standard APIs and workflows, increasing their compatibility across vehicle brands and models.

• Fleet Management and Telematics
  Fleet and mobility service providers can integrate diagnostic data collection, remote monitoring, and maintenance scheduling using standardized interfaces.

• Vehicle Software Updates
  Secure and efficient methods for updating vehicle software, managing configurations, and logging are detailed, supporting over-the-air (OTA) update strategies.

• Development and Quality Assurance
  Engineering teams use the defined use cases for test automation, logging, scripting, and simulation, streamlining the validation and commissioning of new vehicle features.

Related Standards

• ISO 17978-1:
  Road vehicles - Service-oriented vehicle diagnostics (SOVD) - Part 1: General information, definitions, rules and basic principles.

• ISO 17978-3:
  Road vehicles - Service-oriented vehicle diagnostics (SOVD) - Part 3: Application programming interface (API).

• ISO 20077 Series:
  Road vehicles - Extended vehicle (ExVe) methodology, supporting broader connected vehicle frameworks.

Summary of Benefits

By adopting ISO 17978-2:2026, automotive stakeholders can:

• Improve interoperability and integration of diagnostic systems
• Reduce development and maintenance costs through standardized procedures
• Enhance security, data protection, and lifecycle management of vehicle diagnostics
• Keep pace with shifting automotive architectures, including HPCs and domain-based systems
• Enable faster deployment of new features and ensure compliance with recognized international practices

Leverage ISO 17978-2:2026 to future-proof your vehicle diagnostics solutions in an increasingly connected mobility landscape.

Standards Content (Sample)

International
Standard
ISO 17978-2
First edition
Road vehicles — Service-oriented
2026-04
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
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Use cases . 2
5.1 General .2
5.2 Use case 01 – Discover SOVD server(s) .2
5.3 Use Case 02 – Discover entities .3
5.4 Use case 03 – Authenticate and authorize SOVD clients .3
5.5 Use case 04 – Read fault(s) and/or its details from an entity .4
5.6 Use case 05 – Delete fault(s) of an entity .4
5.7 Use case 06 – Read data resources .5
5.8 Use case 07 – Write data items .5
5.9 Use case 08 – Control operations .6
5.10 Use case 09 – Read and write configurations .6
5.11 Use case 10 – Control software updates .7
5.12 Use case 11 – Handle bulk data .8
5.13 Use case 12 – Control logging and retrieve logs .9
5.14 Use case 13 – Control communication logging .10
5.15 Use case 14 – Manage and execute scripts . .11
5.16 Use case 15 – Manage triggers and subscriptions . 13
5.17 Use case 16 – Query an online capability description .14
5.18 Use case 17 – Provide an offline capability description .14
Bibliography .16

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 documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO’s adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 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) in vehicles is associated with changes in the
classical electronic and electrical vehicle architecture. Besides classical distributed embedded electronic
control unit (ECU) 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) 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 1 shows the open systems interconnection (OSI) layers of the ISO 17978 series.

v
Key
a
Communication protocol.
b
Network technology depending on E/E vehicle network architecture.
Figure 1 — OSI layers of SOVD
vi
International Standard ISO 17978-2:2026(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 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).
SOVD entities are defined in ISO 17978-3:2026, 5.3. They can be physical, functional or logical.
NOTE 1 System-specific names for entities are not defined in the ISO 17978 series.
NOTE 2 To maintain readability, the use case descriptions and the examples in Clause 5 cover only the successful
answers to requests. ISO 17978-3:2026, 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 vehicle) manufacturer for each use case.
For detailed examples and descriptions, refer to ISO 17978-3.
Key
Use case
Figure 2 — Term dependencies
Figure 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 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.
Input — Prerequisite: the SOVD server and client are in the same IP subnet. Both have valid 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 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.
Input — API call to discover entities
— Type of entities to be discovered (e.g. component, area or app)
Output — Available entities of the requested type
— 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 3 defines the use case 03 – Authenticate 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
Output — E.g. token which can be attached to SOVD requests
— 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 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).
Input — API call to read faults or fault details
— Entity
— Filter parameters like status, severity, scope
Output — List of faults matching the given query
— 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 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
Input — API call to delete faults
— 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 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
...