InTouch with Redundant Historian?

Hi Arul, you can't setup the Historian config for 2 historians this way, allows for only one, if you need 2, then you will have to do it via Historian config file or duplicate the intouch and have each of them point to different historians

Hi Arul, As Rainer mention, setting up a redundant Historian Pair is not configured in the InTouch or Application Server level.

You need to configure your historian pair in your Historian configuration that is found using OCMC.

On the primary node you configure the backup partner and vice versa.

On any client you enter the name of the primary node and if it is not available, the partner Historian node is used.

Please refer to the Historian Documentation for further details.

file:///C:/Program%20Files%20(x86)/Wonderware/Historian/Docs/1033/HistorianAdmin.pdf

Page 290

Using a Redundant Historian
You can configure the AVEVA Historian to have a "partner" AVEVA Historian that can be used as a hot backup if
the primary historian is not available. This is called a "redundant historian" setup.
If AVEVA Application Server is configured to send data to the AVEVA Historian, the AppEngine automatically
sends data to both the primary historian and the specified partner. If one of the historians goes offline, the
AppEngine stores the historized data until the historian comes back online. After the connection is restored, the
AppEngine forwards the data to the historian that was offline.
The Historian Client automatically detects and selects the online Historian from the redundant pair.

The historians in a redundant setup are not intended to be a synchronized pair, where both the historian
configuration and data are fully and automatically synchronized. It is up to you to make sure that the two
historians are symmetrical and synchronized. The following recommendations are examples of actions you
should take to keep the pair synchronized, or else incoming data is not stored as previously described.
• If you make configuration changes for one historian, be sure to perform the same actions on the partner.
• If you import a CSV file on one historian, you will need to repeat the import on the partner.
• If you add or update data to one Historian using SQL or the Historian SDK, you will need to repeat the action
on the partner.
To specify a historian partner:
1. In the Operations Control Management Console, expand Historian Group, expand the server, and then
expand Configuration Editor.
2. Expand System Configuration and then click Parameters. A list of all system parameters displays in the
details pane.
3. Double-click the Historian Partner system parameter. The System Parameter Properties dialog box appears.
4. In the Value box, type the computer name of the partner historian. You can use either the host name, fully
qualified name, or an IP address. Leading backslashes are optional.
Note: In network environments where AppEngine and Historian Client computers on different subnets must
access the partner, be careful to use a name or IP address that can be correctly resolved from all of those
network locations and not just between the historian servers themselves.
5. Click OK

Perhaps you also want to read up on how to set up Replication between two Historian nodes, perhaps that is also applicable for your original intentions.

I hope this answers your question.

Update!

I must admit that after posting my message I started to think that I, in my comments assumed that the (new) feature in InTouch to send data to a Historian worked in the same way as when logging data from Application Server (using similar feature).

So I decided to test to verify, and came to the conclusion that there are some features not fully available in InTouch yet.

When setting up two historians in a Pair you indeed get failover on a client level, but on a data provider level it seems to be differences.

In Application Server, adding objects with History enabled will create the attribute configuration (tag) in both Historians.

But when I try this in InTouch it will only create the tag in the primary server, leaving the redundant partner unaware of the new tag.

And the result of this is that in a scenario where the primary historian server is offline, no data from InTouch is ever logged to the backup, but when it comes online the Store and Forward feature will backfill the missing data on the primary historian.

On a client level, ie. in the Trend Client it will stay 'connected' though and you will be able to find and select only the tags available on the backup historian.

In a scenario of Application Server as the data provider it behaves as you might expect, If the primary server is offline it will continue to feed the backup historian server with data.
And when the primary server is online again, store forward will fill in the missing data, thus enabling redundance. (at least on this level, the subject of full redundancy is quite vast and can be built for many scenarios).

Since configuring InTouch to Enable logging to historian, witch is a quite new feature, it will be able to push data to the configured historian, and even the alarms and events generated with Store and Forward capability, witch is a huge advantage compared to the previous possibility, to manually configure historian to retrieve data from InTouch (view.exe) using a Suitelink connection. there are many tools to simplify this step, but in its core Historian uses InTouch as a datasource similar to any Device Integration Driver.
And if you want to achieve Store and Forward in this scenario, you have to set up an IDAS component on the InTouch Node.

The limitations are also related to the logging of Alarms, that from InTouch it will not support redundancy, yet.

So to re-conclude, If you want to achieve redundancy of Historian data, you might need to revert to the solution where you have two historians retrieving data from the same datasource, in this case, InTouch. (as already suggested by RAINER CARLTON DSOUZA )

Or look in to the Historian feature of Replication, depending on what is the need and possibility in your scenario.

Thanks Richard and Rainer for quick response.