Vous êtes sur la page 1sur 9

Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

PAPER SERIES 2006-01-0516

Vehicle Model Development and Verification

Using MathWorks Simulink and National
Instruments Virtual Instrumentation
Marc E. Herniter and Zachariah Chambers
Rose-Hulman Institute of Technology

2006 SAE World Congress

Detroit, Michigan
April 3-6, 2006

400 Commonwealth Drive, Warrendale, PA 15096-0001 U.S.A. Tel: (724) 776-4841 Fax: (724) 776-5760 Web: www.sae.org
Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

The Engineering Meetings Board has approved this paper for publication. It has successfully completed
SAE's peer review process under the supervision of the session organizer. This process requires a
minimum of three (3) reviews by industry experts.

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise,
without the prior written permission of SAE.

For permission and licensing requests contact:

SAE Permissions
400 Commonwealth Drive
Warrendale, PA 15096-0001-USA
Email: permissions@sae.org
Tel: 724-772-4028
Fax: 724-776-3036

For multiple print copies contact:

SAE Customer Service

Tel: 877-606-7323 (inside USA and Canada)
Tel: 724-776-4970 (outside USA)
Fax: 724-776-0790
Email: CustomerService@sae.org

ISSN 0148-7191
Copyright  2006 SAE International

Positions and opinions advanced in this paper are those of the author(s) and not necessarily those of SAE.
The author is solely responsible for the content of the paper. A process is available by which discussions
will be printed with the paper if it is published in SAE Transactions.

Persons wishing to submit papers to be considered for presentation or publication by SAE should send the
manuscript or a 300 word abstract to Secretary, Engineering Meetings Board, SAE.

Printed in USA
Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018


Vehicle Model Development and Verification Using MathWorks

Simulink and National Instruments Virtual Instrumentation
Marc E. Herniter and Zachariah Chambers
Rose-Hulman Institute of Technology
Copyright © 2006 SAE International

plant) and a Stateflow [3] model that implements our

