Omsorgsbasert Sengevekt - HVLhome.hvl.no/ai/elektro/2016/BO16E-25.pdf · Omsorgsbasert Sengevekt Rev: v1.2 3(62) 06.06.16 Forord Denne bacheloravhandlingen er en videreutvikling av

OMSORGSBASERT SENGEVEKT

[email protected];[email protected];Joakim.Vindenes@stu

d.hib.no;[email protected]

13HEEL

6. juni 2016

Dokumentkontroll

Rapportens tittel:

BOE16E-25-Sengevekt Dato/Versjon

06.06.16/v1.2 Rapportnummer:

Forfatter(e):

Daniel Rene Kleppe Oppegaard Ove Lylund Joakim Vindenes Muhamed Ali Ahmed

Studieretning: 13Heel

Antall sider m/vedlegg

62

Høgskolens veileder:

Svein Haustveit [email protected]

Gradering:

Eventuelle Merknader:

Oppdragsgiver: Høgskolen i Bergen

Oppdragsgivers referanse:

www.hib.no

Oppdragsgivers kontaktperson(er) (inklusiv kontaktinformasjon): Geir Omar Berland [email protected]

Revisjon Dato Status Utført av

v.0.01 14.03.16 Førte inn innhold fra Midtveisevalueringen Joakim Vindenes

v.0.02 18.05.16 Førte inn IPK, Main, Sqlite, testing av TCP/IP, modulen, forord og sammendrag.

Muhamed Ali Ahmed

v.0.03 31.06.16 Førte inn deler av realiseringen Muhamed Ali Ahmed

v.0.04 02.06.16 Førte resten av løsningsalternativ Muhamed Ali Ahmed

v.0.05 02.06.16 Små endringer Muhamed Ali Ahmed

v.0.06 02.06.16 Ført inn realisering av analog del Ove Lylund

v.0.07 03.06.16 Redigering av Design løsning 1 Ove Lylund

v.0.08 03.06.16 Korrektur og små endringer Muhamed Ali Ahmed

v.0.09 03.06.16 Korrektur fra toppen Ove Lylund

v.0.10 03.06.16 Lagt til alt i testing bortsett fra TCP/IP Daniel Oppegaard

v.0.11 04.06.16 Importert modulbeskrivelse, retting Ove Lylund

v.1.0 05.06.16 Ferdig rapport Ove Lylund

v.1.1 06.06.16 Rettet opp i formateringsfeil Ove Lylund

v.1.2 06.06.16 Formateringsfeil og skrivefeil Daniel Oppegaard

Omsorgsbasert Sengevekt

Rev: v1.2 3(62) 06.06.16

Forord Denne bacheloravhandlingen er en videreutvikling av en tidligere bacheloroppgave fra 2015,

«Veicellebasert system for omsorgsteknologi». Etter tre år på elektronikk-avdelingen ved Høgskolen i

Bergen, valgte vi å ta denne oppgaven som avsluttende hovedoppgave. Dette prosjektet vekket

interesse hos oss, på grunn av sin unike problemstilling som bygger en bro mellom elektronikkverden

og helsebransjen. For oss handlet det også om å ta utfordringen om å bygge et system fra grunnen

av, der problemstillingens løsning består av flere fagelementer fra datafag og elektronikk. Arbeidet

med oppgaven har vært en utrolig lærerik, utfordrende og til tider frustrerende prosess.» Det

oppstod ofte vanskelige situasjoner, men ved å jobbe sammen klarte vi å overkomme alle hinder.

Dette ga oss inspirasjon, og vi fikk utvidet horisontene våre. I løpet av utviklingsprosessen har vi

tilegnet oss mye faglige kunnskap. Vi har også lært mye om oss selv og hverandre, i tillegg til å fått

erfart hvordan et godt samarbeid kan løse komplekse problemer.

Vi vil bruke denne anledningen for å takke vår veileder Svein Haustveit og oppdragsgiver Geir Omar

Berland, for hjelpen og veiledningen de har gitt oss.

Videre vil takke Atilla Gunhan for tips og råd i starten, Farzan Jouleh som lånte oss lab-fasiliteter samt

nødvendig utstyr. Takk til Adis Hodzic som tok seg tid til å lære oss om trådprogrammering.

Vi er veldig takknemlige og ydmyke for støtten Nils Jacob Berland har gitt oss. Tusen takk for utrolig

bra veiledning, støtte og engasjement, med dine råd klarte vi å få skuten på rett kurs når ting gikk

dårlig.

Takk til våre familier og venner som har vært tålmodige med oss gjennom disse tre årene.


Rev: v1.2 4(62) 06.06.16

Sammendrag Denne hovedoppgaven omhandler et omsorgsbasert smart-system, laget fra grunnen av for å

imøtekomme utfordringer i omsorgs- og helsebransjen. Dette prosjektet er en rekonstruksjon og

videreutvikling av en lignende bacheloravhandling fra 2015. Målet med denne oppgaven er å lage en

komplett løsning, for personer boende i helse eller omsorgs-institusjoner. Produktet skal kunne

brukes både i offentlig og privat sektor. Fysiske skader som forekommer i disse bransjene, reduserer

livskvalitet og koster samfunnet store utgifter. Dette kan være skader som de eldre og de trengende

er utsatt for. Systemløsningen kan veie opptil to personer i en seng. Den kan også assistere

vedkommende med et automatisert, eksternt tilkoblet lys, som blir aktivert dersom noen beveger

seg ut av sengen. Systemet har også funksjoner som kan detektere epilepsi og logge vekt som blir

sendt til ekstern server. I denne bacheloroppgaven er både elektroniske komponenter og

programvarer som ble brukt i den tidligere oppgaven, byttet ut med nye, fleksible og billigere

løsninger.

Ifølge kravspesifikasjonene har vi klart å oppfylle alle punktene, utenom muligheten for å ha en

berøringsskjerm for konfigurasjon. Dette gikk vi bort fra fordi vi erstattet berøringsskjerm-løsningen

med et web-basert grafisk grensesnitt. Vi tok bort behandling og grafisk presentasjon av

søvnmønster funksjonen. Grunnen til dette var at, tolking av søvndata krever veldig komplekse

algoritmer, utviklingen av disse kunne være en egen oppgave i seg selv.

Med hensyn til kravspesifikasjonene, klarer systemet å:

Måle vekten til opptil to personer som befinner seg i sengen

Detektere epilepsianfall

Lagre ukentlig logg av vekt

Sende logget data ved forespørsel over internett, til ekstern server for videre behandling

Aktivere belysning i rommet dersom vedkommende beveger seg ut av sengen

Presentere systemets hovedfunksjoner ved hjelp av web-basert grafisk bruker grensesnitt

Det endelige resultatet av prosjektet vårt er oppnådd i henhold til kravene. Samspillet mellom

komponentene og programmodulene utfører oppgavene sine raskt og effektivt. På

kommunikasjonssiden med omverden sender programmet vårt nødvendige data både til klienten og

webleseren. Systemet virker sømløst, selv med billige komponenter klarer det å produsere gode

resultater.


Rev: v1.2 5(62) 06.06.16

1 Innhold Dokumentkontroll ................................................................................................................................... 2

Forord ...................................................................................................................................................... 3

Sammendrag ........................................................................................................................................... 4

1 Innledning ........................................................................................................................................ 8

1.1 Organisering av rapporten ...................................................................................................... 8

1.2 Oppdragsgiver ......................................................................................................................... 8

1.3 Problemstilling ......................................................................................................................... 8

1.4 Hovedidé for løsningsforslag ................................................................................................... 8

2 Kravspesifikasjon ........................................................................................................................... 10

2.1 Maskinvare ............................................................................................................................ 10

2.2 Programvare .......................................................................................................................... 10

2.3 Grensesnitt ............................................................................................................................ 11

3 Analyse av problemet .................................................................................................................... 11

3.1 Utforming av mulig løsning ................................................................................................... 11

3.1.1 Oppbygging av systemet ........................................................................................... 12

3.1.2 Løsnings alternativ styringsenhet .............................................................................. 12

3.1.3 Konklusjon ................................................................................................................. 13

3.2 Mulig utvidelse av oppgaven ................................................................................................. 13

3.3 Gjennomførbarhet ................................................................................................................ 13

4 Realisering av valgt løsning ........................................................................................................... 13

4.1 Første løsning ........................................................................................................................ 14

4.1.1 Blokkskjema til system .............................................................................................. 14

4.1.2 Analog ........................................................................................................................ 14

4.1.2.1 Hoved komponenter: ......................................................................................................... 15

4.1.3 Power distribution board .......................................................................................... 17

4.1.4 Montering i boksen ................................................................................................... 18

4.1.5 Design av software og drivere ................................................................................... 19

4.1.6 Windows Embedded (Windows IoT) ......................................................................... 19

4.1.7 .NET Framework ........................................................................................................ 19

4.1.8 Windows API.............................................................................................................. 20

4.1.9 Det interne nettverksproblemet ............................................................................... 20

4.1.10 Inter prosess kommunikasjon (IPK) metoder som ble utprøvd ................................ 20

4.1.11 Design av drivere ....................................................................................................... 23


Rev: v1.2 6(62) 06.06.16

4.1.12 Virkemåte og funksjoner for driver LYS ..................................................................... 23

4.1.13 Design av «Vektbehandling» ..................................................................................... 23

5 Kommunikasjon med GUI .............................................................................................................. 23

5.1.2 Design av Søvnmønster ............................................................................................. 24

5.1.3 Design av Epilepsi deteksjon modul .......................................................................... 24

5.1.4 Den opprinnelige GUI løsningen ................................................................................ 24

5.2 Andre løsningsalternativ ....................................................................................................... 25

5.3 Tredje og endelige løsningsalternativ ................................................................................... 26

5.3.1 Main ........................................................................................................................... 27

5.3.2 GPIO_init ................................................................................................................... 28

5.3.3 Globals variabel fil ..................................................................................................... 28

5.3.4 ADC-driver ................................................................................................................. 28

5.3.5 Lys-driver ................................................................................................................... 28

5.3.6 Epilepsi-driver ............................................................................................................ 28

5.3.7 Vektbehandling ......................................................................................................... 29

5.3.8 Person deteksjon ....................................................................................................... 30

5.3.9 ThrowAway filter ....................................................................................................... 30

5.3.10 Database lagring – Sqlite ........................................................................................... 30

5.3.11 Inter prosess kommunikasjon (IPK) ........................................................................... 31

6 Testing ........................................................................................................................................... 34

6.1 Hovedprogrammet ................................................................................................................ 34

6.1.1 ADC-driveren ............................................................................................................. 35

6.1.2 Vektbehandling ......................................................................................................... 36

6.1.3 Lysdriver .................................................................................................................... 36

6.1.4 Epilepsi....................................................................................................................... 36

6.2 Test av hovedprogrammet .................................................................................................... 37

6.2.1 Test av ADC driver og vektbehandlings program ...................................................... 37

6.2.2 Test av lysdriver ......................................................................................................... 38

6.3 Grafisk bruker grensesnitt ..................................................................................................... 38

6.3.1 Funksjonene bak knappen «Hent Vekt» ................................................................... 40

6.3.2 Funksjoner bak knappene Person A/Person B .......................................................... 42

6.3.3 Funksjoner bak knappene epilepsi av/på for «Person A» og «Person B» ................. 43

6.3.4 Modul Piping ............................................................................................................. 45

6.4 Slutt test (komplett system test) ........................................................................................... 45


Rev: v1.2 7(62) 06.06.16

6.5 Test av komplett system ....................................................................................................... 45

6.5.1 Konklusjon komplett systemtest ............................................................................... 49

6.6 TCP/IP Server ......................................................................................................................... 50

7 Diskusjon ....................................................................................................................................... 50

7.1 Vurdering av fremdriftsplanen .............................................................................................. 50

7.2 Windows IoT og Raspberry Pi 2 ............................................................................................. 50

7.3 Linux og Raspberry Pi 2 ......................................................................................................... 51

7.4 Risikoliste evaluering ............................................................................................................. 51

8 Konklusjon ..................................................................................................................................... 52

Litteraturliste ............................................................................................................. 54

Forkortelser og ordforklaringer ................................................................................. 55

Prosjektledelse og styring .......................................................................................... 56

C.1 Prosjektorganisasjon ............................................................................................................. 56

C.2 Prosjektform .......................................................................................................................... 56

C.3 Fremdriftsplan ....................................................................................................................... 57

C.4 Konklusjon ............................................................................................................................. 58

C.5 Risikoliste ............................................................................................................................... 58

Skjemadesign ............................................................................................................. 59

Tabell og figur liste .................................................................................................... 60

Innhold i zip-fil og plassering av programkode ......................................................... 62


Rev: v1.2 8(62) 06.06.16

1 Innledning

1.1 Organisering av rapporten

I denne rapporten har vi valgt å først introdusere fagterminologi med fult navn og forkortningen i

parentes på formen Analog Digital Converter(ADC), for så å bare bruke forkortningen i resten av

oppgaven.

Videre har henvisninger til litteratur gjort med referansestilen som f.eks (Lifehacker, 2011)

Henvisninger til andre kapitler i rapporten er gjort slik 4.1.2.1.1

Rapporten er inndelt slik at underkapitler står under relevant hovedkapittel.

Rapporten presenterer tre forskjellige løsningsalternativ av Software (SW), dette er for å gi innsikt i

endringene vi måtte gjøre underveis, og hvordan disse påvirket prosjektet.

1.2 Oppdragsgiver

Oppdragsgiveren er Høgskolen i Bergen, heretter kalt HIB. Med sine om lag 7700 studenter og 830

ansatte (Høgskolen i Bergen, 2016)består HIB av tre avdelinger, helse og sosialfag, ingeniør- og

økonomifag, og lærerutdanning. HIB ble etablert i 1994 (Wikipedia, 2015) Avdeling for ingeniør- og

økonomifag holder til på Campus Kronstad, som er HIB sin nye lokasjon.

1.3 Problemstilling

Fall og beinbrudd reduserer livskvalitet og krever store helse resurser fra helsevesenet. I dagens

sykehus og omsorgsboliger finnes det et stort forbedringspotensial ved å ta i bruk elektroniske

hjelpemidler. Når pasienter og eldre mennesker skal stå opp av sengen om natten, er det en viss fare

for at man kan falle og slå seg i mørket da lyset ikke slår seg på før vedkommende allerede er ute av

sengen. Ved utvikling av omsorgsteknologi kan dette forhindres dersom lyset slår seg på tidligere.

Dagens løsninger består av sensor i sengematter (registrerer når person er ute av sengen),

nattkamera (nattfrid) eller besøk av helsepersonell på nattestid som sjekker at vedkommende sover.

Sensorene merker ikke vibrasjon og kan derfor ikke registrere om det er en person eller en gjenstand

som ligger i sengen, heller ikke om pasienten opplever å få noe type anfall. Her er det rom for

forbedringer.

I forbindelse med velferdsteknologi er det behov for en smart seng. Det vil si en seng utstyrt med

sensorer som er i stand til å måle vekt, tilstedeværelse i seng og vibrasjon. Ved å introdusere vekt vil

vi kunne innhente verdifulle helseopplysninger i forhold til vektreduksjon, vektøkning,

tilstedeværelse osv.

