How VXI Is Impacting MIL-STD-1553 Testing

The MIL-STD-1553 avionics bus, around since the 1970s, is a local area network originally developed for military vehicle applications. The standard defines how an operational bus is supposed to work with real avionics hardware. It specifies interface and protocol requirements, but not system-level test requirements. Although a Remote-Terminal (RT) Validation Test Plan has been defined, it only verifies a singular unit interface and does not provide a reference for verification of system operation.

With the unique architecture of the bus and its protocol, 1553 test equipment has evolved dramatically over the years and continues to change as computers evolve. While the MIL-STD-1553 bus is a Society of Automotive Engineers (SAE) standard, 1553 test equipment and interfaces are not.

A Brief History

In the early days, engineers could only test 1553 designs by building test boards using the same protocol chips used in the design. This presented some problems:

Engineers spent time designing and debugging test equipment.

The protocol chips were not designed for error injection and detailed error detection or analysis.

The chips did not emulate more than one 1553 device at a time.

A market soon developed for a dedicated 1553 bus analyzer, essentially a logic analyzer that allowed engineers to analyze 1553 hardware and electrical characteristics. These systems were relatively easy to set up and use, and detected and analyzed a variety of bus problems. They could also inject electrical and protocol errors into the bus traffic to see how the system would handle these problems in the real world.

These products were limited in other ways:

They were expensive, typically $25,000 to $40,000+.

They usually could interface to only one redundant bus at a time.

They took up much space, especially when installed into rack-and-stack test systems.

They could not emulate an entire 1553 network in real time and did not have standard interfaces for computer systems of the day (DEC VAX).

