Safety Instrumented Systems Implementation Guidelines

This article describes general guidelines and minimum requirements for the design of safety instrumented systems. This article shall be read in conjunction with SES-X03-S01.

2. References

Reference is made in this article to the following documents. 
R01-E01 Field Instrumentation Design Criteria
R07-E03 On-off Valve
X01-E01 Control System Design Criteria
X02-G01 Distributed Control System Implementation Guidelines
X03-S01 Safety Instrumented Systems Logic Solver Specification
Safety Health & Environment Management Standard (SHEM)
SHEM-02 Risk Assessment
SHEM-10 EHSS Incident reporting, Classification, Investigation and Analysis

International Electrotechnical Commission (IEC)
61511 Functional safety – Safety instrumented systems for the process industry sector.
The International Society for Automation (ISA)
18.1 Annunciator Sequences and Specifications

3. Definitions

Availability. It represents the statistical probability that the safety instrumented system is operational and can respond properly to an initiating event at some instant in time.
Availability Target (AT) is commonly used as a design criteria for systems. Availability = 1-PFD
Bypass. A method or device that provides an alternate path around an interlock system.
Dangerous Failure (IEC 61511). Failure which has the potential to put the safety instrumented  system in a hazardous or fail to-function state.
Emergency Shutdown Valve (ESV). A valve activated by SIS logic solver.
Failure Actions. The resulting action of the safety instrumented system upon loss of energy, e.g., electrical power, instrument air, or failure of M-out-of-N voting redundant components. There are two possible actions: Fail-Safe (Fail-Action) and Fail-Danger (Fail-No-Action).

Fail-Safe Action. Failure causing the safety instrumented system to take a predetermined action and move the process or equipment to its safe state.
Fail-Danger Action. Failure does not initiate any safety action. Safety instrumented system may not be able to respond to subsequent process hazards.
Fail-Safe. Designed to return to a safe condition in the event of a failure or malfunction.

Final Element (IEC-61511-1). Part of a safety instrumented system which implements the physical action necessary to achieve a safe state. Examples are valves, switch gear, motors including their auxiliary elements such as solenoid valves and actuator if involved in safety function.
Hardware Fault Tolerance (HFT) (IEC-61511-1). It is the ability of a component or subsystem to continue to be able to undertake the required safety instrumented function in the presence of one or more dangerous faults in hardware. A hardware fault tolerance of 1 means that there are, for example, two devices and the architecture is such that the dangerous failure of one of the components or subsystems does not prevent the safety function from occurring.

Hardware Fault Tolerance (HFT) (IEC-61508-2). A hardware fault tolerance of N means that N+1 is the minimum number of faults that could cause a loss of a safety function. 

Operator Interface (IEC-61511-1). Means by which information is communicated between a human operator(s) and SIS.
Logic Solvers. A component or group of components that receives inputs from sensors, performs a predetermined decision-making function, causes final elements to assume a safe position, and provides alarms.

Manual Initiator. A manually actuated pushbutton or switch which causes the safety instrumented system to bring the process or equipment to its safe state.
Proof-Test. The process of periodic testing to reveal undetected faults and ensure that the safety instrumented system is able to respond to an initiating event and bring the process or equipment to its safe state. Different parts of the SIS may require different test intervals, e.g. the logic solver may require a different test interval from the sensors or final elements.  

Reset. A function that controls the action of the safety interlock when a trip function returns to the normal state.
Safe Failure (IEC 61511). Failure which does not have the potential to put the safety instrumented system in a hazardous or fail-to-function state.
Safety Function (IEC-61511-1). Function to be implemented by SIS, other technology safety related system or external risk reduction facilities, which is intended to achieve or maintain a process safe state with respect to a specific hazardous event.

