BS EN 62508:2010

BSI Standards Publication

Guidance on human aspects of

dependability

NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

raising standards worldwide™

BS EN 62508:2010 BRITISH STANDARD

National foreword
This British Standard is the UK implementation of EN 62508:2010. It is
identical to IEC 62508:2010.
The UK participation in its preparation was entrusted to Technical Committee
DS/1, Dependability and terotechnology.
A list of organizations represented on this committee can be obtained on
request to its secretary.
This publication does not purport to include all the necessary provisions of a
contract. Users are responsible for its correct application.
© BSI 2010
ISBN 978 0 580 61716 4
ICS 03.120.01

Compliance with a British Standard cannot confer immunity from

legal obligations.

This British Standard was published under the authority of the Standards
Policy and Strategy Committee on 30 November 2010.

Amendments issued since publication

Date Text affected

EUROPEAN STANDARD EN 62508
NORME EUROPÉENNE
EUROPÄISCHE NORM October 2010

ICS 03.120.01

English version

Guidance on human aspects of dependability

(IEC 62508:2010)

Lignes directrices relatives aux facteurs Leitlinien zu den menschlichen Aspekten

humains dans la sûreté de fonctionnement der Zuverlässigkeit
(CEI 62508:2010) (IEC 62508:2010)

This European Standard was approved by CENELEC on 2010-10-01. CENELEC members are bound to comply
with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard
the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on
application to the Central Secretariat or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CENELEC member into its own language and notified
to the Central Secretariat has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus,
the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy,
Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia,
Spain, Sweden, Switzerland and the United Kingdom.

CENELEC
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung

Management Centre: Avenue Marnix 17, B - 1000 Brussels

© 2010 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.

Ref. No. EN 62508:2010 E

BS EN 62508:2010
EN 62508:2010 - ii -

Foreword
The text of document 56/1365/FDIS, future edition 1 of IEC 62508, prepared by IEC TC 56,
Dependability, was submitted to the IEC-CENELEC parallel vote and was approved by CENELEC as
EN 62508 on 2010-10-01.

Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN and CENELEC shall not be held responsible for identifying any or all such patent
rights.

The following dates were fixed:

– latest date by which the EN has to be implemented

at national level by publication of an identical
national standard or by endorsement (dop) 2011-07-01

– latest date by which the national standards conflicting

with the EN have to be withdrawn (dow) 2013-10-01

Annex ZA has been added by CENELEC.

__________

Endorsement notice
The text of the International Standard IEC 62508:2010 was approved by CENELEC as a European
Standard without any modification.

In the official version, for Bibliography, the following notes have to be added for the standards indicated:
IEC 60812:2006 NOTE Harmonized as EN 60812:2006 (not modified).

ISO 6385:2004 NOTE Harmonized as EN ISO 6385:2004 (not modified).

ISO 9000:2005 NOTE Harmonized as EN ISO 9000:2005 (not modified).

ISO 9241-1:1997 NOTE Harmonized as EN ISO 9241-1:1997 (not modified).

ISO 9241-2:1992 NOTE Harmonized as EN ISO 9241-2:1993 (not modified).

ISO 9241-3:1992 NOTE Harmonized as EN 29241-3:1993 (not modified).

ISO 9241-4:1998 NOTE Harmonized as EN ISO 9241-4:1998 (not modified).

ISO 9241-5:1998 NOTE Harmonized as EN ISO 9241-5:1999 (not modified).

ISO 9241-6:1999 NOTE Harmonized as EN ISO 9241-6:1999 (not modified).

ISO 9241-7:1998 NOTE Harmonized as EN ISO 9241-7:1998 (not modified).

ISO 9241-8:1997 NOTE Harmonized as EN ISO 9241-8:1997 (not modified).

ISO 9241-9:2000 NOTE Harmonized as EN ISO 9241-9:2000 (not modified).

ISO 9241-11:1998 NOTE Harmonized as EN ISO 9241-11:1998 (not modified).

ISO 9241-12:1998 NOTE Harmonized as EN ISO 9241-12:1998 (not modified).

ISO 9241-13:1998 NOTE Harmonized as EN ISO 9241-13:1998 (not modified).

ISO 9241-15:1997 NOTE Harmonized as EN ISO 9241-15:1997 (not modified).

ISO 9241-16:1999 NOTE Harmonized as EN ISO 9241-16:1999 (not modified).

ISO 9241-17:1998 NOTE Harmonized as EN ISO 9241-17:1998 (not modified).

 BS EN 62508:2010
- iii - EN 62508:2010

ISO 9241-20:2008 NOTE Harmonized as EN ISO 9241-20:2009 (not modified).

ISO 9241-110:2006 NOTE Harmonized as EN ISO 9241-110:2006 (not modified).

ISO 9241-151:2008 NOTE Harmonized as EN ISO 9241-151:2008 (not modified).

ISO 9241-171:2008 NOTE Harmonized as EN ISO 9241-171:2008 (not modified).

ISO 9241-210:2010 NOTE Harmonized as EN ISO 9241-210:2010 (not modified).

ISO 9241-300:2008 NOTE Harmonized as EN ISO 9241-300:2008 (not modified).

ISO 9241-302:2008 NOTE Harmonized as EN ISO 9241-302:2008 (not modified).

ISO 9241-303:2008 NOTE Harmonized as EN ISO 9241-303:2008 (not modified).

ISO 9241-304:2008 NOTE Harmonized as EN ISO 9241-304:2008 (not modified).

ISO 9241-305:2008 NOTE Harmonized as EN ISO 9241-305:2008 (not modified).

ISO 9241-306:2008 NOTE Harmonized as EN ISO 9241-306:2008 (not modified).

ISO 9241-307:2008 NOTE Harmonized as EN ISO 9241-307:2008 (not modified).

ISO 9241-400:2007 NOTE Harmonized as EN ISO 9241-400:2007 (not modified).

ISO 9241-410:2008 NOTE Harmonized as EN ISO 9241-410:2008 (not modified).

ISO 11064-1 NOTE Harmonized as EN ISO 11064-1.

ISO 11064-2 NOTE Harmonized as EN ISO 11064-2.

ISO 11064-3 NOTE Harmonized as EN ISO 11064-3.

ISO 11064-4 NOTE Harmonized as EN ISO 11064-4.

ISO 11064-5 NOTE Harmonized as EN ISO 11064-5.

ISO 11064-6 NOTE Harmonized as EN ISO 11064-6.

ISO 11064-7 NOTE Harmonized as EN ISO 11064-7.

__________
BS EN 62508:2010
EN 62508:2010 - iv -

Annex ZA
(normative)

Normative references to international publications

with their corresponding European publications

The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.

NOTE When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.

Publication Year Title EN/HD Year

IEC 60300-1 2003 Dependability management - EN 60300-1 2003
Part 1: Dependability management systems
IEC 60300-2 - Dependability management - EN 60300-2 -
Part 2: Guidelines for dependability
management
IEC 60300-3-15 - Dependability management - EN 60300-3-15 -
Part 3-15: Application guide - Engineering of
system dependability
 BS EN 62508:2010
–4– 62508 © IEC:2010

CONTENTS
INTRODUCTION.....................................................................................................................6
1 Scope ...............................................................................................................................7
2 Normative references .......................................................................................................7
3 Terms, definitions and abbreviations ................................................................................7
3.1 Terms and definitions ..............................................................................................7
3.2 Abbreviations ........................................................................................................ 10
4 Human aspects............................................................................................................... 10
4.1 Overview ............................................................................................................... 10
4.2 Components of the system and their interactions................................................... 11
4.2.1 Introductory remark ................................................................................... 11
4.2.2 Goals......................................................................................................... 11
4.2.3 Humans ..................................................................................................... 12
4.2.4 Machine (interactive system) ..................................................................... 12
4.2.5 Social and physical environment................................................................ 13
4.2.6 Output ....................................................................................................... 13
4.2.7 Feedback from the machine to the person ................................................. 13
4.3 Human characteristics ........................................................................................... 14
4.3.1 Introductory remark ................................................................................... 14
4.3.2 Human limitations ...................................................................................... 14
4.3.3 Comparison of humans and machines ....................................................... 14
4.4 Human performance shaping factors ..................................................................... 15
4.4.1 External performance shaping factors........................................................ 16
4.4.2 Internal performance shaping factors ......................................................... 16
4.5 Human reliability analysis (HRA) ........................................................................... 16
4.5.1 Overview ................................................................................................... 16
4.5.2 Identifying the potential for human error .................................................... 17
4.5.3 Analysing human failures to define countermeasures ................................ 17
4.5.4 Quantification of human reliability .............................................................. 18
4.6 Critical systems ..................................................................................................... 18
4.7 Human-centred design guidelines.......................................................................... 19
4.8 Human-centred design process ............................................................................. 20
4.8.1 Human-centred design principles within the design process ...................... 20
4.8.2 Human-centred design activities ................................................................ 21
5 Human-oriented design in the system lifecycle ............................................................... 21
5.1 Overview ............................................................................................................... 21
5.2 The system life cycle ............................................................................................. 22
5.3 Integrating human-oriented design in systems engineering.................................... 23
6 Human-oriented design at each life cycle stage .............................................................. 24
6.1 Overview ............................................................................................................... 24
6.2 Concept/definition stage ........................................................................................ 24
6.2.1 Concept..................................................................................................... 24
6.2.2 Human-centred design planning ................................................................ 24
6.2.3 Understanding needs................................................................................. 25
6.2.4 System requirements ................................................................................. 25
6.2.5 Human-centred design requirements ......................................................... 25
BS EN 62508:2010
62508 © IEC:2010 –5–

6.3 Design/development .............................................................................................. 26

6.4 Realization/implementation.................................................................................... 26
6.5 Operation/maintenance ......................................................................................... 27
6.6 Enhancement ........................................................................................................ 27
6.7 Retirement/decommission ..................................................................................... 28
6.8 Outsourcing projects and related human-centred design issues............................. 28
7 Human-centred design methods ..................................................................................... 29
7.1 Classification of human-centred design activities................................................... 29
7.2 Applications of human-centred design methods ..................................................... 30
Annex A (informative) Examples of HRA methods ................................................................ 31
Annex B (informative) Summary of human-oriented design activities and their impact
on system dependability ....................................................................................................... 37
Annex C (informative) Best practices for human-centred design........................................... 41
Bibliography.......................................................................................................................... 47

Figure 1 – Components of the system and their interactions ................................................. 11

Figure 2 – Human performance shaping factors .................................................................... 16
Figure 3 – Simple model of human information processing.................................................... 17
Figure 4 – Human-centred design activities .......................................................................... 21
Figure 5 – Human aspects of the system life cycle ................................................................ 23

Table 1 – People who influence dependability....................................................................... 12

Table A.1 – HRA methods and their application .................................................................... 31
Table B.1 – Automation ........................................................................................................ 37
Table B.2 – Design for maintainability ................................................................................... 37
Table B.3 – Computer-human interface ................................................................................. 38
Table B.4 – Incorporation of displays, controls and alarm functions ...................................... 39
Table B.5 – Incorporation of input devices ............................................................................ 39
Table B.6 – Environment....................................................................................................... 40
Table B.7 – Safety ................................................................................................................ 40
Table B.8 – Security ............................................................................................................. 40
Table C.1 – Examples of methods and techniques that contribute to best practices .............. 41
 BS EN 62508:2010
–6– 62508 © IEC:2010

INTRODUCTION

This International Standard provides guidelines on human aspects of dependability of

systems. It fills the need for a standard to address the dependability of human/machine
systems.

It gives guidance on how the human aspects of dependability can be considered at all the
system life cycle stages, including ergonomic principles during design and human reliability
understanding for system applications.

This standard provides an overview of the principles with some examples of the types of
methods that can be used.

It is intended that a supporting standard, which describes more detailed methods that include
quantification of human reliability will follow the issue of this standard in due course.

This standard contains recommendations, and does not include any requirements. Attention is
drawn to the possibility of the existence of regulatory requirements for systems covered by
the scope of this standard.
BS EN 62508:2010
62508 © IEC:2010 –7–

GUIDANCE ON HUMAN ASPECTS OF DEPENDABILITY

1 Scope

This International Standard provides guidance on the human aspects of dependability, and
the human-centred design methods and practices that can be used throughout the whole
system life cycle to improve dependability performance. This standard describes qualitative
approaches. Examples of quantitative methods are given in Annex A.

This International Standard is applicable to any area of industry where human/machine

relationships exist, and is intended for use by technical personnel and their managers.

