Safety Instrumented Systems: Bridge the Gap

Many companies today are striving for sustainable safe manufacturing. The challenge to successfully achieving this goal is to understand how to optimize profitability while still fully meeting process safety management (PSM) obligations — i.e., preventing and controlling incidents with the potential to release hazardous materials or energy that could harm people, property and the environment. As part of the broader PSM task, an organization must identify necessary protective layers and implement functional safety (FS) lifecycle management.

Dedicated automation systems serve as an important protective layer in a process operation. Processing visibility provided by integrated control and safety automation underpins successful delivery of both FS and business sustainability.

Managing FS is an increasingly complex challenge and involves specifying safety requirements and then ensuring those requirements are successfully incorporated into design and engineering solutions from your supply chain partners.

[javascriptSnippet ]

Defining what is required to deliver an optimized safety instrumented system (SIS) within process industry projects, whether new builds, major upgrades or expansions, can be incredibly complicated. Therefore, the asset owner or engineering-procurement-construction (EPC) company must ask three essential questions:

1. Do we spend enough time and effort on our systems to ensure FS requirements are correctly specified and documented?
2. Do we have competent people assigned and available over the entire supply chain to undertake and deliver these requirements?
3. Can we demonstrate compliance against industry good-practice expectations?
If a safety system is over-specified, it is likely to cost more upfront and, because of the extra complexity, will require more attention and maintenance once commissioned. Over-specification pushes up running costs over the lifetime of the plant. However, under-specification can pose much more serious consequences because the safety system may well be inadequate and unable to provide the correct level of risk reduction — potentially resulting in a failure on demand.

Safety Requirements Specification

The second edition of the IEC 61508 functional safety standard [1] gives higher priority to defining a suitable, dedicated safety requirements specification (SRS) for each project. It introduces a formal phase (Phase 9) between the conclusion of the hazard analysis stage of a project and specifying particular SIS requirements leading into the design and engineering phase. The same focus on requirements specification also appears within the recently revised and enhanced process-industries-sector standard IEC 61511 [2] — in particular, the 29 pieces of minimum information as identified within Clause 10.3.

Ultimately, the SRS is intended to bring together all the information necessary to ensure the required SIS provides the right level of performance and risk reduction without being overly complex or expensive.

During a typical project front-end-engineering-design study, the outline SIS requirements are based on a preliminary automation philosophy document. This usually is confirmed in principle before any detailed hazardous scenario is defined, risk assessed and an eventual target safety integrity level (SIL) established. This also is even prior to considering the functionality aspects needed to successfully design, engineer, operate and maintain an SIS.

At this stage in the project, work on the safety requirements typically begins, as do discussions with possible supply chain partners. Decisions are made early in the process regarding SIS requirements. They are not usually based on a full technical clarification process, i.e., one that focuses on the potential hazards that may be present at the site and details needed to provide adequate risk reduction. Therefore, it is impossible to confirm in any great detail whether the selected technology requirements exhibit the necessary safety integrity and safety functions. Nevertheless, the specific technology chosen usually centers around the need for one or more SIL-rated-capable logic solvers.

For larger projects, the SIS usually forms a very small part of the broader automation scope of supply in terms of the cost and resources applied to a typical new-build project. However, what often is missed completely at this stage of the decision-making process is the modest effort that the responsible process engineering and instrumentation teams can and should apply to get the SIS correct. The resultant lack of robustness frequently develops into an SRS seeded with too many assumptions and potential gaps that the automation partner is expected to bridge during the future detailed design and engineering lifecycle phases.

An owner/operator should always remember the SIS usually is the last line of defense against the occurrence of an incident.

Consider this analogy: Do you actually have a robust, well-built steel bridge to your functional design and engineering requirements? Or, in reality, is it a wobbly rope bridge missing many foot planks, potentially leading to an incident when put into use?

When it comes to allocating risk reduction requirements to instrumented protective layers, it is the responsibility of the asset owner/EPC firm to provide an SRS that enables the SIS design teams to correctly create the safety functionality and safety integrity requirements for the desired SIS. To meet industry good-practice expectations, this is identified as Phase 4, Overall Requirements, and Phase 9 for E/E/PES in the IEC 61511/61508 safety lifecycle models.

The Challenges

Experience suggests that a significant disjoint or tangible gap exists between the current hazard and risk assessment activities (leading to the derivation of the target SIL) and the development of a robust and meaningful SRS for the design and execution of an SIS.

Consider the expectations of industry good practice. Does the interpretation of the performance and detailed information derived from earlier safety lifecycle phases align with the recommended sections of an SRS development document as set out in the safety standards? If not, this may have consequences on safety performance when the SRS is released to the supply chain, i.e., additional issues relating to commercial, contractual, technical and requirements creep.

This is a further bridge to cross as the SIS integrators/equipment suppliers are expected to correctly turn an asset owner/EPC’s non-application specification into a technology-specific solution that delivers what is required. The question to pose here is: How does the integrator/equipment supplier provide such an assurance so early in the project lifecycle if its response is built on an SRS that lacks any real substance?

Therefore, getting it right means:

• Everyone involved within the supply chain understands the safety function and safety integrity requirements for the SIS.
• The design completely satisfies the requirements of the SRS and achieves the necessary performance to provide safety-related assurance to the asset owner.
• The asset owner/EPC can demonstrate that lifecycle traceability regarding risk reduction targets has been met.
• The project doesn’t suffer from issues and schedule slippages due to numerous clarifications/design by technical query (TQ).
• Operation, maintenance and necessary testing of system solutions reflect the optimum tradeoff between capital and operating expenses.
• Carefully documenting how your efforts accord with regulatory and industry good-practice expectations as part of your overall PSM obligations satisfies needs for stakeholder scrutiny.

An asset owner developing an SRS should consider structuring the document and breaking down the particulars into generic SIS performance requirements, including detailed information linking to any company-specific standards, guidance or good practices. The asset owner should also contemplate applying further granularity for defined functionality and integrity sections for each individual safety instrumented function (SIF) required, e.g., process engineering data associated with the sensor, logic-solver and final-element portions required for every SIF.

Splitting the SRS into defined sections for both process and instrumentation requirements allows process engineers to concentrate on their requirements and instrument engineers on theirs. This enables developing and populating the SRS in an efficient and resource-focused manner.

When populating the SRS content, the performance requirements essentially cover the range of considerations that ensure the SIS is fit for the purpose for which it’s designed.

Experience suggests that potential errors usually stem from issues such as:

• lack of understanding of what constitutes an SRS;
• ignorance within the supply chain on how to address requirements to achieve accurate and compliant SILs;
• superficial knowledge of IEC 61508 and IEC 61511/ISA84.01[3];
• delay in preparation — often design has started;
• failure to make one person responsible for owning and producing it;
• inclusion of too many references to irrelevant or outdated standards, leading to conflicting requirements;
• misunderstanding of many caveats and too many assumptions;
• omission of a defined list of SIFs — so there’s no visibility on the entire system;
• imprecise statements, e.g., “Supply a SIL 3 system,” that give no clue as to what this entails;
• resistance to “cutting and pasting” from past SRSs, leading to applicable process conditions/standards being missed; and
• incomplete hazard, operability and risk assessment information, seeding errors into risk reduction requirements.

To avoid such errors when developing the SRS, you must get input and help from a broad range of people — typically, the process safety engineer, environmental/health/safety manager, project manager and commercial manager as well as operations and maintenance staff. Never treat an identified issue as simply the instrument engineer’s problem.

Note that the latest edition of IEC 61511-1 requires recording the results of the allocation process so that the SIFs are described in terms of the functional needs of the process — for example, the actions to be taken, set points, reaction times, activation delays, fault treatment, valve closure requirements, etc., and also in terms of the risk reduction requirements. This document, often called the process requirements specification or safety description, serves as essential input information for the SRS.

In this way, once the SRS has been formally released, the SIS integrator/supplier can test key assumptions and spot if there’s an opportunity to safely reduce complexity in design and installation and the expected maintenance regimes while optimizing the overall cost to:

• provide clarification and reduce ambiguity to technical, management and integrity requirements;
• give commercial assurance the SRS meets the intended risk reduction to be afforded by the SIS; and
• establish the basis for traceability and audit trail throughout later lifecycle phases.

When the SRS is commercially released to the supply chain, the specification is no longer just the focus of compliance to some form of re-usable functional description appropriate for use in other past projects. Therefore, to bridge the gap, much more than a loosely worded scope document supported by a declared SIL and a cause-and-effects diagram is required.

Build A Better Bridge

The overall objective of the SRS is to specify everything necessary for an effective SIS, satisfying both the functional relationship between the described process inputs and outputs and the integrity for each SIF determined with respect to its SIL.

Experience to date suggests that an “invite to tender” from an asset/project owner doesn’t necessarily come with a full SRS in accordance with the relevant safety standards. This leads to the potential for:

• misinterpretation of “intention-to-treat” solution responses by the project owner’s commercial team when analyzing suppliers’ proposals;
• project schedule slippages due to time wasted clarifying TQs and performance qualifications. Asset owners will have to conduct impact analysis for every change in the specification, i.e., design by TQ.
• expensive re-engineering of the solution either at the factory or during site acceptance testing. This could be based on misinterpretation of requirements regarding baseline assumptions, often impacting on resources and costs;
• approval for design and installation of a safety system that does not meet the necessary risk reduction;
• lack of demonstrable traceability to industry good-practice standards; and
• exposure to liabilities, both corporate and professional.

In summary, developing the SRS is one of the most important activities during the lifecycle because the SRS collects all important information necessary to design and build functional safety into process applications. It is written to aid comprehension by all those who are likely to use the information at any lifecycle phase; it is the key document provided by the asset owner/EPC for all SIS-relevant requirements.

So, the next time you are responsible for managing the development of an SIS, ask yourself the question: “How strong is my SRS bridge for transferring detailed requirements into functional design?”

JOHN WALKINGTON is manager, Safety Lead Competency Centre, for ABB Ltd., St. Neots, U.K. E-mail him at [email protected].

REFERENCES

1. IEC 61508, “Functional Safety of E/E/PES Safety-Related Systems,” 2nd ed., Intl. Electrotechnical Commission, Geneva, Switz. (2010).
2. IEC 61511, “Functional Safety — Safety Instrumented Systems for the Process Industry Sector, Part 1,” 2nd ed., Intl. Electrotechnical Commission, Geneva, Switz. (2016).
3. ANSI/ISA-84.00.01, “Functional Safety: Safety Instrumented Systems for the Process Industry Sector,” Intl. Society of Automation, Research Triangle Park, N.C. (2004).