MIL-STD-1553

El directorio enciclopédico desde la Wikipedia.

MIL-STD-1553 is 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 for use with military avionics, but has also become commonly used in spacecraft on-board data handling (OBDH) subsystems, both military and civil. It features a dual redundant balanced line physical layer, a (differential) network interface, time division multiplexing, half-duplex command/response protocol and up to 31 remote terminals (devices). 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 was first used on the F-16 Fighting Falcon fighter aircraft. Other aircraft designs quickly followed, including the F-18 Hornet and F-20 Tigershark. It now is widely used by all branches of the U.S. military and has been adopted by NATO as STANAG 3838 AVS. MIL-STD-1553 is being replaced on some newer U.S. designs by FireWire.^[1]

1 Revisions
2 Physical layer
3 Bus protocol
4 Conceptual description
5 References
6 External links
7 See also

[edit] Revisions

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. ^[2] 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".

The MIL-STD-1553 standard is now maintained by both the US DOD and the Aerospace branch of the Society of Automotive Engineers.

[edit] Physical layer

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 a coupling transformer. This reduces the impact of a short circuit and assures 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 = 1 μ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 better resists electromagnetic interference, including EMP. This is known as MIL-STD-1773.

[edit] Bus protocol

Messages consist of one or more 16-bit words (command, data or status). Each word is preceded by a 3 μs sync pulse (1.5 μs low plus 1.5 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 is a 4 μs gap between messages. Devices have to start transmitting their response to a valid command within 4–12 μs and are considered to not have received a message if no response has started within 14 μs.

All communication on the bus is under the control of the master bus controller and is on the basis of a command from the master controller to a terminal 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 master controller 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)

The sequences ensure that the terminal is functioning and able to receive data. The status request 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. The above sequences are simplified and do not show the actions to be taken in the case of an error or other fault.

A terminal device cannot originate a data transfer of itself. Requests for transmission from terminal devices are handled by the master controller polling the terminals. Higher-priority functions (for example, commands to the aircraft control surfaces) are polled more frequently. Lower-priority commands are polled less frequently. However, the standard does not specify any particular timing for any particular word -- that's up to the system designers. The absence of a response when a device is polled indicates a fault.

Five types of transactions exist between the Bus Controller (BC) and Remote Terminals (RT).

Receive data. The Bus Controller sends one 16 bit command word, immediately followed by 1 to 32, 16 bit data words. The selected Remote Terminal then sends a single 16 bit Status Response word back to the Bus Controller.
Transmit data. The Bus Controller sends one command word to Remote Terminal. The Remote Terminal then sends a single Status Response word, immediately followed by 1 to 32 words to the Bus Controller.
Broadcast data. New for 1553B. The Bus Controller sends one command word with a Terminal address of 31 signifying a broadcast type command, proceeded by 1 to 32 words. All Remote Terminals will accept the data but none will respond. This can be used for system wide updates, such as time of day.
Mode Code. The Bus Controller sends one command word with a Subaddress of 0 or 31 signifying a Mode Code type command. This command may or may not be followed by a single word depending on which code is used. The Remote Terminal responds with a Status Response word which may or may not be followed by a single data word.
RT to RT Transfer. The Bus Controller sends out a Receive data command followed by a Transmit data command. The transmitting Terminal sends a Status Word followed by 1 to 32 data words to the Receiving RT. The receiving Terminal then sends its Status Word.

The Command Word is built as follows. The first 5 bits are the Remote Terminal address (0 ~ 31). The sixth bit is zero for Receive or one for Transmit. Next 5 bits are the location (subaddress) to hold / get data on Terminal (1 ~ 30). Notice 0 and 31 are reserved for Mode Codes. Last 5 bits are the number of words to expect (1 ~ 32). All zero bits indicates 32 words. In the case of a Mode Code, these bits are the Mode Code number; Initiate Self Test and Transmit BIT Word are examples.

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. Some bits are reserved. A 'one' state indicates condition is true; Message Error and Service Request are examples. More than one condition may be true at the same time.

[edit] Conceptual description

Figure 1. A conceptual model of a MIL-STD-1553B bus.

Figure 1 at right shows a typical MIL-STD-1553B system.

It consists of:

a dual-redundant MIL-STD-1553B bus
a Bus Controller
three Remote Terminals
a Bus Monitor

[edit] The Bus Controller

There is only one Bus Controller at a time on any MIL-STD-1553 bus. It initiates all message communication over the bus.

Figure 1 shows 1553 data bus details:

operates according to a command list stored in its local memory
commands the various Remote Terminals to send or receive messages
services any requests that it receives from the Remote Terminals
detects and recovers from errors
keeps a history of errors

[edit] The Remote Terminals

A Remote Terminal can be used to provide:

an interface between the MIL-STD-1553B data bus and an attached subsystem
a bridge between a MIL-STD-1553B bus and another MIL-STD-1553B bus.

For example, in a tracked vehicle, a Remote Terminal might acquire data from an inertial navigational subsystem, and send that data over a 1553 data bus to another Remote Terminal, for display on a crew instrument. Simpler examples of Remote Terminals might be interfaces that switch on the headlights, the landing lights, or the annunciators in an aircraft.

Test Plans for Remote Terminals:

The RT Validation Test Plan is intended for design verification of remote terminals designed to meet the requirements of AS 15531 and MIL-STD-1553B with Notice 2. This test plan was initially defined in MIL-HDBK-1553, Appendix A. It was updated in MIL-HDBK-1553A, Section 100. The test plan is now maintained by the SAE AS-1A Avionic Networks Subcommittee as AS4111.

The RT Production Test Plan is a simplified subset of the validation test plan and is intended for production testing of remote terminals. This test plan is maintained by the SAE AS-1A Avionic Networks Subcommittee as AS4112.

[edit] Bus monitor

A Bus Monitor cannot transmit messages over the data bus. Its primary role is to monitor and record bus transactions, without interfering with the operation of the Bus Controller or the Remote Terminals. These recorded bus transactions can then be stored, for later off-line analysis.

Ideally, a Bus Monitor captures and records all messages sent over the 1553 data bus. However recording all of the transactions on a busy data bus might be impractical, so a Bus Monitor is often configured to record a subset of the transactions, based on some criteria provided by the application program.

Alternatively, a Bus Monitor is used in conjunction with a back-up Bus Controller. This allows the back-up Bus Controller to “hit the ground running”, if it is called upon to become the active Bus Controller.