Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Dealing with automotive software complexity (Part 1)

Posted: 18 Jun 2014     Print Version  Bookmark and Share

Keywords:Electronic Control Units  ECU  automotive  Software-In-the-Loop  Model-In-the-Loop 

Nowadays, a luxury car 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 multi-disciplinary 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: 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 visualise dependencies, analyse 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.

1 • 2 Next Page Last Page

Comment on "Dealing with automotive software com..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top