An error has occured...

Effektiv sluttbrukermarkedfor kraftUtkast M4 – Øvrige forretningsprosesser1

Innhold1.1 Referanser 31.2 Mål 4 - En løsning som er nøytral og som effektivt støtter dagens og morgendagens behov imarkedet (forretnings- og kundeprosesser) 31.2.1 Data- eller Kommunikasjons HUB 41.2.2 Finn målepunkt ID 51.2.2.1 Datautveksling for å finne målepunkt ID i en desentral løsning ..................................................................... 61.2.2.2 Datautveksling for å finne målepunkt ID i en sentralisert løsning .................................................................. 71.2.3 Leverandørskifte 71.2.3.1 Datautveksling for leverandørskifte i en desentral løsning ............................................................................. 81.2.3.2 Datautveksling for leverandørskifte i en sentralisert løsning .......................................................................... 91.2.3.3 Forskjeller: Leverandørskifte i desentralisert og sentralisert løsning ............................................................ 101.2.4 Anleggsovertakelse 101.2.4.1 Datautveksling for anleggsovertakelse i en desentral løsning ....................................................................... 101.2.4.2 Datautveksling for anleggsovertakelse i en sentralisert løsning .................................................................... 111.2.5 Opphør av kraftleveranse 131.2.5.11.2.5.2Datautveksling for opphør av kraftleveranse i en desentral løsning.............................................................. 13Datautveksling for opphør av kraftleveranse i en sentralisert løsning .......................................................... 141.2.6 Opphør av kraftleveranse og overføring av kraft 151.2.6.11.2.6.2Datautveksling for opphør av kraftleveranse og overføring av kraft i en desentral løsning .......................... 15Datautveksling for opphør av kraftleveranse og overføring av kraft i en sentralisert løsning ....................... 161.2.7 Målerbytte 171.2.7.11.2.7.2Datautveksling for målerbytte i en desentral løsning .................................................................................... 17Datautveksling for målerbytte i en sentralisert løsning ................................................................................. 181.2.8 Oppdatering av grunnlagsdata fra Nettselskap 181.2.8.11.2.8.2Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en desentral løsning .............................. 19Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en sentralisert løsning ........................... 201.2.9 Oppdatering av grunnlagsdata fra kraftleverandør 211.2.9.1 Datautveksling for oppdatering av grunnlagsdata fra kraftleverandør i en desentral løsning ....................... 211.2.9.2 Datautveksling for oppdatering av grunnlagsdata fra Kraftleverandør i en sentralisert løsning ................... 221.2.10 Innsamling og distribusjon av måleverdier til sluttkunde og leverandører for analyse ogbeslutningsstøtte 231.2.10.1 Datautveksling for innsamling og distribusjon av måleverdier i en desentral løsning .................................. 231.2.10.2 Datautveksling for innsamling og distribusjon av måleverdier i en sentralisert løsning ............................... 241.2.11 Leverandøravregning (Måledata kundeavregning?) 241.2.11.1 Datautveksling for måledata for kundeavregning i en desentral løsning....................................................... 251.2.11.2 Datautveksling for måledata for kundeavregning i en sentralisert løsning ................................................... 261.2.12 Ukeavregning (Måledata balanseavregning?) 271.2.12.1 Datautveksling for ukeavregning i en desentral løsning ............................................................................... 281.2.12.2 Datautveksling for ukeavregning i en sentralisert løsning ............................................................................ 291.2.13 Avvikshåndtering 301.2.13.1 Datautveksling for avvikshåndtering i en desentral løsning .......................................................................... 301.2.13.2 Datautveksling for avvikshåndtering i en sentralisert løsning ...................................................................... 31VEDLEGG A KARTLEGGING AV ROLLEMODELL OG INFORMASJONSFLYT .......... 32A.1 Kort om metodikk 32A.2 ESK rollemodell 33A.3 Definisjoner av roller og domener 342

