Clear and Concise Safety Requirements Specifications

by | Sep 15, 2011 | Safety, Services, Consulting & Training | 0 comments

Update and bump: Here is the link to Andy’s paper, The importance of a clear Safety Requirements Specification as part of the overall Safety Lifecycle, which is now posted.

Original May 2011 post: Emerson’s Andy Crosland, a process safety expert, will be presenting a paper at the Safety Control Systems Conference, May 24-26 in Manchester, United Kingdom. His paper, The importance of a clear Safety Requirements Specification as part of the overall Safety Lifecycle, looks at why it is so important to get this key document right at the outset, and why it’s needed later when it comes to Validating the SIS. I’ll link to the paper once it’s been posted on the event website after the conference. Here’s the paper’s abstract:

The need for specifying requirements clearly is recognised best practice for most automation projects, so it makes sense to be extra-vigilant when dealing with safety systems. Many project specifications cover functional and user requirements in great detail, but often miss the key safety considerations set out in IEC 61511. As well as the obvious benefits of a clear specification from the outset, the Safety Requirement Specification (SRS) is the essential reference document for the mandatory IEC 61511 Safety Lifecycle task of SIS Safety Validation. You will be shown the key SRS considerations, particularly why this information is so important at Validation time.

I’ll highlight a few key ideas I learned from reading Andy’s paper. He opens by distinguishing the risks associated with equipment failures in a safety instrumented system, which he terms “random failures” with human error, or “systemic failures”, which can occur through the safety lifecycle—specification, design, implementation, installation, and beyond.

Even if the safety system is built from logic solvers, sensors, and final control elements that are designed and certified per the IEC 61508 global safety standard, mistakes made in their configuration or installation could mean that the overall SIS does not provide the risk reduction that is required for the application.

Andy focuses this paper on how the safety requirements specification should be developed to minimize human/systemic failure risk. The purpose of the SRS per the IEC 61511 safety lifecycle standard:

…should be expressed and structured in such a way that they are:
– clear, precise, verifiable, maintainable and feasible; and
– written to aid comprehension by those who are likely to utilize the information at any phase of the life cycle

Andy notes that the word “concise” should be added to focus this document on functional safety-related topics only. The tendency is to put much more into this document, such as:

…HMI requirements, electrical wiring and tagging standards, cabinet dimensions, etc…

This information is better located in separate user requirements or functional design specifications.

IEC 61511 Clause 10 lists 27 mandatory requirements for the SRS. What’s often not well addressed are definitions of the process safe states for each safety instrumented function (SIF), separate hazards created by concurrent individual safe process states, SIF response times to bring the process to a safe state, override/inhibit/bypass requirements, dangerous combinations of output states, and environmental condition extremes.

Andy recommends that certain key information from the hazard and operability (HAZOP) study should be included in the SRS:

… for those Hazards which do require risk reduction from an SIS, there may well be valuable information about the nature of the hazard and the process and environmental conditions which may affect the SIS. This information, where relevant to safety, should be captured and consolidated within the SRS. Few projects refer back through the many pages of a HAZOP report at the design, build, test, install phases.

Consolidating the process safety-related elements from the HAZOP into the SRS helps to achieve the IEC 61511 requirement to aid in the comprehension of anyone using this information through the safety lifecycle.

The HAZOP analysis is a precursor to the analysis to determine where instrumented safety needs to be used for risk reduction. A common form of this analysis is the Layers of Protection Analysis (LOPA). Just as with the HAZOP, the relevant process safety-related information should be captured in the SRS.

Andy provides process examples with what types of information should be captured in a structured approach to the development process for the SRS. Some of this information really comes into its own when it comes to SIS safety validation to satisfy IEC 61511 Clause 15 around inspection and testing. You’ll want to read these sections once I’ve linked to his paper.

Here’s a portion from Andy’s concluding thoughts:

The Safety Requirement Specification should consolidate information from preceding lifecycle phases where relevant to the functional safety provision by the complete SIS, including sensor, logic solver and final element parts.

The SRS should contain all information necessary as the basis for the mandatory lifecycle phase of SIS Safety Validation; an inspection and test of the installed SIS prior to introducing the process hazards. Validation should be based on the SRS, not on intermediate lower-level design documents, so that any errors which may have been made in the creation of those detail design documents are detected by the validation, rather than becoming a part of the installed SIS.

Validation should not be confused with Verification, which is an ongoing activity throughout all phases of the safety lifecycle.


Related Posts

Follow Us

We invite you to follow us on Facebook, LinkedIn, Twitter and YouTube to stay up to date on the latest news, events and innovations that will help you face and solve your toughest challenges.

Do you want to reuse or translate content?

Just post a link to the entry and send us a quick note so we can share your work. Thank you very much.

Our Global Community

Emerson Exchange 365

The opinions expressed here are the personal opinions of the authors. Content published here is not read or approved by Emerson before it is posted and does not necessarily represent the views and opinions of Emerson.

PHP Code Snippets Powered By :