Projekt nr Side 2 af 55

Transkript

1

2 Side 2 af 55

3 1 Godkendelsesformular Ved underskrivelse af dette dokument, bekræftes aflevering af projektrapporten. Ligeledes tilkendegives det, at projektdeltageren ønsker denne rapport bedømt ved eksamen. Sted og dato: Ingeniørhøjskolen i Århus, den: Deltager underskrift: Stefan Lykkehøj Lund Side 3 af 55

4 Side 4 af 55

5 2 Resumé Denne rapport beskriver det undersøgelsesprojekt, som Stefan Lykkehøj Lund udførte som afgangsprojekt på elektrolinien ved Ingeniørhøjskolen i Århus. Formålet med projektet, er at udvikle et system, der gør en i stand til at fjernstyre Zigbee enheder med en Android Smartphone. Der skrives "åbne og lukke et vindue og en dør", for at gøre projektet mere jordnært og håndgribeligt. Systemet udvikles iterativt og med en objektorienteret tilgang. Således var systemet ikke færdigspecificeret fra starten, men udvikledes fra iteration til iteration. Der blev taget udgangspunkt i en modificeret form for 'Scrum' til projektstyringen. Modificeret da Scrum normalt kræver en gruppe. I første omgang blev der lavet en grundlæggende arkitektur for systemet. En struktur der har dannet grundlag for systemudviklingen. Da tilgangen skulle være objektorienteret, besluttedes det at dele systemet op i delmoduler, som kunne udvikles selvstændigt. Til hvert modul har der derfor været en analyse-, implementations og test fase. Forud for konstruktionen blev anselige tidsressourcer brugt til analyse af de ønskede trådløse teknologier og ikke mindst til at finde ud af hvordan disse bruges. De brugte trådløse teknologier er: Bluetooth, GSM og Zigbee. Skitser blev til diagrammer, diagrammer til print. Ideer til styring af microcontrollere blev til færdig firmware. Analysen af teknologierne førte til drivere. Tegninger af brugerinterface blev til et enkelt og elegant brugerinterface. Modulerne blev testet hver for sig. Modulerne blev sat sammen og testet igen. Til sidst fulgte slut/accepttesten, der har til formål at teste det samlede system. Således udvikledes systemet sig fra at være en idé på tegnebrættet, til at være et fuldt funktionelt system. Side 5 af 55

6 Side 6 af 55

7 3 Abstract This report describes the research project, which Stefan Lykkehøj Lund performed as Final Project in the Electronic department at the Engineering College of Aarhus. The ain of the project is to develop a system that makes one able to remotely control Zigbee devices using an Android Smartphone. The words "open and close a door and a window" are used to make the project more down to earth and tangible. The system is developed iteratively and with an object oriented approach. Thus the system was not completely specified from the beginning but has evolved from iteration to iteration. A modified version of 'Scrum' has been used for project management. Modified since Scrum usually requires to be performed in a group. At first a basic system architecture sketch was made. A structure that has formed the basis for this system's evolution. Since the project should be object oriented it was decied to divide the system into sub-modules that could be developed independently. For each module, there has been an analytical, implementations and testing phase. Before construction, considerable time resources was used for the analysis of the desired wireless technologies to be used, among others to find out how they are used. The used wireless technologies are: Bluetooth, GSM and Zigbee. Sketches became schematics, schetcheds became prints. Ideas for controlling the microcontrollers became firmware. The analysis of technologies lead to drivers. Drawings of the User Interface became a fully functional User Interface, elegant and intuitive. The modules were tested separately. The modules were put together and tested again. At last came the final "Acceptance test", designed to test the overall system. Thus evolved the system from a stray idea to a fully functional system. Side 7 af 55

8 Side 8 af 55

9 4 Indholdsfortegnelse 1 Godkendelsesformular Resumé Abstract Indholdsfortegnelse...9 Figuroversigt...11 Forord Indledning Formål med projekt Læsevejledning Ordliste Projektbeskrivelse Projektfgrænsning Projektgennemførelse Metoder Scrum: V-modellen: Analysearbejde Designarbejdet Modul 1 Motherboard Modul 2 - GSM Modul 3 Bluetooth Modul 4 - Smartphone Modul 5 - XBee Main Modul 6 - XBee Window Modul 7 - XBee Door Udviklingsværktøjer Hardware Software Resultater Resultat af test Bluetooth forbindelse Resultater i Bluetooth Mode Resultater i GSM Mode Anden funktionalitet Diskussion af opnåede resultater Resultat af test Bluetooth forbindelse Resultat i Bluetooth Mode Resultat i GSM Mode Anden funktionalitet WCS i forhold til andre systemer Opnåede erfaringer Projektets fortræffeligheder Forslag til forbedringer Side 9 af 55

10 7 Konklusion Litteraturliste Bilag Bilag A: Tidsplan Bilag B: Firmware diagrammer Modul 1 - Motherboard Modul 2 - GSM Modul 3 - Bluetooth Modul 4 - Smartphone (Async tråd) Modul 5 - XBee Main Modul 6 - XBee Window Modul 7 - XBee Door Side 10 af 55

11 Figuroversigt Illustration 1: Visuelt Overblik over det konstruerede system...14 Illustration 2: Billede af 'Backlog'-tavlen: "ToDo", "In Progress", "Done"...18 Illustration 3: En typisk udgave af V-modellen...19 Illustration 4: WCS's overordnede arkitektur...23 Illustration 5: Modul 4 - Smartphone, GUI...25 Illustration 6: RS232 kommunikations sniffer...29 Illustration 7: USBASP In System Programmer...29 Illustration 8: XBee Development Kit...30 Illustration 9: Atmel STK500 Development Kit...30 Illustration 10: GUI i bluetooth mode...33 Illustration 11: GUI i GSM mode...33 Illustration 12: Knaptryk i bluetooth mode...34 Illustration 13: Grøn diode lyser...34 Illustration 14: Rød diode lyser...34 Illustration 15: Knaptryk i GSM mode...35 Illustration 16: Grøn diode lyser...35 Illustration 17: Rød diode lyser...35 Illustration 18: Projektets tidsplan...48 Illustration 19: Modul 1 - Motherboard, firmware aktiviteter...49 Illustration 20: Modul 2 - GSM, firmware aktiviteter...50 Illustration 21: Modul 3 - Bluetooth, firmware aktiviteter...51 Illustration 22: Modul 4 - Smartphone, Async Task aktiviteter...52 Illustration 23: Modul 5 - XBee Main, firmware aktiviteter...53 Illustration 24: Modul 6 - XBee Window, firmware aktiviteter...54 Illustration 25: Modul 7 - XBee Doors, firmware aktiviteter...55 Side 11 af 55

12 Side 12 af 55

13 5 Forord Dette afgangsprojekt, omhandler analyse, design og udviklingen af et system til fjernstyring af en dør og et vindue. Baggrunden for projektet er ønsket om at udvikle et system der i sidste ende kan gøre livet lettere for mennesker. Dette kan være handicappede der ikke er i stand til på traditionel vis at kunne åbne et vindue, eller en gigtplaget mand der ikke behøver at rejse sig op for at åbne døren. Jeg vil gerne takke Jesper Rosholm Tørresø for kyndige råd og god vejledning i forbindelse med projektforløbet. Yderligere vil jeg takke Stefan Wagner for inspiration til at udvikle et produkt med basis i det elegante og intuitive. Til sidst vil jeg gerne takke Ingeniørhøjskolen i Århus for at give mig rammerne til at kunne lave dette projekt. Side 13 af 55

14 Side 14 af 55

