Most of the PI Data Archive information that is accessible from PI System Management tools is perfect for a relational database: PI Identities, PI Mappings, PI Point attributes, PI Message Logs, etc.

Moving all of this to an SQL Server database would make it easier for the PI Data Archive to communicate with:
• PI Asset Framework (which already uses SQL Server),
• PI OLEDB Enterprise (currently responsible for translating SQL queries to native PI requests),
• PI Builder (translates the PI file format to a relational database format anyways), and, most importantly,
• the user (users know relational databases, but they do not currently know how the PI Data Archive stores its information, so they are stuck with PI System Management Tools and its limitations)

The use of an SQL Server database can lead to a simpler, more transparent, more flexible PI Data Archive. There would be less "translation" code for OSIsoft to maintain and the user can write queries to the PI Data Archive more easily.

Most of the time, zero, span, and typical value are unused, cause confusion, and/or lead to easy but costly mistakes.

Typical value is probably the most useless PI Point attribute. It doesn't affect the PI system. It is just there for the user's reference. Why not a range of typical values? Why not calculate it dynamically based on actual data? Typical value is superseded by limit traits in PI Asset Framework, so there is no need to force a typical value on every PI Point.

Zero is mostly used for Float16 PI Points, which is probably rarely used these days. The concept of zero in cases other than Float16 is sufficiently covered by point types having a minimum possible value that they can store.

Arguments similar to the ones against zero can also be used for span, but span has an additional reason to disappear. Exception and compression deviation (E&CD), whether they are specified in engineering units (EU) or as a % of the span, are saved as a % of the span. This means that any edit to the span results in a change in the E&CDs when they are interpreted in EUs, which is an unexpected surprise for the PI administrator if they are used to thinking of E&CD in terms of EUs. After all, EUs are the default way to specify E&CD in PI System Management Tools, so why would anyone think that this is not what gets saved to the PI Data Archive? In cases where the span is increased, this can cause the E&CDs to be larger than intended, resulting in data loss. The mistake is too easy to make (I made it twice already), and it is too tempting to correct the span from its default value when another PI administrator asks why the span does not reflect the corresponding tag in the data source. Many PI Points do not need a span. Just remove it.

I realize that a point class without zero, span, or typical value would mean that the Float16 point type cannot be used and that E&CDs can only be specified and saved in terms of engineering units, but this "sacrifice" is actually very appropriate in a lot of cases.

OPC server is outputting data with the currency data type (VT_CY) and it needs to be stored in the float type.  As per the OPCtoCSV document, the OPCtoCSV tool/OPC interface invokes VariantChangeType in order to convert this currency value to it's string representation before PI receives it.

"Some OPC servers have property values that are type VT_CY. The VT_CY type is intended to represent monetary values. A VT_CY value is a fixed-point number with four digits after an implied decimal point that is scaled and stored as a 64-bit integer. When VariantChangeType converts a VT_CY value to string, the string representation is an integer. To account for the implied decimal point, divide the integer by 10000. That is, “123456” actually represents 12.3456 (using dot to indicate the decimal point), “123” represents 0.0123, and so forth. (p. 19)

So essentially, PI is receiving an integer value of the string type that is several orders of magnitude larger than the original.  He needs PI to first convert this value from a string to a float, and then scale it down by 1/10,000.  Typically, a conversion from currency to float would be done on the source before the data reaches PI, but his OPC vendor has prevented this.

As far as I know, the Data Archive is not capable of automatically converting and scaling this event before archiving it.  We tried setting a conversion factor to 0.0001 and changing the point type to float but then we started getting "Bad" values.  The only way I know to accomplish is to create a performance equation that will parse the string value (using Float()) and then scale the result by 1/10,000.  In fact, we did create a test performance equation and it did exactly what we needed it to.

For PI System Administrators, it would be nice to be able to easily get a list of all buffered or unbuffered points on the PI Data Archive.

Currently, a list of buffered points is possible to retrieve using 'piartool -bfs <id> -ptlist', but a comprehensive list would require iterating through all of the buffered sources.

Such functionality would be nice because it would allow administrators to easily identify which data sources need to be configured for buffering, or which data sources are possibly misconfigured for buffering. It would also be a quick thing to check for points which may potentially have data loss during server downtime/server maintenance tasks.

As a production supervisor, I would like to be able to convert historical data tags to future data tags so that I can more efficiently transition my production target tags from being something that I have to update every day, to something that I can update ahead of time. Currently my production target tags are historical data tags, meaning that I have to go in every morning and update the tag with today's production target. I'll be upgrading my PI Server soon, which will allow me to use the future data feature. If I could make these tags into future data tags, then I could start to enter in my production targets the day before, which would save me a lot of trouble.

Consider upgrading from 32-bit Unix time to 64-bit Unix time so that PI can support dates past January 19, 2038. Reasons:

1. This date is fast approaching as a future value. It is only 20 years away.

2. OSIsoft will need time to implement the 64-bit time stamps and convert all existing and supported PI Data Archives to use the 64-bit time stamps. At least a year of time will be used up for leeway.

3. Once 64-bit Unix time is implemented, then OSIsoft can exclude from training presentations the (very high) upper limit of supported time. This gives the user 1 less thing to worry about.

4. It gives 1 less thing for OSIsoft to have to remember for the future.