Process Safety - Market Requirements. V.P.Raman Mott MacDonald Pvt. Ltd.

Size: px

Start display at page:

Download "Process Safety - Market Requirements. V.P.Raman Mott MacDonald Pvt. Ltd."

Laureen Davis
6 years ago
Views:

1 Process Safety - Market Requirements V.P.Raman Mott MacDonald Pvt. Ltd.

3 Objective of Process Safety Protect personnel Protect the environment Protect the plant equipment / production.

4 Multiple Layers of Protection (LOPA) Community Emergency Response Plant Emergency Response Physical Protection (Dykes) Physical Protection (Relief Devices) Safety Instrumented System Alarms, Operator Intervention Basic Process Control Process

5 Control System Incident Occurrence HSE statistics Operation & Maintenance, 15% Changes after Commissioning, 20% Installation & Commissioning, 6% Design & Implementation, 15% Specification Requirements, 44%

6 Hazard or Risk HAZARD Anything that can cause harm (e.g. over temperature of chemical process, overpressure of a pipeline). RISK How great the chance that someone will be harmed by the hazard.

7 Definition of a Hazard: Hazard or Risk A hazard is something (e.g. an object, a property of a substance, a phenomenon or an activity) that can cause adverse effects. For example: Water on a staircase is a hazard, because you could slip on it, fall and hurt yourself; Loud noise is a hazard because it can cause hearing loss; Breathing in asbestos dust is a hazard because it can cause cancer.

8 Definition of a Risk: Hazard or Risk A risk is the likelihood that a hazard will actually cause its adverse effects, together with a measure of the effect. Likelihoods can be expressed as: Probabilities (e.g. one in a thousand ); Frequencies (e.g cases per year ) or; in a qualitative way (e.g. negligible, significant, etc.). The effect can be described in many different ways.

9 Concepts of Risk Risk is a measure of the probability and consequence of a specified hazardous event occurring. The tolerable risk is determined on a societal basis and involves consideration of societal and political factors. Once the tolerable risk has been set, and the required risk reduction determined, the safety integrity requirements for the safety-related systems can be allocated. Safety integrity applies solely to the E/E/PE safetyrelated systems, other technology safety related-systems and external risk reduction facilities

10 Tolerable Risk The purpose of determining the tolerable risk for a specific hazardous event is to state, what is deemed reasonable with respect to both its frequency (or probability) and the severity of the consequences. The degree of risk considered to be tolerable depends upon a number of factors: Degree of control one has over the circumstances; the voluntary or involuntary nature of the risk; the number of persons at risk in any one incident. What is a tolerable level of risk?

11 Is it a Tolerable Risk

12 Risk Reduction Leads to fatality Residual Risk Tolerable Risk Level Intermediate Risk Risk inherent in the process PFD < 0.1 PFD = 0.1 PFD = 0.1 PFD = 0.1 SRS Risk Gap Other Mech Alarms Process 10-5 /yr 10-4 /yr Hazard frequency 10-2 /yr 0.1 /yr

13 SIL Tables Safety integrity Low demand mode of operation level (Average probability of failure to perform its design function on demand) to < to < to < to < 10-1 Safety integrity level High demand or continuous mode of operation (Probability of a dangerous failure per hour) to < 10-8 < 10-4 /yr to < 10-7 < 10-3 /yr to < 10-6 < 10-2 /yr to < 10-5 < 10-1 /yr

14 SIL Table Failure on Demand SIL Safety Availability PFD RRF % ,000 10, % , % PFD = Probability of Failure on Demand. RRF = Risk Reduction Factor (1/PFD)

15 Low / High Demand Control of Airbags Infrequent use; Probability of Failure on Demand; LOW DEMAND. Control of Brakes Continuous use; No brakes: immediate hazard; Failure Rate; HIGH DEMAND. 15

16 Safety Standards - Relationship Safety Instrumented System (SIS) Manufacturers & Suppliers of Devices IEC SIS Designers, Integrators and Users IEC SIS is an independent system composed of sensors, logic solvers & final control elements for the purpose of taking process to a safe state, when predetermined conditions are violated

17 Guidelines IEC & IEC Process Sector SIS Process Sector Hardware Process Sector Software Develop New Hardware Device Use Proven Hardware Device Use Developed Hardware Device Develop Embedded (System) Software Develop Application Software Use Fixed Software Programs Follow IEC Follow IEC Follow IEC Follow IEC Follow IEC Follow IEC 61511

18 Failure Classification Dangerous Failure [IEC : 3.6.7] A failure which has the potential to put the safety-related system in a hazardous or fail-to-function state. Safe Failure [IEC : 3.6.8] A failure which does not have the potential to put the safetyrelated system in a hazardous or fail-to-function state. Detected [IEC : 3.8.8] Hardware failure, detected by Diagnostic Tests, operator intervention (eg: physical inspection and manual tests) or through normal operation. Undetected [IEC : 3.8.9] Hardware failure, undetected by the diagnostic tests, operator intervention (eg: physical inspection and manual tests) or through normal operation. Only revealed by Proof Tests.

