23 Samss 020

Materials System Specification
23-SAMSS-020 1 January 2018

Supervisory Control and Data Acquisition (SCADA) Systems
Document Responsibility: Process Control Standards Committee
Contents
1 Scope ............................................................2
2 Conflicts and Deviations ..................................2
3 References .....................................................2
4 Definitions ......................................................3
5 General Requirements ....................................6
6 System Requirements .....................................8
7 Functional Requirements ............................... 14
8 Configuration Requirements .......................... 28
9 Hardware ..................................................... 34
10 Security and System Access .......................... 36
11 Engineering Tools ......................................... 42
12 Environmental Conditions .............................. 43
13 Electrical Requirements ................................. 43
14 Documentation.............................................. 43
15 Inspection and Testing .................................. 44
Revision Summary............................................... 44
Previous Issue: 14 March 2017 Next Planned Update: 16 January 2019

Revised paragraphs are indicated in the right margin Page 1 of 44
Contact: Khalifah, Abdullah H. (khalah0i) on phone +966-13-8801830
©Saudi Aramco 2017. All rights reserved.

Document Responsibility: Process Control Standards Committee 23-SAMSS-020
Issue Date: 1 January 2018
Next Planned Update: 16 January 2019 Supervisory Control and Data Acquisition (SCADA) Systems
1 Scope
This specification defines the minimum mandatory requirements for Supervisory

Control and Data Acquisition (SCADA) systems for oil & gas and utility applications.
The SCADA, referenced as system in this document, is a system primarily intended for
data acquisition, remote and supervisory control over a wide geographically confined
area.
1.1 This specification applies to all SCADA equipment and associated software
required to remotely control (supervisory) and monitors a process plant.
This document excludes Remote Terminal Units (covered by 23-SAMSS-030),

distributed control systems (covered by 23-SAMSS-010), auxiliary systems,
Management Information Systems and field instrumentation.
1.2 Where a project Functional Specification Document (FSD) calls for an

integrated control system and SCADA, this specification shall apply to the
SCADA portion of the system.
1.3 Project functional requirements shall be stated in the individual project FSD or
related documents while this specification will serve as the minimum mandatory
requirements.
1.4 In addition to this specification, SAES-Z-004 “Supervisory Control and Data

Acquisition Systems” requirements shall apply to the SCADA system.
2 Conflicts and Deviations
Any conflicts between this document and other applicable Mandatory Saudi Aramco
Engineering Requirements (MSAERs) shall be addressed to the EK&RD Coordinator.
Any deviation from the requirements herein shall follow internal company procedure
SAEP-302.
3 References
Material or equipment supplied to this specification shall comply with the latest edition
of the references listed below, unless otherwise noted.
3.1 Saudi Aramco References
Saudi Aramco Engineering Procedures

SAEP-302 Waiver of a Mandatory Saudi Aramco Engineering
Requirement
SAEP-750 Testing Procedures for Process Automation Systems
Saudi Aramco: Company General Use
Page 2 of 44
Saudi Aramco Engineering Standards

SAES-J-003 Instrumentation and Control Buildings - Basic
Design Criteria
SAES-Z-001 Process Control Systems
SAES-Z-004 Supervisory Control and Data Acquisition (SCADA)
System
Saudi Aramco Materials System Specification

34-SAMSS-820 Instrument Control Cabinets - Indoor
Saudi Aramco Inspection Requirements

Form 175-230200 Supervisory Control and Data Acquisition (SCADA)
System
3.2 Industry Codes and Standards
American Petroleum Institute

API MPMS 21.1 Manual of Petroleum Measurement Standards
Chapter 21 - Flow Measurement Using
Electronic Metering Systems Section 1 -
Electronic Gas Measurement
Internet Architecture Board

RFC 793/791 Compliant Standard is for TCP/IP (TCP Running
Over IP) for Client/Server Applications
International Electrotechnical Commission

IEC 60870-5-101 Transmission Protocols, Companion Standard for
Basic Telecontrol Tasks
IEC 60870-5-104 Transmission Protocols - Network Access for
IEC 60870-5-101 Using Standard Transport
Profiles
IEC 61709 Electronic Components - Reliability - Reference
Conditions for Failure Rates and Stress Models
for Conversion
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
Page 3 of 44
“Comprehensive Dictionary of Measurement and Control”, International Society for

Measurement and Control, shall apply.
4.1 Acronyms and Abbreviations

API Application Program Interface
BSAP Bristol Standard Asynchronous Protocol
CAD Computer Aided Design
DA Data Access
DNP Distributed Network Protocol
FAT Factory Acceptance Test
GUI Graphical User Interface
GPS Global Positioning Satellites
HDA Historical Data Access
JDBC Java Database Connectivity
LAN Local Area Network
ODBC Open Database Connectivity
OPC OLE for Process Control
PC Personal Computer
PLC Programmable Logic Controller
RFI Radio Frequency Interference
RTU Remote Terminal Unit
SAT Site Acceptance Test
SCADA Supervisory Control and Data Acquisitions
SQL Structured Query Language
TCP/IP Transmission Control Protocol / Internet Protocol
UA Unified Architecture
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.

Page 4 of 44
Auxiliary System: A control and/or monitoring system that is stand-alone,

performs a specialized task, and communicates with the SCADA.
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.
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 SCADA and perform other functions.
Cyclic Polling (data request): The process by which a data acquisition system
selectively requests data from one or more of its RTUs. An RTU may be
requested to respond with all, or a selected portion of, the data available.
Dead Band: The range through which an input signal may be varied without
initiating an action or observable change in output signal.
Fault Tolerant: It is a system that identifies and compensates for failed control
system elements and allows repair while continuing an assigned task without
process interruption.
Firmware: Programs or instructions that are permanently stored in hardware

memory devices (usually read-only memory).
Module: An assembly of interconnected components that constitute 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.
Object Based Programming: A type of programming in which programmers

define not only the data type of a data structure, but also the types of operations
(functions) that can be applied to the data structure. In this way, the data
structure becomes an object that includes both data and functions. In addition,
programmers can create relationships between one object and another.
For example, objects can inherit characteristics from other objects.
Protocol: A strict procedure required to initiate and maintain communication

with the RTU or a PLC. Open Industry Standard communication protocol is
Page 5 of 44
defined as a protocol that has a published specification and available for all
suppliers to read and implement and will not lock the customer into a particular
vendor or group. The Protocol may be extended, or offered in subset form and
supported by publication of reference information.
Redundant Configuration: A system/subsystem configuration that provides

automatic switchover, in the event of a failure, without loss of a system function.
Report-by-Exception: The reporting of data (e.g., from RTU to master station)

only when the data either changes state (e.g., for a status or digital input point)
or exceeds a predefined deadband (e.g., for an analog input point).
Resolution: The least value of the measured quantity that can be distinguished.
Self-diagnostics: Programs automatically executed, at predetermined intervals,

in the master station or RTU, to check the health of the system.
System Alarm: Alarm that occurs as a result of a SCADA hardware or

software fault.
System Operating Software: The vendor's standard software that performs the
basic functions of the system.
Tag: The unique alphanumeric code assigned to point such as inputs, outputs,
equipment items, and control blocks. The tag 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 General Requirements
5.1 Use and Compliance to Open Standards
5.1.1 The Supervisory Control and Data Acquisition (SCADA) system shall
be designed based on Commercial-Off-The-Shelf (COTS) hardware,
software, firmware, and vendor standard application packages.
5.1.2 All supplied hardware, firmware, and software (excluding application

software) shall be field-proven prior to the hardware freeze date.
Commentary Note:
Application software that is written for project specific control and

monitoring strategies is not required to be field proven. The exclusion
of application software from the field proven requirement is not
intended to exclude software for standard functions.

