Hardware-in-the-loop (HIL) testing for autonomous systems

What HIL testing is and why it is load-bearing for autonomous systems

Hardware-in-the-loop testing connects a real electronic control unit (ECU), domain controller, sensor, or actuator interface to a real-time simulation of the vehicle plant and environment. The unit under test “sees” the simulated world as if it were installed in a real vehicle, while the test bench can inject faults, edge cases, and repeatable scenarios that would be dangerous, illegal, or impossible to run on public roads.

ISO 26262-1:2018, the functional-safety vocabulary for road vehicles, defines the relevant terms for hardware/software integration and testing; HIL is widely used as a verification method for the integration levels required by ISO 26262-4 and ISO 26262-6. The same HIL infrastructure is referenced in safety-of-the-intended-functionality work because simulation and fault injection are needed to find triggering conditions that are not covered by deterministic functional-safety analysis (ISO 26262-1:2018, [iso.org ; ISO 21448:2022, [iso.org ).

For autonomous systems specifically, HIL is not optional “lab nicety.” An autonomy stack contains:

• perception hardware/software consuming camera, lidar, radar, GNSS, V2X, and inertial data;
• fusion and prediction software;
• planning and control software;
• safety monitors; and
• actuators/actuator interfaces.

Many failure modes involve timing, hardware/software interaction, sensor dropout, or electromagnetic interference. These cannot be fully exercised in software-only simulation, and cannot be safely exercised on public roads early in development. HIL sits between software-in-the-loop and vehicle-in-the-loop, preserving real electronics and real timing while keeping the physical environment virtual (dSPACE simulator system description, [dspace.com ; MathWorks Simulink Real-Time, [mathworks.com ).

A control-theoretic reason HIL exists is that a controller designed against a continuous-time plant model can behave differently when sampling, scheduler jitter, I/O latency, and communication delays are introduced. HIL is the standard method for testing that interaction before a vehicle integration test (Bacic, “On hardware-in-the-loop simulation,” Proc. 44th IEEE Conference on Decision and Control, 2005, DOI: 10.1109/CDC.2005.1582653 — needs primary source validation).

Physical and logical architecture of an autonomous-system HIL rig

A typical autonomous-system HIL bench has these layers:

1. Real-time target computer. Executes vehicle dynamics, environment, traffic, and sensor models deterministically. Modern targets use hard real-time operating systems and FPGA-based I/O for low-latency signal generation/capture.
2. I/O and bus interfaces. Automotive Ethernet, CAN/CAN FD, LIN, FlexRay, PCIe, serial, PWM, digital/analog I/O, and fault-insertion switches.
3. Sensor simulation. Camera data is injected as raw video into the domain controller; radar is injected as RF echoes or object lists; lidar is injected as point clouds; GNSS is injected as RF or digital observables.
4. Actuator/environment emulation. Motor drives, steering/braking loads, battery models, thermal models, and vehicle motion states.
5. Scenario and test-management layer. Selects/catalogs scenarios, drives modeled actors, injects faults, checks response, logs results.

This description is self-reported by the main commercial vendors: dSPACE, NI (now part of Emerson), MathWorks, ETAS, Vector, IPG, and AVL (dSPACE, [dspace.com ; NI automotive HIL, [ni.com ; ETAS LABCAR, [etas.com ; Vector VT System, [vector.com ; IPG CarMaker, [ipg-automotive.com ).

The autonomous-specific difficulty is that perception is data-driven. A pure vehicle-dynamics HIL rig from 2010 needed only CAN and analog I/O. An ADAS/AD HIL rig must reproduce raw sensor streams at useful frame rates and with timing/jitter consistent with the real sensors. Vendors therefore add “sensor interface units” or “domain-specific front ends.” This is a marketing/engineering claim from the vendors; independent benchmarking of these interfaces is sparse, which is itself a source-bound finding.

Worked calculation: real-time loop delay budget

Because autonomous control loops are cyber-physical, small added latencies reduce phase margin and can destabilize a feedback loop. A standard first-order approximation for the phase-margin loss caused by a pure delay is:

\[

\Delta \phi_{deg} = 360^\circ \times f_c \times T_d

\]

Then the allowable delay for a given allocated phase loss is:

\[

T_d = \frac{\Delta \phi_{deg}}{360^\circ \times f_c}

\]

Where:

• \(f_c\) = loop crossover frequency, Hz
• \(T_d\) = total loop delay, seconds
• \(\Delta \phi_{deg}\) = phase loss allocated to delay, degrees

Assumed inputs:

• Lane-keeping/steering controller crossover frequency \(f_c = 10\) Hz — assumed for this calculation; this is typical for a slow outer-loop steering controller but must be tuned per architecture. needs primary source validation
• Phase margin lost to HIL-added delay \(\Delta \phi = 15^\circ\) — assumed allocation out of a total phase-margin budget; no public standard provides this exact allocation for autonomous steering.
• The formula is standard linear-control theory; the numerical input is an assumption, not a measured industry value.

Calculation:

\[

T_d = \frac{15^\circ}{360^\circ \times 10\ \text{Hz}} = \frac{15}{3600} = 0.004167\ \text{s} = 4.17\ \text{ms}

\]

Sensitivity:

Interpretation: if a vendor HIL rig contributes 1–2 ms of end-to-end I/O and solver latency, a 10 Hz steering loop has only about 2–3 ms of additional budget left for the domain controller, communication bus, and actuators. A faster loop such as 50 Hz requires sub-millisecond HIL behavior. This is why real-time target vendors emphasize FPGA loop rates and deterministic communication (NI HIL product page, self-reported, [ni.com ).

This calculation is a derived control-theory estimate. It does not by itself prove that any particular vendor achieves the required latency; that is exactly what independent testing or an acceptance test would measure.

Parameter table

Patents, moat, and IP boundaries

Why patents matter here: A granted patent is evidence of a recorded claim, not proof that the claimed method performs to a commercial or safety level. For moat/feasibility claims, a granted patent is stronger than an application, but it still does not establish that a product using the patent is safe, fast, or economically viable.

Illustrative granted patent:

• US 10,126,401 B2, titled “Method for testing a control unit in a hardware-in-the-loop simulation,” assigned to dSPACE digital signal processing and control engineering GmbH, granted 2018-11-13 — needs primary source validation [patents.google.com .

If this identifier resolves, it supports the statement that granted claims exist for a HIL test method. It does not support any quantitative performance claim. Pending applications and expired patents were excluded from moat claims because they cannot carry the same inference.

A second IP boundary: many HIL vendors emphasize open or standards-based interfaces, but the scenario/model interfaces and sensor-injection formats are frequently proprietary. This can create switching costs even when the real-time execution hardware is commodity. This statement is source-bound to vendor engineering documentation and is self-reported market structure; it is not an independent market analysis.

Contradictions and source-bound findings

Contradiction 1: “Real-time” marketing vs. actual measurable delay

Vendor pages describe HIL systems as “real-time” and “deterministic,” but specific jitter/latency figures are often not independently certified. A system can be “real-time” in the scheduler sense while still adding enough delay to matter for a fast control loop. The calculation above shows the practical consequence: a 50 Hz loop has less than 1 ms of delay budget, so marketing claims of “real-time” must be verified against actual measured I/O-to-I/O latency. This is a load-bearing performance claim and currently has no independent Tier 1 source; treat vendor latency figures as self-reported.

Contradiction 2: HIL validates control, but perception remains a sim-to-real gap

Peer-reviewed and standards-based work recognizes that HIL can strongly validate the deterministic control/actuation path but cannot fully validate learned perception models because simulated sensor data is an approximation of the physical world. ISO 21448:2022 explicitly addresses the insufficiency of simulation-only validation for unknown triggering conditions. Therefore HIL is necessary but not sufficient for autonomous-system safety case; road/closed-course testing remains required (ISO 21448:2022, [iso.org ).

Contradiction 3: Company filings vs. vendor marketing

Autonomous-vehicle developers publicly emphasize simulation and HIL in engineering blogs and press events, but their SEC 10-K risk factors warn that validation is incomplete and that automated-driving systems may fail in unexpected ways. These are compatible statements: HIL reduces validation cost but does not eliminate the risk. The contradiction appears only when marketing suggests that HIL coverage makes the system “safe” without a full heterogeneous validation program. See, for example, Tesla’s annual-report risk discussion on Autopilot/FSD timing and safety, and Alphabet’s Waymo risk disclosure (Tesla investor SEC filings, [ir.tesla.com ; Alphabet investor page, [abc.xyz ).

Contradiction 4: Patent strength is not performance strength

A granted dSPACE patent may show inventive method claims, but it does not demonstrate that dSPACE hardware achieves a specific latency, jitter, or sensor-fidelity level. Patent citations cannot be used as performance benchmarks, only as evidence that a party recorded a protective claim. This is the difference between a moat claim and a feasibility claim.

Unit economics / business model

Who monetizes HIL for autonomous systems:

1. Test-system vendors — dSPACE GmbH (private), National Instruments/Emerson (public parent), Keysight Technologies, ETAS/Robert Bosch (private parent), Vector (private), IPG Automotive (private), AVL (private), and specialized GNSS/radar simulator vendors such as Spirent.
2. Simulation/model vendors — MathWorks (private), IPG, AVL, and others sell software licenses and model libraries.
3. Engineering-service firms — perform test-bench integration and scenario validation for OEMs.
4. Automotive/AV developers — build internal HIL labs and consume the same components.

How value is captured:

• Hardware sale + integration service. HIL benches range from tens of thousands of dollars for simple ECU benches to multi-million-dollar full-vehicle/AV labs. Public price lists are generally not available; specific prices are needs primary source validation.
• Software licenses and annual subscriptions. Simulink Real-Time, CarMaker, AVL, and ETAS tools are licensed per seat/target. Pricing is not public; exact figures are needs primary source validation.
• Model libraries and maintenance contracts. Vendors earn recurring revenue on vehicle dynamics, sensor models, and firmware/model updates.
• Custom real-time targets and FPGA I/O. This is semiconductor content supplied by Texas Instruments, Xilinx/AMD, Intel/Altera, and Analog Devices.

Margins. HIL-specific gross margin is generally not disclosed. Public test-and-measurement peers provide only company-level proxies. Keysight’s consolidated gross margin and Emerson’s Test & Measurement segment margin are the nearest public anchors, but they are not HIL-specific. Exact margin figures are needs primary source validation and should be pulled from the latest 10-K filings (Keysight investor SEC filings, [investor.keysight.com ; Emerson investor page, [emerson.com ).

Who captures the value: In the near term, incumbents with installed simulators and model libraries (dSPACE, MathWorks, NI/Emerson, ETAS, Vector, IPG) capture toolchain value. Over time, AV developers with proprietary simulation/HIL stacks (Waymo, Tesla, Aurora, Mobileye) retain internal validation value but may still buy commodity real-time hardware. The largest public-company hardware beneficiaries are the component suppliers and the listed test/simulation integrators, not necessarily the OEMs.

Disconfirming Evidence

The thesis that HIL is a load-bearing, durable infrastructure layer for autonomous-system validation would be materially weakened if any of the following appear in primary sources:

• Independent, third-party latency/jitter benchmarks show that common HIL rigs cannot meet the loop-delay budgets in this note; if vendor “real-time” claims fail under external measurement, HIL’s value for fast control loops declines.
• Regulators or OEM safety cases conclude that HIL adds no meaningful validation beyond software simulation and closed-course testing, reducing its economic moat.
• Public company disclosures or procurement data show that autonomous developers are materially abandoning HIL in favor of fully virtual or fully on-road validation.
• The patent landscape shows that the main HIL method patents are expired, invalidated, or unenforced, removing the patent-moat element.
• A major autonomous-driving safety failure is traced specifically to an HIL validation gap, leading to regulatory restrictions on HIL-reliant safety claims.