Automotive MCU code fault-busting with vHIL

With electronic and software content in vehicles skyrocketing, and the expectations for flawless operation getting larger, the need for system-level verification continues to grow. Last month, we looked at a Synopsys methodology for virtual hardware in the loop, or vHIL, using co-simulation and modeling to allow use of production software unmodified while still performing fault injection.

Previously, the context of the discussion was in ISO26262 and providing artifacts for compliance through testing with faults applied. This month, we turn to one of the more practical applications of the technology: mixed signal verification. Mixed signal is a beast under normal circumstances, but in the automotive environment of today, testing has to encompass things like high-performance power electronics found in an electric vehicle powertrain (EVP).

Most designers are familiar with using modeling environments for such a task. In this case study, a completely soft model for components of an EVP was the starting point. Within the Synopsys SaberRD tool, a field-oriented control (FOC) scheme for a permanent magnet synchronous motor (PMSM) was created, completely in C. The model included Park’s Transformation, PID control, and a Maximum Torque per Amp algorithm, along with soft models for velocity, position, and other sensors.

The reasons for modeling all this in C become clear at the next step – integrating a virtual prototype of a microcontroller running production code into the simulation. The desired target hardware is a Freescale MPC5643L MCU, and for simplicity in the case study some of the external interfacing such as power transistors to provide high-voltage motor drive capability was abstracted out. The focus of the effort is illustrating how an actual microcontroller, through its virtual prototype proxy, would run actual software.

That said, the FOC block needs to be transformed from a C model into available microcontroller constructs. “Up” and “down” switching signals for the three-phase inverter were converted into PWM outputs. Motor angle, current, voltage, and speed references were connected to the ADC block with the proper signal conditioning – with the analog portions modeled in Saber.

Co-simulation links were then established between the SaberRD model and the Virtualizer Development Kit (VDK) for the MPC5643L. Signal names were mapped between the two sides, and a simple register configuration applied to the VDK to complete the connections.

At that point, one has real MCU code, compiled in CodeWarrior and loaded into the flash model of the virtual MCU and running self-contained on a model of the e200 processor core. One more tweak is needed, to set the dead time of the PWMs in sync with the step size of the co-simulation – in the real world, sample rates and dead time would be set for corresponding physical characteristics of the motors. A quick check shows the virtual prototype MCU code reproduces the same speed and motor currents in a time trace.

That seems like a lot of work, but the entire point was to be able to start injecting faults using SaberRD and see how the software running on the virtual MCU responds. Those observations are not just from an external analyzer viewpoint – the internals of the code and MCU can be investigated as deeply as required, since everything is visible in the virtual prototype. Several fault injection scenarios and the results are described in the balance of the white paper:

Is Your Software Robust Enough for Hardware Faults?
Part 2: Electrical Vehicle Powertrain Case Study for Virtual FMEA

This is one of the more interesting uses of virtual prototyping I’ve seen, not just the usual story of being able to develop and debug embedded code on a part early. Again, the context is automotive, but the methodology applies to any safety-critical mixed-signal situation powered by a microcontroller or SoC – assuming there is a virtual prototype available for the chip in use.

For automotive design teams, this type of fault-busting may shake out something traditional simulation and hardware testing can’t identify.