908 / 1143
Introduction
As an engineer involved in the design of electronic and programmable safety systems back in the 90’s
for a large system integrator, who was involved in some of the biggest projects in the UK and Middle
East for both the oil & gas and nuclear industries, I can honestly state that regulations, standards and
guidelines were around but certainly not followed to the letter and treated as in no way mandatory
around that period.
Requirements capture that defined the functionality of such systems would be derived from a
combination of End User, EPC and Systems Integrators interpretation of process narratives, P&IDs
and flow diagrams. No bad thing, a team effort, one could say, but what of the risk?
Although I may have been aware on certain projects that something resembling a HAZOP may have
taken place there didn’t seem to be a connection to the (functional) safety requirements. No
verification of the output of such a meeting or validation that the integrated system met the original
design intent.
A recent post on LinkedIn questioned the accuracy and usefulness of Cause & Effect diagrams for
safety system design. The post, entitled; “Cause and Effects – The Good, The Bad and The Ugly” was
widely viewed and received numerous comments all agreeing what a poor communication tool these
diagrams are. That unfortunately is still the state of the industry today – a 2-dimensional matrix view
of logical requirements with no substantial improvement in functional and performance specification
and assurance in the last 20 years.
But that was more safety engineering and not functional safety or at least not as we may understand it
today i.e. it was safe, but was it safe enough? There was definitely a lack of continuity and
communication between activities and stakeholders. Risk assessment was a tick in a box with often a
subjective or unexplainable target, thereafter did the allocated protection layers and in particular the
SIS fulfil the requirements for risk reduction. Did it meet the requirements of the risk assessment for
safe operation? A FAT would be driven by the accuracy with which it met the logic of a Cause &
Effect sheet. Bypass and override philosophy was taken from an End User company-wide
specification. Process safety times? Identified safety instrumented functions? No, sorry, no real
management (never mind lifecycle) in the mid 90’s.
If we take a leap forward to circa 2005, IEC61508 has been in circulation for around 5 years and
IEC61511 for two. Enterprising individuals had jumped well and truly on the ‘risk assessment’ band
wagon offering services and even software tools. SIL and SIF had become common place acronyms.
SRS? not so much. Where were these early pioneering consultants plying their considerable talents?
The end users? Well surely not, the End Users had clung tightly on to the ‘grandfather’ clause and of
course the standards weren’t mandatory, were they?
In other words, there was no real reason (regulatory, commercial or otherwise) for End Users to get
too hot under the collar about functional safety or safety compliance. All the same, specifications
started to appear with statement such as ‘safety system shall be SIL3’. Not as the result of a SIL
determination report but more of a ‘better make sure we’re covered’ stand point. In fact specified SIL
levels took a downward trend from 3 to 2 to 1 when the end user realised there was possible a huge
difference in costs, especially life time costs.
In fact, in those dark days’ suspicion was widespread that consultants were being leant on to use
methods such as LOPA and allocation of protection layers to arrive at an outcome more in line with
the budget than the risk reduction required.
If we think of the safety lifecycle as a pie chart what percentage of time and effort is the risk
assessment slice? This isn’t really a question that can be answered because in real terms once we feel
we have arrived at defined SIL and allocated our protection layers, nearly the rest of the lifecycle is