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

Victor Reyes, Technical Marketing Manager, Synopsys Inc.
embedded.com (May 24, 2014)

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]

To read the full article, click here