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

Functional Safety 2014

4

th

– 5

th

November 2014

Copyright © 2014 by Cenbee Bullock PFS Consulting Ltd

Page 12 of 14

For LVL and FVL, the design, development and verification of the software should follow the

recommended structures and procedures as stated in IEC61508 part 3 in order to demonstrate the

systematic capability of the system.

Fig 6 illustrates the steps and procedures for the design, development and verification of the software

with reference to IEC61508-3. All steps shown should be followed in order to demonstrate the

systematic capability of the software. The Safety Requirement Specification (SRS) for application

software should be written for the specific project requirement for the software and be designed and

developed accordingly. For example, when joining two certified library function blocks into one

specific function, the joining procedure should be written in the application software SRS for the

specific project. The testing methodology should be written in the Safety Manual.

The PE System supplier should provide a Safety Manual for the programmable software language with

full instructions for installation, testing and modification and also state the systematic capability. Any

modification or change to an LVL library function block should be confirmed and verified against

IEC61508-3. Any new function block should be written according to the instructions in the safety

manual.

For FVL, certified software tools (i.e. utility software) should be used for software verification. It

should be reviewed and approved by a suitably qualified independent assessor. All steps and

procedures for the design and development or any modification during verification and testing should

be recorded with systematic traceability.

A Programmable Electronic system has the highest potential for systematic failures compared to

Electro-Mechanical systems. They can be caused by widespread factors: environmental influences,

human errors, software bugs and data communication error etc. The V-model provides the most

effective techniques and measures to demonstrate the systematic capability. All PE system suppliers

are required to provide evidence of their compliance to these procedures.

The above procedures demonstrate the importance of using a systematic approach throughout the

safety lifecycle and good control documentation system is vital for the process.

Measures of Human Reliability

ISA TR84.00.02-2002 states that systematic failures caused by human error can take place in any phase:

design, installation, proof test and operation in by-pass mode. This can be represented

mathematically by:

Psys-human error = Pdesign error + Pinstallation + Pproof test error + Pbypassed

The US Process Improvement Institute (PII) produced a Standardised Plant Analysis Risk Model (SPAR-

H) based on work by the US Nuclear Regulatory Commission (NUREG). The model enabled analysis of

human reliability which found various reasons for possible human errors in a given task, including:

insufficient time, stress, fitness for duty, complexity of the design, experience, training, competence,

communication, procedures, work supervision, work environment and the number of personnel.