CONTRACT RESEARCH REPORT 373/2001 - HSE: … · CONTRACT RESEARCH REPORT 373/2001. HSE ......

HSEHealth & Safety

Executive

Proposed framework for addressinghuman factors in IEC 61508

Prepared byAmey VECTRA Limited

for the Health and Safety Executive

CONTRACT RESEARCH REPORT

373/2001

HSEHealth & Safety

Executive

Proposed framework for addressinghuman factors in IEC 61508

Michael Carey BSc, MErgSAmey VECTRA Limited

Europa House301 Europa BoulevardGemini Business Park

WestbrookWarrington

WA5 7YQUnited Kingdom

IEC 61508 is an international standard developed to provide a basis for conformity assessment on theapplication of electrical, electronic and programmable electronic (E/E/PE) safety-related systems. Thestandard recognises the need to address 'human factors', but provides minimal guidance as to whatthis entails. This report explores various issues that are involved in addressing human factors underIEC 61508. Firstly, existing human factors requirements within IEC 61508 are reviewed. Considerationis then given to a range of applications of E/E/PE systems in safety-related application to drawconclusions concerning the relationship between Safety Integrity Levels and required human factorseffort. A proposed framework is introduced with the purpose of relating required human factorsactivities and assurance processes to types of safety-related applications. The framework addressesways in which requirements for human factors may vary according to the integrity levels of thefunctions provided by a safety-related system. Finally, questions raised by the framework arehighlighted and discussed to stimulate debate prior to further development and application.

This report and the work it describes were funded by the Health and Safety Executive (HSE). Itscontents, including any opinions and/or conclusions expressed, are those of the author alone and donot necessarily reflect HSE policy.

HSE BOOKS

ii

© Crown copyright 2001Applications for reproduction should be made in writing to:Copyright Unit, Her Majesty’s Stationery Office,St Clements House, 2-16 Colegate, Norwich NR3 1BQ

First published 2001

ISBN 0 7176 2114 6

All rights reserved. No part of this publication may bereproduced, stored in a retrieval system, or transmittedin any form or by any means (electronic, mechanical,photocopying, recording or otherwise) without the priorwritten permission of the copyright owner.

iii

ACKNOWLEDGEMENTS

In developing the ideas in this report, valuable assistance has been provided by the HSE project officers, Mr Simon Brown and Mr Sarabjit Purewal. They have provided the author with assistance in keeping the framework simple and avoiding allowing the complexities of IEC 61508 to obscure some of the more obvious results of this research. Further thanks are due to the organising committee of the annual IEE Vacation School on Safety-Critical Systems and particularly Mr Ron Bell. They have continued to tolerate the author's regular lectures on human factors and have been prepared to debate some of the issues touched upon within this report, often into the early hours. Finally, much encouragement was provided by the late Dr Matthew Bransby during the progress of this research. He would have enthusiastically reviewed this report and no doubt had some valuable and incisive views on its content.

v

FOREWORD

This report is a result of recently commissioned research into the development of a framework for addressing human factors in electrical, electronic and programmable electronic (E/E/PE) safety-related systems in the context of IEC 61508. The report is the opinion of the author alone and does not necessarily represent HSE policy. However, in situations where the human has an impact on the safety integrity of the E/E/PE safety-related system, the framework proposed in this report is intended to be the basis for further development work in this area. HSE invites comments on the practicability and effectiveness of the recommended approach and on any other aspect of human factor issues impacting on E/E/PE safety-related systems that is not considered to be addressed in this report. Please send your comments by 16 November 2001 to: Sarabjit Purewal Technology Division Electrical and Control Systems Unit Magdalen House Stanley Precinct Bootle Merseyside L20 3QZ

vii

CONTENTS

Acknowledgements iii

Foreword v

Contents vii

Executive Summary ix

1 Introduction 1

2 Objectives 3

3 Scope 5

4 Approach 7 4.1 Task 1: Identify Human Factors Requirements in IEC 61508 7 4.2 Task 2: Outline Current Human Factors Techniques 7 4.3 Task 3: Construct Outline Framework 7 4.4 Task 4: Apply to Sample Application Areas and Develop Framework 7

5 Human Factors in IEC 61508 9 5.1 Overview of the Standard 9 5.2 References to Human Factors in IEC 61508 9 5.3 Coverage of Human Factors Issues in the Standard 10 5.4 System Architectures Addressed by IEC 61508 11 5.5 Implications for Human Factors in Applying IEC 61508 14

6 Overview of Human Factors Methods 17 6.1 Background to Human Factors Methods 17 6.2 Key Elements of Human Factors Approaches 18 6.3 Human Factors Activities in the Context of the Safety Lifecycle 20 6.4 Human Factors Standards 20

7 Human Factors Requirements in Safety-Related System Design 23 7.1 Analysis of Typical Architectures 23 7.2 Summary of Key Principles and Requirements 30

8 Proposed Framework 33 8.1 Inclusion within Hazard and Risk Analysis 33 8.2 Basis for Specifying Human Factors Design Requirements 36 8.3 Proposed Framework for Human Factors Design Requirements 37 8.4 Limitations and Areas for Further Development 43

9 Conclusions 47

viii

10 References 49

APPENDIX A: References to Human Factors in IEC 61508 53 Part 1: General Requirements 53 Part 2: Requirements for Electrical/Electronic/Programmable Electronic Safety-Related Systems 54 Part 3: Software Requirements 56 Part 4: Definitions and Abbreviations 56 Part 5: Examples of methods for the determination of safety integrity levels 57 Part 6: Guidelines on the Application of Parts 2 and 3 58 Part 7: Overview of Techniques and Measures 59

APPENDIX B: Mapping of Human Factors Processes to Safety Lifecycle 61

APPENDIX C: Descriptions of Human Factors Activities 67

APPENDIX D: Examples of Human Factors Standards 75

ix

EXECUTIVE SUMMARY

Introduction IEC 61508 is an international standard developed to provide a basis for conformity assessment on the application of electrical/electronic/programmable electronic (E/E/PE) safety-related systems. The majority of the technical content of the standard is concerned with the claims that can be made related to hardware and software integrity. Within the standard there are a significant number of direct and inferred references to human factors. However, there is limited detailed guidance in the standard regarding how to address human factors and it is clear that for some systems, important human factors aspects may be inadequately considered or managed. The objective of this project was to develop a framework that can describe the relationship between the various stages in IEC 61508 and human factors activities. This initial piece of work is intended to provide the initial basis for discussion. Relationship of human factors to safety related systems As a key part of this project, consideration has been given to a range of applications of E/E/PE systems in safety-related applications. This has highlighted the diversity of ways in which human factors requirements map on to various E/E/PE systems in different industries and contexts. A number of conclusions were drawn from this: • Determination of the safety integrity level (SIL) for an E/E/PE system requires

careful consideration of not only of the direct risk reduction functions it is providing, but also those risk reduction functions performed by staff that interact with it. This requires addressing in the Hazard and Risk Analysis step of the IEC 61508 lifecycle;

• Having determined the safety integrity of the E/E/PE system in this way, it can be

shown that the effort that needs to be placed into operations and maintenance human factors should be greater as the SIL level increases;

• The types of human factors issues that need to be addressed vary between the classes

of systems discussed. The framework, therefore, cannot be specific in terms of the technology or aspects of human factors design.

Proposed framework Based on the above analysis, a framework has been proposed for addressing Human Factors under IEC 61508. This breaks down into two main elements: • Incorporation of human tasks and errors into the Hazard and Risk Assessment

process; • Use of the tables to define the human factors requirements for a given safety integrity

level.

x

Addressing human factors within the Hazard and Risk Analysis processes will require the adoption of methods of hazard identification and risk analysis that encourage examination of a wide range of degraded and emergency conditions. It should be noted that this requires an additional set of assessments alongside the normal equipment integrity assessments performed under IEC 61508. Not only is the integrity of the equipment hardware/software being assessed from the perspective of its inherent reliability, but the integrity of associated human safety functions are being assessed in order to identify what assurance is required for the human factors aspects of the overall system. A set of tables has been generated to illustrate how human factors design requirements might be linked to E/E/PE Safety Integrity Levels. These are illustrative examples only and require further development and validation. Within any future supporting documentation describing the framework, it is expected that the requirements would be amplified and explained. To provide guidance, it would be possible to describe example techniques that might be applied to meet the requirements at each safety integrity level. Further ways of presenting such requirements are open to exploration. Points for Debate The project has left some unresolved issues that are recognised to require further investigation. These, in summary, are as follows: ♦ the inclusion of 'human safety functions' into the assessments under IEC 61508 extends

the current common applied scope of application of the standard. It is not clear whether including non E/E/PE safety functions will be readily accepted in industrial practice;

♦ human operators often make use of multiple sources of information and means of communication. How can human factors integrity requirements be suitably apportioned between such systems?

♦ in many cases, the operator may be acting as a source of a hazard and as a means of recovery. This poses questions related to human error dependency.

Finally, one function of the human operator is to deal with unpredicted or unlikely events when they occur. Such events are by their nature have an extremely low likelihood of occurrence. Any framework based on risk reduction would require that little effort should be put into supporting such recovery actions. Yet, these can require the greatest effort in terms of human factors to aid human detection and diagnosis. Clearly, a risk-based approach cannot provide the full answer in such circumstances. The framework presented in this report is one possible means of linking human factors requirements in system design to the safety integrity of E/E/PE systems. This is now offered up for discussion and debate.

1

1 INTRODUCTION

IEC 61508 is an international standard developed to provide a basis for conformity assessment on the application of electrical/electronic/programmable electronic (E/E/PE) safety-related systems. It is designed to be non-sector specific with the intention that it will be used progressively as the basis for developing sector-specific standards. With the standard having now been published, IEC 61508 is likely to play an increasingly important role in setting out the framework for application of E/E/PE safety-related systems across a diverse range of industrial sectors. The standard recognises that the required level of safety for a particular system may be achieved through a number of diverse means (not just through E/E/PE systems) and necessitates a full lifecycle approach that covers specification, design, installation, testing, commissioning, operation, maintenance and modification/removal. IEC 61508 concerns itself with the overall level of safety that can be achieved within a given application context, including normal, degraded and emergency conditions. The majority of the technical content of the standard is concerned with the claims that can be made related to hardware and software integrity. However, throughout the lifecycle process, there are requirements to take into account human factors1. Yet the actual guidance provided in the standard regarding how to address human factors is limited. Without more explicit guidance, it is clear that for some systems, important human factors aspects of E/E/PE safety-related systems may be inadequately considered or managed.

1 Whilst it is recognised that there is human involvement in specifying, designing and delivering E/E/PE systems, the usage of the term 'human factors' in this report (and in IEC 61508) relates to those who will operate and maintain the delivered system.

3

2 OBJECTIVES

The objective of this project is to develop a framework that can describe the relationship between the parts in IEC 61508 and the required human factors design and development activities. To be successful, it is judged that this framework needs to: • Provide a means of understanding how any particular E/E/PE system may directly or

indirectly impact upon human activities which are key to functional safety; • Clearly identify any claims that are implicitly or explicitly made on human

performance in the design of the E/E/PE safety-related system; • Define what steps need to be taken to adequately address human factors (cross-

referencing to existing standards and established approaches wherever possible). • Enable the level of human factors effort to be defined in accordance with the safety

integrity of the related human roles within the system of concern; • Provide an approach which is generic (industry independent).

5

3 SCOPE

This initial piece of work is intended to provide the initial basis for discussion that may lead to further more detailed development work related to IEC 61508 and human factors. This necessitated some limitations to the scope of work as follows: a) The primary focus is on the human factors issues related to the 'operation' of E/E/PE

safety-related systems and of other technology safety and control systems; b) Limited consideration is given to the 'maintenance' of E/E/PE safety-related systems; c) The scope and nature of the human factors issues are likely to vary widely between

application sectors and types of control philosophy. The development of the framework involved examining a number of sample application sectors to identify the scope and range of possible issues to be considered. Since this involved a selected 'sample', there is a potential that the resulting framework will not be totally representative;

d) The focus of this Report is on the development of a clear framework rather than on the detailing of all related standards and guidance;

7

4 APPROACH

This research was conducted through following a series of progressive development tasks. At the completion of each task, the current thinking was presented for discussion with the HSE technical monitor. The tasks were as follows:

4.1 TASK 1: IDENTIFY HUMAN FACTORS REQUIREMENTS IN IEC 61508

This initial task identified the specific human factors requirements embodied within both the published parts of IEC 61508 and within the then current versions of the unpublished draft parts. The coverage of the stated requirements was then explored further and discussed. Apart from defining the specific requirements related to human factors in IEC 61508, this task examined the wider implications of functional safety analysis as required by the standard. Many human factors issues will require consideration as part of this wider analysis in order to identify in turn the safety functions that need to be addressed by E/E/PE safety-related systems. This task was intended to enable an understanding to be developed of those aspects of human factors that may directly affect the design of the safety-related system and those that indirectly may make a demand upon its functionality.

4.2 TASK 2: OUTLINE CURRENT HUMAN FACTORS TECHNIQUES

This task set out to provide an overview of the range of techniques that are specified within human factors and how they might be mapped on to the safety lifecycle of IEC 61508. This is intended to act as an introduction to human factors approaches and to assist in identifying the relationship between the safety lifecycle of IEC 61508 and human factors development lifecycles.

4.3 TASK 3: CONSTRUCT OUTLINE FRAMEWORK

A proposal was then developed for the type of framework that may be applied with regard to human factors under IEC 61508. This suggested a manner by which SIL levels might be mapped on to requirements for human factors techniques.

4.4 TASK 4: APPLY TO SAMPLE APPLICATION AREAS AND DEVELOP FRAMEWORK

