How to leverage automotive software development standards to mitigate risk

This article discusses some of the issues contributing to automotive software complexity, as well as the risks associated with automotive software development. We’ll also discuss how implementing known development best practices, such as ISO 26262, helps organizations mitigate those risks.


By Arthur Hicken, Parasoft           Download PDF version of this article


When average non-engineer consumers think of electronic systems in automobiles, they likely think of integrated GPS, infotainment systems, and probably some vague notion that there is a computer somewhere in the car controlling some of the safety features. Of course, the reality is that modern cars are significantly more complex with software playing an increasingly larger role in all facets of functionality, including many safety-critical functions. In fact, cars have been leveraging electronic systems for critical functionality for decades, and market changes, such as the push toward an Internet of Things, have nudged automakers towards embedding a greater number of complex computer systems that run the gamut of criticality.

The business structures and supply chains associated with system development further adds to the complexity. It’s rare, if it happens at all, that a manufacturer engineers and builds every component and subsystem in their cars from the ground up, leading to potential integration issues. A transmission is taken from this model, a good braking system from that one. While they may have worked well in their previous environment, in a totally new complex system they may well have unintended and unexpected results. As a result, automotive software is often a complex hodgepodge of systems that may or may not have been sufficiently tested. Implementing components in an ad-hoc manner without proper testing, especially in safety-critical applications, can be extremely costly.

The upside, though, is that there are known practices for helping automakers mitigate the risk of failure by building software quality into their development processes. According to some estimates, a standard mid-range car can have well over a hundred electronic control units (ECU) processing millions of lines of code - and this number is increasing. It’s not uncommon for a manufacturer to have several models of cars with over one hundred million lines of code. There is a perception that the more expensive the car, the more software is embedded - and that most of the software is dedicated to high-end infotainment components. While it’s true that these systems become increasing complex as you move up the model line, even introductory lines of cars use software to control steering, brake systems, electrical power distribution, and so on. And even seemingly minor shifts in features, such as Bluetooth, climate control, cruise control, etc, lead to exponential growth of code.

We can assume that more code translates to more complexity - and therefore risk, but the impact may not necessarily be significant. A larger contributor to business risk associated with automotive software is the integration of code developed from a variety of sources across multiple tiers. Most components, including ECU-based components, are subcontracted to second-tier providers who subcontract to third-tier providers and so on. Each preceding tier has specific requirements associated with the component they’re developing. Organizations often (but not always) have practices in place for analyzing incoming code to ensure that the components function as expected.

But this assumes that every component along the supply chain is a  new development. In reality, downstream tiers are branching off code written for a specific make, model, and year. The mutation and reuse of code takes place throughout the supply chain, which leads to a testing problem. How does the manufacturer implement end-to-end testing in such a chaotic ecosystem of software development? When the ECU in the steering wheel was originally developed for one vehicle and the ECU in the dashboard was developed for another vehicle, and neither ECU was designed for the vehicle they are currently embedded in, what’s the impact? How can you ensure that the complete system functions as expected? It is entirely possible for both systems to pass testing as functional but be unable to communicate properly in all situations. What is the risk associated with this gap?

When organizations attempt to measure the cost of software development, they tend to look at general metrics: development time for the engineers; testing time for QA; building materials in the form of acquiring tool licenses, compilers, and other infrastructure components. These are important metrics, but often overlooked are the costs of failure. If the software in the braking system fails, what will it cost the business in terms of rework, recalls, audits, litigation, and loss of stock value? What if there is a loss of life? We argue that the cost of quality is the cost of developing and testing the software, including all the normal metrics we identified plus the very tangible costs associated with a failure in the field.

Figure 1. The amount of software defects has doubled in the last years, and NHTSA estimates that recalls and fixes cost automakers $3 billion per year.

 

