Stakeholder Requirements

Overall goals

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

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

Variant management		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__persistency__variant_management
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__overall_goals__variant_management		Stakeholder Requirement

IP protection		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__overall_goals__ip_protection		Stakeholder Requirement

Functional requirements

File Based Configuration		status: valid security: NO safety: QM
rationale: File based configuration allows changes without rebuilding the software. reqtype: Functional satisfied by: feat_req__config_mgmt__term_parameter, feat_req__config_mgmt__term_parameter_set, feat_req__config_mgmt__central_housekeeping, feat_req__config_mgmt__parameter_set_relation, feat_req__config_mgmt__prm_name_unique, feat_req__config_mgmt__prm_set_name_unique, feat_req__config_mgmt__prm_set_cfg_content, feat_req__config_mgmt__prm_set_cfg_source, feat_req__config_mgmt__parameter_modification, feat_req__config_mgmt__provider_interface, feat_req__config_mgmt__parameter_set_access, feat_req__lifecycle__modular_config_support, feat_req__lifecycle__session_extension, feat_req__lifecycle__clustering_modules_supp, feat_req__persistency__default_value_file, feat_req__persistency__config_file
The platform shall support configuration of applications via files (e.g. yaml, json)
stkh_req__functional_req__file_based		Stakeholder Requirement

Support of safe Key/Value store		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 satisfied by: feat_req__persistency__maximum_size, feat_req__persistency__multiple_kvs, feat_req__persistency__support_datatype_keys, feat_req__persistency__support_datatype_value, feat_req__persistency__default_values, feat_req__persistency__default_value_get, feat_req__persistency__default_value_reset, feat_req__persistency__persistency, feat_req__persistency__integrity_check, feat_req__persistency__versioning, feat_req__persistency__update_mechanism, feat_req__persistency__snapshots, feat_req__persistency__tooling
The software platform shall provide towards the applications a safe (ISO26262-2018) key/value store. Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__functiona_req__support_of_store		Stakeholder Requirement

Safe Configuration		status: valid security: NO safety: ASIL_B
rationale: Configuration files may hold safety relevant information. reqtype: Functional satisfied by: feat_req__config_mgmt__prm_set_qualifier, feat_req__config_mgmt__prm_initial_qualifier
The platform shall support safe configuration. Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__functional_req__safe_config		Stakeholder Requirement

Safe Computation		status: valid security: NO safety: ASIL_B
rationale: Safe systems require computations to be done in safe environments. reqtype: Functional satisfied by: feat_req__logging__asil_support
The platform shall support safe computation. Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__functional_req__safe_comput		Stakeholder Requirement

Base Libraries		status: valid security: YES safety: QM
rationale: Common libraries reduce duplication, improve consistency and quality across components. reqtype: Functional satisfied by: feat_req__baselibs__core_utilities, feat_req__baselibs__safety, feat_req__baselibs__multi_language_apis, feat_req__baselibs__consistent_apis, feat_req__baselibs__maintainable_design, feat_req__baselibs__security, feat_req__baselibs__json_library, feat_req__baselibs__result_library
The software platform shall provide a set of base libraries offering common functionality for platform components.
stkh_req__functional_req__base_libraries		Stakeholder Requirement

Hardware Accelerated Computation		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__functional_req__hardware_comput		Stakeholder Requirement

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

Operating System		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__functional_req__operating_system		Stakeholder Requirement

Video subsystem		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__functional_req__video_subsystem		Stakeholder Requirement

Compute subsystem		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__functional_req__comp_subsystem		Stakeholder Requirement

Communication with external MCUs/standby controllers		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__functional_req__comm_with_control		Stakeholder Requirement

Dependability

Automotive Safety Integrity Level		status: valid security: NO safety: ASIL_B
rationale: The platform shall be usable by safety relevant applications. reqtype: Functional satisfied by: feat_req__baselibs__safety, feat_req__baselibs__multi_language_apis, feat_req__orchestration__exec_preempt_safety, feat_req__orchestration__exec_safe_task_prio, feat_req__orchestration__orch_safety_tasks, feat_req__orchestration__gen_preempt_act, feat_req__orchestration__gen_excl_ipc
The software platform shall support applications with an automotive safety integrity level up to ASIL-B. Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__dependability__automotive_safety		Stakeholder Requirement

