Remote test equipment solves problems in avionics bus systems

June 24, 2008

Bill Schuh

Astronics (world headquarters)

A more cost-effective solution exists than sending an engineer thousands of miles for remote MIL-STD-1553 bus analysis.

For the manufacturer of a MIL-STD-1553 device or Line Replaceable Unit (LRU) - or any I/O for that matter - who receives a call from the field reporting a problem, the question is how to respond effectively. One way is to send an experienced engineer or technician on a plane along with a test instrument box and attendant diagnostic software to run diagnostics at the site. Another alternative would be to conduct testing remotely.

Although test equipment has been used remotely for some time, data bus analysis has traditionally been performed on location. Obviously no one wants to tie up an expensive engineer on a trip to run diagnostics upon arrival if there are less expensive alternatives that are equally effective.

Fortunately there are. Today, there are Avionics Data Bus Interfaces (ADBIs) that make it possible to perform all kinds of tasks on LRUs located tens of thousands of miles apart - as if all the LRUs were connected to the same Host test bench, as depicted in Figure 1.

Figure 1

(Click graphic to zoom by 2.2x)

1553 over Internet

In what we shall call Case I, depicted in Figure 2, it is assumed that one has developed code or has a commercial MIL-STD-1553 based, off-the-shelf LRU product to check out at a remote operating site. In this case, arrangements can be made to have that code run over the Internet. The entire application remains resident and runs on the test computer. However, the application program is talking to an ADBI, which is programmed to act as a 1553-Ethernet bridge controller over the Internet, via an Ethernet connection. The 1553-Ethernet bridge controller, in turn, is talking to the Unit Under Test (UUT). In this case, the remote LRU is the Remote Terminal (RT).

Figure 2

(Click graphic to zoom by 2.2x)

The diagnosis is orchestrated by an expert at the manufacturer's headquarters, who runs the diagnostic program and can dynamically introduce a series of new program functions as necessary, until the problem at the remote site is resolved.

Case II, depicted in Figure 3, is an arrangement that demonstrates the ability to run the diagnostic from a 1553-Ethernet bridge controller to another - one local, the other remote. Together, the two ADBIs form a bridge to the remotely located malfunctioning box at the operating site that may be tens of thousands of miles away. The two 1553-Ethernet bridge controllers interconnect to the Worldwide Web, via an Ethernet cable, a router box, or a wireless plug-in module, and are controlled by the test computer that enables the operator to perform the programming and diagnostic tasks - whatever the case may be.

Figure 3

(Click graphic to zoom by 2.2x)

Global diagnostics offer a multitude of cost-effective applications

The ADBI can be used to simply employ its Ethernet link. An example of this is where a customer has five LRUs in one building with its supporting ADBI and a 1553 Bus Controller (BC) with its ADBI in another building. The customer employs an Ethernet link between the two buildings. Another good fit is where an LRU under development is going to be at a site for a long period of time and it is impractical for the LRU to leave the site. With a Case II arrangement, command and control of the operating site can still be maintained by the BC residing at the test site, which may be far away from the operating site, via the Worldwide Web.

There may be a number of companies partnering in the development of a MIL-STD-1553 system. Perhaps they do not want to share their LRUs with anybody else - or cannot. The scenario would be as we have depicted in Figure 1. Of course, each ADBI can optionally have a host computer connected to it - or all the sites could be controlled by a single host computer.

In addition, a manufacturer, or perhaps an integrator, may have assigned to a subcontractor the task of developing software. The time then comes to test that software on the box. Instead of having the box shipped to the software company, the testing is simply performed over the Internet. Consequently, the Case II scenario becomes invaluable to anyone engaged in developing and testing in multiple locations - all through an ADBI.

In all the aforementioned cases, the global diagnostic solution offered a convenient and effective way to develop and test product while keeping expenses to a minimum. Linking via the Internet is far less costly than purchasing one or more LRUs for test or development purposes.

The distinction between Case I and Case II is this: Case I allows engineers to be more ad hoc - which is to say impromptu. A box could be shipped to the site, and someone with minimal skills could connect it, enabling tests to be run from the test computer. Case II, however, is more of a semi-permanent type of operation where the engineer is actually trying to extend the data bus around the world. In this case, it is more than likely specific code has been written that is running on the test computer.

Satisfying the BC

What is essential is that the Bus Controller (BC) is satisfied so that normal bus behavior is unimpeded. In compliance with the standard, the BC at the test site must receive a reply to any message it transmits within the 14-microsecond BC response time out. This usually requires that the ADBI at the test site mirror the MIL-STD-1553 bus at the operating site. By "mirror" we mean that the LRUs at the remote site must appear to the BC at the test site as if they are actually at the operating site. The reason is that the actual time for the data to make a roundtrip may be several seconds, or even more.

In addition to fulfilling the BC's requirements, the data itself might be in absolute time dependence. If this is true, compensation may be necessary. In this case, the responsibility falls upon the test program coordinator to orchestrate or account for any data time latencies that might be important to the LRUs. Figure 3 shows two ADBIs behaving as a bridge, so that the BC at the test site is served with data by the RT. This arrangement also ensures that the BC will be able to handle the extended propagation delays encountered by data packets traveling over the Worldwide Web, as depicted in Figure 4. As shown on the left side of the figure, the ADBI transmits and receives Internet data packets in a non-time-critical fashion while at the same time the 4- to 14-microsecond latency range of MIL-STD-1553 is accommodated (see right side of figure).

Figure 4

(Click graphic to zoom by 2.2x)

Dealing with stale data

If stale data is a concern, then the BC/RT and/or the ADBIs must be programmed to accommodate this. How the BC deals with arriving data can be handled in various ways. If a BC cannot live with stale data, there are several options:

• Every time something different is sent, the BC decides whether it is different. If the received data is not different, it simply discards it.
• Either the BC or the RT may embed a counter or a current time in the data message.
• Stale data could also be interpreted as the detection of a problem that could, in turn, set a console flag. To avoid an erroneous console flag, the ADBI program may slightly adjust a data word value so that an erroneous fault is not signaled.

In any event, the data transfers are going to be delayed in time. But if an engineer is running tests or non-time-correlated simulations, the engineer may not care.

Remote diagnostics save time and money

In a broader sense, the Case II situation establishes a worldwide MIL-STD-1553 network, enabling each vendor to participate in developmental and full functional testing of the interconnected LRUs within the avionics network. An example of an ADBI is Ballard Technology's OmniBusBox. Some of its powerful and unusual features include user-generated application code that resides in a host computer or within the box itself for BCs and/or RTs. Or, users can acquire industry software such as Ballard Technology's CoPilot, which can perform multiple roles as a simulator as well as an analyzer or diagnostic tool. This software provides many ad hoc capabilities and script resources to perform more custom procedures.

Finally, it is important to remember that the people at a remote operating site do not need to know anything about MIL-STD-1553. All they need to know is how to connect their LRU(s) to the ADBI.

Bill Schuh is vice president of sales at Ballard Technology. He is responsible for the identification and assessment of new strategic growth initiatives as well as the development of key customer accounts and programs. Bill brings more than 20 years of avionics management experience to Ballard, much of which has been in the avionics market. Prior to joining Ballard, he led military avionics product line development at Condor Engineering. He can be reached at [email protected].

Ballard Technology, Inc.
425-339-0281
www.ballardtech.com