Mil-Std-1553B Interface & Test-Setup Design

Mil-Std-1553B Interface & Test-Setup Design

Mr. Sameer Vaghela*, Prof. Y. B. Shukla#

* E.C. Department, SardarVallbhbhai Institute of Technology, Vasad Gujarat Technology University, Gujarat, India.

# E.C. Department, SardarVallbhbhai Institute of Technology, Vasad Gujarat Technology University, Gujarat, India.

Abstract

MIL-STD-1553 is a military standard that specifies the requirements for a digital command/response time division multiplex data bus for integration of aircraft/spacecraft subsystems. Simply stated, digital command / response time division multiplexing is the transmission of information between subsystems over a pair of wires with different subsystems transmitting at different points in time in response to commands. The 1553 Standard contains several sections and describes the method of communication, the data bus requirements and the electrical interface requirements for subsystems connected to the data bus. This paper contains the interfacing of different hardware element within a single digital mil-std-1553B bus & explains how to testify & validate terminal elements with the help of Tester/Simulator.

Keywords: Mil-std-1553 Bus, Remote Terminal, Testing, Coupling

1. Introduction

   MIL-STD-1553B is the military specification defining a Digital Time DivisionCommand/Response Multiplexed Data Bus. The 1553 databus is a dual-redundant, bidirectional, Manchester II encoded databus with a high bit error reliability. All bus communications are controlled and initiated by a main bus controller. Remote terminal devices attached to the bus respond to controller commands MIL-STD-1553B defines specifications for terminal device operation and coupling, word structure and format, messaging protocol and electrical characteristics.

   1. History

      MIL-STD-1553B was developed from the growing complexity of integrated avionics systems and the subsequentincrease in the number of discrete interconnects between terminal devices. The first draft of a standard in 1968 by the Aerospace Branch of the Society of Automotive Engineers (SAE) laid the foundation for the US Air Forces adoption of MIL-STD-1553 in 1973.

      A tri-service version, MIL-STD-1553A was released in 1975, modified to MIL-STD-1553B in 1978 and utilized in the Air Force F-16 and the United States (US) Army AH-64A Apache Attack Helicopter. Notice 2, released in 1986 and superseded Notice 1 released in 1980. Notices 3 and 4 did not alter the contents of the standard, but only provided a title change. MIL-STD-1553B has become the internationally accepted networking standard for integrating military platforms.

   2. Application

      The 1553 data bus is the most commonly used military data bus today. It is used in systems where data integrity and system reliability are critical. It is heavily used in aircraftavionics and stores and in ships, submarines and ground vehicles such as tanks. The data busis also being used in space in numerous satellites and the Space Station and in somecommercial applications such as reactors, subway cars and oil drilling.[8]

   3. Why 1553?

   • Linear LAN Network Architecturemakes it ideally suited for connecting distributed devices, reduce cabling requirement, reduce overall weight, reduce conserving space, provides system design & maintenance/flexibility allowing ease of add & removal of node.

   • Capacity of Redundancy by providing fault tolerance.

   • Support for Dumb & Smart Nodes by providing interfaces to sensors/actuators.

   • It provides High Level of Electrical Confidence as nodes can be easily/safely isolated from network, reducing potential for damage to equipments.

   • Generated real-time Determinism, this is the most compelling reason for which designer choose this as its command/response protocol which guarantees real-time determinism.

     Figure 1: Typical Block Diagram

2. Hardware Components [1]

MIL-STD-1553B defines three types of terminal devices that are allowed on the bus:

• The Transmission Media.

• Remote terminals.

• Bus controllers.

