Systems Engineering

Vägledning till läsaren

Denna berättelse beskriver Saabs arbete med Systems Engineering.

Systems Engineering har vuxit fram som en ingenjörsdomän för att på ett strukturerat sätt etablera och kommunicera en ”organisationell” samsyn kring definitionen av systemets önskade egenskaper, från ett operationellt och tekniskt perspektiv.

Målsättningen är alltså att utveckla och driftsätta system med tillräckligt goda egenskaper för att tillfredsställa intressenternas förväntningar och behov till en rimlig kostnad.

För att kunna bedriva en strukturerad, effektiv verksamhet för att utveckla och producera avancerade produkter krävs att man har effektiva arbetssätt och processer som verkligen drivs i ett värdeflöde.

För att bedriva en effektiv verksamhet och kontinuerligt utveckla denna har Saab valt att utgå från en standard, för att på ett strukturerat sätt använda processer i hela verksamheten. Denna standard kallas för ISO 15288. Standarden utgör ett ramverk för att beskriva livscyklerna.

Bakgrund

Systems Engineering är en relativt ung ingenjörsdomän. Den omnämns för första gången i samband med ”Manhattanprojektet” och utbyggnaden av telekomsystem i USA under 1940-talet.

Under senare halvan av 1900-talet har Systems Engineering främst tillämpats inom rymd- och försvarssektorn, men under 2000-talet tillämpas Systems Engineering även inom fordons-, bioteknik-, transport- och energisektorerna.

Rekommendation

Författaren rekommenderar nedanstående texter som har koppling till denna berättelse: Under Utvecklingskompetens, läs gärna Utveckling av världens bästa styrsystem och Agila metoder i programvaruutveckling samt Systemintegration - en unik kompetens.

Texten berör markerade områden inom förändringsresan i flygindustrin

Sammanfattning

Över tid har komplexiteten i de tekniska systemen som realiserats i samhälle och företag ökat. Kraven på kvalitet och funktionalitet har dessutom ökat på alla system som är realiserade och används i företag och samhälle. Det innebär att antalet egenskaper för att hantera ett realiserat system har ökat.

I takt med att antalet egenskaper som behövs för att hantera ett system har ökat så har också antalet ingenjörsdiscipliner ökat i motsvarande grad för att utveckla komplexa system.

Den stora utmaningen vid utvecklingen av Gripen A/B från ett tekniskt perspektiv var att skapa den grundläggande plattformen, genomföra en integration av alla system och säkerställa att flygplanet blev en stabil flygande plattform.

När Gripen C/D började utvecklas i mitten av 1990-talet hade komplexiteten i produkten ökat avsevärt jämfört med den första versionen - Gripen A. Nu hade fokus ändrats, Gripen skulle kunna exporteras och bli en internationellt användbar produkt, vilket ställde helt nya krav.

För Gripen E kombineras och vidareutvecklas de starka sidorna i tidigare arbetssätt, detta görs utifrån de erfarenheter som framkommit från utvecklingsarbetet med de tidigare Gripen-varianterna. Med utökad modelleringsförmåga kan man nu enkelt kommunicera en designlösning och simulera stora delar av systemet långt innan det är realiserat.

Beskrivning av innehåll

  • Under senare halvan av 1900-talet har Systems Engineering främst tillämpats inom rymd- och försvarssektorn, men under 2000-talet tillämpas Systems Engineering även inom fordons-, bioteknik-, transport- och energisektorerna.
  • Inom Systems Engineering används ett antal grundtermer för att på ett entydigt sätt resonera kring ett system.
  • Systems Engineering har tillämpats i alla större projekt på Saab sedan 1980-talet. Tillämpningarna har skiftat beroende på hur idealbilden av området uppfattats i omvärlden.
  • Ett långsiktigt och uthålligt arbete med att stärka förståelse och kompetens inom Systems Engineering har resulterat i en avsevärd förmågehöjning. Specifikt har det gällt för teknikområdet ”Integration” som är centralt för Saab.
  • Nästa steg för bättre verktygsstöd blir att införa stöd för hantering av flera alternativa konfigurationer av modeller och på så sätt förenkla utvärdering av flera samtidiga alternativ och inte minst förenkla parallell utveckling av komplexa system.