Safety features		status: valid security: NO safety: ASIL_B
rationale: tbd reqtype: Functional satisfied by: feat_req__feo__alive_supervision, feat_req__feo__deadline_supervision, feat_req__feo__logical_supervision, feat_req__feo__trustable_computation, feat_req__feo__response_term_request, feat_req__feo__secondary_conn_timeout, feat_req__feo__act_startup_error, feat_req__feo__act_alloc_error, feat_req__feo__act_timeout, feat_req__feo__startup_timeout, feat_req__feo__act_stepping_error, feat_req__feo__act_shutdown_error, feat_req__lifecycle__secpol_non_root, feat_req__lifecycle__support_secpol_type, feat_req__lifecycle__aslr_support, feat_req__persistency__eng_mode, feat_req__persistency__field_mode
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 Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__dependability__safety_features		Stakeholder Requirement

Availability		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__feo__response_term_request, feat_req__feo__secondary_conn_timeout, feat_req__feo__act_startup_error, feat_req__feo__act_alloc_error, feat_req__feo__act_timeout, feat_req__feo__startup_timeout, feat_req__feo__act_stepping_error, feat_req__feo__act_shutdown_error, feat_req__persistency__async_api
The software platform shall support the development of highly available systems. (see also Availability).
stkh_req__dependability__availability		Stakeholder Requirement

Security features		status: valid security: YES safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__logging__security_log_access, feat_req__com__acl_placement, feat_req__com__acl_per_service_instance, feat_req__com__acl_for_producer, feat_req__com__acl_for_consumer, feat_req__orchestration__gen_excl_ipc, feat_req__persistency__access_control
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__dependability__security_features		Stakeholder Requirement

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.

Support for Time-based Architectures		status: valid security: NO safety: ASIL_B
rationale: tbd - potentially above explanation reqtype: Functional satisfied by: feat_req__com__time_based_arch, feat_req__com__interfaces, feat_req__com__event_type, feat_req__com__producer_consumer, feat_req__feo__application, feat_req__feo__activity, feat_req__feo__task_chain, feat_req__feo__service_activity, feat_req__feo__agent, feat_req__feo__application_lifecycle, feat_req__feo__activity_init, feat_req__feo__activitiy_step, feat_req__feo__activity_shutdown, feat_req__feo__alive_supervision, feat_req__feo__deadline_supervision, feat_req__feo__logical_supervision, feat_req__feo__trustable_computation, feat_req__orchestration__orch_static_graphs, feat_req__orchestration__orch_ctrl_flows, feat_req__orchestration__orch_event_sync, feat_req__orchestration__orch_fault_mon, feat_req__orchestration__orch_code_api, feat_req__orchestration__orch_single_deploy, feat_req__orchestration__orch_multi_prog, feat_req__orchestration__orch_event_comm
The platform shall support a deterministic, time-based application execution model that triggers logic based on predefined schedules or polling intervals.
stkh_req__app_architectures__support_time		Stakeholder Requirement

Support for Data-driven Architecture		status: valid security: NO safety: QM
rationale: tbd - potentially above explanation reqtype: Functional satisfied by: feat_req__com__data_driven_arch, feat_req__com__interfaces, feat_req__com__zero_copy, feat_req__ipc__zero_copy, feat_req__feo__application, feat_req__feo__activity, feat_req__feo__task_chain, feat_req__feo__service_activity, feat_req__feo__agent, feat_req__feo__application_lifecycle, feat_req__feo__activity_init, feat_req__feo__activitiy_step, feat_req__feo__activity_shutdown, feat_req__feo__alive_supervision, feat_req__feo__deadline_supervision, feat_req__feo__logical_supervision, feat_req__feo__trustable_computation, feat_req__persistency__events
The platform shall support an event-driven, high-throughput application architecture where execution is triggered by data changes.
stkh_req__app_architectures__support_data		Stakeholder Requirement

Support for Request-driven Architecture		status: valid security: NO safety: QM
rationale: tbd - potentially above explanation reqtype: Functional satisfied by: feat_req__com__request_driven_arch, feat_req__com__interfaces, feat_req__com__method, feat_req__com__signal, feat_req__com__zero_copy, feat_req__persistency__async_api
The platform shall support a request-driven, asynchronous application architecture that processes requests on-demand.
stkh_req__app_architectures__support_request		Stakeholder Requirement

Execution model

