Validering, estimering og redigering: hva VEE betyr for målerdata.

En vannmåler rapporterer 1 842 m³ klokken 03:00 og 1 849 m³ klokken 04:00. For en husholdning er det 7 000 liter på en time. Er det et rørbrudd, en måler med klokkefeil der to dagers forbruk havnet i én time, eller en avlesning som kom to ganger med ulike tidsstempler?

Tre flere tilfeller fra daglig drift:

• En målerstand går ned med 40 liter i løpet av natten. En ødelagt måler, eller reell tilbakestrømning i et bygg med trykktank?
• En avlesning mangler den dagen tariffen endres. Fakturaen trenger en verdi for akkurat det tidspunktet.
• En montør korrigerer en verdi etter et målerbytte. Månedstotalen i rapporten viser fortsatt det gamle tallet.

Hver måleravlesning er en påstand, ikke et faktum. VEE, kort for validering, estimering og redigering, er regelsettet som gjør påstander om til data som kan faktureres, analyseres og forsvares. Begrepet kommer fra strømmåling, der det har vært en standard del av målerdatahåndtering i tjue år. Det gjelder like mye for vann, varme og gass, og det dukker nå opp i de fleste anbud på en målerdataplattform.

Hva EU-reglene sier

De europeiske reglene for målerdata er skrevet for strøm, men de gjør et skille som ethvert vannverk bør kopiere.

Direktiv (EU) 2019/944, artikkel 20 bokstav a, skiller mellom to typer data. Validerte historiske forbruksdata skal gjøres tilgjengelige for sluttkunder på forespørsel. Ikke-validerte data i nær sanntid kan også gjøres tilgjengelige gjennom et standardisert grensesnitt, for å støtte forbruksstyring og andre tjenester. Direktivet sier ikke hvordan validering skal gjøres. Det sier at de to typene data må kunne skilles fra hverandre.

Gjennomføringsforordning (EU) 2023/1162 setter interoperabilitetsreglene for tilgang til disse dataene. Definisjonen av validerte historiske måledata er verdt å lese to ganger: data samlet inn fra en måler, «eller supplert med erstatningsverdier som fastsettes på annen måte når måleren ikke er tilgjengelig». Med andre ord: estimering er per definisjon en del av validerte data, så lenge erstatningsverdiene er fastsatt etter en regel og kan skilles fra målte verdier.

IEC 61968-9:2024, grensesnittstandarden i Common Information Model (CIM) for måleravlesning og styring, gir datamodellen. En måleravlesning i en CIM-melding bærer en avlesningskvalitet sammen med verdien: om den ble målt, estimert eller redigert, og hvorfor. Standarden er primært skrevet for strømdistribusjon og sier selv at den også kan brukes på gass- og vannmåling.

Til sammen sier disse tre ting. Hold validerte og ikke-validerte data fra hverandre. Tillat erstatningsverdier, men merk dem. Bær kvaliteten på en avlesning sammen med avlesningen, ikke i et eget regneark.

Validering: å avgjøre hva som kan stoles på

Validering kjøres når en avlesning kommer inn. Den endrer ikke verdien. Den setter en status, og hvis avlesningen stryker, en begrunnelse. Kontrollene som betyr noe i praksis:

To av disse krever skjønn heller enn en regel.

Et synkende telleverk er ikke alltid en feil. Tilbakestrømning gjennom en måler er reelt, og en regel som avviser enhver nedgang vil kaste ekte data. Det bedre mønsteret er å flagge avlesningen, beholde den, og la mønsteret over flere avlesninger avgjøre.

En spiss avhenger av måleren. 7 000 liter på en time er umulig for en DN15 husholdningsmåler og rutine for en DN100 innløpsmåler. Tersklene må følge målerstørrelsen og helst målerens egen historikk. Ett fast tall for alle målere gir enten falske alarmer på store målere eller blindsoner på små.

To designregler skiller god validering fra dekorativ validering:

1. En avvist avlesning må ikke inngå i grunnlaget for den neste. Hvis en spiss avvises, men fortsatt teller med i nyere historikk, utvides båndet og neste spiss slipper gjennom.
2. Validering må ikke feile åpent. Hvis historikkoppslaget er utilgjengelig, bør avlesningen lagres som ikke validert ennå, ikke som gyldig. Stillhet er ikke godkjenning.

Estimering: å fylle et hull etter en regel

Estimering gir en verdi der ingenting ble målt. Det vanlige behovet er et faktureringstidspunkt: slutten av måneden, dagen tariffen endret seg, dagen leietakeren flyttet ut. Måleren rapporterte dagen før og dagen etter, og fakturaen trenger verdien imellom.

De vanlige strategiene, i økende grad av ambisjon:

• Videreføre forrige verdi. Forbruket i hullet er null. Enkelt, konservativt og feil for alt som faktisk var i gang.
• Gjenta forrige forbruk. Anta samme forbruk som i forrige periode av samme lengde.
• Interpolere. En rett linje mellom siste avlesning før hullet og første etter. Riktig standardvalg når begge ender finnes.
• Profilbasert. Bruk samme periode i fjor, eller en sammenlignbar gruppe målere. Nødvendig når hullet er langt.

Hvilken strategi som er riktig avhenger av bruken. For en vannfaktura er interpolering mellom to faktiske avlesninger vanligvis rettferdig for begge parter. For en lekkasjealarm bør ingen estimater brukes i det hele tatt.

Tre regler gjelder uansett strategi. Estimatet er flagget som et estimat overalt der det vises, også på fakturaen og i API-et. Det erstattes av den faktiske verdien hvis én kommer senere, og erstatningen registreres. Og det er reverserbart: et estimat som viser seg å være feil, kan trekkes tilbake uten å redigere en database for hånd.