Further consideration of the proposed outline framework highlighted a number of problems of definition and application. These were explored by looking at specific example applications from a range of industrial domains. As a result some agreed principles were defined, though there remains some key areas for further discussion. This report summarises the key outputs from the above tasks and then discusses the proposed framework for addressing human factors under IEC 61508.

9

5 HUMAN FACTORS IN IEC 61508

5.1 OVERVIEW OF THE STANDARD

The structure of the standard is shown in Table 1. Part 1 outlines the overall process required under the standard, from concept through to operation. A key part of this approach is the performance of a hazard and risk analysis to determine the safety integrity requirements for E/E/PE safety-related systems. This aspect is supported by Part 5, that provides guidance on risk based techniques for use in determining safety integrity levels.

Table 1 Parts of IEC 61508

Part No. Title

1 General Requirements

2 Requirements for E/E/PE Safety-Related Systems

3 Software Requirements

4 Definitions and Abbreviations

5 Examples of Methods for the Determination of Safety Integrity Levels

6 Guidelines on the application of Parts 2 and 3

7 Overview of Techniques and Measures Parts 2 & 3 provide specific requirements for hardware and software (respectively) in order to meet the required SIL level. Parts 6 and 7 are intended to provide guidelines and techniques to support the application of Parts 2 & 3 Part 4 supports the whole standard by providing definitions and abbreviations.

5.2 REFERENCES TO HUMAN FACTORS IN IEC 61508

A review of the detailed text of the standard has been carried out. All relevant clauses are included in a table within an appendix to this report (Appendix A). It should be noted when referring to this table that: a) The page numbers refer to the references given on those pages presented in the

English language; b) The text from the standard has sometimes been paraphrased for the purposes of

clarity and brevity; c) A wide definition of human factors has been adopted, including references to

operational error, user interfaces, operations/maintenance procedures and training and human error during system specification and design. The scope of this report covers only the first three of these areas. The references to human error during system design are only provided for the sake of completeness.

10

References to the text in the standard are shown throughout this Section in square brackets (e.g. [1/7]) and are based upon the numbering system given in the tables in Appendix A.

5.3 COVERAGE OF HUMAN FACTORS ISSUES IN THE STANDARD

As can be seen from the tables in Appendix A, there are a significant number of direct and inferred references to human factors within the standard. Table 2 summarises the main requirements based on the stages in the safety lifecycle (stages not shown have no specific stated human factors requirement). This demonstrates that IEC 61508 make clear requirements on various aspects of human factors. Of particular relevance are: • The inclusion of human failure and recovery actions within the hazard and risk

analysis step; • Appropriate planning/execution of operations and maintenance procedures; • Aspects of user interface design.

Table 2 Human factors requirements explicitly specified in IEC 61508

Stage Requirement

2. Overall Scope Definition • Must identify accident-initiating events, including procedural faults and human error [1/9]

3 Hazard and Risk Analysis • To include all 'relevant' human factors issues [1/11, 4/2, 5/3, 5/5, 6/3]

• To cover reasonably foreseeable misuse [1/10, 4/1]

• Particular attention to be given to abnormal or infrequent modes of operation [1/10,1/11]

• Any credit taken for operational constraints or human intervention to be detailed (and documented) [1/12, 5/2, 5/4]

5 Safety Requirements Allocation • In determining the type of risk reduction technology to be applied, consideration should be given to the availability of skills and resources for operation and maintenance in the target application [1/13]

6 Overall Operation and Maintenance Planning

• Routine maintenance tasks and scope of maintenance activities to be specified [1/14, 2/6, 2/7]

• Required operating rules to be specified during normal, degraded, abnormal and emergency states of the system [1/14, 2/5]

7 Overall Safety Validation Planning • No specific requirement stated though intended to be included within the scope of this activity [1/8]

11

Stage Requirement

9 E/E/PE Safety-Related Systems: Realization

• Safety requirements shall identify operator interfaces and these shall be addressed during design [2/1, 2/2, 2/7, 3/1, 6/2]

• The E/E/PE design shall be tolerant against mistakes made by the operator of the equipment under control [2/4, 2/10, 2/12, 3/2, 7/6]

• The design of the E/E/PE safety-related systems shall take into account human capabilities and limitations and be suitable for the actions assigned to operators and maintenance staff [2/5, 7/2, 7/3]

• The design of all interfaces shall follow good human factors practice and shall accommodate the likely level of training or awareness of operators (to include members of the public for consumer items) [2/5, 7/4, 7/9]

• All E/E/PES operation and maintenance procedures shall be validated by test and/or analysis [1/8]

• The assessment of common mode failure shall taken into account some human factors issues [6/4, 6/5]

14 Overall Operation, Maintenance and Repair

• Implementation of procedures [1/16]

5.4 SYSTEM ARCHITECTURES ADDRESSED BY IEC 61508

Various clauses within the standard indicate that a 'person can form part of a safety-related system' [1/1, 4/3, 4/4]. The examples given in Clause 3.4.1 of Part 4 [4/4] describe safety-related systems where: • A person is using information from a programmable electronic device to perform a

safety function; • A human-initiated safety action is performed through a programmable electronic

device. The examples given in IEC 61508 illustrate that the 'system' need not necessarily be related to the real-time control of equipment. The programmable electronic systems could be acting as 'an aid' to a human operator in performing a safety-related function, as a source of information or as a communications device. However, whilst permissive of other architectures, the predominant architecture implied in the text throughout the body of the standard is related to real-time control. The following Sections illustrate the pro-typical architecture implied within IEC 61508 and one example of another architecture where an E/E/PE system is used in a safety-related application. The relationships of E/E/PE systems to operators and maintainers is discussed further in Section 7.1.

12

5.4.1 Typical system architecture addressed under IEC 61508

Figure 1 provides a typical example of the architecture that is dominant throughout IEC 61508. The E/E/PE safety-related system is utilised within a control environment (note: this need not, of course, be a process control environment). The hazards and risks are generated by the equipment under control (EUC), malfunctions of the EUC control system, human error or other reasonably foreseeable events. Taking into account any human recovery or procedural controls, the risk is assessed. From this, it is possible to determine the level of risk reduction required to achieve the target level of safety. The standard recognises three types of safety measures that may be employed; E/E/PE safety-related systems, other technology safety-related systems (e.g. pneumatic, mechanical) or external risk reduction facilities (e.g. bunds, passive fire protection). For the E/E/PE safety-related systems, the standard then clearly defines the specification, design and implementation requirements to be able to claim a specified level of risk reduction.

ProtectionSystem

ControlSystem

Operator

Equipment Under Control

OperatorInterface Operator

Interface

Figure 1 Typical industrial control architecture

It can be seen that the human operator in this 'system' is very much outside of the boundary of the 'safety-related' part of the system (assuming that the control system is not being claimed as a safety-related system in the terms used in the standard). The human factor can, therefore, be treated in the following manner:

• Any potential operational errors are captured as initiating or contributory events for

inclusion in the hazard and risk analysis. The operator interface of the control system may influence the likelihood of such errors, but this can be assessed as a given, independently of the safety-related protection systems;

• Recovery actions or procedural controls are also likely to be predominantly effected

through the control system and so such 'human safety functions' are included as assumptions in estimating the EUC baseline risk level;

13

• The required level of risk reduction is achieved through the allocation of safety functions to one or more physical systems, including E/E/PE safety-related systems;

• As a 'protection system', the interface with operational staff is likely to be limited in

scope. Therefore, most of the specific methods that are recommended in IEC 61508 focus on preventing the operator from making inputs that could defeat the operation of the E/E/PE system and on ensuring that any user interfaces are simple and limited in scope;

• Effort is required in ensuring that operations and maintenance procedures are defined

up front and then implemented. There is again an emphasis on protecting the E/E/PE system from inadequate maintenance or mal-operation and ensuring that any operating assumptions (e.g. operational restrictions when protection system is being maintained or tested) are carried forward into practice.

5.4.2 Alternative architectures

The principles embodied in IEC 61508 are required to be used in a different manner when applied to other forms of safety-related system. Figure 2 is an example of the use of programmable electronic systems in the management of crowds. In this case, one safety function of this system may be 'to issue instructions to crowds to prevent the density of crowds in a part of the venue reaching a dangerous level'. The implications for the application of the principles in IEC 61508 for such a situation are as follows:

• The risk of the overcrowding hazard would need to be established independently of

the 'safety-related system'. This would therefore consider the frequency of crowd flows exceeding a criterion safety level when they are allowed to enter the venue in an uncontrolled manner;

• The required level of risk reduction would define the safety requirements for the

specified safety function; • In determining the required safety integrity of each of the components of this system,

it would be necessary to determine what would be an acceptable failure rate for each of the components in the system. This would include both complete failure of the CCTV and PA system, as well as failure modes that might cause the wrong picture to be shown or the wrong PA speaker to be selected. The likelihood of failure of the human operator would also need to be determined, which could include a number of contributory error mechanisms. It would need to be demonstrated that the combined system could provide the required level of risk reduction for the safety function concerned. The hardware aspects of the CCTV and PA systems would need to assessed from first principles (or from historical data), since the various tables that are provided within the standard tend to relate to sensors and actuator logic in industrial control systems. Any software aspects could be guided by Part 3 of the standard.

14

Operator

��

��

User Interface(input devices)User Interface

(monitors)

CCTVSystem Public

AddressSystem

Figure 2 Alternative control architecture

• The user interface aspects of the two electronic sub-systems in this case could be critical to the overall level of safety integrity that can be achieved. The quality of the user interfaces could have a direct impact upon operator performance and hence on the overall reliability of the safety-related system. IEC 61508 provides some guidance on what type of interface features are required in accordance with the SIL level of the safety-related system [2/10, 2/11, 2/12], but by inspection it is evident that the tables would give little assistance in this case. 'User friendliness' is mandatory for all SIL levels, but no guidance is provided on how this might be achieved or verified.

• There would still be a need for operations and maintenance procedures to be defined

in advance. In general, the operations and maintenance planning aspect of IEC 61508 has universal application.

5.5 IMPLICATIONS FOR HUMAN FACTORS IN APPLYING IEC 61508

The two types of architectures described above appear to make very different demands upon the consideration of human factors in the development of safety-related systems. Where the E/E/PE system is largely acting as an autonomous protection system, the standard allows operator performance to be treated as a largely 'external demand'. Guidance is given to limit the impact of the operator upon the protection system and to minimise the impact of the system upon the operator. In many other contexts, however, people will form part of safety-related systems, and it is no longer possible to view the operator as an external demand. The performance of the overall system may have a high dependence upon the quality of the operator interface and the limited guidance and requirements within IEC 61508 would be inadequate to provide the level of assurance that is necessary.

15

In reality, even in the context of protection systems, the design of the operator interface may have an impact upon safety that has not been accounted for. The classic example of this is where the protection system includes the generation of alarms. An assumption may be made that the operator would detect certain critical alarms that relate to the functioning of the protection system and take appropriate remedial action (e.g. activate a manual shutdown). However, if the alarm generation rate is high, the user interface sub-optimal and the demand occurs alongside other demands upon the operator's attention (from the initiating event), the required response may be delayed or not take place at all. Little effective claim could be made for operator recovery of a protection system failure in such circumstances. Anticipating such problems requires a structured approach to be taken to human factors analysis. This needs to define what techniques should be applied according to the level of criticality of the user interface. Ideally, this would be built into the existing steps of IEC 61508 as additional, compatible requirements. The key issue that needs to be resolved, however, is to what extent the criticality of the user interface can be determined by the criticality of the system concerned (i.e. its SIL level). This is a point returned to later in Section 7.

17

6 OVERVIEW OF HUMAN FACTORS METHODS

6.1 BACKGROUND TO HUMAN FACTORS METHODS

This section provides an overview of human factors activities and methods that might be applied in the development of a safety-related system. Illustrative details are provided for a selected set of proven and widely used methods within the context of the system development lifecycle. This is intended to be an illustrative rather than a complete or exhaustive list of methods. There are four particular areas of closely-related, overlapping sets of human factors discipline areas that are relevant to the requirements of IEC 61508: • Human reliability assessment (HRA) processes, that enable the contribution of human

error to EUC risk to be estimated; • Human-computer interaction (HCI) or, more recently, Usability Engineering (UE)

processes, that focus in detail on the user interface element of systems. • Human factors engineering (HFE) processes, that contribute at the systems level to

the design of equipment, working environments and user tasks; • Human factors integration (HFI) processes include documentary and organisational

structures for integrating HFE into project processes; The combination of these activities are necessary to address the scope of the requirements of IEC 61508. It should be noted that they have their roots in slightly different background discipline areas within human factors. HFE and UE are the most closely related, with HFE existing before the widespread growth of computing applications, providing the background to a number of current UE approaches. HRA has been developed within the domain of Safety and Reliability Assessment applied in the high hazard industries. HFE and UE (in particular) are viewed as part of software and project engineering (not necessarily of safety related systems). There is a need under IEC 61508 to bring these together into a coherent framework. HFI may provide some of the tools required, with its focus on specifying the mechanisms to build human factors into project programmes. Human factors as an overall discipline covers a wide range of areas related to integration of humans within work systems. Whilst there is a body of core activities that, it can be argued, are specifically 'human factors techniques', there are also many techniques/methods that are specified/employed within human factors processes that belong to or are applied by other distinctive disciplines. For example, human factors specialists will get involved with person specification, job design, personnel selection criteria and training development. This can be necessary to ensure that the needs of the technology are addressed in the calibre and skill levels of its users ('fitting the person to the job'). Personnel management or human resources disciplines will normally own such parts of the system development process. Similarly, human factors analysts may be involved in procedures development, establishing the process to be followed in developing procedures, the types of procedure, their content and format. Again, others may own the specific detailed knowledge and techniques in this area, but the human factors objective is to ensure that the procedures chosen are compatible with the skill levels of users, the task context and the technology being used.

