ITWEM1. Home Management System. Udarbejdet af: Mads Michelsen (04200) Morten Engberg (04268) Sune Hedetoft (03800) Dato: 4.

Transkript

1 ITWEM1 Home Management System I2C Temp. Sensor GPIO Tænd/Sluk Sensor SPI Alarm Bluetooth Udarbejdet af: Mads Michelsen (04200) Morten Engberg (04268) Sune Hedetoft (03800) Dato: 4. juni 2009 Ingeniørhøjskolen i Århus

2 Indholdsfortegnelse 1 Indledning Formål Referencer Definitioner Læsevejledning 2 2 Projektbeskrivelse Hardware 3 3 Arkitekturdesign HMS Konsol Presentation layer Business Layer HMS MeasurePoint Data Access Layer HMS Mobil Klient Presentation layer Business layer Data Access layer 14 4 Resultat og test Diskussion af opnåede resultater 16 5 Opnåede erfaringer Tahoe touchscreen events Invalid Operation Exception Serialisering mellem Compact - og Micro Framework MF og 1-Wire 16 6 Konklusion Fremtid 17 7 Bilag Figurliste Tabelliste Diagram farve betegnelser Billeder af HMS HMS Konsol HMS Mobil Klient 19

3 1 Indledning 1.1 Formål I forbindelse med ITWEM1 kurset på Ingeniørhøjskolen i Århus (IHA), skal der udarbejdes et projekt, hvor der inddrages dele af den teori der er blevet undervist i. Denne rapport beskriver det projekt som Morten Engberg, Mads Michelsen og Sune Hedetoft har beskæftiget sig med. Projektet har fået navnet: Home Management System (HMS) og omhandler et system til overvågning af hjemmet. Rapporten vil give læseren, med den rette tekniske forståelse for faget, et indblik i, hvordan løsningen er blevet implementeret og hvordan det endelige resultat er blevet opfyldt i henhold til en udført test. 1.2 Referencer Bánský, P. (2007). 1-Wire Bus and.net Micro Framework. Hentede 2009 fra About.NET in Embedded World: Device Solutions.net. (2009). Tahoe-II Development Board. Hentede 2009 fra Kühner, J. (2008). Expert.NET Micro Framework. Apress. Martin, R. C., & Martin, M. (2006). Agile Principles, Patterns and Practices in C#. Pearson Education Inc. Microsoft. (2009). WindowsClient.NET. Hentede 2009 fra Windows Presentation Foundation: Århus Tekniske Bibliotek. (2009). Litteraturlister og litteraturhenvisninger. Hentede 2009 fra Definitioner Følgende liste forklarer de definitioner der er anvendt i rapporten Definition Forklaring HMS Home Management System IHA Ingeniørhøjskolen i Århus Tahoe Tahoe II developer kit (Device Solutions.net, 2009) HMS Mobil Klient Applikationen der afvikles på Windows Mobile og kan forbinde til HMS HMS Konsol Applikationen der afvikles på Tahoe II Developer kit og har forbindelse til enheder i hjemmet. WPF Windows Presentation Foundation (Microsoft, 2009) MF.NET Micro Framework CF.NET Compact Framework Sune Høffding Hedetoft Side 1 af 19

4 1.4 Læsevejledning Denne rapport indeholder en generel beskrivelse, samt funktionelle krav og design af HMS. Der er ligeledes vedlagt en CD, hvor denne rapport findes i digital form. Derudover er der på cd en vedlagt datablade og kildekoden for systemet. Kapitel 1: Indledning Indledning til projektet, formål, referencer og definitioner. Kapitel 2: Projektbeskrivelse Definerer projektets funktionelle krav, og en generel beskrivelse af systemet. Kapitel 3: Arkitekturdesign Implementering af systemet og den anvendte arkitektur. Kapitel 4: Resultat og test Resultat og test af systemet Kapitel 5: Opnåede erfaringer Beskriver opnåede erfaringer og problemstillinger under projektet Kapitel 6: Konklusion Konklusion af systemet Kapitel 7: Bilag Refererede dokumenter gennem rapporten, samt yderligere information der ikke falder ind i rapportens punkter. Generelt: Referencer angives med Harvard-formatet (Århus Tekniske Bibliotek, 2009), som angiver forfatter/virksomhed efterfulgt af årstal. Læseren kan ved en sådan henvisning slå op i referencer og finde uddybende information til emnet. Figurer nummers med fortløbende figurnummer efterfulgt af beskrivende tekst Tabeller nummers med fortløbende tabelnummer efterfulgt af beskrivende tekst Forkortelser angives i parenteser efter det fulde navn. Forkortelsen anvendes herefter uden uddybning af dens betydning Sune Høffding Hedetoft Side 2 af 19

