|
|
| Historical Trending Organization and Strategy | |
|
This article deals with organizing your SCADA database for efficient archiving of historical data for the PLCs and RTUs on your SCADA system. Many SCADA systems are plagued with inefficient organization for system historical data that results in slow historical trend displays response times. A system that is overloaded with bloated historical database files may slow dramatically, or even halt operation. This article will outline some strategies that should help make your SCADA system manage historical database files as efficiently as possible.
Subjects Include:
|
| |
How many times you have attempted to display a very long historical trend for some of your data only to have your historian stall or take an excessive amount of time to display the data? The usual reason for poor historian performance is excessive historical database file size(s). Most system integrators deal with this by configuring the system to keep only the last 7-30 days worth of data. In some cases this strategy may be OK but the ability to view important trends over longer periods of time may be lost. I have found that implementing a strategy to organize the historical database can minimize the amount of data archived. This can be accomplished without the loss of transients or important trends in the data and should allow for retention of data for a much longer period of time.
|
| |
The best strategy I have found for organizing the SCADA historical database is following the rules below:
- KNOW YOUR DATA. Know what’s important to the end-user and make sure the historical is archived for those points. Also know what’s important to the maintenance technicians for the system and make sure the historical is archived for those points also.
- LEAVE THE HISTORICAL TREND TURNED OFF FOR THE REMAINING POINTS. If no one needs the data, exercise diligence to turn the point’s historical data collection to an "off" condition.
- USE DEAD BANDS to minimize the amount of data collected. However, it is important that you do not set the dead band so loose that important transients are not captured. Again it is important to know your data to determine which points are the points where important transients may occur.
- If your SCADA package has the ability to ARCHIVE SOME OF THE OLDER HISTORICAL, yet still make it available at runtime, take advantage of that feature. The smaller the set of actively managed and updated historical data, the faster the updates.
- Below is an example of how organizing your Historical database can make your SCADA historian more efficient.
|
| |
In this case the integrator had 10 analog points on a PLC for which a historical strategy should be developed. In the example below the poll rate for all the points is 1 poll/second and no deadbands are set for any of the points. We are assuming that it takes 10 bytes of storage in the database for each integer type point and 12 bytes storage for each real or floating point type. As you can see, with no deadbands set, the historical database files would quickly grow unmanaged to an excessive size.
|
| |
Assumes 10 bytes of storage in the database for each integer type point and
Assumes 12 bytes storage for each real or floating point type
| Point # | Type Data | Type of Number in PLC | Source of Data | # of samples saved/day | Dead band | Total bytes/day (uncompressed) |
| 1 | Process pressure in PSIG 0-1,500 | Integer
(16 Bit) | PLC I/O Analog Input | 86,400 | None | 860,400 |
| 2 | Process temp in °F 32-150 | Integer
16 Bit | PLC I/O Analog Input | 86,400 | None | 860,400 |
| 3 | Process pressure safety high setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 860,400 |
| 4 | Process pressure safety low setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 860,400 |
| 5 | Process temp safety high setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 860,400 |
| 6 | Process temp safety low setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 860,400 |
| 7 | Process flow rate in CFD 0-20,000 | Real
32 Bit | Internal value calculated by application in PLC | 86,400 | None | 1,036,800 |
| 8 | Process flow rate Alarm High Setting in CFD | Real
32 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 1,036,800 |
| 9 | Process flow rate Alarm Low Setting in CFD | Real
32 Bit | Internal alarm setpoint value in PLC | 86,400 | None | 1,036,800 |
| 10 | Fuel usage in CFD | Real
32 Bit | Internal value calculated by application in PLC | 86,400 | None | 1,036,800 |
| | Total | | | | | 9,309,600 |
|
| |
In this case the integrator used a historical strategy that turned off the historian for some points unless the points changed and set deadbands for other points. In the example below the poll rate remains unchanged for all the points and is 1 poll/second. We are assuming that it takes 10 bytes of storage in the database for each integer type point and 12 bytes storage for each real or floating point type. As you can see, by turning off some of the unnecessary points unless they change and employing deadbands on other points, the historical database files would grow much, much more slowly. For the 10 analog points in the example, we were able to save >99% by reducing the amount of data saved daily from 9.3mb to 2.3kb! Additionally, any transients on the measured points would be captured and recorded for analysis by operations and engineering personnel. Also, changes to setpoint type points are also captured and recorded.
|
| |
Assumes 10 bytes of storage in the database for each integer type point and
Assumes 12 bytes storage for each real or floating point type
| Point # | Type Data | Type of Number in PLC | Source of Data | # of samples saved /day | Dead band | Total bytes/ day (uncom-pressed) |
| 1 | Process pressure in PSIG 0-1,500 | Integer
16 Bit | PLC I/O Analog Input | 122 | 2 PSIG or min 1/hr | 1,220 |
| 2 | Process temp
in °F 32-150 | Integer
16 Bit | PLC I/O Analog Input | 37 | 1 °F or min 1/hr | 370 |
| 3 | Process pressure safety high setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 0 | Record only on change No changes | 0 |
| 4 | Process pressure safety low setting in PSIG | Integer
16 Bit | Internal alarm setpoint value in PLC | 0 | Record only on change No changes | 0 |
| 5 | Process temp safety high setting in °F | Integer
16 Bit | Internal alarm setpoint value in PLC | 0 | Record only on change No changes | 0 |
| 6 | Process temp safety low setting in °F | Integer
16 Bit | Internal alarm setpoint value in PLC | 1 | Record only on change 1 change | 10 |
| 7 | Process flow rate in CFD
0-20,000 | Real
32 Bit | Internal value calculated by application in PLC | 60 | 10 CFD or min 1/hr | 720 |
| 8 | Process flow rate Alarm High Setting in CFD | Real
32 Bit | Internal alarm setpoint value in PLC | 1 | Record only on change 1 change | 12 |
| 9 | Process flow rate Alarm Low Setting in CFD | Real
32 Bit | Internal alarm setpoint value in PLC | 0 | Record only on change
No changes | 0 |
| 10 | Fuel usage in CFD | Real
32 Bit | Internal value calculated by application in PLC | 1 | Record only 1 sample/day | 12 |
| | Totals | | | | | 2,344 |
|
| |
Adopting a specification to define a historical data strategy could be one solution that may improve system historical database and historian performance. Additionally, adopting a historical data strategy helps ensure that important events, transients, and trends are recorded. If your system integrators adheres to a spec such as the below when developing your HMI and SCADA application databases, data historian performance should not suffer due to excessive database size. The below example assumes that your HMI or SCADA application allows sufficient control over the frequency and what triggers the recording of an historical sample.
The specification is an example only, and it will be necessary to define the allowable data deadbands for your process data types. You should review the historical recording configuration each process data point with knowledgeable operations, support, and engineering personnel to make a determination on the settings for historical recording including the deadbands.
The specification should also work with a specification to minimize the number of scans to collect all necessary data from your PLC or RTU system. You may find an example for that that specification here.
|
| |
| Type Historical Data | Recommended record interval | Notes |
| Discrete Input card status | Record all changes | Selective exceptions will be made for some points that we do not need to track |
| Discrete Output card status | Record all changes | Selective exceptions will be made for some points that we do not need to track |
| Discrete internals from RLL logic | Record only changes necessary for HMI/SCADA application | Selective exceptions made for a few discrete internals that we need to track |
| Discrete internals from PLC diagnostic registers | Record only changes necessary for HMI/SCADA application | Selective exceptions made for a few discrete diagnostic internals that we do not need to track |
| Analog Input card values | Use deadbands for each process data type | Deadbands need to be applied on a point by point basis to ensure important changes and transients to the process are captured |
| Analog Output card values | Use deadbands or record only on change | Deadbands need to be applied on a point by point basis to ensure important changes and transients to the controlled element are captured |
| Analog internals from RLL logic - alarm setting | Record alarm settings only on change | When operators make alarm limit changes, record the changes |
| Analog internals from RLL logic- setpoint values | Record setpoints values only on change | When operators make setpoint changes, record the changes |
| Analog internals from PLC diagnostic registers | Record diagnostic registers only on change | These are usually error codes so when they change, record them. |
|
| |
NetSCADA is designed to minimize the effort to implement an efficient historical archiving strategy and has special features that make organizing historical data easy and efficient. NetSCADA allows each poll of a PLC or RTU to be configured individually for the interval for recording historical data for points collected by that poll. This allows high poll rates without bloating the size of the historical database. Additionally, deadband controls on each historical point allow the historical data for those points to capture important trends and transients. NetSCADA is designed to allow the integrator to implement a historical point by simply setting the historical property for the discrete or analog point to true. Click here to see more on how to set up NetSCADA for efficient historical data archiving.
|
| Additional Resources | |  | |
|
|