18

Within this section, all activities relevant in the widest sense to the 'human factor' are accounted for. However, the discussion of example methods focuses on those that are core to human factors, as these are likely to be the more unfamiliar to those without background knowledge of human factors.

6.2 KEY ELEMENTS OF HUMAN FACTORS APPROACHES

6.2.1 Human reliability assessment

There are two predominant frameworks that employ HRA techniques: • A top-down approach is conventionally applied in Probabilistic Risk Assessments to

identify potential equipment failures, external events and human errors that can combine to cause a hazard. Human errors include those that might initiate a hazard (e.g. signal passed at danger) and failures to recover from a hazard (e.g. activating an emergency shutdown button). Such errors are either directly quantified or are further analysed to identify and quantify the combinations of errors that may contribute to a failure.

• A bottom-up approach is generally favoured within the Human Factors community.

This focuses on the tasks of key personnel to identify the potential for error. The analysis begins with a detailed task analysis, followed by the application of a human error identification technique to identify potentially critical errors. A semi-quantitative risk ranking system may be applied at this point to screen out low risk errors. The remaining errors may then be incorporated into a risk model to identify the contribution of such failures to overall system risk. Once again, human reliability quantification methods are applied to estimate the error probabilities.

These two approaches take different routes to the common goals of identifying potentially significant human errors and then assessing the contribution of such errors to overall risk. Methods of human error identification and of quantification can assist in identifying key causative factors for significant errors and lead to the specification of remedial actions.

6.2.2 Usability engineering

BS EN ISO 13407 (Human-Centred Design Processes for Interactive Systems) provides a definition of the key principles applied in Usability Engineering. The key characteristics of the human-centered design process are as follows: a) The active involvement of users and a clear understanding of user and task

requirements; b) An appropriate allocation of function between users and technology; c) The iteration of design solutions; d) Multi-disciplinary design. The major groups of activities described in the standard and their interrelationships are shown in Figure 3. It should be noted that this is not directly mapped on to a design life-cycle (though the links are evident). There are direct mappings, however, onto the safety lifecycle in IEC 61508. The meaning of each of the groups of activities (rectangular boxes) is given in Table 3.

19

Identify need forhuman-centred

design

Understand and specifythe context of use

Specify the user andorganizationalrequirements

Producedesign

solutions

Evaluate designs againstrequirements

System satisfiesspecified user and

organisationalrequirements

Figure 3 Human-centered design processes from BS EN ISO 13407

The focus of these processes is on the effectiveness of artefacts and, in particular, information technology applications. The goal can be equally important in safety-related applications of computer systems. Usability may be critical in determining the likelihood that significant errors are made, or to the effectiveness of human actions in preventing or recovering a critical event.

Table 3 Human-centred design processes outlined in ISO 13407

Process Description

Understand and specify the context of use

Characteristics of intended users, tasks to be performed and environment to be captured. Environment should include physical, social, cultural, technical and legislative aspects.

Specify the user and organizational requirements

Specify users and other personnel; define human-centred design goals, set priorities for requirements, provide criteria to measure success against and any statutory/legislative requirements.

Produce design solutions • Use existing knowledge to develop design proposals (with a multi-disciplinary input)

• Make design more concrete using simulations, models, mock-ups etc.

• Present design to users and let them perform tasks

• Alter design in response to user feedback

Evaluate designs against requirements

Generate an evaluation plan, provide feedback of performance of design, acceptance test HCI and monitor performance in the field.

20

6.2.3 Human factors engineering

Human Factors Engineering (HFE) is used within this document to describe the combinations of techniques employed for engineering a range of types of products and complex systems. Typical elements include: • Functional analysis • Allocation of functions (automation decisions) • Task analysis (including timeline and workload analysis) • Application of human factors criteria, principles in design • Experimental studies, performance and environmental modelling • Job design and training development • Design of procedures and other job-aids • Trials, evaluations of mock-ups/prototypes

6.2.4 Human factors integration

Originating from HFE, Human Factors Integration (HFI) provides an organisational and managerial framework to integrated HFE (and HRA/UE) into the project engineering lifecycle. Key elements include: • Establishing standards and requirements related to human factors for project

managers and procurement departments within organisations; • Identifying required human factors project management and advisory roles within

projects; • Identifying specific required human factors deliverables within projects, including a

Human Factors Integration Plan; • Application of a wide range of human factors analyses at specified stages of the

system design lifecycle.

6.3 HUMAN FACTORS ACTIVITIES IN THE CONTEXT OF THE SAFETY LIFECYCLE

The table in Appendix B presents the full set of steps in the IEC 61508 safety lifecycle and maps specific human factors activities to each step. This includes activities, which are not necessarily specific to human factors though they may benefit from a human-centred focus. Those which have a particular human factors element are shown in bold in the right-hand column of the table. This table is far from exhaustive, but serves to demonstrate the range of methods that might be applied to a design. Many of these will not currently be routinely used within the development of a safety-related system. Further details of the human factors specific activities are provided in Appendix C.

6.4 HUMAN FACTORS STANDARDS

There are many organisations, which produce standards and guidance which are relevant to Human Factors. These include international bodies, such as the ISO and IEC, national bodies such as BSI, ASTM, and ANSI, and industry/discipline specific bodies such as IEEE and MOD. Maintaining an up to date knowledge of these standards and guidance is important as

21

they can play an important role in supporting human factors in design and assessment activities. Standards and guidance can be applied in a number of ways, such as: • To provide an authoritative definition of what constitutes good practice in addressing

human factors in design; • To define high level human factors design processes for integration into engineering

projects; • As design specifications for products/components of systems; • To specify minimum standards for detailed specialist human factors processes or

design criteria; • To establish consistency in detailed aspects of interface design across applications; • To provide principles and guidance for use in design and in assessing design. The first of these categories is particularly relevant to this document. Ideally, any framework developed for IEC 61508 will utilise cross-references to existing standards wherever possible, rather than create further standards material. A selected listing of human factors standards that define relevant human factors processes in design is provided in Appendix D.

23

7 HUMAN FACTORS REQUIREMENTS IN SAFETY-RELATED SYSTEM DESIGN

The previous section highlighted ways in which human factors methods may be applied at various points during the safety lifecycle of an E/E/PE system. Applying the full range of methods would involve significant effort. It might, therefore, be expected that the level of effort could be determined as some function of the safety integrity level of the system. This would correspond to the approach taken to software integrity levels in IEC 61508, where specific software development and assurance techniques are identified as 'recommended' or 'required' as a means of determining the level of assurance required for a particular safety integrity level. Consideration has been given to a range of applications of E/E/PE systems in safety-related applications. This has highlighted the diversity of ways in which human factors requirements map on to various E/E/PE systems in different industries and contexts. Such differences have already been alluded to in Sections 5.4.1 and 5.4.2 using just two examples of system architectures. In examining each of the basic architectures independently, the relationship can be explored between human factors effort and safety integrity. This section examines the characteristics of different categories of E/E/PE systems and then outlines the key principles that have been derived from their examination.

7.1 ANALYSIS OF TYPICAL ARCHITECTURES

The following Sections describe a number of identifiable 'human-machine architectures' that cover a range of safety-related applications. For completeness, this includes the example systems covered in Section 5. This is unlikely to be an exhaustive list and many applications are likely to be hybrids between such architectures. Some of the examples described in this Section are single systems that support a safety-related function. It should be noted that IEC 61508 explicitly excludes applications where a single E/E/PE system is capable of providing the necessary risk reduction (Part 1, Section 1.2). Such functions are often control or decision-making functions, the failure of which might lead to a safety related failure. They are not risk reduction or protection systems per se. However, the principles of IEC 61508 are being applied in practice to a much wider scope of systems than its scope specifically demands (e.g. control and information systems). Hence, any mechanism under IEC 61508 for considering human factors must be developed to incorporate such applications.

7.1.1 E/E/PE as a protection system

This is as described in Section 5.4.1 as being a 'typical' application of IEC 61508. The equipment/plant and its control system provide the baseline risk. A protection system is then provided to reduce the risk to an acceptable level. A typical example would be an Emergency Shutdown System for a process plant (refer to Figure 4). Operational staff have little direct interaction with this type of system. It may trigger alarms when it is activated or when it fails. It is likely to have an override capability, allowing parts to be taken out of service when necessary and it may have means of being manually initiated. In terms of its operator interface, it is likely to be relatively simple, but its human factors attributes are important in the following ways:

24

• Should it be activated, malfunction or fail to operate, it is important that it provides

the operator with a clear indication of what has occurred; • Implementation of an override in error or in an unauthorised manner could seriously

jeopardise safety. Adequate safeguards, therefore, have to be provided; • Should it be necessary to manually initiate the system, it is likely to be required under

tight time pressure. The activation control needs to be accessible, clearly labelled and easy to operate.

The higher the level of protection that is provided by the system, the more important these aspects are likely to become.

E/E/PEProtection

System


ControlSystem

Alarms/Indicators

Manual Initiation

Overrides

Safety-Related System

Figure 4 E/E/PE as a protection system

The same relationship between safety integrity and human factors applies to the maintenance of such systems. Physical access to the system, clarity of labelling, design and identification of components to prevent incorrect re-assembly and the quality of diagnostic information all contribute to the possibility of maintenance error. An added complication is that the higher the safety integrity level, the more complex the protection system is likely to be from the perspective of maintenance.

7.1.2 E/E/PE as a supervisory control system

This type of system may provide some safety functions (e.g. maintaining continuous control over critical equipment or process parameters) and is likely to interact with the operator in a more intensive manner. Primary closed-loop control is exercised by the control system, with the operator acting in a supervisory or executive capacity. Examples might be a SCADA or

25

Distributed Control System operating a process plant, an industrial process, utility supplies or a railway (refer to Figure 5).

E/E/PE ControlSystem


InformationAlarms/Indicators

Control Input

Safety-Related System(s)

Interlocks

Figure 5 E/E/PE as a control system

Typically, such system will provide sequenced or closed loop control of the equipment/plant concerned. Operational staff will supervise the equipment/plant performance through displays provided by the control system and intervene where scheduling, throughput or quality decisions are required to be made. The system will also be used by operations staff to support maintenance operations. This may involve isolating parts/areas of the equipment to protect the maintainers and operating the equipment for testing when requested. Such systems tend to have sophisticated colour graphics user interfaces and various input devices. The quality of the user interface may be important in a number of ways: • The user interface needs to minimise the opportunity for incorrect input that could

result in a hazardous loss of control; • The operator will utilise the displays to gather a range of information about the

equipment under control and utilise it to make decisions or give advice. Misread or obscure information may lead to hazardous decisions being made or advice being given;

• Key safety related information is likely to be provided in the form of alarms. Appropriate alarm system design is essential to prevent alarms being missed or flooding the operator with information that causes a distraction during critical conditions;

26

• Actions may need to be performed via the control system that are time critical. The speed with which the functions can be executed and the feedback provided are likely to determine the effectiveness of such safety critical functions;

• In interacting with maintenance operations, the provisions for displaying information on equipment and plant status can be important.

The importance of the human factors characteristics of this class of systems depends upon the combination of the criticality of the safety functions provided by the control system (which the operator might affect) and the criticality of the safety functions provided by the operator (which the control system might affect). With regard to the criticality of the safety functions provided by the control system, the greater its role in controlling risk, the more important it is that erroneous, spurious or unauthorised inputs are protected against. A greater influence on its design is likely to be the need to support operator safety related functions, requiring attention to the format of displayed information, the selection of input devices and the design of the user interaction. The overall integrity requirements of a control system will once again determine the effort that needs to be placed into human factors aspects of its maintenance.

7.1.3 E/E/PE as a remote control system

This type of system is a variation of that defined above as a 'Supervisory Control system'. In this case, the control system is 'driven' by the operator and the E/E/PE system integrates the control inputs and operates actuators. Examples include powered steering, rudder control systems, remote manipulator systems, dynamic positioning systems (used on some marine vessels) and 'fly-by-wire aircraft control systems. The inputs to this system are largely provided by a human operator and may be augmented, optimised, resolved and interlocked by the control system (refer to Figure 6).


Control Inputs

Safety-RelatedSystem

E/E/PE Control System

Information

ExternalWorld

Figure 6 E/E/PE as a remote control system

27

Particular human factors issues related to this class of system are as follows: • The design of the input device and related controls (e.g. those selecting modes, gain

etc) will be critical to the safe execution of the control task. Consideration will have to be given to the physical location and characteristics of the control device (e.g. force feedback on a joystick), appropriate positioning and coding of ancillary controls (e.g. tactile coding of buttons) and protection against inadvertent activation.

• The appropriateness of the control dynamics to produce accurate and safe human control. For example, the control software may integrate human input actions to generate an appropriate output command. The type of integration and the feedback provided will both affect human performance.

In this context, the operator, driver or pilot is the source of control and is performing a safety-related function. The E/E/PE system is supporting those safety functions. Therefore, the higher the criticality of the operator control task, the greater the level of integrity that will be required of the hardware, software and the quality of related human factors. The level of integrity required for maintenance activities is, in this case, directly related to the level of integrity of the safety-related system. It is vital that the hazard and risk assessments identify the criticality of such human-dependent safety functions. This will enable the required integrity of the related E/E/PE systems to be defined.

7.1.4 E/E/PE as a display and/or communications system

The class of systems does not directly provide safety-related protection or control functions. In examples such as the crowd management system described earlier in Section 5.4.2 and for air traffic control systems, the protection and control functions are largely provided by the 'operator-in-the-loop' (refer to Figure 7). Examples of areas where human factors may be critical include: • The quality of the displayed information can be vital in such applications. The size

and definition of CCTV pictures, for example or the design of the graphics on a radar display;

