Standards Development

Scope

This series of documents defines the use cases and their associated APIs for the SOVD and fall within the scope already defined by ISO 20077-1 "ExVe”.

The methodology adopted for the implementation of an SOVD API is intended to follow the definitions in ISO 20077 (all parts) regarding “Extended Vehicle (ExVe)” (definitions, basic principles, rules, uses cases, API, etc...).

It specifies the way to diagnose the vehicle via High Performance Computer (HPC) and Electronic Control Unit (ECU). The SOVD API provides, in the ExVe perimeter a unified access to ECUs and HPCs. This access can be performed remotely (e.g., backend or cloud), nearby in the repair shop (e.g., repair shop test equipment), or in the vehicle (e.g., on-board application). 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 in the perimeter of the Extended Vehicle:

• 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 provides an interface to initiate and monitor a software update for a vehicle

• SOVD provides access to Extended Vehicle logging information

With these features SOVD covers the entire chain of the vehicle life cycle: engineering (development), manufacturing (production), storage park, sales, vehicle operation (usage), maintenance and repair, technical inspection, recycling (re-use).

This document provides general information, specifies common definitions applicable for SOVD and defines overall rules and basic principles.

Purpose

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. Attached is the version 1.0 of the ASAM SOVD standard. This document serves as a starting point for the ISO work.

The following changes and additions to the ASAM document shall be considered during the ISO drafting process:

- The use cases in the SOVD draft shall be reviewed and checked for consistency with ExVe series documents. In order to produce consistent ISO work results, there shall be no conflicts between SOVD and ExVe documents.

- The SOVD standards shall make normative reference to the ExVe series of standards. Especially the methodology, the use cases, the terms and definitions as well as the basic principles of the ExVe series shall be considered in SOVD

- If applicable, new services or use cases should be considered in ISO20080 or a new ExVe use case document

- Add the following technical features: Extended logging API and publish/subscribe mechanisms

The standard shall be developed jointly between ASAM e. V. and ISO. In order to keep consistency, a proposal for the voting comments resolution should be provided by the ASAM experts through the ASAM liaison.

The following paragraph contains suggestions from the proposer to ensure a consistent work with a good quality:

The expertise needed for the project is (different aspect can be covered by different experts) - Diagnostic use cases and processes (covering the complete diagnostic process chain) -API design principles and technologies like REST, json, OAuth, http

ISO Experts are explicitly invited to contribute to SOVD and nominate experts.

It is proposed that the National member bodies distribute later drafts to the experts of TC22/SC31/WG2 as well as TC22/SC31/WG6. This will help to ensure that all relevant experts can contribute with voting comments. The comments resolution will be done under the lead of the working group which has the lead for the respective part.