CLC IEC/TR 63201:2020

SLOVENSKI STANDARD
01-november-2020
Nizkonapetostne stikalne in krmilne naprave - Navodilo za razvoj vgrajene
programske opreme (IEC/TR 63201:2019)
Low-voltage switchgear and controlgear - Guidance for the development of embedded
software (IEC/TR 63201:2019)
Niederspannungsschaltgeräte - Leitfaden für die Entwicklung von Firmware (IEC/TR
63201:2019)
Appareillage à basse tension - Guide pour le développement du logiciel embarqué
(IEC/TR 63201:2019)
Ta slovenski standard je istoveten z: CLC IEC/TR 63201:2020
ICS:
29.130.20 Nizkonapetostne stikalne in Low voltage switchgear and
krmilne naprave controlgear
35.080 Programska oprema Software
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT CLC IEC/TR 63201

RAPPORT TECHNIQUE
TECHNISCHER BERICHT
August 2020
ICS 29.130.20
English Version
Low-voltage switchgear and controlgear - Guidance for the
development of embedded software
(IEC/TR 63201:2019)
Appareillage à basse tension - Guide pour le Niederspannungsschaltgeräte - Leitfaden für die
développement du logiciel embarqué Entwicklung von Firmware
(IEC/TR 63201:2019) (IEC/TR 63201:2019)

This Technical Report was approved by CENELEC on 2020-08-10.

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

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2020 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. CLC IEC/TR 63201:2020 E

European foreword
This document (CLC IEC/TR 63201:2020) consists of the text of IEC/TR 63201:2019 prepared by
SC 121A "Low-voltage switchgear and controlgear" of IEC/TC 121 "Switchgear and controlgear and
their assemblies for low voltage".
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.

Endorsement notice
The text of the International Technical Report IEC/TR 63201:2019 was approved by CENELEC as a
European Technical Report without any modification.
In the official version, for Bibliography, the following notes have to be added for the standards
indicated:
IEC 60880:2006 NOTE Harmonized as EN 60880:2009 (not modified)
IEC 61508 (series) NOTE Harmonized as EN 61508 (series)
IEC 61508-3:2010 NOTE Harmonized as EN 61508-3:2010 (not modified)
IEC 61508-4:2010 NOTE Harmonized as EN 61508-4:2010 (not modified)
IEC 61508-7:2010 NOTE Harmonized as EN 61508-7:2010 (not modified)
IEC 61511-1:2016 NOTE Harmonized as EN 61511-1:2017 (not modified)
IEC 62061 NOTE Harmonized as EN 62061
IEC 62443 (series) NOTE Harmonized as EN IEC 62443 (series)
ISO 13849-1:2015 NOTE Harmonized as EN ISO 13849-1:2015 (not modified)

Annex ZA
(normative)
Normative references to international publications
with their corresponding European publications
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 1  Where an International Publication has been modified by common modifications, indicated by (mod), the relevant
EN/HD applies.
NOTE 2  Up-to-date information on the latest versions of the European Standards listed in this annex is available here:
www.cenelec.eu.
Publication Year Title EN/HD Year
ISO/IEC 2382-1 1993 Information technology - Vocabulary -- - -
Part 1: Fundamental terms
IEC TR 63201 ®
Edition 1.0 2019-05
TECHNICAL
REPORT
colour
inside
Low-voltage switchgear and controlgear – Guidance for the development of

embedded software
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
ICS 29.130.20 ISBN 978-2-8322-7006-6

– 2 – IEC TR 63201:2019  IEC 2019
CONTENTS
FOREWORD . 4
INTRODUCTION . 6
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 7
4 Risk assessment and identification of the main functions. 10
5 Design management . 10
5.1 Objective. 10
5.2 Software management plan of the main functions . 10
5.3 Configuration management . 11
5.4 Change management . 11
5.5 Defect management . 12
5.6 System build and release processes . 13
5.6.1 Binary generation . 13
5.6.2 Release management. 13
6 Manual parameterization of the embedded software . 13
6.1 General . 13
6.2 Influences on main function related parameters . 14
6.3 Requirements for software-based manual parameterization . 14
6.4 Verification of the parameterization tool . 15
6.5 Documentation of software-based manual parameterization . 15
7 Design lifecycle. 15
7.1 General . 15
7.2 Tools usage . 16
7.3 Software lifecycle . 16
7.3.1 Software lifecycle model . 16
7.3.2 Independence of review, testing and verification activities . 17
7.4 Requirements definition . 18
7.4.1 General . 18
7.4.2 System requirements . 18
7.4.3 Software requirements specification. 18
7.5 Software architecture . 20
7.5.1 General . 20
7.5.2 Software architecture specification . 20
7.6 Software unit design . 20
7.6.1 General . 20
7.6.2 Input information . 20
7.6.3 Software unit specification . 21
7.7 Coding. 21
7.8 Software unit test . 22
7.9 Software integration test . 22
7.10 Software testing . 22
7.10.1 General . 22
7.10.2 Test planning and execution . 23

