GUI Front End for UA Adapter

Howdy. After using the MQTT Adapter as the primary ingress tool for data flow for roughly 30,000 tags, I have some thoughts on the use and utility of the Adapter.

Learning the system

• Coming into a situation where the Adapter was already set up and no prior experience with it, I did not find the mechanisms to work with it to be intuitive.

• The user guide has a lot of information and details. However, I had a hard time converting what I CAN do to what I SHOULD do. It would be useful for some succinct examples of how to add a device and add points without needing to skip dozens of pages. Something that I could point to when training someone and say “here is what you should do”.

• Coming into a system blind, it’s difficult to determine if the source devices are sparkplug or a generic.

Maintenance

• Logging is lacking in useful information

  • Logs are extensive in what can be captured but are difficult to find the useful information. Many errors are very generic or don’t point to the object that is causing the problem. And if the logs have an identifier, they’re hard to figure out what tag they are referring to.

  • For example, deciphering the Adapter’s Data EgressDebugLogs when troubleshooting issues is nearly impossible when trying to find a specific error.

• Adding tags

  • Compared to interfaces where I can just add tags, I find it odd that I need to pull a list of all existing tags to add the new tags.

• Can’t easily filter tags (Include X, exclude Y)

  • The Adapter works well when I need to add all tags from a source, but it is annoying when I need to add subset of the tags.

  • When using the discovery function, it is difficult to keep track of which ID is being used if more than one person is adding tags. I have seen notes saying that that is not necessary, but seems to be suggested to use a discovery ID.

  • Once tags are discovered, it is a slog to go through and pick out a subset of tags to add/remove.

• Can’t easily update tags

  • If a tag’s name is changed in the source, it’s difficult to process that change. As it stands, I need to update the PI tag name, the Exdesc, and update the data selection upload for the PI Adapter.

• Without the consideration of the overall infrastructure, the MQTT adapter uses an “Extra server” in order to have effectively the same data flow as an interface. As such it essentially adds another “Moving Part” that requires monitoring and understanding.

  • Interface: Data Source > Interface > PI Data Archive

  • Adapter: Data Source > MQTT Broker > PI Connector > PI Data Archive

• It’s annoying that I can’t force the adapter to create tags. This comes up when setting up an AF structure and I get “PI Point Not Found” errors. This primarily occurs for set points or non-analog tags.

Overall, the issues I bring up can be distilled into the following points:

• The lack of GUI makes adding/monitoring/editing/removing tags a lot more difficult then it should be (or seems to be more difficult then using an interface). Right now, a lot of manual entries are required where each manual edit can lead to errors or mistakes. The addition of a GUI would add a level of abstraction to make maintenance and use of the adapter easier.

• When errors do occur, they are usually hard to troubleshoot or determine which object is causing the issue.

• I’ve encountered an issue when editing tags where the Adapter can’t handle a tag that has a duplicate container ID/Name. When this has occurred, ALL data flow stops.

My large customer, with many sites and limited support personnel, struggles to turn over the ongoing care of Adapters once they have been correctly installed by the support staff who cannot return to maintain them as the data source (and tags to collect) change over time. Providing a GUI for these maintainance-type tasks, would allow the local staff to maintain their own data sources.

I think the GUI should be an optional extra selected by the user at install-time, or a seperate install package altogether.

Part of the appeal of the adapters is the light weight. Adding a GUI would add bloat and consume resources on the hosting machine. Further considering that AVEVA's recent GUIs have been web portals which recommended Google Chrome, this would also be another source of bloat.

Another possible downside to having a GUI is that its more code to be maintained (look at ICU), and with the intention that the adapters are cross-platform a GUI may introduce additional complexity. Not a dev, so would be happy to be corrected.

One thing AVEVA could do to help users is to publish a Powershell script which will take a folder of JSONs and push them into the config as needed. For Linux the equivalent shell script can be provided. These would be open source and provided without guarantee, so maintenance of the code would not be a key factor in the adapter core functionality. I was also freaked out the first time I started an adapter, but after cooking a little powershell I much prefer it than e.g. the connector / DCM / relay webUI.

Another improvement requested elsewhere is to allow the config to be done from a remote machine and authenticated with Kerberos.

Hi Jiyeon,

For those of us who do not want to expose our systems to the internet, it would be better to have a GUI that is available on the machine that the adapter is installed on to allow for adding in Tags/Streams and be able to modify the configuration there without requiring a tenant and network connectivity. Otherwise, there are a whole host of customers who cannot consider the PI Adapters if they have to be open to the internet.

Thank you for your feedback. This is something we have heard from other customers as they evaluate which data connectivity product will suit their needs. While I do not have a timeline for when we will be looking at migration paths between PI Interfaces or PI Connectors to AVEVA Adapters, it is on our radar and we will do our best to make it a positive experience for you.

Related to this topic, we do have an offering via AVEVA Data Hub called Edge Management, which allows you to remotely deploy Adapters and Edge Data Store using edge modules. There is also a software management component we are working on to make it easier for you to manage Adapters and Edge Data Store instances from one central location in AVEVA Data Hub (regardless of whether you deployed them using Edge Management or not). These offerings do not require you to use AVEVA Data Hub as the data endpoint, but you will need a Data Hub tenant and network connectivity to the Adapter/Edge Data Store device.

If you have specific needs from the user interface, please share them in the comments so that we can have better insight into your expectations.