Building Automation System

Transkript

1 Sektor for Elektroteknik og Informationsteknologi Ingeniørhøjskolen i København Lautrupvang 15, 2750 Ballerup 5. semester projekt - Efterår 2012 SUSIE Vejleder Ole Schultz Deltager Studienummer Underskrift Martin Ravn Troels Vest

2 Indholdsfortegnelse FORORD INTRODUKTION SYSTEMBESKRIVELSE RISIKOSTYRING PROBLEMANALYSE OG PROJEKTAFGRÆNSNING KRAVSPECIFIKATIONER Funktionskrav Hardwarekrav Softwarekrav USE CASE MODEL USE CASE SPECIFIKATIONER NETDUINO VS. ARDUINO PROBLEMLØSNING BLOKDIAGRAM XBEE OG ZIGBEE Enhedstyper Netværksopsætninger SENSORMODUL INTERFACEBOARD KLASSEBESKRIVELSER SOLCELLE SOM STRØMFORSYNING Strømforbrug i idle mode Strømforbrug i sample mode Valg af optimal placering af solcelle ud fra strømforbrug Sleep mode ENERGIFORBRUG FOR NETDUINO PLUS BRUGERMANUAL WEBINTERFACE SMS ALARMER ENERGIOPTIMERING BRUG AF EN TILSTEDEVÆRELSESENSOR LIVSCYKLUSANALYSE FOR ET XBEE-MODUL FORMÅL FUNKTIONEL ENHED MÅLGRUPPE MECO CHART HVAD HAR VI LÆRT? PROGRAMMERING Side 2 af 51

3 7.2 SENSORER XBEE OG ZIGBEE RUM INDRETNING KONKLUSION REFLEKSION OVER SUSIE KURSET LITTERATURFORTEGNELSE BØGER HJEMMESIDER BILAG PROJEKTOPLÆG SOLCELLEMÅLINGER Gammelt loftarmatur Nyt loftarmatur På bordet I vindueskarmen KOMPONENTLISTE Sensormodul Interfaceboard MECO CHART Side 3 af 51

4 Forord Indholdet af denne rapport er en fremstilling af projektet i Sustainable electronics and IT. Vores gruppe består af to ingeniørstuderende på elektroniklinjens 5. semester. Vi vil i rapporten give en problembeskrivelse af projektet, samt hvordan vi har valgt at løse problemet, så det svarer til de krav der er defineret. Inden vi starter på de mange forklaringer og beskrivelser, vil vi gerne takke udefra stående personer som har bidraget med hjælp og vejledning i projektforløbet. Ole Schultz: Takkes for sine lektioner i kurset SUSIE. Derudover takkes han for sin konstruktive sparring med gruppen, i henholdsvis udviklings- og dokumentationsfasen. Jesper Molin: Takkes for sine lektioner i kurset BIHK, samt supplerende vejledning i udviklingsfasen. Peder Hundebøll: Takkes for sine foredrag omkring LCA, samt hjælp til denne. Birte Møller Andersen: Takkes for hendes vejledning i rumindretning og arbejdsmiljø. Komponentshoppen: Takkes for det brede udvalg af komponenter, samt råd og vejledning i forbindelse med disse. I det følgende gives en kort beskrivelse af hvad der er muligt at læse i vores rapport. Vi lægger ud med en kort systembeskrivelse af projektet. Efter dette kommer vores risikostyring. Denne gjorde os tidligt i projektet opmærksomme på hvilke risici der var forbundet med projektarbejdet, samt hvordan disse risici undgås. Vores problemanalyse og projektafgrænsning som indeholder kravspecifikationer og use cases samt use case model blev ligesom risikostyringen, lavet meget tidligt i udviklingsfasen. Disse krav er ment som vores mål med vores færdige system. Efter dette følger vores problemløsning. Denne beskriver i detaljer hvordan vi har løst problemet. Det er derfor også dette afsnit som er teknisk mest krævende at læse. Vi har i det efterfølgende afsnit om energioptimering forsøgt at estimere en eventuel besparelse ved implementering af vores system. Side 4 af 51

5 Udover dette har vi lavet en livscyklusanalyse over et XBee modul som benyttes til trådløs kommunikation i vores system. Til sidst i denne rapport opridser vi hvad vi har lært igennem arbejdet med dette projekt, samt konkluderer vores løsning ud fra de opstillede krav. 1. Introduktion 1.1 Systembeskrivelse Med vores system er det muligt, at styre rumtemperatur, ventilation og belysning ud fra de aktuelle forhold der er i lokalet. Systemet fungerer ved at man først starter systemet - enten gennem en booking af lokalet gennem et webinterface, eller ved at benytte kontakten på væggen. Benytter man sig af muligheden for at booke lokalet, så sørger systemet for at starte op en halv time før reservationen er lavet så forholdene er i orden når tidspunktet for reservationen er nået. Hovedenheden i systemet er et Netduino Plus board. Dette board styrer relæerne til de forskellige funktioner, så som ventilation, radiator og lys. Målingerne af de aktuelle forhold sker trådløst via et eksternt sensor. Boardet kommunikerer med Netduino en over ZigBee protokollen igennem to stk. XBee moduler. Når der forekommer en situation i systemet som kræver opmærksomhed, som f.eks. at batteriet på det eksterne sensor board er ved at løbe tør, så sender systemet en SMS til administratoren. Side 5 af 51

6 1.2 Risikostyring I nedenstående tabel har vi indekseret forskellige risici efter hvor stor sandsynligheden er for at de indtræffer, hvorefter vi har taget stilling til hvor stor en indvirkning det vil have på projektets færdiggørelse hvis de skulle opstå. Derefter kommer vi med en mulig løsning på hvordan de kan undgås. Risiko Sandsynlighed Indvirkning Hvordan undgåes risikoen? Manglende faglig viden blandt udviklerne Lav Høj Uddannelse, kurser Hjælp fra underviser Selvstudie i form af bøger og internet Simuleringer Virkelige eksperimenter Indbyrdes holdproblemer: Mellem Mellem Lav en klar og detaljeret Holdkontrakt ikke eksisterende eller ikke funktionel holdkontrakt i starten af projektarbejdet De individuelle personer på holdet Team building kender ikke deres rolle Spørg underviseren til råds Interessekonflikter mellem personer på holdet Underviser fraværende pga. sygdom eller lignende Lav Lav Få hjælp fra medstuderende eller andre undervisere Selvstudie Tab af data Mellem Høj Tage backup jævnligt, både i Dropbox, USB-stick og på CampusNet Udviklerne fraværende pga. sygdom, arbejde etc. Mellem Mellem Nogle må arbejde ekstra, hvis én skulle være fraværende Planlægge evt. nødvendige fridage Uddelegere specifikke opgaver Arbejde ekstra om eftermiddagene og i weekenderne Forkerte komponenter Lav Høj Komponenterne dobbelt tjekkes og evt. måles før brug Side 6 af 51

