DataHub - Bilag 3a - Kundens kravspecifikation - Energinet.dk

DataHub 

Bilag 3a – Kundens kravspecifikation 

1.0 Udbudsmateriale til udsendelse d. 5. juli 2010 

01-05-2010 02-07-2010 DATE 

MLM ADA NAME 

REV. DESCRIPTION PREPARED CHECKED REVIEWED APPROVED 

© Energinet.dk 

EU-udbud 2010/S 97-149624 

31785-10 

Doc. no. 

DATE 

NAME

Energinet.dk udbudsmateriale – DataHub 


Vejledning 

Vejledning: 

Bilaget er færdigt, og det er et mindstekrav, at leverandøren ikke foretager ændringer i bilaget 

Dok. 31785/10, Sag 10/3365 2/132



Indholdsfortegnelse 

1. INDLEDNING .............................................................................................6 

1.1 Læsevejledning .....................................................................................................6 

2. INTRODUKTION TIL DATAHUB PROJEKTET ...............................................7 

2.1 Formål .................................................................................................................7 

2.2 Baggrund .............................................................................................................7 

2.2.1 Energinet.dk .....................................................................................................7 

2.2.2 Elmarkedet ..................................................................................................... 10 

3. OVERORDNET BESKRIVELSE....................................................................11 

3.1 Opgavebeskrivelse............................................................................................... 11 

3.2 Projektets scope.................................................................................................. 13 

3.2.1 IT-systemer .................................................................................................... 13 

3.2.2 Interface til aktører og interne it-systemer.......................................................... 14 

3.2.3 Vision............................................................................................................. 16 

3.3 Overblik over forretningsprocesser ........................................................................ 20 

3.4 Bruger- og interessenttyper .................................................................................. 23 

3.4.1 Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og mægler............ 24 

3.4.2 Testbrugere: Markedsaktør og it-leverandør........................................................ 24 

3.4.3 Kunder: Elforbruger og elproducent ................................................................... 24 

3.4.4 Myndigheder ................................................................................................... 24 

3.4.5 Administrator og superbrugere .......................................................................... 25 

3.4.6 Brugere fra Energinet.dk .................................................................................. 25 

3.5 Afhængigheder.................................................................................................... 25 

3.6 Afgrænsninger .................................................................................................... 25 

4. FÆLLES KOMPONENTER OG KRAV ...........................................................26 

4.1 Administration af system ...................................................................................... 26 

4.1.1 Administration af system kravtabel .................................................................... 27 

4.2 Bruger- og rettighedsstyring ................................................................................. 29 

4.2.1 Bruger- og rettighedsstyring kravtabel ............................................................... 29 

4.3 Workflow............................................................................................................ 32 

4.3.1 Workflow kravtabel .......................................................................................... 32 

4.4 Rapportering....................................................................................................... 34 

4.4.1 Rapportering kravtabel ..................................................................................... 34 

4.5 Dataudveksling ................................................................................................... 35 

4.5.1 Dataudveksling kravtabel.................................................................................. 36 

4.6 Alternativ webadgang for kunder........................................................................... 36 

4.6.1 Alternativ webadgang for kunder kravtabel ......................................................... 37 

5. FUNKTIONSKRAV TIL PORTALEN.............................................................38 

Dok. 31785/10, Sag 10/3365 3/132



5.1 Generelle funktionskrav til Portal ........................................................................... 38 

5.1.1 Kravtabel til generelle funktionskrav til Portal...................................................... 40 

5.2 Webformularer.................................................................................................... 45 

5.2.1 Kravtabel til etablering af webformularer ............................................................ 45 

5.2.2 Kravtabel til webformularer............................................................................... 47 

5.3 Krav til DataHub portalen ..................................................................................... 48 

5.4 Krav til Aktørtestsystem portalen .......................................................................... 48 

5.5 Funktionskrav til integration af Selvbetjeningsportalen............................................. 49 

5.5.1 Skærmbilleder – menuoversigt .......................................................................... 51 

5.5.2 Applikation...................................................................................................... 62 

5.5.3 Kravtabel til Selvbetjeningsportalen ................................................................... 64 

6. FUNKTIONSKRAV TIL DATAHUB’EN .........................................................65 

6.1 Understøttelse af forretningsprocesser (BRS) .......................................................... 65 

6.1.1 Forretningsprocesser (BRS) kravtabel................................................................. 65 

6.2 Samlet datamodel ............................................................................................... 69 

6.3 Stamdata ........................................................................................................... 70 

6.3.1 Stamdata, opdateret på baggrund af markedsprocesser ....................................... 70 

6.3.2 Adgang til stamdata via webportal ..................................................................... 73 

6.3.3 Stamdata kravtabel.......................................................................................... 76 

6.4 Måledata ............................................................................................................ 78 

6.4.1 Adgang til måledata via webportal ..................................................................... 78 

6.4.2 Send måledata til tredje part............................................................................. 79 

6.4.3 Måledata kravtabel .......................................................................................... 79 

6.5 Beregningsfunktion.............................................................................................. 81 

6.5.1 Statiske beregninger ........................................................................................ 81 

6.5.2 Dynamiske beregninger.................................................................................... 83 

6.5.3 Automatisk beregning - nettoafregnede værker ................................................... 83 

6.5.4 Beregningsfunktion kravtabel ............................................................................ 84 

6.6 Beregning af residualforbrug, andelstal, fordelte forbrug og saldoafregning ................ 84 

6.6.1 Beregning af residualforbrug, andelstal, fordelte forbrug & saldoafr. kravtabel ........ 86 

6.7 Forberedelse til Samfakturering............................................................................. 87 

6.7.1 Samfakturering kravtabel ................................................................................. 88 

6.8 Kvalitetsindeks (KPI) på måledata ......................................................................... 88 

6.8.1 Beregning af KPI'en "IFIM"................................................................................ 89 

6.8.2 KPI på måledata kravtabel ................................................................................ 91 

6.9 Dataudtræk via webservice................................................................................... 91 

6.9.1 Dataudtræk kravtabel ...................................................................................... 92 

6.10 Rapportering....................................................................................................... 92 

6.10.1 Rapportering kravtabel ................................................................................. 93 

7. FUNKTIONSKRAV TIL AKTØRTESTSYSTEMET...........................................95 

7.1 Aktørtestsystemets formål.................................................................................... 95 

7.1.1 Overordnet formål med Aktørtestsystemet.......................................................... 95 

7.1.2 Brugertyper til Aktørtestsystemet ...................................................................... 96 

7.1.3 Testtyper........................................................................................................ 96 

7.2 Overordnede rammer for Aktørtestsystemet ........................................................... 98 

7.2.1 Model for Aktørtestsystemet.............................................................................. 98 

7.2.2 Overordnet testflow ......................................................................................... 99 

Dok. 31785/10, Sag 10/3365 4/132



7.2.3 Overordnede krav .......................................................................................... 100 

7.3 Funktionelle krav............................................................................................... 102 

7.3.1 Registrering af it-system kravtabel .................................................................. 102 

7.3.2 Administration af testcases ............................................................................. 103 

7.3.3 Administration af testcases kravtabel ............................................................... 106 

7.3.4 Administration af testdata............................................................................... 108 

7.3.5 Administration af testdata kravtabel................................................................. 108 

7.3.6 Administration af testforløb............................................................................. 110 

7.3.7 Administration af testforløb kravtabel............................................................... 111 

7.3.8 Godkendelse af testforløb ............................................................................... 113 

7.3.9 Godkendelse af testforløb kravtabel ................................................................. 113 

7.3.10 Historik for testforløb.................................................................................. 114 

7.3.11 Historik for testforløb kravtabel.................................................................... 116 

8. IKKE-FUNKTIONELLE KRAV TIL ARKITEKTUR........................................119 

8.1 Generelle arkitekturkrav..................................................................................... 119 

8.1.1 Generelle arkitekturkrav kravtabel ................................................................... 121 

8.2 Platform og kommunikation ................................................................................ 122 

8.2.1 Platform og kommunikation kravtabel .............................................................. 123 

8.3 Integrationer .................................................................................................... 124 

8.3.1 Eksterne integrationer .................................................................................... 125 

8.3.2 Integrationer kravtabel................................................................................... 126 

9. ØVRIGE IKKE-FUNKTIONELLE KRAV......................................................127 

9.1 Sikkerhed......................................................................................................... 127 

9.1.1 Transaktionsspor og revisionsspor ................................................................... 127 

9.1.2 Sikkerhed kravtabel ....................................................................................... 127 

9.2 Implementering og datamigrering ....................................................................... 128 

9.3 Uddannelse....................................................................................................... 129 

9.4 Drift................................................................................................................. 130 

10. TABEL- OG FIGUROVERSIGT ..............................................................131 

Dok. 31785/10, Sag 10/3365 5/132



1. Indledning 

1.1 Læsevejledning 

I dette bilag, som indeholder kravspecifikationen, gøres der opmærksom på flg.: 

• Ved referencer til forskrift, menes der de "foreløbige" forskrifter, benævnt pseudoforskrifter 

i kravspecifikationen 

• Hvis ikke andet specifikt er nævnt, gælder kravene både for DataHub'en, Aktørtestsystemet 

og Portalen. 

• Hvert afsnit afsluttes med en opsummering af kravene i en kravtabel. 

Nedenstående illustration viser opbygningen af denne kravspecifikation. 

Specifikationen består af tre afsnit, der er fælles for DataHub'en og Aktørtestsystemet. Herudover 

er to specifikke afsnit, der beskriver de specifikke krav for de to hovedsystemer. 


Forretningsprocesser 

Stamdata 

Beregningsfunktioner 

Portal 

Samfakturering 

Rapportering 

Måledata 

Dataudtræk 

Specifikke afregninger 

Kvalitetsindeks (KPI) 

Aktørtestsystem 

Registrering af system 

Fælles komponenter 

Systemadministration Rapportering 

og krav Brugeradministration Workflowadministration 

Testcases 

Testdata Testforløb 

Testgodkendelse 

Testhistorik 

Design & tilgængelighed Webformularer Selvbetjeningsportal 

Dataudveksling 

Ikke-funktionelle 

Arkitekturkrav Kommunikation 

Platform 

krav Integrationer 

Sikkerhed 

Datamigrering 

Figur 1-1: Opbygning af kravspecifikationen 

Dok. 31785/10, Sag 10/3365 6/132



2. Introduktion til DataHub projektet 

2.1 Formål 

Energinet.dk er af Klima- og Energiministeren blevet bedt om at etablere en DataHub til det danske 

elmarked. I sommeren 2009 startede Energinet.dk på den baggrund projektet i samarbejde 

med repræsentativt udvalgte aktører fra det danske elmarked. 

DataHub'en skal være en Business-to-Business (B2B) løsning (datatrafikalt knudepunkt), som 

administrerer transaktioner og kommunikation mellem alle elmarkedets aktører i Danmark: 

Netvirksomheder, elleverandører, balanceansvarlige og Energinet.dk. Dette betyder, at aktørerne 

skal kommunikere med DataHub'en på en standardiseret måde, og aktørerne ikke længere 

skal udveksle data bilateralt, som det sker i dag. 

DataHub'en skal indeholde alle nødvendige data til markedsafregning og tilbudsgivning, som aktørerne 

har behov for. 

I tillæg til B2B løsningen, skal kunderne (elforbrugerne) tilbydes adgang til at se egne data 

(stamdata og elforbrug) vha. sikker adgang på en webportal. DataHub'en skal ikke stille en webportal 

til rådighed til dette, men skal i stedet tilbyde lettilgængelige webapplikationer, der kan 

tilgås fra elleverandørernes webportaler. 

Kunden skal således kunne logge på sin elleverandørs webportal med NemID og elleverandøren 

skal ved kald af DataHub'ens webapplikationer vise forbrugerens egne data fra DataHub'en i elleverandørens 

portal. Autentifikation sker via NemID. 

Endvidere skal legitime interessenter gives adgang til dataudtræk fra DataHub'en til samfundsnyttige 

formål. 

2.2 Baggrund 

2.2.1 Energinet.dk 

2.2.1.1 Mission 

Som ansvarlig for el- og naturgassystemerne ejer vi den overordnede infrastruktur, sørger for en 

sikker energiforsyning og skaber rammerne for velfungerende energimarkeder og effektiv indpasning 

af vedvarende energi. 

2.2.1.2 Vision 

Gennem internationale og fortrinsvise markedsbaserede løsninger vil vi muliggøre øget anvendelse 

af vedvarende energi og bidrage til håndtering af de globale energi- og klimaudfordringer. 

2.2.1.3 Fakta om Energinet.dk 

• Selvstændig, offentlig virksomhed under Klima- og Energiministeriet 

• Egen bestyrelse 

Dok. 31785/10, Sag 10/3365 7/132



• Etableret på baggrund af Lov om Energinet.dk Danmark af 14. december 2004 

• Fusion mellem Elkraft, Eltra og Gastra i 2005 

• Ca. 500 medarbejdere, hovedparten i Erritsø og Ballerup 

• Ejer og driver energiens motorveje 

o Det overordnede el- og naturgasnet 

o Det regionale elnet i Nordsjælland 

• Ejer og driver Gaslageret i Lille Torup mellem Viborg og Års 

• Medejer af den nordiske elbørs, Nord Pool Spot 

• Medejer af den danske gasbørs, Nord Pool Gas 

• Medejer af European Market Coupling Company 

• Årlig omsætning på 8-9 mia. kr. 

• Forbrugerne betaler til vores aktiviteter via tariffer på el- og gasregningen 

2.2.1.4 Energinet.dk's kerneopgaver 

• Vores økonomi skal hvile i sig selv, dvs. vi skal ikke skabe overskud 

• Vi har ansvaret for den overordnede forsyningssikkerhed på el- og gasområdet på både 

kort og lang sigt 

• Vi planlægger og udbygger det danske el- og gassystem 

• Vi sikrer velfungerende konkurrence på markederne for el og gas 

• Vi støtter produktion af miljøvenlig strøm 

• Vi støtter forskning, udvikling og demonstration af nye teknologier til miljøvenlig elproduktion 

• Vi opgør udledningen af stoffer til miljøet fra det samlede energisystem 

• Vi sikrer, at energisektorens beredskab er velfungerende 

• Vi sikrer: 

o at der altid er strøm i stikkontakterne og gas i hanerne 

o den nødvendige udbygning af el- og gasnettet 

o forsyningen af gas, når produktionen i Nordsøen klinger af 

o at strømmen føres i land fra nye havvindmølleparker 

• Vi udvikler et mere fleksibelt elsystem, der kan håndtere markant mere vedvarende 

energi 

Dok. 31785/10, Sag 10/3365 8/132



• Vi sikrer velfungerende markeder for el og gas – konkurrence og gennemsigtige priser 

• Vi yder tilskud til miljøvenlig el- og kraftvarmeproduktion 

2.2.1.5 Energinet.dk's interne værdier 

Værdierne fortæller, hvordan vi vil arbejde for at nå vores mål. 

Vores værdier udtrykker, hvad der kendetegner os, og hvad vi kan forvente af hinanden. Dermed 

lægger de også fast, hvad vores omverden kan forvente af os. Værdierne er et kompas, der 

udstikker retningen for alt, hvad vi gør. 

I løbet af 2009 er vi sammen nået frem til et værdisæt, som vi udfolder efter bedste evne: 

Udvikling 

• Vi skaber forandring og nye løsninger. Vi har plads til nye idéer, personlig og faglig udvikling 

Engagement 

• Vi tager ansvar, er opsøgende og vi motiverer hinanden 

Forretningsorientering 

• Vi er økonomiske ansvarlige, er effektive og er opmærksomme på behov og muligheder 

i vores omverden 

Ansvarlighed 

• Vi gør det, vi siger. Vi tager opgave, samfund og miljø alvorligt og vi behandler hinanden 

og andre med respekt 

Dok. 31785/10, Sag 10/3365 9/132



2.2.2 Elmarkedet 

Engrosmarked 

Detailmarked 

Nord Pool 

Elleverandør 

Balanceansvarlig 

Systemansvarlig 

Elleverandør 


Elleverandør 

Netvirksomhed Netvirksomhed Netvirksomhed 

Figur 2-1: Illustrerer principperne for elmarkedet og viser de aktører, der agerer i markedet. 

Danmark er opdelt i ca. 85 geografiske netområder, og hvert netområde ejes af en netvirksomhed. 

Netvirksomhederne har ansvaret for at drive og udbygge ledningsnettene, foretage alle målinger 

hos forbrugere og producenter i netområdet samt at videreformidle målinger til relevante 

aktører. 

Elforbrugeren er fysisk tilsluttet nettet hos den netvirksomhed, hvor forbrugeren geografisk er 

placeret, og elforbrugeren kan indgå aftale om køb af el med en af de ca. 100 elleverandører der 

agerer i Danmark. Elforbrugeren kan altså vælge at skifte elleverandør, men kan ikke skifte 

netvirksomhed. 

Elleverandørerne handler deres energi med de balanceansvarlige på engrosmarkedet. Der er pt. 

ca. 50 balanceansvarlige i Danmark. De balanceansvarlige køber og sælger el i engrosmarkedet, 

f.eks. fra den nordiske elbørs Nord Pool. 

De balanceansvarlige indmelder dagligt deres handelsplaner på timebasis til den systemansvarlige 

(Energinet.dk), der har det overordnede ansvar for at sikre den fysiske energibalance i elmarkedet 

(forbrug = produktion), og derudover har ansvaret for et velfungerende elmarked. 

En mere detaljeret beskrivelse af elmarkedet kan bl.a. ses i "Forskrift A: Principper for elmarkedet" 

der kan findes på Energinet.dk's hjemmeside. 

Dok. 31785/10, Sag 10/3365 10/132



3. Overordnet beskrivelse 

DataHub projektet er organisatorisk forankret i Markedsafdelingen i Energinet.dk. 

Til projektet er der oprettet projektkontor med dedikeret projektleder og projektkoordinator. Der 

vil i projektet være tilknyttet tilstrækkelige ressourcer fra relevante sektioner i Energinet.dk (Elmarked, 

it, jura osv.). (se Bilag 10). 

3.1 Opgavebeskrivelse 

Følgende 2 dokumenter beskriver det omfang for DataHub projektet, der er aftalt med Energistyrelsen: 

11. juni 2009 Energinet.dk 

3. november 2009 Energinet.dk 

"Referencemodel for implementering af et centralt markeds register i det danske elmarked" 

"Uldne punkter i referencemodellen" 

Nedenstående dokumenter danner desuden baggrund for DataHub projektet: 

21. april 2009 Energistyrelsen: 

24. april 2009 Connie Hedegaard 

"STAMDATAREGISTER OG DATAHUB til håndtering af måledata i det danske elmarked" 

"L 3 – betænkningsbidrag med henblik på etableringen af en DataHub i elmarkedet" 

30. april 2009 Det Energipolitiske udvalg 

Maj 2009 NordREG 

Februar 2008 NordREG 

"Det Energipolitiske Udvalg L 3 - Bilag 27" 

"Market Design Common Nordic end-user market" - Report 03/2009 

"Harmonized supplier switching model" - Report 2/2008 

Dokumenterne er tilgængelige på www.datahub.dk. 

Introduktionen af en DataHub i elmarkedet, betyder at de gældende markedsforskrifter for elmarkedet 

skal revideres. Markedsforskrifterne er et regelsæt udarbejdet af Energinet.dk, der 

efter høring af markedets aktører, er anmeldt til Energitilsynet i overensstemmelse med loven. 

De definerer, hvorledes alle aktører i elmarkedet skal agere i forhold til hinanden, og hvilke roller 

de har. De gældende markedsforskrifter kan findes på www.Energinet.dk. 

Dok. 31785/10, Sag 10/3365 11/132



Referencedokument 

af juni 2009 

krav til funktionalitet 

og arbejdsdeling i 

branchen 

EU’s liberaliseringspakke 

-eldirektivet 

-forordning om netadgang 

Energitilsynet 

NordREG 

Harmonized Supplier 

Switching Model, 

NordREG 

Report 2, 2008 

Marked Design 

Rapport 3, 2009 

Figur 3-1: Centrale dokumenter 

”Uldne” punkter i 

referencedokument 

krav til samfakturering 

Markedsforskrifter 

D1, F, H1, H2 

- incl: BRS’er og RSM’er 


i det danske elmarked 

”Ønskeliste” 

Ændringsønsker fra aktørene 


- Kravspecifikation 

• Alle måledata 

• Stamdata alle kunder 

• Leverandørskift 

• Saldoafregning 

• Formidle data til samfakturering 

• kundeadgang via www 

Aktørtest 

- Kravspecifikation 

• Ny kommunikationsstandard 

Aktørsystemer 

- Ændringsspecifikation 

• Ny kommunikationsstandard 

• Ændrede processer 

Figur 3-1 illustrerer hvorledes de ovenstående dokumenter giver input til udarbejdelsen af nye 

markedsforskrifter. Udover de nævnte dokumenter, er der input til projektet fra EU Kommisionen 

("3. Liberaliseringspakke") og fra Energitilsynet. Der har fra elmarkedets aktører været ønsker 

om ændringer af uhensigtsmæssigheder i de gældende regler.("Ønskeliste") 

Ultimo juni 2010 er de nye pseudoforskrifter blevet fastlagt, og "Forretningsprocesser for det 

danske elmarked", der beskriver dataudvekslingen mellem markedets aktører er ligeledes fastlagt 

i en foreløbig version. Pseudo-forskrifterne er ikke godkendte af Energitilsynet endnu, men 

lægges til grund for dette udbudsmateriale. 

På baggrund af de nye markedsforskrifter og beskrivelse af forretningsprocesserne udarbejdes 

der kravspecifikationer til de it-systemer, der skal varetage EDI-kommunikationen i elmarkedet - 

herunder DataHub'en og Aktørtestsystemet, som dette udbud omhandler. 

Aktørerne i markedet skal sideløbende specificere de ændringer, der skal foretages i deres lokale 

it-systemer (Aktørsystemer) 

Dok. 31785/10, Sag 10/3365 12/132



3.2 Projektets scope 

I nedenstående figur 3.2 er projektets omfang illustreret grafisk. 

Kunder 

På elleverandørens 

hjemmeside: 

- se egne målinger 

- se egne stamdata 

- se leverandørskifte 

-konfigurer system 

-administration 

-overvågning 

-fejlsøgning 

Elleverandør 

- modtage målinger 

- forespørge stamdata 

- foretage leverandørskifte 

Mægler 

- forespørge målinger 

- forespørge stamdata 

Webservices 

-indsende målinger 

-vedligeholde stamdata for målepunkter 

-forespørge status på målinger og stamdata 


Målepunkt 

-aftagenummer 

-adresse 

-elleverandør 

-balanceansvarlig 

-kundenavn 

-gyldighedsperiode 

Netvirksomhed 

Målinger 

-tid (periode) 

-værdi 

-status 

Webportal 

Funktioner: 

-Beregninger 

-Saldoafregning 

-Revisionsspor 

-Statistik 

Figur 3-2: Illustration af DataHub'ens interessenter og funktioner. 

3.2.1 IT-systemer 


- modtage målinger 


-måledata 

- se statistikdata 

Offentlig 

Myndigheder 

- hent foruddefinerede data 

Selvbetjeningsportal 

(eksisterende IT-system) 

PandaService 


Webservices til Webportal 

Panda 


Afregning på engrosmarkedet: 

-balanceafregning 

-afgiftsafregning 

-udbetaling af pristillæg 

DataHub'ens samlede leverance består af 2 systemer: DataHub'en og Aktørtestsystemet - og de 

betragtes i dette udbud som 2 separate leverancer. 

3.2.1.1 DataHub – kapitel 6 

• DataHub'en skal lagre stamdata for alle målepunkter i Danmark, bl.a. adresseinformation, 

navn på disponent (kunde), elleverandør og netvirksomhed. Disse stamdata er variable 

over tid. 

• For hvert målepunkt skal der registreres målinger (forbrug, produktion eller udveksling). 

Disse målinger kan være foretaget på kvarters-, times-, måneds-, kvartals eller 

årsbasis. 

• DataHub'en vil være en kombineret informations- og transaktionsportal, som dels skal 

rumme aktuelle og historiske forbrugs- og produktionsdata (målinger), og dels skal 

håndtere processen for leverandørskifte og flytning (stamdata). 

• Målet er en specialbygget eller specialtilpasset applikation opbygget af standardmoduler. 

Dok. 31785/10, Sag 10/3365 13/132



• Arkitekturen er lagopdelt (præsentation, logik og data). 

• Slutbrugergrænsefladen skal primært være webbaseret. 

• Systemet skal håndtere store datamængder (målinger) fra ca. 3,2 mio. målepunkter. 

• Systemet skal håndtere store transaktionsmængder, dagligt modtages 1,2 mio. timemålinger, 

og der forventes ca. 0,5 mio. stamdataændringer pr. år (f.eks. flytninger eller 

skift af elleverandør). 

• Systemet vil indeholde personfølsomme oplysninger, hvilket stiller krav til sikkerhedsniveauet. 

• Der skal være integrationer til andre systemer hos Energinet.dk. 

• Systemet vil blive omdrejningspunkt for markedskommunikationen, hvorfor der er krav 

om høj oppetid. 

3.2.1.2 Aktørtestsystem - kapitel 7 

• Til test og verifikation af it-kommunikationen fra markedets aktører, skal der udvikles et 

Aktørtestsystem, hvor aktørerne gennemfører specificerede test-cases. 

• Slutbrugergrænsefladen på Aktørtestsystemet skal være webbaseret. 

• Testscenarierne skal kunne afvikles individuelt af aktørerne og deres it-leverandører, 

med mindst mulig involvering fra Energinet.dk's side. 

• Aktørtestsystemet skal efterfølgende fungere som en service på markedet ved: 

o test af nye releases 

o nye systemer for eksisterende aktører 

o test af nye aktørers systemer. 

3.2.1.3 Webportal – kapitel 5 

• Da slutbrugergrænsefladen på både DataHub'en og Aktørtestsystemet skal være webbaseret, 

ses der en fordel i en løsning, der anvender samme webportal. 

• Webportalen skal give brugerne en oplevelse af et sammenhængende system. 

Energinet.dk's eksisterende portalløsning ("Selvbetjeningsportal") kan tænkes integreret i denne 

webportal. Den omtalte integration vil kun gælde for elkunder, altså vil Selvbetjeningsportalen 

fortsætte med servicering af gaskunder. Denne eventuelle integration er i dette udbudsmateriale 

beskrevet som en option. 

3.2.2 Interface til aktører og interne it-systemer 

3.2.2.1 Netvirksomheder 

Det er netvirksomhedernes ansvar at vedligeholde stamdata for målepunkter, på nær oplysningen 

om elleverandør og balanceansvarlig. Det er også netvirksomhedernes ansvar at indmelde 

målinger pr. målepunkt og eventuelle korrektioner til disse målinger. 

Dok. 31785/10, Sag 10/3365 14/132



Den primære kommunikation mellem netvirksomhederne og DataHub'en skal ske via EDIudveksling 

(webservice), men DataHub'en skal tilbyde adgang via en webportal, således at 

netvirksomhederne kan udføre forretningstransaktioner og kontrolfunktioner i DataHub'en. 

3.2.2.2 Elleverandører 

Når en elleverandør overtager en kunde på et målepunkt, er det elleverandørens ansvar at 

ajourføre "elleverandør" oplysningen på målepunktet. Elleverandøren har ret til de målinger, der 

er foretaget på de målepunkter, hvor elleverandøren har kunder. 

Den primære kommunikation mellem elleverandørerne og DataHub'en sker via EDI-udveksling, 

men DataHub'en skal tilbyde adgang via en webportal, således at elleverandørerne f.eks. kan 

hente måledata og stamdata samt udføre kontrolfunktioner i DataHub'en. 

3.2.2.3 Mægler 

En mægler har samme muligheder som en elleverandør for at forespørge på kundestamdata og 

historiske målinger for kunder. Mægleren kan ikke udføre opdaterende forretningstransaktioner 

som f.eks. skift af elleverandør, eller ændring af stamdata. 

3.2.2.4 Balanceansvarlige 

Den balanceansvarlige er aktøren i engrosmarkedet, der handler el med elleverandørerne (detailmarkedet). 

De balanceansvarlige aktører skal modtage målinger pr. elleverandør fra Data- 

Hub'en. 

Den primære kommunikation mellem balanceansvarlige og DataHub'en sker via EDI-udveksling, 

men DataHub'en skal tilbyde adgang via en webportal, således at den balanceansvarlige f.eks. 

kan hente måledata og stamdata samt udføre kontrolfunktioner i DataHub'en. 

3.2.2.5 Kunde, offentlighed og myndigheder 

Alle elkunder i Danmark skal ved indlogning på deres elleverandørs webportal kunne se registrerede 

stamdata og registreret forbrug på egne målepunkter samt oplysninger om eventuelle registrerede 

