1
Shedding Light onto Safety Integrity Level and Basic Software Constraints in a Real-World Automotive Application: Case Study with Driverator Framework Tobias Denzinger # CARIAD SE, Germany
Matthias Becker # KTH Royal Institute of Technology Stockholm, Sweden
arXiv:2605.04837v1 [cs.SE] 6 May 2026
Peter Ulbrich # Technische Universität Dortmund, Germany Abstract Automotive electronic control units (ECUs) are intricate systems with hundreds of individual functions, numerous software components, and multiple interdependent tasks. A prevalent structural pattern in these systems are so-called cause-effect chains. While significant research efforts have been dedicated to the temporal analysis and optimization of these chains, particularly minimizing data age and function response times, other crucial non-functional properties remain relatively underexplored. In particular, the safety integrity level (SIL) classification substantially influences the system design by determining task colocation strategies. Improper sharing of functions or interweaving tasks with different safety levels can compromise
the integrity of critical functions. Additionally, AUTOSAR basic software (BSW) (e.g. OS, runtime environment, communication stacks, or diagnostics) introduces complexity that varies based on task characteristics and SIL categories. Furthermore, memory requirements present another critical challenge, given the diversity of memory architectures and SIL-specific dependencies that strongly constrain task allocations. This paper thoroughly characterizes a real-world automotive application, describing an automotive application based on SIL constraints, the impact of basic software, and memory requirements. In this context, the Driverator configuration framework is introduced for scalable system analysis.
Tool availability. The Driverator tool and accompanying case-study material are archived as [5] at https://doi.org/10.17877/TUDODATA-2026-MOR12ARE.
1
Introduction
In recent years, automotive electronic control units (ECUs) have experienced significant growth in complexity, driven by the integration of multiple applications and advanced driver-assisting functions, and architectural stringency demanded by functional safety standards such as ISO 26262 [7]. Modern automotive ECUs now colocate dozens to hundreds of interconnected software components (SW-C), with designs constrained by non-functional requirements, including timing, memory, and, particularly, Safety Integrity Levels (SIL). SIL classification directly influences architectural decisions through stringent constraints on function colocation, task allocation, and memory isolation. This problem is evident in heterogeneous hardware architectures, where safety characteristics vary by core and memory region. Improper synthesizing of tasks considering different SILs can severely compromise the integrity of the system, leading to substantial risks and inefficiencies. In addition, automotive software systems are heavily based on standards, such as AUTOSAR [2], which provide basic software (BSW) components such as operating systems, runtime environment (RTE), communication stacks, and diagnostic services. While these components provide critical infrastructure, they also inherently add to the overall complexity and resource demands. The
2
Case Study with Driverator Framework
impact introduced by BSW varies with functional attributes and SIL classifications, creating an intricate interplay between software architecture and system performance. A prevalent design pattern in automotive software is the cause-effect chain, which structures tasks into data-flow sequences from sensor inputs to actuator outputs. These chains represent critical functional paths where data is propagated across tasks, each potentially having different execution rates [8]. A crucial component in designing these chains is their end-to-end timing, which must remain within predefined limits to ensure adequate quality of service given by an age constraint on the involved data [6]. The age constraint defines the maximum time of sequential data propagation between reading an input value by the first task of the chain and providing an output value by the last task at the end of the chain within the specified constraint. Integrating SIL constraints with cause-effect chains significantly adds to the overall design complexity, requiring careful consideration when allocating SW-Cs and BSW to the hardware. In contrast to [8], this paper investigates the impact of SIL classifications and basic software on automotive system architecture. We aim to identify correlations between these critical design aspects, emphasizing the early design stage. Although the functional scope and specifications are defined at this stage, individual teams typically focus separately on distinct functions, SW-Cs, and BSW, without yet integrating them into a specific hardware platform. Regarding the V-model in Figure 1, our work targets the left side, addressing early, high-impact architectural decisions.
Figure 1 Extraction of respective application and basic software characteristics according to the highlighted V-model phases.
Although significant research on automotive systems and cause-effect chains, including detailed characterizations, analysis, and scheduling approaches, and despite a vast body of work on mixedcriticality systems, e.g., the review of Burns and Davis [4], to manage uncertainties in task design, there remains a notable gap. Existing case studies have not painted a holistic picture, treating safety level, basic software, and memory requirements as first-class citizens. In Section 4, we present our case study of a real-world automotive motion and drive system to explicitly quantify SIL constraints, basic software, and memory requirements. This addresses our first challenge by providing detailed statistical data, filling a crucial research gap. The insights allow for the generation of realistic artificial test systems for our evaluation and are beneficial for future studies.
2
Automotive Applications
According to the AUTOSAR automotive system framework [2], the architecture of the platform is subdivided by the application layer, the runtime environment (RTE), the basic software layer and the underlying microcontroller. The automotive software is structured into components,
T. Denzinger, M. Becker, P. Ulbrich
3
e.g., software components (SW-C), which are assigned to the application layer. The atomic software component is categorized by a specific Automotive Safety-Integrity Level (ASIL) to meet the requirements of ISO26262 [7]. Each SW-C contains one or multiple runnables that are distinguished between initial or cyclic calls. These runnables serve as the base for scheduling with respect to respective AUTOSAR timing specifications [3], i.e., as periodic release as an activation pattern. Runnables communicate with each other via sender-receiver communication or client-server calls. The communications are orchestrated by the Runtime Environment (RTE). Furthermore, the AUTOSAR basic software (BSW) includes the categories of services, ECU abstraction, microcontroller abstraction and complex drivers. Each of these categories orchestrates operations, e.g., operating system (OS), runtime environment (RTE), communication stacks, and diagnostics, which introduce complexity that varies based on task characteristics based on various safety levels (ASIL). Each basic software component contains a multitude of system-related runnables. In general, runnables with the same activation pattern are typically mapped to the same task. Note that multiple tasks with the same activation pattern may exist in one system. Subsequently, tasks are scheduled in the operating system with fixed priorities, as described in [1]. Accordingly, the tasks run until completion and can only be preempted by higher priority tasks. All tasks are primarily triggered time-synchronously at determined rates or sporadically activated by specific events.
3
Approach from Benchmark Abstraction to Driverator Framework
The underlying benchmark of the automotive application is derived from multiple requirements by an abstract way to preserve the restrictions of intellectual property (IP). Neither descriptions on the various functionalities nor exact values of software budgets compared to measurements can be revealed. To meet these circumstances, the idea is to provide a respective case study where the specifications are statistically derived by specific means, e.g. the Weibull distribution, with an indication of correlation coefficients compared to the benchmark. Our focus is on the feasibility of the system design in the early development stage, as explained in Section 1. We design the application software without measured values and thus we deal with pessimistic timing budgets under the paradigm of tight bounds. Furthermore, rough design specifications of basic software are provided with rare timing information, which will only be refined in a later implementation stage. To address this problem, we present an abstraction concept to estimate the expected impact of basic software from previous development cycles. In summary, the key indicators of the application are driven by the interactive perspectives of SIL, BSW, and Memory.
Subject-specific correlation coefficients Abstraction Method
RealTime Application
Critical IP
System Properties via Case Study
Deployment
Driverator Framework
Uncritical IP
Figure 2 Overview of methodical abstraction based on a real-world application without IP constraints.
Our approach to methodical abstraction from a real-world application under IP constraints to the available case study in Section 4 is outlined in Figure 2. We have implemented a system
4
Case Study with Driverator Framework
configuration and generation tool, called Driverator, to set up the application structure provided in the case study without IP restrictions. The archived Driverator tool and accompanying case-study material are available via DOI [5]. The Driverator framework can be scaled according to the underlying platform, enabling the integration of timing analysis and system optimization.
4
Case Study: SIL, BSW, and Memory in a Real-World Automotive Vehicle Driving System
This section introduces the application characteristics of a real-world motion and drive controller as the essential unit of an automotive system available in the early development stage.
4.1
Properties of Application Software
An overview of the properties of the software components (SW-C) is provided in Table 1, which includes an appropriate safety-critical distribution, as well as respective intervals for read-only memory (ROM) and random-access memory (RAM). The correlation factor is 0.5174 compared to the baseline features. Table 1 Attributes of Software Components ASIL
QM A B C D
Share
41 % 7% 14 % 10 % 28 %
ROM (kB)
RAM (kB)
Min.
Max.
Min.
Max.
6 37 15 18 21
255 140 228 168 252
0.5 1 0.5 1 1
29 22 17 26 23
In general, the total number of software components depends on the functional design in interaction with the underlying platform. One software component is implicitly composed of an initial call and cyclic runnables that can be activated at the same or different rates. Furthermore, the relation between the SW-C and runnable can not be separated. Each SW-C serves as a container that specifies the safety-critical category (ASIL) for each related runnable. In Table 2, time-specific budget values (tight bounds) for cyclic runnables are specified with a correlation coefficient of 0.4322. All common periods are shown in relation to the minimum and maximum intervals of worst-case execution times (WCET), the total share, and associated safety ranges. Basically, the runnables are primarily triggered time-synchronously at determined rates or sporadically activated by specific events.
4.2
Setup of Communication via Cause-Effect Chains
The interaction between cyclic runnables is realized via inter-runnable communication. In Table 3, the actual communication direction is described by the sender runnables in the rows and the receiver runnables in the columns. The associated arrows indicate if the adjacent periods of runnables communicate with each other. The highest interaction volumes are represented between runnables of the same period, which are highlighted in color. In addition, runnables contain so-called read/write labels that are used to implement communication, as considered in [8]. Depending on the task assignment, the abstraction results in intra- or inter-task communication. In consideration of the orchestration of the communication paradigms, the cause-effect chains are taken into account. The critical chains are made up of application-specific runnables with
T. Denzinger, M. Becker, P. Ulbrich
5
Table 2 Characteristics of Runnables in Application Layer Period (ms)
WCET (µs)
1 5 10 20 50 100 200 500 1000
Min.
Max.
15 10 22 56 125 228 191 403 1,209
290 725 1,218 1,733 1,902 2,447 3,988 6,176 9,200
Share
ASIL
5% 31 % 25 % 12 % 8% 10 % 2% 4% 3%
QM, B, D QM, A, B, C, D QM, B, C, D QM, B, C, D QM, A, B, D QM, C, D QM, A QM, D QM
Table 3 Matrix of Inter-Runnable Communication
50
↰↰↰↰
↰↰↰↰↰
↰↰↰↰
↰↰
200
500
1000
↰↰
↰
↰↰↰
100
↰↰
20
↰↰
10
↰↰↰↰
5
↰↰
1
↰↰↰
Period (ms) 1 5 10 20 50 100 200 500 1000
the same or multiple activation patterns, which are also spread over the tasks. Each activation pattern represents the number of release periods of runnables assigned per chain. In summary, each cause-effect chain can contain one to three different activation patterns with a total range of between two and 18 runnables based on various safety-critical levels. The number of critical chains depends on the implemented features and the underlying platform, which may also share common runnables. The configuration in Table 4 shows the various attributes of each cause-effect chain. Table 4 Configuration of Cause-Effect Chains Cause-Effect Chain Activation Pattern
Share
1
65 %
2
25 %
3
10 %
Activation Pattern Set of Runnables
Share
2 3 4 5 6
40 % 25 % 20 % 10 % 5%
Additionally, runnables and resulting tasks are sequenced in a predefined execution order within each cause-effect chain that must guarantee end-to-end latency constraints. The respective data age ranges are determined by a minimum factor of 1.8 and a maximum factor of 4.9 of the
6
Case Study with Driverator Framework
chain-specific hyperperiods. The tasks are mostly activated time-synchronously by the included period, but can also be triggered by special events in either a preemptive or cooperative sample.
4.3
Impact of Basic Software
The proportion of features is constantly increasing, affecting a more frequent interaction between the application software and the AUTOSAR basic software (BSW). The BSW properties aggregate costs by runtime environment, communication stacks, operating system, or diagnostics. According to [9], the increasing share of parallel use of safety and non-safety software leads to runtime overhead and higher complexity, which can be reduced by partitioning measures of BSW. Table 5 Task Properties with Basic Software Extensions Count of Runnables
BSW Ratio
1 2 3 4 5 ≥6
Min.
Max.
24 % 19 % 15 % 12 % 10 % 8%
57 % 48 % 39 % 30 % 22 % 14 %
The impact of basic software is not yet available in the early design phase, and thus the methodical concept is to statistically approximate the basic software, depending on the task structure of the application. Table 5 presents the properties of each task with respect to the BSW proportion depending on the composition solution of the task and the number of critical runnables. The task properties are correlated by a factor of 0.5042. In general, the more cyclic runnables can be concatenated within a task, the less BSW interaction costs are necessary. This fact is mirrored by the BSW extension ratios that indicate the additional WCETs costs of basic software dependent on the accumulation of integrated runnable WCETs in each task structure based on constant SIL. Finally, the extended execution time measures must be calculated for the respective tasks that contribute to the system utilization. Table 6 Attributes of Basic Software Task Budgets Period (ms)
1 2 5 10 20 50 100 200
WCET (µs) Min.
Max.
26 18 21 38 37 41 95 14
168 385 1,014 1,430 1,698 972 588 114
Share
ASIL
7% 6% 31 % 34 % 6% 8% 3% 5%
QM, D QM, D QM, A, B, C, D QM, A, B, C, D QM, B, D QM, D QM QM
To enable crucial basic software operations, dedicated BSW tasks are considered by discrete safety levels, which are differentiated between sporadic and periodic calls. Table 6 provides the characteristics of such periodic BSW tasks based on a correlation coefficient of 0.4189. The relation between the basic software task set and the BSW extensions of the application task set is described
T. Denzinger, M. Becker, P. Ulbrich
as the more BSW extensions are advantageously integrated in the application task set, the less BSW tasks are needed for e.g. communication efforts. The total basic software set contains approximately 6,000 system-wide runnables on a modern multi-core microcontroller. Each BSW task can be composed of up to 200 different system-related runnables. This fact also highlights the advancement of the system architecture compared to an engine control unit with up to 1,500 runnables about ten years ago [8]. In addition, the summarized specifications for basic software memory BiROM are statistically indicated between 634 and 1,258 kB per lockstep-specific core that reduce the available hardware capacities MiROM .
5
Challenges
Automotive software development faces various challenges in the early design stage. Initially, non-functional software specifications without concrete measurement values are available, and thus these requirements are rather described as pessimistic budgets in order to depict a runtime-capable system that is as close as possible to comparable measurements (tight bounds), available only at a later development phase. In addition, the basic software specifications are still in the design phase without detailed design or measurements, resulting in an extremely difficult evaluation of the runtime and memory impact of basic software in the early development phase. To comply with safety standards (e.g. [7]), special care is required when mapping runnables to tasks in order to guarantee freedom from interference in time and space. The challenge is to design the tasks in such a way that all individual timing specifications of runnables and cause-effect chains are met as long as the task meets its own scheduling requirements. Thus, several aspects are addressed to ensure timing, safety, basic software, memory, and end-to-end constraints upon a multi-core system, known as the architects dilemma. The main requirements that need to be met are described below: R1 Each runnable is assigned to exactly one periodic task with implicit deadlines; a task may contain multiple runnables. Tasks are mapped under partitioned FP scheduling. R2 Clustering/merging must preserve SIL separation and chain context and must respect data-age constraints (modeled later as JLDs). R3 All runnables of the same SW-C must be co-located on one core; per-core ROM/RAM capacities must not be exceeded. R4 BSW overheads are modeled as task-local extensions (via f BSW (·)) and as global BSW tasks with per-core memory envelopes. In addition, the software development process of automotive applications faces further challenges in the context of the real-time systems, which provide potential for future research and analysis: 1. Enabling tight worst-case execution time (WCET) bounds between budgets available in the early design phases and later measurements on real values. 2. Considering the design of basic software (BSW) specific cause-effect chains that are composed of up to 100 system-related runnables under end-to-end latencies. 3. Precise analysis of various hardware platforms with divergence of lockstep and non-lockstep mechanisms and their impact on SIL-constraint cause-effect chains on a multi-core system.
6
Conclusion
In this paper, we demonstrate that explicitly incorporating Safety Integrity Levels (SIL), Basic Software (BSW), and memory impacts during early design phases significantly enhances the realism and resilience of forseen system architectures. In addition, we introduce the abstraction
7
8
Case Study with Driverator Framework
method of our application benchmark and present the Driverator benchmark framework to enable scalable analysis across various system configurations. We provide viable insights for task and memory allocation configuration by safety and timing constraints through a real-world case study. The importance of treating non-functional constraints is underscored as first-class citizens in the early development lifecycle. References 1 2 3 4
5
AUTOSAR - Specification of Operating System. R24-11, 2024. AUTOSAR - Specification of RTE Software. R2411, 2024. AUTOSAR - Specification of Timing Extensions. R22-11, 2022. Alan Burns and Robert Davis. Mixed criticality systems - a review : (13th edition, february 2022). Department of Computer Science, University of York, Tech. Rep, 02 2022. Tobias Denzinger, Matthias Becker, and Peter Ulbrich. Driverator: Generating Realistic Automotive Real-Time Task Sets with SIL and BSW Effects, 2026. doi:10.17877/ TUDODATA-2026-MOR12ARE.
6
7
8
9
Nico Feiertag, Kai Richter, J. Eric Nordlander, and Jan Åke Jönsson. A compositional framework for end-to-end path delay calculation of automotive systems under different path semantics. In IEEE Real-Time Systems Symposium, 2008. ISO 26262-1:2018. https://www.iso.org/ standard/68383.html, 2018. [Online; accessed on 19 July 2024]. Simon Kramer, Dirk Ziegenbein, and Arne Hamann. Real world automotive benchmarks for free. In 6th International Workshop on Analysis Tools and Methodologies for Embedded and Realtime Systems (WATERS), volume 130, 2015. Jonas Wolf and Peter Müller. Safety and performance with asil d autosar basic software. Safety AUTOSAR Hanser Automotive, 2016.