Bakgrund till systems engineering

Ända sedan de urgamla civilisationerna har ingenjörer och deras föregångare, skapat produkter och system som uppfyller omgivningens förväntningar. Ett tidigt exempel är romarnas välutvecklade transportsystem såväl till lands som till sjöss. Goda vägar, välorganiserade rastställen med utvilade hästar säkerställde snabba, kostnadseffektiva och säkra transporter till lands. Detsamma kan sägas om de välutvecklade hamnarna med tillhörande infrastruktur.

Systems Engineering är en relativt ung ingenjörsdomän. Den omnämns för första gången i samband med ”Manhattanprojektet” och utbyggnaden av telekomsystem i USA under 1940-talet. Under senare halvan av 1900-talet har Systems Engineering främst tillämpats inom rymd- och försvarssektorn, men under 2000-talet tillämpas Systems Engineering även inom fordons-, bioteknik-, transport- och energisektorerna.

Målsättningen är alltså att utveckla och driftsätta system med tillräckligt goda egenskaper för att tillfredsställa intressenternas förväntningar och behov till en rimlig kostnad. Inom ramen för denna beskrivning används termen egenskap. Sådana egenskaper kan vara statiska som exempelvis vikt, materialhårdhet, densitet, bandbredd eller dynamiska som exempelvis beteende, momentan kapacitet etc.

Komplexitet

Över tid har komplexiteten i de tekniska systemen som realiserats i samhälle och företag ökat. Kraven på kvalitet och funktionalitet har dessutom ökat på alla system som är realiserade och används i företag och samhälle. Det innebär att antalet egenskaper för hantera ett realiserat system har ökat.

I takt med att antalet egenskaper har ökat som behövs för att hantera ett system så har också antalet ingenjörsdiscipliner ökat i motsvarande grad för att utveckla komplexa system.

För att realisera ett modernt stridsflygsystem som Gripen-systemet behövs åtminstone bidrag från ingenjörer med kompetens inom mekanik, flygteknik, elektronik, drift och underhåll samt mjukvara. Resultatet blir av nödvändighet en stor organisation med medarbetare med olika uppfattningar om vilka systemegenskaper som är viktiga och vilken balans mellan egenskaperna som är optimal.

Systems Engineering en ingenjörsdomän

Systems Engineering har vuxit fram som en ingenjörsdomän för att på ett strukturerat sätt etablera och kommunicera en ”organisationell” samsyn kring definitionen av systemets önskade egenskaper, från ett operationellt och tekniskt perspektiv.

Nedanstående figur illustrerar några av de systemegenskaper som måste beaktas vid utvecklingen av ett stridsflygplan. Det är väsentligt att tänka på att till varje egenskap så krävs personer med utbildning och erfarenhet för att hantera just den specifika egenskapen.
Nedan visas ett antal exempel på systemegenskaper som måste beaktas vid utvecklingen av stridsflygplan.

  • Radar Cross-section
  • Service Life
  • Fuel Capacity
  • Weight
  • Environmental Impact
  • Range
  • Supportability
  • Development Cost
  • Survivability
  • Flight Envelope
  • Operational Cost
  • Availability
  • Safety
  • Center of Gravity
  • Fuel Consumption
  • Maintenance Interval

Grundkoncept för Systems Engineering

Inom Systems Engineering används ett antal grundtermer för att på ett entydigt sätt resonera kring ett system. De termer som presenteras i nedanstående text bygger på underlag från standarden ISO 15288, 2008 ”System lifecycle processes”.

Alla system har en livscykel. En livscykelmodell används för att enkelt kunna diskutera kring var i utvecklings- eller driftsfasen ett system befinner sig. Dessutom beskriver livscykelmodellen vilket fokus man har inom det värdeflöde som skapas när man utvecklar ett system och en produkt.

Figuren visar den livscykelmodell med sex olika faser som används på Saab.

Livscykelmodellen