7 2. Problemanalyse og projektafgrænsning 2.1 Kravspecifikationer Funktionskrav F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F14 Funktionskrav Lokalets temperatur skal reguleres automatisk ud fra værdien af en temperatursensor. Lokalets lys skal styres automatisk ud fra værdien af en lysanhængig modstand. Lokalets ventilation skal åbnes og lukkes ud fra værdien af en CO2-sensor. Lokalets lys skal kunne tændes og slukkes uafhængigt af systemet. Det skal være muligt at booke lokalet. Bookingsystemet skal sørge for at lokalet starter op en halv time før booking start. Det skal være muligt at starte systemet op via en kontakt, og dermed overrule booking systemet. Alle sensorer skal kommunikere trådløst med hovedenheden. Det skal være muligt at se lokalets temperatur via et webinterface. Det skal være muligt at se lokalets lysniveau via et webinterface. Det skal være muligt at se lokalets CO2-niveau via et webinterface. Det skal være muligt at se de trådløse sensormodulers batterispænding via et webinterface. Hvis temperaturen når under eller over x-antal grader skal der sendes en advarsel til administrator via SMS. Hvis batterispændingen på de trådløse sensormoduler når under x-antal Volt skal der sendes en advarsel til administrator via SMS Hardwarekrav Vi har i vores udviklingsfase diskuteret og analyseret, hvilken hardware der ville være nødvendig og smart at implementere. Derfor er vi kommet frem til følgende hardwarekrav., H1 H2 H3 H4 H5 H6 H7 Hardwarekrav Hovedenheden i systemet skal være en Netduino Plus. De trådløse sensormoduler skal kommunikere trådløst via ZigBee protokollen. Minimum et trådløst sensormodul skal forsynes fra en grøn energikilde, som f.eks. en solcelle. Som interface til 230 V styring, skal der benyttes USB-strømspareskinner. Kontakterne til at aktivere systemet, samt tænde og slukke for lyset, skal være en fjederbelastet kroneafbryder. Til forsyning af sensormodulet med solcellen skal der benyttes et 3,7 V Litium-Ion batteri. Til opladning af batteriet gennem solcellen benyttes en MCP73871 ladekreds fra Adafruit Industries. Side 7 af 51

8 2.1.3 Softwarekrav Softwarekrav S1 Programmeringssproget ASP.NET C# skal bruges til programmering af Netduino Plus en. S2 Udviklingsmiljøet i S1 skal være Microsoft Visual Studio 2010 S3 Programmeringssproget ASP.NET C# skal bruges til programmering af webinterfacet. S4 Udviklingsmiljøet i S3 skal være Microsoft Visual Studio 2012 Side 8 af 51

9 2.2 Use case model På Figur 2.1 ses vores use case model. Denne viser hvilke aktører der er knyttet til de enkelte use cases. System Book lokale Start system Stop system Bruger Administrator Modtag SMS alarmer Se temperatur Se lysstyrke Se batterispænding Se CO2 niveau Booking system Tænd/sluk lys uafhængigt af systemet Figur 2.1 Side 9 af 51

10 2.3 Use case specifikationer Herunder er en beskrivelse af de forskellige use cases i vores system. Hver enkelt beskrivelse forklarer forløbet for den enkelte use case, samt forudsætninger og postconditions for disse. UC1: Book lokale Kort beskrivelse: Det skal være muligt gennem et webinterface at booke et lokale til et bestemt tidsrum. Brugere: Bruger og administrator. Forudsætninger: At brugeren eller administratoren har adgang til systemet. Hovedforløb: Use case en starter når man fra webinterfacet opretter en booking. Denne booking vil sørge for at systemet starter op en halv time før bookingen start, så lokalet er tilpas opvarmet. Postconditions: Der er registeret en booking og systemet starter når tiden for booking er nået. Alternativ forløb: Brugeren starter systemet manuelt gennem kontakten på væggen. UC2: Start system Kort beskrivelse: Lys, varme og ventilation startes. Brugere: Bruger, administrator og booking system. Forudsætninger: Systemet skal være stoppet. Der skal være fortaget en booking i systemet, eller der skal trykkes på kontakten i det respektive lokale. Hovedforløb: Use case en starter når tidspunktet for bookingen passerer, eller når der trykkes på kontakten på væggen. Når systemet er startet reguleres der efter det aktuelle forhold. Postconditions: Systemet er startet og der reguleres efter de aktuelle forhold. Alternativ forløb: Systemet stoppes Side 10 af 51

11 UC3: Stop system Kort beskrivelse: Lys, varme og ventilation stoppes. Brugere: Bruger, administrator og booking system. Forudsætninger: Systemet skal være startet. Der skal være fortaget en booking i systemet og tidspunkt for bookingens udløb skal være passeret, eller der skal trykkes på kontakten i det respektive lokale. Hovedforløb: Use case en starter når tidspunktet for bookingens udløb passerer, eller når der trykkes på kontakten på væggen. Når systemet er stoppet reguleres der efter kravet om en minimumstemperatur på 16 grader. Postconditions: Systemet er stoppet og der reguleres efter de aktuelle forhold. Alternativ forløb: Systemet startes. UC4: Modtag alarm SMS er Kort beskrivelse: Hvis der er fejl eller ting der kræver opmærksomhed i systemet som f.eks. lav batterispænding på de trådløse sensormoduler, skal systemet give besked til administrator via SMS. Brugere: Administrator. Forudsætninger: Fejl på systemet, eller ting der kræver administratorens opmærksomhed. Hovedforløb: Hvis en situation som kræver opmærksomhed fra en administrator indtræffer sender systemet en SMS til administratoren med information om hvad der er galt. Postconditions: Administratoren er informeret om problemet og kan nu foretage de nødvendige ændringer/udskiftninger. Alternativ forløb: Administratoren tjekker selv systemet via webinterfacet. Side 11 af 51

12 UC5: Se temperatur Kort beskrivelse: Det skal være muligt at se lokalets aktuelle temperatur via et webinterface. Brugere: Bruger og administrator. Forudsætninger: At der er adgang til webinterfacet og der er kommunikation med temperatursensoren. Hovedforløb: Use casen starter når man går ind på webinterfacet og vælger temperaturmenuen. Herefter måles temperaturen og den vises på skærmen. Postconditions: Temperaturen er blevet vist på skærmen. Alternativ forløb: Der vælges en anden funktion eller temperaturen måles manuelt. UC6: Se lysniveau Kort beskrivelse: Det skal være muligt at se lokalets aktuelle lysniveau via et webinterface. Brugere: Bruger og administrator. Forudsætninger: At der er adgang til webinterfacet og der er kommunikation med lysniveausensoren. Hovedforløb: Use casen starter når man går ind på webinterfacet og vælger lysmenuen. Herefter måles lysniveauet og det vises på skærmen. Postconditions: Lysniveauet er blevet vist på skærmen. Alternativ forløb: Der vælges en anden funktion eller lysniveauet måles manuelt. Side 12 af 51

13 UC7: Se batterispænding på et trådløst sensormodul Kort beskrivelse: Det skal være muligt som administrator at se batterispændingen på sensormodulerne via et webinterface. Brugere: Administrator. Forudsætninger: At der er adgang til webinterfacet og der er kommunikation med sensormodulet. Hovedforløb: Use casen starter når man går ind på webinterfacet og vælger batterispændingsmenuen. Herefter måles batterispændingen og den vises på skærmen. Postconditions: Batterispændingen er blevet vist på skærmen. Alternativ forløb: Der vælges en anden funktion eller målingen foretages manuelt. UC8: Se CO2 niveau Kort beskrivelse: Det skal være muligt at se lokalets aktuelle CO2 niveau i lokalet via et webinterface. Brugere: Bruger og administrator. Forudsætninger: At der er adgang til webinterfacet og der er kommunikation med CO2-niveausensoren. Hovedforløb: Use casen starter når man går ind på webinterfacet og vælger CO2-menuen. Herefter måles CO2-niveauet og det vises på skærmen. Postconditions: CO2 niveauet er blevet vist på skærmen. Alternativ forløb: Der vælges en anden funktion eller målingen foretages manuelt. Side 13 af 51

