Ekspertgruppemøte Elhub Migrering og test. Oslo 16. Oktober 2014

Transkript

1 Ekspertgruppemøte Elhub Migrering og test Oslo 16. Oktober 2014

2 Agenda og introduksjon Dagens agenda Status hjemmelekser Valg av pilotaktører Pilotenes oppgave høsten 2014

3 Agenda ekspertgruppemøte :30-9:45 Velkommen og introduksjon Dagens agenda Presentasjon av pilotaktører for migrering 9:45-10:30 Informasjon fra NVE Revidert forskrift :30-10:45 Pause 10:45-11:15 Personvern Behov for fødselsnummer Status for innføring av fødselsnummer 11:15-12:00 Datasikkerhet Infrastruktur for distribusjon av migreringsfiler 12:00-12:15 Pause 12:15-12:45 Aktiviteter mot bransjen og eksterne Preliminær datavask - Overordnet regelsett for bransjen 12:45-13:00 Test Fokusområder 13:00-14:00 Lunsj 14:00-15:00 Gruppe Migrering Dataelementer Semantikk og syntaks Gjennomgang av kapittel 3 i Elhub Specification of Migration Files samt innspill fra ekspertgruppen Gjennomgang av kapittel 4 i Elhub Specification of Migration Files samt innspill fra ekspertgruppen 15:00-15:30 Oppsummering og videre arbeid. Gjennomgang av kapittel 5 i Elhub Specification of Migration Files Gruppe Test Elhub/Edielportalen - Prosess og roller Presentasjon av prosesser for innsamling av måledata hos aktørene Diskusjon om roller og ansvar til nye tjenesteleverandører og hvordan dette påvirker rutiner for sertifisering Mulige forbedringspunkter i Edielportalen Utfordringer knyttet til utvikling og test Tema for neste møte

4 Status hjemmelekser Mange gode og fyldige tilbakemeldinger Viktig at tilbakemeldinger kommer innen fristen slik at vi rekker å bearbeide alle innspill før ekspertgruppemøtene Ekspertgruppen representerer bransjeaktørene inn i prosjektet og det er viktig for oss at bransjen blir hørt

5 Status pilotaktører migrering

6 Pilotenes oppgave høsten 2014 Gjøre datauttrekk i henhold til standarden beskrevet i dokumentet Elhub Specification of Migration Files Man skal gjøre uttrekk enten som kraftleverandør eller nettselskap, slik at vertikalintegrerte selskap må velge seg en rolle Et vertikalintegrert selskap kan gjøre uttrekk i begge roller, men det må være tydelig hvilken rolle de forskjellige uttrekkene gjelder. Standarden skal være lik for kraftleverandører som ikke er integrert med et nettselskap Standarden skal følges til punkt og prikke både når det gjelder syntaks og semantikk

7 Pilotenes oppgave høsten 2014 forts. Arbeidet med uttrekkene skal presenteres for ekspertgruppen enten 18. november eller 11. desember Tekniske problemer relatert til ytelse Problemer med spesifikke kildesystemer Fikk man ut alle data på riktig format? Noen tilfeller der man mangler data? Det forventes at man vil trenge bistand fra systemleverandørene i pilotarbeidet, og det er også ønskelig at disse trekkes inn

8 Altså.. ALLE medlemmene i ekspertgruppen skal være med å utforme dataformatene for migrering gjennom innspill i form av hjemmelekser og diskusjoner i gruppen Pilotene skal I TILLEGG teste disse formatene mot sine egne systemer, det vil si lage automatiske rutiner (programvare) for å gjøre disse uttrekkene og presentere erfaringene sine for gruppen. Hva fungerte godt med formatene? Må noen av formatene endres?

9 Fortrolig behandling av pilotenes data Elhub utarbeider fortrolighetserklæring: Sikker overføring av pilotdata mellom pilot og Elhub Betryggende og sikker lagring av pilotdata hos Elhub Forpliktelse om at Elhub ikke transporterer dataene videre. Forpliktelse om at Elhub ikke bruker dataene utover det som er formålet med pilotprosjektet Forpliktelse om at Elhub har innhentet taushetserklæringer fra sine medarbeidere og konsulenter. Forpliktelse om destruksjon (sletting) av data etter at Elhubprosjektets behov for datasettene har opphørt.

