Pilotaktørmøte Skype

Transkript

1 Pilotaktørmøte Skype

2 Agenda Plan for høstens aktiviteter og deltakere Status systemtesting og Elhub testmiljø (Exa2) Kommunikasjon Connectivity og oppstart av pilotaktiviteter Testdata for pilotaktiviteter Det migreres ikke inn måleverdier i Elhub Pilot aktørgodkjenning Beregningstest hvilke MGA som skal benyttes og hvordan utveksling skal sendes inn. Ende til ende markedsprosesser Go Lite 2

3 Plan og deltakere 3

4 Aktivitetsplan pilottesting høsten

5 Oversikt over hvilke pilotaktører som deltar i hvilke aktiviteter Aktør Pilot aktørgodkjenning Beregningsverifikasjon Ende til ende markedsprosesser Go Live Agder Energi X X X X Eidsiva Marked X Embriq (BSP) X X X Gauldal X X Gurusoft X Hafslund X X X X Høland og Setskog Elverk X X Hydro X X X Nesset kraft X X X SFE Nett X X X Skagerak Nett X X X X Smarthub (BSP) X X X Statnett X X Ustekveikja X X Validér (BSP) X X X Vest Telemark Kraftlag X X

6 Status Elhub testmiljøer 6

7 Systemleverandørtesting i Systest 3 Systest 3 er under oppgradering til R3.1 i uke 38 (denne uke) Flere feil enn forventet funnet i Elhub UAT av R3.1 mange av disse forventes rettet inneværende uke Intern verifikasjon R3.1 i Systest3 uke 39 Det vurderes å åpne for parallell ekstern testing i uke 39 Regresjonstest på testcaser for Market Trial planlagt uke Funksjonelt / markedsprosesser R3May og migrering/systemgodkjenning systemvendor trial/status interntest exatest2 Test case Market trial Imb.settl. /Recon. Mandatory/ Optional Internal Status External Status Elhubdefect BRS NO 101 Confirm Yes No M 01.aug Partial Pass ED 4848 BRS NO 101 Reject Yes No M 01.aug Pass 18:08:17 Pass BRS NO 101 Cancel Yes No M 31.aug Pass Pass ED BRS NO 102 Confirm Yes No M 01.aug Partial Pass ED 4848 ED BRS NO 102 Reject Yes No M 01.aug Pass Pass BRS NO 102 Cancel Yes No M 01.aug Pass Pass BRS NO 103 Profiled Yes No M 01.aug Partial Pass ED 4848 ED BRS NO 104 Yes No M 01.aug Partial Pass ED 4848 BRS NO Yes No M 25.aug Partial Pass ED 4848 BRS NO Yes No M Pass BRS NO 121 Yes No M 01.aug Pass Pass BRS NO 122 Yes No M 01.aug Pass Pass BRS NO 123 Yes No M 25.aug Partial Pass ED 4848 BRS NO 201 Yes No M 04.aug Pass Pass BRS NO 201 Cancel Yes No M 03.aug Pass Pass ED BRS NO 202 Yes No M 09.aug Pass Pass BRS NO 202 Cancel Yes No M 31.aug Pass Pass BRS NO 301 Yes No M 01.aug Pass Pass BRS NO 302 Yes No M 18.aug Pass Pass BRS NO 303 Yes No M 01.aug Pass Pass BRS NO 306 Yes No M 17.aug Pass Pass BRS NO 311 EAC Yes No M 03.aug Pass Pass BRS NO 311 Meter Yes No M 07.aug Pass Pass BRS NO 312 Yes Yes M 03.aug Pass Pass BRS NO 313 Yes Yes M 08.aug Partial Pass ED 7979 BRS NO Yes Yes M 07.sep Fail ED BRS NO 315 Yes Yes M 24.aug Pass BRS NO 315 Neg Yes No O 18.aug Fail ED BRS NO Yes Yes M 05.sep Fail ED 9759 BRS NO 402 Yes No M Pass Pass BRS NO Yes No M 01.aug Pass Pass BRS NO Yes No M 18.aug Pass BRS NO 602 Yes No M 15.aug Fail ED BRS NO 611 with ID Yes No M 07.aug Pass Pass BRS NO 611 with MPID Yes No M 07.aug Pass Pass BRS NO Yes No M 29.aug Pass BRS NO Yes No M