Safety Interlock. A system or function that detects an out-of-limits (abnormal) condition or improper sequence and brings it to a safe condition. A safety interlock operates automatically; no operator action is involved.
Safety Instrumented Function (SIF) (IEC-61511-1). It is the safety function with a specified safety integrity level which is necessary to achieve functional safety and which can be either a safety instrumented protection function or a safety instrumented control function.

Safety Instrumented System (SIS) (IEC-61511-1). Instrumented system used to implement one or more safety instrumented functions. An SIS is composed of any combination of sensors, logic solvers and final elements to implement one or more SIFs.
Sensor (IEC-61511-1). Device or combination of devices, which measure the process condition. Examples are transmitters, transducers, process switches, position switches, etc.

Spurious Trip. A trip of the process by the safety instrumented system for reasons not associated with a problem in the process. This is a detected safe failure also referred to as nuisance or false trip. Allowable spurious trip rates (STR) are design criteria for safety instrumented system redundancy requirements or a measure of the system reliability.  

Test Interval. The test interval represents the maximum time between the proof-test of components of safety interlock, i.e. sensor, logic solver, and final element. Individual components can be tested at different times; one year is a typical test interval.

4. Safety Instrumented Systems Implementation Guidelines General

4.1 Process Hazard and Risk Assessment

4.1.1 Requirement of safety functions shall be derived during Process Hazard Analysis (PHA) study according to SHEM-02.
4.1.2 To determine safety integrity level (SIL) for each safety instrumented function (SIF), either risk matrix or risk graph or layer of protection analysis (LOPA) methods shall be used.  
4.1.3 If the determined SIL with either risk matrix or risk graph crosses SIL 2, then SIL determination shall be done by applying LOPA method. In all such cases, the SIL obtained using LOPA method shall be considered as final to design the SIS.

4.2 SIS

4.2.1 Safety instrumented system shall be designed by following the SIS safety life-cycle model of IEC-61511.
4.2.2 A safety requirement specification (SRS) shall be developed to ensure that all safety criteria envisaged prior to the detailed engineering phase, are completely addressed. 

4.2.3 The SRS shall comply with IEC-61511 requirements.

4.3 Cyber Security

Refer to SES-X01-E01 for description and details of cyber security.

4.4 Power Supply and Distribution

4.4.1 Refer to SES-X01-E01 for description and details.
4.4.2 Power supply units used for logic solvers shall not be shared with any other application.

5. System Sizing and Loading

The following requirements shall be ensured at the end of the project.

5.1 Logic Solver I/O

5.1.1 The spare capacity shall be equally distributed throughout the system.
5.1.2 On logic solver basis, a spare capacity of 10 percent of each I/O type shall be installed and  wired to termination points. Apart from this, 10 percent of the installed I/O modules or minimum 1 slot of each type of card spare slot capacity in I/O rack as well as in terminal block shall be provided.

5.2 Logic Solver CPU Loading

5.2.1 Each CPU loading shall not exceed 80 percent.
5.2.2 Additional spare capacity shall also be made available for future expansions according to  project specific requirement.

5.3 Network Loading

5.3.1 The vendor shall design the system such that each network does not degrade communications speed or any function among the components of the safety instrumented
system under any operating conditions.
5.3.2 The network shall be sized such that it shall be capable to bear additional load of 20 percent spare capacity for connectivity of additional modules, racks, etc in future.  

5.3.3 Network used for communication with DCS shall update all required information or data within
the specified time without losing any information or data.

5.4 Memory Sizing

5.4.1 Vendor shall size all type of memory used in logic solver, for constituting the system to meet performance specifications.
5.4.2 The system shall provide the ability to track memory utilization, allocation and calculate total scan period of the application program.
5.4.3 Memory sizing shall consider 20 percent sparing philosophy for future expansion.

6. Design Considerations

6.1 Basic Design

