Separate Connectivity Server to feed data to Third Party OPC Client
We are looking at ways of shielding the 800xA from untimely restarts or unplanned large read requests from the third party client.
The system is 800xA 5.1 FP4 Rev D RU2, with AC800M 5.0.2, & SG400 1.6/3 and any large read requests can cause loading increase on the SG400 controllers and we want to avoid this.
The system has 2 redundant pairs of 800 and 400 connectivity servers, have looked into options where we split the tag data set between multiple 800xA OPC surrogate nodes and setting affinity to different connectivity servers to spread the load across different connectivity servers.
There were some incomplete suggestions we received with an option to have separate connectivity for 3rd party subscriptions this potentially will limit or avoid disruption of operations in the event of an issue with the third party subscriptions as the 800xA nodes will get served by dedicated connectivity servers. Are any aware of this option or have used this we would like to try and understand how this can be achieved.
If there are other easy options please suggest, currently, we can see that 15k items are subscribed from one 400CS via the surrogate for this third party connection and this might go up by another 5k by next year.
Voted best answer
> "Separate Connectivity Server to feed data to Third Party OPC Client"
This wont solve your problem.
All data is available on all clients. The connectivity servers collect the data from the controllers and distribute the data to every client. So your third party OPC Client does not need ( and probably wont benefit from ) an "Additional Server". You should however always install your third party client interface on an "Application server" - ie a dedicated 800xA client - NOT the Connectivity Servers ( which you have already done )
Additional AC400 Connectivity Servers are appropriate if the RTA board is becoming overloaded. Additional AC800M connectivity servers are appropriate if the number of MMS messages are overloading the communications between the AC800M and OPC Servers. Adding more servers will not solve the problem of excessive load on the controllers.
> " large data set subscribed by a third-party OPC client"
That's one of your problems.
OPC-DA connectivty to an AC800M control network is fairly robust, and you can "get away" with subscribing a lot of data. It is important that you properly implement callbacks and manage the subscription group sizes.
>"15k items are subscribed from one 400CS" "and any large read requests can cause loading increase on the SG400"
This is the BIG problem.
This is a feature and fact of using OPC-DA connections to AC400 series controllers. And its why using OPC-DA to subscribe large amounts of data continuously from AC400 controllers is a really not a great idea
How to deal with it ? Well, this depends on the number of AC400 controller nodes, the subscription rates and how well your third party client can manage the startup of the OPC subscription groups.
Note that ... An improperly configured OPC Subscription rate on AC400 series controllers can seriously affect the performance of the controllers and network, including potentially, loss of HMI, stalls and crashes of the controllers. Adding connectivity servers or additional clients will not protect your system from this. This means that you really cant "shield"your control system from excessive load caused by a badly configured startup. You need to fix the startup. Ensure that your third party client does not try to start everything at the same time.
The best way if possible, is to stop using OPC-DA and instead use OPC-History and collect the data from the Basic History service. Any tag in History can be collected. This DOES protect your control system from improperly configured subscription rates, and means that your third party system can start up without affecting the controllers because the data comes from the History Server, not the controller. It also means that you can backfill data for the period while the third party system was down.