Applications in which sensors provide data are growing exponentially, allowing manufacturers to refine their operations and enhance their efficiencies. The more sensors show they can do, the more they are asked to do. But the sensor is just the front end of the process. If you can't aggregate the data, analyze trends, and cull actionable information, sensors' contribution is all for not. That's where plant data historians come in.
Strong Suits
The architecture of the plant data historians is tailored for certain types of applications and optimized for time-series data, which means that they excel at answering questions such as: "What was today's hourly unit production standard deviation?"
These repositories are the perfect choice when you must capture data from sensors and other real-time systems because they use manufacturing standards, such as OPC, that facilitate communications. With plant data historians, you can streamline implementation by using standard interfaces.
In addition, these systems require little or no management or creation of data schema, triggers, stored procedures, or views. You can usually install and configure a plant data historian quickly without specialized services, such as custom coding or scripting for the installation.
Plant data historians are also designed to survive the harshness of the production floor and feature the ability to continue capturing and storing data even if the main data store is unavailable. Another feature typically found in a plant data historian is the ability to compress data, reducing the amount of drive space required. When capturing time-series data rapidly (with a re-read rate of less than 5 s) for several thousand sensors, a plant data historian may work best.
No Repository Is an Island
While plant data historians can meet some of your needs well some of the time, they probably can't meet all of them all of the time. For complete coverage, you might consider combining this system with a relational database and other analysis tools (e.g., Excel).