Lagring av data i en tjänstehubb EN RAPPORT TILL SVENSKA KRAFTNÄT 18 APRIL 2016 PROJEKT NR:

Transkript

1 Lagring av data i en tjänstehubb EN RAPPORT TILL SVENSKA KRAFTNÄT 18 APRIL 2016 PROJEKT NR:

2 Copyright Sweco Energuide AB All rights reserved No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise without the prior written permission of Sweco Energuide AB.

3 Disclaimer While Sweco Energuide AB ( Sweco) considers that the information and opinions given in this work are sound, all parties must rely upon their own skill and judgement when making use of it. Sweco does not make any representation or warranty, expressed or implied, as to the accuracy or completeness of the information contained in this report and assumes no responsibility for the accuracy or completeness of such information. Sweco will not assume any liability to anyone for any loss or damage arising out of the provision of this report. 18 APRIL 2016 SWECO 3

4 Report name Availability status Lagring av data i en tjänstehubb Final Completion date Project manager Authors and contributors Stephan Stålered Malin Anderberg, Moustafa Chenine, Stephan Stålered, Bertil Söderquist, Peter Österberg LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 4

5 Innehåll 1. Uppdraget Metod, förutsättningar och avgränsningar Förutsättningar för analysen Framtidsscenario/avgränsningar Förutsättningar för kostnads-nyttoanalysen Danmark, Norge, Finland Decentralt vs Centralt Synpunkter från aktörerna Innebörden i en central informationshanteringsmodell Alternativa utformningar av datalagring Definition av alternativ 1 - Central lagring Definition av alternativ 2 - Decentral lagring Definition av alternativ 3 - Hybridlösning Oberoende av alternativ Tekniska lösningar för Decentral lagring Analys av alternativen Alternativ 1 Central lagring Alternativ 2 Decentral lagring Alternativ 3 Hybridlösning Identifierade nyttor och kostnader Nyttor Identifierade kostnader Resultat från kostnads-nyttoanalysen Kvantitativ analys Kvalitativ analys Anpassning till framtida förändringar Slutsatser APRIL 2016 SWECO 5

6 9. Referenser Figur- och tabellförteckning LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 6

7 Sammanfattning Sweco har på uppdrag av Svenska kraftnät genomfört en kostnads-nyttoanalys av tre alternativ beträffande lagring av mätvärden för en svensk tjänstehubb. Alternativ 1 Central lagring Alternativ 2 Decentral lagring Alternativ 3 Hybridlösning Central lagring innebär att alla data (strukturdata, mätvärden och övrig information) lagras i den centrala tjänstehubben. Vid decentral lagring lagras inga mätvärden i hubben förutom aggregerade timserier för balansavräkningen. I stället ansvarar nätägarna för att lagra mätvärden i egna mätdatabaser och leverera dessa via hubben till de aktörer som efterfrågar dem. Då en total decentralisering ställer stora krav på tillgänglighet för alla nätägares databaser har även två varianter av hybridlösning konstruerats där central och decentral lagring kombineras. Kostnads-nyttoanalysen visar att alternativet med central lagring av alla data för tjänstehubben är fördelaktigare än övriga alternativ. Den kvantitativa analysen visar att decentral lagring liksom även en hybridlösning ger högre kostnader sett över en 10 års-period. Den kvalitativa analysen pekar på att en central lagring är fördelaktigare även inom följande områden: Snabbare åtkomst av data Högre tillgänglighet Högre säkerhet Det är därför vår rekommendation att utvecklingen av en svensk tjänstehubb inriktas på att alla data ska lagras centralt i hubben. Därmed får tjänstehubben en tydlig roll i en den gemensamma informationshanteringen för elmarknaden. Hubben är den plats där nätägarna levererar de data som elhandlare och energitjänsteföretag behöver för sin verksamhet. Det är också där som merparten av elmarknadens processer som t ex leverantörsbyten, flyttar och nätavräkning utförs. Utifrån de diskussioner som varit med branschrepresentanter under utredningsarbetet vill vi även peka på tre viktiga frågor i det fortsatta arbetet med utveckling av en tjänstehubb: Klargör helhetsbilden kring tjänstehubben Skapa konsensus kring ansvarsfrågorna (föreskrifter och/eller avtal) Klargör kraven på unbundling i hubben och aktörernas interna IT-system Den sista punkten bland annat för att tidigt klargöra förutsättningarna för utformningen av aktörernas ITsystem. 18 APRIL 2016 SWECO 7

8 1. Uppdraget Svenska kraftnät har formulerat följande uppdrag till Sweco. Svenska kraftnät kommer att införa en central informationshanteringsmodell, en så kallad tjänstehubb, för att underlätta införandet av en elhandlarcentrisk modell och en nordisk slutkundsmarknad. Med en central tjänstehubb avses ett IT-system för informationshantering och informationsutbyte mellan elmarknadens aktörer. Målet med arbetet är att utveckla en effektiv tjänstehubb för elmarknaden med ändamålsenliga och förankrade funktioner. Arbetet ska också beskriva hur tjänstehubben ska drivas och förvaltas på ett kundvänligt, säkert och effektivt sätt. Uppdraget omfattar att göra en kostnads- och nyttoanalys gällande lagring av data kopplad till tjänstehubben. Tjänstehubben ska hantera tre typer av data. Den första typen, grunddata för mätpunkter (strukturdata) visar egenskaper för de olika mätpunkterna, exempelvis information om kund, leverantör, balansansvarig och nätområde. Den andra typen är mätvärden för mätpunkterna, inklusive mätarställningar. Mätvärden ska också i tjänstehubben aggregeras för balansavräkning och statistik. Den tredje typen av data är av mer informationskaraktär, exempelvis hur en nättariff ska beräknas. Tanken är att grunddata och aggregerade mätvärden ska lagras i tjänstehubben. Mätvärden per mätpunkt ska antingen lagras centralt i tjänstehubben eller decentraliserat hos nätägarna. Detsamma gäller för informationsdata. Nätägarna är ansvariga för insamling av mätvärden från mätarna och kvalitetssäkring av mätvärden. Vid central lagring laddar nätägare upp mätvärden till tjänstehubben. Vid decentraliserad lagring levererar nätägare mätvärden när de efterfrågas. Figur 1 - Alternativa modeller för datalagring Central Decentraliserad Källa: Svenska kraftnät Parametrar att beakta vid utredningen: Tillgänglighet till data (ex dygnet runt) Responstid (hur snabbt får jag de data jag efterfrågar) Presentation av data (web eller leverans till mottagarens system) LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 8