Det finnes slike senger som er brukt i det profesjonelle markedet i dag, men det ønskes en lettere

utgave som kan brukes av hjemmeværende eldre med behov eller i mindre institusjoner.

1.4 Hovedidé for løsningsforslag

Fire veieceller plasseres under hvert sitt sengebein. Disse kobles til hver sin analog til digital

konverter (ADC) med forsterker. Signalene konverteres til digitale verdier ved hjelp av ADC. De

digitale verdiene leses av en prosesseringsenhet, som foretar nødvendige beregninger og behandling

av data. De nødvendige data vises på en nettleser, som også kan konfigurere enheten. Det kan også


Rev: v1.2 9(62) 06.06.16

brukes en berøringsskjerm til å konfigurere enheten og vise data. Systemet får strøm fra en

stikkontakt.

Systemet skal operere i normale omgivelser, det vil si romtemperatur mellom 18° C og 25° C. Dette

vil si at vi kan bruke hyllevare komponenter. Ettersom systemet er designet for anvendelse i

omsorgsbransjen, er det ingen krav for at systemet skal fungere under ekstreme forhold. ADC, level

converter og Raspberry Pi2 (RPI) enheten, ble plassert i en IP 66/65 sertifisert boks. Denne boksen

tåler kraftig vannspyling fra tre meters avstand med 100 kPa, opptil tre minutter. Boksen har flere

utganger for ekstern tilkobling. Ledningene fra veiecellene og Wireless Fidelity (WiFi) antennen

kobles til boksens tilkoblingspunkter. Boksen kan bli plassert under eller i nærheten av sengen.

Systemet i sin helhet skal måle vekten til personen som ligger i sengen, og gi et signal til et rele som

videre aktiverer et ekstern lys dersom personen beveger seg ut av sengen. Dette er den mest

essensielle funksjonen til systemet.

Hovedenheten i systemet er en RPI, dette er prosesseringsenheten der all programkode kjøres. RPI

enheten kan sammenlignes med en PC, bare i mindre dimensjon. Den kan enkelt kobles til eksterne

enheter. RPI er også ansvarlig for bearbeiding av rådataene som kommer fra ADC. Ved belastning på

cellene genereres analoge signaler. Disse signalene blir videre filtrert, forsterket og digitalisert.

Før de digitale signalene blir sendt for videre behandling av RPI, må spenningsnivåene reduseres.

Dette er for å unngå å skade RPI. Dette utføres av level converter.

For konfigurasjon av systemet benytter vi oss av en web basert Graphical User Interface (GUI). GUI

skal vise vekt, epilepsi deteksjon og vektendring. Brukeren skal også kunne:

Hente/Vise vekt

Kalibrere

Vise logg av vekt

Vise logg av epilepsi anfall og

Lagre vekt til to personer manuelt


Rev: v1.2 10(62) 06.06.16

2 Kravspesifikasjon Kravspesifikasjonen er utarbeidet av oss i gruppen i samarbeid med vår veileder og oppdragsgiver.

Det skal lages et helhetlig system der det skal plasseres fire vektceller under hvert sitt sengebein,

som skal kobles til en prosesseringsenhet. Løsningen skulle følge kravene 2.1-2.3, men ut over dette

var gruppen fri til å velge løsninger på detaljnivå.

2.1 Maskinvare 1. Veiecellene skal velges slik at de tåler å sitte under sengebeina til en standard sykehusseng,

mens det befinner seg en person oppe i senga.

2. Systemet skal ha en måte å vite dato og tid, etter at systemet har vært avslått.

3. Systemet skal kunne kobles til et WiFi nettverk.

4. Systemet skal bruke en strømforsyning som kobles til stikkontakt, som leverer 230v 50hz.

2.2 Programvare 1. Systemet skal kunne beregne vekt.

2. Systemet skal kunne indikere at en person er i ferd med å gå ut av senga.

3. Systemet skal kunne skille mellom 2 ulike personer basert på ulik vekt.

4. Systemet skal kunne indikere at personen i senga opplever et epilepsi anfall, som

resulterer i voldsomme bevegelser på 2-5 Hertz.

5. Systemet skal kunne indikere unormal vektendring for de lagrede personene.

6. Systemet skal kunne indikere relativ søvnkvalitet.

Figur 1 Originalt system oppsett


Rev: v1.2 11(62) 06.06.16

2.3 Grensesnitt

1. Systemet skal kunne konfigureres via en liten berøringsskjerm.

2. Systemet skal kunne konfigureres via en GUI som er tilgjengelig via en nettleser.

3. Systemet skal kunne indikere at en person er på vei ut av senga, ved å signalisere med et

logisk ut signal.

3 Analyse av problemet Her vil vi presentere ulike løsningsalternativer, som vi kom frem til i forstudiet. Grunnet stor frihet i

valg av løsning, vil alle løsningsalternativene oppfylle kravspesifikasjonen, men løsningene har

forskjellig vanskelighetsgrad. Der det er presentert flere løsningsalternativer, har vi vurdert det første

som det beste, men vanskeligste løsningsforslaget. De alternative løsningene kan være enklere for å

oppnå ønsket resultat. I tillegg presenteres noen ekstra løsninger som vi vil prøve å realisere dersom

det er tid. Disse ekstra løsningene er ikke beskrevet i kravspesifikasjon, men er for å øke

læringsutbyttet av oppgaven.

3.1 Utforming av mulig løsning Hovedfokuset vårt var å lage et brukervennlig og pålitelig system, som skal kunne betjenes av alle.

Det var derfor viktig at vi hadde en god plan for oppbygging av systemet, slik at vi fikk avlest korrekt

data, samt lagre og behandle data på best mulig måte. Vi måtte også ta hensyn til tidsbegrensning og

kostnader.

Systemet består av:

Sensor (vekt celle)

Analog filter og forsterker

ADC

Styringsenhet Field Programmable Gate Array (FPGA), mikrokontroller eller RPI

Touch-skjerm for konfigurasjon av systemet

Trådløs kommunikasjon (WiFi)


Rev: v1.2 12(62) 06.06.16

Figur 2 Blokkdiagram av systemet

3.1.1 Oppbygging av systemet

Vi fikk utdelt fire vektsensorer av skolen som skulle plasseres under hvert sengebein. Dette ga oss

muligheten til å måle vekten av pasienten til enhver tid. Siden sensorene sendte ut analoge signaler

måtte vi ha en ADC per celle, slik at styreenheten kunne lese og prosessere signalene. Vi trengte også

et lavpass filter som fjernet høye frekvenser, samt en signal forsterker som gjorde det mulig å lese av

detaljerte verdier. Etter signalet har gått igjennom filteret, forsterkeren og ADC, blir det digitale

signalet lest og prosessert av styringsenheten.

3.1.2 Løsnings alternativ styringsenhet

Siden vi hadde tidsbegrensning på et semester og et lite budsjett, var det kritisk at vi valgte riktig

styringsenhet. Ette mye undersøking kom vi frem til tre forskjellige styringsenheter som vi kunne

bruke. Disse var FPGA, Arduino-mikrokontroller eller RPI.

FPGA

En FPGA er en kraftig og allsidig styreenhet. Siden den kan utføre oppgaver parallelt, har den en stor

fordel med at den behandler data raskt. Den er også allsidig med tanke på at man lett kan gjøre

endringer i hardware (HW), uten å bytte komponenter. Selv med disse fordelene, vil det ikke svare

seg med en slik styringsenhet i vårt prosjekt. Denne enheten er unødig rask og relativt dyr for vårt

formål, i tillegg er den krevende å programmere.

Arduino mikrokontroller

Arduino er en open-source platform som blir brukt i mindre elektronikk prosjekter. Den har ikke

operativsystem og den kan enkelt programmeres i C, et språk vi behersker bra. Den har lavt

strømforbruk, høyt antall GPIO og den er veldig billig. På den andre siden, har den lite minne og

prosesseringskraft, noe som gjør den mindre egnet for vårt prosjekt.

Vektceller

AD-modul

Raspberry pi

Lagrings

database

Avlesning via

HTML-side

Kontrollmodul

(touch skjerm)


Rev: v1.2 13(62) 06.06.16

Raspberry PI 2

RPI er laget som en liten datamaskin og kjører et operativsystem. Den er mye raskere enn Arduino,

samt den har adskillig mer minne. Den er fleksibel med tanke på at man lett kan utvide med ekstern

skjerm og WiFi. Den koster noe mer enn Arduino, men er vesentlig billigere enn en FPGA. Ulempen

med RPI er at den er krevende å programmere, siden vi har lite kjennskap til den fra før av. Den

trekker også mer strøm enn Arduino.

3.1.3 Konklusjon

Vårt prosjekt krever middels databehandlingskraft, data overføring via WIFI, og et brukervennlig

Interface. Derfor valgte vi RPI.

3.2 Mulig utvidelse av oppgaven

Dersom man blir ferdig med alle punkter i kravspesifikasjonen, kan en bruke tid på å gjøre produktet

mer kommersielt. Det vil si at vi må lage et representativt design på sengen, der alle enheter og

sensorer er integrert eller skjult i sengen. Det kan også være muligheter for å skifte ut veiecellene

med noen som er mindre, samt mulig å få hjul på sengen. Dersom vi fortsatt har mer tid til overs kan

en designe og utvikle ADC, filter og forsterker som fungerer bedre til vårt prosjekt.

3.3 Gjennomførbarhet

Prosjektet vårt hadde en tidsbegrensning på et semester. Det var derfor avgjørende at vi kommer så

raskt i gang med bestillingen av komponentene. Siden vi allerede har fått lånt veieceller av skolen

sparte vi en del tid. RPI var lett å kjøpe ettersom den kunne bestilles fra Norge, dette medførte at vi

ikke ble forsinket på grunn av lang leveringstid. Andre komponenter som ADC, WiFi-adapter, filter og

forsterker ble bestilt fra utlandet. Dette gjorde vi fordi utvalget i norske butikker er dårlig, samt vi får

en rimeligere pris. Ulempen var derimot at vi fikk lang leverings tid, rundt to til fire uker.

4 Realisering av valgt løsning Ved å analysere problemstillingen, er det valgte løsningsalternativet syntetisert av flere moduler,

hovedsakelig bestående av HW og SW. HW modulen er et nettverk bestående av nødvendige

elektroniske komponenter og en prosesseringsenhet. Denne modulen har ikke blitt endret på etter

første løsning. Utdataene fra HW modulen blir videre behandlet i SW modulen. Modulen består av

flere kildekoder, og har en modulær oppbygning.

I motsetning til HW modulen, har SW modulen gått igjennom tre store forandringer. Disse

forandringene blir beskrevet i kommende underkapitler. Grunnen til disse forandringene er

hovedsakelig, tekniske utfordringer og begrensninger vi har møtt underveis. Alle designene var godt

gjennomtenkt og optimalisert, men likevel viste det seg at de ikke var realiserbar. Problemene vi

møtte underveis var grunnet ukjente programmeringsspråk og plattform restriksjoner. Vi måtte gjøre

tiltak for å overkomme hindringene.


Rev: v1.2 14(62) 06.06.16

4.1 Første løsning

4.1.1 Blokkskjema til system

Dette blokkskjemaet viser en kort oversikt over hvordan vi har brutt ned systemet.

Figur 3 Kort systemoversikt (løsning 1)

4.1.2 Analog

Her er detaljene rundt det analoge systemet, brutt ned i mindre moduler. Dette vises i blokkskjemaet

under.

Figur 4 Grov oversikt, analogt blokkskjema

ADC-modul

Veieceller

Level

konverter

RPI Monitor

Analog

Software

GUI


Rev: v1.2 15(62) 06.06.16

4.1.2.1 Hoved komponenter:

4.1.2.1.1 L6E3-C3/C4-100kg-3G og YZC-131» 1kg

Lastcellene har en enkel, men effektiv virkemåte. De består av fire strekklapper, som er plassert på

øvre og nedre del av en aluminiums klosse. Ettersom kun den ene siden av klossen blir utsatt for

vekt, vil den bøye seg. Dette skaper motstandsendring i strekklappene som er koblet sammen i en

målebro. Ved å tilføre forsyningsspenning over målebroen, vil en kunne detektere variasjon i

spenning, som er tilnærmet lineær med bøyingen på aluminiums klossen.

Siden skolen allerede hadde fire lastceller som vi kunne bruke til vårt prosjekt, var det et naturlig valg

å bruke de om våre krav ble oppfylt:

Skal være så lineære som mulig (avvik maks ± 500 gram)

Skal tåle 150 kg pr veiecelle.

Skal ikke være for stor og klumpete.

Bortsett fra at cellene er unødvendig store, er cellene godt innenfor kravene. Fra databladet kan vi se:

Combined error (linearitet): % maksimal ulinearitet < 0.0230

Safe overload: 150 kg

Ultimate overload: 300 kg

Sensitivity: 2.0 ± 0.2 𝑚𝑉

𝑉

Dette er langt innenfor det vi mener er akseptabelt. Dersom man veier 100 kg vil det kun gi oss en

feil på 100 𝑘𝑔∗0.0230

100= 23 gram. Veiecellene vil også tåle 300 kg før de blir ødelagt.

Ut i fra disse måledataene, mener vi lastcellene er godt egnet for dette prosjektet.

For å gjøre simuleringen lettere, lagde vi en liten modell av sengen, der vi byttet ut veiecellene med noen mindre. Dette gjorde testing og simulering mye lettere, med tanke på praktiske årsaker. Vi kjøpte derfor fire «YZC-131» 1 kg veieceller.

4.1.2.1.2 HX711 24-Bit Analog-to-Digital Converter

I hovedsaka består AD-modulen av en 24-bit ADC og en forsterker med variabel forsterkning: 32, 64

eller 128 𝑉

𝑉. Forsterkningen blir bestemt ved å sende ett visst antall pulser inn på pin PD_SCK. Siden

vi ønsker å detektere små signaler, bruker vi 128 𝑉

𝑉 i forsterkning. Dette betyr at vi må sende 25

pulser inn på PD_SCK. På grunn av at ADC har 24 bit betyr det at det er mye data som skal behandles. På den andre siden vil den gi stor oppløsning, noe som gjør at «resolution error» er ganske liten. I databladet kan vi sjå at dersom vi bruker 5V referansespenning og 128 i forsterkning blir «resolution error»:

𝑅𝑎𝑛𝑔𝑒

2^𝑏𝑖𝑡 =

5𝑉

128

2^24 =

39.06𝑚𝑉

2^24= 2,39

𝑛𝑉

𝑏𝑖𝑡

Dette betyr at man må ha en spennings endring på 2,39nV for at ADC skal få utslag. Dette resulterer i

en maksimal feil på 2,39𝑛𝑉

2,0𝑚𝑉±0,2𝑚𝑉∗ 100 = 0,000009958%

Ut i fra disse verdiene kan man se at det feilmarginen er så liten, at det ikke vil ha innvirkninger for vekt resultatet.


Rev: v1.2 16(62) 06.06.16

4.1.2.1.3 “Logic Level Converter Bi-Directional Module 5V to 3.3V”

Level konverteren består av en mos-fet transistor og to motstander. Dens oppgave er å konvertere

spenning opp eller ned, i vårt tilfelle fra 5 V til 3,3 V. Dette gjør vi fordi ADC sender ut logisk høy og

