InstMC FS2016 (Rev 3.0)
Page
6
of
10
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.