Designspecifikation.pdf. Diagnos av elkraftsystem

Designspecifikation Diagnos av elkraftsystem i satellit Version 1.0 Ansvarig utgivare: Karin Ohlsson-O hman Datum: 8 oktober 2010 Status Granskad Godka nd Kursnamn: Projektgrupp: Kurskod: Projekt: Erik Frisk Erik Frisk Reglerteknisk projektkurs, CDIO TSRT10 Diagnos av elkraftsystem 2010-10-08 2010-10-08 E-post: Ansvarig utgivare: Utgivarens E-post: Dokumentnamn: Karin Ohlsson-O hman karoh885@student.liu.se Designspecifikation.pdf

Projektidentitet Gruppens E-post: Hemsida: Beställare: Kursansvarig: Projektledare: Handledare: Erik Frisk, Linköpings Universitet Tel: +46 (0)13-285714, E-post: frisk@isy.liu.se David Törnqvist, Linköpings Universitet Tel: +46 (0)13-281882, E-post: tornqvist@isy.liu.se Karin Ohlsson-Öhman Daniel Eriksson, Linköpings Universitet Tel: +46 (0)13-28 1327, E-post: daner@isy.liu.se Gruppmedlemmar Namn Ansvarsområde Telefon E-post (@student.liu.se) Karin Ohlsson-Öhman Projektledare 070 8574863 karoh885 Emma Andersson Testansvarig 070 3908021 emman332 Kurt Källkvist Dokumentansvarig 070 4181897 kurka837 Fredrik Johansson Designansvarig 070 4547182 frejo674 Martin Kågebjer Övriga 070 2849955 marka103 Sandra Alfredsson Övriga 070 2432807 sanal785

Dokumenthistorik Version Datum Utförda ändringar Utförda av Granskad 0.1 6 okt 2010 Första utkastet alla alla 0.2 7 okt 2010 Andra utkastet SA, MK, KK, FJ KOÖ, EA 1.0 8 okt 2010 Första skarpa versionen KOÖ EF

Innehåll 1 Inledning 1 1.1 Bakgrund............................................. 1 1.2 Mål................................................ 1 1.3 Definitioner............................................ 1 2 System 2 3 Modellering 3 3.1 Batterier.............................................. 3 3.2 Reläer............................................... 3 3.3 Inverterare............................................ 4 3.4 Sensorer.............................................. 4 3.4.1 Spänningssensorer.................................... 4 3.4.2 Strömtransmittorer.................................... 5 3.4.3 Positionssensorer..................................... 5 3.4.4 Temperatursensorer................................... 5 3.4.5 Flödestransmittorer................................... 6 3.4.6 Hastighetstransmittorer................................. 6 3.5 Laster............................................... 6 3.5.1 Fläktar.......................................... 6 3.5.2 Lampor.......................................... 7 3.5.3 Pumpar.......................................... 7 3.5.4 Brytare.......................................... 7 3.5.5 Resistorer......................................... 8 4 Diagnosalgoritm 8 4.1 Teststorheter........................................... 8 4.1.1 Batterier......................................... 8 4.1.2 Reläer........................................... 8 4.1.3 Inverterare........................................ 9 4.1.4 Sensorer.......................................... 9 4.1.5 Laster........................................... 9 4.2 Trösklar.............................................. 10 4.3 Detekterbarhet.......................................... 10 4.4 Isolerbarhet............................................ 10 4.5 Robusthet............................................. 11 4.6 Beslutsstrukturer......................................... 11 4.7 Optimeringsalgoritm....................................... 11 5 DxC 11 5.1 Mjukvarubeskrivning....................................... 11 5.1.1 DxC-API......................................... 12 5.1.2 Diagnosmetodik..................................... 17

Diagnos av elkraftsystem 1 1 Inledning Detta dokument är en designspecifikation för diagnossystemet som kommer att utvecklas i projektet Diagnos av elkraftsystem i satellit. Designspecifikationen är en beskrivning av hur arbetet med framtagandet av diagnossystemet kommer att gå till och innehåller även beskrivningar av komponentmodellerna samt hur mjukvaran kommer att utformas. 1.1 Bakgrund NASA är intresserade av att undersöka olika sätt att detektera fel som inträffat i deras system. Det är till stora nytta för dem att veta vad som är fel och hur det eventuellt kan åtgärdas innan de skickar ut någon i rymden för att åtgärda felet eller tar systemet ur drift. Att snabbt kunna identifiera ett fel och vidta åtgärder, såsom nedstängning av funktioner, kan i vissa fall dessutom förhindra att följdfel uppstår. En tävling anordnas för att stödja utveckling av diagnosmetoder. Tävlingen DxC10 är den andra upplagan av tävlingen som är indelad i olika klasser: Synthetic Track och Industrial Track. Industrial Track-utmaningen är vidare indelad i två klasser, Diagnostics Problem 1 och 2. Tävlingsdeltagarna förväntas leverera en artikel samt en diagnosalgoritm som sedan testas mot DxC-mjukvaran. Detta projekt antar utmaningen i klassen Industrial Track Diagnostics Problem 2, dock ska ej denna diagnosalgoritm deltaga i tävlingen utan endast jämföras med tävlingsdeltagarnas diagnosalgoritmer. 1.2 Mål Projektets huvudmål är att skapa en så bra diagnosalgoritm som möjligt utifrån de bedömningskriterier som ställs för DxC. Det innebär främst att algoritmen ska få en så låg poäng som möjligt från DxC-mjukvaran vid utvärdering med tillgängliga testscenarier (ju lägre poäng desto bättre). Vidare ska de fel som bedömts vara detekterbara detekteras och de som bedömts vara isolerbara ska isoleras av diagnosalgoritmen i enlighet med Kravspecifikationen [Ohlsson-Öhman, 2010]. 1.3 Definitioner DxC - Diagnostics Competition, en tävling med syfte att främja forskning inom diagnos av komplexa system utlyst av NASA (National Aeronautics and Space Administration) och PARC (Palo Alto Research Center). ADAPT - Advanced Diagnostics and Prognostics Testbed, ett system NASA använder för att enkelt kunna utvärdera diagnosalgoritmer och verktyg under kontrollerade förhållanden. Systemet är uppbyggt för att efterlikna ett typiskt elkraftsystem i en satellit med olika laster, energikällor, omkopplare, omvandlare och sensorer. DA - Diagnosalgoritm, projektets produkt avsedd att diagnostisera ADAPT-systemet. DxC-mjukvara - Mjukvarupaket tillhandahållet av tävlingsarrangörerna som används för att utvärdera DA. DxC-API - Application Programming Interface, en uppsättning definitioner och funktioner för att kommunicera med DxC-mjukvaran.

