1. No category

Ekspertgruppemøte Elhub
Migrering og test
Oslo
16. Oktober 2014
Agenda og introduksjon
• Dagens agenda
• Status hjemmelekser
• Valg av pilotaktører
• Pilotenes oppgave høsten 2014
Agenda ekspertgruppemøte 16.10.2014
9:30-9:45
9:45-10:30
10:30-10:45
10:45-11:15
11:15-12:00
Velkommen og introduksjon
• Dagens agenda
• Presentasjon av pilotaktører for migrering
Informasjon fra NVE
• Revidert forskrift 301
Pause
Personvern
• Behov for fødselsnummer
• Status for innføring av fødselsnummer
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
Test
• Fokusområder
Lunsj
12:45-13:00
13:00-14:00
14:00-15:00
15:00-15:30
Gruppe Migrering
Gruppe Test
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
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
Oppsummering og videre arbeid.
• Gjennomgang av kapittel 5 i Elhub Specification of
Migration Files
• Mulige forbedringspunkter i Edielportalen
• Utfordringer knyttet til utvikling og test
• Tema for neste møte
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
Status pilotaktører migrering
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
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
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?
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.
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
Elhub - Forskriftsendringer
■ Viktige temaer i høringen mht.
Elhub
■
■
■
■
■
■
■
■ Høring av forskriftsendringer
■
Personvern (lagringstid,
fødselsnummer)
Rolleendring for nettselskap og
kraftleverandør
Tidspunkt for innføring av NBS
Definisjon av nettselskap
Måling av produksjon
Nøytralitetskrav
Asymmetrisk
avviksoppgjør
Høringsfrist 1. oktober
■ Oppsummering av høringen
pågår
■ Viktig å avklare
problemstillinger knyttet til
personvern før vedtak
Norges vassdrags- og energidirektorat
Forskriftsendringer
■ Leverandørskifter,
■ Overføring av timeverdier innen
anleggsovertagelse
■ Ansvar for beregningsoppgaver
kl. 07.00
■ Kraftleverandør skal presentere
forbruksdata
■ Sikkerhetskrav
■ Nøytralitetskrav
■
Stipulering av timesvis uttak +
estimering
■ Nettap
■ Avregningsdata til
regulerkraftavregning
■ Måleverdier tilgjengelig kl. 0900
■ Lagring av timeverdier og
kundeinformasjon i 3 år i Elhub
■ Avviksoppgjør
■ Standard for behandling av
timeverdier (VEE)
Norges vassdrags- og energidirektorat
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 2015budsjett
■ NVEs rolle
■
■
Pålegg om kvalitetssikring
og testing av datakvalitet
Må gjennomføres innen
gitte frister/milepæler
Norges vassdrags- og energidirektorat
Takk for oppmerksomheten!
Norges vassdrags- og energidirektorat
Statnett SF
Personvern og datasikkerhet
i Elhub migreringsprosesser
Agenda
• Personvern
– Personopplysningsloven
– Kraftmarkedet
• Datasikkerhet ved migrering
– Bakgrunn
– Nå (transisjonsperiode)
– Med Elhub løsning (produksjoninfrastruktur)
Agenda
• Personvern
– Personopplysningsloven
– Kraftmarkedet
• Datasikkerhet ved migrering
– Bakgrunn
– Nå (transisjonsperiode)
– Med Elhub løsning (produksjoninfrastruktur)
Nytt Elhub-dokument:
Identifisering av sluttkunder i kraftmarkedet
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”
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
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
Identitet benyttes
også utenfor
kraftmarkedet
Ja
Ja
Ja
Ja
Ja
Nei
Ja
Ja
Ja
Nei
Nei
Nei
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.
Kraftleverandør
Kraftleveranseavtale
Nettselskap
Måleverdier
Adresse
Nettilknytningsavtale
Navn
og adresse
Måleverdier
Adresse
Målepunkt
Sluttkunde
Måleverdier
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
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
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
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
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
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
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?
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.
Søkelinjer i Elhub informasjonsmodell
Searchable:
Contract parties,
class Information Model Master Data
e.g., Balance
Suppliers
Bitemporal object
Required key:
Security Object
is used for invoicing of
Party reference
Balance Supply Contract
1..*
(current or new)
Required key:
Market parties
(these are always
known)
Searchable:
Grid Access
Provider
must refer to a valid
1
governs balance supply to
Bitemporal object is responsible contact for
Party connected to
1
Grid
0..*
Bitemporal object
Security Object
Grid AccessContract
is governing access to
0..*
points
invoicing to
Domains::
Accounting Point
0..*
use as
contact
1
Multi-Domain Base
Domains::Metering
Point
0..1
May be
connected to
Security Object
Searchable:
Name, date,
customer Id
Searchable:
Address
(invoice and
contact)
Consumer Personal
Data
Multi-Domain Base
references references
Address
Postal address
Searchable:
Metering Point Id,
Metering Grid Area
is located at
Metering Point
address
Searchable:
Metering
Point
address
Required key:
Metering Point Id
(current, or new
and old)
Example search
P.no.: 300367 12345
30.03.67 Ole Olsen
Kanonveien 3, 1234 Oslo
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)
Found
If multiple permutations of relations
(customer, invoice, contact), there may
be multiple instances of Party
connected to Grid.
Consumer Personal Data: 550e8400-e29b-41d4-a716-446655440000
InvoiceAddress_Used: 550e8400-e29b-41d4-a716-446655440100
Party connected to Grid: 550e8400-e29b-41d4-a716-446655440200
InvoiceUsed: 550e8400-e29b-41d4-a716-446655440000
Contact_Used: 550e8400-e29b-41d4-a716-446655440000
Balance Supply Contract: 550e8400-e29b-41d4-a716-446655440300
InvoiceRecipient_Used: 550e8400-e29b-41d4-a716-446655440200
MeteringPoint_Used: 550e8400-e29b-41d4-a716-446655440400
Accounting Point: 550e8400-e29b-41d4-a716-446655440400
MeteringPoint_Used: 707057500054119600
Address_Reference: 550e8400-e29b-41d4-a716-446655440700
Metering Point address: 550e8400-e29b-41d4-a716-446655440700
StreetName:Kanonveien,BuildingNumber:3,PostCode:1234,PlaceName:Oslo
A Party connected to Grid may have
multiple metering points.
Balance Supply Contract: 550e8400-e29b-41d4-a716-446655440301
InvoiceRecipient_Used: 550e8400-e29b-41d4-a716-446655440200
MeteringPoint_Used: 550e8400-e29b-41d4-a716-446655440401
Unique identifier from contract to
accounting point and metering point
address.
Agenda
• Personvern
– Personopplysningsloven
– Kraftmarkedet
• Datasikkerhet ved migrering
– Bakgrunn
– Nå (transisjonsperiode)
– Med Elhub løsning (produksjoninfrastruktur)
Agenda
• Personvern
– Personopplysningsloven
– Kraftmarkedet
• Datasikkerhet ved migrering
– Bakgrunn
– Nå (transisjonsperiode)
– Med Elhub løsning (produksjoninfrastruktur)
Filformat – en liten recap.
• Semikolon separert liste (SDV fil)
• Kodesett UTF-8
• Velkjent og enkelt format
• Mye brukt i migreringsverktøy
• Liten overhead
Hvorfor filer? – mer recap.
Aktører
Sikkerhetssone
Grid owner
DB
DB
SDV
Power supplier
DB
DB
SDV
Other
DB
DB
SDV
Analyse
verktøy
Migrerings
DB
Elhub
DB
Security levels – fra Elhub utlysningsdokumenter
Information level
Authorization level
Information level security model
(cf. role-, market- and information models)
Authorization level security model
(user definitions and role definition)
Authentication level
Authentication level security model
(interface specific authentication methods)
Infrastructure level
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
Infrastructure level security model – fra utlysning
Internet
DMZ/internet
Interface: Web-API
(authorizations)
End users
Interface: Web-API
(metered data)
Extranet
(market party
access)
DMZ
Market
parties
Interface: Portal
(users and parties)
Elhub system
Interface: B2B
Internal
(Elhub) users
Office
zone
Elhub Core zone
Interface: Portal
(users and parties)
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
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
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
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
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?
Datasikkerhet – og datakvalitet
Metering point data
consistency
Single-actor consistency
Data integrity across
multiple actors
Structure data
consistency
• Verify identity of customers
• Verify identity of metering points
(vs. locations, etc.)
• Verify relation between metering
points, customers and location
• Verify metering grid area
consistency (balance within the
MGA)
• Verify metering point status
(production, consumption,
exchange and non-calculated)
• Verify relations between customers
of different actors
• Verify consistent metering point use
and reference
• Verify supply balance within
metering grid areas
• Verify balance across MGAs and
within market balance areas
Ekspertgruppemøte Elhub
Aktiviteter mot bransjen og
eksterne
Oslo
16. Oktober 2014
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
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!
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)
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
Mulighet?
Oppslag i eksterne registre via DAM?
Register
1
Register
2
Migration Files
Aktør
Correction Files
Register
3
DAM
Register
4
Register
5
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 (!)
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?
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
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
Ekspertgruppemøte Elhub
Migrering og test
Oslo
16. oktober 2014
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?
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
Tentativ tidsplan for aktørtest
1/7 2015
1/3 2016
Edielportalen
ferdig utviklet
Elhub systemtest ferdig
1/7 2016
Elhub akseptansetest ferdig
Sertifisering
Systemleverandører
Sertifisering Aktører
Godkjenning Aktører
i Elhub
1/10 2016
Elhub
go-live
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
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  Q2 2015
– Systemtest Elhub  Q4 2015 – Q1 2016
– Akseptansetest/Markedstest Elhub  Q2 2016
– Pilot-test Elhub  Q3 2016
Relasjoner innad og mellom filer
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, …}
M if
last instance of
The field value must be one of the listed values within {}
The source field (left column) is mandatory for the constraint specified
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
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.
Format(field)
Indicates that the constraint includes a check on the format used for the field.
num(x)
Check if the field value has a particular format or length, where "x" denotes the length
in number of numeric characters of the field.
Substring(field, x)
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.
diff
Represents the difference between the values of the two fields.
Eksempel
RepFreq EACon > 100.000 kWh -> RepFreq == 60 min
EACon
Hvis estimert årlig forbruk er større enn 100.000 kWh, så medfører dette
at rapporteringsfrekvens er lik 60 min.
Eksempel
Format(CusID) == num(11) ->
CusID
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
Relasjoner mellom filene
Eksempel
Fieldname Reference description
Ref. to field
Actor
Filename
EACon
EACon
GridOwner
MeteringValues
= last instance of
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.
Fieldname
MP_Used
Reference description
=
Ref. to field
Actor
Filename
MP_Used
GridOwner
MeteringPoint
Målepunktnummer i målerverdifilen til kraftleverandør må eksistere
i målepunktfilen til nettselskapet.
Roller og funksjoner - forenklet
Markedsprosesser
(opphør/oppstart)
Oppdatering
grunndata
kunde
Oppdatering
grunndata
målepunkt
Måleverdiinnsamling
Roller og funksjoner - testcase
Obligatorisk
• Mottak av Oppstart kraftleveranse lev. plikt
• Kansellering
• Mottak av Opphør kraftleveranse lev. plikt
• Kansellering
• Mottak masterdata kunde
• Mottak måleverdier
Obligatorisk
• Oppstart
• Leverandørskifte
• Innflytting
• Kansellering
• Opphør
• Oppsigelse
• Utflytting
• Kansellering
• NUBIX
• Oppdatering grunndata kunde
• Målerstand/årsforbruk
Valgfritt
• Spørring
• Måleverdier
• Porteføljeoversikt
• Avregningsgrunnlag
• Masterdata
• Forespørsel til nettselskap
• Forespørsel til Elhub
Obligatorisk
• Oppstart i målepunkt
• Innflytting
• Kansellering
• Opphør i målepunkt
• Oppsigelse
• Kansellering
• Oppdatering av grunndata MP
• Svar fra nettselskap
Valgfritt
• Spørring
• Måleverdier
• Porteføljeoversikt
• Avregningsgrunnlag
• Masterdata
• Forespørsel til Elhub
Obligatorisk
• Måleverdier
Valgfritt
• Spørring
• Måleverdier
• Forespørsel til Elhub