• The controls provided will swap between displayed views or enable selection of a required output channel (e.g. radio channels, intercom/telephone numbers). Poor design may result in the wrong information being consulted or key messages being lost or delayed. The user interface needs to minimise the opportunity for such errors;

• The amount of information provided simultaneously and its physical location can also affect the ability of the operator to perform key monitoring tasks to the level of performance required.

The importance of the human factors characteristics of this class of systems depends upon the combination of the criticality of the safety functions provided by the operator (which the E/E/PE systems can directly influence). In essence, the operator provides the main safety functions. The other devices form part of the control loop. The higher the level of performance required from the operator, the greater the level of integrity required of the hardware, software and quality of human factors.

28

E/E/PE DisplaySystem


CommandsInformation

Safety-RelatedSystems

E/E/PE CommsSystem

Figure 7 E/E/PE as a display and/or communications system

Often, such systems are not the only means of obtaining information about the equipment, personnel or system under control. There are a number of additional redundant display and communication channels available to the human-in-the-loop. Furthermore, the information provided or the communications may not be safety critical in their own right. An example of this concerns 'train identification systems' which provide details of train identities to a signaller. Control over routing may be exercised through a separate, interlocked control system. Information about train identities may have a limited safety role, being more concerned with traffic regulation. If the system fails, the signaller can revert to other manually intensive means of tracking train identities. However, within a busy traffic area, loss of such supporting systems may have a significant knock-on impact on operator workload, which in turn would have safety implications. Therefore, in considering the integrity of the system, it is important not only to consider the criticality of the safety functions it directly supports, but also the criticality of the operator safety functions it might affect under failure conditions. Hence, the hardware/software integrity is determined by the functional safety of a range of human tasks, though the 'integrity' of the human factors aspects of the system, are determined by those human safety functions that are directly supported.

7.1.5 E/E/PE as an offline analysis or support tool

This class of systems consists of non-real time data processing, information or engineering analysis computer systems. They are deemed to have a safety-related role since the

29

information they provide supports safety-related decision making2. Specific illustrative examples include: • Software used to calculate loading, unloading and ballasting arrangements on large

bulk carrier ships (N.B. errors can lead to structural failure); • Software processing data on tunnel lining strength (e.g. used to monitor potential for

tunnel collapse as sprayed concrete lining hardens) • Expert advisory systems (e.g. providing guidance for operators or maintainers). Parameters may or may not be input by the users of such systems, and the output may be on screen or in printed form. The users are likely to have other sources of information against which to assess the information provided by the E/E/PE system, though a degree of trust will tend to be built up in the information provided and the extent of cross-checking will vary.

Offline AnalysisSystem

Equipment/System Under Control

Information

Configuration and/or Data

Safety-RelatedSystem

Data (in some cases)

Figure 8 E/E/PE as an offline analysis or support tool

Particular human factors issues related to this class of system are as follows: • Assuming that all necessary steps have been taken to ensure the accuracy of the

results generated by the system, the presentation of those results is going to be of importance. Firstly, the format needs to be appropriate to the decision making task and the end users of the system. Information that needs to be translated or interpolated may lead to errors of interpretation. Simple aspects of displayed information (e.g. scales on graphs, use of text formatting to emphasise key points) may result in misreading. Inappropriate use of technical terminology or missing

2 Of all of the types of system considered within this section, this is probably the least most likely to be considered under IEC 61508, though the same principles still apply.

30

units/labelling may lead to misunderstanding. Secondly, the end user may be expected to validate the information/advice provided. Relevant information needs to be presented so that an appropriate degree of scrutiny can be paid to the data used and results reached.

• Where the user is required to enter data and/or to configure the system to generate appropriate results, it will be of importance that the system dialogue is well designed and supports cross checking of inputs.

In this case, there is a safety function being performed by a combination of the operator and the advice provided by the E/E/PE system. The integrity of the human factors aspects of system input/output will directly relate to the reliability of the safety function and hence the overall integrity of the E/E/PE system. As stated previously, the effort on software maintenance will also be directly proportional to the integrity of the E/E/PE system.

7.2 SUMMARY OF KEY PRINCIPLES AND REQUIREMENTS

Table 4 provides a summary of the main points from the preceding sections. A number of conclusions can be drawn from this: • Determination of the integrity level for an E/E/PE system requires careful

consideration of not only of the direct risk reduction functions it is providing, but also those risk reduction functions performed by staff that interact with it. This requires addressing in the Hazard and Risk Analysis step of the IEC 61508 lifecycle;

• Having determined the integrity of the E/E/PE system in this way, it can be shown

that the effort that needs to be placed into operations and maintenance human factors should be greater as the SIL level increases;

• The types of human factors issues that need to be addressed vary between the classes

of systems discussed. The framework, therefore, cannot be specific in terms of the technology or aspects of human factors design.

31

Table 4 Summary of human factors integrity requirements

Determinants of SRS Integrity System

Category Related Section E/E/PE System Overall E/E/PE Operational Human

Factors Key E/E/PE Operational Human Factors Issues

E/E/PE Maintenance Human Factors

Protection System

7.1.1 Determined by the risk reduction required to ensure operation of the equipment under control is ALARP

Increases in proportion to integrity of E/E/PE

Alarms

Protection of override functions

Manual initiation


Supervisory Control System

7.1.2 Determined by the combination of criticality of automatic and operator directed safety functions


Input protection

Information display

Alarm handling

Speed of operation

Plant/system status


Remote Control System

7.1.3 Determined by criticality of overall control function (being directed by operator)


Input device design

Control dynamics and intrinsic/extrinsic feedback


Display and/or Communications System

7.1.4 Determined by criticality of control function being exercised by operator


Information display

Controls

Amount and location of display

Impact of failure


Offline Analysis or Support Tool

7.1.5 Determined by criticality of decisions made on basis of output


Format and content of output

Integrity of input


32

Some classes of safety-related system will have no direct interface with operational personnel. Indeed, the system may have been implemented to provide protection against human error (e.g. railway interlocking). Whilst this would remove any need to consider human factors issues related to direct operator interfaces, the impact of failure or degraded operation would need to be considered in the overall hazard and risk analysis. In particular, additional effort may need to be put into the design of other E/E/PE systems that provide the operator with the information and control facilities necessary to respond in the advent of full or partial failure. Paradoxically, the level of effort in such aspects of human factors, may need to be greater the higher the level of integrity of such a system. This is because of two factors: • If a high integrity system fails, a significant level of risk reduction is removed from

the system. Hence the greater the reliability of control that the human operator is likely to need to exercise;

• A high integrity system is likely to fail less frequently (or at least fail into an unsafe condition). Humans tend to respond less reliably to an infrequent event or one they have not experienced before. The effort in terms of display there has to be greater to overcome this tendency.

The analysis has demonstrated that it is critical that the processes of hazard and risk analysis and the derivation of safety requirements capture all of the safety functions that are provided by or contributed to by operational staff. This will require methods of hazard identification and risk analysis that encourage examination of a wide range of degraded and emergency conditions.

33

8 PROPOSED FRAMEWORK

The previous Section has identified a number of key principles upon which a framework can be based for relating human factors effort to E/E/PE Safety Integrity. This section explores how this framework may be derived and presents a proposal for what it might contain.

8.1 INCLUSION WITHIN HAZARD AND RISK ANALYSIS

IEC 61508 clearly isn't intended to be a general framework for risk assessment or for human reliability analysis. It is intended to provide a means by which the adequacy of E/E/PE hardware and software can be judged for a safety-related application. As has already been described in Section 7, there are various elements of the integrity and interface design of an E/E/PE system that can interact with the 'human factor' to influence risk. To address this, the following aspects need to be addressed: • The opportunities for the operator/user or other human agents to cause or contribute

to unsafe conditions needs to be understood; • It needs to be understood what safety functions the operator/user is required to

deliver via or in conjunction with E/E/PE systems; • The required integrity of the E/E/PE system needs to be determined taking into

account the identified operator/user safety functions. It should be noted that this requires an additional set of assessments alongside the normal equipment integrity assessments performed under IEC 61508. Not only is the integrity of the equipment hardware/software being assessed from the perspective of its inherent reliability, but the integrity of associated human safety functions are being assessed in order to identify what assurance is required for the human factors aspects of the overall system. In particular, in line with the specific focus of IEC 61508, the assessment process is required to identify what needs to be done in developing the equipment hardware/software to be able to support the required level of human safety integrity and hence the overall safety performance of the system. An overview of the logic of this process is given in Figure 9. Human accident initiating events need to be included within the hazard and risk analysis step to the extent outlined in the Overall Scope Definition. It should be noted that assessment of such events will be based on various assumptions related to the expected human factors characteristics of the completed system (e.g. staff competency, quality of user interface). These requirements cannot therefore be considered in isolation from the allocation of safety integrity requirements as shown later in the design lifecycle.

34

Hazard & Risk Analysis

Overall SafetyRequirements

SafetyRequirements

Allocation

E/E/PE Safety Functions

Human Safety Functions

Integrity Requirements

Hardware/softwaredesign requirements

Humanfactorsdesign

requirements

Equipment Safety IntegrityPeople/Procedures

Staff selection,training,

procedures etcrequirements

Human accidentinitiatingevents

Assumptionsregarding

HF aspects ofdesign

Figure 9 Determination of HF safety requirements

Having identified the safety requirements and required level of risk reduction, the requirements are allocated within IEC 61508 to E/E/PE systems, other technology Safety-Related System (SRS) or external risk reduction facilities. Human operators will provide one possible source of risk reduction. Figure 9 shows just the allocation between human and E/E/PE SRS.

35

Figure 9 also shows how the delivery of the required level of integrity for human safety functions will require not only the user interface to be addressed (i.e. the direct issues affecting the E/E/PE SRS), but also aspects of processes (e.g. tasks/plans/procedures) and people (e.g. staff numbers, selection, training). The required level of safe performance cannot be assured without such considerations being taken into account. Some coverage is given to such aspects within IEC 61508, but the design requirements of equipment (i.e. the SRS) provide the main focus. To address these issues with IEC 61508 or to provide guidance to support IEC 61508, will require specific advice to be given on including human factors issues within hazard and risk analysis. With regard to specifying basic concepts in human reliability analysis and specific techniques, no standards currently exist that could be cross-referred, though work is ongoing to produce such standard under IEC (IEC/TC56/WG11). Advice may also need to be given as to which types of methods should be applied in different contexts. If this is deemed necessary, a scale of effort may be provided (e.g. Table 5).

Table 5 Example specification for human reliability analysis requirements

Severity of Consequences Possible Requirements for Human Reliability Analysis

Minor injury • Human failure explicitly considered within main top-down system hazard identification process.

Major injuries • Operational tasks analysed at high level to identify safety functions.

• Human failure explicitly considered within main top-down system hazard identification process.

Major injuries and fatalities • Operational tasks analysed at detailed level to identify safety functions.


• Risks arising from human error assessed quantitatively and modelled

Multiple fatalities

(Major disaster)

• Operational and maintenance tasks analysed at detailed level to identify safety functions.


• Potential errors of commission identified (i.e. actions on wrong system or non-required actions, rather than just failure to perform required action)

• Human error dependency assessed

• Risks arising from human error assessed quantitatively and modelled

The examples given in Table 5 are only intended to be illustrative. The mapping of requirements to the consequence levels has not be systematically derived or verified. As can be seen, it would be necessary to calibrate the proposed level of effort depending upon the overall maximum severity of consequences of system failure (which is all that could be

36

estimated prior to embarking upon the hazard and risk analysis process). Such guidance may be necessary, as there is considerable uncertainty regarding what type of human reliability analysis needs to be applied in a specific context.

8.2 BASIS FOR SPECIFYING HUMAN FACTORS DESIGN REQUIREMENTS

Given that it has been shown that the level of effort on human factors can be linked to safety integrity, three possible ways have been identified to develop an appropriate framework: • HRA Based Framework: Existing human reliability assessment methods enable the

probability of task failure to be linked to various attributes such as task type, personnel competence, equipment characteristics and environmental influencing factors. This could be employed to define the minimum levels of such attributes (e.g. skill-based task, experienced operator, equipment interface with clearly labelled, well-laid out controls with positive feedback) to achieve a particular level of human safety integrity (e.g. probability of task failure of 1 in 1000). This would be linked through the safety requirements allocation to the integrity level of the E/E/PE system;

• Techniques Requirement Framework: Human factors development techniques and

testing methods could be specified at each level of safety integrity. Therefore, for a low integrity requirement, some level of design specification and a simple end-of-development testing programme may be sufficient. To achieve a high integrity requirement, full testing using high fidelity simulated data may be necessary, along with appropriate empirical validation of key interface elements, assessment and measurement of workload etc;

• Assurance Demonstration Framework: It may be possible to link levels of human

safety integrity to particular defined levels of assurance. For example, for a high integrity safety function it should be possible to provide documented evidence that:

All relevant tasks to be performed by the operator/user have been defined, described and, where possible, verified against actual observed behaviour; All physical aspects of the design have been reviewed against operational design requirements and other relevant aspects of human factors best practice and any problems resolved (e.g. screen design, dialogue design, control room environment); The HF aspects of the design have been subjected to evaluation by typical users operating the equipment under simulated conditions and problems fed back into design improvements;

For a low integrity interface, the requirements would be significantly less onerous such as:

Key tasks, user groups and operating environments have been described as part of the requirements documentation; Critical tasks and aspects of the HF design and requirements have been identified and subjected to documented review by the design team.

37