ABSTRACT control strategy (referred to as the Hybrid Vehicle
Supervisory Controller (HVSC)). Both models are tested
Rose-Hulman Institute of Technology is one of 17 and verified on National Instruments PXI real-time
universities competing in Challenge X – Crossover to systems. [4] Because the development of our control
Sustainable Mobility, an international competition where strategy and its implementation on a real-time target
teams are challenged to design, build, and test a hybrid require the close integration of MathWorks and National
vehicle architecture utilizing alternative fuels to reduce Instruments products, both platforms are discussed
the energy consumption and emissions production of a concurrently in this paper since they were used
2005 Chevrolet Equinox. Our first year of competition concurrently to develop our control system.
has focused on vehicle simulation in which The
MathWorks SimDriveline and Stateflow toolboxes have We are using three National Instruments platforms for
been used almost exclusively. A model of our vehicle’s model development and control system implementation.
split train architecture was developed in SimDriveline Initially we will use three PXI based platforms: One
and Stateflow was used to develop the control strategy. system is for data acquisition in the vehicle, the second
This approach was extraordinarily useful as we could implements our control algorithm, and the third runs the
readily identify hazards such as high torque stresses, plant model. The data acquisition and control platforms
battery over or under voltage spikes, battery over current will reside in the final vehicle, while the third system
spikes, wheel skidding, and rpm limits. We have been which runs the plant model is strictly for system
continuously improving our model and control strategy to development. When a Compact RIO (cRIO) system
uncover new hazards and verify components becomes available, it will be used to run our control
specifications and limits. We have ported our vehicle algorithm rather than a PXI system. [5] Also, if the cRIO
model to a National Instruments PXI platform and have has the capacity, the data acquisition system and HVSC
performed real-time testing and verification. Over the will be combined into a single system that performs both
course of the competition we will be further refining our functions and runs on a single cRIO platform.
model and control strategy.
Initially our development focused around using the
INTRODUCTION Powertrain System Analysis Toolkit (PSAT) [6] to
develop our vehicle model and control algorithm. PSAT
Rose-Hulman Institute of Technology is designing a is a modeling package that runs under Simulink and is
split-train architecture [1] hybrid electric vehicle that uses used to design and evaluate advanced vehicle
three power sources that can potentially move the powertrains. [6] PSAT can be used to model over 1000
vehicle: a 70 kW VM Motori engine that uses B-20 advanced vehicle configurations and proved to be too
Diesel fuel, and two 60 kW synchronous electric complicated for our development. PSAT contains both a
machines from Light Engineering. All three power plant model and a control algorithm for controlling a
sources are connected through a planetary gear set vehicle of our architecture. Initially, we were going to
(PGS). The electric machines can move the vehicle in extract the plant and HVSC models and run each on
forward or reverse, can act as motors or generators, and their own platform. The two would then communicate
one of the motors is required to control the speed of the through the CAN bus and our control algorithm would be
engine. When the three power sources are combined based on the PSAT models. Because of the large
with a battery that must be maintained within specific number signals exchanged between the plant and the
operating limits, the system becomes a challenging HVSC, the complexity of the plant and HVSC models,
control problem. and a lack of understanding of the communication
signals that are exchanged between the plant and
Our approach to developing a control system is through HVSC, we were unable to implement the PSAT models
the use of model based design with Simulink and model on our platforms. Consequently, we developed our own
verification using National Instruments virtual plant and HVSC models using SimDriveline and
instrumentation. The Simulink model includes a Stateflow, and the models have been implemented and
SimDriveline [2] model of the vehicle (referred to as the tested on the National Instruments real-time platforms.
Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

Achievements thus far range from the development of necessary. Thus, if we need to measure any signals not
the plant and HVSC models to running those models on already measured by a component controller, those
National Instruments real-time targets. The plant and signals will be measured directly by the DAU and then
HVSC were developed in a single Simulink model using passed to the HVSC through the CAN bus.
basic Simulink and SimDriveline components. Initially,
an ideal model was developed that allowed us to
understand the relationship between the various Hybrid Vehicle
drivetrain components. Slowly, non-idealities were Controller Data Acquisition
introduced into each component model until we had a Unit
very detailed model that modeled the behavior of the Compact RIO
system as well as its limitations. Next, the plant and Or PXI Chassis
HVSC models were split into two separate Simulink PXI Chassis
models and compiled into two dynamic link libraries
(DLLs) which run on National Instruments PXI platforms.
Initially, the plant and HVSC were run as two separate
processes on a single PXI platform. The two processes 6.5"
exchanged information using first-in-first-out (FIFO) data LCD
structures, and thus there was no communication of data
outside of the PXI platform except for driver controls and Chevrolet Equinox
a display. This model runs in real-time and allows us to
get a “consumer’s feel” of the vehicle as well as debug Electric
Engine Motors Battery
the HVSC. Finally, the HVSC and plant DLL models
were run on separate PXI platforms, with information
between the two models exchanged through the CAN
bus and through the PXI platform’s A/D and D/A Body Brakes
hardware. This model runs in real-time and is an
accurate representation of the control hardware that will
be used in the vehicle. In the actual vehicle, the HVSC
will run on a National Instruments PXI or cRIO platform,
information will be exchange with the component Figure 1: Control System Overview
controllers using a CAN bus or A/D and D/A hardware.
All communication between component
controllers, the HVSC, and the DAU will occur over the
CONTROL SYSTEM ARCHITECTURE Controller Area Network (CAN) bus. [7] The CAN
standard was chosen because of its popularity in the
A control system has been developed to allow automotive industry. Additionally, the GMLAN, [8] a
individual components, each with their own controller, to CAN-based network, already exists in the competition
work together. The HVSC oversees the individual vehicle. By selecting CAN, we will be able to easily
component controllers such as the engine controller, interface the DAU and HVSC with pre-existing
motor controllers, body controller, and battery monitoring controllers and sensors on the GMLAN. A block diagram
system. The HVSC sends commands to the component of our bus architecture is shown in Figure 2. The
controllers to make them function as a unified system. A GMLAN and the CAN bus will interface through the
block diagram of our control system architecture is production engine control unit (ECU). Although the
shown in Figure 1. We have separated the tasks of data original engine will be replaced, we will maintain the
acquisition and vehicle control into two separate units to original ECU as the gateway between the CAN bus and
decrease the processing and memory requirements of the GMLAN.
each unit. It is possible that in the future, the Data
Acquisition Unit (DAU) and the HVSC could be
combined into a single unit.
The small blocks inside of the Chevrolet
Equinox block represent the individual component
controllers. We are assuming that the individual

component controllers measure and collect data relevant

to the successful operation of the component they
control. Thus, most of the data required to control the
overall system is already being collected. The main Figure 2: Bus Architecture
function of the DAU is to record information already
collected by the component controllers. The DAU has
the capacity to directly measure and record information
from a large number of analog and digital channels if

Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

MODEL DEVELOPMENT STRATEGY With this simplified model, we were able to gain an
understanding of the individual vehicle systems, the
Our model development consists of several phases that SimDriveline model components, and Stateflow. We
include development in both the Simulink and LabVIEW were able to implement a simple controller for a series
environments. architecture and have the vehicle follow a drive cycle. An
1) Based on our understanding of our vehicle, a flow important result of these simulations was that we found
chart was designed that describes the operation of our that as we engaged and disengaged the clutches,
vehicle. This is the starting point for all development. components experienced high torque stresses and
2) Implement an ideal plant model and a simplified occasionally a hazard would occur such as the engine
version of the HVSC using SimDriveline and Stateflow. spinning backwards.
3) As we gain a deeper understanding of the vehicle and
HVSC, refine the vehicle model to include component With the insight gained from this simple model, we
non-idealities and implement a more complicated control implemented our second control algorithm using the
algorithm. same plant model. This control method eliminated the
4) Identify hazards that occur during state transitions. use of three of the clutches (although they were still
Hazards include high torque stresses, battery over or available for use in the plant model) and allowed us to
under voltage spikes, battery over current spikes, wheel investigate a basic split-train control algorithm. For this
skidding, and rpm limits. implementation, the engine was enclosed in a feedback
loop that used the engine throttle to maintain constant
The Simulink environment is ideal for development and engine rpm. The two motors were then used to control
refinement of the control algorithm. However, it does not the speed of the vehicle. This model gave us a thorough
give us a consumer’s feel for how the vehicle transitions understanding of how the three power sources
between states, acceleration and deceleration, or allow interacted through the PGS and also allowed us to
us to easily test the control logic using vehicle control develop an engine starting and stopping procedure.
inputs generated by a real driver. Steps 1 through 4 are Ultimately, we found that this method would not work
developed in the Simulink environment. because the engine throttle cannot control the speed of
the engine when it experiences large positive and
5) The fifth step is real-time testing in the LabVIEW negative torques through the PGS. Simulations showed
development environment. The Simulink model is us that during high acceleration and deceleration, we
partitioned into the three parts and tested on a National could not control the rpm of the engine using only the
Instruments real-time platform. The three parts are: engine throttle. This problem led to the third control
a) The driver block that includes the key switch, brake, algorithm discussed next.
gear shift, and accelerator pedal.
b) The plant model that implements the complete vehicle Our third model uses a different control method for
model excluding the HVSC. regulating the speed of the engine. Whenever the
c) The HVSC. engine is on, one of the motors is exclusively used to
control the speed of the engine. The engine throttle is
SIMULINK MODEL BASED DEVELOPMENT then used to control the speed of the vehicle while the
engine is on. When the engine is off, the engine’s rpm is
Using the Stateflow and SimDriveline components of held at zero by a locking clutch, and either of the motors
Simulink, a large amount of model development was can be used to control the speed of the vehicle.
accomplished. The overall strategy was to start with the
simplest model possible and implement a simple control This model has seen considerable development and
algorithm. As we became more comfortable with the includes models of the engine, battery, and motors that
modeling environment, our vehicle topology, and with use vendor supplied data. It includes several HVSC
vehicle control algorithms, we improved the model to refinements including smooth transitions between states,
implement more accurate component models and more forward and reverse, vehicle start-up and shut-down
complicated control algorithms. procedures, and identification of hazards.

