Using the Server-to-Server Collector

Important: You do not have the latest version of Historian! You are missing out on the newest capabilities and enhanced security. For information on all the latest features, see the Historian product page. For more information on upgrades, contact your GE Digital sales agent or e-mail GE Digital Sales Support. For the most up-to-date documentation, go here.

Configuring Data Collection

When administrating the destination computer using the Historian Administrator, you can browse and add tags that exist on the source computer using the same steps as used with other data collectors. You can view the status and properties of the Server-to-Server Collector on the configured destination computer as well.
Note: The Server-to-Server collector requires licensing on the destination machine. It is similar to any other collector. The destination machine will have the Server to Server listed in its collector list.

There are four basic steps to configuring data collection using the Server-to-Server Collector.

  1. Start the Server-to-Server Collector.
  2. Create the destination tag.
  3. Assign a trigger to the formula.
  4. Build the formula.

Server-to-Server Naming Conventions

When you add a Server-to-Server Collector during the Historian install, you specify a destination. Historian uses the following naming convention for the Server-to-Server Collector interface name:
SOURCE_To_DESTINATION
where SOURCE is the name of the source archiver and DESTINATION is the name of the destination archiver.
When the collector is run on a computer other than the source or destination, Historian uses the following naming convention:
SOURCE_To_DESTINATION_Via_REMOTEMACHINENAME
where SOURCE is the name of the source computer, DESTINATION is the name of the destination computer, and REMOTEMACHINENAME is the name of the remote computer where the collector is running.

After you install Historian, you can view the Server-to-Server Collectors in the main screen of the Historian Administrator. You can quickly identify a collector in the list as a Server-to-Server Collector because it uses the naming convention discussed in this section. If you add another collector through the Historian Administrator after the install, it is recommended that you use these naming conventions.

Starting Server-to-Server Collector

The Server-to-Server Collector should automatically start when you start your system. If the Server-to-Server Collector is not running, refer to Data Collectors > Configuring a Data Collector for Automatic Startup.

Optionally, you can use the silent install feature, described in Getting Started Guide > Installing a collector silently using the command line.

About the Configuration Tab

To display the Configuration Tab for a Server-to-Server Collector in the Historian Administrator, select a Server-to-Server Collector from the list on the left and click the Configuration Tab.


The table describes the Server-to-Server Collector-specific fields.
Field Description
Source Server Designates the Historian Server to use as the Source.
Alarm Replication Allows you to enable or disable alarm replication. If you enable alarm replication, all collected alarm data will be transferred from the source server to the destination server. If you enable alarm replication, you also enable alarm recovery. However, if you set the Max Recovery Time to zero, no alarm recovery should occur.
Message Replication

Allows you to enable or disable message replication. If you enable message replication, you also enable message recovery. However, if you set the Max Recovery Time to zero, no message recovery should occur.
Calculation Timeout (sec) The maximum time allowed for a tag's calculation formula to execute before being terminated. The default is 10 seconds.
Max Recovery Time (hr) The maximum time in hours before now that the collector will attempt to restore data during recovery logic. The default is 4 hours.
Add Prefix to Messages Allows you to add an identifying prefix to replicated messages, so that they can be easily identified on the destination.
Alarm and Event data will automatically have a prefix added to it with the following syntax:
MachineName_Datasource

For example, if your alarm is forwarded from the server Almserver12 with a data source named OPCAE, the prefix will be Almserver12_OPCAE.

Creating a Destination Tag

Prior to building your formula, you must add a destination tag. This differs from the Calculation Collector in that you can browse the collector and select a tag rather than having to copy a tag or create a tag manually. You can also copy or add a tag manually, if you want.

