Dervo
In a software-defined vehicle, many features are delivered and improved through software, often after the car has been sold. That changes how vehicles are built, and it changes testing even more.
What is actually changing
- Fewer, more powerful computers. Functions that used to be spread over dozens of small ECUs move to a few central computers and zone controllers.
- Software updated over the air. A feature can change months after start of production.
- Faster release cycles. Some software is released many times a year instead of once per model year.
- More regulation of software itself. UN Regulations No. 155 (cybersecurity) and No. 156 (software updates) require manufacturers to manage cybersecurity and updates across the vehicle's life.
What this means for testing
Testing becomes continuous
If software can be released at any time, it must be testable at any time. Teams move from a big test phase before release to automated tests that run on every change.
More testing moves to virtual environments
Virtual ECUs and software-in-the-loop let teams test long before hardware exists, and run thousands of tests in parallel in the cloud. HIL benches and vehicles are still needed, but for what only they can prove.
Regression grows quickly
Every update must be checked against everything that already works. Without strong automation and good test selection, regression testing becomes the bottleneck.
Updates themselves need testing
The update process is a feature: download, install, interrupted installation, rollback, and compatibility between software versions on different computers.
Data from the field feeds back into tests
Problems seen in vehicles on the road become new test cases, so the same issue never returns.
Skills test teams need now
- Test automation in Python or similar languages
- Continuous integration tools and pipelines
- Working with virtual ECUs, containers and simulation
- Automotive Ethernet and service-based communication such as SOME/IP
- Basics of cybersecurity testing
- Analysing large amounts of test and vehicle data
A practical first step
Pick one software component and build a full pipeline for it: build, run unit tests, run SIL tests and publish a report on every change. Once that works, extend the same pattern to more components and to HIL. Small, working pipelines beat large plans.
