This document proposes using feedback control to improve hardware-in-the-loop (HIL) based ECU system function testing. It introduces a method that uses feedback from either directly connecting an output signal back to the HIL simulator (hardware feedback) or accessing an internal ECU variable through a communication protocol (software feedback). This feedback is used in a PID control loop to dynamically adjust inputs to drive the output or variable to a target value. The document presents a case study using throttle position control to demonstrate this method. It evaluates the hardware and software feedback approaches and concludes that feedback control enhances HIL-based testing capabilities when transfer functions are unclear.

1. 10AE-0033
Use of Feedback Control to Improve HIL Based ECU System
Function Testing
Yixin Chen
Delphi Powertrain Systems
Rob Carpenter
BeijingWest Industries
Copyright © 2010 SAE International
ABSTRACT
Most times in ECU system function testing, the sensor input signals are directly set to a known value in order to
drive the corresponding software variable to within a range of an expected value. This works only if the transfer
function from the physical signal input to the software variable is well defined such as the measurement on
MAP, A/C pressure, etc. Nevertheless, there are times the transfer function is not clearly defined and it is
difficult to drive the software variable to an expected value. One example is throttle position sensor (TPS) test
in an electronic throttle control (ETC) system, where TPS is not directly driven by the driver accelerator pedal
sensor (APS) and it is very difficult to get TPS to an expected range by only changing APS. This paper
introduces a method to use feedback in an HIL based ECU testing system to control outputs to an expected
range. In this case study, the signal to be controlled is connected back to the HIL system to provide feedback.
The error between the target and the actual signal is used in a PID control system to adjust the input signal
dynamically and keep the signal to be controlled within the targeted range. Two different feedback methods,
namely hardware feedback by physically connecting the signal to be controlled to HIL simulator and software
feedback by reading back the software variable to be controlled through ASAP3 protocol between the HIL
simulator and ECU instrumentation tool, are evaluated.
INTRODUCTION
Hardware-in-the-loop (HIL) based ECU testing systems are able to quickly conduct many automated system
level function tests in short time during the time stressed product development phase. This type of automated
testing plays an important role in finding software problems and ensuring the release of quality software in
automotive industry. Many times in ECU system function testing, the sensor electrical inputs )(tx are driven to
certain values by the HIL simulator in order to get the software variable to be controlled or hardware output
)(ty to an expected range. Let us denote this as )}({)( txfty = . If the mapping relation from )(tx to )(ty ,
namely }{•f , is clearly defined, it should be easy to program it into the HIL scripts. One example is to set the
manifold absolute pressure (MAP) sensor electrical input to a value to drive ECU MAP software variable to a
specified value such as 70 kPa. Challenges exist if trying to drive an output to a specified value when the
transfer function is complicated. For example, in testing ETC algorithm of an engine controller, one challenge is
how to drive throttle position to 60% open as throttle is not directly driven by any single sensor input such as
APS or MAP. Instead, it is driven by the desired throttle position, which is the output of a complex ETC
algorithm. Nevertheless, if we can feedback the output either in hardware by directly connecting the signal back
to the HIL simulator or in software by accessing the ECU software variable, using feedback control will enable
the HIL system to adaptively adjust the sensor input )(tx and stabilize the output )(ty to a specified value.

2. PROBLEM DESCRIPTION
As described above, the existing mechanization in HIL based testing system to drive an output to certain range
is shown as Figure 1.
Figure 1: Normal testing mechanization
This is an open loop path and it is difficult to drive the output )(ty to within an expected range if the transfer
function from )(tx to )(ty , namely }{•f , is not clearly understood.
PROPOSED TESTING MECHANIZATION BY USING FEEDBACK CONTROL
The proposed testing mechanization is shown as Figure 2 where an output feedback loop is added. The error
between the desired )(ty and real output )(ty is used in a PID control algorithm to adjust the sensor input )(tx
dynamically to drive the real output )(ty to within an expected range.
Figure 2: Enhanced testing mechanization by introducing feedback control
There are two different methods for feedback:
Hardware: If the output under test is a direct ECU hardware output or resultant sensor input (such as throttle
position sensed by a throttle position sensor), the electrical signal can be simply connected back into HIL
simulator to provide the feedback signal. This method is called “hardware feedback” in this paper;
Software: In many cases, an algorithm output which is not a real ECU output or sensor signal is what is being
verified. In this case, “software feedback” is needed. The software feedback path should enable the HIL
simulator to access the appropriate ECU internal software variables. The HIL testing system with this
capability is shown as Figure 3. In our case the software feedback is realized by utilizing the ASAP3 protocol
[1] which enables the communication path between an ECU instrumentation tool and the HIL simulator.
ECUHIL Simulator
Input x(t) Output y(t) = f(x(t))
ECU
HIL Simulator
Input x(t) Output y(t)PID
Adjustment
y(t) set point
+
-

3. Figure 3: Hardware and software feedbacks
HARDWARE FEEDBACK CASE STUDY: THROTTLE POSITION CONTROL
In an engine controller with ETC control, the throttle blade opening angle is determined by the ETC control
algorithm. It is difficult to drive the throttle directly to a target angle if using the normal open loop testing setup
shown in Figure 1. By directly feeding the throttle position sensor signal back into the HIL simulator, a PID
feedback control algorithm was developed to drive and maintain the throttle position to the target value. The
case study includes: 1) the derivation of a first-order transfer function based ETC plant model using the throttle
step response data (from acceleration pedal position step input to throttle opening angle output); 2) the offline
Simulink model development of PID feedback control on throttle opening angle using the ETC plant model
derived in Step 1; and 3) the implementation of the PID feedback control on throttle opening angle in an HIL
simulator based testing system where a real ETC is connected.
THE FIRST-ORDER ETC PLANT MODEL – The system plant model can usually be approximated by a
transfer function [2]. The parameters of transfer function can be derived based on the experimental data of
system step response. To better understand the ETC system, Figure 4 shows the system ramp-up response from
APS input to TPS output. Based on Figure 4, we can say 1) TPS is showing a delay in responding to the APS
input (zone 1); 2) zone 2&3 are showing approximately linear response but with different slopes; and 3) TPS is
saturated to around 4 volts while APS is larger than 3 volts.
The system step response to APS step input from 0 to 3 volts is therefore selected to derive the system plant
model. Figure 5 shows the system step response data plot.
Ethernet
ECU I/O’s (Hardware Feedback Path)
ASAP3 Protocol (Software Feedback Path)
CCPProtocol
HIL Simulator
ECU
ECU Instrumentation

