Subscribe to OPC and get values from ALL tags in 800xA
We have a R&D project going where we use artificial intelligence to build models who analyse data and i.e. give an predicted control set point based on the calculations.
Our system is 800xA v6.0.3 without ABB historian. AC450 and AC800M plcs. Selected tags are subscribed to PI OPC DA Interface and stored in PI Data Server for historical needs.
When we wish to build a new model in the AI and PI don't have data for the sensors required for the model, we need to add them to PI and wait 2-3 months for data to accumulate to the model. This is not acceptable for us.
Expanding the tag license in PI is expensive and adding them to PI is a manual task.
Based on this we do not desire to use PI in this project.
We want to be able to build new models in the AI system at any time and have access to historical data on ALL tags in 800xA, continuously. The AI system will handle this.
When using Matricon OPC browser to the surrogate OPC I notice that the whole 800xA structure is exposed here. I would imagine that subscribing to all items on the surrogate would not be recommended?
We have selected Cogent Datahub to connect to surrogate. From here we want to subscribe to all tags (AI/AIC/AO/AOC/DI/DIC/DO/DOC/MOTCON/VALVECON/PIDCON/PIDCONA and more) and send to a 3rd party (AI datastorage). Subscribing to new tags need to be automated so when a new tag is created in 800xA, it automatically is subscribed to and sent to the AI datastorage.
Can we subscribe to "all tags" (i.e. in control structure) in 800xA without overloading the system?
Can we detect new tags and automatically subscribe to them?
Our system is 800xA v6.0.3 without ABB historian. AC450 and AC800M plcs. Selected tags are subscribed to PI OPC DA Interface and stored in PI Data Server for historical needs.
When we wish to build a new model in the AI and PI don't have data for the sensors required for the model, we need to add them to PI and wait 2-3 months for data to accumulate to the model. This is not acceptable for us.
Expanding the tag license in PI is expensive and adding them to PI is a manual task.
Based on this we do not desire to use PI in this project.
We want to be able to build new models in the AI system at any time and have access to historical data on ALL tags in 800xA, continuously. The AI system will handle this.
When using Matricon OPC browser to the surrogate OPC I notice that the whole 800xA structure is exposed here. I would imagine that subscribing to all items on the surrogate would not be recommended?
We have selected Cogent Datahub to connect to surrogate. From here we want to subscribe to all tags (AI/AIC/AO/AOC/DI/DIC/DO/DOC/MOTCON/VALVECON/PIDCON/PIDCONA and more) and send to a 3rd party (AI datastorage). Subscribing to new tags need to be automated so when a new tag is created in 800xA, it automatically is subscribed to and sent to the AI datastorage.
Can we subscribe to "all tags" (i.e. in control structure) in 800xA without overloading the system?
Can we detect new tags and automatically subscribe to them?
Asked 4 months ago
Answers
0
Every OPC server has a performance envelope that must be heeded.
800xA for Advant Master is sensitive for the clients' choice of update rate.
To run lean and optimized, only 1, 3 or 9 seconds should be used. A 60 seconds subscription actually drain more resources than a 9 second subscription.
RTA CPU load should be kept below 50%, preferably less to not endanger the operators' view and control of the process.
Depending on number of controllers and IO you may max out the RTA CPU load before you reach your "all signals" goal.
You can add additional RTA and connectivity servers to split up a large subscription load.
Basic History is included free of charge with 800xA. You can have 10.000 logs per pair of connectivity servers. Not all of those logs can run at 1s. Use fast enterprise grade SSD or PCIe disks to reach optimum performance with Basic History.
Maybe your AI can read OPC HDA from such logs? A 9 second log (lean to the controllers and OPC server) can easily be read out at 10s, 30s, 60s, etc interpolation using OPC HDA "ReadProcessed" calls.
800xA for Advant Master is sensitive for the clients' choice of update rate.
To run lean and optimized, only 1, 3 or 9 seconds should be used. A 60 seconds subscription actually drain more resources than a 9 second subscription.
RTA CPU load should be kept below 50%, preferably less to not endanger the operators' view and control of the process.
Depending on number of controllers and IO you may max out the RTA CPU load before you reach your "all signals" goal.
You can add additional RTA and connectivity servers to split up a large subscription load.
Basic History is included free of charge with 800xA. You can have 10.000 logs per pair of connectivity servers. Not all of those logs can run at 1s. Use fast enterprise grade SSD or PCIe disks to reach optimum performance with Basic History.
Maybe your AI can read OPC HDA from such logs? A 9 second log (lean to the controllers and OPC server) can easily be read out at 10s, 30s, 60s, etc interpolation using OPC HDA "ReadProcessed" calls.
0
Just to add to Stefan's excellent response. Keeping to the native 1, 3, 9 seconds for the AC450 is absolutely crucial. For subscription to all object I suspect 9 seconds might be the only feasible option, if at all possible.
You can measure RTA CPU load with the ANPER command. You could also measure the CPU load impact on the AC450 by using the ANPER command and doing a Task Load measurement for a minute or two. List the relative task load and add up the percentages for all the tasks with a name that starts with "DCSA01". You also want to note the load on any MB300 communications task. Look for task names that starts with "CXN". Also note the total system load (100 minus task load on CXKK340). Create a baseline before you start adding tags to the subscription list. Keep checking as you are adding tags to get a feel for the total impact.
You can measure RTA CPU load with the ANPER command. You could also measure the CPU load impact on the AC450 by using the ANPER command and doing a Task Load measurement for a minute or two. List the relative task load and add up the percentages for all the tasks with a name that starts with "DCSA01". You also want to note the load on any MB300 communications task. Look for task names that starts with "CXN". Also note the total system load (100 minus task load on CXKK340). Create a baseline before you start adding tags to the subscription list. Keep checking as you are adding tags to get a feel for the total impact.
Answered 4 months ago
0
As others have mentioned, the AI system will handle this, but the 800xA system wont. It simply cannot pass all of the data to your data lake. The pipe isnt big enough.
You cannot subscribe to "all" tags in an 800xA system because every object has tens or hundreds of properties, and the 800xA server doesnt have the capacity. There is also often no rhyme or reason to the naming of these properties and no simple automatic rule that can let PI consistently decide which properties are required and which are not.
Instead, use the PI OPC HISTORY Data Access Interface and ( optionally) configure the PI Auto Point Synch service (APS) for this interface. The History Interface can scan connect to the 800xA Basic History Service and identify all of the configured 800xA Historical Logs.
The APS can scan the 800xA Basic History which is exposed as an HDA server. Note however, there are some serious limitations that you must be extremely carefull of ....
- Scanning the HDA server for all tags on older versions of 800xA can overload the subscriptions on some older DCS systems. I have experience of an HDA crawler tool crashing a MOD300 node for example. Similarly, I have also experienced issues with Gogent's Datahub crashing because it simply cannot scan all of the OPC DA tags in an AC800M server. )
- Functionality of the APS is a little limited with the 800xA system - especially on Advant Master. Your PI Point Sources will need to be the GUID identified for the Log Configuration aspect ... so {very long guid}{very long guid}Property. This makes diagnosing PI point Sources a little confusing, but it does work.
Overall, it is usually better to export the Basic History Configuration with Bulk Data manager and Convert this back to a PI Point Configuration work sheet.
The PI History Interface can ALSO recover and back fill all of the old 800xA History Data stored in the 800xA history logs. So even if you do not immediately configure a PI Point you can still recover old data for whatever period you currently have stored on 800xA.
We have some considerable experience with 800xA, PI and data collection and BI systems like you describe. Feel free to contact me off forum to discuss your needs.
You cannot subscribe to "all" tags in an 800xA system because every object has tens or hundreds of properties, and the 800xA server doesnt have the capacity. There is also often no rhyme or reason to the naming of these properties and no simple automatic rule that can let PI consistently decide which properties are required and which are not.
Instead, use the PI OPC HISTORY Data Access Interface and ( optionally) configure the PI Auto Point Synch service (APS) for this interface. The History Interface can scan connect to the 800xA Basic History Service and identify all of the configured 800xA Historical Logs.
The APS can scan the 800xA Basic History which is exposed as an HDA server. Note however, there are some serious limitations that you must be extremely carefull of ....
- Scanning the HDA server for all tags on older versions of 800xA can overload the subscriptions on some older DCS systems. I have experience of an HDA crawler tool crashing a MOD300 node for example. Similarly, I have also experienced issues with Gogent's Datahub crashing because it simply cannot scan all of the OPC DA tags in an AC800M server. )
- Functionality of the APS is a little limited with the 800xA system - especially on Advant Master. Your PI Point Sources will need to be the GUID identified for the Log Configuration aspect ... so {very long guid}{very long guid}Property. This makes diagnosing PI point Sources a little confusing, but it does work.
Overall, it is usually better to export the Basic History Configuration with Bulk Data manager and Convert this back to a PI Point Configuration work sheet.
The PI History Interface can ALSO recover and back fill all of the old 800xA History Data stored in the 800xA history logs. So even if you do not immediately configure a PI Point you can still recover old data for whatever period you currently have stored on 800xA.
We have some considerable experience with 800xA, PI and data collection and BI systems like you describe. Feel free to contact me off forum to discuss your needs.
Answered 4 months ago
0
Example:
Is an analog input tagvalue on the AC450, read through PU410 RTA to connecctivity server, replicated to all surrogates at the same rate? Who decides the rate?
If a OPC client subscribe to the tag on the application server, with another scan interval, would this affect the update rate on the surrogates and/or affect performance on AC450 CPU and/or on PU410 RTA?
In another thread here on the forum, it says that the data rate is driven by the OPC client. If a OPC client subscribes "too many tags" on the application server, it would only affect the application server performance and keeping the system safe (operators view and control). Is this correct?
https://forum-controlsystems.abb.com/864818/OPC-Surrogate-Process
We're using basic history on most tags. I was not aware that we could use OPC HDA and get reply from the basic history on this. Would certainly be an good option to look into this function!
All servers run on VM Host using enterprise grade SSD in RAID so we're in good shape here.
Answered 4 months ago
0
I've written a small script in Python that reads OPC HDA data from basic 800xA historical data.
PyOpcHda (github.com)
PyOpcHda (github.com)
Answered 4 months ago
Add new comment