Designspecifikation Max Karjalainen

Transkript

1 Designspecifikation Max Karjalainen Version 1.1 Granskad Status Godkänd LIPS Designspecifikation i bohli890@student.liu.se

2 PROJEKTIDENTITET HT15, Detektion och felisolering i er Linköpings universitet, Institutionen för systemteknik Namn Ansvar Telefon E-post Bohan Liang Projektledare (PL) bohli890@student.liu.se Markus Vilhelmsson Testansvarig (TA) marvi038@student.liu.se Max Karjalainen Designansvarig (DA) maxka588@student.liu.se Minh Le Tran Dokumentansvarig (DOC) minle240@student.liu.se Philip Nilsson Mjukvaruansvarig (MA) phini326@student.liu.se Erik Carlsson Dataansvarig (DA) erica797@student.liu.se E-postlista för hela gruppen: bohli890@student.liu.se Hemsida: Beställare: Erik Frisk, ISY, frisk@liu.se Kund: Volvo Car Sverige AB, GÖTEBORG, Växel Kontaktperson hos kund: Mikael Krizmanik, mikael.krizmanik@volvocars.com Kursansvarig: Daniel Axehill, B-huset 2A:581, , daniel@isy.liu.se Handledare: Daniel Jung, , daner@isy.liu.se LIPS Designspecifikation ii bohli890@student.liu.se

3 1 Introduktion Parter Syfte och Mål Användning Bakgrund Definitioner Översikt Modellering Diagnossystem Modellering Utvärdering av delmodeller Implementation av felmodeller och testfunktioner för simulerade fel Strukturell analys av diagnostiserbarhetsprestanda... 9 Feldetekterbarhets- och isolerbarhetsprestanda... 9 Sensorplacering samt möjlighet till extra sensorer... 9 Analys av systemets realtidsprestanda Mätning Arbetspunkter Körcykler Diagnossystem Feldetektion Autogenerering av tester Val av tester Residualer och tröskling Cumulative Sum Generalized likelihood ratio Utvärdering av teststorheter Metoder för att skapa teststorheter Felisolering Minimal Hitting Set Approach Rangordning Sannolikhetsbaserad diagnos Systemarkitektur Referenser Appendix A Fabriksmonterade sensorer LIPS Designspecifikation iii bohli890@student.liu.se

4 Dokumenthistorik Version Datum Utförda förändringar Utförda av Granskad Första utkast MaK,PhN Reviderad version MaK,BoL Första version MaK,BoL Korrigeringar från beställare LIPS Designspecifikation iv

5 1 Introduktion Projektet Detektion och felisolering av er är ett studentprojekt som tillhandahålls utav institutionen för systemteknik (ISY) vid Linköpings universitet. Projektet är ett samarbete mellan ISY och Volvo Cars, Göteborg och utförs som en del utav kursen (TSRT10). Projektet utförs enligt utbildnings ramverket Construct Design Implement Operate (CDIO). 1.1 Parter De involverade parterna i projektet är; Kund, Mikael Krizmanik (Volvo Cars) Examinator, Daniel Axehill (ISY) Beställare, Erik Frisk (ISY Vehicular Systems) Handledare, Daniel Jung (ISY - Vehicular Systems) Projektet kommer att utföras utav sex studenter från civilingenjörsprogrammen i maskinteknik samt teknisk fysik och elektroteknik. 1.2 Syfte och Mål Syftet med projektet är att analysera hur ett modellbaserat diagnossystem för en kan utvecklas med hjälp av ett systematiskt arbetssätt. Projektets syfte är att utvärdera utvecklingsmetodiken vid skapandet av diagnossystemet samt dess framtida potential i utvecklingsarbete hos kunden. Projektets mål är att presentera en analys av utvecklingsmetodiken bakom det framtagna diagnossystemet samt leverera tillhörande diagnossystem i form av MATLAB-kod. Med diagnossystemet kommer en tillhörande simuleringsmodell av motorn att presenteras. Simuleringsmodellen motorn under drift samt ett antal olika felmodeller. Simuleringsmodellen kommer att valideras mot uppmätt data från motorlaboratoriet. Diagnossystemet kommer att valideras med uppmätt data från motorlaboratoriet och data från simuleringsmodellen. De uppmätta experimenten från motorlaboratoriet skall även sammanställas i en databas för framtida forskning. 1.3 Användning Projektet kommer att användas till att undersöka om modellbaserad diagnos är ett effektivt verktyg för att utveckla framtida diagnossystem hos kunden. 1.4 Bakgrund Feldetekterings- och felisoleringsalgoritmer övervakar komponenter och delsystem för att larma då komponenter felar eller inte längre uppfyller sin funktion. I personbilar är motordiagnostikalgoritmer en central och viktig del av styrsystemets funktionalitet och algoritmerna körs typiskt i realtid under normal drift av fordonet. Diagnosfunktionaliteten kan vara riktad mot On-Board Diagnostics (OBD)-lagstiftning som krävs för certifiering av fordon, eller användas som information till verkstadstekniker för att effektivisera felsökning. En enkel beskrivning av ett diagnossystem är att ett antal, så kallade teststorheter, är implementerade som detekterar olika fel. I en ideal situation har man en teststorhet för varje LIPS Designspecifikation 5 bohli890@student.liu.se

