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

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

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

2
 Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018
MODEL DEVELOPMENT STRATEGY
Our model development consists of several phases that
include development in both the Simulink and LabVIEW
environments.
1) Based on our understanding of our vehicle, a flow
chart was designed that describes the operation of our
vehicle. This is the starting point for all development.
2) Implement an ideal plant model and a simplified
version of the HVSC using SimDriveline and Stateflow.
3) As we gain a deeper understanding of the vehicle and
HVSC, refine the vehicle model to include component
non-idealities and implement a more complicated control
algorithm.
4) Identify hazards that occur during state transitions.
Hazards include high torque stresses, battery over or
under voltage spikes, battery over current spikes, wheel
skidding, and rpm limits.
The Simulink environment is ideal for development and
refinement of the control algorithm. However, it does not
give us a consumer’s feel for how the vehicle transitions
between states, acceleration and deceleration, or allow
us to easily test the control logic using vehicle control
inputs generated by a real driver. Steps 1 through 4 are
developed in the Simulink environment.
5) The fifth step is real-time testing in the LabVIEW
development environment. The Simulink model is
partitioned into the three parts and tested on a National
Instruments real-time platform. The three parts are:
a) The driver block that includes the key switch, brake,
gear shift, and accelerator pedal.
b) The plant model that implements the complete vehicle
model excluding the HVSC.
c) The HVSC.
SIMULINK MODEL BASED DEVELOPMENT
Using the Stateflow and SimDriveline components of
Simulink, a large amount of model development was
accomplished. The overall strategy was to start with the
simplest model possible and implement a simple control
algorithm. As we became more comfortable with the
modeling environment, our vehicle topology, and with
vehicle control algorithms, we improved the model to
implement more accurate component models and more
complicated control algorithms.
Since we had little understanding of how the two motors
and engine worked together through the PGS, our first
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
and engine. The only non-ideal component was the
battery which was adapted from the PSAT model.
With this simplified model, we were able to gain an
understanding of the individual vehicle systems, the
SimDriveline model components, and Stateflow. We
were able to implement a simple controller for a series
architecture and have the vehicle follow a drive cycle. An
important result of these simulations was that we found
that as we engaged and disengaged the clutches,
components experienced high torque stresses and
occasionally a hazard would occur such as the engine
spinning backwards.
With the insight gained from this simple model, we
implemented our second control algorithm using the
same plant model. This control method eliminated the
use of three of the clutches (although they were still
available for use in the plant model) and allowed us to
investigate a basic split-train control algorithm. For this
implementation, the engine was enclosed in a feedback
loop that used the engine throttle to maintain constant
engine rpm. The two motors were then used to control
the speed of the vehicle. This model gave us a thorough
understanding of how the three power sources
interacted through the PGS and also allowed us to
develop an engine starting and stopping procedure.
Ultimately, we found that this method would not work
because the engine throttle cannot control the speed of
the engine when it experiences large positive and
negative torques through the PGS. Simulations showed
us that during high acceleration and deceleration, we
could not control the rpm of the engine using only the
engine throttle. This problem led to the third control
algorithm discussed next.
Our third model uses a different control method for
regulating the speed of the engine. Whenever the
engine is on, one of the motors is exclusively used to
control the speed of the engine. The engine throttle is
then used to control the speed of the vehicle while the
engine is on. When the engine is off, the engine’s rpm is
held at zero by a locking clutch, and either of the motors
can be used to control the speed of the vehicle.
This model has seen considerable development and
includes models of the engine, battery, and motors that
use vendor supplied data. It includes several HVSC
refinements including smooth transitions between states,
forward and reverse, vehicle start-up and shut-down
procedures, and identification of hazards.
Example results of our vehicle following a FU505 drive
cycle are shown in Figure 3:
Figure 3: Simdriveline Model Following An FU505
Driving Schedule
3
 Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018
