MIL-STD-1553

MIL-STD-1553B, which superseded the earlier 1975 specification MIL-STD-1553A, was published in 1978. The basic difference between the 1553A and 1553B revisions is that in the latter, the options are defined rather than being left for the user to define as required. It was found that when the standard did not define an item, there was no coordination in its use. Hardware and software had to be redesigned for each new application. The primary goal of the 1553B was to provide flexibility without creating new designs for each new user. This was accomplished by specifying the electrical interfaces explicitly so that electrical compatibility between designs by different manufacturers could be assured.

Six change notices to the standard have been published since 1978.[7] For example, change notice 2 in 1986 changed the title of the document from "Aircraft internal time division command/response multiplex data bus" to "Digital time division command/response multiplex data bus".

MIL-STD-1553C is the last revision made in February 2018.[8]

The MIL-STD-1553 standard is now maintained by both the U.S. Department of Defense and the Aerospace branch of the Society of Automotive Engineers.

A single bus consists of a wire pair with 70–85 Ω impedance at 1 MHz. Where a circular connector is used, its center pin is used for the high (positive) Manchester bi-phase signal. Transmitters and receivers couple to the bus via isolation transformers, and stub connections branch off using a pair of isolation resistors and, optionally, a coupling transformer. This reduces the impact of a short circuit and ensures that the bus does not conduct current through the aircraft. A Manchester code is used to present both clock and data on the same wire pair and to eliminate any DC component in the signal (which cannot pass the transformers). The bit rate is 1.0 megabit per second (1-bit per μs). The combined accuracy and long-term stability of the bit rate is only specified to be within ±0.1%; the short-term clock stability must be within ±0.01%. The peak-to-peak output voltage of a transmitter is 18–27 V.

The bus can be made dual or triply redundant by using several independent wire pairs, and then all devices are connected to all buses. There is provision to designate a new bus control computer in the event of a failure by the current master controller. Usually, the auxiliary flight control computer(s) monitor the master computer and aircraft sensors via the main data bus. A different version of the bus uses optical fiber, which weighs less and has better resistance to electromagnetic interference, including EMP. This is known as MIL-STD-1773.[9] NASA's "AS 1773" experiment has a dual rate of 1 Mbit/s or 20 Mbit/s – probably a predecessor of STANAG 3910.[10]

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 transmission. Several options are available for such retries including an immediate retry (on the other data bus of a redundant pair of data buses) and a retry later (on the same bus) in the sequence of transfers.

The sequences ensure that the terminal is functioning and able to receive data. The status word at the end of a data transfer sequence ensures that the data has been received and that the result of the data transfer is acceptable. It is this sequence that gives MIL-STD-1553 its high integrity.

However, the standard does not specify any particular timing for any particular transfer — that's up to the system designers. Generally (the way it is done on most military aircraft), the Bus Controller has a schedule of transfers that covers the majority of transfers, often organized into a major frame or major cycle, which is often subdivided into minor cycles. In such a cyclic executive schedule structure, transfers that occur in every minor cycle (rate group 1) happen at the highest rate, typically 50 Hz, transfers that occur in every other minor cycle, of which there are two groups (rate group 2.1 and 2.2) happen at the next highest rate, e.g. 25 Hz. Similarly, there are four groups (3.1, 3.2, 3.3, and 3.4) at, e.g., 12.5 Hz and so on. Hence, where this scheduling structure is used, the transfers are all at harmonically related frequencies, e.g. 50, 25, 12.5, 6.25, 3.125, and 1.5625 Hz (for a major frame comprising 32 minor cycles at 50 Hz). Whilst RTs cannot start a transfer directly on their own, the standard does include a method for when an RT needs to transmit data that is not automatically scheduled by the Bus Controller. These transfers are often called acyclic transfers as they are outside the structure used by the cyclic executive. In this sequence, an RT requests transmission through a bit in the status word, the Service Request bit. Generally, this causes the Bus Controller to transmit a Transmit Vector Word Mode Code command. However, where an RT only has one possible acyclic transfer, the Bus Controller can skip this part. The vector word is transmitted by the RT as a single 16-bit data word. The format of this vector word is not defined in the standard, so the system designers must specify what values from what RTs mean what action the Bus Controller is to take. This may be to schedule an acyclic transfer either immediately or at the end of the current minor cycle. This means that the Bus Controller has to poll all the Remote Terminals connected to the data bus, generally at least once in a major cycle. RTs with higher-priority functions (for example, those operating the aircraft control surfaces) are polled more frequently. Lower-priority functions are polled less frequently.

