Forprosjekt ELECTRONIC TROLLEY FENCE

Transkript

1 Forprosjekt ELECTRONIC TROLLEY FENCE 1

2 Gruppe HØGSKOLEN I SØR-TRØNDELAG Avdeling for teknologi Program for elektro-og datateknikk 7004 TRONDHEIM Forprosjekt Oppgavens tittel: Dato: Electronic Trolley Fence Project title: Electronic Trolley Fence Gruppedeltakere: Lars Martinsen, Thomas Andrew Durrans, Ronny Pettersen og Magnus Lysgård Program/studieretning: Antall sider/bilag: 19 Veileder (navn/ /tlf.): Stein Øvstedal stein.ovstedal@hist.no Prosjektnummer: AFT/ Teleteknikk og Elektronikk 7 Oppdragsgiver: Atmel A/S Kontaktperson hos oppdragsgiver (navn/tlf.): Morten Werner Lund Tilgjengelig etter avtale med oppdragsgiver X v 2

3 SAMMENDRAG På Oslo Sentralbanestasjon har de den senere tid hatt store problemer med tap av bagasjetraller. Det forsvinner ca 50 traller hvert år. Dette viser seg å være en så stor økonomisk belastning at de vurderer å installere et system som sikrer trallene. Atmel har i denne anledning laget et hovedprosjekt som de ville ha utført av HiST avdeling for teknologi. Oppdragsgiver har siktet seg inn på bruk av deres AVR-mikrokontrollere og Zigbee teknologi for å lage et elektronisk gjerde. Hensikten med prosjektet blir å finne ut om det er mulig å lage et velfungerende elektronisk gjerde med denne teknologien. I dette forprosjektet har gruppen lagt vekt på å definere oppgavens rammer, mål og struktur. Det har vært viktig å sette reelle og klare rammer rundt oppgaven. Rammen Vi skal i første omgang fokusere på helt enkle vinklinger, men vil på et senere tidspunkt i prosjektet vurdere utvidelser. Utgangspunktet vårt består i å ta i bruk dagens teknologi for å lage et system som kan lokalisere objekter innenfor et definert område. Dette skal gjøres ved hjelp av AVR-mikrokontrollere og RF teknologien Zigbee. Systemet skal bestå av fire stasjonære sensorer(st) og et mobilt system i trallen(mt).. En av ST ene defineres som master, og skal ha et grensesnitt mot PC. Alle ST ene kommuniserer trådløst med hverandre. Kommunikasjon mellom trallen og ST ene vil foregå trådløst med Zigbee protokollen IEEE Den viktigste grunnen for valg av protokoll var energibruk og pris. Prosjektmål Videre har vi satt stort fokus på å utforme godt definerte prosjektmål. Målene er delt opp i effektmål, resultatmål og prosses mål. Effektmålet er å redusere antall forsvunne bagasjetraller på Oslo S. med 70 %. Prosjektorganisering For å kunne gjennomføre et prosjekt av denne størrelsen, er det vesentlig å ha god struktur. Gruppen består av fire studenter. Vi har fordelt ansvarsområder og oppgaver etter kvalifikasjoner og ønske. Videre er det laget et gantt-diagram og en beskrivelse av arbeidspakker for hele oppgaven. Materielle ressurser står oppdragsgiver for. Gruppens arbeidstimer defineres som oppgavens hovedressurs. Det er i tillegg definert fem punkter som beskriver kvalitetssikringen av prosjektet. 3

4 FORORD Bakgrunnen for denne rapporten er å definere problemstillingen. Videre vil rapporten sette prosjektets realisme og verdi i søkelyset. Prosjektgruppens fire medlemmer har jobbet med denne i cirka en uke ved avdeling for teknologi ved HiST. Innholdet er ment å være grunnlaget for hele oppgaven. Oppdragsgiver og veileder skal bruke forrapporten sammen med prosjektgruppen som en veiledende ramme rundt prosjektet. Prosjektgruppen vil rette en takk til Atmel for tildelig av prosjektet. 4