This International standard is not intended to be used for certification, regulatory or

contractual use.

2 Normative references

The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.

IEC 60300-1:2003, Dependability management – Part 1: Dependability management

systems

IEC 60300-2, Dependability management – Part 2: Guidelines for dependability management

IEC 60300-3-15, Dependability management – Part 3-15: Application guide – Engineering of

system dependability

3 Terms, definitions and abbreviations

For the purposes of this document, the following terms, definitions and abbreviations apply.

NOTE Certain terms have been taken from the draft text of the second edition of IEC 60050-191, International
Electrotechnical Vocabulary – Part 191: Dependability, currently under consideration.

3.1 Terms and definitions

3.1.1
dependability
ability to perform as and when required 1

NOTE 1 Dependability characteristics include availability and its inherent or external influencing factors, such as
reliability, fault tolerance, recoverability, integrity, security, maintainability, durability and maintenance support.

NOTE 2 Dependability is also used descriptively as an umbrella term for time-related quality characteristics of a
product or service, and it can also be expressed as a grade, degree, confidence or probability of fulfilling a defined
set of characteristics.

NOTE 3 Specifications for dependability characteristics typically include: the function the product is to perform;
the time for which that performance is to be sustained; and the conditions of storage, use and maintenance.
Requirements for safety, efficiency and economy throughout the life cycle can also be included.

___________
1 Future IEC 60050-191, definition 191-41-26, second edition, under consideration.
 BS EN 62508:2010
–8– 62508 © IEC:2010

3.1.2
ergonomics
human factors
HF
scientific discipline concerned with the understanding of interactions among human and other
elements of a system that applies theory, principles, data and methods to design in order to
optimize human well-being and overall system performance

[ISO 6385:2004, definition 2.3, modified]

3.1.3
error resistance
ability of a system to minimize the probability of human error occurring

3.1.4
error tolerance
ability of a system or component to continue normal operation despite the presence of
erroneous inputs

[ISO/IEC 24765:2009, definition 3.1034]

3.1.5
human aspects
abilities, limitations, and other human characteristics that are relevant to the design, operation
and maintenance of systems and/or their components affecting overall system performance

3.1.6
human-centred design
approach to system design and development that aims to make interactive systems more
usable by focussing on the use of the system, applying human factors, ergonomics and
usability knowledge and techniques

NOTE 1 Usable systems provide a number of benefits including improved productivity, enhanced user well-being,
avoidance of stress, increased accessibility, and reduced risk of harm.

NOTE 2 This standard uses the term "human-oriented design" to refer to the need to take account of humans in
system design, but retains the term "human-centred design" used in ISO standards to refer to the specific
principles and activities.

NOTE 3 The term “human-centred design” is used rather than “user-centred design” in order to emphasize that this
standard addresses a number of stakeholders, not just those typically considered as users. However, in practice,
these terms are often used synonymously.

[ISO 9241-210:–, definition 2.7, modified] 2

3.1.7
human error
discrepancy between the human action taken or omitted, and the action intended 3

3.1.8
human error probability
HEP
probability that an operator will fail in an assigned task

NOTE 1 This can be based on the ratio of the average number of errors within a certain task in relation to the
overall number of error possibilities for this type of task.

___________
2 To be published.
3 Future IEC 60050-191, definition 191-43-13, second edition, under consideration.
BS EN 62508:2010
62508 © IEC:2010 –9–

NOTE 2 Human error probability is expressed in a distribution where the distribution needs to be determined in
accordance with the human variations and situational variations under which the task needs to be conducted.

3.1.9
human failure
deviation from the human action required to achieve the objective, regardless of the cause of
that deviation

NOTE For any particular system or situation the range of human failures is the combination of human errors and
violations that lead to system failures and/or hazardous outcomes.

3.1.10
human-oriented design
takes a user-centric approach to design by adapting technologies to meet human performance
requirements, account for human limitations, achieve mental comfort and enhance overall
system performance

3.1.11
human reliability
capability of human beings to complete a task under a given condition within a defined period
of time and within the acceptance limits

3.1.12
human reliability analysis
HRA
systematic process to evaluate human reliability

NOTE Evaluation methods can be just qualitative but can be expanded to provide quantitative results.

3.1.13
mistake
deficiency or failure in the judgemental or inferential process involved in selection of an
objective or in specification of the means to achieve it irrespective of whether or not the
actions run according to plan

3.1.14
performance shaping factors
characteristics of the external environment, of the task and of humans that shape individual
performance

3.1.15
requirement
need or expectation that is stated, generally implied or obligatory

[ISO 9000:2005, definition 3.1.2]

NOTE In the context of this standard, this is a need or expectation which should be met or possessed by a
system, system component, product, or service.

3.1.16
situational awareness
human perception of the elements in the environment within a volume of time and space, the
comprehension of their meaning and the projection of their status in the near future

3.1.17
system
set of interrelated or interacting elements

[ISO 9000:2005, definition 3.2.1]

 BS EN 62508:2010
– 10 – 62508 © IEC:2010

NOTE 1 In the context of dependability, a system will have:

 a defined purpose expressed in terms of intended functions;
 stated conditions of operation/use; and
 defined boundaries.

NOTE 2 The structure of a system may be hierarchical.

[IEC 60300-1:2003, definition 3.6]

NOTE 3 For some systems, such as information technology products, data is an important part of the system
elements.

NOTE 4 Humans can form part of a system.

3.1.18
violation
deliberate but not necessarily reprehensible deviation from practices deemed necessary
3.2 Abbreviations
ASEP Accident Sequence Evaluation Program
ATHEANA A Technique for Human Error ANAlysis
CAD Computer Aided Design
CAHR Connectionism Assessment of Human Reliability
CARA Controller Action Reliability Assessment
COTS Commercial Off The Shelf
CPC Common Performance Condition
CREAM Cognitive Reliability and Error Analysis Method
EFC Error Forcing Context
ESAT ExpertenSystem zur Aufgaben-Taxonomie (expert system for task taxonomy)
FMEA Failure Modes and Effects Analysis
FMECA Failure Modes Effects and Criticality Analysis
HCD Human-Centred Design
HCR Human Cognitive Reliability
HEART Human Error Assessment and Reduction Technique
HEP Human Error Probability
HF Human Factors
HRA Human Reliability Analysis
HR Human Resources
HS Human System
HSI Human System Interaction
ILS Integrated Logistics Support
MERMOS Méthode d’Evaluation de la Réalisation des Missions Opérateur pour la Sûreté
(method for the evaluation of the relisation of an operator’s mission regarding
safety)
ORE Operator Reliability Experiments
PSF Performance Shaping Factor
RR Reliability Rating
SHERPA Systematic Human Error Reduction and Prediction Approach
SLI Success Likelihood Index
SLIM Success Likelihood Index Methodology
SPAR-H Standardized Plant Analysis Risk
THERP Technique for Human Error Rate
UI User Interface

4 Human aspects

4.1 Overview

Human actions can have a strong influence on the dependability of the whole system and the
quality of the output. Therefore important benefits accrue from consideration of human
aspects, among which are preventing failures, improving system performance, ensuring
safety, increasing reliability and enhancing cost effectiveness. A system that requires human
BS EN 62508:2010
62508 © IEC:2010 – 11 –

interaction involves human(s), machine(s) and the social and physical environment in which
they operate. The dependability of the system and the efficiency and effectiveness with which
the goals of the system are achieved depend on each component of the system individually
and the interactions between them (Figure 1).

Social and physical

environment

Goals Human Output

Individual
characteristics, skills Machine
and experience (Interactive
system)
Individual human
performance

Feedback IEC 1541/10

Figure 1 – Components of the system and their interactions

The grey arrows represent the performance shaping factors (PSFs) (described in 4.4).

The components shown in Figure 1 are as follows.

• Goals: what the work system has to achieve ( 4.2.2).

• Human: person who performs the task ( 4.2.3).
• Machine: interactive system designed to support achievement of the work system goals
( 4.2.4).
• Environment: social and physical factors that can influence the human(s) and machine
( 4.2.5).
• Output: that which should be achieved with the required level of effectiveness and
efficiency ( 4.2.6).
• Feedback: feedback coming from the machine ( 4.2.7).

4.2 Components of the system and their interactions

4.2.1 Introductory remark

This subclause describes each component of Figure 1.

4.2.2 Goals

The objective of the work system is to achieve goals with a desired effectiveness and
efficiency.
 BS EN 62508:2010
– 12 – 62508 © IEC:2010

4.2.3 Humans

The role of humans in the system is to perform a task or interact with a machine in order to
achieve a defined goal. The human operator can either have a monitoring role (such as in a
process control or road traffic control room), or an active role (for example when resolving a
road traffic incident).

Human influence can both be negative (e.g. human errors and violations) or positive (e.g.
preventing system breakdowns or system problems). Humans can influence the system
through action or inaction. Even in an automated system a human is part of the system,
through design, maintenance and monitoring functions.

A range of people (shown in Table 1) may be involved in the different phases in the life cycle
of a system each influences the dependability of the system through their actions and
decisions.

Table 1 – People who influence dependability

Job function Examples of influence

Project manager Awareness of dependability needs in system concepts
Designer
• Takes account of human factors in normal use and
reasonably foreseeable misuse

• Designs for recognition and recovery from fault

conditions including where there are multiple failure
modes

Operational procedure writer Establishes procedures that minimize human failures

Operational manager and supervisor • Ensures appropriate working conditions resources,
communication, feedback and training

• Motivates operators

• Ensures compliance with procedures

Operator Observes and reports consequences of human error

Trainer Highlights error-prone situations in training
Maintenance personnel Understand, interpret and ensure compliance with
procedures

Human performance including strengths and limitations and the potential for humans to
improve or degrade system operation should be taken into account when considering total
system dependability. Although this appears to be additional work with financial implications,
the cost of failure, if total system dependability is not considered, could be significant. The
possible adverse consequences of human failures (including mistakes, slips, lapses,
violations or malicious human actions) are particularly important when the human is part of a
complex system with safety, security or mission critical applications. Human error can also
have severe consequences in business and e-commerce environments.

For details of human characteristics, see 4.3.

4.2.4 Machine (interactive system)

The machine is designed to achieve functional and performance objectives within the
environments in which it is to function.
BS EN 62508:2010
62508 © IEC:2010 – 13 –

During operation the machine receives input from the human through its controls and will
provide output that progresses the system’s task. The output will often be displayed to provide
feedback to the human on the operation of the machine.

For the system as a whole to work effectively the interface and interaction between the
machine and the people who work with it at all stages of the life cycle from design to disposal
needs to take account of the human aspects. These include the fundamental human
characteristics together with specific skills and experience, and the tasks that are to be
performed. In particular, the interaction between the human operator and the machine (i.e.
tasks, displays and controls) should be designed to be easy for the operator to use and to
ensure acceptable levels of mental comfort.

4.2.5 Social and physical environment

4.2.5.1 Social environment

Organizational structure, work flows and the resulting social factors influence the human and
system performance and need to be designed to support efficient and reliable human
performance. An organizational structure is characterized by the transfer of tasks
(delegation), decision competence, information, communication and decision paths as well as
the number of hierarchy levels. The work process is characterized for example by the work
flow method, the shift system, the work time and the work planning and execution.

Other features like leadership behaviour, participation, safety culture and climate can also
influence human motivation and behaviour when using a system.

4.2.5.2 Physical environment

Physical environmental factors that affect people, and hence system reliability, include light,
noise, mechanical vibrations, climate, dirt, humidity, air pressure, toxic gas and radiation.
Environmental factors can directly influence the capabilities of human beings (e.g. noise, toxic
gas, etc.), or they can influence interactions between people and machines (e.g. mechanical
vibration) or they can influence the machine itself (e.g. side winds when driving a car).
However, apart from their negative effects, they can also provide a feedback function that
enhances the ability of the human to interact effectively with the machine (e.g. the engine
noise/vibration when driving a car).

Some factors of the physical environment can require people to use protective equipment
(e.g. breathing apparatus). Some individual human limitations can require the use of assistive
technologies (e.g. reading spectacles or specialized input devices). These technologies can
have an effect on their ability and will need to be taken into account in design.

4.2.6 Output

The task goals should be achieved with the required level of effectiveness and efficiency.

4.2.7 Feedback from the machine to the person

Appropriate feedback from the machine is an important characteristic of dependable design.

Feedback concerning input occurs from the machine to the person through sonic, visual and
tactile signals. Feedback concerning the output of the system as a whole provides information
on the achievement of the goals.

Feedback is important for a number of reasons. It allows a person to correct undesired

