Dervo
Most vehicle programs today use both AUTOSAR platforms side by side. Classic still runs the bulk of the ECUs, while Adaptive runs the high-performance computers behind ADAS, infotainment and connectivity. If your team tests both, the difference is bigger than the name suggests.
The two platforms in one table
| Classic Platform | Adaptive Platform | |
|---|---|---|
| Typical hardware | Microcontrollers | High-performance processors |
| Operating system | OSEK-style real-time OS | POSIX operating system (for example Linux or QNX) |
| Language | Mainly C | Mainly C++ |
| Communication | Signals over CAN, LIN, FlexRay and Ethernet | Services over Ethernet (SOME/IP) |
| Configuration | Fixed at build time | Applications can be deployed and updated |
| Typical use | Body, chassis, powertrain, safety controllers | ADAS, central computers, gateways, connectivity |
Testing Classic Platform software
Classic software is configured heavily and statically. A large part of the risk sits in the configuration (the ARXML files), the RTE and the basic software, not just in the application code.
- Check the configuration early. Wrong signal mappings, timing settings or memory sections cause problems that look like application bugs.
- Test at several levels. Unit tests for software components, integration tests for the RTE and basic software, and HIL tests for the complete ECU.
- Simulate the rest of the vehicle. On a HIL bench, restbus simulation provides the CAN and LIN messages the ECU expects from other ECUs.
- Watch timing. Classic ECUs are hard real-time. Task overruns and jitter need their own tests, not just functional checks.
- Include diagnostics and network management. Fault memory, UDS services and bus sleep and wake-up are common sources of late defects.
Testing Adaptive Platform software
Adaptive software behaves more like modern server software running in a car, so test methods move closer to general software engineering.
- Test service interfaces. Check that services are offered, found and used correctly, including what happens when a service disappears or comes back.
- Use virtual ECUs and CI pipelines. Much of the testing can run on a PC or in the cloud on every code change, long before target hardware is available.
- Test states and start-up. Execution management and state management decide what runs and when. Start-up order, shutdown and recovery after a crash need dedicated tests.
- Measure resources. CPU load, memory use and latency matter because many applications share one processor.
- Plan for updates. Since software can be updated in the field, test the update itself, including interrupted updates and rollback.
- Treat security as a test area. Access control, secure communication and secure boot need their own test cases.
What stays the same
Some things do not change between platforms:
- Every test should trace back to a requirement.
- Regression tests should run automatically and often.
- Test results need to be reproducible, with the software version and configuration recorded.
- Defects found late cost much more than defects found early.
Where teams struggle most
The hardest part is usually the boundary between the two worlds: a Classic ECU sending signals that a gateway turns into services for an Adaptive application. Plan end-to-end tests across that boundary early, because neither team owns it by default.