6.1.1 As a minimum, SIS design shall incorporate the following:
a. Logic solver and safety application program
b. Network
c. Engineering
d. SOE recording
e. Bypass management
f. Safety alarm management
g. System printer
6.1.2 The hardware, software, and network design to implement these applications shall be approved by Company.
6.1.3 Design shall comply with SES-X01-E01 requirements.
6.1.4 The SIS shall be designed to satisfy the criteria mentioned in SRS.
6.1.5 Requirements for operability, maintainability and testability shall be addressed during the design.
6.1.6 The network design shall be in accordance with interfaces requirements of IEC-61511, i.e. operator, maintenance, engineering, and communication interfaces.
6.1.7 The proof-test interval used during SIL calculation shall not be less than the scheduled turnaround period. In case the test interval is less than the scheduled turnaround period, approval shall be required for each SIF. Refer to proof-testing clause of this document.
6.1.8 Spurious trip rate (STR) shall not exceed 0.1/year, i.e. the maximum number of allowed spurious trips or safe failures shall be less than 1 time per 10 years.

6.2 Redundancy

6.2.1 System shall be redundant with fault tolerant configuration. Single point failure anywhere in the system shall not degrade or result into the loss of any safety function.  
6.2.2 All CPUs and I/O modules shall be provided in redundant configuration. However nonredundant triplicated I/O modules, i.e. each module composed of three independent microprocessors, can be used as per application requirements and with Company approval.
6.2.3 For circuits not related to the safety function such as annunciator, status indicators, etc., nonredundant I/O modules can be used with approval.

6.2.4 The internal networks of the logic solvers, and network among the logic solvers shall be redundant and TUV approved.
6.2.5 Redundancy will include, but not limited to, all network interface cards, network elements, cables, etc.
6.2.6 The communication network with DCS shall be redundant.
6.2.7 All power supplies shall be in redundant configuration.
6.2.8 In case of failure or malfunction, system shall automatically transfer to redundant modules to continue all required functions and shall generate an appropriate alarm message. The vendor should advise the standard time of switch-over to transfer all functions between redundant components.
6.2.9 All kinds of software packages required for the redundancy of the whole system shall be supplied with appropriate licenses and hardware.

6.3 Architecture

6.3.1 The conceptual SIS architecture should include all necessary components that constitute the safety instrumented system. It can include logic solvers, networks, workstations for different applications, e.g. SOE, bypass, operator, engineering, storage devices, peripheral devices, and interface with DCS, etc. as per project requirement.  

6.3.2 SIS shall be physically and functionally segregated from any other system.
6.3.3 Any external connections to the SIS shall not compromise the safety function or the safety integrity of the system.
6.3.4 Operating data exchange between the DCS and the SIS shall not compromise the safety  functionalities of the SIS in any circumstances.
6.3.5 The data interface with DCS shall not be used for programming and shall not allow any  access to the SIS application program.
6.3.6 The same control network and proprietary interfaces can be used for SIS and DCS, without affecting the safety functionalities in any circumstances.
6.3.7 SES-X01-E01 shall be referred for compliance with general requirements of SIS.  

6.4 Application Logic

6.4.1 Safety application, which is specific to process requirements, shall be developed in compliance with IEC-61511 and this standard’s requirements.
6.4.2 Depending on project requirements, the SIS can be formed of single or multiple logic solvers and various networks and workstations. Implementation of any safety function among the logic solvers via peer-to-peer communication shall require Company approval and the following requirements:

a. Conformance with IEC 61508 requirements for peer-to-peer communications

b. Compliance to conditions imposed by TUV certification and vendor’s system architecture

6.4.3 The adapted logic structure of SIS shall be defined as per the process requirements and be  selected among the following:
a. 1oo2 redundant
b. 2oo3 redundant
c. 2oo4 redundant

6.4.4 Where allowed by availability target and spurious trip rates, single channel fail-safe 1oo1D configuration can be used with Company approval for non-critical applications where the consequences of spurious trips are acceptable.
6.4.5 For each safety loop, the number of sensors and final elements shall be determined by using the “maximum allowable safety integrity level” tables, i.e. table-2 and table 3, of IEC-61508-2.

