A useful test case records the receiver goal, DBC revision, messages and signals in scope, known start state, time/value transitions, bus settings, expected receiver response, and the evidence needed to judge the run. Keep that plan with the editable scenario and the observed result.
Copy this scenario brief
| Field | What to record | Why it matters |
|---|---|---|
| Test objective | The receiving behavior or decision you need to exercise. | Keeps the scenario tied to a downstream result. |
| Source assumption | What upstream system is unavailable or being represented. | Makes the substitute and its limits explicit. |
| Definition set | DBC filename, revision, frame format, units, scaling, bounds, and expected rates. | Prevents a plausible profile from using the wrong encoding. |
| Start state | Initial signal values, message enablement, bus assignment, and receiver preconditions. | Lets the next operator begin from the same state. |
| Scenario phases | Steps, ramps, holds, timing, and coordinated changes. | Turns static values into intentional behavior. |
| Expected result | The visible receiver response at each important phase. | Defines success before observing the run. |
| Evidence plan | Dry-run output, app diagnostics, independent bus observation, receiver logs, or screenshots. | Separates what each observation can actually prove. |
| Run record | Date, operator, software version, hardware settings, result, deviations, and saved files. | Makes later playback and comparison possible. |
Example: a visible 12-second receiver input
The free simCAN starter pack uses one generic VehicleSpeed signal so the scenario is easy to inspect. A test-case plan for that sample can be written before opening the app:
| Time | Input profile | Expected observation |
|---|---|---|
| 0–1 s | Hold 0 km/h. | The receiver remains in its stopped state. |
| 1–4 s | Ramp from 0 to 50 km/h. | The receiver follows the increasing value without an unexpected reset. |
| 4–7 s | Hold 50 km/h. | The receiver maintains the stable state. |
| 7–9 s | Ramp down to 15 km/h. | The receiver follows the decreasing value. |
| 9–12 s | Return to 0 km/h. | The receiver returns to its stopped state. |
This is a workflow example, not a claim about a specific vehicle, sensor, controller, adapter, or test platform. Replace the sample signal and expected observations with the CAN contract your receiver actually consumes.
Build the repeatable playback asset
- Start with the receiver objective and list only the messages and signals it needs.
- Load the approved DBC and confirm the definitions that will be used for packing.
- Export or create an Excel scenario with explicit start values and time/value points.
- Save the DBC, workbook, test-case brief, and expected result together.
- Run in Dry run and review the profile and packed-frame configuration before connecting hardware.
- Move to an isolated bench only after the channel, bitrate, frame format, identifiers, scaling, termination, and evidence plan are approved.
- Record the tested configuration and observed result so the same scenario can be played after the next downstream change.
For the detailed file workflow, see how to generate CAN signal profiles from a DBC. Use the signal profile authoring guide to choose the start, ramp, hold, step, recovery, and coordinated phases. If the complete upstream system is delayed, use the companion guide to simulate the receiver inputs first.
Match evidence to the claim
| Evidence | Reasonable conclusion | Do not conclude |
|---|---|---|
| Dry run | The scenario model, values, and internal sequence behave as planned. | That the adapter, wire, bus, or receiver saw the frames. |
| App schedule health | The application requested and accepted the planned schedule under the tested conditions. | Independent wire timing or receiver delivery. |
| Adapter acceptance | The selected driver and adapter path accepted the tested workload. | That every frame appeared on the bus or was processed downstream. |
| Independent bus observation | The analyzer observed traffic on the tested bus configuration. | Receiver behavior that was not separately observed. |
| Receiver logs or behavior | The downstream system responded to the tested inputs as recorded. | Performance outside the saved configuration and scenario. |
Finish with a replay check
A test case is not repeatable merely because its files were saved. Ask a second operator—or your future self—to open the same DBC and workbook, establish the documented start state, run the scenario, and find the expected evidence without relying on memory.
Use the 22-point CAN bench checklist before live transmission. When a recorded baseline already exists, compare this generated workflow with CAN record and replay testing.
Start from files you can inspect.
Download the free workbook and matching example DBC, run the 12-second sample in Dry run, then use this template to replace it with your own receiver contract.