Hardware-in-the-Loop Testing: What It Is & When You Need It

A flight control algorithm passes every simulation on a desktop workstation. The math checks out, the logic is sound, and the team moves to integration. Then, running on the actual electronic control unit (ECU) with real analog signals and millisecond timing constraints, the controller drops samples during a fast transient and clips an internal variable. The algorithm that looked stable in simulation misbehaves the moment it meets fixed-step execution and physical input/output (I/O) latency.

Hardware-in-the-loop testing addresses the gap between simulated behavior and real hardware performance. HIL testing catches defects that pure software simulation can miss, including timing violations, I/O electrical interface mismatches, and signal quantization errors that may only appear when production code runs on the target processor under real-time constraints.

This post covers what HIL testing is, how the loop works, when teams need it, and how HIL results connect to the requirements they verify.

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

In HIL testing, an embedded controller or ECU connects to real-time hardware that runs software models of the system it controls. The device under test (DUT) is the only real physical component. Everything else, including the plant, sensors, actuators, and the operating conditions, is replaced by a digital twin running on dedicated real-time hardware.

The closed-loop architecture includes four components:

Real-time processor: Runs the plant model at wall-clock speed on a dedicated real-time operating system (RTOS).
I/O interfaces: Produce analog and digital stimulus signals so the DUT perceives a real physical system.
Device under test: Runs production embedded software on the actual target microcontroller.
Operator interface: A separate host PC handling test automation, visualization, and reporting.

Software-in-the-loop (SIL) executes compiled control code on a simulated plant on a desktop and runs faster than wall-clock time for large parameter sweeps, but it can’t detect hardware-specific failures such as interrupt latency, ECU driver behavior, or I/O electrical interface problems. HIL catches those failures because the DUT runs with real electrical connections and real-time scheduling. Unlike full physical prototype testing, HIL lets teams exercise dangerous fault conditions, extreme conditions, and edge cases that would risk injury, equipment loss, or prohibitive cost on real hardware.

How Hardware-in-the-Loop Testing Works

Three subsystems work together in each HIL test cycle: the real-time simulation loop, the signal-conditioning setup, and the fault-injection methods.

The Real-Time Simulation Loop

The plant model, developed in a modeling environment like Simulink, is compiled into executable code and deployed on the real-time target. Each computation cycle follows a strict sequence. The simulator reads the DUT’s actuator outputs, advances the plant model state, and writes updated sensor values back to the DUT’s inputs.

This entire cycle must complete within the allocated time step, often measured in microseconds for power electronics applications. If the plant model computation exceeds the time step, the system can trigger a task overrun, and the test may be invalidated.

How the I/O Layer Fakes a Real System

The I/O subsystem creates the electrical illusion of a real system around the DUT. Analog and digital channels carry sensor emulation signals to the DUT’s input pins and read actuator commands from its output pins. Communication bus interfaces handle protocol-level interactions over Controller Area Network Flexible Data-Rate (CAN FD), Local Interconnect Network (LIN), FlexRay, and Automotive Ethernet.

How Fault Injection Forces the Edge Cases

Fault injection testing verifies that a controller can respond to and recover from failures without compromising safety. HIL systems use several injection methods:

Hardware fault insertion units (FIUs): Modules that programmatically switch signals between normal operation and fault conditions like open circuits, short-to-ground, or short-to-supply voltage.
Software-level sensor manipulation: Stuck-at values, offset biases, noise injection, and complete signal dropout are applied to the plant model’s computed sensor values before output.
Communication bus fault injection: Corrupted frame content, delayed message transmission, and dropped messages that simulate node failures are injected into serial bus traffic.
Plant model scenario changes: Modifications to the simulated system that push the controller into operating regions too dangerous to reproduce on a bench, such as grid faults in power electronics or engine stall conditions in aerospace.

Simulated conditions and fault injection are part of embedded software verification and validation work.

When Do You Need Hardware-in-the-Loop Testing?

You typically need HIL when one of four situations applies.

When a Failure Could Hurt Someone

When a software defect on real hardware poses risks of injury, equipment loss, or environmental damage, HIL provides a controlled setting to exercise failure modes that physical testing can’t safely reproduce. HIL helps teams verify failure handling in a lab setting without exposing people or equipment to the same level of risk as live physical testing. Power electronics teams face the same constraint because fault injection on grid-connected converters involves voltages and currents that make physical testing dangerous.

When You Can’t Reach or Rerun the System

Real-time ground simulation is valuable when the deployed system cannot be easily retrieved or repeatedly tested in its operating conditions. The MOVE-II CubeSat HIL lets the satellite interact with a simulated space environment in real time during ground tests. HIL simulators are also used in aerospace verification during ECU software development.

When You Have to Retest on Every Build

Firmware regression suites that must run continuously across revisions need automated, repeatable execution. HIL test systems allow repeatable lab-based execution across many test scenarios for each firmware build. As vehicles receive over-the-air (OTA) updates that directly affect performance and safety, the update validation pipeline creates a recurring HIL use case distinct from traditional regression testing.

Which Programs Actually Require HIL Evidence?

DAL A and DAL B programs under DO-178C require on-target hardware testing as part of the verification record. Under ISO 26262, ASIL C and ASIL D items require hardware integration testing with production-representative code. IEC 61508 SIL 3 and SIL 4 functions carry equivalent expectations. Where a safety standard expects proof that production code behaves correctly on the real processor, HIL is the practical way to produce that evidence at scale.