Processes and thread management		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__feo__task_chain, feat_req__feo__application_lifecycle, feat_req__feo__activity_init, feat_req__feo__activitiy_step, feat_req__feo__activity_shutdown, feat_req__feo__response_term_request, feat_req__feo__secondary_conn_timeout, feat_req__feo__act_startup_error, feat_req__feo__act_alloc_error, feat_req__feo__act_timeout, feat_req__feo__startup_timeout, feat_req__feo__act_stepping_error, feat_req__feo__act_shutdown_error, feat_req__lifecycle__launch_support, feat_req__lifecycle__process_ordering, feat_req__lifecycle__parallel_launch_support, feat_req__lifecycle__custom_cond_support, feat_req__lifecycle__process_input_output, feat_req__lifecycle__process_launch_args, feat_req__lifecycle__debug_support, feat_req__lifecycle__support_held_state, feat_req__lifecycle__uid_gid_support, feat_req__lifecycle__launch_priority_support, feat_req__lifecycle__cwd_support, feat_req__lifecycle__terminal_support, feat_req__lifecycle__std_handle_redir, feat_req__lifecycle__retries_configurable, feat_req__lifecycle__capability_support, feat_req__lifecycle__fd_inheritance, feat_req__lifecycle__supplementary_groups, feat_req__lifecycle__scheduling_policy, feat_req__lifecycle__runmask_support, feat_req__lifecycle__process_rlimit_support, feat_req__lifecycle__detach_parent_process, feat_req__lifecycle__waitfor_support, feat_req__lifecycle__cond_process_start, feat_req__lifecycle__total_wait_time_support, feat_req__lifecycle__polling_interval, feat_req__lifecycle__validate_conditions, feat_req__lifecycle__validation_conditions, feat_req__lifecycle__launcher_status_storage, feat_req__lifecycle__condition_check_method, feat_req__lifecycle__config_actions_cond, feat_req__lifecycle__path_condition_check, feat_req__lifecycle__env_variable_cond_check, feat_req__lifecycle__dependency_check, feat_req__lifecycle__check_dependency_exec, feat_req__lifecycle__define_swc_dependencies, feat_req__lifecycle__stop_sequence, feat_req__lifecycle__running_processes, feat_req__lifecycle__drop_supervsion, feat_req__lifecycle__multi_start_support, feat_req__lifecycle__consistent_dependencies, feat_req__lifecycle__stop_process_dependents, feat_req__lifecycle__stop_order_spec, feat_req__lifecycle__run_target_support, feat_req__lifecycle__start_named_run_target, feat_req__lifecycle__switch_run_targets, feat_req__lifecycle__process_state_comm, feat_req__lifecycle__configurable_timeout, feat_req__lifecycle__process_termination, feat_req__lifecycle__terminationn_dependency, feat_req__lifecycle__time_to_wait_config, feat_req__lifecycle__launch_manager_shutdown, feat_req__lifecycle__slow_shutdown_support, feat_req__lifecycle__fast_shutdown_support, feat_req__lifecycle__launcher_exit_shutdown, feat_req__lifecycle__shutdown_signal, feat_req__lifecycle__control_commands, feat_req__lifecycle__query_commands, feat_req__lifecycle__controlif_status, feat_req__lifecycle__request_run_target_start, feat_req__lifecycle__monitor_abnormal_term, feat_req__lifecycle__ext_monitor_notify, feat_req__lifecycle__recovery_action_support, feat_req__lifecycle__recov_run_target_switch, feat_req__lifecycle__smart_watchdog_config, feat_req__lifecycle__configurable_wait_time, feat_req__lifecycle__monitoring_processes, feat_req__lifecycle__failure_detect, feat_req__lifecycle__liveliness_detection, feat_req__lifecycle__process_monitoring, feat_req__lifecycle__process_failure_react, feat_req__lifecycle__multi_instance_support, feat_req__lifecycle__lm_self_health_check, feat_req__lifecycle__lm_ext_watchdog_notify, feat_req__lifecycle__lm_ext_wdg_failed_test, feat_req__lifecycle__lm_ext_watchdog_cfg, feat_req__lifecycle__dependency_visu, feat_req__lifecycle__runtime_config_compat, feat_req__lifecycle__central_default_defines, feat_req__lifecycle__lazy_check, feat_req__lifecycle__deps_visualization, feat_req__lifecycle__offline_config_valid, feat_req__orchestration__exec_async_rt, feat_req__orchestration__exec_yielding, feat_req__orchestration__exec_block_threads, feat_req__orchestration__exec_preempt_safety, feat_req__orchestration__exec_safe_task_prio, feat_req__orchestration__exec_fixed_pool, feat_req__orchestration__exec_os_prio, feat_req__orchestration__exec_thread_aff, feat_req__orchestration__exec_pool_isolation, feat_req__orchestration__exec_no_int_prios, feat_req__orchestration__exec_fifo_fair_sched, feat_req__orchestration__exec_scale_instances, feat_req__orchestration__orch_static_graphs, feat_req__orchestration__orch_ctrl_flows, feat_req__orchestration__orch_event_sync, feat_req__orchestration__orch_fault_mon, feat_req__orchestration__orch_code_api, feat_req__orchestration__orch_single_deploy, feat_req__orchestration__orch_multi_prog, feat_req__orchestration__orch_event_comm, feat_req__orchestration__orch_safety_tasks, feat_req__orchestration__obsv_trace_corr, feat_req__orchestration__obsv_lifecycle_qm, feat_req__orchestration__obsv_flow_vis, feat_req__orchestration__obsv_fw_integ, feat_req__orchestration__ext_health_inds, feat_req__orchestration__ext_task_health, feat_req__orchestration__gen_det_scale, feat_req__orchestration__gen_preempt_act, feat_req__orchestration__gen_excl_ipc
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__execution_model__processes		Stakeholder Requirement