8 Exa2 Eksistende data i Exa2 Grunndata for ~ målepunkter fordelt på pilotaktørene Oppstartsdato (channel milestone): Ny migrering Alle pilotaktører har lastet opp filer til Market Trialmiljø Integritets og formatsjekker har blitt kjørt for alle filer Grunndata for ~ målepunkter lastes inn på nytt i Elhub i uke 41 Tilgjengelighet fremover Tilgjengelig for test uke 38 (denne uke) DR testing uke 39 Oppgradering til 3.1 uke 40 Intern verifikasjon uke Funksjonelt / markedsprosesser (R3May) og migrering/pilottesting/status exa2 BRS Market trial Imb.settl./Rec Internal Status BRS NO 101 Confirm Yes No 18.sep Failed BRS NO 101 Reject Yes No 15.sep Passed BRS NO 101 Cancel Yes No 15.sep Passed BRS NO 102 Confirm Yes No 18.sep Failed BRS NO 102 Reject Yes No 15.sep Passed BRS NO 102 Cancel Yes No 15.sep Passed BRS NO 103 Profiled Yes No 15.sep Failed BRS NO 104 Yes No 15.sep Passed BRS NO Yes No Blocked BRS NO Yes No 15.sep Passed BRS NO 121 Yes No 15.sep Passed BRS NO 122 Yes No 15.sep Passed BRS NO 123 Yes No 15.sep Passed BRS NO 201 Yes No 18.sep Passed BRS NO 201 Cancel Yes No 15.sep Passed BRS NO 202 Yes No 18.sep Passed BRS NO 202 Cancel Yes No 15.sep Passed BRS NO 301 Yes No 15.sep Passed BRS NO 302 Yes No 15.sep Failed BRS NO 303 Yes No 15.sep Passed BRS NO 306 Yes No 15.sep Failed BRS NO 311 EAC Yes No 15.sep Passed BRS NO 311 Meter Yes No Not started BRS NO 312 Yes Yes 15.sep Passed BRS NO 313 Yes Yes 15.sep Passed BRS NO Yes Yes Not started BRS NO 315 Yes Yes Not started BRS NO 315 Neg Yes No Not started BRS NO Yes Yes Not started BRS NO 402 Yes No 15.sep Failed BRS NO Yes No Not started BRS NO Yes No Not started BRS NO 602 Yes No Not started BRS NO 611 with ID Yes No 15.sep Passed BRS NO 611 with MPID Yes No 15.sep Passed BRS NO Yes No Not started BRS NO Yes No Not started

9 Elhub Aktørportal Elhub aktørportal vil gjøres tilgjengelig når sikkerhet er verifisert i intern akseptansetest Run 2 planlagt ut februar

10 Kommunikasjon og samhandling 10

11 Kommunikasjon med Elhub Oppgradert området på elhub.no som omtaler pilottesting Bruk av HipChat Bruk av JIRA 11

12 Elhub.no 12

13 HipChat Sensitive data skal ikke deles på HipChat. Vi har forskjellige rom i HipChat for å diskutere ulike aspekter ved verifiseringen: Pilottesting Generelt forum der man for eksempel kan diskutere ting relatert til migrering og Connectivity, i tillegg til Pilot Aktørgodkjenning og ende til ende markedsprosesser Beregningsverifisering Her diskuteres beregningsverifiseringen Go Live Her diskuteres Go Live simuleringene 13

14 HipChat slik ser det ut 14

15 JIRA Alle testcaser for ende til ende markedsprosesser Alle testcaser for beregningstest Alle testcaser for Go Lite Rapportering av defects Må skrive under NDA noen har gjort dette allerede, resten vil få denne tilsendt snart 15

16 Connectivity og oppstart av pilotaktiviteter 16

