# Welcome The **SDV Guide** offers a comprehensive introduction to **Software-Defined Vehicles (SDVs)**. It serves as a key resource, providing a broader introduction for non-technical people while also covering the foundations and technical aspects of SDV development. The **SDV Guide** is closely aligned with the methods and best practices developed by the [digital.auto](https://www.sdv.guide/www.digital.auto) community. The first module, **SDV101**, is already available 👉 [here](https://www.sdv.guide/sdv101). It accompanies the [SDV101 course on Coursera](https://www.coursera.org/learn/sdv101/), providing additional learning materials and insights. Looking ahead, **SDV201** is currently **work in progress** and will be published on this site step by step. Stay tuned for updates and new learning opportunities in the world of SDVs!
SDV101 Guide (this site)/files/cE0CoIKZB28myyDBQBMA/pages/OnIPlIJI6FyDN0MD97bG
SDV101 Online-Course (Coursera)/files/EVQ8BOXeIBWHHiuIYHWehttps://www.coursera.org/learn/sdv101/
SDV201 Guide (Work in Progress)/files/sIBUyUCd7UfR1gaNjg6o/pages/MhUdsk2mLr9CwYMNp4Lx
./pulse Framework (beta)/files/x0scBkZdaIIO03go4T5Rhttps://www.sdv.guide/.-pulse
digital.auto Community/files/pcv8JmEWCRTw6nRVNjaZhttps://www.digital.auto/
# SDV101 Welcome to **SDV101**, the first part of the **SDV Guide** series. This guide accompanies the **SDV101: Introduction to Software-Defined Vehicles** course on Coursera, providing additional insights, explanations, and examples to support your learning journey. It is the successor to the successful Software-Defined Vehicle ebook by O'Reilly (Dirk Slama, Achim Nonnenmacher, Thomas Irawan). Whether you are new to the world of Software-Defined Vehicles or looking to strengthen your understanding, this guide will serve as your reference throughout the course and beyond. Let’s begin your journey into the exciting field of Software-Defined Vehicles! ## Outline
Part A: Essentials/files/EEu8Ho1XdxYvOgL1uu0D/pages/znQfYfmFr1ziUE5yXo2g
Part B: Lessons Learned/files/hgPKCjRuHF5s8zqYcuzH/pages/O5Cf8cvyorZOGTz7vumM
Part C: Building Blocks/files/78CpnFZcc4j9d7QfNTE8/pages/mZQKZIs1qXbyiuOShZ6B
Part D: Implementation Strategies/files/NemPYC7AbNwPb2Er4qQU/pages/DXdAgdQEtLSKnJ0hMsCo
## Roots of this Project In 2023, Dirk Slama (Bosch/Steinbeis FSTI), Achim Nonnenmacher (ETAS), and Thomas Irawan (ETAS) published the foundational *Software-Defined Vehicle* 👉 [ebook](https://www.oreilly.com/library/view/the-software-defined-vehicle/9781098157814) with O'Reilly. This pioneering work introduced key concepts and provided a solid starting point for understanding the SDV paradigm.
Building on this foundation, the *SDV Guide* has been re-imagined as a much more comprehensive resource, expanding the original content to five distinct parts. These additions dive deeper into the evolving SDV ecosystem, offering advanced topics, real-world case studies, and the latest industry insights. Far from being a mere extension or copy, the *SDV Guide* delivers a robust framework for practitioners, researchers, and innovators, shaping the future of automotive software development. ## Contributors to the SDV Guide Lead Author: Dirk Slama, VP Bosch, Prof. at Ferdinand Steinbeis Institute, Germany Lead Content Advisor: Achim Nonnenmacher, ETAS Content review board * Damian Dyrbusch, Bosch * Jens Gerle, Bertrandt * Mohan BV, Bosch * Sven Kappel, ETAS * Ulrich Schulmeister, Bosch Content contributors * Achim Nonnenmacher, ETAS * Augustin Friedel, MHP - A Porsche Company * Chris Seiler, Mercedes * Dieter Schwarzmann, Bosch * Dominik Morar, Ferdinand-Steinbeis-Institut * Felix Strauß, Bertrandt * Frédéric Merceron, Dassault Systèmes * Indrasen Raghupatruni, Bosch * Jan Becker, ApexAI * Marco Wagner, Hochschule Heilbronn * Sarunas Kondratas, NIO Use of GenAI: GenAI was instrumental in supporting the content creation for the *SDV Guide*, enabling efficient drafting, refinement, and expansion of complex topics to provide a comprehensive and up-to-date resource. ## Copyright and license SDV Guide and SDV 101 Guide, Copyright 2024: Dirk Slama, Germany License: CC BY 4.0 (Creative Commons). Please cite us and link back to this web site when using content from the SDV Guide. Thank you! ## Formal Citation Templates ### APA Style Slama, D. (2024). *SDV101: Introduction to Software-Defined Vehicles*. Retrieved from [https://www.sdv.guide](https://sdvguide.gitbook.io/)/sdv101 ### MLA Style Slama, Dirk. *SDV101: Introduction to Software-Defined Vehicles*. 2024, [https://www.sdv.guide](https://sdvguide.gitbook.io/)/sdv101. ### Chicago Style Slama, Dirk. 2024. *SDV101: Introduction to Software-Defined Vehicles*. Accessed \[Date]. [https://www.sdv.guide](https://sdvguide.gitbook.io/)/sdv101 ## Disclaimers The **SDV101 Guide** is intended for informational and educational purposes only. While every effort has been made to ensure the accuracy and relevance of the content, it is provided "as is" without any guarantees or warranties of any kind, express or implied. The authors, publishers, and contributors disclaim all liability for any errors, omissions, or inaccuracies in the content. ### No Professional Advice The content of the **SDV101 Guide** does not constitute professional, technical, legal, financial, or business advice. Readers are advised to consult with qualified professionals before making decisions based on the information provided in this guide. Use of the information is at your own risk. ### Intellectual Property The **SDV101 Guide** may reference trademarks, copyrights, or other intellectual property belonging to third parties. Such references are for illustrative purposes only and do not imply endorsement or affiliation. All rights to these materials remain the property of their respective owners. ### Limitation of Liability Under no circumstances shall the authors, publishers, or contributors of the **SDV101 Guide** be liable for any direct, indirect, incidental, special, consequential, or punitive damages arising out of or in connection with the use of this guide or its content. ### External Links and Third-Party Content The **SDV101 Guide** may include links to external websites or reference third-party content. These are provided for convenience only and do not constitute an endorsement or approval of the content, products, or services offered by third parties. The authors, publishers, and contributors of the **SDV Guide** are not responsible for the content or accuracy of external links or third-party materials. ### Updates and Revisions The **SDV101 Guide** is subject to updates and revisions. The authors and publishers reserve the right to modify, update, or remove content without prior notice. ### Governing Law This disclaimer and the use of the **SDV101 Guide** shall be governed by and construed in accordance with the laws of the jurisdiction in Germany. ### Acceptance of Terms By using the **SDV101 Guide**, you acknowledge that you have read, understood, and agree to the terms of this legal disclaimer. If you do not agree with any part of this disclaimer, you should not use the guide. # Part A: Essentials # Smart Phone? No: Habitat on Wheels! When Tesla sparked the electric vehicle revolution, people often described its cars as "smartphones on wheels." This comparison came from how Tesla fundamentally redefined cars as **software-centric connected devices** rather than purely mechanical machines.
{% embed url="" %} Modern vehicles, especially electric ones, do share some notable similarities with smartphones: #### **Key Similarities with Smartphones** 1. **Touchscreen-Centric Interfaces**\ Physical buttons have been largely replaced by app-like touchscreen interfaces, creating a user experience similar to smartphones. 2. **Connectivity and Cloud Integration**\ Vehicles are constantly connected to the internet, enabling real-time navigation, diagnostics, and data sharing—just like smartphones. 3. **Over-the-Air Updates**\ Modern vehicles receive frequent software updates, improving functionality and fixing bugs without visiting a service center. 4. **Personalization**\ Cars now offer driver profiles and personalized settings, adapting to individual preferences much like a smartphone would. 5. **Ecosystems and App Stores**\ The concept of app ecosystems is slowly emerging in vehicles, making them dynamic platforms for software, connectivity, and user experiences. *** #### **Why “Smartphone on Wheels” Falls Short** Despite these similarities, calling modern cars “smartphones on wheels” isn’t entirely accurate. Here’s why: 1. **Functional Safety**\ A car must prioritize safety because **traffic accidents** can have life-threatening consequences—a concern far beyond smartphone functionality. 2. **Habitat on Wheels**\ We spend significant time in our vehicles, often using them for personal, family, and professional purposes. With features like teleconferencing and automated driving, cars are evolving into a kind of **habitat on wheels**, not just a tech gadget. *** #### **What This Means for SDV101** Throughout this guide, we will explore these concepts further and explain why modern vehicles should be thought of as **"habitats on wheels"**—complex, software-driven environments that blend mobility, connectivity, and safety in ways smartphones never could. # Basics: What is a Software-defined Vehicle ## What is a Software-Defined Vehicle? To answer this question, we need to look at two different perspectives: the **customer perspective** and the **OEM (Original Equipment Manufacturer)** or **car manufacturer's perspective**.
### **Customer Perspective** From the customer’s point of view, a software-defined vehicle is: * **Connected**: Always online and integrated into a digital ecosystem. * **Personalized**: Tailored to user preferences with driver profiles and custom settings. * **Ever-Expanding**: New features and services can be activated through updates and app stores. * **Self-Updating**: Software updates bring improvements and new features automatically. It’s becoming more than just a car—it’s a **habitat on wheels**. ### **Manufacturer Perspective** From the manufacturer’s point of view, a software-defined vehicle: * **Enables Vehicle Experiences**: Through advanced software-driven features. * **Decouples Hardware and Software**: Allowing for faster, modular development. * **Uses Open Standards and Open Source Software**: Encouraging a collaborative ecosystem. * **Supports Iterative Development**: Continuous improvement and regular updates. The core philosophy is **continuous improvement** and **ecosystem-centric design**. *** ## Horsepower vs Gigaflops How can a software-defined vehicle support differentiation? Today, especially among younger generations and in regions like China, the definition of what makes a car valuable is shifting. It's no longer just about **horsepower** but about **gigaflops**, reflecting digital performance. Cars are now judged by their **digital experience**, not just physical attributes. This includes: * **Entertainment Features**: Like in-car karaoke. * **Interactive Systems**: AI-powered assistants and advanced infotainment. * **Software-Enabled Services**: Custom digital features that can be added after purchase. This **software-driven differentiation** is reshaping what makes a vehicle stand out. *** ## What is at the Center of the Universe? In our modern world, we’ve moved from a **geocentric** to a **heliocentric** view of the universe.
But in the automotive world, this question still has two possible answers: #### **Smartphone-Centric World** From the **customer's perspective**, the smartphone is the primary tool. They expect cars to fit into their smartphone-driven ecosystem seamlessly, offering easy integration, data sharing, and familiar interfaces. #### **Car-Centric World** From the **OEM’s perspective**, they prefer the car to be the central ecosystem. They are reluctant to play second fiddle to smartphone companies, as this could limit their control over customer interactions and valuable data.
#### Market Examples * **Apple**: Rumored to have explored building its own electric car but may have paused due to profitability concerns. * **Xiaomi**: Has entered the automotive market with the **Xiaomi SU7**, a car many describe as a "smartphone on wheels." The competition between these two perspectives will continue to shape the future of mobility. ## Always Connected: Customer Perspective From the **customer's perspective**, an always-connected software-defined vehicle offers a seamless digital experience, including: * **Navigation and Traffic Alerts**: Real-time route updates and traffic warnings. * **Connected Infotainment Services**: Streaming music, podcasts, and videos on the go. * **Remote Vehicle Apps**: Control functions like unlocking doors or starting the engine remotely. * **On-Demand Services**: Location-based services like ridesharing or delivery. * **Maintenance and Emergency Services**: Automatic updates, diagnostic alerts, and emergency assistance. * **Smart Home Integration**: Connecting the car to home automation systems for convenience.
*** ## Always Connected: OEM Perspective Traditionally, OEMs **lost contact with vehicles** the moment they left the factory. Their only touchpoints with customers came through **occasional repair visits** or **aftermarket services**, leaving them with little insight into how vehicles were used on a day-to-day basis. This lack of data limited their ability to understand product performance, anticipate issues, and offer tailored services. The arrival of connected cars has **eliminated this disconnect**, enabling continuous monitoring and customer interaction. From the **OEM's perspective**, connected vehicles revolutionize the entire automotive business: * **Real-Time Data Insight**: Understanding how cars are used, which features are popular, and identifying problems early. * **Continuous Product Improvement**: Using customer feedback and data analytics to improve product features and user experiences. * **Enhanced Customer Relationships**: Offering personalized services and creating long-term customer engagement. * **Revenue Optimization**: Developing new revenue models through connected services, upgrades, and feature subscriptions.
*** ## Never Finished In the **old way of working**, developing a new vehicle model was treated as a **project with a clear endpoint**: the **Start of Production (SOP)**. After SOP, the development team moved on, and only a few years later, a **new project** might be initiated to create a vehicle **facelift** or **next-generation model**. This approach left little room for continuous improvement after the vehicle’s initial release.
In the modern **software-defined vehicle (SDV)** paradigm, the concept of **"never finished"** is visualized as a continuous improvement process following the **Start of Production (SOP)** milestone. Unlike traditional automotive development models that ended with SOP, SDVs embrace iterative enhancements: #### **Customer Benefits:** * **Regular Improvements**: Regular updates ensure a constantly improving user experience. * **New Features on Demand**: Customers can activate new functionalities as needed. * **Personalization**: Tailored settings and user experiences. * **Value Retention**: Updates ensure the vehicle remains relevant and competitive over time. #### **Manufacturer Benefits:** * **New Business Models**: Opportunities for subscriptions, feature unlocks, and service-based revenue streams. * **Build/Measure/Learn Cycle**: Continuous feedback loop to optimize features and performance. * **Agile Organization**: Adoption of new processes and ways of working. * **Ecosystem Expansion**: Vehicles are part of a broader digital and connected ecosystem. This approach represents a shift from static product development to a **dynamic lifecycle model**, benefiting both customers and manufacturers.
*** ## Cost Perspective The **cost perspective** in automotive has changed with the rise of software-defined vehicles: * **Battery Cost Management**: Software helps optimize energy use, extending battery life and reducing costs. * **Reduced Bill of Materials (BOM)**: Shifting features from hardware to software lowers engineering and production costs. * **Simplified Vehicle Variants**: Offering only basic vehicle models and enabling additional features via software unlocks. * **Increased Reuse**: Software platforms can be reused across models, reducing development costs and time-to-market. * ```
``` *** ## The Big Shift The automotive industry is undergoing a **big shift** in how vehicles are developed: * **From Hardware-Centric to Software-Centric**: Software defines the vehicle's value, making hardware upgrades less critical. * **Platform Standardization**: A unified software platform supports multiple models, reducing complexity. * **Ecosystem Expansion**: Cars become part of a larger digital ecosystem, offering compatibility with external platforms like smartphones. * **Re-Use as a Key Enabler**: Developing the **core software platform once**, then deriving customized versions for specific vehicle models using **APIs** for model-specific features while keeping **one shared platform** across all vehicle models.
*** ## Key Enabler: SDV Approach The **Software-Defined Vehicle (SDV) Approach** relies on several technical building blocks: * **Hardware Abstraction**: Decoupling hardware from software for modular development. * **APIs and Service-Oriented Architectures (SOA)**: Enabling communication between software components. * **Container Technology**: Isolating services to run them independently and securely. * **DevOps and Automated Pipelines**: Streamlining development, testing, and deployment processes. * **Virtualization**: Allowing development before hardware is ready through virtual testing environments. * **Continuous Homologation**: Ensuring faster regulatory approvals for new features and updates.
# MHP: Expert Opinion The SDV transformation demands not only technological evolution but also organizational agility and strategic foresight. **Augustin Friedel** (Senior Manager at MHP - A Porsche Company) provided the input in this chapter to help OEMs navigate the challenges and unlock the potential of this game-changing paradigm. ## Software-defined Vehicle The Software-Defined Vehicle (SDV) is considered a game changer in the automotive industry. It aims to meet growing customer expectations for features and functions. The term "Software-Defined Vehicle" (SDV) itself is coined by the automotive industry and is not typically relevant for customer marketing.
The core principle of SDVs involves shifting from hardware-embedded software to a setup where software is fully decoupled from the hardware. This creates an abstraction layer for control and management. Much like smartphones, PCs, or tablets, SDVs feature a base hardware layer over which an operating system (OS) runs, enabling flexibility in software and feature management. Operating systems, such as iOS, Android, Linux, or other proprietary platforms, provide the foundation for this innovation in vehicles. To move forward, SDVs are conceptualized in layers. The **base layer** consists of vehicle hardware (e.g., sensors, high-performance computers, actuators, batteries, and wiring), along with core vehicle software such as the operating system. Above this, the **customer-centric layers** include UX/UI components linked to intelligent cockpits, in-car software, contextual intelligence, and artificial intelligence. A critical enabler for SDVs is **cloud integration**, which connects vehicles with external devices like smartphones and enables digital twins. This integration ensures the smooth delivery of features for the cockpit, management of vehicle ecosystems, and enhanced interconnectivity with external environments. ## Shift in the E/E-Architecture The evolution toward SDVs is closely tied to a shift in Electrical/Electronic (E/E) architecture. Historically, vehicles utilized distributed architectures with more than 150 ECUs spread across various vehicle zones. Modern designs, however, aim to consolidate compute power into **zonal or centralized architectures**.
Zonal architectures reduce the number of ECUs by grouping them into zones, allowing for streamlined communication and compute processes. This shift enhances cost efficiency, simplifies integration, and supports a higher degree of standardization. While centralized architectures are the end goal for many OEMs, transitional models, such as modern domain architectures, serve as intermediate steps. The choice between these approaches depends on the strategic priorities, budgets, and skills of individual OEMs. Governance plays a critical role in managing this transformation. OEMs must structure their organizations effectively to address the challenges of transitioning to modern E/E architectures and ensure their development roadmaps align with market demands. ## E/E + SDV Combining E/E architectures with SDV principles facilitates a unified approach to vehicle design. **Standardized APIs** are a crucial enabler for this integration, bridging the gap between hardware and software. These APIs simplify the integration process, reduce costs, and create a modular system that can adapt to customer requirements over time.
By decoupling the base hardware layer from user-centric features and functionalities, manufacturers can achieve greater flexibility. For instance, features like digital cockpits and AI-driven personalization can be updated independently of hardware upgrades, enabling vehicles to remain competitive throughout their lifecycle. ## Different Change Pace for Each OEM The automotive industry is witnessing varied progress among OEMs in adopting SDV principles. Based on the **Gartner Digital Automaker Index 2024**, OEMs are categorized into three tiers: 1. **Leaders**: Companies, particularly in China, are at the forefront of immersive SDV technologies, leveraging AI and cloud integration. 2. **Middle Field**: Primarily OEMs from Japan, Korea, and parts of Europe, which are transitioning from smart car features to full SDV integration. 3. **Challengers**: OEMs that are still focusing on basic smart car capabilities, such as OTA updates and first-generation app stores. China, with brands like Huawei, Xiaomi, and JiYue, has surpassed Tesla in several areas of SDV development, particularly in immersive digital living spaces. This regional advantage stems from a focus on AI-driven features, intelligent cockpits, and rapid software development cycles.
## Levels of SDVs SDVs can be categorized into three progressive tiers: 1. **Smart Cars**: Vehicles offering basic OTA updates, app stores, and limited customization. 2. **Software-Defined Vehicles**: These feature smartphone-like OS releases, extensive backward compatibility, and flexible compute power. 3. **Immersive SDVs**: Fully integrated with AI and contextual intelligence, these vehicles offer seamless cloud connectivity and cutting-edge features. Immersive SDVs are predominantly seen in advanced markets like China, while Europe and the US are still transitioning. ## Two Speed Delivery Model To manage the complexities of SDV development, OEMs adopt a **two-speed delivery model**: Fast Cycle vs Slower Cycle. This approach allows manufacturers to address both the demand for rapid innovation and the need for robust platform-level development.
### **Fast Cycle** The fast cycle focuses on feature development, leveraging **DevOps** and **agile methodologies**. This approach enables quick iterations and faster delivery of new features. Key elements include: * CI/CD pipelines for streamlined development and integration. * Shift-North strategies to accelerate innovation and feature rollouts. ### **Slower Cycle** The slower cycle involves platform-level development using systems engineering models like the **V-model**. A **shift-left** approach ensures early identification and resolution of issues during development, minimizing costly fixes later in the process. This dual-speed framework helps OEMs balance rapid feature delivery with robust platform development. # 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. # SDV Domains and Two-Speed Delivery ## SDV Domains Let us now explore the different **Software-Defined Vehicle (SDV)** domains, and how they can best be supported by a Two-Speed Delivery Model. The main vehicle domains include **AD ADAS**, **Motion**, **Energy**, **Body & Comfort**, and **Vehicle Experience**, encompassing **Infotainment** and **Value-Added Services**.
Each domain contributes unique functionalities and carries varying levels of safety-critical requirements, categorized into **ASIL** and **QM** ratings.
## AD/ADAS The **AD/ADAS (Automated Driving / Advanced Driver Assistance Systems)** domain includes systems like: #### ASIL Functions: * **Lane Keeping Assist**: Maintains the vehicle within lane boundaries. * **Adaptive Cruise Control**: Maintains speed and distance relative to other vehicles. * **Fully Automated Driving**: Self-driving capabilities requiring robust functional safety. * **Electric Power Steering**: Essential for precise control and safety. #### QM or ASIL-A Functions: * **Camera Display Systems**: Provides visual alerts about vehicles in blind spots. These are rated QM or ASIL-A as they only inform the driver without taking corrective action. * **Traffic Sign Recognition**: Detects and displays signs like speed limits for driver awareness, typically QM or ASIL-A due to limited safety implications. * **Basic Parking Assist**: Alerts the driver of nearby obstacles but does not intervene in steering or braking, making it QM or ASIL-A.
## Motion The **Motion domain** focuses on core driving and vehicle control functions. #### ASIL Functions: * **Anti-Lock Braking Systems (ABS)**: Prevents wheel lock during braking. * **Electronic Stability Control (ESC)**: Maintains vehicle stability during maneuvers. * **Brake-by-Wire Systems**: Replaces mechanical braking with electronic systems. * **Electronic Power Steering (EPS)**: Ensures precise steering control. #### QM or ASIL-A Functions: * **Powertrain Modes**: Eco or Sport driving settings enhance user experience without impacting safety-critical systems. * **Non-Critical Drivetrain Adjustments**: Torque distribution or shift patterns for improved driving feel. * **Suspension Settings for Comfort**: Adjustable modes like soft or firm improve ride quality. * **Cosmetic Bumpers**: Provide minor protection and aesthetics but are non-safety-critical.
## Energy The **Energy domain** differs significantly across electric, hybrid, and combustion vehicles. #### ASIL Functions: * **Battery Management Systems (BMS)**: Monitors and controls battery performance. * **High Voltage Distribution Systems**: Ensures safe power delivery. * **Thermal Management Systems**: Regulates operating temperatures. * **Regenerative Braking**: Recaptures energy during braking. * **Onboard Charging Control**: Manages electric vehicle charging processes. #### QM or ASIL-A Functions: * **Battery Charge Level Display**: Provides status without impacting safety. * **Auxiliary Power Management**: Controls non-critical electrical systems. * **Solar Panel Integration**: Enhances energy efficiency but is non-safety-critical.
## Body & Comfort The **Body & Comfort domain** spans structural and convenience features, with safety-critical and non-critical elements. #### ASIL Functions: * **Seat Belt Pre-Tensioners**: Tighten belts during crashes for occupant safety. * **Airbag Systems**: Deploy to protect occupants during collisions. * **Door Locking Systems**: Maintain security and safety. * **Active Head Restraints**: Minimize whiplash injuries. * **Pedestrian Protection Systems**: Reduce injury risks in collisions. #### QM Functions: * **HVAC (Heating, Ventilation, and Air Conditioning)**: Maintains cabin comfort. * **Power Seat Adjustments**: Customizes seating positions. * **Sunroof Operations**: Adds convenience without impacting safety. * **Power Windows and Mirrors**: Enhances usability.
## Vehicle Experience The **Vehicle Experience domain** focuses on overall user experience, primarily rated QM. #### QM Functions: * **Personalized Settings**: Tailored user profiles for comfort and convenience. * **Passenger Welcome Sequences**: Algorithms that adjust the seat and open doors based on user preferences. These QM algorithms often interact with ASIL-rated systems through safe APIs. For example, a welcome sequence algorithm may open doors (ASIL-rated) but remains non-critical itself.
## Infotainment The **Infotainment domain** enhances the driving experience through connectivity and entertainment features, generally rated QM. #### QM Functions: * **Audio Systems**: Manage sound entertainment. * **Navigation Systems**: Provide real-time routing and traffic updates. * **Media Controls and Displays**: Offer user-friendly interfaces for controlling media. * **Smartphone Integration**: Connects mobile devices to the vehicle. Infotainment warnings (e.g., attention prompts) inform drivers but do not control safety-critical systems, keeping them out of the ASIL domain.
## Value-Added Services The **Value-Added Services domain** focuses on convenience and innovation, also primarily rated QM. #### QM Functions: * **Subscription-Based Features**: Unlockable digital services. * **Non-Critical Predictive Maintenance**: Offers proactive notifications without safety implications. * **Smart Home Integration**: Connects vehicles to home automation systems. * **E-Commerce and Sustainability Services**: Adds functionality without affecting safety.
## SDV Domains: Summary Each domain maps differently to the ASIL vs. QM framework: * **ASIL-Dominant**: AD ADAS, Motion, Energy. * **QM-Dominant**: Vehicle Experience, Infotainment, Value-Added Services. * **Mixed**: Body & Comfort.
## Two-Speed Delivery Model Implementing a **two-speed delivery model** for Software-Defined Vehicles (SDVs) requires a clear understanding of **QM** and **ASIL** ratings to effectively balance fast innovation with safety compliance. This approach ensures seamless integration and efficient resource allocation while addressing both safety-critical and non-critical domains.
### Aligning Speed with Safety Requirements * **QM Systems**: Enable faster iterations and agile development for non-critical features. * **ASIL Systems**: Require rigorous, slower validation processes to meet functional safety standards. ### Optimizing Resource Allocation * **Agile Teams**: Focus on QM domains to accelerate development cycles. * **Specialized Teams**: Handle safety-critical ASIL systems, ensuring compliance and robustness. ### Ensuring Smooth Integration Differentiating QM and ASIL ratings avoids conflicts between safety-critical and non-critical domains, enabling: * Clear separation of development workflows. * Harmonized interactions across domains. ### Balancing Innovation and Compliance Encourage rapid development in QM areas while maintaining stringent safety standards for ASIL-rated functions. This dual approach fosters: * Continuous innovation. * Regulatory compliance. ### Mitigating Risks Effectively Fast updates in QM domains are carefully managed to ensure they do not compromise the reliability of ASIL systems. This minimizes risks while maximizing flexibility. The two-speed delivery model enables SDV developers to address the diverse requirements of modern vehicles, combining agility and safety to drive innovation without sacrificing reliability. By aligning development strategies with domain-specific requirements, OEMs can optimize both user experience and functional safety. # Part B: Lessons Learned In part B, we’ll take a step back and explore the valuable lessons that the Internet and smartphone industries have to offer. By reflecting on their evolution, best practices, and key innovations, we’ll uncover strategies that can guide the development of SDVs. From early e-commerce pioneers like Amazon to the seamless user experiences of modern smartphones, this part will highlight how these industries overcame challenges, embraced agility, and leveraged technology to transform the world. # Learnings from the Internet Folks From the Internet, we’ll examine the interplay between innovation and cloud-native best practices, understanding how rapid experimentation and resilient architectures drive success. We’ll begin by analyzing innovation principles from the Internet to set the stage for adaptable, forward-thinking strategies. Then we will look at lessons learned from Cloud Native Development, including DevOps, Continuous Delivery and Loose Coupling. # Innovation Management The intranet’s transformative journey began with the emergence of affordable personal computers, early browsers like **Mosaic** and **Netscape Navigator**, and accessible intranet service providers. Early milestones included the rise of search engines such as **Yahoo (1994)** and **Google (1998)**, which laid the foundation for today’s ubiquitous mesh of online services, representing a multi-billion-dollar industry that has revolutionized daily life. For example, **Amazon’s early evolution** showcases rapid adaptation. From its rudimentary website in 1995 to its modern, user-centric interface in 2024, Amazon illustrates the power of iterative improvement and customer-focused design.
Behind the success of modern Internet companies lies a powerful toolbox of methodologies: **design thinking**, **lean startup**, and **agile development**. Together, these three frameworks—design thinking, lean startup, and agile—offer a holistic approach to innovation by combining user-centric problem solving, rapid iteration, and flexible, adaptive workflows. They have driven transformative success in the intranet and smartphone industries and hold valuable lessons for SDVs. ## Key Innovation Frameworks ### Design Thinking **Design thinking** is a human-centered, iterative problem-solving approach that focuses on understanding user needs, challenging assumptions, and exploring innovative solutions. Combining empathy, creativity, and rationality, this approach redefines problems to develop practical, user-centric outcomes. By prioritizing the user, design thinking has driven the creation of more meaningful and impactful products.
### Lean Startup The **lean startup** methodology emphasizes rapid experimentation, validated learning, and iterative development to minimize waste and maximize value. At its core is the **build, measure, learn** cycle, which guides businesses to test ideas quickly, gather feedback, and adapt. #### Example: Iterative Testing at Amazon A concrete example is **Amazon’s iterative testing approach**: * A customer feedback dialog box was tested in three variations, each featuring small changes like different fonts or icons. * These variations were deployed to thousands of users, with the feedback informing which version to scale up. * This method allowed Amazon to continuously optimize its offerings, improve customer experience, and maximize revenue.
A central concept of lean startup is the **minimum viable product (MVP)**, enabling early customer feedback and iterative improvement. From an SDV perspective, this raises the question: **What is the MVP of a car?** ### Agile **Agile development** has been a cornerstone of software innovation for the past two decades. Built on the foundation of the **Agile Manifesto**, agile emphasizes: * **Individuals and interactions** over rigid processes. * **Working software** over comprehensive documentation. * **Customer collaboration** over contract negotiations. * **Responding to change** over following fixed plans. #### Agile Frameworks: 1. **Scrum**: Organizes work into iterative cycles called sprints, emphasizing collaboration, accountability, and continuous improvement. 2. **Kanban**: Visual workflow management that limits work in progress, optimizes flow, and focuses on delivering value efficiently. ### Summary When combined, **design thinking**, **lean startup**, and **agile** form a powerful foundation for innovation. Though not always an exact science, this synergy has driven the success of many intranet-based businesses.
## Applying Internet Best Practices to Software-Defined Vehicles We have explored best practices from the internet industry, including **design thinking**, **lean startup**, and **agile**, and the big question is: how much of this can be applied to the automotive industry, particularly in the development of Software-Defined Vehicles (SDVs)? ### Balancing First-Time Right and MVP Approaches Automotive development requires understanding which features demand a **first-time right** approach and which can adopt an **MVP (Minimum Viable Product)** strategy: * **First-Time Right Features**: Safety-critical components like airbags and driving-related systems require rigorous processes to ensure failure-free operation from the outset. * **MVP Features**: Vehicle experience-related features, such as personalized settings or infotainment systems, can be iteratively and experimentally improved over time. The key is determining the appropriate approach for each feature or feature component.
### Challenges to Agile Practices in Automotive While agility is desirable, several factors necessitate a more rigid, planning-oriented process in many areas of automotive development: 1. **Safety-Critical Features**: * High safety demands prevent catastrophic failures and require rigorous validation. 2. **Cross-Organizational Alignment**: * Large organizations and multi-stakeholder collaborations (OEMs, suppliers, regulators) require stable requirements and extensive planning. 3. **Hardware and Mechanical Parts**: * Fixed specifications and long lead times necessitate detailed planning and stability. 4. **Fixed-Price Development Contracts**: * For software components or AI-enabled functions, fixed-price contracts mandate predefined deliverables and timelines. 5. **Manufacturing Setup**: * Long lead times and the need for planning stability make agile practices challenging in manufacturing contexts. 6. **Regulatory Compliance**: * Despite emerging practices like continuous homologation, regulatory requirements often demand detailed documentation and stable processes. These challenges explain why the automotive industry continues to rely on planning-oriented approaches like the V-model, often combined with agile practices for specific areas.
### The Digital-First Paradigm To address these challenges and enable faster, more customer-centric development, the **digital-first paradigm** is emerging as a transformative approach. It consists of two key elements: 1. **Shift North**: * Moving functionality out of deeply embedded areas and above the hardware abstraction layer. * Enables faster, more agile development by decoupling software from hardware constraints. 2. **Shift Left**: * Emphasizes early-stage prototyping, simulation, and virtualization. * Facilitates upstream testing and validation to catch issues early, reducing downstream costs and risks. These strategies help balance the need for safety and stability with the agility required to innovate in the rapidly evolving world of SDVs.
Further exploration of the **digital-first paradigm**, including **shift left** and **shift north**, will be covered in the following sections. # Cloud Native Principles Having explored innovation in the Internet, we now turn to **cloud-native principles**, the foundation for agile methods, DevOps, and continuous improvement.
## The Power of Cloud-Native Principles **Cloud-native architecture** emphasizes modularity and loose coupling, creating a foundation for scalability and resilience. These principles enable rapid deployment, testing, and iteration without disrupting production systems, fostering a more agile and responsive development process. When combined with **DevOps practices** like automation and Continuous Delivery, supported by automated pipelines, cloud-native approaches allow teams to adapt quickly, reduce risk, and consistently deliver value to users. ## The Role of Open Source Open source is integral to the success of cloud-native principles. It provides a collaborative ecosystem where developers can build on shared tools, frameworks, and best practices. Open source not only accelerates innovation but also ensures transparency, security, and interoperability, making it a cornerstone of modern software development. Let’s dive into how these principles power modern software development and drive the transformation of industries like automotive. # DevOps and Continuous Delivery C**loud-native principles** form the foundation for agile methods, DevOps, and continuous improvement. Supported by **DevOps practices** like automation and collaboration, and **continuous delivery pipelines**, cloud-native principles empower teams to adapt quickly, reduce risk, and consistently deliver value. ## DevOps and Continuous Delivery: Two Sides of the Same Coin **DevOps** provides the **cultural framework**, while **Continuous Delivery (CD)** delivers the **technical practices** for implementing cloud-native systems.
## DevOps: Breaking Down Silos DevOps is a cultural and organizational approach that eliminates silos between development, operations, and testing teams to foster seamless collaboration. A personal example highlights the importance of this: > "Years ago, I worked on a development team for a major airline, building a tool using new technology—a NoSQL database. Despite our progress, the operations team eventually refused to support it because their processes only allowed relational databases. We had to redesign the architecture to meet operational requirements, wasting time and effort" Dirk Slama, Lead Author This story underscores the core principle of DevOps: ensuring alignment between different teams like development and operations from the start. ## Continuous Delivery: Automating the Release Process CD automates the software release process, enabling frequent and reliable deployments. Tools like Jenkins, Docker, and Selenium streamline this pipeline, making it possible to: * Commit code. * Build systems. * Test, deploy, and operate systems efficiently. The synergy between DevOps and CD results in faster delivery, reduced errors, and continuous feedback, essential for innovation at scale. ## The DevOps and CI/CD Infinity Loop The **DevOps infinity loop** illustrates the lifecycle of software delivery: 1. **Plan**: Define upcoming changes. 2. **Develop**: Write and test code or create AI models. 3. **Build**: Compile and package source code or AI models into executable software that is ready for deployment. 4. **Test**: Validate functionality and performance. 5. **Release**: Deploy software (including AI models) to production. 6. **Operate**: Monitor the system in real-time. 7. **Learn**: Gather insights to improve future iterations. Modern development extends beyond traditional coding to include training and fine-tuning AI models, integrating data from operational environments, and deploying assets not just to the cloud but also to edge devices, such as smartphones and IoT devices.
## Pipelines: Automating the Development Lifecycle Pipelines automate and streamline the development lifecycle, from code commitment to deployment. Key tools include: * **GitHub**: Code management. * **Maven**: Build automation. * **Selenium**: Web testing. * **Docker**: Containerization. * **Jenkins**: Orchestration and automation across all steps. These pipelines ensure faster delivery, higher quality, and reduced errors. However, in the automotive industry—especially for embedded systems—many of these goals remain unmet.
## Independent Pipelines for Collaborative Development Consider an example where two teams develop components independently: 1. **Team A** develops a smartphone app. 2. **Team B** builds a cloud backend for the app. Each team uses its own pipeline to independently test and iterate on its component. During early stages: * Team A uses a mock backend service for testing. * Team B uses a mock smartphone app for validation. Once both components are stable, they merge in an integration pipeline to: * Test the combined system. * Deploy the complete solution. * Monitor the system holistically to identify improvements. This approach ensures flexibility in development while enabling smooth integration and deployment.
## The Road Ahead for Automotive While these cloud-native principles are widely adopted in internet-based systems, the automotive industry—especially for embedded software—faces significant challenges. Automation, agile practices, and continuous delivery pipelines offer immense potential to transform this sector by enabling: * Faster delivery. * Enhanced quality. * Continuous feedback and innovation. By learning from cloud-native best practices, automotive development can evolve to meet the demands of modern software-defined vehicles. # Loose Coupling Loosely coupled architectures offer a solution to the challenges of scaling and maintaining complex software systems by emphasizing modularity and independence. ## The Tower of Babel: A Lesson in Coordination Many of you may know the story of the **Tower of Babel**—a biblical tale where humanity's ambition to build a tower to reach heaven failed due to a lack of shared language. This breakdown in communication, coordination, and unity mirrors challenges seen in disorganized software projects. Without consistency in design or structure, achieving a cohesive system becomes impossible, often leading to failure.
In mature software systems, similar issues arise: * Millions of lines of code and thousands of files grow organically. * Short-term demands lead to tightly coupled components with numerous interdependencies. * Shared variables, memory, and databases make understanding the system difficult. * Changes in one area frequently break other parts. * Testing and fault isolation are nearly impossible, requiring full system rebuilds even for minor fixes. This "Gordian knot" of complexity demands a solution, and the answer lies in **decoupling**. ### The Bento Box Analogy: Understanding Loose Coupling A **bento box**—a traditional Japanese meal container with separate compartments—is a powerful analogy for **loose coupling** in software architecture. Each compartment holds a specific food item, such as rice, proteins, or vegetables, separate from others, yet collectively forming a complete meal.
Similarly, loosely coupled architectures share these characteristics: 1. **Independence**: Each module or service performs a distinct function, like food compartments in a bento box. 2. **Boundaries**: Clear separations prevent changes in one module from affecting others. 3. **Interoperability**: Modules work together cohesively, like a meal’s components complementing each other. 4. **Flexibility**: Modules can be modified, replaced, or removed without impacting the entire system. These principles foster scalability, maintainability, and adaptability, essential traits for modern software systems. ### Tight vs. Loose Coupling To understand the benefits of decoupling, it is essential to compare tightly coupled and loosely coupled architectures, highlighting their respective advantages and trade-offs.
#### Loosely Coupled Architectures: * Functional nodes are grouped and connected by minimal links. * Benefits: * Reduced interdependencies. * Easier coordination of changes. * Lower information flow overhead. * Suitable for scalability and parallel development. #### Tightly Coupled Architectures: * Every node depends on many others. * Drawbacks: * Difficult to scale. * High coordination effort. * Occasionally necessary for tighter information flow. While tight coupling has its place, it often comes at the cost of scalability and adaptability. ### Organizational Implications: Two-Pizza Teams The concept of **two-pizza teams**, popularized by Amazon’s Jeff Bezos, emphasizes small, self-contained teams: * Teams should be small enough to be fed with two pizzas at lunch. * Smaller teams are easier to coordinate and align with the principles of loose coupling. * Loosely coupled systems allow multiple small teams to collaborate on larger projects without creating bottlenecks.
### Enabling Loose Coupling Achieving loose coupling requires both technical and organizational strategies. Technically, this involves deploying independent software modules as microservices, each running in its own container. These services communicate using well-defined APIs, ensuring clear boundaries and reducing interdependencies.
Container runtimes like Docker facilitate this modular deployment by isolating services and enabling scalability. APIs act as bridges between services, promoting seamless integration while maintaining the independence of individual components. From an organizational perspective, loose coupling necessitates a shift in team structure and culture. Teams must be small, self-contained, and aligned with specific service modules, as exemplified by Amazon's two-pizza team model. Each team focuses on a well-defined area, minimizing cross-team dependencies and fostering efficient parallel development. Despite its advantages, loose coupling introduces challenges such as coordinating multiple services and adapting organizational culture. Additionally, managing distributed systems can complicate monitoring and debugging. However, the benefits of scalability, fault isolation, and flexibility far outweigh these complexities, making loose coupling a cornerstone of modern software architecture.
While loosely coupled systems require cultural, organizational, and technical shifts, their benefits—scalability, adaptability, and robustness—far outweigh the challenges. By adopting these principles, teams can create systems that are easier to develop, maintain, and scale, ensuring long-term success in a complex and dynamic software landscape. ### Conclusion While loosely coupled systems require cultural, organizational, and technical shifts, their benefits—scalability, adaptability, and robustness—far outweigh the challenges. By adopting these principles, teams can create systems that are easier to develop, maintain, and scale, ensuring long-term success in a complex and dynamic software landscape. # Microservices & APIs A famous anecdote in the tech world involves then-CEO Jeff Bezos reportedly mandating that all teams at Amazon expose their data and functionality through **Application Programming Interfaces (APIs)**. According to the story, he insisted that all teams communicate exclusively via service interfaces and design these interfaces to be externalizable to support future ecosystems. While the exact details of this mandate remain unverified, its impact on modern software development is undeniable, emphasizing **modularity**, **scalability**, and **collaboration**.
## APIs: The Backbone of Communication APIs serve as structured interfaces that allow different software components to interact, enabling the seamless exchange of data and functionality. Consider a large online e-commerce platform needing to share **customer data** across multiple teams. Instead of granting direct database access, a dedicated **Customer Data Service** can be built around the customer database, exposing essential data only through APIs.
For example, a web shop front-end might call an API method like **getPurchaseHistory()**, which retrieves a customer’s recent purchases, such as a Lego car, sneakers, and perfume. This ensures that the front-end team can access relevant data without knowing the database’s internal structure.
## Real-World Application in Automotive The API-driven approach extends well beyond e-commerce. In automotive contexts, APIs could facilitate functions like retrieving vehicle data or controlling components. An API such as **getVehicleSpeed()** could return the car's current speed.
Similarly, an API like **openFrontLeftDoor()** could be used to unlock and then open the door. This API must check whether the vehicle is stationary before proceeding, ensuring functional safety.
## API Communication Patterns Understanding API communication patterns is crucial because they define how services interact, ensuring efficient data exchange and system scalability. Two of the most important patterns are Request / Response and Pub / Sub, as will be explained in the following.
### Request-Response The **Request-Response** pattern is the most familiar API communication method. A **service consumer** sends a request to a **service provider**, which processes the request and sends back a response. This synchronous interaction is widely used in traditional web services. ### Publish-Subscribe (PubSub) An even more decoupled approach is the **Publish-Subscribe (PubSub)** pattern. Here, **publishers** broadcast relevant events to specific **topics** or **channels** without knowing who is listening. **Subscribers** interested in these topics automatically receive updates when new events occur. This architecture supports dynamic and scalable interactions. ## Benefits of Microservices and APIs Microservices and APIs enable agility, flexibility, and scalability on both technical and organizational levels. They enhance **resilience** by isolating failures, facilitate **reuse** of components, and streamline **development and maintenance** processes, ultimately reducing costs. When APIs are externalized, they even enable broader **ecosystems**, fostering innovation and collaboration beyond organizational boundaries.
By structuring complex systems into modular services with well-defined APIs, organizations can achieve a level of agility and scalability that would be impossible with monolithic architectures. This approach is foundational in building resilient, future-proof software systems. # Containerization **Containers** are the backbone of cloud computing, transforming how applications are built, deployed, and managed. Running at massive scale, containers power hundreds of millions, if not billions, of internet-based workloads, from web applications and databases to AI training and inference. They are widely adopted across industries leveraging internet technologies. ## How Containers Work Containers function as lightweight, isolated environments that package software and its dependencies. They enable consistent performance across different computing environments. Containers are closely tied to **microservices**, performing specific business functions while exposing APIs for communication. ### Microservices in Containers Microservices reside within containers and are managed by container runtimes. These runtimes handle essential service lifecycle operations, including: * **Deployment and Activation**: Starting new services when needed. * **Service Termination**: Shutting down inactive services. * **Scaling**: Adjusting the number of running service instances based on demand. * **Service Monitoring and Health Checks**: Ensuring availability and performance. * **Fault Tolerance and Recovery**: Automatically restarting failed services. * **Version Management**: Managing different service versions. * **Multi-Tenancy Support**: Running services for multiple clients securely.
### Infrastructure Layering Containers operate on a lightweight infrastructure layer, often running on virtualized operating systems hosted on physical servers. This layered architecture supports scalability and flexibility.
### Containers and Automated Pipelines Additionally, **CI/CD pipelines** automate the entire deployment process, enabling continuous delivery of services into container runtimes.
## Benefits of Containers Containers provide a host of advantages that enhance application development and operations: * **Simplified Deployment**: Packaging applications with all dependencies ensures smooth deployments. * **Improved Resource Utilization**: Containers optimize resource use by running multiple services on the same infrastructure. * **Scalability**: Services can be easily scaled up or down based on demand. * **Isolation**: Containers isolate applications, reducing conflicts and ensuring consistent behavior. * **Faster Deployment and Testing**: Applications can be quickly deployed and tested in containerized environments. * **Compatibility**: Containers ensure compatibility across different platforms. * **DevOps Enablement**: They support DevOps practices by automating deployment and operations tasks. * **Ease of Collaboration**: Developers can work independently and merge updates seamlessly. * **Simplified Maintenance**: Containers simplify updating, patching, and maintaining applications. Containerization has become a foundational technology for modern cloud-based services, offering unparalleled flexibility, efficiency, and scalability in managing complex applications. # Building Robust and Resilient Systems When Netflix began migrating its massive distributed systems to a cloud service provider, they faced the challenge of ensuring reliability at an unprecedented scale. To prepare for inevitable hardware and service failures, Netflix developed **Chaos Monkey**, a tool designed to randomly disrupt services in their production environment. By simulating real-world failures, Chaos Monkey forced Netflix to design for **loose coupling**, enabling individual components to fail without compromising the entire system.
{% embed url="" %} ### Simulating Failures for Resilience In today’s interconnected digital landscape, ensuring **resilience** and **robustness** is essential for maintaining seamless service delivery. With unpredictable hardware failures, network outages, and security breaches being inevitable, systems must be designed to adapt, recover, and continue functioning despite disruptions. Netflix’s proactive approach involved deliberately injecting failures into production or pre-production environments. This strategy ensured that their systems could handle disruptions gracefully and remain operational. Here’s how these simulated failures are introduced: Netflix’s proactive approach involved deliberately injecting failures into production or pre-production environments. This strategy ensured that their systems could handle disruptions gracefully and remain operational. Here’s how these simulated failures are introduced: * **Server Failures**: Simulate server unavailability or non-responsiveness, testing how dependent services handle such disruptions and whether failover mechanisms work as intended. * **Microservice Failures**: Cause service failures by making critical microservices unavailable or limiting API responsiveness to ensure inter-service communication can adapt to partial outages. * **Network Disruptions**: Introduce artificial network latencies, packet loss, or slow connections to test the platform’s tolerance for degraded network conditions. * **Service Degradation**: Intentionally overload services to see how gracefully they handle high traffic or reduced capacity, highlighting potential bottlenecks. * **Regional Failures**: Take entire cloud regions offline to simulate large-scale disruptions, testing the system’s ability to shift workloads and maintain service availability. * **Security Vulnerabilities**: Simulate attacks and data breaches to evaluate how services detect and respond to security threats. * **State Corruption**: Inject invalid or corrupted data into services to test whether they can maintain data integrity and recover gracefully. ### Key Benefits of Failure Injection By embracing controlled failure injection, Netflix achieved several critical advantages: * **Enhanced System Resilience**: The system can withstand unexpected failures and continue functioning. * **Accelerated Recovery**: Faster detection and resolution of issues ensure reduced downtime. * **Increased Engineer Confidence**: Developers and engineers gain trust in their services, knowing they have been tested under real-world failure conditions. Proactive failure simulation has proven to be a revolutionary practice in ensuring that loosely coupled distributed systems remain robust, scalable, and dependable under any circumstances. # Learnings from the Smart Phone Folks After exploring lessons from the internet, we now turn to **smartphones**, the devices that revolutionized personal technology by integrating communication, computing, and connectivity. Smartphones built on the internet’s foundation, enabling seamless access to information, apps, and services anytime, anywhere. With touch interfaces, app ecosystems, and powerful hardware, they set new standards for usability, scalability, and innovation. ## The Smartphone Revolution Think back to devices like the Apple Newton, Palm Treo, BlackBerry, and Nokia Communicator. These were precursors to the modern smartphone era. The true smartphone revolution, however, began in January 2007, when **Steve Jobs announced the iPhone**, transforming how technology and personal devices interacted. Smartphones continue to serve as benchmarks for **Software-Defined Vehicles (SDVs)**. Let’s explore how their key principles apply. ## APIs and Developer Ecosystems Consider a simple but illustrative example from popular culture: a smartphone app that makes a whip sound, as seen in *The Big Bang Theory*. As the app developer, you wouldn’t need to understand the physics behind measuring acceleration. You’d only need access to an **API** that provides acceleration data. Based on that, you’d program the app to trigger a whip sound when the phone moves fast enough.
Smartphone vendors invested heavily in creating **APIs**, **abstraction layers**, and **reusable libraries**, along with marketplaces like app stores. This infrastructure enables developers to build millions of apps, generating billions in revenue. APIs ensure different apps look and behave consistently while allowing third-party developers to build innovative features without needing deep knowledge of the underlying hardware. ## App Stores and Developer Engagement **App stores** provide centralized distribution channels for apps. They ensure: * **Quality Control** through standard reviews. * **Monetization Models** with in-app purchases and subscriptions. * **Developer Engagement** through portals, hackathons, competitions, and early access programs. Smartphone companies continually invest in these ecosystems, enabling faster development and ongoing innovation. ## Hardware Abstraction and Device Compatibility Smartphones use a **hardware abstraction layer (HAL)** to ensure compatibility across devices. This allows apps to run on different devices and future hardware versions. Developers don’t have to rewrite code when new smartphones are released. Instead, the HAL adapts their apps to new hardware, simplifying development and future-proofing applications. ## Sensors and Actuators Modern smartphones are packed with sensors like: * Light and proximity sensors. * Touchscreens and fingerprint readers. * GPS and communication modules. * Accelerometers, gyroscopes, and magnetometers. The default apps use only a fraction of these sensors' potential, leaving the rest to the creativity of developers. This open ecosystem encourages novel applications, from fitness tracking to augmented reality.
## Resource Utilization: Smartphones vs Automotive Systems Smartphones and automotive systems approach resource management with fundamentally different priorities. Smartphones emphasize flexibility and headroom to support third-party applications, enabling continuous innovation. In contrast, automotive systems focus on tightly optimized resource use, ensuring safety-critical operations and reliability. ### Smartphones: Dynamic and Extensible Smartphones are designed with excess capacity, allowing developers to introduce new features and apps. This adaptability supports diverse workloads, frequent updates, and third-party innovation. Resource allocation dynamically scales to user needs, balancing performance and battery life. ### Automotive Systems: Tightly Controlled and Efficient Automotive systems prioritize efficiency and stability, with resources precisely allocated to predefined tasks. This ensures reliable performance for safety-critical functions like braking and steering. The highly optimized nature of embedded systems leaves minimal room for additional functionality or post-production updates. ### Bridging the Gap The shift to software-defined vehicles (SDVs) aims to bring the flexibility of smartphones to automotive systems. By adopting hardware abstraction layers and scalable architectures, SDVs can enable dynamic resource management, fostering innovation while maintaining safety and reliability ## Lessons for the Automotive Industry The smartphone industry offers critical lessons for automotive development: * **User-Centric Design**: Prioritize user experience and personalization. * **Ecosystem Integration**: Build a platform that supports external developers. * **New Revenue Models**: Use app stores, subscriptions, and premium features. * **Software-First Approach**: Focus on software-driven innovation. * **Frequent Updates**: Enable over-the-air (OTA) updates. * **Fast Innovation Cycles**: Encourage rapid iteration and testing. * **Data-Driven Insights**: Use operational data for continuous improvement. * **Developer Community Support**: Invest in engagement and resources. * **Platform Thinking**: Create a flexible, scalable, and secure platform. * **Global Scalability and Interoperability**: Ensure compatibility across diverse environments. * **Cybersecurity**: Implement robust security features from the start. ## Applying Smartphone Principles to SDVs The smartphone model inspires how SDVs can evolve. Non-safety-critical applications could run on a separate software stack above the **hardware abstraction layer**, isolated from critical systems like **ADAS**, **energy management**, and **motion control**. This setup would allow rapid feature development, app store-like distribution, and community-driven innovation.
The **digital-first approach** underpins these principles, emphasizing **shift-north** (moving functionality above the hardware layer) and **shift-left** (enabling early development and testing). This strategy promises a new era of automotive innovation, unlocking possibilities similar to the smartphone revolution. # Part C: Building Blocks In this section, we explore the foundational components that enable Software-Defined Vehicles (SDVs) to transform the automotive industry. At the heart of this transformation lies the intricate interdependency between the Electrical/Electronic (E/E) Architecture and SDV.
E/E Architecture serves as the bridge connecting the mechanical systems of the vehicle, its power distribution network, and connectivity infrastructure with the software layers. It ensures that these traditionally hardware-dominated domains can support the dynamic, real-time demands of modern automotive software systems. Meanwhile, SDVs build on this foundation by introducing software-enabled vehicle experiences, creating a seamless blend of hardware capabilities and advanced digital services. Together, E/E Architecture and SDVs form the backbone of the next generation of connected, intelligent vehicles. In this chapter, we delve into the key building blocks of software-defined vehicles (SDVs), exploring the critical integration of modern E/E architectures, such as domain-centralized and zonal high-performance computing (HPC) systems, with SDV-enabling technologies. These include service-oriented architectures (SOA), container runtimes, vehicle APIs, functional safety measures, over-the-air (OTA) updates, and the transformative potential of vehicle app stores—all built on robust modern tech stacks.
# Foundation: E/E Architecture E/E Architecture stands for Electrical and Electronic Architecture, forming the backbone of modern vehicles by integrating power systems with advanced computing.
The **electrical** components manage the transmission and distribution of power throughout the vehicle. This includes the wiring harness, battery, power distribution units, electrical connectors, and fuses. On the other hand, the **electronics** process information and execute functions through circuits and microcontrollers, ranging from lower-level endpoint ECUs (Electronic Control Units) to high-performance compute ECUs designed to run complex algorithms for AD (Automated Driving), ADAS (Advanced Driver Assistance Systems), sensors, and actuators. ## Key Elements of the E/E Architecture Traditionally, the E/E Architecture is structured hierarchically: 1. **Domain Level**: Encompasses functional areas such as powertrain, chassis, and infotainment. 2. **System Level**: Defines individual systems, for example, engine management and brake control systems. 3. **Component Level**: Contains specific hardware and software components to form the complete system. ### Components Key components of the E/E Architecture include: * **Control Units (ECUs)**: Manage specific vehicle functions. They process data and control various systems. * **Sensors**: Gather real-time data from the vehicle's environment or interior. They provide crucial input for system operations. * **Actuators**: Convert electrical signals into mechanical actions. They execute commands from control units. * **Communication Networks**: They enable seamless communication between components. ### E/E Communication Networks Networks like CAN, LIN, and FlexRay facilitate data exchange and enable seamless communication between components like ECUs, sensors, and actuators. * **CAN (Controller Area Network)**: A widely established, robust protocol for high-speed communication, predominantly used in powertrain and chassis systems. * **LIN (Local Interconnect Network)**: A cost-effective, efficient solution for non-critical applications, commonly used in body electronics. * **FlexRay**: A high-speed, deterministic protocol used in safety-critical systems like drive-by-wire and brake-by-wire. * **Automotive Ethernet**: Adapted from Internet Ethernet technology, automotive Ethernet is increasingly used for high-bandwidth applications in modern vehicles. By tying together these components and communication networks, E/E Architecture enables the seamless interaction of mechanical, electrical, and software systems, laying the foundation for the evolution of Software-Defined Vehicles.
# Today\`s E/E Architectures Currently, in most modern vehicles, Electrical/Electronic (E/E) architectures feature a very large number of highly specialized ECUs and extremely complex wiring harnesses.
For example, compact cars today may contain up to 70 ECUs, while high-end cars can include up to 150 ECUs. Similarly, the wiring harness in high-end cars can span up to 5 kilometers, weighing as much as 30 kilograms. ## Challenges in Today's E/E Architectures The high number of ECUs and the complexity of the wiring harness present several challenges: * **Engineering Complexity**: Managing such intricate systems becomes increasingly difficult, particularly when coordinating multiple stakeholders, teams, and suppliers. * **Testing Difficulties**: The sheer number of components and connections makes comprehensive testing a significant challenge. * **Weight**: The weight of the wiring harness contributes to overall vehicle inefficiency. * **Manufacturing Complexity**: Building and testing vehicles with such elaborate architectures adds layers of difficulty to the production process. * **Maintenance and Repair**: Troubleshooting and fixing issues in these tightly coupled systems becomes progressively more complicated.
## Message Exchange in E/E Architectures Modern vehicles feature dozens of ECUs exchanging thousands of messages, typically via the CAN protocol. For example: * **Engine Control and Diagnostics**: The engine control unit shares engine speed data with the transmission ECU to optimize gear shifting and with the dashboard for display. * **ASIL Examples**: Anti-lock braking systems use data from wheel speed sensors. * **QM Examples**: Climate control sensors collect cabin data and share it with the climate control ECU. In a typical vehicle, there can be between 250 and 2,500 different CAN message types, with 500 to 5,000 messages exchanged per second when the car is operational. ## Tightly Coupled Architectures and Their Drawbacks The CAN bus system creates an inherently tightly coupled system architecture, which introduces several technical limitations: 1. **Direct Message Identification**: Hard-coded message IDs create direct dependencies between senders and receivers. 2. **Fixed Network Topology**: A shared bus structure requires reconfiguration for changes, reinforcing tight coupling. 3. **Dependency on Timing and Bandwidth**: Prioritized message arbitration limits flexibility and creates potential bottlenecks. 4. **Limited Scalability**: Low bandwidth and static design hinder the addition of new ECUs or features. 5. **Lack of Modular Abstraction**: The absence of dynamic addressing or abstraction layers impedes flexibility and future upgrades.
## Organizational Consequences The tight coupling imposed by CAN and similar architectures on a technical level has severe consequences on the organizational level. The increased cost and extended delivery times for new vehicle features or entire vehicle generations result from the additional overhead required to align multiple teams and organizations. These challenges make innovation slower and more expensive, highlighting the need for a shift toward more modular and scalable architectures.
# Evolving Trends in E/E Architectur As automotive OEMs strive to address the challenges of traditional E/E architectures, several transformative trends are emerging to reshape the landscape. These trends aim to simplify complexity, enhance scalability, and future-proof vehicles for the software-defined era.
The first major trend is the **introduction of domain controllers**, which consolidate the functions of multiple specialized ECUs into fewer, more powerful domain-specific units. This approach streamlines vehicle design and reduces the overall complexity of hardware systems. The second trend is **centralized computing**, where high-performance computing units manage diverse software and AI workloads across multiple domains. Centralized compute enables faster, more flexible software updates and supports advanced functionalities such as ADAS and infotainment. Lastly, **zonal architectures** are gaining traction. These architectures organize the E/E system based on the physical layout of the vehicle, significantly reducing wiring complexity. Zone controllers handle the functionality of specific vehicle zones, interlinking with a central compute unit for coordination. This shift introduces hardware abstraction layers, allowing domain-oriented software to operate independently of the physical vehicle layout.
## The Shift North: Decoupling Software from Hardware The concept of the **shift north** marks a transformative approach in E/E architecture evolution, especially in the context of zonal designs with central computing. While traditional **domain-centralized architectures** focus on hardware-level clustering of functions, zonal architectures take a fundamentally different path. They create a **physical layout-based design** to significantly reduce wiring complexity, grouping functionality according to the physical zones of the vehicle. In a zonal setup, **zone controllers** handle a wide variety of functions from multiple domains within their specific physical areas. This approach simplifies the vehicle's hardware by decoupling domain functionality from its physical organization. The **functional clustering**, traditionally tied to hardware, shifts upwards into the software domain. This shift north relies on **hardware abstraction layers (HALs)**, which create a critical buffer between software and hardware. HALs ensure that software components are shielded from the specifics of the physical layout. As a result, developers can work in a **domain-oriented approach**, unaware of the underlying zonal structure. This abstraction fosters **scalability, flexibility, and maintainability**, enabling faster updates and easier integration of new features, independent of hardware constraints.
The shift north is a key enabler for modern software-defined vehicles, unlocking the potential of **zonal architectures** while maintaining the domain-focused design needed for complex vehicle systems. ## Comparing E/E Architectures Different E/E architectures offer distinct advantages and trade-offs. Domain-centralized architectures cluster functionality at the hardware level, while zonal architectures with central compute shift functional clustering to software.
For instance, in a zonal setup, each vehicle zone operates independently with isolated wiring harnesses and a dedicated zone controller. Central compute handles higher-level functions, with high-resolution sensors directly connected to it. This design fosters modularity and loose coupling, laying the foundation for scalability, maintainability, and agility. ## Benefits and Challenges of Modern E/E Architectures Modern E/E architectures offer several advantages while presenting notable challenges. On the benefits side, they reduce costs by minimizing the number of ECUs and simplifying wiring, which lowers manufacturing expenses. Scalability and flexibility improve, making upgrades easier and designs more future-proof. Modular designs enable parallel development, shortening time to market, while central computing supports advanced software features like over-the-air updates. Reliability is enhanced through simplified architectures, which streamline diagnostics and reduce failures. Additionally, standardized interfaces improve collaboration with suppliers and the broader ecosystem. However, challenges persist. Transitioning to these architectures involves high costs, as overhauling legacy systems requires substantial investment. Organizational barriers complicate adapting processes like development, approval, and procurement. Integration risks arise from combining new and legacy technologies, requiring careful coordination. Economic pressures and regulatory demands can delay projects, while established OEMs may hesitate to adopt bold changes, opting instead for incremental adjustments to mitigate risks.
## Adoption Trends in the Automotive Industry The automotive industry is currently witnessing varied adoption patterns across OEMs. **Traditional E/E architectures** dominate today but are gradually declining in favor of **domain-centralized** and **vehicle-centralized architectures**. Domain-centralized systems are already prominent, while vehicle-centralized setups, though less common in 2024, are expected to grow steadily in the coming years. Predictions suggest a significant shift toward these modern architectures as OEMs balance innovation with the costs of legacy system overhauls.
## The Path Forward Evolving E/E architectures represent the foundation for software-defined vehicles, bridging hardware efficiency with software-driven innovation. While the transition poses challenges, the potential for cost savings, enhanced functionality, and faster innovation cycles underscores the importance of embracing these new paradigms. OEMs must carefully navigate the trade-offs to ensure a successful transformation. # Case Study: Rivian Rivian, a California-based EV startup specializing in adventure-oriented electric vehicles, provides an insightful example of innovation in E/E architecture. With strong partnerships, including Amazon and Volkswagen, Rivian has made remarkable progress in reducing the complexity of its vehicle architecture, as shared during their Investor Day 2024.
In their first-generation vehicles, Rivian managed to reduce the number of ECUs to just 17, a stark contrast to the dozens typically used by incumbent OEMs. Currently, Rivian is working on its second-generation vehicles, further streamlining the design to only seven in-house developed ECUs.
This architecture employs a region-oriented zonal design, including east, west, and south zonal controllers, complemented by a few specialized ECUs for key functions such as infotainment, AD and ADAS, vehicle access control, and battery management.
The benefits Rivian reports from their Gen 2 architecture are striking: * A 60% reduction in the number of ECUs compared to their first-generation vehicles. * A 1.6-mile reduction in harness length, significantly reducing vehicle complexity. * A weight reduction of 44 pounds per vehicle. * A 40% cost reduction in the electrical Bill of Materials (BOM). This case study underscores how Rivian and other EV startups are embracing zonal E/E architectures, central computing, and software-defined vehicle principles, achieving tangible benefits in cost, complexity, and efficiency. It highlights the competitive edge startups can gain by adopting cutting-edge approaches to E/E systems. # Standards for Software-Defined Vehicles and E/E Architectures Standards play a crucial role in shaping the development and interoperability of **Software-Defined Vehicles (SDVs)** and **E/E architectures**. In this chapter, we explore three key standards: **AUTOSAR**, **COVESA**, and **SOAFEE**, which have become foundational in modern automotive engineering. In addition, we will be looking at Eclipse SDV as an open source alliance, building on open standards. ## **AUTOSAR: A De Facto Industry Standard** The **AUTOSAR (Automotive Open System Architecture)** standard is a widely adopted architecture that has been implemented by numerous OEMs and suppliers across millions of vehicles. Developed by the **AUTOSAR partnership**, an alliance of OEMs, Tier 1 suppliers, and other industry players, it aims to decouple hardware and software through a standardized layer.
This architecture supports key functionalities such as **adaptive cruise control** and **lane departure warnings**, typically in applications with high **ASIL ratings**. It also provides standardization for communication, diagnostics, and integration with vehicle networks. * **Advantages**: * Strong standardization and interoperability. * Scalability for diverse systems integration. * Proven safety and reliability for critical applications. * **Challenges**: * High complexity and a steep learning curve. * Limited flexibility for rapid innovation. * Potentially higher development costs. Despite its limitations, AUTOSAR remains a cornerstone in ensuring reliable and scalable automotive systems. {% embed url="" %}
## **COVESA: Vehicle Signal Specification (VSS)** **COVESA (Connected Vehicle Systems Alliance)**, formerly known as GENIVI, is an open alliance that promotes interoperability in **connected vehicle solutions**. A key contribution from COVESA is the **Vehicle Signal Specification (VSS)**, a standard for structuring and accessing vehicle data.
COVESA VSS provides a **tree-structured data model** that organizes vehicle domains and their associated sensors and actuators. This standard essentially realizes the **signal-to-service transformation** discussed earlier in **Service-Oriented Architectures (SOA)**. * **Key Features**: * Standardized vehicle signal definitions. * Simplified data access for applications. * Strong alignment with modern SOA principles. The adoption of COVESA VSS ensures seamless data handling and accelerates development for connected and software-defined vehicles. ## **SOAFEE: Scalable Open Architecture for Embedded Edge** The **SOAFEE (Scalable Open Architecture for Embedded Edge)** standard, spearheaded by **ARM** and supported by a wide range of OEMs, Tier 1s, hyperscalers, and other industry players, introduces **cloud-native principles** to the automotive industry.
SOAFEE integrates both **on-board** and **off-board** environments to handle mixed-criticality services efficiently. * **On-Board Architecture**: * Differentiates between **high-compute CPUs** for performance and **high-safety CPUs** for critical functions. * Provides separate **QM** and **ASIL** environments. * Features a **hardware abstraction layer (HAL)** to support both high and low-safety services. * **Off-Board Architecture**: * Executes cloud-based microservices in a mixed-criticality environment. * Ensures seamless interaction with on-board systems via orchestrators. SOAFEE's **mixed-criticality orchestrators** and modular design enable greater flexibility and efficiency in managing SDV services. It bridges the gap between automotive-grade safety requirements and the agility of cloud-native architectures. ## Eclipse SDV: Driving Open-Source Innovation The **Eclipse SDV Working Group**, hosted by the **Eclipse Foundation**, plays a pivotal role in advancing open-source development for **Software-Defined Vehicles (SDVs)**. Its mission is to create an open-source platform supporting tools, frameworks, and runtime environments that align with modern industry standards such as **AUTOSAR**, **COVESA**, and **SOAFEE**. Key contributions from Eclipse SDV include **reference implementations**, **open development models**, and the promotion of **standardized APIs**. This enables faster, collaborative development and ensures interoperability between different SDV components. By embracing an open-source approach, Eclipse SDV accelerates the deployment of cutting-edge automotive technologies while fostering a global developer community focused on the future of mobility. ## Summary: Standards and Alliances Shaping SDVs Together, **AUTOSAR**, **COVESA**, **SOAFEE**, and **Eclipse SDV** address the evolving demands of **Software-Defined Vehicles**, balancing **safety**, **scalability**, and **innovation**. These standards empower OEMs and suppliers to build **interoperable** and **future-ready** vehicle platforms by standardizing hardware-software integration and promoting cloud-native, service-oriented architectures. Complementing these technical standards, the **SDV Alliance** serves as a global initiative fostering industry collaboration. By uniting automotive manufacturers, technology companies, and software developers, the alliance defines **best practices** and **standards** for SDV ecosystems, ensuring a cohesive and innovative approach across the automotive industry. Together, these standards and alliances create a solid foundation for the automotive industry’s **software-driven transformation**, supporting cutting-edge technologies while ensuring **functional safety**, **data-driven intelligence**, and **service-oriented designs** that define the future of mobility. # Building Blocks of an SDV The **building blocks** for an **SDV** include **Service-Oriented Architectures (SOA)**, the **SDV TechStack**, **Over-the-Air (OTA) Updates**, and the **Vehicle App Store**. These components form the core technological framework enabling seamless software integration, real-time updates, and enhanced in-vehicle services. # Service-Oriented Architecture **Service-Oriented Architectures (SOA)** leverage vehicle hardware abstraction layers to enable agile application development. SOA represents a critical evolution in vehicle architecture, enabling seamless integration of hardware and software through modular and scalable services. # The SOA Framework for SDVs The SOA framework for SDVs encompasses both **on-board** and **off-board** environments, integrating **QM** (Quality Management) environments for agile application development and **ASIL** (Automotive Safety Integrity Level) environments for first-time-right safety-critical applications.
Here’s how the SOA Framework for SDVs is structured: **1. Cloud Runtime** At the heart of the off-board system, the **cloud runtime** enables scalable and agile development for microservices. It ensures seamless integration with on-board systems, allowing continuous updates, data processing, and application enhancement in a centralized environment. **2. Vehicle-to-Cloud API** The **vehicle-to-cloud API** acts as a bridge between on-board and off-board environments. It facilitates communication between vehicle systems and cloud platforms, ensuring that data and functionalities flow bidirectionally in a secure and efficient manner. **3. Container Runtime** To execute SDV functions on-board, a **container runtime** is essential. It provides the modular infrastructure needed for running microservices independently, ensuring scalability, fault tolerance, and agility. The container runtime supports parallel development and efficient deployment, allowing for quicker updates and testing. **4. Signal-to-Service APIs** At the core of SOA, **signal-to-service APIs** transform raw signals from sensors, actuators, and ECUs into higher-level services. This abstraction layer simplifies interaction with complex vehicle systems, enabling application developers to focus on creating functionalities without worrying about the underlying hardware complexity. **5. Signal-Oriented Embedded Runtimes** Embedded runtimes leverage signal-oriented designs to optimize real-time performance and ensure smooth operation of on-board systems. These runtimes interact with the signal-to-service APIs and containerized microservices, orchestrating critical processes in SDVs with minimal latency and high reliability. ## **On-Board SOA Building Blocks** * **Endpoint ECUs**: These lower-level control units connect to sensors and actuators through local bus networks. They transmit data to zonal controllers. * **Zonal Controllers**: Higher-end ECUs that host **signal-to-service APIs**, creating a bridge between hardware and software services. * **Microservices**: SOA enables the development of lightweight microservices: * **Basic Microservices**: Simple, standalone services performing specific tasks. * **Composite Microservices**: Higher-order services that combine multiple basic services into more complex functionalities. ## **End-to-End Service Chains** SOA supports the creation of **end-to-end service chains** that span on-board and off-board environments: * In the **cloud**, microservices can access vehicle functions through vehicle-to-cloud APIs, interacting with sensors and actuators at the signal level via signal-to-service APIs. * On-board, these APIs enable agile development for QM functionalities, with future support planned for ASIL A and B functionalities. ## **The Future of SOA** SOA enables seamless communication across the vehicle, cloud, and external ecosystems, driving flexibility, scalability, and safety. As the architecture evolves, signal-to-service APIs will increasingly support safety-critical applications, pushing the boundaries of **software-defined vehicles**. This convergence of on-board and off-board services is central to building robust and future-proof SOA frameworks. # Container Runtimes Container runtimes form the operational backbone of **Software-Defined Vehicles (SDVs)**, extending principles from internet infrastructure into the automotive domain. While containers already power modern cloud services, adapting them for automotive applications comes with unique challenges and requirements. ## Key Requirements for Automotive Container Runtimes Key Requirements for Automotive Container Runtimes include Fast and Deterministic Startup Times, Resource Optimization and Enhanced Security and Efficient Updates: 1. **Fast and Deterministic Startup Times**: In vehicles, startup delays are unacceptable. Imagine unlocking a car and waiting several seconds for critical services like the vehicle experience interface to boot. Automotive-grade container runtimes must ensure near-instant responses, supporting real-time or near-real-time applications even within QM environments. 2. **Resource Optimization**: Onboard compute systems face hardware constraints despite using high-performance processors. Unlike cloud environments, onboard systems cannot scale elastically. Therefore, efficient resource allocation is essential, ensuring that containerized services run smoothly within limited computational resources. 3. **Enhanced Security and Efficient Updates**: Automotive containers require robust security measures, such as isolation between services, secure boot mechanisms, and protection against cyber threats. Efficient update mechanisms must support seamless over-the-air (OTA) updates with minimal downtime. ## Container Runtimes in Automotive E/E Architecture In an automotive **E/E architecture**, container runtimes fit within the broader system structure, enabling flexible and scalable service deployment: * **Central Compute Unit**: This unit hosts multiple instances of operating systems, often using virtualization technologies like hypervisors. * **Virtual OS Instances**: Inside these virtual machines, container runtimes manage microservice deployment. * **Container Runtimes**: Lightweight and modular, these environments host one or more microservices, creating a service-oriented architecture. * **Microservices**: Each microservice runs independently, providing modular vehicle functionalities. Multiple containerized services can run simultaneously, ensuring robust and scalable performance.
By integrating container runtimes, **Software-Defined Vehicles** achieve the scalability, modularity, and reliability needed for modern automotive functions while ensuring seamless interaction with **off-board cloud services**. This combination enables **real-time applications**, **over-the-air updates**, and **enhanced service delivery**, forming the technological backbone of next-generation automotive platforms. # Vehicle APIs **Vehicle APIs** play a central role in modern **Software-Defined Vehicles (SDVs)** by enabling standardized access to vehicle data and functions. They simplify development, enhance interoperability, and support new services, driving innovation within the automotive ecosystem. ## Why Vehicle APIs Matter Vehicle APIs matter because the offer Standardized Data and Function Access, Seamless Developer Integration, and Service Enablement and New Business Models: 1. **Standardized Data and Function Access**: Vehicle APIs allow developers to access essential vehicle data, such as sensor readings (e.g., vehicle speed or battery state of charge) and control actuators (e.g., moving mirrors, opening windows) in a consistent and standardized way. 2. **Seamless Developer Integration**: APIs abstract the complexities of underlying **E/E architectures** and automotive networks, enabling application developers to focus on creating features without requiring in-depth automotive engineering expertise. 3. **Service Enablement and New Business Models**: By facilitating easy access to vehicle functions, APIs unlock opportunities for **on-board** and **off-board services**, enhancing the vehicle experience and enabling ecosystem-driven business models such as personalized apps, remote diagnostics, and connected services. ## Key API Standards in the Automotive Domain There are a number of key API standards emerging in the automotive domain, including: 1. **COVESA VSS (Vehicle Signal Specification)**: A signal-to-service API standard defining how vehicle signals are structured, enabling seamless data access and control through a tree-structured model. 2. **Android Automotive HAL (Hardware Abstraction Layer)**: Developed by Google, this API standard defines hardware abstraction for Android-based infotainment systems, ensuring consistent integration across different automotive hardware platforms. 3. **ISO 23150**: An international standard aimed at standardizing interfaces for **automated driving functions**, ensuring reliable communication between systems in the context of autonomous vehicle development. Vehicle APIs are a key enabler for **connected services**, **software-defined platforms**, and **automotive innovation**, bridging the gap between complex vehicle systems and application developers while supporting scalable and interoperable automotive ecosystems. ## Example: digital.auto VSS Browser The digital.auto VSS Browser is an open source, free to use tool to explore the COVESA VSS API catalogue. For example, in the following we show a part of the API catalogue in its original tree structure.
The VSS browser also allows for navigation of the COVESA VSS tree along the VSS catalogue structure. The following shows the catalogue root:
When selecting a particular VSS signal, the details will be shown as follows:
Use the following link to try it out yourself: {% embed url="" %} # Example: Real-World Application of SDV Concepts So how does all of this play together? How are **container runtimes** and **vehicle APIs** helping us build a **service-oriented architecture (SOA)** for **Software-Defined Vehicles (SDVs)**? In the following, we will be looking at two use cases: An app for a mobile mechanic performing repairs on-site, and a passenger welcome app. Both will share an API to open the vehicle door, i.e. first unlocking the door and then physically opening the door via a motor.
Let’s see how the components interact. We have an **off-board cloud runtime**, an **on-board edge container runtime**, and deeply embedded **signal-oriented environments** in the vehicle. Connecting these elements are two key API layers: the **vehicle-to-cloud API** for external communications and the **on-board hardware abstraction layer (HAL)**, possibly utilizing standards like **COVESA VSS**.
Now, consider a real-world use case involving mobile maintenance or repair services, similar to what Tesla and other EV startups offer. Suppose a service technician needs to access a vehicle for maintenance, even when the owner is not present. Using a mobile app, the technician can send a request to unlock the car remotely. The cloud runtime processes the request through the **vehicle-to-cloud API**, which relays the command to the **on-board container runtime**. The appropriate service is triggered, and the car door unlocks and opens.
Next, consider another use case: a **passenger welcome sequence** designed to enhance the emotional connection between the car and its owner. When the driver approaches the vehicle, the car recognizes the owner through an on-board app. Using stored driver preferences, the vehicle automatically adjusts the seat, triggers a light sequence, and opens the door—all through the same **on-board API**.
What makes this architecture efficient is that both use cases reuse the same **door control API**. In the first scenario, the API is accessed externally by the service technician’s mobile app, while in the second, it’s triggered internally by the on-board application running the welcome sequence. This demonstrates the power of **modularity**, **service reusability**, and **API-driven development** in building scalable and feature-rich SDV platforms. # Ensuring Functional Safety he next big question is: **Is it actually safe to open the vehicle door via an API?** The answer is **no**, unless critical safety measures are in place. In a service-oriented SDV architecture, safety depends on implementing proper checks within the **API for door control**. ## Ensuring Functional Safety To make the door control API safe, several precautions must be built into its implementation: 1. **Check Vehicle Motion Status:** Before initiating the door-opening sequence, the API must verify that the vehicle is completely stationary. Opening the door while the vehicle is moving could lead to hazardous situations. 2. **Rear Camera Verification:** The API must also check the **rear camera feed** to detect approaching vehicles or obstacles in the vehicle’s path. If any danger is detected, the door-opening process must be blocked. 3. **Side Camera Obstacle Detection:** Using the **side camera**, the system must ensure that the vehicle door can open without hitting an obstacle like a wall, post, or another vehicle parked nearby. 4. **Regulatory Compliance:** All these checks must comply with relevant automotive safety standards, such as **ISO 26262** and applicable **UNECE regulations**, ensuring that the door-opening process follows industry best practices. The following diagram shows how this is implemented in our SOA architecture.
## Testing: Ensuring Safety and Resilience Finally, we return to the critical topic of **testing** in the context of **Software-Defined Vehicles (SDVs)**. Recall our earlier discussion about testing loosely coupled systems and the **Simeon Army with Chaos Monkeys**. In the case of the **open-door API** with multiple use cases, testing needs to balance structured, deterministic methods from **ISO 26262** with more chaotic, resilience-focused methods inspired by the **Chaos Monkeys**. ### Structured Testing: ISO 26262 Approach ISO 26262 mandates **highly structured and deterministic testing** aimed at ensuring **functional safety**, **reliability**, and **regulatory compliance**. This approach involves thorough documentation, rigorous reproducibility, and a time-consuming certification process. Essential testing techniques include: * **Fault Injection Testing:** Simulating hardware faults such as sensor failures or intermittent ECU connections. * **Software Fault Injection:** Introducing issues like memory overflows or corrupt data in communication protocols (e.g., CAN bus). * **Power Fault Simulation:** Testing power stability by simulating voltage fluctuations or power interruptions. ### Resilience Testing: Chaos Monkeys Approach To evaluate how the system performs under unexpected conditions, **resilience testing** follows a more chaotic, exploratory path: * **Fault Injection at Scale:** Injecting large-scale, unexpected failures, including network outages or system misconfigurations. * **Boundary Testing:** Pushing the system to its operational limits. For the open-door API, this could mean simulating 10,000 rapid open-close requests per minute. * **Signal Range Testing:** Verifying the system’s response when input values exceed design specifications, such as extreme brake pressure or abnormal steering inputs.
### Comprehensive System Validation Finally, **system validation** ensures that all interconnected components—hardware, software, and external environments—work seamlessly. This includes end-to-end testing of: * **Functional Correctness:** Ensuring the system works as intended under expected conditions. * **Integration Testing:** Confirming that subsystems interact correctly. * **Environmental Simulation:** Testing system responses to external factors like weather, road conditions, and driver behavior. By combining these diverse testing approaches, SDV developers can build robust, safe, and resilient systems that comply with automotive standards while being prepared for real-world challenges. ## Homologation for the Open-Door API Ensuring **functional safety** for every API introduced in a **Software-Defined Vehicle (SDV)** is critical. This requirement ties directly into the process of **homologation**, where APIs must comply with relevant technical regulations before deployment. ### Why Homologation Matters Homologation ensures that the **open-door API** meets **legal** and **safety standards** defined by international and regional authorities. Compliance is mandatory to certify that the vehicle is safe, secure, and road-legal across different markets. ### How It’s Done To achieve homologation for the open-door API, developers can query a **regulatory database** like **Certivity**, which provides detailed technical regulations relevant to vehicle systems. For door-related APIs, several key standards apply, including: * **UNR 11**: Governs door latches and hinges, ensuring mechanical integrity and secure closure. * **UNR 97**: Focuses on vehicle alarm systems, ensuring anti-theft capabilities and safe vehicle access. By referencing these standards, the development team can align the open-door API’s implementation with industry regulations, ensuring that **technical compliance** is met early in the development process. This approach reduces **regulatory risk**, supports **continuous homologation**, and accelerates product certification for global markets. The following shows an example for a prototype combining COVESA VSS in the digital.auto VSS browser with the Certivity RegDB.
## Conclusion By integrating these safety mechanisms into the API, we ensure that the door-opening process becomes secure, compliant, and failsafe. This highlights how **functional safety** in **SDV architectures** is not just a technical feature but a critical system requirement that supports safety, reliability, and regulatory compliance. # Event Chains in Vehicle SOAs ## Event Chains in Vehicle SOA In traditional automotive systems, event chains are typically viewed from an embedded perspective, focusing solely on on-board systems deeply integrated with hardware components. These event chains involve tightly coupled ECUs (Electronic Control Units) that execute functions based on sensor inputs and actuator commands within the vehicle's hardware boundaries. In contrast, Service-Oriented Architectures (SOA) in Software-Defined Vehicles (SDVs) extend the concept of event chains beyond the vehicle, incorporating both on-board and off-board components. This creates an end-to-end event processing framework where microservices in the cloud interact with microservices on the vehicle, enabling features such as remote diagnostics, over-the-air updates, and cloud-enhanced functionalities. These interconnected event chains are critical for enabling dynamic, scalable, and flexible vehicle services. ## System Models in Automotive Microservices So how are events processed by microservices in a vehicle SOA? Automotive microservices can be built using various system models, including: * **Mathematical Models:** These models simulate complex systems and are translated into executable code. * **State Models:** They describe state transitions using structured tools, ideal for handling systems like vehicle doors or power management. * **Handcrafted Code:** Developers write custom code to implement specific features. * **AI Models:** These models perform inference tasks, enabling advanced features such as image recognition and predictive maintenance.
## Event Chains and Call Chains Interactions between microservices in an SOA environment occur through event chains or call chains: * **Event Chains:** Microservices interact asynchronously, triggering events without waiting for responses. * **Call Chains:** Microservices invoke one another synchronously, waiting for responses before proceeding. These chains allow complex functionalities, such as a passenger welcome sequence, to be built by orchestrating several microservices.
## Mapping Models to Execution Environments Microservices in SDVs rely on different execution environments, such as: * **Microcontrollers:** Low-cost, real-time processors used for safety-critical tasks like braking and airbag deployment. * **Microprocessors:** High-performance CPUs used for AI tasks, image processing, and infotainment. * **FPGAs:** Programmable logic arrays for specialized tasks requiring high-speed processing. Each execution environment can have a dedicated, specific operating systems and middleware, such as real-time OS for microcontrollers and Linux-based systems for microprocessors.
## Concrete Implementation Example: Open Door Microservices in vehicle SOA can be implemented using several distinct models, depending on the nature of the required functionality. One straightforward approach is using handcrafted code, where a developer writes custom code to implement the desired service. For example, a microservice could access a vehicle’s internal database, perform computations based on retrieved data, and return results such as processing sensor inputs or managing user preferences. Another implementation model involves AI-powered microservices. In this case, a trained AI model is integrated into a microservice that performs inferences using real-world data. Consider the passenger welcome sequence: the system could employ an AI-based microservice to analyze video data from rear-view cameras, detect incoming bicycles, and identify potential hazards. Mathematical models provide another means of implementation. These models handle complex computations, such as projecting a bicycle's trajectory based on image analysis data. An AI model would first detect and track the bicycle’s movement through a series of video frames. The corresponding mathematical model would then calculate the future trajectory, helping determine whether opening the vehicle door would be safe. State models are particularly useful for managing finite state transitions within the vehicle. For example, a microservice could handle the various states of the vehicle’s door, including locked, unlocked, open, and closed. This state management ensures that logical combinations of door and window positions are consistent and safe during vehicle operation. By combining these models—handcrafted code, AI inferences, mathematical computations, and state management—vehicle SOA systems can support complex functionalities like the passenger welcome sequence. Each implementation type plays a specific role, creating a robust, modular, and scalable system capable of handling sophisticated automotive tasks. ### Embedded Part To understand how the open-door functionality is implemented within the embedded environment, let’s examine an Autosar Classic-based architecture. At its core lies the microcontroller, a hardware component that includes the CPU, memory, and various peripherals essential for running the vehicle’s embedded software. This microcontroller serves as the execution platform for the embedded system.
To ensure the software remains portable and adaptable across different microcontrollers, the Microcontroller Abstraction Layer (MCAL) standardizes the interface between the hardware and the higher-level software layers. This abstraction layer simplifies hardware access by encapsulating low-level hardware details, enabling software portability. The ECU Abstraction Layer sits above the MCAL, providing a unified interface to ECU-specific hardware components like door sensors and actuators. This layer abstracts hardware-specific implementations, making it easier for higher software layers to interact with various components regardless of their unique technical details. Above the ECU Abstraction Layer is the Service Layer, which offers system-wide services such as communication protocols, diagnostics, and memory management. This layer ensures seamless interaction across various ECU functions, independent of the specific hardware involved. Specialized hardware components like LiDAR or battery management systems may require custom drivers known as complex device drivers. These extend the standard Autosar framework by supporting specialized hardware functions beyond what Autosar natively provides. At the top of the software stack are the Runtime Environment and the Application Layer. The Runtime Environment acts as middleware, facilitating communication between user-defined applications and the underlying software components. The Application Layer contains vehicle-specific functionality, such as managing door locks, windows, and mirrors. For the open-door example, a state model in the Application Layer could manage different door states such as locked, unlocked, open, and closed. This model would coordinate interactions with lower software layers, ensuring that door operations comply with defined safety and operational rules. This structured approach, supported by Autosar Classic’s modular architecture, makes managing complex vehicle functionalities both scalable and maintainable. ### End-to-End Perspective To illustrate the end-to-end architecture of a vehicle system, let’s consider a typical use case involving a smartphone-based app triggering the vehicle's door-opening event.
The process begins with the smartphone, where the app runs on a standard operating system and application stack. When the user initiates the door-opening command, the app communicates with a cloud-based microservice, typically hosted in a cloud runtime environment also powered by a standard OS and application stack. From the cloud, the command transitions to the vehicle's on-board system, where a high-performance compute environment awaits. This environment often runs a virtualized operating system capable of hosting containerized microservices. In this setup, microservices execute within a container runtime managed by Kubernetes-like orchestration platforms. The next step involves message processing through a middleware service, such as the KUKSA message broker. This broker facilitates secure and reliable communication between cloud and on-board systems.
Once the command is validated, the vehicle's on-board system performs a series of safety checks before unlocking or opening the door. The safety checks begin by verifying whether the vehicle is stationary, a requirement enforced through integration with the Autosar platform. If the vehicle is not moving, the system activates the rear camera, using AI-powered image recognition to detect any incoming objects or pedestrians that might be at risk during the door-opening process. Next, the side camera scans for obstacles close to the vehicle's sides, ensuring that the door won’t hit anything upon opening. If all checks pass, the system communicates with the responsible ECU via the Autosar-compliant communication layer. The ECU sends the final command to the vehicle’s door actuator, unlocking and opening the door as requested. In advanced architectures, these event chains seamlessly combine cloud-based and on-board operations, leveraging a mix of microcontrollers and microprocessors. For safety-critical tasks, such as emergency braking or actuator control, microcontrollers certified for ASIL D-level functions ensure maximum reliability. Meanwhile, microprocessors handle complex AI-enabled tasks like perception, sensor fusion, and path planning, even though these components often operate under less stringent QM or ASIL A ratings. This architecture underscores the complexity of modern vehicle SOAs, where cloud, edge, and embedded systems must work together, ensuring safety, functionality, and a responsive user experience. # Vehicle SOA Tech Stack The architecture of a modern tech stack for software-defined vehicles (SDVs) builds upon the principles of service-oriented architecture (SOA), carefully dividing the environment into safety-critical and non-safety-critical layers. The attached image illustrates the integration of cloud and on-board environments, categorized into Quality Management (QM), ASIL A/B, and ASIL C/D layers.
## Layers of the Tech Stack for Vehicle SOAs At the top of the stack lies the **cloud environment**, where middleware and applications are executed within a Platform-as-a-Service (PaaS) framework. The underlying layers of the cloud leverage Infrastructure-as-a-Service (IaaS) platforms powered by high-performance CPUs and GPUs. This configuration enables scalable computation and centralized management of services that interact with the vehicle's on-board systems. Transitioning to the on-board **QM environment**, we see the use of container runtimes for efficient execution of microservices. These run within virtual operating system instances managed by hypervisors, which typically utilize general-purpose OSs such as Linux. This layer relies on high-performance compute environments powered by CPUs and GPUs, ensuring the rapid execution of non-critical vehicle functions and enhanced vehicle experiences. For the **ASIL A and B environments**, the stack incorporates specialized platforms such as Autosar Adaptive or the Robot Operating System (ROS). These operate on generic microprocessors to support safety-critical functionalities while maintaining sufficient flexibility for dynamic service orchestration. The **ASIL C and D environments** delve deeper into real-time operations, where the tech stack includes high-end ECUs running real-time operating systems on generic microprocessors for zone controllers. At the endpoints, the stack employs low-end ECUs powered by microcontrollers. These typically run Autosar Classic or similar micro-OS platforms, ensuring the safe and reliable execution of highly critical tasks like braking and engine control. This layered and modular approach to the SDV tech stack highlights how safety-critical and non-critical environments can coexist. Each layer is optimized for its specific role, from supporting scalable cloud-based computation to enabling real-time, safety-critical operations on embedded systems. This separation ensures scalability, functional safety, and the agility needed for software-defined vehicle ecosystems. ## Application Perspective on the SDV Tech Stack To better understand the modern SDV tech stack, let’s revisit it from the perspective of applications. Previously, we introduced two distinct applications: one for a mobile mechanic and another for an on-board passenger welcome sequence. These applications demonstrate how the tech stack enables seamless integration between various components and ensures safety and functionality.
The **first application**, designed for a mobile mechanic, runs on a smartphone. This app allows the mechanic to open the vehicle door remotely, making use of the **vehicle-to-cloud API** to communicate with the car. The app sends a command to the cloud, where it interacts with a microservice implementing the **door open API**. This microservice, running in the cloud runtime, processes the request and transmits it to the vehicle's on-board system via the **vehicle-to-cloud API**. The **second application**, the passenger welcome sequence, operates directly on the vehicle within the **QM container runtime environment**. This app is responsible for creating an engaging user experience by adjusting settings, such as seat position, and opening the door when the owner approaches the car. Like the mobile mechanic app, it leverages the **door open API** to perform its functions. In both scenarios, the **door open API** acts as a central interface, abstracting the complexities of interacting with the vehicle’s hardware. The implementation of this API involves a multi-step process to ensure functional safety. When a request is made to open the door, the API must first pass through the **signal-to-service API**, which connects it to the embedded environment. In the embedded environment, safety checks are conducted in the following sequence: 1. **Vehicle Speed Check**: Ensures the car is stationary before proceeding. 2. **Rear Traffic Monitoring**: Uses the rear camera and AI to detect any approaching vehicles. 3. **Side Clearance Check**: Verifies that no obstacles or pedestrians are near the door using side cameras. 4. **Execution at the ECU Level**: After all safety checks are validated, the signal-to-service API communicates with the embedded ECU to physically unlock and open the door. This layered approach showcases how the SDV tech stack supports end-to-end functionality, ensuring safety-critical computations are performed within appropriate environments while exposing reusable APIs for application development. The ability to reuse the **door open API** across both on-board and off-board applications highlights the modularity, scalability, and interoperability that a service-oriented architecture brings to software-defined vehicles. ## Case Study: Rivian's Modular Architecture and Strategic Vision To conclude, let’s revisit Rivian’s innovative approach to vehicle architecture and its broader implications. Rivian's vision revolves around modularity, where different versions of electrical hardware are abstracted through a hardware adaptation layer. This approach allows Rivian to build flexible, generic software layers on top, which can be tailored for specific vehicle variants. This modular architecture is crucial not only for Rivian’s ability to scale across its product portfolio but also for its strategic collaboration with Volkswagen. In the context of the Rivian-Volkswagen joint venture, this architecture provides an opportunity for Volkswagen to leverage Rivian’s core platform while introducing distinct digital features tailored to its own brand and market requirements. For instance, Volkswagen could reuse Rivian's higher-level architecture for vehicle operations but customize it with proprietary digital experiences, enhancing its competitive differentiation in areas such as infotainment, user interaction, or advanced driver assistance systems. This partnership highlights the transformative potential of scalable and flexible architectures in the automotive industry. By abstracting hardware complexities and focusing on software differentiation, Rivian’s approach sets a benchmark for the efficient and collaborative development of next-generation, software-defined vehicles.
# Over-the-Air Updates: The Backbone of Software-Defined Vehicles Over-the-air (OTA) updates are a cornerstone of software-defined vehicles (SDVs), enabling dynamic enhancements, fixes, and improvements without the need for physical intervention. OTA updates today can deliver various digital artifacts, including software updates, AI model improvements, configuration and media data, as well as operating system or firmware updates. Each update must go through rigorous testing, integration, validation, and regulatory approval before distribution.
The distribution process is typically managed through an app store or similar platform, incorporating campaign management to ensure compatibility with different vehicle variants and environmental factors. Once an update is ready, it reaches the vehicle via either a push mechanism or a pull initiated by the driver or vehicle owner. Onboard, an update agent handles the process, performing security and safety checks, identifying the target environment (e.g., a specific ECU or container), and applying the update through installation, configuration, and validation. ## Limitations Traditional vehicle architectures with dozens or even hundreds of ECUs, often connected via low-level networks like CAN or LIN, present significant challenges. These networks lack the capacity to support comprehensive OTA updates, leaving many ECUs isolated from the update process.
As a result, in such legacy architectures, updates for certain ECUs may still require manual recalls. This limitation underscores the importance of modern central compute and zonal architectures, which are designed to fully support OTA capabilities and unleash the potential of software-defined vehicles. ## The Future of OTA The limitations of legacy vehicles mean that OTA update campaigns often focus primarily on resolving quality-related issues rather than optimizing existing features or introducing entirely new functionalities. However, the future of OTA lies in enabling greater individualization and personalization of vehicles throughout their lifecycle.
This shift will support not only bug fixes but also the continuous release of new features, enhancements, and innovative functionalities. Managing the growing complexity of software and hardware combinations will be key, ensuring seamless integration and maintaining the high reliability expected in the automotive industry. This vision of continuously evolving software-defined vehicles aligns with the broader trends of digital transformation across mobility. ## Case Study: OTA at Rivian Rivian provides a compelling example of the potential of OTA in software-defined vehicles. During their investor day, Rivian reported that over the past two and a half years, they had successfully introduced approximately 500 new features through more than 30 OTA campaigns. This achievement highlights the transformative power of OTA in delivering ongoing value to customers. Impressively, 96% of Rivian's customers installed these updates within two weeks of release, showcasing high customer engagement and trust in the OTA process. Rivian’s example underscores the importance of robust OTA systems in creating vehicles that evolve dynamically with software, staying at the forefront of innovation and user experience. # Vehicle App Store: The Holy Grail of Software-Defined Vehicles The concept of a **Vehicle App Store** represents a transformative leap for software-defined vehicles, integrating cloud, smartphone, and on-board services to enable rich, dynamic applications. At its core, this ecosystem requires several foundational elements. ### Foundational Elements of the Vehicle AppStore First, a secure on-board app execution environment is essential, utilizing container technology to create isolated sandboxes where apps can operate safely. This environment ensures that apps have controlled API access, organized into trust levels. For example, apps developed by the OEM (Original Equipment Manufacturer) would have higher trust levels, enabling access to a broader range of APIs, while partner or third-party apps might have more restricted permissions.
The Vehicle App Store itself plays a crucial role, providing a platform for distributing apps to vehicles via over-the-air (OTA) updates, supported by robust cloud connectivity. This seamless connection between the on-board environment and the cloud enables ongoing updates and the integration of new services. ### Example: A Mechanic's Smartphone App to Open a Vehicle Door To understand how this system works in practice, let’s revisit a concrete example: a mechanic using a smartphone app to open a customer’s vehicle door. The app, designed for the smartphone, is downloaded from the app store of the smartphone's provider (e.g., Apple, Google). For this app to function, the OEM must first submit it to the smartphone company’s app store. Additionally, the OEM must ensure that supporting microservices are distributed across the necessary environments. Here’s how it unfolds: 1. **App Deployment:** The OEM provides the app to the smartphone company’s app store. Simultaneously, the required software components and microservices are deployed to vehicles via OTA updates. These microservices act as the on-board counterparts to the smartphone app. 2. **Backend Services:** The OEM also sets up backend cloud services to support both the on-board and smartphone applications. 3. **Action Execution:** The mechanic presses a button in the smartphone app, triggering a call to a remote API. This API request is processed by a microservice in the cloud, which then calls a remote API exposed by a microservice running on-board the customer’s vehicle. 4. **On-Board Operations:** The on-board microservice communicates with the vehicle API to execute the requested action, such as opening the door. This involves performing all necessary safety checks (e.g., ensuring the vehicle is stationary, checking surrounding traffic, and confirming no obstructions). 5. **Cross-System Collaboration:** For this process to work seamlessly, all three components—the smartphone app, the cloud microservice, and the on-board microservice—must be fully functional and integrated. Additionally, the vehicle must have the necessary API (in this case, the open door API) implemented. The following diagram shows the flow of app components through the system:
The following diagram shows how the distributed app components are interacting after having been installed in the different runtime environments:
## Complexities and Cross-System Coordination The Vehicle App Store paradigm highlights the complexities of creating Vehicle SOAs as a distributed system. OEMs must coordinate across multiple domains, including on-board systems, cloud services, and third-party platforms like smartphone app stores. Each element must work together flawlessly, requiring extensive cross-checks and validations to ensure compatibility and functionality. Despite these challenges, the Vehicle App Store is considered the "holy grail" of software-defined vehicles. By enabling the seamless integration of applications that combine smartphone, cloud, and on-board services, it promises to revolutionize the vehicle experience, delivering rich, innovative features to customers and establishing a dynamic ecosystem for the future of mobility. # Summary: Building Blocks for Software-Defined Vehicles In Part C of **SDV 101: Building Blocks**, we explored the foundational elements enabling modern software-defined vehicles (SDVs). At the core of SDVs lies the evolution of **E/E architectures**, which transition from legacy designs into either **domain-centralized architectures** or cutting-edge **zonal architectures** with **high-performance compute (HPC)** capabilities. These advancements provide the structural backbone for SDVs.
Building on E/E architectures, SDVs implement **service-oriented architectures (SOAs)** that leverage **container runtimes** and **vehicle APIs** to ensure modularity, scalability, and integration with external ecosystems. Critical to this framework is the focus on **functional safety**, especially when operating in mixed-criticality environments, supported by **modern tech stacks** and industry standards such as **AUTOSAR**, **COVESA VSS**, and **SOAFEE**. We also examined **over-the-air (OTA) updates**, a critical enabler for dynamic updates of software, AI models, and other digital artifacts, paving the way for continuous innovation. Finally, we looked at the concept of the **Vehicle App Store**, a transformative vision integrating secure environments, controlled API access, and cross-platform services to deliver new digital experiences to automotive customers. Together, these building blocks represent the future of automotive innovation, where modular architectures, advanced software integration, and seamless updates redefine the vehicle experience. # Part D: Implementation Strategies In this section of SDV101, we explore key strategies for implementing Software-Defined Vehicles (SDVs). We begin with the #digitalfirst approach, emphasizing the shift toward software-centric development. Next, we examine the interplay between hardware and software engineering, highlighting integration challenges and opportunities. The chapter on implementing the Shift Left details how early validation, simulation, virtualization and continuous testing can accelerate development. A strategic perspective follows, addressing big picture strategy topics. Finally, we cover essential enterprise topics like Homologation, Variant Management, and Engineering Intelligence.
# #DigitalFirst ## From Building Blocks to Value Streams In the previous part, we introduced the concept of loose coupling using the bento box analogy to highlight the importance of modularity and independence in system architectures. The compartments in the bento box represented how we are using modularization and system layering to form a cohesive system—a key principle for modern, software-defined vehicles.
Now, as we transition into the implementation strategy, we shift our focus from system architecture to value streams, represented by processes and organizations. This is where the restaurant analogy comes into play. Unlike the static compartments of a bento box, a restaurant operates as a dynamic process, combining raw ingredients into customized dishes on demand. This perspective mirrors how organizations and teams need to collaborate in flexible and efficient ways to deliver continuous value in a rapidly evolving environment. The bento box and restaurant analogies go hand in hand: while the bento box demonstrates how to design decoupled architectures, the restaurant highlights the processes and organizational structures required to execute them effectively. Together, they form the foundation for enabling the shift north in architectures and the shift left in development processes, which are critical to building agile, software-defined vehicles. In a software-defined vehicle (SDV) development organization, value streams operate at multiple speeds to address diverse needs effectively. As depicted in the image below, there are two distinct but complementary streams: 1. **Agile Value Stream**: This stream focuses on fast, continuous improvements for features that require frequent updates and lower safety requirements. Agile processes here emphasize delivering minimal viable products, iterating rapidly, and introducing enhancements north of the hardware abstraction layer. These developments are ideal for areas without hard real-time constraints, allowing for flexibility and experimentation. 2. **Safe Value Stream**: This stream emphasizes a "first time right" approach for systems with high safety or hard real-time requirements. Here, the focus is on long-term planning, stability, and a fully hardened environment, as these developments often involve components south of the hardware abstraction layer. This stream supports high ASIL-rated systems, ensuring reliability and compliance with rigorous safety standards. Together, these value streams enable a multi-speed organization to balance agility and safety, ensuring efficient development of both exploratory digital features and mission-critical systems in SDVs.
## Two Key Shifts for SDVs: Shift-Left and Shift-North The #digitalfirst approach builds on two foundational strategies for achieving efficiency and agility in software-defined vehicle (SDV) development: **shift north** and **shift left**, as illustrated in the diagram. Traditionally, the term "shift north" refers to moving functionality upward in the architectural stack, north of the Vehicle Hardware Abstraction Layer (VHAL). However, in this context, "shift north" is also about **organizational decoupling**. By separating fast, agile value streams from the slower, safety-critical processes, organizations can enable multi-speed development. Agile streams focus on continuous improvement, while safety-critical streams emphasize stability and reliability, both coexisting yet independently evolving above and below the VHAL. "Shift left," on the other hand, emphasizes **early testing and validation in digital environments**, significantly reducing dependencies on physical prototypes and test setups. By simulating and validating designs earlier in the development process, organizations can avoid costly delays and streamline time-to-market.
Together, these shifts enable a digital-first mindset, where decoupled processes and early testing empower teams to move faster and innovate while maintaining quality and safety. ## Shift North The concept of **Shift North** involves moving functionality from hardware-centric, deeply embedded, safety-critical ASIL environments into more agile, software-oriented QM environments.
As shown in the diagram, ASIL environments rely on structured approaches like the V-Model, real-time systems, and model-based systems engineering (MBSE) to meet strict safety requirements. By shifting north, non-safety-critical components are decoupled and transitioned into QM environments, enabling agile methodologies, faster updates, cloud integration, and the development of minimum viable products (MVPs). This shift is supported by the Vehicle Hardware Abstraction Layer (VHAL), which ensures modularity while facilitating rapid innovation above the hardware layer. The concept of "shift north" in software-defined vehicles encompasses three distinct levels: E/E architecture, software environments, and the integration of on-board and off-board systems.
Each type of shift north addresses unique challenges, enabling a more centralized, agile, and efficient vehicle system architecture. ### **Shift North on the E/E Level** At the electrical and electronic (E/E) architecture level, the shift north involves transitioning responsibilities from distributed, specialized ECUs and peripheral sensors or actuators to a central compute architecture. This reduces the reliance on numerous, less powerful devices and instead leverages a more centralized, high-performance compute system. By consolidating processing power, this approach enhances scalability, simplifies the architecture, and enables more advanced processing capabilities within a centralized framework. ### **Shift North on the Software Level** On the software side, the shift north entails moving functionalities from safety-critical ASIL environments into the more agile QM environments. By decoupling event chains and isolating non-safety-critical components, these functionalities can be handled in higher-level compute environments. This decoupling enables faster iteration, continuous improvement, and more dynamic updates for non-ASIL components. Hardware abstraction layers (such as the VHAL) play a crucial role in facilitating this shift, ensuring that software components can operate independently of the underlying hardware constraints. ### **Shift North from On-board to Off-board** In some cases, the shift north goes beyond onboard systems to include off-board processing in the cloud. By moving certain functionalities or computations off-board, the architecture can take advantage of cloud resources for scalability, faster updates, and advanced analytics. This approach supports a hybrid model where onboard systems manage real-time and safety-critical functions, while the cloud handles more complex, non-critical tasks such as AI inference, large-scale data processing, or feature updates. Together, these three levels of shift north—E/E architecture, software, and on-board to off-board—create a more modular, flexible, and agile system architecture, enabling faster innovation and better alignment with the needs of software-defined vehicles. ## Shift Left The "shift left" approach emphasizes the importance of addressing quality early in the development process, as illustrated in the diagram. Traditional quality models, represented by the red curve, focus heavily on identifying and correcting errors during the later stages of deployment and operation, which is both time-consuming and expensive—up to 640 times more costly, according to NIST data.
In contrast, the shift-left model prioritizes integrating quality assurance into the earlier stages of planning, design, and building. This proactive strategy reduces risks, accelerates delivery timelines, and significantly lowers the cost of error correction by ensuring issues are addressed long before they escalate in complexity. ### **User Experience Validation: Early-Stage Prototyping** Shift left begins with validating user experience as early as possible. Instead of waiting for physical prototypes, which take months or even years, early-stage prototyping uses tools like rapid cloud-based simulations, virtual reality, and digital twins to test UX concepts. This allows teams to identify usability issues and refine the vehicle experience in a virtual environment, ensuring customer-centric designs are validated long before physical development begins. ### **System Validation: Simulation and Virtualization** Simulation and virtualization play a crucial role in enabling system validation earlier in the development process. By creating highly detailed digital models of components and systems, engineers can replicate real-world scenarios without relying on physical prototypes. This approach accelerates testing cycles, supports parallel development, and ensures that functional requirements are met while reducing both time and costs traditionally associated with hardware-based validation. ### **Continuous Integration: Automation from Day 1** Continuous Integration (CI) brings automation into the development pipeline right from the start. By implementing CI practices, developers can frequently integrate code changes into a shared repository, triggering automated builds and tests immediately. This early feedback loop helps detect and address errors quickly, preventing costly late-stage fixes while fostering collaboration across teams. With CI in place, software quality improves steadily throughout the project lifecycle. ### **Continuous Homologation: Virtual Testing** Shift left in the context of regulatory compliance is supported by continuous homologation through virtual testing. By leveraging simulation environments and virtualized tools, regulatory checks can be performed much earlier in the process. This reduces reliance on physical test vehicles and enables faster iterations to ensure safety, compliance, and reliability. Continuous homologation ensures that new features and updates are validated efficiently, paving the way for rapid deployment while maintaining strict standards. ## Conclusion In conclusion, the *#digitalfirst* approach combines architectural and organizational shifts—*Shift North* and *Shift Left*—to transform the way software-defined vehicles are developed. By decoupling systems, leveraging early-stage validation through simulation and virtualization, and embracing continuous integration and homologation, organizations can achieve faster, more efficient, and cost-effective development cycles. This strategy enables multi-speed value streams, balancing agile innovation with the rigorous safety and reliability demands of automotive systems. Together, these principles lay the foundation for a digital-first mindset, ensuring that SDV development is not only accelerated but also future-ready.
# Hardware vs Software Engineering In the world of software-defined vehicles (SDVs), the convergence of hardware and software engineering presents unique challenges and opportunities. Traditional hardware development has long been guided by the **V-Model**, a proven approach for managing the design, integration, and validation of mechanical and electrical/electronic (E/E) systems. However, as the automotive industry shifts towards more software-centric architectures, the need for agility and multi-speed development becomes essential.
While hardware workstreams often require long-term planning and stability, **software engineering** demands continuous iteration and rapid updates. This multi-speed approach requires **decoupling** hardware, E/E, and software development processes through clear technical interfaces like VHAL and organizational alignment. To fully realize this decoupling, **automated CI/CD pipelines** must be introduced and mapped effectively onto the V-Model, enabling seamless integration and validation across digital, E/E, and mechanical workstreams. In this chapter, we explore how hardware and software engineering principles interact, the role of the V-Model in managing these complexities, and the ways CI/CD automation and agile methods can harmonize the different speeds of development. # The Traditional V-Model in Automotive Development The V-Model has long been the standard framework for automotive development, guiding the design, verification, and validation of vehicle systems. It emphasizes a sequential yet interconnected process, where each design phase is complemented by a corresponding testing and validation phase.
The diagram above illustrates an extended version of the V-Model, which integrates not only software development but also electrical/electronic (E/E) systems and mechanical system development, creating a unified view of modern automotive engineering. On the left side of the V, we see the design phases: 1. **Strategy, ideation, and concept**: This is where the initial vision, strategy, and high-level requirements for the vehicle or system are defined. 2. **Overall system design**: The system architecture is created, detailing the functional and technical specifications. 3. **Vehicle properties and features**: Key vehicle features, such as performance, safety, and comfort, are defined. 4. **Sub-system design**: Specific subsystems, such as powertrain, braking, or infotainment systems, are developed with their hardware and software components. Between the left-hand phases and the right-hand phases is **Verification and Validation**, connecting design to integration and testing phases on the right side of the V. The right-hand phases include: 1. **Sub-system integration and testing**: Subsystems are combined and tested for functionality, performance, and compatibility. 2. **Vehicle functional integration and testing**: Integration of all vehicle systems to ensure they work together as intended. 3. **Overall product integration and testing**: Complete system validation, ensuring the final product meets all regulatory and performance requirements. 4. **Production (SOP)**: Standard Operating Procedure (SOP) marks the start of production. 5. **Usage and service**: Post-production support, including maintenance and updates, ensures a successful lifecycle. Additionally, the diagram highlights **homologation** for regulatory compliance and **multi-supplier deliveries**, reflecting the collaborative nature of automotive development. Supply chain and manufacturing planning are integrated early, ensuring alignment between design, testing, and production. ## Model-Based Systems Engineering (MBSE) Model-Based Systems Engineering (MBSE) is a key supporting methodology within the V-Model. It replaces traditional document-driven development with model-driven processes, using system models to capture requirements, design, and verification details. In MBSE, a central model serves as a “single source of truth,” enabling better collaboration across teams, tools, and domains. This approach enhances traceability, reduces errors, and ensures consistency, particularly when dealing with the complexity of E/E systems and software-defined vehicles. By employing MBSE, engineers can simulate, validate, and optimize designs early in the development process, supporting the "Shift Left" concept and reducing late-stage changes, which are costly and time-consuming. ## Automotive SPICE (A-SPICE) Automotive SPICE (A-SPICE) is a process assessment model widely used in the automotive industry to evaluate and improve software and system development processes. It provides a structured framework for managing quality and ensuring compliance with stringent automotive standards. A-SPICE defines processes across the full development lifecycle, including requirements management, design, integration, and testing, making it an essential component of the V-Model. OEMs and suppliers use A-SPICE to ensure their development processes meet high maturity and reliability levels, which are critical for delivering safety-critical systems like autonomous driving and ADAS (Advanced Driver Assistance Systems). ## Pros and Cons of the V-Model The V-Model offers several advantages: * **Clear structure and traceability**: Each design phase has a corresponding test phase, ensuring alignment and early issue detection. * **Strong focus on validation**: The emphasis on verification and validation helps meet quality and regulatory requirements. * **Systematic approach**: It supports complex, multi-domain development across software, E/E, and mechanical systems. However, the V-Model also has its limitations: * **Rigidity**: Its sequential nature makes it less adaptable to changes, particularly in agile and iterative development environments. * **Late integration risks**: Issues may only become visible during integration and testing phases, increasing costs for late-stage fixes. * **Limited support for continuous improvement**: The V-Model’s structure does not inherently support iterative and agile processes, which are becoming more important in the era of software-defined vehicles. * **Limited support for Multi-Speed Development:** The V-Model’s structure also does not foresee that different value streams are delivering results at different speeds. To address these challenges, the V-Model is often combined with modern practices like MBSE, A-SPICE, and continuous integration to create a more flexible, digital-first development approach. # Agile V-Model, anybody? In the era of software-defined vehicles, OEMs are aiming to decouple mechanical, electrical/electronic (E/E), and digital (software and AI) workstreams to enable **multi-speed development**. As shown in the diagram, this decoupling ensures that each stream operates at its own optimal pace. The **digital workstreams** must support rapid iteration cycles, often measured in hours or days, enabling frequent updates, feature improvements, and testing. In contrast, **E/E workstreams** require a medium-term focus, typically spanning weeks, to ensure robust system integration and validation. Finally, the **mechanical workstreams** follow a long-term development cadence measured in months, driven by extensive physical testing, safety requirements, and production timelines.
To achieve this multi-speed approach, OEMs must establish **clearly defined technical and organizational interfaces**. On the technical side, key enablers include **loose coupling** between the layers of development, supported by **hardware abstraction layers (HAL)** and **vehicle hardware abstraction layers (VHAL)**. This abstraction allows software and digital innovation to advance independently of hardware constraints. The concept of **"Shift North"** further supports this, enabling non-safety-critical software functions to reside in higher-level compute environments where rapid changes can occur without impacting lower-level systems. Organizationally, this decoupling requires well-defined workflows, tools, and responsibilities across teams. By creating interfaces that align development priorities and testing processes, OEMs ensure seamless collaboration while maintaining the integrity of long-term physical systems and fast-moving digital innovation. Additionally, this approach aligns with the **Shift Left** strategy, which emphasizes early-stage digital validation through simulation, virtualization, and continuous testing. This minimizes costly late-stage errors and ensures that the digital, E/E, and mechanical streams can efficiently converge during system integration, verification, and production. Ultimately, this multi-speed, decoupled development approach provides OEMs with the agility to innovate quickly in the digital space while maintaining the reliability and safety of the physical vehicle systems. # Key: Loosely Coupled, Automated Development Pipelines In this section, we revisit the **lessons learned from the internet era**, emphasizing the need for **fully automated CI/CD pipelines** to support the rapid development and deployment of digital vehicle features. Continuous Integration and Continuous Deployment (CI/CD) pipelines are essential for maintaining agility in the fast-paced digital development space while ensuring consistency, quality, and efficiency. ## Mapping CI/CD Pipelines to the V-Model As shown in the diagram below, CI/CD pipelines can be **directly mapped to the V-Model**, where automation acts as a driving force for efficient iteration. While mechanical and E/E assets follow their structured, long-term development cadence, **digital assets**—including AI models, SDV software (QM), and embedded ASIL code—require a highly automated approach to enable faster cycles of build, integration, and validation.
Automation is key to accelerating development and reducing manual overhead, particularly for **on-board and off-board assets**. AI models, software-defined vehicle code, and embedded systems benefit significantly from automated pipelines that can validate changes across virtualized environments, simulate real-world scenarios, and ensure compliance with safety and quality standards. By integrating fully automated CI/CD pipelines into the development process, organizations enable continuous testing, rapid prototyping, and frequent feature updates. This not only aligns with the **multi-speed development** approach but also ensures that digital vehicle features can evolve seamlessly in parallel with E/E and mechanical workstreams. Ultimately, automation of CI/CD pipelines ensures that **fast-moving digital innovation** can scale effectively while maintaining synchronization with the broader system development lifecycle. This is critical for achieving the agility and reliability required in modern software-defined vehicles. ## Integrated Pipelines Across the Right Side of the V-Model In the DevOps community, the importance of **automated integration** across different development pipelines is widely recognized. This automation enables the creation of new pipelines capable of integrating results from multiple sources, ensuring consistent quality and accelerating development cycles.
In the context of the V-Model, this principle becomes even more critical when applied to the **right side of the V-Model**, where integration and validation occur. Here, the focus shifts from isolated workstreams—**mechanical assets, E/E assets, and digital assets**—to their seamless integration. The goal is to manage these diverse outputs as **combined digital artifacts**, enabling end-to-end system verification and validation. Automation plays a crucial role in orchestrating this complexity. Integration pipelines must handle artifacts generated at various levels—mechanical designs, E/E components, and digital software (including AI models and embedded code). By continuously merging and testing these artifacts, organizations can detect inconsistencies early, ensuring alignment across all layers of the development process. This approach also allows for **cross-domain synchronization**. For instance, mechanical systems may progress through slower, long-term validation cycles, while digital artifacts iterate at higher speeds. Automated pipelines ensure that outputs from both streams are periodically integrated, enabling functional validation at the **subsystem** and **vehicle level** without manual overhead. Ultimately, applying DevOps principles to the right side of the V-Model unlocks the potential for efficient, cross-stream validation and **continuous integration** of the entire vehicle system. This harmonization of workflows ensures that mechanical, E/E, and digital domains deliver a **cohesive, fully verified product**—ready for production and real-world deployment. ## Bringing it all Together Finally, we need to bring together the principles of **multi-speed development** and **integrated testing** within the V-Model, highlighting how digital, E/E (Electrical/Electronic), and mechanical workstreams are coordinated. At the core, **digital assets**, **E/E assets**, and **mechanical assets** flow in parallel through the development stages, each contributing to the overall integration.
The **feedback loops** illustrate the agility of digital workstreams, enabling iterations within hours, weeks, or months. This flexibility contrasts with the slower, long-term cycles of mechanical and E/E components, which require greater planning and stability. To overcome the challenge of synchronization, the diagram emphasizes the use of **digital mockups and simulations** to test against physical components when they lag behind, ensuring no delays in integration. The key message is that **de-coupling** and aligning workstreams through **automation**, virtual validation, and robust interfaces enable continuous integration, even across complex systems. By combining rapid digital iterations with stable physical processes, OEMs can achieve efficient, end-to-end vehicle development. # The SDV Software Factory {% hint style="info" %} By Achim Nonnenmacher, ETAS {% endhint %} The challenges faced by OEMs in recent years have underscored a critical need for a systematic approach to software development: the **SDV Software Factory**. Headlines such as software-related delays in vehicle production, unsatisfied customers, or recalls due to software quality issues are becoming all too common. These issues highlight three fundamental goals: **increasing software quality**, **boosting productivity**, and **meeting deadlines**. At its core, the SDV Software Factory is about applying a **systematic, industrialized approach** to software development, inspired by principles from the manufacturing world. The term itself dates back to the Japanese IT and telecommunications industry of the 1970s, which aimed to increase software quality and efficiency. Drawing parallels with the Toyota Production System, the software factory optimizes design through standardization, streamlines processes, focuses on continuous improvement, and fosters a culture that empowers employees to adopt new ways of working.
The SDV Software Factory achieves these goals through three key pillars: **design optimization**, **process automation**, and **continuous improvement**. Much like modular hardware components, software today is designed in **standardized, isolated containers** for efficient reuse and mass production. Continuous improvement, exemplified through CI/CD pipelines, enables teams to iteratively refine and deliver software faster, while automation eliminates manual inefficiencies, reducing waste ("muda") and accelerating development cycles. ## Key Elements of the Software Factory The scope of a modern software factory spans all aspects of the development lifecycle: **coding, building, integration, and verification/validation (V\&V)**. Each step aims to remove bottlenecks, streamline workflows, and shorten feedback cycles. Take the **build process** as an example: in traditional systems, software builds can take up to 20 hours—far too slow for agile iteration. By optimizing pipelines, engineers can reduce build times to just a few minutes, enabling rapid testing and validation. The same principle applies to integration and V\&V, where automation replaces manual handovers, and engineers receive near-instant feedback on code quality.
Today, the software factory primarily focuses on single software stacks (e.g., POSIX or AUTOSAR). However, the future vision expands to include the **entire SDV ecosystem**. This means automating processes across multiple domains—like ADAS, infotainment, and body control systems—integrating them into a cohesive whole that reflects the complexity of the modern vehicle. ## Example: Edge and Cloud Software Development Consider an example in **Edge and Cloud software development**. The process begins with creating classical code or training AI/ML models. Next comes the build step, followed by continuous integration, testing, and delivery.
At every stage, the goal is to **tighten feedback cycles**. If a bottleneck exists—say, a slow build system or manual handover—it is identified, optimized, and automated. Real-world feedback from vehicles in operation is incorporated back into the pipeline to identify and resolve issues efficiently. Over time, this iterative process leads to higher-quality software, greater productivity, and fewer manual interventions. ## The Future of the Software Factory The SDV Software Factory will evolve to encompass the entire lifecycle, from **requirements to operations**. The aim is not only to optimize individual pipelines but also to integrate workflows across all vehicle systems. For example, automating the build and integration pipelines for both ADAS and infotainment systems, then merging these systems into the fully integrated vehicle. In summary, the SDV Software Factory is the automotive industry’s answer to the need for high-quality, efficient software development. By adopting principles of **automation**, **continuous improvement**, and **systematic optimization**, OEMs can meet the growing demands of software-defined vehicles while ensuring reliability, scalability, and speed. # Implementing the Shift Left In this chapter, we focus on the implementation of **"Shift Left"**—a strategy to identify and resolve issues as early as possible in the development lifecycle, minimizing costly fixes downstream and accelerating time-to-market. By shifting activities such as prototyping, validation, and testing **earlier in the process**, OEMs can dramatically improve quality, reduce risks, and enable faster iterations.
The chapter explores a comprehensive set of techniques and tools that enable the **Shift Left** approach, starting with **simulation and virtual prototyping**, which include cloud-based prototyping and immersive UX testing to validate user experiences at an early stage. We will also delve into **virtual development and testing**, highlighting virtualization strategies that form the backbone of a robust digital-first vision. While virtual methods are powerful, physical testing remains indispensable. This section will also address **physical test systems** such as Hardware-in-the-Loop (HiL), engineering mules, and development vehicles, which provide the bridge between virtual validation and real-world verification. Complementing these strategies is **fleet-based testing**, where real-world data is collected and analyzed to validate performance at scale, ensuring continuous improvement throughout the vehicle lifecycle.
Finally, we bring everything together under the theme of **#digitalfirst system evolution**, showcasing how a digital-first mindset supports the integration of simulation, virtual testing, and physical validation into a cohesive, end-to-end process. By combining these elements, OEMs can establish a powerful foundation for **multi-speed development**, continuous testing, and ongoing evolution of software-defined vehicles. # Simulation and Digital Prototyping To successfully implement **Shift Left**, simulation and prototyping play a critical role in accelerating development cycles and ensuring higher-quality outcomes. As shown in the diagram, both approaches address key challenges in the early phases of the development process. ## Introduction **Prototyping** focuses on **reducing project risk** by validating ideas early and confirming that teams are building the *right* product. By testing and evaluating concepts with end-users at the earliest stages, prototyping ensures alignment between development goals and user expectations, avoiding costly course corrections later in the process.
On the other hand, **simulation** is essential for **predicting system performance** and ensuring that the product is being built *right*. Simulation allows teams to assess existing systems, test planned changes, and evaluate alternative solutions in a virtual environment before any physical implementation occurs. This significantly reduces the dependency on time-consuming physical prototypes and enables rapid iteration and optimization. In the context of Shift Left, combining **prototyping** for validation and **simulation** for performance prediction helps identify and resolve issues as early as possible, minimizing downstream risks and driving efficiency throughout the development lifecycle. Together, they ensure that teams can move faster, improve quality, and deliver better outcomes with fewer surprises. ## McKinsey Case Study A recent McKinsey Case Study highlights **three critical levers** for improving testing and validation efficiency during product development and ramp-up phases: 1. **Push on Virtualization**: By leveraging virtual simulation and digital models, teams can test and validate designs early, reducing risks and optimizing decisions with tools like 3D modeling. 2. **Optimize Use of Prototypes**: Physical prototypes remain necessary, but their usage is streamlined through rapid prototyping, frontloading tests, and better coordination. This reduces testing costs and efforts significantly. 3. **Shift Tests to Preseries**: Final validation happens on pre-series vehicles using series tools, enabling earlier detection of production-related issues and ensuring high-quality outcomes. The level of impact spans from **revolution**—through virtualization—to **evolution** as processes mature.

Source: McKinsey

To emphasize the importance of prototyping, McKinsey references a case study from an **aircraft manufacturer** that implemented a virtual development platform shared with 27 partners. This collaborative approach resulted in a **50% reduction in assembly time** and a **66% decrease in tooling costs**, demonstrating the enormous value of virtual tools and optimized prototyping. This example underlines how combining virtual and physical testing accelerates development while maintaining quality and cost efficiency. {% embed url="" %} # Early Validation: Cloud-based SDV Prototyping Cloud-based SDV prototyping provides a lightweight and cost-effective way to validate new ideas early in the development process. By implementing prototypes in the cloud, developers can test functionalities against real vehicle APIs while using mock-up or simulated data. This approach enables a quick, flexible exploration of concepts without requiring physical test setups, making it an ideal starting point for innovation. A key advantage of cloud-based prototyping is its ability to support **shift left** strategies effectively. It accelerates validation by allowing early engagement with multiple stakeholders – from product teams to end-users – fostering alignment and feedback at minimal cost. By validating assumptions and refining requirements before heavier development efforts begin, teams reduce risks and improve efficiency, ensuring that they are building the **right product** from the outset. This method not only supports agile iterations but also provides a clear path for moving validated concepts into more robust testing phases, driving speed and confidence in the software-defined vehicle development lifecycle. ## Cloud-based Prototyping with the digital.auto Playground The **cloud-based SDV prototyping approach** illustrated in the diagram leverages the free and open **digital.auto playground** to enable early-stage validation and rapid iteration of vehicle features. At its core, this process bridges **stakeholder feedback** with **enterprise architecture**, requirements, and components (HW+SW), ensuring alignment between development efforts and business goals.
The playground enables the creation of **prototypes** that validate requirements and epics in an agile and iterative manner. Stakeholders can interact with early versions of the software or functionality, providing feedback that loops back into the development cycle. This iterative process ensures transparency, allowing for better collaboration between business, IT, and organizational boundaries. Key benefits include: 1. **Improved Transparency**: Promotes clear visibility across teams and regions, aligning business and IT objectives. 2. **Early Validation of Components**: Prototypes validate enterprise architecture decisions and ensure consistency. 3. **Identification of API Requirements**: API dependencies, especially for hardware and external supplier components, are identified early to address long lead times. 4. **Agile Development with MVP**: Encourages incremental delivery of minimum viable products while ensuring robust and validated components through the **First Time Right** principle. Overall, this cloud-based prototyping approach reduces risks, accelerates development timelines, and aligns hardware and software components seamlessly, enabling efficient and high-quality SDV delivery. ## Example The range extension example highlights the use of digital.auto's playground platform, implementing an SDV algorithm for EV range optimization.
Leveraging COVESA's Vehicle Signal Specification (VSS), the algorithm interacts with mock-up vehicle signals, initially coming from a test database, to demonstrate range-saving capabilities like powering down non-essential energy consumers (e.g., HVAC or infotainment). This cloud-based prototyping validates the solution efficiently before hardware integration, aligning with the *shift-left* philosophy for faster, cost-effective testing and multi-stakeholder alignment. For full details: [COVESA EV Power Optimization Whitepaper](https://wiki.covesa.global/download/attachments/37093447/2023%20Whitepaper%20EV%20Power%20Optimization%20202310.pdf?version=1\&modificationDate=1697035446299\&api=v2). # Detailed Validation: SDVs and Simulation Simulation has long been a cornerstone of vehicle development, supporting everything from physics simulations for crash testing and aerodynamics to energy management, sensor modeling, and control system validation. These tools are essential for improving efficiency, safety, and performance across all stages of design and testing.
However, traditional vehicle simulation systems are complex, comprehensive, and time-consuming to build. To address this challenge in the SDV era, modularization, architectural layering, and the *shift north* approach—supported by the Vehicle Hardware Abstraction Layer (VHAL)—are critical. This enables faster, more agile simulation environments that decouple hardware from software development, aligning with modern SDV strategies. ### SDV Simulation Domains Simulation plays a critical role in modern vehicle development, enabling comprehensive virtual testing across multiple domains to reduce costs and time. Key areas include **Vehicle Dynamics and Performance**, where handling, braking, and aerodynamics are optimized, and **Safety and Crashworthiness**, which tests crash scenarios to validate occupant protection systems. **Environmental Testing** assesses vehicle performance across varying weather, terrain, and altitudes, while **Electrification and Energy Management** models battery range, charging, and energy use. In **ADAS and Autonomous Driving**, simulations validate sensors, decision-making algorithms, and vehicle behavior. **E/E Systems and Software** benefit from Hardware-in-the-Loop (HIL), Software-in-the-Loop (SIL), and Model-in-the-Loop (MIL) testing to ensure seamless integration. Computational Fluid Dynamics (CFD) enhances **Aerodynamics and Thermal Management**, while **Human Factors and UX** simulations focus on ergonomics, HMI interfaces, and cabin NVH performance. Additionally, virtual **Regulatory Compliance** testing ensures emissions, safety, and homologation standards are met. Simulations also address **Modular and Variant Testing** for platform flexibility and configuration validation, as well as **Sustainability and Lifecycle Analysis** to model environmental impacts. Finally, **Manufacturing and Assembly** processes are optimized virtually, improving factory workflows and reducing production issues. Together, these simulation efforts create a robust, efficient, and agile development process, supporting a "Shift Left" strategy in vehicle engineering. ### SDV and Simulation Simulation in Software-Defined Vehicles (SDVs) predominantly occurs **south of the Vehicle Hardware Abstraction Layer (VHAL)**, where it focuses on physical systems and safety-critical, ASIL-compliant components. These simulations replicate real-world vehicle behavior for areas like vehicle dynamics, battery management, and environmental conditions, ensuring high-fidelity results closer to physical reality. In contrast, development **north of the VHAL** follows a **code-first** approach. Algorithms here, often classified as QM or low-ASIL, are developed iteratively using agile methodologies, MVPs, and continuous improvement. This separation enables rapid innovation north of the VHAL while maintaining stability and accuracy south of it, showcasing the benefits of modularization and layered development. This modular approach allows for **cross-domain integration**, even when different domains south of the VHAL rely on distinct simulation platforms, ensuring cohesive, multi-domain validation while accelerating innovation. ### Example: Simulation for Range Extension SDV Use Case In the next step of the *Range Extension* use case, the basic mock-up data south of the Vehicle Hardware Abstraction Layer (VHAL) is replaced with a more realistic vehicle simulation. This advancement ensures that vehicle behavior below the VHAL is far more accurate, leading to better testing and validation results for the range extension algorithm north of the VHAL.
Importantly, this change does not impact the algorithm itself, as it interacts with the vehicle API above the VHAL. This demonstrates the benefits of *loose coupling*—allowing improvements south of VHAL without affecting development north of it. ### Simulation-based Test Strategies To enable a deeper understanding of simulation methods in SDV development, we will explore Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Hardware-in-the-Loop (HIL) approaches, highlighting their roles, benefits, and importance in achieving efficient and reliable testing across different stages of the development cycle.
The diagram illustrates three key simulation approaches in the context of Software-Defined Vehicles (SDVs): Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), and Hardware-in-the-Loop (HIL). * **MIL**: Simulation inputs are tested against mathematical or functional models. It allows early testing of algorithms or system behaviors in a virtual environment. * **SIL**: Validates software components by simulating their performance with inputs and outputs. This ensures the software works as intended before integration. * **HIL**: Combines real hardware with simulated environments to test physical components under realistic conditions. These simulation "loops" enable iterative testing, providing fast feedback while reducing risks and costs. They also allow cross-domain integration, ensuring systems interact seamlessly, which supports a shift-left approach to development. # Towards the Virtual Vehicle The evolution from vehicle simulation to a fully virtualized vehicle, including virtual ECUs and virtual bus systems, enables comprehensive testing of software and system integration in a digital environment, accelerating development while reducing dependency on physical prototypes.
## What exactly is virtualization? Virtualization allows software or hardware to run on generalized, widely available hardware, such as consumer-grade systems, instead of specific, high-cost controllers. By virtualizing components like controllers, developers can replace limited, specialized hardware with scalable solutions running on Windows or Linux environments. This approach reduces costs, improves resource availability, and accelerates development cycles. It enables faster iterations, as engineers can test and validate systems without waiting for physical controllers, making software-defined vehicle development more efficient and accessible.
Virtualization plays a pivotal role in the SDV development lifecycle by bridging the gap between simulation and physical testing. It allows application code to run seamlessly in both virtual ECUs (vECUs) and real hardware ECUs, enabling environmental parity for consistent development and validation. This approach significantly reduces hardware dependencies, accelerates development timelines, and improves collaboration for globally distributed teams. Moreover, virtualization supports cloud-based management of test environments, simplifying tasks like cloning and scaling, ultimately enhancing efficiency and flexibility across the development process.
## What are Virtualization Levels The different virtualization levels represent a gradual progression from abstract simulations to fully realistic, hardware-level testing. This progression is necessary to balance speed, cost-efficiency, and accuracy as development advances. 1. **Level 0 (Controller Model):** Simulates the controller logic at a high abstraction level, focusing on basic functionality validation. 2. **Level 1 (Application Level):** Introduces software applications, testing interactions within the application layer. 3. **Level 2 (Simulation BSW):** Adds a simulated basic software (BSW) layer for more detailed behavior testing. 4. **Level 3 (Production BSW):** Tests production-grade BSW, ensuring compatibility and integration. 5. **Level 4 (Target Binary):** Deploys the actual target binary, validating software in near-real conditions. This tiered approach ensures early-stage development is fast and cost-effective while allowing a gradual transition to higher-fidelity testing closer to physical hardware.
## Example: Cross-ECU Simulation The following example illustrates the integration of virtualization into different types of ECUs within a Software-Defined Vehicle (SDV). On the left, a **Virtual High-Performance Compute ECU** runs on standard hardware with a Linux-based environment, enabling applications to interact through a **Vehicle API**. This abstraction allows flexibility, as the virtualized system mimics real hardware behavior while being cost-efficient and scalable.
On the right, a **Virtual Endpoint ECU**, such as AUTOSAR Classic, runs on a simulated microcontroller stack. It mirrors the structure of real embedded ECUs, with abstraction layers, service layers, and drivers. Communication between these systems happens over **virtual buses** like vCAN or vETH, enabling seamless interaction. Together, these setups reduce dependencies, speed up development, and allow testing across distributed environments. By combining virtual high-performance compute units with virtual microcontroller-based ECUs, teams can validate cross-domain functionality and optimize vehicle behavior cost-effectively and early in the development process. ## Time Synchronization In co-simulation of multiple virtual ECUs (vECUs), **time synchronization** is critical to ensure consistent communication and execution across all components. The goal is not to match real-world speed but to maintain a unified time domain so that all sub-systems, regardless of complexity, run on the same relative timeline. Without proper synchronization, the simulated components may drift out of sync, leading to misaligned data exchanges, invalid test results, and incomplete validation of interactions between systems.
Virtual buses, such as **vCAN** or **vETH**, facilitate synchronized communication between the vECUs. These buses ensure that inputs, outputs, and messages are transmitted in a harmonized manner, reflecting the intended interactions of the physical system. Even if the simulation operates slower than real-world execution, **all components must adhere to the same simulated time**. This is especially vital for validating event-driven systems, where delays or timing mismatches can introduce unintended behavior, reducing the reliability of test results. Ultimately, accurate time synchronization guarantees that the overall system behaves as a cohesive unit, enabling precise testing, validation, and verification in complex SDV simulations. # Case Study: Multi-Supplier Collaboration on Virtual Platform To address the aforementioned challenges of **“integration hell”** in automotive development, virtual development platforms can play a critical role in the future. They simplify the integration of components coming from multiple suppliers by providing a unified environment for testing and validation. ## Case Study Overview This case study highlights a scenario involving two distinct Electronic Control Units (ECUs): a high-performance ECU (ECU1) and a lower-level endpoint ECU (ECU2). The challenge stems from the **OEM’s decision to unbundle hardware and software suppliers**, resulting in multiple suppliers contributing software components, even for the same ECU.
In this example: * **Supplier 1** and **Supplier 2** deliver separate software components running on ECU1. * The OEM simultaneously develops a software component for ECU2. * The system integration requires **three software components** (two from suppliers, one from the OEM) to function cohesively as part of a single **event chain**. ## Development Process and Pipelines 1. **Isolated Development**: * Supplier 1 develops software for ECU1, using a **mock-up environment**. * Supplier 2 develops a service provider component, testing it against a mock service client. * The OEM independently develops software for ECU2 in a separate environment. 2. **Virtual Integration Environment 1**:\ The software components from Supplier 1 and Supplier 2 are integrated onto **virtual ECU1**. Meanwhile, the OEM’s software is tested on **virtual ECU2**. 3. **Integrated Virtual Environment 2**:\ Both virtual ECUs—ECU1 and ECU2—are brought together, running all three components (Supplier 1, Supplier 2, and OEM) in an integrated manner to validate the end-to-end event chain. 4. **HIL Testing**:\ The validated software progresses to **Hardware-in-the-Loop (HIL) testing**, where the system undergoes further validation in realistic physical and virtual environments.
## Key Takeaways This case highlights the effort required not only to develop **individual virtual ECUs** but also to set up robust **development, integration, and testing pipelines**. These pipelines are critical to ensure efficient DevOps workflows, automate testing, and accelerate development cycles while managing contributions from multiple suppliers. By leveraging virtual environments early and progressively integrating components, OEMs can **minimize integration challenges** and **streamline validation** across ECUs. # Long-Term Vision The long-term vision for SDVs focuses on a **100% virtualized vehicle in the cloud**, enabling engineers to **clone test vehicles effortlessly**. Instead of spending months replicating complex HIL integration scenarios or building physical test vehicles, virtual vehicles can be copied and pasted with a few clicks. This allows for rapid deployment of identical test setups, accelerating testing timelines and reducing costs.
## Cloning Test Vehicles for Scalability Cloning virtual vehicles provides a significant edge in scalability. Engineers can create unlimited instances of the same test setup, whether for running simultaneous tests, replicating advanced driving scenarios, or supporting globally distributed teams. This capability removes constraints associated with physical vehicle availability, enabling **unparalleled flexibility** in testing.
## Advanced Configuration and AI-Driven Adaptation Generative AI simplifies reconfiguration of virtual vehicles. For example, converting a left-hand drive model to a right-hand drive becomes seamless as AI identifies and automates adjustments, such as repositioning the steering wheel and associated components. This results in two **independent test environments** for parallel validation, enhancing efficiency in managing diverse vehicle variants.
## Virtual Integration with Hardware-in-the-Loop Virtual environments pave the way for **HIL testing**, where real hardware components, such as ECUs, sensors, and actuators, are validated within simulated conditions. Initially, Component HIL validates single hardware modules, while **System HIL** scales to the entire vehicle, forming a **House of HIL** for comprehensive testing.
## Managing Complexity in the House of HIL The House of HIL integrates dozens of ECUs, sensors, and actuators in modular test racks, supporting system-level validation. Reconfiguring these physical setups for new variants—like left- versus right-hand drive—requires significant time and resources. However, feeding **simulated data** into HIL environments ensures robust safety validation without needing operational vehicles. ## Bridging Virtual and Physical Systems Features like “cabin door open” require safety checks, such as vehicle speed and rear-camera inputs. Simulated data replaces real-world inputs, enabling hardware systems to operate and validate functions within the HIL lab seamlessly. ## The Future of System Complexity As SDVs transition toward **centralized compute** and **zone-based architectures**, the complexity of HIL systems may reduce. Combined with the ability to **clone virtual vehicles**, this evolution allows for a modular, scalable testing strategy that enhances speed, cost efficiency, and collaboration. By integrating **virtual cloning**, AI-driven configuration, and **HIL validation**, this approach empowers the industry to accelerate development cycles and streamline the path to software-defined vehicles. # Physical test system While **virtualization** and **shift-left strategies** significantly reduce physical testing overheads, physical testing remains **irreplaceable** to ensure real-world performance, safety, and durability. Real-world environments introduce variables like vibrations, wear-and-tear, and edge-case conditions that cannot be fully replicated in simulations. Physical testing also validates **complex integrations** between hardware and software under real operational stress. By combining virtual and physical testing, manufacturers can ensure not only faster development cycles but also the robustness and reliability required for **safe, high-quality vehicles** on the road. In automotive testing, physical test systems ensure real-world validation of vehicle components and systems. The primary types include: 1. **Component HIL (Hardware-in-the-Loop)**: Real hardware components (e.g., ECUs, sensors, actuators) are tested in virtual environments simulating vehicle behavior and conditions. 2. **System HIL:** Integrates multiple components into sub-systems (e.g., powertrain or ADAS) for end-to-end validation. 3. **Development Vehicles**: Pre-production prototypes used to test real-world performance and integration across systems. 4. **Engineering Mules**: Modified test vehicles combining new components with existing platforms to assess feasibility. 5. **Fleet-Based Testing**: Real-world driving of multiple vehicles to collect data over time for reliability and performance analysis. Each of these systems plays a critical role in bridging the gap between simulation and real-world conditions, ensuring robust vehicle performance. ## Hardware-in-the-Loop Testing **Hardware-in-the-Loop (HIL)** is a testing method where real hardware components, such as ECUs and sensors, are integrated into a virtual environment. This virtual environment simulates the rest of the vehicle, its subsystems, or real-world operating conditions like driving scenarios. HIL testing allows systems to be validated in near-real conditions without requiring a fully built physical car. This significantly accelerates development, reduces costs, and ensures safety-critical components are thoroughly tested before integration into physical prototypes.
The introduction of **High-Performance Computing (HPC)** and **Software-Defined Vehicles (SDVs)** is transforming HIL testing in significant ways: 1. **Increased Complexity**: HPC enables centralized computing and domain integration, meaning HIL systems must simulate entire zones or vehicle domains, not just isolated ECUs. This requires more processing power and advanced virtual environments. 2. **Scalability**: HIL setups now need to scale for SDV architectures, where software can continuously evolve. Virtualization and cloud support allow hardware to be integrated with virtual components for modular and agile testing. 3. **Real-Time Requirements**: HPC-powered systems and SDVs demand synchronized testing across virtualized ECUs, real hardware, and connected systems to ensure functional safety (ASIL) and performance. 4. **Software-Centric Focus**: SDVs rely on frequent software updates. HIL systems are evolving to validate over-the-air (OTA) updates, dynamic software configurations, and real-world scenarios rapidly. 5. **Enhanced Simulation Integration**: Combining HIL with virtual environments enables **hybrid testing**, where virtual and physical components interact seamlessly. This is crucial for validating AI-driven features, ADAS, and autonomous functions. In essence, HIL is transitioning from isolated, static setups to dynamic, integrated platforms that accommodate evolving SDV architectures, high-performance computing, and real-time software development. ## System HIL Testing **System-HIL** (System Hardware-in-the-Loop) represents an advanced level of HIL testing where **entire vehicle systems**—spanning powertrain, infotainment, ADAS, and body controls—are integrated into a single testing environment. Unlike component-level HIL, System-HIL focuses on realistic **system-level interactions** to simulate full-vehicle behavior under near-real conditions.
### House of HIL A **House of HIL** is an advanced test environment that integrates numerous **Hardware-in-the-Loop (HIL)** systems to validate the full vehicle. It consists of **multiple component HILs**, each dedicated to testing individual ECUs, sensors, or actuators, and combines them to form a complete **system-level testing setup**.
For a **single vehicle**, a House of HIL setup typically includes: * **Dozens of Component HILs**: Each HIL tests specific ECUs (e.g., ADAS, infotainment, braking). A modern car may have **30-70 ECUs**, requiring corresponding HIL systems. * **Physical Space**: HIL test racks, power supplies, and cooling infrastructure require **dedicated labs**. For a full vehicle, this can span several rooms, often over **hundreds of square meters**.
The number of **Component HILs** depends on vehicle complexity: * **Modern SDVs**: Up to **50+ component HILs** for individual ECUs. * Each HIL tests functions like **powertrain**, ADAS, climate control, and body electronics independently before integrating into the system. The House of HIL combines these systems, ensuring synchronization and enabling end-to-end validation for complex vehicles. ### Impact of High-Performance Compute and SDVs The introduction of High-Performance Compute and SDVs will have a significant impact on System-HIL, including: 1. **System Integration**\ With HPC and centralized SDV architectures, multiple domains (powertrain, ADAS, infotainment) need integrated testing. System-HIL ensures realistic interaction across interconnected systems, enabling validation of complex dependencies. 2. **Data Management and Processing Power**\ SDVs generate massive amounts of real-time data. System-HIL relies on HPC to manage, process, and simulate this data efficiently, ensuring accurate testing of time-sensitive systems like braking and steering. 3. **Hardware-Software Synchronization**\ High-performance computing allows for better synchronization between physical hardware components and virtual systems. For SDVs, this is critical to validate continuously evolving software configurations and over-the-air (OTA) updates. 4. **Scalability and Modular Testing**\ Modular testing of subsystems is integrated into a scalable System-HIL setup. For example, a full-vehicle simulation can test individual zones or domains while maintaining system-wide scalability. 5. **Realistic Sensor and Actuator Emulation**\ Advanced ADAS and autonomous functions rely on accurate sensor and actuator emulation. System-HIL integrates real hardware with virtual sensors to ensure realistic, safety-critical system validation. 6. **Cost and Space Optimization**\ While System-HIL requires substantial resources, virtualization and HPC reduce physical infrastructure by integrating virtual environments, minimizing costs and space needed for traditional hardware racks. The figure below indicates how a System HIL should be designed to test our - by now famous - Open Door API.
### Conclusion System-HIL, evolving with HPC and SDVs, supports **full-vehicle testing** by combining real hardware with advanced simulations. It ensures scalable, modular, and synchronized validation while addressing the growing complexities of software-defined and high-performance vehicle systems. ## Engineering Mules **Engineering Mules** are early-stage test vehicles built by combining new development components with an existing production vehicle platform. They allow **real-world testing** of systems like powertrains, suspension, or new electronic architectures long before the final vehicle design is ready. Mules help **validate critical functions** under real driving conditions, bridging the gap between simulation and full vehicle prototypes. They reduce **development risks** by exposing design flaws early, allowing engineers to refine systems before committing to costly production tooling.
## Sample Vehicles The A-D test samples represent progressive stages of prototype development in automotive testing: 1. **A-Sample**: Initial prototypes validate basic functionality and identify integration issues. 2. **B-Sample**: Enhanced prototypes refine subsystem interactions, optimize software, and test durability. 3. **C-Sample**: Pre-production prototypes undergo full regulatory, safety, and real-world deployment tests. 4. **D-Sample**: Production-intent prototypes confirm readiness for production, meeting all quality and compliance requirements. In the past, non-connected vehicles in A-D sample phases had minimal issues with version compatibility, as systems were self-contained. However, in **SDVs**, cloud backends and Vehicle-to-Cloud (V2C) APIs are integral to vehicle operations. If these **APIs or backend services** evolve during development, it creates versioning challenges. Sample vehicles at various phases (A-D) need their **on-board software** and cloud services to remain synchronized. Misalignment can cause failures in functionality or testing, requiring strict version control, backward compatibility, and coordinated updates across all systems. This synchronization is critical for seamless integration and validation.
## Vehicle-in-the-Loop Vehicle-in-the-Loop (ViL) testing is a method that combines real vehicles with a simulated environment to validate vehicle systems under controlled and realistic conditions. The vehicle operates on test benches, like chassis dynamometers, while virtual inputs simulate road conditions, traffic, and sensor data. ViL is particularly useful for validating advanced driver assistance systems (ADAS), autonomous driving, and energy management. It enables repeatable testing of complex scenarios without physical road tests, improving safety, cost efficiency, and development speed. This approach bridges simulation and real-world testing.
## Fleet Testing and Fleet Data Test fleets are essential for validating vehicles under real-world conditions, evolving into production fleets as development progresses. Initially, small fleets (5-20 vehicles) validate core systems, focusing on functional testing and performance. As systems mature, mid-sized fleets (50-200 vehicles) capture diverse data, testing across environments, driver behaviors, and edge cases. Test fleets generate **terabytes of data** daily, including sensor logs, V2C communication, and diagnostics. Production fleets scale up (thousands of vehicles), monitoring long-term reliability, OTA updates, and real-world user feedback to ensure readiness for market deployment. For progressive OEMs, every production vehicle now also acts as a test vehicle for new feature updates delivered via **Over-the-Air (OTA)**. While updates undergo rigorous validation and homologation, they enable continuous innovation post-production. This approach allows OEMs to experiment more dynamically, gradually introducing new features or improvements. Compared to the past, where vehicles were static once sold, today’s production vehicles serve as platforms for iterative development, leveraging real-world data and feedback to refine performance, safety, and user experience.
Fleet data offers numerous opportunities for OEMs and operators to optimize vehicle development and operations: 1. **Product Development**: By identifying patterns and real-world usage, fleet data helps refine features, improve vehicle performance, and address customer needs dynamically. 2. **Continuous Homologation**: It supports compliance by validating software updates to ensure regulatory alignment as vehicles evolve. 3. **Fleet Management**: Real-time data optimizes operations, reduces maintenance costs, and improves uptime. 4. **Research & Innovation**: Anonymized datasets power AI model development for autonomous driving and other advanced technologies. 5. **Customer Support**: Proactive issue detection enhances support and reduces customer disruptions. 6. **Sustainability Efforts**: Fleet data tracks emissions and promotes green initiatives, supporting environmental goals.
# De-Coupled, Multi-Speed System Evolution Coming back to our goal of establishing a shift-left approach in combination with multi-speed development, we have now looked at the evolution along the V-Model. In this context, it is important to understand that testing evolves independently north and south of the Vehicle Hardware Abstraction Layer (VHAL). North of the VHAL, algorithms and software are developed and validated without direct dependency on the underlying hardware, enabling rapid prototyping and iterative testing. Applications here are agnostic to whether they interact with lightweight simulations, virtual ECUs, or physical test hardware, supporting agile, continuous improvement.
South of the VHAL, the test environments progress in complexity – starting with basic models, moving to high-fidelity simulations, virtual ECUs, and ultimately hardware-in-the-loop (HIL) and physical systems. This layered approach ensures embedded systems, often safety-critical (ASIL), are rigorously validated under realistic conditions. By decoupling development speeds, engineers can iterate quickly on software north of the VHAL while gradually increasing hardware realism south of the VHAL. This multi-speed strategy accelerates testing cycles and supports robust, end-to-end validation across the V-Model. The multi-speed, shift-left approach combined with the VHAL separation offers several key benefits: 1. **Accelerated Development**: Algorithms north of the VHAL iterate quickly, decoupled from hardware readiness. 2. **Scalable Testing**: Enables testing progression from lightweight virtual prototypes to realistic hardware environments. 3. **Cost Efficiency**: Reduces dependency on physical prototypes early in development. 4. **Enhanced Flexibility**: Software remains agnostic to test environments, fostering reusability across simulations and hardware. 5. **Improved Validation**: Gradual complexity south of the VHAL ensures robust, safety-critical validation without stalling software development. These benefits are enabled by the de-coupled, multi-speed system evolution approach. # Continuous Homologation As Software-Defined Vehicles (SDVs) evolve through frequent software updates, ensuring compliance with regulatory and safety standards becomes a continuous challenge. Traditionally, vehicle homologation—the process of certifying that a vehicle meets regulatory standards—was performed after development was complete. This model worked in a hardware-dominated automotive world but fails in the fast-paced, iterative environment of SDVs. This is where **Continuous Homologation (CoHo)** comes into play. ## **How Continuous Homologation Fits into Shift-Left** The **Shift-Left** approach in SDV development advocates for earlier testing, validation, and integration, moving critical processes "leftward" on the development timeline. Continuous Homologation extends this principle by embedding compliance checks into the development process itself. Rather than treating homologation as a final, isolated step, CoHo ensures that every change—whether a software patch or a major feature update—is evaluated for regulatory impact as soon as it is proposed.
By shifting regulatory validation left, CoHo allows software teams to identify and address compliance issues early. This reduces the risk of costly delays caused by late-stage certification failures. It also ensures that regulatory compliance keeps pace with rapid development cycles, enabling continuous delivery while maintaining safety and legal integrity. #### **Key Elements of Continuous Homologation** 1. **Automated Compliance Checks:** Every Change Request (CR) is automatically matched against relevant regulations using advanced tools. 2. **Virtual and Real-World Testing:** Compliance is validated through simulation, virtualization, and real-world testing environments. 3. **Progressive Validation:** Testing progresses from early prototypes to full-system integration, ensuring continuous verification. 4. **Collaborative Ecosystem:** OEMs, suppliers, and regulators must work together using shared platforms to streamline compliance efforts. ## **digital.auto Whitepaper** The whitepaper *“Continuous Homologation for Software-Defined Vehicles”* provides a detailed framework for implementing CoHo. It covers Change Request management, regulatory mapping, dependency analysis, and simulation-based validation, supported by real-world case studies. The proposed system emphasizes automation, scalability, and collaborative standard-setting within the industry. For a deeper dive, read the full whitepaper here: [**Continuous Homologation Whitepaper**](https://www.digital.auto/_files/ugd/604381_8407b82ac15a4ae0a0ed508894bcf814.pdf). # Summary and Outlook Let’s look at the strategic benefits before finishing the discussion with an outlook for a long-term, **#digitalfirst Vehicle Development** approach. ## Strategic Benefits Along the V-Model, several key benefits emerge when applying shift-left strategies: By shifting towards virtual prototyping, simulation, and advanced digital tools early in the V-Model, organizations can achieve **early alignment, stakeholder engagement, and rapid iteration**. At the initial phases, improved stakeholder alignment and early customer feedback help validate desirability and UX quickly. This enables early stabilization of APIs and the end-to-end E/E architecture, ensuring robust foundations.
During virtual testing, fine-tuning features and validating variants accelerate development while reducing HIL testing costs and efforts. Later phases benefit from more flexibility due to a delayed HIL start, allowing focused testing. Finally, the overall process reduces homologation costs and efforts while improving system quality and integration efficiency. ## **Vision: #digitalfirst Vehicle Development Phases** The #digitalfirst approach envisions multiple iterations through the V-Model to optimize vehicle development and operations. It begins with **Concept & Integration Landscape**, focusing on lightweight mock-ups, API identification, and a holistic experience. This evolves into **Virtual Vehicle & Simulation**, where virtual ECUs, bus systems, and physics simulations enable extensive testing, including variant analysis. This could be a full iteration through the V, resulting in a fully functional albeit virtual vehicle. **Hybrid Vehicle (Virtual + Real)** integrates virtual testing with physical builds, complete HIL setups, and test fleets. Finally, **Continuous Optimization** supports OTA updates, continuous homologation, and rapid deployment of fixes, enhancements, and new features for seamless innovation and compliance.
# Enterprise Topics As we conclude the discussion on implementation strategies, it is essential to address key enterprise-level topics that ensure successful adoption of Shift-Left in SDV development. Vehicle variant management must extend to the software level, enabling flexible and scalable configurations. Engineering intelligence must provide robust tools to manage diverse development processes and tool landscapes. Enterprise processes and architecture require a holistic perspective to integrate teams, workflows, and technologies effectively. Finally, understanding the strategic differences between incumbent OEMs and disruptors helps determine the best path forward. These considerations set the stage for the next chapter, where we explore these critical enterprise aspects in detail. # Variant Management Vehicle variants refer to the numerous configurations of a vehicle model created to meet **market demands**, **regional specifics**, and **regulatory requirements**, as illustrated in the diagram. Customers may customize their vehicles using options like engine power, wheel size, seat type, or color via a sales configurator. Additionally, variations are introduced to comply with region-specific regulations or preferences, such as emission standards, safety requirements, or driving habits.
While these variants are essential to satisfy customer preferences and address diverse market needs, they introduce significant challenges across the entire vehicle lifecycle. From **design and engineering**, the need to accommodate multiple combinations of features increases system complexity, requiring sophisticated management tools and processes. In **manufacturing**, the growing number of variants complicates production lines, demanding flexible assembly processes and increasing costs. Once on the market, the **maintenance** of these vehicles becomes equally challenging, as each variant may require specific parts, diagnostics, and updates. ## Incumbent OEMs vs EV Start-ups Incumbent OEMs, both in the mass market and luxury segments, face particularly high variant complexity. Luxury manufacturers cater to customers with extremely high levels of personalization, offering a wide range of options to differentiate their vehicles. This results in significant engineering and manufacturing complexity but is necessary to meet premium customer expectations. Mass-market manufacturers, on the other hand, balance customization with production efficiency, offering fewer options but still managing significant complexity due to high volumes and broad market coverage.
In contrast, EV start-ups take a fundamentally different approach to variants. With a focus on simplicity, they limit customization options and portfolio complexity. Their vehicles are often designed with a smaller number of configurations, reducing engineering and manufacturing overhead. Instead of hardware-based personalization, EV start-ups rely on software-driven features to provide differentiation, such as over-the-air updates and digital services. This approach allows them to streamline production, lower costs, and adapt quickly to market demands. ## The Variant Space The **variant space** refers to the total number of mathematically possible combinations of vehicle features and configurations. This space grows exponentially as more options are introduced. For example, a low-end car with around **50 features** and **3 options per feature** results in over **718 trillion possible combinations**. In contrast, a high-end car with **200 features** and **10 options per feature** generates an astronomically large number of possibilities. This sheer scale of combinatorial complexity has significant implications. From an **engineering perspective**, every variant must be validated to ensure it meets performance, safety, and regulatory standards. In **manufacturing**, the variant space complicates production lines, as assembly must adapt to an immense range of configurations. Finally, in **maintenance**, managing spare parts, diagnostics, and software updates for such a large number of variants becomes a logistical challenge. ## Variant Management Tools To manage this complexity, OEMs rely on specialized **variant management tools** that integrate across various systems within the engineering and production lifecycle. These tools help track, configure, and validate variants efficiently, ensuring consistency and reducing errors. They work in close alignment with **Model-Based Systems Engineering (MBSE)** to define and analyze variant behavior early in the design process, ensuring all requirements are met. Variant management tools are also tightly connected to **Product Lifecycle Management (PLM)** systems, where product configurations, dependencies, and lifecycle information are centrally managed. In parallel, **Computer-Aided Design (CAD)** systems provide detailed design models that accommodate variant-specific features, while **Manufacturing Execution Systems (MES)** ensure that production lines adapt seamlessly to the required combinations. Further upstream, **sales configurators** enable customers to select their preferred vehicle options, directly feeding into the variant management ecosystem. This ensures a smooth flow of information from customer choices to engineering design, manufacturing planning, and final production. By connecting these systems, OEMs can streamline variant handling, reduce complexity, and maintain a single source of truth across the entire lifecycle. ## Handling Variants in Software-Defined Vehicles (SDVs) Software-Defined Vehicles (SDVs) must be capable of addressing vehicle variants dynamically, as software algorithms must operate reliably across diverse configurations. For SDVs, algorithms need to be developed and tested with multiple variants in mind, ensuring compatibility and seamless functionality. Take the **Passenger Welcome Sequence** as a simple example: this feature involves actions like seat adjustments and dashboard illumination when a driver enters the vehicle. In vehicles equipped with **seat adjustment**, the algorithm must include logic to trigger seat movement. However, for vehicles **without seat adjustment**, the algorithm must bypass this feature without failure. Similarly, the feature must adapt to both **left-hand drive** and **right-hand drive** configurations, accounting for sensor and actuator placements that differ across these variants.
There are two primary approaches to make SDV algorithms aware of variants: **Explicit Configuration Feeding:** The concrete vehicle configuration is explicitly provided to the software, allowing the algorithm to adapt its behavior based on predefined inputs. This method ensures clarity but requires consistent management of configuration data throughout the vehicle lifecycle.
**Dynamic Detection:** The algorithm dynamically detects the availability of sensors, actuators, and features during runtime. By querying the system for accessible components, the algorithm can adapt to the specific vehicle configuration autonomously. This approach enhances flexibility but demands robust detection mechanisms and fallback logic to handle missing components gracefully. Also, Homologation is probably much more difficult to achieve for this approach, at least with current Homologation processes between OEMs and approving agencies in place.
In summary, SDVs must manage variants at the software level, ensuring that algorithms like the Passenger Welcome Sequence can adapt seamlessly across different configurations. Whether through explicit configuration feeding or dynamic detection, handling variants effectively is essential for delivering a consistent and reliable user experience in the face of growing vehicle complexity. # Engineering Intelligence Engineering Intelligence brings together all relevant data from engineering sub-systems, such as **PLM**, **MES**, and **CI/CD systems**, by leveraging modern approaches like a **data mesh**. By connecting this data and applying **Generative AI (GenAI)**, engineering processes, as well as manufacturing and aftermarket operations, can be optimized. Engineering Intelligence addresses the need for consistency, efficiency, and actionable insights across increasingly complex systems. ## Incumbent OEMs Incumbent OEMs face unique challenges due to their **highly complex product portfolios** and **organically grown, heterogeneous toolchains**. Their systems span across multiple repositories, connecting requirements management, PLM, MES, CI/CD, ERP, CRM, and sales systems (as shown in the first image). While this setup has evolved over time to support specific needs, it introduces redundancy, inconsistency, and complexity across the engineering lifecycle. Managing this complexity is particularly challenging when dealing with the scale of variants seen in incumbent OEMs’ portfolios.
## EV Start-ups In contrast, EV start-ups operate with **leaner product portfolios** and much more stringent variant policies. They prioritize simplicity and standardization, minimizing the number of configurations and focusing on software-driven differentiation. Start-ups are often referred to as **single-repo companies**, where all engineering-related artifacts are managed within a single repository per domain (as shown in the second image). While they still maintain multiple repositories in practice, the stringent discipline of "one repo per domain" brings significant benefits, including reduced complexity, improved data consistency, and a single point of truth.
## Engineering Intelligence: Dealing with Heterogeneity and Redundancy Engineering Intelligence must address the heterogeneity and redundancy inherent in complex engineering systems, particularly for incumbent OEMs. By leveraging a **data mesh**, data from disparate systems can be connected and made accessible across the organization, breaking down silos. Additionally, **Generative AI** can analyze this data to provide insights, automate routine tasks, and optimize engineering workflows. This allows companies to manage complexity, streamline processes, and ensure consistency across systems, from design to production and aftermarket support.
In summary, Engineering Intelligence, powered by data mesh and GenAI, is key to overcoming the challenges of heterogeneity and redundancy. It enables both incumbent OEMs and EV start-ups to optimize their engineering processes, reduce complexity, and achieve greater agility in the face of growing product and system demands. ## Outlook: Product Line Engineering and Type-Based Product Line Engineering (TLPE) **Product Line Engineering (PLE)** is a systematic approach to managing a portfolio of related products by identifying shared assets and features while accounting for differences. This approach is particularly valuable in managing vehicle variants efficiently, as it allows manufacturers to define a core architecture and customize features for specific configurations. An emerging evolution of PLE is **Type-Based Product Line Engineering (TLPE)**. TLPE introduces a more structured, modular approach to managing product lines by categorizing features and assets into distinct types. This allows for better reuse, standardization, and traceability across the engineering lifecycle. Engineering Intelligence can both **empower and benefit from TLPE**. By integrating data from PLE systems, Engineering Intelligence can leverage AI-driven insights to identify opportunities for standardization, optimize feature reuse, and manage complexity effectively. Conversely, TLPE enhances the value of Engineering Intelligence by providing a clear, modular structure for data analysis, ensuring consistency across product lines. In summary, Product Line Engineering, particularly with TLPE, offers a scalable approach to managing variants. Combined with Engineering Intelligence, it enables manufacturers to achieve greater efficiency, consistency, and innovation across complex product portfolios. # Enterprise Organization, Processes, and Architecture The complexity of Software-Defined Vehicles (SDVs) requires a fundamental shift in enterprise organization, processes, and system architecture. This transformation is driven by the need to align teams, tools, and technologies to deliver faster, high-quality software updates while maintaining end-to-end consistency. To achieve this, enterprises must focus on three critical elements: **end-to-end responsibilities**, leveraging **shift-left approaches** for early feedback, and stabilizing API requirements and architecture. Additionally, combining **Model-Based Systems Engineering (MBSE)** with code-centric **DevOps** becomes essential to balance big-picture organizational views with agile, iterative development. ## 1. End-to-End Responsibilities In the SDV context, multi-skilled teams must take on **end-to-end responsibility** for delivering features and functions. These features are composed of **artifacts** contributed by multiple value streams, each with delivery pipelines operating at **different speeds**. For example, software components for cloud backends, embedded systems, and vehicle hardware evolve independently but must integrate seamlessly.
To succeed, teams must collaborate across domains, ensuring that ownership extends from feature conception to delivery and validation. By adopting end-to-end responsibility, organizations can: * Reduce handovers and delays between teams. * Improve the quality and consistency of delivered features. * Foster a systems-thinking mindset that considers the full lifecycle of a function. ## 2. Use Shift-Left to Get End-User Feedback Early The **shift-left approach** emphasizes testing, validation, and user feedback earlier in the development process. For SDVs, virtual prototypes of **end-to-end features and functions** enable feedback loops long before physical prototypes are available.
By using virtual environments and simulation tools, teams can: * Validate feature behavior in diverse configurations. * Gather end-user feedback early to align with customer needs. * Identify and resolve issues before integration into real vehicles. This iterative process allows organizations to de-risk development, accelerate time-to-market, and ensure that final features meet end-user expectations. ## 3. Use Shift-Left to Stabilize API Requirements and End-to-End Architecture Stabilizing **API requirements** and the **end-to-end architecture** early in the development process is critical for managing SDV complexity. APIs define the interfaces between components across different systems (e.g., cloud, embedded software, and vehicle hardware), and any instability can lead to integration issues and delays.
By shifting-left, teams can: * Define and validate API requirements early through virtual prototypes and iterative feedback. * Ensure architectural consistency across value streams and delivery pipelines. * Minimize late-stage changes that disrupt development and testing. A stable end-to-end architecture provides a robust foundation for integrating multi-speed delivery pipelines, ensuring that features and functions evolve cohesively across the SDV ecosystem. ## 4. Combining MBSE and Code-Centric DevOps The integration of **Model-Based Systems Engineering (MBSE)** and **code-centric DevOps** addresses the dual challenge of maintaining a **big-picture organizational and architectural view** while adhering to agile, iterative development principles. * **MBSE** focuses on creating high-level system models, defining requirements, and ensuring that architecture and system-level decisions are validated against overall goals. It provides the "big picture" of system structure, behavior, and dependencies, which is essential for managing SDV complexity. * **DevOps** follows the agile principle of "**code first**," where development progresses iteratively with rapid prototyping, testing, and integration. Code-centric practices prioritize delivering working software and enabling continuous feedback loops.
Combining MBSE with DevOps allows organizations to: * Align architectural decisions with real-world software implementation. * Balance long-term systems thinking with agile responsiveness to changes. * Continuously validate system models against the delivered code to ensure traceability and consistency. This approach ensures that the SDV development process remains both **structured and flexible**, enabling teams to deliver complex systems efficiently while maintaining alignment with organizational goals and customer requirements. #### 5. Building a Re-Usable SDV Platform The ultimate target for SDV development is to establish a **re-usable platform** that enables software to be shared, customized, and tailored efficiently across **multiple vehicle models** and **generations**.
A reusable SDV platform provides: * **Common, core software** that serves as the foundation for all vehicles. * **Tailored layers** that adapt the core software to specific models, features, or customer requirements, as illustrated by tailored components in the diagram. * **Interfaces and APIs** that standardize communication across components, ensuring modularity and ease of integration. By enabling software reuse and customization, organizations can: * Significantly reduce development costs and effort for new vehicle models. * Accelerate time-to-market for software features and updates. * Foster continuous improvements and innovation across platforms through shared software components. In summary, the development of a reusable SDV platform is key to achieving scalability, cost efficiency, and innovation. By combining end-to-end responsibilities, shift-left approaches, and the integration of MBSE and DevOps, organizations can build a robust, flexible foundation that drives sustainable success in the SDV era. # Incumbent OEMs vs EV Start-ups The SDV transformation highlights critical differences between **incumbent OEMs** and **disruptors**, as outlined in the table:
Incumbent OEMs, with their legacy systems and processes, focus on **cost optimization** and milestone-driven innovation. Their structures are often **siloed**, with slower, hierarchical decision-making. In contrast, disruptors embrace **value-driven innovation**, operate with **cross-functional teams**, and adopt agile, decentralized processes. Disruptors prioritize continuous feedback, shorter release cycles, and automated testing while unifying their CI/CD pipelines for consistency. #### Closing: Learning from Disruptors For incumbents to remain competitive in the SDV era, they must adopt key principles from disruptors, including agile decision-making, continuous feedback, and unified DevOps practices. At the same time, they must leverage their ability to **scale globally** and deliver products at the **highest quality**. Successfully merging these strengths will enable incumbents to innovate rapidly while maintaining the reliability and scale that have been their core competencies. # SDV201 The **SDV201** project is the successor to **SDV101**, offering a more advanced, hands-on exploration of Software-Defined Vehicles (SDVs). While **SDV101** provides a general introduction to SDVs aimed at a broad audience, including non-technical readers, **SDV201** targets individuals with a deeper interest in the technical aspects of SDV development. ## Key Goals and Focus The primary objective of SDV201 is to deliver a **practical, project-based learning experience**. Participants will engage in real-world SDV development tasks, requiring: * **Basic Programming Skills**: Some experience in coding (e.g., Python, C++) will be helpful. * **Embedded Hardware Knowledge**: Familiarity with basic hardware components and their integration. ## What SDV201 Will Cover SDV201 will provide a deep dive into the **digital.auto Playground** and the corresponding **E/E Starter Kit** developed by digital.auto. Participants will gain hands-on experience working with both hardware and software components of an SDV system. ## Project Timeline The SDV201 project is currently **work in progress**, with the goal of releasing a **solid beta version by summer 2025**. Content development, course structure, and supporting materials are actively being created by the digital.auto community. ## Get Involved If you are interested in **contributing to SDV201** or want to stay informed about project updates, **connect with us** through our **LinkedIn channel**:\ 👉 [Digital.auto LinkedIn](https://www.linkedin.com/company/79020337) Subscribe to the channel for the latest news and updates regarding the SDV201 project. # ./pulse The ./pulse driving the digital.auto revolution {% hint style="info" %} This is the beta version of the ./pulse framework. We are currently going through reviews and building up our ./pulse [advisory board](https://www.linkedin.com/feed/update/urn:li:activity:7308001628664512516/) with international experts from the different domains. Click [here](/pulse/community-and-meetups) to learn more about our community and meetups. {% endhint %} In an era where the automotive industry is transforming into a software-driven ecosystem, the **./pulse framework** introduces a pioneering **multi-speed delivery model**. This model is designed to bridge the gap between **traditional automotive standards** like **ISO 26262** and **ASPICE** and the **agile methodologies** shaping modern software development, including **SAFe**, **Scrum**, and more.

./pulse framework

The ./pulse framework ensures **seamless integration of safety-critical systems** with the iterative, fast-paced innovation cycles required for **software-defined vehicles (SDVs)**. By harmonizing these two paradigms, the framework empowers organizations to adopt **continuous delivery**, **real-time compliance**, and **collaborative engineering intelligence** across **mechanical, electrical/electronic (E/E), and digital domains**. The **multi-speed delivery model** of the **./pulse framework** allows different value streams to progress at tailored speeds, aligning with their unique risk profiles and planning horizons. Mechanical systems, such as chassis and body components, move at a slower pace due to their reliance on physical prototyping, extensive validation, and regulatory requirements, often requiring months to complete development cycles. Electrical/Electronic (E/E) systems operate at a medium pace, balancing hardware and software integration, and progressing in weeks through iterative simulation and testing. Digital/software systems, such as infotainment and user experience features, are highly agile, moving in days or even hours, leveraging continuous deployment and rapid iteration. The **./pulse framework** is designed to harmonize traditional automotive development with agile principles, enabling faster, more efficient, and compliant delivery of complex systems. It introduces key elements to streamline requirements, systems engineering, and continuous improvement across mechanical, E/E, and software domains. * **Lean Sourcing** * **LeanRM (Lean Requirement Management)**: Simplifies requirements management by focusing on value, reducing waste, and ensuring traceability at the speed of modern development. * **Supply Chain Management for SDVs** shifts from static, hardware-driven logistics to a modular, software-first ecosystem. It unbundles HW and SW, and enables agile contracts with fewer fixed requirements. * **SDV Systems Engineering** * **LeanSE (Lean Systems Engineering)**: Integrates systems engineering into agile workflows, balancing cross-domain dependencies while ensuring safety and compliance. * Combined with **SDVxMBSE**, which enables co-existence of model- and code-centric development. * **#DigitalFirst:** Integrates **Shift Left** (early validation, simulation, and CI/CD) with **Shift North** (moving business logic out of deeply embedded environments and embracing cloud-native DevOps). * **Loose coupling** in SDVs enables agility through an **API-first approach**, allowing independent development while ensuring seamless integration. **Freeze points** are balancing flexibility with system-wide stability, accelerating innovation without breaking compatibility. * **Intelligent Automation** * **CI/CD/CT Automation** accelerates development through DevOps for SDVs and highly automated development pipelines * **Engineering Intelligence** provides AI-powered insights and automation * **Continuous Homologation**: Ensures dynamic compliance with regulations by integrating homologation processes directly into iterative workflows. * **Build / Measure / Learn**: Embeds feedback loops across all phases to optimize processes, identify bottlenecks, and continuously enhance product quality and delivery speed. This framework empowers organizations to deliver safe, compliant, and innovative vehicles while adapting to the evolving demands of a software-driven world. # SDV Enabling **SDV Enabling** is the backbone of the ./pulse framework—the set of cross-cutting capabilities that turn bold architecture diagrams into real, revenue-generating vehicles. It spans hard numbers and investment logic, the culture and skills that power agile squads, the cloud-to-ECU toolchains that keep code flowing, the guard-rails that satisfy safety and regulators, and the partner ecosystem that accelerates innovation. In short: everything an OEM must line up before pressing the “go” button on a software-defined programme. ## Business & Investment Enablement * **Goal:** Provide a quantitative foundation for SDV decisions, from concept to post-sale services. * **Scope:** SHIFT business-case framework, portfolio ROI dashboards, scenario modelling, revenue-share logic for OTA features. * **Outcome:** Clear €/$ per vehicle, funding gates, and monetisation playbook accepted by CFO and strategy teams. ## People, Skills & Culture Enablement * **Goal:** Build the agile, cross-domain mindset and competencies SDV requires. * **Scope:** Upskilling pathways, micro-learning labs, talent rotation, culture campaigns, change-management KPIs. * **Outcome:** Workforce comfortable with continuous integration, cross-functional squads, and software-first thinking. ## Technical Platform & Toolchain Enablement * **Goal:** Deliver the hardware, software and DevSecOps pipelines that make fast iteration possible. * **Scope:** SDV reference compute, cloud/hybrid CI / CD / CT, simulation farms, BYOD test rigs, shared data lakes, AI co-pilot tooling. * **Outcome:** Reproducible builds, hour-level feedback loops, and self-service developer experience across E/E, cloud and mobile. ## Governance, Safety & Compliance Enablement * **Goal:** Ensure speed does not kill safety, security or regulatory approval. * **Scope:** Agile FuSa workflows, continuous homologation, cybersecurity policy, SLA guard-rails, audit-ready traceability. * **Outcome:** Releases that hit quarterly cadence **and** pass ISO 26262, UNECE R155/156, data-privacy and regional recalls with minimal friction. ## Ecosystem & Partner Enablement * **Goal:** Orchestrate suppliers, start-ups, and open-source communities in one coherent SDV programme. * **Scope:** API & data-licence models, joint road-mapping, app-store governance, co-engineering spaces, standards alignment. * **Outcome:** Faster feature onboarding, shared risk, and a plug-and-play marketplace that keeps the OEM core architecture clean. # SDV Business & Investment Enablement Creating great SDV tech is only half the challenge—funding it responsibly and proving its pay-off is the other half. Business & Investment Enablement equips decision-makers with hard numbers, repeatable models, and clear investment gates so they can prioritise features, size budgets, and justify ongoing updates throughout a vehicle’s life. Without this lens, SDV quickly turns into “cost to compete.” With it, the programme becomes a measurable value engine. ## **SHIFT – The SDV Business Case** A joint initiative by **KPMG, A2MAC1, BinaryCore, and Reusch Law** SHIFT (SDV **H**olistic **I**nvestment Framework for **T**ransformation) will be the first open model that quantifies both the **true cost** and the **real value** of SDV transformation across multiple vehicle generations. * **Why it matters**\ Legacy OEMs face agile SDV-native rivals and billion-euro write-offs. Digital add-on revenues remain elusive. SHIFT supplies a data-driven baseline so strategy and engineering can take informed bets instead of expensive guesses. * **What it delivers**\ *Top-down P\&L scenarios* vs. legacy E/E, *bottom-up TCO* from 900+ teardown datasets, feature-level lifecycle costing, and legally safe, anonymised data that any OEM can reuse. Future extensions will add interactive dashboards for what-if analysis and make-or-buy trade-offs. * **How it works**\ Finance modelling (KPMG) meets granular cost benchmarks (A2MAC1) and in-field feature economics (BinaryCore), all wrapped in an IP-safe governance shell (Reusch Law). The result: an investment playbook that can be shared, audited, and continuously refined. SHIFT will give CFOs, platform strategists, and procurement leads a common language—and the numbers—to steer SDV programmes with confidence. Watch this space! # SDV Culture ### Why Culture Matters in SDV Development The transition to Software-Defined Vehicles (SDVs) is more than just a technological shift—it’s a fundamental transformation in how the automotive industry operates. While methodologies, tools, and frameworks like **./pulse** provide the structure, the real enabler of change is **culture**. Without a shift in mindset, organizational structure, and ways of working, even the most advanced development models will fail to deliver the agility, quality, and compliance needed for SDVs. ### The SDV Mindset: From Legacy to Multi-Speed Traditional automotive development follows a linear, hardware-driven process where software is a late-stage integration effort. In contrast, SDVs require a **multi-speed delivery model**, where software evolves continuously while ensuring safety and compliance remain uncompromised. This shift demands that organizations: * Embrace **continuous iteration at China speed**, while maintaining the rigor of **first-time-right** safety validation. * Recognize that **ASPICE and ISO 26262** do not have to conflict with **Agile and DevOps**, but instead must be integrated into an adaptive workflow. * Foster **cross-functional collaboration**, where software, hardware, and regulatory teams work in tandem rather than in silos. ### Breaking Cultural Barriers Cultural inertia is one of the biggest obstacles to SDV transformation. Common barriers include: * **Resistance to Agile** – Many teams still view Agile as chaotic rather than structured. * **Slow decision-making** – Traditional hierarchies prevent rapid iteration and course correction. * **Separation of software and systems teams** – Hardware and software teams often work independently, leading to integration bottlenecks. Enabling SDV culture requires: * **Leadership commitment to change** – Executives must champion new ways of working. * **Psychological safety** – Teams need the freedom to experiment, fail, and improve. * **Data-driven decision-making** – Moving from gut feeling to measurable outcomes. ### The Shift from Component Owners to End-to-End Feature Ownership One of the most critical shifts in SDV development is moving from **component-based roles** to **end-to-end feature ownership**. In traditional ECU-centric organizations, engineers are responsible for specific hardware or software components, but this siloed approach creates inefficiencies in a software-driven world. #### **Why Is This Important?** * **End-to-end ownership** ensures that software and hardware evolve together to meet customer needs. * It enables **cross-functional collaboration**, breaking down barriers between component teams. * **Feature teams** can deliver updates faster, ensuring a more responsive and flexible vehicle development process. #### **Why Is This Difficult?** * Many engineers and managers are accustomed to **owning a specific ECU or subsystem**, making the shift to cross-domain thinking challenging. * It requires **restructuring teams and accountability**, which can be met with resistance. * **Compliance and safety responsibilities must be integrated across feature teams**, requiring a shift in validation and homologation processes. This transformation is **not just technical—it’s cultural**. Organizations that successfully adopt an **end-to-end feature ownership model** will be able to innovate faster, integrate compliance more effectively, and deliver **true software-defined experiences**. ## The Cultural Shift Beyond Engineering The transformation towards SDVs does not stop at the engineering organization. A true cultural shift must extend across the entire automotive value chain, including: * **Requirements Management (LeanRM):** Moving from static, document-heavy requirement processes to **dynamic, software-driven** requirement flows that adapt to continuous software development. * **Procurement:** Decoupling hardware and software sourcing strategies, introducing **virtual models in hardware RFPs**, and aligning supplier collaboration with agile and CI/CD principles. * **User Experience (UX):** Shifting towards **software-defined UX**, where continuous updates, data-driven personalization, and real-world feedback loops shape feature development. * **Testing & Validation:** Moving towards **virtual-first validation**, integrating digital twins, simulation, and AI-powered test automation. * **Homologation:** Shifting from a one-time regulatory certification mindset to **Continuous Homologation**, ensuring that compliance evolves with each software update rather than being a bottleneck at the end of development. Organizations that fail to extend cultural transformation beyond engineering will struggle with slow adoption, misaligned processes, and regulatory roadblocks that hinder true SDV progress. ### Organizing for SDV Success The structure of an organization determines its agility. Traditional models built around **project-based silos** are being replaced by **product-oriented, cross-functional teams**. SDV organizations are evolving towards: * **Platform and feature teams** – Developing software components independent of hardware release cycles. * **Compliance-integrated workflows** – Embedding regulatory and safety processes into CI/CD pipelines. * **Digital Twin-driven development** – Using virtualization to parallelize software and system validation. ### The Role of ./pulse in SDV Transformation The **./pulse** framework provides the backbone for this cultural shift by enabling: * **Fast iteration where possible, rigorous validation where necessary**. * **Parallel development of software and system validation** to reduce bottlenecks. * **A unified approach to ASPICE, ISO 26262, and Agile** to bridge compliance and innovation. ### Scaling the Culture Shift To make SDV transformation successful at scale, organizations must: * **Invest in capability building** – Upskilling teams in software, AI, and data-driven engineering. * **Establish KPIs for cultural transformation** – Measuring agility, quality, and compliance together. * **Encourage external collaboration** – Engaging with open-source ecosystems and digital.auto initiatives. ### Conclusion Culture is the foundation of SDV transformation. Without a mindset shift, organizations will struggle to balance speed and safety. The **./pulse** framework provides the structure, but real success depends on how teams adopt and integrate new ways of working. Those who embrace a **fast, adaptive, and compliance-aware culture** will lead the future of SDVs. # Lean Sourcing In the **multi-speed delivery model** of **./pulse**, where hardware and software evolve at different paces, **traditional sourcing and requirements processes become bottlenecks**. **Lean Sourcing** enables **modular, agile procurement** by **decoupling HW and SW**, supporting **just-in-time sourcing**, and aligning supplier contracts with **continuous integration cycles**. This approach **reduces dependencies, accelerates updates, and ensures supply chain resilience**, making it essential for **Software-Defined Vehicles (SDVs)**. * **Lean Requirement Management (LeanRM)** simplifies requirements management by **focusing on value, reducing waste, and ensuring traceability** at the speed of modern development. It replaces **rigid, document-heavy processes** with **adaptive, iterative requirement flows** that match the pace of SDV innovation. * **Supply Chain Management for SDVs** shifts from **static, hardware-driven logistics** to a **modular, software-first ecosystem**. It **unbundles HW and SW** and enables **agile contracts with fewer fixed requirements**, allowing for **faster integration, reduced risk, and better alignment with over-the-air (OTA) updates**. Together, these approaches create an **adaptive framework** that enables SDVs to evolve **continuously, efficiently, and at scale**. # LeanRM LeanRM (Lean Requirements Management) is an approach that applies Lean principles to the process of managing requirements in software and systems development. It aims to reduce waste, increase efficiency, and ensure continuous value delivery while maintaining compliance and traceability. ## Challenges with traditional RM Traditional Requirements Management (RM) in the automotive industry is struggling to keep up with the complexity of modern vehicle development.

Challenges with traditional RM

Vehicles can now require managing over a million requirements, spanning domains like mechanical, electrical, and software systems. This overwhelming volume has pushed traditional methods to their limits, making it increasingly difficult to track, prioritize, and validate requirements effectively. {% embed url="" %} Traceability, a cornerstone of requirements management, has become nearly impossible to maintain manually. With every requirement needing links to design, testing, and regulatory compliance, the process is not only time-consuming but also prone to errors. As the pace of development accelerates and regulations evolve, requirements often become outdated faster than they can be updated. This volatility exposes traditional processes as too rigid and slow to adapt to constant change. Automation is another critical gap. Many traditional approaches rely on manual efforts for test management, compliance validation, and change tracking. This lack of automation creates significant bottlenecks, increases the risk of human error, and limits the ability to scale to meet the demands of software-defined vehicles and agile development cycles. While traditional methods aim to ensure clear documentation, rigorous validation, and regulatory alignment, their document-heavy, manual nature is becoming unmanageable. The growing complexity of modern vehicles, the pressure to meet global safety and emissions standards, and the demand for faster innovation are rendering these approaches insufficient. To remain competitive, the automotive industry needs solutions that are scalable, adaptable, and automated, capable of bridging the gap between traditional frameworks and the agility of modern development methodologies. ## Introducing LeanRM Because of the many challenges with traditional requirements management, such as overwhelming complexity, lack of traceability, and slow adaptation to change, LeanRM offers a streamlined, value-focused approach to ensure efficiency, agility, and compliance in modern development. ### Key Aspects of LeanRM include: * Value-Driven Requirements – Focus on requirements that deliver real business or customer value. * Just-in-Time Requirements – Avoid excessive upfront documentation; instead, refine and prioritize requirements continuously. * Minimized Waste – Reduce unnecessary documentation, redundant approvals, and delays. * Iterative & Adaptive – Requirements evolve based on feedback, market changes, and testing insights. * Traceability Without Overhead – Use automation and lightweight tracking to ensure compliance without excessive bureaucracy. * Collaboration & Transparency – Engage cross-functional teams and stakeholders early and often. ### Traditional RM vs LeanRM Traditional Requirements Management (RM) focuses on exhaustive documentation and rigidity, while LeanRM emphasizes agility, value-driven prioritization, and minimizing waste to align with modern development needs.
### Relevance to SDVs and Continuous Homologation In Software-Defined Vehicles (SDVs) and Continuous Homologation, LeanRM aligns well by: * Ensuring regulatory compliance with minimal process overhead. Supporting incremental software updates with dynamic requirement validation. * Enhancing agility in managing cross-domain dependencies. * Leveraging automation and AI for smarter impact analysis and traceability. However, despite its benefits, applying MBSE to Software-Defined Vehicles (SDVs) presents unique challenges. SDV development often takes a **code-first approach**, emphasizing rapid software iteration and deployment over structured systems modeling. This can result in gaps in traceability and integration, particularly when balancing fast-moving software development cycles with the more deliberate pace of systems engineering. ## Outlook As an **OEM**, you can significantly reduce the **number of requirements** you actively manage by shifting responsibility while maintaining strategic control. This requires structuring **supplier relationships, interfaces, and compliance processes** in a way that ensures quality, safety, and regulatory compliance without micromanaging each individual requirement. This will be discussed in the next section. # Why so many Requirements? The number of requirements for a **new vehicle product line** varies widely based on complexity, regulatory needs, and market positioning. However, here are some general figures: 1. **Traditional Internal Combustion Engine (ICE) Vehicles** * **50,000 to 100,000+** requirements * Covers mechanical, electrical, regulatory, and safety aspects 2. **Electric Vehicles (EVs)** * **100,000 to 200,000+** requirements * Includes additional software, battery management, thermal management, and high-voltage safety 3. **Software-Defined Vehicles (SDVs)** * **200,000 to 500,000+** requirements * Higher complexity due to over-the-air (OTA) updates, software-based functionalities, connectivity, ADAS, and autonomy 4. **Highly Automated / Autonomous Vehicles** * **500,000 to 1,000,000+** requirements * Integrates AI-driven perception, sensor fusion, redundancy, fail-operational architectures, and extensive regulatory compliance In modern vehicle development, **40-60% of requirements are software-related**, and this share is increasing with SDVs. OEMs rely on **requirement management tools** (e.g., Polarion, DOORS, Codebeamer) to track and validate these requirements across product lines. ### **Example: Airbags** The Airbag sub-systems of a car can easily have 50,000-80,000 requirements associated with them. Here is why ### **1. Functional Requirements** * **Deployment Logic:** When should the airbag deploy? (E.g., frontal impact > 25 km/h) * **Multi-stage Deployment:** Different force levels depending on crash severity. * **Passenger Sensing:** Detecting occupants (adult, child, empty seat). * **Side Airbags & Curtain Airbags:** Coordinated deployment in different crash scenarios. *** ### **2. Safety & Redundancy** * **Redundant Triggering Circuits:** Prevent false positives/negatives. * **Fail-Safe Mechanisms:** System must self-diagnose failures. * **Sensor Fusion:** Integration with accelerometers, gyroscopes, and radar. *** ### **3. Regulatory & Compliance Requirements** * **FMVSS 208 (USA):** Occupant crash protection standards. * **UNECE R94/R95 (Europe):** Frontal & lateral impact regulations. * **China NCAP, Euro NCAP, IIHS:** Different rating system compliance. *** ### **4. Hardware & Material Constraints** * **Inflator Chemistry:** Must be stable under various temperatures. * **Fabric Strength:** Must resist wear and environmental degradation. * **Connector Reliability:** Must withstand vibration and corrosion. *** ### **5. Integration with Other Systems** * **Seatbelt Pretensioners:** Airbag must coordinate with them. * **ADAS (Advanced Driver Assistance Systems):** Adjustments based on predicted impact. * **Vehicle Architecture:** Different requirements for SUVs vs. sedans. *** ### **6. Software & Communication Protocols** * **CAN Bus Messaging:** Ensure proper timing of deployment signals. * **OTA Updates:** Requirements for software-based calibration. * **Self-Diagnostics & Logging:** Error codes, sensor failures, and remote monitoring. *** ### **7. Testing & Validation** * **Crash Test Scenarios:** Dozens of crash speeds, angles, and occupant sizes. * **Environmental Testing:** Extreme heat/cold, humidity, aging simulation. * **End-of-Line Testing:** Every unit must pass factory quality control. *** #### **Why 80,000+ Requirements?** Each of these **top-level requirements** branches into **hundreds of sub-requirements**, covering: * **Component-level details** (e.g., inflator pressure curve specs). * **Software constraints** (e.g., real-time response deadlines). * **Testing conditions** (e.g., crash test dummies of different weights). * **Country-specific compliance differences**. # SCM for SDVs SCM4SDVs is a lightweight, adaptive supply chain model designed for software-defined vehicles (SDVs). It removes inefficiencies, reduces dependencies on rigid release cycles, and aligns supply logistics with software-first development. ## **Core Principles of SCM4SDVs** 1. **HW/SW Unbundling** * Software and hardware evolve **independently** with modular integration points. * Suppliers provide **pre-validated digital twins** of hardware, enabling early software development. 2. **Agile Contracts & Fewer Fixed Requirements** * Suppliers commit to **capability-based contracts**, not just fixed deliveries. * Software updates and hardware iterations occur **asynchronously** with fewer, more flexible requirement checkpoints. 3. **Just-in-Time SW/HW Integration** * Software development aligns with **virtual hardware** before physical hardware is even shipped. * Cloud-based pre-integration ensures readiness before final assembly. 4. **Event-Driven, Demand-Synchronized Logistics** * **Real-time telemetry** from SDV production lines triggers dynamic material flow. * Predictive analytics **pre-orders components** based on software-defined feature demand. 5. **Lean Validation & Digital Homologation** * Continuous compliance checks **digitally verify** regulatory conformity. * Automated homologation pipelines reduce time-to-market for software-defined components. #### **SCM4SDVs in Action:** ✅ **Tier 1 supplies digital twins of ECUs before hardware ships.**\ ✅ **OTA-ready software releases allow continuous updates, independent of hardware refresh cycles.**\ ✅ **Contracts focus on "capability delivery" instead of rigid requirements.**\ ✅ **Reduced requirement checkpoints and homologation bottlenecks enable software-defined flexibility.** SCM4SDVs **optimizes SDV supply chains by making them modular, software-driven, and real-time adaptive**—moving beyond traditional linear automotive logistics. ## Five Key Strategies OEMs can minimize managed requirements by outsourcing system responsibility to suppliers, enforcing standardized interfaces, leveraging pre-certified components, adopting simulation-driven validation, and utilizing third-party compliance services. ### **1. Black-Box Outsourcing (Supplier-Owned Responsibility)** * **Concept:** Shift full responsibility for specific systems or components to a **Tier 1 supplier**, treating them as a **black box** where you only define high-level requirements and expected performance outcomes. * **How It Works:** * The supplier provides a **fully developed, validated, and homologated system**. * The supplier is contractually required to meet all **functional, safety, and regulatory standards**. * OEM only manages **interface requirements** and **system integration**. * **Example:** * Instead of managing **80,000 airbag system requirements**, OEM defines: * Deployment speed * Crash test compliance (UNECE, FMVSS) * Electrical interface * The **supplier handles the rest**. * **Impact on Supplier Relations:** * Requires **strong trust and contractual oversight**. * OEM **audits** supplier processes instead of managing detailed requirements. * Increases reliance on Tier 1 suppliers’ **engineering expertise**. **✅ Pros:** Low internal complexity, fast time-to-market.\ **❌ Cons:** Less control over deep technical details and customizations. *** ### **2. Standardized Interfaces & Modularity** * **Concept:** Define **clear, standardized interfaces** that allow suppliers to develop components independently, reducing the number of requirements managed at the OEM level. * **How It Works:** * OEM defines **hardware and software interfaces** but not the internal logic of components. * Suppliers deliver **pre-certified modules** that integrate seamlessly. * Use industry standards to avoid custom requirement sets. * **Example:** * **Software-defined vehicles (SDVs)** can use **COVESA VSS for software interfaces**, allowing plug-and-play ECUs. * **AUTOSAR-based ECUs** standardize communication between vehicle domains. * **Battery systems** following standardized charging interfaces (ISO 15118). * **Impact on Supplier Relations:** * Encourages **competition among suppliers** (plug-and-play components). * Requires **OEM enforcement of interface specifications**. * Reduces long-term supplier lock-in. **✅ Pros:** Highly scalable, allows multiple supplier options.\ **❌ Cons:** Requires strong interface governance. *** ### **3. Pre-Certified & Homologation-Ready Systems** * **Concept:** Work with suppliers who deliver components and systems that are already pre-tested and pre-certified for regulatory compliance. * **How It Works:** * OEM specifies only **regulatory requirements** and expected **performance**. * Supplier provides **certified solutions** with documentation for homologation. * **Example:** * ADAS system suppliers ensure **UNECE R79 (steering), R152 (AEB), and FMVSS compliance** before delivery. * Tier 1 suppliers provide **ISO 26262 ASIL-D safety cases** for ECUs without OEM involvement in every detail. * **Impact on Supplier Relations:** * Increases supplier responsibility for compliance. * Reduces need for OEM-internal homologation efforts. * Requires **legal and contractual frameworks** for liability sharing. **✅ Pros:** Reduces homologation complexity at OEM level.\ **❌ Cons:** Supplier selection must be rigorous. *** ### **4. Virtual Validation & Digital Twin-Based Homologation** * **Concept:** Use **simulation, AI, and digital twins** to reduce physical testing and requirement documentation. * **How It Works:** * Define **high-level functional requirements** and verify them via **virtual models** instead of manual requirement decomposition. * Suppliers provide **simulation-based proof of compliance**. * AI-driven **requirements management tools** suggest and track regulatory changes. * **Example:** * Using **virtual crash testing** to verify airbag compliance instead of managing thousands of test conditions manually. * Using AI to **auto-map regulatory updates** to existing requirement sets. * **Impact on Supplier Relations:** * Requires suppliers to provide **simulation models**. * Reduces dependence on **physical prototyping**. * Shifts verification from **physical testing to software validation**. **✅ Pros:** Reduces test complexity, faster compliance.\ **❌ Cons:** Requires investment in **simulation infrastructure**. *** ### **5. Regulatory Compliance as a Service (RaaS)** * **Concept:** Outsource regulatory tracking, compliance, and homologation documentation to specialized third-party services. * **How It Works:** * OEM only **defines vehicle-level compliance goals**. * Third-party experts handle **legal interpretation, requirement updates, and certification**. * Suppliers deliver **pre-certified components** validated by these services. * **Example:** * **KPMG, TÜV, or DEKRA** handle regulatory approvals. * Third-party AI tools continuously track **UNECE, FMVSS, ISO** updates. * **Impact on Supplier Relations:** * Simplifies compliance management for OEMs. * Reduces **in-house regulatory tracking** needs. * Requires **partnerships with homologation experts**. **✅ Pros:** Reduces complexity of regulatory tracking.\ **❌ Cons:** Adds external dependency. ## Summary: Choosing the right approach
# SDV Systems Engineering **SDV Systems Engineering** combines **LeanSE** and **SDVxMBSE** to enable **agile, model-driven development** while maintaining **safety, compliance, and cross-domain coordination**. * **LeanSE** integrates **systems engineering into agile workflows**, managing dependencies efficiently without slowing innovation. * **SDVxMBSE** ensures the **co-existence of model- and code-centric development**, with **VHAL as the bridge**, enabling early validation, simulation, and continuous integration. This approach streamlines **feature development, verification, and integration**, aligning **systems thinking with the fast-paced SDV lifecycle**. # LeanSE ## Systems Engineering Systems Engineering (SE) is the backbone of complex vehicle development, ensuring that all components and systems work together harmoniously. In the automotive industry, SE enables the management of complexity across multiple domains and ensures that vehicles meet safety, functional, and performance requirements. Model-Based Systems Engineering (MBSE) is a modern approach to Systems Engineering that replaces traditional document-driven processes with digital models to design, analyze, and validate complex systems. By using tools like SysML and other modeling frameworks, MBSE enables the creation of a unified, visual representation of system architectures, requirements, behaviors, and interactions across domains. While MBSE (Model-Based Systems Engineering) and SE (Systems Engineering) are closely related, they should not be used interchangeably, even if no OEM is relying on paper-based SE anymore. The distinction lies in **scope, methodology, and tools**. Systems Engineering is the broader discipline that defines the principles, processes, and methodologies for developing complex systems. MBSE is a **specific approach within SE** that replaces traditional document-based processes with model-driven practices. SE includes activities that may not always involve models, such as stakeholder communication, conceptual design, and high-level trade-off analyses. MBSE, by contrast, focuses on creating and leveraging digital models to support these activities. ### **Functions of Systems Engineering in Automotive** The core functions of SE are critical to managing complexity and ensuring system-level integration: * **Requirements Management**: Defines, tracks, and verifies requirements across mechanical, electrical, and software domains, ensuring compliance with regulations. * **System Architecture Definition**: Establishes a blueprint for how various subsystems interact, balancing performance, safety, and scalability. * **Integration Planning**: Ensures smooth assembly and interoperability of components from Tier 1 and Tier 2 suppliers. * **Validation and Verification**: Ensures systems meet defined requirements through simulation, testing, and compliance checks. * **Risk Analysis and Mitigation**: Identifies potential system failures, enabling proactive measures to ensure safety and reliability. ### **Domains Covered by Systems Engineering** SE spans across critical automotive domains, ensuring holistic development: * **Mechanical**: Chassis, body design, and structural safety. * **Electrical/Electronic (E/E)**: Wiring harnesses, sensors, and ECUs. * **Software**: Functional safety, over-the-air updates, and user interfaces. * **Cross-Domain Systems**: Integration of ADAS, powertrain, and infotainment into unified vehicle systems. ### **Roles in Systems Engineering** Systems Engineering requires a multidisciplinary team: * **System Architects**: Design high-level system structures and interactions. * **Safety Engineers**: Ensure compliance with ISO 26262 and other safety standards. * **Integration Specialists**: Bridge gaps between hardware, software, and supplier components. * **Validation Teams**: Conduct end-to-end testing and homologation. ### **Challenges in Adopting Systems Engineering** Despite its importance, SE adoption faces significant barriers in the rapidly evolving automotive landscape. **Managing Complexity** Modern vehicles are more complex than ever, with over a million requirements, thousands of components, and increasingly software-centric architectures. Traditional SE practices struggle to keep pace with the explosion of data and dependencies. **Balancing Rigidity and Agility** Traditional SE methodologies are inherently rigid, relying on extensive upfront planning. This clashes with agile practices that dominate software development, creating friction between iterative workflows and system-level predictability. **Heterogeneous Tool Landscapes** OEMs often rely on fragmented tools for requirements management (e.g., DOORS), architecture design (e.g., SysML), and testing. These siloed systems make collaboration and traceability challenging, leading to inefficiencies and data inconsistencies. **Maturity Levels of OEMs** Most incumbent OEMs struggle with adapting SE to support agile software development, while BEV start-ups like Tesla and Rivian bypass traditional practices in favor of leaner, software-first approaches that inherently embed systems thinking into their workflows. ## **Introducing Lean Systems Engineering (LeanSE)** To address these challenges, LeanSE applies **Lean principles** to Systems Engineering, focusing on efficiency, value delivery, and adaptability. ### **What is LeanSE?** LeanSE redefines Systems Engineering by prioritizing simplicity, waste reduction, and iterative improvement. It integrates well with agile frameworks, making it ideal for modern software-defined vehicles. ### **Benefits of LeanSE** LeanSE bridges the gap between traditional SE and agile practices, providing: * **Faster Development Cycles**: Aligns SE workflows with iterative software releases. * **Enhanced Collaboration**: Encourages cross-functional teamwork through shared models and real-time updates. * **Improved Traceability**: Automates traceability and compliance checks, reducing manual effort. * **Scalability**: Adapts to the varying complexity of mechanical, E/E, and software systems. * **Cost Efficiency**: Reduces waste by focusing only on high-value activities. ### **Adoption** Adoption of LeanSE is growing, with BEV start-ups like Tesla, NIO, and Rivian leading the charge. These companies leverage LeanSE to integrate systems thinking directly into their software-first development pipelines. Incumbent OEMs, while slower to adapt, are increasingly adopting LeanSE to modernize their workflows and remain competitive. LeanSE adoption highlights clear differences between traditional OEMs and BEV start-ups. **Incumbent OEMs** * Often rely on rigid, document-heavy SE processes. * Face challenges integrating SE with agile and software development practices. * Gradually adopting LeanSE to streamline cross-domain collaboration and improve efficiency. **BEV Start-Ups** * Embrace LeanSE from the outset, with minimal legacy processes or tools. * Leverage software-first development pipelines to embed SE naturally. * Use leaner, faster workflows to rapidly iterate on features and systems. ## **Conclusion** Systems Engineering is essential for managing the complexity of modern vehicles, but traditional approaches face challenges in the software-driven era. LeanSE offers a way forward, enabling OEMs to streamline workflows, improve collaboration, and adapt to the demands of agile development. By adopting LeanSE, automotive companies can remain competitive and deliver innovative, safe, and compliant vehicles at the speed of modern development. # SDVxMBSE Despite its benefits, applying MBSE directly to Software-Defined Vehicles (SDVs) presents unique challenges. SDV development often takes a **code-first approach**, emphasizing rapid software iteration and deployment over structured systems modeling. This means we need to be balancing fast-moving software development cycles with the more deliberate pace of systems engineering. ## **Bridging Model-Centric and Code-Centric Development** The integration of **Model-Based Systems Engineering (MBSE)** with the fast-paced, software-first approach of **Software-Defined Vehicles (SDVs)** is reshaping how modern vehicles are designed and developed. The diagram illustrates the distinct characteristics of these two paradigms and the critical role of the Vehicle Abstraction Layer (VHAL) in bridging them.

SDVxMBSE

## **Holistic Perspectives through Systems Engineering** Systems Engineering (SE) provides a holistic perspective on vehicle development by ensuring the integration of all subsystems—mechanical, electrical, and software—into a cohesive whole. MBSE, as a modern implementation of SE, excels in managing the **slower-evolving domains** of vehicle design. These include: * **Mechanical Components**: Structural elements like the chassis and body that undergo minimal iteration once production tooling begins. * **Deeply Embedded Software**: Safety-critical functionalities (e.g., airbag deployment logic or braking systems) requiring strict compliance with standards like ISO 26262. These systems are tightly coupled with hardware and evolve cautiously to maintain reliability and safety. MBSE offers rigor, traceability, and compliance assurance for these slower-moving elements, ensuring their alignment with overall system goals. However, its inherently structured and model-centric approach can limit flexibility when addressing the rapid iteration cycles characteristic of SDVs. ## **The Code-Centric Nature of SDVs** In contrast to the structured pace of MBSE, SDVs operate at a much faster cadence, driven by: * **Cloud-Connected Software**: Features like infotainment, personalized user experiences, and connected services evolve rapidly, often updated over-the-air (OTA). * **AI-Driven Capabilities**: Systems such as predictive maintenance or autonomous driving algorithms adapt dynamically based on new data and training cycles. * **Lower Safety-Criticality**: Many SDV features prioritize innovation and usability over strict safety requirements, allowing for greater experimentation and faster iteration. This faster evolution of SDV-related features demands agility, continuous integration, and deployment practices that are not traditionally supported by MBSE workflows. ## **VHAL: Aligning the Two Worlds** The **Vehicle Abstraction Layer (VHAL)** serves as a critical bridge between the model-centric world of MBSE and the code-centric perspective of SDVs. VHAL standardizes the interactions between physical components and software-defined functionalities, enabling: * **Design-Time Alignment**: By defining clear interfaces between mechanical, embedded systems, and cloud-based functionalities, VHAL ensures that these domains can be developed and validated in parallel. * **System Coherence**: VHAL allows code-centric features to evolve independently while maintaining alignment with the slower-moving systems managed through MBSE. * **Scalability**: By abstracting the complexity of hardware, VHAL empowers faster, modular updates in SDV features without disrupting deeply embedded systems. ## **SDVxMBSE: An Emerging Practice** **SDVxMBSE** represents the convergence of these two paradigms, combining the strengths of MBSE’s rigorous, model-driven processes with the agility and speed of SDV development. It leverages VHAL and other alignment mechanisms to: * **Harmonize Workflows**: Ensures that the system-level perspectives from MBSE are reflected in the rapid evolution of SDV functionalities. * **Enable Parallel Development**: Facilitates simultaneous progress in hardware-centric and software-centric domains without delays or misalignment. * **Enhance Agility with Compliance**: Balances the need for safety and reliability in embedded systems with the flexibility to innovate rapidly in non-critical domains. ## **Conclusion** The integration of MBSE and SDVs into the **SDVxMBSE** paradigm is not just a technical evolution—it is a necessary practice to manage the complexities of modern automotive development. By bridging the model-centric rigor of MBSE with the agility of code-centric SDVs, this approach ensures that vehicles can meet the demands of safety, innovation, and user experience simultaneously. The VHAL plays a pivotal role in this alignment, enabling faster, more collaborative development cycles while maintaining system coherence. As this practice matures, SDVxMBSE will become the foundation for the next generation of intelligent, connected vehicles. # Digital First The #DigitalFirst approach builds on two foundational strategies for achieving efficiency and agility in software-defined vehicle (SDV) development: **shift north** and **shift left**, as illustrated in the diagram. Traditionally, the term "shift north" refers to moving functionality upward in the architectural stack, north of the Vehicle Hardware Abstraction Layer (VHAL). However, in this context, "shift north" is also about **organizational decoupling**. By separating fast, agile value streams from the slower, safety-critical processes, organizations can enable multi-speed development. Agile streams focus on continuous improvement, while safety-critical streams emphasize stability and reliability, both coexisting yet independently evolving above and below the VHAL. "Shift left," on the other hand, emphasizes **early testing and validation in digital environments**, significantly reducing dependencies on physical prototypes and test setups. By simulating and validating designs earlier in the development process, organizations can avoid costly delays and streamline time-to-market.
Together, these shifts enable a digital-first mindset, where decoupled processes and early testing empower teams to move faster and innovate while maintaining quality and safety. {% embed url="" %} # Loose Coupling **Loose coupling** in SDVs ensures modularity by **decoupling software from hardware dependencies**, enabling faster updates and scalability. An **API-first approach** allows components to communicate via well-defined interfaces, reducing direct dependencies and enabling parallel development. **Freeze points** define stable integration layers, ensuring that while internal components evolve independently, system-wide compatibility is maintained. This balance between flexibility and stability accelerates innovation while preserving reliability in software-defined architectures. # API-first An **API-first approach** is a critical enabler of the **./pulse framework**, driving modularity, scalability, and seamless collaboration across mechanical, E/E, and digital domains. APIs not only allow for loosely coupled architectures but also foster loosely coupled organizations, enabling diverse teams to innovate at different speeds without breaking system cohesion. To fully leverage APIs, it is essential to understand their types and how they align with the **SDVxMBSE architectural layering**. ## API-first: Lessons Learned from the Internet Folks APIs - short for Application Programming Interfaces - are seen by many in the industry as the key enabler for the Internet as we know it today. A famous anecdote in the tech world involves then-CEO Jeff Bezos reportedly mandating that all teams at Amazon expose their data and functionality through **Application Programming Interfaces (APIs)**. The SDV Guide provides a more detailed overview of APIs and how they enable modern microservice architectures. {% embed url="" %} ## **Types of APIs in Software-Defined Vehicles (SDVs)** Different types of APIs serve specific roles in connecting systems and enabling cross-domain interactions. Vehicle APIs are the foundation for Vehicle Service-oriented Architectures (SOA). The following provides an overview of the different types of Vehicle APIs most commonly found: 1. **REST-Based Vehicle-to-Cloud APIs** * **Purpose**: Connect the vehicle with external cloud services, enabling remote monitoring, OTA updates, and user applications. * **Examples**: APIs for retrieving vehicle telemetry data, enabling remote start/stop, or scheduling maintenance services. * **Role in Architecture**: Operates at the **cloud interface layer**, facilitating communication between the vehicle and external ecosystems. 2. **Signal-to-Service APIs** * **Purpose**: Provide higher-level onboard service abstractions, allowing digital applications to interact with the embedded layer through service-based interfaces. * **Examples**: APIs for high-level functions like "open door" or "adjust climate," which translate user commands into embedded signal operations. * **Role in Architecture**: Resides at the **service layer** in SDVxMBSE, bridging application logic with embedded system functionality. 3. **Embedded-to-Embedded APIs** * **Purpose**: Enable communication between embedded systems, such as ECUs, within the vehicle. * **Examples**: APIs facilitating interactions between a door motor controller and the body control module for coordinated functionality. * **Role in Architecture**: Functions within the **embedded systems layer**, ensuring low-latency and deterministic communication for safety-critical operations. 4. **Software-to-Hardware APIs** * **Purpose**: Abstract hardware-specific details, allowing software components to interact with actuators, sensors, or other hardware components without requiring hardware-specific knowledge. * **Examples**: APIs for controlling hardware like motors, cameras, or LiDAR systems, abstracting commands into standardized calls. * **Role in Architecture**: Operates at the **hardware abstraction layer (HAL)**, providing a standardized interface to physical components. For a more detailed discussion, including safety aspects, refer to the SDV Guide. {% embed url="" %} ## **Aligning API Types with the Vehicle SOA** The **Vehicle SOA** integrates APIs into a layered architecture to ensure consistency and traceability across the system. Each API type maps to a specific architectural layer in the vehicle SOA: * **Cloud Interface Layer**: REST-based APIs connect vehicles to the cloud, enabling external applications to access vehicle functions and data. These APIs are essential for maintaining user-centric features and seamless OTA updates. * **Service Layer**: Signal-to-Service APIs provide a high-level abstraction for SDV features, enabling modular digital applications to interact with embedded systems without requiring detailed knowledge of signals or hardware. * **Embedded Systems Layer**: Embedded-to-Embedded APIs manage low-level interactions between ECUs, ensuring real-time coordination for safety-critical and functional systems. * **Hardware Abstraction Layer (HAL)**: Software-to-Hardware APIs allow the digital layer to interact with physical components through standardized interfaces, reducing complexity and enabling modular hardware upgrades. This alignment ensures that APIs are not designed in isolation but as part of an integrated system architecture, enabling seamless interaction between the code-centric and model-centric layers. {% embed url="" %} ## **Importance of APIs for Loosely Coupled Architectures** APIs are vital for creating **loosely coupled architectures** by abstracting system complexity and defining clear interaction boundaries. This decoupling allows individual subsystems to evolve independently, ensuring: * **Parallel Development**: Teams working on mechanical, E/E, and digital systems can progress simultaneously, knowing that APIs will standardize integration. * **Rapid Iteration**: Faster-moving digital systems can iterate and deploy updates without disrupting slower-moving hardware or embedded systems. * **System Scalability**: Modular APIs make it easier to scale features across vehicle platforms or integrate new services without reworking existing components. ## **Importance of APIs for Loosely Coupled Organizations** In addition to architectural benefits, APIs support **loosely coupled organizations** by enabling efficient collaboration across diverse teams and suppliers. Key advantages include: * **Clear Collaboration Boundaries**: APIs act as contracts between teams, reducing the need for constant cross-team alignment and allowing for independent development. * **Supplier Integration**: For OEMs working with multiple suppliers, APIs standardize how third-party components integrate into the broader system, reducing onboarding times and ensuring compatibility. * **Global Coordination**: In distributed development environments, APIs provide a shared framework, enabling geographically dispersed teams to work together effectively. ## **Example: API-First Approach for a Motorized Door System** To illustrate the importance of API-first principles, consider a **motorized door system** supporting features like **passenger welcome sequences** and **on-site maintenance services**. * **REST-Based Vehicle-to-Cloud API**: Enables remote control of the door (e.g., opening the door via a mobile app) and provides telemetry data for predictive maintenance. * **Signal-to-Service API**: Abstracts the "open door" and "close door" commands into high-level functions, allowing the passenger welcome system to interact seamlessly with the embedded layer. * **Embedded-to-Embedded API**: Facilitates communication between the door ECU and the body control module, ensuring that door locking mechanisms synchronize with other safety systems. * **Software-to-Hardware API**: Abstracts control of the door motor, providing a standardized interface for adjusting speed or force thresholds during door operation. This example highlights how APIs align with the architectural layers and enable decoupling. For instance, freezing the **Embedded-to-Embedded API** and the **Software-to-Hardware API** early ensures stability for hardware and embedded systems, while allowing the REST-based and Signal-to-Service APIs to evolve rapidly to support new digital features. For more details, refer to the SDV Guide {% embed url="" %} ## **The Evolution of Vehicle API Adoption by OEMs** As software-defined vehicles (SDVs) become more advanced, automakers are increasingly adopting APIs to enable connectivity, automation, and new business models. This evolution has occurred in distinct stages, each introducing new opportunities and challenges. ### **1. Internal API Use: Vehicle-to-Cloud and On-Board APIs** The first stage of vehicle API adoption focuses on **internal use by the OEM**, primarily for improving operational efficiency and delivering cloud-based services. * **Vehicle-to-Cloud (V2C) APIs** are typically the first to be implemented. They enable secure data exchange between the vehicle and OEM-operated cloud services, supporting features such as predictive maintenance, remote diagnostics, over-the-air (OTA) updates, and fleet management. * **On-Board APIs**, such as those based on the COVESA Vehicle Signal Specification (VSS), provide a structured way to interact with vehicle data and functions. However, their adoption is often slower due to their deep integration with vehicle electronics and electrical (E/E) architectures. At this stage, APIs remain private, ensuring that only OEM-approved software interacts with vehicle systems. ### **2. Selective API Access for Partners** The next stage involves **opening API access to a limited number of external partners**, enabling new business models while maintaining control over security and compliance. * A common use case is **usage-based insurance (UBI)**, where an OEM provides an insurance company with access to vehicle telematics to determine policy pricing based on driving behavior. * Other potential partners include **roadside assistance providers, fleet operators, and smart home integrations**, which require controlled access to specific vehicle data points. Since exposing APIs introduces security and liability risks, OEMs typically grant access **only to a small number of trusted partners**, often large corporations that have the financial and legal standing to be held accountable. This cautious approach ensures that potential misuse or vulnerabilities can be managed effectively. {% embed url="" %} {% embed url="" %} ### **3. Open Vehicle App Stores and Third-Party Application Deployment** As consumer demand for in-vehicle digital services grows, OEMs are moving toward **vehicle app stores**, allowing third-party developers to create and deploy applications directly onto vehicles. This shift requires: * A **secure application runtime environment** that ensures apps cannot interfere with core vehicle functions or compromise safety. * **Granular API access controls**, where applications only receive the specific data and functionality they require. * **A structured approval process** to validate applications before deployment, similar to mobile app stores. At this stage, automakers must balance **innovation and security**, ensuring that opening API access does not expose vehicles to cyber threats or operational risks. {% embed url="" %} ### **4. Bring Your Own Device (BYOD) and the Integration of Custom Hardware Gadgets** The most advanced stage of API adoption extends beyond software, allowing consumers to integrate **custom hardware gadgets** with their vehicles. This approach, often seen in consumer electronics brands like **Xiaomi with the SU7**, combines: * **A software app store** that enables third-party apps to interact with vehicle APIs. * **Custom hardware modules** that connect to the vehicle, either through standard interfaces (such as USB-C or Bluetooth) or through OEM-provided expansion slots. This model transforms vehicles into **platforms for both software and hardware innovation**, enabling users to personalize their driving experience with aftermarket components, from custom infotainment systems to smart driving assistants. ### **Conclusion** The adoption of vehicle APIs by OEMs follows a clear progression, from internal use to selective partnerships, open application ecosystems, and finally, consumer-driven hardware integration. Each stage requires increasing levels of security, regulatory compliance, and business model adaptation. As the industry moves toward **fully software-defined and connected vehicles**, API strategy will become a core differentiator for OEMs, determining their ability to support innovation while ensuring safety and reliability. ## **Alignment with the ./pulse Framework** The API-first approach aligns closely with other elements of the **./pulse framework**, ensuring consistency and efficiency across domains: 1. **LeanRM**\ APIs streamline requirements management by acting as a bridge between high-level requirements and technical implementation. This reduces redundancy and simplifies traceability, ensuring that only high-value requirements are prioritized. 2. **LeanSE (Systems Engineering)**\ By defining clear interaction boundaries, APIs reduce complexity in systems engineering and enable cross-domain alignment. They act as a common language between mechanical, E/E, and digital systems, facilitating integration. 3. **Freeze Points**\ APIs serve as stable interaction points between subsystems, allowing hardware and slower-evolving domains to freeze their designs while enabling continuous iteration in faster-moving digital layers. For instance, an API for door control can be frozen early, even if the digital services leveraging it continue to evolve. 4. **CI/CD/CT Automation and Engineering Intelligence**\ APIs enable automated integration and testing pipelines by providing well-defined interfaces for validation. They support virtual validation and simulation, accelerating development and ensuring quality. 5. **Continuous Homologation (CoHo)**\ APIs simplify homologation by providing a consistent framework for mapping feature updates to regulatory requirements, enabling faster and more reliable compliance validation. 6. **Measure / Learn**\ By exposing telemetry and diagnostic data through APIs, teams can create real-time feedback loops to optimize system performance and user experience. ## **Conclusion** An API-first approach is a foundational element of the **./pulse framework**, enabling modularity, scalability, and collaboration across architectures and organizations. By defining APIs across the cloud interface, service, embedded, and hardware abstraction layers, the framework ensures seamless interaction between the code-centric and model-centric worlds. This approach supports loosely coupled architectures, allowing subsystems to evolve independently, and loosely coupled organizations, enabling diverse teams to collaborate efficiently. As SDVs continue to evolve, API-first principles will remain essential for driving innovation while maintaining system coherence and agility. 4o # Freeze Points In the **multi-speed delivery model** introduced by the **./pulse framework**, **freeze points** serve as critical alignment mechanisms between domains that evolve at different speeds. They act as decision checkpoints to stabilize specific aspects of a system's design, ensuring consistency and feasibility across mechanical, electrical/electronic (E/E), and digital layers of development. ## **Why Freeze Points Are Needed** Freeze points are essential for managing the complexities of modern vehicle development, where interconnected systems evolve at different cadences: * **Coordination Across Domains**: Decisions in one domain, such as mechanical design, often have cascading effects on others, like software or E/E systems. * **Resource Planning and Commitment**: Certain decisions, such as hardware choices, require long-term commitments that involve procurement, factory tooling, and supplier contracts. * **Mitigating Risks**: Freezing key elements ensures stability, preventing costly rework or integration issues as faster-moving domains, like software, iterate. * **Regulatory and Safety Compliance**: For safety-critical systems, freeze points help ensure that standards like ISO 26262 are adhered to without constant disruptions from late-stage changes. ## **Forms of Freeze Points** Freeze points can take on various forms, depending on the domain and the nature of the development process: * **Digital Freeze Points**: These focus on software features, APIs, and system architecture. They may define key elements such as: * Core APIs for subsystems (e.g., a "door open" API). * Fixed software module interfaces to ensure compatibility with embedded systems. * Base functionality for features that cannot be modified via OTA updates due to safety or regulatory constraints. * **E/E Freeze Points**: Electrical and electronic systems require freeze points to lock down: * Hardware interfaces, such as connectors and wiring harnesses, to ensure compatibility with downstream systems. * ECU (Electronic Control Unit) specifications, including memory, processing power, and safety-critical software components. * **Mechanical Freeze Points**: These are long-term commitments involving physical components that are costly and time-consuming to modify. Examples include: * Decisions to include motors, actuators, or other physical elements in a design. * Structural reinforcements to accommodate specific features. * Factory tooling and assembly line adjustments for new hardware. ## **Freeze Points in Agile Frameworks** Frameworks like **SAFe (Scaled Agile Framework)** adopt the concept of **freeze points** to balance agility with stability in large-scale software and system development. While agile methodologies emphasize continuous iteration and flexibility, complex industries like automotive and aerospace require **structured milestones where certain decisions, architectures, or interfaces are locked in** to prevent uncontrolled changes. In SAFe, this is often implemented through **Program Increments (PIs)** and **Solution Trains**, where key components are stabilized before the next iteration, ensuring dependencies between teams remain manageable. These freeze points help organizations **maintain regulatory compliance, align hardware and software development cycles, and reduce integration risks**, making them essential for domains like software-defined vehicles (SDVs), where iterative updates must coexist with fixed safety-critical elements. ## **Freeze Points in a Multi-Speed Delivery Model** Freeze points are particularly important in a **multi-speed delivery model**, where domains like mechanical, E/E, and digital evolve at different rates. For example: * Mechanical systems operate on a slow timeline due to the lead times associated with design, procurement, and factory setup. * E/E systems move at a moderate pace, balancing hardware iteration with software integration and testing. * Digital systems evolve rapidly, with OTA updates enabling frequent iterations of user-facing features. By defining clear freeze points, the framework ensures that faster-moving domains, like software, can innovate without causing disruptions to slower-moving mechanical or E/E systems. This alignment is critical to maintaining development efficiency while avoiding bottlenecks. ## **Example: Freeze Points for a Multi-Domain Feature** Consider a scenario where various **digital use cases**—such as a **passenger welcome sequence** and **on-site maintenance services**—require a feature for an **"open door" service**, including a **safe API** for controlling the door. 1. **Mechanical Freeze Point**: * The decision to add a **motorized door mechanism** has significant long-term implications. This includes supplier procurement, factory tooling for the assembly line, and structural reinforcements to the vehicle body. Once this decision is frozen, it cannot be reversed without incurring substantial costs and delays. 2. **E/E Freeze Point**: * The motorized door requires an ECU to control its movement. A **safe API** for this ECU must be defined early to enable communication with the digital layer. * Safety-critical embedded software components may also need to be developed to ensure secure and reliable door operation. These components might be difficult to update via OTA later, necessitating a robust initial design. 3. **Digital Freeze Point**: * Digital services like the **passenger welcome sequence** rely on a fixed API to interact with the door motor. While the software features themselves can evolve rapidly, the API must remain stable to avoid breaking integrations with the E/E and mechanical systems. * Additionally, the software architecture must accommodate future use cases, even if those features are not fully defined yet. ## **Key Takeaways** 1. **Holistic Alignment**: Freeze points align the slower-evolving mechanical and E/E systems with the faster-paced digital layer, ensuring seamless integration and long-term viability. 2. **Risk Management**: By freezing critical elements, teams can focus on innovation in areas with greater flexibility while minimizing risks in hardware and safety-critical systems. 3. **Efficient Collaboration**: Freeze points serve as a common reference for multidisciplinary teams, enabling parallel development without constant rework. In the **./pulse framework**, freeze points are not rigid constraints but rather strategic checkpoints that balance stability with flexibility. By managing freeze points effectively, OEMs can optimize resources, reduce risks, and accelerate the delivery of innovative, software-defined vehicles. # Automation and Engineering Intelligence In the context of the `./pulse` framework, automation through **Continuous Integration (CI), Continuous Delivery (CD), and Continuous Testing (CT)** is essential for accelerating the development of modern, software-defined vehicles (SDVs). It enables faster iteration, consistent quality, and smooth integration across mechanical, E/E, and digital domains. Building on this foundation, [Engineering Intelligence ](#engineering-intelligence)brings a new layer of capability: leveraging data, models, and AI to support smarter decision-making across the development lifecycle. From impact analysis and requirement traceability to simulation orchestration and predictive validation, Engineering Intelligence helps teams navigate complexity and drive informed, efficient engineering workflows. ## **The Role of CI/CD/CT Automation** CI/CD/CT automation is more than just a collection of tools—it's a cultural and technical shift that transforms how automotive systems are developed, tested, and delivered. It aligns with the multi-speed delivery model of the **./pulse framework**, bridging the slower-moving domains like mechanical systems with the rapid evolution of digital features. * **Continuous Integration (CI)**: Automates the process of integrating changes from multiple developers into a shared repository. Frequent integration ensures early detection of conflicts, reducing costly late-stage rework. * **Continuous Delivery (CD)**: Enables automated deployment of software to production-ready environments, ensuring that new features and updates are delivered seamlessly and reliably. * **Continuous Testing (CT)**: Embeds automated testing at every stage of the pipeline, from unit and integration tests to system and acceptance tests, ensuring quality and compliance throughout the development lifecycle. ## **Key Components of CI/CD/CT in the ./pulse Framework** 1. **Unified Pipelines for Multi-Domain Development**\ CI/CD/CT automation in the **./pulse framework** unifies pipelines across mechanical, E/E, and digital domains, enabling seamless collaboration and integration. For example: * Software teams can integrate and validate OTA updates alongside embedded system changes. * E/E teams can verify ECU firmware updates within the same pipeline as higher-level system tests. 2. **Virtual Validation and Simulation**\ By leveraging digital twins and virtual environments, CI/CD/CT pipelines can test features and system interactions without requiring physical prototypes. This is especially critical for SDVs, where software updates can impact multiple subsystems. 3. **Incremental and Modular Testing**\ Automated testing frameworks enable incremental validation of subsystems, ensuring that changes to individual components do not introduce system-wide defects. Modular testing also supports reuse across vehicle platforms. 4. **Integration with Homologation Processes**\ The **continuous homologation (CoHo)** aspect of the **./pulse framework** is tightly integrated with CI/CD/CT automation. Pipelines include automated checks for regulatory compliance, ensuring that features meet global standards before deployment. 5. **Feedback Loops for Continuous Improvement**\ Automated pipelines provide real-time feedback to developers, enabling faster resolution of issues and continuous improvement of the development process. Metrics such as test coverage, build success rates, and defect trends are continuously monitored. ## **Benefits of CI/CD/CT Automation** * **Speed and Efficiency**: Automating repetitive tasks like builds, tests, and deployments reduces development cycle times, enabling faster delivery of features and updates. * **Quality and Reliability**: Continuous testing ensures that defects are identified and resolved early, improving overall system quality. * **Alignment Across Domains**: Unified pipelines enable collaboration between mechanical, E/E, and software teams, ensuring that changes in one domain are validated against the others. * **Regulatory Compliance**: Automated compliance checks streamline homologation, reducing the time and effort required to meet safety and regulatory standards. * **Scalability**: Modular pipelines support the scalability required for SDVs, where frequent updates and platform reuse are critical. ## **CI/CD/CT Automation in a Multi-Speed Delivery Model** The multi-speed delivery model of the **./pulse framework** requires different domains to operate at varying paces. CI/CD/CT automation ensures synchronization between these domains by: * Enabling **parallel development**: For example, while mechanical systems freeze early due to long lead times, CI/CD pipelines allow software teams to continue iterating and testing new features. * Supporting **long-term stability**: Embedded systems and safety-critical components benefit from rigorous automated testing to maintain reliability. * Facilitating **rapid iteration**: Digital systems, such as infotainment or user-facing features, leverage CI/CD pipelines to deploy updates frequently, ensuring a seamless user experience. ## **Example: CI/CD/CT for a Motorized Door System** Consider the development of a **motorized door system** with features like a **passenger welcome sequence** and **remote access via mobile apps**. CI/CD/CT automation supports the development lifecycle as follows: 1. **Continuous Integration**: * Software teams integrate API changes (e.g., for remote door control) into a shared repository. * Embedded system teams update the ECU firmware for the door motor, which is automatically validated against the existing software stack. 2. **Continuous Testing**: * Virtual validation environments simulate door operation, testing edge cases such as obstruction detection and emergency overrides. * Compliance checks ensure the motorized door system meets ISO 26262 safety standards. 3. **Continuous Delivery**: * OTA pipelines deploy updates to the digital service, adding new features like gesture-based door opening. * Updates to the ECU firmware are delivered to test vehicles, ensuring compatibility with the deployed software. 4. **Real-Time Feedback**: * Metrics from automated tests, such as API response times or motor calibration accuracy, are fed back to developers for continuous improvement. This example highlights how CI/CD/CT automation bridges the mechanical, E/E, and digital domains, ensuring smooth integration and rapid delivery of innovative features. ## **Challenges and Best Practices** While CI/CD/CT automation offers significant benefits, it also presents challenges that organizations must address: * **Tool Integration**: Automotive development often involves heterogeneous tools across domains. Unified pipelines must bridge these gaps for seamless collaboration. * **Complex Test Environments**: Creating realistic simulations and virtual validation environments requires investment in tools and expertise. * **Cultural Shift**: Adopting CI/CD/CT requires a cultural shift toward automation and continuous improvement, particularly for teams accustomed to traditional workflows. To overcome these challenges, the **./pulse framework** emphasizes best practices such as adopting standardized tools, investing in virtual validation, and fostering a culture of collaboration and innovation. ## **Engineering Intelligence** Engineering Intelligence refers to the application of data-driven insights, artificial intelligence (AI), and advanced analytics to optimize product development processes across domains.
In the context of the **./pulse framework**, Engineering Intelligence plays a vital role in enhancing decision-making, automating repetitive tasks, and identifying patterns to improve quality, reduce time-to-market, and increase system reliability. It supports areas like predictive defect detection, requirements impact analysis, and the optimization of CI/CD pipelines by leveraging data from virtual validation, real-world telemetry, and historical development cycles. This capability is particularly valuable in aligning fast-moving digital systems with more rigid mechanical and E/E domains, ensuring continuous improvement throughout the product lifecycle. For a deeper dive into Engineering Intelligence, refer to the SDV Guide’s detailed section on [Engineering Intelligence](https://www.sdv.guide/sdv101/part-d-implementation-strategies/enterprise-topics/engineering-intelligence). {% embed url="" %} ## **Conclusion** CI/CD/CT automation is a foundational element of the **./pulse framework**, enabling faster, more reliable, and scalable development of software-defined vehicles. By integrating continuous integration, delivery, and testing across domains, the framework ensures alignment between mechanical, E/E, and digital systems, supporting the multi-speed delivery model. As vehicles become increasingly software-driven, CI/CD/CT automation will remain critical to delivering innovative, high-quality, and compliant systems at the pace of modern development. # Continuous Homologation **Continuous Homologation** is a central pillar of the **./pulse framework**, enabling seamless alignment between fast-paced development cycles and the stringent regulatory requirements of the automotive industry. Unlike traditional homologation processes, which are often treated as end-of-line activities, Continuous Homologation integrates compliance checks and validation into every stage of development. This ensures that regulatory adherence evolves dynamically alongside the product, reducing delays, rework, and risks associated with late-stage changes.
In the multi-speed delivery model of the **./pulse framework**, Continuous Homologation acts as a critical integration layer across domains. It leverages insights from **LeanRM** to ensure requirements are mapped to relevant regulations, integrates with **LeanSE** to validate system designs against compliance frameworks, and uses **freeze points** to lock in safety-critical decisions without stalling agile innovation. APIs play a key role in maintaining traceability, enabling automated compliance checks as part of the CI/CD/CT pipelines. Additionally, **Engineering Intelligence** provides data-driven insights to identify compliance risks early, further accelerating the homologation process. By embedding homologation into iterative workflows, the framework shifts compliance activities to the left, reducing dependency on time-consuming final-stage approvals and ensuring that even rapidly evolving SDV features remain compliant. For a more detailed exploration of Continuous Homologation and its implementation strategies, visit the SDV Guide’s section on [Continuous Homologation](https://www.sdv.guide/sdv101/part-d-implementation-strategies/implementing-the-shift-left/continuous-homologation) or download the [whitepaper](https://www.digital.auto/_files/ugd/604381_8407b82ac15a4ae0a0ed508894bcf814.pdf). {% embed url="" %} # Build / Measure / Learn The **Build / Measure / Learn** (B/M/L) cycle in the **./pulse framework** is a foundational approach to iterative development and continuous improvement. It adapts principles from agile and Lean development to the complexities of modern automotive systems, enabling rapid innovation while ensuring system reliability and regulatory compliance. By emphasizing data-driven feedback loops, the B/M/L cycle helps align vehicle development with customer needs and technological advancements across the entire lifecycle, from pre-SOP prototypes to post-SOP real-world vehicles. ## **Build: Pre-SOP vs Post-SOP Phases** The **Build phase** in the B/M/L cycle differs significantly before and after the vehicle's **Start of Production (SOP)**: * **Pre-SOP (Prototyping Phase)**:\ In the pre-SOP phase, prototypes and virtual models are used to experiment with new features and systems. These builds allow teams to: * Validate concepts and designs in controlled environments (e.g., simulations, labs, and limited physical prototypes). * Test integrations between mechanical, E/E, and software layers to identify early-stage issues. * Freeze critical elements such as hardware and embedded software APIs while maintaining flexibility in fast-moving digital systems.\ Prototypes provide the initial learning ground, where engineers refine features based on simulated scenarios and lab-scale testing. * **Post-SOP (Learning from Real Vehicles)**:\ After SOP, learning shifts to **real vehicles on the road**, providing access to vast amounts of real-world data from diverse use cases and environments. * **User Behavior Insights**: Analyze how customers interact with various vehicle features, such as adaptive cruise control, infotainment, or energy-saving modes. * **Problem Identification**: Detect issues such as feature usage inconsistencies, safety anomalies, or performance bottlenecks based on telemetry data from connected vehicles. * **Fleet Data Aggregation**: Use aggregated data to identify trends across the fleet, supporting feature optimization and predictive maintenance. The transition from pre-SOP to post-SOP learning ensures that every iteration—whether a software update or a new model variant—improves upon the previous one, guided by real-world insights. ## **Measure: The Role of Customer Journey Analysis** Understanding how customers interact with their vehicles is vital to delivering features that truly enhance user satisfaction. **Customer Journey Analysis (CJA)** applies best practices from the digital world to the automotive industry, enabling a deeper understanding of user behavior. * **Mapping Customer Journeys**:\ CJA involves mapping how customers interact with the vehicle across different touchpoints—such as entering the car, configuring driver preferences, or using connected services. This mapping helps identify friction points and opportunities for improvement. * **Data Collection and Analysis**:\ By leveraging APIs, vehicles can collect anonymized telemetry data on feature usage, such as: * How often customers use a specific mode (e.g., sport mode or eco mode). * Interaction frequency with voice assistants or infotainment systems. * Behavioral patterns, such as typical charging times for EVs or preferred navigation settings. * **Insights for Feature Refinement**:\ CJA insights help prioritize features based on actual customer needs, reduce redundant functionalities, and improve user interfaces to align with real-world preferences. ## **Learn: Leveraging AI for Smarter Insights and Features** Artificial Intelligence (AI) plays a transformative role in the **Learn phase**, with two primary dimensions: 1. **AI to Improve Learning**: * **Enhanced Data Analysis**: AI-powered tools can analyze massive datasets from connected vehicles to uncover patterns, identify anomalies, and predict future behavior. * **Advanced Customer Journey Analysis**: AI can dynamically segment users based on their behavior, offering insights into how different demographics interact with vehicle features. * **Predictive Insights**: Machine learning models can predict maintenance needs, feature failures, or even emerging customer preferences, enabling proactive adjustments. 2. **AI Deployed on the Vehicle**: * **Onboard Learning**: AI systems embedded in vehicles, such as personalized driver settings, adaptive infotainment, or autonomous driving algorithms, continuously learn from real-world scenarios. * **OTA Updates for AI Models**: Post-SOP, onboard AI models can be updated over-the-air (OTA) to improve performance, integrate new features, or address edge cases not covered during pre-SOP testing. * **Example Use Case**: An AI-powered parking assistant might learn from user feedback to optimize parking space detection in complex urban environments. Over time, these improvements are deployed fleet-wide, enhancing the feature for all users. AI, in both dimensions, ensures that vehicles are not static products but dynamic systems that evolve based on real-world use and feedback. ## **Mapping Build / Measure / Learn to the ./pulse Framework** The B/M/L cycle integrates seamlessly with the other elements of the **./pulse framework** to ensure iterative development and alignment across domains: * **LeanRM**: Requirements evolve dynamically based on insights from the "Learn" phase, ensuring that feature development aligns with real-world usage and customer needs. * **LeanSE (Systems Engineering)**: Systems-level design considerations feed into the "Build" phase, ensuring that dependencies between mechanical, E/E, and software systems are accounted for. * **Freeze Points**: Critical design decisions made in the "Build" phase are stabilized through freeze points, ensuring downstream stability while enabling continued iteration in digital systems. * **API-First**: APIs enable seamless data collection for the "Measure" phase and ensure modularity for faster updates in the "Build" phase. * **CI/CD/CT Automation and Engineering Intelligence**: Automation accelerates the "Build" and "Measure" phases, while Engineering Intelligence provides actionable insights for the "Learn" phase. * **Continuous Homologation (CoHo)**: Compliance checks integrated into the "Measure" phase ensure that iterative updates meet regulatory requirements. ## **Conclusion** The **Build / Measure / Learn** cycle in the **./pulse framework** transforms automotive development into an iterative, data-driven process. By differentiating pre-SOP prototyping from post-SOP real-world learning, incorporating Customer Journey Analysis, and leveraging AI to enhance both learning and feature evolution, the B/M/L cycle ensures continuous improvement across all domains. Integrated with the other elements of the framework, it empowers OEMs to deliver software-defined vehicles that are innovative, user-focused, and compliant with evolving industry standards. # Community & Meetups **./pulse is the product of an open, cross-disciplinary community.** Experts in finance (KPMG), teardown cost analytics (A2MAC1), feature-lifecycle economics (BinaryCore), lean systems engineering (Spicy SE), legal contracting (Reusch Law), MBSE research (TU Berlin & Steinbeis FSTI), API/virtualisation (Axway, Bosch, MHP), AI-driven CI/CD (Spread.ai), homologation (Certivity), agile + ASPICE (iProcess), crowd-testing (TestBirds), market intelligence (SBD Automotive), tool-chain enablement (ETAS) and developer-ecosystems (SODA.auto) all contribute. **pulse.meet**: We work in **open monthly meet-ups**, share assets transparently, and invite any OEM or supplier to join and extend the framework. The schedule below shows the upcoming sessions and the expert perspectives that shape each topic. | Date | Topic | Expert | Perspective | | -------------------------------------------------------------------------------------------------------------- | -------------------------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | 26 Jun 2025: [event link](https://www.linkedin.com/events/pulse-meet-1-thesdvbusinesscase7340603190066782210/) | **SDV Business Case** | KPMG | CFO perspective – investment KPIs, ROI gates | | | | A2MAC1 | Tear-down data – hardware & BOM cost baseline | | | | BinaryCore | Feature-lifecycle economics – SW cost & value levers | | 24 Jul 2025 | **Lean RM / Lean SE, SCM** | Spicy SE | Lean RM / Lean SE methods & toolchain | | | | Reusch Law | Outcome-based contracting & legal risk-sharing | | 28 Aug 2025 | **SDVx MBSE + Shift-Left** | Prof. Rainer Stark / Jens Lachenmeier | SDVx MBSE project with prostep ivip | | | | Bosch | Virtualisation & early validation (“shift-left”) | | 25 Sep 2025 | **Loose Coupling** | Axway | API-first, service gateway patterns | | | | Bosch | Vehicle API implementation & governance | | | | MHP | Two-speed delivery model & operating model design | | 23 Oct 2025 | **Continuous Improvement** | Spread.ai | Agentic engineering intelligence & AI-assisted CI/CD/CT | | | | Certivity | Continuous homologation & regulatory traceability | | | | iProcess Consulting | Agile + ASPICE integration | | | | TestBirds | Crowd & remote testing at SDV pace | | 27 Nov 2025 | **Enabling** | SBD Automotive | Market intelligence & competitive benchmarking | | | | ETAS | Toolchain enablement – DevSecOps, ECU & cloud integration | | | | SODA.auto | Developer-ecosystem catalyst – open-source SDKs, API sandbox, community onboarding for third-party SDV apps | # Glossary This is the glossary for the SDV Guide. Currently covering SDV101. **Agile**: A methodology that promotes iterative development, collaboration, and adaptability in the software development process. **App Store**: A digital marketplace where users can browse, purchase, and download applications and services for their devices. **Application Programming Interface (API)**: A set of rules and protocols that allow different software components to communicate with each other. **Artificial Intelligence (AI)**: The simulation of human intelligence processes by machines, enabling them to perform tasks requiring human-like intelligence. **ASIL (Automotive Safety Integrity Level)**: A risk classification scheme defined by ISO 26262 to determine the necessary safety requirements for automotive systems. **AUTOSAR**: A standardized automotive software architecture enabling interoperability and scalability in vehicle electronics systems. **CAN (Controller Area Network)**: A robust vehicle bus standard designed to enable communication among microcontrollers and devices without a host computer. **Chaos Monkey**: A tool developed by Netflix that randomly disrupts services in production environments to test resilience and recovery capabilities. **CI/CD (Continuous Integration/Continuous Delivery)**: Practices that automate code integration, testing, and delivery processes to streamline software development and deployment. **Cloud-Native Principles**: Designing and building applications to leverage cloud computing delivery models, emphasizing scalability, resilience, and flexibility. **Containerization**: A technology that packages an application and its dependencies into a container, ensuring consistency across environments. **Continuous Homologation**: The process of continuously ensuring that vehicle updates and changes comply with regulatory and safety requirements. **COVESA**: The Connected Vehicle Systems Alliance, focused on developing open standards for vehicle data and connectivity. **COVESA VSS (Vehicle Signal Specification)**: A standardized way to describe and access vehicle data signals, enabling interoperability. **DevOps**: A set of practices combining software development (Dev) and IT operations (Ops) to deliver applications and services faster. **Eclipse SDV**: An open-source initiative within the Eclipse Foundation focused on tools and frameworks for Software-Defined Vehicles. **E/E (Electrical/Electronic Architecture)**: The vehicle’s integrated electrical and electronic systems, including wiring, sensors, actuators, and control units. **Ecosystem Integration**: The process of ensuring seamless interaction between various components, applications, and services within a larger system. **Ethernet**: A high-speed networking protocol increasingly adopted in automotive systems for reliable data communication. **FLEXRAY**: A high-speed automotive network protocol designed for real-time, fault-tolerant communication in advanced systems. **Hardware Abstraction Layer (HAL)**: A programming layer that provides a uniform interface to interact with hardware components. **Homologation**: The process of certifying that a vehicle or component meets regulatory and safety standards. **Innovation Management**: The process of generating, capturing, and implementing new ideas and technologies within an organization. **ISO 26262**: An international standard for the functional safety of electrical and electronic systems in production automobiles. **LIN (Local Interconnect Network)**: A low-cost automotive network protocol for communication between components like sensors and actuators. **Loose Coupling**: A design principle that minimizes dependencies between components, enabling modularity and resilience. **MBSE (Model-Based Systems Engineering)**: A methodology that uses models to support the design, analysis, and validation of complex systems. **Microservices**: An architectural style that structures applications as collections of small, independent services, each performing specific business functions. **QM (Quality Management)**: The classification level in ISO 26262 for systems with no safety-related risks requiring functional safety measures. **Real-Time**: The ability of a system to process and respond to inputs or events within a guaranteed time frame, critical for safety-critical automotive applications. **RegTech (Regulatory Technology)**: The use of technology to simplify and improve compliance with regulatory requirements. **SOA (Service-Oriented Architecture)**: A software architecture style where services provide modular functionality accessible via standardized interfaces. **SOAFEE (Scalable Open Architecture for Embedded Edge)**: A framework aimed at enabling the development of automotive-grade applications using cloud-native principles. **Software-Defined Vehicle (SDV)**: A vehicle whose functionality is primarily enabled and enhanced through software, allowing continuous updates and improvements. **SUSM (Software Update Management System)**: A system designed to manage and distribute software updates for vehicles. **TCP (Transmission Control Protocol)**: A fundamental internet protocol providing reliable, ordered, and error-checked delivery of data. **Two-Speed Delivery**: A development model that separates systems into rapid-update and slower-update tracks, balancing innovation and stability. **UNECE (United Nations Economic Commission for Europe)**: An international organization that develops regulations and standards for the automotive industry and other sectors. **V-Model**: A software and system development model emphasizing validation and verification at each stage of the lifecycle. **vBUS (Virtual Bus)**: A simulation model for testing vehicle communication networks without physical hardware. **vECU (Virtual Electronic Control Unit)**: A software-based simulation of an ECU used for development and testing. **Virtualization**: The creation of virtual versions of hardware, platforms, or systems to enable flexible and scalable testing and deployment. **Vehicle Hardware Abstraction Layer (VHAL)**: An abstraction layer enabling software to communicate with vehicle hardware in a standardized way.