behaviour of the machine or the system as a whole in order to improve performance or to
correct undesired actions. In addition, lack of appropriate feedback can produce errors, e.g.
when a computer is slow to provide visual feedback in response to the delete button, the
operator will often repeat the action. Feedback can also contribute to performing a task more
accurately, e.g. feedback from the car brake pedal helps the driver brake smoothly. Feedback
 BS EN 62508:2010
– 14 – 62508 © IEC:2010

from the machine and the system also help provide situational awareness. In some
circumstances, feedback can result in a change to the goals.

4.3 Human characteristics

4.3.1 Introductory remark

Human beings have a set of physical, cognitive and psychological characteristics that vary
from person to person (4.5.2). These characteristics provide fundamental limitations to the
human capabilities that need to be taken into account in systems design. Appropriate training
and experience will enable people to work more effectively, but only within their limitations.

Human reliability and performance will be influenced by the design of the machine and by the
physical and social environment (4.5.1). To ensure a working situation with high
dependability, the system should be designed so that the stress on the human being due to
the work task, work environment and technical design remains within acceptable limits.

4.3.2 Human limitations

The design should take account of human limitations.

a) Physical limitations

• Anthropometric and biomechanical constraints.

• Sensory constraints (e.g. the range of signals that can be perceived and
differentiated).

b) Cognitive limitations

• The time needed between perception of a signal and an action in response. This can
range from a few hundred milliseconds for skill-based actions where response is quasi
automatic (and is not reasoned), to several seconds or minutes where reasoning and
analysis is necessary.
• Limitations of short-term memory. Only 5 to 7 items of information can be held in
short-term memory. For larger amounts of information, mental models or patterns are
constructed.
• Limitations on the amount of information that can be processed at one time (working
memory).
• The inability to focus effectively on more than one task at a time or process
information in parallel.
• Potential for loss of situational awareness resulting in actions based on incorrect
perception of reality.

c) Psychological limitations

• Performance degradation due to physical and mental fatigue or boredom.

• Tendency for decisions and actions to be based on emotional rather than reasoned
responses particularly under situations of stress.

Since these characteristics of humans cannot be designed out of the system, the division of
tasks between people and the rest of a system and the design of technical systems and
interfaces have to be taken into account. The relative strengths of humans and machines
should be considered (4.4.3).

4.3.3 Comparison of humans and machines

The allocation of activities and operational steps between human beings and machines should
take into account the relative strengths of humans and machines.
BS EN 62508:2010
62508 © IEC:2010 – 15 –

a) Human strengths

• Ability to perceive patterns of light or sound.

• Ability to improvise and use flexible procedures.
• Ability to store very large amounts of information for long periods and to recall relevant
facts at the appropriate time.
• Ability to reason inductively.
• Ability to exercise judgement.

b) Machine strengths

• Ability to detect small amounts and a wider range of visual and acoustic signals.
• Ability to respond quickly to control signals, and to apply great force smoothly and
precisely.
• Ability to perform repetitive and routine tasks consistently and accurately.
• Ability to store information briefly and then to erase it completely.
• Ability to reason deductively, including computational ability.
• Ability to handle highly complex operations and to do many different things at once.

There are major differences between humans and machines.

• Machines can be modified, redesigned, and retrofitted whereas humans cannot.

Humans are born with innate, genetically determined differences that are shaped by
the environment. Innate aptitudes or abilities are developed through education and
training.
• Machines can be manufactured to provide exact output and duplicate precise
operation. Humans are not identical and vary across all sensory, cognitive, physical
and performance characteristics. Specific aspects of human performance can be made
more equal through selection and training.

4.4 Human performance shaping factors

4.4.1 General

The performance and reliability of people within a system will vary depending on a range of
internal and external conditions that differ from person to person and from one instant to
another. The factors that influence the capability of human beings to reliably accomplish a
task are called performance shaping factors (also known as the context of use).

Figure 1 indicates the types of performance shaping factors with grey arrows.

Figure 2 provides examples distinguishing between external and internal performance shaping
factors.
 BS EN 62508:2010
– 16 – 62508 © IEC:2010

Human performance

External performance shaping factors Internal performance shaping factors

Organisational Technical Performance

prerequisites prerequisites capacity Willingness

Organisational Organisational Task- Situational Physiological Psychological Physiological Psychological

structure dynamics difficulty factors capacity capacity fitness motivation

Hierarchies Working hours Machinery- Work-layout Constitution Talent Circadian Intrinsic

Remuneration Work design Anthropometric Sex Education rhythm motivation
Education - Structure Task-content Environmental Age Experience Sicknesses (including
- Resources Task-design Design Training Emotional interest, social
Instructions Technical- stability integration)
implementation Condition Extrinsic
motivation
(including career
opportunities,
work-climate)

Occupational health and safety

Quality assurance
IEC 1542/10

Figure 2 – Human performance shaping factors

4.4.2 External performance shaping factors

External performance shaping factors are the result of organizational and technical
prerequisites. Organizational prerequisites ( 4.2.5.1) can often only be described qualitatively.
Technical prerequisites including machine design ( 4.2.4) and environmental factors ( 4.2.5.2),
on the other hand, can most often be described quantitatively.

Taking account of the external performance shaping factors in design will have a positive
impact on the performance.

4.4.3 Internal performance shaping factors

Internal performance shaping factors can be separated into performance capacity and
willingness. They represent factors caused by physiological and psychological variations in
people and are shown as “individual characteristics, skills and experience” in Figure 1.

These include human limitations ( 4.3.2), and differences in size and strength, differences in
talent, skill, experience and knowledge, psychological variations and motivational factors.

4.5 Human reliability analysis (HRA)

4.5.1 Overview

The analysis of human reliability is part of the overall analysis of the reliability of a technical
system. Human reliability analysis involves the following activities.

• Identification of potential for human failure.

• Analysis of sources of error and causes of violations so as to be able to define appropriate
counter-measures.
BS EN 62508:2010
62508 © IEC:2010 – 17 –

• Where appropriate, quantification of human reliability so as to be able to quantify the

reliability of the system as a whole.
• Decision as to whether improvements are necessary.

4.5.2 Identifying the potential for human error

In general the role of humans in the system is to receive an input such as instructions or
information via a sensory process. This input is then subjected to a cognitive process
involving knowledge, memory or training to make a decision on how to respond. The resulting
decision is implemented by a motor process of action involving the use of appropriate
muscles. Often the action generates feedback that provides additional inputs which either
confirms the correctness of the action or indicates a problem that needs correcting (Figure 3).
This applies whether the task involves operating a machine, following procedures, designing
equipment or procedures or undertaking a management or supervisory task.

Performance shaping
factors

Input Sensory Cognitive Motor Response

Processing

IEC 1543/10

Figure 3 – Simple model of human information processing

The input in Figure 3 includes task goals, environment and feedback.

Information processing and decision making often requires use of memory and can require
further external information. Errors can occur at any of the steps of this cognitive process, and
the potential for error can be identified by considering each cognitive step, in turn, in order to
look for where problems might occur. The potential for human error can also be identified
using Failure Mode and Effect Analysis (FMEA) which starts with a task analysis and
identifies likely errors at each step of the tasks and how these errors might occur (see
Annex A).

4.5.3 Analysing human failures to define countermeasures

An understanding of how and why humans fail helps to define appropriate counter-measures
and improve system dependability.

Human failures can be separated into violations and errors. Violations are deviations from a
known correct path. They typically occur because there are unintended rewards for incorrect
behaviour (for example saving time and effort or peer approval). Rules might be violated
because it is perceived that there is a better way to achieve the end, to cover up mistakes or
to assist colleagues. Violations may occur maliciously but this is rare.

Errors are when a planned sequence of mental or physical activities fail to achieve their
intended outcome. This may be because the plan was inadequate or because the activities
did not go as planned. This distinction leads to a classification of errors into mistakes, slips
and lapses.

Another type of error is where the action an individual intends to carry out is correct but the
performance of the action is incorrect. These errors can also be divided into two groups.
 BS EN 62508:2010
– 18 – 62508 © IEC:2010

• Slips, which are failures in execution, often when performing well known and routine tasks
automatically with little mental processing, for example typing or driving.
• Lapses are failures of memory or cognition (such as losing ones place in a list) or
accidentally following a well known procedure instead of a required new one.

The classification is a useful starting point for analysing causes of human failure. The
following approaches may be taken in design when problems are found or suspected.

To minimize violations, reasons why people might act incorrectly need to be considered and
“rewards” attached to correct rather than incorrect behaviour. For example violations are less
likely where the easy way of doing something is the correct way.

Mistakes are minimized by taking into account the inherent human limitations in design, then
by ensuring that people have the correct knowledge and skill for the task and sufficient time to
reason correctly. Clear instructions, intuitive displays and controls and aids to memory help
minimize mistakes.

Slips and lapses are more difficult to minimize since the person’s intention is correct and the
errors often arise when performing automatic activities where the individual is not in
conscious control. Designs that maintain and check situational awareness, match
unconscious mental expectations and provide early feedback that an error has occurred can
help ensure that slips and lapses are corrected before overall dependability is compromised.

Clause A.1 lists a number of HRA methods which include techniques for analysing
mechanisms and causes of human failures which are then reviewed to define counter-
measures. Human failures of all types can also be reduced by considering performance
shaping factors in the design of the system and its components and designing to enhance
human performance.

4.5.4 Quantification of human reliability

When the reliability of a system is to be quantified it may be appropriate to also put a value on
the probability of human error. There are a number of different methods that can be applied to
do this. These are listed with brief descriptions in Annex A. Usually, probabilities are applied
to slips, lapses and mistakes, taking into account the performance shaping factors. Normally
malicious violations are excluded from the analysis (i.e. it is assumed that people are well
intentioned but can still make slips, lapses and mistakes).

4.6 Critical systems

A critical system is a computer, electronic, mechanical or electromechanical system whose

failure to operate as required can have a significant impact, such as injury or human deaths,
major equipment damage or large financial loss. In the design of critical systems, it is
particularly important that consideration is given both to normal operation and operation under
possible fault conditions where the operator may be making decisions under stress. It is
important to envisage how the operator would respond to the widest possible range of
abnormal situations, and to design the interface to minimize the possibility of
misinterpretation.

Critical systems are normally designed to limit or exclude human intervention. However, when
human intervention is needed, the human action is usually required to be correct, swift and
decisive to stop or prevent further progress of adverse conditions.

There are broadly three abnormal situations where human input is critical. These situations
are not exclusive and some cases may evolve from one situation to another:

a) in an emergency situation, when human decision capability is often degraded, and

information can be misinterpreted;
BS EN 62508:2010
62508 © IEC:2010 – 19 –

b) in normal or abnormal situations where the operator does not realise the impact of his/her
actions. In this case the operator is not stressed, in fact they may not be paying adequate
attention and thus contribute to harm in some way;
c) where the operator cannot know outcomes and needs support in making and following-
through decisions (maybe over very extended periods of time).

Appropriate human decisions in these situations can be achieved by the following measures:

• identify the increased potential for and consequence of single person error in highly
automated systems;
• simulating emergency situations with prototype interfaces to assess human
understanding, and using the feedback obtained to improve the interfaces;
• where there is any remaining potential confusion, training the operators in how to respond
to the situation;
• selecting staff who are able to perform effectively in stressful multi-tasking environments;
• training the operators in regular intervals to being able to handle the system under
possible fault conditions by hand;
• put in place means to address complacency/lack of awareness, such as staff selection,
checking procedures, behavioural safety system, etc.;
• where it is not possible to know the risks in advance, and operators have to act with high
uncertainty (e.g. finance, defence, exploration, waste disposal, etc) include procedures
and tools for modelling and decision making.

4.7 Human-centred design guidelines

The following human-centred design guidelines will contribute to improved human reliability
and system dependability, when applied appropriately.

a) Fitness for use

• Make the design durable, reliable and applicable for its intended use.
• Allocate functions between people and technology appropriately.
• Accommodate physical, cognitive and psychological characteristics of the users.
• Test with users.

b) Simplicity

• Design to be as simple as possible.

• Minimize the need for training.
• Make functions obvious.

c) Error tolerant and resistant

• Make the system error tolerant.

• Design such that it is not possible to make a mistake.
• Design to be fail-safe.

d) Consistency

• Make design consistent with user experience, with real life objects and with similar
systems.

e) Standardization

• Use standardized hardware and software where practicable.

 BS EN 62508:2010
– 20 – 62508 © IEC:2010

• Maintain identical interfaces for identical functions.

