欢迎来到麦多课文档分享! | 帮助中心 海量文档,免费浏览,给你所需,享你所想!
麦多课文档分享
全部分类
  • 标准规范>
  • 教学课件>
  • 考试资料>
  • 办公文档>
  • 学术论文>
  • 行业资料>
  • 易语言源码>
  • ImageVerifierCode 换一换
    首页 麦多课文档分享 > 资源分类 > PDF文档下载
    分享到微信 分享到微博 分享到QQ空间

    IEEE C37 231-2006 en Recommended Practice for Microprocessor-Based Protection Equipment Firmware Control《基于微处理机的保护设备固件控制用实施规程》.pdf

    • 资源ID:1249081       资源大小:393.93KB        全文页数:23页
    • 资源格式: PDF        下载积分:10000积分
    快捷下载 游客一键下载
    账号登录下载
    微信登录下载
    二维码
    微信扫一扫登录
    下载资源需要10000积分(如需开发票,请勿充值!)
    邮箱/手机:
    温馨提示:
    如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
    如需开发票,请勿充值!如填写123,账号就是123,密码也是123。
    支付方式: 支付宝扫码支付    微信扫码支付   
    验证码:   换一换

    加入VIP,交流精品资源
     
    账号:
    密码:
    验证码:   换一换
      忘记密码?
        
    友情提示
    2、PDF文件下载后,可能会被浏览器默认打开,此种情况可以点击浏览器菜单,保存网页到桌面,就可以正常下载了。
    3、本站不支持迅雷下载,请使用电脑自带的IE浏览器,或者360浏览器、谷歌浏览器下载即可。
    4、本站资源下载后的文档和图纸-无水印,预览文档经过压缩,下载后原文更清晰。
    5、试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。

    IEEE C37 231-2006 en Recommended Practice for Microprocessor-Based Protection Equipment Firmware Control《基于微处理机的保护设备固件控制用实施规程》.pdf

    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


    注意事项

    本文(IEEE C37 231-2006 en Recommended Practice for Microprocessor-Based Protection Equipment Firmware Control《基于微处理机的保护设备固件控制用实施规程》.pdf)为本站会员(explodesoak291)主动上传,麦多课文档分享仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文档分享(点击联系客服),我们立即给予删除!




    关于我们 - 网站声明 - 网站地图 - 资源地图 - 友情链接 - 网站客服 - 联系我们

    copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
    备案/许可证编号:苏ICP备17064731号-1 

    收起
    展开