• Bus monitors.

  Figure 2: Terminal Devices

  1. Transmission Media

     The transmission media, or data bus, is defined as a twisted shielded pairtransmission line consisting of the main bus and a number of stubs. Thereis one stub for each terminal connected to the bus. The main data bus isterminated at each end with a resistance equal to the cable's characteristicimpedance (plus or minus two percent). This termination makes the databus behave electrically like an infinite transmission line.

     Stubs, which are added to the main bus to connect the terminals, providelocal loads and produce impedance mismatch where added. Thismismatch, if not properly controlled, produces electrical reflections anddegrades the performance of the main bus. Therefore, the characteristicsof both the main bus and the stubs are specified within the standard. Table summarizes the transmission media characteristics.

     Table 1: Bus Characteristics

     There is now no maximum length for the main data bus. Following transmission line design practices and careful placement of the stubs can yield working systems with the main bus length of several hundred meters.It is highly recommended that the bus be modeled and tested to insure its operation and performance characteristics.

     1. 1553 Cabling

        The MIL-STD-1553B definition of a data bus is atwisted- shielded pair transmission line made up of amain bus and a number of attached stubs.Shielding limits signal interference from outsidesources and the twisted pair maintains messageintegrity through noise canceling.

        MIL-STD-1553B specifies that all devices in thesystem will be connected to a redundant pair ofbuses, providing an alternate data path in the eventof damage or failure of the primary bus path. Busmessages only travel on one of the buses at a time,determined by the bus controller.

        Properly terminating the main data bus on each end makes the bus appear like an infinite line.Stub loading effects can be minimized on the bus by properly designed coupling.

     2. 1553 Coupling

     Coupling connects a terminal device to the main data bus via interconnecting buses calledstubs. Connecting terminals create a load on the main bus, creating impedance mismatchesand resultant signal reflections that can distort and degrade signal quality on the bus. Systemerror rate performance and good signal to noise ratio require a balance between stubimpedance being low enough to provide adequate terminal signal levels but high enough toreduce signal distortion from reflections.

     The main bus is terminated at each end of the cable with the characteristic impedance to minimize reflections caused by transmission line mismatch. With no stubs attached, the main bus looks like an infinite length transmission line with no disturbing reflections. When the stubs are added to connect terminals the bus is loaded locally and a mismatch occurs, which can result in reflections. The degree of mismatch and

     resulting signal distortion is a function of the absolute impedance Z presented by the stub and terminal impedance. To minimize signal distortionit is desirable to maintain a high stub reflectedimpedance into to the main bus. At the same time the impedance needs to be low so that adequate signal power will be delivered to the receiver.

     A trade-off and compromise between these conflicting requiremets is necessary to achieve the specified signal to noise ratio and system error rate performance. In addition to this trade-offs, careful consideration must be made in the determination of the type of connector used to connect the terminal to the bus.

     MIL-STD-1553B allows two methods of coupling terminal devices to the main bus:

     1. Direct coupling

     2. Transformer coupling.

     Figure 3: Coupling Methods Direct& Transformer Coupling

     Direct coupling connections are wired directly to the bus cabling. The isolationresistors and transformer are internal to the terminal device, not requiringadditional coupling hardware. Direct coupling connections can only be used withstub lengths of less than 1 foot.Isolation resistors provide some protection for the main bus in the event of a stubor terminal short, but MIL-STD-1553B cautions the use of direct coupling becausea terminal short could disable the entire bus. Direct stubs can also causesignificant impedance mismatches on the bus.

     Transformer coupling utilizes a second isolation transformer, located external tothe terminal device, in its own housing with the isolation resistors. Transformercoupling extends the stub length to 20 feet and provides electrical isolation, betterimpedance matching and higher noise rejection characteristics than directcoupling. The electrical isolation prevents a terminal fault or stub impedancemismatch from affecting bus performance.

  2. Remote Terminal

     Remote terminals are defined within the standard as All terminals notoperating as the bus controller or as a bus monitor.Therefore if it is not acontroller, monitor, or the main bus or stub, it must be a remote terminal.The remote terminal comprises the electronics necessary to transfer databetween the data bus and the subsystem. So what is a subsystem? For1553 applications, the subsystem is the sender or user of the data beingtransferred.

     In the earlier days of 1553, remote terminals were used mainly to convertanalog and discrete data to and from a data format compatible with thedata bus. The subsystems were still the sensor that provided the data andcomputer, which used the data. As more and more digital avionics becameavailable, the trend has been to embed the remote terminal into the sensorand computer.

     A remote terminal typically consists of a transceiver, an encoder/decoder,a protocol controller, a buffer or memory, and a subsystem interface. In amodern black box containing a computer or processor, the subsystem interface may consist of the buffers and logic necessary to interface to thecomputer's address, data, and control buses. For dual redundant systems,the most prevalent in today's applications, two transceivers and two encoders/decoders would be required. Theremote terminal consists of all the electronics necessary to transfer data between the data bus and the user or originator of the data being transferred.

     Figure 4: Remote Terminal Architecture

     But a remote terminal must be more than just a data formatter. It must be capable of receiving and decoding commands from the bus controller and responding accordingly. It must also be capable of buffering a message worth of data, detecting transmission errors and performing validation tests upon the data, and reporting the status of the message transfer. Notice 2 to the standard also requires that a remote terminal be capable of performing a few of the bus management commands (referred to as mode commands). For dual redundant applications, it must be capable of listening to, and decoding, commands on both buses at the same time.

     A remote terminal must follow the protocol defined by the standard. It can only respond to commands received from the bus controller (i.e., it speaks only when spoken to). When it receives a valid command, it must respond within a very small, closely defined amount of time. If a message doesnt meet the validity requirements defined, then the remote terminal must invalidate the message and discard the data (not allow it to be used by the subsystem). In addition to reporting status to the bus controller, most remote terminals today are capable of providing some level of status information to the subsystem.

     i)Functional Elements

     A MIL-STD-1553 terminal may be specificallydesigned as a standalone remote terminal, embedded remote terminal, bus controller or bus monitor. Flexible terminal designs often perform both buscontroller and remote terminal functions. This is achievable because of their intelligence (processing power) and a common front end design compatible with both remote terminal and bus controller functions. This section will describe the functional elements of a generalized terminal design.[6]

     Figure 5: Remote Terminal Functional Elements

     The four major functional elements are:

• The analog receiver/transmitter

• The digital encoder/decoder

• The subsystem interface.

  1. Analog Transmitter/Receiver

     The analog transmitter/receiver functional element is primarily the analog front end required to interface the terminal's digital logic with the data bus. This section includes the coupling transformer and fault isolation resistors required for a direct coupled connection to the data bus. The 1553 receiver provides low level noise rejection and a digital output compatible with the digital logic that follows in the decoder.

  2. Encoder/Decoder

     The encoder/decoder is used to analyze the data bits and words required for data transfer on the receiver side of the terminal. The squared up signal from the receiver is input to the decoder, which senses bit timing to decode the sync pattern, data bits, and parity to identify command/status or

     data words. Bit patterns other than the sync pattern are checked to verify proper Manchester encoding. The number of bits per word and parity are verified to complete the bit and word analysis.

  3. Protocol Sequencer & Subsystem Interface

  The encoder/decoder is transparent to data word type and contents. Therefore, it passes the words with the error indications to the message processor for further analysis. The message processor continues the analysis by performing command word decoding, address validation, data flow direction (transmission or reception), data reception, message length validation, and data storage when receiving data and data transmission for transmitting data. A major task of the protocol sequencer is the subsystem interface control. The subsystem interface complexity may vary from a single parallel or serial handshake for communication to a DMA or shared RAM interface to buffer RAM and/or mail memory.

  1. Bus Controller

     The bus controller is responsible for directing the flow of data on the databus. While several terminals may be capable of performing as the buscontroller, only one bus controller may be active at a time. The buscontroller is the only one allowed to issue commands onto the data bus.The commands may be for the transfer of data or the control and managementof the bus (referred to as mode commands).

     Typically, the bus controller is a function that is contained within someother computer, such as a mission computer, a display processor, or a firecontrol computer. The complexity of the electronics associated with thebus controller is a function of the subsystem interface (the interface to thecomputer), the amount of error management and processing to beperformed, and the architecture of the bus controller.[4]

  2. Bus Monitor

  A bus monitor is a terminal that listens (monitors) to the exchange ofinformation on the data bus. The standard strictly defines how busmonitors may be used, stating that the information obtained by a busmonitor be used for off-line applications (e.g., flight test recording,maintenance recording or mission analysis) or to provide the back-up buscontroller sufficient information to take over asthe bus controller. Amonitor may collect all the data from the bus or may collect selected data.The reason for restricting its use is that while a monitor may collect data, itdeviates from the command- response protocol of the standard, in that amonitor is a passive device that doesnt transmit a status word andtherefore cannot report on the status of the information transferred. Busmonitors fall into two categories:

