Techniques and practices

The automotive industry is witnessing a fundamental shift in software validation as organizations move toward automated, continuous end-to-end testing throughout the development lifecycle. This approach mirrors successful patterns from IoT and other phygital industries, where automated testing has become essential for managing complex, interconnected systems. While validation has always been a standout in the automotive industry, organizations are now adopting testing automation to ensure software quality across increasingly sophisticated vehicle architectures.

To achieve comprehensive testing coverage, organizations are using end-to-end development platforms and virtual engineering workbenches (VEWs) that integrate testing capabilities into mobile devices, vehicle back-ends and in-vehicle systems.

This approach goes hand-in-hand with the test pyramid methodology, where automation is implemented across multiple testing levels. At the base, continuous integration (CI) pipelines enable automated unit and integration testing in virtual environments. VEWs provide simulation-based testing, while automated boxcars and labcars enable hardware-in-the-loop testing for real-time validation. At the top of the pyramid, vehicle-in-loop systems combine virtual and physical testing to validate complete vehicle behavior.

The shift toward automated testing requires significant investment in testing infrastructure, simulation tools and CI pipelines. With vehicle software complexity increasing through multiple subsystems and interdependencies, automated, continuous end-to-end testing is becoming essential for maintaining quality and safety while enabling rapid development.

Continuous compliance is the process of continually assessing automotive software components to ensure they always meet regulatory requirements and industry standards. This approach integrates compliance checks into the development process rather than treating them as separate milestone activities.

In automotive software development, compliance audits — including functional safety, cybersecurity and ASPICE — play a crucial role in the safety assessment of vehicle systems before homologation. We are now seeing the emergence of knowledge graphs that capture entire development processes, enabling scalable safety arguments from individual components to complete code bases. Augmented by GenAI, frameworks such as the Trustable Software Framework from Codethink are unlocking innovative approaches to compliance by automating evidence synthesis and transforming audit workflows. Continuous compliance tools such as Kosli and ChainLoop complement this evolution, providing real-time monitoring of software changes against regulatory requirements. These tools also ensure traceability across the development lifecycle, allowing teams to identify and resolve compliance gaps proactively.

The continuous approach reduces the risk of compliance failures during certification and enables faster adaptation to evolving regulatory requirements. It also supports over-the-air updates by ensuring that software changes maintain compliance with safety standards. As vehicles become more software-defined, continuous compliance will be essential for maintaining safety while enabling rapid software evolution.

SDV OEMs need deep visibility into software development processes and their external dependencies to monitor progress, manage risks and avoid production delays. These constant assessments apply to individual software artifacts and systems — and to entire vehicle software projects.

The virtual engineering workbench (VEW) integrates engineering, testing and virtual validation tools, allowing users to trace successfully executed tests and validations back to their requirements. As this process can be fully automated, the VEW dashboard will always reflect the current state of development progress, providing OEMs with real-time visibility.

VEWs also offer integration with other VEW environments. By securely connecting these systems, OEMs can gain insights into the development progress of dependent software artifacts spanning multiple suppliers and accounts, giving them a comprehensive view of the end-to-end software development lifecycle.

This approach enables more efficient resource allocation and better coordination of complex automotive software development programs. However, the shift toward cross-project visibility requires the integration of various development tools and the standardization of metrics and reporting. Organizations need to balance transparency with security and ensure teams can focus on their work while maintaining awareness of broader project context.

Historically, the way of working for automotive embedded software has been defined by the OEM’s ‘process, methods and tools’ (PMT). The goal was to fix the software development lifecycle to ensure quality and compliance. However, the strict PMT approach is now often seen as a burden by developers. The growing complexity of in-vehicle software and the adoption of new tools and technologies means developers need greater flexibility; the established way of working can seem inefficient or even counter-productive.

Companies like Netflix, Spotify and Etsy have established a ‘Golden Path’ (sometimes referred to as a ‘Paved Road’) approach. This provides a recommended and supported way to complete essential tasks in building, testing and deploying software, but allows teams to deviate from the described path as long as they fulfill defined outcomes. 

‘Sensible defaults’ offer a similar approach, giving teams a defined set of practices and methods that are considered to be standard. They should be the starting point for every project and only changed in special circumstances. For software development, this might include test-driven development, pairing and build automation. Companies might also define sensible defaults for data, security or AI. Every employee should be proficient in their use and able to apply them in their role.

We currently see automotive organizations attempting to apply these approaches for their software development. While many have met challenges in finding the right categories and achieving alignment, we consider these approaches to offer powerful ways to foster discussions and define the target way of working.

The automotive industry’s electrical/electronic (E/E) architecture and systems are rapidly evolving toward having a powerful, centralized compute system for most core car functions. Many OEMs adopting new E/E architectures are also modernizing their software.

However, in many cases automotive manufacturers moving functionality from legacy software to modern architecture are simply translating existing software to the new architecture.