The HRA Based Framework has the benefit that there is a means of demonstrating a verified link between an integrity requirement (e.g. a risk reduction of 1 in 1000) to a specific range of task types and conditions. However, current HRA methods handle some types of tasks better than others (e.g. discrete single actions - pushing an ESD button, is handled better than continuous control tasks, such as tracking aircraft on a screen or steering a vehicle). They also have only a limited amount to say about the specific design of modern user interfaces. Such techniques have their place during the hazard and risk analysis stage, but would provide little definitive guidance for the design and implementation of an E/E/PE system. The Techniques Requirements Framework provides a more practical linkage between integrity and required design actions. However, there is no known way of determining the required mapping between a level of integrity and a set of techniques. Many techniques are also new and still under development. There is also a plethora of methods that overlap with existing system engineering processes. A framework established on this basis could be contentious and become rapidly outdated. The Assurance Demonstration Framework approach has the benefit that it does not specify any particular methods, but sets out requirements around which the design team would need to demonstrate an acceptable level of assurance. This could be linked to particular technique guidance, but allows the design team the scope to select methods appropriate for their domain. Whilst less concrete than the Techniques Requirements Framework, it has the benefit that it would require its users to 'think' and may deliver requirements that can be directly built into specifications and assurance plans. It has the same problem as the Techniques Requirements Framework, however, that there is no established way of determining the linkage between integrity level and assurance requirement level. Also, there would be a need for some form of independent assessment to determine that an appropriate level of assurance has been demonstrated. Fortunately, the need for independent assessment already forms a part of IEC 61508, linked to the E/E/PE software integrity level requirements (Part 1, Section 8.2) and it would be possible to extend this in a similar manner to cover human factors integrity requirements. Based on this analysis, it is proposed that any Framework would be based on the Assurance Demonstration approach. In making this proposal, it is recognised that there are still a number of areas of uncertainty that would need to be overcome before this could be developed into a fully robust and justifiable framework. These are discussed in Section 8.4.

8.3 PROPOSED FRAMEWORK FOR HUMAN FACTORS DESIGN REQUIREMENTS

The following tables illustrate how human factors design requirements might be linked to E/E/PE Safety Integrity Levels. The grey areas indicate an overlap between those aspects that would be delivered as part of the design of an E/E/PE system and wider human factors implementation requirements. These are illustrative examples only and require further development and validation. Within documentation describing the framework, it is expected that the requirements would be amplified and explained. To provide guidance, it would be possible to describe example techniques that might be applied to meet the requirements at each safety integrity level. Further ways of presenting such requirements are open to exploration. In the following examples, requirements are amplified and made more onerous as the SIL level increases. As an alternative, it is possible that requirements could be written in a form that allows them to

38

be applied at any safety integrity level, and then mapped onto SILs using the recommended, highly recommended and not recommended codes (i.e. H, HR, NR) employed in the IEC 61508 tables. Figure 10 illustrates the overall, proposed process. This breaks down into two main elements: • Incorporation of human tasks and errors into the Hazard and Risk Assessment

process; • Use of the tables to define the human factors requirements for a given safety integrity

level. As shown in the figure, assumptions will be made regarding human tasks and system design during the Hazard and Risk Assessment stage of the process that will require validation during the design phase.

Table 6 Example human factors requirements for a SIL1 system

SIL 1

Aspect Requirement

Understanding and defining the context of use

• Key tasks, user groups and operating environments have been described as part of the requirements documentation

Derivation and definition of HF design requirements

• Selected mandatory standards and specifications have been identified for application to the HF aspects of the design

Documentation of design

• The user interface has been described as a design deliverable (e.g. within the operating/maintenance manuals)

Evaluation and testing of HF performance

• Critical tasks and aspects of the HF design and requirements have been identified and subjected to documented review by the design team

Specification and delivery of training

• All staff who are to operate or maintain the equipment have received instruction that covers all relevant aspects of the equipment

Development of documentation

• Sufficient documentation necessary to operate or maintain the equipment has been produced and its accuracy/completeness has been verified

Evaluation in use

• Support arrangements are in place to address significant problems that may arise when the equipment is in use

39


SIL 2

Aspect Requirement


• Key tasks to be performed by operations and maintenance staff have been identified (those that are concerned with safety related functioning of the equipment).

• Key operator and maintainer groups have been identified, along with their roles and responsibilities.

• Typical operating environments have been identified and described


• Selected mandatory standards and specifications have been identified for application to the HF aspects of the design, along with additional context specific HF requirements


• The conceptual design of the user interface is documented as a design deliverable (e.g. within the operating/maintenance manuals)

User evaluation and testing of HF performance

• Critical tasks and aspects of the HF design have been identified and subjected to systematic, documented review by the design team

• The design has been reviewed in detail during the design phase by representative operations and maintenance staff and any problems raised have been resolved

• The design has been evaluated against the original HF design requirements and any shortfalls have been resolved


• All staff who are to operate or maintain the equipment have successfully completed training that covers all relevant aspects of the equipment and its application


• All documentation necessary to operate or maintain the equipment has been produced and its accuracy/completeness has been verified

Evaluation in use

• Support arrangements are in place to address significant problems that may arise when the equipment is in use


SIL 3

Aspect Requirement


• All relevant tasks to be performed by the operators/maintainers have been defined, described and verified by staff representatives. This includes operations under normal, abnormal, degraded and emergency conditions.

• The roles and responsibilities of all potential user and maintainer groups have been identified and their key characteristics defined (e.g. training, skills)

• Typical operating environments have been systematically identified and assessed for potential implications for the design

40

SIL 3

Aspect Requirement


• Selected standards and specifications have been identified for application to the HF aspects of the design

• Appropriate functional and user performance requirements have been specified for the HF aspects of the design


• The processes utilised in developing the design are specified and controlled

• The conceptual design of the user interface is fully documented and controlled

Operational performance assessment of HF design

• Critical task sequences and activities have been identified and all relevant aspects of human performance have been assessed and found to be acceptable (e.g. speed, workload, reliability)

• Key physical aspects of the design have been reviewed against operational design requirements and other relevant aspects of human factors best practice and any problems resolved (e.g. screen design, dialogue design, control room environment)

Maintainability assessment of design

• Critical maintenance tasks have been identified and all relevant aspects of human performance have been assessed and found to be acceptable (e.g. maintenance reliability, speed)

• All physical aspects of the design which are novel or critical have been reviewed against maintenance design requirements and other relevant aspects of human factors best practice and any problems resolved (e.g. access, component identification, software diagnostic tools)


• The HF aspects of the design have been subjected to evaluation by typical users performing or simulating typical tasks with design mock-ups and problems fed back into design improvements

• The design has been evaluated against the HF design requirements and performance goals and any shortfalls have been resolved

Specification and delivery of staffing

• Job and person specifications have been developed, validated and implemented in screening or selecting operations and maintenance personnel


• Training specifications and material have been developed that covers both equipment use training and job related training

• Training has been delivered within an assured and validated process to all staff who are to operate or maintain the equipment


• All documentation necessary to operate or maintain the equipment has been produced in a suitable format and its content/usability has been verified

Evaluation in use

• Support arrangements are in place to gather information on problems in use, to address significant problems and to feed forward improvements into future upgrades/designs

41


SIL 4

Aspect Requirement


All relevant tasks to be performed by the operators/maintainers have been defined, described and, where possible, verified against actual observed behaviour and records. This includes operations under normal, abnormal, degraded and emergency conditions.

All potential user and maintainer groups have been identified and their characteristics, roles and responsibilities defined in detail (e.g. backgrounds, aptitudes, training, skills)

The range of possible operating environments has been systematically identified and assessed for potential implications for the design


• All relevant standards and specifications have been identified for application to the HF aspects of the design

• Appropriate functional and user performance requirements have been specified for the HF aspects of the design


• The processes utilised in developing the design are specified and controlled

• The conceptual and detailed design of the user interface is fully documented and controlled

Operational performance assessment of HF design

• Critical task sequences and activities have been identified and all relevant aspects of human performance have been assessed and found to be acceptable (e.g. speed, workload, reliability)

• All physical aspects of the design have been reviewed against operational design requirements and other relevant aspects of human factors best practice and any problems resolved (e.g. screen design, dialogue design, control room environment)

Maintainability assessment of design

• Critical maintenance tasks have been identified and all relevant aspects of human performance have been assessed and found to be acceptable (e.g. maintenance reliability, speed)

• All physical aspects of the design have been reviewed against maintenance design requirements and other relevant aspects of human factors best practice and any problems resolved (e.g. access, component identification, software diagnostic tools)


• The HF aspects of the design have been subjected to evaluation by typical users operating the equipment under simulated conditions and problems fed back into design improvements

• The design has been formally evaluated against the HF design requirements and performance goals and any shortfalls have been resolved

Specification and delivery of staffing

• Job and person specifications have been developed, validated and implemented in screening or selecting operations and maintenance personnel


• Training specifications and material have been developed that covers both equipment use training and job related training

• Training has been delivered within an assured and validated process to all staff who are to operate or maintain the equipment

42

SIL 4


• All documentation necessary to operate or maintain the equipment has been produced in a suitable format and its content/usability has been verified

Evaluation in use

• Support arrangements are in place to gather information on problems in use, to address significant problems and to feed forward improvements into future upgrades/designs

Hazard & Risk Analysis

Overall SafetyRequirements

SafetyRequirements

Allocation

E/E/PE Safety Functions

Human Safety Functions

Integrity Requirements

Equipment Safety IntegrityPeople/Procedures

Human accidentinitiatingevents

Assumptionsregarding

HF aspects ofdesign

Training

HF DesignReqmnts

Context of use

Safety Integrity Level

R: xxxxx

R: xxxxx R: xxxxxR: xxxxx

R: xxxxxR: xxxxxR: xxxxx


R: xxxxx


R: xxxxxR: xxxxx

R: xxxxx R: xxxxxR: xxxxxR: xxxxx

R: xxxxxR: xxxxx

Figure 10 Proposed framework for addressing human factors in IEC 61508

43

8.4 LIMITATIONS AND AREAS FOR FURTHER DEVELOPMENT

In order to address human factors in the design of E/E/PE systems it is necessary to adopt a holistic view of the systems and processes that are involved in reducing risk. As was illustrated in Section 7, there are a number of ways that the design of E/E/PE systems and human tasks can interact in controlling, reducing and, in some cases, generating risk. Once it is accepted that Hazard and Risk Assessment needs to capture 'human safety functions' as well as 'equipment-orientated safety functions', it is possible to see how Safety Integrity Levels can be mapped on to levels of Human Factors assurance. There are a number of areas where this is problematic within the approach taken by IEC 61508: • The scope of the standard only addresses situations where risk reduction requires

more than one E/E/PE system to be applied. In many of the cases cited, there is only a single E/E/PE system and a human operator;

• As already stated, IEC 61508 includes the control system within the baseline risk of

the Equipment Under Control and then applies the concept of Safety Integrity Levels to the protection system that is designed to provide risk reduction. The operator may be considered as part of the baseline risk (through potential control errors) as well as being an 'other technology' form of protection system. The operator is clearly external to the normal considerations of risk reduction covered by IEC 61508;

• The 'architectures' presented in Section 7.1 are illustrative, but actual control

environments often involve a combination or accumulation of such systems. The operator may have the choice of one or more diverse means of obtaining information and of executing safety-related actions using a variety of E/E/PE systems. Given that the human action is required to be performed to a particular level of integrity, it is not immediately clear whether all, one or a combination of E/E/PE systems would be required to have a matching level of integrity;

• From a human reliability perspective, there are difficulties with viewing an operator

as a source of risk (i.e. through human error) and as a means of risk reduction or recovery from the same hazardous event. Yet, it is sensible to ensure that there are the provisions for detecting such failure states built into the system. It is important, therefore, that the Hazard and Risk Analysis does not screen out valid human recovery safety functions (for risk calculation purposes) with the result that they may not be addressed in the design;

Within this project, considerable effort was placed into trying to find a way of reconciling the strict interpretation of IEC 61508 with the need to find a means of linking human factors requirements to safety integrity. More complex frameworks were considered and then rejected. The current framework is probably the least complex that can be proposed, but operates in some aspects in potential conflict with the strict scope of IEC 61508. The framework is offered in its current form with the intention of provoking debate on such issues. Finally, in generating this framework, it has been assumed that risk is a useful concept in determining the effort that needs to be placed into the human factors aspects of an E/E/PE system. This can lead to a situation where less attention is given to the human factors aspects of systems that might support recovery from highly unlikely or unpredictable events (i.e. low risk or unanticipated, though possibly high consequence events). Yet it is in these

44

circumstances that human operators can be at their most useful. A series of recent incidents have highlighted this point: • The Texaco Oil Refinery Fire occurred through a series of human errors leading to a

major hydrocarbon discharge. The operators were unable to diagnose the cause of the various problems occurring on the plant until it escalated into an explosion and fire. It was concluded in the report on the incident (Reference 1) that the operators were not provided with sufficient means to determine the mass balances across the process and hence to detect the nature of the problem. In any prior risk assessment, the source event that occurred would have been considered highly unlikely. It is uncertain whether any parts of the risk assessment would have determined that leaks might occur without being clearly signalled by a flow or pressure indication. Whilst the concept of providing mass balance displays has been widely discussed in human factors circles, taking a risk assessment approach during this system design would not necessarily provided the driver to include such displays.

• In the sequence of events that led to the Ladbroke Grove railway crash, there was an

opportunity for the signallers to have intervened and potentially averted the collision (Reference 3). They were provided with an alarm that detected a possible signal passed at danger and they attempted to set signals to stop one of the trains involved. The audible alarm was not distinct from many other more 'routine' and frequent alarms received at the desk and sounded only once. In this case, however, the signaller in question was seated at his console and identified the alarm relatively quickly. Delays in responding to the alarm were due primarily to an expectation (based on previous experiences) that the driver would identify his own error, stop and call in.