IEC TR 63201:2019  IEC 2019 – 3 –
7.11 Documentation . 23
7.12 Configuration and change management process . 24
7.13 Verification and relationship with the validation of the equipment or system . 24
Bibliography . 26

Figure 1 – Defect management process . 12
Figure 2 – V-model of software lifecycle . 17

– 4 – IEC TR 63201:2019  IEC 2019
INTERNATIONAL ELECTROTECHNICAL COMMISSION
____________
LOW-VOLTAGE SWITCHGEAR AND CONTROLGEAR –
GUIDANCE FOR THE DEVELOPMENT OF EMBEDDED SOFTWARE

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, Techni ca l S pe cif i cat i ons,
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 intereste d
in the subject dealt with may participate in this preparat ory w ork. In t ern at i on al , go vern me nt al a n d n on -
governmental organizations liaising with the IEC also participate in this preparation. IEC collabo rat es cl o sel y
w ith the International Organization for Standardization (ISO) in accordance w i t h co nd i ti o ns d et ermi n e d b y
agreement between the tw o organizations.
2) The f ormal 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 committ ee h as r ep resen ta ti o n f ro m a l l
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accep te d b y IEC Na t i o n a l
Committees in that sense. While all reasonable efforts are made to ensure that the tech ni cal c on te nt of IEC
Publications is accurate, IEC cannot be held responsi ble for the w ay in w hich they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake t o a pp l y IEC Pu b l i c a ti o ns
transparently to the maximum extent possible in their national and r egional publications. Any divergence
betw een any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC itself does not provide any attestation of conformity. Independent certification bodies pro vid e c onf o rmi ty
assessment services and, in some areas, access to IEC marks of conformity. IEC is not r esp onsi b l e f o r a ny
services carried out by independent certification bodies.
6) A ll 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 e xpe rts a n d
members of its technical committees and IEC National Committees for any personal injury, property damage o r
other damage of any nature whatsoever, whether direct or indirect, or for c osts ( i ncl ud i ng l e ga l f ees) a n d
expenses arising out of the publication, use of, or rel i a nce u p on , t h is IEC Pu b l i c a t i on o r a ny o t he r IEC
Publications.
8) A ttention is drawn to the Normative references cited in this publication. Use of the referenced p ub l i cat i ons i s
indispensable for the correct application of this publication.
9) A ttention is drawn to the possibility that some of the elements of this IEC Publicatio n ma y be t he su bj ect of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
The main task of IEC technical committees is to prepare International Standards. Ho w e ve r , a
technical committee may propose the publication of a technical report when i t has c ol l ec ted
data of a different kind from that which is normally published as an International Standard, fo r
example "state of the art".
IEC TR 63201, which is a technical report, has been prepared by subcommi t te e 1 2 1 A : L o w-
voltage switchgear and controlgear, of IEC technical committee 121: Switchgear and
controlgear and their assemblies for low voltage.
The text of this technical report is based on the following documents:
Enquiry draft Report on voting
121A /256/DTR 121A /287A/RVDTR

Full information on the voting for the approval of this technical report can be found in the
report on voting indicated in the above table.

IEC TR 63201:2019  IEC 2019 – 5 –
This document has been drafted in accordance with the ISO/IEC Directives, Part 2.
The committee has decided that the contents of this document will remain unchanged until the
stability date indicated on the IEC website under "http://webstore.iec.ch" in the data related t o
the specific document. At this date, the document will be
• reconfirmed,
• withdrawn,
• replaced by a revis ed edition, or
• amended.
A bilingual version of this publication may be issued at a later date.

IMPORTANT – The 'colour inside' logo on the cove r pa ge of this publication indicat e s t h a t i t
contains colours which are considered to be useful for the correct understanding of its
conte nts. Use rs should the re fore print this document using a colour printer.

