Ofsopc: With Citect SCADA 2016

OFSOPC with Citect SCADA 2016
April 2017 - White paper
Martin Lalanne
Summary
I. Introduction 3
1.1 Architecture Overview 3
1.2 SCADA Project 4
1.3 Computer Selection 4
1.4 PAC Selection 4
1.5 PAC Sizing 5
1.6 PAC Scan Cycle 6
II. Citect SCADA Communication 7

2.1 Communications Overview 7
2.2 Citect SCADA Communications detail 9
III. OFSOPC Driver 10

3.1 OFS Internal Architecture 10
3.2 OPC Communications 10
3.3 OFSOPC Driver 11
3.4 Startup and Redundancy 12
IV. OFS Configuration 13

4.1 OFS Alias 13
4.2 OFS Communication Parameters 25
4.3 OFS Options 25
V. Citect SCADA Fast Link 27

5.1 Import PAC Tags with Fast Link 27
5.2 Add / Modify / Delete Tags 30
VI. Performance 32
6.1 SCADA Redundancy 32
6.2 PAC Redundancy 33
6.3 PAC Scantime 33
6.1 OFS Server communication modes 34
2
I. Introduction
Applies to:
 Citect SCADA 2016
 OFS 3.60 SP2
 OFSOPC V2.05.46
 Modicon M340, M580 and M580 HSBY
 Unity Pro v11.1
Summary:
This document will illustrate how to set up Citect SCADA, the OFSOPC driver and OFS to communicate
with Schneider PACs.
This document will also describe the Citect SCADA best practices, OFSOPC driver configuration, OFS
setup as well as the communication capabilities of Schneider Electric PACs; M340 (BMX P34 2020),
M580 (BME H58 4040), M580 Hot Standby (BME H58 6040).
1.1 Architecture Overview
Figure 1: System Architecture Overview
3
1.2 SCADA Project

Two test projects were used to provide results in this document.
Project 1:
 10,000 I/O | 3,750 Alarms | 6,250 Trends
 2,500 Analog | 7,500 Digital tags
Project 2:
 20,000 I/O | 7,500 Alarms | 12,500 Trends
 5,000 Analog | 15,000 Digital tags
Both projects were built and run with the following characteristics:
 25 / 75 per cent split between analog and digital points
 Two per cent of analogs change every seconds
 One per cent of digitals change every 60 seconds
The simulation is focused on providing a base load to allow realistic timing measurements.
1.3 Computer Selection

The SCADA servers run on physical PC machines with the following specifications:
 Windows Server 2012 R2
 Intel Core i7-3770 CPU 3.40 GHz
 16 Gb RAM
 Hard Drive 2 Tb
1.4 PAC Selection

A number of different models were selected to explore the different performance characteristics of
each PAC. A total of three PACs with varying sizes and capabilities were chosen.
M340 PAC System

The M340 is a compact mid-range PAC suited to process control and industrial applications. It is capable
of supporting various industrial protocols by installing optional communication modules. It also forms part
of the Ethernet Remote I/O solution.
The built in CoPro was chosen as the communications channel for SCADA-to-PAC communications.
This is the preferred channel, due to increased throughput and capabilities.
Additional communications modules can be added for dedicated programming, PAC-to-PAC
communications, I/O scanning, global data and many other industrial protocol standards.
4
M580 PAC System

The M580 is a compact high-range PAC. It is suitable for a number of medium to large sized applications
requiring advanced control, scalability and flexibility. It is capable of supporting various industrial
protocols by installing optional communication modules. It also forms part of the Ethernet Remote I/O.
The CPU Channel was chosen as the communications channel for SCADA-to-PAC communications.
This is the preferred channel, due to increased throughput and capabilities.
Additional communications modules can be added for dedicated programming, PAC-to-PAC
communications, I/O scanning, global data and many other industrial protocol standards.
M580 Hot Standby PAC System

The M580 hot standby system provides high speed exchange capacity and the I/O sizing requirements
for large projects. It was chosen to demonstrate the PAC redundancy performance capabilities for the
SCADA-to-PAC channel with OFSOPC.
1.5 PAC Sizing

