IEC 61511 Implementation - The Execution Challenge

Figure 1. Simplified SIS lifecycle (Partial)Figure 1 shows the elements commonly performed and supported by EPCs and MACs. The PEP defines the scope of work, roles and responsibilities, work processes and procedures, QA/QC plans, etc. A functional safety plan (FSP) is required by IEC 61511 and encompasses many of these PEP processes and procedures, but continues beyond the project to include the entire safety lifecycle through commissioning and operations. It also includes additional requirements that are specific to safety systems. The project team needs to coordinate and cross-reference both documents to ensure there are no conflicts or exclusions. As indicated in Figure 1, the application of IEC 61511 increases the number of analysis and design steps that can lengthen SIS design cycle. The project must be well- planned, managed and correctly scheduled and resourced to keep the SIS design off of the project's critical path. 

Layer of Projection Analysis (LOPA)

LOPA is a commonly accepted method for determining layers of protection and allocating safety functions. The PHA report is the LOPA starting point. For each PHA hazard and associated risk values, the LOPA team identifies and assigns one or more independent protection layers (IPL) until the risk is reduced to an acceptable level. If a risk remains after other preferred IPLs are applied, the remaining risk is typically reduced by a SIF. Like PHAs, LOPA reports are issued with recommendations and action items that may require further analysis and assessment. The report in this form is often handed off to the EPC or MAC to implement. 

Once received, the EPC or MAC reviews the LOPA report to understand its content. A month or more may lapse before this step is completed. On closer examination, questions may arise and irregularities may become apparent. A process should be in place that allows the LOPA team to review the PHA and if necessary, make changes in the PHA if an error is confirmed.  

The LOPA report does not typically provide the following information required to progress the SRS:

• SIF final elements.
• An answer to the question, "Does SIF activation create a new hazard?"
• Hazard process response times.
• Potential sources of common cause failure.
• Confirmation that the assessment addresses all modes of operation.

Often a proposed SIF final element creates a new hazard when it moves to its safe state or position. This triggers a one-off, unplanned hazard assessment that may require a revisit to the PHA or LOPA. Process response time is often difficult to define and provided by different disciplines and equipment specialists. A fast response time may trigger a new hazard that also requires further assessment. Identifying sources of common-cause failure often requires input from several disciplines. The additional time needed to assess hazards when operating in different operating modes is often overlooked. 

Suggestions for improving PHA and LOPA outcomes:

• Provide the FSP before the project starts. It should clearly define the site or corporate approach, tools, processes and personnel required; and include a process to resolve problems that are not directly addressed in the PEP and FSP, as well as instructions on how to provide the analysis information missing in the LOPA report. 
• Resist the temptation to shortcut or truncate the analysis phase to save money or reduce project schedule.  
• Provide equipment- and risk-specific PHA and LOPA examples that show the expected application of the corporate and project tools, risk matrices and IPL rules.    
• Align the PEP with the FSP. Revise the plan to address challenges unique to an IEC 61511 implementation.
• Increase training for PHA and LOPA teams on the correct use and application of the supplied tools, standards and procedures.  
• Provide checklists that define the recommended steps to assess hazards for common equipment types.   
• Provide a documented process to track, expedite and resolve PHA and LOPA recommendations and action items.  
• Provide a quality assurance plan to confirm the requisite procedures are followed.    
• Assign a team to verify and consolidate PHA and LOPA recommendations and replace "consider" recommendations and action items with actionable decisions. 
• Have technical specialists conduct pre-assessments of specialty equipments.
• Insure teams include the necessary technical expertise. 

• Ensure that management-of-change procedures encompass all steps in the IEC 61511 process.

Safety Requirements Specification (SRS)

Figure 2. Safety requirements specification inputs and reports.

The simple task of issuing the SRS requires discussion. The global section should be issued for approval early. Issuing the SIF section may need to occur on a SIF-by-SIF basis since completion depends on when PHA/LOPA action items are completed and information is available.

The information required to fully define and document a SIF may entail 40 or more unique data items. The source and detail required to document each item must be defined clearly. The effort to gather, track and review this data can be significant. For a large project, the work includes migrating and recording large amounts of data that may be provided in different formats, at different times and by different disciplines and organizations, so some companies develop in-house SRS database tools to improve productivity, reduce errors and track SIF development and approval status. Information provided by different disciplines and organizations represents an interface challenge that should be addressed in the PEP Interface Management Plan. The potential for data transfer and transcription errors should be addressed in the PEP Quality Plan. 

Completing the SIF section typically requires an SIS engineer with depth and breadth of experience. Once it's completed, a competent senior person should do a "cold eyes" quality check. The quality plan should define the approach to these checks. 
The SIF specification process may identify problems that can trigger a secondary work process or design change.  

A common scope question is what are the project requirements for documenting protective instrumented functions (PIF) that are not required by the LOPA/PHA. Are PIFs documented in the SRS? Do the SIF analysis and verification steps apply to PIFs? Will the SRS differentiate between SIFs and PIFs? These questions need to be answered before budgets are firmed up and schedules developed.

To improve SRS outcomes and execution:

• Define what information is included in the SIF specification section, the level of detail required, who provides the information, and who records it in the SRS.
• Provide an example specification for common SIF types and indicate the level of detail required.
• Define the approach to assessing and documenting PIFs that are not SIL-rated. 
• Define if the SRS will differentiate instrumented functions by type, e.g. safety, environmental, regulatory or asset protection.
• Define the quality checks required in the PEP quality plan.
• Complete and approve the global SRS narrative section before SIF specification work begins. 
• Confirm which document is the "master" repository for alarm and trip settings. 
• Define how and when the individual SIF specifications will be issued for approval.
• Use electronic tools to manage the SRS SIF definition section, support electronic data transfer and manage SRS data over the SIS life cycle.
• Develop tools for tracking SIF specification design and completion status.

SIL and Spurious Trip Rate (STR) Calculations

SIL and STR targets are verified using project-approved calculation tools and reliability data sets. The SRS typically provides the information needed to correctly model the SIF. Final SIL calculations are generally provided late in the project. To support early equipment procurement, preliminary SIL calculations are often recommended to confirm that SIL 2 and 3 SIFs and the more complex SIL 1 SIFs can meet the SIL and STR targets. Failure to meet a target typically triggers a study to identify alternate designs, adding time to the schedule.

If not defined in the FSP, the reliability data used in SIL calculations should be selected early. The FSP or PEP must define how new data will be assessed and formally approved.  

To improve verification calculations and execution:

• Identify the calculation software and the source of the reliability data used. 
• Provide rules to guide how SIFs are modeled, named and documented, and how they target PFD safety factor, applicable common cause factors, etc.
• Define what information and detail is recorded in free- form fields.
• Provide example calculations for common equipment and complex SIFs. 
• Define the process for approving third-party reliability data used in preliminary and final calculations and its introduction to the team.
• Define what test interval is used.
• Define the issue and approval of calculations process.

Implementing IEC 61511 requires changes in historical work processes, procedures, tools and execution plans. Operating companies, EPCs and MACs should continue to develop corporate standards, guidelines and tools to guide project teams and improve consistency between projects, and the execution and technical plans, procedures, tools and resources required to successfully implement this standard in today's complex project environment.  

Tom Shephard is an automation project and (MAC) program manager at Mustang Engineering.

Dave Hansen is the Safety System Practice lead at Mustang Engineering.

Find out how Moore Industries International (www.miinet.com) worked with TÜVRheinland (www.us.tuv.com) to certify compliance to IEC61508 for its single-loop logic solver. Go to www.controlglobal.com/whitepapers/2010/042.html for the complete story.