EDOF PI Architecture blueprint overview

eni S.p.A.
EDOF- PI ARCHITECTURE BLUE PRINT

Upstream and Technical
Services
DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 1-38
EDOF- PI ARCHITECTURE BLUE PRINT
DATE: 19-April-2016
REV DESCRIPTION PREPARED BY APPROVED BY

Issue based on
revision of
1.1 EDOF- PI (EXP-DAST-DAOP)
ARCHITECTURE
BLUE PRINT
eni S.p.A. EDOF- PI ARCHITECTURE BLUE PRINT
Services
CONTENTS
1 INTRODUCTION 4
1.1. DOCUMENT PURPOSE 4
1.2. INTENDED AUDIENCE 4
1.3. UPDATE HISTORY: 4
1.4. TERMINOLOGY AND ACRONYMS 4
2 DATA ACQUISITION REQUIREMENTS 7
2.1 REAL TIME DATA 7
2.1.1 Data Types 7

2.1.2 Polling rate 7
2.1.3 Precision 8
2.1.4 Availability 8
2.2 COMMUNICATION PROTOCOL 8
3 ACCEPTANCE TEST 9
3.1 TEST ENVIRONMENT 9
3.2 TEST SET 9
4 REAL TIME DATA ACQUISITION ARCHITECTURE 10
4.1 HIGH LEVEL DESIGN 10
4.2 COMPONENT DESCRIPTION 11
5 NETWORK CONSIDERATIONS 14
5.1 PCN AND OFFICE INTERNETWORKING 14
5.2 PI INTERFACES POSITIONING 15
5.3 PI SERVER(S) POSITIONING 16
5.4 TRAFFIC AND LINKS BANDWIDTH CONSIDERATIONS 17
6 SECURITY CONSIDERATIONS 19
6.1 APPLICATION SECURITY GUIDELINES 19
6.2 FIREWALL AND SECURITY CONSIDERATIONS 19
7 DETAILED DESIGN (BILL OF MATERIAL) 20
7.1 SCENARIO 1 21
Services
7.1.1 Services 22
7.1.1 Plant OPC Server 23
7.1.2 Interface Node Servers 24
7.1.3 Shared components configuration 25
7.1.4 Rack layout example (OPC server system excluded) 25
7.2 SCENARIO 2 26
7.2.1 Branch PI server 26

7.2.2 Shared components configuration 27
7.2.3 Rack layout example (OPC server system excluded) 28
8 APPENDIX A- TEMPLATE DOCUMENT:” EDOF PI REAL TIME
ACQUISITION ARCHITECTURE UAT/FUAT 29
Services
1 INTRODUCTION
1.1. DOCUMENT PURPOSE

The objective of this document is to provide the guidelines regarding the implementation of the
real time data acquisition system, a key component of the Digital Oil Field (DOF) system, on eni’s
production Assets. The Blue Print must be used as the basis for the project specification of the PI
data acquisition system.
1.2. INTENDED AUDIENCE

This document is intended for eni group IT Team and eni group project managers involved in DOF
projects.
1.3. UPDATE HISTORY:
Version Date Author Changes

1.0 17/06/2015 revision of
PI FOR BRANCH REFERENCE HW ARCHITECTURE
1.4. TERMINOLOGY AND ACRONYMS
Term Definition
DOF /eDOF Digital Oil Field /eni Digital Oil Field
OPC Open Platform Communications
DCS Distributed Control System
SCADA Supervisory Control And Data Acquisition
PCN Process Control Network (named Control Room)

Services
DCOM Distributed Component Object Model
DA Data Access (type of OPC server)
HDA Historical Data Access (type of OPC server)
HA High Availability
RDP Remote Desktop Protocol
iLO Integrated Lights-Out (physical devices on servers used

for management by HP)
DRAC Dell Remote Access Control (physical devices on servers
used for management by Dell)
Production Site Onshore or offshore production plant
Hub site eni’s branch offices usually located near the prod. site
HQ eni HeadQuarter (San Donato Milanese – MI)
OPC server Server providing OPC connections to OPC clients
Contractor Contractor responsible for the Automation System of the

plant
Office Network LAN managed by eni (it comprehend the production site,
the hub site and the HQ)
Industrial Firewall Firewall usually located between the PCN and the
production site office network
UAT User Acceptance Test
UFO PI Universal Failover mechanism, based on a text file

shared between two PI Interface nodes, each looking at
the file to see the active note status
MUST -This word, or the terms “REQUIRED” or “SHALL”, mean that the definition is an absolute requirement
of the specification.
MUST NOT – This phrase, or the phrase “SHALL NOT”, means that the definition is an absolute prohibition
of the specification.
Services
SHOULD – This word, or the adjective “RECOMMENDED”, mean that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full implications must be understood and carefully
weighed before choosing a different course.
SHOULD NOT – This phrase, or the phrase “NOT RECOMMENDED” mean that there may exist valid reasons
in particular circumstances when the particular behavior is acceptable or even useful, but the full implications
should be understood and the case carefully weighed before implementing any behavior described with this
label.
MAY – This word, or the adjective “OPTIONAL,” mean that an item is truly discretionary.
FUTURE – This word means that objectives are provided as guidance or expectation and may or may not be
accurate.
Services
2 DATA ACQUISITION REQUIREMENTS
For Digital Oil Field (DOF) system a key requirement is real time data acquisition. This chapter will describe
its general requirements, while the following chapters will show an example of implementation.
2.1 REAL TIME DATA
2.1.1 Data Types
In principle every digitally available data shall be collectable.

A non-exhaustive list could be as follows:
• Probes (temperature, humidity, pressure, flow, …)
• Power meters (current, voltage, active/reactive/real power, phase, frequency, distortion, by phase
and/or average)
• Inverters, Engines, Valves, … (control, feedback, speed, power usage, running time, …)
• Digitally controlled devices (control, feedback and internal parameters like pressures, temperatures,
overall load, power usage depending on the specific device)
The list of the data to be acquired and made available into the PI Subsystem will be defined during project
design phase.
2.1.2 Polling rate
Variable polling rate shall be supported, with frequencies ranging from hours down to seconds, the exact
maximum rate will be defined during project design phase.
Supporting a given poll rate means both that the digital interface can handle the query rate and the underlying
value is updated at an equal or better rate (eg: if a temperature is polled at 10s the corresponding probe must
be able to update the value at least every 10 seconds)
Services
2.1.3 Precision
Unless approved during project design phase, there shall be no loss of significant digits from the data source
to the collecting system
2.1.4 Availability
Unless approved during project design phase, there shall be no loss of real time data from the data source to
the collecting system even in case of temporary interconnection issues.
2.2 COMMUNICATION PROTOCOL
The protocol chosen for data collecting shall comply to the following requirements:
• Ethernet/IP compliant: no special purpose hardware required
• Public specification: vendor-specific protocols will not be accepted unless explicitly approved
• Concurrent access: at least two clients shall be able to concurrently query every device
• Fault tolerant: redundant access path will be deployed if required
Services
3 ACCEPTANCE TEST
Before releasing the real time data acquisition system to production sites, eni will require to perform an
exhaustive acceptance test.
The detailed test plan will be defined during project phase according to the guidelines described in the PI
acceptance test blue print document.
3.1 TEST ENVIRONMENT
A test environment, matching as closely as possible the actual production environment, will be deployed
together with a metering system.
• Data sources (eg: probes) will be either simulated or actually deployed
• Processing devices (servers, controllers etc) will be provided with at least one unit per device type
• Network infrastructure shall match the production topology and characteristics (bandwidth, latency,
packet switching rate etc)
• A means for measuring device load will be proposed (eg: CPU load, bandwidth utilization, memory
usage etc)
• During test execution, those measures shall be collected for instant and later analysis at an adequate
rate (eg: 5 seconds)
3.2 TEST SET
The acceptance test will consist of running the system under predefined load (test set). The test set should
represent the worst case load for the system, with some margins as follows:
• 1.5x the total number of tags will be queried
• polling rate will be the fastest supported by every device
• running time will be no less than 5 days
If clients other than the data acquisition system are expected (eg: SCADA), their load (at worst case) will be
included, too.
The test is passed if during the its execution the resources are not loaded above than 70% average
and no slowdown that could hamper the data acquisition in PI are reported.
Services
4 REAL TIME DATA ACQUISITION ARCHITECTURE
4.1 HIGH LEVEL DESIGN
The real time data acquisition system is a key component of the eni Digital Oil Field (eDOF) system. It is based
on the commercial OSIsoft PI system (ref. www.osisoft.com). The PI system provides a way to acquire and
efficiently store real time data, making them available for further analysis and visualization through a number
of client (PI ProcessBook, PI DataLink) and web based (PI WebParts for SharePoint, PI Coresight) tools.
Moreover, the PI AF tool provides a way of smart navigation across plant systems, subsystems, unit,
equipment, allowing to organize such elements in hierarchical and user friendly way.
In order to implement the real time data acquisition architecture, the following components need to be in place:
• OPC Servers: provide a standard way to access real time data from the plant. They are usually
provided by the Contactor as part of the Plant Automation System. If not the contractor shall provide
it, vendor-specific protocols will not be accepted unless explicitly approved. OPC protocol could be
DA, HDA, UA.
• PI OPC Interface: PI component used to fetch data from OPC Servers and send data to the PI Server,
where they are stored for long term retention. The PI OPC Interface includes a local caching buffering
that allow to avoid loss of data in case of temporary network outages towards the PI Server.
• PI Server: efficiently stores data (including compression) for long term retention.
In the figure below, the data acquisition architecture is conceptually sketched: from left to right, the OPC
Servers are provided by the Contractor: both OPC DA servers (i.e. connecting directly to the DCS, SCADA,
PLC or RTU, and capable to fetch the current value from each sensor) and OPC HDA server (i.e. connecting
to a local plant historian provided by the Contractor, and capable to fetch current and historical data) are
suitable for the DOF architecture. Multiple OPC servers can be provided, either in case different Contractors
implemented subsystems of the automation system for the plant or to guarantee HA in data feeding (figure
indicates, for example, up to 8 OPC Servers). In the middle, the PI OPC Interface is installed on a pair of
servers in order to provide HA on data acquisition. One of these servers is active while the other one is in
stand-by. The standby server automatically switches to active mode in case of problems on the other server
(UFO, Universal Fail-Over mechanism). The failover mechanism is based on a small shared file, as shown in
figure, where the active server keeps track of its status. On the right hand side, the PI Server receives data
from the PI OPC interfaces.
Services
Since the PI system is usually accessed by office applications, at least one firewall should be present along
the data acquisition flow, to ensure that the plant network is appropriately protected from external intrusions.
4.2 COMPONENT DESCRIPTION
The Real Time data acquisition architecture is based on following components:
• OPC servers : (usually provided by the contractor of DCS, SCADA or other plant automation
systems). The component collects real-time tags provided by different sources and makes them
available to any connecting client.
In most of the cases, the OPC Server exposes data through the DA interface, which provides access
to the current value of each tag. In case a local plant historian is available, an OPC HDA server can
provide access to both current and historical data (i.e. it transparently queries the local plant historian).
If available, OPC UA could be considered depending on PI OPC interface releases. 11
1
PI OPC UA (Unified Architecture) is not available at the time of the document release but it is the OSIsoft road map.
Services
The OPC server should be configured to provide READ-ONLY access to the values of the tags (no
WRITE operations allowed).
OPC client connects to OPC Servers through port 135; however, the OPC servers provides a callback
handle to the client which can be dynamically allocated on any port between 1024 and 65535. This
means that between OPC servers and clients a broad range of ports must be open. In case a firewall
is configured between OPC server and client, it is suggested to use the OPC Tunneling technology to
force all data traffic on a single user-defined port.
• PI Interface node: The component acts as an OPC client to connect to the Contractor’s OPC Servers.
It receives the list of tags to be acquired from the PI System, asks for them to the OPC Server, and
send back (with full caching capability) the real time data to the PI system. A bidirectional data
transmission with PI server occurs on port 5450.
The component is usually in HA (High Availability) mode to ensure resilience against failover. Interface
node HA implementation requires a file share where the active status of the servers is tracked
In case the contractor provider of DCS, SCADA or other plant automation systems does not
support the OPC protocol, a specific solution shall be proposed by contractor and accepted
by eni, to guaranty the data acquisition to the PI server. 2
• Osisoft PI Subsystem: The PI Subsystem receives, stores and provides access to real-time data,
supporting the analysis and decision making activities of eDOF users.
The PI Subsystem can be deployed in one of the following options depending on Asset’s requirements.
1. Standalone PI server (minimum requirement): a single PI server is installed; all the client
applications connect to the single PI server and all the PI interfaces installed feed the single
PI server.
2. HA PI Collective (High Availability Version of Minimum Requirement): two or more PI

servers are installed. This solution facilitates load balancing and enables High Availability of
the PI Subsystem. Such architecture can also help to locate the PI Secondary server(s) in
different geographic locations where it can be efficiently accessed by client tools. For the HA
PI Collective architecture functioning explanation please refer to the PI-Osisoft Subsystem
2
In a limited number of cases, it might happen that the automation system does not support the OPC interface: this currently
happens on UNIX-based systems, since OPC DA/HDA are Windows-specific mechanisms, and OPC UA, no longer depending
on Windows DCOM is not widely adopted yet. In such cases, OSIsoft usually provides a DCS-specific connector to support real
time data acquisition. Only in this case, eni allows to deviate from the standard OPC interface
Services
Specification document.
The final architecture of the PI Subsystem will be asset-specific and will depend on the network
architecture, type of DCS, geographical locations, and specific asset’s requirements.
.
Services
5 NETWORK CONSIDERATIONS
The current chapter lists some considerations and guidelines regarding the logical positioning of the various
DOF elements.
However the network architecture and placement of PI Interface Nodes and PI Servers shall be designed
separately for each asset depending on their requirements and limitations (i.e. wireless channel bandwidth,
geographic considerations, DCS type and its limitations, local network infrastructure capabilities, etc.).
5.1 PCN AND OFFICE INTERNETWORKING
The PCN frontend and the eni’s Office network on the production site are assumed to be TCP/IP over Ethernet
network. The following figure summarizes the possible internetworking schema in the case of PI Interface
nodes located on the Office network.
Figure 1 - PCN and eni's office internetworking schema; PI Interface nodes on the office network.
This is a suggested configuration which clearly segregates the responsibility of the Contractor (yellow part)
and the responsibility of eni (light blue part). However, other options can be proposed by the Contractor and
evaluated by eni, as explained in next Chapter.
Services
• The physical interconnection should connect the switching infrastructure of both networks. Depending
on the single case the architecture could vary (resiliency, high availability, etc.): physical
interconnection options proposed by the Contractor have to be evaluated by eni case by case.
If the OPC servers are equipped with one NIC dedicated to the DOF project, the interconnection could link the
OPC servers directly to the eni’s switching infrastructure on the production site. The NIC’s address will be given
by eni.
• The PCN is viewed by eni’s office network as a separate network/Vlan. In case of different addressing
plan, IP natting has to be configured between the two networks. Assuming that one or more firewalls
are logically positioned between the two networks, these have to be configured to allow the
communication.
• eni configures on its routing infrastructure the security policies (ACL on routers or policies on firewalls)
that allow only the traffic flows between OPC servers and PI Interface nodes, only on a specified
agreed port. Depending on the volumes of the traffic flows and on the router’s capabilities, a firewall
could be requested to eni. On the other side the contractor has to guarantee the communication
between OPC servers and the PI Interface Nodes on his infrastructure.
• In case of more than one PCNs, the single PCN configuration will be replicated by eni to allow the
communication between PI servers and the OPC servers in different networks.
5.2 PI INTERFACES POSITIONING
Referring to OSIsoft best practices, all interfaces have to be positioned on Interface Nodes (separate
computers/servers) in proximity of data sources. I.e. if DCS is on PCN (Process Control Network) domain, it
would be recommended to locate the Interface Node on the same domain and geographically closer to the
DCS. This will decrease possible data losses in case of network failure as well as decrease network load. In
fact, a smart data acquisition mechanism can be setup, so that real time data samples are only acquired when
they differ from the previous ones by more than a specified threshold (exception deviation mechanism).
Usually all traffic between the PCN and the Office Network is firewalled through one or more Firewalls.
Anyway the choice of the location of PI Interface Nodes will be decided by eni: geographically they will be
always on the production site; the logical positioning (PCN, DMZ in Office network etc.) will depend on the
specific case:
• PI Interface nodes logically situated in the PCN:

the Contractor(s)’ capability to host the PI Interfaces is an assumption. Interfaces could be positioned
on dedicated hardware machines (Interface nodes) or could be hosted directly on OPC servers. The
access to the PI interfaces management interfaces has to be guaranteed by the contractor in both
case.
Assuming that an industrial firewall separates the PCN and the eni’s Office Network, contractor has to
guarantee the communications between the PI Interface nodes and the PI server(s) on the Office
network, configuring the industrial firewall properly (see 4.2 – Firewall and security considerations).
Services
• PI interface Nodes located in the eni’s Office Network:

Contractor(s) has to guarantee the reachability of the OPC server(s) from the PI Interface nodes.
If a firewall is configured on the connection between the PI Interface Node and the OPC server(s),
Contractor(s) has to guarantee the capability to configure an OPC tunnel between the OPC server(s)
and the PI Interface Nodes. The usage of an OPC tunnel allows to keep open one single port across
the firewall, as already discussed in chapter 2.2.
The choice of the tunneling software (Kepware, Matrikon etc.) will be up to the contractor. Contractor
has to guarantee the communication between the tunneler endpoints by configuring correctly his
firewall on the basis of the ports agreed with eni (tunneling communication can be agreed on user
defined ports).
The single PI interface Node will require:
• Up to eight – 1Gb Ethernet network interfaces - TRAFFIC with OPC servers

• Two – 1Gb Ethernet network interfaces - TRAFFIC with PI Server(s)
• One – 1Gb Ethernet network interface - remote management
The support from eni’s office network can be limited to providing the network ports required; or could
include the provision of a dedicated network device (router/firewall) according to the specific case.
5.3 PI SERVER(S) POSITIONING
PI server(s) will be hosted on a dedicated machine located on the eni’s Office Network.
They could physically be local to the production site or remotized (in Hub site or HQ).
In case of PI server(s) in the production site the PI HA configuration (PI collective mode) will be
mandatory. The other PI server will be hosted in the Hub site or in the HQ site. The primary PI will be
chosen depending on the specific case.
The physical positioning of the PI server(s) will depend on the specific case, considering both the
branch requirements and the network infrastructure capabilities of the involved sites.
The presence of an eni network infrastructure on the production site and on the hub site that can host the PI
server is an assumption.
The single PI server will require:
• Two – 1Gb Ethernet network interfaces – TRAFFIC

• One – 1Gb Ethernet network interface - remote management
Refer to chapter 5 Detailed design (Bill of material) for furthermore information on the physical machines
requirements.
The communication between the PI server and both the PI Interfaces and the client applications (i.e. PI
Services
ProcessBook, PI DataLink) has to be guaranteed. In particular:
• PI Server should be able to resolve (through DNS or /etc/hosts) the IP address of the PI Interface
node;
• PI Interface node should be able to resolve (through DNS or /etc/hosts) the IP address of the PI server;
• PI Server should also be provided with the IP address(es) configured on additional network cards on
the PI Interface computer, because such IP addresses need to be trusted within the PI Administration
tool (even if they cannot be resolved by DNS and /etc/hosts, because they can be addressed within a
DMZ or PCN);
• Port 5450 should be bi-directionally open between PI Server and PI Interface node.
PI server(s) will be managed remotely by eni, so they have to be reachable from the HQ for remote assistance
and configuration. The MNGT VLANs has to be routed to the HQ and to the Hubsite.
5.4 TRAFFIC AND LINKS BANDWIDTH CONSIDERATIONS

The main traffic flows involved in the proposed architecture are:
- Traffic between the PI Interfaces and the PI server(s):

data transfer rates would depend on the sources scan rates that are specified for the PI tags and on
other parameters (see the table below).
Number of tags, type of tags and scan rate determine the bandwidth requirement between the PI
interfaces and the PI server(s).
Traffic between the PI server(s) and the client applications;
it depends on the refresh rates defined for each of these applications (up to project requirements).
The solution has to be evaluated case by case depending on the bandwidth limitation if any.
The PI system configuration will reflect the network constraints.
The values will be calculated using the Osisoft Buffer-And-Bandwidth-Calculation spreadsheet, below is an
example.
Services
Table 1 - Bandwidth percentage consumption