The following table summarizes the type, tag count and channel selected for communications with SCADA:
PAC Type Comm Channel Max Number Requests Tag Count
per Scan per Channel
M340-BMXP342020 Stand-alone CoPro 12 10,000 (Project 1)
M580-BMEP584040 Stand-alone CPU 24 20,000 (Project 2)
NOR 16
M580-BMEH586040 Hot standby CPU 32 20,000 (Project 2)
Table 1: PAC Details
For all controllers the server processes the requests at the beginning of the scan. The resources
available to process requests depend on the controller model.
The server communication resource of a PAC can be adjusted using the system word %SW90. Adjusting
this parameter will adjust the maximum number of requests the PAC can handle per CPU scan.
PAC Default Maximum Value Used

M340-BMXP342020 8 12 12
M580-BMEP584040 32 40 32
M580-BMEH586040 56 64 56
Table 2: Number of Requests PAC Configuration
5
1.6 PAC Scan Cycle
Figure 2: Synchronous PAC Scan Cycle
The figure above illustrates the synchronous scan cycle of the PAC. It can be seen that communications
processing occurs at the start of scan. This information should be taken in the context of the number of
requests the CPU can process per scan. It is also important to note that the PAC scan time can impact
the communications performance and throughput.
6
II. Citect SCADA Communication

2.1 Communications Overview
The following diagrams provide a high level overview of the communications configuration for Citect
SCADA, OFS and PAC controllers.
The current architecture of the OFSOPC driver only supports having Citect SCADA and OFS on the
same physical machine. It is therefore important to note that most communication delays and
optimization will be on the link between the OFS Server and the PACs. We advise that the channel
between OFS and the PAC should therefore first be analysed and optimized, before modifying any
SCADA parameters.
The first diagram focuses on the Primary SCADA Server and the second diagram focuses on the Standby
SCADA Server.
Important:
One port is recommended to host several I/O Devices with the OFSOPC Driver
Primary SCADA server:
Figure 3: System Communication Diagram - Primary Server
Standby SCADA server:
7
Figure 4: System Communication Diagram - Standby Server
8
2.2 Citect SCADA Communications detail

The following diagrams show one example of the communications configuration for Citect SCADA.
There are two parts, Primary and Standby SCADA.
Note: This example demonstrates the configuration for a single redundant I/O Device.
Figure 5: Citect SCADA communications detail
Detailed information about individual communications configuration properties can be found in the
online help.
9
III. OFSOPC Driver

3.1 OFS Internal Architecture
The OPC Factory Server (OFS) is composed of three main components:
1. A communication task (COM Handler) which manages communication with a device
2. A shared memory area (Cache Memory)
3. An OPC task that manages groups and OPC method access from groups
The figure below shows the internal architecture of the OFS server:
Figure 6: OFS internal architecture
3.2 OPC Communications

This section will describe the typical behaviour of the Citect SCADA OFSOPC driver (OPC client)
connecting to OFS. When the I/O server starts, the OFSOPC driver creates three OPC groups for each
I/O Device with different update rates using the notification mechanism:
- Group 1 with 400ms update rate (created with name “<OFSAlias>_GROUP_1”)
- Group 2 with 1s update rate (created with name “<OFSAlias>_GROUP_2”)
- Group 3 with 3s update rate (created with name “<OFSAlias>_GROUP_3”)
The three OPC groups are first created as inactive. The OFSOPC driver then adds all items (configured
variable tags) as active in Group 1. A status tag <OFSAlias>!#PLCQualStatus which has its own OPC
group (“STATUS_GROUP”) is read. If it returns healthy status, the driver will set the three groups active,
which effectively brings the unit online and OFS starts polling the device. As the different subscription
rates for each variable tag stabilise, items are moved between OPC groups to best match the requested
update rate.
Two additional groups are created by OFS for PAC Status and data dictionary management:
- Group at 500ms for the PAC Status