• A recorder for testing.

• A terminal functioning as a back-up bus controller.

1. Testing [1]

   MIL-STD-1553B terminal testing has been conducted by designers and the US Air Force SEAFAC Laboratories at Wright Patterson AFB. In the past, the proof that a terminal's design was acceptable, required it to pass the SEAFAC Validation Tests. Several years ago, the government recognized that a single laboratory could not test everyone's designs. With the increasing numbers and suppliers of 1553 embedded terminals and the extensive number of chip sets being developed, something had to be done to distribute the testing load while maintaining the highly successful design verification effort.

   1. Purpose

      The purpose of any form of testing is to determine the quality or functional capability of an item. In the testing of 1553 devices, the purpose of the test procedure is to verify that the design does meet the 1553 specifications and that the options implemented have been done so correctly. In the early days of 1553 implementation, there were few, if any, standard components (e.g. transceivers, encoders/decoders, protocol sequencers, etc.) available for the designers to use. Therefore, designers were developing their own based upon their interpretation of the standard.

   2. Levels of Testing

      The levels of testing can be identified as follows: developmental, design verification, production, systems integration, and field/operational testing. These levels may be applied to the remote terminal, bus controller, monitor, or actual bus system (cable, couplers, stubs, etc.).

      These levels are discussed as follows:

      1. Developmental Testing.

         Developmental testing begins with the breadboard of the design. It is used to determine the circuits operation and to eliminate any design flaws. This level of testing also includes the testing of the circuits operating margins and tolerance limits usually over the required operational requirements (e.g., temperature range, etc.).

      2. Design Verification.

         For design verification, usually a preproduction unit is subjected to a series of tests designed to verify that the unit satisfies the requirements of the 1553 standard and the options specified in the system specification. This level is generally the most extensive phase of testing.

      3. Production Testing.

         Production testing is generally referred to as "end item" or "acceptance" testing, but can also be applied to in progress or subassembly items. It is assumed that the design has been previously verified and that this level of testing is performed to verify that all of the circuitry is functioning properly including mode code operation, error message validation, and any other special sequences that can normally be performed.

         Figure 6: Production test plan board & software

      4. Systems Integration Testing.

         The purpose of systems level testing is to insure that all elements of the bus network *play" together. This level of testing is usually centered around the operation of the bus controller's software and its ability to manage the data flow on the bus. This level of testing is generally performed in a Systems Integration Laboratory.

      5. Field/Operational Testing.

      Regardless of the amount of integration testing performed, the final design verification is the actual field/operational testing of the system. Often this is the first time the actual subsystems (as opposed to simulated systems) are interfaced to the bus network. For military applications this level of testing is usually referred to as Development Test/Operational Test (DT/OT). This level of testing is systems oriented and encompasses a total examination of all systems functions from the man/machine interface to the accuracy to the systems performance.

   3. Test Requirements

      Test requirements for terminals can be divided into two main topics: electrical interface tests (including noise tests), and protocol tests. The electrical interface tests apply to all terminal types (remote terminals, bus controllers, and monitors), whereas the protocol tests are a function of the type of terminal being tested. All tests should be applied to each of the buses when the terminal contains redundant buses. Some of the tests are used to "characterize" the terminal rather that to verify compliance to the standard and the results should be included in the Interface Control Document. Each of the tests is summarized as follows:

      1. Electrical Interface Tests

         The specifications called out in the standard define the requirements at the connector pins of the terminal. These points are defined by point A in figures 9 and 10 of MIL-STD- 1553B. It is important to note that all of the specified requirements are for the terminal itself and are not to be measured with the terminal connected to a system where they would be dependent on other system elements. The electrical

         interface tests can be subdivided into four parts: input, output, isolation, and noise tests.

         The input tests include:

         1. Input Polarity

         2. Input Impedance

         3. Input Signal Amplitude

         4. Zero Crossing Distortion

         5. Rise/Fall Times

         6. Common Mode Rejection

         7. Input Bit Rate Stability

            The output tests include:

            1. Output Polarity

            2. Output Amplitude

            3. Zero Crossing Stability

            4. Rise/Fall Times

            5. Distortion, Overshoot and Ringing

            6. Output Symmetry/Tailoff

            7. Output Noise

            8. Power on/off Noise

            9. Output Bit Rate Stability

            Since terminals functioning as monitors need not be designed with a transmitter, the output tests do not always apply. The isolation tests are used to verify the input and output isolation between buses in a redundant bus design. The requirement is given as the ratio in dB between the voltage on the active bus and the voltage on the inactive bus.

      2. Protocol Tests

         The protocol tests are performed as a function of the terminal type. Bus controllers which are also capable of performing as a remote terminal (e.g. while acting as the backup bus controller) need to be tested for both functions. The protocol tests for the remote terminal and bus controller are summarized as follows:

         1. Remote Terminal Protocol Tests.

   The first step in testing the remote terminal is to verify that the terminal responds properly to all the legal (valid) information transfer formats including BC-RT, RT-BC, RT-RT, mode commands with and without data words (receive and transmit). These formats should be tested with all subaddress and word counts implemented in the terminal. All implemented mode code operations also need to be tested. If the terminal is designed to recognize illegal commends, then all of these commands, and their specified response, need to be tested. The unique terminal address of the terminal needs to be checked by sequencing the address through all combinations while issuing commands to all the other addresses.

   In addition, if the broadcast option has been implemented, all of these tests need to be repeated for the broadcast address. The terminals timing characteristics need to be verified and

   characterized. This includes the measurement of the status word response time.

   The terminal should also be tested for its ability o respond to superseding commands. The message validation of the terminal needs to be examined by injecting messages with various error conditions.

   The validation criterion which needs to be tested includes:

   1. Sync Errors

   2. Encoding Errors

   3. Bit Count Errors (word length)

   4. Parity Errors

   5. Word Count Errors (message length)

   6. Gaps (discontinuous data)

   b) Bus Controller Protocol Tests.

   Testing of the bus controller function requires prior knowledge of the bus controllers software. The first step is to verify that the bus controller is capable of issuing the desired command list and data. This is often difficult to do, especially in systems where events occurring on the bus or data word patterns cause the insertion of various aperiodic messages into the command list. Also an important part of this test is to monitor that the controller never issues invalid commands (1553) OR commands prohibited by the systems specification (i.e., dynamic bus control mode codes). The bus controller must also be tested to insure that it transmits on only one bus at a time.

   If possible, the proper processing of the normal valid terminal responses must be tested. The bus controller must also be tested for its processing of abnormal or invalid responses. These may include: no response; improper status bits; word errors (sync, encoding, parity, etc.); discontinuous data words; and word count errors. The bus controllers timing characteristics also needs to be verified. This includes the minimum intermessage gap and the minimum no response time out. As can be seen, knowledge of the software operation is required in order to perform most of the bus controller protocol tests.