15 6 Indledning Som afgangsprojekt på elektrolinien i Ingeniørhøjskolen i Århus valgte jeg, Stefan Lykkehøj Lund, at arbejde med udviklingen af et generisk framework der kan fjernstyres vha. en Android Smartphone. For at gøre 'generisk framework' mindre flyvsk tages der udgangspunkt i, at de fjernstyrede objekter er et vindue og en dør. Dog er det kun fantasien der sætter grænsen for hvad systemet kan bruges til hvis det tilpasses andre behov: En handicappet der ikke selv er i stand til at åbne sine døre og vinduer. Sætte varme på i sommerhuset før man ankommer. Sørge for at døren låser og alarmen sluttes til, hvis man glemte det inden man tog hjemmefra. Det var vigtigt for mig, at systemet ville tage afsæt i noget som mange er i besiddelse af, nemlig en smartphone. Det er min opfattelse at man ikke bør have en fjernbetjening til hver funktion i sit hus: TV, stereoanlæg, home automation osv. derfor udvikles systemet på en Android Smartphone. Projektet er især interessant, da det det forener elektronik og IT. Projektet spænder vidt og inkluderere flere forskellige abstraktionsniveauer. Et spænd helt fra brugen af elektriske komponenter, elektronikkens grundsten til højniveau GUI's på Android'en. Projektet gik godt i tråd med min (Stefan Lykkehøj Lund, undertegnede) kommende specialisering: "Elektroingeniør med speciale i indlejrede systemer". Projektet meget af den viden jeg har tilegnet mig i løbet af studiet, specielt i specialiseringsdelen. Ud over de indlejrede aspekter af projektet, lå det mig også på sinde at arbejde med trådløse teknologier. Derfor blev de tre trådløse teknologier: Zigbee, Bluetooth og GSM inddraget i projektet. Projektet søger at afklare om et sådan system i det hele taget kan konstrueres. Systemet kan ydermere sammenlignes med eksisterende produkter på markedet. Til udviklingen af systemet benyttes følgende udviklingsmetoder: SCRUM og V-Modellen. Da det er min vurdering at disse vil passe bedst til denne type projekt. Illustration 1: Visuelt Overblik over det konstruerede system. Side 15 af 55

16 6.1 Formål med projekt Formålet med projektet at udvikle en funktionsmodel. Kort fortalt skal funktionsmodellen bestå af en Android telefon med en GUI. Denne Android telefon skal kunne 'styre' et XBee objekt. Android telefonen kan ikke umiddelbart styre XBee. Derfor må man benytte sig af de trådløse teknologier telefonen har, nemlig: Bluetooth og GSM. Et hovedmodul skal konstrueres, der kan omsætte Bluetooth og GSM til XBee og således tillade Android telefonen at kontrollere XBee objekter. Dette vil samtidig give en klar fordel over bluetooth, da et XBee netværk kan indeholde langt flere devices end et Bluetooth netværk (op til 64000) [5]. Projektet spænder således over mange discipliner. Der skal programmeres Android, der skal designes firmware til mikrocontrollere samt designes, udlægges og monteres print. Hertil kommer at der skal tilegnes en hel del viden om de pågældende trådløse teknologier Bluetooth, GSM og Zigbee (XBee). For hurtigt overblik over projektets slutprodukt anbefales vedlagte projektvideo ("WinDoorCS.wmv"), der findes på CD'en 6.2 Læsevejledning ens bestandele er angivet nedenfor. I store træk kan det siges at rapporten består af to hoveddele: Projektbeskrivelsen og evalueringen. Projektbeskrivelsen består af: Analysefasen Designfasen Testfasen Evalueringen består af: Resultater Diskussion af resultater Opnåede erfaringer Projektets fortræffeligheder Forslag til forbedringer. Systemets fremtid. Konklusion Efter hovedafsnittene følger litteraturliste og bilag. Såfremt der refereres til litteraturlisten, gøres dette med følgende indikation: [Litteraturliste nr.] (eks. [3]). Side 16 af 55

17 6.2.1 Ordliste Ordliste: Beskrivelse: Gnd Ground (stel / referencepunkt) HW Hardware ISP In System Programming LM058 Bluetooth SPP device MISO Master In Slave Out MOSI Master Out Slave In SCK SPI clock SPI Serial Peripheral Interface (Seriel data bus) STK500 Atmel STK500 Development Kit SW Software TC35i GSM Terminal WCS UART Universal Asynchronous Receiver/Transmitter uc MicroController API Application Programming Interface XBee Digi XB24-B Zigbee Module Side 17 af 55

18 7 Projektbeskrivelse Projektet kaldes '' (WCS). Det skal dog understreges at systemet er et 'generisk framework' til fjernstyring af objekter vha. en Android Smartphone. Systemet kan således i princippet bruges til mange andre ting. Kort forklaret er systemet i bund og grund i stand til følgende: En Android telefon der kan kontrollere en mikrocontroller på den anden side af et system via GSM, Bluetooth og XBee. Men igen, lad os for forståelsens skyld antage at det er en dør og et vindue vi fjernstyrer. 7.1 Projektfgrænsning Det blev besluttet, at systemet ikke skulle indeholde et væld af funktioner. Men i stedet fokusere på det essentielle og vigtige i dette projekt: Hvis projektet kom op at køre, så ville det primære fokus være på brugerglæden ved systemet, følelsen af intuition og følelsen af at systemet er afbalanceret og gennemtænkt. Dermed findes der i systemet kun funktioner som 'tænd' og 'sluk' for hhv. dør og vindue. Der er dog tilføjet en 'sluk for GSM' funktion, for at forhindre brugen af GSM hvis dette ikke er tilsigtet. Det har heller ikke været prioriteret højt at få systemet bygget ind i en flot kasse, da systemet blot er en funktionsmodel. 7.2 Projektgennemførelse Da projektet kun har været udført af én person, har der ikke været brug for megen intern kommunikation. Det har dog alligevel været meget vigtigt for mig, at have struktur igennem projektforløbet, også i forbindelse med vejledning og sparring. Projektet er blevet udført 'iterativt' men ikke i traditionel forståelse. Meget tidligt i forløbet blev det valgt at splitte systemet op i syv moduler, dette forsvares i designafsnittet. Disse moduler er hver især blevet udviklet iterativt, baseret på principperne i 'Scrum'. Princippet i Scrum er blandt andet, at man efter hver iteration har et funktionsdygtigt produkt. Dette produkt kan så videreudvikles i de følgende iterationer. Det vil sige, at man bygger videre på noget som virker. Dette princip er også beskrevet i: "Object Mentor's First Law of Agile Development" A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. Systemantics: How Systems Really Work and How They Fail, 2d. ed., J. Gall, The General Systemantics Press, 1986, p. 65 De syv moduler er til sidst sat sammen til det samlede system. Undervejs har der været foretaget deltests af systemet og til sidst en accepttest, der har til formål at holde systemet op imod kravspecifikationen. Side 18 af 55

19 7.3 Metoder Dette afsnit beskriver hvilke metoder og arbejdsmodeller, der er benyttet under udarbejdelsen af dette projekt. Hver metode og model er beskrevet nedenfor, hvad metoderne indebærer og hvad de er blevet brugt til i projektet. Til projektet er benyttet elementer fra: SCRUM og V-modellen, i mere eller mindre modificeret form. Hver model beskrives i de følgende underafsnit, hvad de indebærer og hvordan de er brugt i projektet Scrum: SCRUM er en metode der bruges til projektledelse. SCRUM bruges normalvis til softwareudvikling, men kan også med fordel bruges i kombinerede projekter som dette, hvor både HW, SW og Firmware skal udvikles. SCRUM indbyder til at mødes ofte, for kort at fortælle hvordan man kommer hen til næste delmål og tilkendegive eventuelle problemer. Når man mødes ofte, behøver møderne ikke være særligt lange, minutter. Et andet vigtigt SCRUM-element er tidsprioriteringsmodellen kaldet 'Backlog'. Backlog kan være en tavle med "POST-ITs" med små opgaver der skal udføres i projektet. Alt efter vigtigheden af opgaven hænger den højere på tavlen. Ved hver opgave kan der laves et tidsestimat. Disse tidsestimater kan regnes sammen og give en mulig ca. afleveringsdato. For hver gang en opgave er udført kan tidsestimatet korrigeres for større præcision. Slutteligt er et af nøgleelementerne i SCRUM "Sprints". Sprints er små forløb, hvor hvert forløb skal ende med et delmål (evt. en fungerende funktionsmodel, som udbygges ved senere sprints). Dette er kort fortalt om SCRUM. Der henvises i øvrigt til bogen "Applying UML and Patterns" [3]. Scrum i projektet: I SCRUM forudsættes det normalvis, at der arbejdes i grupper. Da jeg har været alene om projektet, er det derfor en modificeret udgave af SCRUM jeg har benyttet. De SCRUM møder der har været, har været med vejlederen. Det vigtigste element der er benyttet i projektet, er en simplificeret udgave af backloggen. Forskellen fra en traditionel backlog og denne projekts, er at der ikke har været angivet nogen sprints. Derimod har det fungeret som en prioriteret 'todo' liste, med prioritering af opgaver, samt hvilke opgaver der er færdiggjort og hvilke der er igang. Illustration 2: Billede af 'Backlog'-tavlen: "ToDo", "In Progress", "Done" V-modellen: V-Modellen er den udviklingsmodel der benyttes på elektrolinien. Som det ses på Illustration 3 findes Side 19 af 55

20 analyse og design på venstre side af modellen, implementering i midten og tests på højre side. Hvert af punkterne på venstre side af modellen matcher et punkt på højre side. Dvs. kravsdefinitionerne fører til en sluttest (accepttest). Overordnet design fører til en integrationstest osv. Illustration 3: En typisk udgave af V-modellen De forskellige faser af modellen forklaret: Fase 1: Udfærdigelse af foranalyse og sluttest specifikation Fasen indeholder en undersøgelse af alle delene af projektet. Hvad systemet skal kunne. Hertil hører en testspecifikation, der tester de krav der er blevet sat op i projektet. Kort sagt, systemets overordnede funktionalitet og tests der tester disse funktionalitet. Fase 2: Udfærdigelse af overordnet design og integrationstest specifikation I denne fase designes arkitekturen af systemet. Den overordnede funktionalitet er nu fastlagt, nu skal det bestemmes hvordan vi kommer derhen. Her kan det være passende at splitte et projekt op i moduler. Denne fase følges af en integrationstest specifikation. Denne beskriver tests man kan udføre på sammensatte moduler. Fase 3: Udfærdigelse af enhedsdesign og enhedstest specifikation (modul-design) Hvert enkelt modul designes. Dette følges af en testspecifikation, der har til hensigt at teste modulerne hver for sig. Fase 4: Implementering Implementeringsdelen er den fase hvor det hele konstrueres. De designs der er fremstillet skal overføres til praksis i denne fase. Fase 5: Test I denne fase skal alle de tests der er skrevet udføres. Denne fase afsluttes med en accepttest / sluttest, der søger at bekræfte om den fra starten ønskede funktionalitet er til stede. V-Modellen i projektet: V-modellen er brugt som udgangspunkt i dette projekt. En vigtig forskel er dog, at projektet har fulgt en iterativ udviklingsmodel. Een iteration svarer således til en tur rundt på V-modellen. Når man er kommet hele vejen rundt, starter man forfra. For hver iteration vil der derfor være et produkt, som kan videreudvikles i de næste iterationer. Dokumenterne tilsvarende iterativt. Side 20 af 55

21 7.4 Analysearbejde Forud for designfasen gik et grundigt analysearbejde. Analysearbejdet bestod især i undersøgelsen af de trådløse teknologier: Bluetooth XBee GSM Der skulle oparbejdes et stort kendskab til dem, da de var en essentiel del af produktet. Kendskab til hvordan de kommunikerer og hvordan man interfacer med dem. Denne viden skulle benyttes, når teknologierne skulle kontrolleres af mikrocontrollere. Der blev udarbejdet skitser til drivere, baseret på observationer under forsøgsopstillinger. Efter grundig forberedelse blev teknologierne i første omgang testet via PC'ens terminal. Når der var opsamlet en god del information blev teknologierne testet sammen med mikrocontrollere. I denne fase var RS232 Communication Spy uundværlig. Problemer med at 'se' informationsstrømmen, mellem teknologierne og mikrocontrolleren, førte til udviklingen af denne 'sniffer'. Snifferen viste sig så effektiv, at den hurtigt blev en del af udviklingsmiljøet omkring projektet. Efter oparbejdelsen af et kendskab til disse teknologier, skulle der laves et udkast til en samlet systemarkitektur. Overvejelserne gik i hovedtræk ud på, hvorvidt systemet skulle bestå af 'et stort print' eller om funktionaliteten skulle fordeles på mindre moduler. Det blev besluttet at bryde projektet ned i mindre moduler. Det vurderedes at fordelene ville være større end ulemperne. Illustration 4 viser den færdige system-arkitektur. Opdelingen førte til syv moduler. Smartphonen er et modul for sig. De perifere enheder skulle også være selvstændige moduler (et modul = vindue og et modul = dør). De sidste fire moduler findes i hovedmodulet. Et modul til hver trådløs teknologi, samt et modul til at lede og fordele arbejdet, samt forsyne tilknyttede moduler med spænding. Nedenfor beskrives hvert modul kort. 1. Modul 1 Motherboard Et modul der modtager, evaluerer og formidler systemets information. Samtidig et modul der forsynger de tilstødende moduler med spænding. 2. Modul 2 GSM Hver trådløs teknologi har fået hver deres modul. Begrundelsen er at hver modul således kun skal holde styr på een teknologi. Teknologien kan afprøves for hvert modul, uden at indgå i en kompleks sammenhæng. 3. Modul 3 Bluetooth Det samme gælder bluetoothmodulet, hver trådløs teknologi har sit eget modul. 4. Modul 4 - Android telefon Android modulet er naturligt adskilt fra resten af systemet. Udviklingen af Android modulet, er samtidig væsentligt anderledes end de resterende moduler. 5. Modul 5 - XBee Main Samme begrundelse som for GSM- og Bluetooth-modulerne. 6. Modul 6 - XBee Window XBee Window og XBee Door er begge to selvstændige moduler. Det er disse moduler der skal fjernstyres, og vil af den grund naturligt være adskilt fra de resterende moduler. 7. Modul 7 - XBee Door Side 21 af 55

22 Samme begrundelse som XBee Window Udover at kunne udvikle modulerne seperat, er tanken med de syv moduler ovenfor, er muligheden for, eksempeltvis, at kunne benytte en anden GSM-terminal. Man kan udskifte GSM-modulet, bare det overholder den interne protokol i systemet. På den måde undgåes re-design af hele systemet. Bluetooth-modulet ville også kunne byttes ud med et wifi-modul, igen skal det nye modul blot overholde grænseflader og protokol. Ud over at det er smart at adskille moduler grundet lettere udskiftning af moduler, gøres arbejdet lettere og mere objektorienteret. Nu kan hvert modul designes individuelt. Den opdelte model gør samtidig debugging af systemet lettere, da hvert modul kan testes seperat. Men opsplitningen er ikke uden omkostninger: Kompleksiteten af systemet øges. Der kræves en ekstra microcontroller pr. nyt modul. Firmware skal programmeres til hvert enkelt modul. Kommunikationen i systemet kompliceres yderligere, jo flere moduler der skal tale sammen. Ikke alene skal hardwaren passe sammen, firmwaren skal også fungere på tværs af grænseflader. Det blev bestemt at systemet skulle fungere på følgende måde: Når der trykkes på en knap på telefonen, skal telefon enten sende information med bluetooth eller GSM (SMS). Det skal afgøres om telefonen er inden for bluetooth afstand, ellers benyttes GSM. Informationen modtages af Modul 2 - GSM eller Modul 3 - Bluetooth. Modulet validerer informationen og sender den videre til Motherboardet. Motherboardet sørger for at sende informationen videre til Modul 5 XBee_Main, der vil broadcaste informationen med Zigbee. Modul 6 - XBee_Window og Modul 7 XBee_Door kan begge 'høre' den information. Disse kan hver især afgøre om de skal reagere på informationen eller ej (åbne eller lukke vindue eller dør). I første omgang blev det besluttet, at systemet skulle give mulighed, for at få en status fra systemet. Således skulle systemet kunne give svar på, hvorvidt dør og vindue var åbne eller lukkede. Dette blev dog fravalgt i implementeringsfasen. Det var næsten indarbejdet, men ideen blev alligevel forkastet, da det ville kræve for meget tid. 7.5 Designarbejdet I designarbejdets første fase skulle systemets arkitektur fastlægges. Designprocessen er lavet som en iterativ proces, dette betyder at designbeslutningerne er resultat af flere design- og implementeringsforløb. Dog blev den overordnede arkitektur fastlagt i starten. Systemarkitekturen ses på Illustration 4. Hvert modul, med undtagelse af modul 4 - Smartphone består af følgende: Hardware Firmware Grænseflade Modulernes HW har det tilfælles, at alle er bygget op omkring en Atmel Mega16 mikro-controller. For at få Mega16 til at fungere, skulle der designes et svingningskredsløb, samt designes en strømforsyning til at Side 22 af 55

