Validering av testparametrar

(1)

EXAMENSARBETE INOM MASKINTEKNIK, Maskinteknik, högskoleingenjör 15 hp SÖDERTÄLJE, SVERIGE 2017

Validering av testparametrar

- En kvantitativ analys av användardata

David Bryngelsson Matteus Arriaza-Hult

SKOLAN FÖR INDUSTRIELL TEKNIK OCH MANAGEMENT INSTITUTIONEN FÖR TILLÄMPAD MASKINTEKNIK

(2)

(3)

Validering av testparametrar

av

David Bryngelsson Matteus Arriaza-Hult

Examensarbete TMT 2017:39 KTH Industriell teknik och management

Tillämpad maskinteknik Mariekällgatan 3, 151 81 Södertälje

(4)

Examensarbete TMT 2017:39

Validering av testparametrar

Godkänt

2017-06-21

Examinator KTH

Alexander Engström

Handledare KTH

Håkan Carlqvist

Uppdragsgivare

Scania CV AB

Företagskontakt/handledare

Max af Klintberg

Sammanfattning

Användandet av olika system innehållande mjukvara i samhället ökar konstant. Ökat användande och ökad tillgänglighet till mjukvara leder till att högre krav ställs på prestanda och tillförlitliga produkter. Därav har kvalitetssäkring av mjukvara blivit et viktigt inslag hos företag för att kunna garantera kvalitet hos sina produkter. Scania har som mål att släppa produkter av högsta kvalitét vare sig det är hårdvara eller mjukvara. Scania har förutom sin fordonstillverkning även verksamhet inom eftermarknad som bland annat tillverkar produkten Scania diagnose and programmer 3 (SDP3). SDP3 är en mjukvara som används för diagnostisering och

programmering av styrenheter på Scaniafordon.

Ett tidigare examensarbete på gruppen YSPV (Kvalitet, integration och test) har tagit fram en teststruktur bestående av parametrar som SDP3 bör ha testats mot under betatestning. Målet är att teststrukturen ska kunna användas som en statisk mall för att utvärdera kvalitén på både mjukvaran och betatesten. Vid start för detta examensarbete var det okänt för Scania om dessa parametrar förekom under en betatestning. Men även i vilken utsträckningen som användandet av produkten i test motsvarade det verkliga användandet av produkten.

Syftet med detta arbete är att med hjälp av användardata validera valet av parametrar. Ytterligare mål var att undersöka ifall användandet av mjukvaran under betatest skiljer sig ifrån det

vardagliga användandet av SDP3. Ifall brister i valet av parametrar eller avvikande beteende kunde påvisas skulle förbättringsförslag lämnas.

Slutsatsen av denna studie var att utifrån den nuvarande teststrukturen är det svårt att avgöra kvaliteten på ett fälttest och framförallt på mjukvaran. Fälttesten bör fortsätta att analyseras och nya tydliga mål för att kvalitetssäkra mjukvaran behöver formuleras.

(5)

(6)

Bachelor of Science Thesis TMT 2017:39

Validation of test parameters

Approved

{2017-06-21}

Examiner KTH

Alexander Engström

Supervisor KTH

Håkan Carlqvust

Commissioner

Scania CV AB

Contact person at company

Max af Klintberg

Abstract

There is a constant increase in the usage of software in our everyday life. One of the effects of this is that the requirements that the users have on reliability and performance is also increasing.

Ultimately this have led to an increasing effort from corporations to test software to guarantee high quality software products. Scanias goal is to release products of the utmost quality whether it is hardware or software. Besides vehicles Scania produces tools for the aftermarket, one of these tools is Scania Diagnose and Programmer 3 (SDP3). SDP3 is a software used by mechanics and technicians to program and diagnose control units on Scania vehicles.

Earlier work on the group YSPV (Quality, integration, test) has produced a test structure composed of parameters that SDP3 should be tested against during beta testing. The aim is for this structure to act as a static template for measurements of software quality. Previously the group has been unaware of the degree of fulfilment that the beta testing today has with respect to the current structure. Another unknown factor is how well the use of the software during beta testing reflects the actual use of the software.

The goal for this study is to validate the selection of parameters based on user data. But also, to see if the use of SDP3 during testing differs from every day use of the product. If a difference in usage or if shortcomings in the selection of parameters can be demonstrated then suggestions on how to alter the structure should be produced.

The conclusion from this study was that assessing the quality of field tests and software based on the results of the current test structure is difficult. Field tests should undergo further analysis and new clear goals on how to ensure software quality needs to be produced.

(7)

(8)

Förklaring och definitioner

I rapporten används vissa ord något för generöst medan andra ord används utan att ha definierats tidigare. För att undvika otydligheter förklaras här ord på förhand.

Fälttestomgång – Det sista fälttestet i varje sprint ur respektive kvot där SDP3 innehåller översättningar på samtliga språk.

Testpopulation – Den sammansatta datamängden av de fyra utvalda fälttestomgångarna.

Reellpopulation – Datamängd från motsvarande tidsperiod som för testpopulationen fast med användardata från den mjukvara som släppts till kund.

Mjukvara – Genomgående i rapporten används mjukvara något generaliserande. I samtliga fall syftas till SDP3 förutom i kapitel 4. I kapitel 4 kan mjukvara användas för att beskriva dataprogram

överlag.

(9)

Innehåll

1. Inledning ... 1

1.1 Bakgrund ... 1

1.2 Bakgrund till undersökningen ... 1

1.2.1 Hur går ett fälttest till ... 3

1.3 Syfte ... 3

1.4 Problemdefinition ... 3

1.4.1 Begränsningar ... 4

1.5 Mål ... 4

1.6 Avgränsningar ... 4

1.7 Metod ... 5

2 Statistiskteori och tillämpning ... 7

2.1 Typ av undersökning ... 7

2.2 Urval... 8

2.3 Datanivå och variabeltyper ... 9

2.4 Grafiskframställning ... 10

2.5 Frekvenstabeller och Diagram ... 10

2.6 Binomial-test ... 11

2.7 Felkällor ... 12

2.7.1 Urvalsfel ... 12

2.7.2 Icke-urvalsfel ... 12

2.7.3 Det totala felet ... 13

3 Datainsamling ... 15

3.1 Mjukvaran i fokus: Scania Diagnos and Programmer 3 (SDP3) ... 16

3.2 Skapande av data ... 17

3.3 Datakällor ... 18

3.4 Gränssnitt: Splunk ... 19

3.5 Gränssnitt: Scania Product Individual Information (SPII)... 21

3.6 Verktyg: Python ... 22

4 Testning av mjukvara ... 23

4.1 Målet med testning ... 23

4.2 Kostnad och kvalitet ... 24

4.3 Varför innehåller mjukvara fel ... 24

4.4 Utveckling enligt Scrum modell ... 25

4.5 Typer av test ... 26

(10)

4.6 Regressionstest ... 26

4.7 Fälttestets plats i de olika testfaserna ... 27

4.8 Kvalitetsaspekter hos mjukvara ... 27

5 Genomförande ... 29

5.1 Arbetsprocess ... 29

5.2 Redovisande parametrar ... 30

5.3 Kvalitetsgenomgång av fälttest ... 30

5.4 Jämförelse av Populationer ... 31

6 Resultat ... 33

6.1 Kvalitetsgenomgång Fälttest ... 33

6.2 Jämförelse av Populationer ... 34

6.2.1 ECU-Uppdatering ... 34

6.2.2 Reservdelsprogrammering ... 38

6.2.3 Guider ... 42

6.2.4 Konfigurationer... 44

6.3 Binomialtestning av signifikans ... 47

6.3.1 ECU-uppdatering ... 47

6.3.2 Reservdelsprogrammering ... 49

6.3.3 Guider ... 51

6.3.4 Konfigurationer... 52

7 Analys ... 53

7.1 Resultat av Fälttest ... 53

7.2 Utfall av jämförelse ... 53

7.3 Korrigering av parameterval ... 54

