Sabp Z 074

Best Practice
SABP-Z-074 28 December 2015

Guidelines for Virtual Servers and
Thin Clients for Process Automation Systems
Document Responsibility: Process Control Standards Committee
Contents
1 Introduction......................................................... 2
2 Conflicts with Mandatory Standards................... 2
3 References, Acronyms and Definitions.............. 2
4 Background........................................................ 3
5 Virtual Servers.................................................... 6
6 Recommended Architecture by Plant Type...... 10
7 Thin-Clients………………………..………......... 17
8 Backup and Restore……………....................... 19
Previous Issue: New Next Planned Update: TBD

Page 1 of 21
Primary contact: Kinsley, John Arthur (kinsleja) on +966-13-8801831
Copyright©Saudi Aramco 2015. All rights reserved.

Document Responsibility: Process Control Standards Committee SABP-Z-074
Issue Date: 28 December 2015 Guidelines for Virtual Servers and
Next Planned Update: TBD Thin Clients for Process Automation Systems
1. Introduction
1.1 Scope
This Best Practice provides information and guidelines for the deployment of
Virtual Servers and Thin client devices in Process Automation Systems.
1.2 Disclaimer
This SABP is not intended to detail all aspects of the configuration and does not
include adequate information to enable it to be used as an instruction or user
manual.
2. Conflicts with Mandatory Standards
In the event of a conflict between this Best Practice and other Mandatory Saudi Aramco
Engineering Requirements (MSAERs), the Mandatory Saudi Aramco Engineering
Requirements shall govern.
3. References, Acronyms and Definitions
Specific sections of the following documents are referenced within the body of the
document. Material or equipment supplied to this best practice, shall comply with the
referenced sections of the latest edition of these specifications. Where specific sections
are not referenced, the system shall comply with the entire referenced document.
3.1 References
Saudi Aramco Engineering Procedure

SAEP-99 Process Automation Networks and Systems Security
Saudi Aramco Engineering Standards

SAES-Z-001 Process Control Systems
SAES-Z-004 Supervisory Control and Data Acquisition Systems
SAES-Z-008 Terminal Management Systems
SAES-Z-010 Process Automation Networks Connectivity
Saudi Aramco Materials System Specifications

23-SAMSS-010 Distributed Control Systems
23-SAMSS-020 Supervisory Control and Data Acquisition (SCADA)
Systems
Page 2 of 21
Issue Date: 28 December 2015
Next Planned Update: TBD Virtual Servers and Thin Clients for Process Automation Systems
23-SAMSS-050 Terminal Management Systems
Saudi Aramco Engineering Report

SAER-6467 Virtualization and Thin-client HMI for Process
Automation Systems
3.2 Acronyms
HMI - Human-Machine Interface

PAS - Process Automation Systems
PAN - Process Automation Network
PCS - Process Control Systems
P&CSD - Process and Control Systems Department
TC - Thin-client
V&TC - Virtual Server / Thin Client architecture
3.3 Definitions
Process Automation System (PAS): The system consisting of all four layers of
complete process automation: instrumentation, control, plant information and
optimization, and enterprise.
Process Control System (PCS): The integrated system which is used to

monitor and control an operating facility. The PCS consists of Distributed
Control Systems and their related auxiliary systems which are connected
together at the Process Control Network and Plant-wide Information Network
level to form a single integrated system.
Process Automation Network (PAN): PAN is a plant-wide network

interconnecting Process Control Systems and interface to the WAN. A PAN
does not include proprietary Process Control Networks (PCN) provided as part
of a vendor’s standard process control systems.
Process Control Network (PCN): A proprietary process control network

provided as part of a vendor’s standard process control system.
Virtual Instance: A complete software image of a workstation or server which

runs on a virtual server. Multiple virtual instances may run on a single virtual
server at the same time.
Saudi Aramco: Company General Use

