Dealing with automotive software complexity with virtual prototyping – Part 1: Virtual HIL development basics - Embedded.com

Dealing with automotive software complexity with virtual prototyping – Part 1: Virtual HIL development basics

Editor’s Note: In Part 1 of a series excerpted from the book Better Software. Faster! , Victor Reyes compares how a virtual Hardware-in-the-Loop (vHIL) approach can replace traditional HIL, Processor-in-the-Loop, and Model-in-the-Loop techniques in complex automobile system designs.

Today’s luxury car now has upwards of one hundred million lines of code, more than a commercial airliner built for transcontinental travel, and this number is rising steadily with no upper limit in sight [1]. Today, this code is distributed across 50 to 100 Electronic Control Units (ECUs) governing thousands of singular functions. Hundreds of related functions are grouped on a single ECU.

Industry analysts calculate that at least 40% of a vehicle’s market value is linked to its software content and manufacturers report that software problems are now the source of a majority of customer complaints. An estimated 80% of automotive innovations are now computer-based, making software a major contributor to the price and value of a car. It’s not unusual for Tier 1 and OEMs in the automotive supply chain to employ several thousand software engineers to develop, integrate, and test software.

The cost of embedded software (non-) quality
Today’s vehicles comprise mechanical, electrical, electronic, and software components. Consumers expect them to perform a myriad of different tasks seamlessly, on time, and without errors. Governmental agencies mandate standards for safety. These expectations create an expanding universe of inter-dependencies that require multidisciplinary expertise, with software playing more and more of a central role.

As the amount of software grows, the volume of software errors multiplies. Automotive recalls due to software problems have increased exponentially over the last decade. The problem is not only the direct costs associated with bringing cars to a garage and patching the software, but also the indirect costs associated with brand image damage even in cases where no accidents or injuries are involved. Not only are recalls critical, redesigns due to software bugs being discovered late are also extremely costly in an industry where time-to-market is becoming increasingly important.

In order to improve the software quality in a vehicle, it is not only a matter of performing more tests, but also a matter of increasing the quality of the tests. In order to increase the quality it is necessary to measure whether the tests are exercising all the software functionality. That includes corner cases that are not triggered during normal operation, but also when the underlying hardware fails or the software gets corrupted. Today’s safety critical systems include multiple fault tolerant mechanisms which are implemented both on hardware and software. Those mechanisms are able to detect and even correct such faults. However, this comes with a huge impact on the overall development cost. For instance, diagnostic software today takes up to 40% of the total lines of code of an ECU and counts for up to 50% of the processor runtime.[2]

Software Development and Test Evolution
The traditional automotive V-model parses the development, integration and test process into chronological steps. The V-model links specification and design (left side) with testing (right side) in several steps or levels of hierarchy. From the point of view of the software, the process starts with the definition of the vehicle requirements. Those requirements are split among the different sub-systems that compose a vehicle (powertrain, chassis, body, etc). Functionality is specified at the system level, which typically has to consider mechanical, electrical and control aspects. Control functions are then specified and designed at the component level (ECU) and mostly implemented as software functions that execute on a microcontroller unit (MCU). Those software functions are then compiled with other software stack layers and tested on the ECU during the integration phase. Next step is to test all the ECUs in a sub-system, together with the mechanical and electrical parts. Finally, the sub-systems are integrated together and the complete vehicle is validated.

Figure 1: The V-model, traditionally used for auto development and test

Today, the big bulk of embedded software testing happens using a method called “Hardware-In-the-Loop” or HIL testing. The biggest investment and cost around software functional testing is related to HIL equipment and the ecosystem around it. The HIL concept was born out of the need to frontload the testing of the embedded software and the increasing adoption of Model-Based Development (MBD) and “in-the-loop” simulation.

In search of a way to discipline software complexity, many automotive teams have turned to model-based development. Here, models help designers visualize dependencies, analyze problems and introduce abstractions that simplify the problems to be solved. As MBD has taken root, the automotive industry has evolved “In-the-Loop” methods to develop and test control strategies. Simulation is used in the place of “real” mechanical and electrical parts to test the validity of the control logic. First, on the left side of the V cycle, Model-In-the-Loop (MIL) is applied, followed by Software-In-the-Loop (SIL). Sometimes, Processor-In-the- Loop (PIL) is applied after SIL, although it is not that common.

Model-In-the-Loop or MIL consists of mixing the physical plant model (including mechanical, electrical, thermal, etc., effects) with the control strategy at the algorithmic level (typically using state machines). This creates a complete mechatronic model that can be simulated together to find out whether the behavior of the control logic is correct. Initial tests can be created at this level. These tests should be reusable for the next subsequent phases. Once the MIL simulation shows that the results are correct, the control part is implemented (typically in software). Implementing the control model can be done manually by writing C code or automatically by using code generation tools.

