Rockwell Automation FactoryTalk Historian SE 3.0 User Manual
FACTORYTALK HISTORIAN TO HISTORIAN INTERFACE
USER GUIDE
PUBLICATION H2H-UM001A-EN-E–July 2012
Contact Rockwell Automation
Customer Support Telephone — 1.440.646.3434
Online Support — http://www.rockwellautomation.com/support
Copyright Notice
© 2012 Rockwell Automation Technologies, Inc. All rights reserved. Printed in USA.
© 2010 OSIsoft, Inc. All rights reserved.
This document and any accompanying Rockwell Software products are copyrighted by Rockwell Automation Technologies, Inc.
Any reproduction and/or distribution without prior written consent from Rockwell Automation Technologies, Inc. is strictly
prohibited. Please refer to the license agreement for details.
Trademark Notices
FactoryTalk, Rockwell Automation, Rockwell Software, the Rockwell Software logo are registered trademarks of Rockwell
Automation, Inc.
The following logos and products are trademarks of Rockwell Automation, Inc.:
FactoryTalk Historian Site Edition (SE), FactoryTalk Historian Machine Edition (ME), RSView, FactoryTalk View, RSView
Studio, FactoryTalk ViewStudio, RSView Machine Edition, RSView ME Station, RSLinx Enterprise, FactoryTalk Services
Platform, FactoryTalk Live Data, and FactoryTalk VantagePoint.
The following logos and products are trademarks of OSIsoft, Inc.:
PI System, Sequencia, Sigmafine, gRecipe, sRecipe, and RLINK.
Other Trademarks
ActiveX, Microsoft, Microsoft Access, SQL Server, Visual Basic, Visual C++, Visual SourceSafe, Windows, Windows ME,
Windows NT, Windows 2000, Windows Server 2003, and Windows XP are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
Adobe, Acrobat, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States
and/or other countries.
ControlNet is a registered trademark of ControlNet International.
DeviceNet is a trademark of the Open DeviceNet Vendor Association, Inc. (ODVA).
Ethernet is a registered trademark of Digital Equipment Corporation, Intel, and Xerox Corporation.
OLE for Process Control (OPC) is a registered trademark of the OPC Foundation.
Oracle, SQL*Net, and SQL*Plus are registered trademarks of Oracle Corporation.
All other trademarks are the property of their respective holders and are hereby acknowledged.
Restricted Rights Legend
Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause at DFARS 252.227-7013.
Warranty
This product is warranted in accordance with the product license. The product‟s performance may be affected by system
configuration, the application being performed, operator control, maintenance, and other related factors. Rockwell Automation is
not responsible for these intervening factors. The instructions in this document do not cover all the details or variations in the
equipment, procedure, or process described, nor do they provide directions for meeting every possible contingency during
installation, operation, or maintenance.
This product‟s implementation may vary among users.
This document is current as of the time of release of the product; however, the accompanying software may have changed since
the release. Rockwell Automation, Inc. reserves the right to change any information contained in this document or the software at
anytime without prior notice. It is your responsibility to obtain the most current information available from Rockwell when
installing or using this product.
Table of Contents
Chapter 1. Introduction ................................................................................................ 1
Interface Limitations ............................................................................................ 1
Interface Requirements ....................................................................................... 2
Reference Manuals ............................................................................................. 3
Supported Operating Systems ............................................................................ 3
Supported Features............................................................................................. 3
Diagram of Hardware Connection ....................................................................... 7
Chapter 2. Principles of Operation ................................................................ ............ 11
Interface Startup ................................................................................................ 11
How FactoryTalk Historian to Historian Finds Source Points ........................... 12
Data Collection .................................................................................................. 13
History Recovery ............................................................................................... 14
Exception Data Collection ................................................................................. 15
Maximizing Data Throughput .................................................................. 15
Archive Data Collection ..................................................................................... 16
Performance Considerations .................................................................. 16
Data Timestamps .............................................................................................. 17
Data Type Conversions ..................................................................................... 17
Interface Status Events ..................................................................................... 18
Adding, Removing and Editing Tags ................................................................. 18
Error Handling ................................................................................................... 19
Source Historian Server-Level Failover ............................................................ 19
Fault Conditions ................................................................................................ 19
Communication Failure ........................................................................... 19
Detection of Stale Data ........................................................................... 20
UniInt Failover ................................................................................................... 20
Interface Status Tags ........................................................................................ 20
Internal State Status .......................................................................................... 20
Failover Status .................................................................................................. 21
Deployment Scenarios ...................................................................................... 21
Historian to Historian within a Historian Collective ............................................ 21
Tag Attribute Override Parameters ......................................................... 22
Historian to Historian between Historian Collectives .............................. 24
Chapter 3. Installation Checklist ................................................................................ 27
Data Collection Steps ........................................................................................ 27
Interface Diagnostics ......................................................................................... 28
Advanced Interface Features ............................................................................ 29
Chapter 4. Interface Installation ................................................................................. 31
Naming Conventions and Requirements .......................................................... 31
FactoryTalk Historian To Historian Interface User Guide iii
Table of Contents
Interface Directories .......................................................................................... 32
PIHOME Directory Tree .......................................................................... 32
Interface Installation Directory ................................................................ 32
Interface Installation Procedure ........................................................................ 32
Installing Interface as a Windows Service......................................................... 32
Installing Interface Service with Historian Interface Configuration Utility .......... 33
Service Configuration ............................................................................. 33
Installing Interface Service Manually ...................................................... 35
Chapter 5. PointSource .............................................................................................. 37
Chapter 6. Historian Point Configuration .................................................................. 39
Point Attributes .................................................................................................. 39
Tag .......................................................................................................... 39
PointSource ............................................................................................ 40
PointType ................................................................................................ 40
Location1 ................................................................................................ 40
Location2 ................................................................................................ 41
Location3 ................................................................................................ 41
Location4 ................................................................................................ 42
Location5 ................................................................................................ 42
InstrumentTag ......................................................................................... 43
ExDesc .................................................................................................... 43
UserInt1 .................................................................................................. 44
Scan ........................................................................................................ 45
Shutdown ................................................................................................ 45
Exception and Compression ............................................................................. 45
Interface Configurations .......................................................................... 46
Recommended Tag Configurations ........................................................ 46
DataAccess, PtAccess ............................................................................ 47
Zero, Span .............................................................................................. 47
Chapter 7. Interface Status Tag Configuration ......................................................... 49
Chapter 8. Startup Command File ............................................................................. 51
Configuring the interface with ICU .................................................................... 51
FactoryTalk Historian to Historian Interface page .................................. 54
Configuring Interface Startup Files .................................................................... 64
Command-line Parameters ............................................................................... 64
General Interface Operation ................................................................... 65
History Recovery and Archive Data Collection ....................................... 70
Exception Data Collection ....................................................................... 71
Tag Attribute Override ............................................................................ 72
Server-Level Failover .............................................................................. 72
Sample Startup Configuration Files .................................................................. 73
Sample PItoPI.bat File ............................................................................ 73
Sample PItoPI.ini File ............................................................................. 74
Chapter 9. UniInt Failover Configuration .................................................................. 75
Introduction ........................................................................................................ 75
Quick Overview ....................................................................................... 76
Synchronization through a Shared File (Phase 2) ............................................ 77
iv
Configuring Synchronization through a Shared File (Phase 2) ......................... 78
Configuring UniInt Failover through a Shared File (Phase 2) ........................... 81
Start-Up Parameters ............................................................................... 81
Failover Control Points ........................................................................... 83
Historian Tags ......................................................................................... 84
Detailed Explanation of Synchronization through a Shared File (Phase 2) ...... 88
Steady State Operation .......................................................................... 89
Failover Configuration Using ICU ...................................................................... 91
Create the interface Instance with ICU ............................................................. 91
Configuring the UniInt Failover Startup Parameters with ICU .......................... 92
Creating the Failover State Digital State Set .................................................... 92
Using the ICU Utility to create Digital State Set ...................................... 93
Using the SMT 3 Utility to create Digital State Set ................................. 93
Creating the UniInt Failover Control and Failover State Tags (Phase 2) .......... 96
Chapter 10. Interface node Clock ............................................................................ 97
Chapter 11. Security ................................................................................................. 99
Tag and Node Security.................................................................................... 100
System Manager Responsibilities ................................................................... 100
Receiving System Manager .................................................................. 100
Source System Manager ...................................................................... 101
Sample Security Files...................................................................................... 101
Sample 1 ............................................................................................... 101
Sample 2 ............................................................................................... 101
Chapter 12. Starting / Stopping the interface ....................................................... 103
Starting Interface as a Service ........................................................................ 103
Stopping Interface Running as a Service ........................................................ 103
Chapter 13. Buffering ............................................................................................. 105
Which Buffering Application to Use ................................................................. 105
How Buffering Works....................................................................................... 106
Buffering and Historian Server Security .......................................................... 106
Enabling Buffering on an Interface Node with the ICU ................................... 107
Choose Buffer Type .............................................................................. 107
Buffering Settings.................................................................................. 108
Buffered Servers ................................................................................... 110
Installing Buffering as a Service ........................................................... 113
Chapter 14. Interface Diagnostics Configuration ................................................. 117
Scan Class Performance Points ..................................................................... 117
Performance Counters Points ......................................................................... 120
Performance Counters .......................................................................... 121
Performance Counters for both (_Total) and (Scan Class x) ............... 121
Performance Counters for (_Total) only ............................................... 122
Performance Counters for (Scan Class x) only .................................... 125
Interface Health Monitoring Points .................................................................. 126
I/O Rate Point .................................................................................................. 131
Interface Status Point ...................................................................................... 134
FactoryTalk Historian To Historian Interface User Guide v
Table of Contents
Appendix A. Error and Informational Messages ................................................... 137
Message Logs ................................................................................................. 137
Messages ........................................................................................................ 137
Interface Startup Messages ............................................................................ 137
Scan Summary ................................................................................................ 138
System Errors and Historian Errors ................................................................ 138
Historian to Historian Specific Error Messages ............................................... 138
UniInt Failover Specific Error Messages ......................................................... 139
Informational ......................................................................................... 139
Errors (Phase 1 & 2) ............................................................................. 139
Errors (Phase 2) .................................................................................... 141
Appendix B. PI SDK Options .................................................................................. 143
Appendix C. Terminology ...................................................................................... 145
Appendix D. Technical Support and Resources ................................................... 149
Technical Support ........................................................................................... 149
Knowledgebase .................................................................................... 149
Worldwide Support................................................................................ 149
Training Programs ................................................................................ 149
Consulting Services .............................................................................. 150
TechConnect Support ........................................................................... 150
Find the Version and Build Numbers .................................................... 150
View Computer Platform Information .................................................... 150
Appendix E. Revision History ......................................... Error! Bookmark not defined.
vi
Chapter 1. Introduction
The Rockwell FactoryTalk Historian to Historian interface copies tag data from one Historian
Server to another. Data is moved in one direction, meaning data is copied from the source to
the receiving Historian Server (also referred to as target Historian Server). The interface must
run on a Windows Intel-based operating system.
Note: The Rockwell FactoryTalk Historian to Historian interface functions and is
configured the same as the standard Rockwell Automation PItoPI interface, with the
exception that this interface can only connect to FT Historians.
Interface tags are created on the receiving Historian Server. Each interface tag is configured
to receive data for a unique source tag. Tags receive either archive or exception data updates
from the source tag. Exception data is data that has not yet been subjected to compression.
The type of data collection, exception or archive, is configured through scan class
assignment. By default, all tags belonging to the first scan class receive exception data. Tags
assigned to any other defined scan class receive archive data.
The interface supports history recovery. History recovery enables users to recover data for
time periods when the interface was not running or otherwise unable to collect data. The
history recovery period is configurable; the default is 8 hours. Users have the option of
performing time-range specific history recovery by specifying a start and end time. In this
configuration the interface collects data for the specified time period then exits.
Both source Historian Server-level failover and UniInt Phase 2 interface level failover are
supported. When running in source Historian Server-level failover mode, the interface obtains
data from one of two available source Historian Servers. The source Historian Servers must
have identical tag definitions and data streams for each interface source tag. This requirement
ensures the interface will obtain the same data regardless of which source server is active.
When running in UniInt Failover mode, two copies of the interface are connected to the
source Historian Server at the same time. When the primary interface stops collecting data,
the backup interface assumes the primary role and continues data collection. Source Historian
Server-level failover and UniInt Phase 2 interface level failover modes can be run
simultaneously. Failover maximizes interface data availability on the receiving Historian
Server(s).
Interface Limitations
The FactoryTalk Historian to Historian interface is not a true data replication tool. It does not
synchronize Historian Server data or perform data validation. It simply provides a method for
copying data from one Historian Server to another in an incremental, time forward manner.
There is no guarantee that an exact archive data match will exist between the source and
receiving Historian Servers. If the goal is to achieve data matching (replication) Rockwell
FactoryTalk Historian To Historian Interface User Guide 1
Introduction
Automation recommends using n-way buffering which is supported with PI API v1.6.x and
later. Please see the PI API installation manual for details.
The Historian Archive subsystem may temporarily queue data in memory prior to it being
committed to disk. This can lead to data gaps when using Historian to Historian for real-time
data collection with history recovery enabled. To avoid data gaps the recommended
configuration is to run in history recovery only mode without snapshot updates. Note that this
means current real-time data from the source Historian Server will not be available on the
target Historian Server.
The interface is a PI API based application. It does not currently support tag annotations,
which are only available through the PI SDK. This means it cannot be used to copy Batch
Database data between Historian Servers.
The interface is a single threaded process. This design increases performance dependencies
on the responsiveness of the source and receiving Historian Servers and dependencies on
network quality.
It is highly recommended that users use tools such as Rockwell Automation‟s Performance
Monitor interface and Historian Ping interface to monitor these interface dependencies. These
interfaces are distributed by default with the latest Historian Server setup kit. This
information will be invaluable for troubleshooting Historian to Historian interface issues if
they should arise. Using these tools to monitor system health is also part of Rockwell
Automation‟s Best Practices Recommendations for FactoryTalk Historian System Mangers.
Interface Requirements
PItoPI requires the following software versions:
Windows Intel-based operating system
PI API version 1.6.1.5 or greater, which is distributed with the PI SDK installation
kit.
TCP/IP connections are needed to both receiving and source Historian Servers. This
interface also operates using RAS to connect over dial-up or ISDN connections. Dialup connections of 9600 baud have been used successfully.
To configure Phase 2 failover using the ICU you must use ICU 1.4.6.0 or later.
Note: The value of [PIHOME] variable for the 32-bit interface will depend on whether the
interface is being installed on a 32-bit operating system (C:\Program
Files\Rockwell Software\FactoryTalk Historian\PIPC) or a 64-bit operating
system (C:\Program Files (x86)\PIPC).
The value of [PIHOME64] variable for a 64-bit interface will be C:\Program Files\Rockwell
Software\FactoryTalk Historian\PIPC on the 64-bit Operating system.
In this documentation [PIHOME] will be used to represent the value for either [PIHOME]
or [PIHOME64]. The value of [PIHOME] is the directory which is the common location for
Historian client applications.
2
Platforms
32-bit application
64-bit application
Windows XP
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
Windows 2003 Server
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
Windows 7
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
Windows 2008
32-bit OS
Yes
No
Windows 2008 R2
64-bit OS
Yes (Emulation Mode)
No
Windows 7
32-bit OS
Yes
No
64-bit OS
Yes (Emulation Mode)
No
Feature
Support
Interface Part Number
Historian-IN-RW-FTPI-NTI
* Auto Creates Historian Points
APS Connector
Point Builder Utility
No
ICU Control
Yes
Historian Point Types
Historian 3: Float16 / Float32 / Float64 / Int16 /
Int32 / Digital / String / Blob
Historian 2: R / I / D
Sub-second Timestamps
Yes
Sub-second Scan Classes
Yes
Automatically Incorporates
Historian Point Attribute Changes
Yes
Exception Reporting
Yes
Outputs from Historian
No
Reference Manuals
Rockwell Automation
Historian Server manuals
PI API Installation manual
UniInt Interface User Manual
Historian Interface Status
Supported Operating Systems
The interface is designed to run on the above mentioned Microsoft Windows operating
systems and their associated service packs.
Please contact Rockwell Automation Technical Support for more information.
Supported Features
FactoryTalk Historian To Historian Interface User Guide 3
Introduction
Feature
Support
Inputs to Historian: Scan-based /
Unsolicited / Event Tags
Scan-based Only
* Supports Questionable Bit
No
Supports Multi-character PointSource
Yes
Maximum Point Count
Unlimited
* Uses PI SDK
No
PINet String Support
No
* Source of Timestamps
Source Historian Server
History Recovery
Yes
UniInt-based
* Disconnected Startup
* SetDeviceStatus
Yes
No
Yes
Failover
Source Historian Server-Level
UniInt Phase 2 Interface Level (Warm)
* Vendor Software Required on
Historian interface node / PINet Node
No
Vendor Software Required on Foreign
Device
No
Vendor Hardware Required
No
Additional Historian Software Included
with Interface
No
Device Point Types
Real, Integer and Digital.
Serial-Based Interface
No
* See available paragraphs below for further explanation.
APS Connector
The PItoPI APS Connector (PItoPI_APS) is a specific module that communicates with the
Receiving and Source Host FactoryTalk Historian SE‟s, gets tag attribute updates from the
Source Host FactoryTalk Historian System, and locates new and deleted points on the Source
Host FactoryTalk Historian System. The PItoPI APS Connector and its attendant routines are
called with each synchronization scan.
Note: The PItoPI APS Connector contains a separate implementation of the
procedure to identify the source point for an interface point. If an interface instance is
registered with APS, confirm that the PItoPI APS Connector version implements the
same procedure as the interface, which is required to ensure that the PItoPI APS
Connector synchronizes with the same source point as the interface.
Supports Questionable Bit
The interface will copy questionable bit data for a give source point from one PI3 server to
another. However the interface itself does not make this a configurable parameter.
Uses PI SDK
The PI SDK and the PI API are bundled together and must be installed on each interface
node. This Interface does not specifically make PI SDK calls.
4
Maximum Point Count
While the interface does not have a hard-coded point count limit, there are performance
dependencies that can effectively limit point count. The interface is a single-threaded process.
This design exposes performance dependencies on Historian Server responsiveness and
network quality. For example a high latency network connection will result in a significant
decrease in data transfer rate over a network connection without high latency.
It is highly recommended that users use tools such as Rockwell Automation‟s Performance
Monitor interface and Historian Ping interface to monitor these interface dependencies. These
interfaces are distributed by default with the latest Historian Server setup kit. This
information will be invaluable for troubleshooting Historian to Historian interface issues if
they should arise. Using these tools to monitor system health is also part of Rockwell
Automation‟s Best Practices Recommendations for FactoryTalk Historian System Mangers.
Source of Timestamps
The source Historian Server provides a timestamp for each data event. Timestamps are
automatically adjusted to account for time zone differences if both source and receiving
Historian Servers are Historian 3. Time zone adjustment is optional if either Historian Server
is Historian 2.
The interface can also adjust timestamps for clock drift. Clock drift is the time offset between
Historian Servers after accounting for time zone differences. An offset of 30 minutes or less
is considered clock drift. Adjusting for clock drift means the time offset is added to the source
timestamp adjusting it to receiving Historian Server time.
Timestamp adjustment is configured on a tag-by-tag basis through the Location2 tag
attribute. Note that all computers (interface nodes, source and receiving Historian Servers)
must have the correct system time for their configured time zone.
History Recovery
History recovery enables users to recover archive data for time periods when the interface
was not running or otherwise unable to collect data. History recovery is performed on startup,
after restoring a lost Historian Server connection and after a disruption in exception data
collection. In addition, when a new point is added to the interface, history recovery is
performed on that point. The history recovery period is configurable. The default is to recover
data for the previous 8 hours. History recovery is disabled by setting the time period to 0.
Time range-specific history recovery can be performed by passing a start and end time. When
run in this configuration the interface collects data for the specified time range then exits. It
should be noted that the start and end time will be relative to the node where the interface
runs. This is important if the source Historian Server is in a different time zone than the
machine where the interface is running.
UniInt-based
UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an
Rockwell Automation-developed template used by developers, and is integrated into many
interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set
and behavior across as many of Rockwell Automation‟s interfaces as possible. It also allows
for the very rapid development of new interfaces. In any UniInt-based interface, the interface
uses some of the UniInt-supplied configuration parameters and some interface-specific
parameters. UniInt is constantly being upgraded with new options and features.
The UniInt Interface User Manual is a supplement to this manual.
FactoryTalk Historian To Historian Interface User Guide 5
Introduction
SetDeviceStatus
The Historian to Historian Interface is built with UniInt 4.4.4.0. New functionality has been
added to support health tags. The Health tag with the point attribute ExDesc =
[UI_DEVSTAT] represents the status of the source device. The following events can be
written into this tag:
“1 | Starting” - the interface is starting.
“Good” - the interface is properly communicating and reading data from the server.
The following event represents a failure to communicate with the server:
o "3 | 1 device(s) in error | Network communication error to source Historian
Server"
o "3 | 1 device(s) in error | Unable to get archive data from source Historian
Server"
o "3 | 1 device(s) in error | Unable to get snapshot data from source Historian
Server"
o "3 | 1 device(s) in error | Unable to write data to receiving Historian Server"
o "3 | 1 device(s) in error | Unable to obtain current data with source Historian
Server failover enabled."
“4 | Intf Shutdown” - the interface is stopped.
Refer to the UniInt Interface User Manual for more information on how to configure health
points.
Failover
Source Historian Server-Level Failover Support
Source Historian Server-level failover maximizes interface data availability on the receiving
Historian Server(s). It enables the interface to obtain data from one of two source Historian
Servers. Each source server must have identical tag definitions and data streams for interface
source points. Source Historian Server failover is not supported for Historian 2.
The interface will initiate failover if the active source data becomes stale or is not available
due to network issues. The Historian Interface Status utility is required for each source
Historian Server to monitor data quality. The interface uses the utility status tag output to
verify source data is current and has not become stale.
UniInt Interface Failover Support
UniInt Phase 2 Failover provides support for cold, warm, or hot failover configurations. The
Phase 2 hot failover results in a no data loss solution for bi-directional data transfer between
the Historian Server and the Data Source given a single point of failure in the system
architecture similar to Phase 1. However, in warm and cold failover configurations, you can
expect a small period of data loss during a single point of failure transition. This failover
solution requires that two copies of the interface be installed on different interface nodes
collecting data simultaneously from a single data source. Phase 2 Failover requires each
interface have access to a shared data file. Failover operation is automatic and operates with
no user interaction. Each interface participating in failover has the ability to monitor and
determine liveliness and failover status. To assist in administering system operations, the
ability to manually trigger failover to a desired interface is also supported by the failover
scheme.
6
The failover scheme is described in detail in the UniInt Interface User Manual, which is a
supplement to this manual. Details for configuring this Interface to use failover are described
in the UniInt Failover Configuration section of this manual.
Device Point Types
Real, Integer and Digital.
Diagram of Hardware Connection
The following diagrams illustrate the three basic hardware configurations for PItoPI: the
interface runs on the source Historian Server, the interface runs on the receiving Historian
Server or the interface runs on a separate interface node. The interface must run on a
Windows Intel-based operating system.
Figure 1: Configuration 1 PItoPI runs on the source Historian Server “pushing” data to the
receiving Historian Server.
FactoryTalk Historian To Historian Interface User Guide 7
Introduction
Figure 2: Configuration 2 PItoPI runs on the receiving Historian Server “pulling” data from
the source Historian Server.
8
Figure 3: Configuration 3 PItoPI runs on a separate interface node.
FactoryTalk Historian To Historian Interface User Guide 9
Chapter 2. Principles of Operation
The FactoryTalk Historian to Historian interface copies tag data from one Historian Server to
another. It consists of a single executable and startup configuration file. No specific tag limit
exists for the interface. However, data throughput (events/second) can be limited by network
quality and/or system resources on the source and receiving Historian Servers. Users can
configure the interface to copy exception (snapshot) or archive data. Although it is possible
for one copy of the interface to do both, it is highly recommended that separate copies are
used for this purpose to ensure a high level of performance.
Interface Startup
On startup, the interface reads its configuration file for site-specific operating parameters.
This file contains required and optional configuration information, such as source and
receiving Historian Server, data update rates, and history recovery settings. Next the interface
establishes a connection to each Historian Server and initializes its tag lists.
Each client connection to a Historian Server is associated with a specific PI user. This PI user
determines what permissions are granted to the client. The source Historian Server must grant
the interface permission to read tag attributes and data for interface source tags. On the
receiving Historian Server the interface requires read access for tag attributes and read and
write data access for its tag list. See the section Tag and Node Security for additional
information.
As the interface initializes its tag lists, tags are grouped internally by scan class assignment.
Each interface tag must be configured for a unique source tag. If an invalid tag configuration
is detected, the tag is either rejected or added to the tag list and marked in error. In either case
a message will be logged with specific information about the error. The interface outputs
messages to pipc.log, which can be found in the local \pipc\dat directory.
After the interface is finished building its tag lists it calculates the time offset between
Historian Servers. The offset is updated every 2 minutes and used for data timestamp
adjustments, if configured, and to timestamp interface status events. It is required that each
participating node has the correct system time for its configured time zone. At this point the
interface is ready to begin data collection.
FactoryTalk Historian To Historian Interface User Guide 11
Principles of Operation
Interface parameters
Search order for attribute containing source point tag name or ID
/tn
/tnex
/ptid
No
No
No
1. Non-empty InstrumentTag attribute is source point tag name.
2. ExDesc attribute that contains STAG= specifies source point tag.
3. UserInt1 attribute greater than 0 contains source point ID.
(Point rejected if source Historian Server-level failover configured.)
4. Tag of the interface point is also source point tag name.
No
No
Yes
UserInt1 attribute contains source point ID.
(Illegal configuration if source Historian Server -level failover is
configured.)
No
Yes
No
1. ExDesc attribute that contains STAG= specifies source point tag.
2. Tag of the interface point is also source point tag name.
No
Yes
Yes
Tag of the interface point is also source point tag name.
Yes
N/A
N/A
How FactoryTalk Historian to Historian Finds Source Points
When the FactoryTalk Historian to Historian Interface loads a point, the interface must
identify the source point from which data will be collected. In other parts of this manual, this
process is referred to as mapping the interface point to a source point.
The interface uses four receiving point attributes as possible links to the source point:
InstrumentTag, ExDesc, UserInt1, and Tag. However, the FactoryTalk Historian to
Historian Interface /tn, /tnex, and /ptid parameters exclude one or more of these
attributes from mapping to the source point. For most interface instances, none of these
parameters are used. The following table summarizes the effect of these parameters on the
search for either source point tag name or point ID. The actual implementation of the search
is described below the table.
The interface performs the following steps to find the source point:
1. If no /tn parameter and no /tnex parameter and no /ptid parameter and the
InstrumentTag attribute is not a zero-length string, the InstrumentTag value
contains the source tag name and the search ends. Otherwise, proceed to step 2.
2. If no /tn parameter and no /ptid parameter and the ExDesc attribute begins with
case-insensitive “STAG” followed by zero or more spaces followed by “=”, the
source tag name is extracted from the remainder of the ExDesc value (as described
in the following paragraph) and the search ends. Otherwise, proceed to step 3.
To extract the source tag name, the interface ignores any spaces following the “=”. If
the next character is not a double quotation mark ("), it is the first character of the
source tag name which extends to the first comma or to the end of the ExDesc
attribute. If the first non-space following the “=” is a double quotation mark, the
source tag name begins with the following character and extends to the first double
quotation mark or to the end of the ExDesc attribute. The interface extracts the
source tag name from ExDesc and the search ends.
3. If no /tn parameter and no /tnex parameter and either the UserInt1 attribute is
greater than zero or the /ptid parameter is present, the UserInt1 attribute is the
12
source point ID and the search ends. Otherwise, proceed to the step 4. If the search
ends in this step and either the UserInt1 attribute is not greater than zero or the
interface is configured for source Historian Server-level failover, the interface rejects
the point.
4. The source point tag name is the same as the receiving tag name.
The search for the source point ends with either a source tag name or source point ID. If the
source tag name or point ID does not exist, the interface puts the point into an error state and
logs a message.
Note: The PItoPI APS Connector contains a separate implementation of the search
for source point tag name or ID. If an interface instance is registered with APS,
confirm that the PItoPI APS Connector version implements the same search
procedure as the interface, which is required to ensure that the PItoPI APS
Connector synchronizes with the same source point as the interface. If the latest
release of the PItoPI APS Connector is older than this version of the FactoryTalk
Historian to Historian interface, compare the procedure described in this section with
the “How PItoPI and PItoPI_APS Find Source Points” section in the Historian to
Historian TCP/IP Interface AutoPointSync Connector user manual.
Data Collection
There are two modes of data collection, history recovery and scanning for updates. History
recovery enables users to recover archive data for time periods when the interface was not
running or otherwise unable to collect data. After performing history recovery, the interface
begins scanning for updates. When the interface is scanning for updates each tag recei
Historian to Historian TCP/IP Interface AutoPointSync Connector ves an incremental copy of
either archive or exception data from its configured source tag.
A tag configured for exception data receives a copy of its source tag‟s current value updates.
A tag‟s current value is also referred to as its snapshot value. A snapshot value is a data event
that has passed the first level of data filtering, the exception test. Every Historian Server
maintains a snapshot table that contains the current value for each tag in its database. When a
new value passes exception filtering, the snapshot table is updated. The existing snapshot
value is then subjected to the compression test. The compression test determines whether or
not a snapshot value is archived. If a value passes compression filtering, it becomes part of
the archive data collection.
Tags are configured for archive or exception data collection through scan class assignment.
Scan classes are update rates that users define in the interface startup configuration file. When
a scan is executed the interface performs an incremental copy of data for each tag in its scan
list. By default, all tags assigned to the first scan class receive exception data. Tags assigned
to any other scan class receive archive data.
Note: Interface performance is maximized when a separate copy of the interface is
used for archive and exception data collection.
All data collected by the interface has already passed exception filtering on the source
Historian Server. Any additional exception filtering can only lead to a data mismatch between
Historian Servers. Additionally we recommend applying source tag compression deviation
settings to interface tags. See the section Exception and Compression for additional
information.
FactoryTalk Historian To Historian Interface User Guide 13
Principles of Operation
In general the interface can sustain higher data rates (events/second) when configured for
exception data collection. Exception updates are queued in memory on the source Historian
Server. This is not the case for archive updates. Only the most recently accessed archive data
is stored in memory, specifically the archive data cache. When the interface requests archive
data it is likely a certain percentage is read from disk. Disk reads require more computer
resources than reading from memory. As the interface data rate increases, the source
Historian Server will work harder if the interface is requesting archive versus exception data.
History Recovery
History recovery is executed after each of the following events:
On interface startup.
After restoring a lost Historian Server connection.
Update overflow error recovery.
For each new point added to the interface.
History recovery is configured through interface startup parameters. Users can specify the
recovery period, time increments within the total recovery period, a pause time between
increments, and the maximum number of archive events returned per data request. These
parameters enable users to manage the performance impact on the source and receiving
Historian Servers by throttling the data collection rate.
The starting point for history recovery is set on a tag-by-tag basis. If the current value for a
tag is more recent than the starting point of the recovery period, history recovery will begin at
the tag‟s current value. This prevents data overlap, streamlines data retrieval, and prevents
out-of-order data. There is one exception: Pt Created is the value given to a tag when it is
created. If the current value of an interface tag is Pt Created, the interface performs history
recovery for the total recovery period.
History recovery is performed independently for each scan class. The interface periodically
prints a message to indicate completion status. Every minute the interface calculates percent
completion. A message will be printed for each 10% completion increment or every 5
minutes, whichever comes first.
If a scan class is configured for exception data collection, the interface transitions from
archive to exception data on the last history recovery increment. As the interface cycles
through its tag list, each tag is added to the exception update list after obtaining its last
recovery increment. By default the interface breaks from history recovery to collect exception
updates every 5 seconds. This time interval is configurable through the /rh_qcheck startup
parameter. As it nears the end of its tag list, more tags are in the update list and the time to
collect exception updates increases. This extra overhead can significantly increase the time
for complete history recovery.
The default behavior is for history recovery data to bypass compression on the receiving
Historian Server. Source data is written to the receiving archive in one of three modes;
append, replace or no replace. This is configured on a tag-by-tag basis. If the /dc interface
startup parameter is specified, this data is subjected to compression. Historian 2 and Historian
3.2 servers will always apply compression to interface data. In this case the data write mode
is effectively disabled.
Time-range history recovery is configured through the interface startup configuration file.
When enabled, the interface starts up, recovers archive data for the specified start and end
14
time then exits. The times specified are relative to the machine where the interface runs. This
is important if the source Historian Server is in a different time zone than the machine where
the interface runs. Note that backfilling data may require additional server preparations on the
receiving node. For example, there may not be enough space in the target (non-primary)
archive for the recovery data, or non-primary archives may not have space allocated for
newly created tags. See the Historian Server System Management Guide for information on
backfilling data.
Exception Data Collection
Tags assigned to the first scan class receive exception data. An exception is a current value
update (snapshot value). On startup each source tag is registered with the update manager on
the source FactoryTalk Historian System. The update manager then collects snapshot updates
for each registered tag. This data is queued in memory. When the interface executes a scan it
requests and processes these events until the queue is empty. Data update latency is
minimized by configuring a high frequency scan rate for the exception scan class. Exception
and compression should be configured carefully for the interface to avoid data mismatches
between Historian Servers. See the section Exception and Compression for additional
information.
Maximizing Data Throughput
Interface performance is maximized when a separate copy of the interface is used for archive
and exception data collection.
The number of events returned per update request to the source Historian Server is
configurable through the interface startup file. The default is for up to 10,000 exception
events returned per update request. This list of exceptions is given to the interface in time
sequence, oldest to newest. The interface processes the list one event at a time. These events
are temporarily queued by the interface. Only one update is queued per tag at any given time.
Whenever a second event for any one tag is processed within the exception update list, the
interface must first flush its queue, writing this data to the receiving server. This behavior is
required for exception data filtering. As a result, the interface will make many more calls
writing data to the receiving Historian Server than retrieving data from the source.
Note: Whenever possible, users should run the interface on the receiving Historian
Server to minimize the effect of network latency on data throughput.
Network latency will have a significant effect on data throughput. Interface testing over a
WAN connection with 200ms latency showed throughput was reduced by 2/3 when the
interface ran on the source versus the receiving Historian Server. When run on the receiving
Historian Server, the interface was able to sustain 1800 events/second. This was reduced to
600 events/second when the interface ran on the source Historian Server. Testing with a
latency of <1 ms, throughput was not affected. The interface maintained 11,000
events/second when run on the source and receiving Historian Server.
FactoryTalk Historian To Historian Interface User Guide 15
Principles of Operation
Archive Data Collection
By default, the first scan class is used for exception data collection. Tags configured for any
other scan class will receive archive data. However, exception data collection can be disabled
entirely by specifying the /hronly interface startup switch. When specified, all scan classes
update with archive data.
When a scan is executed, each tag receives an incremental copy of data. An archive update
begins at the interface tag‟s current value. The source server returns all source tag data
including its current snapshot value. Users have the option of including the current snapshot
value with each scan update. This is configured through the Location3 tag attribute. The
snapshot value is not part of the archive data collection. Including the snapshot value can lead
to a data mismatch between Historian Servers. In this case data compression must be enabled
by specifying the /dc startup switch. If this is not done and a tag is configured to include the
snapshot, a snapshot value will be archived on each scan. This will result in the interface tag
having more archive values than its source.
The default behavior is for archive data collected by the interface to bypass compression on
the receiving Historian Server if its version is PI 3.3 or later. Source data is written to the
receiving archive in one of three modes; append, replace or no replace. This is configured on
a tag by tag basis through the Location5 tag attribute. If the /dc interface startup parameter
is specified, this data is subjected to compression which effectively disables the archive write
mode. Historian 2 and Historian 3.2 servers will always apply compression to interface data.
In this case compression must be managed through interface tag configurations. See the
section Exception and Compression for additional information.
Performance Considerations
Load Distribution
Archive data collection can have a significant impact on Historian Server performance. The
source server will be providing the interface with outgoing data for its tag list in addition to
the normal incoming data rate. This may significantly increase system resource usage. This
performance impact can be minimized by distributing tags among multiple scan classes.
For example, a user configures the interface for 10,000 tags. Instead of assigning these tags to
a single scan class, multiple scan classes are used. The user defines ten scan classes and
assigns 1,000 tags to each one. A 10-minute update rate is chosen with each scan class offset
by one minute. The result is each scan executes one minute after the next distributing the
10,000 tag updates into 10 requests of 1,000 tags each. When compared to having all tags
belong to one scan class, this configuration is a more efficient use of server resources.
Scan Rates
The scan class update frequency can be chosen to minimize the performance impact on the
source Historian Server. Recent archive data is cached in Historian Server memory for each
tag. Historian Server resource usage is minimized when interface updates are obtained by
reading cached data. If the data does not reside in memory it is read from disk. Disk reads
require more hardware resources than a memory read. When possible a scan frequency
should be chosen that minimizes disk access while maximizing the time between scans.
A Historian 3.4 server allocates space for 4 data events per point in the archive read memory
cache. This cache size is a configurable parameter. When the interface performs history
16
Receiving Tag Point Type
Source
Tag Point
Type
Float
16/32/64
Int16/32
Digital
String
Float 16/32/64
Yes
Yes
No
recovery nearly all data is obtained from disk reads. When the interface transitions to
scanning for updates, disk reads should decrease as recent data is obtained from the archive
memory cache. The percentage of data obtained via disk reads versus memory can be
managed through the scan frequency. Increasing the scan rate should increase the percentage
read from memory. Vice versa, decreasing the scan rate increases the percentages of data
obtained from disk reads. With some trial and error users can determine a scan rate that
maximizes the time between scans while minimizing archive disk reads. For Historian 3
source servers, use the Historian Performance Monitor interface to access archive
cache versus disk read data counters. Historian 2 source servers will want to monitor disk
versus cache read ratios.
Data Timestamps
The source Historian Server provides a timestamp for each data event. These timestamps may
be adjusted to account for time zone differences and clock drift between Historian Servers. It
is required that each Historian Server have the correct system time for the configured time
zone.
Timestamps are automatically adjusted for time zone differences when both source and
receiving servers are PI3. PI3 uses Universal Coordinated Time (UTC) to timestamp data.
UTC is based on seconds since Jan.1, 1970 in Greenwich Mean Time. Each UTC time stamp
contains a time offset from Greenwich Mean Time that represents the local time zone setting.
If source and/or receiving Historian Server is PI2, users have the option of adjusting for time
zone differences. PI2 uses local time. Local time is seconds since Jan. 1, 1970 in the local
time zone. PI2 data timestamps do not include a time zone offset. For example, viewing data
from a PI2 server in a time zone two hours behind your local time will appear to be two hours
old. PI3 data includes time zone information that allows for automatic adjustment to local
time.
The interface can also adjust for clock drift between Historian Servers. Clock drift is the time
offset between Historian Servers after accounting for time zone differences. An offset of 30
minutes or less is considered clock drift. When configured to do so, the time offset is added to
the timestamp provided by the source Historian Server adjusting it to receiving Historian
Server time.
Timestamp adjustment is configured on a tag-by-tag basis through the Location2 tag
attribute. Note that all computers (interface node, source and receiving Historian Server) must
have the correct system time for the configured time zone.
Data Type Conversions
The following table displays supported data type conversions between source and receiving
Historian tags.
FactoryTalk Historian To Historian Interface User Guide 17
Principles of Operation
Int16/32
Yes Yes
No
Digital
No
Yes No
String
No
No
Yes
Interface Status Events
The FactoryTalk Historian to Historian interface may update a tag to indicate a specific status
event. These status events represent data that is generated by the interface and therefore will
not exist for the source tag.
There are three specific status events generated by the interface:
IO Timeout status events are triggered when the interface loses a Historian Server
connection. This information informs users that current data is not being collected.
An event is written to indicate the time of disconnection and another event is written
to indicate the time of reconnection.
Access Denied status events are written whenever the interface is denied access to a
tag‟s data or attribute information.
Intf Shut status events are enabled through /stopstat startup parameter. When
enabled an event is written when the interface is stopped and again on startup. These
events tell users no data is being collected because the interface is not running. See a
more detailed description in the “Command-line Parameters” section.
To prevent a data mismatch between Historian Servers these status events should be disabled.
If enabled these events create a data gap that will not be filled through history recovery.
Each tag receives an „IO Timeout‟ event at the time of Historian Server disconnection and a
second event at reconnection. Likewise, when the interface is stopped and started a
„Shutdown‟ event is written to each tag. History recovery begins either at the start of the
recovery period or a tag‟s current value, whichever is more recent. The status events are
updated prior to performing history recovery, making them the starting point of the recovery
period for each tag. This results in a gap in data for a time period that might otherwise be
recovered.
Interface status events are configured on a tag-by-tag basis through the Location3 tag
attribute. Interface shutdown events are enabled through the interface startup script. By
default shutdown events are not written by the interface.
Adding, Removing and Editing Tags
Tag definitions can be modified while the interface is running. The interface periodically
checks with the receiving Historian Server for tag configuration updates. These updates
include adding, editing, and removing tags. During normal operation the interface checks for
updates every two minutes. It will only process up to 25 tag updates on any given update.
This is to prevent the processing of tag updates from delaying data collection. If there are
more than 25 tag updates, the interface will check again every 30 seconds until all updates
have been processed. Processing tag updates is a low priority for the interface. If a large
18
number of tag edits are made, a user may choose to restart the interface. Restarting the
interface will force it to process all edits by rebuilding its tag list.
Error Handling
When the interface encounters an error, it will print a message to the log file. If the error is
tag-specific, the error message will include the tag name along with the specific error code.
The tag is then marked by the interface as being in error and removed from the update list.
The interface will attempt to clear tags in error every 10 minutes. It does this by trying to read
a value from the source tag and then update the interface tag with that value. If this is
successful, the tag is added back to its assigned scan class for data collection. Otherwise, it
remains in error until the next attempt to clear it.
If an error is not tag-specific, the interface verifies server connectivity. Typically system
errors are a result of network upsets. When a system error is encountered, the interface
verifies Historian Server communication and attempts to continue collecting data.
Source Historian Server-Level Failover
Source Historian Server-level failover maximizes interface data availability on the receiving
Historian Server. It requires that two Historian source servers are available that have identical
tag definitions and data streams for interface points. This requirement ensures the interface
will obtain the same data regardless of which source server is active. Source Historian Serverlevel failover is not supported for Historian 2.
Failover is enabled by specifying a primary and secondary source server in the interface
startup file. On startup the interface attempts to establish a connection to each source server
then load and initialize its tag list. Data collection begins from the primary source server
making it the active node while the secondary source server assumes the standby role.
However, if one of the source servers is unavailable on startup, the other server is designated
the active source regardless of primary or secondary configuration.
Note: Source tag mapping by point ID is not compatible with server-level failover.
This is because there is no guarantee of a point ID match between two source
Historian Servers unless they are part of a Historian Collective.
Fault Conditions
There are two conditions that will cause the interface to initiate failover: a communication
failure or detection of stale data.
Communication Failure
The first failover condition is when the interface loses communication to the active Historian
source server. This may be the result of a temporary network upset, shutdown of the active
source server, hardware failure, etc. The interface has no way of identifying what causes the
disconnection. A disconnection means the interface did not receive a response from the active
source within the timeout period. The interface may initiate a short wait then attempt to
reconnect to the active source before attempting to failover. The timeout period, pause
FactoryTalk Historian To Historian Interface User Guide 19
Principles of Operation
between reconnection, and number of reconnection attempts are all user configurable
parameters.
Note: the default network timeout period is 60 seconds. This is not an interface
configuration parameter. This is configured through the PI API configuration file,
pilogin.ini. Please refer to the PI API Users Manual for information on adjusting the
default timeout period.
Detection of Stale Data
The second failover condition is stale source data. The Historian Interface Status Utility is
required on each source server to track data quality. This utility is a separate program that
monitors updates to a specified watchdog tag. The utility updates a status tag to indicate
whether or not the watchdog tag is being updated. The interface monitors this status tag as an
indicator that source data is current. When configuring the Interface Status Utility users will
want to select a watchdog tag that receives reliable high frequency updates.
Whenever possible the interface is connected to a source Historian Server that is actively
receiving data. If this is not possible, the interface enters a loop where it waits for the first
available source Historian Server receiving data.
Note: The Historian Interface Status Utility is not included as part of the interface
installation. It is available for downloaded on our website;
http://support.rockwellautomation.com
UniInt Failover
This interface supports UniInt Phase 2 failover with warm failover configuration. Refer to
section UniInt Failover Configuration of this document for configuring the interface for
failover.
Interface Status Tags
The interface has the optional functionality of outputting status data to a digital tag. There are
two optional status tags that are mutually exclusive. These are digital tags that are created on
the receiving Historian Server. These tags are useful for tracking performance and assisting
with troubleshooting.
Internal State Status
The interface updates the internal state tag to indicate when it executes specific functions.
Specifically, the status will indicate whether the interface is in startup, performing history
recovery, scanning for data, experiencing network communication errors, denied data or point
access (security permissions) or performing shutdown operations. This functionality is
enabled by specifying an internal state status tag in the interface startup script.
20
Failover Status
When configured for server-level failover users can specify a status tag. The interface will
update this tag to indicate whether the primary or secondary source server is active. It will
also update this tag when it is in the process of failing over (no active source) or experiencing
network communication errors.
Deployment Scenarios
There are two typical FactoryTalk Historian to Historian interface applications. One is to
isolate users from the source Historian Server. This may be for security requirements, load
distribution, database centralization or to resolve remote access issues. In this scenario users
will want to configure the interface for exception data collection to provide real-time updates
to end users.
The other application is to maintain a copy of archive data on a secondary Historian Server.
For example, in this scenario the receiving Historian Server maybe a backup of the source
Historian Server. This is achieved by running the interface in archive data collection mode
with tag attribute overrides in the startup configuration file. The tag attribute overrides enable
users to configure interface data collection without configuring receiving tags specifically for
PItoPI. This strategy allows receiving tags to be configured for their native interfaces and
eliminates the need for mass tag editing prior to bringing the backup server online, reducing
down time.
Historian to Historian within a Historian Collective
PItoPI can be used to distribute data within a collective. The primary method for data
distribution within a collective is n-way data buffering from the data source. N-way data
buffering provides the best performance and is the most efficient method for data distribution.
However due to system architecture and security restrictions this may not always be possible.
FactoryTalk Historian To Historian Interface User Guide 21
Principles of Operation
Historian to Historian is used to transfer data within a collective when the data cannot be sent
directly from the interface node. The following section describes typical configuration and
deployment scenarios when running Historian to Historian within a collective.
Tag Attribute Override Parameters
The interface supports tag attribute override parameters. These startup parameters must be
used when running the interface within a collective. Tag attribute override parameters enable
the interface to collect data for tags that are not actually configured for the Historian to
Historian interface.
Each member of a collective is required to have identical Historian point database definitions.
Using Historian to Historian within a collective will result in the need to have a tag
configured for Historian to Historian on one collective member but these same tags must also
be configured for the native data source interface on a different collective member.
For example, consider a secondary Historian Collective node that sits behind a firewall. The
primary Historian Collective node receives data directly from a Historian OPC and a
Historian ModBus interface node. The points on the secondary Historian Collective node are
defined exactly as they are on the primary Historian Collective node. This means these points
are either configured for the Historian OPC or the Historian ModBus interface
22
Example Architecture for Historian to Historian within a Historian Collective
Tag attribute override parameters allow users to pass global settings that enable the interface
to identify and build its tag list without requiring the tags to be defined explicitly for
Historian to Historian. A detailed description of the tag attribute override parameters can be
found in section Startup Command File section of this manual.
Firewall Considerations
When a firewall separates the source and receiving Historian Servers for the Historian to
Historian interface users may want to run the interface outside of the firewall network. This
configuration requires that port 5450 be opened for incoming connections to the Historian
Server through the firewall. All outgoing connections from the Historian Server will require
that port 1024+ and greater are opened. Additional configuration information for
implementing a firewall can be found in our knowledge base (KB) article #2820OSI8 which
is available on our TechSupport website (http://support.rockwellautomation.com).
For the best security posture, Historian to Historian should push data out from the most
sensitive Historian Server. Enable buffering to eliminate the latency bottleneck.
FactoryTalk Historian To Historian Interface User Guide 23
Principles of Operation
Historian to Historian between Historian Collectives
The following diagram architecture depicts a typical deployment of Historian to Historian for
aggregating data between two Historian Collectives.
Limitations
The following limitations apply to the Historian to Historian interface when aggregating data
between two collectives.
Historian Collective Support
The Historian to Historian interface is not collective aware. While multiple Historian Servers
will compose a collective, the interface will only know about the Historian Servers specified
in its startup file. This means on startup both receiving and source Historian Server(s)
specified in the interface startup file must be available in order for the interface to initialize
its point list.
24
Loading...