MiL, SiL and HiL disagree on abort latency
You are validating an automated-parking function on three rigs: MiL with a bicycle-model plant at a 1 ms step size, SiL running the production binaries on a PC cluster with a stubbed ultrasonic sensor driver, and HiL with 12 ultrasonic sensors emulated on the CAN/CAN-FD bus at a 10 ms cycle. The park-abort function passes in MiL and SiL, but fails on HiL in 3 of 40 runs when the lateral gap narrows from 30 cm to 25 cm; measured abort latency is 160 ms against a specified 100 ms. The supplier's position is that the HiL plant model is wrong and asks for release on the SiL results. Homologation is fixed and you have two weeks. A back-to-back comparison between SiL and HiL has never been run with identical stimulus.
1. Evaluate the supplier's request: which rig should carry more weight for this latency defect, and what would you require before accepting or rejecting the claim that the HiL plant model is wrong?
Read the worked answer
The claim is testable, so it should be tested rather than argued.
HiL adds three things SiL does not have: real bus scheduling and timing, the real sensor interface with its 10 ms sampling, and execution on the target with its real-time scheduling. A 60 ms latency delta is six times the 10 ms sampling quantum and far larger than any plausible error in a kinematic plant model for an abort decision, so plant-model error is a weak hypothesis on its face. It cannot be dismissed, but the burden of proof is on the supplier.
Requirement before any decision: run a back-to-back comparison. Feed the identical recorded sensor trace, with identical timing, into SiL and HiL, and compare ECU outputs plus internal timestamps. If the divergence appears between sensor frame arrival and the ECU's internal detection, the cause is in the ECU or the interface, not the plant. If it disappears when both use the same plant parameters, the plant model is implicated.
Until that evidence exists, do not release on SiL results: a latency violation on a safety function is not a modelling artefact until proven.
2. Name the three most plausible causes of the extra 60 ms and describe one discriminating experiment for each.
Read the worked answer
- Sensor interface and emulation: 12 sensors on a 10 ms cycle with a stubbed driver in SiL. Experiment: log each sensor frame at the ECU input with timestamps, replay the identical frame sequence into SiL with the same timing, and compare. If HiL diverges with identical frames, the driver or the bus scheduling is implicated.
- Real-time scheduling on the target: task jitter, priority inversion, or CPU load that a PC SiL does not reproduce. Experiment: trace task activation-to-completion, CPU load, and bus load while sweeping the number of active sensors; look for the abort task being delayed behind a lower-priority runnable.
- Plant-model or parameter mismatch at the 30 cm to 25 cm threshold: the abort condition may flip near a threshold, so a small modelling difference changes the decision, not the latency. Experiment: run SiL with the HiL plant model and identical parameters. If the failure follows the model, it is the plant; if it stays in HiL only, it is the ECU or interface.
Note the fourth asymmetry: the stubbed driver means SiL cannot see a defect in the real driver at all.
3. What do you put in the report to the safety manager, and what is your release recommendation?
Read the worked answer
Report facts, hypotheses and the discriminating plan, in that order, without hiding the disagreement.
- The observation: 3 of 40 HiL runs, gap transition 30 cm to 25 cm, 160 ms measured against 100 ms specified. State the rig configuration, the sensor cycle and the sampling assumptions so the result is reproducible.
- What is not yet known: no back-to-back comparison with identical stimulus has been run, so the cause is unlocalised. Say explicitly that plant-model error is one of three candidate causes and is not excluded.
- What the SiL pass does and does not prove: it proves the software logic works with a stub and a simplified plant; it proves nothing about the real interface or real-time behaviour.
Recommendation: withhold release for this function, approve release of unaffected functions if the programme needs a partial milestone, and set a two-week gate that ends with the back-to-back result. If the back-to-back shows the ECU exceeds its timing budget, it is a software or integration defect and goes to the change process, not to a rig argument.