BP RP30-4

RP 30-4 INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS - SYSTEM DESIGN AND CONFIGURATION GUIDELINES
February 1998
Copyright The British Petroleum Company p.l.c.
Copyright The British Petroleum Company p.l.c.

All rights reserved. The information contained in this document is subject to the terms and conditions of the agreement or contract under which the document was supplied to the recipient's organisation. None of the information contained in this document shall be disclosed outside the recipient's own organisation without the prior written permission of Manager, Standards, BP International Limited, unless the terms of such agreement or contract expressly allow.
BP GROUP RECOMMENDED PRACTICES AND SPECIFICATIONS FOR ENGINEERING Issue Date Doc. No.
February 1998
RP 30-4
Latest Amendment Date
Document Title
INSTRUMENT AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS

- SYSTEM DESIGN AND CONFIGURATION GUIDELINES
APPLICABILITY Regional Applicability: SCOPE AND PURPOSE This Recommended Practice provides a guide for selection and use of Control and Data Acquisition Systems for the control and monitoring of production and process plant, storage facilities, pipelines and other installations handling flammable gasses, liquids and other materials. Its purpose is to provide design engineers and plant management with:(a) (b) (c) guidance on the need and applicability of Control and Data Acquisition Systems. a basis for designing, evaluating and selecting and making best use of Control and Data Acquisition Systems for various duties. guidance on health and safety aspects associated with the design, installation and operation of Control and Data Acquisition Systems.
International
AMENDMENTS Amd Date Page(s) Description ___________________________________________________________________
CUSTODIAN (See Quarterly Status List for Contact)
Control & Electrical Systems

Issued by:-
Engineering Practices Group, BP International Limited, Research & Engineering Centre Chertsey Road, Sunbury-on-Thames, Middlesex, TW16 7LN, UNITED KINGDOM Tel: +44 1932 76 4067 Fax: +44 1932 76 4077 Telex: 296041
CONTENTS Section Page FOREWORD ........................................................................................................................... v 1. INTRODUCTION ............................................................................................................... 1 1.1 Scope ..................................................................................................................... 1 1.2 Application .................................................................................................................... 1 1.3 Quality Assurance.......................................................................................................... 1 2. SPECIFICATION ............................................................................................................... 2 2.1 DCS Project Organisation and Implementation Strategy .............................................. 3 2.1.1 Basic Training ........................................................................................... 5 2.2 Statement of Requirements and Control Philosophy..................................................... 6 2.3 Front End Engineering Design (FEED)......................................................................... 8 2.3.1 Functional Specification ........................................................................... 8 2.3.2 FDS System Sizing ................................................................................... 9 2.3.3 Ancillary Areas ....................................................................................... 15 2.4 Performance................................................................................................................. 16 2.4.1 Safety Requirements ............................................................................... 16 2.4.2 Reliability and Availability ..................................................................... 19 2.4.3 System Response Times.......................................................................... 21 3. SYSTEM SELECTION AND PURCHASE.................................................................... 22 3.1 Pre-qualification of Vendors ....................................................................................... 22 3.2 Enquiry and Vendor Selection..................................................................................... 23 3.2.1 Invitation To Tender ............................................................................... 23 3.2.2 Secrecy Agreements................................................................................ 23 3.2.3 The Tender .............................................................................................. 23 3.2.4 Bid Evaluation and Vendor Selection..................................................... 24 3.3 Purchase ................................................................................................................... 25 3.3.1 Negotiation.............................................................................................. 25 3.3.2 Purchase Specification ............................................................................ 25 3.3.3 Delivery Schedule ................................................................................... 25 3.3.4 Warranty and Vendor Support ................................................................ 25 3.3.5 Payment Terms ....................................................................................... 26 3.3.6 Training................................................................................................... 26 4. DETAILED SYSTEM DESIGN ...................................................................................... 27 4.1 Project Management .................................................................................................... 27 4.1.1 System Design Specification .................................................................. 27 4.1.2 Management of Data............................................................................... 28 4.1.3 Documentation........................................................................................ 28 4.1.4 Software .................................................................................................. 30
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE i
4.1.5 System Configuration ............................................................................. 30 4.1.6 CONSOP................................................................................................. 30 4.2 System Infrastructure................................................................................................... 31 4.2.1 Control Room Design ............................................................................. 31 4.2.2 Equipment Location and Accommodation ............................................. 39 4.2.3 Spare Capacity and Upgrades ................................................................. 39 4.2.4 Power Supplies........................................................................................ 40 4.3 System Functionality ................................................................................................... 40 4.3.1 Interfaces................................................................................................. 42 4.3.2 Maintenance and Diagnostics ................................................................. 44 4.3.3 Control and Data Acquisition ................................................................. 44 5. SYSTEM CONFIGURATION......................................................................................... 46 5.1 Man Machine Interface................................................................................................ 46 5.2 Security ................................................................................................................... 47 5.3 Information Display..................................................................................................... 48 5.3.1 User Requirements.................................................................................. 48 5.3.2 Providing the Functionality..................................................................... 49 5.3.3 The Display Hierarchy ............................................................................ 50 5.3.4 Access/Navigation .................................................................................. 51 5.3.5 Custom Replacement of Standard Displays............................................ 52 5.3.6 Data Access/Change Facilities................................................................ 52 5.3.7 The Use of Colour................................................................................... 53 5.3.8 Display of Fixed Information.................................................................. 55 5.3.9 Display of Variable Information ............................................................. 56 5.4 Data Entry ................................................................................................................... 57 5.4.1 Physical Devices ..................................................................................... 57 5.4.2 Functional Aspects.................................................................................. 59 5.5 Alarm Systems............................................................................................................. 60 5.5.1 Alarm Definition..................................................................................... 61 5.5.2 Alarm Detection...................................................................................... 62 5.5.3 Alarm Prioritisation ................................................................................ 63 5.5.4 Association of Alarms with Plant Areas or Process Units...................... 64 5.5.5 Audible Warning..................................................................................... 64 5.5.6 Alarm Identification and Situation Assessment...................................... 65 5.5.7 Corrective Action.................................................................................... 66 5.5.8 Alarm and Event History Reporting ....................................................... 69 5.5.9 Alarm System Management.................................................................... 69 5.5.10 Point Processing/ Alarm Conditioning ................................................. 70 5.6 Trending and History Configuration............................................................................ 74 5.6.1 Historical Data to Collect........................................................................ 74 5.6.2 Time and Magnitude Resolution of Historical Data ............................... 75 5.6.3 Archiving ................................................................................................ 76 5.6.4 Trends ..................................................................................................... 76 5.6.5 SQL Reports............................................................................................ 78
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE ii
5.7 Controller Configuration Guidelines ........................................................................... 78 5.8 Batch and Sequence Control........................................................................................ 80 5.9 Advanced Control/ Optimisation................................................................................. 84 5.9.6 Other Kinds of Advanced Control Scheme............................................. 90 6. ACCEPTANCE AND INSTALLATION ........................................................................ 91 6.1 Factory Acceptance Testing (FAT) ............................................................................. 91 6.2 Delivery and Installation.............................................................................................. 93 6.3 Site Acceptance Test (SAT) ........................................................................................ 94 6.3.1 Site Testing Principles ............................................................................ 94 6.3.2 Hardware Testing.................................................................................... 95 6.3.3 Software Testing ..................................................................................... 95 6.4 Pre-commissioning and Loop Testing ......................................................................... 96 6.4.3 Operator Familiarisation and Training.................................................... 97 6.5 Commissioning............................................................................................................ 98 6.5.1 Loop Tuning Starting Values.................................................................. 98 6.5.2 Re-instrumentation - Hot Changeover .................................................... 99 6.5.3 Advanced Control Commissioning....................................................... 100 7. OPERATIONAL MANAGEMENT .............................................................................. 101 7.1 Operation and Development...................................................................................... 101 7.2 Change Procedures .................................................................................................... 101 7.3 Housekeeping ............................................................................................................ 102 7.4 Maintenance and Spares ............................................................................................ 103 7.5 Refresher Training ..................................................................................................... 103 APPENDIX A....................................................................................................................... 104 DEFINITIONS AND ABBREVIATIONS ...................................................................... 104 APPENDIX B....................................................................................................................... 106 LIST OF REFERENCED DOCUMENTS ...................................................................... 106 APPENDIX C....................................................................................................................... 107 GUIDANCE CHECKLISTS ........................................................................................ 107 C.1 DCS Specification Contents ..................................................................................... 107 C.2 Instructions To Tenderer........................................................................................... 110 C.3 Front-End Engineering.............................................................................................. 111 C.4 Enquiry ................................................................................................................. 112 C.5 Purchase ................................................................................................................. 112 C.6 Delivery Schedule ..................................................................................................... 113 C.7 Man-Machine Interface Philosophy and Specification ............................................. 114 C.8 Detailed Design......................................................................................................... 115 C.9 FAT ................................................................................................................. 116 C.9.1 FAT Specification.................................................................................................. 116
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE iii
C.9.2 FAT - Hardware Testing ........................................................................................ 117 C.9.3 FAT - Software Testing ......................................................................................... 118 C.10 Delivery and Installation ......................................................................................... 119 C.11 SAT ................................................................................................................. 119 C.12 Precommissioning and Loop Testing...................................................................... 120 C.13 Commissioning ....................................................................................................... 120 APPENDIX D....................................................................................................................... 121 ABRIDGED AMHAZ METHODOLOGY ..................................................................... 121 APPENDIX E....................................................................................................................... 125 SOFTWARE CHANGE REQUEST FORM................................................................... 125 SUBSEA CONTROL SYSTEMS: The old Section 4, Subsea Control Systems, has been removed from this latest (February 1998) issue with the intention of producing a separate document covering Subsea Control Systems or a new Subsea document with a section within it covering Subsea Control Systems.
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE iv
FOREWORD Introduction to BP Group Recommended Practices and Specifications for Engineering The Introductory Volume contains a series of documents that provide an introduction to the BP Group Recommended Practices and Specifications for Engineering (RPSEs). In particular, the 'General Foreword' sets out the philosophy of the RPSEs. Other documents in the Introductory Volume provide general guidance on using the RPSEs and background information to Engineering Standards in BP. There are also recommendations for specific definitions and requirements. Value of this Recommended Practice This document gives the basis for the Specification, Selection, Design, Configuration and Use of Control and Data Acquisition Systems. It has been developed from cross-Business experience gained during capital project developments, operations and maintenance; and from equipment developments and evaluations. This document gives guidance on Control and Data Acquisition system strategy, equipment selection and project development which is not available from industry, national or international codes. Where such codes exist for established elements of the technology, the document guides the user as to their correct application. General This document specifies all BP's general requirements for Control and Data Acquisition Systems that are within its stated scope. This document previously contained sections for Telecommunications and Subsea Control Systems, which now appear under separate issue. This document has been updated to reflect the current industry wide appreciation of Control and Data Acquisition Systems. This document therefore contains abridged sections from those previously released, as well as some additional sections and sub-sections (see Contents). Principal Changes from Previous Edition Principal changes to Sections Issued from October 1994:(a) (b) (c) Sections 3 (Telecommunications) and 4 (Subsea Control Systems) have been removed. The sections have been updated to include references to new standards and reflect changes in operating practices. Section numbering has been amended to suit the applicable part.
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE v
Application Text in italics is Commentary. Commentary provides background information which supports the requirements of the Recommended Practice, and may discuss alternative options. It also gives guidance on the implementation of any 'Specification' or 'Approval' actions; specific actions are indicated by an asterisk (*) preceding a paragraph number. This document may refer to certain local, national or international regulations but the responsibility to ensure compliance with legislation and any other statutory requirements lies with the user. The user should adapt or supplement this document to ensure compliance for the specific application. Feedback and Further Information The document covers the rapidly developing field of digital technology, it is therefore intended to review and update this document at regular intervals. The value of this document will be significantly enhanced by contributions to its improvement and updating. Users are urged to inform the BP custodian of their experience which could improve its application. Users are invited to feed back any comments and to detail experiences in the application of BP RPSEs, to assist in the process of their continuous improvement. For feedback and further information, please contact Standards Group, BP International or the Custodian. See Quarterly Status List for contacts.
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE vi
1.
INTRODUCTION 1.1 Scope This Recommended Practice provides a guide to the Specification, Selection, Design, Configuration and Use of Control and Data Acquisition Systems. The successful design of digital systems is a challenge. This challenge stems from detailed design after purchase order placement, rather than before as with most other equipment. The document is structured to reflect phases of project execution, and sections can be used/ adapted for free-standing issue. Other related Practices to BP Group RP 30-4 specify BP requirements for specific equipment, i.e. Instrumentation and Control Design and Practice, Measurement, Valves and Actuators and Protective systems. 1.2 Application To apply this Practice, it shall be necessary to make reference to other BP Group RPSEs and national codes and standards as indicated in the relevant text. Reference is made to British Standards. These standards are generally being harmonised with other International/European standards and will be allocated ISO/EN reference numbers. In certain countries, national Standards may apply. BP shall approve use of other standards.
1.3 Quality Assurance Verification of the vendor's quality system is normally part of the pre-qualification procedure, and is therefore not specified here. If this is not the case, clauses should be inserted to require the vendor to operate and demonstrate the quality system to the purchaser. The quality system should ensure that the technical and QA requirements specified in the enquiry and purchase documents are applied to all materials, equipment and services provided by sub-contractors and to any free issue materials. Further suggestions may be found in the BP Group RPSEs Introductory Volume.
RP 30-4
INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS SYSTEM DESIGN AND CONFIGURATION GUIDELINES PAGE 1
2.
SPECIFICATION This section defines the recommended requirements for the safe, reliable and fit for purpose design and specification of a Distributed Control System (DCS). The term DCS is synonymous with the family of micro-processor based process control systems that includes Supervisory Control & Data Acquisition (SCADA) and PLCs. The term DCS is used here in this wider context, and recommendations made are equally applicable across this family of system types. The procedures for each specific project will depend upon its size and nature. Therefore a specific strategy should be determined for each project. The scope of the following activities should be assessed:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) Generate Statement of Requirements. Pre-qualification of Vendors. Front End Engineering Design. Enquiry. Vendor Selection and Purchase. Detailed Design and Construction. Factory Acceptance Testing. Delivery and Installation. Site Acceptance Testing. Pre-commissioning and Loop Testing. Commissioning. Operation and Development.
It is important to develop a firm design and implementation framework during the DCS project formative stages. This should be done in association with the Asset management. Sufficient time should be allowed in the pre-project programme for development, discussion and acceptance of this framework.
RP 30-4
2.1
DCS Project Organisation and Implementation Strategy Many aspects of control system interact with other disciplines at various stages of the project. Project organisation should facilitate networking and communication between these disciplines. Key cross discipline links:Control Room Layout Hardware Installation Architect, Civils, H&V, Lighting Architect, Civils, Electrical, Protection, Safety Systems Reliability & Availability Process Design, HAZOP Process Design, HAZOP, Operating Procedures Process Design, HAZOP, Operating Procedures Process Design, HAZOP, Operating Procedures, Training Fire
Power Supply Hardware I/O Control Control Configuration
MMI; Alarm Handling
Training Simulator
RP 30-4
The detailed design engineering of DCS differs from almost all other plant equipment because it is carried out after the purchase order, not before. The detailed engineering is extensive and complex to manage. A number of approaches can be used to manage the detailed engineering phase. The following table lists the more common methods.
DCS IMPLEMENTATION METHODS Method Hardware Configuration Application Comments Software Best suited to grass roots projects with well 1 Vendor Vendor Vendor 2 3 4 5 6 7 8 9 Vendor Vendor Vendor Vendor Vendor Vendor Vendor Vendor Vendor Vendor Vendor BP BP Contractor Contractor Contractor BP Contractor Specialist BP Specialist BP Specialist Contractor
understood and defined control requirements, e.g. BP licensed and own processes Best suited to grass roots projects with well understood and defined control requirements, e.g. BPs own processes Not recommended unless the contractor owns the process technology supplied and is DCS experienced and competent Useful where special application software is required e.g. optimisers Good for Site projects such as BP led reinstrumentation projects Good for site projects such as BP led reinstrumentation projects Needs careful vetting to ensure contractor DCS competence experience and capability. The number of information interfaces detracts. Needs careful vetting to ensure contractor DCS competence, experience and capability. The number of information interfaces detracts. Not recommended unless the contractor owns the process technology supplied and is DCS experienced and competent
On site-based projects such as reinstrumentation projects, BP will be generally managing the project and its resources whether they are wholly BP or integrated with contractor resources. Site personnel familiar with the operation and control requirements of the plant are invariably involved. Implementation methods 5 and 6 are therefore most appropriate. On grass roots projects, the choice of implementation method is less straightforward and is influenced by the overall project organisation e.g. number of contractors their responsibility and the location and type of project, e.g. wholly-owned or joint venture. Methods 1 and 2 have proved the most successful. Methods 5 and 6 can also be used but they tie up significant BP resources for long periods, which can be difficult to justify. The other methods involving contractors and specialists should only be used following careful vetting and evaluation. Few plant contractors have a significant DCS capability.
RP 30-4
In selecting an implementation method, it is good practice to minimise human interfaces, i.e. minimise the numbers of contractors and vendors and generally to avoid split responsibility unless the split is between BP and the vendor. Whichever implementation method is adopted it is recommended that a DCS task force or team is formed with responsibility for the detailed engineering, from purchase order until at least completion of Site Acceptance. On Site projects, this team should be an integrated team where contract resources are used. On grass roots projects where the contractor typically is managing, the BP resources should be integrated with the Contractors and include a vendor representative. The team should ideally also contain members with responsibility for other control room instrumentation such as ESD to ensure a unified and robust control system design is achieved. It is recommended that at least one BP DCS Engineer is involved fulltime in any project using DCS. On site projects, and where a large DCS (e.g. > 2,500 tags or 250 control loops) is required on grass roots projects, it is recommended that more than one engineer should be involved. 2.1.1 Basic Training Training in the basics of DCS technology and terminology, the use of keyboards and familiarisation with standard displays should normally be in a specialised training facility. The following table provides overview guidance of the type, extent and likely timing of such training.
JOB FUNCTION Project manager Project engineer Planning engineer DCS engineer Control engineer SUGGESTED TRAINING DCS project overview TIMING At start of project COMMENTS Can be joint BP and vendor overview session
Full vendor training courses
Process engineer Plant management Maintenance technician
DCS overview course. Simulator training. Vendor first line maintenance course. Attendance at factory testing "Hands-on" training on DCS operation. Attendance FAT. Simulator training
Before detailed DCS design. Preferably before SDS development Before detailed DCS design Before FAT
Operator
Before loop testing at site
General overview by vendor As an alternative onsite training by vendor following delivery can be considered Generally carried out by BP DCS engineers.
RP 30-4
The requirement for a Training Simulator should be determined at the initial stages of a project. If a Training Simulator is required, its schedule, resource and data requirements should be considered as part of the overall project plan.
Delivered, sufficiently early, the simulator will not only train operational staff, but provide valuable checks on plant control system design and operability, and operating procedures. Control schemes and display configuration can be developed in a live environment, and process design problems can be identified and proposed changes validated.
The Pre-commissioning phase of the project is an opportunity for operators to become thoroughly familiar with the whole interface. Walk-through exercises can be used to test the compatibility of DCS displays with plant operating instructions.
Plant operating instructions should be developed interactively with DCS configuration to ensure consistency and compatibility. Training on the delivered system should be spread between instructors from operations, technical and engineering to give a balanced understanding of the capability of the interface and how it meets the operators needs.
2.2 2.2.1
Statement of Requirements and Control Philosophy A Statement of Requirements (SOR) and Control Philosophy should be developed with the Operating Business to define the use and purpose of the DCS. The SOR should contain the following information;(a) (b) (c) (d) Location, type and scope of plant to be controlled. Scope of field instrumentation and instrument sub-systems to be connected to the DCS; interfaces to other systems. Operator requirements (e.g. location and number of operating centres, number and responsibilities of individual operators). Operating philosophy, (e.g. continuous or batch processing, start-up, shutdown and operation in normal, unsteady and emergency conditions: the need for operator intervention, what is controlled and monitored, and where). Centralised control building and local equipment room requirements. Extent and purpose of advanced control, profit optimising controls and management information. The type, extent, features and location of associated equipment with a definition of the proposed interface; e.g. ESD & package equipment; to define alarm and display strategy.
(e) (f) (g)
RP 30-4
(h) (i) (j) 2.2.2
Required control system reliability, availability and maintainability. Definition of project responsibilities and third party involvement. Changeover and Commissioning Requirements.
The Control Philosophy (CP) for the plant and its DCS is then developed in line with the SOR. The CP functionally describes how the control, monitoring and safe operation of the plant is achieved through the DCS. The CP should address the following:(a) (b) (c) (d) (e) (f) (g) How the control of the plant is to be achieved, (broad functional terms). The areas to be controlled and the extent of control, e.g. regulatory, sequential, advanced, optimisation. Remote control requirements, (if any). Subdivision of the plant into control 'Areas' and 'Units'. The form and extent of the operator interface, e.g. number of consoles. Number and types of displays and reports required. Safety and protective system display, monitoring and interface requirements; e.g. philosophy and means for applying overrides. Alarm Philosophy. Operator console additional facilities (e.g. communications equipment, closed circuit TV). Other user interfaces, (e.g.. shift supervisors, engineers, development engineers, disturbance, and plant management). Interfaces to packaged equipment. Interfaces to other instrument systems, e.g.. ESD, Fire and Gas, Metering, Analysers, Sub-sea, Anti-surge controllers etc. How motors are to be interfaced and controlled. Functional outline of software applications and any advanced control or optimisation required. The extent of historical information recording and trending requirements. The need and extent of computing facilities required for Management Information and higher level applications. Hazardous Area Classification of field mounted equipment. Field equipment interfacing, signal and transmitter types, e.g. smart. Requirements for future expansion or plant integration. Cabling and termination philosophy, i.e. overhead or underground, armoured cable or conduit, close coupled or segregated field terminations. Power supply (UPS) and distribution requirements.
(h) (i) (j) (k) (l) (m) (n) (o) (p) (q) (r) (s) (t)
(u)
RP 30-4
(v) (w) (x)
Fire and smoke detection and protection e.g. VESDA. Environmental requirements of the control and equipment rooms e.g. HVAC, lighting, noise. Established operating sites may include their requirements for DCS maintenance and support.
2.3
Front End Engineering Design (FEED)

