FAQ: Historian configuration general recommendations
1. Recommendation on hardware:
| Storage | Memory | CPU |
| - SSD (Solid-State Drive). - Disk space capacity as detailed in the attached Excel sheet outputs. | -
RAM required to load the archive data is about 4 times greater the size of
the respective ARX files. E.g., reading 250MB of .ARX files needs around 1GB
RAM. - Recommended maximum SPEICHER setting is 4000000 (size of the ARX files) (it requires ~16GBs in RAM when displaying all data in a Extended trend screen). Setting higher values, computer specs must be very high. When reserving such amount of RAM make sure there is enough free memory left while Service Engine is running. | -
High-end CPU specs. - Adequate temperature room/cabinet & server/CPU cooling system. |
2. Archive recording configuration
In general, there are no hard restrictions for the number of variables, ARX files and data sampling in archives. Instead, we recommend first to clearly define data scope/requirements and fill the Excel sheet attached before proceeding with Historian configuration:
- Data sampling frequency (granularity) and deadbands.
- Storage time & type.
- Data usage.
We also suggest following the guidelines in the documentation page: Service Engine & Engineering Studio / Historian / Archiving concept (+ / Best Practice).
Practical example:
i. Data requirements:
- Variables: 10 analog values with deadband [-0.1,0.1].
- Records: On-change*.
- Usage: 1 hour trend of 10 analog values should be displayed.
- Storage: Data should be local for 1 month (2,592,000 seconds).
- Long-term data storage: SQL database.
ii. Concept:
Raw estimation for .ARX files:
Archive File Header = 69 Bytes; Variable Header = 48 Bytes; Variable float size = 24 Bytes
Archive File Header = 69 Bytes; Variable Header = 48 Bytes; Variable float size = 24 Bytes
.ARX file size in MB = (Archiv File Header + Variable Header * No. of Variables + Variable float size * No. of Variables * No. of values per .ARX file) /1024/1024
Example: (69 Bytes + 48 Bytes * 10 + 24 Bytes * 10 * 864000) /1024 /1024 = ~19.78 MB
Example: (69 Bytes + 48 Bytes * 10 + 24 Bytes * 10 * 864000) /1024 /1024 = ~19.78 MB
Few notes:
- *Records on-change: It is not possible to forecast values change rate during operation. In this case, System Engineer should try to come with the best prediction possible (E.g., ~Scanning cycle = 1 second). Signal/historian hysteresis must be used to discard values in the deadband.
- The Saving cycle chosen is 1 day (86,400 seconds). Although the data displayed in the trend screen is one hour only (per requirement) and archive capsules of 1 hour could be used, this configuration would produce many small ARX files considering the local storage duration time and the low number of values recorded (size=0.82MB;#files=721). In this case, increasing the saving cycle to 1 day (as in figure above) finds a good balance between the number and the size of the ARX files (<100 MB) (size=19.78MB;#files=31).
- The same procedure should be done to all archives in the Historian.
iii. Configuration:
- Variables: Signal hysteresis: Negative/Positive for signal = 0.1.
- Archive: Scanning cycle = On-change; Saving cycle = 1 day; Recording cycle = 1 hour; Storage duration = 1 month.
3. Display curves in the Extended Trend
There are no hard limits for the number of curves displayed in an Extended Trend screen. However, the number of points can be displayed in a curve are limited to the number of pixels in width of the Extended Trend screen "Diagram window" element.
As a rule of thumb: A trend can only display as much data as its width in pixels. Loading a trend for a longer period from a base archive with high-density, requires loading large amounts of data that cannot be displayed in detail.
For example, displaying a variable that is recorded every second in a trend for one month period would require 2,592,000* pixels, while the number of pixels in the diagram window is limited, e.g., 1,400. In this case, there is no sense trying to represent the raw data in the trend, so that automatic aggregation should be used.
*Number of points for one month = 60 seconds x 60 minutes x 24 hours x 30 days = 2,592,000!
For long term periods of data (e.g., one week), disable automatic Refresh of the Extended Trend screen (set 'Refresh rate' = 0) as this demands high CPU processing and has no benefit for the Operator, e.g., there is no visible change in the curves by refreshing the trend every few seconds.
4. Best practices to configure or when using large amount of data in Historian:
- Use variables deadbands to prevent analog data changing their value frequently and with insignificant values.
o Configure signal hysteresis: Improves general Service Engine performance. Avoids transfer values in the deadband from zenon drivers to Service Engine for further processing (e.g., Historian).
o Configure archive hysteresis: This feature does not have an impact in Service Engine performance in general as it only affects Historian module but can further avoid recording unnecessary value changes.
- Use of aggregated archives to avoid reading raw data when long time-spans are displayed and use the feature aggregation archives for automatic selection in Service Engine.
- Use Swinging Door algorithm (only with Historian 360).
- Create separate archives for binary (Boolean) and numerical variables.
o Data aggregation and Swinging Door algorithm have high benefit for archives with analog values but no benefit for Boolean values.
- Grouping variables in one archive that are displayed together in one trend benefits the trend loading time.
- High frequency on-change historical data can be moved to a central location (read-back folder from a shared network folder) or to an external database to reduce the amount of disk space needed locally.
- ARX files size should not be larger than 100 MB.
- For Cyclic archives + SQL historian evacuation: In zenon 11/12, use an archive Saving Cycle = 50 x Scanning Cycle. This makes best usage of the insert bulk statements. Previous zenon versions do not benefit of this functionality (insert bulk statements).
- Avoid opening multiple Extended trend screens in the same Service Engine client.
- Start of Service Engine servers in 64 bit and as service (without user interface).
- Start add-ons like Process Gateways on dedicated client PCs.
If you have any question for this FAQ please leave a feedback.
If you would like to know more about Historian please contact your local COPA-DATA Representative.
Related Articles
Archive configuration for best SQL evacuation performance
The time required to evacuate data to a database increases linearly with the number of insert SQL statements. In earlier zenon versions, recorded values were evacuated to the target database sequentially using single-insert statements. From zenon 11 ...Redundant License Configuration
Starting from zenon version 8.00 it is possible to share each license over the CodeMeter network. This allows you to have a dedicated license server. The license server can be any PC or virtual machine which runs CodeMeter. One license for two ...FAQ: How can I browse an OPC UA Server using the zenon OPC UA Client Driver?
Go to Drivers > New Driver Create a Driver of Type "OPC UA Client Driver" Open the Driver Configuration Go to "Connections" Create a new Connection Enter your Discovery URL Enter your Server URL manually or click the 3 dots to browse the Discovery ...Historian Editor tree doesn't update aggregation archive overview after change.
Summary In the Editor Archives tree if you want add new variable via edit archive configuration screen aggregation archive are not up to date with new configuration. DescriptionIn the Editor Archives tree if you want add new variable via edit archive ...FAQ: What are the different zenon drivers modes?
All Service Engine process-driven drivers can run in four different modes, mainly allowing you to switch between active hardware connection and values simulation. While "Hardware" allows establishing a connection to the target device(s) and its the ...