The hardware fault tolerance shall be determined with respect to the required SIL and SFF of an element and the number of sensors and final elements shall be accordingly calculated. 

6.4.6 When an element of the safety loop has the programmable feature then it should be treated as “type B” with respect to definitions of IEC-61508-2.
6.4.7 1oo2 and 2oo4 logic shall be designed with 2 independent field instruments connected to different input modules. Different channels of the same input module shall not be used.

6.4.8 2oo3 logic shall be designed with 3 independent field instruments connected to different input modules. Different channels of the same input module shall not be used.
6.4.9 2oo3 voting of analog inputs shall use middle of three selection algorithm in the application program. Use of other algorithms shall require approval.
6.4.10 SIS design shall be fail-safe. Safety related instruments shall normally be energized, and shall go to de-energized state to trip or alarm.
6.4.11 Safety instrumented systems using a fail-danger design, i.e. energize to trip, shall require approval. In this case line monitoring shall be provided.
6.4.12 Depending on adapted architecture, when the system degrades to single-channel or dualchannel operation, the system generated trip feature should be defeated and only an alarm should be used to indicate failure of a channel. However process initiated trips shall not be defeated.
6.4.13 Where there is a requirement to trip one system as a result of another system tripping, this shall be done directly using a “tripped” signal from the first system to the second system.  

6.4.14 The trip of the second system shall not be derived from cascading effects, e.g. waiting for trip  conditions to react. A trip condition shall also not be deduced from secondary or indirect measurements.
6.4.15 Trip logics of machinery systems should be developed in MMS, with the trip signals hardwired to SIS.
6.4.16 The reset of the trip logic shall be as per the design philosophy. After trip the logic should remain in its fail-safe state, until manually reset action, even if trip conditions return to their normal positions.
6.4.17 The manual reset function can be implemented either via soft reset switches configured in DCS or with specific switches installed on the operator console.

6.5 Sensors  

6.5.1 All trip initiating signals shall be hardwired.
6.5.2 Transmitters shall be used for flow, differential pressure, pressure, temperature, and level signals.

6.5.3 If the usage of transmitter is not practical, switches can be used with approval.
6.5.4 Flame sensors shall be self-checking type and shall not require online testing.

6.6 Process Connections

6.6.1 Each SIS sensor shall have a separate tap or well.
6.6.2 Where a single orifice plate is used for flow measurement for both SIS and DCS, a second set of taps on the orifice flange shall be used for the DCS transmitter.

6.7 Final Elements

6.7.1 Finals elements shall be equipped with positions switches or other feedback mechanism to transfer the status data into SIS. This will inform the operator that the final element has responded.
6.7.2 ESV shall not have bypass or block valve. Pneumatic operated ESV shall not be equipped with hand-wheel.
6.7.3 To assure positive shut-off, use of two ESVs in series, and for positive open, use of two ESVs in parallel should be considered.
6.7.4 Control valves shall not be used as a primary ESV Use of control valves as a secondary ESV shall require Company approval.
6.7.5 If control valve is used as an ESV, the bypass valve around the control valve or the block valve in series of the control valve shall be equipped with a limit switch which will generate an alarm to indicate the control valve is bypassed or blocked.
6.7.6 Double block or double block and bleed arrangements should be specified as part of process requirement.
6.7.7 After trip or loss of power source, i.e. electrical, air, or hydraulic, final elements shall remain in their fail-safe state, until manually reset action, even if trip conditions return to their normal positions.
6.7.8 The manual reset function can be implemented either via soft or hardwired reset switches and/or at specific field devices.

6.8 Criteria for Sharing SIS Components

