An ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis, operating efficiencies and cost savings, as well as all relevant safety standards, such as those from NFPA, ANSI, RIA, IEC, ISO and OSHA. About J.B. Titus.
Functional Safety From UL - Let's Discuss!
January 25, 2011
Certainly, functional safety evaluations can play a large role in improving levels of machine safety in industry. By providing more consistency between SIL (Safety Integrity Level) and PL (Performance Level) via both being probabilistically derived should help. The old practice of determining hazards under EN 954-1 qualitatively is being replaced by ISO 13849-1 and the new quantitative PL approach. Additionally, the new approach addresses the use of programmable electronic safety devices and technology in the safety-related control system. Yet, the old way of providing machine safety via hard wired electromechanical components is still considered an approved approach for machine safety. This presents a rather broad range of considerations for industry regarding their mandated OSHA conformance to providing a safe work place. This is why in my previous blog on this subject posted Dec. 17, 2010 I stated, “In my opinion, we need to start a discussion on this subject to gather comments from across industry.”
To address this issue I’ve started a discussion at a Safety Forum on Linkedin. I urge you to take some time to post your comments, questions, advice, etc. on this issue so that we can improve our collective understanding of this transition. For example, I find a lot of great information on the UL Functional Safety web site but one of my take away’s is that a lot of the material appears to be focused at the manufacturer or OEM. What would your opinion be? If you agree, how does the end user comply with the same industry standards when they install a field retrofit on a used machine? The end user may not have the technical staff to perform the required engineering and analysis. In the US, industry standards apply to the manufacturer, OEM, Systems Integrator and the end user. In fact, OSHA points the ultimate responsibility and enforcement to the end user.
Are these issues too complicated or does it only appear that they might be complicated and in reality they’ll work themselves out?
INTEGRATED SAFETY COULD BE YOUR OPPORTUNITY – CONSIDER IT!
Submit your ideas, experiences, and challenges on this subject in the comments section below. Click on the following text if you don't see a comments box, then scroll down: Functional Safety From UL - Let's Discuss!
Contact: www.jbtitus.com for “Solutions for Machine Safety”.
For more than 30 years, J.B. Titus has advised a wide range of clients on machine functional safety solutions, including Johnson + Johnson, Siemens, General Motors, Disney, Rockwell Automation, Bridgestone Firestone, and Samsung Heavy Industries. He holds a Bachelor of Business Administration degree from Oklahoma University in industrial management and an MBA from Case Western Reserve University in marketing and finance. He is a professional member of the American Society of Safety Engineers and is OSHA-certified in machine guarding. Titus is also TUV-certified as a Functional Safety Expert and serves on several American National Standards Institute, National Fire Protection Association, and National Electrical Manufacturers Association national safety and health standards committees. Reach him at jb(at)jbtitus.com and via www.jbtitus.com.
Wednesday, 02-02-11 10:37
My own background is software/electronics engineering of safety-critical embedded systems. My personal opinion is that the automation industry desperately needs a change in the way safety-critical systems are implemented. "Automation" is far, far behind other industries when it comes to safety standards.
In traditional industry automation, people still sit an calculate their ridiculous MTTFd, designing sand castle systems to hold together for x years. And if something does break before the x years have passed, despite the calculations, then let the system rain destruction upon the users!
This is all because the precious 61508 SIL standard and its various misguided offspring are not even based on scientific research! Pick up pretty much any technical rationale to the rules needed for SIL, you can find them in 61508-7. First of all you will notice that they rarely cite more than one source for the claims. Second, most of the references are ridiculously non-scientific.
Some examples: Books regarding CPU architectures and memory management dated to the early 70s, as if CPUs haven't evolved at all in 40 years. Articles from engineering papers and newsletters, most available only in german. Program design research from the 70s, before good program design was even invented. Algoritms for memory verification dated 20 years before flash memories were invented. Other standards, that in turn doesn't have any valid references. Etc, etc. This is nonsense!
The only valid sources should be (widely recognized) scientific research, or books written based on such research. Yes, there are a few such valid sources in 61508, but they are rare. Most of the standard seems based on the assumption that "if something was ever written in text, by anyone, then it is true".
It gets even worse when we come to calculations of MTTF, DC, PL etc, because then there are no sources at all to be found, not even non-scientific ones. For all I know they may as well have been invented by some ISO bureaucrat with no experience from designing safety-critical systems what-so-ever.
Furthermore the demands on software in 13849 are completely ridiculous, taken out of the blue. They have no relevance to software in general, and safety-critical software in particular. Many of the requirements cannot even be applied to high-level languages. Whoever wrote them was clueless about modern programming.
These standards need to be banned, not preached. They are an enormous threat to industrial safety.