A Front End Engineering Design is required to develop strategies for later stages of the project and to establish a robust Class III estimate to enable full project sanction to be sought.
During FEED the DCS design should be developed sufficiently so that the following will be produced:(a) (b) (c) (d) An approved Functional Specification for the system. A cost estimate based on a firm quotation from the potential system vendor. A definition of project strategy and cost estimate for detailed design, installation and commissioning phases of the project. On projects associated with operating plant an implementation strategy for system installation and commissioning with due regard to operational safety and potential production losses, particularly where 'on-the-run' loop changeover is envisaged. The outline Man Machine Interface philosophy. Training requirements for operators, system engineers and maintenance technicians. Engineers and operators involved in the design will require training early in the project if they are to be effective.
(e) (f)
2.3.1
Functional Specification The Functional Specification should be based on the SOR and the CP documents and should describe the required system functionality. The Functional Specification (FS) should detail the vendor's scope of supply. It should:(a) (b) (c) (d) (e) be written purely in functional terms concentrate on application requirements, and not repeat vendor standard specification material. include the extent of hardware needed and the requirements for overall project management of the system. include sufficient information to permit sizing of the DCS. an outline block diagram showing the inter-relationship between the major components of the DCS.
RP 30-4
The block diagram clarifies the design intent and assists in ensuring that a unified and robust design is produced.
(f)
Include specific rules for implementing the design of displays.
The FS on a single vendor project will typically be developed in association with the vendor and include more specific design details, e.g. network topology, outline console design and layout, powering arrangements, and equipment packaging. Generally, the FS can be developed into the System Design Specification (SDS), with very little further work. This is an obvious advantage of the single vendor route. Where several vendors are being asked to bid, it may be necessary to write different FS documents for each vendor so as to make best use of each make of equipment, or to write the FS in more general terms so as not to prejudice the vendor selection. 2.3.2 FDS System Sizing Accurate sizing of a DCS at the front-end of a project can be difficult. This is particularly the case on processes that are new and unfamiliar. DCS sizing can also be difficult on Reinstrumentation projects if drawings are out of date, etc. Sizing of is predominantly a function of:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) (m) (n) Physical Input/ Output (I/O). Number of control areas, consoles, screens and process operators. The extent and complexity of the process to be controlled. The number of users other than the operator. The reliability & availability of control & monitoring required and hence the use of redundancy. The extent of historical information recording. The extent of subsystem interfacing. he extent of advanced control. The extent of interlocking. The extent of event monitoring. The application software processing requirements. Numbers and types of control functions. Power supply philosophy or arrangements. Spares allowance viz. installed spare capacity and system expandability.
RP 30-4
2.3.2.1
Physical I/O Requirements The physical I/O required will depend on the extent of field equipment to be monitored and controlled plus any (non serial link) repeats from other systems such as the ESD system. On new plant projects, the I/O count is best established from the P&IDs, or using data from a similar plant. For bought-in processes, the licensor can generally advise.
Machinery packages with condition monitoring, can be especially difficult to assess at FEED. The following guidance is therefore provided, n.b. figures are typical averages based on casings containing two radial, and one axial bearing:TYPICAL SIGNAL NUMBERS Lube Oil Vibration & Systems Displacement per Casing 4-20mA DI 4-20mA DI 6 4 6 4 4 8 6 4 6 2 4 4
MACHINE
Speed
Temperature per Casing T/C 8 6 2 DI
Status
4-20mA Compressor Turbine Turboexpander Hi-Speed Pump 2 1
DI 1
DI 3 2 2 3
2.3.2.2
Number of Consoles, Screens and Operators The number of control areas and the number of process operators required will dictate the number of consoles and screens needed. Plant complexity will ultimately have an impact on the design of the console(s), i.e. number of consoles, number of operators, and number of screens per operator. A Plant Complexity Assessment will assist in determining these requirements. Pertinent issues in this assessment will be the size of plant, degree of unit interaction, amount of advanced control schemes, etc. (a) Control Loops (Valves) per Operator
An assessment of the operator workload can be broadly determined on the basis of the number of final control elements (control valves) that the operator must manipulate. The number of control valves per operator is influenced by factors including plant complexity, additional tasks that the operator is required to perform, the degree of plant upset that may be experienced, etc.
RP 30-4
Good practice within BP typically calls for between 100 and 200 control valves per operator, and reported good refinery practice indicates that the optimal number of control valves per operator is approximately 160, or 195 with advanced controls.
(b)
Screens per Operator
Screens per operator depends on factors including plant complexity and the number of control valves allocated per operator. Good practice within BP calls for 3 or 4 screens per operator. Consideration should be given to the 3 keyboard-6 screen (3+3 stacked) console on large units. Process plants with a high degree of complexity or high speed of response would need an increase above the figures given. As technology changes and a move is made towards 'windows' based displays it will be possible to display additional data on one screen and it may be possible to reduce the number of screens per operator. Poor display design can lead to demands for a greater number of screens per operator. Should an operator need two or more displays to monitor one task, improved design should be sought to provide this data more concisely. (c) Screen for users other than the process operators
The number of users other than the operator requiring system access, i.e. engineers, plant superintendents, should be established, and dedicated screens in dedicated rooms are generally preferred.
On some DCSs two screens are required for effective DCS engineering work.
2.3.2.3
I/O Modules and Spares Allowance Physical segregation of control areas and software maintenance requirements should be considered as there is always the need to develop software whilst the plant is running. Sizing in whole hardware modules per plant area or per reactor, etc. is generally the most practical and effective approach.
RP 30-4
The chosen installed spares allowance significantly impacts DCS size and cost. The temptation to minimise on spares should be resisted as the cost and delay potential of running out of I/O far outweigh the hardware costs in spares. Spare capacity should be considered for both installed modules and rack-space. Installed modules can be added at small incremental cost, but adding rack-space can have a major impact on the project. The table is provided for guidance:PROCESS ATTRIBUTES INSTALLED SPARES I/O ALLOWANCE MODULES 10% 15% to 25% 30% RACK SPACE 20% 25% to 35% 40% COMMENT
Well Known Established (not well known) New and untried
Minm recommended Normal range Maxm recommended
I/O spares allowance should be evenly distributed as far as practicable. Hot-spares have the advantage that the equipment is guaranteed to work when it is needed, and in some cases can be used without physical interference. Hot-spares can also provide a development environment if appropriately configured. It should be ensured that when installed spares are removed from a live system there is no potential adverse affects on the adjacent live equipment. 2.3.2.4 Reliability and Availability The reliability and availability of control and monitoring required as defined in the SOR, dictates the extent of redundancy required on shared processors, such as multiloop controllers, shared display processors, multiplexors and gateways. As a starting point the following design criteria can be applied:(a) All control redundant. This applies to any shared control processor, power supplies and associated input/output cards, and may include the field loop equipment. All monitoring non-redundant. Exceptions would be large capacity shared processing, (more than 16 analogue signals or 32 digital or temperature signals), or signals used for high value control schemes.
A CONSOP should be performed for high value control schemes
(b)
(c)
No single fault in the display system should cause a complete loss of process vision or ability of the operator to control the plant.
RP 30-4
This means on systems with a single display processor driving several display screens, the display processor and screens would be redundant. Whilst on a single display processor per screen system, sufficient screens should be provided for a single display failure to be tolerated.
The availability/reliability requirements can then be established to match the process needs.
If the critical control loops on the process can be established and agreement reached that only these are redundant, a more cost effective design can be achieved. On demand corrective cover is an alternative consideration, and alternatives should be assessed on the maxim that the cost of plant downtime is generally large compared to the cost of DCS hardware to provide redundancy or other remedial alternatives.
On some systems the processing speed of control is user selectable. However faster control will be at the expense of a greater number of controller modules. Where variable processing speed is available, a 1 second processing interval satisfies analogue control loops with outputs to pneumatic control valves. Faster rates may exceptionally be required for interlocks or control of high-speed rotating machinery. Beyond the basic three term control and process variable monitoring requirements, the following will normally demand additional processing capacity:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) 2.3.2.5 Cascade control. Mass flow conversions. Selectors, e.g. hi-lo selects, etc. Derived variable calculations, e.g. partial pressure, heat load. Accumulations, e.g. flow or time integration. Dynamic compensations, e.g. lead-lags, time delays. Ramping. Logic processing, e.g. for interlocks, etc. Simple sequencing. Custom algorithms, e.g. dual transmitter handling.
Extent of Historical Information/ Trending

The extent of historical information recording will have direct and significant impact on hard disc capacities. Advanced control and optimisation schemes will often require the historical collection of additional parameters to the PV, e.g. SP, OP. Without the use of data compression techniques, 50 kilobytes of hard disc capacity will typically be required to store 1 process variable at 1 minute intervals for 1 week.
Beyond the immediate needs of operations, (typically 2 to 4 weeks of history), plant data should be kept in a computer database, e.g. PI, Oracle on a DEC VAX. This allows data to be more easily and cost effectively managed, whilst facilitating wider access to the data.
RP 30-4
All real time and historical data should be available for use in displays, trends, reports, calculations and application programs. As well as spot values the system should be capable of producing hourly, 4 hour, shift, daily, weekly and monthly averages of any selected analogue point for use in trends, reports and calculations. Trend displays should be both real time and historic. It should be possible to assign all analogue input variables, any displayed, calculated or manually input variables and all controller setpoints and outputs. It should be possible to trend multiple variables on the same screen for comparison of variables. Trending should be selectable over discrete time intervals ranging typically from 1 minute to a minimum of 4 days. For historical trends it should be possible for the operator to scroll backwards through the last 4 days of 1 minute spot values of any selected point. The system should allow the operator to re-scale the Y-axis of any trend or temporarily change the range of a point that is being trended for better observation of the trend. 2.3.2.6 Extent of Subsystem Interfacing The extent of subsystem interfacing will dictate the number of interface modules or gateways required. In the case of PLC controlled packaged plant, typical I/O figures can usually be obtained from the vendor or the licensor. As these data are typically acquired via serial link the DCS tag number count, i.e. database size is affected rather than the physical I/O count. 2.3.2.7 Extent of Advanced Control Additional controllers or modules may be needed for advanced control schemes and models, and for plants with significant amounts of batch control and recipe management. The sizing of these requirements is particularly difficult at FEED unless the application is well known or understood. It is recommended that an assessment is made of the number and likely size of programs required by:(a) (b) (c) (d) Comparison with similar applications Consultation and advice from vendors BP Group experience Program number and size estimates
RP 30-4
2.3.2.8
Power Supply Arrangements The power supply arrangements for the DCS will affect physical sizing and cost.
On the process I/O, the choice needs to be made whether to power from redundant battery/charger sets within the DCS, or from an external high integrity (bulk DC or inverter) supply. The battery/charger set solution is generally cheaper and provides good diversity but does result in batteries in the DCS cabinets rather than in the switch room or elsewhere. The maintenance management of a distributed battery back-up system needs to cater for un-revealed battery failures, and for batteries failing at different times. The operator interface is typically powered from an inverter fed mains supply.
2.3.3
Ancillary Areas The DCS will impact a number of ancillary areas, in particular on the following: (a) (b) (c) (d) Control and Equipment Room size. Power supply requirements. Heating, Ventilating, and Air Conditioning Requirements (HVAC). Control Room Lighting.
Vendors can readily supply the physical dimensions, weights, power consumption etc. of DCS equipment. Good estimates can be made of system power consumption including inrush, and of system heat output. These can be used in the preliminary sizing for power and HVAC requirements. Vendors often provide guidance on lighting. The lighting arrangements in the control room, and especially around the MMI should be subject to specialist advice from consultant specialists in ergonomic design. The numbers of equipment and termination cabinets and consoles should be established in a vendor's budgetary estimate. Using this information, the DCS equipment in the control and equipment rooms can be laid out and the space requirements estimated. It is prudent to make some unallocated floor space allowance for future requirements.
As cabinets are often mounted on sub-frames, consideration should be given to the installation of sub-frames and cabinets to accommodate future expansion. Where a false floor is provided this should be integrated into the sub-frame to provide stability.
RP 30-4
Cabinet spacing in equipment rooms should allow sufficient clearance for cabinet doors and access for maintenance. Inter-cabinet spacing of no less than 1 metre is recommended. 2.4 2.4.1 Performance Safety Requirements Reliable control systems are essential for safe operation of process plant. Unreliable systems place extra demands on safety devices such as relief valves and high integrity instrument systems. The performance of control systems is limited by equipment and application design and the normal errors made during operation, maintenance and modification. Where control system failure would lead to consequences such as risk to life, the environment or significant asset loss, separate devices such as relief valves or protective instrument systems should normally be provided to reduce the risks to tolerable levels. All systems with protection functions with claimed average probability of failure on demand less than 0.1 shall be designed in accordance with IEC61508 Functional Safety - Safety Related Systems (Reference RP 30-6 ). 2.4.1.1 Control systems where failures would lead to safety consequences or demands on safety systems or protective instrument systems shall also be implemented in accordance with IEC61508 unless the following can be established:(a) The safety systems is independent. It should be established that control system failures will not lead to a failure of the safety system to act on demand. The safety system is separate. It should be established that the safety system is physically separate from the control system such that external influences such as environmental change or maintenance activities are unlikely to cause a failure of both systems simultaneously. The safety system is designed for all reasonably foreseeable failures of the control system. With DCSs a single failure may cause all outputs on a single output card to fail to the high output state at the same time and it will need to be established that equipment such as relief systems have been designed accordingly. The same hazard could occur where complex
(b)
(c)
RP 30-4
software schemes are used to control multiple valves on heating/cooling applications. (d) The safety system is designed for the likely failure rate of the control system. The likely failure rate can be established from either field experience, calculation using industry standard methods or industry databases on generic failure rates. The claimed failure rate should not be less than 0.1 per year.
2.4.1.2
Control systems can be used to reduce the demand rate on safety systems or protective instrument systems subject to the following restrictions:(a) There shall be sufficient time for the operator to take action between when an alarm is indicated and when the process conditions exceed required levels. The claimed reduction in demand rate shall not be more than a factor of 5.
(b)
2.4.1.3
Control systems which have not been implemented according to IEC61508 can be used to diagnose failures of the protection system by comparing control system and protective system sensor readings. The diagnostic coverage can be taken into account in determining the average probability of demand of protection systems subject to the following restrictions:(a) Alarms are automatically generated in a permanently manned control room when a difference in control and protective system sensors are detected. The claimed diagnostic coverage for the sensor shall not be more than 60%.
(b)
2.4.1.4
Where control systems are used to diagnose failures of the protection system sensor(s) and the claimed diagnostic coverage is greater than 60% then the control system shall be implemented according to IEC61508. Where a failure of a control system would lead directly to a hazard and no independent protection is provided then the control system shall be implemented according to IEC61508 but in addition the following will apply. (a) The process dynamics should be considered such that it can be established that the process conditions will remain within the
RP 30-4
safe region after all reasonably foreseeable failures of process equipment and utilities. (b) A quantitative reliability analysis shall be carried out to confirm that the hazard rate is tolerable.
2.4.1.5
Certain control system vendors claim that their systems have been designed in accordance with IEC61508. The advantages of using such systems include the following:(a) The claimed demand rate on protection systems may be reduced leading to a reduction in the required safety integrity level of safety instrumented protection systems. The number of shutdowns due to failures of the control system can be reduced.
(b)
2.4.1.6
Where credit is taken for the system being designed according to IEC61508 the following shall apply:(a) An independent assessment shall be carried out to verify that the control system is in accordance with the requirements of IEC61508. Independent organisations capable of carrying out such assessments include TV, FM, Ineris, ERA. Application software shall be designed, verified, validated, assessed, and modified according to the requirements in IEC61508. Where the same control system is used for non safety applications then the complete arrangement of hardware and software shall be designed and maintained in accordance with IEC61508 unless it is demonstrated by independent assessment that the security arrangements are adequate to prevent design errors or unintended modifications causing failures of the safety functions.
(b)
(c)
2.4.1.7
System Safety Review

The consequences of equipment failure and its potential impact on plant protection systems should be considered. In particular, the failure modes of analogue output cards should be established, e.g. common mode failure causing multiple outputs to fail high simultaneously. Such failures may lead to a demand on the plant protection systems and should be addressed by techniques such as loop allocation, card depopulation, equipment redundancy etc.
RP 30-4
The DCS design should be subject to a formal (project) independent Instrumentation Technical Safety review. The Safety Review is a two part process. Part 1 Part 2 Performed soon after the Process OHSE Stage 2 review Performed soon after the Process OHSE Stage 3 review.
Typical Review Subject Categories Documentation Required

Part 1 Software variability of the system. Alarm Systems Control and Monitoring Operator Interface Occupational Health aspects Power Supplies Equipment location and environment Failure definitions Vendor choice and record Control Philosophy Document Man-Machine Interface Design Document DCS Design Topology Drawing Power Supplies Single Line Diagrams SDS (dealing with part 1 review topics) Vendor Overview summarising functionality P&I Diagrams
Typical Review Subject Categories Documentation Required