Short application cycles		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__persistency__fast_access
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__execution_model__short_app_cycles		Stakeholder Requirement

Realtime capabilities		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__execution_model__realtime_cap		Stakeholder Requirement

Startup performance		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__execution_model__startup_perf		Stakeholder Requirement

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

Communication

Inter-process Communication		status: valid security: NO safety: QM
rationale: Application software typically consists of multiple processes which need to interact. reqtype: Functional satisfied by: feat_req__com__time_based_arch, feat_req__com__data_driven_arch, feat_req__com__request_driven_arch, feat_req__com__interfaces, feat_req__com__event_type, feat_req__com__method, feat_req__com__signal, feat_req__com__producer_consumer, feat_req__com__service_instance, feat_req__com__service_instance_names, feat_req__com__versioning, feat_req__com__service_location_transparency, feat_req__com__stateless_communication, feat_req__com__service_instance_granularity, feat_req__com__service_discovery, feat_req__com__safe_communication, feat_req__com__data_corruption, feat_req__com__data_reordering, feat_req__com__data_repetition, feat_req__com__data_loss, feat_req__com__zero_copy, feat_req__com__testability_mock_api, feat_req__com__testability_fake_binding, feat_req__com__multi_binding_support, feat_req__com__binding_agnostic_api, feat_req__com__multi_binding_depl, feat_req__com__depl_config_runtime, feat_req__com__acl_placement, feat_req__com__acl_per_service_instance, feat_req__com__acl_for_producer, feat_req__com__acl_for_consumer, feat_req__com__asil, feat_req__ipc__zero_copy, feat_req__ipc__confidentiality, feat_req__ipc__integrity, feat_req__ipc__availability, feat_req__orchestration__gen_excl_ipc
The platform shall support inter-process communication.
stkh_req__communication__inter_process		Stakeholder Requirement

ABI Compatible Data Types		status: valid security: NO safety: QM
rationale: ABI compatiblity ensures that the same memory location is correctly interpreted by different programming languages. reqtype: Functional satisfied by: feat_req__abi_compatible_data_types__bool_sz, feat_req__abi_compatible_data_types__int_fix, feat_req__abi_compatible_data_types__flt_sz, feat_req__abi_compatible_data_types__arr_fix, feat_req__abi_compatible_data_types__st_tpl, feat_req__abi_compatible_data_types__enum_udr, feat_req__abi_compatible_data_types__nop_mt, feat_req__abi_compatible_data_types__compabi, feat_req__abi_compatible_data_types__prv_abv, feat_req__abi_compatible_data_types__abv_fld, feat_req__abi_compatible_data_types__abv_noa, feat_req__abi_compatible_data_types__abv_ovf, feat_req__abi_compatible_data_types__abo_api, feat_req__abi_compatible_data_types__prv_ari, feat_req__abi_compatible_data_types__ari_flg, feat_req__abi_compatible_data_types__ari_api
The platform shall support ABI compatible data types for zero-copy communication between Rust and C++ applications.
stkh_req__communication__abi_compatible		Stakeholder Requirement

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

Stable application interfaces		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__communication__stable_app_inter		Stakeholder Requirement

Extensible External Communication		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 satisfied by: feat_req__some_ip_gateway__stack_plugin_ifc
The platform shall support external communication via well established protocols e.g. Zenoh, DDS.
stkh_req__communication__extensible_external		Stakeholder Requirement

