STLF Load Forecast Starter

Bygg en transparent korttidsprognos (STLF) av din egen lastdata — och bedöm den så som en flexmarknad bedömer den, inte så som en lärobok gör. Lågt MAPE är inte målet; målet är att träffa rätt i de dyra timmarna.

Build a transparent short-term load forecast (STLF) from your own load data — and judge it the way a flexibility market does, not the way a textbook does. Low MAPE is not the goal; the goal is to be right in the expensive hours.

⛭ All databehandling sker i din webbläsare Ingen uppladdning · ingen server Metod: typdag + temperaturkorrigering Validering: trängselträff, inte bara MAPE

Varför detta verktyg

Det akademiska svaret på "vad är en bra lastprognos" — minimera MAPE med hybrid-ML — är fel svar för flexmarknader. Där är prognosen ett finansiellt instrument vars värde definieras av avräkningsreglerna: bra = träffsäker där fel är dyra, manipulationssäker där pengar står på spel, och färsk när marknaden stänger. En 1,47 %-MAPE-modell på systemnivå kan vara en dålig flexprognos. Detta verktyg räknar därför MAPE — men lägger tyngden på topptimsfel och på om prognosen faktiskt fångar trängseltimmarna. (Grundat i wiki: STLF for Flexibility Markets — What Counts as Good.)

The academic answer to "what is a good load forecast" — minimize MAPE with hybrid ML — is the wrong answer for flexibility markets. There the forecast is a financial instrument whose value is defined by the settlement rules: good = accurate where errors are expensive, manipulation-resistant where money is at stake, and current when the market clears. A 1.47%-MAPE system-level model can be a bad flex forecast. This tool therefore computes MAPE — but weights peak-hour error and whether the forecast actually catches the congestion hours. (Grounded in the wiki: STLF for Flexibility Markets — What Counts as Good.)

1 · Lastdata

Förväntat format: en rad per tidssteg (timvis funkar bäst), med tidsstämpel och last (kW eller MW). Valfritt: temperatur (°C) för väderkorrigering och pris (kr/MWh) för kostnadsviktning. Avgränsare ;, , eller tab och svenskt decimalkomma hanteras. Exempel:

Expected format: one row per time step (hourly works best), with a timestamp and load (kW or MW). Optional: temperature (°C) for weather correction and price (SEK/MWh) for cost weighting. Delimiters ;, , or tab and Swedish decimal commas are handled. Example:

tidpunkt;last_kw;temp_c;pris
2025-11-01 00:00;4210;3,4;612
2025-11-01 01:00;3980;3,1;588
...

timestamp;load_kw;temp_c;price
2025-11-01 00:00;4210;3.4;612
2025-11-01 01:00;3980;3.1;588
...

Klistra in CSV — eller ladda en fil / demodata

2 · Inställningar

Kapacitetsgräns (trängsel om last > gräns)

Föreslås automatiskt ≈ P96 av lasten när data lästs in.

Valideringsfönster (dygn i slutet hålls undan)

Modellen tränas på det tidigare, testas mot det undanhållna.

Hög-CI-kvantil (säkerhetsprognos)

E.ON gick i SWITCH från P50 → övre kvantil för att sluta missa topptimmar.

Väderkorrigering Justera prognosen linjärt mot temperatur

Kräver temperaturkolumn.

3 · Resultat

Validering: utfall vs prognos i testfönstret

Verkligt utfall P50-prognos (typdag) P50→P90-band Kapacitetsgräns Faktisk trängseltimme

Träffsäkerhet — och varför ett tal inte räcker

Läs så här

MAPE är medelfelet över alla timmar — det domineras av de många lugna timmarna och döljer det som kostar pengar. Jämför MAPE med topptims-MAPE: är topptimsfelet mycket högre missar din modell systematiskt de timmar som driver trängsel, aktivering och utnyttjandegrad. Bias visar riktningen: negativ = du underskattar lasten (farligast för en DSO — du missar trängsel).

MAPE is the mean error across all hours — it is dominated by the many calm hours and hides what costs money. Compare MAPE with peak-hour MAPE: if the peak-hour error is much higher, your model systematically misses the hours that drive congestion, activation, and utilisation. Bias shows the direction: negative = you underestimate load (most dangerous for a DSO — you miss congestion).

Trängseldetektering — det som faktiskt skapar ordern

För en DSO är prognosens jobb att svara på en binär fråga per timme: kommer detta nät att överskrida sin gräns? Det är den frågan som blir en marknadsorder. Nedan: hur väl P50 respektive hög-CI-prognosen fångar de faktiska trängseltimmarna i testfönstret.

