209217952 SIL Working Method Report

Document No.:37-1A-KST-F15-00026

Originator: AET

Tag No. : NA

Document Title:

Rev.:01

System No. : 00

Page: 1 of 35

Area Code: X00

SIL WORKING METHOD REPORT

Project name:

Nyhamna Onshore EPCm Project

01

05.04.2013

Issued for IDC/ IDC Company Comments

XG

KA

HAS

Rev.

Issue date

Description

Org’d by

Chk'd by

Disc. Appr.

SHELL networkcode.:

Contract No.: 4610036236

Subcontractor:

Contractor:

www.kvaerner.com

Proj. Appr.

Document title: SIL Working Method Report

Document no.: 37-1A-KST-F15-00026

Rev.: 01

Page: 2 of 35

TABLE OF CONTENTS

1

INTRODUCTION

4

1.1

Abreviations

4

1.2

Revision History

5

1.3

Scope

5

2

THE IEC 61508 AND IEC C 61511 STANDARDS, R RELATIONSHIP BETWEEN THE STANDARDS

8

2.1

General

8

2.2

“Safety lifecycle”

9

3

PROJECT ASSUMPTIONS

12

3.1

Risk and integrity level categories

12

3.2

SIL allocation

12

3.3

Reliability data

12

3.4

Low complexity, proven in use or prior use

13

3.5

Safe failure fraction (SFF)

13

3.6

Systematic failures, PSF and calculation of PFD

14

3.7

Partial stroke testing

15

3.8

Demand mode of operation

15

3.9

Vendor interface

15

3.10

Strategy for handling of deviations

16

4

DOCUMENTATION

17

4.1

Introduction

17

4.2

SIL working method report

17

4.3

SIL identification and allocation report

17

4.4

SIL compliance report

17

4.5

Safety Requirement Specification (SRS)

17

4.6

Safety Analysis Report (SAR)

18


5


MANAGEMENT OF FUNCTIONAL ONAL SAFETY

Rev.: 01

Page: 3 of 35

21

5.1

General requirements

21

5.2

Organisations and resources

21

5.3

Risk evaluation and risk management

22

5.4

Planning and follow up

23

5.5

Implementing and monitoring

23

5.6

Assessment and auditing

23

5.7

Handling of potential non-conformance conformance

23

5.8

Relevant interactions with other project activities

23

OVERALL SAFETY LIFECYCLE YCLE REQUIREMENTS

24

6 6.1

SIS working process – Safety lifecycle model

24

6.2 6.2.1 6.2.2 6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8

Safety lifecycle requirement Scope definition Identification of EUC and SIS to be SIL evaluated Method for establishment of SIL requirements and SIL allocation Additional SIL allocation Operation and maintenance philosophies & SIL strategy Detailed requirement and SIS realisation Avoidance and control of systematic failures Safety validation planning

27 27 27 27 28 28 29 29 30

7

VERIFICATION, VALIDATION TION AND FSA

31

7.1 7.1.1 7.1.1

Verification General SIS verification

31 31 31

7.2

Validation

31

7.3

Functional Safety Assessment (FSA)

32

8

REFERENCES

33

APPENDIX A

34

SRS RESPONSIBILITY MATRIX

34



Rev.: 01

Page: 4 of 35

1 INTRODUCTION To prevent escalation of unstable situations into hazardous situations or accidents, as well as to reduce the consequences of accidents, safety barriers shall be installed on equipment, process segments and as protection between different areas eas on an installation. These barriers can be mechanical barriers (relief valves, fire walls, etc.), or barriers controlled by instrumentedsystems ystems (such as F&G systems, automatic PSD/ ESD isolation valves and automatic fire extinguishing systems). The quality ity of the safety barriers is essential for achieving acceptable risk levels on an installation. Hence Hence, relevant Safety Integrity Level (SIL) analysis activities (incl. management of functional safety) shall be established and performed as an integrated part rt of the design development for the Nyhamna Nyhamnaexpansion installation. For this project, design of all electrical, electronic, programmable electronic (E/E/PE) safety systems shall meet requirements specified in IEC61508 and IEC 61511 standards, ref. /1// &/2/. &/ The implementation of IEC 61508 and IEC 61511 shall be according to the requirements given in the Company documents DEP 32.80.10.10- Gen / 3/ and OLF GL 070 /4/in addition to the IEC standards61508 61508 and 61511.

1.1 ABREVIATIONS CSU

Critical Safety Unavailability

DEP

Design and Engineering Practice (Shell design manual)

E/E/PES

Electrical/Electronic/Programmable Electronic System

EPCm

Engineering Procurement Construction Management

ESD

Emergency Shutdown

EV

Emergency shutdown Valve (valve connected to the ESD system)

EUC

Equipment Under Control

F&G

Fire and Gas

FAT

Factory Acceptance Test

FEED

Front End Engineering Design

FMECA

Failure Modes Effects and Criticality Analysis

FSA

Functional Safety Assessment

FW

Fire Water

HIPPS

High Integrity Pressure Protection System

HVAC

Heating, Ventilation, Air Condition

HWFT

Hardware fault tolerance

HZV

Process shutdown valve (valve connected to the PSD system)

I/O

Input / Output

IEC

International Electrotechnical Commission

IPF

Instrumented Protective Function

ISO

International Standardisation Organisation

MTTR

Mean Time To Repair

NORSOK

Norsksokkelskonkurranseposisjon – (The competive standing of the Norwegian offshore sector)

OLF

The Norwegian Oil Industry Association (OljeindustriensLandsforening) (

OREDA

Offshore Reliability Data

P&ID

Process & Instrumentation Diagram

PDS

Pålitelighet av Datamaskin baserte Sikkerhetssystemer (Reliabilityof computer basedsafety systems)

PFD

average Probability of Failure to perform function on Demand


PRE

Package Responsible Engineer

PSD

Process Shutdown

PSF

Probability of Systematic Failure

QA

Quality Assurance

SAR

Safety Analysis Report

SAS

Safety and Automation System

SAT

System Acceptance Test

SFF

Safe Failure Fraction

SIF

Safety Instrumented Function

SIL

Safety Integrity Level

SIS

Safety Instrumented System

SRS

Safety Requirement Specification


Rev.: 01

Page: 5 of 35

Definitions: SIS – Safety Instrumented System: Instrumented system used to implement one or more Safety Instrumented Functions (SIFs). A SIS is composed of any combination of Initiator(s), Logic Solver(s), and/or Final Element(s). SIF – Safety Instrumented Function: 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. function SIF used in this report is referred to an Instrumented Protective Function (IPF) in n DEP 32.80.10.1032.80.10.10 Gen /3/. Operator/Company: When Operator/Company is referred to in this report, reference is made to Shell. Contractor: When Contractor is referred to in this report, reference is made to Kværner who is the main engineering engin (EPCm) contractor in the Nyhamna hamna onshore EPCm EPCmproject. Reference is made to IEC C 61508 Part 4 (/1/) (/ /) for other relevant definitions and abbreviations.

1.2 REVISION HISTORY Revision

Modifications

01

First issue for IDC// Company Comments for Nyhamna expansion project

1.3 SCOPE The FEED phase The SIL assessment on local Safety Instrumented Function (SIF) for the Nyhamna Expansion Project was carried outby Company during FEED phase. The FEED review consists of SIL classification for the SIFs. In total 99 SIFswere were classified and a NYX NYX-SIL report /5/ was produced by Company during FEED phase phase.



Rev.: 01

Page: 6 of 35

The detail engineering (EPCm)) phase The EPCm Contractor is responsible for the following SIL activities in the detail engineering neering phase: Plan and document how IEC 61508/61511, DEP 32.80.10.10-Gen 32.80.10.10 and OLF GL 070 shall be implemented in the project. (ref. /6/). Further identify/ define, detail out and document the SISs and SIFs where SIL and functional safety requirements are applicable, and allocate SIL requirements for each relevant SIF,ref. SIF ref. /7/. Perform preliminary reliability calculations to detect any SIFs that possibly need to be reconsidered or redesigned, ref. / 7/. Establish and update Safety Requirement Specification (SRS) and dedicated System SRS documents for each relevant system, system ref. /8/. Give input to package specifications and technical requisitions. Establish structure and content requirements for Safety Analysis R Reports (SARs),/9 9/. Update SRS and dedicated System SRS documents for each relevant system. Follow up vendors and collect SARs – commenting/approval. Document compliance with SIL requirements; preferably based on input from vendor SARs where found to have the required/approved quality (to be documented in each System SRS or separate SIL compliance report). Ensure required QA (verification/validation/FSA)as (verification/validation/FSA) described in Chapter 7. Follow up and provide input to commission commissioning and operations. After HAZOP has been performed during detail engineering phase, Company will be responsible for the following SIL activities: TM