Six types of transactions are allowed between the BC and a specific RT or between the Bus Controller and a pair of RTs:

Figure 6: Information transfer formats. Note: "TRANSMIT COMMAND" equals "command word"

1. Controller to RT Transfer. The Bus Controller sends one 16-bit receive command word, immediately followed by 1 to 32 16-bit data words. The selected Remote Terminal then sends a single 16-bit Status word.
2. RT to Controller Transfer. The Bus Controller sends one transmit command word to a Remote Terminal. The Remote Terminal then sends a single Status word, immediately followed by 1 to 32 words.
3. RT to RT Transfers. The Bus Controller sends out one receive command word immediately followed by one transmit command word. The transmitting Remote Terminal sends a Status word immediately followed by 1 to 32 data words. The receiving Terminal then sends its Status word.
4. Mode Command Without Data Word. The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word.
5. Mode Command With Data Word (Transmit). The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command. The Remote Terminal responds with a Status word immediately followed by a single Data word.
6. Mode Command With Data Word (Receive). The Bus Controller sends one command word with a Sub-address of 0 or 31 signifying a Mode Code type command immediately followed by a single data word. The Remote Terminal responds with a Status word.

MIL-STD-1553B also introduced the concept of optional broadcast transfers, in which data is sent to all RTs that implement the option, but to which no RTs respond, as this would cause conflicts on the bus. These can be used where the same data is sent to multiple RTs, to reduce the number of transactions and thus reduce the loading on the data bus. However, the lack of explicit responses by the RTs receiving these broadcasts means that these transfers cannot be automatically re-tried in the event of an error in the transaction.

Four types of broadcast transactions are allowed between the BC and all capable RTs:

Figure 7: Broadcast information transfer formats

1. Controller to RT(s) Transfer. The Bus Controller sends one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by 0 to 32 data words. All Remote Terminals that implement broadcasts will accept the data but no Remote Terminals will respond.
2. RT to RT(s) Transfers. The Bus Controller sends out one receive command word with a Terminal address of 31 signifying a broadcast type command, immediately followed by one transmit command. The transmitting Remote Terminal sends a Status word immediately followed by 1 to 32 data words. All Remote Terminals that implement broadcasts will accept the data but no Remote Terminals will respond.
3. Mode Command Without Data Word (Broadcast). The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command. No Remote Terminals will respond.
4. Mode Command With Data Word (Broadcast). The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command and a sub-address of 0 or 31 signifying a Mode Code type command, immediately followed by one Data word. No Remote Terminals will respond.

The Command Word is built as follows. The first 5 bits are the Remote Terminal address (0–31). The sixth bit is 0 for Receive or 1 for Transmit. The next 5 bits indicate the location (sub-address) to hold or get data on the Terminal (1–30). Note that sub-addresses 0 and 31 are reserved for Mode Codes. The last 5 bits indicate the number of words to expect (1–32). All zero bits indicate 32 words. In the case of a Mode Code, these bits indicate the Mode Code number (e.g., Initiate Self Test and Transmit BIT Word).

The Status Word decodes as follows. The first 5 bits are the address of the Remote Terminal that is responding. The rest of the word is single bit condition codes, with some bits reserved. A 'one' state indicates condition is true. More than one condition may be true at the same time.