For a DSO the forecast's job is to answer a binary question each hour: will this grid segment exceed its limit? That is the question that becomes a market order. Below: how well the P50 and high-CI forecasts catch the actual congestion hours in the test window.

P50 → hög-CI: försäkringslogiken

Nästa steg bortom detta verktyg

Detta är typdagsnivå. För riktig flex-STLF binder andra saker före algoritmen: dataåtkomst (submätning/DMD art. 7b, DHV/FIS), DER-inventering per matarledning, och organisatorisk förmåga (~32 % av DSO:er saknar dokumenterad metodik). Hybrid-ML (CNN-LSTM) lönar sig specifikt på EV/värmepumps-olinjäritet — men först över en kapabilitetströskel.

Och kom ihåg: verklig avräkning sker mot en baslinje, inte realiserad last. Detta verktyg validerar det enklare problemet.

This is typical-day level. For real flex STLF, other things bind before the algorithm: data access (submetering/DMD Art. 7b, DHV/FIS), DER inventory per feeder, and organisational capability (~32% of DSOs lack a documented methodology). Hybrid ML (CNN-LSTM) pays off specifically on EV/heat-pump non-linearity — but only above a capability threshold.

And remember: real settlement is against a baseline, not realised load. This tool validates the easier problem.

Metod & förbehåll

Hur prognosen byggs (typdagsmetoden)

Verktyget använder en typdags-/liknande-dag-metod — samma nivå som Energiforsks lathund, lämplig för de ~32 % av svenska DSO:er som idag saknar dokumenterad prognosmetodik:

Profil: lasten grupperas efter dygnstyp (vardag / lördag / söndag) × tidpunkt på dygnet; medelvärdet per grupp blir P50-grundprognosen.
Väderkorrigering (valfri): residualen (verklig − profil) regresseras linjärt mot temperatur; korrigeringen a + b·temp läggs på. Eftersom uppvärmning är ungefär linjär i temperatur lyfter detta ofta de kalla topptimmarna.
Hög-CI-band: residualernas övre kvantil (P80/P90/P95) per dygnstimme adderas till P50 → en säkerhetsprognos som är bredare där lasten är volatil.
Validering: de sista N dygnen hålls undan; modellen tränas på resten och testas mot det undanhållna utfallet.

Detta är en startpunkt, inte en hybrid-ML-modell. Poängen är att göra metoden transparent och flytta fokus från modellval till rätt frågeställning.

The tool uses a typical-day / similar-day method — the same level as Energiforsk's lathund, suitable for the ~32% of Swedish DSOs that today lack a documented forecasting methodology:

Profile: load is grouped by day-type (weekday / Saturday / Sunday) × time-of-day; the mean per group becomes the P50 base forecast.
Weather correction (optional): the residual (actual − profile) is regressed linearly on temperature; the correction a + b·temp is added. Since heating is roughly linear in temperature, this often lifts the cold peak hours.
High-CI band: the upper quantile (P80/P90/P95) of residuals per hour-of-day is added to P50 → a safety forecast that is wider where load is volatile.
Validation: the last N days are held out; the model is trained on the rest and tested against the held-out outcome.

This is a starting point, not a hybrid-ML model. The point is to make the method transparent and shift focus from model choice to the right question.

Fem sätt som "bra för flex" skiljer sig från "lågt MAPE"

Dimension	Lärobokens svar	Flexmarknadens svar
Objekt	Bruttolast	Baslinjen (kontrafaktiskt) och nettoposition — inte realiserad last
Granularitet	Systemlast (utjämnad)	Matarledning / hushållskluster / enskild DER — hög relativ varians
Förlustfunktion	Symmetrisk MAPE	Kostnadsviktad, tröskelstyrd, koncentrerad till topptimmar
Motståndskraft	(saknas — ingen motpart)	Manipulationssäker & återräknelig (NC DR art. 14)
Färskhet	Bäst offline	Bäst vid gate-closure — värdet förfaller med ålder

Dimension	Textbook answer	Flex-market answer
Object	Gross load	The baseline (counterfactual) and net position — not realised load
Granularity	System load (smoothed)	Feeder / household-cluster / single DER — high relative variance
Loss function	Symmetric MAPE	Cost-weighted, threshold-based, concentrated in peak hours
Resistance	(none — no adversary)	Manipulation-resistant & recalculable (NC DR Art. 14)
Currency	Best offline	Best at gate closure — value decays with age

