After a false trip incident, I heard a control engineer express his displeasure with the automatic diagnostics in a new safety rated transmitter.  The transmitter diagnostics were annunciated by sending the analog current out of range.  In this case, the current went to 3.6 milliamps.  The problem was that the logic solver was configured for a low trip and did not recognize out of range signals as a diagnostic alarm.  It interpreted the signal as a trip condition.  The safety instrumented function (SIF) worked perfectly.  It did the job for which it was programmed.

I can see how the diagnostics are blamed for the problem, but how could anyone not want a product that can tell them when it fails?  The answer:  When the system is programmed to trip on a diagnostic and trips are NOT WANTED!

Sometimes the problem is inadvertent.  Those writing the Safety Requirements Specification (SRS) do not know the details of how the equipment works because often it is not even chosen yet when the SRS is written. Those doing conceptual design do not update the SRS because it is not their job. No one gets the message about programming the PLC to recognize out of range analog signals as a diagnostic alarm.

Then of course there are those who demand that every diagnostic alarm cause a trip. “It is the safest thing to do,” I have heard.  But is it?  How safe is the design if the production people disable the safety function because it causes too many false trips? I have certainly seen this. I once asked how reliable is your safety system?  “It is great since we fixed it.” They fixed it by disabling the output. 

Please be careful when you design a SIF.  Take full advantage of new product features like diagnostics that significantly improve safety.  But be careful that you understand how the products work and design the parts of the system to play well with other.