23 Samss 010

Materials System Specification
23-SAMSS-010 28 February 2005

Distributed Control Systems
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 Scope............................................................. 2
2 Conflicts and Deviations................................. 2
3 References..................................................... 3
4 Definitions...................................................... 4
5 Environmental Conditions.............................. 9
6 General......................................................... 11
7 Electrical Requirements............................... 15
8 Cabinets and Consoles................................ 18
9 Inputs and Outputs....................................... 21
10 Workstations................................................. 25
11 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 Page 1 of 1
Primary contact: John A. Kinsley on 873-0952
Document Responsibility: Process Control 23-SAMSS-010
Issue Date: 28 February 2005
Next Planned Update: 1 March 2010 Distributed Control Systems
13 Control and Data Handling........................... 32

14 Configuration and Database......................... 40
15 Security......................................................... 43
16 Diagnostics................................................... 46
17 Displays and Graphics................................. 47
18 Alarm and Message Handling...................... 51
19 Data Historization......................................... 57
20 Trend Displays.............................................. 58
21 Reports......................................................... 61
22 External Interface......................................... 61
23 Inspection and Testing................................. 65
24 Documentation............................................. 65
1 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.
2 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.
3 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 Nonmaterial Requirements for Control Cabinets
3.2 Industry Codes and Standards
American Society for Testing and Materials
ASTM E1137 Standard Specification for Industrial Platinum
Resistance Thermometers
International Electrotechnical Commission
IEC 60751 Industrial Platinum Resistance Thermometer
Sensors
IEC 61000-6-2 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 Reliability Prediction Procedure for Electronic
Equipment - Telcordia Technologies
4 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
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
4.2 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 4-
20mA 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 (1)
b) Ambient relative humidity: 20% to 80%.
Page 8 of 67
Note:
1) 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.
5.2 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:
• Outdoor Sheltered = 0 °C to 55 °C (1)(2)
• Outdoor Unsheltered = 0 °C to 65 °C (2)(3)
b) Ambient relative humidity: 5% to 95% non-condensing.
Notes:
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.
5.2.2 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
• 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)
5.2.3 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:
a) Temperature: 0 to 55°C.
b) Relative humidity (outside the moisture proof container): 10 to 90%.
6 General
6.1 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.
6.2 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 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.
6.3 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.
6.4 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 Withdrawal of product support for DCS vendor manufactured products
shall be notified in writing to Saudi Aramco twelve months in advance.
6.5 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 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
6.6 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 above 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.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 daisy-
chained 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-SAMSS-
820.
7.3.3 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.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.
7.3.4 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.
8 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 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.
8.4 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 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.
8.5 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 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.
8.6 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.
8.7 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 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.
9.2 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 open-
circuit 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 Discrete Input

9.3.1 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.
9.4 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
b) Single pulse, (configurable width).

c) Latching and non-latching (momentary) contact outputs
9.5.2 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.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.
9.7 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 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.
10.2 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.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.
10.3 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) 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.
10.4 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.
10.5 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.
11 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
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.
12 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 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
12.2.2 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 All supported FF HIST features shall be integrated seamlessly into the
existing control system's engineering, configuration, maintenance, and
operations system.
12.3 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.
12.4 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.
12.5 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.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.
12.6 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.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.
12.7 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
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.
13 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) 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
13.1.4 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
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
13.1.5 Output Functions
The following output functions shall be supplied as standard
configurable items:
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
13.1.6 Discrete Control
The following discrete control functions shall be supplied as standard
configurable items:
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
13.1.7 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 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.
13.2 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) Local/remote setpoint switching.

13.3 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) 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.
13.4.2 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.
13.5 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.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.
13.6 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.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.
13.7 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) Relational expressions:
- Equal to
- Not equal to
- Less than
- Less than or equal
- Greater than
- Greater than or equal
- IF / IF Then.
b) Calculations:
- Add
- Subtract
- Multiply
- Divide
- Exponentiation (whole and fractional)
- Square root
c) Timers:
- Output true after preset delay
- Output false after preset delay
d) Counters:
- Count up
- Count down
e) 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
h) Skip 1 or more steps