Services
6 SECURITY CONSIDERATIONS
6.1 APPLICATION SECURITY GUIDELINES
The Security requirements shall be verified for each Project with the ENI ICT Security Team.
6.2 FIREWALL AND SECURITY CONSIDERATIONS
Following the list of protocols and ports required by the DOF solution.
Protocol/Port Area/Direction Description

All PI Interfaces and PIBufss use API/SDK
TCP/5450 PI Interfaces –> PI Server
to write data to PI
PI AF Client connects to AF Server using

TCP/5457 PI AF Client –> PI AF Server
AF SDK over TCP/IP port 5457
PI AF Client connects to Notifications
PI AF Client -> PI Notifications
TCP/5458 Server using AN SDK over TCP/IP port
Server
5458
PI ACE connects to PI Server using PI
TCP/5450 PI ACE -> PI Server
SDK over TCP/IP port 5450
PI AF connects to PI Server using PI SDK

TCP/5450 PI AF -> PI Server
over TCP/IP port 5450
PI Clients (Processbook, PI Client applications connect to PI Server

TCP/5450
DataLink) -> PI Server using PI SDK over TCP/IP port 5450
Table 2 - Ports and protocols requested by the DOF solution
Note that in the case of both PI Interfaces and PI server on the Office Network, the communication between
the OPC servers on the PCNs and the PI Interfaces must be guaranteed by configuring OPC tunnels on both
endpoints. The choice of the tunneling software will be up to the contractor. Contractor has to guarantee the
communication between the tunneler endpoints by configuring correctly his firewall on the basis of the ports
agreed with eni (tunneling communication hasn’t fixed ports).
Services
7 DETAILED DESIGN (BILL OF MATERIAL)
The current chapter will provide a reference HW architecture for OSIsoft component to be installed on ships,
offshore platforms or other production plants. The main assumption is that components that collect the
data and expose to the OPC Interfaces are properly installed and configured by contractor and tested
and accepted by eni.
Two scenarios are available:
• Scenario 1: Local interface HA interface nodes + remote PI Server

Services
• Scenario 2: local interface HA interface nodes + local PI Server
7.1 SCENARIO 1
Interface node only on production site:
The suitability of this scenario depends on local available infrastructure

Services
• PROS: This scenario can be centrally managed more easily. There is no local PI Server to be
managed.
• CONS: The infrastructure fully operates only with TLCRoom-Hubsite link active: if link disruption
occurs, the remote PI server will recover missing data only when the connection is recovered.
PI Interface Node Specifications:
• HA – High Availability (active-passive configuration)

• Infrastructure Consolidation – connecting up to eight OPC Servers in the same site to the same
Interface Servers (two nodes), using dedicated and isolated network connection to the processing
network.
• Availability to use remote monitoring/managing tools (such as RDP or on-demand tools), ILO or
equivalent management interface.
• PI Interface node will be reachable from HQ/BU and will be in a DMZ between production plants/data
sources and Corporate Office Network.
7.1.1 Services
In-scope servers (PI System and PI Interface nodes) should be configured to be remotely managed by eni.
Service options can be activated are listed below.
 Base Infrastructure Management:
□ HW&OS uptime granted by specific SLA
□ Automatic HW&OS failure detection
□ No Backup&Restore Management is implemented by design.
 Application Operations - Specific services for PI system Software support:
□ Active monitoring to check correct data collecting (three times a day, Italian business days)
□ Automatic SW services failure detection
□ Patching management.
□ Software updates management.
 Support:
□ Reactive lvl1 or lvl2 support
Considerations:
• Specific ports must be opened from TLC Room to HubSite
Services
7.1.1 Plant OPC Server
The presence of an OPC server as data-source is an assumption and follows the rules below:
• New plants must include the requirement for an OPC Server in the Invitation To Tender for the plant
automation work package
• HW will be provided by Contractor.
• Infrastructure will be managed by Contractor.
• It is not mandatory to host it in the Interface node’s rack
Suggested Hardware Configuration
The OPC Server should be provided by the Contractor, according to the design criteria and sizing of the
automation system. However, since such server needs to be accessed by eni to acquire the real time data of
the plant, the following sizing guidelines are suggested.
Infrastructure Role Mandatory/Optional Configuration

OPC server (Active) Mandatory • Server format: Tower or if a rack is present
1/Unit.
• CPU: 2 Intel cpu (minimum 4 cores)
• RAM: 8 GB
• Disks:
• 2x300 GB (RAID1) internal disk
• Network card: 2x1000 Mbit for processing
Network
• Redundant power supply
• Remote management interface (i.e.: ILO,
DRAC) in case the PI OPC interface is hosted in
the OPC server.
• OS: Windows 2008r2 or later
OPC server (stby) Mandatory • Server format: Tower or if a rack is present
1/Unit.
• RAM: 8 GB
• Disk: 2x300 GB internal disk
• Network card: 2x1000 Mbit for processing
Network
• Remote management interface (i.e.: ILO,
DRAC…) in case the PI OPC interface is hosted
in the OPC server.
Services
7.1.2 Interface Node Servers
Mandatory Hardware Configuration