Since we had little understanding of how the two motors Example results of our vehicle following a FU505 drive
and engine worked together through the PGS, our first cycle are shown in Figure 3:
and simplest model added four clutches to the
architecture that allowed us to isolate each of the power
sources and use the power sources in any combination.
This innovation allowed us to run as a simple series
hybrid topology, or as a complex split-train hybrid. With
this model, we used ideal components for the motors Figure 3: Simdriveline Model Following An FU505
and engine. The only non-ideal component was the Driving Schedule
battery which was adapted from the PSAT model.

Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

MODEL BUILDING PHILOSPHY This model allowed us to use the motor in both the
motoring and regenerating modes of operation. This
Our general philosophy for developing the vehicle model model was used extensively and allowed us to generate
is to start as simple as possible using ideal components, a complete control strategy. Since the model can be
and then slowly add detail to each component to make used in both motoring and regenerating modes, it
the component as realistic as possible. Our modeling allowed us to understand how the various vehicle
process is summarized in the following steps: components interacted without the confusion of an
extremely complicated motor. This simple model allowed
• Start with the simplest model possible. us to focus on the system as a whole, without the
distractions of how the motor efficiency or torque curve
• Understand the operation of each component. affects the system. With three power sources in our
topology (two electric motors and an engine), it is
• Understand the model output and that it agrees paramount that we understand the basic interaction of
with our understanding of the system. the ideal components before we add non-ideal effects
that will make the system even more complicated.
Once we are satisfied that the model works as expected
and we have convinced ourselves that the model is Further step by step improvements to the motor model
correct, we add a single function to the model to make were:
the model more accurate. By “correct” we mean that
either the model matches measured data, matches the 3) Adding a current limit (the same current limit for
results of another simulation package, or the model regenerating and motoring modes).
behaves as expected and follows our intuition of the
system. 4) Adding a constant efficiency loss (the same efficiency
loss for regenerating and motoring modes).
A good example of this process was the evolution of our
motor model, the steps of which are outlined next. 5) Adding separate current limits for motoring and
regenerating modes.
1) The first motor model was a constant torque output:
6) Adding an efficiency map to make the efficiency a
function of rpm and terminal voltage. (The same
efficiency is used for motoring and regenerating modes.)