1.1 Referanser[1] Forskrift om måling, avregning og samordnet opptreden ved kraftomsetning og fakturering avnettjenester av 11. mars 1999, nr. 301, med til en hver tid siste endring, NVE, www.nve.no[2] Ediel Portalen, www.ediel.no[3] Prosessbeskrivelser for avregningsgrunnlag, siste versjon, www.ediel.no[4] Prosessbeskrivelser for utveksling av grunnlagsdata i den norske kraftbransjen www.ediel.no[5] Rollemodell for det norske kraftmarkedet, www.ediel.no[6] Rollemodell for det europeiske kraftmarkedet fra ebIX ® , EFET og ETSO (ETSO HarmonisedElectricity Role Model), https://www.entsoe.eu/resources/edi-library/[7] «Høring – rapport om overføring av myndighetsoppgaver fra de lokale eltilsyn (DLE) tilDSBs regionkontorer (fase 1-rapporten) og rapport om innhold, oppgaver og oppfølging aveventuelt konkurranseutsatt teknisk tilstandskontroll (fase 2-rapporten)» fra Justis- ogberedskapsdepartementet, sehttp://www.regjeringen.no/nb/dep/jd/dok/hoeringer/hoeringsdok/2004/horing-fremtidigorganisering-av-de-loka/1.html?id=97157.[8] «Hovedtall fra NVEs leverandørskrifteundersøkelse 3. kvartal 2011» fra NVE, sehttp://www.nve.no/PageFiles/812/Leverand%c3%b8rskifter_hovedtall%203%20kv%202011.pdf?epslanguage=no[9] NordREGs reccomendation on the future model for billing customers in the harmonisedNordic end-user market, December 19 th 20111.2 Mål 4 - En løsning som er nøytral og som effektivt støtter dagens og morgendagensbehov i markedet (forretnings- og kundeprosesser)Leverandørbytte, oppstart og anleggsovertakelse, avregning, leveringsplikt, målerdata ihht. krav frajustervesenet, balanseavregning, inndriving av avgifter, diverse funksjoner som er til nytte fornettselskapene i utvikling og drift av nettet (struping, måling, styring), demand respons, positivtforbruk.Noen spørsmål fra Ove:A) Hvordan beskriver vi «særnorske prosesser», som Agdermodellen, i forhold til «M5Tilpasset et felles nordisk sluttbrukermarked og fremtidig utvikling i EU»? Denneprosessen passer dårlig inn i en «leverandørsentrisk modell».B) Burde vi kalle Sluttbruker fakturerings ansvarlig for Faktureringstjenesteyter, som ernavnet brukt i Norsk rollemodell [5]?C) I henhold til adresseregisteret i Ediel-portalen er det registrert 167 nettskap. Burde viendre «ca 130 nettselskap» til «167» eller «ca 170 nettselskap»?Noen generelle kommentarer til beskrivelsen av forretningsprosessene:Datautveksling mellom interne roller i et Nettselskap, hos en Kraftleverandør eller i en sentralHUB er i hovedsak ikke beskrevet i forretningsprosessene under, siden dette høyst sannsynligvil bli håndtert direkte i aktørenes datasystemer. Det er i hovedsak kun den rollen som eransvarlig for ekstern datautveksling som er beskrevet. Dette medfører at enkelte avforretningsprosessene har flere roller i en sentralisert modell enn i en desentral modell.Unntaket er forretningsprosessene «Innsamling og distribusjon av måleverdier» og«Totalfakturering utført av kraftleverandørene» som er nye prosesser i bransjen og derfor erbeskrevet noe mer detaljert enn de andre forretningsprosessene.Rollen Målepunktansvarlig er kun ansvarlig for enkeltobservasjoner for det enkelteMålepunkt. Aggregering av måleverdier, bl.a. for avregningsformål, forutsettes gjort av rollenBeregningsansvarlig. Oppsplitting i disse to rollene gjør det mulig å la nettselskapet væreansvarlig for avlesning og kvalitetssikring av måleverdier, mens en sentral hub kan ta seg avaggregering og beregning på måledata.Comment [A1]: Hva inkluderer denneprosessen?Comment [A2]: Hva er forskjellen på«avregning» og «ballanseavregning»?Burde avregning være avviksoppgjør?Comment [A3]: Beskrevet i 1.2.8Comment [A4]: Antar at det er denneprosessen som er beskrevet i 1.2.9 (?)3

Danmark har i forbindelse med datahub’en, implementert ebIX ® prosessene nesten til 100 %.Det er imidlertid noen forskjeller mellom ebIX ® prosessene og det som i dag er implementert iNorge. Et eksempel er dokumentet (melingen) «bekreftelse på leveringsstart»(leverandørskifte) der vi i Norge kombinerer bekreftelsen og tilhørende grunnlagsdata, mensebIX ® splitter dette i to dokumenter. I de etterfølgende prosessbeskrivelsene er ebIX ®tilpassingene foreslått implementert, bl.a. for å tilpasse modellene til et felles nordisksluttbrukermarked.1.2.1 Data- eller Kommunikasjons HUBKan figurene under benyttes for å beskrive forskjellen mellom en kommunikasjons HUB (desentralmodell) og en Data HUB (sentralisert modell)?Figur 1 UseCase diagram for kommunikasjons HUB4

Figur 2 UseCase diagram for Data HUB1.2.2 Finn målepunkt IDProsessen «Finne målepunkt ID» er i dagens modell løst gjennom NUBIX.I en sentralisert modell vil Kraftleverandør sende meldingen «Finne målepunkt ID til en sentral HUB(i rollen som Målepunktadministrator) som håndterer prosessen. Nettselskapet vil ikke ha noen rolle iprosessen.5

1.2.2.1 Datautveksling for å finne målepunkt ID i en desentral løsningFigur 3 Sekvensdiagram for l for å finne målepunkt ID i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKonsistent datahåndtering mot allenettselskapHøy grad av tilgjengelighetRask verifikasjon av målepunkt IDFeil i sentralen (NUBIX) vil ha konsekvensfor alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKan enkelt utvides med nye dataelementereller meldingerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)Det kreves høye krav til oppetid hos allenettselskaper6

