diff --git a/docs/requirements/stakeholder/index.rst b/docs/requirements/stakeholder/index.rst index 33c27e5..d1d2610 100644 --- a/docs/requirements/stakeholder/index.rst +++ b/docs/requirements/stakeholder/index.rst @@ -17,6 +17,739 @@ Stakeholder Requirements ======================== +Overall goals +------------- + +.. stkh_req:: Reuse of application software via managed APIs + :id: STKH_REQ__20 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: This is a usability constraint needed for long maintenance support + :status: valid + + The platform shall enable the reuse of application software via a set of managed APIs. + These APIs shall be developed via a well-defined life-cycle ensuring + non-breaking changes. + + +.. stkh_req:: Enable cooperation via standardized APIs + :id: STKH_REQ__30 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: To enable cooperation with other cooperation partners. + :status: valid + + The software platform shall where possible be based on existing standards (e.g. network protocols). + +.. stkh_req:: Variant management + :id: STKH_REQ__60 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall provide variant management support. + Variant management support shall enable users to ensure the + compatibility of application software across vehicle variants and vehicle + software releases. + + +.. stkh_req:: IP protection + :id: STKH_REQ__50 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support cooperation models, where partners do not + want to disclose their intellectual property of applications to all other + partners. + + + +Functional requirements +----------------------- + +.. stkh_req:: File Based Configuration + :id: STKH_REQ__8 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: File based configuration allows changes without rebuilding the software. + :status: valid + + The platform shall support configuration of applications via files (e.g. yaml, json) + +.. stkh_req:: Support of safe Key/Value store + :id: STKH_REQ__350 + :reqtype: Functional + :security: NO + :safety: ASIL_B + :rationale: Key/Value storage is a standard way to structure file based non-volatile memory access. + :status: valid + + The software platform shall provide towards the applications a safe + (ISO26262-2018) key/value store. + + Note: This is part of 0.1 release and therefore can only support ASIL_B. Goal is ASIL_D. + +.. stkh_req:: Safe Configuration + :id: STKH_REQ__9 + :reqtype: Functional + :security: NO + :safety: ASIL_B + :rationale: Configuration files may hold safety relevant information. + :status: valid + + The platform shall support safe configuration. + Note: This is part of 0.1 release and therefore can only support ASIL_B. Goal is ASIL_D. + + +.. stkh_req:: Safe Computation + :id: STKH_REQ__10 + :reqtype: Functional + :security: NO + :safety: ASIL_D + :rationale: Safe systems require computations to be done in safe environments. + :status: valid + + The platform shall support safe computation. + + +.. stkh_req:: Hardware Accelerated Computation + :id: STKH_REQ__11 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: High computation loads typically need to be speed up hardware acceleration e.g. in ADAS applications + :status: valid + + The platform shall support computation accelerated by a Hardware accelerator. + + +.. stkh_req:: Data Persistency + :id: STKH_REQ__12 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: Applications typically need to store data across power cycles. + :status: valid + + The platform shall support to store data on non-volatile memory e.g. disks, flash, etc. + + +.. stkh_req:: Operating System + :id: STKH_REQ__13 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: This allows portability of platform on POSIX compliant operating systems. + :status: valid + + The platform shall support operating systems compliant with IEEE Std 1003.1 (2004 Edition or newer) + +.. stkh_req:: Video subsystem + :id: STKH_REQ__340 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall provide an interface for pre-processing and + distribution of camera data via the following mechanisms + + * PCIe Graphic streams + * Shared Memory Graphic streams + * Display Serial Interface Driver + * APIX serialization driver + * ISP Driver including correction and frame pre-processing CV library (lens distortion et. al.) + * Sensor Streamer component (binding ISP Driver & pre-processing CV library) + + +.. stkh_req:: Compute subsystem + :id: STKH_REQ__330 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The compute subsystem shall provide the following frameworks towards the + applications: + + * Math library: Eigen Blaze like safety enhanced math front-end library + * Graphics and compute API: Vulkan GPU back-end and CPU (SIMD capable)-based compute libraries: + + * Deep Neural Network API: (including pytorch, tensorflow conversion scripts) + * Computer Vision API: e.g. like OpenCV + * Linear algebra API: e.g. BLAS / Lapack + * AVB Sensor streams + * PCIe Sensor streams + * Shared Memory Sensor streams + * GSML serialized data + +.. stkh_req:: Communication with external MCUs/standby controllers + :id: STKH_REQ__310 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall define protocols and concepts for the interaction with + external micro-controllers for + + * board management + * external supervision for safety and security functions + * software update + * debugging + * feature activation + + +Dependability +------------- + +.. stkh_req:: Automotive Safety Integrity Level + :id: STKH_REQ__70 + :reqtype: Functional + :security: NO + :safety: ASIL_B + :rationale: The platform shall be usable by safety relevant applications. + :status: valid + + The software platform shall support applications with an automotive safety + integrity level up to ASIL-B. + + Note: This is part of 0.1 release and therefore can only support ASIL_B. Goal is ASIL_D. + + +.. stkh_req:: Safety features + :id: STKH_REQ__80 + :reqtype: Functional + :security: NO + :safety: ASIL_D + :rationale: tbd + :status: valid + + The following safety feature shall be supported by the software platform: + + * Health Management (alive, deadline, logical supervision) for time and event based taskchains + * E2E Protection for communication + * Built-in hardware self-tests + * Safe reset paths + * IO MMU protecting DMA accesses + * Memory Management Unit + * Memory Protection Unit for caches + * ECC Memory + * Software Lockstep + * Power management integrated circuit (PMIC), external watchdog and voltage monitoring + * Safe switch from engineering for field mode and back + + +.. stkh_req:: Availability + :id: STKH_REQ__90 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support the development of highly available systems. + (see also `Availability `_). + + +.. stkh_req:: Security features + :id: STKH_REQ__140 + :reqtype: Functional + :security: YES + :safety: QM + :rationale: tbd + :status: valid + + The following security features shall be supported by the platform + + * Mandatory access control + * Secure boot + * Secure onboard communication + * IPSec and MACSec + * Firewall + * Certificate installation and storage in HSM or ARM trustzone. + * Kernel hardening (ASLR, Pointer obfuscation …) in libc and compiler + * Identity and Access Management + * Secure Feature Activation + * Secure software update + + +Application architectures +------------------------- + +In modern software systems, the architectural design plays a critical role in determining how components interact, how they process +data, and how they manage workloads. Each architectural pattern is tailored to address specific challenges in terms of execution +model, resource consumption, communication strategy, and discovery. The three major architectures that we'll focus on — **Time-based +(Deterministic, Polling-based)**, **Data-driven (Event-driven, High-throughput)**, and **Request-driven (Asynchronous, Sporadic +interaction)** — each emphasize different operational priorities. + +1. **Time-based Architecture (Deterministic, Polling-based):** Time-based architecture operates by triggering actions + at fixed intervals, using scheduled polling to ensure consistent, predictable behavior. This architecture ensures + high availability and deterministic execution, meaning that actions always happen at a predefined time, making it + ideal for systems that require reliability. However, it can lead to inefficient CPU usage, as the system continues + to poll even when no new data is available. The communication is synchronous and unidirectional, with the system + staying up-to-date by polling for new information. Discovery is data-centric, meaning that the application focuses + only on the data being communicated and not on the identity of the data source. + +2. **Data-driven Architecture (Event-driven, High-throughput):** In a data-driven architecture, actions are triggered + by events or data changes. The system optimizes for high throughput and performance, making it well-suited for + applications where responsiveness to data is critical. The execution is non-deterministic, meaning that timing + depends on when data arrives, which can lead to unpredictable bottlenecks, especially during data surges. The + communication is unidirectional and driven by updates to data, decoupling the producers and consumers of the data. + Discovery is data-centric, as applications react to events regardless of their origin, optimizing for low latency + and dynamic scalability. + +3. **Request-driven Architecture (Asynchronous, Sporadic interaction):** A request-driven architecture is triggered + only when a request is made, making it ideal for applications that handle sporadic, unpredictable workloads. The + system remains idle during inactivity, saving resources until a task is triggered. This model does not provide + deterministic behavior, and response times depend on when requests arrive. Communication is bi-directional, with + requests and responses flowing between client and server. Discovery is service-instance-centric, requiring knowledge + of specific server instances, especially for stateful systems where session continuity or state preservation is + crucial. + + +.. stkh_req:: Support for Time-based Architectures + :id: STKH_REQ__281 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd - potentially above explanation + :status: valid + + The platform shall support a deterministic, time-based application execution model that triggers logic based on predefined schedules or + polling intervals. + + +.. stkh_req:: Support for Data-driven Architecture + :id: STKH_REQ__282 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd - potentially above explanation + :status: valid + + The platform shall support an event-driven, high-throughput application architecture where execution is triggered by data changes. + +.. stkh_req:: Support for Request-driven Architecture + :id: STKH_REQ__283 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd - potentially above explanation + :status: valid + + The platform shall support a request-driven, asynchronous application architecture that processes requests on-demand. + + + +Execution model +--------------- + +.. stkh_req:: Processes and thread management + :id: STKH_REQ__280 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the following scheduling strategies: + + * Process Management + + * Startup and Shutdown of processes + * Recovery + * Machine State Management (modelled via simple JSON file) + + * Cross-process synchronization of threads (Activities) + + * Event activated multi-process taskchains + * Time-sliced activated multi-process taskchains + * memory management (via PMR), + * signal handling, error handling (FPU Exceptions, other traps …) + +.. stkh_req:: Short application cycles + :id: STKH_REQ__110 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + Cycle times of less then 5 ms on application level shall by supported by the + platform assumed this is supported by the underlying hardware. + +.. stkh_req:: Realtime capabilities + :id: STKH_REQ__111 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the controlled reaction on events + (timing events, interrupts) within a defined timing interval. + +.. stkh_req:: Startup performance + :id: STKH_REQ__112 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support fast startup scenarios e.g. cold boot and + resume from hibernate mode. + +.. stkh_req:: Low power mode + :id: STKH_REQ__113 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support low power modes to safe energy. + +Communication +------------- + +.. stkh_req:: Inter-process Communication + :id: STKH_REQ__2 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: Application software typically consists of multiple processes which need to interact. + :status: valid + + The platform shall support inter-process communication. + + +.. stkh_req:: Intra-process Communication + :id: STKH_REQ__3 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: Application software typically maps software building blocks into the same process. + :status: valid + + The platform shall support intra-process communication. + +.. stkh_req:: Stable application interfaces + :id: STKH_REQ__171 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: In case of incompatible changes on external interface the portability effort shall be reduced. + :status: valid + + The platform shall provide a framework to mitigate incompatible changes on + external interfaces to keep application interfaces stable. + +.. stkh_req:: Extensible External Communication + :id: STKH_REQ__5 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: ECUs need to interact with each other. There are multiple protocols today and more to come in the future. + :status: valid + + The platform shall support external communication via well established protocols e.g. Zenoh, DDS. + + +.. stkh_req:: Safe Communication + :id: STKH_REQ__6 + :reqtype: Functional + :security: NO + :safety: ASIL_D + :rationale: Distributed safe systems often require communication to be safe. + :status: valid + + The platform shall support safe communication. + + +.. stkh_req:: Secure Communication + :id: STKH_REQ__7 + :reqtype: Functional + :security: YES + :safety: QM + :rationale: Distributed secure systems often require secure communication. + :status: valid + + The platform shall support secure communication. + +.. stkh_req:: Supported network protocols + :id: STKH_REQ__160 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support the following automotive network + protocols + + * SOME/IP + * DDS + * UWB including Driver for UWB Peripheral + * SPI (+ CSC ADI & Texas Instruments chipset support) + * Vehicle to Grid + ISO Charge protocols + * AVB + + +.. stkh_req:: Quality of service + :id: STKH_REQ__170 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall provide a framework to ensure quality of service + of applications deployed on the platform. This includes but is not limited + to: + + * QOS for applications + * Controlled latency for communication and scheduling + * Guaranteed network and compute quotas + + +.. stkh_req:: Automotive diagnostics + :id: STKH_REQ__180 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The following diagnostic protocols shall be supported + * UDS (ISO14229) Diagnostics + * Diagnostic trouble codes + * Diagnostic jobs + + +Hardware support +---------------- + +.. stkh_req:: Chipset support for ARM64 and x64 + :id: STKH_REQ__190 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support arm64 and x64 architectures. + + +.. stkh_req:: Virtualization support for debug and testing + :id: STKH_REQ__200 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall run on qemu to enable test and debug in virtualized + environments. + + +.. stkh_req:: Support of container technologies + :id: STKH_REQ__210 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support deployment of self-contained application + bundles + + * Kernel Features: e.g. cgroup, secpol, namespaces as precondition for containerization + * e.g. SOAFFEE Like realtime capable containers: https://www.soafee.io/ + + + +Developer experience +-------------------- + +.. stkh_req:: IDL Support + :id: STKH_REQ__220 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall provide a human readable interface definition language + with decentralized glue code generation. + + +.. stkh_req:: Developer experience and development toolchain + :id: STKH_REQ__230 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support a state-of-the art developer experience for + functional development and application development. + + Features: + + * IDE support for all supported languages. + * IDL Editor with syntax highlighting. + * Connection to qemu and real target via SSH. + * Support of continuous integration and deployment systems. + + +.. stkh_req:: Performance analysis + :id: STKH_REQ__240 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support performance analysis of platform and + application software: + + * Flame-graph visualization for long termed CPU behavior + * RAM usage statistics for long-term Memory behavior + +.. stkh_req:: Tracing of execution + :id: STKH_REQ__241 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the tracing of events (start, stop) of executable + entities and kernel threads on all computation units e.g. + + * CPU + * GPU + * Neural Network Processors + * Image Processors + * etc. + +.. stkh_req:: Tracing of communication + :id: STKH_REQ__242 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the tracing of communication events for internal + and external communication systems. + +.. stkh_req:: Tracing of memory access + :id: STKH_REQ__243 + :reqtype: Non-Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the tracing of memory events (allocation, copy, + de-allocation) for different types of memory e.g. + + * CPU Memory + * GPU Memory + +.. stkh_req:: Timing analysis + :id: STKH_REQ__120 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall support observation, assessment of + timing requirements with state-of-the-art analysis tools. + +.. stkh_req:: Debugging + :id: STKH_REQ__250 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The software platform shall provide a method and interface to enable + debugging of the software on target and in vehicle. + + +.. stkh_req:: Programming languages for application development + :id: STKH_REQ__260 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support implementation of applications in the following + programming languages up to the highest ASIL level as defined in :need:`STKH_REQ__70`: + + * C + * C++ + * Rust + + +.. stkh_req:: Reprocessing and simulation support + :id: STKH_REQ__270 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support data-collection and injection of reprocessed data. + + +.. stkh_req:: Logging support + :id: STKH_REQ__290 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support the following logging setups: + + * Logging to external disk via mounted filesystem on top of PCIe driver + * Logging via second dedicated Ethernet Channel + * Logging/sensor data Gathering via Cloud native filesystem on top of second Ethernet Channel + * Gathering of raw sensor data e.g. video streams + * Diagnostic Log and Trace / Logcat format is supported + * Logging of early startup events + +.. stkh_req:: Previous boot logging + :id: STKH_REQ__291 + :reqtype: Functional + :security: NO + :safety: QM + :rationale: tbd + :status: valid + + The platform shall support logging of data to memory which survives a reboot + cycle. + + Integration -----------