How replication is handled for different types of data

An accurate map of data between replication tiers is maintained over time. This mapping includes both tag configuration and data synchronization.

Replication is unidirectional -- it goes from one tier to the next tier. For example, from the tier-1 Historian to the tier-2 Historian, but not from tier 2 to tier 1. If the data on a next-tier Historian is changed in any way, the system does not try to map the change back to the lower-tier Historian.

For example, suppose a tag from Historian A is replicated in real-time to Historian B. The tag on Historian B has exactly the same data and OPC quality values as the tag on Historian A. The replication system performs the following actions:

• When a new original value fitting the real-time window gets stored on Historian A, it gets transmitted and stored on Historian B, as well as the original value.

• If you perform an insert or update operation for some old values of the Historian A, the same change is reflected on Historian B.

• If some store-and-forward data gets merged into history on Historian A, the same data gets transmitted to Historian B and gets merged into history of Historian B.

Replication is implemented in two ways: streaming replication and queued replication. The replication system uses a combination of streamed replication and queued replication as required.