o <OFSAlias>!#PLCQualStatus
o <OFSAlias>!#PLCDataDicReady
- Group at 2s which is managing the consistency of data dictionary with service requests
On the OPC Handler side several groups will be created and refreshed to satisfy the OFSOPC driver
requested update rates.
On the controller communication side (COM Handler), three groups will be created with update rates of
400ms, 1s and 3s. The communications for each group period will be calculated and optimized in order
to send the minimum number of requests to the controller.
10
Each time an item is activated or deactivated the request optimization will re-evaluate the communication
requests. Within the created groups the items added by the OFSOPC driver will be either active or
inactive depending on the need of the SCADA system.
In general, the alarm and trend items will always be active, while for visualization only the displayed
items are active. Other items that are not requested are not exchanged between the OFS and the
controller. This mechanism optimizes the communication between OFS and the controller, sending the
minimum amount of data to satisfy all requests.
When a new page is displayed on the SCADA system, the OFSOPC driver activates the item and
promotes it into the group with the required update rate. It then disables any items that were previously
displayed but no longer required. The deactivation time is five (5) seconds.
3.3 OFSOPC Driver

It is recommended to use the latest version of the OFSOPC driver that is available.
This document targets OFSOPC V2.05.46.00000 or greater.
The OFSOPC driver defines three groups per I/O device. These groups are polled at a rate defined by
the [OFSOPC]Group<i>UpdateRate parameter in citect.ini.
These poll rates should be set such that:
 Group1UpdateRate < Group2UpdateRate < Group3UpdateRate

 Group1UpdateRate < AlarmScanTime
 Group2UpdateRate < Fast trend sampling time
 Group3UpdateRate < Slow trend sampling time
The default values are:
 Group1UpdateRate = 400ms
The minimum group update rate is 50ms in OFS 3.60 SP2. This parameter is fixed and can’t be changed.
Each requested tag will be added in the group which provides the lowest (e.g. fastest) update rate and
the one that is faster than the requested rate. For example, a tag with a request rate of 2s will be activated
in Group 2 if the default values are being used.
If no group provides such a rate, then Group 1 (the fastest group) is used. For example, tags requested
at 200ms with default configuration will be put in the 400ms group.
Usually Group 1 is associated with variable tags in the active display page and alarms. Group 2 is
typically targeted for use by trends and Group 3 is there for slow trends if they are configured.
11
3.4 Startup and Redundancy

On startup, the OFSOPC driver connects to OFS and checks the connection status of the device. The
I/O device with the best availability and highest priority will become activate first.
 The OFSOPC driver adds five groups for each device.
Figure 7: OFS groups in Client window
 The groups are initially in the inactive state except for the Status group.
 Items are added in the inactive groups in the active state.
 Once all items are added, the OFSOPC driver enables the group for primary devices.
 On the standby machine the groups are in the inactive (disabled) state.
 During a redundancy switchover event, the OFSOPC driver on the Standby I/O Server sets the
groups active, which enables communications to the controller.
12
IV. OFS Configuration

Schneider Electric’s OPC Factory Server (OFS) is required to be installed on each Citect SCADA I/O
Server, as DCOM is not supported by the OFSOPC driver.
The following section details the OFS configuration used in this example and makes some
recommendations regarding key parameter settings for better performance.
4.1 OFS Alias

The alias configuration is important to optimize communication between OFS and the controller. This
section describes how to optimize the settings of an alias.
4.1.1 Add Device Alias
 In the OFS Configuration Tool, create a New Device Alias in the Device overview section.
 Define a name. This name will be use in Citect SCADA for the IO Devices communication.
 Define the IP address of the PAC in Device address A for a single communications channel.
Figure 8: OFS Alias configuration
13
4.1.2 Dual communication channels
OFS can support two communication channels to each PAC. In this example, the M580 PAC has an
additional channel with the NOR communication module. In OFS one address is defined for the M580
CPU module and one for the NOR communication module. Both modules are connected to the Plant
Network which provides a redundant link to communicate between the M580 PAC and OFS (which
serves the Citect SCADA system). This removes complexity from the Citect SCADA configuration as
you only define a single I/O device, while OFS handles the dual channel communication.
Figure 9: M580 PAC Overview in Unity Pro
 For dual channel configuration in OFS, enter the second IP address in Device address B.
Figure 10: OFS Alias configuration – Dual communication channels
 If Device address A is not available, OFS will automatically switch to Device address B
