Functional Safety Management in Greenfield Offshore Projects

Transcription

1 Functional Safety Management in Greenfield Offshore Projects Jasjeet Singh, Senior Consultant, DNV GL, Highbank House, Exchange Street, Stockport, SK3 0ET, UK. The offshore oil and gas industry has ventured into a new phase with the advent of ultra-deep water drilling and exploration in harsh environments. The operation is hazardous, costly and controversial due to environmental concerns, especially after the Macando oil spill incident. The industry has responded by assuring the stakeholders that personal and environmental safety will be deeply integrated into the operating culture, and to modernise the way the oil and gas industry operates. One aspect of the modernisation process is the substantial use of computer technology in safety applications. The use of electrical/electronic/programmable electronic (E/E/PE) systems in safety applications is not new, but the way these are designed and managed is changing. International standards such as IEC and IEC (for the process sector) have been available and in use for a number of years, although the offshore industry is still in the process of adapting these. The process is slow and requires a step change in the way the industry has traditionally operated, where reliance on and use of performance standards is still at the core of ensuring safety; this has its drawbacks when used for E/E/PES systems. In addition, many organisations are still on a steep learning curve towards understanding the concept of functional safety and its management lifecycle. The lifecycle starts well before the integrity level determination, and continues throughout the system lifetime. It is critical to introduce functional safety management at an appropriate stage in a project lifecycle. This paper is focused on new build offshore projects and lays out a suggested road map for implementing functional safety management in the project lifecycle. It discusses the various elements of functional safety lifecycle such as safety planning, competency management and verification requirements. The paper also attempts to summarise a must have philosophy documents at various stages in the functional safety lifecycle. The paper also describes the good practice in functional safety management as perceived by independent verification and certification bodies such as DNV GL in selected key areas of the SIS safety lifecycle. Keywords: Functional Safety; IEC 61508; IEC 61511; Offshore oil and gas Introduction Background Although instrumentation has always been an integral part of all aspects of process operations, its employment in safety systems has been overhauled in recent years. It is well recognised that if instrumentation is to be effectively used for safety, it is vital that it is designed and implemented to certain minimum standards. In this respect, International Electrotechnical Commissioning (IEC) introduced a series of standards after elaborate consultation process with a variety of industries that use instrumented safety systems. The standard IEC is now used across multiple industries when designing safety systems that use Electrical (E)/Electronic (E)/ and Programmable Electronic (PE) technology. The process industry sector uses IEC 61511, which is a smaller version of IEC aligned to its requirements, particularly the manner in which safety instrumented systems (SIS) are designed and operated. This international standard has two main concepts which are fundamental to its application: The SIS safety lifecycle; and The concept of safety integrity and safety integrity level (SIL). In order to successfully achieve functional safety, both these aspects must be abided by. Unfortunately, in the experience of DNV GL, the implementation of safety lifecycle beyond SIL determination and SIL verification is lacking. The SIS safety lifecycle forms the central framework which links together the concepts in IEC 61511, and also sets out an approach for safety lifecycle activities. The lifecycle addresses all relevant stages of achieving functional safety, from the initial concept, through to design, implementation, operation and maintenance, and decommissioning of the SIS. If applied correctly, it ensures consistency in managing the SIS and achieving functional safety. This could have both safety and economic benefits. SIL as a concept was partly introduced to ease the reliability aspects of the safety systems whilst remaining rational and logical. Unfortunately, in many cases, it has had the exact opposite effect. SIL has become a buzzword and in many cases completely overshadows other aspects of the lifecycle. The legislative authorities and the industry both have been overly focussed on the numeric part of the SIL rather than the overall functional safety management. It is not uncommon to come across engineering projects where functional safety fails to go beyond SIL/LOPA. Functional Safety in Offshore Oil & Gas Operations This paper is focussed on functional safety management (FSM) in greenfield offshore projects. The reasons for selecting such projects for the paper are manifold and a few are summarised as follows: 1

