For decades, for any semiconductor company aiming to get a foot in the door to the automotive electronics market, the first order of business was clearing the Automotive Electronics Council's AEC-Q100 standard, a critical stress-test qualification for automotive ICs.
This is still the case. But it might not be enough for entry into a future of fully autonomous cars, with the advanced driver assistance system (ADAS) as its maiden technology.
Ensuring functional safety is the critical next step for both software and hardware deployed in cars. The burden of proof — product offerings compliant with the functional safety standard ISO 26262 — applies to practically everyone involved in the automotive food chain: foundries, chip vendors, RTOS/tool companies, and apps developers included.
As daunting as the functional safety standard is, Freescale Semiconductor has taken up the challenge. Freescale announced Monday (May 19) its collaboration with Green Hills Software and Neusoft Corp. to develop a comprehensive ADAS vision system built on an ISO 26262 ASIL (Automotive Safety Integrity Level) assessed software foundation.
The basic building blocks include Cognivue Corp.'s APEX image cognition processing IP, now available from Freescale. Advanced, silicon-aware software will come from Neusoft's ADAS vision applications and Green Hills Software's safety-certified Integrity operating system and tool chain. Freescale has an exclusive partnership agreement in place with the functional safety expert Green Hills for the automotive domain, according to Allan McAuslin, Freescale's ADAS product manager.
Cost and design implications
The ISO 26262 potentially carries a risk for every chip vendor eyeing the growing ADAS market. The easiest challenge is designing an ADAS system, enabled by a certain chip (and module), to warn a driver about what's in front of the car. But if the ADAS system is expected to take control from the driver when danger is imminent, the implications for long-term reliability are huge, says McAuslin. Of course, the industry is also aware of the implications for its liability.
More significantly, ISO 26262 poses massive ramifications for the design and cost of fully automated cars. As the technology develops, the cost of safety often will require “redundancy” in systems, McAuslin observes. But economy cars, like the Ford Focus, will only stay economical by trimming away safety redundancies while not compromising safety. This will be a neat trick.
“The ADAS software platform battle is just getting started,” says Egil Juliussen, director of research for Infotainment and ADAS at IHS Automotive. The players are just positioning themselves for future growth, he notes.
Juliussen, calling ISO 26262 “very important,” sees it having “a long-term impact on software reliability over the next decade.”
The concept and techniques for functional safety, represented in ISO 26262, are well established. But how different industries apply them is another story.
In a recent interview with EE Times, Michael Barr, an embedded software expert, offered the reminder that poorly designed software can kill people.
He said in a video interview, speaking of the failure of the Therac-25 radiation therapy machine in the mid-1980s and a 1991 Patriot Missile failure, “Time and time again, we heard in both cases that people were saying 'We did a lot of testing'; and they named the number of hours they did testing… But in hindsight, the lesson we learned was there were software defects, and those software defects were lethal…
“So, counting the number of tests, or even the kinds of testing, is not sufficient. You have to do what's called functional safety. You have to build the safety case. And we are not inventing these techniques. These techniques exist, and they have existed for some time. It's a matter of applying those.”
So, where are we with the automotive industry when it comes to functional safety?
Next page: Smart move
Carmakers, whose traditional strength (and focus) has been the safety of mechanical functions, aren't exactly known as software wizards. Juliussen notes that the ISO 26262 debate for carmakers is “only getting started.” The automotive industry needs to apply ISO 26262 for “every ADAS system — the sooner the better.”
Paul Colestock, director of segment marketing at GlobalFoundries, recently told EE Times that the industrywide discussions on how best to comply with ASIL, a process described in the ISO 26262, have only begun. Every component, ranging from foundries to chips, chip modules, and software, needs to be certified to meet a specific ASIL level, he says.
It's far from clear how each will respond to the demand, and if there will be any division of labor that allows each segment to meet certain aspects of ISO 26262. Freescale's McAuslin explains that, while there is now no such division, each supplier is expected to put ISO-aware product and process in place. Tier 1s — which integrate the system — need to know the ASIL of each component and software and will eventually work with OEMs for approval.
The ASIL classification helps define safety requirements necessary to the ISO 26262 standard. ASIL is established by performing a risk analysis of a potential hazard by looking at the severity, exposure, and controllability of the vehicle-operating scenario. The safety goal for that hazard in turn carries the ASIL requirements. There are four ASILs identified by the standard: ASIL A, B, C, and D. ASIL D dictates the highest integrity requirements on the product.
So, could the stringent ISO 26262 functional safety standard trip up certain chip vendors? It will, without plans for building a comprehensive ADAS system that involves everyone in the supply chain.
Jeremy Carlson, senior analyst for ADAS automotive technology at IHS, calls Freescale's partnership a “smart” move. He explained that Freescale's platform combines pieces of the supply chain into an off-the-shelf solution while allowing for continued development or customization after sale, should the customer prefer it.
“One key element of this,” says Carlson, “is enabling visibility,” or keeping transparency for technology developers. The ADAS system is still a market segment enabled by nascent technologies. It's necessary to allow technology developers “to continue development,” instead of supplying them “a sort of black-box solution, which isn't easily altered.”
On the one hand, the black box is a preferable approach, because some car OEMs or Tier 1s “won't have the expertise to further develop on that platform even if they wanted to,” he says. However, the black-box approach could “keep cost down, since there's no need for other components like a development environment.”
On the other hand, the open approach (e.g., Freescale's announced partnership), which includes a development environment and other related tools, means capable customers can simply use this as a development platform to continue working on customization or differentiation, Carlson told us. “That it also works as an off-the-shelf solution means the Freescale partnership is more flexible to serve more types of clients, though that may necessitate a higher average price as well, given the extra tools and flexibility.”
— Junko Yoshida, Chief International Correspondent, EE Times
This article was originally published on EBN's sister publication EE Times.