SECURE IVlfL-STD-1553 DATA BUS

BACKGROUND

[0001] MIL-STD-1553 is a military standard published by the United States Department of Defense that defines the mechanical, electrical, and functional characteristics of a serial data bus. It was originally designed for use with military avionics but has also become commonly used in spacecraft on-board data handling (OBDH) subsystems, both military and civil. It features a dual redundant balanced line physical layer, a (differential) network interface, time division multiplexing, half-duplex command/response protocol, and up to 31 remote terminals (devices).

[0002] Since its inception in 1973 and in subsequent revisions during the ensuing years, MIL-STD-1553 has evolved into the predominant, internationally accepted networking standard for the integration of military platforms. Today, the standard has expanded beyond its traditional domain of US Air Force and Navy aircraft to encompass applications for combat vehicles, ships, satellites, missiles, and the International Space Station Program, as well as advanced commercial avionic applications. Once considered primarily a military data bus standard, MIL-STD-1553 has caught the attention of commercial aircraft manufacturers who seek to capitalize upon the standard's inherent reliability, robustness, maturity, and superior EMI performance.

[0003] The current version of MIL-STD-1553 is MIL-STD-1553B, which is attached hereto and made a part hereof as Appendix A, and is fully incorporated by reference, though as used herein the term "MIL-STD-1553" means either MIL-STD-1553A, MIL-STD-1553, or any future release/upgrade of the standard. [0004] MIL-STD-1553 has a long history going back to the 1970s, and it remains very active today even in new systems, MIL-STD-1553 is deterministic and dual-redundant, thus making it highly fault tolerant and suitable for use in mission-critical systems. MIL-STD-1553 will likely be a part of military platforms for many years to come,

[0005] However, MIL-STD-1553 was developed before cyber security became a concern. MIL-STD-1553 has no inherent security features built into the protocol itself, and thus has significant vulnerabilities. In complex modern systems, with many MIL-STD-1553 terminals being part of intelligent and interconnected subsystems, security has become a growing concern.

[0006] Potential threats on MIL-STD-1553 data buses include, for example, the following basic threats and how they would appear relative to the 1553 bus: (1) compromised bus controller (BC) software; for example, the BC is re-programmed to send malicious commands or sequence of commands and/or data; (2) compromised remote terminal (RT) software; for example, the RT is re-programmed as a malicious BC; (3) compromised RT software; for example, the RT is re-programmed to transmit incorrect/corrupted data; (4) a second (false) BC sending malicious commands or sequence of commands and/or data; (5) a terminal (generally configured as a BC) can create traffic to cause collisions, resulting in a denia!-of-service type of attack; (6) a malicious BC connected to maintenance port; (7) and the like. These are only examples. There is almost no limit to the types of theoretical attacks which one could imagine, but many are impractical or inapplicable to the vast majority of systems. For example, some have suggested that attacks could take the form of a slight altering of the timing of either BC messages and/or RT response time to slowly and indirectly “leak” sensitive or classified data. This type of attack would require at least two terminals to be compromised and participating in the attack, as well as the ability to both control and detect the subtle timing differences. [0007] Previously proposed MIL-STD-1553 security concepts include blocking / filtering of command words and possibly also data words. In some instances, security may be required to be incorporated into individual terminals. Also in some instances, security may be specific to the configuration of the network.

[0008] Therefore, what is needed are systems and methods for providing security for data buses utilizing MIL-STD-1553 that overcome challenges in the art, some of which are described above. In particular, an approach that provides simple, reliable, easy-to-integrate security for MIL-STD-1553 communication buses is desired that focus on the message content itself and preventing unauthorized messages from completing successfully.

SUMMARY

[0009] Disclosed and described herein are embodiments of a bus security device that provides security on a MIL-STD-1553 serial data bus. In one aspect the device comprises a memory, wherein the memory at least contains security rules stored thereon; a processing circuit in communication with the memory; and a transceiver that connects the bus security device to the MIL-STD-1553 serial data bus. The processing circuit is programmed to monitor the MIL-STD- 1553 serial data bus in accordance with the security rules stored in the memory; and if the processing circuit detects an anomaly on the serial data bus that is characterized as a threat by the rules stored in the memory, then the processing circuit causes the transceiver to inject an invalidation signal onto the data bus to counteract the anomaly.

[0010] in some instances, the memory of the device comprises non-volatile memory. For example, the memory may comprise flash memory.

[0011] in some instances, the security rules are stored on the memory using hardware description language (HDL) or a lookup table. [0012] in various instances, the memory may be integrated into the processing circuit, or it may be separate from the processing circuit.

[0013] in various instances, the processing circuit of the device may comprise a field- programmable gate array (FPGA), a processor or microprocessor, an application-specific 1C (ASIC), and the like.

[0014] in various instances, the transceiver of the device connects the security device to the MiL-STD-1553 serial data bus by a transformer or directly.

[0015] In various instances, the anomaly comprises a message on the MiL-STD-1553 serial data bus that is characterized as a threat. For example, the message on the MiL-STD-1553 serial data bus may be characterized as a threat based on content of the message.

[0018] in various instances of the device, the invalidation signal comprises a relatively short transmission burst injected onto the data bus that creates a collision with either a data or status word transmission and causes the message identified as a threat to be invalidated. Generally, the invalidation signal is at a higher frequency than normal traffic on the MIL-STD- 1553 serial data bus. For example, the Invalidation signal may be at or above the maximum level specified in MiL-STD-1553 to ensure the message is invalidated by corrupting Manchester encoding or sync encoding of the message.

[0017] in some instances, the device may further comprise an indicator that provides an indication that an anomaly has been detected. For example, the indication may be in the form of an electronic signal, and/or audible or visible indicators, and the like.

[0018] in various instances, the device may be a stand-alone device connected to the

MIL-STD-1553 serial data bus, while in other instances the device may be integrated into a bus controller (BC). For example, the device may be integrated into an unsecure BC, or it may be integrated into a secure BC.

[0019] in various instances, the device may provide security against false BC attacks caused by a second false BC generating traffic on the serial data bus. In some instances, the device further comprises a transmit detect device to detect a transmission in a stub of the serial data bus that connects the BC to the serial data bus.

[0020] In some instances, the device detects a transmission by the BC. For example, the device may detect BC command transmission by both monitoring the serial data bus and by detecting current in the stub of the serial data bus. Any detected transmission determined to not be initiated by the BC is invalidated by the device.

[0021] in some instances, the BC into which the device is integrated may comprise a fixed silicon BC protocol sequencer and/or a BC that cannot be modified. For example, the BC may be a secure BC. In such instances, the device detects a command word transmission in the serial data bus or in a stub of the serial data bus that connects the BC to the serial data bus and determines whether the command word transmission was initiated by the BC or not by the BC. For example, the device may determine whether the command was initiated by the BC either by direct integration with a BC sequencer in the processing circuit, or by detection of a command word transmission by detecting current in the stub of the serial data bus. if the device determines the command word transmission was not initiated by the BC, then it determines that the command word transmission was initiated by a false BC, and the device invalidates the command word transmission initiated by the false BC.

[0022] Also disclosed and described herein are methods of providing security on a MIL-

STD-1553 serial data bus. In one aspect, the method comprises monitoring the MIL-STD-1553 serial data bus in accordance with security rules; and in response to detecting an anomaly on the serial data bus that is characterized as a threat by the security rules, then the injecting an invalidation signal onto the data bus to counteract the anomaly. For example, the message on the M!L-STD-1553 serial data bus may be characterized as a threat based on content of the message.

[0023] in some instances of the method, the invalidation signal comprises a relatively short transmission burst injected onto the data bus that creates a collision with either a data or status word transmission and causes the message identified as a threat to be invalidated. The invalidation signal may be at a higher frequency than normal traffic on the MIL- STD-1553 serial data bus. For example, the invalidation signal may be at or above the maximum level specified in MIL- STD -1553 to ensure the message is invalidated by corrupting Manchester encoding or sync encoding of the message,

[0024] In some instances, the method further comprises providing an indicator that provides an indication that the anomaly has been detected. For example, the indication may be in the form of an electronic signal, and/or audible or visible indicators, and the like.

[0025] in various instances, the method may be performed by a device that is a standalone device connected to the MIL-STD-1553 serial data bus. In some instances, the method may be performed by a device that is integrated into a bus controller (BC). The BC may be a secure BC or an unsecure BC.

[0026] In instances where the BC is an unsecure BC, the method provides security against false BC attacks caused by a second false BC generating traffic on the serial data bus. For example, the device may further comprise a transmit detect device to detect a transmission in a stub of the serial data bus that connects the BC to the serial data bus, in such instances, the method comprises the device detecting a transmission by the BC. in some instances of the method, the device detects BC command transmission by both monitoring the serial data bus and by detecting current in the stub of the serial data bus. in such instances, the method comprises invalidating any detected transmission determined to not be initiated by the BC.

[0027] in some instances of the method where the BC comprises a fixed siiicon BC protocol sequencer and/or a BC that cannot be modified, the BC is considered a secure BC, and the method comprises the device detecting a command word transmission in the serial data bus or in a stub of the serial data bus that connects the BC to the serial data bus and determining whether the command word transmission was initiated by the BC or not by the BC. In such instances, the method may comprise determining whether the command was initiated by the BC either by direct integration with a BC sequencer in a processing circuit of the device, or by detection of a command word transmission by detecting current in the stub of the serial data bus. In such instances of the method, if the device determines the command word transmission was not initiated by the BC, then it determines that the command word transmission was initiated by a false BC and the method comprises the device invalidating the command word transmission initiated by the false BC.

[0028] It should be understood that the above-described subject matter may also be implemented as a computer-controlled apparatus, a computer process, a computing system, or an article of manufacture, such as a computer-readable storage medium.

[0029] Other systems, methods, features and/or advantages will be or may become apparent to one with skill in the art upon examination of the following drawings and detailed description, it is intended that all such additional systems, methods, features and/or advantages be included within this description and be protected by the accompanying claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] The components in the drawings are not necessarily to scale relative to each other. Like reference numerals designate corresponding parts throughout the several views.

[0031] FIG. 1A is an illustration of a MIL-STD-1553 data bus that includes a stand-alone bus security device.

[0032] FIG. IB is a flowchart illustrating a method of securing a MIL-STD-1553 data bus using a stand-alone security device such as the one described in reference to FIG. 1A.

