Standards Development

Scope

This document defines an Application programmer Interface (API) for Service-Oriented Vehicle Diagnostics (SOVD). It specifies the methods for diagnosing High Performance Computer (HPC) and classic Electronic Control Unit (ECU), the retrieval of the diagnostic capabilities, and the discovery of the SOVD methods in a vehicle. The SOVD API provides a unified access to classic ECUs and HPCs. This access can be performed remotely (e.g., backend or cloud), in the repair shop (e.g., repair shop test equipment), or in the vehicle (e.g., on-board test equipment).

The SOVD API leverages existing technologies:

• The API follows the Representational State Transfer (REST) principles and uses Javascript Object Notation (JSON) for encoding the transmitted data.

• SOVD uses Hypertext Transfer Protocol (HTTP) 1.1 but for achieving the best communication performance HTTP/2 is recommended. No HTTP/2 specific features are used.

• The SOVD API utilizes the OpenAPI specification to define the API as well as the diagnostic capabilities of the vehicle.

• The authentication and authorization of clients builds upon OpenID Connect and Open Authentication (OAuth) 2.0, but a vehicle manufacturer may use other authentication mechanism like certificates if required.

The SOVD API provides the following functions:

• Clients can access the faults, including reading the fault entries, reading environment data, and deleting fault entries.

• Measurements and identifications from all entities in the vehicle can be read. In addition, identifications may be written as well.

• SOVD supports the execution of routines, I/O controls, and software functions. Their execution can only be performed in certain modes or states. Thus, an SOVD client can set the Component into a specific mode.

• The configuration of a vehicle (e.g., equipment, country, customer demand, variant coding etc.) can be read and written using the SOVD API.

• SOVD encapsulates the vehicle manufacturer specific software update strategy (incl. Firmware Over The Air (FOTA)) through a generic API.

• SOVD provides access to logging information of an HPC. With these features SOVD can cover all areas of the vehicle life cycle: Engineering (Development), Manufacturing (Production), After Sales, Vehicle operation (Use).

Purpose

URPOSE AND JUSTIFICATION Vehicle electronics topologies are changing rapidly. New functions e. g. autonomous driving require application-level software of high complexity to be executed within the vehicle. HPCs with considerable computing resources are found in many of the current vehicle platform designs. A HPC is a computing device within the vehicle that may feature multiple CPUs, and that is capable of hosting multiple virtualized guest systems based on operating systems like QNX, Linux, AUTOSAR Adaptive.

The introduction of HPCs in vehicles is associated with changes in the classical E/E vehicle architectures. While classical distributed embedded ECU architectures were used previously, domainor zone-based E/E architectures dominate today.

On HPCs, there will be an agile exchange of applications to enable new functionalities for the user. Since the HPCs can be compared to classic computers running numerous applications, this means that diagnostics are no longer limited to classic fault codes (DTCs with environment data). An analysis of the running programs is required in real operation. The diagnosis of these programs is comparable to the error and runtime analysis of software running on PCs. That means, it has the memory usage, processor load and number of active services that is required to be recorded, and therefore also log and trace files might be needed.

This shifts the focus from ECU diagnostics in today's vehicles from checking hardware to checking the software functionality of applications, which corresponds to a paradigm shift. All these topics result in new challenges regarding the management of the vehicle life cycle, which includes the diagnosis, (re-)configuring and re-programming of vehicle electronics.

New operating systems also no longer follow the classic rules for embedded systems, therefore, the diagnosis changes and adapts due to several factors, these include:

• Faster release and update cycles

• Increased requirements such as data protection, security

• State-of-the-Art diagnostic API using current information technologies.

The SOVD (service-oriented vehicle diagnostics) standard takes these points into account and provides a diagnostic API based on current IT technologies for the purpose of diagnosing vehicles with modern E/E architectures.

Consider the following:

Is there a verified market need for the proposal?

What problem does this document solve?

What value will the document bring to end-users?

See Annex C of the ISO/IEC Directives, Part 1 for more information.

See the following guidance on justification statements in the brochure ‘Guidance on New work’: https: //www.iso.org/publication/PUB100438.html