Akademin för Innovation, Design och Teknik
Symptombaserad felsökning
av tunga fordon
En systematisk metod för att sammankoppla kundsymptom
med systemreaktioner
Examensarbete
Avancerad nivå, 30 hp
Produkt- och processutveckling
Alexander Törnqvist & Jesper Jansson
Rapport nr:
Handledare, företag: Nedim Zaimovic
Handledare, Mälardalens högskola: Jennie Åkesson Examinator: Sten Grahn
Abstract
This thesis is about symptom-based troubleshooting of heavy vehicles. The existing troubleshooting system at Scania is adapted to handle errors based on electronic fault codes. This means that some faults, such as mechanical faults when sensors are missing, are difficult to troubleshoot. In the thesis, a method is developed that will be a part of a symptom-based troubleshooting system which can handle all types of errors. The main objectives of the thesis are both to develop a method that can link customer symptoms with system reactions and also to develop formats for both customer symptoms and FMEA for the developed method.
In the thesis, a literature study was first conducted in which troubleshooting methods and principles for the formalization of customer data were identified. The identified troubleshooting methods were Bayesian Network, Case-Based-Reasoning and Fault tree analysis. A case study was then conducted which was based on several documents for troubleshooting in gas engines and gas tanks. In the case study, data from the literature study and the empirically collected data were used to develop the final concept of the method. The case study included, among other things, semi-structured interviews to map out the existing troubleshooting process, and a workshop to choose the final concept.
In order to meet the objectives of the thesis two research questions and one question linked to the case study were formulated:
Research Questions:
• RQ1: How is the troubleshooting process affected by the methods that can be used to link customer symptoms with system reactions in heavy vehicles?
• RQ2: How can customer data and FMEA be formalized in order to be useful in the troubleshooting process of heavy vehicles?
Case Study:
• What kind of data is missing from Scania’s existing documentation to link customer symptoms with system reactions?
The thesis resulted in a method based on two troubleshooting methods Bayesian network and Case-Based-Reasoning. The method links customer symptoms with system reactions by excluding human considerations and instead relying on previously documented cases and probabilities. A requirement for using this method is a cooperation between customer support, mechanics and development engineers. The formalization of customer symptoms in the developed method is based on what good data is for mechanics in troubleshooting contexts and what customers are capable of communicating; deviation – the customer’s description of the vehicle’s unexpected condition, position – where the customer considers the deviation to be present, context – what happened before, during and after the deviation was discovered. The conclusions that can be drawn is that it is not necessary to link customer symptoms with system reactions since the developed method allows the customer symptoms to be linked directly to the corrective actions needed. In addition, it was noted that the existing documentation at Scania on customer symptoms and system reactions is insufficient. However, this is not problematic as it was shown that FMEA is redundant for the method developed. In order for customer data to be useful, the formalization should include deviation, position and context. Further conclusions are that the role of the customer support becomes less critical when data driven troubleshooting methods are used, and that the accuracy of the developed method will improve over time as more data will be collected.
Sammanfattning
Detta arbete behandlar symptombaserad felsökning av tunga fordon. Scanias befintliga felsökningssystem är anpassat för att hantera fel som grundas i elektroniska felkoder. Detta innebär att vissa typer av fel, såsom mekaniska fel när sensorer saknas, är svåra att felsöka. I detta arbete utvecklas en metod som ska ingå i ett symptombaserat felsökningssystem eftersom ett sådant system kan hantera alla typer av fel. Målen med arbetet är att utveckla en metod som kan sammankoppla kundsymptom med systemreaktioner, och utveckla format för kundsymptom och FMEA för den framtagna metoden.
I arbetet utfördes först en litteraturstudie där felsökningsmetoder och principer för formaliseringen av kunddata identifierades. Felsökningsmetoderna som identifierades var Bayesiska nätvkerk, Case-Based-Reasoning och Felträdsanalys. Därefter utfördes en fallstudie som grundades på underlag om felsökning inom gasmotorer och gastankar. I fallstudien användes data från litteraturstudien och den empiriskt insamlade data för att utveckla det slutgiltiga konceptet. I fallstudien utfördes bland annat semistrukturerade intervjuer för att kartlägga den befintliga felsökningsprocessen, och en workshop för att kunna välja det slutgiltiga konceptet.
För att kunna uppfylla arbetets mål formulerades två forskningsfrågor och en frågeställning kopplad till fallstudien:
Forskningsfrågor:
• F1: Hur påverkas felsökningsprocessen utifrån de metoder som kan användas för att sammankoppla kundsymptom med systemreaktioner inom tunga fordon?
• F2: Hur kan kunddata och FMEA formaliseras för att vara användbara inom felsökningsprocessen av tunga fordon?
Fallstudie:
• Vilken data saknas i Scanias befintliga dokumentation för att kunna sammankoppla kundsymptom med systemreaktioner?
Arbetet resulterade i en metod som baseras på de två felsökningsmetoderna Bayesiska nätverk och Case-Based-Reasoning. Metoden sammankopplar kundsymptom med systemreaktioner genom att exkludera mänskligt avvägande och istället förlita sig på tidigare dokumenterade fall och sannolikhet. En förutsättning för att metoden ska kunna användas är ett samarbete mellan kundmottagare, mekaniker och utvecklingsingenjörer. Formaliseringen av kundsymptom i den framtagna metoden bygger på vad bra data är för mekaniker i felsökningssammanhang och vad kunderna är kapabla att förmedla; avvikelse – kundens beskrivning av fordonets oväntade tillstånd, position – var anser kunden att avvikelsen förekommer, kontext – vad hände innan, under och efter att avvikelsen upptäcktes.
Slutsatserna som kan dras utifrån arbetet är att det inte är nödvändigt att sammankoppla kundsymptom med systemreaktioner, utan kundsymptom kan sammankopplas direkt med åtgärder med den framtagna metoden. Dessutom noterades det att den befintliga dokumentationen hos Scania angående kundsymptom och systemreaktioner är bristfällig. Detta är inte problematiskt då det påvisades att FMEA inte är nödvändig för att metoden ska fungera. För att kunddata ska vara användbart bör formaliseringen ske med avvikelse, position och kontext. Ytterligare slutsatser är att kundmottagarrollen blir mindre kritisk när datadrivna felsökningsmetoder används, och att den framtagna metodens träffsäkerhet kommer att förbättras över tid allt eftersom mer data har samlats in.
Förord
Arbetet har varit lärorikt och intresseväckande, men samtidigt väldigt utmanande då det har behandlat ett område som ingen av oss har haft kontakt med tidigare under vår utbildning. Dessutom var det utmanande på grund av de rådande omständigheterna i världen med covid-19 pandemin. Vi vill därför tacka Jennie Åkesson, vår handledare från Mälardalens Högskola, som har stöttat oss under arbetes gång. Dina insiktsfulla råd har varit ovärderliga och en stor bidragande faktor till att arbetet har kunnat genomföras. Följaktligen vill vi tacka Nedim Zaimovic, vår handledare på Scania AB, som har avsatt sin tid trots begränsade resurser på grund av permittering. Slutligen vill vi tacka de mekaniker och kundmottagare på Scania R&D som har gjort det här arbetet möjligt genom att ställa upp på intervjuer.
Eskilstuna, Juni 2020.
Innehållsförteckning
1 Inledning ... 1 1.1 Bakgrund ... 1 1.2 Problemformulering ... 2 1.3 Syfte och mål ... 3 1.4 Frågeställningar ... 4 1.5 Projektdirektiv ... 4 1.6 Avgränsningar ... 4 2 Teoretisk referensram ... 5 2.1 Felsökning ... 5 2.2 Symptom ... 5 2.3 Felsökningsmetoder ... 6 Bayesiska nätverk ... 6 Case-Based Reasoning ... 7 Felträdsanalys ... 8 2.4 Formalisering av kundsymptom ... 9Jämförelse mellan erfaren och oerfaren felsökare ... 9
Kund och kundmottagare ... 11
2.5 Failure Mode and Effect Analysis (FMEA) ... 12
FMEA - I felsökningssammanhang ... 13 3 Metod ... 15 3.1 Produktutvecklingsprocessen ... 15 3.2 Litteraturstudie ... 15 3.3 Fallstudie ... 16 Avgränsningar för fallstudien ... 18 Produktutvecklingsverktyg ... 18 Datainsamlingstekniker ... 20 3.4 Kvalitativ analys ... 23
3.5 Validitet och reliabilitet ... 24
3.6 Etik och moral ... 25
4 Fallstudie ... 27
4.1 QFD ... 27
4.2 Analys av felsökningssystem identifierade i litteratur ... 27
4.3 Scanias befintliga felsökningsprogram – SDP3 ... 29
4.4 Kartläggning av den befintliga initiala felsökningsprocessen ... 30
4.5 Dataanalys av dokument från Scania ... 34
Konkurrensanalys - Volvo Cars VIDA ... 37
4.6 Konceptutveckling ... 38
Konceptgenerering ... 38
Konceptval ... 41
5 Resultat ... 43
5.1 Presentation av valt slutgiltigt koncept ... 43
Den inledande fasen ... 43
Den faktiska fasen ... 44
5.2 Uppfyllelse av mål ... 46
6 Analys ... 49
6.1 Analys av det slutgiltiga konceptet ... 49
6.2 Besvarande av fallstudiens frågeställning ... 51
6.3 Besvarande av forskningsfrågorna ... 52
7 Diskussion ... 57
Litteraturförteckning ... 65
Figurförteckning
Figur 1. Visar hur ett Bayesiskt nätverk kan presenteras grafiskt med noder och relationer.
Figuren är baserad på en figur framtagen av Huang et al. (2008). ... 6
Figur 2. Visar produktutvecklingsprocessen som har tillämpats under arbetet. ... 15
Figur 3. Visar den initiala och faktiska felsökningsprocessen som utförs på Scania. ... 17
Figur 4. Visar flödet för den inledande fasen. ... 43
Figur 5. Visar den grafiska modellen för det Bayesiska nätverket för exemplet ovan. ... 45
Figur 6. Visar flödet för den faktiska fasen. ... 46
Tabellförteckning
Tabell 1. Visar teman som användes till respektive analys. ... 24Tabell 2. Visar en sammanfattning av några potentiella lösningar och rekommendationer på hur ett felsökningssystems formalisering kan vara uppbyggt. ... 28
Tabell 3. Visar bakgrundsinformation om respondenterna: kön, ålder, År av erfarenhet, befattning, samt i vilket perspektiv hen intervjuats. ... 30
Tabell 4. Visar beskrivningar av respektive steg i den initiala felsökningsprocessen. ... 31
Tabell 5. Visar data som kunden kan förmedla till kundmottagaren. ... 32
Tabell 6. Visar tidsåtgången för respektive moment i den initiala felsökningsprocessen. ... 32
Tabell 7. Visar rubrikerna som fanns i FMEA:n och en beskrivning av respektive rubrik. .... 35
Tabell 8. Visar datakvaliteten för respektive rubrik i FMEA:n. ... 36
Tabell 9. Visar uppfyllnad av de kritiska kraven samt vilket huvudmål de påverkar. ... 47
Tabell 10. Visar uppfyllnad av de önskade kraven samt vilket huvudmål det påverkar. ... 47
Tabell 11. Visar uppfyllnad av huvudmål och delmål samt motivering till samtliga del och huvudmål. ... 48
Förkortningar
CBR Case-Based-Reasoning
ECU Electronic Control Unit
FMEA Failure Mode and Effect Analysis
OBD On-Board-Diagnostics
QFD Quality-Function-Deployment
RPN Risk priority number
1 (68)
1 Inledning
I följande kapitel presenteras bland annat det som låg till grund för arbetet och vilka målen för arbetet är. Utöver det presenteras även de formulerade forskningsfrågorna och frågeställningen för fallstudien.
1.1 Bakgrund
Inom fordonsindustrin kan ingen tillverkare utesluta att det inte finns fel på ett fordon trots intensivt kvalitetsarbete och diagnostisering av fordonet då vissa fel bara kan uppenbaras efter att fordonet tillhandahållits av kunden och varit under drift (Wedeniwski, 2015). En anledning till varför fel inträffar trots noggranna åtgärder i produktutvecklingsfasen av fordon, är att under de senaste åren har funktionaliteten och komplexiteten av fordonen ökat. Den ökade komplexiteten av tekniska fordon bidrar till mer komplexa symptom när fel uppkommer under användningsfasen hos fordonen (Bracke & Haller, 2012). Detta gör även att felsökningssystemen blir viktigare för fordonens säkerhet och tillförlitlighet samtidigt som det blir mer komplext att felsöka fordon (Huang, et al., 2008).
Scania CV AB är ett tillverkande företag av produkter för transportlösningar, så som lastbilar och bussar. Samtidigt erbjuder Scania ett flertal tjänster kopplade till deras produkter gällande reparationer och underhåll (Scania CV AB, 2018). Kristensson et al. (2014) påpekar att en värdeskapande process kan skapas i kombination av tjänst och fysisk produkt för kunden. Det innebär att det inte är själva lastbilen eller bussen som efterfrågas av kunden, utan istället förmågan att kunna frakta gods mellan olika platser. Därför är det tillgängligheten av transportlösningen som skapar värde för kunden. Detta innebär att tyngden ligger i vad produkten gör och inte vad den är (Kristensson, et al., 2014). Genom att effektivt upprätthålla Scanias produkters funktionalitet med välutvecklade felsökningssystem kan företaget skapa konkurrenskraftiga värdeerbjudanden.
Inom Scania R&D arbetar YS-avdelningen med eftermarknad där utveckling av verktyg kopplade till diagnosticering sker. YSNE-gruppen, som tillhör YS-avdelningen, ansvarar för diagnosticeringen av styrenheter, Electronic Control Unit (ECU), kopplade till hytt och chassi. YSNE arbetar huvudsakligen med utveckling av verktyget Scania Diagnos & Programmer 3 (SDP3), som framförallt används av mekaniker på Scanias verkstäder. SDP3 bygger på felkoder som identifieras av styrenheterna i Scanias produkter. Om felkoder är aktiva kan SDP3 användas av mekanikerna för att åtgärda felet (Scania CV AB, 2017). Arbetet med SDP3 innebär bland annat att utveckla lösningar inom verktyget som både förbättrar tillgängligheten för kundernas fordon och reducerar servicekostnader. Underhåll är en nödvändig aktivitet inom de flesta mekaniska och dynamiska system vilket är både tidskrävande och kostsamt. För fordonsindustrin är detta inte ett undantag. Inom underhåll är feldiagnos en kritisk aktivitet och om det utförs effektivt och produktivt kan det spara tid, pengar och därmed öka tillgängligheten för fordonsägare, då tillgängligheten ofta är deras källa för inkomst. Diagnostisering ses som upptäckten av fel, isolering av fel och åtgärd (James, et al., 2018).
Verktyg, såsom SDP3, kan också betraktas som en produkt. Verktygen används i sin tur för att tillhandahålla tjänster till Scanias huvudprodukter, det vill säga lastbilar och bussar. Ur ett produktutvecklingsperspektiv kan diagnosticeringen ses som en kritisk del eftersom om information kring produktens hälsa inte kan erhållas, kan inte lämpliga åtgärder utföras. Lämpliga åtgärder kan exempelvis vara reparation eller vidare diagnosticering av fordonet.
2 (68)
Scania undersöker ständigt hur deras felsökningsprocesser kan förbättras. Ett sätt att förbättra felsökningsprocessen är att ta fram ett verktyg som inkorporerar kundsymptom i felsökningsprocessen. I ett initiativ från Scania har därför ett förslag lagts fram att undersöka möjligheten att utveckla ett verktyg inom symptombaserad felsökning som kompletterar det befintliga felkodsbaserade felsökningssystemet. Detta för att kunna hantera alla typer av fel, vilket omfattar elektroniska, hydrauliska och mekaniska fel. Dessutom görs detta också för att Scania eftersträvar att majoriteten av lastbilarna ska vara färdigdiagnosticerade innan de kommer in till verkstäderna.
Verktygets princip bygger på att sammankoppla kundsymptom med systemreaktioner, och sedan systemreaktioner med lämpliga åtgärder. I praktiken innebär detta att de angivna kundsymptomen leder till lämplig åtgärd. I studien kommer kundsymptom betraktas som kundens sätt att beskriva avvikelser hos ett system utan teknisk kompetens. I detta fall en beskrivning av fordonets oväntade tillstånd. Exempelvis vibrationer, ljud, lukt och synliga tecken så som rök och varningslampor. Systemreaktioner betraktas som de designade effekterna felet har på ett systemet. Exempelvis om en ventil sitter fast så produceras en felkod och en gul lampa börjar lysa på informationsklustret i fordonet. I detta fall är systemreaktionen både felkoden som aktiveras samt att den gula lampan börjar lysa. Felet är att ventilen sitter fast, och effekten av det blir systemreaktionerna.
I samband med att nya komponenter utvecklas till lastbilarna eller bussarna av Scania utförs en så kallad Service Failure Mode and Effect Analysis (SFMEA). Detta för att bland annat identifiera fel, så kallade felmoder, för olika komponenter och konsekvenserna som blir om felmoderna uppstår (Scania AB, 2014). Scanias SFMEA är en variant av den traditionella Failure Mode and Effect Analysis (FMEA). I studien kommer enbart termen FMEA att användas för att erhålla en generaliserbarhet genom arbetet. Scania anser att denna datakälla, FMEA, kan vara en relevant utgångspunkt för studien i och med att den innehåller information kring systemreaktioner. Dessutom anser YS-avdelningen på Scania att detta är deras mest pålitliga data inom området.
1.2 Problemformulering
Problematiken med att endast använda sig av felkoder är att felkoder endast kan detektera några av alla potentiella grundorsaker till ett problem. Detta gör att felkoder endast kan ge visst stöd för diagnostisering och endast peka ut vissa felaktiga komponenter i systemet, beroende på felkodens precision (James, et al., 2018). Scanias befintliga felsökningsprogram SDP3 är anpassad för att hantera felkoder för diagnostisering av fordonen idag. Vissa system i fordonen har i viss utsträckning ofta sensorer som i sin tur kan fungera som underlag för felkodsbildning. Dock är det praktiskt och ekonomiskt omöjligt att förse alla fordonets delar med sensorer, vilket innebär att det alltid kommer att finnas mekaniska fel vars uppkomst inte kan upptäckas och identifieras med felkoder. I sådana fall kan inte mekanikerna instrueras av SDP3 för vilka lämpliga åtgärder som måste utföras för ett observerat fel, och det blir då även svårt att kunna upprätthålla den tänkta funktionaliteten hos produkten.
För att kunna hantera alla typer av fel har, som tidigare nämnts, ett förslag lagts fram att utveckla ett verktyg inom symptombaserad felsökning. Problemet i dagsläget är dock att ingen omfattande utredning har gjorts för att klargöra hur verktyget för symptombaserad felsökning ska fungera. Dessutom finns problematiken att Scanias verkstäder runt om i världen inte är konsekventa med hur insamlingen av kundsymptom utförs. Därför påverkas kvaliteten och formen på den data som samlas in av hur verkstadspersonal väljer att dokumentera den. För att systematisera sammankopplingen mellan kundsymptom och systemreaktioner måste därför
3 (68)
formaliseringen av kundsymptom först överses. Dessutom kommer även formaliseringen av FMEA att utredas i och med att sammankopplingen anses grundas i FMEA. Därefter måste en metod för sammankopplingen mellan kundsymptom och systemreaktioner identifieras för att kunna erhålla en tillräckligt god träffsäkerhet mellan kundsymptom och åtgärd. God kvalitet på metoden för sammankopplingen leder till en god kvalitet på felsökningen av Scanias huvudprodukter, lastbilar och bussar, vilket i sin tur leder till att Scania kan säkra sitt värdeerbjudande.
1.3 Syfte och mål
Syfte: Syftet med studien är att få en matchning mellan kundsymptom och systemreaktioner inom felsökning av tunga fordon. Dessutom ska studien utreda hur formaliseringen av kundsymptom och verktyget Failure Mode and Effects Analysis (FMEA) bör se ut för att möjliggöra denna sammankoppling.
Mål: Arbetet har två mål. Det ena är att utveckla en metod för att tydligt sammankoppla kundsymptom med systemreaktioner inom tunga fordon (1). Metoden kommer att vara en dellösning som ingår i det verktyg för symptombaserad felsökning. Det andra är att utveckla ett format för kundsymptom och FMEA som kan tillämpas i den framtagna metoden för sammankopplingen mellan kundsymptom och systemreaktioner (2).
För att uppnå målen definieras ett delmål med tillhörande kravlista. Varje krav i listan är kopplat till minst ett huvudmål. Det finns både kritiska krav och önskade krav, för motivering av de kritiska kraven, se Bilaga A – Motivering av kritiska krav.
Delmål: Uppfylla 10/10 av kraven, det acceptabla målvärdet är att uppfylla alla kritiska krav 5/5.
Kravlista: Kritiska krav:
• Identifiera kategorier av data som är nödvändiga för att formalisera kundsymptom och som möjliggör att en sammankoppling mellan kundsymptom och systemreaktioner kan uppnås. Påverkar mål: (1), (2).
• Identifiera kategorier av data som är nödvändiga för att formalisera FMEA och som möjliggör att en sammankoppling mellan kundsymptom och systemreaktioner kan uppnås. Påverkar mål: (2).
• Identifiera vetenskapligt grundade felsökningsmetoder som kan tillämpas för att sammankoppla kundsymptom med systemreaktioner. Påverkar mål: (1).
• Metoden skall kunna hantera kundsymptom som både grundas i elektroniska fel och mekaniska fel. Påverkar mål: (1).
• Metoden skall ta hänsyn till den detaljrikedom av information som en kund är kapabel till att ge kundmottagaren med sin tekniska kompetens. Påverkar mål: (1), (2).
Önskade krav:
• Metoden skall vara applicerbar inom samtliga system, som exempelvis broms- och motorsystemet, i ett tungt fordon. Påverkar mål: (1).
• Metoden skall förebygga brister som existerar i den nuvarande initiala felsökningsprocessen. Påverkar mål: (1).
4 (68)
• Metoden skall tillhandahålla möjlighet till förslag på åtgärd i framtida symptombaserat felsökningsverktyg. Påverkar mål: (1), (2).
• Metoden skall vara tillämpbar till samtliga generationer av Scanias fordon. Påverkar mål: (1).
1.4 Frågeställningar
Forskningsfrågor:
• F1: Hur påverkas felsökningsprocessen utifrån de metoder som kan användas för att sammankoppla kundsymptom med systemreaktioner inom tunga fordon?
• F2: Hur kan kunddata och FMEA formaliseras för att vara användbara inom felsökningsprocessen av tunga fordon?
Fallstudie:
• Vilken data saknas i Scanias befintliga dokumentation för att kunna sammankoppla kundsymptom med systemreaktioner?
1.5 Projektdirektiv
Examensarbetet på 30 högskolepoäng utförs mot Scania AB under vårterminen 2020. Tidsramen för arbetet är 20 veckor. Arbetet dokumenteras i en rapport som ska hålla en hög teknisk nivå, och ska presenteras i arbetets slutskede. För att uppnå Mälardalen Högskolas lärandemål ska även en opponering genomföras.
1.6 Avgränsningar
• Arbetet avser inte att behandla kopplingen mellan kundsymptom och lämpliga åtgärder i ett symptombaserat felsökningssystem. Istället avser arbetet att behandla den initiala kopplingen mellan kundsymptom och systemreaktioner.
• Arbetet avser att utveckla koncept, för att sammankoppla kundsymptom med systemreaktioner, som använder befintliga felsökningsmetoder. Arbetet avser inte att gå djupgående inom dessa felsökningsmetoder.
• Arbetet avser inte att praktiskt validera det slutgiltiga konceptet, istället utförs en workshop i samband med konceptsållningen för att ta hänsyn till Scanias preferenser och kunskaper. Samtidigt görs detta för att stödja att en god vetenskaplig nivå kan erhållas i arbetet.
• Arbetet avser inte att behandla ekonomiska faktorer såsom kostnaden av att realisera den framtagna metoden och/eller den eventuella kostnadsbesparingen för att nyttja metoden i verksamheten.
5 (68)
2 Teoretisk referensram
I följande kapitel kommer begreppet felsökning och symptom redogöras, samt kommer metoder lämpade att använda vid felsökningsapplikationer att presenteras. Utöver detta presenteras även principer för att formalisera kunddata.
2.1 Felsökning
Felsökning kan betraktas som en problemlösningsform. En felsökning kan utföras inom flera olika tillämpningsområden, exempelvis inom mekaniska och elektroniska system. Strategin för att felsöka komponenter är att först identifiera komponenten som har ett avvikande beteende, och vad som orsakar att komponenten inte kan utföra den önskvärda funktionen. Förutom felidentifikationen, även kallad feldiagnos, omfattar felsökning även handlingar för att åtgärda felen. En åtgärd kan vara reparation av komponenten, men när detta inte är möjligt så kan en ersättning istället vara nödvändig. Dock menar H. Jonassen & Hung (2006) att den största vikten inom felsökning ligger på den initiala felidentifikationen. Det huvudsakliga syftet med felsökning är att komponenter ska återfå ett normalt beteende. Därför använder felsökningsarbetare den insamlade feldiagnosdata för att kunna utföra relevanta åtgärder som eliminerar felet (Hung & Jonassen, 2006).
Inom felsökning förekommer det flera utmaningar, och en del grundas i att problembilden för ett fel kan vara väldigt stort. Det innebär att det kan finnas många potentiella orsaker till att ett specifikt fel uppstår. Dessutom grundas alla fel inte alltid av en enda orsak, utan flera orsaker kan tillsammans ha inverkan på att fel uppstår. Det ökar komplexiteten i att kunna minimera felets problembild. En annan utmaning grundas i att en förutsättning för att kunna utföra feldiagnoser oftast är att mekanikern besitter tidigare erfarenheter kring systemet och komponenterna i fråga. Därför kan det vara komplext för oerfarna mekaniker att utbildas inom felsökningsområdet (Hung & Jonassen, 2006).
Cegarra & Hoc (2006) beskriver feldiagnos som processen av att jämföra symptom med syndrom, med syndrom menas då en bestämd kombination avvikelser medan symptomen är de enskilda avvikelserna. Men det förekommer flera definitioner av feldiagnos-strategier. Det påpekas att det finns två sätt att se diagnostik på. Den ena är strategier som utgår från det nominella beteendet av en enhet och baseras på den fysiska strukturen, för att kunna genomföra en positionsbaserad sökning eller en funktionell sökning. Den andra är strategier vilka vägleds av det icke nominella beteendet. Exempelvis genom sökning av hypoteser som vägleds av relationen mellan symptom och syndrom. I samband av de två uppdelningarna beskrivs ett tredje sätt som negligerar en uppdelning. Den tredje beskrivningen grundar sig i att en uppdelning av positionsbaserad och funktionell sökning inte är nödvändig för den symptombaserade sökningen, detta då symptomen kan anpassas efter både funktionella och positionsbaserade termer (Cegarra & Hoc, 2006).
2.2 Symptom
Enligt Nationalencyklopedin (2020) kan symptom även skrivas som ”symtom”. Där beskrivs även att symptom ofta används inom medicinsk terminologi som beskrivning av tecken på en viss sjukdom (Nationalencyklopedin, 2020) (Cegarra & Hoc, 2006). Exempelvis som en sjukdomsyttring som uppfattas av den sjuka personen och yttrar sig genom obehag eller lidande som följd av en sjukdom (Nationalencyklopedin, 2020). Cegarra & Hoc (2006) nämner att symptom är en del av diagnostiken vilket omfamnar områden utöver medicin så som process kontroll och felsökning. Ord som ”symtombild” och ”symtomfri” benämns även i sammanhang med symptom (Nationalencyklopedin, 2020). Bergmann et al. (2003) beskriver i samband med felsökningsmetoder att symptom används vid diagnostik av fordon. Beskrivning av ett fall inom
6 (68)
en felsökningsmetod kan göras genom de observerade symptomen hos fordonet. Symptomen kan exempelvis vara en problembeskrivning (exempelvis, motorn startar inte), kontextparametrar (exempelvis, tändningsnyckeln är vriden) eller mätparametrar (exempelvis värden för hur en elektronisk enheten mår genom mätningar med testverktyg) (Bergmann, et al., 2003).
2.3 Felsökningsmetoder
I följande kapitel presenteras metoder som kan användas i felsökningssammanhang. Bayesiska nätverk
Inom diagnos kan probabilistiska metoder som grundas i sannolikhetslära tillämpas. En metod som används frekvent vid diagnosapplikationer är Bayesiska nätverk. Metoden kan användas för att beräkna sannolikheten att ett specifikt fel hos ett system eller en komponent förekommer. En förutsättning för att kunna utföra sannolikhetsberäkningen är att en grafisk modell först tas fram. I denna modell redogörs relationer och beroenden mellan fel som kan förekomma och observationer som kan göras när felen uppstår (Warnquist, 2015), se Figur 1. I Bayesiska nätverk betraktas felen och observationerna som noder. Förutom fel och observationer kan även symptom användas som noder (Huang, et al., 2008). Noder som påverkar andra noder i den grafiska modellen kan betraktas som ”parent nodes”. Noder som är direkt beroende av andra ”parent nodes” betraktas istället som ”child nodes” (Kurz, et al., 2011). I Bayesiska nätverk är det viktigt att beroendena mellan noderna inte är cykliska. Därför kan ett Bayesiskt nätverk betraktas som ett så kallat ”riktat acykliskt diagram” (Huang, et al., 2008).
Figur 1. Visar hur ett Bayesiskt nätverk kan presenteras grafiskt med noder och relationer. Figuren är baserad på en figur framtagen av Huang et al. (2008).
I utförandet av ett Bayesiskt nätverk bestäms respektive nods sannolikhetsdistribution, i en tabell, efter att beroendena i den grafiska modellen har definierats. Hur nodernas sannolikhet bestäms beror på typen av nod. Till ”parent nodes” som inte är beroende av några andra noder kan sannolikheten bestämmas genom att studera statistiska data, eller så kan den erhållas genom tidigare erfarenheter. Sannolikheten till ”child nodes” bestäms istället av ”parent nodes”, vilket innebär att sannolikheten blir i detta fall villkorlig. En ”child nodes” sannolikhet grundas alltså i andra påverkande sammankopplade noders status (Huang, et al., 2008).
Bayesiska nätverk kan tillämpas till system som är väldigt komplexa i sin natur, exempelvis fordon med ett stort antal ingående system och komponenter. Dessutom förutsätter inte metoden att samtliga data, till exempel data gällande observationer, har identifierats, utan metoden kan
7 (68)
tillämpas ändå (Kurz, et al., 2011). Dessutom kan Bayesiska nätverk bli smartare då ny data tillförs (Warnquist, 2015).
Case-Based Reasoning
Case-Based-Reasoning (CBR) är en metod som kan tillämpas vid komplexa felsökningsapplikationer. Metoden har sitt ursprung från maskininlärningsområdet, ”machine learning”. Principen för metoden är att identifiera lösningar till nya problem genom att sammankoppla tidigare fall av lösta problem. Detta kan liknas med människans naturliga tillvägagångsätt för att lösa problem (Yu, et al., 2015). Fallen av lösta problem beskrivs i så kallade ”cases”, och dokumenteras efter att felsökningsprocessen är avklarad och validerad (Warnquist, 2015). Formaliseringen på fallen är i största grad standardiserad. Varje fall innehåller huvudsakligen två typer av information som tidigare nämnts; problem och lösning. Problembeskrivningen utgörs främst av observationer som användaren kan göra när ett fel har uppstått. Lösningen innehåller istället information kring vilka aktiva åtgärder, i detta fall reparationer, som gjordes för att eliminera felet som orsakade problemet (Yu, et al., 2015). Dokumentation av fallen sker i ett bibliotek, i en så kallad ”case library”. Biblioteket används sedan som underlag när nya problem hos system ska diagnosticeras. Informationen i fallen jämförs med tidigare dokumenterade fall i biblioteket, och uppstår det en matchning rekommenderas lösningen från det tidigare fallet. Dock om det inte sker någon matchning kan istället användaren instrueras att utföra vissa relevanta observationer. Genom att tillföra kompletterande information kan en matchning eventuellt ske. En förutsättning för att kunna utföra felsökningar när nya problem uppstår är att det finns tidigare fall i biblioteket. Därför utförs oftast initialt manuella felsökningsprocesser för att tillföra fall i biblioteket som möjliggör att matchningar mellan nya och tidigare fall kan göras. En nackdel med CBR är att felsökningskvaliteten är direkt beroende av tid, och därför är inte alltid metoden tillförlitlig till en början (Warnquist, 2015).
Matchningen av ett liknande fall görs genom en så kallad ”retrieval” (hämtning). Det finns flera sätt att utföra en hämtning på vilket ofta påverkas av fallets representation i ”case library”. Exempelvis om det använts ett textbaserat CBR-system för dokumentationen används en nyckelordsdriven metod för att hämta fallet. Däremot om CBR-systemet har använts med ett så kallat ”konversions-CBR-system” har systemet en mer djupare och mer avancerad kodning bakom sig för att kunna möjliggöra en hämtning av fallet (Bergmann, et al., 2003). ”Konversations-CBR-system” är CBR-system som framkallar en fråga för att beskriva ett problem, ofta i användning för att minimera problembilden och komma fram till en lösning (Aha, et al., 2006). Det nämns även att CBR-system som följer ett strukturerat tillvägagångsätt ofta går att skräddarsy utefter hur matchningen mellan fallen sker och då hämtningen av fallet sker. Tekniken som används för detta kallas ”nearest neighbour” och utgår från att den globala likheten mellan fall kan matchas. I tekniken kan funktioner eller andra värden som nummer och symboler användas för att göra en matchning mellan fallen. I samband med textbaserade CBR-system nämner Bergmann et al. (2003) att det är orealistiskt att ens en tränad kundmottagare skall kunna alla nyckelord vid sökning efter fall i ett ”case library”. Inte heller kan då förvänts att en kund kan alla nyckelord (Bergmann, et al., 2003).
CBR kan betraktas som en metod som relativt enkelt kan identifiera lösningar på problem. Detta grundas i att nya fall jämförs med tidigare fall för att identifiera lämpliga lösningar. Vilket innebär att den bakomliggande logiken för sammankopplingen mellan fel och lösning inte behöver utredas. Dock kan avsaknaden av logik medföra att träffsäkerheten mellan fel och
8 (68)
korrekt lösning kan försämras. Dessutom kan det vara svårt att erhålla en god feldiagnos när symptom inte bara grundas i ett enda fall (Yu, et al., 2015).
Felträdsanalys
Felträdsanalys (FTA) är en ofta förekommande metod som används inom spridda branscher. En FTA:s huvuduppgift är ofta att bidra med pålitlighet och utvärdering av säkerhet i stora komplexa och säkerhetskritiska system (Bobbio, et al., 2001). FTA har även föreslagits av forskare som metod för att hitta potentiella fordonsfel, genom att systematiskt analysera fordonets system, delsystems och komponenters grundorsaker till fel. Under senare år har FTA exempelvis används för att diagnostisera fel inom fordonsindustrin (James, et al., 2018). Det finns flera typer av felträdsanalyser varav en är standarfelträd (SFT). Ett SFT passar till statiska system medan det finns felträd som är skräddarsydda för dynamiska system, så kallade Dynamiska Felträd (DFT). Dynamiska felträd är utvecklingar av standarfelträd (Kabir, 2017). Standardfelträd – SFT
Uppbyggnaden av SFT bygger på att ansvarig för uppbyggnad av trädet har förståelse av systemets struktur samt principer inom systemet (Yu, et al., 2015). Metodens struktur baseras på att oönskade händelser och felsymptom analyseras, det kan exempelvis vara ett systemfel i ett fordon. Det oönskade felsymptomet sätts som Topp-händelse (TH) i strukturen av trädet. Strukturen bygger sedan på att en bakvänd metod där utgångspunkten är TH och jobbar mot att hitta grundorsaken till problemet genom att gå mot trädets grenar och löv. Detta betyder att strukturen av ett SFT följer en ”top-down” approach (Bobbio, et al., 2001). Ett SFT erbjuder även en grafisk presentation av hur felsymptom och kombinationer av felhändelser leder till det innan nämnda grundorsaken till problemet. Det som ofta presenteras grafiskt som det logiska trädet är en översättning av det fysiska systemets logiska struktur till ett logiskt diagram i form av ett SFT (James, et al., 2018). Den visuella presentationen hjälper användare att utföra felsökning på ett lämpligt sätt (Yu, et al., 2015). Förutom den visuella fördelen med ett SFT, är att resultatet visar hur olika komponenters felsymptom eller miljörelaterade förhållanden tillsammans skapar systemets fel (Kabir, 2017). Vid analys av ett färdig konstruerat SFT utförs analysen ofta genom två nivåer, så kallade kvantitativ och kvalitativ analys. En kvalitativ analys används oftast för att reducera antalet grundhändelser till det minsta antalet nödvändiga, för att hitta orsaken till topp-händelsen (TH). Detta görs ofta genom att beräkna sannolikheten av underliggande noders gemensamma sannolikhet, (förhållandet mellan dessa sannolikheter beror på händelsernas relation med varandra) för att sedan jämföras mellan grenarna i trädet. Kvantitativanalys av ett SFT innebär oftast att sannolikheten och/eller någon annan typ av mätbardata, används för att räkna ut vilken individuell komponent av systemet som med största sannolikhet innehar det grundläggande felet (Kabir, 2017) (Ruijters & Stoelinga, 2015). För mer information om grindar och symboler som kan används i ett SFT, se Bilaga B – Symbolbeskrivning av felträdsanalys.
Dynamiskt felträd – DFT
Standardfelträd är endast kapabla till att utvärdera statiska system. Ett statiskt system är ett system som endast har ett typ av läge under drift, vilket gör att påfrestningen av system är konstant och förändras inte beroende på systemets driftläge. Stora komplexa system så som moderna tunga fordon, har däremot flera driftlägen vilket gör att ett SFT inte är tillräckligt för att bevaka pålitligheten. En skillnad mellan driftlägen kan till exempel vara hur ett fordon opererar i ett stillastående läge och hur det opererar i ett drivande driftläge. En konsekvens av dynamiska system blir att fel uppstår som är karakteristiskt-urskiljbara i relation till funktionsrelaterade händelser för olika driftlägen av de dynamiska systemet. Dynamiska pålitlighetsbedömningar har många fördelar över statiska pålitlighetsbedömningar, genom
9 (68)
möjlighet till analys av dynamiska system kan det dynamiska angreppssättet inhämta information från flera typer av stadier i ett system. Det kan även modellera flera senarior av interaktion mellan olika komponenter och variabler. Ett dynamiskt system har även möjlighet till att fånga tid- och sekvensberoende beteenden i komplexa system (Kabir, 2017). Det finns flera typer av dynamiska pålitlighetsbedömningar varav den vanligast använda är DFT, vilket också är en typ av utveckling av ett SFT (Ruijters & Stoelinga, 2015). Ett dynamiskt felträd står ut från mängden på grund av förmågan att kunna behandla sekventiella beteenden av system (Kabir, 2017). För att det sekventiella beteendet skall kunna analyseras används vanligtvis två till typer av grindar i ett DFT, Funktionellt Beroende (FB) grindar och RESERV grindar. Med sekventiellt beteende menas ett beteende vilket återkommer i en sekvens (Ruijters & Stoelinga, 2015).
Automatiskt genererarbara felträd
FTA: er utförs oftast manuellt, men med växande komplexitet av system finns ett behov av att simplifiera FTA:er. Under senare år har därför forskare utforskat möjligheten till att åstadkomma pålitlighetsinformation från systemmodeller automatisk och semiautomatisk. Enligt Kabir (2017) har det lett till utveckling inom området ”Modellbasserad Pålitlighetsanalys” eller på engelska ”Model-based Dependability Analysis” (MBDA). Flera MBDA tekniker baseras på felträd som grunden för teknikens pålitlighetsanalys. Det finns flera tekniker för MBDA några av dem är ”Failure Propogation and Transformation Notation” (FPTN), ”Hierrarchically Performed Hazard Orgin & Propogation Studies” (HiP-HOPS) och ”AltaRica” (Kabir, 2017).
2.4 Formalisering av kundsymptom
Här presenteras i flera delar den identifierade litteraturen gällande formalisering av kundsymptom. Delarna presenterar bland annat hur en oerfaren felsökare ställer sig mot en erfaren felsökare och vilka kunskapsområden felsökare använder vid felsökning.
Jämförelse mellan erfaren och oerfaren felsökare
Enligt Hung & Jonassen (2006) finns det flera skillnader mellan erfarna och oerfarna felsökare. Lärande oerfarna felsökare bygger ofta upp kunskapsrika mentala konceptuella modeller av alla olika ingåendesystem som exempelvis ingår i ett fordon, en erfaren felsökare däremot litar mer på mentala händelsescheman som byggs upp utefter erfarenhet. Oberoende av vilket område felsökning utförs inom exempelvis medicin eller fordon, visar forskning på att en frekvent exponering av så kallade ”sjukdomsbeskrivningar” giver felsökaren kunskap av symptommönster och ett mentalt händelseschema kan byggas upp. Symptommönster kan användas som kunskap och är tendenser av att specifika delar går sönder i specifika fordonsmodeller och feltillstånd. Vad som gör informationen användbar hos en erfaren felsökare jämfört med en oerfaren, är att en erfaren felsökare har en större mängd relaterbara händelser med sin erfarenhet att relatera till. Hung & Jonassen (2006) beskriver några punkter för vilka nivåer av kunskap olika erfarenhetsnivåer av felsökare kan besitta:
• Förståelse för systemens olika syften och mål. • Förståelse för övergriplig struktur och funktion.
• Generaliserad förståelse för standardfunktioner och processer för systemet.
• Förståelse för fysisk struktur och funktioner av systemet, exempelvis mekaniska och elektrisk komponenter vad dem gör och deras betydelse.
• Förståelse för systemets struktur, funktioner, ”informationstopologi” (koppling emellan del-system och hur dem samarbetar) och materialkunskaper.
10 (68)
I högsta grad kan en oerfaren felsökare ha en övergripande förståelse för struktur och funktion medans en erfaren felsökare förstår systemets struktur fullt ut, vart del-system sitter, hur varje del har sin funktion och hur flödet av funktioner och information i systemet hör ihop (Hung & Jonassen, 2006).
Hung & Jonassen (2006) presenterar flera kunskapsområden inom vilka erfarna och oerfarna felsökare utnyttjar olika information.
(1) Domänkunskap är generellkunskap om teorier och principer som rör system och del-systems, exempelvis specifika materialkunskaper så som korrosionsbeständighet eller principer som Ohm`s lag. Domänkunskap är inte en viktig del för att bli en erfaren felsökare, däremot är det viktigare i den meningen att få djupare kunskap och förstå grunder till felorsaker (Hung & Jonassen, 2006). Erfarna felsökare har ofta en djupare förståelse och kunskap av domänkunskaper än oerfarna felsökare (Cegarra & Hoc, 2006).
(2) Systemkunskap ses som kunskap av strukturen i systemet, funktionerna av komponenterna i systemet och beteendet av komponenterna och beteendet i samspelet med andra komponenter. Den största skillnaden mellan erfarna och oerfarna felsökare ses som kunskapen av systemet (Hung & Jonassen, 2006). Forskare har kommit fram till att erfarna felsökare använder topografiskkunskap för att bestämma felorsak av fordon på ett systematisk sätt (Hung & Jonassen, 2006) (Cegarra & Hoc, 2006). En topografisk modell av ett system är en rumslig presentation av systemet. I fordonsindustrin innebär topografisk kunskap positionen av systemets alla ingående komponenter, till exempel positionen av komponenterna i en motor eller bromssystem. Topografiskkunskap har visat sig effektivt för att bryta ner problembilden. Jämfört med oerfarna felsökare som inte har sådan kunskap skapar teorier av felorsaken slumpmässigt, vilket inte är lika effektivt för att hitta felorsaken till problemet. Lika väl som topografiskkunskap är funktionellkunskap viktigt för felsökare. Funktionellkunskap är förståelse för varje individuell komponents funktion och relation till andra komponenter. Funktionellkunskap kan exempelvis vara hur gnist och valv synkroniseringen påverkar kompressionen i en motor. Många erfarna felsökare organiserar ofta sin mentala topografiska karta utefter funktioner i förstahand. Oerfarna felsökare har en tendens till att skapa lösningsteorier till felorsaker mer på den topografiska kunskapen, som nämnt innan är oftast även kunskapen begränsad inom detta område. Även fast att både topografiskkunskap och funktionskunskap båda är två bra källor att basera en hypotetisklösning på, använder oftast erfarna felsökare den funktionella kunskapen i första hand som en metod för att skapa en mental visuell problembild. Felsökning baserad på funktionellkunskap leder oftast felsökaren till felorsak effektivare (Hung & Jonassen, 2006). Cegarra & Hoc (2006) förklarar även att ett topografiorienterat tillvägagångsätt har två variabler att ta hänsyn till, vilka är bedömningen av symptomets relevans och hur vidare positionen är korrekt.
(3) Prestanda- och procedurkunskap handlar om kunskap relaterad till mätningar och utförande av tester. Sådan kunskap sker till stor del automatiskt genom sensorer i modernare fordon. Även är utförande av rutinarbete så som service och underhåll kopplad till prestanda- och procedurkunskap. Utförandet av kunskapen är oftast begränsad till just det specifikt lärda systemet eller del-systemet. I dagens läge finns det ofta felsökningssystem som assisterar felsökaren med prestanda- och procedurspecifik kunskap för varje individuell fordons modell. Genom att kunskapen är så pass automatiserad är det oftast ingen större skillnad på erfarna och oerfarna felsökare inom kunskapsområdet prestanda- och procedurkunskap (Hung & Jonassen, 2006).
11 (68)
(4) Strategiskkunskap är kunskap relaterad till vetskap av vad som skall felsökas i första eller nästa steg om felorsak inte kan urskiljas samt att bekräfta hypoteser för felorsaken. Författarna beskriver att strategiskkunskap är en väsentlig del i att isolera potentiella fel. En klassificering kan göras gällande strategiskkunskap. Strategiskkunskap kan delas upp i lokal- och global-strategi. Globalstrategi är strategikunskap oberoende av systemet och området. Det betyder att kunskap som är globalt strategisk kan användas för flera system och del-system inom olika områden, så som mekaniska eller elektroniska. Lokalstrategikunskap klassificeras som kunskap som endast kan användas inom ett specifikt system, komponent eller område, så som instrumentbräda, varvmätare och elektronik. Hung & Jonassen (2006) nämner att globalstrategikunskap hjälper felsökare att minimera problembilden medans lokalstrategikunskap assisteras felsökaren i att utföra en reduceringsprocess. Inom strategisk kunskap finns det ett antal kända strategier för att systematiskt genomföra felsökning, dem specifika strategierna är oftast mer användbara för oerfarna felsökare än för erfarna felsökare. Erfarna felsökare använder sig mer av erfarenhet än specifika felsökningsstrategier. Vid felsökning av mycket komplexa system kan det vara fördelaktigt för en erfaren felsökare att också använda en specifik felsökningsstrategi (Hung & Jonassen, 2006).
(5) Erfarenhetskunskap har bevisats i flera studier vara den mest användbara typen av kunskap. Vid diagnostisering har erfarenhetskunskap visats vara det vanligaste sättet för att strategiskt gå fram i ett felsökningsperspektiv. Enligt Hung & Jonassen (2006) har även forskare kunnat konstatera att felsökare grundar hypoteser om felorsak då där finns ett avvikande symptom som kan ge felsökaren insikt i orsaken. Vidare har där även bevistats att erfarna felsökares vanligaste handling mot att lösa ett problem, är att undersöka det vanligaste felet utefter erfarenhet. Erfarenhetskunskap visar sig vara den mest användbara kunskapen för felsökare, vilket också är den största skillnaden mellan en erfaren och en oerfaren felsökare (Hung & Jonassen, 2006). En skillnad mellan erfarna och oerfarna felsökare är att erfarna felsökare är bättre på att bedöma ifall ett symptom är korrekt eller inte. Samtidigt är en erfaren felsökare även bättre på att identifiera potentiella symptom (Cegarra & Hoc, 2006).
Kund och kundmottagare
När en kund beskriver ett symptom beskriver kunden ofta felet utefter vad kunden observerar. Kunden besitter i generell mening ingen teknisk kunskap om fordonet vilket gör att observationerna som görs av kund vid observerade avvikelser från det nominella beteendet ofta inte är av analyserad karaktär. Med analyserad karaktär menas att kunden inte drar några slutsatser kring det observerade symptomet. Faktumet att kunden inte drar slutsatser från det observerade symptomet visar på att teknisk kunskap saknas om fordonet. Om samma symptom observeras av en erfaren kundmottagare beskriver oftast kundmottagaren symptomet som en direkt felorsak. Exempel på ett sådant scenario skulle kunna vara om kunden observerar att fordonet inte har någon tändning vid uppstart av fordonet, symptomet skulle kunna beskrivas som ”inget vrid i motor, när nyckel vrids om”. Kundmottagaren given samma observation beskriver symptomet istället som ”urladdat batteri”. Faktumet att kundmottagaren beskriver symptomet som felorsak indikerar då på ett tekniskt kunnande om fordonet (O`Neill, et al., 2005).
Kundmottagare har i många fall en roll som översättare mot kunden. Kundmottagare översätter ofta det mer vardagliga språket som kunden beskriver symptomen i till mer tekniska termer. Konversationen mellan kund och kundmottagare sker ofta i mer vardagligt språk. Översättningen kundmottagaren gör utförs ofta av två anledningar. För det första för att symptom eller felorsakbeskrivningar i de felsökningsprogram som kundmottagaren jobbar mot ofta använder mer tekniskt korrekta termer vilka är okända för kunden. För det andra på grund
12 (68)
av att kunden saknar tekniskt kunnande kan inte kunden medla i tekniska termer eller förstå den tekniska informationen kundmottagaren har tillhandahållet. Det är tydligt att kundmottagaren har en viktig roll i förädlandet och tolkningen av vad kunden observerar, för att kunna förmedla vidare information i felsökningsprocessen (O`Neill, et al., 2005). Forskare menar på att kunden inte skall behöva ha ett tekniskt kunnande för att kunna beskriva sina felsymptom på ett sätt som är värdefullt för kundmottagaren. I situation där kunden skall beskriva symptom utan assistans av kundmottagare som översättare av kundens symptom, är det också viktigt att beskrivningen kan ges på ett sätt som kunden är kapabel till att utföra. Eventuellt genom ett mer vardagligt språk i form av symptom istället för i form av felorsaker och lösningar (O`Neill, et al., 2005) (Bergmann, et al., 2003).
Kundmottagaren har även en viktig roll att, med hjälp av kunden medla för att komma fram till felorsaker. På grund av kundens lägre grad av tekniskt kunnande kan observerbara symptom ibland vara svåra att observera. På grund av det är kundmottagaren också ett form av bollplank mot kunden för att tillsammans komma fram till fler symptom som annars kunden inte hade observerat utan kundmottagarens hjälp. Kunden kan även göra egna bedömningar av vikten av ett symptom. Exempelvis kan kunden anse att symptomet inte har någon informationsmässig tyngd för att resultera i en felorsak. Det kan leda till att kundmottagaren inte får all den tillgängliga informationen som behövs för att göra en korrekt diagnostisering direkt. Kundmottagaren kan då behöva ställa följdfrågor för att vara säker på att all relevant information samlats in (O`Neill, et al., 2005).
För att symptom skall vara aktuella understryker O`Neill et al. (2005) att där bör finnas ett sätt att uppdatera eller tillföra symptom i felsökningssystemet. När kundmottagare inte är närvarande är det även relevant att ge kunden information om vilka steg som måste genomföras för att kontrollera symptomens relevans. Det ska då ge kunden möjlighet att själv kunna minimera problembilden. När kundmottagare inte är tillgänglig är det även viktigt att ge kunden möjlighet till att kunna söka både på tekniska termer och vardagliga språktermer. På så sätt kan kunden utnyttja den tekniska kunskapen kunden besitter, samtidigt som kunden kan utnyttja vardagliga termer där kunden inte besitter teknisk kompetens (O`Neill, et al., 2005).
2.5 Failure Mode and Effect Analysis (FMEA)
Failure Modes and Effects Analysis (FMEA) är en metod för att identifiera fel som kan uppstå hos en produkt (Ullman, 2010). Khan et al. (2014) beskriver att FMEA är en väl använd metod för att identifiera och eliminera kritiska fel som påverkar pålitligheten i ett system. Ofta används metoden för att förbättra pålitligheten hos ett system innan dess systemet lanseras på marknaden, då designförändringar fortfarande är möjliga inom en rimlig kostnad (Khan, et al., 2014). Inom fordonsindustrin är det vanligt att använda sig av FMEA för att utvärdera pålitligheten och potentiella fel både i design- och funktionselementen av ett system. Att kombinera en FMEA-analys med en design för en komponent är ett vanligt utförande i fordonsindustrin (Teng & Ho, 1996). FMEA kan även användas vid felsökning av produkter då fel och åtgärder har kartlagts. I detta fall omfattar definitionen av fel både orsaken till att felet uppstod, och vilken funktion hos produkten som felet påverkar. Utförandet av en FMEA grundas i fem steg; ”Identify the Function Affected”, ”Identify Failure Modes”, ”Identify the Effect of Failure”, “Identify the Failure Causes or Errors”, och “Identify the Corrective Action” (Ullman, 2010).
Det första steget handlar om att avgöra vilken funktion hos produkten som felet påverkar. Det andra steget handlar istället om hur felet artar sig, och hur det synliggörs. I det tredje steget undersöks andra funktioner än den som är direkt påverkad av felet. Detta beror på att ett fel kan
13 (68)
innebära att andra fel också uppstår. Därför undersöks och beskrivs övriga potentiella effekter av felet. Efter detta arbete startar det fjärde steget som handlar om att identifiera det bakomliggande felet. Ullman (2010) menar att felen kan kategoriseras enligt följande; designfel (D), tillverkningsfel (M) och operationella fel (O). Det slutgiltiga steget handlar om att utreda och dokumentera vilka handlingar som åtgärdar respektive fel. I det här steget listas handlingar som rekommenderas att utföras, och vilken medarbetare inom organisationen som ska utföra handlingen. Ibland kan det vara en annan åtgärd än den rekommenderade som löste felet. Därför är det viktigt att dokumentera den åtgärd som verkligen fungerade. Om ett fel är ett design- eller tillverkningsfel är åtgärden för att minimera risken att felet uppstår oftast att göra vissa förändringar i produktens design. Därför dokumenteras dessa förslagna designändringar. Däremot om felet är operationellt, så kan det vara mer relevant att utveckla en rutin för att enklare upptäcka felet. Dock så kan designändringar även underlätta vid operationella fel för att felets inverkan på funktionen inte ska bli lika stort (Ullman, 2010). Riskprioritetsnummer - ”Risk priority number” (RPN) kan ansättas för felmoder i en FMEA. Värdet för RPN består ofta av tre faktorer, upptäckbarhet - ”detectability”, förekomst - ”occurrence” och allvarlighetsgrad - ”severity” (Khan, et al., 2014). Värdena för varje faktor utgår oftast från en 10 gradig skala, där ett lågt nummer eftersträvas. RPN-värdets faktorer kan även bedömas individuellt. Exempelvis om en felmod har en hög faktor för allvarlighetsgraden kommer den anses som en kritisk felmod, däremot kan en kritisk felmod fortfarande ha ett relativt lågt RPN-värde om den har en låg faktor för förekomst (Teng & Ho, 1996).
FMEA - I felsökningssammanhang
FMEA är ett typiskt sätt att förutse potentiella fel av ett system. Med informationen från metoden kan ingenjörer avgöra hur ”On-Board-Diagnostics” (OBD) teknik kan upptäcka potentiella fel. OBD är en dataenhet vilket övervakar och producerar felkoder i en lastbil. Med informationen från FMEA kan även felsökningsaktiviteter förberedas, aktiviteterna gör det sedan möjligt att hitta felets grundorsak från alla möjliga potentiella orsaker. Khan et al. (2014) menar på att aktiviteter för felsökning samlas i felsökningsmanualer. Manualerna används sedan manuellt av kompetent personal för att avgöra grundorsaken till ett potentiellt fel. Manualerna är inte felfria, vilket betyder att manualerna inte är helt korrekta eller kan ge stöd för alla potentiella fel, men det förespråkas heller inte att manualerna är det. Samtidigt uppdagas ändå att det är viktigt att uppdatera materialet för FMEA som om det vore ett dynamiskt dokument med ny information och kunskap gällande potentiella felorsaker. Där påpekas även att FMEA-analyser användas för att bidra till utvecklingen av effektiva underhålls-, felsöknings- och reparationsaktiviteter samt underlag till underhållsmanualer och OBD-system i flera branscher. Det är ingenjörer som förutser de potentiella felen i en FMEA, men på grund av den mänskliga faktorn kan ingenjörerna inte förutse alla fel. Om ett fel uppstår som står utanför de identifierade potentiella felen, löses problemet ofta av kunskap på verkstäder (fältkunskap). Lärdomar som görs från felen som inte har förutspåtts av ingenjörerna genom FMEA lämnas ofta odokumenterade, även fast där finns viktiga lärdomar att göras från dessa lösta fall (Khan, et al., 2014).
Det har uppdagats att det gynnar arbetsflödet för felsökningen med fälterfarenhet. I samband med fälterfarenhet av underhåll och reparationer är det positivt med delandet av erfarenhet mellan parter. Vidare spridning av nya erfarenheter kring ett system kan leda till att andra parter inom ett företag exempelvis, avdelning för reparation och underhåll kan lösa problem snabbare. Att spara ned fälterfarenhet inom underhåll och reparationer kan även över tid hjälpa den utvecklande sidan i ett företag att förbättra pålitligheten av system och komponenter. Khan et al. (2014) menar med detta att fälterfarenhet hade gynnat utvecklingen av arbetsflödet för felsökning om informationen förmedlas tillbaka till ingenjörerna som utför FMEA (Khan, et al., 2014).
14 (68)
Med FTA är det möjligt att räkna ut pålitligheten av att system. Däremot är det nödvändigt att identifiera de potentiella felen innan en FTA utförs. En FMEA kan användas för att ge en FTA information angående de potentiella felen i ett system. Detta görs möjligt genom att översätta data i en FMEA till matematiska modeller. Modellerna används sedan för att implementera i en FTA. En FTA möjliggör sedan att det går att peka ut enskilda potentiella fel i komplexa system. Det föreslås att standardiserade kontroller bör göras så att fälterfarenhet och numerisk data kan samlas in på ett standardiserat sätt. Ren numerisk data från fälterfarenhet kan konverteras till sannolikhetsdata. Att återkoppla data från fält gällande sannolikhet för exempelvis komponenter, hade varit fördelaktigt för RPN-värdet i en FMEA. RPN-värdet i FMEA kan stödja sannolikheten för olik komponenters sannolikhet för potentiella fel, vilket vidare kan användas i en FTA. Fördelaktigheten med att basera RPN-värdet på fältdata är att talet blir trovärdigt, och om detta görs kontinuerligt kan det även vara en bevakning över komponenter och olika designval för komponenter, hur dem presterar och mår ute på fält (Teng & Ho, 1996).
15 (68)
3 Metod
I följande kapitel presenteras metoden som har tillämpats genom hela arbetet.
3.1 Produktutvecklingsprocessen
Arbetet innehåller både en litteraturstudie och en fallstudie, där litteraturstudien kan ses som ett förarbete till fallstudien. Tillvägagångsättet som har följts under arbetet baseras på produktutvecklingsprocessen beskriven av Ulrich & Eppinger (2012). Denna produktutvecklingsprocess innehåller sex olika faser; ”Fas 0: Planering, Fas 1: Konceptutveckling, Fas 2: Utveckling på systemnivå, Fas 3: Detaljutveckling, Fas 4: Testning och vidareutveckling samt Fas 5: Produktionsupptakt (Ulrich & Eppinger, 2012). Eftersom arbetet inte avser att resultera i en färdig produkt, utan endast i ett metodförslag, måste vissa faser exkluderas eller anpassas. För att vara lämpad för arbetets ändamål utformades därför en egen produktutvecklingsprocess med bas i den tidigare nämnda processen, se Figur 2. Fas 0 omfattar bland annat litteraturstudien, medan Fas 1 och 2 omfattar fallstudien.
Figur 2. Visar produktutvecklingsprocessen som har tillämpats under arbetet. 3.2 Litteraturstudie
Litteraturstudien utfördes inom områdena kunddata, FMEA och felsökningsmetoder för att skapa en bas till den kommande fallstudien. Det fanns två mål med att utföra litteraturstudien. Det första målet var att samla in data angående tidigare forskning inom respektive område. Detta gjordes för att kunna identifiera vilka metoder och principer som senare skulle kunna tillämpas vid konceptgenereringen i fallstudien. Det andra målet var att kunna stödja fallstudiens slutsatser med vetenskapliga artiklar vilket anses öka arbetets generaliserbarhet. Utöver de ovan nämnda områdena studerades även begreppen felsökning och symptom för att kunna erhålla relevanta ämneskunskaper. Då arbetet grundades i felsökning och symptom ansågs det fördelaktigt att erhålla en allmän förståelse kring dessa begrepp i samband med att arbetet uppstartades.
Innan insamlingen av litteratur påbörjades bestämdes ett flertal begränsningsfaktorer för att erhålla en högre relevans på litteraturen (Bell, 2006). Begränsningsfaktorerna som bestämdes var bland annat; tidsintervall 2005-2020, litteratur som är expertgranskad och att antalet resultat vid sökning inte får överskrida 100 stycken. Årtalsbegräsningen valdes för att det ansågs som ett rimligt span för att avgränsa för relevant litteratur och antalet resultat sattes som begränsningsfaktor för att visa på att kombinationen av nyckelord var tillräckligt specifik. De satta begränsningsfaktorerna följdes så gott det kunde, i ytterst få fall där relevant litteratur inte kunde hittas släpptes tyglarna för vissa begränsningsfaktorer, såsom tidsintervall och antal resultat. För fullständig information kring begränsningsfaktorerna, se Bilaga C – Information om litteraturstudie. Eftersom den insamlade litteraturen initialt var avsedd för andra studier så
16 (68)
är data i litteraturstudien sekundär. Detta skiljer sig från primära data, som är data som exklusivt samlats in till en studie (Saunders, et al., 2009).
I början av litteraturstudien studerades först Scanias rekommenderade litteratur inom felsökning, vilket var doktorsavhandlingen Troubleshooting Trucks – Automated Planning and Diagnosis av Warnquist (2015). Utifrån avhandlingen skrevs korta minnesanteckningar och använda nyckelord dokumenterades. Relevant litteratur som refererades undersöktes även för att erhålla ytterligare ämneskunskap och förståelse kring frekvent använda nyckelord. Vid dokumentationen av denna litteratur noterades även dess relevans med kategorierna; starkt relevant, tveksamt relevant och inte relevant. Detta för att kunna undersöka litteraturen på ett strukturerat sätt. Utifrån den identifierade litteraturen och arbetets forskningsfrågor kunde egna nyckelord formuleras. En del nyckelord var direkt tagna från dokumentation kring frekvent använda nyckelord, medan andra egenformulerades. Ett exempel på ett egenformulerat nyckelord var Customer symptom, där ordet Customer lades till för att göra nyckelordet mer specifikt mot arbetet än vad enbart ordet symptom hade varit. Exempel på nyckelord som användes vid litteratursökningen var; Automotive industry, Fault diagnosis, Symptom och Troubleshooting. Sökningen av litteratur utfördes i bland annat följande databaser; IEEE Xplore, ScienceDirect, Google Scholar, SpringerLink och Emeraldinsight. För att avgöra den identifierade litteraturens relevans utvärderas litteraturens titel först. Därefter utvärderades även sammanfattningen. Vid osäkerhet lästes även litteraturens inledning och slutsats. Därefter dokumenterades samtlig relevant litteratur (Bryman, 2016).
Det ovannämnda tillvägagångsättet för att söka efter litteratur följer metoden för litteratursökning beskriven av Bryman (2016). Metoden användes utav två anledningar. Den första anledningen var att metoden ansågs ge en tydlig struktur till litteratursökningen, vilket ökar arbetets reliabilitet. Den andra anledningen var att metoden utgår ifrån specifik litteratur, i detta fall den tidigare nämnda doktorsavhandlingen, vilket gjorde det möjligt att använda litteratur med anknytning till både Scania och forskningsfrågorna. Detta ansågs underlätta litteratursökningsprocessen då relevant data kunde samlas under kortare tid.
3.3 Fallstudie
En fallstudie utfördes för att kunna utveckla format för kundsymptom och FMEA. Dessutom för att kunna utveckla en metod, där respektive format integreras, för att sammankoppla kundsymptom med systemreaktioner i tunga fordon. En fallstudie innebär att utföra en studie vilket involverar empiriska utföranden i en verklig kontext som stödjs av flera källor (Saunders, et al., 2009). Inom studien har förövrigt flera kvalitativa datainsamlingstekniker använts inom fallstudien. Av alla tillgängliga kvalitativa insamlingstekniker för fallstudie, användes semistrukturerad intervju, workshop och litteraturstudie. Flera datainsamlingstekniker valdes att användas för att försäkra att data berättar det som är antaget, enligt triangulering (Saunders, et al., 2009). Fallstudien har anpassats för att kunna besvara de frågeställningar som formulerats i arbetets uppstartningsfas. Frågeställningarna formaliserades utöver arbetets syfte och mål, utefter arbetets valda approach, ändamål och forskningsprocess. I arbetet valdes induktiv som approach, då tillvägagångssättet linjerade med syftet och målet med arbetet. En induktiv approach innebär bland annat; att teori följer empiriska data, att där kan finnas flera alternativa lösningar till samma problem och inom en induktiv approach framställs kvalitativa data som den primära datatypen (Saunders, et al., 2009). Arbetet har skett i ett utforskande tillvägagångssätt. Det har inneburit att arbetet har inriktats mot att utforska bland annat mönster och besvara frågeställningar istället för att grunda arbetet på att bevisa en hypotes (Sage Publications, 2020). Arbetet har vidare skett enligt en anpassad produktutvecklingsprocess, se 3.1 Produktutvecklingsprocessen, som forskningsprocess för arbetet.