Page 3 of 21
4. Background
Process Automation suppliers have adopted Virtual Server and Thin-client technologies
for their automation systems. Virtualization can refer to a variety of computing
concepts, but it usually refers to running multiple operating systems and associated
software applications on a single physical server, called a virtual server. While most
computers have a single operating system, virtualization software, called a Hypervisor,
allows a computer to run several operating systems at the same time.
Through virtualization, users are able to run multiple instances of traditional PCs or
servers on a single virtual server. The figure below is a conceptual diagram of a virtual
server which hosts four different traditional workstations.
Figure 1 - Conceptual Diagram of Virtual Server
This technology offers many advantages over traditional PC based workstations and
servers. Hardware obsolescence of PC based workstations used in Process Automation
Systems (PAS) is a major challenge for operating facilities. Virtualization software
minimizes the dependency of the Operating System (OS) and Vendor Application
software from the physical hardware (PC) on which it is running. Virtual Servers will
enable replacement of failed servers with newer model servers without impacting the
operating systems / application software running on the server. In the traditional
architecture, replacing an old model workstation or server with a newer model typically
requires upgrading of the automation application software. This is a costly and complex
process which could involve conversion of process graphics and control databases.
This is expected to result in a longer lifespan of the Process Automation application
software.
Access to the automation applications running on the virtual servers is still a requirement
and this is accomplished by providing a remote desktop connection from a device located
Page 4 of 21
at the operator / engineering console to the virtual server. Any computer running a
Windows operating system can be used to provide this remote connection; however, there
are significant advantages of using Thin-client (TC) devices. Thin clients are compact
devices which run an embedded Windows operating system. They utilize Remote
Desktop Protocol (RDP) to connect to an application running on a virtual server.
Communications with the virtual server is provided using standard Ethernet network
connection. This enables a user at the TC to interact with the automation application
which is running on the virtual server. The figure below shows the thin-client concept.
Figure 2 - Conceptual Diagram of Thin-clients
Thin-clients offer several advantages over traditional desktop PCs. Most significant is
they are much more reliable than traditional PCs because they have no hard-drive or
other moving parts. This increases the reliability and lifespan of thin-clients vs.
traditional PC desktops. In addition, Thin-clients typically do not contain any vendor
specific application software; making change-out of one TC device with a newer model
much simpler.
The adoption of Virtual Server and Thin Clients for Process Automation systems is
expected to significantly increase the reliability of the HMI layer. It is also expected to
extend the timeframe between automation applications software upgrades thereby
reducing total cost of ownership. Refer to Saudi Aramco Engineering Report,
SAER-6467, “Virtualization and Thin-client HMI for Process Automation Systems”
for details on the expected benefits and costs for implementation of V&TC for PAS.

Page 5 of 21
5. Virtual Servers
5.1 There are three common architectures for achieving redundancy of virtual
servers. Details and the advantages / disadvantages of each contained below:
 Independent Virtual Servers
 Redundant Virtual Servers
 Blade Virtual Servers
5.1.1 Independent Virtual Servers: In this architecture, each virtual server is

configured to host separate virtual instances. Virtual servers are
physically separate and there is no automatic fail-over capability
between virtual servers. Each server will have the software image of the
virtual instances which run on the server stored on the servers’ physical
hard-drive. Servers are provided with RAID hard-drives to provide
hardware redundancy of the data storage. Redundancy is achieved by
assigning virtual instances of redundant operator workstations and/or
servers to different physical servers. Automation applications may only
be run simultaneously on redundant servers if the automation software
supports application redundancy (e.g., redundant SCADA servers).
While this is the simplest and most cost effective architecture, it does not
provide any automatic failover or restart of virtual instances on the
redundant server in the event of a server failure. Restarting virtual
instances on the redundant server must be done manually. In order to do
this, the redundant server must have up-to-date images of the virtual
instances which are required to restart. In order to facilitate use of the
most recent virtual image, it is recommended to configure automatic
backup of virtual instances on each server on a periodic basis and to
store the backup images on a separate physical server or network storage
device.
Page 6 of 21
Figure 3 - Independent Server Architecture
5.1.2 Redundant Servers with shared Network Storage (SAN):

