BLF / Binary Logging Format¶

Vector binary log format for CAN, LIN, FlexRay, Ethernet, and related captures.

Identity¶

Vector binary log format for CAN, LIN, FlexRay, Ethernet, and related captures.

What This Protocol Teaches¶

• A proprietary log format can become de facto infrastructure.
• It teaches how to inspect timestamped records, channel identifiers, bus-specific events without mistaking field extraction for meaning.
• It keeps observer inference separate from system truth.

Operational Context¶

BLF / Binary Logging Format appears in automotive, capture-format contexts and is modeled in the atlas at the capture-format layer(s). The binder treats it as an inspection surface: what evidence appears, what timing matters, and what outside authority is required before assigning meaning.

draft-structure-only: this is not yet a final-copy binder page. It has an atlas-grounded teaching hook and source notes, but still needs a stronger worked trace, page-specific ambiguity case, and reviewer-validated visual before promotion.

A Concrete Artifact¶

# synthetic BLF summary
object=CAN_MESSAGE timestamp=0.010 channel=1 id=0x123 dlc=8 data=10 27 ...

Synthetic offline sample for explanation; not a real operational trace or live-system instruction.

Worked Decode¶

1. Treat object=CAN_MESSAGE as a log-object classification in a synthetic capture summary.
2. timestamp=0.010 and channel=1 are capture metadata, not hardware proof.
3. id=0x123 dlc=8 data=10 27 ... is preserved traffic evidence, not decoded signal meaning.
4. The page can teach provenance and record shape while staying docs-only for BLF parsing.

Field Layout / Anatomy¶

Visual Model¶

Timing And Authority¶

Timing and authority depend on the log-format role: scheduled, polled, arbitrated, transmitted, or logged evidence should not be read as the same kind of truth. Semantic authority is external to the raw artifact unless the artifact is itself a description or capture format; even then, provenance determines whether the description should be trusted.

Bytes rarely explain themselves. Name the source that defines meaning before naming engineering values: standard metadata, label table, DBC, PGN/SPN definition, object dictionary, register map, DID catalog, LDF, ARXML, channel metadata, or vendor profile.

Failure And Ambiguity¶

• Binary log object summaries can hide parser assumptions and dropped metadata.
• Channel labels are capture-file evidence, not hardware proof.
• A converted summary can preserve bytes while losing original provenance.

Observer Lesson¶

A passive observer can usually infer artifact boundaries, repeated structure, cadence, missingness, and candidate state transitions. The observer usually cannot prove physical truth, application intent, complete system state, or engineering-unit meaning without semantic authority and timing provenance.

Python Model¶

schoolbus does not parse this format in this wave. This page records source posture, passive inspection questions, and metadata boundaries only. Runtime support would require a separate approved plan with concrete synthetic artifacts, tests, and source-checked parser boundaries.

Local Teaching Notes¶

The artifact and diagrams are synthetic teaching material. The page intentionally omits conformance timing tables, electrical design detail, proprietary configuration, and exhaustive standard behavior.

Source Confidence¶

Source confidence is medium for scope and terminology, with semantic claims limited to public metadata, public source notes, and synthetic teaching artifacts.

Source Notes¶

References¶

Public Sources¶

• Vector
• Vector logging formats context — vendor tooling context.
• Tooling references
• python-can — CAN log inspection and offline lab context.
• cantools — description-file parsing and signal inspection.