tool-mock/docs/impl/plans/INITIAL.md

type

type
default

Initial plan

What actually needs building

Need	Answer	Ours?
A CAN bus that isn't a car	vcan — kernel module, no bitrate to configure	No
Replay real captures	canplayer, with frame mapping so a log recorded on can1 plays onto vcan0	No
Traffic before any capture exists	ICSim — simulated cluster with speed, doors, indicators	No
GNSS fix	GPX or synthetic track → yukart/gnss/fix	Yes, small
Local broker	a mosquitto config for the workstation	Trivial
App boundary peer	only if the full stack proves too heavy for Flutter iteration	Deferred

Two of the three fixtures are configuration, not code.

Why ICSim matters more than it looks

Phase 2 is the hard part of this project: correlating observed frames against a written event log to work out what the Z27AG is saying. ICSim is built for exactly that exercise — a simulated cluster with controllable speed, doors and indicators, and four noise levels where level 0 is clean packets and level 3 randomises arbitration IDs and byte positions.

So the whole decode workflow can be practised, and the decoder written and tested, before a single real capture exists. That is worth doing while the PCBs are unassembled.

Order

1. vcan bring-up script — everything else needs a bus.
2. ICSim, vendored or documented, driving vcan0.
3. GNSS fixture publishing yukart/gnss/fix.
4. Local mosquitto config, and a single entry point that brings the whole fake car up.
5. canplayer wrappers — only useful once Phase 1 has produced real captures.