Bakgrunn

Elhub Edielstandard inneholder detaljerte beskrivelser og retningslinjer som supplerer Avregningsforskriften med rettigheter og plikter markedsaktørene har i meldingsutveksling i kraftbransjen. Elhub Edielstandard utvikles og drives av Systemstøtte for Ediel i tråd med mandatet fra Avregningsforskriften og avregningskonsesjonen.

Dokumentasjonen var opprinnelig utarbeidet før oppstart av Elhub i samarbeid med bransjerepresentanter, og har deretter blitt løpende utviklet i forbindelse med nye behov i markedet og endringer i reguleringer.

Prosessene som er beskrevet legger til rette for en leverandørsentrisk markedsmodell. Det har samtidig vært et mål å sikre en kundevennlig modell, der sluttbrukeren får løst sine behov på enklest mulig måte, uten å bli avvist eller henvist videre. En markedsmodell som er intuitiv å forstå men samtidig smidig, vil være med å øke bransjens omdømme.

Endringer til Elhub Edielstandard

Elhub utvikler kontinuerlig funksjonaliteten i Elhub systemet og oppdaterer dermed også Edielstandarden. Det kan være mange grunner til disse endringene, for eksempel nye behov hos markedsaktørene, endringer i reguleringer, feil som oppdages i daglig drift. Alle endringer beskrives i Endringsloggen.

Ikke alle endringer til Edielstandarden er koblet til endringer i Elhub systemet. Det kan for eksempel være endringer i regler for hvordan markedsprosesser skal brukes av markedsaktørene eller tydeliggjøringer og feilrettinger i dokumentasjonen.

Elhub jobber tett med representanter fra bransjen i utviklingen av Elhub systemet og Edielstandarden. Endringer med signifikant betydning for markedet blir diskutert i relevant fora, for eksempel Brukerforum og Bransjerådet. Det organiseres også dedikerte arbeidsgrupper hvor det er nødvendig å diskutere endringer i større detalj. Mer informasjon om samarbeidet i bransjen finnes i Elhub Brukeravtale Bilag 3 Styringsmodell for samhandling mellom Elhub og markedsaktører.

Driftsetting av endringer

Fordi det ofte vil være behov for markedsaktørene å tilpasse sine systemer og rutiner som resultat av endringer i Elhub må Edielstandarden oppdateres før endringer til Elhub systemet settes i produksjon. Hvor lang tid markedsaktørene til enhver tid trenger for å gjøre nødvendige endringer og gjennomføre eventuell sertifisering vil bli avtalt med representanter fra bransjen. Akkurat når endringer til Elhub systemet settes i produksjon og skal tas i bruk vil bli kommunisert separat fra oppdateringer til Edielstandarden. Informasjon om dette finnes på separate sider på elhub.no. Her vil det refereres til når en spesifikk endring settes i produksjon og i hvilken versjon av Edielstandarden endringen er beskrevet.

Versjonering av Edielstandarden

Elhub Edielstandard har tre nivåer for versjonering (Stor.Mellom.Liten, f.eks. v1.12.1). Hvilken nivå som økes for en ny versjon avhenger omfanget av endringene som er gjort.

Nivå

Endring

StorEndringer i Elhubs funksjonalitet som har stor innvirkning på markedet og krever omfattende planlegging sammen med alle markedsaktører for å kunne innføres. Vil sannsynligvis ikke være kompatibel med tidligere versjoner.
MellomEndringer i Elhubs funksjonalitet som ikke innebærer en signifikant endring i markedsmodellen men som fortsatt kan kreve utvikling av systemer hos markedsaktørene for å tas i bruk. Planlegging vil skje i samarbeid med representanter fra markedet og regulator. Edielstandarden vil publiseres i god tid før funksjonalitet settes i drift. Kan være kompatibel med tidligere versjoner.
LitenMindre endringer i funksjonalitet eller dokumentasjon som ikke har innvirkning på integrasjoner mellom systemer. Kan innføres av Elhub uten ekstern konsultasjon. Vil bli brukt for å sikre at enkle avklaringer og feilrettinger blir kontinuerlig kommunisert til markedet. Vil alltid være kompatibel med tidligere versjoner.

