Define the CAN contract with a known DBC revision, create time/value profiles for the signals the receiver consumes, start from a documented state, and preserve the scenario as a reusable test asset. Dry run validates the model; a live bench verifies the complete adapter-to-receiver path.
The missing system is usually a schedule problem
Downstream software often becomes ready before the hardware that supplies its inputs. Waiting makes integration risk appear late. Hand-entering constants may unblock a screen, but it does not exercise timing, transitions, thresholds, state changes, or coordinated signals.
A generated CAN scenario gives the downstream team stable inputs and lets them repeat the same sequence after every software change.
Define the receiver contract
- List only the messages and signals the receiving system actually uses.
- Record the DBC revision, frame format, units, scaling, bounds, and expected rates.
- Choose a known start state before any transitions occur.
- Write the expected receiver response for each important phase.
- Identify which evidence is needed from the app, adapter, bus, and receiving system.
Build behavior, not just frames
Use ramps for realistic changes, steps for threshold handling, holds for stable-state behavior, and coordinated points when several signals define one operating state. Add edge cases deliberately rather than hoping a recorded drive happens to contain them.
With simCAN, profiles can be edited visually or in Excel and then validated before playback. The resulting workbook can travel with the test case.
Move from simulation to evidence
| Stage | What it proves | What it does not prove |
|---|---|---|
| Dry run | Scenario structure, profile behavior, packing configuration, and internal scheduling. | Adapter, wire, bus, or receiver delivery. |
| Adapter benchmark | The driver and adapter path can accept a controlled workload. | Independent wire timing or receiver processing. |
| Live bench + analyzer | Traffic observed on the bus under the tested configuration. | Behavior outside that configuration. |
| Receiver evidence | The downstream system handled the intended inputs and states. | Unobserved failure modes. |
Keep the substitute honest
Do not make the generated source more perfect than reality unless the test explicitly calls for it. Model startup delays, valid and invalid states, limits, missing updates, and recovery behavior when they matter. Label assumptions so a later hardware comparison can reveal what changed.
Start with a visible working scenario.
Download the free starter pack, run it in Dry run, and replace the example signal with the inputs your receiving system needs.