[0033] FIG. 2A illustrates another embodiment of a security device for providing security to a MIL-STD-1553 data bus where the security device is integrated with an unsecured bus controller (BC) to secure against false BC attacks.

[0034] FIG. 2B is an illustration of a security device integrated with a secure BC to secure against false BC attacks.

[0035] FIG. 2C illustrates a flowchart for a method of securing a MIL-STD-1553 data bus using the implementations of a security device as shown in FIGS. 2A and 2B.

[0036] FIG. 3 is an example computing device.

[0037] FIG. 4 is an exemplary setup for demonstrating securing a MIL-STD-1553 data bus using the implementations described herein.

[0038] FIGS. 5A-5G show examples of timing diagrams showing messages with and without invalidation.

DETAILED DESCRIPTION

[0039] Before the present methods and systems are disclosed and described, it is to be understood that the methods and systems are not limited to specific synthetic methods, specific components, or to particular compositions. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting.

[0040] As used in the specification and the appended claims, the singular forms "a," "an" and "the" include plural referents unless the context dearly dictates otherwise. Ranges may be expressed herein as from "about" one particular value, and/or to "about" another particular value. When such a range is expressed, another embodiment includes from the one particular value and/or to the other particular value. Similarly, when values are expressed as approximations, by use of the antecedent "about," it will be understood that the particular value forms another embodiment. It will be further understood that the endpoints of each of the ranges are significant both in relation to the other endpoint, and independently of the other endpoint.

[0041] "Optional" or "optionally" means that the subsequently described event or circumstance may or may not occur, and that the description includes instances where said event or circumstance occurs and instances where it does not.

[0042] Throughout the description and claims of this specification, the word "comprise" and variations of the word, such as "comprising" and "comprises," means "including but not limited to," and is not intended to exclude, for example, other additives, components, integers, or steps. "Exemplary" means "an example of" and is not intended to convey an indication of a preferred or ideal embodiment. "Such as" is not used in a restrictive sense, but for explanatory purposes.

[0043] Disclosed are components that can be used to perform the disclosed methods and systems. These and other components are disclosed herein, and it is understood that when combinations, subsets, interactions, groups, etc. of these components are disclosed that while specific reference of each various individual and collective combinations and permutation of these may not be explicitly disclosed, each is specifically contemplated and described herein, for all methods and systems. This applies to all aspects of this application including, but not limited to, steps in disclosed methods. Thus, if there are a variety of additional steps that can be performed it is understood that each of these additional steps can be performed with any specific embodiment or combination of embodiments of the disclosed methods.

[0044] As will be appreciated by one skilled in the art, the methods and systems may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the methods and systems may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. More particularly, the present methods and systems may take the form of web- implemented computer software. Any suitable computer-readable storage medium may be utilized including bard disks, CD-ROMs, optical storage devices, or magnetic storage devices.

[0045] Embodiments of the methods and systems are described below with reference to block diagrams and flowchart illustrations of methods, systems, apparatuses, and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be Implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.

[0046] These computer program instructions may also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.

[0047] Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions, it will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.

[0048] The present methods and systems may be understood more readily by reference to the following detailed description of preferred embodiments and the Examples included therein and to the Figures and their previous and following description. [0049] Some of the components that comprise a MIL-STD-1553 communication bus include the bus controller (BC), the embedded remote terminal (a sensor or subsystem that provides its own Internal 1553 interface), the stand-alone remote terminal (RT is used herein to refer to either the embedded remote terminal or the stand-alone remote terminal), and the bus monitor (BM). Generally, the data bus comprises twisted shielded pair wire data bus and may include optional isolation couplers. The bus controller's 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 comprises interface circuitry located inside a sensor or subsystem directly connected to the data bus. It performs 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).

[0050] 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 onboard 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. [0051] Regarding the data bus, the standard defines specific characteristics for the twisted pair shielded cable. Notice 2 of the standard tightens these requirements and adds a definition for connector polarity.

[0052] The data bus coupler unit isolates the main bus from the terminals. MIL-STD- 1553B allows two types of data bus interface techniques; direct coupling and transformer coupling, it is to be appreciate that while the figures herein typically illustrate transformer coupling, that direct coupling may also be used and is contemplated within the scope of the claims. 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 seiection of the vaiue 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. 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. [0053] Disclosed and described herein are security mechanisms that use simultaneous transmission on the data bus to invalidate a message which is considered a threat. A relatively short transmission burst injected onto the bus is designed to create a collision with either data or status word transmission and causes the message to be invalidated. This technique can effectively invalidate almost all MIL-STD-1553 message types. The invalidation signal is optimized to interfere with and invalidate the word immediately following the detection of the threat. This signal may be at a higher frequency than normal 1553 traffic. The transmit level of the invalidation signal is at or above the maximum level specified in MIL-STD-1553 to ensure the message is invalidated by corrupting the Manchester encoding or sync encoding. The disclosed embodiments are easily integrated into existing systems, requiring no modifications to existing legacy terminals (BCs, RTs, BMs) on the bus. The security architecture is open, predictable, and fully defined. The response of the security device to threats is based on strict pre-defined rules. The security rules can be programmed in at least two different ways: hard-coded in hardware description language (HDL), or loaded into FPGA lookup table from non-volatile memory. The security architecture can neutralize a large number of potential threats on a MIL-STD-1553 bus with unsecured legacy RTs and/or BC. The security mechanism does not interfere at all with normal bus traffic, but remains entirely passive. The security mechanism can be implemented in existing FPGA-based hardware platforms. The security mechanism can be integrated with third party security algorithms. The disclosed embodiments secure the entire bus (all terminals) by monitoring message traffic. Embodiments may be implemented as a standalone device, or can be integrated with a bus controller to prevent all other terminals from initiating messages. In some instances, embodiments of the security device give an indication of the presence of abnormal activity or threats that have been detected. Can be used in at least two different use cases: in some instances, embodiments may be implements as a completely independent security agent which polices the bus for unacceptable messages and when It detects them it invalidates them. Optionally and/or additionally, embodiments can be used in conjunction with a secure or unsecure bus controller to invalidate all messages not originated by the bus controller.

[0054] FIG. 1A is an illustration of a MIL-STD-1553 data bus 100 that includes a stand- alone bus security device 102. As shown in FIG. 1A, this example of a bus security device 102 comprises a memory 104 that is in communication with a processing circuit 106 (e.g., a processor, a field-programmable gate array (FPGA), an ASIC, and the like). An FPGA is a device used in electronic circuits. An FPGA is a semiconductor device inciuding programmable logic blocks and interconnects. An FPGA is capable of being programmed after manufacture, for example, using a hardware description language (HDL). FPGAs are known in the art and therefore not described in further detail here. Alternatively, in other implementations, the processing circuit 106 may include an application-specific 1C (ASIC). An ASIC is a customized 1C chip. Unlike an FPGA, an ASIC is not capable of being programmed after manufacture. ASICs are known in the art and therefore not described in further detail here. In some instances, the memory 104 may be integrated into a comprise a part of the processing circuit 106. in some instances the memory 104 may be flash memory. The processing circuit 106 monitors the data bus 100 in accordance with security rules stored in the memory 104. For example, the security rules may be hard-coded in HDL, or loaded into FPGA lookup table from non-volatile memory. The processing circuit 106 uses a transceiver 108 to monitor the data bus 100. The transceiver 108 may be connected to the data bus 100 by a transformer, or directly, as described herein, if the processing circuit 106 detects an anomaly

(e.g., an event (e.g., message) on the data bus 100 that is characterized as a threat by the rules stored in the memory 104), then the processing circuit 106 causes the transceiver 108 to inject an invalidation signal onto the data bus 100 to counteract the anomaly. The processing circuit 106 causes a relatively short transmission burst to be injected onto the data bus 100 that is designed to create a collision with either data or status word transmission and causes the message identified as a threat to be invalidated. The invalidation signal is optimized to interfere with and invalidate the word immediately following the detection of the threat. This signal may be at a higher frequency than normal 1553 traffic. The transmit level of the invalidation signal is at or above the maximum level specified in MIL-STD-1553 to ensure the message is invalidated by corrupting the Manchester encoding or sync encoding. The anomaly is identified, using the security rules, based on message content, in some instances, the stand-alone security device may provide an indication 114 that a anomaly has been detected. This indication 114 may be in the form of an electronic signal, and/or audible or visible indicators.

[0055] The stand-alone security device 102 secures the entire bus (all terminals) 100, and requires no changes to the system. A typical use case for the stand-alone security device 102 of FIG. 1A might be for securing a MIL-STD-1553 maintenance port.

[0056] Allowed messages and threats must be pre-determined and completely defined in terms of command word, and possibly also in terms of data words if out-of-bounds data constitutes a legitimate threat. These definitions are stored in the memory 104 in the form of security rules. Existing bus traffic without anomalies can potentially be analyzed to help determine the set of allowed messages. The security device 102 transmits at full MIL-STD-1553 power levels to ensure that the invalidation signal reliably corrupts the threat message.

[0057] FIG. IB is a flowchart illustrating a method of securing a MIL-STD-1553 data bus using a stand-alone security device such as the one described in reference to FIG. I.A. At 120, the security device monitors aii messages transmitted on the data bus. At 122, the security device detects an anomaly on the data bus. For example, the anomaly may comprise a non-allowed command word. Optionally, the anomaly may comprise an out-of-bounds data word. At 124, the security device outputs an invalidation signal onto the data bus in response to the detected anomaly. The invalidation signal comprises a transmission burst that interferes with normal 1553 transmission. The invalidation signal results in a collision and corrupts either the data word or status word transmission of the non-ailowed message and prevents successful message completion. After the invalidation signal has been transmitted, the security device will continue monitoring traffic on the bus. if the data bus is a dual-redundant 1553 channel, then an independent security circuit services each bus of the dual-redundant 1553 channel. In some instances, the security device also generates a signal indicating that a threat was detected and the bus may be compromised.

[0058] Using the security device shown and described in FIGS. 1A and IB, the security method is able to secure the entire bus based on message content only, it makes no distinction regarding which physical terminal may be participating in message traffic. This also implies that threats can only be defined in terms of message content, but cannot be defined based on command/data source or destination. The security device may be coupled to the bus in any location and can be either direct or transformer-coupled. When power to the security device is removed or the security device is disabled, the security function is disabled and the bus operates normally. This is a desirable feature.

