ImageVerifierCode 换一换
格式:PDF , 页数:48 ,大小:566.58KB ,
资源ID:429696      下载积分:5000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-429696.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(API RP 1167-2016 Pipeline SCADA Alarm Management (Second Edition).pdf)为本站会员(arrownail386)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

API RP 1167-2016 Pipeline SCADA Alarm Management (Second Edition).pdf

1、Pipeline SCADA Alarm ManagementAPI RECOMMENDED PRACTICE 1167SECOND EDITION, JUNE 2016Special Notes API publications necessarily address problems of a general nature. With respect to particular circumstances, local, state, and federal laws and regulations should be reviewed. Neither API nor any of AP

2、Is employees, subcontractors, consultants, committees, or other assignees make any warranty or representation, either express or implied, with respect to the accuracy, completeness, or usefulness of the information contained herein, or assume any liability or responsibility for any use, or the resul

3、ts of such use, of any information or process disclosed in this publication. Neither API nor any of APIs employees, subcontractors, consultants, or other assignees represent that use of this publication would not infringe upon privately owned rights. API publications may be used by anyone desiring t

4、o do so. Every effort has been made by the Institute to ensure the accuracy and reliability of the data contained in them; however, the Institute makes no representation, warranty, or guarantee in connection with this publication and hereby expressly disclaims any liability or responsibility for los

5、s or damage resulting from its use or for the violation of any authorities having jurisdiction with which this publication may conflict. API publications are published to facilitate the broad availability of proven, sound engineering and operating practices. These publications are not intended to ob

6、viate the need for applying sound engineering judgment regarding when and where these publications should be utilized. The formulation and publication of API publications is not intended in any way to inhibit anyone from using any other practices. Any manufacturer marking equipment or materials in c

7、onformance with the marking requirements of an API standard is solely responsible for complying with all the applicable requirements of that standard. API does not represent, warrant, or guarantee that such products do in fact conform to the applicable API standard. All rights reserved. No part of t

8、his work may be reproduced, translated, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission from the publisher. Contact the publisher, API Publishing Services, 1220 L Street, NW, Washington, DC 200

9、05. Copyright 2016 American Petroleum Institute Foreword Nothing contained in any API publication is to be construed as granting any right, by implication or otherwise, for the manufacture, sale, or use of any method, apparatus, or product covered by letters patent. Neither should anything contained

10、 in the publication be construed as insuring anyone against liability for infringement of letters patent. Shall: As used in a standard, “shall” denotes a minimum requirement in order to conform to the specification. Should: As used in a standard, “should” denotes a recommendation or that which is ad

11、vised but not required in order to conform to the specification. This document was produced under API standardization procedures that ensure appropriate notification and participation in the developmental process and is designated as an API standard. Questions concerning the interpretation of the co

12、ntent of this publication or comments and questions concerning the procedures under which this publication was developed should be directed in writing to the Director of Standards, American Petroleum Institute, 1220 L Street, NW, Washington, DC 20005. Requests for permission to reproduce or translat

13、e all or any part of the material published herein should also be addressed to the director. Generally, API standards are reviewed and revised, reaffirmed, or withdrawn at least every five years. A one-time extension of up to two years may be added to this review cycle. Status of the publication can

14、 be ascertained from the API Standards Department, telephone (202) 682-8000. A catalog of API publications and materials is published annually by API, 1220 L Street, NW, Washington, DC 20005. Suggested revisions are invited and should be submitted to the Standards Department, API, 1220 L Street, NW,

15、 Washington, DC 20005, standardsapi.org. iiiContents1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . . . . . .

16、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Terms, Definitions, and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . .

17、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.2 Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Alarm Management Pl

18、an. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Alarm Philosophy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19、65.1 Alarm Philosophy Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65.2 Alarm Philosophy Use and Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20、 . . . . 76 Alarm Application and Determination. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86.1 General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21、 . . . . . . . . . . 86.2 Alarm Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96.3 Purpose and Use of Alarm Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22、 . . . . . . . . . . . . . . . . . . . . 96.4 Diagnostic Alarm Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.5 Safety-related Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106.6 Other Uses of the Alarm System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Alarm Documentation and Rationalization. . . . . . . . . . . . . . . . . .

24、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.2 Documentation alarm selection and configuration; alarm

25、 system performance monitoring; procedures or work processes for resolution of alarm problems; methods for alarm rationalization and priority determination; alarm detection, presentation, annunciation, navigation, and controller interface; alarm documentation, including controller response to alarms

26、; considerations for alarms routed to multiple controllers/locations; alarm handling methods; defined alarm design topics that are “up-front” decisions regarding the consistent implementation practices to be followed for the configuration of certain types of alarms; alarm system maintenance and test

27、ing; alarm system management of change (MOC); alarm system training; alarm system improvement process; alarm system roles and responsibilities; 8 API RECOMMENDED PRACTICE 1167 alarm system audit; definitions (not included in “alarm definition and principles” above) and references; alarm system train

28、ing for noncontrol center personnel (e.g. staff, control system technicians, etc.). The alarm philosophy should be based on several key principles as follows: The alarm system is to be designed to notify the controller of events requiring a response. Alarms are not a substitute for the controllers r

