MIL-STD-1553¶

This page teaches how MIL-STD-1553 turns bus authority into transaction-shaped evidence: who was commanded, what role each word played, and what a passive bus monitor can and cannot infer.

A Concrete Artifact¶

# synthetic BC-to-RT7 receive transaction
BC -> RT7 command word: 0x3983
BC -> RT7 data words:   0x1234 0x5678 0x9ABC
RT7 -> BC status word:  0x3800

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

Inspection Trap¶

An isolated 16-bit word is not enough evidence. A value such as 0x3983 becomes a command word only in transaction context, and the data words that follow get their role from that command. Treating every word as a standalone value destroys the authority and timing evidence that makes MIL-STD-1553 inspectable.

The safer claim is transaction-shaped: a passive bus monitor can reconstruct the observed command, data, status, missing status, broadcast behavior, and redundant bus path evidence. It cannot command the bus or infer platform data semantics without RT maps and integration context.

Worked Decode¶

1. 0x3983 is treated as a command word in this transaction context, not as arbitrary data.
2. The command addresses RT 7, uses receive direction from the RT perspective, selects subaddress 12, and requests word count 3.
3. The following data words 0x1234, 0x5678, and 0x9ABC are accepted as application data only because the command context predicted three words.
4. The status word 0x3800 is terminal-response evidence. In the simplified model it identifies RT7 and carries no modeled status flags.
5. A word-count code 0 is treated as 32 only for ordinary transfer commands; subaddresses 0 and 31 are mode-code space, where the low five bits are mode-code evidence rather than ordinary word count.
6. The transaction is valid only as an ordered exchange. The command predicts who may speak, direction, subaddress, and word count. A missing or late status word is evidence, not just an absent field.

What The Evidence Supports¶

The artifact supports a bounded bus-monitor claim: a bus controller was observed authorizing a BC-to-RT7 receive transaction for subaddress 12, word count 3, followed by three data words and a terminal status response from RT7.

Authority is architectural. Words are typed by context. Messages are transactions. Observation is explicit: the monitor reconstructs what was observed on the bus, not what off-bus equipment truly did with the data.

What The Evidence Does Not Support¶

The artifact does not prove application meaning for 0x1234, 0x5678, or 0x9ABC; it does not prove subsystem state, response-timing conformance, redundant-bus health, or certification behavior; and it does not cover the full mode-code, broadcast, redundancy, electrical, or response-timing behavior of the standard.

Broadcast changes the observer claim: it suppresses per-terminal status, so successful reception by every RT is not directly observed. Per-terminal status evidence exists after this non-broadcast transaction, but not after a broadcast-shaped transaction in the teaching model.

Field Layout / Anatomy¶

Visual Model¶

BC command  ->  data word 1  ->  data word 2  ->  data word 3  ->  RT status
 authorizes              transaction evidence                  response evidence

Timing And Authority¶

Authority is centralized in the active bus controller. Remote terminals do not speak unless commanded, and a bus monitor never participates. Timing is validity evidence: response presence, response order, suppressed status, retry behavior, and redundant-bus use shape what an observer can infer. Timing is validity evidence for the transaction, not application truth. Observed redundant bus paths still need schedule context before they become a system health claim.

Command/status/data roles explain the bus transaction. Application meaning still comes from RT maps, subaddress conventions, word offsets, mode-code behavior, and platform integration documents that this binder does not redistribute.

Failure And Ambiguity¶

• Treating a data word as a command word destroys context; words are typed by transaction position.
• Mode-code, broadcast, and ordinary subaddress behavior must not be conflated.
• Broadcast suppresses per-terminal status, so successful reception by every RT is not directly observed.
• Missing status after a non-broadcast command is different evidence from suppressed status after a broadcast-shaped command.
• A broadcast-shaped transaction with a status word is anomalous in this teaching model.
• Status bits reveal terminal conditions, but application data meaning still depends on RT maps and word offsets.
• Redundant standby bus paths can hide failures unless the observer captures both paths and schedule context.
• This page is not full conformance coverage for mode-code, broadcast, redundancy, electrical, or response-timing behavior.

Python Model¶

The current package exposes a concrete transaction example:

"""Runnable MIL-STD-1553 transaction example for the schoolbus binder."""

from schoolbus.protocols.milstd1553 import MilStd1553Transaction

transaction = MilStd1553Transaction.bc_to_rt(
    remote_terminal=7,
    subaddress=12,
    data_values=(0x1234, 0x5678, 0x9ABC),
    status=7 << 11,
)

print(transaction.show_fields())
print(transaction.explain())

The model focuses on command/status/data roles and safe synthetic transaction explanation.

The passive monitor example shows mode-code-shaped, broadcast-shaped, and RT-to-RT transaction evidence without adding a bus-controller scheduler or live monitor:

"""Runnable MIL-STD-1553 passive monitor example for the schoolbus binder."""

from schoolbus.protocols.milstd1553 import CommandWord, MilStd1553Transaction

mode_command = CommandWord.from_int((7 << 11) | (31 << 5) | 2)
print(mode_command.explain())

broadcast = MilStd1553Transaction.broadcast(
    subaddress=12,
    data_values=(0x1234, 0x5678),
)
print(broadcast.explain())

rt_to_rt = MilStd1553Transaction.rt_to_rt(
    transmitting_remote_terminal=4,
    receiving_remote_terminal=7,
    subaddress=12,
    data_values=(0x1111, 0x2222),
    transmit_status=4 << 11,
    receive_status=7 << 11,
)
print(rt_to_rt.explain())
print(rt_to_rt.show_fields()["transfer_kind"])

The first workbook sample pack includes a passive synthetic MIL-STD-1553 fixture under samples/first-workbook/ for command, data, and status-word inspection without naming platform-specific engineering values.

The avionics workbook adds passive monitor transaction-shaped evidence under samples/avionics-workbook/, including broadcast suppressed status, missing non-broadcast status, word-count mismatch, contradictory status terminal identity, and mode-code evidence.

The artifact is synthetic and intentionally omits electrical waveforms, Manchester encoding, exact response-time windows, coupling methods, retry policy, detailed mode-code tables, and conformance-testing behavior.

Source Notes¶

References¶

Public Sources¶

• DLA ASSIST / U.S. Department of Defense
• MIL-STD-1553 Digital Time Division Command/Response Multiplex Data Bus — canonical-standard metadata.
• UEI
• MIL-STD-1553 tutorial — vendor tutorial.

Project posture is aggregated in the protocol support policy, source policy, and project charter.