10 Elhub - Status Prosjektet er i rute Statnett forhandler med tilbydere Anskaffelse offentliggjøres januar 2015 Oppstart oktober 2016 Ekstern kvalitetssikring God prosjektledelse Usikkerhet om rammevilkår og om tidsfrist er oppnåelig ROS-analyse av Elhub-prosjektet Gjennomført første gjennomgang vinteren 2014 Neste gjennomgang i mars 2015 Norges vassdrags- og energidirektorat

11 Elhub - Forskriftsendringer Viktige temaer i høringen mht. Elhub Høring av forskriftsendringer Høringsfrist 1. oktober Personvern (lagringstid, fødselsnummer) Oppsummering av høringen pågår Rolleendring for nettselskap og kraftleverandør Tidspunkt for innføring av NBS Viktig å avklare problemstillinger knyttet til personvern før vedtak Definisjon av nettselskap Måling av produksjon Nøytralitetskrav Asymmetrisk avviksoppgjør Norges vassdrags- og energidirektorat

12 Forskriftsendringer Leverandørskifter, anleggsovertagelse Ansvar for beregningsoppgaver Stipulering av timesvis uttak + estimering Nettap Avregningsdata til regulerkraftavregning Måleverdier tilgjengelig kl Lagring av timeverdier og kundeinformasjon i 3 år i Elhub Avviksoppgjør Standard for behandling av timeverdier (VEE) Overføring av timeverdier innen kl Kraftleverandør skal presentere forbruksdata Sikkerhetskrav Nøytralitetskrav Norges vassdrags- og energidirektorat

13 Migreringsprosjekt Kritisk med en effektiv migrering for gjennomføring av Elhub-prosjektet Alle må bidra og må sette av ressurser til kvalitetssikring i egen database i budsjett NVEs rolle Pålegg om kvalitetssikring og testing av datakvalitet Må gjennomføres innen gitte frister/milepæler Norges vassdrags- og energidirektorat

14 Takk for oppmerksomheten! Norges vassdrags- og energidirektorat

15 Statnett SF Personvern og datasikkerhet i Elhub migreringsprosesser

16 Agenda Personvern Personopplysningsloven Kraftmarkedet Datasikkerhet ved migrering Bakgrunn Nå (transisjonsperiode) Med Elhub løsning (produksjoninfrastruktur)

17 Agenda Personvern Personopplysningsloven Kraftmarkedet Datasikkerhet ved migrering Bakgrunn Nå (transisjonsperiode) Med Elhub løsning (produksjoninfrastruktur)

18 Nytt Elhub-dokument: Identifisering av sluttkunder i kraftmarkedet

19 Personvern - personopplysningsloven Lov om behandling av personopplysninger (personopplysningsloven) "beskytte den enkelte mot at personvernet blir krenket gjennom behandling av personopplysninger" sikre behandling "i samsvar med grunnleggende personvernhensyn, herunder behovet for personlig integritet, privatlivets fred og tilstrekkelig kvalitet på personopplysninger

20 Personvern personopplysninger i kraftmarkedet Konsesjonsbelagt (nettselskaper) Navn, fødselsdato og adresser Andre personopplysninger (beskrivelser, kommentarer, osv.?) Avtaleregulert (kraftleverandører) Navn, fødselsdato, fakturainformasjon og adresser Datatilsynet ift. AMS: Måleverdier er å betrakte som personopplysninger Hva med måleverdier mellom kontraktsforhold, samt separasjon av eierskap til måleverdier fra samme målepunkt til forskjellige eiere? Ingen sensitive personopplysninger Men det vil være kommersielt sensitive opplysninger

21 Personvern identiteter i kraftmarkedet Begrep Fødselsnummer (les: identitet på fysisk person) Identifikasjonsnummer og type identifikasjon for utenlandske statsborgere Elhub entitetid Organisasjonsnummer MarkedsaktørID, GLN for kraftleverandør og nettselskap MålepunktID, GSRN for målepunkter Entitet relevant også utenfor kraftmarkedet Ja Ja Ja Ja Ja Nei Identitet benyttes også utenfor kraftmarkedet Ja Ja Nei Ja Nei Nei

