The IEC 61511 Standard requires the user to create a Safety Requirements Specification (SRS) for a Safety Instrumented System (SIS) that incorporates all the analysis done during the Risk Assessment, HAZOP/PHA and LOPA reviews.  The SRS falls into two types: an initial conceptual SRS, often referred to as the Process Safety SRS; a detailed Design SRS which contains all the detailed design information. 

As in any requirements specification, how well and how concisely information is conveyed to the designer is essential to ensure that there is no ambiguity and potential for misinterpretation of the requirements.  This is especially true for safety-related process applications using SIS, where it is critical to convey the requirements in as clear and concise a manner as possible; avoiding jargon and/or TLAs (Three Letter Acronyms) is another important requirement.  However, if TLAs are used, then a glossary of terms should be included to assist in comprehension.  Another very important requirement is that the quality of the document should not be a measure of the number of pages or thickness but in the way the reader can efficiently understand and extract the information.

Why is it so important?  The UK’s Health and Safety Executive (HSE) conducted a study in 2003, regarding accident causes involving control systems[1] and concluded that 44% of the causes were related to specification issues.  Having a poorly, ill-defined or ambiguous specification will lead to increased risk since the SIS design may not meet its intended safety targets.  Therefore, for the SIS there can be no room for misinterpretation or misunderstanding.

The IEC61511 standard is a performance-based standard that is all about the performance of the SIS and reducing risk, so it is very clear about what the SRS should contain: all the requirements for the Safety Instrumented System and its associated Safety Instrumented Functions (SIFs).  Remembering that the SIS consists of one or more Safety Instrumented Functions (SIFs), which can consist of a combination of sensor(s), logic solver(s) and final element(s), including all interfaces and sources of power, so the SRS needs to define two sets of criteria for each SIF: a set of Functional Requirements and a set of Integrity Requirements (Safety Integrity Level target), indicating the amount of risk reduction required to be achieved (i.e. a measure of its dependability).

• SIS General Requirements Section – can include such things as:-
  • operating environment
  • industry standards
  • RFI, EMI, EMC, …
• SIF General Requirements Section – can include such things as:-
  • Operating modes (Normally open, normally closed)
  • Maintenance overrides
  • Failure modes
  • Diagnostics, …
• SIF Specific Requirements Section – can include such things as:-
  • Safe state (i.e. de-energize to trip or  energize to trip)
  • Required SIL (together with target RRF)
  • Proof Test Interval
  • Response time
  • Architecture requirements, voting arrangements ….

A bad SRS will exhibit the following:

• Not defining all failure modes and protection requirements:-
  • Actions of function do not actually achieve safe state.
  • Measurement too slow to pick-up and prevent accident
• Not defining all operating regimes, start-up, shut-down
• Not defining all environmental conditions
• SRS not maintained (poor revision control)
• Conflicting or missing requirements:-
  • Safety & Non-Safety actions

It is strongly recommended that non-safety related functions are limited to the Basic Process Control System (BPCS) and not mixed in with the SIS.  We at exida have seen many examples of poorly implemented SRS requirements for SIS, attributed to some of the factors listed above.  This in turn can be related to competency and having competent people involved, per the requirements of IEC 61511, but this is another whole interesting topic and one that I have discussed before.  If this blog has sparked some interest then please look out for some interesting webinars on this topic.

[1] Out of Control: Why Control Systems go Wrong and How to Prevent Failure,” U.K.: Sheffield, Health and Safety Executive, 1995 (Ed 2, 2003)