Diagnos av elkraftsystem 2 2 System ADAPT-systemet består av tre stycken batterimoduler som förser systemet med elektricitet och två stycken lastbankar som består av lampor, pumpar och fläktar. Eftersom de flesta komponenterna går på växelström och batterimodulerna levererar likström finns två stycken inverterare som omvandlar 24 V likström till 120 V växelström på 60 Hz. För att kunna styra vilka delar av systemet som ska köras finns ett antal styrbara reläer. I ADAPT-systemet finns även sensorer som kan mäta till exempel ström, spänning, flöde från pumparna, rotationshastighet på fläktarna, temperatur (mäts på batterierna och vissa av lamporna) och om reläerna är slutna eller öppna. Ett kretsschema över systemet visas i Figur 1. Figur 1: Kretsschema för ADAPT-systemet

Diagnos av elkraftsystem 3 3 Modellering Eftersom diagnossystemet kommer att vara modellbaserat krävs det att modeller för komponenterna i ADAPT-systemet tas fram. Varje modell kommer att valideras mot testdata från NASA förutsatt att tillräckligt med data finns tillgängligt. Index in anger den sida om komponenten som ligger närmast batterierna och index ut anger den andra sidan. 3.1 Batterier ADAPT-systemet består av tre stycken batterimoduler. Varje modul består av två stycken seriekopplade 12 V batterier. BAT1 och BAT2 i kopplingsschemat är identiska och består av två stycken 100 Amp-hr Powersonic PS-121000U-batterier medan BAT3 består av två stycken 50 Amp-hr Exide Select Orbital ORB78DT-84. Alla batterimoduler har dock samma moder, vilka visas i Tabell 1. Då inga ideala spänningskällor existerar kan det vara nödvändigt att ta med batteriernas inre resistans i modelleringen av systemet. Om spänningen över batteriet utan last är U 0 och om en last med resistans R kopplas till batteriet fås följande ekvation: U 0 = (R 0 + R) I (1) där R 0 är batteriets inre resistans och I strömmen som flyter genom kretsen. Spänningsfallet över resistansen R blir alltså U R = R I = R U 0 (R 0 + R) (2) För en ideal spänningskälla är R 0 = 0 vilket ger U R = U 0. Problemet med att använda denna modell är dock att den inre resistansen i batterierna inte är konstant utan beror på hur mycket last som är pålagt på batteriet vilket gör att batteriets utspänning får ett mer komplext beroende av hur stor ström som dras från batteriet. Den totala spänningen över batteriet är spänningen över batteriet då det är obelastat minus spänningsfallet över den inre resistansen. Utifrån de felfria dataseten kan den inre resistansen skattas som funktion av strömmen ut från batteriet. I ADAPT-systemet finns även temperatursensorer för att övervaka batteriernas temperatur. Eftersom längden på de tillgängliga dataseten är så pass kort är det rimligt att anta att temperaturen på batterierna är konstant. Önskad spänning Tabell 1: Moder för batterierna Given spänning Mod 24V 24V Nominal 24V - AbruptParasiticLoad 3.2 Reläer Tjugofyra stycken likadana reläer finns i ADAPT-systemet. De har alla samma moder, vilka ges av Tabell 2. En styrsignal kan sluta eller öppna reläet förutsatt att det fungerar felfritt. Då reläet är slutet kommer en ström att flyta genom kretsen och reläet kan betraktas som en resistansfri ledning. Om reläet är öppet kommer ingen ström att flyta genom reläet och det kan då betraktas som ett avbrott.

Diagnos av elkraftsystem 4 Önskad position Tabell 2: Moder för reläerna Verklig position Mod Stängd Stängd NominalClosed Öppen Öppen NominalOpen - Öppen StuckOpen - Stängd StuckClosed 3.3 Inverterare I ADAPT-systemet finns två stycken likadana inverterare av typen Xantrex Prosine 1000, Part No. 806-1051, som omvandlar DC till AC-ström. Spänningen in till inverterarna ligger på 20-32 V (DC). Spänningen ut är 120 V (AC) (±3 procent), uteffekten är 1000 W och frekvensen är 60 Hz (±0.05 Hz) [Xantrex Technology Inc.]. Inverterarna har tre olika moder, vilka ges av Tabell 3. U in definieras som spänningen in till inverteraren. U ut är spänningen ut från inverteraren och I ut är strömmen ut från inverteraren. Tabell 3: Moder för inverterarna U in > 20 V U ut > 116 V I ut > 0 Mod ja ja - NominalOn nej nej nej NominalOff ja nej nej FailedOff När U in och U ut är större än specifika värden fungerar inverteraren som den ska och är i läge NominalOn. När både U in och U ut är små är inverteraren avstängd och är i läge NominalOff. Om U in är hög men U ut låg fungerar inte inverteraren utan är i läge FailedOff. I de båda senare lägena är strömmen efter inverteraren noll. Utifrån detta kan följande modell ställas upp för inverterarna: U ut = H(U in 20) 120 (3) där H är Heavisidefunktionen. Alltså, om U in är mindre än 20 V blir U ut = 0 V. Om U in är större än 20 V blir U ut = 120 V. 3.4 Sensorer ADAPT-systemet innehåller en mängd olika sensorer för att kunna övervaka systemet. Sammanlagt finns 40 sensorer bestående av AC/DC-spänningssensorer, AC/DC-strömtransmittorer, possitionssensorer, temperatursensorer, flödestransmittorer och hastighetstransmittorer. 3.4.1 Spänningssensorer I ADAPT-systemet finns sju sensorer som mäter likspänning (DC) och två som mäter växelspänning (AC). Spänningssensorerna som mäter likspänning har en samplingsfrekvens på antingen 2 Hz eller 10 Hz. Båda AC-sensorerna samplas med 2 Hz. Moderna för båda typerna av sensorer visas i Tabell 4 där U s är det mätvärde sensorn har fastnat på och d är ett offsetfel.