9 Tillsyn av nätägarens mätvärdesrapportering (har vi kvar mätvärdesrapportering eller är det endast leverans vid efterfrågan) Aggregerade mätvärden, hur ofta ska de uppdateras (ska de alltid vara uppdaterade) Hantering av debiteringsgrundande mätvärden, när är masterdata? Säkerhet Integritet Decentraliserad lagring löses exempelvis med Endpoint och Node-lösning likt MADES. Här kan man tänka sig att man både kan efterfråga alla mätvärden för en viss period eller alla uppdaterade (jämfört en viss tidpunkt) mätvärden för en period, det sistnämnda för att hålla nere mängden data som levereras mellan olika system. Figur 2 - Decentraliserad lagring enligt MADES-modellen Aggregerade mätvärden Endpoint Endpoint Endpoint Node Endpoint Elhandlare Nätägare Endpoint Grunddata (ev i Node) Tjänstehubb Källa: Svenska kraftnät Det finns andra tekniska lösningar för att hantera decentraliserad lösning, utredningen ska inte låsa sig vid enbart ovan nämnda exempel. Utredningen ska redovisa en kostnads/nyttokalkyl för de två alternativen central lagring och decentraliserad lagring av mätvärden. 18 APRIL 2016 SWECO 9

10 2. Metod, förutsättningar och avgränsningar Dataunderlaget bygger på tidigare utredningar, möten med branschrepresentanter samt synpunkter framförda vid en workshop tillsammans med företrädare för ett antal energiföretag. Vid workshopen deltog representanter för Vattenfall, E.ON, Ellevio, Göteborg Energi, Kraftringen och Nacka Energi. De båda sistnämnda deltog också som representanter för Energidataföreningen, som är en sammanslutning av ett 40-tal mindre och medelstora energiföretag.. representanter för uppdragsgivaren. Vi har också tagit del av erfarenheter från Danmark, Norge och Finland. Dessutom deltog två Kostnads-nyttoanalysen har genomförts kvantitativt för de delar där det varit möjligt att kvantitativt uppskatta kostnader och nyttor. I tillägg till detta diskuteras ett antal ytterligare kostnader/nyttor i kvalitativa termer. Figur 3 - Genomförande av analysen Källa: Sweco Förutsättningar för analysen Utgångspunkten för analysen är att en tjänstehubb ska etableras i Sverige för att understödja en övergång till en elhandlarcentrisk marknadsmodell. Grundförslaget beträffande utformningen av en centraliserad informationshanteringsmodell för elmarknaden är en tjänstehubb med central lagring av alla data som ska vara tillgängliga för samtliga marknadens aktörer. Formellt skulle detta egentligen benämnas som en tjänstedatahubb, men den något kortare beteckningen tjänstehubb har använts för enkelhets skull. Analysen görs därför endast avseende en förändring från utgångspunkten en helt centraliserad hubb till en lösning där data lagras decentralt, men med funktionaliteten fortfarande placerad centralt. Avsikten är inte att analysera andra varianter av informationshanteringsmodeller. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 10

11 Framtidsscenario/avgränsningar Följande förutsättningar har antagits gälla vid en implementering av en central informationshanteringsmodell i Sverige. Tidshorisont I denna studie har 10 år bedömts vara en rimlig tidshorisont. En betydande kostnad för implementeringen avser IT-kostnader och det är rimligt att anta att dessa är avskrivna efter 10 år. Sweco menar vidare att det är vanskligt att inom detta område uttala sig om en framtid som sträcker sig mer än 10 år i framtiden. Geografisk avgränsning Studien ska primärt ha ett nordiskt fokus. En ökad regelharmonisering kan väntas vilket kommer att förenkla en etablering av nya aktörer. Denna process understöds av den förväntade utvecklingen av centrala tjänstehubbar som kommer att utgöra nav i det nationella informationsutbytet. En nordisk slutkundsmarknad kommer på något sätt att innebära att det krävs en gemensam informationshanteringsmodell för Norden. Här kommer dock inte att behandlas närmare vilken påverkan detta kan ha på valet av lösning för datalagring i anslutning till den svenska hubben. Samfakturering En viktig komponent i den elhandlarcentriska modellen är samfakturering av el och nätavgifter. Denna fråga har varit föremål för utredning av Ei parallellt med denna utredning. Två huvudmodeller behandlas där ombudsmodellen och grossistmodellen. Mycket kort uttryckt innebär ombudsmodellen att elhandlaren utfärdar en samlad faktura och då agerar i egenskap av ombud för nätägaren vad avser nätavgifterna. Dessa beräknas av nätägaren som levererar dem till elhandlaren via hubben. I grossistmodellen ansvarar elhandlaren själv för hela affären inkl kreditrisk mot kunden. Nätavgifterna beräknas i hubben där elhandlaren hämtar dem. Utredningen pekar på att grossistmodellen är fördelaktigast, men rekommenderar att den genomförs i två steg. Det första steget innebär att nätägarna beräknar de fakturaposter som avser nätavgifter och levererar dessa till hubben på samma sätt som i ombudsmodellen. I ett andra steg flyttas beräkningen av nätavgifterna över till hubben (jfr den danska hubben). I avvaktan på beslut beträffande valet av modell för samfakturering måste vi här utgå från att hubben ska kunna hantera båda varianterna. Utveckling av tjänster/nya funktioner Det förutsätts att en väl genomförd implementering av en central informationshanteringsmodell ska resultera i större möjligheter att utveckla nya tjänster och funktioner. Möjligheterna att göra detta beskrivs mer detaljerat i kostnads-nyttoanalysen. Arkivfunktion Vi har utgått från att en tjänstehubb inte ska fungera som arkiv för mätvärden, dvs den ska inte svara upp mot de krav som t ex bokföringslagen och allmänna bestämmelser ställer på lagring av underlag för fakturering. Ansvaret för att fullgöra den skyldigheten bör vila på respektive aktör. Hubbens uppgift kommer att vara att förmedla och tillhandahålla de data som marknadens aktörer behöver i sina affärsprocesser. Det bedöms inte vara aktuellt att utnyttja hubben som ett långtidslager. En anledning till det är bland annat att hubben inte kan ansvara för vilka data som aktörerna använt t ex vid fakturering. Det skulle kräva att elhandlaren markerar i hubben vilka uppgifter som användes när fakturan producerades. Ett mätvärde kan ha ändrats av nätägaren i hubben sedan faktureringen utfördes, och att enbart gå på tidsstämplingen av mätvärdet bedöms osäkert. 18 APRIL 2016 SWECO 11