lav henholdsvis 5 V-0 V, mens input portene på RPI skal maks ha 3,3 V.

4.1.2.1.4 «Raspberry Pi 2 model B»

RPI modell B er en kraftig og liten mikroprosessor. Den har mange likheter med en vanlig pc bare at

den er mindre og svakere.

Spesifikasjoner:

900MHz quad-core ARM Cortex-A7 CPU

1GB RAM

4 USB ports

40 GPIO pins

HDMI port

(FOUNDATION, 2016)

Med sin raske prosesserings kapasitet vil ikke 24 bit x 4 veieceller x 80 samples pr sekund= 7,68 Kbps,

være noe problemer. Den er også fleksibel med tanke på at den har mange GPIO pins, USB porter og

HDMI. Det gjør at vi lett kan utvide med LCD skjerm og WiFi.

4.1.2.1.5 “2PCS DS3231 Real Time Clock modul”

Real time clock (RTC) modulen er en billig, men presis enhet. Den besår av en RTC chip, et lite minne

og et batteri. Dens oppgave er å gi presis dato og tid, selv om man opplever strømbrudd.

4.1.2.2 Oppkobling

Systemet ble koblet opp slik som Figur 51 viser. Vi kjøpte en liten boks hvor vi monterte alle

komponentene. Boksen skal festes/monteres under sengen, og alle kabler fra veiecellene skal trekkes

gjennom sengen benene, slik at de er skjult og beskyttet.

4.1.2.3 Realisering av analoge komponenter

Etter en lang periode med undersøking og planlegging, kunne vi endelig starte oppbyggingen av

systemet. Først måtte vi gjøre klar komponentene til oppkobling. Dette innebar å lodde på

tilkoblingskontakter, skjold og lage et Power distribution board. Vi var heldige og fikk låne lodde

labben på skolen, der hadde vi tilgang på det utstyret vi trengte.

4.1.2.3.1 Lodding av tilkoblingskontakter og skjold

Alle komponentene kom uten ferdig monterte tilkoblingskontakter, ADC modulene var også uten

skjold, som skal skjerme for elektromagnetisk støy. Figur 6 og Figur 5 viser komponentene før

lodding. Montering av skjold er vanligvis ikke nødvendig, men siden komponentene ligger tett inntil

hverandre, kan det oppstå støy. For å unngå dette, valgte vi å montere skjoldet. Figur 8 og Figur 7

viser de ferdig modifiserte komponentene.


Rev: v1.2 17(62) 06.06.16

4.1.3 Power distribution board

Vi måtte også designe et «Power distribution board» som fordeler 5 volt, 3.3 volt og jord. Dette måtte vi gjøre fordi styringsenheten ikke har nok tilkoblingskontakter. Figur 9 viser designet, Figur 10 viser det ferdige kretskortet.

Figur 8, Level Converter med tilkoblingskontakter

Figur 7, AD-modul med tilkoblingskontakter og Shield

Figur 9, Kretstegning av Power distribution board

Figur 10, Power distribution board

Figur 6, AD-modul uten tilkoblingskontakter og Shield

Figur 5, Level konverter uten tilkoblingskontakter


Rev: v1.2 18(62) 06.06.16

4.1.4 Montering i boksen

Siden vi ønsket at boksen skal være så liten som mulig lagde vi to monteringsplater, som gjorde det

mulig å montere komponenter i to etasjer. Platen kuttet vi til av plastikk, og den blir klemt fast av

boksen. Vi måtte også lage hull til gjennomføring av kabler. Boksen kommer med gummi som man

selv skal kutte, dersom hullene blir kuttet i mindre diameter enn kabelen, vil ikke vann eller støv

trenge inn gjennom gjennomføringene.

Siden styringsenheten genererer en del støy, ønsket vi den lengst mulig bort fra komponentene som

er koblet til veiecellene. Derfor monterte vi styringsenheten og RTC-modulen i øverste etasje, mens

de andre komponentene er i underetasjen. Denne løsningen vil også gjøre det lettere å komme til

styringsenheten, dersom man ønsker å kommunisere via HDMI eller ethernetkabel. Som ledninger

mellom komponentene kjøpte vi «hun til hun» DuPont ledninger. Disse ledningene har kort lengde

og forskjellige farger, som gjør det lettere å holde oversikten.

Figur 11, Lukket boks Figur 12, 2. etasje boks

Figur 13, 1. etasje boks


Rev: v1.2 19(62) 06.06.16

4.1.5 Design av software og drivere

Figur 14, Første SW løsning

Blokkdiagrammet Figur 14, viser oppgavens første løsningsforslag for SW delen. Dette var vår

originale SW arkitektur. Programmet skulle implementeres med Windows IoT platform, og kjøres på

RPI. GUI problematikken skulle løses ved hjelp av programmeringsspråket C#. Dette programmet

skulle presentere brukeren det grafiske grensesnittet, med alle mulige konfigurasjoner og

innstillinger. Videre skulle C# programmet kommunisere med resten av modulene, via en

kommunikasjons fil. Vi gjorde stor progresjon med dette designet, inntil vi møtte et problem med

interprosess kommunikasjon. Dette satte en stopper for videre fremdrift i utviklingen, og bydde på

seriøse tidsproblemer. Med ingen kommunikasjons mellom GUI og resten av programmet, var det

umulig å sende data til brukeren fra C++ programmet til GUI. I avsnittene under vil vi se nærmere på

oppbygningen av SW.

4.1.6 Windows Embedded (Windows IoT)

Windows IoT tidligere Windows Embedded, er et av Microsofts operativ systemer for innebygd

systemer. Windows IoT er designet for at en skal kunne bygge et system, eller et produkt koblet

sammen av flere elektroniske enheter og programmer. Koblingsnettverket kan både være lokalt eller

eksternt, derav navnet IoT «Internet of Things». IoT er en optimalisert versjon av Windows 10, egnet

for mindre krevende innebygd systemer. For å skrive programmer på IoT plattformen, benyttes

Universal Windows Platform (UWP) Application Programmable Interface (API), som kan

programmeres med forskjellige programmeringsspråk. Visual Studio 2015 Community Edition

inneholder de fleste av disse språkene.

4.1.7 .NET Framework

.Net Framework er et rammeverk utviklet av Microsoft, for å forenkle utvikling av applikasjoner. Det

består av «Application Framework Library» og «Common Language Runtime». Rammeverket

inneholder mange nyttige og gode funksjoner, som man kan kalle uten behov for å lage de selv.

Biblioteket inneholder også forhånds definerte funksjoner og klasser. .Net blir mest brukt av

profesjonelle program utviklere. Dessuten må det følges visse standard prosedyrer og

fremgangsmåter, dersom man skal skrive applikasjonskoder for .Net


Rev: v1.2 20(62) 06.06.16

4.1.8 Windows API

Alle kjerne API laget av Microsoft, er samlet i Windows API biblioteket. Biblioteket består blant annet

av grensesnitt, som nettverk, grafikk, «shell» og noen andre API. I dette biblioteket finner vi de

viktigste API for program utvikling på Windows IoT.

4.1.9 Det interne nettverksproblemet

For å utveksle data trenger programmodulene et kommunikasjonsnettverk. Da det midlertidige

oppsettet av GUI ble programmert, gjenstod det å foreta små tester for å sjekke forbindelsen mellom

C# og C++ modulene. To av felles ressursene C# utnytter .Net Framework og Windows API. Dessverre

benytter ikke IoT hele funksjonaliteten til .Net og Windows API. Da vi begynte å bruke IoT var det

under utvikling, og er i dag fremdeles under utvikling. Med tanke på C#s brukervennlighet for GUI

programmering, var det ikke tvil om å implementere det i RPI. Dersom vi hadde kun brukt C#, kunne

vi løse dette problemet veldig enkelt. Men i og med at vi skulle også lage raske og effektive drivere,

var C++ et bedre alternativ.

I senere tid, fant vi ut at IoT og UWP API var umoden for robust intern prosess kommunikasjon

metoder. Siden IoT var under utviklingsfasen, manglet det viktige API som vi trengte. IoT støttet

heller ikke enkle og elementære operasjoner som skriving og lesing. En annen ting som kan være

viktig å påpeke, er at RPI var opprinnelig anbefalt til å bli brukt med andre OS. Videre hadde UWP en

veldig streng forhånds programmert restriksjon, som var umulig å overstyre. Denne

sikkerhetsmekanismen hindret noen av program metodenes tilgang på lokale filer, som vi ville bruke

for å kommunisere med.

4.1.10 Inter prosess kommunikasjon (IPK) metoder som ble utprøvd

I kommende underkapitler beskriver vi metodene som vi skulle ta i bruk. Men uansett metode

konkluderte vi med at UWP sammen med IoT var ikke kompatibel med det opprinnelige designet

vårt. Til slutt kunne vi verken bruke IPK på IoT, eller implementere andre metoder på grunn av

kompleksiteten til de gjeldende metodene.

4.1.10.1 Skriving og lesing

I første omgang bestemte vi oss for å bruke en standard fil, med mulighet for tilskrivning og

avlesning. Fil beskyttelse var tiltenkt for senere steg, foreløpig skulle vi bruke flags for å tilordne en

rekkefølge, for når programmene fikk lov å skrive og lese. Det som gjenstod var å sende en variabel

fra C++, til C# og vise det på GUI. Dette var det enkleste og mest naturlige alternativet til å begynne

med. UWP API hadde ikke støtte for dette. Dermed måtte vi droppe dette alternativet.

4.1.10.2 Pipes og Socket

Med disse metodene kunne vi konstruere kommunikasjonsmoduler både på lokalt og eksternt

nettverk. Disse metodene droppet vi på grunn av vanskelighetsgraden og kompleksiteten til program

strukturen, og omfattende trådprogrammering som var langt utenfor vårt kompetanse nivå. I kapittel

(Python TCP) vil si se hvor mye lettere det er å nettverks programmere med Python.

4.1.10.3 Dll, P/Invoke, Memory Mapped File og Shared Memory

Shared Memory og Memory Mapped File kan brukes som IPK metode, mens Dll og P/Invoke faller

ikke under samme IPK kategori. Dll og P/Invoke metoden er ikke IPK metoder i seg selv. Her var

tanken å bruke P/Invoke til å kalle på Dll filer. På denne måten kunne vi overføre data mellom to

prosesser, eller forskjellige programmer. Vi ville manipulere programmet vårt til å lagre data


Rev: v1.2 21(62) 06.06.16

variablene og funksjonene i en Dll fil. Dll filer er eksekverbare koder slik som .exe filer. Når en prosess

i et program lager en felles minnelokasjon, som er tilgjengelig for andre prosesser kalles dette Shared

Memory metode. Memory Mapped File er en fil avbildet innpå systemets virtuelle minne. Den

imiterer som om en annen prosess har kopiert filen til systemets faktiske minne.

Anvendelsene av disse metodene feilet totalt. Hvis vi skal finne grunnen til dette, må vi henvise oss til

UWP sitt system arkitektur. For det første hadde vi ingen anelse om system mappe restriksjonen,

som vi nevnte i kapittel 4.1.9. UWP sitt fil og mappe håndteringsmekanisme, nektet to av

programmene vi hadde skrevet, tilgang til den aktuelle filen vi ville jobbe med.

Det første tilfellet var med Shared Memory. Shared Memory prosessen ble nektet tilgang til filen som

vi ville skrive og lese fra. Vi kunne heller ikke lage en vilkårlig fil i den beskyttede mappen. Dette er på

grunn av Shared Memory på UWP kun jobbet mot den mappen, og den mappen var total låst for

modifikasjon.

En annen løsning vi prøvde på, var at vi forsøkte å få tilgang til mappen på en «lovlig» måte. Ved å

bruke bestemte program klasser, kunne vi endre på filen i mappen. Selv om C# sitt bibliotek støttet

denne metoden, var det ingen API på UWP som var kompatibel med denne metoden. Et annet

problem med denne løsningen, var å gi C++ modulene tilgang til denne mappen, noe som var

absolutt umulig.

Det andre tilfellet var med vanlig skriving og lesing. Igjen møtte vi på API ukompatibilitet i UWP sitt

bibliotek. Problemet med Dll og P/Invoke var litt annerledes. Ved å først lage et Dll program, prøvde

vi å tilkalle en enkel funksjon i C++ fra et C# program, deretter kalle på Dll filen med P/Invoke. Vi

avbrøt utviklingen av Dll og P/Invoke metoden, da vi oppdaget en alvorlig system feil når vi utførte en

liten test. Det var derfor ikke noe poeng å gå videre, da vi ikke klarte å spore opp feilen.

(Stackoverflow, 2010), (Wikipedia, 2016), (Microsoft, 2016), (Microsoft, 2016), (Wikipedia, 2016),

(Lifehacker, 2011)


Rev: v1.2 22(62) 06.06.16

Rekkefølge av funksjoner:

Figur 15, Rekkefølgen av funksjoner i main

4.1.10.4 Funksjon og virkemåte

«Behandling av data» er vårt hovedprogram, dette er mer eller mindre «hjernen» til SW og kalles

heretter «main». Main må kalle på de forskjellige funksjonene og drivere i rett rekkefølge, slik at

systemet fungerer korrekt. Main må også holde på variabler som skal brukes i flere funksjoner. Den

må også holde de konverterte verdiene fra bl.a. vekt funksjonen i et array, slik at de funksjonene som

trenger disse variablene har tilgang til dem. Main skal også lagre data som skal holdes over lengre tid,

så den må ha muligheten til å skrive og lese fra filer.

ADC-Driver

Vekt

Lagre data i

array

Lys_driver

Nei

Ja

Epilepsi

Kommunikasjon

med gui

80 verdier i

array?

Søvnmønster


Rev: v1.2 23(62) 06.06.16

4.1.11 Design av drivere

Vi har valgt å definere drivere som et program, som styrer en eller annen form HW. I vår oppgave

hadde vi to drivere, en for å hente informasjon fra ADC. Den andre driveren er for å styre et lys via en

GPIO, hvor man kobler til en for form belysning. Driverne skrives i C++ og skulle blitt lagt til som

«.cpp» filer.

4.1.11.1 Virkemåte og funksjoner for ADC driver

ADC-driveren sin hovedoppgave er å motta data fra ADC-ene, for å gjøre dette bør den kunne vekke

ADC-ene fra dvale. Deretter må den sende et pulstog som innehar 25 pulser, tidskravene til disse

pulsene finner vi i databladet til (HX711), pulstoget sendes til en bestemt pinne. Når ADC-driveren

har mottatt 24bit i fra ADC, skal disse konverteres til integer. Det konverterte tallet skal returneres til

main. ADC-driveren må også kunne vente på ADC-ene, dersom en disse er opptatt. Det er ikke noe

poeng i at programmet fortsetter uten nye data.

4.1.12 Virkemåte og funksjoner for driver LYS

Lys driveren skal beregne vektpunktet til personen(e), som er i sengen. Når en av disse personene

flytter seg mot en av langsidene av sengen, skal lyset slåes på. Dette gjøres via en GPIO pin. Denne

driveren er avhengig av en del variabler i fra hovedprogrammet.

4.1.13 Design av «Vektbehandling»

Vektbehandlingsprogrammet er funksjonen som skal håndtere vekten som er i sengen, da med tanke

