ISO/PRF 17978-3

ISO/DISPRF 17978-3:2025(en)
ISO/TC 22/SC 31
Secretariat: DIN
Date: 2025-11-252026-01-15
Road vehicles — Service-oriented vehicle diagnostics (SOVD) —
Part 3:
Application programming interface (API)
Véhicules routiers — Diagnostic Véhicule Orienté Services (SOVD) —
Partie 3: Interface de Programmation D’applications (API)
This document is the "single source" ISO/CS
DIS Enquiry Word (en) document with DIS
Voting Comments Resolution
implementation!
PROOF
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 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. Phone: + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 3
4 Symbols and abbreviated terms . 3
5 SOVD API general aspects . 5
6 Capability description . 31
7 SOVD REST API . 41
8 Classic diagnostic adapter . 269
Annex A (normative) Access to legally required diagnostics . 274
Annex B (informative) SOVD API common example . 277
Bibliography . 294

iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types of
ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent rights
in respect thereof. As of the date of publication of this document, ISO had not received notice of (a) patent(s)
which may be required to implement this document. However, implementers are cautioned that this may not
represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 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
traditional electronic and electrical vehicle architectures. Besides classical distributed embedded electronic
control unit (ECU) architectures, domain- 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. This includes
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. Further aspects are:
— — faster release and update cycles,;
— — increased requirements such as data protection and cybersecurity,;
— — state-of-the-art diagnostic 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 1Figure 1 shows the OSI layers of the ISO 17978 series.
v
Key
a communication protocol
b network technology depending on electric/electronic (E/E) vehicle network architecture
vi
a
Communication protocol.
b
Network technology depending on electric/electronic (E/E) vehicle network architecture.
Figure 1 — OSI layers of SOVD
For the convenience of the user, a machine-readable OpenAPI definition of the methods is published alongside
this document in the ISO Standards Maintenance Portal: https://standards.iso.org/iso/17978/-3/ed-1/en .
NOTE This document marks some API methods as deprecated. The background to this is the release of ASAM SOVD
version 1.0 in calendar year 2022.
vii
Road vehicles — Service-oriented vehicle diagnostics (SOVD) —
Part 3:
Application programming interface (API)
1 Scope
This document defines an application programming interface (API) which standardizes the methods for
diagnosing HPCs and legacy ECUs, the retrieval of the diagnostic capabilities, and the discovery of the service-
oriented vehicle diagnostics (SOVD) methods in an extended vehicle. The SOVD API provides a unified access
to classic ECUs and HPCs.
The SOVD API provides functions such as:
— — access to the faults, including reading the fault entries, reading environment data, and deleting fault
entries,;
— — measurements and identifications of all entities,;
— — execution of routines, input/output (I/O) controls and software functions in certain modes or states,;
— — configuration of a vehicle (e.g. equipment, country, customer demand, variant coding),);
— — encapsulation of the ExVe manufacturer specific software update strategy (including firmware over
the air (FOTA) if available),);
— — access to logging information of an HPC.
With these features, SOVD can cover all areas of the vehicle life cycle which includes in particular, including
engineering (development), manufacturing (production), after sales (maintenance and repair), legal and
technical inspections, and vehicle operation (use).
There are several aspects which are not covered by this document, as they are specific to the implementation
of an SOVD server, for example:
— — prevention and quick reaction to attack vectors like denial of service, zero-day exploits of
vulnerabilities,;
— — recognition of security incidents,;
— — maintaining the operational safety based on data monitoring,;
— — management of security incidents,;
— — data privacy issues,;
— — load balancing of concurrent requests.
[5]
In accordance with the extended vehicle concept, defined in the ISO 20077 series , the SOVD API or its
components may reside inside or outside the physical vehicle.
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 8601--1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
th th 1)
ECMA 262: 16 16, edition, ECMAScript general-purpose programming language
REST:. Architectural Styles and the Design of Network-based Software Architectures, PhD dissertation Fielding
2)
R.T., University of California, Irvine,2000
3)
HTML Server-Sent Events API
IETF RFC 1341, MIME (Multipurpose Internet Mail Extensions)
IETF RFC 1847:1995, Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted; 1995
IETF RFC 3339:2002, Date and Time on the Internet: Timestamps; 2002
IETF RFC 3986:2005, Uniform Resource Identifier (URI): Generic Syntax; 2005
IETF RFC 5322:2008, Internet Message Format; 2008
IETF RFC 6570:2012, URI Template; 2012
IETF RFC 6762:2013, Multicast DNS; 2013
IETF RFC 6763:2013, DNS-Based Service Discovery; 2013
IETF RFC 7540:2015, Hypertext Transfer Protocol Version 2 (HTTP/2); 2015)
IETF RFC 8259:2017, The JavaScript Object Notation (JSON) Data Interchange Format; 2017
IETF RFC 9110:2022, HTTP Semantics; 2022
IETF RFC 9562:2024, Universally Unique IDentifiers (UUIDs); 2024)
NodeJS, Semantic Versioning Range Definition [viewed 2024-04-15]
4)
Open API Initiative, OpenAPI Specification v3.1.0; 2021
OpenJS Foundation, JSON Schema 2020-12 Release Notes. [viewed 2024-04-15]
Semantic, Versioning 2.0.0 [viewed 2024-11-18]