• Server format: server-grade PC or rackable 1/Unit.
Interface Node Mandatory • CPU: 1 Intel cpu (minimum 2 cores)
• RAM: minimum 4 GB
(Active) • Disk: 2x300 GB internal disk.
• Network physical interfaces:
o 2x1000 Mbit RJ45 NIC (Teamed) for production Network
o 1x100 Mbit RJ45 Motherboard-integrated management
interface (i.e.: ILO, DRAC …)
• Remote management (i.e.: ILO, DRAC …)
• OS: Windows 2008r2
• Server format: server-grade PC or rackable 1/Unit.
Interface Node (Stby) Mandatory • CPU: 1 Intel cpu (minimum 2 cores)
• RAM: minimum 4 GB
• Disk: 2x300 GB internal disk
• Network physical interfaces:
o 2x1000 Mbit RJ45 NIC (Teamed) for production Network
o 1x100 Mbit RJ45 Motherboard-integrated management
interface (i.e.: ILO, DRAC …)
• Remote management interface (i.e.: ILO, DRAC …)
• OS: Windows 2008r2
Services
7.1.3 Shared components configuration
Shared RACK Optional • Half sized rack: 22 unit
• PDU: standard RACK mounted PDU
Shared UPS Optional • UPS system:
• Rack-mounted
• Provides continuity for 2x Interface server
• Sized for 4 hour of continuity and automatic shutdown of the
systems (via network interface)
7.1.4 Rack layout example (OPC server system excluded)
Interface Servers (HA)

HP
ProLiant
5 8 DL360 G7
SID
1 2 3 4 UID 1 2
HP
ProLiant
5 8 DL360 G7
SID
1 2 3 4 UID 1 2
UPS
AMERICAN POWER CONVERSION
Services
7.2 SCENARIO 2
Interface node + Branch PI Server on production site
The suitability of this scenario depends on local available infrastructure

• PROS: The aggregated data (stored in Branch PI Server) can be accessed also in case of TLCRoom-
HubSite link disruption.
• CONS: One more server (Branch PI server) needs to be managed on local sites.
The sizing of OPC Servers and PI Interface Nodes are the same of chapters 5.1.1 and 5.1.2.
The current chapter will only describe the additional server in this option (Branch PI server).
7.2.1 Branch PI server
The Branch PI server will not be backupped; the backup will be foreseen only for the PI Subsystem Located
in Hub Site.
Services
Mandatory Hardware Configuration:
PI Branch Mandatory • Server format: rackable 2/Unit.
• RAM: 16 GB
• Disk:
o 2x146 GB internal disk for OS
o 3x600 GB internal disk for PI Archives and PI Backup
o 1 x 50 GB internal disk for PI Event Queue
• Network card:
o 2x1000 Mbit for frontend Network
• Remote management interface (i.e.: ILO, DRAC …)
7.2.2 Shared components configuration
Shared RACK Optional • Half sized rack: 22 unit
• PDU: standard RACK mounted PDU
Shared UPS Optional • UPS system:
• Rack-mounted
• Configured to provide continuity for 2x Interface server + 1 x
Branch PI Server
• Sized for 4 hour of continuity and automatic shutdown of the
systems (via network interface)

Services
7.2.3 Rack layout example (OPC server system excluded)
1 5
Branch PI Server
UID
2 6
3 7
4 8 ProLiant
DL380e
Gen8
Interface Servers (HA)

HP
ProLiant
5 8 DL360 G7
SID
1 2 3 4 UID 1 2
HP
ProLiant
5 8 DL360 G7
SID
1 2 3 4 UID 1 2
UPS
AMERICAN POWER CONVERSION
Services
8 APPENDIX A- TEMPLATE DOCUMENT:” EDOF PI REAL TIME ACQUISITION

ARCHITECTURE UAT/FUAT
Document code :
Revision :0
Creation date :
Revision date :
Document type Template for :User Acceptance Test/
:Final User Acceptance Test T
TITLE : eDOF PI real time acquisition architecture UAT/FUAT

PROJECT : eDOF PI architecture implementation
PHASE : System Testing and Final Acceptance test
Prepared by : ............................................. Role: eDOF team Support

