REloadIT functioneel & technisch ontwerp
REload T Ontwikkeld door de gemeente Zaanstad
Datum: 8-12-2011 Status: definitief voor offerteaanvraag
Inhoud Inhoud
2
Figuren
2
Functionele specificatie Smart Grid systeem
3
Inleiding
3
Basisfuncties Smart Grid systeem Regelstrategie business agent ICT infrastructuur Data-acquisitie - en besturing Data opslag systeem Visualisatie Data verwerking en rapportages
4 4 4 4 4 4 5
Systeem specificaties
6
Uitgangspunten systeemontwerp
6
Systeemcomponenten
7
Software architectuur SG-systeem.
8
Scope of work en deliverables
9
Opleveringen Materialen Documentatie Activiteiten Onderhoud en garantie Eigendomsrechten
9 9 9 9 9 9
Quality Assurance
10
Planning
11
Referenties
11
Bijlage: Uitwerking functionele specificaties
12
Figuren Figuur 1: Proces flow schema van het SG systeem ............................................................................................. 3 Figuur 2: Concept systeemarchitectuur REloadIT ............................................................................................... 7 Figuur 3: Concept software architectuur c.q. proces data flow ReloadIT ........................................................... 8
2
Functionele specificatie Smart Grid systeem Inleiding Een Smart Grid systeem (SG) bestaat uit een cluster van meerdere onafhankelijke energiebronnen en energie-gebruikers, die onderling energie en informatie uitwisselen via respectievelijk het elektriciteit- en een ICT-netwerk. Het doel van een SG is om op basis van een specifieke business case, elektriciteitsgebruik en (duurzame) productie binnen een cluster optimaal te benutten. Voorbeelden van business cases zijn: peak shaving, dwz het vermogensprofiel van het distributienet te verbeteren door het verschuiven van de vermogensprofielen van de diverse gebruikers en producenten. Daarmee wordt het piekverbruik verlaagd en het distributienet ontlast. Tevens kunnen hiermee piektoeslagen in het contract vermeden worden. Een andere business case is om financieel voordeel te behalen door het aanbieden van flexibiliteit (dalen en pieken in vermogensverbruik) aan de netbeheerder. In het kader van dit project is het hoofddoel om optimaal gebruik te maken van de beschikbare duurzame energie ten behoeve van het elektrisch vervoer. Figuur 1 toont een schematische weergave van het beoogde SG-systeem in de vorm van een proces flow schema.
Device Agent Wind turbine Device Agent PV systeem (3)
Priority manager Divice-Agent Laadstation (of per laadpaal?)
Busines Agent
Meteo service
Figuur 1: Proces flow schema van het SG systeem
Het SG-systeem heeft een hierarchische structuur, het is samengesteld uit een Priority Manager een Business Agent, en 1 of meerdere Agent-devices. In een meer uitgebreid SG-systeem kunnen er meerdere Priority Managers opgenomen worden. In de context van dit project kan wegens de kleine omvang van het cluster worden volstaan met 1 Priority Manager. De Agent-devices melden zich aan bij de Priority Manager. Van ieder device (de energiebron of een energiegebruiker: laadstation en zonne-installaties) berekent de Device Agent de prioriteit, dit geeft de wil van het device weer om energie te verbruiken of te produceren. De Agent-devices geven deze informatie door aan de Priority Manager. De business agent interpreteert de busines rules in combinatie met de weersvoorspelling, en stuurt dit door naar de Priority Manager. Deze berekent op zijn beurt de vermogensallocaties per device, gebaseerd op de informatie ontvangen van de device agents en de business agent. De allocaties worden daarna terug gegeven aan de Agent-devices. Het gehele systeem draait cyclisch: Per tijdsslot van bv 15 minuten wordt de business case doorgerekend en informatie uitgewisseld. In deze case dient optimaal gebruikgemaakt te worden van de energieopbrengst van de 3 zonne-installaties en toekomstige wind turbine ten behoeve van het elektrisch vervoer. De business rules (of regelstrategie) worden in het volgende hoofdstuk beschreven.
3
Basisfuncties Smart Grid systeem Regelstrategie business agent Het managen van de load van het SG vindt plaats op basis van de regels die door de Business Agent worden doorgerekend: 1. Maximaal gebruikmaken van de beschikbare zonne-energie (en later ook de windenergie). M.a.w. voertuigen overdag laden met duurzame energie tot de maximale state of charge. Het overschot van elektriciteit wordt teruggeleverd aan de gemeente Zaanstad via het distributienet. 2. Optimaal gebruikmaken van tariefvoordeel tussen het dag- en nachttarief indien er onvoldoende duurzame energie beschikbaar voorspeld is voor de dag. 3. De state of charge van de 16 voertuigen dient per auto gegarandeerd te worden adhv de gebruikersparameters zoals: de agenda met rijtijden, gewenste minimum rijbereik, en het tijdstip waarop het rijbereik beschikbaar moet zijn. Alternatief: het laadstation als 1 grote accu beschouwen. INFO Imtech? 4. Indien mogelijk: Terugleveren aan het net door de accu’s als er een overschot is op basis van het geplande gebruik.
ICT infrastructuur Ten behoeve van de communicatie en koppeling van de randapparatuur aan het SG-systeem dient een ICTnetwerk beschikbaar te zijn. In hoofdstuk Systeem specificaties worden de specificaties van deze ICT infrastructuur verder uitgewerkt.
Data-acquisitie - en besturing Integraal onderdeel van het SG-systeem is het periodiek kunnen uitlezen en aansturen van alle parameters van de Agent-devices. We onderscheiden de volgende componenten: 1. De 3 PV-installaties , (type inverter? Interfacespecificatie? INFO Zaanstad). 2. Het laadstation, uitbreidbaar tot maximaal 32 laadpalen, (type?? Interface? INFO Imtech). 3. De windturbine(s). 4. Interfaces met externe systemen zoals de meteo-server voor de weersvoorspelling. Parameters die minimaal beschikbaar moeten zijn per Agent-device: Specifieke data per device voor analysedoeleinden. Voor het laadstation impliceert dat: status mbt de werking van het laadstation, state of charge per laadpaal of per auto. Gebruikersinformatie. Voor de zonneinstallaties: geproduceerd vermogen, status mbt de werking van het systeem.
Data opslag systeem De functie van het data opslagsysteem is om alle relevante data vast te leggen als bron voor het analyseren van de gegevens van het SG-systeem. Tevens dient het als bron van informatie voor de rapportage tools, en de (web)applicaties waarmee de data aan het publiek kan worden getoond. De data wordt regulier, eens per 15 minuten opgeslagen.
Visualisatie Resultaten van de metingen worden gecomprimeerd en op een grafische display weergegeven via een webapplicatie (al of niet publiekelijk toegankelijk gemaakt).
4
Bij voorbeeld: een publiek toegankelijk web-display met info over “duurzaam Zaans vervoer” met daarop aangeven:
Het percentage of aantal kilometers gereden op duurzame energie. Weekproductie PV-installaties en windturbines versus actuele meteogegevens. State of charge accu’s. Voorzien van het logo van e-harbours, Zaanstad, Interreg, REloadIT. Daarnaast uitleg over relatie tussen het weer, de duurzame energieopwekking, en het elektrisch vervoer. Informatie per automobiel of gebruiker. Wat is mogelijk met het huidige laadpaalsysteem?
Data verwerking en rapportages De bron van de data verwerking en de rapportage is het data opslag systeem in de vorm van de data base (SQL server of mySQL oid). De data base dient via een open interface (zoals ODBC) toegankelijk te zijn. Rapportages kunnen mbv standaard tools als MS Access en Excel uitgevoerd worden. Er hoeven geen speciale applicaties voor ontwikkeld te worden.
5
Systeem specificaties Uitgangspunten systeemontwerp 1. Het systeem dient bij voorkeur schaalbaar te zijn, hetgeen impliceert dat bij uitbreiding van een bestaand type energieleverancier of gebruiker dit mogelijk is zonder het gehele platform te herzien. Laat zien wat wel en wat niet haalbaar is. Het systeem dient schaalbaar te zijn in de zin dat het systeem uitbreidbaar: de interfaces tussen de apparatuur binnen uw eigen standaard dienen bij voorkeur uniform te zijn. De bedoeling is dat er later windturbines en WKO (warmte koudeopslag) en evt pompen en gemalen in de businesscase kunnen worden opgenomen. 2. De apparatuur dient bij voorkeur draadloos informatie uit te wisselen. 3. Het SG-systeem is bij voorkeur platformonafhankelijk. Windows en Linux is toegestaan alhoewel voor de desktop data verwerking een koppeling met Windows vereist is. 4. Alle opgeslagen data dient toegankelijk te zijn in een data base, toegankelijk via een open interface zoals ODBC. 5. Bepaling van de hardware omgevingsspecificaties zoals locatie, huisvesting, temperatuur, vochtigheid, stof etc. TBD 6. Keuze hardware voor de MMI (man machine interfaces). Al of niet gebruikmaken van lokale displays. 5. Lokale stroomvoorziening: een UPS met een capaciteit van ca 30 minuten om het systeem zichzelf gecontroleerd uit te kunnen schakelen. 7. Bij uitval van de ICT-infrastructuur dienen het laadstation en de zonne-installaties autonoom te kunnen blijven werken. 8. Inbel-faciliteit voor het onderhouden van het systeem (VPN, in overleg met ICT dienst gemeente Zaanstad). nice to have
6
Systeem architectuur Het basisplatform is samengesteld uit de volgende onderdelen (zie Figuur 2: Concept systeemarchitectuur REloadIT):
Agent device PV systeem (3*) Agent device laadstation
Agent device Windturbine
Internet VPN
Fire wall
Workstation gemeente Zaanstad, Smart Grid server GUI reserveringssysteem
RF router
LAN Zaanstad
Laadstation
Console laadstation
Publieke web applicatie
Extern: Meteo server
Figuur 2: Concept systeemarchitectuur REloadIT
1. Een centraal opgestelde Workstation (IPC oid), die de coördinerende functie vervult van het totale systeem, en data base bevat, en de web-applicatie(s) serveert. 2. Het laadstation van Imtech (type ? INFO IMTECH ). Dit station is uitgerust met een ethernet of draadloze interface waarmee informatie uitgewisseld kan worden met het Workstation via een specifiek protocol. Minimum vereisten zijn: het systeem dient zonder aanpassing in het ontwerp of in de software geschikt te zijn voor maximaal 32 laadpunten. 3. Bedieningsconsole automobilisten (is dit mogelijk gezien beperkte intelligentie auto’s? Nader in te vullen: locatie, functies,….) 4. 3 zonne-installaties die op 3 onafhankelijke locaties staan opgesteld. De installaties hebben ieder een inverter die de zonne-energie omzetten in elektrische energie en op het 220 Volt distributienet injecteren. De inverter bevat tevens een interface (Merk type en type interface benoemen), waarmee het Smartgrid-paltform kan communiceren om de real time opbrengst van het paneel uit lezen. (Staan de inverters in een gesloten ruimte opgesteld of in de buitenlucht? ) 5. Een display panel dat in het stadshuis wordt opgesteld voor de weergave van kentallen van het systeem (nader te specificeren). Beeldscherm met webapplicatie (kan centrale Workstation zijn waarop de SGsoftware draait). 6. Meteo interface: koppeling met een real - of gesimuleerde interface met een weersvoorspellend systeem dat gebruikt wordt voor het voorspellen van de opbrengst van wind en zonne-energie in het SGsysteem. 7. Een link met het autoreserveringssysteem. Nader te definiëren (bv een koppeling met Outlook waarin de 16 auto’s ingepland kunnen worden). 8. Back up systeem: van de meetdata en parameters dient eens per week een back up gemaakt te worden.
7
Software architectuur SG-systeem
Figuur 3: Concept software architectuur c.q. proces data flow ReloadIT
Toelichting en ontwerpoverwegingen eventuele opties mbt de scope volgen nog.
8
Scope of work en deliverables Opleveringen Materialen Alle onderdelen zoals in de vorige paragraaf omschreven staan, en voorzover niet expliciet aangegeven, alle noodzakelijk onderdelen om het systeem compleet werkend op te leveren. Operationele kosten en consumables zoals communicatie- en internetkosten, reis- en verblijfkosten, etc… Buiten de scope vallen: De laadpaalinfrastructuur en de ICT infrastructuur althans het vaste netwerk.
Documentatie Documentatiepakket bestaande uit de volgende onderdelen: 1. Kwaliteitsplan software- of systeemontwikkeling (uittreksel). 2. Testplan c.q. factory- en site acceptance test (FAT en SAT) op te leveren SG-systeem. 3. Elektrotechnische tekeningen van de hardware, met name de interfaces met de infrastructuur en randapparatuur (as built). 4. Basis ontwerp software (as built). Activiteiten 1. Ontwerp en ontwikkeling van het SG systeem. 2. Inbedrijfstelling van het systeem obv een door de opdrachtnemer opgesteld SAT plan. 3. Operationeel onderhoud van het complete systeem tot 31-12-2013. 4. Het beschikbaar stellen van de data aan de eindgebruikers via autorisatiesysteem van de opdrachtgever. en data formaat toegankelijk via het centraal opgesteld Workstation en data base. 5. Handleiding bedieningsfuncties laadpalen de chauffeurs??? 6. Technische documentatie voor zover relevant voor de eindgebruikers en onderhoud van het systeem. Onderhoud en garantie 1. Operationeel houden van het gehele systeem gedurende de periode van het projectcontract van oplevering tot 31-12-2013. 2. Het binnen 3 werkdagen opnemen van een storing via een contactpersoon (accountmanager project of gebouwbeheerder ), en binnen 7 werkdagen oplossen van een storing. TBD 3. Bij defecten kosteloze vervanging van de ICT apparatuur gedurende de doorlooptijd van het projectcontract. Eigendomsrechten De geleverde apparatuur is eigendom van de Gemeente Zaanstad. De geleverde software, althans de binary objecten of executables zijn eigendom van Gemeente Zaanstad. De IP van de VPP-software en de broncode van de software zijn eigendom van de opdrachtnemer.
9
Quality Assurance De kwaliteitsaspecten omvatten de volgende aspecten: 1. Veiligheidseisen apparatuur moeten allen voldoen aan de CE markering eisen voor elektrotechnische apparatuur. 2. Opdrachtnemer heeft het recht tot het uitvoeren van ontwerp reviews voordat tot de werkelijke implementatie wordt overgegaan. 3. Site acceptance testen van het systeem en deelsystemen worden door de opdrachtnemer en opdrachtgever gezamenlijk uitgevoerd obv een door de opdrachtnemer opgesteld en door de opdrachtgever goedgekeurd testplan. 4. De opdrachtnemer dient aan te tonen dat zij volgens een kwaliteitssysteem werkt waarbij o.a. de ontwikkelmethodiek, testprocedures, en het versiebeheersysteem een onderdeel vormen.
10
Planning Zie tevens het projectplan (Ref 1). Binnen dat kader onderscheiden we de volgende fases en milestones: 1. Vastleggen cq fiatteren systeemeisen en gebruikerseisen. 2. Review basisontwerp systeemontwerp van opdrachtnemer door opdrachtgever. 3. Inzien detailontwerp voorafgaande de implementatie 4. Implementatie hardware en software 5. Afnametesten systeem, en deelsysteem obv de functionele- en systeemspecificaties. 6. Installatie op locatie 7. Afnametesten op locatie 8. Acceptatie totale systeem 9. Inbedrijfstelling totale systeem 10. Onderhoud van het systeem 11. Evaluatie en aanpassingen (buiten deze scope en obv nacalculatie). Tot mile stone 9 is de doorlooptijd 4 maanden, gerekend van opdrachtverstrekking tot oplevering.
Referenties Ref 1 Ref 2 Ref 3
11
Project plan REloadIT Specificatie IMTECH interface Specificatie PV-inverter
Bijlage: Uitwerking functionele specificaties
12
13