Safe Communication		status: valid security: NO safety: ASIL_B
rationale: Distributed safe systems often require communication to be safe. reqtype: Functional satisfied by: feat_req__com__time_based_arch, feat_req__com__interfaces, feat_req__com__method, feat_req__com__producer_consumer, feat_req__com__service_instance, feat_req__com__service_instance_names, feat_req__com__versioning, feat_req__com__service_location_transparency, feat_req__com__stateless_communication, feat_req__com__service_instance_granularity, feat_req__com__service_discovery, feat_req__com__safe_communication, feat_req__com__data_corruption, feat_req__com__data_reordering, feat_req__com__data_repetition, feat_req__com__data_loss, feat_req__com__depl_config_runtime, feat_req__com__tracing, feat_req__com__asil, feat_req__some_ip_gateway__e2e_plugin_ifc
The platform shall support safe communication. Note: This is part of 0.5 release and therefore can only support ASIL_B. Goal is ASIL_D.
stkh_req__communication__safe		Stakeholder Requirement

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

Supported network protocols		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__some_ip_gateway__stack_plugin_ifc, feat_req__some_ip_gateway__someip_protocol, feat_req__some_ip_gateway__e2e_specs, feat_req__some_ip_gateway__someip_sd_protocol
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__communication__supported_net		Stakeholder Requirement

Quality of service		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__communication__service_quality		Stakeholder Requirement

Automotive diagnostics		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional
The following diagnostic protocols shall be supported * SOVD (ISO 17978) * UDS (ISO 14229) Diagnostics * Diagnostic trouble codes * Diagnostic jobs
stkh_req__communication__auto_diagnostics		Stakeholder Requirement

Time

Vehicle Time base Synchronization		status: valid security: NO safety: QM
rationale: Enables the system to compare events chronologically. reqtype: Functional satisfied by: feat_req__time__vehicle_time_sync, feat_req__time__vehicle_time_sync_prec
The software platform shall provide a time synchronization framework to synchronize its clock to Time Master within the vehicle.
stkh_req__time__vehicle_time_sync		Stakeholder Requirement

Vehicle Time base API		status: valid security: NO safety: QM
rationale: Enables an application to correlate its data with a vehicle-internal time reference for event timestamp and chronological events comparison. reqtype: Functional satisfied by: feat_req__time__vehicle_time_time_api, feat_req__time__vehicle_time_acc_qual_api, feat_req__time__vehicle_time_time_pt_qual, feat_req__time__vehicle_time_ctrl_flow
The software platform shall provide access to synchronized vehicle time.
stkh_req__time__vehicle_time_api		Stakeholder Requirement

Synchronize the HW clock with Vehicle Time		status: valid security: NO safety: QM
rationale: Enables the system to compare events from different ECUs chronologically, using the same time base for timestamping ingress and egress frames. reqtype: Functional
The software platform shall synchronize the local HW clock to vehicle time.
stkh_req__time__hw_clock_sync		Stakeholder Requirement

Time Synchronization with external sources		status: valid security: YES safety: QM
rationale: Enables the system to validate a certificate or token with temporal validity conditions, adding a UTC-timestamp to a data set. reqtype: Functional satisfied by: feat_req__time__abs_sync
The software platform shall provide a framework to synchronize the clock to external-to-vehicle absolute time base (UTC).
stkh_req__time__absolute_time_sync		Stakeholder Requirement

Absolute time base API		status: valid security: YES safety: QM
rationale: Enables an application to correlate its data with an absolute vehicle-external time reference for event timestamping and chronological events comparison. reqtype: Functional satisfied by: feat_req__time__abs_base_api, feat_req__time__abs_acc_qual, feat_req__time__abs_sec_qual
The software platform shall provide access to the absolute time base, synchronized with external time sources.
stkh_req__time__absolute_time_api		Stakeholder Requirement

Local High precision Clock API		status: valid security: NO safety: QM
rationale: Enables an application to get the current system time, which is essential for time-sensitive operations and event scheduling, via common, mockable and standardized API. reqtype: Functional satisfied by: feat_req__time__high_prec_clock_api
The software platform shall provide access to the current high precision clock from the system time provider in nanoseconds. Note: to which clock the high precision clock is mapped, depends on the system design.
stkh_req__time__high_precision_clock_api		Stakeholder Requirement

