PI Vision does not support the renaming of AF elements or attributes or the movement of them within the hierarchy. After renaming or moving these objects, symbols referencing them will show No Data in PI Vision.

As a PI Vision user, I want to use an AF hierarchy Tree View to switch the asset context of my display so that I can navigate to the asset I'm looking for.

PI Vision should be able to directly pull entire  table objects (such as linked tables) from Asset Framework into a display, rather than forming a table of attributes with Table Lookup data reference.

It is great that I can attach files as an attribute to an element in AF and that these files are shown in the PI-Vision navigation (see attached screenshot). But why is it not possible to open these files directly from PI-Vision? This would be a great improvment.

Assets and machines are never quite the same. Be able to swap the asset/element context (may be different template) and if the selected asset doesn't have certain data available on the display, don't show it on the display rather than an error message.

This should apply to collections in addition to individual symbols.

We should be able to add element's name and description to symbols, without the need to create another attribute for that. So we could easily have element relative titles and labels...

PSE is often used as a client-tool where it is not intended to be. It would be very beneficial to have a simple PSE tool just to view data. Browse Element Hierarchies and view Attributes, EventFrames.
Just like PSE. The hierarchy could also make a small step towards a navigation hierarchy to navigate to Asset-relative displays.

Allow AFTable data to be used in a Coresight display symbol.

Currently there is no way to navigate to AFTable instances in the navigation pane of Coresight. It would be useful to expose these object types and allow custom Coresight symbols to consume their data.

It would also be beneficial to expose a function in the webServices service so that this data can be retrieved programmatically. Currently, this is only possible by directly querying the PI Web API for this data via an $http call.

We have found PI System Explorer to be excellent at navigating through PI Tags, Document/Manual hyperlinks and general metadata about assets (serial numbers etc).

If it was possible to embed a PI Vision or PI Processbook page on a dedicated tab (Where General, Child Elements, Attributes, Ports, Analyses etc are) it would leverage visual tools within the asset framework, and allow for a true enterprise tool to monitor assets and projects.

Collection Criteria: Attribute Value

Current functionality allows to set collection criteria based on an AF Attribute value. However, this functionality does not work if the attribute uses the “Table Lookup” data reference.

Having this functionality available would increase scalability and flexibility.

This "feature" is very useful for all users (specially Operations) when we change from ActiveView to Pi Vision. The transition period must be taken in account.

It will be an extra if OSI can develop the visualization of some more detail information about the attributes of the assets in PI VISION.

As a PI Admin, we need to invalidate data that we do not believe is valid.  This can be a real pain to do in SMT and would be much more user friendly if we could highlight a trend of where we deem the data invalid and have it flag the data as questionable.

Currently, table dynamic filter criteria only includes element concepts, however, would like attribute category filtering concepts. For example, if I wish to categorize attributes as “Ancillary”, where one turbine model has 3 such attributes and another has 10 (because they come from different templates derived from the same base) – the table should shrink/grow rows to only reflect those attributes for the current asset context.

Handle the ability to trend data from attributes across AF Element Versions. 

For example, when old sensors have been replaced with a new control system, new tags are created and customers use AF Element Versions to manage the mapping between the old and new tags.  Users would like to use and visualize data across this versioning time point.

As a user, I would like to enter more than 1 reason code per event frame. For example, a downtime event frame is created for the whole production line, and I would like to have a reason code for the cause and the other for the equipment.
Currently, AF only supports 1 reason trait attribute per event frame. This also allows PI Vision to enter 1 reason per event frame.

As a user of PI Vision I would like to be able to swap through assets based on their element description rather than element name as it is easier for me to identify the assets as such.

We noticed that if we created in PI AF a parent template with a nested a child template, and subsequently instantiated the nested parent/child template in a PI AF hierarchy, PI Coresight would only recognize the instantiated parent asset in a related asset search. For example, in PI AF we are creating a parent template for a reactor and are looking to nest a child template for a weigh scale that only applies to a subset of all reactors. We want PI Coresight to return in a related asset search all reactors and the weigh scale where applicable.

As a user of PI Coresight I want to be able to swap context at a parent (plant) level and propagate new context to child elements relative to the AF model hierarchy.
Currently only information on the Coresight display part of the same element template are concerned by the swapping.

We would like to have a synonym field for an element’s attribute that is searchable through PI Coresight, analogous to how we could search for an attribute’s description. In the screenshot below, the rightmost button with the pencil allows us to search for an attribute’s description. Another button could be added to search for a PI AF Synonym. Synonyms for an element’s attribute could be created within PI AF and presented to PI Coresight. For example, we may want to equate the attribute “RPM” with “SPEED.”

Many times PI Administrators develop screens but are not the process specialists. The process user might see a "red" condition that is false and wants to quickly change the attribute limit (hi or lo) value so that it is no longer "Red". Rather than communicating to the PI Admin they should have the access to change it themselves without having PSE installed on their system. Saves a lot of time and work.