• Make controls, displays, markings, coding, labelling, and arrangement uniform.
• Make appearance distinctive.
• Standardize terminology, look, and feel.
• Make equipment with similar functionality interchangeable.

f) User-centred perspective

• Understand user roles, responsibilities, decisions and goals.

• Provide timely and informative feedback.
• Use familiar terms and images.
• Design within user abilities.
• Maximize human performance and satisfaction.
• Minimize training requirements.
• Facilitate transfer of skills.
• Accommodate physical diversity.

g) Maintainability and maintenance support

• Design for ease of disassembly and reassembly.

• Provide for specialized tools if necessary.
• Provide logistic support where needed.
• Design for common tools.
• Make design easy to maintain.

Annex B summarizes the human factors design influence and impact on system dependability
in specific situations.

4.8 Human-centred design process

4.8.1 Human-centred design principles within the design process

Human-oriented design involves the process of engineering the total system design to meet
the needs of the human operator and other stakeholders. The aim is to maximize the overall
system capabilities and performance in operation.

Whatever the design process and allocation of responsibilities and roles adopted, the
incorporation of a human-oriented approach to design should follow the human-centred
design principles listed below (and described more fully in ISO 9241-210).

a) The design is based on an explicit understanding of users, tasks and environments.

b) Users are involved throughout design and development.
c) The design is driven and refined by user-centred evaluation.
d) The process is iterative.
e) The design addresses the entire user experience (including how the user will respond to
the task, working environment, support, training and long-term use).

f) The design team includes multi-disciplinary skills and perspectives.

BS EN 62508:2010
62508 © IEC:2010 – 21 –

4.8.2 Human-centred design activities

Five linked human-centred design activities shall take place during a system development
project (described in ISO 9241-210). They take place throughout the project and vary in detail
and degree, depending on the project stage.

a) Plan the human-oriented design activities.

b) Analyse, understand and specify the context of use.
c) Analyse user needs and specify user requirements.
d) Use current human factors knowledge to design solutions to meet these requirements.
e) Evaluate the design solutions against requirements and user feedback, and modify the
design and/or requirements accordingly.

Plan the human-

centred activities

Design solution
Understand and specify
satisfies
the context of use
requirements
Iterate,
where
appropriate
appropriat

Specify the user

Evaluate
requirements

Produce design
solutions
IEC 1544/10

Figure 4 – Human-centred design activities

In practice, these activities can overlap or can represent distinct stages. Later activities can
also modify the assumptions made in the earlier stages. Figure 4 (taken from ISO 9241-210)
illustrates their interdependence.

5 Human-oriented design in the system lifecycle

5.1 Overview

The purpose of considering human aspects in systems engineering is to incorporate the

interests and needs of the individuals and/or groups that will work with the system. This has
the following benefits.

• Projects anticipate and address the issues and risks arising from human-system
interaction.
• The system has a life cycle phase planning and resourcing designed to combat human
factors risks in a cost-effective manner.
 BS EN 62508:2010
– 22 – 62508 © IEC:2010

• The needs of the stakeholders in the system are communicated to the development
organization.
• Overall system dependability is improved.

The human-oriented approach to design involves the application of human-centred design

methods in the system lifecycle whilst being cognizant of the variability of performance and
reliability of humans..

Systems should be designed to minimize the potential for human error and to reduce the
impact of errors should they occur. To achieve acceptable human reliability, the design
process needs to take account of all relevant human issues, such as the following.

• Eliciting and defining the full range of users, maintainer and other stakeholder
requirements.
• Defining the contexts in which the system will be used and maintained, including the
characteristics of the users, the tasks and the working environments.
• Defining the human performance and mental comfort requirements necessary to achieve
system objectives during all phases of the life cycle.
• Identifying potential for human error by operators, maintainers and others who form part of
the system during different life cycle phases.

Human-oriented design utilizes the human factor knowledge base for application in user-
centric, error-resistant and error-tolerant designs by adapting appropriate technologies to
mitigate challenges in meeting human performance requirements and to enhance human-
system interaction.

Taking a human-oriented approach to design not only improves human reliability but also has
other important benefits, such as listed below.

• Increased productivity, improved performance and greater user satisfaction.

• Reduced errors in design and operation.
• Simplified system operation and maintenance procedures.
• Reduced time in user support.
• Reduced need for special skills training.
• Reduced risks of serious accidents.
• Cost avoidance and reduce life cycle costs.

5.2 System life cycle

Human aspects should be integrated with systems engineering and the system life cycle
process. The system life cycle concept adapted from IEC 60300-3-15 is shown in Figure 5 to
identify the key human-oriented design influence in the system life cycle. The system life
cycle stages are briefly described as follows.

– The Concept/Definition stage is to identify the market needs, define/identify the

operational use environment/timeline, define preliminary system requirements and confirm
feasible design solutions by producing technical specifications for the system design. The
process activities involve the definition and analysis of requirements, architectural design,
and functional design/evaluation to provide high-level system specifications. The human
aspects to be considered at this stage are the variability of performance and reliability of
persons who will be operating the system. HCD activities should commence with a plan
which includes all the requirements.
– The Design/Development stage is to plan and execute selected engineering design
solutions for the realization of system functions. This is transcribed into an appropriate
system development effort, including engineering modelling, prototype construction, risk
assessment, and interface identification of system and subsystem elements. Continued
 BS EN 62508:2010
62508 © IEC:2010 – 23 –

attention to the variability of operators is necessary at this stage. Maintenance needs

should also be identified at this stage in order to ensure the appropriate access is catered
for in the initial design. The variability of performance and reliability of those humans who
will carry out the maintenance should be considered.
– The Realization/Implementation stage is to execute make-buy decisions for acquisition
and deployment of subsystem elements. The realization efforts deal with activities such as
technology applications, manufacturing, packaging and supplies sourcing to ensure the
complete transformation from system design to the specified product or subsystem
elements. The realized products or elements can comprise a combination of hardware and
software functions. Implementation includes such activities as integration of system
functions, verification of subsystems and installation of the system. Training of operators
and those who will maintain the system should be conducted at this stage.
– The Operation/Maintenance stage is used to deploy the system for delivery of service and
to support system operational capability by means of maintenance. The process activities
include operating and maintaining the system for service in accordance with system
performance requirements, operators and maintainers training to maintain skills
competency, customer interface to establish service relationship, and record keeping on
system performance status and reporting failure incidents to initiate timely corrective and
preventive actions.
– The Enhancement stage is to improve the system performance with added features to
meet growing user demands on the system. The process activities include software
upgrade, hardware addition, repair and overhaul, skills training, simplifying procedures to
improve operational efficiency, obsolescence management, organizational restructuring to
increase expediency and customer value. All the human aspects considered in previous
phases should be revisited to realise any improvements that may be achieved out of the
knowledge of operating the system.
– The Retirement/Decommissioning stage is to end the existence of the system entity. Upon
termination of system service to the customer, the system might be disassembled,
redeployed for other use, or disposed of where possible without affecting the
environments. The physical and mental characteristics of those who will be operating the
disposal and recycling process should be considered.

System life cycle stages

Concept/ Design/ Realization/ Operation/ Enhancement Retirement/

Definition Development Implementation Maintenance Decommission

* Identify user * Use HF * Skills training * Operation/ * Review in service * HF issues

objectives knowledge • Health and safety maintenance HF performance related to
* Plan HCD * Understand awareness records • Process disposals,
activities maintenance • Implement fault * Corrective/ improvements recycling,
* Understand needs management preventative * Recommend- and reuse
user needs * Test prototypes procedures actions actions for design
* Define HCD with users * Incident reporting changes
requirements * Human oriented
design
assessment
IEC 1545/10

Figure 5 – Human aspects of the system life cycle

5.3 Integrating human-oriented design in systems engineering

Integrating human-oriented design in systems engineering is done throughout the system life
cycle, especially during the design/development, realization/implementation and operation/
maintenance stages. It is during these stages that human-oriented design has the most
influence on systems engineering tasks related to design enhancements, safety features,
automation impacts, human-system performance trade-offs, ease of use and workload.
 BS EN 62508:2010
– 24 – 62508 © IEC:2010

The key activities are listed below:

a) Obtain a complete and in depth understanding of the needs of the users and user
organizations.
b) Identify risks to dependability arising from human involvement in the system (related to
both unintended errors and potential malicious human behaviour).
c) Identify factors that will shape human performance (see 4.5).
d) Apply human factors knowledge to the design in order to achieve optimum human
performance and minimize risks.
e) Iterate proposed design solutions and incorporating feedback from users into the design.

These activities are described in more detail in the following clauses. The resources allocated
to the use of human-centred design activities should depend on the projected benefits of
carrying out the activities at particular lifecycle stages and the associated risks if they are not
carried out. Risks to be considered should include the possibility of not achieving
requirements for reliability, dependability or other stakeholder needs, the operational or
business implications and the associated costs of any necessary rework. The best practices
are described below and listed in Annex C.

6 Human-oriented design at each life cycle stage

6.1 Overview

Annex C provides a list of the activities that are necessary to implement human-oriented
design at each system life cycle stage. These are summarized in this clause.

6.2 Concept/definition stage

6.2.1 Concept

At the concept stage, it is important to obtain a clear understanding of the objectives which
the user or user organization wants to achieve through use of the system, to assess the
viability of these objectives and to identify any risks that might need to be incorporated into
specifications and considered during design. Dependability requirements for the system
should be specified, as this can affect human roles within the system.

6.2.2 Human-centred design planning

A human-centred design plan is essential to establish a strategy for managing the human-
centred design effort to support system development and operation. The objective is to
address human-centred design issues to improve total system performance and reduce
developmental and life cycle costs. This is achieved by optimizing human performance when
the system is operated and maintained in the application environment. The planning approach
should include the following activities.

• Derive the goals for the human-centred activities from the overall organizational goals for
the system.
• Determine the resources devoted to use of human-centred design methods. This should
depend on the level of risk that would be incurred by the project at each stage if human-
centred methods were not used.
• Specify how and when human-centred activities integrate into the overall system life cycle
and how input from the activities is used in the system life cycle.
• Decide which methods will be included, and how they will link together in the life cycle.
• Make allowance for iteration where necessary.
• Identify the need for and cost of user involvement.
• Define outputs and criteria for success for each activity.
BS EN 62508:2010
62508 © IEC:2010 – 25 –

• Identify the necessary specialist skills and plan how to provide them.

A human-centred design plan should be developed in the early concept/definition stage of the
system life cycle to maximize its effectiveness to influence system definition and framework
development. The human-centred design plan should be part of the system overall plan.

6.2.3 Understanding the needs

The roles of each group of stakeholders likely to be affected by the system (including user
groups and maintainers) should be identified, and the tasks that they are to perform should be
analysed. The extent to which ease of use and error-free human performance are important
should be established. The overall context of use in which the system is expected to be used
should be identified, including the environmental factors (see 4.2.5.2) and the organizational
structures, tasks and work flows (see 4.2.5.1). Field visits might be necessary to obtain this
type of information.

6.2.4 System requirements

The purpose of incorporating human issues in system requirements includes the following:

• provide human-centred design inputs to develop system specifications;

• include human-centred design requirements in the quality assurance process;
• include human-centred design requirements for outsourcing and subcontracting;
• establish human-oriented procedures for system operation and maintenance.

The objective is to achieve a human-centred, error resistant and tolerant system framework
that is suitable and usable for effective system operation.

• User requirements should be established in conjunction with potential users.

• The intended behaviour and performance of the system with respect to the users should
be established.

6.2.5 Human-centred design requirements

The human-centred requirements analysis provides the necessary information and relevant
data for the following activities:

• determination of human-centred design issues in system application and operating

scenario;
• integration of human-centred design principles into the system context;
• tailoring the human-centred design project to meet system requirements.

Human-centred design requirements should include the following:

• operator and maintainer roles and responsibilities;

• human-system interfaces influencing user performance efficiency and effectiveness;
• specification of the context in which the system will be used, including the environmental
factors (see 4.2.5.2) and the organisational structures, tasks and work flows (see 4.2.5.1);
• system performance metrics including operator/maintainer performance;
• mental comfort and user satisfaction requirements;
• system architecture design affecting human-system interactions;
• system application environment impacting human resources and requirements.

The human-centred design requirements should be presented to relevant stakeholders to

obtain feedback. Scenarios of use can be used to present the requirements. They have the
 BS EN 62508:2010
– 26 – 62508 © IEC:2010

benefits of being relatively easy to test and being easy for other project stakeholders to
understand.