1)
Available at:
2)
Available at:
3)
Available at:
4)
https://standards.iso.org/iso/17978/-3/
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminologicyterminology 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 3.1
application
App
app
entity (3.5(3.5)) representing a software program that performs a specific task
3.2 3.2
area
entity (3.5(3.5)) representing a logical view on vehicle topologies
3.3 3.3
ContributingEntity
abstract entity (3.5(3.5)) that describes relationships like hosts, is-located-on, contains, depends-on, belongs-
to to represent dependencies between specialized entities app (3.1(3.1),), area (3.2(3.2),), component
(3.4(3.4),), and function (3.6(3.6).)
3.4 3.4
component
entity (3.5(3.5)) representing hardware (characterized by the availability of a central processing unit (CPU)))
or software (characterized by the availability of an operating system or hypervisor), or a combination of both
3.5 3.5
entity
object combining logically interrelated diagnostic information represented in the form of resources
Note 1 to entry: entity (3.5(3.5)) is an abstract base class. The specific entities describe a diagnostic view of the vehicle.
Note 2 to entry: The term entity (3.5(3.5)) used in the context of this document refers to "SOVD entity” (see ISO 17978-
2).
3.6 3.6
function
entity (3.5(3.5)) representing a functional view on vehicle information spread across components (3.4(3.4))
3.7 3.7
SOVDServer
entity (3.5(3.5)) representing the server-side implementation of the representational state transfer (REST)
API services
4 Symbols and abbreviated terms
4.1 Symbols
— empty table cell
4.2 Abbreviated terms
AI artificial intelligence
App application
AUTOSAR_DLT AUTOSAR Specification of Diagnostic Log and Trace
C conditional
CDA classic diagnostic adapter
CPU central processing unit
DHCP dynamic host configuration protocol
DLT diagnostic log and trace
DNS domain name system
DNS-SD DNS service discovery
E/E electric/electronic
ePTI electronic Periodic Technical Inspection
ExVe extended vehicle
FOTA firmware over the air
HPC high performance computer
HTML hypertext markup language
HTTP hypertext transfer protocol
HTTPs HTTP secure
IETF internet engineering task force
IP internet protocol
JSON java script object notation
M mandatory
MD5 message-digest algorithm 5
mDNS multicast domain name system
MIME multipurpose internet mail extensions
O optional
OBD onboard diagnostics
REST representational state transfer
SHA256 secure hash algorithm 256
SSE server-sent events
TCP transmission control protocol
TLS transport layer security
TXT text strings
UML unified modeling language
URI uniform resource identifier
URL uniform resource locator
UUID universally unique identifier
VIN vehicle identification number
XML extensible markup language
YAML yet another markup language
5 SOVD API general aspects
5.1 Use cases overview
In accordance with the extended vehicle concept, defined in the ISO 20077 series, the SOVD API or its
components may reside inside or outside the physical vehicle.
[4]
ISO 17978-2 defines use cases. For information, Table 1Table 1 shows a mapping of those use cases to the
API method calls as defined in this standard.
Table 1 — Mapping of ISO 17978-2 use cases to ISO 17978-3 API method calls
ISO 17978-2 ISO 17978-2 use case title ISO 17978-3 API subclause(s)
use case # implementing this use case
01 Discover SOVD server(s) 5.115.11
02 Discover entities 7.67.6
03 Authenticate SOVD clients 7.237.23
04 Read fault(s) and/or its details from an entity 7.8.1, 7.8.27.8.1, 7.8.2, 7.8.3, 7.8.3
05 Delete fault(s) of an entity 7.8.47.8.4, 7.8.5, 7.8.5
06 Read data resources 7.9.1, 7.9.2, 7.9.3, 7.9.47.9.1, 7.9.2,
7.9.3, 7.9.4, 7.9.5, 7.9.5
07 Write data items 7.9.67.9.6
08 Control operations 7.147.14
09 Read and write configurations 7.127.12
10 Control software updates 7.187.18
11 Handle bulk data 7.207.20
12 Control logging and retrieve logs 7.217.21
13 Control communication logging 7.227.22
14 Manage and execute scripts 7.157.15
15 Manage triggers and subscriptions 7.107.10, 7.11, 7.11
16 Query an online capability description 6.3.36.3.3, 7.5, 7.5
17 Provide an offline capability description 6.3.26.3.2
5.2 Accessing the API
5.2.1 HTTP REST based approach
The SOVD API uses the following standards and technologies.
— — The API shall follow REST: Architectural Styles and the Design of Network-based Software
Architectures principles and shall follow IETF RFC 8259 for the use of JSON for encoding the transmitted
data.
— — SOVD shall follow HTTP/1.1 in accordance with IETF RFC 9110 or, for achieving the best
communication performance, HTTP/2 in accordance with IETF RFC 7540 Hypertext Transfer Protocol
Version 2 is recommended. No HTTP/2 specific features are used.
— — The SOVD API shall follow the Open API Initiative, OpenAPI Specification v3.1.0; 2021 to define the
API as well as the diagnostic capabilities of the vehicle.
— — It is recommended to build authentication and authorization upon OpenID Connect and OAuth 2.0 in
[22] [21] [23]
accordance with IETF RFC 8693 ,, IETF RFC 6749 and IETF RFC 6750 ,, but an ExVe manufacturer
may use other authentication mechanism like certificates if required.
Based on REST principles, the diagnostic content is provided in the form of resources.
A resource is accessible via its specific resource path. In SOVD, the resource path is composed of the path to
the individual entity (see 5.35.3)) and the standardized resources and resource collections provided for that
entity (see 5.45.4).).
The operations available for the individual diagnostic content are represented using HTTP methods.
Table 2Table 2 shows the HTTP methods used by SOVD.
Table 2 — HTTP methods of the SOVD API
HTTP method Purpose
GET
Reading content from a resource
PUT
Update content of a resource (e.g. by writing a new value)
POST
Creation of new (temporary) resources
DELETE
Deletion of created resources, resetting content to default
OPTIONS
The server returns the HTTP methods that are supported for a particular resource
An SOVD server shall support the method OPTIONS on each resource to inform a client about the supported
methods. By this a client can determine which functionality (e.g. writing a data value) is supported for a
specific resource. For example, for the following data resource representing the software identification of an
ECU, the SOVD server returns that only the GET method is supported, besides OPTIONS.
Request:
OPTIONS {base_uri}/apps/WindowControl/data/swVersion HTTP/1.1

