IEEE Recommended Practice for

Microprocessor-Based Protection
Equipment Firmware Control

IEEE Power Engineering Society

Sponsored by the
Power System Relaying Committee

IEEE
IEEE Std C37.231-2006
3 Park Avenue
New York, NY 10016-5997, USA

6 June 2007

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE Std C37.231-2006

IEEE Recommended Practice for

Microprocessor-Based Protection
Equipment Firmware Control

Sponsor
Power Systems Relaying Committee
of the
IEEE Power Engineering Society

Copyright 2007 IEEE. All rights reserved. i

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Abstract: This recommended practice deals with the implications surrounding the use and admin-
istration of firmware revisions for protection-related equipment. In general, the number of firmware
revisions have become prolific since the introduction of microprocessor-based protection related
equipment and no standard means of dealing with the issues surrounding this situation has been
addressed. This recommended practice attempts to provide guidelines for the effective communi-
cation of firmware-related issues with the intent of helping to maximize the security and reliability
of the power system.
Keywords: firmware, IED, Intelligent Electronic Device, microprocessor, revisions, software

The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright 2007 by the Institute of Electrical and Electronics Engineers, Inc.
All rights reserved. Published 6 June 2006. Printed in the United States of America.

IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics
Engineers, Incorporated.
Print: ISBN 0-7381-5329-X SH95620
PDF: ISBN 0-7381-5330-3 SS95620
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the
IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus
development process, approved by the American National Standards Institute, which brings together volunteers
representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the
Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness
in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the
information contained in its standards.

Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other
damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting
from the publication, use of, or reliance upon this, or any other IEEE Standard document.

The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims
any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that
the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied AS IS.

The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market,
or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
time a standard is approved and issued is subject to change brought about through developments in the state of the art and
comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for
revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to
conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned
to check to determine that they have the latest edition of any IEEE Standard.

In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services
for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or
entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a
competent professional in determining the exercise of reasonable care in any given circumstances.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific
applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare
appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any
interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its
societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except
in those cases where the matter has previously received formal consideration. At lectures, symposia, seminars, or educational
courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered
the personal views of that individual rather than the formal position, explanation, or interpretation of the IEEE.

Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with
IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate
supporting comments. Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854
USA

Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of
Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To
arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.

Copyright 2007 IEEE. All rights reserved. iii

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Introduction

This introduction is not part of IEEE Std C37.231-2006, IEEE Recommended Practice for Microprocessor-Based
Protection Equipment Firmware Control.

In the past few years, the technology used for the protection of the power system has evolved from
electromechanical devices, to solid state, to microprocessor-based devices. Electromechanical devices had
the inherent characteristic that their behavior was dependant upon physical or mechanical properties
determined by the laws of physics. With the introduction of solid-state technology into protection and
control, the earlier generation of microprocessor-based protective devices were developed and applied.
Feature enhancements or product deficiencies were addressed by installing new integrated circuits or printed
circuit board upgrades. Todays microprocessor-based devices, however, are mostly controlled by the
firmware or code that instructs the device how to operate and perform. Firmware refers to programming
code that is based on the internal operating paradigms of the microprocessor, or microcontroller, being used
in the particular application. This code is based on the specific performance desired from the device and is
typically stored in read-only memory. A certain DSP may be used for an automotive application in one
instance, a business-related application in a second instance, and a protective relaying function in a third
instance. What distinguishes the application is the firmware code written to control the processor (or
processing chip) being used.

The implementation of the desired functionality is not based on the hardware construction of a physical
device (as with the electromechanical device) but on the algorithms coded by the programmers. This leads to
a wealth of different ways of implementing specific functions such as filtering, anti-aliasing, protection,
metering, and combinations thereof. Over time the manufacturer may want to augment existing functionality
by adding new features, such as changing the range/performance of certain functions, or correcting certain
deficiencies found in the performance of the device. All of this leads to the possibility of a firmware change.

The reality of a firmware change for existing devices can have vast and far reaching implications. Questions
arise such as: How important is the change? Is the firmware change compatible with existing devices? How
important or critical is the new firmware for existing customers? What is the impact on documentation?
How does one test the new revision? How does one ascertain that existing functionality has not changed?
The user is also concerned about the reliability of the equipment purchased as well as the cost associated
with changing firmware in existing devices.