The human-centred design requirements analysis should be conducted in conjunction with the
human-centred design plan during concept/definition stage of the system life cycle. This
facilitates the tailoring process working to meet specific project needs in the system definition.
The project tailoring process is described in IEC 60300-2.

6.3 Design/development

Human-centred design analysis in system design is conducted during the design/development

stage of the system life cycle. The objective is to ensure that

• human-system capabilities and limitations are properly reflected in the system

requirements,
• human-system performance characteristics provide relevant information to identify design
options and alternatives,
• human reliability and other human related system dependability risks are identified,
assessed and appropriately addressed in design.

System specifications and the operation and maintenance procedures should take into
account of the following elements:

• human performance such as human capabilities and limitations (see 4.3.3), workload,
function allocation, hardware and software design, decision aids, environmental
constraints, and team versus individual performance;
• training needs such as duration of training, training effectiveness, skills retraining, training
devices and facilities, and embedded training;
• staffing requirements such as staffing levels, team composition, and organizational
structure;
• personnel selection such as minimum skill levels, special skills, competency and
experience;
• health and safety risks that can arise at all subsequent stages of the life cycle. Issues
include hazardous materials and conditions, system and equipment design for safe
operation, biomedical influences, protective equipment, and warning and alarm
requirements.

The design of the system should take into account that humans need to detect, diagnose and
correct faults during operation including complexities where there may be multiple failures.

The system should be reviewed in accordance with applicable knowledge of human sciences,
style guides, standards, guidelines, regulations and legislation, and prototypes should be
evaluated by users to refine the usability of the developing system. The system should be
tested as part of verification and validation to ensure that it meets the requirements of the
users, the tasks and the environment, as defined in its specification. This can be achieved
using a prototype in a simulated working environment to test how humans interact with the
proposed design. For more complex systems and/or components, where human interactions
are particularly important, the system should be tested during initial operations.

6.4 Realization/implementation

In this stage the product is manufactured, the system components are assembled, and the
product is put in place for application and operation.

The human-centred design includes the following activities.

• Review of human-machine interactions in the light of experience.

BS EN 62508:2010
62508 © IEC:2010 – 27 –

• More detailed assessment of risks including human reliability risks of operation and
maintenance stage.
• Training in the skills needed to use the system.
• Creation of health and safety awareness.
• Implementation of fault management procedures.
• Review of regulatory compliance.
• Testing of the final system to ensure that it meets human-oriented requirements.

6.5 Operation/maintenance
Errors during operation and maintenance are reduced by good design but not eliminated. It is
important that errors are reported so they can be reviewed and improvements made. This
requires a culture where error is able to be reported freely without fear of punishment, and
understanding of underlying causes of error and the conditions which tend to provoke error.
Regular simulation and/or training should be provided in responding to emergency situations
and the lessons learnt should be used to enhance the system performance and the human
awareness and skills.
Human-centred design assessment in the operation/maintenance stage is intended to check
that human-centred design considerations have been adequately integrated into the system
for effective performance operation. The assessment is achieved by system testing and
performance verification with the aim of producing evidence of conformance to human-centred
design requirements in an application environment. The human-centred design assessment
process should include the following activities.

• Measurement of human performance and mental comfort in critical tasks.

• Determination of efficiency and effectiveness of human intervention.
• Maintenance of human-centred design test records and assessment data as basis for
evaluation and improvement.
• Assessment of ease of maintenance.
• Performance of emergency situation simulations/training in defined intervals and provision
of the lessons learnt for enhancement of the system performance and the human
awareness/skills.

The human-centred design assessment results should be analysed to support

recommendations for design changes, where appropriate, provide rationale for human
performance improvements or implement training solutions.

The human-centred design information flow should include sharing with integrated logistics
support (ILS) programs where applicable. ILS is a disciplined approach to integrate support
considerations into design, to acquire the necessary initial support for the system and to
identify life cycle support requirements. The human-centred design program provides the
human resource and performance dimension for logistics support requirements and functions.
Close coordination between the human-centred design and ILS programs will reduce data
redundancies and result in more effective use and sharing of information.

6.6 Enhancement

This stage is to improve system performance with added features to meet growing user
demands on the system.

The human-centred design process should include the following activities.

• Collection and analysis of in-service reports to generate updates or lessons learnt for the
next version of the system.
• Improvement of the human-centred design process in the context of the wider systems
engineering process.
 BS EN 62508:2010
– 28 – 62508 © IEC:2010

• Communication with stakeholders on proposed improvements.

The result might be to apply a miniature version of the life cycle in order to implement the
enhancement.

6.7 Retirement/decommission

This stage is designed to end the existence of the system entity.

The human-centred design process should include the following activities:

• Examine human factors issues related to disposals, recycling, and reuse

• Identify risks and health and safety issues associated with removal from service and
destruction of the system.
• Define how users will be re-allocated, dismissed or transferred to other duties.
• Plan the break-up of social structures.
• Debrief and retrospective analysis for the replacement system.

6.8 Outsourcing projects and related human-centred design issues

The human-centred design requirements should be incorporated in system specifications and

procurement documents. This is crucial for the system to achieve its objectives for coherent
design and consistent performance involving proper function allocation and interactions of
hardware, software and human elements in system design and operation.

The outsourcing of subsystems development requiring human operation is common in today’s

complex system development and enhancement projects. Incorporation of commercial-off-the-
shelf (COTS) products as system functions often has cost benefits. System support services
are frequently used for contract maintenance.

The success factors are dependent on the collaborative efforts of the acquirers and suppliers,
the system integrators and service providers through application of supply-chain management
and quality assurance processes. Since human-oriented design involves multi-disciplinary
actions, it is sometimes necessary for technical experts to deal with resolution of critical
human issues related to outsourcing and procurement needs.

Outsourcing human-centred design projects should consider the following issues.

• Conformance to the human-centred design process in ISO 9241-210 and making available
work products such as those described in ISO/IEC TR 25060 (context of use description,
user needs report, user requirements specification, user interaction specification, user
interface specification, evaluation reports).
• Human-system interface requirements to achieve the level of human performance during
system operation and maintenance.
• Maximizing the economical demands on utilization of available human resources, skills
and training.
• Staffing implications of the human resources, job classification, skill levels and experience
needed for the projects.
• Evaluation for design automation trade-off with human operation in terms of applicability,
efficiency and cost implications.
• Potential system safety and health hazard areas involving human-system interactions.
• Quality assurance provisions for procurement contracts.
• Reintegration of all outsourced tasks and projects into the total system model for system
optimization.
BS EN 62508:2010
62508 © IEC:2010 – 29 –

Human performance testing of COTS products should take advantage of available information
from the product manufacturers, records of warranty returns, previous commercial testing and
product use experience.

Outsourcing projects should be identified during concept/definition stage of the system life
cycle. The procurement contracts should be well established at the completion of the
design/development stage. This permits time for subcontractor evaluation, multiple sourcing
of preferred suppliers and COTS product assessment for incorporation as system functions to
facilitate the system integration process.

7 Human-centred design methods

7.1 Classification of human-centred design activities

Human-centred design activities are classified in ISO/PAS 18152 as follows:

• HS.1 Life cycle involvement activities: in each stage of the system life cycle.

• HS.2 Integrate human factors activities: in business strategy, quality management,

authorisation and control, management of HS issues, HF data in trade-off and risk
mitigation, user involvement, human-system integration and development and re-use of
HF data.

• HS.3 Human-centred design activities: context of use, user requirements, produce design
solutions, evaluation of use.

• HS.4 Human resources activities: human resources strategy, definition of standard

competencies and identification of gaps, design of staffing solution and delivery plan,
evaluation of human resources system solutions and obtaining feedback.

The methods that can be used to support these activities include the following.

a) Human-centred design analysis methods

Human-centred design analysis methods are used to define system concepts, describe
application/mission scenarios, determine functional requirements and assign tasks for
appropriate skills allocation. The various analyses provide a means for identifying human-
centred design related goals, objectives, critical design issues, and further evaluation needs
to meet system performance requirements involving human interactions.

b) Human-centred design methods for design and development

Human-centred design methods for design and development are used to incorporate all
necessary human-centred design criteria into the human-system interface design. The human-
system interface includes system hardware, software, procedures, work environments and
facilities associated with the system functions requiring human interactions. The process is
designed to convert the results of the human-centred design analysis activities into design
criteria for human factors project development and implementation.

c) Human-centred design methods for test and evaluation

Human-centred design methods for test and evaluation are used to verify human-system
interface and procedures to ensure that the system can be operated, maintained, supported
and controlled in its intended operating environment by the users. These methods facilitate
identification of critical human-centred design issues in operation and maintenance for
problem resolution and process improvement.
 BS EN 62508:2010
– 30 – 62508 © IEC:2010

Annex C provides a summary of practical methods for human-centred design analysis, design
and development, as well as test and evaluation.

7.2 Applications of human-centred design methods

The human-centred design methods for general analysis, evaluation and assessment
applications are based on systems engineering techniques. They should be used in
conjunction with other engineering methods and technical disciplines in system design and
implementation. The human factors engineering methods listed in Annex C contribute to the
best practices for human-centred design, as shown in Table C.1.
BS EN 62508:2010
62508 © IEC:2010 – 31 –

Annex A
(informative)

Examples of HRA methods

There is a distinction between the HRA methods of the first generation and the HRA methods
of the second generation.

First generation methods treat human failure in the same way as hardware failure with the
output from human tasks substituted for equipment outputs. Human actions are considered in
a binary fashion, i.e. as success or failure to achieve the required result from a task. Tasks
and subtasks are considered to have an inherent failure probability which is then modified by
performance shaping factors which are based on the evaluation of the ergonomic
environment. Methods differ in the way in which they estimate the basic human error
probabilities (HEP) and incorporate performance shaping factors (PSFs).

HRA procedures of the second generation model and evaluate the role of the context and
human decision-making behaviour which can have adverse effects on the system.

Table A.1 provides a description of the various methods and details on how they are applied.

Table A.1 – HRA methods and their application

Method and short description Level of use

ASEP – Accident Sequence Evaluation ASEP is used if a quick but not
Program: very precise quantitative estimation
simplified version of THERP for pre- is needed for screening. This is the
assessments (with conservative estimates case in low power and shutdown
during pre-assessments). states of nuclear power plants for
instance where the number of
Critical tasks are broken down into subtasks action to assess is large and a
which are arranged on a human performance time-efficient method is needed.
event tree. HEPs for subtasks are obtained
from tables published in NUREG/CR-4772 ASEP is a first generation HRA
(US regulatory Commission 1987). Guidance method, allowing for assessment of
is also given for allowing for PSFs in the ergonomic problems in the working
HEP. environment.

Standardized action decomposition: critical

actions and diagnosis of disturbances if
applicable. Overall recommendations for
commitment on one HEP per critical action;
detailed judgment on human-machine
interfaces not required. Time-related HEP-
diagnosis, given curves are based on an
expert consensus. Allows for fast pre-
selection of important tasks.
 BS EN 62508:2010
– 32 – 62508 © IEC:2010

Method and short description Level of use

ATHEANA – A Technique For Human Error ATHEANA is used in a number of
Analysis: studies in particular in the nuclear
thorough analysis of the context and of environment.
decision-making provides the system analyst
with detailed knowledge about the potential ATHEANA is a second generation
for erroneous human decisions. HRA method, allowing for thorough
qualitative analysis of the influence
The method identifies human failure events of the context on human behaviour
(HFEs) by considering accident scenarios. and decision making.
HFEs are characterized by unsafe acts i.e.
actions (or omissions) which result in Can be used for analysis of post
degraded plant performance and by the error incident error where error forcing
forcing context (EFC). The EFC includes both context of the incident occurs.
PSFs and plant conditions that make human
error likely. HFE is quantified by combining
probabilities of EFCs, the probability of an
unsafe act in the EFC and the probability of
an EFC given the unsafe act and additional
evidence following the unsafe act. The
quantitative estimates are based on expert
judgment similar to the SLIM approach.

CAHR – Connectionism Assessment Of CAHR can be used for either

Human Reliability: assessing classical ergonomic
the method requires operational events or problems or interrelations of
other behavioural data to perform its multiple conditions and factors.
assessment. It consists of: (1) a structured Applications range from nuclear,
framework for data collection, (2) a method automobile, aviation, and air traffic
for qualitative analysis of the collected data, to maritime management.
and (3) a method for human reliability
assessment. CAHR is a second generation HRA
method, allowing thorough
For the assessment the method distinguishes qualitative analysis of the influence
the task and the context under which the task of the context on human behaviour
needs to be performed, the cognitive demand and decision making in a time
that the task and the context place on the efficient manner.
human, the human compensation
mechanisms and the resulting behaviour.
BS EN 62508:2010
62508 © IEC:2010 – 33 –

