23-SAMSS-010

Materials System Specification 23-SAMSS-010 Distributed Control Systems

28 February 2005

Process Control Standards Committee Members Qaffas, Saleh A., Chairman Assiry, Nasser Y., Vice Chairman Awami, Luay H. BenDuheash, Adel O. Busbait, Abdulaziz M. Dunn, Alan R. ElBaradie, Mostafa M. Esplin, Douglas S. Fadley, Gary L. Genta, Pablo D. Ghamdi, Ahmed S. Green, Charlie M. Hazelwood, William P. Hubail, Hussain M. Jansen, Kevin P. Khalifa, Ali H. Khan, Mashkoor A. Mubarak, Ahmed M. ShaikhNasir, Mohammed A. Trembley, Robert J.

Saudi Aramco DeskTop Standards Table of Contents

1 2 3 4 5 6 7 8 9 10 11

Scope.................. Scope............................... ........................... ........................... ................ ... 2 Conflicts and Deviations................ Deviations...... ..................... ................. ...... 2 References......... References....................... ............................ .......................... ................ .... 3 Definitions.......... Definitions........................ ............................ .......................... ................ .... 4 Environmental Conditions.............. Conditions..... ..................... ................ .... 9 General.............. General............................ ............................ .......................... ............... ... 11 Electrical Requirements.............. Requirements.... ...................... ................. ..... 15 Cabinets and Consoles................. Consoles...... ...................... ............... .... 18 Inputs and Outputs................. Outputs...... ..................... ...................... ............ 21 Workstations........ Workstations....................... ............................. .......................... ............ 25 Control Network and Internal Communications.............................. 28 12 Foundation Fieldbus ™ (FF) Host Requirements....................................... 28 Table of Contents (cont'd)

Previous Issue: 31 October 1999 Next Planned Update: 1 March 2010 Revised paragraphs are indicated in the right margin Primary contact: John A. Kinsley on 873-0952

Page 1 of 1

Document Responsibility: Process Control Issue Date: 28 February 2005 Next Planned Update: 1 March 2010

23-SAMSS-010 Distributed Control Systems

13 14 15 16 17 18 19 20 21 22 23 24

1

2

3

Control and Data Handling................ Handling..... ..................... ............ 32 Configuration and Database................. Database...... ................... ........ 40 Security............. Security............................ ............................ .......................... ................ ... 43 Diagnostics......... Diagnostics....................... ............................ .......................... .............. .. 46 Displays and Graphics.................. Graphics....... ...................... ............... .... 47 Alarm and Message Handling................. Handling...... ................ ..... 51 Data Historization............ Historization.. ..................... ...................... .................. ....... 57 Trend Displays................ Displays...... ..................... ...................... ................... ........ 58 Reports............... Reports............................. ........................... ......................... ............... ... 61 External Interface............... Interface.... ..................... ...................... ................ .... 61 Inspection and Testing.................. Testing........ ..................... ............... .... 65 Documentation............ Documentation.. ..................... ....................... ...................... .......... 65

Scope 1.1

This specification along with the requirements specified in SAES-Z-001 defines the minimum mandatory design, fabrication and testing requirements for a Distributed Control Systems (DCS).

1.2

This specification applies to all DCS equipment and associated software required to monitor and control a process plant.

1.3

Where a project Functional Specification Document (FSD) calls for more than one distributed control system, this specification shall apply to each DCS system individually.

1.4

Additional requirements might be included in Company's FSD, in which case the more stringent requirements shall be met.

Conflicts and Deviations 2.1

Any conflicts between this specification and other applicable Saudi Aramco Materials Systems Specifications (SAMSSs), engineering standards (SAESs), standard drawings (SASDs), or industry standards, codes, and forms shall be resolved in writing by the Company or Buyer Representative through the Manager, Process & Controls Systems Department, Saudi Aramco, Dhahran.

2.2

Direct all requests to deviate from this specification in writing to the Company or Buyer Representative, who shall follow internal Company Engineering Procedure SAEP-302 and forward such requests to the Manager, Process & Control Systems Department, Saudi Aramco, Dhahran.

References Specific sections of the following documents are referenced within the body of the document. Material or equipment supplied to this specification, shall comply with the

Page 2 of 67



referenced sections of the latest edition of these specifications. Where specific sections are not referenced, the system shall comply with the entire referenced document. 3.1

Saudi Aramco Documents

Saudi Aramco Materials System Specifications 34-SAMSS-820

Instrument Control Cabinets – Indoor

34-SAMSS-821

Instrument Control Cabinets - Outdoor

Saudi Aramco Engineering Standards SAES-Z-001

Process Control Systems

SAES-Z-010

Process Automation Networks Connectivity

SAES-J-904

FOUNDATION ™ Fieldbus (FF) Systems

Saudi Aramco Engineering Reports SAER-5895

Alarm Management Guideline for Process Automation Systems

Saudi Aramco Engineering Procedures SAEP-302

Instructions for Obtaining a Waiver of a Mandatory Saudi Aramco Engineering Requirement

SAEP-334

Retrieval, Certification, and Submittal of Saudi Aramco Engineering and Vendor Drawings

Saudi Aramco Inspection Requirement Form 175-230100

Distributed Control Systems (DCS)

Saudi Aramco Form and Data Sheet Form NMR-7923 3.2

Nonmaterial Requirements for Control Cabinets

Industry Codes and Standards

American Society for Testing and Materials ASTM E1137

Standard Specification for Industrial Platinum Resistance Thermometers

International Electrotechnical Commission

IEC 60751

IEC 61000-6-2

Industrial Platinum Resistance Thermometer Sensors Generic standards – Immunity for Industrial Environments

Page 3 of 67


IEC 61000-4-3


Testing and measurement techniques – Radiated, Radio Frequency, Electromagnetic Field Immunity Tests

IEC 61131-3

Programmable Controllers - Programming Languages

IEC 61158

Fieldbus for Use in Industrial Control Systems

International Society for Measurement and Control ISA 50.02, Part 2

Fieldbus Standard for Use in Industrial Control Systems, Part 2: Physical Layer Specification and Service Definition

National Fire Protection Association

NFPA 255

Surface Burning Characteristics of Building Materials

Telecommunications Industries Association TIA 232-F

Interface Between Data Circuit - Terminating Equipment Employing Serial Binary Data Interchange

TIA/EIA 422-B

Electrical Characteristics of Balanced Voltage Digital Interface Circuits

TIA 485-A

Electrical Characteristics of Generators and Receivers for Use in Balanced Digital Multi-point Systems

Other Industry References Bellcore TR-332

4

Reliability Prediction Procedure for Electronic Equipment - Telcordia Technologies

Definitions This section contains definitions for acronyms, abbreviations, words, and terms as they are used in this document. For definitions not listed, the latest issue of the "Comprehensive Dictionary of Measurement and Control", International Society for Measurement and Control, shall apply. 4.1

Acronyms and Abbreviations

BMS

Burner Management System

CCS

Compressor Control System

COTS

Commercial Off-The-Shelf

DCS

Distributed Control System Page 4 of 67


4.2


DD

Device Descriptor

EEPROM

Electrically Erasable and Programmable Read-Only Memory

EIA

Electronic Industries Association

ESD

Emergency Shutdown

ETP

External Termination Panel

FAT

Factory Acceptance Test

FSD

Functional Specification Document

FTA

Field Termination Assembly

FF

FOUNDATION ™ Fieldbus

I/O

Input/Output

ISA

The International Society for Measurement & Control

MBPS

Mega Bits Per Second

MOV

Motor Operated Valve

MTBF

Mean Time Between Failures

OPC

OLE for Process Control (OLE – Object Linking and Embedding)

PC

Personal Computer

SCADA

Supervisory Control and Data Acquisition

VMS

Vibration Monitoring System

Words and Terms Application Software: The software written specifically to perform functional requirements for an individual plant when standard software packages cannot be configured to meet the requirements. Application software works with the standard operating software, it does not modify any standard software. Auxiliary System: A control and/or monitoring system that is stand-alone, performs a specialized task, and communicates with the DCS. Availability: The capability of a system to perform its designated function when required. Call Up Time: The time between when the operator initially enters a display request and when all objects, lines, values (good or invalid), trends and other parts of the display have been fully presented to the operator. Communications Subsystem: The hardware and software that performs the transmitting and receiving of digital information.

Page 5 of 67



Configurable: The capability to select and connect standard hardware modules to create a system; or the capability to change functionality or sizing of software functions by changing parameters without having to modify or regenerate software. Configuration: The physical installation of hardware modules to satisfy system requirements; or the selection of software options to satisfy system requirements. Console: A collection of one or more workstations and associated equipment such as printers and communications devices used by an individual to interact with the DCS and perform other functions. Control Network: The physical communications equipment which provides the communications path between the operator and engineering workstations to the controllers and communications interface modules. The I/O bus from the controllers to the I/O modules is considered separate from the control network. Dead Band: The range through which an input signal may be varied without initiating an action or observable change in output signal. Discrete Control: Control where inputs, algorithms, and, outputs are based on logical (yes or no) values. Distributed Control System: A process control system that is composed of distinct modules. These modules may be physically and functionally distributed over the plant area. The distributed control system contains all the modules and associated software required to accomplish the regulatory control and monitoring of a process plant, excluding field instruments, remote terminal units, auxiliary systems and management information systems. Faceplate: A graphic element that mimics the front panel of an analog or discrete controller instrument, hardwired push-button or switch. Factory Acceptance Test (FAT): The final test at the vendor's facility of the integrated system being purchased. This test is usually witnessed by Saudi Aramco personnel. Fault-Tolerant System: A system incorporating design features which enable the system to detect, discriminate, and log transient or steady-state error or fault conditions and take appropriate corrective action while remaining on-line and performing its intended function. Fieldbus Foundation (FF) (ISA 50.02) Definition: As per ISA SP50.02 the Fieldbus is defined as that communications protocol meeting all requirements specified in the IEC 61158 standard. Field Proven: A system shall be considered to be field proven when it has been installed, commissioned, and operational in a customer facility for a period of

Page 6 of 67



six months or longer (excluding beta test periods). It shall be possible for Saudi Aramco to verify the field proven status of any equipment. Firmware: Programs or instructions that are permanently stored in hardware memory devices and not normally lost upon electrical power failure (usually EEPROM or Read-Only Memory, "ROM"). HART Protocol: A digital protocol which is superimposed on a standard 420mA signal which enables communication of process data and instrument diagnostic and configuration data from HART compatible field devices. HART refers to "Highway Addressable Remote Transducer", originated by Rosemount. Invalid Value: The state of a tag value, which indicates that the quantity being measured or calculated is out-of-range, not measurable or not calculable. Marshalling Cabinet: A cabinet which contains mainly terminal strips and wire terminations but may also contain DCS I/O module Field Termination Assemblies. Signal cables for field instruments are normally terminated inside marshalling cabinets. Mean Time Between Failure: (MTBF) Is a statistical value equal to the mean or average time expected between failures of a given device which is used in the determination of system reliability. MTBF figures can be "predicted" or "observed". Observed MTBF for a given component is calculated using actual failure rate data collected for the population of the component while in-service. Predicted MTBF is a figure which is calculated based failure rate models of individual sub-components of the component. Two methods widely accepted for calculation of predicted MTBF are; MIL-HDBK-217 and Bellcore TR-332. Mode: Control block operational condition, such as manual, automatic, or cascade. Module: An assembly of interconnected components that constitutes an identifiable device, instrument, or piece of equipment. A module can be disconnected, removed as a unit, and replaced with a spare. It has definable performance characteristics that permit it to be tested as a unit. Operational Data: The statistical data such as alarm limits, tuning parameters, and clamping values, as opposed to process data such as input values, output values, and setpoints. Operator Console: A console used by an operator to perform the functions required to monitor and control his assigned units. Plant Area: The designated points (inputs, outputs, and calculated values) that belong to a geographic or functional section of a plant. Point: A process variable derived from an input or calculated in a process calculation.

Page 7 of 67



Redundant Configuration: A system/subsystem configuration that provides automatic switchover, in the event of a failure, without loss of a system function. Regulatory Control: The functions of process measurement, control algorithm execution, and final control element manipulation that provide closed loop control of a plant process. Reliability: The capability of a system or component to perform its intended function for a specified period of time. Self-Diagnostic: The capability of an electronic device to monitor its own status and indicate faults that occur within the device. Supervisory Control: Higher level control functions that interface with regulatory controllers and other DCS equipment to provide for integrated control. Supervisory Control and Data Acquisition (SCADA): A system primarily intended for data acquisition and limited remote control over a wide geographically distributed area. System Access: Access to components of a system used to perform configuration and system diagnostics. Access to these components is typically through program such as configurators and systems diagnostics displays. System Alarm: Alarm which occurs as a result of a DCS hardware or software fault. System Operating Software: The vendor's standard software that performs the basic functions of the system. System Cabinet: Any cabinet which is supplied as part of the PCS which is not classified as a marshalling cabinet. Tag: A collection of attributes that specify either a control loop or a process variable, or a measured input, or a calculated value, or some combination of these, and all associated control and output algorithms. Each tag is unique. Tag ID: The unique alphanumeric code assigned to inputs, outputs, equipment items, and control blocks. The tag ID might include the plant area identifier. Workstation: A set of electronic equipment including a minimum of one monitor, keyboard(s) and associated pointing device(s).

5

Environmental Conditions 5.1

Air-conditioned Buildings

Equipment installed in air-conditioned buildings shall be designed for: a)

