Developing Engine Test Software in LabVIEWB

Russ Turley, Matthew Wright

CACI
San Antonio, TX 78228 USA
Phone (210) 735-1903 Fax (210) 734-8872
E-Mail rturley@hq.caci.com mwright@hq.caci.com

Abstract
CACI International Inc. is on contract with SAALC/LDAD, the Air Force engine tester program management
office, to build an Engine TesVTrim Automated System I1
(ETTAS 11) using Commercial Off The Shelf (COTS) hardware
and software. This tester will ultimately replace the three
aircraft engine test systems currently used by the Air Force, all
of which are becoming increasingly difficult to maintain due to
hardware/softwareobsolescence problems. In keeping with the
COTS requirement, we chose to develop our data acquisition
and test program software in LabVIEWO 4.0.1 for Windows@
NT/95.
This paper discusses the advantages we have gained in using
LabVIECVk3 4.0.1, a graphical programming language, rather
than a #conventionalprogramming language as our software
develop,mentenvironment We detail how we were able to take
advantqge of LabVIEWO's instrument control capabilities to
optimize! our Wl data acquisition process. We then discuss
how LabVlWO can be used not only as an instrument control
language, but also as a general purpose programming
language. We discuss how we used LabVIEWk3 for test program
set (TPS) development and for rapidly prototyping user
interfaces
and
program
features
for
immediate
operator/customer feedback. The paper also details how
LabVIEWO enabled us to readily establish a core of "generic"
Vls (virtual instruments) for subsequent reuse in developing
additional TPS for other aircraft engine types/variants.

I. INTRODUCTION.
The Engine Test/Trim Automated System II (ETTAS II)
is a new aircraft engine test system which will replace
the Air Force's three major aircraft engine testers, all of
which are encountering reliability and maintainability
problerns partially due to software limitations imposed
by out-.of-date and proprietary software environments.
The ETTAS II software was required to be Commercial
Off The Shelf (COTS) and to provide at least the same
functionality as the existing test systems' software. The
software was also required to be developed using
object-oriented programming techniques, with code
reuse as a design objective. Additional goals were for
the software to be menu driven and feature a graphical
user interface,

0-7803-4162-7/97$5.00 0 1997 IEEE

575

Given the stated software requirements and objectives,

as well as the additional requirement to control VXI
instruments, we chose LabVlEW 4.0.1 for Windows NT
as our software development environment. LabVlEW is
a graphical programming language perhaps best
known for its instrumentation control capabilities.
However, using LabVlEW not only enabled us to
optimize the VXI instrument control and data
acquisition process, but also allowed us to gain several
advantages throughout the software development
effort. The ETTAS II software consists of the instrument
control and data acquisition program and the enginespecific TPS, as well as a self-test program and a
calibration program,. All of these programs were
written in LabVlEW rather than in a conventional
programming language.
LabVlEW's graphical programming environment has
several features that allow the developer to easily
create engine test software. Among these features are
the fact that LabVlEW programs do not have to be
compiled into executables prior to running, LabVlEW
contains functions analogous to operators or library
functions in conventional languages that are readily
implemented by "point and click" with a mouse, and
LabVlEW programs are created by wiring graphical
objects together in block diagrams to perform various
actions rather than writing text-based programs.

II. OPTIMIZING THE VXI ICDA

The Instrument Control and Data Acquisition (ICDA)
portion of the system software is set up to run
independent of the TPS. The ICDA, loaded on the
embedded computer, continuously acquires data from
measurement instruments, and updates values sent to
stimulus instruments based on data sent from the TPS.
This is achieved through the use of shared memory.
On the embedded computer, a portion of system RAM

is reserved for use as VXI shared memory. After bootup, the ICDA software writes certain information about
itself to shared memory. For example, the number of
channels of each signal type (analogs, discretes, etc. ..)
that the system has is written to shared memory.
When first loaded, the TPS reads in this data and
determines which shared memory addresses to read to
retrieve data. The TPS, in turn, lets the ICDA software
know what voltages, temperatures, etc., to send out by
writing the requested value to certain pre-determined
areas of shared memory. The ICDA then does the
rest, sending the appropriate command to the proper
instrument. In this way, the TPS never has to know
what instrument is being used, or even what command
is being sent. Should an instrument ever become
obsolete, and a new instrument is used, the system
software would be updated with the appropriate
command set for the new instrument, but the TPS
would not have to be modified. This sets up a layer of
hardware independence between the TPS and the
system itself, and does it in a way that does not
sacrifice TPS performance. Also, since it is literally a
physical separation, it does not require the TPS
developer to expend any additional effort at ensuring
the TPS is indeed hardware independent.

can be positioned and resized by dragging with the

