EN 62138:2009

SLOVENSKI STANDARD
01-november-2009
1XNOHDUQHHOHNWUDUQH0HULOQDLQQDG]RUQDRSUHPD]D]DJRWDYOMHQMHYDUQRVWL
=QDþLOQRVWLSURJUDPVNHRSUHPHUDþXQDOQLãNLKVLVWHPRYNLL]YDMDMRNDWHJRULML
IXQNFLM%DOL&,(&
Nuclear power plants - Instrumentation and control important for safety - Software
aspects for computer-based systems performing category B or C functions
Kernkraftwerke - Leittechnik für Systeme mit sicherheitstechnischer Bedeutung -
Softwareaspekte für rechnerbasierte Systeme zur Realisierung von Funktionen der
Kategorie B oder C
Centrales nucléaires - Instrumentation et contrôle commande importants pour la sûreté -
Aspects logiciels des systèmes informatisés réalisant des fonctions de catégorie B ou C
Ta slovenski standard je istoveten z: EN 62138:2009
ICS:
27.120.20 Jedrske elektrarne. Varnost Nuclear power plants. Safety
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 62138
NORME EUROPÉENNE
August 2009
EUROPÄISCHE NORM
ICS 27.120.20
English version
Nuclear power plants -
Instrumentation and control important for safety -
Software aspects for computer-based systems
performing category B or C functions
(IEC 62138:2004)
Centrales nucléaires -  Kernkraftwerke -
Instrumentation et contrôle-commande Leittechnik für Systeme
importants pour la sûreté - mit sicherheitstechnischer Bedeutung -
Aspects logiciels des systèmes Softwareaspekte für rechnerbasierte
informatisés réalisant des fonctions Systeme zur Realisierung von Funktionen
de catégorie B ou C der Kategorie B oder C
(CEI 62138:2004) (IEC 62138:2004)

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

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

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

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

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

Central Secretariat: Avenue Marnix 17, B - 1000 Brussels

© 2009 CENELEC - All rights of exploitation in any form and by any means reserved worldwide for CENELEC members.
Ref. No. EN 62138:2009 E
Foreword
The text of the International Standard IEC 62138:2004, prepared by SC 45A, Instrumentation and
control of nuclear facilities, of IEC TC 45, Nuclear instrumentation, was submitted to the formal vote
and was approved by CENELEC as EN 62138 on 2009-07-01 without any modification.
The following dates were fixed:

– latest date by which the EN has to be implemented
at national level by publication of an identical
national standard or by endorsement (dop) 2010-07-01

– latest date by which the national standards conflicting
with the EN have to be withdrawn (dow) 2012-07-01
Annex ZA has been added by CENELEC.
__________
Endorsement notice
The text of the International Standard IEC 62138:2004 was approved by CENELEC as a European
Standard without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 61508-3 NOTE  Harmonized as EN 61508-3:2001 (not modified).
IEC 61508-4 NOTE  Harmonized as EN 61508-4:2001 (not modified).
IEC 61511-1 NOTE  Harmonized as EN 61511-1:2004 (not modified).
ISO 9000-3 NOTE  Harmonized as EN ISO 9000-3:1997 (not modified).
ISO 9001 NOTE  Harmonized as EN ISO 9001:2008 (not modified).
__________
- 3 - EN 62138:2009
Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications

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

NOTE  When an international publication has been modified by common modifications, indicated by (mod), the relevant EN/HD
applies.
Publication Year Title EN/HD Year
1)
IEC 61226 - Nuclear power plants - Instrumentation - -
and control systems important to safety -
Classification of instrumentation and
control functions
IEC 61513 2001 Nuclear power plants - Instrumentation - -
and control for systems important to
safety - General requirements for systems

1)
Undated reference.
NORME CEI
INTERNATIONALE
IEC
INTERNATIONAL
Première édition
STANDARD
First edition
2004-01
Centrales nucléaires –
Instrumentation et contrôle-commande
importants pour la sûreté –
Aspects logiciels des systèmes informatisés
réalisant des fonctions de catégorie B ou C

Nuclear power plants –
Instrumentation and control important for safety –
Software aspects for computer-based systems
performing category B or C functions
 IEC 2004 Droits de reproduction réservés  Copyright - all rights reserved
