What is a Historian?

An off-the-cuff answer is someone that records history. We’re talking about control system historians, but that’s not an altogether incorrect answer. A historian is a tool that records data from the control system. But like so many other things in the manufacturing realm, that’s not really sufficient. There are many types of historians that end-user manufacturers can use. Here are some of the ways that we can distinguish them:

BY PLATFORM – Historian applications can run in PLCs, they can run in Servers, they can run in modules on the network. Each platform has some advantages and disadvantages for the end-user.

BY DATA COLLECTION MEDIA – Historian applications can collect data in lots of ways. Prior to the deployment of large flash memories, some historians used (and still use) USB drives. People walked around grabbing these periodically and offloaded their data at some server station. Many of these historians now use microSD cards, which can provide cheap storage of up to 2 Terabytes. In some applications, people collect the microSD cards, but often that data is just uploaded to a server over Ethernet.

BY FUNCTIONALITY – simple historians just collect data, hold it and make it available for transfer to some other device. Others implement database functionality within the historian and can provide graphs, charts and predictive analysis on the data. The right choice for an end-user depends on what they plan to do with the data. In most cases, they’ll want to combine it with other data and do post-analysis where they process the data after the fact. In many cases, the data just needs to be moved to some long-term storage media where it can remain for months or years.

BY CONNECTIVITY – Most historians now have some Ethernet capability (EtherNet/IP, Profinet IO), but that wasn’t often the case in earlier times when storage and connectivity were more expensive. Now with Ethernet as the connectivity standard, the communications protocol becomes very important. The receiver must have some way of knowing the data is coming and what it is. Just the ability to send data over Ethernet is not enough. There are several ways that a historian can organize the data to make it easily acceptable to a receiver:

• JSON File – A JSON file is a structured ASCII file that self-identifies the data in the file. It is a common mechanism for communicating data in the IT world. Java Script inherently supports the direct movement of JSON data into its program memory.
• XML File – An XML (eXtensible Markup Language) is a more verbose way of structuring a set of ASCII data. XML was the predecessor to JSON and provides the same self-identification of each data item.
• CSV File – A CSV file is a comma-delimited file (meaning the fields are separated by commas) where data values are delivered as ASCII Strings separated by commas and terminated by a CR (carriage return). The first line of the CSV file generally contains header data that identifies data in each record (line) of the file.

A historian must transmit these files to the receiver at some frequency. There are various mechanisms to do that using all sorts of languages and utilities. A common tool for the purpose is FTP. A historian can periodically FTP a file to a receiver. In other cases, a historian might send the file in its entirety using a protocol that supports that, such as OPC UA. Or when it doesn’t, it could send chunks using any one of an assortment of protocols. In the end, it depends on what is supported by the receiver. The historian needs to be extremely flexible to handle many different application scenarios.

The answer to “what is a control system historian?” is very varied and really depends on what the end-user wants it to be.