Underpinning any firmware revision notification mechanism is the need for accurate and up-to-date records.
This is the responsibility of both the manufacturer and user. As is the case for automobiles and other
consumer products, recall notices and information bulletins are realities of doing business. In some cases,
due diligence may have to be exercised in order to avoid legal implication, for example, in cases where a
product may lead to loss of revenue or may impact system or scheme performance.

Due to the fact that the person who applies a firmware change to the actual device may not be the same
individual as the one corresponding with the manufacturer or the field personnel who actually commissions
the device, the term firmware controller is used in this document to refer to the individual who has the
responsibility to maintain the firmware for protection devices. The firmware controller could be the end-user
(field personnel), the engineering design department, purchasing, or any number of alternatives (as practices
vary among users). The firmware controller will most likely be different from case-to-case and is a generic
term in this document.

iv Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Notice to users

Errata

Errata, if any, for this and all other standards can be accessed at the following URL: http://
standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for
errata periodically.

Interpretations

Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee/interp/

index.html.

Patents

Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken with respect to the existence or
validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying
patents or patent applications for which a license may be required to implement an IEEE standard or for
conducting inquiries into the legal validity or scope of those patents that are brought to its attention.

Copyright 2007 IEEE. All rights reserved. v

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Participants

At the time this recommended practice was completed, the I3 Working Group had the following
membership:
Robert W. Beresh, Chair
Roger L. Whittaker, Vice-Chair

Gustavo Brunello Gerald Johnson Veselin Skendzic

Dac-Phuoc Bui Bogdan Kasztenny Michel Toupin
Ratan Das Ashish Kulshrestha Solveig Ward
Ken Fodero Vahid Madani Dave Weinbach
Juergen Holbach Tony Napikoski James Whatley
Sam Sciacca

The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
William J. Ackerman Jeffrey G. Gilbert Gary L. Michel
Steven C. Alexanderson Sergiu R. Goma Charles A. Morse
Ali Al Awazi Ron K. Greenthaler Brian P. Mugalian,
G. J. Bartok Randall C. Groves Jerry R. Murphy
David L. Bassett Roger A. Hedding Anthony P. Napikoski
Kenneth C. Behrendt Gary A. Heuston Michael S. Newman
Robert W. Beresh Scott J. Hietpas Michael A. Roberts
Oscar E. Bolado Jerry W. Hohn, Charles W. Rogers
Stuart H. Bouchey Dennis Horwitz M. S. Sachdev
Steven R. Brockschink R. Jackson Steven Sano
Juan C. Carreon James H. Jones Michael Scholles
Danila Chernetsov Lars E. Juhlin Thomas Schossig
Keith Chow Piotr Karocki Tony L. Seegers
Tommy P. Cooper Bogdan Z. Kasztenny Mark S. Simon
James R. Cornelison Jim Kulchisky Richard P. Taylor
Ratan Das Ashish Kulshrestha Michael J. Thompson
Matthew T. Davis Solomon Lee Mark A. Tillinghast
Kevin E. Donahoe William G. Lowe Demetrios A. Tziouvaras
Michael J. Dood William Lumpkins Roger L. Whittaker
Gary R. Engmann G. L. Luri Eric V. Woods
Kenneth J. Fodero Vahid Madani Richard C. Young
Marcel Fortin Walter P. McCannon Oren Yuen

vi Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
When the IEEE-SA Standards Board approved this standard on 6 December 2006, it had the following
membership:
Steve M. Mills, Chair
Richard H. Hulett, Vice Chair
Don Wright, Past Chair
Judith Gorman, Secretary

Mark D. Bowman William B. Hopf Greg Ratta

Dennis B. Brophy Joseph L. Koepfinger* Robby Robson
William R. Goldbach David J. Law Anne-Marie Sahazizian
Arnold M. Greenspan Daleep C. Mohla Virginia C. Sulzberger
Robert M. Grow T. W. Olsen
Malcolm V. Thaden
Joanna N. Guenin Glenn Parsons
Ronald C. Petersen Richard L. Townsend
Julian Forster*
Mark S. Halpin Tom A. Prevost Walter Weigel
Kenneth S. Hanus Howard L. Wolfman

*Member Emeritus

Also included are the following nonvoting IEEE-SA Standards Board liaisons:

Satish K. Aggarwal, NRC Representative