12 Förutsättningar för kostnads-nyttoanalysen Definition av alternativ I detta fall handlar det om att jämföra den initialt förutsatta modellen utformad efter förebilderna från Danmark, Norge och Finland med en annorlunda modell för lagring av data. Den initialt tänkta designen kan därför betraktas som ett nollalternativ, men vi kommer i det följande att använda beteckningarna: Alternativ 1 Central lagring Alternativ 2 Decentral lagring Alternativ 3 Hybridlösning (en kombination av alt 1 och 2) Då alternativ 1 har karaktär av referensalternativ eller nollalternativ utförs beräkningar endast för differenser mellan resp alternativ och alternativ Diskonteringsränta Den samhällsekonomiska diskonteringsräntan som används för att diskontera kostnader och nyttor reflekterar samhällets alternativkostnad av kapital. Utifrån att vi här behandlar en infrastrukturinvestering förefaller en diskonteringsränta på 3-4 % vara rimlig. Vi har därför valt att använda en samhällsekonomisk real diskonteringsränta på 3,5 % som basfall. Samma diskonteringsränta används för alla aktörer Danmark, Norge, Finland I det uppdrag som Svk fått från regeringen förutsätts att man ska följa det utvecklingsarbete som görs i våra nordiska grannländer, och att även om det är möjligt samarbeta med dessa länder i de fall detta är lämpligt. Vi gör därför här en kort sammanfattning av situationen i övriga Norden för de aspekter som ska behandlas i denna studie. I Danmark finns en central datahubb i drift i en första etapp sedan mars Den drivs av Energinet.dk och går under namnet Datahubb. Den 1 april 2016 driftsattes etapp 2 som innebär en fullständig övergång till elhandlarcentrisk modell inklusive samfakturering av nät och elhandel. Datahubb baseras på en central lagring av alla data. Möjligen ska då noteras att Danmark än så länge bara har fjärravläsning och timmätning på delar av nätet. Nya föreskrifter kräver fjärravläsning och timmätning i Danmark från I Norge pågår utveckling av en central datahubb. Projektet drivs av Statnett som kommer att driva hubben genom ett bolag med namnet Elhub. Målet är att kunna ta hubben i bruk under 2017, och då som i Danmark en etapp 1 som exkluderar samfakturering. Elhub utvecklas som en central databas som lagrar alla data. I Norge pågår parallellt utrullning av fjärravläsning (AMS). Där är kravet att detta ska vara infört med timmätning för alla anläggningar från 1 januari Dock görs vissa undantag i regelverket som möjliggör att äldre mätare för manuell avläsning kan behållas. Dessa anläggningar kommer att profilavräknas, vilket ungefär motsvarar det som i Sverige kallas schablonavräkning. I Finland pågår upphandling av en central datahubb med målsättning att kunna ta den i bruk hösten Även denna är designad med central datalagring. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 12

13 3. Decentralt vs Centralt Synpunkter från aktörerna Bakgrunden till att frågan om decentral kontra central lagring kommit upp under hubb-projektet är att den dök upp i samband med den utredning som Sweco gjorde på uppdrag av Energimarknadsinspektionen våren 2014 (Sweco, ). Under intervjuer med några branschrepresentanter framfördes synpunkter att en decentral lagring av data skulle vara att föredra. Detta behandlades inte närmare i den studien utan resulterade endast i en kommentar att frågan eventuellt borde utredas vidare. Frågan har därefter förts vidare av Ei till departementet, som i sin tur markerade frågan i regeringsuppdraget till Svenska kraftnät. Sweco har därför under denna utredning tagit förnyad kontakt med de företag som talade för decentral lagring för att klargöra närmare vad ett sådant alternativ skulle innebära praktiskt. Från dessa möten finns nu en tydligare bild av vad man förväntar sig av en decentral struktur för lagring av data. Vi kan konstatera att det egentligen är en flerdimensionell frågeställning, men där vi uppfattat följande utgångspunkter som grund för önskemål om en decentral design av lösningen. Ansvarsfrågan Det finns en osäkerhet inom några företag kring hubbens möjligheter att ta ansvar både för data och kanske framförallt för beräkningar. Osäkerheten kring ansvaret för beräkningar gäller i vissa fall både nätavräkning och beräkningar av fakturaunderlag, men det som verkar vara störst osäkerhet omkring gäller beräkning av fakturaposter om hubben ska utföra det för elhandlarens samfakturering. Aktörerna ifrågasätter om hubborganisationen är beredd och villig att ta ansvar för konsekvenserna om det blir allvarliga fel i beräkningarna. Om felen drabbar slutkunder genom felaktiga fakturor blir det marknadens aktörer som får ta konsekvenserna. Flexibilitet Någon aktör hävdar att det är risk för att hubben inte kommer att erbjuda all den information som behövs för en elhandlare. Här har nämnts ex.vis faktureringsdata, anläggningsstatus: på/av, skattesatser, avbrottsinfo, energitjänster, information kring elmätare antal siffror, decimaler, konstanter osv. Det finns en osäkerhet från vissa aktörer kring flexibiliteten i en central lösning jämfört med en decentral. Här handlar det egentligen inte enbart om lagring centralt/decentralt utan mer frågan om en central lösning kan anpassas tillräckligt snabbt för att hänga med i en snabb utveckling av elmarknaden. Nya tjänster för elbilar har nämnts i detta sammanhang. Någon aktör har pekat på att de kommer att ha väsentligt mer data i sina egna system än vad som kommer att hanteras i hubben. Argumenten har då varit att om man använder sig av API:er för att tillhandahålla data till elhandlare så kan man erbjuda väsentligt mer information som kan vara värdefull i utveckling av nya produkter och tjänster. Tanken är här (som vi uppfattat det) att detta skulle ske vid sidan av en tjänstehubb, dvs direkt mellan elhandlare och nätägare. 18 APRIL 2016 SWECO 13

14 Dubbelarbete Några aktörer hävdar att en central modell kan generera mer dubbelarbete. Man säger att man vid en helt central modell kommer att kontrollberäkna allting i egna system för att vara säkra på att resultaten från hubben är rätt. Man hänvisar också till att central lagring innebär att man kommer att behålla sina befintliga system, dels för kontroll, dels också för att kunna erbjuda nya produkter/tjänster till slutkunder. Man påpekar att det innebär dubbellagring av data. Datakvalitet Den föregående frågan om dubbellagring av data hävdar man också ökar risken för datakvalitetsbrister. Nätägare påstår att man inte alltid hinner uppdatera mätvärden i hubben, och att det senaste, korrekta värdet enbart finns i deras egna system. Tunn tjänstehubb Någon aktör har också hävdat att man helst hade sett en mycket tunn tjänstehubb, dvs i princip nästan helt utan central datalagring. Det skulle innebära att även en stor del av strukturdata lagras decentralt hos respektive aktör. Motiveringen är ansvar för data och i viss mån större flexibilitet. En central informationshanteringsmodell En del av de synpunkter som kommit grundar sig förmodligen till viss del på att det i nuläget är oklart hur helhetsbilden för en central informationshanteringsmodell kommer att se ut. Då frågan fortfarande är i ett utredningsläge saknas naturligtvis en klar bild av hur en svensk lösning kommer att se ut. Vi vill därför innan vi formulerar alternativa lösningar för central/decentral lagring ytterligare beskriva hur den svenska lösningen kan komma att se ut om man till största delen baserar den på de danska och norska modellerna. Detta innebär dock inte att det med säkerhet kommer att bli på det beskrivna sättet i Sverige, men får ändå i viss mån utgöra en ram för detta utredningsuppdrag. Elhandlarcentrisk modell (ECM) Den centrala informationshanteringsmodellen har utformats för att stödja övergången till ECM, och i ett längre perspektiv nordisk slutkundsmarknad (NSM). ECM innebär att slutkunden enbart ska behöva ha kontakt med elhandlaren för alla frågor som rör el. De tekniska frågorna kring anslutningar, avbrott och elkvalitet ska dock fortsatt hanteras av nätägaren. Hubben måste så långt möjligt tillhandahålla all information som elhandlaren behöver i sina kundkontakter. Vid utformningen av hubben bör dessutom beaktas att elhandlarens ansvar i framtiden kan komma att utvidgas, vilket kan komma att kräva ytterligare data, t ex kring avbrott och elkvalitet. Konkurrensneutralitet En komponent i ECM är att stödja en ökad konkurrens på elmarknaden. Det påpekas i regeringsuppdraget till Svk att informationsutbytet mellan aktörerna ska vara konkurrensneutralt. Det innebär bland annat att de personer som arbetar mot en tjänstehubb inte får representera både handel och nät. Nätägare får inte tillhandahålla data till elhandlare eller energitjänstföretag via någon annan kanal än hubblösningen såvida det inte sker på lika villkor för alla aktörer. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 14

15 Det innebär att informationssystemen hos elhandlare och nätföretag i integrerade företag måste vara separerade, helst fysiskt men eventuellt enbart ur ett användarperspektiv. Åtminstone måste detta gälla långsiktigt. Det föregående blir speciellt accentuerat vid införande av samfakturering där mätvärden eller andra data i integrerade företag inte får hämtas av elhandlaren direkt i nätägarens system utan enbart via hubben. Ansvar En hubb med central lagring av alla data innebär inte att hela ansvaret för datakvaliteten överflyttas till hubborganisationen. Det kommer precis som vid en decentral lagring att vara nätägaren som ansvarar för att data om anläggningar och mätvärden är korrekta även när dessa lagras i hubbens databas. Elhandlare är ansvariga för att alla kunduppgifter är korrekta, och att uppgifter om leverantör, balansansvarig mm är korrekta. Det är alltså egentligen inte någon skillnad i ansvar mellan central respektive decentral lagring. Man kan jämföra det med lagring i molnet, dvs det är bara en fråga om var man lagrat data. Flera av kommentarerna från aktörerna visar på att man inte till fullo känner sig bekväm med att lämna över ansvaret för ex.vis beräkningar till en annan part. Här gäller naturligtvis att ansvaret noga regleras mellan hubben, nätägarna och elhandlarna både vad gäller ansvar för data och beräkningar samt konsekvenserna av fel. Vi förutsätter att detta kommer att regleras genom nya föreskrifter och avtal mellan parterna. Flexibilitet En viktig utgångspunkt vid design av en tjänstehubb är att nätägare i någon mån ska förskonas från att behöva förändra sina systemlösningar varje gång marknadens regelverk ändras. Mätvärdesflödet kommer att vara förhållandevis stabilt över tid möjligen bortsett från att timvärden inom en snar framtid kommer att ersättas med 15-minutersvärden, men det är tekniskt ingen stor utmaning. Däremot kanske en prestandamässig utmaning. Elhandlare och energitjänst-företag måste däremot vara beredda att snabbt kunna anpassa sina system till en föränderlig marknad. Med en genomtänkt design behöver man dock som elhandlare inte nödvändigt anpassa sig i alla delar på det sätt som är aktuellt i dagens informationshanteringsmodell med kommunikation alla-till-alla. Det här kan innebära att en central lagring är lika flexibel som en decentral. Med en bra design av hubben kan den eventuellt vara mer flexibel eftersom man inte måste ändra i alla nätägares system för att införa nya möjligheter för marknaden. Ändrat arbetssätt Några aktörer uttrycker oro för att en central lagring kommer att leda till dubbelarbete. Vår tolkning av detta är att påståendet egentligen syftar på en central informationshanteringsmodell med en tjänstehubb med omfattande funktionalitet så som förordats av Ei och i regeringsuppdraget till Svk. Hos dessa aktörer anger man att man kommer att fortsätta utföra processer som t ex nätavräkning i egna system även om det enbart är för att kontrollera att hubben räknar korrekt. Det kommer naturligtvis att vara så initialt tills den nya hubben är helt färdigtestad, men överensstämmer inte med den tänkta utformningen av processerna sedan hubben har tagits i bruk fullt ut. Då är tanken att nätägaren använder funktioner i hubben för att varje dag kontrollera att nätområdesbalansen är noll, vilket innebär att inrapporteringen är komplett. Man kommer också att kontrollera att status på inrapporterade mätserier är acceptabel, och att de beräknade nätförlusterna är korrekta. I övrigt behöver inte nätägarna kontrollera utfallet av nätavräkningen eftersom det är hubbens organisation som 18 APRIL 2016 SWECO 15

16 ansvarar för detta. Detta förutsätter vi är lika oavsett central eller decentral lagring. Då vi utgår från att analysen ska avse en central informationshanteringsmodell kommer vi inte att titta på alternativ där t ex nätavräkning fortfarande utförs hos varje nätägare. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 16