Method and short description Level of use

CREAM – Cognitive Reliability And Error CREAM is widely used for quick
Analysis Method: assessments of the context on
human performance and provides
The human control mode applicable to the insights on the level of a screening
scenario is selected from 4 “contextual technique.
control modes” (human reliability is assumed
to increase as level of control increases). CREAM is a second generation
The context of the task or scenario is HRA method, allowing a qualitative
described using CREAM’s 9 common analysis of the influence of the
performance conditions (CPCs). (CPCs are context on human behaviour and
similar to PSFs.) decision-making and a coarse
quantification.
Potential errors are identified and classified
into a number of groups that describe error
modes and error causes.

For the assessment CREAM uses similar

tables to THERP but only after having
performed the analysis of the essential
contextual control modes.

ESAT – Expertensystem zur Aufgaben- ESAT stems from aviation but is

Taxonomie (expert system for task still occasionally used also in other
taxonomy): industrial settings like assessing
PSF-related quantification of discretionary human errors in production.
tasks. Determination of a reliability rating
(RR, on a scale of 1 to 10) by assessments ESAT is a first generation HRA
(“ratings”) of given PSFs. The functional method, allowing for assessment of
connection between HEP and RR is partly ergonomic problems in the working
determined by expert assessments (based on environment.
generic knowledge on human work
performance) and partly by measuring work
performances. This method has been applied
for the design of cockpits in aviation.

FMEA/FMECA – Failure Modes And Effects FMEA and FMECA are commonly
Analysis used for equipment reliability and
identifies failure modes (i.e. what is done extended into human reliability as
incorrectly) and failure mechanisms (how it is either a qualitative or quantitative
done wrongly or psychological error tool.
mechanisms) and its effects. As with
equipment, FMEA probabilities error modes For more detailed guidance see
occurring can be estimated and the criticality IEC 60812.
of errors can be estimated by considering
their probability of occurrence and the
magnitude of the effects.
 BS EN 62508:2010
– 34 – 62508 © IEC:2010

Method and short description Level of use

HCR/ORE (Human Cognitive Reliability / Op- The approach was developed
erator Reliability Experiments): because the original HCR (human
cognitive reliability model)
HCR methods recognise that the success or approach, distinguishing between
failure of an operator depends on the time skill- rule- and knowledge-based
available for action. HEP is the fraction of behaviour, was proven to not be a
time required for diagnosis and response valid approach towards human
time available. reliability.

HCR/ORE was developed on the basis of HCR/ORE requires simulation

operator reliability experiments (ORE). For experiments to be conducted
tasks described in procedures, time-related before it can provide valid
and time-unrelated failures of diagnosis are assessments. Due to the efforts
distinguished. There are 6 HEP-time-curves combined with this requirement
available (according to the type of reactor current use is limited to some
and dynamic of failure) normalized on the nuclear control room actions.
average time requirement (Median). PSF-
related HEP quantification for the time- HCR/ORE is a first generation HRA
unrelated failure is performed by considering method, allowing for assessment of
8 given error mechanisms. Guidelines for a task performance dependent from
decision-tree-type PSF-modelling are also the time available; ergonomic
given. For tasks that are not represented in problems are addressed in a limited
procedures, a quick method for assessment way.
of the HEP is offered

HEART/CARA – Human Error Assessment Easily and quickly manageable.

And Reduction Technique: Many of the PSF-figures are based
Intended for generic, system-based tasks on empirical studies; disadvantage:
(e.g. put system X into operation) rather than model calibration is insufficient.
for elementary tasks (e.g. manipulate switch
X). A nominal value for HEP is selected by The technique is hence not suitable
comparing the task with a list of 8 generically for estimating the reliability of
defined tasks for which HEPs are defined. Human actions if a high precision in
HEP is then modified by a rating for PSFs the assessment or a high reliability
selected from a list of 38 PSFs. is required (e.g. actions leading
immediately to adverse effects in
The method received further development the system).
into generic task types in air traffic
management under the name CARA. HEART and its successors are first
generation HRA methods, allowing
for assessment of task
performance in the sense of a more
detailed screening rather than a
thorough assessment.
BS EN 62508:2010
62508 © IEC:2010 – 35 –

Method and short description Level of use

MERMOS – Méthode d'Evaluation de la MERMOS is used extensively in the
Réalisation des Missions Opérateur pour la French nuclear industry. It was
Sûreté (Method for the evaluation of the validated several times and
realization of an operator’s mission regarding received regulatory acceptance.
safety).
MERMOS is a second generation
MERMOS avoids the term “human error” and HRA method, allowing thorough
distinguishes missions (set of tasks to be qualitative analysis of the influence
performed); mechanisms are established by of the context on human behaviour
humans on how to coordinate the mission and decision making.
and probable outcomes of such coordination.

Multiple failure paths that lead to mission

failure are identified using a process
structured by considering strategy, action
and diagnosis. Probabilities are assigned to
path elements by expert judgment.

Data stem from operational experience as

well as simulator observations.

SHERPA – Systematic Human Error First generation method that

Reduction And Prediction Approach. provides a structured
Starts with task analysis and classifies comprehensive means of
bottom level sub-tasks by type (action, identifying errors in performing
retrieval, checking, selecting and specific tasks and qualitatively
communicating). rating their importance. Used to
seek error reduction strategies.
Determine credible error modes for subtask Does not incorporate system or
using SHERPA check list for error modes. organizational errors.

Consequences are described and the

possibility of recovery at a later task noted.
Probability and criticality of each error for
each subtask are given an ordinal rating
(high, medium, low).
 BS EN 62508:2010
– 36 – 62508 © IEC:2010

Method and short description Level of use

SLIM – Success Likelihood Index SLIM is used if a flexible method is
Methodology: required and no specific data is
available. Also PSF-
Experts identify relevant PSFs (e.g. interdependencies are not taken
complexity of task) and nominate endpoints into account. Therefore the results
on a scale from 1 to 9 (e.g. 1 = simple and of the method can only provide a
9 = complex). The point on each scale at screening.
which ideal performance is expected is noted
and used to rescale ratings according to the SLIM is a first generation HRA
distance from an ideal value. Each task is method, allowing for assessment of
rated for each PSF on these scales. A task performance in the sense of a
success likelihood index (SLI) is calculated more detailed screening rather than
on the basis of an overall sum of weighted a thorough assessment.
PSF ratings and is transformed to a
probability scale by applying at least 2
reference-HEPs. Prerequisite: proven
reference-HEPs and relevant PSFs are
available; PSFs are clearly assessable. The
determination of reference-HEPs is
problematic and predetermines the results
that can be achieved.

SPAR-H – Standardized Plant Analysis Risk The SPAR-H is a screening method

(SPAR) HRA: and should not necessarily be
consists of a two-step process to identify preferred over more sophisticated
nominal human error probabilities (HEPs), and detailed approaches, such as a
and then modify those HEPs on the basis of technique for human event analysis
summary-level performance-shaping factors (ATHEANA) in situations that
(PSFs) and dependence. require detailed analysis of the
human performance aspects of an
Significantly, this method required analysts to event.
complete a relatively straightforward
worksheet, which was then used to estimate SPAR-H allows addressing in a
the PSFs and the HEP of interest. SPAR-H limited way first and second
has inherent limitations of modelling and generation HRA issues on the level
analysis that should be clearly understood. of screening.

THERP – Technique for Human Error Rate THERP is used when a thorough
Prediction: this is the standard method for assessment of the tasks is required
human reliability in respect to ergonomic and the overall system
issues. Produces in-depth task dependability relies on critical
decomposition into elements using THERP actions. Decision-making and the
taxonomy, errors for elements represented in influence of a wide spectrum of
event tree format. Nominal HEP is assigned contextual factors cannot be
to each task element by selecting assessed.
‘appropriate’ HEPs from a data base of
around 100 factors. Nominal HEP is modified THERP is a first generation HRA
by multiplier for PSFs if applicable. method, allowing thorough
Dependence between errors for the task assessment of task performance
elements is modelled. and providing detailed ergonomic
requirements for system design. It
Curves are produced for the probability that a is not suitable for assessing
human will respond to a disturbance in a decision making or to consider the
given time are based on an expert range of contextual conditions
consensus. sufficiently.
BS EN 62508:2010
62508 © IEC:2010 – 37 –

Annex B
(informative)

Summary of human-oriented design activities

and their impact on system dependability

B.1 Overview

This annex gives some examples of human-centred design activities that when used
appropriately, will improve system dependability.

B.2 Automation

Table B.1 – Automation

Human-centred design activity Impact on system dependability

• Provide automation information and operating • Enhancing availability of system functions.
status and other feedback to system user. • Improved system performance due to automated
• Make features easy to use. functions.
• Ensure safe operations within the user’s capacity • Enabling users to carry out the required tasks to
and capability. avoid increased cognitive demands, extreme
• Alert user of automation failure or degradation, and workload situations, interruption or distraction
potential unsafe modes of operation. imposed on the user.
• Provide error resistant and error tolerant features • Simplifying user training needs and requirements
that are not unnecessarily difficult to use to for system applications.
prevent unauthorized or accidental access. • Minimizing errors and risk arising from error.
• Provide means for manual override (with safe-
guards)

B.3 Design for maintainability

Table B.2 – Design for maintainability

Human-centred design activity Impact on system dependability

• Build in redundancy where practicable and cost- • Improved maintainability.
effective to reduce unscheduled maintenance. • Improved reliability.
• Design for modularity, lowest replaceable unit and • Simplification of maintenance functions.
throwaway assembly. • Enhancing testability, diagnostics, and fault
• Incorporate built-in-test capabilities, remote and identification.
self-diagnostic features. • Reduced maintenance time and logistic support
• Incorporate quick and easy access to all assembly resource requirements.
units requiring maintenance for inspection, removal
and replacement.
• Minimize the numbers and types of tools and test
equipment needed for maintenance.
• Incorporate self-healing and self-adjustment
features where applicable and practical.
 BS EN 62508:2010
– 38 – 62508 © IEC:2010

B.4 Computer-human interface

These activities are based on ISO 9241-110. For more detailed guidance on user interface
design, see ISO 9241, Parts 2, 12, 13, 14, 15, 16, 17, 20, 151 and 171.

Table B.3 – Computer-human interface

Human-centred design activity Impact on system dependability

• Make the interactive system suitable for the task • Improved system usability and serviceability.
so that it supports the user in the completion of the • Increased system speed.
task. • Reduced number of errors.

• Make the interactive dialogues self-descriptive so

that it is obvious to the users which dialogue they
are in, where they are within the dialogue, which
actions can be taken and how they can be
performed.

• Make the interactive dialogues conform with user

expectations so that it corresponds to predictable
contextual needs of the user and to commonly
accepted conventions.

• Make the interactive dialogues suitable for learning

so that they support and guide the user in learning
to use the system.

• Make the interactive dialogues controllable so that

the user is able to initiate and control the direction
and pace of the interaction.

• Make the interactive dialogues error-tolerant so

that despite evident errors in input, the intended
result can be achieved with either no, or minimal,
corrective action by the user.

• Make the interactive dialogues capable of

individualization so that users can modify
interaction and presentation of information to suit
their individual capabilities and needs.
BS EN 62508:2010
62508 © IEC:2010 – 39 –

B.5 Incorporation of displays, controls and alarm functions

For more detailed guidance on displays and controls, see ISO 9241, Parts 300, 302, 303, 304,
305, 306, 307, 308, 309, and 920.

Table B.4 – Incorporation of displays, controls and alarm functions

Human-centred design activity Impact on system dependability

• Make displays and controls legible, identifiable, • Improved maintainability.

and distinguishable under all conditions.
• Improved testability.
• Locate controls in a consistent manner in grouping
and arrangement for easy access to the user. • Improved system operation and maintenance
tasks.
• Design the control movement and direction in a
consistent manner. • Reduced number of false alarms.

• Design the controls with sequential operations to • Improved safety and security in system
follow a fixed pattern. performance.

• Design the controls for maintenance and • Simplifying user training needs and skills
adjustment to be protected to avoid accidental requirements.
activation.
• Design the coding for controls to differentiate
among the controls with uniform application of the
code throughout the system.
• Simplify coding entry and identify error for re-
entering codes.
• Design alarm functions to be visible and auditable.
• Design alarm functions to provide unambiguous
and clear indication of the cause for the alert,
inform the user of the priority and nature of the
problem, and possible responses.
• Incorporate alarm input validation to prevent false
alarms.
• Provide voice communication systems where
essential and applicable in alarm and emergency
situations.