1.2.2.2 Datautveksling for å finne målepunkt ID i en sentralisert løsningFigur 4 Sekvensdiagram for å finne målepunkt ID i en sentralisert løsningStyrkerSvakheterKort implementeringstidBenytter kjent modellKraftleverandørene kan benytte dagensløsning, evt. med enkle utvidelserEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett stedNettselskap slipper eget grensesnitt mot KISDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingMuligheterTruslerRask integrasjon ved utvidelse, f.eks. mednye dataelementer eller meldingerNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneKostnadsrisikoImplementasjonsrisikoFeil teknologivalgDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speiling1.2.3 LeverandørskifteVed et leverandørskifte sender Ny kraftleverandør «Melding om leveringsstart» tilMålepunktadministrator (i dag nettselskapet). Målepunktadministrator kontrollerer mottatt «Meldingom leveringsstart», bekrefter leverandørskiftet til Ny kraftleverandør ved å sende «Bekreftelse påleveringsstart» og informerer Gammel kraftleverandør om leverandørskiftet ved å sende «Melding omopphør». «Bekreftelse på leveringsstart» kan være negativ, det vil si en avvisning av leverandørskiftet.Dersom leverandørskiftet avvises må prosessen startes på nytt av Kraftleverandør etter at årsaken tilavvisning er løst. Inntil full implementering av AMS er gjennomført må prosessen omfatteunderprosessen «Skaff målerstand» for profilavregnede målepunkter.Dersom Sluttbruker bruker angreretten, må prosessen inneholde en mulighet for å kansellereleverandørskiftet. Dette gjøres ved at Ny kraftleverandør sender «Kansellering av Melding omleveringsstart» som kan sendes inntil en virkedag før dato for leverandørskifte. Meldingen vil være7

tilsvarende «Melding om leveringsstart», men med informasjon om at dette er enkanselleringsmelding.Sluttbruker har en rolle i prosessen (starter prosessen ved å tegne kontrakt med ny leverandør) men erikke tatt med i de videre diagrammene.1.2.3.1 Datautveksling for leverandørskifte i en desentral løsningFigur 5 Sekvensdiagram for leverandørskifte i en desentral løsningI Figur 5 vises meldingsflyt mellom Kraftleverandør og Nettselskap. I det virkelige liv vil prosessen itillegg omfatte:Kontakt mellom Sluttbruker og Kraftleverandør for å inngå en kraftleveransekontrakt.Kraftleverandør må finne målepunkt ID og eventuelt Nettselskap. I dagens modell måKraftleverandør sende melding til riktig Nettselskap.I dagens modell må Kraftleverandør skaffe til veie skiftestand for profilavregnede (ikkefjernavleste) Målepunkter. Videre må Nettselskapet validere skiftestanden og distribueredenne til både ny og gammel Kraftleverandør. Disse prosessene vil imidlertid forsvinne iforbindelse med innføring av AMS.StyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap måkommunisere med hverandreStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandører8

Skille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.3.2 Datautveksling for leverandørskifte i en sentralisert løsningFigur 6 Sekvensdiagram for leverandørskifte i en sentralisert løsningI en sentralisert modell vil Kraftleverandør sende «Melding om leveringsstart (leverandørskifte)», iprinsippet kun med målepunkt ID, til en sentral HUB (i rollen som Målepunktadministrator) somhåndterer leverandørskiftet. Nettselskapet vil ikke ha noen rolle i leverandørskifteprosessen.StyrkerSvakheterKraftleverandørene benytter kjent modellNettselskapene slipper å tenke påleverandørskifterEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetOmfattende prosess som krever langimplementeringstidMuligheterTruslerRask integrasjon ved utvidelseNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneMulig å forta leverandørskifte i «realtime»KostnadsrisikoImplementasjonsrisikoFeil teknologivalg9

1.2.3.3 Forskjeller: Leverandørskifte i desentralisert og sentralisert løsningI en sentralisert løsning vil:Kraftleverandørene forholder seg til en HUB istedenfor ca 130 NettselskapNettselskapene slipper all datautveksling i forbindelse med leverandørskifter. I 2011 ble detforetatt ca 200.000 leverandørskifter i Norge (kilde: [8]). I dagens modell trigger hvertleverandørskifte minst 4 meldinger fra Nettselskapene:o «Melding om bekreftelse på leveringsstart» til ny Kraftleverandøro «Melding om opphør» til gammel Kraftleverandøro «Melding med skiftestand» til ny Kraftleverandøro «Melding med skiftestand» til gammel KraftleverandørMed en sentralisert løsning bør det være mulig å foreta leverandørskifter i «realtime» og ikke6 dager eller mer, som i dag.Comment [A5]: Disse meldingeneforsvinner med innføring av AMS uansett –Skal de være med i rapporten?1.2.4 AnleggsovertakelseProsessen for anleggsovertakelse inkluderer prosessen for oppstart på et anlegg som en Sluttbrukerovertar. Det kan for eksempel være ved flytting, overtakelse av fritidsbolig eller når en bedrift overtarnye lokaler. Felles for disse situasjonene er en endring i den som står som ansvarlig på Målepunktet.Også ved anleggsovertakelse skal «Melding om leveringsstart» benyttes. Forskjellen fra etleverandørskifte er at navn, anleggsadresse og eventuell fakturaadresse inkluderes i meldingen.Målepunktadministrator skal akseptere anleggsovertakelse inntil 30 virkedager før mottatt «Meldingom leveringsstart», noe som kan medføre avviksoppgjør mot Ny og gammel kraftleverandør.Sluttkunde har en rolle i prosessen (starter prosessen ved å tegne kontrakt med ny kraftleverandør)men er ikke tatt med i diagrammene videre.1.2.4.1 Datautveksling for anleggsovertakelse i en desentral løsningFigur 7 Sekvensdiagram for anleggsovertakelse i en desentral løsning10