Page 6 of 44
5.1.3 A vendor's standard SCADA base software shall not be modified to

meet any of Saudi Aramco's requirements.
5.2 Field Proven Systems
All supplied hardware, firmware, and software (excluding application software)

shall be field proven prior to the hardware freeze date. Field proven is defined
as successful operation at a field installation for at least six (6) months or more
(excluding beta test period). It shall be possible for Saudi Aramco to verify the
field proven status of the system.
Commentary Note:
Application software that is written for project specific control and monitoring
strategies cannot be field proven prior to the hardware freeze date. The exclusion
of application software is not intended to provide exclusion for software written to
perform standard functions.
5.3 Software Protection
5.3.1 No software or hardware locking mechanisms that restrict the user

from copying the application software source code or compiled
executable code from the storage media shall be employed.
5.3.2 No software or hardware locking mechanisms that restrict the user

from booting (starting up) shall be employed.
5.3.3 System's operation and maintenance shall not be dependent on license

renewal.
5.4 Software Revision
5.4.1 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.
5.4.2 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
Page 7 of 44
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.
5.5 System Support
5.5.1 The SCADA vendor shall guarantee to support all system hardware,
firmware, and software with spare parts and services for a period of ten
(10) years from the system delivery date or as defined in the contract or
purchase order for all proprietary components and software; and a
period of five (5) years for all commercial off-the-shelf products and
software supplied as part of the SCADA system. This support shall not
be contingent on the customer upgrading to later releases of software
or hardware unless this upgrade is supplied at no additional cost.
5.5.2 The vendor shall notify Saudi Aramco of product termination at least
2 years before the product is removed or discontinued from service,
support, and/or production.
6 System Requirements
The SCADA system shall support and operate efficiently over any type of
telecommunication technologies and any network topology. The selection of the
appropriate and applicable technology is outside the scope of this document.
6.1 General
6.1.1 The system components shall be capable of being integrated into open
distributed real time and historical data in client/server architecture.
6.1.2 The system shall be based on industry standard in-memory (IMDB),

Object Oriented Relational Database Management System (OR DBMS).
6.1.3 The system shall support structure and object oriented graphics and
alarms.
6.1.4 The system shall support building graphics and devices database and
alarms as objects that allows easy replication.
6.1.5 The system shall support integration to packages such as process

simulator, leak detection and other systems as defined in the FSD via
open connectivity standards such as ODBC, XML, ADO, OLEDB,
JDBC or OPC.

Page 8 of 44
6.1.6 Applications integrated with the SCADA system shall access all
process and calculated tags in the real time and historical database.
6.1.7 The system shall support association of any I/O point with specific
operational assets (i.e., objects).
6.1.8 The SCADA master station communication subsystem shall include

functionality to optimize and limit the number of open communication
ports. Number of open communication ports shall not degrade the
overall system performance.
6.2 Redundancy
6.2.1 The system shall support hardware and software redundancy as

standard offering. Redundancy shall include systems software
components as well as hardware components.
6.2.2 The system shall be robust. Single failure anywhere in the system shall
not result in loss of supervisory control or of operator's ability to view
or manipulate the process from a workstation.
6.2.3 The following are general redundancy requirements:

a) There shall be no effect on programs or tasks in progress when a
switch over to redundant server occurs.
b) There shall be no loss of field data when a switch over takes place
between a primary and a redundant server. The system shall
automatically upload and fetch all buffered data.
c) Redundant equipment and software shall be continuously
monitored for errors, raise system alarms, and failovers to back up
component on preset criteria.
d) Automatic switchover to backup equipment shall occur on
detection of failure of the primary equipment, with no operator
intervention and shall be fully functional within 30 seconds.
e) Failure of any primary or backup equipment shall be alarmed as a
system alarm and shall be logged. The alarm message with error
codes and explanation of failures shall be displayed.
f) The system shall support manual switch over between primary and
backup components.
g) Switch back to repaired equipment shall be permitted only after
the system diagnostics function has determined that the module is

Page 9 of 44
fully functional.
h) Automatic and manual switchover shall be displayed, logged, and
alarmed by the system.
i) The system shall continuously monitor and test all backup
equipment to determine whether the backup equipment is capable
of assuming primary equipment functions.
j) The system shall generate an alarm and log if the backup system is
incapable of assuming primary equipment functions.
k) A failure or malfunction of any operator workstation shall not
impact the overall system performance.
6.2.4 The system shall include communication modules, power supplies, and
processors in a redundant configuration. The system shall support
peripheral devices (i.e., disk drive, printer) redundancy.
6.3 Scalability
6.3.1 The system shall be modular in design. This means the same hardware
is used for small, medium, and large SCADA configurations, with
expansion being based on adding components.
6.3.2 The system shall be capable of being configured as standalone or

networked to other SCADA systems.
6.3.3 It shall be possible to expand the number of data communication

channels whether serial or over TCP/IP to meet future expansion
requirement without requiring additional licenses for protocol(s) that
is/are already installed on the system.
6.3.4 In case where system upgrade results in system failures, instability, or

loss of functionality, it shall be possible to revert back to older version
while retaining view and control of the process.
6.4 Flexibility
6.4.1 The system shall be capable of supporting hierarchical servers to

distribute the database and polling capabilities in several field
machines to minimize the impact of communications failures while a
consolidated real-time database is required for corporate access.
6.4.2 The system shall be capable of supporting Peer-to-Peer servers for

offsite hot backup where the offsite servers run in a different location.

Page 10 of 44
6.4.3 The SCADA system shall be capable to support distributed system

software, application software, and data in multiple workstation/server.
6.4.4 The system shall have the capabilities to utilize/Interface with

Relational Databases.
6.4.5 The system shall provide a Graphical User Interface (GUI) that supports
window management such as OSF-Motif, Xwindows and MS Windows.
6.4.6 The system shall have the capability to time synchronize to/from
external clock source, e.g., GPS.
6.4.7 The system shall have the capability to time synchronize all connected
RTUs and Subsystem. Time deviation shall not exceed 100 msecond.
6.4.8 System back-up shall be automatic or by command from an engineering

workstation. The automatic system back up capability, from a central
location, shall be available with the user-friendly graphical interface.
6.5 Reliability
6.5.1 SCADA system shall include communication network management

functions capable of blocking network flooding generated by a faulty
communication device which may cause network jamming or
degradation of the system performance.
6.5.2 It shall be possible to expand the SCADA system by adding additional

servers and RTUs without the need to shut down the entire system
during the expansion process.
6.5.3 The system shall be capable of upgrading the system operating software
and application software on all redundant modules and software
components without the necessity of shutting down SCADA system or
the process, without losing the operator interface, and without the loss of
access to any control function for more than 30 seconds.
6.5.4 SCADA host shall have the capability to upload all data stored in the
RTU memory (Buffer), after restoring the communication where
supported by the communication protocol. Uploaded data shall be
fetched with the correct time stamp to the SCADA database.
6.5.5 Equipment supplied as part of the SCADA system shall meet or exceed
the MTBF data specified in the table below at the equipment's design
temperature.

Page 11 of 44
Power Supply modules 150,000 hours

Commercial off-the-shelf networking
100,000 hours
or communications equipment
All other electronic modules 200,000 hours
The MTBF figures shall be “Predicted” data calculated using and in

accordance to IEC 61709.
6.5.6 Replacement of any failed workstation or printer shall not affect the
operations of the plant.
6.5.7 CPU utilization of the SCADA Servers and workstations shall not
exceed 30% during normal operations and shall not exceed 75% for a
period of 5 seconds during initial startup.
6.6 Network
6.6.1 The system shall support distributed network equipment such as

