This document discusses using C/C++ as a common software interface for test systems. It presents an example of using Matlab/Simulink to model and simulate a communication system, exporting the simulation to a C/ATLAS test program to test a low pass filter unit under test. Labview is then used to analyze and display the test results. The example demonstrates how a test program can utilize different software packages through a common C/C++ interface to expand testing capabilities beyond what could be done with C/ATLAS alone.

1. Using C/C++ as a Common Software Interface for Test Systems
Curtis F. Williams
Marine Corps Logistics Command
814 Radford Blvd.
Albany, Georgia 31704-0325
Phone: 229-639-8500, Email:curtis.williams@usmc.mil
Abstract - Test program developers are sometimes limited, by the
test environment, to writing a program that fully tests the unit
under test. If different software packages were included with the
test development environment, this limitation could be overcome.
A common language could be used as an interface for the different
software packages. Many commercial software packages are able
to translate to C/C++. The software packages could use C/C++
language as the common language. Any file, data, library, or
procedure imported or exported by a software environment could
be done as if were communicating with a C/C++ program. The
developer would then have a larger selection of tools to use; this
could help overcome the limits.
I. INTRODUCTION
This paper does not endorse any commercial software; it
does endorse giving a test program developer more software
tools. Matlab/Simulink and Labview are used along with
C/ATLAS, test environment, as an example. The example
will demonstrate the benefits of using different software
packages and the need of a common software interface.
A simple communication system example will be used to
demonstrate the benefits of using different software
packages. A test program is developed for a low pass filter
(UUT), which is part of a receiver. C/ATLAS test
environment will run on Marine Corps Third Echelon Test
Set (TETS). Modeling and simulating the system using
Matlab/Simulink aids the test developer in understanding
the UUT. The simulated stimulus of the UUT will be
exported to the C/ATLAS test development environment
and used to program the TETS arbitration generator. The
actual response of the UUT is analyzed and displayed by
code generated in Labview.
II. TEST SYSTEM
The test system that is used in this example is the Marine
Corps TETS tester. The arbitration generator and
oscilloscope will be the only instruments used. The
C/ATLAS test environment is used to develop the test
program, as illustrated in Fig. 1. The arbitration generator
applies the stimulus to the UUT. The arbitration generator is
programmed by using the signals from Matlab/Simulink
simulation. After the simulation is executed, the input to the
filter is exported from Matlab/Simulink as a text file
(stimFILE.txt). The C/ATLAS test program opens the
stimFILE.txt and loads the data into the array variable
‘stimDATA’. The APPY, WAVEFORM statement loads
the ‘stimDATA’ variable into the arbitration generator. The
stimulus is then applied to the low pass filter. The
“PERFORM, ‘Analysis’” statement calls the program
Analysis.exe, developed in Labview. The Labview program
includes the drivers for the TETS oscilloscope. The output
of the low pass filter is sampled by the oscilloscope. The
Labview software can also perform the analysis and display
the graphics. The results of the analysis can be passed back
to C/ATLAS by a text file.
Fig. 1. C/ATLAS test program
III. SIMULATION
Matlab/Simulink is used to model the system. The model
consists of a transmitter and receiver (Fig. 2). The analog
filter, UUT, is part of the receiver. The transmitter’s carrier
(20 KHz) is modulated by the message signal (500 Hz).
Noise is added to the transmitted signal, this simulates
environment interference. Demodulation occurs at the
receiver by multiplying the received signal by the 20 KHz
sine wave. At the output of the demodulator is a noisy 500
Hz signal. The unfiltered 500 Hz signal is exported
(stimeFILE.txt) to the C/ATLAS (APPLY,
WAVEFORM…) statement. It is used as the stimulus for
the UUT. Analog filter (UUT) will remove the noise. The
simulation results are displayed in Fig. 3.
Fig. 2. Matlab/Simulink Model
000001 BEGIN, ATLAS PROGRAM 'Example' $
INCLUDE, NON-ATLAS MODULE 'Analysis' $
DECLARE, VARIABLE, 'stimFILE' IS FILE OF TEXT $
DECLARE, VARIABLE, 'I' IS INTEGER $
DECLARE, VARIABLE,
'stimDATA' IS ARRAY (1 THRU 4096) OF
LONG DECIMAL $
E100000 OUTPUT,
C 'Using C/C++ as a Common Software Interface for Test
Systems' $
ENABLE, INPUT FROM C'stimFILE.txt', VIA 'stimFILE' $
FOR, 'I' = 1 THRU 4096, THEN $
INPUT, FROM ‘stimFILE’, INTO 'stimDATA'('I') $
END, FOR $
DISABLE, 'stimFILE' $
APPLY, WAVEFORM,
STIM 'stimDATA' (1 THRU 4096),
SAMPLE-SPACING 10 USEC,
TEST-EQUIP-IMP 1 MOHM,
CNX VIA ARB-Out $
PERFORM, 'Analysis' $
999999 TERMINATE, ATLAS PROGRAM 'Example' $

2. Fig. 3. Matlab/Simulink Signal Display
IV. ANALYSIS
Labview is used to perform the analysis and display the
low pass filter data. The Labview code is an executable
program called by C/ATLAS (PERFORM, 'Analysis'). The
Labview code contains the driver for the TETS
oscilloscope. The two channels of the oscilloscope measure
the input and output of the analog filter (UUT). The
Labview code can then perform an analysis of the data and
display the results in graphic form. The results of the
Labview analysis can be passed back to the C/ATLAS as a
report.
The Labview display is shown in figure Fig. 4. Notice
the stimulus is the same as shown in the unfiltered 500Hz
simulation in Fig. 3. The output from the filter corresponds
to the output of the filtered 500Hz of Fig. 3. Power
spectrum for the response signal is also part of the display.
Fig. 4. LabView Analysis display
V. CONCLUSION
The example demonstrates how a test program can be
developed using different software packages within a test
environment such as C/ATLAS. It would be difficult to
develop a program, even this simple, by just using
C/ATLAS alone. The ability to use different software
packages can significantly expand the capabilities of the
C/ATLAS test language and extend the life of legacy
testers. The different software packages would work better
together if they had a common interface. Using C/C++ is a
logical choice because of its popularity and wide spread use
as a programming language.
This paper also hints about the architecture of the Next
Generation testers. These testers should be capable of
utilizing many different software packages while hardware
capabilities, such as number of input/output channels,
should be expanded to interface with the software.