Verified by : ............................................. Role:
Approved by : ............................................. Role:
Distributed by : ............................................. Role: .......................................
Services
DATE: 25-March-2016
REV DESCRIPTION PREPARED BY APPROVED BY
(EXP-DAST-DAOP)
CONTENT
1 DOCUMENT PURPOSE 3
2 INTENDED AUDIENCE 3
3 SCOPE OF WORK 3
4 INFRASTRUCTURAL TESTS 3
4.1 AUTHENTICATION TO OPC SERVER AND BROWSING OF TAGS 4
4.2 VERIFY CONNECTIVITY WITH ALL CONTRACTOR SOURCE NODES 4
4.3 PERFORMANCE TEST 6
5 FIREWALL SECURITY 6
6 HIGH AVAILABILITY 7
7 DATA MANAGEMENT 7
7.1 CREATE/EDIT/DELETE OPC TAGS 7
8 APPENDIX A-UAT TAGS LIST 9
9 APPENDIX B-FUAT TAGS LIST 10
Services
1 DOCUMENT PURPOSE
The objective of this document is to describe the guidelines to prepare the User Acceptance Test (UAT)
documents for testing the PI architecture of the real time data acquisition system, a key component of the
Digital Oil Field (DOF) system. The guidelines should be applicable during the system test and for the Final
User Acceptance test (FUAT) in the production Asset.
Appendix A and Appendix B shall be filled in with the full list of tags to be used as test set. The MAX number
of TAGS mentioned in the following chapter will be defined as the MAX number of tags acquired from the
production system for all the live cycle taking into account possible further expansion of the Asset.
2 INTENDED AUDIENCE
This document is intended for eni group IT Team and eni group project managers involved
in eDOF projects.
3 SCOPE OF WORK
The scope of work of the UAT activities to be held at CONTRACTOR test environment
_________ is to validate the architecture that CONTRACTOR has put in place to allow data
flow between the onsite control system of the CONTRACTOR and eni PI Server. The scope
of work of the Final UAT is to test that the full set of real time data in Appendix B will flow
from the production control system to the PI server(s) that could be on site and/or remote.
In the system-testing phase, a test environment should be put in place in CONTRACTOR

lab replicating the configuration to be applied onsite.
During the UAT, a VPN (Virtual Private network) will be established to allow communication
between the relevant servers in the CONTRACTOR lab network and PI server test in the
eni network. In case is not possible to provide the access through a VPN the data flow will
end in the PI OPC client node.
4 INFRASTRUCTURAL TESTS
The PI architecture real time acquisition foresees a high availability scenario, the following
paragraph will apply to all the involved OPC Server(s) machines and all the OPC Client
nodes.
Services
4.1 AUTHENTICATION TO OPC SERVER AND BROWSING OF TAGS

In order to achieve the connectivity between OPC Server(s) and OPC Client, a local
Windows user account with a never expiring password must be defined and inserted in the
local Administrators group. If the OPC Server and OPC client will be hosted on different
machines this account must be defined exactly in the same way both on the machine hosting
the OPC Server and the node hosting the PI OPC client.The connectivity between the 2
components will be tested.
The connection to the OPC Server will be in Read Only mode.