Ambient temperature range:

10°C to 35°C

b)

Ambient relative humidity:

20% to 80%.

(1)

Page 8 of 67



Note: 1)

5.2

For equipment which dissipates internal heat and is installed in custom engineered enclosures (e.g., enclosures not included in the original manufacturer's temperature certification), an additional 15°C shall be added to the above maximum temperatures. An example, for "indoor air conditioned" installation, the equipment must perform at 35 + 15 = 50°C.

Outdoor Environment

5.2.1

All equipment specified for outdoor installation shall be designed to meet the following outdoor environmental conditions: a)

Ambient temperature range:

b)

•

Outdoor Sheltered

= 0 °C to 55 °C

(1)(2)

•

Outdoor Unsheltered = 0 °C to 65 °C

(2)(3)

Ambient relative humidity: 5% to 95% non-condensing.

Notes:

5.2.2

1)

"Sheltered" refers to permanent, ventilated enclosures or buildings, or permanently fixed sunshades with a top and three sides.

2)

For equipment which dissipates internal heat and is installed in custom engineered enclosures (e.g., enclosures not included in the original manufacturer's temperature certification), an additional 15°C shall be added to the above maximum temperatures. An example, for the "outdoor unsheltered" case, the equipment shall be designed for a maximum operating temperature of 65 + 15 = 80°C.

3)

For the outdoor installations only, the designer can take credit for forced or passive cooling to eliminate or reduce the 15°C heat rise. For example, if vortex coolers are used, the heat removal capacity of the coolers may be subtracted from the generated heat. No more than 15°C reduction in temperature will be given as credit. The designer shall substantiate his claim by providing the support data and calculations.

All equipment specified for outdoor installation shall be compliant with the following contaminant levels: 5.2.2.1

Dust Concentration: Usual airborne dust concentration is 1 mg/m³. During sandstorms, dust concentrations may reach 500 mg/m³. Particle sizes are as follows: •

95% of all particles are less than 20 micrometers.

•

50% of all particles are less than 1.5 micrometers.

5.2.2.2

Elements present in dust include compounds of calcium, silicon, magnesium, aluminum, potassium, chlorides and sodium. When wetted (high humidity conditions) these compounds function as electrolytes and can result in severe corrosion.

5.2.2.3

Other pollutants present in the atmosphere under the most extreme conditions are: •

H2S

20 ppm (vol/vol)

Page 9 of 67


5.2.3


•

Hydrocarbon 150 ppm (vol/vol)

•

SO2

10 ppm (vol/vol)

•

CO

100 ppm (vol/vol)

•

NOx

5 ppm (vol/vol)

•

O3

1 ppm (vol/vol)

Equipment which is not enclosed or hermetically sealed, but is situated outdoors offshore or outdoors near-shore shall be protected against corrosion and operational failure due to wind-borne sea water spray and the accumulation of wetted salt (sodium chloride). Near-shore is defined as within one kilometer from the shoreline of the Arabian Gulf, all of the Ras Tanura refinery and terminal, and within three kilometers from the shoreline of the Red Sea.

5.3

Storage Environment

It shall be possible to store the equipment in moisture proof containers for up to 6 months under the following conditions:

6

a)

Temperature: 0 to 55°C.

b)

Relative humidity (outside the moisture proof container): 10 to 90%.

General 6.1

6.2

Use of Standard Products

6.1.1

The system shall be composed of manufacturer's standard hardware, systems software, and firmware that can be configured to meet the stated requirements.

6.1.2

A vendor's standard system operating software shall not be modified to meet any of Saudi Aramco's requirements.

6.1.3

Application software shall be designed in a manner that requires no modification to the system operating software.

Revision Level

6.2.1

All controller and I/O subsystem hardware and other vendor proprietary hardware shall be the latest "field proven" revision level at the time of the hardware freeze date as defined in the contract purchase order or the Preliminary Design Review (PDR); whichever is later. It shall be possible for Saudi Aramco to verify the field proven status of the system. Commentary Note:

Page 10 of 67



It is acceptable for a system to contain different revision levels of a hardware component so long as the revision level of the component represents a minor revision. In such cases, the vendor must demonstrate that the two components will work together and remain physically interchangeable as a redundant pair, if redundancy is required on the system, and that the functionality of the module is not affected by the revision of the module.

6.2.2

All vendor proprietary software, exclusive of application software, shall be the most recent, commercially released, software revision level that is applicable to the system hardware revision level at the later of the Critical Design Review (CDR) or the hardware freeze date as defined in the contract or purchase order. Commentary Note: The exclusion of application software is not intended to provide an exclusion for software written to perform either system functions or standard functions which apply to many tags. Software of this type still requires a waiver to ensure that alternatives have been properly evaluated and that appropriate safeguards are put in place.

6.2.3

6.3

6.4

All personal computers, monitors, printers, peripherals, Ethernet switches and other commercial of-the-shelf (COTS) equipment provided by the vendor as part of the system shall be the latest model commercially available which has been tested and approved for compatibility by the vendor at the time of the Critical Design Review (CDR) or the hardware freeze date as defined in the contract or purchase order, whichever is the later.

Software Revision

6.3.1

The system shall allow for upgrading of system operating software on all redundant modules of the system without requiring a shutdown of any process equipment, without loss of the operator's view to the process, and without the loss of access to any control function.

6.3.2

Application software shall not require modifications in order to be able to run under new releases of the system operating software. It is acceptable if a translator is provided by the vendor.

System Support

6.4.1

DCS vendor shall guarantee support of all hardware, firmware, and software associated with the controller and I/O subsystems and any proprietary communications equipment for a period of ten (10) years from the hardware freeze date. Support shall include spare parts and technical support. This support shall not be contingent on the customer upgrading to later releases of software or hardware.

Page 11 of 67


6.4.2


DCS vendor shall provide support for all Commercial Off-The-Shelf (COTS) products supplied as part of the DCS for a period of five (5) years. Commentary Note: It is not the intent of Saudi Aramco to require DCS vendors to service commercially available products which they did not manufacture. The vendor shall, however, guarantee that COTS equipment supplied with the system can be replaced with a similar component for the period specified without loss of functionality to the system and without requiring software upgrades to later releases of the DCS operating system software.

6.4.3 6.5

Withdrawal of product support for DCS vendor manufactured products shall be notified in writing to Saudi Aramco twelve months in advance.

Redundant Configuration

6.5.1

The following equipment shall be supplied in redundant configuration unless specified otherwise in the project FSD: a)

All Controllers.

b)

All Power supply modules.

c)

All DCS control network equipment.

d)

All communications equipment required for communications between controllers and I/O modules.

e)

All Input and Output modules used for critical regulatory control.

f)

All Foundation Fieldbus Host interface modules.

g)

All Foundation Fieldbus power supply and conditioning modules.

h)

All data storage devices (e.g. hard-drives) used to store system configuration information or control strategy configuration information.

i)

All auxiliary systems communications interface modules, including communications paths, where either the communications channel is used to send commands from the DCS to the auxiliary system or data from the auxiliary system is used within a regulatory control strategy within the DCS.

Commentary Notes: Regulatory control refers to control which is implemented at the DCS layer. This can be either analog (e.g., 4-20mA to control valves) or discrete (e.g., 24vDc to Motor starters). Critical regulatory control refers to control of equipment which does not have an installed spare or backup or where failure of the equipment would result in a significant loss of production or an unsafe operating condition. Inputs and

Page 12 of 67



Outputs used for regulatory control in critical applications shall be supplied with redundant I/O modules. Requirements for redundant inputs and outputs will be specified in the project FSD. Requirements for redundancy can be satisfied by using either redundant or fault tolerant configurations.

6.5.2

6.6

The following requirements apply to those parts of the system supplied in a redundant or fault-tolerant configuration: 6.5.2.1

The system shall continuously monitor and test all backup equipment to determine whether the backup equipment is capable of assuming control.

6.5.2.2

Failure of backup equipment shall be alarmed as a system alarm.

6.5.2.3

Automatic switchover to backup equipment shall occur on detection of failure of the primary equipment.

6.5.2.4

Switchover shall not degrade the performance or functionality of the module or result in the operator's loss of view to the process.

6.5.2.5

Switchover of controllers shall not cause initialization of any control strategies implemented in the controllers.

6.5.2.6

Replacement of any redundant module shall not disturb or interfere with the performance of the operating module in the redundant pair.

6.5.2.7

Switch back to repaired equipment shall be permitted only after the system diagnostics function has determined that the module is fully functional.

6.5.2.8

Automatic and manual switchover shall be displayed, logged, and alarmed by the system.

6.5.2.9

Switchover from a failed module to the backup shall occur and the backup shall be fully functional within the timeframes specified below: •

Redundant I/O modules:

½ second

•

Redundant Controller:

1 second

Availability

6.6.1

A single failure anywhere in the system shall not result in the loss of regulatory control.

Page 13 of 67


6.6.2


A single failure anywhere in the system shall not result in loss of an operator's ability to view or manipulate the process from his workstation. Commentary Note: The two requirements above do not apply to a single failure of a non- redundant input or output module. A loss of a single, non-redundant input or output module will result in loss of control and loss of the operator's view to the process for only those points associated with the single I/O module.

6.7

Reliability

Equipment supplied as part of the DCS system shall meet or exceed the MTBF data specified in the table below at the equipment's design temperature. MTBF figures shall be "Predicted" data calculated using the Bellcore Reliability Prediction Procedure. Process controllers and input/output modules

300,000 hours

Power Supply modules

200,000 hours