Diagnos av elkraftsystem 5 Tabell 4: Moder för spänningssensorerna Sensorvärde Verkligt värde Mod U U Nominal U + d U Offset U s U Stuck 3.4.2 Strömtransmittorer I ADAPT-systemet finns även sju sensorer för att mäta strömmen i olika delar av kretsen, fem stycken för likström och två stycken för växelström. Likströmstransmittorerna samplas med 2 Hz eller 10 Hz och har mätområden på 0 12.5 A eller 0 50 A. Växelströmstransmittorerna samplas med 2 Hz och har ett mätområde på 0 12.5 A. Moderna för båda typerna av sensorer visas i Tabell 5 där I s är det mätvärde sensorn har fastnat på och d är ett offsetfel. Tabell 5: Moder för strömtransmittorerna Sensorvärde Verkligt värde Mod I I Nominal I + d I Offset I s I Stuck 3.4.3 Positionssensorer Två olika typer av positionssensorer förekommer i ADAPT-systemet. Dessa används för att mäta om antingen brytare eller reläer är öppna eller slutna. Båda typerna av sensorer samplas med 10 Hz och har datatypen boolesk. Moderna för positionssensorer visas i Tabell 6. Tabell 6: Moder för positionssensorerna Sensorvärde Verklig värde Mod Öppen Öppen Nominal, Stuck(Open) Stängd Stängd Nominal, Stuck(Closed) Öppen Stängd Stuck(Open) Stängd Öppen Stuck(Closed) 3.4.4 Temperatursensorer För att övervaka temperaturen T på olika komponenter i ADAPT-systemet finns det totalt elva temperatursensorer. Alla temperatursensorer har samma samplingsfrekvens, 1 Hz och ett mätområde på -320 520 F. Moderna för temperatursensorer visas i Tabell 7 där T s är det mätvärde sensorn har fastnat på och d är ett offsetfel.

Diagnos av elkraftsystem 6 Tabell 7: Moder för temperatursensorerna Sensorvärde Verkligt värde Mod T T Nominal T + d T Offset T s T Stuck 3.4.5 Flödestransmittorer För att kunna mäta flödet Φ från ADAPT-systemets två vattenpumpar finns två stycken flödestransmittorer. Flödestransmittorerna samplas med 2 Hz och har ett mätområde på 0 600 GPH (gallons per hour). Moderna för flödestransmittorerna visas i Tabell 8, där Φ s är det mätvärde sensorn har fastnat på och d är ett offsetfel. Tabell 8: Moder för flödestransmittorerna Sensorvärde Verkligt värde Mod Φ Φ Nominal Φ + d Φ Offset Φ s Φ Stuck 3.4.6 Hastighetstransmittorer För att mäta rotationshastigheten N på de stora fläktarna finns det två stycken hastighetstransmittorer i ADAPT-systemet. Hastighetstransmittorernna samplas med 2 Hz och har ett mätområde på 0 600 000 varv per minut. Moderna för hastighetstransmittorerna visas i Tabell 9 där N s är det mätvärde sensorn har fastnat på och d är ett offsetfel. Tabell 9: Moder för hastighetstransmittorerna Sensorvärde Verkligt värde Mod N N Nominal N + d N Offset N s N Stuck 3.5 Laster Lasterna i ADAPT-systemet består av små fläktar, stora fläktar, lampor, vattenpumpar, kretsbrytare och DC-resistorer. Genom att känna lasternas nominella effekter (eller resistanser i fallet med DC-resistorer) kan lasterna modelleras med P = U I, eller U = R I där I är strömmen genom lasten, U är spänningen över lasten, R är lastens resistans och P är effekten. 3.5.1 Fläktar Två stora fläktar (LargeFan) med nominella effekten 120 W finns, en i varje lastbank. Moderna för de stora fläktarna är Nominal, Overspeed, Underspeed och FailedOff. En liten

