It was left to Marc Osajda, global automotive strategy manager at Freescale Semiconductor Inc., to bring the panelists and the audience down to earth. He made the point that although the market might increase the pressure would come from automobile makers to do all the difficult things; to reduce size, reduce power consumption and reduce cost. The latter was particularly true as much of the expansion of the market would be coming in emerging markets and costs would have to be reduced significantly to hit car price targets.
Bernhard Schmid, manager of sensor systems and the technology center for chassis and safety division of tier one supplier Continental Teves AG, didn't disagree on this point. But his wish list included car-to-car and car-to-infrastructure communications, for enhanced traffic safety, as well as more robust, less sensitive, lower cost MEMS sensors.
There followed a dialog between Freescale's Osajda and Conti's Schmid that explored the likely impact of ISO26262. The standard, published in November 2011, provides requirements, processes and methods to mitigate the effects of systematic and random faults. The standard requires proof of risk assessment and documentation of the steps taken to avoid systematic and random errors in functional systems in product development. This might include the inclusion of such things as redundant systems.
Osajda's initial position was that the standard, with its classifications of A, B, C and D levels of automotive safety integrity levels, takes a system-level view of safety in road vehicles. "It is a system architecture thing," he said.
Schmid's interpretation was different. "Sales into automotive requires that MEMS makers change the way they develop and manufacture," he said. One of the main requirements is the documentation assembled during the MEMS design process to prove that safety has been considered and the measures that have been taken and that can be passed downstream to the tier-1 and on to the automobile maker.
Some car makers have reportedly been asking for ISO26262 compliance since early 2011 although most silicon and software, developed before the publishing of the standard, is inherently non-compliant. Schmid said that MEMS makers must respond if they want to sell to tier-1s.
Other concerns raised from the floor included that visual sensors would replace inertial MEMS as image sensors together with software can be better at analyzing dangerous situations ahead of impacts and helping with avoidance. Schmid tried to relieve some concern by making it clear there is room for a wealth of sensors in Continental systems "Think of your human senses. Your eyes didn't cannibalize your ears."
@Peter Clarke: it seems like some of the regulating authorities are making things harder for us engineers. On one end, (as you mention, the legal requirement in France to carry a breathalyzer in the car, mandatory tire pressure monitoring systems, etc), there are must-comply requirements while the other, like ISO26262, are putting additional design requirements.
There are existing quality requirements that ensure products designed are up to the standard. What is deficient in ISO/TS 16949 (2009) that ISO26262 aims to fill?
I am not an expert on ISO/TS 16949 (2009) or ISO 26262 but from what I can see the former is a quality management standard that does not specifically address functional safety.
Would it be possible to be ISO 16949 compliant and produce an unsafe vehicle?
The point of ISO 26262, as fas I can see, is to prevent, as far as is possible/feasible, the design/manufacture of an unsafe vehicle or a vehicle that could become unsafe AND should there be a failure that produces a dangerous situation to have an audit trail that means the vehicle maker and/or an upstream supplier can be held accountable.
Hi Peter, thanks for the follow up. It looks like the ISO 26262 is an adaptation of IEC-61508. I haven't read the ISO document but it would seem that it may introduce some additional requirements specification on the 'system' but not at the component level. So the burden is more on the adopters of MEMS in vehicles than on the MEMS vendors. I doubt if design procedures at component-level change significantly from what they are now; component vendors may need to provide additional doc's as @Dave.Dykstra also point out below.
That was kinda the Freescale guy's initial position. However, the Continental executive made his point: there's work to be done and the Tier-1's expect their suppliers to do as much of it as possible.
The Conti guy seemed to indicate that MEMS components (and general ICs and software as well as far as I can tell) have to documented DURING DESIGN for the purposes of ISO 26262.
Obviously, that has not been done for most devices and LOCs currently deployed.
I think that the key point here is for the Tier1 to define a safety architecture at the system level. The choice of the safety architecture will determine to what ASIL level the silicon devices (including sensors) will have to be designed.
The mistake in my opinion is to ask ASIL D for everything upfront. Using ASIL D components in an application does not guarantee that the application will be ASIL D.
Freescale is specifically adressing functional safety through its Safe Assure program in order to offer silicon solutions that will fit our customer needs.
Have a nice week end,
Marc Osajda, Freescale
Quite an interesting story. Of course, the manufacturers will have some issues at first until they get things lined up well to be able to readily provide the required documentation. The adoption here is probably not radically different than the adoption of quality standards and the added requirements can probably be met by an expansion of those methods to produce the proper audit trail. And, of course, this will ultimately have an impact on parts delivery schedule and price, but much of this is probably long overdue.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.