Figure 11: Diagnostic window logs in OFS Server
 Device address B will become the Primary address
14
Figure 12: OFS network window for M580 PAC
Once Device address A is available again, it will be the Primary address for OFS only if Device
address B is shutdown or the OFS Server is restarted.
4.1.3 PAC Hot Standby Configuration
The OFS configuration with Hot Standby Controller (M580 HSBY) only needs a unique Main IP
Address. It should be noted that the Standby PAC address corresponds to the Main IP +1.
The SCADA system must not use the Standby PAC address (Main IP+1), since no control commands
are processed. Only the Main can handle control commands and manages synchronisation with the
Standby.
Note:
Do not use the Standby PAC IP address for communication with SCADA
 Define the Main IP address for the PAC in the first field in IPConfig tab in Unity. This address is
used by the SCADA system for communications. The IP+1 is created automatically for the
redundant PAC (Standby).
Figure 13: Unity Pro PAC – Main IP & IP+1 addresses
 Use only the Primary PAC IP address in OFS configuration.
15
Figure 14: OFS configuration with the main PAC IP address
4.1.1 OFS communication Modes
There are different scenarios to configure OFS communication:
 XVM Symbol table file only

 XVM Symbol table file & Using Data Dictionary
 Using Data Dictionary only
Figure 15: OFS communication mode overview
16
4.1.1.1 Data dictionary
 In Unity Pro, open Project Settings and select the Data dictionary option.
Figure 16: Data dictionary setting in Unity Pro
 Select “Only HMI variables” when variables are configured with the HMI variable option. This
allows OFS to load only the HMI variables from the PAC. It also optimises the size of the Data
Dictionary that is then stored in the PAC memory.
Figure 17: Variables in Unity Pro with HMI variable option
 In the OFS Configuration Tool, select Using Data Dictionary and No Communication Break
options. If No Communication Break is set, While OFS server is copying the new data
dictionary, OFS will continue to use old one.
17
Figure 18: OFS Alias configuration data links
4.1.1.2 Symbol Table (XVM)
 To generate XVM file, export Variables in Unity Pro on the XVM format.
Figure 19: Generate Symbol Table XVM in Unity Pro
18
 In OFS configuration, specify the symbol table file (XVM) path.
Figure 20: OFS configuration with Symbol Table XVM
Note: It is possible to combine Data Dictionary and Symbol table file. More details about the performance can be
found in section 6.1.
Figure 21: OFS configuration with Symbol Table XVM and Data Dictionary
19
 Define Consistency level for Symbol table file
- Strict Mode: OFS will stop communicating to the controller when there is any mismatch between the
controller and XVM signatures. Once XVM signatures match, it starts communicating.
- Debug Mode: OFS will ignore any minor changes like changed code, comment added, Tag added in
the controller
Figure 22: Consistency level mode
4.1.2 OFS Parameters
The key parameters to adjust communication with the controller are the Max Channels and Max Pending
parameters.
 Max Pending – the number of requests that are allowed to be sent in parallel to the controller
 Max Channels – the maximum number of TCP/IP connections that OFS will open with the
controller
 By default, MaxChannels = 1 and MaxPending = 0
MaxPending: Number of requests that are allowed to be sent in parallel to the controller
A setting of MaxPending=0 means the OFS server automatically detects the PAC’s target
communications port and decide how many parallel requests may be sent at the same time. OFS will
choose the appropriate MaxPending value using a predefined table of communication modules. It is
preferable to let OFS choose the value of the MaxPending parameter, unless a new release of a PAC
firmware changes the capability of the device.
20
In case of multiple OFS connections to the same PAC (redundant IO Server), it is recommended to set
MaxPending to the capacity of the channel (refer to Table 1: PAC Details). This number depends on
the PAC type and the number of channels the user wants to configure on the PAC for OFS.
Max Channels: Maximum number of TCP/IP connections that OFS will open with the controller
It should be considered that for Unity devices (frame length = 1023 Bytes) the TCP/IP stack is able to
buffer up to 4 KB. Therefore, it is possible to configure
MaxChannels = MaxPending / 4
By increasing the number of channels, it increases the communications "fault tolerance" if a connection
becomes unavailable. It also makes it possible to send parallel requests and increases the reliability of
the communication by distributing the load.
4.1.3 Identifying request requirements for the Alias
From OFS, it is possible to view the number of requests needed to refresh items from a specific group.
 When OFS is running, in the General menu, select Network Window and then select the
