Elhub-data utan aktörsroll

Det är inte åtkomsten som är problemet

Ett bolag som vill ha mätvärden från Elhub, men som varken är nätbolag eller elleverantör för mätpunkterna, har en väg in. Rollkoden heter AG, tredje part, och den bygger på samtycke från slutanvändaren: bestämda mätpunkter, bestämda datatyper, en bestämd period. Samtycket kan återkallas, och då upphör åtkomsten.

Den mekanismen finns på plats och fungerar. Ändå är det inte ovanligt att ett bolag i denna situation får sina data genom en EDI-plattform, alltså genom ytterligare ett led, år 2026.

Det är värt att förstå varför, eftersom skälet inte är det man skulle tro.

Vilka det gäller

Den typiska aktören är en kraftproducent. Den vill ha två saker tillbaka från Elhub: sin egen förbrukning och sin egen produktion. Bådadera finns där, och bådadera är tillgängliga med rätt samtycke.

Detsamma gäller industri och andra näringar med ett reellt behov av mätvärden från egna anläggningar, utan att de för den skull har någon roll i kraftmarknaden.

Det gemensamma är inte branschen. Det är att ingen av dem har ett kundinformationssystem som byggdes med Elhub-integration som en del av konceptet, eftersom de aldrig var målgruppen för ett sådant system.

Systemet har tidsserier, men ingen navkoppling

Här ligger det egentliga jobbet, och det är lätt att underskatta.

Systemet som ska använda data har som regel precis det som behövs för att lagra dem. Det har tidsserier. Det kan hålla förbrukning och produktion per mätpunkt över tid och göra något vettigt med dem. Det saknar ingen datamodell.

Det som saknas är ett sätt att ta emot. Systemet byggdes för att läsa ett filformat som fanns långt före nationella nav, och det är fortfarande det format det förstår. Ofta MSCONS eller UTILTS.

Gapet är alltså inte åtkomst mot ingen åtkomst. Det är XML mot EDIFACT.

Översättaren som blev kvar

Detta förklarar något som annars ser ut som tröghet: varför EDI-plattformarna inte försvann från den norska marknaden när Elhub togs i drift 2019.

När navet togs i bruk hade mycket få av de dominerande kundsystemen stöd för det. En EDI-plattform kunde däremot hämta från Elhubs utgående kö och leverera vidare som MSCONS eller UTILTS, i det format mottagarsystemet redan läste. Ingen på mottagarsidan behövde ändra något.

I takt med att systemleverantörerna byggde Elhub-stöd själva föll behovet bort för dem som fick det. För alla andra gjorde det inte det. Översättarrollen är densamma i dag som då: konvertera från navets format till det format mottagaren förstår.

Det är ett fullt reellt jobb. Det är bara inte det jobb EDI ursprungligen byggdes för.

Elhub är inte den enda motparten

En sak till gör bilden mindre enkel än "behöver du fortfarande EDI mot Elhub".

För flera aktörer går samma meddelandelager också till andra ställen. Bud till elbörsen kan skickas och tas emot genom det. Underlag till eSett, som gör balansavräkningen för Norge, Sverige och Finland, kan skickas i det format eSett tar emot.

Det betyder att frågan "täcker en Elhub-integration hela mitt behov" har olika svar från bolag till bolag. För några är Elhub hela bilden. För andra är Elhub en av tre motparter, och då försvinner inte meddelandelagret genom att lösa den ena.

Vad som avgör om behovet försvinner

Två frågor avgör det, och ingen av dem handlar om Elhub.

Har ditt system fått Elhub-stöd, eller kommer det att få det? Om din leverantör har byggt det är översättaren överflödig för den delen. Om inte måste någon fortsätta att översätta, vem det än är.

Hur många motparter har du? Ett nav är en integration. Ett nav plus en börs plus en balansavräknare är tre, och de delar inte nödvändigtvis format.

Svaren skiljer sig från bolag till bolag, och det är hela poängen. Det finns inget enda svar på om EDI-lagret fortfarande behövs i Norge, eftersom frågan aldrig gällde landet, utan systemlandskapet i varje enskilt hus.