När alla delsystem och all funktionalitet är utvecklad sätts de samman till det tänkta systemet. Delsystemen utvecklas vardera för sig men med stor hänsyn till hur de ska fungera ihop. Slutskedet i utvecklingsarbetet när alla delsystem beter sig som förväntat är att kontrollera så de fortfarande kan utföra sina uppgifter enligt önskan även med
beroenden från andra delar. Detta gör att testning med olika testscenarion måste utföras för det sammansatta systemet.
4.2 Testning
En viktig del både under utvecklingsarbetet och i slutskedet är testning av systemet. Ett tänkvärt uttryck när det gäller teknisk utveckling är ”Det man inte har testat fungerar inte” sagt av Gunnar Asplund, ABB [24]. Detta uttryck är mycket värt att ta i beaktning ju mer komplext system det gäller. Det är inte alltid lätt att förutse alla funktioners utfall med olika beroenden, framförallt inte ju större system blir. För att komma till bukt med eventuella problem som kan uppstå så bör testning av alla funktioner och delsystem ske under arbetets gång och slutligen måste delsystemet testas med alla tänkbara fall som är relevanta för systemets funktionalitet. Detta avsnitt behandlar olika testfall som används under utvecklingens gång, och vid sammansättning för verifiering om systemet slutligen fungerar som tänkt.
Eftersom mer eller mindre all kod i någon utsträckning drabbas av buggar är testning viktigt genom hela flödet av utveckling. Men hur noggrann testning som skall ske är en avvägning som måste göras. Allt måste ju testas för att veta om det fungerar som citatet ovan säger, men går det att testa med alla tänkbara villkor och går det att lösa alla buggar som återfinns? Någon stans måste man dra en gräns, eftersom testning annars blir en allt för resurskrävande process. När testning kan anses slutfört beror även på applikationen tillämpning, i vissa fal är det viktigare än andra att inga fel kan ställa till problem längre fram. Framförallt maskiner som ska användas inom sjukvård och kan riskera människors liv, eller maskiner som ska ut i rymden och där ett fel kan få miljonsatsningar att gå
förlorade. Exempelvis så jobbar Google och Microsoft med testning för att komma ner till en gräns där de hittar mindre än 40 buggar och fel per 1 000 rader kod, medan NASA som har mer kritiska tillämpningar har sin nivå på 4 buggar och fel per 1 000 rader kod [25]. Men bara för att man hittar färre fel vid testning betyder det inte per automatik att den utvecklade koden är bra, det handlar mycket om hur man testar. Det gäller alltså att hitta relevanta scenarion som kan tänkas uppstå och testa hur det fungerar i dessa fall.
4.2.1 Testscenarion
För att testningen av olika delfunktioner och av det sammansatta systemet ska kunna genomföras behöver olika testfall sättas upp. Varje delfunktion måste testas med all relevant indata för att kontrollera så att efterfrågat resultat uppnås. Eftersom projektets system i detta fall är enkelt och inte utgör några risker så som styrsystemet i verkliga automatiserade industrier med risk för personskador, så kan testfallen förenklas. Men för att uppnå en god realism används även testfall där systemets funktionalitet ska förväntas att fallera. Detta för att se hur stödfunktioner beter sig som ska förhindra större problem.
Testfall för delsystem
Under utvecklingens gång görs ständigt test för nya delsystem allt eftersom de skapas. Det första testet som gjorts för robotarna är att köra alla motorer och samtidigt läsa av ändlägen för dessa för att få en uppfattning om antalet steg i stegräknarna från ena änden till den andra. Dessa värden har sedan använts i beräkningar för rörelser längre fram i utvecklingen. Sedan har det lagts till fler funktioner i robotarna som efter hand har testats. Till exempel har enklare program skrivits där roboten testar att läsa och skriva till databas, eller köra en testslinga med att hämta box på ett ställe och lämna på ett annat. För GUI har det snabbt synts resultat om koden fungerar eller ej då det gör att köra koden direkt utan kompilering så fort koden lagras på webbservern. Utan att ansluta robotarna kan knappar testas så de genererar önskat utfall i databasen samtidigt som databasen kan uppdateras med ny information som motsvarar den som robotar senare ska skicka för att se att detta mottages korrekt i GUI. Lite svårare blir det att testa när den mer
avancerade funktionaliteten i GUI implementeras i form av automatiska anrop med jQuery och Ajax. Med timers som triggar funktioner blir testerna mer komplexa, men principen är densamma som innan; ändring av värden i databas används som test.
Testfall för sammansatt system
Allt eftersom delfunktionalitet fungerar som förväntat var för sig sätts de samman mer och mer till större delar för att testning av det slutgiltiga systemet. I detta skede skapas ordrar i systemet som sedan robotarna får paketera som de ska. Sedan observeras hur de
arbetar för att lösa uppgiften för att se om det uppstår några problem. När de beter sig som förväntat läggs hinder in för att testa hur de reagerar när problem uppstår. Till
exempel töms lagret på materiell för att se att robotarmen detekterar detta och skickar en varning. Alla tänkbara problem som kan uppstå testas för att studera utfallet. Några fall som används i test är följande:
- Saknade bitar i lager
- Order lagd utan att ange leveransutgång - Drift med svag batterinivå
- Slut på paketeringsboxar
- Koppla ifrån internetanslutning på robot
Varje testfall är av olika vikt beroende på funktion som testas. I vissa fall görs nogra
datainsamling, medan i andra fall är det visuell observation som avgör om testet passerad med godkänt resultat eller ej. Ett exempel på ett testfall är en mätning av
positionsmarkeringar för roboten RoboTransport. För att slippa utgå ifrån en känd
position vid varje rörelse längs rälsen så skapas några angivna platser med deras position på stegräknaren. Eftersom noggrannheten i motorerna inte är så väldigt exakt så körs roboten längs rälsen flera gånger och räknarens värden när olika positioner passeras sparas. Sedan räknas ett medelvärde ut och en toleransnivå på medelvärdet jämfört mot uppmätta värden. Se tabell 2. Dessa värden läggs sedan in som konstanter som används när roboten förflyttas sig mellan de olika positionerna och jämför dessa mot aktuellt värde i stegräknaren. Ett värde för vad som är okej differens anges även det baserat på
Tabell 2. Insamlade värden i testfall för positionsberäkning.
Position Värde 1 Värde 2 Värde 3 Medelvärde Tolerans Lastplats 1 496 522 521 513 17 Utgång 1 1220 1248 1238 1238 18 Lastplats 2 1532 1560 1503 1532 29 Boxlager 1 2284 2284 2277 2282 5 Utgång 2 2440 2441 2434 2438 4 Boxlager 2 2885 2884 2848 2872 24 Boxlager 3 3423 3425 3425 3421 6 Total längd räls 3743 3753 3725 3740 15 4.2.2 Datainsamling
I flera av testscenariorna sker datainsamling för att kontrollera testernas utfall och
resultat. Datainsamlingen varierar på olika vis och består av värden så som mätningar från stegräknare eller avläsningen från sensorer. Just avläsningen från sensorer är en del i ett tidigt skede i utvecklingen för att kontrollera hur dess värden skall behandlas när olika funktioner blir beroende av dess utläsningar.
Datainsamling sker även ständigt under drift för att uppdatera status för robotar och system. Lagringen sker främst i databasen, men lokala filer på robotarna används även då inte anslutning till databas är tillgänglig eller som extra backup. Information som lagras är viktiga systemmeddelanden om utförda aktiviteter utöver det normala, som åtgärder vid problem, eller inrapporterade fel. Den ständiga övervakningen av robotarnas status samlas bara in till databasen med ett aktuellt senaste värde.
4.3 Granskning av expansionsmöjligheter
När det gäller expansionsmöjligheter så finns det flera avgörande punkter för huruvida systemet kan expanderas eller inte. De avgörande punkterna i detta fall är
arbetsuppgiften som systemet ska lösa och systemets konstruktion. Även om
systemdesign alltid kan göras om så betyder det inte att ett ombyggt större system är en expansion på det ursprungliga, det kan även vara ett nytt system om olikheterna är för stora.
Detta system är som nämnt inledningsvis byggt som en modell av ett större system som både kan agera som det är, eller som en del i ett stort system. Det medför då att systemet blir utbyggbart precis som det automatiserade systemet som modellerats. Dels kan enkelt fler produkter läggas till och fler robotar jobba parallellt med paketering, men arbetsflödet kan även förlängas. Ett nästa steg kan läggas till där en ny robot packar upp delarna i orden och skickar till en annan robot som sen monterar ihop dessa. Så möjligheterna är stora för systemets expansion.
När det sedan gäller styrsystem och konstruktionsdesign för mjukvara så byggs mjukvaran på sådant vis att fler robotar ska kunna ansluta till systemet utan större förändringar i uppbyggnaden. Viktiga funktioner och metoder är byggda för att kunna tillämpas på olika vis beroende på antalet enheter i systemet. Produktutbudet kan enkelt justeras genom att fler produkter läggs till i databasen. Det går även att lägga in fler användare i systemet så administration av systemet kan göras i olika steg av olika personer med olika behörighet.