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, feat_req__daal__lifecycle
The SW-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 SW-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 SW-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 SW-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 SW-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
tags: safety_mechanism 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 SW-platform shall provide towards the applications a safe 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
tags: safety_mechanism 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 SW-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 SW-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, feat_req__baselibs__containers_library, feat_req__baselibs__bitmanipulation, feat_req__baselibs__filesystem_library
The SW-platform shall provide a set of base libraries offering common functionality for SW-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 SW-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 SW-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 SW-platform on POSIX compliant operating systems. reqtype: Non-Functional satisfied by: feat_req__daal__env
The SW-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 SW-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 SW-platform 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 SW-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 SW-platform shall be usable by safety relevant applications. reqtype: Functional satisfied by: feat_req__baselibs__safety, feat_req__baselibs__multi_language_apis, feat_req__baselibs__filesystem_library, 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 SW-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
tags: safety_mechanism rationale: There are state-of-the-art safety mechanisms to check HW and SW errors. These are expected to be supported either by the SW-platform alone or by using HW or OS provided safety features. reqtype: Functional valid_from: v1.0.0 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 SW-platform shall support the following safety feature: 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 to field mode and back
stkh_req__dependability__safety_features		Stakeholder Requirement

SW-platform error reaction		status: valid security: NO safety: ASIL_B
tags: safety_mechanism rationale: Safety relies on error reporting, e.g. to preserve a safe system state. reqtype: Functional
The SW-platform shall react in the following way on errors: report the error (incl. details if available) to the calling user function Note: See also Safe SW-platform state (stkh_req__dependability__safe_state)
stkh_req__dependability__error_reaction		Stakeholder Requirement

Safe SW-platform state		status: valid security: NO safety: ASIL_B
tags: safety_mechanism rationale: A safe state definition is a common expectation of safety integrity standards. reqtype: Functional valid_from: v1.0.0
The SW-platform shall react in the following way on errors: in case of an unrecoverable error (e.g. access violations), report the error to the external health monitor Note1: Together with SW-platform error reaction (stkh_req__dependability__error_reaction) the “safe state” of the SW-platform can be described as “error reported”. Note2: The implementation of the reporting of an unrecoverable error must take into account that after such an error the functions of the SW-platform may be corrupted (solution for this may be a cyclic triggering of an external watchdog in the healthy case and stopping the triggering in the error case).
stkh_req__dependability__safe_state		Stakeholder Requirement

Error report timing		status: valid security: NO safety: ASIL_B
tags: safety_mechanism rationale: It is assumed that there is a need to know how much time is allowed between the ocurrence of an error and the reporting, so we define a feasible time span. reqtype: Functional valid_from: v1.0.0
The SW-platform shall react on errors (as described in Safe SW-platform state (stkh_req__dependability__safe_state) and SW-platform error reaction (stkh_req__dependability__error_reaction)) within 1 millisecond. If this is not feasible a special component AoU needs to be defined. Note1: The time span mentioned is the SW reaction time and not the time between the error happening and the reporting. For example if there is a alive supervision configured with 10ms cycle time and 5ms allowed delay, the error could happen in the first millisecond but will be reported earliest after 10+5ms plus the SW reaction time. Note2: If a user application calls a SW-platform function the (error) return is required latest after the reaction time, so there could be a timeout used by the application considering this.
stkh_req__dependability__error_report_timing		Stakeholder Requirement

No mixed ASIL		status: valid security: YES safety: ASIL_B
rationale: It is assumed that POSIX processes as implemented by the OS provide isolation from memory and timing errors of other processes but not within. reqtype: Functional
The SW-platform safety components running in one POSIX process shall implement the highest ASIL of their assigned functional requirements.
stkh_req__dependability__no_mixed_asil		Stakeholder Requirement