22 Kraftmarkedet sammenfallende identiteter Fra NVEs sider: "Når du har inngått nettleieavtale med nettselskapet, står du fritt til å velge hvilken kraftleverandør du ønsker å få levert strøm fra." Dvs. kun personen som har inngått nettleieavtalen kan forplikte målepunktet gjennom en kraftleveransekontrakt Aktør koblet til nett = sluttkunde Må være sammenfallende identitet på både nettleie- og kraftleveransekontrakt Kan være flere adresser (evt. som peker til andre personer) knyttet til forholdet, eksempelvis fakturamottaker og kontaktpersoner.

23 Kraftleverandør Nettselskap Kraftleveranseavtale Nettilknytningsavtale Navn og adresse Måleverdier Adresse Måleverdier Adresse Sluttkunde Målepunkt Måleverdier

24 Personvern unike identiteter i kraftmarkedet Unik identifikasjon av sluttbruker Må ivareta både norske og utenlandske identiteter Elhub må benytte en egen unik intern identitet, frikoblet fra andre identitetsbegreper Identifikasjonsbegrep må følge sluttbruker gjennom markedet Elhub vil lagre for senere validering, samt benytte denne for å knytte aksjoner til korrekt intern identitet i registeret

25 Personvern identiteter i kraftmarkedet Unik identifikasjon to aspekter Hvilke begreper skal brukes i Elhubs registre, og Hvilke identifikasjonsbegrep skal benyttes av aktørene for unik identifikasjon av personer i Elhubs registre

26 Personvern identiteter i kraftmarkedet Hva skjer uten fødselsnummer? håndteres som i dag (den enkelte markedsaktøren identifiserer personer etter beste evne og basert på tilgjengelig informasjon) Må søke etter Elhub identifikasjon som i dagens Nubix, og benytte denne i meldinger Markedets løsninger vil måtte distribuere en Elhub identifikasjonen med koder for tilgang til måleverdier

27 Personvern identiteter i kraftmarkedet Spesiell risiko uten fødselsnummer? en person vil kunne bli knyttet til en feil identitet datakvaliteten generelt vil bli vesentlig redusert kvaliteten på personopplysningene i registeret ikke lenger vil være tilstrekkelig for registerets, markedets eller sluttbrukerens formål Enhver feil vil måtte korrigeres manuelt, kostnadene for dette må hentes fra kollektivet av sluttbrukere

28 Fødselsnummer behov og konsekvens Fødselsnummer er derfor nødvendig for å 1. Sikre entydig identifikasjon av sluttbruker 2. Eliminere uønsket og/eller uautorisert eksponering av personopplysninger i markedet 3. Ivareta forskriftsmessige krav til felles identitet på nett- og kraftkontrakter 4. Sikre kontroll på juridiske forhold og økonomiske forpliktelser i markedet

29 Fødselsnummer i kraftmarkedet gir oss Bedre datakvalitet grunnet enklere kobling av identitet og personopplysninger (les: måleverdier) Lettere identifikasjon av sluttbruker Enkel tilgang til sluttbrukerens egne måleverdier BankID og andre tilsvarende offentlige ID-begreper krever bruk av fødselsnummer som nøkkel til informasjon

30 Hvor kan og bør vi benytte fødselsnummer? Kun for identifikasjon av sluttbruker Sluttbruker er den reelle forbrukeren av kraft Skal være sammenfallende for både kraft- og nettkontrakter Ikke nødvendig eller ønskelig for: Fakturamottaker/fakturaadresse Kontaktpersoner Hva med tilfeller der flere er ansvarlige for samme målepunkt (eks. ektepar med felles bo) Hvem er oppført i kontraktene og hvem kan endre kraftleverandør?

31 Status innføring av fødselsnummer Fra forskrift 301 (under revisjon, gjeldende fra 1. okt. 2016): En kraftleveringskontrakt kraftleveringsavtale skal minimum inneholde følgende informasjon: a) målepunkt-id, b) sluttbrukers fødselsnummer eller organisasjonsnummer, c) sluttbrukers navn eller firmanavn, d) hvilket produkt avtalen gjelder, e) sluttbrukers samtykke. Kraftleveringsavtalen kan gi kraftleverandør adgang til ensidig å endre målepunkt ID i forbindelse med anleggsovertagelse. Det er også viktig at nettselskap og kraftleverandør tar i bruk fødselsnummer i arbeidet med å migrere data slik at de kan foreta kvalitetssikring før data overføres til Elhub. Se for øvrig kommentarer til ny 1-6 om migrering av måleverdier og kundeinformasjon til avregningsansvarlig.

