Convert a manual procedure into test steps
Map each operator action to the existing CANoe or CAPL interface, identify required initial conditions, and define which actions can be automated in the supplied environment.
CAPL Automation
Automate repeatable CANoe tests with CAPL
CAPL automation turns defined bench procedures into repeatable CANoe execution. I extend existing scripts with setup, stimulus, bounded waits, assertions, and cleanup, so an engineer can rerun a case and inspect the evidence behind its verdict.
Discuss CAPL AutomationProblems I can investigate
Find the behavior behind the symptom
- 01
Testing is too manual
Repeated test execution and evaluation consume excessive engineering time. CAPL automation can replace repeatable steps with executable workflows and consistent result checks.
- 02
Diagnostic test automation needed
Diagnostic test cases require repeatable execution and result evaluation. Automation can structure UDS procedures around defined expected results without assuming unsupported ECU behavior.
- 03
ECU unavailable for testing
Model the communication of an unavailable counterpart from agreed requirements. A model can help prepare a test sequence, but testing that model does not validate the absent target ECU.
- 04
Vehicle unavailable for testing
System validation cannot depend on access to a complete vehicle. CANoe-based simulation and automated tests can support bench testing and other defined validation activities.
What I can help with
Focused engineering work in Testing, Validation & Simulation
Implement waits and verdicts
Use bounded event or timer-driven waits, check specified outcomes, and produce distinct failure evidence for missing responses and incorrect values.
Reset between repeat runs
Add cleanup and explicit state restoration so earlier tests do not silently influence later results. Document any reset action that still depends on hardware or an operator.
Exercise diagnostic procedures
Automate the specified UDS exchange and expected-response checks in the available project, retaining service and timing evidence when a case fails.
What to send
Start with the evidence you already have
Existing CAPL
Existing CAPL nodes, test modules, or libraries to extend, refactor, or connect to the requested automation.
Existing CANoe project
The existing CANoe configuration and project assets that define the available test and simulation context.
DBC
The CAN database defining messages, signals, nodes, scaling, and related metadata required by the automation.
Test specification
Test cases, procedures, expected results, or acceptance criteria used to define execution and evaluation behavior.
How the analysis works
From recorded data to engineering findings
- 01
Review the test boundary
Review the supplied CAPL, CANoe project, DBC, and test specification to identify the requested automation scope, dependencies, and expected behavior.
- 02
Implement the automation
Develop or adapt CAPL behavior for test execution, diagnostic procedures, result evaluation, or missing-node simulation within the defined project context.
- 03
Exercise defined scenarios
Run the implemented workflows against the available CANoe or CANalyzer setup and inspect communication and test results against the supplied expectations.
- 04
Refine and package
Address observed implementation issues, clarify remaining assumptions, and package the scripts, tests, or simulation components for handover.
What you receive
Deliverables matched to the investigation
CAPL script
CAPL source implementing CANoe or CANalyzer behavior for the agreed automation or simulation scope.
Automated test suite
Executable tests with setup, expected-result checks, and repeatable results based on the supplied test specification.
Restbus simulation
A simulation of missing network nodes and their communication, bounded by the supplied DBC and project requirements.
Technologies & formats
Automotive data and analysis environments
- CAPL
Communication Access Programming Language
Vector event-driven language for network simulation, testing, and automation.
- CANoe
Vector CANoe
A development, simulation, test, and analysis environment for vehicle networks.
- CANalyzer
Vector CANalyzer
A Vector environment for recording and analyzing vehicle-network communication.
- CAN
Controller Area Network
A priority-based broadcast bus used for in-vehicle control communication.
- UDS
Unified Diagnostic Services
ISO 14229 diagnostic services for communicating with vehicle ECUs.
- CAN-FD
CAN Flexible Data-rate
An extension of CAN with larger payloads and a faster data phase.
- BLF
Binary Logging Format
A Vector binary container for timestamped bus communication.
- ASC
ASCII Log Format
A human-readable Vector format for timestamped bus events.
- DBC
CAN Database
A text format describing CAN messages, signals, nodes, scaling, and metadata.
- J1939
SAE J1939
A higher-layer vehicle network protocol suite using CAN, common in heavy vehicles.
- ISO-TP
ISO 15765-2 Transport Protocol
A segmented transport protocol for messages carried over CAN.
- python-can
python-can
A Python library providing a common API for CAN interfaces and messages.
- DoIP
Diagnostics over Internet Protocol
Diagnostic transport over IP networks as defined by ISO 13400.
FAQ
Practical questions before an investigation
- What makes a CAPL test repeatable?
- The test needs a known initial state, explicit stimulus, a defined observation window, and a measurable expected result. Timers should end with a clear timeout verdict, and cleanup should restore the setup for the next case. Merely replaying messages does not establish a pass or fail.
- What can be automated with CAPL?
- The scope can include repeatable CAN or CAN-FD communication, test setup, diagnostic procedures, expected-result checks, and simulation of missing network nodes in the supplied project context.
- Can this work with an existing CANoe project?
- Yes. Existing CANoe project assets and CAPL can be reviewed and extended when they are provided as inputs.
- Can diagnostic tests be automated without the target ECU?
- Some test work can be supported through simulation when the required network behavior is defined. The achievable scope depends on the supplied test specification, DBC, project assets, and available communication context.
- What is needed to start?
- Provide the existing CAPL, CANoe project, DBC, and test specification relevant to the requested automation.
Discuss the evidence
Discuss CAPL Automation
Share your existing CAPL, CANoe project, DBC, and test specification to define a focused automation task and identify the next engineering step.