B.6 Incorporation of input devices

For more detailed guidance on design of input devices, see ISO 9241, Parts 4, 9, 400, 410
and 920.
Table B.5 – Incorporation of input devices

Human factors design activity Impact on system dependability

• Design of keyboard entry and fixed-function keys. • Improved accessibility.

• Design of pointing devices (mouse, joystick and • Improved operability.
trackball, light pen).
• Improved usability.
• Design of non-pointing devices (touch interactive
devices and touch panels, voice activated
controls).
• Design inter-changeability among input devices
 BS EN 62508:2010
– 40 – 62508 © IEC:2010

B.7 Environment

For more detailed guidance on workplace environment, see ISO 9241-6.

Table B.6 – Environment

Human-centred design activity Impact on system dependability

• Modular designs for lowest replaceable units. • Improved maintainability.

• User control of workplace environment (ventilation, • Improved human performance and satisfaction in
illumination, temperature, humidity, noise). workplace.

B.8 Safety

Table B.7 – Safety

Human-centred design activity Impact on system dependability

• Workplace safety for accessibility and operation. • Improved human performance in a safe
environment.
• Equipment-related safety for user operation.
• Risk mitigation for degraded system performance.
• Hazard avoidance designs.
• Statistics on human performance.
• Human reliability analysis.

B.9 Security

Table B.8 – Security

Human-centred design activity Impact on system dependability

• System security and authorized access. • Improved system performance integrity.

• Security safeguards and protective measures and • Risk reduction.
controls.
• Physical security.
• Information security.
 BS EN 62508:2010
62508 © IEC:2010 – 41 –

Annex C
(informative)

Best practices for human-centred design

This annex lists the most important activities in ISO/PAS 18152 that are relevant at each
lifecycle stage (together with their reference numbers), and gives examples of methods and
techniques that can be used to implement them.

Table C.1 – Examples of methods and techniques that contribute to best practices

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
1.1 Concept Identify expected context of use of systems – Future workshop
(forthcoming needs, trends and expectations) (1.1-1)
– Preliminary field visit
Analyse the system concept to clarify objectives, their
viability and risks (1.1-2) – Focus groups
– Photographic surveys
– Simulations of future working environments
– In-depth analysis of work and lifestyles
Describe the objectives which the user or user – Participatory workshops
organization wants to achieve through use of the
system (1.1-3) – Field observations and ethnography
– Consult stakeholders
– Human factors analysis
Define the scope of the context of use for the system – Context of use analysis
(3.1-1)
1.2 Planning Develop a plan to achieve and maintain usability throughout – Plan to achieve and maintain usability
the life of the system (2.4-1)
a) General – Plan use of HSI data to mitigate risks
Identify the specialist skills required and plan how to
provide them (2.4-2)
b) User Identify the HS issues and aspects of the system that – Identify HSI issues and aspects of the
involvement require user input (2.6-1) system requiring user input
Define a strategy and plan for user involvement – Develop a plan for user involvement
(2.6-3)
Select and use the most effective method to elicit – Select and use the most effective methods
user input (2.6-4)
Customize tools and methods as necessary for – Customize tools and methods as necessary
particular projects/stages (2.7-4)
 BS EN 62508:2010
– 42 – 62508 © IEC:2010

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
c) Risks Assess the health and well-being risks to the users of – Risk analysis (process and product)
the system (1.2-6)
– HSI program risk analysis
Assess the risks to the community and environment
arising from human error in the use of the system
(1.2-7)
Evaluate the current severity of emerging threats to
system usability and other HS risks and the
effectiveness of mitigation measures (2.5-3)
Assess the risks of not involving end users in each
evaluation (2.6-2)
Plan and manage use of human factors data to mitigate
risks related to HS issues (2.5-1)
Evaluate the current severity of emerging threats to
system usability and other HS risks and the
effectiveness of mitigation measures (2.5-3)
Take effective mitigation to address risks to system
usability (2.5-4)

1.3 Identify and analyse the roles of each group of – Successful identification of critical
Understanding stakeholders likely to be affected by the system (1.1-4) stakeholders
needs
Describe the characteristics of the users (3.1-3) – Field observations and ethnography
a) Context of use
Describe the cultural environment/ organizational/ – Participatory workshop
management regime (3.1-4)
– Work context analysis
Describe the characteristics of any equipment
external to the system and the working environment – Context of use analysis
(3.1-5) – Event data analysis
Describe the location, workplace equipment and – Contextual enquiry
ambient conditions (3.1-6)
– Visibility diagram
Decide which goals, behaviours and tasks of the
organization influence human resources (4.1-1) – Reach envelope
Present context and human resources options and
constraints to the project stakeholders (1.1-6)
b) Tasks Analyse the tasks and work system (3.1-2) – Task analysis
– Cognitive task analysis
– Work context analysis
– Application/mission analysis
– Functional flow diagram
– Operational sequence diagram
– Flow process chart
– Decision/action diagram
– Action/information requirements
– Timeline
– Integrated computer-aided manufacturing
definition
– Workload analysis
– Situation awareness analysis
– Link analysis
– Human performance reliability analysis
c) Usability needs Perform research into required system usability (1.1- – Investigate required system usability
5)
– Usability benchmarking
– Heuristic/expert evaluation
– Predetermined time standards
 BS EN 62508:2010
62508 © IEC:2010 – 43 –

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
d) Design options Generate design options for each aspect of the – Early prototyping and usability evaluation
system related to its use and its effect on
stakeholders (1.2-1) – Develop simulations

Produce user-centered solutions for each design – Parallel design (tiger testing)
option (1.2-2)
1.4 Requirements Analyse the implications of the context of use (3.1-7) – Define the intended context of use,
including boundaries
a) Context
requirements
b) Infrastructure Identify, specify and produce the infrastructure for the – Identify staffing requirements and any
requirements system (1.3-2) training or support needed to ensure that
users achieve acceptable performance
Build required competencies into training and
awareness programs (1.3-4)
Define the global numbers, skills and supporting
equipment needed to achieve those tasks (4.1-2)
c) User Develop an explicit statement of the user – Scenarios
requirements requirements for the system (3.2-2)
– Personas
Generate and agree on measurable criteria for the
system in its intended context of use (3.2-4) – Storyboards
– Establish performance and satisfaction
goals for specific scenarios of use
– Define detailed user interface requirements
– Prioritize requirements
1.5 Analysis Assess the extent to which usability criteria and other – Identify and analyse the success of critical
requirements HS requirements are likely to be met by the proposed stakeholder requirements)
design (2.5-2)
– Common industry specification for usability
Analyse the user requirements (3.2-3) requirements
Present these requirements to project stakeholders – Environment/organization assessment
for use in the development and operation of the
system (3.2-5)
Identify any staffing gap and communicate
requirements to design of staffing solutions (4.2-6)
2. Design/ Generate design options for each aspect of the – Function allocation
development system related to its use and its effect on
stakeholders (1.2-1) – Generate design options
a) General
Produce user-centred solutions for each design option – Physical ergonomics
(1.2-2) – Participatory design
Design to enable customization to support specific – User interface guidelines and standards
market and user needs (1.2-3)
Distribute functions between the human, machine and
organizational elements of the system best able to fulfil
each function (3.3-1)
Develop a model of the user's work from the
requirements, context of use, allocation of function
and design constraints for the system (3.3-2)
Produce designs for the user-related elements of the
system that take into account the user requirements,
context of use and human factors data (3.3-3)
Produce a description of how the system will be used
to support integration of system components (3.3-4)
 BS EN 62508:2010
– 44 – 62508 © IEC:2010

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
b) Prototyping Develop simulation or trial implementation of key – Prototyping and usability evaluation
and evaluation aspects of the system for the purposes of testing with
users (1.2-4) – Develop prototypes
–Develop simulations
– Drawing
– Mock-up
– Scale model
– Manikin
– CAD environment
– Technical, manual and functional evaluation
– Use human factors engineering data for
evaluation
c) Human Decide which goals and tasks of the organization – Work domain analysis
resources influence human resources (4.1-1)
– Task analysis
Define the global numbers, skills and supporting
equipment needed to achieve those tasks (4.1-2) – Participatory design

Identify current tasking/duty (4.2-1) – Workload assessment

Analyse gap between existing and future provision – Human performance model
(4.2-3) – Design for alertness
Identify skill requirements for each role (4.2-3) – Plan staffing
Predict staff wastage between present and future
(4.2-4)
Calculate the available staffing, by taking into account
the working hours, attainable effort and non-
availability factor (4.2-5)
Identify and allocate the functions to be performed
(4.3-1)
Specify and produce job designs and competence/
skills required to be delivered (4.3-2)
Calculate the required number of personnel (4.3-3)
Generate costed options for delivery of training and/or
redeployment (4.3-4)
Evolve options and constraints into an optimal training
implementation plan (4.3.5)
Develop and submit to trial a training solution to
representative users (4.3-6)
Define how users will be re-allocated, dismissed or
transferred to other duties (1.5-3)
 BS EN 62508:2010
62508 © IEC:2010 – 45 –

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
3. Realization/ Maintain contact with users and the client – Risk analysis (process and product)
Implementation organization throughout the definition, development
and introduction of a system (1.3-3) – User feedback on usability and user
experience
Evolve options and constraints into an implementation
strategy covering technical, integration and planning – Use models and simulation
and manning issues (1.3-1) – Guidelines: common industry format for
Revise design and safety features using feedback usability reports
from evaluations (3.3-5) – Performance measurement
Deliver final training solutions to designated staff – Design criteria checklist
according to agreed timetable (4.3-7)
Collect user input on the usability of the developing
system (1.2-5)
Test that the system meets the requirements of the
users, the tasks and the environment, as defined in its
specification (1.3-5)
Review the system for adherence to applicable human
science knowledge, style guides, standards,
guidelines, regulations and legislation (1.4-3)
4. Operations Produce personnel strategy (1.4-1) – Work context analysis
Review the system for adherence to applicable human – Organizational and environmental context
science knowledge, style guides, standards, analysis
guidelines, regulations and legislation (1.4-3)
Deliver training and other forms of awareness-raising
to users and support staff (1.4-2)
Review health and well-being risks to the users of the
system (1.4-5)
Review the risks to the community and environment
arising from human error in the use of the system (1.4-6)
Perform research to refine and consolidate operation
and support strategy for the system (1.4-8)
5. Enhancement Provide means for user feedback (on human issues) – Organizational and environmental context
(4.4-2) analysis
Analyse feedback on the system during delivery and – Risk analysis
inform the organization of emerging issues (1.3-6)
– User feedback on usability and user
Assess the effect of change on the usability of the experience
system (1.4-4)
– Work context analysis
Take action on issues arising from in-service
assessment (1.4-7) – Continuous direct observation

Take effective mitigation to address risks to system – Sampled direct observation

usability (2.5-4) – Interviews and questionnaires
6. Retirement Collect and analyse in-service reports to generate
updates or lessons learnt for the next version of the
system (1.5-1)
Identify risks and health and safety issues associated
with removal from service and destruction of the
system (1.5-2)
Define how users will be re-allocated, dismissed, or
transferred to other duties (1.5-3)
Plan break-up of social structures (1.5-4)
Debriefing and retrospective analysis for replacement
system (1.5-5)
7. Outsourcing Take into account the stakeholder and user issues in – Common industry format
acquisition activities (2.3-1)
 BS EN 62508:2010
– 46 – 62508 © IEC:2010

Life cycle stage Best practices from ISO/PAS 18152 Example methods
(ISO/PAS 18152 reference number given in and techniques
brackets)
8. Integration Contribute to the business case for the system (1.1-7) – Program risk analysis
a) Business Define usability as a competitive asset (2.1-1) – Develop and maintain HSI infrastructure
strategy and resources
Set usability, health and safety objectives for systems (2.1-
b) Quality 2) – Identify required HSI skills
management
Develop user-centred infrastructure (2.1-4) – Provide staff with HSI skills
c) Authorization
and control Relate HS issues to business benefits (2.1-5) – Establish and communicate a policy on HSI
Define and maintain HCD and HR infrastructure and – Maintain an awareness of usability
resources (2.2-3)
Increase and maintain awareness of usability (2.2-4)
Develop or provide staff with suitable HS skills (2.2-5)
Implement the HR strategy that gives the organization
a mechanism for implementing and recording lessons
learnt (4.1-4)
Enable and encourage people and teams to work
together to deliver the organization's objectives (4.1-
6)
Create HR capabilities to meet future system
requirements (conduct succession planning) (4.2-7)
d) Staffing Decide how many people are needed to fulfil the
strategy and what ranges of competence they need
(4.1-3)
BS EN 62508:2010
62508 © IEC:2010 – 47 –