– 6 – IEC TR 63201:2019  IEC 2019
INTRODUCTION
Programmable electronics are now being integrated within switchgear and c ont rol gear. F or
example, soft-starters, electronic overload relays, circuit-breakers with elec tr o n ic t r i p u n i t s ,
proximity switches with built in micro-controllers and some acc es sories s uch as ex t ensi on
modules and control panels are using programmable electronics with embedded software
called firmware. This embedded software often supports the main functions (see 3.3) provided
by the equipment such as overcurrent protection and other import a n t fu n c ti o n s, e. g. al arm
detection from monitoring devices.
The integration of embedded software within switchgear and controlgear should n o t d e g r a d e
the integrity of their main functions compared to purely electromechanical equipment.
Therefore, a minimum set of standard requirements for embedded software is provided by this
document.
This document takes into account the existing best practices for developing embedded
software within safety functions for automation given by IEC 61508-3. Functional safety
approach is mainly used in machinery , automotive, automation and process automation where
safety functions are implemented with multiple components which should match a c o n s i ste n t
level of integrity when combined. In other sectors, such as electric distribution and power
control systems, key functions such as over-current release, residual c urrent rel eas e, l oad
monitoring, etc. should follow installation rules and coordination rules which are
systematically safety and reliability related. Therefore, this document can be seen as
providing the principles of the good practice given by IEC 61508-3.
This document is also intended to provide an up-to-date method with regards to the
supplement SE of UL 489.
The intention of this document is to provide guidance about:
– risk assessment aspects in relation to embedded software;
– embedded software evaluation method;
– software architecture;
– basic coding rules;
– measures to control software errors;
– software verification and its relationship with the validation of the equipment or system.
In this document, the term “software” is used as a generalized term for embedded software.

IEC TR 63201:2019  IEC 2019 – 7 –
LOW-VOLTAGE SWITCHGEAR AND CONTROLGEAR –
GUIDANCE FOR THE DEVELOPMENT OF EMBEDDED SOFTWARE

1 Scope
This document provides information, and recommended minimum requirements related to
embedded software supporting the main functions of switchgear and cont r o l g e a r d u r i n g t h e
whole lifecycle of the equipment. It includes also the parameteri zat ion as pect s and bas i c s
about secure coding standards.
This document can be used in addition to product standard requirem ent s when not al ready
covered.
This document is appropriate for new development or major changes in existing equipment.
This document is not intended to cover the functional safety of control systems for machi n e r y
or for automation which are covered by IEC 62061, ISO 13849-1 and IEC 61508 (all parts),
neither the cybersecurity risk which are covered by ISO 27005, and IEC 62443 (al l part s ). It
gives only some example of secure coding rules.
NOTE Future new publication IEC TS 63208 is under development for implementing embedd ed cybe rsecur it y
measures within switchgear and controlgear based on ISO 27005 and IEC 62443 (all parts).
2 Normative references
The following documents are referred to in the text in such a way that some or all of their
content constitutes requirements 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.
ISO/IEC 2382-1:1993, Information technology – Vocabulary – Part 1: Fundamental terms
3 T e rms and de finitions
For the purposes of this document, the terms and definitions given in ISO/IE C 2382-1: 1993,
as well as the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following
addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
e mbe dded softw a re
software, supplied by the manufacturer, that is an integral part of the eq u i p m e n t a n d t hat i s
not accessible for partial modification
Note 1 to entry: Firmw are and system software are examples of embedded software.
Note 2 to entry: A n embedded software can be upgraded by an integral upload.
__________
Future publication IEC TS 63208 is currently at CD stage.