6 typ av fel och då blir felutpekningen trivial, eftersom varje larm direkt pekar ut en specifik komponent. I ett komplext system som en modern i en personbil, är det inte realistiskt att kunna generera tester som bara är känsliga för ett fel. Detta beror delvis på att det skulle krävas en stor mängd sensorer, något som inte är ekonomiskt eller tekniskt möjligt idag. Dessutom, i en motor är delsystemen ihopkopplade på så sätt att en förändring i en komponent kommer påverka hela systemet vilket gör att ett fel på ett ställe manifesterar sig även i andra delar av motorn och ett fel kan leda till larm i flera teststorheter. Exempelvis är insug och avgas-sidorna ihopkopplade via turbo och kompressor och ett läckage av luft kan leda till onormala luftflöden på flera positioner vilket kan ge upphov till larm och samtidigt oväntade tryck vilket också kan ge larm. Att systemet dessutom är dynamiskt, dvs. det tar en viss tid innan fel börjar påverka olika delar av systemet, bidrar med ytterligare komplexitet. Fel kan också uppenbara sig under speciella driftsförhållanden för att sedan inte visa sig under andra driftsförhållanden. Det kan också vara fel som försvinner efter en tid, till exempel en kloggning som sedan släpper. Dessa fel kallas för intermittenta fel och kan vara svåra att återskapa och därmed åtgärda. Därmed är det viktigt att kunna detektera och isolera intermittenta fel online. 1.5 Definitioner Följande förkortningar kommer användas i kravspecifikationen. CDIO - Construct Design Implement and Operate ISY - Institutionen för Systemteknik LiU - Linköpings Universitet MAF Mass Air Flow MSO - Minimally Structural Overdetermined set of equations FTP - Federal Test Procedure NEDC - New European Driving Cycle CUSUM Cumulative Sum GLR Generalized likelihood ratio 2 Översikt Systemet kommer att bestå av två större delar som här kommer att beskrivas i korthet. Den första delen är den modell som kommer att användas för att modellera det nominella beteendet hos n. Den andra delen är själva diagnossystemet, vars uppgift är att så långt som möjligt peka ut vad som faktiskt är fel i motorn. I simuleringsmiljön kommer även finnas möjlighet att välja om riktiga data eller simuleringsdata ska testas i diagnossystemet. Figur 1 visar en översikt av systemet där kopplingen mellan motormodell, motor och diagnossystem syns. Figur 1: Översikt av systemet LIPS Designspecifikation 6 bohli890@student.liu.se

7 För att kunna fastställa huruvida det är fel på motorn eller inte behövs redundans. Redundansen ges av att kombinera modellerade värden med uppmätta värden. Detta gör det möjligt att konstruera teststorheter som reagerar på olika uppsättningar av fel. Vidare kommer diagnossystemet isolera vilka fel som möjligen skulle kunna orsaka det uppmätta beteendet. Slutligen rangordnas de möjliga diagnoserna efter vilken uppsättning fel eller diagnos som mest sannolikt orsakar beteendet. 2.1 Modellering Merparten av modelleringsarbetet som krävs för att utveckla diagnossystemet är redan gjort då en simuleringsmodell av motorn tillhandahålls utav projektets beställare. Simuleringsmodellen visar god noggrannhet då dess simulerade värden jämförs med mätdata från motorlaboratoriet då merparten av simuleringsvärdena är inom +/- 10 % av mätvärden. Undantaget är avgastemperaturen, fyllnadsgradsmodellen för cylindrarna samt turbinens vinkelhastighet. De brister simuleringsmodellen uppvisar bör tas hänsyn till vid design av diagnossystemet. Simuleringsmodellen ska vidareutvecklas med felmodeller över de intressanta felen som är givna för projektet. Dessa ska implementeras för att kunna testa diagnossystemet utan att utföra nya mätningar på motorn. Simuleringsmodellen ska även vidareutvecklas med en förarmodell och en fordonsmodell. Detta gör det möjligt att simulera körcykler i simuleringsmodellen. 2.2 Diagnossystem I diagnossystemet kommer sensorerna även att vara tillgängliga i motormodellen så att samma fel, både för motormodellen samt den riktiga motorn, kan diagnostiseras. 3 Modellering En grundförutsättning för diagnossystemet är att en modell av den aktuella motorn utvecklas. Utifrån en given modell, med tillhörande modellfel, är projektets mål att diagnostisera systemet och vilka prestanda som kan uppnås på ett systematiskt sätt. En modell av motorn som är validerad mot mätdata finns tillgänglig i projektet. Tidigare valideringar av modellen visar att vissa delmodeller har dålig modellnoggrannhet och kan behöva förbättras, till exempel variabla ventiltider som inte modelleras i modellen. Däremot är huvudmålet i projektet inte modellutveckling utan design av diagnossystemet och begränsad tid kommer att läggas på att förbättra modellen. Den slutgiltiga modellen ska simulera motorn och producera relevant simuleringsdata för vidarebehandling av diagnosalgoritmerna. De parametrar som finns i modellen kan delas upp mellan de fysikaliska konstanterna som är generella för hela systemet och de parametrar som är unika för de olika delmodellerna. Parametrarna finns till stor del implementerade i de MATLAB-filer som initierar motormodellen och kan således hämtas därifrån. Diagnosmodellen kommer att utvecklas i MATLAB. För att hitta MSO er innehållandes de möjliga tester som går att göra kommer Fault Diagnostics Toolbox [4] användas. Modellekvationerna som bygger upp simuleringsmodellen för motorn kommer att extraheras och deklareras i MATLAB. När motormodellen är deklarerad i MATLAB kommer felmodeller att införas i motormodellen. Efter att motormodellen och felmodellerna är deklarerade går det att skapa en diagnosmodell i MATLAB. Sedan när diagnosmodellen är deklarerad i MATLAB går det enkelt att dra slutsatser kring exempelvis modellens residualer. LIPS Designspecifikation 7 bohli890@student.liu.se