17 Connectivity testing og brøytekjøring Sertifikater må installeres først (snakke med systemleverandør) Konfigurering av endepunkter (snakke med systemleverandør) URL: test2.elhub.no:8200/webservice/services/marketprocesses Etc. Gjør spørring eller verifisering på grunndata i et målepunkt, avhengig av om dette er et målepunkt aktøren skal ha tilgang til eller ikke vil man enten få informasjon om målepunktet eller beskjed om at man ikke har tilgang til dette målepunktet. Dersom systemet ikke har kontakt med Elhub overhodet skal det komme en feilmelding om dette. Aktøren oppfordres til å snakke med sin systemleverandør for å finne ut nøyaktig hvordan dennes spesifikke system fungerer. Anbefalte prosesser: Kraftleverandører kjører følgende: BRS NO 611 Nettselskap kjører følgende: BRS NO 303 Testmiljøet er åpent, prøv i tillegg å kjøre markedsprosesser som er ok i Exa2 ihht status (f.eks. BRS NO 312, 313, 301) Tilgjengelig testdata er et subsett av det som ble lastet opp 25. august. Dere har fått tilbakemelding om hvilke data som er inne. Selve connectivity testen kan gjøres uavhengig av om man lastet opp data 25. august. Avsjekk: Hvem har fått forbindelse til Elhub? 17

18 Oppstart av pilotaktiviteter på R3.1 Opplasting av migrerte data 18.9 Connectivity ønskes gjennomført innen Exa2 tas ned for DR testing og R3.1 oppgradering uke Lasting fra EDM (gamle DAM) til Elhub vil foregå i uke 41 Elhub vil gjøre intern verifisering av Elhub R3.1 med migrerte data i uke 42 Planlagt oppstart av pilot aktørgodkjenning Run 1 er uke 43, Fiktive testdata vil bli publisert på elhub.no Hvilke av de migrerte produksjonsdataene som er lastet inn i Elhub vil distribueres Ønsker dere at vi legger dette på elhub.no eller sender det på mail? Hvis mail, kan vi sende fellesmail? Invitasjon til oppstartsmøte(r) og statusmøter kommer Statusmøter foreslås fredager kl hver uke, første statusmøte fredag

19 Testdata for pilotaktiviteter 19

20 Pilotene skal gjennomføre pilot aktørgodkjenning, beregningstest og endetil ende markedsprosesser på 17.august uttrekket 17.August uttrekket migreres inn i Exatest2 (Elhubs testmiljø), og pilotene vil benytte dette uttrekket til aktivitetene Pilot aktørgodkjenning Beregningsverifikasjon Ende til ende markedsprosesser 20

21 Hver pilotaktør har ulike oppsett for hvilke testdata de vil bruke i pilot aktørgodkjenning, beregningstest og ende til ende markedsprosesser EXATEST 2 Når verifikasjon mot piloter starter vil følgende testdata ligge i Exa2: Utvalg av grunndata fra 17.augustuttrekket Fiktive testdata for aktører som ønsker dette i pilot aktørgodkjenning og Elhuboperatører Type data Strukturdata; aktører, nettstruktur og tilhørende relasjoner Grunndata med 3 års historikk; kontrakter, målepunkt, sluttkunde Ingen måleverdier i Elhub, hverken for timeavregnede eller profilavregnede målepunkt EXATEST 2 Hafslund Har ett nett som brukes både til beregningstesten, pilot aktørgodkjenning og ende til ende markedsprosesser med 1000 målepunkter som man «later som er hele MGAet» i beregningstesten Gauldal Har ett nettavregningsområde som brukes til beregningstesten der hele nettområdet migreres inn Deltar i beregningstest, men ikke i pilot aktørgodkjenning og ende til ende markedsprosesser Statnett Har sentralnett. Utvalgte målepunkt vil brukes til beregningstesten Deltar i beregningstest, men ikke i pilot aktørgodkjenning og ende til ende markedsprosesser Agder, Skagerak, Hydro Har regional /produksjonsnett som brukes til beregningstesten der hele nettområdet migreres inn I tillegg er det trukket ut målepunkter fra de andre nettene dersom de har det som vil brukes til pilot aktørgodkjenning og ende til ende markedsprosesser Nesset Kraft, SFE Nett, Gurusoft, Ustekveikja Deltar i pilot aktørgodkjenning og ende til ende markedsprosesser, men ikke i beregningstest For Nesset Kraft og SFE Nett vil målepunktene som migreres brukes til pilot aktørgodkjenning og ende til ende markedsprosesser Gurusoft og Ustekveikja benytter fiktive testdata generert av Elhub i testene? Høland og Setskog Elverk, Vest Telemark Kraftlag, Eidsiva Deltar kun i pilot aktørgodkjenning Høland og Setskog, og Vest Telemark Kraftlag vil benytte målepunktene som migreres til pilot aktørgodkjenning Eidsiva benytter fiktive testdata generert av Elhub i testene? 21

