This site uses Cookies. By using the site you accept our usage of Cookies. Dismiss More info

Historian for plant data

Historian for plant data

Picture historian Historian

What a historian does

A historian is recording data over time. The time period can be long - very long, for many years. Later this can be used for forensic applications. Additionally a fast overview over the plant activities can be done. The frondend for these are trend views. OEE applications always are basing on data recorded with a historian.

Data con be stored into two destinations.

  • Into memory.

    Memory recordings are often operated as a ring. This means that a small amount of recorded data is available. This allows you to determine run times, or briefly check what has run in the last quarter of an hour. Memory data is not saved permanently. If the machine is switched off with the historian, the data is no longer available after the restart.

  • Permanently into files.

    Recordings on hard disks are permanent, they require a physical storage medium. This can be done on locally installed disks, or it can be disks on the network. You can also use any cloud storage like Dropbox, Google Drive, Azure or AWS for this purpose, a file access must be provided only. With hard disk data, you can make evaluations even after a long time. If damage has occurred, this data could be used to determine the cause of the damage. An example are tachographs or the black box in airplanes. Many settings are available for the files. So in regular time intervals in each case a new file can be used. Older files can then be moved to a separate medium, for example.

Of course, for one variable both are possible at the same time like a storage ring for short term data and long term logging to files.

A variable in the historian can be a number. This will certainly be a frequent use.
Variables - often numbers, are fixed or floating point values. They can also be texts.
Fields are possible, an example can be a list of numbers.
Complex things like structures that contain several different numbers are also possible.
For complex data, it makes sense to determine the trigger - the value whose change triggers an entry with a time stamp in the historian - independently. independently. The easiest way to do this is with the product PLC Engine. There you can additionally also conversions can be made. This may be necessary if an analog floating point value is to be processed in the historian. Almost all signal generators have a noise, the value changes constantly around a very small value. A limit check prevents the too frequent data writing. In technology this is also called deadband.
Complex data can be extensive. If this is used in the historian, the hardware should be correspondingly powerful. Complex data structures cannot be displayed so easily, e.g. in trend curves. The advantage is that a time synchronous data entry can contain many things.

The historian can also be operated on a different system than the one on which the OPC Server is working. This can go so far that several OPC Servers write data to one Historian. Only a certain variable in the historian can be filled by writing from one from one data source. Reading, i.e. using the history - can be done by several sources. Each variable in the historian always has a data source.
This becomes important when the OPC data sources work on small embedded systems. These systems rarely have data storage, hard disks practically never. In this case, it is a good idea to run the historian on a PC or in a cloud. Several stations then share it.
The data traffic from an OPC server to the historian during recording is small. Only new changed data is transferred. The load on the networks is very low.
Even if an OPC server now requests history data, the data rate remains rather small. This is because the calculations of the data are done in the historian. All data are not simply given to the OPC server, which then filters and calculates, but the historian takes over this work. The storage formats of the historian are defined in such a way that hardly any calculations are necessary. The original data is directly accessed via index files recording with created index files. This guarantees also on simple inexpensive computers an immediate data output.

The software provides the history functions to all systems that are able to use it. These are:

  • OPC UA
    OPC UA knows history functions. For all variables specified in the historian configuration the corresponding functions are offered. An UA client can specify in which grid the history data is retrieved. The historian maps these requests to the really available data and delivers them.
    Important: For security reasons alone, data can only be added and read. Modification or deletion of data is not allowed.
  • BACnet
    Several BACnet elements like the trend elements access the data. Of course, this must be specified accordingly in the Historian configuration.
    As with OPC UA, the data can only be added and read. Security comes first.
  • REST API for trend graphs
    A REST interface is intended for requirements in the web area, but it can be used anywhere if a program supports REST.
    There are rules for REST, but no fixed standard. Tani provide a REST API interface. This interface remains stable over time. Even strong advancements in Historian will continue to execute existing requests.
    A simple web element is provided in sources that displays a trend view. The communication to the historian uses the REST interface. You can use this trend element as you like and also share it.
    The trend element also provides a good diagnostic of the data in the historian.
    As in the existing Web Toolkit, there are two variants for the trend element: for web servers that use PHP and for the Node.js system.

Simply recording all data at all times makes little sense. Thousands of data are often used in plants. Thus, the variables that provide a history function need to be configured.

The variables that the historian processes originate from a process, often from an OPC Server. In the OPC Server a variable often has a long path. For easier management the historian uses its own - often more meaningful - names. You define the assignment yourself, a 1:1 assignment is possible. Determining the respective variable is as usual easy - with browsing. There are many options for recording: Time grid, when to take a new file and much more. A simple wizard when setting up uses default values, which can also be adjusted later at any time if Bedauf.
. In addition to the data that a trend view needs, you can have other values calculated directly at the recording time. These are minimum and Maximum values, the average une one more. If that is not enough, you have in the PLC Engine extensive conversion and normalization functions.

TTani values openness. The file formats used by the historian are located in this description file.. Thus the data can be processed by own programs without using the REST interface or the complete OPC server. Many of the files that make up a variable are only written to at the end of the file by the historian at runtime. This facilitates access, Reading is always possible.

Historian
Memory 1G RAM
Historian Memory 1G RAM
• 1 024 MiB Historian Memory
• 10 Historian File Variables

Licensed features:
• History
105-0001-01 V2
Addon Historian
Memory 25G RAM
Addon Historian Memory 25G RAM
• 25 600 MiB Historian Memory
• 40 Historian File Variables
105-0002-01 V2
Disc 5 Variables
Addon Historian Disc 5 Variables
• 5 Historian File Variables
105-0011-01 V2
Disc 10 Variables
Addon Historian Disc 10 Variables
• 10 Historian File Variables
105-0012-01 V2
Disc 20 Variables
Addon Historian Disc 20 Variables
• 20 Historian File Variables
105-0013-01 V2
Disc 40 Variables
Addon Historian Disc 40 Variables
• 40 Historian File Variables
105-0014-01 V2

Software protection with dongle

Historian technical data
Historian file formats
Historian REST interface

Products overview

Download trial

Without a license, the communication products work as a trial version for three days after each launch.