2 Offshore oil and gas industry operates high hazard installations in increasingly harsh environments. The impact of a major incident in areas such as the Arctic will be catastrophic to the environment. Also, it can seriously jeopardise the future of oil and gas exploration and production in sensitive environments; Greenfield offshore projects are of sufficiently large scale and involve a multi-organisation and multi-discipline effort. As such these are ideal candidates for implementing a comprehensive FSM system; The offshore sector s approach to managing a project and the process safety on the final asset is dissimilar to that typically seen in other industries. A mobile offshore asset may be expected to operate in a host of geographical locations governed by varied regulatory regimes. As such, the initial design phase has to ensure that the asset is developed to reasonably comply with all expected geographical areas; and Many operators in the offshore operations are yet to completely adapt the SIS safety lifecycle. The industry has made remarkable improvement in recent years in managing functional safety but it has significant scope for further improvement. This observation is based on DNV GL s experience as an independent verification body and also as a process safety advisor to the industry. This paper attempts to describe the often overlooked aspects of functional safety lifecycle. A Synopsis of the Current FSM Practices in New Build Offshore Projects Current practices relevant to FSM in the offshore industry are varied. The standards exhibited by operators in closely regulated environments differ significantly from other geographical locations where perhaps the regulatory intervention is minimal. In addition, the practices followed by various organisations such as the operator, the engineering, procurement and construction (EPC) contractor, shipyards, design organisations etc. which are part of a major offshore project can be significantly offset to each other s expectations. This has often been found as a cause for errors and omissions including items relevant to functional safety. Figure 1 portrays the SIS safety lifecycle. The shaded regions show the lifecycle phases which are often not included or are introduced at a later stage, resulting in retrospective preparation of the documents to fit the engineering system. The author has come across a number of major offshore projects in recent years where this was evident. Figure 1: SIS Safety Lifecycle - The Missed Parts Management of Functional Safety & Functional Safety Assessment Safety Lifecycle Structure & Planning 1 2 Hazard and Risk Assessment Allocation of Safety Functions to Protection Layers Verification 3 4 Stage 1 FSA Safety Requirements Specifications SIS Design and Engineering Design and development of other means of risk reduction Stage 2 FSA Stage 3 FSA 5 Installation, Commissioning & Validation 6 Operations & Maintenance Stage 4 FSA Stage 5 FSA 7 Modification Decommissioning 9 SIS Lifecycle Phase Activities in shaded phases are typically missed Most projects rarely go beyond SIL/LOPA during the front end engineering design (FEED) stages. It is still treated as a discrete activity in the list of safety studies that an installation prepares as part of its safety case. This approach plants the 2