5 2 Projektbeskrivelse Ideen med HMS er at integrerer forskellige perifere enheder i hjemmet, som f.eks. lys, temperatur og alarm sensorer. Systemet skal gøre det muligt at overvåge, om man f.eks. har er glemt at slukke lyset i bryggerset, om temperaturen er tilpas i alle rum, eller om man f.eks. har glemt at lukke alle vinduer i huset inden man tager hjemmefra. Figur 1 Illustration af Home Mangement System (HMS) Ovenstående billede viser en illustration af det ønskede system. Mobiltelefonen/PDA kommunikerer via Bluetooth med Tahoe II kortet, som er forbundet til forskellige perifere enheder. Enhederne kan aflæses fra både Tahoe II og mobiltelefon/pda, som vises til brugeren via et grafisk layout. På Tahoe II og mobiltelefon/pda, vil det grafiske bruger interface anvende touch funktionaliteten. 2.1 Hardware Projektet tager brug af følgende hardware. Tahoe II Developer Kit Windows Mobile Serial til Bluetooth Adapter Temperaturføler (I2C) Tænd/Sluk sensor (GPIO ) Alarm simuleret med STK500 developer kit (SPI) Sune Høffding Hedetoft Side 3 af 19

6 Figur 2 illustrerer et blokdiagram over systemet. SPI GPIO Figur 2 HMS Blokdiagram Sune Høffding Hedetoft Side 4 af 19

7 3 Arkitekturdesign Det samlet HMS er delt op i to delsystemer. Udvikling til HMS konsol, som er et Microsoft.NET Micro framework applikation og HMS mobil klient som er en Windows Mobile applikation, udviklet i Microsoft.NET Compact framework. I de efterfølgende afsnit beskrives arkitekturen for de to delsystemer. 3.1 HMS Konsol Applikationen på HMS konsolen er udviklet i Microsoft.NET Micro Framework og er bygget som en lagdelt struktur. Presentation layer HMS GUI Business layer RemoteController HMS Controller HMS Mesaurepoints Data Access Layer Data Layer HMS Communication Legend Egenudviklede pakker og klasser Eksterne Pakker og klasser Interfaces Sensors Bluetooth Ekstern Hardware Figur 3 Pakkediagram HMS Konsol Lag Presentation layer Business layer Data Access layer Data layer Beskrivelse Indeholder HMS GUI pakken, som præsenterer den grafisk brugergrænseflade. Står for al forretningslogik mellem presentation layer og Data access layer. RemoteController klassen står dog udelukkende for logikken til HMS mobil klient. Her tilgås der adgang til de forskellige perifere enheder fra forskellige busser, som er understøttet af HMS konsolen. Er perifere enheder, i form af temperaturføler og simuleret døre, vinduer, lys og alarm, som er koblet til HMS konsolen. Bluetooth enheden anvendes til forbindelse mellem HMS konsole og HMS mobil klient Sune Høffding Hedetoft Side 5 af 19