mouse. Various layouts can be readily created by
merely repositioning the controls and indicators with the
mouse. Additionally, features such as pop-up menus
and alarm messages can be created and tried out
quickly since LabVlEW programs do not have to be
compiled into executables prior to running.
Once we had established what we considered a good
starting point for the GUI, we presented it to our
customer and to users of the existing engine testers.
The menu buttons, indicators, and controls were made
to appear operational through the use of "dummy" data.
The users were able to select menu items, push
buttons, turn knobs, and otherwise use the interface
just as if it were connected to the actual ETTAS II. We
were able to get feedback from the users and
immediately make changes based on their comments
while they watched. This was a very effective method
for obtaining "buy-in" by all the relevant parties, since it
gave the users a real voice in the development process
rather than having a new system foisted upon them.

As mentioned, the ICDA software will send commands

to output instruments as well, at the request of the TPS.
The ICDA monitors that portion of shared memory used
for output instruments, and waits for the TPS to change
any value. Only after a change in value does the ICDA
send a command to the output instrument with the new
value to output. This avoids sending repeat commands
to the instrument on every pass through the loop.
Every instrument driver in the ICDA takes advantage of
LabVIEW's built-in VISA (Virtual Instrument Software
Architecture) functions. VISA is quickly becoming the
industry standard means of communicating with, and
retrieving data from, instruments of many types. VXI,
GPIB, and RS-232 instruments can all be accessed
using functions in the VISA library. This not only allows
the ICDA to be more generic and reusable, but allows
the ICDA to be compatible with any future LabVlEW
upgrades, VISA revisions, or whatever new industry
standard replaces VISA in the future.
Ill. RAPID PROTOTYPE DEVELOPMENT
LabVlEW is ideal for rapid prototyping of graphical user
interfaces (GUI) and program features since it is a
graphical programming language. A number of prebuilt
graphical controls and indicators are available in
LabVIEW. These items are selected from menus and

576

Many rapid prototype software development tools allow

the developer to quickly build a GUI for demonstration
purposes, but then the GUI must be redone in a
conventional
programming
language
for
implementation. An advantage of using LabVlEW was
that we were able to take the GUI developed with the
users' inputs, and use it directly in our final product. All
that was required was to strip out the "dummy" data,
and make the appropriate connections to the actual
acquired data.
Thus, we saved significant
development time by using LabVlEW as both a rapid
prototype tool and as our programming language
during creation of the ETTAS II software.
IV. TPS DEVELOPMENT
In general, the TPS for an aircraft engine consists of a
collection of tests, each designed to check some
aspect of the engine's performance. Each test consists
of a series of test steps made up of instructions guiding
the operator through manual procedures required for
performing that particular test Mandatory critical
engine parameters, as well as operator-selected
engine parameters, are monitored and displayed during
each test. The operator is given pass/fail and critical
parameter alarm (out-of-limits) information during each
test, with the option to perform troubleshooting when
required. At certain test points, pertinent engine
performance data are recorded for incorporation into a
final test report, which is printed out after completion of

all testing. LabVlEW is well suited for development of

TPS with these features.
LabVIEW's modularity greatly streamlines the process
of developing and testing a TPS of this type. Each of
the tests that make up the TPS have a main VI which
contains subVls, one for each test step in that test.
Likewise, each test step subVl contains additional
subVls. Each subVl performs a single function or a
group of associated functions, which also facilitates the
opportunity for code reuse. (Section V. discusses the
code reuse aspects in further detail.) The modularity of
LabVlEW can be seen in Fig. 1, which shows part of
the VI hierarchy of a typical engine TPS.

As stated in the first paragraph of this section, several

operations occur simultaneously when the TPS is
running. Test step instructions and pass/fail feedback
are being provided to the operator, the operator test
menu is being monitored for inputs, and engine
parameters are being continuously acquired, displayed,
and limit-checked for alarm conditions. These tasks
are easily handled in LabVlEW in a high-level VI
containing four WHILE LOOPS in parallel running
asynchronously. One WHILE LOOP contains the code
for the test steps, and executes once every half
second. A second WHILE LOOP contains the operator
test menu code, and executes once every half second.
A third WHlL,E LOOP contains the data acquisition and
parameter limit-checking functions, and runs as fast as
possible. The fourth WHILE LOOP has the code for
the user displays, and runs once every tenth of a
second. The different time intervals are set by placing
the WAIT (msec) function inside each WHILE LOOP,
and wiring the value, in milliseconds, of the desired
execution interval to the WAIT'S input. The execution
times vary between the different loops because of the
varying update requirements. The data acquisition loop
needs to execute as frequently as possible in order not
to miss any data, the user display loop needs to update
often, but not so rapidly as to be unreadable, and the
test step and test menu loops need to execute only
once every half second since they wait for operator
action, which is unlikely to occur in any more frequent
interval.

round

Fig. 1 VI Hierarchy
LabVIE'W VIS are unique in that, once om leted, they
can be run without' being first compiled into an
executable. This feature enables the developer to
create the VIS for a TPS, and test them in an iterative
manner. First, the individual VIS are each separately
tested for correct functionality.
Next, they are
integrated together into test steps, and once again
tested for proper operation.
Finally, all the VIS
comprising a TPS are integrated and tested for correct
functionling. This approach increases the probability of
the TPS performing properly on the first try since all the
VIS have successfully completed integration testing at
several different levels during the entire development
cycle. The entire TPS can be written and tested
without ever being compiled into an executable form,
providing significant savings in development time over
conventional programming languages that must be
recompiled after any changes.