Livscykelmodellen är uppdelad i sex olika faser. Under varje fas sker en värdemässig förädling av det system eller den produkt som man utvecklar. I denna typ av försörjningskedja är det värt att notera att även sista steget med avveckling och skrotning av ett system också är en form av återtagande av värden. Här börjar delar av systemet eller produkten att kunna återanvändas och på nytt ingå i en ny försörjningskedja.

Livscykelsmodellens faser

Initial studies: I denna fas genomförs inledande studier med syfte att utreda en eller flera aspekter av ett system. Denna fas används vid tidiga utredningar kring nya flygsystem eller vid tidiga studier av nya förmågor för existerande system. Fasen avslutas normalt med en rapport som summerar utkomsten av arbetet som genomförts.

Concept: Under konceptfasen formaliseras utvecklingsaktiviteterna med syfte att definiera ett koncept med tillräckligt goda egenskaper för att initiera fullskalig utveckling. Fokus under fasen ligger primärt på identifiering av intressenternas krav, analys av tekniska krav och arkitektur för systemet under utveckling.

Under konceptfasen utvärderas ett flertal olika koncept innan något väljs för vidare utveckling. För att kunna genomföra val av koncept måste även icke funktionella egenskaper utvärderas som systemsäkerhet, underhållsbarhet, utbyggbarhet och informationssäkerhet för olika systemkoncept.

Vid utvecklingen a Gripen-systemet används konceptfasen både vid definitionen av ett nytt flygplan, till exempelvis Gripen E men också för varje nytt ”förmågepaket” som ska integreras i systemet.

Development: Utvecklingsfasen innebär att den i konceptfasen valda systemlösningen realiseras och kvalitetssäkras. Det innebär att alla identifierade systemegenskaper och systemkrav verifieras. Dessutom valideras den realiserade systemlösningen i sin operativa miljö.

Production: Produktionsfasen innebär att systemlösningen för det realiserade systemet serieproduceras. För system som tillverkas i liten serie kan själva produktionsfasen vara relativt okomplicerad. Produkten i sig kan dock vara mycket komplicerad vilket kräver realisering av ett omfattande och komplext produktionssystem.

Operation and Maintenance: Drift- och underhållsfasen innefattar alla aktiviteter för att säkerställa drift och underhåll av det realiserade systemet. Det innebär att man säkerställer att drifts- och underhållsorganisationen behåller och utvecklar sin förmåga.

Disposal: Under avvecklingsfasen tas ett system ur drift och avvecklas på ett för omgivningen skonsamt sätt, vilket innebär att ingående material återanvänds.

Processer

För att kunna bedriva en strukturerad, effektiv verksamhet för att utveckla och producera avancerade produkter krävs att man har effektiva arbetssätt och processer som verkligen drivs i ett värdeflöde. För att bedriva en effektiv verksamhet och kontinuerligt utveckla denna har Saab valt att utgå från en standard, för att på ett strukturerat sätt använda processer i hela verksamheten. Denna standard kallas för ISO 15288. Standarden utgör ett ramverk för att beskriva livscyklerna.

Standarden definierar processer med tillhörande terminologi. Standarden beskriver dessutom stödprocesser för att styra och förbättra de livscykelprocesser som används inom en verksamhet eller i ett projekt.

Inom denna standard grupperas processer i fyra grupper baserade på innehåll.

  1. Agreement processes: Innehåller grupper av affärs- och gränssnittsprocesser för en organisation för att på ett ordnat sätt kunna interagera med kunder och leverantörer.
  2. Project processes: Beskriver hur man arbetar i projekt. Här beskrivs hur man organiserar arbetet i projekt, hur styrning skall ske, hur resultaten skall utvärderas och hur man arbetar med informations- och konfigurationshantering.
  3. Technical processes: Här grupperas processer som styr den tekniska utvecklingen av ett system. Från identifiering av intressentkrav, till verifiering, validering, drift, underhåll och till sist skrotning av ett system.
  4. Organizational project enabling processes: Detta område innehåller processer som används för att styra ett helt företag.

