Load the DBC, select the signals that represent the missing source system, define their values over time, validate the resulting frame definitions, assign the correct bus, and transmit the scenario through the intended CAN interface. Save the DBC and profile together so the test can be repeated.
What the DBC provides
A DBC describes how raw CAN frame data maps to meaningful signals. It can define arbitration IDs, message length, signal start bits and lengths, scaling, offsets, signedness, units, value ranges, and other metadata.
The DBC does not normally describe the complete test scenario. It tells the software how to encode a value; the signal profile tells the software which value to send at each point in time.
A repeatable six-step workflow
- Confirm the DBC revision. Match it to the receiving ECU, software build, or data interface being exercised.
- Select the required signals. Start with the smallest set that makes the downstream system enter the state you need to test.
- Define the start state. Give every active signal a known, safe initial value before transitions begin.
- Build time/value profiles. Create steps, ramps, holds, and coordinated transitions in the desktop editor or an Excel workbook.
- Validate before transmitting. Check frame identity, bounds, timing, bus assignment, and estimated bus load.
- Play and observe. Transmit through the real adapter, verify receiver behavior, and capture independent wire evidence when the test requires it.
Why Excel can be useful for scenario authoring
Excel is practical when many signals share the same timeline, reviewers need a familiar table, or scenario values are generated from existing calculations. The workbook can also become part of the test evidence.
A good template should keep signal identity, bus assignment, time points, and values explicit. It should not rely on hidden manual steps that the next operator cannot reproduce.
| Authoring method | Use it when | Watch for |
|---|---|---|
| Desktop profile editor | You need to shape or inspect a smaller number of signals visually. | Keep the final scenario file with the DBC and expected result. |
| Excel workbook | You need many coordinated signals, reviewable tables, or calculated values. | Validate units, time ordering, blanks, bounds, and workbook revision before import. |
| Recorded CAN log | You already have a known-good sequence and need faithful reproduction. | A capture is less convenient when you need values or edge cases that never occurred. |
Checks that prevent expensive false starts
- Standard versus extended arbitration ID is correct for every active frame.
- Classic CAN versus CAN FD and the nominal and data bitrates match the network.
- Signedness, scaling, offset, units, bounds, and byte order match the DBC revision.
- The planned message rate and overall traffic leave enough bus margin.
- The receiving system sees a stable start state before the first event.
- The test records app version, adapter, driver, bus settings, scenario revision, and observed result.
How simCAN supports this workflow
simCAN loads DBC definitions, exports an Excel scenario template, imports the completed workbook, plots selected signals, validates frame definitions, and transmits enabled profiles through compatible CAN hardware. The same app can record incoming frames and replay them later at original timing.
Because adapter and driver behavior varies, the correct evaluation is a trial on the exact Windows machine and CAN path planned for the bench.
Build one small scenario before you commit.
Choose two or three representative signals, run the workflow end to end, and confirm that the receiving system responds correctly. The 7-day trial is full-featured and does not require a credit card.