Commercial off-the-shelf networking or communications equipment

100,000 hours

All other electronic modules and power supply modules.

100,000 hours

Commentary Note: Requirements for MTBF do not apply to workstations and peripheral devices (such as monitors, keyboards, printers, etc.). Requirements for MTBF apply to all other components supplied by the vendor as part of the system whether they be vendor proprietary or COTS equipment.

7

Electrical Requirements 7.1

Electrical Area Classification

DCS equipment designated 'indoors' shall be installed in buildings that are rated as electrically unclassified. DCS equipment designated 'outdoors' shall be rated for the electrical area classification for the area in which it will be installed. 7.2

Electromagnetic Compatibility

DCS equipment designated as 'indoors' shall carry CE Mark for compliance with European EMC Directive 89/336/EEC or shall comply with immunity levels stated in IEC 61000-6-2. Alternatively, the vendor shall provide testing results to confirm that the equipment will operate without disturbance when energized and subjected to an electromagnetic field from a radiating source equivalent to a level 3 disturbance as detailed in IEC 61000-4-3. In particular, RF sources such as hand-held radio transceivers operating at 5 Watts within the frequency ranges, 50-174 MHz, 406- 470MHz, and 800-870 MHz and held at a distance off 1.0 meters from the Page 14 of 67



equipment with cabinet doors open shall not cause any malfunction, data corruption, or damage to the equipment. 7.3

Power Supply and Distribution

7.3.1

Redundancy 7.3.1.1

All controllers, I/O modules, control network and I/O bus communications equipment shall be fed from redundant UPS power sources.

7.3.1.2

A single failure of any power supply shall not result in the failure of more than one module in a pair of redundant DCS modules. This failure shall not cause a disturbance to the process or result in loss of operator functionality. Commentary Note: The term "module" in the above requirement refers to DCS controllers, I/O modules, and any DCS communications equipment supplied in a redundant fashion.

7.3.1.3

Power supplies shall be capable of being removed and replaced without disturbing the operation of the other power supplies.

7.3.1.4

Power supplies for the same voltage rating shall be of the same make and model for interchangeability and spare parts management.

7.3.1.5

Where the power supply to a controller, I/O, or communications module is supplied from the chassis or baseplate which houses the module, the chassis or baseplate shall be fed from two separate power supply circuits. Each circuit shall be fed from separate and independent power sources.

7.3.1.6

Power supply redundancy shall be provided using either an N+N or an N+1 redundancy configuration. N+1 redundancy schemes shall be reviewed and approved by the General Supervisor, Process Control Division, Process & Controls Systems Department, Saudi Aramco, Dhahran. Commentary Note: N+N redundancy utilized two separate power supplies; each sized to supply 100% of the demand load. N+1 redundancy utilized multiple power supplies; each supplying some percentage of the load. The number of power supplies in an N+1 configuration depends on the power demand and the actual percentage of this load that each is capable of delivering.

Page 15 of 67


7.3.2


Power Distribution within DCS Cabinets 7.3.2.1

Power supplies which feed multiple chassis' or baseplates shall have their outputs wired to a power distribution panel within the cabinet. Commentary Note: The term "power distribution panel" in the a bove requirement and subsequent requirements of this section refers to a collection of din-rail mounted circuit breakers and/or fused terminal blocks, terminal blocks and wiring used to distribute power to multiple loads from a single source.

7.3.3

7.3.2.2

Branch circuits from power supplies shall be individually fused or protected by a circuit breaker.

7.3.2.3

Terminal blocks in the power distribution panel shall be segregated by voltage level.

7.3.2.4

Power distribution terminal block wiring shall not be daisychained using wires or crimp connectors. Jumper bars or preformed jumper combs designed for the specific terminal blocks being used are acceptable methods of distributing power supply wiring.

7.3.2.5

Wiring, terminal blocks, wire tagging and terminal block coding within the power distribution panel shall be as per the requirements defined in the relevant sections of 34-SAMSS820.

Power Supply and Distribution to DCS Consoles and Workstations 7.3.3.1

DCS workstations shall be fed from UPS power sources. This requirement applies to the processor, monitor, and other peripheral devices associated with the workstation.

7.3.3.2

For redundant workstations within an operator console, it is acceptable to supply power to the workstations using either of the configurations described below: a)

Each workstation shall be fed from a single UPS power circuit; provided that each workstation is fed from a separate UPS power source.

b)

Each workstation shall be fed from two separate power circuits utilizing a power switching device to maintain continuous power on loss of a single circuit. One of these circuits shall be fed from UPS power source and the other may be fed from utility power.

Page 16 of 67


7.3.4

8


7.3.3.3

Workstations which are not supplied in a redundant configuration shall be powered as described above in 7.3.3.2.b.

7.3.3.4

Commercially available multiple outlet power strips (i.e., Tripp-Lite model UL24CB-15 or similar) may be used to distribute power to multiple components of a workstation (i.e., processor, monitor, and associated peripheral devices) provided that each power strip feeds equipment associated with a single workstation. The power strip must have an integral circuit breaker and switch and must carry either a UL listing, CSA certification, or CE marking.

Utility Power 7.3.4.1

One, duplex-type convenience outlet, rated at 120 VAC, 15 amp shall be provided within each cabinet for utility power. Convenience outlets shall be wired to a separate terminal strip which in turn is sourced from a non-UPS AC distribution panel.

7.3.4.2

Two, duplex-type convenience outlets, rated at 120 VAC, 15 amp shall be provided within each console for utility power. Convenience outlets shall be wired to a separate terminal strip which in turn is sourced from a non-UPS AC distribution panel. The outlets shall be placed on opposite sides of the console to enhance availability.

Cabinets and Consoles 8.1

Marshalling Cabinets

Marshalling cabinets shall comply with the requirements of 34-SAMSS-820, "Instrument Control Cabinets - Indoors." 8.2

System Cabinets

Saudi Aramco 34-SAMSS-820 requirements shall be applied for all wiring, cables, terminal blocks, and wire ways located within system cabinets which are associated with the following: •

Power supply and distribution

•

Utility power, lighting, and convenience outlets

•

Intermediate terminal strips for I/O wiring

•

Grounding

Commentary Note:

Page 17 of 67



It is not the intent to dictate to DCS vendors and the like, the method of interconnecting and mounting their standard proven equipment. However, the wiring for system power, lighting, convenience outlets, field terminal wiring and input/output wiring between intermediate terminal strips within these cabinets shall adhere to this specification.

8.3

Consoles

8.3.1

All power supply and distribution wiring, grounding, and I/O termination wiring within consoles shall comply with the requirements of 34-SAMSS-820, "Instrument Control Cabinets – Indoors." Exception: Power distribution to workstations, monitors, and other COTS peripheral devices housed within consoles may be distributed as described in paragraph 7.3.3 above.

8.3.2

8.4

Consoles shall be noncombustible. When use of a noncombustible finish item is not practicable, the flame spread index shall be 25 or less per NFPA 255.

Communications and Interconnecting Cables

8.4.1

Any standard vendor cable which is used to interconnect equipment which is physically located in different cabinets, shall be tagged with source and destination on both ends.

8.4.2

Vendor standard cables shall be designed and installed in such a way as to allow cable disconnection in order to service the equipment. Commentary Note Vendor standard cables refers to cables which are pre-manufactured and have a standard DCS vendor part number. These cables are most often used for interconnecting chassis within a system cabinet and communications between various components of the system.

8.4.3

8.5

Data Highway or network communication cables shall maintain a minimum separation of 75 mm from any AC power cables. Fiber optic cables are excluded from this requirement.

Cabinet Protection Equipment

8.5.1

Each cabinet which contains system components, such as controllers, I/O and communications modules or which house power supply modules shall contain a temperature sensing device. This device shall be connected to the DCS to provide continuous analog temperature indication and to provide high temperature alarming to the operators.

8.5.2

Where fans are required for heat dissipation, each cabinet shall be equipped with two continuously running fans. Each cabinet with fans shall be fitted with replaceable or washable filter screens inserted behind slotted louver inlets for cabinet air supply air. Page 18 of 67


8.5.3

8.6

8.7


Cabinets which house power supply modules shall be capable of housing a High Sensitivity Smoke Detector (HSSD). The type and location of HSSD and responsibility for procurement, installation, and commissioning of the devices shall be specified in the project specific FSD.

Nameplates

8.6.1

All Cabinets shall have a nameplate permanently attached indicating the service description. Nameplates shall comply with the relevant sections of 34-SAMSS-820 specific to Nameplates.

8.6.2

Cabinets designed for both front and rear entry shall have a nameplate attached to both the front and back.

8.6.3

All push buttons, switches, lamps and other console mounted devices shall have a nameplate permanently attached indicating the service description.

Drawings and Documentation

Documentation shall be provided for all cabinet and consoles as defined in form NMR-7923, Non Material Requirements for Control Panels.

9

Inputs and Outputs 9.1

General

9.1.1

Input/Output (I/O) modules shall be capable of being inserted into or removed from their chassis or mounting assemblies without disturbing field wiring and while the chassis is powered (hot replacement).

9.1.2

The type of card in each slot shall be indicated either by labels on the card slots or a drawing or table securely attached to the inside of each cabinet door.

9.1.3

Common Mode Rejection Ratios (CMRR) of the input circuitry shall be 60 dB or greater for DC to 60 Hz and normal mode rejection ratio shall be 30 dB or greater at 60 Hz are required.

9.1.4

Process I/O circuits shall be protected against common mode transient surges of up to 300 V RMS. Such transient surges shall not cause damage or system performance degradation.

9.1.5

All digital process I/O circuits shall be designed to ensure that accidental normal mode connection of up to 300 V ac/dc for an unlimited period of time shall not cause damage other than to the I/O module to which it is connected.

Page 19 of 67


9.1.6

9.2


All Input/Output modules shall provide a status LED which indicates the health or operational condition of the module. The status of the module shall also be communicated to the system diagnostics software.

Analog Input

9.2.1

The system shall be capable of supporting the following analog process input signals: a)

4-20 mA dc.

b)

0-10 Vdc.

c)

1-5 Vdc.

d)

Type E, J, and K thermocouples.

e)

Platinum resistance temperature detector (RTD), per ASTM E1137 or IEC 60751.

f)

Pulse inputs.

9.2.2

Temperature linearization and thermocouple cold junction compensation shall be provided.

9.2.3

The system shall provide automatic detection of thermocouple opencircuit conditions. Open-circuit detection circuitry shall not affect the accuracy of a temperature measurement by more than 0.25°C.

9.2.4

Analog input modules shall provide the accuracy shown below: Accuracy

:

+ 0.25% of full range

9.2.5

Calibration of the A/D converters shall be automatically checked by the system on a periodic basis. An indication of calibration error shall be provided by the system.

9.2.6

The noise level that is generated by the input circuitry shall be less than the minimum resolution of the measurement.

9.2.7

Analog input modules shall be able to power 4-20 mA field instrumentation loops with a loop resistance of 600 ohms.

9.2.8

Pulse input modules shall be capable of measuring pulse frequency. Input pulses will be characterized as follows: a)

Square wave, sine wave, or dry contact

b)

0 to 10 kHz

c)

5 to 10 Volt peak to peak

d)

2-wire (self-powered or dry contact) or 3-wire (DCS powered at 24 Vdc).

Page 20 of 67


9.3

Distributed Control Systems

Discrete Input

9.3.1

9.4

23-SAMSS-010

The system shall be capable of supporting the following discrete input types, time stamped to 1 second or better resolution: a)

