The 1553 standard is organized similar to most military standards with a foreword, scope, referenced document section, definitions, general requirements, the appendix, and a tri-service Notice 2. Notice 2, which supersedes Notice 1, was developed to define which options of the standard are required to enhance tri-service interoperability and to further define some of the open-ended timing variables implied within the standard.
1.1 Key Elements
The bus controller’s main function is to provide data flow control for all transmissions on the bus. In this role, the bus controller is the sole source of communication. The system uses a command /response method.
The embedded remote terminal consists of interface circuitry located inside a sensor or subsystem directly connected to the data bus. Its primary job is to perform the transfer of data in and out of the subsystem as controlled by the bus controller. This type of terminal usually does not have bus controller capability. However, if the sensor itself is fairly intelligent, it can become a candidate for the backup bus controller function. Generally, an intelligent subsystem (i.e., computer based) can become a backup bus controller if a second computer, equal in function to the primary, is unavailable.
The stand-alone remote terminal is the only device solely dedicated to the multiplex system. It is used to interface various subsystem(s), which are not 1553 compatible with the 1553 data bus system. Its primary function is to interface and monitor transmission in and out of these non-1553 subsystem(s).
The bus monitor listens to all messages, and subsequently collects data, from the data bus. Primary applications of this mode of operation include: collection of data for on board bulk storage or remote telemetry; or use within a “hot” or off-line back-up controller to observe the state and operational mode of the system and subsystems.
The fourth item is the data bus itself. The standard defines specific characteristics for the twisted pair shielded cable. Notice 2 tightens these requirements and adds a definition for connector polarity.
The last item to be discussed is the data bus coupler unit that isolates the main bus from the terminals. MIL-STD-1553B allows two types of data bus interface techniques; direct coupling and transformer coupling. Subsystems and 1553 bus elements are interfaced to the main data bus by interconnection buses (called “stubs”). These stubs are either connected directly to the main bus or interfaced via data bus couplers. The data bus couplers contain two isolation resistors (one per wire) and an isolation transformer (with a ratio of 1 to the square root of 2). The purpose of the data bus couplers is to prevent a short on a single stub from shorting the main data bus. The selection of the value of the resistors, the transformer’s turn ratio, and the receiver impedance are such that the stub appears to the main bus as a “clean interface” (i.e., high impedance). This technique reduces the distortion caused on the main data bus by the termination. The characteristics of the data bus couplers are discussed in paragraph 4.2.4. Main buses utilizing direct coupled stubs must be designed to withstand the impedance mismatch of the stubs. This can be reduced by minimizing stub length (less than one foot) and “tuning” the bus by terminal spacing. Designs not using data bus couplers should be carefully analyzed and tested to determine if waveform distortion is significant enough to cause receiver problems. The other risk associated with direct coupled stubs is a short on a stub will cause the main bus to fail. The obvious advantage to direct coupled stubs is the elimination of the logistical problems associated with another device and the installation problem of locating these small devices (approximately 1 inch cube) in the aircraft. Today, data bus couplers and line terminating resistors are available in molded packages, which can become part of the wiring harness, thus eliminating some of the installation problems. Also, multiple data bus couplers and data bus line terminating resistors are available in single packages, which reduces the number of unique units installed per aircraft.
1.2 Message Types
This handshaking process validates error free message completion. Since broadcast message formats are transmitted to multiple receivers, a more detailed scheme is required to validate error free message reception (this method is described in paragraph 1.4.2). Also, since address 31 is used by all terminals receiving a broadcast message, subaddressing needs to be managed on a data bus system basis rather than on a remote terminal basis. The ability to define and use more than 30 subaddresses is discussed in paragraph 3.7.1.
The information transfer formats allow communications between two elements in the data bus system the bus controller and the remote terminal (RT). In 1553, the bus controller is in control of all communication and it is the sole device allowed to transmit command words. Notice that all messages are initiated by the bus controller using command word(s).
Messages to a device (remote terminal) from the bus controller are issued using a command word (see figure II1.2) containing the remote terminal’s address, direction of message transmission (transmit/receive bit), subaddress (destination within the specific remote terminal or subsystem), and the word count.
The command word is immediately followed by the appropriate number of data words specified in the command word. The receiving terminal validates error free message reception by transmitting a status word (see figure I-1.3), which contains information about its health. Using this technique, the bus controller can transmit data to any terminal attached to the data bus. In a similar manner, the bus controller can initiate a command to a remote terminal, which requires the remote terminal to transmit a specific message to the bus controller. This is accomplished using the RT to bus controller message format. Similarly communication can be established between two unique remote terminals, when the bus controller commands one terminal to receive data and the other terminal to transmit data. Neither the receiving nor the transmitting terminal knows where the message originated or destined. Both will transmit status words in the proper formats. Each status word is evaluated by the bus controller to verify error free message completion. In addition to these three message formats, three control message formats are provided to support data bus system management. These formats are mode code formats allowing the transmission of a command word and up to one data word from the bus controller to a unique remote terminal. The remote terminal’s response involves the transmission of a status word and up to one data word upon receipt of the mode command. The use of each mode code will be discussed in paragraph 1.4.2.
Broadcast formats are identical to the nonbroadcast formats discussed above, except the bus controller transmits commands using a remote terminal address of “31” (11111), which has been reserved for this function. All remote terminals with the broadcast reception capability will receive this command, validate error free message reception, and establish a status word response, but the transmission of the status word will be suppressed. Obviously, if multiple terminals simultaneously transmitted their status responses a bus “crash” (undetectable message transmissions) would occur. As can be seen by the RT to RT(s) transfer formats (see figure I-1.1), the bus controller can set up a broadcast data reception for all terminals and then command a single terminal (unique address) to transmit. Since the data bus system is required to follow the last valid command, the unique terminal will transmit its status word (which will be ignored by the other terminals) followed by the specified number of data words. This format allow a a subsystem to broadcast its data directly to multiple users. Broadcast messages can be validated using a transmit status or transmit last command mode code (see paragraph 1.4). Therefore, even broadcast message formats have a command/response approach to message validation, if required by the system design. Notice 2 of the standard allows for the transmission by the bus controller of broadcast mode codes only (whereas Notice 1 forbid all broadcast messages). This will ease the bus controller’s overhead in performing such tasks as minor/major frame synchronization.
1.3 Word Types
The command word provides the definition of the message format to be transmitted and can only be transmitted by the bus controller. As seen in the message format section, the command word may be followed by data, another command word, or a response time gap prior to status word transmission by the remote terminal. The command word sync pattern is a unique invalid Manchester waveform, which cannot be duplicated by data (see figure I-1.3). The command word sync and the status word sync are identical and the inverse of the data word sync pattern. Therefore, command and status words, which initiate a sequence, can always be distinguished from data word sync patterns. The command word address is always the address of the remote terminal being com- mended; a bus controller does not have an address while in the active bus controller mode (backup bus controllers can function as an RT with a unique address or as a bus monitor with no address until they become an active bus controller). The transmit/receive (T/R) bit indicates the direction of flow of data words (i.e., receive means data to be received by the remote terminal). The subaddress/mode code field has two purposes. When a unique terminal is to receive or transmit data, the subaddress acts as an internal address to point to the type of data desired, the location of a data pointer in memory, subsystem interface, etc. (see paragraphs 3.7.1 and 5.3 for further discussion on subaddressing).
When the subaddress field is 00000 or 11111, it indicates that the next field contains the number of the mode code. The next field (word count/mode number) contains the number of data word(s) in the message or the number of the mode code. Odd parity is established for all words based on the 16 bits of data plus parity bit.
The data word contains a unique sync (three bit times long), 16 data bits, and a one bit parity. No restrictions are placed on the encoding of the data field, except that the “most significant bit shall be transmitted first.” Once again, parity is odd and established on the 16 bits of data plus the parity bit.
Recently, there have been several efforts to standardize on data word formats for the more commonly used functions. The Army and Navy have recently developed data bases for some avionics equipment. The designer should check the status of these efforts before establishing a unique set of data formats for the system. Section 80 (formerly Chapter 11) of the “MiL-HDBK-1553 Multiplex Applications Handbook” has established guidelines for the development of data word and message formats for data bus applications. (See paragraph 3.9 for further discussion on system documentation and Interface Control Documents.) The status word utilizes the same sync format as the command word. The remote terminal address is placed in the transmitted status word for two reasons; so that the status word can be validated by the bus controller (a remote terminal may also validate the status word address field against that of the command word’s during an RT-RT message transfer), and so that the status word will not be misinterpreted by the other terminals as a command word. Any status word transmitted, must contain valid information at all times (i.e., following RT power-up, during initialization, and during normal operation). The message error bit is the only required status bit and it is used to identify messages which do not pass the word or message validation tests of 1553 (1553B paragraph 4.4.1.1 and 4.4.1.2). MIL-STD-1553 requires this bit to be set if a message fails to pass the tests and the status word to be suppressed (NOT to be transmitted). This means that all messages that are NOT error tree will NOT have a responding status word. This allows the bus controller to timeout on the no status response, thus alerting the bus controller of a failure condition. To obtain the status word with the error bit set requires a transmit status mode code or transmit last command word mode code to the terminal to retrieve the untransmitted status word (see paragraph 1.4.2). The only exception is the illegal command option (see paragraph 1.6.3). The instrumentation, service request, broadcast command received, busy, subsystem flag, dynamic bus controller acceptance, and terminal flag bits are all optional and are discussed in paragraph 1.4.1. Notice 2 tightens the requirements for remote terminals employing broadcast recognition, capability of dynamic bus control, RT built-in-test, or subsystem built-in-test, by requiring the use of the bits in the status word associated with these functions. Bit positions 12 through 14 are reserved for future use and must be transmitted as zeros. To obtain usage of these bits requires DoD approval (no approval has been given as of 7/87). The last bit of the status word is the odd parity bit, which is calculated in a similar manner to all other parity bits.
1.4 Options Within the Standard - Part 1
1.4.1 Status Bits
The optional status bits are; instrumentation, service request, broadcast command received, busy, subsystem flag, dynamic bus control acceptance and terminal flag.
The instrumentation bit in the status field Is set to distinguish the status word from the command word. Since the sync field is used to distinguish the command and status words from a data word, a mechanism to distinguish command and status word is provided by the instrumentation bit. By setting this bit to logic zero in the status word for all conditions and setting the same bit position in the command word to a logic one, the command and status words are identifiable. If used, this approach reduces the possible subaddresses in the command word to 15 and requires subaddress 31 (11111) to be used to identify mode commands (both 11111 and 00000 are allowed). If the instrumentation bit is not used, the bit will remain set to logic zero in the status word for all conditions.
The service request bit is provided to indicate to the active bus controller that the remote terminal is requesting service. When this bit in the status word is set to logic one, the active bus controller may take a predetermined action (if only one action can occur) or use the transmit vector word mode command to identify the specified request. The message format for acquiring this is discussed under transmit vector word mode command (below).
For terminals implementing the broadcast option, the broadcast command received bit is set to logic one when the proceeding valid command word was a broadcast command (remote terminals address 31). Since the broadcast message formats require the receiving remote terminals to suppress their status responses, the broadcast command receive bit is set to identify that the message was received error free. To allow the bus controller to examine the status word requires the use of the transmit status word mode code or the transmit last command word mode code. The broadcast command received bit will be reset, when the next valid command occurs if it is NOT one of two mode codes; transmit status word or transmit last command word. Therefore, to analyze the status word after a broadcast message has occurred requires a mode code message to a unique terminal. The mode code message must be transmitted before any other message transmission to that unique terminal in order to retrieve to proper status word.
The busy bit in the status word is set to logic one to Indicate to the active bus controller that the remote terminal is unable to move data to or from the subsystem in compliance with the bus controller’s command. A busy condition can exist within a remote terminal at any time causing it to be non-responsive to a command to send data or to receive data. This condition can exist for all message formats. In each case, except the broadcast message formats, the active bus controller will determine the busy condition immediately upon status response. In the case of the broadcast message formats, this information will not be known unless the receiving terminals are analyzed using transmit status mode code after the broadcast message. If the status word has the broadcast received bit set, the message was received and the terminal was not busy. Notice 2 to the standard discourages the use and existence of busy conditions, as they affect the overall communications flow on the bus, add overhead to the bus controller, and may have adverse effects upon data latency requirements within time critical systems (i.e., flight controls). A busy condition must only occur as the results of a particular command or message received by the terminal and NOT due to an internal periodic function. Thus for a non-failed terminal, the bus controller, with prior knowledge of the RT’s characteristics, can determine what actions (commands/messages) will cause an RT to become busy, thus preventing any unnecessary busy conditions.
The subsystem flag bit is provided to Indicate to the active bus controller that a subsystem fault condition exists and that data being requested from the subsystem may be invalid. The subsystem flag may be set in any transmitted status word. If more than one subsystem is interfaced to the remote terminal the subsystem flag is the ORed results of all subsystems. The only method available in 1553B to determine subsystem(s) health is via a normal message. The use of the subsystem flag bit requires considerable system control philosophy. If upon receiving the bit set, the bus controller is to do anything other than stop all communication with the terminal, a detailed protocol is required.
The system protocol must define the message (NOT a mode code) that the bus controller uses to poll the subsystem to determine the reason the bit was set. This polling will provide system application software the knowledge to determine the availability and status of the unit(s). If the unit(s) are usable, the subsystem flag bit must be cleared so that troubleshooting analysis does not occur, until another failure occurs. This can be accomplished using additional messages or upon transmission of the first message. This process usually requires several transmissions during which time the remote terminal is NOT a part of the normal periodic data bus traffic. Obviously user subsystems must deal with this temporary situation; permanent loss of this data. Mode commands can not be used to acquire subsystem built-in-test results.
The next bit in the status word is provided to Indicate the acceptance of the bus controller’s offer to become the next bus controller. The offer of bus control occurs when the presently active bus controller has completed its established message list and issues a dynamic bus control mode command to the remote terminal that is to be the next potential controller. To accept the offer the potential bus controller sets its dynamic bus control acceptance bit in the status word and transmits the status word. The establishment of which controller should be the next potential controller will be discussed in the system design section (see paragraph 3.2). For Air Force applications, Notice 2 prohibits the bus controller from issuing a dynamic bus mode code, therefore this bit would always be set to zero.
The terminal flag bit is set to a logic one to Indicate a fault within the remote terminal. This bit is used in conjunction with the three mode code commands, inhibit T/F flag, override inhibit T/F flag, and transmit BIT word. The first two mode code commands deactivate and activate the functional operation of the bit. The transmit BIT word mode code command is used to acquire more detailed information about the terminal’s failure. Most MIL-STD-1553B RT chip sets provide BIT word responses indicating the health of the chip. Notice 2 requires implementation of this bit within the status word if the remote terminal is capable of any form of self test (including what may be performed internal to the various chip sets such as data wraparound and data comparisons).
1.4 Options Within the Standard - Part 2
1.4.2 Mode Codes
The basic philosophy of the information transfer system is that it operates as a transparent communication link. “Transparent” means that an application’s function does not need to be involved with the management of communication. Obviously, the information transfer system requires management that introduces overhead in the data bus system. The command words, status words, status word response gaps, and intermessage gaps are the overhead. Within the command word the mode codes provide data bus management capability. The mode codes (see table I-1.1) have been divided into two groups; mode codes without a data word (00000-01111) and mode codes with a data word (10000-11111). The use of bit 15 in the command word to identify the two types was provided to aid in the decoding process. Also, the use of a single data word instead of multiple data words was adopted to simplify the mode circuitry.
Generally, with these two types of mode commands, all data bus system management requirements can be met. Additional overhead is required by the system to maintain RT health, system time control (synchronization), subaddress message mapping, aperiodic message control, initialization/shutdown messages, etc. The determination of whether the command word contains a mode code is accomplished by decoding the subaddress/mode field (bit times 10-14). This field being either all zero’s [00000] or all one’s [11111] indicates that the command is a mode code and that the word count/mode code field (bit times 1519) contain the mode code type. Notice 2 requires that terminals must decode both indicators and that they must not convey different information. (Some earlier designs had used the [00000] indicator for the terminal hardware and the [11111] indicator for subsystem hardware.
Notice 2 also permits the broadcasting of mode codes. While this can reduce bus controller overhead in the areas of frame synchronization, it can have adverse effects upon the system if inadvertently issued (e.g., broadcast of a reset mode code). The system’s designer is cautioned to research the implications of the use of the broadcast mode code commands before implementation.
There is no particular reason for the numerical assignment of the mode codes, except for dynamic bus control [00000], which was previously defined in 1553A. The separation of mode commands into two categories (with and without data words) is important to allow for controlled expansion of the standard. By controlling the mode code command number and its definition, commonalty between various terminals can be maintained. All undefined 1unused] mode codes are considered Illegal commands (see paragraph 1.6.3 for discussion of illegal command protocol). Notice 2 requires that all remote terminals must implement the following mode codes as a minimum: a) transmit status word, b) transmitter shutdown, c) override transmitter shutdown, and d) reset remote terminal. The bus controller must have the capability of implementing all mode code commands. The message formats associated with mode commands are shown in figure I-1.1.
The dynamic bus control mode code [00000] is provided to allow the active bus controller a mechanism (using the information transfer system message formats) to offer a potential bus controller (operating as a remote terminal) control of the data bus. Only the single receiver command (unique address) is allowed to be issued by the active bus controller. The response to this offering of the bus controller is provided by the receiving remote terminal, using the dynamic bus control acceptance bit in the status word. Rejection of this request by the remote terminal requires that the presently active bus controller must continue offering control to other potential controllers, the same controller, or remain in control. When a remote terminal accepts control of the data bus system by setting the dynamic bus control acceptance bit in the status word, control is relinquished by the presently active bus controller and the potential bus controller can then begin bus control. Note that Notice 2 prohibits the bus controller from ever issuing this mode command for Air Force applications.
Two mode codes are used to synchronize the data bus system; synchronize without a data word and synchronize with a data word. Synchronization informs the terminal(s) of an event time, to allow coordination between the active bus controller and terminals. Synchronization information may be implicit in the command word [mode code 00001] or in the data word [mode code 10001] following the command word. If a data word is used, the definition of the bits are the responsibility of the system designer and may contain system information such as timing data, data mapping pointers, etc. Paragraph 3.6 provides a system discussion of the use of the synchronize with data word mode code for remote terminal synchronization and subaddress mapping within a remote terminal for both periodic, aperiodic, and time critical messages.
The status word associated with the transmit status word mode code [00010] is identical in format to the status word transmitted with every error free message. However, this is one of two mode codes, which do not change the state of the status word. Therefore, the status word returned with this mode code represents the status word of the previous message NOT the status of the mode code message. Paragraph 5.2 provides a discussion on the affects of back to back transmission of this mode code. This mode code gives the bus controller the ability to analyze problems associated with the previous message. Using this approach, a bus controller can organize the communication with a terminal to obtain error analysis data.
The initiate self-test mode command [00011] is provided to initiate built-in-test (BIT) circuitry within a remote terminal. The mode code is usually followed, after sufficient time for test completion, by a transmit BIT word mode command [10011] yielding the results of the test. Notice 2 specifies that the RT receiving this mode code must complete its test and have the results ready within 100 milliseconds. The purpose of establishing an upper limit to the amount of time required to perform a reset is that the bus controller, with this prior knowledge, is aware of the maximum amount of time that the controller will be off-line” or busy, and may cease further communications with this terminal until such time has elapsed. This prevents the bus controller’s software from continuously being vectored to error handling routines. The message formats provided for the initiate self-test mode command allow for both individual requests and multiple requests (broadcast). Notice that the initiate self-test mode command is associated with the 1553 multiplex hardware only and NOT with the interfacing subsystem. Paragraph 5.2 discusses the problem of separating subsystem self test and health status messages from RT tests in terminals with embedded RTs.
The transmit BIT word mode command [10011] provides the BIT results available from a terminal, as well as the status word. Typical BIT word information for both embedded and stand-alone remote terminals include encoder-decoder failures, analog transmitter/receiver failures, terminal control circuitry failures, power failures, subsystem interface failures, and protocol errors (e.g., parity, Manchester, word count, status word errors, and status word exceptions). The internal contents of the BIT data word are provided to supplement the appropriate bits already available via the status word. Notice that the transmit BIT word within the remote terminal “. . . shall not be altered by the reception of a transmit last command or transmit status word mode code” received by the terminal. This allows error handling and recovery procedures to be used without changing the error data recorded in this word. However, the RT will only save the last command and the status code field [of the status word] if the mode code transmit last command or transmit status word are transmitted. Broadcasting of this command by the bus controller is not allowed. Another point, which needs to be mentioned again, is that the function of transmitting RT BIT data “. . . shall not be used to convey BIT data from the associated subsystem[s].” See discussion on subsystem flag bit in paragraph 1.4.1.
Four mode code commands are provided to control the transmitters associated with terminals in a system. These commands can be sent to a single receiver or broadcasted to multiple users. The transmitter shutdown mode code [00100] is used in a dual-redundant bus structure, where the command causes the transmitter associated with the other bus to terminate transmissions. No data word is required for this mode command. The overrlde transmitter shutdown mode code [00101] is used in a dual-redundant bus structure where a previously disabled transmitter is enabled. No data word is provided for this mode code.
The selected transmitter shutdown mode code [10100] is used in a multiple (greater than two) redundant bus structure where the command causes the selected transmitter to terminate transmissions on its bus. A data word is used to identify the selected data bus. The override selected transmitter shutdown mode code [10101] is used in a multiple (greater than two) redundant bus structure where the command allows the selected transmitter to transmit on its bus when commanded. The format of the data word associated with these two mode commands is NOT controlled by the standard and must be defined by the systems designer. Another method of overriding the transmitter shutdown mode codes [00100 and 10100] is to issue a reset mode code to the terminal.
Note that the standard or Notice 2 does not imply that issuance of either the transmitter shutdown or the selected transmitter shutdown mode codes will cause the associated receiver to also be shutdown. If the receiver does not “shutdown,” then the system’s designer should be aware that the terminal may still be receiving and processing data (on the shutdown bus). Therefore, the bus controller should remove the terminal from the active periodic communications list.
1.4 Options Within the Standard - Part 3
The override inhibit terminal flag mode command [00110] negates the inhibit function thus allowing the T/F flag bit In the status response to report the present condition of the terminal. This mode code can be transmitted by the active bus controller to both single and multiple receivers. There Is no data word associated with this mode code. This mode code could be used to analyze all the faults that exist in a remote terminal, since the inhibit terminal flag mode code will mask faults that have occurred since its implementation.
The reset remote terminal mode code [01000] causes the addressed terminal(s) to reset themselves to a power-on initialized state. This mode code may be transmitted to an individual remote terminal or to multiple remote terminals (broadcast). Notice 2 requires that all terminals receiving this command shall complete their reset function within 5 milliseconds following the transmission of their status word (non-broadcast message). This mode code provides a means to “start over” at a known point. It may be the last thing the error handling software tries before giving up on a terminal.
The transmit vector word mode code [10000] is associated with the service request bit in the status word and is used to determine specific service being required by the terminal. The service request bit and the transmit vector word mode command provide the only means available for the terminal to request the scheduling of an asynchronous message, if more than one service request exists per terminal. If a remote terminal contains only a single service request, the bus controller may be “smart enough” to perform the request without the transmit vector mode code data word to point to the location of the commands within the bus controller to perform the service. The message format for this single receiver operation contains a data word associated with the terminal’s response. Figure I-1.4 illustrates the message formats associated with this mode command. Since a service request Is handled at the convenience of the bus controller and NOT the remote terminal’s, a remote terminal design feature Is required to queue multiple service requests until they can be serviced by the bus controller. The transmission of the transmit vector word mode code by the bus controller does not necessarily release the remote terminal to set the service request bit for a new request. There are several methods that can be used to resolve this handshake problem. Whatever the solution chosen by the systems designer, it should be applied to all terminals in the system. Thus, it’s a system design issue, which should be addressed in the multiplex system specification. Solutions that are acceptable to most designers are; after transmission of the transmit vector word code allow new service request codes, and use of the synchronize without data word mode code command to release the RT to set a new service request. However, the first method has the potential of losing a critical request if the transmit vector word is not received properly by the bus controller. To counter this problem, previous designs have used the second method to release the service request queue. The transmission of the synchronize without data word mode code after proper receipt of the transmit vector mode code frees the terminal’s service request bit at the expense of an extra transmission.
The transmit last command [1001 0] is used in the error handling and recovery process to determine the last valid command received by the terminal, except for this mode code. The message format contains the previous status word and a data word. The data word contains the previous 16 bits of the last valid command word received. Notice that this mode command will not alter the state of the receiving terminal’s status word. This fact allows this mode command to be used in error handling and recovery operations without affecting the status word, which could contain added error information. Some hardware is designed such that both the last command word and the status word are made available to the error handling software when the transmit last command mode code is received by the bus controller.
Each of the mode code types (with and without data words) have several unused mode codes that are reserved for future use and cannot be used without the permission of the Office of Prime Responsibility (OPR), which Is the USAF. See paragraph 1.6.3 fore discussion of illegal command protocol, that could be used if a remote terminal received a reserved mode code.
1.5 Data Bus Network Considerations
1.5.1 MIL-STD-1553B Bus Network Requirements
Table I-1.2 is a summary listing of the data bus coupling requirements contained in 1553B. The characteristics of the twisted-shielded pair cable have been relaxed from 1553A to allow selection of cable types from a variety of manufactures. It has been shown that minor variations from the specified fed cable characteristics do not significantly affect the system performance. Today it is possible to obtain high quality cabling from various manufacturers which meet all the requirements of the standard. Notice 2 tightens the shielding requirements to 90.0 percent coverage for the cable and 360 degree shielding with 75.0 percent coverage for connector junctions, cable terminations, and bus-stub junctions.
A great deal of concern is attributed to the cable network requirements including; bus length, coupling and stubbing. MIL-STD-1553B does not specify a maximum main bus length, because the cable length, number of terminals and length of stubs are all subject to trade-offs and must be considered in the design for reliable system operation.
To help understand these problems a generalized multiplex bus network configuration is shown in figure I-1.5. 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 distortion it is desirable to maintain a high stub reflected impedance 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 requirements is necessary to achieve the specified signal-to-noise ratio and system error rate performance. In addition to these trade-offs, careful consideration must be made in the determination of the type of connector used to connect the terminal to the bus. This consideration should include the required integrity, isolation, and shielding (Notice 2 requires 360 degrees of shielding with a minimum of 75% coverage from the cable to the connector). Other issues, which need to be addressed, include the location and type of connector (concentric, twinax, etc.), and if the data bus connectors will be standalone or included with other signals in a multi-contact connector. As a minimum, the two buses (A and B) should be brought into the terminal via separate connectors for isolation purposes.
Two methods for coupling’ a terminal to the main bus are defined in 1553B, transformer coupling and direct coupling (see figure I-1.6). Transformer coupling is usually used with long stubs (1 to 20 ft.) and requires a coupler box or in-line molded coupler, separate from the terminal, located at the junction of the main bus and stub. Direct coupling is usually limited to stubs of less than 1 ft. In transformer isolated stubs, fault isolation resistors are included to provide protection for the main bus in case of a short circuit in the stub or terminal. The transformer characteristics defined in 1553B and listed in table I-1.2 provides a compromise for the signal level and distortion characteristics delivered to the terminals. The transformer turns ratio (1 :1.41) provides beneficial impedance transformations for both terminal reception and transmission.
The advantages of transformer coupling are as follows:
- The 1:1.4 turns ratio increases the impedance of the stub and terminal by a factor of two, as seen by the main bus. This reduces the loading effects of the distributed capacitance of the stub cable. This is advantageous by reducing reflections on the bus and increasing the overall bus impedance.
- For a direct coupled terminal, the impedance of the stub, as viewed from the secondary side of the terminal isolation transformer, is 2Zo. For a transformer coupled terminal, this impedance is Zo. Allowing the terminal to drive into a matched impedance improves the terminal’s transmitter waveform by minimizing reflections back to the terminal.
- Improved DC isolation.
- Improved common mode rejection:
Notice 2 states that for Navy applications, terminals shall have both transformers and direct coupled stubs available, whereas for Army and Air Force applications, only transformer coupled stubs are required.
1.5.2 Data Bus Network Analysis
A plot of the calculated first-order-magnitude stub absolute impedance Z versus stub length is presented in figure I-1.7. As indicated, the improvement of stub load impedance is a result of impedance transformation that is proportional to the square of the turns ratio, assuming an ideal transformer. The band of curves for the transformer-coupled case indicated by the darkened area between the curves results from assuming various values of transformer shunt impedance.
The lower bound is the curve using a transformer with the minimum impedance specified in 1553B. The upper bound is for an ideal transformer with very high impedance. All values of stub impedance are magnitude values for a 70-ohm cable with 30 pF/ft capacitance and are calculated for 1,000 ohms terminal input impedance, with the exception of the upper direct-coupled curve. This curve is based on the 1553B specified terminal input impedance of 2,000 ohms. It can be seen from these curves that stub impedance values are increased generally by use of the transformer, which provides at least a 2 to 1 improvement for the longer (greater than 10 ft) stubs. The curves also show the importance of the transformer characteristics for maintaining the expected improvement.
1.5 Data Bus Network Considerations - Part 2
where,
ZO is the characteristic impedance of the data bus and ZR is the reflected impedance from the bus to the stub. Therefore, the transformer impedance transformation is:
Therefore, the coupling transformer specified in 1553B provides the characteristics desired for reducing reflections and maintaining signal levels for systems where long stubs are required.
Direct coupling can be used for stub connections of 3 ft or less if terminal input impedance is maintained at the specified value:
Many configurations can be built reliably if careful attention is paid to the number, length and location of the stubs on the main bus. It is highly desirable to test a proposed network using a computer simulation and a laboratory test setup. The computer-generated data bus simulation provides more flexibility during the early design stages. The laboratory mockup with proper lengths of main bus and stubs is the final test of a good design.
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 1
1.6.1 When to Transmit a Status Word [1553B paragraph 4.4.3.3 and 4.4.3.4]
The MIL-STD-1553 status word is a vital part of achieving the command/response protocol. The transmission of a status word by a remote terminal indicates to the bus controller that the previous command or command and data was received without error. The suppression of the status word (status word not transmitted after reception of a command word) is used to indicate a message error exists if the message was NOT a broadcast message. Broadcast message formats require the status word to be suppressed to prevent a bus crash (multiple terminals transmitting simultaneously). Therefore, status words will always be transmitted for all error free, non-broadcast messages. Several types of errors can exist:
- If a command word contains an error, the terminal rejects the message and resets, and starts “looking” for a new valid command word with its unique terminal address or the broadcast address. No status word transmission should occur.
- It a command word requests data from a subaddress, which is not operational for this terminal, the standard calls this failure an “Illegal command.” Two options are available to the terminal designers; a) respond with the normal message protocol required by the standard with data from a fixed location containing “don’t care” data words, or b) design into the terminal the capability to recognize the failure and set the message error bit in the status word and transmit the status word only. This is the only time when the statue word will ever be transmitted with the message error bit set as a response to a non-mode code (normal) message. If the remote terminal design selects method a) above, usually a common area of 32 data words is set aside and all unused subaddress transmit messages are retrieved from there and all unused subaddress receive messages are deposited there. This technique is called “responding in form.” Thus, a garbage-in/garbage-out buffer is provided for all unused subaddresses, which are NOT to be transmitted by or requested by the bus controller in the first place. The standard also Identifies illegal commands as incorrect T/R bit setting and a word count that Is not allowed in the terminal. Since the standard allows the designer the choice of implementing this analysis or not, most designers ignore monitoring for illegal commands (use method a) above rather than implement the analysis. These designers depend on the bus controller NOT transmitting illegal commands see paragraph 1.6.3 also). SEAFAC testing is normally done to the above b) option.
- If the command word is a broadcast address 31, the terminal analyzes the message, sets the proper bits in the status word and then suppresses the transmission of the status word.
- If the command word is correct and the message contains an error then, the data is rejected, the message error bit is set in the status word and status word is suppressed.
Therefore, the suppression of the status word is used to indicate a broadcast message or an error condition.
1.6.2 Superseding Valid Commands [1553B paragraph 4.4.3.2] and Reset Data Bus Transmitter [1553B paragraph 4.6.3.2]
The superseding valid command requirement in MIL-STD-1553B allows communication with a remote terminal that is presently working on a command. To better understand this requirement the data bus system redundancy needs to be considered. Both a single bus system and a dual standby redundant bus system (1553B paragraph 4.6.3) will be discussed.
MIL-STD-1553B states that a superseding command can not occur before time “T” (the response time between command and status words-maximum 12 microseconds). In any bus system, an error condition exists if there is no response in time “T.” Communications can, therefore, be re-established with the remote terminal, if operational, by transmitting another command on the data bus that the previous command occurred on or any other data bus the terminal is connected to. Using the superseding valid command requirement, the remote terminal is required to respond to the new command, hopefully resolving the nonresponse to the previous command. This new command can be a normal message format or a mode code command.
In dual standby redundant systems, the “Reset Data Bus Transmitter” is a specific paragraph of 1553B (4.6.3.2), which provides specific requirements. . .”If while operating on a command, a terminal receives another valid command, from either data bus, it shall reset and respond to the new command….” Since another bus is available to the bus controller (i.e., the standby bus), the bus controller can transmit a new command to the remote terminal using the other bus. This allows the bus controller to identify messages containing a data word error, for example, to be retried on the alternate bus before the message is completed on the previous bus. It also allows the approach discussed in the paragraph above for any bus system to be used on either the active or standby bus to hopefully resolve the condition of a non-responding (silent) terminal. Therefore, superseding commends and reset data bus transmitters provide an effective means of recovery. This error management (e.g., retrying or resolving a no response) can be initiated rapidly, thus reducing bus down time (bus inefficiency).
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 2
1.6.3 Illegal Command [1553B paragraph 4.4.3.41]
As discussed in paragraph 1.6.1, concerning status word transmissions, illegal commands occur when; 1) an error exists in the T/R bit; 2) the subaddress/mode code field is an unused subaddress; or 3) an unimplemented mode code is transmitted. The command word that contains an illegal condition must first meet all 1553B word validation requirements (1553B paragraph 4.4.1.1) before Its Illegal nature can be established. If the command word does not meet these requirements, the remote terminal ignores the command. If the command word is correct, but has an illegal condition, the standard allows the designers two options: provide NO unique capability in the remote terminal to recognize the condition and respond normally as if there was NOT an illegal command, and respond with the message error bit set in the status word. The first approach is often referred to as “responding in form. This means that the remote terminal uses the normal message protocol response (figure 6 and 7 of 1553B) and the receiving device (bus controller or remote terminal for an RT-RT message) will obtain garbage” data. The second approach requires some analysis on the part of the remote terminal, but the response is straightforward. A message error has occurred and data should NOT be used. The message error alerts the bus controller of the problem. However, this is a system designer’s problem, which can not be solved by the bus controller. So reporting it helps no one. Not using the data or having the data cause a remote terminal problem is the key. This must be solved regardless of the selection of the option to respond with a status word or respond in form as if no illegal command occurred. To understand how this command can cause remote terminal data problems each illegal command will be examined.
- The impact of receiving a transmit/receive (T/R) bit set to the inverse of data flow can cause internal confusion and errors within the remote terminal or the system. If the T/R bit indicates the terminal is to transmit data, but the bus controller sends data to the terminal a problem exists. The remote terminal will recognize that data words are coming and the T/R is set to transmit and will NOT transmit. However, the remote terminal must now deal with the incoming data words. Most terminal designs without illegal command detection hardware will still map the data to a designated memory location. This must be considered when mapping data into and out of memory. If detection hardware is available, the status word message error bit will be set and the status word transmitted. When the inverted T/R bit says receive data and no data follows the command word, a real message error exists— to few words and the message error bit will be set in the status word and its transmission will depend on if the detection circuitry is present. If not, the status word will be suppressed.
- The reception of a message to an unused subaddress can cause internal remote terminal problems. Most remote terminals are designed to use mapping schemes, which map messages to memory using the T/R bit and the subaddress. Therefore, an illegal command could cause data to be written into areas of memory used for other functions. In the same way, improper data can be transmitted on the data bus by a remote terminal using an illegal command from an unused subaddress. This information could be anything and if used by a source could cause unknown responses. Therefore, as a minimum the designer should map all unused transmit and receive subaddresses to a common 32 word buffer that could be set to all zeros at initialization. Therefore, the first transmission of an unused subaddress should not affect anyone. After that if both receive and transmit commands arrive for unused subaddresses, the system could have problems. Obviously, additional memory space can be provided to separate receive and transmit unused subaddress memory areas to prevent bad data escaping the terminal. Remember the bus controller is not allowed to transmit commands requesting or transmitting data from unused subaddresses of remote terminals.
- Illegal commands, which request action associated with unused or unimplemented mode codes, must also be faced without causing remote terminal errors. These are more easily handled, because most remote terminals use chip sets which have selected when and how they will respond to each illegal mode condition. If you are interested in designing your own remote terminal, the “RT Validation Test Plan” (see Section Vl) should be used as a reference guide in determining acceptable performance. The general philosophy Is to “respond inform,” in other words, according to the protocol If It was legal. This might mean bit bucketing data words or generating data words for transmission. If a remote terminal uses no mode codes (remember that Notice 2 requires at least four mode codes), subaddress codes 00000 and 11111 (the mode codes designator) is also not needed and it can be treated as an unused subaddress. Therefore, even it a remote terminal designer chooses not to implement the option to analyze illegal commands, the design must be able to withstand the existence of these commands without causing the remote terminal internal errors or data bus system problems.
1.6.4 Invalid Command [1553B paragraph 4.4.33]
An invalid command in 1553B occurs when the command word fails to meet the criteria established for the word validation by the standard (1553B paragraph 4.4.1.1). These tests for proper sync, valid Manchester II biphase data, and information format of 16 bits plus odd parity are basic to all 1553B words, but in the case of the command word they are essential. Since the protocol depends on a command/response action, remote terminals must only respond when “spoken to” (commanded to) by the bus controller. This is accomplished by the address validation (between the particular remote terminal’s internal address and the address in the command word). Notice 2 requires that no single point failure in the address selection circuitry may cause a terminal to validate a false address. To prevent multiple terminal reception or multiple terminals transmitting data, the command word must be correct. Command word verification involves more than just using the remote terminal’s address, it includes all of the 1553 required (4.4.3.5 in 1553B) word checks. Many remote terminal designers, in an effort to get a head start on handling a command word, examine only the address and fail to validate the remainder of the word before accepting it as a command.
1.6.5 Impact of Notice 2 to MIL-STD-1553B
Notice 2 to MIL-STD-1553B, issued 8 September 1986, was developed to define which options within the standard were required to enhance tri-service interoperability of systems. The Notice goes on to further define some of the open-ended timing constraints, which were undefined within the standard.
A notice to a standard is applied whenever the standard is referenced or specified. The notice does not apply to previous versions of the standard
or applications to which the standard was applied prior to the release date of the notice. Waivers to the notice can be sought using the same technique allowed for the standard.
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 3
- Broadcast Message Formats.
Broadcast message formats are not restricted from being implemented in hardware. However, use of the broadcast command is limited to mode code commands only. This is a major departure from the Notice 1 restrictions, which prohibited broadcast messages altogether. The broadcast option for non-mode code messages may be designed into the remote terminal. If implemented, then the terminal MUST be capable of distinguishing between broadcast and nonbroadcast messages to the same subaddress. - Mode Codes and Mode Code Indicators.
The terminal hardware may be designed with any or all mode codes, but the following mode codes must be implemented: transmit status word, transmitter shutdown, override transmitter shutdown, and reset remote terminal. Remote terminal’s must be designed to recognize both 00000 and 11111 as a designator in the subaddress/mode code field of the command word. The two indicators must not convey different information. Also bus controllers must be designed to support all modes regardless of system usage.For Air Force applications, the bus controller is prohibited from issuing a dynamic bus control mode code (one of the few exceptions to a total tri-service agreement).Also timing constraints have been established for two of the mode codes: reset remote terminal, and initiate FT self test. For the reset remote terminal, the terminal must complete its reset function within 5 milliseconds after transmitting its status word to this command. For the initiate self test mode code, the terminal must complete its self test function within 100 milliseconds after transmitting its status word to this command. In both cases, while the terminal is performing the commanded function (reset or self test) the terminal may respond to a valid command by: a) no response on either bus, b) status word transmitted with the busy bit set; or c) normal response. However, any data transmitted as the result of this command MUST be valid data. - Status Word Bits.
The only required status word bit is the message error bit. However, if the terminal employs broadcast recognition, capability of dynamic bus control, RT built-in-test, or subsystem built-in-test then the bits in the status word associated with these functions are also required.The busy bits’ use (due to existence of busy conditions within a terminal) is strongly discouraged. However if these conditions affect the terminal’s ability to properly communicate via the bus, then the busy bit is to be used. Setting of the busy bit must be caused by the result of a command to the terminal. The busy bit may also be set as the result of a failure within the terminal or subsystem. - Message Formats and Subaddresses.
Remote terminal must be capable of the following nonbroadcast message formats: RT-BC, BC-RT RT-RT (receive and transmit), and mode codes commands without data words. Bus controllers must have the capability to transmit all message formats. The remote terminal must provide a data wraparound capability equal to the maximum number of data words it’s capable of processing for any subaddress. The desired subaddress for this function is 30 [11110]. The purpose of this function is to provide the bus controller the capability to test the data flow through a terminal’s front end (1553 hardware), initial subsysem interface (memory buffers), and the data bus media (cabling and bus couplers). - RT-RT Timeout.
In addition to normal message validation criteria, the remote terminal must timeout (invalidate the message) if the receive command word is not followed by the first data word within 57 ± 3 microseconds. Although this poses few problems for current hardware designs and chip sets, some of the earlier designs would wait “forever” then take the data intended for some other terminal (the transmitting terminal’s status word was ignored since it contained a command/status sync).
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 4
The data bus cable characteristics have been tightened in the area of cable shielding (90%), connector/junction shielding (360 degrees at 75%), and impedance (actual to within the range of 70-85 ohms at 1 megahertz). In addition, the polarity for concentric connectors has been defined with the center pin being the high (positive) bus signal and the inter-ring being the low (negative) bus signal. The outer ring is obviously the bus shield.
For Navy applications, terminals must have both transformer coupled stub and direct coupled stub connections externally available (either may be used). For Army and Air Force applications, only transformer coupled stubs are required. The remote terminal must limit spurious output signals during power up or down sequences to ± 250 mV for transformer coupled stubs and ± 90 mV for direct coupled stubs.
1.6.6 Responses to Nonimplemented Mode Code Commands and Undefined Mode Codes.
Table 1 of 1553B and paragraph 4.3.3.5.1.7 define mode codes while paragraph 4.3.3.6.4 identify the two types of mode codes; without data word and with data word. Table 1 also identifies a group of mode codes as RESERVED. However, table 1 fails to identify all of the binary combinations that can exist in the T/R bit and five bit mode code field. Table I-1.3 expands the 1553B table to include these possibilities. As can be seen 22 of the 64 entries are undefined and are considered INVALID. Notice from the table that these DO NOT include the RESERVED mode codes.
Several terms must be clearly defined in order to proceed with an explanation of the handling of RESERVED mode codes or UNDEFINED mode codes. For convenience, the following definitions are recapitulated with reference to 1553B.
Valid Words. (paragraph 4.4.1.1) Every word must meet four tests of validity to be declared a valid word. These tests are:
a. Valid sync field
b. All bits are encoded as valid Manchester II code
c. The information field has 16 bits + 1 parity bit
d. The parity over the word is odd parity.
A word failing any of these tests would be considered to be invalid.
Invalid Command. (paragraph 4.4.3.3) A command that does not have an RT address field that matches the address of the receiving RT or that does not have an address of 11111 if the broadcast option is implemented in the RT, or that fails to satisfy the test for a valid word shall be considered to be an invalid command.
Invalid data reception. If any data word that is part of a BC to RT message fails the tests for being a valid word, or if the message transmission if not contiguous, or if the number of data words received is not correct (does not match the command word
count field), an invalid data reception has occurred.
Illegal commands. (paragraph 4.4.3.4) An illegal command is a valid command word, but which contains a combination of T/R bit, subaddress/mode field, and data word count/mode code field that has not been implemented in the receiving RT. Notwithstanding a side discussion as to which commands may be considered to be optional, the detection of illegal commands is itself optional.
Now, the rules for setting of the message error bit in the status word and when to transmit status or to suppress transmission of a status word will be reviewed.
Paragraph 4.3.3.5.3.3 states that the message error (ME) bit of a status word shall be set to indicate that:
- One or more of the data words associated with the proceeding BC-to-RT command (receive command) was not a VALID WORD, or
- The message transmission was not contiguous per paragraph 4.4.1.2, or
- The command received was an ILLEGAL COMMAND and the RT has implemented the option for illegal command detection, or
- There was an INVALID DATA RECEPTION.
Based on paragraphs 4.4.3.1 and 4.4.3.5, a status word response is required if the RT receives a command that is a valid command and if any associated data reception is a valid data reception. Paragraph 4.4.3.3 specifically states that a RT shall not respond to an INVALID COMMAND and paragraph 4.4.3.6 requires the status word response be suppressed for the case of INVALID DATA RECEPTION.
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 5
Notice that there is no restriction on a bus controller not to transmit a RESERVED mode code command. RESERVED mode commands may be defined in the future, in which case receipt of that command would be an absolutely normal occurrence. Simply treating the RESERVED mode commands as an ILLEGAL COMMAND is consistent with the potential for future expansion of mode commands since a pre-existing RT design should not implement the new command created from a RESERVED mode command. The “RT Validation Test Plan” (Notice 1 to MIL-HDBK-1553) supports this discussion.
The UNDEFINED mode code commands present a more difficult situation. If an RT receives an undefined mode command, by default it could treat this command as an ILLEGAL COMMAND from the standpoint of it’s being a combination of T/R, subaddress/mode, and data word/mode code fields that definitely will not have been implemented by the RT design. But the undefined mode command can be regarded as an ILLEGAL COMMAND only if it is also a valid command. This point raises questions as to how such a command came to be received by the RT. Since the undefined mode command is not a valid combination of T/R, subaddress/mode field, and data word/mode code field as defined in table 1 of 1553B, it must be presumed that a bus controller would never purposely send such a combination. The case can be made that some failure mode has to have occurred in order for the command received by the RT to be interpreted as an undefined mode command. Invalid encoding, undetected multiple bit errors, or bus controller failures could be possible sources for the erroneous mode command. It may be surmised that the receipt of an undefined mode command implies that the command could be an INVALID COMMAND. It is also possible that all of the checks for validity of the command word genuinely pass, but that a failure mode in the bus controller has resulted in the transmission of an undefined mode command. As such, it would be proper to regard the command as an ILLEGAL COMMAND and to set the ME bit of the status word register and either transmit or suppress the status word depending on the implementation of the ILLEGAL COMMAND option.
The validity of the command determines whether or not a status response is to be sent. Due to the likelihood that the undefined command is in reality an INVALID COMMAND generated by undetected errors in encoding, the safest approach to the decision concerning whether or not to transmit the status word would be to suppress transmission of the status word.
So, depending upon the failure mode that produces an undefined mode command, attributes of either an ILLEGAL COMMAND or an INVALID COMMAND or both may be present. The required response is not clear since the prescribed responses are opposing when comparing an ILLEGAL COMMAND with an INVALID COMMAND. For this reason, this category of command is sometimes referred to an illogical command. By implementing the dominant responses for both an ILLEGAL COMMAND and for an INVALID COMMAND, the safest overall response results. The ME bit of the status word is set to indicate an error and the transmission of the status word is suppressed to prevent violation of the command/response protocol for a potentially INVALID COMMAND. Suppression of the transmission of the status word in response to the receipt of an undefined/illogical command has the added benefit of distinguishing the associated failure mode from the receipt of a reserved mode command. In any event, diagnosability of errors resulting from the receipt of an improper mode command can be improved by providing bits in the BIT word to expand the encoding of errors.
The “RT Validation Plan” allows two responses; a) treat the condition as an ILLEGAL COMMAND, or b) treat the condition as an INVALID COMMAND. In the first case, the terminal would respond with a status word with no errors set if it did not have ILLEGAL COMMAND detection capability. If the terminal did have ILLEGAL COMMAND detection capability, a status word with the ME bit set would be transmitted only. In the second case, if the INVALID COMMAND was detected, the status response would be suppressed and the ME bit set in the status word. This message error would NOT be recorded by the bus controller unless the next message was a transmit status word mode code or transmit last command word mode code.
1.6.7 Two Single-Channel Remote Terminal Operating in a Dual Standby Redundant System
A few remote terminal designers have designed subsystems using the channel concept (see figure I-3.7 right side) only to discover that the terminal failed to meet all the 1553B requirements when used in a dual standby redundant data bus network (see 1553B paragraph 4.6.3). 1553B provides certain general capabilities, which are influenced when a system is operating in a dual standby redundant network, as most are, compared to a single channel network. Mode codes that convey the operational capability of the entire remote terminal as compared to that of the channel are the most affected; a)transmit status word, b)reset remote terminal, c) transmit last command word, and d) transmit BIT word. Transmit status word mode code provides the message error results of the last message processed by the terminal regardless of which bus (channel—active or standby) the message was received on. The other bits in the status word represent the health of the entire terminal, not just the channel receiving the request. The reset remote terminal mode code also applies to the entire terminal and NOT just the channel the request was received on. Transmit last command word must come from a register, which contains the 16 bit contents of the last command received regardless of the bus received on. The same is true for the terminal’s BIT word and vector word, it must reflect the terminal’s state and not that of channel. Figure I-3.7 illustrates that too little redundancy is unacceptable just as well as to much isolation is unacceptable.
1.6.8 Testing of 1553 Terminals
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.
To this end, the SAE Avionics Systems Division and the government began developing a series of verification and production test plans and procedures, which could be conducted by independent laboratories to validate the design approach and provide a basis for production level testing of 1553 terminals. This approach would allow multiple industry sources to be used to verify compliance of a design and provide industry with ground rules for production testing. It was clear from the beginning that remote terminal test plans were required first, followed by bus controller test plans and then system data bus test plans. The initial remote terminal test plans grew out of the test procedures developed and used at SEAFAC. It was obvious from the start that the test plans would set a lower level of definition for “acceptable terminal performance” than existed in the standard. This caused extensive work and coordination between industry and the government. Today (7/87) these test plans are available in preliminary form from the SAE (Society of Automotive Engineering) under the following Aerospace Standard numbers:
1.6 The Most Frequently Asked Questions Concerning MIL-STD-1553 - Part 6
| AS4111 Rev. D 3/84 |
Validation Test Plan for Aircraft Internal Time Division Command/Response Multiplex Data Bus Remote Terminals. (see Section VI). |
| AS4112 Rev. 4/85 |
Production Test Plan for Aircraft Internal Time Division Command/Response Multiplex Data Bus Remote Terminals (see Section V). |
| AS4113 Rev. F 3/86 |
Validation Test Plan for Aircraft Internal Time Division Command/Response Multiplex Data Bus Bus Controllers. |
| AS4114 Final Draft 2/87 |
Production Test Plan for Aircraft Internal Time Division Command/Response Multiplex Data Bus Bus Controllers. |
| AS4115 Final Draft 2/87 |
Test Plan for the Digital Internal Time Division Command/Response Multiplex Data Bus System. |
Note that the Validation Test Plan for Remote Terminals (AS4111) has been adapted by the military and released as Notice 1 to MIL-HDBK-1553 Multiplex Applications Handbook.
In the near future, these documents will be approved by the SAE and published as Aerospace Standards. The military is considering placing some of these in future updates of MIL-HDBK-1553 Handbook. Some differences still exist between the SEAFAC test plans and procedures and the SAE documents, which must be resolved. In addition, with the release of Notice 2 to MIL-STD-1553B these documents will be updated by the SAE.