[0059] The special case of broadcast mode commands without a data word, and by extension all broadcast commands, require special consideration to invalidated. There are seven of these broadcast mode commands without data defined by 1553. The nature of these commands is such that an unauthorized execution might alter the state of RTs in an undesirable way, but it would likely not pose a specific threat to any particular RT. If broadcast mode commands are not supported by RTs in a system, then this problem generally disappears. The Air Force strongly discourages the use of ANY broadcast commands in their systems because it eliminates the command-response handshake which contributes to the robustness of MIL-STD- 1553. Broadcast commands without data require the invalidating transmission to begin during the transmission time of the command word. This means that the security device cannot wait to receive the whole command word before making the decision to invalidate. Therefore, to work reliably, the security device would need to make the decision to invalidate as soon as it was determined that the command was a broadcast command. This means that ALL broadcast commands would not be allowed if any broadcast commands without data were to be invalidated. The following is a list of these commands: Synchronize; Initiate Self-Test; Transmitter Shutdown; Override Transmitter Shutdown; Inhibit Terminal Flag Bit; Override Inhibit Terminal Flag Bit; and Reset Remote Terminal.

[0060] Uses of the security device and method disclosed in relation to FIGS. 1A and IB include adding security to a M!L-STD-1553 maintenance port where the threat might come from a maintenance computer with compromised software which attempts to generate message traffic inappropriate during maintenance. In another use, the security method may also be appropriate for securing an otherwise unsecured operational bus where the threat might come from a terminal generating message traffic that is inappropriate during normal operation (for example, running maintenance type traffic during normal operation).

[0061] FIG. 2A illustrates another embodiment of a security device for providing security to a MIL-STD-1553 data bus where the security device is integrated with an unsecured bus controller (BC) to secure against false BC attacks. It is to be noted that this use case adds additional security against a second false BC generating traffic. In this implementation, the entire bus (ail terminals) is secured based on message content alone. Furthermore, this implementation requires no changes to the BC or RTs in the system. It detects BC command transmission by both monitoring the bus and by detecting current in the BCs stub. If a MIL-STD- 1553 system contained redundant/multiple BCs, only one BC could be active at any given time and the active/inactive status of the BC would need to be reported to the security device. A typical use case for this implementation would be for securing a MIL-STD-1553 bus which contains a bus controller that uses a fixed silicon BC protocol sequencer or any other BC which cannot be modified.