24 Vdc

b)

120 Vac

c)

125 Vdc

9.3.2

The system shall be capable of detecting discrete input transitions with duration of 50 millisecond.

9.3.3

24Vdc inputs shall be able to use either internal or external power supplies. Other voltages may be provided by external power supplies.

9.3.4

Relay or solid-state input from field powered contacts shall be available.

9.3.5

The system shall support configurable digital input filtering to prevent digital input "chatter" or "bounce".

9.3.6

Discrete input modules shall have visible LED indicators on a per channel basis to indicate the current state of the input.

Analog Output

9.4.1

The system shall support 4-20 mA outputs.

9.4.2

The analog outputs shall be capable of driving resistive loads of 600 ohms impedance.

9.4.3

Analog output modules shall provide the accuracy shown below: Accuracy

:

+ 1.0% of full scale

9.4.4

Output modules shall be provided with individually fused outputs or current limiters.

9.4.5

Analog output modules shall have the following configurable failsafe options: a)

Drive to zero output or full-scale output

b)

Maintain last good output value

Commentary Note: The fail-safe actions listed above shall be taken upon processor halt or communication break between the controller and the I/O module.

9.5

Discrete Output

9.5.1

The system shall be capable of supporting the following: a)

On/off Page 21 of 67


9.5.2


b)

Single pulse, (configurable width).

c)

Latching and non-latching (momentary) contact outputs

The following solid state or relay board output ratings shall be available: a)

24 VDC, 80 mA, non-inductive load

b)

120 VAC

9.5.3

Relay or solid state output contacts that are free of voltage and ground shall be available.

9.5.4

The duration of the single pulse outputs shall be individually configurable.

9.5.5

Output modules shall be provided with individually fused outputs or current limiters.

9.5.6

Discrete output circuits shall be provided with protection for the switching of inductive loads.

9.5.7

Discrete output modules shall have visible LED indicators on a per channel basis to indicate the current state of the output.

9.5.8

Discrete output modules shall have the following configurable fail-safe options: a)

Drive to either energize or de-energize output

b)

Hold last output

Commentary Note: The fail-safe actions listed above shall be taken upon processor halt or communication break between the controller and the I/O module.

9.6

Digital I/O

9.6.1

The system shall support redundant input and output modules which are capable of communicating to Foundation Fieldbus ™ (FF) based devices.

9.6.2

The system shall support redundant input and output modules which are capable of communicating to HART ™ registered devices using HART protocol version 5.6 or greater.

9.6.3

The system shall support communications to HART devices using the Universal and Common Practice command sets using the HART I/O modules as the interface.

9.6.4

The system shall be capable of receiving, displaying, and storing diagnostic data and device alerts from HART devices using the HART I/O modules as the interface. Page 22 of 67


9.7


9.6.5

The system shall be capable of displaying configuration data resident in HART devices at the DCS workstations.

9.6.6

The system shall be capable of modifying the configuration of HART devices from the DCS workstations.

Manual Input

9.7.1

The system shall be capable of accepting manual entry inputs into a tag type configured for such manual entry.

9.7.2

Manual inputs may be of the following types: a)

Analog values

b)

Discrete values

c)

Text values (including date/time values)

Commentary Note: Tags receiving analog and discrete manual inputs shall be treated as any other tag with regard to availability to historization, trending, calculation and controller blocks, and high level language programs.

10

Workstations 10.1

10.2

All Workstations

10.1.1

Failure of any component shall not cause the failure of more than one workstation.

10.1.2

The workstation operating system shall be Unix or Microsoft ™ Windows, independent of the hardware.

10.1.3

The workstation operating system (OS) + service packs shall be a revision which is currently supported by the OS vendor and has been verified by the vendor for application software compatibility.

10.1.4

Tools shall be provided to enable a complete hard-drive image backup for all workstations and servers which are part of the system. The backup and restore shall be capable of being performed to a networked server and to removable storage media.

Operator Workstations

10.2.1

Each Operator Workstation shall be supplied with, but not limited to, the following: •

One (1) pointing device.

•

One (1) alphanumeric (QWERTY) keyboard.

•

One (1) programmable operator keyboard or equivalent functionality. Page 23 of 67


10.3


10.2.2

Operator workstations shall be supplied with minimum 20" flat screen CRT or LCD color monitor with minimum resolution of 1280 X 1024 pixels.

10.2.3

All operator workstations shall have the ability to view and monitor any and all process areas / process units connected to the DCS.

10.2.4

Operator workstations shall be configured to have access to perform control functions to only those process areas and process units to which it has been assigned. (Note: Designation of operator workstation control assignments shall be specified by the project specific FSD).

10.2.5

The control assignment of each operator workstation shall be capable of being changed by the operator by entering an appropriate password.

10.2.6

Operator workstations shall have either a dedicated operator keyboard or a dedicated operator graphic display which provides the following functionality. If the functionality is to be provided using a dedicated graphic display, call-up of the display must be accessible via a single mouse click from any process graphic window. 10.2.6.1

User configurable LEDs which are activated and flashing when predefined process alarm(s) are active and unacknowledged and activated and steady when predefined process alarm(s) are active and acknowledged. A minimum of twenty-four (24) LEDs are required.

10.2.6.2

User configurable buttons to select operational functions or callup predefined process graphics with a single selection. A minimum of twenty-four (24) key assignments are required.

10.2.6.3

A dedicated button for Horn Silence.

Engineering Workstations

10.3.1

An engineering workstation shall provide the following functions: a)

Configuration

b)

Database generation

c)

Graphics display generation and modification

d)

Control algorithm generation and modification

e)

Report generation and modification

f)

System access configuration

g)

File access

h)

Diagnostics

i)

Workstation/monitors and keyboard plant area assignments Page 24 of 67


j)

10.4

10.5

11


Utility program access.

10.3.2

Engineering workstations shall contain all the functionality of an operator workstation and be capable of being used as an operator workstation when required.

10.3.3

Engineering workstations shall be supplied with minimum 20" flat screen CRT or LCD color monitor with a minimum resolution of 1280 X 1024 pixels.

10.3.4

A QWERTY keyboard and pointing device shall be provided with each engineering workstation.

10.3.5

Removable storage media, either DVD or CDROM RW or DAT tape, shall be provided at each engineering workstation.

Printers

10.4.1

Each operator and engineering workstation shall have access to a networked printer for printing of reports, process graphics, and other information.

10.4.2

Black and white and color printers shall be supported.

10.4.3

It shall be possible to send multiple requests to a printer without having to reboot it or its interface or its associated workstation.

Display Hardcopy

10.5.1

The capability to generate a hardcopy of any active display shall be available.

10.5.2

Generation of a hard copy shall not freeze the monitor display for longer than 2 seconds.

10.5.3

The system shall support both full color and black and white copies for all displays.

10.5.4

It shall be possible to save an image of the current operator window to file in either .jpg or .bmp format.

Control Network and Internal Communications 11.1

DCS networks shall be based upon industry standards from IEEE/IEC.

11.2

Communication at the control network level shall have redundant or fault tolerant paths. Communications from the controller to the I/O subsystem shall have redundant paths.

11.3

DCS internal communication shall be designed such that no single failure will degrade the performance of the system. This requirement applies to all communication between DCS modules, including communication between controllers to their I/O modules. Page 25 of 67


12


11.4

Data highways shall use both paths continuously or shall check the backup path at least once per minute to determine if the backup path is operating normally.

11.5

Failure of any single device that is connected to DCS network shall not affect the ability of the system to communicate with other devices on the network.

11.6

It shall be possible to run redundant or fault tolerant communication cables in separate conduits or paths.

Foundation Fieldbus ™ (FF) Host Requirements 12.1

Host Control System Requirements

In addition to the FF requirements specified in this document, Host systems shall meet all requirements specified SAES-J-904, "Foundation Fieldbus (FF) Systems." 12.2

FF Host Interoperability

12.2.1

12.2.2

All FF Host systems shall have completed Host Interoperability System Testing (HIST) based on HIST Procedures document FF-569. The features which a system must have passed as defined in FF-569 are as follows: •

Device Tag Assignment

•

Device Address Assignment

•

Configuration of Link Master Devices

•

Block Tag Configuration

•

Block Instantiation

•

Standard Blocks

•

Enhanced Blocks

•

Custom Blocks

•

Function Block Linkage Configuration

•

FF Alert Configuration

•

FF Alert Handling

•

Device description services

•

DD Method execution

•

Capability files

A letter of conformance to the Host Interoperability System Test shall be provided to verify test completion and feature support.

Page 26 of 67


12.2.3

12.3

12.4

12.5


All supported FF HIST features shall be integrated seamlessly into the existing control system's engineering, configuration, maintenance, and operations system.

Host-To-Device Revision Download Capability

12.3.1

Hosts shall have the capability to download software revisions to Foundation Fieldbus devices.

12.3.2

Hosts systems shall have the capability to store multiple revisions of a Device Descriptor (DD) file on-line.

12.3.3

Hosts systems shall be capable of hosting multiple devices of the same make and model using different revisions of DD files simultaneously.

Host Configuration Features

12.4.1

Host FF configuration shall be consistent in method and 'look and feel' with conventional configuration.

12.4.2

The Host FF configuration tool shall seamlessly and transparently integrate with, and maintain, the master configuration database. Saves, restores and partial downloads of the master control system database shall be seamlessly and transparently accomplished for both FF and conventional control strategies by the same configuration tool.

12.4.3

The Host shall not require separate databases be maintained on the system for FF configuration vs. configuration of conventional control strategies.

Host Configuration Capabilities

The FF Host configuration tool must have the following capabilities: 12.5.1

Offline FF configuration, e.g., to configure FF strategies with no segment or FF devices connected.

12.5.2

The Host shall be capable of configuring all FF function blocks and parameters and support of DD services and Common File Format specification.

12.5.3

Importing non-native, bulk configuration data for developing configuration of larger project databases.

12.5.4

Simple or complex online FF control strategy creation or modification.

12.5.5

Providing alerts and messages for FF configuration errors.

12.5.6

Transparently managing the macrocycle schedule including maintaining minimum unscheduled acyclic time, coordinating integration of proprietary and FF function block execution times.

Page 27 of 67


12.6


12.5.7

Displaying individual macro cycles in graphical format showing block execution times and unscheduled free time.

12.5.8

Partial or incremental downloads to target function blocks and link schedulers without disrupting the operating segment strategies.

12.5.9

Master database saves and restores of targeted strategies or FF segments.

Host Commissioning and Maintenance Functions

The Host shall be capable of commissioning, setup, and maintaining all FF devices. This function may be integrated into the Host or available from an integrated Instrument Management System. The following functions shall be supported:

12.7

12.6.1

Add a new FF device to a segment. Add a future FF device to a segment through use of templates.

12.6.2

Automatically manage FF segment address assignment for new instruments. Manual address changes shall not be required.

12.6.3

Simple and complex commissioning functions including transmitter range changes, zeroing, and control valve positioner setup.

12.6.4

Soft simulating and testing of all FF function blocks while the actual devices are not connected to the system.

12.6.5

Support for any FF instrument supported DD methods and menus (wizards) to walk technicians through the necessary maintenance procedures.

12.6.6

Provide specific maintenance displays, organized in a logical manner, for all FF devices using English language descriptors and definitions with access to all parameters. Screens shall not use lists of FF function block parameters.

12.6.7

Ability to mirror existing FF device configuration (all Function Blocks and parameters) onto a new FF device to allow quick device replacements.

12.6.8