Defects cost automakers a lot of money. The NHTSA estimates that recalls and fixes across the industry cost automakers $3 billion annually. When it comes to the cost of software-related issues, a 2005 estimate from IEEE put the cost to manufacturers at $350 per car. When you consider the low profit margins across a line of vehicles, it’s conceivable that a serious enough software defect can severely hurt the business. The bottom line is important, but even more important is that people can become seriously injured or even die as a result of a software defect. And it doesn’t matter how far down the supply chain the defect may originate, defects and all their associated consequences become the responsibility of the automaker. As such, any cost analysis around software development needs to take the potential costs of failure into consideration.

Figure 2. In modern cars, numerous complex computer systems are installed, with well over a hundred ECUs processing millions of lines of code.

 

We’ve argued that the complexity of the tiered supply chain for automotive software contributes to the overall risk associated with safety-critical systems. We’ve also reiterated the potential costs to automotive businesses. But there’s another dimension to this issue that reside in the cultural difference between engineering and software development. Software development is almost never engineering. That is, certain concepts from engineering principles, such as repeatability, well-exercised best practices, and reliance on building standards have yet to become firmly established in software development. Additionally, training for software developers can be inconsistent - even non-existent - and organizations would have to go through great lengths to verify that their developers possess adequate knowledge to build safety-critical software.

This is in contrast to engineering in which the attitudes, mindsets, and history of the discipline enforce a process that is less prone to defects when compared to software development. That is not to say that engineers know what they’re doing and software developers don’t. Rather, it’s to say that automotive engineering as a field is twice as mature as software development, and that the intangible, temporal nature of software perpetuates a cavalier attitude in which if it works, then it’s done.

The emphasis in software development is around faster delivery and functional requirements - how quickly can we have this functionality? There is little incentive from management to implement sound engineering practices into the software development lifecycle. Achieving functional safety in software requires operationalizing certain engineering principles: functional safety must be proactive, processes must be controlled, measured, and repeatable, defects should be prevented through the implementation of standards, testing must be effective, deterministic, and should be done for complex memory problems.

The good news is that the attitudes around software development have been evolving. ISO 26262, MISRA, and other standards seek to normalize software development for automotive applications by providing a foundation for implementing engineering concepts in software development processes. Some organizations view compliance with ISO 26262 and other standards as an overhead-boosting burden without any direct value, but the truth is that the cost of failure associated with software defects is much, much greater than the cost of ensuring quality. As in electrical standards that specify a specific gauge of wire to carry a known voltage, coding standards can provide the guidelines that help avoid disaster.


Related


TestOps - The Next Level in Electronic Test

How can you speed overall product development, improve your team’s efficiency, and accelerate time-to-market? Adopt a TestOps approach. Just like software developers did with DevOps, brin...

Hardware-based AES Encrypted Storage Solution

Secure data encryption is essential for a wide variety of mission-critical applications pertaining to both civilian matters and national security. These sectors both require comprehensive safeguards t...

Give Your Product a Voice with Alexa

Join us for a deep dive into the system architecture for voice-enabled products with Alexa Built-In. Device makers can use the Alexa Voice Service (AVS) to add conversational AI to a variety of produc...

The two big traps of code coverage

Code coverage is important, and improving coverage is a worthy goal. But simply chasing the percentage is not nearly so valuable as writing stable, maintainable, meaningful tests. By Arthur Hick...

 

nVent Schroff at Embedded World 2019

The theme of the nVent Schroff booth at Embedded World 2019 was “Experience Expertise – Modularity, Performance, Protection and Design”. Join us as our experts give an overview of th...


Garz & Fricke Interview at Embedded World 2019 with Dr. Arne Dethlefs: We are strengthening our presence in North America

Through its US subsidiary, located in Minnesota, Garz & Fricke is providing support for its growing HMI and Panel-PC business in the USA and Canada while also strengthening its presence in North A...


SECO's innovations at embedded world 2019

In a much larger stand than in previous years, at embedded world 2019 SECO showcases its wide range of solutions and services for the industrial domain and IoT. Among the main innovations, in this vid...


