Saes Z 004

Engineering Standard
SAES-Z-004 10 November 2013

Supervisory Control and Data Acquisition (SCADA) System
Document Responsibility: Process Control Standards Committee
Saudi Aramco DeskTop Standards

Table of Contents
1 Scope.............................................................. 2
2 Conflicts and Deviations................................. 2
3 References..................................................... 3
4 Definitions....................................................... 4
5 System Design Requirements........................ 8
6 Data Acquisition and Processing.................. 13
7 System Sizing, Spare Capacity
and Expansion …………………….…… 17
8 System Performance Requirements............. 17
9 SCADA Connectivity .................................... 19
10 External Interfaces........................................ 22
11 Display Design Philosophy........................... 23
12 Security and System Access........................ 29
13 Instrument Asset Management
System (IAMS)...................................... 37
14 Documentation.............................................. 38
15 Inspection and Testing.................................. 38
16 System Maintainability.................................. 38
Previous Issue: 25 October 2010 Next Planned Update: 10 November 2018

Page 1 of 39
Primary contact: Khalifah, Abdullah Hussain on +966-13-8801830
Copyright©Saudi Aramco 2013. All rights reserved.

Document Responsibility: Process Control Standards Committee SAES-Z-004
Issue Date: 10 November 2013
Next Planned Update: 10 November 2018 Supervisory Control and Data Acquisition (SCADA) System
1 Scope
This Standard defines the minimum mandatory requirements and guidelines governing
the engineering, design, installation, testing and commissioning of Supervisory Control
and Data Acquisition (SCADA) systems for upstream oil and gas applications, pipeline
applications, power and utility applications in Saudi Aramco plants. Parties involved in
the design of new, upgrade and/or expansion of SCADA systems are required to comply
with this standard.
This standard is also applicable for SCADA communications channels and RTU
interface with 3rd party subsystems.
Where the project Functional Specification Document (FSD) calls for an integrated
process control system, this standard shall apply to the SCADA portion of the Control
system. Project specific requirements and any requirements above and beyond those
included here shall be defined in project specification documents.
Exclusions:
1) The requirements and guidelines governing the engineering, design and installation of
proprietary Distributed Control Systems is covered in SAES-Z-001.
2) The requirements and guidelines governing the engineering, design and installation of
Process Automation Networks (PAN) is covered in SAES-Z-010.
The procedural requirements and guidelines to govern minimum mandatory Security for
SCADA Systems are covered in SAEP-99 and excluded from this document.
This entire standard may be attached to and made a part of purchase orders. A table of
compliance to the requirements of this standard shall be provided with every technical
proposal.
2 Conflicts and Deviations
2.1 Any conflicts between this standard and other applicable Saudi Aramco
Materials Systems Specifications (SAMSSs), Engineering Standards (SAESs),
Engineering Procedures (SAEPs), Standard Drawings (SASDs), or other
Mandatory Saudi Aramco Engineering Requirements (MSAERs) shall be
resolved in writing by the Company or Buyer Representative through the
Manager, Process & Control Systems Department, Dhahran.
2.2 Direct all requests to deviate from this standard in writing to the Company or
Buyer Representative, who shall follow internal Company Engineering Procedure
SAEP-302 and forward such requests to the Chairman, Process Control Standards
Committee, Process & Control Systems Department, Dhahran.
Page 2 of 39
3 References
Material or equipment supplied to this standard shall comply with the latest edition of
the references listed below, unless otherwise noted.
 Saudi Aramco References
Saudi Aramco Engineering Procedures

SAEP-99 Process Automation Networks & Systems Security
SAEP-302 Instructions for Obtaining a Waiver of a Mandatory
Saudi Aramco Engineering Requirement
SAEP-368 Alarm System Management
Saudi Aramco Engineering Standards

SAES-J-902 Electrical Systems for Instrumentation
SAES-J-904 FOUNDATION™ Fieldbus (FF) Systems
SAES-J-905 Instrument Asset Management Systems (IAMS)
SAES-T-566 Plant Demilitarized Zone (DMZ)
SAES-T-624 Telecommunications Outside Plant - Fiber Optics
SAES-T-625 Inter and Intra Building Fiber Optic Communications
Cables
SAES-Z-001 Process Control Systems
SAES-Z-010 Process Automation Networks
Saudi Aramco Materials System Specifications

23-SAMSS-020 Supervisory Control and Data Acquisition (SCADA)
Systems
23-SAMSS-030 Remote Terminal Unit
23-SAMSS-060 Applications Integration Middleware
34-SAMSS-623 Programmable Controller Based ESD Systems
Saudi Aramco Inspection Requirements

Form 175-230200 Inspection Requirements for SCADA System
Saudi Aramco General Instructions

GI-0710.002 Classification of Sensitive Information
GI-0299.120 Sanitization and Disposal of Saudi Aramco Electronic
Page 3 of 39
Storage Devices and Industry Codes and Standard
Saudi Aramco Information Protection Manual (IPM)

IPSAG-007 Computer Accounts Security Standards & Guidelines
Corporate Policy
INT-7 Data Protection and Retention
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 of
Automation, shall apply.
4.1 Acronyms and Abbreviations

API Application Program Interface
CBO Check Before Operate
COTS Commercial-Off-The-Shelf
DAHS Data Acquisition and Historization System
DCS Distributed Control System
DMZ Demilitarized Zones
FSD Functional Specification Document
GPS Global Positioning System
GUI Graphical User Interface
HMI Human Machine Interface
OEM Original Equipment Manufacturer
OPC OLE for Process Control
PDR Preliminary Design Review
PLC Programmable Logic Controller
RBE Report by Exception
RTU Remote Terminal Unit
SAEP Saudi Aramco Engineering Procedures
SAES Saudi Aramco Engineering Standards
Page 4 of 39
SAMSS Saudi Aramco Material System Specifications
4.2 Words and Terms
Address: An identifying name, label, or number for a data terminal, source, or

storage location calculation.
Analog data: Data represented by scalar values.
Application Account: refer to the account name used to run applications as

either a service or a background process.
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 and access the SCADA real-time and historical
database data.
Availability: The percent of time a system or component remains on line and

performs as specified.
Bidirectional: Providing for information transfer in both directions between

master and remote terminals (of a communication channel).
Binary digit: A character used to represent one of the two digits in the binary
number system and the basic unit of information in a two-state device. The two
states of a binary digit are usually represented by “0” and “1”. Synonym: bit.
Buffer: A device in which data are stored temporarily in the course of

transmission from one point to another; used to compensate for a difference in
the flow of data, or time of occurrence of events, when transmitting data from
one device to another.
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.
Command: Commands are sent by operators or by applications. Commands

can be binary or analog (set-point). Commands require reliable, secure, and
timely delivery. Command data should be delivered to its target as quickly as
possible, typically in the order of seconds or sub-seconds. If a command cannot
be delivered or acted upon, the SCADA system should report this to the
operator.
Communication channel: A facility that permits signaling between two

terminals i.e. a path between master station and an RTU, PLC or a subsystem.
Page 5 of 39
Communications Subsystem: The hardware and software that performs the

transmitting and receiving of digital information.
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.
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.
Cycle: The scanning of inputs, execution of algorithms and transmission of