This architecture utilizes two physical virtual servers. Each server is
connected to a network storage device or SAN. The SAN contains the
virtual software images which are started and run on the virtual servers.
In this architecture, the automation applications, running in virtual
instances, are only active on one of the virtual servers at any given time.
In the event of a failure of one virtual server, the virtualization software
can be configured to start and run the virtual instances on the backup
virtual server automatically. This architecture is sometimes referred to
as 'High Availability’ since the virtualization layer manages the server
redundancy and is not dependent on application redundancy.
This architecture achieves a higher level of availability for automation

applications, but is also more costly and more complex to manage.
A typical example of the architecture is shown in the figure below:

Page 7 of 21
Figure 4 - High Availability Virtual Server Architecture
5.1.3 Blade Servers: The Blade Server architecture combines automatic

failover of virtual servers and shared data storage into a single chassis.
The chassis contains multiple rack mounted servers which interface with
RAID hard-drives which are integrated into the chassis to achieve high
availability. In effect, it combines the three separate devices shown in
Figure 2 above into a single chassis. A single blade chassis may contains
up to eight different blade servers. Figure 3 below shows the typical
hardware used with this architecture.
The advantages of blade servers is that it simplifies the server

infrastructure by eliminating the need for a separate storage area
network. The disadvantages are cost and availability. Blade chassis can
accommodate up to eight different blade servers. They are cost effective
if all eight blade servers are required. However, for applications which
require four or less servers, they are more costly than individual servers.
Another disadvantage of blade servers is that all servers in the chassis
utilize the same hard-disks installed in the chassis. Chassis disk storage
for blade servers is typically provided with RAID 10 configuration;
however, the raid controller is still a single point of failure and thus has
the potential to affect all servers in the chassis. In order to ensure
availability; segregation virtual instances to multiple chassis’ would be
Page 8 of 21
recommended making the overall cost higher than the normal high
availability design.
Figure 5 - Blade Server Architecture
5.2 General Recommendations for Virtual Servers
5.2.1 Process Automation Systems which utilize more than two (2) virtual
servers, should have as a minimum, a separate physical server which
would serve as the domain controller for the virtual servers and also the
virtual server management station. Note that both applications may be
combined on the same physical server.
5.2.2 Redundant instances of virtual operator workstations within an operator

console should be assigned to different virtual servers. As an example, if
there are four operator workstations in an operator console in a
traditional PC based architecture, in the virtual environment, two of the
operator workstation images should be assigned to one virtual server and
the other two operator workstation images should be assigned to the
another (redundant) virtual server within that operating area.
5.2.3 Virtual Server Network Interface Cards (NIC) should not be shared
between the primary process control network and other networks, such
as the PAN. Where access is required to more than one network,
separate physical NICs shall be used to connect to each network.
5.2.4 Separate server(s) (virtual or traditional) should be used to host any

application which would normally reside within the plant Demilitarized
Zone (DMZ).

Page 9 of 21
5.2.5 Operator workstations hosted on virtual servers shall have a dedicated

thin-client at the operator console for each virtual workstation hosted on
the server.
6. Recommended Architecture by Plant Type
6.1 Single Train GOSP
These facilities normally have 3 plant areas, Crude, Gas, Utilities. The normal
configuration is to have 2 operator workstations for Crude and two for Gas
and Utilities. In the virtual architecture, two virtual servers is adequate.
Redundant workstations for each plant area would be segregated to different
virtual servers. The DCS, ESD, VMS and CCS engineering workstations and
other process automation applications such as ALMS, IAMS, PI scan nodes, etc.
would be distributed between the two servers. The operator console should have
4 thin-clients, each with their own video display, keyboard and mouse. Two of
these thin-clients would normally be configured to connect to virtual instances
on one of the redundant virtual servers and the other two thin clients would be
configured to access virtual instances on the other redundant virtual server.
Two additional thin-clients are required for maintenance and engineering
functions. These thin-clients should be configured to connect to any of the
virtual servers hosting the engineering and maintenance applications.
A separate physical server may be required to host the system domain controller
and virtualization management software.
6.2 Multi-Train GOSP
A multi-train GOSP is one which has more than one GOSP train within the same
plant fence. Manifa Central Processing Facility (CPF) and Khurais Central
Processing Facility are typical examples. Plants this size will typically have
separate Process Interface Buildings (PIBs) for each plant area. Manifa CPF has
three GOSP trains. The table below show the plant areas and PIBs at Manifa CPF:
PIB #1 - GOSP Train #1 PIB #5 - Gas Compression