22 Testdata pilotaktørgodkjenning og ende til ende markedsprosesser Aktør Produksjonsdata Fiktive testdata Agder Energi X Eidsiva X Embriq (BSP) X Gauldal X Gurusoft X Hafslund X Høland og Setskog Elverk X Hydro X Nesset kraft? SFE Nett X Skagerak Nett X Smarthub (BSP)? (Følger av Nesset) Produksjons eller fiktive testdata for pilot aktørgodkjenning og ende til ende markedsprosesser Nettselskaper og regulert kraftleverandør skal benytte migrerte produksjonsdata Kraftleverandører og balanseansvarlige kan velge om de vil benytte produksjonsdata eller fiktive testdata generert av Elhub Tredjeparter skal benytte fiktive testdata generert av Elhub. Dersom en tredjepart er del av et kraftkonsern og ønsker å benytte produksjonsdata er dette greit. Statnett X Ustekveikja? Validér (BSP) Vest Telemark Kraftlag X X 22

23 Krav til aktører som benytter produksjonsdata og fiktive data Produksjonsdata Krever at nettselskapet har migrert data Krever at kraftselskapet laster inn data i egne testsystemer Aktørene må selv finne ut hvilke målepunkt testene skal kjøres på med utgangspunkt i beskrivelsen i «forutsetninger» / «preconditions» per testcase For testcase på profilavregnede målepunkt må nettselskapet sende inn en målerstand før testen kan starte Fiktive data Elhub genererer fiktive testdata per aktør Kun strukturdata trenger å lastes inn i egne testsystem da alle testene vil starte med at en kraftleverandør tar til seg et målepunkt (leverandørbytte eller innflytt) Det blir angitt hvilken testdata som skal brukes til hvilket testcase Elhub sender inn målerstand for alle profilavregnede målepunkt før testen starter 23

24 Det migreres sannsynligvis ikke måleverdier inn i Elhub ved Go Live, og derfor heller ikke i høstens pilottesting 24

25 Vi forutsetter at nettselskap overtar avviksoppgjør frem til Go Live, det vil ikke migreres historiske måleverdier og testene må legges opp deretter SITUASJON Som følge av at Elhub Go Live har blitt utsatt skal nettselskapene gjøre avviksoppgjør for alle bruksdager før GoLive, også hvis korreksjonene oppdages etter GoLive. Elhub har kun ansvaret for bruksdager fra og med Go Live. Ettersom Elhub overtar ansvar for avviksoppgjør ved Go Live er det ikke lenger behov for å ha måleverdihistorikk i Elhub ved oppstart. Ved Elhub Go Live for timeavregnede målepunkt vil Elhub settes opp slik at nettselskapene sender målerverdier det andre driftsdøgnet for Golive dagen slik som i vanlig drift. Dette er ingen endring fra tidligere. Netteierne må sende inn en målerstand for Go Live dato kort tid etter Go Live slik at vi har en stand ved overgangen og faktisk verdi for å kunne gjøre eventuelle estimeringer. Ved Elhub Go Live for profilavregnede målepunkt vil Elhub legge inn en forekomst i channel milestone som indikerer at det finnes måleverdi på Go Live datoen. Da vil alle prosessene tro at det finnes en målerstand på Go Live datoen selv om det ikke gjør det, i påvente av nettselskapet innsending. Det må utvikles Go Live spesifikk kode for dette i Elhub. KOMPLIKASJON For timeavregnede målepunkt vil testløpene starte opp på samme måte som etter Elhub Go Live. Elhub vil sette en «oppstartsdato» for testløpene etter hver migrering. Måleverdier må sendes inn til Elhub fra og med dette tidspunktet. Markedsprosessene i timeavregnede målepunkt vil prosesseres uavhengig av om det finnes måleverdier i målepunktene. Dette er ingen endring fra tidligere. For profilavregnede målepunkt vil Go Live tilnærmingen med å legge inn forekomst i channel milestone ikke være tilgjengelig før tidligst Go Live simulering 1, og alle testløpene før dette må derfor planlegges for dette. For profilavregnede målepunkt må det finnes en måleravlesning før innsending av markedsprosesser som krever en 3 måneder gammel avlesning for at disse ikke skal bli avvist. I testløpene etter at løsningen med forfalskning av målerstand blir tilgjengelig vil det ikke kreves innsending av måleverdier for disse markedsprosessene. SPØRSMÅL: Hvordan skal vi håndtere innsending av måleverdier for timeavregnede og profilavregnede målepunkt som inngår i de eksterne testløpene av Elhub? 25

