Beyond the Hype: How OEMs Actually Deliver a Software-Defined Vehicle

Key takeaways

1. SDVs require a holistic revamp that integrates user applications, instrumentation systems, embedded operating systems, and hardware, and thus highlights the complexity of modern vehicle design. 
2. OEMs are facing challenges such as legacy architecture constraints and the need for compliance with safety and cybersecurity standards, factors that necessitate innovative solutions and collaboration among cross-functional teams. 
3. Proven practices including model-based design, continuous integration and DevOps, and advanced simulation platforms are vital for enhancing efficiency and reliability in the development of Software-Defined Vehicles. 

Cutting through the buzz 

SDVs are gaining significant attention from both consumers and industry experts, frequently appearing in today’s news. Building an SDV requires more than just adding new software; it demands a complete redesign of existing vehicle architectures, training staff with new skills, combining complex tools, all while maintaining safety standards and meeting project deadlines. Moving from traditional vehicle models to advanced SDVs involves many challenges that need a well-planned and thorough approach beyond simple tweaks to your existing technology. 

To successfully create an SDV, it is essential to understand its complex architecture and the important roles played by different layers within these advanced systems, from the application layer to embedded operating systems. 

OEMs face practical challenges that require creative solutions along with proven methods to overcome them. In the following sections, we will explore the key components of SDV architecture, the difficulties OEMs face, and the established practices that help achieve success in this evolving field of automotive development. Focusing on these important areas helps us better understand and analyze future innovations in the automotive industry. 

Real-world challenges for OEMs in delivering SDVs 

Building SDVs is not just a matter of adding more software; for OEMs this shift creates several real-world challenges, technical, organizational, and process-related, that many teams are still working through. 

1. Legacy architecture constraints: Many current vehicles are still built using numerous separate electronic control units (ECUs), each running specific software. These systems were designed for stability and long life, not for updates or flexible features. Changing them to support modern software features such as over-the-air (OTA) updates or cloud services necessitates costly and time-consuming architectural revisions. 
2. Software and hardware development: Traditional vehicle development is planned around hardware, with fixed milestones. But software needs to be developed and tested in fast, ongoing cycles. When the timelines of these two aspects don’t match, teams encounter delays or must replicate their work. 
3. Lack of standardized toolchains: OEMs and suppliers often use a wide variety of tools for modeling, coding, testing, and validation, but their compatibility isn’t always assured. As a result, engineers spend time converting files, managing versions, or fixing mismatches. This slows progress and increases the chance of mistakes. 
4. Organizational silos: In many OEMs, software, systems, hardware, and safety teams work separately, but in SDV development, they all need to collaborate closely from the beginning. Without shared tools, workflows, and goals, it’s hard to create a well-integrated system. 
5. Compliance with functional safety and cybersecurity standards: An increasing amount of software creates a greater need to ensure system safety and security. OEMs must follow standards, like ISO 26262 for functional safety and ISO/SAE 21434 for cybersecurity, which require strong traceability and testing across the full development process, something many teams are still adapting to. 
6. Scaling over-the-air (OTA) updates and data management: OTA updates are a major benefit of SDVs, but they also bring risks along with them. Updates must work with old systems, not introduce bugs, and be reversible if something goes wrong. Performing these in a safe and reliable way, especially for safety-critical software, is still a big challenge. 

Addressing these challenges requires a thorough revision of vehicle architecture and coordinated efforts across multiple disciplines, which can be both expensive and time consuming. 

What actually works: Proven practices from OEMs 

Leading OEMs have successfully navigated the challenges of software development for self-driving vehicles by implementing several effective strategies. To foster team synergy, these companies enhance their efficiency in integrating and developing software by employing cutting-edge tools and methodologies. 

The sections that follow will explore three fundamental practices that are crucial to this approach: Model-based design (MBD), continuous integration with DevOps principles applied alongside it, and use of simulation platforms. 

Model-based design and model-based systems engineering

Model-based design (MBD) has traditionally been used to develop and verify embedded algorithms on ECUs using tools like Simulink®. In SDVs, targets have expanded beyond ECUs to include zonal ECUs, central computing units, and cloud-based services. Algorithms are no longer signal-driven; they may now be invoked via calls in service-oriented architectures (SOAs). MathWorks tools have been updated to support this, allowing engineers to design both signal-based- and service-based interfaces. 

Automation has become essential. MBD is being integrated into CI/CD pipelines using tools like Jenkins, Git, and Artifactory. Engineers can automatically trigger model checks, generate code, run simulations, and perform static analysis every time a change is committed. This shortens iteration cycles and improves traceability and test coverage. 

Model-based systems engineering (MBSE), using tools like System Composer™, adds system architecture modeling on top of MBD. This enables engineers to: 

• Define and manage system and software architectures; 

• Allocate behavior and requirements to components. 

• Trace design artifacts across system levels; and 

• Analyze interfaces and run early system simulations. 

System Composer integrates with Simulink and Requirements Toolbox™, so teams may move from high-level system models down to tested, integrated code. This supports better coordination across software-, system-, and safety teams, and helps meet standards like ISO 26262. 

To match modern software practices, teams are moving from PLM-managed assets to Git-based workflows with branching and merging. Engineers can continuously update SDV software, before and after SOP, via OTA pipelines.  

Continuous integration and DevOps 

DevOps automation streamlines the software development process by facilitating ongoing integration and delivery, thereby accelerating the deployment of software-defined vehicles (SDVs) to market. Through automated testing within DevOps frameworks, testing frequency and software update frequency are increased, which leads to a reduction in potentially expensive recalls. By embracing DevOps methodologies, automotive firms foster an agile culture that supports swift adjustments to evolving requirements and consumer expectations. 

For businesses at the forefront of software-centric automotive development, such as Zeekr, incorporating Continuous Integration (CI) along with DevOps practices proves crucial in boosting developmental productivity. Such practices underpin Zeekr’s support for seamless continuous integration, which enables instantaneous updates for its software while maintaining robust testing procedures. Merging agile principles with continuous feedback loops serves to refine strategies concerning SDV implementation effectively. 

Read more about Zeekr here: https://www.mathworks.com/company/technical-articles/zeekr-innovates-software-defined-vehicle-engineering.html 

The role of service-oriented architectures (SOA) in SDVs 

Service-oriented architectures (SOAs) are critical in software development for Software-Defined Vehicles, as they promote the portability and modular nature of vehicle systems’ software. SOAs achieve this by enabling the independence of software components from their underlying hardware. This separation allows services to be updated or changed without impacting the entire system. Middleware within SOA acts as a facilitative layer during the development process by managing communication between services and concealing complexities associated with hardware. 

The architecture ensures that individual services can be identified via a directory service, which fosters flexible connections among them while avoiding rigid linkages between different components. Thanks to its modularity, this approach enables various applications from multiple developers to run concurrently on a single electronic control unit (ECU), which contributes greatly to improving connectivity across distinct systems. 

By separating software from hardware through an SOA framework, there’s not only an enhancement in scalability, but over-the-air updates of a vehicle after SOP are also enabled, a key advantage for architectures defining SDVs. 

How MathWorks’ tools support SDV transition 

MathWorks offers a comprehensive set of tools essential for facilitating the shift toward service-oriented applications within self-driving vehicles. Utilizing Simulink in conjunction with System Composer, engineers can craft, model, and generate code tailored for service-oriented architectures. This enables them to construct personalized live views within System Composer that depict distinct architectural designs and assessments. 

By employing MathWorks tools, companies in the automotive sector are able to refine their design and simulation workflows, promoting effective and reliable SDV deployments. The adaptability and visualization features offered by these instruments play a vital role in navigating the intricate nature of SDV structures while ensuring smooth integration of software components. 

Scalability and cost efficiency in SDV development 

Employing a centralized computing approach in vehicle manufacturing can decrease the number of ECUs, thereby improving scalability. By embracing service-oriented architecture, manufacturers are able to adapt more quickly to market shifts, which markedly eases scalability concerns. Advances in electrical and electronic (E/E) architecture facilitate significant cost savings across both production processes and the entire lifespan of a vehicle. 

Software scalability advancements help to diminish overall costs involved with developing SDVs. The use of modeling and simulation tools assists companies in reducing development expenses while accelerating software deployment timelines. These instruments empower effective oversight over vehicle functions, which allows for the modular integration and detachment of software from hardware, thus increasing system adaptability. 

Zeekr’s use of model-based design 

Zeekr uses model-based design (MBD) to accelerate software development for Software-Defined Vehicles, combining agile workflows with system-level modeling. MBD supports their full development cycle, from requirements and architecture to design, implementation, testing, and deployment, which helps them react quickly to changing requirements.

By integrating MBD into their CI/CD pipelines, Zeekr automates simulation, code generation, and testing tasks, thus reducing manual overhead and shortening iteration times. Simulation plays a key role: ~90% of their automated driving algorithms are tested virtually before hardware is involved.

They follow a hybrid V-model + agile approach, using simulation to validate early and often. This enables rapid software updates with high confidence in quality and reliability. Polyspace® is used for static code analysis to catch runtime errors and verify software correctness.

Key outcomes: 

• Faster software delivery and reduced development cost 

• Improved software quality and system reliability 

• Efficient integration of software and physical components through virtual testing 

Zeekr’s workflow reflects a scalable, modern SDV development approach, where MBD and automation bridge the gap between traditional automotive engineering and fast-paced software cycles. 

Read more about Zeekr here

Summary 

Future progress in automotive hinges on successfully implementing Software-Defined Vehicles (SDVs). OEMs must master core SDV components, address practical challenges, and apply proven engineering practices to navigate this complex, transformative space. MathWorks tools accelerate this transition by optimizing design workflows, enabling robust simulation, and supporting seamless software integration.

Moving forward, the industry must adopt the right toolchains, development methodologies, and system architectures to deliver safe, reliable, and advanced SDVs. Software innovation is now the primary driver of automotive evolution, marking a new era in vehicle technology.

Featured products

MathWorks® products:

• • MATLAB
  • Simulink
  • System Composer
  • Requirements Toolbox

 

Learn more

• Blog: Software-Defined Vehicles: The New Era of the Automotive Industry
  SDVs are transforming how cars operate and perform. Unlike traditional vehicles, they rely on advanced software to deliver continuous over-the-air updates, introduce new features, and enhance safety. In this article, we’ll look at their key benefits, technological advancements, and what the future holds for this exciting innovation.
  Read more
• Live Workshops: Designing Service-Oriented Architectures for SDVs with MathWorks Tools: A Hands-On Approach
  Get actionable insights and a clear technical roadmap to move from outdated designs to scalable, service-based architectures.
  Register here
• On-demand webinar: Driving the Future: An On-Demand Webinar on Software-Defined Vehicles
  Explore the strategic and technical foundations of SDVs and explain how modern architectures and tools are enabling faster, more modular, and scalable automotive development.
  Watch here