Safety-instrumented function

In ANSI/ISA-84.00.01-2004 (lEC 61511 Mod), 3.2.71, a safety instrumented function is defined as a safety function with a specified safety integrity level which is necessary to achieve functional safety. This standard, 3.2.68, defines a safety function as a function to be implemented by a SIS, other technology safety-related system or external risk reduction facilities, which is intended to achieve or maintain a safe state for the process, with respect to a specific hazardous event.  

Examples of potential safety instrumented functions include the following  

Emphasis should be placed on the last phrase of the SIF definition, specific hazardous event. This phrase helps one clearly identify what equipment is included in the safety instrumented function versus auxiliary equipment not actually needed to provide protection against the hazard. 

Consider the example of a safety instrumented function to protect against vessel rupture due to over-pressure. When high pressure above the trip point is detected, the function will do three things  

It will close a valve to stop material flow into a process unit. 

---

LOPA is a semi-quantitative tool for analyzing and assessing risk. This method includes simplified methods to characterize the consequences and estimate the frequencies. Various layers of protection are added to a process, for example, to lower the frequency of the undesired consequences. The protection layers may include inherently safer concepts the basic process control system safety instrumented functions passive devices, such as dikes or blast walls active devices, such as relief valves and human intervention. This concept of layers of protection is illustrated in Figure 11-16. The combined effects of the protection layers and the consequences are then compared against some risk tolerance criteria. 

The concept of PFD is also used when designing emergency shutdown systems called safety instrumented functions (SIFs). A SIF achieves low PFD figures by... 

General References Guidelines for Hazard Evaluation Procedures, Second Edition with Worked Examples, American Institute of Chemical Engineers, New York, 1992 Layer of Protection Analysis A Simplified Risk Assessment Approach, American Institute of Chemical Engineers, New York, 2001 ISA TR84.00.02, Safety Instrumented Functions (SIF)—Safety Integrity Level (SIL) Evaluation Techniques, Instrumentation, Systems, and Automation Society, N.C., 2002. 

Safety instrumented function (SIF) A safety function allocated to the safety instrumented system with a safety integrity level necessary to achieve the desired risk reduction for an identified process hazard. 

Safety instrumented system (SIS) Any combination of separate and independent devices (sensors, logic solvers, final elements, and support systems) designed and managed to achieve a specified safety integrity level. An SIS may implement one or more safety instrumented functions. 

Safety integrity level (SIF) Discrete level (one out of a possible four SIL categories) used to specify the probability that a safety instrumented function will perform its required function under all operational states within a specified time. 

Use Level of Protection Analysis to evaluate the reliahility needed for safety instrumented functions. (Before startup for all serious consequences identified in the process hazards analysis)... 

Safety instrumented systems have been used for many years to perform safety instrumented functions in the process industries. If instrumentation is to be effectively used for safety instrumented functions, it is essential that this instrumentation achieves certain minimum standards. 

Allocation of the safety requirements to the safety instrumented functions and development of safety requirements Specification... 

Safety instrumented functions are derived from the safety function, have an associated safety integrity ievei (SiL) and are carried out by a specific safety instrumented system (SiS). For exampie, ciose vaive XY123 within 5 s when pressure in vessei ABC456 reaches 100 bar . Note that components of a safety instrumented system may be used by more than one safety instrumented function. 

In order to determine the need for a SIS and its associated SIL, it is important to consider what other protection layers exist (or need to exist) and how much protection they provide. After considering the other protection layers, a determination should then be made on the need for a SIS protection layer. If a SIS protection layer is needed, a determination should then be made on the SIL for the safety instrumented function(s) of this SIS. 

The requirement here is to agree on the safety layers to be used and to allocate performance targets for the safety instrumented functions. In practice, safety functions are in many cases only allocated to safety instrumented systems where there are problems in using inherently safe designs or other technology systems. 

When a safety function is aiiocated to a safety instrumented function, it wiii be necessary to consider whether the appiication is in demand or in continuous mode. The majority of appiications in the process sector operate in demand mode where demands are infrequent, in such cases, Tabie 3 in iEC 61511-1 ANSi/iSA-84.00.01-2004 Part 1 (iEC 61511-1 Mod) is the appropriate measure to use. There are some appiications where demands are frequent (for exampie, greater than one per year) and it is more appropriate to consider the application as continuous mode because the probability of dangerous failure will be primarily determined by the failure rate of the SIS. In such cases. Table 4 in IEC 61511-1 ANSI/ISA-84.00.01-2004 Part 1 (IEC 61511-1 Mod) is the appropriate measure to apply. Continuous mode applications where failure would result in an immediate hazard are rare. Burner or turbine speed control may be continuous mode applications if protection systems are insufficient for all failure modes of the control system. 