8 3.1.1 Presentation layer Her beskrives det udviklede menu struktur til HMS Konsol. Programmet viser ved opstart en hovedmenu, hvor der kan trykkes ind på undermenuer. Hver undermenu viser enheder af den pågældende type og har mulighed for at returnere til hovedmenuen. Presentation layer HMS GUI Application Window +Run() Program -mainprogram +Main() BaseWindow «interface» IState Menu Windows MainMenuWindow WindowsMenuWindow LightsMenuWindow StateHandler +Start(in p : Program) DoorsMenuWindow TempMenuWindow SetupMenuWindow Business layer HMS Controller Figur 4 Klassediagram over pakken HMS GUI Ved programopstart sender Program klassen en instans af sig selv til StateHandler. Denne sørger for at sætte første State til MainMenu og derved loade et Window objekt i program objektet. Når programmet er startet og Main Menu vises, vil event fra brugerinput registreres og kalde et nyt State via IState interfacet, som så loader den valgte menu. Til generering af det grafiske layout på hver menu vindue, er der anvendt Micro Frameworkets GUI objekt model, som er baseret WPF (Microsoft, 2009), men som er uden XAML understøttelse. Dvs. at alle objekter skal oprettes og placeres manuelt i paneler, i den rigtige rækkefølge Business Layer Business laget har ansvaret for at styre forretningslogikken for HMS. Figur 5 illustrerer business lagets opbygning. Pakken HMS MeasurePoint er beskrevet i afsnit Sune Høffding Hedetoft Side 6 af 19

9 Figur 5 Klassediagram over pakken HMS Controller Klassen HMSControl er en singleton og har ansvar for at tilføje nye måleenheder til systemet, som derved ligges i en arraylist. Måleenhederne er angivet i pakken HMS MeasurePoint, som er uddybet i afsnit Klassen kører sin egen tråd som fyrer en række events, når der er hentet en ny måling. Eventene indeholder et array med MeasurePoint på den samme type enhed. HMSControl implementere 2 interfaces, som anvendes af den HMS GUI pakken, samt RemoteController klassen. Denne klasse står for forretningslogikken til at styre den information, som skal sendes til HMS Mobil Klient. Kommunikationen sker over en Bluetooth forbindelse, som tilgås gennem UART bussen i HMS Communication pakken Sune Høffding Hedetoft Side 7 af 19

10 HMS MeasurePoint Pakken har ansvaret for at holde styre på alle de måleenheder som systemet kan supportere, samt opsamling af målingerne. Figur 6 Klassediagram over pakken HMS MeasurePoint Systemet supporterer en række måleenheder, som er angivet i denne pakke. Alle enheder afledes fra MeasaurePoint klassen. MeasurePoint klassen indeholder en arraylist med de sidste ti målinger for hver enhed. En måling er af typen Measaurement. Fra measurepoint er det derfor muligt at få den nyeste måling samt de sidste ti målinger. Da systemet har forskellige temperaturføler, er disse afledt af klassen Temperature. Temperaturfølerne anvender I2C bussen og kører deres egen tråd, som derved henter en ny måling ved et bestemt interval. Alarm klassen anvender SPI bussen, mens de resterende enheder Door, Window, og Light anvender GPIO (Input/Output) bussen. Fælles for disse enheder er at de abonnerer på et event i HMS Communication pakken, som fyres når der sker en ændring som f.eks. hvis en dør låses eller omvendt Sune Høffding Hedetoft Side 8 af 19

11 3.1.3 Data Access Layer Laget består af én pakke som har ansvaret for at kommunikere til de perifere enheder, samt bluetooth modulet, som er installeret på forskellige busser på HMS konsolen. Figur 7 Klassediagram over pakken HMS Communication Systemet anvender en række busses, som er implementeret på dette lag. Fælles for alle busser er at de er afledt fra BUS, som er en abstrakt klasse, der har to abstrakte funktioner (Write, Read). Herunder er der udtaget koden for hvordan de forskellige busser sættes op i.net Micro Framework Sune Høffding Hedetoft Side 9 af 19