14 UC9: Sluk/tænd lyset uafhængigt af systemet Kort beskrivelse: Det skal være muligt at tænde lyset uden at tænde hele systemet. Denne funktions skal blandt andet benyttes af rengøringen, så der kan blive gjort rent i klasselokalet uden at man behøver at tænde hele systemet op. Samtidig skal lyset kunne slukkes uden hele systemet slukkes. Denne funktion kan f.eks. benyttes når lokalet skal mørklægges hvis der skal bruges en projektor eller overhead. Brugere: Bruger og administrator. Forudsætninger: At der er en separat vægkontakt med denne funktion. Hovedforløb: Use casen starter når man trykker på vægkontakten som har tilknyttet denne funktion. Efter der er trykket er lyset enten tændt eller slukket afhængigt af om det var tændt eller slukket inden der blev trykket. Postconditions: Lyset er tændt eller slukket. Alternativ forløb: Lyset styres automatisk efter de aktuelle lysforhold i lokalet. Side 14 af 51

15 2.4 Netduino vs. Arduino Da vi startede på projektet, var vi i tvivl om hvilken platform vi skulle benytte os af. En dag fik vi et tip af en kammerat som anbefalede os at tage et kig hen imod Netduino platformen. Derfor lavede vi lidt research og fandt hurtigt ud af, at der var mange muligheder med Netduino. Chris Walker, en af mændene bag Netduino udtaler blandt andet 1 : Both Arduino and Netduino are great introductory platforms (8-bit and 32-bit correspondingly). A few reasons why users might want to pick up a Netduino: 1. With Netduino, you can create _really_ sophisticated projects 2. Visual Studio integration, ability to debug your Netduino apps 3. C# (and soon, Visual Basic) -- easy and ability to reuse code in phone/xbox/desktop/web apps 4. Lots of FLASH and RAM (4x FLASH, 30x RAM) 5. "32-bits for an 8-bit price" 6. True open source TCP/IP networking, simple USB functionality 7. Less need to switch to native C/C++ code for 'advanced' applications mA power regulators, 16-bit PWMs, really nice hardware 9. MonoDevelop support project in progress (Mac/Linux future experimental support) 10. Next-generation technology A few reasons why users might want to pick up an Arduino: 1. "Lots of blinky lights" and other applications which require native code speed 2. Large pool of users, large pool of projects to pick from, lots of kits 3. Lots of clones to pick from, in a variety of form factors 4. Mac and Linux support today 5. Learning Arduino programming is a bridge between "easy" 8 bit programming and true C/C++ embedded programming Som man kan høre på Chris udtalelse, er der langt flere muligheder ved at vælge Netduino platformen i forhold til Arduino platformen. Vi har derfor valgt at bruge et Netduino Plus board frem for de udleverede Arduino boards i SUSIE. 1 Side 15 af 51

16 3. Problemløsning 3.1 Blokdiagram På Figur 3.2 ses et blokdiagram over vores system. Dette viser de forskellige blokke i systemet samt deres forbindelser til hinanden. Sol Temperatursensor Lyssensor Co2-sensor Fotoner ADC 0-1,2 V DC ADC 0-1,2 V DC ADC 0-1,2 V DC Solcelle panel 0-6 V DC 3,7 V DC Lade-kredsløb XBee 3,7 V DC ZigBee 2.4 GHz Li-Ion batteri XBee UART Netduino Ethernet Computer Logisk 0 eller 1 (0 eller 3.3 V DC) 230 V AC Relæ 0 eller 230 V AC 0 eller 230 V AC 0 eller 230 V AC Radiator Lys Ventilation Figur 3.1 Side 16 af 51

17 3.2 XBee og ZigBee Man kunne godt gå hen og forveksle XBee med ZigBee og tro at det var en og samme ting. Men det er forkert. ZigBee er en standard kommunikationsprotokol til lavenergi trådløse mesh netværk og XBee er et mærke af enheder som understøtter forskellige slags kommunikationsprotokoller, som f.eks. ZigBee. På samme måde som Bluetooth er en standard, er ZigBee en standard i den forstand at alle produkter der supporterer ZigBeestandarden kan kommunikere med hinanden. Måden det fungerer på, er ved brug af lag. De fleste moderne netværksprotokoller benytter lag til at adskille komponenter og funktioner i uafhængige moduler som derefter kan sammensættes på forskellige måder. Alle netværk har et fysisk lag hvor signalerne overføres fra. Et eksempel kan være ens computer. Her kan man være forbundet til internettet via et Ethernet kabel, men man kan derudover også være forbundet via Wi-Fi. Alt dette sker i det fysiske lag og har ikke noget at gøre med hvad der f.eks. sker i applikationslaget. I applikationslaget har vi f.eks. ens browser, og denne er ligeglad med hvilken forbindelsestype der vælges, da den er sikret af de interfaces der er imellem lagene. Disse interfaces sikrer at lige meget hvordan hardware eller software ændre sig, så kan lagene stadig kommunikere sammen. Netværkslaget under ZigBee er et sæt af standarder og kaldes for IEEE Disse sæt bestemmer ting som power management, addressing, error correction, message formats samt point-to-point. Alle nødvendige dele der skal til for at oprette korrekt forbindelse mellem enhederne. ZigBee er et sæt af lag som er bygget oven på IEEE Disse lag tilføjer tre vigtige ting: Routing Routing tabeller som definerer hvordan en enhed kan sende beskeder gennem en serie af enheder frem til destinationen. Ad hoc network creation Dette er en automatisk proces som danner netværket undervejs som enheder tilføjes. Self- healing mesh Self-healing er en proces der automatisk finder ud af når en eller flere enheder mangler i netværket og derefter re-konfigurerer netværket så brudte veje bliver ordnet. Side 17 af 51

18 3.2.1 Enhedstyper Et ZigBee netværk kan bestå af tre forskellige enhedstyper: Koordinator Et ZigBee netværk har altid en koordinatorenhed. Denne enhed har ansvaret for at forme netværket, udlevere adresser samt styre andre funktioner som definerer netværket, sikrer det og holder det ved lige. Et netværk skal altid skabes af en koordinator og der er aldrig mere end én koordinator i hvert netværk Router En router er en fuld funktionel ZigBee node som kan slutte sig til eksisterende netværk, sende og modtage information, samt route information mellem enheder der er for langt væk fra hinanden til kommunikationen kan gå direkte. En router skal være tændt hele tiden da den skaber forbindelsen gennem netværket, og er derfor typisk sluttet til el nettet End node En end node kan lige som routeren slutte sig til et eksisterende netværk og sende og modtage information. De kan ikke som routeren bruges til at sende information mellem to andre enheder. Dette gør at den ikke behøver at være tændt hele tiden og de kan derfor gå i en såkaldt sleep mode for at spare energi. En end node skal altid have en koordinator eller en router som forældreenhed. Denne enhed hjælper end noden med at koble sig til netværket samt gemmer data for dem mens de er i sleep mode. Et ZigBee netværk kan have et hvilket som helst antal af end noder. Faktisk kan et netværk konstrueres af én koordinator, adskillelige end noder og ingen routere Netværksopsætninger ZigBee enhederne i en et netværk kan forbindes i forskellige opsætninger for at danne netværksstrukturen. Opsætningen indikerer hvordan noderne er logisk forbundet. Disse opsætninger er som følgende: Pair Dette er det mest simple netværk med kun to enheder, hvor af den ene skal være koordinator og den anden enten skal være router eller end node. Side 18 af 51

19 Star Denne netværksopsætning er også simpel. En koordinator er centrum i stjernen og forbinder til en cirkel af end noder. Dette betyder at alle informationer routes gennem koordinatoren. End noderne kommunikerer altså ikke med hinanden direkte Mesh Mesh-opsætningen bruger router enheder som tillæg til koordinatoren. Disse routere kan sende information mellem hinanden og til end noderne. Koordinatoren styrer netværket, men fungerer samtidig også som router. Adskillelige end noder kan tilføjes til routerene eller koordinatoren. Disse end noder kan modtage og sende information, men benytter deres forældreenhed til at kommunikere med de andre noder Cluster tree Dette er en netværksopsætning hvor routere danner en form for backbone hvor der er en række end noder som kommunikerer gennem en router med resten af netværket. Der er ikke den store forskel mellem mesh- og cluster tree-opsætningen. Figur Figur 3.2 viser de fire forskellige netværkstyper. 2 Side 28 i bogen Robert Faludi Building Wireless Sensor Networks with ZigBee, XBee, Arduino and Processing Side 19 af 51

20 3.3 Sensormodul Vores sensormodul er bygget op omkring et XBee-modul. Dette modul sørger for at kommunikere med vores Netduino Plus. Til sensorer benytter vi analoge komponenter. Som lyssensor bruger vi os af en LDR og vi benytter på samme måde en NTC modstand som temperatursensor. Grunden til at vi benytter disse analoge sensorer er, at XBee-modulet ikke understøtter brugen af hverken OneWire eller I2C. Det er derfor ikke muligt at benytte disse digitale sensorer. For at udlade et unødigt strømforbrug på sensormodulet, er de to sensorkredsløb med henholdsvis LDR og NTC modstanden forsynet gennem en digitale I/O porte på XBee-modulet. Det betyder at vi kun forsyner kredsløbet når portene sættes til logisk 1 og dermed giver 3,3 V, hvilket betyder at vi kan tænde kredsløbet, lave en måling og derefter slukke for kredsløbet igen. XBee ens ADC arbejder med en referencespænding på 1,2v. Vi er derfor nød til at lave en spændingsdeler som vist på Figur V 15K NTC/LDR ADC 10K Figur 3.3 Vi har fundet modstandsværdierne til spændingsdeleren ved at bestemme størrelserne på modstandene så outputtet er 1,2V når NTC eller LDR ens modstandsværdi er 0. Vi har lagt bundmodstandens værdi fast til og dermed finder vi seriemodstandens værdi ved følgende ligning: Outputtet fra spændingsdeleren kan herefter bestemmes ved følgende ligning: Side 20 af 51

21 På vores sensormodul har vi også to lysdioder. Disse to lysdioder er tilsluttet hver deres digitale I/O port på XBee-modulet. Lysdioderne er kun brugt til debugging i forbindelse med udviklingen for hurtigt at kunne teste forbindelsen mellem modulerne. På Figur 3.4 ses diagrammet for vores sensormodul. POWER CON2 R U1 Vcc AD0/Dio0 Dout AD1/Dio1 Din/conf AD2/Dio2 /Rst AD3/Dio3 PWM/RSSI RST/AD6/Dio6 Nc0 Asso/AD5/Dio5 Nc1 AD4/Dio4 /DTR/Sleep_RQ/Dio8 /CTS/Dio7 Gnd Do8 ON/Sleep Vref R5 R R7 15k D1 LED 15k D2 LED LDR 10k R2 10k NTC 10k R3 10k XBee Figur 3.4 Komponentlisten for sensormodulet kan findes i bilag Interfaceboard Vi har lavet et interfaceboard som vi benytter til at styre hvilke ting der skal tænde og slukke. Vi benytter en række USB-strømspareskinner som relæer, da vi på den måde undgår at pille ved 230 V AC ved siden af systemet. I spareskinnen sidder der et relæ som ved et 5 V input gennem USB-stikket slutter og tillader stikdåsen at lede. Da relæet skal bruge en større strøm end Netduino Plus en kan udlevere på sine digitale I/O porte har vi bygget et kredsløb hvor vi benytter en NPN transistor som switch. Vi forsyner med en 12 V strømforsyning og benytter derfor en 5 Volts spændingsregulator. På interfaceboardet sidder der også en klemmerække hvor på vi har monteret vores LK kroneafbryder. Indgangen på afbryderen er forbundet med en 3,3 V spændingsregulator, da det er denne spænding som Netduino ens digitale I/O porte definerer som logisk 1. Via interfaceboardet er det muligt at styre fem USB-strømspareskinner uafhængigt af hinanden. Side 21 af 51

22 Diagrammet for vores interfaceboard ser ud som vist på Figur 3.5. Power J U6 C1 100n LM VIN U7 VIN LE33 Netduino J1 J3 VOUT VOUT LK af bry der C2 100n R12 R11 10k 10k D5 1N4001 R6 2k R1 D4 1N R7 2k R2 D3 1N R8 2k R3 D2 1N R9 2k R4 D1 1N R10 2k R Q1 BD Q2 BD Q3 BD Q4 BD Q5 BD441 U1 Vcc Data+ Data- GND USB U2 Vcc Data+ Data- GND USB U3 Vcc Data+ Data- GND USB U4 Vcc Data+ Data- GND USB U5 Vcc Data+ Data- GND USB 20 Figur 3.5 Side 22 af 51

23 3.5 Klassebeskrivelser I vores system har vi brugt to biblioteker som vi har fundet ud af dækker vores behov. Det første bibliotek er en såkaldt Multi-threaded web server for Netduino Plus 3 og er lavet af en person ved navn Jasper Schuurmans. Som navnen antyder, er det en simpel multitrådet web server til vores Netduino Plus. Biblioteket indeholder tre klasser: WebCommand.cs WebControlEventArgs.cs WebServer.cs Man har her mulighed for at definere et sæt af tilladte kommandoer og parametre som kan blive kaldt på serveren. Når serveren modtager en gyldig kommando, fyrer den et CommandReceived event med detaljer som er gemt i WebControlEventArgs parameteren. Biblioteket bruges på følgende måde: Instantiere en ny instans af WebServer: WebServer server = new WebServer(5000); Tilføj en handler til CommandReceived -eventet: server.commandreceived += new WebServer.CommandReceivedHandler(serverCommandReceived); Tilføj en eller flere kommandoer: server.allowedcommands.add(new WebCommand("setled", 1)); - Denne betyder at man kan kalde server.allowedcommands.add(new WebCommand("writechannel", 2)); - Betyder at man kan kalde Start server: server.start(); Det andet bibliotek vi bruger er en modificeret udgave af Asynchronus API XBee biblioteket fra Grommet, som er et udvidelsesbibliotek til.net Micro Frameworket som vores Netduino bruger. Denne modificerede udgave er lavet af en person ved navn Josefa 3 Side 23 af 51