7.4 Vad säger parametrarna om kvalitén på fälttestet? ... 54

7.4.1 Teststrukturen i verifierande syfte ... 55

7.4.2 Teststrukturen i testande syfte ... 55

7.4.3 Teststrukturen i syfte att öka konfigurationspoolen ... 55

7.5 Vad säger parametrarna om kvalitén på mjukvaran? ... 56

7.6 De tre testprofilerna ... 56

7.6.1 Verifierandeprofil ... 57

7.6.2 Testandeprofil ... 57

7.6.3 Kundnöjdhetsprofil ... 58

7.7 Vidareutveckling av teststrukturen ... 59

7.7.1 Fälttestet 2018 ... 59

(11)

7.8 Felkällornas påverkan på resultatet ... 60

8 Slutsats ... 61

Källförteckning ... 63

Appendix A ... 64

Appendix B ... 68

(12)

1

1. Inledning

1.1 Bakgrund

Scania är en svensk fordonstillverkare som bildades 1891 och som främst tillverkar lastbilar och bussar. Idag verkar Scania globalt och har ca 45 000 anställda runt om i världen med försäljning och service i över 100 länder. Företaget har sitt huvudkontor i Södertälje, vilket även är orten där detta examenarbete utförts.¹ I samspel med utvecklingen av Scanias fordon och motorer utvecklas även servicemarknadsverktyg som används för att bistå mekaniker och servicetekniker i sitt arbete. Detta examensarbete kommer behandla SDP3, en av de mjukvaror som används av servicemarknaden. I utvecklingen av denna mjukvara genomförs betatestning i kvalitetssäkringssyfte. När en ny

mjukvaruversion genomgått de första testfallen på Scania skickas den ut på fälttest hos utvalda verkstäder.

För att kunna kvalitetssäkra SDP3 är det viktigt att förstå hur mjukvaran används, vilka behov som finns och att de uppfylls. För att kunna uppfylla detta samlas data om hur produkterna används in över tid i form av loggfiler. Loggfilsdata används också i syfte att lokalisera fel eller

funktionsavvikelser som en användare eller utvecklare stöter på. Denna rapport kommer att innehålla en statistisk analys av de loggfiler som genereras under användning av programvaran.

För att garantera att mjukvaran är välfungerande innan den släpps till kund behöver Scania veta att ny funktionalitet har testats på vanligt förekommande lastbilsutföranden. Ett tidigare examensarbete som utförts på Scania har tagit fram parametrar som bör ha testats för att en testomgång ska anses vara godkänd. Dessa parametrar har delats in i tre kategorier, användartäckning, funktionstäckning och konfigurationstäckning (se Appendix A). Scania vill nu veta ifall dessa parametrar är något som testas i den nuvarande formen av fälttest eller ifall de egna testen bör justeras. Men även hur

representativa dessa parametrar är för den reella populationen av användande både med avseende på lastbilskonfiguration och på mjukvaruanvändning.

Resultatet av detta arbete kan ses både som en kvalitetskontroll av testningen som den ser ut idag men är också som ett underlag som säkerställer korrektheten i de valda parametrarna. De som är bekanta med statistik och statistiskanalys vet att det går att styrka i princip vilken tes som helst genom att justera urval och antaganden. Därför har extra ansträngning gjorts för att grunda urval och antaganden i teori, både i syfte att öka transparens men främst för att påvisa korrektheten i resultatet.

1.2 Bakgrund till undersökningen

Beställare av examensarbetet är gruppen YSPV – Kvalitet, integration och test. Gruppen ligger under marknadsområdet eftermarknad och produkten som levereras är bland annat en mjukvara för diagnostisering och programmering av lastbilar och mjukvara(SDP3). En del av den agila

utvecklingsmetodiken är fälttest där utvalda verkstäder får möjlighet att testa den mjukvaruversion som fortfarande är i utvecklingsstadiet.

Ett tidigare arbete på gruppen har framtagit en täckningsstruktur som ska ses som ett underlag för att bestämma kvalitén på ett fälttest. Denna struktur har delats in i tre huvudområden som är

1 https://www.scania.com/se/sv/home/experience-scania/about-us.html

(13)

2 användartäckning, funktionstäckning och konfigurationstäckning med syfte att ge en fullskalig bild av mjukvaransanvändning inom rimliga ramar. Se figur 1 som är en förenkling av den nuvarande strukturen. Men även Appendix A som innehållet hela strukturen.

Mjukvarans komplexitet och storlek gör att det inte är möjligt att få en täckning av hela programmet.

Dessutom styr inte Scania över hur mjukvaran används av kunder eller vilka typer av fordon som kommer in till verkstäderna ett så kallat slumpmässigt flöde, vilket göra det omöjligt att uppnå någon form av totaltäckning under en fälttestomgång. Därför måste grovhuggna avgränsningar göras för att kunna kvalitetsstämpla en fälttestomgång på en rimlig nivå. Avgränsningarna som gjorts inom de tre huvudområdena har skapat teststrukturen som den ser ut i dagsläget. Med intervjuer som grund har populära och applikationskritiska funktioner valts ut som underlag för kvalitet.

Frågan som gruppen vill få besvarad är nu ifall denna struktur är lämplig för att kvalitetssäkra en fälttestomgång. Informationsunderlaget för undersökningen är de loggfiler som användandet av mjukvaran genererar. Loggfilerna existerar på Scanias server under ett års tid vilket begränsar undersökningen till de fyra senaste versionerna av mjukvaran och de tillhörande fälttesten.

Intressant är också att kontrollera användandet av mjukvaran utifrån dessa parametrar. Används SDP3 i dess betatestsversion på samma sätt som den version som ligger ute hos kund eller väljer

Figur 1 - Teststrukturen med dess tre huvudkategorier, under huvudkategorierna finns sub-kategorier. Det finns totalt tre nivåer som är utförligt beskrivna i appendix.

(14)

3 fälttestverkstäderna att använda SDP3 på ett avvikande sätt när de känner till att det är en

mjukvaruversion under testning som dem använder. En annan orsak till avvikande beteende skulle kunna vara att fälttestverkstäderna som valts ut har en specifik profil eller är geografiskt belägna så att vissa konfigurationer av lastbilar inte besöker verkstäderna med samma frekvens som i resten av världen. Är beteendet avvikande är det önskvärt att rikta sig till andra eller fler verkstäder för att hitta ett användande som mer efterliknar det verkliga användandet.

1.2.1 Hur går ett fälttest till

Utvecklingen av SDP3 sker i sprintar enligt den agila utvecklingsmetodiken. En sprint är en förutbestämd tidsperiod där projektledaren och produktägare bestämmer vilket arbete som ska utföras under sprinten. Det finns alltså en klar deadline med färdiga mål att arbeta mot.

Utvecklingen av en ny version av SDP3 består av 4-6 sprintar beroende på hur omfattande

ändringarna i mjukvaran är. SDP3 ges ut på 18 olika språk som lyfts in allt eftersom översättningarna blir klara mellan sprintarna, den sista sprinten ska då innehålla samtliga språk.

Varje sprint har en sprinttestfas som gruppen YSPV ansvarar för. I slutet av varje sprinttest sker fälttesterna som i antal också blir fyra till sex stycken för varje version. Fälttesten har vissa krav som måste uppfyllas innan mjukvaran kan skickas ut. Följande måste godkänts innan fälttest:

 Säkerhetskritiska tester

 Riktade tester

 Affärskritiska tester

Ett fälttest pågår i ungefär 10 dagar där antalet deltagande verkstäder ökar i och med att antalet språk som lyfts in i programmet ökar. Det finns idag (juni 2017) totalt 16 stycken verkstäder som deltar i fälttestningen av SDP3. Utskicken av testmjukvaran består av mjukvaran, en lista över fixar, ny funktionalitet och eventuellt särskilda instruktioner från testledaren om vilken funktionalitet som gruppen är särskilt intresserad av att den testas. Mejl och felrapporter är den återkoppling som kommer från verkstäderna.