MODEL BUILDING PHILOSPHY
Our general philosophy for developing the vehicle model
is to start as simple as possible using ideal components,
and then slowly add detail to each component to make
the component as realistic as possible. Our modeling
process is summarized in the following steps:
• Start with the simplest model possible.
• Understand the operation of each component.
• Understand the model output and that it agrees
with our understanding of the system.
Once we are satisfied that the model works as expected
and we have convinced ourselves that the model is
correct, we add a single function to the model to make
the model more accurate. By “correct” we mean that
either the model matches measured data, matches the
results of another simulation package, or the model
behaves as expected and follows our intuition of the
system.
A good example of this process was the evolution of our
motor model, the steps of which are outlined next.
1) The first motor model was a constant torque output:
Figure 4: Motor Model With Constant Torque Output
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 5: Motor Model Where Electrical Power
Equals Mechanical Power
This model allowed us to use the motor in both the
motoring and regenerating modes of operation. This
model was used extensively and allowed us to generate
a complete control strategy. Since the model can be
used in both motoring and regenerating modes, it
allowed us to understand how the various vehicle
components interacted without the confusion of an
extremely complicated motor. This simple model allowed
us to focus on the system as a whole, without the
distractions of how the motor efficiency or torque curve
affects the system. With three power sources in our
topology (two electric motors and an engine), it is
paramount that we understand the basic interaction of
the ideal components before we add non-ideal effects
that will make the system even more complicated.
Further step by step improvements to the motor model
were:
3) Adding a current limit (the same current limit for
regenerating and motoring modes).
4) Adding a constant efficiency loss (the same efficiency
loss for regenerating and motoring modes).
5) Adding separate current limits for motoring and
regenerating modes.
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.
Our present model is show below:
Figure 6: Complete Motor Model
This model is fairly complicated and includes several
non-ideal functions of the motor. However, the process
that we follow gives us confidence in the accuracy of
each block within the model.
4
 Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018
All of the blocks in our model have undergone this
evolutionary design process. Some of the blocks and
their functions are discussed below:
x Engine – The engine model includes engine
braking torque while the engine is on, engine off
compression torque, fuel consumption as a
function of rpm and torque, and maximum
engine torque as a function of engine rpm.
x Battery – The battery model includes battery
charge and discharge resistances that are
function of the battery state of charge (SOC) and
the battery temperature. The model includes
columbic efficiency during charging, and
calculates the battery SOC, open circuit voltage,
terminal voltage, and average power dissipation.
FUTURE SIMULINK WORK
The present model has matured enough so that we can
begin experimenting with various aspects of the
vehicle’s control algorithm and investigate how it can be
modified to optimize the vehicle’s performance. Future
work includes
x Modifying the control algorithm to decrease the
0 to 60 mph time.
x Modifying the control algorithm to increase the
fuel efficiency.
x Eliminate all torque spikes during mode
transitions.
SYSTEM DEVELOPMENT USING VIRTUAL
INSTRUMENTATION
Once the Simulink model matured, we began real-time
testing of the model and HVSC using LabVIEW on
National Instruments PXI platforms. The Simulink model
was split into three blocks: the driver controls, the plant,
and the HVSC. The National Instruments Simulation
Interface Toolkit together with the MathWorks Real-Time
Workshop was used to generate separate DLL files for
the plant and the HVSC. These models execute in real-
time on the PXI chassis. The driver inputs are
implemented using three methods. In the first method,
the driver inputs are included as part of the plant model
and the driver inputs are read from a file. This method
allows us to observe the real-time system as it follows a
standard drive cycle. In the second method, the driver
controls are implemented as LabVIEW front panel
controls with communication to the plant model through
TCP/IP. This method allows us to drive the vehicle
manually but has the drawback that the TCP/IP
connection is not always deterministic because of
network latency. The third method uses a hardware
driver console to drive the vehicle manually with inputs
for the key, gear shift, brake pedal and accelerator
pedal. The hardware console has analog outputs that
are read by the A/D inputs of the plant PXI chassis. This
method is deterministic and represents the vehicle
accurately because the driver controls are a part of the
plant.
The hardware implementation of the real-time simulator
has evolved over three major topologies. All three
methods required the vehicle model to be split into the
plant model and the HVSC model. These two models
executed as separate processes and data were
exchanged between the two. The data includes control
signals flowing from the HVSC to the plant that tell the
plant what to do, and measurement data flowing from
the plant to the HVSC so that the HVSC knows the state
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)
data structure within the PXI platform. This method
allowed us to focus on the performance of the plant and
HVSC in real-time without worrying about latency in the
data exchange between the two.
In the second hardware implementation, the plant and
HVSC are run on separate PXI platforms and data are
exchanged through a CAN bus. This method allowed us
to see the effect of the CAN bus’ limited bandwidth on
the system.
In the third implementation, we tried to accurately model
the final vehicle hardware realization where some of the
signals needed by the HVSC are not available and must
be measured by our data acquisition system. In this
realization, the plant model outputs some of its
information as analog voltages and these signals are not
exchanged between the plant and HVSC through the
CAN bus. Instead, a third PXI platform running our data
acquisition system measures the signals and then sends
the information to the HVSC through the CAN bus. This
model is an accurate representation of the architecture
described in Figures 1 and 2.
The manual methods of driving the vehicle have been
especially useful as they allow us to investigate every
state transition of the vehicle control algorithm in detail.
With this simulator, we have been able to exercise the
HVSC through each control state in numerous vehicle
situations. We have identified several problems that
were not identified using the Simulink environment
where the vehicle followed a specific driving cycle. A
catastrophic problem was uncovered when we found
that the vehicle would speed out of control intermittently
when we shifted from forward to reverse while the
vehicle had a small amount of speed. We identified the
problem as an error in our logic sequence that
guarantees that the driver cannot shift from forward to
reverse while the vehicle is moving. A sequence of
states was created to guarantee that a specific set of
events must occur before the vehicle could switch from
5
 Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018