This lift-and-shift approach fails to leverage the fundamental benefits of SDV. Instead of carefully planning features for the new architecture, OEMs are porting their static, ECU-centric software designs to work on the new E/E architecture, missing opportunities for improved scalability, performance and maintainability. To take full advantage of the capabilities of modern SDV architectures and compute systems, OEMs must properly redesign their software components.

Machine learning (ML) models are fundamental to modern vehicles, powering Advanced Driver-Assistance Systems (ADAS) and enabling features like lane-keeping assist and object detection by processing real-time sensor data with ML models to enhance safety.

Self-driving and ADAS applications in cars require rapid decision-making. Therefore, processing information directly within the vehicle is preferable to transmitting large volumes of data to the cloud and processing for information there. While the cloud can assist with highly complex tasks, cars can pre-process data to reduce information transfer. However, integrating increasingly sophisticated AI models into compact, power-efficient in-car computers presents a significant challenge.

AI is also transforming automotive interactions through voice commands and personalized entertainment system recommendations. To enable continuous improvements and new features, frequent vehicle updates are necessary. This necessitates proficiency in wirelessly deploying AI models to cars. This capability will foster the development of the next generation of safer, smarter and continuously evolving vehicles. Automotive manufacturers should also consider managing all ML models within a vehicle fleet to ensure optimal performance and feature delivery throughout the car's lifespan.

Shadow mode refers to running two versions of a software component in parallel. One is live and impacts other components with its results; the other runs simultaneously but its results are logged for comparison and analysis and don’t affect other components. This allows teams to gather software performance data and compare it with current production versions.

For example, in adaptive cruise control (ACC), a vehicle sensor detects the distance to the vehicle in front frequently, with an ECU continuously processing the data and generating output. When a new ACC variant is deployed into the vehicle in shadow mode, teams can compare how the new version performs against the current one. When enough data is collected from the field to prove the new ACC variant outperforms the current one, the new variant can be deployed to the entire fleet.

For features such as ADAS, it’s impossible to develop test cases for every imaginable scenario. Running vehicle functions in shadow mode provides a safe way to test new vehicle functions at scale, based on their behavior under real-world conditions. 

With shadow mode capabilities in on-board architectures, organizations can also safely train new functions in the field while processing data in the vehicle and comparing results with expected outcomes. This technique supports the drive toward increased software quality in the automotive industry.

Shift-left security is a set of practices for addressing security questions early in the software development process, rather than dealing with them at the end. As vehicles become increasingly software-driven they also become more attractive targets for cyber attackers. For example, in 2024, the Chaos Computer Club showed how it retrieved the movement information of 800,000 vehicles, including user details. This growing threat landscape requires a fundamental change in how OEMs approach software security.

Development teams are evolving their practices to embed security into CI/CD pipelines. They’re also conducting automated security testing to identify vulnerabilities in code and dependencies, and carrying out constant threat model assessments for their applications.

Teams are increasingly using AI and ML models to perform real-time code analysis, detect anomalies and assist with automated threat modeling. These tools are being integrated into IDEs and CI/CD pipelines, reducing manual overhead and enabling proactive vulnerability detection before code even hits test environments.

There’s also a greater focus on end-to-end trust, including mutual attestation between in-vehicle ECUs and cloud services, and secure OTA workflows that preserve cryptographic integrity and traceability across domains.

Testing in automotive software development involves various environments, from local unit tests on virtual environments to more complex physical hardware setups. Environments early in the testing process are typically faster, but can't reliably detect certain types of errors. 

As automotive software development moves to a more iterative approach, testing must ‘shift left’, catching issues sooner and reducing development time and costs. However, it’s true that different levels of physical test environments are still needed.

The test pyramid is a common metaphor in general software development. It categorizes tests by their scope and granularity, suggesting a pyramid-shaped ratio between the test types. While commonly used test categories must be changed to reflect the challenges and requirements of embedded automotive development, the concept of a test pyramid remains valid. 

Simply aiming to shift left does not define a desired target state, making it difficult to measure progress. By defining their own test pyramid and making it an essential part of testing strategy, automotive organizations can determine testing goals more clearly to make their initiatives more efficient.

Traditionally, vehicle data has been instrumental during product development phases, primarily for debugging car components and fine-tuning them to meet quality, security and user experience standards. However, with the advent of SDVs, there's been a significant increase in the volume of data vehicles generate.

One of OEMs' biggest challenges is integrating this data into product engineering so engineers can use real-world insights to refine components more efficiently and deliver enhanced vehicle iterations.

Another challenge is managing data at scale. Selecting which data to extract and analyze from the vehicle is a complex process, as is building the tooling to translate it into actionable insight.

Vehicle data-driven engineering enables more informed decision-making throughout the development process. Teams can use data to validate design assumptions, prioritize development efforts and measure the impact of software changes. This approach also supports predictive maintenance and helps identify potential issues before they affect vehicle performance or safety. If organizations can use data effectively, they’ll engineer better vehicles  and better vehicle experiences.