MWVCS pilot / sample deliverable
What a saved-log report can show.
A small, computed example. All sixteen frames were created for this demonstration; no customer or vehicle data is included.
The question
Which message IDs occur in an agreed saved-file format, how many frames belong to each, and which payload bytes change?
Input and method
One candump-format text file, sixteen frames, two message IDs and two data bytes per frame. The observation window is explicitly two seconds. The last event is at 1.5 seconds; the window was supplied separately rather than inferred from that span. No DBC or signal definition was provided.
Input SHA256: 63cc8d57f1541362e1213541c848826af17629dfde8a771db8cf7e776570170d
Computed observations
| Message ID | Frames | Frames / observation second | Changing byte offsets |
|---|---|---|---|
| 0x100 | 12 | 6.0 | 0 |
| 0x200 | 4 | 2.0 | None observed |
For 0x100, byte 0 takes twelve distinct values and byte 1 takes one. Both bytes of 0x200 stay constant in this sample. Byte offsets begin at zero. The input remains unchanged and no bus connection or vehicle command is involved.
What this does not establish
No signal names, physical units or fault meaning can be inferred from these counts alone. A changing byte could be a counter, sensor value or something else. A short unchanged sequence does not prove that a byte is always constant.
These are observations of the synthetic input, not claims about a vehicle, bus bitrate, timing reliability, diagnostic accuracy, module compatibility, safety or repair success.
An accepted pilot
The agreed deliverable would include a written report, machine-readable results, recognized and unsupported inputs, and a documented way to repeat the selected check. The dataset, output, rights, fee and acceptance conditions are set before work. This example is not a customer result or production software release.