Evolution of automotive software testing - Embedded.com

Evolution of automotive software testing

When General Motors introduced the first software based engine controller unit (ECU) in 1980 (http://en.wikipedia.org/wiki/Engine_control_unit), nobody could foresee how critical software would become for the automotive industry in terms of safety, security, and cost. At the time, complexity was not high and software testing was done primarily in the car. With today’s software complexity this is no longer possible.

Nowadays final sign off still happens in the car, together with software calibration activities, but the big bulk of testing has already happened using other methods–methods that were introduced for the sake of efficiency, quality and obviously cost savings. Automotive companies followed a divide and conquer approach where the different subsystems (powertrain, chassis, body, etc.) are tested separately. Physical prototypes of the plant under control (such as the engine) were connected to the electronic control units and software testing happened on those testbeds. Although better than waiting for a fully assembled car, using physical prototypes to perform the functional software testing was still inefficient, cumbersome and expensive. Bugs in the software could easily damage an engine or a transmission system. As software complexity grew these methods did not keep up.

Hardware in-the-loop (HIL) was then born. Fueled by the adoption of model-based design during the design of new control functions, physical models of the plant started to be reused for functional software testing using HIL systems. Engineers could now start doing software integration and testing on the ECU before a prototype of the physical plant was available. This has been key to increasing the quality and reducing the cost of developing cars with more and more software running on them. Although models of the physical plant are abstractions of the real thing, they are good enough to enable early software testing. Their fidelity is sufficient for the job at hand, and the software does not notice any difference.

Clearly the trend in testing's evolution is the move from full car, to subsystem testbeds, to HIL systems, all with the goal of enabling teams to test software earlier in the design cycle. Every step is required, a new method doesn't replace an old one, but frontloading some of the work improves the final result. As software continues to grow in complexity and size, and time to market pressure persists, the automotive industry cannot stand still. New ways of frontloading the software development and testing are required. And it is here where models of the ECU hardware can be a game changer (as it happened for the models of the physical plant). Completely removing the dependency on physical hardware to develop, integrate and test software can gain automotive companies valuable months, that will result in higher quality products. Just imagine frontloading the creation (and validation) of tests from using HIL systems to using simulation models, such that the HIL systems are fully utilized just to run the tests. This can save millions directly and indirectly to automotive companies. Testing methods are continuously evolving and virtual prototypes of the digital ECU hardware are the natural next step on this path.

Victor Reyes is currently a technical marketing manager in the System-Level Solutions group at Synopsys. His responsibilities are in the area of virtual prototyping technology and tools with special focus on automotive. Victor Reyes received his MsC and PhD on electronics and telecommunication from University of Las Palmas, Spain, in 2002 and 2008 respectively. Before joining Synopsys, he held positions at CoWare, NXP Semiconductors, and Philips Research.

1 thought on “Evolution of automotive software testing

  1. Interesting, I hadn't heard before about HIL. I'm not in to testing automotive but I suppose this concept could apply to a certain extent in other industries. The proper modeling of the plant to control involves many mathematical variables and models. In o

    Log in to Reply

Leave a Reply

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