Ability to perform device replacement without disturbing other devices on a segment.

12.6.9

Display of commissioning and maintenance screens shall be from the operator and engineering workstations.

Host FF Feature Integration

12.7.1

All Host FF functions, including engineering, configuration, maintenance, and operational display functions, shall be integrated into a single, seamless Host system. Page 28 of 67


13


12.7.2

Engineering, configuration, maintenance and operational features shall apply consistently and seamlessly to conventional analog or discrete I/O, smart HART and proprietary I/O, bus based I/O, and FF systems.

12.7.3

Separate software tools, displays, or procedures - specific for FF and different from conventional - are not acceptable.

12.7.4

Internal mirror or shadow function blocks used by control systems to map FF function blocks to internal proprietary function blocks must be completely transparent to the operator. Operating displays must use single, unique and independent tag names. Duplicate tag names for the same function are not acceptable.

12.7.5

FF function block operation, including use of data quality, status, windup and bad value indication and mode switching, must be supported by, and transparently integrated into the control system operation and operating displays. Differences in operation or displays between FF devices or loops and conventional loops are not acceptable.

12.7.6

FF process alarms must be supported by, and integrated into the control system. Differences between conventional and FF alarm management and alarm displays are not acceptable.

12.7.7

It shall be possible to trend data from an FF device using the same historical data collection and trending tools used for conventional analog and discrete I/O.

Control and Data Handling 13.1

Regulatory Control

13.1.1

Input Scanning Controllers shall scan inputs at a sufficient frequency to provide freshly sampled data at .25 Sec or faster.

13.1.2

Input Functions 13.1.2.1 The following input functions shall be supplied as standard configurable items: a)

Square root extraction

b)

Linearization of type E, J and K thermocouples

c)

Linearization of RTDs

d)

Time-based filtering

e)

Digital input totalization

f)

Pulse input to frequency conversion Page 29 of 67


g)


Dead band on a per loop basis

13.1.2.2 It shall be possible to force flow measurements to zero if the input is below a configured value (after square root extraction). 13.1.2.3 Input filtering and signal conditioning shall be performed before alarms are checked and control calculations are made. 13.1.3

Computational Functions The following computational functions shall be supplied as standard, configurable items or simple algebraic instructions. a)

Addition/subtraction

b)

Ramp generator

c)

Lead-lag

d)

Integrate - accumulators

e)

Dead time

f)

High/low select

g)

Median select

h)

Multiply and divide

i)

Time average

j)

13.1.4

Signal selection switch

k)

Exponential polynomial

l)

Fifth order polynomial

m)

Logarithms

n)

Square root

o)

Totalizer with reset for analog and calculated valid values.

p)

Absolute value

Continuous Control Functions The following control functions shall be supplied as standard configurable items: a)

Proportional Integral Derivative (PID)

b)

Proportional Integral

c)

Proportional Derivative

d)

Proportional only Page 30 of 67


13.1.5

e)

Integral only

f)

Auto/manual with bias control

g)

Ratio control

h)

Control (Signal) Selector

i)

Output Splitter

j)

PID with feed-forward

k)

PID with non-linear gain

l)

External Feedback

m)

Gap action

n)

adaptive tuning


Output Functions The following output functions shall be supplied as standard configurable items:

13.1.6

a)

Linear

b)

Linear with clamping (high and low restricted)

c)

Non-linear characterization

d)

Rate of change limits

e)

Output limiting based on application program

f)

Output limiting based on discrete input status

Discrete Control The following discrete control functions shall be supplied as standard configurable items:

13.1.7

a)

Logic functions -- AND, OR, NOT, NOTAND, NOR, XOR

b)

Change of state detect

c)

Set/reset flip-flops

d)

Timers and counters

e)

Comparisons -- greater than, less than, equal to, not equal to

f)

Pulse elements -- fixed, maximum, minimum

g)

Check for invalid value

h)

Flags

Control Loop Execution Frequency

Page 31 of 67



It shall be possible to select the execution frequency of each control loop. The following minimum selections shall be available: a)

One second

b)

One half (½) of a second

c)

One quarter (¼) of a second or less

Commentary Note: The control loop execution frequencies are for those loops which are executed in DCS process controllers. These execution times do not apply to Foundation Fieldbus systems where control is implemented in the field devices.

13.1.8

Setpoint Clamps Upper and lower clamps on all setpoints shall be available.

13.1.9

13.2

It shall be possible to define a tag ID that combines multiple inputs and outputs of a single device, such as a pump or MOV. An operator shall be able to operate the device (start, stop, open, or close) by calling up that tag.

Control Modes

13.2.1

It shall be possible to put any individual control loop in a manual mode; and for an operator to manipulate the output of a control loop while in the manual mode.

13.2.2

In manual mode, an output signal from a field output module must change within one second from the last operator action that is required to command the change.

13.2.3

For cascade control, it shall be possible to configure remote setpoints from other regulatory controllers or from other DCS modules.

13.2.4

All control blocks that can accept a setpoint shall be capable of being switched between local setpoint (operator entered) and remote setpoint.

13.2.5

All cascaded loops shall support bumpless transfer.

13.2.6

Information shall be transferred between cascaded loops that are in separate controller modules within 2 seconds.

13.2.7

Information shall be transferred between cascaded loops that are in the same controller module at whatever the configured block processing period is for the loop.

13.2.8

Control blocks shall be able to perform automatic mode switching based on external or internal logic inputs. Mode switching shall include the following: a)

Auto/manual/supervisory switching Page 32 of 67


b) 13.3


Local/remote setpoint switching.

Fault Handling

13.3.1

Invalid value status shall be generated for inputs and calculated variables.

13.3.2

A value shall be declared invalid if any of the following conditions are true: a)

if a value is out of range.

b)

if a value can not be measured or calculated.

c)

if a value is declared invalid by an application program.

d)

if a value is declared invalid by the source instrument.

e)

On loss of communications to the data source.

13.3.3

Invalid value status shall be propagated through control schemes.

13.3.4

It shall be possible to inhibit the detection and propagation of an invalid value status. This selection shall be available on a per tag basis.

13.3.5

It shall be possible for an invalid value status to be used as a logical input to initiate control algorithm changes.

13.3.6

When a control algorithm's input is declared invalid, it shall be possible to configure the output to take any of the following actions, on a per point basis: a)

hold last good value,

b)

zero output signal,

c)

full-scale output.

Commentary Note: The term control algorithm refers to instructions executed within function blocks where an output is calculated based on the value and status of inputs to the function block.

13.4

Initialization

Initialization is the process by which initial values of the mode, setpoint and output of a control block are set. 13.4.1

It shall be possible to initialize a control block or control strategy when any of the following conditions exist: a)

The control block is turned from off to on.

b)

The control block mode is changed from manual to automatic, from manual to cascade, or from automatic to cascade. Page 33 of 67


c)

13.4.2

13.5


The control block output is cascaded to the remote setpoint of a downstream control block which is being switched from manual to automatic, from automatic to cascade, or is being initialized.

Variables that are being initialized shall be subject to the following: a)

Calculations involving time-based data shall be reset.

b)

Initialization shall not cause an audible alarm.

13.4.3

Function blocks which have a setpoint shall offer the option of either initializing the setpoint to the process value (PV) or of maintaining the last valid setpoint upon algorithm initialization.

13.4.4

Function blocks which write their outputs to field devices, shall initialize their output to the current state or position of the field device during initialization.

Bumpless Transfer

Bumpless transfer is the ability of a control function block to transition from a non-controlling state (i.e., manual, hold, tracking, initialization) to the controlling state whereby the output of the control block maintains its present value at the moment the transition occurs. The system must contain the functionality listed below in order to support bumpless transfer capability.

13.6

13.5.1

Function blocks which have a setpoint shall have an option for setpoint tracking. When configured for setpoint tracking, the setpoint will track the process value (PV) when the block is switched to manual.

13.5.2

In a cascade loop an output tracking option shall be available. When configured for output tracking the primary controller output tracks the secondary controller setpoint when the secondary controller is in either manual, automatic, or is itself output tracking.

13.5.3

When either setpoint tracking or output tracking is active, this state shall be clearly visible to the operator in a standard faceplate display, and available as a parameter which can be accessed for either a graphic display or an application program.

13.5.4

Function blocks shall be capable of propagating the initialization status to upstream control blocks when configured in a cascade configuration.

13.5.5

For cascade control, the primary controller must be configured to set its output equal to the downstream setpoint when the downstream controller transitions from an initializing state to a controlling state.

Windup protection

Page 34 of 67



Windup protection is the ability of a control function block which contains integral action to disable the effect of integral action on the computed output when the output of the block is constrained. 13.6.1

Control functions blocks, which include integral action, shall provide windup protection.

13.6.2

Windup protection shall inhibit the integral action when the control block output is constrained by conditions such as: a)

Output at high or low limits of span

b)

Output at high or low clamps

c)

Output tracking is active

d)

Output is connected to the setpoint of a secondary controller which is output limited or in manual.

e)

Output is connected to a signal selector block which selects between multiple inputs and the output of the control block is not selected.

f)

Output is not connected to any valid device or algorithm.

Commentary Note: Item (f) above may occur if a controller loses communication with the output module due to hardware failure.

13.7

13.6.3

When windup protection is active, this status shall be clearly visible to the operator in a standard faceplate display, and shall set a parameter which is accessible to graphic displays and application programs.

13.6.4

When windup protection is active, this status shall be propagated to all function blocks connected to the control function block to prevent windup of primary controllers in a cascade configuration. Windup status shall be able to be propagated to as many levels of control as are configured in the control strategy.

Sequential/Batch Control

13.7.1

The system shall provide a graphical configuration tool which conforms to the IEC 61131-3 guidelines for Structured Text or Sequential Function Chart.

13.7.2

It shall be possible to modify individual program logic for sequential functions without interrupting the operation of other sequential functions that are active.

13.7.3

The system shall have the ability to monitor and control program flow through sequential functions in real-time.

13.7.4

Sequential Functions Page 35 of 67



The following sequential functions shall be supplied as standard instructions: a)

b)

c)

d)

e)

Relational expressions: -

Equal to

-

Not equal to

-

Less than

-

Less than or equal

-

Greater than

-

Greater than or equal

-

IF / IF Then.

Calculations: -

Add

-

Subtract

-

Multiply

-

Divide

-

Exponentiation (whole and fractional)

-

Square root

Timers: -

Output true after preset delay

-

Output false after preset delay

Counters: -

Count up

-

Count down

Logical expressions: -

And

-

Or

-

Not

-

Exclusive Or

-

Single bit memory elements (flip/flops)

f)

Hold sequence - Manual or preset time

g)

Recycle to prior step Page 36 of 67


14


h)

Skip 1 or more steps

i)

Restart at beginning

Configuration and Database 14.1

Configuration

14.1.1

Configuration Editor 14.1.1.1 The system shall provide a graphical configuration tool which conforms to the IEC 61131-3 guidelines for Function Blocks for development and configuration of regulatory control strategies. 14.1.1.2 The configuration tool shall be capable of interconnecting function blocks on a single display to develop control strategies. Commentary Note: A display which graphically shows the interconnection of function blocks which make up a control strategy is typically referred to as a control strategy diagram or CSD.

14.1.1.3 The system shall be capable of displaying real-time process data on control strategy diagrams. 14.1.2

The system shall provide the capability for multiple users to perform configuration tasks from multiple workstations simultaneously. The system shall ensure that multiple users cannot modify the same control strategy at the same time.

14.1.3