24 Rouska og er udviklet specielt til at arbejde med det minimum af ressourcer man har i en microcontroller. Derudover er det også udviklet til at arbejde specielt til XBee i API mode. Biblioteket indeholder følgende fire klasser: ApiFrame.cs ApiFrameBuilder.cs Enumerations.cs XBee.cs Biblioteket fungerer ved at man kalder en metode der hedder SendRemoteAtCommand. Denne metode skal have tre parametre: Destinationens (XBee modulets) serienummer, AT kommandoen og et XBee callback. XBee callback et er den ramme som der bliver sendt tilbage til afsenderen når man har sendt en ramme til modtageren. Ud over disse to biblioteker har vi lavet en klasse som sammenholder og styrer hele systemet: Program.cs Denne klasse er hovedklassen i hele systemet, og af vigtige metoder kan der nævnes: Metodenavn Returtype Beskrivelse StartSystem(bool state) void Starter eller stopper hele systemet, alt efter om man giver den en true eller false som parameter. TurnOnCeilingLights(bool state) void Tænder eller slukker for loftlyset, alt efter om man giver den en true eller false som parameter. GetSupplyVoltage(XBeeModule module) GetTemperature(XBeeModule module) ServerCommandReceived(object source, WebCommandEventArgs e) double double Returnerer forsyningsspændingen på det XBee modul man giver som parameter. Returnerer den aktuelle temperatur på det sensormodul man angiver som parameter. void Denne metode bliver kaldt med en WebCommandEventArgs parameter når web serveren bliver kaldt med en kommando. Alt efter hvad denne kommando er, udfører metoden de forskellige cases som er defineret. Side 24 af 51

25 0,049 0,083 0,124 0,163 0,204 0,607 1,008 1,405 1,804 2,2031 4,944 5,52 5,77 5, Solcelle som strømforsyning Et krav til projektet er at der skal benyttes grøn energi som forsyning til et sensormodul. Vi har derfor valgt at benytte os at et li-ion batteri som oplades af en solcelle. For at se om denne energikilde er tilstrækkelig har vi foretaget en del målinger på solcellen ved forskellige placeringer, for at se om den kan levere nok strøm til at lade batteriet, samt forsyne sensorboardet. Vi har placeret solcellen forskellige steder, og taget målinger på outputtet. Herefter har vi tegnet en graf med strømmen som funktion af spændingen samt effekten som funktion af spændingen. Først ser vi på placeringen tæt på et gammelt loftarmatur i klasseværelset som vist på Figur 3.6. Figur 3.6 Ud fra vores målinger som kan ses i bilag?? har vi lavet en graf som vist på Figur 3.7. Gammelt loftarmatur 0, , ,09 0,08 0,07 0,06 0,05 0,04 0,03 0,02 0,01 0 Current [A] Power [W] Figur 3.7 Den blå graf viser strømmen som funktion af spænding og den røde graf viser effekten som funktion af spændingen. Vi aflæser strømmen til det punkt på grafen hvor effekten er størst, og vi kan her se at den største strøm som solcellen kan levere er. Derudover kan vi aflæse at den maksimale effekt som solcellen kan levere er. Side 25 af 51

26 0,067 0,133 0,2 0,266 0,334 0,997 1,659 2,32 2,976 3,642 6,063 6,188 6,277 6, Dernæst har vi foretaget målinger hvor solcellen er placeret tæt på et nyt loftarmatur som vist på Figur 3.8. Figur 3.8 Ud fra disse målinger som kan findes i bilag?? har vi lavet en graf som vist på Figur 3.9. Nyt loftarmatur 0, , ,18 0,16 0,14 0,12 0,1 0,08 0,06 0,04 0,02 0 Current [A] Power [W] Figur 3.9 Også her viser den blå graf strømmen som funktion af spænding og den røde graf viser effekten som funktion af spændingen. Strømmen i det punkt hvor effekten er størst har vi aflæst til at være. Den maksimale effekt solcellen kan levere er 162,4. Side 26 af 51

27 0,0015 0,0028 0,0042 0,005 0,007 0,021 0,035 0,049 0,063 0,078 0,219 0,36 0,779 4, Herefter har vi placeret solcellen på bordet som vist på Figur 3.10 og foretaget målinger her. Figur 3.10 På bordet 0,0016 0, ,0014 0,0012 0,001 0,0008 0, ,0006 0,0004 0, Current [A] Power [W] Figur 3.11 Her på Figur 3.11 kan vi aflæse at den maksimale strøm som solcellen kan levere er og at den maksimale effekt solcellen kan levere er. Side 27 af 51

28 0,0032 0,006 0,01 0,014 0,016 0,048 0,08 0,112 0,143 0,176 0,5057 0,838 1,797 4, Til sidst har vi placeret solcellen i vindueskarmen som vist på Figur 3.12 og foretaget målinger. Figur 3.12 I vindueskarmen 0,0035 0,003 0, ,0025 0,002 0, ,0015 0,001 0, Current [A] Power [W] Figur 3.13 På grafen på Figur 3.13 kan vi aflæse at den maksimale strøm som solcellen kan levere i vindueskarmen er og den maksimale effekt er. Side 28 af 51

29 Vi har efter disse målinger af solcellen foretaget målinger af strømforbruget for vores sensormodul. Under disse målinger har vi anvendt et break-out board til XBee modulet uden lysdioder og spændingsregulator. Målingerne af strømforbruget er taget ved at montere en modstand i serie med strømforsyningen, hvorefter spændingen over denne måles. Hermed kan vi igennem Ohm s lov beregne strømmen Strømforbrug i idle mode I idle mode kommunikerer vi ikke XBee-modulet og strømforbruget svinger derfor mellem til. Grunden til at strømforbruget ikke er konstant i denne situation, er at der underliggende i ZigBee-protokollen sker en såkaldt keep alive kommunikation mellem de to moduler. Denne kommunikation kan monitoreres i programmet Wireshark som vist på Figur 3.14 Figur 3.14 Da tiden for det højeste og laveste strømforbrug er tilnærmelsesvis ens, kan vi derfor tage gennemsnittet af de to værdier som et mål for strømforbrug i idle mode. Gennemsnittet for XBee modulet i idle mode kan derfor siges at være her.. Effektforbruget er Strømforbrug i sample mode Vi har herefter målt strømforbruget når XBee-modulet tager en sample samt når den sender de samplede værdier tilbage til koordinatoren. Når modulet sampler har vi mål strømforbruget til at være, og når der efterfølgende sendes data retur til koordinatoren er strømforbruget. Vi vurderer at denne situation hvor vi beder om en sample og denne sendes retur, er et gennemsnitligt strømforbrug på. Effektforbruges er her. Side 29 af 51

30 3.6.3 Valg af optimal placering af solcelle ud fra strømforbrug Ud fra vores målinger af XBee-modulets strømforbrug kan vi nu vælge hvilken af de fire afprøvede placering af solcellen der vil være den optimale. Vi kan se på målingerne at ved placering i vindueskarmen, kan solcellen maksimalt levere en strøm på hvilket kun er nok til at forsyne XBee-modulet i idle mode. Det betyder, at der på intet tidspunkt vil ske en opladning af batteriet, og det vil derved ikke være muligt at lagre energi til brug når der intet lys er. Ligeledes kan det ses, at ved placering på bordet, kan solcellen maksimalt levere end strøm på hvilet ikke engang er nok til at forsyne XBee-modulet. Hvorimod en placering af solcellen tæt ved det gamle loftarmatur vil give en maksimal strøm fra solcellen på. Dette vil være tilstrækkeligt, da der vil ske en opladning af batteriet når XBee-modulet er i idle mode og der ikke samples. Dog leverer den kun omtrent nok til at dække XBee-modulets behov når der samples. Det er dog ikke et problem, da tiden hvor der ikke samples er langt større end tiden hvor der samples. Der vil derved være rig mulighed for opladning af batteriet. Placeres solcellen tæt ved den nye type loftarmatur, ses det at den her kan levere en strøm på maksimalt. Det vil derfor være den optimale placering for solcellen, set ud fra de fire testede placeringer af solcellen, da der her vil ske en opladning af batteriet både ved idle mode og når der samples. Vi har i ovenstående ikke taget højde for et evt. strømforbrug fra ladekredsløbet. Ved en fuld opladning af vores li-ion batteri kan det levere. Det betyder at batteriet vil kunne holde XBee-modulet kørende i idle mode i. Det er svært at estimere hvor længe XBee-modulet egentlig vil holde på batteriet, da dette afhænger af hvor ofte der samples. Da vi igennem vores webinterface giver brugeren mulighed for at se de aktuelle målinger på sensorerne, afhænger det af hvor ofte brugeren gør dette Sleep mode XBee-modulerne har en funktion som kan sætte dem i sleep mode. I denne mode er strømforbruget endnu lavere. Vi anvender dog ikke denne funktion i vores system, da vi ønsker at brugeren uafhængigt skal have mulighed for at se de aktuelle målinger på webinterfacet. Side 30 af 51

