[:en][vc_row][vc_column][vc_column_text]Have you ever wondered why some dangerous failures are classified as undetected and others are classified as detective?  Aren’t dangerous failures all dangerous? Why do we classify them differently?

Let’s say we have a plant that is running in normal operation mode and the system needs to trip. The safety function of this system is that the actuator will attempt to move/close the ball valve to the safe position. However, what happens if the stem of the ball valve had previously sheared from the actuator?  That would be considered a dangerous undetected failure in both the close on trip application and open on trip application.

A broken stem will prevent the ball valve from moving and the system would not be able to perform the safety function.

If a test is performed that only monitors that the stem moves, the dangerous failure will not be found since the actuator can still move the top of the stem.  This test does not reveal that the bottom of the stem is no longer connected and does not move the valve. This failure would still be considered dangerous undetected.

If a partial valve stroke test (PVST) is performed that monitors either the flow rate, leakage, or actual valve position, the failure would turn into a dangerous detected failure.  This is because the failure would be found when the test results showed the valve not moving when the actuator thinks it is.

Only detecting the dangerous failure rates isn’t enough.  Detecting undetected failures are key in creating a safety system![/vc_column_text][/vc_column][/vc_row][:zh][vc_row][vc_column][vc_column_text]Some organizations complain about the ‘high bar’ to comply with 61508.  They complain that there is too much overhead in documentation and testing, and it all costs too much.  Other organizations actually benefit from this ‘high bar’ as a barrier to entry for competitors.  This is a differentiation factor for competitive advantage.  So 61508 can sometimes be a double-edged sword.

Your organization may have been producing widgets for years, but a safety widget is often a different product and is intended for a different purpose.  It’s logical that it deserves more attention to detail to reduce the risk of failure.

Meeting 61508 requirements is not that much different than trying to meet other international standards.  Each standard has its own set of requirements.  Some standards may have more overlap than others, and meeting some of those requirements is bound to help meeting others, in whole or in part (eg., EMC).

But corporations rarely look for MORE work to do… they look to streamline operations and do more with less.  There is no reason this concept cannot work for functional safety products.  The more training your staff has regarding functional safety, the more efficient and streamlined your development process can be.  And there are many automated tools that can help.  But once your processes are compliant to some SIL, you want to be sure you maintain or improve your adherence to those processes.  It does you no good to put a good process in place if there is no enforcement to follow it, especially for modifications.  In my world, I have seen too many “small changes” made to products that were not well thought-out and the true impact not known until the field service group started getting customer complaints.

The truth is, designing products for 61508 does involve a bit more effort.  But it is not usually an overwhelming effort.  Best practices in software and hardware development are incorporated into the current 61508 requirements.  In a way, you’re just keeping up.  Of course, there is nothing wrong with going a bit farther than you have to, but any of these improvements should make sense in your development environment.  If these improvements add to the bottom line because of higher customer satisfaction and lower field return rates, all the better.[/vc_column_text][/vc_column][/vc_row] [:]