Saab har gjort en tolkning av standarden för att anpassa den till Saabs verksamhet. Syftet med Saabs processer är att utnyttja möjligheterna på marknaden, uppfylla kundernas och andra intressenters krav och förväntningar på produkter och tjänster. Det sker genom att effektivt utnyttja de resurser och kompetenser som finns i verksamheten.

Saabs har också gjort en tolkning av hur de tekniska processerna används under livscykeln. Processerna ligger här parallellt och de spänner över flera livscykelsteg.

Figuren visar Saabs processkarta för teknikprocesser som spänner över en hel produktlivscykel.

Systemstruktur

Att identifiera delsystem och deras egenskaper är ett av grundkoncepten i Systems Engineering. Tanken är att dela upp ett komplext system i mindre och mer hanterbara delar. Därefter utvecklar man dessa oberoende av varandra för att sedan integrera delarna till en helhet som har de önskade egenskaperna d.v.s. de uppfyller ställda krav.

För Gripen-systemet innebär detta att flygplanet delas ned i ett antal delsystem, exempelvis kommunikationssystemet, skrov, vapenintegration och beslutsstöd.

Inom ramen för detta är det viktigt att inte bara beakta de i systemet ingående delsystemen utan också ingående stödsystem.

Utvecklingssystemet utgörs av systemelement som används för att utveckla själva systemet för produkten. Utvecklingssystemet innefattar stödsystem som kan omfatta alla komponenter som ingår i ett modellbaserat arbetssätt som Saab använder. Man använder MBD Model Based Definition för strukturutveckling och MBSE Model Based Systems Engineering för systemutveckling.

För att bedriva ett effektivt utvecklingsarbete bör ”utvecklingssystemet” som används vara moget redan vid starten av utvecklingsarbetet. Utvecklingssystemet innefattar exempelvis CAD-verktyg, system för hantering av produktdata, modelleringsverktyg etc.

Verifieringssystemet omfattar de systemelement som krävs för att verifiera och validera systemet. Det innefattar riggar, simulatorer och provflygplan.

För Gripen E finns både mjukvarubaserade och ”typlika riggar”. De senare kan vara en modell av en apparat som innehåller ”skarp kod”.

Träningssystemet innefattar systemelement för att utbilda slutanvändarna av systemet. Det innefattar stöd för pilot och underhållspersonal. Träningssystemet omfattar utbildningsmaterial, pilot- och underhållsmanualer. Träningssystemet kan utformas som simulatorer, exempelvis som i VMT för Gripen C/D.

Produktionssystemet omfattar alla system och all produktionsutrustning för att kunna producera slutanvändarsystemet med godtagbar kvalitet.

Underhållssystemet omfattar både underhåll i fält och underhåll i verkstäder. Här finns reservdelsmateriel, diagnos, reparationsmateriel, med tillhörande arbetsinstruktioner och informationssystem för att vidmakthålla slutanvändarsystemets operativa förmåga.

Skrotningssystemet, omfattar instruktioner och stödjande komponenter för att ta isär slutanvändarsystemet på ett säkert sätt och återanvända alternativt skrota ingående komponenter på ett ur miljöhänseende och ekonomiskt hänseende godtagbart sätt.

Alla ovan nämnda stödsystem inkluderar normalt även den personal som krävs för att operera respektive system. I alla system i detta sammanhang inkluderas både det egentliga systemet som används i en produkt och de stödsystem som krävs för att utveckla, producera och underhålla systemet.

Figuren visar kopplingen mellan slutanvändarsystem och stödsystem.

Tekniska granskningar

Under hela koncept- och utvecklingsfasen är det särskilt viktigt att ha en nära samverkan med kunden (i Sverige FMV) och brukaren (i Sverige Försvarsmakten).

 

Den stora utmaningen vid utvecklingen av komplexa system är att man i tidiga utvecklingsskeden kan vara tvingad att ta vissa svåra arkitekturbeslut. Dessa beslut kan komma att påverka hela systemet både avseende förmåga och livscykelkostnad innan man en har en djupare kunskap om systemet och hur det kommer att fungera i sin operativa miljö.

