Reading an avionics bus: MIL-STD-1553 and ARINC 429

Two buses, two philosophies

MIL-STD-1553 dates from the 1970s and ARINC 429 from 1977. Both are still being specified on aircraft entering service today, which is worth pausing on: in a field where nothing lasts, these two have outlived every fashion since. The reason is that both do exactly one thing, and do it predictably.

They took opposite routes to get there. 1553 shares a single medium under central control: one bus controller decides who speaks and when, so the traffic is a repeating schedule and latency is bounded by construction. ARINC 429 gives each signal its own pair of wires and a single transmitter, so there is nothing to arbitrate — determinism by having no contention at all.

One trades wiring for protocol complexity, the other protocol complexity for wiring. A large civil aircraft ends up with hundreds of 429 buses; an aircraft built around 1553 runs a handful of them carrying everything. Both choices are defensible, and both leave a distinct signature on how you instrument them.

MIL-STD-1553: a bus with a conductor

The physical layer is a shielded twisted pair, transformer-coupled, terminated at both ends, carrying Manchester-encoded data at 1 Mbit/s. Installations are usually dual-redundant — bus A and bus B — with the controller deciding which one is in use, and that choice is itself something you want in your recording.

Everything on the bus is a word of twenty bit-times: three of synchronisation, sixteen of payload, one of parity. There are three kinds — command, data and status — and the sync pattern distinguishes command and status words from data words, which is what lets a monitor parse traffic it did not initiate.

The bus controller issues every transaction. Remote terminals, addressed from 0 to 30 with 31 reserved for broadcast, speak only when addressed and must answer within a bounded response time. A command word names the terminal, the direction, a subaddress selecting which data buffer is meant, and a word count of one to thirty-two. That last limit shapes every 1553 interface ever written: a message carries at most thirty-two words, so a large parameter set becomes many small messages on a fixed schedule.

Because the controller schedules everything, the traffic is periodic — commonly a minor frame at 50 or 100 Hz. That makes 1553 unusually pleasant to analyse: you know what should be present, so a message that fails to appear is a finding rather than a mystery.

ARINC 429: one talker, no questions asked

A 429 bus is one transmitter and up to twenty receivers, on a twisted shielded pair, at 12.5 kbit/s or 100 kbit/s. Encoding is bipolar return-to-zero — three voltage states, so a null is a real state and not just an absence. Reception is entirely passive: you wire a receiver in and nothing on the bus notices.

Every word is thirty-two bits. Eight of them are the label, written in octal by convention and transmitted least-significant-bit first — a detail that catches everyone exactly once. Two bits identify source or destination, nineteen carry the data, two carry the sign and status matrix, and the last is odd parity.

The label says which parameter this is; it does not say what the value means. The encoding — binary with a declared range and resolution, binary-coded decimal, or a field of discrete bits — comes from the specification for that label on that equipment. And the sign/status matrix says whether you are allowed to believe the number at all: valid data, no computed data, functional test, or failure warning. It is the field most often ignored, and the one that turns a puzzling analysis into an obvious one.

There is no acknowledgement and no retransmission. A corrupted word is simply wrong, and the next update comes along at the repetition rate specified for that label — which is also how a receiver detects a parameter that has gone stale.

What recording a bus actually means

You are a monitor. You never transmit, never acknowledge, and never load the bus: the tap is high-impedance or transformer-coupled, and the installation is designed so that removing your instrumentation changes nothing. If the aircraft behaves differently with your equipment fitted, your data describes a different aircraft.

Every message is time-stamped on reception, and the useful resolution is microseconds rather than milliseconds. A 1553 word occupies twenty microseconds; the question that motivated the test is very often a latency — how long between the command and the response, between the sensor update and the command that used it — and a millisecond stamp cannot answer it.

What has to be recorded is more than the payload: which of the redundant buses carried the message, the error status, the response time, and the fact that an expected message did not appear at all. A bus recording that contains only successful messages has quietly discarded the most interesting part of the flight.

The good news is that bus traffic is cheap to store. A fully loaded 1553 bus is 1 Mbit/s of raw traffic; a high-speed 429 bus is 100 kbit/s. Twenty buses together still cost less than one video channel, so filtering at the source — the classic source of "we did not record that" — is almost never justified.

In a Chapter 10 recording, bus traffic goes into message-oriented packets where every message carries its own intra-packet time. The D.T.MUX format pairs each message with a time-offset word whose resolution is selectable. Same idea, two spellings: the timing belongs to the message, not to the block that happens to carry it.

From traffic to parameters: the ICD is the real work

A raw 1553 message is a terminal address, a direction, a subaddress, a word count and up to thirty-two words of payload. Nothing in it says "airspeed". A raw 429 word is a label and nineteen bits. Nothing in it says "at 1 metre per second per count, two-complement, negative down".

What makes the traffic meaningful is the interface control document: which words of which message carry which parameter, in which encoding, with which scaling, sign convention and unit. Recording is a hardware problem that was solved decades ago. Interpretation is a configuration-management problem that is never quite solved.

And the ICD is alive. It belongs to an aircraft configuration and a software standard, and it changes between them. A decode built from last year document applied to this year traffic produces numbers that are wrong in a way nobody notices — the same failure mode as a mismatched PCM format, and just as expensive.

The discipline that pays: keep the interface description with the recording rather than in somebody folder, and use a tool that checks what can be checked — expected labels present, repetition rates plausible, status fields valid — instead of decoding in silence.

Where it goes wrong

• A tap that loads the bus, or a coupling network installed without the stub-length rules — instrumentation that changes the thing it measures.
• Ignoring the status word and the sign/status matrix, then spending a week explaining a parameter the aircraft had already flagged as invalid.
• Time resolution chosen for convenience rather than for the question: milliseconds cannot measure a bus latency.
• Assuming a message exists because the ICD says so. The schedule is what the software does, not what the document says it does.
• The label transmitted least-significant-bit first, and binary parameters read with the wrong sign convention. Both produce data that looks almost right.
• Not recording which redundant bus was active, then trying to explain a gap that was simply a switch to the other bus.

CAN and AFDX: the modern picture

CAN arrived from the automotive world and is now everywhere on light aircraft, rotorcraft, unmanned platforms and equipment-level links. It arbitrates by identifier priority rather than by schedule, which makes it event-driven: bus load varies with what the aircraft is doing, and the interesting moments are exactly the loaded ones. That makes recording more valuable, not less.

ARINC 664, better known as AFDX, rebuilds determinism on top of switched Ethernet: virtual links with a guaranteed bandwidth allocation, so a network with no central controller still has bounded latency. Recording it is an Ethernet capture problem — orders of magnitude more data than a 1553 bus, and the filtering question becomes real again.

The trend is clear: fewer dedicated buses, more network. The instrumentation problem shifts from decoding a bus to capturing and filtering a network. The configuration problem does not shift at all — you still need the document that says what the traffic means.

Back on the ground

The value of a bus recording is almost never the bus itself. It is the correlation: the commanded value on the bus next to the measured value on an analog channel, the crew action on the cockpit video, the same parameter as it appeared in the telemetry stream. That is where a test answers a question rather than producing a file.

Which brings back the condition that runs through every one of these subjects: one time reference across the whole installation, and a tool that reconstructs the timeline from the recorded time rather than from the order in which things were read. Everything else is decoding.