PIB #2 - GOSP Train #2 PIB #6 - Utilities
PIB #3 - GOSP Train #3 PIB #7 - Cogen
PIB #4 - WOSEP, Crude storage and shipping CCR - Engineering/Maintenance Console
Each plant area has an operator console in the CCR and Maintenance /
Engineering workstations in the corresponding PIB. For this plant layout, it is
recommended that all engineering an maintenance workstations in a PIB be
hosted on a single virtual server, located in the PIB. In this configuration, the
virtual server in the PIB would be configured to host the following applications:
Page 10 of 21
DCS Engineering Workstation Instrument Asset Mgmt. station

ESD Engineering workstation (if applicable) Alarm Management Station
CCS HMI / Engineering station (if applicable) OPC Interface station
VMS Engineering station Other applications as required
There are exceptions where more than one virtual server would be required per
PIB. If the DCS / ESD vendor has some restriction for not allowing other
applications like ALMS, CCS, IAMS or other applications to run on the same
virtual server, then two or more virtual servers would be required. A typical
example would be if one vendor only supported Microsoft Virtualization
software (Hyper-V) and another vendor only supported a different virtualization
software (e.g., VMWare). Where this is the case, two virtual servers would be
required in order to separate applications.
Another exeption which would require more than one virtual server to be located
in the PIB is where the automation system utilizes redundant servers to interface
with Control and IO signals. Where redundant servers are the standard
architecture for the automation system, it is recommended to utilize two virtual
servers to separate the virtual instances of the redundant servers onto different
virtual servers.
Where a virtual server is used to connect virtual workstations which reside on

separate process automation networks, separate physical Network Interface
Cards (NICs) must be used to connect the virtual server to multiple physical
networks.
In each PIB, a minimum of two thin-clients would be required in order to

provide access to all virtual instances running on the server. Each thin client
should be configured to access all PAS virtual instances.
The configuration and layout of virtual servers within the Central Control Room
(CCR) should be designed to segregate virtual instances of operator
workstations onto separate virtual servers. Using the Manifa example, and
assuming there are four operator workstations for each operator console, the
layout of virtual workstations to virtual servers depends on whether the
automation system utilizes high-availability servers (refer to item 5.1.2 above)
or independent server architecture.
Table 1 below show a segregation philosophy which combines thirty-two or

more workstations into eight virtual servers using independent server
architecture.

Page 11 of 21
Table 1 - CCR Virtual Server-to-Virtual Instance Design, Independent Servers
VIRTUAL SERVER #1 VIRTUAL SERVER #5

GOSP-1, Operator workstation #1 Gas Compression, Operator station #1
GOSP-2, Operator workstation #1 Utilities, Operator workstation #1
GOSP-3, Operator workstation #1 Cogen, Operator workstation #1
WOSEP, Operator workstation #1 DCS Engineering workstation #1

WOSEP, Operator workstation #2 DCS Engineering workstation #2

WOSEP, Operator workstation #3

WOSEP, Operator workstation #4
Other support stations would be allocated to a fifth set of servers.

The recommended allocation is as follows:

Primary Domain Controller Backup Domain Controller
WSUS patch / AV management station Backup and Recovery Server
Network Management station CMS eng/maint client station
ALMS workstation CCS eng / maint client station
Historian Scan Node IAMS eng/maint client station
In the traditional architecture, this HMI / Server layer would be comprised of