output values to devices.
Cyclic Polling (Poll cycle, 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.
Flag: A character that signals the occurrence of some event. Usually, a field of
1 bit.
Faceplate: A graphic element that mimics the front panel of an analog

controller instrument, hardwired push-button or switch.
Fail-Over: Occurs automatically without user intervention, transparent to the

user.
Gateway: A device that connects client requests that are transported over one
or more protocols to a remote destination that uses the same or (typically)
different protocol.
Intelligent Electronic Devices (IED): An intelligent electronic device that

perform specific control and/or data gathering function.
Logs: Files or printouts of information in chronological order.
Master Station: Server or servers and software responsible for communicating

with the field equipment (RTUs, PLCs, etc.), and then to the HMI software
running on workstations in the control room, or elsewhere. Master station may
include multiple servers, distributed software applications, and disaster recovery
sites. The Master Station includes all networks switch and connectivity devices
required to communicate with RTUs and remote sites.
Page 6 of 39
Operating System: software that runs on computers and manages the computer
hardware and provides common services for execution of application software.
Protocol: A strict procedure required to initiate and maintain communication

with the RTU or a PLC. Open Industry Standard communication protocol is
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 and/or subsystem that provides for a

backup module with automatic switchover from the primary unit to the backup
module, in the event of a failure, without loss of a system function. Both active
and backup modules utilize diagnostics to assist in identifying and locating
failures and to permit modules to be removed for repair and/or replacement.
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 dead-band (e.g., for an analog input point).
Round Trip Delay (latency): The time required for a packet of data to travel
from a specific source to a specific destination and back again. Latency is
measured by sending a packet that is returned to the sender and the round-trip
time is considered the latency.
Scan: The process by which a data acquisition system interrogates remote

terminals or points for data.
Security code: A group of data bits calculated by a transmitting terminal from

the information within its message by use of a prearranged algorithm, appended
to the transmitted message, and tested by the receiving terminal to determine the
validity of the received message.
Self-Diagnostic: The capability of an electronic device to monitor its own

status and indicate faults that occur within the device.
Supervisory control: A telemetry based process control command initiated

from a Master Central Station either manually by operator or automatically by
an application to initiate an action and/or change analog set point in a remotely
located Control Stations over a bidirectional communications link using specific
communication protocol. Such command is dependent of having quality process
related alarm/event data and follows timely bidirectional confirmation and
acknowledgment executing sequences between the master and the station known
as select/check before Operate (CBO).
Page 7 of 39
System Account: refer to account names used by the operating system.
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.
Transaction: A sequence of messages between cooperating terminals to

perform a specific function. Usually, a minimum of one message in each
direction that is comprised of a command followed by a response.
5 System Design Requirements
The SCADA system can support any type of telecommunication technologies.

However, the design of the telecommunication system and/or topology is outside the
scope of this document. The following design requirements shall be complied with to
provide highly efficient and reliable SCADA system for each application using the
selected technology.
5.1 General
A detailed Performance analysis shall be conducted for each application

(Project) to recommend the optimum architecture to meet the performance
requirement stated in the performance section of this standard.
5.1.1 The performance analysis shall be based on the expected data scan
frequency and spare capacity for each application as stated in the
project functional specification document.
5.1.2 The analysis shall address SCADA server(s) loading, bandwidth

capacity and utilization of each telecommunication channel based on
the used communication protocol messaging structure.
5.1.3 Data communication channel loading and capacity calculation shall be

performed prior to adding new RTUs to an existing communication
channel.
5.1.4 Communication protocol(s) used to communicate with the RTU and

other system components shall be on Open Industry Standard
protocol(s) as defined in 23-SAMSS-020 and 23-SAMSS-030.
5.1.5 All functional requirements shall be implemented using the protocol’s

standard features. However, if the vendor needs to use any of the
optional protocol functions to meet any of the project specific
Page 8 of 39
functional requirements, vendor shall provide full documentation of the

implementation at the PDR phase. Such implementation shall not
result in a proprietary interface.
5.2 Design Architecture
5.2.1 The SCADA software shall be based on Client/Server architecture.

Processing load shall be balanced and distributed among the system
components to achieve the scalability to meet the required performance
level.
Commentary Note:
Use of SCADA on virtualized servers, thin clients operator/engineering

workstation environment can be considered on cases by case bases
and based on using dedicated server hardware. Request to consider
this architecture require prior approval from P&CSD.
5.2.2 The master station shall consist of online redundant SCADA servers
configuration interconnected by a redundant high-speed local area
network (LAN) using dedicated Layer 3 network switches.
5.2.3 SCADA system redundant components shall include Human Machine

Interface (HMI), Front End Processor (when required to run on a
separate machine), the real time database, all applications servers and
the data historian.
5.2.4 The SCADA system shall be physically and logically isolated from all
other non SCADA systems such as Voice, CCTV and non-process
control system hardware.
5.2.5 The SCADA server(s) shall be dedicated to perform the real time data
acquisition and telecommunication processing functionalities and shall
not be shared and/or used to perform any non-SCADA related data
processing functions.
5.2.6 Data collector applications such as PI-OPC Interfaces, etc., shall be

installed on dedicated Windows Servers (called as Scan Nodes) and
shall be located on the same SCADA domain.
5.2.7 All SCADA servers and workstations including network components

and peripherals shall have redundant network connectivity.
5.2.8 Operator workstations located in the main control center shall run thick
client software. Operator work stations shall not be based on Windows
Terminal Services, Remote Desktop protocol, Web Servers, or any
Page 9 of 39
other thin client architecture. Thin client architecture may be used for
view only workstations.
5.2.9 Remotely located view only work station(s) (Clients) shall use PI client
to connect to the central DAHS (central PI).
5.2.10 Remotely located Engineering and/or Maintenance work station(s)

which are used to access the SCADA server/RTU shall be connected to
the SCADA network through dedicated communications channel.
5.2.11 The network connectivity for the remote Engineering and/or

Maintenance work station(s) shall be separate with no network bypass
and/or data leakage from the corporate shard packet network.
5.2.12 For application requiring redundant RTU communication modules, the

design shall provide dedicated communication path from each
communication module to the telecommunication network.
5.2.13 There shall be a minimum of one dedicated engineering workstation

configured on the system. Engineering workstation shall be capable of
functioning as operator workstation.
5.2.14 Serial and IP based communication protocols shall be implemented in

the SCADA server and shall run in native mode. Use of external
communication protocol converter (hardware unit) or internal converter
(third party software driver) shall be limited and shall require approval
from Chairman, Process Control Standards Committee, P&CSD.
Commentary Note:
The above requirement is not intended to exclude the use of media

converters.
5.2.15 Active and backup SCADA servers shall be kept in a fully

synchronized state. Synchronization shall include but not limited to
applications and databases.
5.2.16 In the event of a failure of the active (primary) server, the backup
server shall automatically assume control of all peripherals and
communications lines within a maximum of 30 seconds. The system
shall be clearly designating the active server as the primary.
Repaired server shall resume the function as a backup server.
5.2.17 If and whenever RTU redundancy is required, the server switchover to

the active CPU and/or communication module shall be immediate and
shall not result in any process upset.
Page 10 of 39
5.2.18 The system shall allow engineering/maintenance access privilege to

any RTU from any engineering station in the network with appropriate
access authority.
5.2.19 The SCADA system shall incorporate set of tools to commission,

monitor, and maintain the communication channels and end devices.
Provided tools shall allow connectivity to the overall system from a
central location.
5.2.20 It shall be possible to view and/or operate the process from any
SCADA client, except if this is explicitly disabled for certain users or
clients via removing the corresponding access privileges.
5.2.21 The SCADA server shall be connected to a GPS and shall serve as the
master time source to synchronize the time of all network devices and
connected slaves (RTU/PLC).
5.2.22 Time Synchronization shall occur whenever a network device,

RTU/PLC is restarted from a power down via the standard
communication protocol synchronization command.
5.2.23 For communication protocols that do not support standard time

synchronization function, i.e., MODBUS, the SCADA server shall
provide functionality to write time values to specific registers in all
connected slave devices. The Slave device shall also accept and
process the new time value settings.
5.2.24 The system shall be configured to switch to a predefined alternate

communication port (or IP address) that can be used to reach the RTUs.
5.2.25 On a series of communication errors with an RTU, the system shall

generate an alarm and switch ports or IP address after a user-definable
port retry count expires. The SCADA system shall provide separate
point indicate which port is currently being used to poll each RTU.
5.2.26 If the communication line is looped, it shall be possible to determine

between which two RTUs a break exists by examining the values of
the port status points. Network management system may be used to
meet this requirement.
5.2.27 For each RTU, the SCADA system shall maintain communication
channel/protocol statistics in the form of analog points that may be
viewed on displays, printed in reports, or stored in historical data files.
Such statistics shall include percentage of successful communication,
number of timeouts and number of security errors.
Page 11 of 39
5.2.28 After an RTU has been declared failed, the system shall continue to
poll it but at a reduced rate, for example: poll only one failed RTU on
each poll cycle. If all RTUs are failed on a communication line (on
both ports, if two ports are defined), the system shall declare the entire
communication line as failed.
5.2.29 Communication protocol monitoring tools shall be provided for each

communication protocol used in the SCADA system to allow users to
view the messages issued to and returned from individual RTUs or all
RTUs.
5.2.30 For application where FOUNDATION™ Fieldbus (FF) based RTU is

specified, refer to SAES-J-904 for the design requirements.
5.3 Availability and Reliability
5.3.1 The SCADA System architecture shall provide a 99.98% hardware and
software availability and reliability.
5.3.2 The SCADA telemetry network connecting the SCADA master station
and RTU/PLC design shall provide, as minimum, 99.50% availability
and reliability.
5.3.3 SCADA communication network flooding generated by a faulty

communication device shall not block network, cause network
jamming and/or degrade system performance.
5.3.4 The SCADA Master Station shall be designed with no single point of
failure. For application where redundant RTU/PLC is required, the no
single point of failure requirement shall include the communication
modules and communication links to the RTU/PLC.
5.3.5 Replacement of any failed SCADA LAN component shall not affect
the operations of the process.
5.3.6 There shall be no effect on programs, control application, tasks running

in the RTU and no loss of field data when a switchover takes place
between a primary and a redundant SCADA server.
5.3.7 Switch back to repaired equipment shall be permitted only after the
system diagnostics function has determined that the module is fully
functional.
5.3.8 Failure of any primary or backup systems components, including

communication channel shall be alarmed as a system alarm and shall
be logged.
Page 12 of 39
5.3.9 Health Status of the backup equipment shall be monitored all the time.
The system shall generate an alarm and log if the backup system is
incapable of assuming primary equipment functions.
5.3.10 Automatic and manual switchover shall be displayed, logged, and

alarmed by the system.
5.3.11 Intelligent Electronic Devices (IEDs) and/or I-Field surface units’ data
gathered by the RTU shall be reported to the Master Station along with
the RTU’s own data.
5.3.12 The RTU shall retain all configuration parameters of all devises
connected to the RTU through serial link such as Intelligent Electronic
Devices (IEDs) and/or I-Field surface units register and addresses of
slave devices.
5.3.13 Failure of an Intelligent Electronic Devices (IEDs) and/or I-Field

surface units connected in multi drop serial link shall not impact data
access from other units in the same link. All units in a multi drop link
shall be wired such that a unit can be removed from the link without
impacting other units.
6 Data Acquisition and Processing
6.1 Data Acquisition
6.1.1 The Data Acquisition shall be based on a communication protocol that

supports report by exception scanning (RBE). The dead band setting
for all analog values shall ensure conformance to each application data
transmission frequency update and data value resolution.
6.1.2 In events of RTU failure, the system shall mark all points that are
transmitted by the RTU with some visible indication that the data is not
current. For each point, this telemetry failed quality code shall not clear
until a value is subsequently received from the RTU or the slave device.
6.1.3 Data acquisition shall be automatic and transparent to the user.

The RTU data, when presented to the user on a display or used in any
of the functions defined by the project specification, shall reflect the
current field conditions as of the last scheduled acquisition of data for a
given point. The data shall be in the current engineering units as
defined in the real time database.
Page 13 of 39
6.2 Status Data Processing
The system shall process changes of the following types of status points as follow:
a) 2-state status. This is a 1-bit alarm that can decode 2 states to indicate the
status of a device that may be in one of two possible states. The user shall
be able to define the names of each state, e.g., ON and OFF, Open and
Closed. In addition, a color shall be associated with each state.
b) 3-state status. This is a 2-bit alarm that can decode 4 states. The user shall
be able to define the names and colors associated with each state, e.g., in
the case of a valve, Open, Closed and Moving, or failed.
6.3 Analog Data Processing

