Process Historian Software Vendors
Automated Results has developed a core expertise in process historians (OSIsoft PI), which are used in industrial and manufacturing environments to record and report on historical data over time, which can include process and product information, as well as network performance and IT monitoring. Automated Results provides historian application and database consulting, support, integration, user and administrator training, custom application development, and reporting services.
What is a Process Historian?
A Process Historian is a specialized database for recording real-time process data like:
- Analog Readings: temperature, pressure, flowrates, levels, weights
- Digital Readings: valves, limit switches, motors on/off, discreet level sensors
- Product Info: product id, batch id, material id, raw material lot id
- Quality Info: process and product limits, cusum limits
- Alarm Info: out of limits signals, return to normal signals
- Aggregate data: average, standard deviation, cpk, moving average
A specialized database (ex. non-relational) is required when the combination of the:
- Number of data points being recorded (3000 points)
- Rate of data recording (every 5 seconds)
- Length of time data is retained in the database (1 year)
exceeds a certain level. At that point, the retreival time from a relational database can be excessive (ex. 30 seconds to ask for the last month's data on 1 data point).
What is a compressible database?
There are a number of process historians on the market, some of them use a relational database for their data storage and some have developed a hybrid database structure. These hybrids typically have a compression mechanism that throws away data points that the software can predict. As a simple example, if a valve is off for 8 hours (a value of zero) and the data is sampled every 5 seconds, then a relational database will store 5760 data values (5 sec over 8 hrs; 12 values/min * 60 min/hr * 8 hr), while a compressible database might only store 2 values. The compression algorithm is actually smarter than simply rejecting the same value, it will not store values within a user-defined, data point specific deadband. Thus if a temperature reading is only useful to 1/2 of a degree, the deadband could be anything less than 1/2 degree. The compression technique typically used is call 'box-car compression'.
To put compression in perspective, we did a benchmark comparison and found that a relational database (ex. MS SQL Server) would store 1 gb / month of data similar to the categories listed above, but a compressible database (ex. OSIsoft PI) would store only 150 mb / month for 1000 data points at a 5 second sampling rate. If you extrapolate that for a plant with only 10,000 data points, you would need to be able to handle 10 gb / month in a relational database or 120 gb / year. When you consider that there are facilities with 60,000 or 150,000 data points, it is easy to see that the compressible database is the only choice.
The data access time is what the end-user will notices, but this data typically needs to be backed up to tape and/or to CDROM for archival storage. Even 10 gb / month of data will tax tape drive, but remember a relational database backup file size will keep increasing month after month.
How do you plan for the long-term?
Thus for small isolated process historian applications (ex. 50-100 points) the less expensive process historian that uses a relational database is a great choice. However, as your sampling rate, data point count, and retention time increase, one must be careful to select a historian that can handle your data load for the full retention time. In addition, most process historian applications lend themselves to handle the entire site or an entire company's needs and not operate as an isolated entity. For example, a company that implements a historian in the powerhouse (ex. supply steam, brine, water, etc) and the production facility could gain tremendous benefit from having the both sets of data available to correlate process and product problem to problems with upstream facilities (ex. insufficient steam to meet peak demand). Thus, when deciding on a process historian, one must consider all the sites, facilities, and data that might go into the historian and select one that can handle the long-term number of data points along with the data sampling rate and retention period.
If after analyzing your needs, you still have small needs, then you can save significant dollars by purchasing a less expensive historian, but please choose wisely!