Local Monotonic Clock API		status: valid security: NO safety: QM
rationale: Enables an application to get the current system time, which is essential for time-sensitive operations and event scheduling, via common, mockable and standardized API. reqtype: Functional satisfied by: feat_req__time__monotonic_clock_api
The software platform shall provide access to the current monotonic clock from the system time provider. Note: to which clock the monotonic clock is mapped, depends on the system design.
stkh_req__time__monotonic_clock_api		Stakeholder Requirement

AI Platform

On-board ML Workloads		status: valid security: NO safety: QM
rationale: Modern vehicles require the integration of ML capabilities to remain competitive and support customer expectations. reqtype: Functional satisfied by: feat_req__ai_platform__workloads_execution
The platform shall support the execution of traditional ML workloads on-board.
stkh_req__ai_platform__enablement		Stakeholder Requirement

Support for Safety-Critical ML		status: valid security: NO safety: ASIL_B
rationale: Some ML-based functionality is required to be certified up to ASIL-B. reqtype: Functional satisfied by: feat_req__ai_platform__safety_backends
The platform shall support safety-compliant (ASIL-B) deployment of AI/ML components, including inference backends and pipelines.
stkh_req__ai_platform__safety_critical		Stakeholder Requirement

Runtime Efficiency for Edge Devices		status: valid security: NO safety: QM
rationale: Automotive platforms have limited compute and thermal budgets. reqtype: Non-Functional satisfied by: feat_req__ai_platform__embedded_efficiency
The AI platform shall be optimized for runtime performance and memory footprint on embedded hardware targets.
stkh_req__ai_platform__runtime_efficiency		Stakeholder Requirement

Platform Portability (QNX + Linux)		status: valid security: NO safety: QM
rationale: AI/ML use cases span both safety and non-safety environments, requiring portability across operating systems. reqtype: Non-Functional satisfied by: feat_req__ai_platform__qnx_linux_support
The platform shall support both QNX (for safety) and Linux (for GenAI and flexibility) with reusable components.
stkh_req__ai_platform__platform_portability		Stakeholder Requirement

Secure Model Execution		status: valid security: YES safety: QM
rationale: AI model execution must be protected against tampering or abuse. reqtype: Functional satisfied by: feat_req__ai_platform__model_verification
The platform shall ensure secure, verified, and integrity-checked model execution.
stkh_req__ai_platform__model_security		Stakeholder Requirement

Deterministic Execution Paths		status: valid security: NO safety: ASIL_B
rationale: Safety certification requires predictable and bounded system behavior. reqtype: Non-Functional satisfied by: feat_req__ai_platform__static_backend
The platform shall ensure deterministic behavior for AI components used in safety-relevant paths.
stkh_req__ai_platform__runtime_determinism		Stakeholder Requirement

On-board GenAI Workloads		status: valid security: NO safety: QM
rationale: Modern vehicles require the integration of AI/ML capabilities to remain competitive and support customer expectations. reqtype: Functional satisfied by: feat_req__gen_ai__workloads_execution
The platform shall support the execution of Generative AI workloads on-board.
stkh_req__gen_ai__enablement		Stakeholder Requirement

GenAI User Interaction		status: valid security: YES safety: QM
rationale: HMIs are expected to support intelligent, natural interaction using LLM-based assistants. reqtype: Functional satisfied by: feat_req__gen_ai__ui
The platform shall support on-device GenAI-based models with user interaction.
stkh_req__gen_ai__interaction		Stakeholder Requirement

Action Safety and Governance		status: valid security: YES safety: ASIL_B
rationale: GenAI output may be unpredictable or unsafe and must be controlled before affecting vehicle behavior. reqtype: Functional satisfied by: feat_req__gen_ai__validator
The platform shall validate all actions proposed by GenAI models against safety and policy rules prior to execution.
stkh_req__gen_ai__safety_filter		Stakeholder Requirement

Seamless Integration with Vehicle Systems		status: valid security: YES safety: ASIL_B
rationale: AI components must interact with vehicle state and control interfaces. reqtype: Functional satisfied by: feat_req__gen_ai__structured_vapi
The platform shall expose structured APIs to access vehicle state and execute safe commands.
stkh_req__gen_ai__vehicle_com		Stakeholder Requirement

Diagnostics and Fault Management