32 Søkelinjer i Elhub informasjonsmodell Required key: Party reference (current or new) class Information Model Master Data is used for invoicing of Searchable: Contract parties, e.g., Balance Suppliers Bitemporal object Security Object Balance Supply Contract 1..* must refer to a valid Required key: Market parties (these are always known) Searchable: Grid Access Provider Searchable: Name, date, customer Id Bitemporal object Party connected to Grid 0..* points invoicing to 1 Security Object Consumer Personal Data references 1 0..* 1 use as contact 0..1 references is responsible contact for Multi-Domain Base Address governs balance supply to May be connected to Domains:: Accounting Point is governing access to Multi-Domain Base Domains::Metering Point is located at Metering Point address 0..* Bitemporal object Security Object Grid AccessContract Required key: Metering Point Id (current, or new and old) Searchable: Address (invoice and contact) Postal address Searchable: Metering Point Id, Metering Grid Area Searchable: Metering Point address

33 Example search P.no.: Ole Olsen Kanonveien 3, 1234 Oslo Found Possible searches: Customer ID -> Personal Data (direct access) Name/Date -> Personal Data (may be mult. hits) Address -> Postal address (ditto) Address -> Metering Point Address (ditto) If multiple permutations of relations (customer, invoice, contact), there may be multiple instances of Party connected to Grid. Consumer Personal Data: 550e8400-e29b-41d4-a InvoiceAddress_Used: 550e8400-e29b-41d4-a Party connected to Grid: 550e8400-e29b-41d4-a InvoiceUsed: 550e8400-e29b-41d4-a Contact_Used: 550e8400-e29b-41d4-a A Party connected to Grid may have multiple metering points. Balance Supply Contract: 550e8400-e29b-41d4-a InvoiceRecipient_Used: 550e8400-e29b-41d4-a MeteringPoint_Used: 550e8400-e29b-41d4-a Balance Supply Contract: 550e8400-e29b-41d4-a InvoiceRecipient_Used: 550e8400-e29b-41d4-a MeteringPoint_Used: 550e8400-e29b-41d4-a Accounting Point: 550e8400-e29b-41d4-a MeteringPoint_Used: Address_Reference: 550e8400-e29b-41d4-a Unique identifier from contract to accounting point and metering point address. Metering Point address: 550e8400-e29b-41d4-a StreetName:Kanonveien,BuildingNumber:3,PostCode:1234,PlaceName:Oslo

34

35 Agenda Personvern Personopplysningsloven Kraftmarkedet Datasikkerhet ved migrering Bakgrunn Nå (transisjonsperiode) Med Elhub løsning (produksjoninfrastruktur)

36 Agenda Personvern Personopplysningsloven Kraftmarkedet Datasikkerhet ved migrering Bakgrunn Nå (transisjonsperiode) Med Elhub løsning (produksjoninfrastruktur)

37 Filformat en liten recap. Semikolon separert liste (SDV fil) Kodesett UTF-8 Velkjent og enkelt format Mye brukt i migreringsverktøy Liten overhead

38 Hvorfor filer? mer recap. Aktører Grid owner Sikkerhetssone DB DB SDV Power supplier DB DB SDV Analyse verktøy Migrerings DB Elhub DB Other DB DB SDV

39 Security levels fra Elhub utlysningsdokumenter Information level Authorization level Authentication level Infrastructure level Information level security model (cf. role-, market- and information models) Authorization level security model (user definitions and role definition) Authentication level security model (interface specific authentication methods) Infrastructure level security model (interface locations, security zones, etc.) Implicit authorizations Explicit authorizations Elhub internal users Market party users Business to business Portal access Web access Internet linked access Extranet linked access Internal access

40 Infrastructure level security model fra utlysning Internet DMZ/internet End users Interface: Web-API (authorizations) Extranet (market party access) DMZ Market parties Interface: Web-API (metered data) Interface: Portal (users and parties) Interface: B2B Elhub Core zone Elhub system Internal (Elhub) users Office zone Interface: Portal (users and parties)