Response:
HTTP/1.1 204 No Content
Allow: OPTIONS, GET
The example in Figure 2Figure 2 illustrates the REST based approach used by SOVD.
The example shows a software application in the vehicle providing functionality to access information about
the windows, for example it offers information about the “RearWindows” positions.
Figure 2 — WindowControl application example
In terms of SOVD this is implemented by providing an SOVD entity “WindowControl” containing the leaf
resource “RearWindows”, which can be read using a GET operation.
The path elements “apps” and “data” of the resource path in the following example is explained in 5.35.3 and
5.45.4.
EXAMPLE
Request:
GET {base_uri}/apps/WindowControl/data/RearWindows HTTP/1.1

5.2.2 Server-sent events
5.2.2.1 General
For pushing content from an SOVD server to an SOVD client the SOVD API shall follow the HTML server-sent
event mechanism as specified within the EventSource API (see HTML, server-sent-events).
The update of content is realized by an HTTP connection which is kept alive. The response is incrementally
appended by new events, where each new event represents a new set of content. Examples for this mechanism
are the cyclic reception (7.10(7.10)) or the trigger-based reception (7.11(7.11)) of data.
The server-sent events mechanism is used in the API method for retrieving content in increments. The setup
of the URI, which provides the server-sent events stream is covered in the subclauses of the respective use
cases. A server should detect lost clients via the server-sent event stream. The handling of this scenario is also
covered by the respective use cases.
HTML, server-sent-events specifies the JavaScript API EventSource and the HTTP mechanism server-sent
events. For SOVD only the specification of server-sent events shall be followed. While SOVD client and server
shall adhere to the specification of server-sent events, the client API is an implementation detail not covered
by this document.
5.2.2.2 Retrieving payload in increments
Method:
GET {event-stream-uri}
Method description:
This method establishes a server-sent event stream to enable pushing of payload from an SOVD server to
an SOVD client.
Path parameters:
Table 3Table 3 specifies the path parameters to retrieve payload in increments.
Table 3 — Path parameters — Retrieving payload in increments
Parameter name Type Convention Description
event-stream-uri string
M URI of the server-sent event stream.
Query parameters:
This method does not support query parameters.
Request headers:
This method does not use specific header parameters.
Response headers:
Connection: keep-alive
Content-Type: text/event-stream