leverandørskift på målepunktet. Disse oplysninger skal stilles til rådighed for elleverandøren 

fra DataHub'en som webapplikationer. Det er et krav til elleverandørerne, at indlogningen 

på deres portal sker ved "NemID". 

Myndigheder skal via webportalen kunne hente foruddefinerede dataudtræk, og uden indlogning 

(offentlighed) skal webportalen vise diverse statistikdata for elmarkedet. 

3.2.2.6 Energinet.dk 

DataHub'en administreres af Energinet.dk. Der skal kunne udføres systemkonfigureringer, overvågning 

af systemet, administration af brugere/rettigheder samt fejlsøgninger i processer. 

Energinet.dk skal desuden kunne foretage diverse rapporteringer via standardværktøjer, evt. 

ved integration med Energinet.dk's eksisterende Datawarehouse løsning. 

Dok. 31785/10, Sag 10/3365 15/132



3.2.2.7 Panda, PandaService og Selvbetjeningsportal 

Panda er et eksisterende it-system hos Energinet.dk. Panda udfører afregningen i engrosmarkedet 

primært på basis af målinger der fremover modtages fra DataHub'en. 

På basis af det beregnede forbrug pr. netområde beregner Panda de net- , system- og PSOafgifter 

der skal opkræves hos netvirksomhederne. 

Alle produktionsanlæg i Danmark (værker og vindmøller) er registreret med relevante stamdata i 

Panda, og i Panda beregnes hver måned det pristillæg, der skal udbetales til ejerne af produktionsanlæggene. 

Alle afregningsbilag og stamdata for produktionsanlæg fra Panda gøres tilgængelige på Energinet.dk's 

Selvbetjeningsportal, hvor der pt. er registreret ca. 4300 brugere. Da brugerne af Data- 

Hub'en også vil være brugere af den eksisterende Selvbetjeningsportal, er der i dette udbudsmateriale 

en option om integration af Selvbetjeningsportalen ind i DataHub portalen. Den omtalte 

integration vil kun gælde for elkunder, altså vil Selvbetjeningsportalen fortsætte med servicering 

af gaskunder. 

3.2.3 Vision 

På sigt forventes DataHub'en at skulle udbygges med yderligere funktionalitet, hvoraf nogle emner 

kan nævnes: 

3.2.3.1 Elbiler 

Det forventes, at der i forbindelse med udbredelse af elbiler i Danmark vil blive etableret offentlige 

ladestandere til elbiler. DataHub'en kan her få en central rolle mht. håndtering af målinger/afregninger 

fra disse ladestandere. 

Figur 3-3 illustrerer et eksempel på et design, hvor DataHub'en modtager detailregistreringer fra 

de offentlige ladestandere, evt. via netvirksomheden. På baggrund heraf kan forbruget opgøres 

pr. kort (=virtuelt målepunkt), pr. kunde og pr. elleverandør. 

Dok. 31785/10, Sag 10/3365 16/132



Model for håndtering af elbiler, der lader ved 

offentlige ladestanderne 

ELLEVERANDØR 

Oprettelse af målepunkt 

3 

4 

Målepunkt sendes 

18 

Fakturalinjer 

17 

15 

Tidsserier pr. målepkt. 

BALANCEANSVARLIG 

16 

Tidsserier pr. 

elleverandør 

14 

2 Aftale 

Tidsserier pr. målepkt. 

Fakturalinjer pr. målepkt. 

Samlet faktura 19 

6 

Bestilling af reg. 

kraft /SPOT 

Levering af reg. 

kraft /SPOT 

10 

7 Målepunkt id er aktiv 

OPERATØR 

Validering af målepunkt id 

12 

NETVIRKSOMHED 

13 

Styring 

Identificering af målepunkt id 

9 

8 

Hjemtagning af timeværdier 

1 Aftale 

Ladestanderens eget forbrug 

Figur 3-3: Model for elbiler der lader ved offentlige ladestandere 

3.2.3.2 Nordisk detailmarked 

11 

Samlet faktura 20 

3 7 9 

kWh 

OFF. LADESTANDER 

Dok. 31785/10, Sag 10/3365 17/132 

5 

KUNDE 

Elbilen lader ved 

ladestanderen 

Ladestander 

identificerer 

målepunkt 

Oprettelse af kunden 

Opladning af elbil 

Styring 

Afregning af kunden 

Integrationen mellem det danske elmarked og det øvrige Norden står overfor en række store 

udfordringer. Det skyldes de nordiske energiministres beslutning om at danne et fælles nordisk 

slutbrugermarked i 2015. 

Elbranchens forskellige interessenter er allerede i nordisk sammenhæng gået sammen i et projekt 

for at forberede indførelsen af dette fælles detailmarked. Projektet koordineres af NordREG 1 . 

Der er nedsat fire task forces (TF) som skal fremkomme med løsningsforslag til realiseringen af 

det fælles slutbrugermarked. De fire TF’s omhandler følgende 

• Target market model TF (formandskab: NordREG) 

• Balance and settlement TF (formandskab: Nordiske TSO’er) 

• Data exchange TF 2 (formandskab: Nordenergi) 

• Customer interface model TF (formandskab: Nordenergi). 

1 Forum of Nordic Energy Regulators. 

2 Collaboration between the Nordic electricity industry associations



Den endelige afrapportering til EMG 3 fra de fire TF’s skal finde sted til september 2010. 

Det forekommer på nuværende tidspunkt svært at prognosticere, hvilke forhold som opnår første 

prioritet, og hvilke forhold som prioriteres som mindre væsentlige. Det skyldes, at processen 

først er ved at starte op nu. Der er dog ingen tvivl om, at alle interessenter skal udvise særdeles 

stor fleksibilitet, hvis energiministrenes ønsker skal kunne tilgodeses allerede i 2015. 

Der er en række punkter, som antages at indgå i de videre overvejelser: 

Det skal være sikkert og nemt for forbrugerne at købe elektricitet fra enhver nordisk leverandør. 

Det samme gælder leverandørernes adgang til at være aktiv på hele det nordiske 

marked. 

Harmoniseringen af slutbrugemarkedet skal ske på en omkostningseffektiv måde. 

Der skal være et incitament til at markedets aktører leverer en høj kvalitet ved udveksling af 

data og meddelelser. 

Markedsreglerne skal kunne administreres, og være klare, transparente og samtidig robuste 

overfor fremtidige tiltag. 

Forventningerne til designet af det nordiske detailmarked er, at en dansk elleverandør kun skal 

kommunikere med den danske DataHub, men kan agere i markedet i de øvrige tilknyttede lande. 

Det forventes således at være de nationale DataHub's, der skal kommunikere på tværs af 

grænserne. 

3.2.3.3 Samfakturering 

I dag modtager elkunder, der har skiftet elleverandør, både en faktura fra sin netvirksomhed og 

fra sin elleverandør. Her kan DataHub'en få en rolle mht. udveksling af bl.a. fakturaoplysninger, 

således at der udsendes en samlet faktura fra elleverandøren til kunden. 

DataHub'en skal være forberedt til samfakturering (beskrevet i afsnit 6.7) men dette område 

kan forventes at blive udvidet med flere funktionaliteter. 

3.2.3.4 Afregning i engrosmarkedet 

Afregningerne for engrosmarkedet, der i dag foretages i Panda systemet, forventes med fordel 

at ville kunne integreres i DataHub'en. 

3 Electricity Market Group (EMG) of Nordic Council of Ministers 

Dok. 31785/10, Sag 10/3365 18/132




Energistyrelsen 

Stamdataregisteret 

Figur 3-4: Panda 

Hent afregningsbilag 

Stamdata prod.anlæg 

Afregningsbilag 


Panda 

Netvirksomhed 


Stamdata produktionsanlæg 


Stamdata prod.anlæg 


Afregning på engrosmarkedet: 

-balanceafregning 

-afgiftsafregning 

-udbetaling af pristillæg 

Målinger 


Vedligehold stamdata 

Posteringer pr. kunde 


Udbetaling af pristillæg 

SAP 

Bogføring 

Anlægsejer 

NemKonto 

Faktura: 

- Balanceafregning 

- Afgiftsafregning 

Som illustreret i figur 3-4 vil Panda modtage målinger fra DataHub'en, og på basis af disse foretage 

følgende tre typer afregninger: 

Balanceafregning: 

På timeniveau beregnes differencen mellem de planlagte produktioner/forbrug og målingerne for 

hver balanceansvarlige, og denne differens (ubalance) prissættes til afregning overfor den balanceansvarlige. 

Afgiftsafregning: 

For hvert netområde beregnes netområdets forbrug på basis af forbrugs-, produktions- og ud- 

vekslingsmålingerne. På basis af det opgjorte forbrug opkræves hvert netområde med tre typer 

afgifter: Systemtarif, Nettarif og PSO-tarif. 

Udbetaling af pristillæg: 

Vindmøller og øvrige el-produktionsanlæg kan være berettiget til at modtage et pristillæg til deres 

produktion. Disse pristillæg beregnes i Panda pr. produktionsanlæg, og udbetalingen foreta- 

ges til anlægsejerne. 

Som illustreret i figur 3-4 foretages de ovenstående tre typer afregninger i Panda, og der dannes 

detaljerede afregningsbilag (pdf-filer), som er tilgængelige for kunderne via Selvbetjeningsportalen. 

Dok. 31785/10, Sag 10/3365 19/132



Panda foretager den egentlige beløbsberegning for alle afregningerne, og posteringerne pr. kunde 

overføres til SAP. Fra SAP udskrives faktura til de balanceansvarlige og netvirksomhederne, 

og udbetalingen af pristillæg til produktionsanlægsejerne sker via NemKonto. 

Stamdata for produktionsanlæg: 

Energinet.dk er pålagt en opgave fra Energistyrelsen om varetagelse af "stamdataregister for 

produktionsanlæg", og denne opgave varetages også af Panda-systemet. Netvirksomhederne 

skal via Selvbetjeningsportalen indberette og vedligeholde stamdata for alle produktionsanlæg i 

Danmark. Disse stamdata valideres i Panda og indberettes på månedsbasis til Energistyrelsen 

sammen med produktions- og afregningsdata. 

3.2.3.5 Vision kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 

Kravtitel Kravbeskrivelse 

03-01 K Beskrivelse af forberedelse til op- 

Tabel 3-1: Vision kravtabel 

fyldelse af visioner 

3.3 Overblik over forretningsprocesser 

Det skal beskrives, hvorledes det leverede sy- 

stem vil kunne opfylde de udvidelser som beskrevet 

i visioner afsnit 3.2.3 

Markedsforskrifterne beskriver de grundlæggende forretningsregler. Reglerne fra forskrifterne er 

nedbrudt i enkelte forretningsprocesser, kaldet BRS - Business Requirement Specification og EDI 

transaktionerne i de enkelte forretningsprocesser er beskrevet i RSM dokumentationen (Requirement 

Specification Mapping). 

Markedsforskrift 

Markedsregler 


for det 

danske elmarked 

BRS – 

Business 

Requirement 

Specification 

EDI-Transaktioner 

RSM – 

Requirement 

Specification 

Mapping 

DataHub'en skal overholde alle regler beskrevet i Markedsforskrifter og "Forretningsprocesser for 

det danske elmarked", og ved evt. uoverensstemmelse mellem dokumenterne er Markedsforskrifterne 

de gældende dokumenter. 

Det skal bemærkes, at der i forbindelse med DataHub projektet er udarbejdet nye forskrifter, 

kaldet pseudo-forskrifter. Pseudo-forskrifterne er endnu ikke godkendt af Energitilsynet, men 

lægges til grund for dette udbud. 

Dok. 31785/10, Sag 10/3365 20/132



Nedenstående tabel viser alle markedsforskrifter for elmarkedet og deres relevans for dette projekt. 

Markedsforskrift Relevans 

A Principper for elmarkedet Ikke relevant for DataHub'en - men definerer flere 

grundlægende principper i elmarkedet. 

B Vilkår for adgang til elmarkedet Ikke relevant for DataHub'en 

C1 Vilkår for balanceansvar Ikke relevant for DataHub'en 

C2 Balancemarkedet og balanceafregning Ikke relevant for DataHub'en 

C3 Planhåndtering - daglige procedurer Ikke relevant for DataHub'en 

D1 Pseudo-forskrift: Afregningsmåling Er revideret kraftig aht. DataHub projektet, og er 

vedlagt udbudsmaterialet i revideret udgave. Den 

reviderede udgave er ikke officielt gældende i markedet. 

D2 Tekniske krav til elmåling Ikke relevant for DataHub'en 

E Miljøvenlig elproduktion og anden udligning Ikke relevant for DataHub'en 

F Pseudo-forskrift: EDI-kommunikation i elmarkedet 

G Diskretionspolitik og procedurer vedr. datasikkerhed 

Er revideret kraftig aht. DataHub projektet og er 



Relevant 

H1 Pseudo-forskrift: Skift af elleverandør Er revideret kraftig aht. DataHub projektet, og er 



H2 Pseudo-forskrift: Måling og skabelonafregning Er revideret kraftig aht. DataHub projektet, og er 


reviderede udgave er ikke officielt gældende i mar- 

kedet. 

I Pseudo-forskrift: Stamdata Nyudarbejdet forskrift aht. til DataHub projektet. 

Forskriften fastlægger krav til stamdata for målepunkter 

og aktører i relation til oprettelse/ vedlige- 

Dok. 31785/10, Sag 10/3365 21/132



Tabel 3-2: Markedsforskrifter 

holdelse i DataHub'en. 

Forretningsprocesserne er beskrevet i "Forretningsprocesser for det danske elmarked" og beskriver 

meddelelsesflowet mellem kunde, elleverandør, balanceansvarlig, netvirksomhed og Data- 

Hub. Processerne beskriver både meddelelser der udveksles som EDI meddelelser, og meddelelser 

der udveksles f.eks. pr. brev. 

Pseudo-forskrifterne er vedlagt dette udbudsmateriale, mens øvrige forskrifter kan findes på 

Energinet.dk's hjemmeside. 

Forretningsprocesserne i elmarkedet, der er beskrevet i dokumentet "Forretningsprocesser for 

det danske elmarked", listes i nedenstående tabel. 

Områder BRS’er 

Forretningsprocesserne, der beskriver hvorledes 

en kunde skifter elleverandør, eller en elleverandør 

opsiger kontrakten med en kunde. 

Desuden beskrives processen, der udreder et 

fejlagtigt leverandørskifte. 

Stamdata for målepunktet og kunden udveksles 

mellem DataHub'en og henholdsvis netvirksomhed 

og elleverandør. 

Til- og fraflytning af kunder til et målepunkt er 

en proces, der involverer netvirksomhed, Da- 

taHub og elleverandør. 

Netvirksomheden har det primære ansvar for 

vedligeholdelse af stamdata for målepunktet, 

herunder skift af afregningsform og afbrydelse/genåbning 

af målepunktet. 

Udover stamdata, skal der udveksles målinger 

(registreringer) mellem aktøren i markedet og 

BRS-001 - Leverandørskift 

BRS-002 - Leveranceophør 

BRS-003 - Håndtering af fejlagtigt leverandørskift 

BRS-004 - Oprettelse af målepunkt 

BRS-005 - Anmodning om stamdata 

BRS-006 - Fremsendelse af stamdata 

BRS-007 - Fraflytning - meldt til netvirksomheden 

BRS-008 - Tilflytning - meldt til netvirksomheden 

BRS-009 - Tilflytning - meldt til elleverandøren 

BRS-010 - Fraflytning - meldt til elleverandøren 

BRS-012 - Skift af afregningsform 

BRS-013 - Afbrydelse og genåbning af målepunkt 

BRS-020 - Forbrugsopgørelse for skabelonafregnet målepunkt 

Dok. 31785/10, Sag 10/3365 22/132



DataHub'en. 

DataHub'en foretager beregninger på basis af 

de fremsendte basale målinger, og fremsender 

af resultatet fra disse beregninger. 

Endelig kan aktøren anmode om måledata eller 

beregningsresultater fra DataHub'en. 

BRS-021 - Fremsendelse af måledata for et målepunkt 

BRS-022 - Fremsendelse af andelstal 

BRS-023 - Fremsendelse af beregnede tidsserier 

BRS-024 - Anmodning om historiske data 

BRS-025 - Anmodning om måledata 

Tabel 3-3: Forretningsprocesser i elmarkedet (Business Requirement Specifications) 

3.4 Bruger- og interessenttyper 

Brugerne af DataHub og Aktørtestsystemet kan overordnet opdeles i to grupper: 

• Gruppen "Kunder", der udelukkende tilgår DataHub'ens funktionaliteten via en webapplikation, 

indlejret i elleverandørens portal. 

• Gruppen af professionelle brugere der tilgår både DataHub og Aktørtestsystemets funktionalitet, 

via systemets webportal. 

Dette er illustreret i nedenstående figur. 

Kunder 

Markedsaktører 

Testbrugere 

Myndigheder 

Administrator 

Brugere 

Elleverandør 

portal 

Figur 3-5: Oversigt over brugeradgang 

NemId validering 

DanId 

Webapplikation 

Portal Autentifikation 

Brugerrettigheder 


funktionalitet 


funktionalitet 

I dette materiale dækker betegnelsen "brugere" alle der tilgår funktionalitet i DataHub'en eller 

Aktørtestsystemet, uanset om tilgangen sker via DataHub'ens portal eller via en elleverandørs 

Dok. 31785/10, Sag 10/3365 23/132



portal. Men i materialet er der ikke differentieret på, om funktionerne skal være gældende i én 

eller begge portaler, da det endelige design af autentifikationsmetoder og brugerrettigheder skal 

ske i samarbejde med Energinet.dk. 

En mere detaljeret gennemgang af de forskellige brugertyper følger herefter. 

3.4.1 Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og 

mægler 

De primære brugere af DataHub'en er aktørerne i elmarkedet. Det forventes, at aktørerne vil 

anvende portaladgangen til DataHub'en til at følge status på egne forretningsprocesser og på 

EDI-kommunikationen. 

Der er ca. 250 virksomheder der typisk forventes at have 1-5 daglige brugere på DataHub'en. 

Brugerne forventes at have almindeligt it-kendskab og har forståelse for forretningsprocesserne. 

Brugerne vil anvende systemet i almindelig kontortid. 

3.4.2 Testbrugere: Markedsaktør og it-leverandør 

Inden en markedsaktør kan agere på markedet vha. EDI-kommunikation, skal aktørens itsystem 

godkendes i Aktørtestsystemet. Ligeledes skal markedets aktører have mulighed for at 

tilgå DataHub testsystemet (Preproduktionssystemet) bl.a. til brug i undervisning af nye medarbejdere. 

Markedets aktører vil derfor tilgå Aktørtestsystemet og DataHub testsystemet i rollen som testbruger. 

Aktørernes it-leverandører har behov for test af nye releases af aktørernes it-systemer og har 

derfor samme behov for tilgang til Aktørtestsystemet, som markedets aktører. 

3.4.3 Kunder: Elforbruger og elproducent 

Alle elforbrugere og elproducenter i Danmark skal have adgang til egne stamdata og målinger 

fra DataHub'en via elleverandørens webportal. En forudsætning er, at kunden er logget på elleverandørens 

webportal med NemID, og at denne autentifikation anvendes ved kald af Data- 

Hub'ens webapplikation. 

Der er her et potentiale på ca. 3,5 mio. brugere med et meget varieret it-kendskab, og med et 

varieret forbrugsmønster. 

3.4.4 Myndigheder 

Enkelte myndigheder har behov for tilgang til DataHub'en for udtræk af bl.a. statistikdata for 

processerne. Der vil her være tale om meget få brugere med et behov for begrænset funktionalitet, 

og anvendelsen forventes at være meget sporadisk. 

Dok. 31785/10, Sag 10/3365 24/132



3.4.5 Administrator og superbrugere 

Energinet.dk varetager administrationen af DataHub'en og Aktørtestsystemet og har ansvaret for 

den daglige drift. Det forventes, at der hos Energinet.dk vil være 2-5 administratorer og 2-5 superbrugere. 

3.4.6 Brugere fra Energinet.dk 

Energinet.dk har ansvar for den daglige drift af systemet, herunder support til aktørerne i markedet. 

De 10-15 brugere har bl.a. ansvaret for overvågning af forretningsprocesser, udredning 

af fejl, og ansvar for definition og kontrol af andelstalsberegning og saldoafregning. 

3.5 Afhængigheder 

Der er i projektets implementeringsfase store afhængigheder til test og implementering af ændringerne, 

der skal foretages i it-systemerne hos markedets aktører. Den endelige opstart af 

DataHub-systemet kan ikke ske før alle aktørers it-systemer er testet og godkendt, og alle initielle 

stamdata er loadet og verificeret i DataHub'en. 

3.6 Afgrænsninger 

Dette projekt omhandler ikke: 

• Ændringer i aktørernes it systemer 

• Ændringer der skal foretages i Energinet.dk's eksisterende it-systemer 

Dok. 31785/10, Sag 10/3365 25/132



4. Fælles komponenter og krav 




Portal 

Stamdata 


Rapportering 

Måledata 

Dataudtræk 








Testcases 



Testhistorik 





Platform 


Sikkerhed 

Datamigrering 

Dette afsnit beskriver krav til fælles komponenter for DataHub og Aktørtestsystemet, f.eks. system- 

og brugeradministration. 

4.1 Administration af system 

Den daglige administration af DataHub'en og Aktørtestsystemet vil ske hos Energinet.dk. 

Administrationsopgaven for DataHub'en og Aktørtestsystemet forventes for administrationsbrugerne 

primært at være: 

• Systemkonfigurering 

• Bruger- og rettighedsadministration (beskrevet i afsnit 4.2) 

• Workflow-administration (beskrevet i afsnit 4.3) 

• Overvågning af dataudveksling (webservices) og processer 

• Udredning af fejl i forbindelse med udførelse af workflow 

• Overvågning og udredning af fejlmeldinger/advarsler fra DataHub-processer 

DataHub'en skal internt, f.eks. ved planlagte jobs, udføre overvågning på egne processer og 

melde evt. registrerede uhensigtsmæssigheder til administrationsbrugerne. Denne overvågning 

kan f.eks. være: 

Dok. 31785/10, Sag 10/3365 26/132



• Overvågning og rapportering af låsninger mellem processer 

• Overvågning og rapportering af evt. løbske eller låste processer 

• Overvågning og rapportering om uregelmæssigheder i kommunikationen: F.eks. lange 

svartider, unormalt antal kald af webservices eller mange meddelelser i kø til/fra en aktør. 

• Overvågning og rapportering af unormalt cpu-, memory- eller diskforbrug 

Der skal findes processer til at udføre almindeligt vedligehold på applikationen, som f.eks.: 

• Oprydning og sletning af fejlede workflows 

• Oprydning/arkivering af logtabeller og meddelelseskøer 

Administrationen af Aktørtestsystemet vil udover ovennævnte være: 

• Konfigurering af testcases og testdata 

• Opfølgning og godkendelse af testforløb 

Disse yderligere krav for Aktørtestsystemet er beskrevet i afsnit 7. 

4.1.1 Administration af system kravtabel 

Krav 

ID 

Krav- 

type 

MK/K/O 


03-02 K Administrationsinterface Administrationsinterfacet skal være tilgængeligt 

03-03 K Parameterstyring - systemopsætning 

03-04 K Systemadministrators overvågning 

af processer 

over WAN. 

Administrationsdelen af DataHub'en og Aktørtestsystemet 

behøver ikke nødvendigvis at være 

webbaseret, men skal overholde krav til brugervenlighed 

og tilgængelighed som beskrevet i 

afsnit 5.1.1 

Systemadministrator skal have adgang til et 

niveau af systemopsætning, som overordnet 

sætter rammerne for og danner overblik over 

systemets brug. 

Parameteropsætningen og konfigurationsstyringen 

skal være separat for DataHub'en og Aktørtestsystemet. 

Systemadministrator skal have værktøjer til rådighed 

til overvågning af den aktuelle drift af 

systemet, f.eks. overvågning af status på alle 

Dok. 31785/10, Sag 10/3365 27/132



Krav 

ID 

Kravtype 

MK/K/O 


03-05 K Systemets egen overvågning af 

processer 

aktuelle processer, eller status på EDIkommunikation 

(webservices). 

Det skal være muligt at se yderligere detaljer 

omkring de enkelte processer. 

Systemet skal selv overvåge kritiske processer, 

og melde evt. observerede fejl eller uhensigtsmæssigheder 

til systemadministrator vha. mail 

eller SMS. 

Fejl der observeres kan f.eks. være løbske/låste 

processer eller uregelmæssigheder i webservice 

kommunikationen. 

03-06 K Modstandsdygtig i forhold til fejl En fejl må ikke efterlade systemet i en ustabil 

eller udefineret tilstand. 

03-07 K Processer til vedligehold Der skal findes processer til almindelig vedlige- 

03-08 K Testfunktioner i driftssituationen til 

bl.a. webservices 

holdelse af systemet, f.eks. sletning af forældede 

logmeldinger eller mulighed for at fjerne fejlede 

workflows. 

Systemet skal indeholde værktøjer, der på en 

overskuelig måde verificerer enkelte delfunktioner 

i systemet i driftsøjeblikket. 

Det kan fx være et test-værktøj, der kan kalde 

de enkelte webservices og verificere, at de sva- 

rer som forventet, eller starter et test-workflow, 

der verificerer, at workflow-funktionen virker ok. 

03-09 K Definition af kalender Systemadministratoren skal have mulighed for 

opsætning af den kalender, der gælder for hele 

systemet Herunder definition af helligdage, arbejdsdage 

og start/slut på sommertid. 

03-10 K Ugenummerering I brugerinterface (webportal og rapportering) 

skal systemet anvende dansk ugenummerering. 

03-11 K Notifikation af systemadministrator Det skal være muligt at konfigurere, hvorledes 

systemadministrator skal notificeres af systemet, 

via mail eller SMS til mobiltlf. og hvilket log- 

ningsniveau, der ønskes rapporteret. 

Dok. 31785/10, Sag 10/3365 28/132



Krav 

ID 

Kravtype 

MK/K/O 


03-12 K Fejltekster Systemets fejltekster skal kunne redigeres af 

systemadministratoren. 

Tabel 4-1: Administration af system - kravtabel 

4.2 Bruger- og rettighedsstyring 

Vedligeholdelse af brugere og brugerrettigheder i DataHub'en og Aktørtestsystemet sker af systemadministratoren 

hos Energinet.dk. 

Som beskrevet i afsnit 3.4 kan brugerne til DataHub'en og Aktørtestsystemet deles i følgende 

fem grupper: 

• Markedsaktører: Elleverandør, netvirksomhed, balanceansvarlig og mæglere 

• Kunder: Elforbruger og elproducent 

• Testbrugere: Markedsaktør og IT-leverandør 

• Myndigheder 

• Systemadministrator, superbrugere og brugere hos Energinet.dk 

Brugergruppen "Kunder" er med 3,5 mio. potentielle brugere, klart den største. Autentifikation 

og rettigheder til denne gruppe skal ske fuldt automatiseret. Autentifikation skal foretages via 

NemID. 

Rettighederne for de øvrige 4 brugergrupper skal vedligeholdes af systemadministratoren, men 

autentifikation kan med fordel foretages via NemID. 

4.2.1 Bruger- og rettighedsstyring kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-13 K Fælles brugeradministration for DataHub'en 

og Aktørtestsystemet 

Administrationen af brugere skal være fælles for 

DataHub'en og Aktørtestsystemet, men det skal 

dog være muligt at definere forskellige roller til 

samme bruger i de to systemer. 

03-14 K Brugerinterface til brugeradmini- Al administration af brugere og rettigheder skal 

ske gennem et velfungerende brugerinterface, 

Dok. 31785/10, Sag 10/3365 29/132



Krav 

ID 

Kravtype 

MK/K/O 


stration og skal opfylde krav til brugervenlighed og tilgængelighed 

som beskrevet i afsnit 5.1 

03-15 K Princip for brugerstyring 

Det er dog ikke et krav, at brugeradministratio- 

nen skal ske via webportalen. 

Systemadministratoren vedligeholder brugeroplysninger 

og rettigheder. 

Brugerstyringen skal opfylde følgende overord- 

nede målsætninger: 

Autentifikation - (hvem er brugeren) 

Autorisation - (hvad må brugeren) 

03-16 K Vedligeholdelse af brugergrupper Systemadministratoren skal kunne oprette og 

03-17 K Vedligeholdelse af brugere 

03-18 MK Autentifikation af brugergruppen 

"Kunder" via NemID 

03-19 K Autentifikation af øvrige brugergrupper 

vedligeholde et ubegrænset antal brugerroller i 

systemet, herunder tildele/fjerne rettigheder i 

systemet til en brugergruppe. 

Systemadministratoren skal kunne redigere alle 

oplysninger for en specifik bruger og skal ligeledes 

kunne låse adgangen for denne. 

Autentifikation af brugere i brugergruppen 

"Kunder" skal ske via NemID, og skal her an- 

vende NemID's portlets til dette. 

De fire brugergrupper markedsaktører, testbrugere, 

myndigheder og administrationsbrugere 

(dvs. undtaget "Kunder") - skal autentificeres 

via NemID - eller via ordinær brugeradministration 

i systemet. 

Ved ordinær autentifikation, skal det være muligt 

at definere mindstekrav til styrke af pass- 

word, passwordlængde og udløb af password. 

03-20 K Rollebaseret rettighedsstruktur Brugerrettighederne skal tildeles gennem en 

rollebaseret bruger- /rettighedsstruktur. 

En bruger kan typisk have flere (og forskellige) 

roller i DataHub'en og i Aktørtestsystemet. 

03-21 K Rettigheder håndteres uanset til- Der skal tages hensyn til en brugers rettigheder 

til funktioner og data, uanset hvorledes bruge- 

Dok. 31785/10, Sag 10/3365 30/132



Krav 

ID 

Kravtype 

MK/K/O 


gang til systemet ren tilgår systemet (f.eks. webportal eller webservices). 

Rettighedshåndteringen må derfor 

ikke være implementeret i brugergrænsefladen. 

03-22 K Rettigheder til data på aktørniveau. Rettigheder til data tilknyttes på aktørniveau. 

03-23 K Vedligeholdelse af brugeroplysninger 

Eksempel: En bruger hos en elleverandør, må 

kun få adgang til de målepunkter denne elleverandør 

er tilknyttet, og kun få adgang til de må- 

linger, som tilhører disse målepunkter. 

Brugergrupperne - undtaget brugere i brugergruppen 

"Kunder" - skal selv kunne registrere 

yderligere brugeroplysninger, fx. e-mail adresse 

eller telefonnummer. 

03-24 K Vedligeholdelse af password For de brugere, hvor der ikke anvendes NemID 

som autentifikation, skal det være let at ændre 

03-25 K "Glemt password" og "Glemt brugernavn" 

funktion 

03-26 K Decentral vedligeholdelse af brugere 

hos aktørerne 

eget password. 

For de brugere, hvor der ikke anvendes NemID 

som autentifikation, skal der findes standardiserede 

funktioner til "Glemt password" og "Glemt 

brugernavn". 

I brugergrupperne - undtaget "Kunder" - skal 

det være muligt at oprette en bruger med rollen 

"aktør administrator" - der har ansvar for opret- 

telse/vedligeholdelse af brugere i denne aktørs 

egen virksomhed. 

03-27 K Rapportering af brugerdefintioner Der skal findes rapportfunktioner til dokumenta- 

tion af brugere, deres tilknytning til brugerroller 

og brugerrollernes rettigheder i systemet. 

03-28 MK Revisionslog af brugerændringer Alle ændringer, der foretages mht. brugeropsætning 

og brugerrettigheder, skal logges i sy- 

03-29 K Rapportering af ineffektive brugere 

af systemet 

stemet, med angivelse af hvilken bruger der har 

foretaget rettelsen og tidspunktet for rettelsen. 

Der skal findes rapportfunktioner til dokumentation 

af brugere på portalen, som ikke har været 

logget ind i en periode (parameterstyret). 

Dok. 31785/10, Sag 10/3365 31/132



Krav 

ID 

Kravtype 

MK/K/O 


03-30 K Understøttelse af SAML 2.0 standard I relation til overførsel af information om identitet 

og rettigheder, skal DataHub'en understøtte 

SAML 2.0 standarden, jf. standarden på OIO. 4 

Tabel 4-2: Bruger- og rettighedsstyring - kravtabel 

4.3 Workflow 

Workflow-funktionalitet er en meget central mekanisme, som anvendes til behandlingen af de 

forskellige forretningsprocesser i DataHub'en, og til processering af testcases i Aktørtestsystemet. 

I DataHub'en forventes det, at alle forretningsprocesser (BRS'ere) defineres ved at konfigurere 

et workflow svarende til hver proces. 

I Aktørtestsystemet vil de testcases, som aktørerne skal gennemføre, kunne defineres i et workflow. 

Da det kan forventes, at der vil ske ændringer til de definerede forretningsprocesser i forbindelse 

med ændringer i markedsreglerne, skal definitionerne af workflows være fleksible over tid. 

Der forventes at være mange samtidige aktive workflows i en normal situation, hvilket kræver 

velfungerende overvågningsværktøjer til at sikre sig, at alle processer gennemløbes ok, og der 

skal findes gode værktøjer til fejlfinding af workflow. 

4.3.1 Workflow kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-31 K Oprettelse og redigering af workflow Der skal være anvendelige værktøjer til oprettelse 

og redigering af workflow i systemet. 

4 http://www.itst.dk/it-arkitektur-og-standarder/standardisering/standarder-forserviceorienteret-infrastruktur/standarder-for-brugerstyring/filer-til-standarder-forbrugerstyring/brug-af-saml-2.0 

Dok. 31785/10, Sag 10/3365 32/132



Krav 

ID 

Kravtype 

MK/K/O 


03-32 K Brugerinterface til workflow administration 

Al administration af workflow skal ske gennem 

et velfungerende brugerinterface, og skal opfylde 

krav til brugervenlighed og tilgængelighed 

som beskrevet i afsnit 5. 

Det er dog ikke et krav, at administrationen af 

workflow skal ske via webportalen. 

03-33 K Status for workflow Det skal være muligt for brugere i DataHub'en 

at se overordnet status for alle aktive workflows 

og at kunne se detaljerede oplysninger for specifikke 

processer. 

03-34 K Fejlmelding fra workflow Hvis en workflow-proces fejler, skal dette logges 

i DataHub'en og systemadministratoren skal 

notificeres. 

03-35 K Ændring af aktivt workflow Det skal være muligt for brugere at ændre sta- 

03-36 K Flere versioner af workflow definitioner 

tus eller forløb på et aktivt workflow. 

Det skal være muligt at definere flere versioner 

af samme workflow i forbindelse med ændring af 

processer. 

03-37 K Rollback ved afbrudte workflow Det skal være muligt at foretage rollback for de 

transaktioner, der indgår i et workflow ved en 

evt. afbrydelse af workflowet. 

03-38 K Logning af workflow Alle workflow processer skal logge procesflowet 

og der skal være mulighed for at foretage evt. 

fejlsøgning senere. 

03-39 K Dokumentation af workflow Der skal findes rapportfunktioner, der giver en 

overskuelig dokumentation af workflow definitioner. 

03-40 K Konfigurering af tidsfrister Pseudo-forskrifterne H1, H2 og D1 definerer 

mange tidsfrister for processer og kan forventes 

at blive ændret på sigt. 

Disse tidsfrister skal være konfigurerbare i 

workflowprocesserne. 

Dok. 31785/10, Sag 10/3365 33/132



Krav 

ID 

Kravtype 

MK/K/O 


03-41 K Midlertidig annullering af tidsfrister I forbindelse med fejlsituationer, kan der være 

behov for en midlertidig annullering af aktuelle 

tidsfrister, defineret i workflow. 

Tabel 4-3: Workflow – kravtabel 

4.4 Rapportering 

Hvis f.eks. kommunikationen til DataHub'en har 

været afbrudt et døgn, må aktørernes efterfølgende 

indsendelser af data ikke blive afvist pga. 

overskridelse af tidsfrist. 

I vurderingen af tilbuddet vil der blive lagt positiv vægt på, at rapportering fra DataHub'en og 

Aktørtestsystemet kan foretages via en veldefineret arkitektur. Det er et krav, at der skal leveres 

et generelt rapporteringsværktøj, som bl.a. kan levere de rapporter som DataHub'en og Aktørtestsystemet 

har behov for (se krav beskrevet i specifikke afsnit). 

Der skal samtidig leveres en integrationsløsning til Energinet.dk's eksisterende Datawarehouse 

platform SAP / BW (ETL proces). Evt. kan det ovenstående rapporteringskrav opfyldes ved brug 

af Energinet.dk's SAP / BW. 

Kravene til indholdet i de enkelte rapporter er specificeret under de specifikke krav til Data- 

Hub'en og Aktørtestsystemet. 

4.4.1 Rapportering kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-42 K Rapporteringsarkitektur Der skal leveres et generelt rapporteringsværktøj, 

som bl.a. kan levere de rapporter, som er 

03-43 K Integration med eksisterende SAP 

BW / BO 

specificeret i de specifikke afsnit under DataHub 

og Aktørtestsystem. 

Der skal leveres en integrationsløsning til Ener- 

ginet.dk's eksisterende SAP / BW og SAP BO 

rapporteringsplatform. 

03-44 K Afvikling af rapportering Afvikling af rapporteringskørsler må ikke påvirke 

svartider for brugerne eller øvrige transaktioner 

Dok. 31785/10, Sag 10/3365 34/132



Krav 

ID 

Kravtype 

MK/K/O 


03-45 K Rapporteringsgrænseflade Brugergrænsefladen skal være webbaseret, hvor 

brugerobjekter kan indlejres i andre webløsninger 

eller portaler 

03-46 K Rapporteringsformat Rapportoutput skal være i pdf format og regnearksformat 

(XML og csv). 

Tabel 4-4: Rapportering – kravtabel 

4.5 Dataudveksling 

Principper og regler for dataudveksling med DataHub'en er beskrevet i pseudoforskrift F og i de 

tilhørende bilag. 

Det er her bl.a. beskrevet, at al dataudveksling sker via synkrone og asynkrone webservices. 

DataHub'en skal udover webservices også have mulighed for udveksling af data via SMTP (email). 

Dette skyldes, at DataHub'en, udover dataudveksling med aktørerne i det danske elmarked, 

også skal udveksle data med f.eks. NordPool (elbørsen) og de øvrige nordiske samt nordeuropæiske 

systemansvarlige, og her er kommunikationsmetoden SMTP. 

Den forventede funktionalitet af webservice, kan skitseres således: 

Funktionalitet 

Dataudveksling beskrevet i forretningsprocesserne Asynkron webservice. Store transaktionsmængder, 

og store datameddelelser. 

Simple forespørgsler på data fra aktørernes it- 

systemer 

Synkron webservice. Som service til aktørernes eg- 

ne it-systemer, skal der stilles en række webservices 

til rådighed fra DataHub'en. Nogle webservices 

kan være sammenfaldende med forretningsprocesserne, 

f.eks. "hent stamdata for målepunkt", eller 

"hent status for transaktioner indsendt i dag" 

Simple forespørgsler/opdateringer på data fra Portal Synkron webservice. Dataudveksling til/fra webportalen 

forventes at ske ved kald af webservices. Her 

vil der også være tale om muligheder for opdaterin- 

Tabel 4-5:Funktionalitet af webservices 

ger af data i DataHub'en. 

Anvendelse af webservices i elmarkedet har indtil nu været begrænset til de balanceansvarliges 

indmelding af handelsplaner til Energinet.dk, ellers har al dataudveksling i elmarkedet foregået 

Dok. 31785/10, Sag 10/3365 35/132



via SMTP (e-mail). Webservices er således nyt i dette forretningsområde, og det må forventes, 

at krav og ønsker til nye webservices fra aktørerne vil vokse i takt med modningen af anvendelsen. 

Webservices der tilbydes i DataHub'en skal også være tilgængelige i Aktørtestsystemet. 

4.5.1 Dataudveksling kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-47 MK Krav fra pseudo-forskrift F Webservice skal opfylde krav til dataudveksling, 

som beskrevet i pseudo-forskrift F og bilagene 

til denne forskrift. 

03-48 K Dataudveksling via SMTP Dataudveksling med DataHub'en skal alternativt 

kunne ske med SMTP (mail). 

Dataformat er det samme som ved udveksling 

via webservices, beskrevet i pseudo-forskrift F. 

03-49 K Dataudveksling med webportal Kommunikation og dataudveksling mellem webportalen 

og DataHub'en skal ske ved webservicekald. 

03-50 K Testfunktion til webservices Der skal til systemadministratoren findes web- 

03-51 K Webservices i DataHub og Aktørtestsystem 

Tabel 4-6: Dataudveksling - kravtabel 

4.6 Alternativ webadgang for kunder 

forms, der kan anvendes til test af de enkelte 

webservices. 

Webservices, der tilbydes i DataHub'en, skal 

også være tilgængelige i Aktørtestsystemet 

I opgavebeskrivelsen, der danner grundlag for dette projekt, er det et krav at alle elkunder i 

Danmark får adgang til at se egne stamdata og måledata i en webportal. I denne kravspecifikation 

er dette formuleret som et krav om, at DataHub'en stiller en indlejret webapplikation til rådighed, 

og at elleverandørerne anvender denne webapplikation i deres egen portal. 

Et alternativ til dette er, at DataHub'en selv tilbyder en portalløsning, hvor kunden logger ind 

med NemID og her kan se egne stamdata og måleregistreringer. 

Dok. 31785/10, Sag 10/3365 36/132



Funktionaliteterne i DataHub'en vedr. kunder, f.eks. tilknytning af et målepunkt til en kunde vil 

være uændret - det er blot DataHub'en, der stiller portalen til rådighed for kunden, herunder 

understøttelse af indlogning med NemID. 

4.6.1 Alternativ webadgang for kunder kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-52 O Alternativ webadgang for brugergruppen 

"Kunder" 

Tabel 4-7: Alternativ webadgang for kunder - kravtabel 

Det skal belyses hvilke økonomiske, tids- og 

systemmæssige konsekvenser det har for projektet, 

at DataHub'en tilbyder indlogning til alle 

kunder, via NemID, på DataHub-portalen. 

Funktionaliteten for kunderne skal i portalen 

være uændret i forhold til de i øvrigt specificerede 

krav i dette bilag. 

Dok. 31785/10, Sag 10/3365 37/132



5. Funktionskrav til Portalen 

Dette afsnit beskriver generelle krav til portalløsningen. 


Portal 


Stamdata 



Rapportering 

Måledata 

Dataudtræk 









Testcases 



Testhistorik 




Platform 


Sikkerhed 

Datamigrering 

5.1 Generelle funktionskrav til Portal 

DataHub'en skal primært understøtte de operationelle datastrømme og processer, der driver elmarkedet. 

Men der er også krav til en brugervenlig webportal. Brugerne af portalen kan primært 

opdeles i tre grupper: 

• Netvirksomhed, elleverandør, balanceansvarlig og it-leverandør - som kan anvende portalen 

som det daglige værktøj mod DataHub'en og Aktørtestsystemet. 

• Elkunde (elforbruger, elproducent) og myndighed - som kan anvende portalen til opslag 

efter behov. 

• Offentligheden - som kan anvende portalen til statistik opslag efter behov. 

Portalen skal være en fælles løsning for DataHub'en og Aktørtestsystemet og skal sikre en god 

og effektiv kommunikation til alle brugere af DataHub'en. 

For at sikre at brugerne kan bruge systemet med minimal instruktion og support, findes der en 

række principper relateret til brugeroplevelsen: 

• Systemet skal være umiddelbart forståeligt. 

Dok. 31785/10, Sag 10/3365 38/132



• Det skal være nemt at lære systemet at kende og med tiden bruge mere avancerede 

funktioner. 

• Systemet skal kunne betjenes af en række forskellige brugere med forskellige forudsætninger 

og behov 

• Systemet skal være attraktivt for brugeren at bruge, den grafiske brugergrænseflade 

skal give brugeren lyst til at bruge systemet 

• Systemet skal have mulighed for at følge standarder, juridiske krav og best practice 

ang. brugervenlighed 

Brugergrænsefladen skal være rig og omfatte tekst, tabeller, grafik herunder grafer og animation. 

Design 

Der er ikke udarbejdet en specifik designmanual for DataHub'en. Webportalens design skal så 

vidt muligt ligne Energinet.dk's kommende hjemmeside (idriftsættes august 2010). 

Energinet.dk's Design- og styleguide er vedlagt som bilag. 

Brugervenlighed 

Portalen skal støtte brugerne med intuitive brugergrænseflader, som skal sikre: 

• Let genkendelighed – både visuelt og sprogligt, så det passer til brugernes faglige omgivelser 

• Ensartethed og konsistens. Det gælder layout, ikoner, tekst, funktionalitet og menuer. 

• Hurtigst mulig adgang til relevant funktionalitet. 

Portalen skal så vidt muligt følge krav om tilgængelighed jf. ”Standarder for offentlige hjemmesider 

og tilgængelighed” (WCAG 2.0-AA Web Content Accessibility Guidelines), men Energinet.dk 

er ikke underlagt lovkrav om opfyldelse af WCAG. 

Det er ligeledes et ønske at portalen, så vidt muligt, følger retningslinierne for IT- og Telestyrelsens 

”Bedst på Nettet”. 

Der lægges vægt på, at det er muligt at tilgå indhold med brug af andre browsere end Internet 

Explorer. Der skal browser-optimeres til MSIE, Firefox, Safari og Chrome. 

Hjælpefunktioner og dokumentation 

Brugerne har brug for at kunne finde relevant hjælp og vejledning, når behovet opstår i systemet. 

Der er behov for en intuitiv og selvforklarende brugergrænseflade, som understøttes af 

hjælpefunktioner kombineret med et godt visuelt (grafisk) overblik. 

Som selvhjælp til brugerne skal der være adgang til diskussionsforum og FAQ. 

Dok. 31785/10, Sag 10/3365 39/132



5.1.1 Kravtabel til generelle funktionskrav til Portal 

Krav ID Kravtype 

MK/K/O 


Generelle funktionskrav 

03-53 K Brugergrænsefladen Portalen skal kunne anvende portlets, webparts 

eller lignende i brugergrænsefladen. 

03-54 K Standardbaseret webinterface 

Systemets skærmbilleder skal baseres på 

XHTML 1.0 eller nyere. Skærmbilledernes layout 

skal implementeres med CSS 2.0. Skærmbillederne 

skal kunne gennemgå W3C HTML/XHTML 

og CSS 2.0 validering uden fejl. 

03-55 K Portal software Portalens brugergrænseflade skal baseres på 

03-56 K Browser 

standard portal software og administreres gennem 

standard CMS. 

Der skal browser-optimeres til de browsere, der 

har mere end 5 % markedsandel. 

03-57 K Ændringer i drift Brugergrænsefladen i portalen skal kunne tilpasses 

og konfigureres, mens systemet er drift. 

03-58 K Konfigurerbarhed 

Brugergrænsefladen skal være så fleksibel som 

mulig. Derfor skal alle links, felter, datoer og 

grænseværdier kunne konfigureres gennem 

administrationsinterfacet. 

03-59 K Periodisering Der skal være mulighed for at systemadmini- 

stratoren kan periodisere f.eks. idriftsættelse af 

webformularer. 

03-60 K Opret/rediger tekster Systemadministrator skal kunne oprette og redigere 

sider og tekster. 

03-61 K Sprog Systemet skal kunne håndtere flere sprog i brugergrænsefladen. 

Sprogvarianter skal ligge som 

selvstændigt tekstbibliotek, der kan udskiftes 

og udbygges i takt med behov. 

03-62 K Sprog ved startleverance Systemet skal leveres med dansk og engelsk 

brugergrænseflade. 

Dok. 31785/10, Sag 10/3365 40/132




MK/K/O 


03-63 K Valg af sprog I brugergrænsefladen skal det være muligt for 

brugeren, at vælge hvilket sprog siden ønskes 

vist med. 

03-64 K Tegnsæt og dialog Som default skal brugergrænsefladen være på 

dansk – (herunder også decimal- og tusindtalsseparatorer) 

og dialog. 

03-65 K Skærmopløsning 

Systemets nye skærmbilleder skal optimeres til 

skærmopløsning 1024*786 og 16/32 bit farver 

samt være skalerbart til større skærmopløsninger. 

Der bør være fleksibilitet for andre standard 

opløsninger, så systemet kan bruges på en 

række forskellige enheder. 

03-66 K Vedligehold menustruktur Systemadministrator skal kunne redigere i portalens 

menustruktur. 

03-67 K Søgefunktion 

Der skal etableres søgefunktion, som er til rådighed 

på alle sider. Der søges på tværs af hele 

brugergrænsefladen, og søgningen skal fungere 

som standard wildcard søgning. 

03-68 K Sporing af brugernes adfærd Systemadministratoren skal kunne spore brugernes 

adfærd på specificerede sites. 

Der skal kunne genereres udtræk over: 

- hvor ofte de enkelte sider besøges 

- hvilke filer, der bliver downloadet og hvornår 

03-69 K Print ikon På alle sider skal der være et ”Print" ikon for 

start af printdialog. 

03-70 K Print layout Ved print af siden, skal siden udskrives uden de 

faste rammer f.eks.. top og venstremenuer. Der 

skal på udskriften anføres brødkrummesti og 

sidens navn. Ud over fjernelse af rammerne 

skal indholdet stå som på skærmen og må ikke 

beskæres. 

03-71 K Download til regneark På relevante sider skal det være muligt at eksportere 

de fremsøgte data til regneark i forma- 

terne xml og csv. 

Dok. 31785/10, Sag 10/3365 41/132




MK/K/O 


03-72 K Sortering af data Ved visninger af data i tabeller/lister skal det 

være muligt at sortere data ved klik på kolonneoverskriften. 

03-73 K Søgning af data Der skal kunne fremsøges data, og på disse 

sider skal der anvendes søgefunktion baseret på 

enkle og gængse principper og standarder for 

web-brugergrænseflader. Søgningen må ikke 

være case sensitiv. 

03-74 K Filtrering af data På sider, hvor der skal fremsøges data, skal det 

være muligt at filtrere data ved hjælp af dropdown 

lister eller wildcard søgning. 

Design- og brugervenlighed 

03-75 K Design Webportalen og webapplikationens design skal 

følge retningslinierne for Energinet.dk's hjem- 

meside, som beskrevet i Energinet.dk's Design- 

og styleguides, vedlagt som bilag. 

Hvis dette krav ikke kan opfyldes, skal der redegøres 

for afvigelserne i forhold til design- og 

styleguides i Løsningsbeskrivelsen. 

03-76 K "Bedst på Nettet" Portalen skal følge retningslinierne for IT- og 

Telestyrelsens ”Bedst på Nettet". 

03-77 K Tilgængelighed 

Leverancen skal opnå en vurdering på mini- 

mum 4 Netkroner, baseret på "Bedst på nettets" 

screening (foretaget af Leverandøren) og 

brugerevaluering (foretaget af brugere i Energinet.dk). 

Begge tæller ligeligt. 

Brugerevalueringen kan evt. gennemføres på 

en brugervenligheds-workshop. 

Portalen skal opfylde retningslinjer angivet i 

”Standarder for offentlige hjemmesider og til- 

gængelighed” (WCAG 2.0 AA Web Content Accessibility 

Guidelines), 

03-78 K Menustruktur Alle brugere af portalen skal kun se de menupunkter, 

som vedkommende har adgang til. 

Dok. 31785/10, Sag 10/3365 42/132




MK/K/O 


03-79 K Brugervenlighed Brugerne må ikke opleve mistet brugervenlighed 

i forbindelse med præsentation af systemsider 

("siden ikke fundet" mm.) 

Hjælpefunktioner og dokumentation 

03-80 K Administration af hjælpetekster 

Det skal være muligt for systemadministratoren 

at vedligeholde portalens hjælpetekster. 

03-81 K Pop up hjælp på felter Det skal være muligt at definere pop up hjælp 

på felter (hjælpetekst når cursoren hviler på en 

tekst/felt) 

03-82 K Autotekst på felter Det skal være muligt at anvende autotekst på 

felter (hjælpetekst vises i et indtastningsfelt) 

03-83 K Vedligeholdelse af vejledninger 

og informationsmateriale 

03-84 K Online hjælp og vejledning 

Det skal være muligt at oprette og vedligeholde 

vejledninger (til download) og andet informationsmateriale. 

Eksempler på andet informati- 

onsmateriale kunne være links, kontaktinformation, 

markedsinformation el. lign. 

Alle typer af brugere skal kunne finde relevant 

hjælp og vejledning, når behovet opstår i systemet. 

03-85 K Vejledninger Det skal være muligt for brugeren at blive præsenteret 

for og downloade relevante vejlednin- 

03-86 K FAQ 

03-87 K Diskussionsforum 

ger. 

Diskussionsforum og FAQ 

Portalen skal indeholde en FAQ side, som skal 

kunne vedligeholdes af systemadministratoren. 

FAQ skal kunne ses og anvendes af alle interessenter 

med rettigheder hertil. 

Brugergrænsefladen skal tilbyde standard forum 

funktionalitet, hvor markedsaktørerne og itleverandører 

kan vende problemstillinger og 

lignende, både med Energinet.dk og andre brugere. 

Dette forum skal bl.a. give brugerne mu- 

lighed for at oprette og kommentere på tråde, 

samt at abonnere på relevante tråde og efter- 

Dok. 31785/10, Sag 10/3365 43/132




MK/K/O 


følgende blive adviseret omkring nye indlæg. 

03-88 K Standard WIKI funktionalitet FAQ og diskussionsforum ønskes baseret på 

standard WIKI funktionalitet. 

03-89 K Nyheder Nyheder skal kunne kategoriseres og skal kunne 

præsenteres på forskellig vis overfor systemets 

brugere. Eksempelvis ved at aktuelle nyheder 

vises på én side og gamle nyheder fremfindes 

på et arkiv, hvor nyhederne er kategoriseret 

efter et sæt metadata eller via en indbygget 

søgefunktion, der skal kunne slås til eller fra 

efter eget valg. 

03-90 K Nyhedsbrev abonnement Det skal være muligt at sende information direkte 

til sitets brugere i forbindelse med diverse 

nyheder. 

03-91 K Nyhedsbrev tilmelding Markedsaktører og it-leverandører skal selv 

kunne til- og framelde sig som abonnenter på 

nyhedsbreve, som varierer efter brugerens interesseprofil. 

03-92 K Nyhedsbrev sikkerhed Systemet skal automatisk sikre, at abonnenterne 

ikke kan se hinandens e-mail-adresser i de 

udsendte nyhedsbreve eller anden information 

der kan vise de øvrige abonnenters identitet. 

03-93 K Nyhedsbrev udsendelse Det skal være muligt at sende forskellige nyhedsbreve 

til forskellige grupper af abonnenter. 

03-94 K Nyhedsbrev arkiv Det skal være muligt at se nyhedsbrevskladder 

og udsendte nyhedsbreve i et internt arkiv. 

03-95 K Nyhedsbrev oversigt Det skal være muligt genere en oversigt over, 

hvilke nyhedsbreve, den enkelte abonnent har 

modtaget. 

Tabel 5-2: Kravtabel for Generelle funktionskrav til portal 

Dok. 31785/10, Sag 10/3365 44/132



5.2 Webformularer 

I DataHub'en skal der findes webformularer til en række formål såsom forespørgsler mellem aktører 

i markedet, bestilling af ændringer i stamdata etc. 

Anvendelsen af webformularer skal bl.a. sikre anonymiteten mellem elleverandør og netvirksomhed. 

Webformularer forventes at blive en meget anvendt funktion i DataHub'en, og det er derfor vigtigt, 

at de kan ændres og nye tilføjes på en let tilgængelig måde efter behov. 

Webformular-eksempel på forespørgsel fra netvirksomhed til elleverandør: 

En netvirksomhed har fået en henvendelse fra en kunde vedr. en fejlagtig flytning. Netvirksomheden 

skal afklare dette med kundens elleverandør og vælger derfor webformularen "Forespørgsel 

til elleverandør". Da netvirksomheden ikke kender målepunktets elleverandør, skal forespørgslen 

foregå via webformular til DataHub'en for at sikre anonymiteten. 

I denne webformular skal netvirksomheden: 

• Vælge det aktuelle målepunkt vha. en søgefunktion eller fra en valgliste der viser 

netvirksomhedens målepunkter. 

• Vælge om meddelelsen skal sendes til tidligere, nuværende eller kommende elleverandør 

(radio button el. checkboks). 

• Formulere problemet i en tekstboks 

• Evt. udfylde afsenderens kontaktoplysninger, mailadresse el. telefon 

• "Sende" til elleverandør 

Herefter skal DataHub'en finde oplysningerne på den pågældende elleverandør og sende oplysninger 

fra webformularen til elleverandøren pr. mail. DataHub'en arkiverer webformularen. 

5.2.1 Kravtabel til etablering af webformularer 

Krav 

ID 

Kravtype 

MK/K/O 


03-96 K Kunde til netvirksomhed vedr. et 

målepunkt 

03-97 K Kunde til elleverandør vedr. et 

målepunkt 

Forespørgsel til netvirksomhed vedr. et måle- 

punkt. F.eks. hvis kunden har spørgsmål til det 

målte forbrug eller til et fremsendt aflæsningskort. 

Forespørgsel til elleverandør vedr. et målepunkt. 

F.eks. hvis kunden har spørgsmål til det 

afregnede forbrug eller til tidligere, nuværende 

Dok. 31785/10, Sag 10/3365 45/132



Krav 

ID 

Kravtype 

MK/K/O 


03-98 K Kunde til netvirksomhed vedr. forkerte 

stamdata 

03-99 K Kunde til elleverandør vedr. fejlagtig 

leverandørskift 

03-100 K Elleverandør til netvirksomhed 

vedr. måling på et målepunkt 

03-101 K Elleverandør til anden elleverandør 

vedr. leverandørskift 

03-102 K Elleverandør til øvrige 

markedsaktører vedr. målepunkt 

eller kommende elleverandør. 

Oplysning til netvirksomhed vedr. forkerte 

stamdata på et målepunkt f.eks. disponentnavn. 

Forespørgsel til nuværende eller kommende 

elleverandør i forbindelse med udredning af 

fejlagtig flytning på et specifikt målepunkt. 

Forespørgsel til netvirksomhed vedr. målinger 

på et specifikt målepunkt. F.eks. atypisk eller 

manglende måling på et målepunkt. 

Forespørgsel til tidligere, nuværende eller 

kommende elleverandør i forbindelse med problemer 

ved et leverandørskifte på et specifikt 

målepunkt. 

Information til øvrige markedsaktører, der er 

relateret til et specifikt målepunkt. Kan vedrøre 

tidligere, nuværende eller kommende elleverandør. 

03-103 K Elleverandør til Energinet.dk Forespørgsel til Energinet.dk: Markedsrelaterede 

spørgsmål, support til DataHub funktioner, 

spørgsmål vedr. aktørtest etc. 

03-104 K Netvirksomhed til elleverandør 

vedr. fejlagtig flytning 

03-105 K Netvirksomhed til elleverandør 

vedr. fejlagtig leverandørskifte 

03-106 K Netvirksomhed til øvrige markedsaktører 

vedr. målepunkt 

Forespørgsel til tidligere, nuværende el. kom- 

mende elleverandør i forbindelse med udredning 

af fejlagtig flytning på et specifikt målepunkt. 

Forespørgsel til tidligere, nuværende eller 

kommende elleverandør i forbindelse med ud- 

redning af fejlagtig leverandørskifte på et specifikt 

målepunkt. 

Information til øvrige markedsaktører der er 

relateret til et specifikt målepunkt. 

03-107 K Netvirksomhed til Energinet.dk Forespørgsel til Energinet.dk. F.eks. markedsrelaterede 

spørgsmål, support til DataHub funktioner, 

spørgsmål vedr. aktørtest etc. 

Dok. 31785/10, Sag 10/3365 46/132



Krav 

ID 

Kravtype 

MK/K/O 


03-108 K It-leverandør til Energinet.dk Forespørgsel til Energinet.dk. Fx. support til 

funktioner eller spørgsmål vedr. aktørtest 

03-109 K It-leverandør til øvrige itleverandører 

eller markedsaktør 

Tabel 5-2: Kravtabel til etablering af webformularer 

5.2.2 Kravtabel til webformularer 

Krav 

ID 

Kravtype 

MK/K/O 


Information eller forespørgsel til øvrige it- 

leverandører el. markedsaktører vedr. aktørtest. 

03-110 K Webformular videreudvikling Der skal findes et designværktøj til oprettelse 

og ændring af webformularer. Der lægges vægt 

på, at løsningen skal være åben og let tilgængelig 

for løbende ændringer af de elektroniske 

formularer, og at nye formularer kan tilføjes 

uden brug af ekstern ekspertbistand. Man skal 

kunne udvide anvendelse af formularer i takt 

med, at behovet opstår. 

03-111 K Vedhæfte bilag I forbindelse med udfyldelse af formularer skal 

der være mulighed for at vedhæfte eller medsende 

bilag. Som minimum i Word, pdf-, eller 

regnearksformat. 

03-112 K Print af webformular Alle elektroniske formularer skal i den eksisterende 

form kunne printes af brugeren. 

03-113 K Arkivering webformular Systemet skal give mulighed for en arkivering 

af udfyldte blanketter. Indsendelser skal kunne 

gemmes og ekspederes i et arkiv til formålet. 

Systemadministratoren skal have mulighed for 

at slette fra arkivet. 

03-114 K Søgning i arkiv Systemadministratoren have mulighed for fri- 

Tabel 5-2: Kravtabel for webformularer 

tekstsøgning og filtrering på status, side, dato 

og/eller feltspecifikt indhold i arkivet. 

Dok. 31785/10, Sag 10/3365 47/132



5.3 Krav til DataHub portalen 

Brugerne af DataHub portalen vil både være professionelle brugere, og it-svage brugere. Brugerne 

kan grupperes således: 

• Systemadministratorer, superbrugere og brugere (Energinet.dk) 

• Markedsaktører er de primære brugere af systemet. 

• Kunder - elforbruger, elproducenter og myndigheder 

• Offentlig - den offentlige del af portalen 

Nedenstående tabel viser de primære overordnede funktioner, der skal kunne udføres via Data- 

Hub portaldelen for de enkelte brugergrupper. De enkelte funktioner er nærmere beskrevet i 

afsnit 6 

Funktion System 

admin 

Markeds 

aktører 

Kunder Offentlig 

Stamdata for aktør CRUD 5 RU R R 

Stamdata for målepunkt CRUD CRU R 

Måledata CRUD CRU R 

Beregningsfunktion CRUD CRUD 

Rapportering CRUD R R R 

Procesovervågning og styring (workflow) CRUD CRU 

Tabel 5-1 Overordnede funktioner 

5.4 Krav til Aktørtestsystem portalen 

Brugerne af Aktørtestsystemet vil være professionelle brugere, og kan opdeles i to grupper: 

• Systemadministrator, superbrugere og brugere (Energinet.dk) 

• Markedsaktører og it-leverandører er de primære brugere af systemet. 

5 CRUD: Create, Read, Update, Delete 

Dok. 31785/10, Sag 10/3365 48/132



De overordnede funktioner der skal kunne udføres via portalen i Aktørtestsystemet for de enkelte 

brugergrupper vil være: 

Funktion Systemadministrator 

Registrering af it-system der skal testes CRUD CRUD 

Administration af testcases CRUD R 

Administration af testdata CRUD CRUD 

Administration af testforløb CRUD R 

Godkendelse af testforløb CRUD 

Historik for testforløb R R 

Tabel 5-2: Funktioner per brugergruppe i Aktørtestsystemet 

De specifikke funktionskrav til Aktørtestsystemet er specificeret i kapitel 7. 

Aktør & itleverandør 

5.5 Funktionskrav til integration af Selvbetjeningsportalen 

"Selvbetjening" er betegnelsen for den eksisterende webapplikation placeret på 

https://selvbetjening.energinet.dk. 

Selvbetjeningsportalen (SBP) anvendes både af el- og gaskunder, og er funktionsmæssigt opdelt 

efter dette, men brugerstyring og administration er fælles for hele portalen. 

Da brugerne på SBP også vil være brugere på DataHub'en, ses en fordel i at integrere Energinet.dk's 

Selvbetjening i DataHub portalen. Den omtalte integration vil kun gælde for el-kunder, 

altså vil Selvbetjeningsportalen fortsætte med servicering af gas-kunder. 

Dok. 31785/10, Sag 10/3365 49/132





Konverteres til 

DataHub portalløsning 

Flyttes uændret til 

DataHub portalløsning 

Webservice: 


Stamdata 

PandaService 



Netvirksomhed 

Hent 

afregningsbilag 

Figur 5-1: Oversigt over Selvbetjeningsportal 

Vedligehold 

stamdata 


Webform 

Bruger/rettighed 

Forretningslogik 

Hent 

afregningsbilag 

Webservice: 

Hent oplysning pr. CVR-nr 

CVR-register 

Anlægsejer 

Indberet 

rådighed 

Indberet 

servicebesøg 

Servicevirksomhed 

Ovenstående Figur 5-1 viser den overordnede opbygning af SBP, og brugerne af denne. Portalen 

har webservice integrationer til PandaService, hvorfra der hentes oplysninger om stamdata for 

produktionsanlæg, og afregningsbilag. Og fra CVR-registeret hentes adresseoplysninger på de 

ca. 5000 anlægsejere, der er oprettet i portalen. 

Brugerne på SBP er medarbejdere hos netvirksomhederne, hos de balanceansvarlige og anlægsejere 

(ejere af en vindmølle eller et værk). 

Brugerne oprettes, og deres rettigheder vedligeholdes af Energinet.dk. Brugerne kan på Selvbetjening 

se deres egne afregningsbilag, stamdata for de produktionsanlæg de ejer og evt. servicebesøg 

på deres vindmøller. 

Når Panda overfører nye afregningsbilag til SBP, modtager de berørte brugere en notifikation via 

e-mail om, at der er nye bilag. 

En del ejere af værker skal af hensyn til deres afregning, dagligt indberette om deres anlæg er 

til rådighed for markedet. Denne indberetning af rådighed, sker via funktioner i SBP. 

Virksomheder, der servicerer vindmøller i Danmark, skal i portalen indberette datoen for servicebesøg, 

de har foretaget på de enkelte vindmøller, og datoen for det næste planlagte servicebesøg 

skal registreres. 

Portalens database og forretningslogik skal genbruges ved integrationen, så integrationen vedrører 

altså udelukkende skærmbilleder og brugerstyringen. 

Dok. 31785/10, Sag 10/3365 50/132



Integration mellem eksisterende SBP funktion og brugergrænseflade i DataHub'en vil være baseret 

på WCF (Windows Communication Foundation). Energinet.dk leverer et færdigt API, som 

denne del af brugergrænsefladen baseres på. 

For at give et overblik over systemet, gennemgås i næste afsnit skærmbillederne fra systemet, 

og efterfølgende et kort overblik over applikationsstrukturen. 

5.5.1 Skærmbilleder – menuoversigt 

Til forståelse af funktionaliteten vises efterfølgende skærmdumps af relevante skærmbilleder fra 

SBP, som ønskes integreret i DataHub'en. 

Alle brugere til SBP er tildelt rettigheder iht. deres rolle i el-markedet. Efter indlogning vises en 

oversigt over de menupunkter, som brugeren har rettigheder til. 

Menuoversigten har følgende punkter med tilhørende skærmbilleder: 

• Stamdata - vindmølle- og værksdata 

• Rådighed - indmelding af rådighedsdage for værker 

• Dokumenter - afregningsbilag m.m. 

• System - konfigurationer, logs m.m. 

5.5.1.1 Stamdata 

5.5.1.1.1 Produktionsanlæg oversigt 

Produktionsanlægs oversigten viser alle el-producerende anlæg, som er registreret hos Energinet.dk. 

Brugerne kan kun se de anlæg, som de har rettigheder til, f.eks. hvis de: 

Ejer en vindmølle eller værk, er netvirksomhed for anlægget, er en servicevirksomhed etc. 

Dok. 31785/10, Sag 10/3365 51/132



Skærmbilledet har mange filtreringsmuligheder, og det er valgfrit, om afmeldte anlæg ønskes 

vist i oversigten. På siden er der også mulighed for at danne en Excel fil over fremsøgte anlæg. 

Ved oprettelse kan der gemmes data for et anlæg i en 'kladde', således at brugeren på et senere 

tidspunkt kan afslutte redigeringen og indsende data for anlægget. 

Når en bruger har oprettet/redigeret et anlæg i SBP, vises en lille rød trekant ved 'Navn'. Trekanten 

fjernes, når rettelsen er foretaget i Panda, og SBP er opdateret med disse data (se Figur 

5-1: Oversigt over Selvbetjeningsportal) 

Fra oversigten kan vælges et anlæg, og man kan se alle detaljer for dette i et nyt skærmbillede. 

5.5.1.1.2 Produktionsanlæg, stamdata for et anlæg 

Alle felter for et enkelt anlæg vises og brugerens rettigheder bestemmer, om data kan redigeres 

eller om det kun er visningsfelter. Stamdata er grupperet under faneblade, men de kan også 

vises i listeform. På felterne er der forskellig funktionalitet, f.eks.: 

• GSRN nummer tildeles automatisk af SBP ved oprettelse af et anlæg. 

• Der er validering på en del af felterne, f.eks. for: Syntaks, krydsvalidering, obligatorisk udfyldning, 

grænseværdier m.m. 

• Validering af CVR-nummer mod CVR-registeret online i skærmbilledet. Relevante felter udfyldes 

automatisk med data. 

• Har en bruger oprettet/redigeret stamdata for et anlæg og gemmer disse, bliver der sendt 

en mail til brugerens egen mailadresse og til Energinet.dk. 

Disse stamdata opdateres derefter manuelt i Panda af Energinet.dk. En gang dagligt opdateres 

alle Panda stamdata med PandaService. 

Dok. 31785/10, Sag 10/3365 52/132



Ved klik på 'Historik' vises anlæggets forskellige gyldighedsperioder. Der kan også her vælges at 

se detaljer for anlægget i et nyt skærmbillede. 

5.5.1.1.3 Vedligehold ændringer 

I skærmbilledet kan systemadministrator se alle oprettelser, ændringer eller kladder på anlæg, 

der er foretaget i SBP. Systemadministrator kan efter behov vælge at køre en 'roll back' pr. 

transaktion ved at slette disse data i oversigten. 

Dok. 31785/10, Sag 10/3365 53/132



5.5.1.1.4 CVR-data rapport 

Det er muligt at kontrollere CVR-nummer mod CVR-registeret for ejere af anlæg. 

Kontrollen kan udføres pr. netområde, for vindmøller og/eller værker eller på kortnavn for anlæg. 

Resultatet af kontrollen, SBP data kontra CVR data med markering af forskelle, vises i en 

Excel-fil på skærmen eller sendes pr. mail til systemadministrator. 

Kontrollen køres som batch job én gang ugentligt for alle anlæg i SBP. 

5.5.1.1.5 Oversigt over servicevirksomheder 

Oprettelse af godkendte servicevirksomheder, som derefter har ret til at indberette servicebesøg 

for vindmøller. 

5.5.1.1.6 Indlæs servicebesøg 

En Servicevirksomhed kan levere en Excel-fil med data for sine servicebesøg hos vindmøller i 

stedet for at indberette data manuelt. Denne fil indlæses i SBP og gemmes i databasen. 

Dok. 31785/10, Sag 10/3365 54/132



5.5.1.1.7 Servicebesøg oversigt 

Oversigten indeholder alle vindmøller, som er registreret i SBP. 

Brugeren finder den relevante vindmølle og trykker 'Indberet', hvorefter et skærmbillede til indtastning 

vises. 

I Servicebesøg indberetning skærmbilledet indtastes dato for aktuelt servicebesøg og dato for 

næste planlagte besøg. Data gemmes i databasen og er nu tilgængelige i servicebesøg oversigten. 

5.5.1.2 Rådighed 

5.5.1.2.1 Rådighedsoversigt 

Rådighedsoversigten viser alle værker og anlæg, som af hensyn til deres afregning, skal indberette 

om deres anlæg er til rådighed for markedet. Brugeren kan kun se de anlæg, der er rettigheder 

til og vælger her hvilket anlæg, der ønskes indberettet for (Indberet rådighed). 

Dok. 31785/10, Sag 10/3365 55/132



5.5.1.2.2 Indberetning af rådighedsdage for anlægget 

Her indtastes hvilke dage pr. måned anlægget ikke har været til rådighed i den forgangne måned 

og data gemmes. 

5.5.1.2.3 Rådighedsskema årsoversigt 

Oversigt over indberettede dage i et angivet år, hvor anlægget ikke har været til rådighed. 

5.5.1.2.4 Rådigheds godkendelse 

Ved at angive en skæringsdato fremfindes de anlæg, som mangler at blive godkendt. Systemadministrator 

markerer herefter anlæggene, som kan godkendes. 

Dok. 31785/10, Sag 10/3365 56/132



5.5.1.2.5 Rådigheds indberetning 

For en given måned hentes status for alle anlægs rådighedsdata. Der markeres, hvilke anlæg 

som ønskes sendt til Panda. 

5.5.1.2.6 Rådighedsrykker 

Der angives en skæringsdato, hvorefter der vises, hvilke anlæg som mangler indberetning før 

skæringsdatoen. Systemadministrator vælger hvilke anlæg, der skal sendes en rykker til, og indtaster 

en tekst til mailen. Derefter hentes tilhørende mailadresser til de brugere, som er tilknyttet 

disse anlæg. Disse vises i et nyt skærmbillede til kontrol. 

Dok. 31785/10, Sag 10/3365 57/132



5.5.1.2.7 Oversigt over udedage 

Oversigt som viser indberettede udedage pr. anlæg - opdelt pr. år og pr. måned 

5.5.1.2.8 Driftsoversigt for værket 

Driftsoversigt pr. værk, viser de beregnede, akkumulerede data som er indsendt til Panda. 

Dok. 31785/10, Sag 10/3365 58/132



5.5.1.3 Dokumenter 

5.5.1.3.1 Dokument oversigt 

Her kan anlægsejere, netselskaber og balanceansvarlige se deres afregningsbilag som pdf-filer. 

Dokumenterne er uploadet fra PandaService via en webservice. 

5.5.1.3.2 Nyt dokument 

Det er muligt manuelt at uploade et dokument til SBP. Der skal angives, hvilken gruppe dokumentet 

skal tilhøre, hvilken periode, om det skal godkendes automatisk, og i hvilken sti dokumentet 

ligger. 

Dok. 31785/10, Sag 10/3365 59/132



5.5.1.3.3 Udsende dokument notifikation 

Når der er uploadet nye dokumenter til SBP, kan der sendes en notifikation via mail til relevante 

brugere. Modtagere af notifikationen er brugere, som har rettigheder til at se de nye dokumenter. 

5.5.1.4 System 

5.5.1.4.1 Email log 

Viser hvilke kvitteringer, nye password m.m. som er sendt fra SBP via mail pr. en given dato. 

Dok. 31785/10, Sag 10/3365 60/132



5.5.1.4.2 Aktivitetslog 

Viser hvilke aktiviteter der er sket på SBP, grupperet pr. handling. Logning af bruger login, fejl 

ved indlogning og indberetning af rådighed. 

5.5.1.4.3 Dokument konfiguration 

I oversigten findes alle dokumenttyper i SBP. Her kan systemadministrator konfigurere hvilke 

brugerroller, som må se de enkelte dokumenttyper. 

Dok. 31785/10, Sag 10/3365 61/132



5.5.1.4.4 Generér GSRN numre 

Systemadministratoren har her mulighed for at hente og vise GSRN numre i SBP uden at oprette 

anlæg. Tildeling af GSRN sker kun i SBP for at sikre éntydigheden. 

5.5.2 Applikation 

Energinet.dk's selvbetjeningsportal er bygget som en webapplikation med anvendelse af CMS 

2002 til håndtering af applikationens sidestruktur De to følgende figurer illustrerer applikationsopbygningen. 

Figur 5-2: Applikationsopbygning af SBP 

Dok. 31785/10, Sag 10/3365 62/132



Figur 5-3: Nuværende arkitektur tegning 

Som ovenstående Figur 5-3 illustrerer, er applikationen bygget som en traditionel ASP.NET web 

applikation, med udgangspunkt i et standard Microsoft teknologi skema. 

Dok. 31785/10, Sag 10/3365 63/132



5.5.3 Kravtabel til Selvbetjeningsportalen 

Krav 

ID 

Kravtype 

MK/K/O 


03-115 O Integration af Selvbetjeningsportal Webform og brugerstyring fra den eksisterende 

Selvbetjeningsportal ønskes integreret i Data- 

Tabel 5-3: Selvbetjeningsportalen – Kravtabel 

Hub-portalen. Formålet er at opnå en fælles 

brugerstyring, og at brugerne kun oplever én 

portal hos Energinet.dk. 

Alle skærmbilleder skal have samme indhold 

som i den eksisterende Selvbetjeningsportal. 

Det er kun den del af Selvbetjeningsportalen 

der vedrører el, der ønskes integreret. 

Dok. 31785/10, Sag 10/3365 64/132



6. Funktionskrav til DataHub’en 



Stamdata 


Portal 


Rapportering 

Måledata 

Dataudtræk 








Testcases 



Testhistorik 





Platform 


Sikkerhed 

Datamigrering 

I dette afsnit beskrives de specifikke krav til DataHub funktionaliteten. 

6.1 Understøttelse af forretningsprocesser (BRS) 

Alle forretningsprocesser beskrevet i "Forretningsprocesser for det danske elmarked" skal understøttes 

af DataHub, og Aktørtestsystemet skal kunne simulere disse processer i forbindelse med 

test af aktørernes IT-systemer. 

Forretningsprocesserne er beskrevet enkeltvis, og udfordringen med at udarbejde løsninger på 

evt. konflikter mellem flere samtidige processer skal løses i designfasen i et samarbejde mellem 

leverandøren og Energinet.dk. 

Bemærk, at forretningsprocessen "BRS-011: Fejlagtig flytning" er en manuel proces, og derfor 

ikke indgår i kravtabellen. 

6.1.1 Forretningsprocesser (BRS) kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


Dok. 31785/10, Sag 10/3365 65/132



Krav 

ID 

Kravtype 

MK/K/O 

03-116 K BRS-001: Leverandørskift 

03-117 K BRS-002: Leveranceophør 

03-118 K BRS-003: Håndte- 


ring af fejlagtigt leverandørskift 

03-119 K BRS-004: Oprettelse 

af målepunkt 

03-120 K BRS-005: Anmodning 

om stamdata 

03-121 K BRS-006: Fremsendelse 

af stamdata 

03-122 K BRS-007: Fraflytning 

- meldt til netvirksomheden 

03-123 K BRS-008: Tilflytning 

- meldt til netvirksomheden 

03-124 K BRS-009: Tilflytning 

- meldt til elleverandøren 

DataHub'en modtager og processerer anmodning om skift af 

elleverandør fra en elleverandør. 

DataHub'en skal understøtte funktionerne beskrevet i BRS-001. 

DataHub'en modtager og processerer anmodning om stop af 

leverance fra en elleverandør. 


DataHub'en modtager og processerer anmodning om fejlagtigt 

leverandørskifte fra en elleverandør. 


DataHub'en modtager og processerer anmodning om oprettelse 

af et nyt målepunkt fra en netvirksomhed. 


DataHub'en modtager og besvarer en anmodning om stamdata 

for et målepunkt fra en elleverandør eller en netvirksomhed. 


DataHub'en modtager stamdata for et målepunkt fra en netvirksomhed 

og videresender disse. 


DataHub'en modtager fra en netvirksomhed meddelelse om 

fraflytning af en kunde på et målepunkt og processer dette. 


DataHub'en modtager fra en netvirksomhed meddelelse om 

tilflytning af en ny kunde på et målepunkt og processer dette. 


DataHub'en modtager fra en elleverandør meddelelse om tilflyt- 

ning af en ny kunde på et målepunkt og processer dette. 


Dok. 31785/10, Sag 10/3365 66/132



Krav 

ID 

Kravtype 

MK/K/O 


03-125 K BRS-010: Fraflytning 

- meldt til elleverandøren 

03-126 K BRS-012: Skift af 

afregningsform 

03-127 K BRS-013: Afbrydelse 

og genåbning af målepunkt 

03-128 K BRS-020: Forbrugsopgørelse 

for skabe- 

lonafregnetmålepunkt 03-129 K BRS-021: Fremsendelse 

af måledata for 

et målepunkt 


af andelstal 


af beregnede 

tidsserier 

03-132 K BRS-024: Anmodning 

om historiske 

data 

03-133 K BRS-025: Anmod- 

ning om måledata 

DataHub'en modtager fra en elleverandør meddelelse om fraflytning 

af en kunde på et målepunkt og processer dette. 


DataHub'en modtager og processer en meddelelse fra en 

netvirksomhed om skift af afregningsform for et målepunkt. 


DataHub'en modtager og processerer en meddelelse fra en 

netvirksomhed om afbrydelse eller genåbning af et målepunkt. 


DataHub'en modtager forbrugsopgørelse for et målepunkt fra 

netvirksomheden og videreformidler dette. 


DataHub'en modtager måledata for et målepunkt fra netvirksomheden 

og videreformidler disse. 


DataHub'en fremsender beregnede andelstal til relevante aktører. 


DataHub'en fremsender resultatet af tidsserieberegninger til 

relevante aktører. 


DataHub'en modtager og besvarer en anmodning om måledata 

for et målepunkt fra en elleverandør. 


DataHub'en modtager og besvarer en anmodning om måledata 

for et målepunkt fra en elleverandør eller netvirksomhed. 


Dok. 31785/10, Sag 10/3365 67/132



Krav 

ID 

Kravtype 

MK/K/O 


03-134 K Forretningsprocesser 

via portal 

03-135 K Visning af status for 

processer 

03-136 K Konflikt mellem parallelle 

processer 

Tabel 6-1: Markedsprocesser kravtabel 

Alle forretningsprocesser beskrevet i "Forretningsprocesser for 

det danske elmarked" skal, hvis muligt og relevant, kunne gennemføres 

via sider i portalløsningen. (jf. de ovenstående krav i 

tabellen) 

Processerne skal udføres præcis med samme funktioner og kontroller 

som hvis indmeldt via EDI. 

F.eks. skal det være muligt at oprette et målepunkt (BRS-004) 

via webportalen, mens fremsendelse af andelstal (BRS-022) 

ikke er relevant. 

Aktørerne skal via webportalen kunne se aktuelle status på de 

processer, der vedrører den aktuelle aktør. 

En elleverandør skal f.eks. kunne se, at han har initieret en le- 

verandørskifteproces, og at status for processen lige nu er at 

der afventes en måleraflæsning fra netvirksomheden. Skærmbilledet 

skal tage hensyn til de gældende rettigheder, så en 

netvirksomhed f.eks. ikke kan spore hvorfra en leverandørskifteproces 

er initieret. 

Leverandøren skal i et samarbejde med Energinet.dk analysere 

evt. mulige konflikter mellem flere samtidige parallelle forretningsprocesser, 

og udarbejde løsninger for disse konflikter. 

Dok. 31785/10, Sag 10/3365 68/132



6.2 Samlet datamodel 

Aktør 

Aktør 

GLN 

Navn 

CVR 

Kon Kon c c erna erna k k tør 

tør 

1 * 

Aktør ID 

AktørIDformat 

CVR/ P 

Navn 

Adresse:Type sammensat adresse 

Webadresse 

EDI godkendt 

It-system kan lukkes 

Ønkes fejlrapport 

Tidspunkt for lukning 

Lukningstidspunktskode 

Tidspunkt for dannelse af fejlrapport 

Fejlrapportstidspunktskode 

1 

* 

0..1 

Balanc Balanc e e ansv ansv arlig 

arlig 

Prisområde 

Prisområde 

Prisområde Balanc Balanc e e - 

- 

Prisområdekode an an sv sv arsfun arsfun tion 

tion 

Prisområdenavn BA funktion 

* 

* 

* 

0..1 

N Net et et områd områd e 

e 

Netområde_nr 

Netområde_navn 

Obligatorisk grænse 

1 

Fra 

* 

Til 

Samle Samle Samle -- 

- - 

ud ud v v ek ek slin slin gsmålepunk gsmålepunk t 

t 

Aflæsningsfrekvens 

Ik Ik k k eMP eMP t t idssse idssse riev riev æ æ rdi 

rdi 

* 

* 

0..1 

1 

* 

1 

1 

Består af 

* 

Udv Udv e e k k slingsmålep slingsmålep unk unk t 

t 

1 

1 

1 

* 

* 

3 

1 

1 

1 

UD UD UD V 

V 

tid tid sseriev sseriev æ æ rdi 

rdi 

1 

* 

M M ålep ålep unk unk t- 

t- 

Netområd Netområd e e e relation 

relation 

Fra_dato 

Til_dato 

1 

Netv Netv irk irk somh somh ed 

ed 

Markedsskæringsdato 

* 

Ellev Ellev era era ndør-BA- 

ndør-BA- 

Netområde Netområde rela rela rela tion tion 

tion 

Fra_dato 

* Til_dato 

Samle Samle -nettoa -nettoa fregne fregne t 

t 

måle måle punk punk t 

t 

Nettoafregningsgruppe 

Målepunktsart 

Brændselsart 

VærksGSRN 

PSO fritaget 

M M -målepu -målepu nk nk t 

t 

1 

* 

1 

Består af 

* 

Nettoa Nettoa fregne fregne fregne t 

t 

tid tid sseriev sseriev æ æ rdi 

rdi 

Figur 6-1: Samlet logisk datamodel 

* 

Valgt 

Valgt 

forsyn forsyn ingspligtig 

* 

ingspligtig 

Fra_dato 

Til_dato 

* 

* 

1 

Ellev Ellev erandør erandør 

erandør 

Forsyningspligtig 

1 

1 

Le Le v v eran eran c c epe epe riode 

riode 

Fra_dato 

Til_dato 

M M ålepunk ålepunk t 

t 

Målepunkt ID 

