1 of 1 people found this helpful
Have you considered using Attribute Categories to identify if an Attribute belongs to Design, Engineering or Operating category?
Within PI System Explorer the Attributes View can be customized by defining what columns should be visible. By clicking on the header of a column you can change the sorting. There's also an option to Group attributes by Category.
Some of the AF SDK calls allow to define a sorting that should be applied. A predefined AFSortField Enumeration has the available sort fields. Unfortunately AFCategory or Category is not included with that enumeration but AFCategory can be used as a filter for the Attribute retrieval. With AF SDK it's recommended to perform bulk calls which instead of single items return a collection of items. Those item collections can easily be sorted client side.
Because PI Web API depends on AF SDK, I assume that the before mentioned as well applies here.
Just to avoid confusion, PI SDK doesn't provide access to the Asset Framework. In addition we recommend against using it with recent development projects because PI SDK is announced to become deprecated.
Because you expressed to be interested in how others have addressed the issue you described, I join you in hoping to see some answers from other users.
We have considered all options, but probably the main requirements has not been well understood.
In Practice, we need to have a predefined position of categories and attributes in the asset element display , from any client or interface request result, getting this order automatically and not setting it outside the source ( i.e. in the client or interface )
The importance of category and attribute positioning is well known in the scientific environment, where they order / sequence you display and report the information must follow some specific rules, and most of them solve this using ordering/positioning fields on attributes/variables.
Not only a category/group of attributes before others, but even within the same category a specific attribute/variable must be placed before another one, and so on.
This because each attribute/variable/parameter has its own weight of importance and the way you report it has a strong impact on human readability and easy of use.
Well, I know the importance of this can vary a lot from business to business, but maintain this ordering logic from the client side costs a lot of efforts we do not have to pay in other applications.
Thanks in advance for your feedbacks, highly appreciated.
Here a use case.
An element template must be represented in that way:
Category AttributeName Yellow Volume Yellow Pressure Yellow Min Yellow Max Yellow Temperature Yellow Min Yellow Max Red Volume Red Pressure Red Min Red Max Red Temperature Red Min Red Max
As soon as you checkin the element will be visualized in the following "wrong" ( it does not respect the needed layout ) way:
Category AttributeName Red Pressure Red Max Red Min Red Temperature Red Max Red Min Red Volume Yellow Pressure Yellow Max Yellow Min Yellow Temperature Yellow Max Yellow Min Yellow
Is the behavior you are expecting described somewhere as a kind of industry standard or similar? Is there any resource that you can refer to?
Besides that I wouldn't know the behavior you expect is built in with the Asset Framework but Stephen Kwan can likely better answer this question.
If this is a common problem, there should be somebody who has been facing this already. I am still hoping for a comment from within the community of users.
7 of 7 people found this helpful
AF sorts by name because the sorting is done by SQL Server. I understand your needs and I can recall maybe a couple of customers requesting this feature. In their case, they want the asset hierarchy to resemble the physical arrangement of their assets - i.e. Asset_B is positioned before Asset_A in their plant so they want to see that same physical ordering in client tools such as PI System Explorer. We have not implemented this due to several concerns that we have. Let me elaborate on a couple of things that immediately come to mind.
- By adding a sort field, we would increase the size of the AF object. This may be small but having it on every attribute and in some of the industries that we serve, such as AMI, an AF database can have 1 billion attributes. Any increase in size would negatively affect performance in very large systems.
- When there are large number of objects to retrieve from SQL Server, we implement paging. If we had another sort field, we would need to first sort it before we can start doing paging, otherwise you would get very weird results from clients as the 10th page may have data that really belongs on the 1st page. This sorting + paging is very resource intensive and again negatively affect performance especially for large systems.
- Any implementation of a sort field would require all our clients to adopt it, e.g. Coresight, ProcessBook, etc.
Unfortunately the number of customers requiring a custom sort field is quite small and it's simply not very high on our priority list - both servers and clients.
As system integrator, I have been questioned by customers a couple of times about this ordering also. I have wanted this feature myself as well, but never brought this up to discussion and appreciate your explanation on the matter now.
However, not beeing an expert in SQL server or relational database performance in general, I have a doubt:
why is it ok for SQL Server ordering by name while expensive ordering by any other field? Isn't object's name one column the same way any other field is?
1 of 1 people found this helpful
I did not imply that it cannot be done . What I wanted to say was that this would increase complexity and negatively impact scalability. It also requires all our clients to support this so it's impactful to the entire PI System. Due to the relatively small number of requests that I have received, it has never been high priority to support this both on the server side and client side.
Thanks Steve for the clarification.
While I completely understand your concern , I'm with those that are looking forward to complete AF with this kind of basic functionalities we consider fundamental in such kind of applications.
To reply to Gregor, we are talking about standards in defining measures for analytical tests, or characteristics for Product Specifications and Recipes ( in AF we should have Instrument and Equipment Design Specification ).
All of them refers to an order/positioning field in the structure that is normally a simple integer, maintained by the app when you edit your set of records ( attributes/parameters/measures ) . It is not commonly set in all the results/element attributes , but only at the "attribute template" level, and a view links that order field to the other information so you don't have to create that field in the big data table. If you need it, you search through the view ( using JDBC/ODBC interfaces ).
From the client/reporting side this has a terrific positive effect.
As mentioned before, in the past ( starting more than 20 years ago ) we faced this issue in user groups meeting of many different application types ( LIMS, MES, PLMs, ERP ... ) and it was hard as today to explain why this is was very important feature until everybody were able to test the resulting benefits. It is the same logic of "what you type is what you get"
Again, as this ordering field is added only at attribute template level , it would have no impact in the huge collections, and for those using JDBC/ODBC a definition of a custom view would be enough to do the magic
Thanks a lot for your feedback.
What would you use as a client tool to visualize your data if such ordering is possible?
Well, first of all, PI System Explorer.
Then, for the advanced reporting it depends if the ordering is kept at template level or down to the snapshot, as we have a Web App to navigate through Instrument and Equipment Design Specification, down to real time data.
In the first case ( template level ) we are forced to use JDBC/ODBC with the view I mentioned before and , a simplify our Web application that communicates with PI with two interfaces
1) PI Web API , for simple queries and data maintenance operations
2) Our own SOAP that get the data in JSON or XML format via JDBC performed at the server side ( that's a very simple service )
In the second case, where the ordering will be implemented down to the element attribute details and in PI Web API, then we would use only the native PI Web API to communicate with PI.
Eventually also PI CoreSight would be a bit more readable for the users if the attributes are automatically sorted in the correct order, and even with PI DataLink you can build a single simple spreadsheet to visualize any kind of element data in the correct sequence disregarding from the template type.
Hi Steve! We approached this order problem on the client side in a previous project without a lot of work since it could be easily done by the developers. Having said that, if we receive the request in a predefined order, then that is one less thing we have to worry about. Order is AF related and best implemented at template level is what I feel. Andrea's requirement is a definite feature request and I am hoping your team can perform some testing to see if it negatively impacts with scale.
Order mattered in one of the T&D projects I worked recently. Just one-upping this request again!
As i slightly lean towards OSI's view, let me add my view that PSE is not a client tool. PSE is a tool for AF configuration purposes. If you need any functionality that has specific business rules driving the visualisation then build a custom client. We need a generic tool for the generic purpose of configuring the AF server. Yes, my client wants values to turn red if the SQC traits of an attribute suggest out-of-band, but i think it would be a bad idea for everyone to deal with this functionality as the majority does not require this.
This does point to a more generic issue that Coresight as the main visualisation platform does not allow us to do this very easy yet. Why don't we have a light-weight PSE in CoreSight for just these purposes?
1 of 1 people found this helpful
How about adding this to the PI Coresight feature suggestion box which was put into place by the PI Coresight team to collect feedback like yours?
Do you already have an idea how that could look like? What's the functionality you have in mind? Do you believe this could be done using PI Coresight Extensibility and if not would this be a topic for a community project, a HTML5 based light-weight administration client?