page_title: MIL-STD-1553
section_title: Bus protocol
hierarchical_section_title: MIL-STD-1553 / Bus protocol
caption_attribution_description: Redrawn copy of figure 6 from MIL-STD-1553B, which is copyright free anyway
context_page_description: MIL-STD-1553 is a military standard published by the United States Department of Defense that defines the mechanical, electrical, and functional characteristics of a serial data bus. It was originally designed as an avionic data bus for use with military avionics, but has also become commonly used in spacecraft on-board data handling subsystems, both military and civil. It features multiple redundant balanced line physical layers, a network interface, time division multiplexing, half-duplex command/response protocol, and can handle up to 30 Remote Terminals. A version of MIL-STD-1553 using optical cabling in place of electrical is known as MIL-STD-1773.
  MIL-STD-1553 was first published as a U.S. Air Force standard in 1973, and first was used on the F-16 Falcon fighter aircraft. Other aircraft designs quickly followed, including the F/A-18 Hornet, AH-64 Apache, P-3C Orion, F-15 Eagle and F-20 Tigershark. It is now widely used by all branches of the U.S. military and by NASA. Outside of the US it has been adopted by NATO as STANAG 3838 AVS.
context_section_description: A MIL-STD-1553 multiplex data bus system consists of a Bus Controller (BC) controlling multiple Remote Terminals (RT) all connected together by a data bus providing a single data path between the Bus Controller and all the associated Remote Terminals. There may also be one or more Bus Monitors (BM); however, Bus Monitors are specifically not allowed to take part in data transfers, and are only used to capture or record data for analysis, etc. In redundant bus implementations, several data buses are used to provide more than one data path, i.e. dual redundant data bus, tri-redundant data bus, etc. All transmissions onto the data bus are accessible to the BC and all connected RTs. Messages consist of one or more 16-bit words (command, data, or status). The 16 bits comprising each word are transmitted using Manchester code, where each bit is transmitted as a 0.5 μs high and 0.5 μs low for a logical 1 or a low-high sequence for a logical 0. Each word is preceded by a 3 μs sync pulse (1.5 μs low plus 1.5 μs high for data words and the opposite for command and status words, which cannot occur in the Manchester code) and followed by an odd parity bit. Practically each word could be considered as a 20-bit word: 3 bit for sync, 16 bit for payload and 1 bit for odd parity control. The words within a message are transmitted contiguously and there has to be a minimum of a 4 μs gap between messages. However, this inter-message gap can be, and often is, much larger than 4 μs, even up to 1 ms with some older Bus Controllers. Devices have to start transmitting their response to a valid command within 4–12 μs and are considered to not have received a command or message if no response has started within 14 μs.
  All communication on the bus is under the control of the Bus Controller using commands from the BC to the RTs to receive or transmit. The sequence of words, (the form of the notation is <originator>.<word_type(destination)> and is a notation similar to CSP), for transfer of data from the BC to a terminal is
  master.command(terminal) → terminal.status(master) → master.data(terminal) → master.command(terminal) → terminal.status(master)
  and for terminal to terminal communication is
  master.command(terminal_1) → terminal_1.status(master) → master.command(terminal_2) → terminal_2.status(master) → master.command(terminal_1) → terminal_1.data(terminal_2) → master.command(terminal_2) → terminal_2.status(master)
  This means that during a transfer, all communication is started by the Bus Controller, and a terminal device cannot start a data transfer on its own. In the case of an RT to RT transfer the sequence is as follows: An application or function in the subsystem behind the RT interface (e.g. RT1) writes the data that is to be transmitted into a specific (transmit) sub-address (data buffer). The time at which this data is written to the sub-address is not necessarily linked to the time of the transaction, though the interfaces ensure that partially updated data is not transmitted. The Bus controller commands the RT that is the destination of the data (e.g. RT2) to receive the data at a specified (receive) data sub-address and then commands RT1 to transmit from the transmit sub-address specified in the command. RT1 transmits a Status word, indicating its current status, and the data. The Bus Controller receives RT1's status word, and sees that the transmit command has been received and actioned without a problem. RT2 receives the data on the shared data bus and writes it into the designated receive sub-address and transmits its Status word. An application or function on the subsystem behind the receiving RT interface may then access the data. Again the timing of this read is not necessarily linked to that of the transfer. The Bus Controller receives RT2's status word and sees that the receive command and data have been received and actioned without a problem.
  If, however, either RT fails to send its status or the expected data or indicates a problem through the setting of error bits in the status word, the Bus Controller may retry the transmi
caption: Figure 6: Information transfer formats
exif: {}