3 errors in the initial stages, which result in a number of issues at later stages of the project. These issues often result in costly re-design and a detrimental impact on the project schedule. Missing Links and their Impact The safety lifecycle management process is a dynamic one which must grow and adapt to the project as it matures. However, a basic structure to manage the safety lifecycle and functional safety must be prepared at the start of the project. Lack of such a structure leaves the project functional safety approach without a direction. In the following paragraphs, the author wishes to discuss a few aspects of the lifecycle activities which are critical during the initial stages and are often missed in a project lifecycle. FSM and the Functional Safety Plan The standards IEC and IEC both recommended that a functional safety management system based on the safety lifecycle is implemented to ensure that the project achieves functional safety. Contrary to the popular belief, functional safety lifecycle starts well before any SIL determination activity is carried out. Perhaps, the most critical aspect that is often absent is a project specific functional safety plan. The safety plan is essentially the project specific guidance document on how to implement and utilise the requirements of the FSM system into the specific tasks which will be carried out as part of the project. The impact of the absence of a functional safety plan on a project is profound. Typically, it manifests as an inconsistent approach and confusion in various lifecycle phases. It is often found that lack of a FSM and corresponding functional safety plan results in: Unclear scope of functional safety activities; Unclear roles and responsibilities; Unclear communication protocol, document control and configuration control; Unclear scope for verification of a lifecycle phase output; No set agenda for functional safety assessments (FSAs) and audits; Inconsistent methodologies for SIL determination and verification without taking into consideration the intended operations and maintenance philosophies; Lack of robust documentation which can be used to make a case for achieving functional safety and also provide essential information for operations and maintenance of the SIS. Hence, it is not surprising that a thorough and unbiased FSA often discovers important concerns which require significant corrective actions. In other words, a project completed without a functional safety plan is likely to fail in demonstrating that it has achieved required functional safety. Critical Philosophy Documents Another aspect which is often not found during the analysis phases is philosophy documents and the duty holder s criteria for risk management. During the execution of phase 1 - hazard and risk assessment, and phase 2 - allocation of safety functions to protection layers as per IEC 61511, a number of critical decisions must be made which have a lasting effect on the basis of safety, the engineering design of the SIS and the maintenance workload. For example, during a LOPA study basic information must be available on basic process control system (BPCS), pressure relief devices and an estimate of the distribution of persons on board (POB). Hence, a control philosophy, relief and blowdown philosophy etc. should be available to the assessment team so they can conduct an assessment which reflects the installation. Another document which is often not available or sometimes not referred to is the intended duty holder s risk management system and risk acceptance criteria. Any SIL determination exercise must be performed using tools calibrated to the duty holder s (or equivalent) criteria. The target SILs are dependent upon the calibration. It is also likely that use of generic risk acceptance figures will fail to demonstrate to the stakeholders that the assessment performed and the results generated are an accurate reflection of the intended operations and safety philosophy. Line of Sight It is of critical importance that the operations and maintenance teams on an installation have a clear understanding of the SIFs and what hazards they are intended to protect against. In many cases, the operations and maintenance teams can deduce the obvious hazard but may fail to do so for any secondary hazards or other considerations which were analysed during the hazard and risk assessments. Also, the initiating events which have a potential to result in the hazard under consideration must be clear to the operations team. This enables them to manage and operate the SIS with the knowledge of hazards it is protecting against. During a SIS outage, if the hazards and the initiating events are known, the team can implement the correct alternate safety measures. In other words, one should be able to trace the hazards a SIF is designed to protect against. The path should be unambiguous and unique for each SIF-hazard-initiating event combination. This path has been referred to as the line of sight by the author. This is not an explicit requirement stated in the standard IEC but is considered best practice in FSM. It is an 3

4 immensely powerful method of demonstrating that those hazards which required risk reduction measures have been identified along with their initiating events and such measures have been implemented, including where relevant, use of a SIS. A documented evidence of the line of sight also assists in the various stages of FSAs. Establishing a line of sight also helps in identifying poor hazard analysis or inadequate assessment. It is difficult to incorporate the changes required to deal with the late identification of hazards after the design process has begun, and more difficult (and expensive) to make such changes later in the life of the asset. It is preferable to expend resources eliminating a problem, rather than to expend resources in dealing with its effects. SIS Software Software is a critical part of most SISs but rarely gets the rigorous attention it needs. It is worth noting that software related errors are a significant contributor to overall systematic errors that may be present in a SIS. Hence, software needs as much attention as the hardware it will run on or control. The standard IEC requires a SRS for the software, and recommends a software safety lifecycle. DNV GL has seen several FSAs which fail to consider the software aspect of the SIS. The impact of errors in the software is dependent upon the type of errors. Some errors may be revealed or identified during the verification and validation stages, if performed, whilst some will remain hidden. Communications Failure Lack of communication between various organisations and engineering disciplines often results in late identification of errors or even the propagation of errors into the final system. DNV GL has come across a number of cases where a duty holder organisation was not actively involved during the initial stages of the project. This often results in the engineering companies producing a design for an offshore installation, including its safety systems, which does not conform to the requirements or standards mandated by the duty holder organisation. Another example is minimal involvement of operations and maintenance representatives in the SIS design. An important aspect of SIS architecture selection is the selection of the proof test intervals. A designer can select different combinations of proof test intervals and redundancy to meet the reliability targets. This often results in the designer s selecting proof test intervals which may prove to be impracticable, such as a three months test requirement on a large riser isolation valve. However, if operations and maintenance teams can provide guidance on their desired proof test intervals, say to match maintenance shutdown frequency along with their preference for online testing facilities, partial stroke testing for valves etc.; the design team can tailor the SIS design accordingly. A Roadmap for Functional Safety Management It is not possible or recommended to a have fixed recipe for implementing functional safety. The IEC standards for functional safety are performance based rather than the traditional prescriptive style. A fixed recipe will be considered against the spirit of the performance based style of these standards. However, generic set activities/documents that make up the functional safety lifecycle and its activities can be formulated. In this section, an attempt has been made to list the primary activities, documents etc. that are considered key to the successful implementation of functional safety. The aspects covered are as follows: Functional safety management system; Project functional safety plan; Project competency management; Project configuration control; Functional safety assessments; Installation SIF and non-sif registers; SIS operations and maintenance procedures; Proof testing essentials; and SIS software essentials. Functional Safety Management System It is recommended that all organisations develop a general FSM system which provides the baseline approach to functional safety. The functional safety standards (IEC / / 62061) have a mandatory requirement to have a FSM in place. The SIS lifecycle consists of distinctive phases as shown in figure 1. The phases can also be grouped into distinctive periods as summarised below and in figure 2. Analysis Period: Phase 1 Hazard and Risk Assessment, Phase 2 Allocation of Safety Functions to Protection Layers and Phase 3 Safety Requirement Specifications Realisation Period: Phase 4 Design and Engineering and Phase 5 Installation, Commissioning and Validation 4

