Din mätdataYour Metering Data
En praktisk guide till den mätdata ni redan har — från det som redan finns i SCADA till ett användningsfall någon faktiskt vill finansiera. A practical guide to the metering data you already have — from what's sitting in SCADA today to a use case someone will actually fund.
Det här är den första i en annan sorts guide än DSO-resan eller FSP-resan: inte en serie beslut om huruvida flexibilitet är värt att satsa på, utan en praktisk väg som börjar i något ni redan har. Den fungerar oavsett om ni bestämt er om flexibilitet än.
1 · Vad mäter ni redan?
Innan något annat, gör en inventering av tre lager ni sannolikt redan har, i den ordning de vanligtvis är enklast att använda:
SCADA eller motsvarande. De flesta svenska elnätsföretag har redan en driftcentralshistorik med mer data än man tror: oftast i ojämn upplösning, kanske med luckor ingen kartlagt, men värdefull och redan tillgänglig.
Kundens avräkningsmätning. Lagstadgat heltäckande, timvis eller bättre sedan utrullningen av smarta mätare. Kan ni inte snabbt få upp nätstationsdata går det oftast att bygga en rimlig modell enbart på avräkningsmätningen.
Undermätning. Rogowski-spolar och liknande ström-/spänningsgivare, billiga jämfört med SCADA-klassad instrumentering, för riktad komplettering där de två första lagren lämnar ett specifikt gap.
De flesta svenska elnätsföretag utgår från samma utmaningar vad gäller mätdata. En DNV GL-studie från 2018 för Energiforsk pekar ut det övervägande problemet som en närmast total avsaknad av information om nätet mellan fördelningsstationens utgående fack och kundanslutningspunkterna nedströms: inte brist på transformatorer eller kablar, utan brist på information om hur den kedjan faktiskt beter sig. Ett fälttest hos Vattenfall visade det konkret: av 14 nätstationer med installerad energimätning uppförde sig bara 8 som dokumenterat, en visade negativa förluster (den dokumenterade topologin var helt enkelt fel), och fem visade obegripligt höga förluster ingen kunde förklara. Sex av de 14 pekade mot ett fel eller ett dataintegritetsproblem som elnätsföretaget inte visste att man hade.
Samma rapport ger också ett användbart, elnätsföretags-validerat sätt att definiera var ni står:
De flesta svenska nätstationer ligger på brons. Utvecklingspotentialen, enligt samma rapport, ligger främst i mät- och kommunikationssystem, inte i primärutrustning: ungefär 70 % av komponenterna i svenska lokal- och regionnät är äldre än 20 år och 37 % äldre än 38 år. Det är arvet från en ojämn utbyggnad för 40–50 år sedan, och därför varierar det så mycket från station till station hur svårt det är att bygga på i efterhand. Inget av detta är ett skäl att vänta, utan snarare en fingervisning att börja med det som redan är digitalt, vilket för de flesta medelstora elnätsföretag är avräknings- och SCADA-lagren, inte nätstationslagret.
Den här guiden är avgränsad till medelstora elnätsföretag och uppåt (ungefär 10 000 kunder eller fler), vilket är omkring 77 av Sveriges 146 lokalnätsföretag men täcker uppskattningsvis 94 % av Sveriges elnätskunder. Är ni mindre än så är det inte säkert att bygga detta internt är rätt väg. Att låta en licensierad tredje part sköta det åt er är ett gångbart alternativ värt att läsa om först.
2 · Vad är det första värt att göra med den?
Fyra potentiella användningar dyker upp gång på gång för samma underliggande data:
- Lastprognoser: se Din lastprognos
- Nätanalys och planering: förluster, topologivalidering, underlag till nätutvecklingsplanen
- Flexibilitet: upphandling, aktivering, avräkning
- Prediktivt underhåll: att fånga komponentfel innan de blir avbrott
Bara en av dessa behöver motivera att bygga den infrastruktur resten av guiden beskriver. De andra tre följer med gratis när den väl finns, eftersom insamling, kvalitet och åtkomst (steg 3 till 5) är gemensam infrastruktur oavsett vilket användningsfall som betalar för den först.
De elnätsföretag som faktiskt gör detta bekräftar båda halvorna av påståendet. I en enkät från 2022 bland 34 svenska elnätsföretag svarade 85 % att de redan samlar in data de inte använder; råmaterialet till steg 1 är sällan begränsningen. Men 56 % svarade också att det finns data de skulle vilja samla in men inte kan, och angav hinder som gammal utrustning, otillräckliga system och kommunikationsvägar, IT-säkerhet, samt brist på kompetens och tid. En svarande sammanfattade ekonomin rakt av: “det finns möjlighet att samla in mer data från de nya mätarna, men just nu finns inget värde i att samla in allt, i förhållande till kostnaden för att validera och lagra den.”
En genomförbarhetskontroll är också på sin plats: stödjer den data ni inventerade i steg 1 faktiskt användningsfallet, i den upplösning och latens det kräver? En kartläggning av 50 svenska elnätsföretag fann att 28 % saknar dokumenterad prognosmetodik helt och i stället förlitar sig på erfarenhetsbaserad bedömning: en rimlig utgångspunkt, men inte en som ett business case kan byggas på utan att först verifiera att datan underifrån håller.
Verktyget Vad räcker mätdatan till? kan användas för just det: besvara några frågor om upplösning, latens och kvalitet, och se vilka av de fyra användningsfallen ovan er data faktiskt kan stödja idag.
3 · Kan ni få ut den?
Insamling bör läsa från en replika eller ett schemalagt uttag. Fråga aldrig ut från produktionssystemet direkt. Valet av latensklass avgör arkitekturen mer än något annat: ett dagligt batchuttag och ett flöde i nästan realtid är helt olika byggen, och att välja fel här kan bli ett dyrt misstag, inte en detalj att fixa senare.
Sveriges 168 elnätsföretag kör heterogena legacysystem, för det mesta med standardprotokoll på nätlagret: IEC 61850 för stationsautomation, IEC 60870-5-104 (Europas motsvarighet till DNP3) för kommunikation mellan driftcentral och station. Men leverantörernas egna tillägg ovanpå standarderna skapar konkreta kostnader vid byten och migreringar. Därför räcker inte “vi använder båda samma standard” som svar på “kommer det här att fungera ihop.” Flexibility Communication Protocols dokumenterar samma gap ett lager högre upp, där E.ON och Ellevio båda använder OpenADR för villkorade avtal men implementerar det tillräckligt olika att Energiföretagen fick publicera ett tillägg som förklarar skillnaden.
Den kommersiella fällan sitter på affärssidan av det här steget, inte den tekniska: exportgränssnitt är ofta en separat licensierad modul, och kostnaden brukar bara komma fram efter att någon redan sagt till ledningen “det är ju bara en export.” Få kostnaden för uttaget bekräftad skriftligt innan den antas in i en budget.
Ei:s egen tillsyn har redan hittat samma mönster (“gränssnittet finns, men inte informationen som behövs för att använda det”) ett lager närmare kunden: en riktad tillsyn 2025 fann att elnätsföretag inte publicerade vilka dataprotokoll deras egna öppna kundgränssnitt faktiskt stödjer, vilket undergrävde ett gränssnitt som formellt var regelefterlevande men i praktiken oanvändbart för tredje part. Kontrollera det på era egna exportgränssnitt innan någon längre ner i kedjan upptäcker det när det redan har blivit dyrt.
Varför man inte bör invänta den nationella datahubben
Den planerade nationella datainfrastrukturen är Datahanteringsverktyget (DHV), ibland diskuterat som det framtida Flexibilitetsinformationssystemet (FIS). Det är ett förslag som väntas från Ei i september 2026, och enligt vår uppskattning innebär ett bygge på fyra till sex år från ett regeringsbeslut som väntas 2027 att det tas i drift först i början av 2030-talet. Det kan vara frestande att se den tidslinjen som ett skäl att vänta: varför bygga en intern infrastruktur nu, om en nationell är på väg?
Det är snarare tvärtom. DHV kommer att kräva precis den här datan, i standardiserad form, från varje elnätsföretag. Har man inte rett ut sina egna lager för insamling, kvalitet och åtkomst när DHV kommer riskerar man att bli sen och fast i något inkompatibelt, istället för att ha en fungerande infrastruktur med kända luckor. Att bygga nu med fokus på senare exportmöjligheter är bättre än att vänta.
4 · Kan ni lita på den?
Här ligger det mesta av arbetet, och enligt Ei:s egen granskning är det här svenska elnätsföretag just nu har mest att rätta till.
Tidssynkronisering. Klockdrift, sommartidsövergångar och tidszonshantering kan stöka till en dataserie utan att någonsin ge ett felmeddelande.
Kartläggning av luckor. Känn er faktiska andel saknade värden innan någon nedströms antar att den är noll.
Topologikoppling. Koppla varje avläsning till en avgång eller station. Ett tal utan en hemvist i infrastrukturen är inte användbar data, hur exakta värdena än är.
Ei:s tillsyn 2022–2023 av tio elnätsföretags mätefterlevnad fann att 6 av 10 överskred den lagstadgade gränsen för saknade mätvärden; i två av de sex fallen var huvudorsaken att ett mätarbyte fastnade mitt i utrullningen och bröt insamlingskedjan tills elnätsföretaget inte hade något annat val än att beräkna. Ei upptäckte att vissa elnätsföretag fyller luckan med en helt platt profil för mindre kunder istället för kundens faktiska förbrukningsprofil: en sträcka av “intervalldata” utan någon riktig tidsinformation. Mätföreskrifterna kräver att beräknade värden markeras som beräknade, men en datakedja som tappar markeringen kan inte skilja sträckan från en riktig avläsning. En modell eller en baseline som tränats på den slutar inte fungera på något märkbart sätt, den blir bara fel utan att någon har upptäckt det.
Delmålet här är en dokumenterad kvalitetsbaseline med en känd andel luckor (inte noll luckor, en känd andel), så att den som använder datan nedströms vet vad de faktiskt arbetar med. Det här knyter också an till guiden för lastprognoser: prognosförmåga kan inte ärligt utvärderas mot data vars egen kvalitet inte först kartlagts.
Animationen nedan följer en lucka från mätaren till prognosen.
5 · Kan något annat nå den?
Utforma lagring och ett API efter ett datautbyte som faktiskt finns, inte ett påhittat schema. Sverige har redan två dokumenterade uppsättningar värda att bygga mot direkt: NODES och SWITCH publicerar båda fullständiga API-specifikationer, och ett elnätsföretag som formar sin export efter det en befintlig marknadsplats redan förväntar sig slipper ett andra integrationsprojekt senare. Ellevios eget fall är den konkreta versionen av detta: efter att ha byggt ett prognosverktyg från sin egen SCADA-data integrerade man det verktyget via API med både SWITCH och NODES för att kunna använda prognosen till flexibilitetsupphandling, inklusive det dataklassificeringsarbete som krävdes för att säkerställa att enskild kundinformation inte exponerades i processen.
Åtkomstmodellen är ett affärsbeslut, och den behöver vara avgjord innan API:et finns, inte upptäckt efteråt: vem internt får läsa vad, vilka externa leverantörer får åtkomst på vilka villkor, och hur GDPR- och Berättigad part-skyldigheter gäller för det ni exponerar. Kommer den frågan in sent kan en tekniskt välfungerande datakedja stanna upp i månader.
6 · Vem håller den igång?
En infrastruktur är inte klar när den fungerar första gången, utan när den klarar att personen som byggde den flyttar till ett annat projekt. Övervakning hör hemma på själva infrastrukturen. De flesta fel här är diskreta, och ett stoppat flöde upptäcks vanligtvis veckor senare av den som först undrar varför siffrorna ser gamla ut.
Det svårare vägvalet är organisatoriskt, inte tekniskt: bygg den löpande driftskompetensen internt, eller köp in den. En enkät från 2022 bland svenska elnätsföretag fann att den kombinerade elkrafts-och-IT/dataskompetensen som krävs för att driva detta väl är den enskilt mest bristfälliga resursen: inte elkraftskunskap ensamt, inte IT ensamt. Som en svarande uttryckte det: traditionell elkraftskompetens med viss programmeringskunskap slår djup digitaliseringskompetens utan tillräcklig elkraftsgrund. För ett medelstort elnätsföretag är detta ett viktigt bygg-eller-köp-beslut som behöver en budgetpost, inte en projektkod som stängs när piloten är slut.
7 · Vad öppnar det här upp för härnäst?
När ett användningsfall väl har visat tydligt värde av data ni redan hade förbättras förutsättningarna för nästa investeringslager (rikare nätstationsmätning, riktad stationsmodernisering) av sig själv, eftersom det inte längre handlar om att spendera på löftet om framtida värde utan på något som redan har betalat för sig självt en gång. Det är så Ei:s stationsstatistik (bara 35 % med timmätning) kan förbättras över tid: inte genom att argumentera för bättre instrumentering i abstrakta termer, utan genom att utnyttja det som redan finns så väl att det blir självklart att efterfråga mer datainsamling.
Ett andra potentiellt lönsamt användningsfall är värt att nämna: identifiering av icke-tekniska förluster, undersökt i en kompletterande Energiforsk-studie. Även om ert första användningsfall inte var det här, är det ändå troligt att det fortfarande är relevant, och nästan helt finansierat av infrastruktur ni byggde för något annat.
Är flexibilitet i sig fortfarande en öppen fråga finns DSO-resan som stöd.
This is the first of a different kind of guide from The DSO Journey or The FSP Journey: not a sequence of decision gates about whether to pursue flexibility, but a practical path that starts from something you already hold. It works whether or not you’ve decided anything about flexibility yet.
1 · What are you already measuring?
Before anything else, take stock of three layers you likely already have, in the order they’re usually easiest to use:
SCADA or equivalent. Most Swedish DSOs already have a control-room historian holding more history than people assume: usually at inconsistent resolution, with gaps nobody has ever characterized, but real and sitting there.
Customer settlement metering. Universal by law, hourly or better since the smart-meter rollout. If nätstation-level data can’t be stood up quickly, a reasonable model can usually be built from settlement metering alone.
Submetering. Rogowski coils and similar current/voltage sensors, cheap relative to SCADA-grade instrumentation, for targeted top-up where the first two layers leave a specific blind spot.
Most Swedish DSOs start from the same gap. A 2018 DNV GL study for Energiforsk names the dominant problem as a near-total lack of information about the network between the fördelningsstation’s outgoing bays and the customer connection points downstream: not a shortage of transformers or cables, a shortage of information about how that stretch actually behaves. A Vattenfall trial made it concrete: of 14 nätstationer fitted with energy metering, only 8 behaved as documented, one showed negative losses (the recorded topology was simply wrong), and five showed inexplicably high losses nobody could yet explain. Six of the 14 pointed to a fault or a data-integrity problem the DSO didn’t know it had.
That report also gives a useful, DSO-validated way to name where you sit:
Most Swedish nätstationer sit at bronze. Development potential, per the same report, lies mainly in metering and communication systems, not in primary equipment: roughly 70% of Swedish local and regional grid components are older than 20 years and 37% older than 38, the legacy of an uneven buildout 40–50 years ago, which is why retrofit difficulty varies so much station to station. None of that is a reason to wait. It’s a reason to start from what’s already digital, which for most mid-size DSOs is the settlement-metering and SCADA layers, not the nätstation layer.
This guide is scoped to mid-size grid companies and up (roughly 10,000 customers or more), which is around 77 of Sweden’s 146 local-grid companies but covers an estimated 94% of Swedish grid customers. If you’re smaller than that, building this capability in-house may not be the right call at all. A licensed third party handling it on your behalf is a real alternative worth reading first.
2 · What’s the first thing worth doing with it?
Four candidate uses show up repeatedly for the same underlying data:
- Load forecasting: see Your Load Forecast
- Network analysis and planning: losses, topology validation, DNDP input
- Flexibility: procurement, activation, settlement
- Predictive maintenance: catching component faults before they become outages
Only one of these has to justify building the pipeline described in the rest of this guide. The other three ride free once it exists, because extraction, quality, and access (steps 3 through 5) are shared infrastructure regardless of which use case pays for them first.
The DSOs actually doing this confirm both halves of that claim. In a 2022 survey of 34 Swedish grid companies, 85% said they already collect data they don’t currently use; the raw material for step 1 is rarely the constraint. But 56% also said there’s data they’d like to collect and can’t, citing old equipment, insufficient systems and communication pathways, IT security, and lack of skill and time. One respondent summed up the economics directly: “there’s an opportunity to collect more data from the new meters, but right now there’s no value in collecting all of it, relative to the cost of validating and storing it.”
A feasibility check belongs here too, cheap now and expensive to discover later: does the data you inventoried in step 1 actually support the use case at the resolution and latency it needs? A survey of 50 Swedish DSOs found 28% have no documented forecasting methodology at all, relying on expert judgement instead: a reasonable starting point, but not one a business case can be built on without first checking the data underneath it will hold up.
The Metering Use-Case Fit Checker runs that check directly: answer a few questions about your data’s resolution, latency, and quality, and see which of the four use cases above it can actually support today.
→ Metering Use-Case Fit Checker
3 · Can you get it out?
Extraction should read from a replica or a scheduled export. Never query production directly. The choice of latency class decides the architecture more than anything else: a daily batch export and a near-real-time feed are genuinely different builds, and picking the wrong one here is the expensive mistake, not a detail to fix later.
Sweden’s 168 DSOs run heterogeneous legacy systems, mostly speaking the standard grid-layer protocols: IEC 61850 for substation automation, IEC 60870-5-104 (Europe’s DNP3 equivalent) for control-centre-to-substation communication. But proprietary vendor implementations on top of those standards create real switching costs. That’s exactly why “we both use the same standard” still isn’t a sufficient answer to “will this integrate.” Flexibility Communication Protocols documents the same gap one layer up, where E.ON and Ellevio both use OpenADR for villkorade avtal but implement it differently enough that Energiföretagen had to publish a supplement explaining the divergence.
The commercial trap sits on the business side of this step, not the technical side: export interfaces are frequently a separately licensed module, and the cost tends to surface only after someone has already told leadership “it’s just an export.” Get the licensing cost of egress quoted in writing before it’s assumed into a budget.
Ei’s own supervision has already found the same “the interface exists, the information needed to use it doesn’t” pattern one layer closer to the customer: a 2025 riktad tillsyn found DSOs weren’t publishing which data protocols their own open customer interface actually supports, undermining an interface that was technically compliant but practically unusable to third parties. The same failure mode is worth checking for on your own internal export interfaces before someone downstream discovers it the hard way.
Why "wait for the national data hub" is the wrong read
The planned national data infrastructure is Datahanteringsverktyget (DHV), sometimes discussed as the future Flexibility Information System (FIS). It’s a proposal due from Ei in September 2026, and on our estimate a build of four to six years from a government decision expected in 2027 puts it in operation in the early 2030s. It can be tempting to read that timeline as a reason to wait: why build an internal pipeline now, if a national one is coming?
It’s the opposite. DHV will demand exactly this data, in standardised form, from every DSO. A grid company that hasn’t sorted its own extraction, quality, and access layers by the time DHV arrives won’t be able to feed it either. It will be late and still stuck, instead of ready to hand off a working pipeline that already knows its own gaps. Building now, shaped to hand off later, beats waiting.
4 · Can you trust it?
This is where most of the real work is, and per Ei’s own audit, it’s where Swedish DSOs currently have the most to fix.
Time alignment. Clock drift, daylight saving transitions, and timezone handling all corrupt a series without ever throwing an error.
Gap characterization. Know your actual missing-value rate before anyone downstream assumes it’s zero.
Topology mapping. Attribute every reading to a feeder or station. A number with no place to stand on is not useful data, whatever its accuracy.
Ei’s 2022–2023 supervision of ten DSOs’ metering compliance found 6 of 10 exceeded the legal limit for missing values; in two of the six cases the main cause was a stalled smart-meter swap that breaks the collection chain until the DSO has no choice but to estimate.
The estimate itself is the risk. Ei found that some DSOs fill the gap with a completely flat profile for smaller customers instead of the customer’s actual consumption shape: a stretch of “interval data” with no real temporal information. The measurement rules require calculated values to be flagged as calculated, but a pipeline that drops the flag can’t tell that stretch from a genuine reading, and a model or a baseline trained on it won’t fail loudly; it will be wrong in a way nobody flagged.
The gate here is a documented quality baseline with a known gap rate (not zero gaps, a known rate), so whoever consumes the data downstream knows what they’re actually working with. This is also the direct handoff to guide #2 on load forecasting: forecast skill can’t be honestly evaluated against data whose own quality hasn’t been characterized first.
The animation below follows one gap from the meter to the forecast.
5 · Can anything else reach it?
Design storage and an API against a real consumer contract, not an invented schema. Sweden already has two documented ones worth building against directly: NODES and SWITCH both publish full API specifications, and a DSO that shapes its own export to look like what a real flexibility platform already expects saves itself a second integration project later. Ellevio’s own case is the concrete version of this: having built a forecasting tool from its own SCADA data, it integrated that tool via API with both SWITCH and NODES to actually use the forecast for flexibility procurement, including the data-classification work needed to keep individual consumer information from being exposed in the process.
The access model is a business decision, and it needs to be settled before the API exists, not discovered after: who internally may read what, which external vendors get access under what terms, and how GDPR and Berättigad part obligations apply to whatever you’re exposing. Engaged late, this stalls a working pipeline for months over a question that had nothing to do with the technology.
6 · Who keeps it running?
A pipeline is not done when it first works; it’s done when it survives the person who built it moving to another project. Monitoring belongs on the pipeline itself. Most failures here are silent, and a stopped feed is typically noticed weeks later, by whoever downstream first wonders why their numbers look stale.
The harder fork is organizational, not technical: build the ongoing operating competence in-house, or buy it in. A 2022 survey of Swedish DSOs found the combined electrical-power-and-IT/data competence needed to run this well is the single scarcest resource named: not power-system knowledge alone, not IT alone. As one respondent put it, traditional power-system competence with some programming ability beats deep digitalization skill without enough power-system grounding underneath it. For a mid-size DSO, this is a genuine build-vs-buy decision, not a detail. It needs a budget line, not a project code that closes when the pilot ends.
7 · What does this unlock next?
Once one use case has demonstrated real value from data you already had, the business case for the next layer of investment (richer nätstation metering, targeted substation modernization) improves on its own, because it’s no longer a request to spend on the promise of value; it’s a request to extend something that has already paid for itself once. That’s how Ei’s own substation statistics (only 35% hourly-measurement compliance) actually move, over time: not by arguing for better instrumentation in the abstract, but by using what already exists well enough that asking for more becomes the easy call.
A second, separately monetizable use case is worth naming even if it wasn’t your first: non-technical loss detection, examined in a companion Energiforsk study. If your first use case wasn’t this one, it’s very likely still sitting there, funded almost entirely by infrastructure you built for something else.
If flexibility itself is still an open question, The DSO Journey is where that decision gets made.