MIL-STD-1553

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 (OBDH) subsystems, both military and civil. It features multiple (commonly dual) redundant balanced line physical layers, a (differential) network interface, time division multiplexing, half-duplex command/response protocol, and can handle up to 30 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 first was used on the F-16 Falcon fighter aircraft. Other aircraft designs quickly followed, including the F-18 Hornet, AH-64 Apache, P-3C Orion, F-15 Eagle 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. STANAG 3838, in the form of UK MoD Def-Stan 00-18 Part 2,[1] is used on the Panavia Tornado; BAE Systems Hawk (Mk 100 and later); and extensively, together with STANAG 3910 - "EFABus", on the Eurofighter Typhoon.[2] Saab JAS 39 Gripen uses MIL-STD-1553B.[3] The Russian made MiG-35 also uses MIL-STD-1553.[4] MIL-STD-1553 is being replaced on some newer U.S. designs by IEEE 1394.[5]

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.[6] 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 U.S. Department of Defense and the Aerospace branch of the Society of Automotive Engineers.

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, optionally, 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 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. The "AS 1773" implementation has a dual rate of 1 Mbit/s or 20 Mbit/s.[7]

Bus protocol

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.2, 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
  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).

 Command Word Bit Usage
Remote Terminal address (0 - 31) Receive or Transmit Location (sub-address) of data (1 - 30) Number of words to expect (1 - 32)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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.

 Status Word Bit Usage
Remote Terminal address Single bit condition codes
1 2 3 4 5 6 - 16

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.

Conceptual description

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

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

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:

The 1553B spec dictates that all devices in the system be connected to a redundant pair of buses to provide an alternate data path in the event of damage or failure of the primary bus. Bus messages only travel on one bus at a time, determined by the Bus Controller.

Backup Bus Controller

Whilst there may be only one BC on the bus at any one time, the standard provides a mechanism for handover to a Backup Bus Controller (BBC) or (BUBC), using flags in the status word and Mode Codes. This may be used in normal operation where handover occurs because of some specific function, e.g. handover to or from a BC that is external to the aircraft, but connected to the bus. Procedures for handover in fault and failure conditions generally involve discrete connections between the main and backup BCs, and the backup monitoring the actions of the main BC during operation. For example, if there is a prolonged quiescence on the bus indicating that the active BC has failed, the next highest priority backup BC, indicated by the discrete connections, will take over and begin operating as the active BC.

The Bus Monitor

A Bus Monitor (BM) 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 RTs. These recorded bus transactions can then be stored, for later off-line analysis.

Ideally, a BM 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 BM is often configured to record a subset of the transactions, based on some criteria provided by the application program.

Alternatively, a BM is used in conjunction with a Backup Bus Controller. This allows the Backup Bus Controller to "hit the ground running", if it is called upon to become the active Bus Controller.

The Remote Terminal

A Remote Terminal can be used to provide:

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.

Bus hardware characteristics

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

Cabling

Although MIL-STD-1553B specifies that the data bus should have characteristic impedance between 70 and 85 ohms, industry has standardized on 78 ohms. Likewise, the industry has generally standardized on the cable known as twinax cable that has a characteristic impedance of 78 ohms.

MIL-STD-1553B does not specify the length of the bus. However, the maximum length of bus is directly related to the gauge of the cable conductor and time delay of the transmitted signal. A smaller conductor attenuates the signal more than a larger conductor. Typical propagation delay for a 1553B cable is 1.6 nanoseconds per foot. Thus, the end-to-end 100-foot bus (30 m) would have a 160 nanosecond propagation delay, which is equal to the average rise time of a 1553B signal. According to MIL-HDBK-1553A, when a signal's propagation delay time is more than 50% of the rise or fall time, it is necessary to consider transmission line effects. This delay time is proportional to the distance propagated. Also, consideration must be given to the actual distance between the transmitter and receiver, and the individual waveform characteristics of the transmitters and receivers.

