ASAM SOVD – Service-Oriented Vehicle Diagnostics

Use Cases  

The SOVD standard defines an API for a diagnostic system that is implemented in an HPC in the vehicle. This enables use cases on the vehicle (Proximity), from a distance (Remote) or in the vehicle (InVehicle).

• Proximity  
  In this case, the diagnostic user is close to the vehicle and accesses the diagnostic system in the vehicle with their application via a wireless connection or a cable.  
  A typical use case is the repair shop where diagnostics is used to determine a possible repair.  

• Remote  
  In the remote case, the diagnostic system in the vehicle is accessed via the Internet and corresponding wireless technologies, such as 4G. Examples of use cases include remote support in the repair shop, fleet diagnostics in a road test and predictive maintenance algorithms for production vehicles.  

• InVehicle  
  Here, the diagnostic application is located in the vehicle and has direct access to the diagnostic system. One example is an SOTA application (Software Over The Air), in which the application regularly checks for new software in the cloud, downloads it if necessary and then updates the ECU.  

Implementation

The standard requires one occurrence of an SOVD server on an HPC in the vehicle. This is addressed via a unique URI (Unified Resource Identifier) and provides a defined API. The parameterization of the API methods takes place via JSON strings or directly via the URL.  
An SOVD server can implement various applications (entities):  

• Components are ECUs in the vehicle or software modules which implement driving functions, and which can be addressed directly 
• Classic Diagnostic Adapter (CDA) – is a special form of a component and makes diagnostics possible with today’s ECUs via UDS 
• APP – applications for comprehensive diagnostic processes that can be accessed via SOVD services 
• FUNC – access to diagnostic methods which compile several sources of information 
• AREA – access to information from specific areas of an E/E architecture in the vehicle, such as zones or domains  

The access to elements in the vehicle has a strict hierarchy. The diagnostic capabilities can be determined for each element of a level. The entities are addressed below the SOVD server (Apps, Components/CDA, FUNC, AREA), with relevant resources for diagnostics underneath. Examples of resources are faults, measurement values (data) or codings or parameterizations (configurations). This results in one access path for each diagnostic call.  

Log files and thus important elements for diagnostics within the HPC are also proprietary resources.  

The implementation of an SOVD server is not addressed by the standardization. However, a real implementation will usually have a parameterization option to support installation variants on the one hand, but also to allow changes to the diagnostic functionality during the vehicle’s lifetime on the other.