8 De parametrar som är generella för systemet ska presenteras var för sig. Vidare ska delmodellernas parametrar listas för varje delmodell i systemet. Parametrarna finns till stor del implementerade i de MATLAB-filer som initierar motormodellen och kan således hämtas därifrån. 3.1 Utvärdering av delmodeller De delmodeller som behöver utvärderas för att undersöka huruvida förbättringsåtgärder krävs är modellen för turbinens varvtal, modellen för avgastemperatur samt fyllnadsgradsmodellen för cylindrarna. I det fall att dessa modeller inte uppfyller de krav som ställs av diagnossystemet finns olika tillvägagångssätt. Antingen undviker man att jobba med de arbetspunkter där dessa modeller är dåliga eller så utvecklas modellerna för att bättre kunna simulera motorn. Det går även att anpassa trösklarna i diagnossystemet för olika arbetspunkter. På så sätt kan man undvika falsklarm men ändå bevara detekterbarhetsprestandan i de arbetspunkter där modellen är bra. Det kan även krävas sofistikerade ansatser som till exempel datadrivna metoder för att undvika falsklarm. För att utvärdera de tillhandahållna modellerna kan mätvärden från motormappen jämföras med simulerad data. Detta är möjligt att göra i den tillhandahållna Excel-filen, där alla mätvärden från motormappen jämförs med simulerade värden, och de procentuella felen visas. I första hand ska modellerna utvecklas så att diagnoser vid undersökta arbetspunkter inte påverkas av modellfel. Att undvika de arbetspunkter där modellerna är dåliga ska främst göras ifall den tid som går åt till att förbättra modellen bedöms vara för stor. Även i de fall att en delmodell endast är dålig utanför de arbetspunkter som är intressanta för projektet anses det okej att använda dessa. De delmodeller som inte går att lita på i den tillhandahållna modellen är främst varvtalet i turbinen, avgastemperaturen samt insugstrycket. Vid låga laster och varvtal visar modellen för insugstrycket bristande överensstämmelse mot riktiga mätdata. En trolig anledning till detta är att fyllnadsgradsmodellen för cylindrarna inte är tillräckligt bra. Modellen för kompressorn stämmer sämre vid lågt massflöde. Komponenterna i motormodellen valideras genom att jämföra de modellerade värdena mot uppmätta statiska värden. Detta ger information om modellens validitet i statiska arbetspunkter. Valideringen, både av delmodellerna och motormodellen som helhet, sker i SIMULINK. Modellen som helhet ska även testas tillsammans med modeller för drivlina och förare för att kunna testa motorn under en körcykel. Modellnoggrannhet analyseras i samband med modellvalideringarna. Vid validering av varje delmodell ska delmodellens exakthet och dess användbarhet ur en diagnostisk synvinkel analyseras. Utifrån detta kan modellnoggrannheten utvärderas. Om en delmodell inte kan uppnå önskad kvalité för diagnostikens ändamål ska fortsatt användning motiveras. 3.2 Implementation av felmodeller och testfunktioner för simulerade fel Motormodellen kommer initialt att simulera motorn vid nominellt beteende, det vill säga då alla komponenter i motormodellen är funktionsdugliga. För att kunna simulera motormodellen inklusive fel måste de olika felen modelleras. Felen i motorn kommer till en början modelleras som additiva- eller proportionella fel beroende på vad som bäst modellerar respektive fel. Felmodellerna kommer att införas i motormodellen som finns i SIMULINK. De olika felen kommer att införas i respektive ekvation där felet ingår. Vid simulering av defekt motor LIPS Designspecifikation 8 bohli890@student.liu.se

9 kommer felen att injiceras direkt från ett MATLAB-script. I skriptet kommer det vara möjligt att mata in felets storlek samt start respektive sluttid. De felmodeller som går att implementera i motorlaboratoriet kommer att valideras mot mätdata. Vissa av felen i motormodellen kommer dock ej vara möjliga att implementera fysiskt, till exempel olika luftläckage i systemet. Dessa felmodeller kommer att valideras genom att motormodellen ses över när felet är injicerat i modellen då dessa inte kan valideras mot mätdata. När motormodellen ses över, avses att signifikanta storheter i motormodellen antar rimliga värden i enlighet med det felbeteende som ska simuleras. Ska exempelvis ett läckage simuleras så är det beteende man vill uppnå att flödet in i en komponent inte längre är detsamma som flödet ut ur densamma. 3.3 Strukturell analys av diagnostiserbarhetsprestanda Prestandan hos diagnossystemet ska analyseras med avseende på feldetektion, isolerbarhet, sensorval och placeringar samt systemets realtidsprestanda. Feldetekterbarhets- och isolerbarhetsprestanda Den detekterbarhet som uppnås kommer att bero på hur de olika felen syns i de modellekvationer som motormodellen består av. Detekterbarheten för de olika felen ska således dokumenteras och en analys ska göras som ska förklara vad som skulle krävas för att utöka systemets detekterbarhet. Analysen ska även inkludera resonemang vad gäller huruvida de olika felen är svagt respektive starkt detekterbara samt ifall att diagnosprestandan hos systemet skulle kunna höjas ifall fler fel var starkt detekterbara. Det arbete som leder fram till den isolerbarhetsmatris som ligger till grund för beslutsstrukturen i diagnossystemet ska sammanställas i en analys. Syftet med denna är att visa hur den resulterande isolerbarhetsprestandan uppnåtts. Vidare ska analysen förklara hur man, om möjligt, kan uppnå bättre isolerbarhetsprestanda. Sensorplacering samt möjlighet till extra sensorer I modellen kommer ett visst antal sensorer vara utplacerade. Felen antas även vara detekterbara och det är möjligheterna att skapa teststorheter som avgör detekterbarheten av felen. Dessa möjligheter ska motiveras i samband med icke-detekterbara fel. Om ett fel inte kan detekteras utförs en analys om möjligheten att installera extra sensorer i modellen samt analysera diagnosprestandan. För att kunna återigen detektera felet som inte var detekterbara kräver att ytterligare redundans skapas. Extra sensorer kan införas i den komponent vilkets modellekvation innehåller storhet som felet kan påverka. Sensorplaceringen och dess effekt kommer undersökas med hjälp av Fault-Diagnosis-Toolbox och utifrån dessa så kan diagnosprestandan jämföras med fler, respektive färre sensorer. Analys av systemets realtidsprestanda Diagnossystemets reaktionstid kan variera beroende på olika typer av fel. Det är därför värdefullt att analysera systemets realtidsprestanda för att undersöka huruvida systemet kan vidareutvecklas i syfte att arbeta online i ett fordon. Även den tid det tar för systemet att detektera och isolera de olika felen är intressant ur ett realtidsperspektiv. LIPS Designspecifikation 9 bohli890@student.liu.se