Gyldighedsdato 

1 Målepunktsadresse:Type sammensat adresse 

Tilslutningsstatus 

Indsendte værdier skal tjekkes 

Basalt målepunkt 

Webadgangskode 

T T ek ek nisk nisk målep målep unk unk unk t 

t 

VE-Samle VE-Samle - 

- 

produk produk tionsmå tionsmå lepu lepu nk nk t 

t 

VE- VEVE- produk produk tionsmå tionsmå lepu lepu nk nk t 

t 

1 

* 

1 

Består af 

* 

VE 

VE 

tid tid sseriev sseriev ææ æ æ rdi 

rdi 

* 

Kon Kon Kon tak tak top top lysnin lysnin g 

g 

Kontaktoplysninger:Type sammensat kontaktoplysning 

Kontaktoplysningsfunktion 

* 

0..1 

Samle Samle - 

- 

analysemålepun analysemålepun k k t 

t 

Består af 

* 

Ana Ana lysemåle lysemåle punk punk t 

t 

1 

* 

1 

Ana Ana lyse lyse 

lyse 

tid tid sseriev sseriev ææ æ rdi 

rdi 

Person 

Person 

Firma 

Firma 

Navn 

CVR 

Adresse:Type sammensat adresse Navn 

Fødselsdato 

Adresse:Type sammensat adresse 

PID 

Rolle 

1 

* 

1 

Person- 

Person- 

Målep Målep unk unk tre tre lation 

lation 

Fra_dato 

Til_dato 

Fo Fo rbrug 

rbrug 

tid tid tid sseriev sseriev æ æ rdi 

rdi 

* 

Fo Fo rbrugsmålep rbrugsmålep unk unk t 

t 

Forventet årsforbrug 

DE Branchekode 

Over 63A 

Samle Samle -forbrug -forbrug s 

s 

målepunk målepunk t t - - T T ime 

ime 

Fo Fo rbrugsmålep rbrugsmålep unk unk unk t t - 

- 

time time 

time 

Tids Tids serieværdi 

serieværdi 

Tid 

Værdi 

Status 

1 

Består af 

* 

Afregning Afregning småle småle småle punk punk t 

t 

Nettoafregningsgruppe 

Fo Forbrugsmålep rbrugsmålep rbrugsmålep unk unk t t - 

- 

Sk Sk abelo abelo n n - - Fje Fjernaflæ rnaflæ rnaflæ st st 

st 

Indsendelsefrekvens til DataHub 


1 

* 

MM M MP P P tidsseriev tidsseriev æ æ rd rd i 

i 

Produkt 

* 

* 

Samle Samle - 

- 

pro pro pro duk duk tionsmålepu tionsmålepu nk nk t 

t 


Blokeret for automatisk lev. skift 

Fo Forbrugsmålep rbrugsmålep rbrugsmålep unk unk unk t t - 

- 

Sk Sk a a belo belo n n - - Manuel Manuel aflæ aflæ st st 

st 

Prod Prod uk uk tio tio n 

n 

tidsseriev tidsseriev tidsseriev ææ æ æ rdi 

rdi 

T T id id sseried sseried efinition 

efinition 

TS_ID 

1 

TS_Type 

Opløsning 

Enhed 

Matematisk type 

Dok. 31785/10, Sag 10/3365 69/132 

1 

Firma Firma - 

- 

M M ålep ålep unk unk tre tre latio latio nn 

n n 

Fra_dato 

Til_dato 

{ Person eller Firma } 

Fo Fo rbrugsmålep rbrugsmålep unk unk t t -- 

- 

sk sk abe abe lon 

lon 

1 

Fo ForbrugsMP rbrugsMP rbrugsMP - - - sk sk ab ab elon 

elon 

tid tidsseriev sseriev sseriev æ æ rdi 

rdi 

Sluttid 

1 

* 

* 

* 

Produk Produk Produk tio tio nsmålepunk nsmålepunk nsmålepunk t 

t 

1 

* 

1 

Består af 

Samle Samle -forbrugsmåle -forbrugsmåle punk punk t t - 

- 

Sk Sk a abelon belon 

1 

belon 

Aflæsningsdag (1..12) 

Forbrug ud over obligatorisk grænse tilladt 

Består af 

1 

* 

*



Bemærk, at dette er den samlede logiske datamodel og som sådan ikke skal betragtes som et 

bud på en fysisk tabelstruktur. 

Bemærk også, at de beskeder, der fremsendes via EDI med stamdata for et målepunkt, vil 

rumme fællesmængden af attributter for alle målepunkstyper. Som eksempel kan nævnes, at 

når der indsendes stamdata for et produktionsmålepunkt, er attributten DE branchekode ikke 

relevant, men kan alligevel findes i beskeden. 

I datamodellen (se Figur 6-1: Samlet logisk datamodel) optræder entiteterne Balanceansvarlig, 

Elleverandør og Netvirksomhed som sub-entitteter af den generelle entitet Aktør. I daglig tale 

opfattes entiteterne ofte som helt selvstændige entiteter. Nogle selskaber er også koncernforbundne. 

Bemærk: Nogle firmaer optræder i flere roller. F.eks. er "DONG Energy Frederiksberg Elnet A/S" 

både netvirksomhed og handelsbalanceansvarlig på det tidspunkt, hvor dette dokument skrives. 

6.3 Stamdata 

6.3.1 Stamdata, opdateret på baggrund af markedsprocesser 

6.3.1.1 Målepunkter og målinger 

I figuren over den samlede datamodel svarer dette til entiteterne under Målepunkts-entiteten 

(Målepunktsentiteten inklusiv). Yderligere vil stamdata for Afregningsmålepunkter rumme data 

for op til 2 disponenter (navn, adresse) og også elleverandør ID og netområde ID m.m. Dette 

anses også for stamdata til målepunktet, og det er i den logiske datamodel realiseret, ikke ved 

direkte attributter, men gennem associationer. 

Målepunkter og relaterede entiteter skal kunne vedligeholdes både gennem EDI-kommunikation 

og gennem webportalen. Set fra DataHub'ens synspunkt er det de samme processer, der aktiveres 

uanset om vedligeholdet sker gennem EDI eller webportal. DataHub'en skal have skærmbilleder 

under den generelle webportal, som kan varetage CRUD-funktioner (Create, Read, Update, 

Delete) for disse entiteter. 

Se yderligere i forskriften for stamdata "Pseudo-forskrift I - Stamdata". 

Der er en række markedsprocesser, der basalt set manipulerer med entiteten Målepunkt. 

Disse markedsprocesser findes i pseudo-forskrift H1. Se f.eks. Leverandørskifte, Flytning samt 

udløb af kontrakt, og andre. 

Disse processer vil i nogle tilfælde ændre på målepunktets tilstand (se Figur 6-2). 

Disse markedsforskrifter er brudt ned til en række BRS'er (processer) og RSM'er (datameddelelser) 

og disse kan potentielt alle påvirke Målepunkt og målinger. 

Ansvaret for vedligehold af disse stamdata er principielt altid netvirksomhedens, på nær enkelte 

undtagelser. Et eksempel er processen BRS-009, hvor tilflytning tilmeldt til elleverandør vil medføre 

at elleverandøren overskriver Disponentnavn og adresse. Et andet eksempel er feltet "Webadgangskode", 

der vedligeholdes af DataHub'en og som udveksles via EDI. Et tredje eksempel 

Dok. 31785/10, Sag 10/3365 70/132



er, at stamdata rummer felter, der overvejende vedligeholdes af DataHub'en og ikke udveksles i 

EDI-beskeder. F.eks. "Indsendte værdier skal tjekkes" som for Afregningsmålepunkter altid vil 

have værdien "Ja" og ikke skal vedligeholdes af netvirksomhederne. 

Måledata for målepunkter indsendes i form af tidsserier. Selve målingerne er ikke stamdata men 

til hvert sæt af målinger hører målingens stamdata, se entiteten Tidsseriedefinition. 

Igen er det vigtig at bemærke, at dette er den logiske model for tidsserier. Det der indsendes 

følger ikke præcist dette format. Se "Forretningsprocesser for det danske elmarked" bilaget med 

RSM'er (Requirements Specifications Mapping) herunder klassediagrammer. 

Stamdata[Tilslutnings 

status = 'Tilsluttet'] 

Tilflytning 

Cre Cre ate ate Mete Mete Mete ring ring Point 

Point 

Nyop Nyop Nyop rettet rettet 

rettet 


status = 'Tilsluttet'] 


status = 'Nyoprettet'] 

Skift elleverandør 


Fraflytning 

Ne Ne Ne dlagt 

dlagt 

T T ilsluttet ilsluttet 

Afbrud Afbrud t 

t 

Tilflytning Modtag måledata Tilflytning 

Figur 6-2: Tilstandsdiagram for et Målepunkt 

Stamdata 

Fraflytning 

Åbn målepunkt 

Afbryd målepunkt 

Fraflytning 

Destroy Destroy Metering Metering Point 

Point 

[Sidste registreret måling > x år] 


Fraflytning 


status = 'Nedlagt'] 

Tilflytning 

Fraflytning 

Inaktivt 

Inaktivt 

Dok. 31785/10, Sag 10/3365 71/132



6.3.1.2 Datavask 

DataHub'en skal, for at opfylde sit formål, som minimum kende alle elmålere (målepunkter) i 

Danmark identificeret ved et entydigt målepunkt ID (GSRN) på 18 cifre, deres forbrug og deres 

adresser. Yderligere skal alle afregningsmålere tilknyttes en disponent (kunde), som enten er en 

privat person eller en juridisk person (virksomheder). Disse kunder har selvsagt også en adresse. 

Kendskab til navn og adresse på nuværende og tidligere kunde er væsentlig i f.eks. flytteprocessen, 

hvor oplysninger, via DataHub'en, udveksles mellem elleverandør og netvirksomhed, 

der udsender aflæsningskort og slutopgørelser. Det er derfor af stor betydning for markedet generelt, 

at der kan ske en korrekt datavask. 

Bemærk: Som princip skal datafangst og validering ske hos de aktører, som har den daglige 

kontakt til kunderne, mens DataHub'en alene tilbyder hjælp til datavask. Datavasken skal altså 

ikke være en integreret del af alle udvekslinger af adresseoplysninger, men skal være en separat 

proces, som kan initieres af netvirksomheden eller elleverandøren, hvis og når det ønskes. 

Bemærk: At en given adresse oplyst af en kunde ikke kan valideres op i mod CVR / CPR betyder 

ikke nødvendigvis, at kundens oplysninger er forkerte. Der vil til stadighed være en gruppe af 

kunder / installationer, der er under flytning, har adresse i nyudstykninger, har tekniske adresser 

uden registrering i offentlige registre eller udenlandske adresser. DataHub'en skal også kunne 

håndtere sådanne adresser. 

DataHub'en har i datamodellen adresser opdelt som en sammensat type. Den følger i store træk 

formatet brugt i aws 6 . 

Typen "Type sammensat adresse" rummer følgende felter - her sorteret alfabetisk: 

• Bynavn 

• Dørbetegnelse 

• Etage 

• GML point 

• Husnummer 

• Kommunekode 

• Land 

• Postboks 

• Postdistrikt 

• Postnummer 

• Vejkode 

• Vejnavn 

Attributterne er selvforklarende, måske bortset fra Postdistrikt - Bynavn og GML point. Postdistrikt 

svarer til, hvad almindelige brugere vil kalde navnet på byen, f.eks. svarer postnummer 

7000 til postdistrikt Fredericia, mens Bynavn her er optionelt og svarer til bynavn2 (Snoghøj, 

6 “Adressewebservices ” http://www.ebst.dk/aws. 

Dok. 31785/10, Sag 10/3365 72/132



7000 Fredericia). GML point, skal bruges til udpegning af adressen på et kort og er reserveret til 

fremtidigt brug. 

I forbindelse med EDIFACT findes også et format Kodetadresse - se nærmere i "EDI transaktioner 

for det danske elmarked" et bilag til "Forretningsprocesser for det danske elmarked". 

6.3.1.2.1 Adresser på installationer 

En installation (~et målepunkt) har en adresse af typen "Type sammensat adresse", og netvirksomhederne 

skal, efter behov, kunne datavaske disse adresser ved hjælp af DataHub'en. Bl.a. 

vejkode. Bemærk dog at netvirksomhederne kan have mange målepunkter oprettet på veje 

uden vejkoder tilknyttet i forbindelse med nyudstykninger og lignende. 

6.3.1.2.2 Adresser for private kunder 

DataHub'en har felterne navn, adresse og evt. fødselsdato. Disse felter skal netvirksomhederne 

efter behov kunne datavaske på ved hjælp af DataHub'en op i mod CPR / aws eller tilsvarende. 

Når aktørerne engang i fremtiden er klar til at håndtere entydig identifikation af private, skal det 

ske via en model, hvor CPR ikke udveksles, men kun PID (Personligt ID) numre. DataHub'en er 

den eneste, der vil kende sammenhængen mellem CPR og PID. På basis af navn, adresse og evt. 

fødselsdato finder DataHub'en den eller de personer i CPR der matcher, netvirksomheden / elleverandøren 

godkender, at det er den kunde, der er identificeret, og DataHub'en udleverer et 

PID, som fremover benyttes som entydig identifikation af kunden. 

Fuldt gennemført vil det overflødiggøre webadgangskoder som stamdata på et målepunkt, give 

bedre muligheder for datavask og vil samtidig kunne give langt højere kvalitet i forbindelse med 

mange af processerne, f.eks. flytninger. 

6.3.1.2.3 Adresser og CVR for virksomheder 

Datavask af adresser er et tilbud til aktørerne. Datavasken skal ske op mod CVR 7 / aws eller tilsvarende. 

Der skal også ske en validering af CVR. 

6.3.2 Adgang til stamdata via webportal 

6.3.2.1 Målepunkter 

I datamodellen fremgår hvilke stamdata, der findes på et målepunkt, og de skal alle være mulige 

at fremfinde via en webform. 

Nedenstående figur viser en råskitse til opbygningen funktionaliteten af denne webform: 

7 “CVR - Forside,” www.cvr.dk 

Dok. 31785/10, Sag 10/3365 73/132



Søgekriterier 

Resultatliste 

Detailoplysninger 

Figur 6-3: Eks. på visning af stamdata for målepunkt. 

Ovenstående viser et eksempel på, hvorledes visning af stamdata for målepunkter kunne se ud. 

Figuren er baseret på skærmdumps fra Energinet.dk's Selvbetjeningsportal, med stamdata for 

produktionsanlæg. 

I den første webform "Søgekriterier" (øverst) angives søgekriterier for de målepunkter, man ønsker 

at se. Der skal være valglister, eller søgningerne skal kunne foretages med wildcard. Hvilke 

felter der skal være mulige at søge på, er afhængig af hvilke rettigheder brugeren som kalder 

webformen, har. 

Efter fremsøgningen vises søgeresultatet i en "Resultatliste", hvor der kun vises udvalgte felter 

af stamdata. Brugeren skal selv kunne vælge hvilke felter, der vises i listen. Der skal kun kunne 

vælges felter, som brugeren har ret til at se, f.eks. skal en bruger hos en netvirksomhed ikke 

kunne se feltet "elleverandør". 

Ved klik på et målepunkt, skal der linkes til en ny webform ("Detailoplysninger"), der viser alle 

detailinformationer for målepunktets stamdata, herunder også historik for disse. 

Fra "Resultatliste" skal det også være muligt at linke til en ny webform, hvor målepunktets måledata 

for en given periode vises. 

Dok. 31785/10, Sag 10/3365 74/132



6.3.2.2 Netvirksomheder og netområder 

Området er reguleret, idet man skal have bevilling fra Energistyrelsen til at drive netvirksomhed. 

De nuværende manuelle procedurer for at udstede disse tilladelser forventes opretholdt. 

Danmark er opdelt i ca. 85 geografiske netområder, og hvert netområde ejes af en netvirksomhed. 

Nogle netvirksomheder ejer mere end et netområde. 

Udviklingen i antallet af netvirksomheder går mod færre netvirksomheder, altså mod konsolidering. 

Antallet af netvirksomheder er lidt lavere end antallet af netområder. 

Det vurderes, at det ikke kan svare sig at lave strukturerede beskeder til ændringer af stamdata 

for disse entiteter. 

DataHub'en skal have skærmbilleder under den generelle webportal, som kan varetage CRUDfunktioner 

for disse entiteter. Både netvirksomhederne og DataHub'en skal kunne varetage vedligehold 

af disse entiteter. Den endelige fordeling af, hvilke attributter der kan/må vedligeholdes 

af hhv. netvirksomheden og DataHub'en, udestår. 

6.3.2.3 Elleverandører 

Området er reguleret, idet man fremover skal have tilladelse fra Energinet.dk til at drive elhandel. 


Det er svært at sige noget om udviklingen i antallet af elleverandører, men der vil nok ske en 

svag vækst. 

Det vurderes, at det ikke kan svare sig at lave strukturerede beskeder til ændringer af stamdata 

for denne entitet. 

DataHub'en skal have skærmbilleder under den generelle webportal, som kan varetage CRUDfunktioner 

for denne entitet. Både elleverandøren og DataHub'en skal kunne varetage vedligehold 

af denne entitet. Den endelige fordeling af, hvilke attributter der kan/må vedligeholdes af 

hhv. elleverandøren og DataHub'en, udestår. 

6.3.2.4 Balanceansvarlige 

Området er reguleret, idet man skal tegne kontrakt med Energinet.dk for at varetage balanceansvar. 


Antallet af aktive balanceansvarlige virksomheder i Danmark er ca. 50 og udviklingen er det 

svært at spå om, men der vil nok ske en svag reduktion af antallet pga. konsolidering. Det vurderes, 

at det ikke kan svare sig, at lave strukturerede beskeder til ændringer af stamdata for 

denne entitet. 

Dok. 31785/10, Sag 10/3365 75/132



6.3.3 Stamdata kravtabel 

Krav Kravtype 

MK/K/O 


03-137 K Webforms til stamdata for målepunkter 

03-138 K Webapplikation til stamdata for målepunkter 

03-139 K Elleverandør krav til webform til 

målepunktsstamdata 

03-140 K Kundens krav til webadgang til 

målepunktsstamdata 

Der skal i webportalen findes skærmbilleder, så 

markedets aktører og kunder selv kan se og 

vedligeholde relevante stamdata for målepunkter. 

Netvirksomheder skal kunne oprette og redigere 

stamdata for målepunkter tilhørende netvirk- 

somheden. 

Elleverandører skal kunne søge overordnede 

stamdata for alle målepunkter, og skal kunne se 

detailinformation for egne målepunkter. 

Elkunder skal kunne søge overordnede stamdata 

for egne målepunkter, og skal kunne se detailinformation 

for disse. 

DataHub'en skal tilbyde en webapplikation, såle- 

des at kunder på elleverandørens portal tilbydes 

ovennævnte funktionalitet. 

Elleverandøren skal via webforms specifikt 

kunne: 

Hente aftagenummer på indflytters kommende 

målepunkt ved søgning på målepunktets adresse 

Sortere målepunkter efter CVR-nummer (dette 

vil vise alle målepunkter for en koncernkunde) 

Kunden skal specifikt kunne se: 

- detaljerede stamdata for alle kundens målepunkter. 

- tidligere og kommende leverandørskift på alle 

kundens målepunkter. 

- kontaktinformation for netvirksomhed og elleverandør(er) 

for alle kundens målepunkter 

DataHub'en skal tilbyde en webapplikation, såle- 

des at kunder på elleverandørens portal tilbydes 


Dok. 31785/10, Sag 10/3365 76/132



Krav Kravtype 

MK/K/O 


03-141 K Webforms til opdatering af stamdata 

for aktører 

03-142 K Offentlige aktøroplysninger 

(aktørstamdataregister) 

03-143 MK Datavask af adresser for målepunk- 

ter, private og virksomheder 

Der skal i webportalen findes skærmbilleder, så 

markedets aktører (elleverandører, netvirksomheder, 

balanceansvarlige) selv kan vedligeholde 

egne relevante stamdata, iflg. Figur 6-1: Samlet 

logisk datamodel. 

Der skal på webportalens offentlige del, vises en 

oversigt over markedets aktører. Her skal vises 

udvalgte felter fra stamdata, f.eks. Navn, rolle, 

GLN/EIC nummer, kontaktoplysninger (adresse, 

e-mail, tlf.) o.l.. 

Datafangst og validering sker hos de selskaber 

som har direkte kontakt til kunderne, mens DataHub'en 

tilbyder hjælp til datavask. Datavasken 

skal altså ikke være en integreret del af alle 

udvekslinger af adresseoplysninger, men skal 

være en separat proces som kan initieres af 

netvirksomheden eller elleverandøren, hvis og 

når det ønskes. 

Datavasken skal foretages mod offentlige registre: 

CVR, CPR, Adressewebservice el.lign. 

Resultatet af datavasken skal være en differensliste, 

der viser de registrerede data i DataHub'en 

og differensen med det offentlige register. 

03-144 K Udbygning af datavaskfunktionalitet Kravene til funktionaliteten i datavask forventes 

03-145 MK Brug af CVR til identifikation af virksomheder 

03-146 K Brug af PID til entydig identifikation 

af private 

at øges efter idriftsættelsen af systemet, og det 

er derfor vigtigt at designet af datavasken er 

forberedt til en senere udvidet funktionalitet. 

Pga. den måde hvorpå datafangst sker hos 

netvirksomhederne, kan der ikke opnås dækkende 

identifikation af virksomheder baseret på 

CVR, men som minimum skal DataHub'en kunne 

afgøre, om et CVR nummer tilhører en eksiste- 

rende virksomhed. 

DataHub'en skal være forberedt på brug af PID 

til private kunder. Virksomheder identificeres 

ved hjælp af CVR. Når aktørerne er klar til at 

håndtere entydig identifikation af private, skal 

det ske via en model, hvor CPR ikke udveksles, 

men kun PID numre. DataHub'en er den eneste, 

Dok. 31785/10, Sag 10/3365 77/132



Krav Kravtype 

MK/K/O 


03-147 K Brug af geografiske koordinater i 

adresser 

Tabel 6-2: Stamdata - kravtabel 

6.4 Måledata 

der kender sammenhængen mellem CPR og PID. 

Datamodellen rummer en attribut, GML point, 

der pt. ikke skal indsendes af aktørerne. Det er 

ikke vigtigt, at det præcist er GML point der anvendes, 

men DataHub'en skal kunne håndtere 

geografiske angivelser i fremtiden. 

Den største transaktionsmængde og den største datamængde i DataHub'en vedrører måledata. 

Det er netvirksomhederne, der har dataansvaret for måledata, og pseudo-forskrift D1 beskriver 

roller, ansvar, pligter og processer vedrørende måledata. 

Når måledata er modtaget i DataHub'en fra netvirksomhederne, skal forbrugs- og produktionsmåledata 

videresendes til de relevante elleverandører. 

Netvirksomhederne skal via webportalen kunne definere simple beregningsoperationer, der skal 

foretages på de indsendte målinger, inden målingerne indgår i afregningen. Dette er beskrevet 

som virtuelle målepunkter i pseudo-forskrift D1. 

DataHub'en skal foretage simple beregninger på måledata, f.eks. summering pr. elleverandør, 

og beregningsresultatet skal udsendes til relevante aktører, f.eks. en balanceansvarlig. 

Af mere specielle beregninger, skal DataHub'en beregne andelstal, og saldoafregningen skal ligeledes 

foretages i DataHub'en. Saldoafregningen er beskrevet i pseudo-forskrift H2. 

Endelig skal DataHub'en beregne KPI'er for måledata, hvor der skal måles på kvaliteten af de 

indsendte målinger, dvs. overholdelse af tidsfrister for indsendelser og korrektioner til indsendte 

målinger. 

Bemærk, at der i daglig tale bruges betegnelserne tidsseriedata og måledata om samme begreb, 

og at måledata både kan være direkte målte værdier eller resultatet af en beregning. Måledata 

kan dække over energimålinger (kWh, MWh), effektmålinger (kW, MW) eller reaktive energimålinger 

(kVArh, MVArh), og tidsseriedata kan indeholde priser (øre/kWh, DKK/MWh, NOK/MWh 

osv.). 

6.4.1 Adgang til måledata via webportal 

Brugeren må kun kunne se måledata, som vedkommende er legitim berettiget til. F.eks. må en 

elleverandør kun se måledata for de målepunkter, han er elleverandør for, og kun for den perio- 

Dok. 31785/10, Sag 10/3365 78/132



de hvor elleverandøren har haft leverance til kunden (bortset fra i tilbudsfasen, hvor man kan få 

historiske måledata). 

Hvilke(t) målepunkt(er) der skal vises data for, kan f.eks. vælges via en webform, som vist i afsnit 

6.3.2.1. Der skal kunne vælges at se måledata for et eller flere målepunkter ud fra søgeresultatet. 

F.eks. ved at vælge én, flere eller alle målepunkter ved hjælp af valgbokse. Værdierne, 

der vises for et målepunkt, kan være resultatet af en beregning (virtuelt målepunkt). 

I webformen for måledata skal der som minimum kunne vælges: 

• Periode, der skal vises måledata for 

• Tidsopløsning - skal data vises i 5 minutters-, kvarters-, times- eller måneds opløsning 

eller summeret pr. døgn, uge, måned eller år. Målingens aktuelle tidsopløsning vises 

som default. 

Figur 6-4: Eksempel på visning af tidsseriedata 

Måledata for 2 målepunkter 

Ovenstående er et eksempel på, hvorledes visning af tidsseriedata for 2 målepunkter kunne se 

