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