Linköpings universitet | Institutionen för datavetenskap Examensarbete, 16 hp/ Högskoleingenjör i datateknik Vårterminen 2018| ISRN: LIU-IDA/LITH-EX-G--18/063--SE
Utvärdering av testsystem
och implementering av
automatiserade testmiljöer
Evaluation of test systems and implementation of
automated test environments
Samer Zitoun
Ahmed Dia Jeber
Handledare: Fredrik Jenneus Examinator: Petru Eles
Linköpings universitet SE-581 83 Linköping
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.
Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.
Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.
För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.
Sammanfattning
Under examensarbetet designas och implementeras ett antal testprogram med Python-programmeringsspråk som ersätter de manuella testmetoderna som används i Autoliv i syfte med att automatisera testningsprocessen för Autolivs produkt BOB3 vilket bidrar till en besparing av tid och arbetsresurser. Två av dessa Program presenterar utförandet av HIL-test (Hardware in the loop) och DC-test (Data Collection DC-test). Dessutom så analyseras möjligheten att kunna skapa ett DC-testsystem som kombinerar utförandet av testen i en och samma koppling vilket senare leder till en implementering av ett kombinerat program som utför ett HIL-test på en BOB3-box och ett DC-test på en annan BOB3-box. De producerade programmen för HIL-test, DC-test och kombinationen av DC- och HIL-test analyseras utifrån deras exekveringstider under olika fall (ett fungerande testsystem eller ett system där ett kopplingsfel inträffar) för att bestämma vilket/vilka program som visar bättre prestanda dels i jämförelse med de konventionella manuella testmetoderna som används i Autoliv och dels i jämförelse med varandra. Studien resulterar först in två program som imiterar de manuella testmetoderna för HIL- och DC-testning och öppnar möjligheten att automatisera testningsmetoderna. Senare så lyckas analysen att visa möjligheten att koppla testsystemen för HIL och DC ihop i ett kombinerat testsystem vilket i sin tur leder till ett kombinerat program som relaterar HIL- och DC-testet till varandra i ett och samma testningsmoment. Analysen av exekveringstiderna visar att användningen av testprogram minskar nödvändiga tids- och arbetsresurserna i jämförelse med de manuella testningsmetoderna. Dessutom så visar exekveringstiderna en fördel med att använda programmen som utför HIL- och DC-testet separata i istället för kombinationsprogramment som har andra fördelar som introduceras med en förminskning vids användning av hårdvara resurser och möjligheten att styra datatrafiken som flödar genom ett DC-test.
Förord
Denna rapport är ett examensarbete för Högskoleingenjör i Datateknik vid Linköpings Universitet. Studien utfördes hos Autoliv i Linköping.
Vi vill tacka vår handledare på Autoliv, Fredrik Jenneus, som bidrog till en bra arbetsmiljö. Dessutom så tackar vi Malcolm Sundberg, Wolf Ulmanen och samtliga ingenjörer och anställda i Autoliv för deras positiva attityd och stöd.
Vi vill tacka vår handledare och examinator Petru Eles på Institutionen för datavetenskap och informationsvetenskap Linköpings universitet för hans konstruktiva kritik och tid.
Linköping, juni 2018
Innehållsförteckning
1 Inledning ... 13 Introduktion ... 13 Bakgrund ... 13 1.2.1 Visionssystemet ... 13 1.2.2 Mätsystemet ... 14 1.2.3 Motivering ... 14 Syfte ... 15 1.3.1 Projektarbetet ... 15 Frågeställningar ... 17 Avgränsningar ... 17 Källkritik ... 18 2 Teori ... 19 Visionssystem ... 19 Mätsystem ... 20 2.2.1 BOB3 ... 20 2.2.2 IRIS ... 21 2.2.3 HIL-Player ... 21 FlexRay ... 21 Testtekniker ... 23 2.4.1 Hardware-in-the-loop (HIL) ... 23 2.4.2 Data-Collection (DC) ... 24 Övriga verktyg ... 25 2.5.1 Jenkins ... 252.5.2 UML (Unified Modeling Language) ... 26
2.5.3 ADTF avsökningsverktyg ... 27
2.5.4 DAT_Sanity_Test ... 28
Internt relaterat arbete ... 29
3 Metoden ... 31
DC-testscenario ... 33
3.1.1 Koppling ... 33
3.1.2 Design och implementation ... 33
HIL-scenario ... 35
3.2.1 Koppling ... 35
DC+HIL-test ... 37
3.3.1 Koppling ... 37
3.3.2 Design och implementation ... 37
Insamling av data ... 39
Utvärdering och analys av resultat ... 39
4 Resultat ... 41
DC-scenario ... 41
4.1.1 Design och implementation ... 41
HIL-scenario ... 44
4.2.1 Design och implementation ... 44
DC+HIL-scenario ... 47
4.3.1 Koppling ... 47
4.3.2 Design och implementation ... 50
Datainsamling ... 51 4.4.1 DC-testscenario ... 51 4.4.2 HIL-testscenario ... 52 4.4.3 DC+HIL-testscenario ... 54 5 Diskussion ... 55 DC-testscenario ... 55 HIL-testscenario ... 56 DC+HIL-testscenario ... 57 Analys av datainsamling ... 58 5.4.1 DC-testscenario ... 59 5.4.2 HIL-testscenario ... 61
5.4.3 DC- och HIL-testscenario vs DC+HIL-testscenario ... 62
6 Slutsats ... 65
Förkortning
HIL Hardware in the loop
DC Data Collection
MS Mätsystem
IRIS Autolivs data in/utspelningsverktyg
HIL-Player Autolivs data in/utspelningsverktyg för HIL-test
BOB3 Break-out-box. Autolivs egen box för tidstämpling och organisering av datatrafik
ECU Electronic Control Unit för visionssystem (kamerasystem)
MIPI En port för att sicka bilder till visionssystem
Bilbuss (FlexRay) En port för att överföra data om bilens tillstånd
FR FlexRay
BRR Broad Reach
GW Getway
Debug Ethernet port för koppling mellan ECU och BOB3 och ansvarar för överföring av resulterade data
ADTF Automative Data and Time-triggered frame work för användning vid utveckling av fordon
1 Inledning
Introduktion
Det är alltid nya teknik och utvecklingar som stormar in i fordonsindustrin och hjälper förare att känna sig trygga och säkra på vägarna. En del teknik har varningsförmåga i form av sensorer och backkameror som varnar föraren vid behov.
Å andra sidan har en del teknik en beslutsförmåga där systemet fattar beslut och ingriper när systemet anser att föraren inte kommer hinna reagera vilket förebygger tillkommande olyckor. Syftet med denna teknik är att utnyttja den ökande bearbetnings hastighet i den nya teknologin för att underlätta körningsupplevelsen och rädda fler liv i trafiken.
Autoliv är ett ledande företag inom fordonssäkerhet. Företaget utvecklar och producerar visuella säkerhetssystem som monteras i fordon för att förebygga inträffande av olyckor. Dessutom, arbetar företaget med att skapa en grund för objektsigenkänningssystem för självkörande bilar i framtiden. En av de mest kända produkter i företaget är ett visionssystem som läser och upptäcker objekt på vägen framför bilen via en kamera och arkiverar de på en databas för att sedan använda dessa data för att fatta beslut under nödsituationer. Detta ska ske felfritt för att undvika funktionalitetsstörningar som kan leda till svåra olyckor i trafiken. Detta kräver en hög grad testprocesser på systemet för att upptäcka fel och utveckla systemet vid behov för att nå den bästa möjliga kvalitetsnivån innan det levereras till slutkunden.
För att kunna analysera data under utvecklingen av ett visionssystems tillverkar Autoliv ett till system som kallas för ett mätsystem som har uppgiften att organisera datatrafiken som kommer från ett visionssystem och tidsstämpla dem innan data sparas i en databas redo för analys. Förstås, ett sådant hjälpsystem för utvecklingen behöver noggranna tester som utförs för att säkerställa rätt funktionalitet i hög grad vid koppling med ett visionssystem.
Utifrån högfunktionalitetskravet utför företaget tester på mätsystemets hårdvaror såsom kontrollboxen BOB3 som är en ny generation av den gamla kontrollboxen BOB2, vilket finns i mätsystemet och används för att organisera datatrafiken innan den skickas till databasen. Detta sker genom att använda två olika testtekniker för att utvärdera beteendet av BOB3. Testen kallas för Hardware-in-the-loopsimulation (HIL) och Data-Collection (DC).
I dagsläget utförs testen i företaget manuellt vilket leder till en försämring i produktionens effektivitet. Därför handlar detta arbete om att gå genom de två testtekniker (HIL och DC), utvärdera Autolivs olika förslag för testsscenarion (kopplingsdesigner) och implementera automatiserade testmiljöer för att höja effektiviteten av testmomenten i produktionsprocessen.
Mer detaljer om de olika förslagen för testscenarion och arbetets motivation beskrivs i bakgrundskapitlet.
Bakgrund
I detta kapitel presenteras en kortfattad beskrivning om de olika komponenter i visions- och mätsystemet som innehåller kontrollboxen BOB3. Dessutom, presenteras en motivering till detta examensarbete vilket manifesteras i ett projekt hos beställaren för att implementera testmiljöer för systemet.
1.2.1 Visionssystemet
Ett system som består av en kamera av olika typer (mono, stereo, mörkerseende mm) som är kopplade till en ECU (Electronic Control Unit) som läser information och upptäcka objekt från kamerabilderna. En översiktlig bild på visionssystemet visas i Figur 1 tillsammans med mätsystemet som beskrivs nedan.
1.2.2 Mätsystemet
Mätsystemet som Autoliv producerar (visas översiktlig i Figur 1) är ett nätverk av kopplade hårdvaror (BOB3 och Dator).
• BOB3 en kontrollbox som styr funktionaliteten av mätsystemet genom att organisera datatrafiken innan den skickas vidare till databasen i en dator.
• Dator innehåller databasen och ett par in/utspelningsprogram som en komplettering till mätsystemet
o HIL-Player o IRIS-Program
Mer beskrivning om komponenterna av visionssystemet och mätsystemet hittas senare i rapporten (se kapitel 2.1 och 2.2)
1.2.3 Motivering
En del av det aktuella testprojektet för den nya hårdvaran BOB3 hos beställaren lägger fokus på att automatisera funktionalitetstesterna för HIL och Data Collection för BOB3.
Eftersom beställaren utför begränsade tester på systemet manuellt i nuläget vilket kräver stora tids-, arbets- och personalresurser så har ett arbete startats för att flytta testmetoderna från manuella metoder till automatiserade metoder.
En del av det aktuella arbetet för den nya hårdvaran BOB3 hos beställaren lägger fokus på att automatisera funktionalitetstesterna för HIL- och DC-sekvens i BOB3. Dessa tester förklaras mer detaljerat senare i rapporten (se kapitel 2.4)
Figur 1 En översiktlig design på de olika komponenterna i ett
visionssystem och ett mätsystem kopplade på samma sätt som en test i verkligheten. ECU BOB3 HIL-Player Databas IRIS Kamera
Visionssytem (Monteras i slutkundens fordon )
Mät syst em (an v ä n d s fö r test v id u tv e k li n g av E C U) Dator
Syfte
Syftet med arbetet är att utreda om det går att skapa testmiljöer för integrationstest för BOB3 (en kontrollbox för timstämpling och organisering av datatrafik som kommer från en kamera på vägen till en databas i en dator). Detta sker genom att utvärdera resultaten av scenario 1 och scenario 2 med resultaten från scenario 3 (se kapitel 1.3.1 för mer information om de olika scenariona) för att bestämma om scenario 3 kan ersätta scenario 1 och scenario 2.
En automatiserad testmiljö erhålls genom att producera ett program som senare har möjligheten att kommunicera med en Jenkins-server (se kapitel 2.5.1 för mer information om Jenkins) då när en ny BOB3-mjukvara finns tillgänglig, triggas en nedladdning av BOB3-mjukvaran i BOB3 och därefter startas test scripten. Vid ett godkänt testresultat skall BOB3-mjukvaran släppas annars spärras. Denna testmiljö ger möjligheten att automatiskt testa hårdvaran BOB3 på bänk i laborationen hos beställaren. Detta görs genom att aktivera testen när en ny mjukvara laddas ner i systemet utan att behöva montera hårdvaran i ett fordon och testköra den i verkligheten.
1.3.1 Projektarbetet
Detta arbete utgår från två olika testsscenarion som används vid implementering av den automatiserade testmiljön för HIL- respektive test och förslår en tredje scenario som kombinerar både HIL- och DC-test i samma design.
• Scenario 1 (HIL-testscenario) ett HIL-testscenario med kamera (Figur 2) som redan används hos beställaren där ett klipp och data spelas upp från databasen till HIL-Player, BOB-boxen fram till kamerasystemet via två portar som kallas för MIPI för att överföra bilder och Bilbuss (FlexRay) för att överföra information om bilens tillstånd. Efter det kommer kamerasystemet att behandla datatrafiken och returnera den via porten Bilbuss till BOB tillbaka till HIL-Player och sedan tillbaka till databasen. Detta ger möjligheten att jämföra data och säkerställa att funktionaliteten av systemet inte ändrar sig vid nedladdning av ny mjukvara i BOB3.
ECU BOB3 HIL-Player Databas Bilbuss (FlexRay) MIPI USB3 Kamera
Figur 2 En design som presenterar testscenario 1 (HIL) där datatrafiken loopar
genom systemet (Databas -> HIL-Player -> BOB3 -> ECU -> BOB3 -> HIL-Player -> Databas) vilket ger möjligheten att testa beteendet av BOB3 när data kommer
• Scenario 2 (DC-testscenario) en design som testar funktionaliteten av BOB3 via Data-Collection (DC) (Figur 3). Detta sker genom att ta emot data från kameran i systemet och kontrollera att data når databasen i datorn på ett rätt sätt som man förväntar sig.
• Scenario 3 (DC+HIL-testscenarion) en design som är en kombination mellan scenario 1 och scenario 2 (Figur 4) där HIL-testet utförs på en box och DC-testet utförs på en annan BOB3-box samtidigt. Detta sker genom att returnera klippet och data som spelas upp från databasen till HIL-scenariot och DC-scenariot.
BOB3 Databas IRIS Bilbuss (FlexRay) USB3 PC Image ECU BOB3 HIL-Player Databas Bilbuss MIPI USB3 PC
Figur 4 En design som presenterar en kombination mellan testscenario 1 (HIL) och
testscenario 2 (DC) där den returnerade data från ECU returneras till HIL-test och DC-test samtidigt. ECU BOB3 Databas IRIS Bilbuss (FlexRay) USB3 Kamera Image
Figur 3 En design som presenterar testscenario 2 (DC) där flödet av datatrafiken
kontrolleras genom att säkerställa att data går genom systemet från kameran fram till databasen vi BOB3 och IRIS. Detta ger möjligheten att testa om informationsinsamlingen i BOB3 sker på ett rätt sätt på datatrafiken som kommer från ECU utan att behöva köra systemet i verkligheten.
Denna studie kommer att implementera testmiljöer för de två traditionella scenarion (HIL och DC). Dessutom, kommer studien att analysera möjligheten att verkställa scenario 3 (DC+HIL-testscenario) och implementera en komplett testmiljö för det.
Frågeställningar
I denna rubrik listas ut frågeställningar som lägger fokus på att välja rätt testsscenario för beställaren (se scenario 1, 2 och 3 i kapitel 1.3.1) och implementerar automatiserade (HIL) hardware-in-the-loop- och (DC) Data-Collection-test som körs felfritt i scenarion.
• På vilket sätt designas och implementeras HIL- och DC-tester för scenario 1 respektive scenario 2 som senare kommuniceras med Jenkins-server (mer information om Jenkins finns i kapitel 2.5.1) för automatisering?
• Vad är möjligheten att skapa designen för scenario 3 i verkligheten och implementera en kombinerad test för DC och HIL?
o Går det att skicka datatrafiken (Image och Bilbuss) mellan HIL-delen och DC-delen i scenario 3? (se Figur 4)
o På vilket sätt designas och implementeras scenario 3 som senare kommuniceras med Jenkins-server för automatisering?
• På vilka sätt kan ett testscenario utvärderas så att prestanda av en implementation kan bestämmas med trovärdig noggrannhet?
o Vilken implementation av testscenario (scenario 1, 2 eller 3) ger kortaste exekveringstid? Arbetet med dessa frågeställningar kommer att avgränsas (se kapitel 1.5) för att hålla arbetet synkroniserat med beställarens krav och behov.
Avgränsningar
Trots att det finns många olika programmeringsspråk med olika prestanda som kan användas för att implementera en testmiljö för ett system, håller vi oss till programmeringsspråket Python enligt beställarens krav. Detta krav håller utvecklingsprocessen av produkten hos beställaren uniformerad med andra avdelningar vilket leder till lättare utvecklingsmöjligheter för testmiljön i framtiden.
På samma sätt så kommer automatiseringen att ske med hjälp av Jenkins-server som också är vald av beställaren vilket håller avdelningen där examensarbetet utförs i synkroniserad med andra avdelningar hos beställaren som också använder Jenkins-server.
Genom att ta hänsyn till den begränsade tiden som examensarbetet har så avgränsar arbetet med beställarens hårdvara till specifika typer och versioner. Dessa avgränsningar gäller valet av typen och versionen av kameran respektive BOB3-boxen som används i testscenarion enligt följande:
• På grund av den stora sortimentlistan av kameror hos beställaren som går att använda med ett testsystem så avgränsas arbetet med en specifik typ av kameror (på grund av sekretesskravet så kallas kamera typen för kamera1 version R4R2) som är en monokamera tillverkad av Autoliv. Detta val utgår från tillgängligheten av kameran för implementering under examensarbetet såsom tillgängligheten av konfigurationsfilerna som behövs för att ställa in kameran med. Dessutom, hjälper denna avgränsning att förbättra utvärderingsmomentet genom att använda samma kamera vid jämförelsen av olika testscenarion vilket eliminerar ändringarna på prestandan i testscenarion som resulteras av kameratypen.
• Avgränsningen utförs också på BOB3-mjukvaruversionen (4.0.0) som används vid implementationen av examensarbetet för att hålla fokus på att implementera en fungerande testmiljö för den senaste versionen. Denna testmiljön kan senare användas som en grundpunkt för andra BOB3-versioner.
Testen utförs på enbart en Bilbuss i BOB3-boxen vilket är en FlexRay-port då andra typer av kameror inte är tillgängliga under arbetet för att testa andra portar. Å andra sidan så syftar denna avgränsning på att avsluta genom tidrammen av examensarbetet.
Tiden också begränsar typerna av testutvärdering som utförs på ett HIL-test till en del av en typ vilket ökas i mån av tid när arbetet med examensarbetets huvudaspekter är klar (se 2.4.1 för mer information om HIL-testet och utvärderingstyper i Autoliv). Delen som är planerad att utvärdera kontrollerar den resulterade datatrafiken av HIL-test i jämförelse med en testade data i en databas.
Dessutom så begränsar tiden och tillståndet hos beställaren möjligheten att testa de producerade programmen i Jenkins-server vilket kan tas som ett extra moment för senare utveckling.
Källkritik
Källor som används i rapporten hittas genom att dels söka via Google Scholar eller Liu biblioteket och dels som muntliga källor från Autoliv. Dessutom så används också beställarens hemsida och databas som källor för information.
Källorna som väljs tillhör olika typer av källor såsom tidskrifter, konferensrapporter, böcker, weblänkar och muntliga källor av pålitliga personer i Autoliv.
Den största delen av källor i rapporten består av muntliga källor på grund av bristen i dokumentation i Autoliv särskilt när det gäller visionssystem, mätsystem, HIL och DC. Denna typ av källor är inte lika pålitliga som dokumenterade information då personen som väljs att ha som källa kan ändra tillstånd genom att exempelvis byta sitt arbete eller resa på ett sätt där det blir svårt att åtkomma vilket i sin tur leder till svårigheter att förstärka källans information när det behövs. Å andra sidan så under tiden av examensarbetet ger de muntliga källorna en stor hjälp för att gå vidare med arbetet då det är alltid mer flexibelt att ha en direkt mänsklig kontakt med en person som är insatt i ett specifikt ämne istället för en dokumentation.
2 Teori
I detta kapitel presenteras i mer detalj, komponenterna av ett visionssystem och ett mätsystem. Dessutom så utförs en studie på beställarens två testtekniker (HIL och DC) som används vid testning av mätsystemet och beskrivs de övriga verktyg som kan användas under arbetet vilka är Jenkins-server, UML-diagram och andra verktyg och bibliotek.
Kapitlet också presenterar beskrivning om tidigare relaterade arbete hos beställaren och andra tidigare studier som kan stödja arbetet vid utvärdering och implementering av testmiljöerna.
Visionssystem
Kamerasystemet som har förmågan att skanna miljön rund om en bil och detektera olika objekt på vägen vilket ökar säkerheten vid en körning och förhindrar tillkommande kollision. (Vision Systems, 2018-04-05)
Visionssystemet uppdelas till två huvuddelar, en kamera och ECU (Elctronic Control Unit) som Linus Blomquist (2018-04-04) beskriver som en box uppdelad till olika lager (Figur 5).
• FPGA ansvarar för direkt insamling av bilder från kameran och dess typ skiljer beroende på kameratypen
• Framework generaliserar insamlade data från kameran
• Vision-processorer består av 2–4 processorer som utför olika algoritmer och uppgifter såsom: o Lane upptäcker linjer i bilderna som kommer från kameran
o TSA/TSR ”Traffic Sign Assistant” och ”Traffic Sign Recognition” som upptäcker vägens skyltar
o IHC ”Intelligent Headlight Control” som reagerar med ljuset från bemötande bilar o OD ”Object Detection” som upptäcker olika hinder och objekt på vägen
o PD ”Pedestrian Detection” som upptäcker fotgängare och cyklister (Mikael Rudholm, 2018-04-18)
Datatrafiken som resulteras av processorerna flödar vidare till mätsystemet via Debug
• MCU ”Microcontroller Unit” som tar emot data om bilens tillstånd via Bilbuss och skickar den fram och tillbaka till Vision processorerna
Kamera Debug Bilbuss FPGA Frame work Vision-processorer
Figur 5 En detaljerad ritning för Visionssystemet som uppdelas till en kamera
och ECU som i sin tur är uppdelad till olika lagrar: FPGA, Framework, Vision processorer och MCU. Dessa olika komponenter har syftet att överföra och detektera detaljer om bilens omgivning.
Alla dessa lagrar arbetar tillsamman för att skapa detaljerade data om omgivningen för att sedan arkivera dem i en databas.
Mätsystem
Mätsystemet som studien utförs på består av olika hårdvaror som arkiverar datatrafiken av ett visionssystem i en databas.
2.2.1 BOB3
En ny generation av boxar som produceras av Autoliv och levereras till bilföretag för att hjälpa att analysera datatrafiken som kommer från ett visionssystem (se kapitel 2.1 för mer information om visionssystemet) vilket ger möjligheten att utveckla visionssystemet och förbättra samt kontrollera dess egenskaper innan leverans mot slutkunden sker.
Den huvuduppgiften som BOB3 uppfyller är att tidsstämpla data som kommer från ett visionssystem i rätt sekvens och spara den i en databas. Denna uppgift ger möjligheten att synkronisera datatrafiken då en arkiverad och stämplad data kan användas igen och återspeglas i samma ordning vid andra tillfälle. (Mikael Rudholm, 2018-04-18)
Mikael Rudholm (2018-04-18) förklarar också syftet med tidstämplingen vilket är behovet att ha datatrafiken organiserad och ge möjligheten att analysera data på ett rätt sätt vid utvecklingen av ett visionssystem. Dessutom återanvänds datatrafiken i andra tester i laboratorium såsom HIL-tester (mer information om HIL finns i kapitel 2.4.1) för att kontrollera beteendet av ett visionssystem under utvecklingsprocessen. Kontrollen sker i en kedja av steg som utförs för att säkerställa rättfunktionalitet av ett visionssystem med en ny utvecklad mjukvara där den arkiverade data som stämplades av en BOB3 återanvänds i en HIL-test för att analysera resultatet och bedöma funktionaliteten. Detta kan uppföljas i
Figur 6 som visar testprocessen som utförs på ett visionssystem vid utveckling av ny mjukvara.
Figur 6 Processen som utförs av en biltillverkare på ett visionssystem vid
utveckling av mjukvara för att säkerställa inga försämringar i funktionaliteten av systemet (rätt beteende). Detta sker genom att återanvända en arkiverad data i HIL-tester för att simulera verkligheten och undersöka att systemet ger rätt resultat som ficks av ett rätt arkiverat beteende innan.
Ny mjukvara (ECU)
Rätt beteende? Arkiverat data från (BOB3)
HIL-test Statistik Analys
Förbättring på (ECU)
2.2.2 IRIS
Ett program som är nedladdad i en dator (Figur 1) och har förmågan att spela in datatrafiken som består av bilder, information om hårdvaran som är kopplade i systemet och andra information såsom detekterade objekt och kalibreringsparametrar. Dessutom så har programmet förmågan att spela upp data för analyssyfte som kan tillkomma vid exempelvis kontrollering av hårdvarans version. (Wolf Ulmanen, 2018-04-04)
2.2.3 HIL-Player
Ett Shell-rasprogram som används i syftet att utvärdera algoritmer i ECU (se kapitel 2.1 för mer information om ECU) och säkerställa kommunikationen mellan en BOB3-box (se kapitel 2.2.1 för mer information om BOB3) och själva programmet i en HIL-test. (Per Andersson, 2018-04-17)
Per Andersson (2018-04-17) också beskriver kortfattat vilka funktioner ett HIL-Player-program har vilka består av förmågan att:
• spela upp delar av en arkiverad ADTF-fil (Automotive Data and Time-Triggered Framework-file) som resulterades av ett mätsystem i en riktig bilkörning och sparades in i en databas
• spela in datatrafiken som kommer från en ECU via en BOB3 i en databas som ADTF-fil
Dessa förmågor används i en HIL-test (se kapitel 2.4.1 för mer information om HIL-test) för att skapa en loop av datatrafik i ett system (Figur 7) där sparade data spelas upp till ett system via HIL-Player som senare spelar in returnerade data och sparar det i en databas. Detta resulterar arkiverade data som kan analyseras av en testare (manuellt i dagsläget).
Programmets funktioner kommer att användas vid implementationen av HIL-testscenariot (se Scenario 1 i kapitel 1.3) senare i arbetet då en intern dokumentation används för att ha tillgång till olika styrningskommandorader som behövs för att styra HIL-Player.
FlexRay
Flexray (FR) är en robust datakommunikations protokoll som används inom bilindustrin. FR stödjer både ”time-triggered” och ”event-triggered” kommunikation och tillåter en datahastighet upp till 10 Mbits/s per kommunikationskanal. (How FlexRay works, 2018-05-20)
En FR schema består av ett antal kommunikationscyklar, där alla cyklar har liknande struktur men meddelandet i varje cykel kan vara annorlunda. En FR kommunikationscykel består av fyra olika delar. Figur 8 visar hur FR kommunikation cyklar för statiska och dynamiska delarna fungerar. De delarna beskrivs av Sagstetter, Lukasiewycz, och Chakraborty i ”Generalized Asynchronous Time-Triggered Scheduling for FlexRay” året 2017 i sidorna 214–217 enligt följande.
ECU ECU HIL-Player (uppspelning) HIL-Player (inspelning) BOB3 BOB
Figur 7 En översiktlig design som visar användningen av
HIL-Player-programmets förmågor (uppspelning och inspelning) i en HIL-test där uppspelningsfunktionen skickar data till BOB3 som i sin tur överför det vidare till ECU som utför sina algoritmer och skickar data tillbaka till BOB3 som tidsstämplar datatrafiken och överför den till HIL-Player som inspelar den.
• Den ena är en statisk del där meddelanden överförs genom ett fördefinierat schema. Denna del består av ett antal ”slots” av liknande storlek och varje sådant slott har ”header”,
”trailer” och ”payload”. En slot har data från 0 till 254 bitar.
• En dynamisk del där mindre kritiska information och ”event-triggered” data överförs. • Ett fönster för att överföra speciella symboler.
• Vilotiden för synkronisering av nätverksnoder
David Dahlen (2018-05-25) beskriver kortfattat den inre strukturen av en FR-port (Figur 9) som används i BOB3. Porten består av två par av kontroller (kallas för FlexRay-1 och FlexRay-2) där i varje par finns en kontroller som ansvarar för utskickning av data och en för insamling av data. De kontrollerna är kopplade
Figur 8 Hur FR kommunikation cyklar för statiska och dynamiska delarna fungerar. Där varje ruta i matrisen presenteras med hjälp av slot och Base som bestämmer position medan Repetitions bestämmer när denna ruta repeterar sig. Dessutom så uppdelas matrisen till två delar, en statisk där rutorna alltid besökas av systemet under varje runda (Cycle) och en dynamisk del som innehåller extra rutor som kan användas vid behov.
på ett sätt som säkerställer att allt data som skrivs i FR-buffert för utskickning samlas in och returneras vilket skapas en sort av inreloop inuti porten.
Testtekniker
Kapitlet presenterar två testtekniker som används av Autoliv vid testning av sina produkter. Dessa tekniker är HIL- och DC-test som utförs i syftet att säkerställa att inga försämringar i systemets funktionalitet sker vid utveckling av mjukvara för Autolivs produkter.
2.4.1 Hardware-in-the-loop (HIL)
Hardware-in-the-loopsimulation är en metod som ger möjligheten att testa ett system i en simulerad miljö där en del av komponenterna är verkliga och en del är simulerade, vilket minskar tiden och kostnaden som en verklig test kan kräva. (Isermann, Schaffnit and Sinsel 1999 p.643).
Ogan (2015 p.167) visar i boken ”Hardware-in-the-Loop Simulation” av Loper (2015) det stora intervallet av branscher som nu använder HIL-simulation vilket sträcker sig från medicinbranschens till elkraftproduktion fram till fordonbranschen. Ogan (2015) också presenterar huvudfördelen med att använda HIL-simulation vid testning av ett system vilken består av möjligheten att kontrollera pålitligheten och funktionaliteten av ett system utan att riskera skador på systemet i helheten. Dessutom ger denna metod möjligheten att testa ett system även om ekonomiska eller fysiska hinder uppstår som hindrar utförandet av testningen i verkligheten.
Historiken av användningen av HIL-simulation började enligt Isermann, Schaffnit and Sinsel (1999) sedan 1936 i flygindustrin där komponenterna testades med en fast kaptenkabin som senare används vid träning av piloter. Denna metod även spridde sig i fordonsindustrin för att testa olika delar i fordon såsom stötdämparen och ABS-systemet utan att behöva utsätta varje del i en verklig körningsmiljö för testning.
Figur 9 En inrestruktur av en FR-port där porten har två par av kontroller FR-1 och FR-2
som ansvarar för utskickning och insamling av data (varje par har en kontroller för utskickning och en för insamling).
Utifrån karaktären av HIL-simulering, som Isermann, Schaffnit and Sinsel (1999) beskriver, så byggs simuleringen av en kontroller (hårdvara) och simulator som är kopplade via dator. Detta visas översiktligt i Figur 10.
Denna design ger möjligheten att skicka testdata via ett system i en loop vilket hjälper en testare att prova ett system även med extrema och farliga fall på ett system inne på laboratorium.
Linus Blomquist (2018-04-04) beskriver syftet med användningen av HIL-test i Autoliv vilket presenteras med möjligheten att säkerställa att en ny mjukvara nedladdad till en komponent inte ändrar funktionaliteten av komponenten. Detta sker genom att koppla hårdvaran (vid intervjun hårdvaran var en ECU) som ska testas i ett testsystem som liknar verkligheten och använda redan arkiverade data i en databas som utgångs datatrafik som loopar från databasen via systemet fram till ECU och tillbaka sedan till databasen via testsystemet. Efter detta, utvärderas detta returnerade data av testaren för att analysera om hårdvarans funktionalitet har ändrats. På detta sätt säkerställas att den nya mjukvaran inte har förstört hårdvarans beteende.
Dokumentationen ”HIL Test Specification” (2018-05-20) i Autoliv representerar olika metoder som används för att utvärdera Funktionaliteten under ett HIL-test. De metoderna utförs genom att kontrollera olika aspekter av testresultatet där en del beskrivs enligt följande.
• Kontrollera att signalerna som är förväntade i en ADTF-fil som spelas av HIL-Player är tillgängliga.
• Kontrollera att den resulterade ADTF-filen har inga förlorade bitar av datatrafiken
• Kontrollera att datagrupperna i en resulterad ADTF-fil är organiserade i samma ordning som den ursprungliga filen (filen som utspelas via HIL-Player)
På det sättet säkerställs att data inte ändras när det flödar genom en hårdvara med en ny mjukvara nedladdad.
2.4.2 Data-Collection (DC)
DC är en process där data samlas och mätas från ett system. Syftet med DC är att öppna möjligheten för testningar på ett system i en simulerad miljö där data kan utvärderas och analyseras samt justeras för att anpassa till olika testmiljöer. Exempelvis, när en DC-test utförs och data lagras i en databas så finns det möjligheter att använda det lagrade data för att utföra andra typer av tester som kan hjälpa andra utvecklare att hitta buggar och utreda fel i andra delar av det testade systemet. DC-testprocessen ger möjligheter till Autoliv att leverera kvalité produkter till kunder.
Wolf Ulmanen (2018-04-10) beskriver hur en DC-test utförs i Autoliv genom att förklara syftet och processen av denna testteknik. Denna test syftar på att säkerställa rätt flöde för datatrafik i ett system genom att implementera den testade hårdvaran i ett simulerat system (Figur 11) och testa om datatrafiken går genom hela systemet. Ett exempel som i nuläget utförs manuellt är en DC-test på produkten BOB3 (se kapitel 2.2.1 för mer information om BOB3) där produkten kopplas med ett visionssystem (se visionssystem i kapitel 2.1) och en dator. Denna test utförs genom att ta emot bilder från visionssystemet och kontrollera
Utgång
Hårdvara Simulator
Återkoppling
Figur 10En grundbild av HIL-simulering. Visar hur en loop genomförs mellan hårdvaran och simulatorn där samma data går fram och tillbaka för att sedan utvärderas.
att data flödar genom BOB3 ända fram till databasen i datorn. Förstås, eftersom denna test utförs manuellt så analyseras flödet manuellt av en testare som kontrollerar att de behandlade bilderna och de andra parametrarna som kommer från visionssystemet via BOB3 har lagrats i databasen på ett rätt sätt.
En sådan testteknik visar sin effektivitet i Autoliv då den säkerställer att en ny nedladdad mjukvara inte förstör funktionaliteten av hårdvaran och samtidigt inte skapar något problem med kommunikationen mellan hårdvaran och de andra komponenterna i ett system.
Övriga verktyg
2.5.1 Jenkins
Jenkins är en öppen källa server som kan användas för kontinuerlig integration (CI). Servern är skriven i java men olika andra programmeringsspråk kan användas som PHP och .NET. (Smart 2011 p.3)
Enligt Smart (2011 p.3) så har Jenkins flera fördelar:
• Ett enkelt program med ett enkelt gränssnitt som är lätt att lära in. • Trots enkelheten är programmet starkt och flexibel.
• Jenkins-samhälle är stort och aktivt vilket kan underlätta arbetet med programmet.
Verktyget använder vad det kallas för ”Jenkins Pipeline” som är ett set av plugin-program som kan skrivas i olika programmeringsspråk såsom Java, Python, PHP, mm vilket används som automatiserade beskrivningar för vilken väg en mjukvara ska ta för att flytta från utvecklingsfasen ända till användaren.
Figur 11 En grundbild av DC-simulering. Visar hur data genomförs mellan hårdvaran och
simulanter för att utvärderas.
UT-Data Hårdvara Hårdvara Simulator Simulator IN-Data
Ett exempel på en simple ”Jenkins Pipeline” visas i Figur 12 där en task är skriven med Python-språk för att presentera Python-versionen som är tillgänglig i maskinen där koden exekveras.
Uppgifterna i varje ”Pipeline” är uppdelade i steg ”Steps” där varje steg kan tolkas som en order att utföra. Dessa steg är inkluderade i faser ”Stages” som beskriver vilken fas är processen i och ett misslyckande markeras i sin respektive fas. (Jenkins Steps, 2018-04-10)
Denna användning av ”Jenkins Pipeline” ger möjligheten att utsätta mjukvara på olika processer innan den når dess slutliga version vilket bidrar till att bibehålla mjukvarans kvalitet i en hög nivå. (Jenkins Pipeline, 2018-04-10)
Under arbetet med servern kommer Jenkins-guiden (2018) att användas som ett läromaterial för att konfigurera testmiljön som utvecklas och implementera den i Jenkins när det är möjligt.
2.5.2 UML (Unified Modeling Language)
Objektorentiering är ett viktigt koncept inom mjukvaruutveckling. Den har visat sig vara en väl etablerad metod för att hantera och lösa komplexa problem inom mjukvaruutveckling. Detta gäller inte bara programmering utan kan även etableras inom andra områden såsom databaser. Objektorentiering kan även användas för att kunna på ett enkelt sätt modellera olika typer av system för att lättare förstå och hantera systemet.
”Unified Modeling Language” (UML) är ett visuellt objektorienterat modelleringsspråk för att specificera,
designa, visualisera och dokumentera olika aspekter av ett system och på vilket sätt man har valt att presentera det. Resultatet av modellering med UML är en grafisk modell som visar olika synvinklar och relationer av systemet i form av ett diagram. (Seidl, M., Scholz, M., et al. 2015)
Figur 13 visar ett översiktligt exempel på hur ett UML-diagram ser ut och hur de olika delar i diagrammet
ger en tydligare bild på hur delarna av ett program är kopplade ihop.
Figur 12 Ett enkelt exempel på en Jenkins Pipeline skriven i Python. Denna kod
beskriver en uppgift på att visa versionen av Python som är tillgänglig i en maskin. https://jenkins.io/doc/pipeline/tour/hello-world/ (2018-04-10)
Seidl, M., Scholz, M., et al. (2015) visar också i boken ”UML @ classroom” att det finns olika nivå av UML-diagram, ett som presenterar vilka användare som använder en viss funktionalitet, ett som presenterar och visar strukturen av programmet men utan att specificera en konkret implantation och man kan även ange vilka processer som är tillåtna och förbjudna med hjälp av ett UML-diagram.
Det finns olika typer av strukturdiagram i UML. De viktigaste är klass-, objekt-, paket och timingsdiagram. (uml-diagram-types-list, 208-05-18)
• Ett klassdiagram representerar de olika klasserna i ett program och relationerna mellan dem (Figur 13). Klassdiagrammet också visar datastrukturen och objektstrukturen av systemet. • Objektdiagrammet däremot visar en bild av systemets tillstånd i en viss utförd tid.
• Paketdiagrammet grupperar olika diagram eller moduler baserade på gemensamma egenskaper, exempelvis samma funktionalitet.
• ett Timing-diagram är en typ av interaktions UML-diagram som koncentrerar på processer under bestämd tidsintervall. Timing-diagrammet läsas från vänster till höger istället för andra typ av diagram som läsas uppifrån nedåt.
2.5.3 ADTF avsökningsverktyg
Autoliv har utvecklat bland annat två verktyg, FD_AdtfDebug och FdAdtfIo som kan användas vid analys av ADTF-filer (DAT) som resulteras av DC- och HIL-testen.
• FD_AdtfDebug är ett Shell-program som används för att läsa och skriva ut ADTF-data såsom bilder metadata, Debug-data och bilder data. Programmet har olika tillval för att trimma informationen som skrivs ut vilket hjälper med att hitta rätt information i en stormängd av utgångsdata. (ADTF debug tool, 2018-05-18)
Figur 13 En översiktlig bild på hur ett UML-klassdiagram representeras där varje klass i ett
program presenteras som en box med sina variabler (-/+ betyder privat/publik) och funktioner. Dessutom så visas på diagrammet vilka relationer de olika klasserna har mellan varandra.
Class namn
variabler: typ och namn Ex: + Var1: int - Var2: Class2 + Var3: Class3
Funktioner: typ, namn och returvärde Ex: + int Func(int)
Class2 … … Class3 … … Child Class … …
Dokumentationen ADTF debug tool (2018-05-28) visar också hur verktyget tillkallas och vilka val det har följt med beskrivningar om funktionaliteten och syftet. Exempelvis så kan följande kommandoraden
adtfDebug.exe --show-image-metadata <ADTF-fil>
anropa verktyget med valet att visa metadata information for bilder i en ADTF-fil.
Informationen som skrivs ut är läsbara och visas på standardoutput på terminalen. Detta kan senare styras med extra kommando för att arkivera informationen i en TXT-fil.
• FdAdtfIo som enligt Robin Axelsson (2018-05-17) är ett bibliotek skriven med Python-språk och utvecklats av arbetsgruppen i Measerment System-avdelningen i Autoliv för att presentera data från en ADTF-fil. Syfte med detta verktyg ar att underlätta analysen av ADTF-data som returneras från DC- och HIL-testen och organisera de i bland annat en lista av värden som går senare att manipulera och skriva ut.
Biblioteket har olika funktioner som läser och tolkar data i en ADTF-fil såsom get_chunk_count som returnerar antal datagrupper (frames) som filen innehåller (i en ADTF-fil uppdelas data i grupper där varje grupp har metadata som ger information om gruppens data såsom tid och storlek, följd med själva data). Ett till exempel är get_data som samlar metadata och data av en grupp i en lista (Array) som returneras. Data som tolkas av biblioteket presenteras med siffror som representerar minnets innehåll för varje datagrupp.
2.5.4 DAT_Sanity_Test
Ett Shell-program som läser tidsstämpling av ett Blidström i en ADTF-fil som en BOB3-box resulterar, för att kontrollera att stämplingen sker i ordning, det vill säga att en datagrupp som kommer efter en annan ska inte har en mindre tidsstämpel. Dessutom så kontrollerar programmet om stora hopp i tiden sker vid stämplingen av successiva grupper vilket kan tolkas som en stor latens i BOB3-boxen. (Mustafa Jalal 2018-05-15)
På samma sätt som andra Shell-program så anropas verktyget via terminalen snaityTest.exe <ADTF-fil>
genom att anropa programmet och infoga sökvägen för filen som ska analyseras.
Resultat av denna test arkiveras i en JSON-fil som innehåller information om typen av testet, version, datum och tid, beskrivning, möjliga felkod och slut resultatet i typ av sant eller falskt värde. Ett exempel på en JSON-fil av ett misslyckat test visas i Figur 14 som innehåller en beskrivning om vilket fel som har uppstått.
Figur 14 En JSON-fil resulterades av DAT_Sanity_Test som beskriver testet och dess resultat med en
Internt relaterat arbete
Under en intervju med Linus Blomquist (2018-04-04) presenteras ett projekt som utfördes i en annan avdelning i Autoliv gruppen HIL-Crew och berör HIL-testtekniken. Detta projekt utvecklades med hjälp av en Python-script som representerar en implementation för HIL-test på ECU-hårdvaran (se kapitel 2.1 för mer information om ECU).
Linus Blomquist (2014-04-04) presenterar först designen på HIL-testsystemet som visas i Figur 15. Där kopplas en ECU med resten av testsystemet via en BOB3 (se kapitel 2.2.1 för mer information om BOB3). Dessutom så presenterar Linus Blomqvist också en utmaning som inträffades i designfasen vilken är kopplingen av dataströmmen av Debug-data mellan BOB3 och ECU som har olika typer (Flexray (FR) För BOB3 och Broad Reach (BRR) För ECU). Denna utmaning löstes genom att ha en portgång (Gateway) som konverterar signalerna fram och tillbaka mellan hårdvarorna.
Efter designpresentationen förklarar Linus Blomquist också kortfattat arbetet som ledde till Python-scripten som ger möjligheten at utföra HIL-testen på den kopplade ECU genom att skicka den lämpliga datatrafiken till ECU som i sin tur returnerar respons.
Python-scripten som används i HIL-testen består av olika filer som styr testens olika moment.
• Konfiguration av parametersskrivningen såsom kameravinkel och position som krävs för att kalibrera ECU på samma sätt som verkligheten.
• Inläsning från databasen för att skapa en ström av bilder som används som en simulation till verkligheten (bilder som kommer från en vanlig kamera).
Arbetet använder dock en manuell metod för att validera de returnerade data från ECU vilket sker via direkt kontakt mellan det resulterade data och testare vid analysen.
Designen i detta relaterade arbetet liknar i stort sett designen för HIL-testscenariot (se scenario 1 i kapitel 1.3.1), vilket ger möjligheten att använda arbetet som en inspiration vid utvecklingen av HIL-testmiljön för BOB3.
Figur 15 En design till HIL-testsystemet som utvecklades av HIL-Crew och presenterades av Linus Blomquist under examensarbetet. Systemet skickar bilder från en dator till BOB3 ända fram till ECU och andra analys-data fram och tillbaka via en Dator, BOB3 och ECU (Via GW för signals konvertering). Allt detta styrs med en Python-script.
BOB3 ECU
Gateway (GW)
Flexray (FR) Broad Reach
(BRR) Bilder Databas IRIS HIL-Player Python-script Dator
3 Metoden
För att underlätta arbetet med exjobbet uppdelas metodkapitlet till olika rubriker som beskriver metoderna för att utveckla testmiljöer för examensarbetets testscenarion (se kapitel 1.3). För varje testscenario så uppdelas arbetet till underrubriker som beskriver olika faser av utvecklingsprocessen. Dessa faser flyttar varje scenario från ett förslag fram till en färdig produkt (program) redo för utvärdering och analys. Syftet med den uppdelningen är att organisera arbetet som beskrivs i metoden vilket ger bättre replikerbarhet. Dessutom så beskrivs metoderna som används för att samla och utvärdera prestandan för de utvecklade testscenariona i jämförelse med varandra.
En visualisering av arbetsgången kan uppföljas i Figur 16. Där visas ett flödesdiagram som beskriver flödet av arbetet och hur exjobbet flyttar sig från startpunkten som börjar med förslaget fram till implementationen (testprogrammen för olika scenarion) och testning av produkterna.
Som man ser i Figur 16 så börjar arbetet med att verkställa DC-testscenariot först via utförandet av olika faser.
• Koppling av förslag i verkligheten och testa kopplingen manuellt.
• Design och Implementation av programmet som ska automatisera testscenariot. Dessutom så samlas data om exekveringstiden för programmet och det manuella utförandet av scenariot för att senare använda detta data vid jämförelsen mellan det utvecklade programmet och det manuella utförandet av testet, samt det utvecklade programmet och det tredje scenariot (se scenario 3 i kapitel 1.3.1).
På samma sätt verkställas HIL-testscenariot genom utförandet av samma utvecklingsfaser som DC-testscenariot. Sedan utförs en analys om möjligheten att koppla DC och HIL ihop för att skapa det tredje testscenariot och efter det så utförs ett utvärderingsmoment som jämför de insamlade data för att formulera en slutsats om arbetet.
Analys
Att koppla DC+HIL-Scenario i verkligheten?
Figur 16 Ett flödesdiagram som beskriver arbetsgång under examensarbetet. Processen börjar med att verkställa DC-testscenario sedan HIL-testscenario. Arbeten med DC- och HIL-scenario utförs i olika faser som flyttar varje scenario från design till en färdig produkt (program) som resulterar data för insamling. Efter det så utför ett arbete för att svara på frågan om möjligheten att koppla det tredje scenariot i verkligheten innan man fortsätter vidare till utvecklingen och utvärderingen senare.
Start
Förslag scenario 1, 2 och 3
DC-testscenario
Design, implementation och datainsamling Koppling
HIL-testscenario
Design, implementation och datainsamling Koppling
DC+HIL-testscenario
Design, implementation och datainsamling Koppling
Slut
Utvärdering och analys av resultat
Utvec
k
ling
av
t
es
tm
il
jöer
DC-testscenario
Orsaken med att börja arbetet med DC-testscenariot är den låga svårighetsnivån av scenariot i jämförelse med de andra två scenarion. Detta arbete börjar med en kopplingsfas som uppföljs med en design- och implementeringsfasen.
3.1.1 Koppling
Koppling sker enligt instruktioner och dokumentation som Autoliv förberedde innanför examensarbetet med syfte att kunna utföra DC-test manuellt. Komponenterna som DC-test behöver vid manuell testning är en ECU tillsammans med en BOB3 och en dator med IRIS-program installerat (se kapitel 2.1 och 2.2 för mer information om komponenterna).
Utifrån en överenskommelse med Autoliv väljs specifika typer av BOB3 mjukvara (4.0.0) och ECU typ (kamera1 version R4R2) för att kunna utföra testerna (se kapitel 1.5). Genom att köra manuella testningar bekräftas att DC-testning fungerar som förväntat och även bekräftas att alla komponenter kan kommunicera med varandra med rätt konfiguration.
IRIS som beskrevs i kapitlet 2.2.2 är ett program som Autoliv skapade för att utföra ett DC-test på ett mätsystem (se Figur 17 för en översiktlig bild över programmet). IRIS huvuduppgift är att kunna ta emot data från BOB3 i systemet och spara det i en databas. Programmet har också förmågan att strömma bilderna som kommer från mätsystemet direkt på en skärm för att ge en möjlighet till en manuell kontroll.
Med hjälp av kopplingen och det manuella testet förbereddas DC-testscenario för implementation av en automatiserad miljö med Python-språket som Autoliv håller sig till (se kapitel 1.5 för information om avgränsningar.
3.1.2 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
DC-Körning Kontroll IRIS Konfiguration IRIS Konfiguration DC-Kontrollskapa 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.