Aucune partie de cette publication ne peut être reproduite ni No part of this publication may be reproduced or utilized in any
utilisée sous quelque forme que ce soit et par aucun procédé, form or by any means, electronic or mechanical, including
électronique ou mécanique, y compris la photocopie et les photocopying and microfilm, without permission in writing from
microfilms, sans l'accord écrit de l'éditeur. 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
CODE PRIX
X
PRICE CODE
Commission Electrotechnique Internationale
International Electrotechnical Commission
МеждународнаяЭлектротехническаяКомиссия
Pour prix, voir catalogue en vigueur
For price, see current catalogue

62138  IEC:2004 – 3 –
CONTENTS
FOREWORD.5
INTRODUCTION.9

1 Scope.11
2 Normative references.11
3 Terms, definitions and abbreviations .13
4 Key concepts and assumptions.23
4.1 Types of software.23
4.2 Types of data.25
4.3 Software and System Safety Lifecycles .25
4.4 Gradation principles.31
5 Requirements for the software of I&C systems performing category C functions .35
5.1 General requirements.35
5.2 Selection of pre-developed software.43
5.3 Software requirements specification .45
5.4 Software design.49
5.5 Implementation of new software .51
5.6 Software aspects of system integration .53
5.7 Software aspects of system validation .53
5.8 Installation of software on site .55
5.9 Anomaly reports.55
5.10 Software modification.55
6 Requirements for the software of I&C systems performing category B functions .57
6.1 General requirements.57
6.2 Selection of pre-developed software.65
6.3 Software requirements specification .75
6.4 Software design.79
6.5 Implementation of new software .83
6.6 Software aspects of system integration .87
6.7 Software aspects of system validation .87
6.8 Installation of software on site .89
6.9 Anomaly reports.91
6.10 Software modification.91

Bibliography.95

Figure 1 – Typical software parts in computer-based I&C systems.23
Figure 2 – Activities of the System Safety Lifecycle (as defined by IEC 61513).25
Figure 3 – Software related activities in the System Safety Lifecycle .27
Figure 4 – Development activities of the IEC 62138 Software Safety Lifecycle.29
Figure 5 – Process for providing evidence of correctness for pre-developed software of
an I&C system of safety class 2. .31

62138  IEC:2004 – 5 –
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
NUCLEAR POWER PLANTS –
INSTRUMENTATION AND CONTROL IMPORTANT FOR SAFETY –
SOFTWARE ASPECTS FOR COMPUTER-BASED SYSTEMS
PERFORMING CATEGORY B OR C FUNCTIONS

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of 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, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC
Publication(s)”). 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. 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 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 IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC 62138 has been prepared by subcommittee 45A: Instrumentation
and control of nuclear facilities, of IEC technical committee 45: Nuclear instrumentation.
The text of this standard is based on the following documents:
FDIS Report on voting
45A/507/FDIS 45A/521/RVD
Full information on the voting for the approval of this standard can be found in the report on
voting indicated in the above table.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

