Functional Safety 2016

InstMC FS2016 (Rev 3.0)

Page

Nicol Instrument Engineering Limited

applied during bypassing which describe how the bypasses will be controlled and subsequently

cleared.

Has new sub-clauses for Application Program safety requirements with this either located in the SRS

or in a separate document (e.g., an application program requirements specification (APRS)).

The input for each SIS subsystem shall include; the specified safety requirements of each SIF (e.g.

sensor voting, etc.), architecture requirements (e.g. limitations and constraints of the hardware and

embedded software), and any requirements of safety planning.

Like an SRS the Application Program safety requirements specification shall be sufficiently detailed to

allow the design and implementation to achieve the required functional safety, and allows assessing

through a FSA. For this consideration should be given to; the SIL of the SIF(s), any real-time

performance parameter (e.g. CPU capacity, network bandwidth, acceptable real time performance in

the presence of faults, etc.), any sequencing and time delays, equipment and operator interfaces and

their operability, all relevant modes of operation, action to be taken when there is bad process

variable (e.g. sensor value out of range, excessive range of change, frozen value), etc.

The structure for the APRS includes describing the intent and approach underpinning the safety

requirements, is clear and understandable to those who will utilize the document at any phase of the

safety life-cycle, includes using terminology and descriptions which are unambiguous and understood

by the users (e.g., plant operators, maintenance personnel), can be verified, and is traceable back

through all deliverables (e.g. detailed design documents, the SRS, the H&RA) that set the requirements

for SIFs.

Clause 11:

SIS design and engineering

This edition adds PFH and Application Program as appropriate into this Clause. Such as to design one

or multiple SIS to provide the SIF…... (e.g., SIL, associated risk reduction, PFD and /or PFH), the SIS is

to implement both SIFs and non-SIFs then all the hardware, embedded software and application pro-

gram……., Etc.

Clarification on designing interfaces and separation with the BPCS, such that a BPCS device shall not

be used by the SIS if a failure of the device may result in both a demand or a dangerous failure of the

SIF, unless an analysis has been carried out.

Design of the SIS requires including providing the necessary resilience against the identified security

risks.

A safety manual covering the intended configurations of the devices and the intended operating en-

vironment is required for operation, maintenance, fault detection associated with the SIS.

There are changes to requirements for hardware fault tolerance (HFT) with Table 6 updated, and is

based on route 2H of IEC 61508-2:2010. SIL 2 is now split with ‘low demand mode’ at HFT of 0 and

‘high and continuous demand modes’ remaining at HFT of 1, SIL 3 any mode HFT is reduced from 2 to

1, and SIL 4 any mode added and assigned HFT of 2.

There is clarification on when faults may be excluded, and any fault exclusions must be justified and

documented.

The HFT specified in Table 6 may be reduced for SIS or SIS subsystem that does not use FVL or LVL

programmable devices and if the minimum HFT specified would result in additional failures and lead

to decreased overall process safety. If the fault tolerance is zero then justification is required, and

requires providing evidence that the related dangerous failure modes can be excluded.