Challenges: What sets automotive software development apart?

Automotive software development is uniquely challenging, marked by its focus on functional safety, inherent complexity, and the balance between rigid and flexible development paradigms. These factors set it apart from other industries and make it one of the most demanding fields in software engineering today.

Key: Functional Safety

Automotive software development stands apart due to its strict focus on functional safety. This concept is defined as the absence of unreasonable risk caused by hazards resulting from malfunctioning electric or electronic systems. Functional safety is essential to ensure that critical systems, such as airbags or braking systems, function correctly under all circumstances. This requirement places automotive software development in a class of its own, compared to other industries like desktop or consumer applications.

ISO 26262: ASIL (Automotive Safety Integrity Level)

To meet stringent safety requirements, the automotive industry adheres to the ISO 26262 standard, which defines Automotive Safety Integrity Levels (ASIL). These levels classify risks from ASIL A (lowest safety requirement) to ASIL D (highest safety requirement). A separate level, QM (Quality Management), is applied when there is no significant hazard involved.

Examples of ASIL Classifications:

• ASIL A: Failure of rear lights or windshield wipers, which pose minimal safety risks.

• ASIL B: Issues with headlights, which moderately affect visibility.

• ASIL C/D: Problems with engine control, such as unintended acceleration or critical safety system failures.

• ASIL D: Severe issues such as unintended full-power braking, inadvertent airbag deployment, or steering malfunctions.

This structured framework ensures a systematic and reliable approach to the design, development, and validation of safety-critical automotive systems.

Complexity

Modern vehicles are highly complex systems, incorporating hundreds of subsystems and Electronic Control Units (ECUs). Each ECU is designed to manage specific features, such as braking, engine control, or infotainment. These systems communicate through intricate protocols like CAN Bus, LIN, or FlexRay, creating extensive interdependencies.

Complexity Drivers:

• Heterogeneity: A wide variety of vehicle variants and configurations.

• Technological Diversity: Integration of AI, sensors, control systems, and communication networks.

• Subsystem Dependencies: High interconnectivity among dozens, if not hundreds, of ECUs.

While the transition to modern E/E architectures and SDVs promises to simplify development in the future, current levels of complexity remain a significant challenge for the industry.

Integration Hell

A pervasive issue in automotive software development is integration hell—the struggle to unify diverse technologies into a seamless, functioning vehicle.

Key Challenges:

• Distributed Teams: Development teams work across multiple organizations and geographical locations, often with differing processes and toolchains.

• Legacy Technologies: Many OEMs rely on outdated systems and development frameworks.

• Manual Processes: Approval, testing, and integration steps often lack automation, increasing time and costs.

• Low Automation: CI/CD pipelines and automated workflows are not yet the industry standard, further slowing development.

The complexity of integration significantly impacts the time required to develop new vehicle platforms, as well as the associated costs. Addressing this requires adopting modern development practices, including automated pipelines and continuous integration strategies.

Clash of Two Worlds

Automotive software development faces a unique cultural and technical divide: the ASIL world versus the QM world.

ASIL World:

• Features strict safety requirements and hard real-time constraints.

• Development relies on stable, rigorous processes like the V-model.

• Prioritizes long-term planning, hardened environments, and first-time-right approaches.

QM World:

• Emphasizes flexibility, with lower safety requirements allowing for iterative and agile development.

• Encourages frequent updates, MVPs (Minimum Viable Products), and experimental features.

• Typically avoids hard real-time requirements, focusing instead on customer-facing innovations.

The Challenge:

Many features in modern vehicles span both worlds. For example, a single feature may include safety-critical ASIL components and more experimental QM elements. Successfully integrating these requires:

• Technical solutions to ensure compatibility.

• Cultural and organizational strategies to harmonize differing priorities and approaches.

Navigating this clash is one of the central challenges for automotive OEMs in transitioning to software-defined vehicles.