3.1. Overview¶
3.1.1. SOVD¶
The SOVD block manages incoming SOVD requests and translates them into calls to the Diagnostic Tester API. It includes an HTTP server to receive SOVD requests and an OpenAPI generator to create documentation for API endpoints.
Additionally, the OpenAPI generator can be used as a standalone component to generate comprehensive documentation for ECU variants.
The functionality is divided into three distinct modules:
HTTP Server
Translation between SOVD and Diagnostic Tester API
OpenAPI Generation
3.1.2. Diagnostic Tester¶
The Diagnostic Tester component provides an API for plugins and the SOVD layer. This API handles UDS payload conversion, manages ECU variant detection, and maintains the diagnostic runtime database.
It encapsulates functionality similar to a traditional offboard tester, optimized for the SOVD use case, and supports only the UDS protocol.
3.1.2.1. Diagnostic runtime database¶
The diagnostic runtime database is consulted to translate named parameters and services into UDS. It contains all diagnostic descriptions (.mdd) of the ECUs provided at startup and allows for runtime switches and additions/removal of underlying diagnostic descriptions, while no active diagnostic communication is in progress.
In terms of requirements, the database needs to minimize memory consumption while delivering maximum performance for the most common calls.
3.1.2.2. API¶
In the diagnostic tester, an API needs to be provided to utilize its functionality. The API itself needs to be close to the MCD-3 D specification, to enable future use-cases of the diagnostic tester core.
3.1.2.3. UDS payload conversion¶
As an internal module, the UDS payload conversion is mainly responsible to convert a set of named input parameters (Diagnostic Service, request parameters) into a UDS payload, and also back from UDS payload into named parameters.
3.1.3. Plugins¶
Plugins are responsible for significant portions of the CDAs functionality which are often vendor specific. As an example, security through jwt tokens is solved differently by different vendors, so the mechanism for their verification and interpretation into access rights needs to be customizable.
The same is true for logging, tracing and safety. Lastly, vendors might want to add custom endpoints with custom functionality, which would also be done through plugins.
3.1.4. Communication Layer¶
In the communication layer everything related to the communication with ECUs is handled. This includes periodically sent tester presents, timing and connection parameters. It provides an API to logically communicate with ECUs using their addresses (functional/physical) and handles the execution order, parallelization and link state.
3.1.4.1. UDS¶
Implementation of UDS communication, with handling of NRCs, tester presents (either physical or functional, flag for every connection per address), timeouts, retries and actual data.
3.1.4.2. DoIP¶
Implementation of DoIP communication with handling of timeouts.