Verify and establish updated/additional SIL requirements where required by using the SIFpro software tool. According to the design basis for this project /12/, the SIL facilitator used for FEED shall also be used for detail engineering, The commissioning phase Company (and/or Commissioning Contractor) will be responsible for the following SIL activities: Validate functions (SIFs). Verify that the actual performance of the systems (SISs) and functions (SIFs) are as specified in the SRS documents. Develop test procedures and check that the systems (SISs) and functions (SIFs) can be tested as required. Establish organisation and responsibilities for follow-up follow SIL activities in operation. Establish system and procedures for follow up SIL in operation. operatio The operational phase Company (Operator) will be responsible for the following SIL activities: Test systems (SISs) and functions (SIFs) according to procedures. Monitor the performance of the systems (SISs) and functions (SIFs). All tests, successful sful operations and fails to be logged (e.g. as part of a dedicated SIL application in the Information Management System – IMS).



Rev.: 01

Page: 7 of 35

SIL parameters such as failure rates, Probability of Failure on Demand (PFD) and Safe Failure Fraction (SFF) to be checked regularly. reg Take appropriate actions if systems (SISs) and functions (SIFs) deviate from requirements. Provide SIL feedback to the Contractor(s) and vendors.



Rev.: 01

Page: 8 of 35

2 THE IEC 61508 AND IEC 61511 STANDARDS, RELATIONSHIP BETWEEN THE STANDARD STANDARDS 2.1 GENERAL The international standard IEC 61508 has been widely accepted as the basis for specification, design andoperation of Safety Instrumented Systems (SIS). The standard sets out a risk risk-based based approach fordeciding the Safety Integrity Level (SIL) for systems perform performing ing safety functions. This approach hasproved difficult to handle as part of a development project, as it requires extensive analysis work, andsince requirements to safety functions can normally not be obtained directly from the Quantitative RiskAnalysis (QRA) as it is performed today. Contractor will therefore seek information in the OLF GL 070 with respect to certain topics, as a usefulhelp as this guideline has a widely accepted and recommended approach to the implementation of SIS.The OLF GL 070 is provided ided in order to simplify the application of IEC 61508. Whereas IEC 61508 is ageneric standard common to several industries, the process industry has developed their own sectorspecific standard for application of SIS. This standard, IEC 61511, is also exte extensively nsively referred to in theOLF GL 070. IEC 61508 is relevant primarily for manufacturers and suppliers of SIS devices. IEC 61511 is relevant fordesigners, integrators and users of SIS and is therefore the standard most relevant for the Contractor withdue consideration nsideration to IEC 61508 requirements. The two figuresbelow guidance on when to apply IEC 61508 and IEC 61511 respectively is given.The relationship between IEC 61508 and IEC 61511 is shown in Figure 2.1-1;

PROCESS SECTOR SAFETY INSTRUMENTED SYSTEM STANDARDS

Manufacturers Manufacturers andsuppliers suppliersof of and devices devices IEC61508 61508 IEC

Safety Safety instrumented instrumented systemsdesigners, designers, systems integratorsand and integrators users users IEC61511 61511 IEC

Figure 2.1-1 Relationship between IEC 61511 and IEC 61508 (Figure 2 in IEC 61511, Clause 1) Guidance on when to apply IEC 61511 or IEC 61508 is shown in Figure 2.1-2;



Rev.: 01

Page: 9 of 35

PROCESS SECTOR SAFETY INSTRUMENTED SYSTEM STANDARD

Process sector hardware Developing new hardware devices

Using Proven-inuse hardware devices

Follow IEC 61508

Follow IEC 61511

Process sector software Using hardware developed and accessed according to IEC 61508 Follow IEC 61511

Developing embedded (system) software

Developing application software using full variability languages

Follow IEC 61508-3

Follow IEC 61508-3

Developing application software using limited variability languages or fixed programs Follow IEC 61511

Figure 2.1-2Guidance Guidance on when to apply IEC 61511 or IEC 61508 (Figure 3 in IEC 61511, Clause 1)

2.2 “SAFETY LIFECYCLE” Both IEC 61508 and IEC 61511 are using the “safety lifecycle” as a framework in order to structure requirements related to specification, design, integration, integration, operation, maintenance, modification and decommissioning of a SIS. Each phase has a set of defined inputs and outputs, and towards the end of each phase, a check (or verification) shall be performed to confirm that the required outputs are as planned planned. The safety lifecycle presented inIEC IEC 61511 is shown in Figure 2.2-1. For a summary of requirements related to each lifecycle phase, reference is made to Table 2 in IEC 61511-1. For the purpose of completeness, the lifecycle figure from IEC 61508 is also included, seeFigure seeFigure 2.2-2. For further specification of requirements to each lifecycle phase, reference is made to Table 1 in IEC 61508 61508-1.



Rev.: 01

Page: 10 of 35

Figure 2.2-1Lifecycle Lifecycle from IEC 61511 (Figure 8 from IEC 61511-1), 61511 1), with reference to relevant chapters in OLF GL 070 (in brackets)



Rev.: 01

Figure 2.2-2Lifecycle Lifecycle from IEC 61508 (Figure 2 from IEC 61508-1) 61508

Page: 11 of 35



Rev.: 01

Page: 12 of 35

3 PROJECT ASSUMPTIONS 3.1 RISK AND INTEGRITY LEVEL VEL CATEGORIES According to DEP 32.80.10.10- Gen /3//, the required SIL is established based on: The probability of occurrence of the hazardous situation if the IPF is not installed and The severity of the consequences expressed in terms of: o Personnel health and safety o Environmental impact o Production and equipment loss The SIL decision matrixes in DEP 32.80.10.10 32.80.10.10- Gen, section 4.2.1,, shall be used to determine the associated safety integrity level.

3.2 SIL ALLOCATION A given SIL requirement corresponds sponds to several requirements that have to be fulfilled in order to achieve compliance to IEC 61508/IEC 615111// & / 2/). /). The probability of failure on demand (PFD) is a quantitative requirement for the safety function reliability to function on demand. In order to allocate PFD requirements to suppliers and vendors endors some important assumptions have been made as described below. The given SIL requirement for a SIS loop corresponds to a minimum probability of failure to perform its design function on demand. In order to allocate a target safety integrity parameter parameter as PFD (average Probability of Failure to perform function on Demand), the default mode of operation has been set to low demand mode when specifying requirements to suppliers and vendors (unless specifically identified during the SIL allocation process to o be a high demand function, i.e. requiring use of PFH (Probability of a dangerous Failure per Hour)). For equipment package suppliers, this means that deviations from this assumption must be identified and communicated to the contractor. See assumption in Section Section3.8. A SIL requirement shall be divided between the components in the SIS loop. This is particularly important when there are many equipment suppliers involved in each Safety Instrumented Function (SIF). Dividing the PFD between the components as described below is performed to limit as far as possible the variations in requirements to equipment/component suppliers. Additionally, if the PFD requirement was not split up before they were given to the equipment/component suppliers, one supplier could contribute with a probability of failure on demand which could result in non-compliance non compliance with the PFD requirement defined or the total SIF. The total PFD requirement for the Safety Instrumented Function (SIF) is suggested divided between the components in a SIS loop in the following manner: “Initiator” part (transmitter, pushbutton, detector, etc.) o 35% of the total requirement for the SIF “Logic Solver” part (signal adapters, I/O systems, CPUs, communications, etc.) o 15% of the total requirement for the SIF “Final Element” part (valve, circuit breaker, fire damper, etc.) o 50% of the total requirement for the SIF Where this general distribution of PFD is found not to not suitable (e.g. due to the specific configuration of the SIF), evaluations will be performed on a case to case basis. Note that if one component fails to achieve its PFD requirement this will not necessary result in non non-compliance compliance for the total SIF. This since the other components may perform better than required, such that when all PFD contributions are summed up, the result for the total SIF might still be within the defined overall PFD requirement.

