5.0 Detail Requirements (Not Applicable)

The following paragraphs in this appendix are presented in order to discuss certain aspects of the standard in a general sense. They are intended to provide a user of the standard more insight into the aspects discussed.

It is intended that this standard be used to support rather than to supplant the system design process. However, it has been found, through application experience in various aircraft, that the use of a dual standby redundancy technique is very desirable for use in integrating mission avionics. For this reason, this redundancy scheme is defined in 4.6 of this standard. Nonetheless, the system designer should utilize this standard as the needs of a particular application dictate. The use of redundancy, the degree to which it is implemented, and the form which it takes must be determined on an individual application basis.

Figures II-5.1 and II-5.2 illustrate some possible approaches to dual redundancy. These illustrations are not intended to be inclusive, but rather representative. It should be noted that analogous approaches exist for the triple and quad redundant cases.

The bus controller is a key part of the data bus system. The functions of the bus controller, in addition to the issuance of commands, must include the constant monitoring of the data bus and the traffic on the bus. It is envisioned that most of the routine minute details of bus monitoring (e.g., parity checking, terminal non-response time-out, etc.) will be embodied in hardware, while the algorithms for bus control and decision making will reside in software. It is also envisioned that, in general, the bus controller will be a general purpose airborne computer with a special input/output (I/O) to interface with the data bus. It is of extreme importance in bus controller design that the bus controller be readily able to accommodate terminals of differing protocols and status word bits used. Equipment designed to MIL-STD-1553A will be in use for a considerable period of time; thus bus controllers must be capable of adjusting to their differing needs. It is also important to remember that the bus controller will be the focal point for modification and growth within the multiplex system, thus the software must be written in such a manner as to permit modification with relative ease.

The selection of candidate signals for multiplexing is a function of the particular application involved, and criteria will in general vary from system to system Obviously, those signals which have bandwidths of 400 Hz or less are prime candidates for inclusion on the bus. It is also obvious that video, audio, and high speed parallel digital signals should be excluded. The area of questionable application is usually between 400 Hz and 3 kHz bandwidth. The transfer of these signals on the data bus will depend heavily upon the loading of the bus in a particular application. The decision must be based on projected future bus needs as well as the current loading. Another class of signals which in general are not suitable for multiplexing are those which can be typified by a low rate (over a mission) but possessing a high priority or urgency. Examples of such signals might be a nuclear event detector output or a missile launch alarm from a warning receiver. Such signals are usually better left hardwired, but they may be accommodated by the multiplex system if a direct connection to the bus controller’s interrupt hardware is used to trigger a software action in response to the signal.

The use of simple parity for error detection within the multiplex bus system was dictated by a compromise between the need for reliable data transmission, system overhead, and remote terminal simplicity. Theoretical and empirical evidence indicated that an undetected bit error rate of 10 can be expected from a practical multiplex system built to this standard. If a particular signal requires a bit error rate which is better than that provided by the parity checking, then it is incumbent upon the system designer to provide the reliability within the constraints of the standard or to not include this signal within the multiplex bus system. A possible approach in this case would be to have the signal source and sink provide appropriate error detection and correction encoding/decoding and employ extra data words to transfer the information. Another approach would be to partition the message transmit a portion at a time, and then verify (by interrogation) the proper transfer of each segment.

Stubbing is the method wherein a separate line is connected between the primary data bus line and a terminal. The direct connection of stub line causes a mismatch which appears on the waveforms. This mismatch can be reduced by filtering at the receiver and by using biphase modulation. Stubs are often employed not only as a convenience in bus layout but as a means of coupling a unit to the line in such a manner that a fault on the stub or terminal will not greatly affect the transmission line operation. In this case, a network is employed in the stub line to provide isolation from the fault. These networks are also used for stubs that are of such length that the mismatch and reflection degrades bus operation. The preferred method of stubbing is to use transformer coupled stubs, as defined in 4.5.1.5.1. This method provides the benefits of DC isolation, increased common mode protection, a doubling of effective stub impedance, and fault isolation for the entire stub and terminal. Direct coupled stubs, as defined in 4.5.1.5.2 of this standard, should be avoided if at all possible. Direct coupled stubs provide no DC isolation or common mode rejection for the terminal external to its subsystem. Further, any shorting fault between the subsystems internal isolation resistors (usually on a circuit board) and the main bus junction will cause failure of that entire bus. It can be expected that when the direct coupled stub length exceeds 1.6 feet, that it will begin to distort the main bus waveforms. Note that this length includes the cable runs internal to a given subsystem.

The use of a broadcast message as defined in 4.3.3.6.7 of this standard represents a significant departure from the basic philosophy of this standard in that it is a message format which does not provide positive closed-loop control of bus traffic. The system designer is strongly encouraged to solve any design problems through the use of the three basic message formats without resorting to use of the broadcast. If system designers do choose to use the broadcast command, they should carefully consider the potential effects of a missed broadcast message, and the subsequent implications for fault or error recovery design in the remote terminals and bus controllers.