Diagnos av elkraftsystem 7 fläkt, SmallFan, med nominella effekten 30 W finns. Moderna är Nominal och FailedOff. Fläktarna modelleras som ett första ordningens system, τ ω + ω = KI (4) där ω anger fläktens rotationshastighet, I strömmen in till fläkten, τ tidskonstanten och K stationära förstärkningen. Tidskonstanten och stationära förstärkningen antar olika värden för de olika fläktarna. 3.5.2 Lampor Systemet innehåller sex stycken lampor med nominella effekten 25 W, tre stycken med effekten 60 W och en med effekten 55 W. Moderna för samtliga lampor är Nominal och FailedOff. Lamporna modelleras även de som ett första ordningens system. Modellen ges av τt + T T omg = KP (5) där T anger lampans temperatur, T omg anger omgivningstemperaturen, P anger lampans effektutveckling, τ anger tidskonstanten och K stationära förstärkningen. K och τ har olika värden för de olika lamporna. Omgivningstemperaturen varierar mellan olika datauppsättningar och kommer därför att skattas av diagnossystemet i början av varje körning. 3.5.3 Pumpar Två likadana vattenpumpar med nominella effekten 35 W finns i ADAPT-systemet. Deras moder är Nominal, FlowRestricted och FailedOff. Pumparna modelleras genom att anta att flödet är proportionellt mot strömmen: Φ(t) = C I(t s) (6) där t är tiden, Φ är flödeshastigheten ut från pumpen, C är en proportionalitetskonstant och I är strömmen. Dessutom införs en tidsförskjutning s. 3.5.4 Brytare Två typer av kretsbrytare finns, varav den ena går att reglera med önskemål om position. De moder som är gemensamma för alla brytare är Nominal, Tripped och FailedOpen. För de reglerbara brytarna tillkommer moden StuckClosed. Kretsbrytarna är dessutom olika sinsemellan beroende på amperetal. De reglerbara kretsbrytarnas moder ges i Tabell 10. Sluten brytare = på, öppen brytare = av. Brytarna har en viss resistans när de är slutna och därför modelleras de som resistorer. Tabell 10: Moder för kretsbrytare Önskad position Verklig position Mod Sluten Sluten Nominal Öppen Öppen Tripped Sluten Öppen FailedOpen Öppen Sluten StuckClosed

Diagnos av elkraftsystem 8 3.5.5 Resistorer Två likadana DC-resistorer med nominell resistans 12 Ω finns. Dessa har moderna Nominal och FailedOff och modelleras med Ohms lag R = U I (7) 4 Diagnosalgoritm Diagnosalgoritmen kommer, utifrån mätvärden och modeller för de ingående delkomponenterna i elkraftsystemet, att detektera och isolera fel då detta är möjligt. En avvägning kommer att göras så att sannolikheten för att detektera fel är så stor som möjligt, samtidigt som sannolikheten för falsklarm är liten. Dessutom kommer systemets robusthet att analyseras och i mån av tid kommer en optimeringsalgoritm att implementeras. 4.1 Teststorheter För att testa om något fel har uppstått i elkraftsystemet används mätvärden och modeller för de olika komponenterna. Samma storhet i systemet räknas ut på två olika sätt. Det kan exempelvis vara två olika mätningar som via olika modeller beskriver samma fysikaliska storhet. Teststorheten T kommer typiskt vara en konsistensrelation som utgör skillnaden mellan dessa, som då får värdet T = 0 i felfritt läge om modellerna är korrekta. Även vissa andra tester som inte baseras på konsistensrelationer kommer att implementeras. De teststorheter som följer i detta avsnitt är tänkta att illustrera tester som i första hand riktar in sig på en enskild komponent även om de i de flesta fall kommer vara känsliga mot fel i flera olika komponenter. Utöver dessa kommer även tester som är tänkta att vara känsliga mot en större delmängd av felmoderna att skapas. 4.1.1 Batterier Batteriets utspänning kan enligt modellen beräknas som U = U 0 R 0 I där R 0 = R 0 (I). Utifrån detta kan en teststorhet ställas upp som jämför den förväntade spänningen U med ett sensorvärde för spänningen över batteriet. Om batteriets utspänning ändras på ett sätt som inte är förväntat enligt modellen kommer teststorheten att reagera. Eftersom batteriets temperatur antas vara konstant under varje dataset är det möjligt att skapa en teststorhet som jämför den uppmätta temperaturen med batteriets begynnelsetemperatur. Begynnelsetemperaturen kan beräknas genom att anta att sensorn på batteriet är felfri under de första sekunderna av datasetet och utifrån desssa beräkna ett medelvärde. Denna teststorhet kommer dock att i första hand vara lämplig för att detektera fel i sensorn eftersom ingen felmod i batteriet hör ihop med en förändrad temperatur. 4.1.2 Reläer På de reläer där en positionssensor mäter reläets läge (0 för öppet och 1 för slutet) jämförs sensorvärdet med det angivna kommandot för hur reläet ska vara ställt. Om det finns en skillnad måste antingen reläet eller sensorn vara trasig. Ytterligare ett test är T = U in U ut. Detta test kan enbart användas då reläet är angivet som slutet.

