Virtual HIL and the 100M LOC car

Aerospace and defense applications have traditionally leveraged hardware-in-the-loop (HIL) testing to overcome several issues. A big one is how expensive the physical system is. Even breaking down the system into subsystems for test can still be too expensive when fielding more than a couple test stations. Modeling elements of the “plant” for testing control electronics is essential to achieving reasonable development schedules and reducing risks through more complete testing at both the subsystem and system levels.

Automotive companies – many of whom moonlighted as defense suppliers in varying degrees – borrowed the HIL approach to improve testing of vehicle designs. While the platform isn’t nearly as expensive, the compressed development schedules of model-year releases dictates a more efficient testing approach.

Three other effects are adding to the automotive problem. First is complexity. By many estimates, the traditional metric of lines of code (LOCs) in a luxury vehicle is now surpassing 100M, and it isn’t much less at the midrange and low end as electronics content is increasing. That would be enough if it were a lump, but in fact the problem is much larger. Those LOCs are distributed across perhaps 100 or more subsystems, each with their own software and many running on different processor architectures. Manufacturers are trying to rein in that complexity by consolidating systems and standardizing around AUTOSAR and other architectures, but the problem is still large.

Second is degree of difficulty. Simulation of most electromechanical and hydraulic systems used to be a relatively easy task. Much faster response times in power electronics have made simulation a challenge, with many designers turning to FPGA-based acceleration of test platforms. Also factored in is the asynchronous nature of subsystems, loosely coupled on a vehicle bus such as CAN – accurately simulating and reproducing timing under all conditions is critical to assessing system operation.

Third is liability. The cost of failure in a car is much greater than it used to be, given the escalation in lawsuits and insurance costs. Even more dramatic is the expectation that manufacturers maintain vigilance through product recalls and warranty repairs. This has shifted the burden of test from straightforward functional verification to mitigating defect escalation, and the response is to “shift left” with earlier software testing.

For higher integrity levels in ISO 26262, the recommended approach involves fault tree analysis, fault insertion, and failure mode and effects analysis (FMEA). Physical fault insertion is expensive, time consuming, and hard to reproduce. When scaled across numerous scenarios and subsystems, it becomes difficult to sustain on an aggressive development timeline. As SoC integration is increasing, physical fault insertion is also becoming less feasible for chip users.

In a recent webcast, Synopsys has taken a fresh look at the ISO 26262 problem in the context of virtual HIL, using their experience in virtual prototypes. Using advanced tools combined with detailed, accurate models of popular automotive microcontrollers, many of the limitations of physical assessment of subsystems can be avoided. For instance, faults can be introduced virtually at the SoC level, providing rapid testing with reproducible, fully documented results.

Synopsys overviews the changes in the automotive environment, along with a look at the ISO 26262 standard and the FMEA philosophy, plus a look at how their tools work, in this SAE-moderated event:

“Shift Left” Functional Safety for Automotive System Development

Synopsys has combined their Virtualizer Development Kits with their Saber simulation environment and third-party tools such as Vector CANoe for network simulation to create simulation capability that can handle these larger, more diverse automotive systems. The examples shown in two videos in the webcast are focused on a single ECU for simplicity, but it is evident how the concept could scale.

For teams working on automotive SoCs, ECUs, or in designs targeting safety-critical systems in general, the ideas explored in this webcast may help keep up with the testing challenge.