KTL eBook
Control after failure:
Vehicle-and-Hardware-in-the-Loop (VaHiL) validation for controlled-by-wire vehicles
Read the eBook below, or download it as a free PDF to learn more about the latest advances in by-wire braking and steering system test methods.:
We keep your information safe in accordance with our Privacy Policy.
Control after failure:
Vehicle-and-Hardware-in-the-Loop (VaHiL) validation controlled-by-wire vehicles
Overview
By-wire brakes and steering systems must be proved out with more than fault detection: they must ensure that the vehicle stays controllable after a fault, within tens to hundreds of milliseconds. Vehicle-and-Hardware-in-the-Loop (VaHiL) testing is the most practical way to produce such proofs.
The desired result is repeatable, time-stamped evidence for ISO 26262 safety cases that cover the dangerous fault scenarios that are too risky for public roads or proving grounds and too abstract for conventional Hardware-in-the-Loop (HiL) test benches.
Testing on a proving ground
Lab-based VaHiL solutions such as KTL’s Te.Sense Bonito – a dynamic steering force emulator – can allow a prototype vehicle on a hub-coupled dynamometer to receive dynamic steering rack forces in real time. The road, traffic and environment are simulated; the ECUs, actuators and vehicle responses are real. Faults are injected on command and every signal is recorded on one timeline.
Why by-wire changes the safety question
With by-wire systems, removing any mechanical backup transfers vehicle control authority to an electronic chain, and any link in that chain, if corrupted, can lead to a loss of vehicle control.
A conventional brake has a hydraulic line and a conventional steering system has a physical column. When the electronics fail, the driver still has a physical pathway for vehicle control. Brake-by-wire (BBW) and steer-by-wire (SBW) replace that path with sensors, power supplies, communication buses, controllers and actuators working in a closed loop.
A fault anywhere in that loop can cause too little braking, unintended braking, unintended steering, steering lock-up, etc. – any of which can lead to loss of vehicle control. One way to consider all this is as follows:
What "controllable" has to mean
Under ISO 26262, "controllable" is not a judgment call; it needs three pieces of hard evidence at once:
1. The fault is diagnosed.
2. The system moves to its defined degraded or safe state.
3. The driver and vehicle keep enough margin to stay in control.
All three must happen inside the fault-tolerant time interval (FTTI). In typical hazard analyses, basic braking safety goals are rated ASIL D with FTTIs of a few hundred milliseconds. Stability functions such as ABS and ESC are often held to around 200 ms. Steering goals covering unintended steering or lock-up commonly sit between 20 ms and 200 ms.
So, a convincing validation report cannot stop at "the fault was injected." It must show the fault trigger, the ECU reaction, the vehicle's motion and the pass/fail criteria on one shared timeline, with one time base for every signal.
Download this eBook for free as a PDF:
Where existing test methods fall short
Each established method covers part of the problem, but none shows full-vehicle behavior during a dangerous fault within the required millisecond timings.
Model- and Software- in-the-Loop (MiL/SiL) testing is ideal for fast iteration of control logic parameters. Conventional Hardware-in-the-Loop (HiL) can be used to verify ECU functions, buses and I/O. Road testing typically validates normal driving and final sign-off.
The obvious gap is the fault case, where high risk, millisecond timings, the vehicle, driver or ADAS, actuators and environment are all interacting in a closed loop. VaHiL can help close this gap, as summarized here:
It’s worth noting that VaHiL does not replace traditional methods. Instead, VaHiL addresses the scenarios that are the most dangerous, hardest to reproduce and most demanding of evidence.
What is VaHiL?
VaHiL (Vehicle-and-Hardware-in-the-Loop) is HiL testing with the whole vehicle as the device under scrutiny. The prototype vehicle, its ECUs and its actuators are represented with real hardware. Roads, traffic, weather, grade, tire-road interactions and sensor targets are virtual (simulated).
VaHiL test setup: Real vehicle, simulated surroundings
As one practical example, a hub-coupled dynamometer can apply realistic road loads at each wheel, and a dynamic steering rack force simulator such as KTL’s Te.Sense Bonito can be included as a VaHiL element to apply the real-time, dynamic rack forces that would occur on the road.
VaHiL test setup: Real vehicle, simulated surroundings
In such a setup, a fault injection unit triggers electrical, protocol or signal faults at exact moments, and everything is logged against one time base. The vehicle in the middle is the only part that is not simulated, which is why its response counts as evidence.
Example: a steer-by-wire fault during a lane change
The scenario below checks that an SBW-equipped vehicle stays in its lane and under control when a steering sensor or power fault occurs mid-maneuver.
With no mechanical link, the most sensitive SBW risks are unintended steering, steering lock-up, sudden loss of assist or incorrect lateral commands from an automated or assistive driving function. Torque, angle, yaw-rate and motor position sensors, the power supply and the steering-feel actuator could all be considered as fault injection targets.
1. Scenario
The vehicle travels at 60 km/h and changes into a lane where a traffic vehicle is moving at 40 km/h. The road is flat with typical surface characteristics. The scenario is repeated with the driver in control and with an automated lane function active.
2. Fault injection
At a set moment, one fault is applied: perhaps a torque, angle or motor position signal is shorted to supply or ground; or perhaps a supply under-voltage is applied; or perhaps an implausible yaw-rate signal is introduced.
3. Expected reaction
The automated function hands over control or the system enters a limp-home mode. The backup steering channel takes control, the driver is warned and a diagnostic trouble code (DTC) is stored.
4. Pass criteria
The vehicle does not leave its lane, the safe state is reached within the steering FTTI, and the driver can take over at any point.
The important point to consider is step 4. In addition to simply measuring whether the ECU flagged the fault, VaHiL allows measurement of what the vehicle actually did.
Download this eBook for free as a PDF:
Building the evidence package
A VaHiL lab test session turns safety requirements into a traceable chain: requirement, test condition, fault, reaction, verdict. The flow is as follows:
1. Start from the safety goals
Each test traces to a safety goal from the hazard analysis and its ASIL and FTTI, plus the applicable regulations and standards (ISO 26262, and ISO 21448 SOTIF where automated functions are involved).
2. Inject repeatable faults
Open and short circuits, CRC errors, SENT timing errors, bitflips and signal offsets are scripted and applied at exact times.
3. Record the system's safety response
DTCs, driver warnings, fallback activation and limp-home behavior are captured along with vehicle motions.
4. Deliver the evidence package
Each run produces test conditions, fault waveforms, CAN logs, DTCs, a timing diagram and the pass/fail verdict with its basis.
Because every run is scripted, the same fault can be repeated as many times as a review requires, with identical conditions.
Common questions
When considering the addition of VaHiL tools to an existing workflow, questions naturally arise. Here are some common ones:
Question: We already run SiL, MiL and HiL. Why add VaHiL?
Answer: Traditional laboratory-based SiL, MiL and HiL methods are able to validate algorithms and ECUs quite well. However, they cannot show how the whole vehicle behaves once a dangerous fault couples with real vehicle dynamics situations. For some test cases and scenarios, adding VaHiL to include a real vehicle with driver and/or ADAS in the loop is a way to expand validation coverage.
Question: Why not just test potential faults on the road?
Answer: Normal driving can be road-tested, of course. But certain conditions such as brake failures, steering lock-up and bus faults at speed may be too dangerous to stage and nearly impossible to reproduce exactly during road testing.
Question: Can the same fault be repeated 100 times with VaHiL?
Answer: Yes. Scenario files, fault scripts, channel settings and timestamps are all stored, so runs can be repeated exactly.
Question: Can VaHiL simulate protocol faults, in addition to just open circuits?
Answer: Yes. Protocol-level faults such as wheel-speed sensor message errors and SENT timing, CRC or nibble errors can be scripted.
Question: Does VaHiL work with our existing HiL, DAQ and CAN setups?
Answer: Properly configured VaHiL is designed to add to any existing toolchain. Ethernet, DAQ and CAN logs are linked into one evidence chain.
Question: Can VaHiL-derived results support certification and safety reviews?
Answer: Yes. Each run produces a package with test conditions, fault waveforms, ECU responses, vehicle controllability data and the basis for the verdict.
How Koala Technologies can help
Koala Technologies (KTL) designs and builds specialized lab-based and on-car test equipment for automotive development teams around the world.
As one example, our Te.Sense Bonito steering force emulator is a VaHiL device that applies controlled, realistic tire-road forces to the steering rack, so by-wire systems and their fault reactions can be tested under the loads that would be experienced on-road. For SBW validations, introducing realistic rack loads is really what turns a traditional bench test into a vehicle test, and that is Koala Technologies’ focus with Te.Sense Bonito.
KTL eBook
Control after failure:
Vehicle-and-Hardware-in-the-Loop (VaHiL) validation for controlled-by-wire vehicles
Download our PDF to learn more about the latest advances in by-wire braking and steering system test methods.:
We keep your information safe in accordance with our Privacy Policy.