appropriate device.
Figure 23: OFS network windows
 Expand the Nb Timers section as shown below:
Figure 24: OFS network window for M580 PAC
21
Net Request gives you the number of requests needed for each group. In this example we can see that
27 requests (Total of Net Request across all groups) are needed to retrieve all data from the controller.
Information for this controller in terms of response times is also available. Average Access Time is the
time typically taken for the controller to respond to OFS requests (12 ms).
Max Channels and Max Pending parameters configuration with the M580 system:
To fully exploit the bandwidth of the M580 PAC, the following OFS configuration is recommended.
For the M580 PAC in our test system, two channels with different communications capabilities are
present. The CPU channel is capable of processing 24 requests per CPU scan, while the NOR channel
is capable of processing 16 requests per CPU scan. We must set the number of pending requests
such that the channel capability is not exceeded. Therefore, the Max Pending value of 16 is selected.
From OFS diagnostics, it can be seen that 27 requests will be processed in two (2) CPU cycles if we
consider that 16 requests are processed per CPU cycle.
In this example it is recommended that the Max Channels is set to 4 and Max Pending is set to 16 for
the Alias configuration in OFS.
Figure 25: Max Channels and Max Pending
Given the details above the following OFS configuration is used for each controller:
PAC MaxChannels MaxPending

M340 3 12
M580 4 16
M580 HSBY 8 32
Table 3: OFS configuration Details
22
The following figures detail the M340 which is used in the example calculation above.
Figure 26: OFS network window for M340 PAC Figure 27: OFS Configuration adjustment for M340 PAC
The following figures detail the M580 Hot Standby
Figure 28: OFS network window for M580 HSBY PAC Figure 29: OFS Configuration adjustment for M580 HSBY
23
4.1.1 Optimize OFS group time scan
In a heavily loaded system, it may be possible that a default group rate is too fast for OFS and overrun
errors may occur (“polling rate overrun for …”). For example, Citect SCADA is trying to poll the device
faster than it can provide data. In this case, it would be recommended to increase the OFSOPC group
rate value.
OFS diagnostic window provides info on current communication statistics.
Figure 30: OFS network window for M580 PAC Figure 31: OFS Configuration adjustment for M580 PAC
OFS group time scan can be calculated as per following formula:
OFSTimeScan= AverageAccessTime * NetRequests / MaxPending
Following the M580 example with the OFS Group 1:
 AverageAccessTime = 12 ms
 NetRequests = 8 (for group 1 at 400ms)
 MaxPending = 16
OFSTimeScan = 12 ms * 8 requests / 16 (MaxPending) = 6 ms
The data from the controller for the group 1 will be read in average after 6 ms time scan.
The group period must be longer than this ‘minimum’ time. A general rule is to have group rate at least
twice the value of OFS group scan time. The default group 1 update rate setting of 400 ms is suitable
for this example.
24
4.2 OFS Communication Parameters

When using the OFSOPC driver the following parameters must be activated:
Quick Item Validation: An OPC Method is available to validate an item when it is requested from OFS.
By default, OFS checks if the value is reachable in the controller and this requires a request to be sent.
When Quick Item Validation is enabled, OFS does not run the ‘IsValid’ method.
Quick SetActive State: This parameter refreshes the OPC Client as soon as the value is known without
waiting for the notification period, as the OPC specification defines.
Communication Overrun: This parameter defines whether a communications overrun in OFS should
be notified to the SCADA as ‘bad quality’ or if the OFS server should instead try to auto-adapt its own
polling rate. It is recommended to set this parameter to ‘rate adapt’ to avoid potential false ‘bad quality’
readings when the load on OFS or the PAC is high.
 Select Rate adapt for the Communication Overrun behaviour

 Select Quick item validation & Quick SetActive State in Advanced feature.
 Enable OPC extensions is mandatory.
Figure 32: Communication windows in OFS configuration
4.3 OFS Options

In multi-processor machines it is strongly recommended to set the Processor Affinity of the OFS
server such that it does not run on the same processor as the SCADA I/O Server.
Figure 33: Option windows in OFS configuration
25
OFS is set to CPU 0 and Citect processes are set to use other available CPUs.
 For the Citect Project, unselect CPU 0 in Setup Wizard in CPU Setup
Figure 34: CPU Setup in Citect Setup Wizard
26
V. Citect SCADA Fast Link

5.1 Import PAC Tags with Fast Link
It is possible to import PAC tags into Citect SCADA using the Fast Link feature.
If you link to the PAC database, Citect SCADA is updated with any changes made to the PAC when a
refresh is performed.
Note:
OFS has to be configured and ready to run before importing the PAC tags.
Step 1: Use the Express Communications Wizard to Link your I/O Device to the PAC tag database.
Figure 35: Link I/O Device to the PAC tag database
Step 2: Select Unity SpeedLink to OFS Database type and Browse.
27
Figure 36: Browse external OPC database available
Step 3: Select the PAC branch to import and finalize the express communication wizard procedure.
Figure 37: Complete the Express Communication wizard
You can find the I/O Device configuration in the I/O Devices form in Topology >> IO Devices
Figure 38: I/O Device configuration
28
 Refresh tags manually using Refresh tags button in I/O Devices section
 Select Automatic Refresh option to True for automatic updates
Figure 39: Refresh Linked Tags
Figure 40: Import Tags
29
5.2 Add / Modify / Delete Tags

When Fast Link is used in a Citect SCADA project, if you disconnect an existing link, you can choose to
make a local copy of the tags or you can delete them from Citect SCADA's variable tags database
altogether.
Use the same methodology to add, modify and delete tag across the PACs and Citect SCADA:
 Add/Modify/Delete tag in the PAC
Figure 41: Add Variable tag in Unity Pro
 Compile, Download and Run Unity project
Note:
OFS has to be configured and ready to run before refreshing the PAC tags.
 In Citect SCADA, Refresh tags in Topology view for the selected IO device.
Figure 42: Refresh Linked Tags
30
 Tags will be automatically added/modified/deleted in the Citect SCADA variables list
 Restart IO Server process to refresh tags in Citect SCADA runtime
31
VI. Performance
6.1 SCADA Redundancy
The following tests were performed using Citect SCADA 2016 with the 20,000 IO tag SCADA project (
Project 2) and Schneider PACs.
Time measurements were made by monitoring a trend tag in Process Analyst and using a cicode
function to check the connection status of the IO Devices.
Measured startup time to get I/O Device online:
PAC Startup time

M340 9 sec
M580 14 sec
M580 HSBY 16 sec
Table 4: Startup time
Note: A registry change was set in Windows on the Citect Server machine to improve redundancy
switchover performance in the case of a network isolation.
 Add the KeepAliveTime parameter to the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters section with
the value 3000
Figure 45: Registry Editor in Windows
M340 PAC:
Mode of Failure Switchover time
Primary IO Server shutdown 2.0 sec
Primary IO Server interruption (end task) 2.0 sec
Primary IO Server network isolation 13 sec
Table 5: Redundancy switchover time with M580 PAC
M580 PAC:
Table 6: Redundancy switchover time with M580 PAC
32
M580 HSBY PAC:

Table 7: Redundancy switchover time with M580 HSBY PAC
6.2 PAC Redundancy

PAC Hot Standby Switch Over:
A failure was simulated on the Primary controller to enable a Hot Standby switchover and check the
behaviour of the SCADA system. A Citect Client was displaying tags, alarms and trends properly during
and after the PAC Hot Standby switchover. The PAC redundancy switchover worked seamlessly and
fast, such that there was no measurable SCADA communications interruption, which was to be expected.
6.3 PAC Scantime