Diagnos av elkraftsystem 9 4.1.3 Inverterare För inverterarna jämförs spänningen in med spänningen ut enligt modelleringsdelen. Här används teststorheten T = U ut b(u), där b(u) är modellen för inverteraren. 4.1.4 Sensorer Alla sensorer utom positionssensorerna har ett mätbrus. Om en sensor har felmoden stuck kommer brusets varians att bli noll när felet inträffar. För att testa om en sådan sensor är i felmoden stuck görs därför en variansskattning i ett glidande fönster. Om variansen då skattas till 0 har sensorn fastnat. Variansen skattas enligt: σ 2 = 1 n 1 n (y i m y ) 2 (8) där y i anger de n senaste mätvärdena och m y är medelvärdet över y i, vilket ges av: i=1 m y = 1 n n y i (9) Testet larmar om σ 2 = 0. Detta test reagerar bara på felmoden stuck i den givna sensorn och därför isolerar testet detta fel. Ett offsetfel på temperatur- och flödessensorer testas genom att jämföra variansen av skillnaden mellan modellen och uppmätta data. Om variansen är mindre än en viss tröskel men större än en annan anses sensorn ha ett offsetfel, J 1 < T < J 2. i=1 4.1.5 Laster Utifrån kunskap om varje enskild lasts resistans och hur reläerna på en lastbank är satta kan lastbankens totala resistans bestämmas. Teststorheten ges av T = U R I där U är den uppmätta spänningen över lastbanken, I den uppmätta strömmen in till lastbanken och R lastbankens totala resistans. R kommer att vara en funktion av hur reläerna i lastbanken är satta eftersom den utgör en parallellkoppling mellan sex stycken resistorer som var och en har ett specifikt värde om det tillhörande reläet är slutet och en oändlig resistans om reläet är öppet. Om någon last eller något relä på lastbanken går sönder kommer R därför att anta ett nytt värde och testet kommer att reagera. Fläktar För de fläktar där rotationshastigheten kan mätas införs ett test T = f(i) ω där ω är den uppmätta rotationshastigheten och f(i) är modellen som utgående från strömmen som flyter genom fläkten ger skattad rotationshastighet (se modelleringsavsnittet). Strömmen som används i modellen kan i sin tur inte mätas men kan beräknas med hjälp av Ohms lag enligt I = U R där U är den uppmätta spänningen över lastbanken och R är fläktens skattade resistans. Lampor För lampor med temperaturmätning används testet T = g(p ) T lamp där T lamp anger den uppmätta temperaturen i lampan och g(p) är modellen för temperaturen som har effektutvecklingen i lampan som insignal. Effekten kan bestämmas enligt P = U 2 R där U är den uppmätta spänningen över lampan och R är lampans resistans.

Diagnos av elkraftsystem 10 Pumpar För pumpar används testet T = h(i) Φ där Φ är den uppmätta flödeshastigheten ut ur pumpen och h(i) är modellen för pumpens flödeshastighet. Strömmen bestäms här på samma sätt som för fläktar. Brytare För de ställbara brytarna jämförs den önskade positionen med den registrerade positionen. För brytare med väldefinierad in- och utspänning samt ström kan dessa jämföras enligt T = U in U ut IR. För de brytare där endast inspänningen samt strömmen är väldefinierade skapas ett test som jämför spänningen mot en viss tröskel T U > J U och strömmen mot en annan tröskel T I < J I. Resultatet av detta test ger information om huruvida någon komponent efter spänningssensorn är trasig. Det mest sannolika är att det då är brytaren som är trasig, men fallet kan även vara att samtliga pålagda laster är trasiga. Resistorer För resistorerna används testet T = U RI där U är spänningen över resistorn, I strömmen genom resistorn och R resistansen. 4.2 Trösklar På grund av att mätningar alltid är brusiga jämförs varje teststorhet T med en tröskel J, exempelvis T > J. Om då teststorhetens värde överskrider tröskeln dras slutsatsen att ett fel har uppstått. Om tröskeln väljs till ett för litet värde finns risken att diagnossystemet detekterar falska fel på grund av mätbruset. Väljs tröskeln istället för hög finns risken att fel inte detekteras alls. Trösklarna väljs som en rimlig avvägning mellan sannolikheten för att detektera ett fel och sannolikheten för falsklarm. 4.3 Detekterbarhet Allteftersom modeller för de olika komponenterna tas fram kommer dessa analyseras för att avgöra vilka fel som är detekterbara. De fel som anses vara detekterbara ska sedan kunna detekteras med hjälp av teststorheterna ovan. 4.4 Isolerbarhet Isolerbarheten kommer att analyseras utifrån de teststorheter som skapas. Isolerbarhetsanalysen kommer att illustreras med en isolerbarhetsmatris. Den algoritm som används för isolering av fel är följande: Utifrån givna gamla diagnoser är D old = D 1,..., D n och testresultatet är P i beräknas nya diagnoser D. D initieras till D = [ ]. 1. Om D j ej kan förklara P i (a) Ta bort D j ur D old. (b) Utöka D j map P i för att skapa nya diagnoser. (c) Ta bort diagnoser som ges av supermängder till redan befintliga diagnoser i D old och addera de kvarvarande till D. 2. Diagnoserna i D old läggs till i D. Algoritmen härstammar från [Nyberg, 2010]. Koden för algoritmen finns implementerad i C++ av Erik Frisk.

Diagnos av elkraftsystem 11 4.5 Robusthet Algoritmens robusthet kommer analyseras för att avgöra hur känslig den är för störningar från referenstillståndet. Dessa störningar skulle till exempel kunna vara förändrad omgivningstemperatur eller slitage av komponenter. 4.6 Beslutsstrukturer För att kunna bestämma vilka av felmoderna som kan förklara ett larm behövs kunskap om vilka olika fel varje given teststorhet reagerar på. Utifrån denna kunskap kan tänkbara felmoder bestämmas med hjälp av logik. Diagnossystemet kommer i första hand sluta sig till de mer sannolika diagnoserna. Eftersom enkelfel är mer sannolika än multipelfel kommer systemet i första hand rikta in sig på enkelfel. 4.7 Optimeringsalgoritm I mån av tid kommer även en optimeringsalgoritm att implementeras för att åstadkomma optimala värden på diagnossystemets parametrar. Med optimal menas här att poängen för systemet vid utvärdering med hjälp av DxC-mjukvaran minimeras. Parametrarna kan innefatta till exempel förstärkningar och trösklar. 5 DxC För att kunna delta i DxC-10 krävs att diagnosalgoritmen är fullt integrerbart med gränssnittet mot ADAPT-systemet, även kallat DxC-ramverket. Detta gränssnitt tillhandahålls av NASA. Till utvecklingen av diagnosalgoritmen rekommenderar NASA språken Java eller C++. För dessa språk tillhandahåller DxC-ramverket APIer för kommunikation med ramverket. Eftersom projektgruppen har mer erfarenhet av C++ kommer diagnosalgoritmen att utvecklas i detta språk. 5.1 Mjukvarubeskrivning Startpunkten i DxC-mjukvaran [Kurtoglu et al., 2010] är Scenario Loader, se Figur 2. Den ansvarar för att starta övriga moduler samt rensa upp efter avslutad körning. Scenario Data Source-modulen levererar data i form av kommandosekvenser och sensordata till DA samt information om inducerade fel till Scenario Recorder-modulen. Scenario Recorder-modulen tar hand om information om inducerade fel samt diagnosinformationen från DA och sparar denna tillsammans med tidsstämplar i en fil för vidare utvärdering. Oracle-modulen tar hand om förfrågningar från DA genom att antingen returnera billigaste responsen till en given diagnos eller returnera kostnaden för en given kombination av diagnos och respons. Diagnosalgoritmen består av en exekverbar fil som tar emot sensor- och kommandodata, analyserar dessa och skickar en diagnos till Scenario Recorder-modulen. Evaluator-modulen analyserar datafilen från Scenario Recorder och poängsätter DA utifrån en mängd prestandamått.

