Shedding Light onto Safety Integrity Level and Basic Software Constraints in a Real-World Automotive Application

Jul 16, 2026

Automotive electronic control units (ECUs) are highly complex embedded systems where cause–effect chains connect sensor inputs to actuator outputs. Beyond timing and data age, safety integrity level (SIL) strongly constrains function colocation, task allocation, and memory isolation to protect safety-critical behavior. AUTOSAR basic software (BSW)—operating system, runtime environment, communication, and diagnostics—adds overhead whose impact depends on SIL and task characteristics. A real-world case study introduces the Driverator Framework to generate industrially realistic application instances, including SIL classifications, BSW overheads, and memory consumption.

LanguageEnglish

CategoryResearch & Report

FormatPDF

Pages11

Reading Time28 min

Introduction

Case Study with Driverator Framework

arXiv :2605 .04837v 3 [ cs . SE] 11 Jul 2026 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, Ingolstadt, Germany Matthias Becker \# KTH Royal Institute of Technology Stockholm, Sweden Peter Ulbrich \# Technische Universität Dortmund, Germany ~~ Abstract ~~ Automotive electronic control units (ECUs) constitute highly complex embedded systems comprising hundreds of functions, numerous software components, and multiple mutually dependent tasks. A common architectural pattern in such systems is represented by cause–effect chains. While existing research has extensively addressed the temporal analysis and optimization of these chains—particularly with respect to data age and reaction time—other non-functional properties have received comparatively limited attention. Among these properties, the safety integrity level (SIL) plays a central role in system design, as it directly constrains task allocation and colocation decisions. Inappropriate sharing of functions or the interleaving of tasks with different safety classifications may jeopardize the integrity of safety-critical functionality. Moreover, AUTOSAR basic software (BSW), including the operating system, runtime environment, communication services, and diagnostic components, introduces additional design complexity that depends on task characteristics and SIL classifications. Memory requirements further intensify this challenge, since heterogeneous memory architecturesand SIL-dependent constraints impose strict limitations on feasible task mappings. This case study provides a detailed characterization of a real-world automotive application, with particular emphasis on SIL constraints, AUTOSAR BSW impact, and memory requirements. We introduce the Driverator Framework, which enables researchers to generate application instances that reflect the characteristics of realistic industrial systems. Unlike existing case studies, Driverator incorporates additional systemrelevant aspects, including SIL classifications, basic software overheads, and memory consumption. Tool availability. The Driverator tool and accompanying case-study material are archived as [5] at [https://doi.org/10.17877/TUDODATA-2026-MOR12ARE](https://doi.org/10.17877/TUDODATA-2026-MOR12ARE). 1 Introduction In recent years, automotive electronic control units (ECUs) have undergone a substantial increase in complexity, driven by the integration of multiple applications, advanced driver-assistance functions, and the stringent architectural requirements imposed by functional safety standards such as ISO 26262 [7] . Modern automotive ECUs typically integrate tens to hundreds of interconnected software components (SW-Cs), whose design is constrained by non-functional requirements, including timing, memory consumption, and, in particular, Safety Integrity Levels (SILs) . SIL classifications have a direct impact on architectural design decisions, as they impose strict constraints on function colocation, task allocation, and memory isolation. These constraints become especially relevant in heterogeneous hardware architectures, where safety properties may differ across processing cores and memory regions. An inappropriate synthesis or allocation of tasks with different SIL classifications can compromise system integrity, resulting in safety risks as well as architectural inefficiencies. Automotive systems are further characterized by their reliance on standardized software platforms such as AUTOSAR [2] . AUTOSAR provides basic software (BSW) services, including 2 Case Study with Driverator Framework Figure 1 Extraction of respective application and basic software characteristics according to the highlighted V-model phases. operating systems, runtime environments (RTEs), communication stacks, and diagnostic services. While these components constitute essential

FAQs

How do safety integrity levels (SIL) influence ECU software architecture decisions?

SIL classifications constrain function colocation and task allocation while also requiring memory isolation. Incorrect sharing or interleaving across different SILs can threaten safety integrity and cause architectural inefficiencies.

What role does AUTOSAR basic software (BSW) play in meeting SIL and resource constraints?

AUTOSAR BSW components such as the operating system, RTE, communication stacks, and diagnostics contribute overhead and complexity. Their overhead depends on functional and non-functional properties, creating interdependence between safety requirements and system performance.

What is the purpose of the Driverator Framework in the presented case study?

Driverator enables researchers to generate application instances reflecting realistic industrial systems. It explicitly incorporates SIL classifications, basic software overheads, and memory consumption, distinguishing it from earlier case-study approaches.

Jul 16, 2026

Upload by Ava Thompson