The software team has run thousands of simulations, the model is green, and the first time the real ECU is plugged into the bench its input reads 0.3 V too low and the control loop oscillates. Nothing was wrong with the model. The problem lived in the part that is not in the model: the harness, the conditioning, the ground return and the timing of the I\/O. Hardware-in-the-loop (HIL) testing exists precisely to put that real hardware in the loop early, while the rest of the system is still simulated.<\/p>\n
This guide walks through the architecture of a HIL bench, the role of each block, the timing constraints, and the steps that take a bench from concept to a tool the test team can trust.<\/p>\n
In a HIL bench, the real ECU<\/strong> runs its production (or near-production) software. Everything the ECU would normally see around it, such as the plant, sensors, actuators and other ECUs, is replaced by a real-time simulation<\/strong> connected through real electrical interfaces. The ECU reads simulated sensor signals, computes, and drives outputs that the simulation reads back to update the plant. The loop is closed through physical wires.<\/p>\n The two are complementary. Upstream, co-simulation<\/strong> using the FMI standard (Functional Mock-up Interface) lets models from different tools exchange data as FMUs in SIL; the same models can later be reused, after checking real-time feasibility, on the HIL target.<\/p>\n From the simulation to the ECU, a typical HIL chain looks like this:<\/p>\n Real loads give realistic electrical behaviour (inductance, inrush current, back-EMF) but cost space, heat and sometimes safety measures. Equivalent loads are compact and repeatable but must reproduce what the driver diagnostics check. A common compromise: real loads where the ECU diagnoses the load dynamically, resistive equivalents elsewhere.<\/p>\n A breakout box<\/a> between the harness and the ECU gives measurement access to every pin without cutting wires. A fault-injection matrix in the same position lets you create open circuits, shorts and resistive faults under sequencer control (Fault injection on harnesses and ECUs<\/a>). Designing both into the bench from the start avoids re-cabling later.<\/p>\n A desktop operating system schedules tasks according to its own priorities. It can be pre-empted by updates, drivers or other software, so the time between two loop iterations is not guaranteed. For a control loop, that variation (jitter) is equivalent to a varying delay in the plant, which can change stability and results from one run to the next. The model loop must therefore run on a deterministic real-time target<\/strong>, and the PC is used for configuration and supervision only. The details of where a time base should live are covered in Acquisition timing and jitter<\/a>.<\/p>\n Example:<\/em> the ECU reads a sensor every 1 ms and the plant has a dominant time constant of 20 ms. A model step of 1 ms gives 20 steps per time constant, which is usually enough for a first-order plant with a fixed-step solver (stiff or fast electrical models need a smaller step or FPGA-based simulation), and matches the ECU’s sampling. If the ECU must see a PWM signal at 10 kHz, the 1 ms model step is far too slow to generate it in software: the PWM must be produced or captured by dedicated hardware<\/strong> (timer or FPGA-based I\/O), with the model only updating the duty cycle.<\/p>\n Example:<\/em> total loop latency = I\/O input conversion + model step + I\/O output update + conditioning delay. With an assumed 50 \u00b5s + 1 ms + 50 \u00b5s + 10 \u00b5s, the latency is about 1.11 ms. Compare this with the timing margin of the function under test before trusting the result.<\/p>\n This is the same sequence RAYNOV follows for its custom validation systems<\/a>: specification, architecture, design review, manufacturing, FAT, delivery with SAT and training, then maintenance.<\/p>\n A HIL bench is itself a measuring instrument. Before the first campaign, prove that:<\/p>\n Write these checks as an acceptance procedure with pass\/fail criteria. The difference between acceptance and qualification testing is explained in our article ATP vs QTP<\/a>, and our approach is described on the ATP methodology<\/a> page.<\/p>\n1.1 HIL vs SIL: where the hardware starts<\/h3>\n
\n
2. The reference chain, block by block<\/h2>\n
2.1 Principle diagram (described)<\/h3>\n
\n
2.2 Real or simulated loads?<\/h3>\n
2.3 Breakout and fault injection as building blocks<\/h3>\n
3. Real-time constraints<\/h2>\n
3.1 Why a desktop OS cannot close the loop<\/h3>\n
3.2 Worked example: choosing the model step (illustrative values)<\/h3>\n
4. Electrical points that make or break a bench<\/h2>\n
\n
5. Implementation steps<\/h2>\n
\n
6. Validate the bench before you validate the ECU<\/h2>\n
\n
7. Common mistakes<\/h2>\n
\n
8. Checklist<\/h2>\n
\n
Further reading<\/h2>\n