Eindverslag
Auteur: Ernst Lawende Datum: 15 augustus 2008 Versie: 1.0
Afstudeerbedrijf: Logica
Bedrijfsbegeleiders: Bram Vranken Edwin Essenius Bedrijfsmentor: Eric Zuur
Onderwijsinstelling: Avans Hogeschool, Breda Opleiding: Technische Informatica Docentbegeleider: Wil de Groot – van Velde
Versiebeheer
Versie Omschrijving0.1 Tussentijdse versie, opgeleverd ter beoordeling door docent- en bedrijfsbegeleider
0.2 Tussentijdse versie, opgeleverd ter beoordeling door bedrijfsbegeleider
0.3 Tussentijdse versie, opgeleverd ter beoordeling door docentbegeleider, architect en mentor
Voorwoord
Na vier jaar onderwijs aan de Avans Hogeschool te Breda, ben ik nu
toegekomen aan het afstuderen. Met veel plezier heb ik de studie technische informatica gevolgd, met software engineering als uitstroomprofiel. Dit
document is de afstudeerscriptie. Samen met de ontwikkelde software vormt dit het eindproduct van mijn afstudeerstage.
De primaire doelgroep van dit document is de docentbegeleiding, die de afstudeerstage zal beoordelen. Het document is tevens een middel om de opgedane kennis te delen binnen de afstudeerorganisatie (Logica).
Graag wil ik de mensen bedanken die mij tijdens de afstudeerstage hebben geholpen en zo een bijdrage hebben geleverd aan het eindresultaat. Ten eerste is dank verschuldigd aan de bedrijfsbegeleider, Bram Vranken. Zijn stijl van begeleiding werkt erg motiverend. Dank gaat ook uit naar Martin van Amersfoorth, de eerste architect (inhoudelijk begeleider) tijdens mijn
afstudeerstage. Zijn analytische kijk op problemen laat anderen de zaken van nieuwe invalshoeken bekijken en dwingt mensen na te denken over de
validiteit. Zijn opvolger, Edwin Essenius, valt op door de ervaring uit de praktijk. Praktijkervaring en kennis van de energiemarkt zijn ook ingebracht door Ronald Oreel (hij heeft geholpen met het bepalen van de afstudeeropdracht) en Eric Zuur (uit de rol van mentor wist hij veel te vertellen over de werkzaamheden en over Logica). Dank gaat ook uit naar mijn manager, Rob Martens, vooral om zijn interesse in de werkzaamheden van de vele medewerkers. Daarnaast wil ik mijn mede afstudeerders op de afdeling bedanken. In het bijzonder Emil
Verwoerd, voor zijn hulp op momenten dat ik vast kwam te zitten. Tot slot is dank verschuldigd aan mijn docentbegeleider, Wil de Groot – van Velde. Haar interesse een vooral haar inzet is altijd een opsteker.
Rotterdam, 24 juli 2008 Ernst Lawende
Samenvatting
Omdat elektriciteit lastig is op te slaan, moet het na productie direct worden gebruikt door consumenten. Een efficiënte elektriciteitsmarkt vraagt dus een goede afstemming tussen vraag en aanbod. Bij het bepalen van de benodigde productiecapaciteit wordt uitgegaan van voorspellingen die de dag van tevoren zijn opgesteld. Het voorspellen is lastig en dus zal de werkelijke vraag (en het aanbod) altijd iets afwijken. Deze afwijking wordt onbalans genoemd. Om dit verschil op te vangen worden doorgaans energiecentrales in- en uitgeschakeld. Als aanvulling hierop kan de vraag naar elektriciteit worden aangepast. Dit kan wellicht door advies en voorlichting, maar ook door gebruik te maken van nieuwe technologie. Zogenoemde slimme meters kunnen per huishouden actuele waarden geven over het verbruik. In combinatie met domotica geeft dit vele mogelijkheden om de elektriciteitsvraag op afstand aan te passen (het gaat hier wel om aanpassingen waar de consument niet of nauwelijks iets van merkt). Omdat het gaat om nieuwe ontwikkelingen, is er nog weinig bekend over de mate waarin deze techniek kan bijdragen aan het reduceren van onbalans. Het onderzoeken van dit effect, is de doelstelling van het project. Methoden om vraag en aanbod van elektriciteit beter op elkaar af te stemmen noemen we piekreductie of ‘peak shaving’.
Een consistente en gestructureerde manier waarop de energievraag wordt aangepast, wordt binnen dit project een interventie genoemd. Er zijn drie interventies opgesteld waarvan wordt verwacht dat zij een grote bijdrage
leveren aan piekreductie. Het gaat ten eerste om een variabele elektriciteitsprijs (de prijs is afhankelijk van de actuele vraag). Bij de andere twee interventies worden geautomatiseerde ingrepen gedaan in huishoudelijke apparaten (via domotica). De eerste van deze interventies is het aanpassen van de ingestelde temperatuur, van koelende apparaten (airconditioning, vriezer en koelkast). Een tijdelijke verhoging in de ingestelde temperatuur zorgt voor een lager
elektriciteitsverbruik. De laatste interventie is het aanpassen van ingestelde tijden. Sommige apparaten (vooral witgoed) beschikken over een timer functie. Dat het apparaat exact op de ingestelde tijd begint is vaak niet essentieel. Er kunnen dus kleine aanpassingen worden gemaakt, als dit het doel van piekreductie dient.
Om de interventies te valideren is een simulatie ontwikkeld. Deze software genereert een energievraag van een groep consumenten, op basis van
gebruikersprofielen en de buitentemperatuur. Op deze energievraag wordt een van de drie soorten interventies toegepast. Na afloop van de simulatie wordt er getoond of de interventies tot minder onbalans hebben geleid. Dit is de bijdrage die de interventie heeft aan piekreductie.
Door het ontbreken van voldoende gedetailleerde informatie over de elektriciteitsvraag, zijn gebruikersprofielen deels gebaseerd op schattingen. Hierdoor kunnen geen harde uitspraken worden gedaan over het effect van de interventies. Wel is duidelijk dat er een aantal interventies mogelijk zijn waarvan we kunnen verwachten dat zij een bijdrage leveren aan piekreductie.
Aanbevelingen zijn onder andere het onderzoeken van de elektriciteitsvraag en verder onderzoek naar de mogelijkheden van slimme meters en domotica.
Summary
Storing electricity is a difficult task. After production, customers should thus use the energy immediately. For the electricity market, a good balance between supply and demand has huge benefits. In order to reap these benefits, forecasts are made 24 hours in advance. These are used to determine the required production capacity. Because predicting electricity demand is tricky, actual demand (and supply) will always deviate. In order to overcome this, some power plants will be switched on or off. To complement this, the electricity demand can be altered. This can probably be achieved by informing the
consumers, but can also be done by applying new technology. So called smart meters will supply actual data about energy demand, per household. When this is combined with domotics, new ways are created for the electricity supplier to alter the electricity demand (this should be about changes which aren’t
annoying to the customer). Because the technology is cutting edge, little is known about the technology’s effects on reducing the difference between predicted and actual electricity demand. The goal of this project is to research this effect. Efforts for a better balance between supply and demand are called peak reduction or peak shaving.
Within this project, a consistent and structured method to alter the electricity demand is called an intervention. Three interventions are formulated, which are expected to have a large effect on peak reduction. The first one is a variable electricity price (the price is dependent on actual demand). The other two interventions will make automatic changes in the use of household appliances (by using domotics). The first of these is making small changes in the
temperature setting of cooling devices (air conditioning, fridge and refrigerator). A temporary increase in the temperature setting will cause a lower electricity usage. The last intervention is about making changes to the device’s timer settings. Some devices (especially washing machines) have a timer function to start a device. It is most often not essential to start the device at the exact time set. This means small changes can be made, which can contribute to peak reduction.
A simulation is developed to validate the interventions. The developed software generates an electricity demand for multiple consumers, based on consumer profiles and the outside temperature. One of the interventions is applied to the simulated demand. After the simulation, the effects of the intervention are shown to the user.
Due to the lack of enough detailed information about electricity demand, consumer profiles are partially based on estimates. This makes it difficult to make any hard statements about the effect the interventions have to peak reduction. It can be said, that there are multiple possible interventions for which an effect to peak reduction is reasonable. Recommendations include
researching the electricity demand and further research in the utilizations of smart meters in combination with domotics.
Inhoudsopgave
Inleiding ... 1
1. Plaats van de afstudeerder binnen de organisatie ... 2
1.1. Logica ... 2 1.2. Werkomgeving ... 2 2. Probleemanalyse ... 4 2.1. Probleemsituatie ... 4 2.2. Doelstelling ... 7 2.3. Deelvragen ... 7
3. Plan van Aanpak ... 9
3.1. Projectopdracht... 9 3.2. Projectgrenzen ... 10 3.3. Projectactiviteiten ... 11 3.4. Producten ... 11 3.5. Planning ... 12 3.6. Kosten en baten... 12 3.7. Risico’s ... 13 4. Methoden en technieken ... 15 4.1. Methoden... 15 4.2. Technieken en tools ... 15 5. Uitvoering ... 18 5.1. Oriëntatie ... 18
5.2. Opstellen van user stories ... 19
5.3. User interface ... 21
5.4. Gebruikersprofielen ... 22
5.5. Simulatie ... 26
5.6. Interventies en combineren van gebruikersprofielen ... 28
5.7. Implementatie van interventies ... 31
6. Resultaten ... 34 6.1. Onderzoeksresultaten ... 34 6.2. Demonstratie ... 39 7. Conclusies en aanbevelingen ... 42 7.1. Conclusies ... 42 7.2. Aanbevelingen ... 43
Bijlage I: User stories ... i
Bijlage II: Planning ... v
Bijlage III: Geregelde apparaten ... vi
Bijlage IV: Gebruikersprofielen ... vii
Bijlage V: Klassendiagrammen ... xiii
Bijlage VI: Acceptatietest ... xv
Bronvermelding ... xvii
Inleiding
Dit document vormt de afsluiting van het afstudeerproject en is, samen met de ontwikkelde software, het eindproduct. Het document volgt in principe op het plan van aanpak. Het geeft aan hoe er vorm is gegeven aan dit plan en wat de resultaten zijn.
Naast de onderzoeksresultaten en een beschrijving van de software, bevat dit document ook een procesverslag. De doelstelling van dit eindverslag is dus niet alleen te beschrijven wat er is gedaan, maar ook hoe en waarom.
Lezers die bekend zijn met de doelstelling en de aanpak van het project, kunnen beginnen met lezen vanaf hoofdstuk 4.
In het eerste hoofdstuk wordt een beeld geschetst van het bedrijf en de directe werkomgeving waarbinnen het project wordt uitgevoerd. Het tweede hoofdstuk (‘Probleemanalyse’) gaat in op de energiemarkt en geeft de doelstelling van het project. In het derde hoofdstuk is een samenvatting te vinden van het plan van aanpak. De opvolgende hoofdstukken geven aan wat de resultaten zijn en hoe deze tot stand zijn gekomen. Ten eerste worden in hoofdstuk 4 de gebruikte methoden en technieken beschreven. Ook worden hier de keuzes voor deze methoden en technieken toegelicht. Hoofdstuk 5 bevat het procesverslag. Er wordt beschreven hoe er invulling is gegeven aan het plan van aanpak door gemaakte keuzes te beschrijven en toe te lichten. Het hoofdstuk bevat ook technische details, die de architectuur aangeven die is gebruikt om de software te ontwikkelen. Om deze technische details te begrijpen is de nodige
voorkennis vereist. Het hoofdstuk ‘Resultaten’ bevat de onderzoeksresultaten en een functionele beschrijving van de software. Hier wordt, voor zover mogelijk, antwoord gegeven op de onderzoeksvragen. Tot slot worden conclusies en aanbevelingen gedaan.
1. Plaats van de afstudeerder binnen de organisatie
Het project wordt individueel uitgevoerd, maar niet zonder de middelen, kennis en begeleiding van de organisatie waarbinnen het project valt. In dit hoofdstuk wordt er ingegaan op het afstudeerbedrijf en de werkomgeving (wie er bij het project zijn betrokken en aan wie er wordt gerapporteerd).1.1. Logica
De afstudeeropdracht wordt uitgevoerd binnen Logica te Rotterdam. Het bedrijf heette tot 27 februari 2008 nog LogicaCMG, welk in 2002 is ontstaan uit Logica en CMG. Beide ICT-dienstverleners zijn van oorsprong Engelse bedrijven, maar CMG was in Nederland veel groter dan de Engelse moeder. Sinds 13 januari 2006 is tevens het Franse Unilog onderdeel van het bedrijf. Logica is een internationale ICT-dienstverlener en heeft wereldwijd meer dan 35.000
werknemers in 36 verschillende landen in dienst. Het behoort, ook qua omzet, tot de internationale top-20 in de ICT-dienstverlening. De omzet uit de
traditionele ICT-dienstverlening wordt voornamelijk in Europa en Australië (als continent) gehaald. De omzet uit de rest van de wereld is sterk gebonden aan de telecommunicatie-industrie. Logica levert diensten op tal van terreinen, zoals management- en ICT-consultancy, systeemontwikkeling en –integratie en neemt voor klanten complete bedrijfsprocessen in beheer. De missie van Logica is als volgt geformuleerd:
“To become the most trusted innovation partner, creating sustainable business value by using our local insight and global talent.”
Logica Nederland is opgedeeld in meerdere divisies, verdeeld naar markt. De afstudeeropdracht wordt uitgevoerd binnen de divisie Energy, Utilities en
Telecom (EUT). De opdracht heeft te maken met utilities, waarmee de bedrijven worden aangeduid die de distributie van elektriciteit verzorgen (van
energiecentrales naar huishoudens). De divisies zijn opgedeeld naar werkzaamheden (competenties). Er wordt gewerkt binnen de competentie Java/SOA.
Het project wordt uitgevoerd onder begeleiding van Working Tomorrow (de ‘afstudeerdivisie’ van Logica). Dit is een gedeelte binnen de organisatie dat speciaal is opgezet voor afstudeerders. Hier bevinden zich meer dan 20 afstudeerders met een informatica gerelateerde opleiding.
1.2. Werkomgeving
Er zijn verschillende personen bij het project betrokken. Vanuit Working Tomorrow wordt de begeleiding verzorgd door Bram Vranken
(bedrijfsbegeleider) en Edwin Essenius (architect). De architect geeft
de voortgang en het proces. Vanuit de hogeschool is Wil de Groot – van Velde aangesteld als docentbegeleider.
De uit te voeren opdracht valt onder de divisie EUT. Binnen deze divisie bevinden zich de mentor en de secretaresse van de afstudeerder. Dit zijn respectievelijk Eric Zuur en Rebecca van den Berg. Tot slot is er ook een competence manager (de manager van de compententie Java/SOA, binnen de divisie EUT). Deze functie wordt vervuld door Rob Martens. Hij houdt zich voornamelijk bezig met de kennis en carrière van medewerkers.
Iedere twee weken zal er een voortgangsrapportage worden gestuurd naar de docentbegeleider. Om de vier weken wordt er een overleg ingepland met de bedrijfsbegeleider. Gedurende de afstudeerstage zal er een aantal keer overleg plaatsvinden met de mentor en met de competence manager.
2. Probleemanalyse
Het project gaat over het afstemmen van vraag en aanbod in de energiemarkt. In dit hoofdstuk wordt het probleem en de doelstelling uiteengezet.
2.1. Probleemsituatie
Het afstemmen van de vraag en aanbod is een lastig probleem, zeker in de energiemarkt. Binnen deze paragraaf wordt dit onderwerp behandeld, inclusief de organisatie en nieuwe technieken die hierbij komen kijken.
2.1.1. Vraag en aanbod
Elektriciteit kan niet zonder meer worden opgeslagen1 en moet daarom, na productie, direct naar de afnemers (consumenten) worden getransporteerd. Er moet continu genoeg elektriciteit worden geproduceerd om in de vraag te voorzien. Als de vraag groter is dan het aanbod, zal de elektriciteit uitvallen. Als het aanbod groter is dan de vraag, gaat er energie verloren. In het laatste geval wordt er gesproken van overproductie. Om deze redenen is het in de
elektriciteitsmarkt essentieel om de vraag en het aanbod goed op elkaar af te stemmen.
De distributie van elektriciteit, van de centrales naar de regionale
distributienetwerken gaat via hoogspanningskabels. Binnen het netwerk van deze hoogspanningskabels zijn vaak meerdere routes mogelijk. Er zijn kabels voor lange afstanden en voor regionaal transport. Voor lange afstanden wordt het hoogste voltage gebruikt (in Nederland is dit 380kV). Voor regionaal transport worden verschillende voltages gebruikt, van 10kV tot 150kV. Voor alle hoogspanningskabels geldt een restrictie voor de hoeveelheid elektriciteit die deze kan transporteren. Om deze reden zijn stroomuitval en piekreductie deels een lokaal probleem.
2.1.2. Piekreductie
Als de elektriciteitsvraag van een groot aantal consumenten in een grafiek wordt uitgezet, bevat deze diverse pieken en dalen. De verschillen tussen vraag en aanbod worden meestal opgevangen door het aanbod aan te passen. Hiervoor worden elektriciteitscentrales gebruikt die snel in te zetten zijn (deze centrales worden ‘peaker plants’ genoemd). In de meeste gevallen gaat het om een gascentrale. Een alternatief is het aanpassen van de vraag. In een aantal Amerikaanse staten bestaat er een ‘demand response’ programma.
1 Elektriciteit kan (als gelijkstroom) in accu’s worden opgeslagen, of er kunnen
Grootverbruikers worden dan, in tijden dat dat nodig is, gevraagd hun energiegebruik te reduceren. Zij kunnen hiervoor een financiële beloning ontvangen. De genoemde methoden werken voor voorspelde pieken die tenminste enkele uren duren. Uit historische gegevens is bekend wat het effect is van bijvoorbeeld een warme zomermiddag is op het energieverbruik. Deze situaties zijn vrij voorspelbaar.
Nieuw is het aanpassen van de vraag via domotica1 en (digitale) slimme energiemeters (zie §2.1.4). Een interessant project dat op dit gebied (buiten Logica) is uitgevoerd, is het GoodWatts project [BOIS06]. Hierbij zijn
Amerikaanse huishoudens (in Ashland, Oregon) voorzien van apparatuur die direct in kan grijpen in het energieverbruik. De energieleverancier had hierbij invloed op de thermostaat, de waterverwarming en eventueel de pomp van het zwembad. Tegenwoordig bieden enkele Amerikaanse energieleveranciers een dergelijke dienst aan.
Met de slimme energiemeters is het mogelijk om gedetailleerde en actuele meetgegevens te gebruiken. Als reactie op actuele gegevens kan de vraag worden beïnvloed om kleinere (minder voorspelbare) pieken te reduceren. Welke resultaten hiervan te verwachten zijn, is grotendeels onbekend.
Als pieken in de elektriciteitsvraag effectief worden gereduceerd, levert dit grote maatschappelijke voordelen op. Door een betere afstemming tussen vraag en aanbod zal er minder overproductie zijn. Als de hoogste pieken afnemen wordt er ook minder vereist van de hoogspanningskabels die de elektriciteit
transporteren, waardoor het aanleggen van hoogspanningskabels soms kan worden vermeden. Door de kleinere overproductie en een kleiner aantal hoogspanningskabels zal de hele energievoorziening minder geld kosten en milieuvriendelijker zijn.
2.1.3. Nederlandse energiemarkt
Bedrijven die het beheer hebben over hoogspanningskabels worden
Transmission System Operators (TSO’s) genoemd. Binnen Nederland heeft TenneT het monopolie op deze markt. Zij leveren de energie aan diverse regionale netwerkbeheerders die op hun beurt zorgen voor de levering aan huishoudens.
Leveranciers kopen hun stroom in bij programmaverantwoordelijken (PV partijen). Een PV koopt stroom in tegen marktprijs en verkoopt deze tegen een afgesproken prijs. Zij moeten dagelijks aan TenneT doorgeven hoeveel energie zij verwachten af te nemen (zij geven dit op per kwartier). Als deze voorspelling afwijkt van het werkelijke verbruik, ontstaat er een onbalans. TenneT
demotiveert onbalans door hier financiële consequenties aan te stellen. In het Nederlandse (geliberaliseerde) model bestaan er verschillende energieleveranciers. Zij verlenen service naar consumenten toe en zullen
1
uiteindelijk ook de kosten voor de gehele energievoorziening aan de consument factureren [BCON07]. Consumenten zijn vrij om een energieleverancier te kiezen.
De meeste grote leveranciers treden zelf op als PV.
2.1.4. Slimme energiemeters
Een grote verandering in de energiemarkt, die op dit moment gaande is, is de invoering van (digitale) slimme energiemeters. Binnen een aantal jaar moeten alle analoge energiemeters (te herkennen aan de draaiende schijf) worden vervangen door digitale versies, die meer functionaliteiten kunnen bieden. Vanuit het oogpunt van utility bedrijven hebben de analoge meters een aantal nadelen ten opzichte van de nieuwe varianten:
• Consumenten geven zelf hun meterstanden op
• Er is geen actuele/gedetailleerde informatie over het stroomverbruik Er moet af en toe een controleur langs komen om te controleren of de
opgegeven meterstanden juist zijn. In Nederland maakt de energieleverancier vooraf een schatting, waarna een voorschot wordt betaald. Deze schattingen kunnen afwijken, waardoor een consument soms ineens meer moet betalen, of juist geld terug krijgt. In sommige landen is om deze reden prepaid stroom ingevoerd [REJI05]. De gebruikte (digitale) energiemeter maakt doorgaans gebruik van een directe, digitale verbinding tussen de stroommeter en het energiebedrijf. Via deze verbinding worden dan de meterstanden doorgestuurd. Soms worden gegevens de andere kant op gestuurd, bijvoorbeeld wanneer een huishouden moet worden afgesloten. Schematisch ziet deze opstelling er als volgt uit:
Figuur 1: Communicatie met energiemeter
In het schema wordt de stroomkabel zelf gebruikt als communicatielijn. Deze vorm van communicatie wordt meestal aangeduid met de Engelse term Power Line Communication (PLC).
Het laatstgenoemde nadeel van de analoge meter is het ontbreken van actuele en gedetailleerde informatie over het energieverbruik. De utility bedrijven ontvangen van de huishoudens alleen maar jaarlijkse meterstanden. Met digitale energiemeters kunnen PV partijen over meer gedetailleerde informatie
beschikken, die zij kunnen gebruiken in voorspellingen en adviezen aan de consument1.
2.2. Doelstelling
Het afstemmen van het aanbod van elektriciteit wordt bemoeilijkt door de pieken in de vraag. Er zijn diverse toepassingen van slimme meters denkbaar, die de pieken in de vraag naar elektriciteit kunnen reduceren. Hoe dit het beste gerealiseerd kan worden en wat het effect zal zijn, is grotendeels onduidelijk. Uit dit probleem volgt de doelstelling van dit project:
“Inzicht verkijgen in de mate waarin ingrepen op microniveau kunnen bijdragen aan het reduceren van pieken in de elektriciteitsvraag op macroniveau en wat de beste strategie zal zijn om dit te bereiken.” Het gaat hier voornamelijk om de vele kleine, onvoorspelbare pieken in de vraag. Met het microniveau wordt één kantoor of huishouden bedoeld. De elektriciteitsvraag op macroniveau gaat over de totale elektriciteitsvraag van een grotere groep consumenten, zoals een hele woonwijk.
Met een strategie wordt een combinatie bedoeld van diverse interventies in de energievraag (op micro-niveau). Een interventie is een soort ingreep die kan worden uitgevoerd op een specifiek huishouden, of zelfs een specifiek apparaat.
Het resultaat van dit onderzoek levert inzicht op in het potentieel voor piekreductie, op het niveau van kantoren en huishoudens. Er zal bekend
worden hoe nuttig het beïnvloeden van huishoudelijke apparaten (via domotica) is en wat de beste manier zal zijn om dit doel te bereiken. Het is belangrijk dat deze inzichten op een duidelijke manier worden overgebracht, zodat betrokken partijen het effect en nut van piekreductie kunnen zien.
2.3. Deelvragen
Om het doel te bereiken zijn er een viertal deelvragen opgesteld:
1. Hoe ziet de energievraag van verschillende consumentengroepen er uit?
2. Op welke manieren kan de consument zijn energievraag aanpassen? 3. Wat zijn mogelijke interventies om invloed uit te oefenen op de
energievraag en welke informatie is er dan benodigd van consumenten? 4. Wat is het effect van de mogelijke interventies in diverse situaties? Met de situaties in deelvraag 4 worden de diverse consumentengroepen bedoeld (zoals kantoren, vinex-wijken, achterstandsbuurten…) maar ook
1
externe omstandigheden. Er wordt bijvoorbeeld, bij wijze van worst-case scenario, gekeken naar het effect tijdens een hittegolf.
In het hoofdstuk ‘Resultaten’ moet antwoord worden gegeven op de eerste drie deelvragen. Voor het beantwoorden van de laatste deelvraag wordt een
demonstratie ontwikkeld. Een beschrijving van dit product is te vinden in de laatste paragraaf van het hoofdstuk (§6.2).
3. Plan van Aanpak
In dit hoofdstuk wordt een overzicht gegeven van de opdracht en het plan om deze uit te voeren. Dit is een samenvatting van het oorspronkelijke plan van aanpak, dat afzonderlijk is gepubliceerd (de laatste versie is 1.0). In ‘planning’ (§3.5) is de meest recente planning gegeven.
3.1. Projectopdracht
De opdracht die zal worden uitgevoerd, is als volgt geformuleerd:
“Onderzoek de mate waarin invloed kan worden uitgeoefend op de vraag naar energie en wat de beste manier is om dit te bereiken. Valideer de onderzoeksresultaten met behulp van een simulatie.”
De manier om invloed uit te oefenen op de elektriciteitsvraag wordt gevormd door interventies, die bij consumenten worden gedaan. Er wordt onderzocht welke interventies dit zijn en welke aanpassingen zij zullen bereiken. De energievraag wordt veroorzaakt door consumenten en dus is het belangrijk te weten hoe hun individuele vraag er uit ziet. Hiervoor worden gebruikersprofielen opgesteld.
Voor de evaluatie van het onderzoek zal een softwaresysteem worden
ontwikkeld dat het effect van de interventies kan demonstreren. Onderstaande afbeelding geeft een globaal overzicht van dit systeem:
Gebruikersprofielen Buitentemperatuur Resultaten Simulatie Interventies Energievraag van huishoudens
Figuur 2: Overzicht van het systeem
De simulatie geeft, op basis van dynamisch ingelezen gebruikersprofielen en de buitentemperatuur (externe factor) een concrete energievraag van een aantal kantoren/huishoudens. Dit is de invoer van de interventie, die bepaalde aanpassingen (ingrepen) kan doen op deze energievraag. De verandering in het uiteindelijke energieverbruik en de beslissingen die uit de interventies zijn voortgekomen, vormen de resultaten. Deze resultaten geven inzicht in het effect op het energiegebruik en wat de gevolgen zijn voor de consument. De
resultaten worden visueel gepresenteerd. De nadruk ligt in de opdracht op de interventies en de effecten, niet op de validiteit van de simulatie.
De invoer van de simulatie (in het bijzonder de gebruikersprofielen) worden dynamisch ingelezen. Wanneer mogelijk zullen gegevens uit de praktijk worden gebruikt (deze zijn vanzelfsprekend realistischer). Als dit niet mogelijk blijkt, worden gebruikersprofielen (deels) gebaseerd op schattingen.
3.2. Projectgrenzen
3.2.1. Scope
Binnen het project wordt alleen op het gebruik van elektriciteit gelet. Voor andere energiebronnen, zoals gas, is de probleemstelling niet relevant.
De energievraag van de industrie wordt niet in het onderzoek meegenomen. De reden is dat hier geen eenduidig antwoord op kan komen, omdat de
energievraag sterk afhankelijk is van het soort industrie. De energiegebruikers waar het onderzoek wel rekening mee houdt zijn huishoudens en kantoren. Binnen het project wordt er geen hardware ontwikkeld, noch worden aanpassingen gedaan aan bestaande hardware. De demonstratie is puur softwarematig. Er wordt dan ook niet onderzocht hoe een systeem voor piekreductie in de praktijk kan worden geïmplementeerd, alleen wat een dergelijk systeem het beste kan doen en wat het effect zal zijn.
Het ontwikkelen van de software (de simulatie en de interventies die worden gevalideerd) loopt van het bepalen van de gebruikerseisen tot en met de integratietest.
3.2.2. Begin– en einddatum
Het project is begonnen op 3 maart 2008 en zal eindigen op 12 augustus 2008. Binnen deze periode wordt er full-time gewerkt (40 uur per week), behalve van 10 t/m 18 juli.
3.2.3. Randvoorwaarden
Er zijn een aantal voorwaarden waar aan moet worden voldaan, wil het project kunnen slagen. De volgende randvoorwaarden zijn opgesteld:
• Er moet voldoende informatie beschikbaar zijn over de energievraag van consumenten, zodat de simulatie hierop kan worden gebaseerd.
• Eventuele benodigde software (zoals grafische of simulatietoolkits) moet op tijd worden geleverd.
3.3. Projectactiviteiten
De projectopdracht die in §3.1 is uitgewerkt, is opgedeeld in een aantal projectactiviteiten. Deze activiteiten vormen de basis voor de planning van het project. In de oriëntatiefase is de opdracht verder uitgewerkt en is het plan van aanpak geschreven. Tijdens het project wordt een eindverslag geschreven, een gebruikershandleiding opgesteld en een poster gemaakt (ter demonstratie van het project).
Als gevolg van de gebruikte ontwikkelmethode (welk is beschreven in §4.1) wordt het onderzoek en de ontwikkeling opgesplitst op basis van
onderzoeksresultaten en functionaliteiten, zonder te letten op onderliggende technische eisen. Deze functionaliteiten zijn een oplossing voor een bepaalde behoefte van één van de gebruikers van het systeem (een actor). Deze behoeften zijn gedocumenteerd in user stories. De user stories zijn in het verslag opgenomen als bijlage I.
Sommige activiteiten komen niet in de planning voor. Het gaat hier om voortgangsrapportage aan de docentbegeleider (eens per twee weken) en overleg met de bedrijfsbegeleider, competence manager en mentor.
3.4. Producten
Uit het project komen een aantal producten voort. Hieronder vallen uiteraard de eindproducten, maar ook documentatie die tijdens de ontwikkeling is gebruikt (zoals het plan van aanpak).
3.4.1. Eindproducten
Het project zal twee eindproducten opleveren:
• Een onderzoekresultaat over verschillende mogelijke interventies om de elektriciteitsvraag van huishoudens te beïnvloeden en het verwachte resultaat van deze interventies.
• Een demonstratie die het effect van de (in het onderzoek gevonden) interventies kan valideren met behulp van een simulatie.
Het onderzoek zal worden opgenomen in het eindverslag. De demonstratie zal de vorm hebben van een uitvoerbaar computerprogramma.
3.4.2. Documentatie
Het plan van aanpak is het eerste product van het project.
Tijdens de ontwikkeling van de demonstratie worden delen van het functionele en technische ontwerp gedocumenteerd. Deze documentatie zal niet de vorm hebben van een gangbaar functioneel- en technisch ontwerp, door de keuze
voor een agile ontwikkelmethode (meer over de ontwikkelmethode volgt in §4.1). Van het functionele ontwerp zijn de gestelde eisen en de grafische user interface gedocumenteerd. De documentatie van het technisch ontwerp is verweven met het hoofdstuk uitvoering (hoofdstuk 5). Het gaat om uitleg met ondersteunende UML diagrammen. Voor het testen van de software is de acceptatietest gedocumenteerd. Al deze documentatie wordt aan het begin van iedere iteratie bijgewerkt.
Er wordt een gebruikershandleiding opgeleverd waarin wordt vermeld hoe de demonstratie wordt gestart. Ook wordt er een overzicht gegeven van de functionaliteiten en hoe deze te gebruiken zijn.
Er is verslag gelegd van de behaalde resultaten binnen het project. Ook zijn er aanbevelingen gedaan. Deze zijn samengevoegd in dit eindverslag. Eerder is een tussenverslag opgeleverd, wat kan worden gezien als een tussentijdse versie van dit verslag.
3.5. Planning
De planning is te vinden in bijlage II. In opvolgende iteraties zal de planning nog worden bijgewerkt. Het feit dat dit gedeelte nog niet volledig is gespecificeerd heeft alles te maken met de toegepaste ontwikkelmethode.
Voor iedere user story is een (relatieve) schatting gemaakt van de omvang van de user story (tijd die nodig is voor ontwikkeling). Deze schatting is vermeld in story points. De geschatte velocity1 is 2,5 story points per 8 uur. De tijd die benodigd is voor vaste activiteiten2 bedraagt naar schatting 90 minuten per dag. Een iteratie duurt bij voorkeur twee weken en dus wordt er per iteratie 65 uur ingepland. Als de schatting later niet juist blijkt te zijn, zal de velocity (en daarmee de planning) worden aangepast.
3.6. Kosten en baten
In dit hoofdstuk wordt een overzicht gegeven van wat het project kost en wat het oplevert. Aan de hand van deze informatie kan worden bepaald of het project levensvatbaar is.
3.6.1. Kosten
Binnen het project worden de volgende (algemene) kostenposten onderscheiden:
1
Snelheid waarmee story points worden behaald.
2
Hieronder vallen terugkom- en vrije dagen, rapportage, voortgangsoverleg, interne communicatie en het volgen van presentaties van andere afstudeerders (deze worden op maandagochtend gepland).
• De stagevergoeding die de opdrachtnemer maandelijks ontvangt
• Begeleiding van de opdrachtnemer
• De werkplek, inclusief werkstation
• Gebruikte software
3.6.2. Baten
De resultaten van het project geven inzicht in de mogelijkheden om de vraag naar energie te beïnvloeden. Door de visuele demonstratie kan het concept snel en op een aantrekkelijke manier aan derden duidelijk worden gemaakt. De demonstratie kan energieleveranciers interesseren voor het concept en kan bovendien een uitgangspunt zijn voor verdere werkzaamheden binnen het probleemgebied. De demonstratie kan waardevolle aanbevelingen opleveren, omdat deze het nut (of het ontbreken daarvan) van veelbelovende interventies kan aantonen. Een demonstratie kan tevens (grote) energieverbruikers
overtuigen om te participeren aan projecten binnen dit probleemgebied. Projectteams die werken aan een implementatie in een praktijksituatie kunnen de kennis gebruiken die dit project oplevert.
3.6.3. Conclusie
Het project levert inzicht op, die zeer waardevol kan zijn op het moment dat utility bedrijven interesse tonen in deze vorm van piekreductie. Er is een kans dat dit er nooit van komt, maar gezien de lage kosten van het project is de verwachting dat de baten tegen de kosten opwegen.
3.7. Risico’s
Het project kent een aantal risico’s, specifiek voor deze situatie. De volgende risico’s zijn geïdentificeerd:
• Er is onvoldoende informatie beschikbaar over de energievraag van consumenten, om de simulatie op te kunnen zetten.
• Benodigde software wordt niet op tijd geleverd.
• De opdrachtnemer is nog in opleiding, waardoor er mogelijk een gebrek is aan kennis en ervaring om het project tot een goed einde te brengen.
• De opdracht wordt uitgevoerd door één persoon, zonder de mogelijkheid om extra personeel in te zetten.
Het vinden van goede gebruikersprofielen, die informatie geven over het energieverbruik, is lastig. Er is daarom een redelijke kans dat de gevonden informatie ontoereikend is voor de simulatie. In dat geval zullen er aannamen worden gemaakt over het energieverbruik van verschillende
consumentengroepen, wat ten koste van de kwaliteit van de simulatie (en de uiteindelijke onderzoeksresultaten).
Tijdens het project wordt er mogelijk software gebruikt waarvoor nog geen licentie aanwezig is. Het kan gaan om een bepaald (commercieel)
softwarepakket, een plugin of een software component (denk aan grafische of simulatietoolkits). Er kan enige tijd overheen gaan voordat dergelijke uitgaven zijn gemaakt. Daarom is het belangrijk om zo snel mogelijk aan te geven welke software er nodig zal zijn.
Het feit dat de opdrachtnemer nog in opleiding is, vormt in alle fasen van het project een risico. Gebrek aan ervaring kan er bijvoorbeeld toe leiden dat het model van de software niet valide is, doordat er iets verkeerd wordt ingeschat of over het hoofd wordt gezien. Dit risico kan worden teruggedrongen door een goede begeleiding. Op het moment dat begeleiding nodig blijkt, zal dit zo snel mogelijk worden aangegeven door de opdrachtnemer.
Dat de opdracht door één persoon wordt uitgevoerd, levert problemen op in het geval dat de opdrachtnemer niet beschikbaar is (bijvoorbeeld door ziekte). Als de projectnemer niet full-time beschikbaar is, zal dit ten koste gaan van tijd of van de omvang van het opgeleverde product.
4. Methoden en technieken
Tijdens de uitvoering van het project zijn er diverse methoden en technieken gebruikt. Een aantal is reeds vastgelegd in het plan van aanpak. Voor andere technieken is de keuze gemaakt op het moment dat deze benodigd was (dit is in lijn met de ontwikkelmethode). In dit hoofdstuk wordt vermeld welke
methoden en technieken er zijn gebruikt en wat de motivatie hierachter is.
4.1. Methoden
De gebruikte ontwikkelmethode is eXtreme Programming (XP). Dit is een agile ontwikkelmethode, wat wil zeggen dat er rekening wordt gehouden met
veranderende eisen en prioriteiten. Deze methode is erg flexibel maar vraagt betrokkenheid van stakeholders en schenkt relatief weinig aandacht aan betrouwbaarheid of veiligheid van de software. Wel ligt de nadruk op het product en het toevoegen van waarde in de vorm van functionaliteit.
De reden dat er voor XP is gekozen is tweeledig. Ten eerste is er een vaste deadline. Voor die datum moet er zoveel mogelijk (waardevolle) functionaliteit aanwezig zijn. Binnen een agile ontwikkelmethode wordt er gepland op basis van functionaliteiten in plaats van onderliggende technische eisen. Deze functionaliteiten worden ontwikkeld op volgorde van prioriteit. De tweede reden dat er voor XP is gekozen, is dat het project een innovatief karakter heeft. Dit bracht onzekerheid met zich mee en kan tot gevolg hebben dat eisen
tussentijds veranderen.
Er zijn echter wel een aantal veranderingen aangebracht in de manier waarop de methode wordt toegepast. Het programmeren is, tegen de methode in, individueel gedaan. Dit is noodzakelijk omdat het project door slechts één persoon wordt uitgevoerd.
Het achterhalen van de requirements valt binnen een agile methode gelijk met het opstellen van de user stories. Meer informatie over de wijze waarop de requirements tot stand zijn gekomen is te vinden in §5.2 (binnen het hoofdstuk uitvoering).
Om de implementatie van een bepaalde functionaliteit te valideren, worden een aantal unit tests geschreven.
4.2. Technieken en tools
4.2.1. Technieken
De gebruikte programmeertaal is Java. Binnen Logica is veel kennis aanwezig over deze taal. Ook de projectnemer is met de programmeertaal bekend.
Binnen het ontwerp worden enkele design patterns toegepast. Ze vormen de een goed doordachte oplossing voor enkele veel voorkomende (programmeer-) problemen. Een voorbeeld binnen dit project is het ‘strategy pattern’ dat wordt toegepast voor het parsen van gebruikersprofielen.
Voor de grafische user interface is gebruik gemaakt van de Swing library (deze is in Java ingebouwd). Swing is een uitbreiding op AWT (het meest voor de hand liggende alternatief) en ondersteund complexere gebruikersinterfaces van een hogere kwaliteit [JIA03].
Voor het vastleggen van het ontwerp worden UML diagrammen gebruikt. Deze schematechniek is een internationale standaard en sluit goed aan bij zowel de voorkennis van de projectnemer als bij de gebruikte programmeertaal.
Voor persistente opslag van gebruikersprofielen wordt XML gebruikt. XML Schema wordt gebruikt om de XML bestanden te valideren en hun structuur te beschrijven. De reden hiervoor is dat deze bestanden eenvoudig zijn aan te passen en dat de technieken veel worden gebruikt (er is veel kennis en ervaring aanwezig).
4.2.2. Documentatie
Voor documentatie wordt Microsoft Office gebruikt. Microsoft Visio wordt gebruikt voor het creëren van de UML diagrammen.
4.2.3. Ontwikkelomgeving
De gebruikte IDE is NetBeans. Dit programma biedt alle gevraagde
functionaliteit en is daarnaast open source, waardoor er geen kosten aan zijn verbonden. De keuze is gemaakt naar aanleiding van positieve ervaringen van derden.
Voor de unit tests wordt JUnit gebruikt. Deze toolkit is geschreven in Java en speciaal ontwikkeld voor het maken van unit tests. JUnit is in diverse IDE’s geïntegreerd, waaronder NetBeans.
4.2.4. Simulatietoolkit
Voor het ontwikkelen van de simulatie is ervoor gekozen gebruik te maken van een simulatietoolkit. Dit is een framework dat is opgezet om snel een
betrouwbare simulatie op te kunnen zetten. Het voordeel is dat de ontwikkeling minder tijd in beslag zal nemen. Vooral het genereren van betrouwbare pseudo-willekeurige getallen is erg belangrijk in simulaties, omdat afwijkingen en afhankelijkheden gemakkelijk subtiele fouten kunnen veroorzaken in het eindresultaat [MINA96].
Er is gezocht naar toolkits die eenvoudig te gebruiken zijn vanuit Java. Een andere belangrijke eis is ondersteuning voor willekeurige getallen in een normale (gaussiaanse) distributie, omdat de meeste events in de
gebruikersprofielen op deze wijze zijn verdeeld. Twee toolkits die nader zijn bekeken zijn Swarm en RePast1. De eerste is oorspronkelijk ontwikkeld in Objective C, maar kent ook een Application Programming Interface (API) voor Java. RePast is volledig in Java ontwikkeld, wat als voordeel heeft dat het eenvoudiger te installeren valt en dat het ontwerp meer geschikt zal zijn voor Java. Daarnaast is RePast nieuwer en heeft een meer actieve gebruikersgroep. Om deze redenen is de keuze gemaakt voor de RePast toolkit.
1 Alternatieven zijn Mason en Ascape, maar deze toolkits zijn minder volwassen en
5. Uitvoering
In dit hoofdstuk worden de stappen beschreven, die zijn genomen om tot het behaalde resultaat te komen. Hierbij wordt een chronologische volgorde gehanteerd. Uitgangspunt is het plan van aanpak. Er wordt beschreven hoe er vorm is gegeven aan dit plan en op welke punten de uitvoering af week. Daar waar de ontwikkeling van de software wordt behandeld, worden ook technische details gegeven.
5.1. Oriëntatie
In de eerste fase van de afstudeeropdracht is er gewerkt aan het helder krijgen van de opdracht. Tegelijk is er een beeld gevormd van het probleemgebied. Door problemen bij het bepalen van de opdracht duurde deze fase langer dan verwacht.
5.1.1. Opdrachtomschrijving
In eerste instantie was de opdracht een pilot te ontwikkelen die enkele nieuwe mogelijkheden laat zien, die slimme energiemeters bieden ten opzichte van hun analoge voorgangers. Deze demonstratie omvatte de aansturing van de
energiemeter. Na een oriëntatie op overige projecten binnen Logica, bleek dat grote delen van de opdracht al waren uitgevoerd. Dit resulteerde in een nieuw project.
De nieuwe opdracht kwam voort uit een aanname in de oorspronkelijke
opdracht. Er werd verondersteld dat pieken in de vraag te reduceren zijn. Voor het ontwikkelen van de demonstratie werden immers direct één of meerdere mogelijkheden geïmplementeerd, die zouden kunnen bijdragen aan
piekreductie in de elektriciteitsvraag. De tweede opdracht is een stap die in feite voor de originele opdracht had moeten komen, namelijk een onderzoek naar de validiteit van deze aanname. De nieuwe opdracht is uitgewerkt in de vijfde week van de afstudeerstage. Dit is gedaan in overleg met de begeleiders en Ronald Oreel (competence manager). Deze opdracht is beschreven in §3.1.
Omdat beide opdrachten zich binnen hetzelfde probleemgebied bevinden, was het niet nodig om volledig opnieuw te beginnen met de oriëntatie. Toch heeft deze situatie wel enige tijd in beslag genomen. Omdat er minder tijd over was voor de nieuwe opdracht, werden er meer eisen aan de planning gesteld. Belangrijk is dat er iets tastbaars wordt opgeleverd, ook als de ontwikkeling tegen valt. Dit heeft bijgedragen aan de keuze voor een agile
ontwikkelmethode. Aan het eind van iedere iteratie staat er een werkend product, steeds met iets meer features dan de vorige versie. Ook als de ontwikkeling meer tijd in beslag neemt dan gepland, kan er dus een versie worden opgeleverd.
5.1.2. Oriëntatie op het probleemgebied
Tegelijk met het opstellen van de opdrachtomschrijving is er een oriëntatie gedaan op de energiemarkt. Met Google is er op internet gezocht naar artikelen over het probleemgebied. Er is gezocht op de vaktermen ‘demand response’, ‘peak reduction’ en ‘peak shaving’, in combinatie met de zoekterm ‘energy’ of ‘utilities’. De informatie die het meeste heeft bijgedragen aan de beeldvorming op de energiemarkt komt van artikelen op branche specifieke internetsites1. Over de volgende punten is informatie opgezocht:
• Slimme energiemeters en mogelijke koppeling met domotica
• Piekreductie in elektriciteitsvraag
• Projecten buiten Logica
• Nederlandse energiemarkt
Bij het eerste punt is onderzocht wat gangbare technieken zijn en welke mogelijkheden er worden geboden. De informatie die is gevonden over
piekreductie gaat voornamelijk over het aanpassen van het aanbod met behulp van peaker plants. Er is een artikel gevonden over het Amerikaanse GoodWatts project, dat zich bezig heeft gehouden met het aanpassen van de vraag naar energie (via domotica). Bij de situatie in Nederland is er gekeken naar de verschillende partijen in het geliberaliseerde marktmodel (waaronder
energieleveranciers, programmaverantwoordelijken, regionale distributeurs en de beheerder van het hoogspanningsnet). Ook is er informatie opgezocht over de invoering van slimme energiemeters en de veranderingen die dit heeft op het marktmodel. De gevonden informatie gaf inzicht in de energiemarkt, probleemstelling en mogelijke oplossingsrichtingen. Deze informatie was benodigd voor de probleemanalyse, die is uitgewerkt in hoofdstuk 2.
Het eerste plan van aanpak dat van de nieuwe opdracht uit gaat is versie 0.2 (0.1 ging over de eerste opdracht). Deze versie is ter goedkeuring opgeleverd aan beide begeleiders. Vervolgens is er een definitief plan van aanpak
opgesteld, dat enkele kleine wijzigingen bevat.
5.2. Opstellen van user stories
Nadat de opdracht was opgesteld, is er gewerkt aan het helder krijgen van de requirements. Binnen de toegepaste ontwikkelmethode staat dit gelijk aan het opstellen van user stories. Een user story beschrijft een verzoek voor een functionaliteit. Dit verzoek komt van één of meerdere stakeholders. Bij het opstellen van de requirements is rekening gehouden met de voornaamste belanghebbenden:
• Energieleveranciers
• Energieverbruikers
• Projectteams die werken aan implementatie in de praktijk
1
De laatste partij is op dit moment niet aanwezig, maar de kans is reëel dat een dergelijk team er komt. De wensen van deze stakeholders zijn bepaald aan de hand van desk research en overleg met Ronald Oreel (hij heeft de rol van opdrachtgever). In een later stadium kan er nog rekening worden gehouden met nieuwe of aangepaste wensen. Er zijn geen interviews gehouden met energieleveranciers of –gebruikers.
Het opstellen van een user story begint bij een stakeholder, die een wens heeft voor een bepaalde functionaliteit. Deze stakeholder wordt de actor genoemd. Iedere user story krijgt vervolgens een beschrijving en een herkenbare naam. Bij voorkeur zijn de beschreven user stories niet van elkaar afhankelijk, omdat afhankelijkheden de planning minder flexibel maken. Hieronder is een
voorbeeld gegeven van een user story.
Naam Het combineren van meerdere typen huishoudens (gebruikersprofielen) in één simulatie
Actor Energieleveranciers en in mindere mate energieverbruikers en eventuele projectteams die werken aan implementatie in de praktijk
Beschrijving In plaats van één gebruikersprofiel, dat uitgangspunt is van de simulatie, wil ik dat de simulatie kan worden opgebouwd uit meerdere gebruikersprofielen. Zo kan het effect worden bekeken in wijken met meerdere typen huishoudens of over meerdere wijken.
Story points 5
Prioriteit Should have Tabel 1: Voorbeeld van een user story
Nadat alle wensen van stakeholders zijn beschreven, krijgt iedere user story een prioriteit en een aantal story points toegewezen. Deze story points geven aan hoeveel tijd er nodig is om de story te ontwikkelen. Deze getallen zijn relatief. Om ze om te rekenen naar uren, is er geschat hoeveel story points er per dag (van 8 uur) worden behaald. Deze waarde wordt aangeduid met de Engelse term ‘velocity’.
Voor het opstellen van de user stories is overleg gevoerd met Martin van Amersfoorth1 en mede afstudeerder Emil Verwoerd. Dit gesprek heeft
informatie opgeleverd waarna een eerste versie van de user stories is gemaakt. De schatting in story points is gemaakt in samenwerking met Emil Verwoerd. Per user story is nagegaan welke werkzaamheden het met zich mee zal
brengen (welke delen van het systeem worden er veranderd, valt het eenvoudig te testen, etc.). Dit wordt vergeleken met andere user stories en zo wordt de hoeveelheid story points bepaald.
Martin van Amersfoorth heeft de user stories grondig nagekeken, zowel inhoudelijk als op het volgen van de agile ontwikkelmethode. Aan de hand van zijn feedback zijn er enkele wijzigingen doorgevoerd, voornamelijk om meer nadruk te leggen op het belang dat de stakeholders bij de betreffende story
1 Dit overleg is gevoerd met de architect omwille zijn ervaring met agile
hebben. De user stories zijn te vinden in bijlage I. Hierin zijn enkele wijzigingen doorgevoerd, die in latere iteraties naar voren zijn gekomen.
Tijdens het opstellen van de user stories is er een duidelijk beeld ontstaan van de te bouwen applicatie. Uit deze user stories en de bijhorende story points volgt een gedetailleerde schatting van de hoeveelheid werk binnen het project. Uit ervaring van de opdrachtnemer doet de agile aanpak in dit opzicht niet onder voor meer traditionele methoden van software engineering.
5.3. User interface
In de zevende week is er begonnen met de eerste iteratie. Er is gekozen om niet te beginnen met het opstellen van de gebruikersprofielen, ondanks dat dit de hoogste prioriteit had. De reden hiervoor is dat dit weinig variatie in
werkzaamheden geeft, omdat het direct na de oriëntatie op het probleemgebied valt (in beide gevallen gaat het om desk research). In plaats van de
gebruikersprofielen is er een begin gemaakt aan de grafische user interface, zodat er later vanuit een tastbaar product verder kan worden gewerkt. De user stories die binnen deze iteratie vallen zijn ‘weergave van het eindresultaat’ en ‘weergeven van ingrepen die de interventies tot gevolg hadden’.
Ten eerste is de acceptatietest geschreven voor dit gedeelte van de software. Deze is te vinden in bijlage VI (dit is de volledige versie en bevat daarom ook de acceptatietest van opvolgende iteraties). Na het opstellen van de
acceptatietest, is er gewerkt aan het functioneel ontwerp (met name hoe de user interface er uit moet komen te zien). Voor het ontwikkelen van de user interface is gebruik gemaakt van de editor die is ingebouwd in NetBeans. De reden hiervoor is dat de ontwikkeling zo minder tijd in beslag neemt. Via deze editor kunnen ook eenvoudig aanpassingen worden gemaakt, die nodig zijn geweest in opvolgende iteraties.
Er is gekozen om een Model View Controller (MVC) architectuur toe te passen. Voor de hand liggende alternatieven zijn het multitier model en Service
Oriented Architecture (SOA). MVC is flexibeler dan het multitier model en is daarom handiger in combinatie met een agile ontwikkelmethode. SOA zorgt waarschijnlijk voor de meest herbruikbare applicatie, maar een nadeel is wel dat het veel werk is om deze architectuur op te zetten. Dit project is om die reden waarschijnlijk te klein voor SOA. De MVC architectuur daarentegen is eenvoudig op te zetten. Het is schaalbaar en leent zich goed voor applicaties waarbij er veel interactie is met de gebruiker.
De gedachte achter MVC is dat de ‘flow of control’ in handen is van de controller. Het model wordt gebruikt om data op te slaan (zowel tijdelijke als persistente data) en de view dient voor de presentatie van de data. De controller creëert (of selecteert) het benodigde model en view. De view kan vervolgens direct data uit het model opvragen.
In de applicatie bestaat er één control klasse (Demonstration). Vanuit de view wordt deze klasse niet direct gebruikt, maar via een interface. Voor ieder
venster is een interface gemaakt naar de Demonstration klasse, zodat gelijk duidelijk is waar welke methoden worden gebruikt. Deze klassen zijn uitgebeeld in onderstaand diagram.
Figuur 3: Koppeling tussen de view en control klassen
In de tweede iteratie zijn aan dit gedeelte nog een SettingDialog klasse en
een bijhorende SettingsDialogController interface toegevoegd. Een overzicht van alle control klassen is te vinden in bijlage V (deze bijlage geeft de situatie nadat alle iteraties zijn doorlopen).
Tijdens de eerste iteratie is er een user story toegevoegd, namelijk ‘inzicht in (theoretisch) mogelijke aanpassingen in de energievraag’. Dit onderzoek viel eerst binnen de user story ‘mogelijke interventies’. De verdeling klopt beter met de verdeling in deelvragen. Ook is het totale aantal story points voor het
onderzoek omhoog bijgesteld. Deze inzichten zijn verkregen met de feedback op het plan van aanpak, maar zijn niet direct doorgevoerd in de user stories.
5.4. Gebruikersprofielen
De tweede iteratie begon in week 9 en duurde 14 werkdagen. In deze tijd zijn twee user stories afgerond, te weten ‘gebruikersprofielen van diverse
consumentengroepen’ en ‘laden van verschillende gebruikersprofielen’. De gebruikersprofielen beschrijven de elektriciteitsvraag van consumenten en worden gebruikt als invoer voor de simulatie.
5.4.1. Opstellen van gebruikersprofielen
Op internet zijn diverse bronnen opgezocht die iets vertellen over het energieverbruik van consumenten. Deze bronnen zijn ingedeeld in één of meerdere van de onderstaande categorieën (deze indeling is gebaseerd op de gewenste informatie):
• Macro-niveau
o Gesommeerd verbruik o Gebruikersgroepen
• Opbouw van de vraag
o Gebruik van apparaten
o Verbruik van specifieke apparaten
Er is gebleken dat er onvoldoende informatie beschikbaar is om een volledig gebruikersprofiel op te kunnen stellen. Dit is als risico beschreven in het plan van aanpak (zie §3.7).
Er is ten eerste gezocht naar cijfers over de situatie in Nederland. Hiervoor is gezocht op de websites van het Centraal Bureau voor de Statistiek (CBS) en het Energieonderzoek Centrum Nederland (ECN). Hierna is er meer informatie gezocht over het gebruik en verbruik van specifieke apparaten. Deze informatie gaat deels over Nederland, deels over de situatie in andere landen
(voornamelijk de Verenigde Staten). In de informatie die is gevonden, worden gebruikers vaak opgedeeld naar huishoudgrootte. In deze indeling zijn, binnen Nederland, de één-, twee- en vierpersoonshuishoudens de grootste groepen [CBS1]. Voor deze drie groepen is een gebruikersprofiel opgesteld. Over de elektriciteitsvraag van kantoren is geen informatie gevonden. Vanwege de omvang van deze groep is er toch besloten om een gebruikersprofiel op te stellen (op basis van schattingen), dat uitgaat van een kantoor voor 50FTE. Bij het invullen van de gebruikersprofielen is zoveel mogelijk gebruik gemaakt van informatie die in de bronnen is terug te vinden. Het grootste gedeelte van de getallen is echter gebaseerd op schattingen, wat gevolgen heeft voor het resultaat van de simulatie.
Een gebruikersprofiel bevat gegevens over een aantal apparaten (die zorgen immers voor de energievraag). De apparaten zijn opgedeeld in twee
categorieën: handmatige en geregelde apparaten. Handmatige apparaten worden iedere keer door de consument zelf aangezet. In sommige gevallen wordt een timer functie gebruikt (dit is vrij gangbaar bij bijvoorbeeld
wasmachines). De meeste apparaten vallen in deze categorie. Geregelde apparaten hebben iets te maken met temperatuur. Het gaat om onder andere de centrale verwarming, airconditioning en de koelkast. Deze apparaten worden aan- en uitgezet door een regelaar.
De temperatuur van geregelde apparaten wordt steeds tussen twee
grenswaarden gehouden en er wordt rekening gehouden met een dode tijd. Dit wil zeggen dat het in- of uitschakelen van het apparaat pas na enige vertraging merkbaar is in de temperatuur. Om de snelheid te bepalen waarmee de
temperatuur veranderd, is er een factor voor vermogen en isolatie. Deze waarden vertellen op het oog weinig en zijn daarom lastig te schatten. De isolatiefactor is steeds herleid uit een schatting van het maximale
temperatuursverschil dat het apparaat kan bereiken. Tabel 2 geeft, als voorbeeld, het volledige profiel van een
éénpersoonshuishouden. Het profiel bevat gegevens per apparaat. Welke gegevens dat zijn is afhankelijk van het type. De tijdsduur, gebruik per dag en de ingestelde tijd (bij de timerfunctie) zijn gegeven als stochastische
variabelen1. Als parameter is het gemiddelde en de standaarddeviatie gegeven. De laatste wordt steeds aangegeven met de Griekse letter sigma (σ).
Apparaat: Koelkast Type: Geregeld Verbruik (piek in W): 45 Ingestelde temperatuur (°C): 2,6 – 3,4 Omgevingstemperatuur (°C): 20 Vermogen (factor): 0,1156 Isolatie (factor): 0,99616
Dode tijd (sec): 60
Apparaat: Wasmachine
Type: Manueel (met timerfunctie)
Verbruik (W): 500 [KING]
Gebruik per dag (aantal keer): 0,3 (0,06 σ) [JEEN01]
Tijdsduur per keer (sec): 5400 (600 σ)
Gebruik van timerfunctie (factor): 0,4
Tijd voor timerfunctie (sec): 10800 (3600 σ)
Apparaat: Oven
Type: Manueel
Verbruik (W): 440
Gebruik per dag (aantal keer): 0,6 (0,2 σ)
Tijdsduur per keer (sec): 720 (300 σ)
Apparaat: Magnetron
Type: Manueel (met timerfunctie)
Verbruik (W): 800
Gebruik per dag (aantal keer): 0,7 (0,3 σ)
Tijdsduur per keer (sec): 60 (50 σ)
Apparaat: Koffieautomaat
Type: Manueel (met timerfunctie)
Verbruik (W): 1000
Gebruik per dag (aantal keer): 1 (0,5 σ)
Tijdsduur per keer (sec): 180 (30 σ)
Apparaat: Televisie
Type: Manueel (met timerfunctie)
Verbruik (W): 80 [KING]
Gebruik per dag (aantal keer): 2 (1 σ)
Tijdsduur per keer (sec): 3540 (1000 σ)
Tabel 2: Gebruikersprofiel van een éénpersoonshuishouden
1
Er wordt uitgegaan van een normale verdeling. In de meeste gevallen zal de waarde rond het gemiddelde liggen. De breedte van de verdeling wordt aangegeven door de standaarddeviatie.
5.4.2. Inlezen van profielen
Zoals besproken in het hoofdstuk ‘Methoden en technieken’ (zie §4.2.1) zijn XML en XML Schema gebruikt voor de persistente opslag van
gebruikersprofielen. Voor het wegschrijven en inlezen van deze bestanden wordt gebruik gemaakt van de XML parser uit de standaard Java library. Er zijn enkele dagen besteedt aan het inwerken op deze library. Voordat het
uiteindelijke project is aangepast, is er een kleine applicatie gemaakt die het inlezen en valideren van XML kan demonstreren (een soort ‘proof of concept’). Het inwerken kostte meer tijd dan verwacht, doordat de interface van de library vrij complex is.
Tijdens de ontwikkeling bleek dat de XML validator, die in de Java library is opgenomen, zijn werk niet volledig doet. Sommige eisen die zijn gespecificeerd in het XML Schema bestand, worden niet door deze validator gecontroleerd. Om dit te verhelpen worden deze gevallen in de code opgevangen, tijdens het parsen van het XML bestand.
De gebruikte parser is een SAX parser (dit staat voor ‘Simple API for XML’). Het gaat hier om een streaming parser, wat betekent dat deze het XML document niet volledig in het geheugen zal houden. Tijdens het parsen worden events gegenereerd voor gevonden informatie. Om deze events af te handelen is het ‘strategy pattern’ toegepast [GAMM94]. Op deze manier kon de afhandeling op een logische manier worden gesplitst, zodat de complexiteit hiervan afneemt. Figuur 4 geeft de klassen weer die hiervoor zijn geïmplementeerd.
Figuur 4: Klassen voor het afhandelen van SAX events
De XMLHandler klasse is hier de abstracte superklasse voor de strategie. Deze
bevat een stack van elementen (instanties van Element), om bij te houden waar de parser is gebleven binnen de XML structuur. Figuur 5 geeft het bijhorende statusdiagram.
Profile Controlled Manual start controlled device end controlled device start manual device end manual device
Figuur 5: Statusdiagram voor het afhandelen van SAX events
De parser converteert het document van XML naar een binair formaat. Dit eindresultaat wordt in het geheugen gehouden. Met het binaire formaat wordt een instantie van de ConsumerProfile klasse bedoeld. Deze bevat instanties
van Device (wat zelf een abstracte klasse is). Voor ieder soort apparaat bestaat er een subklasse van Device, zoals te zien is in onderstaand figuur. Deze klassen staan allen in het model package.
Figuur 6: ConsumerProfile en onderliggende klassen
5.5. Simulatie
Nu de gebruikersprofielen worden ingelezen, is alle invoer aanwezig voor de simulatie. Dit is dan ook het thema van de derde iteratie. De user story die hierbij hoort is ‘simulatie van consumenten op basis van een gebruikersprofiel’. Voor het ontwikkelen van de simulatie is gebruik gemaakt van de RePast toolkit (de keuze hiervoor is toegelicht in §4.2.4). Om bekend te raken met deze software zijn eerst artikelen gelezen waarin de algemene opzet en terminologie
van de simulatietoolkits wordt uitgelegd. Ook zijn er enkele voorbeelden bestudeerd, die met de toolkit zijn meegeleverd. Nadat er een duidelijk beeld was ontstaan van de opzet van dergelijke applicaties, is er begonnen met de ontwikkeling van de simulatie. Het gebruiken van RePast gaf geen
noemenswaardige problemen en nam daarom minder tijd in beslag dan verwacht.
Doordat de toolkit een architectuur van de software afdwingt, valt het gedeelte van de simulatie buiten de MVC architectuur. De klassen die binnen deze user story zijn ontwikkeld zijn ondergebracht in een eigen package, onder de naam
simulation. Vanuit de controller spreekt van dit package alleen de
Simulation klasse aan. Klassen in het simulation package kunnen wel data opvragen uit het model. Onderstaand figuur geeft de relatie weer tussen alle packages.
Figuur 7: Package diagram
De simulatie is gebaseerd op een objectgeoriënteerd model, dat zoveel mogelijk overeenkomt met de werkelijkheid. Het model is opgebouwd uit een hiërarchie van entiteiten, die agents worden genoemd. Doordat het model bestaat uit meerdere (onafhankelijke) agents, gaat het om een multi-agent simulatie. Op het hoogste niveau in de hiërarchie staan de huishoudens en kantoren. Hieronder vallen individuele apparaten. Onderstaand figuur geeft de objecten weer in een UML-diagram. Hoe dit zich heeft vertaald naar concrete klassen is te vinden in bijlage V (zie het klassendiagram van het simulation
package).
Figuur 8: Objecten binnen de simulatie
De simulatie ondersteunt alleen regelaars die het apparaat volledig aan, of volledig uit zetten. Meer geavanceerde apparatuur, zoals PID-regelaars, worden niet ondersteund (omwille de tijd die voor het project beschikbaar is).
Bij geregelde apparaten moet de temperatuur steeds worden bijgehouden. De ontwikkeling van de temperatuur is afhankelijk van een aantal instelbare variabelen. Aan het begin van de simulatie moeten apparaten in een willekeurige fase beginnen1. Dit is lastig en vereist een gedetailleerde
uitwerking van wiskundige formules. Hier is een aantal dagen zelfstandig aan gewerkt. In deze tijd is geen hulp gezocht omdat de situatie ten eerste lastig uit te leggen is en ten tweede omdat er wel vertrouwen was dat er een oplossing zou komen voor de wiskundige problemen. Wel had dit gedeelte meer tijd nodig dan van tevoren was geschat. Deze extra tijd weegt op tegen de tijd die is gewonnen tijdens het inwerken op RePast.
In bijlage III zijn de belangrijkste formules te vinden die worden gebruikt bij het simuleren van geregelde apparaten.
5.6. Interventies en combineren van gebruikersprofielen
De vierde iteratie begon in de 15e week van de afstudeerstage. Tijdens het plannen van de iteratie zijn er een aantal aanpassingen gemaakt in de user stories. De stories die vervolgens binnen de iteratie zijn ingepland zijn ‘inzicht in (theoretisch) mogelijke aanpassingen in de energievraag’, ‘mogelijkeinterventies’ en ‘combineren van meerdere typen huishoudens (gebruikersprofielen) in één simulatie’.
5.6.1. Aanpassingen in user stories
De user story ‘rekening houden met de buitentemperatuur’ is weggehaald, omdat deze functionaliteit al is meegenomen in de drie voorgaande user stories (op deze manier leverde de story nauwelijks extra werk op). De ‘real-time’ visualisatie van de stroomvraag heeft een lagere prioriteit gekregen, doordat het voor de meeste betrokken partijen niet zo belangrijk is (alleen de
energieverbruikers hebben hier veel baat bij). Het combineren van meerdere typen huishoudens (gebruikersprofielen) in één simulatie heeft een hogere prioriteit gekregen. Door deze story zijn de resultaten van de demonstratie realistischer en dus betrouwbaarder. De wens om meerdere gebruikersgroepen tegelijk te simuleren kwam ook naar voren tijdens een gesprek met Rob
Martens (competence manager).
In de loop van de iteratie is er nog een user story toegevoegd, namelijk
‘weergeven van gemiddelde en standaarddeviatie van de vraag’. De vraag naar deze functionaliteit is ingebracht door Eric Zuur (de mentor), na het zien van het resultaat tot dan toe.
5.6.2. Uitvoering van het onderzoek
Deze eerste twee user stories binnen de iteratie geven antwoord op
respectievelijk de tweede en derde deelvraag (mogelijke aanpassingen op de
1 Als alle geregelde apparaten in dezelfde status c.q. fase zouden beginnen, resulteert
energievraag en het opstellen van interventies om deze aanpassingen te bereiken). Op het moment dat de iteratie begon was het onduidelijk waar de splitsing tussen deze deelvragen precies lag. Vooral onduidelijk was vanaf wanneer piekreductie het beste in het verhaal terug kon komen. Om het probleem op te lossen is er overleg gevoerd met Martin van Amersfoorth. Het probleem deed zich voor door een gebrek aan ervaring met dergelijke
onderzoeken. Hierdoor ontbrak er vooraf een duidelijk beeld van de structuur en aanpak van het onderzoek. Door deze ervaring is hier nu een iets beter beeld van.
Uit het overleg is gebleken dat het gedeelte over de mogelijke aanpassingen kort zou zijn. De user story voor het opstellen van de interventies bleek veel meer werk dan het onderzoek naar mogelijke aanpassingen. Dit blijkt niet uit de schatting in story points (hier liggen de waarden dichter bij elkaar).
De user story ‘inzicht in (theoretisch) mogelijke aanpassingen in de energievraag’ geeft een overzicht van effectieve aanpassingen. Hierbij is rekening gehouden met de ethiek. Aanpassingen die door de consument als storend worden gezien, zijn immers niet nuttig voor een implementatie van piekreductie in de elektriciteitsvraag. Voor het bepalen van de aanpassingen is een top-down benadering toegepast. Ten eerste zijn alle denkbare
aanpassingen globaal verdeeld (in aanpassingen in de totale vraag en
verplaatsingen in de vraag). Vervolgens is er bedacht hoe deze aanpassingen bereikt kunnen worden. Om een selectie te maken is er rekening gehouden met het energieverbruik van bepaalde apparaten (of groepen van apparaten). De grootte van hun elektriciteitsvraag is bepalend voor de effectiviteit van de aanpassing.
De mogelijke aanpassingen zijn de input voor de volgende user story binnen de iteratie (het opstellen van mogelijke interventies). Er is uitgewerkt wanneer aanpassingen nodig zijn en hoe deze worden bereikt (welke interventies). Niet alle mogelijke aanpassingen leveren een positieve bijdrage aan piekreductie. Er wordt dus een selectie gemaakt, met het oog op het verminderen van onbalans. Deze onbalans ontstaat doordat pieken in de elektriciteitsvraag niet of niet exact zijn voorspeld.
Het moet mogelijk zijn te achterhalen wanneer apparaten zijn ingepland. In dat geval zijn een aantal pieken van te voren bekend (er staan dan veel apparaten tegelijk ingepland). Deze piek is mogelijk niet de dag van tevoren voorspeld. Grote pieken (die tenminste enkele uren duren) kennen waarschijnlijk een duidelijke oorzaak en zijn daarom relatief goed te voorspellen. Er wordt daarom van uitgegaan dat dergelijke (langdurige) pieken zijn opgenomen in de
voorspelling, die is opgesteld door de PV partij. Het is wel mogelijk dat het tijdstip, vorm of hoogte van de piek afwijkt van de werkelijkheid.
tijd w a tt voorspelling verbruik Figuur 9: Onbalans
In het voorbeeld van bovenstaand figuur komt de piek eerder dan verwacht. Als het gaat over een piek die enkele uren duurt, kan de afwijking al worden
geconstateerd voordat de piek is bereikt (de constatering is dat de piek groter is dan verwacht, of eerder komt). Er kunnen ingrepen worden gedaan om het energieverbruik te verminderen of uit te stellen.
Ingrepen volgen dus altijd na een geconstateerd onbalans of op basis van (meestal kortdurende) pieken waarvan vooraf bekend is dat ze komen, op basis van ingeplande acties (het aanzetten van een apparaat via de timer functie). Naast de vraag wanneer interventies nodig zijn, is het ook van belang te weten welke ingreep er moet worden gedaan. Er zijn diverse ingrepen denkbaar die een effect zullen hebben op het energieverbruik. Veel van deze ingrepen hebben tegelijk veel invloed op het doen en laten van de consument, zoals het direct uitzetten van apparaten met een groot verbruik. Dit kan bij consumenten veel irritatie veroorzaken en kan daarom als onethisch worden beschouwd. Een beter alternatief is het stimuleren van het gewenste gedrag, door advies en beloning. De ingreep die hieruit volgt is het aanpassen van de elektriciteitsprijs. Het geven van besparingstip valt niet onder de mogelijke ingrepen omdat dit het doel van piekreductie niet zal dienen. Een besparingstip zorgt voor het verlagen van het totale verbruik en is voor langere tijd geldig (langer dan de piek). Er wordt aangenomen dat de voorspelling van de PV partij rekening houdt met pieken die regelmatig (bijvoorbeeld iedere dag) voorkomen. Als de piek een dag van tevoren is voorspeld, zorgt dit niet voor onbalans.
Er zijn ook geautomatiseerde ingrepen mogelijk, waar de consument niet of nauwelijks iets van merkt. De volgende mogelijkheden worden behandeld:
• Tijdelijk aanpassen van setpoint (van airco, koelkast of vriezer)
• Het verplaatsen van het moment van inschakelen, voor apparaten die op tijd zijn ingesteld
In het laatste geval moet de verplaatsing niet te groot zijn. Als een consument bijvoorbeeld zijn wasmachine om 3 uur ’s nachts wil laten draaien, dan zal het waarschijnlijk niet uitmaken als dit een kwartier eerder of later is. Het kan wel onwenselijk zijn als de wasmachine de volgende ochtend nog niet is begonnen.
