It turns a signal definition into values over time, then repeatedly calculates the encoded CAN frames for that timeline. The useful output is a saved scenario that lets a controller, logger, parser, visualization, or other downstream system receive the same planned inputs after each change.
Choose the transition that answers the test question
| Profile pattern | Use it to test | Define before the run |
|---|---|---|
| Known start and hold | Initialization, stable-state display, or downstream settling. | Start value, hold duration, receiver precondition, and expected stable state. |
| Ramp | Tracking behavior, thresholds crossed over time, and rate-sensitive logic. | Start, end, slope, units, bounds, and the expected response along the ramp. |
| Step | Threshold decisions, mode changes, and event handling. | Pre-step value, post-step value, exact transition time, and expected latency evidence. |
| Hold after change | Debounce, persistence, timeout, or state-retention behavior. | Hold length and the observation that proves the receiver remained in the intended state. |
| Return or recovery | Reset paths, hysteresis, and exit criteria. | Recovery value, transition shape, final state, and whether the scenario will repeat. |
| Coordinated signals | Logic that depends on more than one changing input. | Shared timeline, ordering, valid combinations, and the expected result at each phase. |
Start with one visible 12-second profile
The free simCAN starter pack includes a generic VehicleSpeed example that is intentionally easy to inspect. It holds zero, ramps upward, holds, falls, and returns to zero over 12 seconds. Run it in Dry run first so you can verify the timeline without claiming anything about a hardware path.
- Download the matching example DBC and Excel scenario.
- Import the workbook and confirm the plotted start, ramp, hold, and return phases.
- Choose Validate and resolve model, range, or timing warnings.
- Run in Dry run and compare the visible values with the planned timeline.
- Replace the example with the DBC, signals, bounds, rates, and expected receiver behavior for your own test.
The sample is a workflow demonstration, not a compatibility or outcome claim for a particular vehicle, sensor, controller, adapter, or test platform.
Build the profile from the receiver backward
- Name the receiver decision. Write the state, threshold, calculation, display, or log output that should change.
- Identify the minimum CAN contract. Confirm the approved DBC revision and the smallest set of messages and signals required by that receiver.
- Set a known start state. Give every enabled signal an explicit value before the first event.
- Add time/value points. Use the desktop editor for a smaller visual workflow or an exported Excel scenario for many reviewable profiles.
- State the expected result per phase. Do this before observing the receiver so the pass condition does not move after the run.
- Validate, dry-run, then qualify the real path. Check encoding and sequence first; only then test the intended Windows, driver, adapter, bus, and receiver configuration.
- Save the scenario with its evidence. Keep the DBC revision, workbook, settings, result, deviations, and run date together.
For DBC packing and workbook details, use the DBC-to-signal workflow. Use the CAN test case template to record the receiver goal and expected evidence.
Plan coordinated profiles without hiding assumptions
Multi-signal behavior is useful only when the combinations are intentional. Put related signals on a shared timeline, make their start state explicit, and document which value changes first when ordering matters. If two profiles must remain physically or logically consistent, state that rule in the test case and review the generated points before playback.
simCAN profiles repeat after their configured duration. Check the end-to-start transition as carefully as the main event, especially when continuous playback could make an unrealistic jump. Stop after one cycle when the test requires a single event, or design a final state that is safe to repeat.
Know what each result proves
| Observation | It can support | It does not independently prove |
|---|---|---|
| Profile plot and Dry run | The intended values and internal timeline are present. | Adapter operation, wire traffic, or receiver delivery. |
| Validation result | The loaded model passed the checks reported by the application. | That the DBC matches an external system or that the bench is wired correctly. |
| Schedule health and accepted sends | The application and adapter path accepted the tested workload as reported. | Independent wire timing or downstream processing. |
| Independent bus observation | Traffic was observed on the tested bus configuration. | The receiver interpreted or acted on every value. |
| Receiver logs or behavior | The downstream system produced the recorded result for this scenario and setup. | Performance outside the saved test conditions. |
See the CAN timing and evidence guide when message rate or delivery is part of the pass/fail result.
Generate a variation or replay a capture?
Use a generated profile when you need controlled values, a planned threshold crossing, or behavior that has not yet occurred on the real system. Use record and replay when an existing capture already contains the baseline you need. A practical regression plan can replay the known baseline, generate one deliberate variation, and compare the downstream result.
The record/replay comparison helps choose the right starting point. If the complete source system is delayed, follow the guide to develop the downstream system against repeatable CAN inputs.
Inspect a profile before building your own.
Start with the free DBC and Excel sample, verify its 12-second sequence in Dry run, then replace it with the CAN contract and receiver evidence your bench requires.