Response status codes:
Table 4Table 4 specifies the response status codes to retrieve payload in increments.
Table 4 — Response status codes — Retrieving payload in increments
Status code Response body Description
— The request was successful.
Response body:
The response body shall follow the Server-Sent Event mechanism (see HTML, Server-sent-events). Each
event shall represent new content. Each event shall be transmitted using the EventEnvelope type (see
Table 5Table 5).). Only the event stream attribute data shall be used to transmit new content.
The SOVD attribute schema shall not be included in an event stream as it is provided upon creation of the
subscription resource (e.g. cyclic subscription or trigger resource). The event stream attribute event shall
not be used by SOVD as only one type of event is supported.
Table 5Table 5 specifies the EventEnvelope type.
Table 5 — EventEnvelope type
Attribute Type Convention Description
timestamp string:date-
M Absolute timestamp when the value has been read by the
time
SOVD server (UTC time).
a
payload AnyValue
C1 The subject of the incremental update. This depends on
the setup of the underlying use case (e.g. cyclic
subscription or trigger resource)
b
error GenericError
The error returned by the underlying resource. The error
C2
(see Table 16Table shall be semantically equivalent to an atomic request on
the resource. The attribute http_code inside
16))
parameters should be used to express the corresponding
HTTP error if applicable.
If an error has been returned, the client can still receive
successful responses afterwards depending on the
resource.
NOTE Partial errors (e.g. one value from a
data response had error) are part of the payload as
the resource’s response was in general successful.
a C : the underlying resource successfully provides payload.
b C2: the provision of payload from the underlying response was erroneous.
Example:
Request:
GET {base_uri}/apps/WindowControl/cyclic-subscriptions/
7ab52f10-5ea9-4610-a1de-f45ec8265ce4/events HTTP/1.1

Response:
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream

data: {
data:  "timestamp":"2023-04-03T16:09:53Z",
data:  "payload": {
data:   "id": "RearWindows",
data:   "data": {
data:    "PositionLeft": 100,
data:    "PositionRight": 0
data:   }
data:  }
data: }
data: {
data:  "timestamp":"2023-04-03T16:10:23Z",
data:  "payload": {
data:   "id": "RearWindows",
data:   "data": {
data:    "PositionLeft": 75,
data:    "PositionRight": 50
data:   }
data:  }
data: }
data: .
5.2.2.3 Unsubscribe from an event source
The client closes its connection to the event source by executing the close method on the EventSource
object. Closing the connection does not make the server delete the subscription resource, as other clients are
using the same subscription.
NOTE Due to the nature of SSE, other clients connected to the same event source continue to receive events as usual.
Example:
evtSource = new EventSource("{response.subscription}");

// Process responses
evtSource.onmessage = (event) => {
console.log(event.data.timestamp); // 2021-07-20T
00:00:04.387819Z
payload = event.data.payload;
console.log(payload.id); // RearWindows
console.log(payload.data.PositionLeft); // 100
}
}
// Close event source
evtSource.close();
5.3 Entities
5.3.1 General
The SOVD API defines entities holding diagnostic content. To access diagnostic content, an SOVD client shall
specify the entity it wants to interact with. This subclause covers entity types, the hierarchy, and how to
reference the entity in a method request.
5.3.2 EntityTypes and collections
This document defines entity types as shown in Figure 3Figure 3. entity types are defined flexibly enough to
support various topologies and diagnostic strategies. Entities of same type are grouped within entity
collections under the SOVD server. SOVD entities hold the diagnostic content as resources. Resource
collections available for an entity type are defined in 5.4.25.4.2.