3.3 RELIABILITY DATA



Rev.: 01

Page: 13 of 35

The project shall establish a preliminary reliability data dossier in order to perform reliability calculations during early detail engineering. The data applied in calculations shall prior to available vendor data be based on relevant generic data. Since vendor data will normally not be available at an early stage of engineering, the generic data (preferably from SINTEF’s PDS Data Handbook /11 11/ and/or OREDA data handbook /10/) /) shall be used to perform preliminary reliability calculations. The main purpose of such preliminary reliability calculations will be to identify possible le safety functions that might fail to achieve the required SIL. This will allow potential redesign of systems and/or barriers (if found required) at an early stage of the design development, minimising project cost and schedule impact. In early detail engineering phase preliminary reliminary rreliability eliability calculations shall preferably be based on PDS TM methodology and formulas as recommended by OLF GL 070 / 4/.How to use SIFpro for the reliability calculation has to be agreed between Company and Contractor after all SIFs have been registered in TM SIFpro . Evaluation of vendor data shall be performed prior to use in final SIL compliance calculations. Vendor data shall be used only if found qualified and sufficiently documented by approved SARs in the project. Company and Contractor shall during the final SIL compliance calculations agree upon an approach for utilization of reliability data from the available sources ces such as generic failure data (e.g. PDS reliability data) and/or qualified vendor data and/or relevant experience from operations. The reliability data shall be evaluated and as far as possible be ensured to be qualified for the given application. The reliability data dossier as well as preliminary SIL compliance calculations shall be documented as part of the “SIL Identification and Allocation Report” in the early detail engineering phase, and be updated during the detail engineering phase. The final SIL compliance calculations including an updated Data Dossier shall be established as soon as vendor data (i.e. approved SARs) becomes available. This final SIL compliance documentation for all SIFs related to a specific SIS shall be included as part of the th respective System SRS / 8/.

3.4 LOW COMPLEXITY, PROVEN IN USE OR PRIOR PRI USE A component is of “low complexity” if in accordance with the definition in IEC 61508 / 1// (Part 4, Clause 3.4.3) and if dependable field experience exists (ref. IEC 61508 61508-1, 1, Clause 4.2). According to IEC 61508 61508-2 (Clause 7.4.6 and 7.4.7) the requirement nt related to avoidance and control of systematic failures will not apply to a subsystem considered “proven in use” (given a set of criteria is fulfilled). The term “proven in use” is defined by Clause 7.4.10 in IEC 61508 61508-2. Requirements for claiming “prior ior use” are described in IEC 61511 / 2/ (Part 1; Clause 11.5.3). Alternatively a component can be considered “proven in use” if the following criteria criteria can be documented to be met for the component and its failure data: More than 10 inventories or more than 50 critical failures More than 50000 hours calendar/operational time More than 2 installations covered More than one operator covered. In other words if more than 10 identical components have been supplied to more than 2 installations and more than one operator and been in operation for at least 50000 hours, the component can be considered to be “proven in use”. If a component can be documented umented to be “proven in use” or “prior use” and of a type which can be considered “low complexity”, it will result in reduced requirements for documentation related to systematic failures. It will then be sufficient to document a structured quality assurance assurance (QA) system, preferably ISO 9000 certified.

3.5 SAFE FAILURE FRACTION (SFF) According to IEC61508 / 1// (Part 2, Clause 7.4.4), Safe failure fraction (SFF) requirem requirements ents are depending of type of subsystem. Subsystems are classified into either type A or Type B.



Rev.: 01

Page: 14 of 35

A subsystem can be classified into type A if: The failure modes of all constitu constituents are well defined; and classified the behaviour of the subsystem under fault conditions can be completely determined; and there is sufficient dependable failure data from field experience to show that the claimed rates of failures for detected and undetected dangerous failures are met. A subsystem can be classified in type B if: The failure mode of at least one constituent component is not well defined, or the behaviour of the subsystem under fault conditions cannot be completely determined, or there is insufficient dependable failure data from field experience to support claims for rates of failure for detected and undetected dangerous failures. In general all type A initiators and final elements are assumed to have a SFF of 60% or more, while all type B initiators and final elementss are assumed to have a SFF of 90% or more. For all type A equipment a SFF above 60% is required to avoid hardware fault tolerances (HWFT) of 1 or more (i.e. requiring redundant components). For final elements and initiators such as valves, fire dampers, and analogue transmitters, a SFF of more than 60% is assumed and these are also considered to be type A equipment unless they are “intelligent” (= smart transmitters). Similarly, for all type B equipment a SFF above 90% is required to avoid HWFT of 1 or more more (i.e. requiring redundant components). For type B initiators a SFF of >90% is assumed. Note that fire & gas (F&G) detectors are defined as single components in the SIL assessment,, but will in most fire areas be redundant or in voting configurations which improves the HWFT. This understanding prevents interpretations of the standard resulting in need for redundant valves and transmitters for SIFs that are realized through standard solution. Such SIFs with standard solutions have been proven in use to be satisfactory over the last few decades. This is in line with interpretations in IEC 61511 for SFF and corresponding HWFT and “prior use”. Documentation for “prior use” is required for f equipment where reduction in HWFT is allowed. All vendors supplying equipment/components involved in SIFs with SIL requirements shall document SFF for each critical equipment/components, and a non-compliance non compliance with a SFF requirement shall be handled as a deviation.

3.6 SYSTEMATIC FAILURES, PSF AND CALCULATION OF PFD OLF GL 070 / 4/ describes Probability of Systematic Failure (PSF) to be included in the Critical Safety Unavailability (CSU) calculations. PSF is called PTIF in the PDS Method Handbook / 11// (Typically, CSU = PFD + PSF = PFD + PTIF). However, PSF is very difficult (if not impossible) to quantify, hence PSF is assumed negligible as long as recommendations in the IEC 61508/61511 standards (/1/ (/ / & / 2/) regarding avoidance and control of systematic failures are followed. Furthermore, the IEC 61508/61511 standards require a certain PFD to be achieved given a certain SIL requirement. Applying CSU instead of PFD would give a more stringent criterion to achieve. The IEC 61508/61511 standards fully acknowledge the risks with systematic failures, but believe in a qualitative rather than quantitative approach to the problem. Hence, a SIL function shall be implemented with a certain PFD and corresponding concern/focus towards systematic failures through fulfilment of the specific requirements in the above referred standards. Consequently it is assumed that PFD = CSU. Further it is likely that many systematic failures have been recorded as critical failures in data bases such as OREDA, hence they can already be included in the failure rate figures used when calculating PFD. However, when failure data from the PDS Data Handbook H (ref. / 11/) /) are used as input to SIL calculations, the need for adding PSF should be considered where found to be relevant. Including PSF in the PFD calculations ations might be relevant for cases where the failure data has not been based on failure data collected during operation of existing offshore installations (such as the OREDA database). IEC 61508 require that the unavailability of a safety function includes includes a consideration of the downtime due to repairs. I.e. Mean Time To Repair (MTTR) shall be included in the PFD calculations for a SIF. However, for most safety systems, the MTTR will be small and make an almost negligible contribution to the PFD for a safety ty function. Additionally, when a SIF is out for repair, compensating measures shall be implemented to



Rev.: 01

Page: 15 of 35

ensure that acceptable risk represented by the Equipment Under Control (EUC) is achieved. Hence, it is assumed that MTTR can be disregarded and PFD calcu calculations lations can be based on the dangerous undetected (DU) failures only.

