Use record and replay to reproduce a known bus sequence for debugging or regression. Use DBC-based generation to create deliberate signal values, transitions, and edge cases. Combine them when a recorded baseline should be followed by controlled variations.
What record and replay preserves
A timestamped CAN log can preserve the frames and relative timing observed during a real event. Replaying that log is a direct way to put the same traffic in front of a parser, logger, visualization, gateway, or other downstream component.
This is especially useful when the original system is unavailable, the event is difficult to reproduce, or the software team needs the same input every time a regression test runs.
What generated scenarios add
A generated scenario starts with signal definitions and an intended behavior. Instead of accepting only the values found in a capture, you can create controlled ramps, steps, holds, limits, start states, and coordinated transitions.
That makes generation useful for integration work before real data exists, testing receiver behavior at boundaries, and building a small, understandable test case from a larger network definition.
Choose by the question the test must answer
| Test question | Better starting method | Reason |
|---|---|---|
| Can we reproduce a field or bench issue? | Record and replay | Preserves the traffic sequence that accompanied the observed event. |
| Does the receiver handle a value boundary or transition? | Generated scenario | Creates the exact signal behavior needed, even if it was never captured. |
| Can a new parser or post-processor handle known input? | Record and replay | Provides a stable regression input with an expected result. |
| Can development begin before the source system is available? | Generated scenario | Emulates the required signals from definitions and an intentional profile. |
| Does a change still handle normal traffic and edge cases? | Both | Replay the baseline, then run targeted generated variations. |
A practical combined workflow
- Record a known-good sequence with timestamps and keep the matching DBC revision.
- Replay it into the downstream system and save the expected output as a regression baseline.
- Identify the signals and transitions that matter to the next engineering question.
- Build smaller DBC-based scenarios for those values, boundaries, or timing relationships.
- Run the baseline and targeted variations through the same physical CAN path.
- Save the scenario, log, hardware path, settings, and result together.
Timing claims require the right evidence
Original-timing replay means the software schedules frames according to the timestamps in the log. The complete path still includes the operating system, driver, adapter, bus load, and receiver.
Use application diagnostics to identify scheduling or adapter limitations. If the result depends on precise observed frame timing, measure it independently with an analyzer or logger on the wire.
How simCAN supports both methods
simCAN can record incoming CAN traffic to timestamped logs and replay those logs at original timing. It can also load DBC definitions, build or import signal profiles, plot them, validate frame definitions, and transmit generated scenarios through compatible CAN hardware.
This keeps reproduction and deliberate variation in one Windows bench workflow while preserving the distinction between internal diagnostics and independent wire evidence.
Run a baseline and one deliberate variation.
That small test will tell you whether the combined workflow fits your downstream software or controller, Windows machine, and CAN adapter.