a) The system shall scan every analog input in the RTUs at predefined
scanning intervals. Any failure to complete a scan shall be marked with a
Failed data quality flag.
b) The user shall be able to specify the scale factor and offset to represent the
conversion factors for a linear conversion of the telemetered analog values
to engineering units.
c) The deadband associated with each limit is used to prevent multiple alarms
from being generated when the value hovers near a limit value.
d) Zero clamp option shall not be used for points that will perform totalization.
6.4 Pulse Accumulator Data Processing
6.4.1 The system shall send a command to freeze the accumulators either to
all RTUs or to selected RTU. However, this freeze command shall not
reset the accumulators in the individual RTUs. Upon receiving the
accumulator readings at the master station, the system shall
automatically calculate the difference from the last reading.
6.4.2 Alternatively, the RTU can implement a cyclic freeze based on

synchronized RTU clock, e.g., on hour change without freeze
command from SCADA.
6.4.3 The system shall also be able to retrieve accumulators at user-definable

intervals from 15 to 60 minute intervals.
6.5 Sequence of Events Data Processing
6.5.1 For power and substation automation applications that require

Sequence of Events data processing (SOE), the SCADA system shall
Page 14 of 39
process digital indications from the RTUs which are tagged with the
time of event occurrence.
6.5.2 Sequence of Events data shall have a 1 millisecond time stamp.
6.5.3 The system shall provide a filtered view for all SOE signals.
6.6 Supervisory Control Requirements (Operator Commands/Actions)
6.6.1 The system shall perform all control operations to field devices in a
safe and secure manner. The operator shall be promptly informed if
any anomalies occur during the control sequence.
6.6.2 The system shall allow the system operator at any HMI workstation to
issue controls commands ( Digital outputs and Analog outputs) to
operate equipment, close valves and/or change analog set point through
a select-before operate sequence and automatically monitor the field
device to ensure full and successful command operation. Control action
response times shall take the highest priority over all other data
communication.
6.6.3 It shall be possible for supervisory control applications either to be

scheduled, to run on demand or triggered by events.
6.6.4 The pulse output controls shall be implemented in the RTU with either
variable duration pulse or a train of pulses. The RTU shall monitor the
feedback value and stop the pulses when the setpoint is reached.
6.6.5 All output command shall utilize Select-Check-Before-Operate (CBO)

technique that requires secure handshaking with the RTU before any
controls are executed. In such cases, control of a point requires the
following exchange of messages:
Master to RTU - control point selection
RTU to Master - point address check-back
Master to RTU - control execution
RTU to Master - execute acknowledgement
6.6.6 If the Master Station does not receive proper acknowledgement of

