Ekspertgruppemøte 15 Migrering og test. Statnett, Nydalen 21. april 2016

Transkript

1 Ekspertgruppemøte 15 Migrering og test Statnett, Nydalen 21. april 2016

2 Agenda ekspertgruppemøte :30-10:15 Introduksjon og prosjektstatus Gjennomgang av overordnet status Status M3 Oppfølging av de som ikke har passert M3 Status energinet.dk 10:15-10:45 Tilbakemelding fra ekspertgruppa: Migreringsprosess og arbeid med NCF-filer Diskusjon: Hvordan håndtere migrering av måleverdier på kansellerte kontrakter? Mulige endringer i filformat for migrering 10:45-11:00 Pause 11:00-11:30 Tilbakemelding fra ekspertgruppa: Prosess for registrering av info i Edielportalen Diskusjon: Aktørgodkjenning 11:30-12:15 Diskusjon: Behandling av innkommende meldinger når Elhub er nede over et datoskille Forståelse av prosessendring for beregning av nettap ved innføring av Elhub Forventninger til kommunikasjon/support fra Elhub i drift 12:15-13:00 Lunsj 13:00-14:30 For piloter: Gjennomgang av pilot test/market trial Gjennomgang av plan for Go Live simuleringer 14:30-14:45 Pause 14:45-15:30 For systemleverandører: Status System Vendor Trial

3 Prosjektstatus Ekspertgruppemøte april 2016

4 Energinet.dk sin Datahub v2.0 i drift Åpnet opp kl den Visualisering av aktivitet I Datahub kl for datahub tjenester på MGA-nivå Grønn = aktivitet siste 15 minutter Gul = aktivitet siste 30 minutes Rød = ingen aktivitet siste 30 minutter Hjemmeside: Kundeportalen: DK/Home/Info Link til nyhetssak fra Energinet.dk:

5 Roadmap - Markedsaktører og Elhub AS Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Milepæler: M M M M4a M4b M M MARKEDS- AKTØRER: DATAVASK & MIGRERING Grunnleggende datavask Uttrekk grunndata Pilot migrering Kontinuerlig datavask og datavedlikehold Inkrementell migrering MARKEDS- AKTØRER: SYSTEM- TILPASNING & TEST Systemtilpasning System-sert Ediel Systemgodkjenn. Elhub Resertifisering Ediel Aktørsert Ediel Godkj. Elhub test Verifik. Elhub prod Elhub GO-LIVE ELHUB AS DAM v1 levert LEVERANSER DAM v2 levert Ferdigstilt Edielportalen klar or TGT Elhub R1 Vendor trial Sanksjonsmilepæler NVE Elhub R2 Vendor Trial Elhub UAT Elhub Market Trials

6 Milesstones IT O A O Externa l activitie s emeter Migr. Base Overordnet plan Elhub implementering Nov Dec Jan Feb Mar Apr May Jun R1 construction R1 SI Test Prepare Training (Plan/Define) R1 SI Test - Execute Today R2 Construction (4s) R2 Product test exec / R2 SI Test Prepare Training/Documentation 23.5 R1/R2 SIT BRS testing R3 Construction (3s) 1.8 Jul Aug Sep Oct 23.5 R2 SI Test - Execute 1.8 NF Tests (Performance/Penetration/DR) R3 Prod test exec / SI Test Prep UAT Part 1 R3 SI Test Execute 1.10 UAT Part DAM 2 UAT Execute eip Test (P3) 1.2 Migration support (capacity) DAM 3 Construct DAM 3 UAT Prepare eip (P4A) Accept. Test Prepare eip Accept. Test Execute eip 4 Accept Test (P4) (P4) 1.7 Execute eip (P4A) Accept Test eip (P4) GA eip (P4a) Dev eip (P4) QA eip (P4a) QA eip (P4A) GA System Vendor Trials Prepare 2.5 System Vendor Trials Execute Market Trials Prepare 2.9 Market Trials Execute Transition AO Run Env. setup 1.7 Interim Operations PMS2A PMS2B PMS3A PMS3B

7 Revidering av tidsplan for publisering av v1.6 av spesifikasjonene Versjon 1.6 skal etter plan publiseres Pga stort arbeidspress og forsinkelse på R2 vil vi ikke rekke å publisere all dokumentasjon som planlagt Komplett liste over kommende endringer vil publiseres innen Endringene vil være spesifisert på et nivå som gjør at systemleverandørene kan implementere endringene Publikasjon av fullstendige dokumenter utsettes til

