Stakeholder Requirements#

Overall goals#

Reuse of application software via managed APIs		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: This is a usability constraint needed for long maintenance support reqtype: Non-Functional
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__20		Stakeholder requirements

Enable cooperation via standardized APIs		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: To enable cooperation with other cooperation partners. reqtype: Non-Functional
The software platform shall where possible be based on existing standards (e.g. network protocols).
STKH_REQ__30		Stakeholder requirements

Variant management		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__60		Stakeholder requirements

IP protection		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
The software platform shall support cooperation models, where partners do not want to disclose their intellectual property of applications to all other partners.
STKH_REQ__50		Stakeholder requirements

Functional requirements#

File Based Configuration		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: File based configuration allows changes without rebuilding the software. reqtype: Functional
The platform shall support configuration of applications via files (e.g. yaml, json)
STKH_REQ__8		Stakeholder requirements

Support of safe Key/Value store		status: valid security: NO safety: ASIL_B
status: valid security: NO safety: ASIL_B rationale: Key/Value storage is a standard way to structure file based non-volatile memory access. reqtype: Functional
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__350		Stakeholder requirements

Safe Configuration		status: valid security: NO safety: ASIL_B
status: valid security: NO safety: ASIL_B rationale: Configuration files may hold safety relevant information. reqtype: Functional
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__9		Stakeholder requirements

Safe Computation		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D rationale: Safe systems require computations to be done in safe environments. reqtype: Functional
The platform shall support safe computation.
STKH_REQ__10		Stakeholder requirements

Hardware Accelerated Computation		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: High computation loads typically need to be speed up hardware acceleration e.g. in ADAS applications reqtype: Functional
The platform shall support computation accelerated by a Hardware accelerator.
STKH_REQ__11		Stakeholder requirements

Data Persistency		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: Applications typically need to store data across power cycles. reqtype: Functional
The platform shall support to store data on non-volatile memory e.g. disks, flash, etc.
STKH_REQ__12		Stakeholder requirements

Operating System		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: This allows portability of platform on POSIX compliant operating systems. reqtype: Non-Functional
The platform shall support operating systems compliant with IEEE Std 1003.1 (2004 Edition or newer)
STKH_REQ__13		Stakeholder requirements

Video subsystem		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__340		Stakeholder requirements

Compute subsystem		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__330		Stakeholder requirements

Communication with external MCUs/standby controllers		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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
STKH_REQ__310		Stakeholder requirements

Dependability#

Automotive Safety Integrity Level		status: valid security: NO safety: ASIL_B
status: valid security: NO safety: ASIL_B rationale: The platform shall be usable by safety relevant applications. reqtype: Functional
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__70		Stakeholder requirements

Safety features		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D rationale: tbd reqtype: Functional
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__80		Stakeholder requirements

Availability		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall support the development of highly available systems. (see also Availability).
STKH_REQ__90		Stakeholder requirements

Security features		status: valid security: YES safety: QM
status: valid security: YES safety: QM rationale: tbd reqtype: Functional
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
STKH_REQ__140		Stakeholder requirements

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.

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.
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.
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.

Support for Time-based Architectures		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd - potentially above explanation reqtype: Functional
The platform shall support a deterministic, time-based application execution model that triggers logic based on predefined schedules or polling intervals.
STKH_REQ__281		Stakeholder requirements

Support for Data-driven Architecture		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd - potentially above explanation reqtype: Functional
The platform shall support an event-driven, high-throughput application architecture where execution is triggered by data changes.
STKH_REQ__282		Stakeholder requirements

Support for Request-driven Architecture		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd - potentially above explanation reqtype: Functional
The platform shall support a request-driven, asynchronous application architecture that processes requests on-demand.
STKH_REQ__283		Stakeholder requirements

Execution model#

Processes and thread management		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__280		Stakeholder requirements

Short application cycles		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__110		Stakeholder requirements

Realtime capabilities		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall support the controlled reaction on events (timing events, interrupts) within a defined timing interval.
STKH_REQ__111		Stakeholder requirements

Startup performance		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall support fast startup scenarios e.g. cold boot and resume from hibernate mode.
STKH_REQ__112		Stakeholder requirements

Low power mode		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall support low power modes to safe energy.
STKH_REQ__113		Stakeholder requirements

Communication#

Inter-process Communication		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: Application software typically consists of multiple processes which need to interact. reqtype: Functional
The platform shall support inter-process communication.
STKH_REQ__2		Stakeholder requirements

