Hardware-in-the-Loop (HIL) simulation — real hardware, simulated plant

What Is Hardware-in-the-Loop (HIL)?

WHAT makes it different from Software-in-the-Loop (SIL):

• SIL: Controller code runs on your PC, both controller and plant are simulated software
• HIL: Controller runs on the real target hardware, only the plant is simulated

HOW it works (closed-loop cycle):

1. ECU outputs actuator command (e.g., PWM duty cycle for throttle) via physical pin
2. HIL simulator reads that signal through I/O hardware
3. Simulator updates plant model (calculates new engine RPM, vehicle speed, etc.) in real-time
4. Simulator generates new sensor readings (throttle position, speed, temperature)
5. I/O hardware converts simulator values to analog voltages / digital signals
6. ECU reads these signals through its ADC / GPIO / CAN bus
7. ECU runs control algorithm with new sensor data → repeat at 1

Why Use HIL? The Problem It Solves

THE PAIN POINT: You've written embedded control software for a rocket engine controller. Testing options:

t_{\text{compute}} < t_{\text{sim step}} \leq t_{\text{real}}

$$\Delta t_{\text{sim}} < \Delta t_{\text{real}}$$ **WHY**: If the ECU sends a PWM command at $t=0.001$s, the simulator must compute the resulting motor torque and send back encoder readings **before** the ECU's next control cycle at $t=0.002$s. If the simulator lags, the ECU experiences "time dilation" and control loops become unstable. **HOW we achieve this**: - Use dedicated real-time processors (FPGAs, real-time operating systems with hard deadlines) - Simplify plant models (trade accuracy for speed, e.g., use lookup tables instead of solving ODEs numerically) - Use **fixed-step solvers** (no adaptive step size that could cause unpredictable computation time)

Signal Types & Interface Hardware

I/O Interface Box (e.g., dSPACE, Speedgoat, NI PXI):