Diagnostic via SOVD		status: valid security: YES safety: QM
rationale: Enables modern, scalable diagnostics using a standard REST-based protocol to improve integration, interoperability, and maintainability. reqtype: Functional satisfied by: feat_req__diagnostics__sovd_std, feat_req__diagnostics__sovd_server, feat_req__diagnostics__sovd_config, feat_req__diagnostics__sovd_config_mgr, feat_req__diagnostics__sovd_client, feat_req__diagnostics__sovd_client_core, feat_req__diagnostics__internal_com
The system shall support vehicle diagnostics via the SOVD protocol as defined in ISO 17978, to allow scalable and secure diagnostic access.
stkh_req__diagnostics__via_sovd		Stakeholder Requirement

Fault Reporting Infrastructure		status: valid security: YES safety: QM
rationale: Enables applications and components to report faults in a structured, reusable, and system-wide accessible manner. reqtype: Functional satisfied by: feat_req__diagnostics__fault_lib, feat_req__diagnostics__fault_lib_debounce, feat_req__diagnostics__fault_manager, feat_req__diagnostics__db, feat_req__diagnostics__db_persistence
The system shall support a reusable fault reporting infrastructure that enables applications and platform components to report, persist, and manage diagnostic fault information.
stkh_req__diagnostics__fault_reporting		Stakeholder Requirement

Readout DTCs via SOVD		status: valid security: YES safety: QM
rationale: Enables reading of Diagnostic Trouble Codes (DTCs) from the ECU for various use-cases like production or maintenance. reqtype: Functional satisfied by: feat_req__diagnostics__fault_manager, feat_req__diagnostics__db, feat_req__diagnostics__internal_com
The system shall provide users the ability to retrieve current Diagnostic Trouble Codes (DTCs) from the ECU via the SOVD protocol.
stkh_req__diagnostics__dtc_read_sovd		Stakeholder Requirement

Extensibility of Diagnostic Services		status: valid security: YES safety: QM
rationale: Enables OEMs and developers to implement system-specific or project-specific routines for diagnostic control and testing. reqtype: Functional satisfied by: feat_req__diagnostics__service_app, feat_req__diagnostics__oem_plugin
The diagnostic system shall support extensibility mechanisms that allow integration of custom diagnostic services and routines via the SOVD interface.
stkh_req__diagnostics__custom_services		Stakeholder Requirement

Compatibility with UDS Testers		status: valid security: YES safety: QM
rationale: Ensures continued usability of existing test infrastructure, avoiding costly replacement of legacy tools and ensuring fulfillment of legal requirements. reqtype: Functional satisfied by: feat_req__diagnostics__uds2sovd_proxy, feat_req__diagnostics__uds2sovd_odx
The diagnostic system shall provide compatibility with UDS-based testers by offering a proxy to translate UDS requests into SOVD-compatible actions.
stkh_req__diagnostics__uds_tester_compat		Stakeholder Requirement

Compatibility with UDS ECUs		status: valid security: YES safety: QM
rationale: Ensures continued operability of ECUs that are not SOVD-capable. reqtype: Functional satisfied by: feat_req__diagnostics__classic_adapter, feat_req__diagnostics__classic_adapter_odx
The diagnostic system shall support integration with ECUs that use UDS by providing a compatibility adapter to translate SOVD requests to UDS commands.
stkh_req__diagnostics__uds_ecus		Stakeholder Requirement

Support for Distributed and Multi-ECU Diagnostics		status: valid security: YES safety: QM
rationale: Enables the system to operate in modern, distributed vehicle architectures where diagnostics span multiple ECUs and subsystems. reqtype: Functional satisfied by: feat_req__diagnostics__sovd_gateway
The diagnostic system shall support distributed diagnostics across multiple ECUs and network segments, enabling routing and aggregation of diagnostic data.
stkh_req__diagnostics__distributed_support		Stakeholder Requirement

Secure Access to Diagnostic Interfaces		status: valid security: YES safety: QM
rationale: Diagnostic access allows deep system introspection and manipulation, which must be protected against unauthorized use. reqtype: Functional satisfied by: feat_req__diagnostics__sovd_server, feat_req__diagnostics__sovd_auth_mgr, feat_req__diagnostics__sovd_client
The diagnostic system shall enforce secure access control for all diagnostic interfaces, including authentication, encryption, and role-based access enforcement.
stkh_req__diagnostics__secure_access		Stakeholder Requirement

Hardware support

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

Virtualization support for debug and testing		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__hardware_support__debug_and_test		Stakeholder Requirement

Support of container technologies		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__hardware_support__container_tech		Stakeholder Requirement

Developer experience

IDL Support		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__dev_experience__idl_support		Stakeholder Requirement