– 8 – IEC TR 63201:2019  IEC 2019
3.2
programmable electronic
based on computer technology which can comprise hardware, software, and input and/or
output units
EXA MPLE The f ollowing are all programmable electronics:
– microprocessors;
– micro-controllers;
– programmable controllers;
– application specific digital integrated circuits (ASICs with programmable part);
– programmable logic controllers (PLCs);
– other computer-based devices (for example smart sensors, transmitters, actuators).
Note 1 to entry: This term covers microelectronic devices based on one or more central processing units (CPUs)
together with associated memories, etc.
Note 2 to entry: The term “ programmable component” is f rom A NSI/UL 1998:2013, definition 2.39.The definit i on
in A NSI/UL f or programmable component is: “A ny microelectronic hardware that can be programmed in the design
centre, the f actory, or in the f ield”. Here the term “programmable” is taken to be “any manner i n w h ich on e ca n
alter the software w herein the behaviour of the component can be altered.”
[SOURCE: IEC 61508-4:2010, 3.2.12, modified – In the definition, “may” changed by “can”,
“be” and “of” deleted, and addition of a new Note 2 to entry.]
3.3
ma in function
defined function of switchgear and contr o l g e a r w h o s e fa i l u r e
can result in its unwanted operation which can lead to hazardous situations, in the lo s s o f i t s
protective function, or in the loss of a key functionality defined by the manufacturer
3.4
syste ma tic fa ilure
failure related in a deterministic way to a certain cause, which c a n o n l y b e e l i m i n a t ed b y a
modification of the design or of the manufacturing process, operational procedures,
documentation or other relevant factors
Note 1 to entry: Corrective maintenance without modification will usually not eliminate the failure cause.
Note 2 to entry: A systematic failure can be induced by simulating the failure cause.
Note 3 to entry: Examples of causes of systematic failures include human error in:
– the safety requirements specification;
– the design, manufacture, installation and/or operation of the hardware;
– the design and/or implementation of the software.
[SOURCE: IEC 61508-4, 3.6.6, modified – Deletion of Note 4 to entry.]
3.5
full variability language
FVL
type of language that provides the capability to implement a wide variety of functions and
applications
Note 1 to entry: FV L is normally found in embedded software and is rarely used in application software.
Note 2 to entry: FV L examples include: Ada, C, Pascal, Instruction List, assembler languages, C++, Java, SQL.
[SOURCE: IEC 61511-1:2016, 3.2.75.3, modified – Deletion of “designed to be comprehensible
to computer programmers” and Note 1 to entry, remaining notes to entry renumbered.]

IEC TR 63201:2019  IEC 2019 – 9 –
3.6
configura tion ma nagement
discipline of identifying the components of an evolving system for the purposes of cont r o l l i n g
changes to those components and maintaining continuity and traceability throughout the
lifecycle at a specific point of time
[SOURCE: IEC 61508-4:2010, 3.7.3, modified – Addition of "at a specific point of time".]
3.7
baseline
agreed set of elements (hardware, software, documentation,
tests…) of an equipment at a specific point in time, which serves as a basis fo r ve r i fi c a t i o n ,
validation, modification and changes
Note 1 to entry: If an element is changed the status of the baseline is intermediate until a new baseline is defined.
3.8
coding rule s
coding sta nda rd
set of rules and guidelines for the formatting of software source code of a program intended to
ensure its readability, maintainability, compatibility and robustness
Note 1 to entry: Typical aspects of coding rules are naming conventions, file naming and organization, formatti ng
and indentation, comments and documentation, classes, functions and interfaces, allow ed/forbidden s tandard
library function usages, data types, pointer and reference usage, and testing.
3.9
softw a re unit
separately compilable piece of code
Note 1 to entry: Sof tware unit is also called software module and software component such as in documents fro m
International Software Testing Qualifications Board (ISTQB).
[SOURCE: ISO/IEC 12207:2008, 4.43, modified – Addition of a new Note 1 to entry.]
3.10
inte gration te sts
tests performed during the software units and hardware/software integration
process prior to the verification and system validation to verify compatibi li ty o f t h e s o ft w a r e
and the hardware
[SOURCE: IEC 60880:2006, 3.23, modified – Addition of “software units and”, replacement of
“computer-based” and “computer” by “the verification and system validation”.]
3.11
softw a re ve rification
confirmation by examination (e.g. tests, analysis) that the software, its integration or it s u n i t s
requirements have been fulfilled
3.12
sta tic a na lysis
examination of source code for features that may indicate the presence of
software faults
Note 1 to entry: Static analysis typically reveals unreachable sections of code, unused, misused, doubly-defi n ed
or uninitialized variables, and unintended execution paths.
Note 2 to entry: Static analysis normally employs computer aided software engineering tools.
[SOURCE: IEC 60050-192:2015, 192-09-22]

– 10 – IEC TR 63201:2019  IEC 2019
3.13
system validation
confirmation by examination and provision of objective evidence that the r e q u i r e m e n t s fo r a
specific intended use of the equipment or the system are fulfilled
Note 1 to entry: By principle the embedded software is integrated in an equipment or a system. The validati on of
this equipment or system includes embedded software related verifications.
4 Risk asse ssment and ide ntification of the main functions
Based on manufacturer experience, a system analysis, in the context of the intended
applications of the equipment, including its different modes of operation and t h e r e a s o n a b l y
foreseeable misuse, should determine the list of main functions and t heir assoc iated degr ee
of risk.
EXA MPLE Sensor detection of an object, overcurrent protective function, continuity of supply, power off a mo t or
system.
A risk assessment method such as IEC Guide 116 should be used for this purpose.
Each software part implementing a main function should be managed according to the method
provided in this document.
5 De sign manageme nt
5.1 Objective
A particular organisation of the software design is necessary to ensure the complete
realisation of the main function according to its original specification.
This organisation should be defined by a software management plan which may be a clearly
identified part of a global design management plan.
5.2 Softw a re management pla n of the ma in functions
This plan is required for defining the management of the activities along the software
development lifecycle for the specification and the verification of the software related t o m ai n
functions (see 3.3).
The organisation should be defined with the roles and associated responsibilities for the
management (s tarting, controlling) and the execution of the activities.
It should be drawn up, documented and updated as necessary. It is intended to provide
measures for preventing incorrect s pecification, implementation, or modification issues.
The software management plan of the main functions should be adapted to the project.
In particular, the plan should:
a) identify the relevant design activities for the development of the parts related t o t he m ai n
functions (essential design activities and their organisation in appropriate se q u e n ce s a r e
illustrated in Figure 2);
b) describe the policy and strategy to fulfil the specified requi r em ent s r el at ed t o t he m ai n
functions;
c) describe the strategy for the development, integration, and verification which may inc l ude
conformity assessment;
IEC TR 63201:2019  IEC 2019 – 11 –
d) identify authorized persons, departments or other organisation units a n d res ourc es t hat
are responsible for carrying out and reviewing each of the main functions design activities;
the level of appropriate competency (i.e. training, technical knowledge, experience and
qualifications) should be taken into account;
e) identify or establish the procedures and resources to record and maintain information
relevant to the main function of the equipment, taking into account t he ri s k as sess ment
results and the change management;
f) describe the strategy for configuration management taking into account relevant
organizational issues, such as authorized persons and internal structures of the
organization;
g) describe the strategy for modification;
h) establish a software verification plan as detailed in 7.4.3.
5.3 Configura tion ma nagement
The configuration management is a system engineering process establishing and maintain i ng
consistency of the equipment performance, functional, and physical attributes with its
requirements, design, and operational information throughout its life. It co n s i sts of veri fy i ng
whether the software and hardware elements of the equipment are identified and documente d
in sufficient detail to support its projected lifecycle. This process facilitates the m anagem ent
of the equipment information and the equipment changes for allowing revise capability;
improve performance, reliability, or maintainability; extend life; reduce cost; r e d u c e r i s k a n d
liability; or correct defects.
The main operational aspects of configuration management are:
– identification of the structure of the equipment, by identifying its elemen t s e. g. s ystem,
subsystems, functions, function blocks, management documents, tools for creating a
baseline;
– controlling of the release of an element created during each lifecycle phase at a spe c i fi c
point in time;
– recording and reporting of the status of each element which is a n d / o r w i l l b e p a r t o f a
baseline;
– audit and review of all elements and maintaining consisten cy a m ong al l el em ent s of a
baseline.
Procedures should be developed for configuration management of the equipm ent duri ng t he
overall development lifecycle phases of the equipment system and software, including in
particular:
a) the point, in respect of specific phases, at which formal configuration control is to be
implemented;
b) the procedures to be used for uniquely identifying all constituent parts of an item
(hardware and software);
c) the procedures for preventing unauthorized elements from entering into service.
The configuration management procedures should be implemented in accordance with the
software management plan.
The procedures for an appropriate change-control-process should consider the requi r e m e n t s
of procedures for defining a unique baseline of each version of the equipment including all
related configuration items.
5.4 Cha nge ma nagement
If a modification related to a main function is to be implemented, then relevant activities
should be identified specifically and an action plan should be prepared, documented and
approved before carrying out any modification.

– 12 – IEC TR 63201:2019  IEC 2019
NOTE 1 The request for a modification can arise from, for example:
– main f unction requirements specification changed;
– conditions of actual use;
– incident/accident experience;
– change of material processed;
– modif ications of the equipment or of its operating modes.
NOTE 2 Interventions (e.g. adjustment, setting, repairs) on the equipment made in accordance w ith the
inf ormation for use or instruction manual for the equipment are not considered to be a modification in the context of
this subclause.
The reason(s) for the request for a modification should be documented.
The effect of the requested modification should be analysed to identify the effect on t h e m a i n
function.
The modification impact analysis and the effect on the main function of the equipment s h o u l d
be documented.
All accepted modifications that have an effect on the equipment should initiate a r e t u r n t o a n
appropriate design phase for its hardware and/or for its software (e.g. specifi ca t io n , d e s i g n ,
integration, installation, commissioning, verification and system validat i on). A l l s ubs equent
phases and management procedures should then be carried out in accordance with the
procedures specified for the specific phases in this document. All relevant documents s h o u l d
be revised, amended and reissued accordingly.
5.5 Defect management
Any software development requires a solid defect management process all along the
development lifecycle.
A defect can be:
– a consequence of a coding fault;
– a deviation from the original requirement;
– an unexpected behaviour on an external event.

Figure 1 – De fe ct ma nagement proce ss
Defect process workflow varies depending on development team practices. Upper Figure 1
gives an example of process flow for defect lifecycle with the following states:

IEC TR 63201:2019  IEC 2019 – 13 –
– New : this will be the first step to identify the defect in the proces s . M o s t o f t h e t i m e t he
test team are the one who usually submit defects and sometimes the c u s t o me r c a n a l s o
report about defects;
– Analysed: once the defect registered, the development team setup all means to
reproduce and understand the defect root cause. Usually defect severity is set or modifie d
during this step;
– Rejected: according to the type of defect or severity of the defect, defect res ol ut ion m ay
be rejected;
– Implemented: developer fixes the defect and places it in the s a m e p l a c e fr o m w h e r e i t
was identified;
– Verified: as soon as the defect is fixed, the verification team verifies that defect is actually
fixed and the system is working as expected;
– Closed: once it is fixed, documented and resolved it is marked as closed case.
NOTE Each state of the defect process workflow can be assigned to a specific project team me mb e r , w i th d ue
delivery date.
5.6 Syste m build a nd re lease processes
5.6.1 Binary generation
Building the software binaries that will run on the target (switchgear and controlgear) s houl d
be highly predictable, i.e. s ame sources shall generate same binary.
Hence build tools (compiler, linker, downloader…) and their used o p t i o n s s h a l l b e h a n d l e d
under configuration management.
5.6.2 Release management
Each software release should be identified by a unique version/revision number. The most
common numbering convention identifies major, minor and patch releases:
– a major version is incremented when there is a compatibility break or several new features
support. Usually when MAJOR=0, the software is still in development phase or in Beta
Version;
– a minor revision is incremented when few additional features are supported;
– a patch release is incremented for bug-fixes.
Each software release shall be documented by notes which detail the release c ont ents: new
features, list of fixed defects and known limitations.
6 Manual parame terization of the e mbedded software
6.1 General
Some equipment needs manual parameterization to carry out a main function. The
parameterization can be done via a remote connection (e.g. PC-based configuration tool) o r a
human machine interface (e.g. display, DIP-switches, potentiometer, knobs, m em ory-c ards)
connected to the equipment.
The objective of the requirements for software-based manual parameterization is to guarantee
that the main function related parameters are correctly selected and transferred into the
equipment performing the main function. These parameters should not affect a main fu n c t i o n
in an unintended nor an unauthorized manner.

– 14 – IEC TR 63201:2019  IEC 2019
Different methods can be applied to set such parameters; even DIP-switch based
parameterization may be used to set or change main function related param e t e r s . However,
tools with dedicated parameterization software, commonly called configuration or
parameterization tools, are becoming more prevalent. This subclause i s l i m i te d i n s c o p e t o
only manual, software-based parameterization that is performed and controlled by an
authorized person. These requirements apply if the parameterization occurs at initial
commissioning of the equipment, or if the parameterization occurs at any point in the lifecycle
of the equipment.
6.2 Influe nces on ma in function related pa rameters
During software-based manual parameterization, the main function parameters can be
affected by several influences, such as:
– data entry errors by the person responsible for parameterization;
– faults of the software of the parameterization tool;
– faults of further software and/or service provided with the parameterization tool;
– faults of the hardware of the parameterization tool;
– faults during transmission of parameters from the parameterization tool to the equipment;
– faults of the equipment to store transmitted parameters correctly;
– systematic interference during the parameterization process, e.g. by electromagnetic
interference or loss of power;
– interference due to external influences or factors, such as electromagnetic interference or
(random) loss of power.
Without appropriate measures, the influences listed above can oc c ur wi t hout not i c e t o t he
person responsible for the parameterization and lead to the following:
– parameters are not updated by the parameterization process, either completely or in parts;
– parameters are incorrect, either completely or in parts;
– parameters are applied to an incorrect device, such as when transmission of parameters is
carried out via a wired or wireless network.
Measures should be applied to counteract, avoid or control potential dangerous failures
caused by the influences listed above.
6.3 Re quirements for softw are-base d manual pa rameterization
Software-based manual parameterization should use a dedicated tool provided by the supplier
of the equipment or the related subsystem(s). This tool should have its own identification
(name, version, etc.). The equipment or the related subsystem(s) and t h e p a r a m e t e r i z a t io n
tool should have the capability to prevent unauthorized modification, for exam pl e by us i ng a
password.
W hen the parameterization process can cause an unsafe state, the parameteriz a tio n s h o u l d
be carried out off-line with the equipment in a safe state. The following requir e m e n t s s h o u l d
be fulfilled in addition:
a) the design of the software-based manual parameterization should be considered as a
main function related aspect of the equipment design that is described in a main fu n c t i o n
requirements specification, e.g. in the system requirements specification;
b) the equipment or subsystem should provide a data checking system that carr i e s o u t e . g .
checks of data limits, format and/or logic input values;
c) the integrity of all data used for parameterization should be maint a i n e d . Th i s s h o u l d b e
achieved by applying measures to:
– control the range of valid inputs;
– control data corruption before transmission;

IEC TR 63201:2019  IEC 2019 – 15 –
– control the effects of errors from the parameter transmission process;
– control the effects of incomplete parameter transmission; and
– control the effects of faults and failures of hardware and software of the
parameterization.
The software units used for encoding/decoding within the transmission/retransmission
process and the software units used for visualization of the main function-related para m e t e r s
to the user should, as a minimum, use diversity in function(s) to a vo i d s y s te m a ti c fa i l u r e s.
Diversity in this case consists of using a totally different transmission met hod t o reduc e t he
probability of common cause failure.
6.4 Ve rification of the pa rameterization tool
As a minimum, the following verification activities should be performed to verify the basic
functionality of the parameterization tool:
– verification of the correct setting for each main function related parameter (check agai nst
valid values);
– verification of the plausibility for each main function related parameter, for example by
detection of invalid parameter combinations;
– verification that means are provided to prevent unauthorized modification of main function
related parameters.
NOTE This is of particular importance where the parameterization is carried out using a device n ot sp ecif i ca ll y
intended for this purpose (e.g. personal computer or equivalent).
6.5 Documentation of softw are-base d ma nual parameterization
Software-based manual parameterization should be carried out using the dedicated
parameterization tool provided by the supplier of the equipment, and should be doc um ent ed
according to the requirements given in the information for use. This information can ori g i n a t e
from different parties. It can be stored in different locations (paper, digitally, on the
parameterization tool, on the equipment, etc.). Protective measures against unauthorized
acces s should be activated and used.
The initial parameterization, and subsequent modifications to the parameterization, should b e
documented. The documentation should include:
a) the identification of the parameterized equipment when the documentat io n i s n o t s t o r e d
internally;
b) the date of initial parameterization or change;
c) the date or version number of the data set;
d) the name of the authorized person carrying out the parameterization;
e) an indication of the origin of the data used (e.g. pre-defined parameter s et s , as l eft at a
previous setting after the last change);
f) clear identification of main function related parameters.
7 Design lifecycle
7.1 General
All lifecycle activities of embedded software should focus on the avoidance of faults
introduced during its design lifecycle. The main objective of the following req u i r e m e n t s i s t o
produce readable, understandable, testable, maintainable and correct software.

– 16 – IEC TR 63201:2019  IEC 2019
Where the software performs both non-main functions and main functions, then all of the
software should be treated as main function related, unless sufficient independence b e t w e e n
the functions can be demonstrated in the design. It is therefore preferabl e t o s eparat e non-
main functions such as basic equipment functions from main functions wherever practicable.
7.2 Tools u
...