23 forsyne printet med den korrekte spænding. For understøttelse af programmering af Firmware direkte på hvert modul, blev der indarbejdet et ISP-programmerings-interface. Denne model har dannet grundsten for hardwaren i modulerne. Mega16 blev valgt, da denne er blevet brugt tidligere på studiet, samt at den opfylder kravene til funktionalitet. Kravene er at den skal være i stand til at drive en UART, kunne benytte SPI som kommunikationsform samt kunne interrupte. Valget af mikrocontroller har således haft stor indflydelse udformningen af hardwaren. Ingen af modulerne er dog ens. Hver især skulle de tilpasses hver deres specialisering. Under beskrivelsen af hvert modul, vil det fremgå hvilke specialiseringer de har. Udover de enkelte modulers funktionalitet, var det også vigtigt at få defineret en helt tydelig grænseflade imellem modulerne. Grænsefladebeskrivelsen gør at modulerne passer sammen som et puslespil. Passer 'brikkerne' ikke sammen fungerer systemet simpelt hen ikke. Modulernes Firmware har også en del til fælles. De er alle designet efter denne skabelon: Definitioner Definitioner øger læsbarheden af koden Interrupt Service Routiner (ISR) En funktion der afvikles, når et givent interrupt finder sted. Hjælpefunktioner Funktioner som den pågældende firmware har brug for. Main IO-PINs konfigureres. Hvad er ind- og udgange på systemet. Evt. initialisering af teknologi. F.eks. GSM, Bluetooth eller XBee Superloop (vedvarende opgave) Karakteristisk for microcontrollere. Et vedvarende loop, der sørger for at microcontrolleren ikke stopper med at afvikle kode. Det er her GSM- og bluetooth- modulerne tjekker efter og videregiver information. Det er her motherboardets passive token ring styres. Hertil hører en driver hvis modulet indeholder en XBee-, Bluetooth- eller GSM-enhed. Side 23 af 55

24 Illustration 4: WCS's overordnede arkitektur Modul 4 - Smartphone har ikke noget til fælles, designmæssigt, ift. de andre moduler og beskrives derfor under modulbeskrivelsen nedenfor. Følgende modulbeskrivelse forklarer de enkelte moduler. Hvilket ansvar de har, hvad de består af samt deres plads i det samlede system Modul 1 Motherboard Ansvar: Motherboardet fungerer som 'spilfordeler'. Den trækker information ud af GSM- og Bluetooth-modulet skiftevis. Er informationen relevant, videregives den til XBee-modulet. Dette kalder jeg "Passive Token Ring Configuration". 'Token Ring' da modulerne skiftevis får 'lov' til at sige noget. 'Passiv' da informationen skal trækkes ud af dem. Grunden til at informationen skal trækkes ud er, at Motherboardets uc fungere som SPIMaster. Masteren initierer dataoverførsel. SPI er den kommunikationsform der benyttes mellem modulerne inde i hovedmodulet. Dette fremgår af Illustration 4. Motherboardet skal desuden benyttes til debugging af systemet. Dette gøres ved at udlæsning af informationer på debugdioderne. Firmware: Skal implementere den overordnede funktionaliteten, der illustreres på aktivitetsdiagrammet på Illustration 19 Hardware: Motherboardets specialiserede HW består af: 8 debugdioder Side 24 af 55

25 Det blev vurderet, at det ville være fordelagtigt med muligheden for at udlæse værdier på dioder. Grunden til debugdioderne sidder på motherboardet, er at det er forbundet til tre andre moduler, og kan indgå i et fælles debuggingforløb. SPI-forbindelser til GSM-, Bluetooth- og XBee_Main modulerne. Forbindelser der skal bruges til kommunikation internt i main modulet. Distribuerer spænding til tilstødende moduler (12-15 Volt). For at centralisere spændingsforsyningen. Så de tilstødende moduler ikke også skal have spænding fra en adapter. Klarmeldingsforbindelser, så tilstødende moduler kan melde sig klar til Motherboardets uc DC-Plug til forsyning fra lysnettet gennem adapter Modul 2 - GSM Ansvar: GSM modulets funktion er først at initialisere GSM terminalen. Dernæst at tjekke for modtagne beskeder (via SMS fra Android telefonen). Hver ny SMS gennemsøges for information. Findes der relevant information, videresendes denne via SPI til Motherboardet. GSM Modulets uc fungerer som SPI slave. Firmware: Skal implementere den overordnede funktionaliteten der illustreres på aktivitetsdiagrammet på Illustration 20 Driver: Bruges til konfiguration af TC35i. Driveren sætter PIN-kode, læser SMS'er, sender SMS'er osv. Kommunikationen med TC35i foregår med "AT-kommandoer". I driveren er programmeret 'mikro'funktioner. Simple kommandoer, der kan sammesættes til mere komplekse 'makro-funktioner'. Virker funktionerne i det små, virker de også i det store. Initialiseringen af TC35i er et eksempel på en makrofunktion. TC35i skal initialiseres hver gang systemet startes, da systemet 'glemmer' oplysninger når det slukkes. Hardware: GSM-modulets specialiserede HW består af: RS232 kredsløb til understøttelse af kommunikation med TC35i via UART. Kredsløbet består bl.a. af en "Max232" IC, der vha. nogle kondensatorer er i stand til at levelkonvertere de 0-5 der fås som output fra MEGA16 til niveauet som RS232 understøtter. DB-9 connector til brug ved tilkoblingen af TC35i KlarmeldingsPIN Benyttes til klarmelding af modul til Motherboardet. Spændingsregulering af forsyningsspænding fra Motherboardet. Side 25 af 55

26 7.5.3 Modul 3 Bluetooth Ansvar: Bluetooth modulets funktion er først at initialisere Bluetooth modemmet. Dernæst tjekke for information modtaget via Bluetooth fra Android telefonen. Ved modtagelse af information tjekkes relevansen. Er den relevant, videresendes den til Motherboardet via SPI. Bluetooth modulets uc fungerer som SPI slave Firmware: Skal implementere den overordnede funktionaliteten der illustreres på aktivitetsdiagrammet på Illustration 21 Driver: Bruges til konfiguration af LM058. Driveren kan også benyttes til ændring af indstillinger. Kommunikationen med LM058 foregår med "AT-kommandoer". Dog eksekveres disse anderledes end de AT-kommadoer til TC35i. LM058 behøver kun initialisering hvis den er blevet fejlkonfigureret eller reset. Den husker således indstillinger, selvom strømmen slukkes. Hardware: Bluetooth-modulets specialiserede HW består af: RS232 kredsløb til understøttelse af kommunikation med LM058 via UART. Kredsløbet består bl.a. af en "Max232" IC, der vha. nogle kondensatorer er i stand til at levelkonvertere de 0-5 der fås som output fra MEGA16 til niveauet som RS232 understøtter. DB-9 connector til brug ved tilkoblingen af TC35i KlarmeldingsPIN Benyttes til klarmelding af modul til Motherboardet. Spændingsregulering af forsyningsspænding fra Motherboardet Modul 4 - Smartphone Ansvar: Smartphonens primære funktion er, at fungere som et grafisk bruger interface (GUI). Den er brugerens adgang til systemet. Smartphonen skal have fire knapper: "åbn vindue", "luk vindue", "åben dør"og "luk dør". Alle fire knapper har en grafisk repræsentation af den funktion de udfører. Ud over funktionaliteten var det vigtigt at give brugeren en følelse af, at systemet er 'intuitivt og lækkert'. Dette stiller naturligvis krav til designet. Knapperne og GUI'en er designet med henblik på at give et enkelt og let overblik over systemets funktionalitet. Telefonens overordnede funktionalitet er: Ved tryk på knap på telefonen, skal der sendes en besked via Bluetooth (såfremt der er forbindelse). Er bluetooth forbindelsen afbrudt, skal den sende en besked med GSM. Dette stiller krav om Illustration 5: Modul 4 - Smartphone, GUI fire knapper (åbn- og luk dør, åbn- og luk vindue). Det er blevet valgt, for at fremme oplevelsen, at telefonen selv skal detektere om den er i bluetooth-afstand fra systemet. Denne funktionalitet er beskrevet på Illustration 22. Udover de umiddelbart synlige knapper, kan man også trykke på 'menu'. Denne menu giver en mulighedfor at vælge fire følgende ting: Sluk / Tænd-GSM Giver mulighed for at toggle om GSM skal være tændt eller slukket (i applikationen). Denne Side 26 af 55

