187 / 1145
FUNCTIONAL SAFETY MANAGEMENT WITHIN THE CONSTRAINTS OF A REAL-LIFE MAJOR PROJECT.
1) INTRODUCTION
The author has significant experience of implementing IEC 61511 in major project environments,
including acting as the project Functional Safety Manager for a current UK North Sea project. This
paper will identify those areas of the standard which most typically present project implementation
problems, and show how good FS management can minimise their impact and maximise net risk
reduction.
IEC 61511 is a formal standard which describes a set of processes that are intended to reduce
process-related risk, including systematic failure risk, to a tolerable level. Many standards define
specific requirements for equipment and so are relatively straightforward to implement such as by
their inclusion in equipment specifications. IEC 61511 defines (sometimes complex) processes to be
carried out by real people, with all their human shortcomings, throughout the complete SIS lifecycle.
This makes correct implementation hard to achieve. It changes how projects are executed, not
simply the equipment that is used.
Two types of causes of practical problems are challenges presented by the standards in a real project
environment, and misconceptions by people. These lead to resulting implementation shortcomings.
Let us now look at some of these.
2) IMPLEMENTATION CHALLENGES
a) Complexity
IEC61511 describes and in some places defines requirements for the implementation of processes
for manging process-related safety and environmental risks and bringing them to a tolerable level. It
involves all stages of both an EPC project and the operating life of the installation. It is not surprising
that the standard is far-reaching and in some places complex in its detail, even though it’s
fundamental concept is simple. This complexity is further aggravated by the many references in
IEC61511 back to IEC61508, so implementing IEC61511 means de-facto some understanding of
IEC61508, a much larger and more detailed document. For most people involved in any stage of the
process, they will only have an interest in a small section of the lifecycle (e.g. HAZOP, ICSS
programming, operational testing etc.), and will not see a true picture of where their input fits into
the overall risk reduction process. This can limit their effectiveness.
b) Difficulty of conveying and understanding what the systematic risks are
Experience shows that systematic failures have been the cause of most of the major incidents over
the past 20 years or more. Rarely does the random failure of a component in a device lead to
disaster, more likely it is a systematic issue such as software, operational errors, wrongly specified