1.3 Syfte

Syftet med detta arbete är att validera valet av parametrar genom att undersöka användandet av SDP3 i testmiljö och ute hos kund.

1.4 Problemdefinition

Kvalitetssäkring av mjukvara är den grundproblematik som gjort att både detta och tidigare

examensarbete utförts på gruppen YSPV. Tidigare arbete har konkretiserat vilka parametrar som bör testas för att säkerställa en fullgod testning. Naturliga följdfrågor blir då, testas dessa parametrar i dagsläget? Skiljer sig användandet av mjukvaran mellan fälttestverkstäder och de verkstäder som använder den släppta versionen av mjukvaran?

När en mjukvaruversion släpps på fälttest följer Scania generellt inte hur mjukvaran används utan förlitar sig på de felrapporter som skickas in. Utifrån loggdata går det att uttala sig både om det funktionella användandet av mjukvaran men också om det kvantitativa användandet (ex. antal unika fordon, antal användare). För att försäkra sig om att en ny version av produkten SDP3 är stabil när den släpps till kund behöver stora delar av programmet testas både internt, men också ute hos kund.

Dessutom behöver programmet testas mot flera olika utförande av lastbilar då konfigurationer påverkar hur mjukvaran beter sig. Med loggdata och en korrekt teststruktur som grund kan

(15)

4 kvantitativa krav ställas på de fälttestverkstäder som gruppen använder sig av i dagsläget.

Kvantitativa krav bör leda till en effektivare testningsprocess av högre kvalité.

Sammanfattning av problemdefinitionen:

 Hur stor del av parametrarna testas under en fälttestomgång idag?

 Är förekomsten av parametrar representativa för det verkliga användandet av mjukvaran?

 Om de inte är representativa på vilket sätt bör de justeras?

 Vilka kvantitativa krav kan ställa på fälttestverkstäderna?

1.4.1 Begränsningar

Tidigt i analysprocessen har vissa begränsande faktorer identifierats som försvårar arbetet och som i slutändan påverkar resultatet. Begränsningar lyfts fram i denna del av rapporten i syfte att förklara varför ett tillsynes rättframt problem kan försvåras av dess kontext.

 Utformningen av loggfilen är inte anpassad för beskrivande dataanalys

 Loggfilerna saknar information om hårdvarukonfiguration hos lastbilen

 Databasen för kontroll av hårdvarukonfiguration saknar funktionalitet för bulksökningar

 Valet av en stor del av parametrarna saknar dokumentation

 Loggfilernas utformning och innehåll saknar dokumentation

 Kunskapen om Splunk på avdelningen är centraliserad

1.5 Mål

 Utifrån de tre testkategorierna kontrollera att varje parameter har testats åtminstone en gång under de senaste fälttestomgångarna.

 Jämföra parametrarnas förekomst i test- och reell population. Jämförelsen görs numeriskt och presenteras grafiskt i form av parvisa stapeldiagram.

 Ge ett förslag på korrigering av parametrar då användandet inte är representativt eller då förekomsten av en parameter uteblir.

 Efter jämförelse ge ett förslag på kvantitativa krav på test verkstäderna. Med avseende på antal användare, unika fordon och antal loggfiler.

1.6 Avgränsningar

 Testpopulationen avgränsas i tid till 2016-03-01 – 2017-02-28

 Testpopulationen avgränsas till mjukvaruversionerna som ingått i fälttest under tidsavgränsningen för studien.

 Testpopulationen avgränsas till de mjukvaruversionen som tillhör typen ”All-language”

 Reellpopulation avgränsas i tid till 2016-03-01 – 2017-02-28

 Reellpopulation avgränsas till mjukvaruversionerna som ingått i fälttest under tidsavgränsningen för studien.

 Endast loggfiler av typen Tool-log kommer att analyseras.

 Analysen kommer att göras på SDP3:s grundutförande och inte på tilläggsprogrammen BICT eller SMCT.

 Analysen förutsätter att allt användande av SDP3 har gjorts på ett korrekt sätt.

 Parametrarna som analyseras är de som presenterats i tidigare rapport.

(16)

5

1.7 Metod

Metodavsnittet används för att redogöra och motivera det praktiska tillvägagångssättet som använts i genomförandet av detta examensarbete. Metodiken som använts i denna uppsats för att samla in data och sedan lösa problemet kan delas in i tre delar:

1. Litteraturstudier

Projektet har haft begränsat med resurser därför är det en sund metod att använda sig av litteraturstudier när tiden för studien är relativt kort och den görs utan ekonomiska resurser.

Dessutom är litteraturstudier en intelligent metod att använda sig av för att bygga en teoretisk referensram inom området som ska undersökas.² Litteraturstudier har framförallt använts genom att hitta matematiska teorier inom statistik samt teori inom datalogi för att sedan kunna applicera teorin på problemet.

2. Intervju

Intervjuer används för att hämta information som är direkt relaterad med studiens syfte. Det är även en metod som ger en djupare förståelse inom ämnet. Genom att anpassa frågorna kan

intervjuobjektets kompetens tas tillvara.³ Intervjumetoden har valts i de tillfällen då kunskap om problemet saknats och expertis behövts för att få den nödvändiga informationen att driva studien vidare.

3. Dataanalys

Det är oftast studiens syfte som avgör om den är kvalitativ eller kvantitativ⁴. Då ett av problemen varit att en stor mängd data behövt behandlas för att få fram ett resultat har en kvantitativ metod använts. Möjligheten till generaliseringen är högre med hjälp av kvantitativa studier vilket har varit en förutsättning i detta fall. En kvantitativ analys används för att det möjliggör mätning eller värdera information numeriskt. Numerisk mätning brukar vara vanligast vid analyser som innehåller

matematiska modeller.⁵ För denna rapport har dataanalys varit en viktig del av insamlandet av information, eftersom den enda tillförlitliga källan till hur SDP3 används finns i form av loggfiler som analyserats i datahanteringsverktyget Splunk.

2 Björklund & Paulsson, Seminarieboken: Att skriva, presentera och opponera, 69-70

3 Ibid, 68- 70

4 Ibid, 70

5 Ibid, 69-70

(17)

6

(18)

7

2 Statistiskteori och tillämpning

Statistiska undersökningar görs ofta enligt vedertagna metoder och tillvägagångssätt⁶. Syftet med denna del av rapporten är dels att ge en övergripande bild över dessa metoder men främst att förklara vilka metoder som valts ut och hur dessa har tillämpats på problemställningen.

2.1 Typ av undersökning

Anledningen till att en statistiskundersökning utförs är att ge information om en mängd individer eller element. Dessa individer/element säger vi då ingår i en population. När man talar om populationer så talar man antingen om ändliga populationer eller oändliga populationer där de ändliga är en fysiskexisterande population och de oändliga är en experimentellpopulation.⁷ Problemdefinitionen är det som avgör vilken typ av undersökning som är lämplig att göra. Det kräver en förståelse för problemet och dess kontext men även att man har klart för sig vem, vad och hur undersökningen ska genomföras. De olika typer av undersökningar som kan genomföras är:

 Beskrivande/Deskriptiva

 Förklarande/Utredande/Hypotesprövande

 Framåtblickande/Prognoser

Ser man till de typer av frågeställningar som är bäst lämpade till en viss frågeställning enligt Dahmström så ges denna lista.

Frågeställning Statistisk undersökning

Beskrivande/deskriptiv: Kartlägga någon

förteelse Icke-experimentell undersökning, undersökning

av surveytyp Förklarande: Kartlägga samband, testa

hypoteser Experiment, kvasi-experimentell undersökning

Göra förutsägelser om framtiden Prognoser

Figur 2 - Typer av frågeställningar och tillhörande passande undersökningsmodeller. Källa: Från datainsamling till rapport (2005), s.23

