2.0. Failure Modes, Effects, and Diagnostic Analysis and System Integration Issues
2.1. Failure Modes, Effects, and Diagnostic Analysis
Failure Modes, Effects and Diagnostic Analysis (FMEDA) is an extension of FMEA (Chapter IV) to identify online diagnostics techniques and the failure modes relevant to SIS design. Exida developed FMEDA in the 1990s. Using the component database that has failure rates, failure modes, and useful life, the FMEDA product generates a product failure rate as well as product failure modes, diagnostic coverage, and even useful life. This is a useful design verification tool and means to provide more precise input to reliability and safety modeling. Also this is extensively used by the user and in projects for safe instruments so that safety life cycle is well maintained by the product. It is necessary to know failure rate as function of failure mode. In other words, FMEDA can be described as a systematic technique for problem identification and related systems diagnostic coverage. Component level FMEDA can provide will determine failure mode of the module. So, module level FMEDA can predict the failure mode of device. FMEDA is used to calculate various failure rates and SFF. So, FMEDA results are depicted in SIL certification documents such as functional safety assessment (FSA) document. FMEDA is a procedure for the detailed determination of error causes and their impact on the system and can be very efficiently used in the early stages of systems development to identify weaknesses. From the FMEDA, failure rates are determined and consequently the SFF is calculated for the device. This is where FMEDA is used with its mathematical models and calculation methods, aimed at estimating the residual error probabilities and residual error rates resulting from malfunctions. For functional safety standard, IEC 61508, probabilistic analysis is necessary and for this huge database on failure data about the product is necessary. Unfortunately, such a database for all products is not always available. OREDA provides a good amount of data. Engineers using a good component database, these numbers can be determined and predicted more accurately than with only manufacturers' field data on previous products [15]. FMEDA is best when reviewed and certified by a third party, although self-declarations can be done by the manufacturer.
2.2. System Integration Issues
The topic is very sensitive. It has been found that there two schools of thought towards system integration. One group is of the opinion that when BPCS is designed as per IEC 61508 with appropriate SIL, combined BPCS and SIS should be acceptable and would consider as a good engineering practice. The other group argues that an absolute separation of functionality between the BPCS and SIS is necessary. Also there shall be independence and diversity in protection layers. The integrity requirements for combined systems are extremely high because there are failure modes that will simultaneously generate a hazard and also disable multiple protection layers. However, some communications may be allowed, as long as no common mode failures can occur. In this connection guidelines from www.61508.org is important and may be referred to.
2.2.1. Center for Chemical Process Safety Recommendations
According to the Center for Chemical Process Safety (CCPS) recommendation SIS separation from the BPCS is required to ensure that safety and environmental aspects of the SIS are consistent with user, manufacturer, local, national, and international standards [16] as:
• Minimize the effects of human error on the SIS from normal BPCS activities.
• Protect safety system software from unintentional changes by isolating the PEs-based SIS from process control induced programming changes in the BPCS.
• Provide access security.
• Facilitate stand-alone testing and maintenance of the SIS and BPCS.
• Ensure security and integrity, allowing the PEs-based SIS to achieve a level of security and integrity equal to or better than a direct-wired SIS.
• Minimize CCFs (both hardware and software).
2.2.2. Requirements of IEC and Other Related Standards
With modern digital technology, it is very easy to integrate BPCS and safety system into one common platform or as an integrated system. Some of the major potential benefits include [17]:
• Seamless integration
• Time synchronization
• Elimination of data mapping duplication
• Common HMI
• Compatible configuration tools
• Minimized set of spare parts
• Single operator and maintenance training requirements
However, in such cases there is every possibility that there may be some compromise with safety system/SIS. These integrated solutions may offer some cost benefit but may be at a cost protection sacrifice against common cause and systematic design and application errors.
• From IEC 61511-1 Clauses 9.5.2 and 11.2.4, one can infer that BPCS shall be designed to be separate and independent without sacrificing safety integrity and avoidance of systematic and common fault. Also various other standards elaborate in the similar line.
• NFPA 85 also calls for “the logic system performing the safety function for burner management shall not be combined with any other logic.”
• API 14C – “Two levels of protection should be independent of and in addition to the control devices used in normal operation.”
• API Recommended Practice 554 (1995) – Process Instrumentation and Control, “the shutdown and control functions should be in separate and independent hardware.”
An integrated control/safety system with same operating system may have systematic design and common cause errors. Another important point here is that, third-party certificate of compliance of the equipment is not really sufficient, especially for end-user who has the ultimate responsibility with the plant operating company's management, not the vendor. International standards call for compliance of SIS logic solvers to IEC 61508. Such third party certification does not cover:
• Application-specific issues as it is certified in isolation.
• Spurious trip vulnerability—specific for application.
• Issues with avoidance of CCFs for SIS and BPCS if common platform is used.
• The systematic errors inherent in using the same platform.
Also, long-term management of an embedded SIS is more about maintaining the legality. MOC will be really complex and complicated. Cyber attack vulnerability is also an important issue. Remote process monitoring, diagnostics, and maintenance and asset management through corporate WAN (web connectivity) have become an efficient tool causing highly increased vulnerability from hackers, worms, etc. for the “integrated” control system and SIS. Therefore, catastrophic failure may not be unlikely. In this connection, Clause 5.0.2 of Chapter IX may be referenced also.
2.2.3. About Existing Systems
There are a large amount of installations which have been in place for so many years much before performance-based standards like IEC 61508/61511 came in to effect. According to ISA-TR84.00.04-2005 Part 1, Guidelines for the Implementation of ANSI/ISA-84.00.01-2004 (IEC 61511 Mod), “for existing SIS designed and constructed in accordance with codes, standards, or practices prior to the issuance of this standard (e.g., ANSI/ISA-84.01-1996), the owner/operator shall determine that the equipment is designed, maintained, inspected, tested, and operating in a safe manner.” The Technical Report focuses on:
• Confirmation: Risk analysis has been done to determine qualitatively or quantitatively the level of risk reduction needed for each SIF in the SIS.
• Confirmation: Assessment of the existing SIF, to determine required risk reduction delivery.
As per ISA-TR84.00.04-2005 Annex A.2 when any of the following conditions is met, detailed review is necessary:
• Modifications to the process unit that impact process risk managed by the SIS.
• Modifications to the control system that impact protection layers used to achieve safe operation.
• When an incident or near miss investigation has identified an SIS deficiency.
• When the review of another process unit designed according to similar practice has identified an SIS deficiency.
2.2.4. Discussions
Having said so many words about separation between BPCS and SIS, in reality it is found that the systems may have to be integrated at some level, so as to put forward some interface point for the plant personnel. Why so? BPCS and SIS using separate diverse hardware and programming for their unique operation of I/O, but need to be integrated at some level to exchange data and information so that plant operating and maintenance personnel can manage the issues easily. Such integration obviously calls for some amount of wiring and data mapping via serial communication or OPC, but much less wiring than separate systems which at times calls for more maintenance efforts also. Again this could also be vulnerable to error. So, a well-suited SIS needs to be developed. Also, in support of system integration, modern safety solution providers try to take advantage of fieldbus systems having “built in” safety to reduce wiring costs, improve diagnostics, and better manage assets. See Fig. VII/2.2.4-1.
These features of safe fieldbus systems (discussed in Chapter IX) attracts manufacturers towards system integrations mainly:
• For the reason that integrated safety systems can improve equipment availability, increased overall equipment efficiency.
• Improved return on investment.
• Harmonization of international safety standards, so that manufacturers and end-users to develop globally acceptable safety solutions.
• For limiting liability exposure and improvement of public image.
For further details on safety fieldbus systems, which would play important role in both BPCS and SIS, Clause 2.0 of Chapter IX may be referenced. From a security point of view, a short discussion about separation and integration of BPCS and SIS has been covered in Chapter XI also. Now it is time to move to some specifics: say of fire and gas system.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.