terminal servers, communication servers, network printers, network
workstations, mass storage/backup devices.
6.6.2 The system shall network its nodes using non-proprietary industrial
standards such as Ethernet (i.e., TCP/IP).
6.6.3 All servers, computers, and peripherals shall be connected using dual
and redundant high-speed LAN interfaces. The system LAN shall be
fault tolerant utilizing a network configuration that prevents a single
point of failure.
6.6.4 The system shall allow access to any device from any computer in the
system with appropriate access authority.
6.6.5 The system shall support peripherals connected directly to the LAN,
connected to the LAN via servers, or attached to a workstation serial
port.
6.6.6 The SCADA master station communication subsystem shall include

standard feature to manage and effectively use the RTU primary and
the backup communication channels.
6.6.7 The SCADA master station communication subsystem shall support

redundant communication link to access the redundant communication
Modules when provided at the RTU/PLC.

Page 12 of 44
6.6.8 The SCADA system shall provide access to all configurable

parameters of the communication protocol.
6.6.9 Unrecoverable communications shall be alarmed and shall be logged

and stored in a history file with an appropriate failure message.
6.7 Interface with 3rd Party Sub-systems
6.7.1 The Supervisory Control and Data Acquisition (SCADA) system shall
support Open Industry Standard protocol(s) as defined in this
document and shall include but not limited to Modbus ASCII, RTU
and TCP, DNP Serial, UDP and TCP level 4.
6.7.2 When requested in the project specification document, the Supervisory

Control and Data Acquisition (SCADA) system shall be cable to support
any additional communication drivers such as IEC 60870-5-101 and
IEC 60870-5-104.
6.7.3 The SCADA system shall support redundant OPC DA and OPC HDA
interface with applications and other systems.
6.7.4 The system shall provide user configurable scan rate for each
communication channel, for each RTU and for each data point.
6.7.5 The SCADA system shall have features to optimize data

communication over the following communication links:
a) Serial RS-232C, RS-422, and RS-485 with full and half-duplex
operation using 9600, 19200 and higher data transmission rates.
b) Standard Ethernet TCP/IP
c) Wireless data links such as UHF, GPRS and other higher speed
wireless data links.
6.7.6 The system shall support the following communication media for
communication with the RTU's: copper, coaxial, radios, microwave,
satellite, Ethernet, fiber optic, and dial up.
6.8 External Interface
6.8.1 Computer Communications
6.8.1.1 The system shall support communication to RTU as Local

Area Network (LAN), Wide Area Network (WAN) or
Wireless network.

Page 13 of 44
6.8.1.2 The system shall integrate with application programs using

TCP/IP as stated in RFC 793/791 at 100 Mbps or higher
6.8.1.3 The system shall have multi-protocol routers to provide Wide

Area Network connectivity.
6.8.1.4 The system shall provide an API to communicate to Plant

Information (PI) using OPC UA.
6.8.2 Inter-SCADA Communication
6.8.2.1 The system shall provide configurable, automatic

communication retries for any malfunction occurring during
message transfers.
6.8.2.2 Recoverable and unrecoverable communications errors shall

be counted by the system for each communications channel
and shall be logged and stored in a history file.
6.8.2.3 The system shall count number of requests sent, error

requests, scan overruns, bytes transmitted/re-transmitted,
bytes received/re-received, framing errors, timeouts, CRC
errors, as applicable to the protocol for each communication
channel, route, and RTU on the system.
6.8.2.4 The counts shall be available on per minute, last minute,

today, yesterday and as a total. It shall be possible to reset
the total count.
6.8.2.5 Unrecoverable communications shall be alarmed and shall be

logged on a printer and stored in a history file with an
appropriate failure message.
6.8.2.6 Failures of external systems shall be logged and shall not

degrade internal communications.
7 Functional Requirements
7.1 General
7.1.1 It shall be possible to assign Areas of Responsibilities (AOR) access

for specific operator workstation.
7.1.2 It shall be possible to change control assignments to allow control of

any plant area from any operator workstation by using the appropriate
access privilege level.
Page 14 of 44
7.1.3 On manual restart or re-initialization, it shall be possible to select

restart from the most recently saved operational data or from
previously saved data.
7.1.4 It shall be possible after loss of power and restoration of power to

reboot automatically with operating system and system database
without user intervention.
7.1.5 The SCADA system shall provide an Alarm if the Operator commands
initiation failed or no feedback response is received within the
configurable timeout of the communication protocol. If the system
fails to respond to a command, then a fail-to-operate event shall be
displayed.
7.1.6 When supported by the protocol, the system shall support Operator
commands based on a two way-pass Select and Check before operate
method.
7.1.7 The system shall be capable of updating calculation algorithms, and

dynamic fields of the displays within one second of actual recent event
received at the system from field RTUs.
7.2 Engineering
7.2.1 It shall be possible to perform all configuration, database generation,

graphics building/editing, and software linking/compiling from single
engineering workstation.
7.2.2 It shall be possible to support more than one engineering workstation

in the system.
7.2.3 It shall be possible to use multiple engineering workstations

simultaneously for configuration, database generation and editing.
The workstation resources shall be sized such that real-time
performance is not impacted.
7.2.4 Engineering workstations shall be capable of functioning as operator

workstations.
7.3 Data Acquisition
7.3.1 The systems shall support Analog, Status, Pulse Accumulator,

Sequence of Events and Digital output commands data acquisition and
processing as defined in SAES-Z-004.

Page 15 of 44
7.3.2 The system shall provide configurable parameter to allow polling data
on the communication channel from all connected devices (RTUs, PLC
or other connected subsystems), by group of devices and /or by point
level.
7.3.3 It shall be possible to set the polling parameters to values as low as

1 second.
7.3.4 The system shall be capable to support communication protocols that

are capable of scanning RTUs to retrieve point status in the following
modes:
 Cyclic polling
 Solicited and Unsolicited Report by exception
 On demand based on user specified time.
7.4 Supervisory Control
7.4.1 It shall be possible for supervisory control applications to be

scheduled, run on demand, or triggered by events.
7.4.2 The system or supervisory user-ID shall have access privileges to the
complete database, with privileges that include the following:
 Alarm limits
 Tuning parameters
 Inputs to sequence blocks
 Point status
 Application schemes
 Controller mode
 Controller set point
 Controller output
7.5 Alarm and Message Handling and Display
7.5.1 The SCADA system shall include a feature to minimize analog and
digital points “chattering” (a point going in and out of an alarm
condition rapidly) and shall be configurable dead band parameters, on
a per tag basis.
7.5.2 There shall be a summary display of active process alarms storable

by alarm type and priority for the operator's areas of responsibility.
The process alarm shall be colored based on the category.

Page 16 of 44
Accessing this alarm summary display from any other display or

graphics shall require no more than one operator action.
7.5.3 This display shall show all process alarms currently in alarm condition.
Visible display of any alarm shall not clear unless the alarm is
acknowledged; and the item initiating the alarm has returned to normal
condition.
7.5.4 Multi-page alarm summary displays shall include page forward or

backward and scroll up and down options.
7.5.5 There shall be a summary display of active system alarms.

This display shall show all devices currently in an alarm condition.
An alarm indication shall not be cleared unless the alarm has been
acknowledged and the device has returned to normal condition.
Accessing this alarm summary display from any other display or
graphics shall require no more than one operator action.
7.5.6 Operator shall be able to list all tags that have off scan status, alarms
disabled or inhibited, and manual status.
7.5.7 Operator shall be able to display alarms based on configurable fields

such as plant area, plant unit, etc.
7.5.8 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.
7.5.9 It shall be possible for operator to access/ take corrective action on any
displays with alarm by no more than two operator actions.
7.5.10 Alarms shall be further categorized by at least four priority levels.