Bibliography

IEC 60812:2006, Analysis techniques for system reliability – Procedure for failure mode and
effects analysis (FMEA)

HF-STD-001:2002, Human Factors Design Standard (HFDS), Federal Aviation Administration

HFDG, 1996, FAA Human Factors Design Guide – For Acquisition of Commercial-Off-The-
Shelf Subsystems, Non-developmental Items, and Development Systems, DOT/FAA/CT-96/1.
Federal Aviation Administration

MIL-HDBK-46855A:1999, Human Engineering Program Process and Procedures. Department

of Defense

MIL-HDBK-1472F:1998, Human Engineering Design Criteria. Department of Defense

MIL-HDBK-1908B:1999, Definitions of Human Factors Terms. Department of Defense

WALLACE, D.F.; WINTERS, J.; DUGGER, M.; and LACKIE, J.:2001, “Human Systems
Engineering: Understanding the Process of Engineering the Human into the System”; Naval
Surface Warfare Center Dahlgren Division Technical Report NSWCDD/TR-01/101; November,
2001.

NASA, Man-Systems Integration Standards, NASA-STD-3000, Volume I and II (1995)

FAA, Guidelines for Human Factors Requirements Development, AAR-100 (2004)

ISO/PAS 18152:2003, Ergonomics of human-system interaction — Specification for the

process assessment of human-system issues

ISO 6385:2004, Ergonomic principles in the design of work systems

ISO 9000:2005, Quality management systems – Fundamentals and vocabulary

ISO 9241-1:1997, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 1: General introduction

ISO 9241-2:1992, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 2: Guidance on task requirements

ISO 9241-3:1992, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 3: Visual display requirements W 2008-11-14

ISO 9241-4:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 4: Keyboard requirements

ISO 9241-5:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 5: Workstation layout and postural requirements

ISO 9241-6:1999, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 6: Guidance on the work environment

ISO 9241-7:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 7: Requirements for display with reflections W 2008-11-14
 BS EN 62508:2010
– 48 – 62508 © IEC:2010

ISO 9241-8:1997, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 8: Requirements for displayed colours W 2008-11-14

ISO 9241-9:2000, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 9: Requirements for non-keyboard input devices

ISO 9241-11:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 11: Guidance on usability

ISO 9241-12:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 12: Presentation of information

ISO 9241-13:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 13: User guidance

ISO 9241-14:1997, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 14: Menu dialogues

ISO 9241-15:1997, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 15: Command dialogues

ISO 9241-16:1999, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 16: Direct manipulation dialogues

ISO 9241-17:1998, Ergonomic requirements for office work with visual display terminals
(VDTs) – Part 17: Form filling dialogues

ISO 9241-20:2008, Ergonomics of human-system interaction – Part 20: Accessibility

guidelines for information/communication technology (ICT) equipment and services

ISO 9241-110:2006, Ergonomics of human-system interaction – Part 110: Dialogue

principles

ISO 9241-151:2008, Ergonomics of human-system interaction – Part 151: Guidance on

World Wide Web user interfaces

ISO 9241-171:2008, Ergonomics of human-system interaction – Part 171: Guidance on

software accessibility

ISO 9241-210:–, Ergonomics of human-system interaction – Part 210: Human-centred

design for interactive systems 4

ISO 9241-300:2008, Ergonomics of human-system interaction – Part 300: Introduction to

electronic visual display requirements

ISO 9241-302:2008, Ergonomics of human-system interaction – Part 302: Terminology for

electronic visual displays

ISO 9241-303:2008, Ergonomics of human-system interaction – Part 303: Requirements for

electronic visual displays

ISO 9241-304:2008, Ergonomics of human-system interaction – Part 304: User performance

test methods for electronic visual displays
___________
4 To be published.
BS EN 62508:2010
62508 © IEC:2010 – 49 –

ISO 9241-305:2008, Ergonomics of human-system interaction – Part 305: Optical laboratory

test methods for electronic visual displays

ISO 9241-306:2008, Ergonomics of human-system interaction – Part 306: Field assessment

methods for electronic visual displays

ISO 9241-307:2008, Ergonomics of human-system interaction – Part 307: Analysis and

compliance test methods for electronic visual displays

ISO 9241-308:2008, Ergonomics of human-system interaction – Part 308: Surface-

conduction electron-emitter displays (SED)

ISO 9241-309:2008, Ergonomics of human-system interaction – Part 309: Organic light-

emitting diode (OLED) displays

ISO 9241-400:2007, Ergonomics of human-system interaction – Part 400: Principles and

requirements for physical input devices

ISO 9241-410:2008, Ergonomics of human system interaction – Part 410: Design criteria for
physical input devices

ISO 9241-920:2009, Ergonomics of human-system interaction – Part 920: Guidance on

tactile and haptic interactions

ISO 11064-1, Ergonomic design of control centres – Part 1: Principles for the design of
control centres

ISO 11064-2, Ergonomic design of control centres – Part 2: Principles for the arrangement
of control suites

ISO 11064-3, Ergonomic design of control centres – Part 3: Control room layout

ISO 11064-4, Ergonomic design of control centres – Part 4: Layout and dimensions of
workstations

ISO 11064-5, Ergonomic design of control centres – Part 5: Displays and controls

ISO 11064-6, Ergonomic design of control centres – Part 6: Environmental requirements for
control centres

ISO 11064-7, Ergonomic design of control centres – Part 7: Principles for the evaluation of
control centres

ISO/PAS 18152:2003, Ergonomics of human-system interaction – Specification for the

process assessment of human-system issues

ISO/TR 18529:2000, Ergonomics – Ergonomics of human-system interaction – Human-

centred lifecycle process descriptions

ISO/IEC 24765:–, Systems and software engineering – Vocabulary 5

___________
5 To be published.
 BS EN 62508:2010
– 50 – 62508 © IEC:2010

ISO/IEC DIS TR 25060:–, Software engineering – Software product Quality Requirements and
Evaluation (SQuaRE) – Common Industry Format (CIF) for usability – General framework for
usability-related information 6

Human reliability analysis (HRA)

NOTE Titles preceded by method, in acronym form.

ASEP: SWAIN, A.D. (1987) Accident Sequence Evaluation Program on Human Reliability
Analysis Procedure. NUREG/CR-4772. NRC. Washington DC

ATHEANA: NUREG-1624:2000, Technical Basis and Implementation Guidelines for A

Technique for Human Event Analysis (ATHEANA). NRC. Washington DC. Rev. 1

CAHR: STRÄTER, O.:2005, Cognition and safety – An Integrated Approach to Systems

Design and Performance Assessment. Ashgate. Aldershot. (ISBN 0754643255)

CREAM: HOLLNAGEL, E.:1998, Cognitive Reliability and Error Analysis Method – CREAM.
Elsevier. New York, Amsterdam. (ISBN 0-08-042848-7)

ESAT: BRAUSER, K.:1992, ESAT – Ein neues Verfahren zur Abschätzung der menschlichen
Zuverlässigkeit. In: Gärtner, K. (Hrsg.) Menschliche Zuverlässigkeit. DGLR-Bericht 92-04.
DGLR. Bonn

HCR/ORE: MOIENI, P., SPURGIN, A.J. & SINGH, A.:1994, Advances in Human Reliability
Analysis Methodology. Part I: Frameworks, Models and Data. Reliability Engineering and
System Safety. Vol.44. Elsevier. p. 27

KIRWAN, B.:1994, A Guide To Practical Human Reliability Assessment. CRC

MERMOS: LE BOT, P., DESMARES, E. & BIEDER, C.:1998, MERMOS: an EDF project to
update Human Reliability Assessment methodologies. In: Lydersen, S., Hansen, G. Sandtorv,
H. (1998) Safety and Reliability. ESREL'98, Trondheim/Norway. A. A. Balkema. Rotterdam. p.
767 ff

SLIM: EMBREY, D., HUMPHREYS, P. ROSA, E.A., KIRWAN, B. & REA, K.:1984, SLIM-
MAUD- An Approach to Assessing Human Error Probabilities Using Structured Expert
Judgement. NUREG/CR-3518. NRC. Washington DC

SPAR-H: BYERS, I.C., GERTMAN, D.I., HILL, S.G., BLACKMAN, H.S., GENTILLON, C.D.,
HALLBERT, B.P., & HANEY, L.N.:2000, SPAR HRA Methodology: Comparison with other
HRA methods. International Ergonomics – IEA 2000. San Diego. Human Factors and
Ergonomics Society. Santa Monica CA. Published by: Mira Digital Publishing. South
Jefferson, St. Lois, MO (www.miracd.com)

THERP: SWAIN, A.D. & GUTTMANN, H. E.:1983, Handbook of Human Reliability Analysis
with emphasis on nuclear power plant applications. Sandia National Laboratories,
NUREG/CR-1278. Washington DC

WILLIAMS, J.C.:1988, HEART – A data-based method for assessing and reducing human
error to improve operational performance. In: Proceedings of the IEEE Conference on Human
Factors and Power Plants. Monterey, CA. June 1988. P. 436-450

____________

___________
6 To be published.
This page deliberately left blank
This page deliberately left blank
British Standards Institution (BSI)
BSI is the independent national body responsible for preparing British Standards
and other standards-related publications, information and services.
It presents the UK view on standards in Europe and at the international level.
It is incorporated by Royal Charter.

Revisions Information on standards

British Standards are updated by amendment or revision. Users of British Stan- BSI provides a wide range of information on national, European
dards should make sure that they possess the latest amendments or editions. and international standards through its Knowledge Centre.
It is the constant aim of BSI to improve the quality of our products and serv- Tel: +44 (0)20 8996 7004 Fax: +44 (0)20 8996 7005
ices. We would be grateful if anyone finding an inaccuracy or ambiguity while Email: [email protected]
using this British Standard would inform the Secretary of the technical com-
mittee responsible, the identity of which can be found on the inside front Various BSI electronic information services are also available which
cover. give details on all its products and services.
Tel: +44 (0)20 8996 9001 Fax: +44 (0)20 8996 7001 Tel: +44 (0)20 8996 7111 Fax: +44 (0)20 8996 7048
Email: [email protected]
BSI offers Members an individual updating service called PLUS which ensures
that subscribers automatically receive the latest editions of standards. BSI Subscribing Members are kept up to date with standards
Tel: +44 (0)20 8996 7669 Fax: +44 (0)20 8996 7001 developments and receive substantial discounts on the purchase price
Email: [email protected] of standards. For details of these and other benefits contact Membership Ad-
ministration.
Buying standards Tel: +44 (0)20 8996 7002 Fax: +44 (0)20 8996 7001
Email: [email protected]
You may buy PDF and hard copy versions of standards directly using a
credit card from the BSI Shop on the website www.bsigroup.com/shop. Information regarding online access to British Standards via British
In addition all orders for BSI, international and foreign standards publications Standards Online can be found at www.bsigroup.com/BSOL
can be addressed to BSI Customer Services.
Further information about BSI is available on the BSI website at www.bsi-
Tel: +44 (0)20 8996 9001 Fax: +44 (0)20 8996 7001 group.com/standards
Email: [email protected]

In response to orders for international standards, it is BSI policy to Copyright

supply the BSI implementation of those that have been published
Copyright subsists in all BSI publications. BSI also holds the copyright,
as British Standards, unless otherwise requested.
in the UK, of the publications of the international standardization bodies. Ex-
cept as permitted under the Copyright, Designs and Patents Act 1988 no ex-
tract may be reproduced, stored in a retrieval system or transmitted in any
form or by any means – electronic, photocopying, recording or otherwise –
without prior written permission from BSI. This does not preclude the free
use, in the course of implementing the standard of necessary details such as
symbols, and size, type or grade designations. If these details are to be used
for any other purpose than implementation then the prior written permission
of BSI must be obtained. Details and advice can be obtained from the Copy-
right & Licensing Manager.
Tel: +44 (0)20 8996 7070
Email: [email protected]

BSI Group Headquarters

389 Chiswick High Road London W4 4AL UK
Tel +44 (0)20 8996 9001
Fax +44 (0)20 8996 7001
www.bsigroup.com/standards

raising standards worldwide™