10 4 Mätning Innan mätningar görs så väljs arbetspunkter samt körcykler. Arbetspunkter kommer att väljas så att de representerarar motormodellen vid olika laster och varvtal. Körcykler körs så att mätvärden i ett verklighetsnära scenario kan användas. 4.1 Arbetspunkter De arbetspunkter som används för att utföra tester av diagnossystemet ska väljas för att representera hela motorns arbetsområde med avseende på last och varvtal. Detta görs genom att välja arbetspunkterna som en glesare delmängd av den tillhandahållna motormappen. Resultatet blir då att hela motorns arbetsområde används, dock med lägre upplösning än i den tillhandahållna motormappen. Arbetspunkter väljs först och främst för att validera den felfria modellen av motorn. Felinjiceringarna sker också under de valda arbetspunkterna. En analys som motiverar de valda arbetspunkterna ska göras, för att säkerställa ett så bra urval som möjligt. 4.2 Körcykler Körcykler används för att excitera motorn och motormodellen på ett sätt som är så likt ett verkligt körscenario som möjligt. En körcykel består av en hastighets respektive momentprofil. Motorn tillsammans med en förarmodell och fordonsmodell regleras för att följa körcykeln. Detta ger testdata som kan användas för att testa diagnossystemet mot i ett så realistiskt scenario som möjligt. Två stycken olika körcykler kommer i huvudsak att användas i detta projekt, NEDC respektive FTP. NEDC är den körcykel som används inom Europa då bränsleförbrukning och utsläpp jämförs mellan olika bilmodeller. FTP och är den testcykel som används i USA. Den amerikanska körcykeln är mer lik ett verkligt körscenario än den europeiska körcykeln, vilket gör den till ett bra komplement till den europeiska körcykeln [5]. 5 Diagnossystem Diagnossystemet kan delas upp i två delar: Feldetektion respektive isolering. Detektionssteget i diagnosen går ut på att identifiera fel genom att generera residualer, i isoleringssteget ska sedan de möjliga orsakerna till felet genom att utvärdera residualerna som sedan pekas ut i form av diagnoser. Slutligen kommer diagnoserna rangordnas efter vilken diagnos som med högst sannolikhet stämmer överens med observationerna med systemet. En översikt av diagnossystemet visas i Figur 2 nedan. Figur 2: En skiss över diagnossystemet LIPS Designspecifikation 10 bohli890@student.liu.se

11 5.1 Feldetektion För att detektera och isolera enkelfel i systemet kommer i första hand MATLAB-verktyget Fault Diagnosis Toolbox [1] att användas. För att använda verktyget behöver alla modellekvationer definieras som en diagnosmodell i MATLAB. Med hjälp av diagnosmodellen går det enkelt att undersöka systemets detekterbarhet och isolerbarhet för enkelfel. Det finns även ett flertal andra funktioner i verktyget som kan vara av intresse. Exempelvis finns funktionalitet som tar fram det minsta antalet sensorer som krävs för att detektera ett visst fel, samt funktionalitet för att införa begränsningar i användningen av deriverade och integrerade sensorsignaler. Autogenerering av tester Efter att de ekvationer som beskriver modellen har tagits fram och implementerats i MATLAB är nästa steg att ta fram en mängd med de tester som är möjliga. Fault Diagnosis Toolbox genererar dessa i form av en Minimal Structural Overdetermined Set (MSO) alternativt en Minimal Test Equation Support (MTES) ur vilken man sedan kan välja vilka tester man vill bilda för att grunda diagnossystemet på. Om modellen har hög redundans kan MSO inte gå att använda då storleken på MSO beror exponentiellt av modellens redundans. Om så är fallet kan MTES användas istället.[4] Val av tester Den primära metod som ska användas för att ta fram de slutgiltiga testerna går ut på att i första hand använda sig av de tester som innehåller så få ekvationer som möjligt. I praktiken väljs då först det test som innehåller minst antal ekvationer ut. Detta test kombineras sedan med det test som är byggt av så få ekvationer som möjligt, exkluderat det första. Denna metod itereras fram till det att systemets möjliga detekterbarhet och isolerbarhet har uppnåtts. Ytterligare en möjlig metod för att hantera problemet på är att implementera vad som kallas för "Greedy Approach". Denna metod går ut på att i varje steg lägga till det test som mest förbättrar isolerbarhetsprestandan till dess att systemets detekterbarhet och isolerbarhet är uppnådd. 5.2 Residualer och tröskling Antag att ett test, T(z), ska övervaka ett fel. Antag vidare att testet larmar då det överstiger en tröskel, T(z) > J. Vidare testar varje test två stycken hypoteser: H 0 : Den hypotes som går ut på att systemet är felfritt. H 1 : Den hypotes som går ut på att systemet inte är felfritt. Då finns det fyra olika scenarion som kan inträffa, vilka beskrivs av sina respektive sannolikheter enligt nedan: Inget larm syns eftersom fel inte finns, P(T(z) < J H 0 ). Fel finns och systemet larmar, P(D) = P(T(z) > J H 1 ). Missad detektion då fel finns men systemet inte larmar, P(T(z) < J H 1 ). Falsklarm då systemet larmar trots att fel inte finns, P(FA) = P(T(z) > J H 0 ). I den typ av tillämpning som undersöks i detta projekt ligger stort fokus på att minimera falsklarmssannolikheten. Ett falsklarm i denna typ av tillämpning skulle leda till att en dyr felsökning inleds trots att inget fel finns. För att en teststorhet ska larma krävs att testets tröskelvärde överskrids. Att en teststorhet antar ett värde större än dess tröskelvärde innebär att man förkastar den felfria hypotesen om systemet och istället antar en hypotes som gäller för felfallet. Ett verktyg som kan användas LIPS Designspecifikation 11 bohli890@student.liu.se

