IEC 61508-3:1998
(Main)Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements (see www.iec.ch/61508)
Functional safety of electrical/electronic/programmable electronic safety-related systems - Part 3: Software requirements (see <a href="http://www.iec.ch/61508">www.iec.ch/61508</a>)
Applies to any software forming part of a safety-related system or used to develop a safety-related system within the scope of IEC 61508-1 and IEC 61508-2. Provides requirements: - for safety lifecycle phases and actvities; - for informatin relating to the software safety validation; - for the preparation of information and procedures concerning software; - to be met by the organisation carrying out modifications to safety-related software; - for supporting tools. Has the status of a basic safety publication in accordance with IEC Guide 104. The contents of the corrigendum of April 1999 have been included in this copy.
Sécurité fonctionnelle des système électriques/électroniques/ électroniques programmables relatifs à la sécurité - Partie 3: Prescriptions concernant les logiciels (voir www.iec.ch/61508)
S'applique à tout logiciel faisant partie d'un système relatif à la sécurité, ou utilisé pour développer un système relatif à la sécurité entrant dans le domaine de la CEI 61508-1 et de la CEI 61508-2. Fournit les prescriptions: - concernant les phases et activités du cycle de vie de sécurité; - pour les informations relatives à la validation de la sécurité du logiciel; - pour la préparation des informations et procédures concernant le logiciel; - devant être observées par l'organisation en charge des modifications du logiciel relatif à la sécurité; - pour les outils supports. A le statut, d'une publication fondamentale de sécurité conformément au Guide 104. Le contenu du corrigendum d'avril 1999 a été pris en considération dans cet exemplaire.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL IEC
STANDARD
61508-3
First edition
1998-12
BASIC SAFETY PUBLICATION
Functional safety of electrical/electronic/
programmable electronic safety-related systems –
Part 3:
Software requirements
This English-language version is derived from the original
bilingual publication by leaving out all French-language
pages. Missing page numbers correspond to the French-
language pages.
Reference number
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.
Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the base
publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to this
publication, including its validity, is available in the IEC Catalogue of publications
(see below) in addition to new editions, amendments and corrigenda. Information on
the subjects under consideration and work in progress undertaken by the technical
committee which has prepared this publication, as well as the list of publications
issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees and
date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub) is
also available by email. Please contact the Customer Service Centre (see below)
for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:
Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD
61508-3
First edition
1998-12
BASIC SAFETY PUBLICATION
Functional safety of electrical/electronic/
programmable electronic safety-related systems –
Part 3:
Software requirements
IEC 1998 Copyright - all rights reserved
No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical,
including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
PRICE CODE
X
Commission Electrotechnique Internationale
International Electrotechnical Commission
Международная Электротехническая Комиссия
For price, see current catalogue
61508-3 IEC:1998 – 3 –
CONTENTS
Page
FOREWORD . 7
INTRODUCTION . 9
Clause
1 Scope. 13
2 Normative references. 19
3 Definitions and abbreviations . 19
4 Conformance to this standard . 19
5 Documentation . 19
6 Software quality management system . 21
6.1 Objectives. 21
6.2 Requirements . 21
7 Software safety lifecycle requirements . 23
7.1 General . 23
7.2 Software safety requirements specification. 35
7.3 Software safety validation planning . 39
7.4 Software design and development. 43
7.5 Programmable electronics integration (hardware and software) . 55
7.6 Software operation and modification procedures. 57
7.7 Software safety validation . 57
7.8 Software modification. 61
7.9 Software verification . 65
8 Functional safety assessment . 73
Annex A (normative) Guide to the selection of techniques and measures . 75
Annex B (normative) Detailed tables . 87
Annex C (informative) Bibliography . 95
Tables
1 Software safety lifecycle: overview. 29
A.1 Software safety requirements specification (see 7.2). 77
A.2 Software design and development: software architecture design (see 7.4.3). 77
A.3 Software design and development: support tools and programming language
(see 7.4.4). 79
A.4 Software design and development: detailed design (see 7.4.5 and 7.4.6) . 79
61508-3 IEC:1998 – 5 –
Table Page
A.5 Software design and development: software module testing and integration
(see 7.4.7 and 7.4.8) . 81
A.6 Programmable electronics integration (hardware and software) (see 7.5) . 81
A.7 Software safety validation (see 7.7) . 81
A.8 Modification (see 7.8) . 83
A.9 Software verification (see 7.9) . 83
A.10 Functional safety assessment (see clause 8) . 85
B.1 Design and coding standards (referenced by table A.4). 87
B.2 Dynamic analysis and testing (referenced by tables A.5 and A.9) . 87
B.3 Functional and black-box testing (referenced by tables A.5, A.6 and A.7) . 89
B.4 Failure analysis (referenced by table A.10) . 89
B.5 Modelling (referenced by table A.7). 89
B.6 Performance testing (referenced by tables A.5 and A.6) . 91
B.7 Semi-formal methods (referenced by tables A.1, A.2 and A.4) . 91
B.8 Static analysis (referenced by table A.9) . 91
B.9 Modular approach (referenced by table A.4). 93
Figures
1 Overall framework of this standard. 17
2 E/E/PES safety lifecycle (in realisation phase) . 25
3 Software safety lifecycle (in realisation phase) . 25
4 Relationship between and scope of IEC 61508-2 and 61508-3 . 27
5 Software safety integrity and the development lifecycle (the V-model) . 27
6 Relationship between the hardware and software architectures of programmable
electronics. 35
61508-3 IEC:1998 – 7 –
FUNCTIONAL SAFETY OF
ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC
SAFETY-RELATED SYSTEMS –
Part 3: Software requirements
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization
for Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical reports or guides and they are accepted by the National Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject
of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61508-3 has been prepared by subcommittee 65A: System aspects,
of IEC technical committee 65: Industrial-process measurement and control.
The text of this standard is based on the following documents:
FDIS Report on voting
65A/269/FDIS 65A/277/RVD
Full information on the voting for the approval of this standard can be found in the voting report
indicated in the above table.
Annexes A and B form an integral part of this standard.
Annex C is for information only.
IEC 61508 consists of the following parts, under the general title Functional safety of electrical/
electronic/programmable electronic safety-related systems:
– Part 1: General requirements
– Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems
– Part 3: Software requirements
– Part 4: Definitions and abbreviations
– Part 5: Examples of methods for the determination of safety integrity levels
– Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
– Part 7: Overview of techniques and measures
The contents of the corrigendum of April 1999 have been included in this copy.
61508-3 IEC:1998 – 9 –
INTRODUCTION
Systems comprised of electrical and/or electronic components have been used for many years
to perform safety functions in most application sectors. Computer-based systems (generically
referred to as programmable electronic systems (PESs)) are being used in all application
sectors to perform non-safety functions and, increasingly, to perform safety functions. If
computer system technology is to be effectively and safely exploited, it is essential that those
responsible for making decisions have sufficient guidance on the safety aspects on which to
make those decisions.
This International Standard sets out a generic approach for all safety lifecycle activities for
systems comprised of electrical and/or electronic and/or programmable electronic components
(electrical/electronic/ programmable electronic systems (E/E/PESs)) that are used to perform
safety functions. This unified approach has been adopted in order that a rational and consistent
technical policy be developed for all electrically-based safety-related systems. A major
objective is to facilitate the development of application sector standards.
In most situations, safety is achieved by a number of protective systems which rely on many
technologies (for example mechanical, hydraulic, pneumatic, electrical, electronic,
programmable electronic). Any safety strategy must therefore consider not only all the
elements within an individual system (for example sensors, controlling devices and actuators),
but also all the safety-related systems making up the total combination of safety-related
systems. Therefore, while this International Standard is concerned with electrical/electronic/
programmable electronic (E/E/PE) safety-related systems, it may also provide a framework
within which safety-related systems based on other technologies may be considered.
It is recognized that there is a great variety of E/E/PES applications in a variety of application
sectors and covering a wide range of complexity, hazard and risk potentials. In any particular
application, the required safety measures will be dependent on many factors specific to the
application. This International Standard, by being generic, will enable such measures to be
formulated in future application sector international standards.
This International Standard
– considers all relevant overall, E/E/PES and software safety lifecycle phases (for example,
from initial concept, through design, implementation, operation and maintenance to
decommissioning) when E/E/PESs are used to perform safety functions;
– has been conceived with a rapidly developing technology in mind; the framework is
sufficiently robust and comprehensive to cater for future developments;
– enables application sector international standards, dealing with safety-related E/E/PESs, to
be developed; the development of application sector international standards, within the
framework of this International Standard, should lead to a high level of consistency (for
example, of underlying principles, terminology etc.) both within application sectors and
across application sectors; this will have both safety and economic benefits;
– provides a method for the development of the safety requirements specification necessary
to achieve the required functional safety for E/E/PE safety-related systems;
– uses safety integrity levels for specifying the target level of safety integrity for the safety
functions to be implemented by the E/E/PE safety-related systems;
61508-3 IEC:1998 – 11 –
– adopts a risk-based approach for the determination of the safety integrity level
requirements;
– sets numerical target failure measures for E/E/PE safety-related systems which are linked
to the safety integrity levels;
– sets a lower limit on the target failure measures, in a dangerous mode of failure, that can
be claimed for a single E/E/PE safety-related system; for E/E/PE safety-related systems
operating in
• a low demand mode of operation, the lower limit is set at an average probability of
–5
failure of 10 to perform its design function on demand,
• a high demand or continuous mode of operation, the lower limit is set at a probability of
–9
a dangerous failure of 10 per hour;
NOTE – A single E/E/PE safety-related system does not necessarily mean a single-channel architecture.
– adopts a broad range of principles, techniques and measures to achieve functional safety
for E/E/PE safety-related systems, but does not use the concept of fail safe, which may be
of value when the failure modes are well defined and the level of complexity is relatively
low. The concept of fail safe was considered inappropriate because of the full range of
complexity of E/E/PE safety-related systems that are within the scope of the standard.
61508-3 IEC:1998 – 13 –
FUNCTIONAL SAFETY OF
ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC
SAFETY-RELATED SYSTEMS –
Part 3: Software requirements
1 Scope
1.1 This part of IEC 61508
a) is intended to be utilised only after a thorough understanding of IEC 61508-1 and
IEC 61508-2;
b) applies to any software forming part of a safety-related system or used to develop a safety-
related system within the scope of IEC 61508-1 and IEC 61508-2. Such software is termed
safety-related software.
– Safety-related software includes operating systems, system software, software in
communication networks, human-computer interface functions, support tools and
firmware as well as application programs.
– Application programs include high level programs, low level programs and special
purpose programs in limited variability languages (see 3.2.7 of IEC 61508-4).
c) requires that the software safety functions and software safety integrity levels are specified.
NOTE 1 – If this has already been done as part of the specification of the E/E/PE safety-related systems (see
7.2 of IEC 61508-2), then it does not have to be repeated in this part.
NOTE 2 – Specifying the software safety functions and software safety integrity levels is an iterative procedure;
see figures 2 and 6.
NOTE 3 – See clause 5 and annex A of IEC 61508-1 for documentation structure. The documentation structure
may take account of company procedures, and of the working practices of specific application sectors.
d) establishes requirements for safety lifecycle phases and activities which shall be applied
during the design and development of the safety-related software (the software safety
lifecycle model). These requirements include the application of measures and techniques,
which are graded against the safety integrity level, for the avoidance of and control of faults
and failures in the software.
e) provides requirements for information relating to the software safety validation to be passed
to the organisation carrying out the E/E/PES integration.
f) provides requirements for the preparation of information and procedures concerning
software needed by the user for the operation and maintenance of the E/E/PE safety-
related system.
g) provides requirements to be met by the organisation carrying out modifications to safety-
related software.
h) provides, in conjunction with IEC 61508-1 and IEC 61508-2, requirements for support tools
such as development and design tools, language translators, testing and debugging tools,
configuration management tools.
NOTE 4 – Figures 4 and 6 show the relationship between IEC 61508-2 and IEC 61508-3.
61508-3 IEC:1998 – 15 –
1.2 Parts 1, 2, 3 and 4 of this standard are basic safety publications, although this status
does not apply in the context of low complexity E/E/PE safety-related systems (see 3.4.4 of
part 4). As basic safety publications, they are intended for use by technical committees in the
preparation of standards in accordance with the principles contained in IEC Guide 104 and
ISO/IEC Guide 51. Parts 1, 2, 3, and 4 are also intended for use as stand-alone publications.
One of the responsibilities of a technical committee is, wherever applicable, to make use of
basic safety publications in the preparation of its publications. In this context, the requirements,
test methods or test conditions of this basic safety publication will not apply unless specifically
referred to or included in the publications prepared by those technical committees.
NOTE – In the USA and Canada, until the proposed process sector implementation of IEC 61508 (i.e. IEC 61511) is
published as an international standard in the USA and Canada, existing national process safety standards based on
IEC 61508 (i.e. ANSI/ISA S84.01-1996) can be applied to the process sector instead of IEC 61508.
1.3 Figure 1 shows the overall framework of parts 1 to 7 IEC 61508, and indicates the role
that IEC 61508-3 plays in the achievement of functional safety for E/E/PE safety-related
systems. Annex A of IEC 61508-6 describes the application of IEC 61508-2 and IEC 61508-3.
61508-3 IEC:1998 – 17 –
Technical
requirements
PART 1
Development of the overall safety
requirements (concept, scope
definition, hazard and risk analysis)
(E/E/PE safety-related systems, other
PART 5
technology safety-related systems and
Risk based approaches
external risk reduction facilities)
to the development of
7.1 to 7.5
the safety integrity
requirements
Other
PART 1
requirements
Allocation of the safety
requirements to the E/E/PE
safety-related systems
Definitions and
PART 7
7.6
abbreviations
Overview of
techniques
and measures
PART 4
PART 6
Guidelines for the
Documentation
Realisation Realisation
application of
phase for phase for
parts 2 and 3 Clause 5 and
E/E/PE safety- safety-related
annex A
related systems software
PART 1
PART 2
PART 3
Management of
functional safety
Clause 6
PART 1
PART 1
Installation and commissioning
and safety validation of E/E/PE
Functional safety
safety-related systems
assessment
Clause 8
7.13 and 7.14
PART 1
PART 1
Operation and maintenance,
modification and retrofit,
decommissioning or disposal of
E/E/PE safety-related systems
7.15 to 7.17
IEC 1 686/98
Figure 1 – Overall framework of this standard
61508-3 IEC:1998 – 19 –
2 Normative references
The following normative documents contain provisions which, through reference in this text,
constitute provisions of this part of IEC 61508. At the time of publication, the editions indicated
were valid. All normative documents are subject to revision, and parties to agreements based
on this part of IEC 61508 are encouraged to investigate the possibility of applying the most
recent editions of the normative documents indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.
Functional safety of electrical/electronical/programmable electronic safety-
IEC 61508-1:1998,
related systems – Part 1: General requirements
IEC 61508-2, — Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 2: Requirements for electrical/electronical/programmable electronic
1)
safety-related systems
IEC 61508-4:1998, Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 4: Definitions and abbreviations of terms
IEC 61508-5:1998, Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 5: Examples of methods for the determination of safety integrity levels
IEC 61508-6: —, Functional safety of electrical/electronical/programmable electronic safety-
1)
related systems – Part 6: Guidelines on the application of parts 2 and 3
IEC 61508-7: —, Functional safety of electrical/electronical/programmable electronic safety-
1)
related systems – Part 7: Overview of techniques and measures
ISO/IEC Guide 51:1990, Guidelines for the inclusion of safety aspects in standards
IEC Guide 104:1997, Guide to the drafting of safety standards, and the role of Committees with
safety pilot functions and safety group functions
3 Definitions and abbreviations
For the purposes of this standard, the definitions and abbreviations given in IEC 61508-4 apply.
4 Conformance to this standard
The requirements for conformance to this standard are given in clause 4 of IEC 61508-1.
5 Documentation
The objectives and requirements for documentation are given in clause 5 of IEC 61508-1.
___________
1)
To be published.
61508-3 IEC:1998 – 21 –
6 Software quality management system
6.1 Objectives
The objectives are as detailed in 6.1 of IEC 61508-1.
6.2 Requirements
6.2.1 The requirements are as detailed in 6.2 of IEC 61508-1 with the following additional
requirements.
6.2.2 The functional safety planning shall define the strategy for the software procurement,
development, integration, verification, validation and modification to the extent required by the
safety integrity level of the E/E/PE safety related system.
NOTE – The philosophy of this approach is to use the functional safety planning as an opportunity to customise this
standard to take account of the varying safety integrity which is required in the E/E/PE safety-related system
components. 7.4.2.8 of part 3 should be taken into account when E/E/PE safety-related system components of
differing safety integrity levels are to be used together.
6.2.3 Software configuration management should
a) apply administrative and technical controls throughout the software safety lifecycle, in order
to manage software changes and thus ensure that the specified requirements for software
safety continue to be satisfied;
b) guarantee that all necessary operations have been carried out to demonstrate that the
required software safety integrity has been achieved;
c) maintain accurately and with unique identification all configuration items which are
necessary to maintain the integrity of the E/E/PE safety-related system. Configuration items
include at least the following: safety analysis and requirements; software specification and
design documents; software source code modules; test plans and results; pre-existing
software components and packages which are to be incorporated into the E/E/PE safety-
related system; all tools and development environments which are used to create or test, or
carry out any action on, the software of the E/E/PE safety-related system;
d) apply change-control procedures to prevent unauthorized modifications; to document
modification requests; to analyse the impact of a proposed modification, and to approve or
reject the request; to document the details of, and the authorisation for, all approved
modifications; to establish configuration baseline at appropriate points in the software
development, and to document the (partial) integration testing which justifies the baseline
(see 7.8); to guarantee the composition of, and the building of, all software baselines
(including the rebuilding of earlier baselines);
NOTE 1 – Management decision and authority is needed to guide and enforce the use of administrative and
technical controls.
e) document the following information to permit a subsequent audit: configuration status,
release status, the justification for and approval of all modifications, and the details of the
modification;
f) formally document the release of safety-related software. Master copies of the software and
all associated documentation should be kept to permit maintenance and modification
throughout the operational lifetime of the released software.
NOTE 2 – For further information on configuration management, see ISO/IEC 12207.
61508-3 IEC:1998 – 23 –
7 Software safety lifecycle requirements
7.1 General
7.1.1 Objective
The objective of the requirements of this subclause is to structure the development of the
software into defined phases and activities (see table 1 and figures 2 to 5).
7.1.2 Requirements
7.1.2.1 A safety lifecycle for the development of software shall be selected and specified
during safety planning in accordance with clause 6 of IEC 61508-1.
NOTE – A safety lifecycle model which satisfies the requirements of clause 7 of IEC 61508-1 may be suitably
customised for the particular needs of the project or organisation.
7.1.2.2 Quality and safety assurance procedures shall be integrated into safety lifecycle
activities.
7.1.2.3 Each phase of the software safety lifecycle shall be divided into elementary activities
with the scope, inputs and outputs specified for each phase.
NOTE 1 – For further information on lifecycle phases, see ISO/IEC 12207.
NOTE 2 – Clause 5 of IEC 61508-1 considers the outputs from the safety lifecycle phases. In the development of
some E/E/PE safety-related systems, the output from some safety lifecycle phases may be a distinct document,
while the documented outputs from several phases may be merged. The essential requirement is that the output of
the safety lifecycle phase be fit for its intended purpose. In simple developments, some safety lifecycle phases may
also be merged (see 7.4.5).
7.1.2.4 Provided that the software safety lifecycle satisfies the requirements of figure 3 and
table 1, it is acceptable to tailor the depth, number and work-size of the phases of the V-model
(see figure 5) to take account of the safety integrity and the complexity of the project.
NOTE – The full list of lifecycle phases in table 1 is suitable for large newly developed systems. In small systems, it
might be appropriate, for example, to merge the phases of software system design and architectural design.
7.1.2.5 It is acceptable to order the software project differently from the organization of this
standard (i.e. use another software safety lifecycle model), provided all the objectives and
requirements of this clause are met.
7.1.2.6 For each lifecycle phase, appropriate techniques and measures shall be used.
Annexes A and B (guide to the selection of techniques and measures) give recommendations.
Selecting techniques from annexes A and B does not guarantee by itself that the required
safety integrity will be achieved.
7.1.2.7 The results of the activities in the software safety lifecycle shall be documented (see
clause 5).
7.1.2.8 If at any stage of the software safety lifecycle, a change is required pertaining to an
earlier lifecycle phase, then that earlier safety lifecycle phase and the following phases shall be
repeated.
61508-3 IEC:1998 – 25 –
Box 9 in figure 2
of IEC 61508-1 E/E/PES safety lifecycle
Safety-related
systems:
9.1 E/E/PES safety requirements
E/E/PES
specification
Safety functions Safety integrity
Realisation
9.1.1 9.1.2
requirements requirements
specification
specification
E/E/PES safety E/E/PES design
9.3
9.2
and development
validation planning
E/E/PES
E/E/PES operation and
9.4
9.5
integration maintenance procedures
E/E/PES safety
9.6
validation
One E/E/PES safety
lifecycle for each
To box 14
E/E/PE safety-related
in figure 2
system
of IEC 61508-1
To box 12 in figure 2 of IEC 61508-1
IEC 1 687/98
Figure 2 – E/E/PES safety lifecycle (in realisation phase)
Software safety lifecycle
Software safety requirements
9.1
specification
Safety functions Safety integrity
9.1.1
9.1.2
requirements requirements
specification specification
E/E/PES
safety
lifecycle
(see figure 2)
Software design
Software safety
9.2 9.3
and development
validation planning
PE integration Software operation and
9.4 9.5
(hardware/software) modification procedures
Software safety
9.6
validation
To box 14
in figure 2
To box 12 in figure 2 of IEC 61508-1
of IEC 61508-1
IEC 1 688/98
Figure 3 – Software safety lifecycle (in realisation phase)
61508-3 IEC:1998 – 27 –
Scope of
IEC 61508-2
E/E/PES safety
E/E/PES
requirements
architecture
specification
Hardware safety requirements
Scope of Non-programmable
Programmable
Software safety
hardware
electronic hardware
IEC 61508-3 requirements
Programmable Non-programmable
Software design
electronics design hardware design
and development
and development
and development
Programmable electronics
E/E/PES
integration (hardware and
integration
software)
IEC 1 689/98
Figure 4 – Relationship between and scope of IEC 6158-2 and IEC 61508-3
E/E/PES safety Software safety Validation
Validation
Validated
requirements requirements
testing
software
specification specification
Integration testing
E/E/PES Software
(components, subsystems
architecture architecture
and programmable
electronics)
Integration
Software system
testing
design
(module)
Module Module
design testing
Output
Verification
CODING
IEC 1 690/98
Figure 5 – Software safety integrity and the development lifecycle (the V-model)
61508-3 IEC:1998 – 29 –
Table 1 – Software safety lifecycle: overview
Inputs
Safety lifecycle Objectives Scope Require- Outputs
(information
phase ments (information
required)
subclause produced)
Figure 3 Title
box
number
9.1 Software safety To specify the requirements for PES; 7.2.2 E/E/PES Software safety
requirements software safety in terms of the Software safety requirements
specification requirements for software safety system. requirements specification.
functions and the requirements for specification
software safety integrity; (IEC 61508-2).
To specify the requirements for the
software safety functions for each
E/E/PE safety-related system
necessary to implement the required
safety functions;
To specify the requirements for
software safety integrity for each
E/E/PE safety-related system
necessary to achieve the safety
integrity level specified for each
safety function allocated to that
E/E/PE safety-related system.
9.2 Software safety To develop a plan for validating PES; 7.3.2 Software Software safety
validation the software safety. software safety validation plan.
planning system. requirements
specification.
9.3 Software design Architecture: PES; 7.4.3 Software Software
and software safety architecture design
To create a software architecture
development system. requirements description;
that fulfils the specified requirements
specification;
software
for software safety with respect to
the required safety integrity level; E/E/PES architecture
hardware integration test
To review and evaluate the
architecture specification;
requirements placed on the software
design (from
software/
by the hardware architecture of the
IEC 61508-2).
E/E/PE safety-related system, programmable
including the significance of E/E/PE electronics
hardware/software interactions for integration test
specification (the
safety of the equipment under
same as
control.
IEC 61508-2
requires).
9.3 Software Support tools and programming PES; 7.4.4 Software Development tools
design and safety and coding
languages:
development software requirements standards;
To select a suitable set of tools,
system; specification;
including languages and compilers, selection of
software development tools.
for the required safety integrity level,
support
architecture
over the whole safety lifecycle of the
tools;
design
software which assists verification,
validation, assessment and description.
program-
modification.
ming
language.
61508-3 IEC:1998 – 31 –
Table 1 (continued)
Safety lifecycle Objectives Scope Require- Inputs Outputs
phase ments (information (information
subclause required) produced)
Figure 3 Title
box
number
9.3 Software Major 7.4.5 Software Software system
Detailed design and development
design and components architecture design
(software system design):
development and design specification;
To design and implement software
subsystems description;
software system
that fulfils the specified requirements
of software
support tools integration test
for software safety with respect to
architectural
and coding specification.
the required safety integrity level,
design.
which is analysable and verifiable, standards.
and which is capable of being safely
modified.
9.3 Software Detailed design and development Software 7.4.5 Software Software module
design and system system design design
(individual software module
development design. specification; specification;
design):
support tools software module
To design and implement software
and coding test specification.
that fulfils the specified requirements
standards.
for software safety with respect to
the required safety integrity level,
which is analysable and verifiable,
and which is capable of being safely
modified.
9.3 Software Detailed code implementation: Individual 7.4.6 Software Source code
design and software module design listing;
To design and implement software
development modules. specification;
code review report.
that fulfils the specified requirements
for software safety with respect to support tools
the required safety integrity level, and coding
standards.
which is analysable and verifiable,
and which is capable of being safely
modified.
9.3 Software Software module testing: Software 7.4.7 Software Software module
design and modules. module test test results;
To verify that the requirements for
development specification;
verified and tested
software safety (in terms of the
required software safety functions source code software modules.
and the software safety integrity) listing;
have been achieved – to show that
code review
each software module performs its
report.
intended function and does not
perform unintended functions.
9.3 Software Software 7.4.8 Software Software system
Software integration testing:
design and architecture; system integration test
To verify that the requirements for
development integration test results;
software safety (in terms of the software
specification.
required software safety functions system. verified and tested
software system.
and the software safety integrity)
have been achieved – to show that
all software modules, components
and subsystems interact correctly to
perform their intended function and
do not perform unintended functions.
61508-3 IEC:1998 – 33 –
Table 1 (concluded)
Inputs
Safety lifecycle Objectives Scope Require- Outputs
(information
phase ments (information
required)
subclause produced)
Figure 3 Title
box
number
9.4 Programmable To integrate the software onto the Program- 7.5.2 Software Software
electronics target programmable electronic mable architecture architecture
integration hardware; electronics integration test integration test
hardware; specification; results;
(hardware and To combine the software and
software) hardware in the safety-related integrated programmable programmable
programmable electronics to software. electronics electronics
ensure their compatibility and to integration test integration test
meet the requirements of the specification results;
intended safety integrity level. (the same as
verified and tested
IEC 61508-2
integrated
requires);
programmable
integrated electronics.
programmable
electronics.
9.5 Software To provide information and As above 7.6.2 All above, as Software operation
operation and procedures concerning software relevant. and modification
modification necessary to ensure that the procedures.
procedures functional safety of the E/E/PE
safety-related system is maintained
during operation and modification.
9.6 Software safety To ensure that the integrated As above 7.7.2 Software Software safety
validation system complies with the specified safety validation results;
requirements for software safety at validation
Validated
the intended safety integrity level. plan.
software.
– Software To make corrections, As above 7.8.2 Software Software
modification enhancements or adaptations to modification modification
the validated software, ensuring procedures; impact analysis
that the required software safety results;
software
integrity level is sustained.
modification software
request. modification log.
– Software To the extent required by the Depends on 7.9.2 Appropriate Appropriate
verification safety integrity level, to test and phase verification verification report
evaluate the outputs from a given plan (depends (depends
software safety lifecycle phase to on phase). on phase).
ensure correctness and consis-
tency with respect to the outputs
and standards provided as input to
that phase.
– Software To investigate and arrive at a All above 8 Software Software
functional judgement on the functional safety phases functional functional safety
safety achieved by the E/E/PE safety- safety assessment
assessment related systems. assessment report.
plan.
61508-3 IEC:1998 – 35 –
7.2 Software safety requirements specification
NOTE 1 – See also tables A.1 and B.7.
NOTE 2 – This phase is box 9.1 of figure 3.
7.2.1 Objectives
7.2.1.1 The first objective of the requirements of this subclause is to specify the requirements
for software safety in terms of the requirements for software safety functions and the
requirements for software safety integrity.
7.2.1.2 The second objective of the requirements of this subclause is to specify the
requirements for the software safety functions for each E/E/PE safety-related system
necessary to implement the required safety functions.
7.2.1.3 The third objective of the requirements of this subclause is to specify the require-
ments for software safety integrity for each E/E/PE safety-related system necessary to achieve
the safety integrity level specified for each safety function allocated to that E/E/PE safety-
related system.
Sensors
Logic system Final elements
Architectures shown are
PE
examples and could be: NP NP
PE
— single channel;
PE PE
— dual channel;
PE
H/W H/W
— 1oo2, 1oo3, 2oo2 S/W S/W
H/W S/W
etc.
Programmable electronics architecture
PE software architecture (s/w architecture
PE hardware architecture
consists of embedded s/w and applications s/w)
Generic and application specific PE embedded software PE applications software
features in PE hardware.
Examples include:
Examples include:
Examples include:
— communications — input/output functions;
— diagnostic tests;
drivers;
— derived functions (for
— redundant processors;
— fault handling; example sensor checking
— dual I/O cards.
if not provided as a service
— executive software.
of the embedded software).
IEC 1 691/98
Key
PE programmable electronics
NP non-programmable devices
H/W hardware
S/W software
MooN M out of N (for example 1oo2 is 1 out of 2)
Figure 6 — Relationship between the hardware and software architectures
of programmable electronics
61508-3 IEC:1998 – 37 –
7.2.2 Requirements
NOTE – These requirements will in most cases be achieved by a combination of generic embedded software and
application specific software. It is the combination of both that is required to provide the features that satisfy the
following subclauses. The exact division between generic and application specific software depends on the chosen
software architecture (see 7.4.3 and figure 6).
7.2.2.1 If the requirements for software safety have already been specified in the
requirements for the E/E/PE safety-related system (see 7.2 of IEC 61508-2), then the
specification of software safety requirements need not be repeated.
7.2.2.2 The specification of the requirements for software safety shal
...
NORME CEI
INTERNATIONALE
61508-3
Première édition
1998-12
PUBLICATION FONDAMENTALE DE SÉCURITÉ
Sécurité fonctionnelle des systèmes électriques/
électroniques/électroniques programmables
relatifs à la sécurité –
Partie 3:
Prescriptions concernant les logiciels
Cette version française découle de la publication d’origine
bilingue dont les pages anglaises ont été supprimées.
Les numéros de page manquants sont ceux des pages
supprimées.
Numéro de référence
CEI 61508-3:1998(F)
Numérotation des publications
Depuis le 1er janvier 1997, les publications de la CEI sont numérotées à partir de
60000. Ainsi, la CEI 34-1 devient la CEI 60034-1.
Editions consolidées
Les versions consolidées de certaines publications de la CEI incorporant les
amendements sont disponibles. Par exemple, les numéros d’édition 1.0, 1.1 et 1.2
indiquent respectivement la publication de base, la publication de base incorporant
l’amendement 1, et la publication de base incorporant les amendements 1 et 2
Informations supplémentaires sur les publications de la CEI
Le contenu technique des publications de la CEI est constamment revu par la CEI
afin qu'il reflète l'état actuel de la technique. Des renseignements relatifs à cette
publication, y compris sa validité, sont disponibles dans le Catalogue des
publications de la CEI (voir ci-dessous) en plus des nouvelles éditions, amende-
ments et corrigenda. Des informations sur les sujets à l’étude et l’avancement des
travaux entrepris par le comité d’études qui a élaboré cette publication, ainsi que la
liste des publications parues, sont également disponibles par l’intermédiaire de:
• Site web de la CEI (www.iec.ch)
• Catalogue des publications de la CEI
Le catalogue en ligne sur le site web de la CEI (www.iec.ch/searchpub) vous permet
de faire des recherches en utilisant de nombreux critères, comprenant des
recherches textuelles, par comité d’études ou date de publication. Des informations
en ligne sont également disponibles sur les nouvelles publications, les publications
remplacées ou retirées, ainsi que sur les corrigenda.
• IEC Just Published
Ce résumé des dernières publications parues (www.iec.ch/online_news/justpub)
est aussi disponible par courrier électronique. Veuillez prendre contact avec le
Service client (voir ci-dessous) pour plus d’informations.
• Service clients
Si vous avez des questions au sujet de cette publication ou avez besoin de
renseignements supplémentaires, prenez contact avec le Service clients:
Email: custserv@iec.ch
Tél: +41 22 919 02 11
Fax: +41 22 919 03 00
NORME CEI
INTERNATIONALE
61508-3
Première édition
1998-12
PUBLICATION FONDAMENTALE DE SÉCURITÉ
Sécurité fonctionnelle des systèmes électriques/
électroniques/électroniques programmables
relatifs à la sécurité –
Partie 3:
Prescriptions concernant les logiciels
IEC 1998 Droits de reproduction réservés
Aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun
procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de l'éditeur.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
CODE PRIX
X
Commission Electrotechnique Internationale
International Electrotechnical Commission
Международная Электротехническая Комиссия
Pour prix, voir catalogue en vigueur
– 2 – 61508-3 © CEI:1998
SOMMAIRE
Pages
AVANT-PROPOS . 6
INTRODUCTION . 8
Articles
1 Domaine d'application. 12
2 Références normatives . 18
3 Définitions et abréviations. 18
4 Conformité à la présente norme . 18
5 Documentation . 18
6 Système de gestion de la qualité du logiciel . 20
6.1 Objectifs . 20
6.2 Prescriptions. 20
7 Prescriptions concernant le cycle de vie de sécurité du logiciel. 22
7.1 Généralités . 22
7.2 Spécification des prescriptions de sécurité du logiciel. 34
7.3 Planification de la validation de sécurité du logiciel. 38
7.4 Conception et développement du logiciel. 42
7.5 Intégration de l’électronique programmable (matériel et logiciel) . 54
7.6 Procédures d'exploitation et de modification du logiciel. 56
7.7 Validation de sécurité du logiciel . 56
7.8 Modification du logiciel. 60
7.9 Vérification du logiciel . 64
8 Evaluation de la sécurité fonctionnelle. 72
Annexe A (normative) Guide de sélection de techniques et mesures . 74
Annexe B (normative) Tableaux détaillés . 86
Annexe C (informative) Bibliographie . 94
Tableaux
1 Cycle de vie de sécurité du logiciel: présentation . 28
A.1 Spécification des prescriptions de sécurité du logiciel (voir 7.2) . 76
A.2 Conception et développement du logiciel: conception de l'architecture du logiciel
(voir 7.4.3) . 76
A.3 Conception et développement du logiciel: outils supports et langage
de programmation (voir 7.4.4) . 78
A.4 Conception et développement du logiciel: conception détaillée (voir 7.4.5
et 7.4.6) . 78
– 4 – 61508-3 © CEI:1998
Tableaux Pages
A.5 Conception et développement du logiciel: test et intégration des modules logiciels
(voir 7.4.7 et 7.4.8). 80
A.6 Intégration de l’électronique programmable (matériel et logiciel) (voir 7.5) . 80
A.7 Validation de sécurité du logiciel (voir 7.7). 80
A.8 Modification du logiciel (voir 7.8) . 82
A.9 Vérification du logiciel (voir 7.9). 82
A.10 Evaluation de sécurité fonctionnelle (voir article 8). 84
B.1 Règles de conception et de codage (référencées dans le tableau A.4) . 86
B.2 Analyse dynamique et test (référencés dans les tableaux A.5 et A.9) . 86
B.3 Tests fonctionnel et boîte noire (référencés dans les tableaux A.5 et A.9) . 88
B.4 Analyse de défaillance (référencée dans le tableau A.10) . 88
B.5 Modélisation (référencée dans le tableau A.7) . 88
B.6 Modélisation du fonctionnement (référencé dans les tableaux A.5 et A.6). 90
B.7 Méthodes semi-formelles (référencées dans les tableaux A.1, A.2 et A.4). 90
B.8 Analyse statique (référencée dans le tableau A.9). 90
B.9 Approche modulaire (référencée dans le tableau A.4) . 92
Figures
1 Structure globale de la présente norme . 16
2 Cycle de vie de sécurité d’un E/E/PES (en phase de réalisation). 24
3 Cycle de vie de sécurité du logiciel (en phase de réalisation) . 24
4 Relations entre la CEI 61508-2 et la CEI 61508-3 et leurs domaines
d'application respectifs . 26
5 Intégrité de sécurité du logiciel et cycle de vie de développement (modèle en V). 26
6 Relation entre les architectures matérielle et logicielle pour l’électronique
programmable. 34
– 6 – 61508-3 © CEI:1998
SÉCURITÉ FONCTIONNELLE DES SYSTÈMES
ÉLECTRIQUES/ÉLECTRONIQUES/ÉLECTRONIQUES PROGRAMMABLES
RELATIFS À LA SÉCURITÉ –
Partie 3: Prescriptions concernant les logiciels
AVANT-PROPOS
1) La CEI (Commission Electrotechnique Internationale) est une organisation mondiale de normalisation composée
de l'ensemble des comités électrotechniques nationaux (Comités nationaux de la CEI). La CEI a pour objet de
favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de
l'électricité et de l'électronique. A cet effet, la CEI, entre autres activités, publie des Normes internationales.
Leur élaboration est confiée à des comités d'études, aux travaux desquels tout Comité national intéressé par le
sujet traité peut participer. Les organisations internationales, gouvernementales et non gouvernementales, en
liaison avec la CEI, participent également aux travaux. La CEI collabore étroitement avec l'Organisation
Internationale de Normalisation (ISO), selon des conditions fixées par accord entre les deux organisations.
2) Les décisions ou accords officiels de la CEI concernant les questions techniques représentent, dans la mesure
du possible un accord international sur les sujets étudiés, étant donné que les Comités nationaux intéressés
sont représentés dans chaque comité d’études.
3) Les documents produits se présentent sous la forme de recommandations internationales. Ils sont publiés
comme normes, rapports techniques ou guides et agréés comme tels par les Comités nationaux.
4) Dans le but d'encourager l'unification internationale, les Comités nationaux de la CEI s'engagent à appliquer de
façon transparente, dans toute la mesure possible, les Normes internationales de la CEI dans leurs normes
nationales et régionales. Toute divergence entre la norme de la CEI et la norme nationale ou régionale
correspondante doit être indiquée en termes clairs dans cette dernière.
5) La CEI n’a fixé aucune procédure concernant le marquage comme indication d’approbation et sa responsabilité
n’est pas engagée quand un matériel est déclaré conforme à l’une de ses normes.
6) L’attention est attirée sur le fait que certains des éléments de la présente Norme internationale peuvent faire
l’objet de droits de propriété intellectuelle ou de droits analogues. La CEI ne saurait être tenue pour
responsable de ne pas avoir identifié de tels droits de propriété et de ne pas avoir signalé leur existence.
La Norme internationale CEI 61508-3 a été établie par le sous-comité 65A: Aspects systèmes,
du comité d'études 65 de la CEI: Mesure et commande dans les processus industriels.
Le texte de cette norme est issu des documents suivants:
FDIS Rapport de vote
65A/269/FDIS 65A/277/RVD
Le rapport de vote indiqué dans le tableau ci-dessus donne toute information sur le vote ayant
abouti à l'approbation de cette norme.
Les annexes A et B font partie intégrante de cette norme.
L'annexe C est donnée uniquement à titre d'information.
La CEI 61508 est composée des parties suivantes, regroupées sous le titre général Sécurité
fonctionnelle des systèmes de sécurité électriques/électroniques/électroniques program-
mables:
– Partie 1: Prescriptions générales
– Partie 2: Prescriptions pour les systèmes électriques/électroniques/électroniques program-
mables relatifs à la sécurité
– Partie 3: Prescriptions concernant les logiciels
– Partie 4: Définitions et abréviations
– Partie 5: Exemples de méthodes pour la détermination des niveaux d’intégrité de sécurité
– Partie 6: Lignes directrices pour l’application de la CEI 61508-2 et de la CEI 61508-3
– Partie 7: Présentation de techniques et mesures
Le contenu du corrigendum d'avril 1999 a été pris en considération dans cet exemplaire.
– 8 – 61508-3 © CEI:1998
INTRODUCTION
Les systèmes constitués de composants électriques et/ou électroniques sont utilisés depuis
des années pour exécuter des fonctions liées à la sécurité dans la plupart des secteurs
d'application. Des systèmes à base informatique (généralement désignés par l'appellation:
«Systèmes électroniques programmables (PES)») sont utilisés dans tous les secteurs
d'application pour exécuter des fonctions non liées à la sécurité, mais aussi de plus en plus
souvent liées à la sécurité. Si l'on veut exploiter efficacement, et en toute sécurité, la
technologie des systèmes informatiques, il est indispensable de fournir à tous les responsables
suffisamment d'éléments liés à la sécurité pour les guider dans leurs prises de décisions.
La présente Norme internationale présente une approche générique de toutes les activités
liées au cycle de vie de sécurité concernant les systèmes constitués de composants
électriques et/ou électroniques et/ou électroniques programmables (E/E/PES) destinés à
exécuter des fonctions de sécurité. Cette approche unifiée a été adoptée afin de développer
une politique technique rationnelle et logique concernant tous les appareils électriques liés à la
sécurité. L'un des principaux objectifs poursuivis consiste à faciliter l'élaboration de normes
destinées à chaque secteur d'application.
Dans la plupart des cas, la sécurité est obtenue par un certain nombre de systèmes de
protection fondés sur diverses technologies (par exemple mécanique, hydraulique, pneuma-
tique, électrique, électronique, électronique programmable). En conséquence, il faut que toute
stratégie de sécurité prenne non seulement en compte tous les éléments d'un système
individuel (par exemple les capteurs, les appareils de commande, les actionneurs), mais aussi
qu'elle considère tous les systèmes de sécurité comme des éléments individuels d'un
ensemble complexe. C'est pourquoi cette Norme internationale, bien que traitant essentiel-
lement des E/E/PES, fournit néanmoins un cadre de sécurité susceptible de concerner les
systèmes de sécurité basés sur des technologies différentes.
Personne n'ignore la grande variété des applications E/E/PES. Celles-ci recouvrent, à des
degrés de complexité très divers, un fort potentiel de danger et de risques dans tous les
secteurs d'application. Pour chaque application, la nature exacte des mesures de sécurité
envisagées dépendra de plusieurs facteurs propres à l'application. La présente Norme
internationale, de par son caractère général, rendra désormais possible la prescription de ces
mesures dans des normes internationales spécifiques à chaque secteur d'application.
La présente Norme internationale
– concerne toutes les phases appropriées du cycle de vie de sécurité des E/E/PES et de
leurs logiciels (depuis la conceptualisation initiale jusqu'au déclassement, en passant par la
création, l'installation, la mise en service et l'entretien) lorsque les E/E/PES exécutent des
fonctions de sécurité;
– a été conçue dans le souci de l'évolution rapide des technologies; le cadre est
suffisamment solide et étendu pour pourvoir aux évolutions futures;
– permet l'élaboration de normes internationales par secteur d'application concernant les
E/E/PES relatifs à la sécurité. L'élaboration de normes internationales par secteur
d'application à partir de la présente Norme internationale devrait permettre d'atteindre un
haut niveau de cohérence (par exemple pour ce qui est des principes sous-jacents, de la
terminologie, etc.) à la fois au sein de chaque secteur d'application, et d'un secteur à
l'autre. La conséquence en est une amélioration en termes de sécurité et de bénéfices
économiques;
– fournit une méthode de développement des prescriptions de sécurité nécessaires pour
réaliser la sécurité fonctionnelle des systèmes de sécurité E/E/PE;
– utilise des niveaux d’intégrité de sécurité afin de spécifier les niveaux objectifs d’intégrité
de sécurité des fonctions de sécurité à réaliser par les systèmes de sécurité E/E/PE;
– 10 – 61508-3 © CEI:1998
– adopte une approche basée sur le risque encouru pour déterminer les prescriptions de
niveaux d’intégrité de sécurité;
– fixe des objectifs numériques pour les mesures de défaillances des systèmes de sécurité
E/E/PE qui sont en rapport avec les niveaux d’intégrité de sécurité;
– fixe une limite inférieure pour les mesures de défaillances, dans le cas d’un mode de
défaillance dangereux, cette limite pouvant être exigée pour un système de sécurité E/E/PE
unique. Dans le cas d’un système de sécurité E/E/PE fonctionnant
• dans un mode de fonctionnement faible demande, la limite inférieure est fixée à une
–5
probabilité de défaillance de 10 par heure afin que les fonctions pour lesquelles le
système a été conçu soient exécutées lorsqu’elles sont requises,
• dans un mode de fonctionnement forte demande, ou continu, la limite inférieure est
–9
fixée à une probabilité de défaillance dangereuse de 10 par heure;
NOTE – Un système E/E/PE de sécurité unique ne signifie pas nécessairement architecture à une seule voie.
– adopte une large gamme de principes, techniques et mesures pour la réalisation de la
sécurité fonctionnelle des systèmes de sécurité E/E/PE, mais n’utilise pas le concept de
sécurité intrinsèque qui a un sens particulier lorsque les modes de défaillances sont bien
définis et que le niveau de complexité est relativement faible. Ce concept a été considéré
comme non approprié en raison de l’immense gamme de complexité des systèmes de
sécurité E/E/PE qui entrent dans le domaine d’application de la présente norme.
– 12 – 61508-3 © CEI:1998
SÉCURITÉ FONCTIONNELLE DES SYSTÈMES
ÉLECTRIQUES/ÉLECTRONIQUES/ÉLECTRONIQUES PROGRAMMABLES
RELATIFS À LA SÉCURITÉ –
Partie 3: Prescriptions concernant les logiciels
1 Domaine d'application
1.1 La présente partie de la CEI 61508
a) est prévue pour n'être utilisée qu'après s'être assuré d'une compréhension parfaite de la
CEI 61508-1 et de la CEI 61508-2;
b) s'applique à tout logiciel faisant partie d'un système relatif à la sécurité, ou utilisé pour
développer un système relatif à la sécurité entrant dans le domaine de la CEI 61508-1 et de
la CEI 61508-2. Ce type de logiciel est désigné par le terme «logiciel relatif à la sécurité»;
– Les logiciels relatifs à la sécurité comprennent les systèmes d'exploitation, les logiciels
système, les logiciels des réseaux de communication, les fonctions d'interface homme-
machine, les outils supports et les micrologiciels («firmware»), ainsi que la program-
mation d'applications.
– Les programmes d'applications comprennent les programmes de haut niveau, de bas
niveau et les programmes spécifiques dans des langages de variabilité limitée (voir
3.2.7 de la CEI 61508-4).
c) nécessite que les fonctions de sécurité du logiciel et les niveaux d'intégrité de sécurité du
logiciel soient précisés.
NOTE 1 – Si cela a déjà été réalisé dans le cadre de la spécification des systèmes E/E/PE relatifs à la sécurité
(voir 7.2 de la CEI 61508-2), il n'est pas nécessaire de le répéter dans la présente partie.
NOTE 2 – Spécifier les fonctions de sécurité du logiciel et les niveaux d’intégrité de sécurité du logiciel est une
procédure itérative; voir les figures 2 et 6.
NOTE 3 – Voir l'article 5 et l'annexe A de la CEI 61508-1 pour la structure de la documentation. Cette structure
peut tenir compte des procédures internes de la société et des procédés de travail des secteurs d'application
spécifiques.
d) établit des prescriptions concernant les phases et activités du cycle de vie de sécurité qui
doivent être appliquées durant la conception et développement du logiciel relatif à la
sécurité (modèle de cycle de vie de sécurité du logiciel). Ces prescriptions comprennent
l'application de mesures et de techniques qui suivent une gradation basée sur le niveau
d'intégrité de sécurité, afin d'éviter et de maîtriser les défauts et défaillances du logiciel;
e) fournit les prescriptions pour les informations relatives à la validation de la sécurité du
logiciel et devant être transmises à l'organisation en charge de l'intégration E/E/PES;
f) fournit les prescriptions pour la préparation des informations et procédures concernant le
logiciel requis par l'utilisateur pour le fonctionnement et la maintenance d'un système relatif
à la sécurité;
g) fournit les prescriptions devant être observées par l'organisation en charge des
modifications du logiciel relatif à la sécurité;
h) fournit, en accord avec la CEI 61508-1 et CEI 61508-2, les prescriptions pour les outils
supports tels que les outils de conception et développement, les traducteurs de langage,
les outils de test et de mise au point et les outils de gestion de configuration.
NOTE 4 – Les figures 4 et 6 montrent la relation entre la CEI 61508-2 et la CEI 61508-3.
– 14 – 61508-3 © CEI:1998
1.2 Les parties 1, 2, 3 et 4 de la présente norme sont des publications fondamentales de
sécurité, bien qu'un tel statut ne soit pas applicable dans le contexte des systèmes E/E/PE de
faible complexité relatifs à la sécurité (voir 3.4.4 de la partie 4). En tant que publications
fondamentales de sécurité, ces normes sont prévues pour être utilisées par les comités
techniques pour la préparation des normes selon les principes contenus dans le Guide CEI 104
et le Guide ISO/CEI 51. Les parties 1, 2, 3 et 4 sont également destinées à être utilisées comme
publications autonomes.
Une des responsabilités incombant à un comité technique est, dans la mesure du possible,
d'utiliser les publications fondamentales de sécurité pour la préparation de ses publications.
Dans ce contexte les prescriptions, les méthodes d’essai ou conditions d’essai de cette
publication fondamentale de sécurité ne s’appliquent que si elles sont indiquées
spécifiquement ou incluses dans les publications préparées par ces comités techniques.
NOTE – Aux Etats-Unis d’Amérique et au Canada, les normes nationales de sécurité des processus existantes,
basées sur la CEI 61508 (par exemple l’ANSI/ISA S48.01-1996) peuvent être appliquées dans le domaine des
processus, à la place de la CEI 61508, et cela jusqu’à ce que les normes internationales concernant la mise en
œuvre de la CEI 61508 (soit la CEI 61511) dans le domaine des processus soient publiées.
1.3 La figure 1 montre la structure globale des parties 1 à 7 de la CEI 61508 et indique le rôle
dévolu à la CEI 61508-3 pour assurer la sécurité fonctionnelle des systèmes E/E/PE relatifs à
la sécurité. L'annexe A de la CEI 61508-6 décrit l'application de la CEI 61508-2 et de la
CEI 61508-3.
– 16 – 61508-3 © CEI:1998
Prescriptions
PARTIE 1
techniques
Développement des prescriptions globales
de sécurité (concept, définition du domaine
d’application, analyse de danger et de risque)
PARTIE 5
(Systèmes de sécurité E/E/PE, systèmes
Approches basées sur le
sécurité basés sur d’autres technologies, et
risque pour le développement
dispositifs externes de réduction de risque)
des prescriptions d’intégrité
7.1 à 7.5
de sécurité
Autres
PARTIE 1
prescriptions
Allocation des prescriptions
de sécurité aux systèmes
de sécurité E/E/PE
PARTIE 7
Définitions et
7.6
Bibliographie des abréviations
techniques
et mesures
PARTIE 4
PARTIE 6
Lignes directrices pour
Phase de Documentation
Phase de
la mise en œuvre
réalisation pour
réalisation pour
Article 5 et
des parties 2 et 3
les systèmes de les logiciels
annexe A
sécurité E/E/PE de sécurité
PARTIE 1
PARTIE 2 PARTIE 3
Gestion de la
sécurité fonctionnelle
Article 6
PARTIE 1
PARTIE 1
Installation, mise en service et
validation de la sécurité des
Evaluation de la
systèmes de sécurité E/E/PE
sécurité fonctionnelle
Article 8
7.13 et 7.14
PARTIE 1
PARTIE 1
Exploitation et maintenance,
modification et remise à niveau,
mise hors service ou au rebut des
systèmes de sécurité E/E/PE
7.15 à 7.17
IEC 1 686/98
Figure 1 — Structure globale de la présente norme
– 18 – 61508-3 © CEI:1998
2 Références normatives
Les documents normatifs suivants contiennent des dispositions qui, par suite de la référence
qui y est faite, constituent des dispositions valables pour la présente partie de la CEI 61508.
Au moment de sa publication, les éditions indiquées étaient en vigueur. Tout document
normatif est sujet à révision et les parties prenantes aux accords fondés sur la présente partie
de la CEI 61508 sont invitées à rechercher la possibilité d'appliquer les éditions les plus
récentes des documents normatifs indiqués ci-après. Les membres de la CEI et de l'ISO
possèdent le registre des Normes internationales en vigueur.
CEI 61508-1:1998, Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité – Partie 1: Prescriptions générales
CEI 61508-2, — Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité – Partie 2: Prescriptions pour les systèmes électriques/
1)
électroniques/électroniques programmables relatifs à la sécurité
CEI 61508-4:1998, Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité – Partie 4: Définitions et abréviations
CEI 61508-5:1998, Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité – Partie 5: Exemples de méthodes pour la détermination
des niveaux d'intégrité de sécurité
CEI 61508-6, — Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité – Partie 6: Lignes directrices pour l'application des parties
1)
2 et 3
CEI 61508-7, — Sûreté fonctionnelle des systèmes électriques/électroniques/électroniques
1)
programmables relatifs à la sécurité – Partie 7: Présentation de techniques et mesures
Guide ISO/CEI 51:1990, Principes directeurs pour inclure dans les normes les aspects liés à la
sécurité
Guide CEI 104:1997, Guide pour la rédaction des normes de sécurité et rôle des comités
chargés de fonctions pilotes de sécurité et de fonctions groupées de sécurité
3 Définitions et abréviations
Les définitions et abréviations utilisées dans la présente norme figurent dans la CEI 61508-4.
4 Conformité à la présente norme
Les prescriptions de conformité à la présente norme figurent à l'article 4 de la CEI 61508-1.
5 Documentation
Les objectifs et prescriptions concernant la documentation figurent à l'article 5 de la
CEI 61508-1.
___________
1)
A publier.
– 20 – 61508-3 © CEI:1998
6 Système de gestion de la qualité du logiciel
6.1 Objectifs
Les objectifs sont détaillés en 6.1 de la CEI 61508-1.
6.2 Prescriptions
6.2.1 Les prescriptions comprennent celles qui sont détaillées en 6.2 de la CEI 61508-1 ainsi
que les prescriptions supplémentaires suivantes.
6.2.2 La planification de sécurité fonctionnelle doit définir la stratégie pour l'approvision-
nement, le développement, l'intégration, la vérification, la validation et la modification du
logiciel dans les limites requises par le niveau d'intégrité de sécurité du système E/E/PE relatif
à la sécurité.
NOTE – La philosophie de cette approche est d'utiliser la planification de sécurité fonctionnelle comme une
opportunité d'adapter la présente norme en vue de prendre en compte l'intégrité de sécurité variable requise pour
les composants des systèmes E/E/PE relatifs à la sécurité. Il convient de prendre en compte 7.4.2.8 de la partie 3
lorsque des composants de niveau d'intégrité de sécurité différents doivent être utilisés ensemble dans un système
E/E/PE relatif à la sécurité.
6.2.3 Il convient que la gestion de configuration du logiciel
a) maîtrise administrativement et techniquement, tout au long du cycle de vie de sécurité du
logiciel, la gestion des modifications du logiciel, assurant ainsi la conformité permanente
aux prescriptions de sécurité du logiciel spécifiées;
b) garantisse que toutes les opérations nécessaires ont été effectuées en vue de démontrer
que le niveau d'intégrité requis de sécurité du logiciel a été atteint;
c) maintienne de manière précise et au moyen d'une identification unique tous les éléments
de configuration qui sont nécessaires au maintien de l'intégrité du système E/E/PE relatif à
la sécurité. La configuration comprend au moins les éléments suivants: prescriptions et
analyse de sécurité, documents de conception et de spécification du logiciel, modules de
code source du logiciel, plans de test et résultats, progiciels et composants logiciels
préexistants à incorporer au système E/E/PE relatif à la sécurité et tous les outils et
environnements de développement qui sont utilisés pour créer, tester ou effectuer une
action sur le logiciel du système E/E/PE relatif à la sécurité;
d) applique des procédures de maîtrise des modifications afin d'empêcher toute modification
non autorisée; de documenter les demandes de modification; d'analyser l'impact d’une
modification proposée, et d'approuver ou rejeter la demande de modification; de
documenter les détails et les autorisations pour toutes les modifications approuvées;
d'établir le référentiel de la configuration à des points-clés appropriés lors du dévelop-
pement du logiciel, et de documenter le test d'intégration (partielle) qui justifie le référentiel
(voir 7.8); de garantir la composition et la construction, de tous les référentiels logiciels (y
compris la reconstruction de référentiels précédents);
NOTE 1 – Une autorité de gestion et de décision est nécessaire pour guider et assurer la maîtrise
administrative et technique.
e) documente les informations suivantes afin de permettre un audit ultérieur: état de la
configuration, état des versions, justification et approbation de toutes les modifications, et
détails des modifications;
f) documente de manière formelle la version du logiciel relatif à la sécurité. Il convient
de conserver les copies originales du logiciel et toute la documentation associée afin de
permettre la maintenance de la modification au cours de l’exploitation de la version du
logiciel.
NOTE 2 – Pour tout renseignement complémentaire concernant les processus de gestion de la configuration, voir
ISO/CEI 12207.
– 22 – 61508-3 © CEI:1998
7 Prescriptions concernant le cycle de vie de sécurité du logiciel
7.1 Généralités
7.1.1 Objectif
L'objectif des prescriptions de ce paragraphe est de structurer le développement du logiciel
sous forme de phases et d'activités définies (voir tableau 1 et figures 2 à 5).
7.1.2 Prescriptions
7.1.2.1 Un cycle de vie de sécurité pour le développement du logiciel doit être sélectionné et
spécifié pendant la planification de sécurité conformément à l'article 6 de la CEI 61508-1.
NOTE – Un modèle de cycle de vie de sécurité conforme aux prescriptions de l'article 7 de la CEI 61508-1 peut être
adapté de manière adéquate aux besoins particuliers du projet ou de l'organisation.
7.1.2.2 Les procédures d'assurance qualité et sécurité doivent être intégrées dans les
activités du cycle de vie de sécurité.
7.1.2.3 Chaque phase du cycle de vie de sécurité du logiciel doit être divisée en activités
élémentaires avec le domaine d’application, les entrées et sorties spécifiées pour chaque
phase.
NOTE 1 – Pour tout renseignement complémentaire concernant les phases du cycle de vie, voir ISO/CEI 12207.
NOTE 2 – L'article 5 de la CEI 61508-1 prend en compte les sorties des phases du cycle de vie de sécurité. Durant
le développement de certains systèmes E/E/PE relatifs à la sécurité, la sortie de certaines phases du cycle de vie
de sécurité peut être couverte par un document distinct tandis que les sorties documentées de plusieurs phases
peuvent être fusionnées. La prescription principale est que la sortie de la phase du cycle de vie de sécurité soit
adaptée au but prévu. Pour les développements simples, certaines phases du cycle de vie de sécurité peuvent être
également fusionnées (voir 7.4.5).
7.1.2.4 A condition que le cycle de vie de sécurité du logiciel satisfasse aux prescriptions de
la figure 3 et du tableau 1, il est acceptable d’adapter la profondeur, le nombre et la quantité de
travail des phases du modèle en V (voir figure 5), afin de tenir compte de l’intégrité de sécurité
et de la complexité du projet.
NOTE – La liste complète des phases du cycle de vie fournie dans le tableau 1 convient pour de grands systèmes
nouvellement développés. Pour les petits systèmes, il peut être approprié, par exemple, de fusionner les phases de
conception du système logiciel et de conception d’architecture.
7.1.2.5 Il est acceptable d’ordonner le projet logiciel différemment de l’organisation préco-
nisée dans cette norme (c'est-à-dire d’utiliser un autre modèle de cycle de vie de sécurité) à
condition que tous les objectifs et prescriptions du présent article soient remplis.
7.1.2.6 Pour chaque phase du cycle de vie, des techniques et mesures appropriées doivent
être utilisées. Les annexes A et B (guide pour la sélection de techniques et mesures) donnent
des recommandations. Sélectionner des techniques dans les annexes A et B ne garantit pas,
de ce fait, que l’intégrité de sécurité requise sera atteinte.
7.1.2.7 Les résultats des activités menées dans le cadre du cycle de vie de sécurité du
logiciel doivent être documentés (voir article 5).
7.1.2.8 Si, à un stade quelconque du cycle de vie de sécurité du logiciel, il est nécessaire
d'effectuer une modification portant sur une phase précédente du cycle de vie, cette phase
précédente du cycle de vie de sécurité doit alors être répétée ainsi que les phases suivantes.
– 24 – 61508-3 © CEI:1998
Case 9 de la figure 2
Cycle de vie de sécurité d’un E/E/PES
de la CEI 61508-1
Systèmes liés
9 à la sécurité :
Spécification des prescriptions de
9.1
E/E/PES
sécurité d’un E/E/PES
Spécification des Spécification des
Réalisation
9.1.1 9.1.2
prescriptions
prescriptions
concernant les
concernant l’intégrité
fonctions de
de sécurité
sécurité
Planification de la Conception et
9.2 9.3
validation de sécurité de développement de
l’E/E/PES
l’E/E/PES
Intégration de
Procédures d’exploitation et
9.4
9.5
de maintenance de l’E/E/PES
l’E/E/PES
Validation de
9.6
Un cycle de vie de sécurité de l’E/E/PES
sécurité E/E/PES pour
chaque système
Vers case 14
E/E/PE lié à la sécurité
de la figure 2 de
la CEI 61508-1
Vers case 12 de la figure 2 de la CEI 61508-1
IEC 1 687/98
Figure 2 – Cycle de vie de sécurité d’un E/E/PES (en phase de réalisation)
Cycle de vie de sécurité du logiciel
Spécification des prescriptions
9.1
de sécurité du logiciel
Spécification des
Spécification des
9.1.1 9.1.2
prescriptions sur
prescriptions sur
Cycle de vie
les fonctions de
l’intégrité de
de sécurité de
sécurité
sécurité
l’E/E/PES
(voir figure 2)
Planification de la Conception et
9.2 9.3
validation du logiciel développement du logiciel
Procédures d’exploitation
9.4 Intégration PE
9.5
et de modification de
(matériel/logiciel)
logiciel
Validation de sécurité
9.6
du logiciel
Vers case 14 de
la figure 2 de
Vers case 12 de la figure 2 de la CEI 61508-1
la CEI 61508-1
IEC 1 688/98
Figure 3 – Cycle de vie de sécurité du logiciel (en phase de réalisation)
– 26 – 61508-3 © CEI:1998
Domaine
d’application de
Spécification des
Architecture
la CEI 61508-2
prescriptions de
de l’E/E/PES
sécurité de l’E/E/PES
Prescriptions de sécurité du matériel
Domaine
Prescriptions
Matériel électronique
d’application de Matériel non
de sécurité du
programmable
programmable
la CEI 61508-3
logiciel
Conception et
Conception et
Conception et
développement de développement du
développement
l’électronique
matériel non
du logiciel
programmable
programmable
Intégration de l’électronique
Intégration
programmable (matériel et
E/E/PES
logiciel)
IEC 1 689/98
Figure 4 – Relations entre la CEI 61508-2 et la CEI 61508-3
et leurs domaines d'application respectifs
Spécification des
Spécification des
Validation
Test de
Logiciel
prescriptions prescriptions de
validation
sécurité du validé
de sécurité de
logiciel
l’E/E/PES
Test d’intégration
Architecture de Architecture du
(composants, sous-
l’E/E/PES logiciel
systèmes et électronique
programmable)
Test
Conception de
d’intégration
système logiciel
(module)
Conception Test du
du module module
Sortie
Vérification
CODAGE
IEC 1 690/98
Figure 5 – Intégrité de sécurité du logiciel et cycle de vie de développement (modèle en V)
– 28 – 61508-3 © CEI:1998
Tableau 1 – Cycle de vie de sécurité du logiciel: présentation
Phase du cycle de vie Objectifs Domaine Para- Entrées Sorties
de sécurité d'appli- graphe (informations (informations
cation des pres- requises) produites)
criptions
Numéro Titre
de case
de la
figure 3
9.1 Spécification Spécifier les prescriptions de PES; 7.2.2 Spécification Spécification des
des sécurité du logiciel concernant les des prescrip- prescriptions de
système
prescriptions prescriptions des fonctions de tions de sécurité sécurité du logiciel
logiciel.
de sécurité sécurité du logiciel et les prescrip- des E/E/PES
du logiciel tions d'intégrité de sécurité du (CEI 61508-2)
logiciel;
spécifier les prescriptions des
fonctions de sécurité du logiciel pour
chaque système E/E/PE relatif à la
sécurité nécessaire à l'implémen-
tation des fonctions de sécurité
requises;
spécifier les prescriptions d'intégrité
de sécurité du logiciel pour chaque
système E/E/PE relatif à la sécurité
permettant d'atteindre le niveau
d'intégrité de sécurité spécifié pour
chaque fonction de sécurité qui lui
est attribuée.
9.2 Planification Développer un plan permettant de PES; 7.3.2 Spécification Plan de validation
de la validation valider la sécurité du logiciel. système des prescrip- de sécurité du
de sécurité logiciel. tions de sécurité logiciel
du logiciel du logiciel
9.3 Conception PES; 7.4.3 Spécification Description de la
Architecture:
et dévelop- système des prescrip- conception de
Créer une architecture logicielle
pement logiciel. tions de sécurité l'architecture du
conforme aux prescriptions
du logiciel du logiciel; logiciel;
spécifiées pour la sécurité du logiciel
conception spécification du
par rapport au niveau d'intégrité de
sécurité requis; de l'architecture test d'intégration
du matériel de l'architecture du
passer en revue et évaluer les
E/E/PES logiciel;
prescriptions imposées au logiciel
(CEI 61508-2).
spécification du
par l'architecture matérielle du
test d'intégration
système E/E/PE relatif à la sécurité,
y compris les conséquences des logiciel /
interactions matériel/logiciel sur la électronique
programmable
sécurité de l'équipement commandé.
(identique à celui
requis dans la
CEI 61508-2).
9.3 Conception Outils supports et langages PES; 7.4.4 Spécification Outils de
et dévelop- des prescrip- développement et
de programmation:
système
pement tions de sécurité règles de codage;
logiciel;
Sélectionner un ensemble adéquat
du logiciel du logiciel;
d'outils d'aide à la vérification, sélection des outils
outils
description de de
validation, évaluation et modification,
supports;
la conception développement.
y compris les langages et les
de l'architecture
compilateurs, pour le niveau
langage de
d'intégrité de sécurité requis au du logiciel.
program-
cours du cycle de vie de sécurité
mation.
complet du logiciel.
– 30 – 61508-3 © CEI:1998
Tableau 1 (suite)
Phase du cycle de vie Objectifs Domaine Para- Entrées Sorties
de sécurité d'appli- graphe (informations (informations
cation des pres- requises) produites)
criptions
Numéro Titre
de case
de la
figure 3
9.3 Conception Principaux 7.4.5 Description de Spécification de la
Conception détaillée (conception
et dévelop- du système logiciel): composants la conception de conception du
pement du et sous- l'architecture du logiciel;
Concevoir et implémenter un logiciel
logiciel systèmes de logiciel;
spécification du
qui réponde aux prescriptions
la conception
outils supports test d'intégration
spécifiées pour la sécurité du logiciel
de l'archi-
conformément au niveau d’intégrité et règles de du système
tecture du
codage. logiciel.
de sécurité requis, qui soit
logiciel.
analysable et vérifiable, et qui puisse
être modifiable en toute sécurité.
9.3 Conception Conception détaillée (conception Conception 7.4.5 Spécification de Spécification de la
du logiciel du système la conception du conception du
de module logiciel individuel):
logiciel. système module logiciel;
Concevoir et implémenter un logiciel
logiciel;
qui réponde aux prescriptions spécification du
outils supports test du module
spécifiées pour la sécurité du logiciel
et règles de logiciel.
conformément au niveau d’intégrité
codage.
de sécurité requis, qui soit
analysable et vérifiable, et qui puisse
être modifiable en toute sécurité.
9.3 Conception Implémentation de la conception Modules 7.4.6 Spécification de Listage des codes
et dévelop- logiciels conception du sources;
détaillée:
pement du individuels module logiciel;
rapport de revue
Concevoir et implémenter un logiciel
logiciel
outils supports de code.
qui réponde aux prescriptions
spécifiées pour la sécurité du logiciel et règles de
codage.
conformément au niveau d’intégrité
de sécurité requis, qui soit
analysable et vérifiable, et qui puisse
être modifiable en toute sécurité.
9.3 Conception Modules 7.4.7 Spécification de Résultats des
Test de module logiciel:
et dévelop- logiciels test de module tests de module
Vérifier que les prescriptions pour la
pement du logiciel; logiciel;
sécurité du logiciel (en termes de
logiciel
fonctions de sécurité logicielles listage de code modules logiciels
source; vérifiés et testés.
requises et d’intégrité de sécurité du
logiciel) ont été remplies pour
rapport de revue
montrer que chaque module logiciel
de code.
exécute sa fonction prévue et
n'exécute aucune fonction non
prévue
9.3 Conception Test d'intégration du logiciel: Architecture 7.4.8 Spécification Résultats de test
et dévelop- logicielle; du test d'intégration du
Vérifier que les prescriptions pour la
pement du d'intégration système logiciel;
système
sécurité du logiciel (en termes de
logiciel du système
logiciel système logiciel
fonctions de sécurité logicielles
logiciel.
requises et d’intégrité de sécurité du vérifié et testé.
logiciel) ont été remplies pour
montrer que tous les modules
logiciels, composants et sous-
systèmes interagissent correctement
pour exécuter la fonction prévue et
n'exécutent aucune fonction non
prévue.
– 32 – 61508-3 © CEI:1998
Tabl
...
IEC 61508-3
Edition 1.0 1998-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
BASIC SAFETY PUBLICATION
PUBLICATION FONDAMENTALE DE SÉCURITÉ
Functional safety of electrical/electronic/programmable electronic
safety-related systems –
Part 3: Software requirements
Sécurité fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité –
Partie 3: Prescriptions concernant les logiciels
Copyright © 1998 IEC, Geneva, Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or
IEC's member National Committee in the country of the requester.
If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication,
please contact the address below or your local IEC member National Committee for further information.
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite
ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie
et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur.
Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette
publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence.
IEC Central Office
3, rue de Varembé
CH-1211 Geneva 20
Switzerland
Email: inmail@iec.ch
Web: www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.
About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the
latest edition, a corrigenda or an amendment might have been published.
ƒ Catalogue of IEC publications: www.iec.ch/searchpub
The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…).
It also gives information on projects, withdrawn and replaced publications.
ƒ IEC Just Published: www.iec.ch/online_news/justpub
Stay up to date on all new IEC publications. Just Published details twice a month all new publications released. Available
on-line and also by email.
ƒ Electropedia: www.electropedia.org
The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions
in English and French, with equivalent terms in additional languages. Also known as the International Electrotechnical
Vocabulary online.
ƒ Customer Service Centre: www.iec.ch/webstore/custserv
If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service
Centre FAQ or contact us:
Email: csc@iec.ch
Tel.: +41 22 919 02 11
Fax: +41 22 919 03 00
A propos de la CEI
La Commission Electrotechnique Internationale (CEI) est la première organisation mondiale qui élabore et publie des
normes internationales pour tout ce qui a trait à l'électricité, à l'électronique et aux technologies apparentées.
A propos des publications CEI
Le contenu technique des publications de la CEI est constamment revu. Veuillez vous assurer que vous possédez
l’édition la plus récente, un corrigendum ou amendement peut avoir été publié.
ƒ Catalogue des publications de la CEI: www.iec.ch/searchpub/cur_fut-f.htm
Le Catalogue en-ligne de la CEI vous permet d’effectuer des recherches en utilisant différents critères (numéro de référence,
texte, comité d’études,…). Il donne aussi des informations sur les projets et les publications retirées ou remplacées.
ƒ Just Published CEI: www.iec.ch/online_news/justpub
Restez informé sur les nouvelles publications de la CEI. Just Published détaille deux fois par mois les nouvelles
publications parues. Disponible en-ligne et aussi par email.
ƒ Electropedia: www.electropedia.org
Le premier dictionnaire en ligne au monde de termes électroniques et électriques. Il contient plus de 20 000 termes et
définitions en anglais et en français, ainsi que les termes équivalents dans les langues additionnelles. Egalement appelé
Vocabulaire Electrotechnique International en ligne.
ƒ Service Clients: www.iec.ch/webstore/custserv/custserv_entry-f.htm
Si vous désirez nous donner des commentaires sur cette publication ou si vous avez des questions, visitez le FAQ du
Service clients ou contactez-nous:
Email: csc@iec.ch
Tél.: +41 22 919 02 11
Fax: +41 22 919 03 00
IEC 61508-3
Edition 1.0 1998-12
INTERNATIONAL
STANDARD
NORME
INTERNATIONALE
BASIC SAFETY PUBLICATION
PUBLICATION FONDAMENTALE DE SÉCURITÉ
Functional safety of electrical/electronic/programmable electronic
safety-related systems –
Part 3: Software requirements
Sécurité fonctionnelle des systèmes électriques/électroniques/électroniques
programmables relatifs à la sécurité –
Partie 3: Prescriptions concernant les logiciels
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
COMMISSION
ELECTROTECHNIQUE
PRICE CODE
INTERNATIONALE
X
CODE PRIX
ICS 25.040.40 ISBN 2-8318-4618-8
61508-3 IEC:1998 – 3 –
– 2 – 61508-3 © IEC:1998
CONTENTS
Page
FOREWORD .4
INTRODUCTION .5
Clause
1 Scope.7
2 Normative references.10
3 Definitions and abbreviations .10
4 Conformance to this standard .10
5 Documentation .10
6 Software quality management system .11
6.1 Objectives.11
6.2 Requirements .11
7 Software safety lifecycle requirements .12
7.1 General .12
7.2 Software safety requirements specification.18
7.3 Software safety validation planning .20
7.4 Software design and development.22
7.5 Programmable electronics integration (hardware and software) .28
7.6 Software operation and modification procedures.29
7.7 Software safety validation .29
7.8 Software modification.31
7.9 Software verification .33
8 Functional safety assessment .37
Annex A (normative) Guide to the selection of techniques and measures .38
Annex B (normative) Detailed tables .44
Annex C (informative) Bibliography .48
Tables
1 Software safety lifecycle: overview.15
A.1 Software safety requirements specification (see 7.2).39
A.2 Software design and development: software architecture design (see 7.4.3).39
A.3 Software design and development: support tools and programming language
(see 7.4.4).40
A.4 Software design and development: detailed design (see 7.4.5 and 7.4.6) .40
61508-3 IEC:1998 – 5 –
61508-3 © IEC:1998 – 3 –
Table Page
A.5 Software design and development: software module testing and integration
(see 7.4.7 and 7.4.8) .41
A.6 Programmable electronics integration (hardware and software) (see 7.5) .41
A.7 Software safety validation (see 7.7) .41
A.8 Modification (see 7.8) .42
A.9 Software verification (see 7.9) .42
A.10 Functional safety assessment (see clause 8) .43
B.1 Design and coding standards (referenced by table A.4).44
B.2 Dynamic analysis and testing (referenced by tables A.5 and A.9) .44
B.3 Functional and black-box testing (referenced by tables A.5, A.6 and A.7) .45
B.4 Failure analysis (referenced by table A.10) .45
B.5 Modelling (referenced by table A.7).45
B.6 Performance testing (referenced by tables A.5 and A.6) .46
B.7 Semi-formal methods (referenced by tables A.1, A.2 and A.4) .46
B.8 Static analysis (referenced by table A.9) .46
B.9 Modular approach (referenced by table A.4).47
Figures
1 Overall framework of this standard.9
2 E/E/PES safety lifecycle (in realisation phase) .13
3 Software safety lifecycle (in realisation phase) .13
4 Relationship between and scope of IEC 61508-2 and 61508-3 .14
5 Software safety integrity and the development lifecycle (the V-model) .14
6 Relationship between the hardware and software architectures of programmable
electronics.18
61508-3 IEC:1998 – 7 –
– 4 – 61508-3 © IEC:1998
FUNCTIONAL SAFETY OF
ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC
SAFETY-RELATED SYSTEMS –
Part 3: Software requirements
FOREWORD
1) The IEC (International Electrotechnical Commission) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of the IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, the IEC publishes International Standards. Their preparation is
entrusted to technical committees; any IEC National Committee interested in the subject dealt with may
participate in this preparatory work. International, governmental and non-governmental organizations liaising
with the IEC also participate in this preparation. The IEC collaborates closely with the International Organization
for Standardization (ISO) in accordance with conditions determined by agreement between the two
organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are published in the form
of standards, technical reports or guides and they are accepted by the National Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC International
Standards transparently to the maximum extent possible in their national and regional standards. Any
divergence between the IEC Standard and the corresponding national or regional standard shall be clearly
indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject
of patent rights. The IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 61508-3 has been prepared by subcommittee 65A: System aspects,
of IEC technical committee 65: Industrial-process measurement and control.
The text of this standard is based on the following documents:
FDIS Report on voting
65A/269/FDIS 65A/277/RVD
Full information on the voting for the approval of this standard can be found in the voting report
indicated in the above table.
Annexes A and B form an integral part of this standard.
Annex C is for information only.
IEC 61508 consists of the following parts, under the general title Functional safety of electrical/
electronic/programmable electronic safety-related systems:
– Part 1: General requirements
– Part 2: Requirements for electrical/electronic/programmable electronic safety-related systems
– Part 3: Software requirements
– Part 4: Definitions and abbreviations
– Part 5: Examples of methods for the determination of safety integrity levels
– Part 6: Guidelines on the application of IEC 61508-2 and IEC 61508-3
– Part 7: Overview of techniques and measures
The contents of the corrigendum of April 1999 have been included in this copy.
61508-3 IEC:1998 – 9 –
61508-3 © IEC:1998 – 5 –
INTRODUCTION
Systems comprised of electrical and/or electronic components have been used for many years
to perform safety functions in most application sectors. Computer-based systems (generically
referred to as programmable electronic systems (PESs)) are being used in all application
sectors to perform non-safety functions and, increasingly, to perform safety functions. If
computer system technology is to be effectively and safely exploited, it is essential that those
responsible for making decisions have sufficient guidance on the safety aspects on which to
make those decisions.
This International Standard sets out a generic approach for all safety lifecycle activities for
systems comprised of electrical and/or electronic and/or programmable electronic components
(electrical/electronic/ programmable electronic systems (E/E/PESs)) that are used to perform
safety functions. This unified approach has been adopted in order that a rational and consistent
technical policy be developed for all electrically-based safety-related systems. A major
objective is to facilitate the development of application sector standards.
In most situations, safety is achieved by a number of protective systems which rely on many
technologies (for example mechanical, hydraulic, pneumatic, electrical, electronic,
programmable electronic). Any safety strategy must therefore consider not only all the
elements within an individual system (for example sensors, controlling devices and actuators),
but also all the safety-related systems making up the total combination of safety-related
systems. Therefore, while this International Standard is concerned with electrical/electronic/
programmable electronic (E/E/PE) safety-related systems, it may also provide a framework
within which safety-related systems based on other technologies may be considered.
It is recognized that there is a great variety of E/E/PES applications in a variety of application
sectors and covering a wide range of complexity, hazard and risk potentials. In any particular
application, the required safety measures will be dependent on many factors specific to the
application. This International Standard, by being generic, will enable such measures to be
formulated in future application sector international standards.
This International Standard
– considers all relevant overall, E/E/PES and software safety lifecycle phases (for example,
from initial concept, through design, implementation, operation and maintenance to
decommissioning) when E/E/PESs are used to perform safety functions;
– has been conceived with a rapidly developing technology in mind; the framework is
sufficiently robust and comprehensive to cater for future developments;
– enables application sector international standards, dealing with safety-related E/E/PESs, to
be developed; the development of application sector international standards, within the
framework of this International Standard, should lead to a high level of consistency (for
example, of underlying principles, terminology etc.) both within application sectors and
across application sectors; this will have both safety and economic benefits;
– provides a method for the development of the safety requirements specification necessary
to achieve the required functional safety for E/E/PE safety-related systems;
– uses safety integrity levels for specifying the target level of safety integrity for the safety
functions to be implemented by the E/E/PE safety-related systems;
61508-3 IEC:1998 – 11 –
– 6 – 61508-3 © IEC:1998
– adopts a risk-based approach for the determination of the safety integrity level
requirements;
– sets numerical target failure measures for E/E/PE safety-related systems which are linked
to the safety integrity levels;
– sets a lower limit on the target failure measures, in a dangerous mode of failure, that can
be claimed for a single E/E/PE safety-related system; for E/E/PE safety-related systems
operating in
• a low demand mode of operation, the lower limit is set at an average probability of
–5
failure of 10 to perform its design function on demand,
• a high demand or continuous mode of operation, the lower limit is set at a probability of
–9
a dangerous failure of 10 per hour;
NOTE – A single E/E/PE safety-related system does not necessarily mean a single-channel architecture.
– adopts a broad range of principles, techniques and measures to achieve functional safety
for E/E/PE safety-related systems, but does not use the concept of fail safe, which may be
of value when the failure modes are well defined and the level of complexity is relatively
low. The concept of fail safe was considered inappropriate because of the full range of
complexity of E/E/PE safety-related systems that are within the scope of the standard.
61508-3 IEC:1998 – 13 –
61508-3 © IEC:1998 – 7 –
FUNCTIONAL SAFETY OF
ELECTRICAL/ELECTRONIC/PROGRAMMABLE ELECTRONIC
SAFETY-RELATED SYSTEMS –
Part 3: Software requirements
1 Scope
1.1 This part of IEC 61508
a) is intended to be utilised only after a thorough understanding of IEC 61508-1 and
IEC 61508-2;
b) applies to any software forming part of a safety-related system or used to develop a safety-
related system within the scope of IEC 61508-1 and IEC 61508-2. Such software is termed
safety-related software.
– Safety-related software includes operating systems, system software, software in
communication networks, human-computer interface functions, support tools and
firmware as well as application programs.
– Application programs include high level programs, low level programs and special
purpose programs in limited variability languages (see 3.2.7 of IEC 61508-4).
c) requires that the software safety functions and software safety integrity levels are specified.
NOTE 1 – If this has already been done as part of the specification of the E/E/PE safety-related systems (see
7.2 of IEC 61508-2), then it does not have to be repeated in this part.
NOTE 2 – Specifying the software safety functions and software safety integrity levels is an iterative procedure;
see figures 2 and 6.
NOTE 3 – See clause 5 and annex A of IEC 61508-1 for documentation structure. The documentation structure
may take account of company procedures, and of the working practices of specific application sectors.
d) establishes requirements for safety lifecycle phases and activities which shall be applied
during the design and development of the safety-related software (the software safety
lifecycle model). These requirements include the application of measures and techniques,
which are graded against the safety integrity level, for the avoidance of and control of faults
and failures in the software.
e) provides requirements for information relating to the software safety validation to be passed
to the organisation carrying out the E/E/PES integration.
f) provides requirements for the preparation of information and procedures concerning
software needed by the user for the operation and maintenance of the E/E/PE safety-
related system.
g) provides requirements to be met by the organisation carrying out modifications to safety-
related software.
h) provides, in conjunction with IEC 61508-1 and IEC 61508-2, requirements for support tools
such as development and design tools, language translators, testing and debugging tools,
configuration management tools.
NOTE 4 – Figures 4 and 6 show the relationship between IEC 61508-2 and IEC 61508-3.
61508-3 IEC:1998 – 15 –
– 8 – 61508-3 © IEC:1998
1.2 Parts 1, 2, 3 and 4 of this standard are basic safety publications, although this status
does not apply in the context of low complexity E/E/PE safety-related systems (see 3.4.4 of
part 4). As basic safety publications, they are intended for use by technical committees in the
preparation of standards in accordance with the principles contained in IEC Guide 104 and
ISO/IEC Guide 51. Parts 1, 2, 3, and 4 are also intended for use as stand-alone publications.
One of the responsibilities of a technical committee is, wherever applicable, to make use of
basic safety publications in the preparation of its publications. In this context, the requirements,
test methods or test conditions of this basic safety publication will not apply unless specifically
referred to or included in the publications prepared by those technical committees.
NOTE – In the USA and Canada, until the proposed process sector implementation of IEC 61508 (i.e. IEC 61511) is
published as an international standard in the USA and Canada, existing national process safety standards based on
IEC 61508 (i.e. ANSI/ISA S84.01-1996) can be applied to the process sector instead of IEC 61508.
1.3 Figure 1 shows the overall framework of parts 1 to 7 IEC 61508, and indicates the role
that IEC 61508-3 plays in the achievement of functional safety for E/E/PE safety-related
systems. Annex A of IEC 61508-6 describes the application of IEC 61508-2 and IEC 61508-3.
61508-3 IEC:1998 – 17 –
61508-3 © IEC:1998 – 9 –
Technical
requirements
PART 1
Development of the overall safety
requirements (concept, scope
definition, hazard and risk analysis)
(E/E/PE safety-related systems, other
PART 5
technology safety-related systems and
Risk based approaches
external risk reduction facilities)
to the development of
7.1 to 7.5
the safety integrity
requirements
Other
PART 1
requirements
Allocation of the safety
requirements to the E/E/PE
safety-related systems
Definitions and
PART 7
7.6
abbreviations
Overview of
techniques
and measures
PART 4
PART 6
Guidelines for the
Documentation
Realisation Realisation
application of
phase for phase for
parts 2 and 3 Clause 5 and
E/E/PE safety- safety-related
annex A
related systems software
PART 1
PART 2
PART 3
Management of
functional safety
Clause 6
PART 1
PART 1
Installation and commissioning
and safety validation of E/E/PE
Functional safety
safety-related systems
assessment
Clause 8
7.13 and 7.14
PART 1
PART 1
Operation and maintenance,
modification and retrofit,
decommissioning or disposal of
E/E/PE safety-related systems
7.15 to 7.17
IEC 1 686/98
Figure 1 – Overall framework of this standard
61508-3 IEC:1998 – 19 –
– 10 – 61508-3 © IEC:1998
2 Normative references
The following normative documents contain provisions which, through reference in this text,
constitute provisions of this part of IEC 61508. At the time of publication, the editions indicated
were valid. All normative documents are subject to revision, and parties to agreements based
on this part of IEC 61508 are encouraged to investigate the possibility of applying the most
recent editions of the normative documents indicated below. Members of IEC and ISO maintain
registers of currently valid International Standards.
Functional safety of electrical/electronical/programmable electronic safety-
IEC 61508-1:1998,
related systems – Part 1: General requirements
IEC 61508-2, — Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 2: Requirements for electrical/electronical/programmable electronic
1)
safety-related systems
IEC 61508-4:1998, Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 4: Definitions and abbreviations of terms
IEC 61508-5:1998, Functional safety of electrical/electronical/programmable electronic safety-
related systems – Part 5: Examples of methods for the determination of safety integrity levels
IEC 61508-6: —, Functional safety of electrical/electronical/programmable electronic safety-
1)
related systems – Part 6: Guidelines on the application of parts 2 and 3
IEC 61508-7: —, Functional safety of electrical/electronical/programmable electronic safety-
1)
related systems – Part 7: Overview of techniques and measures
ISO/IEC Guide 51:1990, Guidelines for the inclusion of safety aspects in standards
IEC Guide 104:1997, Guide to the drafting of safety standards, and the role of Committees with
safety pilot functions and safety group functions
3 Definitions and abbreviations
For the purposes of this standard, the definitions and abbreviations given in IEC 61508-4 apply.
4 Conformance to this standard
The requirements for conformance to this standard are given in clause 4 of IEC 61508-1.
5 Documentation
The objectives and requirements for documentation are given in clause 5 of IEC 61508-1.
___________
1)
To be published.
61508-3 IEC:1998 – 21 –
61508-3 © IEC:1998 – 11 –
6 Software quality management system
6.1 Objectives
The objectives are as detailed in 6.1 of IEC 61508-1.
6.2 Requirements
6.2.1 The requirements are as detailed in 6.2 of IEC 61508-1 with the following additional
requirements.
6.2.2 The functional safety planning shall define the strategy for the software procurement,
development, integration, verification, validation and modification to the extent required by the
safety integrity level of the E/E/PE safety related system.
NOTE – The philosophy of this approach is to use the functional safety planning as an opportunity to customise this
standard to take account of the varying safety integrity which is required in the E/E/PE safety-related system
components. 7.4.2.8 of part 3 should be taken into account when E/E/PE safety-related system components of
differing safety integrity levels are to be used together.
6.2.3 Software configuration management should
a) apply administrative and technical controls throughout the software safety lifecycle, in order
to manage software changes and thus ensure that the specified requirements for software
safety continue to be satisfied;
b) guarantee that all necessary operations have been carried out to demonstrate that the
required software safety integrity has been achieved;
c) maintain accurately and with unique identification all configuration items which are
necessary to maintain the integrity of the E/E/PE safety-related system. Configuration items
include at least the following: safety analysis and requirements; software specification and
design documents; software source code modules; test plans and results; pre-existing
software components and packages which are to be incorporated into the E/E/PE safety-
related system; all tools and development environments which are used to create or test, or
carry out any action on, the software of the E/E/PE safety-related system;
d) apply change-control procedures to prevent unauthorized modifications; to document
modification requests; to analyse the impact of a proposed modification, and to approve or
reject the request; to document the details of, and the authorisation for, all approved
modifications; to establish configuration baseline at appropriate points in the software
development, and to document the (partial) integration testing which justifies the baseline
(see 7.8); to guarantee the composition of, and the building of, all software baselines
(including the rebuilding of earlier baselines);
NOTE 1 – Management decision and authority is needed to guide and enforce the use of administrative and
technical controls.
e) document the following information to permit a subsequent audit: configuration status,
release status, the justification for and approval of all modifications, and the details of the
modification;
f) formally document the release of safety-related software. Master copies of the software and
all associated documentation should be kept to permit maintenance and modification
throughout the operational lifetime of the released software.
NOTE 2 – For further information on configuration management, see ISO/IEC 12207.
61508-3 IEC:1998 – 23 –
– 12 – 61508-3 © IEC:1998
7 Software safety lifecycle requirements
7.1 General
7.1.1 Objective
The objective of the requirements of this subclause is to structure the development of the
software into defined phases and activities (see table 1 and figures 2 to 5).
7.1.2 Requirements
7.1.2.1 A safety lifecycle for the development of software shall be selected and specified
during safety planning in accordance with clause 6 of IEC 61508-1.
NOTE – A safety lifecycle model which satisfies the requirements of clause 7 of IEC 61508-1 may be suitably
customised for the particular needs of the project or organisation.
7.1.2.2 Quality and safety assurance procedures shall be integrated into safety lifecycle
activities.
7.1.2.3 Each phase of the software safety lifecycle shall be divided into elementary activities
with the scope, inputs and outputs specified for each phase.
NOTE 1 – For further information on lifecycle phases, see ISO/IEC 12207.
NOTE 2 – Clause 5 of IEC 61508-1 considers the outputs from the safety lifecycle phases. In the development of
some E/E/PE safety-related systems, the output from some safety lifecycle phases may be a distinct document,
while the documented outputs from several phases may be merged. The essential requirement is that the output of
the safety lifecycle phase be fit for its intended purpose. In simple developments, some safety lifecycle phases may
also be merged (see 7.4.5).
7.1.2.4 Provided that the software safety lifecycle satisfies the requirements of figure 3 and
table 1, it is acceptable to tailor the depth, number and work-size of the phases of the V-model
(see figure 5) to take account of the safety integrity and the complexity of the project.
NOTE – The full list of lifecycle phases in table 1 is suitable for large newly developed systems. In small systems, it
might be appropriate, for example, to merge the phases of software system design and architectural design.
7.1.2.5 It is acceptable to order the software project differently from the organization of this
standard (i.e. use another software safety lifecycle model), provided all the objectives and
requirements of this clause are met.
7.1.2.6 For each lifecycle phase, appropriate techniques and measures shall be used.
Annexes A and B (guide to the selection of techniques and measures) give recommendations.
Selecting techniques from annexes A and B does not guarantee by itself that the required
safety integrity will be achieved.
7.1.2.7 The results of the activities in the software safety lifecycle shall be documented (see
clause 5).
7.1.2.8 If at any stage of the software safety lifecycle, a change is required pertaining to an
earlier lifecycle phase, then that earlier safety lifecycle phase and the following phases shall be
repeated.
61508-3 IEC:1998 – 25 –
61508-3 © IEC:1998 – 13 –
Box 9 in figure 2
of IEC 61508-1 E/E/PES safety lifecycle
Safety-related
systems:
9.1 E/E/PES safety requirements
E/E/PES
specification
Safety functions Safety integrity
Realisation
9.1.1 9.1.2
requirements requirements
specification
specification
E/E/PES safety E/E/PES design
9.3
9.2
and development
validation planning
E/E/PES
E/E/PES operation and
9.4
9.5
integration maintenance procedures
E/E/PES safety
9.6
validation
One E/E/PES safety
lifecycle for each
To box 14
E/E/PE safety-related
in figure 2
system
of IEC 61508-1
To box 12 in figure 2 of IEC 61508-1
IEC 1 687/98
Figure 2 – E/E/PES safety lifecycle (in realisation phase)
Software safety lifecycle
Software safety requirements
9.1
specification
Safety functions Safety integrity
9.1.1
9.1.2
requirements requirements
specification specification
E/E/PES
safety
lifecycle
(see figure 2)
Software design
Software safety
9.2 9.3
and development
validation planning
PE integration Software operation and
9.4 9.5
(hardware/software) modification procedures
Software safety
9.6
validation
To box 14
in figure 2
To box 12 in figure 2 of IEC 61508-1
of IEC 61508-1
IEC 1 688/98
Figure 3 – Software safety lifecycle (in realisation phase)
61508-3 IEC:1998 – 27 –
– 14 – 61508-3 © IEC:1998
Scope of
IEC 61508-2
E/E/PES safety
E/E/PES
requirements
architecture
specification
Hardware safety requirements
Scope of Non-programmable
Programmable
Software safety
hardware
electronic hardware
IEC 61508-3 requirements
Programmable Non-programmable
Software design
electronics design hardware design
and development
and development
and development
Programmable electronics
E/E/PES
integration (hardware and
integration
software)
IEC 1 689/98
Figure 4 – Relationship between and scope of IEC 6158-2 and IEC 61508-3
E/E/PES safety Software safety Validation
Validation
Validated
requirements requirements
testing
software
specification specification
Integration testing
E/E/PES Software
(components, subsystems
architecture architecture
and programmable
electronics)
Integration
Software system
testing
design
(module)
Module Module
design testing
Output
Verification
CODING
IEC 1 690/98
Figure 5 – Software safety integrity and the development lifecycle (the V-model)
61508-3 IEC:1998 – 29 –
61508-3 © IEC:1998 – 15 –
Table 1 – Software safety lifecycle: overview
Inputs
Safety lifecycle Objectives Scope Require- Outputs
(information
phase ments (information
required)
subclause produced)
Figure 3 Title
box
number
9.1 Software safety To specify the requirements for PES; 7.2.2 E/E/PES Software safety
requirements software safety in terms of the Software safety requirements
specification requirements for software safety system. requirements specification.
functions and the requirements for specification
software safety integrity; (IEC 61508-2).
To specify the requirements for the
software safety functions for each
E/E/PE safety-related system
necessary to implement the required
safety functions;
To specify the requirements for
software safety integrity for each
E/E/PE safety-related system
necessary to achieve the safety
integrity level specified for each
safety function allocated to that
E/E/PE safety-related system.
9.2 Software safety To develop a plan for validating PES; 7.3.2 Software Software safety
validation the software safety. software safety validation plan.
planning system. requirements
specification.
9.3 Software design Architecture: PES; 7.4.3 Software Software
and software safety architecture design
To create a software architecture
development system. requirements description;
that fulfils the specified requirements
specification;
software
for software safety with respect to
the required safety integrity level; E/E/PES architecture
hardware integration test
To review and evaluate the
architecture specification;
requirements placed on the software
design (from
software/
by the hardware architecture of the
IEC 61508-2).
E/E/PE safety-related system, programmable
including the significance of E/E/PE electronics
hardware/software interactions for integration test
specification (the
safety of the equipment under
same as
control.
IEC 61508-2
requires).
9.3 Software Support tools and programming PES; 7.4.4 Software Development tools
design and safety and coding
languages:
development software requirements standards;
To select a suitable set of tools,
system; specification;
including languages and compilers, selection of
software development tools.
for the required safety integrity level,
support
architecture
over the whole safety lifecycle of the
tools;
design
software which assists verification,
validation, assessment and description.
program-
modification.
ming
language.
61508-3 IEC:1998 – 31 –
– 16 – 61508-3 © IEC:1998
Table 1 (continued)
Safety lifecycle Objectives Scope Require- Inputs Outputs
phase ments (information (information
subclause required) produced)
Figure 3 Title
box
number
9.3 Software Major 7.4.5 Software Software system
Detailed design and development
design and components architecture design
(software system design):
development and design specification;
To design and implement software
subsystems description;
software system
that fulfils the specified requirements
of software
support tools integration test
for software safety with respect to
architectural
and coding specification.
the required safety integrity level,
design.
which is analysable and verifiable, standards.
and which is capable of being safely
modified.
9.3 Software Detailed design and development Software 7.4.5 Software Software module
design and system system design design
(individual software module
development design. specification; specification;
design):
support tools software module
To design and implement software
and coding test specification.
that fulfils the specified requirements
standards.
for software safety with respect to
the required safety integrity level,
which is analysable and verifiable,
and which is capable of being safely
modified.
9.3 Software Detailed code implementation: Individual 7.4.6 Software Source code
design and software module design listing;
To design and implement software
development modules. specification;
code review report.
that fulfils the specified requirements
for software safety with respect to support tools
the required safety integrity level, and coding
standards.
which is analysable and verifiable,
and which is capable of being safely
modified.
9.3 Software Software module testing: Software 7.4.7 Software Software module
design and modules. module test test results;
To verify that the requirements for
development specification;
verified and tested
software safety (in terms of the
required software safety functions source code software modules.
and the software safety integrity) listing;
have been achieved – to show that
code review
each software module performs its
report.
intended function and does not
perform unintended functions.
9.3 Software Software 7.4.8 Software Software system
Software integration testing:
design and architecture; system integration test
To verify that the requirements for
development integration test results;
software safety (in terms of the software
specification.
required software safety functions system. verified and tested
software system.
and the software safety integrity)
have been achieved – to show that
all software modules, components
and subsystems interact correctly to
perform their intended function and
do not perform unintended functions.
61508-3 IEC:1998 – 33 –
61508-3 © IEC:1998 – 17 –
Table 1 (concluded)
Inputs
Safety lifecycle Objectives Scope Require- Outputs
(information
phase ments (information
required)
subclause produced)
Figure 3 Title
box
number
9.4 Programmable To integrate the software onto the Program- 7.5.2 Software Software
electronics target programmable electronic mable architecture architecture
integration hardware; electronics integration test integration test
hardware; specification; results;
(hardware and To combine the software and
software) hardware in the safety-related integrated programmable programmable
programmable electronics to software. electronics electronics
ensure their compatibility and to integration test integration test
meet the requirements of the specification results;
intended safety integrity level. (the same as
verified and tested
IEC 61508-2
integrated
requires);
programmable
integrated electronics.
programmable
electronics.
9.5 Software To provide information and As above 7.6.2 All above, as Software operation
operation and procedures concerning software relevant. and modification
modification necessary to ensure that the procedures.
procedures functional safety of the E/E/PE
safety-related system is maintained
during operation and modification.
9.6 Software safety To ensure that the integrated As above 7.7.2 Software Software safety
validation system complies with the specified safety validation results;
requirements for software safety at validation
Validated
the intended safety integrity level. plan.
software.
– Software To make corrections, As above 7.8.2 Software Software
modification enhancements or adaptations to modification modification
the validated software, ensuring procedures; impact analysis
that the required software safety results;
software
integrity level is sustained.
modification software
request. modification log.
– Software To the extent required by the Depends on 7.9.2 Appropriate Appropriate
verification safety integrity level, to test and phase verification verification report
evaluate the outputs from a given plan (depends (depends
software safety lifecycle phase to on phase). on phase).
ensure correctness and consis-
tency with respect to the outputs
and standards provided as input to
that phase.
– Software To investigate and arrive at a All above 8 Software Software
functional judgement on the functional safety phases functional functional safety
safety achieved by the E/E/PE safety- safety assessment
assessment related systems. assessment report.
plan.
61508-3 IEC:1998 – 35 –
– 18 – 61508-3 © IEC:1998
7.2 Software safety r
...












Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...