This phase begins the shift from analysis to SIS engineering and design. When compared to traditional SIS specifications, the SRS is a major expansion in both depth and breadth (Figure 2). It may contain one or more documents. The SRS is the master document, and referenced documents are subordinate to the SRS. How much time and effort are needed to fully specify individual SIFs can vary widely. On projects with a large number of SIFs, this may noticeably increase the SIS engineering effort, and EPCs and MACs must modify and adapt to this reality.
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.