Design and Manufacturing Services at Portwell

Since about two years Portwell is part of the Posiflex Group. Together with KIOSK, the US market leader in KIOSK systems, the Posiflex Group is a strong player in the Retail, KIOSK and Embedded market...


Arrow capabilities in design support

Florian Freund, Engineering Director DACH at Arrow Electronics talks us through Arrow’s transformation from distributor to Technology Platform Provider and how Arrow is positioned in both, Custo...


Arm launches PSA Certified to improve trust in IoT security

Arm’s Platform Security Architecture (PSA) has taken a step forward with the launch of PSA Certified, a scheme where independent labs will verify that IoT devices have the right level of securit...


DIN-Rail Embedded Computers from MEN Mikro

The DIN-Rail system from MEN is a selection of individual pre-fabricated modules that can variably combine features as required for a range of embedded Rail Onboard and Rail Wayside applications. The ...


Embedded Graphics Accelerates AI at the Edge

The adoption of graphics in embedded and AI applications are growing exponentially. While graphics are widely available in the market, product lifecycle, custom change and harsh operating environments...


ADLINK Optimizes Edge AI with Heterogeneous Computing Platforms

With increasing complexity of applications, no single type of computing core can fulfill all application requirements. To optimize AI performance at the edge, an optimized solution will often employ a...


Synchronized Debugging of Multi-Target Systems

The UDE Multi-Target Debug Solution from PLS provides synchronous debugging of AURIX multi-chip systems. A special adapter handles the communication between two MCUs and the UAD3+ access device and pr...


Smart Panel Fulfills Application Needs with Flexibility

To meet all requirement of vertical applications, ADLINK’s Smart Panel is engineered for flexible configuration and expansion to reduce R&D time and effort and accelerate time to market. The...


Artificial Intelligence

Morten Kreiberg-Block, Director of Supplier & Technology Marketing EMEA at Arrow Electronics talks about the power of AI and enabling platforms. Morten shares some examples of traditional designin...


Arrow’s IoT Technology Platform – Sensor to Sunset

Andrew Bickley, Director IoT EMEA at Arrow Electronics talks about challenges in the IoT world and how Arrow is facing those through the Sensor to Sunset approach. Over the lifecycle of the connected ...


AAEON – Spreading Intelligence in the connected World

AAEON is moving from creating the simple hardware to creating the great solutions within Artificial Intelligence and IoT. AAEON is offering the new solutions for emerging markets, like robotics, drone...


Arrow as a Technology Provider drive Solutions selling approach

Amir Sherman, Director of Engineering Solutions & Embedded Technology at Arrow Electronics talks about the transition started couple of years ago from a components’ distributor to Technology...


Riding the Technology wave

David Spragg, VP, Engineering – EMEA at Arrow Electronics talks about improvements in software and hardware enabling to utilize the AI capabilities. David shares how Arrow with its solutions is ...


ASIC Design Services explains their Core Deep Learning framework for FPGA design

In this video Robert Green from ASIC Design Services describes their Core Deep Learning (CDL) framework for FPGA design at electronica 2018 in Munich, Germany. CDL technology accelerates Convolutional...


Microchip explains some of their latest smart home and facility solutions

In this video Caesar from Microchip talks about the company's latest smart home solutions at electronica 2018 in Munich, Germany. One demonstrator shown highlights the convenience and functionalit...


Infineon explains their latest CoolGaN devices at electronica 2018

In this video Infineon talks about their new CoolGaN 600 V e-mode HEMTs and GaN EiceDRIVER ICs, offering a higher power density enabling smaller and lighter designs, lower overall system cost. The nor...


Analog Devices demonstrates a novel high-efficiency charge pump with hybrid tech

In this video Frederik Dostal from Analog Devices explains a very high-efficiency charge-pump demonstration at their boot at electronica 2018 in Munich, Germany. Able to achieve an operating efficienc...