zenon Runtime, by default, stores process data on the hard disk. This is true for a standalone zenon project, as well as zenon Runtime server(s) in a zenon network. This data consists of alarms, events, Historian, reports, exports, etc. Although zenon uses highly efficient native file formats by default, the amount of data recorded and accumulated by zenon Runtime can vary greatly depending on the project’s configuration.
The purpose of this series of blog posts is to provide an overview of zenon Runtime data storage and how it can be effectively managed to ensure optimal disk space utilization and performance over a typical HMI/SCADA lifecycle of more than 10 years.
Why does zenon Runtime save data?
A zenon HMI/SCADA system not only handles real-time current values coming from the PLCs, IEDs, etc., but is capable of maintaining records for historical reporting, analysis and compliance. zenon Runtime offers ready-to-use modules which are capable of reading from these historical files and presenting the data in a variety of forms. For example, one such module is Extended Trend. The zenon Historian can be configured to record measurement values for the last three months. These are saved onto the hard disk by zenon, and the Extended Trend module knows exactly how to read these files to present the user with a trend diagram in the Runtime.
Where does zenon Runtime save data, and what data is saved?
Runtime Folder: The zenon Runtime Folder contains both the compiled zenon Runtime Files and the zenon Runtime Data. The Runtime folder is commonly named with the zenon project name.
Runtime Files: are the compiled project files created by the zenon Editor. The zenon Editor’s Output Window will provide details about the compilation of the zenon project, but it is not necessary for you to become familiar with the different types of Runtime files and what they mean. The important thing to know is that your entire zenon project is compiled by the zenon Editor into a set of Runtime Files which the zenon Runtime can interpret.
The compiled zenon Runtime Files are usually quite moderate in size and are generally not a concern in terms of hard disk usage. Once a zenon project is live, the Runtime Files do not grow or expand, unless the zenon system is expanded intentionally by an engineer. The path where the Runtime files exist on the target system is user-definable. However, the Runtime files are consistently in a folder called RT, for example: C:\zenonRT\Project_SAS_1023\RT.
Runtime Data: is the data that is created and managed by zenon Runtime. The Alarm Message List, Chronological Event List, and Historian are some of the modules that actually store Runtime Data on the hard disk. Depending on the zenon project configuration, the Runtime Data can increase and use more disk space over the months and years of live zenon operation. The path where the Runtime data exists on the target system is user-configurable, but usually relative to the RT folder, in its own directory with the hostname of the PC e.g. C:\zenonRT\Project_SAS_1023\ServerA.
The following are some of the most common file types that zenon Runtime uses
.AML – The format written for a historical alarm file. To maintain historical alarm records, by default zenon will automatically create one alarm file per day. The naming format for these files is the letter “A”, followed by YYMMDD, for example: A151109.AML. The size of the alarm files depends directly on how many alarms are configured within the zenon project, and the alarm occurrence frequency.
.CEL – The format written for a historical event file. To maintain a historical record of chronological events, by default zenon will automatically create one event file per day. The naming format for these files is the letter “C”, followed by YYMMDD, for example: C150309.CEL. The size of the event files depends directly on how many events are configured within the zenon project, and the event occurrence frequency.
.ARX – The default and native format written for an archive file saved by the historian module. The size of these files is dependent on multiple factors such as the historian recording type (cyclic, on change, event triggered), the amount of variables recorded, and how often there are changes. The naming format for these files is the short name of the archive, followed by a timestamp of when the archive file was closed, in the format YYMMTThhmmss.