The image below exemplifies many of the protocol and physical layer concepts explained above. For example, the RT address contained in the Command Word has a value of 0x3 (in range of 0 to 31). The sixth bit is 1, indicating a Transmit from the RT. The sub-address is 0x01. The last 5 bits indicate the number of words to expect take a value of 1, which is matched by the single Data Word (value 0x2) after the Status Word.

Also as explained above, devices have to start transmitting their response to a valid command within 4–12 microseconds. In the example, the Response Time is 8.97 us, therefore within specifications. This means that the Remote Terminal (RT) number 3 has responded to the Bus Controller query after 8.97 us. The amplitude of the query is lower than the amplitude of the response because the signal is probed at a location closer to the Remote Terminal.

In the Status Word, the first 5 bits are the address of the Remote Terminal that is responding, in this case 0x3. A correct Transfer exhibits the same RT address in the Command Word as in the Status Word.

A RT to BC Transfer, with 1 Data Word

Figure 1: Sample MIL-STD-1553B Multiplex Data Bus Architecture

Figure 1 shows a sample MIL-STD-1553B system that consists of:

• redundant MIL-STD-1553B buses
• a Bus Controller
• a Backup Bus Controller
• a Bus Monitor
• a standalone Remote Terminal with one or more subsystems communicating with it
• a subsystem with an embedded Remote Terminal

The bus hardware encompasses (1) cabling, (2) bus couplers, (3) terminators and (4) connectors.

Stubbing

Figure 9: Data bus interface using transformer coupling

Each terminal, RT, BC, or BM, is connected to the bus through a stub, formed of a length of cable of the same type as the bus itself. MIL-STD-1553B defines two ways of coupling these stubs to the bus: transformer coupled stubs and direct coupled stubs. Transformer coupled stubs are preferred for their fault tolerance and better matching to the impedance of the bus, and consequent reduction in reflections, etc. The appendix to MIL-STD-1553B (in section 10.5, Stubbing) states "The preferred method of stubbing is to use transformer coupled stubs… This method provides the benefits of DC isolation, increased common mode rejection, a doubling of effective stub impedance, and fault isolation for the entire stub and terminal. Direct coupled stubs… should be avoided if at all possible. Direct coupled stubs provide no DC isolation or common mode rejection for the terminal external to its subsystem. Further, any shorting fault between the subsystems [sic] internal isolation resistors (usually on a circuit board) and the main bus junction will cause failure of that entire bus. It can be expected that when the direct coupled stub length exceeds 1.6 feet (0.49 meters)], that it will begin to distort the main bus waveforms."

The use of transformer coupled stubs also provides improved protection for 1553 terminals against lightning strikes. Isolation is even more critical in new composite aircraft where the skin of the aircraft no longer provides an inherent Faraday shield as was the case with aluminum skinned aircraft.[11]

In a transformer coupled stub, the length of the stub cable should not exceed 20 feet (6.1 m), but this may be exceeded "if installation requirements dictate." The coupling transformer has to have a turns ratio of 1:1.41 ± 3.0 percent. The resistors R both have to have a value of 0.75 Zo ± 2.0 percent, where Zo is the characteristic impedance of the bus at 1 MHz.

Figure 10: Data bus interface using direct coupling

In a direct coupled stub, the length of stub cable should not exceed 1-foot, but again this may be exceeded if installation requirements dictate. The isolation resistors R have to have a fixed value of 55 ohms ± 2.0 percent.

STANAG 3910 (EFABus) mates a 1553 or 1773 link with additional high-speed 20 Mbps buses, either optical or electrical. In the STANAG form, the 1553/1773 low-speed link serves as the control channel for the high speed link. In the EFABus Express (EfEx) form, the high-speed link acts as its own control channel. Either way, high and low-speed buses share the same addressing model and can communicate with each other.[12]

STANAG 7221 (E1553) expands a 1553 link with the capability to carry a 100 Mbps signal on the same wire without interfering with old signaling.[13] The concept is similar to how ADSL avoids voice frequencies, but done at higher bandwidths.[14] In addition to 1553B, it also runs over coax, twisted pair, Power-Line Carrier, and existing ARINC 429 links.[15]

