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.