SDV Guide
digital.auto
  • Welcome
  • SDV101
    • Part A: Essentials
      • Smart Phone? No: Habitat on Wheels!
      • Basics: What is a Software-defined Vehicle
      • MHP: Expert Opinion
      • Challenges: What sets automotive software development apart?
      • SDV Domains and Two-Speed Delivery
    • Part B: Lessons Learned
      • Learnings from the Internet Folks
        • Innovation Management
        • Cloud Native Principles
          • DevOps and Continuous Delivery
          • Loose Coupling
            • Microservices & APIs
            • Containerization
            • Building Robust and Resilient Systems
      • Learnings from the Smart Phone Folks
    • Part C: Building Blocks
      • Foundation: E/E Architecture
        • Today`s E/E Architectures
        • Evolving Trends in E/E Architectur
        • Case Study: Rivian
      • Standards for Software-Defined Vehicles and E/E Architectures
      • Building Blocks of an SDV
        • Service-Oriented Architecture
          • The SOA Framework for SDVs
          • Container Runtimes
          • Vehicle APIs
          • Example: Real-World Application of SDV Concepts
          • Ensuring Functional Safety
          • Event Chains in Vehicle SOAs
          • Vehicle SOA Tech Stack
        • Over-the-Air Updates: The Backbone of Software-Defined Vehicles
        • Vehicle App Store: The Holy Grail of Software-Defined Vehicles
      • Summary: Building Blocks for Software-Defined Vehicles
    • Part D: Implementation Strategies
      • #DigitalFirst
      • Hardware vs Software Engineering
        • The Traditional V-Model in Automotive Development
        • Agile V-Model, anybody?
        • Key: Loosely Coupled, Automated Development Pipelines
        • The SDV Software Factory
      • Implementing the Shift Left
        • Simulation and Digital Prototyping
          • Early Validation: Cloud-based SDV Prototyping
          • Detailed Validation: SDVs and Simulation
        • Towards the Virtual Vehicle
          • Case Study: Multi-Supplier Collaboration on Virtual Platform
          • Long-Term Vision
        • Physical test system
        • De-Coupled, Multi-Speed System Evolution
        • Continuous Homologation
        • Summary and Outlook
      • Enterprise Topics
        • Variant Management
        • Engineering Intelligence
        • Enterprise Organization, Processes, and Architecture
        • Incumbent OEMs vs EV Start-ups
  • SDV201
  • ./pulse
    • SDV Culture
    • Lean Sourcing
      • LeanRM
        • Why so many Requirements?
      • SCM for SDVs
    • SDV Systems Engineering
      • LeanSE
      • SDVxMBSE
    • Digital First
    • Loose Coupling
      • API-first
      • Freeze Points
    • Automation and Engineering Intelligence
    • Continuous Homologation
    • Build / Measure / Learn
  • Glossary
Powered by GitBook

SDV Guide

  • Legal Notice
  • Disclaimer
  • Privacy Policy

(c) 2025 Dirk Slama

On this page
  • Key: Functional Safety
  • ISO 26262: ASIL (Automotive Safety Integrity Level)
  • Complexity
  • Integration Hell
  • Clash of Two Worlds
  1. SDV101
  2. Part A: Essentials

Challenges: What sets automotive software development apart?

PreviousMHP: Expert OpinionNextSDV Domains and Two-Speed Delivery

Last updated 6 months ago

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.