Introduksjon

Bakgrunn

Standardene inneholder detaljerte beskrivelser og retningslinjer som supplerer Avregningsforskriften med rettigheter og plikter markedsaktørene har i meldingsutveksling i kraftbransjen. Standardene 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 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 i standardene

Elhub utvikler kontinuerlig funksjonaliteten i Elhubsystemet og oppdaterer dermed også standardene. 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 standardene 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 standardene. 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å standardene 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 standardene. 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 standardene endringen er beskrevet.

Versjonering av standardene

Standardene 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.

Hvordan lese standardene

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.

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 med sekvensdiagram

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. Dersom det henvises til 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 hver enkelt BRS. 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).

• "Prosesspesifikke meldingsvalideringer" beskriver validering av meldingsinnholdet og de logiske sammenhenger mellom innholdet i forskjellige felt, samt kompletthet i nødvendig informasjon for å utføre en prosess. Dette er nødvendig i tillegg til XML schema-valideringen beskrevet i Elhub BIM Business Information Model som kun sjekker at pålagte meldingsdeler og felt er til stede, samt at koder er gyldige. 

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

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