17 4. Alternativa utformningar av datalagring Som en utgångspunkt för vår analys har det varit viktigt att tydligt definiera de alternativ som ska jämföras. Definition av alternativ 1 - Central lagring Vi har utgått från att alternativet med central lagring kommer att likna den befintliga danska Datahub och den norska Elhub som är under utveckling. Dessa båda baseras visserligen på skilda tekniska lösningar, men använder sig ändå av samma princip för datalagring. Även specifikationen för den finska hubben baseras på central lagring av alla data. Den centrala datalagringen karakteriseras av följande: Den centrala hubben är den plats där nätägarna levererar både anläggningsdata och mätvärden till marknadens aktörer. Det är också där man utför i princip alla marknadsprocesser som kräver utnyttjande av gemensamma data. Alla data som hubben ansvarar för lagras i en central databas. Med alla data menas såväl strukturdata, mätdata som övrig information Hubben betraktas som den auktoritära källan för alla data som används gemensamt av marknadens aktörer, dvs de data som lagras av hubben betraktas som master för användning i elmarknadens processer. Det hindrar inte att samma datauppgifter som finns i aktörernas egna system kan betraktas som original. Vid ändringar är det originalet som ändras, och systemet ska sedan automatiskt uppdatera data i hubben. Central databas behöver inte nödvändigtvis innebära en enda fysisk databas, men förutsätter om det är flera fysiska databaser att dessa ska ägas och administreras från den centrala hubborganisationen. Alla aktuella data ägs och förvaltas av hubborganisationen. Principen för en tjänstehubb är att alla marknadens aktörer svarar för att försörja hubben med all relevant data som behöver vara tillgänglig för alla berörda aktörer. Det innebär i stora drag följande ansvar för att tillhandahålla och uppdatera data i hubben. 18 APRIL 2016 SWECO 17

18 Figur 4 - Ansvarsfördelning för uppdatering av data i tjänstehubb Grupp av data Exempel på data Nätägare Anläggningsdata Anläggnings-ID Nätområde Avräkningsmetod Årsförbrukning Energiskattekod Anläggningsadress Mätarnummer Mätdata Timserier för timavräknade anläggningar Mätarställning vid månadsskifte och månadsförbrukning för schablonavräknade anläggningar Mätarställningar vid flytt eller leverantörsbyte samt förbrukning för respektive period för schablonavräknade anläggningar Nättariffer Gäller endast när samfakturering tillämpas Tillämpade nättariffer per nätområde Vald nättariff för respektive slutkunds anläggning Elhandlare Kunddata Slutkundens namn Typ av kund (näringsidkare/privatkund) Fakturaadress Kontaktadress(er) Elavtal Fn inte bestämt om detta ska lagras i hubben Avtalsform Bindningstid Ev avgift för förtida avslut av avtal Balansansvarig (för leveransen till anläggningen) Källa: Sweco (med utgångspunkt från Elhub/Datahub OBS design av svensk hubb ej beslutad) Observera att listan i Figur 4 enbart visar exempel och inte utgör en komplett förteckning över data i hubben. Funktionalitet ska finnas i hubben för att kunna leverera enstaka eller många mätserier vid fråga från elhandlare, energitjänstföretag eller slutkund. De senare förutsätts dock endast få åtkomst till data i hubben via Mina sidor eller liknande hos elhandlaren. Funktionalitet ska även finnas att leverera mätvärden enligt schema, vilket kan styras av prenumeration eller regelverk. Den senare modellen kommer att vara dominerande för norska Elhub där man konstaterat att det blir mest rationellt att sända ut mätvärden enligt schema till de som måste få mätvärden enligt regelverket, t ex elhandlare för fakturering. Prenumeration kommer att vara vanligt för energitjänstföretag, men också för nätägare eftersom dessa måste hämta tillbaka mätvärden bl a om man ska beräkna nätfaktura. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 18

19 Funktionalitet ska finnas i hubben för att beräkna och rapportera aggregerade mätvärden till den nordiska balansavräkningen. Om valet av modell för samfakturering förutsätter att hubben beräknar nätavgifterna som underlag för elhandlarens faktura kommer även denna funktion att finnas i hubben. Väljer man modellen att nätägarna ska beräkna och sända fakturaposterna för nätavgifter till hubben för vidarebefordran till elhandlaren så ligger naturligtvis denna funktion hos nätägaren. Dock ska beaktas att nätägaren i detta fall måste få mätvärden för fakturan från hubben för att säkerställa att det är samma underlag som elhandlaren använder (jfr pkt 5.1.1). Figur 5 - Alternativ 1 - Central datalagring Det som i figuren ovan benämns Slutkundsportal avser en lösning där kunden via elhandlarens hemsida kan ta del av information från hubbens databas. Kunden har inte direkt åtkomst till hubben. Definition av alternativ 2 - Decentral lagring Vi har utgått från förutsättningarna i uppdraget från Svk, som i sin tur utgår från regeringsuppdraget. Det innebär att vi förutsätter att lösningen ska vara det som formellt kanske ska kallas en tjänstedatahubb, dvs en hubb som både lagrar data och tillhandahåller tjänster till marknadens aktörer. Vi utgår från att decentral lagring enbart handlar om mätvärden, medan strukturdata och annan information lagras centralt. Det ska fortfarande vara en central informationshanteringsmodell, vilket innebär att all funktionalitet finns i den centrala hubben på motsvarande sätt som vid central lagring (jfr punkt 4.1 två sista stycken). 18 APRIL 2016 SWECO 19

20 Skillnaden mot den centrala lagringen är att nätägare behåller mätvärden i sina egna databaser (MDMS-system eller liknande), och dessa betraktas som masterdata. Ansvaret för att data är aktuella och korrekta ligger naturligtvis precis som vid central lagring på nätägaren. Tjänstehubben förutsätts tillhandahålla mätvärden till elhandlare, energitjänstföretag och slutkunder på motsvarande sätt som vid central lagring. Funktionalitet måste därför finnas i hubben för att kunna leverera enstaka eller många mätserier vid fråga från elhandlare eller energitjänstföretag. Funktionalitet ska även finnas att leverera mätvärden enligt schema, vilket kan styras av prenumeration eller regelverk (jfr Elhub). Vi har i analysen utgått från att hubben på samma sätt som i alternativ 1 ska beräkna aggregerade mätvärden som ska rapporteras till esett för den nordiska balansavräkningen. Det är då naturligt att dessa lagras centralt i hubben efter beräkningen. I alternativ 1 kommer hubben att göra om beräkningen av aggregerade volymer ett antal gånger per dygn för att fånga in korrigerade och kompletterade mätvärden som kommit in från nätägare. Kompletteringar kommer kontinuerligt att sändas till esett fram till det 13:e dygnet då balansavräkningen slutförs. Detta måste lösas på något liknande sätt med decentral lagring av mätvärden. Vi antar att det kommer att lösas genom att hubben efterfrågar (eller får sig tillsänt) förändrade mätvärden från alla lokala databaser ett antal gånger per dygn. Rimligen schemalägger man detta till tider då belastningen på kommunikationen är låg för att inte störa övriga processer. Den tekniska lösningen för decentral lagring kan utformas efter minst fyra olika linjer: A. Hubben hämtar mätvärden direkt från nätägarens databas när de efterfrågas. Det görs via ett standardiserat webservice-api som nätägaren blir skyldig att installera i sitt system B. När någon part efterfrågar mätvärden sänder hubben en request till den aktuella nätägarens databas. Nätägarens system svarar med att sända efterfrågade mätvärden. Det är i princip samma lösning som finns i dagens UTILTS-standard, Request for missing value, vilken dock inte är i bruk i nuläget. Den är inte heller utformad för att returnera mer än enstaka mätvärden. C. ENTSO-E har utarbetat en standard för datautbyte mellan aktörer på den europeiska elmarknaden kallad MADES. Den beskrivs närmare i avsnitt D. Denna variant innebär att huvuddelen av dataflödet styrs av ett regelverk. Det innebär att nätägare precis som i dagens modell sänder mätvärden enligt ett schema anpassat t ex efter normala faktureringstillfällen. Det kan vara en form av prenumeration på mätvärden som elhandlare eller energitjänstföretag gör. Mätvärdesflödet förutsätts dock passera hubben, som därmed kan sägas få karaktär av kommunikationshubb (jfr EMIX). Modellen måste dock parallellt innehålla en möjlighet att fråga efter mätvärden on demand. Avsikten med att låta nätägarna sända enligt schema är att reducera behovet av hög prestanda och kommunikationskapacitet. För att begränsa mängden data som utväxlas vid varje tillfälle bör samtliga varianter utformas så att man enbart efterfrågar respektive sänder förändrade data. I detta alternativ förutsätts en fullständig decentralisering av mätvärdeslagringen, dvs mätdatasystemen hos alla nätägare ska vara knutna till hubben via den valda tekniken. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 20