Richard DeBlasio, DOE Representative
Alan H. Cookson, NIST Representative

Copyright 2007 IEEE. All rights reserved. vii

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
Contents

1. Overview.............................................................................................................................................. 1

1.1 Scope............................................................................................................................................ 1
1.2 Purpose......................................................................................................................................... 1

2. Definitions and word usage ................................................................................................................. 1

2.1 Definitions ................................................................................................................................... 1

2.2 Word usage .................................................................................................................................. 2

3. Information requirement ...................................................................................................................... 2

3.1 Device model, order code, and serial number ............................................................................. 3

3.2 Firmware version ......................................................................................................................... 3
3.3 Documentation version ................................................................................................................ 3
3.4 Nature of the change .................................................................................................................... 3
3.5 Importance of the change............................................................................................................. 5
3.6 Firmware controller responsibility............................................................................................... 5
3.7 Instructions on how to implement a firmware change................................................................. 5
3.8 Contact mailbox at the manufacturers site or sales company..................................................... 5
3.9 Customer/user contact (firmware controller)............................................................................... 5
3.10 Determination of firmware problem ............................................................................................ 6
3.11 Classification of changes ............................................................................................................. 6
3.12 Testing/validation ........................................................................................................................ 6
3.13 Third-party resellers of Intelligent Electronic Devices................................................................ 6
3.14 Specific recommendations directed towards firmware controllers.............................................. 7
3.15 Specific recommendations directed towards manufacturers ....................................................... 7
3.16 Compatibility of firmware versions ............................................................................................. 8
3.17 Feedback from the end-user to the manufacturer ........................................................................ 8

4. Dissemination of firmware revision information by manufacturers to users ...................................... 8

4.1 Dissemination of notification....................................................................................................... 8

4.2 Availability of on-demand information ....................................................................................... 9

5. Dissemination of firmware revision information by users to manufacturers ...................................... 9

Annex A (informative) Example of a severity rating methodology .............................................................. 10

Annex B (informative) Example of a functional classification scheme ........................................................ 11

Annex C (informative) Bibliography............................................................................................................. 13

viii Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE Recommended Practice for
Microprocessor-Based Protection
Equipment Firmware Control

1. Overview

1.1 Scope

The scope of this recommended practice is to identify the means for timely and efficient exchange of infor-
mation between manufacturers and users of protection-related equipment with respect to (1) changes in
device firmware and (2) the impact of those changes. It will also include an examination of the technical and
operational ramifications resulting from changes in the device firmware. Only hardware changes that impact
firmware changes will be included.

1.2 Purpose

The purpose of this recommended practice is to facilitate the exchange of information between manufactur-
ers and users of microprocessor-based protection equipment on the changes in the firmware and the impact
those changes will have in the performance of the devices.

2. Definitions and word usage

For the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary of
IEEE Standards Terms [B1], should be referenced for terms not defined in this clause.1

2.1 Definitions

2.1.1 acceptance testing: Testing conducted in an operational environment to determine whether a test sub-
ject satisfies its acceptance criteria.

2.1.2 downgrade: To install an older version of firmware or software.

1
The numbers in brackets correspond to those of the bibliography in Annex C.

Copyright 2007 IEEE. All rights reserved. 1

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

2.1.3 end-user: The person who is responsible for the care and maintenance of the protective device. See
also: firmware controller.

2.1.4 fax back: A fax-on-demand system used to provide instant access to a variety of documents, typically
through use of a touch-tone telephone.

2.1.5 firmware controller: The primary point of contact between the manufacturer and the end-user for
communications related to changes to the Intelligent Electronic Device (IED) firmware. This term is used to
refer to the individual who has the responsibility to maintain and keep track of the firmware for protection
devices. This is a generic term and will most likely be different from case-to-case.

2.1.6 order code: A manufacturer-specific code used to describe the particular configuration for the device.

2.1.7 test procedure: A document that defines the implementation of the test plan and describes the meth-
odology for performing the specific test.

2.1.8 upgrade: To install a newer version of firmware or software.

2.2 Word usage

2.2.1 shall: The word shall, equivalent to is required to, is used to indicate mandatory requirements,
strictly to be followed in order to conform to the standard and from which no deviation is permitted.

2.2.2 recommended: The word recommended is used to indicate flexibility of choice with a strong prefer-
ence alternative.

2.2.3 must: The word must is only used to describe unavoidable situations.