MIL-STD-1553B specifies that the longest stub length is 20 feet (6.1 m) for transformer coupled stubs, but can be exceeded. With no stubs attached, the main bus looks like an infinite length transmission line with no disturbing reflections. When a stub is added, the bus is loaded and a mismatch occurs with resulting reflections. The degree of mismatch and signal distortion due to reflections are a function of the impedance presented by the stub and terminal input impedance. To minimize signal distortion, it is desirable that the stub maintain high impedance. This impedance is reflected back to the bus. At the same time, however, the impedance must be kept low so that adequate signal power will be delivered to the receiving end. Therefore, a tradeoff between these conflicting requirements is necessary to achieve the specified signal-to-noise ratio and system error rate performance (for more information, refer to MIL-HDBK-1553A).

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.5 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 long provides an inherent Faraday shield as was the case with aluminum skinned aircraft.[8]

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.

Bus Couplers

Stubs for RTs, the BC, or BMs, are generally connected to the bus through coupling boxes, which may provide a single or multiple stub connections. These provide the required shielding (≥ 75 percent) and, for transformer coupled stubs, contain the coupling transformers and isolation resistors. They have two external connectors through which the bus feeds, and one or more external connectors to which the stub or stubs connect. These stub connectors should not be terminated with matching resistors, but left open circuit when not used, with blanking caps where necessary. One of the bus connectors may be terminated where the bus coupler is physically at the end of the bus cable, i.e. it is not normally considered essential to have a length of bus cable between the last bus coupler and the termination resistor.

Cable Termination

Both ends of the bus, whether it includes one coupler or a series of couplers connected together, must be terminated (in accordance with MIL-STD-1553B) with "a resistance, equal to the selected cable nominal characteristic impedance (Zo) ± 2.0 percent." This is typically 78 ohms. The purpose of electrical termination is to minimize the effects of signal reflections that can cause waveform distortion. If terminations are not used, the communications signal can be compromised causing disruption or intermittent communications failures.

Connectors

The standard does not specify the connector types or how they should be wired, other than shielding requirements, etc. In lab environments concentric twinax bayonet style connectors are commonly used. These connectors are available in standard (BNC size), miniature and sub-miniature sizes. In military aircraft implementations, MIL-DTL-5015 and MIL-DTL-38999 circular connectors are generally used.

Similar systems

DIGIBUS (or Digibus) is the French equivalent of MIL-STD-1553 and 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.[9]

'GJV289A is the Chinese equivalent of MIL-STD-1553 and GOST R 52070-2003 is the Russian/Soviet equivalent of MIL-STD-1553.[10]

Development tools

When developing and/or troubleshooting MIL-STD-1553, examination of hardware signals can be very important to find problems. A logic analyzer with protocol decoding capabilities, a Bus analyzer or protocol analyzers are useful tools which collect, analyze, decode, store signals so people can view the high-speed waveforms at their leisure.

See also

Sources

References

  1. ↑ Avionic Systems Standardisation Committee, Avionic Data Transmission Interface Systems Part 2 : Serial, Time Division Command/Response Multiplex Data Bus Standard, Def Stan 00-18, Issue 2, 28 September 1990
  2. ↑ George Marsh, Typhoon: Europe’s Finest, Avionics Today, June 1st 2003.
  3. ↑ Archived March 13, 2013, at the Wayback Machine.
  4. ↑ "MiG-35 Multi-Role Combat Aircraft". Retrieved 14 November 2014.
  5. ↑ "The Electric Jet." Philips, E. H. Aviation Week & Space Technology. 2007-02-05.
  6. ↑ ASSIST-QuickSearch - Basic Profile Archived February 6, 2009, at the Wayback Machine..
  7. ↑ MIL-STD-1773 Data Bus
  8. ↑ Hegarty, Michael, "MIL-STD-1553 Goes Commercial"
  9. ↑ DIGIBUS
  10. ↑ GOST R 52070-2003
This article is issued from Wikipedia - version of the 11/4/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.