AVEVA Historian Connector from Plant SCADA

There aren't currently any plans to add redundant Historian support to the Connector.

However, when considering redundant configurations, it is best to start with the failure modes you aim to protect against. In the context of a Historian, the primary failures to consider are:

• Data Collection: Data from the sensor never reaches the Historian. Solutions are specific to the type of source
• Storage: Stored data is lost. Best addressed with a backup strategy and reliable disk (e.g. RAID 1, 5, 10 etc.)
• Access: Historian is temporarily offline (e.g. security update). Best addressed with the "partner" functionality in Historian/Historian Client Desktop and the client failover

For some common Data Collection cases, the best approaches are:

• Application Server: Redundant OI Servers with redundant AppEngines.
• Remote IDAS: Use two Remote IDAS each collecting from separate Communication Driver instances and channels to the source and each sending data to a separate Historian. You could use a single IDAS with Communication Driver failover, but most applications are more likely to have network disruptions and Remote IDAS cannot support both Driver failover and store-forward. The user is responsible to keep these configured consistently. 
• Plant SCADA Connector: Use two Connectors each sending data to a separate Historian. The user is responsible to keep these configured consistently. 

One limitation in the "partner" Historians is there is no automatic synchronization between Historian servers. In the redundant AppEngine case, this is less important, since the AppEngines synchronize the data before sending to the Historians. 

The Historian Client Trend failover only relies on having consistent tag names, so all three of the data collection approaches above will still work. 

There aren't currently any plans to add redundant Historian support to the Connector.

However, when considering redundant configurations, it is best to start with the failure modes you aim to protect against. In the context of a Historian, the primary failures to consider are:

• Data Collection: Data from the sensor never reaches the Historian. Solutions are specific to the type of source
• Storage: Stored data is lost. Best addressed with a backup strategy and reliable disk (e.g. RAID 1, 5, 10 etc.)
• Access: Historian is temporarily offline (e.g. security update). Best addressed with the "partner" functionality in Historian/Historian Client Desktop and the client failover

For some common Data Collection cases, the best approaches are:

• Application Server: Redundant OI Servers with redundant AppEngines.
• Remote IDAS: Use two Remote IDAS each collecting from separate Communication Driver instances and channels to the source and each sending data to a separate Historian. You could use a single IDAS with Communication Driver failover, but most applications are more likely to have network disruptions and Remote IDAS cannot support both Driver failover and store-forward. The user is responsible to keep these configured consistently. 
• Plant SCADA Connector: Use two Connectors each sending data to a separate Historian. The user is responsible to keep these configured consistently. 

One limitation in the "partner" Historians is there is no automatic synchronization between Historian servers. In the redundant AppEngine case, this is less important, since the AppEngines synchronize the data before sending to the Historians. 

The Historian Client Trend failover only relies on having consistent tag names, so all three of the data collection approaches above will still work.