Omsorgsbasert Sengevekt - HVLhome.hvl.no/ai/elektro/2016/BO16E-25.pdf · Omsorgsbasert Sengevekt...
Transcript of Omsorgsbasert Sengevekt - HVLhome.hvl.no/ai/elektro/2016/BO16E-25.pdf · Omsorgsbasert Sengevekt...
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.
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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å
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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)
Omsorgsbasert Sengevekt
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)
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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)
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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».
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Fungerer ikke korrekt
Funksjon 1 og 2
Test funksjon 1 og 2 Test feilet eller
Fungerer ikke korrekt
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
Fungerer ikke korrekt
Test feilet eller
Fungerer ikke korrekt
Test feilet eller
Fungerer ikke korrekt
Test modul 1 og 2
Modul 1 og 2
Modul 1 og 2 er ferdigstilt
Programmet er ferdig
Test feilet eller
Fungerer ikke korrekt
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Nr. Input Output Tid fra Input til Output vises på display
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
Omsorgsbasert Sengevekt
Rev: v1.2 43(62) 06.06.16
6.3.2.1.2 Konklusjon
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
Nr. Input Output Tid fra Input til Output vises på display
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"
+
6.3.2.1.4 Konklusjon
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
Omsorgsbasert Sengevekt
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”
Omsorgsbasert Sengevekt
Rev: v1.2 45(62) 06.06.16
Figur 41, B off
6.3.3.1.1 Konklusjon
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”
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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].
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
Rev: v1.2 59(62) 06.06.16
Skjemadesign Koblingsskjema:
Figur 51 koblingsskjema
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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
Omsorgsbasert Sengevekt
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.