Difference between attribute properties in PSE

Indexed versus Configuration Item

Both are for static AFAttributes, that is with a data reference of None. The values for the static attributes are stored in the AFDatabase meaning thats is it stored in the SQL Server's PIFD database.

Indexed means AF will create an index for fast searches. Not much to add there.

Configuration Item is denoting an AFAttribute so important that it is critical to the design of the AFElement. If you ever change it, when it should remain constant, then the state of the AFElement is saved in what is called Element Versioning. The original element probably has a Date of 1/1/1970. If you change the value of the Configuration Item, a new element version is created for that element on the date of check-in.

Let's consider an example that is not process related at all. It's more of inventory, which is a bad fit for PI and AF but may help in this example.

Imagine a car lot of cars from different manufacturers. Each car would be an AFElement and technical details about the car would be AFAttributes such as Color, Number of Doors, Cylinders, Style (SUV, Sedan, Coupe) along with general details like Manufacturer, Model, Year, etc.

General details like Manufacturer, Model, or Year are good candidates to be Indexed. Doesn't mean they should be, but rather they could be, so if you want to search on all BMW's it could be fast.

One could say that all those properties are indeed static and would never change EXCEPT there is an exception: the Color. On rare occasions, someone could paint the car a different color. So the Color is a candidate for a Configuration Item. If it ever changes, then a new element version is created.

In the HELP for Configuration Item, they mention serial numbers as likely candidates. This is true. Imagine a large piece of equipment including a certain Controller with a given serial number. Over time, components wear out and need to be replaced. If you replace that Controller with a new one, and get a new serial number, then you would want element versioning to know which is being referenced when you do a historical look back.

Excluded and Hidden

In the early days, the AFElement was a digital twin of pieces of equipment. In most training and other presentations, this usually involved very simplified types of equipment. As more and more customers adopted AF and were creating their databases, we witnessed more and more complex designs. And if your company happened to support multiple other customers in your AFDatabase, there were more and more instances of where a given AFElementTemplate was unsatisifactory for all of your own customers' needs.

Excluded was introduced as a way of saying, I have Customer A and he wants to see Attributes X, Y, and Z, but I also have Customer B who only wants to see Attribute X. So in your template design, you would exclude attributes Y and Z. As far as Customer B is concerned, they do not exist. For the element instances of Customer A, you would un-check Excluded property on attributes Y and Z so that Customer A can still see them.

Excluded omits those attributes from being returned in searches. Granted a database admin could see it in PI System Explorer but AF treats the attribute as not having a data reference. This can help performance for Customer B because AF won't try to fetch anything at all for attributes Y and Z. There is also a trickle down effect: if you have Formulas or Analyses that reference the excluded attributes, then a failed calculation occurs since no data is available for anything excluded.

Hidden means the AFAttributes do exist, and can be used in searches. They also have their data references applicable. While PSE can sow these as Hidden, if you make your own client apps, then viewer would not see these, but they still exist, and they still have data. Formulas and Analyses referencing hidden attributes will still function.

Thank you Rick for all this explanation.