Ekspertgruppemøte 15 Migrering og test Statnett, Nydalen 21. april 2016
Agenda ekspertgruppemøte 21.4.2016 09: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
Prosjektstatus Ekspertgruppemøte 15 21. april 2016
Energinet.dk sin Datahub v2.0 i drift 01.04.2016 Åpnet opp kl. 00.01 den 01.04.2016. Visualisering av aktivitet I Datahub kl.10.45 01.04.2016 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: http://energinet.dk/da/el/datahub/sider/datahub.aspx Kundeportalen: https://energinet.eloverblik.dk/da- DK/Home/Info Link til nyhetssak fra Energinet.dk: http://energinet.dk/da/el/nyheder/sider/morgendagens-elmarked-begynder-i-dag.aspx
Roadmap - Markedsaktører og Elhub AS 2015 2016 2017 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Milepæler: M1 01.07.15 M2 01.11.15 M3 15.04.16 M4a 01.07.16 M4b 01.09.16 M5 01.11.16 M6 15.01.17 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 20.02.2017 ELHUB AS DAM v1 levert LEVERANSER DAM v2 levert Ferdigstilt Edielportalen klar or TGT Elhub R1 Vendor trial 01.05.16 Sanksjonsmilepæler NVE Elhub R2 Vendor Trial 10.06.16 Elhub UAT Elhub Market Trials
Milesstones IT O A O Externa l activitie s emeter Migr. Base Overordnet plan Elhub implementering 2015 2016 Nov Dec Jan Feb Mar Apr May Jun R1 construction R1 SI Test Prepare 5.2 8.2 Training (Plan/Define) R1 SI Test - Execute Today R2 Construction (4s) 2.5 2.5 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 1.8 1.7 UAT Part 1 R3 SI Test Execute 1.10 UAT Part 2 18.2 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 15.3 1.4 15.6 eip (P4) GA eip (P4a) Dev eip (P4) QA eip (P4a) QA eip (P4A) GA 15.9 1.2 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 18.12 1.3 1.7 1.10 PMS2A PMS2B PMS3A PMS3B
Revidering av tidsplan for publisering av v1.6 av spesifikasjonene Versjon 1.6 skal etter plan publiseres 01.05.2016 Pga stort arbeidspress og forsinkelse på R2 vil vi ikke rekke å publisere all dokumentasjon som planlagt Komplett liste over kommende endringer vil publiseres innen 01.05. Endringene vil være spesifisert på et nivå som gjør at systemleverandørene kan implementere endringene Publikasjon av fullstendige dokumenter utsettes til 01.06.2016
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
Status M3 aktører
Foreløpig status M3 migrering* Antall aktører totalt 332 Har passert 316 95,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 156 3 165 366 17 817 0,56 % Har passert 144 92,3 % 3 111 040 98,3 % 13 960 0,4 % For lav kvalitet 8 5,1 % 54 326 1,7 % 3 857 0,1 % Har ikke sendt inn korrekte filer 4 2,6 % - - Kraft Aktører Målepunkter Nivå 1-feil Antall kraftleverandører totalt 175 2 956 159 1 232 0,04 % Har passert 171 97,7 % 2 953 740 99,9 % 110 0,0 % For lav kvalitet 2 1,1 % 2 419 0,1 % 1 122 0,0 % Har ikke sendt inn korrekte filer 2 1,1 % - * Kvalitetssikring pågår, ikke alle feil er hensyntatt
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
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
Aktiviteter frem til NBS go-live Elhub ekspertgruppe 21. April 2016
Fremtiden er elektrisk Tidsplan frem til go-live
Informasjon om OTR http://www.esett.com/materials/commissioning/ Fremtiden er elektrisk
Fremtiden er elektrisk OTR - Connectivity
Fremtiden er elektrisk OTR - Structure data verification
Fremtiden er elektrisk OTR Shadow settlement
Fremtiden er elektrisk OTR Free testing
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 36 37 38 39 40 41 42 43 Avregner og fakturerer Avregner Avregner Avregner og fakturerer Fremtiden er elektrisk
Registrere henvendelse til esett http://www.esett.com/contact/ Fremtiden er elektrisk
Click to edit Master title style Migrering Ekspertgruppemøte 15 21. april 2016
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
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
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: 11Y1234567890123 + LP = 11Y1234567890123LP 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.
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)
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
Registrering M3 350 registrert ok 60 av disse har valgt systemer som ikke er sertifiserte Tilbakemeldinger?
Migrering M3?
Aktørtest Ekspertgruppemøte 21.april 2016
Agenda Innspill til Aktørgodkjenning Gjennomgang av Markedstest for piloter Status Systemgodkjenning /System Vendor Trial
Overordnet plan for aktørtesting 1/2 2016 M3: 15/4 2016 M4a: 1/7 2016 M4b: 1/9 2016 M5: 1/11 2016 M6: 15/1 2017 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
Overordnet plan for aktørtesting 1/2 2016 M3: 15/4 2016 M4a: 1/7 2016 M4b: 1/9 2016 M5: 1/11 2016 M6: 15/1 2017 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
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
Piloter test Pilotaktiviteter Brøytekjøring Aktørsertifisering Brøytekjøring Aktørgodkjenning Deltakelse Markedstest
Markedstest (Market trial) med piloter 1/8 2016 1/9 2016 1/10 2016 1/11 2016 15/1 2017 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
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
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
Systemgodkjenning - Plan 19/4: Connectivity-test mot åpent endepunkt: https://service-vtrials.elhub.org:8200/webservice/services/marketprocesses 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
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
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
Ekspertgruppemøte 15 Nett-tap
Ansvar for tapsberegningen Elhub overtar beregningsansvaret Nettselskapene har ansvaret for å sett opp beregningstype og parametere
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
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
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
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
Status i bransjen Var dette kjent? Har dere en plan for å velge riktig beregningstype og eventuelle parametere i formelen? Andre kommentarer?
Ekspertgruppemøte 15 Nedetid
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
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
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
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
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
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.
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?
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.