Field testing and troubleshooting of military equipment are critical for combat readiness. However, this requires that test systems be rugged and portable. Equipment that normally could be used inside a laboratory might not meet the environmental or size requirements for field testing. The need to minimize test time and test errors also is magnified for field testing vs. testing in a laboratory environment.
G Systems recently redesigned and built an automated console and simulation unit (CSU) for Lockheed Martin Missiles and Fire Control. The CSU is a component of the U.S. Army’s Multiple Launch Rocket System (MLRS) Soldier-Portable Test Program Set (MST). The MST can field test individual line replaceable units (LRUs) of the MLRS system without requiring them to be installed in the entire system.
The MST hardware has two main components: the CSU and a MST controller. The CSU provides the input power, loads, and communications paths for each of the LRUs to be tested. The MST controller is a laptop with software for interfacing to the CSU (Figure 1 ).
Figure 1. CSU Portable Test Instrument
Lockheed Martin’s previous system required a great deal of operator interaction to perform the unit-test and self-test procedures. Specifically, the operator was instructed to manually switch relays and use a hand-held DMM to measure analog signals, connect shorting plugs, and record results during self-test.
The new system reduces the amount of operator interaction. Instead of requiring the operator to switch relays, the software controls the switching through two digital outputs to create an I2C 2-wire bus for communicating to digital input/output devices. Rather than using a hand-held DMM, the software collects/stores the analog reading through a data acquisition (DAQ) module. The external shorting plugs are replaced by self-contained wrapped-back wiring, and self-test results are automatically logged to file.
Hardware
The CSU consists of ruggedized commercial-off-the-shelf (COTS) hardware and custom hardware from G Systems.
COTS
The brain of the system is an embedded real-time processor, the National Instruments (NI) CompactRIO (cRIO) Real-Time Controller. The DAQ hardware utilizes an FPGA chip embedded in the NI cRIO hardware. Inserted inside the chassis are removable analog input and digital input/output modules along with the removable cRIO real-time controller. The cRIO platform was chosen because of its extreme environmental ratings of -40 to 70°C and 50g shock rating, compact size, and flexibility of programming.
Figure 2. System Diagram
The CSU acts like a custom test and measurement instrument that can communicate to an MST controller through an Ethernet connection (Figure 2). Specifically, the CSU has two standard RJ-45 ports allowing up to two MST controllers to be connected to the CSU. Several of the LRUs have one or multiple static IP addresses. Since the LRUs are military devices, the Ethernet wiring is bundled into several unique MIL-Spec cables/connectors rather than being part of a standard RJ-45 port.
For the MST controllers to connect to the static IP addresses on the individual LRUs, the CSU serves as a router. Inside the CSU is an industrial-rated, managed Ethernet switch that allows the CSU to programmatically enable and disable individual Ethernet ports. To test all the Ethernet ports on the LRUs, the MST controller enables one Ethernet port at a time via the CSU commands and pings each IP address to verify proper communications to the LRU.
An Ethernet self-test is performed to verify the CSU communications path before testing the LRU communications path. During an Ethernet self-test, the real-time embedded controller enables one Ethernet port at a time and attempts to connect to the industrial frame grabber to verify the entire communications path is present and working properly.
The hardware for the CSU is housed inside a custom industrial metal chassis. The metal chassis then is mounted inside a thick industrial-grade plastic case that protects the interior hardware. To increase the unit’s portability, the plastic case also has built-in wheels and a pull-handle.
Custom Hardware
Along with the COTS components, the CSU consists of custom hardware elements. The CSU has three PCBs designed by G Systems that serve essential purposes for the CSU: analog signal conditioning, custom digital communications, and self-test.
Several of the LRUs have voltage levels that are measured by the CSU. For the voltage levels to be read properly by the DAQ module, many of the signal levels are attenuated by the signal conditioning circuitry on the PCB.
To test several of the LRUs, test points are switched by a scalable G Systems design utilizing I2C 2-wire digital serial technology. The data line and clock lines—the 2-wire I2C bus—are generated and monitored by using only two digital output lines and one digital input line on the cRIO digital module. One 2-wire I2C bus can communicate to up to 16 I2C digital input/output chips that theoretically would provide up to 448 input/output lines (see sidebar at end of article ).
The CSU is designed for worldwide power usage. The previous CSU required an external transformer to handle a range of power sources. The redesigned CSU operates from 20 to 32 VDC, 90 to 132 VAC, or 185 to 260 VAC without external hardware. The same MIL-Spec connector can be connected to either a DC or AC supply, and the power supply protects against reverse polarity and transients spikes in the DC source.
Software
The software architecture design is modular and flexible to allow for remote control and monitoring of the portable CSU from the customer’s software application running on the MST controller.
One of the main goals for this redesign was the automation of the hardware control and monitor. This is made possible by the custom software running inside the CSU.
There are two software applications running on the cRIO written by G Systems in NI’s LabVIEW. The LabVIEW Real-Time custom software application automatically starts when power is applied to the CSU. This application handles the CSU’s logic including self-test procedures, datalogging, TCP/IP communications to the laptop, RS-232 communications to the Ethernet managed switch, a custom instrument driver that performs the chip-specific and high-level commands for the I2C digital chips, and communications to the LabVIEW FPGA application.
The reconfigurable hardware or FPGA code is written using LabVIEW FPGA and compiled into VHDL code that runs on a FPGA chip in the cRIO chassis. The LabVIEW FPGA application defines the low-level analog acquisition, RS-422 serial receive and transmit lines, and the low-level clock signals and data lines needed for the I2C bus implementation.
One key feature that allows the CSU to function like a custom instrument is a defined command set or application programming interface (API) in the form of a dynamic linked library (DLL), which has the added capability of being called from many programming languages. The DLL was written in Visual Studio C++.
Lockheed Martin’s test software application has remote access and control of the CSU by linking to this DLL. The DLL handles all the TCP/IP communications, freeing the customer from worrying about the TCP/IP implementation under the hood.
The DLL was defined and the CSU software simulator developed before the hardware was completed. This allowed Lockheed to perform parallel development on its software integration of the DLL into the MST controller software while the hardware was being designed and developed by G Systems.
For each self-test step, the CSU performs a hardware action, compares the result to the specifications, and assigns a pass or fail to that step. Some of the specification values are programmatically determined, and others are listed explicitly in the self-test configuration files. The self-test configuration files are stored locally on the CSU.
When the LabVIEW Real-Time application starts, the self-test configuration files are loaded into memory, which allows the self-test code to be modular and flexible. For each option or file, the LabVIEW Real-Time application parses the optional information loaded into memory at start-up and determines which hardware actions to perform.
The self-test options can be executed at any time and in any order. The DLL has a set of commands for performing self-test. The commands allow the customer’s software application to define which options will be performed and documented in a self-test report generated by the CSU. This report is saved locally on the CSU, but the DLL has a command for transferring any report file to the MST controller via file transfer protocol (FTP). To save hard drive space on the CSU, old files are automatically deleted when the number of files saved exceeds a user-defined number.
Along with the CSU software applications and DLL, two additional software applications are provided to assist in debugging and monitoring the CSU: the CSU tester software and the G Systems Event Tracker, a reusable software service. The CSU tester software is a Visual Studio C++ application written by G Systems that can be installed on the MST controller. It has a custom GUI that allows the user to exercise and test every command available in the DLL.
The CSU software generates string status or event messages throughout the code, for example, the start or completion of software tasks. Those string messages are sent out through user datagram protocol (UDP) to the MST controller.
Then the Event Tracker service installed on the MST controller intercepts those UDP messages. The messages are timestamped down to millisecond resolution, logged to file, and can be displayed as live event messages using the Event Viewer application or incorporated into a custom application using the Event Viewer control.
Environmental Testing
The CSU was tested and verified for the shock, vibration, temperature, and humidity ranges it might experience being transported in a Humvee in varying climates and temperatures throughout the world.
The CSU was placed on a shaker table to verify it met the vibration requirements in accordance with MIL-STD-810E. The vibration profile was repeated three times for each axis of rotation for 40 minutes per axis. After each axis was completed, the unit was inspected for damage, and a self-test was performed. A drop test also was performed to simulate shock caused by field handling.
The CSU was placed in a temperature chamber to verify it met the temperature and humidity requirements in accordance with MIL-PRF-28800F. The temperature was cycled from -40°C to 70°C. During the temperature cycle, an operator completed the self-test five times to verify proper functioning of the system. The CSU also experienced a five-day humidity profile ranging from 45% to 95% humidity and 30°C to 50°C. To ensure the system was functioning properly during this humidity cycle, the system had to pass the self-test three times.
Conclusion
G Systems’ new automated CSU is a rugged, portable test instrument that reduces overall test time through automation and eliminates unnecessary operator tasks. Overall test times have been improved by a factor of five. This was accomplished by integrating COTS and in-house designed components into a rugged and portable package.
The software and hardware were designed to be flexible and robust. The software allows for ease of integration into the customer’s application. The hardware withstands the harsh environmental conditions experienced from rapid worldwide deployment.
About the Author
Russell Blake is an engineering team leader at G Systems and has served in various engineering roles since 2005. Previously, he worked at National Instruments after graduating from the University of Texas/Austin with a B.S. in electrical engineering. He is a Certified LabVIEW Architect and a NI Certified Professional Instructor with more than 10 years of test and measurement and data acquisition experience. 972-234-6000, [email protected]