Hvordan lese Elhub Edielstandard

Kommunikasjonsgrensesnitt og BRS

Sett fra et målepunkt, vil Elhub kommunisere i flere retninger, avhengig av prosess: hovedsakelig overfor målepunktets kraftleverandør(er), og nettselskapet. Kommunikasjon til og fra Elhub er organisert gjennom meldinger. Disse settes sammen til de sentrale forretningsprosessene i markedet. Meldingene er gruppert i 3 hovedgrupper i tillegg til hvilken aktør de sendes til/fra:

  • Oppstart: Dekker meldinger som definerer en ny relasjon i et målepunkt
  • Oppdatering: Dekker meldinger som utveksler data i en etablert relasjon
  • Opphør: Dekker meldinger som avslutter en eksisterende relasjon i et målepunkt 

Det som normalt avgjør hvilke prosesser som får egen BRS ("Business Requirement Specification", forretningsprosess), er:

  • hvem som initierer
  • hvilken hovedgruppe den tilhører
  • om prosessen gjelder datoer frem eller tilbake i tid
  • og om det er vesentlige forskjeller i sekvensen, involverte parter og/eller meldingsinnhold.

Hovedprosessene dekker alle prosesser som er nødvendig i en leverandørsentrisk modell. I tillegg er det tatt med støtteprosesser og korreksjonsprosesser for å sikre en kundevennlig modell med størst mulig grad av automatisering. Disse prosessene er markert spesielt, og skal ikke «markedsføres» ut til sluttbruker, men kun benyttes når de vil hjelpe sluttbrukeren i avvikssituasjoner. Teksten i disse prosessene er skrevet i kursiv for å markere at det er en støtteprosess. BRS nummeret skal sendes i alle relevante meldinger for å identifisere hvilken prosess de tilhører.

Der fristen er satt til 1 kalenderdag – betyr dette i praksis 24 – 48 timer, dvs. hvis meldingen kommer inn på en mandag, vil endring skje onsdag fra 00:00 (lokaltid).

Brukstilfelle (Use Case)

En BRS kan ha et eller flere brukstilfeller beskrevet. Hvert brukstilfelle har et eget sekvensdiagram. Sekvensdiagrammene benytter meldinger fra settet med de predefinerte meldingene/ prosess-komponentene vist i diagrammet under. 

