Transitioning to Software-Defined Vehicles: from MDD to modern Software Engineering

The automotive industry has long embraced model-driven development (MDD) as a foundational methodology for designing and implementing vehicle software systems, particularly in the context of embedded control systems. While MDD has proven effective in developing traditional embedded systems, its limitations become pronounced in the shift toward SDVs, where software complexity rivals or exceeds that of hardware.

The Expanding Role of Software in Vehicle Features

Software must deliver more and more of the complete array of features, including a small but vital portion dedicated to functional safety and real-time operations, roughly 5%, alongside the vast majority (95%) that covers everything else, from infotainment to connectivity and beyond.

The safety-critical elements, aligned with standards like ISO 26262, manage essential real-time functions such as chassis control and advanced driver-assistance systems (ADAS), demanding unwavering reliability and low-latency performance often supported by specialized hardware for the highest safety levels. It is this type of development which suits MDD well. Consequently, the development of these non-safety-critical features, where it is about data, and UI, can leverage modern conventional software engineering practices, using state-of-the-art processes, tools, and languages to deliver high-quality, secure software while enabling a rapid pace of innovation.

This 95-5 division highlights the dual demands on engineering teams: stringent validation for the safety core to prevent failures, contrasted with flexible architectures for the rest to fuel ongoing improvements. Balancing these aspects is key, as it allows SDVs to evolve after leaving the factory, though it can also introduce complexities in maintaining system-wide harmony.

Adopting Dual Software Development Strategies and Decoupling Lifecycles

This broadened software scope naturally leads to a split approach in development: leveraging model-driven development (MDD) for the safety-essential parts (e.g. brakes, blinkers), while embracing mainstream software practices for the larger non-critical segments (climate control, infotainment, interior lighting).

MDD tools, such as those for simulation and verification, are ideal for ensuring traceability and compliance in real-time systems, where precision is non-negotiable. For the expansive remainder (conventional software), agile methodologies with continuous integration enable quicker adaptations and feature rollouts. This dual strategy draws from established software industry practices, such as DevOps, adapted to automotive constraints to enhance agility for non-safety critical software while preserving safety where it matters.

Through architectures like zonal computing, decoupling functional safety can accelerate timelines significantly, supporting OTA enhancements and modular designs that boost efficiency and adaptability without undermining safety. Additionally, it simplifies the relation between hardware and software, while also facilitating cost efficiencies through streamlining hardware complexity, minimizing components like wiring and ECUs.

Phased Transformation and Broader Impacts

Distinguishing safety-critical from regular embedded software, and adopting modern software engineering practices, is key for the Automotive sector to seize the benefits that software can bring – both the agility, the ability to evolve over the product lifecycle, integrate with outside services, and reduce the cost of ownership of the products.

This is a transformative change for any automotive company and affects many aspects, from product management and marketing to the business models to make money with the products. We will explore these in additional articles, among others about the software engineering processes and tools for agile development, requirements management, testing, DevOps, and Software Supply Chain management, and how to integrate these into the product creation process at large.

Author: Hendrik Jilderda (hjilderda@knowmadmood.de)