5 Innhold 1. INNLEDNING Bakgrunn Oppgaveteksten Definisjoner TEKNISK DEL Problemstilling Utvikling dagens situasjon Oppbygging av systemet og valg av teknologi Kalibrering Tidligere resultater og erfaringer Prosjektmål Effektmål Resultatmål Prosessmål Prosjektbeskrivelse Spesifikasjoner Tillegg Problemområder Forprosjekt Deloppgaver Tidsramme Ansvarlig Deltakere Forskning Deloppgaver Tidsramme Ansvarlig Deltakere Transceiveren

6 Deloppgaver Tidsramme Ansvarlig Deltakere Sensor Deloppgaver Tidsramme Ansvarlig Deltakere Datagrensesnitt Deloppgaver Tidsramme Ansvarlig Deltakere Implementering og testing Deloppgaver Tidsramme Ansvarlig Deltakere Produksjon av transceiveren Deloppgaver Tidsramme Ansvarlig Deltakere Administrasjon Deloppgaver Tidsramme Ansvarlig Deltakere PROSJEKTORGANISERING Prosjektdeltakere

7 4.2 Utstyr og ressurser Arbeidsplass Utstyr Ressurser videre i prosjektet Prosjektleveranser Doukmentleveranser Tekniske leveranser Tids- og kostnadsplan Kvalitetssikring Statusrapportering Standardiserte skjemaer Spesifisere tester i en testplan Utarbeide sjekklister Utarbeide dokumentplan VEDLEGG Kilder

8 1. INNLEDNING 1.1 Bakgrunn Det forsvinner type 50 bagasjetraller på Oslo Sentralbanestasjon hvert år. For å få bukt med problemet vurderer de å installere et system som sikrer trallene. Atmel har engasjert studenter ved HiST for se på mulige løsninger. Hensikten med prosjektet blir å finne ut om det er mulig å lage et velfungerende elektronisk gjerde med Zigbeeprotokollen og AVR- mikrokontrollere. 1.2 Oppgaveteksten Formålet med oppgaven er å bli kjent med bruk av AVR-mikrokontroller (MCU) i RF applikasjoner med fokus på embedded C++ programmering og embedded system design. Oslo sentralbanestasjon har ca 500 bagasjetraller som er tilgjengelig for passasjerene til NSB. Hvert år forsvinner det ca 50 traller fra området. For å forhindre dette ønskes et system som gjør trallene ubrukelig utenfor sentralbanens område. Hver tralle har en mekanisk lås som kan styres elektronisk. Låsen skal slås på hvis trallen befinner seg en viss avstand fra en eller flere fastmonterte RF sendere som befinner seg innenfor sentralbanestasjonens område. Oppgaven består i - Inngående forstudie av AVR mikrokontrollere - System design - Design av kretskort (for tralle og for "elektronisk innhegning") - Software design i Embedded C++ - Uttesting/evaluering av systemet Spesifikasjon tralle - Hovedprosessor: AVR mikrokontroller - Lavkost 2.4GHz RF MT. ZigBee er en mulighet - Low power. Min. 1 års driftstid - Lav kost Spesifikasjon "elektronisk innhegning" - Hovedprosessor: AVR mikrokontroller - Lavkost 2.4GHz RF MT. ZigBee er en mulighet - Grensesnitt mot PC for overvåking av trallene - Lav kost 8

9 1.3 Definisjoner MT = mobil transiver ST = stasjonær transiver RSSI = Received Signal Strength Indicator Ad-hoc = direkte tilkobling mellom to terminaler Winavr = C- kompilator i AVRstudio Embedded C++ = programeringsspråk (her brukt til mikrokontrollere) C++ = programmeringsspråk AVRstudio = applikasjonsgrensesnitt mot AVR-produkter Stk500 = fysisk grensesnitt mellom PC og mikrokontroller RS-232 = seriell kommunikasjonsport Zigbee-protokollen = kommunikasjonsprotokoll for trådløse personlige datanettverk 2. TEKNISK DEL 2.1 Problemstilling Utvikling dagens situasjon Posisjoneringssystem med Zigbee-protokollen er en ny og spennende teknologi i utvikling. Systemene som er i bruk i dag har store svakheter. Svakhetene er dårlig rekkevidde- og nøyaktighet som følge av alle hindringer vi har innendørs. Utvikling av et billig og brukervennlig system som kan brukes hjemme og i industrien, vil lette oppgaver som i dag er tidkrevende. 9

