+31 88 52 25 000 Zandbreeweg 12, 7577 BZ Oldenzaal
Storing process data is very important for a lot of different reasons. For most industries it is a requirement to be able to show all production data for 5 to 10 years to a governing body. But other companies just need data to make their production more efficient. In any case, production data needs to be stored. But the data not only needs to be stored, it also needs to be accessible when needed, and it would be beneficial, if the data could be compared or associated with data from other machines in a factory.
For this reason, not only storing data, bu storing data centrally in a common database has become more important. There are many ways of storing data in a process or industrial automation environment, or even from a whole industrial site. Usually the control system manufacturer will have its own process data historian option, and an MES or ERP manufacturer will have their own. This is all okay, until you have a site with multiple control systems, so how would that work?
A historian is software that usually is based on a database engine, and has a front end and a driver set to interact with a particular control system or SCADA. examples of this are:
But there are also historian that are control system agnostic, and have standard drivers for multiple control systems. Examples of these are:
Even though the manufacturer made historians have all the information for their respective control system, it is possible to connect any other input to most historians. This can be done through standards like XML input, OPC UA, OPC DA and/or OPC AE.
It is also possible to use a database and create your own historian, this can be done with database engines like:
A custom solution will have to create a database on a database engine and create a driver set to connect input devices. These inputs have come a long way the last 5 years, with options like RestAPI, OPC UA, IEC61580 and other API’s now also available besides the standard drivers that are made by the control system manufacturers.
To get data into a historian, a data source must be read, and the data associated with that particular device (Tag) should be transferred with a state and time to the database. This is done by the scada system, in most of the control system manufacturer made historians. Most of those systems will read the data into a local (on the scada server residing) database, and then copy the data to the historian once every week or so. Other historians implement a driver to get the data from a PLC or a scada system and load it directly into the historian. Also a connection to an IED through IEC 61580 can be made this way, and data can be read directly through an IEC61580 driver from any Energy management device. Other drivers that can be implemented are OPC, XML, Modbus, Canbus, REST API for instance.
A database has to be maintained, and as to remain fast enough for querying. Also the database must be able to still run in the server memory, and should be capable of being back-upped. To have all these things, the historian database is usually cut into sections of time. So for instance 10 sections of 1 month are enabled on the historian server. these sections will be used in a cycle where if section 10 is completed, section 11 will have the hard disk space of section 1, and section 1 will be archived. This archiving can be to slower storage, or even a network hard disk. The reasoning being that we will probably not need to use that data a lot, and if we do need it, waiting for it will be okay. The data is still part of the database, but is physically somewhere else and so when the database needs it, it will load that data back from the slow storage. The sections can be archived completely though, and the database will disconnect them, and you will have to manually load them back if needed.
There are a couple of ways that the data from a historian can be used. If you are using a control system manufacturer historian, a connection with the SCADA or HMI system is usually made. So when, for instance, a trend is made of a value on the HMI, the historic data will automatically be read from the historian, if they are old enough to reside there. More importantly, the data can mostly be read through reports or a graphical user interface or dashboard. Examples of these user interfaces are:
Reporting can often be created from within these graphical environments. Another way to create a report of the data, like a batch report, or any type of operational report, is to use a reporting tool. Some reporting tools to consider are:
Are you interested in doing more with your data or reporting, and would you like to talk to us about solutions we can offer? Contact us at sales@iautomation.nl
iAUTOMATION is an automation specialist that focuses on industrial automation, IT and the links between these two fields. With many years of experience in the industrial automation and IT world, iAUTOMATION is a mature partner that will benefit you.
iAUTOMATION provides complete projects for the industrial automation world with a specialty in PCS 7 consultancy and engineering. But other systems are also known to us and can be implemented by iAUTOMATION.
With knowledge of virtualization, networks, domains and IT management, iAUTOMATION is also a very suitable partner for all your IT questions and projects. We will always assist you with great enthusiasm and knowledge in your projects, and try to relieve our customers by proactively and positively tackling your project.