80 workstations and three servers. This is reduced to 17 virtual servers and one
virtual management station.
For systems which support the High Availability option (HAO), the layout of
virtual servers to virtual servers would change somewhat. Within the PIBs, high
Page 12 of 21
availability is not required, unless the DCS system utilizes servers which are
required for normal control and monitoring functions. In the CCR, the
distribution of virtual images to virtual servers is essentially the same as the
individual server architecture. Additional consideration must be given to the
assignment of backup servers. In addition, spare CPU and memory must be
allocated on each server to ensure that each server is able to run all virtual
instances, in the event of a single server failure. Table 2 below shows the
recommended assignment, where the A/B servers are used to backup each other.
Table 2 - Assignment of Virtual Instances to Virtual Servers, High Availability
VIRTUAL SERVER #1A VIRTUAL SERVER #1B SAN 1

GOSP-1, Operator workstation #1 GOSP-1, Operator workstation #2
WOSEP, Operator workstation #1 WOSEP, Operator workstation #2

WOSEP, Operator workstation #3 WOSEP, Operator workstation #4

Gas Compression, Operator station #1 Gas Compression, Operator station #2
Utilities, Operator workstation #1 Utilities, Operator workstation #2
Cogen, Operator workstation #1 Cogen, Operator workstation #2

Gas Compression, Operator station #3 Gas Compression, Operator station #4
Utilities, Operator workstation #3 Utilities, Operator workstation #4
Cogen, Operator workstation #3 Cogen, Operator workstation #4

Primary Domain Controller Backup Domain Controller
WSUS patch / AV mgmt station Backup and Recovery Server
Network Management station CMS eng/maint client station
ALMS workstation CCS eng / maint client station
Historian Scan Node IAMS eng/maint client station
Other distributions of virtual instances to servers can be considered. However, it

is recommended that all workstations from a single console not be assigned to a
single set of redundant virtual servers.

Page 13 of 21
6.3 SCADA Systems
The typical SCADA architecture includes a redundant set of SCADA Servers,

an operator console, one or more engineering workstations, and other
workstations/servers for support functions such as a domain controller,
Anti-virus management and historization. SCADA Servers are used to
communicate with RTUs in the field and relay data to/from the operator
workstations. In larger SCADA systems, the function of communications with
the RTUs are separated from update of the SCADA database and
communicating information to/from operator workstations. In this architecture,
the servers which communicate with the RTUs are called Front End Processors
(FEP). The figure below shows the typical architecture for both configurations.
Figure 6 - Traditional SCADA Architectures
In the Traditional SCADA architecture, critical servers, such as the SCADA

Database Server and Front End Processors are supplied in redundant
configuration. This provides redundancy at both the hardware level and the
application level for these servers. A minimum of two operator workstations are
supplied in order to ensure both hardware and application redundancy at the
workstation level.
Page 14 of 21
SCADA systems are very good candidates for virtualization, since, for most
systems, the entire system can be consolidated to two virtual servers.
Redundant stations within the traditional architecture (i.e., SCADA DB Servers,
Front End Processors and Operator Workstations) should be segregated onto
different virtual servers. All of our approved suppliers provide application
redundancy for critical services. For this reason, High Availability, is not
required for SCADA. By segregating redundant services to separate virtual
servers, there is no service interruption in the event of a hardware failure of the
virtual server. A recommended distribution of workstations and servers is
shown in the figure below.
Figure 7 - Virtual SCADA Architecture
6.4 Product Distribution / Bulk Plants (TMS) Systems
The typical TMS system contains redundant Control database servers, redundant
Business Application Servers, TMS operator workstations, TMS engineering
workstations, auxiliary systems engineering workstations, and various support
servers like anti-virus patch management, domain controller, and historian
interface.
Similar to SCADA systems, critical servers in TMS applications are supplied in

redundant configuration making virtualization of TMS applications a good

Page 15 of 21
candidate for virtualization using the independent server architecture. Figure 8

below provides a typical TMS system architecture drawing.
Figure 8 - Typical TMS System Architecture
With TMS Systems, the workstations / servers tend to be in multiple locations

