Increasing Software in Automobiles – Can ALM-PLM Help?

Readers following the Consumer Electronics Show (CES 2012) at Vegas this year would have unmistakably noted car makers showing off their latest and greatest gizmos. As MSN noted in its editorial: “Audi, Chrysler, Ford, Kia, Mercedes-Benz and Subaru all used North America’s largest trade show to demonstrate advances in in-car infotainment, showcase next-generation alternative-powertrain vehicles and offer conceptual visions of how technology will power cars not only a few years from now, but well into the future.” And most of the latest innovation in automobiles is being done using software. Wired magazine in its article “Software Takes On More Tasks in Today’s Cars” notes “According to one study, 90 percent of the innovation we’re seeing within the auto industry is driven by advancements in software and gadgetry.” IEEE Spectrum ran an article some time back titled “This Car Runs on Code” where it put out some in-depth statistics: “It takes dozens of microprocessors running 100 million lines of code to get a premium car out of the driveway, and this software is only going to get more complex.”

How and Where Is Software Used in Cars

Table from the article in IEEE Spectrum “This Car Runs on Code”

While LOC (Lines of Code) measurement is always debatable, many studies do show a rough correlation between LOC and the overall cost and length of development, and between LOC and number of defects. And being a software developer I know a thing or two about the latter. A mountain of code would certainly have a ton of bugs (and that is what scares me!). In fact IBM even forecasted that 100 million lines of code at a Capability Maturity Model CMM level 3, corresponds to 2.3 million software design faults. Imagine driving in a highway at top speed with your family and a bug pops up in the powertrain control module or the electronic fuel injection ECU – pretty terrifying thought! “‘Talking’ Cars Are Coming Soon to Keep Us Safe” – yes but that can malware and script kiddies be far behind?

Automotive Software Verification and Validation Standards

However it’s not like the Wild West here – there are certain standards in place. ISO 26262, MISRA, and SPICE are various software standards that pertain to vehicle based software.

• ISO 26262 is a Functional Safety standard. The standard is an adaptation of the Functional Safety standard IEC 61508 for Automotive Electric/Electronic Systems. ISO 26262 is intended to be applied to safety-related systems that include one or more electrical and/or electronic (E/E) systems and that are installed in series production passenger cars with a maximum gross vehicle mass up to 3 500 kg.
• MISRA (Motor Industry Software Reliability Association) on the other hand aims to facilitate code safety, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C. There is also a set of guidelines for MISRA C++. They publish various development guidelines for vehicle based software.
• Automotive SPICE® Process Assessment Model (v2.5) ((ISO/IEC 15504), also known as SPICE (Software Process Improvement and Capability Determination), is a set of technical standards documents for the computer software development process and related business management functions.

Issues

An OEM typically has a very large number of Tier 1 and Tier 2 suppliers (playing roles of System integrators/System
Manufacturer/Standardizers/Component suppliers etc classically). Imagine a Tier 2 supplier making an ECU whose software development was outsourced to a third party software development firm. It will be very hard to predict how defects in this code will influence say another ECU developed by another Tier 2 supplier when both of them get incorporated into a more complex system. Smarter automotive supply chains have been able to give more visibility, quick response to increased customer demands, cost containment and fillip to globalization drives of the OEM’s. However where they have started lacking is in areas of risk management and quality issues (Toyota’s vehicle recalls being a prime example). “Pervasion of automobiles with digital technology – the integration of hardware and software into automobiles represents the predominant accelerator of increased functionality coupled with increasing complexity. This complexity results in overstrained car development departments, product failures, a cost explosion with respect to guarantee and warranty costs, and impact on customer satisfaction.” (IBM Whitepaper)

ALM-PLM Solution to Rescue?

Application Lifecycle Management (ALM) helps manage the life of an application through governance, development and maintenance. ALM basically integrates requirements management, design and development, testing, and release management and all related processes, and there are a number of tools to do that from a software development perspective. Around a year and half back I wrote an article “Can PLM encompass ALM (Application Lifecycle management)?” – Basic thoughts on tightly integrating Application Lifecycle Management with Product Lifecycle Management for mechatronics system. The way in which automotive products are being developed, manufactured, and serviced is rapidly changing – therefore, Application Lifecycle Management solutions must broaden and augment Product Lifecycle Management for software intensive products.  A panoptic and rigorous approach to software lifecycle management – from development to after-sales support with the precise tools and which fits in the automotive supply chain will be the answer.

Tags: ALM, Mechatronics, PLM, SPICE

This entry was posted on Tuesday, March 6th, 2012 at 6:11 am and is filed under ALM, PLM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.