4. Open loop response (3500 RPM): APS --> TPS
-1
0
1
2
3
4
5
6
-5 0 5 10 15 20 25 30 35 40
Time (second)
APSandTPS(volt)
TPS2
APS1
Figure 4: Open loop ramp-up response: APS TPS
Figure 5: Open loop step response: APS (0 3 volts) TPS
Open loop ramp-up response (3500 RPM): APS --> TPS
Time range (5 -- 15 seconds)
-1
0
1
2
3
4
5
6
0 2 4 6 8 10 12 14 16
Time (second)
APSandTPS
TPS2
APS1
1 2 3 4
Step Response: APS (3V) --> TPS
-0.5
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
0 0.02 0.04 0.06 0.08 0.1 0.12 0.14
Time (S)
APS/TPS
TPS2
APS1
L=0.024 S T=0.048 S
63.2% of the amplitude

5. The first-order transfer function was derived based on the experimental data plot in Figure 5 as follows:
1048.0
077.1
1
)]/()[(
1
)(
024.0
minmaxminmax
+
=
+
−−
=
+
=
−−−
s
e
Ts
eAPSAPSTPSTPS
Ts
Ke
sF
sLsLs
(1)
where K is the system gain (1.077), L is the system delay (24 ms), and T is system time constant (48 ms) which
is corresponding to 63.2% of the amplitude in a first-order system [2].
THE THROTTLE POSITION PID FEEDBACK CONTROL MODEL DEVELOPMENT – PID control
algorithm is chosen to dynamically adjust the accelerator pedal position input to control and maintain the
throttle blade position to within a target value. The Simulink model combining the throttle plant and PID control
is developed and shown as Figure 6(a). Basically, given the error between TPS target and real TPS output, the
APS input is generated based on the classic PID formula as below:
dt
tde
KdeKteKtAPStAPS
TPStTPSte
d
t
ip
ett
)(
)()()()(
)()(
0
0
arg0
+++=
−=
∫ ττ
(2)
The closed loop control simulation results are shown in Figure 6(b) where the TPS output is quickly driven to
and maintained around the new set point, 4 volts, by dynamically adjusting the input, APS.
(a) Throttle plant and PID close loop control model
(b) Close loop control simulation results: TPS target (0 4 V) TPS output
Figure 6
TPS
TPS
target
APS

6. Page 6 of 11
IMPLEMENTATION OF PID FEEDBACK CONTROL IN THE HIL BASED TESTING SYSTEM – The PID
feedback control of throttle position was implemented in a HIL based engine controller testing system. Figure
7(a) shows the Simulink model which was used to generate the HIL executable code through The Mathworks
Real-Time Workshop (RTW). Figure 7(b) shows the resulting HIL logged throttle blade position control data.
(a) HIL model with TPS PID control
(b) HIL system logged close loop TPS control results
Figure 7
TPS TPS target APS

7. Page 7 of 11
SOFTWARE FEEDBACK USING ASAP3 PROTOCOL
The hardware feedback method described in the section above directly connects the physical signal back to the
HIL system and is able to control the output in essentially a real-time fashion. Nevertheless, in many cases, we
need to test algorithm outputs which are intermediate software variables only and do not have physical output
signals. It is challenging to design a test script to drive an algorithm output to an expected value without a good
definition of the algorithm under test.
ASAP3 is a standard RS232 based communication protocol between the Automation System (AuSy) and the
Measurement Calibration System (MC System) which is widely accepted in automotive industry. The market
representative HIL simulators such as dSpace and XPC, and calibration tools such as ETAS INCA and ATI
Vision all have build-in ASAP3 protocols. With ASAP3 capability, the HIL simulator is able to monitor the
ECU control algorithm states by accessing the ECU internal variables. The access of ECU internal variables
also provides the HIL system the feedback path, referred as software feedback in this paper.
INTRODUCTION TO ASAP3 – Figure 8 shows the basic hardware structure while using ASAP3
communications in an HIL based ECU testing system. Basically, the MC system (Measurement Calibration
System) such as ETAS INCA or ATI Vision is used to monitor the ECU software variables and to set
calibrations as well. By ASAP3 communications which use an RS232 connection between the AuSy
(Automation System such as dSpace or XPC) and the MC, the AuSy is able to access the ECU software
variables and set calibrations.
Figure 8: ASAP3 communication hardware structure in HIL based ECU testing system

8. Page 8 of 11
ASAP3 protocol includes different types of commands: initialization/identification; configuration; map
manipulation; measurement data recording; parameter manipulation; recorder; miscellaneous. The detail list of
commands can be found in reference [1]. The ASAP3 commands used in this study is shown in Table 1.
Table 1: List of ASAP3 commands in version 2.1
Initialization, Identification,
Emergency
Code
EMERGENCY 1
INIT 2
IDENTIFY 20
EXIT 50
Measurement Data Recording Code
PARAMETER FOR VALUE
ACQUISITION
12
SWITCHING OFFLINE/ONLINE 13
GET ONLINE VALUE 19
The ASAP3 communications are initiated from the Master (AuSy) to the Slave (MC system) and the software
handshake is needed back from the Slave (MC system). The basic sequence of ASAP3 communications is:
- The MC system periodically checks for an incoming AuSy command;
- The AuSy sends a command and waits an answer from the MC sytem;
- The MC system reads the command, performs all necessary actions and sends the answer back to the
AuSy;
- The AuSy receives the answer.
SOFTWARE FEEDBACK USING ASAP3 IN HIL BASED TESTING SYSTEM – The ASAP3
communication starts with “INIT” (code 2) and ends with “EXIT” (code 50) commands from the AuSy. Figure
9 shows the script flow chart which was used to capture ECU internal software variables through ASAP3
protocol for feedback control purpose.
Figure 10(a)-(d) show the 4 different cases where 4 different ECU internal variables, ETPS2RAW (raw value of
throttle position sensor 2), ETPSDES (desired throttle position), AIRFLOW (calculated final airflow),
CTQ_DIFT (desired flywheel torque), are fed back to the HIL through the ASAP3 protocol, respectively. In
each case, the script running in the HIL system performs a PID control algorithm to adjust APS input and drive
the corresponding ECU variable to the target value. It is challenge to achieve this without using feedback
control (PID control in this study) because 1) the transfer functions between APS input and the outputs are
usually not well understood by test engineers; 2) the transfer functions might be highly non-linear so it is
difficult to stabilize the outputs using only open loop control.
From data logs in Figure 10, we can see that, due to the time delay in ASAP3 communications, it takes
approximately 800 ms for the HIL to get a feedback from ECU instrumentation tool. Namely, there is always a