19 Type A and B Subsystems Type A Sub Systems Failure Modes are well defined AND failure behaviour is completely determined AND there is dependable failure data Type B Sub Systems Failure Modes are not well defined OR failure behaviour is not completely determined OR there is insufficient failure data 19

20 Hardware Design Constraints The Design Primary technique is monitoring the functionality of system. SIL 1 / 2 watchdog for CPU. SIL 3 - Memory and I/O checks. SIL 4. - Significantly more. Environmental stress All components should be designed to meet the intended environment, which will be encountered in both normal and abnormal conditions. Operation failures There should be protection against on line modification. All SILs, shall provide feedback to the operator and take into account any human factors. 20

21 Software Safety Integrity E/E/PES safety requirements specification Software safety requirements specification Validation Validation testing Validated software E/E/PES architecture Software architecture Integration testing (components, subsystems and programmable electronics) Software system design Integration testing (module) Module design Module testing Output Verification CODING 21

22 Software Development The Requirement Specification Software Specification shall include - capacity, response time, maintenance / operator requirements, self monitoring of software hardware etc Specification should be written in a clear and precise manner and traceable back to the safety specification. Software Design should aid modularity and reduce complexity and also provide clear expression of functionality System software to include - Diagnosing fault detections for hardware, Error detection for communication links & On-line testing of standard software modules. Use trusted and verified software modules (SIL 2 +). 22

23 Modifications Hardware & Software For all modifications and changes there should be: Revision Control. Record of the reason for the design change. Impact analysis. Re-testing of the changed and any other affected modules. 23

24 IEC What is IEC61508? Functional Safety of Electrical / Electronic / Programmable Electronic Safety-Related Systems is product oriented (hardware & software) standard created by IEC; Provides a unified and generic approach for all safety lifecycle activities; Facilitates the development of application sector standards. Important: If any part of the safety function contains an E/E/PE component, then IEC61508 applies to the whole safety function. Important: The main objective of IEC is to protect human life through analysis of functionality of products.

25 IEC Functional safety refers to the ability to avoid the risk of physical injury due to incorrect system operation in response to system inputs. Complex systems incorporate multiple hardware and software components or subsystems which require differing degrees of safety. The IEC standard allows for a range of safety criticality levels for independent assessment of subsystems and components. It is possible to classify subsystems and components into the following categories: Safety Critical: single fault can result in a dangerous failure. Safety Relevant: a single fault in combination with a second fault can result in a dangerous failure. Interference Free: faults can not cause a dangerous failure

26 What is Functional Safety? Part of the overall safety relating to the EUC which depends on the correct functioning of the E/E/PE safety-related systems and external risk reduction facilities. SRS Safety Related Sy s tem EUC Equipment Under Control Proc es s

27 Failure Modes With a safety system, the concern shouldn t so much be with how the system operates, but rather how the system fails. Fail closed means lost production Safety Systems can fail in two ways: Safe failures (nuisance trips) Dangerous failures (fail to function) Fail open means safety hazard

28 Simplified Safety Lifecycle Safety Requirement Specification (SRS) Analysis Phase Realization Phase Operational Phase Hazard & Risk Assessment Allocation of Safety Functions to Protection Layers Design & Development of SIS Operation & Maintenance Safety Requirement Specs. For SIS Installation, Commissioning & Validation Modification

31 Process Safety by Industry Power 10 % Pharm 3% Chemical 21% Other 4% Oil & Gas 44% Refining 18 %

32 Process Safety Market Dynamics SIS market grows at twice the rate of DCS & Control Systems. SIS has strong influence on DCS selection. Safety PLC s are introduced to improve Safety & Availability. Safety PLC involves Redundancy, Voting Logic (2 oo 3), TMR etc. Highly reliable systems are available to meet SIL3 requirements Latest safety systems offer improved integration with DCS.

33 Process Safety Market Dynamics Latest safety system works on Windows based IEC programming tools. Employs high levels of Diagnostics. Offers Enhanced Control Functionality, Flexibility and Scalability. Available with intelligent distributed safety I/O s. Flexibility in using advanced devices, like Foundation Fieldbus, Profibus etc. Integrates with wide variety of field devices like F&G sensors, FF devices etc.

35 Expectations from Vendors Product Management Availability of Trained Staff Marketing & Promotion Application Development Safety Lifecycle Services Customer Support - Assist Clients / Consultants in defining & executing Safety Systems. Interface with Industry Competence Centers Support in getting certified from recognized 3 rd parties. Availability of in-house SIL certified experts.

36 Expectations from Vendors Regional process safety experts to assist in: Training, Seminars, Familiarization etc Project Support Design Reviews. HAZOP & HAZAN studies LOPA, ALARP & Fault Tree Analysis SIL study and SIL level determination Trained Software specialists. Product Identification to meet client needs Define System Architecture (Fit for Purpose) Innovative tools for compliance Long term support for products

IEC61511 Standard Overview

IEC61511 Standard Overview Andre Kneisel Instrumentation Engineer Chevron C.T. Refinery SAFA Symposium 2011 August 5 th, 2011 Presentation Overview Provide some understanding of the key aspects of Functional