62138  IEC:2004 – 7 –
The committee has decided that the contents of this publication will remain unchanged until
2009. At this date, the publication will be:
• reconfirmed;
• withdrawn;
• replaced by a revised edition, or
• amended.
62138  IEC:2004 – 9 –
INTRODUCTION
Structure of the SC 45A standard series –
Relationships with other IEC, IAEA and ISO documents
The entry point of the SC 45A standard series is IEC 61513. This standard deals with general
requirements for instrumentation and control systems and equipment (I&C systems) that are
used to perform functions important to safety in nuclear power plants (NPPs), and structures
the SC45A standard series.
IEC 61513 refers directly to other SC 45A standards for general topics related to
categorization of functions and classification of systems, qualification, separation of systems,
software aspects of computer-based systems, hardware aspect of computer-based systems,
control rooms design and multiplexing. The standards referenced directly have to be
considered together with IEC 61513 as a consistent document set.
The other SC 45A standards not directly referenced by IEC 61513 are standards related to
particular equipment, technical methods or specific activities. Usually, those low level
documents, which refer to the documents of the higher levels previously described for the
general topics, can be used on their own.
IEC 61513 has adopted a presentation format similar to basic safety publication IEC 61508,
with an overall safety lifecycle frame and a system safety lifecycle frame, and provides an
interpretation of the general requirements of IEC 61508, parts 1, 2 and 4, for the nuclear
application sector. Compliance with IEC 61513 will facilitate consistency with the
requirements of IEC 61508 as they have been interpreted for the nuclear industry. In that
frame, IEC 60880 and IEC 62138 correspond to IEC 61508, part 3 for the nuclear application
sector.
IEC 61513 refers to ISO as well as to IAEA 50-C-QA (now replaced by IAEA 50-C/SG-Q) for
topics related to quality assurance.
The SC 45A standards series implements consistently and in detail the principles and basic
safety aspects given in the IAEA Code on the safety of nuclear power plants and in the IAEA
safety series, in particular the Requirements NS-R-1, “Safety of Nuclear Power Plants:
Design” and the Safety Guide NS-G-1.3, “Instrumentation and Control Systems Important to
Safety in Nuclear Power Plants”. The terminology and definitions used by the SC 45A
standards are consistent with that used by the IAEA.

62138  IEC:2004 – 11 –
NUCLEAR POWER PLANTS –
INSTRUMENTATION AND CONTROL IMPORTANT FOR SAFETY –
SOFTWARE ASPECTS FOR COMPUTER-BASED SYSTEMS
PERFORMING CATEGORY B OR C FUNCTIONS

1 Scope
This International Standard provides requirements for the software of computer-based I&C
systems performing functions of safety category B or C as defined by IEC 61226. It
complements IEC 60880 and IEC 60880-2, which provide requirements for the software of
computer-based I&C systems performing functions of safety category A.
It is also consistent with, and complementary to, IEC 61513. Activities that are mainly system
level activities (for example, integration, validation and installation) are not addressed
exhaustively by this standard: requirements that are not specific to software are deferred to
IEC 61513.
IEC 61513 defines the safety classes of I&C systems important to safety as follows:
• I&C systems of safety class 1 are basically intended to perform functions of safety
category A, but may also perform functions of safety category B and/or C, and non safety-
classified functions;
• I&C systems of safety class 2 are basically intended to perform functions of safety
category B, but may also perform functions of safety category C, and non safety-classified
functions;
• I&C systems of safety class 3 are basically intended to perform functions of safety
category C, but may also perform non safety-classified functions.
Since a given safety-classified I&C system may perform functions of different safety
categories and even non safety-classified functions, the requirements of this standard are
attached to the safety class of the I&C system.
This standard takes into account the current practices for the development of software for I&C
systems, in particular:
• the use of pre-developed software, equipment and equipment families that were not
necessarily designed to nuclear industry sector standards;
• the use of dedicated “black-box” devices with embedded software;
• the use of application-oriented languages.
This standard is not intended to be used as a general-purpose software engineering guide. It
provides requirements that the software of I&C systems of safety classes 2 or 3 must meet to
achieve system nuclear safety objectives.
2 Normative references
The following referenced documents are indispensable for the application of this document.
For dated references, only the edition cited applies. For undated references, the latest edition
of the referenced document (including any amendments) applies.

62138  IEC:2004 – 13 –
IEC 61226, Nuclear power plants – Instrumentation and control systems important for safety –
Classification
IEC 61513:2001, Nuclear power plants – Instrumentation and control for systems important to
safety – General requirements for systems
3 Terms, definitions and abbreviations
For the purposes of this document, the following terms, definitions and abbreviation apply.
3.1
animation
process by which the behaviour defined by a specification is displayed with actual values
derived from the stated behaviour expressions and from some input values
(IEC 60880-2)
3.2
application function
function of an I&C system that performs a task related to the process being controlled rather
than to the functioning of the system itself
(IEC 61513)
3.3
application-oriented language
computer language specifically designed to address a certain type of application and to be
used by persons who are specialists of this type of application
NOTE 1 Equipment families usually feature application-oriented languages so as to provide easy to use capability
for adjusting the equipment to specific requirements.
NOTE 2 Application-oriented languages may be used to specify the functional requirements of an I&C system,
and/or to specify or design application software. They may be based on texts, on graphics, or on both.
NOTE 3 Examples: function block diagram languages, languages defined by IEC 61131-3.
NOTE 4 See also General-purpose language.
3.4
application software
part of the software of an I&C system that implements the application functions
(IEC 61513)
NOTE See also System software, Operational system software.
3.5
category of an I&C function
one of three possible safety assignments (A, B, C) of I&C functions resulting from
considerations of the importance to safety of the functions to be performed. An unclassified
assignment may be made if the function is not significant to safety
(IEC 61513)
NOTE See also Class of an I&C system.

62138  IEC:2004 – 15 –
3.6
class of an I&C system
one of three possible assignments (1, 2, 3) of I&C systems important to safety resulting from
consideration of their requirement to implement I&C functions of differing importance to
safety. An unclassified assignment is made if the I&C system does not implement functions
important to safety
(IEC 61513)
NOTE See also Category of an I&C function.
3.7
complexity
degree to which a system or component has a design, implementation or behaviour that is
difficult to understand and verify
(IEC 61513)
3.8
configuration management
discipline applying technical and administrative direction and surveillance to identify and
document the functional and physical characteristics of a configuration item, control
modifications to those characteristics, record and report changes in status, and verify
compliance with specified requirements
(IEC 61513)
3.9
design specification
document or set of documents that describe the organisation and functioning of an item, and
that are used as a basis for the implementation and the integration of the item
3.10
documentation for safety
document or set of documents that specifies how a product can be safely used for
applications important to safety
3.11
equipment family
set of hardware and software components that may work co-operatively in one or more
defined architectures (configurations). The development of plant specific configurations and of
the related application software may be supported by software tools. An equipment family
usually provides a number of standard functionalities (application functions library) that may
be combined to generate specific application software
(IEC 61513)
NOTE 1 An equipment family may be a product of a defined manufacturer or a set of products interconnected and
adapted by a supplier.
NOTE 2 The term “Equipment platform” is sometime used as a synonym of “Equipment family”.
3.12
error
discrepancy between a computed, observed or measured value or condition, and the true,
specified or theoretical value or condition
(IEC 61513)
NOTE See also Mistake, Fault, Failure.

62138  IEC:2004 – 17 –
3.13
executable code
software that is included in the target system
NOTE Executable code usually includes instructions to be executed by the hardware of the target system, and
associated data.
3.14
failure
deviation of the delivered service from the intended one
(IEC 61513)
NOTE See also Mistake, Fault, Error.
3.15
fault
defect in a hardware, software or system component
(IEC 61513)
NOTE 1 Faults may be subdivided into random faults and systematic faults. Random faults result from hardware
degradation and cause failures at unpredictable times. Systematic faults result from design errors (for example,
software faults) and, in identical conditions, lead systematically to the same failures.
NOTE 2 A fault (in particular a design fault) may remain undetected in a system until specific conditions are such
that the result produced does not conform to the intended function, i.e. a failure occurs.
NOTE 3 See also Mistake, Error, Failure.
3.16
functional validation
verification of the correctness of the application functions specifications versus the plant
functional and performance requirements. It is complementary to the system validation that
verifies the compliance of the system with the functions specification
(IEC 61513)
3.17
general-purpose language
computer language designed to address all types of usage
NOTE 1 The system software of equipment families is usually implemented using general-purpose languages.
NOTE 2 Examples: Ada, C, Pascal.
NOTE 3 See also Application-oriented language.
3.18
integration
progressive aggregation and verification of components into a complete system
3.19
I&C architecture
organisational structure of the I&C systems of a plant which are important to safety
(IEC 61513)
3.20
mistake
human action (or inaction) that produces an unintended result
(IEC 60880-2)
NOTE See also Fault, Error, Failure.

62138  IEC:2004 – 19 –
3.21
mode of behaviour
functional state of an item where it provides a specific operational behaviour
NOTE Examples: initialisation mode, normal mode, downgraded modes to be taken in case of error in the item or
in its environment.
3.22
operational system software
part of system software the executable code of which runs on the target processor during
system operation
(IEC 61513)
NOTE 1 Examples: operating system, input/output and communication drivers, exception handlers, scheduler,
interrupt management, on-line diagnostic, redundancy and graceful degradation management, application software
libraries.
NOTE 2 See also Application software, System software.
3.23
parameter
data item governing the behaviour of the I&C system and/or of its software, and that may be
modified by operators during plant operation
3.24
pre-developed software
software part that already exists and is available as a commercial or proprietary product
(IEC 61513)
NOTE 1 Pre-developed software may be divided into software that has not been specifically developed for a
specific hardware environment, and software integrated in hardware components that has to be used in association
with this hardware.
NOTE 2 In this standard, this term does not cover software tools, even when they are pre-developed.
3.25
program
document written by a human being that is transformed into executable code by automated
tools
NOTE This includes traditional programs written in general-purpose languages. This also includes programs
written in application-oriented languages.
3.26
security
capability of a computer-based system to provide adequate confidence that unauthorised
persons and systems can neither modify the software and its data nor gain access to the
system functions, and yet to ensure that this is not denied to authorised persons and systems
(IEC 61513)
3.27
software
programs (i.e. sets of ordered instructions), data, rules and any associated documentation
pertaining to the operation of a computer-based I&C system
(IEC 60880)
3.28
software modification
change in an already agreed document (or documents) leading to an alteration of the
executable code
NOTE Software modifications may occur either during initial software development (for example, to remove faults
found in later stages of development), or after the software is already in service.

62138  IEC:2004 – 21 –
3.29
software component
one of the design entities that make up a software item. It may be subdivided into other
software components
(IEC 61513)
3.30
software development
phase of the software lifecycle that leads to the creation of the software of an I&C system or
of a software product. It covers all the activities from software requirements specification to
validation and installation on site
3.31
software safety lifecycle
necessary activities involved in the development and operation of the software of an I&C
system important to safety occurring during a period of time that starts with the software
requirements specification and finishes when the software is withdrawn from use
(IEC 61513)
3.32
static analysis
process of evaluating a system or component based on its form, structure, content or
documentation
(IEC 60880-2)
3.33
system software
part of the software of an I&C system designed for a specific computer or equipment family to
facilitate the development, operation and modification of these items and associated
programs
(IEC 61513)
NOTE 1 The system software of equipment families is usually composed of operational system software and of
support system software (software tools).
NOTE 2 See also Application software, Operational system software.
3.34
software validation
test and evaluation of integrated software to ensure compliance with the functional,
performance and interface specifications imposed by the I&C system requirements
3.35
verification
confirmation by examination and by provision of objective evidence that the results of an
activity meet the objectives and requirements defined for this activity (ISO 12207)
3.36
abbreviation
I&C: Instrumentation and Control

62138  IEC:2004 – 23 –
4 Key concepts and assumptions
This Clause presents some of the key concepts and assumptions about the nature and the
development of the software of I&C systems of safety class 2 or 3, upon which the normative
text is based.
4.1 Types of software
Figure 1 illustrates the variety of services offered by software and software components in a
typical I&C system or I&C architecture. Software components may often be defined as being
either system software or application software. System software may also be divided into
operational system software, which is embedded in safety classified I&C systems, and
support system software (or software tools) which is either off-line or embedded in non-safety
classified support systems. Software may also be found in dedicated devices such as sensors
and actuators, communication devices and Uninterruptible Power Supplies (UPSs).

Software for HMI Software for A and C Software for service
(Human-Machine Interface) (Automation and Control)
systems
Support system
Application software Application software
software
written in application- written in application-
- Operating system
oriented languages oriented languages
- Engineering data base
management system
- Engineering tools
- Diagnostic tools
Operational system Operational system
software software
- Operating system - Operating system
Engineering data
- Function block library - Function block library
for hardware and software
- Graphic library - Communication software
- Communication software - Software interfaces to
- Software interfaces
Peripheral Field de-
devices vices
Application software
written in general-
purpose language
(pre-developed or new)
Input-output
devices
with embedded
software
Graphic display
with embedded software
Field
devices
with embed-
ded software
External processing units
(pre-developed or new software)
IEC  2816/03
Figure 1 – Typical software parts in computer-based I&C systems

62138  IEC:2004 – 25 –
The software in an I&C system may also be divided into pre-developed software (which
usually provides functions useful to a range of I&C systems) and new software (which
is developed to the specific needs of the I&C system). System software is usually pre-
developed, and application software is usually new, but this is not an absolute rule. The
requirements of this standard that are applicable to new software may also be applied to pre-
developed software. The standard also provides alternative requirements that may be applied
specifically to pre-developed software or dedicated devices with embedded software.
Many modern equipment families are provided with extensive application-oriented
development tools that enable plant or system engineers to specify their requirements using
graphical techniques. The tools may automatically translate the graphical programs into
executable application software. When these tools are of adequate quality, this approach is
considered to reduce the risk of faults.
4.2 Types of data
Many system designs make extensive use of configuration data. Configuration data may be
associated with operational system software or with application software. Configuration data
associated with application software consists mainly of plant engineering data resulting from
the design of the plant, and is often prepared by plant designers who are not required to have
software skills. Configuration data may be divided into:
• data items which are not intended to be modified on-line by plant operators, and which are
submitted to the same requirements as apply to the rest of the software;
• parameters, i.e., data items which may be modified by operators during plant operation
(for example, alarm limits, set points, data required to calibrate instrumentation) and which
need specific requirements.
4.3 Software and System Safety Lifecycles
System requirements
specification
Selection of pre-
existing equipment/
Suitability analysis
equipment family
System specification
System detailed design and implementation
Application software Equipment (system Development of new
operational system software
development/generation software and hardware)
and hardware features
procurement
System integration
Functional
validation
System validation
System installation
System modification
IEC  2817/03
Figure 2 – Activities of the System Safety Lifecycle (as defined by IEC 61513)

62138  IEC:2004 – 27 –
Software usually contributes strongly to the functions performed by the I&C system. It may
also support additional functions introduced by system design (for example, initialisation and
surveillance of hardware, communication between, and synchronisation of, sub-systems).
Thus, the Software Safety Lifecycle is in most cases strongly integrated with the System
Safety Lifecycle. In particular, the software requirements specification is a part of, or is
derived directly from, system specification and system design.
And though the verification of new software components is definitely a part of the Software
Safety Lifecycle, there is often no separate and well-identified boundary between software
integration and system integration. Therefore, in this standard, software integration is
considered to be a part of system integration. Software validation too is considered a part of
system validation.
System requirements speci-
Software safety
fication
lifecycle –
software quality
assurance
(5.1.1, 6.1.1)
Selection of Suitability analysis of

pre-developed pre-developed software

software (5.2, 6.2) (5.2.3, 6.2.3)

Software
verification
System specification
(5.1.2, 6.1.2)
System detailed design and implementation

Software
configuration
Development of new
Equipment (system
Application software
management
operational system software
software and hardware)
development/generation
(5.1.3, 6.1.3)
(5.3 to 5.5, 6.3 to 6.5)
procurement
(5.3 to 5.5, 6.3 to 6.5)
Software aspects of system
Selection and use
integration (5.6, 6.6)
of software tools
Functional
(5.1.4, 6.1.4)
validation
Software aspects of system
validation (5.7, 6.7)
Selection of
languages
(5.1.5, 6.1.5)
Software aspects of system
installation (5.8, 6.8)
Software security
Software aspects of system
(5.1.6, 6.1.6)
modification (5.10, 6.10)
IEC  2818/03
Figure 3 – Software related activities in the System Safety Lifecycle
(boxes in thin dotted lines represent system activities not addressed in this standard)

62138  IEC:2004 – 29 –
Figures 2 and 3 illustrate the relationship between the activities of the Software Safety
Lifecycle and the activities of the System Safety Lifecycle.
It should be noted that although IEC 61513 identifies two different paths for the
implementation of new software (application software and operational system software, see
Figures 2 and 3), this standard organises the requirements regarding the implementation of
new software into four Subclauses:
• 5.5.1 and 6.5.1 provide requirements that are applicable whatever implementation
technique is used;
• 5.5.2 and 6.5.2 provide requirements specific to the configuration of pre-developed
software and of devices containing software, and in particular the setting of parameters
and other configuration data;
• 5.5.3 and 6.5.3 provide requirements specific to the implementation and verification of
software in application-oriented languages;
• 5.5.4 and 6.5.4 provide requirements specific to the implementation and verification of
software in general-purpose languages.
As boxes titled “Application software development/generation” and “Development of new
system software” represent a large and essential part of the Software Safety Lifecycle, a
“zoom” is provided in Figure 4, which illustrates in more detail the activities between software
requirements specification and software validation, with a clear representation of the three
different implementation paths (configuration of pre-developed software and devices, use of
application-oriented languages and use of general-purpose languages).

Software aspects of
Software
system validation
requirements speci-
(5.7/6.7)
fication (5.3/6.3)
Software aspects of
Software design system integration
(5.4/6.4) (5.6/6.6)
Configuration of software
and of devices containing
software
(5.5.1, 5.5.2/6.5.1, 6.5.2)
Implementation of new
software in application-oriented
languages
(5.5.1, 5.5.3/6.5.1, 6.5.3)
Implementation of
new software in
Software
general-purpose
detailed design
language
(5.4/6.4)
(5.5.1, 5.5.4/6.5.1,
6.5.4)
IEC  2819/03
Figure 4 – Development activities of the IEC 62138 Software Safety Lifecycle

62138  IEC:2004 – 31 –
Provide evidence of conformance to
6.1, 6.2.1, 6.4 to 6.7 and 6.10
Conformance
justified?
Yes
No
Complete justification using other
means (6.2.2.1 to 6.2.2.4)
Conformance
justified?
Yes
No
Are improvements possible?
Reject
No
Yes
Modify in conformance with 6.2.2.5
IEC  2820/03
Figure 5 – Process for providing evidence of correctness for pre-developed software
of an I&C system of safety class 2
Another activity of particular importance in the Software Safety Lifecycle is the selection of
pre-developed software, as this type of software usually represents a very significant portion
of the final integrated software. Figure 5 illustrates in more detail the selection process to be
used for safety class 2.
4.4 Gradation principles
As a consequence of the gradation of safety relevance for functions of categories A, B and C,
a suitable gradation has been adopted for the requirements applicable to the software of I&C
systems of safety classes 1, 2 and 3.
The application of the requirements of this standard for safety class 3 confer the basic level of
confidence that is suitable for software of an I&C system important to safety. The principles
followed are:
• reliance on Quality Assurance;
• special attention given to the assurance that the software:
− contributes as necessary to, and does not adversely affect, the functions important to
safety;
− satisfies the Software Requirements Specification statements which define constraints
important to safety;
• assurance that the operators of the I&C system are informed as early as reasonably
possible of software errors and failures that may affect the functions identified as
important to safety, so that any appropriate action can be taken;
• documented software requirements specifications, design specifications, integration
specifications, validation specifications and modification specifications.

62138  IEC:2004 – 33 –
For safety class 2, in addition to the principles already stated for class 3, the principles
followed by this standard are:
• justification, based on tests and design, that the required safety-related performance (for
example, response times) will be met in all the specified conditions;
• use of Documentation for Safety for pre-developed software and for pre-developed
devices with embedded software; the objective of such documentation is to provide all the
information that is necessary for using the software or devices safely; in particular, the
need for providing design-based justification regarding the safety-related performance
sets the minimal level of information that is necessary;
• use of pre-developed software and devices with embedded software in accordance with
rules based on the corresponding Documentations for Safety;
• configuration and use of pre-developed “black boxes” according to rules also aiming at the
mitigation of the effects of the known or anticipated failure modes;
• justification of correctness and functional suitability for pre-developed software and pre-
developed devices with embedded software; Figure 5 illustrates the process for providing
such justification of correctness for safety class 2;
• extensive and documented verification of the detailed design and of the implementation of
new software; this may include manual inspections, tool supported analysis and tests;
• more stringent requirements for verification, configuration management, selection and use
of software tools and languages, security and fault tolerance;
• explicit requirements for simplicity, clarity, precision, verifiability, testability and
modifiability.
When the same requirement
...