5 Operations Period: Phase 6 Operations and Maintenance, Phase 7 Modifications and Phase 8 Decommissioning Management and Planning Period: Phase 9 Verification, Phase 10 Functional Safety Management and Functional Safety Assessments and Phase 11 Safety Lifecycle Structure and Planning The FSM system can be developed such that the strategy for the above periods is written in independently. The overall FSM system is akin to a combination of four separate FSM systems, with one dedicated to each period. One benefit of such a structure during the execution of a project is that the workload can be distributed to different teams, each of which is responsible for different phases of the safety lifecycle. Figure 2: Safety Lifecycle Periods Each period should address the five constituents of a FSM system, namely: Organisation and Resources; Risk Evaluation and Risk Management; Planning; Implementing and Monitoring; and Assessment, Auditing and Revisions. It is noteworthy that various organisations will have their own FSM system, and each FSM system should be focussed on the role played by that organisation in the offshore new build projects. For example, an EPC should generate a FSM system which details their approach to functional safety during the design and construction activities. An operator s FSM should provide the strategy for each phase along with the preferred methodology, details on design requirements and limitations, FSA and auditing etc. Project Functional Safety Plan The functional safety plan is a project specific document which should be prepared by a team representing all organisations involved in the project. The functional safety plan should utilise the FSM systems from project organisations to ensure that the plan is developed in a mutually agreed manner. Projects should create a project specific functional safety plan at the start of the overall functional safety lifecycle. The plan should identify the technical and management activities, and the procedures to be applied for all functional safety related activities. The plan is a live document that should be continually updated and maintained by the designated individual. It is likely that ownership of the plan will transfer between organisations and teams (EPC, end-users, suppliers) as various phases of the overall safety lifecycle are completed. Consequently it is important that all parties agree and review the structure and content of the plan prior to its implementation. As a minimum the functional safety plan should include: Roles and the responsibilities of individuals, departments and organisations; Competencies management and assurance plan of individuals; 5