A facility such as copy/paste or a "template" shall be provided to facilitate creating multiple tags that have common parameters (except for minor changes such as tag ID and I/O address). This template can be defined once and then used as the basis for each tag. It shall be possible to define and store multiple templates. An easy method of calling each template shall be available.

14.1.4

Configuration changes shall be validated by the system before being loaded into the on-line controller.

14.1.5

The system shall prevent invalid configurations entries from being loaded into an on-line controller. Upon detection of invalid configuration entries, the system shall indicate to the user which entries are invalid.

14.1.6

The system shall provide the capability to add, delete, or modify DCS function blocks in a controller which is on-line and in-service without affecting other function blocks in the same controller except for those linked directly to the function block being changed. Page 37 of 67



14.1.7

The system shall support the capability to perform bulk configuration through scripting or through the use of a vendor supplied engineering configuration tool which has a windows based GUI.

14.1.8

Functionality shall be provided to enable configuration changes to DCS function blocks without causing a bump to the process. Commentary Note: Placing the block into manual is an acceptable means of preventing a bump to the process for those systems which do not support the capability to make changes without affecting the process while the block is in-service.

14.1.9

The system shall provide the capability to save all database and configuration data on both removable and non-removable media for back up purposes without taking the system off-line.

14.1.10 The system shall provide redundant on-line storage media for configuration data base. 14.1.11 The system shall have the capability to configure at least 10 plant areas and to assign any tag to any one of these plant areas. 14.1.12 The system shall have the capability to upload operational data to a configuration file on demand. Operational data includes setpoints, block mode (A/M), tuning parameters, and other block parameters which operators and/or engineers have access to modify without using the configurator. 14.1.13 On manual restart or re-initialization, it shall be possible to select restart from operational data in the most recently saved or from previously saved data. 14.1.14 The system shall be capable of exporting and importing configuration database information into Microsoft applications such as Excel or Access. 14.2

Tag Parameters

14.2.1

14.2.2

All tags shall be defined with at least the following parameters: a)

Tag ID

b)

Tag descriptor

c)

Tag type

d)

Alarm requirements

Tag IDs shall be unique throughout the system; and access to all tag parameters for configuration shall be available directly by tag ID.

Page 38 of 67


14.3


14.2.3

A tag ID shall allow a minimum of 12 free-format alphanumeric characters.

14.2.4

The system shall support tag descriptors of a minimum 16 characters length.

14.2.5

The system shall provide the capability to define free-format alphanumeric descriptors for each state of a multi-state device. Four states shall be allowed for each multi-state device (for example, open, closed, traveling, and fault for an MOV).

14.2.6

Each analog input, output, and control block shall be assigned an engineering unit designation. Engineering units shall be capable of being a minimum of six free-format alphanumeric characters.

Search Utilities

14.3.1

The system shall provide the ability to search for tags throughout the global system database. These utilities shall be under system access control.

14.3.2

The system shall be capable of generating listings containing the following fields:

14.3.3

15

23-SAMSS-010

a)

tag ID

b)

tag descriptor

c)

point type

d)

hardware address

It shall be possible to perform the following functions on the above list: a)

sort alphanumerically by any field

b)

filter by any field

c)

print, display and store to media

Security 15.1

User Groups and User Roles

15.1.1

The system shall be capable of defining user groups or user roles. System access privileges shall be configurable for each user group or user role. Individual user privileges shall be determined based on the user group / role to which the user is assigned.

15.1.2

A minimum of fifteen user groups / user roles shall be configurable. The system shall be capable of defining the following user roles as a minimum:

Page 39 of 67



a)

View Only

b)

Plant Operator (1 – 10 plant operator roles shall be specifiable)

c)

Process Supervisor

d)

Engineer

e)

System administrator

15.1.3

The system shall be capable of defining as a minimum ten user groups which are dedicated as plant operator user roles. System access privileges for plant operator user roles shall be the same for all operators with the exception of the actual process or plant area for which process parameter manipulation is possible.

15.1.4

An example configuration of user groups is shown below. The actual configuration shall be specified in the project specific FSD. a)

View Only – This role shall enable viewing of all process values and process graphics but shall not allow manipulation of any process parameters.

b)

Plant-XXX Operator – This role shall enable manipulation of process parameters for equipment defined as belonging to plant or process area XXX (XXX represents a plant area or process area. The actual plant areas or process areas shall be defined in the project specific FSD.) This role shall not allow manipulation of process parameters for equipment which are not a part of that particular plant or process area. The system shall support the ability to define as a minimum twelve different User groups for plant operations.

c)

Process Supervisor – This role shall have the same capabilities capabilitie s as a plant operator with the exception that users assigned to this role shall have access to manipulation of process parameters for multiple plant areas.

d)

Engineer – This role shall enable manipulation of process parameters for all plant areas as well as access to configuration tools for control strategies, process graphics, smart device configuration, and other tools. This role shall also enable users to access system diagnostics tools. This mode shall not allow changes to user role assignments, user role privileges, passwords, and other system administration function.

e)

System Administrator – This mode shall enable definition of user role privileges, user assignments, passwords, and other system administration functions. This role shall also enable access to

Page 40 of 67



configuration tools and system diagnostics tools accessible to the engineer user role. 15.2

15.3

User Accounts

15.2.1

The system shall be capable of maintaining separate user accounts for each user whom has access to the system.

15.2.2

Users shall be granted system access privileges by defining the user as belonging to a particular user group or user role. The system access permissions which have been defined for that user group shall be applicable to the individual user once the user is assigned to the group.

15.2.3

The system shall have the ability to track user login activity and maintain records of user login activity.

15.2.4

The system shall have the ability to disable user accounts on a temporary basis when the user has not logged into the system within a user configurable time period. User accounts shall not be automatically disabled, but shall require the system administrator to manually initiate this process. The time-period which must elapse prior to an account being disabled shall be configurable by the systems administrator.

15.2.5

The system shall have the ability to monitor and detect failed login attempts. The system shall automatically notify the system administrator when the number of failed login attempts exceeds a threshold value. The threshold shall be configurable by the systems administrator.

Passwords

15.3.1

Each user shall have a separate password required for login to the system.

15.3.2

Management and administration of passwords shall be done from a central location within the system. If a user updates his password on one station in the system, every station connected to the system shall have access to the updated password. Separate passwords for individual workstations on the system shall not be permitted.

15.3.3

The system shall be capable of enforcing password policies for administration of user passwords. The following policies shall be capable of being configured as a minimum: 15.3.3.1 Password Aging – the system shall be capable of configuring and enforcing a maximum password age. Users shall be required to change their password within the password aging period. Users shall be notified during login when the current password is about to expire. Users whom do not change their Page 41 of 67



password within the password aging period shall be locked out of the system. 15.3.3.2 Password Complexity – The system shall be capable of configuring and enforcing the policies for password construction. As a minimum, passwords shall be required to meet a minimum length requirement. 15.3.3.3 Password Uniqueness – The system shall be capable of configuring and enforcing a minimum number of unique passwords be used prior to a password being re-used. This prohibits the user from entering the same password. 15.4

Anti-Virus Protection

The requirements for anti-virus protection apply only to Microsoft Windows based systems.

15.5

15.4.1

The system shall be capable of running commercially available antivirus software protection packages (such as MacAfee or Norton antivirus) while the station is performing its intended functions.

15.4.2

Configuration requirements for anti-virus software shall be clearly documented in the systems user's manual.

Network Security

Communications networks between DCS control networks and other non-DCS networks shall adhere to the requirements defined in SAES-Z-010.

16

Diagnostics 16.1

General

16.1.1

The status of all modules shall be periodically checked to verify the on-line status and operation. Errors shall be alarmed with an error message identifying the effected module.

16.1.2

The status of each on-line module shall be checked at least once per minute.

16.1.3

Diagnostic tools shall provide the following information: a)

Module status (e.g., on-line, off-line, failed, standby) Commentary Note: DCS modules installed in a redundant or fault-tolerant configuration shall indicate the status of each module in the pair.

b)

Overall Processor loading (CPU) for controllers and other vendor proprietary DCS modules exclusive of I/O Modules.

c)

Network utilization of control network. Page 42 of 67



Commentary Note: Control networks which utilize standard COTS Ethernet networking components may use commercially available network monitoring packages provided by the networking component vendor to fulfill this requirement.

d) 16.2

Software and firmware (if applicable) version of all modules installed in the system.

System and Diagnostic Displays

16.2.1

Communication System Status Displays Standard displays shall show as minimum as the operational status of the communication system. The state of each module connected to the communication system (on-line, off-line, failed, primary failed, backup failed) shall be shown.

16.2.2

Module Status Displays Displays shall be provided to show the operational status and error conditions for all system modules down to the card level.

16.2.3

Diagnostics On-line and off-line diagnostics shall be provided to assist in system maintenance and troubleshooting. Diagnostics shall be provided for every major system component and peripheral. If diagnostics do not exist for a particular peripheral devices (for example printers and terminals), the system must detect and provide an error indication for the failure of these devices.

17

16.2.4

On-line displays shall indicate the results of self-diagnostic tests. Failure diagnosis shall be sufficiently specific to indicate which printed circuit boards, modules, or devices are at fault. The displays shall be designed to help maintenance and engineering personnel diagnose faults in the system and communications paths. Each category of diagnostic display shall be organized hierarchically.

16.2.5

Communications diagnostic displays shall show errors for each of the redundant paths.

Displays and Graphics This paragraph details the requirements for operator displays and graphics. The vendor's standard graphical displays are referred to as "displays" and user generated graphical displays are referred to as "graphics". 17.1

General

17.1.1

Updating Capability

Page 43 of 67



All displays and graphics that show real time data shall update automatically when the display is resident on the screen. Updates shall not require operator initiation. 17.1.2

Invalid Values Special indication shall be used to indicate that a value is invalid.

17.2

17.3

Display and Graphic Response

17.2.1

Call-up-time for display and process graphics shall be a maximum of four (4) seconds. This requirement applies to all displays and graphics including ones which have fully active dynamic elements for up to one hundred (100) fields.

17.2.2

The update frequency for real time data, displayed alphanumerically and symbolically (shape change, color change, etc.), shall be at least once every two (2) seconds for all displays and graphics.

17.2.3

Call-up-time for historical data displays shall be a maximum of ten (10) seconds. This requirement applies to historical data queries for up to 100 records for a minimum of eight (8) tags.

Faceplates

Faceplates provide detailed, dynamic process and status information for a single control loop. They also provide the ability for the operator to manipulate process parameters for the loop.

17.4

17.3.1

The system shall be capable of configuring faceplates as separate displays or as graphic elements.

17.3.2

Faceplates shall be constructed from templates such that the layout and operational characteristics of an individual faceplate shall be inherited from the template. Changes to the template shall be automatically propagated to all faceplates built from the template.

17.3.3

The system shall have standard pre-configured faceplate templates for all standard Function Blocks.

17.3.4

The system shall be capable of configuring faceplates for a minimum of 10,000 tags.

17.3.5

Faceplates shall be moveable on the screen after being called up for display on a workstation.

Graphics

A utility shall be provided that is able to generate and modify user-defined graphics and that is able to implement all the features defined below. 17.4.1

It shall be possible to place a new graphic in service without interrupting an operator's ability to control the plant. Page 44 of 67



17.4.2

The graphics builder utility shall have the capability to make a copy of an existing graphic in order to build a new graphic that is similar.

17.4.3

The graphics builder utility shall use the same tag IDs that are used in the process database to access real time variables from any database. No intermediate index numbers or addressing shall be required.

