I'm trying to better understand how subscriptions work between gateways when using a Remote Tag Provider in Ignition 8.1.
Let's assume the following architecture:
Gateway A exposes tags through a Remote Tag Provider.
Gateway B contains Tag References (or tag bindings that effectively reference remote tags) pointing to tags in Gateway A.
These Tag References are enabled, but:
are not historized,
are not always displayed in any Vision/Perspective view only when the view containing them is showed,
are not used by alarms,
are not otherwise consumed by clients.
My question is whether the mere existence of the Tag Reference creates and maintains an active subscription to the source tag on Gateway A.
More specifically, I would like to distinguish between two scenarios:
Scenario 1: Source tag changes regularly
The source tag in Gateway A changes value frequently.
In this case, I would expect an active subscription and value updates to be propagated through the Gateway Network.
Scenario 2: Source tag never changes
The source tag in Gateway A remains constant for a long period of time:
Value does not change.
Quality does not change.
Timestamp does not change.
In this scenario:
Does the Tag Reference in Gateway B still maintain an active subscription on Gateway A?
Does this subscription generate any Gateway Network traffic besides connection keep-alives?
More importantly, can the existence of that subscription cause the source OPC tag to continue being scanned/read cyclically on Gateway A, even though no value, quality, or timestamp updates are being generated?
My main goal is to understand whether a large number of remote references to mostly static tags can still have a performance impact due to maintained subscriptions and/or continued field device polling at the source gateway.
Has anyone tested this behaviour or can confirm how Ignition 8.1 handles these subscriptions internally?
Subscriptions themselves do not cause any polling. Ignition's entire tag subscription architecture reports changes only. Only OPC drivers (not OPC connections) typically require polling.
Not sure what happens with Reference Tags or Expression Tags set to execute periodically on group mode. Worth testing that case.
I think my remaining doubt is slightly different from the polling question.
I understand that subscriptions themselves do not cause polling of the source OPC tag. However, I'm still trying to understand the behaviour of the Gateway Network subscription itself.
Let's assume:
Gateway B has a Tag Reference pointing to a tag in a Remote Tag Provider on Gateway A.
The source tag on Gateway A remains completely unchanged (value, quality and timestamp stay the same).
In that situation, does Gateway A send any periodic updates across the Gateway Network to keep the reference on Gateway B up to date, or is the subscription entirely event-driven and therefore completely silent until an actual change occurs?
In other words, once the subscription is established, should I expect:
Only connection/subscription maintenance traffic (keep-alives, session management, etc.), with no tag value updates being transmitted?
Or are there periodic tag value refreshes sent to Gateway B even when the value, quality and timestamp have not changed?
My concern is not the OPC polling side anymore, but whether a large number of remote references to mostly static tags could still generate noticeable Gateway Network traffic simply to keep the remote references synchronized.
I wanted to close the loop on this topic because we discussed it further with Inductive Automation while reviewing a large-scale architecture.
Your explanation regarding the Gateway Network itself was correct: updates are indeed event-driven, and static tags do not generate periodic tag value traffic across the Gateway Network.
However, the important detail we learned is that Reference Tags maintain permanent subscriptions to their source tags for as long as the Reference Tag exists, regardless of whether any Vision client, Perspective session, script, or binding is actively consuming them.
In other words, while a static source tag generates no ongoing value updates, the subscription itself remains active indefinitely. At small and medium scale this is generally not an issue, but in our case we were evaluating a Unified Namespace style layer composed of hundreds of thousands of Reference Tags. Under those conditions, the number of permanent subscriptions becomes a relevant architectural consideration.
Inductive's recommendation was to avoid building a large semantic layer entirely from Reference Tags and instead consume data directly from the Remote Tag Providers whenever possible, preserving the dynamic subscription model that Remote Tag Providers natively provide.
This was not obvious to us initially because we expected Reference Tags to behave more like lightweight aliases that could benefit from the same demand-driven subscription mechanism. It turns out they are real tags with their own execution and subscription lifecycle.
Thanks again for your clarification. Your comments helped us narrow the investigation and ask the right questions.
Yeah that's the practice we follow as well but with one caveat that sort of annoys me is that loading times with remote tags are slower than local or reference tags. I wish there was a way to tell the front end gateway to fully mirror/cache the tags in real time to speed up initial page loads.
Figured I'd mention because in our case the performance of two servers in the lab vs the real world with one on site and one cloud based was very noticeable.
The discussion with Inductive Automation raised an interesting architectural question that we are now evaluating.
Since Reference Tags maintain permanent subscriptions to their source tags, using a large Reference Tag layer on a frontend gateway no longer seems like the right approach for the scale we are targeting.
We are therefore considering moving the semantic layer (UNS-style namespace) to the backend gateways themselves and exposing that semantic layer through standard Remote Tag Providers.
My understanding is that this would still incur the cost of maintaining the Reference Tags in the backend, but it might allow the frontend layer to recover the native demand-driven subscription model of Remote Tag Providers.
What I am trying to understand is whether a Remote Tag Provider exposed from a provider that contains mostly Reference Tags still behaves dynamically.
For example:
The backend contains a large semantic layer built from Reference Tags.
That provider is exposed through a Remote Tag Provider.
No Perspective sessions, Vision clients, scripts or bindings are currently consuming any of those tags.
In that situation, would the frontend gateway maintain zero active subscriptions until data is actually requested?
In other words, does the Remote Tag Provider preserve its normal demand-driven subscription behavior even when the tags being exposed are themselves Reference Tags?
This is becoming an important question for us because we are trying to determine whether a distributed semantic layer on the backend could provide a better balance between maintainability and scalability than materializing the semantic layer on the frontend.
A related question that we still need to investigate separately is how local Reference Tags interact with Leased Tag Groups, but I suspect that is a different topic.
