I have come to realize that there is a great synergy, actually more of an overlap, between Product Safety and Functional Safety. I would even go so far as to say that Functional Safety is embedded in Product Safety. 

Since my experience stems from “the old days” (yes, this is showing my age!), we didn’t differentiate between Product and Functional Safety, the systems I dealt with were just “Safety” systems. My “old days” experience is related to Chassis Controls Systems. As a young engineer I became almost immediately involved with Brake Controls, starting in Foundation Brakes, moving into ABS, Traction Control and then into ESC (and all the other aka’s). Following that came Active Cruise Control, Tire Pressure Monitoring, Electronic Parking Brake, Active Steering, etc. Obviously, these systems were safety related. We defined requirements as safety related and assigned more stringent requirements in design, more stringent proof of meeting these requirements, and more stringent manufacturing, operation and service requirements.

I must be honest, when I first saw the ISO 26262 standard, I wasn’t perplexed as to what it was talking about or why these things were needed. To me, it was just a written document saying what I already knew: Safety systems need more stringent requirements, more stringent verification and confirmation of the requirements and test results, and the requirements must be met or we violate at the very least statutory and regulatory requirements for these defined safety systems. As an engineer, you also realize that the statutory and regulatory requirements are put in place for a reason, and typically that reason relates to keeping our end customer safe. If you didn’t meet the defined safety requirements for a system, you faced a potential recall at the very least, so you didn’t release a system that did not meet the safety requirements.

Fast forward, I moved into a position where the system we provided did not have statutory or regulatory requirements, so there were no defined safety requirements, product or functional. So, who knew that there might be safety requirements?

Well, as many of you know, we can only know what we know based on our experience. It turns out, when “performance” systems are electronically controlled, we may start to define that there are actually safety requirements associated with them. The HARA is a very good tool to analyze this and define where there may be Functional Safety Goals (resulting in Functional Safety Requirements) and as many of us have found out, where we didn’t think we have safety requirements, we now do. So, how does that relate to Product Safety?

If I have a system that when electronically controlled may violate a Safety Goal (have an ASIL associated), then I need to consider the other aspects (likely mostly related to mechanical) that can also cause the same Hazard. So, since ISO 26262 does not deal with this (there are no recommended practices or methods relating to the mechanical aspects), how do we address this?

Well, going back to my “old days” mentality, you addressed it through an FMEA (starting at vehicle level). So now, in my FMEA, I need to address not only the electrical and electronic failures but also any mechanical failure that can produce the same vehicle level situation that would violate my top-level Safety Goal. When I look at the Vehicle Level FMEA, that results in a Severity Rating of a 9 or 10. Back to the “old days”, this relates to a 10 “without warning” and a 9 “with warning”(although I know there are some changes potentially coming with the new AIAG/VDA FMEA Severity Ratings, where 10 is more Safety related and 9 is more Regulatory related, which I think is good, because the Regulatory requirements are not always Safety related). So, at a vehicle level, it doesn’t matter if the Hazard is caused by an electronically controlled system (covered by Functional Safety) or a mechanical system, if the Hazard results in ASIL, this must be Product Safety related.

So, at a vehicle level, I don’t care if the potential failure is due to a mechanical issue or an electrical and/or electronic (E/E) system issue, they are all safety concerns. Therefore, overall, I would consider all the potential causes that violate a Safety Goal, ensuring Product Safety. It doesn’t matter how the failure occurs, I need to identify the potential failures and address them.

Strangely enough, the new IATF 16949 Standard (to which all Automotive suppliers will need to be certified to), addresses Product Safety specifically. Please check out my next blog which will discuss how the Product Safety aspects in IATF 16949 can be met if the main practices of ISO 26262 are followed within your organization for the design, development and production of all Safety systems or components.

Leave a Reply.

  1. Shahid Faruqui comments on How Does Product Safety Relate to Functional Safety?
    Shahid Faruqui

    Dear Jennifer:

    Why can’t you just borrow ASIL ranking systems from ISO 26262 for a mechanical hazard (Vehicle LvL Hazard caused by a pure mechanical failure).

    So that ‘this hazard’ can be compared with ‘E/E parts based hazards’ where you gladly use ISO 26262 for hazard ranking.

    Use of DFMEA RPN or the newer AIAG/VDA figure of merit will not be a ‘pure’ comparison.

    I do not see anything in the constituents of ASIL scale namely – Severity, Exposure and Controllability that prevents me from doing do.

    I understand testability analysis/diagnostics or FMEDA will not apply to mechanical parts.

    I also understand ISO 26262 has a lot of recommended best practices and design guidelines that only apply to EE systems, and cant be adopted to mechanical parts.I am not asking for those – I am just asking to ‘borrow’ ASIL ranking from ISO 26262 so that I can purposefully compare mechanically caused hazards to the classical EE parts based hazards.

    I have been doing these analyses for 30 plus years – and for mechanical parts, I do not see a better approach … LOAD-STRENGTH analysis? … heck no …

    just think about it !!!

    Looking forward to your response