AVEVA Product Feedback
We're currently evaluating the future direction of PI System Management Tools and want to make sure we understand what our users need:
To help us evaluate this properly, we'd love to hear more from you:
Which SMT workflows do you use most frequently?
What are your biggest frustrations or pain points with the current SMT today?
Which parts of SMT feel the most cumbersome or time-consuming?
Are there are administration tasks that require multiple tools or manual workarounds?
If you could improve just one thing about SMT, what would have the biggest impact on your day-to-day work?
When determining if something in your PI environment needs attention, are there any health, usage, configuration, or monitoring insights that are difficult to obtain?
Your input is really valuable at this stage. The more detail you can share, the better we can understand what would genuinely solve your problems. Feel free to reply here and thank you!
SMT as a web application should be bundled into the PI Data archive installation, and not a standalone application.
Issues:
SMT is unstable.
Ex: when querying message logs for greater than 1 day.
Does not reconnect automatically when your workstation network disconnects. SMT will throw an exception and requires the user to restart the application. (ie: locking your laptop at the end of a workday and picking up where you left off the next day).
Lot of deprecated or not useful modules
Stale and bad points - this is useless for large PI systems
modules I've never used:
AF link/module database
Module database would be useful if we were able to use it to push changes to interfaces
Batch
Alarms
PI Services
PI Version
reason Tree
SMT is slow
loading interface list or point source list is slow.
If the PI server has all of its threads consumed, then you are unable to use SMT remotely. You must use SMT locally or revert to using cmd line utilities.
ex: querying Get-PIThreadInformation remotely will timeout if the PI server is overloaded.
What I would like to see:
better performance
better stability
expose PI system management functionality as part of the AFSDK or its own management SDK.
collective awareness
SMT should be able to manage changes accross all collective members.
ie: collective creation, decommissioning, promotion of new primary etc.
Tuning parameters should be applied to an entire collective rather than per host.
collective manager is bundled into SMT
remote interface management
PI collective health bundled into SMT
Something a little better than snapshot/archive statistics.
Heavy hitters report
ability to disconnect rogue users
interface health status
Stale and bad points check for interfaces
bulk point creation - import a csv of points with their respective configuration and construct them.
build points from defined template - save a list point configuration templates, that can be reused.
In response to Jaime Olmo ("With all the moving parts…"), PI System Management Tools currently doesn't have to be used from a PI Data Archive server. You can run it on other computers too. However, you still need to install it on every computer that uses it (e.g. on all of the computers of the PI administrators), since it is a client-side tool. If PI System Management Tools were a web application, then you would only need to visit a web link and you would be able to access the PI System Management Tools web page hosted by the PI Data Archive computer. Only a single installation on the PI Data Archive computer would be needed. We can see a similar idea in action when we compare the PI Interface Configuration Utility (PI ICU) to the PI Connector administration pages. The former must be installed everywhere that it is used, whereas the latter is accessible from any computer, as long as the security settings allow the connection.
Edit: I think that I misread Jaime Olmo's post the first time. Having a dedicated server for PI System Management Tools to avoid installing and updating it on each client computer introduces the hassle of having to log into the server just to use PI System Management Tools and of setting up such a server in the first place. It is overkill. As for the process of migrating PI System Management Tools to a web application, there is less to move over than you might think. A lot of the stuff that is available in PI System Management Tools is obsolete.
To answer the administrator's questions:
Which SMT workflows do you use most frequently?
The idea of PI System Management Tools as a web application is so that we can eventually abandon the current PI System Management Tools. It doesn't matter how frequently we use each feature. If we ever need a feature, then it should be available.
With that said, there are many features that I do not use, which are the deprecated ones. Below are the plug-ins that I hide in PI System Management Tools. I also don't use the menus at the top other than View → Settings… to hide the plug-ins listed below.
AF Link
Alarm Groups
AutoPointSync List
Batch Custom Names
Batch Database
Batch Generator
Interface List (soon)
Module Database (soon)
Performance Counters
Performance Equations
Ping
Reason Tree
SNMP
SQL Alarms
TCPResponse
Totalizers
What are your biggest frustrations or pain points with the current SMT today?
The number of plug-ins, menu items, features, etc. that are not applicable to an up-to-date PI System. You need to know some of the history of PI to know which things you can safely ignore. For example, most of the database security tables can be given permission to only piadmin: A(r,w) to effectively lock them down and ignore them. PI Groups, PI Users, and PI Trusts are obsolete.
The fact that I can't specify that I don't want the PI Interface Configuration Utility or the PI Module Database Builder installed, and so I end up uninstalling them after the installation of PI System Management Tools.
The fact that it tracks PI Data Archive servers separately from PI System Explorer, and so I need to check 2 places if a PI Data Archive server migrates or gets renamed.
Having to memorize what does not synchronize between PI Collective members (e.g. Archive Editor edits, tuning parameters, PI Firewall).
You can read some of the other suggestions for PI System Management Tools, including the declined ones, for a better idea of how to improve PI System Management Tools. e.g. suggestions that mention the "PIPOINT" database security table.
Which parts of SMT feel the most cumbersome or time-consuming?
The "Identities, Users, & Groups" and "Mappings & Trusts" plug-ins can take a while to load when I am working remotely. Perhaps PI System Management Tools could do some bulk calls to reduce communication with the on-site servers.
Are there are administration tasks that require multiple tools or manual workarounds?
Yes! The entire PI Asset Framework is handled by another program: PI System Explorer. It wouldn't be a bad thing to have PI System Management Tools and PI System Explorer be combined into the same web application.
Also, there is a lot that needs to be manually kept in sync between the PI Data Archives and the PI Asset Framework (e.g. security, Engineering Units versus Units Of Measure, digital state sets versus enumeration sets).
If you could improve just one thing about SMT, what would have the biggest impact on your day-to-day work?
Turn it into a web application!
When determining if something in your PI environment needs attention, are there any health, usage, configuration, or monitoring insights that are difficult to obtain?
All of them? We currently need to use the PI Interface For Performance Monitor, but I don't use it because it is not critical in my case and because I want to move away from PI Interfaces. The PI Connector For PI System Health was decent except for the fact that it used up a lot of tags for the PI Data Archive message logs, but it is no longer available. PI System Health would have been good if it was easier to set up and actually had a generally available release.