1、IEEE Std C37.231-2006IEEE Recommended Practice forMicroprocessor-Based ProtectionEquipment Firmware ControlI E E E3 Park Avenue New York, NY10016-5997, USA6 June 2007IEEE Power Engineering SocietySponsored by thePower System Relaying CommitteeIEEE Std C37.231-2006(R2012)IEEE Recommended Practice for
2、 Microprocessor-Based Protection Equipment Firmware ControlSponsor Power Systems Relaying Committee of theIEEE Power Engineering SocietyApproved 12 June 2006Reaffirmed 29 March 2012IEEE SA-Standards BoardThe Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-599
3、7, USACopyright 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 +1 978 750 8400. Permission to photocopy portions of any individual standard for ed
4、ucational classroom use can also be obtained through the Copyright Clearance Center. iv Copyright 2007 IEEE. All rights reserved.IntroductionIn the past few years, the technology used for the protection of the power system has evolved fromelectromechanical devices, to solid state, to microprocessor-
5、based devices. Electromechanical devices hadthe inherent characteristic that their behavior was dependant upon physical or mechanical propertiesdetermined by the laws of physics. With the introduction of solid-state technology into protection andcontrol, the earlier generation of microprocessor-base
6、d protective devices were developed and applied.Feature enhancements or product deficiencies were addressed by installing new integrated circuits or printedcircuit board upgrades. Todays microprocessor-based devices, however, are mostly controlled by thefirmware or code that instructs the device how
7、 to operate and perform. Firmware refers to programmingcode that is based on the internal operating paradigms of the microprocessor, or microcontroller, being usedin the particular application. This code is based on the specific performance desired from the device and istypically stored in read-only
8、 memory. A certain DSP may be used for an automotive application in oneinstance, a business-related application in a second instance, and a protective relaying function in a thirdinstance. What distinguishes the application is the firmware code written to control the processor (orprocessing chip) be
9、ing used. The implementation of the desired functionality is not based on the hardware construction of a physicaldevice (as with the electromechanical device) but on the algorithms coded by the programmers. This leads toa wealth of different ways of implementing specific functions such as filtering,
10、 anti-aliasing, protection,metering, and combinations thereof. Over time the manufacturer may want to augment existing functionalityby adding new features, such as changing the range/performance of certain functions, or correcting certaindeficiencies found in the performance of the device. All of th
11、is leads to the possibility of a firmware change.The reality of a firmware change for existing devices can have vast and far reaching implications. Questionsarise such as: How important is the change? Is the firmware change compatible with existing devices? Howimportant or critical is the new firmwa
12、re 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 associatedwith changing firmware in ex
13、isting 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 otherconsumer products, recall notices and information bulletins are realities of
14、doing business. In some cases,due diligence may have to be exercised in order to avoid legal implication, for example, in cases where aproduct 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
15、 not be the sameindividual as the one corresponding with the manufacturer or the field personnel who actually commissionsthe device, the term firmware controller is used in this document to refer to the individual who has theresponsibility to maintain the firmware for protection devices. The firmwar
16、e controller could be the end-user(field personnel), the engineering design department, purchasing, or any number of alternatives (as practicesvary among users). The firmware controller will most likely be different from case-to-case and is a genericterm in this document.This introduction is not par
17、t of IEEE Std C37.231-2006, IEEE Recommended Practice for Microprocessor-BasedProtection Equipment Firmware Control.Copyright 2007 IEEE. All rights reserved. vNotice to usersErrataErrata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/
18、ieee/updates/errata/index.html. Users are encouraged to check this URL forerrata periodically.InterpretationsCurrent interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/index.html.PatentsAttention is called to the possibility that implementation of this
19、 standard may require use of subject mattercovered by patent rights. By publication of this standard, no position is taken with respect to the existence orvalidity of any patent rights in connection therewith. The IEEE shall not be responsible for identifyingpatents or patent applications for which
20、a license may be required to implement an IEEE standard or forconducting inquiries into the legal validity or scope of those patents that are brought to its attention.vi Copyright 2007 IEEE. All rights reserved.ParticipantsAt the time this recommended practice was completed, the I3 Working Group had
21、 the followingmembership: Robert W. Beresh, ChairRoger L. Whittaker, Vice-ChairThe following members of the individual balloting committee voted on this standard. Balloters may havevoted for approval, disapproval, or abstention. Gustavo BrunelloDac-Phuoc BuiRatan DasKen FoderoJuergen HolbachGerald J
22、ohnsonBogdan KasztennyAshish KulshresthaVahid MadaniTony NapikoskiSam SciaccaVeselin SkendzicMichel ToupinSolveig WardDave WeinbachJames WhatleyWilliam J. AckermanSteven C. AlexandersonAli Al AwaziG. J. BartokDavid L. BassettKenneth C. BehrendtRobert W. BereshOscar E. BoladoStuart H. BoucheySteven R
23、. BrockschinkJuan C. CarreonDanila ChernetsovKeith ChowTommy P. CooperJames R. CornelisonRatan DasMatthew T. DavisKevin E. DonahoeMichael J. DoodGary R. EngmannKenneth J. FoderoMarcel FortinJeffrey G. GilbertSergiu R. GomaRon K. GreenthalerRandall C. GrovesRoger A. HeddingGary A. HeustonScott J. Hie
24、tpasJerry W. Hohn,Dennis HorwitzR. JacksonJames H. JonesLars E. JuhlinPiotr KarockiBogdan Z. KasztennyJim KulchiskyAshish KulshresthaSolomon LeeWilliam G. LoweWilliam LumpkinsG. L. LuriVahid MadaniWalter P. McCannonGary L. MichelCharles A. MorseBrian P. Mugalian,Jerry R. MurphyAnthony P. NapikoskiMi
25、chael S. NewmanMichael A. RobertsCharles W. RogersM. S. SachdevSteven SanoMichael SchollesThomas SchossigTony L. SeegersMark S. SimonRichard P. TaylorMichael J. ThompsonMark A. TillinghastDemetrios A. TziouvarasRoger L. WhittakerEric V. WoodsRichard C. YoungOren YuenCopyright 2007 IEEE. All rights r
26、eserved. viiWhen the IEEE-SA Standards Board approved this standard on 6 December 2006, it had the followingmembership:Steve M. Mills, ChairRichard H. Hulett, Vice ChairDon Wright, Past ChairJudith Gorman, Secretary*Member EmeritusAlso included are the following nonvoting IEEE-SA Standards Board lia
27、isons:Satish K. Aggarwal, NRC RepresentativeRichard DeBlasio, DOE RepresentativeAlan H. Cookson, NIST RepresentativeMark D. BowmanDennis B. BrophyWilliam R. GoldbachArnold M. GreenspanRobert M. GrowJoanna N. GueninJulian Forster*Mark S. HalpinKenneth S. HanusWilliam B. HopfJoseph L. Koepfinger*David
28、 J. LawDaleep C. MohlaT. W. OlsenGlenn ParsonsRonald C. PetersenTom A. PrevostGreg RattaRobby RobsonAnne-Marie SahazizianVirginia C. SulzbergerMalcolm V. ThadenRichard L. TownsendWalter WeigelHoward L. Wolfmanviii Copyright 2007 IEEE. All rights reserved.Contents1. Overview 11.1 Scope 11.2 Purpose.
29、12. Definitions and word usage . 12.1 Definitions . 12.2 Word usage 23. Information requirement 23.1 Device model, order code, and serial number . 33.2 Firmware version . 33.3 Documentation version 33.4 Nature of the change 33.5 Importance of the change. 53.6 Firmware controller responsibility. 53.7
30、 Instructions on how to implement a firmware change. 53.8 Contact mailbox at the manufacturers site or sales company. 53.9 Customer/user contact (firmware controller). 53.10 Determination of firmware problem 63.11 Classification of changes . 63.12 Testing/validation 63.13 Third-party resellers of In
31、telligent Electronic Devices 63.14 Specific recommendations directed towards firmware controllers 73.15 Specific recommendations directed towards manufacturers . 73.16 Compatibility of firmware versions. 83.17 Feedback from the end-user to the manufacturer 84. Dissemination of firmware revision info
32、rmation by manufacturers to users 84.1 Dissemination of notification. 84.2 Availability of on-demand information . 95. Dissemination of firmware revision information by users to manufacturers 9Annex A (informative) Example of a severity rating methodology 10Annex B (informative) Example of a functio
33、nal classification scheme 11Annex C (informative) Bibliography. 13Copyright 2007 IEEE. All rights reserved. 1IEEE Recommended Practice for Microprocessor-Based Protection Equipment Firmware Control1. Overview1.1 ScopeThe scope of this recommended practice is to identify the means for timely and effi
34、cient exchange of infor-mation between manufacturers and users of protection-related equipment with respect to (1) changes indevice firmware and (2) the impact of those changes. It will also include an examination of the technical andoperational ramifications resulting from changes in the device fir
35、mware. Only hardware changes that impactfirmware changes will be included.1.2 PurposeThe 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 impactthose
36、changes will have in the performance of the devices.2. Definitions and word usageFor the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary ofIEEE Standards Terms B1, should be referenced for terms not defined in this clause.12.1 Definitions2.1.1 accep
37、tance 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.1The numbers in brackets correspond to those of the bibliography in Annex C.IEEEStd C37.231-2006
38、IEEE RECOMMENDED PRACTICE FOR MICROPROCESSOR-BASED2 Copyright 2007 IEEE. All rights reserved.2.1.3 end-user: The person who is responsible for the care and maintenance of the protective device. Seealso: firmware controller.2.1.4 fax back: A fax-on-demand system used to provide instant access to a va
39、riety of documents, typicallythrough use of a touch-tone telephone.2.1.5 firmware controller: The primary point of contact between the manufacturer and the end-user forcommunications related to changes to the Intelligent Electronic Device (IED) firmware. This term is used torefer to the individual w
40、ho has the responsibility to maintain and keep track of the firmware for protectiondevices. 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 d
41、ocument 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 require
42、ments,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
43、.2.2.4 should: The word should, equivalent to “is recommended that,” is used to indicatea) That, among several possibilities, one is recommended as particularly suitable, without mentioningor excluding others.b) That a certain course of action is preferred but not required.c) That (in the negative f
44、orm) 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 permissiblewithin the limits of this standard.2.2.6 can: The word can, equivalent to “is able to,” is used to indicate possibility and capabi
45、lity, whethermaterial or physical.3. Information requirementA combination of documentation and procedures are required to ensure the effective dissemination of afirmware revision. These items may differ from case-to-case or between manufacturers, but it is importantthat certain basic information be
46、exchanged with the firmware controller(s). The list of recommended itemsincludes the device model, order code, serial number, firmware revision, document version, nature of thechange, new features added, impact on settings; application logic; and function, instructions on how toupgrade, importance o
47、f the upgrade, contact personnel, and required hardware/equipment necessary toimplement the change.IEEEPROTECTION EQUIPMENT FIRMWARE CONTROL Std C37.231-2006Copyright 2007 IEEE. All rights reserved. 33.1 Device model, order code, and serial numberThe firmware controller and the manufacturer shall be
48、 clear on exactly what devices are affected. The devicemodel describes in general terms what equipment may be impacted by a firmware change. The device modelcan provide a general flag to the firmware controller who might not be aware of the exact equipment. Theorder code specifies the exact configur
49、ation of the equipment including current rating, communicationprotocol(s) etc. The order code and the model can provide a clear indication of the equipment that may beaffected. Serial numbers can be used to identify specific devices. This obviously necessitates that themanufacturer has kept detailed records with firmware revisions as shipped, model numbers, serial numbers,order codes, date, Purchase Order number, etc.3.2 Firmware versionThe firmware version is, simply put, the version of the firmware running on the equipment. The firmwareuses the applied settings to p