• ADC to read ECU's analog outputs (e.g., 0-5V throttle position command → digital value for simulator)
• DAC to generate analog sensor signals (simulator calculates temperature → DAC outputs 2.3V to ECU's ADC pin)
• Digital I/O for GPIO, encoders, PWM capture/generation
• Protocol interfaces (CAN, LIN, FlexRay transceivers)

Derivation: HIL Plant Model Update

SCENARIO: ECU controls DC motor speed. We'll derive the HIL simulator's update equations.

Plant physics (DC motor): $\tau_{\text{motor}} = K_t \cdot I \quad \text{(torque proportional to current)}$ $V = R \cdot I + L \frac{dI}{dt} + K_e \cdot \omega \quad \text{(voltage equation)}$ $J \frac{d\omega}{dt} = \tau_{\text{motor}} - \tau_{\text{load}} - b \cdot \omega \quad \text{(rotational dynamics)}$

WHERE:

• $\tau_{\text{motor}}$: motor torque (N·m)
• $I$: motor current (A)
• $\omega$: angular velocity (rad/s)
• $V$: applied voltage (ECU's PWM duty cycle × battery voltage)
• $K_t$: torque constant (N·m/A)
• $K_e$: back-EMF constant (V·s/rad)
• $J$: rotor inertia (kg·m²)
• $b$: damping coefficient (N·m·s/rad)
• $R, L$: motor resistance (Ω), inductance (H)

WHY these equations: They're first-principles physics: voltage drives current (Kirchoff), current produces torque (Lorentz force), torque accelerates rotor (Newton's 2nd law).

DISCRETE-TIME update (Euler integration, time step $\Delta t$):

Step 1: ECU outputs PWM duty cycle $D(t_k)$ (e.g., 0.7 for 70%).

Why this step? The PWM signal is the only input the simulator receives from the real ECU.

$V(t_k) = D(t_k) \cdot V_{\text{battery}}$ Step 2: Solve for current using simplified voltage equation (assuming L small, quasi-static): $I(t_k) \approx \frac{V(t_k) - K_e \cdot \omega(t_k)}{R}$ Why quasi-static? If $L \frac{dI}{dt} \ll R \cdot I$, we can ignore inductance for faster computation. For high-frequency dynamics, use full ODE solver.

Step 3: Compute motor torque: $\tau_{\text{motor}}(t_k) = K_t \cdot I(t_k)$

Step 4: Update angular velocity (Euler): $\omega(t_{k+1}) = \omega(t_k) + \frac{\Delta t}{J} \left( \tau_{\text{motor}}(t_k) - \tau_{\text{load}} - b \cdot \omega(t_k) \right)$

Why Euler? Simple, fast. For stiff systems, use implicit methods (backward Euler), but adds computational cost.

Step 5: Update angular position: $\theta(t_{k+1}) = \theta(t_k) + \omega(t_k) \cdot \Delta t$

Step 6: Generate sensor signal (encoder pulse count): $\text{Encoder count} = \left\lfloor \frac{\theta(t_{k+1})}{2\pi} \cdot \text{PPR} \right\rfloor$ where PPR = pulses per revolution.

Step 7: HIL I/O box sends encoder pulses to ECU's timer input.

TIMING CONSTRAINT: All steps1-7 must complete in less than $\Delta t$ (e.g., if ECU control loop is 1kHz, $\Delta t = 1$ms). Typical HIL simulators run at 1-10 kHz update rates.

Worked Example: Testing Engine Controller HIL

SYSTEM: Automotive engine ECU controls throttle and ignition timing. We'll test idle speed control.

Example1: Normal Operation Test

Objective: Verify ECU maintains 800 RPM idle when engine starts.

HIL Setup:

• Plant model: 4-cylinder engine thermodynamic model (intake manifold pressure, combustion torque, crankshaft dynamics)
• ECU inputs: Throttle position sensor (TPS), crankshaft position sensor (CKP), manifold absolute pressure (MAP)
• ECU outputs: Throttle motor PWM, ignition coil trigger signals

Test sequence:

1. Simulator initializes: engine speed = 0RPM, coolant temp = 20°C
2. Simulate key-on: ECU boots, initializes peripherals
3. Simulate starter motor: Simulator gradually ramps engine speed0 → 200 RPM
4. ECU detects cranking, starts fuel injection and spark
5. Simulator combustion model fires based on ECU's ignition timing → torque generated
6. Engine speed rises to ~1200 RPM (cold start enrichment)
7. As engine warms (simulator updates coolant temp), ECU reduces throttle
8. PASS criterion: Engine speed settles to 800 ± 20 RPM within 10 seconds

Why each step?

• Step 1-2: Validates ECU boot sequence (tests initialization code on real hardware)
• Step 3: Mimics real starter motor behavior (ECU must detect cranking via CKP sensor)
• Step 4-5: Tests fuel injection timing and ignition advance calculations
• Step 6-7: Tests closed-loop idle speed controller (PID algorithm)
• Step 8: Quantifies control performance (settling time, overshoot)

Data collected:

• ECU's throttle command (PWM duty cycle) vs. time
• Simulated engine speed vs. time
• Fuel injection pulse width vs. time

DEBUGGING: If engine speed oscillates (800 → 850 → 750 → 800..), indicates PID gains too aggressive. Adjust Kp/Ki/Kd in ECU firmware, recompile, flash, re-run test in minutes (vs. hours tuning on dyno).

Example 2: Fault Injection Test

Objective: Verify ECU detects stuck throttle and limits engine speed.

Test sequence:

1. Run normal idle test (as above), wait for steady-state 800 RPM
2. At $t=5$s, simulator freezes TPS signal at current value (simulates stuck sensor)
3. Simultaneously, simulator injects throttle plate stuck at 15° open (more air than commanded)
4. Engine speed rises due to excess air
5. PASS criterion: ECU detects TPS/actual-speed mismatch, activates "limp-home" mode (limits throttle to 10° max, sets diagnostic trouble code (DTC) P0122), prevents runaway

Why this test? Real throttle bodies can fail mechanically. This tests safety-critical fault detection logic that's impossible to test on a real engine without intentionally breaking parts.

Example 3: Extreme Temperature Test

Test: Engine start at -40°C ambient.

HIL advantage: Simulator sets initial conditions to -40°C. Tests cold-start fuel enrichment logic without neding a climate chamber or waiting hours for engine to freeze.

PASS criterion: Engine starts within 3 crank attempts, no misfire codes.

Common Mistakes & Steel-Manning

Active Recall Flashcards

#flashcards/coding

What is Hardware-in-the-Loop (HIL) simulation? :: A testing technique where the real embedded controller hardware runs production code and interfaces with a real-time simulator that emulates the physical system (plant) through actual I/O signals (analog, digital, bus protocols).

Connections

• Model-in-the-Loop (MIL) — Pure software simulation, earliest testing stage
• Software-in-the-Loop (SIL) — Compiled code on PC, no hardware
• Processor-in-the-Loop (PIL) — Code runs on target processor model/emulator
• Hardware-in-the-Loop (HIL) — YOU ARE HERE
• Vehicle-in-the-Loop (VIL) — Real vehicle on dynamometer test rig
• Real-time Operating Systems (RTOS) — Deterministic scheduling for HIL simulators
• CAN Bus Protocol — Common ECU communication tested in HIL
• PWM (Pulse Width Modulation) — Actuator control signal type in HIL
• PID Control — Algorithm being tested in HIL (e.g., engine idle speed)
• Fault Injection Testing — Safety validation technique enabled by HIL
• System Identification — Deriving plant models from real-world data for HIL accuracy
• FPGA for Real-Time Simulation — High-speed plant model execution

Summary

Hardware-in-the-Loop bridges the gap between software simulation and real-world deployment. By running production code on real embedded hardware while simulating the physical system, you catch integration bugs, validate timing requirements, and test dangerous edge cases safely. The key challenges are maintaining hard real-time performance (simulator must run faster than real-time), ensuring I/O interface fidelity (match real signal characteristics), and using sufficiently accurate plant models (validated against real data). HIL is essential for safety-critical systems where field failures are unacceptable—automotive ECUs, flight control computers, medical device controllers—enabling exhaustive automated testing before the first physical prototype runs.

Concept Map

Hinglish (regional understanding)

Hinglish (regional understanding)