“But the important thing about learning to wait, I feel sure, is to know what you are waiting for.” —Anna Neagle
Many safety instrumented functions (SIFs) are deliberately designed to wait before tripping. Like a sergeant commanding his troops to “Wait for it!” the SIF designer is anxious that the SIF not trip prematurely. Some worry that this practice is a violation of the intent of a Safety Instrumented System (SIS), perhaps even reflective of a moral failing of the SIF designer. Yet nothing could be further from the truth. While some delays are unnecessary, or even a bad idea, most SIF designs benefit from a delay.
Where possible, SIFs should include a delay between the instant a trip condition is detected, and the instant the final control elements are commanded to trip. The purpose of this delay is to avoid spurious trips because of stray signals, jiggled wires, lightning, etc. The standards recognize this, and this approach can be used to good purpose when the delay time is accounted for in the design of the SIF.
Response Time and Process Safety Time
“Response time should be less than half of the process safety time.” This is helpful, so long as one knows what response time is and process safety time is.
Process safety time is the length of time from the onset of a problem until the problem becomes real. It is dependent on the process and set points, not the SIF hardware. In Guidelines for Safe and Reliable Instrumented Protective Systems, process safety time is defined as “the difference between the time at which the unacceptable process condition occurs and the time where the hazardous event occurs.” This definition is too narrow. The triggering condition may be an acceptable process condition, but one that signals the likely onset of a hazardous event. Also, some may read “process condition” to mean a single process variable, when a set of process values comprise the process condition of concern. So long as these distinctions are recognized, however, the Guidelines definition is useful.
Response time is the length of time from detecting the onset of a problem until the final control elements have acted and performed their function. It is dependent on the SIS. While all the SIS standards use the term “response time”, none define it. The Guidelines do, however. “Response time—Time required to fully execute the protective function from detecting the process condition to achieving the safe state of the process.” To understand what this means, consider the following elements:
- Time for the sensors to detect and for the Safety Logic Solver (SLS) to become aware of the trip condition.
- Time for the SLS to decide.
- Time for the Final Control Elements (FCEs) to act.
- Time for the process to respond to the actions of the FCEs.
It is not solely the action of the FCEs that determine response time. In addition to logic processing and process response, there is again a focus on detection. From that perspective, process safety time and response time have the same starting point: detection of the trip condition.
It is possible for a response time to be fixed, and then to select trip conditions that result in a sufficiently long process safety time. Ideally, however, process safety time drives the requirement for response time.
Requirements of Standards, Codes, and Recommended Practices
The SIS standards and codes—IEC 61508, IEC 61511, ISA S84, NFPA 85, and NFPA 86—all refer to response time. The NFPA standards, being prescriptive, simply state what they must be, with no regard for process safety time. The IEC standards (and by association, the ISA standard) are performance-based and so require consideration of the process safety time.
The Boiler and Combustion Systems Hazards Code, NFPA 85, requires that system response time “be short to prevent negative effects on the application,” without defining “short.” Later in the standard, however, there are two requirements for response time:
- The response time from flame failure to de-energization of the safety shutoff valves shall not exceed 4 seconds.
- The response time from de-energization of the safety shutoff valves to full closure shall not exceed 1 second.
The first item refers to the first and second elements of response time: detect and decide; the second item refers to the third element of response time, act. Implicit in this NFPA code is that the fourth element—process response—is either irrelevant or so fast as to be negligible.
The Standard for Ovens and Furnaces, NFPA 86, is also prescriptive, but less explicit. Regarding response time, the section on Combustion Safeguards simply states that “Each burner flame shall be supervised by a combustion safeguard that has a maximum flame failure response time of 4 seconds or less.” Users may interpret response time differently, but this requirement most likely reflects the 4 second time from flame failure to de-energization of the safety shutoff valves required in NFPA 85.
The performance-based standards take a different approach. A Safety Requirements Specification (SRS) must specify response time, and the response time should be “less than the process safety time”. There is no requirement in the standards for the response time to be less than half of the process safety time.
So where does the requirement for response time to be less than half of process safety time come from? In Guidelines for Safe and Reliable Instrumented Protective Systems, there is a single reference: “Each function should be capable of acting within one-half the process safety time allocated to it by the selected set point.”
Accounting for Delays
There is a question about how to account for delay time. Should it be deducted from the process safety time, or should it be added to the response time? There is no standard interpretation.
When complying with the NFPA codes, the answer is straightforward. Any delay time is part of the 4 seconds allowed in the code. If the time from detection to de-energize is 2.6 seconds without a delay, then a 1.4 second delay may be used.
When complying with the standards, the answer is also straightforward. Any delay time must be less than the difference between the process safety time and the response time. It does not matter whether the delay time is deducted from the process safety time or added to the response time.
The question is only meaningful when the response time is limited to some fraction of the process safety time, say half. In that case, the amount of delay time that can be allowed depends on how delay time is treated. If delay time is deducted from the process safety time, the allowable delay time will be greater than if the delay time is added to the response time.
Example: Consider a hazard with a process safety time of 15 seconds, and a SIF response time of 4 seconds. A response time design criterion says that response time should be less than half of process safety time. The SIF meets that criterion. Now consider adding a 5 second delay to avoid spurious trips. If the 5 seconds is deducted from the process safety time, then 10 seconds becomes the basis for comparison, and 4 seconds is less than half of 10, meeting the response time design criterion. On the other hand, if the 5 seconds is added to the response time, the basis of comparison is 9 seconds, which is not less than half of 15 seconds. In the second case, the design does not meet the response time design criterion.
Either approach meets the standards. The purpose of including a safety factor is to build in a cushion to account for uncertainty. Since, unlike response times, delay times are not uncertain, it seems reasonable to take the less conservative approach and deduct delay times from process safety times. The conservative approach can also be used successfully. In most cases, it will probably not make the design more difficult or expensive, and in some cases, it may result in less risk.
Addressing Process Safety Time in the SRS
The standards require that an SRS specify the response time for each safety instrumented function. This is the total time from detecting the trip condition until the process has gone to the safe state. There is no restriction against specifying detection time, logic time, action time, and process response time separately, but except in the case of the NFPA codes, there is no requirement to.
None of the standards require the SRS to include process safety time. For purposes of auditing, however, including the process safety time in the SRS allows a ready comparison between specified response time and process safety time.
Complying with Standards, Codes, and Recommended Practices
Response time, including any delay, must be less than the process safety time. In the case of systems designed to comply with NFPA codes, the response time is prescribed at less than 4 seconds. Safety factors can be used when specifying response times, but are not a requirement of any standards. At least one guideline, however, suggests a safety factor of two, stating that response time should be less than half of the process safety time.
Use Delays
Use delays in the design of SIFs wherever they can be. A slight delay before a trip will reduce the frequency of spurious trips, which makes a SIF that much more reliable. When you use a safety factor, decide how you are going to delay—as an addition to the response time or a deduction from the process safety time—and apply it uniformly to all SIF designs. Keep in mind, though, that when you use a safety factor, it is more conservative to consider the trip delay as an addition to the response time, even though it is also valid to consider a trip delay as time to deduct from the process safety time.
