6 Slutsats
6.1 Projektutvärdering
6.2.1 Systemfunktionalitet för flera enheter
Hantering av flera enheter önskas från Sogetis håll (se bilaga A.2.4.3). Därför innehar de träffentiteter som hanteras i databasen en enhetsidentitet, som ämnar representera den Raspberry-enhet som försett träffen.
I nuläget har visningsklienten endast funktionalitet för att uppvisa en träffyta, som visualiserar alla träffar i databasen oavsett dess enhetsidentitet. De träffar som simuleras i testapplikationen skickas in som träffentiteter till databasen med en viss enhetsidentitet, så även denna applikation kan utökas för att möjliggöra hanteringar av flera enheter.
Implementerad funktionalitet för flera Raspberry-enheter bör påverka visningsklientens, och isåfall även testapplikationens, utseende. Varje Raspberry-enhet borde i användargränssnittet representeras av en egen träffyta, med tillhörande resultatrutor. Träffsimuleringsprocessen skulle isåfall kunna fungera så att, beroende på i vilken träffyta en träff simuleras, så skickas den till databasen med en respektiv enhetsidentitet, som sedan resultatberäknas och visualiseras i en representerande användargränssnittsdel.
De frågor som uppstår kring en sådan implementation är hur många sådana träffytor som är möjligt och lämpligt att visualisera, samt huruvida visualiseringen görs utifrån hur många enheter som kopplats till systemet eller om alla möjliga träffytor visualiseras oavsett hur många sådana enheter som upptäckts.
6.2.2 Datahämtning och användargränssnittsuppdatering
Den nuvarande prototypen utnyttjar manuell användaruppdatering av dess användargränssnitt. De träffentiteter som befinner sig i databasen vid uppdateringstidpunkten läses in från databasen till en lista. Detta leder till att alla träffar hämtas från databasen vid ett tillfälle, istället för att databaskommunikation måste ske för varje träff då de hanteras var för sig. En optimal lösning för systemet vore om sådan datahämtning och uppdatering kan ske automatiskt utan användarinput. En sådan lösning skulle eventuellt kunna implementera tekniken SignalR, som beskrivs i avsnitt 3.7.3. Tekniken implementerar ett bakplan som sköter meddelandeprocessen mellan servrar och klienter enligt en publish/subscribe-metod. Systemet skulle då kunna, ungefär som en chattapplikation, kunna upptäcka att information har skickats från Raspberry-enhetens applikation och att informationen i databasen således förändrats. Därigenom skulle visningsklienten således förstå att den behöver hämta denna nya information på egen hand, och att därefter resultatberäkna och visualisera den i användargränssnittet.
Om det således finns funktionalitet i visningsklienten implementerad för hantering av fler enheter (se avsnitt 6.2.1), så behöver denna datahämtning och uppdatering eventuellt ske asynkront beroende på vilken enhet som ursprungligen skickat informationen, vilket påverkar i vilken användargränssnittsdel som informationen behöver visualiseras.
6.2.3 Enhetlig API-implementation
Eftersom applikationen som finns i Raspberry-enheten kommunicerar med databasen genom ett API, kan det eventuellt vara intressant att sköta all kommunikation mellan databasen och visningsklienten på samma sätt för att hålla systemet så enhetligt som möjligt. Enligt uppdragsgivaren så föredras en sådan enhetlig lösning om ett API anses vara nödvändigt i de applikationer som Sogeti utvecklar; framtida eventuella ändringar i systemet behöver isåfall endast utföras i API:t istället för i flera systemkomponenter.
Eftersom API:t redan är färdigutvecklat och utför dess avsedda uppgift (se avsnitt 5.3.1), så behöver endast visningsklientens funktionalitet modifieras; istället för att kommunicera direkt med databasen genom ramverket Entity Framework så utförs detta genom API:t med HTTP-begäranden.
6.2.4 Systemets databassäkerhet
De eventuella säkerhetsbrister som systemet har är de åtkomstregler som kan sättas för databasen, samt den uppkopplingssträng som kopplar visningsklienten till den. Sådana brister i systemets säkerhet kan leda till att obehörig åtkomst till server och databas förekommer och att data däri påverkas.
De åtkomstregler som i nuläget gäller för databasen är de brandväggsregler som kan sättas för både den Azure SQL-server som innehåller databasen, samt även enskilt för varje enskild databas i servern för ytterligare åtkomstkontroll. Sådana regler håller reda på de IP-adresser som tillåts åtkomst till servern och därigenom dess databaser.
Under utvecklingsprocessen av applikationen frågas huruvida den uppkopplingssträng som däri används för åtkomst till databasen ska innehålla känslig information eller ej. I nuläget antogs denna lösning vara god nog för en prototyp, men möjlighet finns att låta en användare under exekvering förse applikationen med de inloggningsuppgifter som krävs. Möjligtvis kan en implementationslösning där sådana uppgifter läses in från separata konfigureringsfiler även vara relevant.
Sådana lösningar kan således i autentiseringssyfte koppla behöriga användare till databasåtkomst utifrån de uppgifter eller filer som de tilldelas, istället för att all åtkomst tillåts direkt från applikationen.
6.3 Slutord
Rapportförfattarens intryck av projektet är i det stora hela mycket positivt. Projektet har både av projektutvecklarna och utomstående ansetts vara ett bra ingenjörsprojekt, då det innehållit moment och komponenter som har varit nya från vad som tidigare förekommit i utbildningen. Projektutvecklarna har således tagit med sig erfarenhet av utveckling som enligt de intryck från uppdragsgivaren visar kan komma att vara relevanta i arbetslivet. Uppdragsgivaren har för övrigt varit ett stort stöd under projektet, då projektutvecklarna försetts med det material och den expertis som hjälpt till att driva utvecklingen framåt.
Utvecklingen har under projektet skett förhållandevis problemfritt, och har i den mån det varit möjligt varvats med rapportförfattandet. Vissa antaganden behövdes i slutskedet göras utifrån tidsbrist, men i slutändan resulterade projektet i ett delvis sammankopplat, fungerande system. Även om systemet saknar en fysisk träffyta och dess precision dras ned utav dess fysiska komponenter ger det ändå en bild av hur ett optimerat sådant system skulle kunna fungera i framtiden.
Huruvida projektmålen från början varit för ambitiösa för projektets tidsramar, eller om brister hos projektutvecklarna lett till att projektet inte räckte längre vågar inte rapportförfattaren svara på. Även om inte alla frågeställningar kunnat besvaras (se bilaga A.2.3) eller alla optioner hanterats (se bilaga A.2.4) i kravspecifikationen, så kan det i nuläget delvis fungerande prototypsystem som tagits fram visa att ett mindre kostsamt elektroniskt skyttesystem är möjligt, samt att möjlighet till fortsatt utveckling och optimering finns.
Referenser
[1] Ivarsson, N. 2016. Electronic Scoring System: An Electronical & Mathematical
Approach. Unpublished.
[2] Sogeti, “Historia”, [Online]. Tillgänglig: http://www.sogeti.se/om-oss/historia/ [Använd 18 02 2016]
[3] Capgemini, “Company Profile & Key Figures”, [Online]. Tillgänglig:
https://www.capgemini.com/about/group/company-profile-key-figures [Använd 18 02 2016]
[4] Wikipedia, “Electronic scoring system”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Electronic_scoring_system [Använd 08 02 2016] [5] Megalink Electronic Scoring Systems, “10m range - Cheongwon SR”, [Online].
Tillgänglig: http://www.megalink.no/ [Använd 17 02 2016]
[6] Salazar, D., Waterman, M. 2011. Electronic Target. Senior Design II, Northern Illinois University
[7] Wikipedia, “Trilateration”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Trilateration [Använd 11 02 2016]
[8] SparkFun Electronics Inc., “SparkFun Sound Detector”, [Online]. Tillgänglig: https://www.sparkfun.com/products/12642 [Använd 08 02 2016]
[9] Wikipedia, “Trilateration”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Trilateration#See_also [Använd 10 02 2016] [10] Raspberry Pi, “Raspberry Pi 2 Model B”, [Online]. Tillgänglig:
https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ [Använd 10 02 2016] [11] Wikipedia, “Raspberry Pi”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Raspberry_Pi [Använd 10 02 2016] [12] Wikipedia, “Time-to-digital converter”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Time-to-digital_converter [Använd 11 02 2016] [13] Wikipedia, “Windows 10 Editions”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Windows_10_editions [Använd 10 02 2016] [14] Halsey, M. 2015. Windows 10 Primer, New York City, NY: Apress, pp. 33. [15] Wikipedia, “Internet of Things”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Internet_of_Things [Använd 11 02 2016]
[16] Wikipedia, “SQL”, [Online]. Tillgänglig: https://en.wikipedia.org/wiki/SQL [Använd 18 02 2016]
[17] Microsoft, “Entity Framework”, [Online]. Tillgänglig: https://msdn.microsoft.com/en-us/library/gg696172%28v=vs.103%29.aspx [Använd 03 03 2016]
[18] Microsoft Azure, “What is Azure”, [Online]. Tillgänglig:
https://azure.microsoft.com/en-us/overview/what-is-azure/ [Använd 18 02 2016]
[19] Microsoft Azure, “Services”, [Online]. Tillgänglig: https://azure.microsoft.com/en-us/services/ [18 02 2016]
[20] Wikipedia, “Windows Presentation Foundation”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Windows_Presentation_Foundation [Använd 11 02 2016] [21] Wikipedia, “Business Logic”, [Online]. Tillgänglig:
[22] Wikipedia, “Microsoft Visual Studio”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Microsoft_Visual_Studio [Använd 11 02 2016] [23] Wikipedia, “C Sharp (programming language)”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/C_Sharp_%28programming_language%29 [Använd 16 02 2016]
[24] Wikipedia, “Universal Windows Platform”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Universal_Windows_Platform [Använd 19 05 2016] [25] Wikipedia, “Application programming interface”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Application_programming_interface [Använd 19 05 2016] [26] Wikipedia, “Hypertext Transfer Protocol”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol [Använd 19 05 2016] [27] SQLite, “About SQLite”, [Online]. Tillgänglig: http://www.sqlite.org/about.html
[Använd 21 03 2016]
[28] SQLite, “When To Use SQLite”, [Online]. Tillgänglig: http://www.sqlite.org/whentouse.html [Använd 21 03 2016] [29] Entity Framework Tutorial, “DbContext”, [Online]. Tillgänglig:
http://www.entityframeworktutorial.net/EntityFramework4.3/dbcontext-vs-objectcontext.aspx [Använd 19 05 2016]
[30] Microsoft, “LINQ to Entities”, [Online]. Tillgänglig: https://msdn.microsoft.com/en-us/library/bb386964%28v=vs.100%29.aspx [Använd 12 04 16]
[31] Wikipedia, “Extensible Application Markup Language”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/Extensible_Application_Markup_Language [Använd 28 03 2016]
[32] Microsoft, “WPF Designer Overview”, [Online]. Tillgänglig:
https://msdn.microsoft.com/en-us/library/bb514528%28v=vs.90%29.aspx [Använd 28 03 2016]
[33] Fletcher, P., Wasson M. 2014. Introduction to Scaleout in SignalR. [Blog] ASP.NET. Tillgänglig: http://www.asp.net/signalr/overview/performance/scaleout-in-signalr [Använd 19 05 2016]
[34] Wikipedia, “DreamSpark”, [Online]. Tillgänglig:
https://en.wikipedia.org/wiki/DreamSpark [Använd 19 05 2016]
[35] Wikimedia Commons, “File: 10 m Air Rifle target.svg” [Online]. Tillgänglig:
https://commons.wikimedia.org/wiki/File:10_m_Air_Rifle_target.svg [Använd 19 05 2016]
[36] Wikipedia, “Inkscape”, [Online]. Tillgänglig: https://en.wikipedia.org/wiki/Inkscape [Använd 19 05 2016]
A Kravspecifikation av Mats Persson
A.1. Allmän beskrivning av uppdraget
A.1.1 Bakgrund
Sogeti Sverige AB (Sogeti) är ett IT-konsultbolag med bred verksamhet, stort fokus på kompetens och modern teknik.
Inom sportskytte används idag elektroniska markeringssystem för att detektera och avläsa träffar och dess poäng. Det finns flera olika tekniker för detta, men bland de vanligare är att systemen använder akustik, där man med tre eller flera sensorer (mikrofoner/piezosensorer) och med trilateration baserat på ljudhastigheten detekterar var på en yta en kula träffar. De största kommersiella systemen som finns för detta idag är:
• Megalink - http://megalink.no/ • Sius - http://www.sius.com/
Dessa system är förhållandevis dyra, från 30 000 kr och uppåt per enhet, och detta exjobb ämnar att utreda om man med billiga standardkomponenter kan implementera ett liknande system och uppnå den precision som krävs, alternativt utreda hur hög precision som man rimligen kan uppnå. En implementation av ett prototypsystem ingår också.
Olika skyttediscipliner kräver olika upplösning, men till exempel kan nämnas att för att ett system skall fungera bra för 10m luftgevärsskytte så bör en precision på tiondels millimeter uppnås.
Vi tror att man till exempel skulle kunna använda en Raspberry Pi 2 tillsammans med en s.k. ”Time To Digital”-omvandlare för att mäta tidsskillnaderna mellan signalerna från
mikrofonerna
A.2. Markeringssystem
Uppdrag går ut på att utveckla ett markeringssystem för att ta emot träffar på en tavla och presentera träffarna i en klient.
Med hjälp av 4 mikrofoner kopplade till en Raspberry Pi 2 så tar man emot mätvärden och sparar ner det i en databas tillsammans med namnet på enheten. I visningsklienten sen hämtas mätvärden från databasen och den räknar ut var på tavlan man träffat presenterar det.
Som vi ser det så består uppdraget av följande delar:
Koppla ihop allt och få systemet att reagera när mikrofonerna tar emot ljud av en viss ljudnivå (mycket elektronik i detta)
Läsa in mätvärden från mikrofonerna
Ta reda på hur man räknar ut med så hög precision som möjligt var på tavlan man träffat.
Vilken precision kan man uppnå med hårdvaran uppdragstagarna har tillgängligt och jämföra detta med befintliga system.
A.2.1 Raspberry Pi 2
Enheten behöver kunna ta emot mätvärden från alla 4 mikrofonerna, applikationen som hanterar detta ser vi gärna att man utvecklar och kör i Windows 10 på enheten. Enheten behöver kunna trigga händelser i visningsklienten för att den ska uppdatera sig också, om man inte väljer att helt lösa det på visningsklienten så den uppdaterar sig på annat sätt. Det kan vara så att ytterligare hårdvara krävs för tidsregistrering då IOingångarna på t.ex. en Rasberry Pi 2 troligen är för långsamma för att detektera de korta tider det rör sig om.
A.2.2 Visningsklienten
Visningsklienten behöver kunna hämta data från databasen och det här skall beräkningen ligga för att räkna ut var på tavlan man har träffat. Detta inkluderar då att ta fram den
Visningsklienten lämnar vi fritt för uppdragstagarna att själva välja vad de vill utveckla med för teknik, vi vill dock att man håller sig till Microsoft-plattformen. Några av alternativens som finns är:
ASP.NET MVC (webb) WPF (desktop)
UWP (Universal app för Windows 10 desktop, plattor, telefoner m.m.)
A.2.3 Utredning
Det finns några saker att reda ut i detta uppdraget, så en del av uppdraget är att svara på följande frågor:
Hur hög precision kan man komma upp i med den utrustning som finns tillgänglig? (del av mm., mm, cm, dm?)
Vilken typ av hårdvara skulle man behöva för att komma upp i högre precision? Hur mycket skiljer det i precision med den tillgängliga utrustningen jämfört med de
kommersiella systemen som finns?
A.2.4 Optioner
Följande är förslag på vidareutveckling av detta som uppdragstagarna själv får plocka från om tid finns. Innan uppdragstagarna börjar med någon option så måste ett möte till för att
prioritera dessa.
A.2.4.1 Option 1 – Presentera träffarna i en klient
När visningsklienten fått in information om en träff och räknat ut var på tavlan man träffat så ska det även presenteras grafiskt i en tavla så man tydligt ser var man träffat.
A.2.4.2 Option 2 – Presentera hur mycket poäng varje träff är värd
Efter att man tagit reda på var på tavlan man träffat så kan man räkna ut hur mycket poäng träffen är värd och även presentera det för användaren.
A.2.4.3 Option 3 – Hantera flera enheter
Att enbart hantera en enhet är begränsande så finns det tid så se till att visningsklienten har stöd för att visa information från flera tavlor.
A.2.4.4 Option 4 – Administrationsdel
I visningsklienten ska det också finnas en administrationsdel där man kan se vilka ”tavlor” som finns tillgängliga och där man kan sätta upp en tävling med flera deltagare och att
mätresultaten som kommer in kopplas till en specifik person i tävlingen. Programmet ska även då kunna presentera en vinnare efter att alla skjutit ett antal skott som man också kan ställa in.
A.3. Genomförande/arbetssätt
A.3.1 Rutiner
Sogeti tillhandahåller arbetsplatser, datorer, hårdvara samt erforderliga utvecklingsverktyg. Uppdragstagarna kommer att ha access till Sogetis nätverk och förväntas nyttja vår TFS-server för versionshantering.
A.3.2 Hårdvara
Hårdvara för projektet kommer att bestämmas och köpas in innan projektets start men det är inte bestämt än exakt vad för hårdvara det kommer vara.
A.3.3 Genomförande
Uppdragstagarna planerar själv genomförandet och Sogeti tillhandahåller stöttning både projektstyrningsmässigt och rent implementationstekniskt. Sogeti tillhandahåller all programvara och hårdvara som behövs.
Förslagsvis används SCRUM med en sprintlängd på 2-3 veckor som sätts upp där
uppdragstagarna specificerar vad de tror att de hinner med i början av varje sprint och har en demo för en eller flera på Sogeti i slutet på varje sprint.
A.4. Stöd/kvalitetssäkring
A.4.1 Granskningar
Vid behov genomförs granskning som kan initieras av både handledare och uppdragstagare. Lämpligen definieras några granskningspunkter vid planeringen av projektet.
A.4.2 Testarbete
Funktions-, system- och integrationstest görs av uppdragstagarna.
http://hotchk155.blogspot.com/2011/11/lost-in-maths.html
http://hotchk155.blogspot.com/2012/02/midi-table-top-sensingits-working.html
A.5. Leveranser
A.5.1 Dokumentation
Systemdokumentation görs av uppdragstagarna. Dokumenten lagras i projektarkiv hos Sogeti.
A.6. Konfigurationsstyrning
All programkod och tillhörande specifikationer och andra utvecklingsdokument ska versionshanteras med hjälp av Microsoft TFS.
A.7. Miljö
Utvecklingsmiljö för projektet skall om möjligt vara Visual Studio 2015.
A.8. Uppföljning och Rapportering
A.8.1 Rapportering internt/externt A.8.1.1 Statusrapportering
Rapportering av status och framskridande i utvecklingen beslutas i samråd vid projektuppstart.
A.8.1.2 Möten
Möten hålls vid behov. Vid uppstart läggs lämpligt antal avstämningsmöten in i projektplanen.
A.8.1.3 Slutrapportering