Merk forskjellen mellom å estimere en avlesning og å estimere en avledet størrelse. En sonevannbalanse som fordeler en utdatert innløpsavlesning over dager, estimerer et volum, ikke en målerverdi. Den bør flagges på samme måte, men trenger ikke skrive noe tilbake til målerens historikk.

Redigering: når et menneske endrer en verdi

Redigering er delen de fleste systemer gjør feil, fordi den ser harmløs ut. En operatør åpner en graf, ser et feil punkt og sletter det. Dataene er nå renere, og beviset på at det noen gang var et problem, er borte.

Reglene for en forsvarlig redigering:

• Slett aldri. Merk avlesningen som ugyldig og behold verdien. En slettet avlesning kan ikke revideres og kan ikke gjenopprettes.
• Behold originalen. En redigering oppretter en ny verdi med kilde «redigert». Den målte verdien forblir tilgjengelig.
• Registrer hvem, når og hvorfor. Bruker, tidsstempel, gammel verdi, ny verdi og en begrunnelse. Begrunnelsen er ikke valgfri.
• Gi hver avlesning en kilde. Målt av enheten, lagt inn manuelt, importert fra fil, estimert, redigert. Disse må kunne skilles fra hverandre år senere.
• Krev godkjenning for faktureringsrelevante redigeringer. Den som foreslår en korreksjon og den som godkjenner den, bør ikke måtte være samme person.
• Før endringen videre. En korrigert avlesning for forrige tirsdag må nå forrige tirsdags dagstotal, månedsrapporten og hver eksport som allerede har sendt den gamle verdien. Et system som bare oppdaterer avlesningen, har ikke fullført redigeringen.

Det siste punktet er der de stille feilene bor. Totaler beregnes ofte én gang, om natten, og bygges aldri på nytt. En korreksjon gjort en uke senere ligger i avlesningstabellen mens hver rapport bygget på totalene forblir feil.

Én definisjon av «brukbar», overalt

En plattform leverer typisk avlesninger til et dusin konsumenter: fakturering, alarmer, forbruksanalyser, vanntapsberegninger, kundeportaler, et offentlig API, eksporter til tredjeparter. Hver av dem må svare på samme spørsmål: hvilke avlesninger teller?

Hvis hver konsument svarer hver for seg, svarer de ulikt. Alarmer ignorerer avlesninger som det offentlige API-et gladelig leverer. Vannbalansen inkluderer en avvist spiss som grafen skjuler. En kunde ser ett tall i portalen og et annet gjennom API-et, fordi den ene brukte målerens offset og den andre ikke.

Løsningen er like mye organisatorisk som teknisk: én regel for hva en brukbar avlesning er, skrevet ned og brukt av hver konsument. CIM-avlesningskvaliteten er et fornuftig sted å forankre den regelen, fordi den bærer statusen sammen med avlesningen i stedet for å stole på at hver konsument husker filteret.

Hva dere bør spørre en leverandør om

Hvis VEE står i anbudet deres, eller dere vil vite om plattformen dere allerede har gjør det, skiller disse spørsmålene svarene:

1. Bærer hver avlesning en valideringsstatus og en begrunnelse, eller bare en verdi?
2. Hvilke kontroller kjøres ved mottak, og kan tersklene konfigureres per målerstørrelse eller per prosjekt?
3. Påvirker en avvist avlesning valideringen av den neste?
4. Hva skjer med en avlesning når validering ikke kan kjøres?
5. Kan en avlesning slettes permanent? Av hvem, og beholdes verdien?
6. Hvilke estimeringsstrategier finnes, flagges estimater på fakturaen, og kan et estimat trekkes tilbake?
7. Hvor er revisjonssporet for en redigering, og registrerer det gammel verdi, ny verdi, bruker og begrunnelse?
8. Når en tidligere avlesning korrigeres, hvilke totaler, rapporter og eksporter bygges på nytt?
9. Bruker API-et, eksportene og brukergrensesnittet samme gyldighetsregel og samme offset?

En leverandør som kan vise revisjonssporet for én redigert avlesning, fra ende til ende, har vanligvis svart på de fleste av de andre spørsmålene også.

Slik gjør Divako det

Divako validerer hver avlesning ved mottak og lagrer resultatet sammen med avlesningen: et gyldighetsflagg og begrunnelsen for at en avlesning ble avvist, synlig for operatøren og med videre i dataene som forlater plattformen. Avlesninger fra vann-, varme-, strøm- og gassmålere går gjennom de samme kontrollene uansett hvilket nett som leverte dem.

Estimering og stipulering av faktureringsavlesninger ligger i Divako Settlement. Den foreslår en erstatningsverdi ut fra strategiene over, registrerer kilde og begrunnelse, holder faktureringsrelevante korreksjoner til godkjenning, og kan rulle en stipulert verdi tilbake når den faktiske avlesningen kommer.

Den samme gyldighetsstatusen mater vanntapsstyring, der en avvist innløpsavlesning betyr mer enn de fleste: i en ovenfra-og-ned vannbalanse regnes kundemålerfeil og datahåndteringsfeil som tilsynelatende tap, og hver av dem forskyver lekkasjeanslaget.

Kilder

• Direktiv (EU) 2019/944, artikkel 20 bokstav a: validerte historiske og ikke-validerte forbruksdata i nær sanntid.
• Kommisjonens gjennomføringsforordning (EU) 2023/1162: interoperabilitetskrav og prosedyrer for tilgang til måle- og forbruksdata; definisjoner i artikkel 2.
• IEC 61968-9:2024: Enterprise business function interfaces for utility operations, Part 9: Interfaces for meter reading and control.