8 Krav M3 Sertifiseringskrav Alle systemer (APP og EDI) skal være registrert i Edielportalen Alle aktører skal ha registrert hvilke roller og tilhørende systemkombinasjoner (APP+EDI) de skal benytte mot Elhub Alle kjernesystemer (APP) skal være sertifisert i Edielportalen på en av de versjonene av testcase som er tilgjengelig

9 Status M3 aktører

10 Foreløpig status M3 migrering* Antall aktører totalt 332 Har passert ,2 % Ikke passert 16 For lav kvalitet 10 3,0 % Har ikke sendt inn korrekte filer 6 1,8 % Nett Aktører Målepunkter Nivå 1-feil Totalt antall ,56 % Har passert ,3 % ,3 % ,4 % For lav kvalitet 8 5,1 % ,7 % ,1 % Har ikke sendt inn korrekte filer 4 2,6 % - - Kraft Aktører Målepunkter Nivå 1-feil Antall kraftleverandører totalt ,04 % Har passert ,7 % ,9 % 110 0,0 % For lav kvalitet 2 1,1 % ,1 % ,0 % Har ikke sendt inn korrekte filer 2 1,1 % - * Kvalitetssikring pågår, ikke alle feil er hensyntatt

11 Status M3 - sertifisering Systemleverandører 8 systemleverandører er sertifisert 4 systemleverandører er forsinket 2 systemleverandører til kraftleverandører har søkt og fått innvilget utsettelse til 1/7 Aktører Total 498 aktører med eget GLN i Edielportalen 462 har registrert Elhub roller 291 har registrert et kjernesystem som er sertifisert 283 har passert M3

12 M3 prosess videre Elhub har sendt rapport til NVE NVE varsler aktører som ikke har passert om vedtak, med angivelse av siste frist Aktører som ikke har passer datakvalitetskravet kan rette i sine data og sende inn filer til DAM fortløpende Aktører som ikke har passert sertifiseringskravet kan rette opp sin registerering i Edielportalen fortløpende

13

14 Aktiviteter frem til NBS go-live Elhub ekspertgruppe 21. April 2016

15 Fremtiden er elektrisk Tidsplan frem til go-live

16 Informasjon om OTR Fremtiden er elektrisk

17 Fremtiden er elektrisk OTR - Connectivity

18 Fremtiden er elektrisk OTR - Structure data verification

19 Fremtiden er elektrisk OTR Shadow settlement

20 Fremtiden er elektrisk OTR Free testing

21 Parallellrapportering Perioden med parallellrapportering starter 4 uker før NBS settes i drift Skal gi trygghet i en overgangsperiode for at alle systemer genererer korrekt resultat Korrekt avregningsdata skal i hele perioden sendes både til esett og Statnett 3. okt Uke Avregner og fakturerer Avregner Avregner Avregner og fakturerer Fremtiden er elektrisk

22 Registrere henvendelse til esett Fremtiden er elektrisk

23

24 Click to edit Master title style Migrering Ekspertgruppemøte april 2016

25 Kontrakter og kanselleringer Problemstilling En kontrakt blir kansellert eller på annen måte reversert etter at migreringsfiler er sendt inn, slik at den nyeste kontrakten ikke lenger er gjeldende. Husk: A B Opprinnelig BS B <blank> Ny BS, skal reverseres ---- A B Opprinnelig BS B C Ny BS, skal reverseres C <blank> Reversert til opprinnelig BS Nyeste grunndata overskriver alltid tidligere grunndata, fra dato og tidspunkt til dato og tidspunkt (Merk: dette gjelder ikke måleverdier) A <blank> Opprinnelig BS

26 Ny lev. (skal kans.) Aktør Gml lev. (korrekt) Netteier Nødvendig innsending for korreksjon Type fil: Målepunkt Kontrakt CON GO Type = GO, BS = Gml. BS Dato = A <blank> MP BS Dato = A <blank> (hvis avsluttet tidligere) CON BS Type = BS Dato = A <blank> MP BS Dato = A <blank> (hvis avvikende intervaller) CON BS Type = BC Dato = A <blank> Vil medføre fjerning av MP-fil Må ha sammenfallende tidsperiode