Diagnos av elkraftsystem 12 Scenario Loader Laddar data source, diagnosis algorithm, recorder och oracle Förfrågan Skickar sensordata och kommandonsekvens Diagnosis Algorithm Oracle Scenario Data Source Skickar diagnos Åtgärdsinformation Skickar information om injicerade fel Scenario Recorder Utdata Scenario Results Behandlas av Evaluator Figur 2: Systemöversikt av DxC-mjukvaran 5.1.1 DxC-API DxC-API definierar nio olika meddelandeklasser som alla ärver klassen DxC-Data, se Figur 3. En del av dessa klasser används endast internt i DxC-ramverket och är därmed inte av särskild vikt för implementeringen av DA. De klasser som används vid kommunikation mellan DA och DxC-ramverket beskrivs kort nedan. Diagnosalgoritmen behöver kunna skicka tre olika sorters meddelanden; Scenario-Statusmeddelanden för att indikera att DA är redo att börja diagnostisera eller att den är färdig, DiagnosisData-meddelanden som indikerar att någonting är trasigt i systemet samt vad som är trasigt och slutligen RecoveryData-meddelanden som indikerar vilka åtgärder DA anser att man bör vidta vid de diagnostiserade felen. Diagnosalgoritmen behöver även kunna ta emot fyra olika typer av meddelanden: ScenarioStatusmeddelanden för att indikera att scenariot är slut, CommandData-meddelanden med kommandosekvenser till reläerna i systemet, SensorData-meddelanden med sensorvärden från systemet samt RecoveryData-meddelanden från oraklet med åtgärdsförslag för olika diagnoser. Diagnosalgoritmen kan även skicka meddelanden av typ ErrorData om det skulle uppstå mjukvarufel i algoritmen. Detta gör det möjligt att meddela användaren om det uppstår problem i algoritmen genom att använda sig av till exempel try-catch-strukturer i programkoden eller genom att helt enkelt skicka ett felmeddelande när algoritmen kommit fel. I tabellerna nedan beskrivs meddelandeklasserna samt deras publika medlemsfunktioner och attribut. I de fall en klass har flera överlagrade funktioner som gör samma sak men använder olika inparameteruppsättningar har endast en av dessa funktioner beskrivits.

Diagnos av elkraftsystem 13 CommandData DiagnosisData FaultInjectData RecoveryData DxCData ScenarioStatusData ScenarioData SensorData ProfilingData ErrorData Figur 3: Klassdiagram för meddelandeklasserna i DxC-API

Diagnos av elkraftsystem 14 DxC::CommandData Meddelandetyp för kommandodata såsom reläpositioner och annat som kan styras i (ADAPT-) systemet. Publika funktioner: Returtyp Funktionsdeklaration CommandData(long long timestamp, const std::string &commandid, Value command Value) Konstruktor för att skapa objekt av typen CommandData. Det finns ett par konstruktorer till som accepterar andra inparametrar. const CommandoSet getcommands() Funktion för att läsa ut kommandot. void setcommands(const CommandSet&) Funktion för att sätta kommandot. virtual std :: ostream &put(std::ostram &) Skriver ut kommandodata på ett standardiserat sätt. std :: string getcommandid() Funktion för att får ut ID för kommandot. const Value getcommandvalue() Funktion för att erhålla värdet på kommandot. virtual CommandData clone() Virtuell kopieringskonstruktor. DxC::DiagnosisData Meddelandetyp för diagnoser. En diagnos består av en uppsättning möjliga fel (kandidater) viktade efter deras relativa sannolikhet. Vid skapandet av en diagnos normeras vikterna automatiskt så att totala sannolikheten för alla kandidater blir ett. En diagnos innehåller även booleska signaler som indikerar huruvida systemet har detekterat ett fel samt om felet har kunnat isoleras till en specifik felmod. Publika funktioner: Returtyp Funktionsdeklaration DiagnosisData(Timestamp timestamp, bool detectionsignal = false, bool isolationsignal = false, const CandidateSet& isolation = CandidateSet(), const std::string& notes = ) Konstruktor för att skapa objekt av typen DiagnosisData. Det finns även konstuktorer som accepterar andra inparametrar. bool getdetectionsignal() Returnerar sant om diagnossystemet anser att systemet är i faulty state. bool getisolationsignal () Returnerar sant om felet har blivit isolerat. const CandidateSet getcandidates() Läser ut felmodskandidaterna ur DiagnosisData-meddelandet. std :: string getnotes() Funktion för att hämta anteckningar angånde diagnosen. virtual DiagnosisData clone() Virtuell kopieringskonstruktor. virtual std :: ostream &put(std::ostream &) Skriver ut diagnosdata på ett standardiserat sätt.