41 Personopplysninger behandling (administrativt) Må være avtalebasert Nettselskaper har konsesjon for behandling av personopplysninger Elhub har ikke konsesjon, må sikre tilgang via avtaler Elhub jobber med utarbeidelse av avtaletekst Vil omfatte bl.a.: forpliktelse om forsvarlig behandling av personopplysninger sikker overføring av pilotdata betryggende og sikker lagring av pilotdata forpliktelse om at data ikke transporteres videre forpliktelse om kun bruk av data til angitt formål forpliktelse om innhentet taushetserklæringer fra medarbeidere og konsulenter forpliktelse om destruksjon av data etter endt behov Avtalestruktur vil ivareta krav til sporbarhet i behandling og ansvar i markedet

42 Personopplysninger behandling nå (teknisk) Må være sikret mot innsyn Må være gjennomførbart innen rett tidsperspektiv To mulige alternativer for transport: Fysisk overlevering (USB-pinne) med tilhørende signering på mottatt data Bruk av eksisterende infrastruktur (eksempelvis Nubix med tilhørende sertifikater) Muligens gjenbruke infrastruktur for web-services i Nubix? Dagens EDIEL-modell over SMTP er ikke sikker nok, samt at Elhub ikke er del av infrastrukturen Lagring og behandling Forventer å etablere et midlertidig lokalt nett (eller sone) for behandling av pilotdata hos Elhub Tilsvarende sikring forventes at ivaretas hos de aktører som håndterer pilotdata/er med i pilotgruppen

43 Personopplysninger behandling nå (pilotprosess) Før etablert midlertidig regime Eksporterte og behandlede data beholdes hos den enkelte pilotaktøren Pilotoppgaver vil ikke eksponere data, kun rapportering av erfaringer og fremdrift Etter etablert egnet sikkerhetsregime Pilotdata overføres på avtalt form (enten fysisk eller via egnet infrastruktur) Pilotdata behandles iht. avtalte og avtalefestede regler hos Elhub På dette tidspunktet kan vi starte manuell sammenstilling og kvalitetskontroll av data

44 Personopplysninger behandling fremtidig (teknisk) Basert på endelig infrastruktur for Elhub Avventer anskaffelsesprosess for definisjon og etablering av egnet infrastruktur hos Elhub Flytting av kommunikasjon gradvis etter som de enkelte pilotaktører registreres inn i, og implementerer besluttet infrastruktur NB! Endelig infrastruktur er IKKE besluttet enda Det som foreligger er format på xml-meldinger for endelige prosesser slik disse blir prosessert hos Elhub

45

46 Datasikkerhet i migrering og test av migrering Formål med data Produksjon vs. Test Kilde for data Produksjonssystemer? Testsystemer? Genererte testdata? Hva er tilstrekkelig for hvilke områder?

47 Datasikkerhet og datakvalitet Metering point data consistency Structure data consistency Single-actor consistency Data integrity across multiple actors Verify identity of customers Verify identity of metering points (vs. locations, etc.) Verify relation between metering points, customers and location Verify relations between customers of different actors Verify consistent metering point use and reference Verify metering grid area consistency (balance within the MGA) Verify metering point status (production, consumption, exchange and non-calculated) Verify supply balance within metering grid areas Verify balance across MGAs and within market balance areas

48 Ekspertgruppemøte Elhub Aktiviteter mot bransjen og eksterne Oslo 16. Oktober 2014

49 Kommunikasjonsutfordring Elhub har en enorm kommunikasjonsutfordring Mange aktører kjenner knapt til Elhub For at prosjektet skal lykkes er man avhengig av at ALLE aktører (ca. 200) bidrar AKTIVT i forbindelse med delprosjektene for migrering og test

50 Kommunikasjonsplan høsten 2014 I løpet av oktober: Sende epost til hele bransjen med grunnleggende informasjon om Elhub og migrerings- og testprosjektene I løpet av november: Sende ut spørreundersøkelse for å kartlegge bransjens modenhet for migrering og test I løpet av desember: Publisere resultatet av undersøkelsen og oppfordre til forberedelse til migrering Hele tiden: Delta på bransjetreff og konferanser (f.eks. Elmåledagene) og spre det glade budskap!

