Protocol coverage

This page is the map of what machbus exercises today. Read it as an evidence guide, not as a promise about every device or every corner of ISO 11783, J1939, or NMEA 2000.

The short version:

• a lot of low-level wire formats have fixture and property coverage;
• the in-process virtual bus covers many multi-node workflows;
• the C and Python bindings are tested against the same virtual-bus behavior;
• real vcan and physical-bus captures are planned, but the required capture rows are still open until reports and reduced traces are checked in.

The machine-readable detail lives in assets/protocol_matrix.csv. This prose page is the human version: it explains how to read that matrix and where to go next.

Reading the evidence levels

If a row has only fixture or virtual-bus coverage, treat it as local software evidence. For the hardware-evidence contract, future completed rows must link to a named reduced-hardware trace and a capture report before they are used as hardware evidence.

Areas with strong local coverage

These areas are currently the best exercised parts of the port. The evidence is still local, but it is broad enough that regressions should be caught quickly.

ISOBUS application families

The library also has higher-level session plugins for common ISOBUS roles. In most cases, the Rust side is richer than the C/Python facade, and the docs explain the facade separately.

For a tutorial-style entry point, start in the Tutorials section of the book instead of this reference page.

Binding coverage

The Rust API is the implementation surface. The C and Python APIs expose a stable subset:

• C is checked by make bind-c-check, make c-demo, and make c-full-demo (the examples/c_abi/ demos against the generated include/machbus.h).
• Python is checked by make python-demo, which runs the basic example, regression runner, wheel build, wheel install, and the same regression smoke from a disposable environment.

The binding contracts are described in audit/bindings.md. When a Rust feature is not yet exposed through C or Python, do not infer a binding promise from the Rust module alone.

Trace and hardware path

Trace tooling exists now:

• examples/candump_replay.rs parses compact and bracketed candump text;
• tests/fixtures/traces/manifest.txt records provenance for checked-in traces;
• make trace-replay-demo replays the current trace fixtures;
• the hardware-evidence fixtures under tests/fixtures/hardware/ and tests/fixtures/traces/ track required future capture rows (maintained by hand).

The hardware-facing documentation is in hardware-evidence.md. The current open capture IDs are:

The public-data evidence ID is ddi_public_database_refresh. It is separate from the capture list because DDI freshness is proven by source provenance, refresh metadata, generated-file diffs, and a public-data report rather than by a CAN trace.

How to use the CSV matrix

Use assets/protocol_matrix.csv when you need exact row-level status. The CSV is intentionally boring and machine-readable; keep it updated by hand as coverage changes.

Use this page when you need the story:

1. find the protocol family above;
2. check whether evidence is fixture-only, virtual-bus, binding, trace, or hardware evidence;
3. open the named source/test files;
4. add new evidence to the CSV, tests, and docs together.

When in doubt, prefer narrower wording. A single passing byte fixture proves that byte fixture. It does not prove a whole protocol family.