A safety requirement specification (SRS) for a safety instrumented system (SIS), as part of the IEC 61511 global safety standard [from the exida blog]:
…incorporates all the analysis done during the Risk Assessment, HAZOP [hazard and operability study]/PHA [process hazard analysis] and LOPA [layer of protection analysis] reviews.
He opened citing statistics for the UK Health and Safety Executive on the Primary Cause of SIS Failure:
Russell noted that success of any safety instrumented function (SIF) within the SIS is entirely dependent on it doing the right thing at the right time in the right way. Given this common goal of both process safety and functional safety, it is strange that there is often such a disconnect between them throughout their lifecycle. He asked the attendees how many SIS specifications do they see with no mention of the process being protected at all?
It is no wonder that specifications are the source of so much failure, as it cannot be clearly understood from the specification what exactly the design intent of each requirement is. Russell explained that early errors made up front in the process design stage can get compounded along the way to where hidden systematic failures wait for the right conditions and contribute to the likelihood of accidents occurring.
During the process design phase, the hazard and risk studies can vary significantly both in the complexity and novelty in design. It leads to the generation of numerous primary documents including the P&IDs. These prescribe what measurement and control devices will be connected to the various parts of the automation system. The connection between hazard and SIF may begin to get lost. Between each phase and within each phase are interfaces between individuals and disciplines. Each interface is also a source of error and these errors can be compounded giving a believable but erroneous result.
Russell emphasized that a well-written SRS encourages the contributors and users to have a wider understanding of exactly why each part of an SIS is designed as it is. Knowledge outside the boundaries of an individual’s discipline will lessen the potential for unnoticed error at interfaces.
Also, based on the safety lifecycle as described in the IEC 61511 standard, a significant purpose for the SRS is that it drives the development of validation plans that are used to confirm the correctness of the safety instrumented functions and the overall installed SIS solution. Russell shared IEC 61511-1 clause 10.3, which contains a minimum list of requirements for consideration in the SRS with considerable emphasis placed on the process and its requirements.
Russell summarized his presentation with what he and the SIS functional safety consultants often find missing from an SRS. Regarding process focus, what’s missing is an understanding of the hazard scenarios and how the safe state is achieved. Also missing is a clear understanding of the effects of combining hazards and various scenarios. A clear understanding is for all the process states and mode is needed for the SIF-focused functionality.
As far as the device safety requirements, what’s missing is how this integrity is affected by the process and what restrictions and methods are required in testing the devices on a periodic basis. It’s important to underscore that you cannot validate your SIS without the SRS and that a well-developed SRS is a significant contributor in reducing systematic error.
A better understanding of the hazards in the process leads to better designed and safer solutions. If the SRS is not properly linked to the potential process hazards, then it extremely difficult to judge the importance of these requirements throughout the entire safety lifecycle.
You can connect and interact with other functional safety experts in the Safety Instrumented Systems group in the Emerson Exchange 365 community.
