The MST hardware has two main hardware components, the CSU and a MST Controller. The CSU provides the input power, loads, and communication paths for each of the LRUs to be tested. The MST Controller is a laptop with software for interfacing to the CSU. (See Figure 2)

Figure 1: CSU Portable Test Instrument

Figure 2: System Diagram

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, use a handheld digital multimeter (DMM) to measure analog signals, connect shorting plugs, and record results during self test.

The new system greatly 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 handheld 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 can be thought of as a rugged custom test and measurement instrument consisting of ruggedized Commercial-Off-the-Shelf (COTS) hardware and G System’s designed custom hardware.

COTS

The brain of the system is an embedded real time processor, National Instruments CompactRIO real-time controller. The data acquisition hardware utilizes an FPGA chip embedded in the National Instruments CompactRIO hardware. Inserted inside the chassis are removable analog input and digital input/output modules along with the removable CompactRIO real time controller. The CompactRIO platform was chosen because of its extreme environmental ratings: -40 to 70 degrees Celsius and 50 g shock rating, its compact size, and flexibility of programming.

The CSU acts like a custom test and measurement instrument that can communicate to an MST Controller through an Ethernet connection. Specifically, the CSU has two standard RJ-45 ports allowing up to 2 MST Controllers to be connected to the CSU. Several of the LRUs have one or multiple static IP addresses.

Since the LRUs are rugged military devices, the Ethernet wiring is bundled into several unique MIL-spec cables/connectors rather than being part of a standard RJ-45 port. Therefore in order 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 which 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 communication to the LRU. An Ethernet self test is performed in order to verify the CSU communication path before testing the LRU communication 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 communication path is present and working properly.

The hardware for the CSU is housed inside a custom industrial metal chassis. The metal chassis is then mounted inside a thick industrial grade plastic case, which protects the interior hardware. The plastic case also has built in wheels and a pull handle similar to airport style luggage to increase the unit’s portability.

Custom Hardware

Along with the rugged COTS components the CSU also consists of custom hardware elements. The CSU has three printed circuit boards (PCB) designed by G Systems which serve three 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. In order 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 and cost effective G Systems design utilizing I2C 2-wire digital serial technology. The data line and clock lines (i.e. the 2-wire I2C bus) are generated and monitored by using only 2 digital output lines and one digital input line on the CompactRIO digital module. One 2-wire I2C bus can communicate to up to 16 I2C digital input/output chips which theoretically would provide up to 448 input /output lines.

The CSU is designed for worldwide power usage. The previous CSU required an external transformer to handle a range of power sources. However 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 CompactRIO written by G Systems in a programming language called National Instruments LabVIEW. The LabVIEW Real-Time custom software application automatically starts running when power is applied to the CSU.

This application handles the CSU’s logic including self test procedures, data logging, 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 API in the form of a dynamic linked library (DLL), which has the added benefit of being able to be 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 was developed before the hardware was completed. This allowed Lockheed to perform parallel development on their software integration of the DLL into their 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 either 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 over to the MST Controller via File Transfer Protocol (FTP). In order to save hard drive space on the CSU, old files are automatically deleted when the number of files saved exceeds a user defined maximum number of files.

Along with the CSU software applications and DLL, G Systems also provided two additional software applications to assist in debugging and monitoring of the CSU: CSU tester software and the G Systems Event Tracker. The CSU tester software is a Visual Studio C++ application written by G Systems which can be installed on the MST Controller. The CSU tester software has a custom Graphical User Interface (GUI) which allows the user to exercise and test every command available in the DLL.

G Systems designed a reusable and efficient software service called the G Systems Event Tracker. 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 then sent out through User Datagram Protocol (UDP) to the MST Controller. Then Event Tracker service installed on the MST Controller intercepts those UDP messages. The messages are then time stamped down to millisecond resolution, logged to file, and can be displayed as live event messages using the G Systems Event Viewer application or can be incorporated into a custom application using the G Systems 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 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 was also 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 between -40 to 70 degrees Celsius. During the temperature cycle an operator completed the self test 5 different 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 to 50 degrees Celsius. To ensure the system was functioning properly during this humidity cycle, the system had to pass the self test three different times.