6.8.1 The SIS components like sensors, logic solvers, final elements, manual initiators, and power supplies shall be independent from the DCS or any other system components.  
6.8.2 However, SIS components can be shared for some specific applications and where shared components provide significant cost savings, without affecting the safety.
6.8.3 Where components are shared, the component shall be treated as being part of the SIS and shall be powered from the SIS.
6.8.4 The transfer of any SIS measurement via a signal repeater shall not affect the signal of SIS.
6.8.5 All instances of shared components shall be clearly identified in instrument records and with distinctive tag-names in the control system.

6.9 Typical Cases of Shared SIS Components

6.9.1 If specific equipment requires a dedicated and stand-alone control, which is separate from the DCS, and a safety instrumented system, in this case the control system shall be designed using hardware meeting the same standards as a conventional SIS logic solver. In such circumstances, the control part of the logic, or failures within the control logic or associated inputs, shall not compromise any safety function. The integrated safety and control system shall be engineered and designed according to requirements for safety instrumented system, including change management, access control, etc. Typical examples of this are:

a. Turbo machinery control and safety instrumented systems where machine control, antisurge control  and machinery safety instrumented system is engineered in a specialized integrated package.
b. Some stand-alone packaged equipment where safety instrumented system functionality is required and it is not practical or necessary to provide the process control functionality from the main DCS. For these specific cases of shared components, the basis for the sharing of safety and control functions within the same SIS logic solver shall be provided in project design specifications.

7. Operator Interface

7.1 General

7.1.1 DCS shall be the integrated platform to handle the process data, alarms, trips, and other parameters retrieved from the logic solver.
7.1.2 Operator interface shall conform to IEC-61511 requirements.
7.1.3 Refer to SES-X02-G01 for process graphic, alarm, historization, and report requirements for the data received from the logic solver.

7.2 Hardwired Pushbuttons

7.2.1 Safety instrumented systems shall be provided with at least one hardwired pushbutton for manual trip as per process requirements. This shall be:
a. Hardwired and connected directly to system logic.
b. Locked in the tripped position when activated (push, latch, pull to reset).
c. Located at a continuously manned location such as the operator console or on a backup panel located in the control room.
d. Protected from accidental actuation.

7.3 DCS Initiated Soft Pushbuttons

7.3.1 As an option to the hardwired manual initiator for SIL 1, as mentioned above, DCS initiated manual trip soft pushbuttons can be considered with Company approval.
7.3.2 Soft pushbuttons configured in DCS should not be used as substitutes for console-located hardwired pushbutton for systems assessed as SIL 2 or SIL 3.
7.3.3 Soft pushbuttons shall be configured as 1oo2 de-energize to trip design. Other configurations shall need approval.
7.3.4 From single soft target on the graphic display, two digital outputs (DOs) of different modules shall be driven.
7.3.5 Hardwired connection shall be established between the DOs of DCS and DIs of logic solver.
7.3.6 Soft pushbuttons shall require two-step process, i.e. SELECT and CONFIRM, to avoid  inadvertent operation.
7.3.7 Quick navigation shall be provided to access easily relevant DCS graphic displays.
7.3.8 Any discrepancy in the soft pushbutton function shall be alarmed on the DCS console.

7.4 Workstation Initiated Soft Pushbuttons

7.4.1 As an alternative of soft pushbuttons in DCS, manual trip initiators can also be implemented via redundant workstations that are independent of the DCS.
7.4.2 When redundant workstations are provided for bypass, these workstations can also be used to implement manual trip and other functions related to logic solver applications.

8. Safety Alarms and SOE

8.1 General

8.1.1 SES-X02-G01 requirements shall be followed for alarm management.
8.1.2 Safety alarms and trips shall be annunciated in each DCS operator workstation, SOE workstation, and at the appropriate continuously manned locations.
8.1.3 All safety alarms and trips shall be historized.
8.1.4 SOE workstation should be used for troubleshooting and event observation.
8.1.5 If specified, safety alarms and trips can also be displayed on dedicated LCD or LED alarm annunciators mounted on top of operator consoles or on dedicated workstation installed in the operator console or elsewhere in the control room.