Figure 3 — EntityType overview
Table 6Table 6 specifies the different EntityType in more detail.
Table 6 — Details of EntityType
EntityType EntityCollectionType Description
—
SOVDServer An SOVDServer represents the entry point of the API structure.
Resources on that level are related to all entity managed by the SOVD
server. For further detail see Table 53Table 53.
areas
area An area represents a logical view and can be used to describe various
vehicle topologies, e.g. domain architectures (body control,
infotainment, powertrain), zone architectures (front, rear), or logical
architectures in the context of a software defined vehicle.
components
component A component is a representation of hardware or software. A component
can also represent a combination of both (e.g. ECU with basic software).
components representing hardware are characterized by the
availability of a CPU and execute software. Examples are HPCs, ECUs,
and Smart sensors.
Software as part of components is characterized as basic software
required to execute apps. Examples for basic software are operating
systems, or Hypervisor.
Only software components or components containing software parts
shall link to apps.
EntityType EntityCollectionType Description
apps
app An app represents an application executed on a component, e.g.
Advanced-Lane-Keeping or Window Control.
functions
function A function represents a functional view and allows an ExVe
manufacturer to define access to diagnostic information, which can be
spread across several contributing entities.
NOTE This document defines no further details for the
handling of functions.
The REST approach limits access to a single resource per request. To
accumulate values from multiple entities with a single requests
functions may be used. Annex B.5 shows an example of a function entity
“VehicleHealth” to retrieve a list of faults from multiple components
along with HW and SW version numbers.
From an API perspective, there is no differentiation between hardware and software components.
5.3.3 entityEntity hierarchy and relations
The entity defined can be used to build a hierarchy for the SOVD API. Figure 4Figure 4 depicts the standardized
entity hierarchy. The entry point into this structure is the SOVD server. For simplicity of Figure 4Figure 4,, the
{entity-collection}s are not shown as separate classes but can be seen from the name of the respective
association ends.
Key
can be used in
can not be used in

can be used in
can not be used in

Figure 4 — entity — Entity hierarchy
A component can have multiple subcomponents, which themselves are components and thus can have
subcomponents. components on all levels can have links to apps (identified by the relation hosts). This
information can be used by an SOVD client to present all apps running on a component. An app itself can
provide the information about which component it is located on using the relation is-located-on.
Some SOVD entities may depend on other entities, e.g. an application may depend on information provided by
another application. By introducing the abstract parent class ContributingEntity as well as the relationship
depends-on, this dependency can be modelled for all entities extending ContributingEntity, namely entities
of type component, app, and function.
Using the dependency contains of an area to a ContributingEntity both physical and logical hierarchies can
be represented. The same applies for the opposite possibility of a ContributingEntity to provide the area it
belongs-to.
An area can have multiple subareas, which themselves are areas and thus can have subareas.
In addition, the depends-on relation from a function to a ContributingEntity can be used to represent which
entities contribute to a certain function.
5.3.4 entityEntity identifier and path
An entity identifier uniquely identifies an entity for a given SOVD server on a single level in the hierarchy. A
sub-entity may have the same identifier as the parent entity, as they reside on different hierarchy levels. This
document does not define entity identifiers.
Every entity is accessible via its entity-path. The entity path is built from the element’s
EntityCollectionType (see Table 6Table 6),), and the entity identifier.
The path elements are separated by a forward-slash (‘/’). In case of a sub level entity all path elements are
concatenated.
Example for entity-path:
components/DrivingComputer
components/DrivingComputer/subcomponents/Linux
5.3.5 Location of the SOVD server
The location of the SOVD server is defined by the vehicle manufacturer. It can be located inside the vehicle as
well as outside the vehicle to provide an SOVD interface also for legacy vehicles.
5.3.6 Multi-SOVD server environments
5.3.6.1 General
This document neither defines nor demands a specific architecture within an ExVe. It is intended to support
multiple kinds of architectures, including multiple SOVD servers for a single ExVe.
It is strongly recommended, that each entity for an ExVe is bound to and can only be accessed through a
dedicated SOVD server (see 5.3.25.3.2).). An SOVD server can be public, meaning accessible from outside; or
private, meaning it is not accessible from the outside.
5.3.6.2 Public SOVD server
Each public SOVD server is directly accessible from the outside through connectivity. It is outside the scope of
this document to provide identification of a public SOVD server for remote SOVD clients. For co-located clients,
the identification method as described in 5.115.11 shall be used. Figure 5Figure 5 shows an example with
three public SOVD servers.
Figure 5 — Public SOVD server
5.3.6.3 Private SOVD server
An SOVD server may be limited to internal access within the ExVe, allowing communication only with SOVD
clients inside the ExVe. This includes access to legacy ECUs through an SOVD server’s classic diagnostic
adapter (CDA). If diagnostic information provided by such a private SOVD server is intended to be made
available outside the ExVe, access shall be routed via a public SOVD server. Figure 6Figure 6 shows an example
with one public and one private SOVD server.