26 Nettselskapet må sende inn måleverdier fra en satt oppstartsdato, og det må sendes inn måleverdier på profilavregnede målepunkt før alle testcase OPPSTARTSDATOER FOR PILOTAKTIVITETER I HØST Oppstartsdato pilot aktørgodkjenning: kl Årsaken til at oppstartsdato settes en uke før oppstarten av pilot aktørgodkjenning er at Elhub vil bruke denne oppstartsdatoen i verifiseringen av miljøet i uke 42. Oppstartsdato beregningsverifikasjon: kl Ny oppstartsdato settes før oppstart beregningsverifikasjon Oppstartsdato ende til ende markedsprosesser: Profilavregnet: kl 00.00, Timeavregnet: kl Oppstartsdato i Go Live simulering 1: PROFILAVREGNEDE MÅLEPUNKT Innsending av måleverdier Nettselskapet (DDE) skal sende inn startstand, sluttstand og periodevolum, fra forrige avlesningstidspunkt og frem til oppstartsdato, på de profilavregnede målepunktene som krever en måleravlesning før testen starter Elhub er DDE for de fiktive målepunktene og sender måleverdier på de fiktive målepunktene Pilot aktørgodkjenning. Testcase for kraftleverandør som er avhengig av at DDE har sendt inn måleverdier: DDQ101 02, DDQ103 02, DDQ104 01, DDQ A (på profilert), DDQ B (på profilert), DDQ A (kun fiktive data), DDQ A (kun fiktive data) Testcase for regulert kraftleverandør som er avhengig av at DDE har sendt inn måleverdier : SLR (på profilert) TIMEAVREGNEDE MÅLEPUNKT Innsending av måleverdier Nettselskapet (DDE) skal sende inn måleverdier fra og med oppstartsdatoen. Pilot aktørgodkjenning: I testcasene for pilot aktørgodkjenning må DDE sende inn måleverdier fra oppstartsdato for pilot aktørgodkjenning Beregningsverifikasjon: DDE sender inn måleverdier fra oppstartsdato for beregningsverifikasjon Ende til ende markedsprosesser: DDE sender inn måleverdier fra oppstartsdato for beregningsverifikasjon Beregningsverifikasjon. Vi kommer tilbake til dette i detaljert kjøreplan Ende til ende markedsprosesser. Samme som for pilot aktørgodkjenning 26

27 Pilot Aktørgodkjenning 27

28 Formål og omfang for aktørgodkjenning Formål og hensikt Hensikten med Aktørgodkjenning er å verifisere at alle aktørene i kraftmarkedet har fått tilpasset og konfigurert sine IT løsninger og er klare til å ta i bruk disse mot Elhub ved Go Live. Dette omfatter å: Verifisere at alle aktører har fått installert en Elhubversjon i sitt testmiljø og kan kommunisere med Elhub fra dette miljøet Verifisere at alle aktører kan kjøre et utvalg av definerte prosesser mot Elhubs testmiljø, med realistiske data Bidra til opplæring av aktørene for å sikre at de forstår hvordan Elhub fungerer Omfang Omfanget av aktørgodkjenning vil avhenge av aktørtype og rolle. Hver rolle vil ha et sett tester som dekker de vanligste prosessene. Alle tester er beskrevet i detalj på elhub.no. En test vil kun dekke funksjonalitet og meldingsutveksling for en rolle. Årsaken er at alle aktører skal kunne gjennomføre sine tester uavhengig av hverandre. I noen testcase, der det er hensiktsmessig, er det likevel mulig at flere roller inngår. Dette er spesifisert i beskrivelsen av de casene det gjelder. For de aktørene som tester med fiktive data vil ingen andre aktører merke noe til testingen. For de aktørene som tester med migrerte data vil de avhengig av testen kunne motta meldinger som følge av andres tester. 28