3.7 PARTIAL STROKE TESTING G Partial stroke test of valves may be implemented to detect failures and avoid full shutdown of production during testing. Wherever this is considered relevant, the test system must be designed and documented in accordance with principles given in IEC61508 / 1// for SIFs. In the SIL analyses it is accepted to make use of partial stroke testing, and the actual figure must be qualified in the project based on failure modes not detected by partial stroke ke testing. Partial stroke testing is not considered to fully qualify as functional test with full closure of valves. The contribution to identification of dangerous failures during partial stroke testing has to be documented in e.g. Safety Analysis Reports ts (SARs), test reports or other relevant SIL documentation (or alternatively be defined and agreed with Operator based on e.g. operational experience).

3.8 DEMAND MODE OF OPERAT OPERATION All Safety Instrumented Systems (SISs) are considered to be operating in a low demand mode of operation, unless specifically identified during the SIL allocation process to be operating in a high demand or continuous demand mode for a specific SIF. As a co consequence nsequence of this assumption, most of the reliability requirements related to a certain SIL will generally be based on Table 2 in IEC 61508-1 61508 / 1// while only the SIFs IFs specifically stated to be operating in a high demand or continuously demand mode will be based on Table 3 in IEC 61508-1.

3.9 VENDOR INTERFACE This is descried in details in the “SAR Supplier Guideline” Guideline document /9// to be used for Nyhamna expansion. The main principles for vendor SIL interface within the Nyhamnaexpansion Nyhamna project are illustrated in Figure 3.9-1below. below. It shows the interface required for documentation of compliance with allocated SIL requirements relevant for critical equipment/components within packages. The relevant allocated SIL requirements requirements are directly communicated towards vendors through the package specification as well as with reference to overall SIF and SIL requirements specified in Safety Requirement Specification (SRS) /8/. Each vendor shall document compliance to relevant requirements valid for critical equipment/components within their package supply if being part of a SIF with SIL requirements. This shall be done by producing a Safety afety Analysis Report (SAR) in accordance with relevant format and content requirements as specified in the Nyhamnaexpansion project’s “SAR Supplier Requirements” document.



Contractor

Rev.: 01

Page: 16 of 35

Vendors

SAR- Supplier Requirement

Package specific SIL requirement (included included in Package Specifications/ Specifications PO)

SRS main document

Safety Analysis Reports (SARs) from relevant Vendors

SRS main document + relevant system SRSs (see see Appendix A) A

Updated rev.ss of SRS main document + relevant system SRSs (see see Appendix A) A

Figure 3.9-1Main Main principles for vendor SIL interface within the Nyhamnaexpansion Nyhamnaexpansion project

3.10 STRATEGY FOR HANDLING OF DEVIATIONS For SIFs that fail to meet the PFD, HWFT and/or SFF requirements the following strategies are proposed: Redesign Special analysis to verify compliance towards risk acceptance criteria Special evaluation through review of applied reliability data Evaluate the effect on PFD from introducing partial stroke testing for critical valves (if part of the SIF). Evaluate to change type of equipment Adjustment of test intervals Investigate the impact on overall risk with compliance to a lower SIL requirement through QRA sensitivity Apply for deviation to the specific requirement(s).



Rev.: 01

Page: 17 of 35

