Functional Safety 2016

Paper 2: Why embrace the concept of the Safety Requirements Specification?

Institute of Measurement and Control – Functional Safety 2016

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