Ignition OPC-UA/PLC tags


1.0 I guess OPC-UA server of Ignition stores the PLC tags in a seperate name space, but how does this update? Is it thru Ignition OPC-UA acting as a client and subscribing to tags on PLC OPC server? Or there are PLC drivers which directly update their values from PLC to Ignition OPC server?

2.0 Are the OPC UA Tags corrosponding to PLC name space(s) always exposed to a third party OPC-UA client ? Or they have to be explicitly exposed from Ignition?

3.0 Can a third party OPC-UA Client directly access OPC server on PLCs (perhaps it may depend upon the access rights give to the client logged in as).

Will appreciate some light on this.


Most PLCs do not have OPC servers built in - especially older ones. Our driver modules are plugins to our OPC-UA server and they are polling the PLCs for values in response to the subscriptions made in the UA server.

They are always exposed.

Like I said in 1, you probably don’t have a PLC that has an OPC server on it, but if you did, it would be entirely up to the access rights defined in the PLCs OPC server.

Thaks a lot Kevin. A few more questions come to my mind now:

  1. If PLC Tags in OPC UA server are alway exposed, then are Ignition’s internal tags hidden by default and the expose tags option in Ignition’s OPC UA control panel provided to only exposes these tags?

  2. Are all PLC tags connected to the system always available in Ignition’s OPC UA server? (ofcourse access protected by appropriate client permissions). Or some PLC drivers write values to Ignition’s Internal (memory) tags as well? i.e. does Ignition’s OPC-UA server contain all tags of all the PLCs controllers in the entire system?


That’s right, the “exposed tags” option only changes whether the Ignition tags are available through the UA server. You can maybe think of it as a driver for Ignition’s tags.

The tags from any device you have configured in the server are always available. The PLC drivers never write to Ignition’s tags. They don’t know about or have any access to those tags.

Thanks again kevin,
You said “The tags from any device you have configured in the server are always available”, which means its possible to have devices that are configured out side OPC UA Server?

  1. Then where do such tags get stored in Ignition? In some Ignition folder which is driven by a diver for that device (tag provider)?
  2. How can these be accessed by an external OPC Client? Only by exposing all Ignition tags? That will mean all other tags in Ignition will also get exposed!
    3.What is the general % of devices which are configured under OPC UA and out side of it? I guess all modern control devices come with OPC UA drivers and they get configured in OPC UA address space?
  3. I am just trying to guess what generally % of controller tags can be accessed by an external OPC UA Client? Exposing all tags will make it 100% but how safe is it to expose all tags of Ignition as OPC UA tags and is it done frequently in practice?


No, it’s just devices you’ve configured on the Ignition gateway page. Those are the only devices the UA server will be looking at.

You have to understand that the UA server, conceptually, exists entirely independently of the rest of Ignition. There’s nothing shared between the UA server and the rest of the Ignition tag system.

So you configure devices that the UA server will communicate with. This means any tags available on any of those devices are available to any UA client that connects to the server.

Ignition can act as a UA client. By default, it comes with a UA client connection configured to the UA server. There’s no magic, no sharing. It’s no different than a connection to a 3rd party UA server like Kepware.

Exposing the Ignition tags through the UA server is an all-or-nothing deal right now. Whether that’s safe is for you to decide.

Thanks a lot Kevin. I am asking all these stupid looking questions as I don’t have a hands on with Ignition so far its just evaluation of it. Things are much clearer now and will become more clear as I execute more projects with Ignition.


Sorry for asking again.

does it mean that ALL devices in the system HAVE to be configured to UA server on Ignition (of course thru Ignitiongateway page)? i.e. no device can connect directly to Ignition’s internal tags directly using some driver writting to these internal tag providers (like modbus driver or S5 driver etc?).

What I am trying to understand is that whether all device tags will be accessible to external OPC UA clients (like mine), without having to use the Expose All option on OPC Server control panel. (Of ocurse access rights will depending the profile of my client application). This is to know for example in my ARSCADA module, whether I will be able to read/write tags on all PLCs through OPC or not.(of course depending upon what user I login as). The Ignition’s tags may not be available without the expose option, which is understandable.


The only way data from a PLC gets into Ignition is if it’s configured and coming from the Ignition UA server, or if it’s coming from another UA server like Kepware. Devices/drivers do not write directly to Ignition internal tags. You do not have to use the expose tags option to talk to any of the devices hooked up to the UA server.

Oh! Thanks a lot Kevin. I am glad to know how Iginition connects to devices now. I should be able to connect to device IOs directly through OPC as long as I have the login credentials permit. Its a great relief for me.

Then what are Iginition internal tags use for? Is it for SQL bridge logging in DB, Alarms, Historization, calculations, reports etc? Hope my understanding is correct.

How can I access alarms and trends (history) as they are not part of OPC? What are the API’s in sdk to do that. What about if I want to access alarms & history thru OPC without having to write a module?


Yes, for everything else you get except for the value, essentially. Expressions, DB tags, alarming, all of those are what Ignition tags are for. OPC just provides values.

There’s no access to these through OPC. The SDK can access these through the AlarmManager and HistoryManager interfaces, although I’m not familiar enough with these to provide more details offhand.

Ok, Thanks a lot for the inputs. I will read the documentation for alarms and history module.
best regards