As with other collectors, Historian creates destination tags with the collector prefix, if there is one, attached to the tagname(s). By default there is no prefix, so that the tagname on the source and destination match. The default configured calculation for the destination tag created is as follows:
Result=CurrentValue("sourcetag")
  • Add a destination tag by browsing
    The steps to add a destination tag are the same steps you would follow for other collectors:
    1. Select the collector.
    2. Click Add Tags.
      The Add Multiple Tags from Collector dialog box appears.
    3. Click Browse.
      All available source tags display in the Browse Results section of the dialog box.
    4. Select the tag or tags that you want to add.
    5. Click Add Selected Tags.
  • Add a tag manually. For more information, see Data Collectors General > About Manually Adding New tags.
  • Add a tag by copying. For more information, see Data Collectors General > About Copying Tags.

Assigning a Trigger to a Tag

You assign a trigger to your destination tag in the same manner as you would with calculation tags. The trigger can be scheduled (polled) or unsolicited (event-based). When you use an event-based trigger, you must also set up a dependency list of one or more tags. For more information, refer to Polled Trigger and Unsolicited Trigger.

Creating a Formula

Building a formula with the Server-to-Server Collector is the same as building a formula in a calculation tag. For additional instructions, refer to the following sections in Calculation Collector:

  • Creating a calculation Formulation

  • General Guidelines for Designing a calculation formula

  • Verifying the syntax of a calculation formula

You can expect thousands of tags per second to be processed, depending on your calculation formula. However, the destination server has a limited number of incoming events per second, which is shared by all collectors.

For polled collection, for instance, you can expect to perform hundreds of calculations per second. Polled calculations, using calculated data functions, are slower than unsolicited calculations using the CurrentValue() function.

About Recovery Mode

Normally, the collector operates in real-time mode. Real-time mode is when the Server-to-Server Collector is polling or is subscribed to events and fires calculations based on these events occurring in real-time. Messages are also sent as they occur. Recovery mode allows you to recover tag and alarm data when the connection between the collector and the source server is re-established. After a connection loss, the configuration settings for the Server-to-Server Collector determine how much tag and alarm data is recovered and if messages are included in the recovery.

The default recovery time is 4 hours. You can disable recovery mode by setting the Max Recovery Time on the Configuration tab of the Collector Maintenance screen to 0 hours.

When Does Recovery Occur?

Recovery mode executes:
  • On Calculation Collector and Server-to-Server Collector start-up.
  • When the collector is resumed after a pause.
  • When there is an on-the-fly change (similar to a pause and resume). Only tags in the new tag con- figuration are recovered.
  • When there has not been a collector stop and start, but the connection to the source archiver is restored.

What Happens When Recovery Occurs?

Upon connecting to the source archiver, in recovery mode, the collector will:
  • Set up subscriptions for all alarms and trigger tags.
  • Perform recovery in time order, oldest to newest.
  • Perform message recovery, if enabled.
  • Begin polling and processing subscriptions in real-time mode.
The items recovered are:
  • Event-based tags

    This includes the data from the last write time until now. The system retrieves all tags.

  • Messages

    The system checks for new messages and verifies errors. Once the system verifies a connection to the destination, it sends the messages one at a time.

  • Alarm Data

    This includes all alarm data from the last write time until now.

Note: Alarm recovery uses a different write time than tag recovery. Alarm recovery starts from the time of the last alarm replicated to the destination.

If your formula contains tags not in the trigger list or dependencies exist among tags (for example, if a calculation tag is a trigger for another calculation tag), then you might not recover all data.

About Collection of Raw Samples

It is recommended that you view collected data on the destination with interpolated queries rather than raw data queries to minimize the effect of missing samples.

Here are some suggestions about how best to configure your system when you want raw samples of collected tags to match on the source and the destination. This is often not achievable, but here are some tips:
  • Use the formula Result=CurrentValue("TriggerTag").
  • Do not use collector compression on the destination tag.
  • Use archive compression on the destination if it is set on the source.

    The reason for this is that unsolicted triggers fire based on value changes, not based on what gets stored in the archive. A value change may not get stored on the destination if archive compression is being used. It is up to the destination tag to apply the archive compression before the value is stored.

  • Use event-based triggers with 0 ms collection intervals.
  • In the Server-to-Server collector, disable the Synchronize Timestamps to Server option.

