Test avionics devices to US military standards

-November 09, 2012

For more than three decades, MIL-STD-1553 has been widely used as the defense industry’s standard for data communications for various applications within aerospace and defense.  Core systems deploying it typically have to operate over the lifetime of the program, and are updated and enhanced as new technology becomes available and is adopted. This drives the test systems to also be retrofitted with updated equipment  to support these new designs. Many new programs still use MIL-STD-1553, and the new equipment must support this standard.  Due to natural progression of the test equipment, equipment manufacturers also need to keep pace with the latest technologies to support efficient and effective testing of the MIL-STD-1553 equipment.

Testing is typically executed in accordance with the MIL-STD-1553 test plans such as the industry standard SAE AS4111 to AS4114 for remote terminals and bus controller equipment.  These standards define all of the testing that must be performed for MIL-STD-1553 devices both during design verification and production testing.

Test Flexibility
The test documents define exactly what tests need to be performed, but they allow for multiple methods of implementation.  This gives the manufacturer many options of how to design and implement their test station.  In this article, we will discuss three basic methods of implementing the test systems to perform this testing, and explain the pros and cons of each.  These methods are manual, automated and integrated testing.  Since remote terminals (RTs) are a significant volume item that most companies will produce, we will use the RT Production Test Plan as our example.

AS4112 defines the electrical and protocol testing for production remote terminal devices that operate on a MIL-STD-1553 bus.  The standard defines the test setup, and the expected measurement values and limits, but it does not specifically dictate what equipment should be used, or how to create the conditions necessary to produce the results.  This allows the test engineer wide latitude in the design of test systems.  Test environments can range from totally manual with individual instruments to a fully automated, integrated approach.  The advantages of an automated system are accuracy, repeatability and speed.  As an example we will describe three scenarios.  The first being a manual test setup with separate instruments, the second being an automated version of the manual setup, and the last being an integrated “off-the-shelf” system running automated scripts to perform all testing.

Manual Test Method
The basic equipment necessary to perform the electrical testing is a bus controller (BC) or simulator, a digitizing oscilloscope and a computer, along with the properly connected remote terminal unit under test (UUT).  (The system configuration is shown in Figure 1.)  By invoking commands from the BC that produce the proper responses by the UUT, the user can then measure the electrical characteristics of the signals by adjusting the oscilloscope settings. Then, the measurement would be recorded and compared to the limits called out in the AS4112 document.  This same process would be repeated for each section in the document until all electrical tests are completed.

Figure 1: Manual test method system configuration.

One critical detail that demands careful attention is that the method of connecting the UUT to the bus differs dramatically than when using the remote terminal attached to an actual MIL-STD-1553 data bus. No bus couplers are used in this testing, making short lead lengths and grounding an important consideration in the design of the test system.  The goal is to capture, as accurately as possible, the signal levels at the bus terminals of the RT.  This also applies to any of the test configurations mentioned in this article.

To perform the protocol tests, the same setup is used, except the oscilloscope is replaced by a 1553 bus monitor.  For this set of tests, a series of commands are initiated and sent to the UUT, and the bus is monitored for the proper response from the UUT (or no response in some instances).  Again, the process is repeated for each of the protocol tests and the results recorded.

With the number of tests to be performed, it becomes obvious that this method requires little engineering effort up front but is very time consuming to perform the tests, record and analyze the results, and produce the final report.

Automated Test Approach
The second scenario includes all of the same hardware components as above, but adds a computer (as shown in Figure 2) with the capability of controlling the other instruments, either on the same backplane or through USB, Ethernet, GPIB, etc.  By learning the command sets of the different instruments and following the guidelines of the AS4112 test plan, designers can write software that automatically sends the commands, receives and interprets responses, and produces test reports.

The second approach can reduce the test time dramatically from the manual method, but it requires a substantial engineering effort to implement. The capabilities and instruction sets for multiple instruments from different vendors must be learned and code must be written to communicate with them. In addition, the AS4112 test plan must be reviewed and understood before the software can be written and debugged.  

The effort to implement this type of system is generally proportional to the amount of flexibility desired to add or change RTs with different addresses, capabilities, etc.  A more flexible approach will demand more engineering time to design user interfaces and design software that can be used on multiple devices.  Due to real world budgeting constraints, it is common for these types of systems to become more or less “hardcoded” and dedicated to one particular RT type.

Figure 2: An integrated test solution showing MIL-STD-1553 modules with the digital scope option and PBA.pro advanced simulation and analysis software from AIM GmbH.

>>Integrated Test Solution
Next: Title-1

Loading comments...

Write a Comment

To comment please Log In