Sự khác biệt giữa DataLogger và Historian

Ngày đăng: 02:53:56 26-04-2020

Kepware Product Showdown: DataLogger vs. Local Historian Plug-In

Posted by Aron Semle

Process data is important: it’s the fuel for process improvement. As such, there are many tools to record, analyze, and report on process data. KEPServerEX provides two of these tools with the DataLogger and Local Historian plug-ins.

SQL

Kepware’s DataLogger Plug-In pushes process data into any ODBC-compliant data source. It is primarily used with relational databases, which are often referred to as SQL databases in our space.

SQL databases have been around since the 1970s, and were designed to model relationships between data sets. For example, take a work order that requires part numbers from inventory; these parts were purchased on a purchase order. SQL can store and provide access to these relationships in a fast, consistent, and reliable manner.

SQL is currently the dominant data storage technology used by IT, and has been for decades. As such, there are many tools that interact with SQL, which makes it a very flexible solution.

Historians

Kepware’s Local Historian Plug-In stores time series data and provides access to it via OPC Historical Data Access (HDA), which is an open standard for historical data.

Historians have been around as long as SQL, and were born from the need to collect, store, and analyze high-resolution data streams coming from the plant floor. Unlike SQL, this data is non-relational; for example, a Historian may record the temperature of a furnace every 100 milliseconds.

Historians are primarily used by Operations for troubleshooting and optimization. Often more proprietary than SQL, Historians also come equipped with various tools to provide access to and analyze the data.

Why Both?

The need to model and store relationships and the need to store high velocity non-relational data are different. If the industry could have created a single solution to do both, they would have—but given system constraints, no one could. As a result, we have SQL databases and Historians. So when do you use one versus the other?

When to Use SQL?

SQL is a great solution for Overall Equipment Effectiveness (OEE) applications, which aggregate process data around availability, performance, and quality to produce OEE metrics. This information is typically polled on one second to one minute frequency with a limited number of tags per machine. SQL can easily be used to record and aggregate these metrics, and make them available to web-based and other clients.

SQL is also ideal for recording batch process data and storing set points. In these applications, the rate of data is fairly slow (such as minutes, hours, and so forth). SQL can easily map all the data for a batch into a single table, which keeps the data together and makes it easy to query based on batch attributes.

These applications have common qualities. First, the tag count is relatively low. OEE, for example, often consists of 5 to 10 tags per machine. The data resolution is on the order of seconds, minutes, and hours, and is also more complex than a simple value, quality, and timestamp. Batch data, for example, contains many attributes and measurements.

When to Use a Historian?

Historians are a great solution for troubleshooting or fine-tuning equipment (which requires high-resolution data that can be trended and reviewed by engineers—often millisecond data from multiple variables that can span hours, days, or months). Historians can easily store this data in a minimal amount of space and provide quick access to it for trending tools.

Historians are also ideal for data aggregation. For example, if you need the standard deviation for a boiler temperature reading, historians can collect the raw data and report aggregates in near real-time. HMI, alarming, and maintenance systems can then use these aggregates.

Those same systems also require technology that can store and retrieve large amounts of time series data quickly. This data also needs to be close to the equipment to make real-time adjustments to the process and provide aggregates or chunks of data to higher-level systems. This is the ideal fit for a historian.

Note that historians range from large, centralized, enterprise systems to distributed solutions closer to the edge.

DataLogger vs. Local Historian Plug-In

So use DataLogger if you need to get data into a SQL database. If you’re unsure if SQL is the right technology, consider the volume and velocity of your data. SQL is a great option for low to moderate data volumes. There are many low-cost analysis products available from Excel on up.

Use the Local Historian Plug-In if you’re looking to store large volumes of high-resolution data for troubleshooting and analysis, and you need this data close to the equipment.

Get Started

Have questions on which solution best fits your process data needs? Leave a comment in the space provided below, or contact a Kepware representative by emailing sales@kepware.com or by calling +1 207-775-1660 x208. We'd like to hear from you!

https://www.kepware.com/en-us/blog/2014/kepware-product-showdown-datalogger-vs-local-his/

iStock_000007679700XSmall
DataLogger_driver_diagram
Local_Historian