Elhub-data uden aktørrolle

Det er ikke adgangen, der er problemet

Et selskab, der vil have måleværdier fra Elhub, men som hverken er netselskab eller elleverandør for målepunkterne, har en vej ind. Rollekoden hedder AG, tredjepart, og den bygger på samtykke fra slutbrugeren: bestemte målepunkter, bestemte datatyper, en bestemt periode. Samtykket kan trækkes tilbage, og så ophører adgangen.

Den mekanisme er på plads og virker. Alligevel er det ikke ualmindeligt, at et selskab i denne situation får sine data gennem en EDI-platform, altså gennem endnu et led, i 2026.

Det er værd at forstå hvorfor, for grunden er ikke den, man skulle tro.

Hvem det gælder

Den typiske aktør er en kraftproducent. Den vil have to ting tilbage fra Elhub: sit eget forbrug og sin egen produktion. Begge dele findes der, og begge dele er tilgængelige med det rette samtykke.

Det samme gælder industri og andre brancher med et reelt behov for måleværdier fra egne anlæg, uden at de af den grund har nogen rolle i kraftmarkedet.

Fællestrækket er ikke branchen. Det er, at ingen af dem har et kundeinformationssystem, der blev bygget med Elhub-integration som en del af konceptet, fordi de aldrig var målgruppen for et sådant system.

Systemet har tidsserier, men ingen navforbindelse

Her ligger det egentlige arbejde, og det er let at undervurdere.

Systemet, der skal bruge data, har som regel præcis det, der skal til for at gemme dem. Det har tidsserier. Det kan holde forbrug og produktion per målepunkt over tid og gøre noget fornuftigt med dem. Det mangler ikke en datamodel.

Det, det mangler, er en måde at modtage på. Systemet blev bygget til at læse et filformat, der fandtes længe før nationale nav, og som stadig er det format, det forstår. Ofte MSCONS eller UTILTS.

Gabet er altså ikke adgang mod ingen adgang. Det er XML mod EDIFACT.

Oversætteren, der blev stående

Det forklarer noget, der ellers ligner træghed: hvorfor EDI-platformene ikke forsvandt fra det norske marked, da Elhub kom i drift i 2019.

Da navet blev sat i drift, havde meget få af de dominerende kundesystemer understøttelse af det. En EDI-platform kunne derimod hente fra Elhubs udgående kø og levere videre som MSCONS eller UTILTS, altså i det format, modtagersystemet allerede læste. Ingen på modtagersiden skulle ændre noget.

Efterhånden som systemleverandørerne selv byggede Elhub-understøttelse, faldt behovet bort for dem, der fik den. For alle andre gjorde det ikke. Oversætterrollen er den samme i dag som dengang: konvertere fra navets format til det format, modtageren forstår.

Det er et fuldt reelt arbejde. Det er bare ikke det arbejde, EDI oprindeligt blev lavet til.

Elhub er ikke den eneste modpart

Én ting til gør billedet mindre enkelt end "har du stadig brug for EDI mod Elhub".

For flere aktører går det samme meddelelseslag også andre steder hen. Bud til elbørsen kan sendes og modtages gennem det. Grundlag til eSett, som laver balanceafregningen for Norge, Sverige og Finland, kan sendes i det format, eSett modtager.

Det betyder, at spørgsmålet "dækker en Elhub-integration hele mit behov" har forskelligt svar fra selskab til selskab. For nogle er Elhub hele billedet. For andre er Elhub én af tre modparter, og så forsvinder meddelelseslaget ikke ved at løse den ene.

Hvad der afgør, om behovet forsvinder

To spørgsmål afgør det, og ingen af dem handler om Elhub.

Har dit system fået Elhub-understøttelse, eller kommer det til at få det? Har din leverandør bygget den, er oversætteren overflødig for den del. Hvis ikke, må nogen blive ved med at oversætte, uanset hvem det er.

Hvor mange modparter har du? Ét nav er én integration. Et nav plus en børs plus en balanceafregner er tre, og de deler ikke nødvendigvis format.

Svarene er forskellige fra selskab til selskab, og det er hele pointen. Der findes ikke ét svar på, om EDI-laget stadig er nødvendigt i Norge, for spørgsmålet handlede aldrig om landet, men om systemlandskabet i hvert enkelt hus.