2.2.4 should: The word should, equivalent to is recommended that, is used to indicate
a) That, among several possibilities, one is recommended as particularly suitable, without mentioning
or excluding others.
b) That a certain course of action is preferred but not required.
c) That (in the negative form) a certain course of action is deprecated but not prohibited.

2.2.5 may: The word may, equivalent to is permitted, is used to indicate a course of action permissible
within the limits of this standard.

2.2.6 can: The word can, equivalent to is able to, is used to indicate possibility and capability, whether
material or physical.

3. Information requirement

A combination of documentation and procedures are required to ensure the effective dissemination of a
firmware revision. These items may differ from case-to-case or between manufacturers, but it is important
that certain basic information be exchanged with the firmware controller(s). The list of recommended items
includes the device model, order code, serial number, firmware revision, document version, nature of the
change, new features added, impact on settings; application logic; and function, instructions on how to
upgrade, importance of the upgrade, contact personnel, and required hardware/equipment necessary to
implement the change.

2 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

3.1 Device model, order code, and serial number

The firmware controller and the manufacturer shall be clear on exactly what devices are affected. The device
model describes in general terms what equipment may be impacted by a firmware change. The device model
can provide a general flag to the firmware controller who might not be aware of the exact equipment. The
order code specifies the exact configuration of the equipment including current rating, communication
protocol(s) etc. The order code and the model can provide a clear indication of the equipment that may be
affected. Serial numbers can be used to identify specific devices. This obviously necessitates that the
manufacturer has kept detailed records with firmware revisions as shipped, model numbers, serial numbers,
order codes, date, Purchase Order number, etc.

3.2 Firmware version

The firmware version is, simply put, the version of the firmware running on the equipment. The firmware
uses the applied settings to perform the stated functionality of the device. It is critical to know the firmware
version associated with the equipment along with the model number/order code and/or serial number to
correctly identify equipment that may be impacted. A particular firmware correction may be applicable only
to a subset of devices that have a common order code but different firmware versions. A particular version
of firmware could refer to one of several executables within the device.

The firmware version may be identified by a unique identifier code (for example, Ver. 3.1.02) or the
firmware version may be identified by an exact date/time specifier (for example, 12/July/2001 12:03:21
a.m.).

When a microprocessor-based device contains more than one processor, each of the processors will have
their own firmware. Consideration must be given to the interactions between different versions of processor
firmware, as well as the associated record keeping.

3.3 Documentation version

Firmware changes often alter the performance of a device by adding new features, elements, functions,
changing operating ranges, increasing settings ranges, etc. This frequently implies that the original
documentation shipped with the device will no longer be valid. When a firmware change is disseminated,
specific reference should be made to the relevant documentation and supplemental documentation for the
device issued to keep in step with the firmware change. All documentation should have a reference to the
specific firmware version of the equipment for which it is valid.

Manufacturers may wish to update documentation by electronic means or other convenient methods in order
to simplify the process of keeping relevant references in the field. A change in documentation should
accompany (concurrently) any change in firmware when required.

3.4 Nature of the change

The nature of the change(s) in the firmware should accompany any release. The firmware controller needs to
be able to evaluate the relevance and importance of any change and what the impact is on their particular
system or for decisions to migrate to a new firmware for future installations. Along with information
detailing the changes in the firmware, the manufacturer shall also include the impact of such changes on
existing functionality.

The nature of the change may be presented in the form of a revision history or log. This tends to be very
brief and to the point and of course more detailed descriptions may be useful. A table or listing of firmware

Copyright 2007 IEEE. All rights reserved. 3

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

revisions should be available for the device or application. This will help the user to determine the
importance of a specific revision.

If a particular change is minor (e.g., a spelling correction) or introduces new features, a user may not wish to
upgrade their firmware until absolutely necessary due to possible performance changes and their
ramifications.

3.4.1 Other new features introduced

The nature of the upgrade or change shall include a list of modifications and features added (or removed),
and information on how these affect settings and system performance.

3.4.2 Affected function or application

The change in the firmware may impact the performance, application logic, or settings of existing
function(s). The documentation shall include an explanation of any changes to the previously existing
firmware-based functions.

3.4.3 Settings impact

The following questions may be of concern:

a) Are there specific settings changes associated with this release? Some firmware changes will
involve a change in the settings associated with the device. This may take the form of additional set-
tings, a change in the range of specific settings, or an elimination of certain settings. For each type of
setting change, the manufacturer should also provide a recommendation on the testing required (if
any) in order to validate existing settings for in-service devices.
b) Will existing settings still work with the new firmware? The user will want to know if the existing
settings files will work with the updated firmware or if there will be some translation, or changes,
necessary. Will the existing settings need to be re-installed? The manufacturer may supply a conver-
sion program or, as a minimum, list what is necessary to convert existing settings associated with a
specific firmware version to ensure they properly function with the updated firmware.
c) Are new settings clearly presented in the updated documentation? New features, or changes to exist-
ing settings shall be clearly documented so that the firmware controller can determine what the
impact is on the protection.
d) How can the new settings be tested and is it necessary to verify existing settings? A new firmware
change may introduce additional settings or change the ranges of existing ones.
e) Have any features or functions been removed? A list of previously supplied features or functions
that were removed with the new firmware.

3.4.4 Scheme logic and IED interaction changes

It is possible that with a change to the firmware that the internal logic provided by the manufacturer may be
impacted. This shall be clearly noted so that the firmware controller can identify the impact on the
performance of the protection. Subtle changes in the operation of the new firmware should be provided so
that the continued operation of user logic can be verified.

Often an IED is part of an automation scheme in which communications with other devices and systems is a
critical function. Any changes caused by the firmware revision that affects communications (point mapping,
communication parameters, etc.) shall also be noted.

4 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

3.5 Importance of the change

Many firmware controllers might not have the time or the technical background to understand the
implications a particular change might have on their system. In light of this, it is useful to have a rating
system whereby changes can be categorized as severe, important, or minimal, for example. An example of
such a rating scheme can be found in Annex A. A high, or urgent, rating would imply that the firmware
should be upgraded as soon as possible. Two classification schemes are shown in Annex A and Annex B as
possible ways in which to identify the severity of firmware changes.

3.6 Firmware controller responsibility

The manufacturers notice generally lists the changes or features since the previous firmware upgrade
notice. When a decision is made to skip one or a series of firmware upgrades, the firmware controller should
evaluate the earlier release notices in order to determine the impact of the previous changes as well as to
develop a recommended level of testing for the particular firmware being migrated to.

The firmware controller who applies a firmware change to the field device might not be the same individual
as the one corresponding with the manufacturer or the person maintaining records of changes. The firmware
controller might not be a single individual and could be the end-user (field personnel), the engineering
design department, purchasing, or any number of alternatives, or combinations thereof. The firmware
controller is not only responsible for the archival maintenance of the firmware but also for the technical
impact of changes to their system.

3.7 Instructions on how to implement a firmware change

The firmware controller needs to know how to install the firmware. In many cases, the firmware controller
might not have the technical expertise necessary to implement the change and detailed instructions should be
available. This individual needs to know the following:
a) Detailed instructions on how to install the firmware
b) What hardware and software tools are required
c) Location (web site, removable media, etc.) for information/files
d) How to make a backup of existing firmware/settings/etc. prior to changing
e) What software program/utility and version number is required to install the firmware
f) Where help might be obtained.
g) If a specific operating system, type of computer, or communication protocol is required
h) If it is possible to downgrade and restore the original (unchanged) firmware and how
i) If a special cable or connection method is required
j) Detailed instructions on how to verify a correct and complete installation of the new firmware

3.8 Contact mailbox at the manufacturers site or sales company

The manufacturer should provide a central location where inquiries can be made regarding firmware
changes. This may take the form of a mailbox, telephone number, or fax number.

3.9 Customer/user contact (firmware controller)

The company or facility purchasing the protection device should designate a single point of contact to act as
the firmware controller for the specific device. This contact should ensure that the manufacturer has their
current contact information and that periodic checks are made to validate communication with the

Copyright 2007 IEEE. All rights reserved. 5

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

manufacturer. The firmware controller should confirm their registration with the manufacturer and discuss
the most appropriate method of notification.

3.10 Determination of firmware problem

There shall be some method of determining if a particular unit is affected by a firmware revision
necessitated by a defect in the code. In some circumstances, the firmware controller discovers the problem
and notifies the manufacturer. In such cases, the manufacturer may want to know the following:
a) Under what conditions is a defect evident? Is the deficiency clearly visible under test conditions?
b) What is the rate of occurrence? How often does the problem occur?
c) What are the characteristics of performance deficiencies? What specifically is the problem?

