A SIF gets specified as an automated independent protection layer (IPL), often as the result of a safety integrity level (SIL) target-setting exercise, also known variously as a SIL determination, SIL study or SIL assessment.
Like any many other safety engineering activities, designing a safety instrumented function (SIF) usually involves several repeated rounds of activity. Nevertheless, there are broadly five key steps involved.
When a SIL target gets assigned to a SIF, this is a statement of the safety integrity the designer needs to demonstrate. The safest designs are achieved using multiple redundant devices, high diagnostic capability and diversity. However, most of these aspects come at an equally high cost, and some of them do not necessarily achieve high availability. The key is, therefore, to match the design with the safety integrity level (SIL), while keeping spurious trips to minimum.
So, with the above in mind, what are the five key checks involved in SIF design?
Requirements should be stable
No SIF design should start unless there is a clear statement of stable requirements. That does not mean that detail needs cannot be developed later in a project, but serious money can be saved if the major requirements are clear at the outset.
IEC 61511 lists more than 30 elements that make up a good safety requirements specification (SRS). This can be turned into a checklist or template
Proof testing strategy must be decided
Proof testing is something that few companies think of at this stage. However, it is crucial to ask the question early in the design. If testing is going to be completed off-line, then this step can be a very simple check. On the other hand, if the end applicaiton requires online testing then get ready to make this an early focus which may drive different design decisions.
The supplier must be capable of meeting systematic failure capability
Perhaps too much focus has been attributed to PFD/PFH calculations, and not enough to the systematic capability of equipment. But what is systematic capability and how do you check for it?
In IEC 61508:2010, systematic capability "...applies to an element with respect to its confidence
that the systematic safety integrity meets the requirements of the specified safety integrity
But what is systematic capability and how do you check for it?
Put more approachably, to meet a target SIL, you should check that equipment comes from a reputable supplier with a quality system. The supplier must also provide evidence of functional safety management practices if they are making any SIL capability claims.
A great source of information about supplier maturity with functional safety and SIL is to check if their equipment has a "safety manual" which meets the requirements of IEC 61508-2 Annex D. Item D2.3 in Annex D requires a statement on systematic capability and instructions and constraints for use.
Architecture must meet the hardware fault tolerance (HFT) requirements
As a simple metaphor, fixing a door to a doorframe involves one or more hinges. Most entries are retained perfectly well with two well-designed straps, but it is also possible to use three, four or even more. However, there is a law of "diminishing returns" which governs the decision to keep adding redundant devices. The same is true of SIF designs; it becomes unnecessary, or even counter-productive, to keep adding redundancy for the same function.
What many people do not appreciate is that fault tolerant designs are configurable in different ways. It is not enough to know how many devices you plan to use, but also how they will be arranged. In the case of our door metaphor, it will be important to space the hinges correctly to get the best distribution of weight in case of a single hinge failure. With a SIF, it is critical to know how sensors are voted, and how final element valves are physically piped.
IEC 61511 requires a check for Hardware Fault Tolerance (HFT), which is intended to ensure that sufficient safety integrity is built-in to the SIF design.
The SIF must meet the PFD/PFH requirement
At the outset, let's be clear that Probability of Failure on Demand (PFD) or Probability of Failure per Hour (PFH) calculations are far from an exact science. Just employing numbers does not make the results accurate, especially if the assumptions are incomplete or the underlying data is flawed. Calculations should be realistic and as conservative as possible. With those thoughts in mind, it is still a requirement to meet the PFD/PFH numbers with achieveable proof test intervals.