Inndeling av kapitler for hver prosess (BRS) 

  • Delkapittelet «Oversikt» gir en kortfattet beskrivelse av prosessen, dens utgangspunkt og mål, og illustrerer denne gjennom et brukstilfellediagram (Use Case Diagram). Dette diagrammet følger UML-notasjon og angir hvilke roller som er involvert samt hvilke faktiske brukstilfeller som benyttes for å gjennomføre prosessen. I mange tilfeller er dette kun ett brukstilfelle, mens i andre tilfeller kan det være behov for å utføre flere brukstilfeller for å komplettere prosessen. Dersom det benyttes brukstilfeller fra andre prosesser, er det nødvendig å se på de relaterte prosessene for å få oversikt over den totale flyten som prosessen krever.
  • «Prosessflyt og informasjonsutveksling» består i de fleste tilfeller utelukkende av et sekvensdiagram for hvert brukstilfelle i prosessen. Merk at brukstilfeller som tilhører andre prosesser, men som er knyttet inn i en annen prosess, kun er presentert i den opprinnelige prosessen. I teksten og i tabellene videre benyttes aktørene (f.eks. Nettselskap) og ikke de formelle rollene for å lette forståelsen, og sikre de riktige koblingene til det norske kraftmarkedet. I sekvensdiagrammet er koblingene mellom disse vist.
  • «Starttilstand» er en kortfattet beskrivelse av tilstanden som må være innfridd forut for at prosessen skal kunne gjennomføres.
  • «Prosessforløp» er en verbal presentasjon av flytdiagrammet med utvidet informasjon knyttet til det enkelte steget i diagrammet som er presentert tidligere.
  • «Valideringsregler» gir en oversikt over hvilke parametere som valideres og der utfallet kan bli at prosessen avvises. I tillegg vil også tekniske feil og syntaksfeil kunne føre til avvisning, disse beskrives i dokumentene for BIM (Business Information Model) og Prosesspesifikke meldingsvalideringer. I dette dokumentet tas kun prosessfeil og forretningsmessige feil med. En del valideringer som anses slå inn kun i spesielle feilsituasjoner (f.eks. i forbindelse med inkonsistens i dataene i Elhub) er ikke tatt med, det er dermed mulig å motta andre feilkoder for enkelte BRSer enn de som er inkludert i dette dokumentet.
    Valideringsreglene er bygget opp med et strukturert og entydig språk hvor følgende definerte termer brukes for å beskrive flere av reglene:
    • "må" respektive "skal ikke" - Disse termene brukes for å beskrive noe som kreves er oppfylt, respektive noe som ikke er tillatt. Eksempler: "Dato for leverandørskifte må være innenfor tidsfristene" og "Målepunktet skal ikke være blokkert for leverandørskifte"
    • "Registrert i Elhub" - Denne termen brukes for å beskrive noe som er registrert og lagret i Elhub. Eksempel: Valideringsregelen "Målepunktet må være registrert i Elhub" innebærer at målepunktet må ha blitt opprettet i Elhub før prosessen kan utføres.
    • "oppgitt i" - Denne termen brukes for å beskrive situasjoner hvor et informasjonselement må eller ikke skal være til stede i en viss kontekst, eller må skrives i et visst format. Ofte kreves det at informasjon må være "oppgitt i prosessen" eller "oppgitt i melding" hvilket i hovedsak refererer til informasjonselementet i BIM melding som markedsaktør sender inn, men hvis prosessen også kan kjøres gjennom Elhub Aktørportal gjelder regelen også der. Eksempel: "Sluttbruker ID oppgitt i prosessen må være den samme som er registrert i Elhub på kraftkontrakten i målepunktet" og "Gyldighetsdato må være oppgitt i midnatt lokal norsk tid"
    • "spesifisert for" - Denne termen brukes for å beskrive gyldige og ugyldige tilstander i Elhub, oftest relatert til et målepunkt. Når informasjon skal være spesifisert på en viss måte innebærer det ofte at gyldig tilstand kan oppnås enten ved at riktig informasjonen oppgis i prosessen eller at den er registrert i Elhub fra før. Eksempel: "Innhentingsmetode må være spesifisert for hvert aktivt målepunkt" innebærer at innhentingsmetode kan være registrert i Elhub før målepunktet aktiveres eller at det oppgis samtidig som målepunktet aktiveres.
  • «Tidsfrister» oppsummerer hvilke tidsfrister som er sentrale i den aktuelle BRS'en.
  • «Meldingsreferanser» knytter BRSen til meldinger og innholdet i disse, som er beskrevet i detalj i BIM (Business Information Model).

I prosessforløpene i BRS'ene vil det være referanser til meldingsnummer/prosesskomponent. 

Meldinger/prosesskomponenter i BRS'ene

Meldinger/prosesskomponenter I

Meldinger/prosesskomponenter II


Figurene over angir meldinger som kan utveksles mellom Elhub og markedsaktørene. Meldingsnavn og nummer benyttes i beskrivelsen av prosessforløpene. Disse meldingene er logiske meldinger som knytter sammen BRS'ene og de faktiske meldingene som er beskrevet i BIM (Business Information Model). Flere logiske meldinger kan bli slått sammen i en meldingstype, der parameter som angitt i parentes i figurene over (og benyttet til sekvensdiagrammene der relevant) skiller disse fra hverandre. Denne koblingen er beskrevet under meldingsreferanser på slutten av hver BRS, der logisk melding og tilhørende parameter er knyttet til faktisk melding med tilhørende dokumenttype og årsakskode.

