Institutionen för systemteknik
Department of Electrical Engineering
Examensarbete
Modellering av uppdragsberäkningar i JAS 39
Gripen
Examensarbete utfört i Reglerteknik vid Tekniska högskolan i Linköping
av
Mattias Lager
LiTH-ISY-EX--09/4200--SE
Linköping 2009
Department of Electrical Engineering Linköpings tekniska högskola
Linköpings universitet Linköpings universitet
Modellering av uppdragsberäkningar i JAS 39
Gripen
Examensarbete utfört i Reglerteknik
vid Tekniska högskolan i Linköping
av
Mattias Lager
LiTH-ISY-EX--09/4200--SE
Handledare: Per-Johan Nordlund
isy, Linköpings universitet
Sven Öberg
SAAB Aerosystems AB
Examinator: Martin Enqvist
isy, Linköpings universitet
Avdelning, Institution
Division, Department
Division of Automatic Control Department of Electrical Engineering Linköpings universitet
SE-581 83 Linköping, Sweden
Datum Date 2009-05-18 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport
URL för elektronisk version
http://www.control.isy.liu.se http://urn.kb.se/resolve?urn=urn:nbn:se:liu:diva-ZZZZ ISBN — ISRN LiTH-ISY-EX--09/4200--SE
Serietitel och serienummer
Title of series, numbering
ISSN
—
Titel
Title
Modellering av uppdragsberäkningar i JAS 39 Gripen Mission Calulation Modeling for JAS 39 Gripen
Författare
Author
Mattias Lager
Sammanfattning
Abstract
In JAS 39 Gripen there are functions, collectively called mission calculations, which inform the pilot about the expected amount of fuel and time that is required to complete the current mission. The mission calculation segment is big and complex and by making a model of the mission calculations, one can easily simulate and verify it before a change is applied in reality. In this master’s thesis, a model of the mission calculations code has been implemented in MATLAB/Simulink.
During this thesis, a fuel calculation core and an acceleration function have been modeled. In connection with the modeling, general modeling methods have been developed for common data objects and functionalities in the code, such as variables, loops and if conditions. A large part of the work has been dedicated to validation of the model against the original code. In the future, an automated validation process would be preferable, to enhance the efficiency of the modeling work.
Improvements of the current mission calculations have been presented and in-vestigated. For example, static and dynamic models of a model error have been created by linear regression and system identification theory. When these models were used, the difference between the models’ predicted fuel flow and the measured fuel flow decreased. Some of the improvements are easy to implement in today’s code and others require much more reconstruction before implementation. The current mission calculation segment has been complicated to model in Simulink. Therefore, a concept proposal on how to redesign mission calculations and enhance the compatibility with Simulink is presented.
Nyckelord
Keywords MATLAB, Simulink, System identfication toolbox, Stateflow, Konfektionsmodel-ler, Black box, Regression, Modelleringsmetoder
Abstract
In JAS 39 Gripen there are functions, collectively called mission calculations, which inform the pilot about the expected amount of fuel and time that is required to complete the current mission. The mission calculation segment is big and complex and by making a model of the mission calculations, one can easily simulate and verify it before a change is applied in reality. In this master’s thesis, a model of the mission calculations code has been implemented in MATLAB/Simulink. During this thesis, a fuel calculation core and an acceleration function have been modeled. In connection with the modeling, general modeling methods have been developed for common data objects and functionalities in the code, such as vari-ables, loops and if conditions. A large part of the work has been dedicated to validation of the model against the original code. In the future, an automated validation process would be preferable, to enhance the efficiency of the modeling work.
Improvements of the current mission calculations have been presented and inves-tigated. For example, static and dynamic models of a model error have been created by linear regression and system identification theory. When these models were used, the difference between the models’ predicted fuel flow and the measured fuel flow decreased. Some of the improvements are easy to implement in today’s code and others require much more reconstruction before implementation. The current mission calculation segment has been complicated to model in Simulink. Therefore, a concept proposal on how to redesign mission calculations and enhance the compatibility with Simulink is presented.
Sammanfattning
I JAS 39 Gripen finns funktioner, kallade uppdragsberäkningar, som informerar piloten om hur mycket bränsle och tid som förväntas gå åt för att slutföra det aktuella flyguppdraget. Uppdragsberäkningsdelen är stor och komplex och genom att göra en modell av uppdragsberäkningarna kan man enklare simulera och ve-rifiera dem innan införandet av en ändring. I detta examensarbete har en modell av koden implementerats i MATLAB/Simulink.
Under arbetet har en bränsleberäkningskärna och en accelerationsberäkningsfunk-tion modellerats. I samband med modelleringen har modelleringsmetoder utveck-lats för vanligt förekommande dataobjekt och funktionaliteter i koden, såsom va-riabler, loopar och if-satser. En stor del av arbetet har handlat om validering av modellen mot originalkoden. Valideringen är något som skulle behövas automati-seras för att effektivisera modelleringsarbetet.
Förbättringar av de befintliga uppdragsberäkningarna har föreslagits och under-sökts. Till exempel har statiska och dynamiska modeller av ett modellfel skapats med hjälp av multipel linjär regression och systemidentifieringsteori. Då dessa mo-deller användes minskade skillnaden mellan momo-dellernas skattade bränsleflöde och det verkliga bränsleflödet. En del av förbättringarna som presenteras är enkla att implementera i befintlig kod medan andra kräver betydligt mer anpassning. Da-gens uppdragsberäkningar har visat sig komplicerade att modellera i Simulink. I slutet av rapporten presenteras ett konceptförslag, baserat på ett reglertekniskt angreppsätt, på hur uppdragsberäkningarna skulle kunna omarbetas för att passa Simulink bättre.
Tack
Jag skulle vilja börja med att tacka Sven Öberg för din handledning genom hela arbetet. Examinator Martin Enqvist vill jag tacka för att du har kommit med idéer under arbetet och hjälpt till att höja nivån på rapporten. Jag skulle också vilja tacka Jonas Palm och Per-Johan Nordlund för era kommentarer som lyfte rapporten. Simon Daniel och Daniel Nordgren på SAAB, för att ni tog er tid och hjälpte mig med MATLAB/Simulink-problem.
Fredrik Lindsten skulle jag vilja tacka för dina råd och tips, men framförallt för ditt trevliga sällskap under examensarbetet.
Jag skulle vilja tacka mamma och pappa för ert stöd under hela utbildningen, inte minst under examensarbetet. Mest av allt vill jag tacka Anna för det otroligt stora stödet jag fått från dig, Tack!
Innehåll
1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Mål . . . 2 1.3 Begränsningar . . . 3 1.4 Rapportens disposition . . . 3 2 Systemöversikt 5 2.1 Innan flygning . . . 5 2.2 Strukturen i systemdatorn . . . 5 2.3 Kraftmodell . . . 6 2.4 Flygenvelopp . . . 8 2.5 Medlemsvariabler . . . 8 2.6 Huvudprogrammet i uppdragsberäkningarna . . . 9 3 Teori om systemidentifiering 13 3.1 Grundläggande tidsdiskret teori . . . 133.2 Skattning av linjära dynamiska modeller . . . 13
3.2.1 Konfektionsmodeller . . . 14
3.2.2 Estimering – Minimering av prediktionsfelen . . . 15
3.2.3 Validering . . . 17
3.3 Multipel linjär regression för statiska modeller . . . 18
3.3.1 Vektorform . . . 19
4 Modelleringsmetoder 21 4.1 Programvara som använts under arbetet . . . 21
4.1.1 MATLAB . . . 21
4.1.2 Simulink . . . 21
xii Innehåll
4.1.3 Stateflow . . . 22
4.1.4 System identification toolbox . . . 22
4.2 Val av komplexitet vid modellering . . . 23
4.2.1 Trådar och standardblock . . . 23
4.2.2 Fcn . . . 24
4.2.3 Embedded MATLAB Fcn . . . 24
4.2.4 MATLAB Fcn . . . 25
4.2.5 S-Fcn builder och S-Fcn . . . 26
4.2.6 Slutsatser . . . 26
4.3 Modellering av konstanter och variabler i Simulink . . . 27
4.3.1 Lokala konstanter och lokala variabler . . . 27
4.3.2 Globala konstanter och globala variabler . . . 28
4.3.3 Slutsatser och kommentarer . . . 30
4.4 Tabellslagning . . . 30
4.5 If-satser . . . 31
4.6 Loopar . . . 33
4.7 Kommentarer och slutsatser . . . 35
5 Modellering av bränsleberäkningskärna 37 5.1 Bransle_Ber . . . 38 5.2 TempIsa0_Ber . . . 39 5.3 Temp_Ber . . . 39 5.4 Get_PFD_Model_Pressure . . . 39 5.5 Dyn_Tryck_Ber . . . 39 5.6 Dragkraft . . . 40 5.7 Get_Fuel . . . 42 5.8 BsleOK_fcn . . . 42 5.9 Validering . . . 43 6 Modellering av acceleration 45 6.1 BsleDragk . . . 46 6.2 SP_Interpol . . . 46 6.3 VVind_Ber . . . 47 6.4 Temp_Ljud_Vind . . . 47
6.5 Funktionalitet hos Acceleration . . . 47
Innehåll xiii
7 Undersökningar av förbättringar 51
7.1 Antal iterationer av modellen
Inducerat_motstand . . . 52
7.2 Tre varianter av bränsleflödesberäkningar . . . 57
7.2.1 Jämförelse av metoderna och nuvarande kod . . . 66
7.3 Återskapning av 6:e-gradspolynomet . . . 67
7.3.1 Regression för 6:e-gradspolynomet . . . 68
7.3.2 Validering . . . 69
7.4 Skattning av statisk modell . . . 70
7.4.1 Regression - i statisk modell . . . 71
7.4.2 Validering av statiska modeller . . . 73
7.5 Skattning av dynamisk modell . . . 74
7.5.1 Validering av dynamiska modeller . . . 75
7.5.2 Korrektionsmodellens inverkan på bränsleberäkningsresultatet 78 7.6 Förenkling i Newtons andra lag . . . 80
7.7 Antagande om konstant flygplansmassa vid bränsleflödesberäkningar 81 7.8 Ny variant av uppdragsberäkningar . . . 84
7.8.1 Beskrivning av komponenterna . . . 85
8 Slutsatser och fortsatt arbete 87 8.1 Slutsatser . . . 87
8.2 Fortsatt arbete . . . 88
Litteraturförteckning 89
Kapitel 1
Inledning
1.1
Bakgrund
1982 fick SAAB i uppdrag av regeringen att ta fram ett flygplan som kunde ersätta flygvapnets dåvarande Viggensystem. Det nya planet skulle ha förmågan att kun-na byta roller mellan jakt-, attack- och spaningsuppdrag utan att behöva landa. Dessutom skulle det vara hälften så tungt som Viggen, hälften så dyrt i drift men ha minst lika bra prestanda och lastkapacitet. Uppdraget - som har kallats det mest avancerade utvecklingsprojektet inom svensk industri - resulterade i JAS 39 Gripen, ett förhållandevis litet flygplan med en ny typ av elektroniskt styrsystem. Gripen styrs med fly-by-wire, det vill säga det finns ingen mekanisk koppling mel-lan styrspaken och roderytorna. Ett sådant system ställer naturligtvis höga krav på styrdatorn, som alltid måste fungera. Dessutom utrustades Gripen med en rör-lig nosvinge som gav annorlunda styregenskaper. 1996 var JAS 39 Gripen redo att levereras till det svenska flygvapnet. Numera har även Tjeckien, Ungern, Sydafri-ka, Thailand och Storbritannien köpt eller hyrt planet, och flera andra länder har visat intresse. En bild på Gripen-flygplan kan ses i figur 1.1. Mer om Gripen finns att läsa i [11] och [3].
SAAB har huvudansvaret för utveckling och tillverkning av Gripenplanet. På af-färsenheten Aerosystems i Linköping, där examensarbetet har utförts, utvecklar man bland annat funktioner som beräknar tid- och bränsleåtgång. Dessa funktio-ner används för att informera piloten om hur mycket bränsle som kommer att gå åt för att flyga klart det aktuella uppdraget och landa. Uppdragsberäkningsdelen är stor och komplex och genom att göra en modell av uppdragsberäkningarna kan man enklare simulera och verifiera dem innan införandet av en ändring.
Uppdragsberäkningarna är skrivna i programmeringsspråket Pascal D80/D96 som
2 Inledning
Figur 1.1. Fyra JAS 39 Gripen-plan som flyger i formation. Fotograf: Katsuhiko
Toku-naga, Copyright Gripen International.
är en blandning mellan Pascal och ADA83. Pascal D80/D96 är ett starkt typat språk som inte tillåter några omdefinieringar av datatyperna, utan alla datatyper måste definieras innan kompilering. Däremot tillåts nästlade funktioner, det vill säga att funktioner kan innehålla andra subfunktioner [1].
1.2
Mål
Målet med examensarbetet är att skapa en modell av det nuvarande systemet för bränsleberäkningar och sedan implementera modellen i MATLAB/Simulink. Många av ekvationerna som används för beräkningar är inte dokumenterade nå-gonstans förutom i själva koden. Koden är idag svåröverskådlig men genom att modellera funktionaliteterna så blir den tydligare. Modellen kan också vara an-vändbar vid framtagning av framtida versioner av Gripen. För att kunna uppnå målet är det nödvändigt att utarbeta metoder för modellering av kodens data-objekt och operationer (t.ex. variabler, loopar, tabellslagning). I de fall då det är möjligt ska modellerna valideras med data som samlats in från riktiga flygningar. Slutligen ska eventuella förslag på förbättringar av dagens uppdragsberäkningar presenteras.
1.3 Begränsningar 3
1. Studera dagens beräkningar av bränsle och tid för planerade uppdrag genom att studera specifikationer och källkod.
2. Skapa en modell för tid- och bränsleåtgång i Simulink utifrån nuvarande kod. Modellen ska enkelt kunna modifieras till olika kundbehov.
3. Validera mot insamlade bränsledata från flygningar och jämföra med dagens lösning.
4. Föreslå förbättringar av dagens uppdragsberäkningar.
1.3
Begränsningar
Modelleringen sker endast i ett modelleringsprogram (MATLAB/Simulink), det vill säga någon jämförelse mellan olika program sker inte i detta arbete. Det är orimligt att försöka modellera alla delar av uppdragsberäkningssystemet inom ramen för ett examensarbete och därför har de mest centrala delarna – bränsle-beräkningskärna och acceleration – valts ut. Flygplanet antas färdas i planflykt i samtliga delmodeller, det vill säga stigning/dykning och svängar har inte model-lerats. De grafiska gränssnitten som förser piloten med information har inte heller behandlats i detta arbete.
1.4
Rapportens disposition
Rapporten har följande upplägg:
Kapitel 2 ägnas åt systemöversikt. Här presenteras en mer detaljerad beskrivning
av uppdragsberäkningssystemet och dess uppbyggnad och flygplanets kraftmodell beskrivs.
Kapitel 3 innehåller teori om systemidentifiering. Skattning och validering av
modellerna, samt teori kring multipel linjär regression behandlas i detta kapitel.
Kapitel 4 behandlar de program som har använts i arbetet. MATLAB, Simulink,
Stateflow och System Identification Toolbox beskrivs. I kapitlet beskrivs de mo-delleringsmetoder som har utarbetats för modellering av Pascalkodens dataobjekt och operationer.
Kapitel 5 redogör för modelleringen av bränsleberäkningskärnan och dess
under-modeller.
4 Inledning
Kapitel 7 innehåller förslag på förbättringar av det nuvarande systemet för
bränsle-beräkningar. Effekten av de olika förbättringsförslagen har undersökts i Simulink och resultaten från dessa undersökningar presenteras.
Kapitel 8 innehåller de slutsatser som dragits under examensarbetet och förslag
Kapitel 2
Systemöversikt
2.1
Innan flygning
Innan flygning planerar piloten sitt uppdrag genom att lägga in ett tiotal punk-ter på den rutt han eller hon önskar flyga i ett planeringsverktyg. Piloten anger bland annat punkternas longitud, latitud och altitud, det vill säga var på kartan och vid vilken höjd man önskar flyga. Piloten anger också med vilken hastighet man önskar flyga mellan punkterna. Piloten har möjligheten att planera in andra sorters punkter så som attackpunkter, spaningspunkter och även punkter för luft-tankning. I detta examensarbete kommer ingen särbehandling att ske mellan de olika punkterna. När rutten är färdigplanerad sparas alla punkter ner i en datas-tav som piloten tar med sig ut till flygplanet innan start. Väl i flygplanet laddas uppdraget från datastaven in i systemdatorn där uppdragsberäkningarna utförs. Punkterna binds samman med linjer som utgör rutten från startbasen till land-ningsbasen. Mellan punkterna i uppdraget beräknas en höjdprofil där det är mest ekonomiskt att flyga. På hög höjd är luftmotståndet lägre än på låg höjd. Det är alltså mer lönsamt att flyga en längre sträcka i lägre luftmotstånd än att flyga kortaste sträckan i högre luftmotstånd.
2.2
Strukturen i systemdatorn
I systemdatorn finns det ett tiotal olika mjukvaruenheter (eng. Software unit) och bränsleberäkningar ligger i Mission Data Management (MDM). Utöver MDM, som behandlas i detta examensarbete, finns det andra mjukvaruenheter som till exem-pel Weapon System (WES) och Primary Flight Data (PFD) som ansvarar för lasten respektive flygdata såsom mätvärden för vinklar och temperatur. I
6 Systemöversikt
ruenheten MDM finns det ett antal undersegment där uppdragsberäkningen finns som ett eget segment kallat Mission Calculation (MC). Förutom MC finns det två andra undersegment, Mission Data (MD) och Mission Handling (MH), vars hu-vudfunktioner är att läsa in och bearbeta uppdragspunkter respektive bygga ihop punkterna till rutter. MC arbetar inte själv utan kommunicerar med andra mjuk-varuenheter för att utbyta information. Till exempel hämtar MDM information om omgivande temperatur hos PFD. I figur 2.1 kan delar av systemdatorns struktur studeras. Det är delar ur segmentet MC som har modellerats i detta arbete.
MDM MC MH MD SU SU PFD WES
Figur 2.1. Strukturen hos systemdatorn. Uppdragberäkningar (MC) är en del av
mjuk-varuenheten Mission Data Management (MDM). MC kommunicerar med andra mjukva-renheter, till exempel Primary Flight Data (PFD) och Weapon System (WES).
2.3
Kraftmodell
Koordinatsystemet som används är ett högerorienterat ortonormerat bassystem där X-axeln pekar i nosens riktning, Y-axeln ut i höger vinge och Z-axeln ner från flygplanets undersida. Anfallsvinkeln α är definierad från flygplanets referen-saxel till dess hastighetsvektor, vilket syns i figur 2.2. Flygplanets kursvinkel χ används också i uppdragsberäkningarna och definieras som vinkeln mellan norr och flygplanets hastighetsvektor i ett tänkt plan som är parallellt med marken. Om flygplanet flyger rakt österut är kursvinkeln 90 grader. Figur 2.3 visar hur kursvinkeln definieras.
Både bränsleberäkningarna i koden och i modellerna använder endast den longi-tudinella kraftmodellen, det vill säga krafter i x-led och z-led och rotationer kring y-axeln. Rotationer är dock inget som används i beräkningarna då momentet antas vara noll. De krafter som verkar på flygplanets masscentrum är lyftkraft, luftmot-stånd, dragkraft och tyngdkraft, vilket kan ses i figur 2.4. I luftmotståndskraften är det inducerade luftmotståndet inkluderat. Denna kraft uppstår när luft strömmar runt vingspetsarna på grund av tryckskillnaden mellan ovansida och undersida [9].
För Gripen är lyftkraft, luftmotstånd och dragkraft uppmätta experimentellt för olika hastigheter och höjder. Dessa värden är tabellerade och används vid upp-dragsberäkningen.
2.3 Kraftmodell 7
Y
X
Z
Hastighetsvektor
Figur 2.2. Definiton av koordinatsystem och anfallsvinkeln α. Anfallsvinkeln är vinkeln
mellan hastighetsvektorn och x-axeln. Bilden på flygplanet kommer från SAAB AB.
Norr
Hastighetsvektor
Figur 2.3. Definition av kursvinkeln χ. Kursvinkeln är vinkeln mellan hastighetsvektorn
och norr. Bilden på flygplanet kommer från SAAB AB.
I beräkningen av bränsleflödet används två olika fall, ett är då flygplanet befinner sig i ett stationärt tillstånd, det vill säga att flygplanet befinner sig i kraftjämvikt och den resulterande kraften är noll. Det andra fallet är då flygplanet accelererar och den resulterade kraften är skild ifrån noll.
Bränsleflödet definieras som den bränslemängd som sprutas in i motorn under en viss tidsenhet, vanligen en sekund. Som enhet för att mäta bränslemängden används massa (kg) framför volym (m3) då massan förblir konstant för olika tem-peraturer, vilket inte är fallet för volymen. Bränsleflödet beräknas och mäts alltså i enheten kg/s.
8 Systemöversikt
Lyftkraft
Dragkraft
Tyngdkraft Luftmotstånd
Figur 2.4. Kraftmodellen som används i koden och i modellerna. De krafter som används
är dragkraft, luftmotståndskraft, lyftkraft och tyngdkraft. Flygplanets masscentrum ut-gör angreppspunkt för krafterna. Bilden på flygplanet kommer från SAAB AB.
2.4
Flygenvelopp
Flygenveloppen (från engelskans flight envelope) är det område som beskriver flyg-planets prestanda, dess maximala och minimala hastigheter för olika höjder. En schematisk bild över en flygenvelopp kan ses i figur 2.5. Vid full gas accelere-rar flygplanet tills luftmotståndet blir för stort och motorn inte orkar accelerera flygplanet ytterligare. Luftmotståndet är mindre för högre höjder och därför har flygplanet sin maxhastighet på hög höjd (1 i figuren). Det finns även en nedre gräns för hur långsamt flygplanet kan flyga innan det överstegrar (eng. stall) och tappar lyftkraft. Vid lägre hastigheter krävs en högre anfallsvinkel för att lyftkraf-ten ska vara större än tyngdkraflyftkraf-ten och vid tillräckligt stor anfallsvinkel inträffar ett fenomen kallat överstegring då flygplanet tappar stora delar av sin lyftkraft (2 i figuren). Lyftkraften från vingarna blir lägre på hög höjd och så småningom uppnås ett jämviktsläge där tyngdkraften motsvarar lyftkraften och flygplanet inte kan stiga ytterligare (3 i figuren) [5].
2.5
Medlemsvariabler
Ett uppdrag är uppbyggt av ett antal punkter och varje punkt har ett antal med-lemsvariabler. I dessa medlemsvariabler är det bland annat lagrat hur långt det är till nästa punkt, samt vilken höjd och vilken hastighet som flygplanet ska hålla mellan punkterna. Förutom den förinlagda informationen från
planeringsverkty-2.6 Huvudprogrammet i uppdragsberäkningarna 9
Hastighet
Höjd
1
2
3
Figur 2.5. Schematisk bild över flygenveloppen. (1) och (2) är den övre respektive nedre
gränsen för flygplanets hastighet. (3) anger gränsen för hur högt flygplanet kan flyga.
get finns det bland annat variabler för flygplansmassa, bränslemängd, bränsleflöde och kompensationstillägg för svängar, sidovindar och andra faktorer som påverkar bränsleförbrukningen. En schematisk bild av medlemsvariablerna i en uppdrags-punkt visas i figur 2.6.
Medlemsvariabler Höjd Sträcka Hastighet Vindriktning Vindhastighet Massa Alfa Dragkraft Bränsleåtgång ...
Figur 2.6. För varje punkt i ett uppdrag finns det medlemsvariabler, några av dem visas
i rutan till höger i figuren.
2.6
Huvudprogrammet i uppdragsberäkningarna
Huvudprogrammet består av ett antal olika delar som exekveras olika ofta. Den del som exekveras oftast behandlar inläsningar av sensordata från mjukvaruen-heten PFD och exempel på sensordata är omgivande temperatur, anfallsvinkel,
10 Systemöversikt
flygplanets position och höjd. Genom att exekvera denna del oftare än den andra delen så säkerställs att sensordata alltid är uppdaterade när uppdragsberäkningar utförs. I den del som exekveras lite långsammare sker uppdragsberäkningarna. Be-räkningar utförs i en punkt i taget, eller rättare sagt för sträckan mellan punkten och nästkommande punkt, med hjälp av informationen i medlemsvariablerna och ett antal hjälpfunktioner. Hjälpfunktionerna beräknar bidrag som kompenserar för bland annat svängar, acceleration, sidovindar och för flygning på olika höjd istället för kortaste vägen. Bidragen består av tid, sträcka och bränsleåtgång och sparas i den aktuella medlemsvariabeln.
Om flygplanet inte flyger exakt längs den planerade rutten så går det åt mer bränsle och flygplansmassan blir inte densamma som planerat vid punkterna. Därför görs dessa uppdragsberäkningar kontinuerligt. Flygplanet själv kan ses som en punkt i uppdraget och beräkningarna startar från flygplanspunkten och itererar vidare längs uppdraget till landningsbasen. När alla punkter är beräknade summeras deras bidrag till en total beräknad bränsleåtgång som sedan presenteras för piloten på skärmarna. En översiktsbild hur huvudprogrammet är uppbyggt visas i figur 2.7.
2.6 Huvudprogrammet i uppdragsberäkningarna 11
MD
MH
MC
Planflykt
Acceleration
Stigning
Svängar
Tid, stäcka och
bränsleåtgång mellan
två punkter.
= Total bränsleåtgång
Figur 2.7. En flygrutt är uppbyggd av ett antal uppdragspunkter som läses in i
segmen-tet Mission Data (MD). I segmensegmen-tet Mission Handling (MH) binds uppdragspunkterna samman. I segmentet Mission Calculation (MC) beräknas sedan tids- och bränsleåtgång för en sträcka i taget. Först beräknas bränsleflödet som om rutten skulle flygas utan höjd- och hastighetsvariationer (Planflykt). Därefter beräknas den extra tid, sträcka och bränslemängd som går åt till bland annat acceleration och svängar. Alla dessa bidrag summeras ihop för en punkt för att slutligen summeras för alla punkter.
Kapitel 3
Teori om systemidentifiering
3.1
Grundläggande tidsdiskret teori
Signalerna som används i detta arbete är samplade versioner av en kontinuerlig signal. Den tidskontinuerliga signalen betecknas med y(t) och samplas likformigt med sampeltiden T vilket ger:
y(kT ) = y(tk), k = 0, 1, 2, ... (3.1)
där T är sampeltiden och k är indexet på samplet.
Istället för att skriva ut en tidsförskjutning med tiden T kommer skiftoperatorn
q att användas. Skiftoperatorn q tidsförskjuter signalen som den opererar på med
sampeltiden T och q−1 ger negativ tidsfördröjning. Operatorn definieras enligt [7] som:
qu(kT ) = u((k + 1)T )
q−1u(kT ) = u((k − 1)T ) (3.2)
3.2
Skattning av linjära dynamiska modeller
Vid modellering av mer invecklade system är det inte säkert att man har full insyn i alla delar av systemet. Därför kan fysikalisk modellering vara svår och mödosam att åstadkomma. De systemkomponenter som är okända kan modelleras hjälp av metoder för systemidentfiering, förutsatt att man har tillgång till mätningar av
14 Teori om systemidentifiering
systmets in- och utsignaler. Utifrån dessa kan det okända systemet skattas och det finns två grundtyper av parametriska modeller [7].
1. Skräddarsydda modeller. Om modellen delvis är känd, det vill säga de fysikaliska grundprinciperna är kända men inte alla parametrar, är detta till-vägagångssätt att föredra. Parametrarna har oftast i detta fall en fysikalisk tolkning och denna modellkategori brukar även kallas för grey-box.
2. Konfektionsmodeller. Om systemet som ska modelleras är helt okänt och man endast har tillgång till in- och utsignaler kan denna kategori av modeller väljas. Konfektionsmodeller är väldigt flexibla och modellparametrarna får i allmänhet ingen direkt fysikalisk tolkning, mer än att de beskriver systemets egenskaper. Denna kategori kallas också för black-box och är den typ av parameterskattning som används i detta arbete och beskrivs mer i kommande avsnitt.
3.2.1
Konfektionsmodeller
De linjära konfektionsmodeller som används här har alla enligt [7] strukturen:
y(t) = G(q, θ)u(t) + H(q, θ)e(t), (3.3)
där y(t) är utsignalen, u(t) är insignalen, e(t) är vitt brus, G(q, θ) och H(q, θ) är överföringsfunktioner, q är skiftoperatorn och θ är parametervektorn. Om G(q, θ) och H(q, θ) i (3.3) ersätts med B(q)/F (q) respektive C(q)/D(q) kan modellen skrivas på följande form
y(t) =B(q) F (q)u(t) +
C(q)
D(q)e(t) (3.4)
där täljar- och nämnarpolynomen i de tidsdiskreta överföringsfunktionerna är
B(q) = bnkq −nk+ b nk+1q −nk−1+ ... + b nk+nb−1q −nk−nb+1, C(q) = 1 + c1q−1+ c2q−2+ ... + cncq−nc, D(q) = 1 + d1q−1+ d2q−2+ ... + dndq−nd, F (q) = 1 + f1q−1+ f2q−2+ ... + fnfq −nf. (3.5)
Parametervektorn θ i (3.3) innehåller koefficienterna bi, ci, dioch fii ovanstående
3.2 Skattning av linjära dynamiska modeller 15
nf och nk där de fyra första anger antalet parametrar som B, C, D och F
-polynomen ska innehålla. nk anger hur många sampel som insignalen till modellen
ska tidsfördröjas. Tidsfördröjningen blir nk multiplicerat med sampeltiden T .
Utifrån den generella ekvationen (3.4) kan fyra vanliga specialfall härledas.
ARX-modellen y(t) = B(q)A(q)u(t) +A(q)1 e(t)
I detta fall sätts F (q) = D(q) = A(q) och C(q) sätts till 1. På så vis erhålls ARX-modellen ovan som är den enklaste ARX-modellen att skatta parametrar till, eftersom de går att beräkna med linjär regression. Nackdelen med ARX är att störningarna inte får en egen dynamik utan följer samma dynamik som systemet. I figur 3.1 visas strukturen för ARX-modellen.
ARMAX-modellen y(t) = B(q)A(q)u(t) +C(q)A(q)e(t)
Det som skiljer ARMAX från ARX är att ARMAX har en bättre störningsmodell för bruset än ARX eftersom C(q) inte måste vara satt till 1. Det är dock samma dynamik, A(q), för bruset som för systemet även i detta fall. Denna modell och ARX är lämpliga att använda då störningen kommer in tidigt, vanligtvis med insignalen. Strukturen för ARMAX visas i figur 3.2.
Output-Error-modellen y(t) = B(q)F (q)u(t) + e(t)
OE-modellen fokuserar på att beskriva systemdynamiken till fullo och modellerar inte störningsmodellen alls. Modellen erhålls genom att sätta C(q) och D(q) i (3.4) till 1. Om man inte är intresserad av att modellera störningarnas inverkan är denna modell lämplig. Strukturen för Output-Error-modellen visas i figur 3.3.
Box Jenkins-modellen y(t) = B(q)F (q)u(t) +D(q)C(q)e(t)
Box-Jenkins-modellen är den mest generella och inga förenklingar har gjorts ifrån den allmänna beskrivningen i (3.4). Box Jenkins-modellen beskriver störningarna separat från systemdynamiken, vilket ger möjlighet till en bättre beskrivning. På grund av sin komplexitet är den mer beräkningskrävande än de tidigare beskrivna modellerna. Denna modell är lämplig att välja om störningar kommer in sent och inte består av enbart vitt brus. Strukturen för Box Jenkins-modellen visas i figur 3.4.
3.2.2
Estimering – Minimering av prediktionsfelen
Vid anpassning av modeller till verkliga data krävs ett mått på hur bra modellen är. För detta används det så kallade prediktionsfelet
(t, θ) = y(t) − ˆy(t | θ) (3.6)
16 Teori om systemidentifiering
+
e
B
1/A
u
y
Figur 3.1. ARX-strukturen. Brus- och systemmodellen har gemensamma poler A(q).
+
e
B
1/A
u
y
C
Figur 3.2. ARMAX-strukturen. Brus- och systemmodellen har gemensamma poler A(q)
precis som i modellen men ARMAX har ett C-polynom för bruset vilket inte ARX-modellen har.
+
e
B/F
u
y
Figur 3.3. OE-strukturen. Brusmodellen skattas inte alls med denna modell utan all
beräkningskraft ägnas åt systemmodellen.
+
e
B/F
u
y
C/D
3.2 Skattning av linjära dynamiska modeller 17
beror på tiden t och parametervektorn θ. Hur ˆy(t | θ) beräknas beskrivs på sidan
284 i [7].
Prediktionsfelet anger hur stor avvikelsen är mellan den verkliga utsignalen och modellens predikterade utsignal i varje tidpunkt. För att få ett mått som väger samman samtliga sampel i den tillgängliga mätsekvensen studeras medelkvadrat-felet. Medelkvadratfelet defineras enligt [7] som
VN(θ) = 1 N N X t=1 2(t, θ). (3.7)
Parametervektorn θ beskriver modellen och därför sökes det θ som minimerar
VN(θ) och gör att skillnaden mellan den verkliga utsignalen och den predikterade
blir så liten som möjlig. Den skattade parametervektorn blir således
ˆ
θN = arg min θ
VN(θ). (3.8)
Det optimala värdet på θ går att finna med hjälp av olika metoder, så som linjär regression och iterativ sökning. Endast ARX modellens parametrar går att finna med linjär regression, de andra tre modellerna kräver iterativ sökning, vilket är mer beräkningskrävande än linjär regression. De data som användas för att bestämma parametervektorn θ kallas estimeringsdata.
3.2.3
Validering
För att avgöra hur bra modellen beskriver systemet krävs validering. Estimerings-data bör inte användas igen, utan ny Estimerings-data bör användas för validering. Om samma data används för estimering och validering och om modellordningen väljs för hög finns det risk att modellen blir överanpassad till estimeringsdata. Detta leder till ett lägre värde på VN(θ) utan att det beskriver systemet bättre. För att avgöra
hur bra modellen stämmer överens med det verkliga systemet simuleras modellen med insignaler från valideringsdata. Ett mått på hur bra följning det är mellan skattningen och den verkliga mätningen efter simuleringen är modellanpassningen
µF it, som enligt [8] definieras som
µF it= 100 1 −k y − ˆy k k y − ¯y k , (3.9)
där ˆy är det skattade värdet från modellen, y är mätvärdet från utsignalen och ¯y
18 Teori om systemidentifiering
Modellanpassningen µF itär ett mått angivet i procent, där 100 % motsvarar
per-fekt följning mellan modell och mätdata. Om modellen får 0 % i modellanpassning innebär det att den passar lika bra som att ange medelvärdet för mätsignalen. Det finns ingen nedre begränsning, således kan modellen få negativ modellanpassning.
En kompletterande metod att validera modellen kan vara att studera korskovari-ansen mellan prediktionsfelet (t) och insignalen u(t). Korskovarikorskovari-ansen ska vara nära noll om de är oberoende. Om de inte är okorrelerade kan det tyda på att det finns information i (t) som härstammar från u(t), det vill säga att alla beroenden inte har fångats upp av modellen. Skattningen av korskovariansen definieras enligt [6] som ˆ Ru(τ ) = 1 N N X t=1 (t + τ )u(t) (3.10)
där N är antal sampel och τ är en tidsförskjutning.
Även kovariansen hos prediktionsfelen (t) för olika tidpunkter är intressant att studera då den visar hur pass korrekt störningsmodellen är. Om störningsmodellen är helt korrekt ska prediktionsfelen endast bestå av vitt brus och vara nära noll för alla τ 6= 0. Kovariansen normaliseras ofta så den ligger mellan -1 och 1 och då kallas den korrelation. Skattningen av kovariansen defineras enligt [6] som
ˆ R(τ ) = 1 N N X t=1 (t + τ )(t). (3.11)
3.3
Multipel linjär regression för statiska
model-ler
Teorin i detta avsnittet kommer från [2] och multipel linjär regression används för att linjärt beskriva observationen Y med hjälp av förklaringsvariablerna (X1, X2, . . . , Xk) enligt:
Yj= β0+ β1Xj,1+ β2Xj,2+ . . . + βkXj,k+ ηj,
j = 1, 2, . . . , N. (3.12)
Kolonnvektorn β innehåller regressionskoefficienter (β0, . . . , βk) och ηj är bruset
som antas vara oberoende och normalfördelat enligt ηj∼ N (0, σ2).
3.3 Multipel linjär regression för statiska modeller 19
E[Yj] = β0+ β1Xj,1+ β2Xj,2+ . . . + βkXj,koch
V (Yj) = σ2
för j = 1, 2, . . . , N
(3.13)
För att finna vektorn β som beskriver observationerna Y bäst skapas Q enligt
Q(β) = N X j=1 (Yj− E[Yj])2= N X j=1 (yj− β0+ β1Xj,1+ β2Xj,2+ . . . + βkXj,k)2 (3.14)
Om antalet sampel N är fler eller lika med antalet okända parametrar kan β skattas med hjälp av minstakvadratmetoden och ˆβN kan skrivas som
ˆ
βN = arg min β
Q(β). (3.15)
Multipel linjär regression används för att skatta parametrar till statiska modeller men även till dynamiska modeller såsom modeller. I fallet med en ARX-modell innehåler β koefficenterna a1, a2, . . . , ana, b1, . . . , bnb och X består av
−y(t − 1), −y(t − 2), . . . , −y(t − na), u(t − nk), . . . ,u(t − nk− nb+ 1) [7].
3.3.1
Vektorform
Modellen ovan i (3.12) kan också beskrivas på vektorform där
y1 y2 .. . yN är observationer av Y1 Y2 .. . YN = 1 x1,1 x1,2 · · · x1,k 1 x2,1 x2,2 · · · x2,k .. . ... ... . .. ... 1 xN,1 xN,2 · · · xN,k β0 β1 β2 .. . βk + η0 η1 η2 .. . ηN (3.16)
20 Teori om systemidentifiering
Under förutsättningen att det(XTX) 6= 0 så kan en skattning ˆβN erhållas med
hälp av minstakvadratmetoden enligt
ˆ
βN = (XTX)−1XTY . (3.17)
Under examensarbetet har uttrycket ovan använts för att skatta parametrarna i
Kapitel 4
Modelleringsmetoder
4.1
Programvara som använts under arbetet
4.1.1
MATLAB
MATLAB är ett datorprogram som är utvecklat av MathWorks och som är väl lämpat för beräkningar och simuleringar. Namnet MATLAB är en sammanslag-ning av början från MATrix och LABoratory, vilket speglar det ursprungliga an-vändningsområdet - matrisoperationer. Alla variabler representeras som matriser. Utöver matrisoperationer finns det många inbyggda funktionaliteter i MATLAB. Bland annat innehåller det ett eget programmeringsspråk och bra stöd för visua-lisering. MATLAB används flitigt i den akademiska världen men även i industrin, bland annat för reglerteknik samt signal- och bildbehandling. I den första halvan av examensarbetet har MATLAB-versionen 2007b använts och under andra halvan användes 2008b. SAAB uppdaterade MATLAB från 2007b till 2008b på samtliga datorer då 2008b släpptes.
4.1.2
Simulink
MathWorks utvecklar även ett tilläggsprogram kallat Simulink, där man i en gra-fisk miljö kan koppla samman olika funktionsblock. Simulink har färdiga bibliotek för många funktioner men det går även skriva egna funktioner i MATLAB och an-vända som ett block i Simulink. I Simulink är det möjligt att skapa ett godtyckligt antal undermodeller i en modell, det vill säga det går att skapa modeller som har djup. Modellerna kan då kategoriseras på ett naturligt sätt, till exempel så att en delkomponent i modellen är en egen undermodell. Detta ger en bättre överblick
22 Modelleringsmetoder
över modellen som dessutom kan automatkonverteras till C-kod så att varje un-dermodell blir en underfunktion i den genererade koden. Automatgenerering kan göras med hjälp av tilläggsprogrammet Real-Time Workshop som MathWorks har producerat. De versioner av Simulink som använts under arbetet är först 7.0 och sedan 7.2.
4.1.3
Stateflow
Ett tilläggsprogram till Simulink är Stateflow, vilket främst används för modelle-ring och simulemodelle-ring av diskreta tillstånd i Simulink. Tillståndsmaskinen implemen-teras antingen som sanningstabeller eller som flödesdiagram och båda kan infogas som en undermodell i Simulink. I sanningstabellen anges villkor och konsekven-ser för respektive villkor. Flödesdiagrammet, se figur 4.1, byggs via ett grafiskt gränsnitt där flödesdiagram ritas med hjälp av tillståndsrutor. Det går dessutom att infoga vägskäl och kopplingar i diagrammet. Kopplingar förbinder tillstånden och vägskälen så ett diagram erhålls. Längs kopplingar går det placera villkor som måste vara uppfyllda innan ett byte av tillstånd sker. Vid simulering markeras vil-ket tillstånd som är aktivt och vilken koppling som följs. I diagrammet går det att infoga så kallade inbyggda MATLAB-funktioner och Simulinkmodeller som kan ses som hjälpfunktioner. I det förstnämnda fallet skrivs MATLAB-kod som sedan anropas via ett funktionsanrop i ett tillstånd eller längs en koppling. Simulink-modeller anropas på samma sätt som för inbyggda MATLAB-funktioner men är byggda i Simulink istället för skrivna i kod. Detta innebär att Stateflowdiagram-met kan användas på toppnivå och undermodeller av Simulink och även Stateflow kan byggas inuti diagrammet. Stateflow kan kommunicera med MATLAB genom att läsa och skriva till MATLABs workspace. Genom att definiera in- och utsig-naler kan Stateflowdiagrammet kommunicera med ovanliggande Simulinkmodell. De versioner av Stateflow som använts under arbetet är först 7.0 och sedan 7.2.
4.1.4
System identification toolbox
System identification toolbox, SITB, är ett tilläggsprogram till MATLAB som an-vänder sig av systemidentifieringsteorin som beskrivs i kapitel 3. Programmet har stöd för att importera dataserier både från tid- och frekvensdomänen samt för att bearbeta data genom att exempelvis subtrahera medelvärden och filtrera. Det går att estimera linjära och olinjära modeller och bland de linjära går det välja om det ska vara en skräddarsydd modell eller en konfektionsmodell. Det räcker med att ange ordningstalen för den valda modellen och sedan beräknar programmet den modell som passar bäst. Vid validering visas en graf med den uppmätta sig-nalen och det simulerade resultatet för de skattade modellerna tillsammans med passningsgraden. Kovariansen och korskorrelationen presenteras också i grafer och polnollställediagram kan visas. Den version av SITB som har använts under exa-mensarbetet är 7.2.1.
4.2 Val av komplexitet vid modellering 23
Figur 4.1. Ett flödesdiagram från Stateflow 7.2. Flödesdiagramet byggs med hjälp av
tillstånd (här betecknade one och two) och kopplingar (pilar).
4.2
Val av komplexitet vid modellering
En funktion skriven i Pascal D80/D96-kod kan modelleras på olika sätt i Simulink och frågan är vilken modelleringsmetod som lämpar sig bäst? Målet med arbe-tet har varit att finna så tydliga modeller som möjligt och metoderna som har studerats är följande
• Trådar och standardblock, se avsnitt 4.2.1 • Fcn, se avsnitt 4.2.2
• Embedded MATLAB Fcn, se avsnitt 4.2.3 • MATLAB Fcn, se avsnitt 4.2.4
• S-Fcn builder och S-Fcn, se avsnitt 4.2.5
Den översta, trådar och standardblock, är den enda som inte kräver att kod skrivs manuellt. De övriga metoderna består av programmerbara block.
4.2.1
Trådar och standardblock
Detta är den mest intuitiva metoden av dem alla och på varje block står det beskri-vet vilken funktionalitet blocket har, vilket gör att det blir tydligt för användaren.
24 Modelleringsmetoder
En nackdel med denna metod är den lätt blir komplex och svåröverskådlig eftersom varje funktionalitet kräver ett eget block och antalet block ökar således snabbt. Ett exempel på denna metod ses i figur 4.2.
Fördelar: Intuitivt för enklare modeller.
Nackdelar: Blir snabbt komplext och svåröverskådligt.
Figur 4.2. Trådar och standardblock implementerade i Simulink.
4.2.2
Fcn
Fcn-blocket är det enklaste av de programmerbara blocken. Vid programmering skrivs koden in i en dialogruta och dessvärre går det endast att skriva in en rad kod. Det finns endast en ingång och en utgång för signalerna, för fler in- och utsignaler krävs muxar och demuxar, vilket syns i figur 4.3. Detta gör att Fcn-blocket inte är särskilt användbart. Det är bättre att använda trådar och standardblock eller det något mer avancerade blocket Embedded MATLAB fcn som beskrivs i nästa avsnitt. Fcn-blocket har inte använts i modelleringsarbetet.
Fördelar:
-Nackdelar: En ingång och en utgång och endast en rad kod.
Figur 4.3. Fcn-blocket.
4.2.3
Embedded MATLAB Fcn
Embedded MATLAB Fcn-blocket tillhör också de programmerbara blocken, men till skillnad från Fcn-blocket går det programmera mer än en rad. Genom att
4.2 Val av komplexitet vid modellering 25
dubbelklicka på blocket kommer ett nytt fönster med MATLABs texteditor upp. MATLABs felsökningsverktyg (eng. debugger) finns med i texteditorn, vilket un-derlättar vid eventuell felsökning. In- och utsignaler måste först deklareras och sedan får blocket in- och utgångar med det deklarerade namnen, vilket kan ses i figur 4.4. Att antalet in- och utgångar går att bestämma och även möjligheten att namnge dem medför att modellen blir lättöverskådlig. I koden går det att anropa interna och externa funktioner men dessvärre har inte embedded MATLAB Fcn stöd för alla MATLAB-funktioner, som exempelvis arrayhantering och möjlighe-ten att skriva till globala variabler. Embedded MATLAB Fcn går inte enbart att använda i Simulink utan även i Stateflow och om all kod ska kapslas in i modellen är detta block lämpligt att välja.
Fördelar: Det går att namnge och bestämma antalet in- och utsignaler. Nackdelar: Saknar stöd för bland annat globala variabler och arrayer.
Figur 4.4. Embedded MATLAB Fcn-blocket.
4.2.4
MATLAB Fcn
För att kunna använda globala variabler måste MATLAB Fcn-blocket användas. Med denna modelleringsmetod går koden ej att skriva direkt i blocket, som med embedded MATLAB Fcn. Blocket anropar istället en extern funktion som måste skrivas i en separat MATLAB-fil. Detta gör att blocket blir kraftfullt eftersom det har samma funktionalitet som MATLAB, men tappar i överskådlighet. Det blir osmidigt att växla mellan Simulink och MATLAB vid modellering och felsökning. Antalet insignaler går inte att välja utan en insignal är standard och om fler önskas krävs en multiplexer, vilket kan ses i figur 4.5.
Fördelar: Klarar av globala variabler.
Nackdelar: Koden måste skrivas i MATLAB.
26 Modelleringsmetoder
4.2.5
S-Fcn builder och S-Fcn
Dessa block är de mest kraftfulla av de programmerbara blocken. De är främst lämpliga att använda då modellen innehåller kontinuerliga och diskreta tillstånd samt regulatorer som inte tillhör standardregulatorerna. Koden kan skrivas i C, C++, Ada, MATLAB eller Fortran, vilket är bra eftersom många regulatorer som implementeras i verkliga system med stor sannolikhet är skrivna i något av de språken. En nackdel med S-Fcn builder och S-Fcn blocken är att det krävs en del arbete och inställningar för att blocken över huvud taget ska fungera. Dessa block har inte behövt användas i detta arbete. En översiktsbild på blocken visas i figur 4.6.
Fördelar: Hanterar kontinuerliga tillstånd.
Nackdelar: För komplex vid enklare användningsområden.
Figur 4.6. S-Function-block och S-Function builder.
4.2.6
Slutsatser
Undersökningen av de olika modelleringsmetoderna har visat att det inte lönar sig att välja en mer komplex metod än vad uppgiften kräver eftersom det endast leder till att modellen blir mer svåröverskådlig. Det är därför lämpligt att välja en så enkel metod som möjligt, men givetvis måste blocken klara av sin uppgift. Om den del som ska modelleras kräver fler än 3-5 standardblock är embedded MA-TALB Fcn ett bättre val, eftersom standardblocken snabbt blir oöverskådliga. Då globala variabler används i modelleringen måste MATLAB Fcn blocket användas eftersom endast det har stöd för skrivning till globala variabler. Om en för stor del av koden som ska modelleras implementeras i ett programmerbart block så tappar modellen sin modularitet. Det blir svårare att studera interna signaler och att ersätta en delmodell. Ett extremfall är att implementera hela originalkoden i ett enda block, vilket inte skulle ge någon vinst alls gentemot den ursprungliga lösningen. I varje enskilt fall måste en bedömning ske av vilken komplexitet som ska väljas för att få en så överskådlig modell som möjligt. Det medför att modellen inte blir helt konsekvent i sin uppbyggnad. För att enklare kunna jämföra mellan
4.3 Modellering av konstanter och variabler i Simulink 27
originalkoden och modellen kan varje funktion i koden modelleras som egen mo-dell eller undermomo-dell. Det medför dock att man inte utnyttjar Simulink till fullo eftersom Simulink lämpar sig bättre för att modellera fysikaliska system än kod.
4.3
Modellering av konstanter och variabler i
Si-mulink
Den kod som modelleras är som de flesta andra program uppbyggd med hjälp av konstanter och variabler. Det är inte helt trivialt hur dessa konstanter och variabler ska representeras i Simulink. Konstanter och variabler kan delas upp två huvudkategorier, globala och lokala, där de globala är de som nås av alla funktioner. De lokala däremot är endast tillgängliga inom funktionen och kallas även medlemsvariabler. De två huvudkategorierna som studeras närmare är:
• Lokala konstanter och lokala variabler, se avsnitt 4.3.1. • Globala konstanter och globala variabler, se avsnitt 4.3.2.
4.3.1
Lokala konstanter och lokala variabler
En konstant som endast den egna funktionen har tillgång till kallas alltså lokal konstant. I Simulink kan de realiseras på olika sätt och ett av sätten är att låta modellen innehålla konstanterna. Konstanternas värde matas då in direkt som parametrar till blocken, vilket gör att inga externa MATLAB-filer krävs. Med detta sätt blir det snabbt oöverskådligt vad varje parameter är inställd på och dessutom är det lätt att glömma ett block om en konstant ska uppdateras. För att undvika detta problem kan konstanten först definieras i MATLABs workspace och sedan länkas till konstanten från varje block. Att definiera konstanten direkt i MATLABs workspace kan medföra en del svårigheter. Följande två problem kan exempelvis uppstå:
1. Det blir konflikt om samma konstant finns i fler funktioner men har olika värden.
2. Det blir väldigt många konstanter på samma nivå i MATLABs workspace.
Det första problemet går att undvika genom att applicera funktionsnamnet som prefix på konstanten, ‘Funktionsnamn_Konstantnamn’, men detta tillvägagångs-sätt löser inte problem nummer två. Genom att istället organisera konstanter i da-tastrukturer, så kallade ‘structs’, kan båda problemen undvikas. Till varje funktion
28 Modelleringsmetoder
definieras en egen datastruktur och för att det inte ska vara samma namn på funk-tionen och dess datastruktur används ‘Funktionsnamn_Struct’ på datastrukturen. Exempel på datastruktur är Dragkraft_Struct som innehåller de funktionsspeci-fika konstanterna.
Lokala variabler är de enklaste av de fyra dataobjekten att modellera i Simulink, eftersom varje funktion i originalkoden modelleras som en modell eller undermo-dell. Variablerna kan då modelleras som en signal som förbinder blocken. Om antalet lokala variabler inte är för många fungerar detta sätt bra.
4.3.2
Globala konstanter och globala variabler
I originalkoden består de globala konstanterna och variablerna av skalärer, ta-beller eller datastrukturer. Datastrukturerna innehåller i sin tur skalärer, tata-beller eller ytterligare nivåer av datastrukturer. För att underlätta jämförelsen mellan originalkoden och modellerna har originalkodens struktur på variabler och kon-stanter bibehållits i modellerna. För att inte skriva över variabler och konkon-stanter av misstag om de ligger direkt på workspace har de i detta arbete kapslats in i en datastruktur kallad för ‘Global_Struct’. Om samma metod som för lokala va-riabler (se avsnitt 4.3.1) hade applicerats på globala vava-riabler skulle modellerna drunkna av trådar som var dragna kors och tvärs. Detta är ingen hållbar lösning och därför har några standardblock studerats, för att med hjälp av dem komma runt problemet.
Konstant-blocket fungerar bra för konstanter som är skalärer eller matriser.
Blocket kan inte hantera datastrukturer och inte heller variabler då det är ämnat för just konstanter. En bild på Konstantblocket visas i figur 4.7.
Figur 4.7. Konstant-blocket som finns i Simulink.
From/to workspace-blocken visade sig inte vara lämpliga för att representera
globala konstanter och variabler i Simulink. Blocken måste förses med vektorer med alla värden för hela simuleringen. Det går inte läsa och skriva till samma vek-tor och det är inte särskilt smidigt att skapa vekvek-torer som passar exakt till längden på simuleringen. Dessa block är lämpliga att använda då modeller ska förses med extern mätdata och då man vill spara undan simuleringsresultat. Blockens utse-ende visas i figur 4.8.
4.3 Modellering av konstanter och variabler i Simulink 29
Figur 4.8. From/To workspaceblocken som finns i Simulink. Dessa är lämpliga att
an-vända då modellen ska förses med mätdata och även då simuleringsresultatet ska sparas.
I Embedded MATLAB Fcn kan den globala strukturen ‘Global_Struct’ anges som parameter då dess kod skrivs. Dessvärre kan inte Embedded MATLAB Fcn ändra datastrukturer, vilket gör att detta block inte fungerar för variabler utan endast för konstanter.
Read/Write blocken är lämpliga för att hantera variabler men blocken klarar
in-te av datastrukturer. Variabler som är skalärer och matriser fungerar problemfritt med dessa block. Bild på Read/Write-blocken kan ses i figur 4.9.
Figur 4.9. Read- och Write-blocken som finns i Simulink. För att kunna användas krävs
det att variabeln deklareras, vilket sker i det översta av de tre blocken.
Bussobjekt är något som MathWorks rekommenderar för modellering av
data-strukturer, men det har visat sig vara lite krångligt att få objekten att fungera. I det skapade bussobjektet sparas utöver de definierade variablerna och konstan-terna även en hel del information om objektet. I MATLAB går det bara att se att variablerna och konstanterna finns, men inte vilka värden som de är satta till. Detta gör modelleringsarbetet mindre överskådligt och objekten blir mer svårhan-terliga.
Eftersom varken standardblocken eller bussobjektet uppfyller önskemålen om bi-behållen struktur och lättöverskådlighet har det i detta arbete designats ett block för läsning och ett för skrivning. Blocken bygger på MATLAB Fcn-blocket (se av-snitt 4.2.4) som har stöd för globala variabler, vilket utnyttjats i både läsnings- och skrivningsfunktionen. Koden är skriven i MATLAB och i funktionsargumentet i Simulink anges vilken variabel eller konstant som man önskar uppdatera eller läsa. I funktionsargumentet kan även blockets insignal användas, vilket är bra vid till exempel hämtning av temperatur i väderbiblioteket på en specifik höjd där höjden
30 Modelleringsmetoder
är insignal till blocket. En nackdel med dessa block är att de inte kan användas om modellen ska automatkonverteras till C-kod. Att modellen ska vara lättöver-skådlig vid simulering har prioriterats högre än att modellen ska vara optimal vid automatgenering av C-kod. Exempel på egenskrivna Read- och Write-block visas i figur 4.10.
Figur 4.10. De egenskrivna Read- och Write-blocken. Dessa bygger på
MATLAB-Fcn-blocket men innehåller egenskriven kod. Då ingen insignal används bör inporten kopplas till ett groundblock som signalerar att modellen är färdigbyggd, vilket syns till höger i figuren.
4.3.3
Slutsatser och kommentarer
Variabler är en naturlig del av programmeringsspråket Pascal D80/D96 men de är svåra att modellera i Simulink eftersom det inte finns några lämpliga motsva-righeter. Detta visar på att Simulink inte är avsett för modellering av kod. Vid simulering fungerar de egenskrivna blocken tillräckligt bra, men om modellen ska konverteras till C-kod måste datastrukturen slätas ut så att alla variabler och konstanter ligger fritt i MATLABs workspace. En annan lösning vore att använda bussobjekten, men de är svåröverskådliga och det krävs en del arbete för att defini-era objekten. Något som är svårt i Simulink är att bestämma exekveringsordningen vid läsning och skrivning, vilket kan leda till olika beteende i originalkoden och Simulinkmodellen. Om en variabel i koden ska uppdateras innan den används av en annan funktion finns risk för att proceduren sker i omvänd ordning i Simulink, det vill säga att funktionen först använder variabeln och att den först därefter uppdateras.
4.4
Tabellslagning
Olinjära samband beskrivs ofta i originalkoden med hjälp av en tabell och tabellen är ofta baserad på mätningar. Ett exempel på tabellerade samband är luftmot-ståndskoefficienter som funktion av flygplanets hastighet. Resultatet interpoleras fram mellan två närliggande tabellposter.
4.5 If-satser 31
Den linjära interpolationen beräknas som
y3=
y2− y1 x2− x1
x3+ y1. (4.1)
I koden hittas de närliggande x-värdena (x1och x2) med hjälp av loopar om tabel-len inte är ekvidistant. Om tabeltabel-len är ekvidistant divideras x3 med steglängden och det erhållna talet avrundas sedan neråt för att finna x1. x2 hittas genom att addera steglängden till x1. När x1 och x2 är funna hämtas y1 och y2 ur tabellen för att sedan interpoleras enligt uttrycket (4.1). I det endimensionella fallet erhålls två värden ur tabellen och en interpolationsberäkning utförs. I det n-dimensionella fallet krävs 2n tabellposter och 2n− 1 interpolationsberäkningar för att beräkna fram ett interpolerat resutlat ur tabellen.
I Simulink finns det standardblock för tabellslagning och interpolation. Det finns block för 1, 2 och n-dimensionella tabeller. Hur blocken ser ut visas i figur 4.11.
Figur 4.11. Tre olika tabellblock, för 1, 2 och n dimensioner, som finns i Simulink.
Tabellerna kan antingen matas in i blocken eller definieras i MATLABs workspace.
Vektorn med alla x-värden och matrisen med alla y-värden matas in i blocket. Vektorn och matrisen behöver inte matas in i blocket manuellt utan kan vara definierad i MATLAB sedan tidigare och sedan länkad från blocket till MATLAB. Förutom linjär interpolation går det välja splineinterpolation eller att avrunda till närmaste tabellvärde. Extrapolation finns också som alternativ men det har undvikits i detta arbete då tabellen inte är giltig utanför dess uppmätta område. Tabellslagning är enklare i Simulink än i Pascal D80/D96 eftersom det finns mycket inbyggt stöd för just tabeller.
4.5
If-satser
I och med att if-satser används flitigt i originalkoden blir de således även viktiga i modellen. I Simulink finns det ett standardblock för if- och case-satser. Antalet insignaler till if-blocket kan justeras och villkoret skrivs in i blockets villkorsfält. Det går även ställa in fall det ska vara ett else-if-villkor och om else ska vara med eller ej. Utsignalerna från if-blocket är inte vanliga skalärer eller matriser utan funktionsanrop. Den undermodell som ska användas för ett visst villkor måste
32 Modelleringsmetoder
modifieras så att undermodellen aktiveras vid funktionsanrop. Genom att infoga ett action-block i undermodellen kan den användas tillsammans med if-blocket. Merge-blocket, som visas i figur 4.12, väljer utsignalen från den undermodell som precis har exekverats, vilket är det beteende som efterlyses. Att implementera if-satser i Simulink är relativt enkelt men nackdelen är att villkoren måste vara ganska enkla. Det går till exempel inte att använda externa funktioner såsom cosinus. Om villkoret innehåller ett mer komplext uttryck måste det modelleras innan signalen når if-blocket.
Figur 4.12. If-sats implementerad i Simulink. If-blocket väljer vilken av undermodellerna
som ska exekveras.
Ytterligare ett sätt att implementera if-statser i Simulink är att ta hjälp av Sta-teflow. Samma exempel som ovan har implementerats i Stateflow med hjälp av ett flödesdiagram. I figur 4.13 kan exemplet ses. Flödesdiagrammet saknar helt tillstånd och är endast uppbyggt av vägskäl (cirklarna), Simulinkmodeller samt kopplingar. Om flödesdiagrammet innehåller några tillstånd blir det tidsfördröj-ningar eftersom det inte går att anlända till och lämna ett tillstånd under samma sampel. Med vägskäl blir det inte någon extra fördröjning utan allt exekveras un-der samma sampel, vilket är önskvärt i detta fall. Om villkoret på den horisontella kopplingen är uppfyllt anropas undermodell 2 som returnerar ett värde på y. Om villkoret inte är uppfyllt exekveras undermodell 1. Detta är det beteende som efterlystes.
4.6 Loopar 33
Figur 4.13. Samma if-sats som i föregående figur är här implementerad i Stateflow.
Undermodellerna är modellerade i Simulink och anropas av Stateflow.
4.6
Loopar
Loopar används ofta i programmeringskod och den kod som modellerats i exa-mensarbetet är inget undantag. Simulink har stöd för for- och while-loopar och genom att infoga ett iterationsblock i undermodellen som ska loopas blir model-len iterativ. För for-loopar går det bestämma om antalet repetitioner ska anges internt eller externt. Om det förstnämnda alternativet väljs anges antalet itera-tioner direkt i blocket. Om det andra alternativet väljs kommer en insignal till undermodellen att bestämma hur många repetitioner som ska göras. Detta kan användas om antalet iterationer ska variera under simuleringen. Loopen tar ingen simuleringstid i anspråk utan simuleringen stannar upp och alla iterationer utförs för att sedan fortsätta simuleringen till nästan sampel. När alla beräkningar är klara för en tidpunkt stegas simuleringstiden upp till nästa sampel. Om återkopp-ling används i undermodellen behöver återkoppåterkopp-lingen förses med ett enhetsför-dröjningsblock för att den ska gå att simulera. De signaler som tidsfördröjs med enhetsfördröjningsblocket tolkas som samma signaler fast från föregående varv i loopen. En enhetsfördröjning inuti undermodellen som loopas är inte ekvivalent med en enhetsfördröjning utanför undermodellen, då den senare verkligen tidsför-skjuter signalen ett tidsampel. Detta är något som förvirrar användaren och gör att de modeller som var tänkta att innehålla tidsfördröjningar inte kan loopas.
Grafritningsblocket Scope ritar en signal som funktion av tiden. En signal som befinner sig inuti en modell som itereras kan ha flera olika värden vid samma tidpunkt. Scope-blocket ritar upp de värden som signalen haft under loopen och binder ihop punkterna med linjer. I varje sampeltidpunkt bildas då vertikala streck och detta medför en försvårning av felsökningsarbete inuti loopar. I figur 4.14 visas ett exempel på hur en signal ser ut innanför och utanför modellen som itereras.
34 Modelleringsmetoder 0 5 10 15 20 0 1 2 3 4
Alfa, innanför loopen
tid [s] Vinkel [grader] 0 5 10 15 20 0 1 2 3 4
Alfa, utanför loopen
tid [s]
Vinkel [grader]
Figur 4.14. Samma variabel sedd innanför och utanför en loop. Notera de vertikala
strecken som blir innanför loopen.
Loopar kan också modelleras i Stateflow där de byggs upp av ett antal vägskäl och kopplingar. I figur 4.15 visas ett exempel på en for-loop implementerad i Stateflow. Om villkoret är uppfyllt följs kopplingarna i triangeln men när villkoret inte längre är uppfyllt avslutas loopen. Villkoret kan skrivas på sådant sätt att slingan ter sig som en for-loop. Det är betydligt enklare att skapa loopar som befinner sig inuti andra loopar i Stateflow än vad det är i Simulink.
Figur 4.15. En loop i Stateflow byggs lättast upp genom att bygga en slinga med
4.7 Kommentarer och slutsatser 35
4.7
Kommentarer och slutsatser
Vad det gäller komplexitetsvalet är det lämpligast att välja en så enkel metod som möjligt men metoden måste klara minimikraven för det som modelleras. Blir an-talet standardblock och trådar för många är det bättre att gå över till Embedded MATLAB Fcn för att göra modellen mer överskådlig. Vissa centrala programme-ringsobjekt såsom variabler är svåra att modellera i Simulink. För globala variab-ler, som ska vara tillgängliga för alla undermodelvariab-ler, finns det ingen helt optimal modelleringsmetod, utan den metod som passar ändamålet bäst får väljas. Loo-par och if-satser är också svåra att modellera på ett överskådligt sätt i Simulink, men i Stateflow är de naturligare att modellera. Tabellslagning med interpolation är enklare att utföra i Simulink än i kod då Simulink har bra inbyggt stöd för just dessa operationer. Simulink är inte avsett för att modellera kod utan snarare fysikaliska system och regulatorer. Det är mer lämpligt att utgå ifrån designbe-skrivningen för koden och därifrån skapa modellen än att direkt modellera från kod.
Kapitel 5
Modellering av
bränsleberäkningskärna
En central del för segmentet MC är bränsleberäkningskärnan (Bransle_Ber) som beräknar bränsleflödet och dess delar har modellerats i Simulink utifrån den ur-sprungliga källkoden. Bransle_Ber har valts för modellering eftersom funktionen används mycket i bränsleberäkningar och den befinner sig långt ner i kodhierarkin. Att börja modellera nerifrån i kodhierarkin medför att modellerna kan valideras utan att några undermodeller saknas, vilket underlättar valideringsarbetet.
Förutom bränsleberäkningskärnan finns det flera andra funktioner såsom
Acce-leration, DeacceAcce-leration, Stigning och Plané. Dessa funktioner beräknar tid,
sträcka och bränsleåtgång då flygplanet planerar att accelerera/deaccelerera och stiga/sjunka i höjd. Eftersom dessa fyra är ganska lika har endast en av dem,
Ac-celeration (se kapitel 6), modellerats under examensarbetet. Förutom Brans-le_Ber, Acceleration, Deacceleration, Stigning och Plané finns det flera
andra funktioner som beräknar och kompenserar för bland annat svängar och landningsförfarande. Dessa delar utgör en stor del av segmentet MC och det fanns inget utrymme för att modellera dem i detta examensarbete.
För att underlätta jämförelser mellan modellerna och källkoden har de ursprungli-ga funktions- och variabelnamnen används i modelleringen. I källkoden har funk-tioner och deras returvariabler samma namn och för att skilja dem åt i rapporten så är funktioner (och deras motsvarande modeller) markerade med fetstil.