6 A description of the scope, timing and expected outputs for all relevant safety lifecycle phases; A description of the documentation requirements and configuration control techniques; The verification strategy; The validation strategy; Action tracking and management; Initiation, approval and management of modifications; The timing and scope of functional safety auditing; and The timing and scope of functional safety assessments. For large projects it may not be possible to plan all functional safety related activities during the conceptual stage of the project. Therefore, it is advisable to have hold points for future phases and the plan should be updated to include information as it becomes available. A SIS vendor or integrator may produce its own product specific functional safety plan for the design and engineering phase of the project. This should be reviewed by the engineer responsible for functional safety and included in the overall plan if it can be demonstrated that it provides a comparable level of control and confidence in managing functional safety during design and engineering of the SIS. Project Competency Management The project should produce a competency management plan which acts as an evidence of active competence management and assurance. The aim of competence management is to ensure that it can be demonstrated that the persons involved with or responsible for functional safety lifecycle activities are competent to complete their assigned duties. Each role within the project requires a different set of competencies, and the requirements are also dependent upon the lifecycle phase. The project s competence management plan should define the minimum competence required in each phase of the lifecycle for various roles. This information can be presented in form of a competence matrix. Project Configuration Control The intent of configuration control is to manage and maintain the traceability of all hardware, software and documents related to the SIS and to ensure that all modifications to the SIS are recorded, controlled and traceable throughout the lifecycle. Projects should identify the stage at which formal configuration control of specific deliverables (hardware, software, and documentation) is to be implemented in the FSM plan. In general, configuration control should start when a document or deliverable has been approved. Configuration control procedures should ensure: Unique identification of all SIS devices including the model / version; Unique identification of a logic solver firmware / operating system; Unique identification of logic solver application software and function blocks; Protection against unauthorised manipulation and modification of the SIS; and Prevention of unauthorised items from entering service. Configuration control for non-programmable components or items that incorporate fixed programs may be achieved through revision controlled equipment data sheets that record the following: Device tag number, manufacturer s name, part and serial number; SIL assessment certificate number (if available) Software firmware revision (if required) Fixed program parameter settings (if required) Programmable electronic systems (PES) that utilise a limited variability language (LVL) should have a separate software configuration control document that records the following: PES manufacturer, model, operating system version and edition, compiler version Central processing unit (CPU) model number Communication settings (Bus number, system ID, Baud rate, IP address etc.) Licence numbers (if required) Access passwords 6

7 The software configuration control document should record the revision history of the software application program and may include the revision number, date of revision, the author, code version and the description of version or modification. The FSM plan should define the procedures and practises that ensure the above requirements are fulfilled. This may be done explicitly or by reference to the relevant documents. The plan should also detail the tools and techniques that will support the configuration control activities; this is of specific importance when external organisations are to be responsible for configuration control during the lifecycle. Functional Safety Assessments FSAs are intended to provide an appropriately independent judgment on whether the functional safety provided by the SIS has been achieved and maintained throughout the life of the system. The standard describes five stages at which an FSA may be completed in the lifecycle. Stages 1, 2 and 3 occur in the natural gap between the periods described earlier. An FSA gives the project an opportunity to review the progress, check the deliverables and take a view on the general health of functional safety activities. It is highly recommended that a greenfield offshore project completes stages 1, 2 and 3 FSA before introduction of hydrocarbons. After an appropriate period of experience, a stage 3 FSA should be conducted. The FSM system and functional safety plan should define the requirements for any FSAs, and provide general information for the project personnel on expectations at each FSA. The person(s) completing the FSA should consider the activities carried out and outputs generated during the lifecycle phases within the scope of the FSA being carried out. The appointments of the FSA assessor(s) should be made at an early stage in the project. This will ensure that the appointed person(s) can maintain a suitable level of independence from the project. In most cases a single competent person can be nominated to carry out the FSA. However, for large or complex projects an assessment team comprising of several people with the appropriate competencies may be required. Once appointed the FSA the assessor(s) should prepare an FSA plan detailing: The scope of each FSA; The required participants and their roles and responsibilities; The FSA deliverables; A broad itinerary including a guide as to when specific participants are required; and A list of pre-requisite documentation. The FSAs should be performed in two stages: a desktop review of the deliverables associated with relevant lifecycle phases, followed by a combination of interviews and document reviews with the project personnel. Installation SIF and non-sif Registers A typical SIF will have the following associated with it: Hazard assessment SIL determination SRS and software SRS SIL verification Proof test method statement (PTMS) Certificates, manuals and reports Since the above information is produced at different stages in the project lifecycle and by different organisations, it can be challenging to find the SIF specific information when the asset is in operation. One method of ensuring that the information is readily available and easy to find is by developing SIF and Non-SIF registers. These registers are merely a structured collection of various documents which allows users such as operations and maintenance teams to easily identify the information pertaining to a SIF or non-sif protection layer. These registers are also beneficial in establishing the line of sight as discussed earlier in this paper. SIS Operations and Maintenance Procedure Ideally, the operation and maintenance procedures should be defined at the SIS design and engineering phases and should consider the intended method for operating, proof testing and maintaining the SIS. This includes consultation with the operations and maintenance representatives to note the desired proof test intervals. Also, methods of trip and fault annunciation and diagnosis should be considered at the design stage to minimise the mean time to repair and to facilitate the collection of demand and failure data. In order to maintain the integrity of the SIS in the operational and maintenance phase of the lifecycle, several activities are often required. The functional safety responsible team should ensure that: The requirements for performing proof testing and inspection as per the SRS are identified and all planned activities are populated in the maintenance management system; 7