Den ekonomiskt värsta biasen är systematisk överoptimism om levererbar flex — för en DSO blir spegelbilden att underskatta efterfrågan och missa topptimmen. Båda parter överger därför punktprognosen mot den kvantil som skyddar mot deras katastroffel: FSP:n biaserar ned på sin flex, DSO:n biaserar upp på efterfrågan.

The economically worst bias is systematic over-optimism about deliverable flex — for a DSO the mirror image is to underestimate demand and miss the peak hour. Both parties therefore abandon the point forecast toward the quantile that protects against their catastrophic error: the FSP biases down on its flex, the DSO biases up on demand.

Vad som faktiskt binder i Sverige — inte algoritmen

Wiki-syntesens rangordning av vad som krävs för bra flex-STLF, i ordning efter vad som binder:

Dataåtkomst — submätning/DMD (art. 7b) och DHV/FIS-ryggraden (förslag sept 2026). Den enskilt största hävstången på FSP-sidan.
Bottom-up DER-inventering — du kan inte prognostisera en matarledning utan att veta vad som är anslutet (PREDATOR: analysera–aggregera–extrapolera).
Hybrid-ML — lönar sig specifikt på EV- och värmepumps-olinjäritet, men bara över en kapabilitetströskel de flesta DSO:er inte når.
Probabilistiska metoder — kommunicera osäkerhet; given den asymmetriska förlusten är det i sig en förbättring i beslutstermer.
Kapacitetstaksprodukter — när bra STLF inte går att nå: byt produkt, inte modell (operating envelopes kringgår baslinjen).
Organisatorisk förmåga — den verkliga flaskhalsen. ~32 % saknar dokumenterad metodik; DSO:er efterfrågar helhetslösningar, inte komponenter.

Detta verktyg adresserar punkt 4 och 6 (och lite av 1, genom att hålla datan lokal) — inte algoritmfronten. Det är medvetet.

The wiki synthesis's ranking of what good flex STLF requires, ordered by what binds:

Data access — submetering/DMD (Art. 7b) and the DHV/FIS backbone (proposal Sept 2026). The single biggest lever on the FSP side.
Bottom-up DER inventory — you cannot forecast a feeder without knowing what is connected (PREDATOR: analyse–aggregate–extrapolate).
Hybrid ML — pays off specifically on EV and heat-pump non-linearity, but only above a capability threshold most DSOs do not clear.
Probabilistic methods — communicate uncertainty; given the asymmetric loss this is itself an improvement in decision terms.
Capacity-limit products — when good STLF is unachievable: change the product, not the model (operating envelopes bypass the baseline).
Organisational capability — the real bottleneck. ~32% lack a documented methodology; DSOs ask for holistic solutions, not components.

This tool addresses points 4 and 6 (and a little of 1, by keeping the data local) — not the algorithm frontier. That is deliberate.

Förbehåll & begränsningar

Typdagsmetoden fångar inte helger/röda dagar automatiskt (endast vardag/lör/sön). Stora avvikande dagar (jul, midsommar) bör städas bort manuellt.
Väderkorrigeringen är linjär; den fångar inte tröskeleffekter (värmepump som slår på vid viss temperatur) eller kyleffekt på sommaren bra.
Hög-CI-bandet bygger på historiska residualer — det extrapolerar inte till väderlägen utan motsvarighet i träningsdatan (kallaste topptimmarna har minst historik).
Detta validerar mot realiserad last. Verklig flexavräkning sker mot en baslinje — ett kontrafaktiskt utfall som aldrig inträffar och inte kan valideras direkt. Se wiki: Baseline Methods.
Ingen data lämnar webbläsaren; inget sparas. Ladda om sidan = allt borta.

The typical-day method does not capture holidays automatically (only weekday/Sat/Sun). Large outlier days (Christmas, Midsummer) should be cleaned out manually.
The weather correction is linear; it does not capture threshold effects (a heat pump switching on at a certain temperature) or summer cooling well.
The high-CI band is built from historical residuals — it does not extrapolate to weather conditions with no precedent in the training data (the coldest peak hours have the least history).
This validates against realised load. Real flex settlement is against a baseline — a counterfactual outcome that never happens and cannot be validated directly. See the wiki: Baseline Methods.
No data leaves the browser; nothing is saved. Reload the page = everything gone.

STLF Load Forecast Starter

1 · Lastdata

Kolumnmappning

2 · Inställningar

3 · Resultat

Validering: utfall vs prognos i testfönstret

Träffsäkerhet — och varför ett tal inte räcker

Trängseldetektering — det som faktiskt skapar ordern

Metod & förbehåll