I Figur 7 vises meldingsflyt mellom Kraftleverandør og Nettselskap. I det virkelige liv vil prosessen itillegg omfatte:Kontakt mellom Sluttbruker og Kraftleverandør for å inngå en kraftleveransekontrakt.Kraftleverandør må finne målepunkt ID og eventuelt Nettselskap. I dagens modell måKraftleverandør sende melding til riktig Nettselskap.I dagens modell må Kraftleverandør skaffe til veie skiftestand for profilavregnede (ikkefjernavleste) Målepunkter. Videre må Nettselskapet validere skiftestanden og distribueredenne til både ny og gammel Kraftleverandør. Disse prosessene vil imidlertid forsvinne iforbindelse med innføring av AMS.StyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.4.2 Datautveksling for anleggsovertakelse i en sentralisert løsning11

Figur 8 Sekvensdiagram for anleggsovertakelse i en sentralisert løsningI en sentralisert modell vil Kraftleverandør sende «Melding om leveringsstart (anleggsovertagelse)», iprinsippet kun med målepunkt ID, til en sentral HUB (i rollen som Målepunktadministrator), somhåndterer leverandørskiftet.Siden det kommer en ny Sluttbruker i Målepunktet trenger Nettselskapet informasjon om blant annetnavn på Sluttbruker denne informasjonen vil videresendes til Nettselskapet fra HUB’en. Dette erimidlertid en langt enklere prosess enn dagens prosess for anleggsovertakelse.I en sentralisert løsning vil:Kraftleverandørene forholder seg til en HUB istedenfor ca 130 NettselskapNettselskapene slipper med en informasjonsmelding fra den sentrale HUB’en, medinformasjon om den nye Sluttbrukeren i Målepunktet. Det foretas ca. 375.000 flyttinger per åri Norge (kilde [7]). I dagens modell trigger hver anleggsovertakelse minst 4 meldinger fraNettselskapene:o «Melding om bekreftelse på leveringsstart» til ny Kraftleverandøro «Melding om opphør» til gammel Kraftleverandøro «Melding med skiftestand» til ny Kraftleverandøro «Melding med skiftestand» til gammel KraftleverandørMed en sentralisert løsning bør det være mulig å foreta anleggsovertakelse i «realtime».Comment [A6]: Disse meldingeneforsvinner med innføring av AMS uansett –Skal de være med i rapporten?StyrkerSvakheterKraftleverandørene benytter kjent modellNettselskapene får mindre å gjøre vedanleggsovertagelser, kun oppdatering avkundeinformasjonEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetOmfattende prosess som krever langimplementeringstidMuligheterTruslerRask integrasjon ved utvidelseNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneMulig å forta anleggsovertakelser i«realtime»KostnadsrisikoImplementasjonsrisikoFeil teknologivalg12

1.2.5 Opphør av kraftleveranseDenne prosessen benyttes når Kraftleverandør stopper kraftleveransen til et målepunkt. Årsaker tilkontraktsopphør fra Sluttbruker/Kraftleverandør kan for eksempel være konkurs, dødsbo, dårligbetaler, utløp av kontrakt, osv.Sekvensdiagrammet viser meldingsgangen ved opphør av kraftleveranse. Kraftleverandøren sender«Opphør av kraftleveranse» til nettselskapet senest 3 virkedager før opphør av kraftleveranse. Dersommeldingen kan aksepteres returnerer nettselskapet «Bekreftelse på melding om opphør». Alternativt,dersom meldingen ikke er i henhold til forretningsregler eller forskrifter sendes «Avvising av meldingom opphør». Nettselskapet skal sende «Melding om opphør» senest 2 virkedager etter mottak av«Opphør av kraftleveranse» fra Kraftleverandør.I dagens modell må Kraftleverandør skaffe til veie skiftestand for profilavregnede (ikke fjernavleste)Målepunkter. Videre må Nettselskapet validere skiftestanden og distribuere denne til både ny oggammel Kraftleverandør. Disse prosessene vil imidlertid forsvinne i forbindelse med innføring avAMS.1.2.5.1 Datautveksling for opphør av kraftleveranse i en desentral løsningFigur 9 Sekvensdiagram for opphør av kraftleveranse i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfylt13

Endring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.5.2 Datautveksling for opphør av kraftleveranse i en sentralisert løsningFigur 10 Sekvensdiagram for opphør av kraftleveranse i en sentralisert løsningStyrkerSvakheterKraftleverandørene benytter kjent modellNettselskapene slipper å tenke på opphørEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetDet må etableres en ny prosess for«leveringspliktig kraftleverandør»MuligheterTruslerRask integrasjon ved utvidelseNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneOpphør kan skje «realtime»KostnadsrisikoImplementasjonsrisikoFeil teknologivalgSpørsmål:1. Trenger vi en prosess for å stenge?14