i) Restart at beginning
14 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 All tags shall be defined with at least the following parameters:
a) Tag ID
b) Tag descriptor
c) Tag type
d) Alarm requirements
14.2.2 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.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.
14.3 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:
a) tag ID
b) tag descriptor
c) point type
d) hardware address
14.3.3 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
15 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 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 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.
15.3 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.4.1 The system shall be capable of running commercially available anti-
virus software protection packages (such as MacAfee or Norton anti-
virus) 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.
15.5 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) Software and firmware (if applicable) version of all modules
installed in the system.
16.2 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.
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.
17 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 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.
17.3 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.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.
17.4 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 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.
18 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:
a) Inhibit/enable alarm
b) Change mode of controllers
c) Change setpoint of controllers
d) Changes to alarm limits.
18.1.3 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:
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.
18.2 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:
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
18.2.4 For discrete tags, the configurable triggers for process alarms shall
include:
a) either state
b) change of state.
18.2.5 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.
18.3 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 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.
18.5 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
i) Alarm priority.
j) Alarm state (whether into-alarm state or return-to-normal state).
k) Acknowledgment state.
18.6.6 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.
18.7 Alarm Acknowledgement
18.7.1 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).
18.8 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:
a) 1 or 2 second update
b) 10 second update
c) 1 minute update
19.1.3 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:
a) Process input values
b) Calculated value
c) Controller setpoint
d) Controller output
19.1.8 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 real-
time 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.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.
20.3 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.
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.
21 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 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.
22.2 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.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.
22.3 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.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.
22.4 MIS Systems communications
The system shall have the capability to communicate with external computer
systems as defined below:
Page 57 of 67
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.
22.5 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 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.
22.5.2 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:
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.
23 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 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.
24 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
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
24.2.2 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
24.2.3 603 NMRS

603.1 System Performance Specifications
603.2 Installation Instructions
603.3 Operating Instructions
603.4 Maintenance Manuals
603.5 Certified Test Reports, and Certificates
24.3 All documentation shall be in English.
24.4 Word processor or text files of all application software documentation shall be
provided on removable electronic media in addition to printed hard copies.
24.5 Three (3) backup copies on electronic media shall be provided of all system
software, application software, and system configuration post SAT. The format
and media of these copies shall be such that they can be loaded directly into the
system without additional translation or data manipulation.
Revision Summary
28 February 2005 Major revision.
Page 61 of 67

23 Samss 010

Uploaded by

Copyright:

Available Formats

23 Samss 010

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

23 Samss 010

Uploaded by

Copyright:

Available Formats

Materials System Specification

23-SAMSS-010 28 February 2005

Saudi Aramco DeskTop Standards

Table of Contents (cont'd)

Previous Issue: 31 October 1999 Next Planned Update: 1 March 2010

13 Control and Data Handling........................... 32

IEC 61000-4-3 Testing and measurement techniques – Radiated,

Configurable: The capability to select and connect standard hardware modules

Redundant Configuration: A system/subsystem configuration that provides

5.2 Outdoor Environment

5.2.2 All equipment specified for outdoor installation shall be compliant

• Hydrocarbon 150 ppm (vol/vol)

It is acceptable for a system to contain different revision levels of a

Outputs used for regulatory control in critical applications shall be

Process controllers and input/output modules 300,000 hours

7.3.2 Power Distribution within DCS Cabinets

7.3.3.3 Workstations which are not supplied in a redundant

8.5.3 Cabinets which house power supply modules shall be capable of

9.3 Discrete Input

b) Single pulse, (configurable width).

9.6.5 The system shall be capable of displaying configuration data resident

j) Utility program access.

12.5.7 Displaying individual macro cycles in graphical format showing block

12.7.2 Engineering, configuration, maintenance and operational features shall

g) Dead band on a per loop basis

It shall be possible to select the execution frequency of each control

b) Local/remote setpoint switching.

c) The control block output is cascaded to the remote setpoint of a

Windup protection is the ability of a control function block which contains

The following sequential functions shall be supplied as standard

h) Skip 1 or more steps

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

configuration tools and system diagnostics tools accessible to the

password within the password aging period shall be locked

17.4.12 It shall be possible to display numeric data in dynamic vertical bar

not be alarmed, however, they shall be stored in history files

18.2.1 It shall be possible to initiate process alarms by configuring alarm

18.5.2 Overall Indications

Message Type Number of Events

19.1.7 Analog Values

22.4.1 Communications shall be via standard switched Ethernet networking

601.6 Panel Front and Back Layout Diagrams

24.2.3 603 NMRS

You might also like