7) Adding a constant torque limit.

8) Adding a torque limit based on motor rpm and

terminal voltage.
Figure 4: Motor Model With Constant Torque Output
Our present model is show below:
This model is easy to understand, provides constant
output torque, and has no limits. This model allowed us
to understand and verify the operation of the driveline
and other components in the model.

2) The first improvement to the motor model was to

model it as a 100% efficient power converter where
electric power equals mechanical power:

Figure 6: Complete Motor Model

This model is fairly complicated and includes several

non-ideal functions of the motor. However, the process
Figure 5: Motor Model Where Electrical Power that we follow gives us confidence in the accuracy of
Equals Mechanical Power each block within the model.

Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

All of the blocks in our model have undergone this for the key, gear shift, brake pedal and accelerator
evolutionary design process. Some of the blocks and pedal. The hardware console has analog outputs that
their functions are discussed below: are read by the A/D inputs of the plant PXI chassis. This
method is deterministic and represents the vehicle
x Engine – The engine model includes engine accurately because the driver controls are a part of the
braking torque while the engine is on, engine off plant.
compression torque, fuel consumption as a
function of rpm and torque, and maximum The hardware implementation of the real-time simulator
engine torque as a function of engine rpm. has evolved over three major topologies. All three
methods required the vehicle model to be split into the
x Battery – The battery model includes battery plant model and the HVSC model. These two models
charge and discharge resistances that are executed as separate processes and data were
function of the battery state of charge (SOC) and exchanged between the two. The data includes control
the battery temperature. The model includes signals flowing from the HVSC to the plant that tell the
columbic efficiency during charging, and plant what to do, and measurement data flowing from
calculates the battery SOC, open circuit voltage, the plant to the HVSC so that the HVSC knows the state
terminal voltage, and average power dissipation. of the plant. In the first iteration, both the HVSC and
plant processes executed on the same PXI platform and
data were exchanged through a first-in-first-out (FIFO)
FUTURE SIMULINK WORK data structure within the PXI platform. This method
allowed us to focus on the performance of the plant and
The present model has matured enough so that we can HVSC in real-time without worrying about latency in the
begin experimenting with various aspects of the data exchange between the two.
vehicle’s control algorithm and investigate how it can be
modified to optimize the vehicle’s performance. Future In the second hardware implementation, the plant and
work includes HVSC are run on separate PXI platforms and data are
exchanged through a CAN bus. This method allowed us
x Modifying the control algorithm to decrease the to see the effect of the CAN bus’ limited bandwidth on
0 to 60 mph time. the system.