1.2.6 Opphør av kraftleveranse og overføring av kraftDenne prosessen benyttes når Sluttbruker tar kontakt med Kraftleverandør og melder kombinertopphør av kraftleveranse og overføring av kraft. Prosessen kan for eksempel benyttes ved konkurs.Kraftleverandøren sender «Opphør av kraftleveranse og overføring av kraft» til Nettselskapet. Detanbefales at Nettselskapet skapet godtar «Opphør av kraftleveranse og overføring av kraft» minimum15 dager tilbake i tid.Dersom meldingen kan aksepteres returnerer Nettselskapet «Bekreftelse på melding om opphør».Alternativt, dersom meldingen ikke er i henhold til forretningsregler eller forskrifter, sendes «Avvisingav melding om opphør». «Bekreftelse eller avvising av melding om opphør» skal sendes senest 2virkedager etter mottak av «Opphør av kraftleveranse og overføring av kraft» Kraftleverandør.I dagens modell må Kraftleverandør skaffe til veie skiftestand for profilavregnede (ikke fjernavleste)Målepunkter. Videre må Nettselskapet validere skiftestanden og distribuere denne til både ny oggammel Kraftleverandør. Disse prosessene vil imidlertid forsvinne i forbindelse med innføring avAMS.1.2.6.1 Datautveksling for opphør av kraftleveranse og overføring av kraft i en desentralløsningFigur 11 Sekvensdiagram for opphør av kraftleveranse og overføring av kraft i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interne15

leverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.6.2 Datautveksling for opphør av kraftleveranse og overføring av kraft i en sentralisertløsningFigur 12 Sekvensdiagram for opphør av kraftleveranse og overføring av kraft i en sentralisert løsningStyrkerSvakheterKraftleverandørene benytter kjent modellNettselskapene får en enklere prosess enn i endesentral modellEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan i hovedsak gjøresett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetOmfattende prosess som krever langimplementeringstidMuligheterTruslerRask integrasjon ved utvidelseNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneKostnadsrisikoImplementasjonsrisikoFeil teknologivalgSpørsmål:2. Trenger vi en prosess for å stenge?16

1.2.7 MålerbytteI forbindelse med målerbytte sendes «Melding om målerbytte». Det er anledning til å endre følgendeattributter tilknyttet målepunktet i forbindelse med målerbytte:Avregningsmetode (timemålt eller profilavregnet anlegg). Dersom et timemålt anleggavregnes som profilavregnet skal nettselskapet behandle dette som et profilavregnet anleggoverfor kraftleverandør.Innhentingsmetode (fjernavlest, manuelt avlest eller umålt)KonstantAntall sifferAvlesningsfrekvensDato for første avlesningMålernummerDersom de overnevnte attributtene skal endres uten at det er foretatt et målerbytte, inkludert endringav kun målernummer, benyttes «Oppdatering av grunnlagsdata fra nettselskap».Meldingen skal sendes til både eksisterende kraftleverandør og Ny kraftleverandør dersom det finnesen Ny kraftleverandør som har mottatt «Bekreftelse på leverandørskifte» fram i tid.1.2.7.1 Datautveksling for målerbytte i en desentral løsningFigur 13 Sekvensdiagram for målerbytte i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskap17

MuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.7.2 Datautveksling for målerbytte i en sentralisert løsningFigur 14 Sekvensdiagram for målerbytte i en sentralisert løsningStyrkerSvakheterKraftleverandørene og nettselskapenebenytter kjent modellDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingLite å spare i forhold til en desentral modellMuligheterTruslerNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneKostnadsrisikoImplementasjonsrisikoFeil teknologivalg1.2.8 Oppdatering av grunnlagsdata fra Nettselskap«Melding om grunnlagsdata fra nettselskap» skal sendes fra nettselskapet ved endringer i attributterfor målepunktet, måleren eller sluttkunden. Unntatt er situasjonen ved målerbytte, hvor det er påkrevdmed «Melding om målerbytte».18

«Melding om grunnlagsdata fra nettselskap» er splittet i undertyper (transaksjonsårsak) slik atkraftleverandøren lettere kan se hvilke endringer som er gjort i Målepunktet:Transaksjonsårsak:Beskrivelse:E32 Oppdatering av grunnlagsdata, målepunkt. Benyttes når det har skjedd endringer imålepunktet som ikke trenger egen måleravlesning.E34 Oppdatering av grunnlagsdata, sluttkunde. Benyttes i forbindelse med endring avsluttkunde informasjon (endring av navn og/eller adresse).E58 Oppdatering av grunnlagsdata, måler. Benyttes når det er skjedd endringer i målerkarakteristikkerog det ikke er nødvendig med en måleravlesning i tilknytning tilendringen.E64 Oppdatering av grunnlagsdata, målepunkt, som krever måleravlesning. Benyttes nårdet er nødvendig med en måleravlesning i tilknytning til en endring.Z28 Porteføljeoversikt er litt spesiell og har følgende regelverk: Porteføljeoversikten sendes kun på forespørsel (mail, telefon etc.) Porteføljeoversikten skal kun benyttes som status og ikke som informasjonom endringer i nettselskapets systemer. Porteføljeoversikten kan sendes:o for alle målepunkter kraftleverandør har i nettet (utvekslingspunkt)o pr. komponentkodeo for enkeltmålepunkter Dersom kraftleverandør ønsker å få tilsendt porteføljeoversikt for at antallenkeltmålepunkter anbefales det at det maksimalt bes om 10 målepunkter.Ved flere enn 10 målepunkter bør det benyttes samleoversikter (prkraftleverandør eller komponentkode).1.2.8.1 Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en desentral løsningFigur 15 Sekvensdiagram for oppdatering av grunnlagsdata fra nettselskap i en desentralisert løsning19

StyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.8.2 Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en sentralisertløsningFigur 16 Sekvensdiagram for oppdatering av grunnlagsdata fra nettselskap i en sentralisert løsningStyrkerSvakheter20