Enhver melding sendt til Elhub blir kvittert enten positivt som akseptert eller negativt iht. betingelser angitt i kapitler for valideringsregler. Dersom avsender mottar en negativ respons, må data korrigeres og meldingen sendes på nytt.
Enhver melding antas videre å være atomisk og helhetlig, i det en prosess som blir avbrutt av en negativ respons til enhver tid vil etterlate systemet i en veldefinert tilstand. Enhver prosess avbrytes ved negativ respons, meldingsinnhold må korrigeres, før ny melding sendes for å gjennomføre prosessen.

Utgående meldinger anses som mottatt og forstått når de er hentet ut fra Elhub. Hvis feil oppdages hos aktørene i ettertid, må en korrigerings- eller reverseringsprosess initieres. Hvis aktøren er usikker på om feilen ligger i eget system, kan en spørring initieres for å sjekke gyldig informasjon i Elhub.
Meldingene til og fra Elhub vil bli administrert via køer per aktør. 

Oversikt over forretningsprosesser

Prosess og navn

Hovedprosess/
støtteprosess

Gruppert under

BRS-NO-101 - Oppstart kraftleveranse - leverandørskifte

Hovedprosess

BRS Markedsprosesser

BRS-NO-102 - Oppstart kraftleveranse - innflytting frem i tid

Hovedprosess

BRS Markedsprosesser

BRS-NO-103 - Oppstart kraftleveranse - innflytting tilbake i tid

Støtteprosess

BRS Markedsprosesser

BRS-NO-104 - Oppstart kraftleveranse - leverandørskifte fra leveringsplikt

Støtteprosess

BRS Markedsprosesser

BRS-NO-111 - Reversering av oppstart kraftleveranse

Støtteprosess

BRS Markedsprosesser

BRS-NO-121 - Nytt målepunkt

Hovedprosess

BRS Markedsprosesser

BRS-NO-122 - Aktivering i målepunkt

Hovedprosess

BRS Markedsprosesser

BRS-NO-123 - Oppstart i målepunkt - innflytting

Støtteprosess

BRS Markedsprosesser

BRS-NO-131 - Reversering av nytt målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-132 - Reversering av aktivering i målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-133 - Reversering av oppstart i målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-201 - Opphør på grunn av utflytting

Hovedprosess

BRS Markedsprosesser

BRS-NO-202 - Opphør av kraftleveranse

Hovedprosess

BRS Markedsprosesser

BRS-NO-211 - Utflytting fra målepunkt meldt til netteier

Støtteprosess

BRS Markedsprosesser

BRS-NO-212 - Deaktivering av målepunkt

Hovedprosess

BRS Markedsprosesser

BRS-NO-213 - Fjerning av målepunkt

Hovedprosess

BRS Markedsprosesser

BRS-NO-214 - Deaktivering av målepunkt med sluttbrukerStøtteprosessBRS Markedsprosesser
BRS-NO-221 - Reversering av opphør kraftleveranse

Støtteprosess

BRS Markedsprosesser

BRS-NO-222 - Reversering av utflytting fra målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-223 - Reversering av deaktivering av målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-224 - Reversering av fjerning av målepunkt

Støtteprosess

BRS Markedsprosesser

BRS-NO-301 - Oppdatering av grunndata - kraftleverandør

Hovedprosess

BRS Markedsprosesser

BRS-NO-302 - Oppdatering av grunndata - nettselskap

Hovedprosess

BRS Markedsprosesser

BRS-NO-303 - Spørring grunndata

Hovedprosess

BRS Markedsprosesser

BRS-NO-305 - Endring på målepunkt initiert fra Elhub

Hovedprosess

BRS Markedsprosesser

BRS-NO-306 - Endring i avregningsform

Hovedprosess