51 Arbeid mot eksterne Elhub er ansvarlig for å etter beste evne kontrollere at dataene som migreres inn fra aktørene er korrekte, og avvise ukorrekte data. Migreringsprosjektet ser for seg integrasjoner mot følgende registre: Folkeregisteret (fødselsnummer og navn) Matrikkelen (matrikkeladresser) Posten (postadresser) Brønnøysundregistrene (organisasjonsnummer) GS1 (GLN og GSRN nummer)

52 Arbeidsplan mot eksterne Folkeregisteret: Har mottatt initiell informasjon. Prosjektet skal få en kontaktperson. Matrikkelen: Vi har en kontaktperson. Statnett har også interne ressurser med matrikkelkompetanse som vi har avtalt møte med. Posten: Prosjektet skal få en kontaktperson. Brønnøysundregistrene: Prosjektet skal få en kontaktperson GS1: Prosjektet har en kontaktperson og vi har avtalt initielt møte

53 Mulighet? Oppslag i eksterne registre via DAM? Register 1 Migration Files Register 2 Aktør Correction Files DAM Register 3 Register 4 Register 5

54 Ellers.. På neste ekspertgruppemøte får vi besøk fra Danmark De skal fortelle om sine erfaringer med innføring av Datahub og migrering og test De er i ferd med å rulle ut sin v2.0 og kan derfor snakke om hvilke endringer de har valgt å gjøre denne gang (!)

55 Forberedelse til datamigrering Vi ønsker at aktørene skal starte forberedelse til datamigrering så snart som mulig Dvs. analyse av egen datakvalitet og datavask Hva kan de gjøre før endelig format og verktøy er klare?

56 Målepunkt Målepunktet skal ha en gyldig ID i henhold til gjeldende standard Det skal ikke finnes flere målepunkt med samme ID Alle fysiske målepunkt skal ha en gyldig fysisk lokasjon Dersom Matrikkelinformasjon er brukt, skal denne være gyldig og komplett Dersom postadresse er bruk, skal denne være gyldig og komplett Det skal vites om målepunktet brukes i balanseavregningen Det skal vites om målepunktet er aktivt, inaktivt eller deaktivert Det skal vites om målepunktet er av typen produksjon, forbruk, en kombinasjon av de to, eller utveksling. Det skal vites om målepunktet er timesavregnet eller profilavregnet Det skal vites hva som er estimert årsforbruk for profilavregnede målepunkt

57 Kundedata Fødselsnummer innføres med Elhub Navn på personkunder skal være identisk med navn i Folkeregisteret. Navn skal dessuten være oppdelt i felter for fornavn, mellomnavn og etternavn Postadresse skal være gyldig og komplett

58 Ekspertgruppemøte Elhub Migrering og test Oslo 16. oktober 2014

59 Test - Fokusområder Hvilke tester skal Kraftleverandører og Nettselskaper gjennomføre? Når skal testene gjennomføres? Hvilke verktøy vil tilbys aktørene for testing? Hvilke bidrag ønsker vi fra ekspertgruppen?

60 Tester som skal gjennomføres Sertifisering i Edielportalen Både kraftleverandører og nettselskap og deres systemleverandører må sertifiseres Selvbetjent innenfor en definert tidsperiode Godkjenning i Elhub Ende-til-ende test for kraftleverandører og nettselskap Forutsetter sertifisering i Edielportalen Administreres av Statnett Målet med aktørtesten er å sjekke at prosesser og systemer for utveksling av informasjon med Elhub fungerer som de skal

61 Tentativ tidsplan for aktørtest 1/ / / / Edielportalen ferdig utviklet Elhub systemtest ferdig Elhub akseptansetest ferdig Elhub go-live Sertifisering Systemleverandører Sertifisering Aktører Godkjenning Aktører i Elhub

62 Testverktøy Edielportalen skal benyttes til test og sertifisering av aktører og systemleverandører på samme måte som i dag Edielportalen vil simulere Elhub meldingsutveksling Vi vil vurdere om den også skal kunne simulere aktører Ny versjon av Edielportalen spesifiseres nå og er planlagt utviklet første halvdel av 2015