27 Nettavregningsområder og måleverdier Bakgrunn Elhub trenger enkelte måleverdier knyttet til det enkelte nettavregnings-området. Disse må først forberedes for gjennom å sende inn en MP-fil med relevante parametere, før måleverdier kan sendes inn. For å lagre verdiene trenger vi en "plassholder" som registreres via målepunktfilen. MP_ID settes da lik EIC-Y for MGA + MP_Type fra filformatet (to tegn) Eks. JIP for et MGA: 11Y LP = 11Y LP For MGA_Used settes EIC-Y verdien for prisområdet Øvrige felter i MP-filen settes blanke eller gis dummy-verdier. Måleverdier for MGA-parameter knyttes deretter til disse "målepunktene", som ikke trenger eller skal ha noen kontrakter.

28

29 Endringer i filformat for migrering Historikk på type målepunkt No - > Yes, from time of NBS go-live Noen små korrigeringer og feilrettinger Typisk eksempel: Endring fra E17 (Forbruk) til E19 (Kombinert)

30 Endringer i filformat for avvik Legger til feltet FaultDueToValue i MP og MV-fila. Ulempe: Endring i format ved å innfør ekstra kolonne Gevinst: Mer informasjon om feilene som rapporteres FaultDueToValue

31 Registrering M3 350 registrert ok 60 av disse har valgt systemer som ikke er sertifiserte Tilbakemeldinger?

32 Migrering M3?

33 Aktørtest Ekspertgruppemøte 21.april 2016

34 Agenda Innspill til Aktørgodkjenning Gjennomgang av Markedstest for piloter Status Systemgodkjenning /System Vendor Trial

35 Overordnet plan for aktørtesting 1/ M3: 15/ M4a: 1/ M4b: 1/ M5: 1/ M6: 15/ Edielportalen er klar for sertifisering Kjernesystemer er sertifisert Systemkombinasjoner er sertifisert Alle systemer er godkjent i Elhub Alle aktører er sertifisert Alle aktører er godkjent i Elhub Sertifisering kjernesystemer Resertifisering Edielportalen Sertifisering systemkombinasjoner Aktørsertifisering Systemgodkjenning Markedstest Elhub Testmiljø Aktørgodkjenning Elhub Prodmiljø Aktørverifisering

36 Overordnet plan for aktørtesting 1/ M3: 15/ M4a: 1/ M4b: 1/ M5: 1/ M6: 15/ Edielportalen er klar for sertifisering Kjernesystemer er sertifisert Systemkombinasjoner er sertifisert Alle systemer er godkjent i Elhub Alle aktører er sertifisert Alle aktører er godkjent i Elhub Sertifisering kjernesystemer Resertifisering Alle markedsaktører skal sertifiseres mot Sertifisering systemkombinasjoner Edielportalen ved å kjøre definerte testcase Aktørsertifisering Edielportalen Et utvalg av aktører (piloter) skal delta i test av Elhub og samlet Systemgodkjenning gjennomføre alle BRS er Markedstest Elhub Testmiljø Alle markedsaktører skal godkjennes mot Elhub ved å gjennomføre definerte BRS er Aktørgodkjenning Alle markedsaktører skal verifisere at de kan kommunisere med Elhub produksjon Elhub Prodmiljø Aktørverifisering

37 Aktørgodkjenning i Elhub Hensikt Teste at markedsaktører kan kommunisere med Elhub i henhold til tekniske krav (EMIF - Elhub Messaging Interface) Teste at markedsaktører forstår Elhub og kan prosessere (utvalgte) BRS er Til diskusjon Hvilke gjennomføre aktørgodkjenning for 300+ aktører mest mulig effektivt? Er det utfordringer med testmiljø og installasjon ute hos aktørene som påvirker godkjenningen? Er det noen avhengighet til Aktørsertifisering mot Edielportalen? Er det ønskelig å kjøre egne tester ut over de som er påkrevd? Er det mulig å bruke aktørgodkjenning til opplæring? Det kan være en begrensning at eenkelte BRS er krever etablering av mye testdata i forkant

38 Piloter test Pilotaktiviteter Brøytekjøring Aktørsertifisering Brøytekjøring Aktørgodkjenning Deltakelse Markedstest

