Quality And Safety In Automotive Electronics: Venturing beyond ISO-26262

For the automotive market, chips need to last a lot longer than they do in a phone.

popularity

By Bernard Murphy and Jim Hogan

Rumors of ‘Project Titan’, the Apple Car, are making the rounds. True or not, when we hear Apple touted as a potential automaker, it’s clear how pervasively electronic content has invaded our cars.

A 2013 National Auto Dealers Association report graded electronic content at 15% of auto-buying decision factors, impressive growth from close to zero only a few years ago, especially in the non-luxury segment. Even brand increasingly is tied to electronic differentiation; commercials today routinely lead with infotainment, intelligent safety and driver-assistance features. If we consider evolution beyond traditional options, competition in hybrid and electric drivetrains and semi-autonomous and autonomous vehicles will further accelerate the importance of electronics in the car.

hogan1
Figure 1: Sample of the electronic systems in automobiles today

Use of electronics in automobiles is not new, but until recently was largely invisible to the consumer. The first significant systems were used to control engine functions, to meet Clean Air Act requirements for 1981.

Screen Shot 2015-09-02 at 10.41.03 AM
fig2b
Figure 2: Make-up of electronic control unit (ECU)

This functionality was built largely on well-proven and relatively uncomplicated microcontrollers. But as simple as these are, they have been required to pass five-year qualification cycles before finally appearing in production cars. To meet this arduous objective, a chip manufacturer would create the whole chip design internally, examine and validate it exhaustively, and, once qualified, would consider only modest incremental improvements in future generations of the device. By doing this, quality and safety assurance could build on already well-understood and well-validated characteristics of earlier generations.

Safety and ISO-26262
The advanced electronic content we now see doesn’t fit well with this traditional approach to qualification. Features are considerably more complex than those early microcontrollers, and we consumers are conditioned by our portable devices to expect new capabilities every year. This disconnect between rapid evolution, complexity, and safety is a recognized problem and drove the creation of ISO-26262, an industry-wide standard for the development of safety-critical electronics systems. Electronic component suppliers who plan to sell to automakers must now document and demonstrate they are following a development process in compliance with the standard.

ISO-26262 provides a necessary step to ensure automotive safety, but it fails to directly address two fundamental changes from development of those earlier microcontroller-based systems. First, a large design can no longer be developed by a single team. Major functions (IP) are now supplied by multiple third-party organizations. Unlike expectations for simple microcontrollers, now no single team understands all the logic in the design, which makes it much more challenging to anticipate and guard against pathological behaviors in the complete system. IP suppliers also are required to comply with the standard, but there is little evidence that this piece-wise compliance is comparable to full compliance. Second, the complexity of total chip systems long ago passed beyond any possibility of exhaustive testing. In consumer devices the industry response has been to test only for expected use-cases, but this approach is clearly inadequate for safety-critical auto electronics where life-threatening behaviors may lurk in unexpected corner cases.

Quality
Quality is also important, both for consumers and the auto industry. We have much higher expectations of quality and durability from a car costing tens of thousands of dollars than we do from a phone costing at most, a few hundred dollars. Multiply the kind of problems we routinely face in portable devices by a typical $10M recall cost and, even if they choose to issue recalls for only the most serious problems, auto companies either go out of business or must deal with perpetually dissatisfied customers. This problem is amplified when you compare how long we expect our vehicles to last against our ability to upgrade our phones every two years.

hoganfig3
Figure 3: Age and ownership trends of automobiles

This is not an academic concern. Buy a car today and you will immediately learn that the infotainment system is not covered by the five-year/50,000 mile warranty that covers the rest of the car. For the same functionality you get in your phone, you get the same warranty – two years – and you have to pay a premium to extend that warranty. Even if you didn’t pay that premium, you won’t be happy with the dealer if the infotainment stops working before you sell the car. Quite possibly you’d decide not to buy that brand of car again – a serious consideration for brand loyalty.

This quality challenge is reflected in customer satisfaction surveys. The area that generates the most complaints is infotainment and all associated electronics extending to Bluetooth pairing, voice commands, and backup systems. Some of this may be teething problems, but a likely takeaway is also that quality acceptable in a phone doesn’t rise to expectations for a car. And it’s worth remembering that this problem is happening in systems developed under ISO-26262.

fig4
Figure 4: Satisfaction survey results from new car buyers

Many new entrants to automotive electronics have strong backgrounds in consumer electronics and the PC industry, but are new to the significantly more stringent expectations of quality and safety in the automotive market. ISO-26262 goes part way to address this gap, but is not sufficient on its own and needs to be strengthened to meet public expectations for cars.

Where do we go from here?
Rising to these new expectations will take more than a thin layer of process overlaying existing semiconductor (chip) design methodologies. Semiconductor makers will have to seriously up their quality game from what may be acceptable for smartphones, to what we would expect for cars. We need to be thinking about hardware design the same way we think about manufacturing — driving functional failure rates down to, or below, parts per billion (ppb), over the useful lifetime of a car.

This will require a front-to-back mindset change in regards to safety and quality. Chip design has previously been viewed as “who cares how we get there as long as we are competitive and reasonably efficient”. Engineering practice in many fields has taught us that this doesn’t work for ppb quality any more that it would in manufacturing. Each step has to be quality-conscious and continuously improving.

Chip design component (semiconductor IP) selection should be based not just on what the IP supplier certifies, but also on what the chip manufacturer requires. The IP supplier is certifying for a general market, but the chipmaker must certify for a specific application. That may require tighter controls, especially validating specific usage configurations and anticipating pathological interactions between the IP and the rest of the chip.

The development process must be monitored at multiple points with quality gates. It is a recognized reality in manufacturing that quality requires continuous measurement and control. It cannot be managed to ppb levels solely though final gates in development. Unfortunately, this philosophy is followed, sporadically at best, in today’s semiconductor design teams.

Chip assembly and verification should strive for correct-by-construction and complete validation wherever possible, to overcome earlier-mentioned limitations in coverage through dynamic testing. Today, however, human design assembly may be accelerated with custom scripting with little cross-check as the norm. This is not a defensible approach when there are standards and tools to automate these tasks. Static verification should play a bigger role in full-chip testing since it is inherently more complete and complementary to traditional verification techniques.

Finally, hardware development must give more thought to how to support validating mission software that will run on the hardware, both during software development and over the lifetime of the application in a car. It is not sufficient to assert that behavior has been tested as well as possible, given that some pathological behaviors between hardware and software may not have been uncovered in that testing. Defenses should be provided to detect out-of-bounds behaviors even in long-term use.

fig5
Figure 5: Autonomous vehicles of the not-too-distant future

Making these changes will not be easy, and perhaps they will not fit the business objectives of every semiconductor supplier. But they are essential for auto-electronics to become a dominant part of our driving experience and a healthy and growing market for electronics suppliers. Semiconductor companies have proven already that they can step up to these levels of quality in manufacturing. Now they need to make the same commitment to optimizing the development process.

—Jim Hogan is the managing partner at Vista Ventures and a venture capitalist specializing in the semiconductor industry. He is co-author of this blog.



  • Harry Qin

    Is there any documentation or file to explain well what difference between CE and automotive in terms of IC design flow?