8 The instructions for completing and documenting a full proof test after repairs or like for like replacement is available; The process for tracking SIS component failures to facilitate the analysis of failures is established; The process for tracking demand rates to facilitate analysis is established; Procedures for the management of obsolete equipment are available; Requirements for operational response to abnormal situations, such as response to trips and requirements to respond SIS component failures is available; Processes for investigating SIS incidents including failure on demands, testing failures and spurious trips is established; Security procedures to prevent uncontrolled or accidental changes are in place; etc. It is suggested that the project develops the following procedures prior to introduction of the hydrocarbons. These can be refined and updated by the operations and maintenance teams. SIS operations and maintenance manual; SIS by-pass and override procedure; Proof test method statements; Proof test deferral procedures; SIS visual inspection procedures; and SIS spares holding procedures. The reasons for suggesting that the above procedures and corresponding philosophies are prepared during the design and engineering phases are as follows: The information required to prepare the various procedures is readily available with the design team. It is extremely challenging to prepare these procedures after the design team has disbanded; and Operations and maintenance teams can review the documents and provide their feedback, suggestions etc. to the design team to ensure that any reasonable and/or essential changes can be made before the installation enters active production. Proof Testing Essentials The SIFs operating in demand mode of operation require periodic testing to evaluate if the SIF is performing as per the SRS and meeting its designed reliability targets. The testing frequency is defined in the SRS and confirmed as part of the achieved SIL calculation prepared in the SIS design and engineering phase of the lifecycle. The PTMS should provide a clear, unambiguous, step-by-step methodology for testing the functionality of the SIF in line with the requirements of the SRS. It is suggested that a PTMS includes the following to improve the robustness and validity of proof tests: Description of the tests and inspections performed; Dates of the tests and inspections; Name of the person(s) who performed the test and inspection; Unique identifier of the SIF or equipment tested (for example, loop number, tag number, equipment number, and/or SIF number); Visual inspection of SIF elements; Validation of trip initiating values (set-points); Validation of correct logic action; Validation of the final element activation; Validation that the SIF speed of response is less than the process safety time; Validation of correct alarm and indication; and Test equipment used, serial number and calibration details. It is critical that the PTMS covers the complete functionality of the SIF from the initiator to the final element. The test method should address the foreseeable failure mechanisms (e.g. sensor failure and diagnostics). It is noteworthy that proof 8