4 DOCUMENTATION 4.1 INTRODUCTION The IEC 61508 and IEC 61511 are specifying requirements for documentation of implementation of requirements. A SIL working method report (this ( report),, a compliance report, safety requirement specifications, and safety analysis reports from each equipment package supplier will be produced to document how these requirements have been implemented.

4.2 SIL WORKING METHOD REPORT REPOR The SIL working method report shall hall describe how IEC 61508 and IEC 61511 are planned implemented and executed ted for the Nyhamna onshore EPCm project in the detail engineering phases. This includes document relationships, Requirements for verification, validation, and functional safety assessment, assessment, and management activities. The method for determination of SIL shall also be described within this document.

4.3 SIL IDENTIFICATION AND ALLOCATION A REPORT A SIL identification on and allocation report shall document the systems and safety functions where Safety Integrity Levels (SIL) and functional safety requirements are applicable. The report shall also present how the SIL for each function have been established. A preliminary SIL compliance calculation will be included in the SIL identification and allocation allocation report in the early detail engineering phase. The intention of this calculation is to give early attention to problematic safety barriers, i.e. safety instrumented functions (SIFs) which are unlikely to comply with the given project requirements. The preliminary SIL compliance calculation shall indicate whether the proposed system design is likelyy to achieve the identified SIL and whether a SIS may have to be redesigned. Calculations are performed with generic failure data (no vendor specific failure data are available at this stage).

4.4 SIL COMPLIANCE REPORT TM

A final SIL compliance report (SIL assessment recordings in SIFpro ) will be e produced in late detail engineering phase to document that the SIFs meet the requirements from the methods for determination of TM level of integrity given to the safety instrumented functions. Results will be recorded in SIFpro . Calculations will be performed ormed with vendor specific failure data at this stage.

4.5 SAFETY REQUIREMENT SPECIFICATION (SRS) A Safety Requirements Specification (SRS) will be produced for each safety system. A list of the different SRSs and responsible disciplines are given in Appendix A. The content of a SRS shall be as listed and required in IEC 61511 Clause 10.3, also as shown in Appendix B. The content of each SRS shall be structured in the following way; SRS – Table of content 1. Introduction 1.1. Objective 1.2. Scope 1.3. Regulations/Standards/Specifications 1.4. Abbreviations and Definitions 2. Summary of requirements 3. System description 3.1. Description of EUC 3.2. SIS description 3.2.1. Detailed description of safety instrumented function 3.2.2. Definition of safe state 3.2.3. Status/actions on detection of a fault 3.3. Description of SIS operational mode



Rev.: 01

Page: 18 of 35

3.4. Failure consequences on demand 3.4.1. Safety 3.4.2. Environmental 3.4.3. Commercial 3.5. Demand rates on safety function 4. Performance requirements 4.1. Integrity level 4.2. Required risk reduction 4.3. Response time 4.4. Test interval 4.5. SIF Performance Requirements 4.5.1. Maximum Allowable Spurious Trip Rate 4.5.2. Application Software Requirements 4.5.3. Mean Time to Repair 4.5.4. Survival of the Safety Instrumented Functions 5. Compliance 5.1. Documentation of PFD, SFF and HWFT 5.2. Architectural constraints 5.3. Avoidance and control of systematic failures 5.4. Logging of SIS performance 6. Verifications, Validations and Functional Safety Assessment (FSA) (FS 6.1. Verifications 6.2. Validations 6.3. Functional Safety Assessment (FSA) 7. References 8. Appendix A – Safety Analysis Reports 9. Appendix B – Compliance to requirements 10. Appendix C – Overview of tag no’s / safety function connection 11. Appendix D – FAT/SAT results 12. Appendix E – Commissioning checklist 13. Appendix F – Operations and maintenance checklist The SRS will discuss, calculate, document, and verify the defined safety functions related to the system. These safety functions will each consist of a number of components. A clear definition of the safety function and the battery limits for each package set out by the project will be included. In practice a SRS ‘light’ should be produced in the FEED followed by detailed SRSs which normally would be established before procurement of equipment that is subject to SIL requirements. However, due to long lead time for equipment, inquiries are carried out previously to requirements being set. Hence, SRSs may not be established prior to procurement of equipment that is subject to SIL requirements. Each vendor will produce a SAR to document compliance with SIL requirements given for their equipment in the package specification. The relevant SARs will be referenced in the SRS for the operational phase. The SRS will be a living document throughout the lifetime of the SIS. The SRS shall be updated with vendor specific failure data and compliance with SRS requirements documented.

4.6 SAFETY ANALYSIS REPORT (SAR) The Safety Analysis Report (SAR) shall contain information to document how each supplier of equipment item(s) (hardware/software) has implemented requirements set by the package specification. A component or system is SIL compliant when the SAR documenting compliance for that component or system is approved. roved. A detailed SAR supplier guideline will be made to guide suppliers through the requirements in the package specification and the IEC 61508/61511 standards. With reference to OLF GL 070 (Section 8.10) 8. the minimum content of a SAR should be; System description System topology and Block diagram Operational description of the system



Rev.: 01

Page: 19 of 35

Failure rate of the components Recommended time interval between functional testing MTTR Diagnostic coverage Voting Common cause failures IEC 61508-2 Clause 7.4.9.3 lists information ormation that shall be available for each safety-related safety related subsystem, and hence, documented in the SAR. IEC 61511-1 1 Clause 11.9.2 lists information that shall be taken into account when calculating PFD due to hardware failures, and hence, documented in the SAR. To ensure consistent layout of the SARs the following table of content shall be used. This will facilitate review and verification of the SARs in the detail engineering phase and use of the SARs in the phases following the detail engineering phase; SAR – Table of content I Abbreviations II References III Summary 1. Introduction 2. System Description 3. System Topology and Block Diagram 4. Operational description of the system 5. Assumptions 6. Failure rate of the components 7. Diagnostic Coverage & Safe Failure Fraction 8. Architectural Constraints (HWFT and voting principles) 9. Common Cause failures 10. Behaviour of system/components on detection of a fault 11. Mean Time To Repair 12. Factory testing 13. Operational testing (included test procedures and recommended functional test interval) 14. Avoidance and Control of Systematic Failures 15. Software documentation 16. Results Appendices E.g. Certificates, Test documentation, FMECA, Failure reports This Table of Contents is included in th the SAR supplier requirement report and SAR is listed as a deliverable in the Document List Menu and shall be included in the Supplier Document List when relevant. Note that the SAR should refer to the SRS or other existing documents (test/maintenance proce procedures) where relevant to avoid duplication of information. The SAR should preferably be a relatively short and precise document for easy use in detail engineering, commissioning, and operational phases. It is essential that the information in the SAR is traceable, aceable, unambiguous, and rooted in procedures and processes. This is particularly relevant for the failure data.

SAR – Table of content (Certified equipment)



Rev.: 01

Page: 20 of 35

There are no requirements that components or systems shall be certified to IEC 61508 or IEC 615 61511. A certificate will not relieve a vendor from documenting IEC 61508/ 61511 compliance and supplying a SAR. However, a vendor supplying a certified component/system will only have to document the following parts of the SAR;

I Abbreviations II References III Summary 1. Introduction 2. System Description 3. System Topology and Block Diagram 4. Operational description of the system 5. Assumptions 6. Failure rate of the components* 7. Diagnostic Coverage & Safe Failure Fraction* 8. Architectural constraints nstraints (HWFT and voting principles) 9. Common Cause failures* 10. Behaviour of system/components on detection of a fault 11. Mean Time To Repair* 12. Factory testing 13. Operational testing (included test procedures and recommended functional test interval) interval) 14. NA 15. NA 16. Results Appendices E.g.Certificates * Note that background/supporting documentation for the claimed figures in these chapters is not required for a certified component/system.



Rev.: 01

Page: 21 of 35

5 MANAGEMENT OF FUNCTIONAL FUNCTIO SAFETY The objective of the requirements in this section is to identify the management activities that are necessary to ensure that all functional safety objectives are met. With reference to Clause 6 in IEC 61508 61508-1 and clause 5 in IEC 61511-1, 1, management activities to comply with functional functional safety according to IEC 61508 and IEC 61511 will be based on the following; General requirements Organisation and resources Risk evaluation and risk management Planning and follow up Implementing and monitoring Assessment and auditing (Verification (Verifi / Validation / FSA) It will also be important to ensure correct handling of: Potential contractual challenges Potential non-conformances Relevant interactions with other project activities.

5.1 GENERAL REQUIREMENTS This SIL working method (incl. plan for management and functional safety) established for Nyhamna expansion must be communicated to the project organisation for consistent implementation of IEC 61508/61511 in the project.

5.2 ORGANISATIONS AND RES RESOURCES Persons, departments rtments and organisations or other units which are responsible for carrying out and reviewing each of the safety life-cycle cycle phases shall be identified and be informed of the responsibilities assigned to them. It is also important to ensure the required competence competence within the organisation as well as for each of the personnel involved. In the FEED phase for the Nyhamnaexpansion expansion project, the Company had the main responsibility for coordinating the SIL activities: SIL identification and allocation for the PSD system, s ref. to NYX NYX- SIL report from FEED/5/. In the detail engineering (EPCm)) phase the Safety discipline of Contractortake the main responsibility for coordinating SIL activities and establishing the SIL documentation (i.e. SILWorking Method report, SAR Supplier Requirements, SIL Id. & Allocation Report as well as the main SRS). However, while the Safety discipline will produce the SRS Main Report, the main responsibility for establishing the dedicated System SRS documents for each relevant elevant system will be distributed to the respective system disciplines after Contractor’s PEM milestone stone M2B. Further, the responsibilities for follow follow-up up of the identified SIFs and SIL requirements, including the final SIL compliance documentation, will be distributed to the relevant system disciplines to ensure the required multidisciplinary involvement and ownership. System disciplines (such as Safety, Instrument, Electro, HVAC and Telecom) will be appointed the responsibility for updating and issuing the relevant System SRS documents related to SIS/SIF design covered within their disciplines (see Appendix A showing the SRS responsibility matrix established for the EPCm EPC phase). The Safety Analysis Reports (SARs) are produced by the equipment developers and and suppliers, and shall have structure and contents as described in the “SAR Supplier Requirements” document /9 9/. Suppliers/vendors shall document compliance to IEC 61508/61511 for the relevant part of the Safety Instrumented Function(s) within their scope of work. Each procurement package has a Package Responsible Engineer (PRE). The PREs will be the main responsible for communicating SIL/SAR requirements to the relevant suppliers, and ensure that relevant SIL/SAR requirements are included in the inquiry and purchase purchase order (PO) for each relevant package. The safety discipline and other relevant disciplines shall assist in this process. The PRE will also be the main responsible for ensuring that SAR(s) will be established by supplier(s) with the required format and quality uality (i.e. in line with the “SAR Supplier Requirements” document / 9/). /). PRE must also



Rev.: 01

Page: 22 of 35

follow up and ensure that SAR(s) will be issued by relevant supplier(s) for project review and acceptance in due time (as specified in the supplier document list), i.e. allowing for comments and updating of the SAR if found required prior to achieving project approval. It is also the responsibility of the PRE to make sure that each h SAR is sent to relevant disciplines for review (as a minimum, the Safety discipline shall review the SAR but preferably also the relevant System SRS owner(s)). All SAR(s) must be ensured to have the required quality for approval (i.e. the quality required required for achieving Status Code 1) in due time before final compliance calculations are to be performed within the EPCm EPC project. SAR reports found to have non-compliance non compliance with relevant format and content requirements as specified in the “SAR Supplier Requirements” Requireme document / 9// will not be accepted. It is not sufficient to only deliver a SIL certificate, since all required documentation as specified in the “SAR Supplier Requirements” document shall be included in the he SAR in order to achieve project approval. Figure 5.2-1below gives a coarse overview of multidiscipline involvement and responsibilities related to the main SIL activities and deliverables during EPC EPCm.

Figure 5.2-1Coarse Coarse overview of multidiscipline involvement and responsibilities related to the main SIL activities and deliverables during EPCm m.

5.3 RISK EVALUATION AND RISK MANAGEMENT All systems in the project will be subject to an SIL identification process (e.g. P&ID review, HAZOP, SIL Workshops, etc.) to determine the Safety Instrumented Systems (SISs) and Functions (SIFs) where SIL requirements are applicable. plicable. The SIL identification process will for some SIFs (such as PSD functions) be executed as an integrated part of the process HAZOP, and be followed up as required in separate meetings between the Safety and Instrument discipline as well as other relevant relevant disciplines. The SIL identification process (hazard and risk assessment) shall as a minimum cover the requirements in IEC 61511 61511-1, clause 8,2. SIL requirement and documentation of the process in which they were established shall be documented in the SIL identification and allocation report /7/. /