[0062] As shown in FIG. 2A, this example of a bus security device 202 comprises a memory 204 that is in communication with a processing circuit 206 (e.g., a processor, a field- programmable gate array (FPGA), and the like). In some instances, the memory 204 may be integrated into a comprise a part of the processing circuit 206. In some instances the memory 204 may be flash memory. The processing circuit 206 monitors the data bus 100 in accordance with security rules stored in the memory 204. For example, the security rules may be bard-coded in HDL, or loaded into FPGA lookup table from non-volatile memory. The processing circuit 206 uses a transmit detect device 208 to detect a transmission by the bus controller 210. The device 202 is further connected to the data bus 100 using a transceiver 212 connected to the data bus 100. The transceiver 212 may be connected to the data bus 100 by a transformer, or directly, as described herein. If the processing circuit 206 detects an anomaly (e.g., an event (e.g., message) transmitted by the BC 210 that is characterized as a threat by the rules stored in the memory

204. then the processing circuit 206 causes the transceiver 212 to inject an invalidation signal onto the data bus 100 to counteract the anomaly. The processing circuit 206 causes a relatively short transmission burst to be injected onto the data bus 100 that is designed to create a collision with either data or status word transmission and causes the message identified as a threat to be invalidated. The invalidation signal is optimized to interfere with and invalidate the word immediately following the detection of the threat. This signal may be at a higher frequency than normal 1553 traffic. The transmit level of the invalidation signal is at or above the maximum level specified in MIL-5TD-1553 to ensure the message is invalidated by corrupting the Manchester encoding or sync encoding. The anomaly Is identified, using the security rules, based on message content. The security device 202 may also provide an indication 214 that a threat has been detected.

[0063] FIG. 2B is an illustration of a security device integrated with a secure BC to secure against false BC attacks. It is to be noted that this use case adds additional security against a second false BC generating traffic. This implementation secures the entire bus (all terminals) based on message content alone, and requires no changes to the RTs in the system, if a MIL- STD-1553 system contains redundant/muitiple BCs, only one BC could be active at any given time and the active/inactive status of the BC would need to be reported to the security device.

[0064] FIG. 2B illustrates integration of a security device with a secure bus controlier. As shown in FIG. 2B, the processing circuit 206 interfaces with host 216, and provides BC sequencing, hardware command filtering and invalidates all messages from any additional (i.e., second) BC. In this implementation, the security device determines which commands were initiated by the true bus controller, either by direct integration with the BC sequencer in the same

FPGA, or by detection of command word transmission via current in the bus stub. The security device must be able to transmit at full MIL-STD-1553 power levels to ensure that the invalidation signal reliably overcomes the threat message.

[0065] FIG. 2C illustrates a flowchart for a method of securing a MIL-STD-1553 data bus using the implementations of a security device as shown in FIGS. 2A and 2B. As shown in FIG. 2.C, at 220, the security device detects when the BC is actively transmitting a command word. At 222, it is determined if an external device (i.e,, not the BC) transmits a command word, if, at 222, it is determined that an external device transmitted the command word, then the message will be invalidated at 224. In other words, when bus activity is detected during a period when the BC is NOT actively transacting a message, the security device outputs an invalidation signal on the same bus in which the activity was detected. The invalidation signal is comprised of a transmission burst which is an injection of a non-standard AC signal which interferes with normal 1553 transmission during data word or status word transmission time. The invalidation signal causes a collision and corrupts the attempted message from the false BC. If, at 222, it is determined that the command word was transmitted by the BC (not by an external device), then the process returns to 220 and continues to monitor for a command word. At 224, after the invalidation signal has been transmitted, the security device will return to 22.0 and continue looking for spurious commands and activity on the bus. An independent security circuit services each bus on a dual-redundant 1553 channel. The security device may optionally generate a signal indicating that a threat was detected and the bus may be compromised.

[0066] in the implementations shown in FIGS. 2A-2C, external threats do not need to be defined; all messages originated from a source other than the BC in which the security device is integrated are invalidated, internal threats from the BC itself can still be neutralized, either by hardware filtering in the secure BC, or by simultaneous transmission when used with an unsecured BC. Use cases of the implementations shown in FIGS. 2A-2C include adding security to a MIL-STD-1553 bus where the threat might come from a false bus controller generating otherwise acceptable message traffic. This security method, when integrated with a secure bus controller, provides the most complete security, which includes detecting and neutralizing the following threats: illegal commands generated from the BC itself (because the BC is secured); all messages generated by a second false BC; and, if data word checking is used, it can also prevent out-of-bounds data from RTs from successfully transferring.

[0067] In summary, the above-disclosed implementations of a device and methods for securing a MIL-STD-1553 bus requires no modifications to existing legacy terminals (BCs, RTs, BMs) on the bus; can be easily integrated into existing systems as a standalone device; the implementation of the security device are small and require littie power; does not interfere with normal traffic, and remains entirely passive (in monitor mode); secures the entire bus; the security architecture is open, predictable, and fully defined. The response of the security device to threats could be based on strict pre-defined rules; can neutralize most potential threats on a MiL-STD-1553 bus which has potentially unsecured legacy RT and/or BC terminals; security mechanism can be integrated into existing FPGA-based hardware platforms; can be Integrated with a bus controller to prevent a non-authorized (another) BC from generating AMY commands, even otherwise legal ones; and can take advantage of machine-learning techniques to automate the creation of security rules.

[0068] Example Computing Device

[0069] Referring to FIG. 3, an example computing device 300 upon which the methods described herein may be implemented is illustrated. The computing device 300 of FIG. 3 may comprise all or a portion of a bus security device, as described herein, it should be understood that the example computing device 300 is only one example of a suitable computing environment upon which the methods described herein may be implemented. Optionally, the computing device 300 can be a well-known computing system including, but not limited to, personal computers, servers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, network personal computers (PCs), minicomputers, mainframe computers, embedded systems, and/or distributed computing environments including a plurality of any of the above systems or devices. Distributed computing environments enable remote computing devices, which are connected to a communication network or other data transmission medium, to perform various tasks. In the distributed computing environment, the program modules, applications, and other data may be stored on local and/or remote computer storage media.

[0070] in its most basic configuration, computing device 300 typically includes at least one processing unit 306 and system memory 304. Depending on the exact configuration and type of computing device, system memory 304 may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. This most basic configuration is illustrated in FIG. 3 by dashed line 302. The processing unit 306 may be a standard programmable processor that performs arithmetic and logic operations necessary for operation of the computing device 300. The computing device 300 may also include a bus or other communication mechanism for communicating information among various components of the computing device 300.

[0071] Computing device 300 may have additional features/functionality. For example, computing device 300 may include additional storage such as removable storage 308 and non-removable storage 310 including, but not limited to, magnetic or optical disks or tapes.

Computing device 300 may also contain network connection(s) 316 that allow the device to communicate with other devices. Computing device 300 may also have input device(s) 314 such as a keyboard, mouse, touch screen, etc. Output device(s) 312 such as a display, speakers, printer, etc. may also be included. The additional devices may be connected to the bus in order to facilitate communication of data among the components of the computing device 300. All these devices are well known in the art and need not be discussed at length here.

[0072] The processing unit 306 may be configured to execute program code encoded in tangible, computer-readable media. Tangible, computer-readable media refers to any media that is capable of providing data that causes the computing device 300 (i.e., a machine) to operate in a particular fashion. Various computer-readable media may be utilized to provide instructions to the processing unit 306 for execution. Example tangible, computer-readable media may include, but is not limited to, volatile media, non-volatile media, removable media, and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. System memory 304, removable storage 308, and non-removable storage 310 are ail examples of tangible, computer storage media. Example tangible, computer-readable recording media include, but are not limited to, an integrated circuit (e.g., field-programmable gate array or application-specific 1C), a hard disk, an optical disk, a magneto-optical disk, a floppy disk, a magnetic tape, a holographic storage medium, a solid-state device, RAM, ROM, electrically erasable program read-only memory (EEPROM), flash memory or other memory technology, CD- ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices.

[0073] In an example implementation, the processing unit 306 may execute program code stored in the system memory 304. For example, the bus may carry data to the system memory 304, from which the processing unit 306 receives and executes instructions. The data received by the system memory 304 may optionally be stored on the removable storage 308 or the non-removable storage 310 before or after execution by the processing unit 306.

[0074] it should be understood that the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination thereof. Thus, the methods and apparatuses of the presently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, CD-ROMs, hard drives, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computing device, the machine becomes an apparatus for practicing the presently disclosed subject matter. In the case of program code execution on programmable computers, the computing device generally includes a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. One or more programs may implement or utilize the processes described in connection with the presently disclosed subject matter, e.g., through the use of an application programming interface (API), reusable controls, or the like. Such programs may be implemented in a high level procedural or object-oriented programming language to communicate with a computer system. However, the program(s) can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language and it may be combined with hardware implementations.

[0075] Examples

[0076] The disclosed MIL-STD-1553 security devices and methods were implemented with existing Abaco™ hardware to demonstrate the ability to provide effective security on the MIL-STD-1553 bus. The following was demonstrated: the ability to invalidate disallowed commands was verified; messages with out-of-bounds data was invalidated; and the ability to prevent the generation of any commands from a false BC was demonstrated. It was also found that the implementations can be easily integrated into existing systems; requires no modifications to existing legacy terminals (BCs, RTs, BMs) on the bus; can secure the entire bus (all terminals) by monitoring message traffic; and that security architecture is open, predictable, and fully defined. The response of the security device to threats is based on strict pre-defined rules.

[0077] Referring to the demonstration setup of FIG. 4, an Abaco R15-USB MIL-STD- 1553 module was used with custom firmware to act as a standalone security device. Note that this device only outputs a nominal 1553 transmit signal, NOT a maximum or beyond maximum level. Two Abaco 1553 channels on an Abaco Q.PCX-1553 were used, one acting as a remote terminal and one as a malicious bus controller. The security device was arbitrarily programmed to allow ail traffic with the exception of these command and data word combinations: Command: RT1, RX, Subaddress field equal to the word count field; Command: RT1, TX, Subaddress field equal to the word count field; Any messages with a data word equal to OxDEAD; and Ail broadcast commands.The initial invalidation signal was 24 periods of a 1,25MHz square wave. Other invalidation signals and methods are contemplated within the scope of the claims of this application, still under consideration and more testing and analysis will be performed.

[0078] Referring to FIG. 4, it is to be appreciated that the security function can be integrated into a single channel with the BC/RT/BM terminal, but for the demonstration a separate channel was used as an example of how security can be added to an existing unsecure terminal. The results of the demonstration are that: (1) Initial experiments verified that the invalidation signal successfully prevented completion of the disallowed messages, but did not interfere with allowed traffic. Over 10 million of each of the disallowed messages were attempted and ALL messages were effectively invalidated. (2) The ability to invalidate disallowed commands was verified. (3) Messages with out-of-bounds data was invalidated. (4) The ability to prevent the generation of any commands from a false BC was demonstrated. (5) All broadcast commands were invalidated. The timing diagrams shown in FIGS. 5A-5H show examples of messages with and without invalidation. In FIG. 5A an invalidation signal is injected onto the bus (no other bus activity). The upper signal is the bus voltage measured differentially. FIG. 5B illustrates BC-to-RT Message, normal communication without invalidation. The upper signal is the bus voltage measured differentially. FIG. SC illustrates BC-to-RT Message, Invalidation occurring after receiving command word. First data word is invalidated. The upper signal is the bus voltage measured differentially, and the bottom signal is the time window in which the invalidation signal is injected. FIG. 5D illustrates BC-to-RT Message, Command word itself is invalidated by the disclosed device and methods after receiving command sync and first five bits of RT address. The upper signal is the bus voltage measured differentially, and the bottom signal is the time window in which the invalidation signal is injected. FIG. 5E illustrates RT-to-BC Message, normal communication without invalidation. The upper signal is the bus voltage measured differentially. FIG. 5F illustrates BC-to-RT Message, invalidation occurring after receiving command word. First data word is invalidated. The upper signal is the bus voltage measured differentially, and the bottom signal is the time window in which the invalidation signal is injected. FIG. 5G illustrates RT-to-BC Message, command word itself is invalidated by the disclosed devices and methods after receiving command sync and first five bits of RT address. The upper signal is the bus voltage measured differentially, and the bottom signal is the time window in which the invalidation signal is injected,

[0079] The demonstration shows that the disclosed implementations are flexible and can be integrated with almost any security policy algorithm or security policy layer. Security rules can be programmed in multiple ways, including hard-coded in HDS. (used in the initial demonstration); loaded into FPGA lookup table from non-volatile memory (e.g. on existing Abaco platforms); loaded into FPGA lookup table from a secure microcontroller; other more complex methods are possible as well, since the disclosed implementations design provides all pertinent message information to the security policy layer; the disclosed security mechanisms can integrate with third party security algorithms; security rules/policy can be created from simple analysis of known traffic or can be created using bus monitoring and machine-learning techniques. Further it is shown that the disclosed implementations do not interfere at ail with normal bus traffic, but remains entirely passive. The security mechanism can be integrated with third party non-Abaco terminals. The security device can be implemented as a standalone device to help secure an otherwise unsecured bus. Further, the security device can be integrated with a bus controller to prevent all other terminals from initiating messages. In some instances, the security device can give an indication of the presence of abnormal activity or threats that have been detected. This notification can be tailored to the needs of the system or platform.

[0080] Conclusion

[0081] While the methods and systems have been described in connection with preferred embodiments and specific examples, if is not intended that the scope be limited to the particular embodiments set forth, as the embodiments herein are intended in ail respects to be illustrative rather than restrictive. [0082] Unless otherwise expressly stated, it is in no way intended that any method set forth herein be construed as requiring that its steps be performed in a specific order. Accordingly, where a method claim does not actually recite an order to be followed by its steps or it is not otherwise specifically stated in the claims or descriptions that the steps are to be limited to a specific order, it is no way intended that an order be inferred, in any respect. This holds for any possible non-express basis for interpretation, including: matters of logic with respect to arrangement of steps or operational flow; plain meaning derived from grammatical organization or punctuation; the number or type of embodiments described in the specification.

[0083] Throughout this application, various publications may be referenced. The disclosures of these publications in their entireties are hereby fully incorporated by reference into this application in order to more fully describe the state of the art to which the methods and systems pertain.

[0084] It will be apparent to those skilled in the art that various modifications and variations can be made without departing from the scope or spirit. Other embodiments will be apparent to those skilled in the art from consideration of the specification and practice disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit being indicated by the following claims.

APPENDIX A

MILITARY STANDARD

AIRCRAFT INTERNAL TIME DIVISION

COMMAND/RESPONS& MULTIPLEX DATA SOS

Aircraft Internal Time Division Command /Response Multiplex Data Bus MIL -STD - 1553 B

1. This Military Standard is approved for use by all Department and Agencies of the Department of Defense ,

2. beneficial comments ( recommendations, additions , deletions) and any pertinent data which may be of use in improving this document should he addressed to : Aeronautical Systems Division, Attn: EMAI, feright-Patterson Air force Base 45433 , by using the self addressed Standardisation Document Improvement Proposal (DD Form 1426) appearing at the end of this document or by letter .

This standard contains requirements tor aircraft internal time division command/response multiplex data bus techniques which will be utilized in systems integration of aircraft subsystems , Even with the use of this standard , subtle differences will exist between multiplex data buses used on different aircraft due to particular aircraft mission requirements and the designer options allowed in this standard . The system designer must recognize this fac t and design the multiplex Dus controller hardware and software to accommodate such differences , These designer selected options must exist , so as to allow the necessary flexibility in the design of specific multiplex systems in order to provide for the control mechanism , architecture redundancy , degradation concept and traffic patterns peculiar to the specific aircraft mission requirements . CONTENTS CONTENTS (Confc’d)

Page

COMMENTS (Cont’a)

Paragraph

CONTENTS (tent'd)

FIGURES

1 . SCOPE

1 _. 1 Scope, This standard establishes requirements for digital , command/ response , time division multiplexing (Data Bus) techniques on aircraft . It encompasses the data bus line and its interface electronics illustrated on figure 1 , and also defines the concept of operation and information flow on the multiplex data bus ana the electrical and functional formats to be employed ,

1.2 Application , When invoked in a specification or statement of work , these requirements snail apply to the multiplex data bus and associated equipment which is developed either alone or as a portion of an aircraft weapon system or subsystem development , Ine contractor is responsible for invoking all the applicable requirements of this Military Standard on any and all subcontractors he may employ.

2. REFERENCED DOCu!miMTB

2. 1 Issue of document . The following document , of the issue in effect on date of invitation for bid or request for proposal , forms a part of the standard to the extent specified herein ,

SPECIFICATION

MILITARY Electromagnetic Compatibility Requirements , Systems

(Copies of specifications , standards , drawings , and publications required by contractors in connection with specific procurement functions should be obtained from the procuring activity or as directed by the contracting officer .)

3. DEFINITIONS

3. 1 bit. Contraction of binary digit : may be either zero or one . In Information theory a binary digit is equal bo one binary decision or the designation of one of two possible values or states of anything used to store or convey information ,

3.2 The number of bite transmitted per second .

3.3 Pulse code modulation (PCM) . The form of modulation in which the modulation signal is sampled , quantized , and coded so that each element of information consists of different types or numbers of pulses and spaces .

3- -‘i Time division multiplexing (TDM) . The transmission of information from several signal sources through one communication system with different signal samples staggered in time to form a compossite pulse train .

3 _* 5 Half duplex. Operation of a data transfer system in either direction over a single line , but not in both directions on that line simultaneously.

3,6 Word . In this document a word is a sequence of 16 bits plus syno and parity. There are three types of words: command , status and data . 3.7 Message . A single message is the transmission of a command word , status word , and data woros if they are specified. For the case of a remote terminal to remote terminal (RT to RT) transmission , the message shall include the two command words , the two status words , and data words .

3.8 Subsystem . The device or functional unit receiving data transfer service iron the data bus .

3.9 Data__bus . Whenever a data bus or bus is referred to in this document it shall imply all the hardware including twisted shielded pair cables , isolation resistors , transformers, etc , , required to provide a single data path between the bus controller and all the associated remote terminals .

3. 10 Terminal . The electronic module necessary to interface the data bus with the subsystem and the subsystem with the data bus . Terminals may exist as separate line replaceable units (LRU' s) or be contained within the elements of the subsystem .

3.11 Bus controller . The terminal assigned the task of initiating information transfers on the data bus .

3. 12 Bus monitor. The terminal assigned the task of receiving bus traffic and extracting selected information to be used at a later time .

3. 13 Remote terminal (HT) . All terminals not operating as the bus controller or as a bus monitor .

3. 14 Asynchronous operation . For the purpose of this standard , asynchronous operation is the use of an independent clock source in each terminal for message transmission. Decoding is achieved in receiving terminals using clock information derived from the message .

3. 15 Dynamic bus control . The operation of a data bus system in which designated terminals are offered control of the data. bus

3. 16 Commarsd/Response . Operation of a data bus system such that remote terminals receive and transmit data only when commanded to do so by the bus controller .

3. 17 Redundant data bus . The use of more than one data bus to provide more than one data path between the subsystems , i .e . , dual redundant data bus , tri- redundant data bus , etc ,

3. 18 broadcast. Operation of a data bus system such that information transmitted by the bus controller or a remote terminal is addressed to more than one of the remote terminals connected to the data bus ,

3.19 Mode code . A means by which the bus controller can communicate with the multiplex bus related hardware , in order to assist in the management of infonsation flow . 4. GENERAL REQUIREMENTS

4· 1 Test and operating requirements , All requirements as specified herein shall be valid over the environmental conditions which the multiplex data bus system shall be required to operate .

4.2 Data bus operation. The multiplex data bus system in its most elemental configuration shall be as shown on figure 1. The multiplex data bus system shall function asynchronously in a oommand /response mode, and transmission shall occur in a half-duplex manner . Sole control of information transmission on the bus shall reside with the bus controller , which shall initiate all transmissions . The information flow on the data bus shall be comprised of messages which are , in turn , formed by three types of words ( command , data , and status) as defined in 4.3.3.5.

4.3 Characteristics

4.3. 1 Data form. Digital data may be transmitted in any desired form , provided that the chosen form shall be compatible with the message and word formats defined in this standard . Any unused bit positions in a word shall be transmitted as logic zeros .

4.3.2 Bit priority . The most significant bit shall be transmitted first with the less significant bits following in descending order of ^' value in the data word . The number of bits required to define a quantity shall be consistent with the resolution or accuracy required. In the event that multiple precision quantities ( information accuracy or resolution requiring more than 16 bits) are transmitted , the most significant bits shall be transmitted first , followed by the word(s) containing the lesser significant bits in numerical descending order . Bit packing of multiple quantities in a single data word is permitted .

4.3.3 Transmission method

4.3, 3. 1 Modulation. The signal shall be transferred over the data bus in serial digital pulse code modulation form ,

4.3. 3. 2 Data code . The data code shall be Manchester II bi-phase level , A logic one shall be transssitted as a bipolar coded signal 1 /0 (i .e . , a positive pulse followed by a negative pulse) . A logic zero shall be a bipolar coded signal 0/1 (i .e . , a negative pulse followed by a positive pulse) . A transition through zero occurs at the midpoint of each bit time ( see figure 2) .

4. 3. 3. 3 Transmission bit rate . The transmission bit rate on the bus shall be 1 .0 megabit per second with a combined accuracy and long-term stability of ±

0. 1 percent (i .e . , i 1000 hertz (Hz) ) . The short-term stability ( i .e . , stability over 1.0 second interval) shall be at least 0.01 percent ( i .e . , ± 100 Hz) .

4.3, 3. 4 Bord size. The word size shall be 16 bits plus the sync waveform and the parity bit for a total of 20 bits times as shown on figure 3.

4.3.3· 5 Word formats . The word formats shall be as shown on figure 3 for the command , data , and status words . DATA ENCODING

FIGURE 5 Data sync.

4.3.3.5.1 Command word. A command word shall be comprised of a sync waveform, remote terminal address field, transmit/receive (T/R) bit, subaddress/mode field, word count/mode code field, and a parity (P) bit (see figure 3).

4.3.3.5.1.1 Svnc. The command syne waveform shall be an Invalid Manchester waveform as shown on figure 4. The width shall be three bit times, with the sync waveform being positive for the first one and one-half bit times, and then negative for the following one and one~half bit times. If the next bit following the syne waveform is a logic aero, then the last half of the sync waveform will have an apparent width of two clock periods due to the Manchester encoding.

4.3.3.5.1.2 Remote terminal address. The next five bits following the sync shall be the RT address. Each HT shall be assigned a unique address. Decimal address 31 (11111) shall not be assigned as a unique address. In addition to its unique address, a RT shall be assigned decimal address 31 (11111) as the common address, if the broadcast option is used.

4.3.3.5.1.3 Transmit/receive. The next bit following the remote terminal address shall be the T/R bit, which shall indicate,the action required of the RT. A logic sero shall indicate the RT is to receive, and a logic one shall indicate the RT is to transmit.

4.3.3.5.1.4 Subaddress/mode, The next five bits following the R/T bit shall ba utilized to indicate an RT subaddress or use of mode control, as is dictated by the individual terminal requirements. The subaddress/mode values of 00000 and 11111 are reserved for special purposes, as specified in 4,3.3.5.1.7, and shall not be utilised for any other function.

4.3.3.5.1.5 Data word count/mode node. The next five bits following the subaddress/mode field shall be the quantity of data words to be either sent out or received by the RT or the optional mode cods as specified in 4.3.3-5.1.7. A maximum of 32 data words may be transmitted or received in any one message block. All 1 ^' s shall indicate a decimal count of 31, and all O's shall indicate a decimal count of 32.

4.3.3.5.1.6 Parity. The last bit in the word shall be used for parity over the preceding 16 bits. Odd parity shall be utilised.

4.3.3·5.1.7 Optional mode control. For RT’s exercising this option a subaddress/mode code of 00000 or 11111 shall imply that the contents of the data word count/mode code field are to be decoded as a five bit mode command. The mode code shall only be used to communicate with the multiplex bus related hardware, and to assist in the management of information flow, and not to extract data from or feed data to a functional subsystem. Codes 00000 through 01111 shall only be used for mode codes which do not require transfer of a data word. For these codes, the T/R bit shall be set to 1. Codes 10000 through 11111 shall only be used for mode codes which require transfer of a single data word. For these mode codes, the T/R bit shall indicate the direction of data word flow as specified in 4.3.3.5.1.3. No multiple data word transfer shall be implemented with any mode code. The mode codes are reserved for the specific functions as specified in table I and shall not be used for any other purpose. If the designer chooses to implement any of these functions, the specific codes,T/R bit assignments, and use of a data word, shall be used as indicated.

The use of the broadcast command option shall only be applied to particular mode codes as specified in table 1.

4.3.3.5.1.7.1 Dynamic bus control. The controller shall issue a transmit command to an ST capable of performing the bus control function. This RT shall respond with a status word as specified in 4.3.3.5.3. Control of the data bus passes from the offering bus controller to the accepting RT upon completion of the transmission of the status word by the RT. If the RT rejects control of the data bus, the offering bus controller retains control of the data bus.

4.3.3.5.1.7-2 Synchronize (without data word). This command shall cause the RT to synchronize (e.g., to reset the internal timer, to start a sequence, etc,). The RT shall transmit the status word as specified in 4.3.3.5.3,

4.3.3-5.1.7,3 Transmit status word. This command shall cause the RT to transmit the status word associated with the last valid command word preceding this command. This mode command shall not alter the state of the status word.

4.3.3.5.1.7.4 Initiate,self test. This command shall be used to initiate self test within the RT. The RT shall transmit the status word as specified in 4.3.3.5.3.

4.3.3.5.1.7,5 Transmitter shutdown. This command (to only be used with dual redundant bus systems} shall cause the RT to disable the transmitter associated with the redundant bus. The RT shall not comply with a command to shut down a transmitter on the bus from which this command is received. In all cases, the RT shall respond with a status word as specified in 4.3.3.5.3 after this command.

4.3.3.5.1.7.6 Override transmitter shutdown. This command (to only be used with dual redundant bus system) shall cause the RT to enable a transmitter which was previously disabled. The RT shall not comply with a command to enable a transmitter on the bus from which this command is received. In all cases, the RT shall respond with a status word as specified in 4.3-3 _* 5.3 after this command.

4.3.3.5.1.7.7 Inhibit terminal flag (T/F) bjt- This command shall cause the RT to set the T/P bit in the status word specified in 4.3-3.5-3 to logic zero until otherwise commanded. The RT shall transmit the status word as specified in 4.3.3.5.3.

4.3.3.5.1.7.8 Override inhibit T/R bjt- This command shall cause the RT to override the inhibit T/P bit specified in 4.3-3-5.1.7.7. The RT shall transmit the status word as specified in 4.3.3.5.3.

4.3.3.5.1.7.9 Resetremoteterminal. This command shall be used to reset the RT to a power up initialized state. The RT shall first transmit its status word,and then reset.

4.3-3.5.1.7-10 Reserved mode codes (01001 to 01111). These mode codes are reserved for future use and shall not be used. TABLE I, Assigned mode codes ed 4.3.3.5.1.7. 11 Transmit vector -word. This command shall cause the RT to transmit a status word as specified in 4. 3. 3. 5. 3 and a data word containing service request information.

4.3.3.5.1.7. 12 Synchronize (with data word) . The RT shall receive a command word followed by a data word as specified in 4. 3. 3. 5. 2. The data word shall contain synchronization information for the RT. After receiving the command and data word , tne MT shall transmit the status word as specified in 4, 3. 3.5. 3.

4.3.3.5. 1.7. 13 Transmit last command word . This command shall cause the RT to transmit its status worn as specified in 4. 3. 3.5.3 followed by a single data word which contains oits 4—19 of the last command word , excluding a transmit last command word mode code received by tne RT. This mode command shall not alter the state of the RTs status word .

4.3.3.5. 1.7.14 Transmit built- In- test (SIT) word . This command shall cause the hT to transmit its status word as specified in 4.3.3.5.3 followed by a single data word containing the RT BIT data. This function is intended to supplement the available bits in the status word when the RT hardware is sufficiently complex to warrant its use . The data word , containing the RT BIT data , shall not be altered by the reception of a transmit last command or a transmit status word mode code. This function shall not be used to convey BIT data from the assoc iated subsystem ( s) .

4.3.3.5. 1.7. 15 Selected transmitter _.. shutdown . This command shall cause the RT to disable the transmitter associated with a specified redundant data bus . The command is designed for use with systems employing more than two redundant buses . The transmitter that is to be disabled shall oe identified in the data word following the command word in the format as specified in 4.3· 3. 5.2. The RT snail not comply with a command to shut down a transmitter on the bus from which this command is received . In all esses, the RT shall respond with a status word as specified in 4.3.3.5.3.

4.3.3.5. 1.7. 16 faverride selected transmitter shutdown. This command shall cause the M to enable a transmitter which was previously disabled . The command is designed for use with systems employing more than two redundant buses. The transmitter that is to be enabled shall be identified in the data word following the command word in the format as specified in 4. 3. 3.5.2. The RT shall not comply with a command to enable a transmitter on the bus from which this command is received . In all cases, the RT shall respond with a status word as specified in 4. 3.3.5.3.

4.3.3.5. 1.7. 17 Reserved. mode codes ( 10110 to 11 111 ) . These mode codes are reserved for future use and shall not be used ,

4. 3. 3. 5.2 Data word . A data word shall be comprised of a sync waveform , data bits , and a parity bit (see figure 33 .

4.3.3. 5.2. 1 Sync . The data sync waveform shall be an invalid Manchester waveform as shdwn on figure 5. The width shall be three bit times , with the waveform being negative for the first one and one-half bit times, and then positive for the following one and one-half bit times . Note that if the bits preceding and following the sync are logic ones, then the apparent width of the sync waveform will be increased to four bit times . 4.3.3·5.2,2 Data. The sixteen bits following the syne shall be utilised for data transmission as specified in 4.3.2.

4.3.3.5.2.3 Parity. The last bit shall be utilised for parity as specified in 4.3.3.5.1.6.

4.3.3.5.3 Status word. A status word shall be comprised of a sync waveform,

RT address,message error bit, instrumentation bit, service request bit, three reserved bits, broadcast command received bit, busy bit, subsystem flag bit, dynamic bus control acceptance bit, terminal flag bit, and a parity bit. For optional broadcast operation, transmission of the status word shall be suppressed as specified in 4.3.3.6.7.

4.3.3.5.3.1 Sync. The status sync waveform shall be as specified in 4.3.3.5.1.1.

4.3.3.5.3.2 RT address. The next five bits following the sync shall contain the address of the RT which is transmitting the status word as defined in

4.3.3.5.1.2.

4.3.3.5.3.3 Message error bit. The status word bit at bib time nine (see figure 3) shall be utilised to indicate that one or more of the data words associated with the preceding receive command word from the bus controller has failed to pass the RT ^' s validity*tests as specified in 4.4.1,1. This bit shall also be set under the conditions specified in 4.4.1.2.4.4.3.4 and 4.4.3.6. A logic one shall indicate the presence of a message error, and a logic zero shall show its absence. All RT's shall implement the message error bit.

4.3.3.5,3.4 Instrumentation bit. The status word at bit time ten (see figure 3) shall be reserved for the instrumentation bit and shall always be a logic aero. This bit is intended to be used in conjunction with a logic one in bit time ten of the command word to distinguish between a command word and a status word. The use of the instrumentation bit is optional,

4.3.3.5.3.5 Service request bit. The status word hit at bit time eleven (see figure 3) shall be reserved for the service request bit. The use of this bit is optional. This bit when used, shall indicate the need for the bus controller to take specific predefined actions relative to either the RT or associated subsystem. Multiple subsystems, interfaced to a single RT,which individually require a service request signal shall logically OR their individual signals into the single status word bit. In the event this logical OR is performed, then the designer must make provisions in a separate data word to identify the specific requesting subsystem. The service request bit is intended to be used only to trigger data transfer operations which take place on an exception rather than periodic basis. A logic one shall indicate the presence of a service request, and a logic aero its absence. If this function is not implemented, the bit shall be set to zero,

4.3.3.5.3.6 Reserved status bits. The status word bits at bit times twelve through fourteen are reserved for future use and shall not be used. These bits shall be set to a logic zero. 4.3.3.5.3.7 Broadcast command received bit. The status word at bit time fifteen shall be set to a logic one to indicate that the preceding valid command word was a broadcast command and a logic zero shall show it was not a broadcast command- If the broadcast command option is not used, this bit shall be set to a logic zero.

3.3.5.3.8 .Busy.Bit. The status word bit at bit time sixteen (see figure 3) shall be reserved for the busy bit. The use of this bit is optional. This bit, when used, shall indicate that the RT or subsystem is unable to move data to or from the subsystem in compliance with the bus controller'scommand. A logic one shall indicate the presence of a busy conditions and a logic zero its absence. In the event the busy bit is set in response to a transmit command, then the RT shall transmit its status word only. If this function is not implemented, the bit shall be set to logic zero,

4.3.3.5.3.9 Subsystem flag bit. The status word bit at bit time seventeen (see figure 3) shall be reserved for the subsystem flag bit. The use of this bit is optional- This bit,when used, shall flag a subsystem fault condition, and alert the bus controller to potentially invalid data. Multiple subsystems, interfaced to a single RT,which individually require a subsystem flag bit signal shall logically OR their individual signals into the single status word bit. In the event this logical OR is performed, than the designer must make provisions in a separate data word to identify the specific reporting subsystem. A logic one shall indicate the presence of the flag,and a logic zero its absence. If not used, this bit shall be set to logic zero.

4.3.3·5.3.10 Dynamic bus control acceptance bib. The status word bit at bit time eighteen (see figure 3) shall be reserved for the acceptance of dynamic bus control. This bit shall be used if the RT implements the optional dynamic bus control function- This bit, when used, shall indicate acceptance or rejection of a dynamic bus control offer as specified in 4.3.3.5.1.7.1. A logic one shall indicate acceptance of control, and a logic zero shall indicate rejection of control. If this function is not used, this bit shall be set to logic zero.

4.3.3.5.3.11 Terminal flag bit. The status word bit at bit time nineteen (see figure 3) shall be reserved for the terminal flag function. The use of this bit is optional. This bit, when used, shall flag a ST fault condition. A logic one shall indicate the presence of the flag,and a logic zero, its absence- If not used, this bit shall be set to logic zero.

4,3.3.5.3.12 Parity bit. The least significant bit in the status word shall be utilized for parity as specified in 4.3.3.5.1.6.

4.3.3.5.4 Status ward reset. The status word bit, with the exception of the address, shall be set to logic zero after a valid command word is received by the RT with the exception as specified in 4.3.3·5.1.7. If the conditions which caused bits in the status word bo be set (e.g., terminal flag) continue after the bits are reset to logic zero, then the affected status word bit shall be again set,and then transmitted on the bus as required.

4.3.3.6 Message formats. The messages transmitted on the data bus shall be in accordance with the formats on figure 6 and figure 7. The maximum and minimum response times shall be as stated in 4.3.3.7 and 4.3.3.8. So message formats, other than those defined herein, shall be used on the bus. 4.3-3.6.1 The bus controller shall issue a receive command followed by the specified number of data words. The BT shall,after message validation, transmit a status word back to the controller. The command and data words shall be transmitted in a contiguous fashion with no interword gaps.

4.3.3.6.2 The bus controller shall issue a transmit command to the RT. The RT shall,after command word validation, transmit a status word back to the bus controller, followed by the specified number of data words. The status and data words shall be transmitted in a contiguous fashion with no interword gaps. shall issue a receive command to BT A followed contiguously by a transmit command to RT B, RT B shall, after command validation, transmit a status word followed by the specified number of data words. The status and data words shall be transmitted in a contiguous fashion with no gap. At the conclusion of the data transmission by RT B,RT A shall transmit a status word within the specified time period.

4.3.3.6,4 Mode command without data word. The bus controller shall issue a transmit command to the RT using a mode code specified in table I. The RT shall, after command word validation, transmit a status word,

4.3.3.6.5 Mode command with data word (transmit). The bus controller shall issue a transmit command to the RT using a mode code specified in table I, The RT shall,after command woi’d validation, transmit a status word followed by one data word. The status word and data word shall be transmitted in a contiguous fashion with no gap,

4.3.3.6,6 Mode command with data word (receive). The bus controller shall issue a receive command to the RT using a mods code specified in table 1, followed by one data word. The command word and data word shall be transmitted in a contiguous fashion with no gap. The RT shall, after command and data word validation, transmit a status word back to the controller.

4.3.3·6.7 Optional _b roa dcast _c ommand. See 10.6 for additional information on the use of the broadcast command,

4.3,3.6.7,1 Bus controller to remote terminal(s) transfer (broadcast). The bus controller shall issue a receive command word with 11111 in the RT address field followed by the specified number of data words. The command word and data words shall be transmitted In a contiguous fashion with no gap. The RT(s) with the broadcast option shall after message validation, set the broadcast command received bit in the status word as specified in 4.3.3.5.3.7 and shall not transmit the status word.

4. 3.3· 6.7.2 Remote .terminal to remote .terminal(s) transfers . (broadcast) . The bus controller shall issue a receive command word with 11111 in the BT address field followed by a transmit command to RT A using the RT' s address. RT A shall , after command word validation, transmit a status word followed by the specified number of data words . The status and data words shall be transmitted in a contiguous fashion with no gap. The BT(s) with the broadcast option, excluding RT A, shall after message validation , set the broadcast received bit in the status word as specified in 4. 3.3.5.3.7 and shall not transmit the status word .

4.3.3.6.7.3 Mods command without data word (broadcast) . The bus controller shall issue a transmit command word with 11111 in the RT address field , and a mode code specified in table I. The RT(s) with the broadcast option shall after command word validation , set the broadcast received bit in the status word as specified in 4. 3. 3.5.3,7 and shall nob transmit· the status word,

4.3, 3· 6.7.4 Mode command with data word ( broadcast) , The bus controller shall issue a receive command word with 11111 in the RT address field and a mode code specified in table I , followed by one data word . The command word and data word shall be transmitted in a contiguous fashion with no gap. The RT(s) with the broadcast option shall after message validation , set the broadcast received bit in the status word as specified in 4.3.3.5.3.7 and shall not transmit the status word ,

4.3.3.7 Intermessage gap. The bus controller shall provide a minimum gap time of 4.0 microseconds (.us) between messages as shown on figure 6 and figure 7 . This time period , shown as T on figure 8 , is measured at point A of the bus controller as shown on figure 9 or figure 10, The time is measured from the mid-bit zero crossing of the last bit of the preceding message to mid-zero crossing of the next command word sync .

4.3. 3. 8 Response time . The RT shall respond , in ascendance with 4. 3. 3.6, to a valid command word within the time period of 4,0 to 12.0 us. This time period , shown as T on figure 8, is measured at point A of the RT as shown on figure 9 or figure 10. The time is measured from the mid bit zero crossing of the last word as specified in 4. 3· 3.6 and as shown on figure 6 and figure 7 to the mid-zero crossing of the status word sync .

4.3.3.9 Minimum n o-response time-out . The minimum time that a terminal shall wait before considering that a response as specified in 4. 3.3.8 has not occurred shall be 14,0 us. The time is measured from the mid-bit zero crossing of the last bit of the last word to the mid-zero crossing of the expected status word sync at point A of the terminal as shown on figure 9 or figure 10.

4. 4 Teminal_operation .

4.4. 1 Common operation . Terminals shall have common operating capabilities as specified in the following paragraphs .

18

FIGURE 9. Data bus Interface using transformer coupling.

FIGURE 10 4.4. 1. 1 Word validation . The terminal shall insure that each word conforms to the following minimum criteria ; a . The word begins with a valid sync field, b . The bits are in a valid Manchester 11 code, o . The information field has 16 bits plus parity , d . The word parity is odd .

When a word fails to conform to the preceding criteria , the word shall be considered invalid .

4.4. 1.2 Transmission continuity . The terminal shall verify that the message is contiguous as defined in 4. 3. 3.6. Improperly timed data syncs shall be considered a message error.

4. 4. 1.3 Terminal fail - safe , The terminal shall contain a hardware implemented time-out to preclude a signal transmission of greater than 800.0 us . Tills hardware shall not preclude a correct transmission in response to a command. Reset of this time-out function shall be performed by the reception of a valid command on the bus on which the time-out has occurred .

4.4.2 Bus controller operationa . A terminal operating as a bus controller shall be responsible for sending data bus commands , participating in data transfers , receiving status responses , and monitoring system status as defined in this standard , the bus controller function may be embodied as either a stand-alone terminal , whose sole function is to control the data bus( s) , or contained within a subsystem . Only one terminal shall be in active control of a data bus at any one time .

4.4.3 Remote terminal .

4.4.3. 1 Operation . A remote terminal ( RT) shall operate in response to valid commands received from the bus controller . The RT shall accept a command word as valid when the command word meets the criteria of 4.4. 1. 1 , and the command word contains a terminal address which matches the RT address or an address of 11111 _, if the RT has the broadcast option.

4.4.3.2 Superseding valid commands . The RT shall be capable of receiving a command word on the data bus after the minimus intermessage gap time as specified in 4.3.3·7 has been exceeded , when the RT is not in the time period T as specified in 4.3.3. 8 prior to the transmission of a status word , and when it is not transmitting on that data bus. A second valid command word sent to an RT shall take precedence over the previous command . The RT shall respond to the second valid command as specified in 4. 3· 3· 8.

4. 4. 3. 3 Invalid commands . A remote terminal shall not respond to a command word which fails to meet the criteria specified in 4.4· 3· 1 .

4,4. 3. 4 Illegal command . An illegal command is a valid command as specified in 4. 4. 3. 1 , where the bits in the subaddress/mode field , data word count/mode code field , and the T/R bit indicate a mods command , subaddress , or word count that has not been implemented in the RT. It is the responsibility of the bus controller to assure that no illegal commands are sent out . The RT designer has the option of monitoring for illegal commands. If an RT that is designed with this option detects an illegal command and the proper number of contiguous valid data words ^; as specified by the illegal command word, it shall respond with a status word only, setting the message error bit,and not use the information received,

4.4.3.5 Valid data reception. The remote terminal shall respond with a status word when a valid command word and the proper number of contiguous valid data words are received,or a single valid word associated with a mode code is received. Each data word shall meet the criteria specified in 4.4.1.1.

4.4.3.6 Invaliddatareception. Any data word(s) associated with a valid receive command that does nob meet the criteria specified in 4.4,1.1 and 4.4.1.2 or an error in the data word count shall cause the remote terminal to set the message error bit in the status wox'd to a logic one and suppress the transmission of the status word. If a message error has occurred, then the entire message shall be considered invalid,

4.4.4 Bus monitor operation, A terminal operating as a bus monitor shall receive bus traffic and extract selected information. While operating as a bus monibox·, the terminal shall not respond to any message except one containing its own unique address if one is assigned. All information obtained while acting as a bus monitor shall be strictly used for off-line applications (e,g., flight test recording,maintenance recording or mission analysis) or to provide the back-up bus controller sufficient information to take over as the bus controller.

4.5 Hardware characteristics.

4.5.1 Data bus characteristics.

4.5.1.1 Cable. The cable used for the main bus and all stubs shall be a two conductor, twisted, shielded,jacketed cable. The wire-to-wlre distributed capacitance shall not exceed 30,0 picofarads per foot. The cables shall be formed with not less than four twists per foot where a twist is defined as a 360 degree rotation of the wire pairs; and, the cable shield shall provide a minimum of 75.0 percent coverage.

4.5.1.2 Characteristic impedance. The nominal characteristic impedance of the cable (z _o ) shall be within the range of 70,0 ohms to 85.0 ohms at a sinusoidal frequency of 1.0 megahertz (MBs),

4.5.1.3 Cable attenuation. At the frequency of 4.5.1.2, the cable power loss shall not exceed 1.5 ^' decibels (dB)/100 feet (ft).

4.5.1.4 Cable termination. The two ends of the cable shall be terminated with a resistance, equal to the selected cable nominal characteristic impedance (Z _o ) ± 2.0 percent.

4.5.1.5 Cable stub requirements. The sable shall be coupled to the terminal as shown on figure 9 or figure 10. The use of long stubs is discouraged, and the length of a stub should be minimised. However, if installation requirements dictate, stub lengths exceeding those lengths specified in

4.5.1.5.1and 4.5.1.5.2 ars permissible. 4.5.1.5.1 Transformer coupled stubs. The length of a transformer coupled stub should nob exceed 20 feet. If a transformer coupled stub is used, then the following shall apply.

4.5.1.5.1.1 Coupling transformer. A coupling transformer,as shown on figure 9, shall be required. This transformer shall have a turns ratio of 1:1..41± 3.0 percent, with the higher turns on the isolation resistor side of the stub.

4.5.1.5.1.1.1 Transformer input impedance. The open circuit impedance as seen at point B on figure 11 shall be greater than 3000 ohms over the frequency range of75.0 kilohertz (kHz) to 1.0 megahertz (MHz),when measured with a 1.0 ^' v root-mean-square (RMS) sin wave.

4.5.1.5.1.1.2 Transformer waveform integrity. The droop of the transformer using the test configuration shown on figure 11 at point B,shall not exceed 20.0 percent. Overshoot and ringing as measured at point B shall be less that i 1.0 V peak. For this test,H shall equal 360.0 ohm3 ±5.0 percent and the input A of figure 11 shall be a 250.0 kHz square wave.27.0 V peak-to-peak, with a rise and fall time no greater than 100 nanoseconds (ns).

4.5.1.5.1.1.3 Transformer common mods rejection. The coupling transformer shall have a common mode rejection ratio greater than 45.0 dB at 1.0 MHz.

4.5.1.5.1.2 Fault isolation. An isolation resistor shall be placed in series with each connection to the data bus cable. This resistor shall have a value of 0.75 Z ₀ ohms plus or minus 2.0 percent,where Z _o is the selected cable nominal characteristic impedance. The impedance placed across the data bus cable shall be no less than 1.5 Z _o ohms for any failure of the coupling transformer,cable stub,or terminal transmitter/receiver.

4.5.1.5.1.3 Cable coupling. All coupling transformers and isolation resistors,as specified in 4.5.1.5.1.1 and 4.5.1.5.1.2, shall have continuous shielding which will provide a minimum of 75 percent coverage. The isolation resistors and coupling transformers shall be placed at minimum possible distance from the junction of the stub to the main bus.

4.5.1.5.1.4 Stub voltage requirements. Every data bus shall be designed such that all stubs at point A of figure 9 shall have a peak-to-peak amplitude, line-to-line within the range of 1.0 and 14.0 v for a transmission by any terminal on the data bus. This shall include the maximum reduction of data bus signal amplitude in the event that one of the terminals has a fault which causes it to reflect a fault impedance specified in 4.5.1.5.1.2 on the data bus. This shall also include the worse case output voltage of the terminals as specified in 4.5.2.1.1.1 and 4.5.2.2.1.1.

4.5.1.5.2 Directcoupledstubs. The length of a direct coupled stub should not exceed 1 foot. Refer to 10.5 for comments concerning direct coupled stubs. If a direct coupled stub is used, then the following shall apply.

4.5.1.5·2.1 Fault isolation· An isolation resistor shall be placed in series with each connection to the data bus cable. This resistor shall have a value of 55-0 ohms plus or minus 2,0 percent.The isolation resistors shall be placed within the RT as shown on figure 10.

FIGUXE 12. Terminal I/O characteristics for transformer coupled and direct coupled stubs. 4.5.1.5.2.2 Gable coupling. All bus-stub junctions shall hare continuous shielding which will provide a minimum of 75 percent coverage.

4.5.1.5.2.3 Stub voltage requirements. Every data bus shall be designed such that all stubs at point A of figure 10 shall have a peak-to-peak amplitude, line-to-line within the range of 1.4 and 20.0 V for a transmission by any terminal on the data bus. This shall include the maximum reduction of data bus signal amplitude in the event that one of the terminals has a fault which causes it to reflect a fault impedance of 110 ohms on the data bus. This shall also include the worst case output voltage of the terminals as specified in

4.5.2.1.1.1 and 4.5.2.2.1.1.

4.5~1.5.3 Wiring and cabling for EMC. For purposes of electromagnetic capability (EMC), the wiring and cabling provisions of MIL-E-6051 shall apply.

4.5.2 Terminal characteristics.

4.5.2.1 Terminals with transformer coupled stubs.

4.5.2.1.1 Terminal output characteristics. The following characteristics shall be measured with RL, as shown on figure 12, equal to 70.0 ohms±2.0 percent,

4,5,2.1.1.1 Output levels. The terminal output voltage levels shall be measured using the test configuration shown on figure 12. The terminal output voltage shall be within the range of 18.0 to 27.0 V, pcak-to-peak, line-to-line, when measured at point A on figure 12.

4.5.2.1.1.2 Output waveform. The waveform,when measured at point A on figure 12 shall have zero crossing deviations which are equal to,or less than,25.0 ns from the ideal crossing point,measured with respect to the previous sera crossing {i.e., .5 ± .025 μS, 1,0 ± .025 ,μs, 1.5 ± .025 μs, and 2.0± .025,μs). The rise and fall time of this waveform shall be from 100.0 to 300.0 ns when measured from levels of 10 to 90 percent of full waveform peak-to-peak, line-to-line, voltage as shown on figure 13· Any distortion of the waveform including overshoot and ringing shall not exceed± 900.0 millivolts (mv)peak, line-to-line,as measured at point A, figure 12.

4.5.2.1.1.3 Output _. noise. Any noise transmitted when the terminal is receiving or has power removed, shall not exceed a value of 14,0 mV,RMS, line-to-line, as measured at point A, figure 12.

4.5.2.1.1.4 Output symmetry. From the time beginning 2.5 MS after the mid-bit crossing of the parity bit of the last word transmitted by a terminal, the maximum voltage at point A of figure 12 shall be no greater than ± 250.0 mV peak, line-to-line. This shall be tested with the terminal transmitting the maximum number of words it is designed to transmit, up to 33- This test shall be run six times with each word in a contiguous block of words having the same bit pattern. The six word contents that shall be used are 8000 _16, 7FFF16, 000016,FFFP16 _, 555516, and AAAA16. The outputof the erminal shall be as specified in 4.5.2.1.1.1and 4.5.2.1.1.2.

4.5.2.1.2 Terminal innut characteristics. The following characteristics shall be measured independently.

receiving and operating with the incoming signals specified herein , and shall accept waveform varying from a square wave to a sine wave with a maximum zero crossing deviation from the ideal with respect to the previous zero crossing of ± 150 ns, {i.e., 2.0 ± , 15 μs, 1.5 ± .15 μs, 1.0 ± . 15 . μs , .5 t . 15 μs) . The terminal shall respond to an input signal whose peak-to-peak amplitude , line--o~line , is within the range of .86 to 14.0 V . The terminal shall not respond to an input signal whose peak- to- peak amplitude , line-to-line , is within the range of 0.0 to .20 V. The voltages are measured at point A on figure 9.

4.5.2. 1.2.2 Common mode rejections. Any signals from direct current (DC) to 2, 0 MHz ,with amplitudes equal to or less than ± 10.0 V peak , line-to-ground , measured at point A on figure 9, shall not degrade the performance of the receiver .

4.5.2. 1.2.3 input impedance, The magnitude of the terminal input impedance , when the RT is not transmitting , or has power removed , shall be a minimum of 1000, 0 ohms within the frequency range of 75.0 khz to 1.0 Hite , This impedance is that measured iine-to-line at point A on figure 9.

4.5.2. 1.2.4 horse rejection. The terminal shall exhibit a maximum word error rate of one part in 10?, on all words received by the terminal , after validation checks as specified in 4.4, when operating in the presence of additive white Gaussian noise distributed over a bandwidth of 1.0 kHz to 4.0 MHz at an RMS amplitude of 140 mV. A word error shall include any fault which causes the message error bit to be set in the terminal’ s status ward , or one which causes a terminal to not respond to a valid command . The word error rate shall be measured with a 2. 1 V peak- to- peak , line-to-line , input to the terminal as measured at point A on figure 9. The noise tests shall be run continuously until , for a particular number of failures , the number of words received by the terminal , including both command and data words, exceeds the required number for acceptance of the terminal , or is less than the required number for rejection of the terminal , as specified in table II, All data words used in the tests shall contain random bit patterns. These bit patterns shall be unique for each data word in a message , and shall change randomly from message to message .

4. 5. 2. 2, 1 Terminal output characteristics . The following characteristics shall be measured with R _L , as shown on figure 12, equal to 35.0 ohms t 2.0 percent . measured using the test configuration shown on figure 12 , The terminal output voltage shall be within the range of 6.0 to 9.0 V, peak-to-peak , line-to -line , when measured at point A on figure 12. Table II terminal for the noise. rejection_test

TOTAL WORDS RECEIVED BY THE TERMINAL (in multiples of 10?) 4.5.2.2.1.2 Output waveform. The waveform,when measured at point A on figure 12, shall have aero crossing deviations which are equal to,or less than,25.0 ns from the ideal crossing point, measured with respect to the urevious zera · measured from levels of 10 to 90 percent of full waveform peak-to-peak, line-to-line,voltage as shown on figure 13. Any distortion of the waveform including overshoot and ringing shall not exceed ± 300.0 mV peak,line-to-line, as measured at point A on figure 12.

4.5.2.2.1.3 Output noise. Any noise transmitted when the terminal is receiving or has power removed, shall not exceed a value of 5.0 mV,RMS, line-to-line,as measured at point A on figure 12,

4.5.2.2.1.4 outoutsymmetry. From the time beginning 2.5us after the mid-bit crossing of the parity bit of the last word transmitted by a terminal, the maximum voltage at point A on figure 12, shall be no greater than + 90.0 mV peak,line-to-line. This shall be tested with the terminal transmitting the maximum number of words it is designed to transmit,up to 33. This test shall be run six times with each word in a contiguous block of words having the same bit pattern. The six word contents that shall be used are 8000 ₁₆ ,7FFF _16, 000016,FFFP16, 555516,and AAAA16. The output of the terminal shall be as specified in 4.5.2.2.1.1 and 4.5.2.2.1.2.

4.5.2.2.2 Terminalinputcharacteristics. The following characteristics shall be measured independently.

4.5.2.2.2.1 Incut waveform compatibility. The terminal shall be capable of receiving and operating with the incoming signals specified herein,and shall accept waveform varying from a square wave to a sine wave with a maximum zero crossing deviation from the ideal with respect to the previous zero crossing of plus or minus 150 ns, (i.e.,2.0 ± .15 μs 1.5 ± , 15 μs 1.0 ± .15μs

.5 ± .15 μs). The terminal shall respond to an input signal whose peak-to-peak amplitude, line-to-line, is within the range of 1.2 to 20.0 v. The terminal shall not respond fco an input signal whose peak-to-peak amplitude, line-to-line, is within the range of 0.0 to .28 V. The voltages are measured afc point A on figure 10.

4.5.2.2.2.2 Common mode rejections, Any signals from DC to 2.0 MHz,with amplitudes equal fco or less than + 10.0 V peak, line-to-ground,measured at point A on figure 10,shall not degrade the performance of the receiver.

4.5.2.2.2.3 Input impedance. The magnitude of the terminal input impedance, when the RT is not transmitting,or has power removed, shall be a minimum of 2000.0 ohms within the frequency range of 75.0 kHz to 1.0 MHz. This impedance is that measured llne-to-ltne at point A on figure 10.

4.5.2.2.2.4 Noise rejection. The terminal shall exhibit a maximum word error rate of one part in 107,on all words received by the terminal,after validation checks aa specified in 4.4, when operating in the presence of additive white Gaussian noise distributed over a bandwidth of 1.0 kHz to 4.0 MHz afc an BMS amplitude of 200 mV. A word error shall include any fault which causes the massage error bit to be set in the terminal's status word, or one which causes a terminal to not respond to a valid command. The word error rate shall be measured with a 3.0 V peak-to-peak,line-to-line, input to the terminal as measured at point A on figure 10. The notes tests shall be run continuously until , for a particular number of failures , the number of words received by the terminal , including both command and data words , exceeds the required number for acceptance of the terminal , or is less than the required number for rejec tion of the terminal , as specified in table II. All data words used in the tests shall contain random bit patterns . These bit patterns shall be unique for each data word in a message , and shall change randomly from message to message .

4.6 Redundant_data_bus_requirements . If redundant data buses are used , the requirements as specified in the following shall apply to those data buses ,

4.6. 1 Electrical isolation . All terminals shall have a minimum of 45 dB isolation between data buses . Isolation here means the ratio in db between the output voltage on the active data bus and the output voltage on the inactive data bus . This shall be measured using the test configuration specified in

4.5.2. 1. 1 or 4.5, 2. 2. 1 for each data bus . Each data bus shall be alternately activated with all measurements being taken at point A on figure 12 for each data bus .

4.6, 2 Single event failures . All data buses shall be routed to minimize the possibility that a single event failure to a data bus shall cause the loss of more than that particular data bus ,

4- 6.3 Sisal standby redundant data bus . If a dual redundant data bus is used , then it shall be a dual standby redundant data bus as specified in the following paragraphs .

4. 6. 3· 1 Data bus activity. Only one data bus oan be active at any given time except as specified in 4. 6. 3, 2,

4.6- 3- 2 Reset data bus transmitter . If while operating on a command , a term inal receives another valid command , from either data bus , it shall reset and respond to the new command on the data bus on which the new command is received . The terminal shall respond to the new command as specified in 4 - 3- 3. 8.

5. DETAIL REQUIREMENTS (Not Applicable) APPENDIX

10· General . 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 disc us sea .

10. 1 Redundaney . 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 , None the less , the system designer should utilize this standard as the needs of a particular application dictate . The use o f redundancy, the degree to which it is implemented , and the form which it takes must be determined on an individual appl ication basis . Figures 10. 1 and 10.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 .

10.2 Bus controller . 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 o f 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 in put /out put ( I/O) to inter face 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 protocol ' s 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 , and thus the software must oe written in such a manner as to permit modification with relative ease .

Figure 10,2

NOTE: RT - Remote Terminal

FIGURE 10,2 Illustration of possible redundancy. 10. 3 Multiplex selection criteria . 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 ana 3KKz 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) bub 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 .

10.4 High reliability requirements » 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 indicates 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 .

10.5 Stubbing. Stubbing is the method wherein a separate line is connected between the primary data bus line and a terminal . The direct connection of a stub line causes a mismatch which appears on the waveforms. This mismatch am be reduced by filtering at the receiver and by using bi-phase 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 methoa 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 mods 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 d irect 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. 10.6 Use of broadoast option . 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 broadoast . If system designers do choose to use the broadcast command , they should carefully consider the potential effects of a missed broadoast message , and the subsequent implications for fault or error recovery design in the remote terminals and bus controllers .

*U.S, GOVERNMENT PRINTING OFFICE: 1978 - 603-022/5017