In this case, though a signal was eventually set to danger, the actions were delayed (note: an immediate response would only have reduced the speed of collision). The option of changing a set of points to divert the trains from colliding was not possible due to the time that would have been required to access the relevant screen on the control system and to initiate the control action. An 'all signals on' control was available, but was designed to be operated only in the event of a control system failure. A software function to set smaller groups of signals to red in an emergency had been specified for new control systems, but had not been retrofitted to existing systems. The best course of action in the circumstances (in which the signaller had less than ten seconds to assess and respond) was to use the radio to send an emergency stop message to the train concerned.

The inquiry report recommended changes in procedures and training. It also recommended that the alarm for signals passed at danger should be uniquely identifiable, sounding until acknowledged and that the speed of actuation of points should be improved. Two automated forms of protection were also proposed in the event of the control system detecting a signal passed at danger; automatic setting of signals to danger and sending of a radio message alert to the train involved.

Signals passed at danger is a well known hazardous scenario in railway operations and rules existed directing a signaller on the actions to be taken. However, the frequency of signals passed at danger is still relatively low and is most cases, the driver mitigates their own mistake. Therefore, in assessing the signaller's recovery function purely in terms of risk reduction, little claim on signaller action is likely to have been made in any risk assessment on the grounds of frequency. Indeed, an

45

assessment of signaller reliability would not have placed much reliance on the ability of a signaller to make the necessary decisions and have acted correctly in the time available. Hence, little effort would have been expended in assuring the human factors involved. Yet the expectation as expressed in the inquiry is that, given there was the opportunity and time to respond, the control system should have enabled this to be possible. It is ironic that such recovery actions involving signals and points would most probably have been more easily achievable with earlier generation panel technology.

It follows that some emphasis will have to be placed upon the basic human factors qualities of the operator interface and system maintainability, rather than relying entirely on a risk based approach to determining where effort is placed. The proposed framework, however, can be helpful in forcing consideration of what the operator is in the system for and how they need to be supported. Hopefully, a proper recognition of the uncertainty that exists within risk assessments will encourage designers to exceed the minimum stated human factors requirements for a particular E/E/PE system safety integrity level.

47

9 CONCLUSIONS

From careful consideration of various types of safety-related applications where human interact with E/E/PE systems, it is evident how much human performance depends on attributes of system design and also on wider issues related to staff capabilities and the working environment. Where such performance is important in preventing or recovering from hazards, it is important that human factors is treated systematically within system design. As is demonstrated within Section 5.2, IEC 61508 makes a number of references to human factors. Of most significance is probably the following requirement from paragraph 7.4.8.3 of Part 2 of the standard:

"The design of the E/E/PE safety-related system shall take into account human capabilities and limitations and shall be suitable for the actions assigned to operators and maintenance staff. The design of all interfaces shall follow good human factors practice and shall accommodate the likely level of training or awareness of operators, for example in mass-produced E/E/PE safety-related systems where the operator is a member of the public."

The proposed framework presented in this report attempts to link human factors design requirements to E/E/PE safety integrity in a systematic manner. What initially became clear was that the model adopted for determining safety-integrity requirements within IEC 61508 is potentially limiting in this regard. Operators have to be very much viewed as external to the E/E/PE system, though the standard does indicate that a human being can form part of a safety-related system. The analysis presented in Section 7 of this report examines a range of types of safety-related applications of E/E/PE systems without being concerned about the constraints of the IEC 61508 distinction between systems providing risk reduction and those contributing to the risk of the equipment under control. This demonstrated that, if the hazard and risk assessment step takes a holistic view of risk and risk reduction, it is possible to link the importance of human factors directly to the safety integrity level of an E/E/PE system. The framework presented in Section 8 is one proposal for linking human factors requirements in system design to the safety integrity of E/E/PE systems. This is offered up for discussion and debate. As outlined in Section 8.4, there are a number of areas for discussion and areas for development within this framework. The concern over the implications of using a risk-based approach is fundamental to the role of human operators and maintainers in systems.

49

10 REFERENCES

1 CEI/IEC 61508. Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems 2 Health and Safety Executive, The Explosion and Fires at the Texaco Refinery, Milford Haven, 24 July 1994, HSE Books, 1997. 3 Lord Cullen, The Ladbroke Grove Rail Inquiry; Part 1 Report HSE Books, 2001.

51

APPENDICES

53

APPENDIX A: References to Human Factors in IEC 61508

PART 1: GENERAL REQUIREMENTS

No. Para/Page Content

Scope/Introduction

1/1 1.2 a / p15 Although a person can form a part of a safety related system, human factors requirements related to the design of E/E/PE safety-related systems are not considered in detail in this standard

1/2 1.2 j / p17 Does not cover the precautions that may be necessary to prevent unauthorised persons damaging, and/or adversely affecting, the functional safety of E/E/PE safety-related systems.

Management of Functional Safety

1/3 6.2.1 h / p29

Particular consideration should be given to …training of maintenance staff, training of operations staff and retraining at periodic intervals…

Table 1 - Overall safety lifecycle: overview

1/4 Table 1, No 3

Scope of 'hazard and risk analysis' to include human factors

1/5 Table 1, No 4

Scope of 'Overall safety requirements' to include human factors

1/6 Table 1, No 5

Scope of 'Safety requirements allocation' to include human factors

1/7 Table 1, No 6

Scope of 'Overall operations and maintenance planning' to include human factors

1/8 Table 1, No.7

Scope of 'Overall safety validation planning' to include human factors

Overall Scope Definition Stage

1/9 7.3.2.4 / p49

At concept stage, the type of accident events that need to be considered should be specified, including procedural faults and human error.

Hazard and Risk Analysis

1/10 7.4.1.1 / p51

The first objective is to determine the relevant hazards and hazardous events including… those related to the EUC in all modes of operation and all reasonably foreseeable conditions, which include misuse

1/11 7.4.2.3 / p51

Determining all hazards and hazardous events shall include consideration of all human factor issues and shall give particular attention to abnormal or infrequent modes of operation.

1/12 7.4.2.10 / p53

The hazard and risk analysis shall consider the following …

- any credit taken for operational constraints or human intervention shall be detailed

54


Safety Requirements Allocation

1/13 7.6.2.2 / p59

Note 2- the availability of skills and resources for operation and maintenance, and the operating environment may be critical to achieving the required functional safety in actual operation.

Overall Operation and Maintenance Planning

1/14 7.7 / p69, p71

A plan shall be prepared that includes:

- Routine maintenance actions

- Actions and constraints required to prevent an unsafe state, to reduce demands on the E/E/PE safety-related system, or reduce the consequences of hazardous events

- Scope of maintenance activities

- Actions to be taken in the event of hazards occurring

1/15 7.7.2.3 / p71

The maintenance plan shall be agreed with those responsible for future operation and maintenance (of the system concerned)

Overall Operation and Maintenance and Repair

1/16 7.15.2.1 / p79

The plan and procedures for operations and maintenance should be implemented.

PART 2: REQUIREMENTS FOR ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC SAFETY-RELATED SYSTEMS


E/E/PES Safety Requirements Specification

2/1 7.2.3.1 c/ p14

The E/E/PES safety functions requirements specification shall contain… E/E/PE safety-related system and operator interfaces which are necessary to achieve the required functional safety.

E/E/PES Design and Development

2/2 7.4.2.6 c/ p17

The E/E/PES developer shall review the requirements for safety-related software to ensure that they are adequately specified. In particular they shall consider… equipment and operator interfaces.

2/3 7.4.4.5 c / p22

Diagnostic coverage: On detection of a fault by an E/E/PES diagnostic system, it shall… indicate that a fault has been detected so that the EUC can be put into a safe state by manual means …

2/4 7.4.8.1 c / p30

Control of systematic faults: E/E/PES shall be designed to have tolerance against… mistakes made by the operator of the EUC.

2/5 7.4.8.3 /p30

The design of the E/E/PE safety-related system shall take into account human capabilities and limitations and shall be suitable for the actions assigned to operators and maintenance staff. The design of all interfaces shall follow good human factors practice and shall accommodate the likely level of training or awareness of operators, for example in mass-produced E/E/PE safety-related systems where the operator is a member of the public.

55


E/E/PES Operation and Maintenance Procedures

2/6 7.6.2.1 / p32

E/E/PES operation and maintenance procedures shall specify the following… the routine actions that need to be carried out to maintain the 'as designed' functional safety, the actions and constraints that are necessary to prevent an unsafe state and/or reduce the consequences of a hazardous state…

2/7 7.6.2.3 Note 1/ p33

The routine maintenance actions required to maintain the required functional safety… shall be determined by a systematic method….

Note 1: A consideration of human factors is a key element in determining the actions required and appropriate interface(s) with the E/E/PE safety-related systems

E/E/PES Safety Validation

2/8 7.7.2.3 / p34

…all the E/E/PES operation and maintenance procedures shall be validated by test and/or analysis

E/E/PES Modification

2/9 7.8.2.1 / p35

Appropriate documentation shall be established and maintained for each E/E/PES modification activity, which shall include…

b) an analysis of the modification activity on the overall systems, including hardware, software, human interaction and the environment and possible interactions.

Annex A: Techniques and Measures for Control of Failures

2/10 Table A.18 / p50

Following techniques/measures specified (in relation to SIL levels) to guard against operational failures:

- Modification protection

- Failure detection by on-line monitoring

- Input acknowledgement

- Failure assertion programming

These are described further in Part 7 of the standard

Annex B: Techniques and Measures for Avoidance of Failures

2/11 Table B.4 / p54

Techniques specified for development of operation and maintenance procedures:

- Operational and maintenance instructions

- User friendliness

- Maintenance friendliness

- Project management

- Documentation

- Limited operation possibilities

- Protection against operator mistakes

- Operation only by skilled operators

- Protection against sabotage

These are described further in Part 7 of the standard

56


2/12 Table B.6/ p56

Table indicating how certain measures may be implemented in a manner that achieves a low or high level of effectiveness. These include:

- Limited operation possibilities

- Operation only by skilled operators

- Protection against operator mistakes

PART 3: SOFTWARE REQUIREMENTS


Software Safety Requirements Specification

3/1 7.2.2.4 f/ p37

The software developer shall use the information provided in the E/E/PES specification of requirements to ensure that software requirements are adequately specified. In particular, this shall consider… equipment and operator interfaces.

Software Verification

3/2 7.9.2.13 c / p72

All modifiable parameters shall be verified for protection against… erroneous, inconsistent or unreasonable values, unauthorised changes

PART 4: DEFINITIONS AND ABBREVIATIONS


Safety Terms

4/1 3.1.11 / p21

Reasonably foreseeable misuse: use of a product, process or service under conditions or for purposes not intended by the supplier, but which can happen, induced by the product, process or service in combination with or as a result of, common human behaviour.

Equipment and Devices

4/2 3.2.4 Note 3/ p23

EUC Risk: risk arising from the EUC or its interaction with the EUC control system… note 3: assessment of this risk will include associated human factor issues.

Systems: General Aspects

4/3 3.3.1 Note 1/ p25

System: set of elements which interact according to a design, where an element of a system can be another system, called a subsystem, which may be a controlling system or a controlled system and may include hardware, software and human interaction… Note 1: a person can be part of a system.

57


Systems: Safety-Related Aspects

4/4 3.4.1 Note 5/ p30

Safety-Related System: designated system that both:

- implements the required safety functions necessary to achieve or maintain a safe state for the EUC

- is intendes to achieve or its own or with other risk-reduction measures the necessary safety integrity for the required safety functions.

Note 5: a person can be part of a safety-related system. For example, a person could receive information from a programmable electronic device and perform a safety action based on this information, or perform a safety action through a programmable electronic device.

Fault, Failure and Error

4/5 3.6.6 Note 3/ p41

Systematic failure: failure related in a deterministic way to a certain cause, which can only be eliminated by a modification of the design or the manufacturing process, operational procedures, documentation or other relevant factors. Note 3: Examples of causes of systematic failures include human error in:

- the safety requirements specification;

- the design, manufacture, installation, operation of the hardware;

- the design, implementation etc. of the software.

4/6 3.6.12 / p41

Human error, mistake: human action or inaction that can produce an unintended result

Confirmation of Safety Measures

4/7 3.8.9 / p47 Undetected, unrevealed, covert: in relation to hardware, undetected by the diagnostic tests, proof tests, operator intervention (for example physical inspection and manual tests) , or through normal operation.

PART 5: EXAMPLES OF METHODS FOR THE DETERMINATION OF SAFETY INTEGRITY LEVELS


Annex A: Risk and Safety Integrity - General Concepts

5/1 A.3 para 3/ p21

A person could be an integral part of en E/E/PE safety-related system. For example, a person could receive information on the state of the EUC, from a display screen and perform a safety action based on this information.

5/2 A.4. para 3, point 2/ p23

The general model (of risk reduction) assumes that… there are associated human factor issues

5/3 A.4. para 4, point 1/ p23

EUC risk: the risk existing for the specified hazardous events for the EUC, the EUC control system and associated human factors issues…

5/4 A.4. para 4, point 3/ p23

Residual risk: in the context of this standard, the residual risk is that remaining for the specified hazardous events for the EUC, the EUC control system, human factor issues but with the addition of external risk reduction facilities, E/E/PE safety-related systems and other technology safety-related systems.

58


Annex C: Determination of safety integrity levels - a quantitative method

5/5 C.2 para 3/ p37

The frequency associated with the risk that exists for the EUC, including the EUC control system and human factor issues (the EUC risk), without any protective features, can be estimated using quantitative risk assessment methods.

Annex D: Determination of Safety Integrity Levels - A Qualitative Method: Risk Graph

5/6 Table D.1, third entry / p51

Possibility of avoiding the hazardous event parameter includes as possible inputs:

- operation of a process (supervised (i.e. operated by skilled or unskilled persons) or unsupervised)

PART 6: GUIDELINES ON THE APPLICATION OF PARTS 2 AND 3


Annex A: Application of Parts 2 and 3

6/1 A.1 / p12, first para