För att undvika detta dilemma kan man arbeta med modellbaserat ett arbetssätt. Det gör man i nära samarbete med såväl kunder som underleverantörer.

Olika typer av simulatorer är centrala i det dagliga arbetet. Genom att kontinuerligt och systematiskt arbeta med att utveckla modeller av enskilda delsystem, får man insikt om olika lösningars lämplighet tidigt i konceptarbetet. Med dessa modeller byggs sedan de avancerade simulatorer som definierar flygplanet eller vapensystemet.

Det finns ytterligare en stor utmaning. När systemkunskap har etablerats och insikt vunnits om de valda lösningarnas svaga sidor är det mycket kostsamt att införa förändringar.

Målsättningen inom Systems Engineering är att tidigt öka kunskapen om ett system genom väl genomförda konceptfaser. Man skall också tidigt utsätta föreslagna lösningar för granskning för att säkerställa att bästa möjliga lösning väljs. Insikt om de tekniska lösningarnas begränsningar uppkommer oftast efter en tid.

Figuren illustrerar kostnadssamband - koppling mellan kunskap för valda tekniska lösningar och kostnad för förändring av valda lösningar.

Granskningar (technical reviews) används för att kvalitetssäkra och koordinera utvecklingsarbetet. Detta sker genom att interna och externa intressenter får möjlighet att förbättra föreslagen systemlösning och samtidigt får insikt och gemensam kunskap om den föreslagna lösningen. Genom granskningar kan man se hur ett system mognar både till innehåll och avseende kvalitet.

Tillämpningar av Systems Engineering

Systems Engineering har tillämpats i alla större projekt på Saab sedan 1980-talet. Tillämpningarna har skiftat beroende på hur idealbilden av Systems Engineering uppfattats i omvärlden. Andra faktorer har också spelat in, det har då varit utmaningar som organisationen stått inför och särskilt komplexiteten i dessa utmaningar. Nedan beskrivs tillämpning av Systems Engineering avseende utvecklingsarbete från Gripen A/B till Gripen E.

Gripen A/B

Den stora utmaningen vid utvecklingen av Gripen A/B ur ett tekniskt perspektiv var att skapa den grundläggande plattformen, genomföra en integration av alla system och säkerställa att flygplanet blev en stabil flygande plattform.

Bortsett från att alla tekniska lösningar var nya, så fanns stora tekniska utmaningar kopplade till material (komposit) och realisering av ett helt nytt digitalt styrsystem för en instabil flygfarkost.

Utvecklingen av Gripen A (ensitsversion) gjordes till stor del i en icke digitaliserad värld där handskrivna dokument och ritningar var en del av det naturliga utvecklingsarbetet. CAD för mekanisk- och elektrisk konstruktion infördes först under utvecklingen av Gripen B (tvåsitsversion). Det innebar att stora delar av det tidiga installationsarbetet baserades på fysiska trämodeller av flygplanet.

En stor fördel vid det tidiga utvecklingsarbetet i Gripen A/B var att utvecklingsteamet var relativt litet och systemet var relativt sett, enklare än senare versioner av Gripen. Man kunde därigenom skapa en god överblick över det totala systemet vilket förenklade kommunikationen mellan olika systemutvecklare markant.

Hårdvaran var inte, med dagens mått, särskilt komplicerad vilket gjorde att enskilda ingenjörer kunde ha goda kunskaper om stora delar av Gripen-systemet.

En simulator kallad ”Syrig” utvecklades för utvärdering och utprovning av det ”typlika” Gripen-systemet. Dessutom fanns ett förhållandevis litet antal mindre avancerade riggar och simulatorer som stöd vid utvecklingsarbetet.

Simulatorn ”Syrig” fanns tillgänglig och användes tidigt för utprovning och verifiering. För olika typer av grundflygplanssystem som exempelvis bränsle-, luft-, och hydraulsystem utvecklades traditionella grundflygplansriggar för att verifiera dessa system. Det fanns också ett begränsat antal provstationer som kunde användas för utvecklingsarbete. För att genomföra integrationsprovning av alla system fanns också några provstationer.

