Forprosjektrapport. Utvikling av en værstasjon BO19-G36. Høgskolen i Østfold. Fredrik Forsell, Ivar Sandvik, Ernestas Budreika

Transkript

1 Forprosjektrapport Utvikling av en værstasjon BO19-G36 Høgskolen i Østfold Fredrik Forsell, Ivar Sandvik, Ernestas Budreika 8. Januar 2019

2 Innholdsfortegnelse Innholdsfortegnelse 1 Prosjektgruppen 2 Oppdragsgiver 2 Oppdraget 2 Formål 3 Leveranser 3 Metode 4 Prosjektplan 4 Innkjøp av komponenter 5 Analysere eksisterende database 5 Designe værstasjonen 5 Utvikle programvare for hovedenheten 5 Lage webgrensesnitt 6 Dokumentere oppsettet av komponenter 6 Montering av værstasjon 7 Gjennomføring 7 Referanser 8 1

3 1 Prosjektgruppen Fredrik Forsell kommer fra Stavanger, og bosatt i Halden under studietiden. Har erfaring i bruk av: C, C++, C#, Java, Javascript, HTML, CSS og Arduino. På fritiden liker han å lage applikasjoner for android- og Iphone telefoner. Ivar Sandvik, kommer fra Ås Akershus, og bosatt i Halden hvor han studerer dataingeniør. Har grunnleggende kompetanse innen programmering. Har jobberfaring som lærling i to år som IKT-Medarbeider og har også fagbrev i IKT. På fritiden liker han å spille spill og jobbe med egne programmeringsprosjekter utenfor skoletiden. Ernestas Budreika, bosatt i Fredrikstad hvor han studerer dataingeniør. Jobber som konsulent for et forsikringsselskap ved siden av utdanningen. Har grunnleggende kompetanse innen programmering, data og salg. På fritiden liker han å være med kameratene og se på filmer, serier. 2 Oppdragsgiver Oppdragsgiveren er fra Høgskolen i Østfold Project Hessdalen, et prosjekt som ble startet opp sommeren 1983 av oppdragsgiveren Erling Strand, sammen med venner. Grunnet lite aktivitet ble det startet et samarbeid med forskningsinstitusjonen Høgskolen I Østfold (HIØ). Etter prosjektets dannelse har det blitt installert et stort antall med instrumenter og sensorer med hensikten i å automatisere loggføringene av et verdenskjent lysfenomen kalt Hessdalsfenomenet. Etter overtakelsen av prosjektet har studenter fått muligheten til å fortsette utviklingen av den automatiske målestasjonen Hessdalen AMS (Automatisk Målestasjon). Oppdragsgiveren Erling Strand, er bosatt i Sarpsborg kommune. Han jobber som høgskolelektor ved avdeling for informasjonsteknologi på Høgskolen i Østfold. Han er også den nåværende lederen av Project Hessdalen. Grunnet en stor mediedekning har Erling holdt mange foredrag om hessdalen, inkludert TV- og radio program (Strand, 2018). Han har også arrangert et stort antall science camps i Hessdalen, hvor interesserte får mulighet til se og forske på Hessdalsfenomenet (Moan, 2015). 3 Oppdraget Hensikten med dette oppdraget er å undersøke et naturfenomen som regelmessig tar plass i Hessdalen (noen mil sør for Trondheim). Det verdenskjente naturfenomenet blir beskrevet som glødende kuler som svever i luften i Hessdalen. Det ble først oppdaget i 1981, hvor antallet registrerte forekomster økte de første årene. I en periode ble det sett opp til 20 lysende kuler i løpet av en uke. Dette antallet har sunket betraktelig, og det antatte antallet per år er nå 20 stk (Strand, 2010). 2

4 Ettersom de 2 forrige værstasjonene som var installert i Hessdalen sluttet å fungere (20. mars 2018) ville oppdragsgiver bruke denne muligheten til å bygge en ny og forbedret stasjon. Oppdragsgiver hadde forsøkt å fikse stasjonene, men dette ble problematiske da mikroprosessorene var kodet uten hensyn på at forandringer kunne oppstå. Stasjonene besto av sensorer for: temperatur, fuktighet, vindretning, og vindhastighet. De nevnte sensorene var installert på en Raspberry Pi (Kalmár, Linstad, Todorov, and Rokne, 2016). Oppdraget går ut på å installere to nye værstasjoner i Hessdalen. Disse værstasjonene vil bli plassert på et fjell i Trøndelag og må derfor være designet slik at de kan tåle et tøft klima, i tillegg til å registrere nøyaktige målinger. Stasjonene skal ha sensorer for å måle temperatur, fuktighet, lufttrykk, vindhastighet og vindretning. Kravet til arbeidsgiver er at han skal få 2 ferdigutviklede værstasjoner som måler presise verdier. Kravspesifikasjon vil bli diskutert med oppdragsgiver. 3.1 Formål Formålet med prosjektet er å gi oppdragsgiver og interesserte personer værdata fra Hessdalen slik at dette kan brukes for videre undersøkelse og analyse. Disse vær dataene må være nøyaktige og pålitelige slik at brukerne får en solid oversikt. Dataen skal også presenteres på en god måte slik at brukerne lett kan finne dataene de leter etter på et nettsted. Hovedmål 1: Designe og bygge 2 værstasjoner som fungerer i harde værforhold med tilhørende web-grensesnitt. 3.2 Leveranser Gruppekontrakt og prosjektkontrakt Hjemmeside Forprosjektrapport Første versjon av hoveddokumentet Andre versjon av hoveddokumentet Ferdig hoveddokument 3

5 3.3 Metode Først og fremst trenger vi å bestille komponentene som kan måle de forskjellige verdier som temperatur, fuktighet, lufttrykk, vindretning og vindhastighet. Deretter skal vi bruke Raspberry pi b+ som hovedverktøy som å få sensorer til å fungere slik oppdragsgiveren ønsker de skal fungere. Underveis må vi dokumentere alt, og beskrive hvorfor har vi tatt de forskjellige valgene. Vi skal bruke raspberry pi b+ å programmere på, grunnen til er at det er det enkleste og mest effektivt metode til å få alt til å fungere, finne riktig løsning og deretter finne feil. Vi har valgt å ikke bruke Arduino, siden den er ikke like rask som raspberry pi b+. Vi har valgt å benytte en iterativ utviklingsmetode for programvaren. Der vi deler oppgaven i flere aktiviteter (Techopedia, 2019) med gitte tidsrammer. Vi delegert ansvaret slik at gruppemedlemmene har ulike aktiviteter som de står ansvarlig for at blir ferdigstilt og levert innen gitte frister. Med dette vil vi unngå ansvarsfraskrivelser om det blir problemer med leveringen av den spesifikke delen av prosjektet. 4 Prosjektplan Vi tror at disse faktorene kan bli flaskehalser i prosjektet. - Bestilling og leveringstid på komponenter. - Aktiviteter som er avhengig at vi har tilgang til komponentene. Vi vil forsøke å unngå disse flaskehalsene ved å bestemme oss for hvilke komponenter vi trenger og bestille disse raskt. Vi kan også lese dokumentasjonen på hardwaren vi skal bruke før vi har tilgang på det slik at det går fort å implementere komponentene i koden. 4

6 Aktivitet 1: Innkjøp av komponenter 1. Start: Slutt: Ansvarlig: Alle gruppemedlemmer 4. Leveranse: Bestemme og bestille nødvendige komponenter for systemet. 5. Beskrivelse: Finne ut hvilke sensorer og komponenter vi trenger. Diskutere for å finne beste komponenter som vil tåle værforholdene over tid. Få innspill fra oppdragsgiver for komponentvalg. Aktivitet 2: Analysere eksisterende database 1. Start: Slutt: Ansvarlig: Fredrik Forsell 4. Leveranse: Database for lagring av måleverdier. 5. Beskrivelse: Det finnes en eksisterende database med værdata fra tidligere prosjekt. Oppdragsgiver vil at vi skal bruke denne databasen for nye måledata, slik at man har tilgang på eldre data og nye data i det samme grensesnittet. Aktivitet 3: Designe værstasjonen 1. Start: Slutt: Ansvarlig: Ernestas Budreika 4. Leveranse: Enheten som skal monteres i masten må designes altså hvordan komponentene er koblet sammen. De må deretter monteres slik at værstasjonen er ferdig. 5. Beskrivelse: Vi skal planlegge hvor komponentene skal plasseres og hvordan komponentene er koblet sammen. Dette inkluderer strøm og internett tilkobling. Aktivitet 4: Utvikle programvare for hovedenheten 1. Start: Slutt: Ansvarlig: Ivar Sandvik 4. Leveranse: Lage programvare som kjører på enheten som samler inn data og laster disse opp til databasen. Programvaren må være innen kravene gitt i hovedmålet. 5. Beskrivelse: Hovedenheten trenger programvare for å lese av måleverdier. Aktivitet 4.1: 1. Ansvarlig: Fredrik Forsell 2. Leveranse: Programkode for å lese av måleverdier og lagre disse i minnet eller harddisk. 5

7 Aktivitet 4.2: 1. Ansvarlig: Ivar Sandvik 2. Leveranse: Programkode for opplastning av data. Aktivitet 4.3: 1. Ansvarlig: Ivar Sandvik 2. Leveranse: Sette opp remote kontroll av enheten sine variabler. Aktivitet 4.4 (ekstra): 1. Ansvarlig: Alle gruppemedlemmene 2. Leveranse: Sette opp failsafe (overgang til mobilt internett ved nedetid). Aktivitet 5: Lage webgrensesnitt 1. Start: Slutt: Ansvarlig: Ivar Sandvik og Fredrik Forsell 4. Leveranse: Lage et webgrensesnitt for værstasjonen 5. Beskrivelse: Dette er en separat del av oppgaven som ikke er avhengig av at målestasjonen er aktiv da vi har eldre værdata som kan brukes til testing.. Det skal designes en nettside med mulighet for å se måleverdier over tid i graf format og tabellformat. Aktivitet 6: Testing av værstasjon 1. Start: Slutt: Ansvarlig: Fredrik Forsell 4. Leveranse: Teste værstasjon og verifisere resultater fra målinger. 5. Beskrivelse: Vi skal teste værstasjonen på campus før den settes ut i produksjon for å sjekke at alle komponenter fungerer og opplastingen av data fungerer. Aktivitet 7: Dokumentere oppsettet av komponenter 1. Start: Slutt: Ansvarlig: Ernestas Budreika 4. Leveranse: Dokumentasjon av produktet, hvordan komponentene har blitt koblet sammen. Og en generell oversikt over komponentene. 5. Beskrivelse: Det skal dokumenteres hvordan systemet er bygget opp. 6

8 Aktivitet 8: Montering av værstasjon 1. Start: Slutt: Ansvarlig: Ernestas Budreika 4. Leveranse: Sette opp værstasjonene i Hessdalen. 5. Beskrivelse: Vår oppdragsgiver skal være i Hessdalen den første uken av April og kan være med oss å sette opp værstasjonen i masten. Dette gir oss mulighet til å installere utstyret tidlig slik at vi kan rapportere og få innsikt om den fungerer etter spesifikasjonene gitt at værstasjonen er ferdig med programvare. 5 Gjennomføring Ved møter: Vi i gruppen har avtalt å møte hverandre minst 3 ganger i uken for å jobbe felles med prosjektet og siden oppdragsgiveren våres er så sentral, kan vi avtale møte med han for aktuell tilbakemelding og hjelp underveis. Ved unntak: Hvis en av gruppemedlem er syk eller utilgjengelig med virkelig god grunn, kan vi avtale skype møter, hvis det er mulighet for det, for å jobbe og/eller fordele oppgavene, slik at han kan jobbe selvstendig hjemmefra eller diskutere med resten av gruppa. Rollene i gruppen skal rullere seg mellom prosjektleder, møteansvarlig og kvalitetsansvarlig, slik at hvert gruppemedlem får forskjellig ansvar hver 5 uker. Når vi først har kommet i gang, fått de forskjellig komponenete og verktøy gruppen trenger for prosjektet, så vil det gå helt greit å jobbe distribuert med de forskjellige oppgavene, men målet blir alltid å samarbeidet med prosjektet. Prioritering av oppgavefordeling skal gå til medlem som mest spesialiserer seg best i det, for å holde kvalitet og gjennomføre prosjektet på best mulig måte. Vi som gruppe skal kommunisere mest gjennom messenger på facebook, skype for videomøter og bruke mest mail og messenger for å kommunisere med oppdragsgiver og veileder, når vi trenger eller må. Målet blir å få montert komponentene og få de til å fungere med de verktøyene vi skal bruke. Det er mye vi må også undersøke, hvilken værforholdene de forskjellige komponentene skal tåle, slik at de ikke blir ødelagt, hvor lang tid det vil ta for å få de delene etter vi har bestilt, hvor mye det vil koste. Hvis vi virkelig sitter fast på prosjektet så blir målet å kontakte oppdragsgiveren eller veileder for hjelp. 7

9 Referanser Kalmár, N., Linstad, M. R., Todorov, M., and Rokne, R.W. (2016). Linux-based command and control for off-grid research facility. Kalmár, N., Linstad, M. R., Todorov, M., and Rokne, R.W. (2016). Linux-based command and control for off-grid research facility. Moan, M. (2015). Science Camp i Hessdalen. Nea Radio. Techopedia (2019). What is Iterative Development?. Techopedia. Strand, E. P. (2018). Erling P. Strand. 8