21 Figur 6 - Alternativ 2 - Decentral datalagring Det som i figuren ovan benämns Slutkundsportal avser en lösning där kunden via elhandlarens hemsida kan ta del av information från hubbens databas. Kunden har inte direkt åtkomst till hubben. Definition av alternativ 3 - Hybridlösning En utformning av decentral lagring enligt alternativ 2 innebär betydande krav på prestanda, tillgänglighet och kapacitet hos nätägarnas system. För de större nätägarna bör det inte vara några större problem att svara upp mot de högre kraven. Däremot kan det vara fördelaktigare för mindre eller medelstora nätägare att kunna utforma sina system på samma sätt som vid central lagring eftersom det inte ställer lika höga krav på nätägarnas system. En hybridlösning kan därför vara ett alternativ som kan tillgodose önskemålen från båda dessa grupper. En sådan kan konstrueras efter minst två varianter. A. Hubben utformas som en hybridlösning (Figur 7). Det innebär att hubben lagrar data centralt för de nätägare som väljer att ansluta sig till den modellen. Samtidigt erbjuder hubben att de nätägare, som kan tillhandahålla de prestanda och den tillgänglighet som krävs, att ansluta sin databas för decentral lagring av mätdata. Tekniskt kan det lösas liknande alt 2A, 2B eller 2C, vilka kan klara att leverera mätvärden on demand. Däremot är det nog mindre lämpligt att använda tekniken enligt 2D i kombination med central lagring för vissa nät eftersom de kommer att fungera så olika. B. I denna variant (Figur 8) öppnas möjligheter för tjänsteföretag att erbjuda lösningar som för flertalet nätägare innebär att man arbetar enligt en central lagringsmodell, medan de större nätägarna ansvarar för decentral lagring. Det betyder att det uppstår en eller flera servicehubbar dit mindre nätägare sänder sina mätvärden som i en central modell. Mätvärden mellanlagras i servicehubben som i sin tur svarar mot den centrala tjänstehubben med att leverera mätvärden när de efterfrågas. 18 APRIL 2016 SWECO 21

22 Distribution av mätvärden enligt samma principer som i alt 1 och 2, dvs on demand eller schemalagt. Figur 7- Alternativ 3A - Hybridhubb Betr Slutkundsportal se kommentar under alt 1 och 2. De större nätföretagens mätdatabaser är direkt anslutna till hubben via något nätverk. Den vägen levererar mätdatabaserna mätdata till hubben för vidarebefordran till användaren. All övrig funktionalitet förutsätts utföras via motsvarande B2B-gränssnitt som i alternativ 1. Figur 7 och Figur 8 har förenklats såtillvida att lösningen egentligen kräver dubbla M2M-gränssnitt i hubben (decentral respektive central lagring). Här illustreras det enbart med att de större nätföretagen ansluts direkt till hubben med decentral lagring. De nätägare som inte väljer att ha en mätdatabas direkt ansluten till hubben ansluter i stället sitt mätinsamlingssystem via samma M2Mgränssnitt som i alternativ 1. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 22

23 Figur 8 - Alternativ 3B - Servicehubbar Betr Slutkundsportal se kommentar under alt 1 och 2. De större nätföretagens mätdatabaser är direkt anslutna till hubben via något nätverk. Den vägen levererar mätdatabaserna mätdata till hubben för vidarebefordran till användaren. Motsvarande gäller servicehubbarna som enbart agerar mellanlager för flertalet nätägare. All övrig funktionalitet förutsätts utföras via motsvarande B2B-gränssnitt som i alternativ 1. Oberoende av alternativ Funktionerna i hubben kommer förutom mätvärdesrapporteringen att vara lika i båda alternativen så de beskrivs inte mer ingående här än den korta listan i Tabell 1. Framtida hantering av samlad faktura lämnas utanför denna sammanställning eftersom det just nu är föremål för utredning av Energimarknadsinspektionen. Kort kan noteras följande: 18 APRIL 2016 SWECO 23

24 Tabell 1 Funktioner i tjänstehubben exkl mätvärdesrapportering (urval) Funktion Utförs av Kommentar Uppstart av anläggning Nätägare Elhandlaren ej involverad In- & Utflyttning Elhandlare Nätägaren får info om avslut och ny kund Leverantörsbyte Elhandlare Nätägaren får meddelande om leverantörsbyte och levererar mätaravläsning för månadsavlästa Uppdatering av anläggningsdata Nätägare Meddelas elhandlaren Uppdatering av kunddata Elhandlare Meddelas nätägaren Förfrågan om tjänst från elhandlare till nätägare Elhandlare Återrapportering från nätägare vid avslutat uppdrag om sådant avses Avräkningsunderlag till esett Hubben Korrektionsavräkning Hubben Justering balanskraft och kvarkraft till Svk Rapportering & statistik Hubben Mätvärden & historiska data tillgängliga för kund Hubben Mätvärden till energitjänsteleverantörer Hubben Underlag för tilldelning av elcertifikat Hubben Fn oklart betr vägval i Sverige, ingår i Norge Rapportering av kvotpliktig förbrukning Hubben Fn oklart betr vägval i Sverige, ingår i Norge Källa: Sweco (enligt K/N-analys av svensk datahubb ) Tekniska lösningar för Decentral lagring Webservice-API Den mest näraliggande lösningen för att möjliggöra decentral lagring är att nätägarnas mätdatasystem förses med ett standardiserat API (Application Programmers Interface) som kan anropas från tjänstehubben. Dessa kommer här att vara av typen webservices. Med standardiserat API (webservices) menas här att det ska fungera enligt en specifikation som i det här fallet branschen kommer överens om alternativt beslutas av hubborganisationen. En webservice används när ett system anropar ett annat för att hämta data eller uppdatera data. Anropet kan göras via internet eller ett dedikerat nätverk. I det här fallet kommer hubben att anropa en webservice i respektive nätägares system och sänder med parametrar som anger vilka data som nätägarens system ska leverera i svaret. Vi förutsätter här att det är en webservice som svarar direkt med den efterfrågade informationen. Den här modellen brukar betecknas som pull-teknik. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 24