på sengens egenvekt og den vekta som er i sengen. Funksjonen skal også lagre hvem som er

Person_A eller Person_B, i en fil. Denne filen har vi valgt å kalle ref_fil.

Funksjonen får et utlest tall fra main, og en «beskjed» på hva som skal gjøres med vekten. Med tanke

på hvordan dataene skal behandles/lagres, deretter utfører funksjonen ønsket operasjon. Hvor den

enten returnerer vekten til hva som befinner seg i senga, lagrer vekten til person A-B, eller lagrer

egenvekten til sengen. Alle disse funksjonene bassers på linearisering for en rett linje.

𝑂 = 𝑘 ∗ 𝐼 + 𝑎. 𝑂 = 𝑜𝑢𝑡𝑝𝑢𝑡, 𝑘 = 𝑘𝑎𝑙𝑖𝑏𝑟𝑒𝑟𝑖𝑛𝑔𝑠𝑘𝑜𝑛𝑠𝑡𝑎𝑛𝑡, 𝐼 = 𝑖𝑛𝑝𝑢𝑡 , 𝑎 = 𝑏𝑖𝑎𝑠𝑝𝑢𝑛𝑘𝑡

5 Kommunikasjon med GUI

5.1.1.1 Funksjonalitet

For å få GUI modulen til å kommunisere med hoved modulen, kan vi benytte av oss flere tekniske

metoder. Denne avgjørelsen har blitt tatt på hensyn til fremtidige SW utvidelser. Vi tok også i

betraktning om vi skulle bruke forskjellige programmeringsspråk for forskjellige moduler.

Hovedoppgaven til denne operasjonen er å realisere kommunikasjonen i begge data retninger,

mellom GUI modulen og hoved modulen. Data overføringen mellom disse modulene, må følge

bestemte regler. Overføringen i begge retninger skal skje ved hjelp av lytting av porter, og i lokalt

nettverket. I denne prosessen skal begge modulene utnytte TCP/IP protokoll. Modulen som har

ansvaret for denne operasjonen heter «kom.fil».


Rev: v1.2 24(62) 06.06.16

5.1.2 Design av Søvnmønster

Programmet skal registrere om person A eller person B er i sengen. Deretter skal sengen registrer og

lagre vektverdiene fra de 4 forskjellige cellene. Ut i fra desse verdiene skal sengen kunne merke

endringer i vektpunktet. Vektpunktet samt tidspunktet målingen ble tatt, vil bli målt hvert minutt og

lagret. Disse målingen vil bli sendt til GUI som senere skal framstille søvnmønsteret i en graf.

5.1.3 Design av Epilepsi deteksjon modul

Epilepsi deteksjon modulen skal håndtere oppdagelse av kraftige vibrasjoner med en frekvens på 2-

5Hz. For at den skal kunne gjøre dette må den få samples fordelt utover tid, for å unngå «aliasing»

må frekvensen på samples være to ganger høyere, enn den største frekvensen du skal måle. I dette

tilfellet er den høyeste frekvensen 5Hz noe som betyr at man må sample med 10Hz eller høyere. For

å kunne finne frekvenskomponentene i samplingene som er blitt gjort, kan det implementeres en

«Fast Fourier Transform», som transformerer et signal i tidsdomene til frekvensdomene.

5.1.4 Den opprinnelige GUI løsningen

5.1.4.1 FUNKSJONALITET

GUI modulen i arkitekturen vår skal lage toveis grafisk kommunikasjon mellom sluttbrukeren og

programmet vårt. Brukeren vil kunne taste inn vekten til person a og person b manuelt. Vi har også

en kalibreringsknapp som nullstiller vekten og veier automatisk. I tillegg skal GUI vise vekten til

personene på tilkoblet skjerm. I situasjoner der epilepsi alarmen utløses, skal GUI varsle det visuelt.

Alarm med lyd prioriteres ikke i første omgang.

Figur 16, GUI layout løsning 1

Ovenfor ser vi et enkel oppsett av det grafiske brukergrensesnittet, med knapper som er mulig å

trykke på. Knappboksene som er uten hvit tekstfelt har kun en funksjon, og har ingen undermenyer

som popper opp hvis de blir trykket på. Bokser med rød skrift viser bare informasjon og kan ikke

trykkes på. Knapper med hvit tekstfelt har undermeny med mulighet for inntasting.


Rev: v1.2 25(62) 06.06.16

5.1.4.2 KOMMUNIKASJON MED ANDRE MODULER

GUI modulen må kommunisere både med interne moduler, og eksternt med brukeren. GUI modulen

skal snakke med hovedmodulen via lokalt nettverk, og det grafiske resultatet vises eksternt på en

skjerm. Dette skjer da ved at vi programmerer et GUI program ved hjelp av C#, og installerer det som

en applikasjon på IoT. Figuren under viser data retningen mellom forskjellige moduler og hvordan de

er koblet sammen.

5.2 Andre løsningsalternativ

Figur 18, andre SW løsning

I andre designfase ble det tatt en tøff og risikabel avgjørelse, som skulle bli prosjektets vendepunkt.

Denne gangen ble det bestemt for bytting av OS, samtidig som vi også skulle begynne å

programmere i et annet språk. For det første, var det ingen av oss som kjente godt til Linux operativ

systemet. Her snakket vi om nesten totalt ukjent system for noen av oss. Vi ble satt utenfor vår

komfortsone. Vi manglet også kunnskap om objekt orientert programmering (OOP). Det nye

programmeringsspråket het Python. Python er et veldig populært språk i programmeringsverden.

Med sine flere fordeler, uvurderlig bred API bibliotek, lett syntaks, massevis av dokumentasjon og

stor støttegruppe på internett, virket dette overkommelig. Herfra hadde vi to valg, enten å bruke

kodene fra C++ delen med Python API, eller skrive alle modulene om til Python. C++ kodene stod

allerede til disposisjon for gjenbruk. En annen faktor vi vurderte var om, GPIO pinnene til RPI kunne

toggles fort nok av Python. Derfor endte vi opp med å bruke C++ kodene sammen med Python API

modulen.

Hoved

Modul GUI Kom

.fil

SKJERM

(PC/LCD)

Figur 17 Kommunikasjonsoversikt


Rev: v1.2 26(62) 06.06.16

5.3 Tredje og endelige løsningsalternativ

Ettersom som vi hadde dårlig tid og flere oppgaver vi måtte løse, måtte vi ta en drastisk avgjørelse.

En av problemstillingene var om vi kunne skrive hele programmet og modulene i Python? Python er

OOP, som kunne påvirke driver kodene. Spesielt var vi interessert i å beholde C kodens optimal

hastighet for ADC driveren. Den måtte fungere fort nok til å sende ut data til riktig tid, og i det hele

tatt sende data når det trengtes. Når det gjelder lavnivå programmering, er C++/C veldig anvendelig

og passende for driver programmering. Her var vi opptatt av lavnivå kodene skulle bli prosessert

hurtig og optimal. Helst ville vi beholde lavnivå kodene våre, noe som førte til at vi skrev hele

programmet i Python. Testene viste gode resultater, driverne fungerte som forventet, hele systemet

ble effektivisert og modnet for flere utvidelser. Denne modelldesignen er vår endelige løsning for

systemet. Et slikt program infrastruktur, skaper fleksibilitet for fremtidige utvidelser. Et annet

karakteristikk som er verdt å bemerke seg, er at programløsningen er delt inn i tre programmer.

Disse programmene består enten av en eller flere submoduler.

Figur 19, Tredje løsning


Rev: v1.2 27(62) 06.06.16

5.3.1 Main

«Main» modulen kan anses som hjertet av SW delen. Denne modulen er softkodet og inneholder

funksjonskall fra andre biblioteker som vi har laget. I Python kan bestemte elementer overføres eller

inkluderes fra forskjellige biblioteker, istedenfor å bruke hele biblioteker. Dette er for å unngå bruk

av et biblioteks hele innhold.

Den tekniske forbindelsen mellom alle kildekodene, er sammenkoblet ved hjelp av Main. Når Main

kjøres, starter driverne sammen med de nødvendige funksjonene. Funksjoner som blir kalt på,

beskyttes av koder som fanger opp feil. Denne mekanismen gjør Main mer robust ved å fange feil,

når funksjonene blir initiert. Figur 20 viser eksempelet med fanging av feil. Først prøver programmet

å kjøre et bestemt funksjon ved å bruke try. Deretter fanger programmet eventuelle feil som oppstår,

med except. Feil typene som blir fanget opp bestemmes av program utvikleren. Det er da selvfølgelig

mulig å unnlate å fange feil. Kortsiktig kan programmet fungere, men dersom alvorlige feil oppstår i

biblioteker, kan dette forplante seg videre i kjøringen av programmet. I verste tilfellet kan det føre til

programkrasj. Ved å innføre en slik mekanisme gjør det lettere for brukeren, eller den teknisk

ansvarlige, å oppdage feil av varierende alvorlighetsgrad.

Figur 20: Fanging av feil

I Figur 21 kan vi se noen av bibliotekene som ble brukt.

Figur 21: Mains biblioteker og funksjoner


Rev: v1.2 28(62) 06.06.16

Nedenfor er forskjellige biblioteker og funksjonskall nærmere beskrevet.

5.3.2 GPIO_init

Dette biblioteket har ansvaret for å tildele GPIO pinnene riktig status. De som skal bli lest ifra får

inngangsstatus, og de som skal skrives til får utgangsstatus. Dette biblioteket må kjøres engang ved

oppstart.

5.3.3 Globals variabel fil

For at alle modulene skal kunne snakke sammen, laget vi en Globals variabel fil. I tillegg til å lagre

midlertidige variabler i minne, inneholder modulen også konfigureringsdata. Dette sørger for lett

tilgang av konfigurering av modulene.

5.3.4 ADC-driver

ADC-driverens jobb er å håndtere utlesingen av data fra ADC-modulene, og lese disse inn i globale

tabeller. ADC-driveren måtte derfor ha tilgang til GPIO pins, gjerne via et eksternt bibliotek som

tillater mikrosekund endringer.

Vi valgte å bruke referanse koden for driveren fra databladet, da denne etter noe modifikasjon

håndterte utlesningen, på en robust og elegant måte.

Utlesningen for hver ADC, skulle håndteres slik databladet anbefalte:

Figur 22, Utdrag fra datablad, timingdiagram (HX711)

Databladet til ADC-modulene viser hvordan en utlesning skal foregå. Når DOUT går lav indikerer

dette at data er klar for uthenting. Det er ADC-driverens jobb å detektere dette og respondere med å

pulse Serial ClocK(SCK) linjen med 24 pulser, for så å lese ut 24 bit med data på DOUT linjen. Det skal

så sendes en siste puls for å indikere til ADC-modulen, at neste data skal komme fra kanal A med en

forsterkning på 128.

5.3.5 Lys-driver

Lys driverens jobb er å beregne vektpunkt i senga, og se om det er utenfor grensene som er definert i

Global variabel filen. Lysdriveren avgjør om lyset skal være på eller av, for så å sette en GPIO pin som

er koblet til et rele.

5.3.6 Epilepsi-driver

Epilepsi er ikke en sykdom i seg selv, men en betegnelse på forskjellige sykdomstilstander som gir

anfallsvis funksjonsforstyrrelser i hjernen. Epileptiske anfall deles grovt i to hovedgrupper, kalt

generaliserte og fokale anfall. Vårt mål er å kunne indikere generaliserte anfall som består av to

faser. I den første fasen, også kalt den «Toniske» fasen, mister personen bevisstheten og opplever en


Rev: v1.2 29(62) 06.06.16

tilstiving av kroppen. I forbindelse med dette vil også luften i lungene blåses ut og personen kan bli

blå i ansiktet. Etter 10-20 sekunder går anfallet over i andre fase, eller den «Kloniske» fasen. Det er

her man ser rykkvise bevegelser som man ofte forbinder med epilepsi. Det er disse rykningene vi

ønsker å detektere og varsle om. (Norsk epilepsiforbund, 2016)

Epilepsi-driverens jobb er å avgjøre om det finnes stor bevegelse i frekvensområdet 2-5Hz. Vi oppnår

dette ved å beregne Fast Fourier Transform(FFT) til inngangssignalet. Først implementerte vi en

Diskre fourier transform, men så en 20x forbedring i komputasjonstiden, når vi gikk over til numpy

bibiloteket og dens implementasjon av FFT.

5.3.7 Vektbehandling

Vektbehandlings modulen vil ha flere viktige formål. Det viktigste er å gjøre rådata fra ADC modulene

om til KG verdier, som de andre modulene kan tolke. Dette gjøres via en lineariseringsprosess:

Figur 23, illustrering av lineariseringsprosess

På figuren til venstre ser vi 4 forskjellige responslinjer. Figuren til høyre viser de samme linjene etter

en lineariseringsprosess.

Prosessen består av å finne komponentene i lineariseringsligningen:

𝑂 = 𝐾 ∗ 𝐼 + 𝑎; 𝑂𝑢𝑡𝑝𝑢𝑡 = 𝑆𝑒𝑛𝑠𝑖𝑡𝑖𝑣𝑖𝑡𝑦 ∗ 𝐼𝑛𝑝𝑢𝑡 + 𝐵𝑖𝑎𝑠

Figur 24, illustrasjon av formel


Rev: v1.2 30(62) 06.06.16

Der:

𝐾 = (𝑂𝑚𝑎𝑥 − 𝑂𝑚𝑖𝑛)/(𝐼𝑚𝑎𝑥 − 𝐼𝑚𝑖𝑛)

𝐴 = 𝑂 – 𝐼 ∗ 𝐾

Verdiene Omax, Omin, Imax, Imin blir funnet for hver veiecelle og blir lagret i en REF-fil, K og A blir så

beregnet ved oppstart.

Modulen kompenserer også for egenvekt av senga, slik at en tom seng leses som 0kg, selv om det

kanskje ligger 15kg på vektcella.

5.3.8 Person deteksjon

Denne modulen skal gi indikasjon på om noen av de lagrede personene er i senga, dette oppnås ved

at modulen leser den totale vekta i senga, og ser om den likner på de lagrede vektene ± predefinert

Feilmargin. Modulen tar så å setter globale variabler ut i fra hva den har funnet.

5.3.9 ThrowAway filter

Denne modulen har i oppgave å oppdage impuls støy. Dette gjøres ved at den analyserer punktet N

og ser om dette ligger utenfor de dynamiske grensene.

(ℎ𝑖𝑔ℎ𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 <𝑁

𝑁−1) 𝑜𝑟(

𝑁

𝑁−1 < 𝑙𝑜𝑤𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑)𝑎𝑛𝑑(ℎ𝑖𝑔ℎ𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑 <

𝑁

𝑁−1)𝑜𝑟(

𝑁

𝑁−1<

𝑙𝑜𝑤𝑇ℎ𝑟𝑒𝑠ℎ𝑜𝑙𝑑) gitt att (N-1/=0) og (N+1/=0).

Vis betingelsene over er oppfylt, settes 𝑁 =(𝑁−1)+(𝑁+1)

2 noe som i praksis fjerner spikene, samtidig

gjettes datapunktets faktiske verdi. Dette gjør at tabellen fremdeles skal ha 80 samples, som de

andre modulene krever. I praksis gir dette minimal påvirkning av systemets ytelse. Grunnen til at

dette filteret ble implementert, vises i 6.5.1.

5.3.10 Database lagring – Sqlite

Sqlite er et SQL basert database behandlingsprogram, som kan integreres i forskjellige

programmeringsspråk. Programmet er «lettvekts program» og er lite ressurskrevende. I tillegg er det

selvforsynt, virker uten server og trenger ingen konfigurasjon. Med selvforsynt menes det at,

programmet ikke trenger ekstern støtte fra OS eller bibliotek filer. Det støtter kryss-plattform og har

innebygget API for bruk med flere programmeringsspråk. Alle forespørsler og forandringer mot

databasen, er av typen ACID, «Atomic», «Consistent», «Isolated», og «Durable». Kort sagt vil dette si

at, under data transaksjon er det rustet mot OS krasj, program krasj og strømkutt. Sqlite består mer

eller mindre av et bibliotek på 500 kB. Størrelsen på programmet er avhengig av OS plattformen den

kjører på. En komplett database blir lagret som kryss-plattform disk fil. Sqlite er en av verdens mest

utberedte database motor program. Det er et Open Source program og kan brukes av alle uten

lisens. Sqlite kan anvendes av mange forskjellige programmeringsspråk.

Database modulen skal lagre vekt verdier av alle veiecellene, sammen med tid og dato. Totale vekten

fra alle fire cellene er også inkludert i databasen. Lagringen av vekten er periodisk og betingelses

drevet. Verdiene lagres hvert sekund, eller dersom vekten har endret seg med mer enn 50 gram fra

siste lagring. Verdiene av hver måling, blir i tillegg stemplet med tid og dato når det lagres.


Rev: v1.2 31(62) 06.06.16

Figur 25, database modul

5.3.11 Inter prosess kommunikasjon (IPK)

Inter prosess kommunikasjon er en av de mest viktigste og kritiske byggesteinene i profesjonell

programmering. Med denne teknikken, lager man kommunikasjonskanal mellom submoduler, eller

programmer. Den største hensikten med å ha IPK, er for å opprette et nettverk som består av flerveis

kommunikasjonskanaler, som kan enten dele data med andre moduler, eller sende/motta data

eksternt. Utformingen av IPK er kategoribasert, den baserer seg på faktorer som latens,

nettverksarkitektur, modularitet, systemkrav og systemytelse. Til vårt bruksområde trengte vi to

typer IPK metoder, en protokoll som kunne kommunisere over internett, og en annen som kunne

utveksle data internt mellom moduler. Nedenfor har vi en oversiktstabell for IPK metoder.

Metode Beskrivelse

Socket Strøm av data over lokalt eller eksternt IP basert nettverk.

Fifo Pipes Enveis data sending. Lages automatisk av skall og kjøres i kernel.

Named Pipes Toveis data sending. FIFO prinsipp. Tilgjengelig for flere prosesser.

Shared Memory Blokk av minne laget for kommunikasjon mellom flere prosesser.

Bruker buffer mellom prosesser for å kommunisere.

Semaphore Abstrakt data type som gir kontrollert tilgang til felles minne brukt av flere prosesser.

Message Queue Strøm av data med begrensning av meldingslengde. Påkalles av OS, flere prosesser kan skrive til meldingskøen uten å

direkte snakke med hverandre.

Memory Mapped File Adresse kartlagt filer som befinner seg i RAM. Kan manipuleres direkte i minne.

File Lagret data på disk eller syntetiseres av server hvis det er krav om det.

Vektlogg Database Verdier database.py

sqlite3 API

Database fil


Rev: v1.2 32(62) 06.06.16

Tilgjengelig for flere prosesser.

Signal/Async System

Trap

Brukes for å sende kommando mellom prosesser.

Tabell 1, IPK protokoller

5.3.11.1 Named Pipes

Named Pipe metoden er basert på FIFO prinsippet, som er forkortelse for «First In First Out» regelen.

«Piping» metoden er en av de vanligste måtene for å få overført data mellom to eller flere prosesser.

Ordet pipe betyr å knytte data strømmen fra en prosess til en annen. Som regel piper man fra

utgangen til en prosess, med inngangen til en annen. Pipe teknikken lar brukeren benytte seg av en

eller flere prosesser, som kan skrive til en felles Pipe blokk. Men det er alltid kun en prosess som kan

lese fra Pipe om gangen. Nedenfor er det illustrert to prosesser som skriver til inngangen til Pipe, og

på andre siden leser en tredje prosess utgangen til Pipe.

Figur 26, FIFO pipe protokollen

Named Pipes:

Lages programmatisk ved å bruke mkfifo kommandoen.

Eksisterer i fil systemet med et gitt navn.

Kan bli brukt av en eller flere urelaterte prosesser.

De åpnes ikke idet de blir laget.

Støtter toveis data trafikk.

Prosessen som skriver blokkerer Pipe, inntil det innføres en ny prosess som leser fra Pipe, og

omvendt.

I tillegg til punktene ovenfor, har Named Pipes flere fordeler for vårt bruk, ved at den gjør

programkoden mindre komplisert og har mindre ressurskrevende header. Med Named Pipes kan

prosessene utveksle data uten å bli initialisert i en såkalt «barn-forelder» fase i motsetning til

Unnamed Pipe. Denne programmeringsfasen kan en unnvike, ettersom det ikke er behov for dette i

Prosess 1

Prosess 2

FIFO

PIPE Prosess 3

FIFO fil


Rev: v1.2 33(62) 06.06.16

Named Pipe teknikken. Dataoverføringen skjer via en system fil. Filen er forbeholdt kun til

prosessene som håndterer den, noe som gir filen en slags beskyttelse mot data korrupsjon og

overskriving av eksisterende fil.

5.3.11.2 TCP (Transmission Control Protocol) Socket

En annen IPK metode vi har brukt er TCP/IP basert Socket. I og med at systemet vårt trenger å sende

vekt-logg til klienter innen et IP nettverk, lagde vi en server modul som kun har ansvaret for

utsending av vekt-logg. Designen i server programmet, gjenspeiler en forenklet versjon av

server/klient forhold. Klienten kobler seg til server programmet vårt og sender forespørsel for

vektlogg database filen.

Socket er grensesnittet mellom en applikasjon og et nettverk. Det er to socket typer som har vært av

interesse for oss, TCP og User Datagram Protocol (UDP). TCP protokollen har flere kontroll og

sikkerhets algoritmer, vi vil ikke utdype alle, men skriver likevel om noen av dem. TCP brukes for

pålitelige og forbindelse-orienterte koblinger, mens UDP mangler sikker data transmisjon delen. Vi

ville unngå å bruke UDP på grunn av database filens viktighet, og ved å bruke TCP protokollen kunne

vi forsikre klientsiden en sikker overføring av filer. En annen viktig sikkerhets mekanisme som TCP

bruker, er at den bevarer data rekkefølgen i den utsendte pakken. På den måten sikrer klientsiden

pakkens innhold i riktig rekkefølge. TCP har også algoritme for å sjekke etter feil i mottatt datapakke.

Både server programmet og klient programmet, lager socket som fungerer som styringsbord for

innkommende og utgående data trafikk. Trafikken styres ved å tilføre socket, IP og port parametere.

Serversiden lytter etter innkommende trafikk, og godkjenner forespørselen hvis parameterne er

korrekte. Ved etablert forbindelse kan programmene foreta data utveksling. Programmene sender

eller mottar data via socket, der socket sender data ved hjelp av Internet Protocol (IP). All data

utveksling kan foregå lokalt, eller over internett. Med TCP protokoll er det også mulig å være vert for

flere klienter samtidig.

Figur 27, blokkdiagram TCP/IP

APP Datapakker SOCKET

IP?

PORT?

Datapakker Destinasjon


Rev: v1.2 34(62) 06.06.16

6 Testing Vi har brukt litt forskjellig programmer og utstyr i forbindelse med testing av systemet, både under

utvikling og til slutt-testen av systemet.

Første delen av programmet ble utviklet med Visual studio, hvor vi debugget og skrev koden for

hovedprogrammet. Deretter brukte vi PyCharm, når vi gikk over til Python. Utstyr vi har brukt i

forbindelse med testing er digital analyser, oscilloskop og multimeter.

Vi har også brukt forskjellige fremgangsmåter i forbindelse med testing av programmer, under

utviklingen av programmene. Felles for alle programmene er at har blitt brutt ned i moduler, og

deretter egne funksjoner innenfor hver modul.

6.1 Hovedprogrammet

Hovedprogrammet var det første programmet vi startet med å utvikle. Det var også den første koden

som vi begynte å teste. Vi brukte Visual studio til å skrive programkoden, og som debugger. Deretter

brukte vi PyCharm. Det var veldig enkelt å bruke Visual Studio sammen med RPI, da vi kunne lage

programkoden på PC og kjøre den direkte på RPI. Dette kunne vi imidlertid ikke gjøre like lett med

PyCharm.

Vi brukte en metode hvor vi lagde hver modul basert på den forrige. Dette gjorde vi fordi det var

lettere å bruke rådata fra ADC-ene, istedenfor å lage en simulering av disse. Dette førte til en

akselerert og logisk utviklingsprosess, i tillegg til at vi klart så fremgangsstatus.

Som skjemaet i Figur 2 viser, ble testene utført for hver funksjon, for å kontrollere at disse fungerte

som vi ønsket. Når alt fungerte, gikk vi videre til neste funksjon. Denne funksjonen ble deretter

utviklet og testet, før det ble gjort en kombinert test (om disse funksjonene skulle brukes sammen).

Når alle funksjoner var kommet på plass, og modulen fungerte som vi ønsket, startet vi på neste

modul. Her blir data fra modul 1 brukt under testingen av de nye funksjonene, som blir utviklet i

denne modulen. Fremgangsmåten er fortsatt den samme. Etter hvert som modulene ble ferdig, ble

disse testet sammen. Dette resulterte i at en del bugs og problemer ble luket bort underveis.


Rev: v1.2 35(62) 06.06.16

Figur 28, test fremgangsmåte for hovedprogram

6.1.1 ADC-driveren

Denne modulen ble først utviklet, den skulle ikke samhandle direkte med noen andre moduler.

Modulen ble testkjørt på RPI, da den ikke kunne bli simulert på datamaskin. Modulen skulle bare

hente verdier fra ADC-ene og returnere dem til main. For å få testet at dette fungerte, ble verdiene

målt med digital analysator. Da kunne vi se om klokke signalet ble generert av RPI. Men det gav oss

også muligheten til å se om RPI klarte å få dataene fra ADC-ene. Pulstoget fra ADC-ene (målt med

analysatoren), ble deretter sammenlignet med det ferdige tallet på RPI.

Program Modul 1

Funksjon 1

Test funksjon 1

Test feilet eller

Fungerer ikke korrekt

Funksjon 2

Test funksjon 2 Test feilet eller


Funksjon 1 og 2

Test funksjon 1 og 2 Test feilet eller


Modul 2

Modul 1 fungerer

som ønsket

Funksjon 1

Test funksjon

1

Funksjon 2

Test funksjon 2

Funksjon 1 og 2

Test funksjon 1 og 2 Test feilet eller


Test feilet eller


Test feilet eller


Test modul 1 og 2

Modul 1 og 2

Modul 1 og 2 er ferdigstilt

Programmet er ferdig

Test feilet eller



Rev: v1.2 36(62) 06.06.16

6.1.1.1 Test av ADC-driver

Under vises resultatet fra test av ferdig ADC-driver, PD_SCK vises i oransje og DOUT vises i lilla.

Figur 29, Testresultat av ferdig ADC-driver

Da vi startet på Windows 10 IOT gikk ADC-modulene i dvale. Etter feilsøking viste det seg at GPIO

biblioteket vi brukte var for tregt. Dette førte til at ADC-modulene så logisk høyt nivå i mer enn 50

mikro sekunder, noe som den tolket som beskjed om å aktivere dvalemodus. Dette problemet løste

vi ved å skifte GPIO bibliotek på Windows. Da vi gikk over på Linux fantes det et standard bibliotek

«Wriring PI» som var raskt nok.

6.1.2 Vektbehandling

Denne modulen brukte verdiene fra ADC-ene, under utvikling og testing. Mens funksjonen ble

utviklet, ble verdiene printet ut, for å se at variablene var korrekt oppdatert, og inneholdt korrekt

informasjon. Vi brukte også breakpoints for sjekke verdier, men også for å finne ut hva som eventuelt

gikk galt, om vi fikk ut feile verdier og/eller om programmet krasjet. Breakponts var spesielt viktig når

vi skrev og leste verdier fra/til filer. Når programmet fungerte som ønsket ble KG tallet printet ut til

terminal, ettersom vi ikke hadde noen GUI til å vise tallene på dette tidspunktet.

6.1.3 Lysdriver

Lysdriveren brukte verdier fra vekbehandlingsprogrammet, både til utvikling, testing av funksjoner og

moduler. For å få testet at modulen slo på lyset som ønsket, brukte vi et LED-lys som er innbygget i

RPI som indikator, og en test person på et bord for å utløse indikatoren. Etter hvert som vi fikk

indikatoren til å fungere som ønsket, og parameterne var fin justert, endret vi LED lyset til en GPIO

pin og kjørte testene på nytt (brukte da logic-analyser for å se om GPIO pinnen ble utløst på korrekt

tidspunkt). Når denne var kommet på plass, koblet vi til et rele og kjørte testene på nytt. Da hørte vi

etter klikk fra releet, samt målte GPIO pinnen med Logic analyser.

6.1.4 Epilepsi

Denne modulen har brukt data fra vektbehandlingsprogrammet. Men den har derimot ikke tatt noen

data i fra lysdriveren. De fleste funksjonene har blitt simulert på maskinen, før de har blitt

implementert i modulen (da med tanke på filtret som er brukt). Grunnen til dette er at det er lettere

å få simulert dataene, samtidig som at det ikke krever at en person står å simulerer et epilepsi anfall

på et bord, eventuelt en seng. Når modulen var ferdig og vi fikk ønsket resultat fra simuleringen, ble

modulen implementert i programmet. Deretter testet vi modulen under faktisk forhold, for å

bekrefte at alt fungerte som det skulle.


Rev: v1.2 37(62) 06.06.16

6.1.4.1 Simulering av epilepsi

Figur 30, test av epilepsi-driveren

I Figur 30, til venstre viser et inngangssignal på 70kg dc + 10kg * 3hz + tilfeldig støy ±5kg. Til høyre,

vises det at epilepsi modulen tydelig ser vibrasjonen på 3hz. Legg merke til at signalet er speilet om

Nyquist frekvensen, på 40hz.

6.2 Test av hovedprogrammet

Test strukturen vi har brukt på hovedprogrammet gjorde at vi endte opp i en slutt test av

hovedprogrammet, hvor vi fikk testet alle modulene. De fleste problemene har blitt tatt bort,

resultatet og fremgangsmåte er vist her.

6.2.1 Test av ADC driver og vektbehandlings program

For å teste vektbehandlingsprogrammet, og at ADC driveren henter data fra veiecellene på

forespørsel. Kobler vi ADC-ene og veiecellene til RPI. Deretter lager vi en enkel kode som sender

forespørsel om data 1 gang per sekund. Ønsket resultat er at kilo fra hver av cellene blir printet ut i

terminalvinduet, henholdsvis: celle A = xx, celle B = xx, celle C = xx, celle D = xx, TOT= xx. For å gjøre

testen realistisk, plasserer vi hver av veiecellene under hvert sitt ben på et bord. Deretter sitter en på

gruppen, som veier rundt 100 kg, seg opp på bordet slik som bildet til venstre i Figur 31 illustrerer.

Figur 31, test resultat hovedprogram


Rev: v1.2 38(62) 06.06.16

6.2.1.1 Konklusjon:

Ut i fra terminal vinduet kan vi se at alle cellene gir ut riktig vekt. Man kan også se at vektpunktet er

oppe til høyre, ved celle C. Dette Betyr av ADC-driveren og vektbehandlingsprogrammet fungerer

som de skal.

6.2.2 Test av lysdriver

For å teste lysdriveren brukte vi samme fremgangsmåte som testen for ADC driver. I tillegg til å

printe ut vekten på hver celle i terminalvinduet, printer vi også ut om belysning i rommet er aktivert

eller deaktivert.

Figur 32, status for lys

6.2.2.1 Konklusjon

På Figur 32, ser vi at dersom det ikke er vekt i sengen er lyset aktivert, dette er markert med en gul

ring. Dersom personen går oppi sengen, og vekten har stabilisert seg, er lyset deaktivert. Dette er

markert med rød ring. Vi kan derfor konkludere med at lysdriveren fungerer som ønsket.

6.3 Grafisk bruker grensesnitt

For det grafiske brukergrensesnittet ble det brukt en annen fremgangsmåte, men den er fortsatt

ganske lik.

Vi startet først med å lage en funksjon, deretter ble denne funksjonen testet. Når funksjonen gjorde

det den skulle gjøre, gikk vi videre med å utvikle neste funksjon. Når denne funksjonen fungerte som

den skulle, ble den testet sammen med den forrige funksjonen (om dette var noe som var ønsket).

Eventuelle problemer som oppstod ble løst, før man fortsatte på neste funksjon. Se prinsipielt skjema

i Figur 33.


Rev: v1.2 39(62) 06.06.16

Figur 33, GUI test under utvikling (funksjon)

Etterhvert som modulene var ferdige ble de implementert i programmet de tilhørte. Samme

fremgangsmåte som over, ble brukt for modulene som for programmet, men testene var ikke

avhengig av en bestemt modul for å kjøre en test. Se prinsipielt skjema i Figur 34.

Figur 34, GUI modul test og utvikling

Modul 1

Funksjon 1 Samlet test 1:

Funksjon 1

Funksjon 2

Test av funksjon 2

Samlet test 2:

Funksjon 1 og funksjon 2

Funksjon 3

Test av funksjon 3

Samlet test 3:

Funksjon 1, funksjon 2 og funksjon 3

Utviklingssteg Test steg

Program 1

Modul X

Test av modul 1

Samlet test 1:

Modul X

Modul Y

Test av modul Y

Samlet test 2:

Modul X og modul Y

Modul Z

Test av modul Z

Samlet test 3:

Modul X, modul Y og modul Z

Utviklingssteg Test steg


Rev: v1.2 40(62) 06.06.16

Testingen av modulene ble gjort etter hvert som de ble ferdig. Alle programmene ble skrevet og

testet på Linux maskin, med PyCharm professional som utviklingsverktøy. Dette gjorde vi fordi RPI

kun har en simpel teksteditor, som er tungvint å programmere i. PyCharm er der imot et enkelt og

effektivt program, som gir gode tilbakemeldinger dersom feil oppstår i koden. Det er også gratis å

bruke, så lenge man er student. Det støtter også muligheten til å koble seg til RPI og overføre

program koden.

I Figur 34 går vi mer i detaljer rundt kritiske funksjoner og moduler, siden oppbygningen av bruker

grensesnittet er litt annerledes enn hovedprogrammet. Testingen av programmet underveis er også

blitt gjort annerledes, under utvikling, fordi vi brukte en del IPC mekanismer for å kommunisere

mellom programmene. Fordi GUI må ha muligheten til å hente data fra hovedprogrammet, var det

veldig viktig at testene ble gjort annerledes.

Programkoden har nemlig blitt utviklet/testet opp mot et enkelt simuleringsprogram (som vi laget

selv). Simuleringsprogrammet sov i 1 sekund (henter data fra ADC) og deretter økte en variabel med

1 (simulering av vekt), dette ble gjort i en stor for-løkke.

Felles for alle funksjonene av knapper er at de er tre delt. Og alle knappene innehar en normalverdi

satt i programmet. Disse tre delene er delt opp i en kode som er på GUI siden (Steg 1),

kommunikasjon mellom programmene (piping, steg 2) og kode i hovedprogrammet (her kan data

returneres tilbake til GUI via pipes, Steg 3). Steg 2 blir forklart for seg selv, ikke sammen med

funksjonene bak knappene. Alle knappene i programmet inneholder normalverdi som baserer seg på

funksjonen knappene skal utføre.

6.3.1 Funksjonene bak knappen «Hent Vekt»

Det var lite koding for denne funksjonen, men det var derimot mye testing under utvikling av

funksjonene bak knappen. Steg 1 i denne delen, gikk ut på å få testet at man fikk utført korrekt

handling når man trykket på «Hent Vekt». Så det ble gjort mange tester for å kontrollere at man fikk

ut korrekt resultat, når denne knappen ble aktivert, og at det ikke oppstod en uønsket situasjon. Når

knappen blir trykket på, blir det printet ut en respons på GUI-en. Denne responsen inneholdt

knappens verdi og en annen normalverdi, satt i programmet. Dette ble gjort for å se at vi kunne

utføre kommandoer basert på handlinger, gjort i html.

Steg 3 av testen var å få sjekket at hovedprogrammet mottok korrekt data fra GUI-en. Deretter ble

det utført en operasjon, før den sendte et svar tilbake til GUI, via en annen pipe. Den mottatte

knappens normalverdi ble printet i det simulerte hovedprogrammet. Etter dette printet vi ut en

beskjed, at data var sendt tilbake til GUI, og vekten ble vist på skjermen.

6.3.1.1 Resultater fra test «Hent Vekt»:

Disse resultatene er fra den komplette testen av programmet, ikke testene som pågikk under

utvikling.


Rev: v1.2 41(62) 06.06.16

Vi velger å gjøre 7 tester og kontrolerer utfallet

Nr. Input Output Tid fra Input til Output vises på display

1 «Hent vekt»

«83 kg» 1 sek

2 «Hent vekt»

«85 kg» 1.5 sek

3 «Hent vekt»

«87 kg» 1.5 sek

4 «Hent vekt»

«90 kg» 1.5 sek

5 «Hent vekt»

«111 kg» 1 sek

6 «Hent vekt»

«114 kg» 1.5 sek

7 «Hent vekt»

«123 kg» 1 sek

Tabell 2, Testresultat "Test Hent vekt"

På Figur 35D, kan vi se at simuleringsprogrammet har fått forespørsel fra GUI, videre kan vi se at

vekten 25 kg er returnert til GUI, på Figur 35C. Hele denne operasjonen vil i gjennomsnitt ta 1,3

sekunder.

6.3.1.1.1 Konklusjon

Funksjonen fungere som ønsket, «Henter vekt! Vennligst vent» vises på skjermen helt til vekten er

returnert og vises på skjermen.

Figur 35A, Simuleringsprogram uten forespørsel fra GUI Figur 35B, GUI uten "Hent vekt" klikket

Figur 35C, Simuleringsprogram når "Hent vekt" er klikket Figur 35D, GUI når vekten er returnert

Figur 35, Hent Vekt resultater


Rev: v1.2 42(62) 06.06.16

6.3.2 Funksjoner bak knappene Person A/Person B

Her ble også knappene testet og normalverdien til knappene ble printet ut i konsollen, for å se at

korrekt hendelse inntraff. Her blir samme piping systemet som i 6.3.1 brukt, så denne delen var

allerede testet. Det eneste som er forskjellig er hva som ble sendt gjennom pipen. På den andre

siden av pipen, ble det testet med påbygning av den eksisterende koden. Dette var for å skille hva

som kom inn/ut av pipen. Her ble også verdiene printet ut underveis. Det som skiller seg fra «Hent

Vekt», er testene som ble utført rundt lagring av data til fil. Her blir det også brukt breakpoints og

utskrift til konsoll, for å se hvor vi var i koden. Vi måtte kontrollere at koden ikke stoppet opp, mens

den holdt på med filbehandling. Vi måtte også kontrollere at programmet klarte å skille dataene som

skulle lagres til fil.

6.3.2.1 Resultater fra «Test Person A og Person B»

Disse resultatene er fra den komplette testen av programmet, ikke testene som pågikk under

utvikling. Testene er delt inn i to deler for bedre oversikt over hver av knappene.

6.3.2.1.1 Test «Person A»

Vi velger å gjøre 7 tester og sjekke utfallet


1 «20» «20 kg» 2 sek

2 «abc» «Vennligst tast inn ett tall» 0 sek

3 «100» «100 kg» 1.5 sek

4 «302» «Vennligst velg en verdi mellom 0 til 300» 0 sek

5 «-3» «Vennligst velg en verdi mellom 0 til 300» 0 sek

6 «280» «280kg» 1.5 sek

7 «45» «45 kg» 1.5 sek

Tabell 3, Testresultat Person A

Figur 36B Vekt vises på display for person A

Figur 36C, Lagret vekt for person A i filen

Figur 36A, vekt tastes inn for person A

Figur 36, resultater person A


Rev: v1.2 43(62) 06.06.16


Vi ser at ønskede resultater oppstår, samt at vekten til person A blir lagret i en fil.

6.3.2.1.3 Test «Person B»

Vi velger å gjøre 7 tester og sjekke utfallet


1 «20» «20 kg» 2 sek

2 «abc» «Vennligst tast inn ett tall» 0 sek

3 «100» «100 kg» 1.5 sek

4 «302» «Vennligst velg en verdi mellom 0 til 300» 0 sek

5 «-3» «Vennligst velg en verdi mellom 0 til 300» 0 sek

6 «280» «280kg» 1.5 sek

7 «66» «66 kg» 1.5 sek

Tabell 4, testresultat "Person B"

+


Vi ser at ønskede resultater oppstår, samt at vekten til person B blir lagret i en fil.

6.3.3 Funksjoner bak knappene epilepsi av/på for «Person A» og «Person B»

Fremgangsmåten for testing under utvikling er veldig lik som i 6.3.1, forskjellen er at det er ikke noe

som blir returnert tilbake til GUI fra main. Dette utelukker testing av denne delen.

6.3.3.1 Resultater fra test epilepsi for «Person A» og «Person B»

For å kunne aktiver epilepsi deteksjonen for «Person A» eller «Person B», har vi laget fire knapper.

Dersom man trykker på knappen «Epilepsi_A_on» vil epilepsi deteksjonen for person A bli aktivert.

Dette vises ved at man får opp meldingen: «Epilepsialarm aktivert». Dersom man trykker på

Figur 37C, Lagret vekt for person B i filen

Figur 37A, Vekt tastes inn for person B Figur 37B, Vekt vises på displayet for person B

Figur 37 resultater person B


Rev: v1.2 44(62) 06.06.16

«Epilepsi_A_off» vil epilepsi deteksjon for person A, bli deaktivert. Dette vises ved at man får opp

meldingen «Epilepsialarm deaktivert». De to siste knappene vil ha samme funksjon, bare at de

aktiverer og deaktiver epilepsi deteksjon for person B.

Figur 38, Epilepsi A on

Figur 39, epilepsi A off

Figur 40, epilepsi B on

Figur 38A, Trykker på Epilepsi_A_on Figur 38B, Epilepsialarm er aktivert, trykk ok

Test “Epilepsi_A_on”

Figur 39A, Trykker på Epilepsi_A_off Figur 39B, Epilepsialarm er deaktivert, trykk ok

Test “Epilepsi_A_OFF”

Figur 40A, Trykker på Epilepsi_B_on Figur 40B, Epilepsi alarm er aktivert, tykk ok

Test “Epilepsi_B_on”


Rev: v1.2 45(62) 06.06.16

Figur 41, B off


Vi kan se at epilepsi blir aktivert og deaktivert, både for person A og person B

6.3.4 Modul Piping

Denne modulen ble brukt av flere funksjoner i GUI. For å teste modulen under utvikling, måtte vi hele

tiden følge med hvor vi var i programmet. Dette er fordi det er mye som går galt når man skal

kommunisere mellom to asynkrone prosesser. Samtidig skulle man også sørge for at begge

programmene stoppet opp på samme plass, og leste/skrivet til pipen. Visst dette ikke skjedde, ville

ett eller begge programmene henge. Så hver endring vi gjorde underveis i utviklingen, ble grundig

testet før vi gjorde noen endringer.

Denne modulen er ikke direkte testet, når vi testet hele GUI programmet. Den har imidlertid blitt

indirekte testet, da med tanke på at vi har sendt/mottatt data via pipen under testens forløp.

6.4 Slutt test (komplett system test)

Dette er en test som ble utført på det ferdige systemet. Denne testen ble utført for å kunne sjekke at

hele systemet fungerte som det skulle, og at vi ikke fikk noe bugs, når de forskjellige programmene

skulle snakke sammen etter implementasjon på RPI. Den første komplette system testen vi hadde,

avdekket et støyproblem. Støyproblemet ble løst ved å implementere et throw-away filter, dette

filteret er beskrevet i 5.3.9. Men utenom dette fungerte systemet som det skulle.

I senere tid kjørte vi en ny komplett system test, fremgangsmåte med resultater er som følger.

6.5 Test av komplett system For å teste det komplette systemet var det viktig at vi fikk så realistiske forhold som mulig. Derfor

hadde vi en seng, som vi plasserte opp på veiecellene, se figur NN. Vi koblet også opp en ruter slik at

vi fikk et felles nettverk, hvor vi koblet oss til styringsenheten med mobil og Pc. Det første vi gjord var

å test alle knappene og tekstboksene. I listen under fremgår det hvilken knapp eller innskrivings boks

som ble testet, samt utfallet av testen.

Figur 41A, Trykker på epilepsi_B_off Figur 41B, Epilepsi alarm deaktiver, trykk ok

Test “Epilepsi_B_off”


Rev: v1.2 46(62) 06.06.16

Figur 42, Veiecelle montert på seng

1. «Kalibrer»

Dersom Kalibrerings knappen blir aktivert skal vekten nullstilles slik at man får 0 Kg som

utgangspunkt. Dette betyr at det er kun egenvekten til sengen eventuelt dyne og pute som

skal være tilstede. Her ser vi at vekten blir nullstilt og 0 Kg vises på skjermen

2. «Hent vekt»

Dersom Hent vekt knappen blir aktivert skal vekten til vedkommende som befinner seg i

sengen vises på displayet. En på gruppen som veier rundt 86 kg legger seg i sengen.

Utfall: Klikker på Kalibrerings knappen:

Utfall: Klikker på «Hente vekt» knappen:

Figur 43, kalibrering

Figur 44, Hent Vekt


Rev: v1.2 47(62) 06.06.16

3. «Sett person A»

Dersom Sett person A blir aktivert skal vekten som er skrevet inn i ruten ovenfor bli lagret,

slik at programmet skal kunne skille mellom to personen. Disse kaller vi for person A og

person B. Den lagrede vekten skal så vises i ruten under knappen, for å indikere vekten til

personen. Dersom ingen vekt er lagret for Person A, vil «sett Kg» vises i ruten.

Her kan vi se at 70.1 Kg er taste inn i feltet, etter knappen er blir aktivert vises den lagrede

verdien i ruten under.

4. «Sett Person B»

Sett person B har samme utfall som for person A, bare att alt skjer i ruten for person B.

5. Epilepsi aktiver / deaktiver

Her vil utfallet på displayet bli slik som det var beskrevet i simulerings delen for Epilepsi side

6.3.3.1 under avsnitt «Resultater fra test epilepsi for «Person A» og «Person B»»

Dersom man har aktivert epilepsi deteksjon for person A eller person B, vil ett grønt lys lyse i

5 sekunder dersom vedkommende har epilepsi. Dersom man deaktiverer epilepsi

deteksjonen vil ikke lyset lyse derom vedkommende har epilepsi. Epilepsi deteksjons

programmet er laget slik at man må ha en viss frekvens innenfor et viss intervall. Dette er for

å unngå «falsk alarm» dersom personen beveger seg i sengen.

Utfall: Skriver inn 70.1 og trykker på «Person A»:

Utfall: Skriver inn 89.8 og trykker på «Person B»:

Figur 45, Person A

Figur 46, Person B


Rev: v1.2 48(62) 06.06.16

Siden vi ikke har mulighet til å få testet sengen med en person som har epilepsi, risten vi i

sengen med frekvenser som et epilepsianfall vil generere. Vi foretar to tester hvor personen i

sengen beveger seg, og en ved simulert epilepsianfall.

Her ser vi at dersom personen beveger seg i sengen vil ikke det bli tolket som et

epilepsianfall. Først når en simulerer et anfall vil epilepsialarmen gi utslag og slå på et grønt

lys.

En av hovedfunksjonene til dette systemet er å slå på belysning i rommet dersom vedkommende

beveger seg ut av sengen. For å teste dette la en på gruppen seg oppi sengen og reiset seg ut av

sengen. I tabellen under på den første raden er tiden fra personen begynte å reise seg til han var ute

av sengen. På den andre raden er tiden fra personen reiste seg til belysningen i rommet ble aktivert.

Test2. Personen simulerer ett epilepsianfall:

Test1. Person beveger seg i sengen:

Figur 47, status epilepsi lys


Rev: v1.2 49(62) 06.06.16

Tid oppreist (sekunder)

Tid lys aktivert (sekunder)

4,7 4,0

5,1 4,8

6,1 5,5

6,8 6,3

5,5 4,7

5,1 4,3

5,9 5,1

3,9 3,3

5,1 4,6

5,1 4,7 Tabell 5, Aktiverings tid av belysning

6.5.1 Konklusjon komplett systemtest

Som vi kan se ovenfor, virker systemet som forventet. Men under denne testet fremkom et nytt

problem. Vi hadde nemlig et støyproblem, som ikke har blitt oppdaget tidligere.

Systemtesten viste at ADC-modulene, av og til ga ut veldig høye eller lave verdier. For at dette ikke

skulle påvirke systemet, implementerte vi et spesiallaget filter som oppdaget disse spikene og fjernet

dem. Dette er ingen perfekt løsning, men PGA tidspress hadde vi ikke tid til å skifte ADC-typen vi

brukte. Dette er heller lagt som en utvidelse av oppgaven.

Figur 49, Støy spikes ADC

Her kan en se spikene som oppleves i løpet av ca. 5 min.

Vi kjørte en ny test for denne problemstillingen, etter at vi hadde implementert ThrowAway-filter

modulen. Og systemet fungerer nå som ønsket.

Figur 48, person reiser seg fra sengen


Rev: v1.2 50(62) 06.06.16

6.6 TCP/IP Server

TCP/IP serveren er testet etter punktene nedenfor. Betingelsene nedenfor har blitt skrevet etter

mange testfaser, og danner grunnlaget for de viktigste testpunktene. Testkrav og feil som kan oppstå

for denne modulen:

Et klientprogram må lages for å simulere ekstern tilkobling. Klient programmet må kunne

sende forespørsler for ned lasting av database filen. Klienten må kunne motta database filen

i mindre datamengder om gangen.

Server programmet må lytte og kjøre kontinuerlig uten at programmet krasjer, eller avslutter

på grunn av ukjent feil.

Serveren skal kun sende database filen ved kun to kommandoer fra klienten. Alle ugyldige

kommandoer må bli ignorert av serveren.

Serveren kan godta opptil to klienter samtidig, men skal håndtere kun en klient om gangen.

Serveren til enhver tid skal lytte etter forespørsler fra alle IP adresser, men kun kommunisere

via en bestemt port.

Den overførte database filens størrelse skal sjekkes mot det mottatte database filen på klient

siden. Database filene på begge sider skal være 100 % like store, det må være null feil

toleranse på fil størrelsene. Dette er for å unngå korrupte fil.

TCP/IP modulen har blitt testet etter punktene ovenfor. Klient programmet kobler seg til med sin

egen IP adresse, via en bestemt port til serveren. Serveren lytter etter innkommende forespørsler fra

alle IP adresser. Under etableringen av forbindelsen kan visse nettverksfeil oppstå. Disse feilene

fanger vi ved hjelp av Pythons egen catch funksjon. Dette stopper ikke serveren å kjøre videre, da

kjøres serverkoden på nytt. Ved fullført forbindelse skal serveren først sende en velkomstbeskjed,

klienten skal få kunne svare tilbake ved å enten sende q/Q som svar tilbake. Disse kommandoene

skal få serveren til å sende database filen. Serveren skal i utgangspunktet servere to klienter

samtidig, men dette står ikke i prioriteringslisten vår. Vi skal kun trygt sende filen til klienten, uten at

den blir korrupt underveis.

7 Diskusjon

7.1 Vurdering av fremdriftsplanen

I begynnelsen av prosjektet har den planlagte fremdriftsplanen blitt fulgt nøye og systematisk.

Fremdriftsplanen har ikke blitt fulgt til punkt og prikke, på grunn av små endringer som måtte foretas

underveis. Tillegg oppstod faren ved at vi måtte operere på ukjent terreng. Tap av tid og teknisk

utfordringer, kunne skape negative ringvirkninger og sette hele prosjektet i fare. Utenom disse små

problemene, støtte vi på en uforutsett teknisk hindring i en tidlig fase av prosjektet. Dette problemet

måtte løses for å gå videre i prosjektet. Ved hjelp av intens undersøkelse og eksternt faglig råd, klarte

vi å komme på rett spor igjen. Til tross for problemene som oppstod lå vi likevel foran tidsskjemaet,

både når det gjaldt drivere, ADC, GUI og hovedprogrammet.

7.2 Windows IoT og Raspberry Pi 2

Hjertet av prosjektet er RPI, sammen med operativ systemet Windows IoT, skulle prosjektet vårt

settes ut i livet. Rådataene fra sensorene skulle bli behandlet av C++ programmene, vi hadde skrevet.

Prosessert og klargjort data skulle videre bli presentert grafisk til brukeren. GUI delen skulle bli


Rev: v1.2 51(62) 06.06.16

implementert ved hjelp av C#. Utfordringen med et slikt system, var å kunne utveksle data mellom

C++ og C# programmene.

RPI måtte støtte en av operativ systemene vi hadde tilgjengelig for oss. Valgene stod mellom

Windows IoT og Raspbian, som er et Linux basert OS. Windows IoT var mer aktuell siden vi allerede

var bekvem og kjent med Visual Studio miljøet, og kunne lettere operere med Windows OS. Raspbian

var det anbefalte operativ systemet for RPI, men det var basert på Linux Debian, noe som var ukjent

for de fleste av oss. Vi var kjent med Linux OS, men hadde ikke nok teknisk innsikt. Problemet vårt

med Windows IoT, oppstod da vi skulle utveksle data mellom GUI og resten av de andre modulene.

For å ta et eksempel, skulle hovedprogrammet i C++ sende vekten til en av personene til C#, og dette

skulle vises på GUI skjermen. Med et arsenal av gode IPK protokoller, mislykkes vi med å

implementere en passelig IPK protokoll. IPK protokoller har standard virkemåte for alle OS, utenom

noen veldig få. Det har ikke vært noen baktanke med hvordan vi skal realisere en aktuell IPK

protokoll, dette var rett frem. Med en del prøving og feiling, kunne vi konkludere med at Windows

IoT manglet noen kommunikasjons mekanismer. Dette var noe vi ikke helt klarte å avgjøre, ettersom

vi manglet IPK kunnskap. I starten gjorde vi ikke vi nok undersøkelser, på Windows IoT platformen,

noe som førte til stopp i framdriften. IPK er et uunnværlig element i et kommunikasjon miljø, spesielt

hvis programmerings språkene er forskjellige. Så lenge vi klarte å lage koden for IPK, var det en

selvfølge at OS plattformen skulle iverksette IPK mellom modulene. Egentlig kom IPK problemet helt

uforventet.

Et annet problem som oppstod var togglingen av GPIO pinnene på RPI. Klokke signalene fra RPI GPIO

klarte ikke å toggle ADC-ene fort nok, for normal operasjon. Dette fikset vi ved å inkludering et annet

bibliotek.

7.3 Linux og Raspberry Pi 2

Etter flere mislykket forsøk på IPK med Windows IoT, gikk vi over til Linux Raspbian OS, og benyttet

Python som programmeringsspråk. Selv om vi lå foran fremdriftsplanen, kunne overgangen fra

Windows til Linux, føre til enda mer avgrenset tidsskjema, og økning av antall timer per ressurs.

Foruten tidsproblemer, kunne kompleksiteten til det nye OS og Python være uoverkommelig på

gjenværende tid av prosjektet. Vi utrettet gjenbruk av C++ kodene på Python. Tilpasningen av Python

programmering på Linux ble fullført uten noe store vanskeligheter. Systemet var oppe uten at vi

måtte skrive om alle kildekodene. Overgangen til Linux og Python var smertefritt, og ikke så

krevende. Bruker grensesnittet til utviklingsprogrammet til Python, PyCharm, som vi brukte var

forståelig og oversiktlig. Navigasjon i PyCharm kunne ikke påklages, i mange tilfeller var det lettere å

bruke PyCharm, enn Visual Studio. GUI designing med Flask var likevel krevende og mindre interaktiv

enn C#, her ble det lagt inn en del timer i GUI designet. Vi kan ikke la vær å nevne Pythons API.

Python hadde veldig mange støtte for ekstern API. Bibliotekene gjorde jobben vår betydelig lettere.

Programmer som Flask og Sqlite, er basert på Python språket og har Python API. Pythons og Linux’

faglige felleskap på internett var uvurderlig. De fleste av programmene er open source. Vi fant det

meste av faglig litteratur vi så etter, på internett.

7.4 Risikoliste evaluering

Dersom vi reflekterer over noen punkter fra risikolisten, har vi blitt påvirket av tekniske problemer og

noen tidsfrister har blitt overgått. Tekniske problemer er noe som vi har forutsett siden starten av

prosjektet. Sannsynligheten for slike typer problemer har vært høy, det essensielle her har vært


Rev: v1.2 52(62) 06.06.16

hvordan vi skal imøtekomme, og finne en løsning til disse problemene. Problemet med IPK har vært

mest problematisk og tidskrevende. Derfor måtte vi bruke ekstra ressurser, og vurderte andre

løsningsalternativer, som kunne føre til endring i kravspesifikasjoner eller overgå tidsfristen for

bachelor oppgaven. Kilden til overgåtte tidsfrister stammer fra GUI og IPK problematikken. Dette har

tungt oss til å planlegge fremdriften på nytt.

8 Konklusjon Vi har laget et helhetlig system som oppfyller alle gjenstående Kravspesifikasjoner. Noen krav falt

bort på grunn av at arbeidsgiver mente omfanget ble for stort og hadde liten betydning for

oppgaven. Ønsket resultat er derfor oppnådd og systemet fungerer som ønsket.

Fire veieceller er forbundet med en prosesseringsenhet. Systemet klarer å bestemme tilstanden på et

lys, slik at lyset tennes når en person er på vei ut av sengen. Systemet kan også detektere

epilepsianfall og varsle til eventuelle helsepersonell. Systemet logger vekt og vil på forespørsel sende

loggen til ekstern server. Dette gir mulighet for videre analyse av søvn kvalitet og vekt endring.

Systemet kommuniserer via Wi-Fi og kan derfor konfigureres via GUI, tilgjengelig via nettleser.

Den helhetlige løsningen, som systemet tilbyr, gir et godt grunnlag for økt livskvalitet og kan spare

samfunnet for store kostnader. Ved å forhindre fallskader, detektere epilepsi og logge vekt, kan

systemet assistere helsepersonell i å ta bedre beslutninger. Systemet kan brukes i store

helseinstitusjoner samt i private hjem.

Vi jobbet ut i fra hovedfaser. Ved å jobbe trinnvis gjennom fasene fikk vi god innsikt i fremgangen av

oppgaven. Arbeidsformen ga oss også motivasjon til å fortsette da vi regelmessig fikk en følelse av

progresjon. I gruppen er alle enige i at denne arbeidsformen passer godt til en Bachelor oppgave.

I løpet av oppgavens varighet har vi dannet noen ideer om mulige utvidelser av oppgaven. I denne

delen vil vi legge frem noen forslag, for oppgaver som viderefører og forbedrer det vi har laget.

Vi har brukt ferdige ADC moduler for å komme raskt i gang, og fordi modulene var billige og lett

tilgjengelig. Her ser vi det finnes forbedringspotensial. ADC modulene vi bruker ga oss tilfeldige

spikes som vi måtte fjerne med et throwaway filter. Vi foreslår at prosjektet kan utvides med en

dedikert kretskortløsning som plugges direkte inn i GPIO porten på RPI. Dette kretskortet kan

inneholde ADC instrumenteringsforsterker med frontend. Kretskortet kan også ha et rele for å

kontrollere lys, samt en alarm for varsling av epilepsi. Denne utvidelsen vil gi god kontroll av sampling

rate samt en mer tilpasset frontend.

Det kan designes en tilleggsmodul til systemet, bestående av en tre-akse akselerometer, som samler

inn data for behandling av prosesseringsenheten. Dette kan gi et bedre inntrykk av søvnkvalitet, samt

brukes for korrelasjon med data fra veiecellene.

Når vi har samlet søvndata, sendes dette videre til en ekstern server. En utvidelse kan da være å lage

algoritmer for tolkning av innsamlede data, samt å få presentert resultatene grafisk på en slik måte at

helsepersonell kan dra klarere konklusjoner fra resultatet.


Rev: v1.2 53(62) 06.06.16

Vi ser at når vi setter en seng oppå veiecellene, kan det oppstå situasjoner der en kraftig bevegelse

kan forårsake at senga faller av, spesielt hvis senga har hjul. En forbedring på dette vil være å

redesigne veiecelle festene slik at dette ikke skjer.

I gruppen har samarbeidet vært utmerket. Uoverensstemmelser ble enkelt løst med diskusjon og

drøfting av problemstillingen. Selv om gruppens medlemmer hadde forskjellige ansvarsområder,

klarte vi likevel å opprettholde tverrfaglig samarbeid. Vi er veldig fornøyd med arbeidet lagt inn i

oppgaven.


Rev: v1.2 54(62) 06.06.16

Litteraturliste Referanser

FOUNDATION, R. P., 2016. RASPBERRY PI 2 MODEL B. [Internett]

Available at: https://www.raspberrypi.org/products/raspberry-pi-2-model-b/

[Funnet 15 04 2016].

Høgskolen i Bergen, 2016. Om høgskolen. [Internett]

Available at: http://www.hib.no/om-hogskolen/

[Funnet 25 04 2016].

Lifehacker, 2011. What Is the .NET Framework, and Why Do I Need It?. [Internett]

Available at: http://lifehacker.com/5791578/what-is-the-net-framework-and-why-do-i-need-it

[Funnet 20 03 2016].

Microsoft, 2016. Overview of the .NET Framework. [Internett]

Available at: https://msdn.microsoft.com/en-us/library/zw4w595w(v=vs.110).aspx

[Funnet 16 03 2016].

Microsoft, 2016. Windows Dev Center. [Internett]

Available at: https://developer.microsoft.com/en-us/windows/iot/iotcore

[Funnet 16 03 2016].

Norsk epilepsiforbund, 2016. HVA ER EGENTLIG EPILEPSI?. [Internett]

Available at: http://www.epilepsi.no/medisinsk-/hva-er-epilepsi/

[Funnet 02 04 2016].

Stackoverflow, 2010. http://stackoverflow.com/. [Internett]

Available at: http://stackoverflow.com/questions/2724864/what-is-the-difference-between-c-sharp-

and-net

[Funnet 03 05 2016].

Wikipedia, 2015. Høyskolen i Bergen. [Internett]

Available at: https://no.wikipedia.org/wiki/H%C3%B8gskolen_i_Bergen

[Funnet 21 04 2016].

Wikipedia, 2016. Wikipedia. [Internett]

Available at: https://en.wikipedia.org/wiki/Universal_Windows_Platform

[Funnet 12 04 2016].

Wikipedia, 2016. Windows API. [Internett]

Available at: https://en.wikipedia.org/wiki/Windows_API

[Funnet 18 04 2016].


Rev: v1.2 55(62) 06.06.16

Forkortelser og ordforklaringer

Forkortelse Betydning Beskrivelse

ADC Analog to Digital Converter Konverterer analoge spenningsverdier til digitale bitverdier

DOUT Digital out Navn på digitale utgangsignal

FIFO First In First Out Datastrømningsprinsipp der den første data inn kommer først ut

FPGA Field Programmable Gate Array Programerbar kretskobling

GUI Graphical User Interface Grafisk brukergrensesnitt

HIB Høyskolen I Bergen Institusjonen vi studerer ved

IPK Inter prosess kommunikasjon Metode for to prosesser å kommunisere

RPI Raspberry Pi 2 En mini datamaskin

RTC Real time clock En virkelig tid klokke

SCK Serial ClocK Seriell klokkesignal

TCP Transmission Control Protocol Transmisjon protokoll som håndterer tap av pakker

Wi-Fi Wireless Fidelity Trådløs transmisjon

IP Internet Protocol Kommunikasjons protokoll

SW SoftWare Programvare

HW HardWare Fysiske komponenter/moduler

FFT Fast Fourier Transform Algoritme brukt i digital signalbehandling

UDP User Datagram Protocol Minimal nettverksprotokoll


Rev: v1.2 56(62) 06.06.16

Prosjektledelse og styring

C.1 Prosjektorganisasjon

For å realisere dette prosjektet på en god og effektiv måte, var det kritisk at vi planla og fordelte

arbeidsoppgaver riktig. Vi lagde derfor en strukturert plan i starten av prosjektet som beskriver hva

som må gjøres, og hva hver av oss har ansvar for.

Ansvarsområder

Ove Lylund hadde ansvaret for den analoge delen av prosjektet, dette området er fra veiecellene og

frem til RPI. Han skulle også håndtere økonomien og tok vare på alle billag. Joakim Vindenes sitt

område var Operativ System (OS) og trådløskommunikasjon, han håndterte også bestillingene som

ble gjort i forbindelse med prosjektet. Daniel Oppegaard hadde ansvaret for SW og drivere, han var

også prosjektleder. Muhamed Ali Ahmed hadde ansvaret for GUI, og all kommunikasjon enheten har

med omverdenen, han var også representanten som kommuniserte med intern og ekstern rådgiver.

Arbeidsoppgaver

Ove Lylund startet å jobbe med den analoge biten, da han var ferdig med dette hjalp han til med SW,

og driver delen av prosjektet. Joakim Vindenes hjalp til med den analoge delen, da denne delen var

relativt kritisk for at vi fikk testet drivere og SW. Deretter jobbe han med OS, trådløs kommunikasjon,

SW og drivere. Muhamed Ali Ahmed jobbet med GUI og enhetens kommunikasjon. Daniel Oppegaard

jobbet med SW og drivere, han hjalp Muhamed med GUI, da dette var et nytt emne som krevde en

del arbeid.

Vi var alle tilgjengelig for å hjelpe hverandre, vi roterte også utover det som var fastsatt, visst det var

nødvendig. For mer detaljert informasjon henvises det til Microsoft Project filen, se plassering av

filen i Appendiks F .

C.2 Prosjektform

Vi har valgt en egendefinert prosjektform, hvor prosjektet ble delt inn i fire hoved faser. Hver av disse

modulene hadde en milepæl som ble oppfylt med et ferdig dokument, samtidig som vi valgte å være

litt fleksible. Dette ga oss muligheten til å «flyte» litt over i de andre fasene, før milepælen var

oppnådd.

De forskjellige modulene

De fire forskjellige modulene var:

Forprosjekt

Design

Produksjon

Test

I forprosjektet planla vi selve prosjektet, fordelte arbeidsoppgaver og ansvar. Vi utarbeidet en

kravspesifikasjon og fant ut hvilke deler som skulle bestilles. Da dette arbeidet var fullført, endte

denne fasen med milepælen «forstudie». I design stadiet gikk vi mer i detalj rundt de forskjellige

arbeidspakkene. Vi har delt arbeidspakkene inn i kategorier som vi har valgt å kalle analog, digital

(SW og drivere) og IT (GUI, OS og internettside). Her gikk vi mer i dybden på hva de forskjellige


Rev: v1.2 57(62) 06.06.16

kategoriene og arbeidspakkene inneholdt, samt beskrive fremgangsmåten. Vi definerte hvordan de

forskjellige arbeidspakkene skulle bli, med tanke på oppførsel og utseende. Her tok vi også med

ferdig status for de respektive pakkene. Når denne fasen var over endte den opp i en milepæl

«Spesifiserte krav», som inneholdt det vi konkluderte med i fasen. I produksjonsfasen fulgte vi

«oppskriften» vi hadde laget i design fasen. Det var her det faktiske arbeidet ble gjort, og de ferdige

arbeidspakkene ble som beskrevet i designfasen. Vi koblet sammen komponentene til et helt system,

deretter laget vi et dokument som inneholdt resultater fra de mindre testene. I testfasen testet vi det

komplette systemet grundig, for å luke bort eventuelle feil. Her verifiserte vi også at sluttproduktet

faktisk fungerte. Denne fasen ble avsluttet med en testrapport for det komplette systemet.

Oversikt over modellen:

Figur 50, Prosjektmodell

Denne prosjektmetoden sørget for at prosjektet ble godt planlagt, samtidig som at man fikk følelsen

av fremskritt når man kom forbi en milepæl. Det ble også lett å holde oversikt over prosjektet,

samtidig som at man fikk testet systemet på en grundig måte. Man ville også kjenne igjen

prosjektmodellen i fremdriftsplanen.

C.3 Fremdriftsplan

Fremdriftsplanen ligger vedlagt som flere PDF dokument. Vi har første og siste versjonen vedlagt,

disse inneholder datoer, milepæler og gant-skjema. Den siste versjonen er delt opp i tre forskjellige

versjoner, som ikke viser samme informasjon. En versjon viser tekst, en med detaljert gant-skjema og

et skjema med mindre detaljer.

Se Appendiks F ,for plassering av filene.


Rev: v1.2 58(62) 06.06.16

C.4 Konklusjon Siden vi prioriterte å lage en god plan for hvordan denne oppgaven skulle løses, hadde vi til enhver

tid klart for oss, hvordan vi lå an i forhold til det som måtte gjøres. Dette medførte at vi tilslutt greide

å komme i mål, uten å gjøre store endringer som gikk på bekostning av produktet.

C.5 Risikoliste

Nr Risiko Sannsynlighet

(1-10) Alvorlighetsgrad

(1-10) Konsekvens Formildelse

1 Overgår

tidsfrister 4 7 Forsinket

levering.

Oppdragsgiver

godkjenner ikke

oppgaven.

Kutte ned på arbeidsmengde.

Planlegge godt.

Endre på kravspesifikasjon.

2 Overgå

budsjett 1 5 Finansiere fra

egen lomme.

Planlegge innkjøp godt.

3 Sykdom 3 5 Får ikke utført

arbeid. En eller flere studenter hjelper

til med tapt arbeid.

4 Mottar feile

eller defekte

komponenter.

2 9 Får ikke satt opp

systemet.

Når ikke

tidsfrister.

Bestille deler fra en annen

leverandør. Bestille flere

eksemplarer.

5 Tekniske

problemer

med HW eller

SW

5 5 Systemet vil ikke

fungere.

Systemet

oppfører seg

uforutsett.

Debugge og teste SW flere

ganger.

Teste om HW fungerer.

6 Lagret arbeid

går tapt

1 8 SW må

programmeres

om igjen.

Tidsfrister blir

ikke holdt.

Lagre de viktigste filene til

enhver tid og ta backup et

annet sted enn pcen.

Tabell 6 Risikoliste


Rev: v1.2 59(62) 06.06.16

Skjemadesign Koblingsskjema:

Figur 51 koblingsskjema


Rev: v1.2 60(62) 06.06.16

Tabell og figur liste Tabell 1, IPK protokoller ........................................................................................................................ 32

Tabell 2, Testresultat "Test Hent vekt" ................................................................................................. 41

Tabell 3, Testresultat Person A .............................................................................................................. 42

Tabell 4, testresultat "Person B" ........................................................................................................... 43

Tabell 5, Aktiverings tid av belysning .................................................................................................... 49

Tabell 6 Risikoliste ................................................................................................................................. 58

Figur 1 Originalt system oppsett ........................................................................................................... 10

Figur 2 Blokkdiagram av systemet ......................................................................................................... 12

Figur 3 Kort systemoversikt (løsning 1) ................................................................................................. 14

Figur 4 Grov oversikt, analogt blokkskjema .......................................................................................... 14

Figur 5, Level konverter uten tilkoblingskontakter ............................................................................... 17

Figur 6, AD-modul uten tilkoblingskontakter og Shield ........................................................................ 17

Figur 7, AD-modul med tilkoblingskontakter og Shield ......................................................................... 17

Figur 8, Level Converter med tilkoblingskontakter ............................................................................... 17

Figur 9, Kretstegning av Power distribution board ............................................................................... 17

Figur 10, Power distribution board ....................................................................................................... 17

Figur 11, Lukket boks ............................................................................................................................. 18

Figur 12, 2. etasje boks .......................................................................................................................... 18

Figur 13, 1. etasje boks .......................................................................................................................... 18

Figur 14, Første SW løsning ................................................................................................................... 19

Figur 15, Rekkefølgen av funksjoner i main .......................................................................................... 22

Figur 16, GUI layout løsning 1 ............................................................................................................... 24

Figur 17 Kommunikasjonsoversikt ........................................................................................................ 25

Figur 18, andre SW løsning .................................................................................................................... 25

Figur 19, Tredje løsning ......................................................................................................................... 26

Figur 20: Fanging av feil ......................................................................................................................... 27

Figur 21: Mains biblioteker og funksjoner ............................................................................................ 27

Figur 22, Utdrag fra datablad, timingdiagram (HX711) ......................................................................... 28

Figur 23, illustrering av lineariseringsprosess ....................................................................................... 29

Figur 24, illustrasjon av formel .............................................................................................................. 29

Figur 25, database modul ...................................................................................................................... 31

Figur 26, FIFO pipe protokollen ............................................................................................................. 32

Figur 27, blokkdiagram TCP/IP .............................................................................................................. 33

Figur 28, test fremgangsmåte for hovedprogram ................................................................................. 35

Figur 29, Testresultat av ferdig ADC-driver ........................................................................................... 36

Figur 30, test av epilepsi-driveren ......................................................................................................... 37

Figur 31, test resultat hovedprogram ................................................................................................... 37

Figur 32, status for lys ........................................................................................................................... 38

Figur 33, GUI test under utvikling (funksjon) ........................................................................................ 39

Figur 34, GUI modul test og utvikling .................................................................................................... 39

Figur 35, Hent Vekt resultater ............................................................................................................... 41

Figur 36, resultater person A ................................................................................................................. 42


Rev: v1.2 61(62) 06.06.16

Figur 37 resultater person B .................................................................................................................. 43

Figur 38, Epilepsi A on ........................................................................................................................... 44

Figur 39, epilepsi A off ........................................................................................................................... 44

Figur 40, epilepsi B on ........................................................................................................................... 44

Figur 41, B off ........................................................................................................................................ 45

Figur 42, Veiecelle montert på seng ...................................................................................................... 46

Figur 43, kalibrering ............................................................................................................................... 46

Figur 44, Hent Vekt ................................................................................................................................ 46

Figur 45, Person A.................................................................................................................................. 47

Figur 46, Person B .................................................................................................................................. 47

Figur 47, status epilepsi lys .................................................................................................................... 48

Figur 48, person reiser seg fra sengen .................................................................................................. 49

Figur 49, Støy spikes ADC ...................................................................................................................... 49

Figur 50, Prosjektmodell........................................................................................................................ 57

Figur 51 koblingsskjema ........................................................................................................................ 59


Rev: v1.2 62(62) 06.06.16

Innhold i zip-fil og plassering av programkode Innholdsliste av informasjon i vedlagt zip-fil.

«prosjektfiler\Finans», inneholder budsjettet og en mappe med kvitteringer.

«prosjektfiler\Kode», ligger to mapper som inneholder programmeringskoden vår.

«prosjektfiler\Datablad», inneholder alle datablad til komponentene i systemet.

«prosjektfiler\Planlegging\prosjekt_planlegging\final», ligger det tre filer som viser

prosjektstyringen vår.

«prosjektfiler\Planlegging\prosjekt_planlegging\project_fil», inneholder MS-project-filen.

«prosjektfiler\Planlegging\Timeliste_Prosjektlogg», inneholder timelisten og prosjektloggen.

Documents

Omsorgsbasert Sengevekt - HVLhome.hvl.no/ai/elektro/2016/BO16E-25.pdf · Omsorgsbasert Sengevekt Rev: v1.2 3(62) 06.06.16 Forord Denne bacheloravhandlingen er en videreutvikling av