Design och implementation

För att producera en automatiserad testmiljö för DC-scenariot så designas ett program som härmar det manuella utförandet av testet i verkligheten.

Figur 18 visar mekanismen för en DC-test som är uppdelat till tre viktiga huvudobjekt (Main, DC-Test och IRIS). Dessa objekt kommunicerar med varandra för att stegvist flytta testet från startpunkten där DC-testet skapas ända fram till slutpunkten där resultat om testet presenteras.

Figur 17Visar hur Iris program ser ut vid en manuell DC-testning. Programmet har olika alternativ att välja mellan, som berör olika funktionaliteter där Data Collection gäller för DC-test.

programmet exekverar enligt följande order som visas i Figur 18.

• Main skapar DC-Test genom att anropa funktioner i DC-test som i sin tur anropar nödvändiga konfigurationer i IRIS

• Main kör testet med lämpliga DC-test funktioner och IRIS konfigurationer

• Testet avslutar med ett kontrollmoment som utförs av DC-test och kontrollerar testets tillstånd All detta arkiveras i en databas med hjälp av en underdel som kallas för Log som sparar information om testets körning i en fil.

Utifrån designen som bestäms för programmet uppdelas implementationen till olika klasser där varje klass är ansvarig för en uppgift. Denna uppdelning av arbetet vid implementationen hjälper till med att jobba parallellt för att öka effektiviteten av arbetet och minska implementationstiden vilket i sin tur ger möjligheten att testa beteendet av varje klass för sig och säkerställa funktionaliteten innan sammanslagningen av kod sker (Figur 19 visar ett flödesdiagram på implementationsprocessen).

Implementation och testning av klasser

Sammanslagning och testning av program Datainsamling Justering och förbättring Justering och förbättring

Figur 19Visar implementationsprocessen för DC- och HIL-testscenario där utvecklingen sker stegvist genom att först implementera programmets olika klasser separata. Därefter samlas programmets olika delar ihop och testas. Nästa steg består av datainsamling av testsystemets exekveringstid för utvärderingen senare i arbetet. Förstås stegen repeteras vid behov av förbättring eller justering av programmets funktionalitet.

DC-Skapare

Skapa

Kör

skapa DC test _{IRIS-Konfiguration}

köra test

Kontrollera status

IRIS-

kommandokonfiguration

Main DC-Test IRIS

Log

Figur 18 Visar mekanismen för en DC-test. Mekanismen uppdelas till tre huvuddelar (Main, DC-test och IRIS)

som flyttar mellan olika test moment från en testskapning till en körning fram till en kontroll momentet. All detta kommunicerar med en underdel (Log) för att arkivera information om testets tillstånd.

Första steg av Implementation och testning av programmet sker teoretisk utan direkt kontakt med systemet i verkligheten. Det vill säga att alla tester för respektive funktion i en klass sker genom att skicka bestämda värden och kontrollera resultaten som jämförs med det förväntade beteende av funktionen.

Nästa steg utförs genom att samla programmet ihop i en helhet som uppladdas lokalt i systemets dator. Detta steg syftar på att testa programmet lokalt i verkligheten utan att behöva använda Jenkins-server (se kapitel 2.5.1 för mer information om Jenkins-server) under denna nivå av utvecklingsprocessen. Testningen sker genom att först köra programmet i det fungerande systemet och kontrollera resultatet. Därefter ändras systemet genom att avbryta olika kopplingar och kontrollera de förväntade resultaten vid körning av programmet och justera programmet vid behov.

I mån av tid så implementeras en konfiguration för att använda testprogrammet i Jenkins-server och flytta det globalt till servern. Detta sker med hjälp av Jenkins-guiden (2018) och Wolf Ulmanen som är en medlem i gruppen som arbetar med automatiseringsprojektet i Autoliv.

Sista steg handlar om att samla data om programmets exekveringstid för att förbereda en databas som senare kan användas under utvärderingsmomentet.

HIL-scenario

Metoden att implementera HIL-testscenariot liknar i stort del metoden som används för DC-testscenario där arbetet också börjar med en kopplingsfas sedan en design- och implementeringsfas.

3.2.1 Koppling

På samma sätt som DC-scenario så sker kopplingen för HIL-scenariot enligt instruktioner och dokumentation som Autoliv förberedde för examensarbetet.

Komponenterna som ett HIL-test behöver vid en manuell testning är en ECU tillsammans med en BOB3 och en dator som innehåller

Shell-programmet HIL-Player nedladdat i (se

kapitel 2.1, 2.2.1 och 2.2.3 för mer information om systemets komponenter). Utifrån en överenskommelse med Autoliv (se kapitel 1.5) väljs specifika typer av BOB3 mjukvara (4.0.0) och ECU (kamera1 version R4R2) för att kunna utföra testerna.

Genom att köra en manuell HIL-testning bekräftas att systemet fungerar som förväntat och även bekräftas att alla komponenter kan kommunicera med varandra med rätt konfigurationer.

HIL-Player är ett Shell-program som används vid HIL-testning och har inget vänligt användargränssnitt (Figur 20 visar exemplar på kommandon som styr HIL-Player via terminal). HIL-Players uppgift är att ta emot en ADTF-fil från en databas och skicka datatrafiken vidare till en BOB3. Den har

även förmågan att ta emot data som kommer från en BOB3 och spara dem i en databas som en ADTF-fil.

Figur 20 Beskrivningar till några kommandon som

3.2.2 Design och implementation

Att imitera stegen som utförs i ett manuellt HIL-test är den bästa metoden som kan passa Autoliv för att på ett enkelt sätt och tydlig bild flytta till. Dessutom så underlättar detta förbättringsarbete som kan senare ske på programmet då Autoliv har redan erfarenheter om den manuella versionen av HIL- testning och dess genomförande.

Imiteringen (Figur 21) sker genom att uppdela arbetet under ett HIL-test till olika nivåer där varje nivå ansvarar för kompletteringen av en specifik aspekt av testet och förbereder miljön till utförandet av nästa nivå. Dessa nivåer är också uppdelade till olika utvecklingssteg som utförs i order för att organisera flödet av varje nivå i programmet genom de olika moment och hjälpverktyg som används under testet vilket strukturerar arbetet under testsgenomförandet på ett sätt som underlättar förståelsen av processen och felsökningen när ett fel uppstår vid testning av ett system.

Figur 21 Visar mekanismen för imitering av ett HIL-test där mekanismen uppdelas till tre huvudnivåer

organiserade vertikalt där de flyttar programmet stegvist från skapning av ett test till körning ända fram till kontroll steget. Varje nivå har ett antal delar organiserade horisontellt där delarna kommunicerar med varandra för att förberedda programmet till nästa nivå ända fram till kontrollen som bestämmer ifall det testade systemet ger rätt beteende under testet eller ej.

HIL-Skapare Skapa Kör HIL-Körning Kontroll Set konfiguratione r HIL-Kontroll Skapa HIL-test köra test Kontrollera status

Main HIL-Test HILPlayer

Log HIL-Player- konfigurationer Set konfiguratione r ADTF- hjälpverktyg Klipp- jämförelse Verktygs- konfigurationer

sFigur 21 visar att programmet för ett HIL-test börjar med att först skapa testet genom att förbereda konfigurationerna och det lämpliga klippet för uppspelningen som HIL-Player-programmet kräver för att starta på ett rätt sätt för en specifik version av ECU.

Därefter så utförs testet genom att starta HIL-Player-programmet för uppspelningen och vänta på det returnerande klippet som spelas in också via HIL-Player och sparas i databasen som en ADTF-fil.

Sista nivån utför en jämförelse mellan den ut- och inspelade klippen genom att använda ett verktyg (FD- ADTFTool eller FdAdtfIo) som sönderfaller innehållet av en ADTF-fil till olika typer av information vilket ger möjligheten att analysera olika parametrar i klippen för att bestämma beteendet av det testade systemet ifall en avvikelse i funktionaliteten har inträffat.

DC+HIL-test

Metoden börjar med att analysera möjligheten att koppla systemet i verkligheten och dokumentera beteendet av systemet vid utförandet av DC- och HIL-test parallellt.

Implementationen liknar i stort del metoden som används för DC- respektive HIL-testscenario där arbetet är en kombination av de tidigare arbetena.

3.3.1 Koppling

Kopplingen sker med hjälp av instruktionerna som Autoliv har idag. Syftet med det är att kunna utföra DC- och HIL-test samtidigt i samma scenario. Komponenterna som DC+HIL-testscenario är en kombination mellan komponenterna som används för DC- och HIL-testscenario. Förstås, valet av dessa komponenter är avgränsade enligt en överenskommelse med Autoliv (se kapitel 1.5). komponenterna är uppdelade mellan två delar.

Den ena delen av kopplingen är HIL-delen som behöver en dator, en BOB3 mjukvara (4.0.0) och en gemensamt ECU (version R4R2) for båda HIL och DC (se kapitel 2.1 och 2.2 för mer information om systemets komponenter). Datorn som innehåller Shell-programmet HIL-Player nedladdat i är kopplad till BOB3 via USB3 för att kunna snabbt skicka en stor ADTF-fil. BOB3 i sin tur är kopplad till ECU via en FR-port och en MIPI-port.

Den andra delen av kopplingen är DC som behöver en dator, en BOB3 mjukvara (4.0.0) och även den gemensamma ECU. ECU är kopplad till BOB3 via bildkabel och en FR-port som skickar dataflödet från och till BOB3. Datorn också är ihop kopplad till en BOB3 via USB3 för att ta emot stora mängder av data. Dessutom så innehåller datorn IRIS-programmet nedladdad.

De två datorerna som används i DC+HIL-test är ihopkopplade med varandra via Ethernet IPv4. Syftet med denna koppling mellan datorerna är att skapa en gemensam miljö för kommunikation mellan scenariots olika delar. Detta kan ses i Figur 22 där kommunikationen visas mellan DC- och HIL-del för att utföra testen.

3.3.2 Design och implementation

Efter analysen om möjligheten att genomföra en DC+HIL-scenario (se Scenario 3 i kapitel 1.3) och utförandet av design och implementationsfaserna för DC-testscenario respektive HIL-testscenario, används resultaten för att producera ett kombinationsprogram som har i sin konstruktion ett slags samarbete mellan de redan implementerade programmen för DC- och HIL-test.

Genom att studera DC+HIL-scenariot så märks att DC-testdelen behandlar datatrafiken som kommer från HIL-testdelen på samma sätt som om systemet är kopplad separat, och datatrafiken kommer direkt från en kamera. Problemet med denna kopplingsmetod är behovet att först säkerställa flödet av datatrafiken från HIL-testdelen innan utförandet av DC-testet sker. Därför måste utförandet av DC-testet fördröjas tills

datatrafiken från HIL-delen börjar spelas upp till systemet. Utifrån detta krav så designas programmet på samma sätt som tidigare där de manuella testmetoderna imiteras med en extra funktionalitet som synkroniserar körandet av programmets olika delar vilket är viktigt för att få rätt beteende från de kombinerade scenariona. Denna synkronisering kan ske genom att ha ett delat minne mellan båda delarna av scenariot (DC och HIL). Där erhålls en kommunikation mellan dem olika delarna i det nya programmet. Genom att använda det ovan nämnda delade minnet kan DC-delen av scenariot vänta på besked om tillståndet av HIL-testet innan delen börjar utföra DC-testet (eller i vissa fall avbryta testet när ett fel inträffar i HIL-sidan). Detta kan ses i Figur 22 som visar mekanismen av kombinationssystemet och momentet där en kommunikation sker mellan systemets DC- och HIL-delar för att utföra testen på ett effektivt sätt.

Figur 22 uppdelar kombinationssystemet till två huvuddelar som presenterar DC- respektive HIL-testen där varje del flyttar sin typ av test genom olika nivåer från skapningen av testet fram till kontrollnivån. Flyttningen i programmet sker parallellt i början då båda DC- och HIL-testen skapas och konfigureras samtidigt. Därefter stannar DC-testdelen och väntar på ett besked om dataströmmen som ska fås av HIL- testdelen. Så fort dataöverföringen i HIL-testdelen börjar flöda genom systemet så larmas DC-test som i sin tur fortsätter köra (eller avbryter i fall ett fel inträffar) testet och kontrollerar resultatet på samma sätt

Skapning Konroll Konfiguration Dataöverföring Skapning Konfiguration Väntan på dataström Konroll Kör HIL-test DC-test DC+HIL-Test

Figur 22 Imitering av DC- och HIL-test i ett kombinerat system där

kombinationssystemet uppdelas till två delar, HIL-test och DC-test. Testen utförs separerade men, med en skillnad som bestämmer genomförandet av DC-test utifrån en återkoppling från HIL-test. Det vill säga att DC- och HIL-test skapas och konfigureras samtidigt först, och sedan stannar DC-testdelen och väntar på ett dataflöde från HIL-Player i HIL-Testdelen och fortsätter bara efter att data börjar flöda i systemet. I fall ett fel inträffar i HIL-Testdata då inget data överförs så avbryts DC- testet med ett felmeddelande.

Information om HIL-tillstånd

som utfördes tidigare i DC-testscenario. På detta sätt säkerställs att utförandet av DC-testmoment som kräver dataström inte sker utan datatrafik som flödar genom systemet.

Förstås, implementationen av kombinationssystemet sker genom att dels använda olika implementationsdelar som de tidigare testscenariona har (kapitel 3.1.2 och 3.2.2) , och dels genom att skapa nya funktioner för att etablera en kommunikationskanal mellan testdelarna. Allt detta i syftet med att verkställa designen av Figur 22 i verkligheten.

Insamling av data

För att kunna analysera prestandan av de testscenariona som utvecklas så ägnas en tid för att samla in data om hur bra de olika implementationerna utför arbetet. Detta data består av tidsvärden av olika typ av testningar. Det vill säga, för varje utvecklat testscenario (DC-, HIL- och DC+HIL-testscenario) så utförs ett experiment där exekveringstider vid utförandet av testet antecknas. Detta experiment repeteras ett antal gånger med olika fall såsom fallen där inga fel inträffar i systemet eller fallen där ett fel uppstår i systemets koppling. Dessutom så utförs detta experiment på utförandet av det manuella testet för respektive scenario, då en person utför ett test manuellt medan en annan person räknar och antecknar exekveringstiden. Syftet med det insamlade data är att skapa en empirisk databas ett senare moment i arbetet vilket består av utvärdering av systemet.

Utvärdering och analys av resultat

Efter det föregående momentet som bestod av implementation av testscenarion och tidsdatainsamling lägger arbetet fokus på att utvärdera och analysera de nya testsystemen. Detta sker genom att dels utvärdera det insamlade data för varje testscenario (DC- och HIL-testscenariot) via en jämförelse mellan exekveringstiderna för det utvecklade programmet och exekveringstiderna för det manuella testet för respektive testscenario. Och dels genom att utvärdera tiderna för DC-, HIL- och DC+HIL-testscenario i jämförelsen med varandra.

Sista delen av utvärderingen presenterar också en lista av nackdelarna och fördelarna med att använda de olika testscenarion i jämförelse med de manuella metoderna. Denna lista utgår från exekveringstiderna av varje testscenario, och hur varje scenario upplevs under examensarbetet i jämförelse med de andra. Denna del syftar på ger en personlig åsikt om de utvecklade testsystemen ilket kan hjälpa Autoliv att bestämma effektiveten av de nya systemen i deras verksamhet.