25 Fördelen med den här tekniken är att man får ett snabbt svar förutsatt att det finns kapacitet både hos hubben och i nätägarnas system. Hubbens programvara bör för att vara snabb kunna exekvera frågor till flera nätägare parallellt. Nätägarnas systemlösningar måste både hantera ett snabbt svar från mätdatabasen och ha en hög kommunikationskapacitet för att kunna leverera ut en stor mängd timserier på kort tid. Webservices kan komma att finnas även mellan aktörernas system och hubben för B2Bkommunikation både vid central och decentral lagring beroende på vilken teknisk utformning som väljs för hubben. Vid decentral lagring kommer ett API-anrop från elhandlaren att trigga ett motsvarande API-anrop från hubben till nätägarens databas när mätvärden efterfrågas. Hämtningen av mätvärden kommer därför att ske i två led, vilket kan vara en nackdel genom att det gör processen lite långsammare. Men framförallt är nog nackdelen att det kräver hög prestanda i nätägarnas ITsystem Request Den här varianten efterliknar det som redan idag finns definierat i den UTILTS-standard som tillämpas idag för rapportering av mätvärden i Sverige 1. Där finns definierat ett meddelande UTILTS- REQUEST som en elhandlare kan använda för att efterfråga ett saknat mätvärde från nätägaren. Meddelande-typen används inte generellt idag, men kan användas efter bilateral överenskommelse. En request från hubben till nätägarens system kommer att trigga ett meddelande tillbaka från nätägaren till hubben. Det kan betecknas som en kombination av pull och push. Dagens meddelandetyp är avsedd att användas för enstaka mätvärden, men skulle naturligtvis kunna användas för att efterfråga alla mätvärden inför en fakturering. Processen kommer dock att ta något längre tid än med ett API enligt föregående punkt. Då massfakturering är en väl planerad aktivitet så borde en viss känd väntetid kunna accepteras. Metoden är dock mindre lämplig för spontana frågor om mätvärden MADES Market Data Exchange Standard (MADES) är en standard för en kommunikationsplattform och baseras på internationella IT-protokollstandarder. MADES har införts av ENTSO-E Electronic Data Interchange (EDI) för att underlätta en säker kommunikation mellan transmissionsnätoperatörer och aktörerna på den europeiska elmarknaden. Det är ENTSO-E som har hand om MADES och de underhåller det genom bland annat uppdateringar med jämna mellanrum. Varje användare av MADES skapar en accesspunkt (endpoint) som är länkad till dennes egna informationssystem. Till och från denna punkt kan användaren sedan utbyta dokument med andra användare på ett säkert sätt. Ett MADES-meddelande förpackas med information som är viktig för att det ska kunna spåras, transporteras och överlämnas till mottagaren, exempelvis meddelande-id, uppgifter om avsändare och mottagare, och en businesstyp. En avsändare kan alltid kontrollera statusen på meddelandet (skickat, mottaget, misslyckat). MADES kan stödja alla affärsprocesser oavsett sekvens på utbytet eller dokumenttyp (ex: XML, binary osv). Det är även oberoende av den underliggande kommunikationsinfrastrukturen (internet, privat fysisk infrastruktur, VPN) då det är som ett applikationsskiktprotokoll. Vidare bygger det helt 1 Ediel-anvisning UTILTS & APERAK, Svk, senaste version APRIL 2016 SWECO 25

26 på oskyddade IT-standarder för kommunikationsprotokoll, dataintegritet, signering och sekretess (krypterat). MADES ger ett ramverk för asynkron kommunikation och innehåller noder som under kortare tider kan lagra meddelanden. Detta innebär att mottagaren, till skillnad från i ett synkront system, inte måste vara uppkopplad till systemet hela tiden och att säkerheten i arkitekturen är högre än med andra metoder eftersom en accesspunkt inte måste acceptera en inkommande inkoppling. MADES beskriver två logiska kommunikationskomponenter och deras gränssnitt, accesspunkter och noder. Accesspunkter är viktiga ur ett business applications- och användarperspektiv då det är genom dessa man skickar och tar emot meddelanden. Noderna är en central del av MADESnätverket och innehåller ett register över alla komponenter i nätverket. MADES-nätverket har en distribuerad arkitektur och har inte en enda central komponent utan alla noder har lika ansvar och tar hand om en viss del av nätverket. Varje accesspunkt har en hemnod som den tar emot meddelanden från men den kan skicka meddelande genom andra noder. Noderna i nätverket synkroniserar med varandra med jämna mellanrum för att innehålla samma information om registrerade accesspunkter. Källa: (ENTSO-E, 2014) Figur 9 - MADES-konceptet med Endpoint och Node Källa: (ENTSO-E, 2014) Regelstyrd distribution av mätvärden Denna variant innebär att dagens modell för distribution av mätvärden behålls till stor del oförändrad. Mätvärden sänds från nätägaren till hubben som vidarebefordrar direkt till den elhandlare som ska ha respektive mätserie eller mätarställning. För att kunna leverera mätvärden on demand krävs dock införande av en funktion för att hämta enstaka mätvärden. Det innebär att någon av varianterna A (webservice) eller B (request) måste tillämpas. Förmodligen bör meddelanden utformas i XMLformat även om det inte är ett absolut krav. Kommunikationen kan ske som idag via internet/smtp eller via MADES-nätverket. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 26