Developer experience and development toolchain		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__dev_experience__dev_toolchain		Stakeholder Requirement

Performance analysis		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__dev_experience__perf_analysis		Stakeholder Requirement

Tracing of execution		status: valid security: NO safety: QM
rationale: tbd reqtype: Non-Functional satisfied by: feat_req__orchestration__obsv_trace_corr, feat_req__orchestration__obsv_lifecycle_qm, feat_req__orchestration__obsv_flow_vis, feat_req__orchestration__obsv_fw_integ
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__dev_experience__tracing_of_exec		Stakeholder Requirement

Tracing of communication		status: valid security: NO safety: ASIL_B
rationale: tbd reqtype: Non-Functional satisfied by: feat_req__com__tracing
The platform shall support the tracing of communication events for internal and external communication systems.
stkh_req__dev_experience__tracing_of_comm		Stakeholder Requirement

Tracing of memory access		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__dev_experience__tracing_of_memory		Stakeholder Requirement

Timing analysis		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__dev_experience__timing_analysis		Stakeholder Requirement

Debugging		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__time__vehicle_time_sync_log, feat_req__time__abs_sync_log
The software platform shall provide a method and interface to enable debugging of the software on target and in vehicle.
stkh_req__dev_experience__debugging		Stakeholder Requirement

Mockup implementation for application testing		status: valid security: NO safety: QM
rationale: Enables unit, component and integration testing for both platform related and non-platform related applications. reqtype: Functional satisfied by: feat_req__time__mocking_apis
The software platform shall provide support for mocking its public interfaces, enabling unit, component and integration testing of applications.
stkh_req__dev_experience__mockup_public_apis		Stakeholder Requirement

Programming languages for application development		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__logging__compat_languages, feat_req__baselibs__multi_language_apis, feat_req__baselibs__consistent_apis, feat_req__com__multi_lang, feat_req__com__lang_idioms, feat_req__com__lang_infra, feat_req__persistency__cpp_rust_interop
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__dependability__automotive_safety): C C++ Rust
stkh_req__dev_experience__prog_languages		Stakeholder Requirement

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

Logging support		status: valid security: NO safety: QM
rationale: tbd reqtype: Functional satisfied by: feat_req__logging__timestamping_local, feat_req__logging__timestamping_original, feat_req__logging__timestamping_sync, feat_req__logging__severity_levels, feat_req__logging__prioritization, feat_req__logging__early_startup, feat_req__logging__entity_identifier, feat_req__logging__filtering_log_levels, feat_req__logging__filtering_entity_id, feat_req__logging__message_loss_detection, feat_req__logging__message_loss_handling, feat_req__logging__context_log_level, feat_req__logging__log_sources_user_app, feat_req__logging__log_sources, feat_req__logging__log_sinks_console, feat_req__logging__log_sinks_local_fs, feat_req__logging__log_sinks_cloud_drive, feat_req__logging__log_sinks_network, feat_req__logging__log_sinks_stdout, feat_req__logging__config_log_level, feat_req__logging__sink_device, feat_req__logging__sink_multiple_device, feat_req__logging__sink_strategy, feat_req__logging__config_buffer_size, feat_req__logging__config_storage_size, feat_req__logging__config_permissions, feat_req__logging__config_log_filter, feat_req__logging__config_entity_id, feat_req__logging__config_on_demand, feat_req__logging__config_fallback, feat_req__logging__config_custom_types, feat_req__logging__error_handling_recoverable, feat_req__log__err_handling_nonrec, feat_req__logging__error_handling_isolation, feat_req__logging__compat_os, feat_req__logging__compat_languages, feat_req__logging__resource_storage, feat_req__logging__resource_comm_channel, feat_req__logging__resource_runtime, feat_req__logging__resource_performance, feat_req__logging__qos_message_handling, feat_req__logging__compat_dlt, feat_req__logging__security_log_access, feat_req__logging__system_class, feat_req__lifecycle__slog2_logging, feat_req__lifecycle__process_logging_support, feat_req__lifecycle__log_timestamp, feat_req__lifecycle__dag_logging_controlif
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__dev_experience__logging_support		Stakeholder Requirement

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

Integration

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

Quality

Document assumptions and design decisions		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 S-CORE community.
stkh_req__quality__assumptions_and_dd		Stakeholder Requirement

Requirements Engineering

Requirements traceability		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 Requirement

Document requirements as code		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
Requirements shall be documented as code (Docs-as-code).
stkh_req__requirements__as_code		Stakeholder Requirement