2. FUTURE WORK

   From this paper we conclude that communication between any subsystems present in satellite or spacecraft is possible more reliably with the help of mil-std-1553 bus. Now onwards the real interfacing and programming are to be done on the basis of special RT (Hybrid, STIC, and ACE). It also comes from different vendors in different modules as ACTEL provides its IP core instead of its interfacing card as RT, and you can easily interface through core as compare to card. We can also check its terminal by tester/simulator, and correct it if any error persists.

3. REFERENCE

   1. DDC MIL-STD-1553 DESIGNERS GUIDE 105 Wilbur Place

      Bohemia, New York 11716-2482 SIXTH EDITION

   2. MILSTD1553.com – Complete Online Reference for MIL- STD-1553

   3. An Interpretation of MIL-STD-1553B, Doc 1553 Interpretation.fm, ver 2.0, © 27 Aug 2004, 10:27, SBS Technologies

   4. MIL-STD-1553 Tutorial v1.3 December 2002,AIM GmbH Sasbacher Str. 279111 Freiburg, Germany

   5. http://www.ddc-web.com

6)MIL-STD-1553 Tutorial (1600100-0028), Condor

Engineering, Inc.Santa Barbara, CA 93101

1. Mil-Std-1553 Aircraft Internal Time Division Command / Response Multiplex Data Bus OverviewbyLeroy Earhart, MSEE President, TEST SYSTEMS, Inc.

   Phoenix, Arizona602-861-1010

2. http://www.mil-std-1553.org/