News

Safety Requirement Specification: how to make it clear and concise

Written by GM International | Mar 28, 2018

Clarity and concision are necessary requirements for every technical specification, as all the information contained must be self-evident and the reader has to be put in the position of efficiently focusing on the points. Such requirements are, of course, applicable also to Safety Specifications.

The guide for writing clear and concise safety requirement specifications is a normative requirement by IEC 61511:2016. In fact, the standard requires per Safety Instrumented Function (SIF) - 29 specific description of the intent and approach that shall be applied during the development of the Safety Instrumented System (SIS), listing the following items as applicable:

  • Describe all necessary SIFs to achieve required functional safety;
  • Identify and take account of common cause failures;
  • Define safe state of the process for each identified SIF;
  • Define any individual safe process which, when occurring concurrently, creates a separate hazard;
  • Identify assumed sources of demand and demand rate for each SIF;
  • Identify proof-test intervals;
  • Identify response time for the SIF to bring the process to a safe state;
  • Identify the SIL (Safety Integrity Level) and the mode of operation (demand/continuous) for each SIF;
  • Describe process measurements and their trip point;
  • Describe process output actions and the criteria for successful operations;
  • Identify the functional relationship between process input and output, including logic, mathematical functions and any required permissions;
  • Identify requirements for manual shutdown;
  • Identify requirements relating to energize and de-energize to trip;
  • Identify the requirements for resetting the SIF after a shutdown;
  • Identify maximum allowable spurious trip rate;
  • Identify failure modes and desired response of the SIF;
  • Identify any specific requirements related to the procedures for starting up and restarting the SIF;
  • Identify all interfaces between the SIS and any other system, including BPCS and operators;
  • Describe the modes of operation of the plant and identify the SIFs required for operating within each mode;
  • Identify application program safety requirements;
  • Identify requirements for overrides/inhibits/bypasses including how they will be cleared;
  • Specify any action necessary to achieve and maintain a safe state in the event of faults being detected in the SIF;
  • Identify the mean time to repair which is feasible for the SIF;
  • Identify the dangerous combinations of output states of the SIS that need to be avoided;
  • Identify the extremes of all environmental conditions which are likely to be encountered by the SIS;
  • Identify normal and abnormal modes for both the plant as a whole and individual plant procedures;
  • Define the requirements for any safety instrumented function necessary to survive a major accident event.

The scope of the list provided by the standard is specifying:

  • Logics and actions that a SIS has to comply with;
  • Process actions a SIS has to perform;
  • Process conditions to initiate such actions, including manual shutdown, power supply failure, etc.;
  • Requested SIL level and required performance to achieve it.

The development of the SIS safety requirement specification is one of the most importance activities of the entire SIS life-cycle. The SRS could be a single document, which is easier to maintain, but is more likely a set several documents including procedures, drawings and corporate/company standard practices.

The main objective of the SRS is to specify the requirements for the SIS, including application programs and the architecture of the SIS.  The SRS shall be expressed and structured in a logical way that they are:

  • clear, precise, verifiable, maintainable and feasible
  • written to help comprehension and interpretation by those who will utilize this information to execute any phase activity of the life-cycle

The best way to achieve a safety culture is to specify conditions by quantitative terms whenever possible. In fact, as all engineers know, numbers represent concise and clear information unsusceptible of misunderstanding and misleading interpretations. Examples of information that can, and must, be clearly numerically expressed are: demand rates, proof-test intervals and coverage, SIF response time, process safety time, RRF & SIL level performance, process measurements and accuracy, mean time to restoration, mean repair time, etc.

The SRS is a key document to achieve safety in the process industry and is too often written by designers who forget that later the maintenance-, instrumentation-, and operator- engineers will have to use that information in able to maintain a correct functioning and performing SIS.

G.M. International is providing additional and valuable examples of a detailed SRS in chapter 8 of the SIL manual – 4th edition.