29 Tester i pilot aktørgodkjenning Tester for Nettselskap (DDM, MDR, DDE og BSP): Opprettelse og aktivering av målepunkt Oppdatering av grunndata på et målepunkt Innsending av måleverdier for ulike typer målepunkt Spørring på måleverdier Reversering av nytt målepunkt Test av BSP for DDE rollen Tester for Kraftleverandør (DDQ): Innflytting tilbake i tid Opphør av kraftleveranse Leverandørbytte Kansellering av leverandørbytte Oppdatering av grunndata Endring i avregningsform Verifisering av grunndata i målepunkt Mottak av måleverdier Tester for Leveringspliktig kraftleverandør (SLR): Oppstart i målepunkt Oppdatering av grunndata Spørring grunndata Mottak av måleverdier Spørring måleverdier, spørring avregningsgrunnlag Forespørsel til nettselskap Forespørsel til Elhub Tester for Leverandør for Nettap (BSL): Spørring på avregningsgrunnlag Forespørsel til nettselskap Forespørsel til Elhub 29 Tester for Balanseansvarlig (DDK): Spørring på avregningsgrunnlag Tester for Tredjepart (AG): Spørring på måleverdier Oppdatering av tredjeparts tilgang Tester for Query (QRY): Verifisering av grunndata i målepunkt

30 Pilot aktørgodkjenning kjøres mot Elhub, og Edielportalen brukes som testlogg Forberedelser i Edielportalen Sjekk at aktørene som skal gjennomføre testen har registrert alle prosesskomponenter med tilhørende ITsystemer og adressering Dersom aktøren har gjort endringer etter aktørsertifiseringen må dette registreres i Edielportalen før testen starter Sjekk at aktørene som skal gjennomføre testen har registrert en testressurs Bruk av Edielportalen i test Edielportalen vil fungere som testlogg for pilot aktørgodkjenning Start alle testene i Edielportalen før testene startes i eget system! Siste steg i alle testene er at Elhub godkjenner testen. Testcaset vil «stå og gå» i Edielportalen til Elhub har godkjent caset. 30

31 Steg for steg beskrivelse av gjennomføring 1. Velg ut en test som skal kjøres. 2. Velg hvilket målepunkt, ID eller annen info som testen skal kjøres for. a. Kraftleverandør, Balanseansvarlig, Tredjepart og Query finner testdata i Excel ark. Evt. fra testdata fra nettselskap. b. Nettselskap og Regulert kraftleverandør velger fritt ut fra hvilken type test dere skal kjøre og hvilke testdata som er tilgjengelig. Se også avsnitt over om testdata. 3. Logg på Edielportalen og start testcase for aktuell test og følg instruks i teststeg. 4. Start aktuell test fra eget system. 5. Underveis i testen: 1. Følg teststegene som er beskrevet i Edielportalen 2. Følg med på at alle statuser i eget system er korrekte etter at melding er sendt til Elhub. 3. Vent på eventuelle kvitteringer fra Elhub og sjekk at statuser i eget system oppdateres som forventet 4. Vent på eventuelle bekreftelser fra Elhub med gitt tidsfrist dersom dette er en del av testen. 6. Ved testens slutt: Sjekk teststatus i Edielportalen med jevne mellomrom. Dersom status er godkjent er testen ferdig, dersom status er ikke godkjent må testen kjøres på nytt. Det kan ta opptil et par dager for Edielportalen å godkjenne testen. 31

32 Følg med på Elhubs nettsider før Pilot aktørgodkjenning starter, der vil det komme mer informasjon Vi jobber med en oppdatert versjon av brukermanualer, kun små endringer vil komme Oversikt over anbefalt rekkefølge for kjøring av testcase og instruks vil bli publisert på elhub.no 32

33 Beregningverifisering 33

34 Formål og omfang for beregningsverifikasjon Formål Aktører sender inn måleverdier som gjør at MGA går i balanse. Beregningsjobber kjører riktig i Elhub. Aktører mottar alle relevante resultater. Omfang Kjøreplan og testcase i JIRA er under utarbeidelse. Fase 1 skjer på et begrenset antall MPID. Balanseavregning og avviksoppgjør. Rapportering til NBS og NECS kommer senere. 34

35 Kjøreplan beregningsverifisering fase 1 35