17.4.4

The graphics builder utility shall be subject to system access protection.

17.4.5

It shall be possible to define graphic elements that are a subset of a full graphic. Graphic elements shall have the following capabilities: a)

Graphic elements shall be maintained in a specific library or folder on the system.

b)

Properties of graphic elements (such as visibility, color, fill level, etc.) shall be capable of being linked to process values.

c)

An automated tool shall be provided to update graphic elements inserted into process graphics when a change is made to a graphic element in the library.

d)

It shall be possible to define a minimum of 50 graphic elements.

17.4.6

All control, monitoring, and status attributes of any tag shall be displayable on graphics. For analog points this requirement includes measurement, setpoint, alarm limits, and output. For discrete points this requirement includes input and output status. Status information includes: alarm status, control mode, and control status.

17.4.7

The format of numeric data shall have the following capabilities: a)

It shall be configurable on an individual basis.

b)

It shall be possible to display numeric data in formats ranging from a single digit to 6 digits (not including the sign or decimal place), with from 0 to 5 decimal places.

c)

If the decimal point is not used, it shall be suppressed.

17.4.8

It shall be possible to display numeric data in any available color.

17.4.9

It shall be possible for each state of a multi-state device to be indicated by a unique foreground/background color combination.

17.4.10 It shall be possible for inactive alarm or status messages to be invisible to the operator. 17.4.11 It shall be possible to display numeric data and other text on process graphics with multiple fonts and different character sizes.

Page 45 of 67



17.4.12 It shall be possible to display numeric data in dynamic vertical bar graph format. This format shall have the following capabilities: a)

The height and width of each bar graph shall be configurable on an individual basis.

b)

The height and width shall be configurable in units that are not greater than the normal-sized character height and width.

17.4.13 Symbolic representation of data on the graphics shall be performed by shape changes, color changes (foreground and background independently), and flashing in any combination. 17.4.14 It shall be possible for users to create at least 100 symbols and to store them in a permanent library. The graphic builder utility shall have facilities to maintain this library. 17.4.15 It shall be possible to position any symbol anywhere on a graphic. 17.4.16 Each graphic shall be capable of handling any mix of 200 calculated, analog, and / or discrete dynamic display elements, including graphical symbol representation of process status for real time data display. 17.4.17 It shall be possible to configure a screen target that calls up other displays. 17.5

18

Graphic Capacity

17.5.1

Each operator workstation shall have access to 200 user-defined graphics.

17.5.2

Each monitor in the workstation shall have access to all of the 200 graphics.

17.5.3

Each operator workstation shall be capable of providing graphics for 2000 tags.

17.5.4

Each monitor in the workstation shall be capable of accessing all of the 2000 tags.

Alarm and Message Handling This section details the requirements for process alarms, system alarms, and other messages. Unless stated otherwise, the requirements for alarms within this section apply to both process and system alarms. 18.1

Categorizing

18.1.1

General 18.1.1.1 Process and designated system alarms shall be annunciated, displayed and stored in history files. Normal plant operator actions, events and normal system actions and events shall Page 46 of 67



not be alarmed, however, they shall be stored in history files if designated. Messages shall be categorized as: a)

Process alarms

b)

System alarms

c)

Operator actions

d)

Engineer actions

18.1.1.2 Alarms and messages shall be grouped to allow the user to readily identify and respond to alarms and conditions (e.g., in priority sequence) in his area of responsibility. 18.1.1.3 Alarms shall be further categorized by at least four priority levels. 18.1.1.4 Alarms shall be configured according to the guidelines contained in SAER-5895, "Alarm Management Guideline for Process Automation Systems." 18.1.2

Operator Actions It shall be possible to store all operator actions that affect process control parameters or alarm acknowledgment in history files, including:

18.1.3

a)

Inhibit/enable alarm

b)

Change mode of controllers

c)

Change setpoint of controllers

d)

Changes to alarm limits.

Engineer Actions It shall be possible to store all engineer actions that change the control and monitoring of the process in history files. These actions shall include the following:

18.2

a)

Placing stations and devices on-line or off-line.

b)

Download of point configurations.

c)

Download of configuration data to any on-line controller or FF device.

d)

Changes to tuning parameters.

Process Alarm Initiation

Page 47 of 67



18.2.1

It shall be possible to initiate process alarms by configuring alarm attributes of any process I/O point or any DCS point calculated from process I/O.

18.2.2

To minimize analog input "chattering" (a point going in and out of an alarm condition rapidly) there shall be configurable alarm dead band parameters, on a per tag basis.

18.2.3

For analog tags, the configurable triggers for process alarms shall include:

18.2.4

18.2.5

18.3

23-SAMSS-010

a)

Process variable high high limit exceeded

b)

Process variable high limit exceeded

c)

Process variable low limit exceeded

d)

Process variable low low limit exceeded

e)

Process variable rate-of-change high

f)

Process variable deviation from setpoint

g)

Process variable bad or invalid value

For discrete tags, the configurable triggers for process alarms shall include: a)

either state

b)

change of state.

Alarm Processing a)

It shall be possible to manually inhibit and restore alarm processing on a point-by-point and a group basis. Other system processing such as data acquisition, control and logging shall continue.

b)

It shall be possible to automatically inhibit and restore alarm processing point-by-point based on a flag (true or false), a discrete input status or the mode status of a control loop.

18.2.6

The system shall be capable of inhibiting any alarm based upon the prior occurrence of another alarm.

18.2.7

It shall be possible to display and print a list of inhibited alarms.

System Alarm Initiation

18.3.1

All devices connected to the DCS communication network shall be monitored for loss of communications and hardware failures. A system alarm shall be generated for each failure detected.

18.3.2

System alarms shall be triggered by: Page 48 of 67


a)

Failed modules

b)

Communication errors

c)

Diagnostic errors

d)

Power Supply modules

e)

Cabinet high temperature


Items d and e above may be connected as regular discrete inputs and treated as "process alarms." 18.4

18.5

Process and System Alarms Audible Annunciation

18.4.1

Alarms shall cause audible annunciation at, and only at, workstations configured for those alarms.

18.4.2

The annunciation shall occur within 1 second of the initiating event.

18.4.3

The audible annunciation shall continue until a "Horn Silence" command is issued by the operator.

18.4.4

There shall be at least three audible alarm tones available and these shall be assignable to any priority level.

18.4.5

Volume of the audible tones shall be adjustable.

18.4.6

If an audible alarm is on and another alarm of higher priority is initiated, then the tone of the higher priority alarm shall immediately sound. The lower priority audible tone may either continue or cease.

18.4.7

Return-to-normal state shall not cause audible annunciation.

18.4.8

There shall be a "Horn Silence" command available regardless of which display is in use.

18.4.9

When the "Horn Silence" command is given at a workstation, it shall silence the current audible alarm sound at all workstations within that console only and without acknowledging the alarm itself.

Process and System Alarms Visible Annunciation

18.5.1

General 18.5.1.1 Alarms shall cause visible display annunciation at, and only at, Workstations configured for those alarms. 18.5.1.2 Visible indication of an alarm condition shall occur within two (2) seconds of the initiating event. 18.5.1.3 It shall be possible to display the most recent process alarm within the primary operator window regardless of which display is in use.

Page 49 of 67


18.5.2


Overall Indications 18.5.2.1 There shall be an indication of the overall process alarm status of the operator area regardless of which display is in use. Commentary Note: LED on keyboard or dedicated section of the workstation monitor are acceptable.

18.5.2.2 There shall be a separate indication of the overall system alarm status of the entire DCS regardless of which display is in use. 18.5.2.3 The above indications shall convey whether alarms are present, the highest priority of the alarms present, and whether any alarms are unacknowledged. 18.6

Alarms Summary Display

18.6.1

There shall be a summary display of active process alarms.

18.6.2

It shall be possible to display, as a minimum, 200 alarms in an alarm summary. Multi-page displays may be used. If so, it shall be possible to page forward or backward by a single operator action. The display shall list alarms in tabular format in order of occurrence with the most recent at the top.

18.6.3

Accessing this alarm summary display from any other display shall require no more than one operator action.

18.6.4

Visible display of any alarm shall not clear from the alarm summary display unless the alarm is acknowledged and the item initiating the alarm has returned to normal condition.

18.6.5

It shall be possible to display the following information, as a minimum, for each alarm in the alarm summary display: a)

Tag ID of item in alarm.

b)

Tag Description.

c)

Alarm Type (HI/LO/HH/etc).

d)

Alarm Limit value.

e)

Engineering units (if applicable).

f)

Actual process value at time of alarm.

g)

Time of occurrence.

h)

Alarm description.

Page 50 of 67


18.6.6

18.7


i)

Alarm priority.

j)

Alarm state (whether into-alarm state or return-to-normal state).

k)

Acknowledgment state.

It shall be possible to filter or sort entries in the alarm summary display based on Tag ID, time of occurrence, priority, alarm type, and process area or unit number. The alarm summary display shall clearly indicate when filtering or sorting is active.

Alarm Acknowledgement

18.7.1

18.8

23-SAMSS-010

Acknowledgement of alarms shall be possible: a)

By page

b)

By individual alarm on the page

c)

By faceplate

18.7.2

It shall be possible to acknowledge process alarms only from workstations configured for those alarms.

18.7.3

It shall be possible for an operator to acknowledge any alarm configured at his workstation by no more than two actions.

18.7.4

It shall be possible to acknowledge alarms only if it is shown on a visible display.

18.7.5

It shall be possible to display unacknowledged alarms with a visibly distinct appearance from acknowledged alarms on standard displays (example, reverse flashing red).

18.7.6

It shall be possible to display alarms which are unacknowledged and have returned to normal with a visibly distinct appearance from unacknowledged, active alarms (example, reverse non-flashing red).

Process and System Alarms History Retention

18.8.1

All alarm information available at the alarm summary display shall be capable of being stored in history files.

18.8.2

All alarms shall be stored in history files with the capability to archive these to removable media.

18.8.3

Capability shall be provided to recall alarms in visible display lists according to selectable filtering options.

18.8.4

Capability shall be provided to print the resulting alarm displays to a printer or to export the data to text files or Microsoft ™ Office compatible file format.

Page 51 of 67


18.8.5


The system shall be capable of storing the following number of alarms and events as a minimum: Message Type

Number of Events

Process Alarms

9000

System Alarms

9000

Operator Actions

5000

System Engineer Actions

1000

Commentary Note: This does not require that these events be stored in the operator console.

19

Data Historization This section details the requirements for historical data characterization, collection, storage and use. 19.1

On-line History Collection and Storage

19.1.1

There shall be a configurable, real time and historical data collection package to support trending, logging, and reporting.

19.1.2

The system shall support the following historical data collection rates:

19.1.3

a)

1 or 2 second update

b)

10 second update

c)

1 minute update

The system shall provide the capability to calculate averages, maximum, minimum, and other statistics of raw historical data and store the results at the following intervals as a minimum: a)

5-10 minute

b)

Hourly

c)

Daily

d)

Monthly

19.1.4

The system shall support the addition and deletion of a point on-line without adversely effecting data collection for other points in the process historian.

19.1.5

It shall be possible to store on-line history data to redundant storage media.

19.1.6

When a process point is not available, an unavailable code shall be entered in the history file. Page 52 of 67


19.1.7


Analog Values It shall be possible to store the value of any of the following parameters in on-line history storage:

19.1.8

a)

Process input values

b)

Calculated value

c)

Controller setpoint

d)

Controller output

Discrete Values It shall be possible to store the state of discrete inputs in the online history system.

