Operational safety within the process industries has always been a priority. As the process sector moved into the computer age, new issues arose as manufacturing plants converted to computer-based control systems (replacing their aging electrical, pneumatic, and electronic controls). Accordingly, the process sector developed a variety of tools to address these problems, but safety performance did not always meet expectations. Today, the standardization of machinery protection systems (MPSs), often in accordance with API 670 – while complying with international safety standards such as IEC 61508 and IEC 61511 – plays a vital role in the safe and secure operation of various industrial facilities. IEC 61508: FUNCTIONAL SAFETY OF ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC SAFETY-RELATED SYSTEMS IEC 61508 is an international standard that covers the entire safety lifecycle of safety systems and is aimed at suppliers of systems, original equipment manufacturers (OEMs) and equipment used in those safety systems. IEC 61508 is the basic/fundamental functional safety standard and applies to all industries. IEC 61511: FUNCTIONAL SAFETY – SAFETY INSTRUMENTED SYSTEMS FOR THE PROCESS INDUSTRY SECTOR IEC 61511 is an international standard that sets out practices in the engineering of systems that ensure the safety of an industrial process using instrumentation. IEC 61511 is a technical standard aimed at end-user applications and is specific to the process industry sector. Note: IEC 61511 uses the same safety lifecycle and safety integrity level concepts as IEC 61508 but described in a more industry-specific language and industry-specific context. API 670: MACHINERY PROTECTION SYSTEMS API 670 is a widely recognised industry standard that describes the minimum requirements for machinery protection systems (MPSs) using measurements such as vibration, position, speed, piston rod drop, phase reference, overspeed, and/or temperature. API 670 includes requirements for sensors and monitoring system hardware and covers specification, procurement, installation, documentation, and testing of such systems. The main objective of IEC 61508/61511 is to help ensure the correct design and use of safety instrumented systems (SISs) with safety integrity levels (SILs) in a systematic way to reduce risk in a process to a tolerable level, by following the overall hardware and software safety lifecycle procedures and by maintaining the associated documentation. API 670 AND IEC61508/61511 API 670 and IEC 61508/61511 complement themselves. Simplistically, the first standardizes the machinery protection system’s implementation requirements while the second defines an important and comprehensive safety lifecycle, from concept to design, operation, and decommissioning or disposal of the safety instrumented system (SIS) and their elements. It is important to note that following a safety lifecycle is the best way to ensure (and prove) compliance with IEC 61508/61511 requirements. HAZARD IDENTIFICATION After the conceptual design of an industrial process has been completed, an assessment consisting of hazard identification and systematic risk analysis should be performed. During this assessment, all hazards and risks to personnel or the environment are analyzed individually. The actual risk that is seen with no MPS is compared with the tolerable risk. If the actual risk is lower than the tolerable risk, then a MPS does not need to be considered as part of a SIS. If the actual risk (with no MPS) exceeds the tolerable risk, then risk reduction methods should be enforced – which typically includes the installation of a MPS functioning as a SIS. Note: The necessary degree of risk reduction is determined by the assessment. RISK ANALYSIS AND SIL SELECTION During the assessment, the risks associated with each identified hazard must be determined, evaluated, and compared with the tolerable risk. Again, this risk analysis is done under the assumption that the safety system (SIS or MPS) under evaluation is not present. In IEC 61508/61511, functional safety classifies the necessary degree of risk reduction into four safety integrity levels: SIL 1, SIL 2, SIL 3, and SIL 4. As shown in the table below, the higher the SIL level, the higher the degree of risk reduction, the lower the probability that a system will fail to perform properly, and therefore, the higher the associated safety level. For example, a SIL 1 safety system provides the least amount of risk reduction. Note: In practice, SIL 4 safety systems are so complex and costly that they are not economically viable. For process industries, if a process is so inherently risky that a SIL 4 system is required to bring it to a safe state, then there is probably a fundamental problem in the design of the process itself that needs to be examined! SAFETY REQUIREMENTS  The next step in the safety lifecycle is to develop a safety requirements specification (SRS). This important document describes all aspects of the required safety system including the test procedure and acceptance criteria for validation testing of the SIS (MPS). The SRS is critical to meet the safety standards of an application, so owners/operators, consultants, and suppliers should all contribute to producing it as per plant requirements. Note: IEC 61511 parts 1 and 2 describe the installation, commissioning, and validation of safety systems in more detail. API 670 suggests that if a safety system requires SIL 2 or higher, any systems or equipment that are not SIL 2 certified by an independent certification body, such as Exida or TÜV, should not be considered (API 670, 5th edition, Appendix L, section L.6.7.2 c). SIL VERIFICATION  For each industrial process step, the SIS should be verified against the SRS. In the end, the complete SIS should be tested in accordance with the test procedure and acceptance criteria included in the SRS. If the safety system cannot meet all of the requirements, the safety lifecycle should restart from the beginning to produce an updated SRS that reflects the required changes. It is important to note that simply using equipment and products with SIL certifications does not automatically ensure SIL compliance of the safety system; it only assures the systematic capability (SC) and hardware fault tolerance (HFT/voting (architecture)) needed to meet the SIL requirements. Therefore, experienced consultants/experts must always perform SIL verification for each safety instrumented function (SIF) that is part of an SIS. This includes the average probability of failure on demand (PFDavg) calculations that are based on application-specific information and safety properties of the elements that form the SIS such as proof test coverage (PTC) and proof test interval (PTI), site safety index, mission time, mean time to repair (MTTR), etc. – and not simply based on supplier recommendations. This is why SIL verification is one of the most critical steps in the safety lifecycle. API 670 (5th edition, Appendix L, section L.7.1.x) also defines some end-user responsibilities to help ensure that safety requirements are met:

• The end-user has overall responsibility for the safety of their plant (application).
• The request for quotation (RFQ) should include details of any specific architectural requirements that are required, such as one-out-of-one (1oo1) or two-out-of-three (2oo3).
• A risk analysis should be performed to determine the necessary degree of risk reduction for each protection loop (SIF), preferably in conjunction with the machinery manufacturer/supplier.
• The request for quotation (RFQ) should include details of acceptable proof tests and intervals for any tests that affect the industrial process (application).
• A safety integrity level/performance level (SIL/PL) evaluation should be performed based on the data provided by each system and equipment supplier to verify that each entire protection loop (SIF) meets all functional safety requirements.

SAFETY SYSTEM OPERATION AND MAINTENANCE  It is also the responsibility of the end-user to ensure that an appropriate safety management team is in place to establish operation and maintenance procedures for any safety systems. Such procedures typically include pre-startup safety reviews, SIS safe startup, periodic maintenance, and in-situ functional testing.