Sammanfattningsvis kan man säga att utvecklingen av Gripen A karakteriserades av ett starkt arbetssätt för att beskriva systemets arkitektur och design, medan kravställningen inte var lika tydlig.

Gripen C/D

När Gripen C/D började utvecklas i mitten av 1990-talet hade komplexiteten i produkten ökat avsevärt jämfört med den första versionen - Gripen A.

Nu hade fokus ändrats, Gripen skulle kunna exporteras och bli en internationellt användbar produkt. Detta ställde helt nya krav. Dessutom hade den tekniska utvecklingen gjort att man måste uppgradera eller helt byta många system. Man gick därför från en unik svensk lösning anpassad helt för svenska behov till ett system för exportmarknaden.

Ett samarbete etablerades med BAe Systems för exportförsäljning. Detta satte fokus på användning av internationellt vedertagen metodik.

Jämfört med utvecklingen av Gripen A/B så var den grundläggande luftfarkosten genomarbetad och väl känd. Nu var istället utmaningen att öka den funktionella och operativa förmågan. Avioniksystemet byttes ut till stora delar och mer kraftfulla datorer infördes.

Inom teknikområdet Systems Engineering var under sent 1990-tal till mitten av 2000-talet fokus på kravhantering och processdefinition. Dessa områden bedömdes som nycklar till effektiv systemutveckling. Dessutom fanns de första versionerna av MBSE-verktyg tillgängliga på marknaden. Kännetecknande för dessa MBSE-verktyg var att de gav en modelleringsförmåga och en viss begränsad simulerings- och kodgenereringsförmåga. Genererad kod användes dock endast i simulatorer.

Omfattande investeringar gjordes i forskning och av introduktion i systemmodellering. Som exempel på detta anskaffades verktygen xmath/Systembuild för signal/styrsystem-orienterad modellering och Boeing Easy5 för hydraulikmodellering. Kännetecknande för de här systemen var att de gav organisationen förmågan att genomföra simuleringar av skeenden inom ramen för enskilda ingenjörsdiscipliner och för enstaka system.

Dessutom infördes en modern kravhanteringsmetodik och verktyget Telelogic DOORS för detta ändamål. Kravhanteringsmetodik infördes också vid definition av processer och framtagande av enhetliga mallar för användning vid utvecklingsarbete. Vidare investerades i forskning i verktygsoberoende lagring av information som berörde Systems Engineering. Saab var en av initiativtagarna till skapandet av datautbytesstandarden AP-233 som finns inom ramen för ISO 10303 familjen. Till skillnad från utvecklingen i Gripen A/B var nu alla system helt datoriserade.

I omvärlden fanns det under denna tid en stor tilltro att formalisering av utvecklingsprocessen skulle ge stora förbättringar i kvalitet och produktivitet. På Saab anammades dessa tankar och ett omfattande arbete gjordes med fokus på att dokumentera processer. Arbetet på Saab gjordes i stort med samma ansats och resultat som i omvärlden.

Fokus låg på att i huvudsak definiera sekventiella flöden. Istället för att integrera aktiviteter till en liten sammanhållande mängd av processer så skapades ett uppsättning domänspecifika processer. Resultatet blev ett förhållandevis stort antal väldefinierade processer men med dålig integration mellan enskilda processer, därigenom blev kunskapen begränsad om hur processerna verkligen fungerade tillsammans.

Dessutom var det inte helt lätt att definiera det innehåll som krävdes för att beskriva det ingenjörsarbete som krävs för att utveckla ett komplext system.

Resultatet av blev ett förhållandevis statiskt arbetssätt. där kravhantering prioriterades över beskrivning av arkitektur och design, mycket på grund av det faktum att verktyget DOORS visade sig vara det enda verktyg som verkligen kunde användas i stor skala och som kunde användas brett över organisationen.

Gripen E