Problemdefinitionen behöver alltså vara tydlig med vilket resultat som man vill erhålla. Är det ett beteende som ska kartläggas, ett samband som ska undersökas eller vill man kunna förutspå ett beteende.

Ser man till de deskriptiva undersökningarna som också är den typ av undersökning som denna rapport tillhör så finns där två subtyper. Totalundersökning är en variant där samtliga individer i en population ingår i undersökningen. Ifall endast delar av populationen har studerats är det ett

stickprov eller urvalsundersökning som gjorts. Det är i de flesta fall en kostnadsfråga vilken av dessa två typer man väljer att göra. Optimalt är att göra en totalundersökning men det är i de flesta fall inte möjligt då kostnaden i tid och resurser blir för stor. Fördelar man ser med att göra en

urvalsundersökning är bland annat reducerade kostnader, snabbare utförande och i viss mån större tillförlitlighet.⁸

6 Dahmström, Från datainsamling till rapport, 16

7 Körner mfl, Deskriptiv statistik, 23

8 Ibid, 23

(19)

8

2.2 Urval

Kunskapen och förståelsen för hur testversions-populationen och releaseversions-populationen verkar i förhållande till varandra saknas hos Scania. För att analysera dessa populationer har stickprov ur respektive population gjorts eftersom det på grund av bl.a. tid, datamängd och andra begränsningar inte är möjligt att genomföra undersökningen på hela populationerna. Med hänsyn till detta är det rimligt att göra ett urval och låta det representera respektive population utifrån befogade antaganden och motiveringar⁹. En tumregel är att ju större urvalet är, desto större är sannolikheten att den ska vara representativ för den populationen den representerar¹⁰.

Stickprovet har plockats ut med hjälp av ett kvoturval. Detta är en urvalsmetod som används när urvalet görs utifrån egenskaper som tros finnas hos populationen, det är inte ett slumpmässigt urval där alla individer har samma möjlighet att bli vald.¹¹ Först delas populationen in i ett antal kategorier, t ex besökare under en viss årstid, för att stickprovet ska spegla populationen vad gäller fördelningen av de olika kategorierna¹². Dessa kategorier kallas för kvoter. Med avseende på dessa kvoter

genomförs sedan ett bekvämlighetsurval, det vill säga, testpersonen väljer sedan en andel ur varje kvot för att skapa ett representativt stickprov för populationen Anledningen till att ett kvoturval och inte en slumpmässigt vald metod användes var att fälttesten i sig inte är homogena i sina faser, då den relevanta jämförelsen kan bli avsevärt mindre utifrån ett slumpmässigt urval. Det är dock betydelsefullt att poängtera att det inte går att veta i förväg om urvalet blir representativt i alla avseenden med hjälp av kvoturval¹³.

Tillvägagångssättet som valts för att få urvalet så representativt som möjligt är utifrån antagande att det inte är samma utförande lastbilar eller att samma funktioner som används året om. Utan det är mer troligt att olika sorters lastbilar besöker verkstäder och testar olika funktioner av mjukvaran under olika perioder av året. Det blir då viktigt att stickproven representerar alla årstider för att inte missa viktiga beteenden av mjukvaran. Populationen begränsades till de lastbilar som besökt en verkstad någon gång under perioden 160401–170228. Detta val gjordes utifrån antagandet om att lastbilsbesöken ser likadana ut varje år under samma period. D.v.s., lastbilar med samma

konfiguration besöker och använder samma funktioner i mars 2017 som i mars 2016 för att ta ett exempel. En annan aspekt som var betydande var att data som SDP3 genererar sparas på Scanias servrar i ett års tid, det vill säga, vid start av detta examensarbete var det inte möjligt att få tillgång till data från tidigare än 160301. Därefter bestämdes att fyra stycken kvoter skulle användas och varje kvot delades in i en period av tre månader, på så vis täcktes årets alla säsonger av. Utifrån dessa kvoter valdes sedan en månad ur varje kvot och alla loggfiler i denna månad ingick i stickprovet.

Denna process genomfördes på samma sätt för både testpopulationen och reellapopulationen. De månader som valdes ur varje kvot var de månader där testversionerna av SDP3 hade kommit längst i sin mognadsfas, de hade t ex ”all-language”-funktion där alla översättningar för SDP3 finns med.

Detta på grund av att målet var att testversion och releaseversion skulle vara så homogenasom möjligt vid jämförelsen och att sannolikheten för produktskillnader skulle vara minimal. Värt att poängtera är att samma månader valdes ut både för testpopulation och för reellpopulation för att få en så pass överlappande bild som möjligt av populationerna.

11 SCB, Urval – från teori till praktik, 90

12 Ibid, 90

13 Ibid, 91

(20)

9

2.3 Datanivå och variabeltyper

De egenskaper hos en individ som studeras i en undersökning kallas variabel. Definitionen av en variabel är enligt Dahmström:

Variabel – En egenskap som kan variera mellan olika element i populationen¹⁴

Resultatet av en undersökning är oftast information i form av frekvensen av en variabel i ett visst antal observationer, variation i olika populationer med avseende på en viss variabel eller en

kartläggning av variabler¹⁵. Resultatet av en undersökning och hur resultatet presenteras beror främst av problemställningen, men begränsas också till vilken typ av variabel som undersöks. Här finns två huvudtyper kvantitativa (numeriska) och kvalitativa (icke-numeriska) variabler. De kvalitativa variablerna är exempelvis av typen kön, partitillhörighet, civilstånd medan de kvantitativa kan vara vikt, längd, inkomst osv. Ser man till de kvantitativa variablerna så skiljer man även på diskreta och kontinuerliga variabler (jämför längd och antal barn)¹⁶. En vanlig illustration av variabel typer är figur 2.2

Figur 3 – Hierarkisk bild över vilka variabelfamiljer som finns och hur de hör samman. Källa: Deksriptiv statistisk (1992) s.17

Förutom att dela in variablerna efter kvalitativa och kvantitativa så kan de delas in i olika grader av information som de olika variabelvärdena innehåller. Informationen kopplat till variablerna kan klassas in i fyra olika nivåer, så kallade datanivåer. Dessa är.¹⁷

 Nominalskala

 Ordinalskala

 Intervallskala

 Kvotskala

De olika nivåer styr vilka typer av beräkningar och undersökningar som kan utföras med en datamängd av ett givet slag. På den lägsta nivån nominalskala kan individer efter mätningen endast delas in i grupper t ex partitillhörighet, kön. Det går att beräkna frekvensen för varje värde men alla former av storleksjämförelser mellan individernas variabelvärden är meningslösa.¹⁸

Samtliga variabler i undersökningen som denna rapport bygger på är kvalitativa variabler i nominalskala, exempelvis typ av styrenhet för motorstyrning (S6, S8, EMD1). Känt är att en styrenhet av modellen S8 är en senare modell än en av typen S6 men det finns inget inbördes mått på att det är en dubbelt så bra modell eller att de presterar på olika nivå, därför blir jämförelser dessa emellan också meningslösa. Det går att koda nominalskalevariabler för att öka datanivån och som i

14 Dahmström, Från datainsamling till rapport, 24.

16 Ibid, 17

(21)

10 sin tur möjliggör mer avancerade uträkningar. Målet med rapporten är att kartlägga ett beteende vilket gör att en kodning inte tillför något mervärde till resultatet. För att generera önskat resultat räcker det alltså med de möjligheter till beräkningar som en nominalskalevariabel ger.

2.4 Grafiskframställning

När resultatet av en undersökning ska presenteras är diagram och tabeller ett effektivt sätt att skapa en överblick av resultatet. Det finns en mängd olika sätt att presentera frekvensfördelningar för en variabel där olika diagram passar olika väl för att ge en korrekt och informativ bild av fördelningen.

Några avgörande faktorer sorterar sedan bort mindre lämpliga diagramtyper. Primärfaktorn är typen av variabel som man arbetar med där det finns olika typer av diagram för ordinalskale variabler där jämförelser grupperna emellan kan göras, för tidsserier och för nominalskalevariabler.¹⁹