The targets for average probability of failure on demand or frequency of dangerous failures per hour apply to the safety instrumented function, not to individual components or subsystems. A component or subsystem (for example, sensor, logic solver, final element) cannot have a SIL assigned to it outside its use in a specific SIF. However, it can have an independent maximum SIL capability claim. 

The outcome of the hazard and risk assessment and allocation process should be a clear description of the functions to be carried out by the safety systems, including potential safety instrumented systems together with safety integrity level requirements (along with mode of operation, continuous or demand) for any safety instrumented function. This forms the basis for the SIS safety requirements specification. The description of the functions should be clear as to what needs to be done to ensure that safety is maintained. 

The development of the SIS safety requirements specification is one of the more important activities of the whole safety lifecycle. It is through this specification that the user is able to define how he wants the Safety Instrumented Functions (SIF) to be designed and integrated into a SIS. 

As described in lEC 61511-1 ANSI/ISA-84.00.01-2004 Parti (lEC 61511-1 Mod), there are a number of design requirements that need to be defined early in a project to ensure the Safety Instrumented Functions provide the desired protection. 

Where a single sensor is used for both a BPCS and SIS function, the requirements of 4 G-61511-1 ANSI/ISA-84.00.01-2004 Part 1 flEC 61511-1 Mod) will normally only be satisfied if the sensor diagnostics can reduce the dangerous failure rate sufficiently and the SIS is capable of placing the process in a safe state within the required time. In practice this is difficult to achieve even for SIL 1 applications. For a SIL 2, SIL 3 or SIL 4 safety instrumented function, separate SIS sensors with identical or diverse redundancy will normally be needed to meet the required safety integrity. 

In practice, this is difficult to achieve even for SIL 1 applications. For a SIL 2, SIL 3 or SIL 4 safety instrumented function, separate SIS valves with identical or diverse redundancy will normally be needed to meet the required safety integrity. 

Data communication which is not part of the SIF (for example, display of the actual value of a SIF sensor if the trip function is realised within the SIF) may be displayed in the BPCS if it can be shown that the safety instrumented functions are not compromised (for example, read-only-access in the BPCS). 

The BPCS operator interface may be used to provide automatic event logging of safety instrumented functions and BPCS alarming functions. 

Printers connected to the SIS should not compromise the safety instrumented function if the printer fails, is turned off, is disconnected, runs out of paper or behaves abnormally. 

To achieve this, the sum of the diagnostic test interval and the reaction time to achieve a safe state should be less than the process safety time . The process safety time is defined as the time period between a failure occurring in the process or the basic process control system (with the potential to give rise to a hazardous event) and the occurrence of the hazardous event if the safety instrumented function is not performed. 

The overall SIS architecture may impose additional functional software requirements to the specified safety instrumented functions. A typical example is the 1oo2 selection logic for redundant sensors as well as a specified safe action on detection of a dangerous failure by sensor self-diagnostics. Examples given in Annex B list those requirements originated from the applied architecture. 

The detailed functional safety requirements specification should include all necessary functions during all modes of operation of the process being protected. Additionally, the periodic testing of all the safety instrumented functions should be provided. This typically requires the definition of maintenance override capabilities so the sensors and final elements can be tested without shutting down the process. The same methodology described in the paragraph above can be used to document these requirements. 

If multiple SIS are used to implement safety instrumented functions, documentation should be provided to explain which functions are to be implemented in each SIS. If multiple SIS are used to implement the same safety instrumented function then the interaction and independence of each SIS should be documented. This documentation should include the expected SIL that should be provided by each SIS. 

Prior to development of the application software, the user provides a process risk and hazard assessment which is used to identify the software safety requirements in terms of the safety instrumented functions and their SIL. Once the decision to implement the safety instrumented functions in software is made, any conflicts, discrepancies and omissions in the safety requirements specification which come to the attention of the software designers should be addressed. One example might be the effect of the order of execution of the safety instrumented functions within the software. Another example would be the response of the application software as it relates to energy outages. 

Where the application software in a SIS is to implement safety instrumented functions of different SILs, they should be clearly separated and labelled. This allows the software of each safety instrumented function to be traceable to the proper sensor and final element redundancy. It also allows the functional and validation testing of the functions to be commensurate with the SIL. The labelling should identify the SIF and the SIL. 

---