2. Requirements¶
In this requirements documentation, the sections represent the functional requirements for the communication on both ends, and some generic requirements for the application itself.
The actual architecture and implementation details are defined in different documents for traceability and separation of concerns.
2.1. General¶
2.1.1. Tracing¶
Tracing between requirements, architecture, design, implementation & tests is facilitated with sphinx-needs.
2.1.2. Configuration¶
The CDA must support a configuration file that allows it to be configured to the use-cases of different users.
This includes, but is not limited to:
network interfaces
ports
communication behaviour
communication parameters (includes timeouts)
initial discovery/detection of ecus
2.1.3. Performance¶
The CDAs primary target is an embedded HPC that runs on the vehicle with Linux. Primary target architectures are aarch64, and x86_64. It should be noted, that those HPCs typically have lower memory and worse cpu performance compared to desktop machines, and might run other (higher prioritized) software in parallel.
2.1.3.1. CPU & Memory¶
CPU and memory consumption need to be minimal to allow other tasks on that HPC to perform well.
2.1.3.2. Parallelism¶
The CDA must be able to communicate at least with 50 DoIP entities, and up to 200 ECUs behind those entities.
The maximum number of parallel threads used in the asynchronous communication should be configurable.
2.1.3.3. Modularity¶
The architecture must allow parts of it to be reusable for other use-cases. It’s also required that the internal modules can be interchanged at compile time with other ones, by implementing the well-defined API of that module.
2.1.3.4. Logging¶
The CDA must provide logging capabilities, which allow tracing of events, errors, and debug information. The logging system must be an configurable in terms of log levels and outputs, to adapt to different deployment scenarios.
2.1.4. System¶
2.1.4.1. Storage Access¶
The CDA must provide an abstraction layer for storage access, which allows it to interact with different types of storage systems (e.g., local file system, databases) without being tightly coupled to a specific implementation. This abstraction layer should provide a consistent API for reading and writing data, as well as handling errors and exceptions related to storage operations. The semantics of the API must be well-defined, to ensure atomicity of its operations, and to allow for consistent behavior across different storage implementations. |
Software Requirement: Local File System Storage Access Implementation req~system-default-local-file-system-storage-access
|
A default implementation for local file system access, utilizing the Storage Access Abstraction must be provided. |
2.1.4.2. Persistence¶
The CDA shall provide a persistence API for durable key-value storage. Data shall be organized into Buckets, where each Bucket represents a named, logically separated collection of key-value pairs. The API shall support creating and opening Buckets, as well as performing get, set, delete, and contains operations on entries within a Bucket. The API shall provide a flush operation that explicitly persists all buffered data to the underlying storage media. This allows callers to guarantee durability at defined points, such as during shutdown or for security-critical data that must not be lost. The concrete persistence implementation shall be provided by an exchangeable provider, allowing different storage backends to be used without changing consuming code. |
Software Requirement: Default redb Persistence Provider req~system-default-redb-persistence-provider
|
A default persistence provider implementation using redb shall be provided. This provider shall implement the persistence API, mapping Buckets to redb tables and storing key-value pairs with ACID transaction guarantees. Writes to the underlying storage media shall be minimized to reduce wear on flash-based storage typically found in embedded devices. |
2.1.4.3. Systemd Watchdog Integration¶
When the CDA is running as a systemd service with watchdog enabled, it must periodically aggregate the health status of all registered health providers and send appropriate sd_notify notifications to systemd:
The notification interval must be derived from the systemd-configured watchdog timeout to ensure timely delivery. When systemd is not detected or the watchdog is not enabled, the CDA must operate normally without watchdog integration. |
2.1.5. Extensibility¶
2.1.5.1. Plugin system¶
A comprehensive plugin API must be provided, which allows vendors to extend the functionality. See Plugins for details.
2.2. SOVD (ISO 17978-1)¶
The guiding principle behind this document is to specify the requirements for an ISO 17978-1 compatible API in the Eclipse OpenSOVD Classic Diagnostic Adapter (CDA).
2.2.1. General¶
Paths and parameter names should be case-insensitive, unless otherwise mentioned.
2.2.2. HTTP(S)¶
The CDA must provide an HTTP- or HTTPS-server. The HTTP Server has to support multiple connections, and calls should be handled asynchronously. Rationale Multiple clients might use the CDA at the same time, and asynchronous handling generally improves performance due to reduced thread count. |
The HTTP- or HTTPS-Server port must be configurable. |
In case of HTTPS, the certificate/key must be providable through the configuration, or a plugin. Rationale Certificates/Keys might be stored in an HSM, therefore platform specific code might be needed for access. |
2.2.3. API¶
2.2.3.1. Entities¶
Data types must be mapped as specified by ISO 17978-3. Additionally, for the data type |
2.2.3.2. Paths¶
The CDA must provide a Each ECU with a loaded diagnostic description (MDD file) must be represented as an entity in the collection.
Rationale The |
Software Requirement: Standardized Resource Collection Mapping req~sovd-api-standardized-resource-collection-mapping
|
||||||||||||||||||||||||||||||||||||
The standardized resource collection for
NOTE: The mapping in ISO standard is inconsistent w.r.t. Query Parameters The CDA must support the optional query parameter |
The CDA must return the Special Data Groups (SDGs) and Special Data (SDs) from the diagnostic description when the
optional query parameter This query parameter must be supported on:
The
When no SDGs are available for the requested resource, the Rationale SDGs carry vendor-specific metadata from the diagnostic description (e.g. bus interface type, AUTOSAR version) that clients may need for display or decision-making purposes. Making them opt-in through a query parameter avoids unnecessary overhead in the default response. |
The CDA must support ECU variant detection through a Rationale Some ECUs have different variants, which support different functionality. To provide the correct functionality, the CDA needs to be able to detect the variant in use. This variant may change at any point due to the nature of the ECUs software. Clients may need to trigger this explicitly to ensure correct functionality. |
2.2.3.2.1. Operations¶
Operations (Routines SID 3116) can be synchronous or asynchronous. Asynchronous routines are routines, for which the The order of operations:
Synchronous routines The POST to executions will directly return the result - either a 200 with the data, or an error. Example of a successful call: {
"parameters": {
"key": "value"
}
}
Asynchronous routines Since the response of the Example of a successful call: {
"id": "<id of created execution>",
"status": "running",
"parameters": {
"key": "value"
}
}
Should the call to the There are however use-cases, in which you may want to call |
2.2.3.2.2. Faults¶
The CDA must provide a |
2.2.4. Extensions to the ISO specification¶
2.2.4.1. Data Type A_BYTEFIELD as Hex¶
For the data type Rationale Handling base64 encoded binary directly can be a compatibility challenge for offboard testers accessing the CDA. Manual debugging can also be simplified by directly seeing the hexadecimal encoded data, since it’s easier to process for humans. |
2.2.4.2. Support for mimetype application/octet-stream¶
Software Requirement: Support for mimetype application/octet-stream req~sovd-api-octet-stream-support
|
The NOTE: Only the payload is sent/received. The SID & DID/RID are derived from the path, and in case of NRCs only the NRC code (single byte) is sent back with a HTTP 502. Rationale This requirement simplifies the use of the CDA as a diagnostic tester and in migration scenarios. |
2.2.4.3. Version Info Endpoint¶
The CDA must provide a The endpoint shall return a JSON response containing
The
The path to the Rationale Allows SOVD clients to discover which API versions are supported by the server before attempting to access version-specific resources. |
The CDA may optionally provide vendor-specific version data endpoints at These endpoints are registered by the same registration function that provides the standard
Rationale Provides a convenient vendor-specific endpoint for tooling that expects implementation details in a structured data format without needing to parse the standard version-info response. |
A single registration function shall accept the following parameters:
The function shall always register the The function shall optionally register the Rationale Centralizes version endpoint registration into a single callable unit, ensuring consistency between the standard version-info response and optional vendor-specific endpoints. |
2.2.4.4. Health Endpoint¶
The CDA MAY provide a health monitoring endpoint as an optional build-time feature. When the health monitoring feature is enabled:
When the health monitoring feature is disabled:
Rationale Health monitoring enables external systems (e.g., container orchestrators, load balancers, or monitoring systems) to observe CDA startup progress and operational status. Making this an optional build-time feature allows deployments that do not require health monitoring to reduce the application footprint and avoid unnecessary overhead. |
2.2.4.5. Support for non-standard operation order¶
Software Requirement: Support for non-standard operation order req~sovd-api-routine-operation-out-of-order
|
|||||||||
To support the use-case of calling
When a REST call is initiated that needs to call the service on the ECU, but is missing the required
definition in the diagnostic description, and |
2.2.4.6. Vehicle¶
A vehicle must support operations as a whole, to allow for operations which affect the whole vehicle, like updating mdd-files, or to prepare for operations which affect the whole vehicle (e.g. disabling vehicle communication).
Vehicle level operations must be supported in the CDA.
This requires a standardized resource collection in the exposed root path The standardized resource collection must provide the following resources:
|
2.2.4.7. Functional communication¶
Functional communications needs to be possible. A standardized resource collection must be made available within the
The available functionality must be defined in an additional diagnostic description used solely for defining functional communication services. Since this file may contain multiple logical link definitions, a configuration option can be provided to filter the available links. The following entities must be available in the functional groups resource collection:
Rationale Clients require functional communication to ECUs for use-cases, in which they want to control communication or dtcsettings for all ecus. |
2.2.4.8. Flash API¶
A Flash-API is required to support flashing of ECUs, utilizing SIDs 3416, 3616 & 3716. It needs to enable efficient transfer of the data, without sending the individual data transfers via REST. Flashing is the process of updating the firmware of an ECU. Rationale Handling for the aforementioned SIDs isn’t defined in the ISO specification, it is however an important use-case to be able to update the firmware on ECUs. |
The source of the data to be sent for flashing, must be restrictable to a path and its subdirectories via configuration. Rationale Without restrictions to the path, an attacker could exfiltrate arbitrary accessible data. |
2.2.4.9. Communication Parameters API¶
An API to retrieve and modify communication parameters must be provided Rationale Clients need the ability to modify communication parameters on-the-fly to communicate with classic ECUs. |
2.2.4.10. MDD Embedded files¶
The CDA must support reading embedded files from the mdd file, and provide them via the Rationale Some data required for communication with ECUs might be embedded in the mdd file. To allow clients to retrieve this data, it must be made available through the API. |
2.2.4.11. Security¶
Since vendors have different requirements and systems regarding security, security related functionality has to be implemented in a plugin, see Security.
2.2.4.11.1. Token validation¶
2.2.4.11.2. Audiences¶
2.2.4.11.3. Session States¶
2.2.5. OpenAPI-Documentation¶
An OpenAPI documentation of the provided API must be available for every endpoint of the CDA when Rationale Required by the standard. |
An OpenAPI schema description of the retrieved data must be included in the response when the query
parameter Rationale Required by the standard. |
2.3. Diagnostic Tester¶
This document defines the requirements for the diagnostic tester functionality of the Classic Diagnostic Adapter (CDA), including startup behavior, ECU detection, variant detection, and state management.
2.3.1. Startup Behavior¶
2.3.1.1. Startup Sequence¶
The CDA must execute startup in a defined sequence to ensure proper initialization of all components. The startup sequence must include the following phases in order:
Rationale A well-defined startup sequence ensures predictable initialization behavior and allows external systems to monitor startup progress via health endpoints when health monitoring is enabled (see Health Monitoring Endpoint (req~sovd-api-health-endpoint)).
CDA Startup Sequence¶ |
2.3.1.2. Database Loading¶
The CDA must load diagnostic databases (MDD files) at startup. The following requirements apply:
Rationale Parallel database loading significantly reduces startup time in deployments with many ECU definitions. Graceful handling of duplicates and failures ensures robust operation in real-world environments where database files may be inconsistent or corrupted. |
2.3.1.3. DoIP Gateway Initialization¶
The CDA must initialize the DoIP gateway to enable communication with vehicle ECUs. The initialization must include:
The following must be configurable:
Rationale DoIP gateway initialization establishes the communication path to vehicle ECUs. Configurable parameters allow adaptation to different network topologies and timing requirements. |
2.3.1.4. Deferred Initialization¶
The CDA must support deferred initialization of ECU discovery and communication. When deferred initialization is enabled:
Rationale Deferred initialization supports use cases where the CDA must start quickly without immediately consuming network resources, or where ECU communication should only begin after explicit authorization (e.g., security unlock, session establishment, or plugin-controlled activation). This is particularly useful in diagnostic scenarios where the tester must be fully operational before any vehicle communication occurs. |
2.3.2. ECU Detection and Variant Detection¶
2.3.2.1. ECU Discovery¶
The CDA must discover and register ECUs based on loaded databases and DoIP gateway responses. The following requirements apply:
Rationale ECU discovery establishes the mapping between diagnostic descriptions (MDD) and physical vehicle communication endpoints, enabling the SOVD API to expose the correct ECU capabilities. |
2.3.2.2. Variant Detection¶
The CDA must perform variant detection to identify the correct ECU variant from potentially multiple definitions. The following requirements apply:
Rationale ECUs may have multiple software variants with different diagnostic capabilities. Variant detection ensures the CDA exposes the correct services and parameters for the actually installed variant. |
2.3.2.3. ECU States¶
ECUs must maintain defined states throughout their lifecycle to reflect their current availability and detection status. The following states must be supported:
State transitions must occur as follows:
The current ECU state must be queryable via the SOVD API.
ECU State Chart¶ Rationale Explicit state management provides clients with visibility into ECU availability and allows appropriate error handling based on the current state. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam stateArrowThickness 2
[*] --> NotTested : ECU registered
state NotTested {
}
state Online {
}
state NoVariantDetected {
}
state Duplicate {
}
state Offline {
}
state Disconnected {
}
NotTested --> Online : Variant detected\nsuccessfully
NotTested --> NoVariantDetected : Detection failed\n(fallback enabled)
NotTested --> Duplicate : Another ECU with same\nlogical address is correct
NotTested --> Offline : Variant detection attempted\nbut ECU unreachable
Offline --> NotTested : Reconnection attempt /\nRe-detection requested
Online --> Disconnected : Connection lost
Online --> NotTested : Re-detection\nrequested
NoVariantDetected --> Online : Variant\nre-detected
NoVariantDetected --> Duplicate : Another ECU with same\nlogical address is correct
NoVariantDetected --> Disconnected : Connection lost
Duplicate --> NotTested : Re-detection\nrequested
Disconnected --> NotTested : Reconnection\nattempt
@enduml](../_images/plantuml-b4c9074d030e347a3ef9ea3b64366226f388a4e6.png)
2.3.3. Error Handling¶
The CDA must handle startup failures gracefully to maximize availability. The following error handling behaviors must be supported:
All errors must be logged with sufficient detail for troubleshooting. Rationale Graceful degradation ensures the CDA remains partially operational even when some components fail, which is critical for diagnostic scenarios where partial functionality may still be useful. |
2.4. Communication¶
2.4.1. DoIP Communication¶
DoIP Communication is described in the ISO 13400 standard. Specific communication parameters and implementation details will be defined and linked in this document.
The communication parameters depend on the logical link used for the communication, filtered by configuration and actual ECU detection/availability.
2.4.1.1. Protocol Versions¶
The CDA shall support the DoIP protocol versions defined in ISO 13400-2. The default protocol version shall be ISO 13400-2:2012 ( Rationale ISO 13400-2:2012 is the most widely deployed version across vehicle platforms. Configurable version support ensures compatibility with DoIP entities implementing different standard revisions. |
2.4.1.2. Message Framing¶
The CDA shall frame all DoIP messages according to the ISO 13400 header format, consisting of:
The CDA shall support encoding and decoding of the following payload types:
Rationale Correct message framing is essential for interoperability with any ISO 13400 compliant DoIP entity. Supporting the full set of relevant payload types enables complete diagnostic communication workflows. |
2.4.1.3. Communication Parameters¶
The CDA must support configuration of DoIP communication parameters as defined in the following table. Parameters are sourced from the diagnostic database (MDD files) and may vary per logical link.
|
2.4.1.4. Vehicle Identification¶
The CDA shall discover DoIP entities on the network by broadcasting a Vehicle Identification Request (VIR) via UDP and processing Vehicle Announcement Message (VAM) responses. The CDA shall:
Vehicle Identification Overview¶ Rationale UDP-based discovery enables automatic detection of DoIP entities without requiring static IP configuration. Subnet filtering prevents unintended communication with entities on unrelated networks. Continuous VAM listening ensures the CDA adapts to dynamic network conditions. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "CDA" as CDA
participant "DoIP Entity" as GW
== Discovery ==
CDA -> GW: VIR broadcast via UDP\n(0x0001, to 255.255.255.255:13400)
GW --> CDA: VAM response via UDP\n(0x0004, [VIN, logical_addr, EID, GID])
CDA -> CDA: Filter by subnet mask
CDA -> CDA: Match to known ECUs
== Continuous Listening ==
note over CDA: Background listener\nfor spontaneous VAMs
GW --> CDA: Spontaneous VAM\n(entity online)
CDA -> CDA: Connect and trigger\nvariant detection
@enduml](../_images/plantuml-cc13edcfc580666bb2fca2a78c818cc84dcb73d9.png)
2.4.1.5. Routing Activation¶
The CDA shall perform routing activation on each TCP connection before exchanging diagnostic messages. The routing activation shall:
Rationale Routing activation is a mandatory step in the DoIP protocol to register the tester with the DoIP entity. |
2.4.1.6. TLS Communication¶
The CDA shall support TLS-secured DoIP connections as defined in ISO 13400. TLS Fallback When a DoIP entity denies routing activation with the code
TLS Version
The supported versions for DoIP-connections shall be configurable. TLS Ciphers The CDA shall support the following TLS cipher suites. TLS 1.2 Cipher Suites:
TLS 1.3 Cipher Suites:
Null Cipher Suites:
The supported cipher suites for DoIP-connections must be configurable through a configuration option. Certificate Chain Verification
Rationale TLS support is required for DoIP entities that mandate encrypted communication. Configurable certificate verification and custom CA support are necessary because automotive environments typically use private PKI infrastructures rather than publicly trusted CAs. The option to disable verification ensures compatibility with test and development environments. |
2.4.1.7. Diagnostic Message Exchange¶
The CDA shall send and receive diagnostic messages (UDS payloads) through the DoIP transport layer with proper acknowledgement and error handling. Sending
Acknowledgement
Response Forwarding
Functional Addressing
DoIP Diagnostic Message Transport¶ Rationale Proper ACK/NACK handling with configurable retries ensures reliable delivery of diagnostic messages at the DoIP transport layer. UDS-level response interpretation (including NRC handling) is handled separately at the application layer. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "CDA" as CDA
participant "DoIP Entity\n(Gateway)" as GW
== Send Request ==
CDA -> GW: Diagnostic Message (0x8001)\n[tester_addr -> ecu_addr, UDS payload]
alt ACK
GW --> CDA: Diagnostic Message ACK (0x8002)
note right: Within\nCP_DoIPDiagnosticAckTimeout
else NACK
GW --> CDA: Diagnostic Message NACK (0x8003)\n[nack_code]
note right of CDA: Retry per\nCP_DoIPNumberOfRetries
end
== Receive Response ==
GW --> CDA: Diagnostic Message (0x8001)\n[UDS response payload]
CDA -> GW: Diagnostic Message ACK (0x8002)
note right of CDA: Forward UDS payload\nto application layer
@enduml](../_images/plantuml-60e68ba5f9659c69ad21dcce0d78e44e76ef65d9.png)
2.4.1.8. Alive Check¶
The CDA shall perform periodic alive checks on idle DoIP connections to detect connection loss.
Rationale TCP connections may be silently lost due to network disruption or gateway restart. Periodic alive checks enable early detection of connection loss and timely recovery. Some ECUs do not implement this feature, so the CDA should only consider it a failure if the ECU has previously responded to alive checks, indicating support for this mechanism. |
2.4.1.9. Connection Management¶
The CDA shall manage TCP connections to DoIP entities with automatic recovery from connection failures.
Rationale Automatic connection recovery ensures continuous diagnostic availability despite transient network issues. Sharing a single TCP connection per gateway aligns with the DoIP protocol model where the gateway multiplexes ECU communication. |
2.4.1.10. Error Handling¶
The CDA shall handle DoIP communication errors with configurable retry behavior.
Rationale Configurable retry behavior enables adaptation to different network conditions and ECU response characteristics. Distinguishing between recoverable and non-recoverable errors prevents unnecessary retry attempts on permanent failures. |
2.4.2. UDS Communication (DoIP)¶
This describes the relevant UDS communication parameters when used with DoIP, and how they are used.
2.4.2.1. Communication parameters¶
Software Requirement: The CDA must support configuration of UDS communication as defined in the following table. req~uds-communication-parameters
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
2.4.2.2. Request-Response Flow¶
The CDA shall implement a UDS request-response protocol for diagnostic communication with vehicle ECUs, satisfying the following behavioral constraints. Per-ECU Serialization
Response Matching
Response Timeout and Retry
Rationale Per-ECU serialization prevents interleaving of diagnostic requests to the same ECU, which would violate the UDS protocol’s assumption of single-outstanding-request per tester-ECU pair. SID-based response matching ensures that only the correct response is accepted, discarding stale or misrouted messages. Configurable timeouts and retries allow adaptation to ECUs with varying response characteristics. |
2.4.2.3. NRC Handling¶
The CDA shall handle UDS Negative Response Codes (NRCs) at the application layer according to the configured handling policies and timing parameters. NRC 0x78 – Response Pending When the ECU responds with NRC 0x78, it indicates that the request was received but the ECU requires additional time to process it. The CDA shall:
NRC 0x21 – Busy, Repeat Request When the ECU responds with NRC 0x21, it indicates that the ECU is temporarily busy. The CDA shall:
NRC 0x94 – Temporarily Not Available When the ECU responds with NRC 0x94, it indicates that the requested resource is temporarily not available. The CDA shall:
Application Layer Timeout and Retry
UDS NRC Handling¶ Rationale NRC handling is a UDS application layer concern independent of the DoIP transport. Configurable policies and timeouts per NRC code allow the CDA to adapt to different ECU response characteristics, ensuring that transient busy conditions and processing delays do not cause premature failure of diagnostic requests. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "CDA\n(Application Layer)" as CDA
participant "DoIP Entity\n(Gateway)" as GW
participant "ECU" as ECU
== UDS Request (after DoIP ACK) ==
GW -> ECU: UDS request
activate ECU
alt NRC 0x78 (Response Pending)
ECU --> GW: NRC 0x78
GW --> CDA: UDS response [NRC 0x78]
note right of CDA: Switch to CP_P6Star timeout\nContinue per CP_RC78Handling
ECU --> GW: UDS positive response
deactivate ECU
GW --> CDA: UDS response [positive]
else NRC 0x21 (Busy, Repeat Request)
ECU --> GW: NRC 0x21
deactivate ECU
GW --> CDA: UDS response [NRC 0x21]
note right of CDA: Wait CP_RC21RequestTime\nthen retransmit
CDA -> GW: UDS request (retransmit)
GW -> ECU: UDS request
activate ECU
ECU --> GW: UDS positive response
deactivate ECU
GW --> CDA: UDS response [positive]
else Direct Response
ECU --> GW: UDS response
deactivate ECU
GW --> CDA: UDS response
note right of CDA: Within CP_P6Max
end
@enduml](../_images/plantuml-5c5910bfa0fc177345e33a26fe1a9afbd7a5a1cc.png)
2.4.2.4. Tester Present¶
The CDA shall maintain active diagnostic sessions with ECUs by periodically sending
UDS Tester Present ( Lock-Driven Lifecycle
Tester Present Deduplication
Message Format and Timing
Send Type
Addressing Mode
Generation Control
Error Handling
Tester Present – Component Lock¶
Tester Present – Functional Group Lock¶ Rationale Tester present messages prevent ECU diagnostic sessions from timing out during periods of inactivity between diagnostic requests. Tying tester present to the lock lifecycle ensures that session keepalive is active only when a client has expressed intent to communicate with the ECU. The deduplication rule prevents duplicate tester present traffic to the same ECU. Configurable COM parameters allow adaptation to different ECU requirements regarding message format, timing, and response expectations. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "SOVD\nLock Manager" as LM
participant "CDA\n(UDS Layer)" as UDS
participant "DoIP\nTransport" as DoIP
participant "ECU" as ECU
LM -> UDS: acquire component lock
UDS -> UDS: Start physical TP\nfor ECU
activate UDS #LightBlue
loop Every CP_TesterPresentTime
UDS -> DoIP: [0x3E, 0x00] to\nphysical address
DoIP -> ECU: Tester Present
ECU --> DoIP: [0x7E, 0x00]
DoIP --> UDS: Tester Present Response
end
note over LM, ECU: This shows the typical flow.\nActual message content, timing, and response\nhandling depend on the CP_TesterPresent*\ncommunication parameters.
LM -> UDS: release component lock
UDS -> UDS: Stop physical TP task
deactivate UDS
UDS -> UDS: Reset session and\nsecurity access
@enduml](../_images/plantuml-acc7572f664d250d794baaa88a453464ff58469f.png)
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "SOVD\nLock Manager" as LM
participant "CDA\n(UDS Layer)" as UDS
participant "DoIP\nTransport" as DoIP
participant "ECU\n(Gateway)" as GW
LM -> UDS: acquire functional group lock
UDS -> UDS: Resolve group to\ngateway ECUs
UDS -> UDS: Start functional TP\nfor each gateway
activate UDS #LightGreen
loop Every CP_TesterPresentTime
UDS -> DoIP: [0x3E, 0x80] to\nfunctional address
DoIP -> GW: Tester Present
end
LM -> UDS: release functional group lock
UDS -> UDS: Stop functional TP tasks
deactivate UDS
UDS -> UDS: Reset session and\nsecurity access
@enduml](../_images/plantuml-32ec6b172461c5864668c1c847f017892ccd85bb.png)
2.4.2.5. Functional Communication¶
The CDA shall support functional group communication, sending a single UDS request to multiple ECUs simultaneously using functional addressing with parallel response collection. Functional Group Resolution
Gateway Grouping
Response Collection
NRC Handling
Functional Communication Flow¶ Rationale Functional addressing enables efficient broadcast-style communication where the same diagnostic service must be executed across multiple ECUs (e.g., sending Tester Presents to all ECUs in a vehicle). Grouping by gateway and sending one request per gateway minimizes network traffic. Parallel response collection ensures that slow-responding ECUs do not delay results from other ECUs. Returning NRCs as-is on the functional path avoids complex retry orchestration across multiple ECUs simultaneously. |
![@startuml
skinparam backgroundColor #FFFFFF
skinparam sequenceArrowThickness 2
participant "Caller" as Caller
participant "CDA\n(UDS Layer)" as UDS
participant "Gateway A" as GW1
participant "ECU A" as ECUA
participant "ECU B" as ECUB
== Functional Request ==
Caller -> UDS: Functional group request
activate UDS
UDS -> UDS: Resolve group to\nonline ECUs
UDS -> UDS: Group by gateway
UDS -> GW1: Diagnostic Message\n[functional_addr, UDS request]
GW1 --> UDS: ACK
par Parallel Response Collection
GW1 -> ECUA: Forward request
ECUA --> GW1: UDS response
GW1 --> UDS: Response (ECU A)
else
GW1 -> ECUB: Forward request
ECUB --> GW1: UDS response
GW1 --> UDS: Response (ECU B)
end
UDS --> Caller: Aggregated results\nper ECU
deactivate UDS
note right of Caller: ECUs not responding within\nCP_P6Max reported as\nindividual timeout errors
@enduml](../_images/plantuml-d3d0bc91bbbbec754d931eb150a0417bfeb4a80e.png)
2.5. Plugins¶
2.5.1. API¶
The plugin system API must support the following use-cases.
Plugins must be able to utilize all the APIs in the CDA.
Plugins must be able to access and modify a SOVD-request-context, if applicable for the type/interception point of that plugin
2.5.2. Security¶
A SOVD security plugin must be able to:
Validate and verify the JWT token from incoming HTTP Requests
Utilize additional headers from the request
Reject the incoming request
Enhance the SOVD-request-context with data, this context can then be used in other addons
2.5.3. Paths¶
A SOVD plugin must be able to:
Add paths to the SOVD-API, and handle them
Restructure existing path structures
Modify existing path structures to run different code
2.5.4. UDS¶
An UDS plugin must be able to:
Intercept UDS requests before they are sent to the ECU
Intercept UDS responses
2.5.5. DoIP¶
A DoIP plugin must be able to:
Intercept DoIP requests before they are sent to the ECU
Intercept DoIP responses
2.5.6. Diagnostic Database Update Plugin¶
A diagnostic database update plugin must be available. It must provide an SOVD-API allowing clients to update the diagnostic database of the CDA atomically, meaning all provided files for the update are updated at the same time, and any failure during the update process fails the entire update, rolling back to the previous state of the diagnostic database. The plugin must be able to update the diagnostic database without restarting the CDA. |
Software Requirement: Diagnostic Database Update Plugin - Authentication req~plugin-diagnostic-database-update-authentication
|
The diagnostic database update plugin must ensure that only authorized clients can update the diagnostic database. The exact mechanism (i.e. are calls to the endpoints allowed) must be providable to the plugin. |
Software Requirement: Diagnostic Database Update Plugin - Verification req~plugin-diagnostic-database-update-verification
|
The diagnostic database update plugin must be able to verify the integrity of the mdd files before they are being used by the CDA. The exact mechanism (e.g. signature & hash verification) must be providable to the plugin. |
Software Requirement: Diagnostic Database Update Plugin - Downgrade Protection req~plugin-diagnostic-database-update-downgrade-protection
|
The diagnostic database update plugin must have the option to prevent downgrades of the diagnostic database, meaning that it can prevent applying an update which would lead to an older version of the diagnostic database being active than the currently active one. The exact mechanism (e.g. version determination, persistence of versions for deleted entries) must be providable to the plugin. |
Software Requirement: Diagnostic Database Update Plugin - Safety req~plugin-diagnostic-database-update-safety
|
Updates to the diagnostic database must be safe, it must be ensured that the CDA can recover from power-cycles or crashes at any time during the update process, and that the CDA is not left in an unusable state. |
2.5.7. DLT Logging Plugin¶
The CDA must support logging to the AUTOSAR Diagnostic Log and Trace (DLT) system. When enabled, application tracing events must be forwarded to the DLT daemon running on the target system, allowing log capture and analysis with standard automotive DLT tooling. Rationale DLT is the standard logging mechanism used in automotive ECUs and HPCs. Supporting DLT output allows the CDA to
integrate into existing vehicle logging infrastructure and enables field diagnostics with standard tools such as
|
DLT logging support must be an optional compile-time feature. When the feature is not enabled, the DLT dependency must not be compiled, and DLT-related code must have zero runtime overhead. Rationale The DLT system library ( |
Software Requirement: DLT Logging - Runtime Configuration req~plugin-dlt-logging-runtime-configuration
|
When DLT logging support is compiled in, it must be possible to enable or disable DLT output at runtime through the application configuration. The following parameters must be configurable:
|
Software Requirement: DLT Logging - Context Identification req~plugin-dlt-logging-context-identification
|
Each subsystem of the CDA must be identifiable in the DLT output through a unique context identifier. The context identifiers must conform to the DLT protocol constraints (up to 4 ASCII characters) and allow DLT tooling to filter log messages by subsystem. Rationale DLT context IDs enable operators to filter and analyze logs for specific subsystems (e.g. communication, database loading, SOVD API) without having to parse log message content, which is a standard workflow in automotive log analysis. |
Application log levels must be mapped to their corresponding DLT log levels, so that DLT-side filtering by severity works correctly. |