x Modifying the control algorithm to increase the In the third implementation, we tried to accurately model
fuel efficiency. the final vehicle hardware realization where some of the
signals needed by the HVSC are not available and must
x Eliminate all torque spikes during mode be measured by our data acquisition system. In this
transitions. realization, the plant model outputs some of its
information as analog voltages and these signals are not
SYSTEM DEVELOPMENT USING VIRTUAL exchanged between the plant and HVSC through the
INSTRUMENTATION CAN bus. Instead, a third PXI platform running our data
acquisition system measures the signals and then sends
Once the Simulink model matured, we began real-time the information to the HVSC through the CAN bus. This
testing of the model and HVSC using LabVIEW on model is an accurate representation of the architecture
National Instruments PXI platforms. The Simulink model described in Figures 1 and 2.
was split into three blocks: the driver controls, the plant,
and the HVSC. The National Instruments Simulation The manual methods of driving the vehicle have been
Interface Toolkit together with the MathWorks Real-Time especially useful as they allow us to investigate every
Workshop was used to generate separate DLL files for state transition of the vehicle control algorithm in detail.
the plant and the HVSC. These models execute in real- With this simulator, we have been able to exercise the
time on the PXI chassis. The driver inputs are HVSC through each control state in numerous vehicle
implemented using three methods. In the first method, situations. We have identified several problems that
the driver inputs are included as part of the plant model were not identified using the Simulink environment
and the driver inputs are read from a file. This method where the vehicle followed a specific driving cycle. A
allows us to observe the real-time system as it follows a catastrophic problem was uncovered when we found
standard drive cycle. In the second method, the driver that the vehicle would speed out of control intermittently
controls are implemented as LabVIEW front panel when we shifted from forward to reverse while the
controls with communication to the plant model through vehicle had a small amount of speed. We identified the
TCP/IP. This method allows us to drive the vehicle problem as an error in our logic sequence that
manually but has the drawback that the TCP/IP guarantees that the driver cannot shift from forward to
connection is not always deterministic because of reverse while the vehicle is moving. A sequence of
network latency. The third method uses a hardware states was created to guarantee that a specific set of
driver console to drive the vehicle manually with inputs events must occur before the vehicle could switch from

Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

forward to reverse or reverse to forward. The first two will be removed from the plant and the control signals for
steps were measuring the vehicle speed and making the component that originally went to the plant will be
sure that the vehicle speed was zero, and that the driver physically connected to the component. The operation of
had the brake pedal depressed. (Zero speed was the component will be read either by the component
defined as the vehicle speed being less than 0.5 mph.) controller or the DAU. The data will then be
Once the first two steps were completed, the gear shift communicated back to the HVSC through the CAN bus.
becomes unlocked and the gear can be shifted from Although it is not representative of our final vehicle
forward to reverse. Finally, after the gear has been topology, some of the component data will be read by
shifted and the driver releases the brake pedal, the the plant model so that the plant knows how to react
vehicle will enter the forward or reverse states. This since that component is no longer in the plant model.
sequence requires three distinct states in the control HIL testing will allow us to develop the interface
algorithm. Using the real-time simulations with a driver electronics and communications for each component.
exploring the various modes, we noticed that
intermittently, when we shifted from forward to reverse, CONCLUSION
the vehicle would take off uncontrollably in the wrong
direction. We found that the problem was a result of the A large amount of model development has been
gear shifting from forward (gear 1) to reverse (gear -1). accomplished using the Simulink and LabVIEW
The gear number changes in one of the early states in development platforms. These platforms have allowed
the shifting sequence. This shift changes the feedback us to learn how to develop and test a large control
signal in the control loop from positive to negative in system before we implement that system in a vehicle.
order to change the vehicle direction from forward to The modeling and testing have allowed us to identify
reverse. However, for the feedback to work, we also flaws in our control algorithm that otherwise may not
need to change one of the motor modes from forward (1) have been discovered until the system was implemented
to reverse (-1) to maintain negative feedback. We on the vehicle. In some cases, potentially deadly flaws
discovered that the gear shifted to -1 at the beginning of were discovered. In other cases, high torque spikes
the shifting sequence and the motor changed to reverse were uncovered that would have destroyed mechanical
(-1) at the end of the sequence. The result was that components.
there was a period of time when there was a positive
feedback loop, and if the vehicle had a small amount of We have developed a basic model of the vehicle and of
speed, it would accelerate out of control. the supervisory controller. A large amount of simulation
and testing is still required to guarantee the successful
Using the real-time simulations we were able to identify integration of the system into the vehicle. However, the
this problem and modify the control algorithm to correct models that have been developed represent a significant
it. As expected, there are other problems that we have step in the controller development, and have laid a solid
uncovered using the real-time simulations, and we are in foundation for future development.
the process of correcting them.
The driver interface and plant model indicators are
shown in Figure 7. The authors would like to thank The MathWorks and
National Instruments for providing the tools necessary to
develop a control system of this magnitude. Not only did
they provide state of the art tools, but they provided
training and support so that we could effectively use the
tools. We are grateful for their support. The authors
would also like to thank General Motors and the
Department of Energy for supporting the Challenge X
competition and the development of our vehicle.