12 UARTBus opsætning: Til at kommunikere over en bluetooth forbindelse er der anvendt en RS232 bluetooth adapter. På Tahoe kortet er UART1 forbundet til en RS232 transivere. Kommunikationen til denne sker gennem en seriel comport (COM1) og kan sættes op på følgende måde: SerialPortObj = new SerialPort(portName, 9600, Parity.None, 8, StopBits.One); SerialPortObj.Open(); SerialPortObj.DataReceived += new SerialDataReceivedEventHandler(this.SerialData); Der abonneres på et event, som bliver kaldt, når der modtages data. I2CBus opsætning: I2C bussen anvendes af temperaturfølerne. Der er to vigtige parameter for opsætning af I2C bussen. Adresse på enheden som der skal kommunikeres med samt clockfrekvensen. Herunder ses instansiering af I2C bussen. Microsoft.SPOT.Hardware.I2CDevice.Configuration config = new Microsoft.SPOT.Hardware.I2CDevice.Configuration(adresse, clockratekhz); this.device = new Microsoft.SPOT.Hardware.I2CDevice(config); SPIBus opsætning: For hver SPI enhed der skal kommunikeres med, skal der oprettes en instans af SPI klasen. Klassen modtager en SPI.Configuration inner class i dens konstruktor. Herunder ses hvordan opsætning af SPI bussen sker. SPI.Configuration config = new SPI.Configuration( chipselectpin, //chip select port false, //IC is accessed when chip select is low 1, //setup time 1 ms, is actually min 10 ns 1, //hold chip select 1 ms after transfer true, //clock line is high if device is not selected false, //data is sampled at falling edge of clock clockratekhz, //clock rate in khz spimodule //select SPI bus ); this.spibus = new SPI(config); GPIOBus opsætning: I systemet er der anvendt en række Input/output (GPIO) pins til at indikere om døre og vinduer er åbne eller låst, og om lyset er tændt eller slukket. Alle pins er sat til interrupt mode, som betyder at der bliver kaldt et OnInterrupt event, når der kommer et signal på en pin. InterruptPort gpiointerrupt = new InterruptPort( pin, //Pin number false, //Glicth filter Port.ResistorMode.PullUp, //Resistor mode Port.InterruptMode.InterruptEdgeHigh //Interrupt mode ); gpiointerrupt.oninterrupt += new NativeEventHandler(interrupt_OnInterrupt); Sune Høffding Hedetoft Side 10 af 19

13 3.2 HMS Mobil Klient Er et Windows Mobile projekt som er udviklet i.net Compact Framework 3.5 og er en mobil udgave af enheden i hjemmet (HMS Konsol), som gør det muligt at se de enkelte sensorers status. Der kommunikeres med HMS Konsol via Bluetooth, hvor data omkring de enkelte sensorer opdateres når deres værdier ændrer sig. Figur 8 viser den overordnede designstruktur for HSM Mobil Klient projektet. Presentation Layer GUI Business Layer SensorController Data Access Layer Data Layer Mobile Communication Legend Egenudviklede pakker og klasser Eksterne Pakker og klasser Interfaces Bluetooth Ekstern Hardware Figur 8 HMS Mobil Klient pakkediagram De enkelte lag og pakker forklares i efterfølgende afsnit Sune Høffding Hedetoft Side 11 af 19

14 3.2.1 Presentation layer GUI delen er lavet med henblik på anvendelse på mobil med touchskæm. Brugeren kan se de forskellige målere der er installeret i huset og trykke sig ind på de enkelte følere for at se deres værdier/status. Presentation Layer GUI Forms HomeForm SetupForm TemperaturesForm «interface» IState 1 * WindowsForm DoorsForm LightsForm «creates» State Business Layer SensorController Figur 9 Klassediagram over pakken GUI GUI laget et opbygget med en state pattern, som søger for et let skift mellem de forskellige Forms som brugeren bliver præsenteret for. Dette pattern medvirker også til at der fra hvilket som helst Form vindue kan skiftes til et andet Sune Høffding Hedetoft Side 12 af 19

15 3.2.2 Business layer Business laget står for oprettelsen af de forskellige sensorer, samt opdatering af sensorernes værdier/status. Figur 10 viser et klassediagram over Business laget. Figur 10 Klassediagram over pakken SensorController SensorController holder styr på de enkelte Sensor objekter og GUI pakken anvender denne til opdatering af sensorer værdier. Sensor er en global klasse som indeholder et antal properties, når der sendes data fra HMS Konsollen serialisieres Sensor objektet og deserialiseres igen på HMS Mobil Klient siden Sune Høffding Hedetoft Side 13 af 19

16 3.2.3 Data Access layer Laget håndterer den indkommende data fra HMS Konsollen og forbereder dataene til Business laget. Figur 11 Klassediagram over pakken Mobile Communication CommunicationProtocol (CP) modtager og deserialiserer data fra HMS Konsollen, som herefter anvendes til at oprette sensorer og opdatere deres værdier/status. CP tilbyder et event til håndtering af modtaget data. Ved at benytte sig af dette event, kan systemet let udbygges til at kommunikere med andre enheder end seriel (Bluetooth) Sune Høffding Hedetoft Side 14 af 19

17 4 Resultat og test I dette afsnit præsenteres testresultaterne for det udviklede produkt. Testen er udført som en brugertest, hvor de ønskede krav til systemet opstilles og der indikeres om kravene opfyldes Tabel 1 Brugertest resultat Aktion/Input HMS Konsol: 1) Ved Systemopstart præsenteres brugeren for et grafisk design, hvor der ved hjælp af touchscreen knapper, kan vælges mellem de sensortyper der ønskes at se nærmere på. 2) Ved tryk på Doors præsenteres brugeren for en menu med status på alle tilmeldte dør-sensorer. Sensorerne opdateres løbende. 3) Ved tryk på Windows præsenteres brugeren for en menu med status på alle tilmeldte vindue-sensorer. Sensorerne opdateres løbende. 4) Ved tryk på Lights præsenteres brugeren for en menu med status på alle tilmeldte lys-sensorer. Sensorerne opdateres løbende. 5) Ved tryk på Temperatur præsenteres brugeren for en menu med status på alle tilmeldte lys-sensorer. Sensorerne opdateres løbende. 6) Det er muligt for brugeren, på alle undermenuer, at gå tilbage til Hovedmenu ved at trykke Back på hver menu billede. HMS Mobil Klient: 1) Ved applikationens opstart er det muligt at vælge Connect, hvorpå klienten opretter forbindelse til HMS Konsol. 2) Efter oprettelse af forbindelse til HMS konsol, præsenteres brugeren for et grafisk design, hvor der ved hjælp af touchscreen knapper, kan vælges mellem de sensortyper, der ønskes at se nærmere på. 3) Ved tryk på Doors præsenteres brugeren for en menu med status på alle tilmeldte dør-sensorer. Sensorerne opdateres løbende. 4) Ved tryk på Windows præsenteres brugeren for en menu med status på alle tilmeldte vindue-sensorer. Sensorerne opdateres løbende. 5) Ved tryk på Lights præsenteres brugeren for en menu med status på alle tilmeldte lys-sensorer. Sensorerne opdateres løbende. 6) Ved tryk på Temperatur præsenteres brugeren for en menu med status på alle tilmeldte lys-sensorer. Sensorerne opdateres løbende. 7) Ved tryk på Setup præsenteres brugeren for en menu med setup, hvor det er muligt at vælge den COM port, hvorpå HMS Konsollens bluetooth modul er parret. 8) Det er muligt for brugeren, på alle undermenuer, at gå tilbage til Hovedmenu ved at trykke på Back. Resultat Sune Høffding Hedetoft Side 15 af 19

18 4.1 Diskussion af opnåede resultater Som det kan ses på testen, lever det endelige produkt op til forventningerne, der blev sat op ved projektets start. Der har dog været flere komplikationer undervejs, som beskrives i afsnit 5. 5 Opnåede erfaringer 5.1 Tahoe touchscreen events Tahoe touchscreen displayet har vist sig vanskelig, i forbindelse med håndtering af events, oprettet på forskellige menuer (Windows). Problemet var at gamle registrerede events, virkede som om de ikke unsubscribede korrekt og generede mærkelige eksekveringer af efterfølgende nye events. Her blev gamle abonnerede events vilkårligt kaldt i stedet for det aktuelle abonnerede event. Problemet blev antaget som et garbage collect problem og en dårlig disposing/unsubsribing af eventene. Mange løsninger på at unsubscribe korrekt og abonnere nye events blev forsøgt uden held. I sidste ende viste problemet sig at være at være en ukorrekt håndtering af det aktive Window objekt i Application instansen, der herved gav lejlighed til de mystiske klik events på andre menupunkter end det viste. 5.2 Invalid Operation Exception Udviklingen af det grafiske layout på til HMS Konsollen i Micro Frameworket gav i begyndelsen mange uforståelige exceptions af typen Invalid Operation Exception. Gruppen var af den opfattelse at det var manglende forståelse for strukturen af Window og Paneler i forbindelse med parent og children strukturen. Det har derfor været forsøgt anvendt flere forskellige GUI designs undervejs med bl.a. state machine og model view Presenter (MVP), men i sidste ende er en State struktur anvendt, da denne gav det mest overskuelige design, projektets størrelse taget i betragtning. 5.3 Serialisering mellem Compact - og Micro Framework Da der i projektet kommunikeres mellem CF og MF var det ønskeligt at oprette nogle globale objekter og serialisere dem, samt sende dem fra HMS Konsol(MF) til HMS Mobil Klient(CF). Det viste sig at MF understøtter binær serialisering, hvilket CF ikke gør. Der blev herefter forsøgt med XML serialisering, hvilket CF understøtter, men det viste sig at det gjorde MF ikke. Det hele ledte til en del frustration og det blev herefter valgt at oprette de globale objekter, som skulle serialiseres og sendes fra MF til CP, og manuelt serialisere dem i en XML streng. Det var så muligt på CP siden at deserialisere dem og få fat i de globale objekter. 5.4 MF og 1-Wire Det var under projektet en plan at anvende en temperatursensor baseret på 1-Wire kommunikation, men ved nærmere undersøgelse af 1-Wire på Micro Frameworket, har det vist sig at udviklere oplever store problemer med dette pga. timingskravene ikke kan overholdes af Micro Frameworkets timere (Bánský, 2007). Det blev derfor besluttet ikke investere tid på 1-Wire Sune Høffding Hedetoft Side 16 af 19

19 6 Konklusion Det er gruppens opfattelse at projektet er forløbet godt og at resultatet lever op til den opstillede problemstilling. Der er under projektet arbejdet med mange forskellige emner, heriblandt Micro Frameworket, hvor der er blevet arbejdet med grafisk brugergrænseflade, touchscreen, I2C, UART, GPIO, SPI og flertrådsprogrammering. Der er også anvendt Compact Framework i form a HMS Mobil Klienten, hvor der bl.a. er anvendt grafisk brugergrænseflade og Bluetooth via serial port. Arbejdet med alle disse områder har givet en bred erfaring med embeded Windows programmering, som kan anvendes i fremtiden. Projektet har derved været en yderst lærerig proces. Gruppen er desuden fascineret af hvordan managed code har fundet vejen ned til hardware nære komponenter. Det giver en utrolig fleksibilitet og tillader udvikling af systemer med masser af funktionalitet på ganske kort tid. 6.1 Fremtid Udvidelser af projektet er mange, men et emne som persistering af enheder og data har top prioritet, da systemet på nuværende tidspunkt skal opsættes fra bunden ved hver genstart og ikke kan opbevare historik. Som andre udvidelser kan forbindelsen til HMS Mobil Klienten udvides med forbindelse via Internettet så oplysningerne kan ses overalt. Muligheden for at styre varmeapparater og slukke/tænde lys er også oplagte udvidelser af systemet Sune Høffding Hedetoft Side 17 af 19

20 7 Bilag 7.1 Figurliste Figur 1 Illustration af Home Mangement System (HMS)... 3 Figur 2 HMS Blokdiagram... 4 Figur 3 Pakkediagram HMS Konsol... 5 Figur 4 Klassediagram over pakken HMS GUI... 6 Figur 5 Klassediagram over pakken HMS Controller... 7 Figur 6 Klassediagram over pakken HMS MeasurePoint... 8 Figur 7 Klassediagram over pakken HMS Communication... 9 Figur 8 HMS Mobil Klient pakkediagram Figur 9 Klassediagram over pakken GUI Figur 10 Klassediagram over pakken SensorController Figur 11 Klassediagram over pakken Mobile Communication Tabelliste Tabel 1 Brugertest resultat Diagram farve betegnelser 7.4 Billeder af HMS HMS Konsol Sune Høffding Hedetoft Side 18 af 19

21 7.4.2 HMS Mobil Klient Sune Høffding Hedetoft Side 19 af 19