10 2.1.2 Oppbygging av systemet og valg av teknologi Systemet skal bestå av fire stasjonære ST'er og et MT-system (i trallen). Modulen i trallen skal bestå av en RF-del og en mikrokontroller. De stasjonære transiverene skal også hver bestå av en RF-del og en mikrokontroller. En av de ST ene defineres som master og skal ha et grensesnitt mot PC. Alle ST ene kommuniserer trådløst med hverandre. Kommunikasjon mellom trallen og ST ene vil foregå trådløst med Zigbee protokollen IEEE Den viktigste grunnen for valg av protokoll var energibruk og pris. Zigbee oppfyller disse kravene og bruker i tillegg det åpne frekvensbåndet på 2.4GHz. Atmel som er gruppens prosjektgiver har spesialisert seg på utvikling av mikrokontrollere. I oppgaven må vi legge stor vekt på effektforbruk. Mange av Atmel's produkter krever lite effekt og er av mange ansett som markedes beste i sin kategori. Vi skal bruke en 8 bits mikrokontroller. Hver transceiver sender sin adresse. Alle ST ene lytter og finner signalstyrke. Dette blir sendt til master som beregner posisjonen til trallen. Hvis trallen er utenfor det definerte området sender master beskjed til trallen, og på trallen tennes da en rød lysdiode. Hvis vognen er innefor definert område skal ingen lysdioder lyse, dette for å spare strøm. Når MT ikke har kontakt med noen ST er har vi mange mulige løsninger. Dette har prosjektgruppa valgt å ta stilling til senere i prosjektet, når vi har bedre oversikt på hvordan systemet kommer til å oppføre seg Kalibrering Det skal settes opp 4 ST'er, en i hvert hjørne i en firkant. Denne firkanten definerer det tillatte område. Hver ST måler signalstyrke fra de tre andre ST ene. Disse tre signalstyrkene angir minimalt tillat signalnivå. Synker signalet fra trallen under ett av disse nivåene, vet vi at trallen er utenfor det definerte området. Fordeler Den store fordelen med denne måten er at man slipper å gå rundt med en tralle og kalibrere manuelt. Veldig brukervennlig Enkelt å sette opp Enkelt å oppdatere Trådløs kommunikasjon mellom ST ene Begrensninger Begrensningen med denne måten er at ST'en må stå i hjørnene på firkanten. Alt bak ST'en er definert som utenfor. Området blir begrenset til rette linjer mellom ST ene Må fysisk flytte ST'en for å omdefinere området. 10

11 2.1.3 Tidligere resultater og erfaringer Prosjektgruppen har i forprosjektet lest tidsskrifter og rapporter fra lignende prosjekter. Inntrykket vi sitter igjen med er at utvikling av posisjoneringssystem kan være problematisk. Problemene er mange, men bruk av signalstyrke(rssi) peker seg ut som den største utfordringen. Se vedlegg ref(1)-rapport Prosjektmål Effektmål Redusere antall forsvunne bagasjetraller på Oslo S med 70 % Resultatmål Ha et ferdig system som kan bestemme om bagasjetrallen er innefor eller utenfor et definert område og bestemme posisjonen med en nøyaktighet på under 10m. Ha et system som oppfyller krav om strømforbruk, dvs. behov for service > 1år. Ha et system som oppfyller Atmel's krav om et prisgunstig produkt. Ferdigstille prosjektet til 11. Mai Prosessmål Kompetansebygging, lære å beherske Atmel's utviklingsverktøy. Oppnå B eller bedre som sluttkarakter Utvikle samarbeidsegenskaper og erfaring med prosjektarbeid. 2.3 Prosjektbeskrivelse De to første ukene i prosjekttiden brukes til forprosjekt. Her inngår definisjon av oppgaven og bestemmelse av spesifikasjoner. Den neste uken blir brukt til å forske på utstyret. Dette innebærer utprøving av forskjellige funksjoner, testing av signalstyrke som funksjon av avstand og lignende. Disse resultatene er viktig å ha når vi skal utvikle den matematiske modellen. Konstruksjon av transceiveren og ST'en kan skje samtidig. Disse har høyest prioritet. Når et av parene er ferdig med den oppgaven begynner de på grensesnitt mot PC. Deretter kobles alt sammen og testes. Viser det seg at vi har god tid til rådighet kan flere funksjoner legges til. Hvis tidsskjemaet holder satser vi på å lage et kretskort for transceiveren og få dette produsert. Underveis i hele perioden vil alle resultater bli dokumentert. 11

12 2.4 Spesifikasjoner Systemet skal i utgangspunktet bestå av fire ST'er og en MT. MT Hver transceiver sender sin adresse AT86RF230 Radiodel med Zigbee-protokollen, IEEE ATmega1281 Tar denne som utgangspunkt, i og med at den er den samme som i demonstrasjonssettet. Hvis vi greier oss med en enklere utgave, velger vi det. ST 1 Master og 3 slaver AT86RF230 Radiodel med Zigbee-protokollen, IEEE ATmega1281 Tar denne som utgangspunkt, i og med at den er den samme som i demonstrasjonssettet. Hvis vi greier oss med en enklere utgave, velger vi det. Peer to peer topologi (Ad-hoc) Master trenger ikke å ha direkte kontakt til alle ST ene. Datagrensesnitt Status på vognene: kontakt / ikke kontakt Ca posisjon i meter. Konvertering mellom signalstyrke og avstand i meter. Mulighet for å låse opp traller Tillegg Gul lampe når trallen beveger seg på grensen av tillat område. Batteri-status mot datagrensesnitt Bevegelsesensor, det er ikke vits å sende posisjon når trallen står i ro. LCD som gir brukeren informasjon hvis trallen er utenfor Høyttaler som forteller at MT er utenfor Lysdiode lyser opp en mørklagt tekst. For å gi brukeren beskjed om status. Gir god informasjon og bruker lite strøm. Dynamo for å tilføre strøm, vil også vise bevegelse Fargedisplay som viser reklame og annen nytteinformasjon når vognen er i bevegelse 12

13 2.5 Problemområder I et prosjekt er det flere forhold som kan lage hindringer for oss. Det kan være dårlig kompetanse, uriktig valg av teknologi og/eller personlige forhold. Under føler en liste over mulige problemer vi står overfor. For stor og for avansert oppgave med å utvikle matematiske algoritmer. For stor og for avansert oppgave med utvikling av C- koder. ZigBee brukt i posisjoneringssystem er relativt nytt. Et eksempel på utvikling av et slikt system er et prosjekt fra Sverige. Der ble det utviklet et innendørs posisjoneringssystem. Systemet skulle fungere med hindringer og refleksjoner i rommet. Problemet her var at det ikke ble målt lineær demping i RSSI selv om avstanden mellom kilden og målet økte lineært. Dette vil gjøre nøyaktig posisjonsbestemmelse vanskelig. Sykdom, uenighet eller andre konflikter i prosjektgruppen. 3 ARBEIDSPAKKER For å få en bedre oversikt, har prosjektet blitt delt opp i flere arbeidspakker. De samme arbeidspakkene blir å finne igjen i gantt-diagrammet. Dette gir en grei og oversiktligfremstilling. I dette punktet blir det forklart mer om hvert punkt. For å finne informasjon om timeforbruk og startpunkt se gantt-diagram 1.Forprosjekt. Her blir oppgaven definert. Administrative oppgaver bestemmes. Gruppen lærer seg programmeringsverktøyet. Det hele avsluttes med en forprosjektrapport. Deloppgaver A. Lage generelle spesifikasjoner B. Lage tekniske spesifikasjoner C. Lage hjemmeside D. Lære å bruke programmeringsutstyr E. Lage blokkskjema for hele systemet F. Skrive rapport fra forprosjekt G. Forprosjekt slutt Tidsramme 2 uker 150 timer Ansvarlig Thomas Deltakere Alle 13

14 2. Forskning Med dette menes utprøving av mikrokontrollere og ZigBee-protokollen. Da legges det spesielt vekt på forskning rundt rekkevidde, RSSI, Energy Detection, Link Quality Indication. Deloppgaver A. Utprøving av ZigBee B. Utprøving av aktuelle mikrokontroller Tidsramme 1 uke 50 timer Ansvarlig Lars Deltakere Alle 3. Transceiveren. Konstruksjon av transceiveren Deloppgaver A. Lage flytdiagram for transceiver B. Programmere transceiver C. Teste transceiver Tidsramme 2 uker 200 timer Ansvarlig Ronny Deltakere Thomas 14

15 4. Sensor. Sensormodulen konstrueres. Deloppgaver A. Lage matematisk modell B. Lage flytdiagram for sensor C. Programmere sensor D. Teste sensor Tidsramme 2.5 uke 250 timer Ansvarlig Magnus Deltakere Lars 5. Datagrensesnitt. Bestemme og programmere grensesnittet mot PC. Deloppgaver A. Lage flytdiagram for dataprogram B. Programmere dataprogram for PC C. Teste dataprogram Tidsramme 2 uke 200 timer Ansvarlig Lars Deltakere Alle 15

16 6. Implementering og testing. Etter at alt fungerer på egenhånd, kobles alt sammen og testes. Hvis det er god tid igjen, planlegges å legge til flere funksjoner. All utvikling skal skje ved hjelp av STK-500 Deloppgaver A. Koble alt sammen B. Teste hele systemet C. Hele systemet fungerer sammen D. Eventuelt implementere nye funksjoner Tidsramme 3 uker 300 timer Ansvarlig Thomas Deltakere Alle 7. Produksjon av transceiveren. Gruppen ønsker å lage et eget kort som skal plasseres i trallen. Her går det inn produksjon av kretskort, montering og testing. Deloppgaver A. Design av Transiveren B. Produsere kretskort C. Montere komponenter D. Slutt test Tidsramme 4 uker 350 timer Ansvarlig Thomas Deltakere Alle 16

17 8. Administrasjon. Skrive dokumentasjon, møtereferat, rapport, hjemmeside og lignende. Deloppgaver A. Møter B. Dokumentasjon C. Forberede fremføring D. Fremføring E. Levere rapport Tidsramme 17 uker 300 timer Ansvarlig Thomas Deltakere Alle 17

18 4 PROSJEKTORGANISERING Oppgavene som sekretær og møteleder vil rullere mellom alle medlemmene i gruppen, slik at alle vil få en viktig erfaring med dette. Vi velger å ha en 2 ukers rullering på oppgavene. Se figur. Uke 2 Uke 4 Uke 6 Uke 8 Gjentar seg syklisk Møteleder: Møteleder: Møteleder: Møteleder: Thomas Lars Magnus Ronny Sekretær: Sekretær: Sekretær: Sekretær: Lars Magnus Ronny Thomas Figur 1. Møteleder har som hovedoppgave å lede møtene, men også det overordnede ansvaret for at tidsfrister og de oppgaver som er avtalt blir gjort til rett tid. Sekretæren har ansvar for å skrive møtereferat og møteinnkalling. Møteleder og sekretær skriver den ukentlige rapporten i fellesskap, og har hovedansvaret med at timelistene blir lagt ved ukerapporten. Webansvarlig for hjemmesiden til prosjektet/gruppen er tildelt Ronny, her inngår kontinuerlig oppdatering og utlegg av filer. Magnus er med på å lage hjemmesiden, hvor det er brukt en tidligere hjemmeside for å spare tid. Her vil det bli lagt ut ukerapporter, møtereferat og andre administrative dokumenter. Rapportansvarlig for hovedprosjektrapporten er tildelt Thomas. Her inngår kontinuerlig oppdatering av rapporten, samt backup. 18

19 4.1 Prosjektdeltakere Thomas Andrew Durrans Hjemsted: Andebu kommune i Vestfold Født: 1980 Klasse: Teleteknikk Utdanning: Elektronikk fra videregående, realfagskurs på HIST Fagbrev: Telekommunikasjonsmontør Jobberfaring: 5 år i Bravida. Hovedsaklig med installasjon og feilretting av bredbåndstjenester. Kompetanse relevant for prosjektet: Lang erfaring innen feilsøking i det offentlige telenettet. Har også programmert hussentraler. Lars Martinsen Hjemsted: Fredrikstad Født: 1981 Klasse: Teleteknikk Utdanning: Serviceelektronikk på vgs. og lærling som Telekommunikasjonsmontør, Forkurs Fagbrev: Serviceelektronikk, Telekommunikasjonsmontør Tidligere arbeidsgiver: Elajo Jobberfaring: 3 år med alarmsystemer og felles koblingssystemer. Kompetanse relevant for prosjektet: Generell feilsøking. Programmering av alarmsentraler. 19

20 Magnus Widme Lysgård Hjemsted: Frei på Nord-Møre Født: 1981 Klasse: Teleteknikk Utdanning: Serviceelektronikk på vgs., Luftforsvarets befalskole, forkurs som privatist Fagbrev: Serviceelektronikk Jobberfaring: Luftforsvaret Kompetanse relevant for prosjektet: Spesialisering innen radiokommunikasjon. Ulike kurs innen navigasjon. 40 timers loddekurs. Ronny Petter Pettersen Hjemsted: Dønna i Helgeland Født: 1981 Klasse: Elektronikk Utdanning: 2 år på elektronikk før han valgte å gå allmennfaglig påbygging og realfagskurs. Fagbrev: Nei Jobberfaring: Diverse småjobber innen serviceelektronikk Kompetanse relevant for prosjektet: Litt mer kompetanse innen digitale kretser enn resten av gruppen. 20

21 4.2 Utstyr og ressurser Det trengs mye moderne utstyr for å gjennomføre prosjektet. Atmel som er vår arbeidsgiver og hovedressurs, skaffer det som trengs av komponenter og utstyr. I tillegg har Atmel flere personer som bistår ved spørsmål som måtte komme. Dette er til meget stor hjelp, i og med at mye av det grunnleggende som prosjektet bygger på er nytt for oss i prosjektgruppen. Dette gjør at man raskere kan få besvart de elementære spørsmålene som kommer i en oppstartsfase. Mange av de komponenter og moduler som trengs for å gjennomføre prosjektet er det Atmel som har utviklet, så noen bedre ressurs for å gjennomføre prosjektet kunne man ikke hatt Arbeidsplass Arbeidsplass er gitt gjennom skolen. I tilfeller der prosjektet krever noe mer teknisk utstyr og kunnskap enn det som prosjektgruppen innehar, har gruppen mulighet til å bruke Atmelhuset som arbeidsplass Utstyr Utstyr som prosjektgruppen har mottatt gjennom Atmel og skolen frem til nå, er utstyr for å gjøre seg kjent med systemene som skal brukes videre i prosjektet. Software Dette gjelder programvare som brukes til programmering og simulering av mikrokontrollere, AVR-studio med pluggin som WINavr. Dette programmet gjør at man kan skrive inn en kildekode i for eksempel C, som da kan kompileres til en spesifikk prosessor (embedded C). I AVR-studio kan man simulere programmer som er skrevet, samt feilsøke og modifisere. Man kan også se hvordan programmet påvirker de ulike prosessene og registrene i mikrokontrolleren. Hardware Grensesnittet mellom datamaskin og prosessor, er et koblingsbord kalt stk500. Denne har ulike sockets til de ulike mikrokontrollene som skal programmeres. Tilkopling skjer gjennom seriellporten i datamaskinen. Prosjektgruppen har også mottatt en JTAGICE mkii. Denne brukes til debugging av den ferdig programmerte mikrokontrolleren. Denne kobles opp mellom datamaskin og stk500, grensesnittet mot datamaskin er ub eller RS Med denne enheten koblet, kan man se hva som faktisk skjer i prosessoren etter at programmet er overført fra AVR-studio. Her kan man følge og overvåke hva som skjer i de forskjellige registrene, og på de ulike inn- og utgangene i mikrokontrollen. 21

22 Ressurser videre i prosjektet Det vil fremover bli nødvendig med flere ulike mikrokontrollere og ferdige moduler som Atmel har laget. Det vil blant annet bli brukt ulike moduler som Atmel har utviklet med tanke på Zigbee. Her finnes ferdige kit med transceivere og styreenheter for denne protokollen, samt ferdige radioenheter som er spesiallaget til dette formålet (RBC med AT86RF230). Dette vil gjøre at man blir kjent med Zigbee-protokollen og mulighetene denne har. Det vil også bli anskaffet flere stk500 kit og JTAGICE mkii. Slik kan flere programmere og gjøre seg bedre kjent med disse systemene samtidig. Ulike mikrokontrollere som har OSC-kompatibilitet vil også bli anskaffet. Det er mest sannsynlig en av disse mikrokontrollene som vil bli brukt i sluttproduktet. 4.3 Prosjektleveranser Doukmentleveranser Forrapport utarbeides til 19. januar. Uke-rapport leveres Atmel og veileder hver fredag. Hovedprosjekt-rapport leveres Atmel og veileder 14. mai. Møteinnkalling sendes ut minimum tre dager før hvert møte. Møtereferat sendes ut minimum to dager etter hvert møte. Hjemmesiden oppdateres kontinuerlig Tekniske leveranser Levere DAK-produkt for produksjon til Atmel Levere komplett system til Atmel ved prosjektslutt. 4.4 Tids- og kostnadsplan Se vedlegg 1 for gantt-diagram. Alle kostnadene under prosjekttiden blir dekket av oppdragsgiver. Dette er hovedsakelig komponenter gruppen trenger i utviklingen. I sluttrapporten vil det bli kalkulert pris på ferdig produkt. Akkumulert tidsforbruk kommer frem av gantt-diagram. Se vedlegg(1) 22

23 4.5 Kvalitetssikring For å kunne sikre at prosjektet når alle mål, innføres kvalitetssikring. Under følger 5 punkter som beskriver kvalitetssikringen Statusrapportering Hver uke leveres en uke-rapport til oppdragsgiver (Atmel) og gruppens veileder ved HiST, Stein Øvstedal. Denne rapporten skal inneholde følgende: Oppnådde mål/ milepæler i perioden Avvik, f. eks at mål ikke ble nådd til planlagt tid Oppgaver vi skal ha i den neste perioden Tidsforbruk i perioden vi har vært gjennom. Dette vil gi oppdragsgiver og veileder full oversikt over prosjektstatus. De vil også kunne gi prosjektgruppen konstruktive tilbakemeldinger og rettesnorer gjennom hele prosjektet Standardiserte skjemaer Prosjektgruppen vil bruke standardiserte maler på alle dokumenter som produseres. Se pkt 4.3 for dokumentliste Spesifisere tester i en testplan I gantt-diagrammet (vedlegg 1) er det satt av tid til test av de forskjellige modulene. Først skal hver modul testes alene, deretter skal hver modul implementeres inn. Det er beregnet god tid til dette arbeidet Utarbeide sjekklister HiST har utarbeidet en komplett sjekkliste for prosjektrapporten. Denne vil bli brukt i hele perioden Utarbeide dokumentplan Se pkt

24 VEDLEGG Vedlegg(1) -gantt-diagram Kilder Ref(1) 24