Rev.: 01

Page: 23 of 35

5.4 PLANNING AND FOLLOW UP U The IEC 61508/61511 implementation process is described in this document and specifically in tthe safety lifecycle model as shown in Section 6.1 .1 of this document.

5.5 IMPLEMENTING AND MONITORING MONI The implementing and monitoring of actions from reviews and audits will be covered in the QA plan for the project.

5.6 ASSESSMENT AND AUDITING AUDITI Reference is made to Chapter6 6 of this document. Requirements related to Functional Safety Assessment are outlined in IEC 61511, Clause 5.2.6.1.

5.7 HANDLING OF POTENTIAL NON-CONFORMANCE Any non-conformance conformance with requirements given in IEC 61508, IEC 61511, DEP 32.80.10.10 32.80.10.10- Gen, or OLF GL 070 shall be formally handled through the project systems for handling of contractual deviations. If a deviation is rejected, the next step will be to redesign the SIF in order to meet the relevant SIL requirements. All applications for deviation where re Company documents or governmental regulations are deviated shall be communicated to Company. Deviation applications from vendors regarding SIL requirements shall be directed to SRS owner for handling and further discussions with Company. Typically, non- conformance will be related to too low SFF with the given hardware fault tolerance (HWFT), a too high PFD or insufficient systems (guidelines, procedures, checklists) for avoidance and control of systematic failures.

5.8 RELEVANT INTERACTIONS WITH OTHER PROJECT ACTIVITIES As far as possible, the Quantitative Risk Analyses (QRA) /13// shall reflect and verify the SIL requirements allocated for Nyhamnaexpansion SIFs. The analyses analyses shall utilise the SIL requirements (PFD figures) in e.g. the event trees so that it the assumed performance of the Safety Instrumented Functions (SIFs) are reflected in the calculated risk level. This will also enable the analyses to act as verification verification versus the given SIL requirements, particularly that they are sufficiently stringent.



Rev.: 01

Page: 24 of 35

6 OVERALL SAFETY LIFECYCLE LIFECY REQUIREMENTS 6.1 SIS WORKING PROCESS – SAFETY LIFECYCLE MODEL A project specific SIS working process for implementation of IEC 61508/61511 in the Nyhamna expansion project has been established. Figure 6.1-1and 6.1 Figure 6.1-2 in the next two pages give a brief overview of handling of SIL requirements in the FEED, Detail Engineering (EPCm), (EPC ), Commissioning and Operation phases.



Notes

Activity Time axis

Requirements given in Contract & Regulations

Scope definition. definition Define responsibilities & organisation. Define acceptance criteria. criteria

1

Identify EUC & SIS’s/SIFs SIS’s to be SIL evaluated

2

Test intervals & acceptance criteria from Client/Operator (or other relevant sources such as OLF GL 070, Ormen Lange projects, etc.) Overall lifecycle requirements integrated in OLF GL 070 1. PSD functions: use SIFpro in FEED. 2. ”Global SIFs” : use ”minimum SIL table” in OLF GL 070, SIL requirement from Ormen Lange project, and calibrated risk method in begining of detailed engineering

Hazard identification identification, HAZOP & risk analysis

Operator ”SIL Working Method Report”

2

3

1 Operator ”SAR – Supplier Requirements”

Establish overall safety requirements

D E T A I L

4 2 5

Allocate SIL to SIFs

5

Perform reliability calculations for SIFs using generic data from data dossier

Operation & maintenance philosofies & SIL operational strategy

6 Operator

E N G I N E E R I N G

Vendors

&

”SIL Id. & Allocation Report”

2 Allocate SIL to SIFs - use SIFpro

9

”SRS” (1st. rev.)

Establish detailed requirements for SIS realisation

3 10 Vendors

9

4

C O N S T R U C.

”SARs” (1st. rev). 5 Overall safety validation planning

7

P R O C. &

SIS realisation

SARs are reviewed & commented by project and updated by vendors if required

Page: 25 of 35

Project phase

Interface

Documentation

SIL allocation on all identified EUC & SIFs will be verified by SIFpro

SIL input to packages (inquiry, BCM, package specification )

Rev.: 01

6 Input to operation 6 & maintenance plan

”SARs” (Final rev.) Interface vs. other project documentation (functional spec’s, FAT and operational procedures, etc.)

Operator

Vendors

9

”SRS’s” (2nd. rev.)

13 5 10

To Operational phase Verification

Validation

FSA

X

Ref. lifecycle in IEC 61508

X

Ref. lifecycle in IEC 61511

Figure 6.1-1 SIS Working process for implementation of SIL in the FEED and detail engineering phases for Nyhamna expansion project


Notes

SRS’s from EPC transferred to MC & commissioning


Activity Time axis

Rev.: 01

Documentation

Page: 26 of 35

Project phase

Interface

From Detail Engineering, Procurement & Construction(EPC) C O M M I S I O N I N G

Handover to Operator / Commisioning team Commisioning and installation planning

Operator / Commisioning team

8 Operation and maintenance plan / procedures

Installation and 12 mechanical complete (MC)

6

6

&

5

Handover to operations

9 Commisioning / testing of SIS & SIFs

12

13

5

Update SRSs if found required after Commisioning / testing

5 10

O P E R A T I O N A L

SRS’s rev. X Data collection and analysis

The activities are performed with many iterations as a continuous process throughout the operational phase

Testing of performance Operation, maintenance and repair Update failure data and test intervals as required

14

6

15

SRS’s rev. X

7

Feedback to contractors/ vendors

10

Handover to decommissioning

Decommisioning

16

S T A R T U P

8

Verification Validation

X

Reference lifecycle in IEC 61508

9

Functional Safety Assessment

X

Reference lifecycle in IEC 61511

10

Figure 6.1-2 SIS Working process for implementation of SIL in the Commissioning, Operation and Decommissioning phases for Nyhamna expansion project

P H A S E

D E C O M M I S I O N I N G



Rev.: 01

Page: 27 of 35

6.2 SAFETY LIFECYCLE REQUIREMENT REQU This Section gives a brief description of the act activities as outlined under activity time axis inFigure Figure 6.1-1, covering the SIS working process for implementation of SIL in the FEED and EPC EPCm phases for this project.

6.2.1 Scope definition This phase is covered by the information in and the work around developing developing this document.

6.2.2 Identification of EUC and SIS to be SIL evaluated In general all Safety Instrumented Functions(SIFs) shall go through a SIL assessment to determine the required SIL. Each EUC and related SIFs will be defined by hazard identification activities (e.g. HAZOP HAZOPDuring HAZOP, the EUC and “final element” for each “initiator” should be identified based on P&IDs, P&IDs HAZID, multidiscipline iscipline SIL workshops, etc.) as well as by review of SIS design for theNyhamna theNyhamna expansion versus relevant requirements given in DEP 32.80.10.1032.80.10.10 Gen./3/, /, relevant standards in Nyhamna onshore engineering design standards/14/ , Safety Critical Elements Identification and Performance Standards Standards/15/, OLF GL 070/4/, NORSOK S-001 /16/,, etc. When relevant, discussions with each system responsible will be performed in order to find SIFs not specified in the guideline. Furthermore, dedicated multidiscipline Workshops should be arranged by the Safety discipline as found required in order to identify and verify SISs/SIFs to be SIL evaluated. Relevant disciplines isciplines to participate will typically be Instrument, Process, HVAC, Electro, Telecom, Mechanical and Safety. Company should also be involved and participate in this identification process. The main purposes of performing a SIL classification process during during the FEED phase and early engineering phase are to: Ensure the level of risk reduction afforded to the SIS is not excessive and the SILs are not too high. Ensure adequate sensors and final elements have been provided in the design to meet PFD requirements of the SIL. Confirm that SIFs are capable of adequately preventing/mitigating the hazardous event. Ensure the impact of spurious trips is minimised and understood. The main purposes of an initial SIL workshop are to: Identify Safety Instrumented Functions (SIFs) that shall have a SIL level and consequently shall be implemented by the SIS logic solvers. Decide the SIL level of each SIF. Give early attention to problematic safety barriers, i.e. safety instrumented functions (SIFs) which are unlikely to comply with the given project requirements.