12 för att visualisera avvägningen mellan falsklarm och missad detektion är ROC-kurvor. I en ROC-kurva plottas sannolikheten att detektera fel, P(D), mot falsklarmssannolikheten, P(FA), då man varierar värdet på tröskeln, J. I regel gäller att en högre sannolikhet att detektera fel även ger en högre falsklarmssannolikhet. I det fall att motormodellen visar sig innehålla olika mängder brus vid olika arbetspunkter kommer även adaptiva trösklar att vara ett användbart verktyg. En adaptiv tröskel skulle i det här fallet kunna konstrueras genom att olika trösklar sätts för olika arbetsområden i motorn. På så sätt kan en låg falsklarmssannolikhet fås utan att en onödigt stor sannolikhet för missad detektion fås i de områden där modellen är bra. Andra metoder för att hantera denna problematik är CUSUM och GLR. Cumulative Sum För många teststorheter är det svårt att sätta en tillförlitlig tröskel, exempelvis på grund av de brusförhållanden som råder. En metod för att hantera denna problematik som lämpar sig väl då fördelningsfunktionen för ett fel är känd sedan tidigare är CUSUM. I CUSUM-algoritmen används en skattningsfunktion s(t) med följande egenskaper: E{s(t)} < 0 i H 0 E{s(t)} > 0 i H 1 Denna skattningsfunktion summeras sedan enligt g(t + 1) = g(t) + s(t). Ur detta beräknas sedan en teststorhet enligt följande två punkter: t g(t) = s(i) i=1 T(t) = g(t) min 0 i<t g(i) Då de residualer som genereras inte har de egenskaper som krävs utav skattningsfunktionen ovan införs en driftsfaktor v enligt s(t) = r(t) v. Driftsfaktorn väljs ofta så att den är i samma storleksordning som residualen r(t) är i det felfria fallet. Detta gör att skattningsfunktionen s(t) kommer att uppfylla de ovan ställda kraven. Vidare är det även möjligt att använda sig av driftsfaktorn för att sätta en adaptiv tröskel, exempelvis genom att välja värden på driftsfaktorn som varierar beroende på vilken arbetspunkt motorn arbetar i. Ytterligare ett sätt att skriva ut testfunktionen på, inklusive driftsfaktorn, är som följer: T(t) = max (0, T(t 1) + r(t) v) Slutligen sätts en tröskel J på teststorheten T enligt: T(t) < J vid H 0 T(t) > J vid H 1 Generalized likelihood ratio GLR är på samma sätt som CUSUM en metod för att hantera teststorheter som annars är svåra att sätta definitiva trösklar på. GLR är dock till skillnad från CUSUM användbar i det fall då fördelningsfunktionen för ett fel är okänd. GLR baseras på likelihoodfunktionen, L(θ z) = f(z θ), vilken kan beskrivas som sannolikheten att datan z observeras givet parametern θ. Antag att en adaptiv tröskel sätts enligt: J adp = max L(θ z)c 1 θεθ Då avvisas H 0 enligt följande teststorhet: T(z) = max θ Θ 0 L(θ z) < c max L(θ z) 1 θ Θ LIPS Designspecifikation 12 bohli890@student.liu.se