So another type of 1553 interface was born—real-time computer interfaces. These products, developed at Wright-Patterson AFB in Dayton, Ohio, used embedded processors and custom microcode to emulate the equivalent of 33 protocol chips (one bus controller (BC), 31 RTs and one bus monitor (BM). They allowed software system engineers to write and debug avionics system software before or concurrently with hardware development. These products were also capable of protocol and electrical error injection.

By the late 1980s, there were many different, noncompatible 1553 VXI test solutions available. These included:

Bus analyzers programmed with ASCII commands via the IEEE bus.

Message-based VXI boards with custom ASICs and discrete 1553 interface hardware.

Message-based VXI boards with standard 1553 protocol chips and operational 1553 interface hardware (transceivers).

It was—and is to this day—common for large aerospace companies to have more than one type of 1553 test hardware in different departments, depending on the test requirements of each area. In fact, situations occurred where a design developed using one type of 1553 test equipment would fail when tested in production by another type of 1553 test equipment.

Simulation and Test Markets Merge

In the early 1990s, as electronics technology became more powerful and compact, several trends in the 1553 VXI test market emerged:

Open architectures became common for computer systems, ISA/EISA for PCs and VME for real-time simulation I/O.

A need arose to standardize the application program interfaces for VXI modules for the most popular graphical user software packages like HP VEE, LabVIEW and LabWindows/CVI.

1553 test equipment became single boards or modules, leading to the demise of the stand-alone bus analyzer market.

But the problem was and still is that one vendor’s 1553 interfaces might have been developed for one type of application, such as system simulation, while another company’s products were developed for a different application. As a result, many 1553 interfaces are on the market today with different features, different data structures, different software interfaces and different levels and types of software support.

This is even true of different products from the same vendor. For instance, 1553 cards developed for the simulation market are only register-based and direct-memory accessed. While these cards require programming at a more primitive level, they are the fastest real-time 1553 boards, offering on-the-fly reading and writing of data to and from the interface.

Other boards, having evolved out of the test market, are message-based. While there are standard SCPI commands for simple instruments such as DMMs and DVMs, there has never been a standard software interface for 1553 devices. Consequently, every 1553 interface, having unique capabilities and data structures, must also have its own software interface.

System-Level Testing Today

Despite all of this, there are some general things that can be said about 1553 testing and test equipment. All 1553 interfaces provide the three basic functions: they can act as a BC, emulate one or more RTs or capture all bus traffic as a BM. Basically, there are two types of 1553 interfaces on the market. One type uses the same protocol chip that is in avionics equipment. The other type uses custom microcode or ASICs in place of the protocol chip.

Protocol-chip-based boards are often called single-function boards and can act as a BC, emulate a single RT or record all bus traffic as a BM. Only one function or mode can operate at a time. They also only generate valid bus traffic.

These boards can be used in test applications where valid bus traffic stimulates a UUT, for example, for subsystem testing. This is shown in Figure 1. Note that the host interface for I/O can be PC, VME or VXI/MXI.

Figure 1 shows three possible test scenarios. In the first scenario, the host computer generates valid 1553 bus traffic to the UUT. The UUT analyzes the data and responds accordingly on the 1553 bus. The host computer acquires the returned information and takes appropriate action.

In the second scenario, the host computer sends 1553 messages to the UUT, causing it to output some analog, digital or synchro signals. These signals are then captured via analog, digital or synchro I/O devices, which input the information into the host computer for analysis and comparison to expected values.

In the third scenario, the opposite approach to the second situation is taken. The I/O signals are generated by the host computer to stimulate the UUT. The UUT is then polled by the host computer via the 1553 bus to see if it properly acquired and interpreted the signals. In all three test scenarios, a single-function 1553 board, usually acting as a BC (assuming that the UUT is an RT), is sufficient.

There are single-function, microcode-based products available on the market that use the same microcode as their multifunction counterparts. This provides two significant benefits over protocol-chip-based products:

Since they use the same microcode as multifunction boards, all products share a common software interface. This means users are not locked into one product family.

The microcode, having been developed for test and system simulation applications, is more robust in each mode than protocol-chip-based designs.

Some avionics subsystems or RTs operate in an environment where they must communicate with one or more other RTs via RT-to-RT transfers. To simulate this in the test lab where there is only a host computer and the UUT, use a 1553 board that can simulate the BC and one or more RTs at the same time. This is an example of the use of a multifunction or microcode-based 1553 board.

Some 1553 interfaces, when acting as a BC, do not make a copy of the data sent between RTs during an RT-to-RT transfer (Figure 2). A BC only checks the status words of the two RTs to ensure that the transmission completed successfully. In the lab, if the user acting as a BC wishes to see a copy of the data transferred, then the application requires either a 1553 card that can capture RT-to-RT traffic in the BC mode or a multifunction card that can act as a BC and BM simultaneously.

Testing Invalid Traffic

The preceding examples show various test applications where it is assumed that the 1553 interface in the UUT is operating correctly and the UUT is only responding to valid bus traffic. In other test applications, it is necessary either to verify the 1553 interface circuitry in the avionics hardware under test or to confirm its capability to handle erroneous bus traffic.

In these cases, the test engineer needs a 1553 interface that does not rely on a standard 1553 protocol chip. Only microcode or ASIC-based 1553 modules can inject protocol and electrical errors into the bus traffic.

Some multifunction cards use standard 1553 transceivers to perform the electrical input/output function. These boards will have some capability to inject protocol errors such as wrong parity, long and short words or wrong word count. However, they will not inject electrical errors such as zero crossing deviations, variable output voltages or programmable input threshold settings.

Other cards have both sets of features. Picking the correct card for your application requires knowledge of what kinds of tests need to be performed and verification of the products from each vendor for those features. In these cases, the test scenarios shown in Figures 1 and 2 still apply, but the test data being sent over the 1553 bus is different.

The 1553 modules have varying degrees of error detection and analysis capabilities. Protocol-chip-based single-function boards operating in the BM mode will act just like a flight data recorder. They record all bus traffic. A flag will be set for any message containing an error.

Usually, all types of message errors are lumped together in this one flag and no further analysis is possible. Multifunction boards often offer more detailed analysis, but this also varies from manufacturer to manufacturer.

Conclusion

MIL-STD-1553 test equipment in general, and VXI 1553 test equipment in particular, has undergone a significant evolution since the days of stand-alone bus analyzers. Open architectures have allowed the board-level 1553 interface and test products to proliferate, especially in the PC/ISA, VME and VXI areas.

Today there are many vendors of 1553 test products. Some companies offer

protocol-chip-based single-function products that generate only valid bus traffic. Others offer multifunction products based on microcoded designs that provide added functionality, including error injection and sophisticated error detection.

Product selection must be based on simulation and test requirements and on the programming-interface methodology. Most of these products maintain unique programming interfaces, although certain advantages may be realized by using microcode-based single-function products that share a common software architecture with their multifunction counterparts and provide extended functionality in each mode.

About the Authors

Steve Guentner is the 1553 and Industry Pack product marketing specialist for Systran. Before Systran acquired Digital Technology, he spent 10 years at DTI in sales and marketing. He has also been a sales engineer for Interface Technology and holds B.S. and B.S.E.E. degrees from the University of Maryland. Systran, 4126 Linden Ave., Dayton, OH 45432-3068, (937) 252-5601.

Jerrold V. Birbal spent three years at Digital Technology as director of engineering. He has an M.S. degree from Wright State University in Computer Engineering.

December 1996