which needs to be considered when determining the correct virtual architecture.
The Central Control building houses the operator console, containing 2 or more
workstations, the TMS Database server, TMS engineering workstation, Domain
Controller and other auxiliary systems maintenance workstations. In the sales
office, there is another workstation connected to the Queue Monitor and an
additional station in the Plant Inspection office. Since it is not economical to
virtualize a single workstation on a virtual server, locations which house a single
workstation, such as the sales office and inspection office, would continue to
utilize traditional PC based workstations. The workstations in the control
building would be virtualized, and for availability, two virtual servers are
recommended. These could be either redundant servers connected to a SAN,
high availability option, or two independent virtual servers. The main
consideration is to distribute operator workstations to multiple servers and to
split the redundant servers, such as the TMS database servers and redundant
domain controllers (if applicable) onto two separate virtual servers. Figure 9
below describes a potential architecture.
Page 16 of 21
Figure 9 - Virtualized TMS Architecture
7. Thin Clients
Automation suppliers have adopted different strategies for how they integrate TC devices
into their virtual automation environment. Two specific topologies are most widely used.
The first will be referred to as the 'Stand-alone' architecture, for the purpose of this
document. The second will be referred to as the 'Integrated' architecture. Each topology
has its own pros and cons. The major difference between the two is in how the user
authentication is handled for login to the thin-client operating system. The intent of this
document is not to discuss the pros and cons of each approach. The purpose is to provide
details of each topology and to provide specific guidelines for each to ensure the system
meets Saudi Aramco requirements for security and reliability.
7.1 Stand-alone Thin-Client Implementation
A 'stand-alone' thin-client (TC) is one which is not integrated into an active

directory domain. A 'stand-alone' TC utilizes a local windows user account for
access to the Windows operating system on the device. For this configuration,
the following are the recommended settings:
1. The thin-client device shall have only two user accounts; administrator and
user.
2. The thin-client device shall be configured to 'auto-login' on reboot into the
local 'user' account.

Page 17 of 21
3. The windows desktop for the 'user' account should be configured such that
the user does not have access to the 'Start' menu.
4. The only programs available to user shall be pre-configured remote desktop
icons on the desktop.
5. The device shall be 'write-protected' by enabling the 'write-lock' function
available on TC devices.
6. User account passwords for access to the virtual workstation running on the
virtual server shall not be stored or cached on the thin-client device.
7. Controls shall be implemented to prevent the thin-client device from booting
up into the Administrator account.
7.2 Integrated Thin-client
An integrated Thin-client is a thin-client which is connected to the Process

Control System Domain Controller (PC-DC) and utilizes PC-DC for user
account management and authentication. In this architecture, the Thin-client is
typically connected directly to the Level 2 process control network. The user
account used to login to the thin-client are the same accounts used to login to the
virtual workstation on the virtual server.
7.3 Common Thin-client Guidelines
The following requirements apply to all Thin-client devices regardless of

whether they fit into the stand-alone or integrated category:
1. All unused USB ports must be disabled
2. Guest account must be disabled
3. All unnecessary programs icons shall be removed from the desktop.
4. Thin-clients shall not display TCP/IP addresses in the top menu bar of the
RDP session. If necessary, Thin-clients shall have a local 'hosts' file
configured for the stations to which it will connect.
5. All unused program shall be removed from the device. This includes
various client connection software typically installed on these machines like
Citrix receiver, etc.
6. The 'Write-Filter' lock shall be enabled.
7. Thin-clients installed in manned or unmanned operator consoles shall be
configured to connect to only the specific virtual workstations to which it
would normally require access.
8. Thin-clients which are installed in operator consoles shall have the standard
'remote desktop connection' icon removed from the desktop. The desktop
Page 18 of 21
shall contain only pre-configured remote desktop icons which are configured
to connect to the virtual workstation for which access is required.
8. Backup and Restore
8.1 Snapshots
Snapshots are software backups of virtual images which are created by the
virtualization software. These are different from the backup workstation images
created with software tools such as Acronis and Symmantec. Snapshots can be
taken for any virtual instance without shutting down the virtual instance.
However, snapshots cannot be used to restore a complete virtual image.
Snapshots are only incremental backups from the last snapshot. Snapshots are
not suitable for a complete backup and restore system. Snapshots would only be
used before and after major system changes, such as installation of new
application software patches or revisions and/or installation of major Windows
OS patches.
8.2 Virtual Image Exports
Virtualization software from both Microsoft and VMWare have the functionality
to export a complete virtual image to a backup file. Exports of virtual instances
are complete backups of a virtual instance and are equivalent to Acronis or
Symmantec Station backups in the traditional architecture. In the event of a
virtual server failure, virtual image exports are needed to restore virtual
instances on the replaced server. The following recommendations apply to
virtual image exports:
 Exports of virtual images should be taken at least one time per year for each
