10 tips for developing and using avionics test sets

If you purchase commercial and military avionics test sets, you probably want what customers have always wanted: more module and line-replaceable-unit (LRU) testing capability and better diagnostics at less cost in less space. In addition, you need commercial avionics test sets that meet all current FAA requirements and are easily upgradeable to meet all proposed FAA requirements.

Mission-specific military avionics test sets are expected to be as flexible and portable as the multi-mission aircraft and weapons systems they support. Mission goals change rapidly, and test sets also must often change to help manufacturers meet these goals. Without flexible avionics test sets, the ground support crew would wind up with many different test sets or work-arounds, adding substantially to the workload and to the support costs.

You can keep those additional costs to a minimum by following these basic tips when purchasing your test equipment:

Identify and categorize all test requirements down to the pin level, including writing a preliminary automatic test procedure for each unit under test (UUT). Specify instruments with the range and accuracy you need today with a sizable margin. Instrument performance, accuracy, and stability can degrade over time, and if you initially purchase an instrument that just barely meets the requirements, you may later see an increase in repair incidents and costs, and may need to perform calibrations more frequently.

Check with UUT equipment manufacturers to see what improved specifications they're planning for the next generation of instruments. Buying test instruments today to meet the planned capabilities of tomorrow will save you plenty of time and money. Also, be careful not to confuse accuracy and resolution requirements.

Since many measurements require transducers, specify a known-good transducer or transducer emulator. The known-good transducer will let you quickly check out test-set operation and isolate problems should they occur. Include a transducer emulator for digital signals as well as analog signals.

It is better to have a test set that can do several things well than one that is awful at everything. Using your comprehensive set of test requirements (from step 1) as a guide, you should develop a system that comfortably performs both present and planned requirements. If incorporating a second set of requirements significantly increases complexity and makes the test set less user friendly, you may need to develop a second test set.

By using a modular platform such as PXI for your test sets, you can simplify development for future test sets. With a modular system, you can quickly reconfigure a test set for a different application, and you can add hardware later if usage justifies a dedicated test set.

Before you decide to build a test set, ask a system integrator to give you a bid based upon your test requirements. A system integrator will evaluate the feasibility of your test specifications and let you know if they are realistic. Finding out that your specifications are unrealistic—technically or economically—early in a project can help you avoid expensive mistakes. A system integrator also may save you thousands of dollars by choosing instruments that more closely match your test requirements, which may mean that you won't need to buy as much equipment.

Evaluate the available platforms and buses. Where possible, use commercial off-the-shelf (COTS) boards and modules. Unless there is a compelling reason to do otherwise, choose a bus that is vibrant and is supported by multiple vendors—it is more likely to be there in the future when you need to purchase upgrades, expand, or get support.

Also, keep an eye on technology. Microprocessors are doubling in speed every few years, so you'll want to choose a bus that will support new processors as they become available.

The instruments you use in your avionics test set—be they cards, modules, or boxes—should be interchangeable in the field. This capability reduces repair times and lets you reconfigure your test set, adding capabilities and test functions. This could save you thousands of dollars by allowing you to use older test sets for new test applications.

While it is often desirable to have a portable test set, portable test sets are less flexible and more expensive than fixed test sets. Traditionally, portable test sets use custom-designed instrumentation to make them as small as possible. Remember, though, that it is more expensive to design miniaturized instrumentation than it is to use COTS cards and modules in a rack-mount or desktop configuration. If you decide you do need a portable test set, you might be able to forgo a custom system in favor of a PXI-based system that can easily be moved among locations.

Often, a compromise is possible. It is now possible to design a compact, lightweight, small footprint test set that can be easily relocated using PXI instrumentation. PXI systems are available in both battery-powered and line-powered versions that you can move from location to location.

Choosing the right test software for your avionics test set will reduce initial development costs and make test program maintenance simpler and improve technician productivity, thereby reducing ongoing costs. Your test program will be more maintainable if you create thorough documentation. The documentation should describe program, module, and procedure flows clearly enough for a programmer to figure out what is supposed to happen.

The documentation has to include more than just the source code, though. Make sure it explains the function of each module and procedure and how they all fit together.

You can also ensure your software is maintainable by

• writing understandable diagnostic messages that are intended for technicians and not computer scientists,
• including security features that allow authorized maintenance while preventing unauthorized changes to the automatic test procedures, and
• using a test executive that allows you to step through a test program and find out what's happening at any level.

Figure 1 Specifying robust connectors for UUT interfaces will make your tests more reliable, saving both time and money.

Trying to save money by specifying inexpensive connectors or interface adapters (Figure 1) is a poor strategy. Doing so will result in intermittent connections, and replacing the connectors as they fail will cost you many times the value of the entire system over the life of the test set. Buy the best connectors and adapters you can afford.

A technician should be able to control the instruments and switch matrix and also validate faults in the test set, including both hard failures and intermittent failures. The technician will need system diagnostics, self-test (loop-back), and other hardware and software diagnostic features to detect and diagnose failures in the test adapter, test cables and connectors, and installed instruments.

In addition to validating the functionality of the UUT, the test program should enable technicians to diagnose UUT faults. Making it easier for technicians to repair a UUT will reduce the cost of repair dramatically.

One way to do this is to use a test executive that lets test technicians manipulate the test set's virtual instruments as they would a handheld or benchtop instrument. Giving them the functionality of a DMM, benchtop power supply, or oscilloscope gives them the tools they need to find UUT problems.

In addition, the test executive should include features such as loop on fail, step over test, repeat test, and pause on fail. You may also want to give the technician the ability to check the program source code and see the values of variables, counters, and measurement results, all of which will aid in fault diagnosis. Imagine a technician having to re-run an unalterable, 6-min long, compiled program several times to get a scope to trigger during the next-to-last test-program step.

Finally, make sure the system software has a versatile set of technician-accessible tools for diagnosing faults. Relying on the skill of a test technician to write programs to diagnose faults will yield mixed results at best.