Kraftleverandørene benytter kjent modellNettselskapene får en enklere prosess enn i endesentral modellEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan i hovedsak gjøresett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetOmfattende prosess som krever langimplementeringstidMuligheterTruslerRask integrasjon ved utvidelseNye "nett"-oppgaver kan legges til sentralenLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneKostnadsrisikoImplementasjonsrisikoFeil teknologivalg1.2.9 Oppdatering av grunnlagsdata fra kraftleverandørEndring av grunnlagsinformasjon fra kraftleverandør sendes ved endringer i sluttkundedata.1.2.9.1 Datautveksling for oppdatering av grunnlagsdata fra kraftleverandør i en desentralløsningFigur 17 Sekvensdiagram for oppdatering av grunnlagsdata fra kraftleverandør i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTrusler21

Konsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)1.2.9.2 Datautveksling for oppdatering av grunnlagsdata fra Kraftleverandør i en sentralisertløsningFigur 18 Sekvensdiagram for oppdatering av grunnlagsdata fra kraftleverandør i en sentraliseretløsningStyrkerSvakheterKraftleverandørene og nettselskapenebenytter kjent modellDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingLite å spare i forhold til en desentral modellMuligheterTruslerRask integrasjon ved utvidelseLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneKostnadsrisikoImplementasjonsrisikoFeil teknologivalgSpørsmål:1. Her bør vi vel diskutere om det er noe kraftleverandøren kan oppdatere, som skal sendesvidere til netteier, eller om det kun er relevant for datahuben?22

1.2.10 Innsamling og distribusjon av måleverdier til sluttkunde og leverandører foranalyse og beslutningsstøtteComment [A7]: Dette kapittelet bør velflyttes til M1?Spørsmål:1. Bør det legges inn datautveksling fra kraftleverandør/nettselskap med prisinformasjon,alternativet som en egen prosess?1.2.10.1 Datautveksling for innsamling og distribusjon av måleverdier i en desentral løsningFigur 19 Sekvensdiagram for innsamling og distribusjon av måleverdier i en desentral løsningStyrkerSvakheterKort implementeringstidUtvidelse av kjent modellStor avhengighet av at 130 nettselskaper gjøralt likt, har høy kvalitet og overholdertidsfristerDyrt å endre dersom nye krav på leverandørog kundesiden. Må endre hos alle 130Vanskelig å måle kvalitet på måleverdierMuligheterTruslerStor grad av skalerbarhet i RT leddetAlltid eller ofte ett eller flere nettselskap somikke klarer kvalitetskraveneKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandører23

Måledata leverandøravregning?Måledata leverandørberegning?Med leverandøravregning menes de aktiviteter som Beregningsansvarlig (Oppgavegiver) (i dagNettselskapet) har ansvar for å utføre i forbindelse med å framskaffe avregningsgrunnlaget tilBalanseansvarlig og Kraftleverandør.Beregningsansvarlig (Oppgavegiver) (i dag nettselskap) skal på grunnlag av forbruk i de Målepunkt enBalanseansvarlig har kraftleveranse, beregne det totale kraftuttaket den Balanseansvarlige, fordelt perKraftleverandør, har hatt i Nettområdet i avregningsuken. Det totale kraftuttaket fremkommer somsummen av kraftuttaket i timeavregnede og profilavregnede målepunkter og aggregeres pr.komponentkode.1.2.11.1 Datautveksling for måledata for kundeavregning i en desentral løsningFigur 21 Sekvensdiagram for måledata for kundeavregning i en desentral løsningStyrkerNettselskapene kan benytte dagensavregningssystemer som er knyttet tiløkonomisystemeneKrever sannsynligvis mindre investeringerenn en sentral løsningSvakheter Kraftleverandørene må forholde seg til 130nettselskaper Nettselskapene må utvikle ny funksjonalitetsom muliggjør oppslag for kraftleverandøreneav historiske avregningsunderlag Utfordringer for dokumentering ogopprettholdelse av nøytralitet25

døreneDatahuben kan gjennomføre kvalitetskontroll,og overvåke innsending av data iht fastsattetidsfristerEnkel tilgang for kraftleverandører for åhente ut avregningsunderlagNøytralitet og like konkurranseforholdEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett steddatahubenKrever lang implementeringstidMuligheterTruslerLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneDatahub utfører funksjoner somleverandøravregning, balanseavregningsunderlagetc.Tredjeparter kan få et grensesnitt for å henteut forbruksdata (enøk, styring avapplikasjoner etc.)Datahub kan utvides til også å utarbeideavregningsunderlag for nett-tariffDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetRisiko ifm etablering av datahub (stort ITprosjekt)Inkonsistens mellom data hos datahub ognettselskap (måledata vs. anleggsdata)1.2.12 Ukeavregning (Måledata balanseavregning?)Med ukeavregning menes de aktiviteter som Beregningsansvarlig (Oppgavegiver) (i dag Nettselskapet)har ansvar for å utføre i forbindelse med å framskaffe grunnlag for avregning av regulerkraft, påkraften hver enkelt Balanseansvarlig tar ut i Nettområdet.Avregningsperioden for regulerkraft er i dag en uke.Avregningsansvarlig foretar økonomisk avregning mot Balanseansvarlig av differansen mellomkraftuttaket som Balanseansvarlig har forhåndsmeldt og det kraftuttak som Nettselskap rapporterer iNettområdet.27