The level shall be configurable at the point database level.
7.5.11 All events shall be stored in an event list. An event is any incident in
the system that is stored as a permanent record. Events include alarms,
status changes, and operator's actions including taking RTU Out Of
Scan, Put RTU Into Scan, Put RTU On Test, and Take RTU Off Test.
7.5.12 It shall be possible to store the additional Engineer actions that change
the control and monitoring of the process. These actions shall include
the following:
 Placing stations and devices on-line or off-line

 Download modification of point configurations

Page 17 of 44
 Upload of point configurations
7.5.13 For analog tags, the configurable triggers for process alarms shall
include:
 Process variable high limit exceeded.

 Process variable high high limit exceeded.
 Process variable low limit exceeded.
 Process variable low low limit exceeded.
 Process variable rate-of-change limit.
 Process variable deviation from set point
 Process variable invalid value.
 Point is faulty as loss of communication, out of service, etc.
7.5.14 For digital tags, the configurable triggers for process alarms shall
include:
 either state
 change of state
 Point is faulty as loss of communication, out of service, etc.
7.5.15 It shall be possible to inhibit and enable alarm processing on a point-

by-point and a group basis. Other system processing such as data
acquisition, control and logging shall continue.
7.5.16 Inhibited alarms shall be available to be displayed and printed.
7.5.17 All devices connected to the communication network including

redundant equipment shall be monitored for failures. A system alarm
shall be generated for each failure detected. An overall graphical
display showing the status of all the modules shall be available.
7.5.18 Alarms shall cause audible annunciation at, and only at, workstations
configured for those alarms.
7.5.19 The system shall have the capability to route alarms to another device.
7.5.20 The annunciation shall occur within one second of the detection of the
initiating event by the SCADA server.
7.5.21 The audible annunciation shall continue until a “Horn Silence” or

“alarm acknowledge” commands are issued by the operator.

Page 18 of 44
7.5.22 The audible annunciation system shall be an industrial type that cannot
be disabled or switched off easily. PC speakers shall not be used.
7.5.23 There shall be at least four audible alarm tones available and these
shall be assignable to any priority level. Volume of the audible tones
shall be adjustable.
7.5.24 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 will cease.
7.5.25 Return-to-normal state shall be configurable to cause or not cause

audible annunciation.
7.5.26 There shall be a “Horn Silence” command available regardless of

which display is in use.
7.5.27 Each alarm priority shall be configurable to be printed or not printed at

time of occurrence.
7.5.28 It shall be possible for system alarms to be logged on a printer separate

from the process alarm printer.
7.5.29 The operator workstation shall be capable to buffer at least 1000

alarms without need to retrieve such alarms from the data historian.
7.5.30 Alarm priorities shall be color coded per each priority in the display
and when priority level is printed.
7.5.31 The SCADA system shall be capable of performing advanced alarm

filtering and grouping.
7.5.32 The SCADA system shall alarm on the change of the process variable
(PV). It shall be possible to suppress all soft tag alarm associated with
hardwired signals.
7.6 Data Historization
There shall be a configurable, real time and historical data collection package to
support trending, logging, and reporting. This section details the requirements
for historical data characterization, collection, storage, and use.
7.6.1 It shall be possible to supply redundant on-line storage media.
7.6.2 When a process point is not available, an unavailable code shall be

entered in the history file.

Page 19 of 44
7.6.3 It shall be possible to store the value of any of the following

parameters in on-line history storage:
 process input/output values/status

 calculated value/state
 controller parameters such as set point, output, mode
 digital input/output states
 system events and alarms
7.6.4 The system shall support configurable historical data collection rates
ranging from point scan time to one hour averages. The system shall
also support the following rates:
 Shift averages
 Daily average
 Monthly average
 User-defined rate
7.6.5 The historical data collection package shall be capable of storing the
following number of recent discrete events as a minimum:
Event Type Capacity

Process Alarms 10,000
System Alarms 5,000
Operator Actions 5,000
Engineering Actions 5,000
The above listed entry shall include as minimum: time and date of the
event, associate tag, equipment, user, description of the event, and the
workstation on which the alarm has been acknowledged.
7.6.6 The system shall have the capability to configure historical data
archiving for a minimum of 12 month.
7.6.7 It shall be possible to transfer historical data to removable media for

long term historical data storage.
7.6.8 Data archiving for all data types shall be provided.
7.6.9 It shall be possible to recall and display any data that has been stored
on removable media. It shall be possible to transfer archived data in a

Page 20 of 44
format that can be displayed on a PC using word processing or

spreadsheet software.
7.6.10 Optical disk drive shall be used as mass storage for the data historian
server.
7.6.11 The Data Historian shall support data compression algorithms.
7.7 Operator Displays
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.”
7.7.1 General
7.7.1.1 The graphics package shall support multiple windows. As a

minimum, the operator shall be able to open eight windows
per monitor.
7.7.1.2 All displays and graphics that show real time data shall be
automatically updated when the display or graphic is on a
screen.
7.7.1.3 It shall be possible to move between related displays and

graphics of different detail levels or of the same detail level
with a maximum of two operator actions.
7.7.1.4 It shall be possible to configure special indicators to show

that a value is invalid. Invalid value can be out of range, no
communication, etc.
7.7.1.5 Each display or graphic shall have a dedicated alarm zone

which shall display, as a minimum, the three most recent
alarms.
7.7.1.6 It shall be possible to create a single display with several layers,

such that the layers disappear/reappear (declutter/clutter)
automatically depending on the level of magnification.
7.7.2 Faceplates
7.7.2.1 The system shall support graphical Faceplates to display

dynamic process and status information about process
elements such as a single control loop, pump, MOV, etc.

Page 21 of 44
7.7.2.2 Faceplates shall be provided as separate displays or as

graphic elements. If separate faceplate displays are provided,
it shall be possible to access the faceplate display for any tag
on a graphic display with a maximum of two operator actions.
If graphic elements are provided, it shall be possible to
configure faceplates to appear in any operator display.
7.7.2.3 Faceplates shall display the following information as

applicable:
 Tag ID
 Tag descriptor
 Process input, set point, and output values displayed
numerically with engineering units
 Process input, set point, and output in bar graph
representation
 Auto/manual mode and remote/local set point status if
applicable.
 Visual indication for alarm status (including alarm
inhibited or disabled)
 Symbolic and alphanumeric indication of discrete states
both for two state devices and multi-state devices
7.7.3 Alarm Summary Display
7.7.3.1 The system shall provide summary display of active process

alarms sorted in both chronological and reverse chronological
order for the operator's areas of responsibility. The process
alarm shall be colored based on the category. Accessing this
alarm summary display from any other display or graphics
shall require no more than one operator action.
7.7.3.2 This display shall show all process alarms currently in alarm
condition. Visible display of any alarm shall not clear unless
the alarm is acknowledged; and the item initiating the alarm
has returned to normal condition.
7.7.3.3 It shall be possible to display at least 100 alarms in an alarm

summary. Multi-page displays may be used. If so, it shall be
possible to page forward or backward and scroll up and down
by a single operator action.

Page 22 of 44
7.7.3.4 It shall be possible to list all tags that have: off scan status,
alarms disabled or inhibited, and manual status.
7.7.3.5 It shall be possible to display alarms based on configurable

fields such as plant area, plant unit, etc.
7.7.4 Operator Graphics
7.7.4.1 The format of numeric data shall have the capabilities to

display numeric data in formats ranging from a single digit to
8 digits (not including the sign or decimal place), with from 0
to 5 decimal places. The numeric formatting shall be
configurable on an individual basis.
7.7.4.2 It shall be possible to display numeric data in at least 16K color.
7.7.4.3 It shall be possible for each state of a multi-state device to be