How Do Safety Standards Treat HIL Testing?

Each standard uses a different safety classification taxonomy, and all three include verification activities such as on-target hardware testing, fault handling, and hardware integration verification. The table below maps how HIL appears in each framework and which coverage and process expectations apply to each.

Dimension	DO-178C (Aerospace)	ISO 26262 (Automotive)	IEC 61508 (Industrial)
Safety level taxonomy	Design Assurance Level (DAL) A through E (A most critical)	Automotive Safety Integrity Level (ASIL) A through D (D most critical)	Safety Integrity Level (SIL) 1 through 4 (4 most critical)
How HIL appears	On-target testing as part of software and integration verification	Used as a test method in practice	Supports hardware and software integration verification
Structural coverage	Modified Condition/Decision Coverage (MC/DC) at DAL A, decision coverage at DAL B, statement coverage at DAL C	Structural code coverage expectations generally become more rigorous at higher safety assurance levels than at lower ones	SIL-graded per Part 3 technique tables
Process framework	ARP4754A (system) with DO-178C (software) and DO-254 (hardware)	ISO 26262 Parts 4/5/6 with Automotive SPICE (ASPICE) SWE.4/5/6	IEC 61508 Parts 1 through 7

Why a Passing HIL Test Only Counts When It Traces to a Requirement

A passing HIL test only helps with compliance when the test case traces to a verified requirement. Without that link, a passing test proves hardware works but doesn’t demonstrate that a specific requirement has been satisfied.

How to Link Test Cases to Requirements

Functional requirements and safety goal specifications are the basis for creating HIL test scenarios. The traceability chain across artifacts links the system requirement, safety requirement, HIL test case, and test result. Safety programs often require documented, traceable verification results to meet safety requirements.

How Bidirectional Traceability Turns Tests Into Evidence

Bidirectional traceability links every requirement to its test cases and every test artifact to its originating requirement. Forward traceability confirms every requirement has been implemented and tested. Backward traceability confirms that no test or design artifact exists without a corresponding requirement. These end-to-end traceability links matter because they turn passing tests into a defensible argument for coverage.

How to Catch Uncovered Requirements Before Integration

Coverage gaps discovered during certification review require rework cycles, delaying clearance. Automated traceability analysis surfaces requirements without the need for linked HIL verification, while changes remain inexpensive to address.

How Jama Connect Helps With Hardware-in-the-Loop Testing

Traceability gaps and impact analysis problems can weaken the value of HIL evidence when requirements, tests, and risks drift out of sync. Jama Connect®, a requirements management and traceability platform for regulated product development, links HIL test cases, requirements, and risk items through Live Traceability™. When a requirement changes, the suspect link mechanism automatically flags every downstream artifact, including linked test cases and risk assessments, for reassessment.

Jama Connect’s Test Management Center connects test status directly to requirements. Traceability Information Models (TIMs) define the development workflow and detect when required downstream items are missing.

Building Hardware-in-the-Loop Testing Into Your Verification Plan

Hardware-in-the-loop testing closes the gap between simulation and real hardware by exposing timing, interface, and integration problems before they become late-stage failures. A HIL result carries the most weight when it traces back to the requirement it verifies, which keeps the evidence audit-ready rather than something a team has to reconstruct under deadline pressure. If your HIL results live in a test log disconnected from the requirements they verify, Jama Connect keeps that link live, and you can see it on your own program with a free 30-day trial.

Frequently Asked Questions About Hardware-in-the-Loop Testing

What is the difference between HIL and SIL testing?

SIL is usually the better fit when the main goal is to iterate quickly, run large parameter sweeps, and check control logic before hardware timing becomes the dominant risk. HIL is the better choice when verification needs to show how production code behaves on the target microcontroller.

How much does a HIL test setup typically cost?

No major HIL vendor publishes standard pricing because configurations vary by I/O count, performance tier, and complexity. The more useful budgeting question is cost relative to the alternatives. SIL is lowest, HIL is moderate, and full physical prototype testing is highest, so teams usually justify HIL when they need repeatable, on-target hardware evidence without incurring the cost and risk of constant physical prototype testing.

Can HIL testing fully replace physical prototype testing?

No. HIL is useful for shifting dangerous, expensive, or hard-to-repeat scenarios into a controlled lab environment earlier in the verification process. Physical prototype testing still matters when the goal is to confirm full-system behavior against physical reality, especially where environmental interactions, manufacturing variability, and system-of-systems effects cannot be represented completely by the simulation model.

When in the development cycle should HIL testing begin?

HIL testing belongs on the right side of the V-model, after ECU hardware is available, placing it in the integration and system verification phases. One way to choose the handoff point is to watch what is causing uncertainty. As long as software logic churn is still the bigger issue, SIL usually carries more value. Once timing, interfaces, and target hardware behavior become the main sources of risk, HIL is the better next step.

Author
Recent Posts

Mario Maldari

Director of Product and Solution Marketing at Jama Software

Mario Maldari is Director of Product and Solution Marketing at Jama Software, where he focuses on requirements management and systems engineering solutions for regulated industries. He brings over 2 decades of experience across solution architecture, technical pre-sales, and software quality, and holds patents in traceability and structured data. Before moving into product marketing, he worked directly with engineering teams to solve compliance and requirements challenges.

What Is Hardware-in-the-Loop (HIL) Testing, and When Do You Need It?