Best Practice for Polling Tags from a Remote Gateway

Ignition
, ,
1

I'm looking for some advice on the best approach for quickly polling OPC values from a remote gateway.

Generally, I know that for quickly collecting data, you would create a buffer in the device and pull large chunks in a single request. However, in this case I am creating a popup for a vision application and I need the device, tag paths, and sampling rate to be dynamic.

I had planned on the sampling rate being variable in set intervals with the shortest being 250ms and largest being 1 min.

The other roadblock I am looking at is that the device connections all live on a remote I/O only gateway.

I can use system.util.sendRequest() to execute system.opc.readValues() on the remote gateway, however, I'm "guessing" that making a call over the GAN at a high rate is a poor idea.

My thought was to send a message to the gateway to start an ExecutorSerive to poll for the values at the sampling rate, where I would build a buffer of an appropriate size, and then send that as a payload back to the front end gateway to be handled periodically. This raises some issues, because I would be collecting data to be displayed in the UI outside of the UI thread.

I am trying to be very cautious because if I were to do that, I would need to have a way to:

  1. Shutdown the service when I am finished with it.
  2. Change the sampling rate if needed.
  3. Somehow handle comm loss across the GAN (A user closes the popup, but because of a network issue the Shutdown can not be sent/received).

#3 is what I'm having issues with, I see this as a great way to have a memory leak if it isn't handled correctly, and I'm just not certain I understand how to do that.

I don't really want to expose the remote gateway's OPC server to a gateway where I'm already using it as a remote provider, but if that is really the best way to handle it I suppose that I will. I don't really have a good reason not to want to do that other than it just seems like a security issue.

Any advice on how to approach this would be greatly appreciated.

2

How many different collection rates do you intend to support?

3

I was planning to support 9 different rates:

250 ms, 500 ms, 1 sec, 2 sec, 5 sec, 10 sec,15 sec, 30 sec, 1 min

4

This is your best and most obvious option, followed by just setting up all these tags and tag groups on the remote gateway and then accessing them as remote tags over the GAN connection you already have. The downside to this option is you get control of the polling rates at the source/remote gateway, but you kinda lose that over GAN as values get reported by exception and batched/queued such that they are sent no faster than 1/second I believe.

1 Like
5

If you really don't want to expose your OPC UA server (and I usually don't either), consider an architecture where you have a 250ms timer event on the remote gateway that performs any reads per current schedules, and a message handler that establishes schedules for OPC server/item pairs at specific rates.

The message handler would simultaneously register timestamped "interest" in a server/item/pace and would return the current queue of samples for that point/pace.

Established queues would be sampled at pace until "interest" isn't renewed for some period of time. Perhaps the greater of 2x the pace or ten seconds. Samples older than that would be discarded as new samples are added.

(All held in a project top-level script cache.)

6

An exposed OPC UA server is no less secure than the GAN if you leave security enabled. The only real downside to exposing OPC UA right now is there is no fine-grained access control (read vs read/write permissions per provider or device), but if the client is just another Ignition Gateway then it probably doesn't matter.

7

That's a pretty big deal to me.

Maybe.

A message handler can have scoped access, and it can enforce its own rules, too. (A whitelist of allowed items/paces, perhaps.)

8

For most users it's exactly the same as having a a remote tag provider.

Here's some additional food for thought...

The OPC UA server implementation/security is open source, somewhat battle-tested, and deployed by many other companies than just us.

The GAN is a half-baked, always on, proprietary protocol that cribs the OPC UA security/certificate model and uses Java serialization under the hood...

edit: also to be fair, issues with both are being resolved in 8.3. OPC UA now has access control. GAN is moving away from Java serialization.

9

Good points.

It's in your hands, @lrose. With great power comes great responsibility. :grimacing: