SOVD – Service-Oriented Vehicle Diagnostics
The new SOVD standard is a modern approach to vehicle diagnostics in which diagnostic data and functions are provided as digital services.
It replaces conventional diagnostic solutions based on ISO standards such as UDS (14229) or MCD (ISO 22900-3) and provides extensive diagnostic options in the vehicle using modern WEB standards specified in ISO 17978.
This interface enables flexible access and easier integration into backends, cloud systems and the use of modern technologies such as big data, IoT or AI.
Motivation
The development of SDVs (software-defined vehicles) is being driven in particular by the introduction of EVs (electric vehicles) and the possibility of installing APPs in current vehicles and is placing new demands on vehicle diagnostics. In the future, APPs and vehicle functionalities realised as software will have to be diagnosed in addition to the classic control units (ECUs).
As there will still be a mixed installation of existing and new technology for at least the next few years, SOVD provides a standardised API that covers all use cases.
The introduction of HPCs (High Performance Computers) in the vehicle, which goes hand in hand with EVs and SDVs, makes it possible for the first time to relocate complete diagnostic scopes to the vehicle and make them available via the SOVD API.
Development of the standard at ASAM/ISO
The ASAM SOVD specification defines a standard that covers all vehicle diagnostics tasks, considering the current challenges. This essentially involves standardised access to the SOVD servers located in the vehicle. Conventional ECUs are covered by the use of the CDA (Classic Diagnostic Adapter) provided for in the SOVD standard.
- SOVD has been developed as a standard at ASAM e.V. since 2019
- SOVD was submitted to ISO as ASAM Version 1.0 as NWIP and adopted as a new ISO standard
- SOVD was submitted to ISO as ASAM version 1.1 at the end of 2024 and will undergo the usual process and be published as ISO 17978.
Experts from ACTIA IME GmbH were involved in the development and design of the SOVD standard via a working group of ASAM e.V. (Association for Standardisation of Automation and Measuring Systems) and continue to be active members of the working groups.
SOVD – Technical details
Key features of SOVD
Entity concept
All diagnostic endpoints in the vehicle are mapped using the entity concept in the SOVD standard. Entities are
- the SOVD server itself,
- Components (comparable with classic ECUs)
- APPs (software components of any kind)
- Areas (grouped areas, e.g. formerly the PowerTrain)
- Functions (functionally related entities -> requests that address multiple entities, e.g. vehicle health)
Resource concept
Each entity provides its diagnostic functionality via resources; these are defined in the SOVD standard 1.1:
- Data Read/Write
- Fault Handling
- Configuration
- Operations
- Handling of Bulk Data
- Restart
- Support of Target Modes
- Software Update
- Clearing Data
- Locking
- Cyclic Subscriptions
- Triggers
- Script Execution
- Logging
Capability description
The diagnostic functionalities available in an SOVD server are provided via the capability description. These are available in two central versions:
- Offline Capability Description
This contains the complete diagnostic description of a vehicle class, including all variants and installation options, and makes it available to a diagnostic author. - Online Capability Description
This contains the exact diagnostic data descriptions possible for the exact vehicle variant, including the software versions and configurations active there.
This means that the SOVD server in the vehicle knows its exact status and offers the appropriate diagnostics. This eliminates the need for the complex variant handling that was previously necessary.
This description is labelled as “optional” in the standard system and can be requested specifically and precisely for the resource/entity. - Optionally, the underlying schema can be requested for requests to a resource. This schema describes the exact structure of the returned resource.
Modern REST/JSON based API
In contrast to classic diagnostics, where diagnostic queries had to be set up and parameterised extensively and the diagnostic responses were also evaluated with a great deal of effort, the SOVD API is provided via modern WEB technologies.
A diagnostic request is sent to the SOVD server via a REST request; a simple GET-REST request is comparable to calling up a URL in a browser (e.g. http://sovd.actia.de/v1.0/components). In this case, the ACTIA SOVD demo server would return the list of available component entities. The REST requests are described using OPEN-API, a standard for describing APIs that originated from Swagger. In REST and therefore also in SOVD, it is possible to execute the calls as GET (get information), PUT/POST (send information) and DELETE (delete information).
The SOVD server responds in JSON format, which can be processed by both SOVD clients and any standard browser.
Discovery
SOVD servers include the ability to dynamically determine their presence in a network. This means that a diagnostic client can use mDNS (multicast DNS) to find out whether one or more SOVD servers are present and how they can be reached.
Software update
The SOVD standard offers the software update independently of a specific entity. This makes it possible to update individual components (formerly ECUs), several entities (i.e. components, APPs, ….) or even an entire vehicle with a new software version at once. To do this, the necessary software packages are registered with the SOVD server and then started. The current status and thus also the completion of a software update can be determined via the status query.
Use cases
This all sounds very simple and technically feasible, but it will certainly not be possible to stand next to a vehicle with a diagnostic client and carry out diagnostics. There are organised access scenarios for gaining access to the vehicle network and a distinction is made here between several use cases:
- In-Vehicle
Here, for example, an app or software function within the vehicle can access diagnostic information or trigger actions via the diagnostics. This has the enormous advantage that the information only must be requested and processed once by the SOVD server. Previously, the ECUs listened to or requested the messages on the bus system and had to implement the parameterisation and processing of the data (e.g. in the correct unit) themselves. - Remote
The diagnosis is carried out via a remote connection (backend). - Co-located
This use case covers the workshop case and is used when a diagnostic session needs to be supervised (e.g. when a hydraulic control is being carried out).
The SOVD standard deliberately leaves open which network channels are used to realise communication. An OEM can use its existing infrastructure for this purpose.
SOVD – Service-Oriented Vehicle Diagnostics at ACTIA
ACTIA is developing its own SOVD server in parallel with the creation of the specification at ASAM, which completes ACTIA’s portfolio of ISO diagnostic standards for the automotive industry.
The ACTIA SOVD server is based on an architecture that enables the SOVD server to be used both with a lean UDS client and in various combinations, including the complete integration of a D-Server or an OTX runtime. The CDA provided in the SOVD standard is used for this purpose. The SOVD OTX extension, which is also being developed at ASAM as part of ISO 13209, will in future be part of the OTX runtime and will in turn enable access to the SOVD API and therefore APPs, for example
At the same time, APPs can be addressed via the SOVD API using flexible interfaces. There are currently no standardised interfaces or diagnostic capabilities for APPs, which means that ACTIA’s concept lays the foundation for the integration of customer-specific APPs.
The following image shows an example of the integration of a complete diagnostic stack into the SOVD server.
This
integration makes it possible to utilise stable diagnostic protocols that have
been tried and tested in practice for years, especially to support special
control units or protocols that will still exist in the coming years, parallel
to the modern architectures. In addition, extensive automatic data conversion, e.g.
from ODX to SOVD capability, ensures that the new technology can be used
relatively quickly.
Even though
the SOVD server is intended for in-vehicle diagnostics as standard, ACTIA will
also offer the SOVD server in its VCIs in future, in addition to its use in
HPCs or telematics units, in order to provide standardised diagnostics,
especially in transition scenarios.
