Under arbetet designades och implementerades två Python-program som representerar utförandet av HIL- och DC-test i HIL-testscenario (scenario1) respektive DC-testscenario (scenario 2). Dessutom analyserades möjligheten att koppla DC+HIL-testscenario (scenario 3) och en design och implementation av ett Python- program utfördes för scenariot.
Utifrån detta arbete besvaras frågeställningarna på följande sätt.
På vilket sätt designas och implementeras HIL- och DC-tester för scenario 1 respektive scenario 2 som senare kommuniceras med Jenkins-server för automatisering?
Genom att imitera stegen som utförs vid manuella testningar för HIL- och DC-test så designas två testprogram (HIL- och DC-testprogram).
Designen och implementationen för det första programmet (DC-testprogram) består av olika klasser där varje klass ansvarar för en del av den manuella testningen: Main, DCTest, IRISConfigurations och Logger vilka ansvarar för styrningen av testet i helhet, kommunikationen mellan testet och andra verktyg, användningen av IRIS-programmet respektive dokumenteringen av testets information.
Designen och implementationen för det andra programmet (HIL-testprogram) består av klasserna Main,
HILTest, HILPlayerConfigurations och Logger vilka styr testet i sin helhet, skapar en
kommunikationspunkt mellan Main och HIL-Player-verktyget, förbereder HIL-Player för användningen under testet respektive arkivering av testets information.
Dessutom sker en justering i kopplingen av HIL-testscenariot för att kunna komplettera kontrollmomentet i HIL-testet som jämför det returnerade datatrafiken med ett facit i en databas. Denna justering presenteras med en FlexRay-loop som ersätter kopplingen mellan ECU- och BOB3-hårdvaran för att säkerställa inga ändringar sker av ECU på datatrafiken som flödar i systemet.
Klasserna som designas för båda HIL- och DC-testscenario implementeras och testas i två nivåer (en grundnivå för varje klass separat och en globalnivå för hela programmet).
När det gäller kommuniceringen med Jenkins-server så begränsade tidsramen möjligheten att utföra momentet vilket nämnts i Avgränsningar-kapitlet (se kapitel 1.5).
Vad är möjligheten att skapa designen för scenario 3 i verkligheten och implementera en kombinerad test för DC och HIL?
Denna frågeställning besvaras genom att besvara på underfrågorna som uppdelar frågan till mindre delar. • Går det att skicka datatrafiken (Image och Bilbuss) mellan HIL-delen och DC-delen i
scenario 3?
Praktiken visar att möjligheten att överföra datatrafik mellan HIL- och DC-delen är tillgängligt men med en justering i kopplingen av scenariot då hårdvaran inte är kompatibel med att koppla bilbussen (FlexRay i fallet av examensarbetet) mellan en ECU-hårdvara och två BOB3-boxar samtidigt. Denna justering leder till att ersätta kopplingen mellan ECU och HIL-delen i scenario 3 med en FlexRay-loop som direkt returnerar datatrafiken.
• På vilket sätt designas och implementeras scenario 3 som senare kommuniceras med Jenkins-
server för automatisering?
Designen för implementationen av scenario 3 (DC+HIL-testprogram) består av en kombination av DC- och HIL-testprogram där klasserna Main (för DC-delen), DCTest, IRISConfigurations, Logger
(för DC-delen), Main (för HIL-delen), HILTest, HILPlayerConfigurations och Logger (för HIL- delen) är presenterade i programmet med en addition av en kommunikationsmöjlighet som presenteras med ett gemensamt minne mellan DC- och HIL-delen.
Dessutom sker samma justering som utförs på kopplingen av HIL-delen vilket är FlexRay-loopen som ersätter kopplingen med ECU-hårdvaran för att kunna komplettera kontrollmomentet i HIL- testet som jämför det returnerade datatrafiken med ett facit i en databas.
Klasserna som designas för båda HIL- och DC-delen också implementeras och testas i två nivåer (en grundnivå för varje klass separat och en globalnivå för hela programmet).
När det gäller kommuniceringen med Jenkins-server så begränsade också tidsramen möjligheten att utföra momentet vilket nämnts i Avgränsningar-kapitlet (se kapitel 1.5).
På vilka sätt kan ett testscenario utvärderas så att prestanda av en implementation kan bestämmas med trovärdig noggrannhet?
Genom att samla in exekveringstidsvärden för de tre utvecklade program skapas en möjlighet att analysera förbättringen eller försämringen som varje implementation har. Detta sker i jämförelse mellan programmen och de manuella testningsmetoderna (gäller DC- och HIL-testscenario) och mellan varandra (implementationen av DC+HIL-testscenariot i jämförelse med implementationerna av DC- och HIL- testscenario).
• Vilken implementation av testscenario (scenario 1, 2 eller 3) ger kortaste exekveringstid? Vid jämförelsen mellan programmet för scenario 1 (HIL-testscenario) och den manuella HIL- testningen visade programmet kortare genomsnittliga exekveringstider med upptill 42,3 % vilket tolkas som en förbättring på effektiviteten av testningen och en minskning på användningen av tids- och arbetsresurserna. Förstås denna förbättring beror på tillståndet av systemet och vilka fel kan uppstå vid utförandet av ett test.
I jämförelsen mellan programmet för scenario 2 (DC-testscenario) och den manuella DC-testningen så visade programmet kortare genomsnittliga exekveringstider med upp till 80,67 % för ett fungerande system vilket också tolkas som en förbättring på effektiviteten av testningen.
Vid jämförelsen mellan programmen för scenario 1 och 2 (HIL- och DC-testscenario) mot programmet för scenario 3 (DC+HIL-testscenario) så visade siffrorna att scenario 3 har i allmänhet sämre exekveringstider på upp till 55,5 % i jämförelsen med scenario 1 och scenario 2 tillsammans. Detta beror i stor del på relationen mellan DC- och HIL-delen i scenario 3 som skapar längre väntetider mellan starten av ett test och upptäckandet av ett fel. En sådan försämring inträffar inte i fallet av ett fungerande system då exekveringstiden är samma. Å andra sidan finns det fördelar med att använda scenario 3 vid testningen vilka presenteras med besparingen av hårdvara resurser och den fasta datatrafiken som flödar genom scenario 3 (bilderna som överförs till DC-delen) som kan utnyttjas på ett bättre sätt än Scenario 1 och Scenario 2.
Dessutom så presenteras några förslag om vilka vidare arbeten och utvecklingar som kan utföras på examensarbete. Dessa förslag uppdelas mellan utvecklingen av programmen som implementerades för examensarbetets tre testscenarion och utvecklingen för själva kopplingen av testscenarion.
Först, skulle vidareutveckling på de producerade programmen bidra till bättre effektivitet som leder till enklare användning av programmen. Denna utveckling kan börjas med att förbättra metoden som används
vid hänvisning till olika nödvändiga verktyg, program och filer för respektive testscenarior. Detta sker genom att först testa hänvisningsmetoden (fasta adresser) efter flyttningen av programmen globalt (till Jenkins-server) och sedan försöka exempelvis ändra sökvägarna i programmet till en mer dynamisk version genom att använda programmets adress som en utgångspunkt till alla andra adresser.
Värden i variablerna som kontrollerar väntetidsperioderna i programmen är utvalda på ett sätt som passar hårdvaran och ADTF-filerna som användes under examensarbetet. En utveckling kan genomföras för att testa lämpligheten av tidsvärdena för andra typer kameror och ADTF-filer. Detta kan bidra till mera gemensamma värden som är lämpliga till större intervall av hårdvara och ADTF-filer.
Dessutom, kan mer arbete ske på det data som sparas i ADTF-filer för att utveckla ett analysverktyg i Autoliv som kan visa mer läsbara information som presenterar datatrafiken i en ADTF-fil istället för siffror i exempelvis FdAdtfIo-biblioteket (se kapitel 2.5.3 för mer information om FdAdtfIo). Ett verktyg som underlättar arbetet med automatiseringen i Autoliv.
En till ide för hjälpverktygen som används med programmen kan vara ett kombinerat verktyg som utvecklas för att skapa en kombination av funktionaliteter för HIL-Player och IRIS-program i en och samma miljö för att eliminera eventuella konflikter som kan inträffa.
Sista förslaget riktar sig mot komponenterna som ett testscenario består av vilka kan utvecklas genom att manipulera dess FPGA för att skapa mer kompatibla versioner av komponenter. Denna manipulation kan riktas mot ECU-komponenten för att öppna möjligheten att exempelvis kunna kommunicera med HIL- Player och IRIS-program samtidigt via samma FlexRay-port eller kunna överföra samma klipp flera gånger i rad. Detta kan lösa felen som inträffades och presenterades i kapitel 4.3.1.