36 Utvekslingspunkt Selskap MGA Navn Antall utv.punkt (unike MPID) Utveksling mot annen pilot Hydro HYDROAL2 15 Utveksling mot Statnett Statnett 13 SN13 Norgesyd 58 Statnett 14 SN14 Hallingdal 37 Statnett 15 SN15 Telemark 77 Statnett 16 SN16 Norgeøst 110 Agder AEN1RN 95 Utveksling mot Statnett Gauldal GAULD1 1 Hafslund Hafsl1 5 Utveksling mot Statnett Skagerak SKAGN1 78 Utveksling mot Statnett og Agder 36

37 Utvekslingspunkt rapportering Netteier er selv rapporteringsansvarlig: Innsending av timesverdier skjer på vanlig måte gjennom BRS NO 313. Rapporteringsansvarlig er ikke en del av piloten og utvekslingspunkt ikke er migrert: Eksempel Trønderenergi nett as mot Gauldal sitt MGA. Gauldal (evt Elhub) kan da opprette dette utvekslingspunktet i Elhub aktørportal og selv stå for innsending. Rapporteringsansvarlig er en del av piloten: Eksempel Statnett mot Skagerak sitt MGA. Statnett rapporterer på denne utvekslingen. Backup: Testaktør (Elhub) opprettes som DDE, mottar utvekslingsverdier og står for innsending. 37

38 Ende til ende markedsprosesser 38

39 Formål og omfang for ende til ende markedsprosesser Formål Kombinerte: Flere markedsprosesser kjørt i sekvens på samme målepunkt. Formålet er å kjøre markedsprosesser i rekkefølge slik aktørene vil gjøre i drift. Kryssende: Flere (primært to) samtidige markedsprosesser kjørt på samme målepunkt. Formålet er å teste at valideringsregler fungerer iht. krav. På tvers: Flere aktører er involvert i samme markedsprosess. Formålet er å teste et utvalg av markedsprosesser som kjøres på tvers av markedsaktører med ulike systemoppsett. Omfang Elhub holder på å utarbeide testomfanget av ende til ende verifikasjonen av markedsprosesser. To hovedprinsipper ligger til grunn for å definere omfanget Verifikasjonen skal validere at markedsprosessene for grunndata og kontraktsendringer fungerer når markedsprosessene kjøres i rekkefølge, slik at systemene sender og mottar riktige meldinger med korrekt innhold Målverdirapportering skal fungere i kombinasjon med markedsprosessene for grunndata og kontraktsendringer, slik at måleverdier sendes til riktig markedsaktør når det skjer endringer i grunndata og kontrakter 39

40 Caser i ende til ende markedsprosesser Case Testcasene vil bli tilgjengelige for pilotaktørene i Elhubs eksterne JIRA. Alle piloter må signere taushetserklæring. Påloggingsinformasjon vil bli distribuert til hver pilot når dette er klart. Det ligger eksempler på testcase på elhub.no Hvert testcase består av: Precondition: Angir starttilstand i målepunktet før testen starter Postcondition: Angir sluttilstanden i målepunktet når testen er ferdig Description: Inneholder er tekstlig beskrivelse av hva som skjer i testcaset, hvilke markedsaktørroller som er involvert og hvilke markedsprosesser (BRS er) som er involvert Test step: Inneholder hvilken dag teststeget skal gjennomføres, hvilken markedsaktørrollen som skal utføre teststeget og en tekstlig beskrivelse av hva som skal gjøres Expected result: Inneholder en tekstlig beskrivelse av forventet resultat per teststeg. For teststeg med meldinger angis dokumenttype, navn på meldingen og markedsprosess Forutsetninger og anbefalinger for testgjennomføring I teststegene er det ikke tatt med positiv bekreftelse på at en melding er mottatt (positive acknowledgement) da disse meldingene er frivillige og det varierer mellom systemleverandørene hva som er implementert. Bruk av Elhub Aktørportal er ikke angitt i teststegene, men vi oppfordrer alle testere til å bruke Elhub Aktørportal i denne testen dersom den blir tilgjengelig. En forutsetning for å validere at måleverdier sendes til riktig markedsaktør når det skjer endringer i grunndata og kontrakter, er at det sendes inn måleverdier både for profilavregnede og timeavregnede målepunkt. Vi oppfordrer alle piloter til å sette opp daglig innsending av timeverdier på de timeavregnede målepunktene som er med i testen. Som et minimum bør man tilstrebe å sende hele timesserier for utvalgte dager i testcasene på noen timeavregnede målepunkt. I testcasene der det skjer endringer av kontrakter, og det ikke finnes en målerstand på endringsdatoen vil Elhub estimere denne. Denne estimeringen forutsetter at det kjøres en balanseavregning. Høsten 2017 planlegger Elhub å gjennomføre ende til ende testen av markedsprosesser i utvidet markedstest uten beregninger, og estimeringsmeldingene vil derfor ikke inngå i testen. 40

