Paper 2: Why embrace the concept of the Safety Requirements Specification?
Institute of Measurement and Control – Functional Safety 2016
4
which being that of a Safety Lifecycle; a structured approach which the
standard itself defines as:
necessary activities involved in the implementation of safety
instrumented function(s) occurring during a period of time that starts at
the initial concept phase of a project, through design, implementation,
operation and maintenance, and finishes when
all
of the safety
instrumented functions are decommissioned and therefore no longer
available for use
.
Within the Safety Lifecycle, a number of key Phases are defined, including a
dedicated activity of “Safety Requirements Specification for the SIS”. As the
last activity in the analysis phase of the safety lifecycle, the intent is for all
safety related factors which require consideration in the SIS/SIF solution be
documented in a single, controlled reference point. A significant purpose for the
SRS is that it drives the development of Validation plans which are used to
confirm the correctness of the final installed SIS solution.
SRS Content. What we see and what is missing.
Clause 10.3.1 of IEC61511-1 contains a minimum list of requirements for
consideration in the SRS with considerable emphasis placed on the process
and its requirements. Emerson review a considerable number of specifications
and customer requirements. The content included can vary a lot, but a
summary of what we see suggests that the focus is on the equipment being
purchased and not the requirements it must fulfil to provide adequate functional
safety. We see functionality described in Cause and effect matrices which
include the entire
shutdown functions
with no means of identifying the
safety
functions
and rarely a good understanding of the hazard scenarios the
SIS/SIFs are protecting against. Some notable examples might include:
Reaction to fault. Smart devices can sometimes warn you that is the cause of an
apparent trip. Generally, we see a blanket statement to trip, but this decision should
be made on a case by case basis.
Overrides. These are often specified once for the whole SIS however each SIF
represents entirely different risk circumstances. In each case an override shouldn’t
exist unless it can be proven that process risk can be effectively managed
Proof testing. Factors contributing to proof test viability and success are many. The
effects of prescribing a test interval can significantly change the SIF design. We
normally see a single period prescribed
The above three issues are chosen as examples where an individual should
not be deciding the requirement. Operators, process and automation engineers
will have different points of view. A team decision understanding all the impacts
is the only way to specify the right requirement.
Current approaches to SIS specifications and specifically the SRS does also
depend on whether the SIS is for a new (greenfield) project or a replacement
for obsolete technology (brownfield). Greenfield requirements tend to focus on
what is required to deliver your contractual obligation and brownfield
opportunities tend to focus on a replacement of like for like functionality and an
acceptance that what is there must be right. In either case the point of the SRS
as a reference for the lifecycle is often missed. The SRS should specify what is