indicated by a unique foreground/background color
combination.
7.7.4.4 Numeric data and other text shall be displayable in three

different character sizes.
7.7.4.5 It shall be possible to display numeric data in dynamic

vertical and horizontal bar graph format. This format shall
have the following capabilities:
 The height and width of each bar graph shall be

configurable on an individual basis.
 The height and width shall be configurable in units that

are not greater than the normal-sized character height and
width.
7.7.4.6 Symbolic representation of data on the graphics shall be

performed by shape changes, color changes (foreground and
background independently), and flashing in any combination.
7.7.4.7 Each graphic shall be capable of handling any mix of 200

calculated, analog, and discrete dynamic display elements.
Display of the elements includes text or graphical presentation.
7.7.4.8 It shall be possible to access any display from every operator

workstation.
7.7.4.9 It shall be possible to display trends on process data on the

Page 23 of 44
graphics display.
7.7.4.10 It shall be possible to display alarms in flashing/blinking

mode with different frequencies.
7.7.5 Graphic Capacity
7.7.5.1 Each operator workstation shall have access to minimum of

400 user-defined graphics.
7.7.5.2 There shall be no limit on the number of points that can be

configured on the user displays, per HMI Station.
7.7.5.3 Display and Graphic Response
 All displays and graphics including fully active dynamic

elements for up to 100 fields, displaying their current
values, shall be completed within 2 seconds of the graphic
display being requested.
 The update frequency for real time data, displayed
alphanumerically and symbolically (shape change, color
change, etc.), shall be at least once every 2 seconds for all
displays and graphics.
 Historical data display updates shall occur within five

seconds of call up.
7.7.6 Trend Displays
7.7.6.1 The system shall be capable of trending both real-time and

historical trends.
7.7.6.2 The system shall support pan-and-zoom feature of any trend

display.
7.7.6.3 All operator workstations shall be capable of displaying

trends.
7.7.6.4 Trends shall be provided in adjustable window size, which

could be full, half screen size, etc.
7.7.6.5 Text accompanying the trend shall show the following for
each tag: tag ID, minimum scale value, maximum scale
value, engineering units, and current value.

Page 24 of 44
7.7.6.6 The time periods and process value scales available for trend
displays shall be selectable.
7.7.6.7 Real-time and historical trends shall be available on the same

display (same monitor) simultaneously.
7.7.6.8 It shall be possible to trend as a minimum of eight different

tags simultaneously on one trend display. Each tag shall be
represented by a different color.
7.7.6.9 It shall be possible to incorporate trends in graphic displays.

Commentary Note:
A pre-configured target incorporated in the graphic display

that calls up the associated trend display is acceptable.
7.7.6.10 It shall be possible for a user to configure groups of pre-defined

trend sets. These trend sets shall define a set of one or more tags
to be trended and the scaling to be used for each tag.
7.7.6.11 It shall be possible to configure trend sets. Each set shall be

configured to trend any tag on the system. These trend sets
shall be available at any operator workstation. It shall be
possible to display any trend set by no more than two
operator actions.
7.7.6.12 It shall be possible for the operator to define and store trend
sets.
7.7.6.13 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 digital types.
7.7.6.14 Real time trends shall be updated every two seconds with
actual process data.
7.7.6.15 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 digital types.
7.7.6.16 It shall be possible to configure scale and time span on trend

displays for display purposes.
7.7.6.17 It shall be possible to export trend set data to removable media

in a common data format, i.e., MS Excel or CSV file format.
Page 25 of 44
7.7.7 Diagnostic Displays
7.7.7.1 The system shall provide dynamic communications overview

display to show the status of the communication system and
its components including but not limited to communication
servers, communication channels, routers, terminal servers,
and externally connected devices, i.e., RTUs, PLCs, DCSs, or
other SCADA systems.
7.7.7.2 Diagnostic displays shall be provided to show the operational

status and error conditions for all system components.
7.7.7.3 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 particular
peripheral devices (for example printers and terminals,) the
system must detect and provide an error indication for the
failure of these devices. The manufacturers' diagnostic tools
should be utilized for trouble shooting OEM hardware.
7.7.7.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.
7.7.7.5 Communications diagnostic displays shall show errors for

each of the redundant paths.
7.7.7.6 System displays shall be provided for cabinet temperature

alarms and system power faults.
7.7.7.7 The system shall support On-line help pages. The help pages
shall include text string search. The on-line help shall
support custom help pages.
7.7.8 Reports
7.7.8.1 The system shall provide industry standard report generation

and editing tools.
7.7.8.2 There shall be no need for special and/or dedicated hardware,

i.e., Attached network storage unit, to run and generate the
Page 26 of 44
required reports.
7.7.8.3 It shall be possible to use any variable in the system or the

history files in a report.
7.7.8.4 It shall be possible for all reports to be displayed on a

workstation screen as well as printed on a report printer.
7.7.8.5 It shall be possible for reports to accept manually entered data

for specific fields. Entered data could be numeric and/or
variable text of unlimited length.
7.7.8.6 It shall be possible to print user- defined reports to a report

printer and archive it to a bulk storage device.
7.7.8.7 It shall be possible to export reports to removable media in a

common data format, i.e., MS Excel or MS Word file format.
7.7.8.8 It shall be possible to use any variable in the system or the

history files in a report.
7.7.8.9 Reports to the same device are to be queued.
7.7.8.10 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.
7.7.8.11 The default location for the report printouts shall be the
operator console from which the report was requested.
7.7.8.12 It shall be possible to activate a report by:

 Demand (operator request)
 Scheduled (shift, daily and monthly)
 Event
7.7.8.13 It shall be possible to dedicate printers for reports only.
7.7.8.14 It shall be possible to print user- defined reports to a report

printer and archive it to a bulk storage device.
7.7.8.15 It shall be possible to export reports to removable media in a

common data format, i.e., MS Excel or MS Word file format.
7.7.8.16 The system shall provide the capability to define free-format

Page 27 of 44
alphanumeric descriptors (minimum of 10 characters) for each

state of a multi-state device. Eight states shall be allowed for
each multi-state device (an MOV for example: Open, Closed,
In-Transit, Undefined, Local/Remote Control, and fault for).
7.7.8.17 Each analog input, output, control, and calculated block shall
be assigned an engineering unit designation. It shall be
possible to automatically display this designation with the
value when the input, output, or algorithm is accessed.
7.7.9 Cross Reference Listings
7.7.9.1 The system shall provide facility to generate listings

containing the following fields:
 Tag
 Tag descriptor
 Point type
 Point address
7.7.9.2 It shall be possible to perform the following functions on the

above list:
 Sort alphanumerically by any field

 Filter by any field
 Print, display and store to media
 Generate Queries
8 Configuration Requirements
8.1 Configuration
8.1.1 The system shall provide object oriented database configuration.
8.1.2 The system shall support creating a library of objects. The library shall
support simplex and composite objects. The objects contained in a
composite can be static and/or dynamic. There shall be no limit on the
number of symbols or objects that can be stored in the library.
8.1.3 The system shall have the capability to perform on-line and off-line
database generation.
8.1.4 The system shall have the tools to perform global search and
modifying of on-line databases.

Page 28 of 44
8.1.5 It shall be possible to add or delete points from the history

configuration on-line without shutting down any of the history devices.
8.1.6 Template shall be provided to facilitate creating multiple tags that have
common parameters. 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.
8.1.7 The system shall be provided with an interactive configuration editor

to generate or modify on-line and off-line database and configuration
data. The configuration editor shall employ the following:
 Conversational, fill-in-the-blanks, or graphical techniques.

 Step-by-step prompts to guide sequential actions followed by