577

Also as previously stated, there is a requirement to

record engine performance data for inclusion in a final
test report which is printed out at the conclusion of
testing. LabVlEW provides several functions with
which to accomplish this final report. First, the required
data are collected at the appropriate points in the test
and stored in global variable functions. When the
operator decides to print the final test report, the data
from these globals are input into Write To
Spreadsheekvi. This VI, which is furnished with
LabVIEW, takes an array of numbers and converts it
into a text file readable by most spreadsheet
applications. Once the data are converted to this text
file, Object Linking and Embedding (OLE) functions are
used to initiate a macro that converts the text file to an
Excel file and prints it out.
V. CODEREUSE
A significant reason for using LabVlEW, as opposed to
a conventional text-based language, is the ability to
easily implement code reuse, both within a single TPS
and between multiple TPS. Some of the advantages

p/

Fig. 2 Check RPM VI

provided by this reusability are a reduction in

development time, increased quality of code, and
common "look and feel" of the software.
When developing a TPS, the need to perform the same
function in different test steps is a common event. For
instance, a requirement may exist to check engine
RPM at different throttle positions. As shown in Fig. 2,
one VI can be written that will check RPM for any
particular throttle position provided as an input. Then, it
is merely a matter of "pointing and clicking" with the
mouse to insert a copy of the VI wherever RPM needs
to be checked. This ability to use the same VI in
multiple locations provides a considerable reduction in
software development time, since only one VI is written
rather than several conventional modules.

LabVIEW's graphical programming environment also

provides a common "look and feel" to the TPS through
code reuse. This feature is very important since it
enables the developer to maintain a consistent user
interface. When more than one developer works on a
TPS, it is absolutely essential. For example, each TPS
test step presented to the operator requires an input
menu. If the three developers had each included this
menu as an integral part of the test steps they
developed, there was a great likelihood of each input
menu appearing different. However, by creating one VI
that displays a common user input menu, as shown in
Fig. 3, we were able to guarantee the same "look and
feel" for each test step's input menu, regardless of
developer.

In addition, the quality of the software tends to be better

when only a single module (in this case a VI) is
developed for reuse rather than developing several
unique modules, each for one-time use. This is true for
a couple of reasons. First, as the number of modules
increases, the possibility of errors being introduced
also increases. Even if the modules are very similar in
function, the potential exists for mistakes to occur any
time changes are made. Second, if only one VI is
being reused in several locations, any errors in that VI
are more likely to be identified earlier in the
development due to its extensive use.

578

Fig. 3 Reusable Input Menu VI

Each of the previously stated advantages of code

reuse in a single TPS can also be extended to multiple

TPS developments. The approach we took to make
reusable code available to multiple developers working
on different TPS was to set up a file server on our local
network. We then created a read-only directory to
serve as a VI repository on this server. This directory
is separated into subdirectories to hold the different
types of VIS available for reuse, such as controls, limit-

checking, displays, etc. VIS that are candidates for

reuse are submitted to a designated senior developer,
who is responsible for confirming the VI functions
properly and has an adequate description included in
its VI Information window. If deemed to be acceptable,
the VI is then placed in the repository. Then, when a
developer needs a VI to perform a certain function, he
looks in the appropriate subdirectory for a suitable VI.
By exarnining the VI'S front panel and block diagram,
as well as reading the VI description, the developer can
ascertain if the VI fits their requirement or can be
readily modified to do so. Should the VI meet their
needs, they simply copy it to their computer for
inclusion in the TPS they are developing.

At a sornewhat higher level, we have also created test

step templates that can be copied from the file server
for reuse.
These templates provide the basic
structures for creating test steps, including user
input/output displays, case statements for incrementing
through the tests, and sample VIS that are replaced
with the appropriate VIS by the TPS developer. These
templates are well commented, and provide the
developer a significant "jump-start" when creating a
new TP:S.

VI. CONCLUSIONS
LabVlEW offers several advantages over conventional
programming languages in developing engine test
software. The instrument drivers in the ICDA take
advantage of LabVlEWs built-in VISA functions to
make the ICDA as generic and reusable as possible,
creating significant independence between the ETTAS
I I hardware and the TPS. LabVlEW works well as a
GUI rapid prototype tool since the results can be
directly used in the TPS. Software development is
greatly simplified as a result of LabVIEWs graphical
programming environment, with code reuse a simple
matter of "point and click" with a mouse. Thus,
LabVlEW proved to be much more than merely an
instrumentation control language.
REFERENCES
[I]National Instruments, lnstrument l/O Vl Reference
Manual, January, 1996.
[2] National Instruments, LabVlEW Users Manual,
January, 1996.
[3] R.S. Pressman, Software Engineering, 3rded.,
McGraw-Hill, New York, 1992.

579