Page navigation
- Beginning of the page
SOVD - Service-Oriented Vehicle Diagnostics
With the introduction of HPCs (High-Performance Computer) and thus increasingly software-based systems in future vehicles, diagnostics faces new challenges. The introduction of powerful computing systems with heterogeneous operating systems and a large number of parallel processes requires new diagnostic features.
The significantly higher frequency of changes related to software and also the scope of vehicle diagnostics requires new approaches to data management.
With this background, the "Service-Oriented Vehicle Diagnostics" (‘SOVD’) project was launched in ASAM in 2019. The standardization aims to create a modern, simple diagnostic interface that equally enables access to classic ECUs and emerging software-based systems. Another aim is also to achieve uniform access for the remote, proximity and in-vehicle diagnostics scenarios.
Vector is driving the standardization of SOVD in ASAM forward in order to offer suitable and universal solutions for these challenges.
Challenges
With the introduction of HPCs and thus increasingly software-based systems in cars, new challenges are also facing diagnostics.
Data required for diagnosing HPCs and apps are difficult to combine with the static structure of ODX (Open Diagnostic eXchange format) and UDS (Unified Diagnostic Service). Native apps also use other interfaces or data formats that are difficult to map in a UDS-based byte sequence.
Diagnostics based on UDS requires a matching static offline description for communication, typically in ODX format. However, the main objective of an increasingly software-based architecture is to bring new software and thus functionality into the car much faster and more flexibly. In practice, it will rarely be possible to ensure that the appropriate diagnostic description is always available for every software variant.
In UDS, diagnostic addressing is based on static identifiers and is therefore not very flexible. Changes to the communication matrix are complex and are therefore rarely made. This is also in contrast to the need to quickly introduce new software components into the vehicle.
Even after the introduction of central computer systems in the vehicle, there will still be a considerable number of classic ECUs that form the basis for the SW-based functions. Due to their requirements and resources, these classic ECUs are currently based on familiar software platforms (e.g., AUTOSAR Classic) and will continue to be so in the future. They provide UDS-based diagnostics. It is therefore important to integrate these diagnostics seamlessly into SOVD.
Targets
- One API (Application Programming Interface) for diagnostics and software update (across vehicles).
- A consistent API that can be used for new systems as well as traditional sensor / actuator systems.
- Usage scenarios: proximal (wired to the car or via short-range communication); in-vehicle (driving along with the car); and remote (from a distance to the car).
- A self-describing API that - unlike today - allows diagnostics without an external description file. Nevertheless, some external description will still be needed in the future, for example to be able to create cross-variant test sequences.
- Suitable existing technologies are to be selected and combined. It is an explicit goal to avoid inventing a completely new technology.
Use Cases
Within the vehicle, a wide variety of software components and devices with processors and controllers contribute to functions, and also to the overall diagnostics. Requests for diagnostics and software updates are forwarded to the appropriate processing agent in each case.
In abstract terms, diagnostic requests are operations on a specific resource, e.g.
- Reading of measured values and system parameters, individually or as a series of measured values
- Reading of event and fault memories
- Changing parameters
- Starting of special diagnostic functions
- Low-level control/access to actuators and sensors
In addition, requests are now made to retrieve the self-description (‘Capability Description’) of a concrete resource (hardware or software part). The available diagnostic scope may depend on the role or authorization of the requester. The self-description includes all diagnostic scopes that can be requested by the current role.
If a request is directed to a high-performance computer, the request is processed directly and centrally by its software, the processing is said to be performed in a native manner. This is referred to as, ‘native SOVD’.
However, if a request is directed to an ECU that supports UDS diagnostics, the SOVD request must first be translated into UDS diagnostics, and the response translated accordingly. This means that SOVD is converted to UDS and vice-versa, this is referred to as the ‘Classic Diagnostic Adapter’.
It should make no difference to the requestor whether a request is directed to a high-performance computer or a classic UDS ECU. The Classic Diagnostic Adapter permits a requestor to use the SOVD API and work with only symbolic values and data.
Standardization
The goal of ASAM SOVD is to specify a unified API for new systems and traditional sensor/actuator diagnostics.
An important premise for the development of ASAM SOVD is to use appropriate technologies, and not to invent (or worse, reinvent) a new one. The SOVD API is based on an http/REST-based approach.
The ASAM SOVD API supports querying a self-description so as not to rely on an external data specification. Nevertheless, there are mechanisms for offline documentation and specification to best support development, production, and after-sales processes.
ASAM SOVD focuses on the definition of the interface (API). The implementation of SOVD in the vehicle is not the subject of the ASAM project. However, there are already activities in AUTOSAR to address the implementation issue.
Start a Conversation
Do you want to actively shape the next generation of diagnostics? Then let's talk to each other!
Tobias Weidmann
ASAM SOVD Project Leader - Let's build SOVD solutions!
Good to Know
Diagnostics beyond UDS
[B. Gottschalk (Mercedes-Benz AG), C. Rätz, (Vector)
The lecture provides an overview on the history of vehicle diagnosis as well as a per-spective on current trends in this area. (only in German language)