1.2.12.1 Datautveksling for ukeavregning i en desentral løsningFigur 23 Sekvensdiagram for ukeavregning i en desentral løsningNoen kommentarer til Figur 23:Dersom det oppstår avvik før balanseavregningen er kjørt vil det bli sent korrigerte aggregertemåleverdier til Avregningsansvarlig og Balanseansvarlig (pil 3 og 4), samt korrigertevaliderte måleverdier til Kraftleverandør (pil 5).StyrkerNettselskapene kan benytte dagensavregningssystemer som er knyttet tiløkonomisystemeneTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidSvakheter Feil i kommunikasjons HUB vil hakonsekvens for alle Kraftleverandørene må forholde seg til 130nettselskaper Stor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitet Dyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerNettselskaper kan samarbeide om avregningsfunksjonenfor å søke stordriftsfordelerObligatorisk bruk av kommunikasjonsløsningenvil bedre konkurransen mellomuavhengige leverandører og selvstendigeleverandørerKonkurranse fra systemleverandører forKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfylt28

tilpasning av løsninger til kraftleverandørerog nettselskap1.2.12.2 Datautveksling for ukeavregning i en sentralisert løsningFigur 24 Sekvensdiagram for ukeavregning i en sentralisert løsningStyrkerSvakheter«single point of contact» for avregningsansvarligDatahuben kan gjennomføre kvalitetskontroll,og overvåke innsending av data iht fastsattetidsfristerNøytralitet og like konkurranseforholdEndringer (f.eks. forskriftsendringer somkrever prosessendring) kan gjøres ett stedDersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingKrever en betydelig driftsorganisasjon fordatahubenKrever lang implementeringstidMuligheterTruslerLetter integrasjon mot andre nordiskemarkeder – datahuben kan være gateway motandre datahuber i de nordiske landeneDatahub utfører funksjoner som balanseavregningsunderlagetc.Dersom datahuben feiler/ faller ut vil helebransjen bli berørt – krever gode back-upløsninger og speilingDatahuben blir stor og rigid som kan betyliten fleksibilitet og endringsdyktighetRisiko ifm etablering av datahub (stort ITprosjekt)Inkonsistens mellom data hos datahub ognettselskap (måledata vs. anleggsdata)29

1.2.13 AvvikshåndteringSpørsmål:1. Trenger vi en ny prosess for korrigeringer av feil på faktura/målerverdier? Skal vi beskrive enprosess der sluttkunden tar kontakt med kraftleverandøren, som så tar kontakt mednettselskapet, som så svarer? Burde kunne digitaliseres?1.2.13.1 Datautveksling for avvikshåndtering i en desentral løsningFigur 25 Sekvensdiagram for avvikshåndtering i en desentral løsningStyrkerSvakheterTilsvarer dagens løsning, små (ingen)kostnader for implementeringKjent prosessKort implementeringstidFeil i kommunikasjons HUB vil hakonsekvens for alleAlle kraftleverandører og nettselskap må haeget grensesnitt mot KISStor avhengighet av at 130 nettselskaper gjøralt likt og har høy kvalitetDyrt å endre dersom nye krav. Må endre hosalle 130 nettselskapMuligheterTruslerKonsekvenser av dårlig kvalitet blirskjevfordelt mellom eksterne og interneleverandørerSkille mellom nett og kraft er ikke oppfyltEndring av forskrifter/prosesser måimplementeres hos alle nettselskaper (risikofor avvik)30

Vedlegg AKartlegging av rollemodell og informasjonsflytI dette vedlegget beskrives en rollemodell for roller som benyttes i denne rapporten. Rollemodellen erbasert på Rollemodell for det norske kraftmarkedet [5], som igjen er basert på Rollemodell for deteuropeiske kraftmarkedet fra ebIX ® , EFET og ETSO [6].A.1 Kort om metodikkRollemodellen fra ebIX ® , ENTSO-E og EFET baserer seg på UML metodikk. I rollemodellen visesroller, domener og assosiasjoner mellom disse.En Rolle representerer den eksterne atferden til en aktør. Aktører kan ikke dele en rolle. Aktørerutfører sine oppgaver ved å agere i roller, som kraftleverandør, balanseansvarlig og nettoperatør.Rollene beskriver eksterne interaksjoner med andre aktører i relasjon til bestemte forretningsprosesser.Et Domene representerer et begrenset område, som er unikt identifisert, for et spesielt formål og derforbruk, produksjon eller utveksling av energi kan bestemmes.En Aktør representerer en organisasjon eller en del av en organisasjon som deltar i bestemteforretningsprosesser. Innenfor en bestemt forretningstransaksjon vil en aktør agere i et spesifikt sett avroller.Rollemodellen benytter i hovedsak 4 ulike symboler:Rolle vises som en ”fyrstikkmann” og indikerer en rolle som uføres av en aktør i bransjen.Domeneobjekter.vises som et rektangel (klasse) og indikerer et domene relatert til fysiske eller logiskeAssosiasjon vises som en pil med åpen pilspiss og viser ansvar mellom roller ogdomener. Endepunktene til en assosiasjon kan ha en kardinalitet som viser begrensninger i antallobjekter det kan være i endepunktet, for eksempel:1 = ett objekt0..1 = ingen eller ett objekt0..* = ingen eller flere objekter1..* = ett eller flere objekter32

