1、Developing a PipelineSupervisory Control CenterAPI RECOMMENDED PRACTICE 1113FIRST EDITION, AUGUST 2007REAFFIRMED, JUNE 2012Developing a PipelineSupervisory Control CenterPipeline SegmentAPI RECOMMENDED PRACTICE 1113FIRST EDITION, AUGUST 2007REAFFIRMED, JUNE 2012Special NotesAPI publications necessar
2、ily 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 APIs employees, subcontractors, consultants, committees, or other assignees make any warranty or representation, either express
3、 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 results of such use, of any information or process disclosed in this publication. Neither API nor any of APIs employees, subcontra
4、ctors, consultants, or other assignees represent that use of this publication would not infringe upon privately owned rights.Classified areas may vary depending on the location, conditions, equipment, and substances involved in any given situation. Users of this recommended practice should consult w
5、ith the appropriate authorities having jurisdiction.Users of this recommended practice should not rely exclusively on the information contained in this document. Sound buisiness, scientific, engineering, and safety judgment should be used in employing the information contained herein.API publication
6、s may be used by anyone desiring to do so. Every effort has been made by the Institute to assure 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 l
7、iability or responsibility for loss 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 pu
8、blications are not intended to obviate 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 mar
9、king equipment or materials in conformance 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.Al
10、l rights reserved. No part of this work may be reproduced, 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, N.W
11、., Washington, D.C. 20005.Copyright 2007 American Petroleum InstituteForewordNothing 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 shoul
12、d anything contained 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 o
13、r that which is advised 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 interpr
14、etation of the content 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, N.W., Washington, D.C. 20005. Requests for permission to
15、reproduce or translate 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
16、 the publication can be ascertained from the API Standards Department, telephone (202) 682-8000. A catalog of API publications and materials is published annually and updated quarterly by API, 1220 L Street, N.W., Washington, D.C. 20005.Suggested revisions are invited and should be submitted to the
17、Standards Department, API, 1220 L Street, NW, Washington, D.C. 20005, standardsapi.org.iiiContentsPage1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Scope . . . . . . . .
18、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19、 . . . . . . . . . . . 11.3 How to Use This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Applicable References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20、. . . . . . . . . . . . . . . . . . . . . 23 Definition of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Developing System Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Developing System Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Developing Disaster Recovery Capability . . . . . . . . . . . . . . . . . . . .
22、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Developing the Control Room Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Developing the Data-recording System . . . . . . . . . . . . . . . . . . . . . . . .
23、. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9v1Developing a Pipeline Supervisory Control Center1 General1.1 ScopeA pipeline supervisory control center is a facility where the function of centralized monitoring and controlling of a pipeline system occurs. This document focuses on the
24、design aspects that may be considered appropriate for developing or revamping a control center. There are five sections (Sections 2 through 6) that provide lists of general considerations.This document is not all-inclusive. It is intended to cover best practices and provide guidelines for developing
25、 a control center only. It does not dictate operational control philosophy or overall SCADA system functionality.This document was created by an API Cybernetics Subcommittee task force, based on industry practices used on liquid pipeline SCADA systems. The document is intended to apply to control ce
26、nters for liquids pipelines; however, many of the considerations may also apply to gas control center design.1.2 PurposeThe purpose of this document is to assist the SCADA system designer in identifying issues relevant to the development or redevelopment of a control center.It is recognized that eac
27、h pipeline company has unique operating philosophies and SCADA systems; therefore, not all elements of this document may be applicable. For example: Some pipeline control centers are a combination of several different SCADA systems. Some of these SCADA systems may not have the developer tools necess
28、ary to implement the consideration. Some operators may have existing control center design philosophies/techniques that bridge over into unique operating philosophies. Regulatory and individual company standards are not addressed in this document.1.3 How to Use This DocumentThe “decisions to conside
29、r” points that are written in Sections 2 through 6, do not need to be considered in the order they are presented (i.e. in numerical order). The lists are not all-inclusive but should help stimulate further, detailed analysis.The reader should have a good working knowledge of pipeline operations and
30、control center design philosophies/techniques, and may have to refer to other documents for background or additional information. Any references to SCADA and control center security have been removed and the reader should refer to API 1164 for best practices and guidelines.2API RECOMMENDED PRACTICE
31、11132 Applicable ReferencesAPI Std 1164, Pipeline SCADA SecurityAPI RP 1165, Recommended Practice for Pipeline SCADA Displays3 Definition of TermsSome of the terms used in this document are defined below.3.1 API American Petroleum Institute. The primary trade association of the oil and natural gas i
32、ndustry, API represents more than 400 members involved in all aspects of the oil and natural gas industry. The association draws on the experience and expertise of members and staff to support a strong and viable oil and natural gas industry.3.2 API Cybernetics Subcommittee The API Cybernetics Subco
33、mmittee monitors the field of science concerned with processes of communication and control to provide education and recommended practices to the pipeline industry for monitoring and operating pipelines from a remote location.3.3 control center Physical location where controllers monitor and control
34、 the pipeline systems. A control center typically consists of one or more controller consoles which are manned 24 hours a day/ 365 days a year.3.4 controller The terms “dispatcher,” “operator,” and “controller” all refer to the individual who is responsible for supervisory control of the pipeline. N
35、OTE The term “controller” is used in this document.3.5 distributed computer system A system that involves multiple computers, possibly remote from each other, that each has a role in a computation problem or information processing. 3.6 EDI Electronic data interchange, such as WANs, LANs, Internet, e
36、tc.3.7 fail-over A transfer of control from one component to a backup.3.8 PLC Programmable logic controller (see also RTU below).DEVELOPING A PIPELINE SUPERVISORY CONTROL CENTER 33.9 publish/subscribeclient/server A technique in which all processes and devices that supply data “publish” it to the ne
37、twork, and components which require data “subscribe” to it, with the actual supply of the data managed by a broker.3.10 RTU Remote terminal unit. NOTE SCADA systems gather data from field instrumentation using such data acquisition devices known as Remote Terminal Units (RTU), Programmable Logic Con
38、trollers (PLC), Field Data Acquisition Servers (FDA), and/or Flow Computers (FC). Each of these data acquisition devices may be interchanged for specific applications on the pipeline system.3.11 SCADA Supervisory Control and Data Acquisition, a computer based system in which the Data Acquisition fun
39、ction includes gathering real-time data through a communication network and control functions include controlling field devices.NOTE SCADA processes, displays, and/or may archive data, and provides warnings and alarms to the Pipeline Controller.3.12 UPS Uninterrupted power supply.4 Developing System
40、 ArchitectureControl center architecture considers all the hardware aspects that will be employed and also generically the software that will be employed whether it is developed in-house or purchased from a SCADA system vendor.Item Decisions to Consider4.1 Decide whether to install a centralized sys
41、tem or a decentralized system.4.2 Decide whether to use a single computer system or a distributed computer system.4.3 Decide if the system will have a hot, warm or cold standby configuration and, if so, which components will be used in that configuration.4.4 Determine which computer operating system
42、s are acceptable.4.5 Consider using a real-time/historical database system that is compatible with the corporate database system.4.6 Consider capabilities for on-line training and maintenance.4.7 Consider capabilities of off-line development, testing and/or simulation system.4.8 Consider whether to
43、use “smart” field devices such as microprocessor-based RTUs, flow computers, PLCs, and smart instrumentation devices.4.9 Consider the data requirements of each of the groups of users throughout the organization before setting up the architecture and processes for accessing SCADA/field data. Consider
44、 whether each data user will communicate directly with the field device or will access field data through the SCADA system.4API RECOMMENDED PRACTICE 11134.10 Consider system loading/capacity to allow for optimum system performance and plan for any required expansion. Determine which, if any, functio
45、ns should be distributed to the field to best allow for speed, accuracy, and future expansion. Examples of this would be PLC control and digital/analog deadbanding at the field device.4.11 Consider the option of using a publish/subscribeclient/server approach to facilitate data sharing.4.12 Consider
46、 the software structure or architecture and the ease with which future features and functionality could be added to it.4.13 Consider where system safety/shutdown functions will be performed.4.14 Determine data-transmission protocol and determine whether standard protocols between various computers,
47、remote terminal units, and programmable logic controllers will be enforced.4.15 Determine whether remote communication will be by means of satellite or by terrestrial means, such as leased lines, microwave, frame relay, MPLS, spread spectrum or high-frequency radio, manual entry or non-telemetered d
48、ata, “dial-up,” and “manual with hand-held devices.”4.16 Determine whether backup remote communication is required, and if so, which technology will be used.4.17 Consider using an EDI to link with external information systems.4.18 Consider data integration with management information systems and pow
49、er optimization systems. Applicable areas of data integration that might be considered could include integration with, for example, volumetric accounting systems, revenue accounting systems, system inventories, work order systems, operational analysis systems, root cause failure analysis, measurement systems, logistics/scheduling systems, etc.4.19 Consider data integration with leak-detection, batch-tracking systems and other external applications of the SCADA system.4.20 Consider remote access to the SCADA system for users and/or maintenance personnel.4.21 Decide whether or ho
