Rockwell Automation FactoryTalk Historian SE 3.0 H2H Interface User Guide - Manual (Page 22)

Principles of Operation
16
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