27 implementeres for at forhindre utilsigtet brug af GSM. Luk alt! Trykker man på denne, sendes der besked om både at lukke vindue og dør. Vejledning Brugsvejledning til (applikationen). Om WCS Kort information om projektet. Vigtige overvejelser i udviklingsforløbet: Der var mange vigtige overvejelser i designstadiet. Nedenfor følger de mest toneangivende. Detektion af manglende bluetooth forbindelse. Dette blev der brugt meget tid på. Det ville ikke være så kompliceret at få implementeret hvis brugeren selv kunne toggle mellem Bluetooth- og GSM-tilstand. Men ønsket om et intuitivt design hvor brugeren skal have følelsen af, at applikationen er intelligent, førte til en mere kompliceret løsning. Androids bluetooth API understøtter ikke umiddelbart denne funktionalitet. Det viste sig efter mange forsøg, at afbrydes forbindelsen til bluetooth (LM058 slukkes), kan dette detekteres ved at tvinge information igennem bluetooth-streamen fra Android, dette fører til en "broken-pipeexception". Denne exception kan udnyttes i applikationen. Dette kræver dog efterfølgende genstart af bluetooth på telefonen. Da løsningen ville belaste den primære tråd, blev det besluttet at implementere denne i en seperat tråd (asynchronous task - Illustration 22). GUI'ens design: En anden vigtig overvejelse var hvilke knapper skulle der være på GUI'en. Målet var at få udviklet et så simpelt interface som muligt. Det blev overvejet om der kun skulle være to knapper, en knap til at toggle døren og en til at toggle vinduet. Dette ville kræve kendskab til vinduets og dørens tilstand (hvis de er lukket eller åbnet manuelt). Det besluttede at udvikle applikationen med fire knapper Modul 5 - XBee Main Ansvar: XBee Main modulets funktion er først at initialisere XBee radioen. Dernæst tjekke for modtagne beskeder fra Motherboardet. Modtages relevant information skal denne broadcastes (sendes up via Zigbee). XBeeradioen er flashed med "Coordinator" firmware (antager koordinator rollen i et XBee netværk [7]). Firmware: Skal implementere den overordnede funktionaliteten der illustreres på aktivitetsdiagrammet på Illustration 23 Driver: Bruges til konfiguration af XBee. Som med LM058 og TC35i bruger XBee AT-kommandoer til konfigurationen. I driveren er der ligeledes 'mikro'-funktioner samt makro-funktioner. Den vigtigste funktion ved disse drivere er at initialisere modulet. Når modulet er konfigureret behøves normalvis ikke yderligere konfiguration. Hardware: XBee_Main-modulets specialiserede HW består af: UART kredsløb til understøttelse af kommunikation med XBee. Bemærk at det ikke er RS232, men at den blot benytter de 0-5 Volt som MEGA16 leverer. Side 27 af 55

28 XBee status LED'er LED'er der kan vise netværksstatus for XBee, samt om der er aktivitet på netværket. KlarmeldingsPIN Benyttes til klarmelding af modul til Motherboardet. Spændingsregulering af forsyningsspænding fra Motherboardet. Det skal bemærkes at XBee-modulerne har to spændingsreguleringskredsløb. 5 Volt Forsyner MEGA Volt Forsyner XBee. Det blev overvejet at benytte en Atmel Mega16A til XBee-modulerne, da disse kræver 3.3 volt i forsyningsspænding, så der kun behøvedes eet spændingsreguleringskredsløb. Denne tanke blev dog bortkastet, da XB24-B kræver 5 Volt som logisk højt signal, hvilket en Mega16A ikke kan levere Modul 6 - XBee Window Ansvar: XBee Window modulets funktion er først at initialisere XBee radioen. Dernæst skal den tjekke om der bliver broadcastet noget fra XBee Main. Kommer der relevant information, skal der reageres på denne. Dvs. åbne eller lukket vinduet. XBee radioen på dette modul er konfigureret til at være 'Router / End Device" Firmware: Skal implementere den overordnede funktionaliteten der illustreres på aktivitetsdiagrammet på Illustration 24 Driver: Driveren er den samme som ved XBee Main, og bruges til at konfigurere chippen med. Hardware: XBee_Window-modulets specialiserede HW består af: UART kredsløb til understøttelse af kommunikation med XBee. Bemærk at det ikke er RS232, men at den blot benytter de 0-5 Volt som MEGA16 leverer. XBee status LED'er LED'er der kan vise netværksstatus for XBee, samt om der er aktivitet på netværket. KlarmeldingsPIN Benyttes til klarmelding af modul til Motherboardet. Spænding forsynes fra lysnettet via en adapter (12-15 Volt) Det skal bemærkes at XBee-modulerne har to spændingsreguleringskredsløb. 5 Volt Forsyner MEGA Volt Forsyner XBee. Her kunne det i kommercialiserings-øjemed, at udvikle denne del til at være batteridrevet. Dette ville kræve større hensyn til strømbesparelse i systemet. Side 28 af 55

29 7.5.7 LEDs til indikation om vindue er åbent eller lukket Modul 7 - XBee Door Modul 7 - XBee_Door er helt ens HW og Firmware-mæssigt. Den eneste forskel er de kommandoer modulet tjekker efter. Dette modul skal reagere på kommandoer der vedrører 'døren', hvorimod Modul 6 XBee_Window reagerer på kommandoer der vedrører 'vinduet'. Det skal dog nævnes at selve hardwaren stadig skal monteres, loddes og fejlfindes. Side 29 af 55

30 7.6 Udviklingsværktøjer Hardware I dette afsnit beskrives de udviklingsværktøjer der er hardwarebaseret. Dvs. fysiske hjælpemidler. RS232 Communication Spy og USBASP har jeg selv konstrueret til projektet. Dog er USBASP baseret på et allerede eksisterende diagram RS232 Communication Spy Illustration 6: RS232 kommunikations sniffer CD'en Beskrivelse: Jeg har selv konstrueret denne RS232 kommunikations sniffer. Den gør det eksempeltvis muligt at se hvad microcontrolleren siger til TC35i eller LM058, eller hvad de siger til mikrocontrolleren. Erfaring: Dette værktøj har været uundværligt. Denne sniffer har reduceret debugging-forløbet med flere uger. Andet: Schematic for denne sniffer findes i dokumentationen og på USBASP Beskrivelse: In System Programmer, brugt som alternativ til STK500. Bruges til programmering af mikrocontrollere der understøtter In System Programming (ISP). Forbindes til computer med USB-kabel og kan nu programmere en Atmel Microcontroller via ISP-Stik (10-polet) Erfaring: Et effektivt værktøj, som ikke fylder særligt meget, men er særdeles nyttigt. Samtidig sparer det en for en masse kabler da den understøtter USB og ikke har brug for en COM-port. Illustration 7: USBASP In System Programmer Andet: Driver, Schematic og layout findes på vedlagte CD. Baseret på oplysninger fra: Side 30 af 55

31 XBee Development kit Beskrivelse: Dette Dev-kit er blevet brugt til at skifte firmware på XBeeradioerne. Erfaring: Fungerer godt, både med RS232- og USB-tilslutning (Billedet viser RS232 version). Illustration 8: XBee Development Kit STK500 Development Kit Beskrivelse: Bruges til programmering af Atmels Microcontrollere. Er samtidig blevet brugt til debugging ift. udvikling af SPIinterfacet. Erfaring: STK500 er et udviklings-printkort, meget alsidigt og uundværligt i udviklingen af systemer der indeholder Atmel microcontrollere. Illustration 9: Atmel STK500 Development Kit Fluke 179 Multimeter Beskrivelse: Multimeter der kan måle: strømme, spændinger, capaciteter, dioder, gennemgang osv. Erfaring: Uunværligt i test og fejlfinding af print. Software I dette afsnit beskrives den software der er benyttet i løbet af projektforløbet. Side 31 af 55