27 4.5.5 Val av tekniklösning Vi kommer i denna studie inte att i detalj analysera vilken av de beskrivna tekniklösningarna som är fördelaktigast. Detta val har gjorts då en preliminär analys indikerar att valet av teknik inte kommer att vara avgörande för valet av huvudalternativ. Det är också förmodligen möjligt att hitta modernare tekniska lösningar för decentral lagring. Här görs enbart en sammanfattning av fördelar och nackdelar med de fyra varianterna. Den variant av lösning som i pkt 4.2 benämns D är till största delen utformad enligt dagens informationshanteringsmodell kombinerad med en webservice eller en request också den enligt dagens teknik. Den beskrivs därför inte som en separat teknik men inkluderas i följande sammanfattning av fördelar och nackdelar. Tabell 2 Fördelar & nackdelar med olika tekniklösningar Teknik Fördelar Nackdelar A Webservice- API Kan erbjuda snabbhet förutsatt prestanda, synkron behandling ger svar direkt Kräver hög prestanda och tillgänglighet hos nätägarnas system B Request Beprövad och pålitlig teknik. Något långsammare process pga asynkron behandling fråga-svar C MADES Standard Ingen komplett lösning eftersom det enbart är en standard för kommunikation mellan aktörerna. D Regelverk I princip dagens modell tillämpad på annorlunda sätt Måste kombineras med någon av A eller B för att hantera on demand. (Innebär att tjänstehubben får karaktär av kommunikationshubb.) Källa: Sweco I den fortsatta analysen kommer vi att anta att en decentral lagring baseras på att nätägarnas system förses med webservice-api:er (variant A) då den förefaller ha bäst förutsättningar att erbjuda prestanda likvärdiga med en central lagring. Bedömningen är att övriga varianter inte innebär väsentligt annorlunda kostnadsbild. Kommunikationen mellan aktörerna kan baseras på MADESnätverket, men är inte heller tvunget att gå den vägen. 18 APRIL 2016 SWECO 27

28 5. Analys av alternativen Alternativ 1 Central lagring Påverkan på branschens IT-system Central lagring medför förändrade förutsättningar och krav på de IT-system som aktörerna behöver vara utrustade med. Följande bild är hämtad från den norska designen av processen för hantering av volymserier. Figur 10 - Processen för distribution av volymserier i Norge Källa: Elhub BRS Måleverdier, BRS-NO-313 Oversendelse av volumserier for målepunkt Bilden visar att mätvärden skickas från den som samlar in mätvärden (nätägaren eller dennes ombud) direkt till hubben. Innan de sänds ska alla värden vara validerade, estimerade eller justerade enligt ett fastställt regelverk. I Norge har för Elhub fastställts en VEE-guide som beskriver reglerna för Validation, Estimation and Editing av mätdata. Från hubben distribueras mätvärden till de parter som har behov av dem, dvs elhandlare och tredjepartsleverantörer samt även tillbaka till nätägaren. I Norge har valts att sända ut de godkända mätserierna omgående till de aktörer som enligt regelverket behöver dessa. Respektive aktör abonnerar på de serier man behöver. Abonnemanget är obligatoriskt för elhandlare, men frivilligt för nätägare och tredjepartsleverantörer. Alla behöriga aktörer kan i efterhand via fråga begära att få valfri serie tillsänd från hubben. Anledningen till att mätvärden skickas tillbaka till nätägaren från hubben är att man vill säkerställa att nätägarens fakturering baseras på samma godkända mätvärden som elhandlaren använder. Om man senare väljer att införa samfakturering baserat på grossistmodellen (engrosmodellen i Danmark), och där hubben beräknar nätavgifterna behöver mätserierna inte nödvändigtvis återrapporteras till nätägaren. LAGRING AV DATA I EN TJÄNSTEHUBB SWECO 28

29 Denna utformning av processen reducerar kraven på mätdatabaser hos nätägarna jämfört med dagsläget. Då all avräkning utförs i hubben behöver nätägare inga system för att beräkna aggregerade serier för nätavräkningen. Man behöver inte heller en mätdatabas för att lagra avräkningsdata. Behovet av separata mätdatabaser för lagring av mätvärden för fakturaunderlag reduceras. Underlaget för fakturering levereras (eller hämtas) från tjänstehubben och lagras direkt i faktureringssystemets databas 2. Där lagras då enbart de data som legat till grund för fakturan, dvs om man har timvärden men fakturerar per månad är det tillräckligt att spara månadsvärdet. Detta kommer också att vara det arkiv för mätvärden som krävs enligt bokföringslagen m fl. De befintliga systemen kan behöva kompletteras med funktionalitet för validering och estimering enligt de riktlinjer som beslutas. Det kan göras endera i AMR-systemen eller i MDMS-systemen. Central lagring reducerar därför kraven på lagring lokalt hos nätägare. Det är dock troligt att flertalet nätägare väljer att behålla befintliga system tills vidare, men på sikt kan den här modellen innebära något förenklade system hos nätägarna. Vi har i analysen nedan valt att bortse från att detta långsiktigt kan innebära en kostnadsreduktion Påverkan på energiföretagens organisation Då vi förutsätter en central tjänstehubb med samma funktionalitet oavsett om mätdata lagras centralt eller decentralt kommer påverkan på företagens organisation att vara i stort sett den samma i alla alternativ. Här görs dock några noteringar som exemplifierar vilka förändringar som kommer att bli aktuella även om de är lika i alla alternativ. Förändringar som berör andra aktörer, främst energitjänstföretag, behandlas inte här eftersom det i nuläget är oklart hur dessa kommer att arbeta och sannolikt inte är alternativskiljande. Nätägare Den elhandlarcentriska modellen förväntas medföra en betydande reduktion av ärenden till kundtjänsten hos nätägare. Då nätavräkning utförs i hubben slipper nätägarna denna uppgift, vilket kommer att betyda möjligheter att reducera personalresurserna ganska påtagligt. Nätägaren behöver endast kontrollera att inrapporteringen av mätvärden till hubben är komplett. Det görs med funktioner i hubben där man kontrollerar nätområdesbalansen, status på inrapporterade mätserier och att beräkningen av nätförlusterna gett rimliga värden. Nätägare blir inte heller involverade i leverantörsbytesprocessen eftersom den enbart berör handelssidan. Även det en betydande reduktion av resursbehovet. Vidare kommer nätägarna att avlastas det mesta av arbetet i samband med att kunder flyttar. Uppgiften utförs av elhandlaren, och nätägare får nya kunduppgifter, men behöver inte agera. Om samfakturering kommer att utföras enligt grossistmodellen med beräkning av nätavgifter i hubben (som i Danmark) bortfaller även arbetet med fakturering hos nätägare. I nuläget är det dock fortfarande lika sannolikt att beräkning av nätavgifterna ska utföras av nätägaren, vilket innebär att det mesta av faktureringsarbetet kvarstår. Man befrias dock från uppgiften att bevaka betalningar och kravprocessen. 2 Detta gäller naturligtvis enbart i de fall då mätdata lagras både i en separat mätdatabas och i faktureringssystemets databas. 18 APRIL 2016 SWECO 29