It behooves the firmware controller to report any operation/performance issues to the manufacturer so that
changes can be made for the benefit of all users.

3.11 Classification of changes

The table presented in Annex A gives a suggested list of severity ratings for firmware revisions. The list
provides an indication of how important the change is and what action should be taken. A functional
classification scheme is given in Annex B for the purpose of providing practical suggestions to
manufacturers.

3.12 Testing/validation

It is important to determine what testing may need to be conducted by both the manufacturer and the end-
user to validate a change in the firmware. Specific changes may justify re-testing the protection equipment.
The nature of the change will determine to what extent the equipment should be re-tested. Manufacturers
should keep a record of the tests conducted on the revised firmware for reference and provide it to the
firmware controller if requested and if possible.

The following items should be considered in determining the need for testing:
a) What tests have been conducted by the manufacturer, and why
b) What tests should be conducted to commission the protection device with the revised firmware
c) What tests should be conducted to re-validate any type-testing that was performed on the device by
the end-user

3.13 Third-party resellers of Intelligent Electronic Devices

The issue of how firmware changes can be made, or information disseminated by manufacturers if the
protection device is sold through resellers should be considered. The manufacturer loses control over
information regarding who the user may be when the device is sold through third-party resellers. In this case,
the end-user might wish to contact the device manufacturer in order to register and keep current with any
firmware changes. A label or warning sign affixed to the device stating that new owners should contact the
manufacturer for latest updates might be appropriate.

Resellers of protection devices should make provisions to ensure that their customers are fully enrolled in a
firmware revision program as stated in this document. If the reseller elects not to maintain a compliant
program, the reseller should provide an enrollment process for the customer with the original equipment
manufacturer on a pass-through basis.

6 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

3.14 Specific recommendations directed towards firmware controllers

The firmware controller should keep detailed records of all equipment as it arrives. A database or
spreadsheet application may be the best suitable solution to keep track of all the following information:
a) Manufacturer
b) Where the device was purchased
c) Data of purchase
d) In-service date
e) Model of the device
f) Type/order code
g) Serial number(s)
h) Password(s)
i) Destination site
j) Contact person at site
k) Firmware version as purchased
l) History of all firmware changes made by the company (including dates and versions and persons
responsible)
m) Interface software version with a reference pointing to the appropriate firmware version
n) Settings with a key to point to the appropriate firmware version
o) Purchase order number (in order to allow easier tracking by the manufacturer)
p) Location of local documentation in order that the firmware controller can send updates to the appro-
priate locations
q) Previous version of the firmware, settings, and setting software in order to downgrade if necessary
r) For each revision announced by the manufacturer, the action taken by the company: Was the firm-
ware revision installed? Why or why not? Was testing conducted following the firmware revision
change?
s) What, if any, is the impact of the firmware change on fault analysis

3.15 Specific recommendations directed towards manufacturers

Manufacturers should keep detailed records of all equipment that is manufactured. If the manufacturer is not
the supplier to the user, these recommendations should be implemented by each tier in the supply chain. This
includes the following:
a) Model numbers
b) Type/order codes as shipped
c) Serial numbers (including the serial number for each printed circuit board that have firmware related
components)
d) Destination
e) Contact person (name, address, phone, email, fax, title). The contact person should be the firmware
controller
f) Purchase order number from customer
g) All firmware versions released
h) All software versions (keyed to the specific firmware versions)
i) Manufacture dates
j) Ship dates
k) Shipping address

Copyright 2007 IEEE. All rights reserved. 7

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

l) History of released firmware versions

m) History of documentationwhat devices have been changed, when the change took place, and to
what version number

If the manufacturer does not directly supply the device to end-user these recommendations should be
implemented by each tier in the supply chain.

3.16 Compatibility of firmware versions

The issue of compatibility is an important consideration in the process of changing firmware versions. The
manufacturer shall provide sufficient information to the firmware controller to describe any compatibility
and interoperability issues that may exist with other firmware versions. If one device is upgraded (or
downgraded) in a particular scheme then the firmware controller needs to know if all devices must be
upgraded (or downgraded). The firmware controller also needs to know if devices will be able to
communicate over a substation network if specific protection devices have dissimilar firmware versions.