13 Utvärdering av teststorheter För att utvärdera prestandan hos de framtagna teststorheterna kan styrkefunktioner, β(θ) = P(avvisa H 0 θ) där H 0 är den felfria hypotesen och θ är felstorleken, användas. Styrkefunktioner skapas genom att ta fram sannolikheten för att ett test larmar givet en felstorlek. Styrkefunktionen plottas sedan som en funktion av felstorlek. I grafen kommer falsklarmssannolikheten att kunna läsas av där felstorleken är noll. När styrkefunktionerna har plottats för olika tester kan dessa sedan jämföras med varandra för att hitta det test som har högst prestanda med avseende på falsklarm och missad detektion. I det ideala fallet skulle man kunna ta fram styrkefunktionerna analytiskt. Det kräver dock att man gör antaganden om, exempelvis, oberoende datapunkter och gaussiskt brus. Eftersom att en är ett så pass komplext och olinjärt system kommer dessa antaganden sannolikt inte att hålla. Därför är det ett bättre alternativ att uppskatta styrkefunktionerna med hjälp av simuleringar. För att uppskatta styrkefunktioner kan följande Monte Carlo-algoritm användas: 1. Ta fram den brusfördelning som de uppmätta datapunkterna har. 2. Fixera en felstorlek θ för vilken styrkefunktionen ska beräknas. 3. Skapa en stor mängd datapunkter, z i, och beräkna teststorheten t i = T(z i ) som testas i alla dessa punkter. 4. Samla alla beräknade värden på teststorheten i ett histogram, som nu är en uppskattning av f(t θ). 5. Utnyttja steg 4 i kombination med en tröskel för att uppskatta styrkefunktionen. 6. Upprepa från steg 2 för att plotta nästa punkt av styrkefunktionen. Ytterligare en metod för att uppskatta styrkefunktioner är att utgå från mätdata. Detta kräver att det eller de fel som teststorheten är känslig för kan injiceras fysiskt i motorn. I övrigt är algoritmen mycket lik den som används för att ta fram styrkefunktioner ur Monte Carlosimuleringar. Istället för att i det första steget ta fram den brusfördelning som datapunkterna har så införs ett fel av en viss storlek. Därefter samlas ett antal mätpunkter in och används på samma sätt som de simulerade datapunkterna i Monte Carlo-simuleringarna. Eftersom falsklarm är högst oönskade i den här applikationen kommer även den uppnådda falsklarmssannolikheten att utvärderas. De värden som valts på trösklarna för de olika testerna kommer att spegla en avvägning mellan falsklarmssannolikhet och missad detektion. Analysen av falslarmssannolikhet ska alltså utvärdera huruvida den uppnådda falsklarmssannolikheten är tillräcklig. Vidare ska, om möjligt, vidareutveckling föreslås för att förbättra förhållandet mellan falsklarm och missad detektion. Metoder för att skapa teststorheter Metoderna som kommer att användas för att generera teststorheter är: Prediktionsfel, konstruktion av residualer via konsistensrelationer eller observatör, likelihoodfunktioner och parameterskattning Prediktionsfel Denna metod går ut på att använda en modells förmåga att prediktera framtida signaler för att detektera fel. En nackdel med denna metod är att modellfel kan ge missvisande resultat som leder till falsklarm. Exempel för modellvalidering kan beskrivas med ekvationen: N V(θ, z) = 1 y(t) y (t θ) N t=1 LIPS Designspecifikation 13 bohli890@student.liu.se