1. Gomez, M., Mucino, V., Clark, N., Smith, J., “A

Configuration for a Continuously Variable Power-
Split Transmission in Hybrid-Electric Vehicle
Figure 7: Vehicle Driver Interface Applications,” SAE paper 2004-01-0571, SAE World
Congress, Detroit (March 2004)
FUTURE LabVIEW DEVELOPMENT 2. The MathWorks, “What is SimDriveline?”
The next step in our development process is hardware in http://www.mathworks.com/access/helpdesk/help/to
the loop (HIL) testing of the major components including olbox/physmod/drive/a1064262873.html. (date
the engine, battery, and motors. In this testing we will accessed: September 9, 2005)
test each component individually. The component model
Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

3. The MathWorks, “Stateflow 6.3: Design and simulate ECU: Engine Control Unit.
event-driven systems,”
http://www.mathworks.com/products/stateflow/?BB= Hardware in the Loop (HIL): A simulation technique in
1. (date accessed: September 9, 2005) where the controller hardware is interfaced to physical
4. National Instruments, “PXI,” http://www.ni.com/pxi/. hardware components. The controller controls the piece
(date accessed: September 9, 2005) of physical hardware in a controlled environment.
5. National Instruments, “CompactRIO,”
http://www.ni.com/compactrio/. (date accessed: HVSC: Hybrid Vehicle Supervisory Controller.
September 9, 2005)
6. Rousseau, A., Sharer, P., Besnier, F., “Feasibility of PGS: Planetary Gear Set – A type of transmission
Reusable Vehicle Modeling: Application to Hybrid generally used where there are multiple power sources
Vehicles,” SAE paper 2004-01-1618, SAE World in a vehicle.
Congress, Detroit (March 2004)
7. Microchip, “Controller Area Network (CAN) Basics,” Plant Model: A software based model that uses
Doc. No. DS00713A, (1999 Microchip Technology mathematical approximations to represent the governing
Inc.) physics of a system.
0713a.pdf PSAT: Powertrain System Analysis Toolkit. A Simulink
8. Menon, C., “Future Trends in Networking,” SAE model developed by Argonne National Labs to model
paper 2003-01-3738, SAE World Congress, Sao and test advanced vehicle architectures.
Paulo, Brazil (November 2003)
SimDriveline: A Simulink Toolbox used to model and
CONTACT test vehicle drivetrains.

Rose-Hulman Institute of Technology Faculty Advisors: SOC: State of Charge of the battery.

Marc Herniter, (812) 877-8512 Software in the Loop (SIL): A simulation technique in
Marc.Herniter@ieee.org where a piece of software emulating a piece of control
5500 Wabash Avenue hardware (i.e. engine computer), is interfaced to a
Terre Haute, IN 47803 software “plant” model. There is no requirement of
running the simulation in real-time.
Zac Chambers, (812) 877-8904
Chambez@rose-hulman.edu FIFO: First-in-first-out.
5500 Wabash Avenue
Terre Haute, IN 47803 DLL: Dynamic link library.


DAU: Data Acquisition Unit.