Also, the firmware controller needs to know if a particular firmware change is compatible with the existing
hardware. The manufacturer shall ensure that the firmware controller is clearly warned if a particular
firmware change might not work with a certain version of device hardware. A warning label reading
Caution or Important Notice could be used for this purpose.

If a device uses more than one firmware version due to the presence of multiple processors, for example, the
manufacturer shall inform the firmware controller of any possible incompatibilities that may arise with a
change in one firmware version only.

3.17 Feedback from the end-user to the manufacturer

The manufacturer should keep an accurate up-to-date record of what devices produced have had specific
firmware changes made. This is very important for legal reasons as well as customer satisfaction. It is
important that the end-user communicates back to the manufacturer (or reseller) the fact that a particular
device has had its firmware changed to a certain revision. If there is a change in the firmware controller, the
manufacturer should be informed. Likewise, if the manufacturer changes their method of disseminating
information, the firmware controller should be notified.

4. Dissemination of firmware revision information by manufacturers to

users

Users of protective relaying equipment that includes a software or firmware component need equipment-
specific information to be able to determine if that equipment requires modification to correct any defects or
to incorporate improvements. The manufacturers are the source of that information, and should provide a
means of access to this information to users of their equipment.

There are two primary requirements with respect to this information: dissemination of notification and
availability of on-demand information.

4.1 Dissemination of notification

The first need is for the manufacturer to notify the user of a change. When the need to notify arises, any or
all of the following methods might be used to notify users of an important change to the firmware (in no
particular order):

8 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

a) The firmware controller in consultation with the manufacturer will determine the best method of
communication. This may include physically mailing published information or sending it via fax (or
both). The end-user and the manufacturer should keep accurate records of names and postal
addresses of the people responsible.
b) Electronic mail sent to users
c) Telephone call to users. Telephone calls may be used in critical situations. This would be facilitated
if the manufacturer collected the names of known firmware controllers and maintained the list as
changes are reported.
d) A subscription service or email list so that any new user can join.
e) A central site where customers may periodically check for updates on equipment firmware can be
provided by the manufacturer.

4.2 Availability of on-demand information

The second need is for the user to be able to inquire as to what code is available or recommended for a
particular device. This information should be available to the user at all times, so that it may be accessed as
the need arises.

Possible means of on-demand access include (in no particular order):

a) A public area on the manufacturers website
b) A private (password protected) area on the manufacturers website
c) A clearing-house website that provides data on products from multiple manufacturers
d) A fax-back service (manufacturer or clearing-house)
e) A database distributed or available to users and updated as needed (manufacturer or clearing-house)
f) A telephone, email, or facsimile support line

5. Dissemination of firmware revision information by users to

manufacturers

In a similar vein, it is important that users also feed contact information and defect reports back to the
manufacturer. Notification that a certain device has been modified can be sent back to the manufacturer by
similar means as described in 4.2.

Copyright 2007 IEEE. All rights reserved. 9

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

Annex A
(informative)

Example of a severity rating methodology

This annex proposes a method of classifying problems with device firmware (see Table A.1). The
introduced categories allow quicker evaluation of severity given specific user applications. Also, the
categories allow better dissemination of information within the users organization.

Table A.1Severity ratings

Class Classification Recommendation Importance

1 A dangerous function nonconformity with a Immediate Very high

high potential of danger and damage

2 A critical function nonconformity Immediate High

3 A function nonconformity (high priority Urgent Medium

no work around)

4 A function nonconformity (low priority Optional Medium

work around possible/manual or text
defects)
5 An unimportant function nonconformity Optional Low

6 New or changed feature(s) only Optional Low

7 No functional change No action N/A

10 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

Annex B
(informative)

Example of a functional classification scheme

The manufacturer should report changes in order of descending severity, so that the most potentially
significant problems are listed first.

B.1 Unexpected restart

Unexpected restart results in at least temporary unavailability of operation. More serious consequences are
also possible depending on the function of the device in the broader protection and control system (blocking
signals established by the affected device, action taken by other devices upon unavailability of the affected
device, etc.).

B.2 Unexpected operation

Unexpected operation occurs when a given function changes its state (output flags) without justification in
the input signals given its intended operating principle. The change may be either pickup or dropout
depending on the type of the function. Consequences of problems from this category may be diverse and
depend on the usage of the affected function (tripping, blocking, changing setting groups, etc.).