forward to reverse or reverse to forward. The first two
steps were measuring the vehicle speed and making
sure that the vehicle speed was zero, and that the driver
had the brake pedal depressed. (Zero speed was
defined as the vehicle speed being less than 0.5 mph.)
Once the first two steps were completed, the gear shift
becomes unlocked and the gear can be shifted from
forward to reverse. Finally, after the gear has been
shifted and the driver releases the brake pedal, the
vehicle will enter the forward or reverse states. This
sequence requires three distinct states in the control
algorithm. Using the real-time simulations with a driver
exploring the various modes, we noticed that
intermittently, when we shifted from forward to reverse,
the vehicle would take off uncontrollably in the wrong
direction. We found that the problem was a result of the
gear shifting from forward (gear 1) to reverse (gear -1).
The gear number changes in one of the early states in
the shifting sequence. This shift changes the feedback
signal in the control loop from positive to negative in
order to change the vehicle direction from forward to
reverse. However, for the feedback to work, we also
need to change one of the motor modes from forward (1)
to reverse (-1) to maintain negative feedback. We
discovered that the gear shifted to -1 at the beginning of
the shifting sequence and the motor changed to reverse
(-1) at the end of the sequence. The result was that
there was a period of time when there was a positive
feedback loop, and if the vehicle had a small amount of
speed, it would accelerate out of control.
Using the real-time simulations we were able to identify
this problem and modify the control algorithm to correct
it. As expected, there are other problems that we have
uncovered using the real-time simulations, and we are in
the process of correcting them.
The driver interface and plant model indicators are
shown in Figure 7.
Figure 7: Vehicle Driver Interface
FUTURE LabVIEW DEVELOPMENT
The next step in our development process is hardware in
the loop (HIL) testing of the major components including
the engine, battery, and motors. In this testing we will
test each component individually. The component model
will be removed from the plant and the control signals for
the component that originally went to the plant will be
physically connected to the component. The operation of
the component will be read either by the component
controller or the DAU. The data will then be
communicated back to the HVSC through the CAN bus.
Although it is not representative of our final vehicle
topology, some of the component data will be read by
the plant model so that the plant knows how to react
since that component is no longer in the plant model.
HIL testing will allow us to develop the interface
electronics and communications for each component.
CONCLUSION
A large amount of model development has been
accomplished using the Simulink and LabVIEW
development platforms. These platforms have allowed
us to learn how to develop and test a large control
system before we implement that system in a vehicle.
The modeling and testing have allowed us to identify
flaws in our control algorithm that otherwise may not
have been discovered until the system was implemented
on the vehicle. In some cases, potentially deadly flaws
were discovered. In other cases, high torque spikes
were uncovered that would have destroyed mechanical
components.
We have developed a basic model of the vehicle and of
the supervisory controller. A large amount of simulation
and testing is still required to guarantee the successful
integration of the system into the vehicle. However, the
models that have been developed represent a significant
step in the controller development, and have laid a solid
foundation for future development.
ACKNOWLEDGMENTS
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.
REFERENCES
1. Gomez, M., Mucino, V., Clark, N., Smith, J., “A
Configuration for a Continuously Variable Power-
Split Transmission in Hybrid-Electric Vehicle
Applications,” SAE paper 2004-01-0571, SAE World
Congress, Detroit (March 2004)
2. The MathWorks, “What is SimDriveline?”
http://www.mathworks.com/access/helpdesk/help/to
olbox/physmod/drive/a1064262873.html. (date
accessed: September 9, 2005)
6
 Downloaded from SAE International by Steven Sullivan, Wednesday, November 28, 2018

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

DEFINITIONS, ACRONYMS, ABBREVIATIONS CAN: Computer area network

DAU: Data Acquisition Unit.