@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.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.