BRS Markedsprosesser

BRS-NO-311 - Målerstand og antatt årsforbruk fra kraftleverandør

Hovedprosess

BRS Markedsprosesser

BRS-NO-312 - Oversendelse av måleverdier for profilavregnede målepunkt

Hovedprosess

BRS Måleverdirapportering

BRS-NO-313 - Oversendelse av volumserier for målepunkt

Hovedprosess

BRS Måleverdirapportering

BRS-NO-314 - Purring på måleverdier og antatt årsforbruk fra nettselskap

Støtteprosess

BRS Måleverdirapportering

BRS-NO-315 - Spørring måleverdier

Hovedprosess

BRS Måleverdirapportering

BRS-NO-317 - Oppdatering av antatt årsforbruk

Hovedprosess

BRS Måleverdirapportering

BRS-NO-318 - Oppdatering av parametre for nettap

Hovedprosess

BRS Måleverdirapportering

BRS-NO-321 - Kvalitetssikring avregningsgrunnlag - nettselskap

Støtteprosess

BRS Avregningsgrunnlag og Avviksoppgjør

BRS-NO-322 - Preliminært timesfordelt volum for profilavregnede målepunkt

Hovedprosess

BRS Avregningsgrunnlag og Avviksoppgjør

BRS-NO-324 - Spørring avregningsgrunnlag

Hovedprosess

BRS Avregningsgrunnlag og Avviksoppgjør

BRS-NO-332 - Tilbaketrekking av måleverdier for profilavregnede målepunkt

Støtteprosess

BRS Måleverdirapportering

BRS-NO-402 - Korrigeringer i grunndata - fra nettselskap

Støtteprosess

BRS Markedsprosesser

BRS-NO-501 - Reporting structure data for Imbalance Settlement

Hovedprosess

BRS Reporting for Imbalance Settlement and Elcertificates

BRS-NO-502 - Reporting data for Imbalance Settlement

Hovedprosess

BRS Reporting for Imbalance Settlement and Elcertificates

BRS-NO-503 - Rapportering grunnlag for avviksoppgjør

Hovedprosess

BRS Avregningsgrunnlag og Avviksoppgjør

BRS-NO-511 - Reporting Produced Volume to Registry responsible Elcertificates

Hovedprosess

BRS Reporting for Imbalance Settlement and Elcertificates

BRS-NO-512 - Reporting Quota Obliged Consumption

Hovedprosess

BRS Reporting for Imbalance Settlement and Elcertificates

BRS-NO-601 - Forespørsel til nettselskapet

Hovedprosess

BRS Markedsprosesser

BRS-NO-611 - Verifiser grunndata i målepunkt

Hovedprosess

BRS Markedsprosesser

BRS-NO-622 - Oppdatering av tredjeparts tilgang

Hovedprosess

BRS Markedsprosesser

BRS-NO-623 - Oversikt over tredjeparts tilgang

Hovedprosess

BRS Markedsprosesser

Referanser

  1. Forskrift om måling, avregning, fakturering av nettjenester og elektrisk energi, nettselskapets nøytralitet mv., https://lovdata.no/dokument/SF/forskrift/1999-03-11-301
  2. Informasjon om GS1 (EAN) målepunkt ID, www.gs1.no
  3. Rollemodell for det norske kraftmarkedet, www.ediel.no
  4. NordREG anbefalinger, www.nordicenergyregulators.org
  5. eSett Handbook, https://www.esett.com/handbook/
  6. ebIX Business Requirement Specifications, www.ebix.org
  7. ENTSO-E implementation guides, see https://www.entsoe.eu/publications/electronic-data-interchange-edi-library/
  8. Krav til måling av sentralnettsutveksling, https://www.statnett.no/for-aktorer-i-kraftbransjen/avtaler-og-vilkar-for-kunder-i-sentralnettet/krav-til-maling/
  9. Forskrift om elsertifikater, https://lovdata.no/dokument/SF/forskrift/2011-12-16-1398