Program Flow Monitoring		status: valid security: YES safety: ASIL_B
rationale: Not all POSIX operating systems provide protection of POSIX processes from timing errors (e.g. delayed execution, deadlocks) reqtype: Functional valid_from: v1.0.0
The SW-platform safety components shall use program flow monitoring to detect run time errors or explain in their safety concept why they do not need this. Note1: Reasons for not needing program flow monitoring could be an OS scheduler with timing and execution guarantees. Or that the non/late execution of the application keeps the system in a safe state. Note2: The SW-Platform supports this - see Safety features (stkh_req__dependability__safety_features) “live, deadline, logical supervision”
stkh_req__dependability__flow_monitoring		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 SW-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, feat_req__sec_crypt__sym_symmetric_encrypt, feat_req__sec_crypt__sym_symm_algo_aes_cbc, feat_req__sec_crypt__sym_sym_algo_aes_gcm, feat_req__sec_crypt__sym_sym_algo_aes_ccm, feat_req__sec_crypt__sym_algo_chacha20, feat_req__sec_crypt__asym_encryption, feat_req__sec_crypt__asym_algo_ecdh, feat_req__sec_crypt__sig_creation, feat_req__sec_crypt__sig_verification, feat_req__sec_crypt__sig_algo_ecdsa, feat_req__sec_crypt__mac, feat_req__sec_crypt__hashing, feat_req__sec_crypt__hashing_algo_sha2, feat_req__sec_crypt__hashing_algo_sha3, feat_req__sec_crypt__kdf, feat_req__sec_crypt__rng, feat_req__sec_crypt__rng_algo_chacha20rng, feat_req__sec_crypt__cert_management, feat_req__sec_crypt__key_generation, feat_req__sec_crypt__key_import, feat_req__sec_crypt__key_storage, feat_req__sec_crypt__key_deletion, feat_req__sec_crypt__flexible_api, feat_req__sec_crypt__performance_tooling, feat_req__sec_crypt__algo_naming, feat_req__sec_crypt__no_key_exposure, feat_req__sec_crypt__side_channel_mitigation, feat_req__sec_crypt__api_lifecycle, feat_req__sec_crypt__error_handling, feat_req__sec_crypt__security_concept, feat_req__sec_crypt__algo_updates, feat_req__sec_crypt__reverse_eng_protection, feat_req__sec_crypt__production_keys, feat_req__sec_crypt__pqc_readiness, feat_req__sec_crypt__hw_acceleration, feat_req__sec_crypt__sw_fallback, feat_req__sec_crypt__trusted_time, feat_req__sec_crypt__os_protection, feat_req__sec_crypt__access_control, feat_req__sec_crypt__ids_integration, feat_req__sec_crypt__dos_mitigation, feat_req__sec_crypt__tls_support
The SW-platform shall support the following security features: 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
tags: safety_mechanism 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__daal__time_based_arch, 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 SW-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__daal__com, 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 SW-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 SW-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__daal__lifecycle, feat_req__daal__trigger, feat_req__daal__health_error, 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 SW-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
The SW-platform shall support cycle times of less then 5 ms on application level if 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 SW-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 SW-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 satisfied by: feat_req__daal__lifecycle
The SW-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__one_way_sharing, feat_req__com__readonly_vm, feat_req__com__consistent_data, feat_req__com__lock_free_access, feat_req__com__producer_timestamps, feat_req__com__streamed_data, feat_req__com__configurable_queues, feat_req__com__lock_free_queue, feat_req__com__bi_directional_comm, feat_req__com__async_support, feat_req__com__shared_memory, feat_req__com__data_notifications, feat_req__com__config_notifications, 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 SW-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 SW-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 SW-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 SW-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 SW-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
tags: safety_mechanism 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 SW-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 SW-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 SW-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 SW-platform shall provide a framework to ensure quality of service of applications deployed on the SW-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 SW-platform shall support the following diagnostic protocols * 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 SW-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 SW-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 SW-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 SW-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 SW-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 SW-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 SW-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 SW-platform