32 Multisim Beskrivelse: Benyttet til udvikling af elektriske diagrammer (schematics). Arbejdet godt sammen med Ultiboard, som kan realisere disse diagrammer som printkort. Erfaring: Dejligt at arbejde med, meget intuitivt Ultiboard Beskrivelse: Program til udvikling af printlayouts. Bruges sammen med Multisim, som leverer schematics. Erfaring: Ultiboard er intuitivt og effektivt at arbejde med. Dog kræves en del kendskab til elektriske kredsløb og layout Codevision AVR Beskrivelse: Program til udvikling af firmware til Atmel Microcontrollere. Kan samtidig bruges til at kompilere og programmere microcontrollere. Erfaring: Et godt program. Codevision indeholder også en masse biblioteker, som kan bruges i firmwareudvikling. Meget brugbart Open Office Writer Beskrivelse: Open Source skriveprogram a lá det mere kendte 'Word'. Erfaring: Open Office Writer har de funktioner det skal have. Fungerer godt og intuitivt. Rapporten og dokumentationen er blevet skrevet med Open Office Writer Enterprise Architect Beskrivelse: Program til modellering af UML-diagrammer. Erfaring: Kræver lidt tid, men når man lærer det at kende fungerer det rigtig godt. Brugt til alle UML diagrammer i projektet Microsoft OneNote Beskrivelse: Microsofts noteprogram. Erfaring: Side 32 af 55

33 One Note har været et uundværligt værktøj i dette projekt. Programmet har holdt styr på al information undervejs Adobe Fireworks Beskrivelse: Avanceret billedbehandlingsprogram a lá det mere kendte Photoshop Erfaring: Er blevet brugt til al grafik i projektet, både til dokumenter, men også til GUI på telefonen. Godt program, nemt at gå til X-CTU Beskrivelse: Bruges til at give XBee-radioen ny firmware. Indeholder også en COM-terminal. Erfaring: Gør det det skal: Give ny firmware til XBee. Terminalen er god, da den kan skelne mellem sendt og modtaget information Notepad++ Beskrivelse: Notepad++ fungerer som Windows' notepad. Forskellen er evnen til at have flere dokumenter åbne i faneblade. Samtidig kan den give evt. kodefiler farvekoder. Erfaring: Rigtig godt program til behandling af små tekstfiler. Side 33 af 55

34 7.7 Resultater Dette afsnit er en opsamling på de opnåede resultater i projektgennemførelsen. Resultaterne holdes op imod kravene i kravspecifikationen. Dette afsnit omhandler de resultater der er opnået ifm. test af det samlede system. Der er dog nogle af testene der ikke vedr. kravspecifikationen, test af mere designmæssig karakter. Smartphone-applikationen kan være enten i 'bluetooth-mode' eller 'GSM-mode'. Systemet skal testes i begge disse modes. Dvs. de use cases der er beskrevet i kravspecifikationen skal testes for begge modes. Først testes det om telefonen er i stand til selv at detektere hvorvidt der er bluetooth forbindelse eller ej Resultat af test Bluetooth forbindelse Smartphonen skal være i stand til at detektere, hvorvidt bluetoothforbindelsen kan skabes eller ej. Ved afbrudt bluetoothforbindelse skal den automatisk skifte til GSMmode. Samtidig skal baggrundsfarven skifte til rød. Er der igen mulighed for at oprette forbindelse til bluetoothenheden (modul 3), skal dette gøres automatisk. Baggrundsfarven skal i så fald skifte til blå. Illustration 10: GUI i Illustration 11: GUI i GSM mode bluetooth mode Test: Resultat: Bemærkning: Kan smartphone detektere at bluetooth forbindelsen afbrydes. Godkendt Tager ca sekunder fra afbrudt forbindelse. Kan smartphone automatisk oprette forbindelse til modul 3 - bluetooth, når denne er til stede. Godkendt Tager ca. 2-3 sekunder fra ekstern bluetooth er startet op. Test for skift af baggrund (blå til rød) Godkendt Indikerer at smartphone skifter til GSM-mode. Test af skift af baggrund (rød til blå) Godkendt Indikerer at smartphone skifter til bluetooth-mode. Side 34 af 55

35 7.7.2 Resultater i Bluetooth Mode Testen har til hensigt at undersøge, om systemet opfører sig som det skal i bluetooth mode. Dette undersøges ved at afprøve alle funktioner imens applikationen er i bluetooth-mode. Illustration 12: Knaptryk i bluetooth mode Testresultater: Test: Resultat: Bemærkning: Tryk på 'åbn dør' åbner døren. Godkendt 'Dør' åbner (grøn diode lyser) Tryk på 'luk dør' lukker døren Godkendt 'Dør' lukker (rød diode lyser) Tryk på 'åbn vindue' åbner vinduet Godkendt 'Vindue' åbner (grøn diode lyser) Tryk på 'luk vindue ' lukker vinduet. Godkendt 'Vindue' lukker (rød diode lyser) Funktionerne virker efter hensigten. Illustration 13: Grøn diode lyser Illustration 14: Rød diode lyser Side 35 af 55

36 7.7.3 Resultater i GSM Mode Testen har til hensigt at undersøge, om systemet opfører sig som det skal i GSM mode. Dette undersøges ved at afprøve alle funktioner imens applikationen er i GSMmode. Illustration 15: Knaptryk i GSM mode Testresultater: Test: Resultat: Bemærkning: Tryk på 'åbn dør' åbner døren. Godkendt 'Dør' åbner (grøn diode lyser) Tryk på 'luk dør' lukker døren Godkendt 'Dør' lukker (rød diode lyser) Tryk på 'åbn vindue' åbner vinduet Godkendt 'Vindue' åbner (grøn diode lyser) Tryk på 'luk vindue ' lukker vinduet. Godkendt 'Vindue' lukker (rød diode lyser) Funktionerne virker efter hensigten. Illustration 16: Grøn diode lyser Illustration 17: Rød diode lyser Side 36 af 55

37 7.7.4 Anden funktionalitet I GUI'en er der adgang til nogle flere funktioner gennem 'menu' tasten. Sluk GSM (hvis der trykkes ændres denne til 'Tænd GSM') Fungerer efter hensigten. Toggler GSM-tilladelse internt i applikationen. Luk Alt! Fungerer efter hensigten. Lukker både dør og vindue på samme tid. Vejledning Fungerer efter hensigten. En brugervejledning til GUI'en vises. Om WCS Fungerer efter hensigten. Der vises "kort om." Ud over de manuelle funktioner er der også andre forhold der gør sig gældende: Applikation går i pause mode Får ikke altid disconnected fra bluetooth hvis den går i pause mode. Dette bevirker at nogle gange ved 'onresume' at bluetooth forbindelsen ikke kan få fat igen. Applikation lukkes ned Det hænder (især i Bluetooth mode) at systemet sender en fejlmeddelelse når det lukkes ned. Dette betyder ikke noget i praksis, men tyder på noget der gemmer sig. Information hænger fast i systemet. En sjælden gang får systemet ikke den videresende information videregivet. Ifølge debugdioderne på Motherboardet sidder systemet fast ved modtagelsen af information. Dette problem løses ved at trykke reset på systemet. 7.8 Diskussion af opnåede resultater Samlet set fungerer systemet godt, systemet føles lækkert og intuitivt at benytte. Der er nogle småfejl, det er dog ikke fejl der ødelægger indtrykket af systemet. Systemet kører glat og ubesværet. Døren kan åbne og lukke, vinduet kan åbne og lukke. Således er formålet med projektet opfyldt, nemlig at konstruere et generisk framework der via en Android telefon kan fjernstyre objekter Resultat af test Bluetooth forbindelse Bluetooth til GSM Mode (ved tabt bluetooth forbindelse): Denne del fungerer som den skal. Desværre må det siges, at det tager 'lang tid'. Dog forventes det ikke, at man hele tiden går rundt i gråzonen mellem GSM- og bluetooth-rækkevidde. GSM til Bluetooth (Bluetooth igen inden for rækkevidde): GSM til Bluetooth fungerer systemet helt optimalt. 2-3 sekunder fra den er kommet inden for bluetooth rækkevidde. Resultatet er overordnet ganske tilfredsstillende for denne del. Især da det tilføjer en mere intuitiv / pervasive følelse af systemet. Havde det f.eks. været en knap man skulle trykke på for at toggle mellem Side 37 af 55

38 bluetooth og GSM, havde følelsen ikke været ligeså 'lækker' Resultat i Bluetooth Mode Basale funktioner i Bluetooth mode: Fungerer godt. Reagerer hurtigt (dioder skifter umiddelbart efter tryk). Enkelte gange ser det dog ud til, at informationen bliver 'hængende' i systemet. Debugdioderne på Motherboardet indikerer, at den bliver ved med at indeholde forrige information. Fejlen kan korrigeres ved tryk på 'Reset'. Resultatet betragtes som værende tilfredsstillende Resultat i GSM Mode Basale funktioner i GSM mode: Umiddelbart ingen fejl i dette mode. Det kan dog nævnes, at hvis knaptryk forkommer kort efter hinanden, vil kun det første blive registreret. Dette er grundet Modul 2 - GSM's "SMS-læse-algoritme." Resultatet betragtes som værende tilfredsstillende Anden funktionalitet Funktionerne der findes i 'menuen' blev også testet. Resultatet af tests af disse funktioner kommenteres kort herunder: Sluk GSM: Funktionen fungerer efter hensigten. Forhindrer utilsigtet brug af applikationen (forhindrer applikationen i at sende SMS'er) Luk Alt!: Funktionen fungere som den skal, uanset om den er i bluetooth- eller GSM mode, lukker den både dør og vindue. Vejledning: Vejledningen dukker op i en dialogboks. Vejledningen fungerer efter hensigten. Om WCS: "Om WCS" fortæller kort om projektet i en dialogboks. "Om WCS" fungerer efter hensigten WCS i forhold til andre systemer Naturligvis kan WCS ikke sammenlignes med samtlige systemer på markedet. Dog er en sammenligning stadig relevant. Nedenfor nævnes forskellige systemer, hvad de kan og hvordan WCS adskiller sig fra dem. Oplysningerne om systemerne har jeg fået ved samtale med medarbejdere fra de pågældende firmaer (opkald til Velux og Falck foretaget. 2.september), Danbits produkt er set i nyhedsbrev og fundet i katalog [10]. Velux Integra: Et system der kan bruges til fjernstyring af vinduer, gardiner og ovenlysvinduer. Systemets kommunikation fungerer vha. en protokol som Velux selv har udviklet. Fjernstyringen foregår vha. en fjernbetjening, der understøtter op til 200 forskellige enheder. Velux Integra vs. Velux' system var oprindeligt udviklet til at skulle styres vha. IR-teknologi. Dette er dog forbedret nu, Side 38 af 55

39 således er rækkevidden blevet større, samtidig skal man ikke længere 'pege' direkte på enheden. Dog er systemet meget 'internt'. Grundet en fjernbetjening designet specifikt til dette system, hvilket giver 'endnu en fjernbetjening' i hjemmet. WCS er baseret på brugerens smartphone og er i stand til at kontrollere systemet via GSM, og kan dermed styre systemet fra stort set hele verden. Samtidig understøtter WCS i teorien enheder. Danbit GSM-Gate: Et system der netop er blevet udviklet af Danbit. Det er et GSM-styret relæ, som evt. kan sluttes til en dørlås. Systemet kan indeholde op til 500 telefonnumre, som kan konfigureres vha. PC eller SMS. Systemet giver mulighedfor at slå et relæ til og fra vha. telefonen. GSM-Gate vs. GSM-Gate kan slå et relæ til og fra ved hjælp af GSM. WCS er også i stand til at slå noget til og fra med GSM, men også med bluetooth. GSM-Gate har også mulighed for at benytte timer-styret kontrol af relæet. Falck Alarm: Falck har fået udviklet et system til overvågning af hjemmet. Det er ikke lykkedes mig at få at vide hvilken teknologi der benyttes. Men efter en samtale med en medarbejdet om systemets formåen, kunne systemet være Zigbee baseret. Falcks alarmsystem kan desuden styres vha. GSM. Falck Alarm vs. Umiddelbart virker Falcks Alarmsystem efter nogle af de samme principper som WCS, dog er falcks system ganske udviklet. Systemet giver mulighed for tilkobling af forskellige sensor-moduler: indbrudsalarm, røgalarm og gasalarm (og sikkert flere). WCS adskiller sig fra Falcks system ved at det kontrolleres vha. en Smartphone. Falcks system kan betjenes vha. et fastmonteret betjeningspanel, samt en fjernbetjening. Dog skal det siges, at WCS kun er en funktionsmodel. Både Velux, Danbit og Falck har fuldt udviklede og kommercialiserede produkter. På den baggrund kan man ikke sammenligne nogen af dem med WCS, det er kun systemets funktionalitet der kan bruges i denne sammenligning. Den funktionalitet WCS repræsenterer er samtidig dets "muligheder", hvor Velux, Danbit og Falck har systemer hvor funktionaliteten er til stede (i stedet for en diode der lyser, er der rent faktisk et vindue der åbner og lukker osv.). 7.9 Opnåede erfaringer Her beskrives det hvilke erfaringer jeg har opnået. Erfaringer både i forhold til systemet, men også selve udviklingsforløbet. De største forhindringer undervejs: STK500: STK500 kit blev fejlbehæftet. Det er uklart hvad der foresagede fejlen. Dog var årsagen muligvis en kortslutninger på et af modul-printene ifm. In System Programming (ISP). Løsningen var en omkonfiguration af jumpers på STK500. Dette blev opdaget i forsøget på at benytte et eksternt krystal i stedet for STK500's indbyggede frekvensgenerator. Bluetooth forbindelse fra Android: I en lang periode kunne det observeres at Smartphone var forbundet og parret med LM058. Det var dog ikke muligt at sende information imellem dem. Problemet blev løst ved at slukke og genstarte Side 39 af 55

40 bluetooth på Android inden der skulle sendes information. AT-kommandoer: Alle de trådløse teknologier benytter AT-kommandoer som kommunikationsform. I udviklingen af driverne viste det sig, at den måde AT-kommandoerne bruges på er meget forskellig. Eksempeltvis kan den ene teknologi kan tage imod hele strenge fra mikrocontrolleren, hvor den anden kun kan tage imod 'chars'. Ydermere er rækkefølgen på "newline" + "carriage return" (svarende til et 'enter'tryk i en PC-terminal) forskellig for de forskellige teknologier. Problemet blev løst ved en testfase, hvor RS232 Communication Spy blev benyttet til systematisk at prøve sig frem. LM058 firmware problem: LM058 reagerede ikke på de AT-kommandoer der var angivet i manualen. Der blev brugt lang tid på udviklingen af en driver, da kommandoerne skulle 'gættes' (igen benyttedes RS232 Communication Spy). Det viste sig at firmwaren på LM058 svarede til firmwaren på en LM048 (en tilsvarende bluetooth enhed). Enheden blev skiftet ud, hvorefter en ny driver blev udviklet, en driver der matchede hvad der stod i LM058's manual. Gode erfaringer: Problemløsning: I arbejdet med hardware, software og firmware, har jeg fået en erkendelse. En vished om, at hvis man stænker logisk, analytisk og er vedholdende kan man overvinde langt de fleste tekniske problemer. Samtidig øges kundskaben og selvtilliden for hver overvunden forhindring. Struktur giver overblik og præcision: Arbejdet med objektorienteret udvikling samt SCRUM giver fremdrift. Struktur i projektudviklingen giver både fart, præcision og overblik. Disciplin uden gruppe: Erkendelsen af vedvarende disciplin og struktur på trods af at være uden for en gruppe, har været en god erfaring Projektets fortræffeligheder Der er dele af dette projekt, som jeg er specielt stolt af. Disse dele vil jeg kort nævne og forklare: Brugerinterfacet: Specielt brugerens berøring med systemet, nemlig den GUI der er på telefonen. Denne giver hele systemet en intuitiv og lækker umiddelbarhed tilgang til systemet. Især vil jeg nævne det der sker når systemet eks. skifter fra GSM til bluetooth mode, hvor baggrunden skifter. Modulløsningen: Det at systemet er modulbaseret. At modulerne kan skiftes ud uden at forstyrre systemet, når bare interfacet og protokollen er overholdt. Denne løsning er også en klar fordel i en udviklingssammenhæng. Bluetooth kan evt. skiftes ud med Wifi eller andre teknologier. Samtidig er det også en stor fordel at modulerne kan testes seperat. SPI-delen: Det som jeg har valgt at kalde: "Passive Token Ring Configuration", hvor motherboardet kan trække oplysninger ud af de tilstødende moduler skiftevis. Side 40 af 55

41 Smartphone der kan kontrollere Zigbee: Det at have konstrueret et system der gør, at en smartphone kan kontrollere Zigbee moduler både via Bluetooth men også GSM synes jeg er værd at fremhæve, da dette giver rigtigt mange brugsmuligheder. Generisk system: Netop de mange brugsmuligheder, det generiske system, der i teorien kan kontrollere hvad man vil synes jeg er een af de allerstørste forcer som dette system har. Tænker man eks. på den kommende store generation ældre, vil det være muligt fra een smartphone at kontrollere lige så mange enheder som der kan være på et Zigbee netværk (i skrivende stund understøttes enheder i et netværk. Et netværk der ovenikøbet kan udvides ved brug af gateways [5]) Forslag til forbedringer Systemet kan forbedres på mange områder. En del forbedringer kun også blive aktuelt i en given tilpasningssituation. Da systemet jo er generisk kan det tilpasse mange situationer. Der er her taget udgangspunkt i forskellige områder der kan forbedres. Økonomi: Samle systemet på eet print: Dette ville spare printkort, montagetid samt mikroprocessesorer. Udskifte Bluetooth- og GSM-terminal: Der findes billigere udgaver på markedet. Udgaver der har den ønskede funktionalitet. Funktionel: NAND-gate / multiplexer: Et alternativ til "Passive Token Ring Configuration" kunne være, at lade Bluetooth-, GSM- og XBee_Main modulerne være forbundet til Motherboardet gennem en NAND-Gate. Således kunne de dele en interruptpin på Motherboardet. Dette ville kunne gøre Motherboardet interruptstyret og hurtigere. Udover en NAND gate, skulle der tilføjes en indikation af hvem der prøver at få kontakt. (Dette kunne være en multiplexer-løsning). Optimering ift. batteri: Ønskes fjernstyrede objekter, der ikke er koblet på lysnettet, ville man kunne optimere de perifere enheder til at kunne køre på batteri. Især med tanke på at XBee modulerne er udviklet til at køre med ekstremt lavt batteriforbrug. Sikkerhed: I tilfælde af at systemet skulle bruges i en rigtig 'dør-/vinduessituation' skal sikkerheden nøje overvejes. Således kunne man tilføje funktionalitet som tilmeldning af telefoner til systemet. Master telefon, der kan omkonfigurere GSM og Bluetoothmodemet vha. GSM. Størrelse: Ny GSM-terminal: GSM-terminaler fåes i meget mindre udgaver. Udgaver der sagtens kan passe på et print. Bluetooth On-a-Chip: Det samme gælder Bluetooth. Disse RS232 replacements fåes også i meget små udgaver, der sagtens kan være på et print. Side 41 af 55

42 SMD-print: Brugen af SMD-komponenter på printkortene ville mindske størrelsen af printene betragteligt. Fjerne Debugdioder: Det ville fjerne en del printbaner, og dermed frigøre en del plads, hvis man fjernede alle debugdioderne. Ovenstående forbedringer kunne føre til at bedre generisk framework. Skulle systemet kommercialiseres, skulle der tænkes mere på udviklingen af de 'perifere' moduler. Skal man eksempeltvis åbne et vindue, er det vigtigt at have et modul der kan åbne og lukke vinduet. Dette kunne evt. være et komplet modul med motor og det hele. Det kunne også være en automatisk dør, hvor man kan tilkoble modulet til fjernstyring. Dette er dog ikke en del af projektet, men stadig værd at nævne. Side 42 af 55

43 8 Konklusion Det er i dette udviklingsprojekt lykkedes, at konstruere et system der gør det muligt at kontrollere Zigbeeenheder fra en smartphone. På trods af forskellige småfejl og gener er systemet fuldt funktionelt og opfylder de krav der er stillet til systemet. Udviklingsforløbet har været berigende og udviklende. Det har været godt at se at en struktureret tilgang til arbejdet, samt engagement og god sparring kan føre til gode resultater. Trods af problemer både i analyse- men også implementerings-fasen viste det sig, at problemer er noget man kan arbejde sig ud af. Den overordnede arkitektur viste sig at være et godt valg. Opsplitningen i moduler, gjorde det muligt at delteste systemet, selvom resten ikke var færdigimplementeret eller var fejlbehæftet. Systemet er, som før nævnt, er et 'generisk' system. Systemet er således ikke tilpasset noget konkret. Derfor må det konkluderes at systemet stadig er på et stadie der ikke umiddelbart kan kommercialiseres. En slags funktionsmodel, der bekræfter at formålet kunne opnåes. Dog ville det med ganske få modifikationer være muligt, at tilpasse systemet til mange anvendelsesområder. Det er dog muligt at benchmarke systemet i forhold til eksisterende produkter på markedet. Projektets produkt vidner om et projekt som har været en succes. Men personligt er den tilegnede viden endnu vigtigere. Viden om konkrete teknologier, men også mere overordnet og generel viden om projektstyring og struktur af projekter samt projektforløb. Alt i alt konkluderes det, at trods modstand og småfejl, har projektet været en stor succes. Side 43 af 55

44 9 Litteraturliste [Nr.] [1] Litteratur: Barnett, Cox & O'Cull: Embedded C Programming and the Atmel AVR, 2.edition Type: Bog Dato: Beskrivelse: Bog omhandlede udvikling af applikationer på indlejrede platforme. CD-Rom: [Nr.] [2] Litteratur: Reto Meyer, Professional Android 2 Application Development, 1.edition Type: Bog Dato: Beskrivelse: Bog omhandlende udvikling af applikationer på Android platforme CD-Rom: [Nr.] [3] Litteratur: Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3.edition Type: Bog Dato: Beskrivelse: Bog om UML designmønstre CD-Rom: Side 44 af 55

45 [Nr.] [4] Litteratur: VejledningForEitProjekter.pdf Type: *.pdf Dato: Beskrivelse: Vejledning til hvordan man udformer sin projektrapport. CD-Rom: Litteratur\VejledningForEitProjekter.pdf [Nr.] [5] Litteratur: faq_drop_in_networking.pdf Type: *.pdf Dato: Beskrivelse: Ofte stillede spørgsmål om XBee netværk CD-Rom: Litteratur\faq_drop_in_networking.pdf [Nr.] [6] Litteratur: Atmel Mega16.pdf Type: *.pdf Dato: Beskrivelse: Datablad for Atmel Mega 16 Microcontroller CD-Rom: Litteratur\Atmel Mega16.pdf Side 45 af 55

46 [Nr.] [7] Litteratur: XB24-B.pdf Type: *.pdf Dato: Beskrivelse: Datablad for Digi XB24-B Microcontroller CD-Rom: Litteratur\XB24-B.pdf [Nr.] [8] Litteratur: LM058.pdf Type: *.pdf Dato: Beskrivelse: Manual LM058 CD-Rom: Litteratur\LM058.pdf [Nr.] [9] Litteratur: TC35i.pdf Type: *.pdf Dato: Beskrivelse: Manual TC35i CD-Rom: Litteratur\TC35i.pdf [Nr.] [10] Litteratur: (findes også på CD) Side 46 af 55

47 Type: URL Dato: Beskrivelse: Katalog med beskrivelse af GSM-Gate systemet. CD-Rom: Litteratur\GSM-Gate\Danbit.htm [Nr.] [11] Litteratur: Atmel Mega8.pdf Type: *.pdf Dato: Beskrivelse: Datablad for Atmel Mega 8 Microcontroller CD-Rom: Litteratur\Atmel Mega8.pdf Side 47 af 55

48 10 Bilag 10.1 Bilag A: Tidsplan Illustration 18: Projektets tidsplan Side 48 af 55

49 10.2 Bilag B: Firmware diagrammer Modul 1 - Motherboard Illustration 19: Modul 1 - Motherboard, firmware aktiviteter Side 49 af 55

50 Modul 2 - GSM Illustration 20: Modul 2 - GSM, firmware aktiviteter Side 50 af 55

51 Modul 3 - Bluetooth Illustration 21: Modul 3 - Bluetooth, firmware aktiviteter Side 51 af 55

52 Modul 4 - Smartphone (Async tråd) Illustration 22: Modul 4 - Smartphone, Async Task aktiviteter Side 52 af 55

53 Modul 5 - XBee Main Illustration 23: Modul 5 - XBee Main, firmware aktiviteter Side 53 af 55

54 Modul 6 - XBee Window Illustration 24: Modul 6 - XBee Window, firmware aktiviteter Side 54 af 55