Register validation rules

The following validation rules apply to register data:

The Delta High or Low Limit rules calculate the absolute difference between each register read and the previous register read. These rules use historical data but not reference data. If the delta value is above or below the specified thresholds, these rules warn or fail.

Use these rules to help detect unusual consumption patterns or misreads of a meter.

These validation checks operate on the last register data that is currently saved or will be saved after the current import. Any data that will be eclipsed (written over) by the current import is not used in the comparison. The meter multiplier is applied to the delta value, and the result is compared to the threshold which is in the register's unit of measure.

These checks use the meter multiplier that is on the register channel when the read is validated. The checks automatically handle meter multiplier changes by checking at each register reading for the correct multiplier to use.

The Delta High or Low Limit Percent Difference Checks calculate the absolute percentage difference between each register read and the previous register read. These rules use historical data but not reference data. If the delta value is above or below the specified thresholds, these rules warn or fail.

Use these rules to help detect unusual consumption patterns or misreads of the meter.

These rules compute a percentage difference in the delta of the last register values using the following formula:

100.00 * Math.Abs((adjCurrentUsage - adjPreviousUsage) / (adjCurrentUsage))

In the above formula, adjusted current and previous usage are calculated. Adjusted current and previous usage is calculated as a difference real from the UTC time to the end time of current/previous register reading end time. These rules compare that result to the threshold.

The Delta High or Low Limit Ratio Percent Difference Checks calculate the absolute ratio percentage difference between each register read and the previous register read. These rules use historical data but not reference data. If the delta value is above or below the specified threshold, the rules warn or fail.

Use these rules to help detect unusual consumption patterns or misreads of the meter.

The Overflow Check detects register reads where the register value exceeds the allowed number of dials configured for the register. This rule does not use historical or reference data. This rule does not require any parameters. It fails any register read exceeding the number of dials allowed.

Use this rule to detect incorrect dial configurations for register channels. You can also use this to detect misreads of the meter.

The check marks the interval with an OVERFLOW status.

The Register Gap Check looks for register reads that should exist based on the register channel configuration in IEE, but that do not exist (missing register reads) or that have a value of zero (invalid register reads). This check always results in a FAIL if a register read is not present for the time of day that is specified in the rule.

Use this rule to find gaps in data, particularly if there are no interval channels configured for the meter. If estimation is enabled and a register estimation routine is enabled in the service point's estimation set, IEE attempts to create accurate estimated register reads to replace reads that failed the Register Gap Check.

For example, the following scenarios typically result in gaps:

  • A system that sends the data may lose a file.

  • A changed telephone number for which the paperwork has not yet been completed.

  • An intermittent communication issue may exist within a fixed network or AMI network.

Because data gaps prevent billing accuracy and can lead to lost revenue or disputes with customers, the causes of repeated occurrences in the same service point register channel should be pinpointed and resolved as quickly as possible. Gaps in register data can also affect the accuracy of scaling and use of the data set with other estimations.

The Register Gap Check can detect register gaps regardless of how data is imported: ARI, SRI/SRI-E, manual edit, or pick-up reads via MDUS. For both ARI importers and non-ARI importers such as SRIE or Manual Validation, the register gap check validation rule creates a MISSING register at the “Expected Time” specified in the validation rule. The main criterion is that it will only run against register channels that are linked to an interval channel via MeterRead ChannelSet. During import of intervals through SRIE, if the register gap check validation determines that there are missing registers in the “Expected Time” covered by the date range specified in the interval reads, it creates a MISSING register on the “Expected Time,” which is then marked as failed validation.

The Register Gap Check can be configured against an interval/register channel set. It cannot be configured against an interval channel. It can run in line with readings import, on schedule or manually triggered, via UI or API, or triggered by Validation Detection Processor (VDP).

It uses the Expected Time parameter and the time period to look for register reads that should exist, either in the reading payload or in the database. Only look for the end read (similar to what ARI does today).

For example, if Expected Time is set to 00:00,

  • For timespan Apr 25th 00:01 to Apr 26th 00:00, it will look for the Apr 26th 00:00 register.

    • Scenarios: In line validation for ARI import, or Daily recurring validation for SRI/SRI-E import.

  • For timespan Apr 25th 16:01 to Apr 26th 00:00, it will look for the Apr 26th 00:00 register.

    • Scenarios: In line validation for SRI/SRI-E import of 8 hours chunk of data.

  • For timespan Apr 25th 08:01 to Apr 25th 16:00, it will SKIP because the expected register is in the future.

    • Scenarios: In line validation for SRI/SRI-E import of 8 hours chunk of data.

  • For timespan Apr 25th 00:01 to Apr 30th 00:00, it will look for Apr 26th 00:00, Apr 27th 00:00, Apr 28th 00:00, Apr 29th 00:00, and Apr 30th 00:00 registers.

    • Scenarios: In line validation for Contingency Read or Gap Fill import of 5 days' worth of data.

  • For timespan Apr 1st 00:01 to May 1st 00:00, it will look for all midnight registers between Apr 2nd 00:00 & May 1st 00:00, inclusive.

    • Scenarios: Manual validation for a month billing period, following an ABE exception.

Register reads that are timestamped outside of the Expected Time parameter are not considered; for example, actual pick-up reads timestamped 14:35 (obtained when the field engineer goes on site) are left untouched. When register gaps are identified, validation fails.

Register gaps are marked as needing estimation, after which they can be estimated using register estimation.

Note: When the register gap check rule was introduced, the only importer that created register readings and added a “MISSING” status was AMI Reading Import (ARI). Updates to IEE version 10.1 included register gap checks detecting register gaps for non-ARI with a status of ESTNEEDED. Register gap check that detect register gaps with non-ARI can only be configured against an interval/register channel set. It cannot be configured against a standalone interval channel.

Although the register gap check rule is a register validation rule, it is triggered when a range of interval reads are being imported for an interval/register channel set. The rule uses the timespan of the interval reads being imported to look for register reads at the specified expected time.

The High Limit or Low Limit Checks compare the register reading values to high or low threshold parameters. These rules do not use any historical or reference data. If the value is above or below the specified thresholds, these rules warn or fail.

Use these rules to alert you to unusually high or low measurements. These rules are most relevant in the case of a register that measures demand to detect when the peak demand goes over the specified limit. You can also use these rules to detect other register values, such as temperature or the results of a TOU register formula.

These rules do not check the unit of measure first to determine if the check is relevant for the type of data being measured. Therefore, ensure that you establish thresholds in the register's unit of measure that correspond appropriately to the service point channels that are capturing the data.

Detects meter rollover and fails or warns as specified by the user. Meters that record register data usually have a specified number of dials, which determines the maximum value that can be recorded. The number of dials is specified on the Register Channel entity as an integer. The maximum reading that can be represented by a meter with a non-zero number of dials is just under 10^number of dials. For example, a meter with Number of Dials =2 can record just under 102 or 100, effectively, rolling over after it hits 99.

Example: A typical meter read sequence is [10, 56, 89, 12, 35]. In this example, the meter has rolled over from 89 to 12. The deltas between the reads specify the consumption between two register reads and must be modified when rollover occurs. It is usually the difference between two consecutive reads and in this example would be: [56-10, 89-56, 12-89, 35-12] = [46, 33, -77, 23]. The negative consumption is due to rollover of the meter. The actual consumption is obtained by adding the maximum value the meter can register to the negative consumption: -77 + 100, to get the actual consumption of 23.

IEE skips this rule in the following scenarios:

  • Formula channels

  • The number of dials is configured as zero

  • There is no previous reading to check against