Intra-process Communication		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: Application software typically maps software building blocks into the same process. reqtype: Functional
The platform shall support intra-process communication.
STKH_REQ__3		Stakeholder requirements

Stable application interfaces		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: In case of incompatible changes on external interface the portability effort shall be reduced. reqtype: Functional
The platform shall provide a framework to mitigate incompatible changes on external interfaces to keep application interfaces stable.
STKH_REQ__171		Stakeholder requirements

Extensible External Communication		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: ECUs need to interact with each other. There are multiple protocols today and more to come in the future. reqtype: Functional
The platform shall support external communication via well established protocols e.g. Zenoh, DDS.
STKH_REQ__5		Stakeholder requirements

Safe Communication		status: valid security: NO safety: ASIL_D
status: valid security: NO safety: ASIL_D rationale: Distributed safe systems often require communication to be safe. reqtype: Functional
The platform shall support safe communication.
STKH_REQ__6		Stakeholder requirements

Secure Communication		status: valid security: YES safety: QM
status: valid security: YES safety: QM rationale: Distributed secure systems often require secure communication. reqtype: Functional
The platform shall support secure communication.
STKH_REQ__7		Stakeholder requirements

Supported network protocols		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__160		Stakeholder requirements

Quality of service		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__170		Stakeholder requirements

Automotive diagnostics		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The following diagnostic protocols shall be supported * UDS (ISO14229) Diagnostics * Diagnostic trouble codes * Diagnostic jobs
STKH_REQ__180		Stakeholder requirements

Hardware support#

Chipset support for ARM64 and x64		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall support arm64 and x64 architectures.
STKH_REQ__190		Stakeholder requirements

Virtualization support for debug and testing		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall run on qemu to enable test and debug in virtualized environments.
STKH_REQ__200		Stakeholder requirements

Support of container technologies		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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/
STKH_REQ__210		Stakeholder requirements

Developer experience#

IDL Support		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall provide a human readable interface definition language with decentralized glue code generation.
STKH_REQ__220		Stakeholder requirements

Developer experience and development toolchain		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
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__230		Stakeholder requirements

Performance analysis		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
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__240		Stakeholder requirements

Tracing of execution		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
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__241		Stakeholder requirements

Tracing of communication		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
The platform shall support the tracing of communication events for internal and external communication systems.
STKH_REQ__242		Stakeholder requirements

Tracing of memory access		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Non-Functional
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__243		Stakeholder requirements

Timing analysis		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall support observation, assessment of timing requirements with state-of-the-art analysis tools.
STKH_REQ__120		Stakeholder requirements

Debugging		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The software platform shall provide a method and interface to enable debugging of the software on target and in vehicle.
STKH_REQ__250		Stakeholder requirements

Programming languages for application development		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall support implementation of applications in the following programming languages up to the highest ASIL level as defined in Automotive Safety Integrity... (STKH_REQ__70): C C++ Rust
STKH_REQ__260		Stakeholder requirements

Reprocessing and simulation support		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall support data-collection and injection of reprocessed data.
STKH_REQ__270		Stakeholder requirements

Logging support		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
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__290		Stakeholder requirements

Previous boot logging		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: tbd reqtype: Functional
The platform shall support logging of data to memory which survives a reboot cycle.
STKH_REQ__291		Stakeholder requirements

Integration#

Multirepo integration		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: Allow independent development of software modules reqtype: Non-Functional is satisfied by: TOOL_REQ__BAZEL__unified_build_test_integration
Integration of multiple repositories shall be supported in a unified workflow.
STKH_REQ__INT_multi_repo_integration		Stakeholder requirements

Quality#

Document assumptions and design decisions		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: This is a usability constraint needed for long term maintenance support reqtype: Non-Functional
All assumptions and design decisions made shall be specified as requirements and agreed within the SCORE community.
STKH_REQ__QLY_document_assumptions_and_design_decisions		Stakeholder requirements

Requirements Engineering#

Requirements traceability		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: This is a usability constraint needed for long term maintenance support reqtype: Non-Functional
All requirements shall be linked from lower to upper level, whereby the top-level are the stakeholder requirements.
STKH_REQ__RE_requirements_traceability		Stakeholder requirements

Document requirements as code		status: valid security: NO safety: QM
status: valid security: NO safety: QM rationale: In this project no external tool or service is used. Therefore as-code is the selected option. reqtype: Non-Functional is satisfied by: TOOL_REQ__Sphinx-needs__Process_Modelling
Requirements shall be documented as code (Docs-as-code).
STKH_REQ__RE_requirements_as_code		Stakeholder requirements