Diagnos av elkraftsystem 15 DxC::ErrorData Felmeddelanden som kan skickas från diagnosalgoritmen till DxC utifall DA:n har råkat ut för ett mjukvarufel. Publika funktioner: Returtyp Funktionsdeklaration ErrorData(Timestamp timestamp, const std::string& error) Konstuktor för att skapa objekt av typen ErrorData. std :: string geterror() Funktion för att hämta felmeddelandet. virtual std :: ostream &put(std::ostream &) Skriver ut errordata på ett standardiserat sätt. virtual ErrorData clone() Virtuell kopieringskonstruktor. DxC::RecoveryData Meddelandetyp för åtgärder. Ett RecoveryData-meddelande kan innehålla en uppsättning hypotetiska felmoder (med skattade felparametrar), en uppsättning åtgärder för att avhjälpa felen samt kostnaden för att utföra dessa åtgärder. Publika funktioner: Returtyp Funktionsdeklaration RecoveryData(Timestamp timestamp, const FaultSet& fs = FaultSet(), const CommandSet& commands = CommandSet(), double cost = 1, const std:: string& notes = ) Konstruktor för att skapa objekt av typden RecoveryData. Det finns även konstuktorer som accepterar andra inparametrar. const FaultSet getfaults() Funktion för att hämta defekter. const CommandSet getcommands() Funktion för att hämta kommando. double getcost() Funktion för att hämta kostnaden för defekten. std :: string getnotes() Funktion för att hämta anteckningar. virtual RecoveryData clone() Virtuell kopieringskonstuktor. virtual std :: ostream &put(std::ostream &) Skriver ut återhämtningsdata på ett standardiserat sätt.

Diagnos av elkraftsystem 16 DxC::ScenarioStatusData Meddelandetyp som skickas då diagnosalgoritmen är redo att ta emot data och när diagnosalgoritmen signalerar att den är klar. Publika funktioner: Returtyp Funktionsdeklaration ScenarioStatusData(Timestamp timestamp, const std:: string& status) Konstruktor för att skapa objekt av typen ScenarioStatusData. Det finns även konstuktorer som accepterar andra inparametrar. std :: string getstatus() Funktion för att hämta status. virtual clone() ScenarioStatusData Virtuell kopieringskonstuktur. virtual std :: ostream &put(std::ostream &) Skriver ut scenariostatusdata på ett standardiserat sätt. Publika statiska attribut: Typ Namn static const std:: string SDS AWAITING DA Scenario Data Source-modulen väntar på att DA ska signalera att den är redo att börja. static const std:: string SR READY Scenario Recorder-modulen redo. static const std:: string DA READY Meddelande diagnosalgoritmen skickar när den är redo att börja. static const std:: string STARTED Scenariot påbörjat. static const std:: string SDS ENDED Scnenario Data Source-modulen är klar med scenariot. static const std:: string DA ENDED Diagnosalgoritmen är färdig. static const std:: string UNKNOWN Okänd status DxC::SensorData Meddelandetyp för sensordata med information om bland annat vilken sensor datan kommer från. Publika funktioner: Returtyp Funktionsdeklaration SensorData(Timestamp timestamp, const SensorValueMap& sensormap) Konstruktor som skapar objekt av typen SensorData. Det finns även konstruktorer som accepterar andra inparametrar. virtual std :: ostream &put(std::ostream &) Skriver ut sensordata på ett standardiserat sätt. const SensorValueMap getsensors() Funktion för att hämta mappningen från sensor till värde. virtual SensorData clone() Virtuell kopieringskonstruktor.

Diagnos av elkraftsystem 17 5.1.2 Diagnosmetodik I följande stycke beskrivs hur DA:n är tänkt att arbeta och varför den ska struktureras på ett visst sätt. XML-Systembeskrivning Diagnosalgoritm Oracle Systemmodell Isolerare Teststorheter Subdiagnoser Diagnos Teststorhetshanterare Beslutsmaskin Scenario Data Source Scenario Recorder Figur 4: Översiktlig beskrivning av den planerade strukturen för diagnosalgoritmen I Figur 4 syns den tilltänkta strukturen för DAn. Systemmodell-blocket kommer att utgöras av en bindningsgrafsliknande modell av systemet där residualer kommer att genereras genom att studera överföringsfunktioner mellan de olika sensorerna. Detta block kommer att implementeras i ett senare skede av projektet om tid finns eftersom funktionaliteten som blocket bidrar med löser krav med prioritet 3 (krav 14 i [Ohlsson-Öhman, 2010]). Även bruset kan modelleras och propageras genom modellen för användning vid teststorhetsgenereringen. Innan funktionaliteten för att automatiskt generera residualer utifrån XML-filer finns kommer dessa residualer att skapas manuellt. För att hantera residulerna skapas en egen teststorhetklass. Denna klass innehåller en funktion som beräknar själva residualen. Varje objekt av klassen måste själv veta vilka sensorer som den behöver data ifrån för att kunna göra beräkningarna. Teststorhetklassen ska även innehålla information om hur mätbruset förekommer i mätningarna samt vilka olika moder hos de olika komponenterna i systemet som residualen är känslig. Då residualerna automatgenereras kommer funktionen som beräknar residualen att anropa funktioner för de olika modellerna som i sin tur ropar på ytterligare modellfunktioner tills ett sensorvärde påträffas. Om residualen inte automatgenereras kommer teststorhetklassen peka på en funktion som är komplett nog för att beräkna residualen. Teststorhetsklassen använder om möjligt kännedom om brusets fördelning för de olika residualerna tillsammans med justerbara parametrar såsom önskad falsklarmssannolikhet för att bestämma gränsvärdena. Detta ger förhoppningsvis ett lättjusterat system som enkelt kan anpassas till olika systemkonfigurationer Teststorhetshanteraren ansvarar för att beordra teststorhetobjekten att beräkna test. Teststorhetshanteraren skickar data om vilka test som har larmat och vilken felkänslighet dessa har till Isoleraren. Objekten som innehåller denna information är av typen Subdiagnos.