The round trip time on the SCADA I/O server was measured to understand the communications
performance at the data acquisition layer. This was achieved by sending via cicode a command bit to
the PAC, which increments a counter variable and then measuring the time difference for the value to
arrive in the I/O server cache. A different PAC scantime was used for each test (see table below).
A total of 10 tests were run for each scantime per controller type, with the average and max times
recorded.
M340 PAC:
CPU Scantime Avg Time (ms) Max Time (ms)
10 518 615
50 600 707
100 678 719
Table 8: M580 PAC round trip time
M580 PAC:
10 469 511
50 708 869
100 770 856
M580 HSBY PAC:

10 481 705
50 574 686
100 709 866
It can be seen from the above tables that a lower CPU scantime value will have a direct impact on the
responsiveness of the SCADA communications.
33
6.1 OFS Server communication modes

The OFS Server communication mode is defined by the way in which it accesses the application
symbols.
The different scenarios to configure OFS Server are:
 XVM Symbol table file only

 XVM Symbol table file & Using Data Dictionary
 Using Data Dictionary only
The following tests were performed using Citect SCADA 2016 with the 20,000 IO tag SCADA project
(Project 2) with the Schneider M580 ePAC. Each scenario was tested with the same SCADA system.
Time measurements were made by monitoring a trend tag in Process Analyst and using a cicode
function to check the connection status of the IO Devices.
Measured startup time to get I/O Device online:
M580 Startup time

XVM only 11 sec
XVM + Data Dictionary 13 sec
Data Dictionary only 15 sec
Table 11: Startup time vs. OFS communication mode
34
© 2017 Schneider Electric. All rights reserved.
Schneider Electric
78 Waterloo Road
Macquarie Park NSW 2113
Phone: + 61 (0) 1300 369 233 April 2017
www.schneider-electric.com
35

Ofsopc: With Citect SCADA 2016

Uploaded by

Copyright:

Available Formats

Ofsopc: With Citect SCADA 2016

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

Ofsopc: With Citect SCADA 2016

Uploaded by

Copyright:

Available Formats

OFSOPC with Citect SCADA 2016

April 2017 - White paper

II. Citect SCADA Communication 7

III. OFSOPC Driver 10

IV. OFS Configuration 13

V. Citect SCADA Fast Link 27

1.1 Architecture Overview

Figure 1: System Architecture Overview

1.2 SCADA Project

1.3 Computer Selection

1.4 PAC Selection

M340 PAC System

M580 PAC System

M580 Hot Standby PAC System

1.5 PAC Sizing

PAC Default Maximum Value Used

1.6 PAC Scan Cycle

Figure 2: Synchronous PAC Scan Cycle

II. Citect SCADA Communication

Primary SCADA server:

Figure 3: System Communication Diagram - Primary Server

Standby SCADA server:

Figure 4: System Communication Diagram - Standby Server

2.2 Citect SCADA Communications detail

Figure 5: Citect SCADA communications detail

III. OFSOPC Driver

Figure 6: OFS internal architecture

3.2 OPC Communications

- Group at 500ms for the PAC Status

3.3 OFSOPC Driver

These poll rates should be set such that:

 Group1UpdateRate < Group2UpdateRate < Group3UpdateRate

The default values are:

3.4 Startup and Redundancy

 The OFSOPC driver adds five groups for each device.

Figure 7: OFS groups in Client window

 Items are added in the inactive groups in the active state.

IV. OFS Configuration

4.1 OFS Alias

4.1.1 Add Device Alias

Figure 8: OFS Alias configuration

4.1.2 Dual communication channels

Figure 9: M580 PAC Overview in Unity Pro

Figure 10: OFS Alias configuration – Dual communication channels

Figure 11: Diagnostic window logs in OFS Server

 Device address B will become the Primary address

Figure 12: OFS network window for M580 PAC

4.1.3 PAC Hot Standby Configuration

Figure 13: Unity Pro PAC – Main IP & IP+1 addresses

 Use only the Primary PAC IP address in OFS configuration.

Figure 14: OFS configuration with the main PAC IP address

4.1.1 OFS communication Modes

There are different scenarios to configure OFS communication:

 XVM Symbol table file only

Figure 15: OFS communication mode overview

4.1.1.1 Data dictionary

Figure 16: Data dictionary setting in Unity Pro

Figure 17: Variables in Unity Pro with HMI variable option

Figure 18: OFS Alias configuration data links