This article outlines the practices and conventions of the implementation for DCS that should be followed in control applications, configurations, hardware, power, and grounding systems, and installations depending on application for a particular plant/process.
1. Scope
This article applies to all DCS equipment and associated software required to control and to monitor a process plant. It shall be used in conjunction with SES-X02-S01.
This article excludes field instrumentation, auxiliary systems, remote terminal units, management information systems, and advanced control systems.
2. References
Reference is made in this article to the following documents.
X01-E01 Control System Design Criteria
X02-S01 Distributed Control System Specification
3. Definitions
Application Software. Software written functions specific to an operating unit, plant, or project. Application software does not modify standard software, but works along with it.
Annunciator Keyboard. A key on a workstation keyboard which has alarming functions and a light. The light can flash or be steady to indicate alarm conditions on displays accessed by pressing the key.
Communication Link. The physical means of connecting digital equipment at one location to digital equipment at another for the purpose of transmitting and receiving digital information.
Console. A logical grouping of workstations and associated equipment used by the operator/supervisor/engineer to interface with the process.
Control Network. It is the Ethernet network where process control data is handled among the controllers and workstations
Discrete Input. A signal having only two states. Examples are status signals (OK/failed, running/stopped) and control signals (start/stop). These are represented in external wiring as occurrences of current flow (or none) and in control systems as one bit being a „one‟ or a „zero‟.
Fail-Safe. Design features incorporated for automatically counteracting the unsafe effects of an anticipated possible source of failure. A system is fail-safe if failure of a component, signal, or utility, initiates action that returns the system to a safe condition.
Redundancy. A system and subsystem configuration that provides automatic switchover, in the event of a failure, without loss of a system function.
Reliability. The probability that when operating under stated environmental conditions, the system will perform continuously, as specified, over a specific time interval.
Process Area. The plant process units are combined under process areas for purposes of maintaining production during plant down time for maintenance or due to catastrophic failure of 1 or more process or control units.
Process Unit. Specific production part of the plant.
Scan Period. The time in which CPU of the controller executes the standard control functions.
Scan Cycle. The total time to scan inputs, execute control alghorithms, and transmit outputs to field devices.
System Operating Software. Vendor‟s standard software that performs the basic function of the system
Third-Party System. Any control and/or instrumentation equipment which is manufactured/supplied by other than DCS VENDOR, and which requires integration or digital
communication with the DCS.
Typical Plant Architecture. Refer to Figure-1.
DCS Terms Abbreviations and Acronyms
BMS Burner Management System
BPCS Basic Process Control System
CCR Central Control Room
CCS Compressor Control System
EWS Engineering Workstation
FO Fiber Optic
LEL Lower Explosive Level
MIS/PIMS Management Information System, Plant Information Management System
MTBF Mean Time Between Failure
MTTR Mean Time to Repair
4. Distributed Control System DCS Implementation Guidelines
4.1 The article is not based on any manufacturer‟s system. If any term of a manufacturer is used, it is unintentional and does not mean the equipment is preferred or mandatory.
4.2 Applications shall conform to the conventions of this specification, but it is recognized that there will be occasions where specific performance requirements necessitate that the conventions and practices outlined here will be modified. When such requirements are identified, the application shall be reviewed with SABIC before that aspect of the design is finalized.
4.3 The design of DCS, in addition to the typical process control and monitoring functions, shall address a number of issues that are associated with operation and maintenance of a complex integrated control system. These are described in general terms and the design guidelines in this document and directed towards satisfying these requirements.
4.4 All network communications shall be redundant and installed such that simultaneous damage to both paths is extremely unlikely. The system shall be designed such that even a highly remote occurrence of failure of both redundant paths will not affect the control of the process. Designs shall also be such that any failures are isolated.
4.5 The systems shall be designed so that system maintenance may be readily performed without excessively exposing the system to failures or upsets. The following design practices will enhance maintainability:
a. Use of redundant I/O for all control loops
b. Clear labeling of all I/O modules, cabinets and communications cables
c. Consistent layout of cabinets and standard I/O module addresses versus physical locations
d. Consistent use of standard configuration and programming techniques for common functions
e. Use of redundant power supply.
5. Process Considerations for System Implementation
DCS design shall meet the type of process requirements, i.e. continous, batch, and mixed processes as mentioned in SES-X01-E01.
5.1 Types and Capacity of I/O
The following guidelines help in improving the availability and maintainability of process:
5.1.1 Grouping of I/O signals belonging to a particular process unit shall be considered under separate controller. If the number of I/Os are less, related process unit I/Os can be combined under the same controller.
5.1.2 Remote I/O implementation for the process areas such as bagging lines
5.1.3 Use of redundant I/O and FO cable for interfacing remote I/O with control systems
5.1.4 Limiting the process upset from the failure of a single system component
5.1.5 Assignment of parallel (process) equipment I/Os to different I/O cards
5.1.6 Limiting the single failure of a cable, I/O card, connector, etc. to affect maximum one piece of process equipment, primary or backup, from the same system.
5.1.7 Similarity in design/layout of I/O, assignments, and configuration for parallel equipment
5.1.8 Segregation of design and configuration of the DCS hardware to provide risk isolation for common or parallel plant equipment.
5.2 Operability Requirements
5.2.1 When control and monitoring functions are assigned, the relationship of units assigned to a controller shall be reviewed to verify that all of the units controlled by the controller can reasonably be expected to be shutdown together.
5.2.2 Units that cannot be shutdown together shall not share the same controller. For example parallel process trains that are shutdown (for maintenance) one at a time and cannot all be shutdown together without causing an entire plant shutdown shall not share the same controller. For example multiple furnaces in an ethylene plant or boilers, air compressors, air dryers etc., shall be distributed across many controllers to facilitate the maintenance and operability of individual units without shutting down all of them.
5.3 Plant Criticality and Equipment Reliability
Control system segregation is required for process units that are critical for continuous plant operation and to ensure equipment reliability for multiple trains or spared equipment. The following are guides to system segregation.
5.3.1 The plant process units are separated into Process Areas for purposes of maintaining production during „down‟ periods for plant maintenance or due to catastrophic failure of 1 or more process or control units.
5.3.2 The DCS equipment, including Operator Workstations, controllers, I/O, auxiliary equipment systems, and other control equipment in each process area, shall be dedicated to that particular process area.
5.3.3 The loss of operations in one process area shall have no effect on the functionality and operability of the DCS in the remaining process areas.
5.4 Security Features
Following recommendations shall be evaluated by project based on security, cost, safety, and operation requirements.
5.4.1 The assignment of unit numbers to each console for its area of control
5.4.2 Security features, which ensure, during normal operating conditions, only one console has the control capability over a given unit
5.4.3 Security features, which ensure, during normal operation, a console to only view and monitor areas that are not assigned for control from it
5.4.4 The method by which equipment can be taken out of service for maintenance and avoid alarming, while the process module continues to operate
5.5 Scan Period
Loop processing speed is dependent on the scan cycle of the control system. Scan periods are configurable for each loop and are chosen based on the type of process variable and rate of change.
5.5.1 The scan period indicates the functional block processing time. It does not include I/O signal conversion time for controllers, and transmission time.
5.5.2 As a minimum the following scan periods for the execution of each specific application to be set per Table I.
5.5.3 Memory and processing allocation for control processor shall be described in detail.
5.5.4 After verification that all the known tags and spare requirement have been configured, the memory and processing allocation shall be revisited and adequate spare capacity is ensured.
5.6 Plant Control Complexity
5.6.1 Selection of a control system is not only dependent on the type of process, but also the complexity of the process. Consideration shall be given to the flexibility of the DCS to make process control changes after the system is installed and commissioned.
5.6.2 Often for more complex processes, the actual process performance is much different from the theoretically designed process. The performance specified in SES X02-S01, DCS Standard, shall be ensured.
5.6.3 The control system shall be user friendly in design so that operator training is minimized and operator reactions to process upsets are prompted by logical screen displays.
6. Emerging Technology and Changing System Conditions
6.1 Use of Standard Products
6.1.1 System operating software shall not be modified to meet SABIC requirements.
6.1.2 Application software shall be designed in a manner that requires no modification to the system operating software.
6.1.3 Software design shall be such that future revisions or updates of the system operating software will not affect the successful operation of the system.
6.2 Software Protection
6.2.1 No software or hardware locking mechanisms that restrict the user from copying the application software source or application program from the storage media shall be employed. No software or hardware locking mechanisms that restrict the user from booting shall be employed.
7. Software
7.1 Hierarchy in Control Software
7.1.1 This section provides examples of major aspects of security and access levels and shall be used as a guideline.
7.1.2 Selectable/pickable actions, i.e. actions defined by the “select” attribute, shall be user configurable and assignable as per project requirement.
7.1.3 The DCS shall allow for the setup of multiple, password-protected environments.
7.1.4 Each environment shall provide the user with a unique set of menu selections, giving access to a variety of displays and software resources.
7.1.5 The environment selection shall be made available either from logging or from dedicated icon on the pull-down menu.
7.1.6 Environments shall be created with names that relate to a specific user group.
7.1.7 The environments shall be further distinguished by predefined access levels to individual target and icon points on displays and pull-down menus.
7.1.8 The user shall automatically be given specific access to one or more access levels upon entering an environment. He shall then be able to activate only those points with matching settings.
7.1.9 The boot-up environment for an operator console shall be configured for „Operator‟. No password shall be required for entry into the boot-up environment.
7.1.10 The „CHANGE-ENVIRONMENT‟ menu item shall give access to all other environments. Access shall be restricted to access levels with the appropriate password for all but the view-only environment.
7.1.11 The creation of an environment, including the assignment of a password and top menu bar field, shall be done by appropriate personnel with access to environment/password configuration utilities.
7.1.12 This standard provides examples for major aspects of file management and shall be used as a guideline.
7.1.13 Environment files describing the basic environments set up shall reside on the same system directory containing configuration files.
7.1.14 Pull-down menu files are created as required to allow for a specific order to the pull-down menu file listing and to restrict access to individual menu items by security level.
7.2 Third Party System Interface
7.2.1 The DCS shall receive confirmation from the associated device logic whenever an input is bypassed from DCS or returned to service, if permitted.
7.2.2 All the input bypass confirmation from the auxiliary equipment system logic shall be alarmed and logged in DCS.
7.2.3 In case bypassed from DCS, an alarm shall be initiated if the action confirmation message is not received within preset time.
7.2.4 Time-out shall be set to 10 seconds as default.
7.2.5 DCS shall log all the reset confirmation from the auxiliary equipment system logic in the event log.
7.2.6 The data scaling to represent the process value shall be done and shall be transparent to the operator.
7.2.7 DCS communication to the PIMS/MIS, plant networks and other non-control computer systems shall be designed to ensure that any failure in the external systems, request for information, or network loading problem will not impact the performance or availability of the DCS.
7.3 Operator Workstation Interface Details
7.3.1 This section provides examples of configuration for the operator displays and is to be used as a guideline for the generation of their design.
7.3.2 Design shall include the following for each operator workstation:
a. Name and Node number
b. Console Number and address, physical and logical
c. Process areas to be operated
7.3.3 The operator interface shall consist of custom and standard displays, and overlays to provide a complete and integrated interface for monitoring and controlling the process.
7.3.4 Identification of each of the programmable function keys, using a label, describing the function and displays assigned, to be provided on operator keyboard.
7.3.5 All operator functions relating to normal, abnormal, emergency or any other operations shall be available from the operator consoles.
7.3.6 OWS of a specific process area, shall control any process or process unit within that process area.
7.3.7 Any OWS, Supervisor workstation, etc shall control any process or process unit within any other process area under password control.
7.3.8 Under normal operating conditions, other units may only be viewed and monitored from a console not assigned to that unit.
7.3.9 Equipment can be taken out of service for maintenance, while the controller continues to operate. This allows the operator to do group alarm inhibition or masking.
7.3.10 A hierarchy of displays shall exist. For example, the Plant Overview display shall give access to unit or area menu overview displays, which in turn shall give access to process operating displays, which in turn shall give access to monitoring and control overlays.
7.3.11 The primary objectives of display design shall be safety, operability, and maintainability.
7.3.12 All operator control functions shall require at least confirmation action before it is sent to controller that is no single operator action can initiate a control change.
7.3.13 Access to specific displays and pick points is restricted by password protection.
7.3.14 All Displays shall conform to standards that provide consistency in appearance and operation as defined by the plant operating philosophy. This shall include display layout, data and alarm representation, color choices and navigation procedures.
7.3.15 Display management capabilities shall provide features to minimize operator time spent on positioning, sizing, minimizing, and maximizing the windows. These features shall include but not be limited to the following:
a. Window attributes such as size, origin, and style
b. A software mechanism to consistently place similar display windows in the same area of the screen
c. Display management to close the older windows when a new window is opened so as to avoid loading up of display memory
d. A safeguard wherein the critical displays cannot be overlaid by other non-critical displays
e. A predefined set of windows shall be displayed whenever a console is started
7.3.16 Generic displays e.g. control and I/O overlays in particular, shall be used to ensure that standards are applied consistently and to enhance maintainability.
7.4 Graphics Specification Overview
7.4.1 User Friendly Graphical Design
a. Graphical design shall be user friendly and shall follow a site or plant standard in use of colors, shapes, and responses to operator actions.
b. Such standardization enhances operator efficiency and positively affects safe operation of system, particularly during upset conditions when quick scanning of information and response is essential. Following shall be ensured in the design of graphics:
i. Operator consistently has the needed information on display or easily accessible.
ii. Highly animated objects that may inadvertently divert the operator from important process information are avoided.
iii. Color usage for optimum operator awareness of abnormalities is established.
iv. Content convey the appropriate information consistent with the tasks performed using each display.
v. Navigation accesses the necessary display as effectively as appropriate to the related tasks.
vi. Audible indicators are appropriate to the associated situation.
7.4.2 This category includes all DCS vendor standard displays, as well as any specific custom displays created e.g. for data collection and reporting requirements.
a. DCS vendor standard displays as a minimum shall include messages, help, reporting, scheduling, configuration, process and system alarm, trend, tag detail, system
diagnostic, communication network and node status, and special-function displays e.g., Historian archiving, on-screen calculator, etc.
b. Standard displays shall be well documented within the appropriate DCS vendor standard documentation.
7.4.3 Overlay displays shall provide an alternate window to process and equipment information.
a. Overlays shall be called up from a main process or equipment display.
b. Vendor standard faceplate-type overlays used for I/O monitoring and control shall be set up in generic fashion. This shall ensure that the overlay displays are similar in
appearance and operation.
c. Each overlay shall be called up such that it does not overlap any information within or immediately surrounding the calling field.
d. A target shall be configured on the overlay itself to close the overlay.
e. Multiple, successive overlays may be called up simultaneously.
f. Feature to close one overlay at a time or to close all of the overlays simultaneously shall be available.
g. The data transmitted digitally from various auxiliary equipment systems shall be shown on standard faceplates identical to those transmitted from a hardwired I/O point.
h. The various types of I/O and controller overlays created shall be documented by the DCS vendor.
7.4.4 A Plant Overview Display shall be created showing the various process areas within the facility i.e. the individual units.
a. General availability, inlet and outlet flow, pressure and temperature of each unit and common alarm statuses of H2S/Fire/LEL detectors shall be shown for each area/unit.
7.4.5 A menu display shall be created for each area/unit.
a. The menu shall offer a listing of the various displays available for the given area/unit and give target access to each display listed.
7.4.6 Area/unit overview displays shall be created to allow the operator to monitor large areas of the plant at one time e.g. whole trains or units.
7.4.7 Sub-area overview displays shall be created to provide the operator with an overview of process conditions in a specific sub-area of the major area/unit/train.
a. Typically, the focus of the display is an arrangement of multiple pieces of equipment with a common function.
7.4.8 Special-function overview displays shall be created to group related functions/items into a single display window.
7.4.9 Equipment summary displays shall be created to provide the operator with an overview of the operating conditions associated with specific types of equipment e.g. pumps, blowers, etc.
a. Key/summary information, such as motor run statuses and alarm conditions, shall be shown.
b. The display shall allow the operator to identify the „IN-SERVICE‟ versus „OUT-OFSERVICE‟ status of the equipment.
7.4.10 Process graphics, i shall be created to allow the operator to monitor, control, and acknowledge alarms within his specific operating domain.
a. Process graphics shall be defined based on the P&IDs.
b. Functions associated with a given piece of equipment, process area or operation shall be combined into a single process graphic as far as possible.
c. Process graphics shall show all major equipment and process piping associated with DCS controls, as well as providing the complete I/O and control information needed to
operate the facility.
d. Where space permits, miniaturized trends shall be installed within vessel or equipment display elements, to record levels, pressures, or temperatures associated with the vessel or equipment.
7.4.11 Equipment detail displays shall be created whenever a piece of equipment has a significant amount of information not otherwise associated with control of the main process.
a. The equipment-specific information shall normally appear only on the equipment detail display and not on the process operating display.
7.4.12 Advanced control displays shall be created and shall be selectable from targets on related process operating displays.
a. Targets on advanced control displays shall allow the operator to return to the calling display.
b. All information relating to the application shall be contained within a single display as far as possible.
c. Process operating display guidelines shall be used for simple controllers and indication.
d. Lines representing software linkages between the software blocks in the application shall be shown.
e. A help display, or other useful information embedded within the advanced control display, shall be provided.
f. Control and data entry e.g. manual ratio adjustment shall be initiated from faceplates or specifically designed pop up windows.
7.4.13 Batch process flow chart displays shall show the various steps, sequences involved in each step, the present state of the sequence, the operating parameters for that sequence, etc.
a. From this display the operator shall be able to control the process such as put the sequence into auto or manual mode, select options such as two vessel or three vessels,
regeneration, on line or standby modes etc., stop or skip a sequence etc.
b. A help display, or other useful information embedded within the sequence control display, shall be provided.
c. Control and data entry e.g. manual ratio adjustment shall be initiated from overlays.
7.4.14 Equipment shutdown displays shall contain ESD/DCS information relating to the automatic or manual shutdown of equipment.
a. There shall be equipment shutdown displays that shall include trip status signals, permissives, etc. associated with the ESD logic, as well as soft shutdown and reset
signals initiated from the DCS.
b. The alarm texts on the trip status displays shall be configured to reflect the shutdown alarm descriptions.
c. The shutdown alarms „RESET COMPLETE‟, „PERMISSIVES CLEAR‟, and „READY TO START‟, text shall be shown. The colors shall change between green and yellow.
d. Shutdown and reset operations shall be initiated via „EXECUTE‟ screen targets. The user shall select the appropriate shutdown or reset item and then select „EXECUTE‟ to implement the action.
7.4.15 The shutdown valve‟s open / close status shall be displayed in one single graphic page for each process unit. Pick points for each valve tag shall call up the valve overlay.
a. Shutdown and reset operations shall be initiated via „EXECUTE‟ screen targets. The user shall select the appropriate shutdown or reset item and then select „EXECUTE‟ to implement the action.
7.4.16 Equipment shutdown bypass displays shall permit the user to bypass individual trip signals in the ESD logic, if permitted.
a. Bypass and return-to-normal „EXECUTE‟ target boxes shall be configured to complete the bypass action for a selected tag.
b. Bypass operations shall be initiated after password verification. The user shall enter the password or he may have the option to cancel the action.
c. A confirmation feedback from the ESD logic shall be configured for providing the BYPASS alarm in DCS.
7.4.17 Displays similar to the equipment shutdown bypass displays shall be created to bypass motor interlock signals.
a. All the motor‟s RUN / STOP status shall be displayed in one graphic for each process module.
b. Bypass and return-to-normal „EXECUTE‟ target boxes shall be configured to complete the bypass action for a selected tag.
c. Bypass operations shall be initiated after password verification. The user shall enter the password or he may have the option to cancel the action.
d. A confirmation feedback from the motor control shall be configured for providing the BYPASS alarm in DCS.
7.4.18 Fire and gas displays shall show approximate locations and current statuses of fire and gas detection devices.
7.4.19 ESD health statuses shall be shown on a single display for each ESD.
a. Status of each chassis, module, and point associated with the ESD shall be available.
b. Cabinet displays shall provide information on cabinet temperatures, fan running status, power monitoring, and any other diagnostic information.
7.4.20 The health status of various auxiliary equipment systems such as Vibration Monitoring Systems, Compressor Control System, Turbine Governor Control System, etc. shall be shown on a single display, if the auxiliary equipment system sends its status information to DCS.
a. Status of each chassis, module, and point shall be available.
b. Cabinet displays shall provide information on cabinet temperatures, fan running status, power monitoring, and any other diagnostic information.
7.4.21 DCS cabinet displays shall provide information on cabinet temperatures, power monitoring, and any other diagnostic information.
7.4.22 Each compressor display shall have a sub menu to access control calculations, control overview, process tuning for the various controllers of the CCS, compressor anti surge tuning page, alarm set point displays, group display, and the trend pages.
7.4.23 There shall be displays that indicate the status of the UPS, battery charger, and associated equipment.
a. A display of each associated electrical single line diagrams shall be displayed.
b. Each breaker‟s OPEN/CLOSE status based on the Motor Control Center feed back, the current, voltage, power, fault statuses etc. shall be displayed.
c. If smart electrical protection relays are interfaced digitally with the DCS, a breaker icon with a target box shall be configured to show the parameters as defined in the P&ID.
7.4.24 There shall be displays to indicate the status of various analyzers in a plant. Each tag shall be configured as a target area.
a. On selecting a target area, a tag in this case, each component‟s current process value measured by the respective analyzer, the analyzer‟s operating status, the status of the sample handling system, the shelter‟s environmental status etc. shall be displayed.
7.4.25 An overview of all the nodes connected by the communication links and the status of the entire system architecture shall be provided.
a. A hierarchical display shall be provided to show the DCS groups at the Plant Wide or System Network level.
b. The process area DCS level shall show the actual cabinet layout with the chassis, modules, and associated I/O and the power supply statuses, including auxiliary
equipment systems cabinet status.
7.5 Historical Trending and Events
This specification exemplifies major aspects of DCS Historization and Data Archiving/Trending, and Event handling configuration and shall be used as a guideline.
7.5.1 Data collection reporting requires the following to be defined and configured:
a. Definition of historization hardware e.g. historian, quantity, location, redundancy, the memory allocation for various data collection etc.
b. Disk drives for archive and system loading operations
c. Application packages for retrieving various types of data such as alarm and message interface, SOE data retrieval, pre and post trip reports, report generation, process log and free format report applications, etc
d. PIMS/MIS and other auxiliary equipment system data interface. Definition of data security, normalization, tags conversion, and time synchronization etc.
7.5.2 The reporting function shall be configured to be executed in the background and shall not stop or delay other logging operations.
7.5.3 Some of the reports may also be executed in the PIMS/MISTo avoid loss of reporting during the down time of MIS, the DCS shall be configured to print the periodic reports e.g. shift logs, daily logs, etc.
7.5.4 The historian shall be set up to handle continuous e.g. analog, data as well as differently from non-continuous e.g. discrete and message data.
a. Continuous Data: The historian shall be configured to collect snapshot data at specified time intervals and log the trend information into database files associated with individual data points. Reduction operations e.g., averaging, will be performed on the data to meet reporting needs.
b. Non-continuous Data: A number of predefined message classes shall be available to log specific data into, multi-point files, as new data appears e.g., alarms, events, and operator actions. These shall be typically referred to by a name uniquely associated with the message class e.g., „operator actions‟, etc.
7.5.5 All analog inputs, controller set points, analog/controller outputs, and calculated values shall be logged to the historization module as sample collection data. All equipment run statuses shall be logged to the historization module as well. Additional discrete points required for reports will be added as part of detailed design.
7.5.6 The data shall be further classified based on calculations required such as averaging, totaling, minimum, maximum etc.
7.5.7 Averaging operation shall be configured for all analog data points.
7.5.8 Run time cumulative values shall be configured for all rotating equipment.
7.5.9 Bad quality data flag shall be configured to automatically inhibit the data sampling.
7.5.10 Each historized record shall include:
a. Point identifier e.g. tag name, block name, and parameter name)
b. Time and date stamp
c. Point and engineering unit descriptor
d. Value
e. Status tag i.e. „Bad‟ signal
7.5.11 The following types of alarms and event messages shall be configured for historization:
a. System Management messages
b. Process alarms
c. Event alarms
d. Sequential control block messages
e. Sequence of Event reports from Burner Management Systems/ESD
f. Operator actions
7.5.12 Data shall be configured to be retrieved in trend displays, reports, or tabular listings.
7.5.13 Configuration shall provide capability for the operator to retrieve data by setting up filters as below:
a. Start time and date
b. End time and date
c. Block name
d. Tag name
e. Controller name or address
f. Alarm priority
g. Alarm or message type
7.5.14 Shift times, the average, production quantity, and quality, maximum, minimum values of various process parameters, upset and abnormal situations, points taken out of service, etc., in a shift shall be defined for report generation packages.
7.6 Levels of Processing
This section provides a guideline and examples of input, output and controller configuration for various levels of processing.
7.6.1 Following describes the DCS data acquisition for all I/Os in the DCS via hardwiring, digital communications, internal computation, or manual keyboard input.
a. Regulatory control and monitoring to be utilized for all process units, utilities, auxiliary equipment systems and miscellaneous instruments installed on equipment and systems.
b. The following utility and engineering capabilities and programs are to be provided for the systems supplied:
i. Run system utilities and diagnostics
ii. Automatic PID control loop-tuning package
iii. System and database configuration program
iv. DCS Report Generation package
v. DCS Trending package
vi. Alarm Management package
vii. Graphics Generation package
c. In addition to automatically updating dynamic data fields, capability to change data field status manually from the operator workstation keyboard to be provided
d. Links established in a given controller whenever one or more connections exist between that controller and any other node on the Control Network to be described
e. Any restrictions with respect to point type, quantity, frequency and scan period of the controller when accessing or providing information to other nodes using the
communication link to be highlighted in the design.
7.6.2 The tagging conventions shall follow plant philosophy. Generally the tag numbers shall identify the plant unit/area, the loop function, e.g. flow, level, etc. and a sequential numbering for that loop function in that process area.
The tagging conventions decide the following:
a. Data entry, storage, recall, etc. are accomplished utilizing tag numbers as the primary variable.
b. The loop service descriptors identifying the process and the abbreviation used shall be meaningful and shall be consistent for all the items in a loop. It is recommended to maintain a dictionary of all the abbreviations used in a plant.
c. Tagging of the calculated values, and other loop parameters such as measured value, bad value, setpoint, output etc. shall use the loop number, the loop function identifying character, e.g. „F‟ for flow and suffixes describing the derived function. Example „SP‟ for setpoint, „BADPV‟ for bad PV flag etc.
d. Tagging conversion if required between the DCS and auxiliary equipment system interfaces.
e. Message texts and string parameters from the auxiliary equipment systems configured for alarm and logging.
f. System device tagging for the diagnostic purposes
g. The DCS network drawings shall identify all the system device tags and addresses.
An example of suffixes for tagging the various loop parameters for loop 31FIC101 are as follows:
a. Raw Measurement value 31FIC101.PV.
b. Input value bad quality 31FIC101.PVQ.
c. Setpoint 31FIC101.SP.
d. Output 31FIC101.OP.
e. Auto mode 31FIC101.AUTO.
f. Manual mode 31FIC101.MAN.
g. Remote 31FIC101.RMT.
h. Local 31FIC101.LCL.
i. Compensated input 31FIC101.CMP
j. High alarm 31FIC101.PVH*
k. Low alarm 31FIC101.PVL*
* High-High, Low-Low, Rate alarms and alarms on the setpoint outputs etc. shall follow a similar standard.
The following may require further evaluation based on the DCS used:
a. Software blocks that require tagging e.g. SQ for square root extractor, HSEL for high selector, etc.
b. Array points tagging for the array and individual elements of the array
c. Scaling of numeric values to the appropriate process parameter specified
d. All array elements configuration for use in faceplate displays, alarms, trending, etc
e. Configuration of message texts and string parameters from the auxiliary equipment systems for alarm and logging.
7.6.3 The metric engineering units shall be used per plant philosophy.
a. Any abbreviation used to describe the engineering units shall be documented.
b. The scale factors used for simplifying displays, such as „K‟ for 1000 and „M‟ for million shall be consistent throughout the design.
7.6.4 The following initial tuning parameters shall be configured and fine tuned during startup.
Table-III Tuning Parameters
7.6.5 Table IV provides the alarm dead band values for various data types to be used as a guideline.
Table IV – Alarm Dead Band Values
7.6.6 As a minimum for the analog input of smart transmitter (HART), configuration the following shall be defined:
a. The capabilities of remote calibration, diagnostics, and tools to enable predictive and preventive maintenance
b. Mismatch detection between the transmitter database in DCS and the transmitter database in the field and the mismatch alarm generation
c. The transmitter parameters that are accessible from the DCS operator including but not limited to the following:
i. Upper and Lower range values
ii. Damping
iii. PV source manually entered value or auto from the transmitter
iv. PV type raw value, linearized and/or compensated, square root extracted, etc
v. Communication configuration variables
vi. Status of the transmitter
vii. Transmitter‟s serial number and software revision number
viii. Transmitter‟s scratch pad information
d. Display of these variables in the EWS and/or in OWS
e. Accessing the transmitter tagname from the console
f. The procedure for online calibration and adjustment of the transmitter‟s working range from the operator console
g. The secondary variables of the transmitter such as the meter body temperature for a pressure transmitter, or the pressure, temperature, raw measurement variables in a flow transmitter available for display, alarm, process calculations, and trending and other uses in the DCS.
h. The procedure for downloading the transmitter configuration from the console, uploading the transmitter database into the console database, setting the upper/lower range values, correcting the zero point, and setting all calibration parameters to the factory set default value from everywhere
i. Feedback messages configured to indicate that an action initiated from the console to the transmitter is completed or failed; FIELD COMMUNICATOR IN USE, and other maintenance related activities
j. The transmitter „BAD‟ or failure alarm configuration.
k. Deviation alarm configured for all process variables that are monitored by two transmitters, to monitor the difference between the two transmitter inputs. For example
one of the dual inputs may be for control and another one for indicating points in DCS or, inputs from PLC/ESD application
l. Configuration of the low cut off value for flow measurement application to display the minimum configured flow value
m. Transmitter fault handling whenever the transmitter outputs exceed its saturation limit
n. Characterization and linearization required for various signal types
o. Analog input rate of change limiting to filter out spikes
p. Thermocouple burnout and RTD open circuit detection and alarming.
7.6.7 As a minimum for the analog output point, configuration shall consider the following in the design:
a. Direct/Reverse function
b. Non linear output characterization
c. Initialization
d. Output status and value for a failure condition
e. High and low limit of output value
f. Anti reset windup (where applicable)
g. Standardization of the operator action to set „0 percent‟ for closing the valve and 100 percent for opening of a valve, irrespective of the valve action h. Split range control application configuration and operation flexibility for independent control of each valve.
7.6.8 Open contact shall cause alarm condition. Signal reversal, if required, shall be specified in the configuration.
a. Where two discrete inputs are used to define the status of a device i.e. valve open and closed position, the inputs shall be configured as two inputs with one tag number, e.g. valve tag number in DCS.
b. As a minimum, the digital input configuration shall consider the following in the design:
i. Nuisance alarm handling due to contact bouncing
ii. Enabling, disabling, and inhibition of alarm condition
iii. Momentary digital inputs, such as from push/pull-buttons, handling
iv. Up/down accumulation and count of digital input point transition for the motor RUN/STOP status inputs, and watt-hour measurement discrete input
v. Start, stop and reset command to control the count, target value for the count, and the alarm or message generated when the target value is reached.
7.6.9 The outputs shall be configured to provide closed contact for energizing a field device and open contact for de-energizing a field device. In case of certain motors, a closed contact may be required for tripping.
7.6.10 As a minimum for the pulse input configuration shall consider the following in the design:
a. The accumulated pulse counts for an elapsed time
b. The time base for totalization
c. The scale factor for the pulse value, example pulses per gallon of flow
d. Target values, start, stop, and reset features
e. Alarm and messages configured
7.6.11 As a minimum, for the sizing of the controller configuration shall consider the following in the design:
a. Processing rate limitations
b. Memory limitations, available memory, and available spare memory capacity
c. Communications limitations
d. Maximum number of I/O Cards per controller
e. Redundancy
f. Sizing guidelines for the controller module
g. Control processor sizing spreadsheet package for calculating the controller load
7.6.12 As a minimum, for the flow compensation and totalization configuration shall consider the following in the design:
a. Compensations of flow measurement for variations in temperature, absolute pressure, specific gravity or molecular weight
b. Steam flow measurement compensation for steam quality and compressibility
c. Boiler feed water flow measurement compensation for density and temperature.
d. The quality check on each of the measured values used in the flow compensation and the subsequent action, alarm and display configured
e. The procedure for manual entry of lab measured values of analytical parameters
f. Totalization showing the time scaled accumulation of a flow measurement
g. Totalization of a pulse input or transmitter input or sub-system input and the time scale in seconds, minutes, hours, or days
h. Operator action configured to START, STOP, AND RESET the totalized value from the console
i. The pre alarm and final alarm values configured for the totalized value when target values are reached
j. Value of flow cut-off limit to prevent accumulation of negative flow values
k. Bad quality input detection and return to normal sequence.
l. Event logging of the automatic STOP and START and operator initiated START, STOP and RESET commands.
7.6.13 For equipment such as valves, MOV, pumps, etc. the status inputs, the permissive, and the output commands shall be configured to form a single tag for display and operation. Configuration shall consider the following in the design:
a. The device control point‟s permissive and overrides to issue OPEN/CLOSE/START/STOP commands where required, for example, the LOCAL/REMOTE switch input for a MOV shall be used as a permissive for OPEN/CLOSE/STOP commands.
b. Mismatch alarms when the command and the status feed back are conflicting
c. Time specified, set equal to the valve travel time, to inhibit the mismatch alarm during the valve travel
d. Failure, and initialization status for each of the I/O.
7.6.14 The following paragraphs describe general motor control philosophy. The P&IDs, cause and effect diagrams, and the logic diagrams will describe the final requirement for each motor control. The philosophy and configuration used for each shall consider the following in the design.
a. Motor Control loops are defined as loops containing the I/O and operator access options related to the starting and/or stopping of rotating machinery. There are several different implementations of the motor interface, which have all been classified as motor control functions.
b. In general, hand-switch tags will be suffixed with the hand-switch function, i.e., „S‟ for stop, „R‟ for run, „O‟ for open, „C‟ for close
c. Fans configuration to include DCS start and stop feature
d. Motors to be provided with an alarm for the trip condition only. The state change shall be logged.
e. The order of precedence for pump/motor controls is as follows:
i. Emergencency push button stop contact
ii. ESD/BMS or other logic controls
iii. Field controls
iv. DCS controls
7.7 General Guidelines for Report Generation
7.7.1 Scheduled Reports
All fixed-content or fixed-format reports shall be configured as scheduled reports. These reports are typically scheduled to run at predetermined time intervals, but may be run on demand. For example, the plant „sulfur‟ and „foreman‟ reports will contain fixed, daily average information and are scheduled to run once each day.
Scheduled reports shall be built and configured to print. Configuration is divided into two parts:
a. Configuring overall parameters relating to the report
b. Configuring individual data fields in the report
The following parameters for the reports shall be configured:
a. Report Name. Report name shall reflect the plant name and the report type.
b. Report Type. The report type determines the basic time frame covered by the report. It shall be assigned as part of detail design to match the report requirements. Reports scheduled to run once each day shall be a type „daily‟. Reports normally run on-demand shall be type „hourly‟. The combination of report type and data field type, matched with the historization module‟s time stamp on the data, determines the time stamp associated with each data field appearing in the report.
c. Start Hour. The start hour of the report shall be configured to determine the time stamp associated with each data field.
d. Start Day-of-Week. The start day-of-week shall be set to Saturday.
e. Shifts/Day. The number of shifts/day shall be set to 3.
f. Data Source.
g. Comment Field. Each page shall contain 3 blank lines at the bottom for operator‟s manual comments on upset condition primarily used in shift report.
For the data field configuration the following parameters shall be configured:
a. Tag Number.
b. Function. A list of math operations to be performed on the data e.g., average, total, minimum, maximum, etc., or else selected as a simple listing of the data value(s).
c. Engineering Units.
d. Format. The numerical formatting is assigned as part of the detailed design.
Report Writer Scheduling
a. Daily reports shall be normally scheduled for automatic printing. Provision to both schedule and demand each of these reports from a single display shall be available.
b. Daily reports shall be scheduled to be run after 01:00:00 for the previous day’s data.
7.7.2 Process Log Reports
Process logs present a record of data with the following four values for each point:
a. Current value
b. Hour average
c. Shift average
d. Day average
Where, the start time for the averages shall be the beginning of the previous present hour, shift, and day and the end time shall be the current time. For example, if the report request time is 11:45, then, the hour average shall be based on the last hour average starting from 10:00, the shift average shall be based on the last shift average, e.g. the shift started at midnight, and the day average shall be based on the last day, e.g. yesterday.
In addition process log reports shall include:
a. Tag name.
b. Tag description.
c. Engineering units.
d. Report Title.
e. Report request time and date.
It shall be possible to enter up to 48 tags per page. The list of points once entered shall be saved for future use and modification.
7.7.3 Miscellaneous Reports
Following type of reports shall be configured with calculations on the data gathered:
a. Daily Material Balance log for the whole plant.
b. Daily Energy Balance for the whole plant.
c. Efficiency reports for major rotating equipment, furnaces, and exchangers.
8. Alarm Philosophy
Process and System alarms shall include both audible and visual annunciation.
8.1 Process Alarm Notification and Response
8.1.1 An alarm activates:
a. a blinking LED on the dedicated alarm key of the operator keyboard
b. a blinking LED on the appropriate key assigned to call up the process graphic that contains the tag in alarm
c. simultaneously sounds a horn
d. causes the „alarm‟ menu icon at the top of screen to blink
8.1.2 If the alarm is a fire or gas alarm, a blinking message shall also appear on all process displays on all the consoles indicating that a „FIRE‟ or Gas alarm „in XYZ AREA IS ACTIVE‟.
8.1.3 Fire and Gas alarms shall activate a separate horn and light at the console‟s ESD/auxiliary panel and simultaneously activate a common strobe light in the Central Control Room.
8.1.4 One of the consoles shall have logic built-in to provide a dedicated contact for any „FIRE‟ alarm in the plant. Similar arrangement shall be provided for the „H2S‟ and „LEL‟ alarm.
These contacts shall be wired for the external horn and the strobe light specified.
8.1.5 The operator shall be able to silence the annunciator keyboard horn via a console annunciator keyboard „HORN SILENCE‟ button.
8.1.6 The operator shall be able to acknowledge the alarm by pressing the appropriate key assigned to call up the process graphic that contains the tag in alarm and that is associated with a blinking LED and to simultaneously silence the annunciator keyboard horn if still active.
8.1.7 Existing alarm conditions shall be shown on the process display via color change and blinking action.
8.2 Process Alarm/Event Priority Assignments
8.2.1 Process alarms and status changes are assigned a priority value for each type of alarm/event within a given tag, during configuration.
8.2.2 The priority assignment shall be configurable. Minimum four priority levels shall be available with system.
8.2.3 Priority assignments shall be used by the Alarm Display as part of its sort function.
8.2.4 Priority assignments shall provide a means to suppress groups of alarms on a priority basis.
8.2.5 Each priority shall be matched with a corresponding color for each of:
a. Alarm Display
b. Alarm History Display
c. Process Displays
d. Process Overlays (Control and Indication)
e. Tag Detail Displays
f. Group Displays
8.2.6 Table V shows the priority assignments for the various alarm types, notification and colors associated with each of the priorities. Alarm color shall be based on site preference.
Table V – Alarm Priority Assignments
8.3 Process Alarm / Event Descriptors
8.3.1 Process alarm/event descriptors shall be defined as part of the tag configuration task.
8.3.2 These descriptors, along with appropriate tag descriptors, shall appear as part of alarm messages sent to Alarm Displays and Alarm History Displays. They shall also appear automatically within standard Tag Detail displays.
8.4 Process Alarm / Event Destinations
8.4.1 Providing the alarm has been enabled and a priority has been assigned, it shall not be necessary to configure destination groups to simply view an alarm condition from standard displays and custom displays. In order to direct an alarm to a particular device for the purposes of notification or historizing, the destination device shall be configured.
8.4.2 Process alarms shall be directed to Operator Workstation to:
a. Enable notification at the „alarm‟ menu pick and message recording at the Alarm Display
b. Allow for the sounding of horns
c. Allow assignment of alarms to process graphic call up assignable keys LEDs
8.4.3 Alarms and status changes shall also be for historical record keeping.
8.4.4 If an alarm appears on more than one display, it shall be possible to acknowledge the alarm from any of the selected displays.
8.5 Alarm Annunciation Visual Action
8.5.1 Table VI shows the action and color convention that shall be followed for an LED in a keyboard and alarm menu pick box when a tag in the assigned display goes into an alarm sequence.
Table VI – Visual Notification Example
8.6 Horns
8.6.1 A system horn shall sound at each annunciator and keyboard at an operating console when an alarm is received at that console.
8.6.2 All console horns shall be silenced via any „HORN SILENCE‟ key in the operator keyboard.
8.6.3 Consoles shall be provided with a minimum of two horn tones for process alarms.
8.6.4 Volume level setting shall be adjustable on each console.
8.6.5 Fire and gas alarms shall additionally sound an external horn mounted in the ESD/auxiliary panel associated with the train/unit/area.
8.6.6 System alarms shall sound a different horn tone.
8.7 Alarm Display
8.7.1 The Alarm Display is a list of all unacknowledged plus all active acknowledged alarms received by the Operator console.
8.7.2 The display shall be priority-sorted, multi-page listing of up to 100 alarm and return-tonormal messages.
8.7.3 Messages shall be updated continuously, such that new information specific to one alarm overwrites old information or otherwise causes the superseded information to be removed from the listing.
8.7.4 Message information shall include alarm identification, general description, date, and time of alarm, acknowledge status, trip values, and priority identification via color.
8.7.5 If the alarm display file reaches the 100-alarm limit, then the oldest message shall be overwritten. This shall not affect the alarm history display, nor shall it affect custom displays or standard faceplate displays.
8.7.6 The „ALARM‟ menu pick shall give access to alarm display for the calling console only.
8.8 Alarm Display Target Boxes
8.8.1 Within the alarm display a set of softkey target boxes shall occupy the bottom edge of the screen. These shall give access to a variety of functions, including:
a. Individual acknowledgment for a selected alarm
b. A page acknowledge function
c. A „CLEAR‟ alarm function, to remove a selected alarm from the listing.
d. For a selected alarm, the display shall forward to a pre-configured display, such as process graphics, group view or the tag detail of the associated tag
e. User display call up for a selected alarm, based on the given OWS keyboard configuration
f. Alarm history display call-up.
8.8.2 Screen navigation options e.g., „PREV DISP‟, „1ST PAGE‟, „PREV PAGE‟ and „NEXT PAGE‟ soft keys.
8.9 Alarm Display Configuration
8.9.1 Configuration of the alarm display shall include the following:
a. Sorting order shall provide a sorted listing first by active state, then by unacknowledged state, then by priority, and finally by time.
b. Return-to-Normal (or disabled) Action. Unacknowledged alarms which have since returned to normal shall remain in the alarm display listing, and any corresponding annunciator keyboard LEDs, if any, shall remain activated i.e. blinking until such time as the alarm is acknowledged.
c. Alarm „CLEAR‟ Action. The default action shall be used; the alarm is cleared from the alarm display on the related OWS only. As an example, if a transmitter signal goes „BAD‟, the „BAD‟ alarm shall remain on the alarm display until either transmitter is fixed or the alarm is cleared from the display.
8.10 Alarm History Display
8.10.1 The alarm history display shall provide a historical listing of all alarms, time of acknowledgment, and return-to-normal messages, based on a circular queue of the Alarm History record.
8.10.2 Messaging shall be similar to that for the alarm display
8.10.3 The Alarm History may contain multiple records for a given tag.
8.10.4 It shall be possible to access the alarm history display via a soft-key target box on the alarm display or from the pull-down main menuor from the dedicated key on the operator keyboard.
8.10.5 The specific alarm history display called up shall be that associated with the history files for the given operator console. It shall be possible to save the alarm history file for future use.
8.10.6 Alarm History Display Target boxes
Within the alarm history display, a set of soft-key pick-boxes shall occupy the bottom edge of the screen. These keys shall give access to a variety of functions, including:
a. Tag detail display callup for a selected alarm
b. Process graphic display and group display callup for the top priority alarm, based on the given Workstation
c. Alarm Display callup
d. Screen navigation options e.g., „PREV DISP‟, „1ST PAGE‟, „PREV PAGE‟ and „NEXT PAGE‟ soft keys
8.10.7 Alarm History Display Configuration
Message display format and alarm priority color coding shall follow the alarm display configuration for these items.
8.11 Standard Displays Alarming
8.11.1 This Section deals with alarm handling via tag detail displays, group displays, and faceplates.
8.11.2 Each of these display types shall provide for the identification of alarm conditions within a standard representation.
8.11.3 An „alarm status‟ field in the faceplate shall indicate by text and color change the status of the highest priority alarm within that block. If no alarm currently is active or no unacknowledged previous alarm condition exists, then this field shall be left blank.
8.11.4 Additional alarm information is available within tag detail displays, including display of the associated alarm descriptors configured at the block.
8.12 Process Display Alarm Handling
8.12.1 The common alarm shall appear on a process operating display to indicate that one or more alarm exists at the corresponding machine/equipment-level display. For example, a common vibration alarm may appear on the primary operating display, while individual vibration alarms, any one of which would activate the common alarm, may appear on the equipment-level display.
8.13 Alarm Suppression
8.13.1 Alarm suppression/inhibiting involves suppressing alarm notification at the alarm display, „alarm‟ menu target and historizing at the Alarm History.
8.13.2 Suppressing safety alarms shall be only done via engineering access level.
8.13.3 Alarms for equipment, such as pumps and compressors, which are out of service shall be neither displayed nor printed. Equipment status log shall identify machinery, which is out of service.
8.14 Process Alarm Summary Reports
8.14.1 Process Summary Reports shall provide selectable printout or output to file of current process alarm conditions.
8.14.2 Reports shall identify information pertaining to one or more selected workstations on the network.
8.14.3 Reporting options shall include as a minimum:
a. Tags off scan, in alarm, or with alarms inhibited,
b. Software blocks off scan, in alarm, with alarms inhibited, not on control, in manual, or with „BAD‟ I/O
8.15 System Alarms
8.15.1 System alarms indicate component hardware, associated peripherals, and network communications failures. VENDOR shall supply standard System Management software and it shall be used to the fullest extent.
8.15.2 „System‟ Menu Target box
a. The „System‟ menu icon shall blink red to indicate an unacknowledged system alarm condition.
b. The „System‟ menu icon shall change to steady red to indicate an acknowledged system alarm condition.
c. The „System‟ menu icon shall appear as steady green to indicate that there are no active alarms and all previous alarms have been acknowledged.
8.15.3 System Alarm Configuration
a. System alarms shall be configured to include the status alarms generated by DCS and the auxiliary equipment system interfaced with the DCS.
b. Each console shall be assigned to receive system-related alarm messages for that console.
c. Each console shall historize all system alarms.
d. One EWS on each of the system engineering console shall be directed to receive all system alarms.
8.16 Sequence of Events Recording
8.16.1 SOE data collection and time stamping shall be executed in the ESD/BMS of respective process area. The DCS interface shall gather all the SOE data and shall store in the historian. Necessary software to execute the above shall be provided by the DCS vendor.
8.16.2 SOE data collection shall be time synchronized as per SES-X01-E01. The data shall be grouped based on the shutdown logic schemes. This may require same tags appearing in multiple reports.
8.16.3 SOE data collection shall include the following:
a. Time and date stamp
b. Point identifier e.g. point tag
c. Contact state, fixed as either „ALARM‟ or „RETURN/NORMAL‟
d. Point descriptor
8.17 Trip Reports
8.17.1 This application shall be configured to collate alarms, messages, and historical data into a single report. The report shall be configured for initiation by a predefined event.
8.17.2 Reports shall be organized by month, unit ID, and date/time.
8.17.3 It shall be possible to view the trip reports from any console.