Utmaningen vid utveckling av Gripen E liknar i mångt och mycket kombinationen som organisationen stod inför vid utvecklingen av Gripen A/B och C/D. Många av de grundläggande systemen modifieras i stor grad eller ersätts helt och hållet. Samtidigt byts hela avionik-arkitekturen ut mot mer kraftfulla datorer och nya sensorer. I likhet med utvecklingen av Gripen A finns det delar som kan anses vara mogna och färdigintegrerade, däremot finns en stor insikt om önskat systembeteende och egenskaper när det väl är realiserat.

Systemutvecklingsprocessen som används vid Gripen E är den som beskrevs i början av detta kapitel. Processen betonar vikten av att både identifiera krav och dokumentera design på ett effektivt sätt. För att kunna göra det krävs att man kan integrera bidrag från alla ingenjörsdomäner i utvecklingsprocessen. Det betyder att i princip alla processer måste vara aktiva och koordineras under utvecklingsarbetet.

Utvecklingsteamet är från början redan stort och det finns stora vinster i att kommunicera vald designlösning på ett effektivt sätt.

För att förbättra kompetensen inom Systems Engineering genomförs utbildningar baserade på INCOSEs Systems Engineering handbook. Målsättningen är att certifiera deltagarna som Certified Systems Engineering Professional (CSEP).

Inför utvecklingen av Gripen E infördes en rad nya stödsystem för utvecklingen, bland annat den senaste generationens konstruktions- och modelleringsverktyg.

Exempel på detta är Dassault Catia V5 med tillhörande stödverktyg, det Modelica-baserade verktygen Dymola, Mathworks, Matlab/Simulink, Onefact, Bridgepoint och IBM Rhapsody.

Simuleringsfunktionen i dessa är oerhört mycket mer kraftfull i jämförelse med de verktyg som användes vid utvecklingen av Gripen C/D. Därtill har möjligheterna att koppla samman modeller utvecklade i olika verktyg ökat väsentligt. Det är till exempel möjligt att simulera fysikaliska modeller av delsystem i flygplanet (modellerat i Dymola) tillsammans med modeller av reglersystemet (modellerat i Simulink). Det gör det möjligt att mycket tidigt få en god uppfattning om systemets karaktäristik, som gör det enkelt att optimera den valda designlösningen.

Dessutom är verktygens kodgeneratorer och tillhörande metodik, nu så pass mogna att de kan användas för att generera kod för exekvering i flygplanet.

Utöver förbättrade modelleringsverktyg har nya simuleringsstationer utvecklats. Med dessa kan man öka möjligheterna att tidigt i utvecklingsarbetet integrera och verifiera så mycket som möjligt av systemet. Det kan ske redan innan den faktiska integrationen görs i flygplanet.

Man har också utvecklat helt mjukvarubaserade simulatorer som exempelvis ”MySim”.

Denna simulator ger varje ingenjör möjlighet att simulera hela systemet på sin egen arbetsstation. Jämfört med Gripen A/B har de t skett en enorm ökning i kapacitet. Då fanns det endast ett fåtal provstationer som gav möjlighet att prova hela det integrerade systemet.

Reflektioner

Ett långsiktigt och uthålligt arbete med att stärka förståelse och kompetens inom Systems Engineering har resulterat i en avsevärd förmågehöjning. Specifikt har det gällt för teknikområdet ”Integration” som är centralt för Saab. Det individuella ansvarstagandet och de nätverk som finns mellan medarbetare är en garant för den verksamhetsförmåga som finns inom Saab snarare än de dokumenterade processbeskrivningarna.

För att utveckla den grundläggande förmågan inom Systems Enginering behövs ytterligare satsningar på kompetensöverföring efter genomförda produktutvecklingsprojekt och mellan pågående produktutvecklingsprojekt. Man bör även utveckla erfarenhetsutbyten mellan olika teknikdiscipliner ännu mer då teknikutveckling framgent accelererar. Anledningen till detta är att man måste ta vara på den teknikutveckling som sker inom ett område då det oftast starkt påverkar flera andra teknikområden.

En mycket kortfattad jämförelse mellan de tre generationerna av Gripen ger:

Gripen A/B