B.3 Possible failure to operate

A possible failure to operate occurs where a given function appears to function normally, but would fail to
operate when expected. No corrective action is possible before the event. Consequences of problems from
this category may be diverse and depend on the usage of the affected function (tripping, blocking, changing
setting groups, etc.). Operation is defined as a change in the states of the output flags of the function either
pickup or dropout.

B.4 Unavailability of protection

This category includes problems that lead to a failure to operate of one or more functions of the device. The
deficiency must be self-demonstrating and must be signaled by the device by target or display messages,
fail-safe relay, via communication protocols or other means, so that corrective actionseither manual or
automaticcould be taken to rectify the problem. If the problem is not self-demonstrating, it belongs to the
category of hidden failures to operate.

B.5 Protection out of specification

This category includes problems with protection that are less severe than a complete failure to operate or
very high probability of spurious operation. Typical examples are pickup threshold not meeting the
specification, or being off by a constant, timing inaccuracy, slightly delayed operation, incorrect hysteresis,
etc. Consequences of problems in this category may be diverse. For example, a given element may be used
to block protection functions intended for tripping. If this protection element exhibits slow operation then a
false trip may occur.

Copyright 2007 IEEE. All rights reserved. 11

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
IEEE
Std C37.231-2006 IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED

B.6 Metering

This category covers problems with metering functions. Typical problems are equipment accuracy not
meeting the published specification, overflow, wrong multipliers, or switched memory addresses.

B.7 Protocols and communications

This category covers problems related to communication protocols and associated communication means.

B.8 Changed, incomplete, or false records

Problems from this category lead to incomplete or false records. As such they could impact analysis of the
records either manual or automated. These problems may affect operation of the system if the content of the
records is used in real-time to support system operators.

B.9 Changed, incomplete, or false faceplate indications

This category gathers changes related to faceplate of the relay. Typically this includes target indications
(LEDs), display messages, keypad, and pushbuttons. Severity of this category of problems depends
primarily on the way the indicators are used by the operators and field personnel.

B.10 Enhancement

Enhancements are modifications of the existing features that bring new value or functionality for user
applications. Often enhancements introduce new settings, expand ranges of the existing settings, or change
operating principles of the enhanced features.

B.11 Change

This category contains changes that do not rectify any known problems or bring any new value to the
product. Often, these changes are related to changes in hardware driven by part obsolescence or
substitutions, internal optimizations related to memory utilization, or operating systems.

B.12 New feature

Addition of new features shall be signaled to the users who might make an upgrade decision based on
availability of new functions. If the introduction of a new feature affects other functions of the device, the
effects shall be described separately in conjunction with the affected functions.

12 Copyright 2007 IEEE. All rights reserved.

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.
 IEEE
PROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006

Annex C
(informative)

Bibliography
[B1] IEEE 100, The Authoritative Dictionary of IEEE Standards Terms, Seventh Edition.

[B2] IEEE Std 1008TM-1987, IEEE Standard for Software Testing.2, 3

[B3] IEEE Std 1012TM-1998, IEEE Standard for Software Verification and Validation.

[B4] IEEE Std 1061TM-1998, IEEE Standard for a Software Quality Metrics Methodology.

[B5] IEEE Std 1465TM-1998 (ISO/IEC 12119): IEEE StandardAdoption of International Standard ISO/
IEC 12119:1994(E)Information TechnologySoftware PackagesQuality Requirements and Testing.

[B6] IEEE Std C37.100TM-1992 (Reaff 2001) IEEE Standard Definitions for Power Switchgear.

[B7] IEEE/EIA 12207.1-1997, Industry Implementation of International Standard ISO/IEC 12207:1995:

Information TechnologySoftware Lifecycle Processes.

[B8] MIL-STD-1629A, Procedures For Performing A Failure Mode, Effects And Criticality Analysis.4

[B9] NIST Special Publication 500-234, Reference Information for the Software Verification and Validation
Process.

2
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.
3IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA (http://standards.ieee.org/).
4
MIL publications are available from Customer Service, Defense Printing Service, 700 Robbins Ave., Bldg. 4D, Philadelphia, PA
19111-5094.

Copyright 2007 IEEE. All rights reserved. 13

Authorized licensed use limited to: CHILECTRA. Downloaded on October 25,2010 at 14:51:06 UTC from IEEE Xplore. Restrictions apply.