14 Modellvalideringsmått för modellen är M(θ 0 ). Om θ 0 är en mängd av flera värden så kan följande teststorhet göras: T(z) = min V(θ, z). θ Θ Konstruktion av residualer via konsistensrelationer eller observatör o En residual är en ekvation som i det felfria fallet kommer att vara idealt lika med noll. Den skapas genom att jämföra ett uppmätt med ett modellerat värde och när dessa två inte längre stämmer överens blir residualen nollskild vilket indikerar fel. Residualer kan antingen skapas med hjälp av konsistensrelationer eller genom att implementera observatörer. o En observatör kräver att det går att beskriva systemet på tillståndsform. En observatör skattar med hjälp av derivatan. En observatör är bättre på att hantera brus än en konsistensrelation. Derivering bör undvikas eftersom brusets påverkan blir stort. o En konsistensrelation är enkel att bilda. Det gäller att hitta samband som är relevanta mellan två ekvationer och därmed skapas redundans. Nedan följer exempel på en olinjär konsistensrelation. Betrakta följande exempel på tillståndsform. x = ax + bu y = cx Då bildas konsistenrelationen enligt nedan. y ay cbu = 0 r = 1 ) med tillståndsvariabel w p+α u w = r y w = αw (a + α)y cbu r = w + y Betrakta följande tillståndsmodel: x = f(x, u, f) y = h(x, u, f) Och på observatörsform: x = f(x, u, f) + K(y h(x, u, f) r = y h(x, u, f) Återkopplingen sker med felet, det vill säga felet mellan modellen och den uppmätta signalen. K är förstärkningen. K bestäms genom att linjärisera ekvationen kring en arbetspunkt (x 0, u 0 ). K bestämms sådant att A KC har poler i vänster halvplan. A = f x (x 0, u 0 ) och C = h x (x 0, u 0 ) där A och C ska vara observerbara. Istället för att linjärisera kring en arbetspunkt finns även möjligheten att använda andra typer av observatörer som till exempel Extended Kalman Filter (EKF). Betrakta följande diskreta tillståndsform: x t+1 = f(x t, u t, w t ) y t = h(x t, u t ) + v(t) Där w t och v t med medelvärde noll och är stokastiska med kovarianserna R t och Q t. Låt x t1 t 2 och P t1 t 2 ge tillståndsestimeringen för tiden t = t 1 till t = t 2 då blir EKF enligt följande. x t+1 t = f(x t t0, u t, 0) x (t t 1 ) = x t t 1 + K t (y t h(x t t 1, u t )) K t = P t t 1 H t T (H t P t t 1 H t T + R t ) 1 LIPS Designspecifikation 14 bohli890@student.liu.se

15 P t t = (I K t H t )P t t 1 P t+1 t = F t P t t F T T t + G t Q t G t Där F t = f x (x t, u t, 0), H t = h x (x t, u t ) och G t = f w (x t, u t, 0) Likelihoodfunktioner o Det går givet en modell att konstruera en likelihoodfunktion som beskriver hur väl uppmätt data stämmer överens med modellerad data. Till skillnad från residualer så antar dessa teststorheter stora värden för det felfria fallet och små värden för felfall. o Denna metod kräver dock att man känner till eller kan approximera täthetsfunktionerna hos de olika brus som ingår i modellen. Vidare krävs vanligen att man kan anta att all data är oberoende och normalfördelad. I gengäld är metoden mångsidig och kan exempelvis hantera fel som dyker upp som en ökning av variansen hos en signal. Om täthethetsfuktionen för bruset är känd eller kan bestämmas så är det möjligt att använda Likelihoodfuktionen för modelvaliditet. f är en täthetsfunktion som funktion av sampel Z = {Z 1, Z 2,, Z n } och likelihood som funktion av θ definieras enligt L(θ z) = f(z θ). Teststorhet kan formas som T(z) = max θ Θ 0 L(θ z). Givet en model är det möjligt med hjälp av likelihood att avgöra hur en mätning matchar modelen. Detta görs med hjälp av teststorheten T och med hypotestester Parameterskattning o Denna metod går ut på att man skattar en parameter som påverkas av något fel. Denna parameterskattning jämförs sedan med parameterns nominella värde. Utifrån detta kan en teststorhet skapas som är idealt lika med noll i det felfria fallet, och nollskild i felfallet. o Teststorheter baserade på parameterskattning har ofta bra prestanda för de beteendemoder som är relaterade till den skattade parametern. För andra beteendemoder är de dock betydligt sämre. Om alla fel modelleras med avvikelser i konstanta parametrar f i, skatta alla parametrar och jämför med deras nominella värden. f = arg min V(f, observationer) = min y ŷ 2 där V är f f modellvalideringsfunktion för modellen. 5.3 Felisolering Nedan följer ett exempel på felisolering då tre diagnostester och tre fel används. På raderna, märkta med "d" står vilket diagnostiskt test som körs. I kolumnerna står de olika felen listade, där "F" står för fel. Celler markerade med X innebär att det test som finns på raden är känsligt för motsvarande fel. Tabell 1:Exempel på beslutsstruktur multipelfel för ett system med tre teststorheter och tre fel NF F1 F2 F3 F1&F2 F1&F3 F2&F3 F1&F2&F3 d1 0 0 X X X X X X d2 0 0 X 0 X 0 X X d3 0 X X 0 X X X X LIPS Designspecifikation 15 bohli890@student.liu.se

16 Antag att det diagnostiska testet d1 har larmat. I tabell Fel! Hittar inte referenskälla. visas tt F2 och F3 är lämpliga kandidater. Man kan även se att alla multipelfel som innehåller F2 och F3 är lämpliga kandidater. Detta ger totalt F2, F3, F1&F2, F1&F3, F2&F3 och F1&F2&F3 som lämpliga kandidater. Om även d3 svarar så uppdateras tabellen med kandidater. Därmed kan till exempel inte F3 vara det enda enkla felet. Kandidater som orsakar felet blir alltså: F2, F1&F2, F1&F3, F2&F3 och F1&F2&F3. Alla kandidater uppdateras ytterligare en gång då ett nytt test larmar. Minimal Hitting Set Approach För att isolera multipelfel kan Minimal Hitting Set Approach [1] användas. Denna metod kommer ge de minimala diagnoser som kan orsaka felbeteendet. Pseudokod för algoritmen för att den ska kunna implementeras på datorn presenteras nedan. Algoritmen kan presenteras enligt följande (Kleer and Williams, 1987): S old = S forall D i S do if D i S k 1 = then Remove D i from S old forall b S k 1 do D new D i {b} forall D j S old do if D j D new then goto LABEL1 endif next S add S add {D new } LABEL1 next endif next S new S old S add Algoritmen ovan beskrivs med följande steg: 1. Initialisera ett set av minimala diagnoser till att innehålla ett tomt set. Till exempel inga fel som beskrivs som {{}}. 2. Givet en ny konflikt, kolla om minimal diagnos inte längre gäller. Till exempel att det finns ett tomt snitt med en konflikt. 3. Utöka eventuella ickegiltiga diagnoser till ett set av nya diagnoser som består av ickegiltiga diagnoser och ett element från den nya konflikten. 4. Ta bort nya diagnoser som inte är minimala. 5. Börja om från steg 2 för alla nya konflikter. LIPS Designspecifikation 16 bohli890@student.liu.se

17 5.4 Rangordning Att kunna rangordna förslag på diagnoser som förklarar ett larmat beteende har stor betydelse hos kunden. Med en vedertagen rangordning kan felsökningsarbete inom verkstäderna bli strukturellt och effektivt. De rangordningsmetoderna som i första hand kommer undersökas är sannolikhetsbaserad diagnos och fördelningsanalys med hypotestester. För att sannolikhetsmetoden skulle fungera på sitt bästa sätt krävs korrekt grundsannolikhet på felen. Denna information kan erhållas från tidigare tester eller från verkstadstekniker. Om sannolikhetsdata saknas, och man ändå önskar utforska möjligheten att använda metoden kan man anta en viss sannolikhet som utgångspunkt. Metoden med fördelningsanalys går ut på att utföra hypotestester. Jämförelse kan utföras för varje känd felfördelning med fördelningen hos det aktuella felbeteendet, och resultat kan tolkas numeriskt i form av förslagsvis ett matchningsindex. Sannolikhetsbaserad diagnos En sannolikhetsbaserad diagnos beräknar sannolikheten för en viss felmod (F) givet observationer (O) och modell (M). Nämligen: P(F M, O) Sannolikheten beskrivs av en stokastisk variabel X med värdet x i, där x i endast kan anta värdet True eller False. Sannolikheten för dem beskrivs i form av: P(X = True) och P(X = False) Ett exempel på detta som beskriver fallet då en residual har överskridit sin tröskel kan se ut som följande: P(F = f r > J) = 27.2% if f = NF 55.0% if f = f % if f = f 2 { 1.1% if f = f 1 and f 2 Sannolikhetsberäkningar kan uppdateras med inkommande information med hjälp av betingade sannolikheter: P(x y) = P(y x)p(x) P(y) Kunskapen om X uppdateras här med information att Y har värdet y. En sannolikhetsmodell för en viss variabel givet värden på andra kan beskrivas med inferensuttryck: P(x e) = P(x,e) = α P(x, e, z) P(e) z Där α är normaliseringsfaktor och bestäms ur: 1 = x P(x e) = α x P(x, e) Vid oberoende binära variabler: n P(x 1,, x n ) = P(x i ) i=1 Genom att använda ovanstående samband tillsammans med Bayesianska nätverk kan sannolikheten hos diagnoskandidaterna beräknas. Rangordningen anges här som sannolikheter i fallande ordning. Exempel: Bayesiansk nätverk som beskriver relationer mellan komponenter och larmande test: LIPS Designspecifikation 17 bohli890@student.liu.se

18 F1 F2 A R1 R2 F1: fel 1 F2: fel 2 A: larm R1: residual 1 R2: residual 2 Anta följande information är tillgänglig: P(F1) = 0,001 och P(F2) = 0,002 Figur 3 F1 F2 P(A F1, F2) A P(R1 A) B P(R2 A) Falsk Falsk 0,001 Falsk 0,05 Falsk 0,01 Falsk Sann 0,29 Sann 0,90 Sann 0,70 Sann Falsk 0,94 Sann Sann 0,95 Med tillgänglig information kan sannolikheten på F1 beräknas: P(F1 R1, R2) = α R1 R2 P(F1, F2, A, R1, R2) = α P(F1)P(F2)P(A F1, F2)P(R1 A)P(R2 A) R1 R2 = αp(f1) P(F2) P(A F1, F2) P(R1 A) P(R2 A) R1 R2 Fördelningsanalys med hypotestest Låt nollhypotesen H 0 motsvara det larmat beteende och H j (j = 0,1,2 ) motsvara alla tillgängliga kandidater som kan förklara beteendet från isoleringsalgoritmen. Låt också p 0 (y i ) vara skattning på täthetsfunktionen för det larmade beteendet, och p j (y i ) vara en skattning på täthetsfunktionen för varje kandidat, där y i är observationer. För enkla fel kan p j (y i ) tas fram från simuleringar av kandidater. En matchningsindex kan tas fram med hjälp av log-likelihoodkvoten: s j = ln p j (y i ) eller s p 0 (y i ) j = ln p 0 (y i ) p j (y i ) Placering av nämnaren och täljaren bestäms av det fallet där metoden producerar tydliga index. LIPS Designspecifikation 18 bohli890@student.liu.se

19 Kvoterna s j kan då rankas med sina numeriska signifikanser och motsvarande kandidaters rangordning framställs. 5.5 Systemarkitektur Diagnossystemet består av följande delar med tillhörande in respektive utsignaler: Förar- samt fordonsmodell o Förarmodellen tar in en körcykel som ska följas. o Förarmodellen ger tillsammans med fordonsmodellen ut varvtal, trottelvinkel samt wastegatevinkel Motor samt motormodell o Motorn samt motormodellen kräver följande insignaler: Varvtal, trottelvinkel, wastegatevinkel samt bypass o Ur dessa två delar fås de uppmätta respektive simulerade sensormätvärdena. Bypass kommer dock inte behöva regleras Residualgeneratorer o Residualgeneratorerna tar in mätvärden från motorn eller motormodellen. o Residualgeneratorerna ger ut de genererade residualerna. Tröskling o Trösklingssteget tar in residualer från residualgeneratorerna. o Trösklingssteget ger ut information om vilka tester som har larmat. Då testerna larmar ses även hur mycket residualerna är över trösklarna. Felisolering o Felisoleringssteget tar in alla de residualer som har larmat. o Utdata från isoleringssteget är de möjliga diagnoserna. Rangordning o In till rangordningssteget är alla de möjliga diagnoserna och deras egenskaper som till exempel sannolikhetsinformation eller fördelning. o Utdata kommer att vara de möjliga diagnoserna, samt en rangordning diagnoserna emellan. LIPS Designspecifikation 19 bohli890@student.liu.se

20 6 Referenser Följande källor har använts som referenser för utformning av designspecifikationen. Publicerade källor [1] T. Svensson och C. Krysander, Projektplan i Projektmodellen LIPS, 1 red., Studentlitteratur, 2011 [2] Nyberg, E. Frisk, "Model Based Diagnosis of Technical Processes", 2014 Elektroniska källor [3] (13/9-2015) [4] (22/9-2015) [5] (30/9-15) [6] A Greedy Approach for Selection of Residual Generators. Carl Svärd, Mattias Nyberg, and Erik Frisk (2011). 22nd International Workshop on Principles of Diagnosis (DX-11). Murnau, Germany. Hämtat från < 22/ Personlig kommunikation [7] Filen VEPfilesTSRT10.zip från ISY LIPS Designspecifikation 20 bohli890@student.liu.se

21 Appendix A Fabriksmonterade sensorer Motorn i testriggen är utrustad med följande sensorer från fabrik. Trycksensor efter luftfiltret. Trycksensor före gasspjället. Trycksensor i insugsröret. Temperatursensor för omgivningstemperatur. Temperatursensor för gasspjället. Luftmassflödessensor efter luftfiltret (MAF). Varvtalssensor för motorn. Vinkelsensor för vevaxeln. Positionssensor för gasspjället. Positionssensor för kamaxeln till insugsventilerna. Positionssensor för kamaxeln till avgasventilerna. Lambdasensor. Trycksensor för motoroljan. Temperatursensor för motoroljan. Temperatursensor för kylarvattnet. Bränsletryck lågtryck Bränsletryck högtryck Knacksensor. Batterispänningssensor. LIPS Designspecifikation 21 bohli890@student.liu.se