63 Bidrag fra ekspertgruppen Komme med innspill til ny Edielportal Verifisere Testplaner og spesifikasjoner for aktørtesting Identifisere utfordringer hos aktørene som kan påvirke Elhub Bistå med å definere kritiske suksessfaktorer for Elhub Hva vi bør gjøre og hva vi ikke bør gjøre Delta som piloter i test Testing Edielportalen Q Systemtest Elhub Q Q Akseptansetest/Markedstest Elhub Q Pilot-test Elhub Q3 2016

64 Relasjoner innad og mellom filer

65 Operasjoner for beskrivelse av relasjoner Notation / function name Implication == Check if the field equals the value stated!= Check if the field does not equal the value stated > Check if the value in the field is greater than the value (or field) stated < Check if the value in the field is less than the value (or field) stated = The field must equal the referenced field This notation differs from the "==" notation as the latter represents a validation clause, whereas this notation defines a constraint in itself. -> In combination with "==", this indicates a required constraint, e.g., MM_Type == NON -> SM_Type == NA implies that: SM_Type must equal "NA" if the MM_Type equals "NON" in {value1, value2, } The field value must be one of the listed values within {} M if The source field (left column) is mandatory for the constraint specified last instance of As many files have format specifications having validity dates (from date and to date), this notation points to the last valid row, i.e., the row which has the most recent validity date in the dataset. NULL Format(field) This indicates an absent (or NULL) value in a field a value which is either not set or is missing. This may or may not be a valid state of a field, depending on the field definition and the defined constraint. Indicates that the constraint includes a check on the format used for the field. num(x) Substring(field, x) diff Check if the field value has a particular format or length, where "x" denotes the length in number of numeric characters of the field. Represents a subset of the value as specified in the "field", with a subset value length of "x", e.g., if CusID has the value DDMMYYnnnnn, SubString(CusID,6) has the value DDMMYY. Represents the difference between the values of the two fields.

66 Eksempel RepFreq EACon > kwh -> RepFreq == 60 min EACon Hvis estimert årlig forbruk er større enn kwh, så medfører dette at rapporteringsfrekvens er lik 60 min.

67 Eksempel CusID Format(CusID) == num(11) -> SubString(CusID,6) == Bdate BDate Hvis formatet på kundeid har lengde på 11 tall så medfører dette at de 6 første tallene i kundeid skal være lik bursdagsdato

68 Relasjoner mellom filene

69 Eksempel Fieldname Reference description Ref. to field Actor Filename EACon = last instance of EACon GridOwner MeteringValues Estimert årlig forbruk i nettselskapets målepunktfil skal være lik det estimerte årlige forbruket på målepunktets siste instanse/måleverdi i Nettselskapets måleverdifil.

70 Fieldname Reference description Ref. to field Actor Filename MP_Used = MP_Used GridOwner MeteringPoint Målepunktnummer i målerverdifilen til kraftleverandør må eksistere i målepunktfilen til nettselskapet.

71 Roller og funksjoner - forenklet Markedsprosesser (opphør/oppstart) Oppdatering grunndata kunde Oppdatering grunndata målepunkt Måleverdiinnsamling

72 Roller og funksjoner - testcase Obligatorisk Obligatorisk Obligatorisk Obligatorisk Mottak av Oppstart kraftleveranse lev. plikt Kansellering Mottak av Opphør kraftleveranse lev. plikt Kansellering Mottak masterdata kunde Mottak måleverdier Oppstart Leverandørskifte Innflytting Kansellering Opphør Oppsigelse Utflytting Kansellering NUBIX Oppdatering grunndata kunde Målerstand/årsforbruk Oppstart i målepunkt Innflytting Kansellering Opphør i målepunkt Oppsigelse Kansellering Oppdatering av grunndata MP Svar fra nettselskap Måleverdier Valgfritt Valgfritt Valgfritt Spørring Måleverdier Porteføljeoversikt Avregningsgrunnlag Masterdata Forespørsel til nettselskap Forespørsel til Elhub Spørring Måleverdier Porteføljeoversikt Avregningsgrunnlag Masterdata Forespørsel til Elhub Spørring Måleverdier Forespørsel til Elhub