DIGIBUS (or Digibus, GAM-T-101) is the French counterpart to MIL-STD-1553. It is similar to MIL-STD-1553 in the same notion of Bus Controller, Remote Terminal, monitor, same transmission speed, but the difference is that DIGIBUS uses separate links for data and commands.[16]

GOST 26765.52-87 and its descendant GOST R 52070-2003 are the Soviet and Russian, respectively, equivalents of MIL-STD-1553B. The encoding, data rate, word structure, and control commands are fully identical.

GJV289A is the Chinese equivalent of MIL-STD-1553. Aircraft utilizing this system can reportedly use both Soviet (GOST bus)[17] and western (MIL-STD-1553 bus) weapons.[18]

H009 (also called MacAir H009), introduced by McDonnell in 1967, was one of the first avionics data buses. It is a dual redundant bus controlled by a Central Control Complex (CCC), with up to 16 Peripheral Units (PUs), synchronously communicating using a 1MHz clock. H009 was used in early F-15 fighter jets, but due its noise sensitivity and other reliability issues was replaced by MIL-STD-1553.

When developing or troubleshooting for MIL-STD-1553, examination of the electronic signals is useful. A logic analyzer with protocol-decoding capability, also a Bus analyzer or protocol analyzer, are useful tools to collect, analyze, decode and store the waveforms of the high-speed electronic signals.

Intel M82553 Protocol Management Unit (PMU) using the CHMOS III technology. This device meets full bus interface protocol standard.[19]

• MIL-STD-1760
• MIL-STD-704
• Aircraft flight control systems
• Fly by wire
• Avionics Full-Duplex Switched Ethernet (AFDX) – a faster Ethernet-based technology
• ARINC 429 Commercial Avionics Counterpart
• Bus Coupler – A brief description of Bus Coupler.
• TTEthernet – Time-Triggered Ethernet
• SAE AS6802 Time-Triggered Ethernet
• SpaceWire

• MIL-STD-1553C: Digital Time Division Command/Response Multiplex Data Bus. United States Department of Defense, February 2018.
• SAE AS15531: Digital Time Division Command/Response Multiplex Data Bus.
• SAE AS15532: Data Word and Message Formats.
• SAE AS4111: RT Validation Test Plan.
• SAE AS4112: RT Production Test Plan.

• MIL-STD-1553, Digital Time Division Command/Response Multiplex Data Bus. United States Department of Defense, February 2018.
• MIL-STD-1773, Fiber Optics Mechanization of an Aircraft Internal Time Division Command/Response Multiplex Data Bus. United States Department of Defense, October 1989.
• MIL-STD-1553 Tutorial from AIM, Avionics Databus Solutions, Interface Boards for MIL-STD-1553/1760
• MIL-STD-1553 Tutorial from Avionics Interface Technologies (registration required)
• MIL-STD-1553 Tutorial (video) from Excalibur Systems Inc.
• MIL-STD-1553 Couplers Tutorial (video) from Excalibur Systems Inc.
• MIL-STD-1553 Tutorial by GE Intelligent Platforms (registration required)
• MIL-STD-1553 Tutorial and References from Ballard Technology (includes MIL-STD-1553B & MIL-HDBK-1553A Notice2)
• MIL-STD-1553 Designer's Guide from Data Device Corporation
• MIL-STD-1553 Tutorial and Reference from Alta Data Technologies
• INTRODUCTION TO THE MIL-STD-1553B SERIAL MULTIPLEX DATA BUS by D. R. Bracknell, Royal Aircraft Establishment, Farnbourogh, 1988.
• Introduction to MIL-STD-1553 Short Course from Georgia Tech Professional Education
• MIL-STD-1553 Complete online reference from Data Device Corporation
• Military Computer with MIL-STD-1553 Interface from AMDTEC Defence