Failures can arise from either physical faults in the device or from systematic faults (for example human errors made in the specification and design of a system cause systematic failure under some particular combination of inputs)…

6/2 A.1 / p13, para 6

Part 2 has been developed to provide requirements for achieving safety integrity in the hardware of the E/E/PE safety-related systems…. Where manual action is needed for functional safety, requirements are given for the operator interface.

6/3 A.2 i)/ p15 The functional steps in the application of part 2….

i) Implement the design of the E/E/PE safety-related system. Select measures and techniques to control systematic hardware failures, failures caused by environmental influences and operational failures.

Annex D: A Methodology for Quantifying the Effect of Hardware-Related Common Cause Failures in Multi-Channel Programmable Electronic Systems

6/4 Table D1, Section on Procedures/ human interface/ p55, p56

Scoring programmable electronics or sensors/actuators (note following have been significantly abridged from text in standard):

- Is there a written system of work for identifying and investigating component failures?

- Are maintenance regimes designed to prevent successive maintenance by the same persons on independent protection channels?

6/5 Table D1, Section on Competence/ training/safety culture/ p56

Have designers and maintainers been trained to understand the causes and consequences of common cause failures?

59

PART 7: OVERVIEW OF TECHNIQUES AND MEASURES


Annex B: Avoidance of systematic failures

7/1 B.4.1 / p45 Operation and maintenance instructions

To avoid mistakes during the operation and maintenance of the safety-related system

7/2 B.4.2 / p45 User friendliness

To reduce complexity during operation of the safety related system. Developed must consider relevant system design and design of the workplace to ensure that:

- the need for human intervention is kept to a minimum

- the necessary human intervention is as simple as possible

- any incorrect intervention remains harmless

- the intervention facilities and indication facilities are design according to ergonomic requirements

- the operator is not overstrained, even in extreme situations

- training on intervention procedures and facilities is adapted to the level of knowledge and motivation of the trainee user

7/3 B.4.3 / p46 Maintenance friendliness

To simplify the maintenance procedures of the safety-related system and to design the necessary means for effective diagnosis and repair. Developer should ensure:

- safety-related maintenance measures are required as seldom as possible, preferably not at all

- sufficient, sensible and easy to handle diagnosis tools are included for those repairs that are unavoidable - tools should include all necessary interfaces

7/4 B.4.4 / p46 Limited operation possibilities

To reduce the operation possibilities for the normal user by:

- limiting the operation within special operation modes, for example by key switches

- limiting the number of operating elements

- limiting the number of generally possible operating modes

7/5 B.4.5 / p46 Operation only by skilled operators

To avoid operating failures caused by misuse, ensure operator is trained to a level appropriate for the complexity and safety integrity level of the safety-related system.

7/6 B.4.6 / p46 Protection against operator mistakes

To protect the system against all classes of operator mistakes, wrong inputs are detected via plausibility checks or by monitoring of the EUC.

60


7/7 B.4.7 / p47 Protection against sabotage

In addition to measures already mentioned, implement other organisational measures, for example operator supervision.

7/8 B.4.8 / p47 Modification protection

Detection of hardware modifications by technical means through the use of measure such as plausibility checks for sensor signals and automatic start up tests.

7/9 B.4.8 / p47 Input acknowledgement

To assist an operator in detecting an error prior to activating the EUC through measures such as:

- Echoing back inputs to the operator before they are sent to the EUC

- Prevention of multiple key entries resulting in keystrokes being missed, or a repeated key press being read (because of slow system response time)

- Time outs on multiple choice questions to prevent system hanging waiting for an operator input

61

APPENDIX B: Mapping of Human Factors Processes to Safety Lifecycle

Stage Objectives Human factors related activities3

1 Concept 7.2.1:

To develop a level of understanding of the EUC and its environment (physical, legislative etc) sufficient to enable the other safety lifecycle activities to be satisfactorily carried out.

1.1

1.2

Identify stakeholders

Collect market/user/customer intelligence

2 Overall scope definition

7.3.1:

To determine the boundary of the EUC and the EUC control system;

To define the scope of the hazard and risk analysis (for example process hazards, environmental hazards, etc).

2.1

2.2

2.3

2.4

2.5

2.6

2.7

2.8

Develop human factors implementation plan

Identify and document current/proposed user tasks

Identify and document significant user attributes

Identify and document physical environment

Identify and document organisational environment

Identify and document technical environment

Evaluate concept prototypes to refine requirements

Capture stakeholder requirements

3 Hazard and risk analysis

7.4.1:

To identify the hazards and hazardous events of the EUC and the EUC control system (in all modes of operation), for all reasonably foreseeable circumstances including fault conditions and misuse;

To identify the event sequences leading to the hazardous events identified;

To determine the EUC risks associated with the hazardous events identified.

3.1

3.2

3.3

3.4

Review incident record and data (HF causes)

Perform qualitative human reliability assessment

Perform quantified human reliability assessment

Perform violations analysis

3 Those processes shown in bold type are specifically human factors activities and would normally be carried out or championed by human factors professionals.

62


4 Overall safety requirements

7.5.1:

To develop the specification for the overall safety requirements, in terms of the safety functions requirements and safety integrity requirements, for the E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities, in order to achieve the required functional safety.

Not specific to human factors

5 Safety requirements allocation

7.6.1:

To allocate the safety functions, contained in the specification for the overall safety requirements (both the safety functions requirements and the safety integrity requirements), to the designated E/E/PE safety-related systems, other technology safety-related systems and external risk reduction facilities;

To allocate a safety integrity level to each safety function.

5.1

5.2

Allocate functions and assess implications for performance/reliability

Set quality in use objectives

6 Overall operation and maintenance planning

7.7.1:

To develop a plan for operating and maintaining the E/E/PE safety-related systems, to ensure that the required functional safety is maintained during operation and maintenance.

6.1

6.2

6.3

Produce operations/maintenance task descriptions

Scope requirements for staffing levels, selection, training and job aids

Summarise assumptions on operations and maintenance practice and feed into operating rules

7 Overall safety validation planning

7.8.1:

To develop a plan to facilitate the overall safety validation of the E/E/PE safety-related systems.

7.1 Define Human Factors Testing Plan

8 Overall installation and commission-ing planning

7.9.1:

To develop a plan for the installation of the E/E/PE safety-related systems in a controlled manner, to ensure the required functional safety is achieved;

To develop a plan for the commissioning of the E/E/PE safety-related systems in a controlled manner, to ensure the required functional safety is achieved.

8.1 Define Human Factors Aspects to be addressed in audits and inspections

63


9 E/E/PE safety-related systems: realisation

7.10.1 and parts 2 and 3:

To create E/E/PE safety-related systems conforming to the specification for the E/E/PES safety requirements (comprising the specification for the E/E/PES safety functions requirements and the specification for the E/E/PES safety integrity requirements).

9.1

9.2

9.3

9.4

9.5

9.6

9.7

9.8

9.9

Establish user interface style conventions

Develop interface designs

Evaluate interface design specifications

Develop prototype interface designs

Evaluate prototype designs

Develop design of workplace and related systems

Evaluate workplace designs

Facilitate user group participation

Evaluate design to ensure stakeholder and organisation requirements are being met

10 Other technology safety-related systems: realisation

7.11.1:

To create other technology safety-related systems to meet the safety functions requirements and safety integrity requirements specified for such systems (outside the scope of this standard).

As above

11 External risk reduction

facilities: realisation

7.12.1:

To create external risk reduction facilities to meet the safety functions requirements and safety integrity requirements specified for such facilities (outside the scope of this standard).

11.1 Evaluate design of external risk reduction facilities (to check for any conflict with human performance requirements)

12 Overall installation and commission-ing

7.13.1:

To install the E/E/PE safety-related systems;

To commission the E/E/PE safety-related systems.

12.1 Perform inspections and audits of human factors aspects of system installation and performance

13 Overall safety validation

7.14.1:

To validate that the E/E/PE safety-related systems meet the specification for the overall safety requirements in terms of the overall safety functions requirements and the overall safety integrity requirements, taking into account the safety requirements allocation for the E/E/PE safety-related systems developed according to 7.6.

13.1 Execute Human Factors Testing Plan and Assess Performance against Targets

64


14 Overall operation, maintenance and repair

7.15.1:

To operate, maintain and repair the E/E/PE safety-related systems in order that the required functional safety is maintained.

14.1

14.2

Deliver personnel, training and job aids

Evaluate human performance in use

15 Overall modification and retrofit

7.16.1:

To ensure that the functional safety for the E/E/PE safety-related systems is appropriate, both during and after modification and retrofit activities have taken place.

15.1

- 15.28


Identify and document current/proposed user tasks

Identify and document current physical environment

Identify and document relevant aspects of organisational environment

Review incident record and data (HF causes)

Update qualitative human reliability assessment

Update quantified human reliability assessment


Re-allocate functions and assess implications for performance/reliability

Set quality in use objectives

Produce revised operations/maintenance task descriptions

Scope changes to staffing levels, selection, training and job aids

Summarise assumptions on future operations and maintenance practice and feed into operating rules

Define Human Factors Testing Plan

Review and establish user interface style conventions

Develop specifications for interface designs

Evaluate interface design specifications

Develop prototype interface designs

Evaluate prototype designs

65


Develop design of workplace and related systems

Evaluate location modification designs

Facilitate user group participation

Evaluate design to ensure stakeholder and

organisation requirements are being met

Evaluate design of external risk reduction facilities (to check for any conflict human performance requirements)

Perform inspections and audits of human factors aspects of system installation and performance

Execute Human Factors Testing Plan and Assess Performance against Targets

Deliver personnel, training and job aids

Evaluate human performance in use

66


16 Decommis-sioning or disposal

7.17.1:

To ensure that the functional safety for the E/E/PE safety-related systems is appropriate in the circumstances during and after the process of decommissioning or disposing of the EUC.

16.1

-

16.14


Review changes from current to proposed user tasks (at all steps in process)

Identify and document changes to current physical environment

Produce qualitative human reliability assessment for performance during disposal phase

Update quantified human reliability assessment


Re-allocate functions and assess implications for performance/reliability during disposal phases

Review quality in use objectives (and assess impact)

Produce operations/maintenance task descriptions

Scope changes to staffing levels, selection, training and job aids

Develop revised operating rules

Perform inspections and audits of human factors aspects of system decommissioning and performance

Deliver additional training and job aids

Monitor human performance during process

67

APPENDIX C: Descriptions of Human Factors Activities

Activity Description / methods

2.1 Develop human factors implementation plan

Simply this is a project plan that describes the human factors activities and deliverables that are planned for execution during the project.

This is gradually gaining popularity in the development of major bespoke systems (e.g. Network Management Centres for Railtrack required this to be submitted with the bids). This has been a requirement for naval systems for some time.

What it should consist of is not standardised as yet (except in the military sphere), but the current ISO/IEC work is getting close. This HF guidance should be defining the minimum programme requirements for IEC 61508.

2.2 Identify and document current/proposed user tasks

Before changing an existing system or embarking on a new system design, some 'handle' is required on the scope and content of what the humans in the system actually do. This may be achieved through the use of process modelling tools (e.g. SSADM, data flow), implemented through computer based modelling environments (e.g. CaseWise, System Architect) or methods with their origins in human factors (e.g. Hierarchical task analysis - HTA, TAKD - Task Analysis for Knowledge Descriptions). The purpose is to develop a set of activities and use case (scenarios) so that the richness of system and human behaviour is understood.

Tasks may have to imagined at this stage (at a high, conceptual level), with aspirations for the role and activities of the users, managers and other stakeholders. These aspirations may be explored through 'task synthesis' (logical top-down derivation of tasks).

This later become critical in setting up scenarios for evaluation and in establishing new/revised operating procedures.

2.3 Identify and document significant user attributes

Some understanding is required of the user population, their backgrounds, experience, educational levels, literacy, culture and physical characteristics. It is not unknown for systems to be designed for average height, Caucasian, university educated engineers, to be operated by Asians with a craft apprenticeship background (and English as their third language)!

Most systematic approach adopted in this arena is that required under the US military MANPRINT directive. This requires a 'Target Audience Description' to be defined. This is of particular importance with systems that might take ten years to be delivered (when the educational pool for recruits will have changed) and will call upon hundreds or possibly thousands of personnel to operate and maintain. Such formalism may be overly complicated for smaller projects.

68


2.4 Identify and document physical environment

This may involve a simple survey or a questionnaire study. The techniques here that can help are ergonomic checklists for the physical environment; environmental measurements (heat, noise spectrum, lighting, air movements); user questionnaires and expert evaluation (experienced, qualified human factors engineer).

2.7 Evaluate concept prototypes to refine requirements

Many users will not know what they want until they see it (except that they know that it is not what they have got now)! There is value in developing low fidelity mock-ups, storyboards, concept demonstrators with the purpose of eliciting their requirements. This can also reveal additional scenarios and uses that would not have otherwise been revealed.

A key aspect of this process is that they should not just be shown the demonstrator and asked what they think, but should role play and simulate operational scenarios to explore the ideas in context. Plenty of advice available in reports, not aware of any formalised methods.

3.2 Perform qualitative human reliability assessment

This identifies the possible forms of human error that could generate a demand upon the safety related system or may cause a human fault recovery action to fail.

Most human reliability assessment approaches take a systematic analytic approach to identifying errors which arise from slips or lapses; the expected tasks are examined one-by-one and some form of prompt applied to identify possible failure modes, hazards and consequences. Techniques include Human HAZOP, SHERPA and TAFEI. The output may be in the form of training, procedures or design requirements.

This type of approach is exhaustive and resource intensive. It is possible to identify potential human errors at a higher grain level of detail by building people aspects into overall system hazard identification methods (e.g. Hazops). For complex sociotechnical systems (e.g. railways which involve not only technology, but customers, and a high level of proceduralised human control), the systems models may provide the representation upon which such hazops can be applied. This is covered in DefStan 00-58.