virtual instance.
 Exports should be stored on a separate physical server or on a different
virtual server. Exported images should not be stored on the same virtual
server which hosts the virtual instances for which the backups are taken.
8.3 Workstation Image Backups
Workstation Image backups refers to workstation backups created with software

such as Acronis or Symmantec. This is the same software used to backup and
restore workstation images in the traditional PC based architecture. In addition to
yearly, virtual image exports, it is recommended that each virtual image be
installed with this software to enable normal backups to be made periodically.
Most commercial backup / restore software have the capability to create backups
while the system is running. This feature enables backup images to be created
more frequently than would be possible with Virtual Image exports. However, the
backup software does not contain the Virtual Image properties such as the CPU,
Page 19 of 21
memory allocation, virtual-to-physical network assignments, etc. For this reason,

a combination of Virtual Image exports and Traditional workstation image
backups is needed in order to completely restore virtual images with the most
up-to-date software backup. In addition, this software is needed to create backup
images of the virtual servers.
8.4 Recommended Practices for Backup and Restore
Vendor recommendations for backup and restore of virtual images should be

followed and take precedence over the recommendations below.
The recommendations below can be followed if there are no specific backup /
restore recommendations from the automation vendor.
8.4.1 Virtual Image Exports should be taken for all virtual images at least once
per year. These image shall not be stored on the same virtual server on
which the virtual images are running.
8.4.2 Backup and Restore software such as Acronis or Symmantec should be

installed on all virtual images. The software should be configured to
make complete image backups for all virtual images on a weekly basis.
The image backups should not be stored on the same virtual server on
which the images are running.
8.4.3 Complete backup images of virtual servers are also required.

These would be used in the event of software corruption of the virtual
server operating system itself. Virtual Server image backups should be
made for each virtual server a minimum of one time per year.
8.4.4 Vendor recommended procedures for restoring a virtual image on a

virtual server should be followed. Detailed procedures should be
documented and tested by plant PAS administrators. In general, the
process involves three steps. First, assign a new virtual workstation to
the applicable virtual server. Second, import the latest virtual image
export file to the newly created virtual image. Finally, the latest image
backups should be restored to the virtual image using Acronis,
Symmantec or similar software.
8.5 Recommended Backup and Failover Strategy for Independent Virtual Servers
For systems which utilize a stand-alone redundant server architecture, it is

important to have a strategy for starting and running virtual images on a
different virtual server, in the event of a hardware failure of one virtual server.
One way to achieve this is to assign all virtual instances to both virtual servers.
However, a virtual image may only be running on one server at a time. In the
event of a virtual server hardware failure, the virtual instances which are
Page 20 of 21
assigned to the redundant server, but not running, can be easily started on the
redundant server. The figure below shows this architecture in a simplified
diagram. In the event of a failure of Virtual Server A, Images 1, 2 & 3 can be
started quickly on Virtual Server B.
Figure 10 - Non-redundant Virtual Server Fail-over Strategy
This strategy requires that virtual server A has current backup images of
instances running on virtual server B and visa-versa. To support this
requirement, Virtual Server A hard-disk may be used to store image backups for
virtual server B and visa-versa. In the event of a failure of server B (as an
example), Virtual Server A will have the latest image backups for B which are
ready to be started to restore services until such time as virtual server B has been
replaced.
Revision Summary
28 December 2015 New Saudi Aramco Best Practice was created for the implementation of Virtual Servers
and Thin clients for Process Automation Systems.

