Table of Contents Table of Contents
Previous Page  64 / 975 Next Page
Information
Show Menu
Previous Page 64 / 975 Next Page
Page Background

SCHEME 1 - FULL LIFECYCLE IMPLEMENTATION BUT WITH RETENTION OF ALL API PROTECTION

This approach is in many ways the easiest to understand although it involves the most work. The

project was executed just as if it is a regulatory IEC61511 project. This included the development of

a lifecycle implementation plan, competency assessments, lifecycle verification, SIS validation and

functional safety assessments. The IL assessment and validation was carried out for safety,

environment and asset but for this project only safety SIF’s were considered for further elements of

the lifecycle such as safety requirements specification (SRS), software code reviews and functional

safety assessment (FSA).

Because the regulatory basis was the proscriptive standard, all functions related to compliance with

that standard were retained in the SIS even though many could have been removed completely or

transferred to the DCS on the basis of the SIL assessment. There may even be a little more

equipment for any cases where the SIL assessment showed a need for a high SIL design. Similarly,

test intervals must remain compliant with the API standard even though in all cases they could have

been increased (sometimes significantly) under IEC61511. It could be thought that his design results

in an ultra-safe installation, but in my view this is incorrect. The SIS is some three or four times larger

than it would need to be under IEC61511 and so results in complexity that in itself can result is

increased risk in areas such as testing and spurious trips. Additionally, the high test frequency will

further increase the chance of spurious trips and place people in the hazard zone more often than

needed. However, at least the equipment quality needed to meet performance standards and (very

importantly), systematic issues were addressed for safety functions.

Assuming that SIF loop components will need to comply with IEC61511 related to their SIL rating,

this needs to be considered when specifying equipment at the early stages of the project, rather

than simply purchasing on a lowest-cost basis.

Since the full lifecycle is implemented, competency requirements for the project team and major

package suppliers will need to be enforced.

The addition of the full lifecycle requirements will add man-hours to the project scope and the

formal testing and validation related to the later stages could impact schedule. In particular, these

schedule implications must be considered from the beginning and understood by project

management.

SCHEME 2 - API DESIGN BUT WITH SIL ASSESSMENT AND VALIDATION

This is the most common form of hybrid. The extent of IEC61511 lifecycle implementation ends at

SIL validation (and maybe with the production of an SRS).

There are two main benefits resulting from carrying out the SIL assessment and validation. Firstly,

for SIL-rated SIF’s a performance requirement is specified for the equipment, which is of course a

good thing, and assuming the design must meet the architectural requirements of IEC61511 then

fault tolerance is provided where needed for high-SIL SIF’s.

This design, as with the Scheme 1 approach, results in a “full size” SIS, just as would be required for

the base regulatory design. The more onerous testing frequency and its associated potential to