MIL-STD-1553B Bus Loading and Fault-Detection Trade
A spacecraft avionics architecture uses a 1 Mbit/s MIL-STD-1553B bus with one bus controller and 40 remote terminals. The controller polls every terminal at 50 Hz. Each poll is a single 20-data-word telemetry message; each 16-bit data word occupies 20 bit times on the bus including sync and parity. The command and status words add 40 bit times, and the intermessage gap plus response time totals 10 µs. A new payload requires four additional 32-data-word messages per second. The bus controller currently allows one retry per message and the project budgets 20% spare bus capacity for retries and time synchronization. A remote terminal occasionally misses its status response; the controller retries once and then flags the terminal. The team proposes increasing the poll rate to 100 Hz to improve fault detection.
1. Calculate the current bus utilization and determine whether the new payload fits within the project's 20% spare-capacity budget.
Read the worked answer
At 1 Mbit/s, one bit time is 1 µs, so a 20-bit word takes 20 µs.
For a 20-data-word message:
- Data: 20 words × 20 µs = 400 µs.
- Command plus status: 40 bit times = 40 µs.
- Gap plus response: 10 µs. Total = 450 µs per poll.
Poll rate: 40 terminals × 50 Hz = 2000 messages/s. Bus time = 2000 × 450 µs = 0.900 s per second = 90% utilization.
Spare capacity is therefore 10%, not the required 20%. The current design is already outside the project budget before any new payload is added.
The new payload adds 32-data-word messages: 32 × 20 = 640 µs of data, plus 40 µs command/status, plus 10 µs gap = 690 µs per message. Four per second add 4 × 690 µs = 2.76 ms/s = 0.276% utilization. Total becomes 90.28%. The new payload is numerically small, but it does not fit the 20% reserve because the reserve was already consumed. Accepting it without rescheduling would leave only 9.7% for retries and synchronization.
2. Evaluate the proposal to poll at 100 Hz. What is the maximum poll rate that meets the 80% utilization target, and what alternative would you recommend for faster fault detection?
Read the worked answer
Doubling the poll rate doubles the message rate to 4000 messages/s. Bus time = 4000 × 450 µs = 1.80 s/s = 180% utilization. The bus cannot carry this; deadlines would be missed and the controller would not complete the schedule. The proposal is not feasible.
To meet the 80% target, the available bus time is 0.80 s/s. Maximum messages/s = 0.80 / 450 µs = 1778 messages/s. Dividing by 40 terminals gives about 44.4 Hz. So even 50 Hz exceeds the 80% target; a rate of about 40 Hz gives 40 × 40 × 450 µs = 0.72 s/s = 72%, leaving room for the new payload and retries. If 50 Hz must be retained, the message length must be reduced, for example by splitting telemetry into 10-word messages or using a mode code to fetch only changed data.
For faster fault detection, do not raise the poll rate globally. Use event-driven or exception reporting from the remote terminal, a mode-code status request for critical terminals, or a separate low-rate health-polling schedule. Keep the 50 Hz science/telemetry poll where it is needed and add a faster health poll only for the terminals that require it. A second bus or a higher-rate network is the architectural answer if 100 Hz health monitoring is truly required for all 40 terminals.
3. Quantify the retry budget and the fault-detection time at 50 Hz. How would you use the status word and retry logic to avoid overloading the bus?
Read the worked answer
At 80% target utilization, the spare is 0.20 s/s. One retry costs 450 µs, so the retry capacity is 0.20 / 450 µs ≈ 444 retries/s. With 2000 messages/s, that is about 22% of messages. If the missed-status probability is 10^-3, the expected retry rate is only 2 retries/s, far below the capacity. The budget is therefore adequate for random misses, but not for a terminal that fails continuously and is retried every poll.
At 50 Hz, a terminal is polled every 20 ms. With one retry, a missing status is confirmed after the retry, so the detection time is roughly two poll periods plus processing, about 40 ms. At 100 Hz it would be about 20 ms, but the bus cannot support that rate. A better approach is to use the status word's terminal-flag and service-request bits, or a summary bit in a health message, so the controller can react without polling every terminal faster.
Retry logic should be bounded: one immediate retry, then flag the terminal and skip it for a defined number of minor frames, or move it to a maintenance schedule. Continuous retries of a failed terminal can consume the entire spare budget and delay healthy terminals. The controller should also distinguish a missing status from a message error and log both, so that a persistent fault is not mistaken for a transient.