Can you give me a 10,000 foot view of data flow in OPC-UA?
I am familar with the earlier technologies.
DDE is basically a report by exception scheme.
ADVISE basically says report the current value and tell me whenever it changes.
OLE was an extension to this.
OPC a further extension, standardization. COM and DCOM at some point, OLE or later.
OPC-UA a complete rework, eliminating reliance on COM and DCOM.
So, from OPC-UA driver to say a ControlLogix, what’s the scheme, polling?
From OPC-UA driver to the rest of the Ignition modules, what’s the scheme? Commands and report by exception? A combination of polling and report by exception?
I’m going to start from the Ignition Gateway and work my way down to a driver.
The Ignition Gateway (and any other part of that system) that consumes OPC-UA data does so via a OPC-UA connection added under the Configure > OPC Connections > Servers part of the gateway. Typically, and by default, you are talking to the Ignition OPC-UA server, but it can just as easily be another UA server like Kepware. SQLTag scan classes and SQLBridge groups are realized as subscriptions on a given UA connection.
Let’s work with a group of 10 tags running in a 1000ms scan class. This means that a subscription is created on the UA server at a rate of 1000ms, and items are added to that subscription with a sampling rate of 1000ms. In OPC-UA the rate the subscription evaluates can be independent of the sampling rate of each of the items in that subscription, however we use the same rates for both. The rate the subscription runs at is basically how often it will evaluate its items for changes and send data to the client. The rate the items sample it is supposed to represent how often they sample the underlying data source. So your tags in a 1000ms scan class sample every 1000ms and report every 1000ms.
Into the driver system. This is where our 10 items are now sampling their underlying datasource. An optimized request schedule is created by the driver implementation. It’s likely that 10 items will be reduced to 1 request on a driver. The driver will send that request to the PLC once every 1000ms and report values to the server. The more tags you subscribe to on a driver, the more requests are necessary. The more requests you have, the more requests per 1000ms (or whatever your rate is) the PLC has to respond to.
The server is constantly evaluating the values the drivers are delivering and will only report changes in quality or value. In our example, every 1000ms the subscription would run and look for any tags that had a value/quality change and report those to the client.
So it’s a combination of polling and report by exception. The drivers are always polling - none of the devices we currently support have report by exception capabilities. An OPC-UA server, however, reports by exception to the UA client. Only changes in value or quality are reported in our case.
So scan classes can be used to faster and slower traffic.
I read somewhere that using scan times based on factors of prime numbers helps to distribute the traffic. Something like 2 sec, 3 sec, 5 sec, and 7 seconds. Or it might look like 1 sec, 1.5 sec, 2.5 sec, and 3.5 sec. The scans are not likely to fall on top of each other.
Are you saying that Ignition always samples the PLC based on the scan class rate, or were they the same just for the sake of your example? On the gateway page for OPC-UA settings, there is a minimum sampling interval field. Is that value then basically the fastest scan class rate you can define?
About the scan classes: Scan class evaluation happens on the gateway and executions are decoupled from the subscriptions and sampling in the server. You could set up a scan class at 50ms and it would execute accordingly, however unless the minimum sampling interval were lowered as well you would still only be sampling the device at 100ms (the default minimum sampling interval).