Page 21 of 21

Sabp Z 074

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

Sabp Z 074

Uploaded by

Copyright:

Available Formats

Best Practice

SABP-Z-074 28 December 2015

Previous Issue: New Next Planned Update: TBD

Copyright©Saudi Aramco 2015. All rights reserved.

2. Conflicts with Mandatory Standards

3. References, Acronyms and Definitions

Saudi Aramco Engineering Procedure

Saudi Aramco Engineering Standards

Saudi Aramco Materials System Specifications

23-SAMSS-050 Terminal Management Systems

Saudi Aramco Engineering Report

HMI - Human-Machine Interface

Process Control System (PCS): The integrated system which is used to

Process Automation Network (PAN): PAN is a plant-wide network

Process Control Network (PCN): A proprietary process control network

Virtual Instance: A complete software image of a workstation or server which

Saudi Aramco: Company General Use

Figure 1 - Conceptual Diagram of Virtual Server

Figure 2 - Conceptual Diagram of Thin-clients

Saudi Aramco: Company General Use

5.1.1 Independent Virtual Servers: In this architecture, each virtual server is

Figure 3 - Independent Server Architecture

5.1.2 Redundant Servers with shared Network Storage (SAN):

This architecture achieves a higher level of availability for automation

Saudi Aramco: Company General Use

Figure 4 - High Availability Virtual Server Architecture

5.1.3 Blade Servers: The Blade Server architecture combines automatic

The advantages of blade servers is that it simplifies the server

Figure 5 - Blade Server Architecture

5.2 General Recommendations for Virtual Servers

5.2.2 Redundant instances of virtual operator workstations within an operator

5.2.4 Separate server(s) (virtual or traditional) should be used to host any

Saudi Aramco: Company General Use

5.2.5 Operator workstations hosted on virtual servers shall have a dedicated

6. Recommended Architecture by Plant Type

6.1 Single Train GOSP

6.2 Multi-Train GOSP

PIB #1 - GOSP Train #1 PIB #5 - Gas Compression

DCS Engineering Workstation Instrument Asset Mgmt. station

Where a virtual server is used to connect virtual workstations which reside on

In each PIB, a minimum of two thin-clients would be required in order to

Table 1 below show a segregation philosophy which combines thirty-two or

Saudi Aramco: Company General Use

Table 1 - CCR Virtual Server-to-Virtual Instance Design, Independent Servers

VIRTUAL SERVER #1 VIRTUAL SERVER #5

VIRTUAL SERVER #2 VIRTUAL SERVER #6

VIRTUAL SERVER #3 VIRTUAL SERVER #7

VIRTUAL SERVER #4 VIRTUAL SERVER #8

Other support stations would be allocated to a fifth set of servers.

VIRTUAL SERVER #9 VIRTUAL SERVER #10

In the traditional architecture, this HMI / Server layer would be comprised of

Table 2 - Assignment of Virtual Instances to Virtual Servers, High Availability

VIRTUAL SERVER #1A VIRTUAL SERVER #1B SAN 1

VIRTUAL SERVER #2A VIRTUAL SERVER #2B SAN 2

VIRTUAL SERVER #3A VIRTUAL SERVER #3B SAN 3

VIRTUAL SERVER #4A VIRTUAL SERVER #4B SAN 4

VIRTUAL SERVER #5A VIRTUAL SERVER #5B SAN 5

Other distributions of virtual instances to servers can be considered. However, it

Saudi Aramco: Company General Use

6.3 SCADA Systems

The typical SCADA architecture includes a redundant set of SCADA Servers,

Figure 6 - Traditional SCADA Architectures

In the Traditional SCADA architecture, critical servers, such as the SCADA