The test will be considered passed if using an OPC browser from the client node we will be able to connect to
the OPC Server(s), manually browse for tags and see their values.
This will prove that DCOM settings on the machine both at system level and at OPC Server Windows Service
level are set correctly. This will also ensure that authentication is set correctly on OPC Server. See the attached
OSIsoft documentation for DCOM Configuration Guide_OPCInt.
DCOM Configuration
Guide_OPCInt.pdf
Any OPC browser tool can be used to check the connectivity and to access the tag values.
Example of free OPC browsers are
OPC EXPERT (http://www.opcti.com/opcexpert.aspx)
Matrikon OPC Explorer (https://www.matrikonopc.com/products/opc-desktop-tools/opc-

explorer.aspx)
Additional tools can be used as well.
4.2 VERIFY CONNECTIVITY WITH ALL CONTRACTOR SOURCE NODES
Objective: Make sure we are able to read values for all exposed tags (with the same
precision.) from all CONTRACTOR source nodes, for each kind of data item type required:
• Analog Input
• Analog Output
• Digital Input
Services
• Digital Output
A non-exhaustive list could be as follows:
• Probes (temperature, humidity, pressure, flow, …)
• Power meters (current, voltage, active/reactive/real power, phase, frequency,

distortion, by phase and/or average)
• Inverters, Engines, Valves, … (control, feedback, speed, power usage, running time,
…)
• Digitally controlled devices (control, feedback and internal parameters like pressures,
temperatures, overall load, power usage depending on the specific device)
Before starting the test the CONTRACTOR shall provide the following information for all the data item:
1. Tag name (optional),
2. Tag Description,
3. Unit Of Measure
4. Instrument tag,
5. Data type,
6. Min value
7. Max value
8. Update frequency
9. Max Frequency to be applied in specific period Flag 3
3
In particular phase a specific subset of all tags need to be collected in an higher update frequency. This value
has to be agreed during the design phase.
Services
The test will pass if all tags defined in Appendix A (system test) or in appendix B (production
test) in the all relevant sources shall be manually browsable and we will be able to see their
values using one of the above mentioned OPC browsers.
4.3 PERFORMANCE TEST

Obejctive: Make sure the system can take the load of retrieving the required list of tags with
required frequency without affecting the performance of normal operations.
The acceptance test will consist of running the system under predefined load (test
scenarios). The test scenarios should represent the worst case load for the system, with
some margins as follows:
• 1.5x the total number of tags will be queried
• polling rate will be the fastest supported by every device
• running time will be no less than 5 days
If data sources other than the data acquisition system are expected (eg: SCADA), their load
(at worst case) will be included, too.
The test is passed if during its execution the resources are not loaded above than 70%
average and no slowdown that could hamper either the operation of the control system or
the data acquisition in PI (or both of them) are reported.
Three scenario examples to be defined and tested are reported below:
1. MAX number of tags with scan rate of 1 min
2. 50% of MAX number tags with scan rate of 1 min + 50% of MAX number tags with
scan rate of 1 sec
3. MAX number tags with scan rate of 1 min + MAX number tags with scan rate of 1 sec
Performances will be monitored taking into account these scenarios.
We will report how the system is behaving making sure operations are not slowed down.
Services
5 FIREWALL SECURITY
Objective: Make sure that firewall is properly set and is preventing access to CONTRACTOR
machines on the back end.
Verify IP and port filtering, simulating telnets to CONTRACTOR nodes
The test is passed if from the OPC Client nodes we are able to telnet the OPC Data Hub
machine on port 135 4 only.
As between OPC Data Hub machine and OPC Client nodes a broad range of ports must be
open (dynamic allocation on any port between 1024 and 65535) we will not require a specific
test in this case.
6 HIGH AVAILABILITY
Objective: Make sure the High Availability with hot standby at OPC Server side and Hot
Failover at OPC Client side is working properly.
We will simulate failures on the two OPC Server(s) machines (one at a time) and see if this
will be transparent to the OPC clients collecting the data.
Moreover, we will simulate failures on the two OPC Client nodes (one at a time) and see if
this will be transparent to the data flow in PI.
We can simulate the three following downtimes, applicable to OPC servers and Clients
• HW / OS Failure  shutdown one of the two nodes
• Network Failure  remove network cable from one of the two nodes
• Application Failure  Stop the OPC Server/Client Windows Service from one of the
two nodes
The test will pass if in all the above downtimes the data flow in PI will not be interrupted
7 DATA MANAGEMENT
4
Port 135 is the only port that the PI OPC Client uses to connect to the OPC Data Hub machine.
Services
7.1 CREATE/EDIT/DELETE OPC TAGS AND TEMPORARILY CHANGE DATA FREQUENCY FOR
SPECIFIC TAGS
Objective: Make sure we are able to implement any change requested for tags exposed to
the OPC Server Data Hub: creation of a new tag, change of an existing tag and/or deletion
of a tag.
For the FUAT the CONTRACTOR will provide a procedure to let the on-site personnel be
able to modify the tags exposed to the OPC Server Data hub.
A test of the execution of the step in the procedure will be performed during the Final UAT
Services
8 APPENDIX A UAT LIST OF TAGS

Tag Description UOM Instrument Data Min Max Update Frequency
name tags type value value frequency to be
applied in
specific
period
Services
9 APPENDIX B FUAT LIST OF TAGS

Tag name Description UOM Instrument Data type Min value Max value
tags

EDOF PI Architecture blueprint overview

Uploaded by

Document Information

Original Description:

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

EDOF PI Architecture blueprint overview

Uploaded by

Copyright:

Available Formats

eni S.p.A.

EDOF- PI ARCHITECTURE BLUE PRINT

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 1-38

EDOF- PI ARCHITECTURE BLUE PRINT

REV DESCRIPTION PREPARED BY APPROVED BY

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 2-38

2.1.1 Data Types 7

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 3-38

7.2.1 Branch PI server 26

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 4-38

1.1. DOCUMENT PURPOSE

1.2. INTENDED AUDIENCE

1.3. UPDATE HISTORY:

Version Date Author Changes

1.4. TERMINOLOGY AND ACRONYMS

DCS Distributed Control System

SCADA Supervisory Control And Data Acquisition

PCN Process Control Network (named Control Room)

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 5-38

DCOM Distributed Component Object Model

DA Data Access (type of OPC server)

HDA Historical Data Access (type of OPC server)

RDP Remote Desktop Protocol

iLO Integrated Lights-Out (physical devices on servers used

HQ eni HeadQuarter (San Donato Milanese – MI)

OPC server Server providing OPC connections to OPC clients

Contractor Contractor responsible for the Automation System of the

UFO PI Universal Failover mechanism, based on a text file

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 6-38

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 7-38

2 DATA ACQUISITION REQUIREMENTS

2.1 REAL TIME DATA

2.1.1 Data Types

In principle every digitally available data shall be collectable.

2.1.2 Polling rate

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 8-38

2.2 COMMUNICATION PROTOCOL

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 9-38

3.1 TEST ENVIRONMENT

3.2 TEST SET

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 10-38

4 REAL TIME DATA ACQUISITION ARCHITECTURE

4.1 HIGH LEVEL DESIGN

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 11-38

4.2 COMPONENT DESCRIPTION

The Real Time data acquisition architecture is based on following components:

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 12-38

2. HA PI Collective (High Availability Version of Minimum Requirement): two or more PI

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 13-38

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 14-38

5.1 PCN AND OFFICE INTERNETWORKING

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 15-38

5.2 PI INTERFACES POSITIONING

• PI Interface nodes logically situated in the PCN:

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 16-38

• PI interface Nodes located in the eni’s Office Network:

• Up to eight – 1Gb Ethernet network interfaces - TRAFFIC with OPC servers

5.3 PI SERVER(S) POSITIONING

The single PI server will require:

• Two – 1Gb Ethernet network interfaces – TRAFFIC

DOC. n. 3/2016 (EXP-DAST-DAOP) PAG. 17-38

ProcessBook, PI DataLink) has to be guaranteed. In particular: