Resultat av vald implementation

• PRUSSen med PRU-k¨arnorna ¨ar redan integrerade i BBB, s˚a ingen extra h˚ardvara tillkom- mer som i fallet med en FPGA.

• PRU-k¨arnorna kan programmeras i vanlig C, ett av v¨arldens mest spridda spr˚ak, vilket ¨aven kan anv¨andas p˚a Linuxsidan. En FPGA kr¨aver att programmeras i specialdesignade spr˚ak som VHDL

• PRU-k¨arnorna kan utf¨ora stabil sampling helt oberoende av belastningen p˚a ARM-k¨arnan och ARM-k¨arnans resurser frig¨ors f¨or att t.ex. utf¨ora analys av datan. Under RTLinux s˚a ARM-k¨arnans resurser delas av b˚ade samplingen och ¨ovriga uppgifter.

Nackdelar med PRUSS:

• M¨ojligheten att k¨ora systemet p˚a annan h˚ardvara ¨an BBB begr¨ansas kraftigt, kostnaden att migrera systemet till ny h˚ardvara ¨okar.

E.6

Diskussion

E.6.1

Resultat

E.6.1.1 1 kHz sampling med PRU

D˚a SPI-transaktionerna endast tog 70µs s˚a skulle systemet allts˚a i teorin klara en samplingsfre- kvens p˚a ¨over 16 kHz. Det som sedan s¨atter gr¨ansen f¨or att g˚a ¨annu snabbare ¨ar inte PRU:n utan D/A- och A/D-omvandlaren, vilken inte klarar h¨ogre hastighet p˚a SPI-linan ¨an den som f¨or nuva- rande anv¨ands. PRU:ns SPI-drivrutin inneh˚aller mycket v¨anteinstruktioner f¨or att SPI-enheterna ska h¨anga med i kommunikationen. Med b¨attre D/A- och A/D-omvandlare s˚a skulle PRU:n allts˚a kunna klara ¨annu h¨ogre hastigheter ¨an 16 kHz.

E.6.2

Metod

E.6.2.1 Val av PRUSS

Att anv¨anda PRUSS f¨or att implementera realtidsfunktionaliteten valdes tidigt i projektet baserat p˚a att ingen extra h˚ardvara skulle beh¨ovas och det d˚a var det billigaste alternativet. PRU-k¨arnorna k¨andes ¨aven som att de l˚ag n¨armast de erfarenheter av sm˚a mikrokontrollers som AVR som gruppen hade. Det fanns allts˚a kompetens inom den typen av system, till skillnad ifr˚an realtidsoperativsy- stem som RTLinux, vilket ingen hade erfarenhet av.

Att konfigurera PRUSSen och lyckas exekvera kod p˚a PRU-k¨arnorna visade sig dock inte s˚a trivi- alt som f¨orst antaget. Att sedan designa ett kommunikationsgr¨anssnitt mellan PRU-k¨arnorna och Pythonprogrammet i Linux via det delade RAM-minnet var ocks˚a n˚agot som tog mycket tid. S˚ah¨ar i efterhand s˚a kanske RTLinux hade varit ett lika bra eller b¨attre alternativ som PRUSSen ¨

and˚a. Ingen av dem har n˚agon extra h˚ardvarukostnad, men det kan t¨ankas att RTLinux kanske hade varit billigare i tidskostnad f¨or att implementera systemet p˚a. Mer ing˚aende efterforskningar i f¨orstudien om hur mycket RTLinux egentligen skiljer sig ifr˚an ett vanligt Debianbaserat Linux- system hade kunnat lett oss till att g¨ora annorlunda val.

E.7

Slutsatser

BeagleBone Blacks PRUSS har visat sig utan problem klara av uppgiften att utf¨ora sampling i 1 kHz, utan ytterligare dyr h˚ardvara. PRUSSen skulle tillochmed kunna anses ¨overkvalificerad f¨or en s˚adan enkel uppgift och arbetskostnaden f¨or implementationen kanske inte var helt justifierad om f¨ordelarna ¨over ett realtidsoperativsystem inte anses tillr¨ackligt stora.

F. Magnus - Kravframst¨allning

F.1

Inledning

Jag har, i egenskap av analysansvarig f¨or detta projekt, valt att till¨agna min individuella del i kandidatrapporten till att unders¨oka hur man p˚a b¨asta s¨att kommer ¨overens med kunden om vilka krav som skall st¨allas p˚a projektet.

F.1.1

Syfte

Mitt syfte med denna rapport ¨ar att bli b¨attre p˚a att ta reda p˚a kundens egentliga krav i ett mjukvaruprojekt. Ofta kan kunden inte svart p˚a vitt s¨aga exakt hur produkten skall se ut. Det kan bero p˚a att kunden saknar teknisk kunskap inom omr˚adet eller kanske inte t¨ankt p˚a viss funktionalitet som egentligen g¨or produkten b¨attre.

F.1.2

Fr˚agest¨allning

• Vad ¨ar viktigt att t¨anka p˚a n¨ar man specificerar krav? • Hur p˚averkade kravinh¨amtningsprocessen v˚art projekt?

F.1.3

Avgr¨ansningar

Rapporten behandlar endast ingenj¨orsprojekt inom mjukvarukonstruktion.

F.2

Bakgrund

V˚ar projektgrupp har arbetat med ett projekt som heter dricksvattenkvalitet. Uppgiften var att ers¨atta ett befintligt system som upplevdes som on¨odigt komplext och dyrt. Systemet ska konti- nuerligt utf¨ora tester f¨or att detektera abnorma substanser i ett vattenfl¨ode. Best˚andsdelarna i sy- stemet ¨ar m¨atenheter som ska implementeras p˚a enkortsdatorer(Beaglebone) samt en centralicerad server/databas som kommunicerar med samtliga enheter. Det ska ¨aven finnas ett anv¨andargr¨anssnitt som ska fungera som en kontrollpanel f¨or m¨atstationerna. De fundamentala delarna av syste- met(den kontinuerliga m¨atningen) var kunden tydlig med hur den skulle se ut men resterande delar var kunden inte lika s¨aker p˚a och tyckte var mycket sp¨annande att ha 6(7) dataingenj¨orsstudenter som fick tycka till om uppl¨agget. Framf¨or allt ans˚ag kunden att gr¨anssnittet till det tidigare syste- met var ”icke-responsivt¨och tr˚akigt och s˚ag g¨arna att vi var kreativa och kom med egna ideer n¨ar vi designade det. Efter ett flertal kundm¨oten kom vi fram till en kravspecification som alla parter var n¨ojda med.

F.3

Teori

Med kravinh¨amtningsprocess inom mjukvara, menas de aktiviteter som f¨oretag och mindre projekt- team m˚aste utf¨ora tillsammans med best¨allare/kund, f¨or att specifiera exakt vilken slutprodukt som skall utvecklas och vilken funkntionalitet som skall kr¨avas av den. Sommerville, Ian har listat f¨oljande aktiviteter som han anser b¨or ing˚a i kravinh¨amtningsprocessen. (Sommerville, 2010)

• “Requirement elicitation” Detta handlar om att samla in l¨ampliga krav till systemet fr˚an slutanv¨andare, kunder och ¨ovriga intressenter f¨or projektet.

• “Requirement identification” Identifiera nya krav

• “Requirement specification” Framst¨all ett dokument som listar vilka krav som kommer st¨allas p˚a slutprodukten (kravspecifikation).

• “System modeling” Best¨am ¨overgripande modellering av systemet. H¨ar ¨ar det vanligt att man jobbar med generella objektorienterade spr˚ak som UML (uml , u. ˚a.)

• “Requirement validation” Verifiera att de dokumenterade kraven och modellerna ¨ar rimliga och tillm¨otesg˚ar kund/best¨allares behov.

• “Requirements management” Hantera f¨or¨andringar i kraven under systemets utveckling.

F.4

Metod

Jag har, genom att genomf¨ora detta projekt, erh˚allit erfarenheter som kommer att ligga tillgrund f¨or de slutsatser jag kommer dra i min rapport. Jag har ¨aven diskuterat med kunden hur denne anser att kravinh¨amtningen gick f¨or att f˚a feedback. F¨or att bredda mina vyer ytterliggare har jag l¨ast n˚agra vetenskapliga artiklar fr˚an n¨atet som behandlar detta ¨amne.

F.5

Resultat

Nedan kommer jag att redovisa mina reslutat.

F.5.1

Analys av projektet

I v˚art projekt lade vi ett ganska stort fokus p˚a kravinh¨amtningsprocessen. Det tror jag har gynnat oss oerh¨ort mycket. Kunden delade v˚ar uppfattning att en utf¨orlig kravframst¨allning var n˚agon som skulle prioriteras.

Innan vi b¨orjade koda och designa hade vi flera m¨oten med kunden d¨ar vi diskuterade hur den officiella kravspecifikationen skulle utformas. Kunden hade tillsammans med sina kollegor p˚a IFM redan f¨orberett en grov kravspecifikation som beh¨ovde modifieras och brytas ned till detaljniv˚a. Till exempel s˚a byggde den kravspecifikationen p˚a att en extra h˚ardvarukomponent (Labjack-T7) skulle ing˚a i konstruktionen f¨or att g¨ora synkron pulsgenerering/pulsavl¨asningen m¨ojlig. Vi visste dock att detta skulle kunna genomf¨oras med hj¨alp av realtidsprocessorerna p˚a Beaglebonen. Vi k¨ande ¨aven att flera av kraven i kundens kravspecifikation var f¨or allm¨anna och ”icke-m¨atbara”.

¨

Aven om vi f¨orstod vad kunden efterfr˚agade i de flesta fall s˚a k¨ande vi oss mer komfortabla med mer konkreta krav. Detta medf¨orde att vi spenderade mycket tid ˚at Sommerville’s tredje aktivitet, att analysera kraven tillsammans med kund. Kravens inneb¨ord kanske inte alltid st¨ammer ¨overens med hur projektgruppen ser p˚a dem. Det ¨ar viktigt att man ser till att vara ¨overens om allting. Kunden hade inte heller specifierat n˚agon ¨overgripande design ¨over systemet. S˚a vi presenterade en l¨osning med en centraliserad server som kommunicerar med alla enheter. Denna server f¨oreslog vi skulle k¨ora en webserver. Att vi i ett tidigt skede best¨amde dessa grova designval var viktigt. Om man i ett sent skede i projektet skulle bli oense med kunden om fundamentala designbeslut blir det mycket som m˚aste g¨oras om, vilket blir dyrt och f¨ordr¨ojer projektet.