Part 2 Reliability Assessment Design implementation and progress Training Vendor Reliability calculations Screen Display Layouts Control Room Layout Drawing Equipment Room Layout Drawing DCS Console Layout Drawing DCS Testing Strategy and Procedures Typical Loop Drawings Details of Advanced Control Schemes DCS Network Cable Routing Drawings DCS Training Strategy Later revisions of Documents reviewed at Part 1
2.4.2
Reliability and Availability In addition to section 2.3.2.4, To achieve a practical design that meets the Business requirements in terms of reliability and availability the following approach is recommended. Establish the Business or operating plants requirements (or expectations) for:(a) DCS failure definition. This will depend upon the type of plant and the nature of the process, e.g. Minor Significant Major Total effecting loss of information/status data effecting loss of a single control effecting loss of multiple control or vision effecting loss of the whole system
RP 30-4
Unless otherwise specified by BP, major system failure criteria should be considered to be:(i) (ii) Total loss of Operator screens for a process area. A failure which causes two or more controller outputs to fail to a non safe position simultaneously. A failure that causes the operator to be unable to adjust the output of two or more controller outputs.
(iii)
(b)
Acceptable Mean Time Between Failure (e.g. MTBF > 10 years), or downtimes in hrs/yr, for each class of failure. This requires a knowledge of the technology, its capability and cost implications. Over specification should be avoided. Acceptable equipment repair times for each class of failure. terms (b) & (c) will enable the reliability and availabilities to be calculated for the DCS, its power supply and communications systems.
The vendor should define the calculation method and any assumptions made particularly those relating to failure modes and periods for individual cards or circuit boards. As well as random failures, common mode or systematic failures should not be overlooked. The design should be adjusted if necessary and the calculations repeated until acceptable results are obtained.
(c) (d)
In the absence of specific Business requirements for reliability and availability it is recommended that section 2.3.2.4 is used. All communication networks at the control level should be redundant. In applications involving a hierarchy of control, the design should ensure that failures at an upper supervisory level do not affect the integrity or operability at the plant control level. The integrity of critical control loops and redundant process equipment, e.g. duty/standby pumps, should be maximised where possible. Consideration should be given to allocating points to different I/O cards and controller files to minimise the impact of common cause control system hardware failures. Where redundant arrangements are installed, the health of the duty and back-up devices should be continually monitored and any failure of the
RP 30-4
duty equipment on control applications requiring uninterruptible service should effect an instantaneous switch to the back-up device. It is recommended that failure identification and system recovery procedures are developed for the DCS. These should be written for and made available to the operators to inform them what immediate action, if any, to take in the event of a failure. Detailed recovery procedures should also be prepared by the Systems Engineer for all foreseeable failures.
The procedures and any fast load facilities should be tested at the site acceptance test. Very often this is the only time when the full system will be available for testing since in future there may always be some portion of the system in service.
2.4.3
System Response Times Special requirements with respect to system response may be specified in project or tender documents. The following maximum response times should be met:All Graphic Displays Alarm Annunciation Operator Display Dynamic Data Update Alarm and Event Resolution Sequence of Events Resolution Response to Keyboard 2 seconds 2 seconds 5 seconds (normal) 2 seconds (selectable) 1 second 1 millisecond immediate
Most plants are operated by means of Operator Graphic Displays in preference to Standard Displays, and emphasis should consequently be placed on the performance of these.
RP 30-4
3.
SYSTEM SELECTION AND PURCHASE 3.1 Pre-qualification of Vendors A pre-qualification enquiry document should be produced which defines the functional requirements in broad terms without attempting to show how these requirements must be met. The document should also request vendor responses to various technical and commercial screening criteria.
There is a recommended move to pre-qualify vendors for the Business(es) as a whole to avoid every project having to repeat this activity. The benefits of a uniform control system strategy across the Business(es) cannot be underestimated. There is a need to prequalify and provisionally select (short-list) DCS vendors at an early stage. On a reinstrumentation project this must be done before the FEED, as significant differences in vendors equipment will influence many of the strategy decisions and the associated costs estimated.
Typical screening criteria for potential vendors should include:(a) (b) (c) (d) (e) (f) (g) (h) Size and resources of company Recent experience and track record An established Quality Assurance system Long term commitment to product support, and the ability to provide on-site maintenance and application support. Ability to provide and support application software Communications capability Adequacy of operator interface Whole of life ownership cost, including integration with any existing support structure, site knowledge base and spares holding Weight and space requirements System constraints System performance, e.g. display call-up times. Ability to accommodate advanced control and higher level applications. Integrated ESD and Fire and Gas system capability.
(i) (j) (k) (l) (m)
A qualitative evaluation should be carried out on the vendor responses to the pre-qualification enquiry document, by considering the functional aspects of the systems and assigning scores and weighting to these aspects.
The DCS evaluation should also take account of relevant in-house company experience where a system is well established and its technical strengths and weaknesses are known. Where systems are less well known, these systems may have
RP 30-4
been in-house benchmarked. Account should also be taken of external technical evaluations, typically by SIRA or TNO.
3.2 3.2.1
Enquiry and Vendor Selection Invitation To Tender It is recommended that all commercial requirements associated with an enquiry are separated from the Functional Specification (FS) and are presented in an Invitation To Tender (ITT) document. The FS together with the ITT documents forms the Enquiry Specification. The ITT should define the relative responsibilities of vendor and purchaser to meet the requirements of the functional specification along with the commercial terms and conditions of purchase. It should be drawn up by a procurements and contracts engineer familiar with digital systems.
3.2.2
Secrecy Agreements On some BP processes, there is a requirement to implement a process specific control package in the DCS. These packages invariably contain process know-how which is proprietary to BP. In these cases, a secrecy agreement shall be drawn up and signed with the vendor or contractor before any information is released for design and implementation. This agreement shall preclude release of information to any sub-contractors. These shall be covered by separate agreements where necessary.
3.2.3
The Tender Tenderers should be required to supply their project programme covering the period from contract award to site acceptance testing. Key Dates and Milestones should be defined. A statement of compliance should be completed by tenderers to confirm the level of compliance or non-compliance against each paragraph of the ITT and FS. Tenderers should provide a breakdown of costs, including the following key areas:(a) (b) (c) (d) (e) (f) (g) (h) (i) System Hardware. Licensed and applications software. System configuration. Contract documentation. Project management costs. System testing, delivery and site installation. System support options. Training options. Schedule of rates for reimbursable services.
RP 30-4
(j)
Basis of charging for contract variations.
Attention should be paid to whole of life system costs. Tenderers should therefore supply a list of recommended spare parts together with software and hardware support costs and call-out support costs. Tenderers should propose their project organisation and implementation policy. A project organigram should be requested to clearly define the proposed reporting structures within the various departments of the vendor's organisation and with any proposed subcontractor. Details should also be supplied of design information flow and communication routes. They should nominate a project manager and any lead discipline engineers, declaring their previous experience with the specified system. Tenderers should provide details of perceived and actual work load projections for the proposed contract period. Tenderers should detail standard documentation, both hard copy and firmware based, and define in detail any project special documentation required. Vendor responsibilities covering delivery, site installation and site acceptance tests should be defined. Site manning level estimates and organisation should be provided. All site works should be performed using site approved contractors. Recommendations for training courses for engineering, technical and operations staff should be requested; both vendor based and site based. The provision of such courses should be negotiated at the same time as the main supply contract. Tenderers should provide their preliminary Quality Plan and QA Procedures. 3.2.4 Bid Evaluation and Vendor Selection A technical and commercial qualitative assessment should be carried out taking account of whole life cost of ownership to select the most cost effective and fit for purpose system. Received bids should be checked for accuracy, i.e. do the numbers add up and match requirements. The bids should be checked for over and under specification errors. Both can be expensive, and sometimes impossible to correct later. Allowances for services and support, e.g. project management should be carefully vetted. Application software and configuration man-hour estimates should assessed against the scope of work requested.
RP 30-4
Compliance with the FS and ITT should be checked against the vendors compliance statements. Bids should be reconciled so that a 'like for like' comparison is made. A 'Clarification' meeting may be held to confirm and finalise the scope of individual tenders. 3.3 3.3.1 Purchase Negotiation
On competitive bids post tender negotiation may be sanctioned. Negotiation will generally commence towards the end of the enquiry phase once all bids have been evaluated and reconciled.
The negotiator should be assisted and supported by a DCS Engineer fully familiar with the bid and the system to be purchased. 3.3.2 Purchase Specification The Purchase Specification should be an updated version of the Functional Specification. The update should endeavour to include the following:(a) (b) (c) Elimination of all non-compliance Incorporation of all clarification issues Incorporation of all changes agreed during the enquiry, clarification and negotiation phases.
The above can be conveniently presented as an addendum to the original Functional Specification.
3.3.3
Delivery Schedule During negotiation, the delivery schedule for the system, services, and information to be supplied should be agreed. All significant dates should be clearly identified and tabulated in a schedule of dates. This should include Project Milestones which are associated with a contract payment, other key dates related to project schedule, and information due dates, to allow work to proceed smoothly.
3.3.4
Warranty and Vendor Support It is recommended that warranty support is discussed with the vendor during the contract development phase to ensure that the extent and duration of warranty cover for hardware and software failures matches the project requirements. The warranty period should commence from the date of factory acceptance, delivery, or site acceptance, as applicable. Where the interval between completion of acceptance testing and plant start-up is expected to be longer than the vendors normal warrantee period, it is recommended that an extension to the warranty is negotiated, as some problems may only manifest themselves once the plant is operational.
RP 30-4
System warranties should, as a minimum, cover the repair or replacement of faulty hardware/software by the vendor, including the costs of carrying out such repair or replacement at the point of use. The level of support that may be expected under the warranty (e.g. engineer availability, delivery and response times) should be established.
Maintenance support following the warranty should be explored at this stage to establish the range of options available and their likely cost. Although support following warranty will be the responsibility of the operational site, there is generally significant advantage in negotiating for, or actually purchasing hardware spares at project prices.
3.3.5
Payment Terms The payment terms need to be appropriate for local conditions and to minimise BP's risk and exposure. Stage payments against agreed Milestones are generally used on European Projects but other arrangements are prevalent elsewhere.
The following payment terms are typical of European projects and are provided for guidance:(a) (b) Receipt and approval of the SDS Confirmed delivery of all hardware into staging Completion of system assembly 5% Total System Price 15% Total Price 20% Total Price 35% Total Price 25% Total Price System
(c)
System
(d)
Completion of Factory Acceptance Test Completion of Site Acceptance Test
System
(e)
System
Payments (a) to (c) are generally covered by bank guarantees valid until delivery to site. Payment (e) by a bank guarantee valid until the end of the warranty period.
3.3.6
Training It is recommended that consideration be given at an early stage of the project towards the training requirements of staff on the DCS. Where a contractor is involved, his engineering staff will also need training early in the project if they are to be effective. The provision of training courses by the vendor on the DCS should form part of the DCS contract rather than a separate training contract.
The purchase phase is a good time to secure training courses for technical and other staff. Often an element of vendor training can be negotiated into the contract at little or no extra cost.
RP 30-4
4.
DETAILED SYSTEM DESIGN 4.1 4.1.1 Project Management System Design Specification It is strongly recommended that following the issue of the purchase order the vendor be required to develop a detailed system hardware and software specification of the system. This specification is called the System Design Specification (SDS).
The objective of the SDS is to allow the detailed system design to be more fully developed in functional terms and to verify that the vendor fully understands the requirements and his scope of work. It further allows BP to more fully understand the vendor's system functionality and supply. Development of the SDS should be led by the vendor with full involvement of BP and the contractor where appropriate.
As a minimum the SDS should develop from the Purchase Specification the following aspects:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) (m) (n) (o) Control Room and Equipment Room Layout drawings. Equipment general arrangement drawings. Signal interconnection diagram. DCS Console design layout. The allocation, partitioning and numbering of hardware including installed spare equipment. Principles to be adopted to minimise the effects of failures, (e.g. redundancy levels, slot allocation rules). Unit and Tag numbering rules. Field cable termination cabinet general layout drawings. Control system cabinet general layout drawings. Definition of earthing schemes and external and internal power supply arrangements. Finalised functional specifications of all special project application software. Finalised details (including scope and security details) of serial link or network architecture interfaces to other systems. Finalised Man Machine Interface (MMI) philosophy, i.e. display hierarchy and design rules. Alarm prioritisation, presentation and handling philosophy. The definition of historical data storage (i.e. trending and archiving).
RP 30-4
4.1.2
Management of Data
A significant task when engineering DCSs is the control and management of the design data.
It is recommended that the means of data management and flow to the vendor is discussed and agreed early before any significant amounts of design data are generated. It is recommended that computer based systems and electronic data transfer is used rather than paper forms.
Most DCS vendors can now provide PC based configuration packages for their systems. Alternatively, projects have previously developed instrument databases.
4.1.3
Documentation The provision of documentation of the right level and at the right time is an essential requirement of DCS projects. The overall documentation requirements should be clearly identified in a documentation index. This generally forms part of the vendor's contractual scope of supply. The following documentation should be provided as a minimum. In many cases this could be provided within a self documenting system, e.g. configuration database, and this need only exist on the system and backup disks:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) (m) (n) (o) (p) (q) (r) (s) (t) Hardware Layout and General Arrangement. Full Set of Vendor Hardware, Software and Configuration manuals. Details to assist the specification of linked equipment, e.g. HVAC, UPS. System Design Specification. System Block Diagram and Interface Schematic. Operator Manuals. Termination Index and Input/ Output Listing. Configuration Database. Advanced Control Schematics. Logic Diagrams. Sequence Flowcharts. Man-Machine Interface Design Document. Power Supply, Distribution and Earthing Drawings. Reliability Report. Installation Planning Manuals. Acceptance Test Procedures. Application Software Manuals. IS Certification Dossiers where appropriate. System Maintenance Manuals. "As built" design documents.
RP 30-4
The following table gives guidance in assessing the main documentation requirements and their timing of issue:ACTIVITIES DCS Engineer Support DOCUMENTS Full set of vendor specifications and configuration manuals. System Design Specification (SDS) Operator manuals TIMING Within 1 month of contract award COMMENTS
Other discipline support
Within 2 months of contract award Within 1 month of contract award Within 2 months of contract award Within 1 month of contract award Within 1 month of hardware freeze or earlier.
Usually subject to BP approval
DCS Installation Specification of ancillary equipment
Definition of detailed design
Design Specification Man-Machine Interface Installation planning manuals Heat dissipation calculations. Power consumption and distribution details. Earthing details DCS and equipment drawings. DCS configuration details. Cable, wiring and termination schedules. Application software functional design specifications. Acceptance test procedures Operator manuals "As built" display and configuration details.
Live documents subject to revisions until design is frozen
Definition of test procedures Operator Training
Prior to any software coding. 1 month prior to any testing or earlier. Prior to any operator training
Definition of the detailed design. Loop testing Pre-commissioning Commissioning "First-line" maintenance Support over plant lifetime.
Full set of vendor specifications, configuration and operating manuals. "As built" configuration details, drawings, and schedules. Application software manuals IS Certification dossiers where appropriate. Maintenance manuals
Factory acceptance test for review and approval. Final issue at or close to Site acceptance.
Usually subject to BP approval Where a training simulator is used details of the DCS displays and configuration will be required to build the simulator. Subject to BP approval. This documentation will comprise paper and electronic format items.
RP 30-4
4.1.4
Software It is recommended that the vendor produces for approval a Detailed Functional Specification of all application software to be written. Before placing any equipment order, the vendor should clarify the standard system software release that will be supplied and his expected software updates in the coming three years. The migration path for future software upgrades should be clearly specified by the vendor. Application software is expensive to develop and maintain compared to the use of standard vendor algorithms. Therefore application software coding should be minimised with maximum use being made of the DCS vendor's standard algorithms.
For straightforward supervisory control and monitoring applications where coding is necessary, the DCS vendor's control language and applications/control processor will generally be the most cost effective and appropriate choice. For more complex applications, e.g. optimisers and real time databases, industry standard high level languages such as FORTRAN 90, PASCAL or C running in a plant computer should be considered.
4.1.5
System Configuration The system should be provided with an engineer's console capable of allowing the complete system configuration and program development. The engineer's console should as a minimum be able to perform the following tasks:(a) (b) (c) Configure the system and point database (both on-line and offline. Build all operator displays. Save and load all configuration data.
It should also be possible to save and load configuration data from the Operator's workstation. The system should be capable of self documenting configuration data in clear English format onto a printer. Additionally, it should be capable of saving configuration data on portable digital media for safe storage. Bulk system configuration should be performed on a PC or Workstation rather than on the system itself. 4.1.6 CONSOP The CONSOP (CONtrol Safety and OPerability) review methodology provides a structured and systematic framework and approach to review the controllability, safety and operability issues surrounding the implementation of complex advanced control applications.
RP 30-4
CONSOP was developed as a result of some early and adverse operational experiences with proprietary multivariable predictive controller (MVPC) applications. CONSOP is complementary to existing HAZOP and PHSER reviews, utilising many of their principles but, importantly, addresses areas not covered by them. Other techniques, such as FMEA and CHAZOP concentrate on the security and integrity of system hardware and software, rather than the adverse operability consequences of MVPC mal-operation. CONSOP is implemented by a multidiscipline review team that apply a checklist of questions covering all aspects of application implementation, operation and interface handling. Provision of the CONSOP methodology as part of the bid documentation to a vendor serves the purpose of acting as a design guide and, consequentially, results in more appropriate and better quality bids and quality assurance during project implementation.
CONSOP is used by BP Oil sites and has also been taken up by third parties. CONSOP methodology details are given in report No: 1995-224022. Guidance is given on how to run a review, its documentation, team composition, timing and deliverable requirements. The deliverable is a short CONSOP report, with defined supporting documentation. An audit trail of what was reviewed is thus provided, including review Findings and Recommendations and a register for recording subsequent actions. Extensive background notes to preferred solutions are provided for the checklist questions as well as techniques for analysing the complex and interactive nature of MVPC applications.
4.2 4.2.1 4.2.1.1
System Infrastructure Control Room Design Console Design The Operator Console typically consists of a combination of the following:(a) (b) (c) Operator Stations (display screen and keyboard sets). An auxiliary console area for hardwired equipment (e.g. for ESD buttons, PA system). Communications equipment (e.g. telephones, radio).
In addition, space should be provided for operators documentation along with a suitable writing area. The Operator Console should comply with the HSE Display Screen Equipment Regulations 1992 (EEC directive 89/391/EEC). These requirements include:(d) display screen with stable image, adjustable brightness and free of glare.
RP 30-4
(e) (f) (g)
minimisation of reflection, noise, heat and radiation. adequate lighting and humidity. work chair with leg room and clearances for postural changes.
Examples given by the HSE where compliance can be argued as being unnecessary include:(d) (c) use of detachable keyboard - inappropriate where the operator has to locate and operate emergency controls. requirement for tilting and swiveling screens - undesirable as screens may need to be aligned in a console.
The HSE also state that more detailed and process industry specific standards such as the draft ISO 11064 standard on the general ergonomic design of control rooms should be applied. An operator console should be provided for each section of the plant normally under the control of an individual operator, or operating team (where all members are responsible for operating the same process units). Each console should be furnished with facilities to provide alarm logging and report production. Typically, 2 printers are provided. One printer should be used exclusively to log alarms and events. Alternatively, where there is no statutory or operational requirement for a printer, consideration should be given to installing a separate computer based alarm and event logging system. The other printer should be used for other services such as printing of reports. The printers should have a maximum noise level of 48 dBA. The level may be achieved by the use of acoustic hoods.
Alternatively, consideration should be given to the installation of printers in a separate printer room.
A video copier should be made available near the operator consoles for taking colour prints of the displays. The most efficient operator screen pointing device should be selected. Considerations should include that Touch screens may not be the preferred device, especially in a Windows environment, due to lack of precision, poor resolution, arm-reach fatigue, errors when cleaning etc. A preferred alternative may be the mouse (except for robustness) or tracker-ball. The extent of hardwired equipment mounted on consoles should be minimised to that required for safe operation of the plant. Hardwired annunciators, pen recorders and back-up controllers are not normally required.
RP 30-4
Trip alarm panels may be installed in the console and if so should be placed in a position where the operator can comfortably access the controls (e.g. reset/defeat/accept). Console layout should be reviewed and agreed with the plant operations team. A curved console layout is generally preferred since it improves the operators overview. Consoles for users other than operators (plant management, engineers, etc.) should be positioned away from the main control area.
A 'Supervisor Monitoring Console' may be provided which is set apart but close to the operator consoles. This will provide an overview of all plant areas and is intended for use during plant incidents. Process shift supervisors would typically use it during normal operations.
Data from other information sources (e.g. management information, lab data, etc.) required by the operator for process operations should be displayed within the console, preferably on DCS screens. The introduction of 'windows' based displays can remove the need to integrate 'non DCS' screens into the console layout. The operators DCS console is a collection of DCS workstations, peripherals, telecommunications and ancillary equipment. The ultimate console layout must be reviewed and agreed with the plant operations team. This is essential to avoid re-design post commissioning. 4.2.1.1.1 Layout of Console The layout of the operating consoles must be agreed and accepted by the operations team. Allowing operators to visit vendors facilities or to sites where the equipment is installed helps to establish preferred layout very early in a project. This practice also engenders ownership. The layout requirement of other types of equipment needs to be included e.g. radios, telephones, CCTV controls, etc. A number of different layouts are generally used throughout the industry ranging from a single tier approach (i.e. a number of screens side by side) to a two tier design (screens side by side and on top of each other). The design also dictates the number of keyboards and hence the maximum number of operators that may use the console at any one time. A concave curved console layout is generally preferred.
A console design with upper and lower screens above keyboards would give a single operator easy access. However in an upset if two operators were required access would be difficult. Similarly a console design with a number of screens side by side would give a single operator difficult access to all screens. To this effect the ergonomics of the design against the physical measures of the operator must be
RP 30-4
considered. It should also be noted that on certain systems upper screens have limited functionality.
Other consoles may be required for other users e.g. maintenance personnel, disturbance monitoring, operations management, DCS engineers, etc. These should be positioned away from the main control area, but preferably within visual range.
A prototype console in the form of a cardboard mock-up should be considered at an early stage in a project. This allows different configurations to be tried out ensuring the best design is achieved. This exercise may take the form of a complete cardboard replica or simply pictorial representation of the screens, ancillary equipment, etc., pasted to a wall to give the operating team a look and feel of the final design.
Adequate space should also be made available for any associated documentation and a writing area for the operator during his normal work tasks. 4.2.1.1.2 Other 'Control' Equipment Trip alarm panels may be installed in the console and if so should be placed in a position where the operator can access the controls (i.e. reset/defeat/accept). Any secondary information systems (i.e. management systems required by the operator) should be fed via the DCS console screens. If this is not possible then secondary information screens may be integrated into the operators console. Communications equipment (radios, telephones, etc.) will also need to be located within the console. This should be positioned to allow easy access and to particularly avoid having trailing leads running across screens (and possibly interfering with touchscreen mechanisms). 4.2.1.1.3 Disturbance facilities Where a control-room contains two or more teams of operators having different areas of responsibility, their activities may be co-ordinated, during a major upset, from a single disturbance centre manned by a process supervisor. The following issues should be considered:(a) (b) The consoles may be read-only with no control actions permitted. Special displays should be provided covering the whole plant or site controlled from that control room.
Enables the supervisor quickly to assess the overall context in which actions are being taken.
(c)
Access to all of the displays used by all of the operating teams
RP 30-4
Enables the supervisor to refer to the same information that the operators are using.
(d)
The supervisor needs rapid access to emergency operating procedures.

Where these are provided in electronic form, the disturbance centre must include access to these.
(e)
Appropriate communication equipment should be provided: radio, telephones, hot-lines to shift management and emergency services.
The overall disturbance centre design and its position relative to the other operator consoles, is an important aspect of the plant definition or site emergency procedures. It is essential that these are done as a co-ordinated activity during a project. The disturbance centre may also be used in quiescent times for the benefit of engineers, managers or others needing to access process information.
4.2.1.2
Control Room Layout The following issues should be considered in determining the controlroom layout:(a) The console or operating desk should be laid out in a concave curve.
This facilitates easier viewing across a number of screens.
(b)
Where there are several operating teams, an inward facing horse-shoe, oval or circular arrangement of consoles is recommended. The split and size of the consoles needs to reflect the operating strategy.
Walk-through gaps in the console delimit areas of responsibility, whilst facilitating communication between different operating teams.
(c)
ESD, F&G , and CCTV operating facilities are normally incorporated into the console. The monitors for these systems may be console mounted, (windowed into DCS screens), or remote mounted (ceiling suspended or wall mounted).
Such systems must be clearly visible at all times to the operators, and the same system may need to be seen by several teams of operators.
(d)
Large back-projected wall-mounted screens displaying plant or site over-view information may be used.
RP 30-4
The audience for this feature should be carefully considered. Display resolution may be insufficient for the normal control room occupants, however plant and site over-view information can be useful for controlroom visitors.
(e)
Communications equipment, (telephone and radio), should be readily accessible on the operating desk without moving from the normal operating position.
Vertical console mounting is often preferred as it leaves valuable deskspace free.
(f)
(g) (h)
Process documentation, (logs, night-order books, operating instructions, P&I diagrams, emergency procedures, &c.), should be readily accessible from close to the operating position, and there should be a convenient table or desk to spread out and use the documents and drawings. Consideration should be given to segregating the control-room from other parts of the building by a windowed corridor. A desk may be positioned away from the operating position for issuing work permits etc. This desk may also be used for interactions with tradesmen, visitors and other external issues.
This keeps non-operational personnel away from the operating area.
(i)
DCS Engineering should be performed in an adjacent room, separated from the control-room by clear glass partitions. The screens should be positioned where the operators can see them in use.
This enables the operators to see who is working on the system without the intrusion of non-operational personnel in the control-room.
4.2.1.3
Control Room Access Control The following issues should be considered in controlling control-room access:(a) (b) (c) (d) Access doors should be positioned to discourage the use of the control-room as a corridor to other parts of the building.
The control applications group may have a dedicated entrance.
Visitors should be able to see the control room without intruding by means of a windowed corridor (or other barrier, e.g.
desk).
permits etc. should be dealt with from a desk close to the access door or through a hatch. Other means of restricting access to the operating area may be considered, such as floor demarcation lines or illuminated signs.
RP 30-4
It is important that only those essential for plant operation have access to the operating area, especially when dealing with a critical disturbance when distraction by unwanted personnel can degrade operator performance.
4.2.1.4
Control-Room Lighting It is recommended that a lighting consultant is appointed to design the control room lighting. Consideration should be given to:(a) (b) (c) Closely focused and shielded down-lighting, different zones being individually adjustable for brightness. Operating screens should be hooded or provided with antireflection masks. Individual lights, adjustable for position, direction and brightness, may be provided for reading documentation or drawings.
There are two conflicting requirements on control room lighting:It is essential to avoid glare into the operators eyes and reflections from the operating screens; these are both distracting and tiring. and There must be sufficient light to allow documentation to be clearly and easily read, to avoid a depressing atmosphere and to help night-shift operators to stay alert. Research has shown that night-shift operators remain more alert if close attention is paid to lighting quality. The spectrum should match that of natural sunlight, and it should be comparable in brightness. It is not necessary, however, that it floods the entire room, but it may be contained in a non-distracting position to one side of the operators normal range of view.
4.2.1.5
Control Room Noise Recommendations are to provide:(a) (b) (c) (d) (e) (f) Good external and internal insulation. Acoustic ceiling-tiles. Carpets, carpet tiles or soft vinyl flooring in preference to hard surfaces. Shrouding console equipment cooling fans. Key-boards that minimise key-rattle. Printers located in a separate printer room, or substituted by PC based printer replacement system.
It is highly desirable that control-room noise-levels are minimised. All noise is distracting and tiring. It also interferes with communication
RP 30-4
between operators, between operating teams and with supervision in a disturbance. Noise also tends to raise anxiety and tension in a disturbance tending towards emotional instead of logical decisions and actions.
4.2.1.6
Control Room Interior Decoration Careful consideration should be given to the visual features of the environment. (a) Bright shiny highlights should be avoided.
They cause glare and reflections from the screens.
(b)
A series of different and distinctive features should be provided.

A typical control room may have a selection of mural paintings/ large photographs and groups of large potted plants. This allows the eyes and mind to restfully exercise and relax. Where control rooms feature an expanse of bare plain walls, operators feel a sense of disorientation and depression. The lack of external windows also causes a sense of time-disorientation leading to fatigue and lack of concentration. This can be reduced with dummy windows opening onto a large landscape photograph, with programmed lighting, (direction, spectrum & intensity), to follow a natural day cycle.
4.2.1.7
Control Room Furniture In general, the control-room furniture should be robust but comfortable. Colours should be chosen to blend with the rest of the decor, but should avoid shiny surfaces or bright highlights as these can cause glare or reflections from the screens. The following issues should also be considered:(a) Operating screens and keyboards may be console mounted, but should preferably be located on desks specifically designed for the purpose. Sufficient clear desk area should be available for the documentation that the operator needs to consult in performing his task. The desk should include sufficient clear knee-space and footrests to allow a variety of comfortable operating positions. Chairs should be able to swivel 360, and ride on castors. They should have a shoulder-high back with a fully adjustable lumbar support, seat-height and seat-tilt adjustments and may be provided with arm-rests. Arm-rests, if provided, should be chosen so mutual damage is not caused with the console where they come into contact.
(b)
(c) (d)
RP 30-4
The operator console chairs are in constant use, 24 hours a day, and get extremely heavy wear. They should be designed to be robust and hardwearing as well as comfortable. They should be replaced promptly if they become dilapidated.
(e)
(f)
Documentation tables should be large enough to spread out the largest drawings the operators need to consult; they may include drawing and documentation storage facilities in the base. Furniture for efficient storage and rapid retrieval of bound documentation, such as operating instructions, should be provided.
4.2.2
Equipment Location and Accommodation The control equipment should be installed in areas where the environmental conditions will not violate the vendors specification for temperature and humidity. The need to protect against ingress of dust particles and corrosive chemicals should be considered. Environmental control via HVAC is usually required for most applications. Heat load and temperature rise calculations should be carried out and input into the HVAC design. Digital equipment installed close to or within plant areas should be installed in housings which meet the required environmental conditions. Wherever practicable, local equipment rooms should be located in safe areas. Fire detection and protection should computer/electronic equipment rooms. be provided for
Computer equipment supporting higher level control schemes and information systems should be located in a secure equipment room where access can be controlled. 4.2.3 Spare Capacity and Upgrades Further to the guidance in section 2.3.2.3. Spare capacity should be provided for future site development and modification. Capacity for future development should be agreed with the client Business. The extent of spare capacity shall be specified by the user in tender or project documents and are job specific.
As the design develops and better definition is obtained it may be possible to reduce the spare capacity defined at FEED. It should however be remembered that the difficult areas to expand easily are equipment racks, power supplies and pre-wired controller and circuit board files. Priority should be given to retaining sufficient space in these areas. Slotting additional circuit boards into pre-wired files is relatively easy and boards can often be secured relatively quickly.
RP 30-4
The spare capacity should normally be evenly distributed throughout the system unless it is known that there is more potential growth in one area rather than another.
An examination should also be made of system capacity with regard to processor and communications loading.
Typically, the average loading should not exceed 50% at placement of order. The loading limits may vary depending on the system and should be discussed with the vendor.
As a minimum the spare capacity for the following items should be specified:(a) (b) (c) (d) (e) (f) (g) I/O points. Control processor capacity. Point database. Display database (particularly Graphics. Historical database. Communications network loading. Communications Gateway or interface units.
In addition to the specified spare capacity the system should be capable of future expansion without major changes to the existing hardware/software. 4.2.4 Power Supplies Electrical Power supplied to the DCS should be uninterruptible and plant operation must not be affected by short term supply variations. Careful consideration of power supply configuration is recommended to ensure optimum DCS availability. It is recommended that:(a) DCS power should be derived from two independent secure supplies. Power should be supplied to and distributed within the DCS in accord with the requirements for system reliability and the effect of failure on plant operation and availability.
(b)
4.3
System Functionality Detailed design of the hardware involves confirming and freezing the quantities and the arrangement of equipment. The frozen design should recognise the needs of all the system users and should encompass the requirements for system availability and ease of maintenance.
RP 30-4
The design should provide a reliable, well proven system in the simplest and most standard form to meet the project requirements. Equipment should be provided to cover all operational needs during both normal and abnormal plants conditions. Control functions should be allocated within the system hardware with due regard to plant integrity, common mode failure, cable marshaling, efficient use of equipment and segregation for maintenance. When allocating functions to non-redundant equipment the effects of on-line maintenance and reconfiguration should be considered. Typical activities during hardware detailed design are:(a) (b) (c) (d) Confirmation and freezing of DCS size in terms of controllers, I/O points, consoles, screens etc. Confirmation and freezing of DCS cabinet and console layouts and sizes. Design and layout of field termination cabinets (FTCs). Allocation of field cables to FTCs. Draughting of termination and cable schedules and loop diagrams. Design of cable entries and routings. Allocation of cables and cores ex DCS. Design and draughting of DCS-FTC and internal DCS cabling. Calculation of heat load and its distribution for input into HVAC design. Confirmation of power supply sizes and arrangement, catering for in-rush current requirements. Specification and procurement of non DCS vendor supplies, e.g. UPS. Design and draughting of distribution and fusing. Design and draughting of DCS earthing arrangements including any plant computer. Design and draughting of inter-system cabling and electrical isolation requirements. Typically for DCS-ESD, DCSMachinery Monitor, DCS interfaced packaged units, ESD interfaced packaged units, DCS-Plant computer. Design of ESD system operator plaques and integration into DCS consoles if required. Design of miscellaneous and telecommunication systems and their integration into DCS consoles. Design and layout of control room, equipment room, and any outstation rooms.
(e) (f) (g)
(h) (i)
(j) (k) (l)
RP 30-4
4.3.1
Interfaces Where a DCS needs to interface with other systems such as computers, PLCs, analysers, anti surge equipment, metering systems, plant protective systems etc., it is recommended that secure and field proven data links are used. As a minimum suppliers of DCSs should demonstrate well proven interface units to the following items of equipment:(a) (b) (c) Windows NT based PC's PLCs and other equipment using serial links with industry standard protocols. DEC VAX and UNIX range of computer equipment.
The preferred digital transmission protocols at the control network level should be deterministic. Therefore in general IEEE 802.4 Broadband Token passing hiway communications (deterministic) are advocated in preference to IEEE 802.3 Baseband type communication (non deterministic). Non-deterministic protocols (e.g. IEEE 802.3, Ethernet, DECnet etc.) are considered acceptable for communication at the plant/management information level.
LANs are usually designed so that the ratio of propagation delay to the packet transmission time is small. As this ratio increases the efficiency of LANs using CSMA/CD, i.e. IEEE 802.3 degrade, the problem manifesting itself when the ratio exceeds 20% and where at over 50% access to the network deteriorates dramatically. Arranging for CSMA/CD networks to run at high speeds with a high number of users is difficult as collisions become a major problem and throughput is seriously affected. IEEE 802.3 is non-deterministic and frames are not prioritised making it ill-suited for real-time applications. Deterministic protocols allow estimation of the worst case access time to the communication network (i.e. they are predictable, where as non deterministic protocols may be unpredictable). IEEE 802.4 is deterministic and can handle short minimum frames. Token bus supports priorities and can be configured to provide a guaranteed fraction of the bandwidth to high-priority traffic. It also has a high level throughput and efficiency at high loads. Where maximum percentage loading is kept below 30%, baseband networks behave as if they were deterministic due to the low traffic loading coupled with revertive checking on message sends and receives. This network configuration can offer advantages over IEEE 802.4 as the network may not be constrained by the token travelling time with messages being sent as capacity is available. Modified nondeterministic protocols may be acceptable where response times are not critical. Modified non-deterministic protocols usually limit the size of file that any node may transmit and utilise a re-try algorithm which changes the delay between re-tries.
The interface to PLC's and instrumentation sub-systems such as compressor antisurge equipment, should be by means of standard industry, e.g. Modbus B, Allen Bradley Data Hiway+. Likewise
RP 30-4
standards communication links e.g. RS422 or RS485 should be used in preference to RS-232C link, as many vendors use the RS -232C standard differently. TCP/IP is frequently used for the information connection layer (and to printers), and is becoming an industry standard connection level. TCP/IP and Ethernet interfaces are well suited to information hand off and X-Windowing into package PC's. Several DCSs now have databases that support SQL queries (e.g. Oracle), this allows the equipment to be connected to the information network (TCP/IP) to directly query the external package databases. This has the advantage of openness and no data tables.
In the event that a proven implementation does not exist for linking the required subsystem to the DCS, the following topics are recommended to assist in determining the suitability of the proposed linkage:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) (m) Type of link, unidirectional, bi-directional, etc. The security of data transmission. Parity checks, checksums, cyclic redundancy checks, etc. The length of transmission circuits. What are the limitations? What signals and pins are to be used. This can be shown later on a pin connection diagram. The type of cable and connectors required. Electrical isolation requirements and earthing. Data loading and transmission rates Maintenance, fault diagnosis and test facilities. The definition of logic levels. Power supply requirements and their location. Handshaking and clearance of signals. Timing, i.e. who does what and when? This can be shown later on a timing diagram. Protocols and the extent of protocol use. Are some protocol functions not supported? Initialisation and recovery from failure.
Interfaces to Protective Instrument Systems shall be designed to ensure that the integrity of the Protective System is not compromised by any fault in the plant control and display system. Where Protective System defeats can be applied by software action within the DCS, (single points or groups), a hard wired key should be used as a defeat permissive. The key provides security control against accidental or deliberate operation of the DCS soft defeat. Soft defeat links should be avoided where the protective logic is classified as safety critical.
Soft defeat systems are very cost effective as compared to hard wired key defeat systems, and provide functionality to improve measurement diagnostics and log operator and system events. The security and safety implications of connecting the protection system to the DCS must be considered in detail.
Signals used as part of the protection system should not be serially communicated to the DCS for control purposes. The requirement to
RP 30-4
segregate control and protection should be recognised and carefully considered.

Traditionally the protection system has been totally isolated from the DCS to avoid any common mode failure risk. DCS measurement diagnostic functionality provides accurate and high signal availability to challenge these traditional practices. Where dual signal usage is required, the signals can be wired to the two systems independently, (not by serial communication link, which would be a common mode failure point).
Interfaces to other connected digital devices shall be designed to ensure that the control system is fully protected from corruption and invalid commands emanating from any such connected system. The control system should support communication with smart transmitters in analogue (4 -20 mA) and digital communication modes. 4.3.2 Maintenance and Diagnostics The equipment should be provided with self diagnostic routines that allow continuous on-line monitoring of the software and hardware. The diagnostic functions shall run continuously and shall be capable of detecting a fault before system integrity is lost. It shall inform the operator of a failure and indicate the type of fault and the device unit or card to be replaced It should be possible to monitor and operate back-up facilities from the operators console, i.e.:(a) (b) (c) To initiate manual changeover from duty to standby. To monitor correct operation of automatic change-over. To monitor the status of both duty and standby equipment.
Where individual operating units are shutdown for overall, the hardware and power distribution, should be designed for the associated control and monitoring equipment to be isolated from the remainder of the operating equipment.
The arrangements for maintenance access to equipment should be considered, including arrangements for equipment segregation, powering and fusing of I/O circuits.
4.3.3
Control and Data Acquisition Control and data acquisition hardware should be provided to allow the plant to operate in a secure, safe and efficient manner. Control and data acquisition functions should operate in an integrated manner such that a process signal is terminated only once regardless of the number of uses within the system. Where I/Output cards are mounted separately from the processor, secure redundant communications should be installed for all control applications.
RP 30-4
High speed precision time tagging may be essential to identify a sequence of events which caused a plant emergency or shutdown (e.g. for post incident analysis). Some DCSs offer integrated sequence of event modules which may be used in preference to a separate 'sequence of events' facility interfaced to the DCS. Such systems should be limited to monitoring only the most critical field inputs and outputs. PLC systems should generally be used where there is a need for significant amounts of sequence control, batch logic or interlock logic or where there is a requirement to monitor and control a large amount of digital I/O. Some DCSs have fully integrated PLC modules removing the need to configure gateways to third party PLCs. Control and sequence processors should be capable of communicating directly with each other digitally over the system communications network.
RP 30-4
5.
SYSTEM CONFIGURATION 5.1 Man Machine Interface The DCS is the mechanism to view and control the process. The DCS is also the means to perform Advanced Control, Optimisation, Sequencing and Shut Down. DCSs should enhance an operators performance. Enhancement by performing the tasks that he does less well, e.g. routine and frequent monitoring, checking for bad data and then taking preconceived actions. This allows the operator to handle unexpected and unpredictable events. The Man-Machine Interface (MMI) is a key factor in the ultimate acceptance of the DCS by operators. The MMI can adversely affect the reliability of the plant if poorly designed. The Man-Machine Interface (MMI) must therefore be carefully designed. It is recommended that early in the detailed design a philosophy/specification document for the MMI is developed in association with operations staff and vendors specialists. Emphasis should be on operability rather than over complex or colourful graphics. The MMI specification should detail requirements for:(a) (b) (c) (d) Usage and layout.
consoles and screens
System Navigation.
display hierarchy, touch screen target areas & point selection, navigation between displays
Display Philosophy.
use of colours, flashing, reverse video, intensity, display of bad values or off scan points, equipment symbols, dynamic features
Data Presentation.
descriptions, controller parameters (SP, PV, OP, mode, alarms), number format, tag numbering convention, display of equipment status, engineering units
(e) (f) (g) (h)
Alarm handling and prioritisation. Parameter selection and data entry. Security.
access levels (view, operator, supervisor, engineer)
Display types.
overviews, specials e.g. ancillary equipment
The operator interface is the means by which the operator performs his tasks. It should be designed such that it simplifies rather than complicates the operator's task. The characteristics of a well designed operator interface are as follows:-
RP 30-4
(i) (j) (k) (l) (m) (n) (o) (p)
Consistent commands, rules, syntax and responses throughout the system Minimum number of commands, syntax and rules which the user is required to memorise. Minimum number of mental transformations to be performed on the data. Data, messages and prompts presented in a directly useable form. Minimum data entry. Ensure maximum use made of information available to the system. Provide effectively structured dialogues and/or selection lists. On-line aids such as help, summary displays, diagnostic aids. Computer algorithms for pre-processing of complex data before presentation to simplify decision making.
Mental processing operations which should be avoided by good design include:(q) (r) (s) (t) Complex commands and syntax. Commands, rules or syntax that are specific to a particular display, sub-system or software package. Memorising abbreviations and codes. Translating data into different units.
The latest BP Group experience on DCS MMI should always be sought when developing the MMI. On systems widely used by BP, existing configured display software, e.g. display symbols, trend facilities should be utilised. 5.2 Security A security strategy for the DCS including access to controllers and control configuration must be developed at an early stage to ensure subsequent safe and reliable operation. Means must be provided of controlling access to the various facilities in a secure manner (e.g. by key lock, badge reader or password).
The badge reader or password is preferable for individual engineers to enable an audit trail of changes to the system to be recorded. Instant log-in of operators must be available with ideally a facility for individual identification.
A minimum of three levels of access should be provided:Level 1 Level 2 Level 3 Operator Supervisor Engineer For normal operation of the plant Access to alarm settings, point processing, tuning parameters. Unrestricted access to the database.
RP 30-4
The DCS should also be split into process areas, which are attachable by configuration to Operator stations. Changes to functions within an area are then from stations configured to it and are view only from all other stations. Monitoring of process performance from remote stations should be limited to view only access. Potential risks to DCS security arising from connections to plant computers and through them to wider area computer networks should not be overlooked. Remote user access to a control system network should go through some form of firewall. This approach is widespread in the IT world, and can be a physical hardware device on the control network (e.g. Honeywell CM50), or it could be via a client/ server software product (e.g. @aGlance or PI). In both cases the user is not logged into the control system and has restricted access dictated by the firewall. Many DCSs have inherent security by using a proprietary network protocol (e.g. Honeywell LCN/UCN, ABB DCN, etc.). As control system products move to standard hardware and operating systems, particularly Windows-NT, they become more vulnerable to unauthorised access ("hackers"). This is a potential drawback to "open systems", however it does not present a problem if addressed carefully. The weak links in external security are the connections to the outside world (modems, bridges, LAN/WAN connections, etc.). All remote access over open telecommunications systems, for example modems, should only employ dial-back facilities and should have a means of intelligently recognising the client system. The simplest form of security is keyboard password protection, however it is also the easiest to overcome. A growing range of high security systems are now available, and consideration should be given to the use of these systems e.g. photographic recognition, electronic ID tags, voice recognition. Engineer changes should have a full audit trail with individual identification against each system change. 5.3 5.3.1 Information Display User Requirements The DCS operators needs are paramount in the design of the displays. The DCS operator is required to perform:(a) (b) (c) (d) Process monitoring and control Diagnosis of abnormal conditions Responses to alarm conditions Planned changes in operation.
RP 30-4
Achieving this functionality from a VDU based system has some inherent difficulties, due to the restrictions on information presentation on a single screen, which increases the difficulty of a rapid overview and pinpointing a problem. Inspecting and modifying system hardware and software should all be provided by standard system displays. Systems provided to communicate additional information to the operator should be integrated into the operator displays. 5.3.2 Providing the Functionality The functionality required of the operator station is generally met by the provision of the following classes of displays/features:(a) Overview displays for steady-state monitoring.
The provision of overview displays, to enable the key process variables to be monitored, is an attempt to overcome the restricted process window. Experience has shown that standard vendor offerings are of limited use, and are often replaced by custom displays. Even these tailored solutions, however, are not commonly used by experienced operators
(b) (c)
Customised Graphic.
In addition to operating schematics, customised graphics provide useful status, summary and information displays.
Clear Identification of Abnormal Conditions (Alarm Displays).

Effective alarm summary displays and the linking of process operating graphics to the alarm system is a major step in providing an effective operator plant interface.
(d) (e)
Help Displays for Unusual Conditions.

A Windows-based system offers the opportunity for help information to be dynamically altered to match the plant conditions.
Task Oriented Displays

'Task oriented' displays offer advantages over the conventional process graphic. These displays should be structured to guide the operator through a particular task and should minimise the number of screens required to carry out the task by careful selection of the relevant data, and by the judicious use of windows or sub-pictures.
(f) (g)
Detail Point Displays.

Database point configurations are accessible showing all point parameters and attributes e.g. tuning constants and alarm settings.
Controller Face-Plate Displays.

These provide an easy conversion route for operators familiar with panelbased instruments.. Where these are grouped in displays, they should be configured show the relationship between linked controllers, and allow quick access to parameter trending.
(h)
Trend Displays.
The ability to display recent history for a selection of parameters is a valuable aid to process problem diagnosis and solution. Displays for related variables showing process variable, setpoint and output both digitally and in bar graph form is also a very useful feature. The ability to trend the PV, SP and OP aids control performance monitoring.
RP 30-4
It is recommended that the plant be controlled via custom built operating schematics. Where grouped displays are used, they should generally correspond to the operating schematics, and should be selected by targets on the operating display. Easy access to point detail displays is needed from operating schematics to carry out point parameter modifications. A convenient method of implementing this link is to provide a detail target which is brought up when a point is selected on the display. 5.3.3 The Display Hierarchy The display hierarchy should assist the operator to scan the process he is controlling, and to rapidly identify a process disturbance. The operator needs to be able to 'walk through' the process he is controlling and to rapidly pin point any process disturbance. The display hierarchy must reflect these needs. The structure of the hierarchy will be dependent on the size, process complexity and the split of responsibilities between operators. The DCS database structure must also reflect the link between operator stations and plant areas. This is generally achieved by the concept of plant areas and units. A plant area is associated with a console, which limits alarm annunciation and control access to the designated area. Hence the custom graphics must follow the same structure. At any console, however, a total plant view is a desirable feature. The interlinking of process areas needs to be considered in the display design, possibly by repeating plant data from adjacent areas. Typically four levels are generally needed in the hierarchy for all except the simplest plants. The hierarchy should be accessible from any level. Typically the levels can be classified as follows:Level 1: Plant/ Site Over-View
Plant over-view schematics; site-wide utility and network schematics; interface to plant-wide control systems e.g. economic optimiser. Over-view of one plant area, that requires several unit schematics for operation. Includes the interface to multi-variable or other advanced controls that affect the whole of that plant area. Interface to F&G, ESD, control sub-systems covering that area. Level at which all individual measurements and PID controllers are displayed on process unit schematics. Any area may be divided into typically from three to fifteen units, (e.g. a distillation column may be divided into feed; base/ reboiler; overheads; column profile). Interfaces to small-scale advanced controls specific to that unit may be provided at this level. Trend displays are typically accessed at
Level 2: Process Area
Level 3: Process Unit
RP 30-4
Level 4: Detailed Displays
this level. Focus on a single controller, measurement, interlock, subsystem, etc.
An additional level of detail may be required on some items of equipment such as furnaces, complex columns, rotating machinery. Links from selected points on a process graphic to the point detail are required for point parameter updates. Operator actions will usually be carried out from unit control level, or below. The displays need to be linked both vertically - giving more detail as one moves down the hierarchy - and horizontally, so that the operator can move through the plant at the overview or control level.
The Area Overview display consists of a process block diagram for that part of the plant showing the main units within that area with targets to the Unit Overviews. It may also include some key process parameters and alarm indications and include important parameters that are related to each unit. It is at this level that the operator would interact with plant optimisers, and set targets, however it should not be possible to control the plant directly from this level. Production rates and key plant performance indices may also be included. The Unit Overview consists of a display showing main vessels and equipment within that unit with targets to the operating schematics. It may also display key process parameters and alarm indications.
There are three types of targets: display navigation, which brings up a different display; display further detail, normally on the same display, operator interaction with the process. Targets should be clearly identifiable, either overtly, or if covertly, the so called invisible targets, they should be recognisable by some distinct feature, e.g. a vessel detail may be accessed by its equipment label forming a target which is identifiable by being displayed in reverse video The allocation of loops within a group display should show any relationships between master and slave cascade loops. A loop may appear in more than one group display. Group displays should be configured for different operating tasks e.g. unit start-up, catalyst regeneration. It should be possible to page through group displays in parallel with task procedures. It should be possible for the operator to configure a set of group displays for temporary use.
Help displays and task oriented displays (e.g. for non-routine tasks such as plant start-up, shutdown, optimisation, etc.). are normally configured at the unit level of the hierarchy.
5.3.4
Access/Navigation Experienced operators require fast access to the unit control displays. Inexperienced or infrequent users require a means to move through the hierarchy in a structured manner, which is clear and consistent. The needs of the operating task must be reflected in the linking of displays, and the data selected for a given screen. The design should
RP 30-4
address the need to minimise the number of display screens the operator must access to carry out a task, balanced against not overloading the screens with information. Screen overlays or windows can be incorporated to minimise screen switching. Multiple methods of display call-up should be provided. facilities provided are:(a) (b) (c) (d) (e) (f) Typical
Direct access from user configured keys on the keyboard. Touch screen targets. Manual Data Entry. Dedicated Function Keys e.g. Alarm Summary. Mobility Keys e.g. Prior Display, Page or Display Forward/Backward. Smart Targets - logic behind a target makes a decision on the display to be called, e.g. the active equipment in a duty/standby configuration.
On process schematics, the feed, utility, and product labels can serve as the display targets for moving through the process. Alternatively, a section on the display can be reserved for the display targets.. When moving down through the hierarchy, targets may be provided within the graphic representations of sub-units or equipment. To simplify navigation through the hierarchy, the level on view at any time should either be explicitly indicated, or clear from the display title or layout. A "Help" display showing the hierarchy should be provided. Multi-page listings of information, should be associated by a page linking mechanism, (indicating page x of y). Direct access should be provided for commonly used displays, by the use of configured function keys/buttons. 5.3.5 Custom Replacement of Standard Displays The use of custom displays to replace standard displays is not generally recommended, as the mechanisms to provide the functionality required can often prove complex, and difficult to maintain. Replacing vendor displays with custom displays should only be considered when the vendor displays are not fit for purpose, and a more effective interface can be provided, examples are generally restricted to Alarm Overviews, Process Area Overviews, and Trend Displays. If custom displays are developed to replace vendor standard displays, then access to the superfluous displays should NOT be possible. 5.3.6 Data Access/Change Facilities The process of entering a value into the system consists of three steps:-
RP 30-4
(a)
Point Selection The selectable data on screens should be clearly identified, either explicitly e.g. by a target box, or by following a simple convention, e.g. all variables are selectable. Selectable data entry fields should be sufficiently spaced to make "pointing" to the field an error free task. When this is not possible, for example when lists of data are presented, the fields should be laid out so that tabbing keys can be used to avoid selection mistakes. Whilst a point is selected, it should be highlighted on the main screen.
(b)
Parameter Selection Following point selection, an overlay (e.g. Change Zone), or window should appear on the screen which displays the parameters the operator is most likely to change. Selection of the parameter to change may then be provided by targets (in the change zone), or by special function keys which are only active when a point is selected.
(c)
Data Entry The format of entered information should be consistent with the form in which it is displayed. The format of specific data types should be consistent throughout the system. For entry of numerical values the operator should be able to view the new value alongside the old value before pressing "ENTER" to complete the transaction. It is essential that no change to the process can be made by a single unconfirmed operator action.
5.3.7
The Use of Colour The effective use of colour can enhance visual clarity, and convey information in a succinct form. It can draw attention to screen areas and serve to highlight items of significance. Poor use of colour, such as insufficient contrast between foreground and background colours, or excessive use of bright colours can actually diminish the visual clarity of displays. The key factors to the effective use of colour are:(a) (b) (c) Use conservatively - avoid making the screen too "busy". Use as an aid to code data or in structuring a screen. Make use consistent with traditional expectations.
RP 30-4
(d) (e) (f)
Use colour coding in a consistent manner on all screens. Use colours with high contrast to draw operator attention. Use bright colours on a dark background, or vice versa.
The human eye has a sensitivity to colour which is not uniform in the visible spectrum.
The apparent "brightness" of colours is shown in the following table, which may be used to aid the selection of foreground/background colour combinations, to ensure sufficient contrast. White Yellow Cyan Green Red Magenta Blue 10.0 7.6 7.4 7.1 4.7 3.7 2.7
(Reference - The Effective Use of Color: Physiological Principles, by Gerald Murch, Tektronics Inc.)
A consistent design philosophy for the use of colour must be established. The preferred technique for operating schematics is to use "cool" colours for less important information and "warm" colours for items of importance. To provide sufficient contrast, black has traditionally been used as the background colour, however, Microsoft led/ compatible applications use low intensity white (grey) for a background colour. The choice of the main screen background colour will determine the colour combinations that are easy to read and work well at getting the operator's attention. The windows environment also permits a great deal of flexibility in display design. It is possible to include photographic images or simulated 3-D representations of pipes and vessels. It is important to avoid cluttering the schematic with detail that would detract from the operators primary task of quickly identifying and correcting disturbances to the process. Because the Windows environment low intensity white back-ground lowers the relative contrast with other colours, (compared to the traditional DCS black back-ground), more attention has to be given to the issue of drawing the operators attention to important abnormal data in the display. Icon use, for example allows a single object to be displayed that contains a high contrast, and in this case a black border around a red or yellow symbol gives a stronger visible impact than the same red or yellow directly against the low intensity white background.
The use of warm and hot colours (e.g. yellow, red) in a high-contrast situation should be reserved for alarms and indications of abnormal conditions. The design of back-grounds and fixed information should be subdued and not conflict with the usage for alarms and abnormal conditions. Variable but normal information, (analogue values, digital states, messages), should be clearly distinguishable from fixed information, using cool colours (e.g. green, cyan) against a back-ground chosen for ease of readability.
RP 30-4
A typical use of colour is as follows:Main Process Lines/ Equipment Subsidiary Process Lines Utilities Process Variables: Normal Low priority alarm High priority alarm Emergency Faulty Cyan Cyan (low intensity) White (low intensity) Cyan Yellow Red Red Magenta
5.3.8
Display of Fixed Information Displays should be headed by an informative title, which always appears in the same position and the same colour.
It is useful to display the system file name as part of the picture Information density and the use of colour/intensity must ensure that the screen is not cluttered and important information is easily distinguishable. The fixed (static) information should be displayed in a subdued manner, so that it does not distract from the variable data fields.
The format for labels should be consistent and equipment labels should be adjacent to or within the equipment symbol. The engineering unit descriptors should be as concise as possible without incurring ambiguity.
Care must be taken on identical units that the unit identity is clearly visible - by the use of colour or highlighting - so that there is no danger of the operator mistakenly making changes on the wrong unit.
Process representation should be adequate for operating needs, and not be cluttered by too much P&ID detail. Operating Schematics should normally be broken down such that they contain typically no more than thirty indicators or control points. Standard equipment symbols should be used conforming to PFD/P&ID practice. Duplicated equipment such as exchanger shells need not be represented. One symbol will suffice. Measurement locations should be indicated. Controller connections should be shown by lines which are differentiated from process lines. Displays should follow the process flow from left to right and/or top to bottom. The use of arrows should be kept to a minimum.
RP 30-4
Incoming feeds and outgoing products should be labeled.

Visual clarity is aided if the major process flows are distinguished from the rest by intensity or line width.
Tag names and descriptors should be easily accessible, but not permanently on display. It should be ensured that the requirements of advanced control and optimisation are considered, and properly integrated with the plant control displays, and should be seen by the operator as a seamless extension to regulatory control. 5.3.9 Display of Variable Information The value format for a point should be to the resolution needed by the operator and consistent wherever it is displayed. A clear convention should be adopted for displaying values which are off scan or bad. Colour is recommended as the means of conveying the status of the process variable.
The recommended convention is:Colour Cyan Red Yellow Magenta Status Normal Emergency/ High Priority Alarm Low Priority Alarm Faulty Unavailable
5.3.9.1
Controller Display The four variables commonly displayed for any regulatory controller are: setpoint, process variable, controller output and mode. These values may be grouped together in a controller box. The mode of a controller may be represented by colour and/or text. Abnormal modes of operation, e.g. when a cascade control is broken, should be highlighted. The controller output can be represented by a horizontal bar graph, colour coded to highlight if the output is saturated.
5.3.9.2
Valves with Associated Position Indications Use a solid symbol for a closed valve and a hollow symbol for an open valve as per the P&ID convention. Colour is then used to denote normal/abnormal states, e.g. cyan for normal and red for abnormal. The colour of the abnormal state should correspond with the alarm priority colour. Magenta should be used to indicate faulty inputs, and
RP 30-4
blinking colours to indicate valve in motion where such feedback is available. It is important that the operator has a reminder on the display for valves which are linked to a trip output. This may be done by the choice of symbol and additionally by the use of the text 'FO' or 'FC' to indicate fail open or fail closed. For Motor Operated Valves with remote control facilities and limit switches the display must show the valve status: open, closed, moving and any abnormal condition. During a transition, an alarm should be given if the expected position is not achieved in the given time period. Valves in transit should be displayed flashing.
Valve status can also be used to selectively highlight current pipework routing
5.3.9.3
Equipment Status Use a hollow symbol for running and a solid symbol for stopped. Colour may then be used to denote whether this is a normal or abnormal state. Although spared equipment need not be explicitly shown on the graphic, dynamic labels should be used to indicate which item is in use.
5.3.9.4
Control Switches Control schemes which incorporate switches require a dynamic indication of the switch position.
5.4 5.4.1
Data Entry Physical Devices The data entry interface to the DCS should consist of the following :Keyboard and Screen Pointer - e.g. mouse, tracker ball, touch screen, light pen (a) Keyboard The Keyboard should contain the following functionality/keys:Standard computer QWERTY keyboard. Programmable operator function keys, which provide easy access to frequently used operating graphics. A facility to allow
RP 30-4
easy modification of the Function Key legends should be available, preferably electronically. Engineering function keys - for housekeeping, configuration tasks, etc. Standard operator function keys - these would include commonly employed operator actions such as raise/lower buttons, mode selection keys, alarm acknowledgement, etc. Where possible the keyboard should be adjustable/tiltable and separate from the screen to allow the operator to find a comfortable working position. Additionally the keyboard should have a matt surface to avoid reflective glare. Where possible keys should be full travel (rather than membrane) with some form of protective covering against dirt and liquids. Combined operating and engineering keyboards should be utilised if possible. If however the number of keys specific to configuration and housekeeping are numerous two separate keyboards should be used. Easily removable covers are then required to protect the engineering keyboard whilst the operating station is in use. Where configurable annunciator lamps (e.g. LEDs) are used in conjunction with operator function keys there should be at least two levels of alarm priority. These lamps should also be clearly visible under all normal lighting levels. (b) Screen Pointers The most widely favoured types of pointer device suitable for DCS are:(i) Touch Screen Touch-screens can be slow, have coarse resolution, poor accuracy and be errorprone. They also cause fatigue in the arm if used for long periods. They require a facility for automatic alignment. A switch to disable the screen for cleaning purposes is desirable. The mouse is a quick device, it has good resolution and is accurate. Its lack
(ii)
Mouse
RP 30-4
(iii)
Tracker Ball
of robustness is offset by its low price The tracker-ball is as accurate as the mouse and has the same resolution, but it takes substantially longer for the operator to reach a specific screen location. It is more robust than the mouse.
For consistency the cursor associated with a pointer device should appear in the same initial position on displays to enable the user to quickly locate it. There is also a requirement for the cursor to be easily seen yet not obscure characters underneath. Studies indicate that users are particularly receptive to a blink frequency of around 3 Hz.
5.4.2
Functional Aspects The method of entering information needs to be consistent, in particular:(a) (b) (c) (d) The format in which the operator enters information. The same keys should be used for the same functions throughout the system. The use of shift keys should be avoided. Procedures (i.e. keystrokes) for carrying out similar or related operations
All operations (e.g. input, cursor movements) should provide immediate feedback to the operator. The preference is for visual (e.g. target changes colour) rather than audible feedback. The system should be designed to minimise data entry requirements, to reduce the likelihood of error. This can be achieved by structuring dialogues effectively and by using display options, rather than having to memorise strings of commands. The system should further minimise the possibility of operator errors through facilities for detecting (e.g. data validation) and handling them. This is achieved by communicating the error through meaningful messages, highlighting the fields in error and prompting for corrections.
Examples of data validation for error prevention include:The use of standard system features such as absolute setpoint and output limits. and Limiting the magnitude of operator entered setpoint and output changes. This feature may not be offered as standard and may require specific software to be written.
RP 30-4
There should be a minimum of one verification step if the operator is about to execute an action from which it may be difficult to recover. Screen pointer devices should be used to move around displays, with operator actions of consequence (i.e. irreversible changes e.g. initiating a shutdown) shall require confirmation by use of an appropriate key (e.g. enter) to commit the change. For operator transactions that do not impact on plant (e.g. screen navigation) a dedicated key that would immediately reverse the last command is advantageous. 5.5 Alarm Systems The objective of alarm handling is to give the operator as much early warning as possible of a process problem which requires action from him. To achieve this, a DCS should offer:(a) (b) (c) clear and unambiguous information as soon as possible a fast route to the corrective actions required the least possible opportunity for mistakes.
For every plant an overall alarm strategy should be defined at an early stage of design in full consultation with plant operations personnel. This should be maintained, and adhered to throughout the life of the plant. A clear policy of alarm presentation is required. This should consider how alarms and information from other systems such as Shutdown, machinery monitoring and laboratory relate to the operators tasks and how they will be presented. To control the number of alarms defined on the P&I Diagrams the purpose and priority of each alarm should be recorded, in an Alarm Response Manual. The alarm handling process can be classified into a number of distinct and separate functional areas: (d) (e) (f) (g) (h) (i) (j) (k (l) (m) (n) Alarm Definition. Alarm Detection Mechanisms. Alarm Prioritisation. Association of Alarms with Plant Areas or Process Units. Audible Warning, the first indication of a problem. Alarm Identification or situation assessment. Corrective Action: minimising the consequences and restoring normal operation. Alarm and Event History Reporting. Alarm System Management and Engineering Utilities. Point Processing. Alarm Reduction Mechanisms.
RP 30-4
5.5.1
Alarm Definition An alarm is a warning to the operator that immediate action from him is required. If an alarm exists on the system for which no immediate operator action is appropriate, it should not be an alarm. Its presence on the system distracts the operator from his main task in an upset; the presence of many such alarms is a potential safety hazard because important alarms may thus be hidden from the operator. An alarm is to be distinguished from other plant status indications, discrete value information, sequence messages, and batch reports. Whilst the operator must have ready access to such information through his displays, he generally does not require to take any immediate action, and thus does not require it to be drawn to his attention through the alarm mechanism.
5.5.1.1
Operating Instructions During a process upset, the DCS Operator's task is primarily one of responding to alarms. The Operating Instructions must compiled in close association with the alarm definition to ensure that for each alarm there is a clear corrective action. Where no clear action can be identified, there should not be an alarm.
5.5.1.2
Process Design Considerations Process design, Safety and Operability Studies, AMHAZ, and post disturbance enquiries should consider:(a) (b) (c) Total quantity of alarms which may occur following a given disturbance. Rate at which the new alarms can occur. Time taken to perform the corrective actions required following each alarm.
This will clearly identify whether the demands being placed on the operator are realistic. Where an alarm reduction mechanism is included in the system, an AMHAZ study should be performed. 5.5.1.3 Alarm Response Manual Each plant should possess a properly maintained Alarm Response Manual containing a list of alarm definitions, including:(a) Tag number and duty description.
(e.g. vessel, location, sensor type)
RP 30-4
(b) (c) (d) (e)
Type,
(e.g. deviation, rate of change, high absolute)
DCS configuration parameters.

(e.g. threshold, deadband, priority, process unit, message text)
Justification.
(why it is there, reference to safety studies, incident reports etc.)
Required operator response to alarm.

Management should ensure that process design and HAZOP engineers have sufficient understanding of the capabilities and limitations of DCS alarm handling to make appropriate design decisions. The ARM should embellish the need to reduce the number of alarms to those needed to inform the operator to them take action to avert an upset condition.
5.5.2
Alarm Detection The objective of alarm detection should be to give as much early warning as possible that there is a problem whilst minimising unnecessary or nuisance alarms. To achieve this the most appropriate alarm detection mechanism should be chosen for each parameter. The following detection mechanisms should be used as and where appropriate:Absolute Absolute alarms should be used only where there is an absolute value of a parameter which must be avoided e.g.:- Safety valve setting, Trip threshold, Tank or vessel over-flow, Low vessel level on pump suction. Their unrestricted use in other places can give rise to an unnecessary quantity of nuisance alarms. Deviation Deviation alarms are useful for parameters which are directly associated with a control loop, especially cascade slaves. Rate-of-Change Rate-of-change alarms are useful for parameters which have a wide range of normal values but which do not normally move very rapidly. Statistical Where the DCS is running a statistical process control package, a variety of statistical alarms are available which are noted for their ability to give early warning of real problems whilst minimising nuisance alarms.
RP 30-4
Recipe Driven
Recipe driven alarms are useful for multi-product processes, or for processes with multiple operating modes. Most DCSs have some sort of recipe facility for sequential control and batch processes these can generally be adapted to modify alarm parameters according to logical combinations of plant data. The recipe should permit all alarm parameters to be changed in response to a change in the operating mode of the unit, including:Thresholds, Priorities, Dead-bands, Trigger and reset delay times. The recipe or other standard features can be used as a means of alarm suppression on units which are shut-down or undergoing regeneration.
5.5.3
Alarm Prioritisation The objective of alarm prioritisation is to define the order in which an operator should take corrective action when a number of alarms are present. The priority of an alarm thus defines the degree of urgency associated with it, and typically is dependent on a number of factors, including:(a) The severity of the consequences, (in safety, environmental and economic terms), of failing to take the corrective action associated with the alarm. The time available and required for the corrective action to be performed and to have its desired effect. The state of the rest of the plant, and in particular, what other alarms are active.
(b) (c)
None of these factors are fixed, and they can vary in subtle and complex ways with the state of the plant. Therefore determining the correct alarm prioritisation requires a great deal of thought and effort at the process design stage. Every plant should have a clearly defined strategy on alarm prioritisation so that later additions or modifications retain consistency. The objective is to reduce, as far as possible, the burden on the operator in deciding which high priority alarms he must attend to first in the early stages of a process disturbance. An alarm which annunciates that equipment has tripped should always be given a lower priority than the pre-alarm which warns that the trip is imminent but can be avoided with corrective action.
RP 30-4
If insufficient time exists for corrective action between pre-alarm and trip, the need and design of the pre-alarm should be reconsidered. The following prioritisation guidelines are suggested. Alarm Priority Emergency High Low Journal No Action 5.5.4 Method of Assigning Immediate operator action required to resolve an imminent loss/plant shutdown condition Rapid operator action required to resolve a probable loss condition Prompt operator action required to resolve a possible loss condition - Default Setting Condition Historised - for record purposes Alarm not required
Association of Alarms with Plant Areas or Process Units Each alarm should be associated with the process unit where the operator must take action when the alarm occurs. In some cases, especially utilities, a disturbance may have repercussions in several areas, so an alarm must be associated with several process units.
In many DCSs this may mean replicating the alarm detection algorithm. The alarms may have different consequences and requires different corrective actions on each unit, it may therefore require different thresholds and priorities on each unit.
5.5.5
Audible Warning The audible warning should convey as much information as possible about the nature of the alarm, its priority and the plant area affected. Discrimination of Priority Low volume sounds with a slow pulsation frequency should be used for low priority alarms and higher volume sounds with a rapid pulsation frequency to denote higher priorities.
In some circumstances it may be appropriate to only visually and not audibly alarm low priority alarms.
Discrimination of Plant, Area or Unit
Consideration should be given to distinguishing plant areas by using sounds with clearly distinguishable characteristics.
It is not advisable to use different pitches; few people have perfect pitch and in isolation they can be misinterpreted.
RP 30-4
Tones of the same fundamental pitch, can have quite different characteristics which are easily discriminated both together and in isolation.
Operators can rapidly learn to identify the particular sound which represents his area of responsibility, and to ignore others.
Achieving Audible Discrimination
Most current DCSs provide a set of relay contacts, which can be programmed to respond to different alarm priorities. By connecting these to sounders provided with interrupter circuits of different pulsation frequency, the bleep frequency can be made to vary according to the priority.
Sounders can be purchased with different tone qualities to distinguish different plants or plant areas. Alternatively, by mounting the sounders on bases with different resonant characteristics, clearly distinguishable noises can be produced. 5.5.6 Alarm Identification and Situation Assessment The way in which alarms are presented is of utmost importance in determining how effectively the operator can take the appropriate corrective action in a process upset. When more than one alarm is present, the system should allow the operator to identify quickly and easily which alarm he must respond to first. It should also allow him to assess the situation on the plant as a whole since this may affect his actions. Human factors research clearly indicates that the best means to assess a multiple alarm situation is through a pattern recognition display system; (a) Pattern Recognition Based on Rectangular Grid
Traditional annunciator panels are often cited as the reference against which DCS alarm handling should be judged. Some DCSs provide a basically similar grid-array of alarms. On other systems, it is possible to use the graphics to configure one. The limitation of the rectangular grid is that it contains no process data, and so other displays must be consulted to allow the operator to assess the situation on the whole plant and make appropriate decisions on the corrective actions.
(b)
Pattern Recognition Based on Plant Over-view Schematic

An alternative to the rectangular grid is to use differently shaped icons or symbols to represent the different units of a process. These can be linked forming a schematic overview of the process also containing the values of
RP 30-4
key plant parameters. The icons can be configured to change colour and blink to represent the status, acknowledgement, priority and location of the active alarms. Where appropriate the sequence of occurrence may also be indicated. This helps the operator assess the situation by giving him a large amount of information which can be rapidly assimilated.
5.5.7
Corrective Action When a new alarm occurs, having identified the alarm and assessed the situation on the plant, the operator must be able to access the relevant schematic display and perform the appropriate corrective action quickly. There should also be an easily accessible reminder of the action appropriate to that particular alarm. This is particularly important for events which occur infrequently, and for inexperienced operators. There should be a mechanism to remind the operator of which alarms are still waiting for attention. When several alarms are present, it may be difficult to identify which have already been dealt with and which are still awaiting attention. This is especially important at a shift change, but may also be important in a complex upset situation or when two or more operators are involved in the corrective action process.
5.5.7.1
Display Considerations Alarms of all types should blink when triggered, and remain blinking until acknowledged by the operator, then remain steady until the parameter returns to normal. The use of colour for alarm states must be consistent across the plant, and should conform to common expectations. Colour may be used to denote priority, and types of alarm, (e.g. reserving magenta for instrument or system faults). Alarm colours should be chosen to be readily distinguishable from the remainder of the schematic display.
Systems which allow varying blink frequency may use this to denote priority, a fast blink indicating a high priority.
Parameters in alarm should be denoted by changing the displayed value (back-ground or both) to a brighter (hotter) colour. Where appropriate, a single character to distinguish the type of alarm, (High, Low, Deviation, Rate, Fault), can be displayed. Alarms associated with parameters which are not available as analogue values in the DCS should be displayed either by brief and unambiguous identifying text or by an icon or symbol. These are normally invisible and become visible when the alarm is present, or they may change shape or colour or both, a key or touch-target should be provided to make invisible items temporarily visible for diagnostic and system management purposes.
RP 30-4
5.5.7.2
Annunciator Buttons and Display Navigation Once the operator is aware of, and assessed the upset plant condition, the display where corrective action is taken should be accessible as quickly as possible.
Some systems have and associated display parameter linked to each alarm. A single operator action (pressing the associated display button) will call the display where the operator actions relating to that alarm can be performed. Most DCSs provide annunciator buttons with LED's which can be configured to respond to alarms, and which call the appropriate schematic display when pressed. There are rarely enough of these buttons to satisfy the requirements of larger plants, so some further display navigation is required. The system should be configured to make this as direct and efficient as possible.
Corrective action across a number of displays can be inefficient. Appropriate task-specific displays should be considered which can expedite corrective action. 5.5.7.3 Alarm Acknowledgement Ideally the operator should only be able to acknowledge an alarm from the display on which he must take the associated corrective action. The current practice on alarm acknowledgement is for the operator to acknowledge the alarm as soon as he has identified it. It is preferable to use the alarm acknowledge status as a reminder of which alarms have been dealt with and which still require attention. Therefore operators should be trained to leave each alarm unacknowledged until the associated corrective action has been performed. Most DCSs can display a list of unacknowledged alarms as a check on what actions are outstanding after an upset.
It is important that operators know the differentiation between the Alarm Acknowledge function and the Horn Silence function.
Some DCSs provide alarm acceptance mechanisms which cause all of the active alarms on a schematic or in a process area to be acknowledged at a single key-stroke; the use of this mechanism should be avoided if possible. 5.5.7.4 Links to Operating Procedures It is possible to use some current DCSs to display a reminder of the corrective action procedure. Some DCSs provide functionality for Help or Associated displays which can be customised for this purpose, others allow hidden text to be displayed on schematics in response to logical conditions. These facilities should be used when available.
RP 30-4
5.5.7.5
First-Up Indication For some operations it is desirable for the operator to know in what order a series of associated alarms occurred. Whilst the current alarm summary provides this information, it is not accessible at a glance, since the alarms associated with the group of interest may be scattered amongst a number of others, and the mechanism depends on reading and interpreting text. An extra flag or highlight on the schematic display against the oldest unacknowledged alarm would satisfy this requirement.
RP 30-4
5.5.7.6
System Alarms Every DCS has a number of alarms associated with its own internal self-checking. These also require operator actions which may vary from putting control valves onto by-pass, to telephoning for call-out assistance or even shutting the whole plant down. Virtually all DCS Manufacturers provide an entirely separate and different mechanism for handling system alarms, and do not provide facilities for incorporating the alarm states into schematics or linking to operating instructions. This can lead to confusion and incorrect operator response. Until DCSs provide more flexibility in this area, the systems must be supported by clear operator guide-lines and effective training.
5.5.8
Alarm and Event History Reporting DCS alarm and discrete event history is held in a database from which enquiries can be made and reports generated. Process and System Engineers will make use of this data for post-event analysis, alarm utilisation audits, operator response monitoring and process troubleshooting. It is advantageous to export the raw data to other systems (PCs) to provide adequate analysis. For operator use, a number of pre-defined report structures should be available which are readily accessible from a DCS screen menu. Most DCSs provide this as a standard facility, others have an applications programming capability which can be used to provide this.
5.5.9
Alarm System Management The objectives of DCS alarm management are:(a) (b) (c) Safe and efficient operation of the plant. Rapid recovery from upsets. Facilitate the operator's task at all times.
There must be procedures and facilities for:(d) (e) (f) (g) Change recording. Auditing. Alarm database management. Monitoring and Reporting, e.g. suppressed or inhibited alarms.
RP 30-4
5.5.10 5.5.10.1
Point Processing/ Alarm Conditioning Process Variable Filtering Analogue input processing points should have the facility to filter the incoming field signal. By generic type some field signals are more prone to noise than others. This noise if not dealt with can provide an operator nuisance alarm problem in addition to providing a burden on further system processing including:(a) (b) (c) communications overloading which degrades system performance. quicker data loss on system logs and/or history files inferior performance of calculated data which uses the noisy data
A certain degree of filtering is therefore considered prudent. For controllers the degree of filtering should be individually set during loop tuning. For non controller points the filtering is recommended according to the following list:Point Type Flow Level Pressure Temperature Filter Constant 0.04 mins 0.04 mins 0.02 mins 0.00 mins
5.5.10.2
Analogue Point Alarm Deadbands/ Digital Point Alarm Delay Time Alarm Deadbands are recommended for use in reducing the degree of unnecessary dynamic cycling of alarms on analogue points. Dynamic alarm cycling will be reduced with the prudent selection of signal filtering and the selection of alarm thresholds. There is still scope for the alarm information presented to the operator to be improved by the application of alarm deadbands. Alarm deadbands should be set according to the expected dynamics and criticality of the process application. The table below provides general guidance and recommendations for default deadband settings. Point Type Flow Level Pressure Temperature Deadband 5% 5% 2% 1%
RP 30-4
The minimum duration for which a Digital point is in alarm can normally be set in order to prevent oscillating contacts from inundating the operator with an alarm. The digital alarm delay time should be set according to the expected dynamics of the process application. The table below provides general guidance and recommendations for default delay time settings. Critical applications, or applications presenting specific problems will require individual consideration. Point Type Flow Level Pressure Temperature Others Delay Time 15 secs 60 secs 15 secs 60 secs 05 secs
Critical applications, or applications presenting specific problems will require individual consideration.
Points which reside in DCS modules without normal full functionality may be confined with a fixed deadband/ delay-time. This may be the case for devices which obtain signals relayed from another high level device, e.g. a third party PLC. When such devices are used, it is recommended that the non DCS device is configured to suitably condition the signals sent to the DCS. Signal conditioning should comprise signal filtering, or the separate transfer of an alarm signal.
5.5.10.3
Bad Process Variable Handling Bad Process Variables, as determined by a transmitted signal going out of range, can generally be alarmed to indicate that an instrument requires corrective maintenance. It is recommended that only controllers and critical values used in calculations for advanced control algorithms should be actively alarmed for this condition. All other points should report the Bad PV condition to the system journals. The DCS Support Engineer should regularly interrogate the system journals for Bad PV alarms.
5.5.10.4
Extended Ranges The use of extended ranges on Analogue Input signals minimises the frequency of Bad PV alarms by providing a tolerance against:(a) (b) field conditions transgressing slightly beyond instrument calibration. signals which are slightly out of calibration.
The Extended Range values used need to be chosen in order to assist the operator whilst not disguising the need for calibration maintenance of a signal.
RP 30-4
Initial settings for the Extended Range parameter are recommended to be globally set to a default value of 10% of Range. This default value can then be modified should this figure prove unsuitable for a particular application. 5.5.10.5 PV Clamping Bad PVs can be removed from points which are not appropriate for extended PV ranges by application of a PV clamping option. Caution should be exercised in the application of PV clamping if misinterpretation can result from a clamped value. Applications of merit can be in the background processing of points associated with some advanced control applications which would otherwise experience discontinuity of control if Bad PVs were encountered. 5.5.10.6 Background Processing Points Various points on the DCS are intended to be processed "invisible" to the operator. Such signals include feed forward and analyser dead time calculations for advanced control loops. There is no requirement to annunciate alarms on such calculation points, as the operator is not expected to take action specifically on these points. 5.5.10.7 Equipment Status The position of on/off valves, or the run status of pumps are often set by the operator. The operator should not therefore require an alarm to indicate the status of such equipment. The operator is informed of equipment status by means of the status condition point in the DCS driving colour coded mimics on the graphics. Operator control points for valves and pumps should therefore be configured to alarm a disagreement of its current status against its commanded state. 5.5.11 Alarm Reduction Mechanisms Some useful alarm reduction mechanisms do exist on many current DCSs:Alarm suppression or alarm cut-out can be used to reduce the problems of:(a) (b) (c) (d) Alarm flood following a trip. Standing alarms. Nuisance alarms. The mechanism for suppression or cut-out may take one of several forms, depending on the possibilities and limitations of the DCS:(i) (ii) (iii) Inhibit alarm detection, possibly by taking the alarm detection algorithm off scan. Automatic alarm acknowledgement. Alarm priority reduced, perhaps to `journal only'.
RP 30-4
(iv)
Alarm detection thresholds altered to reflect the state of the plant, possibly by using an Automatic recipe system.
5.5.11.1
Alarm Handling Packages (AHPs) It is vital to prevent/ minimise alarm floods on the DCS. Alarm floods result in important alarms being missed amongst the mass of inconsequential alarm information during a process upset. Alarm Handling Packages (AHPs) to prevent alarm floods should work by disabling alarm annunciation (audible/ visual on alarm summary displays under certain prescribed operating conditions. The alarms will still be visible to the control operator on the process graphics and will be recorded on the system journal. The operating conditions are identified automatically (can be selected manually) by the software according to a set of criteria based on measured operating parameters. The alarms selected to be disabled should be those which are of no consequence to the situation being dealt with at the time, e.g. during unit feed stoppage there will be no value in identifying that a product rundown flow is low. Process alarms are an inherent element in ensuring safe plant operation. Therefore an AHP which will disable alarms should be examined to ensure that no unnecessary hazards to continuing safe operation are introduced by disabling the alarms.
Suggested Execution Path for an Alarm Management Project

GO
Complete Basic Alarm Review Divide process into sections for Alarm Management Define the operating cases to be catered for
E.g. Shutdown, Startup, Regeneration, etc.
Include criteria for validating the inputs to any logic
Define criteria for each operating case
Remove unnecessary alarms. Assign correct priorities to remainder
Configure display enhancements
Functional Specification prepared
Complete function tests and operator training
Configure Alarm Management application

Use of 'dummy' alarm points minimises disruption during tests / training
Conduct AMHAZ review
Define the alarm points and states under each operating case
Adopt aggressive approach. Use AMHAZ review to remove critical alarms from scope
Conduct early to minimise reconfiguration
Commission application
Review performance under demand situations
Revise design as required
RP 30-4
5.5.11.2
Alarm Management Methodology
Hazard
Assessment
(AMHAZ)
Study
Dynamically altering an alarm priority can, on some systems, have unexpected and unwanted interactions with alarm display and reporting mechanisms, since these may not be handled separately.
AMHAZ is a methodology to identify, and provide recommendations to prevent potential hazards created by disabling alarms in an AHP. AMHAZ provides the end-user with assurance that the AHP can be safely put into service. The AMHAZ process considers the operator function to best resolve a process upset condition. The dynamics of the process upset and the operator need to be considered, i.e. likely cascading of process upsets, rate of new/ repeated alarms, and the time to achieve corrective action (if any). The AMHAZ study methodology assesses the safety and operability implications of disabling process alarms under certain prescribed operating conditions. AMHAZ is a rigorous assessment tool, but it does not replace other safety and operability studies/reviews, e.g.. HAZOP, PHSER, CONSOP, which should also be performed. AMHAZ complements other studies by very specifically addressing the impact of the application of alarm management which would not be addressed by any of the other studies or reviews. Abridged details are given in Appendix D, with full details available in report No. 1996225211. 5.6 5.6.1 Trending and History Configuration Historical Data to Collect The following data should be included in the continuous history:(a) (b) (c) (d) (e) all analogue measurements. all calculated or dynamically modified parameters used as controller measurements. all controller outputs. all cascade slave or other dynamically calculated controller setpoints. other controller parameters subject to continuous change, e.g. adaptive gains, calculated or dynamically compensated feedforward parameters. analogue values communicated from instrument subsystems, PLCs, ESD, F&G, etc.
(f)
RP 30-4
The following data may either be included in the continuous history or logged and time-stamped in an event-log:(g) all operator analogue actions: controller set-point adjustments, manual modulating valve movements, sequence control analogue settings, (e.g. ramp-rates, targets).
The following data should be logged and time-stamped in an eventlog:(h) all discrete operator actions: controller mode changes, discrete valve movements, motor start or stop, sequence control initiation, option selection or interruption. discrete control output actions from sequence controls. all alarms. ESD, F&G and other subsystem actions.
(i) (j) (k)
It is preferable that the following data should also be logged and timestamped in an event-log:(l) all DCS configuration changes, especially alarm settings.
An important use of the history system is for post-event diagnostics. It is impossible to know in advance what parameters will be required in post-event analysis, so it is strongly advised to collect all available data, noting that data storage media are very cheap compared with the cost of an incorrectly analysed process incident.
5.6.2
Time and Magnitude Resolution of Historical Data The following should be considered:(a) (b) Ideally, all plant data should be recorded on the finest possible magnitude resolution and for the longest available period. The typical time resolution used for most data is 1 minute. Some fast moving parameters may require a faster collection interval to prevent aliasing.
Network loading may be a constraint on time resolution.
(c)
The data collected should be saved for a minimum of five days before archiving.
To allow for post-event analysis after a long public holiday, (e.g. Easter)
Complex data compression was once in vogue to save disk space at the expense of retrieval speed and resolution; multi-gigabyte disks are now cheaply available that this is unnecessary; (e.g. 1 gigabyte holds 6 byte analogue values for 23,000 tags at one minute resolution for five days without any data compression).
RP 30-4
5.6.3
Archiving The following should be provided:(a) Data history archiving should be to optical disk or other high resolution storable media, and should be performed automatically, (e.g. as a scheduled back-ground activity), except for media replacement. Archive data retrieval should use the same trend and reporting facilities as the on-line history. A mechanism for off-line data retrieval, (e.g. via a PC), should be provided.
(b) (c)
5.6.4 5.6.4.1
Trends There are three main uses of the trend facility:(a) Predictive monitoring of the plant. The critical factors here are:(i) (ii) (iii) (iv) real-time updating and scrolling. fine resolution of the magnitude of the process parameter. the ability to scale the individual traces separately on a multiple trend. the ability to retrieve a trend previously defined by the operator without having to redefine parameter selection, time-base or scaling.
Here the trend is used to monitor conditions whilst vessels are being filled or emptied, units being brought up to temperature or pressure, batch processes nearing a point requiring operator intervention, reaction or separation processes nearing specification as they are brought on stream. The operator watches a number of key parameters relating to the process, (typically up to eight), so that he can correctly anticipate and time his next action.
(b)
Post-event analysis of considerations here are:(i) (ii) (iii) (iv)
disturbances.
The
important
fine time resolution, (to distinguish cause from effect). facilities for zoom and pan in the time dimension. the ability to bring a succession of different parameters onto the same trend graph quickly and easily. It is also desirable to be able to identify discrete events and operator actions on trends.
RP 30-4
When an unexpected event has occurred, trends are used to identify the original cause and to trace the propagation of the event. The operator typically trends the parameter which he first noticed as having a problem, and brings onto the same graph the possible causative parameters. Having found an immediate cause, he may well seek further initiating or predisposing events by a similar process.
(c)
Loop tuning. This may be achieved by a custom graphic, however a standard graphic is preferable, and the important features to include are:(i) (ii) Ability to load all necessary parameters (MV, SP, OP) by entering the loop tag name. the ability to leave the page and return to it without repeating the definition or losing data, so as to be able to tune very slow loops. fine time resolution so as to be able to tune the fastest loops. real-time updating. fast configuration: a single tag-name definition generates trends for set-point, measurement and output. Ability to change tuning parameters, (gain, integral action time, derivative action time-constant, filter timeconstant), as well as set-point, output and controller mode, from the same page.
(iii) (iv) (v) (vi)
Typically, it is necessary to trend the set-point, measurement and output, together with parameters which are known to disturb or influence the loop, (e.g. feed-forward value, cascade controller measured value).
5.6.4.2
In all cases, the following apply:(a) (b) The trends should distinguish parameters by line-colour. The display should show, for each parameter: the tag-name, description, measured value, units, upper and lower trenddisplay limits. The upper and lower trend display limit for each parameter should be capable of individual definition and on-screen modification. It should be possible to zoom and pan along the time axis, or to specify start and end times. The time axis should indicate the exact time and date represented by each grid-line. A hair-line cursor facility should allow the numerical readout of the trended values at the time specified by the cursor position.
(c)
(d) (e) (f)
RP 30-4
(g) (h)
Where the trend end-time is now, the trend display should update in real-time, no matter what the time-span is. Real-time updating trends may update the trended parameters at the display time-resolution, no matter what the history collection interval.
5.6.5
SQL Reports Interrogative access to history data should be possible:(a) On-line SQL-type search and reporting of data from both the continuous and event histories, (with appropriate merging of the results) It should be possible to display the SQL reports on a system screen or to print them on the standard system printers It also should be possible to transfer the SQL report to spreadsheets or other software packages in PCs or other networklinked machines
(b) (c)
5.7
Controller Configuration Guidelines All process inputs should be checked for measurement range validity. An out of range condition should generate an operator workstation message, and on controllers the loop mode should change to manual. For low level temperature inputs the equivalent of up-scale (downscale) burnout protection should be provided. Where an out of range condition exists the system should allow configuration of whether the point continues to process on last good value or not. Process outputs should be checked for 4-20 mA range validity. All control loops should be arranged to fail safe, e.g. by shedding master or supervisory loops onto basic regulatory control and holding current set point or valve position. Controller algorithms should always reside at the lowest practicable level of the control system hierarchy. Control output to valves should be configured on all operator displays as:0% Output = Valve Closed 100% Output = Valve Open Loop initialisation with measured value tracking should be provided for multi-loop control schemes to ensure bumpless switching between control modes.
It should never be necessary for the operator to perform a manual initialisation or controller balancing process.
RP 30-4
Multi-loop control schemes should be configured within a single control processor wherever possible thus ensuring inter processor communications are minimised. Control loops typically have a 1 second controller cycle time. Where significantly faster processing is required, (e.g. compressor anti-surge control), DCSs are generally too slow and separate dedicated controllers should be used interfaced to the DCS via serial links for remote monitoring. Controllers which connect directly to valves in the field should not in general be configured to restore the controller mode following power failure or controller failure, i.e. loops should (in general) restart in manual.
Some specific loops may need individual consideration, this should be achieved through safety and operability studies (e.g. CONSOP).
On failure of a non-redundant controller or a controller and its back-up, the action of the output should be to fail fixed at its last good value, or to the power failure mode.
The failure mode would normally be specified as frozen at the last good value unless there is an overriding process reason to do otherwise.
Following complete power failure, outputs should be restored at 0 %. The settings for bad measured value detection should be defined, e.g.:- 3% = + 103 % = Low Bad Value High Bad Value
Vendor's standard control algorithms and functions should be used where possible in preference to user defined and programmed algorithms. Similar control schemes that are used in several locations on a plant should be configured in the same manner e.g. algorithm usage, display and initialisation. Advanced control and applications running in higher level computers, e.g. VAX, should not directly manipulate valve outputs. They should reset DCS controller setpoints.
Supervisory Control is the term used where controllers are manipulated through set point changes. Supervisory Control should be used in preference to Direct Digital Control, (where the control valve position is manipulated). This ensures that basic level control functions are maintained should the communication or control links fail. Likewise, Supervisory computer outputs to DCS controllers should be subject to validity checks at the DCS for security of plant control.
RP 30-4
Max/min and rate of change limits should be configured on base controllers used in advanced control, optimisation and higher level application programs to ensure that software faults in these programs do not drive the base controller to an unsafe state.
Advanced control schemes should be easy to use and the operator should have a quick and convenient method of turning them on and off. Operators and plant managers should be trained in the objectives and use of the advanced control schemes. Consideration should be given to the provision of special operator help displays to assist the operator in all but the simplest schemes. Configuration details should be checked for appropriate and consistent application by means of the CONSOP process.
5.8
Batch and Sequence Control In addition to the recommended practices for all DCS requirements, batch and sequence control presents some extra considerations. The main features of batch and sequential controls are their time dependency and the use of alternative routing or equipment. Operator action is more frequently in the form of an interactive dialogue and therefore clear understanding, consistent responses and confirmation feedback are very important.
5.8.1
Operating Philosophy A form of operational or task analysis is required to identify the essential order of interactions, (review of the display format is insufficient), for example analysis is required to:(a) (b) (c) Determine what information is required in the selection or initiation of sequence controls. Co-ordinate actions by outside operators such as starting machinery or resetting trip devices. Ensure that safety interlocks are not required to be defeated in normal operation.
The analysis should also determine:(d) (e (f) (g) The diagnostic information on faults in equipment or sequence operation needed by the operator. Stable hold conditions such that sequences can be temporarily stopped. Means to restart, proceed manually or abandon the current step. The effects of an emergency or general plant shutdown on any active sequence.
RP 30-4
5.8.2
Summary of Displays The display hierarchy is generally flatter and navigation between the different types is greater than with continuous plant operations. In addition to the customary displays the operator requires:(a) Sequence Summary Display A summary of all sequences and their status, unacknowledged alarms or messages. (b) Individual Sequence or Batch Overview Detailing the process, the current stage of the sequence, the main equipment selected, key parameter current and target values, elapsed time, alarms, messages active interlocks. (c) Sequence or Batch Set Up Displays Simple sequences, routing or transfers can be set up from a Unit display, using menu or dedicated key selection. More complex sequences should be set up from a custom display. Menu's can be used to enter pre-set recipes or routings. Additional automatic checks of manually entered data are recommended, (e.g. equipment availability, validity of line routing etc.) (d) Control Detail Displays Items of equipment in an inaccessible state, due to an overriding sequence, interlock or external trip should be highlighted on the display. Status data should still be available. (e) Message and Interlock Summaries Sequence and batch programs should generate messages to:(i) (ii) (iii) Initiate operator action. Confirm status of equipment not monitored by the DCS. Advise why operator actions have been inhibited (interlocked).
No operator action should be inhibited without explanation
RP 30-4
5.8.3
Recipe/ Route Selection Pre-set recipes and routings should be held in tabular format for ease of selection. Options to modify individual components should be provided. Authorisation to make changes may be required and all changes must be recorded.
5.8.4
Alarms and Interlocks Batch operation may be affected by the interaction between sequences and fixed interlocks. The operator should be able to easily distinguish between external 'trips', sequence interlocks and other 'holds' by means of effective alarm displays and messages. External alarms, from shutdown and safety interlocks, should be displayed on the graphics as for continuous plant. Sequence interlocks should be shown as a status flag and annunciated, as a message, only when activated; that is when an automatic control or operator action is prevented.
5.8.5
Message Handling Messages are issued to inform the operator of an expected event. They will normally, but not necessarily, require a response or action from the operator. They are displayed and annunciated on either a custom overview or the sequence summary listing. Messages should appear directly and in full on a sequence control graphic. Simplicity and consistency are essential, for example, held, paused, stopped, aborted, waiting, off, are all similar but have different meanings in the context of sequence operation. Progress through a sequence can be monitored by archiving messages as they are displayed to the operator. In simple cases custom operator displays showing the details of the current sequence step can be provided using flowchart concepts or a high level 'pseudo' code.
5.8.6
Navigation Effective navigation is vital. In addition to plant overviews and alarm summaries batch applications can include high level sequence overviews and message summaries. This is compounded when the use of alternative routing means there is no fixed relationship between sequences and equipment. The use of proprietary batch or sequence software may provide all the necessary facilities. The alternate is to balance the simplicity of operator navigation against the complexity of software. When practicable dynamic linking should be used to move directly from the alarm acknowledgement to the control display.
RP 30-4
5.8.7
Advanced Sequencing Sequential control schemes typically have a number of distinct steps of which only a small number is active at any one time. Progress to the next step may be dependent on elapsed time or on certain process conditions being satisfied. There may be selection steps, where the next step may be one of several, depending on the states or values of some parameters. Some steps may require operator actions, in which case an advisory message is generated. The detailed advanced sequencing display typically contains the following features:(a) (b) (c) (d) A schematic diagram, (flow-chart), of the principal steps including the selection steps and operator intervention points. The currently active steps are highlighted, and the actions being taken by the step are indicated. The target and measurement for the condition that moves the scheme to the next step are displayed. If operator intervention is required, data entry points for the relevant actions are included together with help text to prompt the correct action. A recent history is provided giving the values of previously manipulated parameters, elapsed times for previous steps, selection parameter values and other relevant information. A scrollable window is preferable for this feature since the entire history can then be interrogated. A trend may be included of key measurements associated with the scheme. Start/abort and pause/continue targets or buttons should be provided where appropriate.
(e)
(f) (g)
RP 30-4
5.9
Advanced Control/ Optimisation Advanced Control can deliver substantial pay-back to raise profitability. Operator acceptance is crucial to ensure continual good utilisation of schemes. It is therefore vital to have a well designed interface for the operation of advanced control and optimisation systems. Advanced Control is a technology which is advancing quickly, and it is as well to define terms in current use:Regulatory Control Algorithmic Advanced Control Sequential Control Control applications that are shown in detail on the Unit control display. Higher levels of control that are implemented using control algorithms available in the DCS, (aka Traditional Advanced Control) Where there are a number of distinct steps or stages of control in which different control actions take place. Where a multi-variable system identification provides a matrix process response model which is inverted to provide a multi-variable controller. Widely used MVPC packages include DMC and RMPCT A layer above the control system that provides targets to the control system, and can take the forms:Advisory Optimisation (aka Open-Loop Optimisation) and Closed-Loop Optimisation
Multi-Variable Predictive Control (MVPC) Optimisation
5.9.1
General General principles that apply to all advanced control and optimisation schemes are:(a) Information relating to the advanced control or optimisation system should follow the general principles used throughout the DCS. The operator interface to the scheme should be at the appropriate point in the display hierarchy.
thus a scheme that affects the whole of a plant area or process unit should have its primary interface at the area or unit level of the hierarchy. All advanced control scheme points of interaction with regulatory controls should be shown on the relevant operational graphic displays.
(b)
(c)
The operator interface should provide a means of identifying the mode of operation, (on/ off control), and the principal indications of correct function, (e.g. a target value and
RP 30-4
measurement). A means of changing the status and target value may be provided at this point, or in the detailed advanced control display.
hexagon symbol is often used to denote an advanced control scheme, and can be used as a target for calling the detailed advanced control display.
(d)
The detailed advanced control display should enable the operator to understand what the scheme is for, what it is doing, how and why. It should provide sufficient information that the operator can be confident he knows the full effect of any operational changes he is proposing to make. It should inform him of any measurement validity problems or process constraint violations that he needs to take into account when commissioning or decommissioning any part of the scheme, or when modifying any settings. Schemes are often part of a control hierarchy, with higher levels of control providing inputs, (e.g. optimiser feeding into algorithmic control set-points or MVPC targets). The detailed display should include a means to connect or disconnect the higher level of control, and a target to move to the detailed display for that control. Where the scheme executes infrequently, it may be desirable to indicate the last and next expected execution times.
perhaps with a suitable graphical indication of progress through the execution cycle.
(e)
(f)
(g)
The control scheme should be configured to take the appropriate degradation or fall-back action when a bad measurement, inappropriate regulatory control mode or unsuitable process situation occurs. The operator interface should clearly identify to the operator what has happened and why. Operator interface design should be optimised for:(i) Routine operations. The operator should not feel restricted or influenced in his action by the control system itself. Common actions and display navigation should be fast, intuitive and should use a minimum of key strokes or screen interactions.
(h)
RP 30-4
(ii)
Non-routine operations. The experienced operator should be given guidance by the system, both unprompted and operator requested help should be considered. New or inexperienced operators. There should be guidance available about all aspects of the control system, the control application and the expected human actions. This may take the form of brief notes, (which may be context-specific), on the advanced control detailed display. Additional pages of more detailed information may be provided. Hypertext may be used to advantage, here.
(iii)
(i)
A performance monitoring and reporting system should be provided, together with a suitable display. The statistics gathered may include, as appropriate: on-line time or service factor; frequency of successful or unsuccessful runs; and some indication of performance, in terms of economic benefit, production rate or process efficiency.
The configuration and programming details for Advanced Control and Optimisation schemes should be checked for appropriate and consistent application of the principles outlined above by means of the CONSOP process.
5.9.2
Algorithmic Control Scheme Algorithmic control schemes typically have a number of process measurements providing feed-forward, calculation, dynamic compensation or constraint control to single- or multi-layer cascade or ratio control systems. Blocks containing program code may be included in the scheme for complex calculations, interlocks or initialisation sequences. The detailed advanced control display will typically include the following features:(a) The principle feature may be a schematic block-diagram of the control scheme giving the points at which the operator can make mode or setting changes, and any switch or selection actions that the scheme performs. The control connections between algorithm blocks should be shown, with arrows giving the direction of signal flow. Where there are switch or selection actions, the active path may be indicated by making these connections brighter than the inactive paths.
(b)
RP 30-4
(c)
(d)
(e)
Measurement and calculated values should be displayed at appropriate points so that the operator has a clear understanding of what is happening. small trend display of the key variables may be included so that the operator can identify what has recently happened after a disturbance within the control scheme. A single button or target may be provided that will commission or decommission the whole scheme, or a major section of it.
5.9.3
Multi-variable Predictive Control Schemes MVPC schemes vary in complexity from simple two input, one output (2x1) schemes, to complex schemes covering a large section of plant. In principle, a dynamic model relating the controller output(s) to the inputs is used for control. The external parameters generally consist of:(a) (b) (c) Manipulated variable MV - An independent variable manipulated by the controller i.e. the controller output. Controlled Variable CV - A dependent variable (i.e. affected by the MVs). The targets and constraints of the controller. Disturbance or Feedforward Variable DV - An independent variable which the controller has no influence over.
The detailed advanced control display typically contains the following features:(d) For large schemes, the parameters are broken down into small manageable groups consisting of those variables that are closely associated in influencing terms. Some variables may appear on several display pages if they influence several areas of the plant. There may be a top-level display with key plant over-view parameters and the scheme on/ off/ initialise controls, with links to subordinate displays. Colours or highlighting may be used to indicate constrained variables, out-of-limits variables or those currently not meeting target objectives. Displays are generally tabular in form and the target and constraint set-point values may function as operator data entry fields. Steady-state prediction values and status for each controlled variable should be provided. The output signals are provided with auto/manual or cascade/local mode-change facilities and provision for manual entry of the value to allow for manual intervention on a particular output. An indication should be provided of the output move directions, sizes and ramping, preferably by graphical means.
(e)
(f)
(g)
(h)
RP 30-4
(i)
(j)
Fall-back for the MVPC consists generally of simple, cascade or ratio PID controllers plus some manual loading stations. A target on each advanced control detailed display should allow rapid navigation to the fall-back control display. Consideration should be given to automatic commissioning of fall-back controllers to minimise the operators work-load in the disturbance following mal-operation of the MVPC. The MVPC detailed display often contains a trend graph of the key variables for that area, (usually the controlled and constrained measurements). This should plot both the predicted and actual values of the parameters, and include forward predictions.
5.9.4
Advisory Optimisation Advisory optimisation systems calculate optimum plant operating conditions and the operator has to respond to this information. These systems generally operate in final value form, i.e. take no account of plant dynamics nor how long it will take the plant to settle at the optimum value.. Often such systems operate on a significant change basis, advising the operator by way of messages of a new optimum when a significant change has occurred to the plant, (e.g. feed-stock quality). (a) The detailed optimiser display is generally tabular in form, with actual measurement, current set-point and optimiser target values for each of the manipulated variables. The table should also contain an evaluation of lost profit calculated from deviation of each actual process measurement from target; a bar-graph indicating this deviation for each parameter allows the operator to scan the optimiser displays quickly to identify his action priorities.
For large optimisers, this table may spread over several pages.
(b)
(c)
(d)
The operator needs to be able to inform the optimiser which of the set-points he does not want to be manipulated, or which are unavailable for optimisation for any reason, as this will affect the optimum. A mechanism may be provided for down-loading the optimiser targets, either one at a time or as a group, into the controller setpoints. Further pages of display may be provided for the process constraints. The current actual process measurement is listed with the optimiser upper and lower constraint boundaries. Calculated constraint approach values are displayed showing
RP 30-4
the operator the economic effect of changing the currently active constraint boundaries. 5.9.5 Closed-loop Optimisation Closed-loop optimisers generally operate in incremental form, moving the plant conditions only by the amount that the plant can respond during the next optimiser cycle. To provide bump-free commissioning, increments rather than whole values are passed to the control system set-points, and are often enacted through a set-point ramping feature to minimise disturbances. (a) In addition to a tabular display for target values and constraints, there is generally an over-view display that provides status monitoring of the optimiser and provides the operator with switches to select closed-loop or open-loop operating modes. This display includes monitoring of protection features such as a watch-dog on data communication to the control system from the optimiser computer. Closed loop optimisers will often have a stand-by mode where all cascade links are established, but no action is propagated to the underlying controls. This state is useful for commissioning, maintenance and transient handling. Switching to the fully operational state should be with a single operation located on the optimiser summary page. Optimisers should only be left in the stand-by mode for short periods of time, this being enforced by a timer automatic link break. Control loops whose set-point can be set by the optimiser require a cascade/local mode select switch. The mode selector should appear on the individual advanced control detailed display, with status repeated on the optimiser target-value display.
An optimiser watch-dog or off-line signal should set all mode selector to local. Cascade commissioning requires individual action on each control scheme. In some cases local clusters of a few cascades may be grouped together into one control scheme.
(b)
(c)
(d)
It is essential that the operator can identify what the optimiser is doing to the plant. As changes should occur slowly, this is often not obvious from the direction or magnitude of the increments. It is desirable that the optimiser has an intelligent means of informing the operator the strategy it is following.
Operator messages should be generated in the optimiser host computer and down-loaded to the control system.
RP 30-4
(e)
(f)
Operators should be able to set constraint limits and controller set-points. Since constraints affect operation of the whole optimiser, access will usually be through constraint summary pages. The operator should be made aware when constraints become active, however constraint status should be restricted to passive indication, as a closed loop optimiser will generally be running to one or more active constraints in normal operation, which does not require alarming.
5.9.6
Other Kinds of Advanced Control Scheme There are many specific circumstances where programs are provided for particular complex plant control functions, which do not fit the above categories, e.g.:(a) (b) (c) (d) (e) (f) routing logic for tank-farms or silos. ship or road-tanker transfer schemes. recipe management schemes for batch processes. grade-transition schemes for multi-grade continuous processes. batch-blending systems. fuzzy-logic control and optimisation systems.
The nature and function of such schemes is so diffuse that only general principles for the operator interface design are provided:(g) The operator must be able fully to understand the function and action of the control scheme. As far as possible this should be apparent from graphical or schematic presentation of information; help text should be supplementary rather than a primary essential. The operator must have sufficient confidence that the control scheme will do what he expects it to do, from the information on the display, that he feels able to put it into commission. The operator must know how to tell when the control scheme is not doing what it is supposed to do, and what to do when that happens. The operators interactions with the control scheme must match his expectations.
(h)
(i)
(j)
RP 30-4
6.
ACCEPTANCE AND INSTALLATION 6.1 Factory Acceptance Testing (FAT) The objective of the DCS FAT is to ensure and confirm the following:(a) All deliverable items, i.e. hardware, software, documentation, media etc. are present and acceptable. The correct functioning of the DCS in accordance with the SDS, including all interfaces to other equipment and subsystems. The system operates under simulated load conditions over the test period at or better than design availability. The system can tolerate failure of individual modules and subsystems and be recovered to full function following repair and re- instatement of such items. That no untoward control actions can occur. That the operator interface is accurate, safe and operable with respect to the presentation of data and alarms and the implementation of control.
(b)
(c)
(d)
(e) (f)
The FAT should be carried out at the vendors works by the vendor's personnel, witnessed by Project representatives. The tests should be carried out in accordance with an FAT procedure specification prepared by the system vendor and agreed in advance of test commencement. Prior to this test, the vendor should have completed all his in-house validation testing and quality checks to ensure that the system fully complies with the SDS and all application software specifications.
Experience has shown that faults found at site will take significantly longer - often more than twice as long - to rectify than faults found at the vendor's factory. This is especially the case for new sites, or new equipment on established sites. Where there is an established site infrastructure to support the project equipment, on-site repairs may not incur such disadvantage, and the FAT may be less rigorous accordingly. Bearing this in mind, it is recommended that the extent and scope of the FAT should be established against the risks involved in leaving some testing to site.
Effort should be tailored in accordance with risk, e.g. statistical methods such as 10% checks on I/O should be considered to reduce testing effort on well established items.
RP 30-4
An agreed period should be set up at the end of the FAT for conducting any additional or repeat testing that may be required. The vendor should provide documented evidence of all faults identified and their subsequent correction. The scope of the FAT should include:(g) (h) (i) Inventory Checks. Labeling and Presentation Checks. Hardware Testing. Module Testing, e.g. - Diagnostic Routines. - Redundancy Testing. - Failure and recovery Testing. Field Termination Testing. Power, Fusing and Earthing Checks. Interfaces to other systems and Sub-systems. Configuration Testing. System Configuration Checks. I/O Database Configuration Checks. MMI Configuration Checks - Displays, Alarms etc. Control Loop Functionality Testing. Software Testing. Application Program Testing against Functional Specification. Integrated System Tests. Overall System Tests. Operability Testing - system response times. Failure and Recovery of System.
(j)
(k) (l)
FAT Test details are covered in the appendix C. Complex software with non-trivial logic, control sequences, mass flow accounting packages, supervisory control packages, etc. should be tested by the "walk through" test approach. Simple simulator boxes comprising switches and potentiometers or the equivalent in simple software points should be used to drive the "walk through" test. Control loops can be simulated by feeding the output back into the input. The objective of the "walk through" test is to ensure each line or section of code is exercised a least once and its correct operation. The flowcharts and listings of the software can form part of the test script. As the "walk through" test proceeds, paths through the code can be marked off on the flowchart as they are checked and confirmed. Operator interfaces to application software should be checked at the same time, preferably with operations staff present. It is recommended that application software is tested by a two person team, one being the program author, the other being the client's witness tester.
RP 30-4
6.2
Delivery and Installation It is important to thoroughly plan delivery and installation of a DCS in conjunction with the vendor and the receiving site or Project. In particular, Civil, Electrical and Instrumentation work at the receiving location should be as complete as possible. If work has to be completed following delivery of the DCS equipment suitable partitioning or screening should be erected to protect against the ingress of dust or dirt. The following points should be checked prior to delivery:(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l) (m) Access adequate for delivery vehicle? Access adequate for equipment siting? All partitioning complete? All painting complete? Sub-floor clean and suitably sealed? False floor complete? HVAC installed, tested and commissioned? Lighting installation complete? The earthing system complete? The UPS power supply and distribution complete? Field cable pulling and glanding complete? Have procedures been developed to prevent ingress of dust and dirt following DCS installation? Have fire precautions been addressed, i.e.. extinguishers, smoke detectors etc?
A delivery and installation plan should be developed in association with the vendor, the project contractor or site, and the vendor's haulage contractor. This plan should be circulated and discussed with all interested parties prior to delivery. It is recommended that this plan includes the following aspects:(n) (o) (p) (q) (r) (s) (t) A programme bar chart showing all activities, durations, and dates including phasing if the delivery is phased. A description/listing of all activities, i.e. work scope A clear definition of responsibilities for all parties An equipment list Detailed power supply requirements, i.e. which distribution boards will be needed, etc. Details of the size and weight of delivery vehicles Detailed means of moving equipment from delivery vehicle to point of installation
RP 30-4
6.3 6.3.1
Site Acceptance Test (SAT) Site Testing Principles Following delivery and installation, it is recommended that a Site Acceptance Test (SAT) is carried out. This test should be based on a subset of the Factory Acceptance Test (FAT) supplemented by tests which can be carried out only at Site, for location or logistical reasons. The SAT test specification should reflect the structure and the phasing of the testing starting with inventory checks and hardware tests through software testing to final testing of a fully integrated system of hardware and software. Test scripts should be produced to cover all testing. An SAT test specification should be developed to cover all testing to be carried out. The specification should state clearly the objectives of testing and contain test pre-requisites, test scripts, programme, procedures for fault rectification and the means for documenting the tests. The purpose of the SAT is to establish that the DCS equipment has been shipped without damage, has been correctly installed and operates reliably to specification in its final environment. For guidance, the following typical DCS SAT Objectives list is provided:To ensure and confirm the following :(a) (b) All deliverable items, i.e. hardware, software, documentation, media, etc. are present and acceptable. The correct functioning of the Distributed Control System (DCS) in accordance with the SDS, including all interfaces to other equipment and sub-systems on the final power supply and earthing system. The system operates under loaded conditions over the test period at or better than design availability. The system can tolerate failure of individual modules and subsystems and be recovered to full function following repair and re-instatement of such items. All remedial work agreed at FAT has been satisfactorily completed by the vendor and the system meets its design specification in full. The Operator Interface is both safe and operable with respect to the presentation of data and alarms and the implementation of control.
(c) (d)
(e)
(f)
RP 30-4
It is also good practice at this time to check that all environmental conditions in the control and equipment rooms meet design specifications, and operational needs e.g.:(g) (h) (i) 6.3.2 HVAC. Lighting and glare. Noise levels.
Hardware Testing Correct assembly of redundant equipment items should be established by forced failure and recovery testing. This testing should extend to network communication cables, power distributions, and any connected instrument subsystems. Any equipment replaced or added since FAT should be thoroughly tested. The following supplementary hardware testing is recommended to be carried out at SAT:(a) (b) (c) (d) (e) (f) (g) Power distribution, fusing, segregation and earthing checks. DCS/UPS tests including in-rush, mains failure, static switch failure, battery discharge, voltage and frequency variation. Check for interference from ancillary equipment, e.g. HVAC thermostats, lighting dimmers, radios, etc. Check noise levels versus specification. Check operator interface for glare, reflections, etc. Check operation and acceptability of alarm annunciators, lamps and contacts. Check operation of all connected subsystems. In particular, those not previously tested, e.g. links to remote systems by communications link, etc.
6.3.3
Software Testing Any software which has been subject to remedial work since FAT should be thoroughly re-tested including any potential impacts on unmodified software. Similarly any software added since FAT should be fully tested.
6.3.4
Integrated Testing To conclude the SAT, it is recommended that a test of the fully integrated DCS, i.e. hardware, software, instrument sub-systems, communications links should be carried out. If such a test was previously carried out during FAT at the vendor's premises, the duration of the SAT test may be reduced. The integrated testing of equipment not available at FAT, e.g. sub-systems and communications links, should be performed.
RP 30-4
6.4
Pre-commissioning and Loop Testing It is recommended that the planning of pre-commissioning and loop testing activities is carried out as early as possible during the DCS detailed design phase, e.g. on availability of approved for construction P&I diagrams. Planning should be carried out in conjunction with construction and plant commissioning staff and reflect the program of mechanical completion and phasing of process commissioning.
6.4.1
Loop Testing Organisation and Schedule In discussion with construction and commissioning staff, the number of loops to be tested and the dates by which they are required should be established. From this data, the average, number of loops to be tested per day can be established for all phases of pre-commissioning, and hence the number of test teams required and the resource profile against time. For guidance in this area the following information is provided:(a) Loop test teams of two instrument technicians are typically used. Any corrective or remedial work is best carried out by teams dedicated to that task, i.e. not by test teams. Test teams can often be beneficially supported at the control room end of loops i.e. at the DCS screen, by plant operators. On recent DCS projects, the productivity of loop test teams has averaged between 4 and 8 loops per day. This rate is obviously dependent on the loop complexity and availability and the higher figure is more likely where there is a lot of simple loops, e.g. plants with high number of digital inputs.
On reinstrumentation jobs the productivity rate is very dependent on the level and commitment of the operations/ process support available.
(b)
(c)
In drawing up any schedule or resourcing plan, equipment access and availability should be checked. This applies particularly to DCS screens where the phasing of precommissioning and DCS engineering support work may cause access bottlenecks. In such cases, it may be possible to loan or hire extra DCS screens from the vendor for the commissioning period.
6.4.2
Loop Testing Procedures Formal procedures detailing method and responsibilities should be written for loop testing. Each loop should have a documentation dossier raised prior to testing for use by testers. Loop tests should be witnessed. On satisfactory completion of a test, a test certificate should be produced. This should be endorsed by the witness. Any
RP 30-4
documentation errors encountered in the test should be marked up and corrected. The following outline DCS loop testing procedure is provided for general guidance:(a) (b) (c) (d) (e) (f) Issue test schedule. Raise inspection and test documentation dossier Check field cabling for short circuits and earth faults. Check loop voltage and polarity. Power up loop. Test loop.
For analogue inputs, simulate at 0-50-100-50-0 % of input at transmitter process side. Check for correct reading at DCS Screen. For field switches, simulate input signal at switch process side. Check for correct reading at DCS screen. For control valves, check stroking by adjusting at DCS in manual at 0-50-100-50-0 % output. Check for correspondence between field valve position in field and DCS screen value. Check operation of any ancillary devices. e.g. limit switches, boosters, lock up devices etc. Analysers will need special attention but wiring from the field junction box through to DCS can be tested by simple signal injection. Software functionality should also be tested by means of integrated loop testing. This should include loops incorporating logic signals and calculations. For full operation tests, a fully integrated functional test may be required, e.g. interlocks and safety systems requiring a functional integration of the DCS with PLC sub-systems, mechanical devices etc.
(h) (i)
Obtain witness endorsement of test and certificate. Mark up and correct any discrepancies in documentation and drawings.
6.4.3
Operator Familiarisation and Training Operators are involved at the DCS screen to assist in loop testing wherever possible. This has the benefit of providing early DCS familiarity on the actual equipment and allows them to learn DCS operating procedures, display content and structure before commissioning starts.
6.4.4
Precommissioning: Plant Trials and Test Runs Where the process characteristics allow, water test runs can be used to pre-commission process equipment. In these cases, every opportunity should be taken to set up and carry out tuning of control loops and schemes even though the process conditions may differ from design
RP 30-4
figures. Water tests should also be used to further check and set-up control sequences and logic. Inevitable mismatches between plant equipment and sequence logic can be beneficially resolved at this stage without the risks of spoiling actual process material. Every opportunity should be taken during pre-commissioning to set-up and confirm the operation of advanced control schemes. Use should be made of any plant test or water trials to set up limits and constraints. Test runs afford good training opportunities to familiarise plant management and operators with the advanced control design, objectives and operation. Operator interface and reporting aspects can also be re-checked and confirmed directly with the user. 6.5 Commissioning DCS commissioning and loop tuning activities should be closely coordinated with plant commissioning and with the process operators. It is useful to use a two week look ahead of plant commissioning activities to plan and resource activities on DCS. Process operators should be provided with full DCS support during commissioning. This support should reinforce training, and quickly clarify any misunderstandings. This is in addition to resolving any problems with DCS control and configuration. At start up, shift working by DCS engineers may be required to provide the right level of support. 6.5.1 Loop Tuning Starting Values It is recommended that all PID controllers are loaded with safe starting values for the three term control constants. This will greatly assist commissioning loops, for which the following tuning constant starting values are provided for guidance:LOOP TUNING SUGGESTED STARTING VALUES LOOP TYPE Flow Flow Pressure - Liquid Pressure - Gas Temperature Temperature Level - Tight Level - Averaging Level APPLICATION Simple Control Cascade Slave Simple Control Simple Control Simple Control Cascade Master Simple Control Simple Control Cascade Master GAIN 0.3 0.3 0.3 3.0 1.0 1.0 4.0 1.0 1.0 INTEGRAL (MINS/RPT) 0.05 0.05 0.05 2.0 10 10 10 5.0 5.0 DERIVATIV E (MINS) 0.0 0.0 0.0 0.0 later later 0.08 0.0 0.0
RP 30-4
6.5.2
Re-instrumentation - Hot Changeover On re-instrumentation projects, changeover to the new DCS instrumentation can be made with the process equipment shut-down, i.e. cold or with the process equipment live 'loop by loop', i.e. hot. Cold changeover is generally used where equipment can be conveniently shut-down or where the re-instrumentation project is setup to coincide with a planned plant maintenance shut-down period. It is arguable which changeover method involves the least risk and disruption to the plant. Commercial considerations favour hot changeover as the plant continues to operate. Furthermore, as loops are transferred one by one rather than en-block, more control can be exercised over the rate of loop transfer and any faults are picked up immediately rather than all at once during plant start-up. Hot changeover has procedural similarities with conventional plant instrumentation maintenance. In devising changeover procedures, it is therefore recommended that the use of existing procedures for instrument maintenance are maximised. This has the benefit of employing well proven and understood techniques to minimise changeover risk. Proven procedures will normally exist for:(a) (b) Electrical isolation. Prevention of upsets during instrument maintenance, e.g. by use of valve hand wheels, by-passes etc.
Changeover procedure documentation packs should be produced for all loops. Loops involving control valves should be surveyed to establish an appropriate means of changeover and any potential interaction problems, e.g. the valve may be part of a safety system or be slave of a cascade loop. Changeover documentation should include:(c) (d) (e) (f) (g) (h) (i) Overall checklist. Operational requirements. Step by step changeover procedure. Instrument loop diagram. P&ID extract. Termination details. Permit (prior to changeover).
Changeover rates are normally in the range of 10-15 controller loops per day. This rate is limited by the rate at which operations staff can safely accept and feel comfortable with the changed over loops, rather than the rate loops can physically be progressed by instrument technicians. On previous re-instrumentation projects, deliberate breaks
RP 30-4
have been built into the project programme to allow operations staff 'breathing space' to get used to DCS controls. Particular attention should be paid to the training and support of the operator. As the plant is changed over, operators will have to work with the new and the old interfaces at the same time. This temporarily increases operator loading and stress. Training programmes should address these issues and the provision of operator support staff should be considered. 6.5.3 Advanced Control Commissioning Advanced control commissioning should be carefully planned in association with plant management and operators. Prior to attempting to commission any scheme, it is recommended that the following steps are taken:The scheme should be set-up with appropriate safe starting parameter values and maximum use should be made of any available constraints and limits, i.e. take all practical measures to avoid upsetting or shutting down the plant. (a) (b) Operators and plant management should be trained on the objectives and operation of the scheme. Full descriptions of how to operate the scheme should be available to operations staff. In particular, how to put in and out of service and what to do if something goes wrong. A means of monitoring and recording the performance and usage of the scheme should be available. Operators should be directly involved in the commissioning and be fully supported during the initial phases of operation.
(c) (d)
RP 30-4
7.
OPERATIONAL MANAGEMENT 7.1 Operation and Development It is essential that the procedures developed during DCS precommissioning and commissioning phases for controlling changes and housekeeping are maintained for the life of the plant. This will ensure that all changes and development are checked for safety and operability and are auditable and fully documented. DCSs should not be commissioned and then left technically unsupported. Every effort should be made to maximise the use of the DCS facilities for the economic benefit of the plant. Effort should not just be concentrated on improved or advanced control schemes, but also on operability issues such as alarms and displays. 7.2 Change Procedures On completion of the FAT, any further software changes made on the DCS should be documented and approved on a Software Change Control Procedure. This procedure should be set up and agreed prior to the FAT. The vendor and the project should have developed change control and housekeeping procedures in implementing the DCS. These procedures should be reviewed and used as the starting point for developing suitable change control and housekeeping strategies for the running plant situation. A well developed Software Change Request (SCR) form is presented in Appendix E. The SCR form incorporates a checklist which assists in providing a well engineered control system change. It is recommended that the developed procedures incorporate the following points:(a) All changes that impact plant control, operability or safety should be subject to review and approval via a DCS Change Procedure and fully documented. Changes should be reviewed for safety and operability implications and approved by a panel of suitably experienced and qualified staff. Typically this would entail approval of the plant process engineer, plant instrument engineer and the DCS engineer. The impact of a change on other systems. e.g. ESD should be fully considered. All changes must be furnished with a clear audit trail of documentation, both in paper form and via magnetic media. Changes should only be made by suitably qualified, experienced and trained personnel.
(b) (c) (d)
RP 30-4
(e) (f) (g) 7.3
Plant management and operators should be fully informed and briefed on all changes both before and after the change. Training should be given where the change impacts existing plant control or procedures. What constitutes a minor change should be clearly defined.
Housekeeping Housekeeping procedures should always be reviewed following changes to system hardware or system software to ensure they remain up-to-date and appropriate. Recommendations for efficient housekeeping include:(a) Compiling, and working by a set of DCS Operating Procedures. These procedures should include a DCS Permit to Work System, a Software Change Control Procedure, Back-Up Procedures, and a Disaster Recovery Procedure. All procedures should outline responsibilities for DCS support. The Disaster Recovery Procedure should include diagnosing failures, assessing their impact, and agreed remedial actions. Failure areas to be covered include loss of operator window, module and card failures, network failures, with remedial actions including reload procedures. The Back-Up Procedure should include:(i) Regular back-ups should be made of all configuration and program files. The frequency of back-ups should be determined by the extent and rate of system change and the risk of data loss, e.g. in periods of intensive development daily back-ups may be required.; once the system settles down and the development pace reduces weekly or even monthly back-ups may be sufficient. A minimum of two copies of the current back-up should be kept off-system on magnetic media. These copies should be kept in separate locations, e.g. one copy at the plant; one copy off the plant. Storage in a fire-proof safe should be considered for at least one copy. Keeping a previous generation back-up system,
these copies are generally referred to as Present Generation/ Father Copy/ Grandfather Copy.
(b)
(c)
(ii)
(iii)
RP 30-4
(iv)
Full use should be made of any on-line DCS back-up system. This should include full re-installable back-ups, as well as configuration file re-load back-ups. A master set of current up-to-date DCS configuration and software documentation should be maintained on paper or electronically.
(v)
7.4
Maintenance and Spares Maintenance contracts and spares holdings should be geared to plant requirements. A continuous plant may require significant on-site spares and a 4 hour call out response for the vendor's maintenance engineer, whereas a batch plant might only require minimal on-site spares with a 24 hour response. Remote plant locations are likely to require larger on-site spares holdings. Spares holdings and maintenance contracts should be optimised across sites where several systems from the same vendor are installed. Potential to optimise across the Group should not be overlooked. Existing agreements within the Group should be consulted to ensure best value for money is obtained on any new arrangements. Arrangements where the vendor manages on-site DCS spares holding can be attractive. This arrangement has clear responsibilities should a spare be unserviceable, and the spares are then kept up-to-date at the correct revision levels.
7.5
Refresher Training Refresher training of plant operators on DCS should be carried out periodically. This has a number of advantages:(a) (b) (c) (d) It enables less frequently used operating procedures to be revisited. It enables updated procedures to be incorporated. It enables bad operating habits to be eliminated. It reinforces best practice.
RP 30-4
APPENDIX A DEFINITIONS AND ABBREVIATIONS Definitions Standardised definitions may be found in the BP Group RPSEs Introductory Volume. The following general definitions are applicable to all Parts of this Code of Practice:-
Abbreviations AHP AMHAZ CCTV CHAZOP MVPC CONOP CP CSMA/CD CV DCN DCS DMC DV ERA ESD F&G FAT FC FEED FMEA FO FS H&V HAZOP HVAC I/O ID IS ITT LAN LCN Alarm Handling Package Alarm Management Hazard Assessment Close Circuit Television Computer Hazard & Operability (Study) Multivariable Predictive Controller Control Safety and Operability Control Philosophy Carrier Sense Multiple Access/Collision Detect Controlled Variable Distributed Control Network Distributed Control System Dynamic Matrix Control Drive Value Electrical Research Authority Emergency Shutdown Fire & Gas Factory Acceptance Test Fail Closed Front End Engineering Design Failure Mode and Effect Analysis Fail Open Functional Specification Heating and Ventilation Hazard and Operability (Study) Heating, Ventilation and Air Conditioning Input/Output Identification Intrinsically Safe Invitation to Tender Local Area Network Local Control Network
RP 30-4
MMI MTBF MV MVPC OHSE OP P&ID PA PFD PHSER PID PLC PV RMPCT SAT SCADA SCR SDS SIRA SOR SP SQL FM UCN UPS VDU VESDA WAN
Man-Machine Interface Meantime Between Failures Measured Variable Multivariable Predictive Control Occupational Health, Safety and Environment Output Piping and Instrumentation Diagram Public Address Process Flow Diagram Project Health Safety and Environmental Review Proportional Integral Derivative Programmable Logic Controller Process Variable Robust Multivariable Predictive Control Technology Site Acceptance Test Supervisory Control and Data Acquisition Software Change Request System Design Specification Scientific Instrument Research Association Statement of Requirements Set Point Standard Query Language Factory Mutual Universal Control Network Unninterruptable Power Supply Visual Display Unit Very Early Smoke Detection Wide Areas Network
RP 30-4
APPENDIX B LIST OF REFERENCED DOCUMENTS A reference invokes the latest published issue or amendment unless stated otherwise. Referenced standards may be replaced by equivalent standards that are internationally or otherwise recognised provided that it can be shown to the satisfaction of the purchasers professional engineer that they meet or exceed the requirements of the referenced standards. International Standards IEC 61508 ISO 11064 IEEE 802.4 IEEE 802.3 Functional Safety - Safety Related System Ergonomic Design of Control Centres Broadband Token Business Standard Baseband/Ethernet Standard
Group Standards RP 30 series (Control and Instrumentation)
Others 1975-224022 89/391/EEC CONSOP Report EEC directive - Display Screen Equipment
Report 1996 - 225211 AMHAZ Report
RP 30-4
APPENDIX C GUIDANCE CHECKLISTS C.1 DCS Specification Contents Guidance checklist for the contents of a Functional Specification.
The list given is for a single vendor approach. On a competitive project some of the more specific detail would be omitted. INTRODUCTION
Background Purpose of Specification Vendor Specific Clauses Instructions to Tenderer Document Use of Language
DESCRIPTION OF PLANT
Geographical Layout Remote Operator Station Control Building Environmental Conditions in Buildings
OVERALL OPERATIONAL PHILOSOPHY

DCS Design Philosophy Overview Allocation of Operational Areas
VENDOR RESPONSIBILITIES AND SCOPE OF SUPPLY

Hardware Software Services Failure Modes and Availability Analysis Long Term System Support
BP /CONTRACTOR RESPONSIBILITIES SYSTEM DESIGN PHILOSOPHY

Controller and Plant Interface Redundancy Worst Tolerable Controller Failures Redundancy of Operator Station Data Communications Change, Repair and Test On-line
SYSTEM SIZING
Controller Module Sizing Input/ Output Processor Count Sizing and Arrangement of Controller Cabinets Hot Spare Capacity Consoles Peripherals Data Storage Modules Application Processors Computer Interface Serial Interfaces Cable Lengths
RP 30-4
OFF-LINE DEVELOPMENT SYSTEMS SYSTEM FUNCTIONALITY

Regulatory Control Advanced Control Computing Facilities Internal Data Communications Interfaces to Intelligent Instrumentation Communications to/from Associated Computer Consoles and Displays Historical Storage and Trending Alarm Presentation Reporting Engineering Facilities Pre and Post Trip Recording Facility
HARDWARE
System Design Interfaces Analogue Inputs Analogue Outputs Digital Inputs Digital Outputs Smart Transmitter Interfaces Power Supplies Operator Interface Disc Units Printers Screen Copy Device Earthing Cabinets and System Packaging Interconnecting Cables Associated Computer Electrical Standards Labelling and Cable Identification
SOFTWARE
Controller Functionality Execution Speed and Timing Programming Facilities Sequence of Event Recording Control Package for Plant Internal Data Communications External Data Communications Display Facilities Display Attributes Alarm Presentation Trends Data Storage Internal Security Access Security Utilities Start-up, Back-up and Recovery System Clocks On-Line Modifications
SYSTEM PERFORMANCE
Execution Speeds Display Response Display Refresh
RP 30-4
Feed-back Loading Alarm Floods Availability/Reliability
QUALITY ASSURANCE SYSTEM TESTING, SHIPPING AND INSTALLATION

Factory Acceptance Test Foreign Device Interfaces Packing and Shipment Installation Site Acceptance Testing
DOCUMENTATION
Specifications Drawings Test Procedures Operating and Maintenance Manuals Software Documentation Configuration Manuals Documentation for Approval
SPARES
Extent of Spares Firmware Revisions
CONSUMABLES
Vendor Supply Supply During Factory Test
MAINTENANCE SUPPORT
Vendor Support Maintenance Agreements Special Maintenance Equipment Software Maintenance
TRAINING
Configuration Training Maintenance Training Operator Training Inspector Training
APPENDICES & DRAWINGS

APPENDIX I APPENDIX II APPENDIX III SYSTEMS APPENDIX IV APPENDIX V DRAWING I DRAWING II DRAWING III DRAWING IV DRAWING V DRAWING VI DRAWING VII SCHEMATIC & REPORT EXAMPLES INPUT/OUTPUT COUNTS AND PID CONTROLLERS DETAILS OF SERIAL INTERFACES TO EXTERNAL PROGRAMMABLE CONTROL PACKAGE DOCUMENTATION MANUAL DOCUMENTATION INDEX (EXAMPLE) PLANT - PROPOSED PLOT PLAN PLANT - PROPOSED CONTROL ROOM LAYOUT PLANT - DCS PROJECT PROGRAMME PLANT - PROPOSED DCS TOPOLOGY DIAGRAM PLANT - PROPOSED DCS ELECTRICAL ONE LINE DIAGRAM PLANT - PROPOSED DCS BLOCK DIAGRAM PLANT - PROPOSED CONSOLE LAYOUT
RP 30-4
C.2
Instructions To Tenderer
Guidance checklist for ITT contents for an installed contract. More detailed information on ITTs can be supplied by the BP Procurement and Contracts Group.
Comment
INTRODUCTION SCOPE OF PROPOSED CONTRACT As list of key dates PROJECT PROGRAMME SUBMISSION OF TENDER Copies required, form, etc. TS Paragraph compliance INFORMATION REQUIRED WITH TENDER DCS SELECTION SYSTEMS COSTS Presentation of prices DCS Pricing Schedule Documentation Project Costs System Testing, Delivery and Site Installation System Support Training Facilities Power, Off-loading SITE UTILITIES Schedule with milestones PROGRAMME OF WORKS PAYMENT GUARANTEES Parent Company Guarantee Bank Guarantee System Warranty TERMS AND CONDITIONS PROJECT MANAGEMENT AND ENGINEERING SUPPORT Project Manager Lead Hardware Engineer Lead Application Engineer Use of Agency Staff PROJECT IMPLEMENTATION AND ORGANISATION Contract Organisation Project Planning Planning Information Project Reporting Minutes of Meetings Implementation Plan/Method Statement Vendor Support Facilities Procurement and Material Control OTHER COMMITMENTS QUALITY ASSURANCE/QUALITY CONTROL TENDER DOCUMENTS TO BE CONFIDENTIAL FINANCIAL STATUS LANGUAGE ENQUIRIES CONCERNING THE TENDER Completed by Vendor APPENDIX I - DCS PRICING SCHEDULE
RP 30-4
C.3
Front-End Engineering
Guidance checklist of the activities and deliverables during FEED:-. Activities Develop Control Philosophy Develop DCS Outline Design Estimate DCS Size Enquire of Budgetary Costs Estimate DCS Costs Develop DCS Procurement Strategy Evaluate Systems Select Vendor Obtain Endorsement/ Approval of Choice Develop DCS Project Organisation and Implementation Strategy Develop DCS Technical Specification Develop MMI Philosophy Develop Training Philosophy Documents Statement of Requirements Feasibility Study Report [Reinstrumentation] Engineering Basis and Design Data [Grass Roots Projects] Control Philosophy User Requirements Specification Budgetary Enquiry Cost Estimate Procurement Strategy Vendor Evaluation and Selection Report DCS Technical Specification DCS Project Organisation and Implementation Strategy MMI Philosophy
Drawings DCS Block Diagram Proposed Control Room Layout Proposed DCS Project programme Proposed DCS Network Topology Proposed DCS Electrical One Line Diagram Proposed DCS Console Layout
RP 30-4
C.4
Enquiry
Guidance checklist for the activities and deliverables during the Enquiry phase:Activities Develop Invitation to Tender (ITT) Develop Supplementary Conditions of Purchase Raise Secrecy Agreement where appropriate Reconcile Bids Hold Clarification Meetings with Vendors and Clarify Bids Assess Bids Technically Assess Bids Commercially Choose Vendor Obtain Endorsement/Approval of Vendor Choice Issue Letter of Intent. Documents Invitation to Tender (ITT) Conditions of Purchase/Service Supplementary Conditions of Purchase Secrecy Agreement Technical Bid Analysis and Assessment Commercial Bid Analysis and Assessment Recommendation for Purchase Letter of Intent
C.5
Purchase
Guidance checklist for the activities and deliverables during the Purchase phase:Activities Negotiation with Vendor(s) Develop Purchase Specification Develop Contract/Purchase Order Agree Contract Terms and Conditions Contract/Purchase Order Issue and Signature Documents Purchase Specification Purchase Order Contract Delivery Schedule
RP 30-4
C.6
Delivery Schedule
During negotiation the system delivery schedule should be agreed, and this should include services and information that is to be supplied. The delivery schedule should be drawn up as a network diagram or Gantt chart. All significant project dates should be clearly identified, and tabulated in a schedule of dates, (identified as either a Milestone or Key Date). Milestones are generally associated with a contract payment Key Dates are related to project schedule and not usually associated with a contract payment. Significant information due dates should also be tabulated in a schedule of information. The following guidance example is provided:Significant Project Dates By Milestone 1 - Approval of System Design Specification (SDS) and Hardware Drawings sufficient to define system hardware. - Reliability analysis. - Information on total power requirements - Delivery of all Hardware into Staging. - Confirmation of all cable lengths - Completion of System Assembly - Completion of Factory Acceptance - Completion of Site Acceptance - Freeze Date for Hardware - Freeze Date for Software/Configuration - Field Termination Cabinets Available for Delivery .............
Milestone 2 Milestone 3 Milestone 4 Milestone 5 Key Date 1 Key Date 2 Key Date 3
............. ............. ............. ............. ............. ............. .............
Significant Information Due Dates Hardware Console Layout Drawing approval Field Termination Cabinets (FTC) internal layout approval Field Termination Cabinets (FTC) cross wiring approval Control Room Layout System Cable Lengths Software Network Design I/O Tag Design Applications Software Program Design Faceplate Group Design Historical and Real Time Trend Design Display Static Template Design Display Dynamic Design Report Design By ............. ............. ............. ............. ............. ............. ............. ............. By ............. ............. ............. ............. .............
RP 30-4
C.7
Man-Machine Interface Philosophy and Specification

Guidance MMI specification contents:Introduction
Objective
General
Responsibilities Interface Hardware Manning Database Structuring for Alarm and Display DCS Security ESD Security
DCS INTERFACE
DCS Displays
Display Philosophy Hierarchy Operator Change Access Screen Usage Configuration Layout Touch Screen Target Areas Level of Detail Symbols Descriptions Colour Codes Lines Normal Conditions Decimal Places Abbreviations Engineering Units Feedback Date/Time Format
Use of Colour and Attributes

General Colours Visibility Intensity Reverse Video Flashing Fill Level Selection Bad Data
Use of Standard Library Pictures and Symbols

General Controllers Equipment ESD Trip Valves Operator Access Areas Flow Direction Source/Destination Indicators
Area Displays Unit Displays Group Displays Detail Displays Trend Displays Other Displays Alarm Handling Help Displays Allocation of Display References Use of Operator Keyboard Use of Hard Copy Devices Use of Historisation Facilities
ESD INTERFACE
RP 30-4
GAS DETECTION SYSTEM INTERFACE
C.8
Detailed Design
Guidance checklist for the activities and deliverables during the Detailed Design phase:Activities Agree System Design Specification (SDS) Agree methodology for DCS design data management Develop Man-Machine Interface Design Specification Develop and agree interfaces to other systems Obtain design information for ancillary areas, i.e. earthing, UPS, HVAC. Obtain reliability analysis of system Develop and freeze DCS hardware requirements Develop and agree application software requirements Develop "ground rules" for configuration and control scheme design Design and configure system Hold Safety Reviews of system Review DCS security Documents System Design Specification (SDS) Man-Machine Interface Design Specification Vendor specifications Vendor configuration manuals Vendor operating manual Vendor installation planning manual Application Software Functional Design Specifications Vendor reliability analysis Acceptance test procedures Application software manuals Vendor maintenance manuals Hazardous area certification dossiers Configuration listings Screen dumps Drawings and Schedules Console design and arrangement drawings Cabinet arrangement drawings Termination cabinet drawings Earthing drawings Power distribution single line drawings Wiring and system interconnection drawings Cable schedules Termination schedules
RP 30-4
C.9
FAT
Guidance checklist for the activities and deliverables during the FAT:Activities
Develop and agree FAT specification in conjunction with the vendor Develop and agree FAT schedule and resourcing Arrange availability of third party sub-systems and computers where appropriate and feasible Carry out paper checks of configuration prior to FAT Carry out inventory and bill of material checks Carry out hardware testing Carry out software testing Carry out integrated testing
Documents
FAT specification FAT programme and resourcing plan Test scripts for FAT Bill of materials - must be latest Configuration printouts Colour screen dumps Application software flowcharts and listings
C.9.1 FAT Specification

The FAT test specification should reflect the structure and phasing of the testing, and will depend on the vendor's scope, for guidance a contents list for a total system supply is given:INTRODUCTION OBJECTIVES PRE-REQUISITES PREPARATION TEST PROCEDURE & RECORDING OF RESULTS INVENTORY CHECKS LABELLING & PRESENTATION CHECKS HARDWARE TESTING
MODULE TESTING I/O TESTING FIELD TERMINATIONS TESTING POWER, FUSING & EARTHING CHECKS ENVIRONMENTAL TESTS - RFI, Heat, etc. INTERFACES TO OTHER SYSTEMS AND SUBSYSTEMS COMPUTER TESTING
CONFIGURATION TESTING
SYSTEM CONFIGURATION CHECKS I/O DATABASE CONFIGURATION CHECKS MMI CONFIGURATION CHECKS - Displays, Alarms, Trends, etc. CONTROL LOOP FUNCTIONALITY TESTING
SOFTWARE TESTING
INFORMATION & CALCULATION PROGRAM TESTING CONTROL PROGRAM TESTING PLANT COMPUTER PROGRAM TESTING
INTEGRATED SYSTEM TESTS

OVERALL SYSTEM TESTING OPERABILITY TESTING - System response times, etc. SUBSYSTEM TESTING CONTROL SCHEME SIMULATION & TESTING ALARM FLOOD SIMULATION & TESTING FAILURE AND RECOVERY OF REDUNDANT MODULES FAILURE AND RECOVERY OF SINGLE MODULES FAILURE AND RECOVERY OF PLANT COMPUTER FAILURE AND RECOVERY OF SYSTEM
PROGRAMME APPENDICES
PRE-REQUISITE CHECKLIST, PREPARATION CHECKLIST, TEST SCRIPTS
RP 30-4
C.9.2 FAT - Hardware Testing

Inspection Tests labelling and presentation checks cabling checks correspondence with general arrangement drawings Module Testing hardware test programs module failure and recovery testing redundancy testing I/O Testing - consider statistical check here correct operation of I/O points at 3 positions on scale correspondence of field I/O with configured points Field Termination Testing correspondence with design drawings correspondence of field I/O and vendor terminations checks on converters and isolators Power, Fusing & Earthing Checks Distribution and feeder checks Power consumption checks Segregation and Isolation checks Insulation & Fusing checks Earthing checks Environmental Testing RFI/EMI tolerance tests System Testing Network cable failure tests Power Failure tests System clock changes Interfaces to Other Systems and Sub-systems Configuration data checks, baud rate, parity, address maps, etc. Start-up, shut-down, failure and recovery testing Correct correspondence between sub-system and DCS data Computer Testing hardware test programs Start-up, shut-down, failure and recovery testing. Correct correspondence between computer and DCS data
RP 30-4
C.9.3 FAT - Software Testing

System Configuration Full off-line paper checks versus approved design information (Pre-FAT) Full check comparing the online system with approved design information. I/O Database (Tags) Full off-line paper checks versus approved design information (Pre-FAT) Statistical check comparing the online screen version with approved design information. Increase coverage if fault incidence high. Operator Function Database (Faceplates, Trends, Function Keys, etc.) Full off-line paper checks versus approved design information (Pre-FAT) Statistical check comparing the online screen version with approved design information. Increase coverage if fault incidence high. Custom Schematics Spot check a selection of colour screen dumps of the built schematics against approved design information. This checks static elements of the schematic and typically picks up errors in the following:Line detail - colour, shape, thickness, intensity, etc. Titles Display number Tag number static aspects Target static aspects General presentation Check schematics on system to ensure the dynamic aspects of the schematic had been correctly built and applied. This typically picks up errors in the following:Tag correctness and updating Target vectoring Information status presentations, e.g. alarms Reports/Logs Check print-outs for conformity to design and format including:Titles Report/Log no Tag number correctness Dynamic variables Complete Loop Functionality (For complexities beyond simple cascade) Check initialisation, mode changes and correct operation by simulation, e.g.. feeding controller output into the measured variable for all slave loops. Check resilience to transmitter failure and general operability. Interlocks Check logic for conformity to design. Check operability and presentation to the operator
RP 30-4
C.10
Delivery and Installation

Guidance checklist for the activities and deliverables during the Delivery and Installation phase:Activities Arrange for vendor inspection of DCS equipment and control rooms Check for completions of all ancillary Civil, Electrical, and Instrumentation works necessary for delivery Develop and agree delivery and installation plan Develop procedures to prevent ingress of dust and dirt into DCS equipment where necessary Review fire precautions for DCS equipment and control rooms Documents Delivery and Installation Plan
C.11
SAT
Guidance checklist for the activities and deliverables during the SAT:Activities Develop and agree SAT specification in conjunction with the vendor Develop and agree SAT schedule and resourcing Carry out inventory checks against bill of material and shipping list Carry out documentation, drawings, and media checks Carry out hardware testing Carry out software testing Carry out integrated testing Documents SAT specification SAT programme and resourcing plan Test scripts for SAT Shipping List Bill of materials - must be latest Full system documentation - manuals, drawings, media
RP 30-4
C.12
Precommissioning and Loop Testing

Guidance checklist for the activities & deliverables during precommissioning and loop testing:Activities Plan pre-commissioning and loop test activities with construction and commissioning staff. Establish loop testing resourcing, organisation and schedule. Develop loop test procedures. Generate loop test dossiers. Mobilise test teams and familiarise them with test procedures and DCS operation. Carry out loop testing. Use pre-commissioning test runs to check out & set-up advanced control and sequencing. Develop system change control and housekeeping procedures. Documents Loop testing organisation and schedule Loop testing procedures Loop test dossiers System change control and housekeeping procedure.
C.13
Commissioning
Guidance checklist for the activities and deliverables during the commissioning:Activities Plan and resource DCS commissioning activities in association with operations staff. Set up DCS starting parameters for commissioning. Prepare documentation packs for Hot loop changeovers (Re-instrumentation). Train and prepare operations staff for advanced control loop commissioning. Prepare advance control loop operating procedures and write-ups Documents DCS commissioning plan and schedule. Hot loop changeover documentation packs. (Re-instrumentation) Advanced control loop descriptions and operating procedures.
RP 30-4
APPENDIX D ABRIDGED AMHAZ METHODOLOGY AMHAZ is a methodology to identify, and provide recommendations to prevent potential hazards created by disabling alarms in an Alarm Handling Package (AHP). AMHAZ provides the end-user with assurance that the AHP can be safely put into service. Study Timing Items to be available: functional specification for the alarm management software operating scenarios in which alarm disablement will be effected together with the process parameters to be to trigger those scenarios list of alarms to be disabled for each operating scenario (Experience may lead to the situation in which AMHAZ can be applied at the same time as the selection of operating scenarios and selection of alarms to be disabled, i.e. at the initial design stage. This may be both cost and schedule effective by utilising the team making the selections as the core of the AMHAZ team and saving any potential delay to implementation of the system due to changes resulting from the AMHAZ study.) Core team Chairman experienced in AHMAZ; capable of leading the team; familiarity with the process of the plant to be studied would be beneficial but is not essential CR Operator experienced with the plant to which the AHMAZ relates Process Eng. familiar with the plant to be studied Additional team members Engineer from alarm management system vendor Site Control/ Systems Engineer Site Safety Engineer Functional Design Specification for the alarm management system which includes details of the operating scenarios for disablement, the operating parameters selected to identify the scenarios and the lists of alarms to be disabled. Up-to-date Process and Instrumentation Drawings (P&IDs) for the plant Cause and Effect charts for the plant HAZOP and / or CONSOP study of the plant
Team Composition
Documents Required
RP 30-4
Getting Started
Familiarisation with the process and control details of the plant from drawings and documentation. Presentation by someone closely involved in the design on the specific proposals Chairman should then describe the AMHAZ methodology and the manner in which the study will be conducted Operating scenarios:Taking each operating scenario in turn, discuss the operating parameters selected to identify each scenario in the AHP. Agree if the proposed operating parameters uniquely identify the scenario or if other operating conditions would also be identified. The scenarios addressed should include the default or fallback scenario (which, in most cases, would be expected to enable all alarms) and discuss all the conditions under which that scenario would be selected. e.g. normal operation of the plant, failure or false signals on the input to the alarm management system, failure of the alarm management system itself. The alarms to be disabled (a) Led by the chairman the team decide on which operating scenario to address first, e.g. start-up, heatoff, feed trip, etc..(There is likely to be more than one operating scenario to be addressed in the study and to focus the concentration of the team, it is recommended that if there are more than two scenarios then all the alarms are studied for one operating scenario before moving on to the next scenario. If there are only two scenarios it may be possible to consider each alarm for both scenarios before moving on to the next alarm. If in doubt, one scenario at a time should be the rule.) (b) The chairman selects the first alarm to be studied and the team identify it on P&IDs and agree on its basic purpose(s), e.g. it is a high temperature alarm to warn that a product rundown temperature is getting too high and could cause a problem in the storage tank (c) The HAZOP and / or CONSOP report for the plant is checked for any specific requirements for this alarm. (d) The team then consider the effect of the alarm being disabled under the operating conditions pertaining to the scenario being studied. The chairman should lead the team considerations by structuring a series of questions to the team as well as allowing free-ranging team discussion of the impact of disabling the alarm. The structured questions to the team should include:-
Perform Study
RP 30-4
(e)
(f)
(g)
For the selected operating scenario, is the loss of the agreed basic purpose of the alarm likely to create a hazard or lead to an operational difficulty? Is the alarm used for a purpose other than the agreed basic purpose, i.e. is it used to infer a problem elsewhere, and, if so, does loss of the alarm for the inferred purpose create a potential hazard or operational difficulty? Is there another alarm which will provide similar information, e.g. a pump stopped alarm and a pump discharge low flow alarm could, in many circumstances, provide the same information to the control operator, and, if so should one, other or both be disabled? Is there any other potential hazard or operability problem created by disabling this alarm? If any potential hazards or operability problems are identified a record is made on the AMHAZ log sheet to identify the potential hazard or operability problem and to make a recommendation for change. The chairman then leads the team through steps b) to e) for the other alarms proposed to be disabled in the selected operating scenario. When the first operating scenario has been completed, steps a) to f) are repeated for each remaining operating scenario.
Reporting
The main study reporting will be on report sheets. As a minimum, the report sheet should include: alarm tag identification function of the alarm operating scenario considered implication on the plant if the alarm is disabled (relating to the operating scenario being considered) any additional function which is inferred from the alarm any other alarm from which the function of the alarm being considered can be inferred any potential hazard or operability problem identified any recommendation or comment In addition to the report sheets, the AMHAZ report should include the following: brief details of the application including identification of the plant and the application vendor/ system name a list of the team members and any advisers, the documents
RP 30-4
used, the timing and location of meetings a statement of the recommendations and conclusions of the study team including a statement that, subject to satisfactory resolution of the recommendations contained in the report, the application can be put into service safely. (It is anticipated that the text element of the report will be quite brief and the main information will be contained in the report sheets.)
RP 30-4
BP SITE / ASSET SOFTWARE CHANGE REQUEST FORM
Change Request Serial Number
1. DESCRIPTION OF CHANGE REQUESTED (All relevant drawings must be attached)
6.
Approved By:
(Sign and Date)
SOFTWARE CHANGE REQUEST FORM
Operations Engineer (O) Process Engineer (P) Instrument Engineer (I) Systems Engineer (S)
Above signatures are mandatory and Letter code signifies responsibility for completion of section 5
RP 30-4
2. ORIGINATED BY:
DATE:
Systems Control Engineer
3. IMPACT OF CHANGE ON DCS / OTHER SYSTEMS:
Other .. 7. IMPLEMENTATION COMPLETED

Sign and Date SYSTEM CONFIGURATION SOFTWARE WORK BACKED-UP
4.
: SAFETY CHECKS
Encircle as Appropriate
5. RELEVANT DOCUMENTATION UPDATED Sign
HAZOP Required? PMP Required? Alarm Handling Impact? Change Permanent? (if No specify in section 3)
YES YES YES YES
NO NO NO NO
Alarm & Trip Schedule Register ofSafety Related Devices P+IDs Loop Diagrams Operating Procedures
I P P I/S O
APPENDIX E
BP SITE/ASSET SOFTWARE CHANGE REQUEST FORM
Notes for Completion of Software Change Request Form Originator to complete this section giving a Section 1 description of the change required. Section 2 Originator to print his name and date request.
Additional Comment Space
Any person who is party to completing the Section 3 SCR should detail impact on DCS or other systems affected by the requested change. Any person who is party to completing the Section 4 SCR should note the impact of any safety implications with respect to the requested change. It is then incumbent on the senior signatory authority in the process area of the requested change, as to the requirement for safety checks/audits. Encirclements should be initiated by the Engineer making the comment. This section should be completed by the Section 5 discipline Engineer identified by the Discipline Letter Code adjacent to the document type that may need updating. It is incumbent on the identified discipline to ensure that the relevant documentation is updated. Approvals should be signed for as Section 6 appropriate. For simple changes all signatory disciplines may not be needed. In such cases the discipline deeming that another discipline does not need to authorise the change should p/p for that discipline. Record of the completed work should be Section 7 signed for and dated.
RP 30-4
SUBSEA CONTROL SYSTEMS
The old Section 4, Subsea Control Systems, has been removed from this latest (February 1998) issue with the intention of producing a separate document covering Subsea Control Systems or a new Subsea document with a section within it covering Subsea Control Systems.
RP 30-4

BP RP30-4

Uploaded by

Copyright:

Available Formats

BP RP30-4

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BP RP30-4

Uploaded by

Copyright:

Available Formats

RP 30-4 INSTRUMENTATION AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS - SYSTEM DESIGN AND CONFIGURATION GUIDELINES

Copyright The British Petroleum Company p.l.c.

Copyright The British Petroleum Company p.l.c.

Latest Amendment Date

INSTRUMENT AND CONTROL CONTROL AND DATA ACQUISITION SYSTEMS

AMENDMENTS Amd Date Page(s) Description ___________________________________________________________________

CUSTODIAN (See Quarterly Status List for Contact)

Control & Electrical Systems

Power Supply Hardware I/O Control Control Configuration

MMI; Alarm Handling

Full vendor training courses

Process engineer Plant management Maintenance technician

Before loop testing at site

(e) (f) (g)

(h) (i) (j) 2.2.2

(v) (w) (x)

Front End Engineering Design (FEED)

Include specific rules for implementing the design of displays.

Temperature per Casing T/C 8 6 2 DI

4-20mA Compressor Turbine Turboexpander Hi-Speed Pump 2 1

Screens per Operator

Well Known Established (not well known) New and untried

Minm recommended Normal range Maxm recommended

Extent of Historical Information/ Trending

System Safety Review

Typical Review Subject Categories Documentation Required

Typical Review Subject Categories Documentation Required

(i) (j) (k) (l) (m)

Basis of charging for contract variations.

Completion of Factory Acceptance Test Completion of Site Acceptance Test

Other discipline support

Usually subject to BP approval

DCS Installation Specification of ancillary equipment

Definition of detailed design

Usually subject to BP approval

Live documents subject to revisions until design is frozen

Usually subject to BP approval

Definition of test procedures Operator Training

4.2 4.2.1 4.2.1.1

(e) (f) (g)

Access to all of the displays used by all of the operating teams

The supervisor needs rapid access to emergency operating procedures.

A series of different and distinctive features should be provided.

(e) (f) (g)

(j) (k) (l)

segregate control and protection should be recognised and carefully considered.

(e) (f) (g) (h)

(i) (j) (k) (l) (m) (n) (o) (p)

Clear Identification of Abnormal Conditions (Alarm Displays).

Help Displays for Unusual Conditions.

Task Oriented Displays

Detail Point Displays.

Controller Face-Plate Displays.

Level 2: Process Area

Level 3: Process Unit

Level 4: Detailed Displays

this level. Focus on a single controller, measurement, interlock, subsystem, etc.

(d) (e) (f)

Incoming feeds and outgoing products should be labeled.

(b) (c) (d) (e)