On-board ML Workloads		status: valid security: NO safety: QM
tags: artificial_intelligence 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 SW-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
tags: artificial_intelligence 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 SW-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
tags: artificial_intelligence rationale: Automotive platforms have limited compute and thermal budgets. reqtype: Non-Functional satisfied by: feat_req__ai_platform__embedded_efficiency
The SW-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
tags: artificial_intelligence 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 SW-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
tags: artificial_intelligence rationale: AI model execution must be protected against tampering or abuse. reqtype: Functional satisfied by: feat_req__ai_platform__model_verification
The SW-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
tags: safety_mechanism, artificial_intelligence rationale: Safety certification requires predictable and bounded system behavior. reqtype: Non-Functional satisfied by: feat_req__ai_platform__static_backend
The SW-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
tags: artificial_intelligence 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 SW-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
tags: artificial_intelligence rationale: HMIs are expected to support intelligent, natural interaction using LLM-based assistants. reqtype: Functional satisfied by: feat_req__gen_ai__ui
The SW-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
tags: safety_mechanism, artificial_intelligence 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 SW-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
tags: artificial_intelligence rationale: AI components must interact with vehicle state and control interfaces. reqtype: Functional satisfied by: feat_req__gen_ai__structured_vapi
The SW-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 SW-platform 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 SW-platform shall support a reusable fault reporting infrastructure that enables applications and SW-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 SW-platform 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 SW-platform 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 SW-platform 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 SW-platform 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 SW-platform 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 SW-platform 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 SW-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 SW-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 SW-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 SW-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 SW-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 SW-platform shall support performance analysis of SW-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 SW-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 SW-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 SW-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 SW-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 SW-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 SW-platform related and non-platform related applications. reqtype: Functional satisfied by: feat_req__time__mocking_apis
The SW-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 SW-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 SW-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__daal__log, feat_req__lifecycle__slog2_logging, feat_req__lifecycle__process_logging_support, feat_req__lifecycle__log_timestamp, feat_req__lifecycle__dag_logging_controlif
The SW-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 SW-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
The SW-platform infrastructure shall support integration of multiple repositories 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
Contributors shall specify all assumptions and design decisions as requirements which are agreed within the S-CORE community.
stkh_req__quality__assumptions_and_dd		Stakeholder Requirement

Requirements Engineering

Requirements traceability		status: valid security: NO safety: ASIL_B
rationale: This is a usability constraint needed for long term maintenance support reqtype: Non-Functional
he SW-platform infrastructure shall support linking all requirements from lower to upper level, whereby on the top-level are the stakeholder requirements.
stkh_req__re_requirements__traceability		Stakeholder Requirement

Document requirements as code		status: valid security: NO safety: ASIL_B
rationale: In this project no external tool or service is used. Therefore as-code is the selected option. reqtype: Non-Functional
The SW-platform infrastructure shall support documenting all requirements as code (Docs-as-code).
stkh_req__requirements__as_code		Stakeholder Requirement

Safety Mechanisms

The following stakeholder requirements are assumed to be fulfilled by a safety mechanism due to complexity of the realizing SW element(s) or due to dependency on HW. This is confirmed during safety analysis of the derived feature requirements and architecture.

Expected Safety Mechanisms

Title	ID	Tags
Deterministic Execution Paths	stkh_req__ai_platform__runtime_determinism	safety_mechanism; artificial_intelligence
Support for Time-based Architectures	stkh_req__app_architectures__support_time	safety_mechanism
Safe Communication	stkh_req__communication__safe	safety_mechanism
SW-platform error reaction	stkh_req__dependability__error_reaction	safety_mechanism
Error report timing	stkh_req__dependability__error_report_timing	safety_mechanism
Safe SW-platform state	stkh_req__dependability__safe_state	safety_mechanism
Safety features	stkh_req__dependability__safety_features	safety_mechanism
Support of safe Key/Value store	stkh_req__functiona_req__support_of_store	safety_mechanism
Safe Configuration	stkh_req__functional_req__safe_config	safety_mechanism
Action Safety and Governance	stkh_req__gen_ai__safety_filter	safety_mechanism; artificial_intelligence