Som tidigare nämnts i kapitel 2.3 görs denna undersökning endast på nominalskalevariabler utan någon form av kodning. Detta leder till att gruppindelningen endast är en benämning och inte ett numeriskt värde. Det i sin tur leder till att visualiseringen begränsas till olika former stapeldiagram eller cirkeldiagram. När vi sedan har två populationer som ska jämföras faller det sig naturligt att använda parvisa stapeldiagram för att påvisa representation. Där förekomsten av t ex styrenheter för motor representeras med två staplar där den ena stapeln står för frekvens i testpopulation och den andra för frekvens i reellpopulation. Undersökningen vill påvisa hur representativt användandet av mjukvaran i testpopulationen är jämtemot användandet av mjukvaran i den reellapopulationen.

Därav har också representationsgränser visualiserats i de bägge staplarna för att åskådliggöra osäkerheter i urvalet.

Det verktyg som använts för att visualisera resultatet av beräkningarna är Python biblioteket matplotlib och dess stapeldiagrams funktionalitet.

2.5 Frekvenstabeller och Diagram

En frekvenstabell visar hur många gånger varje alternativ förekommer i undersökningen²⁰. Om det framtagna datamaterialet är stort och således även antalet observationer brukar man framställa data med hjälp av en frekvenstabell²¹. Dessa tabeller används sedan som underlag för att ta fram den relativa frekvensen. Den relativa frekvensen anger hur stor andel av det totala som varje alternativ har och på så sätt fördelningen av de alternativ som finns.²²

Den relativa frekvensen anges i procent och det är inget annat än hundradelar, vanligtvis används procenttecknet, %. ²³De procentuella siffror som presenteras har räknats ut med hjälp av klassisk procent-beräkning inom matematiken, dessa andelar ges av:

𝑎𝑛𝑑𝑒𝑙𝑒𝑛 = delen det ℎ𝑒𝑙𝑎

Att använda sig av relativ frekvens och frekvensdiagram har sina fördelar, bl a, att det går att jämföra storleken på en viss företeelse med samma företeelse i en annan population även om storlekarna varierar. Dessutom är det enklare och lättare att analysera stora mängder data med hjälp av denna

21 Jonsson & Norell, Ett stycke statistik, 105

23 Ibid, 32

(22)

11 redovisningsform.²⁴ Om undersökningen, som i detta fall, består av kvalitativa variabler är

frekvenstabeller och frekvensdiagram den vanligaste formen att presentera resultatet i²⁵. Det är då möjligt att redovisa data med hjälp av frekvensdiagram som visualiseras likt grupperade stapeldiagram²⁶.

2.6 Binomial-test

Binomial-test är ett sannolikhetstest som används då man vill jämföra två binomiala

proportioner med hjälp av hypotesprövning²⁷. Antag att det finns två stycken stickprov med olika antal observationer, 𝑛₁ och 𝑛₂. 𝑝₁ och 𝑝₂ utgör populationsproportion av lyckade utfall för stickprov ett respektive stickprov två. Det man vill är att jämföra 𝑝₁ med 𝑝₂ om det finns någon statistisk signifikans mellan dessa två uppmätta värden. Med statistisk signifikans innebär att det är statistiskt säkerställt att ett observerat värde avviker från ett hypotetiskt eller annat jämförelsevärde i så pass stor utsträckning att det inte endast kan bero på slumpen. Detta test genomförs med hjälp av en hypotesprövning där nollhypotesen säger att det inte finns någon statistisk differens mellan 𝑝₁ och 𝑝₂ medan den alternativa hypotesen säger att det finns en skillnad:

𝐻₀=0 𝐻₁≠0

När ett parametervärde inom statistiskteori uppskattas brukar det benämnas som punktskattning.

Eftersom de data som observeras varierar mellan olika tillfällen kommer även punktskattningens värde att variera och avvika från parameterns exakta värde, därför kan det vara relevant att ta fram punktskattningens standardavvikelse.²⁸ Om p är okänt brukar det skattas med hjälp av ^𝑥_𝑛, vi betecknar det då 𝑝̂ .²⁹

Antag att vi har en stor observation n, då säger centrala gränsvärdessatsen att 𝑝̂ är normalfördelad med väntevärdet ^𝑥_𝑛 och att dess standardavvikelse σ ges av √

𝑥 𝑛(1−_𝑛^𝑥)

𝑛 .³⁰

Med hjälp av ett 95 % -konfidensintervall beräknas differensen mellan 𝑝̂₁ och 𝑝̂₂ enligt följande:

25 Ibid, 105

27 http://www.statisticssolutions.com/binomial-test-of-significance/

29 Ibid, 117

30 Ibid, 125

𝑝̂₂-𝑝̂₁ ± 𝜆_0,025√𝜎₁²+ 𝜎₂²

(23)

12

2.7 Felkällor

Dahmström skriver att det ibland finns en övertro bland människor i allmänhet att ju mer exakta tal det finns i tabeller och rapporter, desto mer går det att lita på dessa, att sanningen kommer närmare med dessa tal. Det som inte tas i åtanke då är att den sanning som tagits fram i själva verket döljs av olika fel som vederbörande inte vet varken storlek eller riktning på.³¹De främsta typerna av fel som kan uppkomma kommer att studeras här och även vad som kan orsaka dessa.

2.7.1 Urvalsfel

Om en urvalsundersökning görs istället för en totalundersökning för att skatta en eller ett antal parametrar ur en population finns det att välja på att göra ett slumpmässigt eller icke-slumpmässigt urval³². Om som i detta fall, en icke-slumpmässig urvalsmetod använts finns risk att det blir ett övertäckningsfel, det betyder att individer som inte tillhör populationen ingår i urvalsramen och har då använts i resultatet trots att den inte tillhör den korrekta populationen vilket kan ge missvisande resultat³³.

2.7.2 Icke-urvalsfel

En typ av fel som kan uppkomma vid undersökningar är täckningsfel. det finns två typer av täckningsfel som kan uppkomma, nämligen undertäckning och övertäckning. Undertäckning innebär att det finns objekt i den undersökta populationen som inte har någon möjlighet att komma med i urvalet. Övertäckning innebär det motsatta, dvs., att det finns objekt i stickprovet som inte tillhör den sökta målpopulationen som har möjlighet att komma med.³⁴ Under denna analys finns risk att bägge dessa fall kan ha förekommit, eftersom urvalet av testpopulationen begränsats till den delen med endast den mest utvecklade mjukvaran så har fordon under tidigare del av testperioden inte haft en möjlighet att komma med i urvalet, det fick dock inga belägg för att garantera att ett sådant fordon ska ha uppkommit i stickprovet.

Den typ av icke-urvalsfel som oftast redovisas och som är lättast att studera är bortfallsfel. Det vill säga, ett element som tillhör den population som ska undersökas, men som inte angett något svar eller motsvarande i undersökningen. Vid bortfallsfel så är det framförallt två typer som ofta uppkommer, individbortfall(objektbortfall) och partiellt bortfall(variabelbortfall). I det första fallet fås t ex inga svar från objektet vid t ex en enkät, medan partiellt bortfall innebär att objektet lämnar vissa frågor tomma, men svarar på en del av enkäten.³⁵ I denna undersökning är det framförallt partiellt bortfall som sannolikt varit ett problem. En lastbil som besöker en verkstad, men inte testar alla funktioner(variabler) eller har någon av de intressanta konfigurationerna(variabler).

Ytterligare en typ av fel som kan uppkomma vid undersökningar som liknar denna är mätfel. En önskvärd egenskap hos mätningar är att mätprocessen har hög validitet, dvs., det man vill mäta är det som mäts. Mätmetoden kan därmed ge upphov till fel, om någonting i frågesituationen är oklart kan det vara svårt att veta både storleken och riktningen på det fel som uppstått. Målet ska vara att konstruera frågor som mäter det som är avsett att mätas och att inte någonting som inte tillhör undersökningens syfte.³⁶ För denna undersökning kan mätfel ha uppstått vid t ex intervjutillfällen

32 Ibid, 318

34 Dahmström, Från datainsamling till rapport, 319-320

35 Ibid, 321

36 Ibid, 334-335

(24)

13 eller vid Splunk-förfrågningar då data som inte efterfrågas uppkommer som en del av resultatet.

Eller att data exkluderas då förfrågningarna till databasen inte varit korrektställda.

Om stora mängder data ska bearbetas finns det risk för en annan typ av fel, nämligen bearbetningsfel. Specifika fel som kan uppstå vid bearbetning sker oftast vid kodning eller datorbearbetningen. Det fel som kan uppkomma vid kodningsmomentet är framför allt valet av koder som kräver kunskap och kontroll av denna del av bearbetningen. Med fel av

databearbetningen menas själva bearbetningen med hjälp av något dataprogram, vare sig användningen endast sker med hjälp av ett standardprogram eller kompletteras med egen programmering måste användningen av de program som används vara testade under planeringsstadiet.³⁷

2.7.3 Det totala felet

Totala felet utgår från summan av de fel som tidigare presenterats. Det kan beskrivas med en enkel matematisk modell enligt nedan:

Totala felet = urvalsfel + bortfallsfel + täckningsfel + mätfel + bearbetningsfel

Dahmström skriver att de fyra sista felen förekomma både i total- och urvalsundersökningar, medan urvalsfel av naturliga skäl endast kan förekomma i urvalsundersökningar. Trots detta så kan ändå en urvalsundersökning ge ett lägre totalfel än en totalundersökning på grund av att bättre mätmetoder kan användas på en sådan. Målet med en undersökning, förutom att få ut ett relevant resultat, är att minimera det totala felet. Det totala felet kan ses som en summa av systematiska och slumpmässiga fel, där det med mycket systematiska fel kan vara svårt att göra en bedömning ifall felet är en över- eller underskattning. Detta leder till att det kan vara svårt att mäta och bedöma storleken av det totala felet.³⁸

37 Dahmström, Från datainsamling till rapport, 337-339

38 Ibid, 339-334

(25)

14

(26)

15

3 Datainsamling

Till skillnad från många andra beskrivandestudier behövde inte någon ny data skapas utan data behövde extraheras, kompletteras och bearbetas till ett lämpligt format för beräkning och

presentation. Skapande och indexering av data sker redan idag per automatik och denna studie har inte påverkat metodiken på något sätt. Datainsamlingen har bestått av databasförfrågningar genom främst två gränssnitt som kommunicerar med olika datakällor på Scania.

För att kunna redovisa ett korrekt resultat av en statistisk studie är det viktigt att förstå processen som generar data och sammanhanget som data är kopplat till. Bilden nedan illustrerar hur data som undersökts genereras, lagras, extraheras och bearbetas. I syfte att ge en förståelse för

datamängdernas sammanhang följer här en beskrivning av de olika delmomenten i informationsflödet.

Figur 4 – Figur framställd under studien. Figuren ska illustrera informationsflödet, frågeställningens kontext och även arbetsmetod.

(27)

16

3.1 Mjukvaran i fokus: Scania Diagnos and Programmer 3 (SDP3)

SDP3 är det diagnos- och programmeringsverktyg som används vid uppkoppling mot elektriska systemet på Scania-fordon. Ett diagnosverktyg är delvis en felkodsläsare som används för att läsa ur felkoderna ur fordonets styrenheter för att identifiera vilken del eller vilket system på fordonet det är som krånglar³⁹. Mjukvaran lanserades 2003 och används idag på ca 1600 verkstäder runt om i

världen, både på Scaniaverkstäder samt av icke-Scaniaverkstäder. Verktyget används framförallt av servicetekniker på verkstäder för olika felsökningar och diagnostik av elsystemet på Scanias fordon.

SDP3 har fem olika typer av jobbfördelningar och varje jobb typ består i sin tur av ett stort antal

guider. Guiderna handleder användaren i hur ett arbete på ett standardiserat sätt ska utföras enligt Scanias riktlinjer, exempelvis hur trycket i bränslepumpen justeras. Handledningen sker i form av grafisk och skriftlig information där jobbets förfarande gås igenom stegvis. SDP3 är inte enbart ett diagnostiseringsverktyg utan används också för att kalibrera och programmera om mjukvaran i fordonets styrenheter. Exempel på funktioner i SDP3 som justerar mjukvara är

reservdelsprogrammering, mjukvaruuppdatering och kalibrering(parametersättning).

Ett vanligt handhavande av mjukvaran kan bestå av:

 Utläsande av felkoder

 Felsöka berörda styrenheter

 Starta guide för byte av styrenhet

 Kalibrering av den nya styrenheten utefter fordonets förutsättningar

39 https://www.runns.se/felkodslasare/

Figur 5 – Bild över hur den programmet SDP3 ser ut. I denna session görs en utläsning av felkoder ur styrenheterna på lastbilen. Till höger presenteras typen av fel, sannolik orsak, kommentarer och vilka åtgärder som rekommenderas. Källa: Scania Diagnos and Programmer 3 User instructions s.16

(28)

17

3.2 Skapande av data

Det börjar med att något utförande av Scania fordon som på grund av planerat eller oplanerat underhåll kommer in till en Scaniaansluten verkstad. För att få en bild av fordonets tillstånd använder sig mekanikern av SDP3 mjukvaran.

Datorn där SDP3 är installerad kopplas upp emot lastbilens CAN-nät genom gränssnittet VCI (Vehicle Communication Interface). När SDP3 startas (förutsatt att datorn är kopplad mot internet) skickas loggfilerna från föregående session till en av Scanias servrar. Därefter skapas en grupp nya loggfiler

för den aktuella sessionen däribland SDP3Server, ApplicationLog, Usagelog och SDP3Tool.

Initialdata om användaren skrivs direkt i loggfilerna så som operativsystem, macadress, ipadress, versionsnummer och användarnamn.

När mekanikern sedan använder mjukvaran genereras loggrader för i princip varenda

knapptryckning, denna information sparas i applikationsloggen och i usage loggen. All data som skickas över CAN-nätet loggas i transportloggen. Mer generellinformation om användandet sparas i SDP3Tool som också är den loggfilstyp som analyserats i detta arbete.

Figur 7 Exempel på utförande av SDP3 tool log, ur bilden framgår att varje rad består av en tidsstämpel (datum, tidpunkt, tidszon), syftet med raden och sist den loggtext som genereats av SDP3.

Att Tool-loggen är den logg fil som varit mål för analys är för att den bokför användande och justeringar på en nivå som utifrån alternativen bäst lämpar sig för analys. Allt väsentligt

användande och korrigeringar går att följa i denna loggfil samtidigt som de är direkt läsbara för en människa. De gör att funktioner som textsökning och reguljära uttryck går att tillämpa för att sortera denna data. Ur bilden framgår det att data består av en tidsstämpel, en kategorisering (INFO eller DEBUG) och sist förklarande text kring vad som sker i mjukvaran.

Figur 6 - Grafik över koppling mellan fordon och persondator.

Källa Scania Diagnos and Programmer 3 User instructions s.5

(29)

18

3.3 Datakällor

Data har primärt hämtats ur två datakällor. Den första källan lagrar loggfilerna som genererats av användandet.

Denna källa är kopplad till sök och indexerings verktyget- Splunk vilket möjliggör bearbetning av stora datamängder, fortsättningsvis kallas denna databas för Splunk-databasen.

Ungefär 10 GB loggfilsdata indexeras och lagras på denna server dagligen.

Den andra datakällan SPII lagrar information om samtliga Scanias lastbilar. Nya data genereras när Scania producerat ett nytt fordon eller att ett fordon kalibrerats. Då lagras både generell information kring fordonet men också detaljerad information om fordonets exakta utförande.

Scania följer sedan upp ändringar som görs med fordonet och har oftast den senaste informationen kring fordonets utförande lagrad.

 Kategorisering av loggdata

Förutom den första kategoriseringen av data i själva loggfilen görs ytterligare kategorisering när loggfilerna skickats till Splunk-databasen. En del av Splunk enterprise är dess indexerare, dessa går igenom de data som skickas till servern i realtid och indexerar sedan data efter förutbestämda parametrar. En typiska sådana parametrar är tid eller ursprung. Efter indexering lagras data på servern tillsammans med dess indexeringsparametrarna i ”buckets” som är ett standardiserat

lagringsformat. Detta lagringsformat ger Splunks sökfunktionalitet information på förhand vilket ur en prestandasynpunkt underlättar sökningar i stora mängder data.

 Externa datakällor

För rapportens syfte är den största bristen i utförandet av loggfilerna att dem saknar information kring fordonets hårdvarukonfiguration. Fordonets hårdvaru- och mjukvarukonfigurations finns lagrat i en SOPS (Scania Onboard Product Specification)-fil vilket är en textfil i XML-format. En fullständig SOPS består av sex stycken olika block. De sex blocken är Kabellista, FPC-block, ECU- block, XPC-block, UF-block och versionsblock. Tillsammans bildar den en komplett bild av fordonet både till uppbyggnad av hårdvara men också till mjukvaruversion och till

parametersättning. SOPS-filerna finns lagrade i två av lastbilens styrenheter (koordinator och ICL), men är krypterade av sekretesskäl. SDP3 kan dekryptera SOPS:en men kommer aldrig att logga dess innehåll förutom ECU:ernas familjetyper. Den information som hade varit önskvärd att ha tillgång till är informationen som är lagrad i FPC-blocket som består av en samling FPC-koder. FPC- koderna är parvisdata med nummer (1-7691) och utförande (A-Z – AA-ZZ) ett exempel kan vara FPC2471 som är utsläppsnivå och ett utförande kan vara J som då innebär utsläppsnivå Euro 6.

Den information om lastbilskonfiguration som istället finns att tillgå är chassinummer eller VIN- nummer (Vehicle Identification number). VIN-numret består av 17 siffror och bokstäver som tillsammans ger information om ursprung, typ och årsmodell.

Figur 8 – Illustration av dataflödet från olika processer genom Splunk.

Källa: https://www.splunk.com/en_us/solutions/solution-areas/internet- of-things.html (2017-06-05)

(30)

19

Figur 9 - Information kodad i ett VIN-nummer. Källa: Scania Wiki – VIN (2017-05-04)

Känner vi till ett fordons VIN-nummer så går det att ta hjälp av SPII-databasen (se avsnitt 3.5) för att plocka ut den till fordonet tillhörande SOPS-filen. Det är denna externa datakälla som använts för att samla information kring lastbilarnas konfigurationsutförande.

3.4 Gränssnitt: Splunk

Villkoren för att genomföra medelstora statistiska undersökningar har förändrats markant under de senaste decennierna i och med utvecklingen av datorer och programvaror. Fördelarna med de nya statistiska programmen kan sammanfattas i ökad tillgänglighet till data och bekvämlighet att hantera den data som framtagits.⁴⁰ Allt material för denna undersökning finns i sin ursprungliga form i loggfiler som sparas i Scanias server när SDP3 använts. För att utföra databehandlingen och analysen har ETL (Extract Transform Load) mjukvaran Splunk använts. ETL är ett samlingsnamn för en grupp verktyg, som har till uppgift att omvandla och göra om de rådata som finns för att försöka samla den på ett ställe och att kunna hantera den utefter egna önskemål⁴¹. Denna process innebär med andra ord att extrahera data från olika källsystem så att all data ”pratar samma språk”. Splunks affärsmodell är att användaren betalar för den datamängd som arkiveras in. I Scanias fall är det den datamängd av loggfiler som genereras ur SDP3 och sedan arkiveras i den databas som Splunk installerats på. Varje dag arkiveras genom Splunk lite drygt 10 GB loggfiler i Scanias databas och som sedan lever där i ett års tid. Med hjälp av Splunk är det alltså möjligt att plocka ut meningsfull information från så kallad maskindata som kan användas i flera sammanhang, bland annat för att analysera användandet av SDP3.⁴²

Användandet av Splunks sökfunktion följer ETL metodiken som är gemensam för de flesta typer av databasverktyg. Först extraheras data genom att förfrågningar skickas till verktyget, förfrågningarna filtrerar datamaterialet efter exempelvis tidsintervall, käll-typ, kolumnindex och specifika textsträngar. Nästa steg i metodiken är transformation där resultatet av förfrågningen bearbetas.

Bearbetningen kan exempelvis vara att sortera efter ett visst versionsnummer, söka ut specifika textsträngar med hjälp av reguljära uttryck, utföra aritmetiska beräkningar på data eller sortera data i grupperingar. Bearbetningen sker på ett hierarkiskt vis där en första datakälla (läs resultat av en

40 Dahmström, Från datainsamling till Rapport, 181-182

41 http://bi-effekten.se/2012/03/25/qlikview-etl-extract-transform-load/

42 http://www.daxcom.se/logger-seg-til-bedre-flyt-med-splunk/

Figur 10 Exempel på sökning som gjorts i Splunk. Ur bilden går att följa extract och transform delen av ETL, först laddas den breda sökningen in för att sedan bearbetas.

(31)

20 databasförfrågan) sedan skalas av genom att ”pipeas” genom olika bearbetningssteg.

När väl ett bearbetningsmoment utförts har ofta en datamängd skalats av, denna mängd går inte att återskapa utan att skicka en ny förfrågan till databasen.

Det är därför viktigt att förfrågningar och bearbetning görs på ett väl genomtänkt sätt för att vara så effektiva som möjligt. Om frågor ställs i fel ordning finns en risk att viktiga, eftersökta parametrar försvinner då Splunk sorterar bort allt som inte specificerats i ett kommando. Detta är potentiellt en stor felkälla då förfrågningar som inte ställs på ett korrekt sätt kan få konsekvenser i form av fel.

Dessutom begränsas det inte till en typ av fel utan felaktigt användande av Splunk kan resultera i fel av samtliga typer, urvalsfel, bortfallsfel, täckningsfel, mätfel och bearbetningsfel. Förfrågningarna till databasen och bearbetningen måste ske på exakt samma vis när data ska hämtas ur de båda populationerna annars finns det risk för att stora felkällor introduceras i resultatet.

Sista steget i metodiken handlar om olika sätt att spara och presentera resultat. I Splunk finns det två standardutföranden av presentationer, dessa är reports och dashboards. En report är ett sparat sökningsresultat som Splunk direkt kan påkalla utan att behöver göra en ytterligare förfrågan eller ytterligare bearbetning. Reports kan schemalägga en sökning att köras i ett visst tidsintervall som varje timme, dag eller vecka för att samla in färska resultat eller för att hålla sparade sökningar vid liv. Dashboards är anslagstavlor där flera reports kan presenteras och där det är enkelt att styra över presentationsformen.

Figur 11 – Delar av ett av två dashboards som framtogs under studien. På översta raden ser vi data kopplat till användartäckning och funktionstäckning. Resten av datan i bilden är direkt kopplad till funktionstäckningen (ECU-uppdatering, reservdelsprogrammering och guidstarter).

(32)

21

3.5 Gränssnitt: Scania Product Individual Information (SPII)

Scania Product Individual Information är en databas med tillhörande webbgränssnitt som innehåller produktinformation om alla de produkter som Scania levererar till kund, lastbilar, bussar och

industrimotorer. Den produktinformation som finns att söka är bland annat SOPS:ar, ett

fordons/motors samtliga FPC-koder och dess utföranden men också unika parametersättning. Det går även att jämföra SOPS versioner och följa de justeringar som gjorts med fordonet eller motorn.

I systemet finns det flera olika roller eller behörigheter som möjliggör olika funktionalitet.

Grundbehörigheten möjliggör sökning på enskilda chassiserienummer vilket returnerar:

 Generell information

Exempelvis tillverkningsdatum, garanti, typ av fordon.

 Teknisk information

Hårdvarukonfigurationer som exempelvis typ av motor, växellåda, bränsle- och avgassystem.

 Certifikat

Fordonets certifikatnycklar, kopplat till exempelvis säkerhetskrav och reglering av fordons utsläpp. Med nycklarna går det att följa upp de certifikat som är utställda på fordonet.

Figur 12 – Webbgränssnittet som sköter kommunikationen med SPII databasen. På bilden visas teknisk information om en lastbil.

Särskild behörighet låser upp möjligheten att göra filtrerade sökningar i databasen. Det går då att välja ut kombinationer av FPC-koder och hämta ut listor med alla fordon som innehåller den angivna kombinatoriken. Listorna kan sedan exporteras i CSV format för vidare bearbetning.

En funktionalitet som hade varit önskvärd men som saknas i dagsläget är bulksökning. Bulksökning skulle innebära att som förfrågan till databasen kunna skicka flera serienummer på samma gång och få tillbaka samtliga FPC-koder kopplade till respektive serienummer. I dagsläget går det enbart att

(33)

22 söka efter ett nummer i taget alternativt filtrera efter FPC kombinatorik. Problemet med filtreringen är att ifall vanliga utföranden av FPC koder väljs blir listorna väldigt stora och exportering av dessa listor gör att man kastas ut ur systemet. Ett annat problem är att sökning blir exkluderande de serienummer som inte berörs av de utvalda FPC-koderna kommer att falla ur vilket leder till luckor i den slutliga datamängden.

3.6 Verktyg: Python

När beräkningar och jämförelser ska utföras på stora mängder data krävs användandet av datakraft.

Det finns en stor mängd olika programmeringsspråk som kan lösa den typ av databehandling som gjorts i studien. Python valdes ut då det är ett språk som dels används på Scania men också för dess engagerade bas av utvecklare och den uppmuntrande gemenskap som finns kring dess användande.

De bibliotek som varit centrala i lösningen av databearbetningen:

 Pandas

 CSV

 OS

 Selenium

Andra bibliotek som använts är:

 Random

 Time

 Pickle

 RE

Ytterligare fördelar med Python som programmeringsspråk är att språket bygger på ”dynamic typing” och sköter minnesallokeringen automatiskt, dessutom kommer grundinstallationen med ett brett utbud av för-kodade bibliotek. Kombinationen av dessa faktorer gör att det går snabbt att utveckla programprototyper som sedan kan justeras till en färdig lösning.⁴³

Problemet som kunnat lösas med script har varit sammanfogande av datamängder för att öka informationsnivån på data. Det i sin tur har möjliggjort beräkningar, vidare analys och

grafiskframställning.

43 Lutz mfl, Learning Python, 6

(34)

23

4 Testning av mjukvara

Användandet av system innehållande mjukvara ökar i samhället. Allt från mobiltelefoner,

tandborstar till bilar och kylskåp styrs av mjukvara. Den alldagliga hårdvarans prestanda ökar också i en rasande takt och hårdvara blir även mer lättillgänglig. Ökande användande, prestanda och

tillgänglighet gör det möjligt för oss människor att använda avancerad mjukvara i vårt vardagliga liv.

I takt med att användandet av mjukvara har ökat så har även kraven på tillförlitlighet och robusthet hos systemen vi använder ökat. Resultatet blir att de företag som levererar mjukvara måste garantera att mjukvaran är av hög kvalité och mognadsgrad innan den släpps till kund. Frågan som följer är då hur garanterar vi att mjukvaran är högkvalitativ och robust? Jo genom att utsätta mjukvaran för genomgående testning.

4.1 Målet med testning

Det finns främst två anledningar till att testa mjukvara. Främst åskådliggör test buggar och defekter hos programmet som leder till fel eller avvikande beteende. När buggar och defekter har identifierats kan koden korrigeras vilket leder till ett stabilare program. Inom programmeringssfären finns det två läger med olika synsätt på testning. Där det ena lägret ser testning som en form av validering som visar att mjukvaran fungerar korrekt, utför den aktivitet som den är designad för och påvisar att mjukvaran är felfri. Det andra lägret ser testning som en aktivitet vars syfte är att finna fel. Inget synsätt är på något vis mer korrekt än det andra utan det är istället en kombination av de båda synsätten som formulerar målet med att testa mjukvara⁴⁴. Verifiera funktionalitet, påvisa korrekt beteende, bedömning av kvalitet och identifiering av

buggar är alla önskvärda resultat av testning.

Ur figur 13 framgår förorsakerna till ett haveri i mjukvara. För att identifiera defekterna i programmet skapas testmoduler, så kallade testfall. Det finns olika metoder för att utforma testfall. Ett enkelt utförande av ett testfall är att indata skickas till modulen som är centrum för testet. Man förväntar sig sedan en given output från modulen, avviker outputen från det

förväntade värdet har en defekt identifierat⁴⁵. Målet är att åskådliggöra så många defekter som möjligt för att öka robusthet och kvalitet i slutprodukten. Beroende på mjukvarans tillämpningsområde utsätts mjukvaran för olika omfattande testning. Där militära/hälsovådliga applikationer utsetts för mest testning vilket också leder

till att de innehåller minst andel fel per 1000 rader kod⁴⁶. Därefter ökar antal defekter per 1000 rader kod beroende på applikationen, i fallande ordning så har vi operativsystem, applikationer med stor användarbas, mindre applikationer och enskilda moduler.

44 Homès, Fundamentals of software testing, 9

45 Myers mfl, The art of software testing, 2

46 Homès, Fundamentals of software testing, 16

Figur 13 Schematisk bild över olika typer av fel i mjukvara och hur de hör samman. I illustrationen framgår även skillnaden mellan defekt, bugg och incident. Källa: Improving software testing (2012). S.14

(35)

24

4.2 Kostnad och kvalitet

Det är omöjligt att testa alla delar av mjukvaran på alla tänkbara sätt. Någon form av totaltestning är det inte frågan om utan det är istället en kostnad och effektivitetsfråga. Hur går vi tillväga för att identifiera så många defekter och fel som möjligt till så låg kostnad som möjligt. Där kostnaden både är en fråga om tid och resurser⁴⁷.

En annan kostnadsaspekt är kostnaden för att korrigera fel i mjukvaran. Det är känt att ju senare i utvecklingsprocessen ett fel påträffas ju dyrare är det att

justera felet. Skillnaden i kostnad för att korrigera ett fel i mjukvarans utvecklingsfas jämför med när mjukvaran har släppts till kund är en ökning med faktor 100.⁴⁸ Slutsatsen som kan dras är att testning ska ske så tidigt som möjligt i utvecklingsprocessen för att minimera alla former av kostnader. På så sätt ökar sannolikheten att fler fel

identifieras och att felen identifieras i en tidsperiod där det fortfarande är ekonomiskt möjligt att korrigera dem.

Ju färre fel mjukvaran innehåller desto stabilare blir produkten. En snabb och stabil produkt upplevs också som en produkt av högkvalitet.

4.3 Varför innehåller mjukvara fel

Flera anledningar till varför fel introduceras i mjukvaran har identifierats. I källan ”Fundamentals of software testing” framgår denna illustration:

Figur 15 - Varför fel i mjukvaran existerar, hur dessa påverkar och upplevs av slutanvändaren. Källa: Fundamentals of software testing (2011) s.8

Bilden visar orsak och verkan av fel som introduceras i koden. Så fort en utvecklare rör vid koden i en enskild modul riskerar hen att introducera fel i kodbasen. Större programvaror har en stor mängd

47 Myers mfl, The art of software testing, 8

48 Majchrzak, Improving software testing, 41

Figur 14 Kostnadsökning i de olika utvecklingsstegen. Källa: Trends in software testing (2017) s.20