Figure 6 — Private SOVD server
5.4 Resources
5.4.1 General
Each entity provides its diagnostic content in the form of resources at the SOVD API. These resources are
accessible either at entity-level or via their respective resource collections depending on the underlying type
of diagnostic content they provide.
Annex B.3.3 B.3.3 shows an example for resource collection data containing resources of type data.
This subclause describes the standardized resource types, how they are organized into collections, and which
are available for a specific entity type.
Constraints:
— — A resource shall only be accessible via a single path.
— — Access shall only be provided to an entire resource. It shall not be possible to access parts of a resource
by means of filters, e.g. a single parameter of a data or configuration resource.
— — A resource shall only be available on the entity that represents the diagnostic content. An entity other
than function shall not aggregate resources which are held by e.g. subcomponents.
5.4.2 Standardized resource collections
Table 7Table 7 specifies the standardized resource collections for SOVD. This resource collection classification
helps a generic tester to present the resources of different types in a specific way. Each resource collection can
be queried for its contained resources.
Table 7 — Standardized resource collections
Resource collection Description
configurations
collection of configuration resources
bulk-data
collection of bulk data resources for the respective BulkDataCategory (see
Table 293Table 293))
communication-logs
collection of communication logs
cyclic-subscriptions
collection of cyclic subscription resources
data
collection of static and dynamic data resources
data-lists
collection of combined data resources
faults
collection of fault resources
operations
collection of operation resources
updates
collection of update package resources
modes
collection of mode resources
locks
collection of lock resources
triggers
collection of trigger resources
scripts
collection of script resources
Table 8Table 8 gives an overview on which resource collections are allowed on which entity type.
Table 8 — Relation between entities and resource collections
entity level co cycl
bul mm ic- con dat
ope trig
k- uni sub figu dat a- faul loc mo scri upd
rati ger
dat cati scri rati a list ts ks des pts ates
ons s
a on- ptio ons s
logs ns
a a a a
SOVDServer X X X X X X X X X X X X X
area not supported by this document
component X X X X X X X X X X X X X
app X X X X X X X X X X X X X
function not supported by this document
entity level co cycl
bul mm ic- con dat
ope trig
k- uni sub figu dat a- faul loc mo scri upd
rati ger
dat cati scri rati a list ts ks des pts ates
ons s
a on- ptio ons s
logs ns
a It is strongly recommended that resource collections on an SOVDServer level do not aggregate resources from entities
underneath.
5.4.3 Standardized resources
Table 9Table 9 defines the resource names for an entity.
Table 9 — Standardized resource names
Name Description
docs provides the online capability description
version-info provides supported SOVD API versions
logs access to logging information
related-apps DEPRECATED
apps hosted on a component
related-components DEPRECATED
components related to an area
data-categories categories (currentData, identData, .) used within data resource collections
data-groups groups used to structure data in a specific way (e.g. engine performance related, .)
authorize initiate authentication and authorization with the vehicle
token request token from the vehicle for authorization
is-located-on provides the information that an app is located on a certain component
hosts provides the information about which apps are hosted on a certain component
contains provides the information about which ContributingEntities are contained in an area
belongs-to provides the information about which area a ContributingEntity belongs to
depends-on provides information about ContributingEntities on which a ContributingEntity depends on
clear-data clears temporary data of an entity
Table 10Table 10 provides an overview, which resource is allowed to be used on which entity type.
Table 10 — Relation between entities and resources
EntityType dat
ver is- dep dat
con bel a- aut
doc sio loca hos end a- tok
logs tain ong cate hor
s n- ted- ts s- gro en
s s-to gori ize
info on on ups
es
a a a
SOVDServer X X X — — — X X X X X X
a b a a a a b b b b
area X — — — — X — — — — — —
a a a b b
component X — X — X — X X X X — —
EntityType dat
ver is- dep dat
con bel a- aut
doc sio loca hos end a- tok
logs tain ong cate hor
s n- ted- ts s- gro en
s s-to gori ize
info on on ups
es
a a a b b
app X — X X — — X X X X — —
a b a a a a b b b b
function X — — — — — — X — — — —
a not allowed
b not supported by this document
Resources, which are created by an SOVD client by usage of the SOVD API are considered “temporary”.
Consequently, they are not available in a capability description.
NOTE An example of resources and resource collections is shown in Annex BAnnex B.
5.4.4 Restricting access to entities and resources by authentication
The SOVD server shall ensure the protection of all entities and resources against unauthorized access. This
standard does not define if a client is eligible to connect to the SOVD server, how an SOVD client shall perform
an authorization, or which concept is used to define which client can access which entity or resource. 7.237.23
informally describes an implementation based on OAuth and TLS.
Entities and resources may be accessible without prior authorization, e.g. a server may allow any eligible client
to read fault codes and identifications. For all entities, resources, and methods which require authorization,
the SOVD server shall only grant access to a client that has been both, authenticated and authorized. For SOVD
methods that enumerate resources (e.g. data-lists, subcomponents, .)) or event sources that send resource
content (e.g. cyclic subscriptions, triggers), the server shall ensure that the client does not receive information
about resources they are not authorized to access. In such cases, the server may filter out the inaccessible
resources. For temporary resources, the SOVD server defines if the access is restricted to the client which
created the temporary resource or if other clients can access the temporary resource as well or if the
authorization requirements from the parent resource are inherited.
5.4.5 Custom specific resource collections and types
Additional custom resource types, collections, and top-level-resources may be defined. The naming
convention x-- shall be followed for these custom extensions. Thereby ““ shall be a
unique identifier that leads back to the source of the custom extension to avoid conflicts with other potential
sources. The placeholder ““ shall be a unique identifier for the resource type or the collection type
within the namespace defined by ““. “x-sovd-“ shall never be used for this purpose and is reserved
by this document.
NOTE Since these resource collections and types are ExVe manufacturer specific, it cannot be assumed that a generic
SOVD client can automatically support this.
Example:
An ExVe manufacturer “Cop Cars” wants to introduce a new resource type “special”, which is accessible via a
new resource collection. To avoid a naming conflict with ExVe manufacturer “Spy Vehicles”, who also
introduced a resource type “special”, the resource collection for ExVe manufacturer “Cop Cars” could be named
x-cop-cars-specials and the resource type x-cop-cars-special. In this example, “cop-cars”
replaces “ext” and “specials” or “special” represents the “name”.
5.5 Illustration of SOVD concepts for entities and resources
Figure 7Figure 7 schematically shows the structure of an SOVDServer which contains two areas, three
components and one app as entities. For component 3 and app 1 Figure 7Figure 7 also shows the resource
collections and accessible resources.
NOTE To keep Figure 7Figure 7 simple, not all relations as defined by this document are displayed.
Solid lines are used to illustrate the single path for accessing specific information. The dashed lines show
related entities.
For resources data1, data2 and operation1 the URI for accessing them is provided.
Resources are located below entities. To better distinguish between entities and resources, resources are
represented by boxes with rounded corners.

Key
1 {base_uri}/components/Component3/data/data1
2 {base_uri}/components/Component3/data/data2
3 {base_uri}/components/Component3/operations/operation1
entity
area
component
app
resource collection
resource
direct access
related entity
1 {base_uri}/components/Component3/data/data1
2 {base_uri}/components/Component3/data/data2
3 {base_uri}/components/Component3/operations/operation1
entity
area
component
app
resource collection
resource
direct access
related entity
Figure 7 — Simplified illustration of the relationships between entities and resources
NOTE An example of entities, resources, resource collections are shown in Annex BAnnex B.
5.6 SOVD API versioning
The SOVD API uses URI based versioning. Thus, the version of the SOVD API is included in the URI. For this
document base_uri shall be defined as:

https://[/]/.

The mandatory path element shall express the host name in accordance with IETF
RFC 6763. The mandatory path element shall have the value “v1” for this version
of the document. The optional path element can be used to avoid
clashes in the URIs provided by ExVe HTTP servers.
-----------
...