Software-In-the-Loop or SIL simulation is then used to validate the implementation of the control logic. With SIL, the C code is simulated together with the same physical plant model used in the MIL phase. The same tests can be reused in this phase to assure that the results are equivalent (back- to-back testing). The problem with SIL is that the C code is compiled for the host PC instead of the target microcontroller (MCU). This may introduce differences in precision due to different data types (saturation and overflow effects), as well as other problems due to resource limitations on the MCU (memory, processing power).Replacing HILs, PILs and MILs with a virtual HIL
Assoftware continues to grow in complexity and size, and time to marketbecomes more and more important, the automotive industry cannot standstill. New ways of frontloading the software development and testing arerequired. And it is here where simulated models of the ECU hardware canbe a game changer (as it happened for the models of the physicalplant). Removing totally the dependency on physical hardware to develop,integrate and test software can gain automotive companies valuablemonths, that will turn out in higher quality products. Frontloading thecreation (and validation) of tests before going to HIL systems will alsosave cost, since now those HIL systems will be fully utilized just torun the tests and not to develop them.

On top of that, usingvirtual (i.e. simulation models) rather than real hardware for“in-the-loop” testing creates a smoother path between MIL, SIL and HIL.In a virtual HIL (vHIL) environment (Figure 2 above), a virtual ECUmodel is connected in closed-loop to the same simulated plant model usedon MIL and SIL. The same tests applied on the MIL and SIL phases cannow be executed on the vHIL environment. Moreover, “offline testcreation” can now be done in a more realistic environment, which enablesmore and different tests to be created earlier.

vHIL canbe seen as the centric technology that narrows the gap between the leftand right side of the V-cycle, while keeping the intrinsic added valuecharacteristic of virtual prototyping for hardware dependent softwaredevelopment. The benefits and advantages of virtual prototypes can besummarized in the following major aspects:

A virtual prototypeis a fully functional representation of the digital hardware. Theembedded software sees no differences when executing on a virtualprototype or real hardware. The embedded software can be exactly thesame that runs on the end product (the car), compiled NOT for a PC hostbut for the target MCU architecture.

A virtual prototype can beused similarly as the hardware when debugging software on it. The samesoftware debugger (e.g. TRACE32) can be used transparently. A virtualprototype however reduces the debugging cycles since the software doesnot need to be flashed on the hardware (this can take several minutes).

A virtual prototype is a heavy-duty hardware debugger and “logic” analyzer:

  • Full control with breakpoints and visibility on internal registers and signals extend standard software debuggers capabilities.
  • Models can help you narrow down the root cause of bugs through verbose logs and/or at a glance, tell the hardware state at a high level.
  • Unlike real logic analyzers a virtual prototype can trace an unlimited number of signals (internal and external), register values, state of blocks, etc. All without buffer limitations (limitation is the size of the hard disk of the PC).
  • All the hardware information can be correlated together with the software execution (tasks, functions, instructions) on the same timeline.

A testing harness can be created veryeasily using the virtual prototype scripting interface. Stimuli data canbe fed to the MCU input pads (or internal blocks) with little effort bymeans of scripts. The scripting interface can peek at and poke valuesin all registers, signals, etc. Creating simple tests that can helpbring up the software is made very easy and without the need of externaltools.

A virtual prototype allows a seamless integration withother automotive ecosystem tools. For instance, it can be connected andsynchronously co-simulate together with a plant model coming fromSimulink, an ASIC model created with Saber, or a network of ECUs createdwith Vector CANoe, etc.

A virtual prototype can be controlledvia scripts or external tools. This enables the automation of scenarios,including capture-replay type of capabilities and regression testing.Moreover virtual prototypes do not suffer from the typical scalabilityproblems of hardware and hundreds or thousands of simulations can beexecuted in parallel using a server farm.

In the rest of this series we will look at the use of vHIL in different automotive specific use-cases.

Part 2: AUTOSAR-based hardware dependent software development and integration
Part 3: Embedded software testing

Victor Reyes , Technical Marketing Manager, Synopsys Inc., is the author of a chapter in Better Software Faster! from which this series of articles was excerpted. Edited by TomDeSchutter, the book was published by Synopsys Press and can bedownloaded as a free eBook.

References
[1] /wiki/Engine_ control_unit
[2] Klee, P.; Knirsch, M.; Willimowski, M.; “Herausforderungen der Diagnossentwicklung in der Motorsteueren”, in: Onboard-Diagnose – Status der Gesetzgebung und Auswirkungen auf die Fahrzeugentwicklung, exper-Verlag, Renningen, 2005

1 thought on “Dealing with automotive software complexity with virtual prototyping – Part 1: Virtual HIL development basics

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.