9. Page 9 of 11
noticeable response delay from set point changes to feedback value changes, which is the disadvantage of the
software feedback method compared to the hardware feedback method control as described in the previous
section. Nevertheless, due to most algorithm outputs are not available in hardware feedback path, the software
feedback of almost unlimited ECU internal variables indeed makes the software feedback method very useful in
HIL based ECU testing system.
Figure 9: Access ECU software variables through ASAP3 protocol
(a) Feedback control on raw throttle position 2
ETPS2RAW target
ETPS2RAW
Raw Throttle Position 2 Control

10. Page 10 of 11
(b) Feedback control on desired throttle position
(c) Feedback control on air flow
(d) Feedback control on desired flywheel torque
Figure 10
ETPSDES target
ETPSDES
Desired Throttle Position Control
AIRFLOW target
AIRFLOW
Air Flow Variable Control
CTQ_DIFT target CTQ_DIFT
Internal Desired Flywheel Torque Variable Control

11. Page 11 of 11
SUMMARY/CONCLUSIONS
We have proposed and implemented a method to use PID feedback control in an HIL based ECU testing system
to drive the ECU external hardware outputs or internal software variables to a desired target value. This
enhancement of the testing capability is especially useful where the transfer function from the sensor inputs to
the controlled signal is not fully understood by the test engineers. Two specific methods of obtaining the
feedback, using a direct hardware signal and using an ECU internal software variable, are evaluated. The direct
hardware signal feedback scheme has the advantage of faster control response time but it is limited to the cases
where the corresponding hardware signal is available. On the other hand, ECU internal software variable
feedback achieved by using the ASAP3 protocol is able to provide the HIL system the feedback of all ECU
software variables which are monitored by the instrumentation tool, although the RS232 based ASAP3 protocol
does have the issue of slower control response due to the time delay caused by the RS232 serial data
transmission.
In the future additional work will be focused on the following areas:
1. The adaptive PID control can be introduced to improve the currently implemented standard PID
algorithm. This includes adaptive gains corresponding to the error amount, so there is no need to re-tune
PID gains when controlling different hardware or software variables;
2. Improve the response time in ASAP3 based feedback by using a faster baud rate and optimizing scripts;
3. Explore the possibility to use ASAM MCD3 [3], which is a much newer calibration tool interface than
ASAP3 and has the advantages of higher throughput, synchronous data acquisition, and central data
storage, to improve the system performance for the application described in this paper.
REFERENCES
1. ASAP3-MC Interface Specification, Version 2.1.1, 1999.
2. Katsuhiko Ogata, Modern Control Engineering, Fourth Edition, Prentice Hall, 2006.
3. ASAM MCD-3 Application Programming Interface Specification, Version 2.2.0, 2008.
CONTACT INFORMATION
Yixin Chen, PhD
Senior Electronics Systems Engineer
Delphi Corporation
yixin.chen@delphi.com
Rob Carpenter
Staff Engineer
BeijingWest Industries
robert.d.carpenter@bwigroup.com