hardware-in-loop-reference

Overview

Hardware-in-the-loop (HIL) is, per en.wikipedia.org/wiki/Hardware-in-the-loop_simulation (opens in new window), "a technique that is used in the development and testing of complex real-time embedded systems" that "provides an effective testing platform by adding the complexity of the process-actuator system, known as a plant, to the test platform". In practice it means: the production ECU runs production firmware against a real-time simulator that emulates the rest of the vehicle / aircraft / machine in closed loop, with the same electrical interfaces the ECU sees in the field.

This skill is a pure reference consumed by the per-tool skills (googletest-embedded-arm, unity-test-framework-c, qemu-system-test-runner) when teams need to decide what slips into HIL versus what stays in host / QEMU.

When to use

• Scoping a new HIL rig - what hardware, what protocols, what level of plant fidelity.
• Reading an HIL test report from a vendor (NI / dSPACE / Vector / Speedgoat) and translating their proprietary terms.
• Negotiating the V-model split (MIL / SIL / PIL / HIL) with safety engineering.
• Pairing HIL coverage with structural coverage from embedded-coverage-strategy-reference.
• Specifying fault-injection scenarios for a safety case.

The HIL pattern

+-------------------+         analog/digital I/O      +-------------------+
|                   | <----------------------------- |                   |
|  Real-time        |   CAN / CAN-FD / LIN / FlexRay |  ECU under test   |
|  plant simulator  | <----------------------------- |  (production       |
|  (vehicle / motor |                                |  firmware,         |
|  / battery model) | -----------------------------> |  production HW)    |
|                   |   wheel speed, temp, voltage,  |                   |
+-------------------+   pedal position, error codes  +-------------------+
        |
        | fault injection: short-to-ground / open / corrupt-bus / drift
        v
   Test sequencer + scenario scripts

Per Wikipedia (citation above), the rig "must include electrical emulation of sensors and actuators" - that emulation is what distinguishes HIL from pure software simulation. The ECU sees voltage / current / bus traffic, not numbers in RAM.

V-cycle: MIL → SIL → PIL → HIL

(The terms MIL / SIL / PIL / HIL are not in Wikipedia's HIL article but are universal in automotive ECU verification - cite by stable term "automotive V-model verification stages".) Each stage tightens the realism by replacing one block with the real artefact. HIL is the last gate before SOP (Start Of Production) sign-off.

Vendor stack at a glance

Vendor product pages are largely gated (Cloudflare / login walls); cited by stable ID.

The reader should treat vendor choice as a procurement decision, not a technical one - all the vendors support the core HIL pattern. Vendor differentiation is in I/O density, FPGA latency, and which test-authoring language the team has skill in (CAPL for Vector, LabVIEW for NI, Simulink for Speedgoat).

Bus emulation per protocol

Vector's CANoe is the de-facto authoring tool for the first five rows; NI VeriStand and dSPACE wrap their own driver stacks.

Fault-injection patterns

The reason HIL exists. Sw-only sims can't reproduce these:

These map directly to ISO 26262-5 fault models - see standard expectations below.

Safety-standard alignment

Cited by stable ID - the standards are gated, not WebFetchable.

Test evidence the HIL produces

A typical HIL test report - the artefacts a certifier expects to see - contains:

1. System Definition (NI: .nivssdf; dSPACE: SCALEXIO project) - the I/O map + plant-model binding. The "what is wired to what".
2. Stimulus profile / scenario script - the test inputs over time. Vector calls these "test modules" (CAPL); NI "real-time sequence" or "stimulus profile"; dSPACE "AutomationDesk sequence".
3. Recorded signals - every bus message + analog channel for the duration of the test, indexed by simulation time.
4. Pass / fail verdict - each scenario asserts on expected signal values, expected DTCs, expected timing.
5. Coverage artefact - pair with embedded-coverage-strategy-reference; on-target structural coverage is captured via semihosting or a debug probe write-back.
6. Traceability - each scenario links back to a requirement ID (Polarion / DOORS / Jama). Required for any DAL or ASIL claim.

CAPL / VeriStand stimulus example shapes

CAPL test module (Vector CANoe - cite "Vector CANoe 17 CAPL Function Reference"):

testcase Test_Brake_Latency()
{
    SetSignal(Vehicle::BrakePedal, 0.0);
    TestWaitForTimeout(100);
    SetSignal(Vehicle::BrakePedal, 1.0);
    if (TestWaitForSignalMatch(ECU::BrakeOutput, 1.0, 50) == 0)
        TestStepPass("Brake output engaged within 50 ms");
    else
        TestStepFail("Brake output did not engage in 50 ms");
}

NI VeriStand real-time sequence (cite "NI VeriStand 2024 Real-Time Sequence Editor Help"):

SetChannelValue Inverter/Throttle 0.0
Wait 100 ms
SetChannelValue Inverter/Throttle 1.0
WaitUntilSettled Motor/Torque == 50.0 (tolerance 5.0, timeout 200 ms)
ReportTestResult

The two languages encode the same scenario - choose the one the team is fluent in.

Anti-patterns

Limitations

• Plant-model fidelity is the ceiling. HIL can only test what the plant model knows about. A motor model that omits thermal derating won't reveal a missing thermal-protection feature.
• Cost. A rig is $50k - $2M; rig-hours are scheduled like CT scanners. Push left aggressively.
• Throughput. Real-time means real time - a 60-second drive cycle takes 60 seconds to test. Parallel rigs help; faster-than- real-time isn't an HIL property.
• Vendor lock-in. Test assets in CAPL don't run on VeriStand and vice-versa. Architectural decision at procurement time.
• EMC / RF effects not modelled. HIL is electrical-emulation; it doesn't reproduce field-strength effects. Pair with EMC chamber tests for the safety case.
• Battery / chemistry models drift. Long-duration EV tests need refreshed cell models or the SoC accounting diverges.

References

Cited inline. Foundational documents:

• Wikipedia, "Hardware-in-the-loop simulation" - en.wikipedia.org/wiki/Hardware-in-the-loop_simulation (opens in new window).
• Vector CANoe 17 User Manual (gated - cite by stable ID at www.vector.com/int/en/products/products-a-z/software/canoe/ (opens in new window)).
• NI VeriStand 2024 documentation (gated - cite by stable ID at ni.com/.../what-is-veristand.html (opens in new window)).
• dSPACE SCALEXIO 2024 / ControlDesk 2024 Help (gated - cite by stable ID).
• ISO 11898-1:2015 (CAN), ISO 17987-1:2016 (LIN), ISO 17458-1:2013 (FlexRay) - gated standards, cite by stable ID.
• IEEE 802.3bw-2015 (100BASE-T1), IEEE 802.3bp-2016 (1000BASE-T1) - gated standards, cite by stable ID.
• AUTOSAR FO R23-11 SOME-IP Protocol Specification - open standard available from www.autosar.org (opens in new window) (subject to registration).
• DO-178C §6.4.4 Structural Coverage, DO-254, ISO 26262-4 §7 / ISO 26262-5 §10, IEC 61508-3 Table A.5, IEC 62304 - gated standards, cite by stable ID.
• Sibling reference: embedded-coverage-strategy-reference.