158 / 1145
Paper 2: Why embrace the concept of the Safety Requirements Specification?
Institute of Measurement and Control – Functional Safety 2016
6
hazard as over complexity is the enemy of good SIF design. Emerson were
engaged to assist with defining the safety requirements specification and
therefore a discussion on hazard scenarios was conducted in order to fully
understand and document the safety requirements. From these discussions it
was obvious that under certain circumstances tank outlets could become inlets
and therefore primary actions included in the safety function. This requirement
was in the risk assessment, but the significance of what was written there had
not been appreciated until the definition of each safety function was considered
during the SRS activity.
Case study 4.
This example illustrates how a vital piece of information could get forgotten in
the early phases of the project resulting in a high likelihood of failure on
demand of a shutdown valve. The valve in question was identified as a primary
action closing off the gas stream that during operation could reach
temperatures of -40° C. As part of the SRS process, we discuss each primary
measurement and action and specific safety requirements including affects
which might result in a higher probability of failure. Whilst discussing this valve
with the process engineer he suddenly remembered and said
"I must
remember to check they have lagged the valve. If they do, it will never move".
Such a requirement would not be in the valve specification and is a good
example of where the SRS collects crucial safety related requirements.
The problem.
Our experiences regarding SRS content and the above examples could lead to
many observations. To summarise the problem is difficult. However, I conclude
that the main issue here is:
Nobody NEEDS an SRS!
The dilemma is that you can design, build, install, maintain and modify an SIS
without an SRS. We did for many years, which makes the process of
appreciating what an SRS can do for you more difficult.
From supply driven to requirements driven
The mere presence of a dedicated standard for safety instrumented systems
should be enough for us to conclude that functional safety and safety
instrumented systems deserve a unique identity. From an outsider's point of
view there is little difference between a control system and a safety system.
They measure, they make decisions, they take action and they communicate to
operators via a graphical interface. The supply model is equally similar. We
break down the total scope into individual elements based on technology and
supplier. Each one gets a set of documentation sufficient to complete their
supply obligations. The components may be different but the scene is set for
SIS being treated as an extension of the BPCS rather than unique, distinct and
secure.