Main Goal of the Project
Definition of a standardized service API for HPC diagnostics, which includes new HPC-related and conventional diagnostic use-cases.
The primary focus of ECU diagnostic in today's vehicles is on checking the functionality of hardware components, such as sensors, actuators and the ECU. Diagnostic communication then allows to read trouble codes, manage the diagnostic memory, carry out test procedures in the workshop and perform some other operations like parameter changes and software updates. The most widely spread bus system in use is the CAN-bus. First vehicle platforms supporting Ethernet access have entered the market. The most widely spread diagnostic protocol across both bus systems is UDS.
With the introduction of HPCs (high performance computers) to the vehicle network, the diagnostic capabilities of UDS seem to reach its limitations. HPCs have capabilities, which go far beyond those of conventional ECUs:
- multi-core, multi-threaded computing
- virtualized ECUs sharing resources on the same hardware
- high band-width low-latency communication to other HPCs (e.g. via Automotive Ethernet)
- complex operating systems
- complex software and AI-engines
Hence, mechanisms are required to analyze and diagnose not only the hardware aspects of the vehicle network but also the software executing on HPCs.
In addition to HPCs, new connectivity technology enters the market place, that may in the long run obsolete the OBD connector. Wi-Fi and mobile broadband (4G, 5G) allow for remote and OTA (over-the-air) access to the vehicle network, allowing remote diagnostics, coding, parametrization and re-programming. At the same time, HPCs allow to perform on-board diagnostic tasks without any external access. We thus have to distinguish between use-cases for onboard, proximity and remote diagnostics, which is a new challenge not covered by today’s prevailing diagnostic stacks.
Use-Cases for Standardization
ASAM members have proposed three use-cases for HPC diagnostics standardization, which are given as a starting point for discussion and elaboration for the proposal workshop.
Use-Case 1: Proximity Diagnostics
The person performing vehicle diagnostics is close to the vehicle. The diagnostics system helps the person to detect and localize the fault, e.g. by reading out error codes, sensor/actuator values or debugging information (e.g. log files). He can check the operational status of components (OK/NOK), performing actuations or stimulations and carry out parameter and software updates.
Use-Case 2: Remote Diagnostics
The vehicle diagnostics is performed remotely, i.e. over-the-air (OTA diagnostics). Besides detecting and localizing the fault by a technician, as described in use-case 1, there are more operations possible. Roadside assistance may provide remote help with no technician present. A service advisor may prepare the vehicle for service. Information may be retrieved for monitoring purposes, e.g. fuel level, battery health check, etc. Other services are possible, such as remote activation of vehicle functions or fleet management.
Use-Case 3: Onboard Diagnostics
There is no external device or remote application connected to the vehicle and no external operator or application interacts with the vehicle. Instead, diagnostic functions run autonomously within the vehicle, for instance to monitor critical components, carry out predictive or preventive maintenance scenarios and to collect vehicle status information.
Proposal for Standardization
The aim of the standardization proposal is to define and standardize interfaces and services to cover the above use-cases in a flexible architecture, which includes classic diagnostics for regular ECUs and the additional diagnostic use-cases for one or multiple HPCs. UDS diagnostics capabilities and OBD-based access must be supported. Proximity and remote diagnostics shall be supported by a 'public' interface, that is accessible by external devices. Those HPCs with a 'private' interface shall be accessible by external devices via connected HPCs with a 'public' interface, allowing to implement domain- or gateway-network architectures. This is achieved by API-level standardization of the application interfaces of two diagnostic software components running on an HPC:
- HPC Diagnostics Service (private and public)
- Classic Diagnostic Adapter
The positioning of the software components in a simple central diagnostic access network architecture is shown in the following figure: