Model Based Systems Engineering for Aircraft Systems – Mindset for Change The name of this presentation is … My name is … from … Ingela Lind 19 oktober 2010

Varför använder grundflygplansystem modellering och desktop simulering? Omfattande riskreducering i projekt Hittar fel tidigt i utvecklingsprocessen Utrustning kan simuleras I systemet innan beställning Mjukvara får bättre specifikation (även om den inte simuleras) Bättre förståelse för systemen – problem kan analyseras Få underleverantörer simulerar Kvalificering av flygplan kan utföras Simuleringar kompletterar flygprov som inte når provmålen Ersätter farliga flygprov Kostnadsbesparingar för prov Färre rigg- och flygprov Mindre omdesign av provflygplan och riggar

SYSTEMUTVECKLING Trender: Ökad andel modellering och simulering Fler använder modeller och simuleringsresultat Modellering sker tidigare System modeling and simulation in the development phase increase the system knowledge compared to non-model based development. Through Model based development a defect in a function or system can be found early. Model based development leads to more people using models and simulation results. One trend is that M&S starts earlier and earlier in the process, for example already in the concept evaluation. MBD, Model Based Development

Mindset for Change Finns det mätetal? Identifiera svaga punkter i nuvarande utvecklingsprocess. Exempel: Förmåga att planera och schemalägga, kvalitet, ”time to market”, produktivitet, spårbarhet, konfigurationsstyrning, återanvändbarhet, dokumenteringsrutiner, validering och verifiering Det måste finnas minst två syften att använda MBSE. Exempel: validera krav genom simulering, automatiskt generera dokumentation, utveckla styralgoritmer, generera kod för produktion Modellen är ensam informationsbärare. Använd övergången till MBSE som källa till lärande. Svagheter/styrkor i organisationen, utmaningar, nyckelkompetenser, effektiva punkter Integrera utvecklingsprocessen Se utvecklingen på lång sikt. Börja med svaga punkter och nya produkter

GRUNDFLYGPLANSYSTEM Luftsystem Bränslesystem Elkraftsystem Landställ I have focused on the vehicle systems. Some of the major vehicle systems are: The landing gear, hydraulic system, secondary power system, fuel system, and environmental control system that cools the avionics and cockpit. \in-’vī-rə(n)-’men-təl, Landställ Hydraulsystem

SYSTEMÖVERSIKT Utrustning En typisk modell över ett system som t ex bränslesystem kan delas upp i tre modellkategorier ECU / Inbyggd mjukvara Task Task Task Task Task Omgivning A typical model of a system such as the fuel system may be divided in to tree major model categories: The equipment model with pumps, valves and pipes. The embedded software model for control and monitoring of the equipments. The surrounding models feed the two categories above with input data. The pilot, flight case and the atmosphere will be found here. Komplett systemmodell

Exempel: Många och komplexa kopplingar mellan olika systems uppstartsförlopp och deras systemkontroll (SK). Idag svårt att förutse innan provning i flygplan. Har larmgränser satts korrekt med tanke på systemens normala uppstartsförlopp (långsam tryckuppbyggnad och temperaturinsvängning) och ordningen på SK för olika system? Kan alla normala uppstarter göras, t ex på solig, varm platta, med liten bränslemängd, vid extrem kyla, omstart?  VISION . Pådrag Efterfrågad kylkapacitet Kyld luft Bleedluft Bränsle Trycksättning This simplified simulator example shows the interaction between some models…. The pilot that affects the avionic cooling need engine. The engine affects the environmental control system and so on. It is common that each model has been developed for another purpose than the simulator. Therefore have the models different accuracy. This results in that the output accuracy of a model is a function of the remaining models in the simulator. In the extreme the model with the lowest accuracy defines the whole simulator accuracy.

EN MODELLBASERAD UTVECKLINGSPROCESS VISION EN MODELLBASERAD UTVECKLINGSPROCESS Flygprov Första Återkoppling Andra återkoppling Tredje Systemmodell av fysiska systemet Inbyggd kod Reglermodell M u y Provrigg Simulator This picture describes the model based development process used at SAAB. The first loop consists of two phases: without and with a complete control model. Control system details are needed later relative to the equipment system development. In the loop without a complete software model, the equipment system performance, like cooling effect and dimensions, like heat exchanger size, is specified for system components and to confirm the design choices in the concept phase. In the loop with a complete control model, a closed loop verification can be done by co-simulation or by hosted simulation. The closed loop verification reduces the workload in simulators, rigs, and flight tests, and leads to better understanding of the impact of the control logic on the equipment. The major development of the software takes place in this phase. Failure mode and effect analysis (FMEA) and load analysis can also begin late in this phase because much of the system components and airframe structure design has already been frozen. In the remaining loops the major focus is on tuning, verification, and validation. 2. Second loop, simulator and rig tests The software model from the first loop is converted to embedded code via autocode generation or by hand. By separating software functions according to safety criticality and usage, the software functions can be safely separated so software functions of different criticality level may be hosted in the same physical computer resource. This gives major simplification of the choice of workflow, tools and verification/validation process. One purpose of the simulation activity is to verify the software algorithm and its software interface with other systems. Typical errors concern units and interfaces that are difficult to cover in loop one. A first partial validation can be done in the test rig, where the influence on the system of for example wiring and fluid dynamic, which are seldom modeled, can be analyzed. Third loop, flight tests If all modified software functions are non-critical, flight tests are not considered mandatory. If it is later shown in the aircraft that the software needs to be updated, this can be easily done due to the separation from critical functions. If modified software functions are critical, flight tests are considered mandatory in order to secure airworthiness. An important part of the rig and flight test activity is to feed the models with measurement data to improve the model’s accuracy.

EN MODELLBASERAD UTVECKLINGSPROCESS Data från underleverantörer Fysiska lagar och grundläggande relationer Bänkprov Tidigare erfarenhet Geometriska data / CFD analys Första konceptvalidering Dimensionering Känslighetsanalys Prestandauppskattning u u y y M M Systemmodell av fysiska systemet

EN MODELLBASERAD UTVECKLINGSPROCESS Dokument (genererade) Specifikation för inbyggd mjukvara Simulerbar beskrivning Reglermodell Fysiska begränsningar Reglermål Systemsäkerhet

EN MODELLBASERAD UTVECKLINGSPROCESS Reglermodell Snabb prototyputveckling både för fysiska delen av systemet och regleringen Stöd för systemsäkerhetsarbete Hjälp att ta fram statiska och utmattningslaster Prestandautvärdering Detaljerad design Första Återkoppling u u y y M M Systemmodell av fysiska systemet

EN MODELLBASERAD UTVECKLINGSPROCESS y Systemvalidering Ökad konfidens i modeller och simuleringsresultat Kunna särskilja trovärdiga resultat från osäkra Komplementerande fysiska och virtuella prov ger billigare och säkrare systemverifiering

SYSTEM- MODELL systemsäkerhetsingenjör systemingenjör apparatingenjör systemintegratör CAD-ingenjör specifikation apparater specifikation mjukvara skrov & installation mjukvaruingenjör beräkningsingenjör inbyggd kod laster & hållfasthet simulatorutvecklare SYSTEM- MODELL realtids- modell MYSIM provledare utvecklare specifikation riggprov systemsimuleringsingenjör SYSIM piloter tekniker riggprov flygprov tränings- simulatorer specifikation flygprov provingenjörer

VERKTYGSVAL KRAV FÄLLOR långsiktighet kodgeneratorer användarvänlighet skalbarhet anpassning till utvecklingsprocessen synliggöra ekvationerna som används flexibla modeller (map syfte) versionskontroll robust FÄLLOR kodgeneratorer plattformsberoende licensavtal + jurister många projekt drar nytta av resultatet  ingen vill betala

LUFTSYSTEM (ECS) Språk: Modelica Verktyg: Dymola This is an example of a vehicle simulation model, the environmental control system. The engine produces bleed air which is cooled in the heat exchanges in the ram air channels, passes a turbine and some other equipment and finally cools the cockpit and the avionics. Included in the model is also the control logic in the electronic control unit. \’tər-bən, -’bīn\

MODELLERAD REGLERLOGIK Verktyg: Simulink, Stateflow This is an Air to air refueling example of a modeled control logic. *** The state chart in the middle describes the different stats that the fuel probe has. From the model it is possible to generate code and documentation.

Fundamentala fysikaliska ekvationer i varje komponentmodell: jämviktsekvationer kontinuitetsekvationer gaslagen friktionsförlustekvationer Ohms lag… Typiska tillstånd: tryck, temperatur, flöde, fukthalt, spänning, ström… Vad är en systemmodell? Modellen är i 1D och byggd av komponentmodeller Varje komponentmodell beskriver en komponent av systemet: ventil, pump, rör, sensor, värmeväxlare, RAMMkanal, vattenseparator, reservoar, kablage...

Modellera ett rör – olika modelleringsnivåer q1 q2 p1 p2 Statiskt: q1=q2 and p1=p2 q Kc t p1 p2 Statiskt: Resistans q = Kc (p1-p2)0.5 q q1 Kc Kc q2 t V 63% Dynamiskt: Lumpad volym: Kapacitans med/utan resistans C= V/β = (q1-q2) / p (massans bevarande) . t = C/Kc Ökande noggrannhet och bandbredd t q V m Dynamiskt: Lumpad volym och massa med/utan resistans Resistans +Kapacitans + Induktans (L) L = (ρ*V) / A2 = (p1-p2) / q (rörelsemängdens bevarande) . q t V m V m V m V m Dynamiskt: Lumpat rör Dynamiskt: Distribuerad volym (1-D CFD) Resistans + massans bevarande + rörelsemängdens bevarande + energins bevarande Inklusive temperatur

Signalbaserad eller power port strategi Signalbaserad modellering (Simulink, MatrixX, etc) – systemekvationer p p 2 p q q Volym Ventil 1 q 2 1 Power port modellering (EASY5, HOPSAN, Dymola, etc) – systemscheman. Naturlig objektorientering. Ingen fixerad kausalitet Många fysiska signaler överförda i varje linje p q p q p q Volym Diff ekv 1 1 Ventil Alg ekv 2 2

BESKRIVA MODELLOSÄKERHET statistiska variationer Parameterosäkerhet ventilarea, tryckfallskoefficient… Modellstrukturosäkerhet modelleringsnivå, okända faktorer Hur påverkas simuleringsresultat? valideringsmetodik i komplexa olinjära modeller Kan man rikta prov till det som ger mest nytta för minskning av risker (säkerhet, projekt, …)? brist på information A common way of classifying parameter uncertainties is in aleatory and epistemic uncertainties. *** Uncertainties due to statistical variations in parameters, are termed aleatory uncertainties. An aleatory uncertainty arises because of natural, unpredictable variations in the parameter. Typical model parameters with aleatory uncertainties are fluid properties, pressure drop coefficients that are dependent on manufacturing tolerances. *** Uncertainties due to lack of information about parameters, are termed epistemic uncertainties. Epistemic uncertainty, or reducible uncertainties as it is also called, is due to a lack of knowledge about the behaviour of the parameter. Early in the concept phase, there are more epistemic uncertainties than aleatory uncertainties. During the refinement of the model, most epistemic uncertainties decrease and some epistemic parameters transform into aleatory uncertainties. The model structure uncertainties is related to the epistemic uncertainties, for example the system and its equations are not modelled with sufficient detail.

HELHETSBILD Fortsätta bygga helhetsbilden av en modellbaserad utvecklingsprocess Identifiera och åtgärda brister – ge sammanhängande metodik Stötta utvecklingen mot fler användare – identifiera aktörer och deras behov u u y y M M

KOMPETENSSPRIDNING Informationsspridning MBSE-kurser för systemingenjörer (basnivå) MBSE-forum för OTTODG / OTTOFG / OTTODYM konferensbidrag seminarier efter konferenser Daglig problemlösning i gruppen Scrum-team  aktuella problem och lösningar tas upp flera gånger i veckan ”vi hjälper varann”-anda ”extreme programming” – parprogrammering används vid extra besvärliga eller helt nya typer av problem Forskning och metodikutveckling förstudier / lärling / engineering portal-sidor för ny metodik OTTODG ofta ”först ut” i projekt pga långa ledtider påverkar dokumenterad metodik, t ex för GripenCore forskningsprojekt, t ex Crescendo, NFFP, CleanSky, med syfte att lära och sprida kunskap industrihandledare för doktorander dialog med verktygsleverantörer 0 breddning och informationsspridning 1 daglig problemlösning i gruppen 2 framtidsinriktat, forskning och metodikutveckling