5.5.28 · D5Embedded Systems & Real-Time Software
Question bank — MIL-STD-1553 — military avionics bus
Before you start, a two-line refresher on the vocabulary used below (never guess at a term you can't state):
- Bus Controller (BC) ::: the single "dictator" node — the only node allowed to start a transaction; everyone else waits to be spoken to.
- Remote Terminal (RT) ::: a slave device (radar, nav, weapons) that speaks only in reply to a BC command.
- Bus Monitor (BM) ::: a passive listener that logs traffic and never transmits.
- Word ::: one 20-bit unit on the bus = 3-bit sync + 16 data bits + 1 parity bit.
True or false — justify
TF1. "MIL-STD-1553 is just a slow version of RS-485 Protocol."
False. Both use differential twisted pair, but RS-485 is multi-master with no arbiter, so collisions are possible; 1553 is strictly command/response with one BC, so collisions are structurally impossible — a completely different guarantee, not just a slower one.
TF2. "Because Manchester II guarantees an edge every bit, a 1553 receiver never loses clock sync even on 32 identical data words."
True. Every bit period holds a mandatory mid-bit transition, so the longest gap without an edge is regardless of the data pattern — the PLL always has something to lock onto.
TF3. "Adding a third redundant bus would roughly triple the reliability over the dual-bus design."
False. Reliability follows : two buses already give (e.g. ), so a third only drops loss probability by another factor of into diminishing returns, while adding real weight and cost — which is why avionics stops at two.
TF4. "An RT can start a transaction on its own if it has urgent data (e.g. a threat warning)."
False. An RT can only request service by setting the Service Request bit in its Status Word; the BC must then decide to poll it. The RT never seizes the bus itself — that would break determinism.
TF5. "The 3-bit sync field is just three ordinary Manchester bits at the front of the word."
False. The sync is a deliberately invalid Manchester pattern (3 steady LOW or HIGH with no mid-bit transition), so it can never be mistaken for data — that is exactly what makes word boundaries unambiguous.
TF6. "Transformer coupling exists mainly to boost the signal voltage."
False. It exists for galvanic isolation (breaking ground loops) and for a benign failure mode — a dead stub looks like an open circuit rather than shorting the bus. Voltage is set by the driver, not the transformer.
TF7. "1 Mbit/s was a technical embarrassment even in 1973; they just couldn't build faster."
False (mostly). It was a deliberate trade: at ~1 MHz the wavelength (~300 m) tolerates 100+ ft cables and sits below most engine-ignition EMI (>10 MHz), and 1973 pulse transformers could hold clean edges there. Slow was the correct engineering choice.
TF8. "A Bus Monitor is a third kind of active node that can take over if the BC dies."
False. A BM is purely passive — it only listens and logs. BC failover is handled by promoting a backup BC, a different mechanism entirely, not by the monitor.
Spot the error
SE1. "Word Count = 0 means the RT sends nothing."
Error. A Word Count field of 0 encodes 32 (the maximum), because the 5-bit field can't otherwise reach 32. Zero data words is simply never a valid request.
SE2. "The T/R bit tells the RT which bus, A or B, to answer on."
Error. T/R (Transmit/Receive) tells the RT the direction of data — 1 = RT transmits, 0 = RT receives. Bus A vs B is decided by which physical channel the BC drove the command on, not by any bit in the word.
SE3. "Total time for an 8-data-word transmit command is ."
Error. You forgot the response-time gap. It's (command) (RT response gap) (status) (8 data words) . The inter-message gaps are part of deterministic timing, not overhead to ignore.
SE4. "Since Manchester needs an edge every bit, a 20-bit word has exactly 20 transitions."
Error. There is always a mid-bit transition (20 of those), but there may or may not be a boundary transition between consecutive bits depending on whether the levels match — plus the sync deliberately has no mid-bit edge. So "exactly 20" is wrong on both ends.
SE5. "The BC sends on Bus A, waits, and only uses Bus B if A times out."
Error. In normal dual-redundant operation the BC sends the same message on both buses (with a small offset), and the RT uses whichever valid copy arrives first. Bus B is not merely a cold spare woken after a timeout.
SE6. "Differential signaling removes all noise from the line."
Error. It cancels only common-mode noise — interference that hits both wires equally. Noise that couples differently onto the two wires (differential-mode) survives; twisting the pair is what keeps most real noise common-mode.
SE7. "Parity failure on data word 5 of 8 means the BC keeps words 1–4 and re-requests only 5–8."
Error. 1553 has no partial-message recovery — a parity failure invalidates the transaction and the BC retries the entire message (typically up to 3 attempts).
Why questions
WY1. Why is Ethernet, despite being 1000× faster, unsuitable for a missile-release control loop?
Because its latency is non-deterministic — CSMA/CD backoff and switch buffering mean you cannot guarantee a bounded worst-case arrival time, and a control loop needs a hard ceiling, not a fast average. See the contrast with Time-Triggered Architectures.
WY2. Why does command/response give exactly zero collisions?
Because the BC owns every microsecond of bus time — nothing transmits unless the BC just commanded it — so two nodes can never contend for the medium at once. Contrast CAN Bus, which allows contention and resolves it by priority arbitration.
WY3. Why does 1553 use a Status Word instead of a simple ACK bit like some buses?
One bit says only "received"; the Status Word packs message-error, busy, service-request and other health flags, so a single reply both acknowledges and reports the RT's condition — essential when you can't physically inspect a box in flight.
WY4. Why is ARINC 429 (used on airliners) not preferred for a fighter's tightly-coupled avionics?
ARINC 429 is one-transmitter-per-wire and unidirectional, so many mutually-talking boxes need a rat's nest of point-to-point links; 1553's single shared, bidirectional, BC-scheduled bus scales to 31 RTs on one pair with guaranteed timing.
WY5. Why does higher signaling speed actually hurt over 100+ ft of aircraft cable?
Faster edges mean shorter wavelengths, so reflections, attenuation and impedance mismatches distort the waveform badly over long runs — the slow 1 MHz signaling stays well within what the cable can carry cleanly.
WY6. Why does the standard mandate a 4–12 RT response window rather than "reply immediately"?
A window lets slower and faster hardware coexist while still bounding the worst case, so the BC can compute a fixed schedule. "Immediately" is unmeasurable and unenforceable across different RT designs — see Real-Time Scheduling Theory.
WY7. Why does DO-178C certification favor a passive shared bus over an active switched network?
Fewer active components between nodes means fewer failure modes to analyze and prove; DO-178C Certification Level A demands exhaustive failure-case coverage, and a transformer-coupled passive bus is far simpler to argue safe than switch firmware.
WY8. Why is Manchester Encoding chosen over plain NRZ for this bus?
NRZ can go 100 with no edge on a run of identical bits, drifting the receiver clock; Manchester's guaranteed per-bit edge keeps the PLL locked and also self-carries the clock, needing no separate clock wire.
Edge cases
EC1. What happens on the bus if an RT's stub cable is physically severed by shrapnel?
Its transformer-coupled stub becomes an open circuit — a benign failure that does not short or load the main bus — so every other node keeps communicating normally.
EC2. Two RTs are accidentally set to the same address. What breaks and when?
Nothing collides until the BC commands that address to transmit — then both RTs drive the bus at once, corrupting the reply. The bus is fine at rest; the fault only appears on a transmit poll of the duplicated address.
EC3. The BC (bus master) itself fails mid-flight. Does the bus keep running?
No — with no BC, nobody initiates transactions and the bus goes silent. Survivability comes from a pre-designated backup BC taking over, not from the RTs self-organizing.
EC4. An RT is commanded to transmit but is still busy computing the data. What does it do?
It replies with its Status Word and the Busy bit set, deferring the data; the BC sees Busy and can re-poll later. It must not stall the bus waiting — that would blow the response window.
EC5. Both Bus A and Bus B deliver valid copies of the same message to an RT. What does the RT keep?
Whichever arrives first; the second valid copy is simply ignored. The redundancy is "first good wins," not a vote or a merge.
EC6. A Word Count field holds the value 0 on a receive command — how many words does the RT expect?
32 — the maximum. Zero is the encoding trick for 32 because 5 bits max out at 31; a genuine "no words" transaction does not exist.
EC7. Bus A carries the command but noise flips one bit inside a data word (parity fails), while Bus B's copy is clean. What happens?
The RT/BC uses the clean Bus B copy — that's the whole point of dual redundancy: an independent physical channel usually isn't hit by the same transient, so a valid copy survives.
EC8. What is the longest interval with no voltage transition anywhere in a normal (non-sync) 1553 word, and why does it matter?
— half a bit period — because Manchester forces a mid-bit edge in every bit; this bounded gap is exactly what lets the receiver PLL never lose lock.
Recall One-line summary of every trap family
True/False traps attack identity confusions (1553 vs RS-485/Ethernet); Spot-the-error traps attack encoding and timing slips (Count=0, the 208 budget, whole-message retry); Why-questions force the design-goal reasoning (determinism and certification over raw speed); Edge cases force degenerate-input thinking (severed stubs, dead BC, busy RTs, duplicate addresses).