"Effektivt sluttbrukermarked for kraft" (pdf.) - NVE

Effektivt sluttbrukermarked
for kraft
31. mai, 2012
1

Sluttrapport
Dokument tittel
Effektivt sluttbrukermarked for kraft
Prosjekt
23554 - ESK
Ansvarlig enhet
Statnett, Marked
Prosjektleder:
Tor B. Heiberg
Mottaker:
NVE
Mottakers kontaktperson:
Karl Magnus Ellinggard
Dato:
31.05.2012
Dokument nummer:
Versjon: 1.0
Gradering:
Offentlig
Antall sider + vedlegg:
137 + 68
Sammendrag, resultat:
Prosjektet har utredet behovet for felles IKT løsninger for å sikre et effektivt sluttbrukermarked
for kraft.
Det er prosjektets anbefaling at det etableres en datahub som skal fungere som markedets
kontaktpunkt mot nettselskapene i forhold til måleverdier, leverandørbytter, innflytting,
utflytting, oppsigelse samt autorisasjon og informasjonsutveksling i forbindelse med AMS
tilleggstjenester. Dersom mer leverandørsentriske faktureringsmodeller vedtas vil sannsynligvis
datahuben kunne spille en sentral rolle i forhold til effektivitet og nøytralitet.
Rapporten er Statnett sin utredning av felles IKT løsninger som beskrevet i
Avregningskonsesjonen punkt 11.1 og 11.3, samt i NVE sitt "vedtak om endring av
avregningskonsesjonen" datert 30.01.2012. Konsernsjef og styret i Statnett har tatt anbefalingen
til etterretning.
2

Innhold
1 UTREDNINGENS BAKGRUNN OG ARBEIDSMÅTE .................................. 9
1.1 Bakgrunn og mandat ...................................................................................... 9
1.2 Organisering og gjennomføring av utredningsprosjektet ............................ 10
1.3 Disposisjon for utredningen ......................................................................... 11
2 SAMMENDRAG ................................................................................................. 13
3 SLUTTBRUKERMARKEDET FOR KRAFT OG FELLES IKT
LØSNINGER ....................................................................................................... 17
3.1 Utfordringer med dagens modell ................................................................. 17
3.2 Alternative markedsmodeller ....................................................................... 18
3.3 Felles IKT løsninger .................................................................................... 18
4 MÅLBILDE OG METODIKK .......................................................................... 20
4.1 Konkretisering av utredningens målbilde .................................................... 20
4.2 Konseptuelle modeller ................................................................................. 21
4.3 Vurderingskriterier ....................................................................................... 23
5 HVORDAN LØSE KRAVENE TIL MARKEDSDESIGN ............................. 25
5.1 Grunnleggende krav til markedsdesign ....................................................... 25
5.2 Prosesskartlegging og roller ......................................................................... 25
5.2.1 Kommunikasjonshub ............................................................................................................ 27
5.2.2 Datahub ................................................................................................................................ 28
5.3 Grunnlagsdata .............................................................................................. 30
5.3.1 Hvem har ansvaret for hva og hvor det skal lagres.............................................................. 30
5.3.2 Datautveksling for oppdatering av grunnlagsdata i en kommunikasjonshub-modell .......... 31
5.3.3 Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en datahub .................. 32
5.4 Håndtering av måledata og avregning ......................................................... 33
5.4.1 Innsamling og distribusjon av måleverdier .......................................................................... 33
5.4.2 Distribusjon av måledata ..................................................................................................... 38
5.4.3 Rapportering til balanseavregning (Ukeavregning) ............................................................ 43
5.4.4 Avviksoppgjør ....................................................................................................................... 44
5.4.5 Kundeavregning og fakturering ........................................................................................... 46
5.5 Administrasjon av sluttbrukeren .................................................................. 58
5.5.1 Finn målepunkt-id ................................................................................................................ 58
5.5.2 Leverandørskifte ................................................................................................................... 60
5.5.3 Innflytting (anleggsovertakelse) ........................................................................................... 63
5.5.4 Utflytting .............................................................................................................................. 66
5.5.5 Oppsigelse (opphør) ............................................................................................................. 67
5.5.6 Struping og stenging ............................................................................................................. 69
5.5.7 Mikroproduksjon .................................................................................................................. 70
5.5.8 Leveringsplikt ....................................................................................................................... 70
5.6 AMS tilleggstjenester ................................................................................... 71
5.6.1 Prisinformasjon .................................................................................................................... 72
5.6.2 Nettnytte ............................................................................................................................... 72
5.6.3 3. parts produkter/tjenester og tilrettelegge for konkurranse om tilleggstjenester .............. 73
5.6.4 Infrastruktur for AMS tilleggstjenester ................................................................................ 73
5.7 Anlegg som ikke har AMS etter 2017 ......................................................... 78
5.8 Behov fra Justervesenet ............................................................................... 78
5.9 SWOT analyse for kommunikasjonshub-modell ......................................... 80
5.10 SWOT analyse for datahub-modell ............................................................. 81
6 INTERNASJONAL UTVIKLING OG FREMTIDIGE KRAV ..................... 84
3

6.1 Fremtidige krav ............................................................................................ 84
7 HVA ER BEST FOR SLUTTBRUKEREN OG BIDRAR TIL
KUNDEVENNLIGHET ..................................................................................... 86
8 ØKONOMISK ANALYSE ................................................................................. 88
8.1 Kostnads- og besparelsesanalyse ................................................................. 89
8.1.1 Målerverdiinnsamling og korreksjoner ................................................................................ 90
8.1.2 Målerhåndtering ................................................................................................................... 91
8.1.3 Avregning og fakturering, innfordring og kundeservice ...................................................... 91
8.1.4 Inngåelse og avslutning av kontrakter, flytting, leverandørskifte samt stengning og åpning
av anlegg .............................................................................................................................. 92
8.1.5 Leverandør- og ukeavregning .............................................................................................. 93
8.1.6 Kostnadsbilde for forretningsprosesser ved kommunikasjonshub og datahub ..................... 94
8.2 Utviklingskostnader og årlige driftskostnader ............................................. 95
9 YTELSE OG SIKKERHET ............................................................................... 98
9.1 Generell beskrivelse ..................................................................................... 98
9.2 Alternative scenarier .................................................................................... 99
9.2.1 Scenario 0 - Dagens løsning .............................................................................................. 100
9.2.2 Scenario 1 –Kommunikasjonshub ...................................................................................... 101
9.2.3 Scenario 2 - Meldingshub ................................................................................................... 102
9.2.4 Scenario 3 – Datahub ......................................................................................................... 103
9.3 Metodikk og generelle forutsetninger ........................................................ 105
9.4 Kapasitetsberegning ................................................................................... 107
9.4.1 Beregningsgrunnlag ........................................................................................................... 107
9.4.2 Datavolum .......................................................................................................................... 107
9.4.3 Nye eller endrede felles tjenesteprosesser .......................................................................... 109
9.4.4 Beregnings-caser ................................................................................................................ 110
9.4.5 Løsningsforutsetning .......................................................................................................... 111
9.4.6 Kapasitetsberegninger........................................................................................................ 113
9.4.7 Kapasitetsimplikasjoner og systemimplementering ............................................................ 115
9.5 Sårbarhet .................................................................................................... 116
9.5.1 Overordnede betraktninger ................................................................................................ 116
9.5.2 Sårbarhetsvurderingen ....................................................................................................... 117
9.5.3 Konsekvenser for realisering av løsninger ......................................................................... 119
9.6 Evaluering .................................................................................................. 120
9.6.1 Evaluering ut fra praktisk / økonomisk egnethet til de to scenarier ................................... 121
9.6.2 Evaluering i forhold til de generelle evalueringskriteriene............................................... 123
10 IMPLEMENTERING OG OVERGANGSLØSNINGER ............................. 126
10.1 Forskjeller mellom modellene i forhold til implementering av nye krav .. 126
10.2 Etablering ................................................................................................... 126
10.2.1 Kommunikasjonshub .......................................................................................................... 126
10.2.2 Datahub .............................................................................................................................. 126
10.3 Overgangsordning ...................................................................................... 127
10.3.1 Kommunikasjonshub .......................................................................................................... 127
10.3.2 Datahub .............................................................................................................................. 127
10.3.3 Anbefaling .......................................................................................................................... 129
11 ORGANISERING OG STYRING AV FELLES IKT LØSNING ................ 130
11.1 Oppgaver og rolle ...................................................................................... 130
11.2 Organisering av videre fremdrift ............................................................... 130
11.2.1 Forberedelse; 2012 ............................................................................................................ 130
11.2.2 Utvikling; 2013-2016 ......................................................................................................... 131
11.2.3 Drift; 2017 ...................................................................................................................... 131
11.3 Bransjens involvering ................................................................................ 131
12 OPPSUMMERING OG ANBEFALING ........................................................ 132
12.1 God kvalitet og effektiv distribusjon av måleverdier ................................ 132
4

12.2 Leverandørsentrisk modell ......................................................................... 132
12.3 Tilrettelegge for tilleggstjenester muliggjort gjennom AMS ..................... 132
12.4 Støtte ny markedsdesign ............................................................................ 133
12.5 Effektiv organisering og forvaltning av felles IKT-løsninger ................... 133
12.6 Robusthet i forhold til internasjonal integrasjon ........................................ 133
12.7 Best mulig forhold mellom kostnader og besparelser ................................ 133
12.8 Oppsummering ........................................................................................... 133
13 KONSEKVENSER VED INNFØRING AV DATAHUB .............................. 135
13.1.1 Forskriftsendringer ............................................................................................................ 135
13.1.2 Nettselskapenes tariffer ...................................................................................................... 135
13.1.3 Stenging og struping ........................................................................................................... 135
13.1.4 Samfakturering ................................................................................................................... 135
13.1.5 Standardisert grensesnitt mot AMS måler .......................................................................... 136
13.2 Konsekvenser for nettselskaper ................................................................. 136
13.2.1 Innsamling og kvalitetssikring av AMS måleverdier .......................................................... 136
13.2.2 Håndtering av markedsprosesser (leverandørskifte/flytting osv.) ...................................... 136
13.2.3 Leverandøravregning/ukeavregning. ................................................................................. 136
13.2.4 Formidling av kraftpriser og tariffer (ref. forskriftens § 4.2 f)........................................... 136
13.2.5 Overgangen til AMS ........................................................................................................... 136
13.2.6 Lokale grensesnitt på AMS måleren ................................................................................... 137
13.3 Konsekvenser for kraftleverandører .......................................................... 137
VEDLEGG A REFERANSER ............................................................................... 138
VEDLEGG B ROLLEMODELL OG INFORMASJONSFLYT ........................ 139
B.1 Kort om metodikk ...................................................................................... 139
B.2 ESK rollemodell ......................................................................................... 141
B.3 Definisjoner av roller og domener ............................................................. 142
VEDLEGG C DEFINISJONER ............................................................................. 144
VEDLEGG D SAMMENDRAG AV HØRINGSSVAR TIL ESK-PROSJEKTET
OG PROSJEKTGRUPPENS VURDERINGER ............................................ 145
D.1 Kravene til markedsdesign ......................................................................... 145
D.2 Fremtidens utvikling og internasjonale krav .............................................. 152
D.3 Kundevennlighet ........................................................................................ 152
D.4 Økonomisk analyse .................................................................................... 152
D.5 Implementering og overgangsløsninger ..................................................... 153
D.6 Organisering og styring av felles IKT løsning ........................................... 153
D.7 Andre innspill ............................................................................................. 154
VEDLEGG E HØRINGSSVAR FRA AKTØRENE ............................................ 156
E.1 BKK Nett AS ............................................................................................. 156
E.2 Energi Norge .............................................................................................. 158
E.3 Fjordkraft ................................................................................................... 165
E.4 Gudbrandsdal Energi AS ........................................................................... 167
E.5 Istad AS ...................................................................................................... 169
E.6 KS Bedrift Energi ...................................................................................... 172
VEDLEGG F KAPASITETSBEREGNING ......................................................... 176
F.1 Oppsummering ........................................................................................... 176
F.2 Volum ........................................................................................................ 178
F.3 Datahub ...................................................................................................... 181
F.4 Kommunikasjonshub basert på aktiv Meldingstjeneste ............................. 186
F.5 Kommunikasjonshub basert på ”passiv” meldingsnode ............................ 191
VEDLEGG G SÅRBARHETSBEREGNING ....................................................... 196
5

G.1 Infrastruktur datahub .................................................................................. 198
G.2 Infrastruktur kommunikasjonshub ............................................................. 200
G.3 Informasjonsmodell – Data-hub ................................................................ 202
G.4 Informasjonsmodell – Kommunikasjonshub ............................................. 204
6

Figurer
Figur 1 - Prosjektets organisering .............................................................................................................. 11
Figur 2 - Sluttbrukermarkedet for kraft pr i dag ........................................................................................ 17
Figur 3 - Målbilde knyttet til mål fra NordREG ........................................................................................ 21
Figur 4 - Konseptuell skisse for kommunikasjonshub-modell ................................................................... 22
Figur 5 - Konseptuell skisse for datahub-modell ....................................................................................... 23
Figur 6 - Evalueringskriterier for vurdering av målene M1-M10 .............................................................. 24
Figur 7 - UseCase diagram for kommunikasjonshub ................................................................................. 28
Figur 8 - UseCase diagram for datahub ..................................................................................................... 29
Figur 9 - Sekvensdiagram for oppdatering av grunnlagsdata i en kommunikasjonshub-modell ............... 31
Figur 10 - Sekvensdiagram for oppdatering av grunnlagsdata fra nettselskap i en datahub-modell .......... 32
Figur 11 - Sekvensdiagram for innsamling og distribusjon av måleverdier i en kommunikasjonshubmodell
............................................................................................................................................... 39
Figur 12 - Sekvensdiagram for innsamling og distribusjon av måleverdier i en datahub-modell .............. 41
Figur 13 - Sekvensdiagram for rapportering til balanseavregning i en kommunikasjonshub-modell........ 43
Figur 14 - Sekvensdiagram for rapportering til balanseavregning i en datahub-modell ............................ 44
Figur 15 - Sekvensdiagram for avvikshåndtering i en kommunikasjonshub-modell ................................. 45
Figur 16 - Sekvensdiagram for avvikshåndtering i en datahub-modell ..................................................... 45
Figur 17 - Totalfaktureringsmodell ............................................................................................................ 48
Figur 18 - Sekvensdiagram for avregningsunderlag for sluttbrukeravregning i en kommunikasjonshubmodell
............................................................................................................................................... 51
Figur 19 - Totalfakturering i en datahub-modell hvor nettselskapene utarbeider avregningsunderlag for
nett-tariff ........................................................................................................................................... 53
Figur 20 - Sekvensdiagram for avregningsunderlag for sluttbrukeravregning i en datahub-modell .......... 54
Figur 21 - Totalfakturering i en datahub-modell hvor datahub utarbeider avregningsunderlag for nett-tariff
(mulig fremtidig opsjon) ................................................................................................................... 56
Figur 22 - Sekvensdiagram for datautveksling for avregningsunderlag for sluttbrukeravregning med
opsjon der datahuben avregner kraft og nett-tilknytning i en datahub-modell .................................. 57
Figur 23 - Sekvensdiagram for å finne målepunkt ID i en kommunikasjonshub-modell .......................... 59
Figur 24 - Sekvensdiagram for å finne målepunkt ID i en datahub-modell ............................................... 59
Figur 25 - Sekvensdiagram for leverandørskifte i en kommunikasjonshub-modell .................................. 61
Figur 26 - Sekvensdiagram for leverandørskifte i en datahub-modell ....................................................... 62
Figur 27 - Sekvensdiagram for innflytting i en kommunikasjonshub-modell ........................................... 64
Figur 28 - Sekvensdiagram for innflytting i en datahub-modell ................................................................ 65
Figur 29 - Sekvensdiagram for utflytting i en kommunikasjonshub-modell ............................................. 66
Figur 30 - Sekvensdiagram for utflytting i en datahub-modell .................................................................. 67
Figur 31 - Sekvensdiagram for opphør av kraftleveranse i en kommunikasjonshub-modell ..................... 68
Figur 32 - Sekvensdiagram for opphør av kraftleveranse i en datahub-modell ......................................... 68
Figur 33 - AMS kommunikasjon i en kommunikasjonshub-modell i henhold til forskriften .................... 74
Figur 34 - Ansvar for AMS tilleggstjeneste komponenter og tilgjengelighet av disse i en
kommunikasjonshub-modell i henhold til forskriften ....................................................................... 74
Figur 35 - AMS kommunikasjon i en datahub-modell .............................................................................. 76
Figur 36 - Ansvar for AMS tilleggstjeneste komponenter og tilgjengelighet av disse i en datahub-modell
.......................................................................................................................................................... 76
Figur 37 - Vurdering av kundenytte for henholdsvis kommunikasjonshub og datahub ............................ 87
Figur 38 - Totale kostnader i bransjen ved håndtering av forretningsprosesser ......................................... 89
Figur 39 - Fremtidig kostnadsbilde ved innførelse av kommunikasjonshub og datahub ........................... 94
Figur 40 – Scenario 0 – Dagens løsning .................................................................................................. 100
Figur 41 – Scenario 1 – Kommunikasjonshub ......................................................................................... 101
Figur 42 - Scenario 2 – Meldingshub basert på en aktiv meldingstjeneste .............................................. 102
Figur 43 - Scenario 3- Sentral måleverdidatabase med sine dataelementer og prosesser ........................ 104
Figur 44 - Datahub vs kommunikasjonshub ............................................................................................ 106
Figur 45 - Kjerneprosesser i sentral hub .................................................................................................. 106
Figur 46 - Informasjonsinnhold i en måleverdiserie ................................................................................ 108
Figur 47 -Informasjonsinnhold i fakturagrunnlaget for nettleie ............................................................... 109
Figur 48 - Informasjonsinnhold i balanseavregningen ............................................................................. 109
Figur 49 - Informasjons-, prosess-, og infrastruktur-modell .................................................................... 116
Figur 50 - Svært overordnet presentasjon av aggregert risiko for datahub og kommunikasjonshub ....... 119
Figur 51 - Mulig faseinndeling i forhold til avhengighet av AMS .......................................................... 128
Figur 52 - Rollemodell ............................................................................................................................. 141
7

Tabeller
Tabell 1 - Prosjektets målbilde .................................................................................................................. 20
Tabell 2 - Grunnlagsdata og ansvar ........................................................................................................... 30
Tabell 3 – Tidsfrister.................................................................................................................................. 35
Tabell 4 - Kodebruk for valideringsprosessen ........................................................................................... 36
Tabell 5 - Kodebruk for standard prosesser kl. 24.00 D+5 ........................................................................ 36
Tabell 6 - Kodebruk for standard prosesser etter D+5 ............................................................................... 37
Tabell 7 - SWOT analyse for kommunikasjonshub-modell ....................................................................... 81
Tabell 8 - SWOT analyse for datahub-modell ........................................................................................... 83
Tabell 9 - Økte kostnader/besparelser for målerverdiinnsamling ved kommunikasjons- og datahub........ 91
Tabell 10 - Økte kostnader/besparelser for målerhåndtering ved kommunikasjons- og datahub .............. 91
Tabell 11 - Økte kostnader/besparelser for avregning og fakturering, innfordring og kundeservice ved
kommunikasjons- og datahub ........................................................................................................... 92
Tabell 12 - Økte kostnader/besparelser for inngåelse og avslutning av kontrakter, flytting,
leverandørskifte, og stenging og åpning av anlegg ved kommunikasjons- og datahub .................... 93
Tabell 13 - Økte kostnader/besparelser for avviksoppgjør kundeavregning og rapportering til
balanseavregning ved kommunikasjons- og datahub ........................................................................ 94
Tabell 14 - Årlige kostnader ved kommunikasjons- og datahub................................................................ 96
Tabell 15 - Anslag for samlet besparelser ved kommunikasjons- og datahub ........................................... 96
Tabell 16 - Beregnings-caser ................................................................................................................... 111
Tabell 17 - Løsningsforutsetning – datahub............................................................................................. 112
Tabell 18 - Løsningsforutsetninger - Kommunikasjonshub ..................................................................... 113
Tabell 19 - Fordelingsmatrise .................................................................................................................. 113
Tabell 20 - Kapasitetsberegninger (minimum) – teoretisk kapasitet i minutter (og GB for lagring) ....... 114
Tabell 21 - SWOT analyse for sikkerhet ved løsningen med kommunikasjonshub ................................ 121
Tabell 22 - SWOT analyse for sikkerhet ved løsningen med datahub ..................................................... 122
Tabell 23 - Definisjon av roller ................................................................................................................ 143
Tabell 24 - Definisjon av domener .......................................................................................................... 143
8

1 Utredningens bakgrunn og arbeidsmåte
Kapittelet gir en beskrivelse av prosjektets bakgrunn, mandat gitt av NVE og hvordan
arbeidet har blitt organisert og ledet. Til slutt i kapittelet gis en beskrivelse av
rapportens struktur og innhold.
1.1 Bakgrunn og mandat
I juni 2011 vedtok NVE forskriftsendringer som pålegger innføring av avanserte måleog
styringssystemer (AMS). Det medfører at alle målepunkter skal ha en AMS-måler
installert med toveis kommunikasjon som skal foreta timemåling og gjøre tilgjengelig
verdiene minst en gang i døgnet. Kravene til AMS skal være oppfylt innen 2017. AMS
vil gjøre smarte løsninger realiserbare. Smarte løsninger representerer nye muligheter
for forbrukerne, kraftleverandører og ikke minst nettselskaper som vil få mulighet til å
innføre smarte distribusjonsnett. På nordisk plan gjennomfører NordREG et omfattende
arbeid hvor det vurderes å endre regler og prosesser for å skape et felles nordisk
sluttbrukermarked for strøm. Dette arbeidet gir føringer også inn mot det norske
markedet og den fremtidige strukturen på hvordan roller, ansvar og prosesser fordeles
mellom aktørene. Føringer fra NordREG er hensyntatt i utredningen.
AMS-kravene som nettselskapene nå står ovenfor er omfattende, og det stiller krav til
koordinering blant markedsaktørene for at samfunnet skal kunne ta ut potensialet som
ligger i AMS teknologien. Nye krav til markedsdesign som følge av felles nordisk
sluttbrukermarked vil også medføre endringer for kraftbransjen. Som følge av dette har
flere tatt til orde for en felles IKT-løsning i kraftmarkedet.
NVE mener at utviklingen av felles IKT løsninger vil kunne gi bedre tjenestekvalitet og
lavere kostnader enn ved implementering av nye løsninger i hvert enkelt selskap. NVE
har derfor pålagt Statnett, gjennom endring av avregningskonsesjonen 30. januar 2012,
å "utrede samt å ha et overordnet ansvar for utviklingen av felles IKT-løsninger for
kraftmarkedet."
Mandatet fra NVE til Statnett SF i utredningen inkluderer:
Utredningen skal gi en anbefaling av hvilken funksjonalitet som skal tilbys i
felles IKT-løsninger
Hvilke oppgaver som skal utføres
Forslag til organisering
Det ble videre beskrevet at bransjens deltakelse i arbeidet er viktig for å sikre bransjens
innflytelse. Det ble spesifisert at Statnett SF skulle forelegge utredningen til NVE, og at
NVE skal godkjenne planen før utviklingen starter.
NVE ønsket at utredningen skulle vurdere om følgende oppgaver i kraftmarkedet bør
håndteres av felles IKT-løsninger:
Distribusjon av måleverdier mellom bransjeaktører, sluttbrukere og tredjeparter
Distribusjon av informasjon fra tjenesteleverandører via felles portal
Kvalitetssikring av data
Felles løsninger for utvalgte forretningsprosesser som leverandørskifte, oppstart
og anleggsovertakelse etc.
Formidling av avregningsunderlag og fakturagrunnlag
9

Støttefunksjoner for balanseavregningen
Sikkerhet (tilgang til informasjon, styring av forbruk etc.)
Utredningen skal oversendes til NVE innen 1. juni 2012, og godkjennes av NVE før en
felles IKT-løsning utvikles.
1.2 Organisering og gjennomføring av utredningsprosjektet
Statnett SF har ledet arbeidet med utredningen, og er ansvarlig for sluttrapporten som
oversendes NVE for godkjennelse. Statnett SF etablerte en prosjektgruppe som har
utarbeidet utredningen. Gruppen ble ledet av Tor B. Heiberg fra Statnett SF.
For å sikre god involvering fra bransjen har prosjektet blitt organisert med et bransjeråd
og en ekspertgruppe med deltakere fra nettselskaper og kraftleverandører. Deltakere fra
bransjen har blitt nominert av Energi Norge, Defo og KS Bedrift.
Bransjeråd
Bransjerådets oppgave har vært å gi råd til utredningsprosjektet om viktige forhold som
påvirker selskapene og sikre at utredningen har dekket de vesentligste forhold av
betydning for aktørene i bransjen. Bransjerådet har også hatt en viktig rolle i å sikre
involvering og forankring av det arbeidet som blir utført i bransjen.
I bransjerådet har det vært deltakere både fra nettselskaper og kraftleverandører, NVE
har deltatt som observatør.
Bransjerådet har hatt tre møter i løpet av utredningen. Videre har Bransjerådet hatt som
oppgave å gi innspill på utkastet til rapport slik det forelå 15. mai.
Ekspertgruppe
Ekspertgruppens rolle har vært å gi innspill til Statnetts prosjektgruppe på faglige
spørsmål, samt bidra med informasjon og beskrivelser av dagens modell, krav til
fremtidige modell og bistå i spesifikke forhold som berører nettselskaper og kraftleverandører.
Ekspertgruppen har vært betydelige bidragsytere i rapporten og anbefalingene som gis.
Ekspertgruppen har vært samlet syv ganger i prosjektperioden. I tillegg har
Ekspertgruppen arbeidet mellom møtene og forberedt innspill til utredningen samt
skaffet til veie relevant informasjon.
Styringsgruppe
Styringsgruppen i prosjektet har bestått av Bente Hagem (konserndirektør i Statnett SF),
Per Olav Østli (konserndirektør i Statnett SF) og Thor Erik Grammeltvedt (Seksjonssjef
NVE)
Figuren under viser prosjektets organisering:
10

Bransjeråd
Jens Auset (Hafslund)
Svein A. Folgerød (Agder)
Petter Sandøy (BKK)
Ketil Lille (Skagerak)
John H. Jakobsen (Haugaland)
Gerhard Eidså (Istad)
Eivind Dybendal (Midt-Nett Busk.)
Guttorm Listaul (Notodden)
Sverre Gjessing (Fjordkraft)
Hans Petter Andersen (LOS)
Arild I. Markussen (Helgelandskraft)
Jan Jansrud (Gudbrandsdalen)
Karl M. Ellinggard (NVE)
Prosjekt (Statnett)
Tor B. Heiberg (prosjektleder)
Gorm Lunde
Christer Jensen
Leif Morland
Ove Nesvik
Morten Småstuen
Styringsgruppe
Bente Hagem (Statnett)
Peer Olav Østli (Statnett)
Thor Erik Grammeltvedt (NVE)
Ekspertgruppe
Thore Sveen (Hafslund)
Finn A. Gravdehaug (Istad)
Trond Thorsen (Skagerak)
Arnstein Flaskerud (Fjordkraft)
Haldis Skagemo Gjøsund (Lyse)
Bjørn Skaret (Ustekveikja)
Figur 1 - Prosjektets organisering
I tillegg til møtene med Bransjerådet og Ekspertgruppen har prosjektet hatt god dialog
med Energi Norge på utvalgte deler av utredningen for å sikre informasjonsoverføring
mellom denne utredningen og arbeidet som Energi Norge har satt i gang i forbindelse
med AMS innføringen.
Det er også gjennomført møte med Justervesenet som ønsker å vurdere muligheten for å
opprette et sentralt målerregister for strømmålere.
18.april arrangerte prosjektet et seminar hvor temaet var å presentere internasjonale
erfaringer. Foredragsholdere fra Norge, Finland, Danmark, Nederland og USA
presenterte alternative modeller fra ulike kommunikasjons- og datahuber i utlandet.
For å holde bransjeorganisasjonene orientert om fremdriften i prosjektet er alle
møtereferater blitt distribuert til Energi Norge, KS Bedrift og Defo underveis i
prosjektet.
1.3 Disposisjon for utredningen
I kapittel 2 gis et sammendrag av rapporten og dens anbefalinger. I kapittel 3 beskrives
utfordringer med dagens markedsmodell og nye krav til markedsmodell drevet frem av
innføring av AMS og nordisk sluttbrukermarked og hvordan dette setter krav til
effektive teknologiske løsninger for å støtte endringene som kommer. Kapittel 4 gir en
beskrivelse av målbilde som rapporten arbeider etter, og en utfyllende beskrivelse av to
konseptuelle mulige løsningsalternativer som er brukt til å evaluere ønsket og anbefalt
modell for felles IKT-løsninger.
I kapittel 5 analyseres de to konseptuelle modellene (kommunikasjonshub og datahub),
og hvordan de bidrar til å støtte den nye markedsmodellen. I dette kapitelet beskrives
også ansvar, roller og prosesser for de relevante prosesser i markedet.
Internasjonal utvikling og fremtidens krav er vurdert opp i mot de aktuelle modellene i
kapitel 6.
Kundenytte blir omtalt i kapittel 7 av rapporten, og det vurderes her hvilken modell som
bidrar mest til økt kundenytte og enkelhet for sluttbrukeren.
11

I kapittel 8 er det beregnet kostnader og besparelser for hhv en kommunikasjonshubmodell
og en datahub-modell.
Kapitel 9 omhandler nødvendig teknisk ytelse for en datahub-modell (sentralt system)
som skal støtte markedet i integrasjonen mellom nettselskaper, avregningsansvarlig,
kraftleverandører, sluttbrukere og tredjeparts aktører. Her blir også sårbarhet og
sikkerhet vurdert.
Beskrivelse av implementering og organisering av det videre arbeidet er beskrevet i
kapitel 10 og 11.
Oppsummeringer og anbefalinger er gitt i kapittel 12. Til slutt i rapporten i kapitel 13 er
det også oppsummert hvilke konsekvenser anbefalt løsning vil ha for nettselskaper,
kraftleverandører og mulige regulatoriske konsekvenser.
12

2 Sammendrag
Utredningens hovedoppgave har vært å definere felles IKT løsninger for det fremtidige
kraftmarkedet. Dette er i utgangspunktet en vid oppgave da felles IKT løsninger kan
spenne fra dagens Ediel standard til en fullskala IKT løsning som utfører mange av
nettselskapenes oppgaver i et felles system. Derfor har det vært nødvendig å
konkretisere oppgaven i forhold til et definert målbilde og metodikk.
Målbildet
Det overordnede målet med felles IKT løsninger er størst mulig nytte for samfunnet
gjennom størst mulig kundenytte til lavest mulig samfunnsøkonomisk kostnad. Mer
konkret skal felles IKT løsninger sikre effektiv utnyttelse av AMS i forhold til
kvalitetssikring og distribusjon av måleverdier samt tilleggstjenester muliggjort
gjennom AMS. AMS og felles IKT løsninger gir også mulighet for forbedring av øvrige
forretningsprosesser samt større grad av nøytralitet i kraftmarkedet. Videre skal felles
IKT løsninger legge til rette for mer leverandørsentriske, og felles nordiske
markedsmodeller uten at slike modeller nødvendigvis blir implementert.
Metodikk
Ved å konkretisere målbildet, og evaluere dette opp mot utførelsen av ulike
forretningsprosesser, har vi vurdert egenskaper ved ulike IKT-modeller. Som
løsningsalternativ har vi satt opp to prinsipielle alternativer:
1. Felles IKT løsning i form av en kommunikasjonshub. Dette er en løsning som
ligger tett opp til dagens løsning i kraftmarkedet bortsett fra at det innføres en felles
sentral som formidler all datautveksling mellom nettselskaper og kraftleverandører.
Det essensielle med denne modellen er at den ikke representerer lagring av data, så
som kunder, måleverdier osv. Men det vil være en sentral operativ enhet som sørger
for at all datautveksling når frem til mottaker og oppretting dersom feil oppstår.
2. Felles IKT løsning i form av en datahub. Denne løsningen skiller seg vesentlig fra
dagens modell da det innføres en ny rolle som lagrer data, utfører
forretningsprosesser og er ansvarlig for at dataene er tilgjengelige for
markedsaktørene.
Vi har ikke vurdert dagens modell i sin rene form av to grunner. For det første mener vi
at den ikke vil kunne oppfylle fremtidige krav til datakvalitet, nøytralitet og utnyttelse
av potensialet som ligger i AMS teknologien. For det andre er en kommunikasjonshub
så tett opp til dagens løsning at dagens modell kan sies å være representert gjennom
denne.
Vi har modellert de ulike forretningsprosessene i de to løsningsalternativene og evaluert
dem i forhold til 4 kriterier:
1. Støtte til ny markedsmodell i forhold til kundenytte og effektive prosesser
2. Kostnader/besparelser i forhold til dagens modell
3. Teknisk robust løsning i forhold til ytelse og sikkerhet
4. Implementasjon i forhold til tid og konsekvenser for utrulling av AMS
13

Evaluering
Evalueringen viser at datahub kommer klart bedre ut enn kommunikasjonshub. I det
følgende går vi gjennom hovedgrunnene til dette.
A. God kvalitet og effektiv distribusjon av måleverdier
Datahub er evaluert som klart bedre enn kommunikasjonshub på grunn av:
o Bedre kvalitet
o Enklere feilhåndtering
o Enklere funksjonalitet hos nettselskapene
o Enklere teknisk løsning
o Nøytralitet ved at alle kraftleverandører har lik tilgang til måledata
o Lavere krav til tilgjengelighet hos nettselskaper
B. Tilrettelegge for prisinformasjon og andre tilleggstjenester muliggjort ved AMS
Det er helt avgjørende med felles IKT løsninger for å ta ut potensialet for nettnytte
og innovasjon av 3.parts produkter og tjenester. Datahub er evaluert som klart bedre
enn kommunikasjonshub på grunn av:
o Flere muligheter til å bruke åpne standarder og internett og derigjennom
større fleksibilitet i forhold til fremtidig utvikling
o Felles autorisasjon av 3.parter og felles standard for tilkobling av 3.parts
komponenter og tjenester.
o Datahub vil kunne begrense AMS funksjonene over lokal måler til 3.part.
Dermed slipper 3.parter å gå gjennom det enkelte nettselskap og det enkelte
nettselskap slipper å tilrettelegge spesielt for 3.parter
Det anbefales en standardisering av det åpne lokale grensesnittet til måleren. Dette
er helt avgjørende for å ta ut nyttepotensialet ved AMS. Videre anbefales det å la
nettselskapene få kontroll over nettnytte gjennom egen "kanal" på måler, f.eks. til
nettselskapets laststyring på det enkelte målepunkt.
C. Tilrettelegge for totalfakturering utført av kraftleverandørene
Utredningen har ikke tatt stilling til om det skal være samfakturering eller ikke. Vi
har imidlertid evaluert hvordan en slik modell vil kunne fungere i henholdsvis en
kommunikasjonshub og en datahub. Analysene viser at datahub er bedre enn
kommunikasjonshub. Mye på grunn av samme argumentasjon som ved A. ovenfor.
Uansett vil en datahub ikke være til hindring for å kunne fortsette med dagens
faktureringsregime.
D. Støtte for dagens forretningsprosesser
AMS gir muligheter for forenkling av dagens forretningsprosesser. Disse
mulighetene vil best bli utnyttet dersom en datahub etableres. Da kan
leverandørskifter, flytting og lignende prosesser løses mellom kraftleverandør og
datahub uten at nettselskapet er involvert. En datahub vil også sikre større grad av
nøytralitet og homogenitet i disse prosessene.
E. Fleksibilitet i forhold til fremtidige endringer
14

Markedsmodellen vil måtte være endringsdyktig i forhold til fremtidige endringer.
Det kan være endringer knyttet til felles nordisk sluttbrukermarked, europeisk
harmonisering og utvikling av AMS tjenester. En datahub vil være mer
endringsdyktig fordi en med stor sannsynlighet bare trenger gjøre endringer i huben
slik at nettselskapene slipper å gjøre endringer. Videre vil en datahub i større grad
sikre markedsdrevet utvikling ved at endringer bare må godkjennes av huben og
ikke av 130 nettselskaper.
F. Sikker og robust løsning
Vi har analysert ytelse og sikkerhet ved både kommunikasjonshub og datahub.
Begge løsningene vil kunne tilby tilstrekkelig ytelse og sikkerhet, men en datahub
kommer noe bedre ut.
G. En løsning som gir klare retningslinjer for innføring av AMS
Begge modellene vil for så vidt gi klare retningslinjer for innføring av AMS, men
med en kommunikasjonshub vil det være større usikkerhet for nettselskapene i
forhold til hvordan de skal tilrettelegge for distribusjon av prisinformasjon og
tilleggstjenester.
H. En løsning som er kundevennlig
En datahub er vurdert som mer kundevennlig enn en kommunikasjonshub. Dette
skyldes bedre tilgang til kunde- og måledata, økt konkurranse gjennom mer
nøytralitet og lavere terskler for kraftleverandører samt bedre tilgang til AMS
tilleggstjenester. En datahub vil også i større grad kunne sikre personvern og
datasikkerhet.
I. Effektiv organisasjon for utvikling og drift av felles IKT løsninger
Både en datahub og en kommunikasjonshub vil gi muligheter for effektiv
organisasjon. Men ved en kommunikasjonshub vil effektiviteten i større grad være
avhengig av at 130 nettselskaper klarer å samordne utviklingen.
J. Kostnadseffektiv løsning
Basert på innsamlet kostnadsstatistikk fra nettselskaper og kraftleverandører samt
evaluering av fremtidige kostnader ved de ulike forretningsprosessene har vi
kommet frem til at en datahub vil medføre kostnadsreduksjon for bransjen på 200 til
400 millioner kroner per år inklusiv kostnaden ved å etablere og drive en datahub.
Tilsvarende tall for en kommunikasjonshub viser et intervall fra 80 millioner kroner
i økte kostnader per år til en kostnadsreduksjon på 100 millioner kroner per år.
Evalueringen viser altså at en datahub kommer best ut. Det er derfor prosjektets
anbefaling at det etableres en datahub som skal fungere som markedets kontaktpunkt
mot nettselskapene i forhold til måleverdier, leverandørskifter, innflytting, utflytting,
oppsigelse samt autorisasjon og informasjonsutveksling i forbindelse med AMS
tilleggstjenester. Dersom mer leverandørsentriske faktureringsmodeller vedtas vil
sannsynligvis datahuben kunne spille en sentral rolle i forhold til effektivitet og
nøytralitet.
Implementering
AMS vil bli implementert gradvis frem til 2017 og det vil derfor være behov for
overgangsløsninger for å kunne dekke forskriftskravene i perioden fra 2014 til 2017.
Prosjektet anbefaler en gradvis overgang til datahub, der man innfører funksjon for
15

funksjon i perioden 2104-2017. Hver funksjon vil gjelde for hele markedet, også for de
kunder som enda ikke har fått AMS installert. På denne måten vil en unngå at alle
nettselskapene må håndtere parallelle markedsregimer i en overgangsperiode.
Organisering og drift av datahub er ikke avklart. For det første må regulatoriske forhold
avklares, for det andre må finansieringsmodell avklares og for det tredje må eierskap og
styringsmodell avklares. Dette er forhold som må avklares av NVE i samarbeid med
Statnett og bransjen.
Innføringen av datahub er foreslått i tre faser:
1. Forberedelse 2012; I denne fasen skal det avklares hvordan implementasjons- og
driftsfasen skal finansieres, organiseres og styres. Videre skal det i denne fasen
utarbeides kravspesifikasjon til datahubens IKT system. Oppgaven ligger per i dag
innenfor ansvaret til Avregningsansvarlig og Avregningsansvarlig vil ta ansvaret
men med bistand fra bransjen og i samarbeid med NVE
2. Implementasjon 2013-2016; Gradvis innføring av utvalgte prosesser
3. Drift 2017; Alle relevante prosesser etablert i nytt markedsregime og Datahuben
er operativ
Det er ikke mulig å spesifisere når en datahub kan være operativ før et prosjekt er
etablert og leveranser er avtalt. Vi mener imidlertid at det bør kunne være realistisk å
etablere en datahub med begrenset funksjonalitet som oppfyller forskriftskravene før
2015.
Regulatoriske endringer
Anbefalingen om etablering av en datahub vil føre til endringer av roller og ansvar i
bransjen. Dette betyr at en del grunnleggende rammebetingelser må endres i
reguleringen. Det er viktig å avklare regulatoriske forhold til riktig tid for at
implementering og endringer kan bli foretatt i tide. Dette gjelder blant annet:
Regulering av datahub
Regulering av ny markedsmodell og datahubens rolle
Faktureringsregime
Leveringsplikt
Øvrige forretningsprosesser
Bransjens oppfatning
Det er i det store og hele en samlet bransje som stiller seg bak anbefalingene i denne
rapporten. En ekspertgruppe bestående av personer fra kraftleverandører og nettselskap
har deltatt aktivt i utarbeidelsen av rapporten, og støtter anbefalingen om at en datahub
er den foretrukne modellen.
Et Bransjeråd har vært informert og gitt innspill underveis i prosessen. Medlemmene i
bransjerådet støtter også hovedtrekkene av rapportens konklusjoner.
Vedlagt denne rapporten er det summert kommentarer og innspill fra medlemmer av
bransjerådet og ekspertgruppen som avviker eller presiserer forhold i rapporten. Alle
innspillene også gjengitt i sin helhet.
16

3 Sluttbrukermarkedet for kraft og felles IKT løsninger
Sluttbrukermarkedet er i dag todelt i den forstand at sluttbrukeren må forholde seg til
kraftleverandøren for selve kraftleveransen, mens han må forholde seg til det lokale
nettselskapet når det gjelder nettjenesten. For at en kraftleverandør skal kunne utføre
sine tjenester er han avhengig av kontinuerlig informasjonsutveksling med
sluttbrukernes nettselskaper. Dette gjelder prosesser for bytte av kraftleverandør,
flytting, måledata, generelle kundedata m.m. Nettselskapene er gjennom forskrift
forpliktet til å utføre disse tjenestene ovenfor kraftleverandørene, men nettselskapene
har ingen egennytte av dette. Det norske markedet er således basert på et mange-tilmange
forhold mellom kraftleverandører og nettselskaper illustrert i følgende figur:
Sluttkunde
A
B1
Leverandør Informasjonsutveksling Nettselskap Målepunkt
Sluttkunde
A
J NorgesEnergi
B2 B
BKK
E Måleverdier
B3 C
K
Anleggsinformasjon
Kundeinformasjon
F
N1 F
Fjord Kraft
NTE
I N2 G
Leverandørbytter
Flytting
B4 D
D Hardanger H1 E
C
H1 A
K H2 I
L
Hafslund H3 J
Telinet
Fellesfakturering
B H4 K
G Ustekveikja H5 L
flere..
↓
flere..
↓
------------ Basert på Statnett Ediel standard ------------
aktørene må ha datasystemer som “snakker samme språk”
flere..
↓
flere..
↓
flere..
↓
Figur 2 - Sluttbrukermarkedet for kraft pr i dag
3.1 Utfordringer med dagens modell
Dagens modell betinger stor grad av duplisering av funksjoner: For den samme
sluttbrukeren må både nettselskap og kraftleverandør lagre og prosessere de samme
kundedata og måledata. I tillegg må begge fakturere og drive support ovenfor den
samme sluttbrukeren.
Prinsipielt skal nettselskapenes tjenester ovenfor kraftleverandørene utøves identisk,
dvs. at alle prosessene skal utføres likt uavhengig av hvilket nettselskap eller
kraftleverandør som er involvert. Dette er imidlertid vanskelig å oppnå i praksis fordi
prosessene er detaljerte og det er stadig behov for endring. Det viser seg at ulik praksis
oppstår og at kraftleverandørene må tilpasse seg hvert enkelt nettselskap.
Markedet er i stor grad preget av vertikalt integrerte selskaper hvor både kraftleverandør
og nettselskap ligger i det samme konsernet og hvor disse to deler data i de samme IKT
systemer. Det betyr at vertikalintegrerte kraftleverandører har en markedsfordel i eget
"hjemmemarked". Mellom 60 % og 70 % av alle sluttbrukere er kunder av sin
vertikalintegrerte "hjemlige" kraftleverandør.
17

Dagens modell blir videre utfordret av nye krav til markedsfunksjoner. For det første
gjennom innføring av AMS hvor datamengde og utvesklingsintensitet vil øke og hvor
nye "smarte" produkter og tjenester vil medføre nye aktører og funksjoner i markedet.
For det andre er det et uttrykt ønske fra regulatorisk hold på norsk og nordisk nivå at
markedet skal gå over til fellesfakturering av kraft- og nettjenester, noe som vil medføre
store endringer i dagens modell.
3.2 Alternative markedsmodeller
Ut i fra et effektivitetshensyn kan andre markedsmodeller være å foretrekke, modeller
hvor en ikke dupliserer funksjoner, hvor data i større grad er homogene og hvor en i
større grad sikrer likebehandling av markedsaktørene. Videre kan det være mer effektivt
at noen nye prosesser utføres kun ett sted fremfor i hvert enkelt nettselskap.
Som alternativer til dagens markedsmodell har vi på den ene siden en mer
leverandørsentrisk modell hvor kraftleverandøren har all kontakt med sluttbrukeren
bortsett fra fysisk installasjon og relasjoner knyttet til lokal nettdrift.
På den andre siden kan man tenke seg en modell hvor nettselskapet håndterer alt, dvs.
en "nettsentrisk" modell. I denne modellen vil kraftleverandøren være overflødig og
sluttbrukerne vil være nødt til å få kraften levert fra lokalt nettselskap. For å unngå
monopolpriser på kraft i en slik modell kunne man ha regulert selve kraftprisen til å
være like spotpris med regulert administrasjonspåslag. Det er klart at en slik modell vil
løse mange av dagens utfordringer knyttet til informasjonsutveksling og således kunne
være mer effektiv. Men dette er ikke en realistisk modell fordi den er i motstrid med
grunnleggende prinsipper i norsk og europeisk energilovgivning i den forstand at
forbrukeren skal kunne velge sin kraftleverandør. Videre er det en grunnleggende
oppfatning at monopoler er vesentlige mindre effektive enn konkurranseutsatte
tjenesteleverandører og at det er feil å monopolisere tjenester som kan
konkurranseutsettes. Det ligger heller ikke i mandatet til denne utredningen å evaluere
en slik "nettsentrisk" modell.
Vi mener derfor at en fremtidig markedsmodell vil være en mer eller mindre
leverandørsentrisk modell.
3.3 Felles IKT løsninger
En forutsetning for felles IKT løsninger er at de skal løse oppgaver som nettselskapene
ellers måtte ha løst hver for seg fordi felles IKT løsninger også vil ta form av naturlig
monopol. Felles IKT løsninger skal altså ikke løse oppgaver som kraftleverandører og
markedet kan løse. Statnett er allerede ansvarlig for felles IKT løsninger i dagens
kraftmarked: Balanseavregning, Ediel standarden og NUBIX er ansett som nødvendige
fellesfunksjoner for at markedet skal kunne fungere.
Detaljmarkedet for banktjenester er i stor grad basert på felles IKT tjenester gjennom
den såkalte BBS modellen (nå Nets). Bankene samarbeider og har en felles IKT
infrastruktur for informasjonsutveksling mellom banker og mellom banker og
sluttbrukere. Men dette forhindrer ikke bankene i å konkurrere på produkter og
tjenester, snarere tvert om i den forstand at BBS har bidratt til å opprette et mangfold av
konkurransedyktige banker som ellers ikke hadde vært i stand til å følge med i den
teknologiske utviklingen. Det kan dras en parallell fra bankmarkedet til kraftmarkedet
på dette området.
En fremtidig markedsmodell vil sannsynligvis ligge nærmere en ren leverandørsentrisk
modell enn dagens todelte modell og vil med AMS uansett forutsette større krav til
18

informasjonsutveksling mellom nettselskaper og kraftleverandører. Sammen med øvrig
argumentasjonen i dette kapitlet gir dette grunnlag for å evaluere om markedet i større
grad skal bygges opp rundt felles IKT løsninger enn det vi har i dag.
19

4 Målbilde og metodikk
Kapittelet beskriver det målbilde som prosjektgruppen har arbeidet etter i utarbeidelsen
av utredningen. Videre introduseres de to konseptuelle løsningsalternativene for et nytt
felles IKT system i kraftbransjen i Norge; en kommunikasjonshub og en datahub. Disse
brukes i evalueringen og anbefalingen av en felles IKT-løsning for kraftmarkedet. Sist i
kapittelet presenteres vurderingskriterier og metodikk som prosjektgruppen har fulgt i
utarbeidelsen av utredningen.
4.1 Konkretisering av utredningens målbilde
Utviklingen av en felles IKT løsning skal legge til rette for et samfunnsøkonomisk
effektivt kraftmarked. I den forbindelse har prosjektgruppen etablert et overordnet
målbilde bestående av 10 mål som søkes best mulig oppnådd i en felles IKT løsning.
Disse avdekkes for hver av løsningsalternativene i utredningen.
Målbildet består av nedenstående 10 mål:
M1
M2
En løsning som sikrer effektiv håndtering av måledata og
informasjonsutveksling mellom nettselskaper, kraftleverandører og
sluttbruker i kraftmarkedet
Tilleggstjenester og prisinformasjon
M3
M4
M5
M6
M7
M8
M9
M10
Tilrettelegge for totalfakturering (utført av kraftleverandørene)
En løsning som er nøytral og som effektivt støtter dagens og morgendagens
behov i markedet (forretnings- og sluttbrukerprosesser)
En løsning som sikrer god integrasjon mot et felles nordisk
sluttbrukermarked med like prosesser på tvers av landene
En løsning som har høy grad av sikkerhet, og som er robust nok til å
håndtere store datamengder
En løsning som er oversiktlig, og som gir klare retningslinjer, prosedyrer og
krav til innføring av AMS med tilhørende prosesser i kraftmarkedet
En løsning som er sluttbrukervennlig
En effektiv organisasjon for utvikling og drift av felles IKT løsninger
En løsning som er kostnadseffektiv over tid, og som gir den beste løsningen
for samfunnet
Tabell 1 - Prosjektets målbilde
Målbildet tar samtidig høyde for føringer fra NVE og er derved tett knyttet til NVEs
målbilde. Dermed vil anbefalt modell legge til rette for oppfyllelse av de krav som NVE
har satt til markedsmodell.
Videre tar målbildet hensyn til føringer gitt av arbeidet i NordREG, hvor det er fremsatt
anbefalinger knyttet til etablering av et felles nordisk sluttbrukermarked for kraft i
Norden. Anbefalinger og konklusjoner fra NordREGs arbeid gir behov for tilpasninger
for felles IKT-løsning i Norge og derfor er prosjektets overordnede målbilde tett knyttet
til NordREGs mål.
NordREG beskriver målene sine som følger:
20

Kundevennlighet
Velfungerende
fellesmarked
Konkurranse
Effektivitet
EU regulering
og utvikling
Nøytralitet
Kundevennlighet: Målet er å øke kundevennligheten i kraftmarkedet og gjøre det
enklere for sluttbruker å være aktiv i markedet (for eksempel i forhold til
leverandørskifte)
Velfungerende fellesmarked: Målet er å ha et velfungerende fellesmarked for
kraftleverandør og sluttbruker. Dette forutsetter i en vis grad harmonisering av
forretningsprosesser
Konkurranse: Målet er å øke konkurransen blant kraftleverandører, hvor
tilgangen til data er avgjørende i forhold til å gjennomføre forretningsprosesser
relatert til nye sluttbrukere (inn- og utgangsbarrierene skal minskes)
Effektivitet: Målet er en generell økt effektivitet på kraftmarkedet til nytte for
sluttbrukeren - dette i form av reduserte kostnader ved innhentning, håndtering
og lagring av data samt færre grensesnitt / databaser
EU regulering og utvikling: Målet er at en løsningsmodell skal være i
overenstemmelse med den generelle utvikling i EU samt eksisterende og
kommende reguleringer fra EU
Nøytralitet: Målet er at en løsningsmodell skal sikre nøytralitet i forholdet
mellom nettselskaper og kraftleverandører og dermed medvirke til å begrense
diskrimineringen av kraftleverandører når de sender forespørsler til nettselskaper
Figuren nedenfor viser hvordan de enkelte mål i prosjektet er knyttet til NordREGs mål:
NordREG mål
Målbilde
M1. Effektiv håndtering av måledata og informasjonsutveksling
M2. Tilleggstjenester og prisinformasjon
M3. Tilrettelegge for totalfakturering (utført av kraftleverandørene)
M4. Nøytral og effektiv løsning (prosesser)
M5. Tilpasset et felles nordisk sluttbrukermarked og fremtidig utvikling i EU
M6. Sikker og robust løsning for håndtering av store datamengder
M7. Klare retningslinjer, prosedyrer og krav ift AMS
M8. Sluttbrukervennlig løsning
M9. Effektiv organisasjon for utvikling/drift av felles IKT løsninger
M10. Kostnadseffektiv
Figur 3 - Målbilde knyttet til mål fra NordREG
Kommentarer
• Hensiktsmessig informasjonsutveksling
mellom sluttbruker, leverandør og nettselskap
• Legge til rette for konkurranse om
tilleggstjenester og økt sluttbrukeraktivitet
• Legge til rette for totalfakturering til nytte for
sluttbrukeren
• Felles forretnings- og sluttbrukerprosesser samt
sikring av nøytralitet
• Sikre indirekte overensstemmelse med EU
reguleringer
• Felles utgangspunkt i forhold til tilgang og
konfidensialitet samt lagring av data
• Grensesnittet mellom nettselskapets løsning og
felles løsninger
• Legge til rette for økt sluttbrukeraktivitet og
effektive løsninger
• Sikre effektive beslutningsprosesser i henhold
til felles IKT løsninger
• Investerings- og driftskostnader for bransjen
samt nytte for samfunnet
4.2 Konseptuelle modeller
Utredningen av effektivt sluttbrukermarked for kraft og identifiseringen av en felles
IKT-løsning for kraftmarkedet tar utgangspunkt i to alternative modeller, som prosjektet
har jobbet etter:
En kommunikasjonshub-modell der nettselskapene er ansvarlig for alle måle- og
anleggsdata, og kraftleverandørene er ansvarlig for sluttbruker- og fakturadata
Aktøren som er ansvarlig for data lagrer disse, med en løsning for
tilgjengeliggjøring av data ved bruk av en felles kommunikasjonshub
En datahub-modell med sentralt lager av anleggsdata, måledata, priser,
fakturainformasjon og sentraliserte prosesser. I denne modellen er datahuben
21

autorativ kilde til data, mens nettselskap og kraftleverandør er ansvarlig for å
holde datahuben oppdatert til enhver tid med gjeldende data
Figuren under illustrerer kommunikasjonshuben:
Avregningsansvarlig
Informasjonsutveksling
Informasjonsutveksling
Database
Database
Kraftleverandører
Kommunikasjonshub
• Måleverdier
• Anleggsinformasjon
• Grunnlagsdata
• Leverandørskifte
• Flytting
• Avregningsunderlag for netttariff
Nettselskaper
Kommunikasjonsstandard
1
Kommunikasjonsstandard
2
Supportfunksjon
• Verifisering av sending og
mottatt av meldinger
• Mulighet for monitorering
av forretningsprosesser
mellom kraftleverandør og
nettselskap
• Støtte til problemløsning
Sluttbruker
Målepunkt
Figur 4 - Konseptuell skisse for kommunikasjonshub-modell
I kommunikasjonshuben vil en fremdeles ha ulike systemer hos kraftleverandører og
nettselskaper, og sistnevnte må ha egne måleverdidatabaser. Alle aktørene har bare en
motpart for alle meldinger og all kommunikasjon skal konsistenssjekkes. Videre kan
modellen håndtere ulike kommunikasjonsstandarder på hver side av
kommunikasjonshuben. Konsekvensen av en kommunikasjonshub er høye krav til
standardisering, systemer og forretningsprosesser hos selskapene, herunder tidsfrister
for rapportering, måleverdier og metadata.
I en datahub vil det, som i kommunikasjonshub, bare være en motpart for all
kommunikasjon, som skal utføre konsistens- og innholdssjekk. Det kan imidlertid
eksistere ulike kommunikasjonsstandarder på «hver sin side» av huben. Prosessene
håndteres av datahuben, og nettselskapene informeres om for eksempel
leverandørskifter og flyttinger. Nettselskapene må ha egen måleverdidatabase, og er
ansvarlig for innsamling og kvalitetssikring av måleverdier. Det skal kun utveksles
volumer mellom nettselskap og kraftleverandør. Nettselskapene vil imidlertid hente
stander fra AMS-måler. Kraftleverandørene orienterer seg kun mot datahuben for å få
nødvendig informasjon, uavhengig av hvilket nettselskap som er ansvarlig for
målepunktet.
Nedenstående figur illustrerer datahuben:
22

Avregningsansvarlig
Informasjonsutveksling
Kommunikasjonsstandard 1
Informasjonsutveksling
Kommunikasjonsstandard 2
Database
Database
Kraftleverandører
• Måleverdier
• Lev.skifte
• Flytting
• Avregningsunderlag
faktura
• Prisinfo
• Grunnlagsdata
Datahub
• Anleggsdata
• Måleverdier
• Tariffinfo
• Grunnlagsdata
Nettselskaper
• Leverandører
• Nettselskaper
• Anleggsdata
• Målerverdidatabase
• Målepunktdatabase
• Grunnlagsdata
Sluttbruker
Involvert i forretningsprosesser
• Leverandørskifte
• Inn- og utflytting
• Rapportering til balanseavregning
• Avviksoppgjør kundeavregning
• Avregningsunderlag nett-tariff (OPSJON)
Målepunkt
Figur 5 - Konseptuell skisse for datahub-modell
4.3 Vurderingskriterier
I utredningen er de to alternative løsninger vurdert opp mot det overordnede målbilde
(beskrevet ovenfor) for å avgjøre hvilken modell som best tilfredsstiller de enkelte mål,
herunder hvordan sentrale prosesser håndteres i henholdsvis en kommunikasjonshub og
en datahub. I den forbindelse er det definert noen evalueringskriterier, som blir brukt for
vurdering av målene M1-M10. Kriteriene benyttes for begge modellene. Samtidig
vurderes hvilken betydning de to løsningsmodeller har for henholdsvis nettselskap og
kraftleverandør.
Evalueringskriteriene er splittet i fire overordnede kategorier: (i) Økte
kostnader/besparelser, (ii) Støtter ny markedsmodell, (iii) Teknisk robust løsning og (iv)
Implementering. I vurderingen av modellenes oppfyllelse av målbildet er det brukt så
vel målbare og operative kriterier, når disse har foreligget (for eksempel kostnadstall),
samt mer kvalitative vurderinger. Denne kombinasjon er funnet mest hensiktsmessig i
forhold til å kunne gi den mest rettvisende og nyanserte anbefaling av løsningsmodell.
Evalueringskriteriet Økte kostnader/besparelser går på hvordan den enkelte løsning slår
ut rent kostnads/besparelsesmessig i forhold til dagens modell. Støtter ny
markedsmodell handler om hvilken modell som sikrer mest kundenytte og effektive
prosesser i markedet. Når modellene holdes opp mot det overordnede kriteriet Teknisk
robust løsning vurderes det hvilken modell som gir best ytelse, IT-drift og sikkerhet.
Det siste evalueringskriteriet Implementering dreier seg spesielt om tid og konsekvens
for AMS utrulling.
Figuren nedenfor viser hvorledes kriteriene er knyttet til de enkelte mål samt eksempler
på hva som har ligget til grunn for vurdering av målene:
23

( ) = Delvurdering inngår i
samlet vurdering
Evalueringskriterier
M1
Effektiv
håndtering
av måledata
og
informasjonsutveksling
M2
Tilleggstjenester
og
prisinformasjon
M3
Til rettelegge
for
totalfakturering
(utført av
kraftleverandørene)
M4
Nøytral og
effektiv
løsning
(prosesser)
M5
Tilpasset et
felles
nordisk
sluttbruker
marked og
fremtidig
utvikling i
EU
Målbilde
M6
Sikker og
robust
løsning for
håndtering
av store
datamengder
M7
Klare
retningslinjer,
prosedyrer
og krav ift
AMS
M8
Sluttbrukervennlig
løsning
M9
Effektiv
organisasjon
for
utvikling/
drift av
felles IKT
løsninger
M10
Kostnadseffektiv
Økte kostnader / besparelser () () () () n/a () n/a () ()
Støtter ny markedsmodell n/a n/a
Teknisk robust løsning () n/a n/a () n/a
Implementering n/a n/a
Elementer som er
vurdert (eksempler)
• Vurdering
av
modellenes
betydning
for aktører
og
sluttbrukere
• Tilgjenge
-lighet
• Grad av
enkelthet
for kraftleverandører
og
nettselskap
for å
overføre
priser til
sluttbruker
• Enkelthet
for
sluttbruker
og
tredjepart
aktører
• Distribusjon
av
tjenester i
modellene
• Effektivitet
for
kraftleverandø
rer og
nettselskap
• Prosesser
ift den
enkelte
modell
• Vurdering
av
løsningen
opp
imot
føringer
gitt av
NordREG
og EU
• Ytelse og
sikkerhet
• Kvalitativ
vurdering
av
løsningens
føringer
for
anskaffelse
av
AMS
• Krav fra
forskrifter
og regelverk
• Tilgang
til info
• Tilgang
til
tilleggstjenester
• Kvalitet i
prosesser
• Konkurranse
i
sluttbrukermarked
• Fakturering
• Datasikkerhet
• Vurdering
av
modellene
ift
implementering
av nye
krav
• Etablering
av
modell
• Overgangsløsninger
• Modellenes
betydning
for
dagens
prosesser
(økte
kostnader
/ besparelser)
• Investerings-
og
driftskostnader
Figur 6 - Evalueringskriterier for vurdering av målene M1-M10
Gjennomgangen og vurderingen av i hvilken grad de to alternative løsningsmodeller
oppfyller målbildet i forhold til evalueringskriteriene samt hvilken betydning modellene
har for henholdsvis nettselskap og kraftleverandør er beskrevet i dokumentet. Det er
imidlertid valgt en struktur for utredningen som mer naturlig og flytende kommer inn på
de enkelte mål i målbildet og disse beskrives således ikke enkeltvis og i ovennevnte
rekkefølge.
For å sikre god involvering fra bransjen ble det fra prosjektets oppstart definert et
Bransjeråd og en Ekspertgruppe med et representativt utvalg av deltakere fra
nettselskaper og kraftleverandører. Bransjerådet besto av 12 representanter fra
henholdsvis små og store nettselskaper samt kraftleverandører. Ekspertgruppen hadde
deltakelse av 6 fageksperter også fra nettselskaper og kraftleverandører. Disse to
møtearenaer har vært gjenstand for løpende diskusjon av prosjektets deler og bidratt til
at utredningen bygger på ulike perspektiver fra sentrale aktører i bransjen.
Videre er det innsamlet data fra relevante rapporter fra blant annet NordREG, NBS,
VaasaETT med flere. Det er også gjennomført en spørreskjemaundersøkelse om
tidsbruk/kostnader for interne prosesser blant nettselskaper og kraftleverandører
representert i Bransjerådet og Ekspertgruppen.
Alle vurderinger og endelig anbefaling av løsningsalternativ er imidlertid
prosjektgruppens ansvar.
24

5 Hvordan løse kravene til markedsdesign
Det er umulig å beskrive krav til felles IKT løsninger uten å ta stilling til
markedsdesign, dvs. hvordan de ulike forretningsfunksjonene skal løses med hensyn på
roller, informasjonsutveksling og prosesser. I denne utredningen står vi ovenfor to typer
forretningsprosesser. For det første nye forretningsprosesser som følge av innføring av
AMS, så som daglig kvalitetssikring og distribusjon av timeverdier samt støtte for AMS
tilleggstjenester. For det andre eksisterende forretningsprosesser som vil bli påvirket av
AMS eller som kan forbedres med felles IKT løsninger.
Vi vil i dette kapitlet ta for oss de overordnede forretningsprosessene og analysere
hvordan de kan løses samt fordeler og ulemper med de ulike modellene.
5.1 Grunnleggende krav til markedsdesign
AMS kan for så vidt implementeres uten at nåværende markedsdesign endres. Men da
vil man i veldig liten grad få nytte av AMS. Derfor vil vi uavhengig av nye eller
eksisterende forretningsprosesser legge følgende til grunn ved valg av modeller:
Kravene til kvalitet på måleverdier må økes. Med timevolumer og daglig
rapportering må kvaliteten være høy for at markedet skal kunne fungere
hensiktsmessig. Markedet bruker i dag uhensiktsmessig mye tid på grunn av
dårlig datakvalitet.
Leverandørskifter og flytting må forenkles og effektiviseres. AMS gir
muligheter til forbedring gjennom eksakt målerverdi på bytte- og flyttetidspunkt
samt nærmest kostnadsfri stenging/struping. Videre vil det være
forbedringspotensial gjennom mer konsistent utveksling av grunnlagsdata. En
sluttbruker bør ikke miste sin kraftleverandør dersom han flytter og en ny
sluttbruker må ha valgt kraftleverandør når han flytter inn
Det må legges til rette for AMS tilleggstjenester på en måte som sikrer størst
mulig fleksibilitet i forhold lave terskler for tilbydere og utnyttelse av åpne
standarder og tredjeparts produkter og tjenester
Det må legges til rette for mer leverandørsentrisk markedsmodell hvis det kreves
5.2 Prosesskartlegging og roller
I dette avsnittet beskrives kommunikasjonshuben og datahuben i forhold til de enkelte
prosesser og roller knyttet til hver av modellene. Modellene beskrives blant annet ved
hjelp av datautveksling mellom roller, som er en metodikk hentet fra de europeiske
organisasjonene ebIX ® , EFET og ENTSO-E 1 . Videre beskrives relevante
forretningsprosesser som ikke er detaljert andre steder i rapporten.
For begge alternativer, både kommunikasjons- og datahub, vil det lages ett standard
grensesnitt mot huben. I kommunikasjonshub-modellen vil måledata sendes ("pushes")
fra nettselskapene til kommunikasjonshuben, som ruter måledata videre til
kraftleverandørene. I datahub-modellen vil måledata sendes ("pushes") fra
nettselskapene til datahuben. Videre kan det sendes (”pushes”) eller hentes (”pulles”) til
1 Rollemodell for det europeiske kraftmarkedet fra ebIX ® , EFET og ETSO (ETSO Harmonised Electricity Role
Model), https//www.entsoe.eu/resources/edi-library/
25

og fra kraftleverandør. I begge modeller kan kraftleverandørene på forespørsel hente
måledata via huben.
Noen generelle kommentarer til beskrivelsen av forretningsprosessene:
Datautveksling mellom interne roller i et Nettselskap, hos en Kraftleverandør
eller i en datahub er i hovedsak ikke beskrevet i forretningsprosessene under, da
dette vil bli håndtert direkte i aktørenes datasystemer. Det er i hovedsak kun den
rollen som er ansvarlig for ekstern datautveksling som er beskrevet. Dette
medfører at enkelte av forretningsprosessene har flere roller i en datahub-modell
enn i en kommunikasjonshub-modell. Unntaket er forretningsprosessene
«Innsamling og distribusjon av måleverdier» (se 5.4.1) og «Totalfakturering
utført av kraftleverandørene» (se 5.4.5.1) som er nye prosesser i bransjen og
derfor er beskrevet noe mer detaljert enn de andre forretningsprosessene
Rollen Måleverdiansvarlig er kun ansvarlig for enkeltobservasjoner for det
enkelte Målepunkt. Aggregering av måleverdier, bl.a. for avregningsformål,
forutsettes gjort av rollen Beregningsansvarlig. Oppsplitting i disse to rollene
gjør det mulig å la nettselskapet være ansvarlig for avlesning og kvalitetssikring
av måleverdier, mens en datahub kan ta seg av aggregering og beregning på
måledata
Det er antatt at meldingsutveksling i en ny markedsmodell bør baseres på
prosessmodellene utarbeidet av ebIX ® , som også dagens norske modell er basert
på. Dette medfører imidlertid noen mindre endringer i dagens datautveksling. Et
eksempel er dokumentet (meldingen) «bekreftelse på leveringsstart»
(leverandørskifte) der vi i Norge kombinerer bekreftelsen og tilhørende
grunnlagsdata, mens ebIX ® splitter dette i to dokumenter. I de etterfølgende
prosessbeskrivelsene er ebIX ® tilpassingene foreslått implementert, bl.a. for å
tilpasse modellene til et felles nordisk sluttbrukermarked
Ved ny markedsmodell må det vurderes hvilken type meldingsutveksling,
format og innhold som er mest hensiktsmessig i fremtiden
Ved overgang til en kommunikasjons- eller datahub vil datautveksling foregå
via web-services (WS) og ikke med bruk av SMTP (mail-system) som i dag
Det er forutsatt at en framtidig felles norsk IKT løsning skal være basert på en
«leverandørsentrisk modell». Det betyr at «særnorske prosesser», som
Agdermodellen, ikke er tatt med beskrivelsen av framtidige prosesser. Dette er
en viktig forutsetning i forhold til «M5 Tilpasset et felles nordisk
sluttbrukermarked og fremtidig utvikling i EU»
Det er lagt vekt på at prosesser for effektivisering av nettselskapene skal ikke
være i motstrid med nettselskapenes nøytralitet
Det forutsettes endring av dagens regelverk der nettselskapene har leveringsplikt
NVE må gå gjennom og endre MAF 301 i henhold til ny markedsmodell
Det må defineres klare retningslinjer og ansvarsforhold for prosesser,
avviksbehandling ved inkonsistens og ansvar for oppdatering av data
Felles forutsetninger for en kommunikasjonshub-modell og en datahub-modell:
Alle kraftleverandører skal benytte samme løsning, uavhengig av modell
Alle aktører, inklusive vertikalintegrerte selskap, må utveksle data via
kommunikasjonshub/datahub
26

Siden alle aktører (selskap og sluttbrukere) vil utveksle data via en og samme
hub, vil prosesser og data måtte håndteres likt av alle. Dette vil blant annet gjøre
det enklere å foreta benchmarking mellom aktørene
Nettselskapene er ansvarlige for innsamling og kvalitetssikring av måleverdier.
Dette anses som en konkurranseutsatt virksomhet der nettselskapene kan velge å
gjøre det selv, de kan gå sammen med andre nettselskap eller de kan sette det ut
til en tredjepart. Således vil disse tjenestene kunne utføres kostnadseffektivt til
en markedsbasert pris. I en datahub-modell vil imidlertid datahuben være den
«autorative kilden» til data
Nettselskap må være ansvarlig for at måle- og anleggsdata til en hver tid er
oppdatert
Kraftleverandør må være ansvarlig for at sluttbruker- og faktureringsdata til en
hver tid er oppdatert
Modellen må ikke være begrensende for smart grid, produktutvikling og løsning
for nettselskapet
Modellen skal ikke begrense sluttbrukerens mulighet for å koble seg på med
utstyr direkte på måler for å hente ut verdier
Kraftleverandør står fritt i forhold til valg av CRM, faktureringssystem og KIS
5.2.1 Kommunikasjonshub
I en kommunikasjonshub-modell vil det kun være funksjoner knyttet til datautveksling
som vil være fellesløsninger. Dette omfatter funksjoner som autorisasjon av
kommunikasjonspartnere, felles adresseregister, ruting av meldinger mellom aktørene,
logging av meldinger og support. Supportfunksjonen tenkes å være en utvidelse av
dagens funksjoner, som Systemstøtte for Ediel (SSE), Ediel-portal og NUBIX.
Supportfunksjonen skal være kontaktpunktet som kraftleverandørene og nettselskap kan
kontakte i feilsituasjoner (ved kommunikasjonstekniske feil) og det er
supportfunksjonen som håndterer eventuell kontakt med motparten. Supportfunksjonen
skal også ha en funksjon for å sikre at alle aktører håndterer forretningsprosessene likt,
samt funksjoner som håndterer feil i meldingsinnhold, manglende data etc. Et eksempel
på utvidelse er en logg-funksjon som logger alle meldinger mellom aktørene. I denne
modellen foreslås det også en funksjon for å håndtere feil i innhold, manglende data etc.
på vegne av kraftleverandørene, istedenfor at dette håndteres direkte mellom
kraftleverandør og nettselskap.
En vesensforskjell mellom supportfunksjonen i en kommunikasjonshub-modell og en
datahub-modell er at det ikke finnes noe fullstendig målepunktregister i en rendyrket
kommunikasjonshub. En kommunikasjonshub må imidlertid være i stand til å kunne
rute meldinger, noe som vil medføre behov for et adresseregister, «ruting-register» eller
lignede. I enkleste form for kommunikasjonshub vil det ikke være mulig å rute
meldinger på bakgrunn av målepunkt ID eller kontrollere om data for et målepunkt
mangler i en prosess.
Selv om det er nettselskapene som har ansvar for at det er god kvalitet på data, vil
kraftleverandørene måtte foreta rimelighetskontroll på at data som mottas, samt
kontrollere at det mottas data fro alle målepunkter. Kontrollansvaret forventes å være
mer omfattende i en kommunikasjonshub-modell enn i en datahub-modell der det også
foretas kontroller i datahuben.
27

Forutsetninger for beskrivelser av en kommunikasjonshub:
Kommunikasjonshuben, det vil si en ruting-tjeneste, skal benyttes av alle aktører
i den norske kraftbransjen, også vertikalintegrerte selskaper
Nettselskapet er ansvarlig for informasjon om målepunktet og måledata
Ansvar for data:
o Kraftleverandør er ansvarlig for kundedata. Det vil si all informasjon
som sluttbruker er ansvarlig for, som organisasjonsnummer eller
fødselsdato, strømkunde, fakturaadresse, telefon, epost osv.
o Nettselskapene er ansvarlig for målepunkt-informasjon, som
anleggsadresse, anleggsstatus og måledata. I tillegg er nettselskapene
«autorativ kilde» til data
o Nettselskap må ha all historikk av måledata
Figur 7 - UseCase diagram for kommunikasjonshub
5.2.2 Datahub
Forutsetninger for beskrivelser av en datahub:
Datahuben, skal benyttes av alle aktører i den norske kraftbransjen, også
vertikalintegrerte selskaper
Nettselskapene og kraftleverandørene må til enhver tid ha grunnlagsdata (master
data) de er ansvarlige for oppdatert i datahuben, som vil være den autorativ
kilden
Nettselskapene må til enhver tid ha måledata oppdatert i huben
Det er nettselskapet som er ansvarlig for måledata, mens det i en datahub-modell
vil være datahuben som er den autorative kilden til data
Datahuben må ha all historikk på måledata, inkludert versjonshåndtering
28

Tredjeparts aktører har, etter fullmakt fra sluttbruker, direkte tilgang til datahub.
Det forventes at datahuben kun leverer «rådata» til sluttbrukere og tredjeparter
Det foreslås at sluttbrukere kan få måledata (rådata) direkte fra datahuben.
Dersom sluttbruker ønsker analyser, aggregeringer eller andre beregninger på
data må dette håndteres via kraftleverandør eller tredjepart.
Ansvar for data:
o Kraftleverandørene er ansvarlig for sluttbrukerdata. Det vil si all
informasjon som sluttbruker er ansvarlig for, som organisasjonsnummer
eller fødselsdato, strømkunde, fakturaadresse, telefon, epost osv.
o Nettselskapene er ansvarlig for målepunkt-informasjon, som
anleggsadresse, anleggsstatus og måledata
o Datahuben er den «autorative kilden» til data
Karakteristikker av en datahub-modell:
I en datahub-modell vil datahuben holde oversikt på at det kommer inn måledata
fra alle målepunkter samt ytterligere kvalitetssikre måledata i form av
aggregeringer og sammenligninger, i motsetning til i en kommunikasjonshubmodell
hvor det vil bli lagt et større ansvar på kraftleverandørene for å sikre at
alle data kommer inn
I en datahub-modell vil flytting mellom nettområder foregå i en sentral
målepunktdatabase i datahuben og ikke mellom lokale databaser hos ulike
nettselskap
I en datahub-modell vil datahuben holde oversikt på at det kommer inn måledata
fra alle målepunkter, mens det i en kommunikasjonshub-modell vil bli lagt et
større ansvar for kraftleverandørene (sikre at alle data kommer inn). Det er
nettselskap som har ansvar for å kvalitetssikre måledata.
Figur 8 - UseCase diagram for datahub
29

5.3 Grunnlagsdata
5.3.1 Hvem har ansvaret for hva og hvor det skal lagres
I forbindelse med innføring av AMS og en ny leverandørsentrisk markedsmodell for
den norske kraftbransjen er det viktig å avklare hvilke roller de ulike aktørene har og
hvilket ansvar som tillegges de ulike rollene. Spesielt viktig i denne sammenheng er
ansvar for oppdatering og vedlikehold av data.
I tabellen under vises sentrale dataelementer som må utveksles mellom ulike roller i
marked i forbindelse med prosesser som; leverandørskifte, innflytting/utflytting, samt
oppdatering og utveksling av grunnlagsdata, og som er relevante etter innføring av
AMS. Dataelementer relatert til måleren, som konstant og antall siffer, anses ikke lenger
som nødvendig å utveksle. Imidlertid er det et behov for informasjon om type måler og
kommunikasjonsgrensesnittet som benyttes mot måleren. Denne informasjonen er viktig
for kraftleverandører og tredjeparter som ønsker å tilby løsninger knyttet til AMSmålerne.
I tillegg er det lagt inn en kolonne som viser hvem som er ansvarlig for oppdatering av
de enkelte dataelementer. I en kommunikasjonshub-modell antas det at det er
nettselskapet som har det autorative ansvaret for grunnlagsdata der netteskapet er
ansvarlig og at det er kraftleverandøren har det autorative ansvaret for grunnlagsdata der
denne er ansvarlig. I en datahub-modell vil alle grunnlagsdata lagres i datahuben
(datahuben være den autorative kilden til data), uavhengig av hvem som er ansvarlig for
oppdatering.
Dataelement
Ansvarlig for
oppdatering
Kommentar
Oppstartdato Ny kraftleverandør Kun brukt ved leverandørskifte og innflytting
Målepunkt ID
Nettselskap
Komponentkode Nettselskap Vil muligens erstattes av nettområde ID?
Avregningsmetode
Nettselskap
Forventet årlig uttak Nettselskap Kan tenkes flyttet til datahub
Prioritet
Nettselskap
MVA Kraftleverandør Kraftleverandør bør være ansvarlig i en
leverandørsentrisk modell
Elavgift Kraftleverandør Kraftleverandør bør være ansvarlig i en
leverandørsentrisk modell
Elsertifikatplikt (prosent) Kraftleverandør Kraftleverandør bør være ansvarlig i en
leverandørsentrisk modell
Enova avgift Kraftleverandør Kraftleverandør bør være ansvarlig i en
leverandørsentrisk modell
Næringskode Kraftleverandør Kraftleverandør bør være ansvarlig i en
leverandørsentrisk modell
Sluttbruker
Kraftleverandør
Anleggsadresse
Nettselskap
Fakturaadresse for nettleie Kraftleverandør
Målernummer Nettselskap Relevant for prosessen «Finn målepunkt ID» og
som informasjon på faktura til sluttbruker
Type AMS-måler og
kommunikasjonsgrensesnittet
Nettselskap
Tabell 2 - Grunnlagsdata og ansvar
I dagens modell splittes grunnlagsdata fra nettselskapet i ulike meldinger, avhengig av
type grunnlagsdata som skal overføres, som grunnlagsdata koblet til målepunktet,
30

grunnlagsdata koblet til måler og endring av grunnlagsdata som krever en
måleravlesning. Etter innføring av AMS er det ikke lenger behov for å foreta ekstra
avlesninger, siden alle målepunkter har timeavlesing uansett. Det ses heller ikke som
nødvendig med utveksling av den informasjon som i dag utveksles om måleren, med
unntak av målernummer i prosessen for «Finne målepunkt ID». Videre vil det, i en
leverandørsentrisk modell, være kraftleverandøren som er ansvarlig for oppdatering av
informasjon om sluttbruker og fakturaadresse. Med andre ord faller behovet for å splitte
i undertyper bort etter innføring av AMS.
Den som er ansvarlig for oppdatering av et dataelement (se Tabell 2). I en
kommunikasjonshub-modell vil utveksling av grunnlagsdata være en en-stegs prosess,
mellom målepunktadministrator (nettselskap) og kraftleverandør. I en datahub-modell
vil utveksling av grunnlagsdata være en to-stegs prosess, der data lagres i huben,
samtidig som interessenter informeres om endringer.
5.3.2 Datautveksling for oppdatering av grunnlagsdata i en kommunikasjonshubmodell
Figur 9 - Sekvensdiagram for oppdatering av grunnlagsdata i en kommunikasjonshub-modell
Forutsetninger for oppdatering av grunnlagsdata ved en kommunikasjonshub-modell:
Grunnlagsdata sendes direkte mellom målepunktadministrator og kraftleverandør
via kommunikasjonshuben.
31

5.3.3 Datautveksling for oppdatering av grunnlagsdata fra nettselskap i en datahub
Figur 10 - Sekvensdiagram for oppdatering av grunnlagsdata fra nettselskap i en datahub-modell
Forutsetninger for leverandørskifte ved en datahub-modell:
Grunnlagsdata oppdateres direkte i datahuben av nettselskapene og
kraftleverandøren. Aktørene henter grunnlagsdata ved behov.
Det er ikke lenger behov for dagens spesielle melding for porteføljestatus (Z28).
Denne erstattes av en generell melding med grunnlagsdata.
32

5.4 Håndtering av måledata og avregning
Innføring av AMS kreves nye rutiner for håndtering av måledata i henhold til
forskriften. Følgende forutsetninger er lagt til grunn for utarbeidelse av forslag til nye
rutiner:
Rutinene skal oppfylle kravene i forskrift 301
Formålet med måledata er korrekt avregning samt underlag for beslutningsstøtte
knyttet til energieffektivisering og andre tilleggstjenester. I tillegg vil det være
viktige underlagsdata for drift og utnytelse av distribusjons- og overføringsnett
og ved nettinvesteringer (nettnytte)
Det forutsettes at nettselskapene er ansvarlige for innsamling og kvalitetssikring
av måleverdier. Dette anses som en konkurranseutsatt virksomhet der
nettselskapene kan velge å gjøre det selv, de kan gå sammen med andre
nettselskap eller de kan sette det ut til en tredjepart. Således vil disse tjenestene
kunne utføres kostnadseffektivt til en markedsbasert pris
Måleverdier med tilhørende informasjon (metadata) skal oppfattes og tolkes likt
uavhengig av hvilket nettselskap de kommer fra
Nettselskaper skal distribuere måleverdier i form av timevolumer slik at
sluttbruker og kraftleverandør mottar måleverdier i form av energimengder
Sluttbruker og kraftleverandør skal ha ett grensesnitt for tilgang til måledata
uavhengig av hvilket nettselskap de kommer fra
Avrundingsregler i henhold til norsk Ediel-standard
5.4.1 Innsamling og distribusjon av måleverdier
Kraftbransjen bruker i dag mye tid på å korrigere måleverdier og det skaper mye
friksjon mellom aktørene. God kvalitet på måleverdier er en forutsetning for et
velfungerende marked og AMS representerer en mulighet til å få ett vesentlig løft i
kvaliteten på måleverdier. Derfor er det viktig at det legges opp til regler og rutiner som
sikrer best mulig kvalitet så raskt som mulig.
Måleverdier innsamles, kvalitetssikres og distribueres av nettselskapene. Det er videre
nettselskapenes ansvar å sørge for at feil ved måleverdier korrigeres og at
korrigeringene blir distribuert så raskt som mulig. Vi tar i denne sammenheng
utgangspunkt i krav til grensesnittet fra nettselskapene for distribusjon av måleverdier
til sluttbrukere og markedsaktører. Det blir opp til det enkelte nettselskap å bestemme
hvordan de skal fremstille påkrevde data i dette grensesnittet.
Ut i fra et kostnads- og effektivitetshensyn vil det være hensiktsmessig at
måleverdihåndteringen standardiseres i forhold til validering, estimering og editering
(VEE). Dette fordi måleverdiene skal deles av mange markedsaktører på tvers av
nettselskaper og da må det være et krav at en målerverdi betyr eksakt det samme
uavhengig av hvilket nettselskap den kommer fra. Slik standardisering vil være påkrevd
uavhengig av hvilke felles IKT løsninger som velges. Det anbefales at det etableres,
dokumenteres og vedlikeholdes en nasjonal standard for VEE. I det følgende beskrives
forslag til overordnet innhold i en norsk VEE standard.
Kraftleverandør kan få fullmakt fra sluttbruker til å vise historiske data for målepunktet
for perioden aktuell sluttbruker har vært tilknyttet målepunktet, siden det er sluttbruker
som eier sine egne forbruksdata. Dette kan medføre ulike tilgangs- eller
autorisasjonsnivåer.
33

Ved manglende måledata skal disse estimeres.
Estimering skal foregå etter de til enhver tid gjeldende retningslinjer.
5.4.1.1 Måleverdier
Selv om nettselskapene samler inn og behandler måleverdier i form av stander
(avlesning i kWh) er det volumer (forbruk i en periode i kWh/h) som skal distribueres
til sluttbrukere og kraftleverandører. Volumer er enklere å forholde seg til for
sluttbrukeren og faktureringen er relatert til volumer. Hvis sluttbrukeren også skal
forholde seg til stander blir det for komplekst. En innvending er sluttbrukerens mulighet
til verifikasjon og at han vil kunne lese av stand på måleren. I så fall må sluttbrukeren
jevnlig lese av stand fordi det som vises på måleren aldri vil være det samme som den
stand som eventuelt vil stå på en faktura. Hvis han jevnlig leser av stand vil han uansett
kunne kontrollere dette mot de timevolumer han kan hente fra en felles IKT løsning. Vi
tror heller ikke at en sluttbruker i fremtiden vil lese av stand direkte på måleren, men at
han vil ha utstyr direkte knyttet til sin måler som loggfører forbruk i form av volumer.
Distribusjon av stander ville medføre at flere enn nettselskapene må ha funksjonalitet
for å håndtere stander og at feilhåndtering blir mer kompleks og omfattende for
markedsaktørene.
Datakvalitet på måledata hos nettselskap og incitamenter for å få denne best mulig:
Datakvaliteten på måledata vil bli bedre ved innføring av AMS. Dette begrunnes
i at sluttbruker, kraftleverandør, tredjeparts aktør, avregningsansvarlig og
regulator vil kreve god kvalitet
Nettselskapene tjener på økt datakvalitet i form av mindre klager, spørsmål,
korrigeringer etc.
Det er enklere for NVE å forholde seg til statistikk fra en datahub enn direkte fra
aktørene, som ved utarbeidelse av ulike typer KPI
5.4.1.2 Tidsfrister
Distribusjon av måleverdier fra nettselskap skal i henhold til forskriften være ferdig
innen kl.09:00 hver ukedag for 24 timevolumer for foregående døgn. Det må i tillegg
legges til rette for oppdatering av måleverdier slik at eventuelle feil kan korrigeres, men
måleverdier skal bare oppdateres dersom verdi eller verdien sin status har blitt endret.
Det bør derfor innføres tidsfrister for korrigeringer som gir insentiv til best mulig
datakvalitet så tidlig som mulig.
Følgende tidsfrister foreslås:
Tidsfrist Hva Status
Innen kl. 09:00 D+1
Maskinelt (automatisk)
kvalitetssikrede og eventuelt
estimerte måleverdier tilgjengelig
for sluttbruker og kraftleverandør
for alle timemålte målepunkt
Måledata for analyse
og beslutningsstøtte
Skal også kunne
brukes til fakturering
dersom status 127
Innen kl. 24:00 D+5 Kvalitetssikrede måleverdier klar Faktureringsklare
34

Innen M+3
Utover M+3
for fakturering og balanseavregning
Korrigerte kvalitetssikrede
måleverdier gjenstand for
symmetrisk korreksjonsoppgjør
Korrigerte kvalitetssikrede
gjenstand for asymmetrisk
korreksjonsoppgjør
måledata
Korrigerte
faktureringsklare
måledata
Korrigerte
faktureringsklare
måledata
D: Døgn for aktuelt forbruk/produksjon
M: Kalendermåned for aktuelt forbruk/produksjon
Tabell 3 – Tidsfrister
5.4.1.3 Korreksjoner utover M+3
For å sikre best mulig kvalitet og unngå korreksjonsoppgjør langt tilbake i tid bør dette
legges til nettselskapene slik at de i størst mulig grad unngår korreksjoner utover M+3.
Dette kan være i form av et asymmetrisk korreksjonsoppgjør dersom det identifiseres
feil i måleverdiene etter M+3, hvor det foretas et oppgjør mot sluttbruker via
kraftleverandøren dersom sluttbrukeren har blitt fakturert for mye som følge av feilen.
Dersom sluttbrukeren har blitt fakturert for lite som følge av feilen må nettselskapet selv
dekke tapet i nettleien. Nettselskapet skal også kompensere balanseansvarlig (for
sluttbrukeren) dersom denne har blitt påført tap som følge av feilen.
Alternative insentivmodeller kan være kvalitetsindekser som rapporteres per nettselskap
for % kvalitet etter 1 dag, 5 dager og 3 måneder. Basert på slike oversikter kan hub
ansvarlig og regulator følge opp og i ytterste konsekvens gi bøter for dårlig kvalitet.
Det er viktig å nøye vurdere datakvaliteten i oppstartsfasen av AMS og legge
ambisjonsnivået for kvalitet på "beste praksis" og ikke legge opp til urimelig høye krav
før en har erfaring med hva AMS teknologien kan levere.
Historiske måleverdier i en datahub skal alltid oppdateres, også utover M+3.
5.4.1.4 Standard prosesser innen kl. 09:00 D+1
Pga. den korte tidsfristen må relevante prosesser automatiseres.
5.4.1.5 Automatisk validering
I denne sammenheng tas det ikke stilling til validering av fysisk overføring og format.
Det er en intern prosess som avhenger av hvilken teknologi som ligger til grunn for
innsamlingssystemet. Videre forutsettes det at måleverdiene er transformert til
timevolumer (kWh/h).
Formålet med valideringsprosessen er å identifisere kvaliteten til måledataene og sette
en status på hver enkelt måleverdi. Det legges opp til følgende statuser i henhold til
internasjonal standard:
35

127 – Målt
56 – Estimert
21 – Midlertidig
Disse kodene skal settes i henhold til følgende regler:
127 – Målt Brukes på faktisk målte data hvor det ikke er grunn til å anta at
data kan være feil.
56 – Estimert Brukes ved manglende data fra innsamling eller at data åpenbart
må være feil. Estimering er da påkrevd. Estimeringsmetode
avhenger av hvor mye og hvilke data som mangler.
21 – Midlertidig Brukes når det antas at måleverdien vil bli endret på et senere
tidspunkt. Det kan være innsamlede måleverdier som feiler i
rimelighetskontroll. Data med denne koden må oppdateres innen
kl. 24:00 D+5 til enten 127 eller 56.
Tabell 4 - Kodebruk for valideringsprosessen
5.4.1.6 Standard prosesser innen kl. 24:00 D+5
Nettselskapene har fire dager på å korrigere verdier fra D+1 fristen. Nettselskapene skal
bare sende oppdatering dersom verdi eller status har blitt endret for en måleverdi. Innen
denne tidsfristen skal alle måleverdier ha en av følgende statuser fastsatt i henhold til
følgende regler:
127 – Målt
56 – Estimert
Brukes på faktisk målte data hvor det ikke er grunn til å anta at
data kan være feil.
Brukes også for tidligere estimerte verdier etter at det har
kommet inn en faktisk avlesning og det ikke er grunn til å anta at
data kan være feil.
Dersom en måleverdi sendes med denne status i denne
tidsperioden betyr det at det enten er en korrigering av tidligere
målt eller at en estimert eller foreløpig er erstattet med målt.
Brukes når data er estimert og det ikke forventes at målte eller
mer nøyaktige data vil kunne fremskaffes senere. Selv om disse
måledata er estimert tidligere skal det gjøres en ny estimering
dersom datagrunnlaget for estimeringen er endret.
Tabell 5 - Kodebruk for standard prosesser kl. 24.00 D+5
5.4.1.7 Standard prosesser etter D+5
Dersom en feil oppdages etter fem dager skal verdiene oppdateres i henhold til følgende
regler:
36

127 – Målt Brukes på faktisk målte data hvor det ikke er grunn til å anta at
data kan være feil.
Brukes også for tidligere estimerte verdier etter at det har
kommet inn en faktisk avlesning og det ikke er grunn til å anta at
data kan være feil.
Dersom en måleverdi sendes med denne status i denne
tidsperioden betyr det at det enten er en korrigering av tidligere
målt verdi eller at en estimert verdi er erstattet med målt.
56 – Estimert
Brukes når data er estimert og det ikke forventes at målte eller
mer nøyaktige data vil kunne fremskaffes senere. Selv om disse
måledata er estimert tidligere skal det gjøres en ny estimering
dersom datagrunnlaget for estimeringen er endret.
Tabell 6 - Kodebruk for standard prosesser etter D+5
Både verdi og kode kan endre seg, dvs. at en verdi kan være den samme men at koden
er endret og visa versa. En måleverdi kan endres mange ganger i syklusen beskrevet
ovenfor; i teorien uendelig mange ganger. Det er ikke mulig for mottaker å identifisere
om en verdi har endret seg ved bare å se på koden. Derfor må en måleverdi også være
identifisert fra nettselskapet med måleverdi dato og klokkeslett.
5.4.1.8 Kontroll av måledata
Kontroll av måledata hos nettselskapene bør standardiseres. Som minimum bør
følgende kontrolleres:
Manglende verdier
Dynamiske grenseverdier
Negativt forbruk; Det skal ikke sendes negative timevolumer, utenom ved
korreksjoner. All produksjon skal måles separat og utveksles som positive
timevolumer
Volum mot stander
Kontroll skal utføres av nettselskapet ved innsamling av måleverdier. Kontrollen skal
vurdere om en måleverdi er:
høyst sannsynlig riktig
o Innenfor intervallet som er satt som en sannsynlig verdi for målepunktet
o Målevolumet får kode 127
høyst sannsynlig uriktig
o Utenfor intervallet satt som en sannsynlig verdi for målepunktet
o Målevolumet må estimeres og får kode 56
usikker
o Målerverdien er i et intervall hvor det hverken er høyst sannsynlig riktig
eller høyst sannsynlig uriktig
o Målevolumet får kode 21
37

5.4.1.9 Estimeringsmetoder
Det foreslås at estimering i hovedsak gjøres med utgangspunkt i det enkelte anleggs
individuelle måledata. I de tilfeller det ikke finnes måledata, for eksempel et nytt
anlegg, skal det benyttes antatt årsforbruk på anlegget, vektet etter innmatingsprofilen
for nettområdet.
Estimeringsmetoder skal ikke benytte topp- eller bunnverdier innenfor en døgnserie.
Dette har to årsaker:
1. Topp- og bunnverdier kan være gjenstand for effektprising eller andre
insentiver og feilaktig estimerte topper/bunner vil ha større negativ
konsekvens enn estimeringer som gir verdier likere de andre verdiene i
døgnserien
2. Estimerte topp- og bunnverdier vil kunne skille seg ut og i større grad medføre
klager fra forbrukerne.
5.4.1.9.1 Feil innenfor timeintervall med målt totalvolum
Dersom det finnes målte stander (med kode 127) ved inngang og utgang av et
timeintervall der det mangler verdier for timer innenfor dette intervallet, skal summen
av volum for estimerte enkelttimer innenfor timeintervallet tilsvare differansen mellom
målt stand ved utgang og inngang av intervallet.
Når data som skal estimeres er mindre enn ett visst maksimum sammenhengende
tidsintervall, for eksempel 2 timer skal det kjente totalvolumet fordeles flatt i estimering
av enkelttimene i dette intervallet.
Når data som skal estimeres er mindre enn ett visst minimum sammenhengende
tidsintervall, for eksempel 3 timer skal det kjente totalvolumet fordeles i henhold til
anlegges historiske profil for disse timene.
5.4.1.9.2 Feil innenfor timeintervall uten målt totalvolum
Dersom det ikke finnes målt stand (med kode 127) ved inngang og/eller utgang av et
timeintervall skal manglende verdier estimeres basert på historisk estimering. Da brukes
ett gjennomsnitt av tre tilsvarende historiske tidsintervaller som ligger nærmest i tid og
hvor en tar høyde for normale arbeidsdager og fridager i henhold til norsk kalender.
5.4.2 Distribusjon av måledata
I henhold til alternative modeller vil vi her skille mellom distribusjon i en
kommunikasjonshub og distribusjon gjennom en datahub.
5.4.2.1 Distribusjon gjennom en kommunikasjonshub
Det forutsettes at en kommunikasjonshub gir sluttbruker og kraftleverandør ett
grensesnitt for tilgang/ nedlasting av data.
38

Datautveksling for innsamling og distribusjon av måleverdier i en kommunikasjonshub
er illustrert i følgende figur:
Figur 11 - Sekvensdiagram for innsamling og distribusjon av måleverdier i en kommunikasjonshubmodell
Det må legges opp til at en kraftleverandør eller tredjepart kan hente ut måledata
gjennom en kommunikasjonshub som alle nettselskaper er tilknyttet gjennom ett
standard grensesnitt. Nettselskapet sender (pusher) data til kraftleverandør og tredjepart
gjennom kommunikasjonshuben, i henhold til kravene om distribusjon av data, dvs.
hver dag for foregående døgn samt endringer på eldre data.
Tredjepart og kraftleverandør skal kunne foreta en spørring via kommunikasjonshuben,
som identifiserer aktuelt nettselskap, for eksempel på bakgrunn av målepunktid, og
videresender forespørsel. Nettselskapene returnerer relevante data som sammenstilles
og presenteres/sendes til tredjepart og kraftleverandør. Kommunikasjonshuben lagrer i
prinsippet ingen informasjon, men det kan være prosesseringsmessig effektivt at
kommunikasjonshuben lagrer oppdatert informasjon om hvilke nett en kraftleverandør
er operativ i. I denne løsningen er det nettselskapet som har ansvaret for distribusjon av
måledata til sluttbruker via kraftleverandør eller tredjepart. Det forutsettes at
kommunikasjonshuben vil være en automatisert tjeneste som drives av en teknisk
driftsorganisasjon.
Løsningen krever følgende:
En kommunikasjonshub med funksjonalitet for å motta og rute forespørsler samt
innsamle, sammenstille data fra flere nettselskap og returnere data.
Kommunikasjonshuben må videre ha nokså kompleks funksjonalitet for å
håndtere forespørsler fra kraftleverandør og tilhørende svar fra nettselskap.
Feilsituasjoner må også håndteres automatisk
Alle nettselskap er integrert mot grensesnittet til kommunikasjonshuben med
høy grad av tilgjengelighet
Identifikasjon av sluttbruker-målepunkt-måleverdier. Nettselskap må holde rede
på sluttbruker, kraftleverandør, målepunkt-id, alternativt må kommunikasjonshuben
ha denne informasjonen, slik at forespørselen fra kommunikasjonshuben
til nettselskap spør på målepunkt-id.
Autorative data lagres hos ansvarlig for innsamling og kvalitet, samt nærmest
data-kilden
39

Samfunnsøkonomi
For nettselskapene vil det være noe mer kostbart| å gjøre måledata tilgjengelig i en
kommunikasjonshub-modell som i en datahub-modell. Dette skyldes at en
kommunikasjonshub krever større grad av tilgjengelighet og oppetid.
Det vil bli kostbart å bygge og drifte en kommunikasjonshub-tjeneste men vesentlig
lavere kostnad enn en datahub.
Tilpasninger som følge av nye krav til markedsløsninger vil sannsynligvis medføre
endringer for alle nettselskaper og således kostbart samfunnsøkonomisk.
Kraftleverandørog nettselskap må løse feil og uoverensstemmelser seg i mellom. Det vil
være kostbart og tidkrevende i seg selv, men det vil også øke terskelen for konkurranse i
de ulike nettområder, spesielt de litt mindre.
I en kommunikasjonshub-modell foreslås det en sentral drifts- og supportorganisasjon
som en del av kommunikasjonshuben. Denne vil delvis kunne håndtere manglende data
og oppfølging mot nettselskapene ved avvik.
Støtter ny markedsmodell
Gir støtte til ny nordisk, eventuelt europeisk, markedsmodell men krever detaljerte krav,
disiplin og oppfølging av 130 nettselskaper.
Sluttbruker sin tilgang til egne historiske måledata kan bli komplisert på grunn
leverandørsentrisk modell ved leverandørskifter og flytting.
Sluttbruker vil ikke merke om data blir lagret i en datahub eller desentralt.
Løsningen kan gi større utfordringer for dokumentering og opprettholdelse av
nøytralitet.
Tilgang til måledata for kraftleverandører og tredjeparter vil kreve stor ytelse hos
nettselskapene.
En kommunikasjonshub-modell vil ikke være best alternativ med tanke på et nordisk og
europeisk marked, begrunnet i mer pågang mot hver enkelt nettselskaps database fra
kraftleverandører, tredjeparter osv.
For nye kraftleverandører i markedet vil etablering bli enklere gjennom bare ett
grensesnitt og de vil ha samme tilgang til måledata som eksisterende kraftleverandører.
Det vil også gjøre at sluttbruker i mindre nettområder vil kunne oppleve samme tilbud
av kraftleverandører som i større nettområder.
Teknisk robust løsning
130 nettselskap skal ha ansvaret for hver sin tekniske løsning. Det antas at en
kommunikasjonshub-modell vil gi en mindre robust løsning enn en datahub-modell,
siden nettselskapene vil benytte ulike systemløsninger og man mister stordriftsfordelene
knyttet til en datahub. I mange forretningsprosesser utover avregning av det enkelte
målepunkt, vil kvaliteten avhenge av det svakeste leddet (for eksempel ved
beslutningsstøtte for anmelding for neste døgn samt balanseavregning).
Løsningen vil kreve mye høyere investeringer hos nettselskapene grunnet høyere krav
til prosesseringstid, lagringskapasitet, oppetid, backup løsninger, logging og oppfølgingsrutiner
for manglende data.
40

Implementering
Det er god grunn til å anta at en kommunikasjonshub-modell gir korteste og minst
risikofylte vei i implementeringen. Men det er også grunn til å anta at testing og
produksjonssetting kan bli utfordrende med så mange ulike aktører.
5.4.2.2 Distribusjon gjennom en datahub
Det forutsettes her at alle nettselskap leverer kvalitetssikrede måledata i form av kWh/h
verdier til en datahub som lagrer dataene og gjør dem tilgjengelige for sluttbruker og
kraftleverandør. Datahuben vil da være autorativ datakilde for oppgjør. Nettselskapet får
ansvar for at dataene kommer frem til sentralen. Etter dette overtar datahuben ansvaret
for distribusjon og tilgjengelighet ovenfor sluttbruker, kraftleverandør og tredjepart.
Datahuben vil da drive aktiv feilsøking og oppfølging av nettselskapene i forhold til
manglende data. Sluttbruker og kraftleverandør og tredjeparter vil måtte henvende seg
til datahuben ved mangler i forhold til mottatte data.
Datautveksling for innsamling og distribusjon av måleverdier i en datahub er illustrert i
følgende figur:
Figur 12 - Sekvensdiagram for innsamling og distribusjon av måleverdier i en datahub-modell
Løsningen krever følgende:
En datahub med måleverdidatabase, meldingshåndtering og ett operativt miljø
for både service og teknisk drift
Nettselskapene må sende inn måledata, men kan bruke samme teknologi som i
dag (Ediel standarden)
datahuben må ha grensesnitt for distribusjon av data til sluttbruker og kraftleverandør
Samfunnsøkonomi
En felles datahub for innsamling, datalagring og distribusjon vil være kostbar i forhold
til investering og drift.
41

En felles datahub vil på en nøytral og transparent måte gjøre det mulig å måle og
sammenligne kvaliteten på måleverdikjeden på tvers av nettselskaper. Dette gir beste
forutsetninger for god datakvalitet som igjen sikrer færrest mulig feil og lavest mulig
kostnader ved feilhåndtering.
En felles datahub representerer kun ett operativt grensesnitt å forholde seg til for både
nettselskap og kraftleverandører. Det antas at det vil bli enklere å få til en enhetlig
oppfølging av regelverk og praksis. Videre vil nettselskapene få færre henvendelser i en
datahub-modell.
Det vil kun bli en kommunikasjonsløsning inn til og ut av den sentrale databasen. Det
vil medføre større grad av standardisering av IKT løsninger for både nettselskaper og
kraftleverandører. Det vil medføre lavere investerings- og vedlikeholdskostnader.
Med alle måledata på ett sted vil det kun bli ett grensesnitt ut mot sluttbrukere og
kraftleverandører i sluttbrukermarkedet. Fremtidige endringer i markedsmodell
angående distribusjon av måledata vil høyst sannsynlig kunne løses uten endringer fra
nettselskapene sin side. Slike fremtidige endringer i markedsmodell vil således bli
billigere.
Støtter ny markedsmodell
Gir god støtte til ny nordisk, eventuelt europeisk, markedsmodell. Utveksling av
måledata via en datahub-modell vil medføre at ny krav til måleverdiutveksling høyst
sannsynlig kan løses ett sted. For nye kraftleverandører i markedet vil etablering bli
enklere gjennom bare ett grensesnitt og de vil ha samme tilgang til måledata som
eksisterende kraftleverandører. Det vil også gjøre at sluttbrukere i mindre nettområder
vil kunne oppleve samme tilbud av kraftleverandører som i større nettområder.
Modellen gjør det enklere for sluttbruker å få tilgang til egne historiske data og en enkel
tilgang til datahuben for tredjeparter vil øke tilbudet av produkter for blant annet
energiøkonomisering.
Løsningen vil potensielt legge bedre til rette for dokumentering og opprettholdelse av
nøytralitet.
Teknisk robust løsning
Stordriftsfordeler vil gi grunnlag for høy kvalitet i en datahub-modell. De autorative
måleverdiene vil kunne bli lagret, vedlikeholdt og distribuert med høyest mulig grad av
redundans og sikkerhet.
En datahub krever rask prosesseringstid, mye lagringskapasitet, 100 % oppetid, effektiv
backup løsning og oppfølgingsrutiner for manglende data etc. Det må sikres logging av
all aktivitet for å spore og hindre misbruk.
Det må tas høyde for og legge til rette for at man vil operere med kvarters-verdier.
Det kan være utfordringer knyttet til synkronisering av data mellom nettselskapene og
datahub (inkonsistens).
Implementering
Det finnes ingen ferdig programvare som tilfredsstiller de krav som vil måtte stilles til
en datahub i Norge. Det finnes imidlertid løsninger tilgjengelig som «ligner» men de
42

norske kravene til ytelse når det gjelder innhenting og distribusjon av måledata er unike.
En må anta en omfattende utvikling og implementering som vil ta relativt lang tid og
med vesentlig utviklingsrisiko.
5.4.3 Rapportering til balanseavregning (Ukeavregning)
Med rapportering til balanseavregning menes de aktiviteter som Beregningsansvarlig (i
dag Nettselskapet) har ansvar for å utføre i forbindelse med å framskaffe grunnlag for
avregning av regulerkraft knyttet til kraften hver enkelt balanseansvarlig tar ut i
Nettområdet. Beregningsansvarlig aggregerer volum pr. komponentkode i nettet.
Avregningsperioden for regulerkraft er i dag en uke.
Avregningsansvarlig foretar økonomisk avregning mot Balanseansvarlig av differansen
mellom kraftuttaket som Balanseansvarlig har forhåndsmeldt og det kraftuttak som
Nettselskap rapporterer i Nettområdet.
5.4.3.1 Datautveksling for rapportering til balanseavregning i en kommunikasjonshubmodell
Figur 13 - Sekvensdiagram for rapportering til balanseavregning i en kommunikasjonshub-modell
Forutsetninger for rapportering til balanseavregning i en kommunikasjonshub-modell:
Nettselskapet gjør aggregeringen
43

Dersom det oppstår avvik før balanseavregningen er kjørt vil det bli sendt
korrigerte aggregerte måleverdier til alle involverte aktører
(avregningsansvarlig, balanseansvarlig og kraftleverandør)
5.4.3.2 Datautveksling for rapportering til balanseavregning i en datahub-modell
Figur 14 - Sekvensdiagram for rapportering til balanseavregning i en datahub-modell
Forutsetninger for rapportering til balanseavregning i en kommunikasjonshub-modell:
Datahuben gjør aggregeringen
5.4.4 Avviksoppgjør
I forbindelse med detaljering av en ny leverandørsentrisk markedsmodell for det norske
kraftmarkedet må det beskrives en prosess for korrigeringer av feil på faktura/
målerverdier. Denne prosessen forventes å bli tilsvarende dagens prosess for
«korreksjon på timemålte målepunkter mellom nettselskap og kraftleverandør» 2 . Se
også avsnitt 5.4.1.3 (Korreksjoner utover M+3).
2 Prosessbeskrivelser for avregningsgrunnlag, siste versjon, www.ediel.no
44

5.4.4.1 Avviksoppgjør i en kommunikasjonshub-modell
Figur 15 - Sekvensdiagram for avvikshåndtering i en kommunikasjonshub-modell
Forutsetninger for avviksoppgjør i en kommunikasjonshub-modell:
Nettselskapet er ansvarlig for aggregering av måleverdier og avviksoppgjør
Prosessen for avviksoppgjør er kun relevant etter at rapportering til
balanseavregning er foretatt
5.4.4.2 Avviksoppgjør i en datahub-modell
Figur 16 - Sekvensdiagram for avvikshåndtering i en datahub-modell
Forutsetninger for avviksoppgjør i en datahub-modell:
Datahuben er ansvarlig for aggregering av måleverdier og avviksoppgjør
Prosessen for avviksoppgjør er kun relevant etter at rapportering til balanseavregning
er foretatt
45

5.4.5 Kundeavregning og fakturering
5.4.5.1 Totalfakturering
NordREG anbefaler at modellen for fakturering av sluttbruker i det fremtidige felles
nordiske kraftmarkedet skal være obligatorisk totalfakturering utført av
kraftleverandøren. Løsningen skal være kundevennlig og fremme konkurransen i
kraftmarkedet. Dette innebærer at sluttbrukeren alltid skal motta en samlet faktura som
inneholder både kraft og nett-tariff. 3 Endelig avklaring for hvordan dette skal
gjennomføres i det norske markedet er ikke bestemt, men anbefalt fremtidig modell fra
ESK må oppfylle kravet om totalfakturering utført av kraftleverandør.
Argumentene bak NordREGs anbefaling er:
• Kundevennlig – sluttbrukeren vil motta én faktura og ha et kontaktpunkt
(kraftleverandøren). Løsningen vil være lettere for sluttbrukeren å håndtere,
lettere for sluttbrukeren å forstå, mer konsistent kommunikasjon mot
sluttbrukeren, sluttbrukeren får oversikt over sin totale energikostnad, og
mulighet for å opptre mer aktivt i markedet
• Velfungerende marked og økt konkurranse – styrker forholdet mellom
kraftleverandør og sluttbruker, økt konkurranse mellom kraftleverandører, økt
tilfredshet ved bytting (får fortsatt en faktura) som igjen øker byttehastigheten i
markedet, kraftleverandører kan tilby nye løsninger
• Økt effektivitet – lik prosess i hele markedet som er strømlinjeformet og gir
grunnlag for effektivisering
• Tilfredsstiller EU regulering og utvikling – samlet fakturering er mest vanlig i
EU, og det forventes at fremtidig modell i EU fortsatt vil bli samlet fakturering
• Nøytralitet i forhold til nettselskap – kraftleverandøren vil ha hovedkontakten
med sluttbrukeren og løsningen vil redusere den dominerende aktørens
markedsposisjon. Vil på sikt øke attraktiviteten for nye kraftleverandører i det
nordiske markedet
• Kost-nytte – NordREG har evaluert alternative løsninger 4 , og kommet frem til
at den anbefalte modellen har den beste samfunnsøkonomiske nytteverdien
5.4.5.2 Begrepsavklaringer
I beskrivelsen benyttes følgende begreper:
Avregning - innsamle nødvendige underlagsdata for etablering av ferdig
avregningsunderlag for sluttbruker. Avregningsunderlag blir utarbeidet for kraft
og nett-tariff. I avregningsunderlaget inngår offentlige avgifter som moms, elavgift,
el-sertifikater og andre avgifter/skatter. Avregningsunderlaget baserer seg
på faktisk forbruk hos sluttbruker multiplisert med en kostnad per volumenhet, i
tillegg kan det tillegges volumuavhengige fastpriselementer som inngår i
kontrakten med sluttbrukeren
3 NordREGs reccomendation on the future model for billing customers in the harmonised Nordic end-user market,
4 IBID
December 19th 2011.
46

Totalfakturering - utsendelse av én faktura for både kraft, nettleie og avgifter.
Totalfaktura utarbeides basert på avregningsunderlaget fra kraftleverandør og
nettselskap. Det skal være mulighet for å synliggjøre de forskjellige
kostnadselementene som kraft, nett-tariff, avgifter etc. på fakturaen slik at
sluttbrukeren kan se de ulike kostnadselementene
Engros-modellen - kraftleverandøren selger og fakturerer sluttbrukeren for de
totale kostnadene relatert til elforbruket (nettleie, kraftkostnad og avgifter) og
mottar betalingen fra sluttbrukeren. Nettleien skal utgjøre det samme som om
nettselskapet hadde fakturert sluttbrukeren selv for nettleien. Kraftleverandøren
på sin side betaler nettselskapene for den totale nettleien inklusiv mva som
kraftleverandørens sluttbrukere samlet sett er gjenstand for i de respektive
nettselskapenes distribusjonsnett. Øvrige avgifter/skatt betales av
kraftleverandøren til relevante skatteetater
Det er ikke bestemt i NordREG eller hos NVE hvordan fakturering skal gjennomføres i
det fremtidige markedet. I dette arbeidet er det forutsatt at det benyttes en engrosmodell.
Et alternativ kan være en gjennomfaktureringsmodell, hvor kraftleverandøren
sender en faktura til sluttbruker bestående av to dokumenter; en for kraft og en for netttariff.
I en gjennomfaktureringsmodell vil sluttbrukeren ha to kontrakter; en med
kraftleverandør, og en med nettselskapet. En konsulentrapport utarbeidet for NordREG
av Ernst & Young foreslår en gjennomfaktureringsmodell, alternativt kombinert med en
klientkonto. 5
Vurdering i ESK prosjektet og fremtidig IKT struktur påvirkes sannsynligvis ikke på et
overordnet nivå av om det benyttes en engros-modell eller en gjennomfaktureringsmodell.
5.4.5.3 Beskrivelse av totalfaktureringsmodellen
Modellen består av fire steg:
1. Innsamling av forbruksdata
2. Avregning
3. Fakturering
4. Innfordring
Nettselskapene har følgende oppgaver i totalfaktureringsmodellen:
1. Fremskaffelse av sluttbrukerens forbruk (måledata)
2. Distribusjon av måledata til kraftleverandør slik at kraftleverandør kan utarbeide
avregningsunderlag for kraft
3. Utarbeidelse av ferdig avregningsunderlag pr målepunkt for nett-tariff som
tilgjengeliggjøres for kraftleverandør. Eventuelle avgifter og skatter skal inngå i
avregningsunderlaget. I en datahub-modell vil tilgjengeliggjøring av
avregningsunderlaget for nett-tariff gjøres av en datahub (ref. kapittel 1.1.5)
4. Nettselskap fakturer kraftleverandør for total nett-tariff og eventuelle avgifter
(faktureres som varekjøp etter en engros-modell)
Kraftleverandørene har følgende oppgaver:
5 Credit risk management in future billing regime. A common Nordic end-user market with combined billing, 9
March 2012
47

1. Utarbeidelse av avregningsgrunnlag for kraft pr målepunkt
2. Kraftleverandør kan samle flere målepunkt pr sluttbruker, også for sluttbrukere
som har målepunkt i flere nettområder
3. Sammenstilling av avregningsunderlag for kraft og nett-tariff og etablering av
faktura for nett-tariff, kraft og avgifter. Faktura sendes fra kraftleverandør til
sluttbruker
4. Kraftleverandør står for inndrivelse av fakturabeløp sendt til sluttbruker
5. Betale faktura til nettselskap for total nett-tariff for kraftleverandørens
sluttbrukere i nettselskapets område (engros-modellen)
I utarbeidelse av konkret modell for totalfakturering må det vurderes om
kraftleverandøren skal ha stenge- og struperett ved manglende betaling samt betingelser
og ansvar knyttet til dette.
De ulike oppgavene og grensesnitt mellom nettselskap, kraftleverandør og sluttbruker i
totalfaktureringsmodellen vises i figuren under:
Faktureringsprosessen
Nettselskap
Kraftleverandør
Sluttbruker
Innsamling
forbruksdata
Avregning
Fakturering
Faktura
Betaling
Faktura
Innfordring
Betaling
Figur 17 - Totalfaktureringsmodell
Avregning er delt mellom nettselskap og kraftleverandør, dvs. at nettselskapet gjør
avregning av nettleien, mens kraftleverandøren gjør avregning av kraft.
Nettselskapet fakturerer kraftleverandøren totalsummen for nettleie for
kraftleverandørens sluttbrukere, mens kraftleverandøren totalfakturerer sluttbruker.
Nettselskap må vite hvem som er kraftleverandør siden de skal fakturere
kraftleverandørene for nettleie uansett hvor beregning av fakturalinjer på målepunkt
ligger.
5.4.5.3.1 Tidspunkt for avregning og fakturering
Tidspunkt for utarbeidelse av avregningsunderlag følger en fastsatt tidssyklus som
nettselskapene definerer pr målepunkt. Alle kraftleverandører skal ha tilgang til ferdig
48

avregningsunderlag for nett-tariff og eventuelle avgifter i henhold til de definerte
tidsfrister.
Utarbeidelse av avregningsunderlag for nett-tariff krever mye prosessering og dermed
tidsforbruk av nettselskapene (eller i fremtiden datahuben), dette vil bli ytterligere
krevende med innføring av timesvolumer. For å redusere toppbelastningen i forbindelse
med prosessering for nettselskapene bør det åpnes for alternative løsninger.
En mulighet er at nettselskapene utarbeider avregningsunderlag for deler av sin
kundebase ved fastsatte intervaller (for eksempel 1/30 av målepunktene hver dag i
måneden, eller 1/4 hver uke). Ferdig avregningsunderlag gjøres tilgjengelig for
kraftleverandør så snart det er ferdigstilt, enten ved at nettselskap sender dette, eller at
det blir gjort tilgjengelig via datahuben. Avregningen skal være klar klokken 09:00 D+6
etter det aktuelle målepunktets siste dag av den på forhånd planlagte
avregningssyklusen til nettselskapet. Avregningen må minst bli gjort en gang i
måneden, men er ikke låst til kalendermåneder.
Kraftleverandør vil da ha forutsigbarhet for hvilke målepunkter som avregnes på gitte
tidspunkter. Kraftleverandøren vil benytte avregningsunderlaget fra nettselskapene og
inkludere kraft for samme periode som faktureres sluttbruker. Faktura til sluttbruker kan
således inneholde både kraft og nett-tariff for samme periode, slik at sluttbrukeren lett
kan få oversikt over sitt totale forbruk og kostnad.
Kraftleverandør kan, etter avtale med sluttbrukeren, fakturere sine sluttbrukere etter sitt
kraftprodukt og den hyppighet de selv ønsker.
Det må kunne faktureres kun kraft, dersom man ønsker en annen hyppighet enn når
fakturalinjer for nettleie blir sendt. Nettleien blir således tatt med på første faktura til
sluttbruker etter mottak hos kraftleverandør.
5.4.5.3.2 Håndtering av forskjellige nett-tariff strukturer
Leverandøren skal motta et ferdig avregningsunderlag med spesifisering av nett-tariffen.
Så selv med forskjellige nett-tariffer skal håndtering av avregningsgrunnlaget og
utarbeidelse av faktura kunne håndteres av kraftleverandørene.
Alle sluttbrukere skal motta informative regninger, hvor det tydelig skal fremgå de ulike
elementene nett-tariff, kraft og avgifter. Informasjon fra nettselskapet om endringer av
tariffer skal også kommuniseres via kraftleverandøren.
5.4.5.3.3 Håndtering av offentlige avgifter
I dag er nettselskapet pliktig til å inndrive offentlige avgifter og spesifikke
energirelaterte avgifter. I en leverandørsentrisk modell, vil det være fornuftig at dette
ansvaret blir overført til kraftleverandørene. Det er kraftleverandøren som har
kundekontakt, og derfor bør ansvaret for inndrivelse av avgifter ligge hos
kraftleverandør.
49

Denne rapporten vil ikke ta stilling til hvilken modell som er best egnet for håndtering
av offentlige avgifter og skatter. Både NordREG 6 og NVE har startet arbeid med å
vurdere alternative løsninger for dette.
5.4.5.3.4 Korreksjoner av måleverdier som er avregnet og fakturert
For korreksjoner som er kortere tilbake i tid enn inneværende måned og 3 måneder forut
skal håndteres av kraftleverandøren basert på korrigerte måleverdier fra nettselskapet
Korreksjoner av faktura eldre enn inneværende måned og 3 måneder forut skal foretas
mellom nettselskap og kraftleverandør i form av egen rutine for oppgjørskorrigering.
Måleverdier skal bli oppdatert i masterdatabasen for målerdata. Dette vil sikre
muligheten til å hente ut riktige historiske data. Nettselskapet har det økonomiske
ansvaret, og bærer tapet ved kreditering av sluttbruker.
5.4.5.3.5 Sikring av like konkurransevilkår og nøytralitet
Integrerte selskaper må splitte sine kundedatabaser mellom nett og kraft. Dette vil
innebære en kostnad, men er nødvendig for å oppnå like konkurransevilkår mellom
selvstendige kraftleverandører og kraftleverandører i et integrert selskap.
5.4.5.4 Totalfakturering i en kommunikasjonshub modell
Nettselskapet utarbeider avregningsunderlag og gjør dette tilgjengelig for
kraftleverandør gjennom den standardiserte kommunikasjonshub-løsningen. Det vil da
bli etablert ett grensesnitt for kommunikasjonen mellom nettselskap og kraftleverandør.
Hvert nettselskap må da sende ferdig avregningsunderlag til alle de kraftleverandørene
som har sluttbrukere i det spesifikke nettområdet.
Kraftleverandør sammenstiller avregningsunderlaget for nett-tariff og kraft og
utarbeider faktura for sluttbrukeren. Fakturaen skal inneholde og spesifisere nett-tariff,
kraft kostnad og alle avgifter.
5.4.5.5 Avregningsunderlag for sluttbrukeravregning i en kommunikasjonshub-modell
Med sluttbrukeravregning menes de aktiviteter som beregningsansvarlig (oppgavegiver) (i
dag nettselskapet) har ansvar for å utføre i forbindelse med å framskaffe
avregningsgrunnlaget til balanseansvarlig og kraftleverandør.
Beregningsansvarlig (oppgavegiver) (i dag nettselskap) skal på grunnlag av forbruk i de
målepunkt en balanseansvarlig har kraftleveranse, beregne det totale kraftuttaket den
balanseansvarlige, fordelt per kraftleverandør, har hatt i nettområdet i avregningsuken.
Det totale kraftuttaket fremkommer som summen av kraftuttaket i timeavregnede og
profilavregnede målepunkter og aggregeres pr. komponentkode.
6 Tax Collection in the future billing regime. A common Nordic end-user market with combined billing. Ernst &
young 8 March 2012
50

Figur 18 - Sekvensdiagram for avregningsunderlag for sluttbrukeravregning i en kommunikasjonshubmodell
5.4.5.5.1 Vurdering av kommunikasjonshub-modell
Samfunnsøkonomi
Nettselskaper kan utarbeide avregningsunderlag med samme systemer som i dag. Dog
vil det kreves at systemene håndterer større datamengder enn i dag grunnet innføring av
timesvolumer. Det vil kreves at avregningsunderlaget sendes gjennom en standardisert
kommunikasjonsløsning. Tilpasning til en slik løsning forventes å kreve endringer, men
sannsynligvis ikke store investeringer for å få dette til. Denne tilpasning må gjøres hos
alle nettselskaper.
Nettselskapene vil i totalfaktureringsmodellen ikke lenger trenge å fakturere og foreta
innfordring av sine sluttbrukere, da dette vil bli gjort av kraftleverandørene.
Nettselskapet vil fakturere kraftleverandørene for den totale nett-tariffen, dette vil
utgjøre et mindre antall fakturaer.
Kraftleverandørene må kunne motta ferdig avregningsunderlag for nett-tariff pr
målepunkt, og inkludere denne i sitt faktureringssystem. Det antas at kostnaden ved
tilpasning av en slik løsning ikke er stor.
Nettselskapene må utvikle en løsning hvor kraftleverandørene kan hente (pull)
historiske avregningsunderlag. Kostnaden for dette vil bli lagt på alle nettselskaper, og
vil bli en mer kostbar løsning enn i en datahub-modell hvor denne funksjonen vil ligge
hos datahuben.
Støtter ny markedsmodell
En løsning med kommunikasjonshub for fakturering vil muliggjøre totalfakturering av
kraft, nettleie og avgifter.
Kraftleverandørene vil være avhengig av kommunikasjon med hvert enkelt nettselskap,
og det vil være komplisert for en kraftleverandør å hente opp historiske
51

avregningsunderlag for nett-tariff dersom en sluttbruker etterspør dette. I en løsning
hvor det legges support funksjoner i kommunikasjonshuben kan de gjøre noen av disse
oppgavene.
Teknisk robust løsning
Løsningen er avhengig av at alle nettselskap gjør tilgjengelig ferdige
avregningsunderlag til kraftleverandørene gjennom en standardisert kommunikasjonshub.
I forhold til en datahub løsning med krav til 24/7 drift og backup løsninger, vil en
løsning med kommunikasjonshub være mer sårbar for feil og oppetid.
Dersom en kraftleverandør skal yte god kundeservice er kraftleverandøren avhengig av
en teknisk robust løsning hos alle nettselskaper slik at kraftleverandøren har god tilgang
til nødvendige data 24/7 (historiske data og avregningsdata). Nettselskapene må da ha
funksjonalitet så kraftleverandørene kan hente (pull) data fra nettselskapene for å
håndtere kundespørsmål angående volumer. Dette må utvikles hos alle nettselskap.
Implementering
Løsningen vil kreve mindre endringer enn i en datahub modell, og kan dermed raskere
bli implementert:
Dagens avregningsløsning hos nettselskapene kan benyttes (hvis de har kapasitet
til å håndtere en større mengde data pga. timesvolumer)
Nettselskapene må ha nye systemer i forbindelse med kravene i AMS
Mindre tilpasninger hos kraftleverandøren for å inkludere nett-tariff på fakturaen
5.4.5.6 Totalfakturering i en datahub-modell
Beskrivelsen for modellen er basert på at nettselskapene utarbeider avregningsunderlag
for nett-tariffen og sender dette til datahuben 7 . Kraftleverandørene kan da hente det
ferdige avregningsunderlaget hos datahuben. en lagrer historiske avregningsunderlag
slik at kraftleverandør kan hente historiske data relatert til nettavregningen.
En fremtidig opsjon er at en datahub ferdigstiller avregningsunderlaget for nett-tariff, og
gjør dette tilgjengelig for kraftleverandøren.
Begge løsningene er beskrevet i det følgende.
5.4.5.6.1 Totalfakturering i en datahub-modell hvor nettselskapene utarbeider
avregningsunderlag for nett-tariff
I modellen vil det være en sentral database hvor avregningsunderlag kan lagres, og hvor
kraftleverandørene får tilgang til avregningsunderlag. Kraftleverandørene har ett
kontaktpunkt å forholde seg til for tilgang til avregningsunderlaget.
7 I konsulentrapporten som ligger til grunn for NordREGs anbefaling av totalfakturering legges anbefales det også
etablering av sentral datahub. Consideration of alternative billing regimes for the common Nordic end-user market,
VaasaETT Oy, 16th May 2011
52

I denne modellen blir avregningsunderlag laget av nettselskapene. Nettselskapet henter
gjeldende målerdata fra datahuben (datahuben er autoritativ kilde for målerdata 8 ) og
utarbeider ferdig avregningsunderlag til kraftleverandøren. Dette underlaget inkluderer
da nett-tariff og eventuelle avgifter. Ferdig avregningsunderlag sendes til datahuben
som gjør avregningsunderlaget tilgjengelig for kraftleverandøren som sammenstiller
dette med avregningsunderlag for kraft og gjennomfører fakturering og innfordring.
Nettselskapet fakturerer kraftleverandøren for den totale nett-tariffen for
kraftleverandørens sluttbrukere i nettområdet.
Denne løsningsmodellen er vist i figuren under.
Datahub
Faktureringsprosessen
Nettselskap
Kraftleverandør
Sluttbruker
Innsamling
forbruksdata
Målerdata
Avregningsunderlag
Avregningsunderlag
Avregning
Fakturering
Faktura total nettleie
Betaling
Faktura
Innfordring
Betaling
Figur 19 - Totalfakturering i en datahub-modell hvor nettselskapene utarbeider avregningsunderlag for
nett-tariff
8 Dersom nettselskapet benytter data fra egen database kan det oppstå situasjoner hvor avregningsunderlaget for netttariff
avviker fra målepunkt data benyttet for avregning av kraft.
53

5.4.5.6.2 Avregningsunderlag for sluttbrukeravregning i en datahub-modell
Figur 20 - Sekvensdiagram for avregningsunderlag for sluttbrukeravregning i en datahub-modell
Ved å plassere Måleverdiansvarlig (en rolle ansvarlig for å etablere og validere
måledata fra måledatainnsamler, samt ansvarlig for historiske verdier for målepunktene)
i en datahub vil det være enkelt å åpne for bytte Måleverdiansvarlig.
5.4.5.6.3 Vurdering av løsningen
Samfunnsøkonomi
Nettselskapene vil, som et resultat av totalfaktureringsmodellen, ikke lenger trenge å
fakturere og foreta innfordring av sine sluttbrukere, da dette vil bli gjort av
kraftleverandørene.
Nettselskapet vil fakturere kraftleverandørene for den totale nett-tariffen, dette vil
utgjøre et mindre antall fakturaer.
Kraftleverandørene må kunne motta ferdig avregningsunderlag for nett-tariff pr.
målepunkt, og inkludere denne i sitt faktureringssystem. Det antas at kostnaden ved
tilpasning av en slik løsning ikke er stor.
Datahuben vil ha gode rutiner for kvalitetsjekking av underlagsdata, og kraftleverandørene
vil dermed kunne frigjøre ressurser for kvalitetsjekking av avregningsunderlaget
for nett-tariff og avgifter.
Kraftleverandøren vil ha et kontaktpunkt for å hente ut avregningsunderlag, i forhold til
en modell med kommunikasjonshub hvor kraftleverandørene er avhengig av hvert
enkelt nettselskap for å få avregningsunderlag. Dette vil lette kraftleverandørenes
hverdag og effektivitet.
Nettselskapene trenger ikke å ha en spørreløsning hvor kraftleverandørene har mulighet
til å hente ut historiske avregningsunderlag.
54

Støtter ny markedsmodell
Løsningen krever at nettselskapene vet hvilken kraftleverandør som leverer til hvert
målepunkt. Modellen sikrer derfor i mindre grad et skille mellom nett og
kraftleverandør enn modellen hvor datahuben utarbeider dette avregningsunderlaget.
Teknisk robust løsning
Avregningsunderlaget blir lagret sentralt hos en aktør med store krav til oppetid, kvalitet
og backup løsninger. Dette vil gi kraftleverandørene mulighet til å yte god kundeservice
ved rask tilgang til nødvendige data i forbindelse med fakturering og spørsmål om
historiske avregningsunderlag for nett-tariff.
Implementering
Etablering av en sentral datahub med funksjonalitet for å ta i mot og gjøre tilgjengelig
avregningsunderlag vil kreve et større prosjekt og en lengre implementeringstid enn i en
løsning med kommunikasjonshub.
5.4.5.6.4 Totalfakturering i en datahub-modell hvor datahub utarbeider
avregningsunderlag for nett-tariff (mulig fremtidig opsjon)
I en datahub-modell vil det være en sentral database hvor avregningsunderlag kan
lagres, og hvor kraftleverandørene får tilgang til avregningsunderlag.
Kraftleverandørene har ett kontaktpunkt å forholde seg til for tilgang til
avregningsunderlaget.
I denne modell blir avregningsunderlag laget av datahuben. Datahuben mottar tariff
strukturen fra hvert enkelt nettselskap pr målepunkt (eventuell endring i tariffstruktur
må sendes til datahuben fra nettselskapene). Datahuben benytter måleverdier som er
lagret sentralt til å utarbeide ferdig avregningsunderlag til kraftleverandøren. Dette
underlaget inkluderer da nett-tariff og eventuelle avgifter. Ferdig avregningsunderlag
gjøres tilgjengelig for kraftleverandøren som sammenstiller dette med
avregningsunderlag for kraft og gjennomfører fakturering og innfordring.
Avregningsunderlaget gjøres tilgjengelig for nettselskapet som fakturerer
kraftleverandøren for den totale nett-tariffen for kraftleverandørens sluttbrukere.
Avregningsunderlaget til nettselskapene kan aggregeres pr. kraftleverandør av
datahuben slik at nettselskapet ikke får tilgang til hvem som er kraftleverandør på hvert
målepunkt. Nettselskapet mottar betaling fra kraftleverandøren en gang i måneden (ikke
knyttet til kalendermåneder).
Denne løsningsmodellen er vist i figuren under.
55

Datahub
Faktureringsprosessen
Nettselskap
Kraftleverandør
Sluttbruker
Innsamling
forbruksdata
Målerdata
Tariffstruktur
Avregningsunderlag
Avregning
Avregningsunderlag
Fakturering
Faktura total nettleie
Betaling
Faktura
Innfordring
Betaling
Figur 21 - Totalfakturering i en datahub-modell hvor datahub utarbeider avregningsunderlag for netttariff
(mulig fremtidig opsjon)
Dersom avregningsunderlaget for nett-tariff og avgifter gjøres sentralt av datahuben
sikres en enhetlig beregning av avgifter for alle sluttbrukere. Det gjør det også lettere
ved endringer da dette kun skal gjøres et sted i motsetning til hos alle nettselskaper.
I dag eksisterer det forskjellige tariffstrukturer som nettselskapene benytter. De fleste
nett-tariffer er bygget opp med følgende elementer:
Ett fastledd og ett energivariabelt ledd
Fastleddet er for det meste ett årlig beløp fordelt på hver faktura. Noen
har fastledd avhengig av ampere
Det kan skilles mellom kundetyper; husholdning, hytter, ulike næringer
(for eksempel drivhus osv.)
Noen har ulike tariffer mellom vinter og vår
Ved avregningen av nett-tariff bør det således være en funksjonalitet slik at hvert
målepunkt er angitt med tariffkode som angir hvilken tariff som gjelder basert på
standard parametere som tar hensyn til forskjellige strukturer for nett-tariff. Dette må
vedlikeholdes av nettselskapet.
I løsningen hvor datahuben utarbeider avregningsunderlag for nett-tariff er det en
forutsetning av nett-tariff elementene standardiseres i Norge. Stordriftsfordelen ved å
benytte en hub for beregning av avregningsgrunnlaget for nett-tariff reduseres dersom
det finnes mange med forskjellige nett-tariffer og nett parametere som benyttes. Vi
forslår at strukturen til nett-tariffer i distribusjonsleddet standardiseres til ett håndterbar
sett av parametere begrenset til:
Type sluttbruker
o Husholdning
o Hytter
o Næringskoder
Energiledd i form av pris per energimengde
Effektledd i form av månedlig totalbeløp
Eventuelt fastledd
56

Løsningen hvor en datahub utarbeider avregningsunderlaget for nett-tariff anses som en
betydelig endring av dagens modell og rollefordelingen i bransjen. Det anbefales at
denne løsningen tas med som en opsjon i en eventuell datahub, og at beslutning om
bruk av denne funksjonaliteten i datahuben tas på et senere tidspunkt.
Figur 22 - Sekvensdiagram for datautveksling for avregningsunderlag for sluttbrukeravregning med
opsjon der datahuben avregner kraft og nett-tilknytning i en datahub-modell
5.4.5.6.5 Vurdering av løsningen
Samfunnsøkonomi
En datahub-modell hvor datahuben utarbeider ferdig avregningsunderlag vil gi stordrift
og dermed være en effektiv modell. Det vil sannsynligvis være billigere å gjøre
avregningen sentralt fremfor at alle nettselskapene gjør dette selv.
Nettselskapene vil motta ferdig grunnlag fra datahub for fakturering av
kraftleverandørene.
Nettselskapet vil fakturere kraftleverandørene for den totale nett-tariffen, dette vil
utgjøre et mindre antall fakturaer.
Nettselskapene vil, som et resultat av totalfaktureringsmodellen, ikke lenger trenge å
fakturere og foreta innfordring av sine sluttbrukere, da dette vil bli gjort av
kraftleverandørene.
Nettselskapene trenger ikke å etablere en spørre-løsning hvor kraftleverandørene kan
hente ut historiske avregningsunderlag.
Kraftleverandørene må kunne motta ferdig avregningsunderlag for nett-tariff pr.
målepunkt, og inkludere denne i sitt faktureringssystem. Det antas at kostnaden ved
tilpasning av en slik løsning ikke er stor.
Datahuben vil ha gode rutiner for kvalitetsjekking av underlagsdata, og
kraftleverandørene vil dermed kunne frigjøre ressurser for kvalitetsjekking av
avregningsunderlaget for nett-tariff og avgifter.
Datahuben vil også kunne følge opp manglende innrapporteringer fra nettselskapene.
Dette vil frigjøre tidsbruk og ressurser hos kraftleverandørene.
57

Støtter ny markedsmodell
En datahub-modell for fakturering vil muliggjøre totalfakturering av kraft, nettleie og
avgifter.
En datahub-modell vil sikre nøytralitet i markedet ved at alle avregningsgrunnlag
sendes til den sentrale databasen hvor kraftleverandører har tilgang til sitt
avregningsgrunnlag. Løsningen vil innebære at all fakturering av nett-tariff blir
gjennomført på samme måte. Vertikalintegrerte selskaper vil dermed ikke ha en
konkurransefordel som de kan ha i en kommunikasjonshub modell hvor det kan være
forskjellsbehandling av kraftleverandørene.
En datahub vil sikre at alle kraftleverandører får lik tilgang til avregningsunderlag på et
standardisert format. Dette vil sikre lik håndtering av alle kraftleverandører og støtte et
marked med like konkurransevilkår.
Leverandørenes grensesnitt mot nettselskapene reduseres til forretningsforholdet i
forbindelse med nettselskapenes fakturering av den totale nett-tariffen for
kraftleverandørens sluttbrukere i det spesifikke nettområdet (engros-modellen).
Teknisk robust løsning
Avregningsunderlaget blir utarbeidet og lagret sentralt hos en aktør med store krav til
oppetid, kvalitet og backup løsninger. Dette vil gi kraftleverandørene mulighet til å yte
god kundeservice ved rask tilgang til nødvendige data i forbindelse med fakturering og
spørsmål om historiske avregningsunderlag for nett-tariff.
Implementering
Etablering av en datahub med funksjonalitet for å utarbeide avregningsunderlag vil
kreve et større utviklingsprosjekt med betydelig implementeringstid.
5.5 Administrasjon av sluttbrukeren
5.5.1 Finn målepunkt-id
Prosessen «Finn målepunkt ID» er i dagens modell løst gjennom NUBIX. Det forventes
at prosessen beskrevet under har tilsvarende funksjonalitet som dagens NUBIX løsning.
Generelle forutsetninger for prosessen «Finn målepunkt ID» etter innføring av AMS:
Nettselskap er ansvarlig for anleggsadresse
Kraftleverandør er ansvarlig for kundeinformasjon
Kraftleverandøren beskrevet i prosessen er den nye kraftleverandøren
For å hindre unødvendige avvisninger/feil er det viktig at sjekk på målepunkt ID
kjøres mot samme database som skal godkjenne leverandørskifte.
Når ny kraftleverandør spør om målepunkt ID må to av karakteristikkene under
være med i forespørselen:
o Målepunkt ID
o Fødselsdato/organisasjonsnummer
o Sluttbruker navn
o Anleggsadresse
58

o Målernummer
5.5.1.1 Datautveksling for å finne målepunkt ID i en kommunikasjonshub-modell
Figur 23 - Sekvensdiagram for å finne målepunkt ID i en kommunikasjonshub-modell
Forutsetninger for «Finn målepunkt ID» i en kommunikasjonshub-modell:
Kommunikasjonshuben har ikke et fullt utbygget målepunktregister.
5.5.1.2 Datautveksling for å finne målepunkt ID i en datahub-modell
Figur 24 - Sekvensdiagram for å finne målepunkt ID i en datahub-modell
Forutsetninger for «Finn målepunkt ID» i en datahub-modell:
Kraftleverandør sender meldingen «Finn målepunkt ID» til en datahub (i rollen
som målepunktadministrator) som håndterer prosessen. Nettselskapet vil ikke ha
noen rolle i prosessen
Datahuben har anleggsdata fr alle målepunkter
59

5.5.2 Leverandørskifte
Ved et leverandørskifte sender ny kraftleverandør «Melding om leveringsstart» til
målepunktadministrator (i dag nettselskapet). Målepunktadministrator kontrollerer
mottatt «Melding om leveringsstart», bekrefter leverandørskiftet til ny kraftleverandør
ved å sende «Bekreftelse på leveringsstart» og informerer gammel kraftleverandør om
leverandørskiftet ved å sende «Melding om opphø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 til avvisning er
løst. Inntil full implementering av AMS er gjennomført må prosessen omfatte
underprosessen «Skaff målerstand» for profilavregnede målepunkter.
Dersom sluttbruker bruker angreretten, må prosessen inneholde en mulighet for å
kansellere leverandørskiftet. Dette gjøres ved at ny kraftleverandør sender
«Kansellering av Melding om leveringsstart» som kan sendes inntil en virkedag før dato
for leverandørskifte. Meldingen vil være tilsvarende «Melding om leveringsstart», men
med informasjon om at dette er en kanselleringsmelding.
Sluttbruker har en rolle i prosessen (starter prosessen ved å tegne kontrakt med ny
kraftleverandør) men er ikke tatt med i de videre diagrammene.
I 2011 ble det foretatt ca 200.000 leverandørskifter i Norge 9 .
Generelle forutsetninger for leverandørskifte etter innføring av AMS:
Nettselskapet er autorativ kilde for informasjon som er knyttet til det fysiske
målepunktet, som målepunkt ID og anleggsadresse.
Kraftleverandør er autorativ kilde på kundedata. Det vil si all informasjon som
kunden er ansvarlig for, som organisasjonsnummer eller fødselsdato, sluttbruker,
fakturaadresse, telefon, epost osv.
Ved leverandørskifte sender kraftleverandør kun dato for leverandørskifte og
målepunkt ID. Kontroll på at det er riktig målepunkt må håndteres av
kraftleverandør. Det vil si å kontrollere at organisasjonsnummer eller
fødselsdato, samt sluttbruker navn stemmer.
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 og gammel kraftleverandør. Disse prosessene vil
imidlertid forsvinne i forbindelse med innføring av AMS.
9 Kilde: «Hovedtall fra NVEs leverandørskrifteundersøkelse 3. kvartal 2011» fra NVE, se
http://www.nve.no/PageFiles/812/Leverand%c3%b8rskifter_hovedtall%203%20kv%202011.pdf?epslanguage=no
60

5.5.2.1 Datautveksling for leverandørskifte i en kommunikasjonshub-modell
Figur 25 - Sekvensdiagram for leverandørskifte i en kommunikasjonshub-modell
Forutsetninger for leverandørskifte i en kommunikasjonshub-modell:
Leverandørskifteprosessen foregår mellom kraftleverandør og nettselskap via en
kommunikasjonshub
Alle grunnlagsdata (som er nødvendig for å håndtere et leverandørskifte) ligger i
databasen til henholdsvis kraftleverandør og nettselskap
Nettselskapene må til enhver tid ha oppdaterte anleggsdata og måledata
Prosessen vil i tillegg omfatte:
o Kontakt mellom sluttbruker og kraftleverandør for å inngå en
kraftleveransekontrakt
o Kraftleverandør må finne målepunkt ID
I en kommunikasjonshub-modell vil kraftleverandør sende «Melding om leveringsstart
(leverandørskifte)», i prinsippet kun med dato og målepunkt ID, via en kommunikasjonshub
til nettselskapet (i rollen som målepunktadministrator) som håndterer leverandørskiftet.
61

5.5.2.2 Datautveksling for leverandørskifte i en datahub-modell
Figur 26 - Sekvensdiagram for leverandørskifte i en datahub-modell
Forutsetninger for leverandørskifte i en datahub-modell:
Leverandørskifteprosessen foregår mellom kraftleverandør og datahub.
Nettselskapet har ingen rolle i leverandørskifteprosessen, utover at nettselskapet
trenger informasjon om ny kraftleverandør i forbindelse med fakturering av
nettleie og kundeinformasjon for varsling av driftsutfall i nett eller lignende
Datahuben er autorativ kilde til grunnlagsdata (som er nødvendig for å håndtere
et leverandørskifte)
Nettselskapene må til enhver tid ha oppdaterte anleggsdata og måledata i huben
Prosessen vil i tillegg omfatte:
o Kontakt mellom sluttbruker og kraftleverandør for å inngå en
kraftleveransekontrakt
o Kraftleverandør må finne målepunkt ID
I en datahub-modell vil kraftleverandør sende «Melding om leveringsstart (leverandørskifte)»,
i prinsippet kun med dato og målepunkt ID, til en datahub (i rollen som
målepunktadministrator) som håndterer leverandørskiftet.
5.5.2.3 Forskjeller: Leverandørskifte i kommunikasjons- og datahub-modell
I en datahub-modell vil leverandørskifteprosessen i hovedsak flyttes fra nettselskapene
til datahuben:
Kraftleverandørene forholder seg til en datahub istedenfor ca 130 nettselskap,
noe som vil forenkle oppfølging ved avvik
Nettselskapene vil slippe datautveksling til/fra ny og gammel kraftleverandør,
og kun motta informasjon om ny kraftleverandør til bruk ved fakturering
62

5.5.3 Innflytting (anleggsovertakelse)
Prosessen for innflytting benyttes ved oppstart på et anlegg som en sluttbruker overtar.
Det kan for eksempel være ved flytting, overtakelse av fritidsbolig eller når en bedrift
overtar nye lokaler. Felles for disse situasjonene er en endring i den som står som
ansvarlig på målepunktet. Det er beskrevet en kundesentrisk tilnærming til
flytteprosessen. En innflytting trigger både en utflytting på gammelt målepunkt og
innflytting på nytt.
Prosessen for innflytting minner mye om prosessen for leverandørskifte. Forskjellen fra
et leverandørskifte er at navn, anleggsadresse og eventuell fakturaadresse inkluderes i
«Melding om leveringsstart».
Sluttbruker har en rolle i prosessen (starter prosessen ved å tegne kontrakt med ny
kraftleverandør) men er ikke tatt med i etterfølgende beskrivelsene.
Det foretas ca. 375.000 flyttinger per år i Norge 10 .
Generelle forutsetninger for innflytting etter innføring av AMS:
Nettselskapet blir involvert i prosessen fordi nettselskapet trenger informasjon
om den nye sluttbrukeren på anlegget
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 og gammel kraftleverandør. Disse
prosessene vil imidlertid forsvinne i forbindelse med innføring av AMS
Nettselskapet må kontrollere målepunkt ID ved mottak av «Melding om
leveringsstart»
Forslag til nytt regelverk etter innføring av AMS:
Etter innføring av AMS er det ikke lenger anledning til å foreta
anleggsovertagelse (innflytting) tilbake i tid
5.5.3.1 Datautveksling for innflytting i en kommunikasjonshub-modell
Forutsetninger for innflytting i en kommunikasjonshub-modell:
Nettselskapet må vite hvem som er kraftleverandør i en
kommunikasjonshub-modell, for å kunne håndtere utflytting (oppsigelse)
uten ny sluttbruker på anlegget
Kraftleverandørene forholder seg til kommunikasjonshub
Med en kommunikasjonshub bør det være mulig å foreta innflytting i
«realtime»
Antall meldinger vil i kommunikasjonshub-modell være lik dagens modell
10 Kilde: NordREGs recommendation on the future model for billing customers in the harmonised Nordic end-user
market, December 19 th 2011
63

Figur 27 - Sekvensdiagram for innflytting i en kommunikasjonshub-modell
I figuren vises meldingsflyt mellom kraftleverandør og nettselskap. I det virkelige liv vil
prosessen i tillegg omfatte:
Kontakt mellom sluttbruker og kraftleverandør for å inngå en kraftleveransekontrakt
Kraftleverandør må finne målepunkt ID og eventuelt nettselskap. I en kommunikasjonshub-modell,
som i dagens modell, må kraftleverandør sende melding til
riktig nettselskap
I en kommunikasjonshub-modell trigger hver innflytting 2 meldinger fra
nettselskapene:
o «Melding om bekreftelse på leveringsstart» til ny kraftleverandør
o «Melding om opphør» til gammel kraftleverandør
64

5.5.3.2 Datautveksling for innflytting i en datahub-modell
Figur 28 - Sekvensdiagram for innflytting i en datahub-modell
I en datahub-modell vil kraftleverandør sende «Melding om leveringsstart
(innflytting)», med målepunkt ID, dato og informasjon om ny sluttbruker, til en datahub
(i rollen som målepunktadministrator), som håndterer innflyttingen. Datahuben vil ha
oversikt over all målepunkter i alle nettområder, uavhengig av nettselskap.
Siden det kommer en ny sluttbruker i målepunktet trenger nettselskapet informasjon om
blant annet navn på sluttbruker. Denne informasjonen vil videresendes til nettselskapet
fra datahuben. Dette er imidlertid en langt enklere prosess enn dagens prosess for
anleggsovertakelse.
Forutsetninger for innflytting i en datahub-modell:
Kraftleverandørene forholder seg til en datahub
Totalt vil antall meldinger øke. Kraftleverandørene får tilsvarende datautveksling
som i dag. Datahuben vil overta ansvaret for meldingene nettselskapet
hadde tidligere, både mot ny og gammel kraftleverandør. I tillegg kommer det
en ny datautveksling mellom datahub og nettselskap, med informasjon om ny
sluttbruker og eventuelt ny kraftleverandør
Nettselskapene slipper med en informasjonsmelding fra den sentrale datahuben,
med informasjon om den nye sluttbrukeren i målepunktet
I en datahub-modell er det datahuben som håndterer informasjon til ny og
gammel kraftleverandør
Med en datahub bør det være mulig å foreta innflytting i «realtime»
5.5.3.3 Oppstart av nytt anlegg
For nye målepunkter (nye anlegg) forutsettes en leverandørsentrisk modell.
Nettselskapet har kontakt med sluttbruker i forbindelse med installasjonen av anlegget,
men det åpnes først for strøm når sluttbruker har valgt en kraftleverandør eller er blitt
tildelt en anvisningsleverandør.
65

Prosessen er lik prosessen for innflytting, bortsett fra at den ikke trigger et opphør for
sluttbruker som flytter ut.
Nettselskapet er ansvarlig for å installere, teste og klargjøre anlegget. Nettselskapet må
opprette målepunkt-id og sette status for anlegget.
5.5.4 Utflytting
Denne prosessen heter i dag «Opphør av kraftleveranse og overføring av kraft».
Prosessen benyttes når sluttbruker tar kontakt med kraftleverandør og melder utflytting.
Kraftleverandøren sender «Melding om utflytting» til målepunktadministrator. Dersom
meldingen kan aksepteres returnerer målepunktadministrator «Bekreftelse på
utflytting». Bekreftelsen kan være negativ (avvising av utflytting) dersom «Melding om
utflytting» ikke er i henhold til forretningsregler eller forskrifter.
Generelle forutsetninger for utflytting etter innføring av AMS:
Utflytting kan ikke skje tilbake i tid
Dagens prosess for å skaffe til veie skiftestand for profilavregnede målepunkter
vil forsvinne i forbindelse med innføring av AMS
Siden det forutsettes en leverandørsentrisk markedsmodell, forutsettes det at det
vil være nødvendig med en overføring av kraftleveransen til en leveringspliktog/eller
anvisningsleverandør
5.5.4.1 Datautveksling for utflytting i en kommunikasjonshub-modell
Figur 29 - Sekvensdiagram for utflytting i en kommunikasjonshub-modell
Forutsetninger for utflytting ved en kommunikasjonshub-modell:
«Bekreftelse eller avvising av melding om opphør» skal i dag sendes senest 2
virkedager etter mottak av «Opphør av kraftleveranse og overføring av kraft» fra
kraftleverandør. Ved innføring av en kommunikasjonshub antas det at dagens
tidsfrist opprettholdes.
66

5.5.4.2 Datautveksling for utflytting i en datahub-modell
Figur 30 - Sekvensdiagram for utflytting i en datahub-modell
Forutsetninger for leverandørskifte ved en datahub-modell:
«Bekreftelse eller avvising av melding om opphør» skal i dag sendes senest 2
virkedager etter mottak av «Opphør av kraftleveranse og overføring av kraft» fra
kraftleverandør. Ved innføring av en datahub kan dette gjøre i «realtime»
5.5.5 Oppsigelse (opphør)
Denne prosessen benyttes når kraftleverandør stopper kraftleveransen til et målepunkt.
Årsaker til kontraktsopphør fra sluttbruker/kraftleverandør kan for eksempel være
konkurs, dødsbo, dårlig betaler, utløp av kontrakt, osv. Det vil være ulik prosedyrer hos
nettselskapene, alt etter årsak.
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 og gammel kraftleverandør. Disse prosessene vil imidlertid forsvinne i
forbindelse med innføring av AMS.
I dagens modell vil opphør av kraftleveranse fra kraftleverandør medfører at sluttbruker
havner på leveringsplikt. Siden det skal legges til rette for en mer leverandørsentrisk
markedsmodell, forutsettes det at det vil være nødvendig med en overføring av
kraftleveransen til en leveringsplikt- og/eller anvisningsleverandør, se også 5.5.8,
Leveringsplikt.
5.5.5.1 Datautveksling for opphør av kraftleveranse i en kommunikasjonshub-modell
Sekvensdiagrammet under viser meldingsgangen ved opphør av kraftleveranse i en
kommunikasjonshub-modell. Kraftleverandøren sender «Opphør av kraftleveranse» til
målepunktadministrator (nettselskapet). Dersom meldingen kan aksepteres returnerer
målepunktadministrator «Bekreftelse på melding om opphør». «Bekreftelse på melding
67

om opphør» kan være negativ («Avvising av melding om opphør») dersom meldingen
ikke er i henhold til forretningsregler eller forskrifter.
Figur 31 - Sekvensdiagram for opphør av kraftleveranse i en kommunikasjonshub-modell
Forutsetninger for opphør av kraftleveranse i en kommunikasjonshub-modell:
«Bekreftelse eller avvising av melding om opphør» skal i dag sendes senest 2
virkedager etter mottak av «Opphør av kraftleveranse og overføring av kraft» fra
kraftleverandør. Ved innføring av en kommunikasjonshub antas det at dagens
tidsfrist opprettholdes.
5.5.5.1.1 Datautveksling for opphør av kraftleveranse i en datahub-modell
Figur 32 - Sekvensdiagram for opphør av kraftleveranse i en datahub-modell
68

Sekvensdiagrammet under viser meldingsgangen ved opphør av kraftleveranse i en
datahub-modell. Kraftleverandøren sender «Opphør av kraftleveranse» til
målepunktadministrator (datahub). Dersom meldingen kan aksepteres returnerer
målepunktadministrator «Bekreftelse på melding om opphør». «Bekreftelse på melding
om opphør» kan være negativ («Avvising av melding om opphør») dersom meldingen
ikke er i henhold til forretningsregler eller forskrifter.
Dersom opphør av kraftleveranse aksepteres sender datahuben melding til leveringsplikt-
og/eller anvisningsleverandør som overtar kraftleveransen til målepunktet.
Forutsetninger for opphør av kraftleveranse i en datahub-modell:
«Bekreftelse eller avvising av melding om opphør» skal i dag sendes senest 2
virkedager etter mottak av «Opphør av kraftleveranse og overføring av kraft» fra
kraftleverandør. Ved innføring av en datahub kan dette gjøre i «realtime»
5.5.6 Struping og stenging
Dette er en ny prosess som foreslås innført i forbindelse med innføring av AMS og en
mer rendyrket leverandørsentrisk modell for det norske kraftmarkedet. Det forutsettes at
det kun er nettselskapet som skal ha direkte/fysisk tilgang til stenging/struping, men at
kraftleverandørene skal kunne sende en forespørsel om stenging til nettselskapet ved
manglende betaling. I en slik situasjon vil ikke nettselskapene ha noe forhold til
grunnlaget for stengingen. Slike meldinger bør derfor gå via supportfunksjonen i en
datahub eller kommunikasjonshub som kan sikre høy grad av sikkerhet knyttet til
tilgang og autorisasjon. Prosess for «Stengning/struping» må beskrives i detalj i
forbindelse med detaljering av ny markedsmodell. En må ha klare regler og
ansvarsdeling ved stenging/struping og en må derfor blant annet få avklart:
Hvem har det juridiske ansvaret for stengingen (den som stenger eller den som
sendte melding om stenging)?
Bør det være ”tidsfrister” for stengeprosessen, slik at en i større grad unngå at en
stenger anlegg der kunden har betalt i mellomtiden?
Hvilke regler og prosedyrer må kraftleverandørene følge før de kan bruke
stenging?
Skal en benytte stenging eller struping når en ”stenger” en kunde som er dårlig
betaler?
Skal kraftleverandøren betale nettselskapet for å stenge?
Det er viktig å skille på opphør av anlegg og stenging/struping, for eksempel pga.
manglende betaling.
Det er ikke uproblematisk å stenge selv med AMS. For det første må det være
prosedyrer som dokumenterer eskalering og kundekontakt. For det andre må det sikres
mot brann og skader ved åpning, dvs. at sluttbrukeren er bevisst at det åpnes og at det
ikke står påskrudd apparatur som ikke skal være påskrudd.
69

5.5.7 Mikroproduksjon
Innmating fra mikroproduksjon er en ny forretningsprosess som anbefales innført. Det
foreslås at kraftleverandørene kan inngå avtale med sluttbrukere som har innmating fra
mikroproduksjon, som solsellepaneler, i nettet. Alternativt kan det defineres en ny rolle
for aktører som håndterer mikroproduksjon mot sluttbrukere. Kraftleverandør med
innmatingsavtale må, på lik linje som ved salg av strøm, ha en avtale med en
balanseansvarlig som håndterer innmatingen i engrosmarkedet (mot balanseavregningen).
Nettselskapet samler inn og oversender innmating til kraftleverandør med
innmatingsavtale. Nettselskapene kan ha en egen nett-tariff for innmating. Nettselskapene
kan minske nett-tapet pga. «kortreist strøm» og forbedret systemdrift/ nettanalyse.
Prosessen er ikke beskrevet med egne sekvensdiagrammer, siden datautvekslingen vil
bli en del av de andre prosessene som er beskrevet, med følgende forutsetninger:
Det opprettes egne målepunkt ID’er for innmating og forbruk.
Det må innføres et nytt dataelement i grunnlagsdata for målepunkt;
Målepunkttype, med informasjon om det er et produksjons- eller forbruksmålepunkt.
Tilsvarende må Målepunkttype innføres som attributt i melding med måledata
for sluttbrukeravregning.
NVEs retningslinjer for plusskunder må koordineres med en slik modell og det bør
vurderes å lempe på kravet for å bli definert som plusskunde.
5.5.8 Leveringsplikt
Dersom det skal legges til rette for innføring av en leverandørsentrisk modell er det
naturlig å vurdere dagens ordning der nettselskapene har leveringsplikt. Dersom
nettselskapene i en slik modell ikke skal forholde seg til enkeltkunder vil det ikke gi
mening at de skal måtte ha systemer og rutiner for kun å håndtere kunder på
leveringsplikt. Alternativet til dagens ordning er å innføre leveringspliktleverandører
og/eller anvisningsleverandører. En leveringspliktleverandør er en kraftleverandør som
leverer kraft til sluttbrukere som ingen andre kraftleverandører vil ha, mens en
anvisningsleverandør er en kraftleverandør som leverer til sluttbrukere som ikke har
valgt kraftleverandør. Anvisningsleverandør og leveringspliktleverandør kan for
eksempel utpekes på bakgrunn av anbudsrunder, eller være den dominerende
kraftleverandør i nettområdet. Anbudsrunder eller vurderinger av hvem som er
dominerende kraftleverandør i nettområdet kan gjerne kjøres ved gitte tidsintervall, for
eksempel hvert tredje år. Rollene kan kombineres.
Generelle forutsetninger ved innføring av leveringsplikt- og/eller anvisningsleverandør:
Rollene leveringsplikt- og/eller anvisningsleverandør innføres
Anvisningsleverandør eller leveringspliktleverandør tar over ved oppsigelse av
kraftleveransen pga. dårlig betalingsevne hos sluttbruker
Dersom tidligere sluttbruker melder utflytting og det ikke finnes informasjon om
ny sluttbruker kan anlegget strupes etter et antall dager, for eksempel 5 dager.
Det viktigste er å ha en felles regel
70

5.6 AMS tilleggstjenester
AMS tilleggstjenester er et uklart begrep med uklart innhold. I tillegg har tjenestene så
langt vært diskutert og vurdert ut i fra at en må forholde seg til nettselskapene både for
tilgang til målerverdier og kommunikasjon via nettselskapenes kommunikasjonskanal.
Effektiv distribusjon av prisinfo til sluttbruker via AMS (M2) er en av flere
tilleggstjenester, som er spesielt nevnt i forskriften.
Med AMS får nettselskapene mer informasjon og flere muligheter i forhold til drift av
nettet, som informasjon om brudd, jordfeil, utkobling ved vedlikehold, overvåkning,
lastutkobling, m.m.. Dette er først og fremst funksjonalitet for nettselskapets egen
nettdrift, og har dermed ikke hovedfokus i ESK sammenhengen. Samtidig er det viktig å
være klar over at det er potensielt store synergier i bruken av de ulike løsningene for de
ulike interessegruppene; sluttbruker, nettselskapet, kraftaktøren og balanseansvarlig
Rapporten fokuserer på tjenester som involverer flere parter enn nettselskap og
sluttbruker, typisk tjenester som skal være gjenstand for konkurranse. Dette kan tenkes
å være:
Hel eller delvis utkobling av last mot kompensasjon
Forbruksstyring kontrollert av sluttbrukeren
Forbruks- og prisinformasjon via flere kanaler som display/ mobil-applikasjon/
web
Effektiv konkurranse om energieffektiviseringstjenester
Nye innovative tjenester som valgt løsning vil gjøre mulig
o Som for eksempel en iPhone/Android App som gir råd om hvilken
kraftleverandør som gir deg best pris på ditt forbruk
Teknologien har endret seg betydelig siden diskusjonen rundt tilleggstjenester startet.
Da var en helt avhengig av å få på plass kommunikasjonskanaler for å tilrettelegge for
tjenestene. I 2014+ vil vi høyst sannsynlig se på digital kommunikasjon som ikke støtter
internett som et hinder for innovative løsninger for kontroll og styring i
sluttbrukermarkedet. Allerede i dag kan vi kontrollere ovner, lys, ta opp TV
programmer osv., fra hvor som helst i verden, via utstyr som er billig og lett tilgjengelig
(Clas Ohlson, tjenesteleverandører osv.), og som kobler seg opp på lokalnettet mer eller
mindre automatisk.
Å etablere en infrastruktur hvor flere enheter som kommuniserer direkte med måler kan
reise en del sikkerhetsmessige utfordringer. Dermed er det viktig å skille tilgang til
måledata og statusinformasjon fra muligheten for styring og kontroll av nettselskapets
utstyr.
For å få tilgang til måleren og målerverdier i sann tid, samt energistyring, må måleren
tilgjengeliggjøres gjennom en kommunikasjonsenhet/AMS-Gateway som er
standardisert (WiFi, ZigBee, eller lignende.). Sluttbrukerne bør dermed kunne kjøpe/få
en enhet som de selv kan koble til sitt lokalnett og som kommuniserer med måler
gjennom gatewayen. På denne måten vil en raskt og kostnadseffektivt kunne sikre at
alle som ønsker kan få tilgang til sine data for lokal styring og oversikt. Styringen skjer
via sluttbrukerens utstyr og sluttbrukerens nettverk, og ikke via nettselskapets utstyr.
Dermed reduseres behovet for sikring mot misbruk betydelig.
Et eventuelt display på kjøkkenet vil da kunne kommunisere med måleren via
lokalnettet. Mange vil foretrekke en App på smarttelefon eller nettbrett for å hente ut
71

den samme informasjonen. Noen produsenter vil også kunne kombinere et stasjonært
display med gateway funksjonalitet til det lokale nettet og lokal styring.
Hvis en i tillegg etablerer en datahub, vil det være naturlig for programmer/apper og
hente kvalitetssikrede historiske data fra denne. Dette vil sikre at en historisk forholder
seg til de samme data som avregnes, og at en kun har ett system og ett grensesnitt å
kommunisere mot. Dette vil også gjøre at utstyr og programvare for sluttbrukeren blir
vesentlig billigere enn å gå via hvert enkelt nettselskapets individuelle løsninger. En
kombinasjon av sentrale kvalitetssikrede data, sammen med lokal sanntidsinformasjon
og sluttbrukerens egen styring vil gi komplett oversikt og kontroll. I tillegg vil en slik
løsning sikre enkle og innovative styrings og rådgivningstjenester.
En åpen løsning basert på standardkomponenter og kommunikasjon via internett, vil
sikre innovasjon og et åpent og velfungerende marked også for nye tjenester, kontroll,
energieffektivisering og styringssystemer. Ingen proprietære kommunikasjons- eller
styringsløsninger vil hindre fri konkurranse. Dermed vil Norge kunne bli et attraktivt
marked også for internasjonale maskin og programvareleverandører. Alle elektriske
artikler i husstanden kan styres igjennom et slikt konsept og en trenger ikke være fysisk
til stede i husstanden.
Det er viktig at tjenestene gjøres tilgjengelig som en web-service (e.l.) for sluttbrukeren
slik at de selv kan bestemme hvem de velger som tjenesteleverandører. Dette for å sikre
nye innovative løsninger og tjenester som for eksempel sammenligner
kraftleverandører. Et web-service type grensesnitt er også nødvendig for å tilrettelegge
for automatiserte applikasjoner. Hvis en er avhengig av å logge inn på ”min side” hos
enten nettselskapet, kraftleverandøren eller datahuben for å få tilgang til tjenestene vil
dette føre til store begrensninger i utviklingen av nye løsninger.
En moderne og innovativ AMS standard vil dermed både støtte opp om både et fritt og
nøytralt energimarked og et fritt og nøytralt styrings og energieffektiviseringsmarked.
5.6.1 Prisinformasjon
Forskriftene krever at det legges til rette for distribusjon av prisinformasjon til
sluttbrukerne. I en løsning som beskrevet over, vil det være naturlig å distribuere dette
via det datahuben. Dette er kvalitetssikrede data som ikke endres lokalt. En slik løsning
sikrer nøytralitet, da kraftleverandørens ikke priser sendes via et nettverk som et
integrert selskap har kontroll over. En App vil da for eksempel kunne kombinere
målerverdier, pris/tariff, oppdaterte løpende priser fra NordPool med alternative priser
fra andre kraftleverandører. Resultatet er effektive verktøy for både å ha kontroll over
forbruk og priser, samtidig som en vil kunne få hjelp til å velge riktig kraftleverandør i
forhold til den enkeltes forbruksprofil.
5.6.2 Nettnytte
Noen tjenester som struping/utkobling må uansett håndteres via nettselskapenes egne
løsninger som nevnt i innledningen. Disse tjenestene er det ikke naturlig å
konkurranseutsette direkte. Derimot kan der være aktuelt at det er kraftleverandøren
(som en mulig 3.part) er ansvarlig for noen av disse funksjonene, eller hjelper
sluttbrukerne med å utnytte disse optimalt, i tillegg eller sammen med de andre
tjenestene som er beskrevet over.
Et eksempel på en mulig nettnyttetjeneste via kraftleverandøren kan være;
72

Nettselskapet setter en eller flere negativ tariffer som skal kompensere for at de
kan strupe effekt på enkeltanlegg, per sesong eller år. Kraftleverandøren tilbyr
utstyr til sluttbrukeren som gjør struping mulig. Sluttbrukeren får en andel av
den negative tariffen, kraftleverandøren beholder resten.
Nettselskapet kan bygge signifikante grupper av denne typen sluttbrukere. Ved
behov kan nettselskapet koble ut gruppe for gruppe, enten parallelt eller
sekvensielt.
Informasjon om mulig utkoblingsstatus vil kunne bygges inn i meldinger om
anleggsinfo, leverandørskifter e.l. Typisk fasilitert av en datahub
5.6.3 3. parts produkter/tjenester og tilrettelegge for konkurranse om
tilleggstjenester
En åpen løsning basert på standardkomponenter og kommunikasjon via internett, vil
sikre innovasjon og et åpent og velfungerende marked også for nye tjenester, kontroll,
energieffektivisering og styringssystemer. Ingen proprietære kommunikasjons- eller
styringsløsninger vil hindre fri konkurranse. Dermed vil Norge kunne bli et attraktivt
marked også for internasjonale maskin og programvareleverandører. Alle elektriske
artikler i husstanden kan styres igjennom et slikt konsept og en trenger ikke være fysisk
til stede i husstanden.
5.6.4 Infrastruktur for AMS tilleggstjenester
For AMS tilleggstjenester skiller vi mellom en kommunikasjonshub-modell og en
datahub-modell. Den kommunikasjonshub-modellen er basert på kravene slik de ligger i
fra NVE i dag. Det er et mulig alternativ å tilby tilsvarende funksjonalitet som beskrives
for datahub-modellen over, men implementert hos nettselskapene koblet sammen
gjennom en kommunikasjonshub. Dette alternativet er ikke tatt med, fordi det vil kreve
at alle nettselskapene vil måtte lage en minivariant av det datahuben, med en 24/7
tjeneste, som igjen alle tjenesteleverandørene vil måtte forholde seg til. En
kommunikasjonshub kan ta seg av autentisering og ruting, men vil fort bli lite
kostnadseffektiv, fordi AMS tjenester vil ha betydelig flere kommunikasjons-parter og
varianter av tilbudt funksjonalitet og styring enn den meldingsutvekslingen som er
etablert i dag.
Dermed avviker den kommunikasjonshub-modellen noe i forhold til resten av
dokumentet, men det gjøres for å kunne sammenligne en datahub-modell med den
løsningen som er definert i AMS forskriften, samt at et kommunikasjonshub alternativ
uansett vil avvike fra en kommunikasjonshub for de andre prosessene.
5.6.4.1 Distribusjon gjennom kommunikasjonshub-modell
I dette kapittelet er kommunikasjonshub-modellen basert direkte på AMS kanalen slik
forskriften har definert den i dag. En slik løsning vil en måtte forholde seg til
proprietære kommunikasjons-løsninger og mange nettselskap for å oppfylle de nye
forskriftskravene fra NVE. Dette vil føre til kostbare løsninger med begrenset
funksjonalitet. Med stor sannsynlighet vil både tilbudt funksjonalitet måtte reguleres av
NVE og løsningene få begrenset utbredelse pga. pris.
73

3.part/Kraftleverandører
Tilleggstjenester inkl.
prisinformasjon
Nettselskaper
Tegnforklaring
Internett
”AMS kanalen”
3.parts bruk av
”AMS kanalen”
Nettselskapets
Innsamling og styring
Tilleggstjenester inkl.
prisinformasjon
Sluttbruker
Målepunkt
Lokal Styring
Figur 33 - AMS kommunikasjon i en kommunikasjonshub-modell i henhold til forskriften
Sluttbruker
Display
Leverandør
Priser
"AMS kanal"
Nettselskap
Utstyr
Komm.
kanal
Lokalt
grensesnitt
Historiske
måleverdier
Nett +
Nettnytte
Nye
innovative
tjenester
Figur 34 - Ansvar for AMS tilleggstjeneste komponenter og tilgjengelighet av disse i en
kommunikasjonshub-modell i henhold til forskriften
I en eventuell AMS kommunikasjonskanal vil nettselskapet måtte ta betalt for tilgangen,
for å sikre lik konkurranse mellom aktørene som ønsker å bruke denne kanalen, og i
forhold til andre infrastrukturleverandører (tele, ISP, etc). Dette er sannsynlige føringer
fra Post og Teletilsynet, og vil komplisere implementering og forvaltning ytterligere.
Det må bestemmes hvordan en slik pris skal settes og hvordan reguleres, samt hvordan
nøytralitet sikres.
Autentisering vil høyst sannsynlig bli mer komplisert i en kommunikasjonshub-modell,
da en i tillegg til tilgang til måledata, skal definere opp og gi autorisasjon til ulike
tilleggstjenester med ulik funksjonalitet hos 130 nettselskap.
Fordeler med løsning:
Mer kontroll over tilgjengelige tjenester og bruken av disse, fordi
nettselskapet vil har kontroll over hvem som får tilgang og hvilke tjenester
det vil være mulig å implementere.
74

Ulemper:
Fører til begrensede og kostbare løsninger
Mer omfattende integrasjon fra nettselskapene sin side
Krever høy båndbredde på kommunikasjon og ytelse på serveren hos
nettselskapet.
Kompliserende håndtering av betaling for linjeleie/tjenester
Omfattende autentisering
Samfunnsøkonomi
En kommunikasjonshub-modell vil føre til begrensede tjenester og høyere kostnader på
disse, noe som har en negativ samfunnsøkonomisk effekt.
Støtter ny markedsmodell
Dette har begrenset relevans her, men tjenester og applikasjon vil i en
kommunikasjonshub-modell vanskelig tilbys via kraftleverandøren.
Teknisk robust løsning
130 nettselskap skal ha ansvaret for hver sin tekniske løsning. På tross av at flere vil
kjøre på samme plattform vil det totalt sett sannsynligvis gi noe mindre robust løsning i
og med at det i dette aspektet stordriftsfordeler knyttet til tilgjengelighet og redundans.
Implementering
Det er god grunn til å anta at en kommunikasjonshub-modell gir korteste og minst
risikofylte vei i implementeringen. Men samtidig er tilleggstjenestene lite kritiske, og
ikke avhengig av å være klar fra oppstarten av AMS måleren.
5.6.4.2 Distribusjon gjennom datahub-modell
I en datahub-modell vil en kunne bygge tilleggstjenesten som beskrevet i innledningen.
Det blir en enkel og standardisert tilgang både lokalt og sentralt. Det lokale
tilgangspunktet (AMS gateway) er integrert i eller kobles til måleren av nettselskapet.
Nettselskapet vil legge til rette for at kunden på en enkel måte kan tilknytte enheter til
denne på samme måte som en trådløs printer, Apple sine AirPlay produkter eller
Altibox og Canal Digital sine dekodere. Målepunktet hentes automatisk ut fra måleren
via tilgangspunktet, og kobling til det sentrale systemet etableres dermed automatisk.
75

3.part/Kraftleverandører
Nettselskaper
Tegnforklaring
Internett
”AMS kanalen”
Tilleggstjenester
inkl. styring
+ priser
Tariffer
+ tilgjengelige
AMS netttjenester
• AMS tjenester
• Måledata
Tilgjengelige
AMS netttjenester +
Nettleie Tariffer/priser
Nettselskapets
Innsamling og styring
Lokal WiF/ZigBee
Måledata
Tariffer/nettleiepriser
Datahub
Priser
Sanntidsinformasjon/tjenester
Sluttbruker
Målepunkt
Lokal Styring
Lokal Styring
Figur 35 - AMS kommunikasjon i en datahub-modell
Sluttbruker
Leverandør/
3. part
Utstyr
Komm.
kanal
Display/
App
Nett +
Nettnytte
tjenester
Nye
innovative
tjenester
WiFi/ZigBee
Sentralt
system
Historiske
måleverdier
Priser
Nett +
Nettnytte
tjenester
"AMS kanal"
Nettselskap
Lokalt
grensesnitt
Nett +
Nettnytte
Figur 36 - Ansvar for AMS tilleggstjeneste komponenter og tilgjengelighet av disse i en datahub-modell
Siden tilgangspunktet kobles direkte til måleren, og ellers bruker sluttbrukerens internett
til andre tilleggstjenester, vil en ikke komme i konflikt med kravet fra Post og
Teletilsynet og betaling for kommunikasjonskanalen. Dette forenkler vesentlig i forhold
til en kommunikasjonshub-modell.
Dermed er det tilrettelagt for en rekke «gadgets» eller applikasjoner som vil kunne
levere AMS tilleggstjenester som for eksempel:
Prisinformasjon fra eksisterende kraftleverandør
Forbruksinformasjon både historisk og i sann tid
Smarthus pakker med sensorer og releer som kommuniserer via nettet
Prisovervåkning basert på eget forbruk og koblet mot alternative
kraftleverandører
Automatiserte ”agenter” som overvåker, styrer og bytter kraftleverandør basert
på regler som sluttbrukeren bestemmer/godkjenner
Analyser av forbruket over tid og koblet mot temperatur osv.
”Energirådgivning for alle”
76

Autentisering vil kunne bruke samme autentisering som datahuben og må på plass
uansett, og sluttbruker-tilkoblingen lokalt vil kun være synlig på det lokale nettverket.
Har en tilgang på dette vil en også ha tilgang til måleren.
Nettselskapet vil beholde ansvaret for alle funksjoner og tjenester som direkte er knyttet
til egen nettnytte/nettdrift. Nettselskapet kan benytte egen AMS kanal til denne typen
kontroll/kommunikasjon. Nettselskapet vil også kunne velge å bruke internett kanalen
som beskrevet over tilsvarende som en annen 3.part for deler av disse tjenestene. Det vil
være opp til nettselskapet selv å avgjøre hvordan de best skal implementere de
tjenestene de har brukt for til sin utnyttelse av de mulighetene som ligger innenfor
smartgrid og effektivisering av nettdriften.
Typiske tjenester/funksjoner nettselskapet selv vil være ansvarlig for er:
o overvåkning av AMS infrastrukturen
o hel eller delvis inn/utkobling/struping av anlegget
o innsamling og kvalitetssikring av måleverdier
Sluttbrukeren vil ikke ha tilgang til nettselskapets komponenter for styring uten
eventuelt å gå via 3.part og tilgang til tjenester nettselskapet velger å legge ut via
datahuben. Sluttbrukerens egen styring baseres på eget utstyr, og henter kun ut
målerverdier og statusinformasjon fra grensesnittet mot måleren. Nettselskapet kan også
være kraftleverandør av utstyr til sluttbrukeren for styring lokalt hvis de ønsker dette på
lik linje med andre.
Den foreslåtte datahub-modellen sikrer en fleksibel plattform for innovasjon, og vi ser
nok ikke i dag hvilke funksjonalitet som vil bli implementert og tatt i bruk.
Kommunikasjonen i figur 36 er dermed mer et eksempel på hvilke muligheter vi ser i
dag, men markedet vil avgjøre hvordan dette blir brukt, hvor mange tjenester
nettselskapet ønsker å dele og hvor mye kraftleverandører og nye aktører ønsker å tilby
sine sluttbrukere. Figur 37 viser hvordan ansvaret flyttes i forhold til dagens forskrift
som vist i figur 35.
Fordeler med løsningen:
Åpner for innovasjon og konkurranse
Flere tjenester til lavere pris
Sluttbrukeren får eierskap til løsningene
Sluttbrukerens egen kommunikasjonskanal benyttes, og en slipper
kompliserende linjeleieforhold hos nettselskapene.
Enklere autentisering
Ulemper:
Økt kostnad i datahuben
Sårbart i forhold til oppetider på et enkelt system
Samfunnsøkonomi
En datahub-modell med enkle sentrale og lokale grensesnitt åpner for innovasjon,
mange nye tjenester til lav pris. Dette vil etter all sannsynlighet gi en positiv
samfunnsøkonomisk gevinst.
77

Lav pris og enkel tilgang vil være avgjørende i forhold til hvor mange sluttbrukere som
tar i bruk nye tjenester som igjen vil kunne bevisstgjøre forbrukeren og dermed endre
forbruksmønstre.
Støtter ny markedsmodell
Dette har begrenset relevans her, men tjenester og applikasjon vil kunne tilbys via
kraftleverandørene i en datahub-modell. Samme utstyr, samme tjenester/applikasjoner i
flere land vil kunne gi lavere pris, og en kraftleverandør som er aktiv i flere land (eller
en stor norsk) vil kunne satse tyngre på egne applikasjoner.
Teknisk robust løsning
Sluttbrukeren selv overvåker den lokal koblingen, og har bare en hovedkobling til
datahuben. Dette gir en robust løsning som allerede er i bruk i andre bransjer.
Implementering
Løsningen er avhengig at en omfattende datahub og sluttbrukerens egne konfigureringer.
Dette gir en implementering som tar lengre tid og med høyere risiko enn en
kommunikasjonshub-modell.
5.7 Anlegg som ikke har AMS etter 2017
Det vil være en andel anlegg som ikke har AMS etter 2017. Det må lages egne
markedsregler for disse anleggene i den grad de ikke passer i AMS markedsmodellen. I
og med at en per dags dato ikke har oversikt over hvilken type anlegg dette gjelder eller
omfanget, må markedsmodell for denne typen anlegg bestemmes senere. Ved et
begrenset omfang må en bestrebe enkle modeller slik at en ikke pålegger for store
kostnader.
5.8 Behov fra Justervesenet
Justervesenet har behov for en database som inneholder opplysninger om alle målere
som nettselskapene har anskaffet, inklusiv de som er på lager. For hver måler må en
rekke data rapporteres (mye likt det som ligger i dagens ista database):
Måler ID (JV)
Aktør
Fabrikant og type
Målertype
Kontrollgruppe
Status (Installert: Ja/Nei)
Godkjent dato
Godkjent av
m.m.
Ved etablering av en eventuell datathub kan det være hensiktsmessig at en slik
målerdatabase etableres og at nettselskapene er ansvarlige for å oppdatere påkrevd
målerinformasjon. Oppdateringen kan skje gjennom en utvidet meldingstype for
78

grunnlagsdata. Justervesenet vil da kunne aksesserer datahuben og hente ut de data de
trenger til sine systemer.
Men det vil være få synergier mellom en slik målerdatabase og datahuben for øvrig.
Dette skyldes for det første at med foreslått markedsdesign vil det ikke være behov for
målerdata i datahuben slik at meldingen om grunnlagsdata i utgangspunktet ikke vil
inneholde målerdata. For det andre vil påkrevede målerdata ikke kunne hentes
utelukkende fra nettselskapenes systemer som kommuniserer med datahuben. Det må
med andre ord i stor grad lages ekstra funksjonalitet i både datahub, hos nettselskapene
og i kommunikasjonsløsningen. En målerdatabase i datahuben vil derfor medføre ikke
ubetydelige merkostnader for datahuben. Det kan imidlertid være synergier i form av
operativ drift og samordning av data i regi av en nøytral og regulert enhet som en
datahub vil være. Et alternativ kunne være at datahuben overtar ista eller lignende
system.
Det foreslås at en eventuell målerdatabase i datahuben for å dekke Justervesenets behov
utredes videre i samarbeid med Justervesenet dersom det velges å implementere en
datahub.
79

5.9 SWOT analyse for kommunikasjonshub-modell
Styrker
Generelt
Krever mindre utviklings- og implementeringstid
enn en datahub
Utvidelse av kjent modell (kjente prosesser)
Lavere investeringskostnad enn for en datahub
Ett grensesnitt
Distribusjon av måleverdier
Ved endringer i måledata fra nettselskap kan
disse pushes til kraftleverandør med en gang
Nettselskapene kan benytte dagens
avregningssystemer som er knyttet til
økonomisystemene
Administrasjon av sluttbrukeren
Kjente prosesser
Kort implementeringstid pga. gjenbruk av KIS
AMS tilleggstjenester
Mer kontroll over tilgjengelige tjenester og
bruken av disse, fordi nettselskapet vil ha
kontroll over hvem som får tilgang og hvilke
tjenester det vil være mulig å implementere
Høy grad av tilgjengelighet
Svakheter
Generelt
Stor avhengighet av at 130 nettselskaper gjør
alt likt, har høy kvalitet, overholder tidsfrister
og har høy oppetid (99,9 %)
Feil i kommunikasjonshub vil ha
konsekvenser for alle
Alle nettselskap må være kompatible med
grensesnitt til kommunikasjonshuben og med
høy grad av tilgjengelig. Mange feilkilder og
lite oversiktlig i forhold til feilsøking
Kommunikasjonshuben må ha rask responstid
og prosesseringstid, stor lagringskapasitet,
backup løsning, logging av aktiviteter og
oppfølgingsrutiner for manglede data, avvik
osv.
Tilgang til måledata for tredjeparts aktører vil
kreve stor ytelse hos nettselskapene
Krever god responstid i alle ledd
Endring av prosesser krever tilpasninger hos
alle aktører
Mer omfattende integrasjon fra nettselskapene
sin side
Krever høy båndbredde på kommunikasjon
og ytelse på serveren hos nettselskapet.
Samme måledata vil måtte overføres flere
ganger fra nettselskapets datasystem
Distribusjon av måleverdier
Asynkron innsamling;
Kommunikasjonshuben kan ikke returnere
resultat før en får svar fra alle nettselskap,
alternativt må det lages logikk, med timer og
versjoner
Vanskelig å måle kvalitet på måleverdier
Kraftleverandørene må forholde seg til 130
nettselskaper og er i større grad avhengig av
at hvert nettselskap overholder frister og krav
Nettselskapene må utvikle ny funksjonalitet
som muliggjør oppslag for kraftleverandørene
av historiske avregningsunderlag
Kan gi større utfordringer for dokumentering
og opprettholdelse av nøytralitet
Administrasjon av sluttbrukeren
Krevende å ha god nok oppetid på datasystemene
hos 130 nettselskap
AMS tilleggstjenester
Alle kraftleverandører og nettselskap må ha
etablere egne AMS kanaler for alle tjenester
Fører til begrensede og kostbare løsninger
Kompliserende håndtering av betaling for
linjeleie/tjenester
Omfattende autentisering
80

Muligheter
Generelt
Stor grad av skalerbarhet i kommunikasjonshuben
Kan opprettes en sentral driftsorganisasjon
som på vegne av kraftleverandører,
avregningsansvarlig og tredjepart følger opp
og purrer nettselskaper for manglende data og
avvik
Nettselskaper kan samarbeide om
avregningsfunksjonen for å søke
stordriftsfordeler
Obligatorisk bruk av kommunikasjonsløsningen
vil bedre konkurransen mellom
uavhengige kraftleverandører og selvstendige
kraftleverandører
Konkurranse fra systemleverandører for
tilpasning av løsninger til kraftleverandører og
nettselskap
Vil kunne utføre formatkonvertering
(mapping)
Distribusjon av måleverdier
Kan enkelt utvides med nye dataelementer
eller meldinger
Trusler
Generelt
Konsekvenser av dårlig kvalitet kan bli
skjevfordelt mellom eksterne og interne
kraftleverandører
Modellen fjerner ikke automatisk et eventuelt
samarbeid mellom nett og kraft
Endring av forskrifter/prosesser må
implementeres hos alle aktører (risiko for
avvik)
En kommunikasjonshub-modell vil ikke være
best alternativ med tanke på et nordisk og
europeisk marked, begrunnet i mer pågang
mot hver enkelt nettselskaps database fra
kraftleverandører, tredjeparter osv.
Det kreves 24/7 oppetid hos alle nettselskaper
– et tøft krav som stiller store krav
Kommunikasjonshub må skaleres for å
håndtere stor pågang for uthenting/sending av
avregningsunderlag
Sikkerhet, som tilknytning for eksterne
Distribusjon av måleverdier
Alltid eller ofte ett eller flere nettselskap som
ikke klarer kvalitetskravene
AMS tilleggstjenester
Konsekvenser av dårlig kvalitet kan bli
skjevfordelt mellom tredjeparter
Skille mellom nett og kraft blir ikke
automatisk oppfylt
Krever høy båndbredde på kommunikasjon
og ytelse på serveren hos nettselskapet
Tabell 7 - SWOT analyse for kommunikasjonshub-modell
5.10 SWOT analyse for datahub-modell
Styrker
Generelt
Kraftleverandørene benytter kjent modell
Nettselskapene får forenklede prosesser
Endringer, som forskriftsendringer som krever
prosessendring, kan i hovedsak gjøres ett sted
Lett å endre grensesnitt, siden dette kun skal
gjøres mot datahub
Høy grad av tilgjengelighet
Rask identifikasjon og oppretting av feil
Det vil kunne redusere oppgaver og arbeidsprosesser
hos nettselskap og kraftleverandør
Vil kunne bidra til mindre belastning og
pågang mot nettselskapets database
Løsningen vil legge bedre til rette for dokumentering
og opprettholdelse av nøytralitet
Enkel tilgang til datahub for tredjeparter vil
Svakheter
Generelt
Dersom datahuben feiler/ faller ut vil hele
bransjen bli berørt – krever gode back-up
løsninger og speiling
Omfattende system som krever lang
utvikling- og implementeringstid
Teknisk krevende løsning og høy utviklingskostnad
Stor avhengighet av at 130 nettselskaper gjør
alt likt, har høy kvalitet og overholder
tidsfrister
Må opprettes egen driftsorganisasjon for
support, drift og teknisk oppfølging
Samme data vil lagres flere steder. Det vil bli
en ekstra kostnad for bransjen og sluttbruker
med datahub. Nettselskap må ha database for
81

kunne øke produkter og tilbud til sluttbruker
«Single point of contact» for kraftleverandørene
Datahuben kan gjennomføre kvalitetskontroll
og overvåke innsending av data i henhold til.
fastsatte tidsfrister
Nøytralitet og like konkurranseforhold
Endringer (for eksempel forskriftsendringer
som krever prosessendring) kan gjøres ett sted
Effektiv og rask prosessering av data
Enklere tilknytning mot andre land
Distribusjon av måleverdier
Rask identifikasjon og retting av manglende
data eller data med utilstrekkelig kvalitet
Enkel tilgang for kraftleverandører for å hente
ut avregningsunderlag
Tilrettelegger for høy kvalitet i alle
forretningsprosesser som involverer
måleverdier
Kun en eventuell asynkron overføring fra
nettselskap til datahub
Hvis flere prosesser legges i det datahuben vil
måledata allerede ligge klar
Modellen vil kunne bidra til mindre belastning
og pågang mot nettselskapets database
Kvalitetssikrer måleverdier
Konsistent datahåndtering mot sluttbruker og
kraftleverandør
Kraftleverandørene benytter kjent modell,
men får færre korrigeringer tilbake i tid
(forslag om maks 3 måneder + inneværende)
Nettselskapene får en enklere
avvikshåndtering enn i en kommunikasjonshub-modell
Administrasjon av sluttbrukeren
Kraftleverandørene kan benytte dagens
modell, evt. med enkle utvidelser
Nettselskapene får forenklet leverandørskifte
Nettselskapene får enklere prosess for innflytting,
kun oppdatering av kundeinfo
Ikke lenger nødvendig å foreta innflytting
tilbake i tid
Nettselskapene får generelt enklere prosesser
enn i en kommunikasjonshub-modell
Endringer (for eksempel forskriftsendringer
som krever prosessendring) kan gjøres ett sted
Nettselskap slipper eget grensesnitt mot KIS
AMS tilleggstjenester
Sluttbrukeren får eierskap til løsningene
Sluttbrukerens egen kommunikasjonskanal
benyttes, og en slipper kompliserende
linjeleieforhold hos nettselskapene
Enklere autentisering
Endringer (for eksempel forskriftsendringer
som krever prosessendring) kan gjøres ett sted
Nettselskap slipper vedlikehold av egne
proprietære AMS kanaler
innsamling, kvalitetssikring og måle- og
anleggsdata. Kraftleverandør må ha database
for kundedata og fakturering, i tillegg skal det
være en datahub med kopi av disse data
Det vil kreve 100 % oppetid
Datahub vil kreve stor lagringskapasitet og
god skalering
Utfordringer ved inkonsistens i data mellom
nettselskap og datahub
Må sørge for å kunne hente inn
prisinformasjon fra alle nettselskaper på alle
nett-tariffer
Risiko og kostnad ved utfall vil være større
med en datahub
Distribusjon av måleverdier
En datahub vil være kostbar i forhold til
investeringer og drift
Samme data vil lagres to steder. Ikke relevant
ulempe hvis det datahuben også har ansvaret
for andre prosesser som benytter måleverdier
Løsningen vil være mer sårbar mht. kun en
systemleverandør
Flere ledd å tenke sikkerhet i, i forbindelse
med AMS
AMS tilleggstjenester
Dersom datahuben feiler/ faller ut vil hele
bransjen bli berørt – krever gode back-up
løsninger og speiling
82

Muligheter
Generelt
Rask integrasjon ved utvidelse
Nye «nett-oppgaver» kan legges til datahuben
Rask integrasjon mot andre sluttbrukermarkeder
En driftsorganisasjon sentralt som sjekker og
følger opp manglende måleverdier osv.
Datahub kan potensielt være mer tilpasset et
nordisk og europeisk marked, begrunnet i
mindre pågang mot hver enkelt nettselskaps
database
Sluttbruker kan få flere og bredere utvalg av
produkter og tilleggstjenester grunnet lett
tilgjengelige data samlet
Datahub utfører funksjoner som leverandøravregning,
balanseavregningsunderlag etc.
Tredjeparter kan få et grensesnitt for å hente
ut forbruksdata (enøk, styring av
applikasjoner etc.)
Datahub kan utvides til også å utarbeide
avregningsunderlag for nett-tariff
Administrasjon av sluttbrukeren
Mulig å forta leverandørskifte og innflytting
«realtime»
AMS tilleggstjenester
Åpner for innovasjon og konkurranse
Flere tjenester til lavere pris
Rask integrasjon ved utvidelse, for eksempel
med nye dataelementer eller meldinger
Nye "nett"-oppgaver kan legges til datahuben
Trusler
Generelt
Ved endringer i måledata hos nettselskap,
pushes disse til datahub, men det må opprettes
logikk slik at kraftleverandør får vite om
endringene og får hentet disse hos datahub
Kostnadsrisiko
Implementasjonsrisiko
Feil teknologivalg
Datahuben kan bli stor, som kan bety liten
fleksibilitet og endringsdyktighet
Vil kunne være mer sårbar mht. en
systemleverandør
Det må sikres logging av aktivitet og
bevegelse for å spore og hindre misbruk
Flere ledd å tenke sikkerhet i forbindelse med
AMS
Det må tas høyde for og legge til rette for at
man vil operere med kvarter- og
sekundverdier
Tilpasninger i en datahub vil fordeles ut på
aktørene i form av gebyrer og de vil i mindre
grad ha kontroll over kostnaden selv om den
sannsynligvis er lavere enn om de skulle ha
gjort det selv.
Dersom datahuben feiler/ faller ut vil hele
bransjen bli berørt – krever gode backup
løsninger og speiling
Risiko i forbindelse med etablering av
datahub (stort IT-prosjekt)
Inkonsistens mellom data hos datahub og
nettselskap (måledata vs. anleggsdata)
Det kreves 100 % oppetid
Kommunikasjonshub må skaleres for å
håndtere stor pågang for uthenting/sending av
avregningsunderlag
Tabell 8 - SWOT analyse for datahub-modell
83

6 Internasjonal utvikling og fremtidige krav
Det er få eksempler på land som har innført AMS på den måte som Norge har gjort.
Finland er i ferd med å innføre AMS og ligger implementeringsmessig to år foran
Norge. Men de har i hovedsak fokusert på måling og i liten grad på styring og
tilrettelegging for tilleggstjenester. De har ingen sentraliserte funksjoner for lagring og
distribusjon av måleverdier men de har en felles standard for kvalitetssikring.
Løsningen fungerer i den forstand at måleverdiene blir distribuert til sluttbrukeren innen
tidsfristene, men det favoriserer vertikalintegrerte selskaper og medfører kompleksitet
for uavhengige kraftleverandører gjennom mange grensesnitt. I Finland har man i senere
tid vurdert datahub men har bestemt seg for å avvente implementeringen av AMS og
utviklingen av datahuber i andre land.
I Sverige er AMR innført for noen få år siden, men man har allerede nå innsett at man
ikke gikk langt nok i forhold til krav om timeverdier. En ny lov som gir sluttbrukeren
rett til timeverdier er i ferd med å bli implementert. Videre har Energimyndigheten satt i
gang en utredning om datahub.
I Danmark er man i gang med å implementere datahub uten at det foreløpig er krav om
AMS og timeverdier. Motivet for å innføre datahub i Danmark er i hovedsak knyttet til
manglende nøytralitet i gammel markedsmodell samt økonomisk effektivitet.
I Nederland er det etablert en kommunikasjonshub basert på frivillig deltakelse.
Løsningen fungerer teknisk sett, men det er og har vært mange diskusjoner og
uenigheter om dens rolle og nytte. Løsningen har økt i omfang og den utvides nå til
også å lagre måleverdier slik at man kan ha bedre support fra kommunikasjonshuben.
For en region i Texas med 3,2 millioner målepunkter er AMS innført med
kvartersverdier. Her er det lagt stor vekt på tilleggstjenester og nettnytte. En datahub ble
vurdert som beste løsning og i ettertid vurdert som e eneste mulige løsning i forhold til
realisering av tilleggstjenester og nettnytte. I Ontario er AMS med timeverdier innført
for over 3 millioner målepunkter. En datahub er etablert med hovedoppgave å
kvalitetssikre måleverdier og prosessere avregningsunderlag for hvert enkelt målepunkt.
Erfaringene fra Texas og Ontario er nyttige referanser i forhold til hva som er mulig
med hensyn på ytelser.
6.1 Fremtidige krav
Våre erfaringer med deregulert sluttbrukermarked viser at det stadig er behov for
endringer av markedsmodellen, både teknisk og funksjonelt. Det er ingen grunn til å
anta at dette vil endre seg i fremtiden. Det er konkrete planer om et felles nordisk
sluttbrukermarked og arbeidet i EU vil etterhvert bli mer konkret i forhold til krav til
mest mulig like markedsregler i EU. Videre vil det etter all sannsynlighet skje store
teknologiske endringer. AMS og smarte løsninger er i en tidlig fase og kombinert med
IKT utviklingen generelt er det grunn til å anta at dette vil spille en viktig rolle i den
videre utviklingen av sluttbrukermarkedet.
Erfaringer med dagens markedsmodell viser at det er vanskelig å få til endringer. Både
nettselskaper og kraftleverandører må støtte den samme teknologiske plattformen for
datautveksling og alle endringer må avtales og implementeres samtidig av all
nettselskaper og i stor grad også hos alle kraftleverandører. Dette har medført en rigid
markedsmodell der all endring som involverer nettselskaper i hovedsak blir drevet av
regulatoriske pålegg.
84

Felles IKT løsninger kan legge til rette for en mer endringsdyktig og selvregulerende
markedsmodell. Både ved en kommunikasjonshub og ved en datahub vil en ha en
teknologisk dekobling av informasjonsutvekslingen mellom nettselskap og
kraftleverandører. Eksempelvis kan nettselskapene sende sine data basert på en EDI
standard, mens kraftleverandørene kan hente informasjon basert på en annen.
Kommunikasjonshuben vil da fungere som en datakonverterer som støtter begge
standarder og sikrer konsistens. Dette kan være verdifullt dersom det for eksempel
skulle kom krav om XML grensesnitt i en nordisk markedsmodell. Hvis en derimot
ønsker en funksjonell dekobling mellom nettselskap og kraftleverandør er en datahub
klart mer fordelaktig. Da kan en i tillegg innføre nye funksjonelle krav i markedet uten
at nettselskapene trenger å gjøre endringer for eksempel ved en ny
leverandørskiftemodell, nye regler for leveringsplikt, endrede tidsfrister og oppløsning i
balanseavregning osv. En datahub med sentraliserte funksjoner vil lettere kunne
implementere og vedlikeholde nye standarder for AMS tilleggstjenester.
Ved en datahub vil markedsdrevet endring være mye lettere. Behov og forslag fra
sluttbrukere, kraftleverandører og teknologileverandører kan håndteres og besluttes i
datahuben uten at alle nettselskaper må samtykke.
Slik vi kjenner de foreløpige kravene til et nordisk sluttbrukermarked vil de kunne
imøtekommes av en norsk datahub uten at nettselskapene trenger å implementere
endringer utover det en datahub vil kreve. I Danmark mener man at et felles nordisk
sluttbrukermarked i praksis bare er mulig gjennom nasjonale datahuber.
Vi mener at et marked basert på felles IKT løsninger i form av en nasjonal datahub er
mest endringsdyktig i forhold til fremtidens krav fra regulatorer og markedet generelt.
85

7 Hva er best for sluttbrukeren og bidrar til kundevennlighet
Nytte for sluttbrukeren og kundevennlighet er et av hovedmålene for å etablere en felles
IKT-løsning. Dette er også et av NordREGs hovedmål ved å skape et felles nordisk
sluttbrukermarked for strøm.
Det er et sett av faktorer som påvirker sluttbrukeren og den nytte sluttbrukeren oppnår
avhengig av om man velger en kommunikasjonshub eller en datahub som den felles
IKT-løsningen. De viktigste faktorene er beskrevet under:
Sluttbrukers tilgang til informasjon
Med dette menes hvor lett og raskt en sluttbruker kan få tilgang til informasjon om sitt
forbruk og priser. Dette inkluderer enkel tilgang til historiske data. En sluttbruker med
målepunkter i flere nettområder bør også på en enkel måte få tilgang på sitt samlede
forbruk uavhengig av nettområder. Dette er en problemstilling spesielt i
bedriftsmarkedet.
Sluttbrukers tilgang til tilleggstjenester
Dette innebærer hvor effektivt og lett det er å tilby tilleggstjenester knyttet til AMS,
energisparingstjenester, analysetjenester etc. Dette er tjenester som kan leveres av
kraftleverandører eller av tredjepart.
Kvalitet i kundeprosesser
Kundeservice ovenfor sluttbruker skal være effektive og gjennomføres så hurtig som
mulig. Kraftleverandører skal på en effektiv måte håndtere forespørsler og prosesser på
vegne av sluttbrukeren. Dette er prosesser som for eksempel leverandørskifte, flytting
og oppstart av anlegg. For å kunne tilby god kundeservice er tilgang til riktige data raskt
særdeles viktig.
Konkurranse i sluttbrukermarkedet
Konkurranse i sluttbrukermarkedet oppnås gjennom å redusere barrierer for nye aktører.
Å legge til rette for likebehandling av eksiterende og ny kraftleverandører gjennom lik
informasjon og like prosesser er også et viktig element for å få til økt konkurranse.
Fakturering av kraft og nett-tariff gjennom kraftleverandør
Fakturering av både kraft og nett via kraftleverandør vil bidra til at sluttbrukeren får en
samlet oversikt over sin totale energikostnad. Dette vil gjøre det lettere å ha oversikt
over sitt forbruk og faktiske kostnad for elektrisitet. En endring til samlet fakturering vil
dermed kun øke sluttbrukerens bevissthet og føre til redusert energiforbruk. En
obligatorisk samlet fakturering vil også bidra til økt konkurranse da sluttbrukerne
fortsetter med samlet fakturering også dersom de bytter kraftleverandør.
86

Datasikkerhet og personvern
Informasjon om sluttbrukeren og sluttbrukerens forbruk skal behandles med et høyt
sikkerhetsnivå for å unngå eventuelt misbruk av denne informasjonen.
En kvalitativ vurdering av hvordan de to ulike modellene bidrar til økt kundenytte vises
i figuren under.
Figur 37 - Vurdering av kundenytte for henholdsvis kommunikasjonshub og datahub
Faktorene som er beskrevet er i hovedsak indirekte faktorer som kommer sluttbrukeren
til nytte. Sluttbrukeren vil i hovedsak ikke «se» den tekniske løsningen som ligger i
prosessene mellom nettselskap, kraftleverandør og tredjepart. Kundenytten blir derfor
en funksjon av at kundeprosessene fungerer bra som en følge av effektive
forretningsprosesser som ligger under selve kundebehandlingen.
Dersom «teknikken» fungerer som på tegnebrettet vil ikke en sluttkunde merke
vesentlig forskjell på om det er en datahub eller en kommunikasjonshub som ligger som
plattform for utveksling av informasjon mellom partene. Dette krever dog at alle
systemer har en oppetid på 24/7, alle prosesser fungerer optimalt, og alle aktører følger
retningslinjer og krav. Det er prosjektets vurdering at dette er mer realistisk å få til i en
datahub-modell. For andre forhold som er vurdert (datasikkerhet, personvern,
sluttkunders tilgang til tilleggstjenester med mer) er det en betydelig forskjell mellom
en kommunikasjonshub og en datahub.
Vurderingen viser at en datahub vil gi et større bidrag til økt kundenytte og er derfor
den foretrukne modellen.
87

8 Økonomisk analyse
Den økonomiske analysen av alternativene er en del av den samlede vurderingen av
kommunikasjonshub og datahub. En sammenstilling av alle delvurderingene, hvor også
en økonomisk vurdering inngår, finnes i kapittel 12.
De økonomiske forhold forbundet med valget av enten kommunikasjonshub eller
datahub er blitt analysert. Analysen er ikke en total samfunnsøkonomisk analyse av
kostnader og nytte ved endring fra dagens markedsmodell til en leverandørsentrisk
markedsmodell med endrede prosesser og roller. I en slik analyse vil blant annet verdi
for sluttbruker av nye prosesser være inkludert.
Samtidig tar analysen ikke høyde for økte kostnader som følge av AMS for eksempel
installasjon av AMS målere. Videre skal det understrekes at en del av besparelsene ved
implementering av enten kommunikasjonshub eller datahub kommer som en direkte
følge av en leverandørsentrisk markedsmodell og er derfor ikke direkte knyttet til
innførselen av AMS. For eksempel betyr dette at en del prosesser og kostnader flyttes
fra nettselskapet til kraftleverandøren. Denne «unbundlingen» av systemene har en
betydelig innvirkning på kostnadsbildet for en rekke selskaper, men samtidig vil denne
kostnaden påløpe uavhengig av om det implementeres en kommunikasjonshub eller
datahub. Disse kostnader er heller ikke hensyntatt i analysen.
Analysen som er utført avdekker i stedet kostnadene og besparelsene som knytter seg til
henholdsvis kommunikasjonshub og datahub i forhold til dagens kostnadsbilde for
kraftleverandører og nettselskaper. Formålet med analysen er alene å vise forskjellen
mellom kommunikasjonshub og datahub uten å beregne eventuelle økte kostnader og
besparelser ved innføring av AMS eller leverandørsentrisk modell.
Fremgangsmåten i analysen har vært å estimere kostnaden relatert til de viktigste
forretningsprosesser hos kraftleverandører og nettselskaper for deretter å beregne
størrelsen på eventuelle besparelser eller økte kostnader for både kommunikasjonshub
og datahub. Det er tatt utgangspunkt i følgende forretningsprosesser:
Avregning og fakturering av kunder (sluttbrukere) – etablering av
avregningsunderlag og fakturagrunnlag, klargjøring av faktura og utsendelse
Bytte av kraftleverandør (Leverandørskifte) – måleverdiinnsamling,
informasjon til kraftleverandør m.m.
Flytting – sluttbruker som flytter inn/ut
Innfordring – oppfølging av innbetalinger, purring m.m.
Inngåelse og avslutning av kontrakter – inngåelse og avslutning av
kontrakter/kundeforhold (nye anlegg, ny sluttbruker)
Kundeservice utover ordinær kundekontakt – service overfor sluttbrukeren i
forbindelse med spørsmål om tilkopling, utfall, feilmeldinger m.m.
Leverandøravregning – avviksoppgjør kundeavregning
Målerhåndtering – utrykking ved feil, administrasjon av målere
Måleverdiinnsamling og korreksjoner – innsamling av måleverdier fra
målere, feilretting og korreksjoner
Stengning og åpning av anlegg
Ukeavregning (Rapportering til balanseavregning) – rapportering til
balanseansvarlig er aggregerte måleverdier til bruk i balanseavregningen
I forbindelse med gjennomføringen av analysen er det tatt visse forutsetninger:
En leverandørsentrisk markedsmodell medfører at kraftleverandørene fremover
ivaretar kontakten med sluttbrukeren
88

NordREGs anbefaling om innføring av totalfakturering utført av
kraftleverandøren er gjeldende
Nedenstående figur viser dagens totale kostnader i bransjen ved håndtering av de mest
betydningsfulle forretningsprosesser knyttet til måleverdiinnsamling, håndtering av
sluttbrukere, fakturering og innfordring. Disse kostnadene er estimert basert på innspill
fra selskapene som har vært deltakere i henholdsvis Ekspertgruppen og Bransjerådet.
Kostnadene er deretter skalert opp og gir en indikasjon på det totale kostnadsbildet for
ulike prosesser i bransjen. Kostnadene inkluderer personellkostnad (lønn,
arbeidsgiveravgift, sosiale kostnader), avskrivninger av IT utstyr, varekjøp (lisens- og
systemkostnader, porto etc.), indirekte kostnader (allokerte felleskostnader) og andre
driftskostnader:
Kraftleverandører (MNOK) Nettselskaper (MNOK) Hele bransjen (MNOK)
Avregning og fakturering
av kunder
Kundeservice utover
ordinær kundekontakt
Måleverdiinnsamling og
korreksjoner
Stengning og åpning
av anlegg
0
21
62
186
143
142
167
248
142
229
269
329
Bytte av leverandør
111
23
134
Flytting
46
79
125
Innfordring
85
34
118
Målerhåndtering
0
115
115
Inngåelse og avslutning
av kontrakter
39
39
78
Andre kostnader
17
39
56
Leverandøravregning
Ukeavregning
0
4
∑ MNOK
571
32
27
∑ MNOK
1.088
32
31
∑ MNOK
1.659
Figur 38 - Totale kostnader i bransjen ved håndtering av forretningsprosesser
Dagens totale kostnader for bransjen er estimert til mrd NOK ~1,7 i året. Dette er basert
på et grovt bransjesnitt. Selskapenes individuelle kostnader vil variere mye i forhold til
størrelsen på det enkelte selskap og det er derfor vesentlig forskjell på kostnadsbildet
hos store og små nettselskaper og kraftleverandører. Det er også en forskjell mellom de
selskaper som er uavhengige og de som i dag håndterer både nett og kraft i samme
systemer.
8.1 Kostnads- og besparelsesanalyse
I analysen av kostnader og besparelser vurderes forretningsprosessene i forhold til
dagens kostnader ut i fra innførelsen av henholdsvis en kommunikasjonshub og en
datahub og den effekt hvert av løsningsalternativene har for kostnadsbildet. Siden
enkelte prosesser henger naturlig sammen og argumentasjonen i vurderingene er lik, er
noen prosesser blitt gruppert og beskrives sammen, mens andre prosesser beskrives
enkeltvis:
• Målerverdiinnsamling og korreksjoner
• Målerhåndtering
• Avregning og fakturering av sluttbruker, innfordring og kundeservice
89

• Inngåelse og avslutning av kontrakter, flytting, leverandørskifte samt stengning
og åpning av anlegg
• Leverandøravregning (avviksoppgjør kundeavregning) og ukeavregning
(rapportering til balanseavregning)
Anslagene på endret kostnadsbilde er basert på vurderinger og analyser foretatt av
Ekspertgruppen i prosjektet. Anslagene må sees på som grove estimater, og variasjoner
mellom kraftleverandører og nettselskap i Norge kan variere betydelig fra de estimatene
som er blitt foretatt i prosjektet.
8.1.1 Målerverdiinnsamling og korreksjoner
I dag mottar kraftleverandørene måleverdier fra et stort antall ulike nettselskaper og
benytter således mye tid på oppfølging og korreksjoner. Innføring av AMS betyr at mye
av dagens utfordringer med måleverdiinnsamling forsvinner. Imidlertid vil valget av
enten kommunikasjonshub eller datahub ha innvirkning på den fremtidige kostnaden for
denne prosessen.
Målerverdiinnsamling vil i store trekk minne om dagens modell ved innføring av en
kommunikasjonshub, dog vil volumene være betydelig større med innførsel av
timeverdier. Den største forskjellen vil i hovedsak ligge i en utvidet supportfunksjon,
som skal følge opp om meldinger kommer inn, og i mindre grad, det faktiske innholdet
av meldingene. Derfor vil nettselskapene fortsatt oppleve purring fra flere
kraftleverandører, hvilket vil medføre en økt kostnad. Samtidig vil det komme en
spørrefunksjon der kraftleverandørene skal kunne spørre på historiske måleverdier. Som
et resultat vil det bli en ekstra kostnad for nettselskapene som må ha systemer med
oppetid 24/7 for å håndtere disse forespørslene. I tillegg vil det være en kostnad
forbunnet ved tilgjengeliggjøring av måledata. Dette er en ny prosess som vil ha en
høyere kost ved en kommunikasjonshub enn ved en datahub. Dersom det etableres en
datahub vil kravet til oppetid hos nettselskapene kunne bli redusert betydelig.
Innføring av en datahub vil bety at måleverdiinnsamlingen sentraliseres og data lagres
sentralt, hvilket vil kunne gi en rekke effektiviseringsfordeler. Nettselskapene har
ansvar for å levere inn korrekte målerverdier og pga. monitoreringen som finner sted i
datahuben kan det forventes en mer enhetlig håndtering av målerverdier. Datahuben
disiplinerer således nettselskapene i forhold til datakvalitet i forhold til hva som er
mulig for enkeltleverandører. Slik vil datahuben sørge for at kvaliteten av data heves.
En datahub betyr derfor at kraftleverandørene har et enhetlig grensesnitt når de skal
hente ut data i stedet for å måtte forholde seg til opp imot 130 nettselskap. Dette vil gi
betydelige ekstra besparelser for kraftleverandørene enn ved en kommunikasjonshub.
Datahuben vil også ha en supportfunksjon, og det forventes at supportfunksjonen vil
fungere mer effektivt enn i en kommunikasjonshub da alle nødvendige data er lagret i
datahuben.
Nedenstående tabell viser i hvilken grad kraftleverandør og nettselskap opplever økte
kostnader/besparelser i forhold til dagens kostnader relatert til henholdsvis
kommunikasjonshub og datahub:
90

Kraftleverandør
(KL)
Nettselskap (NS)
Kommunikasjonshub
(% i forhold til dagens kost)
Datahub
(% i forhold til dagens
kost)
Målerverdiinnsamling KL: Besparelser (20-30%)
NS: Økte kostnader (45-55%)
KL: Besparelser (50-60%)
NS: Økte kostnader (10-20%)
Tabell 9 - Økte kostnader/besparelser for målerverdiinnsamling ved kommunikasjons- og datahub
8.1.2 Målerhåndtering
Målerhåndtering skal også i framtiden bli håndtert av nettselskapene. I forhold til
dagens situasjon påvirkes prosessen ikke ytterligere av argumentasjonen rundt og
endelig valg av enten en kommunikasjonshub eller en datahub. Derimot forventes det at
nettselskapene vil oppleve omtrent samme kostnadsbilde ved både kommunikasjonshub
og datahub som i dagens situasjon. Dette ses avspeilet i tabellen nedenfor:
Kraftleverandør
(KL)
Nettselskap (NS)
Målerhåndtering
Kommunikasjonshub
(% i forhold til dagens kost)
KL: n/a
NS: Besparelser (5%), økte
kostnader (5%)
Datahub
(% i forhold til dagens kost)
KL: n/a
NS: Besparelser (5%), økte
kostnader (5%)
Tabell 10 - Økte kostnader/besparelser for målerhåndtering ved kommunikasjons- og datahub
8.1.3 Avregning og fakturering, innfordring og kundeservice
En leverandørsentrisk markedsmodell betyr at avregnings- og faktureringsprosessen
fremover vil håndteres som en totalfaktureringsprosess utført av kraftleverandørene.
Disse vil fremover motta ferdige fakturalinjer fra nettselskapene (enten via
kommunikasjonshub eller at de henter dette i datahuben). Det forventes at
kraftleverandørens kostnader forbundet ved denne prosess vil øke som følge av
månedlig fakturering, hvilket er langt hyppigere enn i dagens situasjon. For
kraftleverandørene forventes det at kostnadsøkningen ved fakturering vil være større
ved en kommunikasjonshub enn ved en datahub. Motsatt vil nettselskapene oppnå
besparelser, da det blir tilsvarende mindre arbeid med avregningen/faktureringen. Disse
besparelser vil være størst ved en datahub. En mulig opsjon for nettleiefakturering i
datahuben kan bety at besparelsene blir enda større som følge av lavere kostnader til
faktureringssystem og for å gjennomføre faktureringen.
Hva angår innfordring er det ingen forskjell mellom kommunikasjonshub og datahub.
Kraftleverandørene kan forvente økte tap pga. dårlige betalere, siden kraftleverandøren
skal fakturere for både kraft og nett i en leverandørsentrisk markedsmodell, mens
nettselskapene vil oppleve store besparelser. For sistnevnte gjelder at besparelsene vil
avhenge av hvordan leveringsplikt/anvisningsleverandør blir håndtert i fremtidig
modell.
I en leverandørsentrisk markedsmodell vil kraftleverandøren være kontaktpunkt mot
sluttbruker og ivareta alle kundehenvendelser. Derved vil kraftleverandørene ved både
en kommunikasjonshub og en datahub ta over mye av de arbeidsoppgavene
91

nettselskapene har i dag. Det forventes derfor betydelig økte kostnader for
kraftleverandøren, men det er også stordriftsfordeler ved at både kraft og nett blir
håndtert fra et kontaktpunkt. Imidlertid vil kraftleverandørenes kostnader til
kundeservice være noe lavere ved en datahub, fordi enklere tilgang til data vil gjøre
kundehåndteringen enklere. For nettselskapene antas det at besparelsene (i kroner) blir
større enn kostnadsøkningen hos kraftleverandørene. Årsaken til det er at
kraftleverandøren uansett må håndtere sluttbrukeren, mens nettselskapene slipper
forespørsler fra mange kraftleverandører og kundeoppfølging på målepunktnivå.
Tabellen nedenfor viser en oversikt over prosessene og i hvilken grad kraftleverandør
og nettselskap opplever økte kostnader/besparelser i forhold til dagens kostnader relatert
til henholdsvis kommunikasjonshub og datahub.
Kraftleverandør
(KL)
Nettselskap (NS)
Avregning og
fakturering
Kommunikasjonshub
(% i forhold til dagens kost)
KL: Økte kostnader (65-75%)
NS: Besparelser (20-30%)
Datahub
(% i forhold til dagens kost)
KL: Økte kostnader (40-50%)
NS: Besparelser (50-60%)
Innfordring KL: Økte kostander (95-100%)
NS: Besparelser (50-70%)
Kundeservice KL: Økte kostnader (300-350%)
NS: Besparelser (50-60%)
KL: Økte kostnader (95-100%)
NS: Besparelser (50-70%)
KL: Økte kostnader (250-300%)
NS: Besparelser (60-70%)
Tabell 11 - Økte kostnader/besparelser for avregning og fakturering, innfordring og kundeservice ved
kommunikasjons- og datahub
8.1.4 Inngåelse og avslutning av kontrakter, flytting, leverandørskifte samt
stengning og åpning av anlegg
Prosessene inngåelse og avslutning av kontrakter, flytting og leverandørskifte vurderes
omtrent likt i forhold til fremtidig kostnadsbilde ved kommunikasjonshub og datahub er
også ganske lik.
Inngåelse og avslutning av kontrakter vil gi noe økte kostnader hos kraftleverandører
ved både en kommunikasjonshub og en datahub, men ved en datahub vil
kostnadsøkningen være noe mindre pga. enklere spørrefunksjoner, og lik behandling av
alle forespørsler hos datahuben. Uansett løsningsalternativ vil nettselskapene få
kostnadene sine betraktelig redusert.
Hva angår flytting og leverandørskifte forventes besparelser i forhold til dagens
kostnader for kraftleverandører og nettselskaper ved både kommunikasjonshub og
datahub. Imidlertid forventes disse besparelser å være høyere ved innføring av datahub
enn tilfellet vil være det ved kommunikasjonshub.
I en kommunikasjonshub skal kraftleverandørene sørge for å sende melding til
nettselskapene. Videre skal nettselskapene sende meldinger til henholdsvis ny og
gammel kraftleverandør. For å håndtere flytting og leverandørskifte forutsettes et
datasystem som tilsvarer dagens modell med noen ekstra kostnader, siden nåværende
KIS vil kunne gjenbrukes. Et slikt system trengs ikke i en datahub modell. Både
kraftleverandører og nettselskaper vil oppleve besparelser i forhold til dagens kostnader.
92

En datahub med oversikt over alle målepunkter i Norge leverandørskifteprosessen
betraktelig. Kraftleverandørene forholder seg til en datahub i stedet for mot hvert enkelt
nettselskap og oppnår derfor enda større besparelser enn ved en kommunikasjonshub.
For nettselskapene vil prosessene og tilhørende kommunikasjon bli sentralisert. I
forbindelse med flytting vil det kun gå en informasjonsmelding fra datahuben med
informasjon om den nye sluttbrukeren i målepunktet. Nettselskapet vil derfor ikke
kommunisere med kraftleverandørene, men kun få en informasjonsmelding om inneller
utflytting. Når det gjelder leverandørskifte slipper nettselskapene all
datautveksling. I tillegg bør en datahub gjøre det mulig å håndtere begge prosesser i
«realtime». Flytting og leverandørskifte i en datahub vil således gi nettselskapene
betydelige besparelser i forhold til dagens kostnadsbilde.
Når det gjelder stengning og åpning av anlegg er det ingen forskjell mellom
kommunikasjonshub og datahub. Nettselskapene forventes å oppleve besparelser i
omtrent samme størrelsesorden ved begge løsningsalternativer. I tillegg forventes
prosessen å bli rimeligere i framtiden uavhengig av modell.
Tabellen nedenfor viser en oversikt over prosessene og økte kostnader/besparelser i
forhold til dagens kostnadsbilde relatert til kommunikasjonshub og datahub:
Kraftleverandør
(KL)
Nettselskap (NS)
Inngåelse og
avslutning av
kontrakter
Kommunikasjonshub
(% i forhold til dagens kost)
KL: Økte kostnader (20-30%)
NS: Besparelser (50-60%)
Datahub
(% i forhold til dagens kost)
KL: Økte kostnader (10-20%)
NS: Besparelser (80-90%)
Flytting KL: Besparelser (20-30%)
NS: Besparelser (50-60%)
Leverandørskifte KL: Besparelser (20-30%)
NS: Besparelser (20-30%)
KL: Besparelser (60-70%)
NS: Besparelser (80-90%)
KL: Besparelser (30-70%)
NS: Besparelser (80-90%)
Stengning og åpning
av anlegg
KL: n/a
NS: Besparelser (20-30%)
KL: n/a
NS: Besparelser (20-30%)
Tabell 12 - Økte kostnader/besparelser for inngåelse og avslutning av kontrakter, flytting,
leverandørskifte, og stenging og åpning av anlegg ved kommunikasjons- og datahub
8.1.5 Leverandør- og ukeavregning
Leverandøravregning - avviksoppgjør kundeavregning - håndteres av nettselskapene.
Ved en kommunikasjonshub modell forventes det ikke å være noen endringer til
prosessen, og prosesskostnadene vil ligge på omtrent samme nivå som de gjør i dagens
modell. Derimot forventes det betydelige besparelser ved en datahub, fordi den har all
nødvendig data lagret sentralt og vil kunne håndtere prosessen og gjøre beregningene.
Det samme gjør seg gjeldende for prosessen ukeavregning – rapportering til
balanseavregning. Ved en kommunikasjonshub vil det ikke være noen effektivisering av
prosessen hos kraftleverandører og nettselskaper og kostnadene blir lik dagens
situasjon. Imidlertid vil nettselskapene ved en datahub oppleve store besparelser av
93

samme årsaker som ved leverandøravregning. Kraftleverandørene derimot vil ikke
oppleve noen endringer fra dagens situasjon og derved ha samme kostnader som i dag.
Tabellen oppsummerer prosessene:
Kraftleverandør
(KL)
Nettselskap (NS)
Kommunikasjonshub
(% i forhold til dagens kost)
Datahub
(% i forhold til dagens kost)
Leverandøravregning KL: n/a
NS: Besparelser (5 %) eller samme
kostnader som i dagens situasjon
KL: n/a
NS: Besparelser (80-90 %)
Ukeavregning
KL: Besparelser (5 %) eller samme
kostnader som i dagens situasjon
NS: Besparelser (5 %) eller samme
kostnader som i dagens situasjon
KL: Besparelser (5 %) eller samme
kostnader som i dagens situasjon
NS: Besparelser (80-90 %)
Tabell 13 - Økte kostnader/besparelser for avviksoppgjør kundeavregning og rapportering til
balanseavregning ved kommunikasjons- og datahub
8.1.6 Kostnadsbilde for forretningsprosesser ved kommunikasjonshub og datahub
Uavhengig av løsningsalternativ vil vertikalintegrerte selskaper generelt oppleve at
prosesskostnaden vil øke for kraftleveransedelen, mens det samtidig vil være nesten
tilsvarende besparelser for nettdelen. Ved gjennomgang av forretningsprosessene
relatert til henholdsvis kommunikasjonshub og datahub er følgende anslag for fremtidig
kostnadsbilde fremkommet:
Fremtidige kostnader i forhold til dagens kostnad (% av dagens kostnader)
Kraftleverandører
100% = dagens kostnad
Nettselskaper
Dagens kostnader Kommunikasjonshub
ift i dag Datahub
ift i dag
MNOK
0% 100% 200% MNOK 0% 100%
200% MNOK
Avregning og fakturering
av kunder 143 186
165% 175% +121-139
140% 150%
+74-93
70% 80%
(-)30-43
40% 50%
(-)71-86
Kundeservice utover 21
400% 450% +62-72
350% 400% +52-62
ordinær kundekontakt 248 40% 50% (-)125-150 30% 40%
(-)149-174
Måleverdiinnsamling og 62
70% 80%
(-)12-19
40% 50%
(-)31-37
korreksjoner 167
145% 155%
+75-92
110% 120%
+17-33
Stengning og åpning 0
N/A
N/A
N/A
N/A
av anlegg 142
70% 80%
(-)28-43
70% 80%
(-)28-43
Bytte av leverandør
Flytting
Innfordring
Målerhåndtering
Inngåelse og avslutning
av kontrakter
Andre kostnader
Leverandøravregning
Ukeavregning
0
23
46
79
85
34
39
39
17
39
0
32
4
27
111
115
70% 80%
(-)22-33 30% 70%
70% 80%
(-)5-7 10% 20%
70% 80%
(-)9-14 30% 40%
40% 50%
(-)39-47 10% 20%
195% 200% +80-85
195% 200%
30% 50% (-)17-24 30% 50%
40%
N/A
N/A
N/A
95% 105%
(-)6- +6
95% 105%
120% 130%
+8-12
110% 120%
50% (-)19-23 10% 20%
N/A
N/A
N/A
95% 100%
Figur 39 - Fremtidig kostnadsbilde ved innførelse av kommunikasjonshub og datahub
N/A
N/A
N/A
(-)2-0
N/A
N/A
95% 100%
(-)0,5-0
95% 100%
95% 100%
(-)1-0 10% 20%
10%
20%
N/A
(-)33-77
(-)19-21
(-)28-32
(-)63-71
+80-85
(-)17-24
N/A
(-)6- +6
+4-8
(-)31-35
N/A
N/A
N/A
(-)26-29
(-)0,5-0
(-)21-24
I dagens modell har kraftleverandørene en årlig kostnad på ~MNOK 571 ved håndtering
av forretningsprosessene, mens nettselskapene har en årlig kostnad på ~MNOK 1.088.
Dagens kostnadsbilde for bransjen er således ~mrdNOK 1,7.
94

Ved innføring av en kommunikasjonshub ses det økte kostnader i bransjen i forhold til
dagens situasjon for prosessene knyttet til avregning og fakturering,
målerverdiinnsamling og korreksjoner, samt for innfordringsprosessen. Prosessene
vedrørende målerhåndtering samt leverandøravregning og ukeavregning er omtrent på
nivå med dagens kostnader, i forhold til de resterende forretningsprosesser oppleves
besparelser for bransjen sett under ett.
Isolert sett vil kraftleverandørene totalt oppleve en potensiell kostnadsøkning på MNOK
190-250/pr år i forhold til dagens kostnadsbilde. Samtidig vil nettselskapene få en
kostnadsbesparelse i størrelsesorden MNOK 200-310/pr år. Bransjens totalkostnad for
håndtering av forretningsprosessene i en kommunikasjonshub modell blir således
mrdNOK 1,5-1,7 i året, hvilket er omtrent som i dag.
Ved innføring av en datahub vil det potensielt sett kunne bli økte kostnader i bransjen i
forhold til dagens kostnadsbilde for de samme prosessene som i kommunikasjonshuben:
avregning og fakturering, målerverdiinnsamling og korreksjoner samt innfordring. De to
førstnevnte prosesser vil imidlertid ha en relativt lavere kostnadsøkning enn i
kommunikasjonshuben eller potensielt kunne oppnå en liten kostnadsbesparelse. Videre
er målerhåndtering ved en datahub også på nivå med dagens kostnader, mens det er
besparelser for de resterende forretningsprosesser.
I forhold til kraftleverandørene alene vil innføring av en datahub medføre en potensiell
kostnadsøkning på MNOK 50-140/pr år. Nettselskapene vil derimot oppleve en
betydelig kostnadsbesparelse på MNOK 430-530/pr år. Totale kostnader for bransjen
ved håndtering av forretningsprosessene i en datahub modell blir da mdrNOK 1,2-1,4 i
året. Den totale besparelsen i bransjen er dermed i området 290 MNOK til 480
MNOK før kostnaden for etablering og drift av en datahub er regnet inn.
8.2 Utviklingskostnader og årlige driftskostnader
Kostnadene ved å utvikle en datahub / kommunikasjonshub tilpasset norske forhold er
ikke kjent. Kostnaden kan først spesifiseres etter at det er blitt utarbeidet en detaljert
kravspesifikasjon til løsningen, og at det blir foretatt en forespørsel til
leverandørmarkedet.
Prosjektet har innhentet kostnadsestimater fra lignende løsninger internasjonalt.
Datahuben i Danmark som Energinet.dk etablerer har et kostnadsbudsjett på ca 160
MDKK for utviklingen av løsningen. Når datahuben er i drift forventes et årlig
driftsbudsjett på ca 25 MDKK. kraftleverandør for systemutviklingen er Logica.
Smart Meter Texas er en avansert sentral måleverdidatabase som er etablert i USA.
Smart Meter Texas skal håndtere 3,5 millioner målepunkter og er et samarbeid mellom
4 store nettselskap i Texas. Utviklingen av denne løsningen kostet 25 MUSD. Den
årlige driftskostnaden for løsningen er på 10 MUSD. Løsningen er utviklet og driftet av
IBM.
Kommunikasjonshub som beskrevet i dette dokumentet vil ha flere av de funksjoner
som en datahub har, med unntak av en komplett målepunktdatabase og måledatabase. I
tillegg vil datahuben utføre utvalgte forretningsprosesser. Kommunikasjonshuben skal
ha en supportfunksjon som støtter kraftleverandører og nettselskap ved
kommunikasjonsfeil, samt ved manglende data. Dette innebærer at
kommunikasjonshuben må etablere et verktøy som følger meldingsutvekslingen og
stegene i forretningsprosessene. Det må derfor etableres et system som muliggjør
95

oppslag i meldingene og mulighet til å lese innholdet i alle meldinger. Løsningen er
ganske omfattende og vil bety et relativt stort utviklingsarbeid.
I denne analysen har vi valgt å bruke følgende kostnadsestimater for utvikling og drift
av henholdsvis datahub og kommunikasjonshub:
Kommunikasjonshub
(MNOK)
Datahub
(MNOK)
Utviklingskostnad 40-80 180-240
Årlig driftskostnad 12-18 20-30
Sum årlig kostnad 20 til 34 56 til 78
Tabell 14 - Årlige kostnader ved kommunikasjons- og datahub
Det forutsettes at utviklingskostnaden avskrives over 5 år, slik at den årlige kostnaden
dermed blir investeringskostnad/5 år. Basert på denne forutsetning vil en
kommunikasjonshub ha en lavere årlig kostnad som inkluderer avskrivninger på
systemet og andre årlige driftskostnader (personell etc.).
Den årlige kostnaden for henholdsvis kommunikasjonshub og datahub vil da måtte bli
fratrukket de eventuelle besparelser som nettselskaper og kraftleverandører vil oppnå i
hver av modellene.
Den totale besparelsen ved å innføre en datahub eller en kommunikasjonshub i det
norske markedet blir dermed:
Kommunikasjonshub
(MNOK)
Datahub
(MNOK)
Økte kostnader
kraftleverandører
Reduserte kostnader
nettselskap
Årlig kostnad
datahub/
kommunikasjonshub
190-250 50-140
200-310 430-530
20-34 56-78
Anslag besparelser -84 til 100 212 til 424
Tabell 15 - Anslag for samlet besparelser ved kommunikasjons- og datahub
Basert på analysen er det vurdert at en kommunikasjonshub totalt sett vil endre
kostnadene i bransjen lite fra dagens nivå. Årlige besparelser er i intervallet – 84
MNOK (tap) til 100 MNOK.
96

Det antas at en datahub vil bidra betydelig til besparelser gjennom effektive prosesser
og reduserte kostnader i bransjen. Den årlige besparelsen er grovt anslått til å være i
intervallet 212-424 MNOK pr år.
97

9 Ytelse og Sikkerhet
Dette kapitlet analyserer om de ulike løsningsalternativ har høy nok grad av sikkerhet
og er robuste nok til å håndtere store datamengder. Sikkerhet omfatter følgende
hoveddimensjoner:
Tilgjengelighet, dvs. hvilken grad løsningen er tilgjengelig i ønsket
tidspunkt/utstrekning
Konfidensialitet, dvs. i hvilken grad man kan stole på at bare autorisert personell
får tilgang til informasjonen
Integritet, dvs. i hvilken grad man kan stole på innholdets nøyaktighet
At løsningen er robust nok til å håndtere de aktuelle datamengdene som det er krav til,
er også et aspekt ved tilgjengelighet. Utilstrekkelig dimensjonering kan føre til
sammenbrudd av hele eller deler av systemet eller uakseptable responstider som gjør at
løsningen ikke kan anses å være funksjonelt virkende. Den følgende analysen omfatter
kapasitetsberegninger av ulike løsningsmodeller og en sikkerhets- og sårbarhetsanalyse
for å avdekke hvordan løsningsmodellene oppfyller øvrige krav til sikkerhet.
9.1 Generell beskrivelse
AMS og tilhørende IKT-løsninger stiller store krav til sikkerhet på flere nivåer.
Forsyningssikkerhet er et hovedmål for aktørene i bransjen og AMS vil innebære nye
muligheter for nettselskapene til å styre leveranse av strøm bl.a. gjennom utkobling av
målepunkter. Av beredskapshensyn er det helt avgjørende med pålitelige funksjoner for
å støtte nettdriften samtidig som at ingen uvedkommende får mulighet til å forstyrre den
normale nettdriften gjennom sabotasje, f.eks med utkobling av spesifiserte målepunkter
eller grupper av målepunkter.
Sikkerhet vil også omhandle løsnings evne til å skjerme data fra uvedkommende
(konfidensialitet) og dens evne til å beholde data intakt (integritet). Konfidensialitet er
viktig i forhold personvernlovgivningene, for å forhindre uønsket konkurransevridning
og svindel. Integritet må ivaretas for å sikre at man kan stole på informasjonsinnholdet
og sikre konsistens i data gjennom hele verdikjeden. Løsningen må også sikres mot tap
av data gjennom tilstrekkelig back-up og mekanismer som gjør at data og funksjoner
alltid kan gjøres tilgjengelig for de definerte brukere selv etter uforutsette hendelser som
kan ødelegge data (tilgjengelighet).
Med AMS får nettselskapene flere muligheter i forhold til drift av nettet, så som
informasjon om brudd, jordfeil, utkobling ved vedlikehold, overvåkning, lastutkobling,
m.m.. Denne typen tjenester er det opp til det enkelte nettselskap å etablere, men det må
sikres at det ikke får kapasitetsmessige og sikkerhetsmessige konsekvenser for
løsningen.
AMS tilleggstjenester innebærer at en må forholde seg til nettselskapene både for
tilgang til målerverdier og kommunikasjon via nettselskapenes kommunikasjonskanal.
Effektiv distribusjon av prisinformasjon til sluttkunde via AMS er bare en av flere
tilleggstjenester, men er spesielt fokusert i forskriften.
For å få tilgang til måleren og målerverdier i sann tid og for målerverdier for de siste 24
timer, må måleren utstyres med en kommunikasjonsenhet som er standardisert.
Sluttbrukerne bør kunne utstyres med en enhet som de selv kan koble til sitt lokalnett og
som kommuniserer direkte med måleren. På denne måten vil en raskt og
kostnadseffektivt kunne sikre at alle som ønsker kan få tilgang til sine data for lokal
styring og oversikt.
98

Et eventuelt display, på for eksempel kjøkkenet, vil da kunne kommunisere med
måleren via sluttbrukerens lokalnett. Mange vil foretrekke en «App» på smarttelefon
eller nettbrett for å hente ut den samme informasjonen. Noen produsenter vil også
kunne bruke grensesnittet for display som kan benyttes til overføring av
sanntidsinformasjon til det lokale nettet og en lokal PC med funksjonalitet for å utnytte
denne informasjonen kombinert med informasjon over internett.
For å møte kravet om at nettselskapene skal formidle informasjonsutveksling med
målepunkt for 3. part (laste ned prisinformasjon, etc.) må det bygges tilstrekkelige
sikkerhetsmekanismer.
Med krav til rapportering og behandling av timeverdier og senere mulig utvidelse av
frekvensen på målingene til hvert 15 minutt, er det avgjørende at løsningen er robust
nok til å håndtere store datamengder. Løsningens kapasitet vil være avhengig av i
hvilken grad kommunikasjonsløsning, servere, applikasjoner, databaseløsning og
lagringsløsning er i stand til å håndtere datavolumene assosiert med regelmessig
innhenting av data fra ca 2,7 millioner målepunkter. En kritisk faktor vil være hvor mye
data som kan håndteres pr tidsenhet, buffer- og håndteringskapasitet. Det kan være
behov for å etablere regler for å fordele innsamling av data over en periode.
Overskridelse av kapasitetsgrenser kan føre til tidsforsinkelser eller sammenbrudd i
løsningen som går ut over tilgjengelighet og dermed blir et sikkerhetsproblem.
9.2 Alternative scenarier
Rapporten konsentrerer seg om to alternative scenarier:
1. En løsning med en sentral datahub med database og sentrale
behandlingsfunksjoner. Nettselskap og kraftselskap oversender data til eller
oppdaterer datahuben direkte. Kraftselskap og nettselskap henter data fra
datahuben ved oppslag i databasen.
2. En løsning med en kommunikasjonshub der alle meldinger enten de kommer fra
nettselskap eller kraftleverandører, sendes via en meldingssentral som igjen
videresender informasjonen til riktig adressat. Kommunikasjonshuben foretar
ingen datalagring, bortsett fra transaksjonslogger
Dagens meldingsbaserte løsning der alle kommuniserer med alle for utveksling av
måledata og annen informasjon som kreves for de aktuelle forretningsprosessene er kort
beskrevet som referansepunkt.
I tillegg gjøres det betraktningen knyttet til en mellomløsning kalt meldingshub med
sentral lagring av målerregister og andre indekser for styring av meldingsutvekslingen.
Det er gjort kapasitetsberegninger også for denne modellen.
De mest desentrale systemene vil kreve innsats på standardiseringssiden (som i dag) og
mye oppgraderinger og koordinering lokalt. I det følgende er de fire scenarier kort
beskrevet, men full analyse er kun gjennomført for Scenario 2 og 4 (Scenario 3 er kun
kapasitetsvurdert).
99

9.2.1 Scenario 0 - Dagens løsning
Dagens løsning er illustrert i figuren nedenfor.
Figur 40 – Scenario 0 – Dagens løsning
I denne løsningen vil meldingsutveksling med overføring av informasjon foregå direkte
fra selskap til selskap ved standardiserte meldinger (i dag benyttes Ediel - en fremtidig
løsning kunne baseres på web-services). Alle nettselskapene må holde oversikt over de
kraftselskap de skal rapporter til med korrekt adresse. Likeledes må kraftselskapenes
systemer også holde oppdatert adressene til de nettselskapene de skal utveksle
meldinger med. Prosessen med leverandørskifte må sikre at disse adresseregistrene
holdes à jour og er korrekte til enhver tid. Det er en forutsetning at meldingsstandardene
hos avsender og mottaker er kompatible.
I sin mest ekstreme form skal 130 nettselskaper kommunisere med 110
kraftleverandører om 2.700.000 målepunkter og deres verdier. Døgnlig rapportering om
timeforbruk fra hvert punkt er påkrevet. I tillegg vil det komme en del fortløpende
oppdateringer fra mange av punktene med større nøyaktighet enn originalmeldingen.
Bare for rapporteringen for et døgn, gir mulighet for over 14.000 kommunikasjonsruter
med ujevnt trafikkinnhold.
100

9.2.2 Scenario 1 –Kommunikasjonshub
En løsning med en kommunikasjonshub er vist i figuren nedenfor:
Figur 41 – Scenario 1 – Kommunikasjonshub
I denne løsningen sender de 130 nettselskapene måledata til kommunikasjonshuben.
Kommunikasjonshuben formidler disse meldingene videre til kraftleverandørene.
Kommunikasjonshuben sikrer at meldingen har autorisert avsender og mottaker og kan
kontrollere format, eventuelt også gjennomføre formatkonvertering dersom avsender og
mottaker ikke har kompatible formater. Både nettselskap, kraftleverandør og andre
autoriserte aktører har et punkt å forholde seg til, nemlig kommunikasjonshuben, men
hver aktør må holde oversikt over hvem de skal utveksle data med i de ulike prosessene.
Meldingsformidlingen skjer ved at nettselskapene «pusher» ut sine meldinger via
kommunikasjonshuben som sender disse videre til kraftleverandørene. Huben kan føre
en transaksjonslog, men tar ikke vare på innholdet. Alternativt kunne
kommunikasjonshuben sorter meldinger i "postkasser" til hver kraftleverandør som så
kunne hente sin post når de måtte ønske det. Uten postkasse vil løsningen kreve en
”push”-mekanisme hele veien, mens med en ”postkasse” kan kraftleverandørene ”pulle”
ut sine meldinger. Dette siste alternativet krever imidlertid mer logikk og
prosessering/lagring sentralt.
For tilleggstjenester i en desentral løsning, vil en måtte forholde seg til proprietære
kommunikasjonsløsninger og mange nettselskap hvis man ønsker å oppfylle de nye
forskriftskravene. Dette vil føre til kostbare løsninger med begrenset funksjonalitet.
Mest sannsynlig ville tilbudt funksjonalitet måtte reguleres av NVE og løsningene ville
få begrenset utbredelse på grunn av pris.
En kraftleverandør av tilleggstjenester som ønsker å operere i eller levere en applikasjon
for dette til flere nettområder, vil måtte tilpasse seg de ulike implementeringene. Slike
tilpasninger kan bli krevende i et lite marked som Norge og vil fort bli kostnadsdrivende
og /eller favorisere «vendor-lock-in».
For å gi sluttbrukere tilgang til forbruk og måleverdier må hver kraftleverandør tilby
adgangskontroll (samme sikkerhetsnivå f.eks. min-ID, bank-ID, e.l.) og web-services
101

eller tilsvarende for å hente ut data. En slik implementering med nødvendig
autentisering og autorisasjon vil bli mer komplisert med en desentral løsning.
Alle støttefunksjoner vil måtte implementeres lokalt med denne modellen.
9.2.3 Scenario 2 - Meldingshub
En løsning med en meldingshub basert på en aktiv meldingstjeneste er vist i figuren
nedenfor:
Figur 42 - Scenario 2 – Meldingshub basert på en aktiv meldingstjeneste
Også denne løsningen sender nettselskapene måledata til meldingshuben.
Meldingshuben har et register som kobler hver enkelt Målepunkt ID til en
kraftleverandør. Basert på dette registeret pakker meldingshuben opp data i innkomne
meldinger fra nettselskapene for så å pakke disse i nye meldinger til kraftleverandørene
med de målepunktene som den enkelte skal ha måleverdier for. Denne omflettingen gjør
at hvert nettselskap kan pakke sine meldinger med en lang sekvens med sine Målepunkt
ID/ timeverdier, mens kraftleverandørene kun forholder seg til mottatte meldinger med
sine Målepunkt ID/timeverdier. Pakking i slik lange serier vil være mest effektivt
transmisjonsmessig. Meldingsformidlingen skjer ved at nettselskapene «pusher» ut sine
melinger via meldingshub (som fletter om innholdet fra nett-meldingene til nye
leverandør-meldinger) og sender disse videre til kraftleverandørene.
Meldingshub må håndtere meldinger fra 2.700.000 punkter pr døgn fra 130 nettselskap
og formidle disse til de 100+ kraftleverandørene. I sin enkleste form sender
nettselskapene sine meldinger på foresatt tidspunkt til sentralen som formidler disse
videre til kraftleverandørene. Denne første formidlingen skjer innenfor et ganske lite
tidsintervall (i forkant av den daglige rapporteringsfristen), men med mulighet for
påfølgende formidlinger, hvor eventuelle data som er oppdatert (med annet statusflagg),
sendes.
102

For tilleggstjenester i en desentral løsning, vil en måtte forholde seg til proprietære
kommunikasjons-løsninger og mange nettselskap for å oppfylle de nye
forskriftskravene. Dette vil føre til kostbare løsninger med begrenset funksjonalitet.
Med stor sannsynlighet vil både tilbudt funksjonalitet måtte reguleres av NVE og
løsningene få begrenset utbredelse på grunn av pris.
En kraftleverandør av tilleggstjenester som ønsker å operere i eller levere en
applikasjoner for dette til flere nettområder, vil måtte tilpasse seg de ulike
implementeringene. Slike tilpasninger kan bli krevende i et lite marked som Norge og
vil fort bli kostnadsdrivende og /eller favorisere «vendor-lock-in».
For å gi sluttbrukere tilgang til forbruk og måleverdier, må hver kraftleverandør tilby
adgangskontroll (samme sikkerhetsnivå f.eks. min-ID, bank-ID, e.l.) og web-services
(eller tilsvarende) for å hente ut data. En slik implementering med nødvendig
autentisering og autorisasjon vil bli mer komplisert med en desentral løsning.
Støttefunksjoner vil måtte kunne implementeres sentralt, men ajourholdes av de lokale
aktører som har ansvar for dataene (kraftselskapene har ansvar for sine kundedata og
nettselskapene har ansvar for målerdata). En slik støttefunksjon vil være å administrere
et indeksregister med Målepunkt ID og adressene til nettselskapet som eier det, og
kraftleverandøren som leverer kraft til det. Enkelte prosesser som leverandørskifte kan
forenkles i en slik modell.
Alternativ til løsningen med "omfletting" kan nettselskapet holde oversikt over hvilke
kraftleverandør som skal ha data fra det enkelte Målepunkt ID og sende meldinger til
hver kraftleverandør med de aktuelle måledata. Alternativet der kraftleverandøren
sender forespørsel med spesifikasjon av "sine" Målepunkt ID vil generere svært mye
datautveksling frem og tilbake.
9.2.4 Scenario 3 – Datahub
En datahub vil inneholde en database med alle måleverdier, strukturdata per målepunkt
og sentraliserte funksjoner. Disse vil finnes i forskjellige former avhengig av status som
beskrevet over. Løsningen er illustrert i figuren nedenfor:
103

Figur 43 - Scenario 3- Sentral måleverdidatabase med sine dataelementer og prosesser
I denne løsningen vil nettselskapene oversende data til og oppdatere datahuben.
Kraftselskap og andre autoriserte aktører får tilgang til informasjon i databasen og kan
hente ut data i det omfang de trenger og når de trenger det. Leverandørskifte håndteres
som en sentral prosess. Databasen vil inneholde målerdata og et målerregister som
grunnlag for leverandørskifte. Målerregisteret med Målepunkt ID inneholder
anleggsinformasjon som oppdateres av nettselskapene og informasjon om hvilke
kraftleverandør som leverer strøm til målepunktet. Balanseavregning kan dermed
produseres av beregningsansvarlig basert på de data som allerede finnes i databasen.
Nettselskapene kan fortsatt ha rollen som beregningsansvarlig.
Toppbelastning i denne løsningen vil være ved den daglige innsending av måledata,
overføring av fakturagrunnlag for nettselskapene (eventuelt kan nettselskapene få
produsert fakturagrunnlaget sentralt) og når kraftselskapene skal hente ut underlag for
sin fakturering til sluttkunden.
Denne databasen vil være avhengig av en godt dimensjonert «front-end» som kan
prosessere innkommende data fra de 130 nettselskapene med målerdata med
timeoppløsning fra 2.700.000 punkter pr døgn. Dette gir et transaksjonsvolum inn mot
den sentrale databasen som er meget ressurskrevende.
Disse data skal tilgjengeliggjøres for de som har «rett» til disse, med en
tilgangsoppløsning som må kunne brytes helt ned til hvert målepunkt. Alle 100+
kraftleverandører er helt avhengig av å hente ut disse data til et gitt tidspunkt for å
104

kunne sette sammen sitt grunnlag for fakturering til hver kunde. Tilsvarende har
nettselskapene rett til «sine» data fra samme kilde. I tillegg kommer forespørsler om
data fra den enkelte måler, for eksempel om forbruk fra en sluttkunde.
En forutsetning som er lagt til grunn, er at data ikke skal «vaskes» sentralt – hvert
nettselskap er ansvarlig for kvaliteten på innlevert data med de forskjellige statusflagg
som beskrevet over.
Tilsvarende vil det med jevne mellomrom være et stort påtrykk for å lese eller hente ut
data for prognostisering, osv.
En sentralisert tjeneste vil bestå av fire funksjonelle deler:
1. Sentralt rammeverk for entydig definisjoner av alle grenseflater og
overføringsmekanismer
2. Sentral database: Dette er antatt å være en standard relasjonsdatabase, med
transaksjonsprinsipper bygget på ACID (Atomicity, Consistency, Isolation,
Durability), eventuelt med prinsipper for CRUD (Create, Read, Update and
Delete) for håndteringen sett fra bruker- / prosess-siden og et system for DBMS
3. Sentrale basisfunksjoner: Alle basisfunksjoner er implementert sentralt
4. Sentrale tilleggsfunksjoner kan utvikles over tid. Kapasitetsanalysen omfatter
kun sentrale funksjoner knyttet til oppdatering og formidling av måleverdier,
formidling av fakturagrunnlag for nettfaktura samt leverandørskifte.
Sikkerhetsanalysen omfatter i tillegg autorisasjon og tilgang til data og formidling av
informasjon til målepunkt. En sentral løsning kan tilby adgangskontroll for å hente ut
data på vegne av ulike sluttbrukere (samme sikkerhetsnivå f.eks. min-ID, bank-ID, e.l.)
og webservices. GUI kan ligge hos kraftleverandøren.
Figur 4 gir et bilde på funksjoner som kan implementeres. Fellestjenestene ringet inn i
rødt er tjenester som (med fordel) bør legges til sentral løsning initielt.
9.3 Metodikk og generelle forutsetninger
De følgende to kapitler omhandler kapasitetsberegninger og sikkerhets- og
sårbarhetsanalyser. Kapasitetsanalysen er gjort i tre trinn:
1. Det er gjort en analyse av datavolum og prosesser
2. Basert på dette og kunnskap om tilgjengelig teknologi er det gjort forutsetninger
om utforming av teknisk infrastruktur
3. Deretter er det foretatt beregninger som viser nødvendig behandlingstid for de
kritiske prosesser som medfører høy belastning på løsningene
Vi presenterer en samlet oppsummering av resultatene fra den trinnvise analysen med
fokus på hva som vil være nødvendig behandlingstid for de kritiske oppgavene.
Sikkerhets og sårbarhetsanalysen er todelt:
a) Analyse av sikkerhet og sårbarhet i de ulike ledd i den tekniske infrastrukturen
b) Analyse av trusselbildet i forhold til informasjonsmodellen og ulike kategorier
av informasjon som lagres og utveksles i den totale løsningen
Vi har benyttet en modell for teknisk infrastrukturen som vist i figuren under:
105

Figuren viser tre prinsipper:
Figur 44 - Datahub vs kommunikasjonshub
Begge modellene forutsetter at kraftleverandørene og nettselskapene har
ansvaret for sine egne tjenester og sin del av infrastruktur helt fram til naturlig
midtpunkt i nettverket
Kommunikasjonshub består av tre hovedkomponenter sett fra et
infrastruktursynspunkt: Nasjonalt nett, Sentral Infrastruktur og sentrale servere
(for å forestå meldingsformidlingen)
Datahub består i de tre elementene til kommunikasjonshuben (antall servere er
utvidet) samt sentral database og støttefunksjoner som sikrer forsvarlig tilgang.
Prinsippene for informasjonsutveksling og prosessering er illustrert i Figur 6 nedenfor.
Kommunikasjon vil i hovedsak være todelt: (1) trafikk inn til sentral hub fra nettselskap
(N1) og trafikk ut fra sentral hub til kraftleverandør (L1). Trafikk andre veien er
primært i forbindelse med leverandørskifte og ulike former for spørring.
Vi anser det mest hensiktsmessig at nettselskap (N1) tar initiativet til å sende data
(push) ved de periodiske innrapporteringene (måleverdier, balanserapporter og
faktureringsgrunnlag). Likeledes vil nettselskap "pushe" informasjon som gjelder
målerdata der nettselskap er ansvarlig for grunndata. I scenariet med en
kommunikasjonshub vil huben pushe disse data ut til kraftleverandør og
balanseansvarlig. Med datahub vil det være mest naturlig at kraftleverandør og
balanseansvarlig selv henter ut data fra huben etter behov (pull).
Prosessering omfatter trafikkstyring, meldingskonvertering, kontroller og loggføring
For datahub kommer i tillegg lagring og uthenting av data fra databasen.
Figur 45 - Kjerneprosesser i sentral hub
106

Frist 1 i figuren er det tidspunkt da informasjonen skal være tilgjengelig for
Kraftleverandører og andre. Frist 2 må settes ut fra det tidsrom det tar for
innrapportering, prosessering og tilgjengeliggjøring av denne (Ut). Dersom alle forsøker
å hente ut data samtidig (pull), kan det skapes flaskehalser som i praksis gjør disse
utilgjengelig. En mulighet til å løse dette er å innføre prosedyrer med tildeling av
adgang. Dette bør i så fall gjøres slik at man ivaretar krav om likebehandling.
9.4 Kapasitetsberegning
9.4.1 Beregningsgrunnlag
9.4.1.1 Overordnet volum
Volumet av data styres foruten innsendingsfrekvens av følgende parametere:
130 nettselskap
110 kraftleverandører
Antall balanseansvarlige = Antall kraftleverandører
2,7 mill målere/målepunkter
200.000 leverandørskifter per år
375.000 flyttinger per år
9.4.1.2 Prosesser
Analysene tar utgangspunkt i følgende tjenesteprosesser:
Måleverdi-innsamling
Innsamling av fakturagrunnlag for nettleie
Balanseavregning
Tilfeldige oppslag og oppdatering av registerinformasjon
o Nye eller endrede felles tjenesteprosesser (leverandørskifte,
målerinformasjon, etc.)
o Mulige tjeneste-prosesser rettet mot sluttbruker og tredjepart
9.4.2 Datavolum
Datavolumet er beregnet ut fra at et antatt ønske om å komprimere innholdet ved å
samle opp mest mulig informasjon i hver overføring som vist i figur 7-9. På dette
volumet er det så lagt på overhead (ca 400 % - noe avhengig av hvilke løsning som
beregnes). En slik overføring av hele ”tidsserier” er imidlertid ikke standardisert. Skal
man overføre hver måling (evt. døgnmåling) som egen melding i et EDIFACT eller
XML- format, vil dette henholdsvis gi dobbelt så mye volum (og dermed
overføringstid) for EDIFACT og over 20 ganger så mye volum for XML når det gjelder
måleverdier. For nettleie vil ikke forskjellene bli så store mellom EDIFACT og de
beregnede løsningene fordi det er avsatt et betydelig volum for fritekst i figurene under
– noe som bortfaller ved standard formater. For XML vil behovet imidlertid bli ca det
tidobbelte av det som er beregnet for nettleiedelen. Meldingsformat vil ha stor
betydning på dimensjoneringen av løsningen.
107

9.4.2.1 Datainnhold i forsendelser av måleverdier
Oversendelse av måleverdier må inneholde:
Tidspunkt for forsendelse
Målepunkt ID
Måleverdier: måleverdi, status-flagg
Oversendelsen fra nettselskapet kan være i form av en tabell med et hode med felles
informasjon og en linje per Målepunkt ID. Figuren nedenfor illustrer hvordan en slik
tabell er antatt oppbyggd.
Figur 46 - Informasjonsinnhold i en måleverdiserie
For timeavregning er N=24, mens med avlesning per kvarter er N=96. Plassering i
tabellen er periodenummer fra kl. 00. Ved innsending flere ganger per dag trengs det et
ekstra dataelement som forteller hvilket periodenummer måleserien starter med.
Rapporteringsfrister:
Innen kl. 09:00 D+1: VEE-justerte data målerverdier (som angitt over) fra alle
målere skal være tilgjengelig sentralt innen kl. 09:00 dagen etter avlesningsdag.
Innen kl. 24 D+5: Eventuelle tall som av eller annen grunn er justert etter «D»,
skal sendes på nytt og være tilgjengelig sentralt innen kl. 09:00 fem dager etter
avlesningsdag.
Innen M+3: Eventuelle tall som av eller annen grunn er justert etter «5+D», skal
sendes på nytt og være tilgjengelig sentralt innen kl. 09:00 tre måneder etter
avlesningsdag.
Innen ∞: Eventuelle tall som av eller annen grunn er justert etter «3+M», skal
sendes på nytt så fort som mulig.
9.4.2.2 Fakturagrunnlag for nettleie
Kontaktinformasjon overfor sluttkunde håndteres utelukkende av kraftleverandørene.
Dagens avregningsmodell og tariffmodeller beholdes til å begynne med til den nye
tjenesten er fullt utrullet.
Nettselskapene skal utarbeide komplett fakturagrunnlag til kraftleverandøren for
nettjenestene inklusive offentlige avgifter. Kraftleverandøren inkluderer dette
fakturagrunnlaget i sin faktura til sluttkunde.
Oversendelsen fra nettselskapet kan være i form av en tabell med et hode med felles
informasjon og en linje per Målepunkt ID. Figuren nedenfor illustrer hvordan en slik
tabell er antatt oppbygget.
108

Figur 47 -Informasjonsinnhold i fakturagrunnlaget for nettleie
Det må være flere fakturalinjer per målepunkt avhengig av nett-tariffen med en
typebetegnelse som viser hva beløpet gjelder og en forklarende tekst. Utvalg av typer
fakturalinjer har utgangspunkt i en fremtidig situasjon med differensierte tariffer for
ulike tidsperioder over døgnet og at sluttkunden kan levere netto kraft i perioder.
9.4.2.3 Balanseavregning
Balanseavregning skal gjennomføres en gang per dag for foregående dag og innebærer
rapportering av akkumulerte tall. Det innebærer at rapporten som sendes fra
nettselskapet til alle balanseansvarlig, evt bare til dem som har levert strøm til
målepunkt i nettselskapet. Rapporten inneholder akkumulert kraftuttak pr dag-periode
pr nettselskap. Selve informasjonsmengden pr melding tilsvarer daglig innsendte
måleverdier for en Målepunkt ID i volum og skal sendes fra 130 nettselskap til
maksimalt 130 balanseansvarlige.
9.4.2.4 Oppslag
Figur 48 - Informasjonsinnhold i balanseavregningen
Det er antatt et oppslagsvolum på opp mot en million kraftleverandør bytter /
endringsprosesser samt et oppslag pr Målepunkt ID på 10 millioner pr år (fire oppslag
pr ID). Gjennomsnittlige datautvekslingsbehov vil, hvis 2 kB antas som
gjennomsnittsvolum pr transaksjon, ligge på 22 GB. Dette tallet er relativ beskjedent
sammenlignet med de andre transaksjonstypene. Denne type oppslag bør likevel helst
strekke seg relativt jevnt ut i tid. I tillegg kommer informasjonsutveksling som følge av
oppdatering av registerdata (måler, sluttbruker, kraftleverandør, etc.).
9.4.3 Nye eller endrede felles tjenesteprosesser
9.4.3.1 Sentrale prosesser
Kvalitetssikring av data inklusive estimering av manglende eller usannsynlige
måleverdier forutsettes utført av nettselskapene i forbindelse med innsamling av
måleverdier gjennom AMS innsamlingssystem. For alle scenarier forutsettes det at
109

nettselskapene oversender kvalitetssikrede data, eventuelt korreksjoner til tidligere
oversendte data. Følgende tjenester kan bli endret eller bli etablert som nye tjenester
og/eller forretningsprosesser:
Leverandørskifte: Ved leverandørskifte må kraftleverandøren innhente
nøkkeldata fra vedkommendes nettselskap. Dette gjøres i dag gjennom NUBIX,
men dette kan forenkles med sentralt oppdatert register/katalog.
Fellesfakturering: Selve faktureringen er en ganske standardisert prosess og ikke
egentlig gjenstand for noe konkurransefortrinn mellom kraftleverandørene.
Stordriftsfordel og likebehandling kan spille inn som faktorer for å sentraliser
denne funksjonen.
Oppslag: Det vil være behov for betydelig volum av oppslag av måleverdier og
andre data på tvers av kraftleverandører og nettselskap.
9.4.3.2 Mulige tjeneste-prosesser rettet mot sluttbruker
Tjenester til sluttbruker:
Forbruksstatistikk: Mange forbrukere vil etter hvert ønske seg sitt forbruk
representert på et format som de kan lese hvor/når de vil og selv eventuelt
tilpasse og etterbehandle
Struping av enkeltpunkt: Det er lagt opp til at nettselskapene skal kunne strupe
hver enkelt måler basert på forbruksmekanismer regulert i gjensidige avtaler. På
sikt kan det være at struping skal kunne foregå forbi hvert målepunkt.
Formidling av pris/tariffer: Pris og tariffering forventes etter hvert å følge
markedet ellers i Europa. Forbrukeren vil være interessert i å vite – eller enda
bedre – la sitt kraftforbruk styres av slike tariffer og dynamiske priser.
Visning av sanntidsforbruk: Et display som viser forbruk i sanntid når/hvor
brukeren ønsker dette, forventes å bli viktig
9.4.4 Beregnings-caser
Kapasitetsberegningene må, som vist i tabellen under, innbefatte de tre kjerneprosessene
og gjennomføres for hver av de fire tjenesteprosessene beskrevet i kapittel 9.4.3.
Kjerneprosessene i en sentral hub er de to kommunikasjonsprosessene og er beskrevet i
kapittel 9.3. I tillegg kommer behov for lagringskapasitet. Denne er tatt med fordi den er
sett på som absolutt nødvendig for den nye modellen. Dette gir totalt sett en
kombinasjon av tolv tjenesteprosesser prosesser og tekniske prosesser.
Kommunikasjon Prosessering Lagring
Målerverdi-innsamling inn til og ut fra hub i hub i hub
Fakturerings-grunnlag inn til og ut fra hub i hub i hub
Balanse-avregning inn til og ut fra hub i hub i hub
Tilfeldige oppslag inn til hub i hub i hub
110

Tre løsningsmuligheter er beregnet:
Tabell 16 - Beregnings-caser
Kommunikasjonshub: Dette er en enhet som er i stand til å ta imot meldinger,
lagre disse lokalt for en kort periode, foreta eventuelle nødvendige formatkonverteringer
og videresende disse til riktig mottager
Meldingsformidlingshub: Dette er en sentral hub med et målepunkt-ID-register
og funksjonalitet til å splitte meldinger fra nettselskap og videresende data til
riktig kraftleverandør basert på målepunkt-ID. (I praksis er dette en mellomting
mellom kommunikasjonshub og datahub.)
Datahub: Denne har en sentral database hvor måleverdier og annen data
struktureres og med funksjonalitet for å behandle disse dataene og formidle dem
til dem som trenger denne informasjonen. Andre fellesfunksjoner kan i tillegg
legges til denne huben.
9.4.5 Løsningsforutsetning
9.4.5.1 Datahub
Foruten den sentrale huben, vil løsningen være avhengig av samspillet med løsningene
hos nettselskapene og kraftleverandørene. Det må settes krav til løsningene hos disse.
Disse kravene må både være relatert til format på data og transaksjoner og til
dimensjonering og tilgjengelighet. Kraftleverandørene og nettselskapene må forplikte
seg på å leverer løsninger med tilstrekkelig opptid mot felles tilknytningspunkt i nettet
(som NIX eller felles peer-punkt).
De elementene som må settes opp og dimensjoneres for riktig volum er (ref tabellen
nedenfor):
System
Hosting
Infrastruktur
Nettverk
Servere
Lagring
Beskrivelse
Støvfritt datarom med tilstrekkelig fysisk sikring, redundant strøm og kjøling samt
overvåking av miljøfaktorer
Riktig dimensjonert lokalt nett, perimetersikring, beskyttelse mot inntrengning
Redundant 100 Mbps linje med garantert kapasitet for overføring
Det er forutsatt en redundant kjerne basert på kapasitet tilsvarende 1,8 Mtcp
(referanse fra fotnote 11 er en HP ProLiant DL580 G7 – på samme sted er tcp
(Transaction Processing Performance) som benevnelse på transaksjons-kapasitet
beskrevet). Det er imidlertid lagt på et påslagsfaktor på 3 for å ta høyde for at
serveren vil måtte håndtere andre oppgaver som overhead og grensesnitt.
Det må i tillegg finnes kapasitet til for front-end og databaseserver
Løsning med redundant (lastdelt eller speilet) 20 TB datalagring med full back-up og
11
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster&versi
on=5%&currencyID=0
111

System
DBMS
Støttesystemer
Beskrivelse
med «restore» implementert både løsnings- og rutinemessig
MS SQL er brukt for i tcp-referansen (se over), men her må databaseteknologien
(Oracle og andre vil være like aktuelle) tilpasses den applikasjonen og miljøet det
skal stå i
Systemer som identitetssystem, tilgangskontroll samt mekanismer for beskyttelse av
data over åpne systemer som internett
Tabell 17 - Løsningsforutsetning – datahub
De fem første elementene er anslått å koste ca 20 MNOK (hosting 1 MNOK, Nett 0,4
MNOK, server 10,8 MNOK, lagring 3,8 MNOK, DBMS 2,8 MNOK, støttesystemer 2,0
MNOK) i investering og ca 5 MNOK i årlig drift/vedlikehold. Det er fullt mulig å
bygge sentral infrastruktur med høyere kapasitet, men priskurven for ytterlige skalering
er relativt bratt. Den foreslåtte konfigurasjon er valgt ut fra en grov kost-nytte
vurdering. Det er viktig å poengtere at utvikling og vedlikehold av applikasjonene vil
være kostnadskrevende og er ikke medtatt i anslagene over.
9.4.5.2 Kommunikasjonshub
Foruten den sentrale huben, vil løsningen være avhengig av samspillet med løsningene
hos nettselskapene og kraftleverandørene. Det må settes krav til løsningene hos disse.
Disse kravene må både være relatert til format på data og transaksjoner og til
dimensjonering og tilgjengelighet. Kraftleverandørene og nettselskapene må forplikte
seg på å leverer løsninger med tilstrekkelig opptid mot felles tilknytningspunkt i nettet
(som NIX eller felles peer-punkt).
De elementene som må settes opp og dimensjoneres for riktig volum er:
112

System
Hosting
Nettverk
Servere
Beskrivelse
Støvfritt datarom med tilstrekkelig fysisk sikring, redundant strøm og kjøling samt
overvåking av miljøfaktorer
Redundant 100 Mbps linje med garantert kapasitet for overføring
I kjernen er det forutsatt en kjerne basert på kapasitet tilsvarende 1,8 Mtcp (referanse
fra fotnote 12 er en HP ProLiant DL580 G7 – på samme sted er tcp som benevnelse på
transaksjons-kapasitet beskrevet) .
Det er imidlertid lagt på et påslagsfaktor på 3 for å ta høyde for at serveren vil måtte
håndtere andre oppgaver som overhead og grensesnitt.
Det må i tillegg finnes kapasitet til for front-end og databaseserver
Tabell 18 - Løsningsforutsetninger - Kommunikasjonshub
Disse elementene er anslått å koste ca 12 MNOK i investering (hosting 1 MNOK, Nett
0,4 MNOK, server 10,8 MNOK,) og ca 4 MNOK i årlig drift/vedlikehold. Løsningen
vil måtte ha samme linjekapasitet og serverkapasitet i kjernen som datahuben. Det er
neppe behov for database eller omfattende lagringskapasitet, men noe kapasitet for
buffring og loggføring.
9.4.6 Kapasitetsberegninger
De konkrete kapasitetsberegningene er mer detaljert gjort rede for i vedlegg F.
Beregningene er gjort ved å ta utgangspunkt i den meldingsstrukturen som er beskrevet
i kapittel 9.4 med meldingsinnhold, meldingshode, en antatt XML-overhead og
overhead for kommunikasjon (TCP/IP) og krypteringssesjoner (TSL).
For å få et balansert bilde av overhead-påvirkning er det også gjort en fordeling av
nettselskap med hensyn på kundemasse som vist i tabellen under (fra NVE).
Antall
nettselskap
Gjennomsnittlig
antall Målepunkt ID
Antall Målepunkt
ID pr gruppe
Totalt antall
Målepunkt ID
6 100000 + 305 000 1 830 000
18 20000-100000 30 500 549 000
106 0-20000 3 029 321 074
130 2 700 074
Tabell 19 - Fordelingsmatrise
Det er også antatt at det sendes og prosesseres 25% ekstra meldinger for korrigering av
måleverdier etter første innrapporteringstidspunkt.
Tabellen under viser rent teoretiske beregningsresultat. Tabellen viser:
12
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=noncluster&versi
on=5%&currencyID=0
113

Kommunikasjon: Tid i minutter for overføring av hele det beregnede
datavolumet på en 100 Mbit/s linje forutsatt at hele kapasiteten (med overhead)
benyttes til den beregnede overføringen og at trafikken flyter helt jevnt i
perioden.
Prosessering: Tid i minutter for prosessering av en «batch» (dvs. målestandene
pr dag, balanseavregningene pr uke og nettleieunderlag pr måned).
Prosesseringene er basert på at hver linje i meldingene kan håndteres som en
transaksjonen i systemet. Dette setter krav til programvare som skal håndtere
disse meldingsvolumene. Det forutsettes også at det er tilstrekkelig kapasitet i
front-end servere og database servere til at hoved-serveren ikke belastes med
grensesnitthåndtering, tung buffring, og databasehåndtering. Det forutsettes
videre at hoved-serveren har en kapasitet tilsvarende 1,8 millioner transaksjoner
per minutt som angitt i referansene i tabellene over.
Alternativ↓
RESSURSER↓
Måleverdi-
innsending
Data
til
hub
Data
fra
hub
Balanseavregning
Data
til
hub
Data
fra
hub
fakturering
s-underlag
nett
Data
til
hub
Data
fra
hub
Andre
Tilfeldige
oppslag
Datahub
Kommunikasjon 13 1,4 1,4 < 1 < 1 12 12 kontinuerlig
Prosessering 14 4,5 < 1 45 kontinuerlig
Lagring (GB/år) 89 1 79 -
Meldings-hub
Kommunikasjon 1,4 1,4 < 1 < 1 12 12 kontinuerlig
Prosessering 9 < 1 90 kontinuerlig
Lagring (GB/mnd) 8 1 7 -
Kommunikasjonshub
Kommunikasjon 2,0 2,0 < 1 < 1 15 15 kontinuerlig
Prosessering < 1 < 1 < 1 kontinuerlig
Lagring (GB/år) - - - -
Tabell 20 - Kapasitetsberegninger (minimum) – teoretisk kapasitet i minutter (og GB for lagring)
Det er anslått at en transparent kommunikasjonsløsning vil kreve opp mot 20% ekstra
kommunikasjonskapasitet (sammenlignet med datahub). Denne ekstrabelastningen
kommer fordi det antas at antall sesjoner blir såpass høyt at stabile krypterte
forbindelser ikke vil opprettholdes og at det derfor må påregnes sesjonsoverhead for
hver ny kryptert forbindelse. Prosesseringsbehovet ville bli neglisjerbart og
lagringsbehovet begrenset til eventuell log.
13 Angitt i minutter basert på jevn, feilfri overføring over en dedisert 100 Mb/s linke
14 Angitt i minutter basert på en 1,8 Mtcp kapabilitet
114

For datahub- og meldingshub-alternativet er volumet gitt ved at:
Håndteringsvolumet pr dag (målerverdier) er ca 250 MB
Håndteringsvolumet pr dag (balanse) er ca 20 MB
Håndteringsvolumet pr mnd. (nettleie) er ca 2 GB
Som det fremgår av tabellen, vil kommunikasjonsbehovet bli minst for en datahub;
måleverdidata kan overføres på under to minutter i alle tilfeller, mens
faktureringsunderlag for nettleie kan overføres på ca 12 minutter. I praksis bør det settes
av opp mot en time for å ta høyde for ujevnheter og feilhåndtering.
Prosesseringsbehovet er imidlertid høyere for en meldingshub enn for en datahub fordi
systemet må foreta ”omfletting” av meldingene i tilnærmet sanntid. For nettleiedelen
børe det settes av 4 timer for dette for å ta høyde for ujevnheter og feilhåndtering
(teoretisk minimum er 1,5 timer som vist i tabellen).
9.4.7 Kapasitetsimplikasjoner og systemimplementering
Ut fra beregningene er følgende kapasitetsmessige vurderinger er gjort:
Målerdata: Håndtering av de daglige målerverdiene regnes som de mest kritiske
fordi tidskravet her er høyt. All data skal være tilgjengelig kl 0900. For datahubløsningen
hvor det teoretisk sett vil ta 2 minutter å overføre data og 5 minutter å
prosessere disse, bør det avsettes minst en time for den sentrale håndteringen.
Fordi disse data er prioriterte, bør det, så langt det er mulig, implementeres
mekanismer for prioritering av slik at målerverdidata får godt over halvparten av
de tilgjengelige ressursene både i nettverket og serverne. Prosessering kan delvis
gå parallelt med mottaket av data, men det anbefales at det settes av en time til
håndtering av datamottak for å ta høyde for transmisjon og prosessering med
håndtering av ujevnheter og feil. Tilsvarende bør det kunne settes av en time for
kraftleverandørenes uthenting av sine data. Dette vil for sentral hub bety at
nettselskapene må tilgjengeliggjøre sine data innen kl. 0700, mens
kraftleverandørene kan hente ut sine data mellom kl. 0800 og 0900. For en
transparent kommunikasjonshub vil kravet til sentral håndtering være lavere,
men overhead er noe høyere, slik at de samme tidsbetraktningene bør gjelde.
Balansedata: Disse overføringene og transaksjonene går en gang pr dag.
Datamengden er relativt ubetydelige bare 10% av batch-volumet til måledata og
kun 1% av volumet for nettleiegrunnlag. Det er imidlertid viktig at balansedata
ikke stjeler kapasitet fra de daglige overføringene i den grad dette blir kritisk.
Faktureringsunderlag for nettleie: Disse overføringene og transaksjonene er i
beregningene forutsatt å gå kun en gang i måneden, men datavolumet er stort –
ca 10 ganger så stort som volumet av måleverdiene. Overføring kan eventuelt
vurderes stykket opp slik at ulike selskaper sender på ulike tider. Hvis alle
nettselskapene sendte sine data i forbindelse med overføring av måleverdiene
innenfor samme tidsperiode, ville transmisjonskapasitet måtte økes. Det bør
derfor unngås at innsending av disse data skjer samtidig med fristen av
innsending av måleverdier.
Bruk av prioritering, skedulering – eventuelt i kombinasjon med aktiv bruk av lastdeling
bør vurderes i løsningen for å håndtere situasjoner hvor både måleverdi-, balanse- og
nettleie-trafikk eventuelt kommer samtidig.
115

9.5 Sårbarhet
9.5.1 Overordnede betraktninger
Implementeringsrisiko ved de forskjellige løsningene er gjort på et helt overordnet nivå.
Sikkerheten er vurdert ut fra tre kriterier:
Integritet, dette beskriver i hvilken grad man kan stole på innholdets nøyaktighet
Konfidensialitet, dette beskriver i hvilken grad man kan stole på at bare
autorisert personell får tilgang til informasjonen
Tilgjengelighet, dette beskriver i hvilken grad løsningen er tilgjengelig i ønsket
tidspunkt/utstrekning
Kun sikkerhet rundt informasjon og infrastruktur er vurdert.
Det er primært tre områder som er vurdert i forhold til sårbarhet:
Prosesser: Dette er de aktuelle kjerneprosesser, felles forretningsprosesser og
prosesser rettet mot sluttledd
Informasjon: Informasjon er kategorisert i gruppene måleverdier,
anleggsinformasjon (inklusive informasjon om sluttbruker / anleggseier ,
selskapsinformasjon (adresser, fullmakter, etc.) og nett-tariffer (fakturagrunnlag
- nettleie).
Fysisk infrastruktur: Den fysiske infrastrukturen i sentral datahub omfatter
database, lagring, servere, støttesystemer (adressetabeller for ruting av trafikk,
loggfunksjoner, autentisering og autorisasjon, etc.), LAN (lokalnett som binder
alle hubens elementer sammen) samt WAN som omfatter internett og
linjetilknytning (kapasitet) fra alle aktører inklusive den sentrale huben.
Modellen er vist i følgende figur:
9.5.1.1 Prosessene
Figur 49 - Informasjons-, prosess-, og infrastruktur-modell
Det er primært fire prosesser som er belyst i denne analysen:
Målerverdi-innhenting som er avhengig av dataelementene; måleverdier,
anleggsinformasjon
Nettleiefaktureringsunderlag-innhenting som er avhengig av dataelementene;
måleverdi, nettselskapsinformasjon og anleggsinformasjon
116

Balanseavregning som er avhengig av dataelementene; måleverdier (og
forpliktet uttak / leveranse som ikke kommer tilsyne i denne modellen)
Oppslag som på sikt vil være avhengig av alle dataelementene
9.5.1.2 Informasjon
De fem dataelementene er beskrevet i sin sammenheng over, men er:
Måleverdier
Anleggsinformasjon
Leverandørinformasjon
Nettselskapsinformasjon
Nett-tariffer
9.5.1.3 Infrastruktur
Den infrastrukturen som er antatt brukt er beskrevet i kapittel 9.4.5.
9.5.2 Sårbarhetsvurderingen
Sårbarhetsanalysene under er gjort for infrastruktur som er påkrevet for å realisere
sentral datahub og kommunikasjonshub. Vurderingen er gjort med utgangspunkt i en
gitt infrastruktur for begge løsningene og for en gitt informasjon.
Terminologien som er benyttet i sårbarhetsanalysen er:
System: Dette er en samling av del-systemer som beskrevet i kapittel 9.4.5
Trussel: Dette er tenkt trusler som kan utløse uønskede hendelser mot systemet
Årsak: Dette er grunnen til eller motivasjonen bak en hendelse
Virkning: Dette beskriver hvordan en faktisk hendelse vil virke inn på
virksomheten
Kategori: Tre kategorier er benyttet:
o I: Integritet
o K: Konfidensialitet
o T: Tilgjengelighet
Konsekvens: Dette er konsekvensen av en faktisk hendelse kategorisert som;
Svært-Høy, Høy, Middels, Lav, Svært-Lav
Sannsynlighet: Dette er vurdert sannsynlighetskategori for at en hendelse
inntreffer; Svært-Høy, Høy, Middels, Lav, Svært-Lav
Risiko: Dette er kombinasjonen av sannsynlighet og konsekvens
Det er viktig å understreke at sårbarhetsvurderinger ofte gjøres på bakgrunn av
eksisterende prosesser og eller system. Slike finnes ikke i dette tilfellet. Grunnlaget for
evalueringene er gjort på bakgrunn av systemantagelesene i kapittel 9.4.5.
Det er brukt en ganske vid skala både for konsekvens og for sannsynlighet. Dette
fremkommer under.
Konsekvens:
1. Svært høy: Kritiske funksjoner nede en uke, omfattende feilfakturering, utstrakt
utilsiktet struping av anlegg og/eller langvarige negative medieoppslag
117

2. Høy: Kritiske funksjoner nede i en dag, noe feilfakturering, noe utilsiktet
struping av anlegg og/eller noe negative medieoppslag
3. Middels: Kritiske funksjoner nede i en time
4. Lav: Redusert funksjonalitet i en time
5. Svært lav: Redusert funksjonalitet i inntil fem minutter
6. Ingen: Ingen konsekvens
Sannsynlighet:
1. Svært høy: inntreffer 37 ganger pr år med utstrekning på 24 timer hver gang (ca
10% nedetid)
2. Høy: inntreffer 11 gang pr år med utstrekning på 8 timer (ca 1% nedetid)
3. Middels: inntreffer 2 gang pr år med utstrekning på 4 timer (ca 0,1 % nedetid)
4. Lav: inntreffer 1 gang pr fjerde år med utstrekning på 2 timer (ca 0,01 %
nedetid)
5. Svært lav: inntreffer 1 gang pr tiende år med utstrekning på 1 time (ca 0,01 %
nedetid)
6. Aldri: skjer ikke noen gang
I praksis vil en riktig dimensjonert løsning befinne seg omtrent i midten av disse
skalaene. Konsekvens kan være vanskelig å påvirke. Sannsynlighet må derfor
brukes som justeringsparameter for at en skal holde seg innenfor rammen på riktig
kostbasert risiko.
Ideelt sett skal hver hendelsestype brytes ned å behandles hver for seg. Med ca 80
systemscenarier, hver med 1-6 ulike hendelsesforløp som kan ha ulike virkninger og
sikkerhetskategoriseringer, blir en detaljanalyse ganske omfattende. Vedlegg 2 gir
en tabellarisk oversikt basert på en viss grad av aggregering. Denne aggregeringen
går ut på at kun hendelsene som ansees å ha høyest sannsynlighet og størst
konsekvens hensyntas, mens de andre ikke vurderes. Før en konkret implementering
bør det foretas en formell ROS-analyse hvor alle de ulike systemscenarier
analyseres hver for seg og avveies.
Figuren under (9) viser hvordan de to løsningsalternativene (datahub og kommunikasjonshub)
er vurdert på et svært overordnet nivå sett fra et infrastrukturperspektiv
og fra et informasjonsperspektiv.
118

Figur 50 - Svært overordnet presentasjon av aggregert risiko for datahub og kommunikasjonshub
Som et fremgår av den aggregerte oversikten, er konsekvensene ved feil høyere med
alle funksjoner sentralisert (datahub) enn for tilfellene med desentrale funksjoner
(kommunikasjonshub). Sannsynligheten for at deler av systemet blir berørt av feil er
imidlertid høyere med en desentral løsning: Sannsynligheten for at en av 130
nettforbindelser eller en lokal databaser er nede til enhver tid er ganske høy.
Vedlegg G redegjør for detaljene i sårbarhetsanalysen.
9.5.3 Konsekvenser for realisering av løsninger
Hva som må ivaretas ved utforming av løsninger for å oppnå akseptable sikkerhet er
oppsummert nedenfor.
9.5.3.1 Datahub
Tilgjengelighet: Full redundant system med doble kommunikasjonslinjer, servere og
lagringsløsninger er ansett nødvendig for å sikre oppetid på over 99,5% ende-til-ende. I
og med at man gjennom en datahub har en sentralisert løsning med gode muligheter for
overvåkning og eventuell sanksjonering, kan det være lettere å «diktere» kravene til
oppetid. Alle enkelt-komponenter bør i utgangspunktet ha en oppetid på eller over
99,9%. Med riktig grad av dublering og parallellitet bør en totaloppetid på 99,5% (endetil-ende)
dermed kunne oppnås i praksis.
Konfidensialitet: Tilgangsstyring på flere nivåer er nødvendig og den bør legges til
datahuben for å styre tilgangen til nettselskapene og for eksterne. Tilgangsstyring må
administreres sentralt og med autentisering og autorisering av tilgang spesifisert minst
ned på det enkelte nettselskap. Slik tilgangskontroll må finnes både på infrastrukturnivå
119

(nett) og i forhold til informasjon (databasenivå). Inntrengningssikring fra eksterne og
interne ressurser må være på plass
Integritet: Det er viktig å sikre seg mot prosessuelle feil i håndtering. Kvalitetskrav til
data bør settes og det bør foretas logging som kan gi entydig og uomtvistelig
informasjon om hvem som har endret data og når det ble gjort. I tillegg må det finnes
tilgangsstyring både på infrastrukturnivå (nett) og i forhold til informasjon
(databasenivå) som beskrevet ovenfor. Det må skilles mellom rettigheter til å
skrive/endre og rettigheter til kun å kunne lese data. Inntrengningssikring fra eksterne
og interne ressurser må være på plass. Det er viktig med et kvalitetssikringsregime
knyttet til endringskontroll og systemutvikling.
9.5.3.2 Kommunikasjonshub
Tilgjengelighet: Fullt redundant system med doble kommunikasjonslinjer og servere
kreves for de sentrale komponenter på samme måte som for datahub. Alle
enkeltkomponenter bør i utgangspunktet ha en oppetid på eller over 99,9%. Med riktig
grad av dublering og parallellitet bør en totaloppetid på 99,5 % (ende-til-ende) i praksis
kunne oppnås. Med 130 nettverksselskap, mange av dem ganske små, er det en ganske
høy sannsynlighet for at minst ett av avgiversystemene ikke er tilgjengelig, enten fordi
deres kommunikasjonslinje er nede eller fordi de lokale servere / databaser er nede.
Detaljert overvåkning og sanksjonering vil være vanskeligere i en løsning med desentral
kommunikasjonshub med mindre det legges inn sentralisert verktøy og prosesser for
dette.
Konfidensialitet: Tilgangsstyring på flere nivåer er nødvendig for den sentralisert
løsningen. Systemet vil kunne ha et kontrollregime som kontrollerer hvem som har
rettigheter til å sende meldinger til det enkelte selskap og hvilke disse kan sende.
Informasjon som utveksles beskyttes gjennom mekanismer knyttet til
meldingsformidlingen. Øvrig tilgangsstyring både til infrastruktur og informasjon hos
nettselskapene må implementeres av hvert enkelte selskap. Inntrengningssikring fra
eksterne og interne ressurser må være på plass lokalt for hver av disse. Disse
mekanismene er komplekse og blir ikke nødvendigvis ivaretatt av en rekke små aktører
uten IKT som hovedfokus. De svakeste leddene i et slikt verdinett vil være
bestemmende for den overordnede konfidensialiteten i løsningen.
Integritet: Det er viktig å sikre seg mot prosessuelle feil i håndtering. Kvalitetskrav til
data bør settes, og det bør foretas logging som kan gi entydig og uomtvistelig
informasjon om hvem som har endret data og når det ble gjort. I tillegg må det finnes
tilgangsstyring både på nettverksnivå og knyttet til drift og det må etableres et godt
regime for endringskontroll for sentral infrastruktur og systemer. Omfanget av slike
komponenter vil være mindre for hver aktør enn for den sentrale datahuben, men
koordinering av disse løsningen vil gjøre totalløsningen med kompleks.
Inntrengningssikring fra eksterne og interne ressurser må være på plass.
9.6 Evaluering
Evalueringen er delt i to:
Evaluering ut fra de praktisk / økonomisk egnethet til de to scenarier
Evaluering i forhold til de formelle evalueringskriteriene
120

9.6.1 Evaluering ut fra praktisk / økonomisk egnethet til de to scenarier
Nedenfor følger SWOT analyse av de to hovedalternativene.
SWOT analyse for kommunikasjonshub
Styrker
Betydelig grad av gjenbruk (dagens KIS og
EDIEL meldinger) gir redusert risiko for
feilsituasjoner
Sentral kontroll med adressater og
meldingsformater, evt formatkonvertering gir
lav risiko for innbrudd via hub-grensesnittet og
for feil med meldings-formater.
Hackere må forholde seg til mange ulike
lokale løsninger, dvs høy barriere for
sabotasje/ innbrudd på tvers av nettselskap
Loggføring fører til at det er enklere å justere
for mangler og feilsituasjoner
Utvidelse av kjent modell, aktørene kan bygge
videre på eksisterende kompetanse for å takle
problemsituasjoner
Færre nye funksjoner og gjenbruk av dagens
løsninger kan gi lavere implementeringsrisiko
enn for datahub, men vanskelig å kontrollere
fordi mye av ansvar for utvikling og
tilpasninger er overført til nettselskapene
Svakheter
Vanskelig å måle kvalitet på måleverdier og
risiko for feil i datautveksling mellom
kraftleverandør og nettselskap.
Daglig innsending av målerdata gir 20%
høyere belastning på kommunikasjonskanalene
enn datahub
Dataoverføring fra 130 nettselskaper for
balanseavregning gir ekstra
høybelastningsperiode mot sentral hub
Dersom huben feiler/ faller ut, vil hele
bransjen bli berørt. Eksponeringen er like
alvorlig som for datahub
Krevende å ha god nok oppetid (24/7) på
datasystemene hos samtlige 130 nettselskap
Stor avhengighet av at 130 nettselskaper gjør
alt likt, holder tilstrekkelig datakvalitet og
overholder tidsfrister
Potensielle sikkerhetshull ved at nettselskap
må ha egen tilgangskontroll mot sluttkunder
og tredjepart
Alle endringer må implementeres hos alle 130
nettselskap
Muligheter
Løsningen kan gjenbrukes i en senere utvikling
av datahub
Antall lokale løsninger kan reduseres ved at
nettselskaper kan samarbeide for å søke
stordriftsfordeler
Sikkerhet og sårbarhet kan forbedres ved å
opprette en kompetent, sentral
driftsorganisasjon for kommunikasjonshuben
Kontroll med nye dataelementer og nye eller
endrede meldinger kan forbedres i forhold til
dagens situasjon
Trusler
Det vil alltid eller ofte være ett eller flere
nettselskap som ikke klarer kvalitetskravene.
Risiko for redusert ytelse ved uthenting/
sending av måledata, balanseavregning og
avregningsgrunnlag for nettleie
Betydelig sannsynlighet for brudd på
oppetidskrav 24/7 hos ulike nettselskaper
Feil teknologivalg, spesielt i sentral
kommunikasjonshub
Endring av forskrifter/ og nye prosesser må
implementeres hos alle nettselskaper
Tabell 21 - SWOT analyse for sikkerhet ved løsningen med kommunikasjonshub
121

SWOT analyse for datahub
Styrker
Svakheter
Datahuben kan gjennomføre kvalitetskontroll,
og overvåke innsending av data iht krav - lav
feilfrekvens
Høy grad av tilgjengelighet av data som skal
deles
Balanseavregning gjøres på grunnlag av
sentralt lagrede måledata - reduserer
datautvekslingsbehov (reduserer risiko for feil
og ytelsesproblemer)
Forenklet forretningslogikk - lavere feilrisiko
Rask identifikasjon og oppretting av feil og
mangler
Felles systemer for tilgangskontroll fra
internett gir større sikkerhet og lavere
implementeringsrisiko.
Vil innebære større grad av fornyelse og
modernisering enn tilfellet med
kommunikasjonshub
Mye av utviklingene legges til fellesprosjekt
med høy grad av profesjonalitet
Store krav til robust og sikker løsning. Dersom
huben feiler/ faller ut, vil hele bransjen bli
berørt. Løsningen er mer kompleks enn
kommunikasjonshub og sannsynlighet for
problemer er større
Daglig innsending av målerdata og utveksling
av fakturagrunnlag for nettleie gir stor
belastning over korte tidsperioder og omfatter
database og prosessering i tillegg til
datakommunikasjon
Krever stort felles prosjekt med betydelig
overhead som følge av samarbeid. Kan gi lang
implementeringstid, høy eksponering
Muligheter
Kan bygges gradvis ut med nye felles
funksjoner. Sentral avregning av nettleie vil
forenkle systemløsning og redusere
høybelastningsperioder.
Lett å endre grensesnitt mot kraftleverandør og
sluttkunde uten å endre mot nettselskap - gir
redusert implementeringsrisiko for endringer
Endringer (f.eks. forskriftsendringer som
krever prosessendring) kan gjøres ett sted -
lavere implementeringsrisiko
Sterkt sentralt fagmiljø kan minske sårbarhet
(24/7 support)
Løsningene kan dimensjoneres og sikres bedre
sentralt enn for kommunikasjons-hub
Trusler
Risiko for redusert ytelse ved uthenting/
sending av måledata, balanseavregning og
avregningsgrunnlag for nettleie
Risiko for brudd på oppetidskrav (nær 100 %)
- store konsekvenser
Feil teknologivalg for datalagring og
prosessering i tillegg til data-kommunikasjon
Datahuben blir stor og rigid som kan bety liten
fleksibilitet og endringsdyktighet
Implementeringsrisiko ifm prosjekt for
etablering av datahub (stort IT-prosjekt) høy
grad av eksponering.
Tabell 22 - SWOT analyse for sikkerhet ved løsningen med datahub
Analysene viser at det er fullt mulig å implementere en tilfredsstillende totalløsning
med begge modellene.
Kravene til kapasitet og sikkerhet for håndtering av datautvekslingen vil være noe
tyngre for en desentral løsning enn for en sentral løsning (datahub). Datahuben vil
imidlertid ha tilleggskrav knyttet til en stor database og ulike støttefunksjoner for
forretningsprosessene. Kapasitetsberegningene viser at daglig innrapportering av
måleverdier teoretisk kan gjennomføres på rundt 10 minutter for begge scenarier. I
praksis forventes dette å ta betydelig lengre tid. Det bør settes av 2 timer for hele kjeden
fra nettselskap via hub fram til leverandørene for å ta høyde for tilfeldige avbrudd,
toppbelastninger og feilhåndtering.
122

Den tyngste belastningen på løsningene vil være utveksling av faktureringsgrunnlag for
nettleie som teoretisk vil kreve 12 minutter for datahub og nærmere 16 min for
kommunikasjonshub, dersom dette gjøres konsentrert en gang per måned. Ved ulike
former for skedulering, kan trafikken spres. Beregning av fakturagrunnlag i datahuben
basert på måleverdiene i databasen der, vil føre til vesentlig redusert behov for å sende
data. Prosesseringsmessig vil håndteringen av disse volumene teoretisk kreve 1 ½ times
”regning” i huben. I praksis bør det settes av tid for feilhåndtering og ujevnt påtrykk.
Det bør settes av minst en time for kommunikasjon for datahub-løsningen og 1 ½ time
for kommunikasjonshub. Prosesseringen kan delvis foregå i parallell, men det bør settes
av ca 3 timer for datahub-modell og innpå det dobbelte for en kommunikasjonshubmodell.
For en helt transparent kommunikasjonshub vil prosesseringsbehovet være
vesentlig mindre enn for begge disse alternativene.
Datahuben bør ha et felles system for tilgangskontroll. I en desentral modell må
tilgangskontroll implementeres i hvert nettselskap, noe som kan skape sikkerhetshull.
Risiko knyttet til en sentral hub vil være ganske lik for de to løsningene. I
kommunikasjonshub-modellen vil man være helt avhengig av lokale løsninger hos
nettselskapene. Konsekvensene av uønskede hendelser vil være store for begge
løsningene - og størst for løsningen med datahub. Sannsynligheten for langvarige
problemer er imidlertid liten med en sentral datahub (forutsatt at denne dimensjoneres
og driftes riktig), mens sannsynligheten for problemer blant mange lokale enheter anses
betydelig. Selv om konsekvensene hver for seg kan være små, kan summen av slike
problemer få alvorlige innvirkninger på tjenestekvalitet - og som følge av dette,
bransjens renommé.
Investeringer i infrastruktur, etablering av organisasjon samt drift vil bli omfattende i
begge scenarier. Nytteverdien av kommunikasjonshuben synes imidlertid meget
begrenset både i forhold til dagens løsning med meldingsutveksling alle-til-alle og i
forhold til kostnader ved etablering og drift. De største kostnadene vil være knyttet til
utvikling og forvaltning av applikasjonsprogramvare med databaser. Med datahub vil
dette i stor grad være felles, mens i en desentral modell vil det være nettselskapene som
hver for seg blir ansvarlig for kostnadene.
Implementeringsrisiko er et komplekst begrep og omfatter bl.a. risiko for:
kostnadsoverskridelser
forsinket implementering
feil og sikkerhetshull i løsningene i drift
dårlige teknologivalg
Implementeringsrisiko er uløselig koblet med hvordan prosjektene blir gjennomført.
Med riktig styring og ressurssetting skal denne risiko kunne begrenses.
Begge scenariene vil kreve et stort fellesprosjekt, men dette er minst for
kommunikasjonshub-løsningen. I den desentrale modellen vil mye av
implementeringsarbeidet gjøres i nettselskapene. Velger man kommunikasjonshubløsningen
basert på omlegging og fornyelse av eksisterende standarder og systemer, vil
sentral implementeringsrisiko kunne reduseres, men total implementeringsrisiko vil
sannsynligvis bli høyere ettersom samtlige aktører må foreta tilpasninger og
vedlikehold.
9.6.2 Evaluering i forhold til de generelle evalueringskriteriene
Evaluering i forhold til de fire kriteriene er gjort nedenfor.
123

9.6.2.1 Samfunnsøkonomi
Isolert sett vil infrastrukturen for en sentral datahub bli mer kostbar enn for en ren
kommunikasjonshub. Tas kostnadene med utvikling og vedlikehold av løsningene med,
vil dette kunne gjøres mer effektivt på ett sted enn ute hos 100+ aktører. I tillegg vil en
desentral løsning gi mer overhead i kommunikasjon – noe som fører til økt tids- og
ressurs-press på hele kommunikasjonsløsningen. Totalløsningen forventes derfor å bli
rimeligere for en sentralisert datahub enn for en kommunikasjonshub.
En kommunikasjonshub vil føre til at terskelen for innføring av felles tjenester kan bli
høyere og/eller at kostnader på disse bli høyere. Begge disse faktorene vil ha en negativ
samfunnsøkonomisk effekt. Et eksempel på en slik tjeneste er beregning av
fakturagrunnlag for nettleie sentralt – noe som vil ta ned kommunikasjonsbehovet
mellom nettselskapene og kraftleverandørene vesentlig.
Hvordan løsningen bidrar til eller hindrer i å hente ut nytteeffekten av smart-grid, vil ha
betydelig samfunnsmessig effekt. Foreløpig er det stor usikkerhet om hvordan markedet
vil utvikle seg med implementering av smart-grid og hvilke tjenester, tariffstrukturer og
adferd vi vil få. Dette betyr at det blir stort behov for fleksibilitet for å tilpasse og
utvikle IT-løsninger. En løsning med datahub vil møte disse kravene på en bedre måte
ved at endringer kan gjøres ett sted istedenfor hos en lang rekke aktører.
9.6.2.2 Støtter ny markedsmodell
Begge modellene støtter ny markedsmodell. Utvikling og forvaltning av nye tjenester
vil bedre kunne tilrettelegges i en sentral datahub ettersom hovedtilpasningene bare skal
foregå ett sted.
En løsning med datahub vil senke terskelen for å komme inn i markedet for nye aktører
i forhold til en løsning med kommunikasjonshub. En datahub vil bidra til sterkere
standardisering og felles grensesnitt og den kan tilby ulike tjenester i datahuben og
enkel tilgang til data.
9.6.2.3 Teknisk robust løsning
130 nettselskap skal ha ansvaret for hver sin tekniske løsning. Det kan tenkes at flere av
disse kjører på samme plattform, men de vil likevel ikke kunne ta ut stordriftsfordeler
knyttet til volum, tilgjengelighet og redundans.
Går en sentral datahub ned, har dette høyere konsekvens enn om noen få enkeltsystemer
går ned. Sannsynligheten for at en riktig dimensjonert og driftet datahub går ned, er
imidlertid svært lav. Totalrisiko anses derfor som lavere med en sentral datahub enn et
system som i større grad avhenger av mange lokale løsninger.
En datahub vil også gi en høyere grad av sikkerhet gjennom etablering av felles
tilgangskontrollsystem. Skal hvert nettselskap etablere og drifte hvert sitt
tilgangskontrollsystem, kan dette gi utilsiktede sikkerhetshull. I tillegg vil forskjellige
sikkerhetspolicy hos de ulike aktørene føre til at de svakeste leddene vil utgjøre
sikkerhetsdimensjoneringen for hele systemet.
124

En sentral datahub vil også mer effektivt kunne kontrollere at krav til kvalitet
overholdes. Det er dermed lettere å bygge et kvalitetssikringsregime som kan føre til
god tjenestekvalitet internt, mot sluttkunder og tredjeparter.
En sentral datahub vil gi stordriftsfordeler både for infrastruktur og for forvaltning av
løsningene.
9.6.2.4 Implementering
Implementering av en sentral datahub som beskrevet over er en omfattende oppgave og
setter strenge krav til prosjektgjennomføring. Sannsynligheten for å lykkes med ett
sentralt prosjekt vurderes likevel som høyere enn for et koordinert løp med mer enn
hundre mindre implementeringsprosjekt hvor alle gjør tilpasningene lokalt.
Koordineringen av ulike implementeringshastigheter og ulik grad av kvalitet i
gjennomføring for en desentral løsning, kan bli ganske krevende. Dette vil også gjelde
fremtidige oppdateringer.
På lenger sikt må man forvente store krav til fleksibilitet og tilpasningsevne til nye
markedskrav som følge av smart grid. En datahub der nye funksjoner og endringer
implementeres ett sted isteden for hos mange ulike aktører, vil senke fremtidig
implementeringsrisiko. Dette vil ikke minst redusere sannsynlighet for
programmeringsfeil og konfigureringsfeil som påvirker driften av løsningene.
125

10 Implementering og overgangsløsninger
10.1 Forskjeller mellom modellene i forhold til implementering av nye krav
I dagens desentraliserte modell er større endringer i meldingsutveksling eller
markedsmodell krevende. Alle aktørene må implementere alle endringer som berører
deres rolle. De fleste av disse bestiller funksjonalitet og/eller et prosjekt av en eller flere
system/tjenesteleverandører. For å nå en tidsfrist som normalt er forskriftsfestet krever
dette en omfattende koordinering, verifisering og driftssetting, der alle
system/tjenesteleverandører, aktører og Statnett sin systemstøtte er involvert. Risikoen
for at noen av aktørene ikke kommer i mål er høy. Modellen gjør også at samme
funksjonalitet må implementeres og finansieres i flere systemer/versjoner.
En kommunikasjonshub vil øke den totale systemkosten, fordi funksjonaliteten
fremdeles vil måte implementeres hos alle aktørene, i tillegg til at
kommunikasjonshuben må etableres og vedlikeholdes. Alle aktørene vil måtte ha
samme tilgjengelighet og verifisere løsningene på samme måte som i dag.
Hovedgevinsten for en kommunikasjonshub er mer effektiv drift med færre
kommunikasjonspartnere.
En datahub vil forenkle implementeringen av endringer i markedet i systemløsningene
hos nettselskapene betydelig. Avhengig av antall funksjoner som sentraliseres, vil
mange nye endringer kun berøre datahuben, og det er kun datahuben som vil ha krav til
tilgjengelighet og ytelse. Hvis en rendyrker nettselskapets systemer til å håndtere
nettdrift og innsamling med å sentralisere markedskommunikasjon og beregning, vil
både nettselskap og kraftleverandør kunne benytte mindre kompliserte systemløsninger
uten særnorske krav og kompliserte energirelaterte beregninger. Men den initielle
etableringskostnaden vil være betydelig større for en datahub i forhold til en
kommunikasjonshub, fordi en datahub skal implementere sentrale funksjoner med
lagring av data i tillegg til den sentraliserte kommunikasjonen.
10.2 Etablering
10.2.1 Kommunikasjonshub
En kommunikasjonshub vil være enklest å etablere isolert sett. Kravspesifikasjonen vil
være enklere enn for en datahub. Men denne løsningen krever at alle aktørene bygger og
verifiserer ny markedsmodell og støtte for AMS. Det vil derfor være aktørene i bransjen
som høyst sannsynlig vil bruke lengst tid på å tilpasse sine løsninger. Det bør være
realistisk å få på plass en kommunikasjonshub løsning til 01.10.14, hvis
kravspesifikasjonen starter tidlig høsten 2012.
Kravspesifikasjon (inkludert anbudsunderlag for kommunikasjonshub): 6-8 mnd
Anbudsrunde: 2-3 mnd
Implementering av kommunikasjonshub og aktørenes løsninger: 10–12 mnd
Test og verifikasjon: 2-4 mnd (i tillegg til en start parallelt med implementering)
10.2.2 Datahub
En datahub vil kreve en mer omfattende kravspesifikasjon, og er betydelig lengre
implementeringsløp. Aktørene i bransjen vil høyst sannsynlig bruke mindre tid på å
tilpasse seg en datahub, enn selve implementeringen av datahuben. Det bør være
126

ealistisk å få på plass en datahub løsning til 01.10.15, hvis kravspesifikasjonen starter
tidlig høsten 2012.
Kravspesifikasjon (inkludert anbudsunderlag for kommunikasjonshub): 10-12
mnd.
Anbudsrunde: 3-5 mnd.
Implementering av datahub og tilpasning av aktørenes løsninger: 12–18 mnd.
Test og verifikasjon: 4-6 mnd. (i tillegg til en start parallelt med
implementering)
10.3 Overgangsordning
10.3.1 Kommunikasjonshub
Med en kommunikasjonshub vil funksjonaliteten tilgjengeliggjøres av aktørene, slik at
en eventuell overgangsløsning vil kunne ha form som en fasedelt flytting av
kommunikasjon rundt prosessene fra dagens mange-til-mange kommunikasjon til en
kommunikasjon via en kommunikasjonshub. Det er lite sannsynlig av en fasedeling av
implementering av en kommunikasjonshub vil påvirke totalt kost eller tid i vesentlig
grad verken opp eller ned. Grunnen til dette er at når motoren er på plass, er
implementeringen av nye prosesser og meldinger relativt enkel. Det vil være en
tilleggskostnad for å kjøre prosjektet, men samtidig reduseres risikoen og
test/verifisering forenkles per fase. En kan velge å gjøre dette av praktiske og risikomessige
grunner, men ikke for å spare tid/kost.
10.3.2 Datahub
En datahub vil være et omfattende prosjekt i alle faser. Avhengig av antall prosesser
som skal sentraliseres, vil en kunne få deler av løsningen etablert raskere ved å
faseinndele implementeringen. Men en slik faseinndeling vil høst sannsynlig øke den
totale kostnaden og den totale implementeringstiden betydelig. Risikoen vil derimot
også reduseres betydelig ved en faseinndeling i forhold til et big-bang prosjekt.
En annen grunn til å faseinndele, er at siden funksjonsansvar flyttes fra nettselskap til
datahub over en periode der en samtidig endrer markedsmodeller, måleverdioppløsning
og beregningsalgoritmer, vil en kunne forenkle datahuben ved kun å supportere
fremtidig/endret funksjonalitet. Dagens regelverk vil håndteres av nettselskapene i
dagens systemer. Ulempen med en slik modell er at overgangsordningene kan bli
kompliserte, og over en periode på flere år, vil bransjen måtte operere, drifte og betale
lisenser for parallelle system som utfører samme oppgaver, men basert på nytt og
gammelt regelverk.
Samtidig er det grunn til å tro av merkostnaden ved å legge til support for dagens
regelverk i en datahub er lav, da dette er kjent funksjonalitet som alle de etablerte
systemleverandørene har støtte for. En lav tilleggskostnad, men lav teknisk risiko taler
for å flytte funksjoner med støtte fra dagens prosesser tidligst mulig, da det vil være
klare stordriftsfordeler med å kjøre prosesser som profilavregning og saldooppgjør
sentralt.
Hvis en likevel velger en faseinndeling kombinert med overgangsordninger, er det
naturlig se disse i forhold til innføringen av AMS. AMS vil være triggeren til at flere
127

andre prosesser i markedet vil måtte endres, etter hvert som vi nærmer oss full
utbygging.
Figur 51 - Mulig faseinndeling i forhold til avhengighet av AMS
Figuren over viser en mulig faseinndeling koordinert med AMS innføringen.
Da det er liten sannsynlig å få komplett løsning på plass innen 01.01.14, så er det viktig
at første versjon støtter tilgjengeliggjøring av AMS måledata. Dermed vil en kunne
unngå at nettselskapene selv må implementere det nye kravet som følge av forskriften.
For å kunne distribuere AMS måleverdier, vil en kun ha behov for å definere de
målepunktene som er ferdig utbygd og kun målepunktinformasjon som er nødvendig for
å gjøre måledata tilgjengelig. Leverandørskifteprosessen vil gjøres etter dagens
regelverk og de nye AMS målepunktene legges inn som timesmålte anlegg i dagens
beregninger i profilavregning/saldooppgjør/korreksjonsoppgjør.
Neste fase bør være innføringen av en leverandørsentrisk modell. Før denne startes opp,
må alle målepunkt flyttes inn i datahuben. Dette må uansett gjøres før andre prosesser
sentraliseres. Grunnen til det er at et konsistent målepunktregister med oppdatert status
på roller og prosesser er avgjørende for å kunne sentralisere beregningsprosesser.
Dagens profilavregning og saldooppgjør/korreksjonsoppgjør holdes utenfor, og
håndteres av nettselskapene basert på oppdateringer fra datahuben
Når andelen profilmålte målepunkt reduseres vil en uansett måtte endre beregningene
og prosessene rundt profilavregning og saldooppgjør. Dagens profilavregning vil ikke
kunne fungere med et lavt profilavregnet forbruk. Dermed må disse prosessene
sentraliseres senest siste halvdel av AMS innføringen. De nye prosessene har vi
tidligere i dokumentet definert som ”rapportering til balanseavregningen” og
”avviksoppgjør”.
Avhengig av eventuelle endringer i forskriften vil en senest måtte ha på plass støtte for
AMS tilleggstjenester når AMS er 100% utbygd, sannsynligvis før.
I tillegg har vi i dette dokumentet berørt prosesser som er uavhengig av AMS
utbyggingen. Totalfakturering gjennom kraftleverandørene er et eksempel på dette.
Disse prosessene kan derfor implementeres når som helst, og risiko og kost/nytte bør
dermed være avgjørende.
128

10.3.3 Anbefaling
Hvis mulig bør en unngå en overgangsordning basert på:
at de fleste av de ny/endrede prosessene må være på plass før AMS er fullt
utbygd
en rask implementering av en leverandørsentrisk modell har en egenverdi
at en må unngå at nye og endrede prosesser først må implementeres i dagens
desentrale modell og senere inngå i en kommunikasjons- eller datahub.
Dermed vil perioden der eventuelle faser kan være aktuelle bli kort. Dette vil føre til at
aktørene vil måtte forholde seg til parallelle standardiseringsprosesser,
implementeringsprosjekt, test/sertifiseringsprosesser og produksjonsdatoer. Totalt sett
vil dette øke både risiko og kostnad mer enn den potensielle besparelsen.
Et alternativt løp for å teste ut huben fasedelt og i mindre skala, er å la noen aktører
være med som pilot brukere. Da kan en starte opp en skyggeproduksjon for eksempel 6
måneder før skarp drift, der en tester en prosess om gangen. Dermed vil en kunne
redusere risiko i en «big bang» etablering og skille eventuelle justeringer i prosessene
fra hverandre.
Kravet til oppstartdato for tilgjengeliggjøring av AMS måledata bør revurderes hvis en
beslutter å etablere en datahub. Hvis en ønsker å prioritere en raskest mulig oppstart av
en datahub bør en endre tidspunktet for tilgjengeliggjøring av AMS måledata og ta bort
overgangsordningen som nettselskapene da må etablere for en kort periode. Hvis en
derimot vil la kravet stå, så bør en gå for en fasedeling som beskrevet i 10.3.
129

11 Organisering og styring av felles IKT løsning
11.1 Oppgaver og rolle
En felles IKT-løsning skal ha oppgaver som defineres som infrastruktur, er til nytte for
bransjen og som det er effektivt å sentralisere. Virksomhetens oppgaver skal derfor
være begrenset, og virksomheten skal i utgangspunktet ikke påta seg oppgaver eller
utføre forretningsprosesser som det er bedre at selskapene selv eller andre aktører i
markedet håndterer.
Uavhengig av valg av en kommunikasjonshub-modell eller datahub-modell kan arbeidet
med utvikling og drift organiseres i en egen enhet/selskap. Dette vil øke transparens om
selskapets forretningsmessige og økonomiske forhold. Dette vil også gi bedre fokus på
arbeidsoppgavene og måloppnåelse. Beslutning om det skal etableres et eget selskap,
bør bli tatt i løpet av 2012.
Organiseringen skal dekke to ulike faser, utvikling og implementering av felles datahub
og en fase som består av drift, vedlikehold og videreutvikling. Fasene har ulike krav til
kompetanse, ressurser og styringsmodell.
Organisasjonen med ansvar for en felles IKT-løsning skal ha følgende oppgaver:
Oppfylle eventuelle myndighetspålagte oppgaver (overholde tidsfrister,
kvalitetskrav, tilpasninger til krav og forskrifter)
Sikre nøytralitet og like konkurransevilkår for alle aktører (kundeservice, tilgang
etc.)
Bidra til å effektivisere beslutninger og implementering (utvikle markedet)
Sikker drift (systemdrift)
Konfidensialitet (sikker datahåndtering)
Håndtere prosesser/tjenester som er naturlige monopoler og hvor det er
stordriftsfordeler for bransjen og sluttbrukerne
Bidra til utviklinger av løsninger til det beste for markedet, aktørene og
sluttbrukerne
Virksomheten er å betegne som infrastruktur og kjennetegnes med å utføre oppgaver
som har natur av å være monopol. Dette medfører at virksomheten er gjenstand for
regulering.
Implementering av første fase i en felles IKT-løsninger skal i henhold til dagens AMS
forskrift være på plass innen 2014, men det er for tidlig å si om en datahub kan være
operativ innen denne tid. Men denne tidsfristen er uansett en viktig premiss for hvordan
organiseringen av det videre arbeidet må utformes for å sikre en hurtig utvikling og
implementering.
11.2 Organisering av videre fremdrift
Innføringen av datahub foreslås i tre faser:
11.2.1 Forberedelse; 2012
I denne fasen skal det avklares hvordan implementasjons- og driftsfasen skal
finansieres, organiseres og styres. Videre skal det i denne fasen utarbeides
kravspesifikasjon til datahubens IKT system. Oppgaven ligger per i dag innenfor
ansvaret til Avregningsansvarlig og Avregningsansvarlig vil ta ansvaret men med
bistand fra bransjen og i samarbeid med NVE
130

11.2.2 Utvikling; 2013-2016
Dette innebærer en gradvis innføring av utvalgte prosesser frem til komplett datahub.
Det er ikke mulig å spesifisere når en datahub kan være operativ før et prosjekt er
etablert og leveranser er avtalt. Vi mener imidlertid at det bør kunne være realistisk å
etablere en datahub med begrenset funksjonalitet som oppfyller forskriftskravene før
2015.
Utvikling og implementering av en felles IKT-løsning vil medføre ett omfattende
prosjekt med store krav til fremdrift og kvalitet. Beslutningsdyktighet og sikring av
nøytralitet i løsningene er også viktige faktorer som det må bli tatt hensyn til. Det er
også viktig at det blir gitt et klart mandat gjennom regulering av virksomheten.
Endelig beslutning vedrørende hvem som bør ha ansvaret for utvikling av en felles IKTløsning
er enda ikke tatt. Dette vil bli bestemt senere i samarbeid med NVE, når det
samtidig – basert på denne rapport – er truffet beslutning om valg av felles IKT-løsning.
11.2.3 Drift; 2017
I denne fasen er alle relevante prosesser etablert i nytt markedsregime og datahuben er
operativ. Etter at løsningen er implementert, og selskapet går inn i en driftsfase, kan det
være naturlig at andre selskaper går inn på eiersiden av selskapet. Hvordan dette
eventuelt skal gjennomføres vil bli vurdert senere. Dette vil blant annet avhenge av
forhold rundt regulering av virksomheten (konsesjon, avkastning etc.), og
bransjeaktørers ønske om å være eiere i et slikt selskap.
11.3 Bransjens involvering
Uansett organisasjonsform må bransjen være sterkt delaktig i utviklings- og driftsfasen.
Kompetanse fra bransjen må delta ved utarbeidelse av datahubens tekniske
kravspesifikasjon, implementering og testing. Innføring av datahub vil kreve mye
testing som involverer nettselskapenes datasystemer. Videre må bransjen være sterkt
involvert i forbindelse med standardisering av AMS grensesnitt og tilleggstjenester.
I driftsfasen må bransjen være involvert i forhold til å evaluere kvalitet på tjenestene,
forslag til endringer og utvikling generelt. Det bør settes opp en styringsmodell for
denne typen arbeid slik at en sikrer hensiktsmessig utvikling.
Det bør etableres en markedshåndbok som beskriver markedsregler, tekniske standarder
og hvordan alle aktørene skal forholde seg til hverandre.
131

12 Oppsummering og anbefaling
Utredningen har beskrevet to ulike modeller; en kommunikasjonshub og en datahub.
Anbefalingen av foreslått modell bygger på de viktiges forholdene som er blitt diskutert
tidligere i utredningen. Disse er:
God kvalitet og effektiv distribusjon av måleverdier
Leverandørsentrisk markedsmodell
Tilrettelegge for tilleggstjenester muliggjort gjennom AMS – «smarte produkter,
tjenester og nettnytte»
Støtte til ny markedsdesign
Effektiv organisering og forvaltning av felles IKT-løsninger
Robusthet i forhold til internasjonal integrasjon
Best mulig forhold mellom kostander og besparelser
12.1 God kvalitet og effektiv distribusjon av måleverdier
Datahub er vurdert som klart bedre enn kommunikasjonshub. Dette er basert på:
Bedre kvalitet på måledata gjennom at det foretas kontroller i dathuben på
innsendte måledata
Muliggjør enklere feilhåndtering av måledata ved avvik
Nettselskapene trenger enklere funksjonalitet i sine systemer da de unngår
system hvor kraftleverandører, sluttbruker og tredjepart har mulighet til å spørre
om data
Lavere krav til oppetid av systemene til nettselskapene
12.2 Leverandørsentrisk modell
Datahub er evaluert som bedre enn kommunikasjonshub.
En datahub vil lette prosessene hos kraftleverandørene da de vil ha et kontaktpunkt å
forholde seg til. Skille mellom nettselskaper og kraftleverandører vil bli mer tydelig, og
interaksjonen mellom nettselskap og kraftleverandører vil bli redusert. For å oppnå
mange av fordelene med en leverandørsentrisk modell er bransjen avhengig av gode
løsninger for å tilgang til måledata, kundedata og raske effektive prosesser. En løsning
med datahub vil støtte en leverandørsentrisk modell på en bedre måte enn en
kommunikasjonshub.
12.3 Tilrettelegge for tilleggstjenester muliggjort gjennom AMS
Datahub er evaluert som bedre enn kommunikasjonshub.
Innføring av AMS vil legge til rette for nye løsninger som vil kunne øke kundenytte og
nettnytte gjennom innovasjon av nye produkter og løsninger. Det er helt avgjørende
med felles IKT-løsninger for å tilrettelegge for nye løsninger og innovasjon.
Utredningen anbefaler en løsning hvor «AMS-kanalen» forbeholdes nettselskapene for
nettnytte formål. Det anbefales å kommunisere informasjon fra AMS måler over «åpne»
og tilgjengelige kanaler som for eksempel internett. Det må legges opp til felles
autorisasjon av 3. parter for tilgang til informasjon og for tilkobling av tredje parts
utstyr.
132

Løsningen som beskrives kan utvikles i en datahub. Fordelene med løsningen er enklere
og sikrere autorisasjon av brukere, samt lettere tilgjengelighet av sluttbruker- og
måledata.
12.4 Støtte ny markedsdesign
En datahub er evaluert som klart bedre enn en kommunikasjonshub. Dette er basert på:
Mer effektiv håndtering av basis data; sluttbruker, målepunkt, adresser,
avgiftsplikt etc.
Mer effektive prosesser, for eksempel leverandørskifte og flytting
Enklere og mer effektiv rapportering til balanseavregningen
Sikrer i større grad nøytralitet mellom aktørene
12.5 Effektiv organisering og forvaltning av felles IKT-løsninger
Datahub evaluert som bedre enn kommunikasjonshub.
En datahub som lagrer alle data sentralt vil ha større mulighet til å foreta
kvalitetskontroller basert på monitorering. Enheten vil også lettere kunne foreta
korrektive tiltak dersom dette er nødvendig.
Endringer forårsaket av myndighetspålegg, effektivisering av prosesser etc. kan også
lettere bli implementert i en datahub, og aktørenes systemer vil bli berørt i mindre grad.
12.6 Robusthet i forhold til internasjonal integrasjon
En datahub er evaluert som klart bedre enn kommunikasjonshub. Dette begrunnes med:
Et grensesnitt for nettselskaper og kraftleverandører
Raskere implementering av endringer som følge av internasjonale krav og
harmonisering av nasjonale markeder
Reduserte endringer for nettselskap og kraftleverandører i egne systemer
12.7 Best mulig forhold mellom kostnader og besparelser
Datahub evaluert som klart bedre enn kommunikasjonshub.
En datahub vil være dyrere å implementere og drifte enn en kommunikasjonshub.
Besparelsene som bransjen totalt sett vil oppnå er betydelig større ved en datahub enn
ved en kommunikasjonshub. Dette fordi mange oppgaver flyttes fra hvert enkelt
nettselskap til datahuben, som vil kunne effektivisere prosessene, og dermed redusere
kostnadene. Det vil også oppstå en betydelig besparelse ved at data er tilgjengelig
raskere enn i dag. Dette vil bidra til enklere hverdag for kraftleverandørene som i dag
har relativt høye kostnader pga. manglende eller feil data.
12.8 Oppsummering
Dagens modell er ikke egnet for fremtidens krav. Den vil ikke kunne levere ønsket grad
av datakvalitet og nøytralitet. Dagens modell vil også virke begrensende på potensialet
133

som ligger i innføringen av AMS. En ny felles IKT-løsning vil derfor måtte bli etablert i
forbindelse med innføringen av AMS i Norge.
Utredningen konkluderer med at en datahub er å foretrekke frem for en
kommunikasjonshub. Dette oppsummeres i punktene under:
Aktørenes besparelser overstiger langt kostnadene ved en datahub
En datahub sikrer bedre kvalitet
En datahub sikrer nøytralitet og like konkurranseforhold
En datahub har et større potensiale for utnyttelse av AMS
En datahub er mer fleksibel og endringsdyktig
En datahub vil støtte en ny leverandørsentrisk markedsmodell som igjen vil gi
økt kundenytte
134

13 Konsekvenser ved innføring av datahub
Anbefalt modell for datahub vil medføre en del konsekvenser. Datahuben sin rolle og
nye markedsregler må reflekteres i reguleringen av markedet. Markedsaktørenes rolle
og forpliktelser har blitt ytterligere definert gjennom foreslått modell og dette vil legge
føringer for de investeringer selskapene skal foreta samt fremtidige krav til drift. Vi har
i det etterfølgende beskrevet de viktigste konsekvenser fordelt på regulering,
nettselskaper og kraftleverandører.
13.1 Regulatoriske konsekvenser
Det er omfattende endringer som foreslås ved innføring av en datahub. Følgelig er det
mange regulatoriske forhold som må avklares. Det er viktig at disse forholdene blir
avklart så tidlig som mulig og senest i henhold til fremdriftsplan for implementering av
Datahub
13.1.1 Forskriftsendringer
Store deler av Forskrift 301 må sannsynligvis omskrives i forbindelse med innføring av
en hub (kommunikasjons- eller datahub). Generelt gjelder dette at datahub må innføres
som rolle og at relasjonen mellom nettselskap, datahub, kraftleverandører samt
balanseavregning må redefineres.
Det bør tas stilling til hvor lenge en datahub skal kunne lagre måleverdier. Kravet om
maksimum 15 måneder er knapt i forhold til bokføringsloven samt energianalyser i
forbindelse med energieffektivisering. Sikkerhet og personvern bør kunne ivaretas
tilfredsstillende i en regulert og offentlig forvaltet datahub.
Forskriftens § 4.2 f) angående kraftpriser og tariffer bør konkretiseres i forhold til
nettselskapene sine forpliktelser. Vil det være tilstrekkelig å påpeke at det er
nettselskapenes ansvar å tilgjengeliggjøre kraftpriser og tariffer uten at det nødvendigvis
må gjøres gjennom AMS kanalen?
13.1.2 Nettselskapenes tariffer
På grunn av historiske forhold er dagens strukturer for nettselskapenes tariffer
diversifisert og lite oversiktlig. Det bør lages ett felles sett med strukturer som dekker
nettselskapenes fremtidige behov. Dette vil for det første øke potensialet for nettnytte og
tilleggstjenester. For det andre vil det muliggjøre mer standardisert og forenklet
nettavregning, enten det gjøres lokalt av det enkelte nettselskap eller av en datathub.
13.1.3 Stenging og struping
Det må avklares regler for stenging og struping. Skal kraftleverandøren ha stenge
og/eller struperett, hvilke prosedyrer skal ligge til grunn og hvor ligger det juridiske
ansvaret.
13.1.4 Samfakturering
Modell for samfakturering må avklares. Hvis det skal innføres modell for pliktig
totalfakturering ved kraftleverandøren, vil det legge en del føringer på datahuben sin
rolle. Videre vil en konsekvens av en slik modell være at det vil bli uhensiktsmessig at
leveringsplikt skal være nettselskapets ansvar. Dette fordi nettselskapene da vil måtte ha
full funksjonalitet for kundehåndtering og fakturering noe som vil oppveie hele
effektiviseringsgevinsten ved at kraftleverandøren er primær kundekontakt og fakturer
nettleien.
135

13.1.5 Standardisert grensesnitt mot AMS måler
Grensesnittet mot lokal AMS måler (AMS gateway) må være standardisert for hele
Norge dersom det skal være interessant for kraftleverandører av tredjeparts produkter
som skal kunne kommunisere med måleren. Noen må ha ansvaret og myndighet til å
bestemme standarden.
13.2 Konsekvenser for nettselskaper
13.2.1 Innsamling og kvalitetssikring av AMS måleverdier
I henhold til beskrivelsene i kap. 5 er nettselskapene ansvarlige for innsamling,
kvalitetssikring og sending av måleverdier. Nettselskapene er utover dette ikke
ansvarlig for distribusjon til den enkelte sluttbruker. Det vil bli ett felles format for
oversendelse av måleverdier til datahuben. Dette formatet vil bli utarbeidet i samarbeid
med bransjen.
AMS måleverdier skal sendes til datahub så snart AMS måleren er satt i drift.
Nettselskapene må være forberedt på at datakvaliteten vil måles i datahuben og
ansvarliggjøres for eventuelle kvalitetsbrister.
13.2.2 Håndtering av markedsprosesser (leverandørskifte/flytting osv.)
Prosessene vil nå håndteres av datahuben, og nettselskapet vil kun bli informert om
endringer.
13.2.3 Leverandøravregning/ukeavregning.
Ansvaret for beregninger, rapporterering og avviksoppgjør flyttes til datahuben.
13.2.4 Formidling av kraftpriser og tariffer (ref. forskriftens § 4.2 f).
Prosjektet mener at den foreslåtte datahuben kan dekke mye av kravene til
nettselskapene med hensyn til distribusjon av kraftpriser, tariffer og andre
tilleggstjenester til sluttkunde. Begrensningen ligger i sluttbrukerens manglende tilgang
til internett eller andre kommunikasjonsløsninger. I slike tilfeller og hvor det kreves av
sluttkunde kan nettselskapet vurdere installasjon av internett som alternativ til
informasjon over AMS kanalen. Det vil fortsatt være en forpliktelse som ligger på
nettselskapet, men en trenger ikke investere i infrastruktur før et eventuelt behov
oppstår og da kan som sagt alternative løsninger benyttes dersom det oppfyller
hensikten. Disse forholdene er viktig å få avklart raskt med regulator, ref. 13.1.1
ovenfor.
13.2.5 Overgangen til AMS
Nettselskapene må kunne støtte dagens forretningsprosesser også for anlegg som får
AMS installert. Nye forretningsprosesser som foreslått i denne utredning vil innføres i
overgangsperioden for alle anlegg uavhengig av om de har fått AMS installert eller
ikke.
Videre må nettselskapene forberede seg på å avregne og fakturere nettleie på samme
måte som i dag også i perioden etter innføring av AMS og inntil en eventuell ny
faktureringsmodell blir implementert.
På sikt vil nettselskapene kunne redusere sine funksjoner i forhold til kundehåndtering
og fakturering dersom det innføres en leverandørsentrisk modell med totalfaktura og
eventuelt avregning dersom nettleien beregnes i datahuben.
136

13.2.6 Lokale grensesnitt på AMS måleren
Utredningen legger opp til minst to lokale grensesnitt på måleren. Ett skal være ett åpent
standardisert grensesnitt for kommunikasjon med lokale 3. parts produkter og tjenester
gjennom en AMS gateway. Her er det viktig med standardisering som presisert i kap.
13.1.4.
Det andre grensesnittet er nettselskapets lokale grensesnitt for nettnytte, f.eks. til lokal
laststyring styrt av nettselskapet.
13.3 Konsekvenser for kraftleverandører
Kraftleverandørene vil kun forholde seg til én datahub og ikke de enkelte nettselskap.
Det vil bli ett felles format for utveksling av data med datahuben. Disse formatene vil
bli utarbeidet i samarbeid med bransjen.
Kraftleverandørene vil slippe å måtte forholde seg til målerstand, målerkonstanter og
tilhørende kompleksitet.
Med en innføring av en leverandørsentrisk modell med totalfakturering vil
kraftleverandøren overta stort sett all kundekommunikasjon og fakturering.
Det er grunn til å anta at en vil kunne gjennomføre prosesser og motta data med høyere
kvalitet og betydelig mindre manuell oppfølgning enn i dag.
137

Vedlegg A Referanser
[1] Forskrift om måling, avregning og samordnet opptreden ved kraftomsetning og
fakturering av nettjenester 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
Harmonised Electricity Role Model), https://www.entsoe.eu/resources/edi-library/
[7] «Høring – rapport om overføring av myndighetsoppgaver fra de lokale eltilsyn (DLE)
til DSBs regionkontorer (fase 1-rapporten) og rapport om innhold, oppgaver og
oppfølging av eventuelt konkurranseutsatt teknisk tilstandskontroll (fase 2-rapporten)»
fra Justis- og beredskapsdepartementet, se
http://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, se
http://www.nve.no/PageFiles/812/Leverand%c3%b8rskifter_hovedtall%203%20kv%20
2011.pdf?epslanguage=no
[9] NordREGs recommendation on the future model for billing customers in the
harmonised Nordic end-user market, December 19 th 2011
138

Vedlegg B Rollemodell og informasjonsflyt
I dette vedlegget beskrives en rollemodell for roller som benyttes i denne rapporten.
Rollemodellen er basert på Rollemodell for det norske kraftmarkedet 15 , som igjen er
basert på Rollemodell for det europeiske kraftmarkedet fra ebIX ® , EFET og ETSO 16 .
B.1 Kort om metodikk
Rollemodellen fra ebIX ® , ENTSO-E og EFET baserer seg på UML metodikk. I
rollemodellen vises roller, domener og assosiasjoner mellom disse.
En Rolle representerer den eksterne atferden til en aktør. Aktører kan ikke dele en rolle.
Aktører utfø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 der forbruk, produksjon eller utveksling av energi kan bestemmes.
En Aktør representerer en organisasjon eller en del av en organisasjon som deltar i
bestemte forretningsprosesser. Innenfor en bestemt forretningstransaksjon vil en aktør
agere i et spesifikt sett av roller.
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.
Domene vises som et rektangel (klasse) og indikerer et domene relatert til
fysiske eller logiske objekter.
Assosiasjon vises som en pil med åpen pilspiss og viser ansvar mellom
roller og domener. Endepunktene til en assosiasjon kan ha en kardinalitet som viser
begrensninger i antall objekter det kan være i endepunktet, for eksempel:
1 = ett objekt
0..1 = ingen eller ett objekt
0..* = ingen eller flere objekter
1..* = ett eller flere objekter
Generalisering vises som en pil med lukket pilspiss og viser at rollen eller domenet som
15 Rollemodell for det norske kraftmarkedet, www.ediel.no
16 Rollemodell for det europeiske kraftmarkedet fra ebIX ® , EFET og ETSO (ETSO Harmonised Electricity Role
Model), https//www.entsoe.eu/resources/edi-library/
139

ligger ved pilspissen er en generalisering av rollen eller domenet i den andre enden av
pilen. Den spesialiserte rollen eller domenet vil ”arve” alle egenskaper (attributter) som
tillegger 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 og domener som senere kan benyttes til å definere
forretningsprosesser og forretningstransaksjoner. En aktør kan ha flere roller i markedet.
Sammen med rollemodell-diagrammet finnes en liste over definisjoner for roller og
domener. I forbindelse med utveksling av informasjon vil en markedsaktør kunne finne
hvilke roller han innehar og hvilke utvekslinger han må forholde seg til. En rolle må
kunne ”stå på egne ben” innenfor rollemodellen, med andre ord inneha en autonom
funksjon i markedet.
140

B.2 ESK rollemodell
Figur 52 - Rollemodell
141

B.3 Definisjoner av roller og domener
Rolle
Beskrivelse
Avregningsansvarlig
Avviksoppgjørsansvarlig
(ESK)
En rolle som er ansvarlig for avregning av forskjellen mellom
avtalte og realiserte volumer for energiprodukter for de
balanseansvarlige i et balanseområde.
Dette er en ny rolle definert av ESK prosjektet:
En rolle som er ansvarlig for avviksoppgjør ved korrigering av
måleverdier for ett Målepunkt.
Dette er en rolle definert av ESK prosjektet
En rolle som har en kontrakt for finansiell sikkerhet og
balanseansvar med avregningsansvarlig for et balanseområde, som
gir balanseansvarlig lov til å operere i markedet. Dette er den eneste
rollen som kan kjøpe og selge energi på engros nivå.
Balanseansvarlig
Beregningsansvarlig
(Oppgavegiver)
Kraftleverandør
Kraftavregningsansvarlig
Måledatainnsamler
Målepunktadministrator
Måleradministrator
Tilleggsinformasjon:
Med balanse menes i denne sammenheng at avtalt forbruk eller
produksjon må være lik faktisk forbrukt eller produsert volum. En
balanseansvarlig er ofte (i europeisk sammenheng) eid i felleskap
av flere aktører.
En rolle ansvarlig for å etablere og kvalitetssikre måledata fra
måleverdiansvarlig. Dataene er beregnet (aggregert) i henhold til
markedsregler.
ESK kommentarer:
Denne rollen heter Oppgavegiver i Norsk rollemodell 17
Rollen Beregningsansvarlig mottar kvalitetssikrede
måleverdier fra rollen Måleverdiansvarlig og aggregerer disse i
henhold til markedsregler, som pr nettområde, per
Balanseansvarlig etc.
En rolle som selger differansen mellom den energien som er kjøpt
gjennom fastenergikontrakter og variabelt kraftforbruk av aktør
koblet til kraftnett. I tillegg selger kraftleverandøren differansen
mellom fastenergikontrakter, for aktør koblet til kraftnett, og målt
produksjon.
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ålepunkter
innenfor et nettområde og tilhørende tekniske spesifikasjoner.
Målepunktadministrator er ansvarlig for å opprette og avslutte
målepunkter.
En rolle ansvarlig for en database over registre (målere).
17 Rollemodell for det norske kraftmarkedet, www.ediel.no
142

Rolle
Måleroperatør
Måleverdiansvarlig
Nettilknytningstilbyder
Nettleieavregningsansvarlig
Nettoperatør
Sluttbruker
Faktureringsansvarlig,
Sluttbruker
Beskrivelse
En rolle ansvarlig for installering, vedlikehold, testing, sertifisering
og avslutning av fysiske målere.
En rolle ansvarlig for å etablere og validere måledata fra
måledatainnsamler. Rollen er ansvarlig for historiske verdier for
målepunktene.
ESK kommentarer:
Rollen er kun ansvarlig for enkeltobservasjoner for det enkelte
målepunkt. Aggregering av måleverdier, bl.a. for
avregningsformål forutsettes gjort av rollen
Beregningsansvarlig.
En rolle ansvarlig for gi tilgang til strømnettet og tilhørende bruk
for forbruk 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 23 - Definisjon av roller
Domene
Måler
Målepunkt
Nettområde
Beskrivelse
En fysisk enhet som inneholder en eller flere registre
Et punkt der energiprodukter måles.
Et nettområde er et fysisk område der forbruk, produksjon og
utveksling kan måles. Nettområdet er avgrenset av målere for
periodisk avlesning av inn- og utmating fra nettområdet.
Nettområde kan benyttes for å etablere sum av profilavregnede
målepunkter og nettap.
Tabell 24 - Definisjon av domener
143

Vedlegg C Definisjoner
AMS
App
Autorativ datakilde
Gateway
HAN
Automatisk måle- og styringssystem
Applikasjon for smarte mobiltelefoner
Ansvarlig kilde for data. Et informasjonselement oppdateres
kun i ett system, og derfra spres det til andre. Systemet hvor
informasjonselement oppdateres, kalles en autorativ kilde for
dette elementet.
En protokoll for å koble ekstern programvare med en tjenermaskin.
Dette lar tjeneren sende forespørsler fra en klients
nettleser til det eksterne programmet.
Home Area Network, lokalt (hjemme) nettverk
iPhone/Android App Applikasjon for iPhone og Android baserte smarte
mobiltelefoner.
Monitorering
VEE
WiFi
ZigBee
Elektronisk overvåking av dataprosesser
Validering, estimering og editering
En kommunikasjonsprotokoll for trådløse personlige datanettverk
En kommunikasjonsprotokoll for trådløse personlige datanettverk
144

Vedlegg D Sammendrag av høringssvar til ESK-prosjektet og
prosjektgruppens vurderinger
Prosjektgruppen har mottatt høringssvar fra ulike aktører tilknyttet ESK-prosjektet –
innspillene er relatert til utkastet til rapport datert 14. mai 2012. Prosjektgruppen har
gått igjennom alle svar og gjort en overordnet sammenstilling av de vesentligste
innspillene i punktene nedenfor. Videre følger prosjektgruppens vurderinger til hvert av
punktene.
Prosjektgruppen har også mottatt tekstlige endringsforslag, direkte i rapporten, fra Lyse.
Disse er det i all hovedsak tatt høyde for i rapporten og de således ikke med i den
etterfølgende oppsummeringen.
Kommentarene fra KS Bedrift Energi / Defo er også støttet av Midtnett Buskerud og
Gudbrandsdal Energi, mens kommentarene fra Energi Norge er støttet av BKK Nett. I
den etterfølgende teksten er imidlertid felles svar kun benevnt med KS Bedrift Energi /
Defo og Energi Norge.
Overordnet støtter KS Bedrift Energi / Defo, Energi Norge og Lyse prosjektgruppens
anbefaling om at en felles IKT-løsning best avstedkommes ved implementering av en
datahub. Det er ikke mottatt noen høringssvar som direkte kritiserer prosjektgruppens
anbefaling om innføring av datahub.
D.1 Kravene til markedsdesign
D.1.1 Grunnlagsdata
Høringssvar fra aktører
Energi Norge mener det er behov for i utredningen å klargjøre kvalitetsbegrepet og
ansvar. Det foreslås at nettselskapene er ansvarlig for kvaliteten av måledataen
(avregningsklare data), mens datahuben er ansvarlig for at data blir korrekt overført til
datahuben med tanke på format, antall verdier etc.
Prosjektgruppens vurdering
Nettselskapene er ansvarlig for innsamling og kvalitet på måledata. De er videre
ansvarlig for at korrekte måledata blir oversendt til datahuben, som vil være den
autorative kilden til dataene
D.1.2 Innsamling og distribusjon av måleverdier
Høringssvar fra aktører
Energi Norge mener at stander fortsatt vil ha en verdi for sluttbrukere i fremtiden og at
en derfor må forholde seg til både volum og stander i alle fall i en overgangsperiode.
Dette baseres blant annet på at EUs MID (målerdirektiv) legger opp til krav om display
med målerstand også i AMS-måkere nettopp for at sluttbrukere skal kunne følge
forbruksutviklingen basert på stand. I den forbindelse foreslår Energi Norge at
nettselskapene leverer volum til datahuben samt månedstander. Dette innebærer at stand
primært bare finnes hos nettselskapet, mens datahuben vil ha lagret volum og
månedsstander for alle sluttbrukere.
145

Prosjektgruppens vurdering
Prosjektgruppen vurderer at stander ikke er nødvendige, og dette kompliserer
meldingsutveksling og behov for bransjespesifikke systemer hos aktørene. Innspillet
blir derfor ikke hensyntatt i utredningen.
Høringssvar fra aktører
Energi Norge mener: Statnett ønsker å finne et system som gir insentiver til at måledata
er riktige så tidlig som mulig. Dette kan gjøres på minst tre måter:
1. Innenfor reguleringsregimet, men uten å sette en kort deadline. På denne måten
vil nettselskaper kunne endre data i lang tid, men de vil bli straffet for dette i
inntektsrammereguleringen.
2. Det er også mulig å lage lister som viser hvilke nettselskaper som er dårligst.
Denne metoden brukes med hell i Danmark.
3. Det er også mulig å sette konkrete tidsfrister som M+3. Dersom denne metoden
velges må en vurdere hva det koster å holde en slik kvalitet, samt hva som er et
rimelig krav M+5 eller M+8 etc. Det er mulig å lage forskjellige frister basert på
ulike feil. Fra et kundeperspektiv derimot er dette trolig lite hensiktsmessig
Hvor effektive disse metodene er, er også avhengig av hvorvidt tapet går i ”spleiselaget”
eller om det går rett på bunnlinjen. Koordineringsgruppen foreslår en gradvis
innstramming av den asymmetriske risikoen over en femårs periode.
Prosjektgruppens vurdering
Prosjektgruppen mener at M+3 er et fornuftig tidsintervall for korreksjon av måledata.
Prosjektgruppen er videre enig i at å utarbeide KPI’er på kvaliteten av måledata er et
viktig verktøy som vil gi nettselskapene incentiver til å rapportere inn data med god
kvalitet. Dette vil derfor bli vurdert i en datahub.
D.1.3 Rimelighetskontroll
Høringssvar fra aktører
Energi Norge mener: Statnett har lagt opp til tre nivåer for rimelighetskontroll.
Koordineringsgruppen anbefaler at en kun vurderer måleverdier som høyst sannsynlig
riktig eller høyst sannsynlig uriktig.
Prosjektgruppens vurdering
Ikke endret i rapporten.
146

D.1.4 Estimeringsmetoder
Høringssvar fra aktører
Energi Norge mener: Statnett sine regler for historisk estimering er relativt komplekse.
Koordineringsgruppen mener at en kun bør operere med hverdager og helger. For øvrig
kan en bruke historisk periode (snitt av tre tidligere) og deretter ta hensyn til helg og
hverdag.
Prosjektgruppens vurdering
Dette er blitt tatt hensyn til i rapporten.
D.1.5 Tidsfrist klokken 009:00 D+1
Høringssvar fra aktører
Energi Norge mener: Dersom Statnett skal ha data klare kl. 9. må de trolig ha dataene
fra nettselskapene kl. 7 eller kl. 8. Dette gir nettselskapene svært liten tid til å behandle
måledata. Koordineringsgruppen anbefaler at kl. 9 tidsfristen revurderes, og at NVE
endrer tidspunktet i forskrift 301 til for eksempel kl. 11 dersom det viser seg at dette er
mer hensiktsmessig..
Prosjektgruppens vurdering
Ikke endret i rapporten da gjeldende forskrift krever distribusjon innen 09:00.
D.1.6 Distribusjon av måledata til sluttbruker
Høringssvar fra aktører
BKK Nett, Fjordkraft og Gudbrandsdal Energi fremhever at sluttbruker bør motta
sluttbrukerinformasjon fra kraftleverandør og ikke direkte fra datahuben.
Prosjektgruppens vurdering
I henhold til gjeldende forskrift har sluttbruker rett på tilgang til sine egne data.
Prosjektgruppen mener derfor at dette best oppnås ved å utvikle en løsning hvor
sluttbrukere kan hente egne data hos datahuben og ikke hos kraftleverandøren eller
tredjepart. Alternativet vil være at egne data hentes hos hvert enkelt nettselskap.
En sluttbruker kan gi kraftleverandører og tredjeparter rett til å hente disse dataene på
vegne av sluttbrukeren. Kraftleverandører og andre tredjeparter kan da benytte disse
dataene og presentere disse på sin egen måte for å gi sluttbrukeren økt verdi.
Høringssvar fra aktører
Energi Norge poengterer at det er nødvendig å gjennomføre en grundig vurdering av
hvorvidt gjeldende krav til lagring faktisk er tilstrekkelig for å dekke formålet med
måledata. Lagring av data i 15 måneder kan vise seg ikke å være tilstrekkelig i forhold
til krav i regnskapsloven og foreldelsesloven, behovet for historiske data i forbindelse
med nettnytte og behovet knyttet til energieffektivisering
147

Prosjektgruppens vurdering
Prosjektgruppen har sett nærmere på dette og kommentert problemstillingen i
utredningen, men videre utredning hvorvidt 15 måneder er tilstrekkelig er ikke en del av
dette prosjekt og må gjøres i etterkant
D.1.7 Leveringsplikt
Høringssvar fra aktører
KS Bedrift Energi / Defo støtter rapportens forutsetting om å endre regelverket for
leveringsplikt. Videre ønsker Gudbrandsdal Energi at det utredes om datahuben kan
være leveringspliktig strømleverandør.
Prosjektgruppens vurdering
Prosjektgruppen foreslår at leveringsplikt flyttes fra nettselskap til kraftleverandør.
Hvordan dette skal løses rent praktisk og formelt må utredes videre. Datahuben vil ikke
kunne være leveringspliktig strømleverandør.
D.1.8 Oppstart av nytt anlegg
Høringssvar fra aktører
Energi Norge foreslår at et anlegg ved oppstart er «åpent» og at ansvaret går over til
leveringspliktig aktør eller kraftleverandør som sluttbrukeren har avtale med når
anlegget er ferdig og fungerer og måling av energiflyt starter.
Prosjektgruppens vurdering
Dette må vurderes sammen med nye regler rundt leveringspliktig kraftleverandør.
D.1.9 Leverandørskifte / flytninger
Høringssvar fra aktører
Gudbrandsdal Energi kommenterer at prosessene leverandørskifte og flytninger bør
legges i en datahub. Dette baseres på nøytralitet og en forventning om bedre service fra
en datahub enn fra nettselskapene.
Prosjektgruppens vurdering
Dette er i henhold til utredningens anbefaling.
D.1.10 Totalfakturering
Høringssvar fra aktører
KS Bedrift Energi / Defo har fremhevet viktigheten av at prosjektet ikke skal ta stilling
til hvorvidt totalfakturering skal innføres som en del av en felles IKT-løsning, men i
148

høyere grad skal sørge for at anbefalt løsning legger til rette for totalfakturering. Istad er
kritisk til et nytt regime med «combined billing». Videre er Energi Norge positive til at
datahuben i utgangspunktet ikke skal utarbeide avregningsgrunnlag for nett-tariffer.
Likevel mener Energi Norge at utredningen burde vurdere praktiske og økonomiske
konsekvenser av om faktureringsgrunnlaget for nett-tariffer produseres i datahuben eller
hos de enkelte nettselskaper.
Gudbrandsdal Energi og Fjordkraft støtter en leverandørsentrisk modell, hvor
kraftleverandør kan fakturere nett og kraft på en faktura.
KS Bedrift Energi / Defo mener det bør vurderes om kunden kan velge hvem som skal
stå for totalfaktureringen, nettselskap eller kraftleverandør. Dette kan også være en
overgangsløsning før datahub er fullt operativ.
Prosjektgruppens vurdering
I henhold til kommentarer fra KS Bedrift Energi / Defo har prosjektgruppen presisert
ordlyden i rapporten slik at det ikke tas stilling til innførelsen av totalfakturering, men i
stedet at den anbefalte løsning ligger til rette for det. Hva angår Energi Norges
kommentarer om en nærmere utredning av praktiske og økonomiske konsekvenser
vedrørende utarbeidelse av avregningsgrunnlag for nett-tariffer: Utredningen har på et
overordnet nivå vurdert økonomien ved å utarbeide avregningsunderlaget i datahuben
og dette viser at det sannsynligvis er kostnadsbesparende å flytte dette fra
nettselskapene til datahuben.
Prosjektgruppen har vurdert det som hensiktsmessig at kraftleverandør er den som har
kundekontakten, og har ansvaret for totalfakturering. Beslutning om totalfakturering er
ikke innenfor mandatet til utredningen.
D.1.11 Løpende avregning
Energi Norge skriver: Spørsmål om dette er mest effektiv, og om kundene ønsker dette.
Dette kan være kostnadskrevende for enkelte kundegrupper. Hvis nettselskapene skal
gjøre avregningen så kommer det trolig til å bli hver mnd. Dersom en ser for seg
totalfakturering som en stor fordel bør avregning for kraft og nett være intakt
Prosjektgruppens vurdering
Dersom en sluttbruker ønsker en slik løsning og en kraftleverandør ønsker å tilby dette
mener prosjektgruppen at løpende fakturering kan gjennomføres.
D.1.12 Avregning i datahub
Høringssvar fra aktører
Gudbrandsdal Energi ønsker at det vurderes om avregning av nettleie og netteiers
tallbehandling relatert til balanseoppgaver blir lagt til datahub. Om det skal skje ved at
datahuben sender over fakturalinjer til kraftleverandør, eller om kraftleverandør mottar
prismatrise som datahuben er ansvarlig for å holde oppdatert, må utredes videre. BKK
149

Nett sier at; avregningsgrunnlag i form av priser for nettleie per anlegg består vanligvis
av tre elementer og bør legges inn (og vedlikeholdes) i hub av det enkelte nettselskap.
Prosjektgruppens vurdering
Prosjektgruppen har foreslått å legge tallbehandling relatert til balanseoppgaver i
datahuben. Utarbeidelse av avregningsunderlag for nett-tariff i datahuben er omtalt som
en opsjon i utredningen.
D.1.13 Soliditet til kraftleverandører
Høringssvar fra aktører
BKK Nett mener at nettselskapene til enhver tid skal ha tilgang til hvem som er
anleggets kraftleverandør. KS Bedrift Energi / Defo påpeker også at nettselskapene må
vite hvem som er kunde på anlegget. Dette i forbindelse med USLA, DLE, tilknytning,
varsler etc.
BKK Nett skriver videre: Ved ny kraftleverandør sin førstegangs ansvar for leveranser
til et anlegg i et nettområde er det behov for å kunne kontrollere den aktuelle
kraftleverandørens soliditet og få vurdert behov for garantistillelse.
Dersom regulator viderefører dagens lave terskel for å etablere seg som kraftleverandør
uten tilleggskrav til soliditet, kompetanse og kapasitet vil det være nettselskapene sin
oppgave å sikre seg mot «misbruk» av monopolets plikter og rettigheter overfor den
enkelte kunde på aktuelle anlegg.
KS Bedrift Energi / Defo påpeker at det må utredes hvordan skatter og avgifter skal
håndteres i en leverandørsentrisk modell.
Prosjektgruppens vurdering
Nettselskapene vil i den foreslåtte modellen vite hvem som er kraftleverandør på
anlegget, og kundedata vil bli gjort tilgjengelig.
Risiko for nettselskaper i forbindelse med totalfakturering må utredes nærmere av NVE.
Regler og rutiner for dette må utvikles. Det samme gjelder hvordan skatter og avgifter
skal håndteres.
D.1.14 AMS tilleggstjenester
Høringssvar fra aktører
KS Bedrift Energi / Defo understreker at tilleggstjenester ikke bør tilbys gjennom AMS
kanalen, da dette kan gi et begrenset tilbud for sluttbruker.
Prosjektgruppens vurdering
Prosjektgruppen er enig i kommentarer fra KS Bedrift Energi / Defo. AMS kanalen
anbefales forbeholdt nettselskapene for nettnytte formål, mens øvrig kommunikasjon av
informasjon fra AMS måler bør foregå over «åpne» og mer tilgjengelige kanaler som
f.eks. internett.
150

Høringssvar fra aktører
Energi Norge viser til at prosjektgruppen i utredningen å løfte distribusjon av
prissignaler, nett-tariffer og styringssignaler (ut over nettselskapets egne
styringssignaler) ut av nettselskapenes AMS-infrastruktur og som et alternativ løst i
datahuben og kommunisert mot kunde/kundens anlegg over internett. Energi Norge
støtter dette initiativet, under forutsetning av at:
Endelig avklaring/konklusjon foreligger senest innen utgangen av 3. kvartal
2012 slik at nettselskapene vet hvilke krav som skal stilles til målernode og
AMS-kanalen. Forskrift 301 må gjøres konsistent med den løsningen som velges
Nettselskapenes mulighet til å innføre dynamiske nett-tariffering ikke begrenses
av en slik løsning
Insentiver som nettselskapene bygger inn i nett-tariffene tilfaller kundene
Prosjektgruppens vurdering
Dette må NVE vurdere.
D.1.15 Struping og stenging
Høringssvar fra aktører
KS Bedrift Energi / Defo og Energi Norge understreker at de juridiske forhold rundt
struping og stenging må utredes videre. Energi Norge viser til at en leverandørsentrisk
modell kan bety at nettselskaper ikke vil ha noe forhold til grunnlaget for stengingen.
Derfor bør stengemeldinger gå via datahuben som sikrer høy grad av sikkerhet knyttet
til tilgang og autorisasjon. Gudbrandsdal Energi kommenterer at kraftleverandør bør ha
mulighet til å sende stengeordre ved mislikehold (jevnfør svensk modell).
Prosjektgruppens vurdering
De juridiske forhold rundt struping og stenging tas det ikke stilling til her likesom det
ikke tas stilling til tidsfrister, regler og prosedyrer for stenging. Dette må utredes videre.
D.1.16 Splitting av databaser
Høringssvar fra aktører
KS Bedrift Energi / Defo og Fjordkraft viser til nøytralitetsprinsipper og reell
konkurranse og understreker riktigheten av å splitte dagens KIS systemer i en kraft- og
en nettdel. Midlertidig mener KS Bedrift Energi / Defo at denne splitt kan vise seg å
være en unødvendig og kostbar mellomløsning på sikt. Dette baseres på en antakelse
om at når datahuben er på plass vil ikke kraftleverandørene kunne benytte informasjon i
nettselskapenes database.
Prosjektgruppens vurdering
Alle aktører, inklusiv vertikalintegrerte selskaper, må utveksle data via datahuben. For å
sikre nøytralitet betyr dette i praksis at databasene bør splittes. Prosjektet vil ikke sette
dette som et absolutt krav og endre ordlyden i utredningen for å ta hensyn til dette.
151

D.2 Fremtidens utvikling og internasjonale krav
Høringssvar fra aktører
Istad kommenterer at utredningen bare henviser lignende internasjonale løsninger, men i
høyere grad burde ha beskrevet disse for å gi større innsikt i utfordringene ved overgang
til datahub.
Prosjektgruppens vurdering
Prosjektet har innhentet erfaringer fra internasjonale løsninger. Det ble også avholdt et
seminar hvor representanter fra selskaper fra Danmark, USA, Nederland, og Finland
deltok. Erfaringene fra dette arbeidet har blitt tatt inn i prosjektet. Den korte tidsfristen
for utredningen har ikke tillatt at en grundigere beskrivelse av internasjonale løsninger
har blitt vektlagt.
D.3 Kundevennlighet
Høringssvar fra aktører
Lyse påpeker at det er vanskelig å se hvordan en datahub kommer bedre ut enn en
kommunikasjonshub når det gjelder modellenes innvirkning på sluttbrukers nytte.
Prosjektgruppens vurdering
I henhold til kommentar fra Lyse er utredningsteksten endret noe i kapittelet som
omhandler sluttbrukers nytte. Prosjektgruppen er allikevel av den oppfatning at en
datahub vil medføre mer effektive prosesser, enklere og raskere tilgang til nødvendige
data for sluttbruker og dermed høyere nytte for sluttbruker.
D.4 Økonomisk analyse
Høringssvar fra aktører
Energi Norge viser til at innføring av AMS vil gi økte kostnader for nettselskapene i
form av både høyere nettkapital og økte driftskostnader sammenlignet med dagens
kostnadsnivå. En felles IKT-løsning vil kunne redusere kostnadene i forhold til en
desentral løsning, men det bør tydelig fremgå av rapporten at besparelsene en sentral
løsning kan gi må ses opp mot den kostnadsvekst AMS-innføringen representerer for
nettselskapene.
Prosjektgruppens vurdering
Formålet med det økonomiske avsnitt er å avdekke de isolerte kostnader og besparelser
som knytter seg til henholdsvis kommunikasjonshub og datahub for å vise den relative
forskjellen mellom modellene. Eventuelle kostnader og besparelser ved innføring av
AMS eller leverandørsentrisk modell er således ikke beregnet og inngår derfor ikke i
vurderingen av modellene.
Høringssvar fra aktører
Energi Norge mener at kostnadene ved etablering og drift av kommunikasjonshub og
datahub er undervurdert. Videre ser det ikke ut som om kostnader for endringer av
152

løsninger og organisasjon hos nettselskaper og kraftleverandører er vurdert eller
inkludert i beregningsunderlaget.
Istad mener at kostnader med å drifte de sentrale IKT-løsningene og dagens løsninger i
parallell frem til alle AMS-målere er installert ikke er vurdert. En forsinkelse i
implementeringen av en felles IKT-løsning vil også kunne føre til økte kostnader. Disse
overgangskostnadene er ikke vurdert i beslutningsunderlaget og må tas med.
Prosjektgruppens vurdering
Prosjektgruppen har innhentet informasjon om kostnader fra tilsvarende internasjonale
løsninger. Investerings- og driftskostnader er i utredning anslag basert på disse
erfaringene, og kan kun verifiseres gjennom en anbudsprosess mot aktuelle
kraftleverandører. I den økonomiske analysen er det vurdert endring i årlige kostnader
ved innføring av henholdsvis kommunikasjonshub og datahub. Dette inkluderer endring
i system- og personellkostnader. Systemkostnader er da vurdert som en årlig kostnad og
ikke som en investering. Kostnader i forbindelse med reorganisering og omlegning er
ikke inkludert.
D.5 Implementering og overgangsløsninger
Høringssvar fra aktører
Energi Norge og Istad kommenterer at fremdriftsplanen fremstår for optimistisk. Istad
fremhever også at det antageligvis er mest fornuftig å utvikle løsningen stegvis.
Fremdriften bør fastsettes realistisk og holdes for å skape forutsigbarhet. Videre
fremhever Energi Norge at når det gjelder overgangsordninger og løsninger i en
oppstartsfase, da burde utredningen også ta høyde for et «worst case» scenario i stedet
for å forutsette en ideell virkelighet. Energi Norge kommenterer også at det bør lages et
eget regelverk og forretningsregler for de anlegg som ikke har AMS – noe som
utredningen ikke beskriver.
Prosjektgruppens vurdering
Prosjektgruppen fastholder den beskrevne tidsplan, men fremhever samtidig viktigheten
av å kjøre parallelle prosesser fremfor et mer sekvensielt forløp. En ytterligere
konkretisering av fremdriftsplanen og oppstilling av ulike scenarioer er ikke en del av
utredningen.
D.6 Organisering og styring av felles IKT løsning
Høringssvar fra aktører
Istad fremhever viktigheten av at Statnett SF bør stå som eneeier ved overgang til en
datahub. Istad påpeker også at lokalisering av en ny organisasjon bør legges utenfor
pressområdene med henblikk på lavest mulig kostnader.
KS Bedrift Energi / Defo mener at eierskapet til datahuben ikke er nødvendig å ta
stilling til nå men må utredes videre. Det er enighet blant aktørene om at bransjen skal
få innflytelse gjennom et representativt brukerråd. Videre viser Energi Norge til risikoen
for at en fremtidig IKT-organisasjon vil kunne utvide målsetning og bevege seg inn i
verdikjeden både mot nettselskapene og kraftleverandørene med det resultat at
153

mulighetene for utvikling begrenses hvilket vil ha betydelige samfunnsøkonomiske
kostnader.
Prosjektgruppens vurdering
Organiseringen og styring felles IKT-løsning utredes nærmere i samråd med NVE og
endelig organisering vedtas i høsten 2012. Formålet med en datahub er å legge til rette
for effektive forretningsprosesser i markedet. Datahuben skal ikke påta seg oppgaver
eller utvide sitt arbeidsfelt utover det som blir definert som infrastrukturoppgaver.
D.7 Andre innspill
D.7.1 Autorativ database
Høringssvar fra aktører
Energi Norge viser til at prosjektgruppen har beskrevet at det er mulig for nettselskaper
å bruke egne databaser for avregning av nettleien, men at de derved løper en risiko for
avvik mellom egen database og datahuben. Energi Norge poengterer at det er lite
hensiktsmessig at nettselskapene skal måtte hente data på nytt i datahuben for å avregne
nettkundene. En må derfor søke å lage løsninger som ikke fører til unødvendig mye
datautveksling.
Prosjektgruppens vurdering
Nettselskapene har ansvar for å oppdatere nødvendige data i datahuben. Dersom
rutinene er gode for disse oppdateringene burde problemet bli relativt lite, men det er
allikevel en mulighet for at det kan bli avvik mellom nettselskapenes databaser og
datahuben. Dersom det besluttes å innføre totalfakturering må rutiner og regelverk rundt
dette utformes i detalj.
D.7.2 Risikovurdering
Høringssvar fra aktører
Energi Norge viser til at risiko ved henholdsvis kommunikasjonshub og datahub kun
behandles stikkordsmessig og at det kunne være behov for en mer helhetlig og
omfattende risikovurdering av de enkelte modeller.
Prosjektgruppens vurdering
I den endelige utredningen er (teknisk) risiko ved de ulike modellene beskrevet i et nytt
kapittel som hetter ytelse og sikkerhet.
D.7.3 KILE
Høringssvar fra aktører
KS Bedrift Energi / Defo ønsker at KILE bør vurderes håndtert i datahub, dersom veldig
mye annet skal legges til datahuben. Det synes uklart hvordan dette kan håndteres.
154

Prosjektgruppens vurdering
Dette er ikke vurdert av prosjektgruppen. Mulighet for håndtering av KILE i en datahub
må vurderes i det videre arbeidet.
D.7.4 Harmonisering av nettleie
Høringssvar fra aktører
Gudbrandsdal Energi mener at nettleia i Norge bør harmoniseres i utforming. Når
nettleie blir fakturert i en ny leverandørsentrisk modell, må det ikke komme senere
korrigeringer. Ref. en del av dagens effekttariffer, hvor et gjennomsnitt av de 3 høyeste
toppene siste år danner grunnlag for betaling av forbrukt effekt etc.
Prosjektgruppens vurdering
Dette er utenfor utredningens mandat, og må håndteres av NVE.
D.7.5 FOS 301, forskriftskrav 4-2 f
Høringssvar fra aktører
Energi Norge skriver:
Statnett foreslår i rapporten å løfte distribusjon av prissignaler, nettariffer og
styringssignaler (ut over nettselskapets egne styringssignaler) ut av
nettselskapenes AMS-infrastruktur og som et alternativ løst i datahuben og
kommunisert mot kunde/kundens anlegg over internett.
Koordineringsgruppen støtter dette initiativet, under forutsetning av at:
Endelig avklaring/konklusjon foreligger senest innen utgangen av 3.
kvartal 2012 slik at nettselskapene vet hvilke krav som skal stilles til
målernode og AMS-kanalen. Forskrift 301 må gjøres konsistent med den
løsningen som velges.
Nettselskapenes mulighet til å innføre dynamiske nettariffering ikke
begrenses av en slik løsning
Insentiver som nettselskapene bygger inn i nettariffene tilfaller kundene
Prosjektgruppens vurdering
Vurderes som et innspill til NVE
155

Vedlegg E Høringssvar fra aktørene
E.1 BKK Nett AS
Generelt slutter BKK Nett opp under de gjennomarbeidede innspill som i sakens
anledning vil bli kanalisert fra Energi Norge.
Imidlertid er det noen elementer vi mener må presiseres
Forholdet mellom kraftleverandør og nettselskap
Nettselskapene må til enhver tid ha tilgang til informasjon om hvem som er anleggets
kraftleverandør.
Ved ny kraftleverandør sin førstegangs ansvar for leveranser til et anlegg i et
nettområde er det behov for nettselskapene å kunne kontrollere den aktuelle
kraftleverandørs soliditet og få vurdert behov for garantistillelse.
Ved en modell som kombinerer SCM og sentral datahub er skissen at kraftleverandøren
overta ansvar for kundens totale kundeforhold inkludert innkreving av nettleie og
avgifter, samt administrasjon av hele kundeforholdet gjennom å være kundens hoved
kontaktpunkt.
Dersom regulator viderefører dagens lave terskel for å etablere seg som kraftleverandør
uten tilleggskrav til soliditet, kompetanse og kapasitet vil det være nettselskapene sin
oppgave å sikre seg mot «misbruk» av monopolets plikter og rettigheter overfor den
enkelte kunde på aktuelle anlegg.
Vi ser det videre som helt sentralt at dathub organiseres med en logikk som sørger for å
kunne ivareta en god balanse mellom tilkoblingsplikten av anlegg(netteier) og
leveringsplikten (kraftleverandør) slik at kundens rettigheter ivaretas
Avregningsgrunnlag i form av priser for nettleie per anlegg består vanligvis av tre
elementer og bør legges inn (og vedlikeholdes) i hub av det enkelte nettselskap, som
faste avregningskriterier, identifisert via en kode per variant.
Ved bruk av engromodellen for avregning av kraftleverandør fra nettselskap vil hvert
anlegg sin tariffkode kunne være en del av grunnlagsinformasjonen som det igjen kan
kjøres kontroll mot. En løsning basert på skissert logikk vil eksempelvis kunne ivareta
nødvendig verifisering av variabel avgiftsplikt. (Under forutsetning av at
klassifiseringsplikten blir liggende hos nettselskapene)
Eksempel på ansvarsgrenser
4.2.2 Ansvar for data
Nettselskapet er de eneste som har «skrive»-rettigheter til data i DATA-HUB. De
«siler» av nettrelaterte driftsdata før de overfører kunderelaterte data til DATA-Huben.
Data-hub-en prosesserer bare «lese»-data.
DATA-Hub-en må i tillegg til et H2M grensesnitt ha et standardisert M2M grensesnitt
som HEC (Home Energy Controller) eller PC kan benytte slik at disse dataene kan
sammenstilles med andre typer data for videre maskinell bearbeiding og analyse.
156

Forholdet til tilgang dathub for enkeltkunder
BKK Nett er prinsipielt motstander av at kunder skal ha direkte tilgang til dathub. Vi
mener at det må skje via kundens kraftleverandør gjennom sikker tilgangskontroll.
Utfyllende vil en tilgang til anleggets totalhistorikk kunne organiseres via nettselskapets
lokale anleggs-base som uansett vil lagre nettnyttedata og spenningskvalitetsdata.
Oppsummert
BKK Nett mener at de skisserte løsninger via sentral HUB vil kreve vesentlig endring i
reguleringsmodell. Spesielt i forhold til roller og plikter.
Vi anser en implementering uten at nødvendige regulatoriske grep er tatt vil kunne
skape store kvalitetsmangler og kun bidra til økte kostnader gjennom opprettholdelse av
parallelle/unødvendige løsninger.
Petter A Sandøy
Divisjonssjef Nettkunde
BKK Nett AS
mobil. +47 9175 6938
www.bkk.no
157

E.2 Energi Norge
Statnett
Att: Tor Bjarne Heiberg 25.05.2012
Innspill til Statnett ESK-rapport
Bagrunn
Energi Norge viser til NVEs oppdrag til Statnett om utredning og utvikling av en sentral
IKT løsning for sluttbrukermarkedet. Videre viser vi til Energi Norges prosjekt for
avklaring av ulike forhold vedrørende innføring av Smart Strøm (AMS).
Statnetts utredning og Energi Norges arbeid på vegne av energibransjen løper parallelt,
og det har vært god kontakt og utveksling av kompetanse og synspunkter mellom
prosjektene. Samarbeidet med Statnett har brakt på det rene at det er et betydelig behov
for ytterligere detaljering og spesifisering av forretningsregler, forretningsprosesser og
ansvarsdeling utover det som er skissert i ESK-rapporten. Det synes derfor fra Energi
Norges ståsted at det er et behov for å fortsette samarbeidet for å finne gode løsninger
også etter at rapporten er sendt inn til NVE og det er tatt en beslutning om valgt løsning.
Koordineringsgruppen i Energi Norges AMS-prosjekt synes likevel det kan være
hensiktsmessig allerede nå å kommentere den foreløpige ESK-rapporten. Dette notatet
gir et kort overblikk over de momenter som koordineringsgruppen har notert, både
overordnet og konkret knyttet til spesifikke problemstillinger. Det understrekes at
notatet ikke er uttømmende og at det vil kunne bli behov for å spille inn andre
momenter på et senere tidspunkt. Det understrekes også at koordineringsgruppen i
AMS-prosjektet består av personer som sitter operativt i AMS-prosjektene i
nettselskaper. Innspill fra andre deler av kraftbransjen, og/eller innspill på mer
strategisk nivå, vil tas opp fra Energi Norge og bransjen via andre kanaler.
Hovedbudskap
Innføring av nordisk sluttbrukermarked med Supplier Centric Model, en nasjonal HUB
og AMS representerer omfattende endringer i verdikjeden, rolledelingen mellom
aktørene og kundedialogen. Nettselskapene står i nær fremtid foran betydelige
investeringer i AMS. Design og innkjøp av løsninger basert på kravene i forskrift 301
vil i stor grad skje kommende år. Endringer i rammebetingelser som påvirker designet
og oppgave/rolledeling mellom nettselskapet, en nasjonal HUB og kraftleverandører
som først avklares etter denne tid vil føre til merkostnader, risiko for feilinvesteringer,
og endringsbehov som man fra et samfunnsøkonomisk perspektiv ikke er tjent med.
158

Dersom avklaringer skyves ut i tid, uten at kravene som pålegges nettselskapene i
forskrift 301 utsettes tilsvarende, vil investeringer blir gjort på sviktende grunnlag og
kreve endringer etter kort tid. Dette bør unngås.
Koordineringsgruppen er derfor opptatt av at NVE fatter klare beslutninger senest innen
utgangen av 3. kvartal 2012 om ny rolledeling mellom nettselskap, kraftleverandør og
en nasjonal HUB. Vi ber også om at NVE fastsetter forutsigbare rammebetingelser i
form av forpliktende milepæler som angir når konkrete konklusjoner foreligger og når
løsningen skal være operativ. Dersom en slik plan viser at tidsfristene i forskrift 301
vanskelig nås, eller eventuelle forsinkelser i denne fremdriftsplanen inntreffer må – etter
koordineringsgruppen vurdering – dette medføre tilsvarende utsettelse for
nettselskapenes i det minste for de forskriftskrav som er tenkt dekket i felles IKTløsning
som for eksempel tredjepartstilgang.
Innføring av nordisk sluttbrukermarked, en nasjonal HUB og nettselskapets forpliktelser
i forskrift 301 må være synkronisert i tid og innhold for å sikre en forsvarlig innføring
av den dramatiske omveltning endringene representerer.
Konkrete overordnede kommentarer
Datahub vs Kommunikasjonshub
Det fremkommer av rapporten at Statnett anbefaler en løsning med en sentral datahub.
Koordineringsgruppen er generelt positiv til en slik løsning.
Generell risikovurdering
Løsningen med felles datahub er særdeles omfattende både med hensyn på omfang og
kompleksitet. Assosiasjon til Altinn er nærliggende. Erfaring viser at slike prosjekter
ofte må realiseres gjennom først å implementere en minimumsløsning, så stabilisere
denne og deretter begynne å bygge på funksjonalitet gradvis og kontrollert. Som
Statnett selv legger vekt på vil man ved en felles datahub innføre et «Single Point of
Failure» og en står derfor over for risiko knyttet til svakheter ved kompensasjonstiltak
som speiling og parallelle løsninger.
I rapporten nevnes ulike type risiko kun stikkordsmessig spesielt i SWOT-oppsettet.
Koordingeringsgruppen savner derfor en mer helhetlig og omfattende risikovurdering
av de ulike alternativene.
Risiko knyttet til forventet fremdrift av nasjonal datahub
Innføring av en nasjonal datahub vil ta tid. Foreslått fremdriftsplan fremstår for
koordineringsgruppen som optimistisk. Koordineringsgruppen er opptatt av at
løsningens kvalitet og egnethet må komme foran ønske om rask implementering.
Fremdriften bør fastsettes realistisk og holdes for å skape forutsigbarhet.
Økonomisk besparelse
Innføring av AMS vil gi økte kostnader for nettselskapene i form av både høyere
nettkapital og økte driftskostnader sammenlignet med dagens kostnadsnivå. En felles
IKT-løsning vil kunne redusere kostnadene i forhold til en desentral løsning, men det
bør tydelig fremgå av rapporten at besparelsene en sentral løsning kan gi må ses opp
159

mot den kostnadsvekst AMS-innføringen representerer for nettselskapene. Den
økonomiske besparelsen til nettselskapene avhenger av hvilke funksjoner/oppgaver som
legges i den felles IKT-løsningen og hvilke tilpasninger som må gjøres i nettselskapenes
systemer.
Flere av medlemmene i koordineringsgruppen stiller også spørsmålstegn ved om
besparelsene som Statnett skisserer i sine presentasjoner ved felles IKT-løsning er
realistiske.
IKT-løsningens rolle
Statnett har vært flinke til å skissere mulighetene som en sentral datahub gir både ved
etablering og i fremtiden. Flere uttrykker likevel bekymring for at en fremtidig IKTorganisasjon
vil kunne utvide målsetning og bevege seg inn i verdikjeden både mot
nettselskapene og kraftleverandørene. Bransjen er opptatt av at tjenester og funksjoner
med egenskaper som tilsier at de er naturlige monopol, eller der samfunnsøkonomisk
nytte ved en felles løsning er stor, skal kunne legges i en felles IKT-løsning. En felles
IKT-løsning må ikke ta en rolle som begrenser nettselskapenes mulighet for utvikling,
for eksempel tilknyttet smart grid mm, og ikke begrense muligheten for
kraftleverandører og tredjeparter til å utvikle markedsbaserte løsninger mot
sluttbrukermarkedet. Dersom slike muligheter begrenses vil dette ha betydelige
samfunnsøkonomiske kostnader, om enn ikke målbare i de beregninger Statnett har
gjort i denne utredningen.
Kostnader knyttet til etablering av fells IKT-løsning
Flere i koordineringsgruppen mener at kostnaden med å få etablert en felles IKT-løsning
og kostnaden med å drive forvaltningsorganisasjonen framstår undervurdert. Videre ser
det ikke ut som om kostnader for endringer av løsninger og organisasjon hos nettselskap
og kraftleverandører er vurdert eller inkludert i beregningsgrunnlaget.
Etablering av felles IKT-løsning og forskrift 301 – Spesielt om forskriftskrav 4-2 f
Statnett foreslår i rapporten å løfte distribusjon av prissignaler, nettariffer og
styringssignaler (ut over nettselskapets egne styringssignaler) ut av nettselskapenes
AMS-infrastruktur og som et alternativ løst i datahuben og kommunisert mot
kunde/kundens anlegg over internett.
Koordineringsgruppen støtter dette initiativet, under forutsetning av at:
Endelig avklaring/konklusjon foreligger senest innen utgangen av 3. kvartal
2012 slik at nettselskapene vet hvilke krav som skal stilles til målernode og
AMS-kanalen. Forskrift 301 må gjøres konsistent med den løsningen som
velges.
Nettselskapenes mulighet til å innføre dynamiske nettariffering ikke begrenses
av en slik løsning
Insentiver som nettselskapene bygger inn i nettariffene tilfaller kundene
160

Konkrete innspill til spesifikke problemstillinger
Denne delen inneholder konkrete innspill til spesifikke problemstillinger.
Problemstillingene refererer til kapittelnummer og tittel i Statnetts ESK-rapport
5.2.6.3.3 – Struping og stenging
Statnett legger primært opp til at kraftleverandørene skal totalfakturere sluttbrukerne.
Dette innebærer at kraftleverandørene får ansvaret for nettleiefordringen og
leveringsplikten og de vil derfor være interessert i å kunne benytte struping/stenging
ved manglende betaling. Det forutsettes at det kun er nettselskapet som skal ha
direkte/fysisk tilgang til stenging/struping, men at kraftleverandørene skal kunne sende
en forespørsel om stenging til nettselskapet ved manglende betaling. I en slik situasjon
vil nettselskapene ikke ha noe forhold til grunnlaget for stengingen. Slike meldinger bør
derfor gå via datahuben som kan sikre høy grad av sikkerhet knyttet til tilgang og
autorisasjon. En må også ha klare regler og ansvarsdeling ved stenging/struping og en
må derfor få avklart:
Hvem har det juridiske ansvaret for stengingen (den som stenger eller den som
sendte melding om stenging)?
Bør det være ”tidsfrister” for stengeprosessen, slik at en i større grad unngå at en
stenger anlegg der kunden har betalt i mellomtiden?
Hvilke regler og prosedyrer må kraftleverandørene følge før de kan bruke
stenging?
Skal en benytte stenging eller struping når en ”stenger” en kunde som er dårlig
betaler?
Skal kraftleverandøren betale nettselskapet for å stenge?
5.2.6.4 - Oppstart av nytt anlegg
Statnett legger opp til at et anlegg først åpnes når kunden har valgt kraftleverandør og
kraftleverandøren har send melding om åpning. Koordineringsgruppen mener på sin
side at anlegget bør være ”åpent” med en gang, blant annet i forbindelse med test av
målermontasje/kommunikasjon. Det er dermed viktig å få avklart hvilke oppgaver
netteier skal ivareta før ansvaret flyttes over til kraftleverandør.
Koordineringsgruppen foreslår at anlegg ved oppstart er ”åpent” og at ansvaret går over
til leveringspliktig aktør eller kraftleverandør som kunden har avtale med når anlegget
er ferdig og fungerer og måling av energiflyt starter.
10.1 – Overgangsordninger - Hva gjør en med anlegg som ikke har AMS
Det vil være en god del anlegg som ikke har AMS. Det må derfor lages et eget regelverk
og forretningsregler for disse målerne. Blant annet må en raskest mulig få avklart at en i
stede for å beregne JIPen, bruker standardprofiler for å fordele forbruket.
161

Statnett legger til grunn en ideell virkelighet der data fra målere i stor grad kommer inn
relativt greit og har god kvalitet. Dette er en virkelighet som koordineringsgruppen også
ønsker og som trolig vil være tilfellet på sikt. I begynnelsen derimot (2017-2019) vil det
i et ”worst case” scenario kunne oppstå problemer med målerne og datakommunikasjon
i et så stort omfang at det vil kunne gå ut over ordinær forretningsdrift/forretningsregler.
Det kan derfor være fornuftig å ta et slikt scenario med i betraktningen når en beskriver
overgangsordninger og løsninger i en oppstartsfase. Det vil kunne bli behov for noe
mildere frister og krav i en slik periode. Hvordan dette konkret skal løses må en komme
tilbake til.
5.2.1.1 – Måleverdier - Bruk av stand vs volum ved oversendelse til HUB
Statnett skriver: ”Nettselskapene skal distribuere måleverdier i form av energimengder
slik at sluttkunde og kraftleverandør slipper å forholde seg til målestander” og videre ”
Vi tror heller ikke at en sluttkunde i fremtiden vil lese av stand direkte på måleren, men
at han vil ha utstyr direkte knyttet til sin måler som loggfører forbruk i form av
volumer.” Videre har både NVE og Statnett poengtert at kraftleverandørene er
interessert i å bruke volum, fordi de da kan benytte bransjeuavhengige avregnings- og
faktureringssystemer som er vesentlig billigere i investering og drift.
Basert på dette og samtaler med Statnett oppfatter koordineringsgruppen at Statnett
ikke tror det vil være behov for Stand i fremtidig kommunikasjon med kundene. De
ønsker derfor å bruke volum.
Koordineringsgruppen tror imidlertid at stander fortsatt har en verdi for kunder i
fremtiden og at en derfor må forholde seg til begge i alle fall i en overgangsperiode.
EUs MID (Målerdirektiv) legger opp til krav om display med målerstand også i AMSmålere
nettopp for at kundene skal kunne følge forbruksutviklingen basert på stand.
Koordineringsgruppen tror derfor det vil være behov for begge deler.
AMS-målerne vil benytte stand og det er dette som vil være grunnlaget for
nettselskapenes måleverdiinnsamling. Stand vil også være output i det lokale
grensesnittet ut fra måleren. Dersom en skal bruke volum, må derfor tilkoblet utstyr som
displayer etc. regne om stand til volum.
Koordineringsgruppen tror at et hensiktsmessig kompromiss kan være at nettselskapene
leverer volum til datahuben + månedsstander. Dette innebærer at stand primært bare
finnes hos nettselskapet, mens sentral datahub vil ha lagre volum og månedsstander for
alle kunder.
5.2 Lagring
Statnett skriver følgende: ”Formålet med måledata er korrekt avregning samt underlag
for beslutningsstøtte knyttet til energieffektivisering og andre tilleggstjenester. I tillegg
vil det være viktig underlagsdata for drift og utnyttelse av distribusjons- og
overføringsnett og ved nettinvesteringer (nettnytte).” I henhold til Forskrift 301 skal
timesdata kun lagres i 15 mnd. Flere selskaper har uttrykt at dette ikke er tilstrekkelig i
forhold til krav i regnskapsloven og foreldelsesloven, behovet for historiske data i
forbindelse med nettnytte og behovet knyttet til energieffektivisering.
Koordineringsgruppen mener derfor at det er nødvendig å gjennomføre en grundig
162

vurdering av hvorvidt gjeldende krav til lagring faktisk er tilstrekkelig for å dekke
formålet med måledata.
5.2.4.5.4 – Totalfakturering i en sentralisert modell hvor datahub utarbeider
avregningsunderlag for nett-tariff (mulig opsjon)
Koordineringsgruppen stiller seg positive til at datahuben i utgangspunktet ikke skal
utarbeide avregningsunderlag for nett-tariffer og at dette kun er nevnt som en mulig
opsjon. Det bør likevel utredes praktiske og økonomiske konsekvenser av om
faktureringsgrunnlaget for nett-tariffer produseres i felles IKT-løsning eller desentralt.
5.2.1.2 - M+3 og asymmetrisk risiko
Statnett ønsker å finne et system som gir insentiver til at måledata er riktige så tidlig
som mulig. Dette kan gjøres på minst tre måter:
4. Innenfor reguleringsregimet, men uten å sette en kort deadline. På denne måten vil
nettselskaper kunne endre data i lang tid, men de vil bli straffet for dette i
inntektsrammereguleringen.
5. Det er også mulig å lage lister som viser hvilke nettselskaper som er dårligst. Denne
metoden brukes med hell i Danmark.
6. Det er også mulig å sette konkrete tidsfrister som M+3. Dersom denne metoden
velges må en vurdere hva det koster å holde en slik kvalitet, samt hva som er et
rimelig krav M+5 eller M+8 etc. Det er mulig å lage forskjellige frister basert på
ulike feil. Fra et kundeperspektiv derimot er dette trolig lite hensiktsmessig
Hvor effektive disse metodene er, er også avhengig av hvorvidt tapet går i ”spleiselaget”
eller om det går rett på bunnlinjen. Koordineringsgruppen foreslår en gradvis
innstramming av den asymmetriske risikoen over en femårs periode.
5.2.1.7 - Rimelighetskontroll
Statnett har lagt opp til tre nivåer for rimelighetskontroll. Koordineringsgruppen
anbefaler at en kun vurderer måleverdier som høyst sannsynlig riktig eller høyst
sannsynlig uriktig.
5.2.1.2 – Tidsfrister - Kl 9 tidspunktet
Dersom Statnett skal ha data klare kl 9. må de trolig ha dataene fra nettselskapene kl 7
eller kl 8. Dette gir nettselskapene svært liten tid til å behandle måledata.
Koordineringsgruppen anbefaler at kl 9 tidsfristen revurderes, og at NVE endrer
tidspunktet i forskrift 301 til for eksempel kl 11 dersom det viser seg at dette er mer
hensiktsmessig.
5.2.1.8 - Estimeringsmetoder
Statnett sine regler for historisk estimering er relativt komplekse. Koordineringsgruppen
mener at en kun bør operere med hverdager og helger. For øvrig kan en bruke historisk
periode (snitt av tre tidligere) og deretter ta hensyn til helg og hverdag.
163

5.2.4.3.1 - Løpende avregning
Spørsmål om dette er mest effektiv, og om kundene ønsker dette. Dette kan være
kostnadskrevende for enkelte kundegrupper. Hvis nettselskapene skal gjøre avregningen
så kommer det trolig til å bli hver mnd. Dersom en ser for seg totalfakturering som en
stor fordel bør avregning for kraft og nett være intakt
Autorativ database
Statnett legger opp til at datahuben skal være autorativ database. Blant annet begrunner
Statnett dette med at dersom nettselskapene benytter data fra egen database kan det
oppstå situasjoner hvor avregningsunderlaget for nett-tariff avviker fra målepunkt data
benyttet for avregning av kraft.
Statnett har likevel i møte sagt at det er mulig for nettselskaper å bruke egne databaser
for avregning av nettleien, men at man da løper risikoen for avvik mellom egen
database og datahuben. Koordineringsgruppen er av den oppfatning at det er lite
hensiktsmessig at nettselskapene skal måtte hente data på nytt i datahuben for å avregne
nettkundene. En må derfor søke å lage løsninger som ikke fører til unødvendig mye
datautveksling.
Statnett skriver flere ganger i rapporten at sentral datahub skal ha ansvar for kvaliteten.
Koordineringsgruppen tror det er behov for å klargjøre kvalitetsbegrepet og ansvar. Det
foreslås at nettselskapene er ansvarlig for kvaliteten måledataen (avregningsklare data),
mens datahuben er ansvarlig for at data blir korrekt overført til datahuben med tanke på
format, antall verdier etc.
Vennlig hilsen
Koordineringsgruppen i
Energi Norges AMS-prosjekt
164

E.3 Fjordkraft
Fra: Flaskerud Arnstein [mailto:Arnstein.Flaskerud@fjordkraft.no]
Sendt: 25. mai 2012 12:32
Til: Tor Bjarne Heiberg
Emne: SV: Utkast II av rapporten - noen kommentarer fra Fjordkraft
Hei
Jeg har samlet opp noen generelle kommentarer, og så har jeg fått noen kommentarer
knyttet til enkeltpunkter.
Mvh
Arnstein
Generelt:
Godt fornøyd med:
- Kundene får enklere brukergrensesnitt og økt valgfrihet
- Strømleverandøren i førersetet - Supplier Centric Model der kundene tar kontakt
med strømleverandøren ved kommersielle forhold.
- Like konkurransebetingelser for alle aktører
- Kostnadseffektiv løsning der en datahub håndterer meldingsutveksling og
oppfølging av alle nettselskap
- Legger til rette for tydelig rolledeling og profesjonalisering av
monopoltjenestene og salgsvirksomhetene
- Legger til rette for økt kundetilfredshet og bedret omdømme for aktørene
- Fakturering via strømleverandøren (metode er ikke endelig besluttet, men
engrosmodellen er presentert her)
- Kundeservice i hovedsak via strømleverandøren
- Vertikalt integrerte selskaper må kjøre all prosessinformasjon via datahuben (
oppstart, leverandørskifte, flytting osv). De kan ikke lenger ha egne frister og
regler internt.
Mindre fornøyd med:
- kundene skal kunne logge seg på Huben og få tilgang til måleverdier og
grunndata. Det tilbys altså et brukergrensesnitt for kunden.
Spesifikke kommentarer:
5.2.2: Forutsetning: Sluttbrukere som ønsker analyser, aggregeringer eller andre
beregninger på data må få dette via kraftleverandør eller tredjepart: Denne avviker fra
det som står i 5.6 at kunden skal ha tilgang til disse dataene(AMS) via HUB
5.5.1: Står følgende innledningsvis: Kraftleverandør ansvarlig for kundeinformasjon.
Dette er bra men stusser da når følgende står to pkt etter: Når kraftleverandør spør om
målepunkt ID må to av karakteristikkene under være med i forespørselen:
165

…..
Fødselsdto
Sluttbrukers navn
Her burde det kommet andre kriterier – da kraftleverandør er vel den med oppdaterte
data på kunden – som da kan avvike fra netteier som ikke lenger har et forhold til
dette…
5.8: Behov fra justervesnet. Tilsier ikke dette at man uansett får en kostnad rundt dette
med sentralisert informasjon? Og dermed vil deler av kostnaden uansett måtte tas? Dette
mener jeg bør inngå som del av business caset – slik at man heller ser på
tilleggskostnaden for en HUB i forhold til det man uansett må ha.
166

E.4 Gudbrandsdal Energi AS
Her følger våre kommentarer - utkast til sluttrapport - ESK .
Med hilsen
Jan Ingvald Jansrud
Markedssjef
Gudbrandsdal Energi AS
Direkte tlf. 61294647 Mob. 92235261
e-post: jj@ge.no
Internett: www.ge.no
Facebook: www.facebook.com/gekraft
Vi viser til svar fra Defo og KS Bedrift Energi som vi i hovedsak slutter oss til. Vi har
imidlertid følgende presiseringer:
Gudbrandsdal Energi har i motsetning til de fleste vertikalintegrerte selskap en stor
ekstern kundeportefølje. Det betyr at våre synspunkter vil avvike en del fra de fleste
vertikalintegrerte selskap sine synspunkter, etter som de i hovedsak har brorparten av
sine kunder i eget forsyningsområde. Vi må konkurrere på pris og kundeservice. Det må
til dels de vertikalintegrerte selskap også, men de drar stor nytte av at de har felles
fakturering som sitt største markedsføringsinstrument. I følge TNS Gallup sine høringer
er fellesfakturering av nett og kraft det kundene setter mest pris på hos disse og som de
blir anbefalt å styrke. Vi konkurrerer i et stadig mer konkurranseutsatt marked og
ønsker av den grunn å presisere følgende:
1. Vi mener at HUB-alternativet i rapporten er det riktige valget. Gjennom
at målerverdier lagres kan HUB utvikle tjenester som vil effektivisere
bransjen betydelig på en rekke områder. Det ligger også en stor
besparelse i å kunne kommunisere en til en i stedet for mange til mange.
2. Leverandørskifter og flyttinger ønskes lagt til HUB pga nøytralitet og
forventninger om bedre service fra HUB enn fra dagens netteiere. Vi
begrunner dette med dagens mange avvisninger fra netteier når nye
kunder meldes til oppstart. Etter vår standard skyldes dette netteiernes
mangel på fleksibilitet og kundeservice vis a vis kraftleverandører og
kunder.
3. Vi ønsker at KIS-systemene må deles i en nett- og en kraftdel. Dette
begrunner vi utfra nøytralitetsaspektet. En unngår således at intern
kraftleverandør i vertikalintegrerte selskap blir favorisert ved at de har
full tilgang til opplysninger om hvilken kraftleverandør som leverer til
hvilke kunder.
4. Vi ønsker at det utredes om leveringspliktig strøm kan forsynes fra HUB.
I dag har intern kraftleverandør store fordeler vis a vis disse kundene.
167

5. Vi ønsker på sikt en leverandørsentrisk modell, hvor kraftleverandør kan
fakturere nett og kraft på én faktura. Ved en slik løsning blir konkurransesituasjonen
mer rettferdig og lik. Vi mener at netteier i en slik modell må
sikres sin inntekt, men da ikke nødvendigvis via bankgaranti, med mindre
det i enkelttilfeller er nødvendig. Oppgjør bør kunne sikres via skarpe
frister for innbetaling av nettleie. Kraftleverandør bør fakturere
etterskuddsvis minimum hver mnd. kraft og nett. Kraftleverandør bør ha
brorparten av fakturerte kroner på konto 45 dager etter forbruksmnd. Frist
for kraftleverandør til å gjøre opp med Netteier kan f.eks. settes til
1mnd+15 dager etter forbruksmnd., og videre utestengelse ved
gjentagende mislighold. Innbetalinger bør fortrinnsvis skje på en faktura
mot HUB. Vi ser for oss at dette må utredes videre.
6. Vi ønsker at det vurderes om avregning av nettleie og netteiers
tallbehandling relatert til balanseoppgaver blir lagt til HUB. Det er viktig
at HUB har god oppetid slik at en fremtidig faktureringsfunksjon ikke blir
forsinket. Om det skal skje ved at HUB sender over fakturalinjer til
kraftleverandør, eller om kraftleverandør mottar prismatrise som HUB er
ansvarlig for å holde oppdatert, må utredes videre.
7. Kraftleverandør bør ha mulighet til å sende stengeordre ved mislighold,
ref. svensk modell.
8. Nettleia i Norge bør harmoniseres i utforming. Når nettleie blir fakturert i
en ny leverandørsentrisk modell, må det ikke komme senere korrigering.
Ref. en del av dagens effekttariffer, hvor et gjennomsnitt av de 3 høyeste
toppene siste året danner grunnlag for betaling av forbrukt effekt etc.
9. Kundedata bør kunden motta fra kraftleverandør og ikke fra HUB. Det er
ingen som logger seg på BBS for å se på eFakturaen.
168

E.5 Istad AS
169

170

171

E.6 KS Bedrift Energi
172

173

174

175

Vedlegg F Kapasitetsberegning
F.1 Oppsummering
F.1.1 Datahub
Tabellen under gir en oppsummering av kapasitetsbehovet for de forskjellige casene
omhandlet i dette vedlegget.
RESSURSER↓
Kommunikasjon
Minutter basert
på en 100 Mbps
linje
Prosessering
minutter basert
på en 1.8 Mtcp
kapabilitet
Måleverdiinnsending
Balanseavregning faktureringsunderlag
nettleie
Andre
Data til Data fra Data til Data fra Data til Data fra Tilfeldige
hub hub hub hub hub hub oppslag
1,403 1,402 0,11 0,07 11,63 11,62 kontinuerlig
4,5 < 1 45 kontinuerlig
Lagring (GB/år) 89 1 79 -
F.1.2 Kommunikasjonshub basert på aktiv meldingshub
Tabellen under gir en oppsummering av kapasitetsbehovet for de forskjellige casene
omhandlet i dette vedlegget.
Balanseavregning
Måleverdiinnsending
faktureringsunderlag
nettleie
Andre
RESSURSER↓
Kommunikasjon
Minutter basert
på en 100 Mbps
linje
Prosessering
minutter basert
på en 1.8 Mtcp
kapabilitet
Data til
hub
Data fra
hub
Data til
hub
Data fra
hub
Data til
hub
Data
hub
fra
Tilfeldige
oppslag
1,97 1,97 0,029 0,025 15,25 15,23 kontinuerli
g
9 < 1 90 kontinuerli
g
Lagring (GB/mnd) 8 1 7 -
F.1.3 kommunikasjonshub
Tabellen under gir en oppsummering av kapasitetsbehovet for de forskjellige casene
omhandlet i dette vedlegget.
RESSURSER↓
Kommunikasjon
Minutter basert
på en 100 Mbps
Måleverdiinnsending
Balanseavregning faktureringsunderlag
nettleie
Andre
Data til Data fra Data Data fra Data til Data fra Tilfeldige
hub hub til hub hub hub hub oppslag
1,40 1,40 0,11 0,07 11,63 11,62 kontinuerlig
176

RESSURSER↓
linje
Prosessering
minutter basert
på en 1.8 Mtcp
kapabilitet
Balanseavregning
Data
til hub
Data fra
hub
Måleverdiinnsending
Data til Data fra
hub hub
faktureringsunderlag
nettleie
Data til Data fra
hub hub
Andre
Tilfeldige
oppslag
< 1 < 1 < 1 kontinuerlig
Lagring (GB/år) - - - -
177

F.2 Volum
F.2.1 Måleverdier
Tabellen nedenfor viser antatt oppbygning av måleverdier.
Felt
navn
SQL
Datatyp
e
Bytes Rekkevidde Head
er
Body
anta
ll
#/
meldin
g
måler_I INT 4 0 - 4294967295 B 4 1 4
D
verdi n SMALLIN 2 0 - 65.535 B 2 24 48
T
status TINYINT 1 0 - 255 B 1 24 24
sendt DATETI
ME
H 0
8 DATE: januar 1,1 A.D. -
desember 31, 9999 A.D.
TIME: 00:00:00 -
23:59:59.9999999
SUM 76
total/
meldin
g
Tabellen nedenfor viser ekstra antatt ekstra volumbelastning grunnet behovet for å
ettersende data med bedre kvalitet.
Ekstra data pga senerer oppdateringer
D+5 M+3 M++ SUM
20 % 4 % 1 % 25 %
Tabellen viser den totale volumberegningen av melingsinnhold.
antall kunder måler_ID byte/linje Byte
/melding
antall byte antall byte
+25%
Små 106 3 029 321 074 76 230 212 24 402 472 30 503 090
Middels 18 30 500 549 000 76 2 318 008 41 724 144 52 155 180
Store 6 305 000 1 830 000 76 23 180 008 139 080 048 173 850 060
SUM 130 2 700 074 25 728 228 256 508 330
F.2.2 Balanseavregning
Tabellen nedenfor viser antatt oppbygning av måleverdier.
Felt navn SQL
Datatype
Bytes Rekkevidde Header
Body
antall #/
melding
total/
melding
tid TIME(0) 3 00:00:00 - 23:59:59 H 0 0 0
Nettselskap-ID SMALLINT 2 0 - 65.535 H 0 0 0
Agreggert beløp INT 4 0 - 4294967295 B 4 168 672
sendt DATETIME 8 DATE: januar 1,1 A.D. - H 0
desember 31, 9999 A.D.
TIME: 00:00:00 -
23:59:59.9999999
SUM 1182
178

Tabellen nedenfor viser ekstra antatt ekstra volumbelastning grunnet behovet for å
ettersende data med bedre kvalitet. Her er det lagt på 85% totalt. Totalvolumet er likevel
svært begrenset i forhold til de andre overføringene.
Ekstra data pga senere oppdateringer
D+5 M+3 M++ SUM
60 % 20 % 5 % 85 %
Tabellen viser den totale volumberegningen av melingsinnhold.
antall kunder måler_ID byte/linje Byte
/melding
antall byte antall byte
+25%
Små 106 110 11 660 1 182 130 028 13 782 968 17 228 710
Middels 18 110 1 980 1 182 130 028 2 340 504 2 925 630
Store 6 110 660 1 182 130 028 780 168 975 210
SUM 130 14 300 390 084 16 903 640 21 129 550
F.2.3 Nettleie-faktureringsgrunnlag
Tabellen nedenfor viser antatt oppbygning av måleverdier.
Felt navn SQL
Datatype
Bytes Rekkevidde Header
Body
antall #/
melding
total/
melding
måler_ID INT 4 0 - 4294967295 H 0 1 0
status TINYINT 1 0 - 255 B 1 0 0
post TINYINT 1 0 - 255 B 1 10 10
beskrivelse NCHAR 80 40 Unicode characters B 50 10 500
beløp INT 4 0 - 4294967295 B 4 10 40
Antall INT 4 0 - 4294967295 B 4 10 40
enheter
enhetspris INT 4 0 - 4294967295 B 4 10 40
sendt DATETIME 8 DATE: januar 1,1 A.D. - H 0
desember 31, 9999 A.D.
TIME: 00:00:00 -
23:59:59.9999999
SUM 630
Tabellen nedenfor viser ekstra antatt ekstra volumbelastning grunnet behovet for å
ettersende data med bedre kvalitet.
Ekstra data pga senere oppdateringer
D+5 M+3 M++ SUM
20 % 4 % 1 % 25 %
179

Tabellen viser den totale volumberegningen av meldingsinnhold.
antall kunder måler_ID byte/linje Byte
/melding
antall byte
antall byte
+25%
Små 106 3029 321074 630 1908282 202277892 252847365
Middels 18 30500 549000 630 19215012 345870216 432337770
Store 6 30000 1830000 630 192150012 1152900072 1441125090
SUM 130 2700074 213273306 1701048180 2126310225
180

F.3 Datahub
F.3.1 Kommunikasjonsbehov
F.3.1.1 Måleverdi-innsamling – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 256 508 330
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 915 160 193
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 052 434 222
Bitvolum (bits) 8 419 473 775
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.023387427
Påkrevet total overføringstid (minutter) 1.403245629
181

F.3.1.2 Måleverdi-innsamling – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 256 508 330
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 914 546 068
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 051 727 978
Bitvolum (bits) 8 413 823 825
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.023371733
Påkrevet total overføringstid (minutter) 1.402303971
F.3.1.3 Balansevolum – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 970 080
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 215 592
Bitvolum (bits) 689 724 735
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001915902
Påkrevet total overføringstid (minutter) 0.114954122
182

F.3.1.4 Balansevolum – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 919 771
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 157 736
Bitvolum (bits) 689 261 890
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001914616
Påkrevet total overføringstid (minutter) 0.114876982
F.3.1.5 Nettleie-faktureringsgrunnlag – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
NETTFAKTURA-GRUNNLAG FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 2 126 310 225
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 2 338 941 248
XML Overhead 300%
Totalt applikasjonsdata (bytes) 7 016 823 744
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 7 586 164 848
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 8 724 089 575
Bitvolum (bits) 69 792 716 599
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.193868657
Påkrevet total overføringstid (minutter) 11.63211943
183

F.3.1.6 Nettleie-faktureringsgrunnlag – til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
NETTFAKTURA-GRUNNLAG TIL KRAFLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 2 126 310 225
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 2 338 941 248
XML Overhead 300%
Totalt applikasjonsdata (bytes) 7 016 823 744
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 7 581 074 095
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 8 718 235 210
Bitvolum (bits) 69 745 881 677
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.19373856
Påkrevet total overføringstid (minutter) 11.62431361
F.3.2 Serverkapasitetsbehov
F.3.2.1 Måleverdier
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall Linjer 2 700 074
Antall SQL-transaksjoner pr linje 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per batch 8 100 222
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 4.5001
184

F.3.2.2 Balanseavregning
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall linjer per faktureringsgrunnlag 14 300
Antall linjer per faktureringsgrunnlag 1
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per batch 42 900
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 0.0238
F.3.2.3 Nettleie-faktureringsgrunnlag
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall faktureringsgrunnlag 2 700 074
Antall SQL-transaksjoner pr linje 1
Antall linjer per faktureringsgrunnlag 10
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per batch 81 002 220
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 45.0012
F.3.3 Lagringsbehov
Tabellen under viser estimert lagringsbehovet pr år. I en slik løsning uten database, kan
data slettes raskt – f eks etter en måned slik at totalbehovet er en tolvdel av det som
vises i tabellen.
Informasjonstype Byte Tid/år GB / år
Måleverdier, lagringsbehov pr batch 256 508 330 365 89,288
Balanseavregning, lagringsbehov pr batch 21 129 550 52.3 1,054
Nettleie-faktureringsgrunnlag pr batch 2 126 310 225 12 24,334
SUM 114,676
185

F.4 Kommunikasjonshub basert på aktiv Meldingstjeneste
F.4.1 Kommunikasjonsbehov
F.4.1.1 Måleverdi-innsamling – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 256 508 330
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 915 160 193
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 052 434 222
Bitvolum (bits) 8 419 473 775
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.023387427
Påkrevet total overføringstid (minutter) 1.403245629
186

F.4.1.2 Måleverdi-innsamling – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Rådata (bytes) 256 508 330
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 914 546 068
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 051 727 978
Bitvolum (bits) 8 413 823 825
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.023371733
Påkrevet total overføringstid (minutter) 1.402303971
Rådata (bytes) 256 508 330
F.4.1.3 Balansevolum – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 970 080
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 215 592
Bitvolum (bits) 689 724 735
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001915902
Påkrevet total overføringstid (minutter) 0.114954122
187

F.4.1.4 Balansevolum – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 919 771
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 157 736
Bitvolum (bits) 689 261 890
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001914616
Påkrevet total overføringstid (minutter) 0.114876982
F.4.1.5 Nettleie-faktureringsgrunnlag – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 129 550
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 242 505
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 727 515
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 75 385 166
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 692 941
Bitvolum (bits) 693 543 528
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.00192651
Påkrevet total overføringstid (minutter) 0.115590588
188

F.4.1.6 Nettleie-faktureringsgrunnlag – til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 129 550
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 242 505
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 727 515
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 75 334 578
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 634 765
Bitvolum (bits) 693 078 120
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001925217
Påkrevet total overføringstid (minutter) 0.11551302
F.4.2 Serverkapasitetsbehov
F.4.2.1 Måleverdier
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall Linjer 5 400 000
Antall SQL-transaksjoner pr linje 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 16 200 000
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 9,0000
189

F.4.2.2 Balanseavregning
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall linjer per faktureringsgrunnlag 28 600
Antall linjer per faktureringsgrunnlag 1
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 85 800
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 0,0477
F.4.2.3 Nettleie-faktureringsgrunnlag
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall faktureringsgrunnlag 5 400 000
Antall SQL-transaksjoner pr linje 1
Antall linjer per faktureringsgrunnlag 10
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 162 000 000
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 90,0000
F.4.3 Lagringsbehov
Tabellen under viser estimert lagringsbehovet pr kvartal – det er ikke bestemt hvor
lenge slike data skal lagres. Dette er heller ikke en database tilrettelagt for strukturert
lagring og gjenfinning av data. Hvis behovet er en måneds lagring med denne løsning er
lagringsbehovet på under 10% av det som er oppgitt i tabellen.
Informasjonstype Byte Tid/år GB / år
Måleverdier, lagringsbehov pr batch 256 508 330 90 22,016
Balanseavregning, lagringsbehov pr batch 21 129 550 13 262
Nettleie-faktureringsgrunnlag pr batch 2 126 310 225 3 6,083
SUM 28,362
190

F.5 Kommunikasjonshub basert på ”passiv” meldingsnode
F.5.1 Kommunikasjonsbehov
F.5.1.1 Måleverdi-innsamling – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 256 508 330
Minimum antall meldinger 14 300
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 349 915 930
TCP/IP protokoll overhead (kompensert for små meldinger) 10%
Data overført på lag 3 (bytes) 1 282 356 052
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 474 709 460
Bitvolum (bits) 11 797 675 683
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.032771321
Påkrevet total overføringstid (minutter) 1.96627928
191

F.5.1.2 Måleverdi-innsamling – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 256 508 330
Minimum antall meldinger 14 300
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 282 159 163
XML Overhead 300%
Totalt applikasjonsdata (bytes) 846 477 489
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 349 915 930
TCP/IP protokoll overhead (kompensert for små meldinger) 10%
Data overført på lag 3 (bytes) 1 282 356 052
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 1 474 709 460
Bitvolum (bits) 11 797 675 683
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.032771321
Påkrevet total overføringstid (minutter) 1.96627928
F.5.1.3 Balansevolum – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 130
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 970 080
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 215 592
Bitvolum (bits) 689 724 735
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001915902
Påkrevet total overføringstid (minutter) 0.114954122
192

F.5.1.4 Balansevolum – data til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØR
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 21 013 207
Minimum antall meldinger 110
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 23 114 527
XML Overhead 300%
Totalt applikasjonsdata (bytes) 69 343 581
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 0
TCP/IP protokoll overhead (kompensert for små meldinger) 8%
Data overført på lag 3 (bytes) 74 919 771
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 86 157 736
Bitvolum (bits) 689 261 890
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.001914616
Påkrevet total overføringstid (minutter) 0.114876982
F.5.1.5 Nettleie-faktureringsgrunnlag – data fra nettselskap
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM FRA NETTSELSKAP
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 2 126 310 225
Minimum antall meldinger 14 300
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 2 338 941 248
XML Overhead 300%
Totalt applikasjonsdata (bytes) 7 016 823 744
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 2 219 717 825
TCP/IP protokoll overhead (kompensert for små meldinger) 10%
Data overført på lag 3 (bytes) 9 949 123 599
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 11 441 492 139
Bitvolum (bits) 91 531 937 114
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.254255381
Påkrevet total overføringstid (minutter) 15.25532285
193

F.5.1.6 Nettleie-faktureringsgrunnlag – til kraftleverandør
Tabellen under viser anslått kommunikasjonsbehov
MÅLEVOLUM TIL KRAFTLEVERANDØRENE
Beskrivelse (enhet)
ressursbehov
Rådata (bytes) 2 126 310 225
Minimum antall meldinger 14 300
Ekstra meldingsoverheadfaktor (små meldinger) 0
Antatt overhead for feilkorrigering 10%
Antall overføringer pr dag 1
Gjennomsnitt rådata overført (bytes) 2 338 941 248
XML Overhead 300%
Totalt applikasjonsdata (bytes) 7 016 823 744
TSL Overhead (trer inn hvis mer enn 1000 sporadiske sesjoner) 2 219 717 825
TCP/IP protokoll overhead (kompensert for små meldinger) 10%
Data overført på lag 3 (bytes) 9 949 123 599
Ethernet overhead med TCP/IP 15%
Data overført på lag 2 (bytes) 11 441 492 139
Bitvolum (bits) 91 531 937 114
Antatt kapasitet på sentral link (b/s) 100 000 000
Påkrevet total overføringstid (timer) 0.254255381
Påkrevet total overføringstid (minutter) 15.25532285
F.5.2 Serverkapasitetsbehov
F.5.2.1 Måleverdier
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall Linjer 14 300
Antall SQL-transaksjoner pr linje 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 42 900
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 0,0238
194

F.5.2.2 Balanseavregning
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall linjer per faktureringsgrunnlag 14 300
Antall linjer per faktureringsgrunnlag 1
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 42 900
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 0,0238
F.5.2.3 Nettleie-faktureringsgrunnlag
Tabellen viser nødvendig beregningskapasitet
Beskrivelse (enhet)
Volum
Antall faktureringsgrunnlag 14 300
Antall SQL-transaksjoner pr linje 1
Antall linjer per faktureringsgrunnlag 10
Antall SQL-transaksjoner pr linje (fletting og defletting) 1
Skaleringsfaktor i forhold til teoretisk kapasitet 3
Total antall transaksjoner per døgn 429 000
Antatt kapabilitet /minutt 1 800 000
Total minutter for å prosessere alle transaksjoner 0,2383
F.5.3 Lagringsbehov
Det er ikke noe lagringsbehov for denne løsningen utover en logg.
195

Vedlegg G Sårbarhetsberegning
Sårbarhetsanalysene under er gjort for infrastruktur som er påkrevet for å realisere
sentral databuh og kommunikasjonshub. Vurderingen er gjort med utgangspunkt i en
gitt infrastruktur for begge løsningene og for en gitt informasjon.
I tabellene brukes følgende terminologi:
System: Dette er en samling av delsystemer som beskrevet i kapittel ZXZX
Trussel: Dette er tenkt trusler som kan utløse uønskede hendelser mot systemet
Årsak: Dette er grunnen til eller motivasjonen bak en hendelse
Virkning: Dette beskriver hvordan en faktisk hendelse vil virke inn på
virksomheten
I: Integritet, dette beskriver i hvilken grad man kan stole på innholdets
nøyaktighet
K: Konfidensialitet, dette beskriver i hvilken grad man kan stole på at bare
autorisert personell får tilgang til informasjonen
T, Tilgjengelighet, dette beskriver i hvilken grad løsningen er tilgjengelig i
ønsket tidspunkt/utstrekning
Gs: Dette er en mest dominerende sikkerhetskategorien av I, K, T som definert
over
Konsekvens: Dette er konsekvensen av en faktisk hendelse kategorisert som;
Svært-Høy, Høy, Middels, Lav, Svært-Lav
A, B, C: Dette er brukt for å identifisere ulike virkninger av en hendelse og for å
angi deres sikkerhetskategori (I, K, T)
Ks: Dette er den mest alvorlig hendelsen av de som er beskrevet på samme linje
Sannsynlighet: Dette er vurdert sannsynlighetskategori for at en hendelse
inntreffer; Svært-Høy, Høy, Middels, Lav, Svært-Lav
Ss: Dette er den hendelsen med høyst sannsynlighet på samme linje
Rikiso: Dette er kombinasjonen av Ks og Ss for hver linje
Konsekvens:
1. Svært høy: Kritiske funksjoner nede en uke, omfattende feilfakturering, utstrakt
utilsiktet struping av anlegg og/eller langvarige negative medieoppslag
2. Høy: Kritiske funksjoner nede i en dag, noe feilfakturering, noe utilsiktet
struping av anlegg og/eller noe negative medieoppslag
3. Middels: Kritiske funksjoner nede i en time
4. Lav: Redusert funksjonalitet i en time
5. Svært lav: Redusert funksjonalitet i inntil fem minutter
6. Ingen: Ingen konsekvens
Sannsynlighet:
1. Svært høy: inntreffer 37 ganger pr år med utstrekning på 24 timer hver gang (ca
10% nedetid)
2. Høy: inntreffer 11 gang pr år med utstrekning på 8 timer (ca 1% nedetid)
3. Middels: inntreffer 2 gang pr år med utstrekning på 4 timer (ca 0,1 % nedetid)
4. Lav: inntreffer 1 gang pr fjerde år med utstrekning på 2 timer (ca 0,01 %
nedetid)
196

5. Svært lav: inntreffer 1 gang pr tiende år med utstrekning på 1 time (ca 0,01 %
nedetid)
6. Aldri: Aldri
Figuren under gir en grovoppstilling av samlet sannsynlighet for uønskede hendelser og
konsekvensene av disse. Det må poengteres at dette er svært overordnet. En detaljert
ROS-analyse bør foretas hvor alle elementene i tabellene betraktes hver for seg og
evalueres i sin riktige sammenheng. Dette vil være hensiktsmessig når mest mulig av
modellen og valgt implementering er kjent.
197

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
G.1 Infrastruktur datahub
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
Sentral
infrastruktur
Nasjonalt
nett
Sentrale
servere
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3. Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d]
1. (deler av) intern
infrastruktur blir
utilgjengelig [A],
manipulasjon
datatrafikk [B], datalekkasje
[C]
2. Hevn [a], aktivisme [b] 2. (deler av) intern
infrastruktur blir
utilgjengelig [A],
manipulasjon
datatrafikk [B], datalekkasje
[C]
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
4. HW/SW feil 4. Slurvmanglende/utilstrekkelig
IT governance [a]
1. Logiske angrep av
eksterne aktører
2. Fysiske angrep av
eksterne aktører
3. Utro tjener i
nettleverandører
1. hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d]
2. hevn [a], utpressing
[b], aktivisme [c]
3. hevn [a], utpressing
[b], aktivisme [c]
3. (deler av) intern
infrastruktur blir
utilgjengelig [A],
redusert ytelse [B]
4. (deler av) intern
infrastruktur blir
utilgjengelig [A],
redusert ytelse [B]
1. DOS (inkl. redusert
ytelse) [A], data
lekkasje [B], manipulasjon
av
datatrafikk [C].
2. WAN blir
utilgjengelig [A], eller
man få lave tilgjengelighet
(f.e. bøying av
fiber) [B]
3. DOS (inkl. redusert
ytelse) [A], data lekkasje
[B], manipulasjon
av datatrafikk
[C].
4. Feilkonfigurasjon 4. Slurv -
4. (deler av) WAN blir
manglende/utilstrekkelig utilgjengelig [A],
IT governance [a] redusert ytelse [B]
5. Ytre miljø (graving, 5. Manglende redundans 5. WAN blir
flom, osv.)
[a]
utilgjengelig [A]
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d],
konkurransevridning[e],
økonomisk gevinst [f]
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [c]
«Hoppe» videre til
DB [A], system blir
utilgjengelig [B],
manipulasjon av forretningslogikk
eks
faktura feil, selv om
grunnlaget ok) [C]
2. System blir utilgjengelig
[A], manipulasjon
av forretningslogikk
(for
eks. 10% av faktura
blir feil, selv om
grunnlaget i DB er
ok) [B]
a b c d e f Ss A B C Ks A B C Gs
L M L M M H M M H T I K T M
L M M H M M H T I K T M
L L H H T T T M
L L M M T T T L
L L L L L M M M T T T L
M M M M M M M T T T M
M L L M M M M M T K I I M
L L M L M T T I L
L L H H T T M
L M M L L M H H H H K T I T-I M
L M L M H M H T I T-I M
198

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
Sentrale
støttesystemer
Sentral
database
3.
Feilkonfigurasjon/drift
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
3. System blir utilgjengelig
[A],
redusert ytelse [B]
4. HW/SW feil 4. Slurv ,
4. System blir utilgjengelig
[A], redu-
manglende/utilstrekkelig
IT governance [a] sert ytelse [B]
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3.
Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d],
konkurransevridning [e]
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [b]
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
4. HW/SW feil 4. Slurv -
manglende/utilstrekkelig
IT governance [a]
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3.
Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d],
konkurransevridning [e],
økonomisk gevinst [L]
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [c]
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
4. HW/SW feil 4. Slurv ,
manglende/utilstrekkelig
IT governance [a]
1. «Hoppe» videre til
DB [A], system blir
utilgjengelig [B],
redusert driftsevne
[C]
2. System blir utilgjengelig
[A],
redusert ytelse [B],
redusert driftsevne
[C]
3. System blir utilgjengelig
[A], redusert
ytelse [B], redusert
driftsevne [C]
4. System blir utilgjengelig
[A], redusert
ytelse [B], redusert
driftsevne [C]
1. Tap av data [A]
uautorisert endring
av data [B],
datalekkasje [C]
2. Tap av data [A]
uautorisert endring
av data [B], datalekkasje
[C]
3. Tap av data [A],
datalekkasje [B]
4. Tap av data [A],
datalekkasje [B]
a b c d e f Ss A B C Ks A B C Gs
L L H M H T T T M
L L H M H T T T M
M M M M L M H H M H K-
I
T T K-I M
H M L H H M M H T T T T H
L L H M M H T T T T M
L L H M M H T T T T M
M M M M L L M M M L M T I K T M
M M L M M H L H T I K T-I M
L L M L M I K I L
L L M L M T T T L
199

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
G.2 Infrastruktur kommunikasjonshub
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
Lokal
infrastruktur
Nasjonalt
nett
Lokale
servere
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3. Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d]
1. (deler av)
intern infrastruktur
blir
utilgjengelig [A],
manipulasjon
datatrafikk [B],
datalekkasje [C]
2. Hevn [a], aktivisme [b] 2. (deler av)
intern infrastruktur
blir
utilgjengelig [A],
manipulasjon
datatrafikk [B],
datalekkasje [C]
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
4. HW/SW feil 4. Slurvmanglende/utilstrekkelig
IT governance [a]
1. Logiske angrep av
eksterne aktører
2. Fysiske angrep av
eksterne aktører
3. Utro tjener i
nettleverandører
1. hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d]
2. hevn [a], utpressing
[b], aktivisme [c]
3. hevn [a], utpressing
[b], aktivisme [c]
4. Feilkonfigurasjon 4. Slurv - manglende/
utilstrekkelig IT
governance [a]
5. Ytre miljø (graving,
flom, osv.)
1. Hacking
(inntrenging)
5. Manglende redundans
[a]
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d],
konkurransevridning[e],
økonomisk gevinst [f]
3. (deler av)
intern infrastruktur
blir utilgjengelig
[A],
redusert ytelse
[B]
4. (deler av)
intern infrastruktur
blir utilgjengelig
[A], redusert
ytelse [B]
1. DOS (inkl.
redusert ytelse)
[A], data lekkasje
[B], manipulasjon
av datatrafikk [C].
2. WAN blir
utilgjengelig [A],
eller man få lave
tilgjengelighet
(f.e. bøying av
fiber) [B]
3. DOS (inkl.
redusert ytelse)
[A], data lekkasje
[B], manipulasjon
av datatrafikk [C].
4. (deler av) WAN
blir utilgjengelig
[A], redusert
ytelse [B]
5. WAN blir
utilgjengelig [A]
«Hoppe» videre
til DB [A], system
blir utilgjengelig
[B], manipulasjon
av forretningslogikk
eks faktura
feil, selv om
grunnlaget ok) [C]
a b c d e f Ss A B C Ks A B C Gs
L M L M M M M L M T I K T M
L M M M L L M T I K T M
SH SH L L T T T M
SH SH L L T T T M
L L L L L L M M T T T L
M M M M M M M T T T M
M L L M M L H H T K I I M
SH SH M L M T T I H
SH SH M M T T H
L L L L L L L M M M K T I T-I L
200

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
Lokale
støttesystemer
Lokal
database
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3.
Feilkonfigurasjon/drift
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [c]
3. Slurv - manglende/
utilstrekkelig IT
governance [a]
4. HW/SW feil 4. Slurv , manglende/
utilstrekkelig IT
governance [a]
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3.
Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d],
konkurransevridning [e]
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [b]
3. Slurv -manglende/
utilstrekkelig IT
governance [a]
4. HW/SW feil 4. Slurv - manglende/
utilstrekkelig IT
governance [a]
1. Hacking
(inntrenging)
2. Utro tjener
(misbruk av
tilgangsrettigheter)
3.
Feilkonfigurasjon/drift
1. Hevn [a], utpressing
[b], nysgjerrighet [c],
aktivisme [d], konkurransevridning
[e],
økonomisk gevinst [L]
2. Hevn [a], aktivisme
[b], bestikkelse fra
eksterne [c]
3. Slurv -
manglende/utilstrekkelig
IT governance [a]
4. HW/SW feil 4. Slurv ,
manglende/utilstrekkelig
IT governance [a]
2. System blir
utilgjengelig [A],
manipulasjon av
forretningslogikk
(feks 10% av
faktura blir feil,
selv om grunnlaget
i DB er ok)
[B]
3. System blir
utilgjengelig [A],
redusert ytelse
[B]
4. System blir
utilgjengelig [A],
redusert ytelse
[B]
1. «Hoppe»
videre til DB [A],
system blir
utilgjengelig [B],
redusert
driftsevne [C]
2. System blir
utilgjengelig [A],
redusert ytelse
[B], redusert
driftsevne [C]
3. System blir
utilgjengelig [A],
redusert ytelse
[B], redusert
driftsevne [C]
4. System blir
utilgjengelig [A],
redusert ytelse
[B], redusert
driftsevne [C]
1. Tap av data [A]
uautorisert
endring av data
[B], datalekkasje
[C]
2. Tap av data [A]
uautorisert
endring av data
[B], datalekkasje
[C]
3. Tap av data [A],
datalekkasje [B]
4. Tap av data [A],
datalekkasje [B]
a b c d e f Ss A B C Ks A B C Gs
L L L L M M M T I T-I L
SH SH M L M T T T H
SH SH M L M T T T H
M M M M L M L M L M K-
I
T T K-I M
M M L M M L L M T T T T M
SH SH M L L M T T T T H
SH SH M L L M T T T T H
M M M M L L M M M L M T I K T M
M M L M M M L M T I K T-I M
SH SH M L M I K I H
SH 0 M L M T T T M
201

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
G.3 Informasjonsmodell – Data-hub
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
Måle-verdier
Anleggsinformasjon
Nettsekskap-info.
Krafttleverandører
-info.
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
1. Sluttkunde -
økonomisk gevinst[a],
konkurrenter – økonomisk
gevinst[b], utro
tjener - hevn[c], tidligere
ansatte - hevn[d],
aktivister - sabotasje[e]
2. Konkurrenter
konkurransevridning[a]
, aktivister -
sabotasje[b], utro
tjener - hevn[c],
tidligere ansatte -
hevn[d]
3. Aktivister skade
omdømme[a], utro
tjener - hevn[b],
tidligere ansatte -
hevn[c]
1. Utro tjener -
hevn[a], tidligere
ansatte hevn[b],
aktivister - sabotasje[c]
2. Aktivister sabotasje[a],
utro tjener
[hevn[b], tidligere
ansatte -hevn[c]
3. Aktivister skade
omdømme[a]
1. Utro - tjener
hevn[a], tidligere
ansatte - hevn[b],
aktivister - sabotasje[c]
2. Utro tjener – hevn
[a], tidligere ansatte -
hevn[b], aktivister -
sabotasje[c]
3. tidligere ansatte -
hevn[a], aktivister -
sabotasje[b]
1. Utro tjener – hevn
[a], tidligere ansatte -
hevn][b], aktivister -
sabotasje[c]
2. Utro - tjener
hevn[a], tidligere
ansatte -hevn[b],
aktivister -sabotasje[c]
1. Omdømme
tapt,
feilfakturering,
«feilstruping»
[A]
2. Omdømme
tapt, manglende
fakturering, tap
av inntekt for
nettleverandøre
r og nettselskaper
[A]
3. Omdømme
tapt Statnett,
nettleverandøre
r og nettselskaper
[A]
1. Omdømme
tapt, feilfakturering,
«feilstruping»
[A]
2. Omdømme
tapt, manglende
fakturering, tap
av inntekt for
nettleverandøre
r og nettselskaper
[A]
3. Omdømme
tapt Statnett,
nettleverandøre
r og nettselskaper
[A]
1. Forsinket
fakturering,
omdømme tapt.
[A]
2. Forsinket
fakturering, omdømme
tapt. [A]
3. Omdømme
tapt Statnett,
nettleverandøre
r og nettselskaper
[A]
1. Forsinket
fakturering, omdømme
tapt. [A]
2. Forsinket
fakturering,
omdømme tapt.
[A]
a b c d e f
S
s
A B C K
s
A
B C G
s
L L H H M M H H H T I H
L M H H H H H T T H
L M M M M M K K M
L M M M H H I I M
L M M M H H T T M
M M L L K K L
M M L M H H I I M
M H L H M M T T M
M L M L L K K L
M M M M H H I I M
M H M H H H T T H
202

SYSTEM
TRUSSEL
ÅRSAK
VIRKNING
risiko
SANNSYNLIGHET
KONSE-
KVENS
KATEGORI
a b c d e f
S
s
A B C K
s
A
B C G
s
Nett-tariffer
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
3. tidligere ansattehevn[a],
aktivister
[sabotasje][b]
1. Konkurrenter -
økonomisk gevinst[a],
utro tjener - hevn[b],
tidligere ansattehevn[c],
aktivister -
sabotasje[d]
2. Utro - tjener
hevn[a], tidligere
ansatte -hevn[b],
aktivister -sabotasje[c]
3. Konkurrenter -
økonomisk gevinst[a],
utro tjener -hevn[b],
tidligere ansatte -
hevn[c], aktivister -
skade omdømme[d]
3. Omdømme
tapt Statnett,
nettleverandøre
r og nettselskaper
[A]
1. Omdømme
tapt, feilfakturering,
feilfakturering,
tap av inntekt
for nettleverandører
og nettselskaper
[A]
2. Omdømme
tapt, manglende
fakturering, tap
av inntekt for
nettleverandører
og nettselskaper
[A]
3. Omdømme
tapt Statnett,
nettleverandører
og nettselskaper
[A]
M M M L L K K L
L M M L M H H I I M
L M L M H H T T M
L M L L M L L K K L
203

SYSTEM
TRUSSEL
ÅRSAK
VIRK-
NING
risiko
G.4 Informasjonsmodell – Kommunikasjonshub
SANNSYNLIGHET KONSEKVENS KATEGORI
a b c d e f Ss A B C Ks A B C Gs
Måle-verdier
Anleggsinformasjon
Nettsekskap-info.
Krafttleverandører-info.
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
1. Sluttkunde -
økonomisk gevinst[a],
konkurrenter
– økonomisk
gevinst[b],
utro tjener –
hevn [c], tidligere
ansatte - hevn[d],
aktivister -
sabotasje[e]
2. Konkurrenter
konkurransevridn
ing[a], aktivister -
sabotasje[b],
utro tjener -
hevn[c], tidligere
ansatte - hevn[d]
3. Aktivister
skader omdømme[a],
utro
tjener - hevn[b],
tidligere ansatte -
hevn[c]
1. Utro tjener -
hevn[a], tidligere
ansatte hevn[b],
aktivister -
sabotasje[c]
2. Aktivister
sabotasje [a],
utro tjener [hevn
[b], tidligere
ansatte -hevn[c]
3. Aktivister
skade
omdømme[a]
1. Utro - tjener
hevn[a], tidligere
ansatte - hevn[b],
aktivister -
sabotasje[c]
2. Utro tjener -
hevn[a], tidligere
ansatte -hevn[b],
aktivister -
sabotasje[c]
3. tidligere
ansatte - hevn[a],
aktivister -
sabotasje[b]
1. Utro tjener -
hevn[a], tidligere
ansatte -hevn]
[b], aktivister -
sabotasje[c]
1. Omdømme tapt,
feilfakturering,
«feilstruping» [A]
2. Omdømme tapt,
manglende
fakturering, tap av
inntekt for
nettleverandører
og nettselskaper
[A]
3. Omdømme tapt
Statnett,
nettleverandører
og nettselskaper
[A]
1. Omdømme tapt,
feilfakturering,
«feilstruping» [A]
2. Omdømme tapt,
manglende
fakturering, tap av
inntekt for
nettleverandører
og nettselskaper
[A]
3. Omdømme tapt
Statnett, nettleverandører
og
nettselskaper [A]
1. Forsinket
fakturering, omdømme
tapt. [A]
2. Forsinket
fakturering,
omdømme tapt.
[A]
3. Omdømme tapt
Statnett, nettleverandører
og
nettselskaper [A]
1. Forsinket
fakturering,
omdømme tapt.
[A]
L L H H H M H M M T I M
L H H H H M M T T M
L H H H M M K K M
L M H H M M I I M
L M H H M M T T M
M M L L K K L
M H L H M M I I M
M H L H M M T T M
H L H L L K K M
M H M H M M I I M
204

SYSTEM
TRUSSEL
ÅRSAK
VIRK-
NING
risiko
SANNSYNLIGHET KONSEKVENS KATEGORI
a b c d e f Ss A B C Ks A B C Gs
Nett-tariffer
Måle-verdier
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Uautorisert
sletning
3. Uautorisert
lesing
1. Uautorisert
endring
2. Utro - tjener
hevn[a], tidligere
ansatte -hevn[b],
aktivister –
sabotasje [c]
3. tidligere
ansatte- hevn[a],
aktivister
[sabotasje] [b]
1. Konkurrenter -
økonomisk
gevinst[a], utro
tjener - hevn[b],
tidligere ansattehevn[c],
aktivister -
sabotasje[d]
2. Utro - tjener
hevn[a], tidligere
ansatte -hevn[b],
aktivister -
sabotasje[c]
3. Konkurrenter -
økonomisk gevinst
[a], utro
tjener -hevn[b],
tidligere ansatte -
hevn[c], aktivister
-skade
omdømme[d]
1. Sluttkunde -
økonomisk gevinst[a],
konkurrenter
– økonomisk
gevinst[b],
utro tjener -
hevn[c], tidligere
ansatte - hevn[d],
aktivister -
sabotasje[e]
2. Forsinket
fakturering,
omdømme tapt.
[A]
3. Omdømme tapt
Statnett,
nettleverandører
og nettselskaper
[A]
1. Omdømme tapt,
feilfakturering,
feilfakturering, tap
av inntekt for
nettleverandører
og nettselskaper
[A]
2. Omdømme tapt,
manglende
fakturering, tap av
inntekt for
nettleverandører
og nettselskaper
[A]
3. Omdømme tapt
Statnett,
nettleverandører
og nettselskaper
[A]
1. Omdømme tapt,
feilfakturering,
«feilstruping» [A]
M H M H M M T T M
H M H L L K K M
L M M L M M M I I M
L M L M M M T T M
L M L L M L L K K L
L L H H H M H M M T I M
205