31 3.7 Energiforbrug for Netduino Plus Vi ønsker at se på energiforbruget for vores Netduino Plus board, og diskutere eventuelle muligheder for at nedbringe dette energiforbrug. Derfor har vi målt Netduino ens strømforbrug. Dette er gjort ved, at der i serie med strømforsyningen monteres en modstand. Derefter måles spændingen over denne modstand, og kan ved hjælp af Ohm s lov finde strømmen gennem systemet. Strømforbruget for Netduino Plus boardet svinger mellem og. Grunden til at strømforbruget svinger, skyldes på samme måde som XBee-modulets strømforbrug, at der sker en underliggende keep alive kommunikation mellem de to XBee-moduler på transmitter og receiver. Det betyder, at i idle mode har Netduino Plus boardet et gennemsnitlig strømforbrug på er. og effektforbruget her Et evt. yderligere strømforbrug afhænger af om der kommunikeres data gennem de to XBee-moduler og om Netduino ens porte er i brug. Man kan evt. reducere effektforbruget på Netduino en ved at afmontere lysdioder. Gøres dette, resulterer det i en reducering i effektforbruget svarende til den afsatte effekt i lysdioderne. Side 31 af 51

32 4. Brugermanual I det følgene afsnit vil vi beskrive hvordan systemet anvendes. 4.1 Webinterface Vores system har et webinterface som gør det muligt at få oplysninger om forskellige ting. Når man er logger ind på hjemmesiden bliver man mødt af følgende skærmbillede: Figur 4.1 Dette er en liste over bookinger der ligger i kø. På Figur 4.1 kan det ses, at der endnu ikke ligger nogle bookinger i kø. For at oprette en booking klikkes der på Booking i menuen øverst til højre. Side 32 af 51

33 Som vist på Figur 4.2 kan det ses, at man her har mulighed for at vælge dato, tidspunkt for start og stop, samt hvilke faciliteter man ønsker der skal starte. Figur 4.2 Hvis man klikker i datofeltet kommer der automatisk en boks op hvor man har mulighed for at vælge hvilken dato man ønsker sin booking. Figur 4.3 Side 33 af 51

34 Systemet er automatisk sat op til at have markeret dags dato. Denne er markeret med gult som vist på Figur 4.3. I dette eksempel har vi valgt at booke systemet til dagen efter. Samme princip gælder når man skal vælge start- og sluttidspunkt for bookingen. Her klikker man også i felterne for henholdsvis start- og sluttidspunkt, og der vil fremkomme en boks som vist på Figur 4.4 og Figur 4.5. Figur 4.4 Figur 4.5 Side 34 af 51

35 Starttidspunktet er prædefineret til kl. 08:00 og sluttidspunktet til kl. 16:00. Dog er det selvfølgelig muligt at vælge andre tidspunkter. Når dato og tidspunkter er valgt, mangler man bare at vælge hvilke faciliteter man ønsker der skal starte når bookingen starter. Som vist på Figur 4.6 har man mulighed for at vælge ventilation, lys, varme og CO2 styring. Figur 4.6 Til sidst mangler man bare at trykke på Create for at oprette bookingen. Herefter er bookingen oprettet og man kan klikke tilbage til forsiden hvor bookingen vil være synlig som vist på Figur 4.7. Figur 4.7 Side 35 af 51

36 En anden feature på webinterfacet er muligheden for at se den aktuelle temperatur. Figur 4.8 Derudover kan man som vist på Figur 4.8 se en graf over temperaturen for de seneste 12 timer. Her har man som vist på Figur 4.9 mulighed for at holde musen over et af punkterne og dermed få vist temperaturen for det angivne tidspunkt. Figur 4.9 Side 36 af 51

37 4.2 SMS alarmer Som en del af systemet har vi implementeret muligheden for at modtage SMS alarmer, hvis der skulle opstå situationer i systemet som kræver administratorens opmærksomhed. Et eksempel på en SMS alarm kunne være hvis batterispændingen på et af de trådløse sensormoduler kommer under den anbefalede minimumsgrænse på 2,1 V. Figur 4.10 På Figur 4.10 ses et eksempel på en SMS alarm hvor batterispændingen er kommet under 2,1 V. Side 37 af 51

38 5. Energioptimering Når systemet kører for venter vi en besparelse på energien. Vi vil i dette afsnit se på hvilke besparelser det vil medføre. Da vi ikke har nogle faktiske målinger og test, er der her tale om estimerede besvarelser ud fra vores faglige vurderinger af forbruget før og efter implementeringen af systemet. Vi har implementeret en mulighed for at booke lokalet til et tidsrum og vi antager at det er denne funktion som vil blive benyttet til hverdag. Vi tænker her, at der kunne være mulighed for at det kunne sammenkøres med informationer om hvornår der er undervisning i de forskellige lokaler. Det betyder at systemet kun er aktivt i de timer der er undervisning og automatisk lukker ned når reservationen er udløbet, hvilket betyder at lys og ventilation ikke kører unødigt. Ser man på belysningsdelen af det, og antager at lyset er tændt omkring 1,5 time ud over den tid hvor der faktisk er behov for lyset, vil det i et klasselokale med 12 armaturer på hver 72 watt betyde en besparelse på: ( ) Dette tal vil dog variere meget fra lokale til lokale, afhængig af folks brugeradfærd. En endelig estimering af besparelsen vil først være muligt at lave hvis anlægget monteres i et lokale som kan benyttes til reference. Herefter vil man så kunne sammenligne energiforbruget for lokalet før og efter systemet er implementeret. Ser man på besparelsen ved at styre ventilationen, er det her endnu mere svært at lave et estimat uden faktiske målinger før og efter. Systemet fungerer ved at spjældene i ventilationskanalerne åbnes og lukkes efter behov. På selve ventilationsanlægget er der monteret en motor som er variabel. Den varierer i forhold til trykket i ventilationskanalerne og drosler op eller ned. Det vil sige, at når der ikke er behov for ventilation i lokalet lukkes spjældene, hvilket betyder at trykket i ventilationskanalen stiger og det vil så resultere i at motoren drosler ned i omdrejninger, og derfor vil benytte mindre energi. På IHK er ventilationsanlæggene store og forsyner adskillige klasseværelser. Det vil derfor her ikke være relevant at snakke om besparelser per lokale da det ikke vil betyde ret meget hvis et lokale lukkes ned. Side 38 af 51