19.2

Off-line History Storage

19.2.1

It shall be possible to export historical data to text file or Microsoft ™ Office compatible file format.

19.2.2

It shall be possible to archive raw historical data to removable media for long term data storage.

19.2.3

It shall be possible to recall and display any data that has been archived to removable media for long term data storage.

19.2.4

The system shall keep a record of data which is transferred to removable media. The record shall contain the timeframe of the data which has been transferred and the name of the file or storage area to which it has been transferred. Commentary Note: This functionality must be provided to enable the user to determine where data which has been archived from the system is stored. When a user wants to recall data which has been archived, they will typically only know the tagname and the timeframe in which they are interested. The system must be capable of informing the user of which archive file contains the data they are looking for.

20

Trend Displays 20.1

General

Unless stated otherwise, the requirements within this section apply to both realtime and historical trends. The system shall be capable of the following: 20.1.1

All operator workstations shall be capable of displaying trends.

20.1.2

The system shall have the capability to display operational trends in full-screen, ½ screen, ¼ screen, and 1/8 screen sizes.

Page 53 of 67



20.1.3

Each trend display shall consist of the plotted trend graph(s) accompanied by the display of trend parameters.

20.1.4

Text accompanying the trend shall show the following for each tag: tag ID, minimum scale value, maximum scale value, engineering units, current value and an abbreviated point description.

20.1.5

Consecutive trend data points shall be connected by straight lines.

20.1.6

If only one tag is on the trend display, the vertical axis shall be in engineering units. If multiple tags are on the trend display then the vertical axis shall be in either engineering units or in percent.

20.1.7

The engineering units for each tag shall be listed in a table if they are not shown on the vertical axis.

20.1.8

The time periods for trend displays shall be selectable. Time periods between 5 minutes and 4 days shall be available.

20.1.9

Real-time and historical trends shall be available on the same display (same Monitor) simultaneously.

20.1.10 Each trend display shall be capable of displaying four different tags simultaneously. Each tag shall be represented by a different color. 20.1.11 It shall be possible to display actual process values for a particular point in time on a trend display by selecting the appropriate position on the trend graph. 20.1.12 It shall be possible to incorporate trends in graphic displays. Commentary Note: A pre-configured target incorporated in the graphic display which calls up the associated trend display is acceptable.

20.1.13 Groups of pre-defined trend sets shall be available. These trend sets shall define a set of one or more tags to be trended and the scaling to be used for each tag. 20.1.14 It shall be possible to configure up to 100 trend sets per operator console. These trend sets shall be available at any operator workstation in the same console. It shall be possible to display any trend set by no more than two operator actions. 20.1.15 It shall be possible to reserve ten of the above trend sets for operator defined groupings, with the access level being Process Operator or above. 20.2

Real Time Trends

Page 54 of 67


20.3


20.2.1

A real time trend feature shall be provided to make it possible for an operator to initiate a real time trend for any process tag or calculated variable, including both analog and discrete types.

20.2.2

Real time trends shall be updated every two seconds with actual process data.

Historical Trends

It shall be possible to initiate historical trend displays for any process tag or calculated variable that has been stored in either the on-line history or off-line history media, including both analog and discrete types. 20.4

Advanced Trending

A trending package shall be available which enables the user to analyze history data saved on the system. The advanced trending package does not need to be integral to the primary operator interface of the system. Trend graphs can be displayed in a separate window from primary operator interface.

21

20.4.1

The advanced trending package must have the following capabilities:

20.4.2

Capability to add or delete tags to a trend on a temporary basis.

20.4.3

Capability to display in numerical format the actual process value for all lines on the trend for a particular point in time.

20.4.4

Capability to search for tags which can be trended by using wildcards.

20.4.5

Capability to scroll backwards or forward in time.

20.4.6

Capability to auto-scale the y-axis on a trend.

20.4.7

Capability to zoom-in or zoom-out on the trend.

20.4.8

Capability to view multiple trendlines on the same trend in either banded or un-banded format.

20.4.9

Capability to export trend data, for external processing, to removable media in a Microsoft ™ Office compatible format.

Reports 21.1

It shall be possible to use any variable in the system or the history files in a report. It shall be possible for all reports to be displayed on a workstation screen as well as printed on a report printer.

21.2

Reports to the same device are to be queued.

21.3

Out-of-range and unknown status inputs and associated calculated blocks shall be flagged by a special character such as a question mark or other reserved symbol. Numerical values shall not be used.

Page 55 of 67



21.4

The default location for the report printouts shall be the operator console from which the report was requested.

21.5

It shall be possible to activate a report by: a)

Demand (operator request)

b)

Scheduled (shift, daily and monthly)

c)

Triggered by an Event

d)

Through automation or scripting

21.6

It shall be possible to dedicate printers for reports only.

21.7

It shall be possible to print user-defined reports to a report printer and at least one bulk storage device.

21.8

Reports saved to bulk storage shall be capable of being recalled and displayed at the operator workstations.

21.9

It shall be possible to export reports, for external processing, to removable media in a Microsoft ™ Office compatible file format.

21.10 Users Guides and Maintenance manuals shall be provided for all report packages.

22

External Interface 22.1

22.2

General

22.1.1

The system shall provide automatic communication retries for any malfunction occurring during message transfers.

22.1.2

Recoverable and unrecoverable communications errors shall be counted by the system for each communications channel and stored in a history file.

22.1.3

Unrecoverable communications shall be alarmed and shall be logged on a printer and stored in a history file with an appropriate failure message.

22.1.4

Failures of external systems shall not degrade the performance or functionality of the DCS.

External DCS communications

The system shall have the capability to communicate with external DCS systems as defined below. This functionality shall be provided using standard vendor supplied software packages. 22.2.1

The system shall be capable of transmitting real-time process data for any tag in the system to the external DCS.

Page 56 of 67


22.3


22.2.2

The system shall be capable of receiving real-time process data from the external DCS and translating this data into an internal tag which is capable of being accessed via the standard internal communications subsystem.

22.2.3

The system shall be capable of transmitting alarm and event data to external DCS systems.

22.2.4

The system shall be capable of receiving alarm and event data from external DCS systems for storage in the alarm and event history database.

Auxiliary Control Systems communications

The system shall have the capability to communicate to external auxiliary control systems as defined below: 22.3.1

The system shall support communications using Modbus Serial protocol in RTU or ASCII mode. Communications implemented over modbus serial shall support RS-232C, RS-422, and RS-485 interface with full or half-duplex operation using the following configurable baud rates: 9600, 19,200, and 38,800.

22.3.2

The system shall support communications using Modbus TCP/IP protocol at either 10 or 100 Mbps. Commentary Note: Modbus interfaces which are configured in a master-slave relationship shall be configured with the DCS interface module as the master.

22.4

22.3.3

The system shall be capable of reading, as a minimum, 1000 data registers from an external device using modbus serial and modbus TCP/IP protocol.

22.3.4

The system shall support communications using OPC DA 2.0 or greater. The system shall be capable of receiving real-time process data from the external auxiliary control system using OPC and translating this data into an internal tag which is capable of being accessed via the standard internal communications subsystem.

22.3.5

Communications to ESD and BMS systems for real-time process data shall be via dedicated, redundant communications paths. The DCS shall NOT communicate real-time process data to more than one ESD or BMS system over the same communications path.

MIS Systems communications

The system shall have the capability to communicate with external computer systems as defined below:

Page 57 of 67


22.5


22.4.1

Communications shall be via standard switched Ethernet networking components using TCP/IP protocol at 10 Mbps or greater.

22.4.2

The system shall have a standard software interface for transmitting data to Oil System's Inc. PI process historian.

22.4.3

The system shall have the capability to communicate real-time process data for any tag in the system through an OPC Server which supports the OPC DA specification revision 2.0 or greater.

Supervisory Systems

The system shall be capable of integrating supervisory systems such as Expert systems or MVC applications as defined below. The FSD shall state whether this capability is required for an individual project. 22.5.1

22.5.2

The supervisory system shall have access privilege to the complete database, with privileges to change the following: a)

Alarm limits

b)

Tuning parameters

c)

Inputs to sequence blocks

d)

Point status

e)

Application schemes

f)

Controller mode

g)

Controller setpoint.

High-Level Control Programming The ability to generate application software with a high level language shall be provided. This language shall have the capability and functions which are specified below. 22.5.2.1 A full screen text editor shall be provided for generating and editing application software. 22.5.2.2 Access to the database by a high-level program shall be by tag ID and parameter. 22.5.2.3 Compilation of programs without alteration of on-line versions shall be possible. 22.5.2.4 On-line, run-time errors shall be reported by program name and host module.

22.6

Remote Dial-In connection

Page 58 of 67



The system shall support the ability to establish a remote session into the system using a dial-in access modem. The dial-in connection shall be capable of providing the following functionality:

23

22.6.1

The ability to view data in real-time on process graphics, standard graphics and faceplates.

22.6.2

The ability to view system diagnostics displays.

22.6.3

The ability to establish a remote terminal session on a workstation connected to the system.

22.6.4

The ability to transfer files To and From the DCS.

22.6.5

The ability to execute system diagnostics routines on the DCS.

Inspection and Testing Saudi Aramco Inspection Requirements Form 175-230100 lists all system components that are subject to verification by buyer's representative. 23.1

Standard Hardware

Standard hardware shall be inspected and tested. Testing shall be in accordance with the manufacturers standard test procedures for system diagnostics. 23.2

24

Integrated Systems

23.2.1

Integrated systems that are staged at a vendor's facilities shall be tested according to Factory Acceptance Test (FAT) procedures produced for each DCS project.

23.2.2

FAT criteria shall be developed by the vendor and approved by Saudi Aramco.

Documentation 24.1

All engineering drawings shall comply with the requirements defined in SAEP-334, Retrieval, Certification and Submittal of Saudi Aramco Engineering & Vendor Drawings.

24.2

The following documentation shall be supplied by the vendor as part of the project deliverables: 24.2.1

601 NMRS 601.1

System Development Plan

601.2

System Design Document

601.3

Integration Specifications Document

601.4

Bill of Materials

601.5

Dimensional Outline Diagrams Page 59 of 67


24.2.2


601.6

Panel Front and Back Layout Diagrams

601.7

Electric Power Distribution Diagram

601.8

Factory Acceptance Test Plan

601.9

Integration Test Plan

601.10

Site Acceptance Test Plan

601.11

Configuration and Graphics Guidelines

601.12

Power Requirements

601.13

HVAC Requirements

601.14

Air Purity Requirements

601.15

Required Floor Loading

601.16

Composite Engineering, Manufacturing and Testing Schedule

602 NMRS 602.1

System Development Plan (Revised)

602.2

System Design Document (Revised)

602.3

Integration Specifications Document (Revised)

602.4

Bill of Materials (Revised)

602.5

Dimensional Outline Diagrams (Revised)

602.6

Panel Front and Back Layout Diagrams (Revised)

602.7

Electric Power Distribution Diagram (Revised)

602.8

Factory Acceptance Test Procedure

602.9

Integration Test Procedure (Revised)

602.10

Site Acceptance Test Procedure

602.11

Configuration and Graphics Guidelines (Revised)

602.12

Installation/ Check-out Plan

602.13

System Performance Specifications

602.14

List of all deviations from Purchase Requisition with Suggested Alternatives

602.15

List of Special Tools, Devices, and Test Equipment Required for Installation

602.16

Functional Test Certificates

Page 60 of 67

23-SAMSS-010

Recommend Documents