ud. (Figuren er baseret på skærmdump fra Energinet.dk's Panda system). 

6.4.2 Send måledata til tredje part 

Når en kunde har fremsøgt sine måledata for egne målepunkter, skal der være en let adgang til 

at sende de fremsøgte data til tredje part. Formålet er, at kunden kan fremsende sine måledata 

til f.eks. en energirådgiver for analyse af elforbruget. 

6.4.3 Måledata kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


Dok. 31785/10, Sag 10/3365 79/132



Krav 

ID 

Kravtype 

MK/K/O 


03-148 K Daglig modtagelse og kontrol af kvarters- 

og timeregistrerede måledata 

03-149 K Modtagelse og kontrol af registreringer 

fra skabelonafregnede forbrugsmålinger. 

03-150 K Modtagelse og kontrol af måledata for 

måneds- og kvartalsaflæst produktion 

DataHub'en skal dagligt modtage kvarters- og 

timeregistrerede data, og udføre kontrol af modtagne 

data som beskrevet i pseudo-forskrift D1, 

afsnit 4. 

DataHub'en skal modtage og kontrollere registreringer 

fra skabelonafregnede forbrugsmålepunkter, 

som beskrevet i pseudo-forskrift D1, afsnit 

5.1. 

DataHub'en skal modtage og kontrollere måledata 

for måneds- og kvartalsaflæste produktionsanlæg, 

som beskrevet i pseudo-forskrift D1, afsnit 

03-151 MK Historik for måledata Ved genindsendelse af måledata, skal tidligere 

data gemmes og disse skal kunne fremfindes. 

5.2. 

Der skal således være fuld historik (revisions- 

spor) på alle transaktioner, der vedrører måledata. 

03-152 K Fiksering og refiksering af måledata Som beskrevet i pseudo-forskrift D1 (afsnit 4.3), 

skal DataHub'en på 5.dagen efter driftsdøgnet 

03-153 K Håndtering af åbne og lukkede systemer 

fiksere (fastfryse) måledata, og efter 3 måneder 

foretage en refiksering (se pseudo-forskrift D1, 

afsnit 4.5.1). 

DataHub'en skal kunne håndtere disse processer. 

Aktørerne kan vælge at modtage korrektioner på 

måledata (åben), eller alternativt at modtage 

mail fra DataHub'en om korrektioner (lukket), 

som beskrevet i pseudo-forskrift D1, afsnit 4.4.1. 

DataHub'en skal kunne håndtere disse processer. 

03-154 K Rykkere og fejlrapporter DataHub'en skal som beskrevet i pseudo-forskrift 

D1, bilag 3, danne og udsende rykkere og fejl- 

rapporter under hensyntagen til de muligheder 

aktøren har for styring af dette, beskrevet i 

pseudo-forskrift D1, afsnit 4.4.1. 

03-155 K Bestilling af manglende målinger Som beskrevet i pseudo-forskrift D1, afsnit 

4.4.1.og 4.4.2 skal aktørerne via webportalen 

Dok. 31785/10, Sag 10/3365 80/132



Krav 

ID 

Kravtype 

MK/K/O 


03-156 K Webform til visning af måledata for 

aktører 

03-157 K Webadgang til visning af måledata for 

kunder 

03-158 K Afsendelse fra kunde af fremsøgte 

måledata 

Tabel 6-3: Måledata - kravtabel 

6.5 Beregningsfunktion 

6.5.1 Statiske beregninger 

kunne bestille genfremsendelse af målinger. 

Bestillingsskærmbilledet skal tilbyde en let fremsøgning/gruppering 

af målinger, bl.a. med mulighed 

for "marker alle" til genfremsendelsen. 

Systemet skal tilbyde en webform til visning af 

flere målinger, med en funktionalitet som skitseret 

i afsnit 6.4.1 

Webformen skal kunne tilbyde aktører en profes- 

sionel tilgang til egne måledata. 

Kunden skal have mulighed for at se egne målinger, 

med en funktionalitet som skitseret i afsnit 

6.4.1 

DataHub'en skal tilbyde en webapplikation, således 

at kunder på elleverandørens portal tilbydes 


Når en kunde har fremsøgt sine måledata, skal 

det være muligt for kunden at sende de fremsøgte 

data i en mail til en valgfri mailadresse. 

Måledata vedhæftes i mailen som en fil i regne- 

arksformat, xml eller csv. 

Kunden skal have mulighed for at give en mailadresse 

hvortil data skal fremsendes, og der skal 

være mulighed for at medsende en tekst i mailen. 

DataHub'en skal tilbyde en webapplikation, således 

at kunder på elleverandørens portal tilbydes 


Nogle målinger skal der foretages beregninger på, inden de kan indgå i den videre afregning. 

Dok. 31785/10, Sag 10/3365 81/132



Et eksempel på en sådan beregning, kan vises ved de målinger, der foretages ved et produktionsanlæg. 

Kollektive forsyningsnet 

Forbrugssted 

M3 

M0 

M1 

Øvrigt 

forbrug 

~ 

Egetforbrug til elproduktion 

Figur 6-5: Nettoafregnet produktionsanlæg 

Ved kunden måles M0, M1 og M3, som illustreret i Figur 6-5, og kundens forbrug skal beregnes 

som summen af M0+M1, og denne beregning skal defineres og foretages i DataHub'en. 

Beregningerne defineres og udføres på tidsserierne, og der vil være behov for at kunne udføre 

nedenstående beregningsfunktioner, beskrevet i Tabel 6-4: Beregningsfunktioner. 

Argumenterne til en beregningsfunktion kan enten være to tidsserier (x og y), en tidsserie (x) og 

resultatet fra en anden beregning (y), eller en tidsserie (x) og en konstant defineret værdi (y). 

Beregningerne skal altid udføres for hvert element (tidsstempel) i tidsserierne. F.eks. skal "Multiplicer" 

funktionen udført på to timestidsserier for et døgn, multiplicere de 2 x 24 timesværdier, 

og ikke multiplicere de to tidsseriers døgnsummer. 

Funktion Beskrivelse 

Adder(x,y) Adder værdierne i x med værdierne i y 

Subtraher(x,y) Subtraher værdierne i x med værdierne i y 

Multiplicer(x,y) Mulitiplicer værdierne i x med værdierne i y 

Divider(x,y) Divider værdierne i x med værdierne i y 

Størst(x,y) Der vælges den største værdi af x eller y 

Mindst(x,y) Der vælges den mindste værdi af x eller y 

Afrund(x,k) Afrund x til k antal decimaler 

Absolut(x) Absolut af værdien x 

Dok. 31785/10, Sag 10/3365 82/132



Funktion Beskrivelse 

Tærskel indenfor(x,k1,k2) Værdien x vælges, hvis denne ligger indenfor det interval der er 

angivet i k1 og k2 - ellers sættes værdien til nul. 

Tærskel udenfor(x,k1,k2) Værdien x vælges, hvis denne ligger udenfor det interval der er angivet 

i k1 og k2 - ellers sættes værdien til nul. 

Tabel 6-4: Beregningsfunktioner 

Definition af formler skal kunne gøres af Energinet.dk og af brugere hos netvirksomhederne. 

6.5.2 Dynamiske beregninger 

Der skal også være mulighed for at definere mere dynamiske beregninger. F.eks. skal man kunne 

opsætte en beregning med: "summér alt forbrug i netområde A som er tilknyttet elleverandør 

B". En sådan beregning skal ud fra stamdata på de enkelte målepunkter udlede, hvilke af disse 

målepunkter, der skal indgå i beregningen. Beregningen skal naturligvis tage hensyn til, at 

stamdata for de enkelte målepunkter varierer over tid. 

6.5.3 Automatisk beregning - nettoafregnede værker 

For de såkaldte nettoafregnede produktionsanlæg, skal DataHub'en ud fra de modtagne målinger 

på et sådant anlæg, benævnt M1, M2 og M3, beregne målingerne "Produktion MP" og "Forbrug 

MP", som skal indgå i afregningen. Beregningerne kan opsættes manuelt som formler (statiske 

beregninger), men der ønskes belyst muligheden for, at DataHub'en udfører en automatisk beregning, 

da beregningsformlerne kan udledes af stamdata for målepunkterne. 

Nedenfor vises en sammenhæng mellem stamdata for målepunkterne, og hvorledes "Produktion 

MP" og "Forbrug MP" beregnes. En fuldstændig beskrivelse af principperne bag nettoafregningsmodellen 

kan ses i bilag til forskrift E: "Retningslinjer for nettoafregning af egenproducenter". 

Gruppe Installations form Tidsopløsning M1 M2 M3(+M0) Produktion MP Forbrug MP Egenproduktion EP 

Grp. 1 

Installationstilsluttet 

Direkte 

Time 

X 

X 

X X 

X 

M1 

M1 

M1-M2+M3 

M3 

M1-pos(M2-M3) 

M1-pos(M1-M3) 

Grp. 2 

Installationstilsluttet 

Direkte 

Time 

X 

X 

X X 

X 

pos(M2-M3) 

pos(M1-M3) 

-1*neg(M2-M3) 

-1*neg(M1-M3) 

M1-pos(M2-M3) 

M1-pos(M1-M3) 

Grp. 4 Installationstilsluttet Time 

X X 

X 

X 

X 

M2 

M2 

M3 

M3 

M1-M2 

- 

Grp. 5 Installationstilsluttet Time 

X X 

X 

X 

X 

- 

- 

M3 

M3 

M1-M2 

- 

Grp. 6 Installationstilsluttet Årsafregnet 

X X 

X 

X 

X 

pos(M2-M3) 

pos(M2-M3) 

-1*neg(M2-M3) 

-1*neg(M2-M3) 

M1-pos(M2-M3) 

- 

Bemærk: 

M1 og M2 målerne kan være måneds/kvartalsaflæste, men indgår med timesværdier via Energinet.dk's estimater. 

I nettoafregningsgruppe 4 og 5 må M3 måleren gerne være skabelonafregnet, da den ikke indgår i beregningen af egenproduktionen. 

Nettoafregningsgruppe 6 skal måske udvides med en model for timesafregnede kunder (er under udvikling) 

Figur 6-6: Sammenhæng mellem stamdata for målepunkterne, nettoafregning 

Dok. 31785/10, Sag 10/3365 83/132



6.5.4 Beregningsfunktion kravtabel 

Krav 

ID 

Krav- 

type 

MK/K/ 

O 


03-159 K Statiske beregninger på måledata Der skal findes mulighed for at definere beregninger 

på måledata med matematiske funktioner 

som beskrevet i afsnit 6.5.1 

03-160 K Periodisering af beregningsdefinitio- 

ner 

Det skal være muligt at definere periodiseringer 

i forbindelse med beregningsdefinitionen. F.eks. 

at et formelled i beregningen ikke skal være 

gyldigt efter et givet tidspunkt. 

03-161 K Dynamiske beregninger på måledata Det skal være muligt at definere dynamiske be- 

regninger som f.eks. : "summér alt forbrug i 

netområde A som er tilknyttet elleverandør B", 

som beskrevet i afsnit 6.5.2. 

03-162 K Webform til beregningsdefinitioner Der skal findes en webform, som på en logisk og 

overskuelig form kan anvendes til opsætning af 

beregningsdefinitioner. 

Formen skal tage hensyn til rettigheder, således 

at f.eks. en netvirksomhed kun kan medtage 

målinger i beregningen, som netvirksomheden 

har ansvaret for. 

03-163 K Definition af formler Definition af formler skal kunne defineres af 

03-164 K Automatisk beregning for nettoafregnede 

anlæg 

Tabel 6-5: Beregningsfunktion - kravtabel 

Energinet.dk og af brugere hos netvirksomhederne 

Der skal beskrives en løsning for automatisk 

beregning af forbrug og produktion for nettoaf- 

regnede anlæg, iflg. beskrivelse i afsnit 6.5.3. 

6.6 Beregning af residualforbrug, andelstal, fordelte forbrug og 

saldoafregning 

I pseudo-forskrift H2 er beskrevet principper og procedurer for beregning af residualforbrug, fordelte 

forbrug, andelstal samt hvorledes saldoafregning skal udføres. 

Dok. 31785/10, Sag 10/3365 84/132



Residualforbruget pr. netområde beregnes på timebasis, og er i princippet det forbrug i netområdet, 

der ikke er timemålt: Residualforbrug = total forbrug minus timemålt forbrug. Det beregnede 

residualforbrug (fikseret og refikseret) skal offentliggøres på den offentlige del af webportalen. 

Figur 6-7: Eksempel på offentliggørelse af residualforbrug. 

Ovenstående figur viser et eksempel på offentliggørelse af residualforbrug fra Energinet.dk's nuværende 

Selvbetjeningsløsning. 

Andelstalsberegningen vedrører udelukkende skabelonafregnede målepunkter og beregner i 

princippet andelen af skabelonafregnet forbrug, som hver elleverandør har i hvert netområde. 

De beregnede andelstal udsendes til markedets aktører, som beskrevet i forretningsproces 

"BRS-022: Fremsendelse af andelstal". 

Saldoafregningen korrigerer afregningerne mellem elleverandørerne, når den endelige aflæsning 

fra kunderne er modtaget og hermed erstatter de skønnede værdier. Saldoafregningen er en 

omfordeling af beløb mellem elleverandørerne. Beregningsresultatet vil være en opgørelse pr. 

elleverandør, som vil medføre en opkrævning/udbetaling til den enkelte elleverandør, og summen 

af alle opkrævninger og udbetalinger vil være nul. DataHub'en skal foretage beløbs beregningen 

og overføre posteringerne (betaling/opkrævning) til Energinet.dk's SAP system via en 

eksisterende webservice. SAP systemet vil udskrive den endelige faktura/kreditnota til elleverandørerne. 

Dok. 31785/10, Sag 10/3365 85/132



6.6.1 Beregning af residualforbrug, andelstal, fordelte forbrug & saldoafr. 

kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-165 K Beregning af residualforbrug Residualforbruget pr. netområde skal beregnes 

som beskrevet i pseudo-forskrift H2, afsnit 4. 

03-166 K Visning af residualforbrug Det beregnede residualforbrug pr. netområde 

skal offentliggøres på DataHub-portalen, på den 

offentlige tilgængelige del af siden, som beskrevet 

i pseudo-forskrift H2, afsnit 4. 

03-167 K Beregning af andelstal Andelstal skal beregnes som beskrevet i pseudo- 

forskrift H2, afsnit 5. 

03-168 K Korrektion af andelstal Det skal være muligt at udføre en ny beregning 

af udvalgte andelstal, hvis der modtages korrek- 

tioner, som beskrevet i pseudo-forskrift H2. 

03-169 K Rapporter til kontrol af andelstal Til kontrol af de beregnede andelstal skal Data- 

Hub'en generere oversigtsrapporter med beregningsresultaterne. 

03-170 K Beregning af fordelt forbrug Det fordelte forbrug pr. elleverandør, pr. balanceansvarlig 

pr. netområde beregnes som beskrevet 

i pseudo-forskrift H2, afsnit 5.3. 

03-171 K Saldoafregning DataHub'en skal kunne udføre en saldoafregning, 

som beskrevet i pseudo-forskrift H2, afsnit 6. 

03-172 K Rapporter til kontrol af Saldoafregning 

03-173 K Adgang til datagrundlag for elleve- 

randører 

Til kontrol af at Saldoafregningen er gennemført 

korrekt, skal der genereres rapporter til kontrol, 

bl.a. til kontrol af at summen af alle afregninger 

giver nul. 

Detailresultater fra Saldoafregningen skal være 

tilgængelige for elleverandøren via webportalen, 

som beskrevet i pseudo-forskrift H2, afsnit 6.5. 

Detailresultater, f.eks. periodiseret forbrug pr. 

målepunkt skal kunne dowloades i regneark. 

03-174 K Rapportering af saldoafregning Resultatet af saldoafregningen skal udskrives i en 

Dok. 31785/10, Sag 10/3365 86/132



03-175 K Overførsel af saldoafregningsresul- 

tat til bogføring 

rapport pr. elleverandør. 

Tabel 6-6: Residualforbrug, andelstal, fordelte forbrug og saldoafregning kravtabel 

6.7 Forberedelse til Samfakturering 

DataHub'en skal være forberedt til Samfakturering. 

Beregningsresultaterne fra Saldoafregningen skal 

kunne overføres til Energinet.dk's SAP system for 

bogføring. Overførslen skal ske vha. et kald til en 

eksisterende webservice. 

I dag modtager elkunder, der har skiftet elleverandør, både en faktura fra sin netvirksomhed og 

fra sin elleverandør. I forbindelse med etablering af DataHub’en er det et krav, at denne skal 

være forberedt til Samfakturering. Dette indebærer, at DataHub'en får en rolle mht. udveksling 

af fakturaoplysninger, således at der kan udsendes en samlet faktura fra elleverandøren til kunden. 

Formatet på udvekslingen af fakturalinjer skal være OIOXML. 

Det endelige procesflow for samfakturering fastlægges ultimo 2010, og der er derfor endnu ikke 

specificeret nogen forretningsproces (BRS) for denne proces. 

1) Fakturalinjer sendes til DataHub pr. målepunkt 

2) Elleverandør henter fakturalinjer 

3) 

4) 

Elleverandør udskriver faktura, enten via girokort (FI) eller 

via PBS opkrævning 

Kunden betaler via sin bank/posthus 

5) Elleverandør modtager betalingsfiler fra PBS-betalinger eller 

FI-betalinger 

6) Elleverandør skal indbetale ”netdelen” via FI oplysninger der 

var med fakturalinjer fra DataHub – pr. faktura 

7) Netvirksomhed kan udligne betaling – pengene er kommet 

ind, men de må ikke vide fra hvilken elleverandør!! 

8) Elleverandøren sender betalingsstatus til DataHub, herunder 

rykkerinformation og evt. uddybbende tekst 

9) DataHub videresender betalingsstatus til netvirksomhed 

Kunde 

44 

Kunde 

Bank 

Betalings 

Service 

FI - Faktura 

-Elforbrug 

-Net abonn. 

-Lev. abonn. 

-Netydelser 

-Evt.afgift 

-Moms 

PBS 

PBS - Faktura 

-Elforbrug 

-Net abonn. 

-Lev. abonn. 

-Netydelser 

-Evt.afgift 

-Moms 

Netvirksomhed 

Bank 

Elleverandør 

Bank 

FI - betaling 

PBS- betaling 

Betaling 

Fakturering 

Udligning 

Elleverandør 

Netvirksomhed 

Udligning Fakturering 

FI - betaling 

-NET kunde nr 

Figur 6-8: Påtænkt dataflow i forbindelse med Samfakturering 

33 

77 

55 

66 

Fakturalinjer 

pr. målepunkt 

-Net fakturanummer 

-Net kundenummer 

-Net - FI oplysning 

-Net abonnement 

-Netydelser 

-Evt. afgift 

-Moms 

-Evt. infotekst 

Fakturalinjer 



-Net kundenummer 

-Net - FI oplysning 


-Netydelser 

-Evt. afgift 

-Moms 



Fakturalinjer: 


-Netydelser 

-Afgift 

-mm 

Dok. 31785/10, Sag 10/3365 87/132 

11 

Betalingsstatus 



-Betalt 

-Kunde rykket: 

 


88 

99 

22 

Betalingsstatus 

pr. målepunkt, f.eks.: 


-Betalt 

-Kunde rykket: 

 

-Evt. infotekst



Figur 6-8 illustrerer det påtænkte dataflow i forbindelse med Samfakturering. DataHub’en modtager 

fakturalinjer pr. målepunkt fra netvirksomheden (alle fakturaoplysninger iflg. lovkrav), og 

fakturaoplysningerne gemmes i DataHub’en. Elleverandøren på det pågældende målepunkt kan 

herefter hente fakturalinjerne fra DataHub'en og danne en samlet faktura til kunden. Elleverandøren 

kan herefter senere returnere oplysninger om betalingsstatus til DataHub'en, som netvirksomheden 

efterfølgende kan hente. 

DataHub'en har altså udelukkende opgaven at udveksle fakturalinjer og status for betalingen, og 

der sker altså ingen økonomiske transaktioner i dette dataflow. Det er netvirksomhederne og 

elleverandørerne, der har ansvaret for dataindholdet i disse transaktioner, DataHub'ens funktion 

er udelukkende at sikre en anonymiseret udveksling af Samfaktureringsdata mellem parterne. 

6.7.1 Samfakturering kravtabel 

Krav 

ID 

Kravtype 

MK/K/ 

O 


03-176 K Forberedt til Samfakturering Det skal være muligt at udvide DataHub'ens 

funktionalitet med processer til Samfakturering 

som beskrevet i afsnit 6.7. 

Tabel 6-7: Samfakturering kravtabel 

6.8 Kvalitetsindeks (KPI) på måledata 

Netvirksomhedernes kvalitet på indsendelse af måledata skal løbende måles, og i pseudoforskrift 

D1, bilag 6 er der kort beskrevet mulige KPI'er (Key Performance Index) for dette. 

Der skal måles på overholdelse af tidsfristerne for indsendelse af måledata, samt for mængden 

af efterfølgende korrektioner der foretages på måledata efter udløb af tidsfristerne. 

I dag beregnes et KPI for måledata i engrosmarkedet, dette kaldes IFIM (Indeks for Forsinkelse 

af Indberettede Mængder). En overordnet beskrivelse af IFIM beregningen kan ses i afsnit 6.8.1. 

Der kan ses en nærmere beskrivelse af IFIM på Energinet.dk's hjemmeside (Marked -> Kunder/AKtører 

-> El - Benchmark af data) 

Det vurderes, at princippet bag IFIM beregningen er for kompliceret til videreførelse i Data- 

Hub'en, og der skal derfor udvikles et nyt koncept. 

Dok. 31785/10, Sag 10/3365 88/132



6.8.1 Beregning af KPI'en "IFIM" 

Nedenstående notat er fra 2004 inden Energinet.dk var blevet dannet som en fusion af bl.a. 

Eltra og Elkraft System. Referencer til disse to firmaer skal ved læsning erstattes af Energinet.dk. 

Dok. 31785/10, Sag 10/3365 89/132



Dok. 31785/10, Sag 10/3365 90/132



6.8.2 KPI på måledata kravtabel 

Krav 

ID 

Krav- 

type 

MK/K 

/O 


03-177 K Forslag til beregning af KPI på måledata 

Der skal udarbejdes et forslag til beregning af 

KPI på måledata, som efterfølgende skal implementeres 

i DataHub'en, med udgangspunkt i 

pseudo-forskrift D1, bilag 6. 

KPI beregningen skal være logisk og gennem- 

skuelig for de berørte aktører. 

03-178 K Offentliggørelse af KPI resultat Resultatet af KPI-beregningen for måledata, skal 

offentliggøres på DataHub-portalens offentlige 

Tabel 6-8: KPI på måledata kravtabel 

6.9 Dataudtræk via webservice 

En dataforbruger f.eks. en elleverandør eller offentlig myndighed skal kunne udtrække data fra 

DataHub'en ved at sende en forespørgsel i form af et kald til en webservice. Dette er beskrevet i 

pseudo-forskrift F, bilag 4 ved metoden QueryData. 

DataHub'en skal dimensioneres til at kunne besvare sådanne kald via webservice samtidig med 

at øvrige krav til svartider og performance overholdes. Hvis forespørgslen vurderes af Data- 

Hub'en til at være for kompleks og ikke vil kunne levere et svar inden for en given tidsfrist (5 

sek.), kan forespørgslen afbrydes, og der skal returneres et forklarende svar til webservicen. 

Eksempel på udtræk: 

En elleverandør kan vælge at indbygge en funktion i sin egen applikation, således at han kan 

søge stamdata på et målepunkt direkte i DataHub'en. Forespørgslen til DataHub'en kan f.eks. 

være med kundens adresse som søgekriterier, og retursvaret fra DataHub'en, kan være en resultatliste 

med disponentnavne, målepunktsadresser og aftagenumre. Fra denne liste kan elleverandøren 

nu vælge det korrekte aftagenummer, og evt. starte en leverandørskifteproces fra sit 

eget system. 

Et andet eksempel på et sådant dataudtræk kunne være, at BBR (Bygnings- og Boligregistret) 

har en hjemmeside, der viser bygningsoplysninger for en bestemt adresse. Disse oplysninger, 

som BBR har internt, kunne suppleres med en oplysning om sidste års elforbrug på adressen, og 

denne oplysning hentes dynamisk fra DataHub'en. 

del. 

Dok. 31785/10, Sag 10/3365 91/132



6.9.1 Dataudtræk kravtabel 

Krav 

ID 

Krav- 

type 

MK/K/ 

O 


03-179 K Generel webservice til forespørgsel DataHub'en skal have en mulighed for, at man 

let kan definere nye forespørgsler i webservicen 

QueryData, beskrevet i pseudo-forskrift F, bilag 

4. 

03-180 K Forespørgsel tidsfrist Hvis forespørgslen er for ressourcekævende 

(kompleks) skal denne afbrydes efter en defineret 

tidsfrist (5 sek.) - og der skal returneres et 

forklarende svar. 

Tabel 6-9: Dataudtræk kravtabel 

6.10 Rapportering 

Rapportering skal ske via rapporteringsværktøjet, beskrevet i afsnit 4.4. 

I nedenstående kravtabel, er de specifikke rapporter der ønskes leveret med systemet, beskrevet. 

Dok. 31785/10, Sag 10/3365 92/132



6.10.1 Rapportering kravtabel 


MK/K/ 

O 


Stamdata rapportering 

03-181 K Elleverandører, balanceansvarlige, 

netvirksomheder m.fl. 

Rapport indeholdende liste over (og antal) aktuelle 

elleverandører, balanceansvarlige, netvirksomheder 

m.fl. 

03-182 K Målepunkter Rapport indeholdende oversigt over (og antal) 

målepunkter, grupperet på aktuel status, pr. 

netvirksomhed, pr. elleverandør og pr. balanceansvarlig. 

03-183 K Målepunkter pr. leverandør Oplysninger om tidligere, aktuelle og kommende 

målepunkter pr. elleverandør med detailinformation 

pr. målepunkt, bl.a. tidspunkt for leverandørskift. 

Skal anvendes af elleverandøren til kontrol 

mod egne stamdata. 

03-184 K Målepunkter pr. netvirksomhed Detaljerede informationer om alle målepunkter 

for en given netvirksomhed. Skal anvendes af 

netvirksomhed til kontrol mod egne stamdata 

Leverandørskifte rapportering 

03-185 K Leverandørskifte Antal leverandørskift opdelt pr. periode, og pr. 

elleverandør. 

03-186 K Fejlagtige leverandørskifte Ikke gennemførte, forsinkede og annullerede leverandørskift 

pr. periode og pr. elleverandør. 

Målerapportering 

03-187 K Elforbrug og elproduktion Elforbrug og elproduktion opgjort pr. periode, pr. 

netområde, pr. elleverandør, pr. DE-branchekode 

og pr. afregningsmetode (skabelon/time) 

Proces rapportering 

Dok. 31785/10, Sag 10/3365 93/132



03-188 K Overholdelse af deadline Overholdelse af deadlines givet i markedsforskrifter. 

F.eks. antal for sent indmeldte leverandørskift 

eller for sent indmeldte flytninger pr. elleve- 

randør 

03-189 K Rykkerstatistik Antal fremsendte rykkere (og antal manglende 

målinger) pr. netvirksomhed pr. periode 

03-190 K Forespørgselsstatistik Antal forespørgsler pr. type (måle- og stamdata) 

pr. aktør pr. periode. Formålet er at detektere 

"uforholdsvise" mange forespørgsler fra én aktør. 

03-191 K Webformularstatistik Antal webformularer fremsendt for en given periode 

pr. type, pr. elleverandør, pr. netvirksomhed. 

System rapportering 

03-192 K Statistik for DataHub-systemet Statistik for anvendelse af DataHub'en for en given 

periode, f.eks. antal kald til webservice, anvendelse 

af webportal, antal igangsatte transaktioner, 

antal fejlede transaktioner osv. 

Tabel 6-10: Rapportering kravtabel 

Dok. 31785/10, Sag 10/3365 94/132



7. Funktionskrav til Aktørtestsystemet 



Stamdata 


Portal 


Rapportering 

Måledata 

Dataudtræk 





Testcases 






Testhistorik 





Platform 


Sikkerhed 

Datamigrering 

Dette afsnit beskriver den specifikke funktionalitet, der kræves i Aktørtestsystemet. 

7.1 Aktørtestsystemets formål 

7.1.1 Overordnet formål med Aktørtestsystemet 

Aktørtestsystemet skal fungere som et automatiseret testsystem, der skal teste de it-systemer, 

som aktører og it-leverandører benytter til meddelelsesudveksling, samt hjælpe aktører med at 

forstå meddelelsesudvekslingen i elmarkedet. Målet for aktørerne er at blive godkendt som aktør 

på elmarkedet og dermed kunne udveksle meddelelser via DataHub’en. Målet for it-leverandører 

er at få godkendt deres it-system i forhold til de roller i elmarkedet, som systemet er udviklet til 

at kunne håndtere. 

Meddelelsesudvekslingen i elmarkedet er en væsentlig del af kommunikationen mellem aktørerne 

og DataHub'en. Det er derfor forretningsmæssigt vigtigt, at alle aktører i markedet meddelelseskommunikerer 

med den højest mulige kvalitet – både ved korrekt brug af meddelelser og ved 

at sikre en høj datakvalitet. Derfor skal Aktørtestsystemet kunne teste de it-systemer som itleverandørerne 

udvikler til aktørerne i elmarkedet, samt aktørernes individuelle opsætning af itsystemerne. 

Først og fremmest skal Aktørtestsystemet udfylde følgende funktioner: 

• Test af meddelelser (syntaks og semantik) afsendt fra aktørens it-system i forhold til de 

gældende markedsforskrifter. 

Dok. 31785/10, Sag 10/3365 95/132



• Test af flere samtidige forskellige testcases af samme aktør med forskellige testdata for 

