Fairly new to Ignition... I'm working on a project where we'd like to have some (not all) of Ignition's OPC tags available to the end user to log to their data historian (Pi, IBA, etc) via OPC UA. I understand that Ignition is inherently an OPC UA server, but I'd like to limit which tags are accessible by the end user. For example, they'll need to read production data and the like, but I don't want them to have access to anything internal the Ignition app, PLC comms, etc. Is there a way to create a second OPC UA server within Ignition the end user can connect to, or a way to partition/hide some of Ignition's tags on the OPC server? Any suggestions would be helpful!
No, the OPC server's authentication/security model isn't sophisticated in v8.1. (Changing in the near future with v8.3, but to what extent is still unknown.)
Consider exposing a Modbus Server (Mine or the open-source server offered by IA's Kevin Herron.) Or perhaps a Logix Server (my EtherNet/IP module's Host Device).
3 Likes
Unfortunately no, not really.
Role-based access control at the device and tag provider level has been implemented and will be available in Ignition 8.3, but until then OPC UA access for external clients is pretty much all or nothing.
2 Likes
If you go my recommended route, you would script the publishing of the tags of interest to Modbus/Logix addresses that the external user would "see" via either of these common protocols.
1 Like
As others posted, not possible within Ignition. I had a similar need (OPA UA specific read/write access) in the past and opted to create a separate UA server outside of Ignition. In my case, I used Node-RED & the Ignition Node-RED Module to connect to Ignition and listen to specific tags, then host the data in the new server within that app. While the client and myself are very pleased with the outcome, setting up a separate application to manage often leaves a lot to be desired...
If native-ignition is a requirement:
- Connect directly to their database and send the data to them.
- Use WebDev module & build custom API to handle their requests
Else:
- Host data via other third-party protocols, as @pturmel mentioned.