Please allow for having an Attribute tagged as a Display Name for the entire element that would be shown in dialogs like the Switch Asset instead of the Element Name.

It is reasonable if this had to be indexed to be usable.

We are aware of the tooltip which helps but its only sometimes useful and does not seem to be sorted alphabetically when the names are identical.

We have identical element names at the lowest element level with the parent path having more unique name (this is to support creating processbook displays from the parent and being able to refer to A,B,C in a relative way if they were fully unique this is not possible.). The Switch Asset is basically unusable if there are too many like this.

Alternately, allow showing 2 or more levels of the hierarchy so that more context can be seen. The full path is usually too long for that to be useful so a partial path would be nicer.

TR2.a Dynamic Hyperlink

In PI Vision, when adding a navigation link, configure the hyperlink address based on an Attribute Value from the target element.

TR2.b Collection of Dynamic Hyperlinks

Given a target AF Element, generate a collection of dynamic hyperlinks in PI Vision. The dynamic hyperlinks shall be generated based on children elements of the target for given criteria (i.e. element template or element category). Each dynamic hyperlink address shall be configured based on the value of a specific AF Attribute value. This attribute shall be the same for all the generated hyperlinks. (for more information on Dynamic Hyperlink, see section TR.2.a)

Note

TR2.a and TR2.b have been accomplished through a Custom Symbol, using the Extensibility Framework in PI Vision. We kept these requirements in this document to point out that the dynamic hyperlink functionality could be useful for several use cases and it may be worth including as an out-of-the-box feature in PI Vision.

In a collection you can use 'Set asset context' to open a new display and show data regarding the selected child element.
But when you want to use a link\button to navigate back to the previous display you cannot use this functionality. Because it will use in the current (the child) element instead of the parent. When you don't use 'Set asset context' it will open the correct display, but the selected element will be the one used when the display is last saved.

Notes:
- The option to open displays in a new tab of the browser is not preferred because it will take longer to open a display and after a while the amount of open tabs will be huge.
- The 'Go Back'-button (arrow) of the browser itself can only be used when no other element is selected using the 'Asset'-dropdown box. Because it will always open the previous page with the same settings, not the page with the actual parent.

I deleted the original post by accident.

I find some users will bring up a trend and want to input a custom time interval, ie 4 hour or 15 min trend. To adjust this right now you can use the left time slot; however, it would be nice to have a double click interaction in the box where the fixed time intervals are located. After double clicking you would be able to add a custom time, ie 4h, 15m, etc...

I also find many users will input a date in the bottom left form box. This date might be 4 years back during a major rain event. Doing this will query a large amount of data. Because

1. We have around 40k events per analog data item.
2. They are querying 4 years ago to now!

Removing the bottom left form box and allowing just the value to display will keep this huge query from happening. And as long as we have the interaction with the custom time intervals the functionality would still be there.

Finally, a lot of old school operators are asking for a popup calendar to show when choosing particular dates.

16 or so years ago Marty Williams at Coors came up with the idea to create a hierarchy to reference the file location of related PI ProcessBook Displays. The system originally as per the presentation used MS SQL to hold the paths of the PI ProcessBook Displays. This was similar to PIW displays but leaner. I rewrote the program to use the Module database to hold PB file references. The Treeview uses an S88 hierarchy to outline the whole brewing process and maps all implemented production PI ProcessBooks available for Brewing Operations staff. This one PDI file is still in service as a main PB Menu the Operations staff open to view their PB Screens.
http://www.osisoft.com/Presentations/Integrated-Access-to-PI-ProcessBook-Displays/
Now as folks implement PI Coresight, folks now need a similar type ability to have a main operations menu for PI Coresight. This Operations PI Coresight home page that would outline Plant Operations and provide a TreeView enabling navigation to the plant, area, process cell, and unit and process equipment displays. The PI Coresight Main Menu even with the searching capabilities would not be a viable solution on the Plant Floor.
Idea – Take the TreeView ActiveX solution of 16 years ago and implement a similar capability using a PI AF database and element attributes to hold the URL’s in a Coresight Symbol TreeView. A page or pages using this TreeView Operations Symbol would allow plant floor staff to easily navigate to their specific unit of interest.