6.2.3 Method for establishment of SIL requirements and SIL allocation The quality of the safety barriers is essential for acceptable risk levels on an installation. One way to ensure the quality of safety ety barriers is through requirements related to the integrity of the barriers. IEC 61508/ 61511 presents different methods for determination of level of integrity given to instrumented functions performed by the safety barriers. The method to be used in the he Nyhamnaexpansion Nyhamna project for the SIL assessment is described in DEP TM TM 32.80.10.10- Gen /3/. As required by Company, SIFpro software shall be used as workshop tool. SIFpro requires the following input to be recorded in the database: EUC, source of demands, demand frequency, safe e state, and safety/ environmental/ commercial consequences. TM SIFpro is used to determine the safety integrity level (SIL) of a SIF. The same software tools also can be used to verify the design of SIFs and the hardware, software and test intervals they’ll they l require. To meet its TM corporate risk level, the project will use SIFpro to establish SILs, employs a software-based based risk matrix, and calibrates it to meet the Contractor’s corporate tolerability risk criteria. Safety Integrity Level (SIL) defines the required robustness of the SIF in order to bring the risk to a tolerable level. A SIL is assigned to each SIF through a risk assessment process, based on the consequence and likelihood of the hazardous event occurring (after all other risk reduction measures measures are applied). According to



Rev.: 01

Page: 28 of 35

DEP 32.80.10.10- Gen,, The consequences were based on three categories, which are personnel safety impact, environmental impact and commercial/economic impact. In case where SIL(Safety Integrated level), EIL(Environment Integrated tegrated level) and AIL(Asset Integrated level) are different from each other, the most stringent requirement shall be applicable for the SIF as an SIL requirement. Note that not all SIFs will be allocated a SIL; however, this is only relevant in case of low l criticality of the SIF. The likelihood considered possible ssible failures that could cause the hazardous event, as well as independent protection layers and conditions that would help to prevent or mitigate the hazardous event. Prevention and mitigation layer layers were only considered if they were deemed sufficiently reliable to provide at least one order of magnitude risk reduction. With a given SIL requirement, an overall maximum allowable average PFD is given. Since a SIF consists of several elements, the PFD should hould be distributed between these based on the specific configuration and in accordance with the expected unavailability (i.e. based on historical failure data) for the involved components. Typical allocation will be performed as described in Section3.2.

6.2.4 Additional SIL allocation In addition to the method defined above, it has been agreed with Company that SIL allocation can be performed according to the following method in the early detail engineering phase: phase TM Since the SIL review was only performed for the PSD functions by using SIFpro during the project FEED phase, the he SIL review for Global Safety Functions needs to be completed in early stage of detail engineering TM phase. Due to limited SIFpro sources, it has been agreed with Company (ref. /17/) / /) that OLF GL 070/4/ should be applied for SIL assessment on Global Safety System. OLF GL 070 specifies a number of standard SIFs with pre-defined defined minimum SIL requirements. Hence, if the identified SIF is evaluated evaluated to be sufficiently covered by any of the OLF GL 070 standard SIFs, then the predefined SIL requirement in OLF GL 070 should be used. Is should however, prior to such simplified allocation, be evaluated and concluded that he pre-defined minimum SIL requirement irement will be fully applicable for the specific SIF(i.e. not too weak or too stringent). In case a potential “Integrity deviation” is identified for a SIF, the pre-defined pre defined minimum SIL requirements may not be relevant, and should be verified and allocated by use IEC61508/61511 risk based methodology. After the process design is more matured during the detail engineering phase, SIL verification/ reTM assessment should be performed by Shell Global Solutions by using SIFpro for all SIL functions in the project.

6.2.5 Operation and maintenance philosophies& SIL strategy The requirements regarding operation, testing and maintenance in IEC 61508 and IEC 61511 are very detailed. To obtain these details, input from Company and vendors are necessary. The requirements are related to (OLF GL 070, Section 10.2); Routine and abnormal operational activities. Preventive and breakdown maintenance activities. Functional proof testing. The application and control of overrides to SIS. The procedures, measures and techniques to be used for operation and maintenance. Compensating measures to maintain SIS risk reduction when detecting dangerous failures or overrides, inhibits or disabling of the SIF or part of the SIF. Verification of adherence to operation and maintenance procedures. At which time the activities shall take place. Equipment and tools needed for carrying out the activities. The people, departments, and organisations that will be responsible for these activities. The training and competency requirements for staff carrying carrying out the activities relating to operation and maintenance of SIS. Consideration for differentiation of operations and maintenance practices to reflect the various SIL levels.



Rev.: 01

Page: 29 of 35

Specification of which reliability data that should be collected and analysed during during the operational phase. From SIS realisation point of view, these bullet points should be established as early as possible to establish relevant premises as input to the SRS. However, this may not be practicable, hence, the above list should be reviewed, d, and information essential for robust & safe SIS development and realisation must be established in a SIL operational strategy. The contents of the SRS indicate the issues required that is covered by the SIL operational strategy. The following table showss the sections of the SRS where the SIL operational operational strategy has inputs (compared to Table E.1 in OLF GL070)

Reference, IEC 61511, Ch.10.3

Lifecycle phase (ref. refer 6.1 in this report)

5

Assumed sources of demand and demand rate of the safety instrumented function

Pre- execution

6

Requirement of proof test intervals

Pre- execution

12

Requirements for manual shutdown

SRS rev. 1

14

Requirements for resetting the SIS after a shutdown Any specific requirements related to the procedure for starting up and restarting the SIS

SRS rev. 1

19

Description of the modes of operation of the plant and identification of the safety instrumented functions required to operate within each mode

SRS rev. 2

21

Requirements for overrides/ inhibits/ bypasses including how they will be cleared

SRS rev. 1

22

Specification of any action necessary to achieve a safe state in the event of faults being detected by the SIS. Any such action shall be determined taking account of all relevant human factors

SRS rev. 1

23

Minimum worst-case case repair time, which is feasible for the SIS, taking into account the travel time, location, spares holding, service contracts, environmental constraints etc.

SRS rev. 2

26

Identification to normal and abnormal modes for both the plant as whole and individual plant operational procedures (for example, equipment maintenance, sensor calibration and/or repair)). Additional safety instrumented functions may be required to support these modes of operation.

Pre- execution

ID

17

SRS rev. 1

Table 6.2-1 Sections of SRS which require Operations input

6.2.6 Detailed requirement and SIS realisation When the EUCs and the SIFs have been defined and the required Safety Integrity Level (SIL) allocated, more detailed tailed requirements must be established. These shall preferably be specified in the first revision of the Safety Requirement Specification (SRS). The specification shall give sufficient basis for the equipment suppliers to produce their components in compliance compliance with relevant IEC 61508, IEC 61511 and DEP 32.80.10.10- Gen. requirements. Detailed requirements for maximum allowable SIL, PFD, SFF, etc. shall be given and implemented into the inquiries and later in the purchase orders for relevant equipment. All vendors shall document that they are capable of implementing SIL requirements as given in the inquiry. All vendors must evaluate if other SIFs or SISs within their product should be given a SIL requirement according to IEC 61508/61511, and inform Contractorr accordingly.

6.2.7 Avoidance and control of systematic failures The measures that shall be taken to avoid and control systematic failures shall be identified at the start of detailed engineering. The required documentation shall be included in the System SRSs (see listing in



Rev.: 01

Page: 30 of 35

Appendix A) to be established for each relevant relevant system (e.g. by cross referring to relevant SARs for detailed documentation for critical equipment and components).

6.2.8 Safety validation planning After the detail engineering lifecycle phase is complete and the SRS is produced for all defined safety systems, ems, an “SIS safety validation” can take place. This validation shall check the actual design against the requirements in the SRS. The “overall safety validation” will be performed in the commissioning phase to verify that the design meets the SRS in all respects. For further details see Section 7.2.



Rev.: 01

Page: 31 of 35

7 VERIFICATION, VALIDATION AND FSA 7.1 VERIFICATION 7.1.1 General Verification is covered by the general QA system within Contractor as well as by separate verification activities. The verification activities will be performed by activity independent personnel in the project and project independent personnel. Verification activities are generally performed throughout the overall safety lifecycle and specifically after each lifecycle phase to ensure that the requirements requirements for that phase is met. These activities include Discipline Internal Checks (DICs); Inter Discipline Checks (IDCs), and reviews & audits logged in the QA management register (Product Assurance Register – PAR). These QA activities are described in Contract Contractor’s corporate requirements. In general, all items with SIL requirements shall be subject to verification activities. This will include checking of the content and quality of such as the Safety Analysis Reports (SARs) and checking of calculations in the Safety afety Requirement Specifications (SRSs), etc. The verifications will also be performed during activities like: HAZOP HAZID SIL workshops. These verification activities will be documented through: HAZOP report HAZID report Minutes of meeting from workshops/reviews. All activities as well as results related to SIL identification and allocation shall be documented in the SIL Identification and Allocation Report / 7/. /.

7.1.1 SIS verification After the Safety Analysis Reports (SARs) from the subcontractors have been handed over to the project, a verification of the SIS will follow. The reliability diagrams and battery limits established are intended to t serve as a basis for the calculation and verification of the allocated SIL requirements. The SIS verification will cover all relevant elements of the IEC 61508/61511 standards such as requirements related to reliability data (documentation of SFF, DC, e etc.), tc.), architectural constraints and how systematic failures are avoided and controlled. In case the SIS verification results in a non-conformance non conformance with the applied SIL requirements, the project will either implement design changes as applicable or apply fo for deviation to Company.

7.2 VALIDATION There are two main validation activities: 1. The “SIS safety validation” should be performed at the end of the design phase and check the design against the SRS. 2. The “overall safety validation” should be performed during commissioning commissioning in order to demonstrate that the SIS meets the SRS. The validations will be performed by activity independent personnel in the project and project independent personnel. Contractor is responsible for execution of validations in the detail engineering engineering phase. Validation of design is during engineering normally combined and covered by the Functional Safety Assessments (FSA). The commissioning responsible will own the overall safety validation. Reference is made toSection to 9 in OLF GL 070 for definition of scope for overall safety validation. The validation planning related to commissioning



Rev.: 01

Page: 32 of 35

shall generally follow normal “project routine” related to commissioning procedures. Engineering scope is therefore limited to providing additional al requirements to existing procedures in form of e.g. SIL related “Commissioning Check Lists” (included as appendices to each System SRSs) The results from the overall safety validation shall be documented in commissioning to ensure that a change made to SIS by commissioning is included in the relevant System SRSs (see document listing in Appendix A). In case the validation results in a non-conformance conformance with the applied SIL requirements, the project shall either implement changes as required or apply for deviation to Company (ref. Section 3.10 and Section 5.7.

7.3 FUNCTIONAL SAFETY ASSESSMENT (FSA) Functional Safety Assessment (FSA) is in the IEC 61508/61511 standards defined as audits at predefined stages of the safety lifecycle. FSAs shall be performed by project project independent personnel as required by the SIL level (ref. table 4 and 5 in IEC 61508-1). 61508 OLF GL 070, Section ection 6.5 recommends FSAs in the following stages of a project (with ref. to IEC61511): 1. After the hazard and risk assessment has been carried out, the required protection layers have been identified and the SRS has been developed. 2. After the SIS has been designed. 3. After the installation, pre-commissioning commissioning and final validation of the SIS has been completed and operation and maintenance procedure has been developed. 4. After gaining experience from operation and maintenance. 5. After modification and prior to decommissioning of a SIF. Based on these recommendations, the following timing of FSAs has has been found to be relevant for the engineering phases (EPCm)) for Nyhamna expansion project: “FSA Phase I”: To be performed after all SIFs and related SIL requirements have been identified, verified/updated in the detail engineering/EPC engineering/EPCm phase (as well as SRS Main in Document and all System SRSs. “FSA Phase II”: To be performed after all relevant SARs have been received and approved, and all SIL compliance documentation updated in the System SRSs or established in a dedicated final SIL compliance report.



Rev.: 01

Page: 33 of 35

8 REFERENCES 1. IEC 61508: “Functional Functional safety of electrical/ electronic/ programmable electronic safety-related safety related systems”, systems 2010. 2. IEC 61511: “Functional Functional safety: Safety instrumented systems for the process industry sector”, sector International Electro technical Commission, 2003. 3. DEP 32.80.10.10-Gen: “Instrument Instrument Protective Functions Functions”, 2011. 4. OLF GL 070: “Application of IEC 61508 and IEC 61511 in the Norwegian Petroleum Industry” Industry”, The Norwegian Oil Industry Association, rev. 02, October 2004. 5. 37-1A-SHA-I15-00009: “NYX-SIL SIL report”. report Rev.03E. 6. 37-1A-KST-F15-00026: “SIL SIL working method report”. report 7. 37-1A-KST-F15-00027: “SIL SIL Identification and Allocation Report”. Report 8. 37-1A-KST-F15-00028: “Safety Safety Requirement Specification (SRS) (SRS)”. 9. 37-1A-AK-F15-00009: “SAR SAR Supplier Requirement Requirement”. 10. OREDA 2009 Handbook: “Offshore Offshore Reliability Data”, Data SINTEF, 5th Edition. 11. PDS Data Handbook: “Reliability Reliability Data for Safety Instrumented Systems”, ”, SINTEF, 2010 Edition. 12. 37-1A-SHA-X02-00010: “Basic Basic Design and Engineering Package Part VIVI Contractor Service”. Service 13. 37-1A-KST-F15-00020: “Nyhamna Nyhamna Expansion QRA Report”. Report 14. 37-1A-NS-D50-66000: “Nyhamna Nyhamna Projects Onshore Engineering Design Standards”. Standards 15. 37-1A-SHA-F15-00005: “Safety Safety Critical Elements Identification and Performance Standards Standards”. 16. NORSOK S-001: “Technical Technical Safety”, Safety Edition 4, 2008. 17. Company response to TQ-AET-KST KST-KS-0017.



APPENDIX A SRS RESPONSIBILITY MATRIX

Rev.: 01

Page: 34 of 35

1 SRS responsibility matrix The following table gives an overview of the responsible system discipline for each dedicated System SRS document. It also shows the SRS- Main Document owned by the safety discipline. The System SRS documents will be owned and issued by the relevant system disciplines as shown in this table. (R=Responsible, I= Input required) Doc. no.

Title

System

37-1A-KST-F15-00028

SRS – Main document

General for all relevant systems

R

I

I

I

I

I

N.A. for expansion

SRS- System 43 Flare, ventilation and blowdown

43 - Flare, ventilation and blowdown systems

-

-

-

-

-

-

Not yet known

SRS – System 67 Process shutdown

67 - Process shutdown systems

I

R

I

I

Not yet known

SRS – System 69 Distributed control/ monitoring (HIPPS)

69 - Distributed control/ monitoring (HIPPS) systems

I

R

I

Not yet known

SRS – System 70F&G detection

70 – F&G detection systems

R

I

Not yet known

SRS – System 71& 72 Fire water

71& 72 - Fire water systems

R

I

Not yet known

SRS – System 77 HVAC

77 – HVAC systems

I

I

Not yet known

SRS – system 78&79 Emergency shutdown and depressurisation

78&79 – Emergency shutdown and depressurisation systems

I

R

I

I

Not yet known

SRS – system 85 Emergency power

85 – Emergency power systems

I

I

I

R

…

…

…

Nyhamna

Safety

www.kvaerner.com

Instrument

Process

Electrical

I I

HVAC

I

I I

Telecom

Piping

Mechanical

Operations/ Maintenance

I

I

I

-

-

-

I

I

I

I

I

I

I

I

I I

I

R

I I

I

I

I

I I

I

I

209217952 SIL Working Method Report

Recommend Documents