Configuration model
The CANoe configuration brings together networks, databases, simulation behavior, measurement, and test execution. Its purpose is to make the same engineering assumptions explicit each time a test runs.
Testing, Validation & Simulation
CANoe Test Automation Guide
A practical engineering model for configuring Vector CANoe, simulating missing network nodes, executing repeatable tests, and analyzing timing and diagnostic behavior.
Engineering model
How CANoe fits together
CANoe test automation connects a network model, the behavior under test, executable test procedures, and result evaluation. The configuration defines how CAN and CAN-FD communication is represented, CAPL supplies event-driven behavior where needed, and the test specification defines expected outcomes. Reliable automation depends on controlling setup, timing, message and signal interpretation, simulation scope, and the boundary between functional testing, integration testing, and regression testing.
Core concepts
The parts of a practical CANoe setup
Executable behavior
CAPL nodes, test modules, and libraries implement stimulus, supervision, and evaluation logic. They control how the automation reacts to network events and timing conditions.
Network representation
CAN and CAN-FD define the communication behavior that the test observes or simulates, including message timing, payload interpretation, and the relationship between messages and signals.
Diagnostic interaction
UDS testing requires the automation to send diagnostic requests, observe responses, and evaluate the resulting behavior against the test specification without assuming undocumented ECU behavior.
Repeatable evidence
A test suite turns defined procedures and expected results into repeatable execution and evaluation, making regression testing less dependent on manual observation.
The automation model
Start by separating what is being stimulated, what is being simulated, and what constitutes a pass or failure.
A CANoe test generally has four logical parts: the configured communication environment, the behavior under test, the executable procedure, and the evaluation criteria. The environment may contain real communication, simulated nodes, or both. The procedure applies stimulus in a defined order, while evaluation checks observed messages, signals, diagnostic behavior, and timing against the test specification.
| Part | Primary responsibility | Typical engineering question |
|---|---|---|
| Configuration | Defines networks, databases, simulation, and test assets | Is the test environment representing the intended communication? |
| Stimulus | Produces the inputs required by the procedure | What message, signal, or diagnostic interaction starts the scenario? |
| Observation | Collects behavior relevant to the expected result | Which message, signal, response, or timing condition is evidence? |
| Evaluation | Applies assertions and acceptance criteria | What exact observation distinguishes pass, failure, and incomplete execution? |
Prepare the CANoe configuration
Configuration quality determines whether an automated failure represents the system or only an incomplete test environment.
- 01
Inspect the existing project
Identify the configured networks, existing CAPL nodes, test modules, libraries, and available project assets before adding new behavior.
- 02
Confirm the communication model
Check that the relevant CAN or CAN-FD messages and signals are represented consistently with the DBC and the intended test scenario.
- 03
Define simulation boundaries
Decide which missing network nodes must be represented by a restbus simulation and which behavior is supplied by the target ECU or other connected elements.
- 04
Connect the test procedure
Associate the test specification with executable setup, stimulus, observation, and evaluation logic so that the procedure can run without undocumented manual actions.
- 05
Perform a controlled dry run
Run the smallest meaningful scenario first and inspect whether setup, communication, timing, and evaluation occur in the intended order.
- Treat the existing CANoe project and existing CAPL as inputs to understand, not as proof that the configuration is test-ready.
- Keep configuration changes traceable to a test requirement or a required simulation behavior.
- Avoid allowing an absent ECU or vehicle to silently change the scenario; represent the missing communication explicitly when required.
Use CAPL for deterministic test behavior
CAPL is most useful when event-driven network behavior, timing supervision, or reusable test logic must be made executable.
A CAPL script can implement network simulation, stimulus generation, event handling, and test-related evaluation. The script should make state transitions and timing assumptions visible: identify what starts a step, what observation ends it, what timeout applies, and what condition records a failure. Reusable libraries can reduce duplication, but they should not hide the acceptance criteria that explain why a test passes or fails.
- Use event-driven logic for message or signal observations rather than relying only on elapsed execution time.
- Keep setup, stimulus, observation, and cleanup responsibilities distinct within the test behavior.
- Record the condition that caused an assertion to fail, including the expected and observed behavior where available.
- Make timeout handling explicit so a missing response is not confused with a late response or an incorrectly decoded response.
- Reuse stable CAPL behavior only when its assumptions match the current CANoe configuration.
Build tests around observable behavior
A good automated test turns the test specification into a sequence of controlled actions and unambiguous observations.
- 01
Define the initial state
Specify the required communication and configuration conditions before stimulus is applied. If the state cannot be established automatically, identify that limitation explicitly.
- 02
Apply one meaningful stimulus
Send or change the input required by the test case, using the network or diagnostic interaction defined by the specification.
- 03
Observe the response
Monitor the relevant message, signal, response, or timing behavior instead of inferring success from the stimulus itself.
- 04
Evaluate the acceptance condition
Compare the observation with the expected result and distinguish a failed assertion from a timeout or unavailable test prerequisite.
- 05
Restore or isolate state
Return the environment to a known condition where practical, or ensure that the next test does not inherit unexamined state from the previous one.
The smallest useful test is not necessarily the shortest test. It is the smallest test whose setup, stimulus, observation, and evaluation provide enough evidence for the stated expected result. Splitting unrelated expectations into separate tests usually makes regression failures easier to localize.
Handle timing and network behavior
Many automation failures are timing-model failures rather than functional failures, so timing must be treated as test data.
| Behavior | What to inspect | Reasoning |
|---|---|---|
| Message period | Intervals between relevant messages | A message can be present but still violate the expected periodic behavior. |
| Response latency | Time from stimulus to observed response | The response may be correct but outside the acceptance condition. |
| Ordering | Sequence of related messages or signals | An expected set of messages in the wrong order can indicate a different state transition. |
| Timeout | Maximum wait for an expected observation | A timeout should identify the missing observation without assuming why it is missing. |
| Bus representation | CAN or CAN-FD configuration and decoded content | A mismatch in network representation can create misleading timing or payload results. |
Use timing measurements consistently across the test suite. Avoid arbitrary delays as substitutes for event-based synchronization when the expected behavior is defined by a message, signal, or diagnostic response. When a timing issue appears, separate scheduling, communication, decoding, and target behavior hypotheses before changing thresholds.
Simulate missing network nodes
Restbus simulation allows testing to proceed when an ECU or complete vehicle is unavailable, but it must represent only the behavior required by the scenario.
A restbus simulation supplies communication from missing network nodes so that the behavior under test can interact with a defined network environment. The simulation should identify which messages and signals it produces, when it produces them, and which state changes cause those outputs. Unnecessary simulation can conceal integration defects by making the environment more cooperative than the real system.
- Define the minimum simulated communication needed by the test specification.
- Represent message periods, ordering, and relevant signal values deliberately.
- Keep simulated responses distinguishable in the configuration and test reasoning from responses produced by the target ECU.
- Test simulation transitions, not only steady-state messages.
- Reassess the simulation when the DBC, CAPL behavior, or expected network interaction changes.
Include diagnostic test cases carefully
UDS automation requires precise request and response handling while avoiding assumptions about ECU behavior that are not in the test specification.
For a UDS test, define the diagnostic interaction as an observable exchange: establish the required initial condition, issue the specified request, observe the response, and evaluate the expected result. The test should make transport and timing assumptions visible where they affect the procedure, but it should not infer undocumented service behavior from a single response.
- 01
Identify the diagnostic precondition
State the communication and ECU condition required before the request is sent.
- 02
Send the specified interaction
Use the request defined by the test specification and preserve the sequence required by that procedure.
- 03
Observe the response
Check the response content and timing that the specification identifies as relevant.
- 04
Evaluate conservatively
Record the observed result and distinguish an unexpected response, timeout, and unavailable prerequisite rather than collapsing them into one failure.
Engineering pitfalls
Common mistakes
Using fixed delays for every synchronization point
A fixed delay can hide variable response timing and make tests slow or flaky. Prefer synchronization on the relevant observed behavior, with an explicit timeout and a defined evaluation condition.
Treating message presence as functional proof
Seeing a message does not prove that its signal values, period, ordering, or triggering condition are correct. Evaluate the properties required by the test specification.
Reusing state between tests unintentionally
A previous test can leave simulated nodes, signals, or diagnostic conditions changed. Establish a known precondition or isolate the test so that execution order does not determine the result.
Overbuilding the restbus simulation
Simulating more behavior than the scenario needs can mask integration problems. Keep the simulated network boundary explicit and limited to the required evidence.
Changing thresholds to remove failures
Widening timing or value tolerances without understanding the observation can convert a real defect into a pass. First determine whether the issue is in configuration, decoding, timing, stimulus, or target behavior.
Assuming a diagnostic response has one guaranteed cause
A UDS response or timeout is evidence about the observed interaction, not automatic proof of root cause. Compare it with setup, network observations, and the test specification.
FAQ
CANoe questions
- What should a CANoe automated test contain?
- At minimum, it should define the initial condition, stimulus, observable response, acceptance condition, timeout behavior, and any required restoration or isolation of state. These elements connect the test specification to repeatable execution.
- When is a restbus simulation appropriate?
- Use it when missing network nodes would otherwise block the scenario and when their required communication can be defined sufficiently for the test. The result should be interpreted as behavior under the simulated environment, not as complete vehicle validation.
- How should timing failures be investigated?
- First determine whether the issue concerns message period, response latency, ordering, timeout, network representation, or decoding. Compare the observed sequence with the test specification before changing thresholds or adding delays.
- Can CAPL replace the test specification?
- No. CAPL can implement executable behavior, but the test specification should remain the source for procedures, expected results, and acceptance criteria. Keeping those concerns distinct makes the automation easier to review and maintain.
- How does automation support regression testing?
- A stable CANoe configuration and automated test suite can repeat the same setup, stimulus, observations, and evaluations after a change. Regression value depends on controlled preconditions and meaningful assertions, not on execution count alone.
Engineering support
Discuss a CANoe Project
Need help structuring a CANoe configuration, CAPL automation, or repeatable test suite around your existing project and test specification?