An appropriate approach is to build 'people processes' into the high level hazard identification studies, then identify sources of possible human threat to the system and new/novel operations. These can then be assessed using the detailed methods.

69


3.3 Perform quantified human reliability assessment

Quantification of human error is only required if a probabilistic approach is being taken to assessing risk reduction requirements. This is one of the options given in IEC 61508.

There are a number of methods for quantifying human reliability. These split into three general categories:

• Human error databases. These are few and far between, though there is a current initiative (CORE-DATA) to start to build a cross-industry repository of data. The problem with such data is that it is very situation/industry specific and difficult to extrapolate. It is vital to know the context of a particular value before using it. Hence, lists of human error figures quoted in some text books can be dangerous as it encourages use of data out of context;

• Human reliability prediction techniques. These techniques, largely sourced from the nuclear industries, provide a structured way of extrapolating from a given database of nominal error probability values to specific sets of circumstances (e.g. effects of stress, poor user interface design, inadequate supervision). These include THERP (widely used in US Nuclear industry), HEART (becoming the technique with widest application) and ASEP (a cut-down version of THERP for use in determining scoping values). These may require specific modelling of human error sequences, consideration of dependency effects and sensitivity analysis;

• Human reliability estimation techniques. These use the judgements of task performers and experts to estimate human reliability values. They can involve repeated comparisons between pairs of errors (this is more likely to happen than that) and absolute judgements of human reliability values. Often it is necessary to have some known 'anchor values' from which the other values can be calculated. Being statistically based, it is possible to estimate the level of confidence in the values derived by use of statistical analysis of the judgements provided.

There are still many difficulties in arriving at accurate human reliability predictions, but for system safety analysis, it often possible to proceed on the basis of the types of techniques already in existence, utilising pessimistic data to minimise underestimating human error potential. This does, however, become problematic when attempting to assess design trade-offs where figure needs to be more accurate.

Also, human error data and predictive models only really effectively apply to routine, skilled tasks and the related types of error (i.e. slips and lapses). Errors driven by misunderstandings, incorrect planning and erroneous diagnoses are not effectively covered.

70


3.4 Perform violations analysis

Whilst errors are unintentional, violations are unwanted or incorrect actions performed intentionally (or actions deliberately missed out where required under operating procedures). It is a requirement under IEC 61508 that the potential for misuse and abuse is assessed, so there is a role for performing such assessments. Also, the design of system may make normal operations difficult or overly complicated and encourage the use of dangerous short cuts. Such potential does need to be assessed.

There does exist a tool for studying violations that has been published by the HSE (Improving Compliance with Safety Procedures, HFRG). This has a large component that addresses safety management and culture, which may not be applicable at a design stage. However, many set of human factors design guidelines identify possible types of violations that can occur (and provide one form of checking mechanism). Also, violations can be identified as part of a qualitative human reliability assessment (e.g. by adding keywords to a human HAZOP session).

5.1 Allocate functions and assess implications for performance/reliability

Based on the assumption that operators form part of a system, there will a number of safety related functions which they be required to perform. It is likely that there will be a limited number of functions where humans directly control high levels of safety risk (note: this is the case in air traffic control). However, there is likely to be reliance on humans for a significant number of functions that support safe operations (e.g. management of maintenance) and to provide a means of recovery for 'beyond design basis' accident sequences.

Part of the human factors engineering approach is explicitly consider and allocate functions between equipment and operational staff. This is directly in line with the philosophy in IEC 61508 and with the latest generations of system engineering standards. However, in the past, it can be argued that functions were allocated to humans by 'default', automating what could be automated and leaving operational staff to integrate all the functions 'left over'. It is not suprising that when it is necessary to rely upon human recovery, the operators are unable to perform the tasks asked of them.

Methods of objectively allocating functions have been under development since the early 1950's. There has been a resurgence of interest in recent years. Techniques, or frameworks are available that give some assistance in selecting appropriate allocations (e.g. STMDWS). However, the key method is to identify possible allocations and then to 'assess the resulting system performance'. This might include looking at human reliability, workload, but will include aspects of assessing job design, skill retention etc. It is clear that development is still ongoing in this area and is going to become an increasingly important area of development as systems get more sophisticated and human roles are pushed to the areas of supervision, decision making, problem solving and recovery.

71


5.2 Set quality in use objectives

As part of the human factors engineering process, it is valuable to set targets against which the system can be measured. This is familiar to control system engineers as part of acceptance testing the hardware aspects of systems. It is more novel (and difficult) to derive appropriate, measurable targets or objectives for human performance that can be used at the acceptance testing phase of a system (i.e. before it is connected to the real world). Work has been going on in this area for a number of years and is embodied in Part 11 of EN ISO 29241 on 'usability statements'. However, there can still be difficulties in identifying suitable, meaningful objectives or parameters that can be objectively measured at the appropriate points during the system lifecycle.

6.1 Produce operations/maintenance task descriptions

This is an extension of activity 2.2, refining and extending task descriptions as operational/maintenance roles are defined and the system developed.

7.1 Define Human Factors Testing Plan

This is linked with activity 5.2 in defining exactly how the human factors aspects of the system under development are to be validated. Such a plan may be implicit in a contractual strategy (e.g. defining deliverables and acceptance points), but there is the danger that unless such a plan is made explicit, the appropriate testing will not be carried out at appropriate points in the system lifecycle. Forming a plan forces consideration of how the system will be tested, by whom and defines what time/resources/support will need to be provided.

9.1 Establish user interface style conventions

'Consistency' and 'compatibility with user expectations' are two critical aspects of interface design, supporting both ease of learning and reliability in use. This can be assisted by defining up-front user interface conventions. This may include aspects such as colour usage (e.g. for colour coding of alarms and other information), dialogue methods (e.g. use of menus, provision of confirmation dialogues for critical actions), terminology and symbology.

Assistance for selecting standard design rules is provided by a wide range of available human factors design guidelines and some standards (e.g. parts of EN ISO 29241). User interface development environments will also assist in providing some standardisation of basic components through the 'widgets' provided and in style guides (e.g. OSF Motif, IBM CUA). An organisation or an industry may also choose to define the most critical conventions in a standard or code of practice.

72


9.3 Evaluate interface design specifications

The first step of design evaluation can take place before any significant code has been written by performing assessments on user interface design specifications. These may consist of an independent review of any proposed style guide (i.e. as described in 9.1), review of screen layouts and evaluation of proposed dialogue structures and flows.

These assessments can include evaluation against human factors interface design principles (heuristic evaluation), verification of the accuracy and clarity of display designs and walkthrough evaluations of a selection of standard tasks (scenario-based evaluation). These assessments are likely to require some human factors expertise, but will also utilise representative operators. Checklists of relevant criteria and sets of test case scenarios can be used to assist these processes.

9.5 Evaluate prototype designs

As the system is developed, it may be evaluated at a number of stages. As soon as screen displays are available and basic dialogue features established, evaluations may be performed by 'walking through' operational scenarios, common operations and emergency actions. For real-time control systems, later evaluations may examine use under dynamic conditions using simulator data or even inputs provided manually by technicians following a timed script (''Wizard of Oz' technique). Finally, acceptance testing may involve exercising the system under near real time conditions and with realistic data.

Such evaluations require a systematic approach to capture objective problems and subjective evaluations. This can include the use of a 'usability laboratory' which is a specific facility set up to provide a controlled environment to test systems and a means of capturing and analysing relevant data. These often include sophisticated video recording systems, event recording systems and playback/analysis systems. Performance may be assessed by identifying errors from the observational data, measuring performance times, measuring workload (e.g. using NASA-TLX or other physiological measures), obtaining subjective satisfaction ratings and post trial de-briefing. Subjects may be encouraged to 'think aloud' (verbal protocol analysis) or to work in pairs (co-operative evaluation) to obtain another source of data.

The measures used will depend upon the nature of the application and the critical usability objectives or targets that need to be assessed. It may not be necessary to go to the extent of using a specialised laboratory, but it is important that controlled and systematic methods are used to ensure that such testing is rigorous and fair.

73


9.7 Evaluate workplace designs

A range of approaches can be used to evaluate the working environment and consoles etc. As with evaluations of operator interfaces, this can be assessed against general principles and against task scenarios. Assessments can be performed using design drawings, CAD models, full scale mock-ups and in the delivered environment. An assessment against ergonomic principles and data may include the use of guidelines (as included in the emerging control centre standard, ISO 11064) and checking of dimensions against anthropometric data. Task-based methods that may be applied include validation against user task requirements, examining the sequence of physical and visual activities (link analysis) and running user trials. Environmental measurements may also be applied to the delivered environment examining temperature, humidity, air movements, lighting and noise levels.

11.1 Evaluate design of external risk reduction facilities (to check for any conflict with human performance requirements)

Where external risk reduction facilities have been applied (e.g. bunds, blast walls, remote location of manned control points), it may be necessary to check that the new facilities will not have a detrimental effect on other safety-related tasks (e.g. local operations, inspection, maintenance access). This can use the same approaches as outlined in 9.7.

14.2 Evaluate human performance in use

IEC 61508 takes a full lifecycle approach and recognises that the process of evaluating safety needs to be carried through into operations. This can apply particularly to the human factors aspects of a system, since problems may not emerge until operations have settled down or particular unusual or abnormal events occur.

Evaluations in use can include a specific questionnaire or observational survey once the system is in use, setting up a confidential near miss reporting system (since human errors are frequently recovered before they cause an accident, so no record exists otherwise) and appropriate root cause analysis of incidents with an apparent human cause. Often pathological failures in system design are revealed in minor incidents before they contribute to a major incident and could be identified through appropriate analysis.

APP

END

IX D

: Exa

mpl

es o

f Hum

an F

acto

rs S

tand

ards

Ref

eren

ce

Title

Ye

ar

Part

Pa

rt T

itle

Stat

us

Def

-Sta

n 00

-25

Hum

an fa

ctor

s for

des

igne

rs o

f equ

ipm

ent

1989

12

Sy

stem

s In

terim

IEC

609

64

Des

ign

for c

ontro

l roo

ms t

o nu

clea

r pow

er p

lant

s 19

89

Issu

ed

IEEE

845

IE

EE g

uide

to e

valu

atio

n of

hum

an-m

achi

ne

perf

orm

ance

in N

ucle

ar P

ower

gen

erat

ing

stat

ions

19

99

Issu

ed

IEEE

102

3 IE

EE G

uide

for t

he a

pplic

atio

n of

hum

an fa

ctor

s en

gine

erin

g to

syst

ems,

equi

pmen

t and

faci

litie

s of

Nuc

lear

Pow

er g

ener

atin

g st

atio

ns

1988

Is

sued

IEEE

108

2 G

uide

for i

ncor

pora

ting

hum

an a

ctio

n re

liabi

lity

anal

ysis

fo

r Nuc

lear

Pow

er g

ener

atin

g st

atio

ns

1997

Is

sued

IEEE

128

9 IE

EE g

uide

for t

he a

pplic

atio

n of

hum

an fa

ctor

s en

gine

erin

g in

the

desi

gn o

f com

pute

r-ba

sed

mon

itorin

g an

d co

ntro

l dis

play

s for

Nuc

lear

Pow

er g

ener

atin

g st

atio

ns

1998

Is

sued

ISO

638

5 Er

gono

mic

prin

cipl

es in

the

desi

gn o

f wor

k sy

stem

s 19

81

Issu

ed

Ergo

nom

ic re

quire

men

ts fo

r off

ice

wor

k w

ith v

isua

l di

spla

y te

rmin

als (

VD

Ts)

1992

2

Gui

danc

e on

task

requ

irem

ents

Is

sued

IS

O 9

241

19

98

11

Gui

danc

e on

usa

bilit

y sp

ecifi

catio

n an

d m

easu

res

Issu

ed

ISO

110

64

Ergo

nom

ic d

esig

n of

con

trol c

entre

s -

1 Pr

inci

ples

for t

he d

esig

n of

con

trol c

entre

s D

raft

ISO

134

07

Hum

an-c

ente

red

desi

gn p

roce

sses

for i

nter

activ

e sy

stem

s 19

99

Issu

ed

ISO

169

82

Ergo

nom

ics o

f hum

an-s

yste

m in

tera

ctio

n - U

sabi

lity

met

hods

supp

ortin

g hu

man

cen

tred

desi

gn

-

U

nder

de

velo

pmen

t

ISO

/TR

185

29

Ergo

nom

ics -

erg

onom

ics o

f hum

an-c

ompu

ter i

nter

actio

n - H

uman

-cen

tere

d lif

ecyc

le p

roce

ss d

escr

iptio

ns

2000

Te

chni

cal r

epor

t

75

Ref

eren

ce

Title

Ye

ar

Part

Pa

rt T

itle

Stat

us

ISO

193

58

Ergo

nom

ic a

sses

smen

t of s

peec

h te

chno

logy

syst

ems

(aut

omat

ic sp

eech

reco

gniti

on a

nd sy

nthe

sis)

-

Und

er

deve

lopm

ent

MIL

-HD

BK

468

55A

H

uman

eng

inee

ring

prog

ram

pro

cess

and

pro

cedu

res

1999

Is

sued

MIL

-STD

147

2F

Hum

an e

ngin

eerin

g 19

99

Issu

ed

Printed and published by the Health and Safety ExecutiveC1 10/01

CRR 373

£15.00 9 780717 621149

ISBN 0-7176-2114-6

CONTRACT RESEARCH REPORT 373/2001 - HSE: … · CONTRACT RESEARCH REPORT 373/2001. HSE ......

Documents

Transcript of CONTRACT RESEARCH REPORT 373/2001 - HSE: … · CONTRACT RESEARCH REPORT 373/2001. HSE ......