29、outine monitoring of a pipeline or facility operation. Controllers are trained on the alarm management strategy. Proper alarm management enhances the controllers ability to make a decision using experience, skill, and available information. Alarm priorities define the order of the controllers respon

30、se. The alarm system is routinely maintained. Controllers respond to all alarms, regardless of priority. The system design, therefore, should not produce more alarms than those to which the controller can respond. Alarms are not created solely upon the assumption that the controller will fail to res

31、pond to a different alarm. NOTE Some of these may also be addressed in other company documents, such as operating procedures or engineering standards. An alarm philosophy document need not be specific to a particular type of SCADA system as the principles and concepts are system independent. It is c

32、ommon to have SCADA system-specific appendices to the philosophy (or separate documents) that translate the principles to the particular features, capabilities, and limitations of a particular SCADA system. Consideration should be given to each of the mentioned topics when preparing an alarm philoso

33、phy document. 6 Alarm Application and Determination 6.1 General Considerations SCADA systems are structured to manage more than just alarms. A typical SCADA system structure may consist of alarms, alerts, and nonannunciated events. The primary focus of this document is on alarms because alarms have

34、a significant importance in safely and effectively operating the pipeline. Alerts are used to drive awareness. The pipeline operator may choose to present alerts on a separate display or on the same display as alarms but with a lower priority. Nonannunciated events are configured similarly to an ala

35、rm, yet are not annunciated to the controller. Properly implemented alarm systems play a key role in safe and effective pipeline operations. Improperly implemented, maintained, or overloaded alarm systems can significantly detract from the controllers ability to accomplish effective operations and h

36、andle nonnormal conditions. Alarms are used to indicate the need for controller action to return the pipeline to normal and safe operation or to avoid automated shutdowns. Alarms may also indicate the need for controller action in response to operational changes in hydraulics, volume measurement, or

37、 product quality operating situations. PIPELINE SCADA ALARM MANAGEMENT 9 The alarm system should be designed, configured, implemented, maintained, and managed in order to be an effective tool that assists in the controllers response. Note that all references to alarms in this document exclude alerts

38、 and nonannunciated events. There are separate sections that define the use of these functions. All other information that is not an alarm, alert, or nonannunciated event should be excluded from the alarm system because it dilutes the importance of actual alarms. Such information can be more properl

39、y conveyed to the controller via a variety of other methods in the human-machine interface (HMI). 6.2 Alarm Determination For alarms to have significance, alarms must be clearly distinguishable from alerts and from other information annunciated to the controller that does not adhere to the definitio

40、n of an alarm. The following characteristics are desirable for achieving effective alarm management: each alarm should require controller action; each alarm should be clear, meaningful, and relevant to the tasks of the controller; alarms should be properly chosen, designed, and implemented; each ala

41、rm should be documented and have a defined response; a single event should not produce multiple alarms signifying essentially the same thing; alarms should not activate during routine pipeline variable changes or from normal, expected modes of operation that do not require additional controller acti

42、on; alarms should be designed to give the controller appropriate time to respond to the alarmed situation; alarms should be configured consistently; alarm rates should be within the handling capability of the controller; alarms should be prioritized in a manner that indicates their importance; the a

43、larm system should perform as a useful tool for the controller in all operating modes and upset conditions; alarm systems should be properly controlled, monitored, and maintained. 6.3 Purpose and Use of Alarm Priority Alarm priority indicates the relative importance of an alarm compared with other a

44、larms. An effective alarm system uses multiple alarm priorities, which are clearly indicated to the controller. Consideration should be given to the several principles addressed below when determining the number and characteristics of the different alarm priorities. The determination of an alarms pr

45、iority should be accomplished in a consistent fashion. Consider the following characteristics when defining priorities: Each alarm priority should display in its own unique color. Each alarm priority should have its own sound. 10 API RECOMMENDED PRACTICE 1167 Alarms should present on an alarm summar

46、y type display and when appropriate on the controllers graphic displays. Unacknowledged alarms should have a different appearance than acknowledged alarms. No more than four alarm priorities are recommended. Table B.1 is an example of distribution of percentages of alarms (configured and occurring)

47、a pipeline operator might use, with four alarm priorities. In general, for higher priorities to have significance, they must be used sparingly. 6.4 Diagnostic Alarm Priority Diagnostic alarms indicate a malfunction of a sensor or similar hardware. These are conditions about which the controller need

48、s to know. Sensor malfunction may be a serious condition requiring a variety of controller actions. In many cases, however, only very limited controller action is desirableaction such as initiating a routine maintenance work request or a routine callout. The use of a separate priority for indication

49、 of such less serious conditions is often useful, since such alarms can be dealt with less urgently than other alarms in high alarm rate, upset situations. Some SCADA control systems allow for the temporary “filtering out” of such a priority. 6.5 Safety-related Alarms Safety-related alarms are those that specifically indicate that pipeline equipment or operating conditions are outside pipeline operator-defined safety-related parameters. Federal regulations 49 CFR 192 and 195 specify certain require

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