39 Markedstest (Market trial) med piloter 1/ / / / / Elhub Akseptansetest Forberedelse Forberedelse Ca. 1.september til 1.oktober Antatt ressursbruk: Ca. 1,5 dagsverk pr. uke i hele perioden Totalt 6 dagsverk Testrunde 1 Testrunde 2 Markedstest vil koordineres med Elhub Akseptansetest og inngå som en del av denne Alle piloter deltar i begge testrunder Utførelse Periode 1: ca. 10.okt til 31.okt Periode 2: ca. 7.nov til 25.nov Antatt ressursbruk: Ca 2,5 dagsverk pr. uke i testperiodene Totalt 15 dagsverk over 6 uker

40 Markedstest (Market trial) med piloter Hver testrunde vil ha et utvalg testcase for ulike områder (mer enn det som gjøres i Systemgodkjenning) BRS er Crossing processes GUI Rapportering Monitorering Ytelse Behov for selvbetjent testing som del av Markedstest må avklares Ber om innspill på dette

41 Krav til pilotaktører Må ha et testsystem med Elhub-funksjonalitet og som kan kommunisere med Elhub-test Må ha gjort klart testsystemet med nødvendige testdata Må være sertifisert i Edielportalen Må delta i planlegging av tester Må gjennomføre tester i henhold til plan Må delta i statusmøter og rapportere testresultater til Elhub

42 Systemgodkjenning - Plan 19/4: Connectivity-test mot åpent endepunkt: Test ved å sende inn en melding uten sertifikat. Dersom meldingen når endepunktet vil dere motta en Soap-fault i retur med beskjed om at meldingen er Unauthorised. 25/4: Test med sertifikat mot sikkert endepunkt med validering av innkommende meldinger for BRS er i testrunde 1. URL for sikkert endepunkt vil bli sendt ut. 2/5: Intern Smoke-test i Elhub 9/5: Oppstart testrunde 1 3/6: Slutt testrunde 1

43 Aksjoner til aktørene Send inn utfylte testcase-beskrivelser basert på mal Send inn navn, epost og mobilnummer til kontaktperson for test Send inn organisasjonsnummer for sertifikatet dere vil bruke i testen Send inn GLN pr. rolle for juridiske og fysiske adresser dere vil bruke i testen Gi tilbakemelding om testdata Frist 22/4

44 Gjennomføring Testmiljøet vil i utgangspunktet være tilgjengelig 24/7 men vi vil kun ha support i normal arbeidstid Vi vil etablere 1. og 2.linje i Elhub for testen 1.linje har samme telefonnummer som Ediel support Epost-henvendelser skal sendes til post@elhub.no Feil i Elhub skal meldes på Excel Bruk av Jira/Confluence vil vurderes videre

45 Ekspertgruppemøte 15 Nett-tap

46 Ansvar for tapsberegningen Elhub overtar beregningsansvaret Nettselskapene har ansvaret for å sett opp beregningstype og parametere

47 Nettområder Sentralnett Regionalnett Distribusjonsnett Sub-nett Primært ønsker vi at nettområdene ikke slås sammen, da tapsberegningen da blir mindre presis Der er mulig å definere virtuelle umålte men beregnede utvekslingspunkt mellom f.eks. regionalnett og distribusjonsnett

48 Beregningstyper/formler Har kun timesavregnede målepunkt Har profilavregnede målepunkt Formel: tomgangstap + tapskonstant * innmating^2 NB! Beregningen skjer i kwh mot MWh i mange system i dag! Tomgangstap: flytte komma 3 plasser til høyre Tapskonstant: flytte komma 3 plasser til venstre Har få profilavregnede målepunkt Formel som over, men skalert sammen med årsforbruket på de profilavregnede målepunktene

49 Støtte i Elhub Legges inn i god tid før oppstart! (del av go-live plan) Simulering av tapsformelen Feilmelding hvis en f.eks. velger formel for ren timesavregning hvis det finnes profilavregnede målepunkt i nettområdet. Månedlig (ellers oftere) rapport som lister nettområder der f.eks. andel profilavregnede begynner å bli så liten at skalert formel bør benyttes

