Which client application they are using to visualize these invalid attributes? In ProcessBook you could use a MultiState Symbols approach to hide these "undesirable" attributes.
Standard OSIsoft tools (ProcessBook, Coresight, Datalink, ...)
Great question. We have had similar requests from other customers and have discussed this feature request internally. Well now that you've asked, maybe you can help us with a bit more details on your specific use case(s) .
So the question is how would we determine if an attribute should be "hidden" or not. Would you want users to have to "flag" each attribute that should be "hidden" and not shown by our client tools (i.e. Coresight, ProcessBook, etc.), maybe using PI System Explorer? Or would you want the software to automatically determine if an attribute should be "hidden"? If it's the latter, we would need to differentiate between many scenarios. For example, we could have an AF attribute that does not have a value because:
1) the source doesn't exist (e.g. if it's a PI Point data reference, the PI Point doesn't exist because the sensor/transmitter doesn't exist)
2) it's not entered or provided (e.g. someone did not enter in a serial number)
3) the data source is broken (e.g. the PI Point exists but the sensor/transmitter is broken)
I'm sure there are more scenarios but these are the 3 most common ones that I can think of. All this assumes we are talking about elements instantiated from templates.
On my side, I don't like the "Automatic guessing" option. Sometimes it hides problems that we should be aware of !
Reading the possible options, I think this looks like a “State” for an attribute. (I mean an attribute can only has one of these values at a time)
1. Valid (default?)
3. Not entered yet.
4. Data source broken.
5 ... more ? ...
A good thing about it it’s when comes the time to implement at a site, it will be very easy to “Hide” unwanted attribute, Query “Not entered yet” and work on these.
PI System Explorer and PI AFBuilder is a good place to update this “future State”.
For my project, this is what my need.
My 2 cents... Hope this help !
PS : Thanks to all that replied !
So it sounds like in your case, it's acceptable for your users to individually configure the attributes that you want "hidden" to the client software. Other customers that have asked for the ability to hide "unused" attributes have indicated that in addition to being able to mark an attribute to be unused, they would not want to HAVE to do that for every attribute. For example, if you would imagine an oil field with many wells that are constantly being drilled, instrumented, tested, etc. Their AF structure is constantly in flux (very dynamic) and asking the user to have to manually mark attributes to be "hidden" is not acceptable, even if it's just a small number of attributes. Another example would be where a refinery is being built, sensors/transmitters are being brought online all the time. It's not very user friendly to have to go manually mark/unmark attributes whenever a change happens.
In addition, then there's the technical implementation side. There's a lot of implication with adding what you described as a "state" to an attribute. Imagine you have 16 million AF elements with X times number of attributes. Whatever we add to a representation of an attribute quickly becomes a scalability issue for our users with XXL AF systems.
So in short, what you have asked for is not new, but often times we have competing requirements and we try our best to satisfy the majority. In this case, we're in discussion internally how best we may be able to accomodate this. Please keep the suggestions and requests coming, I for one very much appreciate your inputs.
I would vote for the automatic guessing, although I would change the guessing part for some simple rules rooted to the Element Template - PE syntax style. However, with hiding of attributes you would still need the potential to override the rules when working with the AF SDK and get all Attributes regardless of what the Template defines.
With that said, maybe we get this type of functionality when we get extended properties of Attributes [;-)] vcampus.osisoft.com/.../12797.aspx
I understand thë ability of hidding attributes will be useful when the user is using these attributes in ad-hoc analysis and when buiding displays (since they would not appear in the search window), but will not be enough when you are trying to use the same display to monitor different assets where some attributes are hidden in one asset but are not hidden in others. So we need to find a way to tie the graphical element to the validity of the attribute. For example, the same ERD to show different wind farms: some farms have more turbines than others, so some values would appear invalid in the display. Using multi-state symbols to hide (cover) the turbines associated with these problematic attributes would do the job.