9 tests are required to identify unrevealed dangerous failures and consequently proof tests should be carried out on equipment in an as-found basis; any planned maintenance activity should be completed after the proof test. Ideally a single test will cover the full operation of a SIF from the initiator to final element. However, in some cases it is necessary to separate elements of the test to support operational requirements. In such circumstances, the testing of individual components/sections of the SIF must overlap to ensure full coverage is achieved and the PTMS should fully describe how full coverage is delivered. PTMS can be prepared in line with the following classifications: OLP (On-Line Partial Test): Testing of SIF sub-systems whilst the asset is in operation and with no loss of production (e.g. partial stroke test, initiator test with override). OLF(On-Line Full Test): Testing of complete SIF whilst the asset is in operation and with no loss of production. SDP (Shutdown Partial Test): Testing of SIF sub-systems whilst the asset is in a shutdown condition. SDF (Shutdown Full Test): Testing of complete SIF whilst the asset is in a shutdown condition. If a defect is revealed or discovered during a proof test, it should be noted on the associated test record and formally recorded in the maintenance management system as a critical defect. All defects should be reported even if the defect is repaired immediately; such defects support the generation of reliability data that underpin the SIS performance metrics. It is essential that suitably rated and calibrated test equipment (sources and meters) are used. The serial or reference number and the calibration date of testing equipment should be recorded on the proof test paperwork as evidence and for records. SIS Software Essentials The following documents are considered to be essential in demonstrating confidence in application software to be used in the SIS: Software SRS; Software safety validation plan; Software integration and test plan; and Software modification procedure. The SIS vendor should be requested to produce the software SRS using information derived from the SRS, the user requirement specification (URS) and the cause and effect diagrams. The software SRS should state how the requirements of the SIS will be transferred into the configured software. It may include the following: A description of the language type (function blocks diagrams (FBD), ladder etc.); A description of the programming tool including any certifications and features; Structure of application software; Naming conventions, for example hard and serial input/output (I/O) points, internal flags etc.); Use of modules, trusted library, standard library and user created function blocks; Support tools, including configuration management, code comparators, simulation and testing; Actions taken on detection of faults; Details of human machine interface (HMI) or interface to the BPCS; Implementation of maintenance override and start-up system; The use of explanatory notes; produced documentation; and Details of integration testing. The software application program produced should be verifiable, testable, modifiable and traceable back to the requirements detailed in the SRS and software SRS. The software application program design should include the following general requirements: All data types used are defined and appropriate action occurs when data is out of range or bad; The setting of trip alarm levels for analogue inputs, setting of timers and selection of normally open or normally closed configuration for digital I/O should be hard-coded in the software application program and should not be adjustable via the HMI or BPCS interface; The values for trip settings and timers should be set through the use of constants. If a variable or calculated setting is required the rationale for this should be detailed in the software SRS and approved by the relevant personnel; 9

10 Where calculations are performed, the logic should be defensively programmed so that a calculation error or other error that might cause the function to go to an indeterminate state (for example, division by zero) does not occur; Where systems utilises the FBD language for programming, the application programs should be split into welldefined modules and use trusted, certified or proven in use function blocks. The program should provide sufficient functionality for safe modification and the software package should be capable of comparing two application software versions and indicating where the modifications have taken place; The logic associated with non-safety functions should be segregated from the logic associated with safety functions; and The program should be sufficiently structured to facilitate the proof test requirements of the SIF. The SIS vendor should create a verification test plan for the software application program which should be issued to the project for approval prior to the production of application program. The SIS end user must carry out the software risk assessment, preferably in conjunction with the supplier of the software. The end user should study the information provided by the supplier to confirm that the software risk assessment is based on the correct understanding of the measurement system. The software safety lifecycle is aimed at ensuring that the software used in SIS is treated as part of the system rather than a black box. It also ensures that the software is subjected to required assessments and control during commissioning, and later stages of the SIS s life. Software should be subjected to verification by a project independent competent engineer. In the early phases of the software safety lifecycle verification is static, for example inspection, review, formal proof. When code is produced, dynamic testing becomes possible. It is the combination of both types of information that is required for verification. For example code verification of a software module by static means includes such techniques as software inspections, walk-throughs, static analysis, and formal proof. Code verification by dynamic means includes functional testing, white-box testing, and statistical testing. It is the combination of both types of evidence that provides assurance that each software module satisfies its associated specification. The verification results should include the following as a minimum: Confirmation that all software related restrictions of use detailed in the product safety manual have been applied; Confirmation that the requirements of the software SRS have been fulfilled; Confirmation that the software design follows the vendor s internal design standards; Confirmation that the safety communication links have been correctly designed and configured; and Confirmation that communication interfaces to external systems (for example, the BPCS) cannot affect the integrity of the safety functions. Concerns with use of Performance Standards for SIS The most common method of managing safety critical elements (SCEs) on an offshore installation is by use of performance standards. For those not familiar with these, performance standards state the various requirements that must be met by an SCE. These requirements include basic design criteria, reliability targets and inspection criteria. Independent bodies such as DNV GL use written scheme of examination (WSE) amongst other documents to verify if the performance standard is being met on an offshore installation. However, for SIS and its constituent parts, use of performance standards can be misleading. This is primarily because of the following reasons: Information specified in the performance standard a SIF element is typically not from the relevant safety requirement specification (SRS) datasheet but based on generic requirements. As an example, it is not uncommon to see performance standards written for a set of emergency shutdown valves (ESDVs). The issue crops up when an ESDV is also a part of a safety instrumented function (SIF). The performance standard may be based on generic requirements for such valves which may or may not be as per the safety requirement specification (SRS) datasheet for the overall SIF of which the ESDV is a part of. A mismatch in the requirements could result in incorrect targets being verified. DNV GL has come across multiple examples of performance standards where the reliability target for ESDVs also part of SIL 2 SIF had been set as 95%. On closer examination, we found that the SIL verification calculations had assumed a higher reliability than specified in the performance standard. Furthermore, other targets such as valve closure time were generic figures as no formal SRS existed. Hence, by only meeting the performance standard target, the loop was no longer considered to be meeting its SIL target. Unfortunately, such cases are a common occurrence on riser ESDVs which were regarded as a SCE and are normally part of a SIF. Performance standards are typically written for an element of the safety instrumented function (SIF) such as a valves or sensors but do not necessarily give any information on the complete loop. This is usually a major cause of concern as it can give a false impression of safety. The WSE may be produced in contrast with the proof test method statement (PTMS) for SIF. A successful verification against the performance standard does not imply that the SIF is functional and meeting its SIL. A final element may function during testing and may even meet the 10

11 specifications in the performance standard. This does not imply that this device will function appropriately as part of a safety loop - the SIF. A correctly executed proof test is the only reasonable method by which the functionality of the complete SIF can be assured. It is critical to remember that the SIL is a property of the whole loop, not just an element. However, DNV GL has come across such examples. In one case, it was stated by the operator that testing of the final element, a large valve operated via redundant hydraulic lines, was sufficient evidence the high integrity pressure protection system (HIPPS) the valve was part of can be deemed functional. In other words, the annual test was regarded as the proof test. Crucially, the SRS was not available and there was no evidence that other elements of the HIPPS loop were appropriately tested. Further sources of confusion arises in recommended proof testing of the SIF. The proof test interval is a critical part of achieving SIL. If the SIL verification calculations assumed a minimum test interval lower than that specified in the performance standard, there is a potential that the required SIL and corresponding average probability of failure on demand (PFDavg) may not be achieved. This compromises the safety provided by the SIF. Reversely, there is a potential that an element may be over-tested which results in unnecessary downtime and associated costs. For these reasons, evidence of compliance with the performance standard is not a guarantee that the SIF meets it s specified functional and integrity targets. Hence, the use of performance standards for SIFs or their constituent parts is prone to errors. A solution? An obvious solution may seem to ensure that the performance standards and WSEs operate independently of the SRS and PTMS. However, this does not ensure that the information on the performance standard and WSEs is factually correct. It must be ensured that any performance standard where a requirement has been placed on an element of a SIF is verified against the corresponding SRS datasheet. The WSEs must also note that any testing completed as part of them does not constitute a proof test. On a large installation, ensuring that the two sets of documents are aligned can be a challenging exercise. Another solution is that performance standards for elements of a SIF need not be written in detail. Any SCE which is part of a SIF can refer to the corresponding SRS datasheet. Any additional requirements which are written in a performance standard but are not typically stated in the SRS datasheet could be added to the SRS. The SRS datasheet can then be used as the performance standard. This can be extended further where a suitably amended PTMS or parts of it can be used as the WSE, if a separate examination is considered necessary to meet the regulations or insurance related requirements. The path forward on this aspect is not straightforward. Since the suggested change is a relatively significant deviation from the industry s current practices on the verification of offshore assets, it requires further evaluation and in-field testing by volunteers to develop a cost-effective methodology. This may indeed be a step-change for operators and independent verification bodies. 11