Q: We are going to design a fire and gas monitoring and alarm system (FGS) for an oil and gas plant. The plant is old, and it is not provided with an emergency shutdown system (ESD). The foreseen number of input/output signals in the anticipated fire and gas detection system is less than 500. The fire and gas detectors will only alarm and monitor. Is it mandatory to make an assessment for the SIL level? I've checked ISA-84.01-1996 and it states that "1.2.14 Systems where operator action is the sole means required to return the process to a safe state are not covered by this standard. (e.g., alarm systems, fire and gas monitoring systems, etc.)"
My question is, do we have to design two separate control systems (one non-SIL for process control and one SIL-certified system for (ESD/FGS), or it is acceptable to design just one SIL system for both process and ESD/FGS, and if it is, what constraints should be considered? In your judgment, must we have an SIL, or can we proceed with a non- SIL system?
Ragab Abdel Fattah
A: You will find below a number of good answers, so I will only say that ANSI/ISA 84.00.01 (2004), which is a relaxed version of IEC 61508/61511 (1996) does not apply to pneumatic or hydraulic logic systems, nor to fire and gas systems, safety alarms or safety controls. Therefore, in the case of your FGS, basic process control system (BPCS) and SIS separation is not a requirement.
As you can see from the answers below, a fair amount of confusion does exist in this area. It is for this reason that I have dedicated a full chapter in my handbook to SIS, and in addition I am dedicating my Lessons Learned column in this issue to a fuller explanation of SIS.
A: F&G is a mitigation system—after the event, such as a rupture, etc. It does not prevent the event. Hence IEC 61508/61511 does not cover it. SIL assessment for F&G is not a requirement.
H S Gambhir
A: First of all, the 1996 version of the ISA 84 standard is obsolete and has been replaced by the 2004 version (which is really the same as IEC 61511). There is no requirement to design a F&G system according to the standard, although you may if you wish to. The attached paper shows how assigning SIL to such functions is usually a bad idea, especially if it is for alarm-only functions. If anything, you should see if you need a safety instrumented system. It is better to prevent the bad event from happening than merely mitigating it (or simply detecting it with a F&G system).
There is too much to explain in an email. See my book, Safety Instrumented Systems: Design, Analysis and Justification, 2nd ed. You could also look at this white paper, "SIL Rating for Fire and Gas System Hardware—an Introduction to ISA TR84.00.07." Generally speaking, most process facilities use two separate systems; one for control, one for safety (and typically a separate system for fire and gas as well). However, the risk in a simple gas plant may be low enough to use one system for control and safety.
Paul Gruhn, P.E.
A: If there is no executive action, and all the mitigation upon fire and gas alarms are manual and based on operator judgment, there is no need of SIL-certified FGS.
However please remember, in the future, if the company decides to implement proper FGS functions such as confirmed fire or gas detection and unit blowdown, you need to go for a SIL-rated PLC.
There are three other points to remember.
1) Control and shutdown layers are independent, and hardware and other parts should not be shared. This is to avoid common-mode failure and increase availability of the respective systems. Also, it is normal practice for an operator to change the alarm and setpoints for control functions during operation. Writing emergency shutdown (ESD) logic on PLCs should only be done after the management of change (MOC) review. This is a procedural issue.
2) An ESD PLC is SIL3-rated and costly hardware. The same hardware type can be used for control functions, provided there is no common hardware and utility shared by both control and ESD functions. You can choose a scalable ESD system and choose a lower specification for control hardware. For example, if you chose HIMA, you can consider 1OO2D architecture for ESD and simply 1OO2 for control processor. The system vendor also can provide different software for those, as ESD software should comply to IEC standards, and control software doesn’t need this. This will reduce cost.
3) You can combine fire-and-gas logic in the same ESD PLC, provided you provide a minimum of eight hours of UPS backup for the combined system. Also, you need to segregate at the I/O level, as FGS logic will be non fail-safe, and you need line monitoring. In conclusion, you can use same vendor and system hardware type for control and safeguarding for small-scale projects, provided you don't share any hardware or software or any other aspects.
A: I thought that all SIL should be certified by TÜV for programmable safety down to module level or electronic level required by the user. This should include SIL for emergency shutdowns.
Gerald Liu, P.Eng.
A: Consider the purpose of the SIL system: to bring the process to a safe state if something fails. The process control system is one of the things that can fail or be compromised by its Internet connection.
In general, people who design dangerous processes avoid single points of failure.
Regardless of what the vendors and the laws that they have bought say, the safety of your process depends on a separate SIL system that is not connected to the Internet. Use a hardwired contact to tell the PCS that the SIL has stopped the process. Some people use double or triple redundancy for the SIL system. It all depends on your organization's tolerance for risk.
The PCS should be programmed for similar shutdown actions as the SIL. Then you have at least two independent ways to shut down the process.
But if your only goal is to reduce cost, not danger to others, then the combined PCS and SIS looks good—until it fails.
A: You will probably hear from purists who say that the BPCS must always be separated from the ESD system, the SIS. While this is implied by the way the standards are written, practically, it is not necessary. It is possible to build a single system with appropriate levels of redundancy to be configured to accomplish both functions if such a system is approved by an appropriate certification authority to do the SIS work. The fact that it can also accomplish BPC work does not prevent it from correctly responding to the requirements of a SIS. In fact, the BPC function is often supplemented with work to examine process data and trends under software control to locate and compensate for abnormal behavior prior to a shutdown condition. Systems with shutdown prevention make processes both more economical and safer.
A: In general, the ESD and process control systems are separate, and if you are to follow the IEC61508 standard, then that requires separation of the BPCS from your SIS. There is a whole discussion regarding separation of fire-and-gas and process safety systems.
Once you have decided to follow IEC61508/61511, you are then going to follow the safety lifecycle. One of the steps in the lifecycle is to perform an analysis of your plant’s operations to identify those instrumented loops that are safety-related and assign a target SIL (layer of protection analysis [LOPA], etc.) to each of those loops, now referred to as safety instrumented functions (SIF). The SIF with the highest target SIL will determine the required maximum SIL capability for the safety logic solver.
I would recommend that you read IEC 61508 (parts 1-3) or IEC61511 (application of IEC61508 to process safety) if you are not familiar with the requirements.
A: If a SIL study has to be implemented, it will define the type of control system or actions necessary, not the fact that the plant is antiquated.
A fire-and-gas system is independent of the control system, and can be used as a monitoring system without activation, as long as the insurance companies, local standards organizations and/or company/corporation standards allow it. Nowadays most don't.
The biggest fundamental issue is the products being handled. If, for example, you are working in a desalinization plant, the fire-and-gas system may be monitoring, but in a gas plant where high concentrations of H2S maybe present, or in a plant where combustible products maybe present, the need for activation maybe more important than monitoring, since you may not have enough time to react.
The cost difference is very large, yes, but the big question is how much does the replacement of the plant or human lives cost. Even though it may be acceptable to use one single SIL-rated system to do everything, in the specific case of ESD and ESD for fire and gas, it may not be the wisest or best solution. The reason behind this is as follows:
SIL studies require that you analyze all the impacts of the processing and logics, which can be cumbersome. And if you add either ESD or ESD F&G into the mix, you have dissimilar actions in one single unit the programming, and cause-and-effect charts as well as control narratives become almost impossible to coordinate.
The process control during an emergency situation may require specific actions for safe shutdowns, while an ESD or ESD/FGS is looking to cause shutdowns independent of the process activities. So as you can see, you are mixing different things into one single piece of equipment, which could, unless expertly designed, cause conflicts during the shutdown command for emergency situations.
As an example, imagine that you have a three-phase separator that due to over-pressure may require a shutdown. The process controller will isolate just that area or unit and implement the shutdown sequences to let down the pressure.
Now imagine that you have a fire in the same area and the ESD/FGS decides to shut down the area. This may require shutting the whole unit down, which could then still be pressurized, and the system does not allow the process controller to act correctly.
To have both pieces of logic in one system could lead to conflicts, and unless there are some very expert programmers, the system action could cause problems.
So I would suggest that you keep each function separate so that conflicting interactions are held to a minimum.