Diagnos av elkraftsystem 18 Subdiagnosklassen innehåller information om vilka komponenter och dess aktuella felmoder. Isoleraren tar in data från Teststorhetshanteraren i form av Subdiagnoser och anropar isoleringsalgoritmen för att få fram en optimal diagnos. Diagnosen skickas sedan vidare som objekt av den (av DxC-API) redan specifierade klassen DiagnosisData som beskrivs i sektion 5.1.1. Slutligen använder Beslutsmaskinen diagnoserna för att skapa RecoveryData-objekt (se sektion 5.1.1) som skickas till oraklet för att bestämma lämplig åtgärd och kostnad för den diagnosen. Utifall flera olika diagnoser förekommer jämförs sedan kostnad och sannolikhet för de olika diagnoserna innan det bästa alternativet väljs ut och returneras i form av RecoveryData och DiagnosisData. Enkelfel kommer att anses vara mer sannolika än dubbelfel. Eftersom teststorheter som är känsliga för felfritt läge (NF) kan förekomma väljs denna diagnos som mest sannolik om den förekommer i mängden av möjliga diagnoser. En beskrivning av de viktigaste klasserna och dessa publika funktioner finns nedan. Varje klass kommer dessutom att ha ett antal privata funktioner och attribut. Projektet kommer även att innehålla ett antal hjälpklasser för att till exempel hantera indata från ScenarioDataSource-modulen samt klasser för komponenter och sensorinformation. TestQuantity Klass som beskriver en teststorhet. Beräknar en residual och jämför värdet med en tröskel. Publika funktioner: Returtyp Funktionsdeklaration TestQuantity(Funktionspekare residual, const DataMap datamap, const double slowestsamplerate, const double sigma, const vector<component > errorcomponents, const vector<sensorinfo> sensorinfo) Konstruktor för att skapa objekt av typen TestQuantity. Det finns även konstuktorer som accepterar andra inparametrar. bool CalculateTest() Funktion för att beräkna teststorheten. double GetResid() Funktion för att hämta värdet på residualen som användes vid senaste teststorhetsberäkningen. int GetSlowestSampleRate() Funktion för att hämta långsammaste samplingsfrekvensen som används i teststorhetsberäkningen. vector<component> GetErrorComponents() Funktion för att hämta ErrorModes. double GetSigma() Funktion för att hämta sigma. double CalculateTreshold(const double alpha) Funktion för att hämta beräkna tröskelvärde.

Diagnos av elkraftsystem 19 TestQuantityManager Klass som hanterar teststorheter. Publika funktioner: Returtyp Funktionsdeklaration TestQuantityManager(const vector<testquantity>:: iterator testquantities, const Isolator isolator) Konstruktor för att skapa objekt av typen TestQuantityManager. Det finns även konstuktorer som accepterar andra inparametrar. void RunTest() Funktion för att beräkna teststorheten. SubDiagnosis Klass som beskriver en subdiagnos. En subdiagnos består av namn på komponenter och vilka moder hos dessa som kan ha fått teststorheten att larma. Publika funktioner: Returtyp Funktionsdeklaration SubDiagnosis(const vector<component> errorcomponents) Konstruktor för att skapa objekt av typen SubDiagnosis. Det finns även konstuktorer som accepterar andra inparametrar. list <int> GetErrorComponentId Funktion för att hämta Id för komponenten. list <list<std:: string>> GetErrorModes Funktion för att hämta felmoderna till komponenten. Isolator Klass som beskriver en isolator. Isolatorn använder sig av subdiagnoser för att köra isoleringsalgoritmen och översätter resultatet till DxC::DiagnosisData-objekt. Publika funktioner: Returtyp Funktionsdeklaration Isolator () Konstruktor för att skapa objekt av typen Isolator. void AddSubDiagnosis(SubDiagnosis subdiagnos) Funktion för att lägga till subdiagnoser i isoleringsalgoritmen. RecoveryManager En klass som utifrån tillgägngliga diagnoser samt oraklets åtgärdsförslag till dessa fattar ett beslut om vilken åtgärd och diagnos som ska skickas till DxC::ScenarioRecorder-modulen. Publika funktioner: Returtyp Funktionsdeklaration RecoveryManager() Konstruktor för att skapa objekt av typen RecoveryManager. void AddDiagnosis(DxCDiagnosisData diagnos) Funktion för att lägga till diagnoser.

Diagnos av elkraftsystem 20 Referenser T. Kurtoglu, S. Narasimhan, S. Poll, D. Garcia, L. Kuhn, J. de Kleer, and A. Feldman. Second international diagnostic competition (dxc 10). http://www.phmsociety.org/ sites/phmsociety.org/files/wp10-dxc.pdf, Maj 2010. hämtad: 2010-09-20. M. Nyberg. A generalized minimal hitting-set algorithm to handle diagnosis with behavioral modes. Systems, Man and Cybernetics, Part A: Systems and Humans, IEEE Transactions on, PP(99):1 12, 2010. ISSN 1083-4427. doi: 10.1109/TSMCA.2010.2048750. K. Ohlsson-Öhman. Kravspecifikation diagnos av elkraftsystem i satellit. September 2010. Xantrex Technology Inc. Prosine 1000/1800. http://www.go2mhz.com/specimages/ Statpower/Prosine%201000%20and%201800%20revA.PDF, 2003. hämtad: 2010-09-15.