de aktuelle forløb af meddelelser mellem aktøren og DataHub’en (beskrevet i "EDI 

transaktioner for det danske elmarked"). 

• Dokumentation af aktørens testforløb, herunder at give besked om evt. fejl, og hvor de 

er opstået. 

• Når en aktør eller it-leverandør positivt har gennemført et godkendelsestestforløb, skal 

systemet kunne indikere over for Energinet.dk, at en aktør er klar til at blive godkendt. 

Udover de ovennævnte primære formål, er der en række situationer hvor Aktørtestsystemet 

også skal benyttes: 

• Når nye it-systemer hos it-leverandørerne introduceres på markedet. 

• I tilfælde hvor aktørerne ændrer eller opgraderer it-systemer. 

• Ved ændringer eller opdateringer i forhold til processer og meddelelser i markedet og 

dermed også i selve DataHub’en. 

Aktørtestsystemet skal sikre størst mulig automatisering og dermed så vidt muligt medvirke til 

at begrænse Energinet.dk’s manuelle involvering i godkendelsesprocessen. Systemet skal således 

understøtte, at testen fremover kun involverer den pågældende aktør/it-leverandør og som 

hovedregel ingen andre. 

7.1.2 Brugertyper til Aktørtestsystemet 

Brugertyperne til Aktørtestsystemet er i afsnit 3.4 betegnet som Testbrugere, men kan yderligere 

specificeres ved disse tre typer: 

Energinet.dk har det overordnede ansvar for Aktørtestsystemet, samt for at systemet er opdateret 

i forhold til de gældende forretningsprocesser og relevante testdata. Energinet.dk skal kunne 

monitorere fremdriften på testflows samt fejl mv. Aktørtestsystemet skal være fuldautomatisk, 

således at Energinet.dk skal bruge ingen, eller kun ganske få ressourcer, på at godkende 

aktører og it-leverandører. 

Markedsaktører har et behov for at teste de meddelelsesflows, aktøren skal kunne udveksle 

med DataHub’en. Herunder er også test af evt. nye aktører i markedet. 

It-leverandøren leverer it-systemer til aktørerne og har derfor brug for at få deres systemer 

godkendt til elmarkedet. It-leverandørerne kan levere til flere forskellige aktører i markedet, og 

det er derfor nødvendigt, at de kan gennemføre flere forskellige testforløb, således at alle roller 

bliver testet i forhold til it-systemet. I testen er der specielt fokus på at alle fejlsituationer i 

kommunikationen håndteres korrekt af it-leverandørens system. 

7.1.3 Testtyper 

Aktørtestsystemet skal kunne håndtere to testtyper, med mulighed for opsætning af flere, der i 

praksis ligger i forlængelse af hinanden: 

• Systemtest: Gennemføres af it-leverandører, der leverer it-systemer til aktører i elmarkedet. 

Dok. 31785/10, Sag 10/3365 96/132



• Aktørtest: Gennemføres af aktører i elmarkedet på baggrund af et it-system, der har 

opnået godkendelse i Systemtesten. 

Systemtesten er mere omfattende og grundlæggende end aktørtesten. 

Figur 7-1: Testtyper 

Systemtesten er rettet mod it-leverandørers it-systemer, der skal testes for første gang, eller 

skal testes i en ny version. Systemtestens forretningsscenarier samt udvalgte fejltyper er nærmere 

specificeret i de relevante testcases, der specificeres senere. Systemtesten omfatter: 

• Test af at alle meddelelsestyper, som it-systemet kan varetage, fungerer, samt at systemet 

reagerer hensigtsmæssigt og korrekt på de testede fejlsituationer. 

• Test af at dataindholdet i meddelelserne er i overensstemmelse med forskrifterne (beskrevet 

i "EDI transaktioner for det danske elmarked"). 

Testen er i høj grad teknisk og skal sikre, at it-systemet grundlæggende fungerer og handler 

hensigtsmæssigt i fejlsituationer. Systemtesten kan indeholde testforløb, der er gældende for én 

eller flere aktørroller. En godkendt Systemtest er en forudsætning for, at en efterfølgende Aktørtest 

kan gennemføres for det pågældende it-system. 

Aktørtesten er en test rettet mod markedsaktørerne og har til formål at sikre, at aktøren kan 

håndtere transaktioner, der er involveret i en given forretningsproces. Testen vil samtidig bidrage 

til aktørens forståelse af meddelelsesflowet. Aktørtesten er mere forretningsorienteret end 

Systemtesten og der er i højere grad fokus på indholdet end på fejlforløb. Afhængig af hvilken 

rolle, aktøren varetager skal alle test under den pågældende aktørrolle gennemføres. Det forudsættes 

i Aktørtesten, at det system der anvendes, har bestået en Systemtest, hvorfor der generelt 

er færre test i Aktørtesten end i Systemtesten – herunder færre test, der afprøver aktørens 

Dok. 31785/10, Sag 10/3365 97/132



evne til at reagere på fejlforløb. Det er til enhver tid aktørens ansvar, at dennes it-system, konfiguration 

og EDI-meddelelser lever op til gældende regler. 

7.2 Overordnede rammer for Aktørtestsystemet 

7.2.1 Model for Aktørtestsystemet 

Som det er beskrevet i afsnit 7.1.2 ”Brugertyper til Aktørtestsystemet” og 7.1.3 ”Testtyper”, skal 

Aktørtestsystemet servicere tre brugergrupper og to forskellige testtyper. 

Til hver af de tre brugergrupper er knyttet funktionalitet, der har til formål at sikre, at brugergruppen 

kan udføre de nødvendige funktioner i forhold til gennemførelse af de respektive testforløb. 

Figur 7-2 giver et overblik over de tre brugergrupper, testtyper og tilknyttet funktionalitet. 

Figur 7-2: System- og aktørlandskab 

Ovenstående figur giver et overblik over hvilke brugergrupper, der er koblet på Aktørtestsystemet, 

samt hvilke systemer og grænseflader der er involveret i Aktørtestsystemet. 

Figuren ovenfor viser de tre interessentgrupper: Aktør, It-leverandør og Energinet.dk, der skal 

anvende Aktørtestsystemet. Hver interessentgruppe, markeret med en bestemt farve, relaterer 

sig til forskellige funktionalitetsområder – listet i de tilsvarende farvede bokse i Aktørtestsyste- 

Dok. 31785/10, Sag 10/3365 98/132



met. Størstedelen af den funktionalitet, som en aktør anvender, anvendes også af itleverandøren. 

Der er generelt ingen forskel mellem den funktionalitet, som aktøren og it-leverandøren skal have 

adgang til, hvilket også fremgår af Figur 7-2: System- og aktørlandskab. Forskellen på de to 

brugergrupper er primært i antallet af tests, som de skal gennemføre. 

Energinet.dk er ansvarlig for Aktørtestsystemet, og har det administrative og driftsmæssige ansvar. 

Figuren viser endvidere, at alle interessenter interagerer med Aktørtestsystemet via en webgrænseflade, 

eller alternativt en webservice der udstiller samme funktionalitet som webgrænsefladen. 

Formålet med denne webservice er, at muliggøre system-til-system kommunikation 

med Aktørtestsystem således, at it-leverandører og aktører kan automatisere deres interne testprocedure. 

Detaljerede status- og fejlmeddelelser vises fortsat kun i den grafiske grænseflade. 

7.2.2 Overordnet testflow 

Aktørtestsystemet skal være i stand til at understøtte følgende proces for test af meddelelsesudveksling 

og dermed automatisering af modtagelse og afsendelse af datameddelelser med aktører. 

Figur 7-3: Model for transaktion i Aktørtestsystemet 

Ovenstående figur beskriver forløbet for opstart og gennemførsel af en testcase (en eller flere 

transaktioner) og dermed test af én eller flere meddelelser initieret af en Aktør via en grænseflade. 

Figuren tager udgangspunkt i, at kommunikationen foregår via webservices både til og fra 

Aktørtestsystemet. 

1. Aktøren initierer en ny testcase i Aktørtestsystemet. Det sker via brugergrænseflade i 

Aktørtestsystemet eller via webservice (eget it-system). 

2. Aktørtestsystemet bekræfter opstart af testcase. 

3. Aktøren initierer transaktion/forretningsproces i eget it-system. 

4. Aktøren (eget it-system) sender meddelelse via webservice. 

Dok. 31785/10, Sag 10/3365 99/132



5. Meddelelsen afleveres til Aktørtestsystemets webservice. 

6. Meddelelsen modtages af Aktørtestsystemet. 

7. Aktørtestsystemet returnerer den korrekte meddelelse ifølge testcasen – sendes via 

webservice. Aktørtestsystemet opdaterer samlet teststatus for Aktøren. 

8. Meddelelsen afleveres til Aktøren (eget it-system). 

9. Aktørens (eget it-system) modtager meddelelsen fra Aktørtestsystemet. 

Resultatet af testcasen præsenteres for aktøren via webgrænseflade. Resultatet angiver, om testen 

er godkendt eller afvist, herunder evt. oplysning om fejlmeddelelse mv. 

Beskrivelsen ovenfor er overordnet og angiver derfor ikke den præcise funktionalitet, samt hvilke 

kontroller, herunder fejlhåndtering, der foretages. 

7.2.3 Overordnede krav 

Aktørtestsystemet kan overordnet beskrives som det miljø, hvor aktørerne og it-leverandørerne 

kan teste kvaliteten og opsætningen af deres it-systemer, som beskrevet i afsnit 7.1.3. 

Samtidig kan Energinet.dk benytte Aktørtestsystemet til at teste markedets it-systemer, inden 

eventuelle ændringer eller nye standarder introduceres i DataHub’en. 

Sidstnævnte behov understreger sammenhængen mellem Aktørtestsystemet og DataHub’en, så 

dataudvekslingen i Aktørtestmiljøet må ikke afvige fra dataudvekslingen i DataHub-miljøet. 

I det følgende beskrives de overordnede krav til Aktørtestsystemet. 

Dok. 31785/10, Sag 10/3365 100/132



Krav 

ID 

Krav 

type 


03-193 K Aktørtestsystemet skal simulere DataHub’en 

03-194 K Aktørtestsystemet skal kunne teste 

meddelelseskommunikation i elmarkedet 

Når en bruger gennemfører en testcase (transaktioner 

mellem aktør og DataHub), skal systemet 

være i stand til at give samme respons, 

som det forventes af DataHub’en. Aktørtestsy- 

stemet skal i testforløbet være i stand til at 

agere som DataHub’en. Brugeren og itsystemerne, 

der skal testes, skal i princippet 

ikke kunne se forskel på, om de meddelelsesudveksler 

med DataHub’en eller Aktørtestsy- 

stemet. 

Aktørtestsystemet skal følge kommunikationsreglerne, 

som beskrevet i pseudo-forskrift F og 

dennes bilag. 

Aktørtestsystemet skal kunne teste alle typer 

af meddelelser, der udveksles i elmarkedet, 

hvor der meddelelsesudveksles via Data- 

Hub'en. 

03-195 O Udelukkende XML som dataformat Pseudo-forskrift F angiver at al kommunikation 

kan ske i EDIFACT eller XML format. Hvis ingen 

aktører vælger at anvende EDIFACT format, 

skal Aktørtestsystemet ikke håndtere dette 

03-196 K Versionering af meddelelser i Aktørtestsystemet 

03-197 K Aktørtestsystemet skal kunne styres 

via en webservice (API) 

format. 

Optionen skal afspejle besparelsen ved dette 

fravalg. 

Aktørtestsystemet skal til enhver tid kunne 

køre et vilkårligt antal versioner af enhver 

meddelelse, således at brugeren kan specificere 

hvilken meddelelsesversion, der skal testes. 

Der skal udvikles en webservice, der stiller 

samme funktionalitet til rådighed som på brugergrænsefladen. 

Det skal være muligt via webservicen at afspille 

testcases samt at modtage retursvar efter 

endt kørsel eller undervejs. Brugere skal via 

webservicen kunne automatisere kørsel af testcases, 

så alle tests kan gennemføres løbende 

uden behov for menneske-til-system interaktion. 

Grundlæggende skal funktionaliteten i web- 

servicen være den samme, som den brugeren 

har i den grafiske grænseflade. Det skal til enhver 

tid være muligt at afbryde et automatise- 

Dok. 31785/10, Sag 10/3365 101/132



Krav 

ID 

Krav 

type 


03-198 K Fremtidig test af kommunikation med 

andre systemer 

Tabel 7-1: Overordnede kravtabel 

7.3 Funktionelle krav 

ret testforløb og logge ind i den grafiske brugerflade 

for at arbejde videre med testforløbet. 

Formålet er at tilbyde brugere, der er fortrolige 

med Aktørtestsystemet, en skalerbar adgang til 

gennemførelse af et testforløb bestående af 

flere testcases. Kravet skal muliggøre, at en 

aktør kan gennemføre et testforløb langt hurtigere 

og mindre ressourcekrævende end via 

den grafiske brugerflade. 

Aktørtestsystemet skal være forberedt til at 

kunne konfigureres til at teste meddelelser, der 

anvendes i øvrige systemer hos Energinet.dk, 

f.eks. plan-indmeldingssystemet (men på 

kendt format EDIFACT/XML) 

I dette kapitel er der indsat eksempler på skærmbilleder fra Aktørtestsystemet på gasmarkedet. 

Disse skærmbilleder (fra www.ediport.dk) skal blot underbygge og inspirere de anførte krav i 

teksten. 

7.3.1 Registrering af it-system kravtabel 

Krav til oprettelse af brugere til Aktørtestsystemet er beskrevet i afsnit 7.1.2. Når brugeren (itleverandør 

eller aktør) er oprettet som bruger af Aktørtestsystemet, skal denne selv registrere 

sig, som beskrevet i nedenstående krav. 

Krav 

ID 

Kravtype 

MK/K/O 


03-199 K Registrering af it-system (itleverandør) 

Når it-leverandøren er oprettet med adgang til 

Aktørtestsystemet, skal det være muligt for itleverandøren 

at registrere det it-system, som øn- 

skes godkendt. 

Oplysningerne om systemet skal minimum være: 

• Navn 

Dok. 31785/10, Sag 10/3365 102/132



Kravtype 


• Hvilke roller i elmarkedet som systemet dækker 

(ud fra en valgliste - defineret af Energinet.dk) 

• Beskrivelse af it-leverandøren med kontaktinformation 

• Versionering 

03-200 K Registrering af it-system (aktør) Når aktøren er oprettet med adgang til Aktørtestsystemet, 

skal denne registrere det pågældende 

it-system og versionsnr., inden testen kan påbegyndes. 

03-201 K Opgradering af it-system (itleverandør) 

Tabel 7-2: Registrering af it-system kravtabel 

7.3.2 Administration af testcases 

Aktøren kan kun registrere et allerede godkendt 

it-system. 

It-leverandøren skal kunne registrere en ny version 

af deres it-system, og dermed have mulighed 

for at gennemføre en Systemtest med den nye 

version. 

Energinet.dk skal definere og administrere indholdet af de forskellige testcases, og dermed de 

konkrete testcases som brugerne skal gennemføre for at opnå godkendelse af testforløbet. 

Nedenstående Figur 7-4 viser centrale begreber for testen og disses indbyrdes sammenhæng. 

Dok. 31785/10, Sag 10/3365 103/132



Figur 7-4: Testbegreber og indbyrdes 

sammenhæng 

Aktørtestsystemet understøtter to typer brugere – aktører 

og it-leverandører. 

Afhængig af brugertype gennemføres en række testcases, 

der er bestemt af, hvilken rolle den pågældende 

bruger varetager. Til hver brugertype er der knyttet en 

række testcases (fastlagt af Energinet.dk). 

En testcase er en samlet betegnelse for de meddelelser 

(udveksling af meddelelser er også kaldet transaktioner), 

der indgår i testen, samt de sæt af testdata som 

kan anvendes. Testcasen beskriver endvidere, hvilke 

parter der indgår i testen, samt hvem der sender første 

meddelelse (aktøren/it-leverandøren eller Aktørtestsystemet). 

Tidsrummet fra en testcase aktiveres til den er slut, 

kaldes selve testen. 

Testforløbet er et samlebegreb for de testcases en aktør/it-leverandør 

skal gennemføre. 

Metadata til en testcase er nr, navn, beskrivelse, de 

parter der indgår i testcasen samt de trin, der indgår i 

forløbet. 

Nedenstående figur viser et eksempel på en eksisterende testcase beskrivelse. I testcasen kan 

der ses, hvilke parametre en testcase indeholder, samt hvordan et testforløb kan se ud. 

Dok. 31785/10, Sag 10/3365 104/132



Testcase BS-002-P1: Leveranceophør 

Beskrivelse: 

Initierende part (første afsender): Hidtidig leverandør 

Behandlende part (første modtager): Netvirksomhed 

Særlige forudsætninger: 

Testdata: 

Testforløb (trinvis) – BT-003 End of supply 

Leverandør Netvirksomhed 

UTILMD 432 

1 2a 

3 

UTILMD 406 

BS-002: Leveranceophør, positivt forløb 

Tidsfristen skal ignoreres. 

Perioden frem til skæringsdatoen skal 

ignoreres. 

Trin Aktør Meddelelse Kommentar OK 

1 EL UTILMD432 EL registrerer ophør af leverance på målepunkt 

X med korrekt skæringsdato (til den første i 

næste måned) i egen applikation og kontrollerer, 

at anmeldelsen af ophør af leverance sendes til 

NV. 

2 NV UTILMD406 NV modtager anmeldelsen af ophør af leverance 

og returnerer bekræftelsen til EL. 

Figur 7-5: Testcase eksempel 

Kontrolpunkt 1: 

2b 

Data skal være: 

− MP ID = X 

− Skæringsdato (til den første i næste måned) 

Ovenstående figur viser et eksempel på opbygningen af en nuværende testcase 

I eksemplet indgår to parter (svarende til aktørroller), en afsender og en modtager. Når man 

opretter en testcase skal Aktørtestsystemet tildeles rollen som afsender eller modtager – afhængig 

af hvilken part der initierer testcasen. 

Som vist ovenfor, beskriver figuren to meddelelser med testdata, der skal udveksles mellem aktørens 

it-system og DataHub’en (i dette tilfælde Aktørtestsystemet). Testcasen er et udtryk for 

Dok. 31785/10, Sag 10/3365 105/132



sammenhængen mellem på den ene side rollen og på den anden side meddelelserne, der skal 

udveksles samt de tilhørende sæt af testdata. 

Figur 7-6: Eksempel på definition af testcase 

Det er Energinet.dk’s behov at kunne sammensætte testcases ud fra de beskrevne begreber og 

deres indbyrdes sammenhænge – hvilket fremgår af nedenstående krav. 

7.3.3 Administration af testcases kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-202 K Aktørtestsystemet skal kunne behandle 

to testtyper 

Aktørtestsystemet skal kunne behandle Aktørtest 

og Systemtest. 

03-203 K Oprettelse af meddelelsestyper Energinet.dk skal kunne oprette og teste nye 

meddelelsestyper i Aktørtestsystemet, uden at 

03-204 K Oprettelse og redigering af testcases 

disse bliver oprettet i DataHub’en. 

Energinet.dk skal nemt kunne oprette og redigere 

testcases i Aktørtestsystemet, der definerer et 

trinvist forløb (én eller flere meddelelser), som 

skal gennemføres i System- og/eller Aktørtesten. 

Ved oprettelse eller redigering af en testcase kan 

systemadministrator tilknytte/definere følgende 

parametre: 

Dok. 31785/10, Sag 10/3365 106/132



Kravtype 


• Testtype(r) (Aktørtest/Systemtest) 

• Aktørrolle(r) 

• Meddelelsestype(r) (her defineres evt. hvilken 

version af den pågældende meddelelsestype 

der skal anvendes i den specifikke testcase) 

• Testdata (standard eller egne uploadede testdata 

– XML- eller CSV-format) 

• Sekvens af meddelelser (hvor mange og 

hvorfra sendes testmeddelelsen – aktøren eller 

DataHub’en?) 

• Hvilken kommunikationsprotokol der skal 

anvendes 

• Der skal som minimum kunne knyttes følgende 

metadata-oplysninger til testcasen (nr, 

navn, beskrivelse, format (EDIFACT/XML), de 

parter der indgår i testcasen samt de trin, der 

indgår i forløbet.) 

03-205 K Kopiering af testcases Det skal være muligt at kopiere definitionen af 

testcases, for at lette oprettelsen af de mange 

meget ens testcases. 

03-206 K Aktørtestsystemet skal kunne teste 

negative testcases 

03-207 K Ændring af meddelelser og/eller 

testdata (negative testcases) 

03-208 K Oversigt over testcases 

Aktørtestsystemet skal kunne udføre testcases 

designet med det formål at afprøve, hvordan aktører, 

it-leverandører og it-systemerne reagerer 

på meddelelser, der fejler. Negative testcases skal 

kunne behandles på samme vilkår som positive 

testcases. 

Energinet.dk skal kunne ændre de meddelelser 

og/eller testdata, som er tilknyttet en testcase. 

Ved at ændre i indholdet af de valgte meddelelser, 

er det kun meddelelserne og/eller testdata i pågældende 

testcase, som påvirkes. 

Energinet.dk skal have adgang til en oversigt over 

oprettede testcases. Oversigten skal kunne fremvise 

sammenhængen mellem aktørrolle, testcase, 

meddelelsetyper og testtype. 

Oversigten skal endvidere kunne vise metadata på 

testcases – enten direkte eller i forlængelse af 

Dok. 31785/10, Sag 10/3365 107/132



Kravtype 


Figur 7-7: Administration af testcases kravtabel 

7.3.4 Administration af testdata 

oversigten (ved at brugeren udbeder sig detaljeret 

information). 

Brugeren skal fra oversigten kunne filtrere på 

testtype, aktørrolle og meddelelsestype. Filtreringen 

kan ske på én eller flere af de nævnte parametre. 

Testdata benyttes i alle testcases. Enten i form af standardtestdata som etableres af systemadministrator 

(Energinet.dk) eller aktørens/it-leverandørens egne testdata. 

Brugeren skal have muligheden for at administrere de testdata, som benyttes i de enkelte testcases. 

Her skal Aktørtestsystemet udvise en høj grad af fleksibilitet, idet brugeren frit skal kunne 

vælge, om man ønsker at benytte standardtestdata (udarbejdet af Energinet.dk), eller om man 

vil benytte egne testdata, som man løbende kan udskifte efter behov. 

Figur 7-8: Eksempel på opsætning af testdata 

7.3.5 Administration af testdata kravtabel 

Dok. 31785/10, Sag 10/3365 108/132



Krav 

ID 

Kravtype 

MK/K/O 


03-209 K Upload af standardtestdata 

03-210 K Ændring af eksisterende testdata 

03-211 K Nulstilling af testdata 

03-212 K Standardtestdata nulstilles ved 

afslutning af testforløb 

03-213 K Upload af egne testdata 

03-214 K Validering af testdata 

03-215 K Download af standardtestdata 

Det skal være muligt for systemadministrator at 

uploade standardtestdata til brug i testcases i 

XML- og CSV-format, som aktørerne dermed kan 

benytte i deres testforløb uden at skulle uploade 

egne testdata. 

Det skal være muligt at ændre i pre-loadet og 

egne uploadede testdata via grænsefladen i Aktørtestsystemet. 

Det skal være muligt at nulstille pre-loadet og 

egne uploadede testdata. Det vil sige, at data 

ændres tilbage til den oprindelige version som ved 

oprettelse. 

Ved gennemførelse af en testcase er standard- 

testdata uploadet af Energinet.dk muligvis ændret 

som følge af testcasens forløb. Aktørtestsystemet 

skal herefter automatisk nulstille testdata til de 

oprindelige uploadet af Energinet.dk, således at 

testcasen kan gennemføres igen med uændret 

testdata. 

Det skal være muligt for brugerne at uploade deres 

egne testdata til Aktørtestsystemet, således at 

de gennemfører testforløbet med egne testdata 

(upload i minimum XML- og CSV-format). 

Ved upload af egne testdata skal Aktørtestsystemet 

validere strukturen af testdata, således at 

testdata matcher den struktur, der i forvejen er 

repræsenteret ved standardtestdata uploadet af 

Energinet.dk. Brugeren skal have besked via 

skærmdialogen om resultatet af valideringen. 

Standardtestdata skal være tilgængelige for 

download af brugerne, således at de kan implementere 

dem i eget system forud for testen. Brugeren 

kan ved download af testdata vælge mellem 

minimum XML- og CSV-format. 

03-216 K Dynamiske datoer i standardtest- Energinet.dk skal kunne ændre datoer (UTC) indeholdt 

i standardtestdata for individuelle testca- 

Dok. 31785/10, Sag 10/3365 109/132



Kravtype 


data 

ses. Det skal være muligt at definere relevante 

datoer ud fra dags dato, enten bagud eller fremad 

i tid, således at relevante datoer i testdata ændrer 

sig ud fra testtidspunktet (Offset). Dette specificeres 

på testcase-niveau, og ændrer ikke på standardtestdata. 

03-217 K Tidsfrister sættes ud af drift Energinet.dk skal i testcases kunne definere, at 

evt. tidsfrister i processen skal ignoreres. Dette 

for at bl.a. at test hændelser der ville kræve en 

tidsmæssig langstrakt test, f.eks. ved afventning 

af svar fra netvirksomhed i leverandørskiftepro- 

Figur 7-9: Administration af testdata kravtabel 

7.3.6 Administration af testforløb 

cessen. 

Inden en aktør går i gang med sit testforløb, skal denne have mulighed for at specificere enkelte 

detaljer i forbindelse med testen, såsom hvilke testdata man ønsker at benytte, samt om testforløbet 

skal være en del af den endelige godkendelse. 

Efter testforløbet, skal brugeren let kunne finde status for egne testforløb samt se detaljerede 

oplysninger om hvert forløb. 

Figur 7-10: Eksempel på oversigt over testforløb 

Dok. 31785/10, Sag 10/3365 110/132



Figur 7-11: Eksempel på statusmelding fra testforløb 

Figur 7-12: Eksempel på detaljeret beskrivelse af valideringsfejl 

7.3.7 Administration af testforløb kravtabel 

Dok. 31785/10, Sag 10/3365 111/132



Krav 

ID 

Kravtype 

MK/K/O 


03-218 K Struktur på testforløb 

03-219 K Sandkassemiljø i Aktørtestsystem 

Energinet.dk skal kunne definere strukturen på et 

testforløb (her refereres til en samling af testcases 

knyttet til en testtype og en aktørrolle), som minimum 

hvilken rækkefølge man ønsker de forskellige 

testcases gennemført, sammenhænge og af- 

hængigheder mellem testcases og gruppering af 

testcases. 

Aktørtestsystem skal stille et sandkassemiljø til 

rådighed for den enkelte bruger, hvor der er mu- 

lighed for 

• at køre testcases efter behov 

• at uploade egne testdata og vedligeholde dem 

• at gemme opsætningen i sandkassemiljøet, 

med henblik på at brugeren senere vender tilbage 

og aktiverer dette igen 

03-220 K Parameterstyring af testforløb Forud for gennemførelse af en test skal brugeren 

03-221 K Gældende eller ikke-gældende 

Aktørtest/Systemtest 

tage stilling til foruddefinerede parametre, der er 

med til at definere, hvordan testen skal gennemføres. 

Parameterstyringen skal som minimum inkludere: 

• Hvilke testdata skal benyttes til testen? 

• Skal testen være del af godkendelsesprocessen? 

Specielt for it-leverandører: 

• Hvilket system og hvilken version testes? 

De valgte parametre er gældende for alle testcases, 

indtil man aktivt vælger at ændre startparametrene. 

Brugeren skal forud for gennemførelsen af et antal 

testcases kunne vælge, om de skal indgå i et godkendelsesforløb 

eller ej. Som standard skal systemet 

sættes op, så alle testcases er gældende i 

et godkendelsesforløb. 

03-222 K Adgang til teststatus og -resultater Teststatus og det endelige testresultat må kun 

være synlig for den pågældende aktør/it- 

Dok. 31785/10, Sag 10/3365 112/132



Kravtype 


03-223 K Ændring af UTC-offset i testmed- 

delelser 

03-224 K Parallelle testforløb 

Tabel 7-3: Administration af testforløb kravtabel 

7.3.8 Godkendelse af testforløb 

leverandør og til enhver tid Energinet.dk. 

Det skal være muligt at ændre offset i UTC-tid i 

meddelsen, dette ved at angive et offset (+/-) i 

timer, der ændrer tidsangivelser i meddelelsen. 

Det skal være muligt for en bruger af Aktørtestsystemet 

at starte flere forskellige testcases samti- 

dig – dog ikke samme testcase. Dette indebærer 

også, at flere brugere tilknyttet samme aktør eller 

it-leverandør individuelt kan opstarte testcases på 

samme tid – dog ikke samme testcase. 

Efter gennemførsel af et positivt testforløb, skal testforløbet godkendes af Energinet.dk. 

Figur 7-13: Eksempel på godkendelse af systemtest 

7.3.9 Godkendelse af testforløb kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-225 K Forudsætningerne for at opnå god- Energinet.dk skal som systemadministrator have 

mulighed for at definere, hvilke test der forudsæt- 

Dok. 31785/10, Sag 10/3365 113/132



Kravtype 


kendelse 

03-226 K Manuel godkendelse af Aktører og 

it-leverandører 

03-227 K Automatisk godkendelse af Aktører 

og it-leverandørers testforløb 

03-228 K Notifikation om afsluttet/godkendt 

test 

tes gennemført for at opnå godkendelse i henholdsvis 

aktør- og systemtesten. Dette inkluderer 

som minimum hvilke testcases, der skal være 

godkendt. 

Energinet.dk skal som systemadministrator have 

mulighed for at foretage manuel godkendelse af 

aktører og it-leverandører. 

Energinet.dk skal som systemadministrator have 

mulighed for at opsætte Aktørtestsystem til automatisk 

at godkende aktører og it-leverandører på 

baggrund gennemførte testcases (alle relevante 

testforløb). 

Energinet.dk skal kunne angive, om der skal afsendes 

en notifikation til de af brugeren (aktør 

eller it-leverandør) oplyste e-mailadresse(r), når 

denne har opnået godkendelse. 

Energinet.dk skal kunne orienteres via brugergrænsefladen 

og/eller mail om, at den pågælden- 

de test er blevet godkendt. 

03-229 K Godkendt Systemtest Efter godkendelse af systemtesten skal itsystemet 

gøres tilgængeligt for aktører, som derefter 

skal kunne vælge it-systemet til afvikling af 

deres Aktørtest. 

03-230 K Godkendt Aktørtest Efter gennemførelse af aktørtesten skal Aktørtestsystemet 

registrere den pågældende aktør og 

Tabel 7-4: Godkendelse af testforløb kravtabel 

7.3.10 Historik for testforløb 

dennes version af it-systemet og give besked til 

Energinet.dk, som derefter kan give meddelelse 

om godkendelse. 

Brugerne har behov for at kunne fremfinde og få overblik over igangværende og gennemførte 

testcases. Historikken dækker derved over muligheden for at få opdateret og detaljeret status på 

alle relevante testcases, samt eventuelle fejlrapporter som måtte være tilknyttet de enkelte 

transaktioner. 

Energinet.dk har behov for et overblik over igangværende og gennemførte testcases på tværs af 

hele systemet. Overblik over testhistorik skal hjælpe med at gennemføre support over for bru- 

Dok. 31785/10, Sag 10/3365 114/132



gerne, hvorfor der er behov for adgang til relevante fejlrapporter og detaljer om hver enkelt 

testcase. 

Figur 7-14: Eksempel på oversigt over testkørsel 

Figur 7-15: Eksempel på oversigt over testforløb 

Dok. 31785/10, Sag 10/3365 115/132



7.3.11 Historik for testforløb kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-231 K Systemadministrators fremsøgning 

af testcases 

03-232 K Systemadministrators krav til søgeresultatet 

ved fremsøgning af 

testcases 

03-233 K Fremsøgning af statistiske data på 

testcase niveau 

Systemadministrator skal kunne fremsøge igangværende 

og gennemførte testcases. Søgeparametre 

skal som minimum være: 

• Tidspunkt (dato) 

• Anvendt meddelelsestype 

• Testcase ID 

• Aktør 

• It-leverandør 

• Status 

I søgeresultatet skal ovenstående parametre ligeledes 

vises. Det er således både parametre til 

fremsøgning og visning. 

Ved fremsøgning af testcases skal søgeresultatet, 

foruden de nævnte parametre give systemadministrator 

mulighed for at navigere til en detajleret 

oversigt over status på de enkelte testcases. Som 

minimum skal det være muligt at se følgende detajleret 

information: 

• Fejlrapporter 

• Hvilke aktører der har bestået en given test- 

case 

• Opsætningsparametre for en given testcase 

• Testdata for en given testcase 

Det skal være muligt at fremsøge og få vist stati- 

stik på en testcase indeholdende: 

• Hvor lang tid det tager at gennemføre testcasen 

• Start- og sluttidspunkt for gennemførelse af 

Dok. 31785/10, Sag 10/3365 116/132



Kravtype 


testcasen 

• Andel der har bestået 

• Andel der endnu ikke har bestået. 

03-234 K Fejlrapporter Aktørtestsystemet skal kunne levere detaljerede 

fejlrapporter til brugerne, hvis der opstår fejl i 

enkelte transaktioner. Fejlrapporterne skal kunne 

03-235 K Aktørers fremsøgning af testcases 

og forevisning af status 

03-236 K Aktørers søgeresultat ved frem- 

søgning af testcases 

præsenteres i brugergrænsefladen og downloades 

med henblik på videreformidling og fejlretning. 

Det skal til enhver tid være muligt for aktører at 

fremsøge igangværende og gennemførte testcases 

og se status herfor. Søgeparameterne skal som 

minimum være: 

• Testcase ID 

• Tidsinterval (start/slut) 

• Anvendt meddelelsestype 

• Anvendte testdata 

• Status på testen – herunder muligheden for 

at udtrække testrapporter 

• Forretningsproces hvori testcasen indgår 

• Anvendt system i testcasen 

• Bruger der har initieret testcasen 

• En oversigt over hvilke testcases der udestår i 

forhold til den endelige godkendelse 

I søgeresultatet skal ovenstående søgeparametre 

endvidere indgå direkte i søgeresultatet eller direkte 

i forlængelse af søgeresultatet. 

Ved fremsøgning af testcases skal søgeresultatet 

give brugeren et overblik over status på de enkelte 

testcases. Fra søgeresultatet skal brugeren 

have mulighed for at få adgang til yderligere detaljer 

for den enkelte testcase. 

Fra søgeresultatet skal brugeren have mulighed 

Dok. 31785/10, Sag 10/3365 117/132



Kravtype 


Tabel 7-5: Historik for testforløb kravtabel 

for at øge detaljeringsgraden på den enkelte testcase 

og bl.a. give adgang til indholdet af meddelelser 

i specifikke transaktioner, eventuelle fejl- 

rapporter samt godkendelsesstatus. 

Dok. 31785/10, Sag 10/3365 118/132



8. Ikke-funktionelle krav til arkitektur 




Portal 

Stamdata 


Rapportering 

Måledata 

Dataudtræk 





Testcases 



Testhistorik 








Platform 


Sikkerhed 

Datamigrering 

Dette afsnit beskriver de ikke-funktionelle krav til leverancen. Kravene er gældende for alle systemmiljøer 

der er indeholdt i leverancen, med mindre andet specifikt er angivet. 

8.1 Generelle arkitekturkrav 

Sikkerhedslag 

Figur 8-1: Løsningsarkitektur for systemerne 

Præsentationslag 

Forretningslag 

Datalag 

Løsningen forventes baseret på en simpel lagdelt arkitektur, som illustreret i Figur 8-1, hvor der 

i størst muligt omfang anvendes standardinterfaces mellem de enkelte lag. 

Arkitekturen består af følgende lag: 

Integrationslag 

Dok. 31785/10, Sag 10/3365 119/132



• Præsentationslag: Brugerens oplevelse af systemet præsenteret i en grafisk brugergrænseflade. 

Løsningen forventes overfor den almindelige bruger at være baseret på en 

webportal. 

Kravene til præsentationslaget er beskrevet i afsnit 5. 

• Forretningslag: Systemets forretningslogik er funktionelt indarbejdet i dette lag. 

Kravene til det logiske forretningslag er beskrevet i afsnittene 3.3 og 6.1. 

• Datalag: Laget indeholder alle lagrede data, relevante for systemet. 

• Integrationslag: Koblingen mellem de tre primære lag i systemet samt koblingen til interne 

og eksterne systemer mv. Laget består i praksis af mange lag mellem de tre primær 

lag også kaldet servicelaget. 

• Sikkerhedslag: Håndterer sikkerhed og rettighed i alle ovenstående lag 

Udover den forventede lagdelte arkitektur, er en modulær opbygning af systemet også i fokus. 

Det forventes, at et "Lego-klods"-princip kan følges. Dette kræver meget stærke og veldefinerede 

grænseflader mellem de enkelte moduler og omfattende brug af en systemmæssig udvekslingsstandard. 

Arkitekturen bør tage hensyn til, at det forventes at udviklingen går mod en mere udbredt brug 

af web services, som sikrer en bedre integration med bagved liggende automations processer. 

Dette kan tilgodeses ved, at f.eks. afsendelse af mail ikke direkte indlejres i portal applikationen, 

men udvikles i særskilte webservice moduler, som så kaldes fra portalen. Det betyder at portalen 

kan anvende både mail og eller webservices. 

Dok. 31785/10, Sag 10/3365 120/132



8.1.1 Generelle arkitekturkrav kravtabel 

Krav 

ID 

Kravtype 

MK/K/O 


03-237 MK Lagdelt arkitektur skal anvendes 

Udviklingsleverandøren skal tilbyde en løsning som 

opbygges lagdelt og modulopbygget med veldefine- 

rede og dokumenterede snitflader mellem de enkelte 

moduler i hvert lag. 

03-238 K Modulopbygget Systemet skal være modulopbygget, med stærke og 

veldefinerede grænseflader mellem modulerne, 

således at ét modul let kan udskiftes uden konsekvenser 

for øvrige moduler ("Lego-klods"-princip). 

03-239 K Opdelt software deployment Applikations opbygningen skal muliggøre opdelt eller 

differentieret deployment (på version og tid) mellem 

de enkelte moduler i det omfang det giver mening i 

forhold til den valgte modulstruktur. 

03-240 K Administrerbart software deployment Der skal forefindes let anvendelige procedurer som 

håndterer og administrerer deployment. 

03-241 MK Databaseplatform Databaseplatformen skal være baseret på en 

relationel database. 

03-242 K Databasedesign Forretningsprocesserne skal afspejles i databasedesignet, 

f.eks. ved opbygning af constraints 

der sikrer at der kun kan tilknyttes én elleverandør 

til et målepunkt på et givet tidspunkt. 

03-243 K Hierarkisk data management Systemet skal understøtte hierarkisk data management, 

dvs. arkivering af data på flere niveauer. 

03-244 K Navngivning af tabeller og felter 

03-245 MK Tidsstempling i database og visning 

af tidsstempler. 

Navngivning af tabeller, felter og funktioner skal 

være logiske og følge begreberne anvendt i forretningsprocesserne 

- i den udstrækning det er 

muligt. 

Alle tidsstempler skal gemmes i databasen i 

UTC+1 ("dansk normaltid") - mens alle visninger 

af tidsstempler i brugergrænseflade og rapporter, 

skal ske i "armbåndsurstid" - altså UTC+2 i 

dansk sommertidsperiode og UTC+1 i den øvrige 

del af kalenderåret. 

Dok. 31785/10, Sag 10/3365 121/132



03-246 K Applikationslog I tilfælde af at applikationen afvikles på Energinet.dk’s 

egne servere, skal alle applikationer 

logge evt. fejl og advarsler til en særskilt Win- 

dows applikations log, navngivet i samarbejde 

med Energinet.dk. 

Dette krav skal sikrer en mulighed for at Energinet.dk 

kan integrere overvågningen med øvrige 

systemer. 

03-247 K Web service som integration Systemets arkitektur bør tilgodese en forventet 

fremtidig øget anvendelse af webservices, som 

den primære integration med øvrige kommende 

systemer. 

03-248 K Modstandsdygtighed ift. fejl Der skal være rutiner, som sikrer, at fejl ikke 

efterlader systemet i en ustabil/udefineret til- 

Tabel 8-1: Generelle arkitekturkrav – kravtabel 

8.2 Platform og kommunikation 

stand. 

Infrastruktur omfatter i denne sammenhæng såvel platforme som kommunikationsinfrastruktur. 

DataHub, Aktørtestsystemet og webportal realiseres som en central service, dvs. platform og 

infrastruktur skal tilpasse sig dette efter følgende retningslinjer: 

• Systemerne i driftsmiljøet afvikles på et skalerbart centralt servermiljø, som dækker alle 

lag i målarkitekturen 

• Der skal også tilbydes Pre-produktionsmiljøer, som er identiske med Driftsmiljøet, og 

som anvendes til test af komplet konfigurerede nye versioner af systemerne. Samme 

miljø skal kunne anvendes til demo- og undervisningsformål, også for eksterne aktører. 

• Endvidere skal der forefindes udviklingsmiljøer og testmiljøer, der ikke nødvendigvis har 

samme konfiguration som drifts- og pre-produktionsmiljøerne, men hvis primære formål 

er test af rettelser eller test af nyudviklede funktioner. 

Kommunikationsinfrastrukturen er en vital og vigtig del af systemet, idet den samlede funktionalitet 

er afhængig af en tilgængelig, hurtig og velfungerende kommunikationsinfrastruktur. 

Dok. 31785/10, Sag 10/3365 122/132



8.2.1 Platform og kommunikation kravtabel 

Krav 

ID 

Krav- 

type 

MK/K/O 


Miljøer 

03-249 MK Skalerbart driftsmiljø Systemerne skal afvikles på et skalerbart centralt 

servermiljø, som dækker alle lag i Driftsmiljøet. 

03-250 MK Øvrige miljøer Der skal tilbydes pre-produktionsmiljøer, som er 

Platforme 

identiske med driftsmiljøet, og som skal anvendes 

til test af komplet konfigurerede nye versioner 

af systemerne. Samme miljø skal kunne anvendes 

til demo- og undervisningsformål, også 

for eksterne aktører. 

Endvidere skal der forefindes udviklingsmiljøer og 

testmiljøer, der ikke nødvendigvis har samme 

konfiguration som drifts- og produktionsmiljøerne, 

men hvis primære formål er test af rettelser 

eller nyudviklede funktioner. 

03-251 K Virtualisering af platform Det skal være muligt at virtualisere platformen 

og afvikle systemerne på virtuelle servere. 

03-252 K Gennemgående teknologier Alle elementer i systemerne skal leveres med 

brug af så få teknologier som muligt. Hvis dette 

krav ikke kan opfyldes skal leverandøren beskri- 

Hardware 

ve rationalet herfor. 

03-253 K Virtualisering Hardwaren skal være i stand til at håndtere vir- 

03-254 K Udveksling af data vha. HTTP og 

HTTPS 

Kommunikationsinfrastruktur 

tualisering af styresystemer. 

Det skal være muligt at udveksle data med andre 

systemer vha. HTTP og HTTPS protokollerne. Det 

er et krav, at alt der kører uden for Energinet.dk's 

netværk, baserer sig på HTTPS. 

Dok. 31785/10, Sag 10/3365 123/132



03-255 MK Ip-baseret kommunikation Al kommunikation ind og ud af systemet skal 

være ip-baseret (både v4 og v6) 

Tabel 8-2: Kommunikationsgrænseflader – kravtabel 

8.3 Integrationer 

Integrationslaget skal binde en række systemer sammen igennem en løst koblet eller meddelelsesbaseret 

integration, så der kan kommunikeres på tværs af DataHub-delsystemerne. Derover 

skal der integreres til øvrige interne og eksterne systemer 

Integrationerne står for selve koblingen og kommunikationen. 

Webportal 

Webservices 



Figur 8-2: Illustration af de forventede integrationer 

Der opereres med to typer af integrationer: 

Integrationslag 

NemId validering 

DanId 

Interne systemer 

SAP 

Mailserver 

SMS Gateway 

Webservice brugere 

Markedsaktører 

Eksterne registre 

CVR-register 

CPR-register 

• Interne integrationer imellem DataHub-delsystemer. Workflow-integrationer etableres 

ved orkestrering og sammensætning af flere processer. 

• Eksterne integrationer til øvrige systemer, som enten kan være interne systemer hos 

Energinet.dk, eller integrationer med eksterne registre. 

Afhængigt af, hvilke integrationer der vælges skal følgende generelle forhold søges sikret: 

• Stabilitet af den kommunikationskanal som sørger for kommunikationen 

• Kvalitet i data der udveksles 

• Kontrol med informationsflowet (herunder relation til recovery og roll-back) 

Dok. 31785/10, Sag 10/3365 124/132



8.3.1 Eksterne integrationer 

Af de interne systemer i Energinet.dk skal der etableres integrationer til eksisterende mailserver, 

SMS-Gateway og til Energinet.dk's SAP-system (via webservice). 

Al EDI-kommunikation med markedsaktørerne sker via asynkrone og synkrone webservice kald, 

der også skal håndteres af integrationslaget. 

For at kunne tilbyde datavask på stamdata, skal der etableres integrationer til opslag af informationer 

i CVR-registeret og CPR-registeret. 

Da der skal anvendes NemID som brugervalidering til portalen, skal der integreres til denne service. 

Dok. 31785/10, Sag 10/3365 125/132



8.3.2 Integrationer kravtabel 

Krav 

ID 

Krav- 

type 

MK/K/O 


03-256 K Integrationssystem Der skal anvendes ét system til håndtering af 

alle integrationer. 

03-257 K Konfigurering af integrationer Integrationerne er vitale for driften af systemet, 

og skal derfor indeholde gode værktøjer til overvågning 

og konfigurering. 

03-258 MK Fejlhåndtering Det skal være muligt at udføre recovery/rollback 

på fejlede transaktioner 

03-259 MK Integration til mailserver 

03-260 MK Integration til SMS Gateway 

03-261 K Standard API´er 

03-262 MK Import/eksport funktionalitet 

Tabel 8-3: Integrationer – kravtabel 

DataHub-systemet skal kunne udsende fejlrap- 

porter, statusrapport og andre beskeder som emails. 

Til dette formål skal DataHub'en kunne 

integrere med Energinet.dk's eksisterende mailserver 

der administreres som en separat del af 

driftsopsætningen. 

DataHub-systemet skal kunne udsende advis’er 

og andre beskeder som SMS. Til dette formål 

skal DataHub 'en kunne integrere med Energi- 

net.dk's eksisterende SMS Gateway der administreres 

som en separat del af driftsopsætningen. 

DataHub'en skal tilbyde åbne dokumenterede 

snitflader, som kan anvendes til at udvide funkti- 

onaliteten, ved at lade andre systemer interagere 

direkte med funktioner eller data i DataHub. 

DataHub'en skal kunne importere data fra og 

eksportere data til filer (f.eks. CSV), og derved 

kunne danne meget simple integrationer til proprietære 

systemer. Dette anvendes ved Data- 

Hub'ens integration med en række eksterne systemer. 

Dok. 31785/10, Sag 10/3365 126/132



9. Øvrige ikke-funktionelle krav 

9.1 Sikkerhed 

DataHub'en indeholder personfølsomme oplysninger, hvorfor der er krav om dels en sikker identifikation 

af brugerne, dels en sikker transport af data mellem systemer og dels en sikker metode 

til autorisation og kontrol af brugerrettigheder. Kravene til bruger- og rettighedsstyring er 

beskrevet i afsnit 4.2. 

9.1.1 Transaktionsspor og revisionsspor 

Eventuelle fejl i data eller i transaktioner (måledata, skift af elleverandør m.m.) kan få stor økonomisk 

konsekvens for netvirksomheder, elleverandører og balanceansvarlige, så det er nødvendigt 

med metoder til at sikre et godt transaktionsspor på alle transaktioner i systemet. 

Det skal være muligt at følge transaktionssporet for alle EDI-meddelelser. 

Ved ændringer i data (oprettelse, opdatering, sletning) skal alle dataændringen logges således, 

at der kan findes dokumentation for hvilken bruger der har ændret data, på hvilket tidspunkt det 

er sket, og hvilken ændring der er sket (data inden opdateringen skal gemmes). Dette gælder 

både målinger og stamdata. 

9.1.2 Sikkerhed kravtabel 

Nedenstående krav gælder kun DataHub'en, hvorimod kravene ikke stilles til Aktørtestsystemet. 


MK/K/O 


03-263 MK Transaktionsspor Det skal være muligt at følge transaktionssporet 

for alle EDI-meddelelser, og på alle forretningstransaktioner. 

03-264 MK Revisionsspor DataHub-systemet skal registrere information om 

en brugers (eller systemets) aktiviteter, således 

at der i relevante tilfælde er mulighed for, at 

etablere et revisionsspor eller udføre andre kontroller 

i forhold til anvendelsen af systemet. 

03-265 MK Logning af dataændringer Alle ændringer i data (målinger og stamdata) skal 

bevirke, at de oprindelige data (før ændringen) 

gemmes med oplysninger om, hvilken bruger der 

har ændret data, og på hvilket tidspunkt det er 

sket. 

Dok. 31785/10, Sag 10/3365 127/132




MK/K/O 


03-266 MK Visning af dataændringer Der skal findes skærmbilleder, der giver let adgang 

til de ændrede data ("skyggedatabase"), og 

giver overblik over de ændringer, der måtte være 

sket på data gennem tid. 

03-267 MK Egen sikkerhedszone Systemet skal befinde sig i sin egen sikkerhedszone, 

adskilt fra Energinet.dk's øvrige systemer. 

03-268 K Etablering af "auto-sluk" funktion Systemet skal indeholde en "auto-sluk" funktion 

(session time-out), som sikrer, at der ikke er adgang 

til systemet uden anvendelse af password, 

såfremt systemet ikke anvendes inden for et parametersat 

tidsrum angivet i minutter. 

03-269 K HTTPS ved webadgang Log-ind gennem webbrugergrænsefladen, skal 

foregå vha. HTTPS. 

03-270 K Sikring af fortrolighed af data 

som kommunikeres 

Kommunikationsinfrastrukturen skal tilbyde kryp- 

tering af forbindelserne, da de udvekslede data 

indeholder personfølsomme oplysninger. Denne 

kryptering kan enten etableres ved SSL eller via 

VPN forbindelser over netværket. 

03-271 K Opdatering af patches Basissoftware skal uden nævneværdige driftsforstyrrelser 

kunne opdateres med nødvendige patches, 

således at systemet altid er opdateret på 

anbefalet patchniveau. 

Tabel 9-1: Sikkerhed – kravtabel 

9.2 Implementering og datamigrering 

Ved implementeringen af Aktørtestsystemet og DataHub forestår der en ikke ubetydelig opgave 

med konfigurering af systemerne og migrering af data fra alle netvirksomhedermes systemer. 

Det forventes, at leverandøren deltager aktivt i denne proces i et tæt samarbejde med Energinet.dk. 

Dok. 31785/10, Sag 10/3365 128/132




MK/K/O 


03-272 MK Konfigurering af DataHub Det forventes, at leverandøren inddrager Energinet.dk 

aktivt i konfigureringen af hele DataHub- 

systemet, bl.a. til opsætning af nødvendige work- 

flows svarende til forretningsprocesserne, og opsætning 

af brugere, brugergrupper og rettigheder 

til disse. 

03-273 MK Konfigurering af Aktørtestsystem Det forventes, at leverandøren inddrager Energi- 

net.dk aktivt i konfigureringen af Aktørtestsystemet, 

bl.a. til opsætning testcases. Der forventes 

at skulle oprettes ca. 150 testcases. 

Systemet skal være færdigkonfigureret til at ud- 

føre system- og aktørtest mod samtlige relevante 

aktører og it-leverandører i markedet. 

03-274 MK Konfigurering af webportal Det forventes, at leverandøren inddrager Energinet.dk 

aktivt i konfigureringen af webportalen, 

f.eks. opsætning af hjælpetekster. 

03-275 MK Konfigurering af integrationer Ved integrationen til øvrige systemer, forventes 

leverandøren at gå aktivt ind i rollen ved konfigureringen 

i et tæt samarbejde med Energinet.dk 

03-276 MK Datamigrering Leverandøren forventes at indgå i et tæt samarbejde 

med Energinet.dk ved løsningen af opgaven 

med migrering af data fra netvirksomhedernes 

Tabel 9-2: Implementering og datamigrering – kravtabel 

9.3 Uddannelse 

systemer. Opgaven skal løses i et tæt samarbejde 

med alle netvirksomhederne, og indbefatter f.eks. 

aftale om dataformater, datavask m.v.. 

Som beskrevet i Bilag 1, skal Leverandøren levere uddannelse af henholdsvis projektdeltagere 

og superbrugere. Herunder hører også forberedelse af uddannelsesforløb. 

Dok. 31785/10, Sag 10/3365 129/132




MK/K/O 


03-277 K Uddannelse Leverandøren skal bistå med uddannelse af superbrugere 

og projektdeltagere, herunder udarbejdelse 

af uddannelsesstrategi, uddannelsespro- 

03-278 O Oplæring af Kundens driftsmedarbejdere 

Tabel 9-3: Uddannelse – kravtabel 

9.4 Drift 


MK/K/O 


gram, materiale og gennemførelse af uddannelse 

af brugere. 

Leverandøren skal planlægge og gennemføre uddannelse 

af Kundens driftsmedarbejdere. 

03-279 O Drift Leverandøren skal tilbyde at varetage driften af 

løsningen i overensstemmelse med kravene i bilag 

7. 

Tabel 9-4: Drift – kravtabel 

Dok. 31785/10, Sag 10/3365 130/132



10. Tabel- og figuroversigt 

Tabeloversigt 

Tabel 3-1: Vision kravtabel .............................................................................................. 20 

Tabel 3-2: Markedsforskrifter........................................................................................... 22 

Tabel 3-3: Forretningsprocesser i elmarkedet (Business Requirement Specifications) .............. 23 

Tabel 4-1: Administration af system - kravtabel ................................................................. 29 

Tabel 4-2: Bruger- og rettighedsstyring - kravtabel ............................................................ 32 

Tabel 4-3: Workflow – kravtabel....................................................................................... 34 

Tabel 4-4: Rapportering – kravtabel ................................................................................. 35 

Tabel 4-5:Funktionalitet af webservices............................................................................. 35 

Tabel 4-6: Dataudveksling - kravtabel............................................................................... 36 

Tabel 4-7: Alternativ webadgang for kunder - kravtabel ...................................................... 37 

Tabel 5-1 Overordnede funktioner .................................................................................... 48 

Tabel 5-2: Funktioner per brugergruppe i Aktørtestsystemet................................................ 49 

Tabel 5-3: Selvbetjeningsportalen – Kravtabel ................................................................... 64 

Tabel 6-1: Markedsprocesser kravtabel ............................................................................. 68 

Tabel 6-2: Stamdata - kravtabel....................................................................................... 78 

Tabel 6-3: Måledata - kravtabel ....................................................................................... 81 

Tabel 6-4: Beregningsfunktioner ...................................................................................... 83 

Tabel 6-5: Beregningsfunktion - kravtabel ......................................................................... 84 

Tabel 6-6: Residualforbrug, andelstal, fordelte forbrug og saldoafregning kravtabel ................ 87 

Tabel 6-7: Samfakturering kravtabel................................................................................. 88 

Tabel 6-8: KPI på måledata kravtabel ............................................................................... 91 

Tabel 6-9: Dataudtræk kravtabel...................................................................................... 92 

Tabel 6-10: Rapportering kravtabel .................................................................................. 94 

Tabel 7-1: Overordnede kravtabel .................................................................................. 102 

Tabel 7-2: Registrering af it-system kravtabel.................................................................. 103 

Tabel 7-3: Administration af testforløb kravtabel .............................................................. 113 

Tabel 7-4: Godkendelse af testforløb kravtabel................................................................. 114 

Tabel 7-5: Historik for testforløb kravtabel....................................................................... 118 

Tabel 8-1: Generelle arkitekturkrav – kravtabel................................................................ 122 

Tabel 8-2: Kommunikationsgrænseflader – kravtabel........................................................ 124 

Tabel 8-3: Integrationer – kravtabel ............................................................................... 126 

Tabel 9-1: Sikkerhed – kravtabel.................................................................................... 128 

Tabel 9-2: Implementering og datamigrering – kravtabel .................................................. 129 

Tabel 9-3: Uddannelse – kravtabel ................................................................................. 130 

Tabel 9-4: Drift – kravtabel ........................................................................................... 130 

Figuroversigt 

Figur 1-1: Opbygning af kravspecifikationen ........................................................................6 

Figur 2-1: Illustrerer principperne for elmarkedet og viser de aktører, der agerer i markedet. .. 10 

Figur 3-1: Centrale dokumenter ....................................................................................... 12 

Figur 3-2: Illustration af DataHub'ens interessenter og funktioner. ....................................... 13 

Figur 3-3: Model for elbiler der lader ved offentlige ladestandere.......................................... 17 

Dok. 31785/10, Sag 10/3365 131/132



Figur 3-4: Panda ............................................................................................................ 19 

Figur 3-5: Oversigt over brugeradgang ............................................................................. 23 

Figur 5-1: Oversigt over Selvbetjeningsportal .................................................................... 50 

Figur 5-2: Applikationsopbygning af SBP ........................................................................... 62 

Figur 5-3: Nuværende arkitektur tegning........................................................................... 63 

Figur 6-1: Samlet logisk datamodel .................................................................................. 69 

Figur 6-2: Tilstandsdiagram for et Målepunkt ..................................................................... 71 

Figur 6-3: Eks. på visning af stamdata for målepunkt.......................................................... 74 

Figur 6-4: Eksempel på visning af tidsseriedata.................................................................. 79 

Figur 6-5: Nettoafregnet produktionsanlæg ....................................................................... 82 

Figur 6-6: Sammenhæng mellem stamdata for målepunkterne, nettoafregning ...................... 83 

Figur 6-7: Eksempel på offentliggørelse af residualforbrug................................................... 85 

Figur 6-8: Påtænkt dataflow i forbindelse med Samfakturering............................................. 87 

Figur 7-1: Testtyper........................................................................................................ 97 

Figur 7-2: System- og aktørlandskab ................................................................................ 98 

Figur 7-3: Model for transaktion i Aktørtestsystemet........................................................... 99 

Figur 7-4: Testbegreber og indbyrdes sammenhæng......................................................... 104 

Figur 7-5: Testcase eksempel ........................................................................................ 105 

Figur 7-6: Eksempel på definition af testcase ................................................................... 106 

Figur 7-7: Administration af testcases kravtabel ............................................................... 108 

Figur 7-8: Eksempel på opsætning af testdata ................................................................. 108 

Figur 7-9: Administration af testdata kravtabel ................................................................ 110 

Figur 7-10: Eksempel på oversigt over testforløb.............................................................. 110 

Figur 7-11: Eksempel på statusmelding fra testforløb........................................................ 111 

Figur 7-12: Eksempel på detaljeret beskrivelse af valideringsfejl ........................................ 111 

Figur 7-13: Eksempel på godkendelse af systemtest ......................................................... 113 

Figur 7-14: Eksempel på oversigt over testkørsel ............................................................. 115 

Figur 7-15: Eksempel på oversigt over testforløb.............................................................. 115 

Figur 8-1: Løsningsarkitektur for systemerne ................................................................... 119 

Figur 8-2: Illustration af de forventede integrationer......................................................... 124 

Dok. 31785/10, Sag 10/3365 132/132

DataHub - Bilag 3a - Kundens kravspecifikation - Energinet.dk

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?