Enforce strict temporal and energy consistency rules for MeterValues within a transaction #1962
Description
Currently, there is no strict validation ensuring that MeterValue timestamps and energy register values remain consistent with the transaction lifecycle and with each other.
1. Transaction time window
For a given transaction:
- A
MeterValues.timestampmust be greater than or equal toStartTransaction.timestamp. - A
MeterValues.timestampmust be less than or equal toStopTransaction.timestamp(if the transaction is already stopped).
In other words, a MeterValues must occur during the transaction window, including boundary timestamps.
MeterValues occurring before the start or after the stop must be marked as suspect.
2. Energy register vs transaction boundaries
For Energy.Active.Import.Register:
- The value must be greater than or equal to meterStart.
- The value must be less than or equal to meterStop (if already known).
Energy values outside the [meterStart, meterStop] interval must be marked as suspect.
3. Energy monotonicity within the transaction
For Energy.Active.Import.Register, values must be monotonic over time:
- A value must not be smaller than the previous MeterValues value (ordered by timestamp).
- A value must not be greater than the next MeterValues value (if already stored and comparable).
This ensures the energy register is monotonic non-decreasing over time within the transaction.
Equal values are allowed (e.g. same timestamp or no consumption between samples).
4. Late or out-of-order MeterValues
- A MeterValues received after the transaction has already been stopped (i.e., StopTransaction already processed) must be marked as suspect.
- A MeterValues that arrives and chronologically inserts itself before an already stored MeterValues must be marked as suspect.
Such messages must not alter previously validated transaction data.
A simular logic could be done with meter values: should not be send before start (timestamp) or after stop.
And meter values should be progressive during the transaction.