39 5.1 Brug af en tilstedeværelsesensor Vores system er bygget op omkring konceptet med at folk booker et lokale i tidsrum, hvor efter systemet selv lukker ned når reservationen er udløbet. Man kan dog indføre brug af en tilstedeværelsessensor, da vi ser to muligheder for at spare yderligere på energien. Den første mulighed er hvis systemet aktiveres via vægkontakten. I dette tilfælde lukker systemet ikke automatisk ned efter endt undervisning. Det betyder, at hvis systemet ikke bliver deaktiveret gennem kontakten på væggen vil det fortsætte med at køre. Det vil derfor her være smart at installere en tilstedeværelsessensor i vores system, som i dette tilfælde kan registrerer om der er personaktivitet i lokalet og ud fra dette selv lukke systemet ned hvis der ingen personer er til stede i rummet. En anden mulighed kunne være hvis der var foretaget en booking og undervisningen slutter før det angivne tispunkt, og lokalet derfor står ubrugt hen det resterende tid af reservationen. Her ville en tilstedeværelsessensor på samme måde være brugbar for at lukke systemet ned hvis der ingen person aktivitet er. Det er ikke på forhånd muligt at udtale sig om en eventuel besparelse på disse to muligheder, da man ikke ved om folk selv vil slukke systemet ved hjælp af vægkontakten, eller om de bookede tider passer med den tid der er folk til stede i lokalet. 6. Livscyklusanalyse for et XBee-modul 6.1 Formål Da XBee modulet er en komponent der indgår i mange forskellige produkter, så er brug og bortskaffelse forskellig fra situation til situation. Det er derfor her mere relevant at se på livscyklussen fra cradle to gate i stedet for cradle to cradle, da bortskaffelsen af XBee modulet sker sammen med produktet det er installeret i. Da vi kun laver en analyse fra cradle to gate, kan det mere ses som en form for varedeklaration, så forbrugeren kan se hvor mange ressourcer der er blevet brugt til fremstilling af et XBee modul. Side 39 af 51

40 6.2 Funktionel enhed XBee modulets funktionelle enhed består i at gøre det nemmere for forbrugeren at anvende trådløs kommunikation gennem ZigBee protokollen. Modulet har en rækkevidde på op til 40 meter indendørs og op til 120 meter udendørs. 6.3 Målgruppe Målgruppen for XBee modulet, er folk der gerne vil anvende ZigBee protokollen til trådløs kommunikation, men ikke ønsker selv at skulle lodde de integrerede kredse på et PCB 4. Målgruppen for selve livscyklusanalysen er folk der ønsker at lave en varedeklaration for et produkt der indeholder XBee modulet, og derfor benytter denne varedeklaration som et led i den samlede varedeklaration for produktet som indeholder XBee modulet. 6.4 MECO chart Som vi skriver under formål, ser vi kun på XBee modulet fra cradle to gate. Vi har derfor ved hjælp af MECO metoden opgjort ressourceforbrug og ressourceforbruget til fremstilling til at fremstille XBee modulet. Input ressources logic ic PCB/ANT Electronic comp. Unspecified alu kappe pins Total mpr/kg mpr MJ/kg Energy MJ Aluminium 4,88177E-05 kg 0, kg 1,18625E-05 kg 0, kg 0, kg 1,5 0, , Chromium 3,03879E-05 kg 0, kg 7,11604E-06 kg 0, kg 2,3 0, Copper 3,75739E-05 kg 0, kg 2,86158E-05 kg 0, , kg 16,5 0, , Gold 1,52129E-06 kg 0, kg 3,381E-07 kg 3,86339E-06 kg , Iron 0, kg 0, kg 0, kg 0, kg 0,08 0, , Lead 2,2735E-06 kg 5,67182E-06 kg 8,81475E-07 kg 8,8268E-06 kg 80 0, Nickel 7,26747E-05 kg 0, kg 1,75522E-05 kg 0, kg 106 0, , Silver 8,2954E-07 kg 2,76218E-06 kg 1,81511E-06 kg 0, , kg ,80618 Tin 1,03932E-05 kg 8,7675E-06 kg 5,05701E-06 kg 2,42177E-05 kg 90 0,00218 Zink 9,37802E-06 kg 4,6426E-06 kg 2,34738E-06 kg 0, kg 33 0, , Energy renevable 0, MJ 0, MJ 0, MJ 1, MJ Oil, crude 0, kg 0, kg 0, kg 0, kg 41,9 2, Gas natural 0, m3 0, m3 0, m3 0, m3 48,5 3, Coal brown 0, kg 0, kg 0, kg 0, kg 29,5 7, Coal hard 0, kg 0, kg 0, kg 0, kg 29,5 4, Stor version vedlagt som bilag. 4 Printed Circuit Board Side 40 af 51

41 7. Hvad har vi lært? Vi vil i dette afsnit opsummere hvad vi har lært i forbindelse med vores arbejde med projektet. 7.1 Programmering Vi har i projektet valgt at arbejde med et Netduino Plus board i stedet for de udleverede Arduino boards. Dette har gjort, at vi har arbejdet i programmeringssproget C#. Samtidig har vi fået kendskab til.net Micro Frameworket som er det software der kører på Netduino Plus boardet. 7.2 Sensorer I projektet har vi arbejdet med to forskellige analoge sensorer, og har derfor lært at interface dem til en ADC hvor referencespændingen er lavere end forsyningsspændingen. Vi har samtidig arbejdet med at få sensorkredsløbene til at bruge mindst muligt energi ved kun at give strøm til sensoren når der skal samples. 7.3 XBee og ZigBee Vi har i arbejdet med kommunikationsopsætning mellem to XBee-moduler, hvor det ene er en koordinator og det andet en end node. På den måde har vi lært at arbejde med kommunikation mellem disse to moduler, og dermed også arbejdet med ZigBee protokollen. 7.4 Rum indretning Vi har gennem kurset BIHK lært om optimal rumindretning og arbejdsmiljø. I projektet har vi benyttet denne viden til at bestemme hvornår systemet skulle tænde eller slukke for de forskellige enheder. Side 41 af 51

42 8. Konklusion Vi har i projektet udviklet et system som kan styre lys, ventilation og varme i et klasseværelse. Dette system fungerer ved at brugeren gennem et webinterface booker lokalet, hvorefter systemet automatisk regulerer lys, ventilation og varme. Vi har i systemet indbygget forskellige funktioner for at opfylde vores kravspecifikationer. Det er derfor muligt gennem en afbryder på væggen at starte og stoppe systemet uafhængigt af bookinger. Det er ligeledes muligt at slukke og tænde lyset uafhængigt af om systemet er startet eller ej. Via samme webinterface hvor der bookes, er der implementeret forskellige funktioner som gør det muligt for brugeren at se de aktuelle målinger fra vores sensorer, samt grafisk at se målinger fra de seneste 24 timer. En anden implementeret funktion er SMS alarmer. Disse alarmer giver administratoren af systemet informationer via SMS hvis en uønsket situation indtræffer. Vores system er bygget op af et Netduino Plus board som gennem XBee-moduler trådløst kommunikerer via ZigBee-protokollen med vores sensormoduler. Som forsyning til det ene af disse sensormoduler har vi valgt en solcelle. Derfor har vi testet forskellige placeringsmuligheder og fundet at den mest optimale placering for solcellen er så tæt som muligt på den nye type loftarmatur der er opsat forskellige steder på skolen. Vi har samtidig set på hvilke besparelser en implementering af vores system ville medbringe, og vi forventer her alene på belysningssiden en besparelse på pr. lokale pr. dag. Ud over disse ting har vi som krav specificeret at der skulle være mulighed for at monitorere lokalets CO2-niveau. Dog har vi pga. manglede tid ikke haft mulighed for at implementere dette i vores system. Ser vi bort fra den manglende implementering af CO2-sensoren, kan vi konkludere at projektet, igennem tæt samarbejde mellem gruppens to medlemmer, er gennemført med et resultat der tilsvarer de opstillede krav. Side 42 af 51

43 9. Refleksion over SUSIE kurset Vi har været meget glade for at deltage i kurset, og synes det har været utrolig interessant at anvende XBee-modulerne til at kommunikere trådløst. I starten følte vi det dog lige uoverskueligt da der var en masse forskellige udviklingsboard samt shields til disse. Dette var blandt andet én af grundene til at vi valgte at anskaffe os et Netduino Plus board, da der i undervisningen blev lagt op til at ens board skulle have forbindelse til internettet. Vi valgte derfor dette board, da det er en del nemmere at få internetforbindelsen op og køre på Netduino boardet frem for et Arduino board, da der i Netduino boardet er indbygget Ethernet forbindelse. Vi foreslår derfor, at man i fremtiden overvejer at benytte disse boards til undervisningen, da vi har været utrolig glade for dette board. Derudover er vi glade for at kurset indeholdte en masse om bæredygtighed. Dette har vi været glade for at lære om i forhold til elektronik og dermed forsøge at minimere strømforbruget på de forskellige enheder. Derimod synes vi ikke at undervisningen i LCA har haft en naturlig sammenhæng med resten af indholdet i kurset, da elektronikken oftest indgår i en større sammenhæng med resten af produktet. Vi har i det store hele være meget tilfredse med at der har været dette valgfag hvor vi har kunne arbejde med embedded programmering, digital elektronik og optimering af denne. Side 43 af 51

44 10. Litteraturfortegnelse 10.1 Bøger Building Wireless Sensor Networks Af Robert Faludi O Reilly Første udgave Hjemmesider Side 44 af 51

45 11. Bilag 11.1 Projektoplæg Project in sustainable electronic and it Chose a problem domain for which it s relevant to monitor and/or control environmental data In the design there must be an autonomous node using a ZigBEE protocol in the XBEE module which communicate with a microcontroller. Autonomous means that there the XBEE node must only be supplied by natural energy. Consider the need for energy how much time can it sleep or be idle and how much time does it really need sampling data. The other nodes can be battery operated find out how long the battery will last for a given use-case The XBee nodes communicate with a microcontroller containing the ZigBee coordinator and which also must have access to the internet. The microcontroller should act as a client, which can forward the data through the LAN to either using the web-service on cosm.com or thingspeak.com or another web server with a database and a graphical presentation of the measured data. If you wish to control some actuators/devices this can be done trough an embedded server in the microcontroller or from the server by a GET request from the embedded client to the web service cosm.com which then controls the actuator/devices An Analysis of the energy consumption for the whole system should be done using data sheets and practical measurements in the different states of uses. The project should evaluate the system or at least one subsystems environmental impact using a LCA analysis as you got introduced through the lecture. The Project is documented in a report and on a poster for the last school day event in the hall and for exam presentation. A running demo for the last school day event The documentation should at least contain: -documentation for the communication chain from Xbee modules to the cosm.com server or alternative. Different protocols used should be documented. -documentation for the program in the microcontroller. -an analysis of the energy consumption for all parts in the communication chain and a discussion for how to minimize it. The solution/the practical implementation should strive for the minimum consumption seen in relation to the chosen problem domain. Alternative solutions and/or an optimal hardware/soft ware plat form can be discussed. -a documentation for how a Xbee end node can be powered or is powered through environmental energy source -an LCA analysis on a part of the system -a reflection over the SUSIE class what can be improved The Project must be done in groups of student Ole Schultz Side 45 af 51

46 11.2 Solcellemålinger Gammelt loftarmatur Current [A] Voltage [V] Power [W] Load [Ω] 5,31815E-05 5,909 0, , ,894 0, , ,77 0, , ,613 0, , ,52 0, , ,337 0, , ,944 0, , ,067 0, , ,2031 0, , ,0055 0, , ,804 0, , ,606 0, , ,405 0, , ,2097 0, , ,008 0, ,0202 0,808 0, , ,607 0, , ,4053 0, ,0204 0,204 0, , ,185 0, , ,163 0, , ,143 0, , ,124 0, ,0206 0,103 0, , ,083 0, , ,062 0, ,0245 0,049 0, ,022 0,022 0, Side 46 af 51

47 Nyt loftarmatur Current [A] Voltage [V] Power [W] Load [Ω] 5,71686E-05 6,352 0, , ,337 0, , ,277 0, , ,218 0, , ,188 0, , ,143 0, , ,063 0, , ,84 0, , ,642 0, , ,305 0, , ,976 0, , ,649 0, , ,32 0, , ,99 0, , ,659 0, ,0332 1,328 0, , ,997 0, ,0333 0,666 0, ,0334 0,334 0, , ,3 0,01 9 0, ,266 0, , ,233 0, , ,2 0, ,0332 0,166 0, , ,133 0, , ,1 0, ,0335 0,067 0, ,033 0,033 0, Side 47 af 51

48 På bordet Current [A] Voltage [V] Power [W] Load [Ω] 4,02934E-05 4,477 0, , ,012 0, , ,779 0, , ,431 0, , ,36 0, , ,29 0, , ,219 0, , ,149 0, , ,078 5,53091E ,0007 0,07 0, ,0007 0,063 0, ,0007 0,056 0, ,0007 0,049 0, ,0007 0,042 0, ,0007 0,035 0, ,0007 0,028 0, ,0007 0,021 0, ,0007 0,014 0, ,0007 0,007 0, , ,006 0, , ,005 0, ,0007 0,0049 0, ,0007 0,0042 0, ,0007 0,0035 0, ,0007 0,0028 0, ,0007 0,0021 0, , ,0015 0, ,0007 0,0007 0, Side 48 af 51

49 I vindueskarmen Current [A] Voltage [V] Power [W] Load [Ω] 4,45054E-05 4,945 0, , ,768 0, , ,797 0, , ,0075 0, , ,838 0, , ,6683 0, , ,5057 0, , ,339 0, ,0016 0,176 0, , ,158 0, , ,143 0, ,0016 0,128 0, ,0016 0,112 0, ,0016 0,096 0, ,0016 0,08 0, ,0016 0,064 0, ,0016 0,048 0, ,0016 0,032 0, ,0016 0,016 0, , ,015 0, , ,014 0, , ,012 2,05714E , ,01 1,66667E ,0016 0,008 0, ,0015 0,006 0, ,0016 0,0048 0, ,0016 0,0032 0, ,0017 0,0017 0, Side 49 af 51

50 11.3 Komponentliste Sensormodul Komponentliste Type Antal Model/værdi Reference XBee 1 XBee series 2 U1 Molex 1 2 polet han CON2 Modstand 2 15k Ω R4, R7 Modstand 2 10k Ω R2, R3 Modstand Ω R5, R6 Diode 2 Lys Diode D1, D2 NTC 1 10k Ω NTC NTC LDR 1 10k Ω LDR LRD Interfaceboard Komponentliste Type Antal Model/værdi Reference Kondensator nf C1, C2 Spændingsregulator 1 LM7805 U6 Spændingsregulator 1 LE33 U7 Diode 5 1N4001 D1, D2, D3, D4, D5 USB 5 USB A U1, U2, U3, U4, U5 10P Connector 1 10 polet han J1 Forsygning 1 12 VDC J2 Klemmerække 1 3 Polet J3 Transistor 5 BD441 Q1, Q2, Q3, Q4, Q5 Modstand 5 20 Ω R1, R2, R3, R4, R5 Modstand 5 2 kω R6, R7, R8, R9, R10 Modstand 2 10 kω R11, R12 Side 50 af 51

51 11.4 MECO chart Side 51 af 51