41 Go Lite (Go Live simulering 1) 41

42 Go Lite Overordnet scope Teste migrering av komplette sett med fokus på både ytelse og kvalitet (også del av UAT for DAM) Migrere inn initielle sett med ca. 1,5 millioner målepunkter i løpet av tre dager Migrere inn deltasett med ca. 1,5 millioner målepunkter i løpet av tre dager Bufring av meldinger hos aktørene Oppgradering av aktørenes systemer Gradvis åpning av BRSer fra Elhub Debufring av meldinger fra aktører Aktørene kjører funksjonelle testcases som er definert i JIRA. Disse dekker både funksjonelle kjerneområder og viktige corner cases 42

43 Go Live simulering 1 skal kjøres på uttrekk fra , og Elhub har som ambisjon å klare og forfalske målerstand for profilavleste anlegg 23. november uttrekket migreres inn i Exatest2 (Elhubs testmiljø), og pilotene vil benytte dette uttrekket til Go Live simulering 1. Elhub har ambisjon om å forfalske målerstand for profilavleste anlegg i denne testen slik at innsending av måleverdier vil gjøres på samme måte som i Go Live for alle målepunktene. 43

44 Testdata som brukes i prosesser (Fortsatt produksjonsdata!) Aktører velger selv testdata Testene må ikke være knyttet til faktiske hendelser i produksjon Vi ønsker at man også prøver å kjøre testcaser på tvers av konserngrensene 44

45 Go Lite Uke 49: Full opplasting til Market Trial miljø mandag 4/12 Start bufring av prosesser Uke 50: Delta opplasting til Market Trial miljø mandag 11/12 Oppgradering av Aktørs system mandag 11/12 til og med onsdag 13/12 Åpning av prosesser for grunndataoppdatering Aktører kjører testcases definert av Elhub Uke 51: Simulert Go Live dato Åpning av prosesser for måleverdirapportering markedsprosesser Aktørene kjører testcases definert av Elhub Nettselskaper genererer edifact melding for periodevolum for uke 50 45

46 Forslag til tidslinje for synkronisering mellom miljøer Sanntid Uke 47 Tors 23/11 Uke 48 Uke 49 Uke 50 Uke 51 Tors 30/11 Man 4/12 Man 11/12 Ons 13/12 Man 18/12 Elhub Market Trial Full opplasting 23/11 uttrekk Elhub prod Full opplasting 23/11 uttrekk Delta opplasting 30/11 uttrekk Aktørs prodsystem Delta uttrekk og fullt uttrekk 30/11 Aktørs testsystem Testsystem synkront med prod per 30/11 46

47 Saker under avklaring Skal vi hente inn måleverdier ved Go Lite? I så fall hvor mye? Metodikk for innsending av første stand Oppstartsstand Periodevolum med fra og til stand 47

48 Risikovurdering Konsekvens 5 Kritisk 4 Alvorlig 3 Middels 2 Lav R11, R15,S3 R14, R12,, R17 R16, M4, S1, R19 1 Ubetydelig 1 Veldig lav (0-20 %) 2 Lav (20-40%) 3 Middels (40-60%) 4 Stor (60-80%) 5 Veldig stor % Sannsynlighet Hendelse Sannsynlighet (1 5) Det er så mange funksjonelle feil i R3.1 koden pr at det ikke er hensiktsmessig å starte 2 pilotaktivitetene som planlagt Det er så mye feil i migrerte data at det ikke er hensiktsmessig å starte pilotaktivitetene som 2 planlagt Ustabilitet i Exa2 forhindrer pilotaktivitetene vesentlig 2 Pilotaktørene feiler i å etablere ende til ende kommunikasjon mot Elhub før planlagt oppstart av pilot aktørgodkjenning Systemleverandørene rekker ikke å klargjøre en release med tilstrekkelig verifisert kvalitet til at det er hensiktsmessig å starte pilotaktivitetene 48som planlagt 2 1