Utvecklingen av Gripen A innehöll stora tekniska utmaningar. Systems Engineering hanterades av en relativt liten grupp ingenjörer. Kommunikationsvägarna var korta och hela den utvecklande organisationen hade en god uppfattning om hela systemet. Dokumentationen av systemet fokuserade på designlösningen. Den utvecklande organisationen var förhållandevis liten, därmed var en formell utvecklingsprocess av underordnad betydelse.

Gripen C/D

När Gripen C/D startade hade komplexiteten och storleken i den utvecklande organisationen vuxit så pass mycket att utveckling formaliserades och styrdes upp enligt vad som uppfattades som ”state-of-the–art” vid tiden för projektets start.

Resultat blev en metodik med starkt fokus på kravhantering på bekostnad av arkitektur och design. Utvecklingsprocessen hade ett strikt sekventiellt arbetssätt. Införande av första generationens verktyg för modellbaserat arbetssätt gav en begränsad möjlighet att få feedback på en lösning innan realisering och integration.

Gripen E

För Gripen E kombineras och vidareutvecklas de starka sidorna i tidigare arbetssätt, vilket görs utifrån de erfarenheter som framkommit från utvecklingsarbetet med de tidigare Gripen varianterna.

Med utökad modelleringsförmåga kan man nu enkelt kommunicera en designlösning och simulera stora delar av systemet långt innan det är realiserat. Samtidigt drar man nytta av tidigare erfarenheter att arbeta med krav på ett ordnat sätt. Man använder kravhantering för att tydligt identifiera de systemegenskaper som ska verifieras.

I och med att utvecklingsorganisationen är stor så är arbetet med processer viktigt. För att få erforderlig flexibilitet och rationalitet i arbetet kan anpassningar göras av processer. Detta är väsentligt för att parallellt kunna arbeta med olika aspekter av utvecklingsarbetet.

Systems Engineering i framtiden

Idag kan stora delar av Gripen E systemet modelleras och simuleras med hög noggrannhet i en helt virtuell miljö. Nackdelen med dagens utvecklingsmiljö är att den är dimensionerad för att hantera modeller i en systemkonfiguration åt gången.

Nästa steg för förbättrat verktygsstöd blir att införa stöd för hantering av flera alternativa konfigurationer av modeller och på så sätt förenkla utvärdering av flera samtidiga alternativ, och inte minst förenkla parallell utveckling av komplexa system. Likaså ökas möjligheterna att integrera modeller från fler ingenjörsdomäner.

En förutsättning för denna utveckling är att egenskaper som identifieras i en modell kan tolkas maskinellt av andra modeller. Detta kräver vidare utveckling av större acceptans av öppna standarder som FMI (Functional Mock-up Interface). Den utvecklingen kommer att möjliggöra snabbare återkoppling inom utvecklingen av enskilda delsystem, men också ge snabbare svar på hur förändringar i delsystem slår på hela systemets förmåga.

Integration och simuleringsförmåga ger större konfidens i system innan de är realiserade, och återmatning för att säkra konfidens i skapade modeller är centralt för effektiv utveckling. Följaktligen räcker det inte att koppla samman modeller utan dessa måste även kontinuerligt förfinas baserat, på återmatning av mätningar från prov av realiserade komponenter och delsystem.

Denna återmatning är i dagsläget en manuell process. För automatisering krävs återigen överenskommelser som möjliggör maskinell tolkning av information generat av olika utvecklingssystem. Här ser framväxande standarder som OSLC (Open Services for Lifecycle Collaboration) lovande ut.

Redan idag är de system vi realiserar så pass komplexa att de endast med stora och kostsamma insatser kan verifieras med simulering och traditionell verifieringsmetodik. Under en lång tid har det påtalats att formella metoder är den enda framkomliga vägen för kostnadseffektiv verifiering.

Efter ett långt utvecklingsarbete börjar nu de formella metoderna bli så kapabla att de kan användas på komplexa, industriella system. Men ett brett industriellt införande kräver både omfattande utbildning av användarna och även ytterligare förenkling av verktygen, som implementerar de formella metoderna, så att de blir enklare att tillämpa.

Författarens reflektioner