8.2 Implementation

8.2.1 Each safety instrumented system shall have a common trouble alarm.
8.2.2 Safety instrumented systems shall alarm any fault resulting in the failure of one or more channels.
8.2.3 Each safety instrumented system shall include an alarm indicating that the system has activated a trip.
8.2.4 Each safety instrumented system shall have a common, non-defeatable, and non-resettable alarm indicating that a safety function is bypassed.
8.2.5 Safety instrumented systems using a fail-danger design, shall indicate any fault that results in the loss of safety function.
8.2.6 The failure of any environmental conditioning equipment, e.g. fans, HVAC, air filtration, required to maintain the operation of the logic solver, shall be alarmed.
8.2.7 Except manual initiators, each process initiator shall have a pre-alarm. This indicates that the process has reached the point where one or more of the safety instrumented system sensors are about to cause the safety instrumented system to operate unless corrective operator action is taken.
8.2.8 Deviation alarm between DCS and SIS signals shall be configured in DCS using the transmitted logic solver data. Similarly, redundant sensors shall be continuously compared and a deviation alarm shall be generated in logic solver.
8.2.9 When redundant sensors are not used, and a dedicated sensor is not available in DCS, two separate sensors shall be used; one for the pre-alarm and one for the safety instrumented system initiator.

8.3 Sequence of Events (SOE)

8.3.1 Logic solver shall be supplied with a first-out alarm function that provides an indication of which initiator actuated first. The first-out alarms shall be implemented by either one of the following:
a. Within the SOE function.
b. As an annunciator in compliance with ISA 18.1, sequence F3A. This additional alarm system shall be considered with approval.
8.3.2 Each logic solver shall have the capability to transfer all the events to DCS or a dedicated third party alarm system, together with time stamping.
8.3.3 The SOE time stamp resolution shall be project specific requirement. Time stamping shall be within the logic solver scan cycle as a minimum.
8.3.4 All alarms, events and status changes shall be historized. It shall be possible to recall them for report or display purposes. Filtering feature for time base, tag base, etc shall be available. 

8.3.5 The capacity of SOE history shall be minimum 100,000 events.

9. Safety Interlock Bypass

9.1 Design

9.1.1 Safety interlock bypassing shall conform to IEC-61511 requirements and shall be approved. 
9.1.2 Bypass function shall be implemented without affecting the safety function in any circumstances.
9.1.3 Bypass function shall require two-step process, i.e. ENABLE and SELECT. 
9.1.4 The key-locked ENABLE switch shall be:

a. Hardwired and connected directly to logic solver
b. Locked in the ENABLE position when activated (push, latch, pull to reset)
c. Located at a continuously manned location such as the operator console or on a backup panel located in the control room
d. Protected from accidental actuation

9.1.5 Depending on the application, the SELECT function should be either through:

a. Switches hardwired and connected to logic solver, and located similiarly to ENABLE switch
b. Soft pushbuttons configured in dedicated DCS graphics.
c. Soft pushbuttons configured in SIS workstation.

9.1.6 A dedicated lamp on operator console shall be provided to indicate that a bypass function is activated.
9.1.7 The number of sensor bypasses in place shall be project specific.
9.1.8 Start-up bypasses should be considered during application development.

10. Field Devices

10.1 General

10.1.1 As a minimum, sensors shall comply with SES-R01-E01 requirements.
10.1.2 As a minimum, ESVs shall comply with SES-R07-E03 requirements.

11. Proof-Test

11.1 General

11.1.1 SIS design shall allow testing either end-to-end or in parts.
11.1.2 Where the interval between scheduled plant turnaround is greater than the proof-test interval, online testing facilities shall be provided to allow the testing without interrupting the process.
11.1.3 Proof-test requirements shall be developed in compliance with IEC-61511 requirements.

Leave a Comment

error: Content is Protected.