50 Justering av tapet frem til Y + 3 år Hvert avviksoppgjør benytter tapet som motpost Hver måned blir det derfor en delta endring i tapet per døgn Hvert år kjøres en avstemming av tapet så langt Innmating minus oppdaterte timesverdier for alt forbruk (etter alle avviksoppgjørene så langt) Resultatet er tilgjengelig for en gitt dag, og med timesoppløsning

51 Status i bransjen Var dette kjent? Har dere en plan for å velge riktig beregningstype og eventuelle parametere i formelen? Andre kommentarer?

52 Ekspertgruppemøte 15 Nedetid

53 Nedetid Meldingsmottaket designes til å ha høy oppetid slik at Elhub kan motta meldinger selv om man har nedetid på selve prosesseringen av meldingene Elhub vil ha fokus på å få opp meldingsmottaket så raskt som mulig ved nedetid Så lenge Elhub ikke har nedetid på meldingsmottaket over midnatt vil man normalt få akseptert meldinger Så lenge man har fått synkron kvittering på at meldingen er mottatt (ok http respons) så vil meldingen prosesseres med regler for mottaksdato Elhub vil ha et backupmiljø man kan bytte over til

54 Eksempel på nedetid 1 Man lager en BRS 302 melding 18:04 med gyldighetsdato dagens dato Elhubs meldingsmottak er oppe, men prosesseringen er nede Man sender inn meldingen 18:05 og får umiddelbart svar om at den ble mottatt Elhubs prosesseringsmotor kommer opp 09:12 neste dag Meldingen prosesseres likt som om prosesseringen ble gjort dagen før Meldingen vil ikke bli avvist pga tidsfrister

55 Eksempel på nedetid 2 Man lager en BRS 302 melding 08:04 med gyldighetsdato dagens dato Elhubs meldingsmottak er nede Meldingsmottaket kommer opp 23:45 Man sender inn samme melding som 08:04 og sender denne til Elhub 23:59 Man får synkront kvittert at den er mottatt innen 00:00 Elhub vil prosessere meldingen etter midnatt, men med reglene som gjaldt for dagen før Meldingen vil ikke bli avvist pga tidsfrister

56 Eksempel på nedetid 3 Man lager en BRS 302 melding 08:04 med gyldighetsdato dagens dato Elhubs meldingsmottak er nede Meldingsmottaket kommer opp 23:45 Man sender inn samme melding som 08:04 og sender denne til Elhub 00:02 Man får synkront kvittert at den er mottatt 00:02 I og med at Elhub mottok meldingen etter midnatt vil den prosesseres med reglene for neste dag Meldingen blir avvist pga tidsfrister og man må konvertere meldingen til en 402

57 Eksempel på nedetid 4 Man lager en BRS 302 melding 08:04 med gyldighetsdato dagens dato Elhubs meldingsmottak er nede Meldingsmottaket kommer opp 06:34 neste dag Man sender inn samme melding som 08:04 og sender denne til Elhub 06:44 og får umiddelbart svar om at den ble mottatt I og med at Elhub mottok meldingen etter midnatt vil den prosesseres med reglene for neste dag Meldingen blir avvist pga tidsfrister og man må konvertere meldingen til en 402

58 Bakgrunn Helt fra starten av Elhub prosjektet og forskriftsarbeidet har aktørene blitt gitt ansvaret for køhåndtering En stor endring med Elhub, er at prosessene kjøres online mellom fagsystemene og Elhub, uten dagens EDI-servere i mellom. Vi forventer at markedsprosessmeldinger som ligger på vent, sendes inn i god tid, primært mellom 00:00 og 01:00, og ellers gjennom arbeidsdagen. Det er ikke lagt opp til at f.eks. grunndataendringer som gjelder dagens dato skal sendes inn 23:59. Risikoen kan reduseres ytterligere ved å sende inn melding i god tid.

59 Utfordring og kostnader Vi må forstå bedre: Gjelder utfordringen kun grunndata? Skyldes den høye kostnaden at en har valgt å dekoble fagsystemene fra Elhub? Hvordan tenker dere å håndtere at deres meldingskø eller internett-linje går ned noen dager?

60 Videre prosess Vi må skille mellom go-live, eventuell plan for 1 dag/1 uke utsettelse og nedetid etter go-live. Vi må forstå utfordringen bedre Vi vil jobbe oss gjennom momentene i eskaleringen i tett dialog med NVE Dere bør jobbe videre med løsning for å håndtere regelverket slik det er definert.