Test automation in CANoe and CAPL
Convert manual procedures into repeatable tests with explicit waits, verdicts, and cleanup, so a run either passes or fails for a stated reason rather than requiring interpretation.
Testing, Validation & Simulation
ECU and vehicle test automation
Most automotive test effort is spent re-running procedures a person has already run before, on hardware that is scarce and shared. Automation is worth doing where it converts that repetition into something with an unambiguous verdict — and where the environment the test needs can be simulated rather than waited for.
Discuss a Testing ProjectProblems I can investigate
Find the behavior behind the symptom
- 01
Testing takes too much manual effort
Procedures are executed by hand, results are recorded by hand, and each repetition costs an engineer's day. The candidates for automation are the steps that are already precisely defined and frequently repeated.
- 02
The ECU is not available when testing needs to happen
Shared or scarce hardware turns test scheduling into the bottleneck. Simulating the component or its surrounding network is often the practical way to keep testing moving.
- 03
A complete vehicle is not available
Behavior that depends on the wider vehicle context has to be reproduced on a bench, which means deciding what genuinely needs to be real and what can be simulated.
- 04
The missing network participants need to be simulated
A component under test expects communication from nodes that are not present. Restbus simulation supplies that communication so the component can run in a realistic context.
- 05
Regression testing is too slow to run often
A suite that takes too long stops being run, which defeats it. Execution time, setup and teardown, and result collection are addressed together rather than only the test logic.
- 06
Diagnostic testing needs automating
Diagnostic sequences involve session state, security access, and ordering constraints that make manual repetition error-prone and its results hard to compare between runs.
What I can help with
Focused engineering work in Testing, Validation & Simulation
Restbus simulation
Build the surrounding network communication a component expects, so it can be exercised on a bench without the complete vehicle environment.
Diagnostic test automation
Automate diagnostic sequences including session handling, security access, and ordering constraints, with results captured in a form that can be compared across runs.
Python-based test tooling
Build test execution, bus interaction, and result handling in Python where the work needs to run outside a vendor test environment or integrate with existing infrastructure.
Regression suites and repeatability
Structure tests so they can run unattended and repeatedly, addressing setup, teardown, and the state leakage between tests that makes suites unreliable over time.
Automated test reporting
Produce test results and reports as an output of the run itself, so the evidence for a verdict is generated rather than assembled afterwards.
Existing test environment support
Work within an established CANoe project or CAPL codebase — extending, repairing, or restructuring it — rather than assuming a rebuild from scratch.
Specific services
Services in Testing, Validation & Simulation
CANoe Configuration
Configure CANoe projects, CAPL automation, and restbus simulations for repeatable CAN and CAN-FD testing, timing analysis, and validation.
CANoe Restbus Simulation
Build CANoe restbus simulations with CAPL nodes, defined message behavior, and clear simulation boundaries for testing available components.
CANoe Test Automation
Automate CANoe testing with CAPL, repeatable simulations, and executable validation workflows for CAN and CAN-FD networks.
CAPL Automation
Automate CANoe test procedures with CAPL setup, stimulus, bounded waits, assertions, and cleanup for repeatable engineering test results.
CAPL Development
CAPL development for CANoe and CANalyzer projects, including automated tests, restbus simulation, and repeatable vehicle-network validation.
What to send
Start with the evidence you already have
Problem description
What is being tested, what is currently manual, and where the process breaks down.
Test specification
The procedures, expected results, and pass criteria to be automated.
Requirements
The requirements the tests are meant to demonstrate.
Existing CANoe project
A current configuration to extend, repair, or build on.
Existing CAPL
CAPL code already in use for simulation or testing.
DBC
A CAN database defining the messages and signals under test or being simulated.
How the analysis works
From recorded data to engineering findings
- 01
Establish what is worth automating
Identify which procedures are repeated often enough and defined precisely enough to justify automation, and which are better left manual for now.
- 02
Define verdicts before writing tests
Agree what constitutes a pass, a fail, and an inconclusive result. Tests without an unambiguous verdict produce results that still need a human to interpret them.
- 03
Determine what must be real
Decide which parts of the environment need actual hardware and which can be simulated, since that decision sets both the cost and the validity of the test setup.
- 04
Build the tests and the environment together
Implement the test logic alongside the simulation, stimulation, and setup it depends on, including the cleanup that lets tests run in sequence.
- 05
Validate against the real target
Confirm the tests behave correctly against the actual ECU or bench, including that they fail when they should, and record what could not be exercised.
- 06
Hand over a maintainable suite
Deliver tests, configuration, and documentation your team can run and extend, rather than a setup that only works as originally delivered.
What you receive
Deliverables matched to the investigation
Automated test suite
Repeatable tests with defined verdicts, setup, and cleanup.
Test report
Documented test results with the evidence behind each verdict.
Automated report
Reporting generated by the test run itself rather than assembled afterwards.
Restbus simulation
A simulation of missing network nodes and their communication.
ECU simulator
A simulated ECU standing in for hardware that is unavailable or shared.
CAPL script
CAPL implementing the test logic, simulation, or stimulation required.
CANoe configuration
A configured test environment covering nodes, databases, and test execution.
Technologies & formats
Automotive data and analysis environments
- CANoe
Vector CANoe
A development, simulation, test, and analysis environment for vehicle networks.
- CAPL
Communication Access Programming Language
Vector event-driven language for network simulation, testing, and automation.
- python-can
python-can
A Python library providing a common API for CAN interfaces and messages.
- Python
Python
A general-purpose language widely used for automotive analysis, tooling, and automation.
- XCP
Universal Measurement and Calibration Protocol
A protocol for ECU measurement, calibration, stimulation, and programming.
- CAN
Controller Area Network
A priority-based broadcast bus used for in-vehicle control communication.
- CAN-FD
CAN Flexible Data-rate
An extension of CAN with larger payloads and a faster data phase.
- UDS
Unified Diagnostic Services
ISO 14229 diagnostic services for communicating with vehicle ECUs.
- DBC
CAN Database
A text format describing CAN messages, signals, nodes, scaling, and metadata.
- BLF
Binary Logging Format
A Vector binary container for timestamped bus communication.
FAQ
Practical questions before an investigation
- Do I need CANoe for automated testing?
- No. CANoe is common and well suited where restbus simulation and bus-level test execution are central, and existing CANoe projects are often worth building on. Where there is no licence, or where tests need to integrate with other infrastructure, Python-based test tooling over a CAN interface is a practical alternative.
- Can existing CANoe or CAPL work be extended rather than replaced?
- Yes, and that is usually the starting assumption. An established configuration encodes real knowledge about the setup. The exception is a codebase whose structure is itself the reason tests are unreliable, in which case restructuring is proposed explicitly rather than done quietly.
- What can be tested without the physical ECU?
- Anything that depends on network communication, message content, and timing can be exercised against a simulation. What cannot be substituted is behavior that depends on the ECU's own implementation — its actual responses, timing, and internal state. That distinction is drawn before the bench is designed, not after.
- How do you decide what to automate first?
- By repetition and precision. A procedure that runs weekly and has an unambiguous pass criterion repays automation quickly. One that runs twice a year, or whose result depends on engineering judgement, usually does not. The exception is a test that is repeated rarely but must be exactly reproducible.
- Can tests run unattended in a pipeline?
- That is the usual target. It requires deterministic setup and cleanup, handling of hardware that fails to initialise, and reporting that makes a failure diagnosable without someone having watched the run. Those requirements shape the suite's design and are addressed as part of it.
Discuss the evidence
Discuss a Test Automation Project
Describe what is currently tested by hand, what hardware is available, and what the tests need to demonstrate. An existing CANoe project or test specification helps.