Generalisering vises som en pil med lukket pilspiss og viser at rollen eller domenet som ligger vedpilspissen er en generalisering av rollen eller domenet i den andre enden av pilen.Den spesialiserte rollen eller domenet vil ”arve” alle egenskaper (attributter) somtillegger den generelle rollen eller domenet, og kan i tillegg ha egne egenskaper.Målet med rollemodellen er å bryte ned kraftmarkedet til et sett med autonome (uavhengige) roller ogdomener som senere kan benyttes til å definere forretningsprosesser og forretningstransaksjoner. Enaktør kan ha flere roller i markedet.Sammen med rollemodell-diagrammet finnes en liste over definisjoner for roller og domener. Iforbindelse med utveksling av informasjon vil en markedsaktør kunne finne hvilke roller han inneharog hvilke utvekslinger han må forholde seg til. En rolle må kunne ”stå på egne ben” innenforrollemodellen, med andre ord inneha en autonom funksjon i markedet.A.2 ESK rollemodellFigur 27 Rollemodell33

A.3 Definisjoner av roller og domenerRolleBeskrivelseAvregningsansvarligAvviksoppgjørsansvarlig(ESK)En rolle som er ansvarlig for avregning av forskjellen mellom avtalteog realiserte volumer for energiprodukter for de balanseansvarlige iet balanseområde.Dette er en ny rolle definert av ESK prosjektet:En rolle som er ansvarlig for avviksoppgjør ved korrigering avmåleverdier for ett Målepunkt.Dette er en rolle definert av ESK prosjektetEn rolle som har en kontrakt for finansiell sikkerhet og balanseansvarmed avregningsansvarlig for et balanseområde, som girbalanseansvarlig lov til å operere i markedet. Dette er den enesterollen som kan kjøpe og selge energi på engros nivå.BalanseansvarligBeregningsansvarlig(Oppgavegiver)KraftleverandørKraftprisavregningsansvarligMåledatainnsamlerMålepunktadministratorMåleradministratorTilleggsinformasjon:Med balanse menes i denne sammenheng at avtalt forbruk ellerproduksjon må være lik faktisk forbrukt eller produsert volum. Enbalanseansvarlig er ofte (i europeisk sammenheng) eid i felleskap avflere aktører.En rolle ansvarlig for å etablere og kvalitetssikre måledata framåleverdiansvarlig. Dataene er beregnet (aggregert) i henhold tilmarkedsregler.ESK kommentarer: Denne rollen heter Oppgavegiver i Norsk rollemodell [5]. Rollen Beregningsansvarlig mottar kvalitetssikrede måleverdierfra rollen Måleverdiansvarlig og aggregerer disse i henhold tilmarkedsregler, som pr nettområde, per Balanseansvarlig etc.En rolle som selger differansen mellom den energien som er kjøptgjennom fastenergikontrakter og variabelt kraftforbruk av aktørkoblet til kraftnett. I tillegg selger kraftleverandøren differansenmellom fastenergikontrakter, for aktør koblet til kraftnett, og måltproduksjon.Dette er en ny rolle definert av ESK prosjektet:En rolle ansvarlig for å avregne kraft for ett eller flere målepunkt.En rolle ansvarlig for måleravlesning og kvalitetskontroll påavlesningen.En rolle ansvarlig for registrering av parter tilknyttet målepunkterinnenfor et nettområde og tilhørende tekniske spesifikasjoner.Målepunktadministrator er ansvarlig for å opprette og avsluttemålepunkter.En rolle ansvarlig for en database over registre (målere).34

RolleMåleroperatørMåleverdiansvarligNettilknytningstilbyderNettoperatørSluttbrukerNettleieavregningsansvarligSluttbrukerfaktureringsansvarligBeskrivelseEn rolle ansvarlig for installering, vedlikehold, testing, sertifiseringog avslutning av fysiske målere.En rolle ansvarlig for å etablere og validere måledata framåledatainnsamler. Rollen er ansvarlig for historiske verdier formålepunktene.ESK kommentarer:Rollen er kun ansvarlig for enkeltobservasjoner for det enkeltemålepunkt. Aggregering av måleverdier, bl.a. foravregningsformål forutsettes gjort av rollen Beregningsansvarlig.En rolle ansvarlig for gi tilgang til strømnettet og tilhørende bruk forforbruk eller produksjon til aktør koblet til nett.Dette er en ny rolle definert av ESK prosjektet:En rolle ansvarlig for å avregne nettleie for ett eller flere målepunkt.En rolle som opererer en eller flere nettområder.En rolle som forbruker strøm.Dette er en ny rolle definert av ESK prosjektet:En rolle ansvarlig for å fakturere Sluttbruker.Tabell 1: Definisjon av rollerDomeneMålerMålepunktNettområdeBeskrivelseEn fysisk enhet som inneholder en eller flere registreEt punkt der energiprodukter måles.Et nettområde er et fysisk område der forbruk, produksjon ogutveksling kan måles. Nettområdet er avgrenset av målere forperiodisk avlesning av inn- og utmating fra nettområdet. Nettområdekan benyttes for å etablere sum av profilavregnede målepunkter ognettap.Tabell 2: Definisjon av domener35