either the select request or the execute command, a check-back failure
alarm shall be generated by the system. If the acknowledgements are
correct, but the expected status change does not occur within the
point’s control response timeout, a control failure alarm shall be
generated.
Page 15 of 39
6.7 Alarm and Message Handling
SAEP-368 shall be followed to provide the required consistency and avoid

configuration of unnecessary alarms. Priority shall be established by severity of
consequence and time to respond for each process variable, rather than a blanket
policy such as setting alarms on all analog inputs at 80%.
6.8 Data Historization
6.8.1 There shall be a configurable, real time and historical data collection
package to support trending, logging, and reporting.
6.8.2 On-line storage media shall be redundant.
6.8.3 When a process point is not collected, an unavailable code shall be

entered in the history file.
6.8.4 Option to store the value of any of the following parameters in on-line
history storage shall be provided:
 process input/output values/status
 calculated value/state
 controller parameters such setpoint, output, mode
 digital input/output states
 system alarms and events
6.8.5 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
6.8.6 The historical data collection package shall be capable of storing the
following number of recent alarm and events as a minimum:
10,000 Process alarms
5,000 System Alarms
5,000 Operator Actions
5,000 Engineering Actions.
Page 16 of 39
The above listed entry shall include as minimum: time and date of the
event, associate tag, equipment, user, description of the event on which
the alarm has been acknowledged.
6.8.7 Option to recall and display any data stored in on-line historical data
storage device shall be provided.
6.8.8 Option to transfer archived data in a format that can be displayed on a

PC using word processing or spreadsheet software shall be provided.
6.8.9 The historical database shall be able to store any data from the real-
time database on a periodic or snapshot basis definable by the user.
The historical information subsystem shall be able to provide storage
of unlimited quantities of historical data depending only on the
limitation of hardware resources (disk storage, etc.).
6.8.10 The stored historical data shall be accessible to other applications for
data review and analysis and to trending displays.
7 System Sizing, Spare Capacity and Expansion
7.1 System expansion and upgrading of system operating and application software
shall be achievable with no impact to the running facilities operation, without
losing the operator interface, without the loss of access to any control function
and without impact on the controlled or monitored process.
7.2 All displays on all workstations shall be updated and responsive to controls
throughout the alarm burst and during primary/backup server’s synchronization
process.
7.3 The system database size shall be expandable to handle the system expansion
requirements as stated in the project specific FSD without any need to expand
the hardware, perform any software change, or purchase additional licenses.
8 System Performance Requirements
8.1 All displays and graphics including fully active dynamic elements for up to
100 fields, displaying their current values, shall be completed within 2 seconds.
This call up time is measured when new graphic display is requested.
8.2 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.
8.3 Operator shall receive feedback indicating the start of the command/desired
Page 17 of 39
action within 2 seconds. Operator shall receive separate notification upon

completion of the action. If the system fails to respond to a command, a fail-to-
operate event shall be displayed.
8.4 The system shall update calculation algorithms, and dynamic fields of the
displays within one second of actual events and data values received at the
system realtime database.
8.5 SCADA host shall upload the RTU data after restoring the communication and
fetch the data in the real-time database with the correct time stamp.
8.6 Historical data display updates shall occur within two seconds of display call up.
8.7 The number of RTU per communication channel shall be determined based on
the following:
 Number and type of data points per RTU including the connected subsystem
IOs
 The Scan frequency specified in the project Functional Specification
Document (FSD) for each data point type
 Round trip delay of data pockets for the provided data network considering
the transmission medium, number of nodes, amount of traffic on the
SCADA LAN, the number of other requests being handled by intermediate
nodes and other services.
 Channel utilization shall be between 40-80% for serial communication.
 Channel utilization shall be between 10-30% for IP communication.
Commentary Note:
The average channel utilization can be estimated considering only the data
values to be routinely serviced by the channel. This typically includes status and
analog data acquisition or only analog data where status-by-exception reporting
is implemented. Any high-periodicity control commands should be added to the
routine data acquisition utilization. Where the channel will be subject to large
bursts of data acquisition loads (such as during a disturbance where report-by-
exception techniques are employed), the highest percentage of the desired
channel utilization range shall be used on estimating the channel utilization.
8.8 SCADA system components utilization, such as memory, disk space, CPU
loading, disk access shall not exceed 30% under normal conditions for the
system size and the future expansion requirement specified in the project
functional specification document.
8.9 The system shall be able to fully process a continuous alarm throughput of 50
alarms per second for at least 60 seconds on receipt of the alarms at the Master.
Page 18 of 39
8.10 SCADA server and workstation operating systems should be configured to

capture all necessary systems related events to detect performance and
availability related information.
 System alarms and failures
 CPU utilization
 Memory utilization
 IO rates (i.e., physical and buffer) and device utilization
 File store utilization (e.g., disks, partitions, segments)
 Applications
 Databases (e.g., utilization, record locks, indexing, contention)
 Network utilization (e.g., transaction rates, error and retry rates)
 Response time for SCADA System and application transaction
9 SCADA Connectivity
9.1 General
9.1.1 Optical Fiber communication networks shall be used for SCADA

Communication networks in all Oil and Gas and Power Monitoring
SCADA applications.
9.1.2 Wireless SCADA communication networks may be considered for

monitoring only Oil & Gas applications where loss of communication
would NOT result in potential safety hazard and/or operational impact
and non-Oil and Gas applications.
9.1.3 Each proposed wireless network application shall be submitted in

writing for P&CSD review and approval prior to being incorporated
into any project scope or design document.
9.1.4 The evaluation of the suitability and economy of wireless SCADA

communications shall be conducted jointly by P&CSD, Proponent and
FPD. The analysis shall consider potential impact on safety,
production loss and operational impact caused by a potential loss of
communications for a continuous period of 48 hours or more.
9.2 Design for Fiber Optic SCADA Long-Haul Networks
9.2.1 SCADA communications network connectivity shall be redundant and

designed to provide self-healing technique and seamless failover to the
backup link. Fiber Optics cable design and installation shall comply
with SAES-T-624 and SAES-T-625.
Page 19 of 39
Exception:
Star topology can be considered to connect single RTU to existing ring.
9.2.2 Industrial Ethernet Switches shall be used to expand existing Fiber

Optics communication networks. Wireless SCADA networks shall not
be used to expand existing wired networks.
9.2.3 If Peer to Peer Communications between ESD systems is required,

the network design shall follow the requirements outlined in
34-SAMSS-623.
9.2.4 All new SCADA communications networks where electrical power is

provided to the RTU from a central location, shall utilize hardwired
optical fiber communications networks between the SCADA system
and the remote site.
Commentary Note:
The use of Composite cable (optical fiber within the power cable) should
be evaluated as a cost savings measure where practically possible.
9.2.5 Diverse routing of redundant fiber optic cables shall be evaluated

based on a cost/benefit and risk analysis.
9.3 Communication Channels
9.3.1 The communication Data link shall be based on physically separated

network.
9.3.2 Services such as Voice, CCTV etc. that shares the same
communication network with the SCADA and terminate in the plant
shall be logically segregated. Segregation at the SCADA Master level
should be done using separate Network cards and switches.
9.3.3 In cases where the RTU protocol supports exception polling, the
communication software shall make use of it to optimize data
communication throughput and to provide rapid alarm throughput and
capture of multiple, rapid succession alarms.
9.3.4 When IP based data communication is used, the SCADA Master

station communication subsystem shall include functionality to limit
the number of open communication ports. Number of open
communication ports shall not degrade the overall system performance.
9.3.5 SCADA communication channels should be available to the RTU

continuously and without change to message routing to achieve 2 seconds
Page 20 of 39
or better response time.
9.3.6 The system shall verify the operation and periodically test and validate
the integrity of the primary and backup communication ports and the
communication channels and shall alarm on any failure. Availability
of the failed channel shall be checked using retries at least once every
minute.
9.3.7 The system shall alarm when any RTU fails to respond to a message
after three unsuccessful retries.
9.3.8 The system shall be configured to generate an alarm when

communications error rates exceed a predetermined limit.
9.3.9 The communication facility shall provide bidirectional data transfer

and shall meet the performance requirement for each application.
9.3.10 The SCADA system shall be configured to collect and historize critical
communications statistics covering the health and performance of each
communication channel for each RTU connected to the system.
A communications overview display shall be built to enable engineers
to quickly ascertain the health of the overall communications network.
9.4 Telecommunications Channels Redundancy
9.4.1 Redundant network interface in the RTU is generally not required.

However, for applications where backup communication route or
network is required per the FSD, i.e., wired and wireless, the SCADA
Master shall monitor the availability of both data channels.
9.4.2 When the SCADA Master declares any of the two communication
channels inoperative or marginal, it should discontinue its use, issue an
appropriate alarm to the local operator, and transmit all subsequent
messages on the backup channel.
9.5 Network Management
9.5.1 Recoverable and unrecoverable communications errors shall be logged

by the system for each communications channel and stored in a history
file.
9.5.2 A graphical display shall be provided to show the health status of the
Network infrastructure devices such as switches, routers, and gateways.
Page 21 of 39
10 External Interfaces
10.1 Configuration and implementation of the interface between SCADA Network and
corporate network shall comply with the following in addition to SAES-Z-010,
‘Process Automation Network’ requirements.
10.2 Communication software components and/or communication drivers required to

interface with the RTU shall be included in the SCADA server.
10.3 OPC usage shall be limited between the SCADA LAN components to exchange
data between the SCADA system and other application, such as DAHS.
10.4 OPC server and client shall conform to OPC Data Access (DA) and OPC
Historical Data Access (HDA) latest specification as minimum.
10.5 Software and/or Hardware gateways such as communication protocol converter

to OPC shall not be used.
10.6 Data exchange, read and write, with other plant process automation systems
shall be through industry standard interface.
10.7 Failures of external systems that interface with the SCADA shall be logged and
shall not degrade internal communications.
10.8 Interface between Intelligent Electronic Devices (IEDs) and/or I-Field surface
units shall use standard Ethernet port communication using standard open
protocol. Standard RS-232/485 Serial interface may be used if the slave device
is not equipped with Ethernet port.
10.9 The control system communication to Corporate Wide Area Network and other
non-control computer systems shall be designed to ensure that failure, request
for information shall not create network loading congestion or impact the
performance and availability of the SCADA System.
10.10 Integration to software packages such as process simulator, leak detection, etc.,
shall be through middleware as per 23-SAMSS-060.
10.11 When Serial Terminal Servers are required to connect the RTU's to the SCADA
LAN, the Terminal Server implementation shall comply with the following:
 The terminal servers shall be provided in redundant configurations where
each terminal server shall be connected to a Local Area Network (LAN) in a
redundant LAN configuration.
 The terminal servers shall be modular and easily expandable.
Page 22 of 39
 Shall not cause network jamming or degradation of the system caused by

faulty network device.
 The RS-232/485 serial data ports provided by the terminal servers shall be
capable of two-way serial communications.
11 Display Design Philosophy
11.1 When designing operator displays, a consistent approach shall be used for the
appearance (look-and-feel) and functionality. Highly animated objects that may
inadvertently divert the operator from important process information shall be
avoided.
11.2 The design approach shall include standardized approach for the entire facility:
 Layout - line sizes, equipment representation, orientation, fonts, titles,
etc.
 Data representation - process values and alarms.
 Color choices - process lines, control lines, process equipment, titles, etc.
 Display access and navigation
 How options are chosen via switches
 How control strategies are commissioned and de-commissioned
 How status pairs are defined (on/off, open/closed, start/stop, etc.)
 Control modes (manual/auto/computer etc.), either by color or by a small
text next to the controller.
 Data validity (invalid, out-or-range, unknown status) by color change.
11.3 Operator Interface
11.3.1 Operators shall be able to easily access specific displays and graphics
by selecting from a list of displays in directories or menus, or by typing
display or graphic names.
11.3.2 A link shall be provided to move between related displays and graphics
with different detail levels or of the same detail level.
11.3.3 Invalid values shall be highlighted with different color. Invalid value
can be out of range, no communication, etc.
11.3.4 Each display or graphic shall have a dedicated alarm zone which shall
display, as a minimum, the three most recent alarms.
Page 23 of 39
11.3.5 Graphics design shall maximize the use of single display with several
layers, such that the layers disappear/reappear (declutter/clutter)
automatically depending on the level of magnification.
11.3.6 The operator interface shall utilize a windowing graphical user

interface (GUI) environment such as Microsoft Windows, making
extensive use of mouse point-click-drag functions, pull-down menus
and interactive dialog boxes.
11.3.7 The operator interface software shall provide a graphical view of the
system, arranged schematically or geographically as defined by the
user.
11.3.8 The displays shall contain static graphical information, as well as

dynamic elements that reflect the information contained in the Master
computer’s database. Database point values displayed by such
dynamic elements may be either telemetered from RTUs or calculated
by the Master server.
11.3.9 Operator interaction with database points shall be by means of clicks of

the mouse on the dynamic display elements. This will include
operations such as controlling field devices, setting database values,
e.g., manual updates, acknowledging or blocking alarms and tagging
data points to inhibit control.
11.3.10 The user shall be able to use elements on the display as pushbuttons to
initiate pre-defined actions. These shall include, as a minimum, the
ability to:
 bring up pop-up notes
 bring up trend graphs
 bring up other displays
 bring up Microsoft Excel or Access based reports
 run command sequences
 access records in other databases
11.3.11 The user shall be able to define any number of displays. The operator
shall be able to go to a display by means of either a pushbutton or by
selection from a list. To facilitate navigation through the list of
displays, it shall be possible to organize the list in a hierarchical set of
named folders.
11.3.12 The Human Machine Interface (HMI) provides the operator interface
and visualization tools of the system via single or multiple monitor
Page 24 of 39
displays. Fully configurable HMI screen and displays, provides

realistic plant representation (dynamic and background).
11.3.13 The operator shall be able to:

 Access data stored in the real-time and historical databases.
 Issue and monitor supervisory controls.
 Use the administrative displays to perform managerial functions.
 Activate the Database Configuration and other utilities.
11.3.14 The following types of displays shall be provided for use by the
operators:
a) Single Line Display shall consist of the user’s process equipment
and pipelines network with the current analog values and status
of devices superimposed on the map. The display(s) shall allow
the operator to select displayed objects in order to issue or inhibit
controls, acknowledge or block alarms, or modify operating
parameters such as limits.
b) Alarm Summary Display shall show a user-customizable list of
alarms that are in the system. The operator shall have the ability
to acknowledge and/or block alarms and to control the operation
of the audible alarm. This display shall be configurable by the
operator by means of filtering by station, zone of responsibility,
alarm priorities, chronological or reverse chronological order,
typeface and size of text, blocked alarms, any combination of
active, cleared, acknowledged or unacknowledged alarms.
c) Operator Summary Display shall show the operations messages
that have been logged by the system. This display shall be
configurable by the operator by means of filtering by alarm
priority, station, zone of responsibility, specific database points,
time range, typeface and size of text.
d) Tabular Data Display shall list the status and analog points by
station and system wide. The information shown on this display
shall include the point names, descriptions, current values and
quality codes and other parameters from the database, e.g.,
transition counts and alarm limits. This display shall be used for
operation and control in the sense that from this display, the
operator can perform point operations such as control, tag, alarm
acknowledge or block, as well as modify operating limits and
reset transition counts.
Page 25 of 39
11.4 Navigation through Displays
11.4.1 Any graphic display shall be accessible via no more than three operator
actions.
11.4.2 When a graphic display has an associated primary control display, e.g.,
a group display, the graphic shall have a target that immediately calls
up the associated control display. This target shall be located in the
same location on every graphic that uses this feature.
11.4.3 When using a windows environment consideration must be given to

prevent the Operator from opening too many windows and potentially
masking important process information.
11.5 General Operator Graphics Requirements
11.5.1 All graphics shall include graphics title, Date & Time and graphics
Description at standard locations.
11.5.2 Process and control line crossovers shall be minimized. Line breaks
shall be used to indicate that crossing lines do not join.
11.5.3 Main process lines for each graphic shall be bold with secondary lines
being of finer width.
11.5.4 Process lines shall either be drawn horizontally or vertically.
11.6 Faceplates
11.6.1 Faceplates shall show dynamic process and status information about
process elements such as a single control loop, pump, MOV, etc.
11.6.2 Faceplates shall be provided as separate displays or as graphic

elements. If separate faceplate displays are provided, it shall be
accessible for any tag on a graphic display with a maximum of two
operator actions.
11.6.3 Faceplates shall display the Tag ID, Tag descriptor, Process input,
setpoint, output values displayed numerically with engineering units
and in bar graph representation, Auto/manual mode and remote/local
setpoint status, 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.
Page 26 of 39
11.7 Operator Graphics
11.7.1 All control, monitoring, and status attributes of any tag shall be
displayable on graphics. For analog points, this requirement includes
measurement, setpoint, span, alarm limits, and output. For digital
points, this requirement includes input and output status. Status
information includes alarm status, control mode, and control status.
11.7.2 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), and from 0 to 5 decimal places.
The numeric formatting shall be configurable on an individual basis.
11.7.3 Each state of a multi-state device shall be indicated by a unique

foreground/background color combination.
11.8 Trend Displays
11.8.1 Option to trend both real-time and historical data in the same trend
shall be provided.
11.8.2 All operator workstations shall be capable of displaying trends.
11.8.3 Trends shall be provided in adjustable window size, which could be

full, half screen size, etc.
11.8.4 Text accompanying the trend shall show the following for each tag: tag
ID, minimum scale value, maximum scale value, engineering units,
and current value.
11.8.5 The time periods and process value scales available for trend displays
shall be selectable.
11.8.6 Real time trends shall be updated every two seconds with actual
process data.
11.8.7 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.
11.8.8 Option shall be provided 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.
11.8.9 Scale and time span adjustment shall be provided on trend displays.
Page 27 of 39
11.9 Diagnostic Displays
11.9.1 Dynamic Communications Overview display shall be provided 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 systems.
11.9.2 Diagnostic displays shall be provided to show the operational status

and error conditions for all system components.
11.9.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.
11.9.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.
11.9.5 Communications diagnostic displays shall show errors for each of the
redundant paths.
11.9.6 System displays shall be provided for cabinet temperature alarms and
system power faults.
11.10 Data Quality
The system shall display data quality indications for analog value and status
point indication. These shall include the following as a minimum:
a) Telemetry failed (value was not reported last scan).
b) Manually set
c) Calculated from manually set data.
d) Alarm blocked for analog points with alarm settings.
e) Digital and analog output Marked Interlocked
Page 28 of 39
11.11 Marked Tag Management
11.11.1 When a controlled device or a line fed by a controlled device requires

maintenance, it is required that the system provide a facility for limiting
control of that device. The system shall allow operators to inhibit
control of devices by means of a secure, multi-level marking feature.
11.11.2 Each point shall be able to be provided with a visual attribute showing
that the point has one or more tags on each display where that point is
shown.
11.11.3 The system shall permit no means of bypassing the control inhibit
caused by a mark. This applies to any and every application supplied
by the vendor or written by the user using the vendor’s API.
11.11.4 A group mark function shall be provided that allows an operator to

define a marked point, select multiple points and apply the same
marking to all selected points.
11.12 Control Functions
The operator shall be able to perform all the basic monitoring and control
functions from graphic displays. These functions shall include, but not be limited
to, changing process variables, alarm logs, set-points, switching control modes,
manually driving outputs, or initiating maintenance bypasses for input points.
11.13 Reports
11.13.1 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.
11.13.2 The default location for the report printouts shall be the operator
console from which the report was requested.
11.13.3 Reports shall be configured to be activated on Demand (operator

request), Scheduled (shift, daily and monthly) and/or on Event.
11.13.4 The system shall include dedicated printer(s) for reports only.
12 Security and System Access
12.1 SCADA System Isolation
12.1.1 The SCADA system LAN shall be isolated from the internet, Office
network and any third party network through the use of firewall with
Page 29 of 39
Demilitarized Zones (DMZ) architecture as minimum in accordance

with to SAES-T-566 Plant Demilitarized Zone (DMZ) Architecture.
12.1.2 Existing (Shared with DCS) and/or new firewall shall provide
dedicated interfaces for the corporate network and a dedicated and
separate interface for the SCADA LAN.
12.1.3 Data Historian shall be placed in the DMZ where it shall interface with
a Historian data collector installed on the SCADA LAN.
12.1.4 Firewall configuration and rule setting shall be implemented in

accordance to SAEP-99.
12.2 Access Control
12.2.1 Access to SCADA Systems shall be restricted only to person(s) with

legitimate business requirements.
12.2.2 User access to a system shall be restricted by means of User IDs and
Passwords or other suitable technologies for identification and
authentication of users.
12.3 User Roles
12.3.1 User Roles shall be created to facilitate application of individual user

access privileges based on the user role or user group to which they are
assigned.
12.3.2 The following user roles shall be configured as a minimum.

Additional user roles may be created based on the particular needs of
the facility:
a) Process Operator: This user role shall be configured to provide
access privileges for process operators and control board
operators. Access privileges shall be defined to enable
monitoring and control of equipment located within specific
process area(s) to which the role is associated. Monitoring of
other process areas without the ability to control these areas is
permissible. View-only access to function block parameters such
as alarm limits and tuning parameters shall also be granted.
This role shall have a restricted user profile so that a user will not
be able to install programs or change software configuration,
access floppy disk or CD drives, or any removable media.
Page 30 of 39
Commentary Note:
It may be necessary to define multiple Process Area Operator

User Roles. Each process area in a plant will typically have a
separate user role. Access to control functions from the
SYSTEM will be limited to those process areas associated with
the specific user role.
b) Process Area Supervisor: This user role shall include all of the
privileges assigned to the area process operator. In addition, any
requirements for special authority commands required for control
of the process area shall be granted to the Process Area
Supervisor role.
c) Maintenance Engineer/Technician: This user role shall provide
access to system and instrument diagnostic and troubleshooting
tools. Access to utilities required for backup and restore of
system information shall also be granted. Other privileges
required to enable maintenance functions (such as replacement of
failed components) shall also be granted as required. View-only
or monitoring-only access to process graphics and function block
parameters shall also be granted.
d) Process Engineer: This user role is used to grant access
privileges for process engineers associated with a particular
process area. Access privileges required for monitoring and
control of equipment associated with the particular process are to
which the role is associated shall be granted. Access privileges
required to modify function blocks parameters (such as alarm
limits and tuning constants) shall also be granted. Read-write
privileges for function block parameters shall be limited to those
function blocks associated with the particular plant area to which
the role is associated.
e) System Engineer: This user role shall be used to grant access
privileges to persons responsible for the configuration and
maintenance of the system. Access privileges required to
perform functions necessary for the configuration and support of
the system shall be granted. Permission to modify user role
privileges, user accounts and passwords shall not be granted.
f) System Administrator: This user role shall provide access to the
entire system. Assignment of users to this role shall be restricted
to a limited number of highly trusted and competent employees.
This role shall also contain privileges necessary for configuration
of user role privileges and assignment of user to particular user
roles. The role shall contain privileges necessary to administer
Page 31 of 39
individual user Ids and passwords as well as system and

application user Ids and passwords. The role shall provide access
to utilities required for monitoring and auditing of system access
activities.
g) View Only: This user role shall be used to provide monitoring
only access of all process areas within the plant. Access to
graphics which are specifically required for control operations
(such as controller faceplates) shall be restricted. Access to
system diagnostics, maintenance and configuration utilities shall
also be restricted.
12.4 User Accounts
12.4.1 Each User shall be assigned a unique User ID. All unneeded vendor-
default user accounts, including guest, service, system and application
defined at both the SCADA application level and operating systems
supporting SCADA application shall be disabled.
12.4.2 Where applicable, all individual User IDs formats should conform to
corporate guidelines as highlighted in Section 11.1.1 within “Computer
Accounts Protection Standards and Guidelines.11.1.1.3.6 “USER ID
CONSTRUCTION” in IPSAG-007.
12.4.3 Systems capable of displaying a warning banner, upon logon, shall be

configured to display the following text “This Computer is for
Company business use only. This system may be monitored as
permitted by law. Unauthorized use may result in criminal
prosecution, termination or other action”. For operator consoles, a
printed sticker may alternatively be used.
12.4.4 Users shall be granted access privileges by assigning the user to a User
Role applicable to their particular job function. Access privileges
which have been defined for that User Role shall be inherited by the
User.
12.4.5 The system shall be configured to require an individual User ID and

password for authentication purposes prior to being allowed access to
any station connected to the system with the exception of the operator
workstations located within operator consoles in the Central Control
Room (CCR) only.
12.4.6 Operator workstations located within operator consoles in the CCR can
be configured with a common 'CONSOLE XX' operator account.
This account can be shared by individuals assigned to the particular
Page 32 of 39
console only. These accounts shall not be valid on any other stations
connected to the system.
12.5 User Account Passwords
12.5.1 Every User ID shall have an individual password.
12.5.2 The system shall be configured to require a minimum password length

of eight characters.
12.5.3 Passwords shall be transmitted and stored in encrypted format.
12.5.4 The system shall be configured to enforce password uniqueness.

A minimum of three unique passwords must be entered before a
password can be re-used.
12.5.5 Password Construction
The system shall be configured to enforce password complexity rules.
12.5.5.1 Easy guessable passwords must be avoided at all times.

As a minimum a password must be constructed as follows:
12.5.5.2 A password must contain at least two of the following four

characteristics:
 Lower case characters a-x
 Upper case characters A-Z
 Digits 0-9
12.5.6 Punctuation characters e.g., ! @ # $ % ^ & *, etc., Management of

passwords, User IDs and User Role privileges shall be done via a
central server.
12.5.7 The system shall be configured to require passwords to be reset for all
User IDs every six months.
12.5.8 Facilities shall be provided to enable user account passwords to be

changed at any workstation connected to the system. A password
changed at one location shall be automatically updated at all stations
where the account is valid.
12.5.9 The system should issue a password expiration notification to the user
at least 10 days prior to password expiry date.
12.5.10 Passwords shall be masked on the screen while being entered
Page 33 of 39
12.5.11 In order to change user account passwords, users should always be

required to provide both their old and new passwords, if supported by
the system.
12.6 Application and System Accounts and Passwords
12.6.1 Application Accounts may require the account name and/or passwords
to be hardcoded into startup scripts. Passwords used for Application
Accounts shall not be stored in un-encrypted format. Passwords used
for Application Accounts are excluded from the six month password
aging policy described above.
12.6.2 System Accounts require special consideration and shall be managed

by the system administrator. System Account default passwords shall
be changed prior to commissioning the system. System account
passwords shall not be stored in un-encrypted format and shall be
excluded from the six month password aging policy described above.
12.7 Anti-Virus Protection
12.7.1 Anti-virus definition files shall be updated on all SCADA servers and
stations. Centralized server on the DMZ shall be used if available.
12.7.2 Vendor approved/certified Anti-virus software shall be installed and

configured on all Windows based SCADA workstations and servers.
12.7.3 SCADA equipment shall have Anti-virus software installed with the
latest vendor approved software versions and virus definition files.
12.7.4 Anti-virus software shall not negatively impact the performance of the
workstation and overall performance of the SCADA system and shall
be configured according to vendor procedures, including the different
configuration options within the scanning software such as:
12.7.4.1 On-Access Scanning
12.7.4.2 Full Scanning
12.7.4.3 Buffer Overflow Protection
12.7.4.4 Directories to be excluded from scanning
12.8 Operating System Software and Vendor Software Patch Management
12.8.1 The vendor's recommended procedures for the upgrade of OS software

and patch installation shall be followed.
Page 34 of 39
12.8.2 Access privileges for the upgrade of OS software and OS patch

installation shall be assigned to SCADA System Administrator only.
12.8.3 OS software and patches shall not be installed unless they have been
tested and certified by the vendor as being compatible with the
SCADA System software.
12.8.4 New SCADA System’s shall be deployed with the latest stable vendor
supported operating system security and operational patches.
12.9 If approved by SCADA System application vendor, audit policies on SCADA

System’s should be configured to capture the following:
12.9.1 SCADA System Audit Policies
12.9.1.1 System Events
12.9.1.2 Account Management
12.9.1.3 Logon Events
12.9.1.4 Privileged activities
12.9.2 SCADA System Logs
12.9.2.1 SCADA System’s shall be configured to log actions

performed by SCADA System administrators and
maintenance personnel
12.9.2.2 Event logs shall be configured to include user names,

time/date and event type.
12.10 Retention and archival of security audit logs shall be developed in accordance
with Corporate Data Protection and Retention INT-7 policy. The following
requirement should be considered:
12.10.1 The retention period for audit logs shall be set for 3 months as a
minimum.
12.10.2 Minimum storage capacity for logs shall be 500 Gb.
12.11 Security Management Practices
12.11.1 All workstations which are connected to the SCADA system and are
not located on an operator console within the CCR shall be configured
to automatically lock the workstation or switch to “view-only” user
environment after it has been idle for 30 minutes or longer. Password
Page 35 of 39
re-authentication from either the last user or the system administrator

shall be required to unlock the station.
12.11.2 All Workstations, Servers, RTUs and networking equipment, such as

switches or hubs, shall be housed in lockable cabinets or consoles to
prevent physical access to the equipment from unauthorized users.
12.11.3 All unused ports on SCADA Process Control Network equipment shall
be deactivated.
12.11.4 All login events shall be recorded by the system. Login events shall be
recorded with date and time of login, user account, and location of
login. Records of logins shall be maintained on the system for a
minimum period of six months.
12.11.5 The system shall record all failed login attempts. If available,
functionality shall be provided to automatically notify the system
administrator after five consecutive failed login attempts has been
exceeded.
12.11.6 Failed login attempts shall not initiate an automatic 'lockout' of the user
account.
12.11.7 The system shall be able to produce a report of stale user accounts.
Stale accounts are user accounts which have not been used on the
system for a period of three months or longer. The system shall have
the produce a report of stale user accounts.
12.12 System Recovery Planning
12.12.1 Procedures for performing an incremental and complete backup and

restoration/recovery of the SCADA system and data shall be
documented.
12.12.2 SCADA System’s shall be configured to automatically take backup of

control database, system configuration, and other vital information to
hard-drive at a minimum of once per week.
12.12.3 A minimum of two sets of complete backup and recovery data for each
workstation, server and RTU shall be stored offline.
12.12.4 A complete system backup shall be performed on all new installations

of SCADA equipment. This includes operating system and
configuration files.
12.12.4.1 The backup shall be tested and verified.
Page 36 of 39
12.12.4.2 two copies of the backup are made. One copy shall be
stored in a secure onsite location and the other copy shall be
maintained at a secure off-site location.
12.12.5 The SCADA System shall be configured to store the online backup in a
hard-drive different from the SCADA System being backed up.
12.12.6 Process control equipment that contains data storage shall be sanitized
in accordance with GI-0299.120 prior to disposal.
12.13 Operating System Hardening
12.13.1 SCADA equipment shall be deployed with vender supported security

hardened operating system.
12.13.2 The secure configuration baselines shall be thoroughly tested by the

vendor and shall be provided to the SCADA System administrators to
enable them to support and administrator the SCADA System
equipment after deployment.
12.13.3 Vendor hardening procedure shall be included as part of the CDR

documents for review and approval.
12.13.4 Vendor shall identify any possible system performance degradation as

result of security hardening.
12.14 Delegation and Support
12.14.1 A risk assessment, with participation from P&CSD, IT and the Plant
shall precede the official delegation of support responsibilities of
SCADA System components to IT or other support entities.
12.14.2 Any Delegation of support and management responsibility must be

approved by the plant Manager through a Service Level Agreement
(SLA).
12.15 Disposal and Sanitization
Process control equipment that contains data storage shall be sanitized in

compliance with GI-0299.120, when disposed of.
13 Instrument Asset Management System (IAMS)
13.1 When an Instrument Asset management System, either integrated or separate

from the SCADA operator/engineering workstation is provided for smart device
configuration, documentation, calibration, and diagnostics it shall be in
Page 37 of 39
accordance with SAES-J-905, Instrument Asset Management Systems (IAMS)

and shall comply with the requirements in 34-SAMSS-911 with the following
exceptions:
a) Device diagnostics data access shall not impact the timely processing of the
process data.
b) Access and monitor the status, events, and operating conditions of the field-
connected devices without interfering with the SCADA process Data
acquisition functionality.
Commentary Note:
IAMS Continuous and automatic monitoring for Smart Instruments diagnostic

data will put additional and unnecessary traffic that will consume large
percentage of the available bandwidth. To reduce traffic and alert operators of
potential anomalies, a common alarm point shall be provided to alert operator of
possible instrument fault. Maintenance technician can then use the IAMS for
further analysis and diagnostic.
14 Documentation
14.1 Detailed SCADA/RTU data link analysis and bandwidth calculation and RTU
traffic aggregate showing SCADA data transfer performance shall be performed
for each application. Analysis report shall be provided during the project PDR
phase.
14.2 Standard documentation shall be available and provided as defined in 23-

SAMSS-020.
14.5 The application 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.
15 Inspection and Testing
15.1 Saudi Aramco Inspection Requirements shall be in accordance to and as defined

in 23-SAMSS-020 for SCADA Master Station and 23-SAMSS-030 for RTU.
16 System Maintainability
16.1 The system shall be designed such that the user will be able to maintain the
SCADA system with minimum reliance on vendor’s services.
16.2 The system shall include all the necessary software for configuration of the
system and maintenance of the database.
Page 38 of 39
Revision Summary
10 November 2013 Major revision.
Page 39 of 39

Saes Z 004

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

Saes Z 004

Uploaded by

Copyright:

Available Formats

Engineering Standard

SAES-Z-004 10 November 2013

Saudi Aramco DeskTop Standards

Previous Issue: 25 October 2010 Next Planned Update: 10 November 2018

Copyright©Saudi Aramco 2013. All rights reserved.

2 Conflicts and Deviations

 Saudi Aramco References

Saudi Aramco Engineering Procedures

Saudi Aramco Engineering Standards

Saudi Aramco Materials System Specifications

Saudi Aramco Inspection Requirements

Saudi Aramco General Instructions

Storage Devices and Industry Codes and Standard

Saudi Aramco Information Protection Manual (IPM)

4.1 Acronyms and Abbreviations

SAMSS Saudi Aramco Material System Specifications

4.2 Words and Terms

Address: An identifying name, label, or number for a data terminal, source, or

Analog data: Data represented by scalar values.

Application Account: refer to the account name used to run applications as

Application Software: The software written specifically to perform functional

Availability: The percent of time a system or component remains on line and

Bidirectional: Providing for information transfer in both directions between

Buffer: A device in which data are stored temporarily in the course of

Command: Commands are sent by operators or by applications. Commands

Communication channel: A facility that permits signaling between two

Communications Subsystem: The hardware and software that performs the

Configurable: The capability to select and connect standard hardware modules

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

Cycle: The scanning of inputs, execution of algorithms and transmission of

Faceplate: A graphic element that mimics the front panel of an analog

Fail-Over: Occurs automatically without user intervention, transparent to the

Intelligent Electronic Devices (IED): An intelligent electronic device that

Logs: Files or printouts of information in chronological order.

Master Station: Server or servers and software responsible for communicating

Protocol: A strict procedure required to initiate and maintain communication

Redundant Configuration: A system and/or subsystem that provides for a

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

Scan: The process by which a data acquisition system interrogates remote

Security code: A group of data bits calculated by a transmitting terminal from

Self-Diagnostic: The capability of an electronic device to monitor its own

Supervisory control: A telemetry based process control command initiated

System Account: refer to account names used by the operating system.

Tag: A collection of attributes that specify either a control loop or a process

Transaction: A sequence of messages between cooperating terminals to

5 System Design Requirements

The SCADA system can support any type of telecommunication technologies.

A detailed Performance analysis shall be conducted for each application

5.1.2 The analysis shall address SCADA server(s) loading, bandwidth

5.1.3 Data communication channel loading and capacity calculation shall be

5.1.4 Communication protocol(s) used to communicate with the RTU and

5.1.5 All functional requirements shall be implemented using the protocol’s

functional requirements, vendor shall provide full documentation of the

5.2 Design Architecture

5.2.1 The SCADA software shall be based on Client/Server architecture.

Use of SCADA on virtualized servers, thin clients operator/engineering

5.2.3 SCADA system redundant components shall include Human Machine

5.2.6 Data collector applications such as PI-OPC Interfaces, etc., shall be

5.2.7 All SCADA servers and workstations including network components

5.2.10 Remotely located Engineering and/or Maintenance work station(s)

5.2.11 The network connectivity for the remote Engineering and/or

5.2.12 For application requiring redundant RTU communication modules, the

5.2.13 There shall be a minimum of one dedicated engineering workstation