Skip to main content

Defining requirements and optimising safety - part one

Oilfield Technology,

The latest functional safety standards recognise that it is important to define exactly what is needed upfront in order to optimise safety systems through the lifetime of a process installation. John Walkington and Stuart Nunns, ABB, UK, explain what is involved and why it matters.

Defining what is required to deliver optimised safety instrumented systems (SIS) in process industry projects can be incredibly complex, whether they are new builds, upgrades or expansions. And while everyone is keen to ensure that whatever is in place at the end of the process presents as little risk as is practical, precisely what that means in terms of safety system requirements has often been a key area open to misinterpretation.

For example, the hazard analysis of a proposed project might identify a possible danger from a flammable storage tank overfilling with the potential to result in a fire or explosion. As a result of having carried out the analysis, instrument engineers will naturally be expected to provide suitable instrumented protection to prevent any fire or explosion from happening in accordance with some form of target safety integrity and functional performance.

 In the past, an individual engineer might well have used a particular type of high-level prevention system based on a previous safety instrumented function (SIF) project design as a default solution. This might include a proof test frequency based on previous maintenance expectations, for instance. Pressures on time and/or resources may well result in the temptation to simply re-use the same approach in any new project, but that could well be an expensive mistake.

 Correctly specifying a safety system for the job at hand is of crucial importance. If safety systems are over-specified, they are likely to cost more upfront, and the extra complexity they introduce will require more operational management and maintenance, pushing up the Opex running costs over the lifetime of the plant. Conversely, the consequences of under-specification can be much more serious. Under-specification leads to a greater likelihood of the safety system being inadequate and thus unable to provide the correct level of risk reduction, increasing the potential for the system being unavailable when a demand occurs.

IEC 61508 Edition 2

A key technical management requirement for the asset owner is the potential mis-match between the hazard and risk analysis information and the development of the safety requirements specification prior to the design and engineering of the safety related system.

The introduction of Edition 2 of the IEC61508:2010 functional safety standard gives a higher priority to defining a suitable, dedicated safety requirements specification (SRS) for each project. It introduces a formal stage between the conclusion of the hazard analysis stage of a project and specifying particular SIS requirements leading into the design and engineering phase. The SRS is intended to bring together all the information necessary to make sure that any SIS provides the right level of performance and risk reduction without being overly complex or expensive.

However, many process owners and contractors continue to omit crucial information that needs to be included in an SRS, especially if it is to meet any ‘due diligence’ requirements regarding traceability and any assumptions made, such as its ability to comply with industry good practice requirements.

 At the early stage of a project, the purpose of the preliminary SRS is to gather sufficient safety requirements information to enable a basic sizing and preliminary costing of the safety system. Further into the project timescales, additional revisions of the SRS document will be needed to complete a detailed specification when more information about target SILs and individual safety instrumented functions becomes available. As such, the SRS effectively becomes a working document to support the development of the SIS during the capital project lifecycle. That said, it will need to be frozen or base lined preferably before design commences otherwise there is the potential for ‘requirements creep’ during this process.

Typically, the SIS usually forms a very small part of the larger project automation scope of supply in terms of the cost to the project. What is often completely missed at this stage, however, is that the small cost of getting it right at the front end of the safety lifecycle can be a significant ratio/multiplication factor in the future if the SIS were to fail on demand.

 When it comes to what constitutes a comprehensive, ‘fit for purpose’ SRS, there is no formal template, although some organisations involved in functional safety, including ABB, may have their own procedures to ensure that their clients cover everything they need to.

 IEC 61508 and IEC 61511 require over 26 pieces of information that should be considered in any SRS. This may sound like a huge information-gathering burden, but most of the information should be readily available, especially if a thorough hazard analysis and SIL determination risk assessment has been previously carried out.

What is involved?

Experience suggests that there is still a significant disconnect between the current processes of hazard and risk assessment leading to the derivation of the safety instrumented function and its related Target SIL and the development of a robust and meaningful SRS for the design and implementation of a safety instrumented system (SIS).

Broadly speaking, SRS requirements fall into four categories: performance, integrity, operations and maintenance and service and repair.

 Performance covers the range of considerations that make sure that the safety instrumented system is fit for the specific purpose for which it is designed.

 Can it meet the required process safety time, for instance? From detecting a problem to carrying out an action to make it safe takes time, especially if there are large, slow-moving items of equipment involved within the end to end design of the safety instrumented function (SIF).

 Integrity is all about making sure that the safety system is working properly when it is needed it most. The required level of integrity for a particular safety system - expressed as a SIL level - will depend on a combination of the likelihood of action being needed and the definition of what constitutes a safe state, including aspects such as the likely operating environmental conditions for the SIS.

Operations and maintenance requirements cover the need for inhibits or overrides, shutdown modes, proof testing regimes, system re-starts, response times and critical information about actions associated with alarms. This is about making sure that the right regime is in place in order to look after safety equipment and have confidence that it will work properly throughout its lifetime.

 How often does proof testing need to be carried out, for instance? Is the right safety management structure in place to guarantee that vital checks will not be missed or forgotten? Are proof testing frequencies re-verified as a result of proof test data and information gathered from trip initiations?

Finally, the SRS should also include information relating to maintaining system security, servicing, repairs and controlling modifications. It is really about ensuring that the performance of the safety equipment is not altered in a detrimental way at some point after it’s installed, i.e., perhaps by an uncontrolled modification, or a potential security threat that enters the system via external communications.

Read part two of this article here.

Edited for web by Cecilia Rehn

Read the article online at:


Embed article link: (copy the HTML code below):