Working Server-to-Server Example

This section describes two Server-to-Server examples:
  • Simple collection, which is raw sample collection.
  • Advanced collection, which is anything other than raw sample collection. It differs from simple example in that you add a tag manually and give it a tagname on the destination server representing the meaning of the calculated value. In the advanced collection formula example, you calculate a value such as an hourly average of a source tag or add two source tags together.

Simple Collection Example

In this scenario you collect raw samples from the source and send them to the destination. The tagnames are the same on the source and destination.
  1. Browse the Server-to-Server Collector to display the tags on the remote server.
  2. Select a tag.
    The collector creates a tag on the destination with the tagname to hold the collected data. The formula of the created tag is Result=CurrentValue and the source is the trigger.

Advanced Collection Example

  1. Add a tag manually to the destination, as shown below:


  2. From the Tags screen, click the Collection tab.
  3. Select Polled from the Collection Type drop-down list.
  4. Set the Collection Interval to 1 hour.
  5. Select the Calculation tab.
  6. Enter the name of the tag into the Calculation pane or use the Insert Function Wizard to browse and select the tagname. Then, build your calculation formula.
    The following figure shows an example of inserting a calculated value for a tag with the Insert Function Wizard.


  7. Select Insert.

    The Tag Maintenance screen appears, showing the formula in the Calculation tab.



  8. Click Update to save your changes.
    A message box appears if you did not test your formula.
  9. If a message box appears, click Yes to proceed with the update.
    The Server-to-Server Collector will begin processing the created tag upon the next collector reload.

General Guidelines for Using the Server-to-Server Collector

It is recommended you follow these general guidelines when using the Server-to-Server Collector:
  • Use polled triggers to perform scheduled data transformations like daily or hourly averages. Use unsolicited triggers to replicate data in real time, as it changes.
  • Use event-based triggers to replicate data throughout the day. The samples can be held in an out- going store and forward buffer when necessary. You cannot schedule batch replication of raw samples. For example, you cannot, at the end of the day, send all raw samples for tags to the destination.
  • Use event-based triggers to replicate data throughout the day. The samples can be held in an out- going store and forward buffer when necessary. You cannot schedule batch replication of raw samples. For example, you cannot, at the end of the day, send all raw samples for tags to the destination.
  • All input source tags for the calculations must originate from the source archiver. For instance, you cannot directly add a tag from server1 plus a tag from server2 and place the result on server2. You could, however, collect tags from server1 to server2 and then use the Calculation Collector or Server-to-Server Collector to accomplish this. This requires two Server-to-Server Collectors, one running on each machine. You could also use the Historian OLE DB Provider.

After Adding Tags using Server-to-Server Collector

When you add a tag by choosing from the Server-to-Server Collector browse list, only certain tag properties are copied from the source tag to the destination tag. If you intend to copy raw samples from the source to the destination, after you add the tag, be sure to set these properties to their desired values. See Tag Properties Copied to the Destination Tag described below.

Important tag properties that do not automatically copy over when you add the tag include:
  • Input scaling settings

    Since the output of the source tag is the input to the destination tag, you actually want to match the EGU limits on the source to input limits on the destination, if you are using Input Scaling.

  • Timestamp resolution

    Make sure that the timestamp resolution properties match. For example, do not use the second timestamp resolution on the destination tag, if your source tag uses millisecond timestamp resolution. If your source tag uses millisecond timestamp resolution, then you also want to set your destination tag to also use millisecond timestamp resolution.

Tag Properties Copied to the Destination Tag

The following table describes the tag properties in the Historian Administrator Tags screen that are copied when the destination tag is created via select from the browse. If a property is not listed in this table, it is not copied.
Tab Name Properties Copied
General Description

EGUDescription
Collection Data Type

DataLength
Scaling0 HiEGU

LoEGU

InputScaling

HiScale

LoScale
Compression ArchiveCompression

ArchiveDeadband(%)