Low-voltage switchgear and controlgear - Guidance for the development of embedded software

IEC TR 63201:2019(E) provides information, and recommended minimum requirements related to embedded software supporting the main functions of switchgear and controlgear during the whole lifecycle of the equipment. It includes also the parameterization aspects and basics about secure coding standards.

General Information

Status
Published
Publication Date
23-May-2019
Current Stage
PPUB - Publication issued
Completion Date
24-May-2019
Ref Project

Buy Standard

Technical report
IEC TR 63201:2019 - Low-voltage switchgear and controlgear - Guidance for the development of embedded software
English language
27 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

IEC TR 63201
Edition 1.0 2019-05
TECHNICAL
REPORT
colour
inside
Low-voltage switchgear and controlgear – Guidance for the development of
embedded software
IEC TR 63201:2019-05(en)
---------------------- Page: 1 ----------------------
THIS PUBLICATION IS COPYRIGHT PROTECTED
Copyright © 2019 IEC, Geneva, Switzerland

All rights reserved. Unless otherw ise 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.
IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé info@iec.ch
CH-1211 Geneva 20 w ww.iec.ch
Sw itzerland
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 corrigendum or an amendment might have been published.

IEC publications search - webstore.iec.ch/advsearchform Electropedia - www.electropedia.org

The advanced search enables to find IEC publications by a The world's leading online dictionary on electrotechnology,

variety of criteria (reference number, text, technical containing more than 22 000 terminological entries in English

committee,…). It also gives information on projects, replaced and French, w ith equivalent terms in 16 additional languages.

and w ithdraw n publications. Also known as the International Electrotechnical Vocabulary

(IEV) online.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Glossary - std.iec.ch/glossary

details all new publications released. Available online and 67 000 electrotechnical terminology entries in English and

once a month by email. French extracted from the Terms and Definitions clause of

IEC publications issued since 2002. Some entries have been

IEC Customer Service Centre - webstore.iec.ch/csc collected from earlier publications of IEC TC 37, 77, 86 and

If you wish to give us your feedback on this publication or CISPR.
need further assistance, please contact the Customer Service
Centre: sales@iec.ch.
---------------------- Page: 2 ----------------------
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

Warning! Make sure that you obtained this publication from an authorized distributor.

® Registered trademark of the International Electrotechnical Commission
---------------------- Page: 3 ----------------------
– 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

---------------------- Page: 4 ----------------------
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

---------------------- Page: 5 ----------------------
– 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.
---------------------- Page: 6 ----------------------
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.
---------------------- Page: 7 ----------------------
– 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.

---------------------- Page: 8 ----------------------
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.
---------------------- Page: 9 ----------------------
– 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.]

---------------------- Page: 10 ----------------------
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]
---------------------- Page: 11 ----------------------
– 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;
---------------------- Page: 12 ----------------------
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 servic
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.