validation responses on completion of the actions.
 Request only applicable information based on previous responses.
8.1.8 Configuration displays shall be provided to aid in system

configuration. These shall include displays to show:
 All tags in the system

 All parameters for each tag, including (as applicable) tag ID, tag
descriptor, the hardware address, tuning constants, mnemonics
associated with the tag, algorithm relating to the tag, and
input/output details
 All configurable (or soft) keys and their function
 All hardware modules in the system and the configuration
parameters for each
8.1.9 The system shall have menu-driven pre-defined configuration tools for
database configuration, data acquisition function, control functions,
selection of control functions and logic, enable and disable scan of
inputs, input scan frequency, frequency of execution, enable / disable
processing, manual entry of data, communication protocols
configuration, local and remote on-line configuration, and on-line data
base modification.
8.1.10 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. The system shall not accept a
Page 29 of 44
duplicate Tag ID within any of SCADA databases and shall generate

an error.
8.1.11 Configuration changes shall automatically update all modules and tags
affected by the change.
8.1.12 Configuration changes shall follow a prompt validation sequence

requiring a final acknowledgment step before the change is
downloaded to an on-line RTU.
8.1.13 The SCADA system shall be equipped with the necessary RTU
configuration package for remote configuration of the RTUs.
8.1.14 When configuration data are downloaded, the system shall not allow
invalid entries to be downloaded to the RTU, PLC, etc. The invalid
configuration entries shall be identified and the parameters affected
shall be indicated.
8.1.15 The system shall verify that affected control blocks are in either
manual or inactive mode before configuration changes are downloaded
to an on-line RTU. If they are not, then either the change is prevented
or a warning message shall be displayed.
8.1.16 It shall be possible to save all database and configuration data on both
removable and non-removable media for back up purposes without
taking the system off-line.
8.1.17 It shall be possible to provide redundant on-line storage media for

configured database.
8.1.18 All tags shall be defined with at least the following parameters:
 Tag descriptor
 Tag type
 Alarm requirements
8.1.19 Tags shall be unique throughout the system; and access to all tag
parameters for configuration shall be available directly by the tag.
8.1.20 It shall be possible to have at least 16 free format alphanumeric

characters in a tag descriptor, e.g., RTU-444 F15-PT-10.
8.1.21 The system shall support tag descriptors of at least 32 characters as a

minimum.
8.1.22 The system shall provide the capability to define free-format

Page 30 of 44
alphanumeric descriptors (minimum of 10 characters) for each state of

a multi-state device. Eight states shall be allowed for each multi-state
device (an MOV for example: Open, Closed, In-Transit, Undefined,
Local/Remote Control, and fault for).
8.1.23 Multiple tags that have common parameters shall be created using
standard templates. 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.
8.1.24 Configuration changes shall follow a prompt validation sequence

requiring a final acknowledgment step before the change is
downloaded to an on-line RTU.
8.1.25 The SCADA system shall be equipped with the necessary RTU
configuration package for remote configuration of the RTUs.
8.1.26 All tags shall be defined with at least the following parameters:
 Tag descriptor
 Tag type
 Alarm requirements
8.1.27 Tags shall be unique throughout the system; and access to all tag
parameters for configuration shall be available directly by the tag.
8.2 Engineering Units
8.2.1 Each analog input, output, control, and calculated block shall be
assigned an engineering unit designation. It shall be possible to
automatically display this designation with the value when the input,
output, or algorithm is accessed.
8.2.2 Engineering units shall be a minimum of six free-format alphanumeric

characters.
8.2.3 The SCADA system shall support searching and modifying on-line
databases of off line and on line databases provided that the real time
performance of the system is not compromised. If the performance is a
concern, then an ODBC SQL interface to extract data to office tools
that support searching shall be provided.
8.3 Cross Reference Listings
8.3.1 The system shall be capable of generating listings containing the

following fields:
Page 31 of 44
 Tag
 Tag descriptor
 Point type
 Point address
8.3.2 It shall be possible to perform the following functions on the above list:
 Sort alphanumerically by any field
 Filter by any field
 Print, display and store to media
 Generate queries
8.4 Display Development
8.4.1 The system shall have the capability to import graphics from
commercial CAD/CAM programs.
8.4.2 The system shall have the capability to generate and modify user-
defined color graphics and to implement all the features of the
following paragraphs, using an interactive or CAD-like procedure.
8.4.3 The graphics builder utility shall have the capability to make a copy of
an existing graphic or graphic symbols in order to build a new graphic
that is similar.
8.4.4 The graphics builder utility shall use the same tags that are used in the
process database to access real time variables from any database.
No intermediate index numbers or addressing shall be required.
8.4.5 The graphics builder utility shall be subject to system access protection.
8.4.6 It shall be possible to place a new graphic in service without affecting

the online system or interrupting an operator's ability to control the
plant.
8.4.7 It shall be possible to build display and graphics off-line without tag
name existence.
8.4.8 The system shall have an extensive library of pre-defined symbols or

objects (simplex and composite - like MOVs, HV, Tanks, etc.). It shall
be possible to insert these symbols and objects into any graphics and
assign associated process data using database tags.
8.4.9 The system shall have the tools to add, delete, or modify any symbol or

Page 32 of 44
object in this library.
8.5 High-Level Programming
The ability to generate custom calculation and/or function blocks shall be

provided. This language shall have as minimum the capability and functions
specified below.
8.5.1 A full screen text editor shall be provided for generating and editing
application software.
8.5.2 The following functions and routine shall be provided using the high
level programming language:
 Display and Workstation I/O functions, including workstation,

monitors and keyboard I/O, and system access (hardware key,
software password).
 Process I/O functions, including routines that facilitate inputting
and outputting to process I/O.
 Peripheral I/O functions, including routines that facilitate inputting
and outputting to peripherals (for example, removable storage
media and printers).
 Access to data tables created and/or editable by the user (for
example, tables of chemical properties, thermodynamics properties,
and tank level versus volume strapping).
 Control algorithms, including routines that facilitate inputting and
outputting to other control algorithms.
8.5.3 Access to the database by a high-level program shall be by tag and

parameter.
8.5.4 Compilation of programs without alteration of on-line versions shall be

possible.
8.5.5 Off-line compilation errors shall be reported by an English description

of the error and the line number.
8.5.6 On-line, run-time errors shall be reported by program name and host
module.
8.5.7 It shall be possible to create similar programs by duplicating, editing

and compiling.

Page 33 of 44
8.6 Engineering Workstation
8.6.1 Engineering workstation shall be capable of the following functions as

a minimum:
 Configuration
 On-line and off-line database generation
 Graphics and display generation and modification
 Control algorithm generation and modification
 Report generation and modification
 Symbols and objects generation and modification.
 Trends generation and modification.
 System access configuration
 File access
 Diagnostics
 Workstation/monitors and keyboard plant area assignments
 Utility program access.
8.6.2 System back-up shall be automatic or by command from an

engineering workstation. The automatic system back up capability,
from a central location, shall be available with the user-friendly
graphical interface.
9 Hardware
9.1 Workstations
9.1.1 Failure of any workstation shall not affect other workstations.
9.1.2 Each operator and engineering workstation shall have access to, either
directly or through a network, a printer for logging alarms, system
events and other information.
9.2 Operator Workstations
9.2.1 All operator functions that are available on a touch screen shall be
available from a keyboard, mouse, or trackball.
9.2.2 An operator workstation shall access control only on those plant areas
to which it is assigned.
9.2.3 It shall be possible to change control assignments to allow control of

any plant area from any operator workstation by using the appropriate
Page 34 of 44
access privilege level.
9.2.4 An operator QWERTY keyboard shall be provided.
9.2.5 Operator workstation shall be equipped with removable media. As a

minimum, a CD RW drive shall be available.
9.3 Engineering Workstation
9.3.1 A QWERTY keyboard shall be provided with each engineering

workstation.
9.3.2 Removable storage media shall be provided at each engineering

workstation.
9.3.3 A network laser printer shall be supplied for the engineering

workstation for general system documentation, screen copying, and
report generation.
9.4 Monitors
LCD monitors for operator workstations shall be as follows or better:
 Diagonal measurement 21 inches nominal

 1280 x 1024 resolution (non-interlaced and low radiation)
 32 bit true colors
9.5 Display Hardcopy
9.5.1 The capability to generate a hardcopy/softcopy of any active display

shall be available.
9.5.2 Generation of a hard copy shall not freeze the monitor display.
9.5.3 The system shall support both full color and black and white copies for
all displays.
9.5.4 A dedicated function key shall be available on the keyboard of each

operator or engineer's workstation to request a copy of its associated
monitor screen.
9.5.5 The system and/or printer shall queue the multi-printing request
without freezing the system.
9.6 Printers
9.6.1 Alarm log printers shall be available with continuous fan-fold paper,
Page 35 of 44
and provide the following:

a) 240 characters per second,
b) 132 characters per line,
c) Holder for fan-fold paper.
9.6.2 The system shall be capable of sharing printers installed on the

network.
9.6.3 The system shall be capable of using key strokes such as configured
keys to disable the console from sending any alarm messages to the
printer.
9.7 Routers
9.7.1 All routers shall support full hardware modem control.
9.7.2 It shall be possible to logically connect any computer connected to a

router to any other computer on a network.
9.7.3 All routers shall perform automatic diagnostic checks on start-up and
during operation and report their status to the controlling host
computer. Router communication with the host CPU shall be kept to
the minimum.
9.7.4 All routers shall be capable of high filtering and forwarding rates.
9.7.5 All routers shall be capable of network node addressing analysis.
9.7.6 The router shall be able to support all popular access methods such as
Ethernet, Fast Ethernet, token ring, etc.
10 Security and System Access
10.1 Communication Security
10.1.1 The system shall verify the operation of the communication channels
on a regular basis and shall alarm on any failure.
10.1.2 The system shall have communication error checking schemes such as
CHECKSUM and shall alarm on repeated failures.
10.1.3 The system shall periodically test and validate the integrity of the
backup communication ports and shall alarm on any failure.
10.1.4 The system shall alarm when an RTU fails to respond to a message

Page 36 of 44
within a specified number of automatic retries and shall alarm on any

failure of an RTU communications channel.
10.1.5 The system shall be capable of generating an alarm when

communications error rates exceed a predetermined threshold value.
10.1.6 The system shall log and print at the event printer all local and remote
access to the system.
10.1.7 The system shall support check-before-operate as well as direct

command operations.
10.2 User Groups and User Roles
10.2.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.
10.2.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:
a) View Only
b) Plant Operator (1 – 10 plant operator roles shall be specifiable)
c) Process Supervisor
d) Engineer
e) System administrator
10.2.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.
10.2.4 Refer to SAES-Z-001, Section 14 for additional requirements on the

configuration of User Groups and User Roles.
10.2.5 The systems shall be capable of defining individual user accounts for
all type of system users.
10.2.6 The system shall have the capability to disable all guest accounts
without affecting the functionality of the system.

Page 37 of 44
10.3 User Accounts
10.3.1 The system shall be capable of maintaining separate user accounts for
each user whom has access to the system.
10.3.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.
10.3.3 The system shall provide the functionality to track user login activity
and maintain records of user login activity.
10.3.4 The system shall provide the functionality 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.
10.3.5 The system shall provide the functionality to temporarily disable user
accounts 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.
10.3.6 The system shall provide the functionality to permanently disable or

remove unused user accounts.

configuration of User Accounts.
10.4 Authentication
10.4.1 The system shall be configured to require an individual user ID and

password for each user which accesses the system.
10.4.2 Management and administration of passwords shall be done from a

central server within the system. When a user updates his password on
any 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.
10.4.3 The system shall be provided with the capability to provide

authentication services when the primary authentication server is
offline. This shall be accomplished using a redundant authentication
Page 38 of 44
servers or through other techniques as long as the mechanism provides

similar functionality to the primary authentication server.
10.4.4 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:
10.4.4.1 Password Aging
The system shall be configured to enforce 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 password within the
password aging period shall be locked out of the system.
10.4.4.2 Password Complexity
The system shall be configured to enforce minimum

complexity policies for password construction. As a
minimum, passwords shall be required to meet a minimum
length requirement.
10.4.4.3 Password Uniqueness
The system shall be to enforce a minimum number of

unique passwords be used prior to a password being re-used.
This prohibits the user from entering the same password.
10.4.5 Facilities shall be provided to enable any user to automatically retrieve

or reset his password by entering or answering user specific
authentication questions. During the user’s initial login of the system,
the user shall be asked to select the password reset / retrieval questions
and provide answers to these questions to facilitate this capability.
10.4.6 The capability to reset or retrieve a user account password shall be

provided for every station connected to the system.
10.4.7 Refer to SAES-Z-001, Section 14 for details on the configuration of

user passwords.
10.4.8 The central authentication mechanism shall be capable to enforce

account changes at one location to automatically update all stations
where the account is valid.
10.4.9 Passwords shall be masked on the screen while being entered.

Page 39 of 44
10.4.10 In order to change user account passwords, the central authentication

mechanism shall require users to provide both their old and new
passwords.
10.4.11 Central authentication mechanism shall have the capability of issuing a

password expiration notification to the user at least 10 days prior to
password expiry date.
10.4.12 Systems shall be capable of configuring the following password and

lockout policies settings:
A. Minimum password length of at least 8 characters.
B. Password changes are forced every three (3) months.
C. Number of unique new passwords that have to be associated with
a user account before an old password can be reused should be at
least 6 passwords.
D. Password complexity shall be enabled to ensure that passwords
meet the following minimum requirements when they are changed
or created.
i. Do not contain the user's entire account name or entire full
name.
ii. Contain characters from three of the following four
categories: English uppercase characters (A through Z),
English lowercase characters (a through z), Base 10 digits
(0 through 9), and Non-alphabetic characters (for example, !,
$, #, %)
E. Systems shall have the capabilities of locking out an account after
five consecutive failed logon attempts.
10.4.13 Systems shall have the capabilities to encrypt password when stored or
transmitted.
10.4.14 Upon logon failure, the system shall not indicate to the user whether
the failure is caused by a wrong user name or password.
10.4.15 All systems shall have the capability of multifactor authentication for
privileged users such as administrators.
10.4 Anti-Virus Protection
The requirements for Anti-Virus (AV) protection apply only to Microsoft

Windows based systems.
Page 40 of 44
10.4.1 All workstations shall be supplied with commercially available anti-

virus software protection package. The software shall be qualified by
the vendor for use on their system. MacAfee AV software is highly
recommended.
10.4.2 Workstations shall be capable of running anti-virus software protection

package while the station is performing its intended functions.
10.4.3 Installation, configuration, and update requirements for anti-virus

software shall be clearly documented in the systems user's manual.

installation and configuration of Anti-Virus software.
10.4.5 The system shall be capable of updating antivirus definition files and
scan engine automatically on a daily basis via a centralized antivirus
distribution server on the network.
10.5 Network Security
Communications networks between DCS control networks and other non-DCS

networks shall adhere to the requirements defined in SAES-Z-010.
10.6 Backup and Disaster Recovery
10.6.1 The systems shall have the capability to backup all necessary client
configuration, operating system files, databases required for system
restoration automatically on a scheduled basis.
10.6.2 The systems shall have the capability to perform a bare metal image
backup for quick restoration.
10.6.3 Network systems shall have the capability to be backed up on a

separate system such as the NMS.
10.7 General Requirements
10.7.1 Shall be capable of having session timeouts for consoles and remote
logins.
10.7.2 Systems shall be capable of displaying a warning banner, upon logon.
10.7.3 Systems shall have an Auto-logoff feature or screen-saver lockout that

gets activated after a predefined time period.
10.7.4 Systems shall be capable to connect to a centralized patch management

server to install security, operational patch updates and software
Page 41 of 44
upgrade of. The centralized management server shall have the

capability to manage the updates remotely.
10.7.5 Security updates of all networks devices shall be done using a

centralized Network Management System (NMS).
11 Engineering Tools
11.1 Software tools shall be available to assist with the initial engineering and long-
term maintenance of the system. These tools do not need to be an integrated
part of the system.
11.2 Capability shall be provided to configure all tag parameters and write high level
language programs off-line.
11.3 It shall be possible to download the configuration and program files created off-
line to the system.
11.4 An interactive editor for building and maintaining a configuration database shall
be provided. This editor shall be capable of reading database files that are
compatible with office personal computers software packages such as Microsoft
Access and Microsoft Excel.
11.5 Software tools shall be available to assist with the initial engineering and long-
term maintenance of the system. These tools do not need to be an integrated
part of the system.
11.6 The System shall include capability to configure all tag parameters and write
high level language programs off-line.
11.7 It shall be possible to download the configuration and program files created off-
line to the system.
11.8 An interactive editor for building and maintaining a configuration database shall
be provided. This editor shall be capable of reading database files that are
compatible with office personal computers software packages such as Microsoft
Access or Microsoft Excel.
11.9 Access to capabilities of editing both the database and displays shall be limited
to the engineering workstation(s) and shall be restricted to users with
appropriate access privileges.
11.10 Engineering workstation shall be capable of the following functions as a minimum:

a) On-line and off-line database generation
b) Graphics and display generation and modification
Page 42 of 44
c) Control algorithm generation and modification

d) Report generation and modification
e) Symbols and objects generation and modification
f) Trends generation and modification, System access configuration, File
access, Diagnostics, Workstation/monitors and keyboard plant area
assignments
g) Utility program access
12 Environmental Conditions
12.1 The system shall meet the temperature and humidity requirements as stated in
SAES-J-003.
12.3 The noise levels for all equipment shall be less than or equal to:
 55 dBA for equipment installed in continuously manned areas.
 60 dBA for equipment installed in other areas.
13 Electrical Requirements
For electrical power requirements, grounding and other requirements related to the
System cabinets design refer to 34-SAMSS-820.
14 Documentation
14.1 Standard documentation shall be available in CD-ROM or other electronic

format approved by the Saudi Aramco.
14.2 The following documents shall be provided as part of the system documentation
package: Installation Guide, Vendor's Functional Design Specification,
Operators Manual, Engineers Manual, Maintenance Manual, Database
Configuration Manual, Test Procedures and Records, network layout, block
diagrams, and the application configuration software, system specifications.
14.3 On-line electronic documentation shall be available and shall include graphics
and text string search.
14.4 The software written for Saudi Aramco project at Saudi Aramco expense will be
property of Saudi Aramco and source code shall be provided to Saudi Aramco.

Page 43 of 44
15 Inspection and Testing
15.1 Saudi Aramco Inspection Requirements Form 175-230200 lists all system
components that are subject to verification by Saudi Aramco's inspection
representative.
15.2 Integrated systems that are staged at a vendor's facilities shall be tested
according to Factory Acceptance Test (FAT) procedures produced for each
SCADA project.
15.3 Factory Acceptance Test (FAT) criteria shall be developed by the vendor and
approved by Saudi Aramco. The FAT shall be structured and include the
requirements of SAEP-750, Testing Procedures for Process Automation Systems.
15.4 The vendor shall supply a list of all required test tools.
15.5 A Site Acceptance Test (SAT) criteria shall be developed by the vendor and
approved by Saudi Aramco. The SAT shall be structured and include the
requirements of SAEP-750, Testing Procedures for Process Automation Systems.
Revision Summary
16 January 2014 Major revision.
14 March 2017 Editorial revision deleting the reference to the canceled procedures (SAEP-1630, SAEP-1634,
and SAEP-1638) and adding procedure SAEP-750 as a reference.
1 January 2018 Editorial revision to paragraph 5.4.2 to delete “Any substitute must be approved by Manager,
P&CSD in writing.”

Page 44 of 44

23 Samss 020

Uploaded by

Copyright:

Available Formats

23 Samss 020

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 020

Uploaded by

Copyright:

Available Formats

Materials System Specification

23-SAMSS-020 1 January 2018

Previous Issue: 14 March 2017 Next Planned Update: 16 January 2019

©Saudi Aramco 2017. All rights reserved.

This specification defines the minimum mandatory requirements for Supervisory

This document excludes Remote Terminal Units (covered by 23-SAMSS-030),

1.2 Where a project Functional Specification Document (FSD) calls for an

1.4 In addition to this specification, SAES-Z-004 “Supervisory Control and Data

2 Conflicts and Deviations

3.1 Saudi Aramco References

Saudi Aramco Engineering Procedures

Saudi Aramco Engineering Standards

Saudi Aramco Materials System Specification

Saudi Aramco Inspection Requirements

3.2 Industry Codes and Standards

American Petroleum Institute

Internet Architecture Board

International Electrotechnical Commission

“Comprehensive Dictionary of Measurement and Control”, International Society for

4.1 Acronyms and Abbreviations

4.2 Words and Terms

Application Software: The software written specifically to perform functional

Saudi Aramco: Company General Use

Auxiliary System: A control and/or monitoring system that is stand-alone,

Configurable: The capability to select and connect standard hardware modules to

Configuration: The physical installation of hardware modules to satisfy system

Console: A collection of one or more workstations and associated equipment

Firmware: Programs or instructions that are permanently stored in hardware

Module: An assembly of interconnected components that constitute an

Object Based Programming: A type of programming in which programmers

Protocol: A strict procedure required to initiate and maintain communication

Redundant Configuration: A system/subsystem configuration that provides

Report-by-Exception: The reporting of data (e.g., from RTU to master station)

Self-diagnostics: Programs automatically executed, at predetermined intervals,

System Alarm: Alarm that occurs as a result of a SCADA hardware or

Workstation: A set of electronic equipment including a minimum of one

5.1 Use and Compliance to Open Standards

5.1.2 All supplied hardware, firmware, and software (excluding application

Application software that is written for project specific control and

Saudi Aramco: Company General Use

5.1.3 A vendor's standard SCADA base software shall not be modified to

5.2 Field Proven Systems

All supplied hardware, firmware, and software (excluding application software)

5.3 Software Protection

5.3.1 No software or hardware locking mechanisms that restrict the user

5.3.2 No software or hardware locking mechanisms that restrict the user

5.3.3 System's operation and maintenance shall not be dependent on license

5.4 Software Revision

5.4.1 All vendor proprietary software, exclusive of application software,

The exclusion of application software is not intended to provide an

5.4.2 All personal computers, monitors, printers, peripherals, Ethernet

commercially available which has been tested and approved for

5.5 System Support

6.1.2 The system shall be based on industry standard in-memory (IMDB),

6.1.5 The system shall support integration to packages such as process

Saudi Aramco: Company General Use

6.1.8 The SCADA master station communication subsystem shall include

6.2.1 The system shall support hardware and software redundancy as

6.2.3 The following are general redundancy requirements: