OSLC är en del av OASIS Open Standards Network. OASIS i sig är ett internationellt ideellt konsortium som sammanför företag, regeringar, akademi och individer för att lösa kommunikationsutmaningar. OSLC-specifikationerna definierar hur livscykelapplikationer representerar, länkar till och accessar resurser baserat på etablerade standarder för Internet och länkade data, inklusive REST-arkitektur, RDF-specifikationer och HTTP-metoder. OSLC gör det kort sagt enklare att få verktyg att fungera tillsammans och dela data.
DET GAMLA SPELET: EN KUND – ETT FLYGPLAN
Bakgrunden är att Saab mellan, lite grovhugget, vart tionde till tjugonde år fått i uppdrag att utveckla nya stridsflygplan. En kund, ett flygplan, långa utvecklingstider och några få exportaffärer, har varit principen. Detta är vad Herzog kallar för, ”det gamla spelet, som vi har varit rätt duktiga på att hantera och som gällde under lång tid.”
Men efter 2010 började det hända saker som ställt mycket på huvudet:
– Vi fick ett partnerskap mellan Sverige och Brasilien gällande Gripen E (2013), vi fick ett utvecklingsjobb med en utländsk kund kring ”early warning” radarsystemet Global Eye och från Boeing fick vi en unik inbjudan att bli partners i utvecklingen av amerikanska flygvapnets träningsjet T-7 Red Hawk. Plötsligt sitter vi i ett helt nytt läge med multipla och parallella projekt, internationella operationer, utveckling och produktion på flera sajter och med krav på anpassningar till varierade regleringar och säkerhetsföreskrifter, summerar Herzog.
En helt ny och utmanande situation alltså, där en av de viktigaste poängerna är att det måste gå snabbt att sätta upp utvecklingsmiljöer för samverkan, samtidigt som man behöver erbjuda sina ingenjörer attraktiva utvecklingsmiljöer. Drygt tioåriga produktutvecklingsloopar och relaterade, ibland t o m med stödjande, IT-system på väg mot att bli obsoleta blev i ett slag något som var mindre lämpligt visavi de nya realiteterna.
– Vårt liv som företag har i detta förändrats och blivit väldigt mycket mer dynamiskt och komplicerat, säger Johan Tingström. Absolut inte negativt, tvärtom ser vi det som ett bevis på att vi har en bra internationell konkurrenskraft. Men vad skulle vi göra för att effektivisera produktframtagningen?
Vi ska titta på detta i dagens artikel, där PLM&ERP News förutom Herzog och Tingström, även diskuterat de här projekten med andra intressenter i Heliple-projektet, KTHs Jad El-Khoury på avdelningen för mekatronik och inbyggda system, Torbjörn Holm, senior konsult och technical fellow på Eurostep och de senares marknadsdirektör, Håkan Kårdén, alla involverade i Heliple-projektet.
EN STARK OCH INTEGRERAD UTVECKLINGSMODELL
En grundläggande faktor i sammanhanget är att man tar till sig insikten att varje gång man talar om utvecklingsarbete måste de lösningar som kommer upp på bordet ligga i linje med internationella ”best practice-lösningar”, konstaterar Erik Herzog.
– De som kommer till oss bör kunna känna att, ”Saab ligger ett steg före oss”, men samtidigt ska vi alltid förklara varför vi gör som vi gör i termer av internationell standard. Men vi måste också se till att kunna erbjuda en utvecklingsmiljö som är flexibel, säger han.
Detta innebär att man måste erbjuda en optimerad övergripande förmåga, kapabilitet att ta till sig det senaste av det senaste, vara bra på att anpassa sig till nya utvecklingsscenarier och det får inte bli för dyrt.
Processmässigt är man baserat på ISO15288, innebärande att de termer Saab använder är lätta att härleda internationellt. Man har också etablerat en stark utvecklingsmodell, som kombinerar den stabilitet som behövs för att bygga ett flygplan där resurserna som behövs är knappa, med kapabilitet att etablera agilt utvecklingsarbete. Enklare uttryckt: Koll på den övergripande arkitekturen, parallellt med förmåga att nå långsiktiga mål med utveckling i små steg, summerar systemarkitekten Johan Tingström.
– Vid varje litet steg måste vi utvärdera – vad gick bra, vad gick dåligt – och när vi sedan integrations-testat, typiskt i en ganska enkel simulator, så kan ett team leverera till ett ”lager” där vi då egentligen har alla våra komponenter tillgängliga. Samtidigt har vi en integrationsorganisation som tar ”legobitar” för att sätta ihop dem till mer eller mindre kompletta konfigurationer, som skulle kunna gå in i en avancerad teststation eller provflygplan.
Orsaken till att man skapat denna iterativa utvecklingsmodell är bl a att det som skapas är så komplext att ”just-in-time” på varje utvecklingsställe är svårnått: en del team blir klara enligt plan för att de inte stöter på några komplikationer; medan andra team blir försenade för att oväntade hinder kommit i vägen
– Men, tillägger Tingström, vi får aldrig låta de som är sena påverka vår integration.
SIEMENS TEAMCENTER ÄR PRODUKTDATARYGGRAD
Med denna bakgrund ska vi titta lite närmare på Genesis-arkitekturen och Heliple-projektets tankar om hur denna skulle kunna realiseras. Men först ta en titt på vilka mjukvaror man har:
• I dagsläget är Siemens Digital Industries Softwares cPDm-lösning Teamcenter Enterprise ryggrad för produktdata. I detta system hanteras produktstrukturer, systemstrukturer, ändringar- och konfiguration
• Mekanikdesignen bärs främst av olika versioner av Dassault Systemes (DS) CATIA. Huvudsakligen då V4 och V5, med tajt integration mot VPM (DS äldre PDM-system). För ett par specifika funktioner, som inte kan realiseras i ovanstående uppsättning, används 3DEXPERIENCE, vilket är DS V6-plattform.
• Till vissa områden används alltså V6 – som är den version som DS ursprungligen kallade ”3DEXPERIENCE” – men numera kallar man både V5- och V6-versionerna för 3DEXPERIENCE-lösningar.
• Ifråga om mjukvaruutveckling används primärt Atlassian som verktygssvit
• För systemdesign och simulering av system-av-system är det IBM Rhapsody och Dassaults Modelica-språkbaserade lösning Dymola som gäller, parallellt med MathWorks MATLAB och Simulink
• DOORS från IBM används för kravhantering
• Därtill kommer en mycket stor och heterogen flora av olika analysverktyg, dessa är både köpta och egenutvecklade.
INGENJÖRERNA FÅR HOPPA MELLAN LIKA ”FRONT-END-MILJÖER”
Totalt sett har man nått bra resultat i denna miljö, även om det finns nackdelar:
– En sådan är att våra ingenjörer får hoppa mellan olika ”front-end-miljöer”, hävdar Erik Herzog. Det blir mycket fram-och-tillbaka beroende på att applikationerna i miljöerna inte är optimalt kopplade till varandra och dessutom tenderar att åldras, vilket kan vara rätt frustrerande för våra ingenjörer. Så vad blir vårt nästa steg? Det är här vi har talat mycket om den s k ”genesis-modellen”.
Genesis-modellen, som nämndes i ingressen, är en tankemodell som såg sitt ljus för ca två år sedan. Sedan dess har ett samarbete med KTH utvecklats där man hjälpt till med att studera förutsättningarna. Bland annat togs en rapport fram förra året som pekar ut potentialen för OSLC.
I Genesis-rapporten påpekas att nackdelar med existerande PLM-lösningar – Teamcenter eller DS 3DEXPERIENCE, båda lösningar som man redan har – är att dessa ger ett oönskat starkt beroende av en enda PLM-leverantör. Det samma gäller om man skulle välja en lösning som Syndelia (InterCAX) eller Aras PLM. Man vill helt enkelt undvika att få ett starkt beroende till en enda leverantör.
PRODUKTER SOM LEVER LÄNGRE ÄN PLM-SYSTEMEN
Men i dagsläget har Saab Aeronautics systemarkitektur alltså flera inslag av icke-integrerade verktyg. Man ska måhända i sammanhanget minnas att exempelvis grundinstallationen av Teamcenter Enterprise är från 2007, vilket är en plattform som ligger en bra bit ifrån vad samma lösning kan prestera idag, även om Saab Aeronautics uppgraderat en del vartefter tiden gått.
På sista raden kan man dock i dagens systemmiljö notera framför allt tre effekter: många manuella import- och export-aktiviteter och begränsad spårbarhet om, eller när, man inte kan utnyttja proprietära gränssnitt.
En konklusion av ovanstående landar i att en ny arkitektur på PLM-stödet skulle kunna ge en hel del; men hur ser förutsättningarna för ett nytt system ut?
Svaret är ett antal i Genesis-rapporten listade punkter, där en primär bakgrund som man skulle vilja komma tillrätta med, är detta med att de produkter man utvecklar har en tendens att leva längre än PLM-systemens versioner.
När man närmare betraktar den förteckning av kapabiliteter Saab Aeronautics skulle vilja ha ut av systemen blir det tydligt att siktet är inställt på det som analytikerna på Gartner och CIMdata gemensamt definierat som s k Product Innovation Platforms, (PIP).
Förenklat beskrivet går detta ut på att den plattform man bygger upp ska präglas av möjligheten att byta ut eller hoppa mellan modulära enheter i systemen, utan omfattande migrationsaktiviteter eller anpassningar. Detta ser man som absolut framgångskritiskt.
Här är parametrarna:
- Rakt igenom ska det vara möjligt att etablera livcykelhantering
- Det ska finnas möjligheter till skräddarsytt stöd i discipliner som systemhantering, mekanik, mjukvara och elektronik
- Man vill ha modulära plattformslösningar där individuella domänmiljöer kan bytas ut utan integrationsproblem
- Saab, som en liten leverantör, kommer aldrig kunna påverka alla leverantörer att använda samma system. Därför finns behov av en produktdatahanteringsplatform baserad på internationella standarder så som Eurosteps Share-A-Space.
FULLT INTEGRERADE, MEN UTBYTBARA MODULER
Den arkitektur man önskar sig är, som en konsekvens av bakgrunden ovan, en struktur som ger stöd för alla ingenjörs- och hanteringsaktiviteter inom varje disciplin. Samtidigt ska dessa vara fullt integrerade i en företagstäckande federativ plattform. En plattform vars individuella komponenter kan uppgraderas oberoende av de andra på plattformen.
Alla processer relaterade till ingenjörsprocesser, som systemutveckling, mjukvaruutveckling eller mekanikutveckling ska kunna göras i dedicerade miljöer. I detta ska processer och flöden kunna ske med spårbarhet, lagringsbarhet och delbarhet, givetvis med relevanta tillgänglighets-begränsningar för alla inom sånt som projektledning, konfigurationsansvar och relaterat ingenjörsarbete.
Johan Tingström igen:
– Genesis PLM är i första hand tillämpbar när vi börjar om på ny kula för kommande produkter. Tittar vi på hur man genomför normalt ingenjörsarbete så ser det ut så här: Det är den traditionella sekvensen som gäller – kravhantering, design, realisering, integrering, verifiering och specifikt för det vi utvecklar, som ju är kritiska system, deklarationer att allt är byggt enligt design. Detta gäller egentligen för alla ingenjörsdomäner.
– Vad vi skulle vilja är att våra systemingenjörer hela dagen skulle kunna hålla till i en systems engineering-miljö, våra mekanikingenjörer i en mekanikmiljö och mjukvaruutvecklarna i en ALM-miljö (Application Lifecycle Management). Annat kan tillkomma, men detta upplägg skulle vi vilja ha som grundläggande princip. Ovanpå det skulle vi sedan behöva se till att vi kan hålla ihop tillgängliggöra och spåra produktdata, tillägger Herzog.
Återigen, tittar man på Saab Aeronautics processer så är fyra integrationspunkter av stor vikt:
• Koll på kravspårbarhet
• Koll på konfigurationsstrukturen
• Koll på ändringarna och
• Koll på den realiserade konfigurationen.
– Givet att produkterna lever så länge så kommer det också att behövas ett långtidsarkiv. Där vi på ett strukturerat sätt kan garantera att produktdata motsvarar det vi levererat, tillägger Herzog.
EN SAMMANHÅLLEN SINGULÄR MILJÖ
– Om vi tänker oss att vi skulle ha en sådan miljö istället, och om vi tänker oss att vi dessutom ska kunna byta ut komponenter oberoende av varandra, ja, då vet vi som sagt att vi behöver ha något slags långsiktigt arkiv där man verkligen kan långtidsspara data. Men samtidigt vill vi hålla ingenjörerna i integrerade miljöer.
Här hävdar Erik Herzog att det modulära upplägget har stor betydelse för att man ska kunna dels maximera automationen som en leverantör kan ge företaget och dels se till att man har alla ingenjörer som jobbar med en nod i produktstrukturerna i samma miljö. Detta gäller f ö även ledarskapet och konfigurationsledarna; så håll ihop miljöerna alltså.
Med en modulär uppbyggnad kan man också hålla ihop allt i en singulär miljö.
Erik Herzog förklarar:
– Det vi försöker skapa är en federation av likvärdiga miljöer, som möjliggör att medarbetarna jobbar i samma miljö och ser samma information. Vi accepterar att vi duplicerar förmågor, så att en mjukvarukrav-förmåga kan mycket väl skilja sig från en systemingenjörskrav-förmåga, men det viktiga är att vi säkerställer att vi kan spåra mellan kraven, säger Saab Aeronautics technical fellow.
– Nästa del är att – eftersom vi vet att de här miljöerna s a s kommer att födas, leva och dö med olika livcyklar och olika frekvens – vi vill kunna byta ut en mjukvara, där utvecklingen sker snabbast, och kanske ersätta den med någon annan. Och detta utan att det påverkar hela landskapet.
Det ska vara lätt att byta ut det som börjar bli gammalt helt enkelt.
ETT MODULÄRT PLM-SYSTEM PÅ ÖNSKELISTAN
Men det finns fler aspekter på PIP-temat. Saabs ”enterprise architect”, Johan Tingström, pekar på krav som relaterar till samarbeten i nya konstellationer:
– Ett samarbete kan innebära att man jobbar inom ramen för ett system, medan ett annat samarbete kräver ytterligare ett annat system. Här måste vi ha flexibilitet i denna typ av nya konstellationer också. Därför är själva systemets livscykel en sak, men vid sidan av detta får man ju beakta möjligheten av att kunna möta nya partners system också.
Modularitet i PLM-stödet ligger alltså högt på önskelistan. Samtidigt måste spårbarhet mellan data som befinner sig i olika produktdiscipliner säkras. Hur då?
– Tittar vi på våra egna processer är det fyra olika dimensioner vi behöver tänka på, konstaterar Erik Herzog: Kravspårbarhet, produktstrukturen, ändringar och realisering. Tittar vi bakåt i tiden var det tillräckligt att man gjorde en länk mellan t ex två olika krav. Så var man färdig. Men för framtiden kommer detta inte att räcka. Vi måste då också ha konfigurationskontroll av den här länken, så att den går till rätt version av en annan struktur.
För att det ska vara realiserbart finns det ett par saker som måste uppnås:
– Integration måste kunna realiseras till låg kostnad. Dvs, få integrationspunkter kombinerat med standardiserade mekanismer. Här anser vi att OSLC-standarden ger oss rätt kapabilitet att uppnå denna förmåga.
TESTER TILLSAMMANS MED KTH
Det är också här man börjat göra tester i mindre projekt och här kommer KTHs, Kungliga Tekniska Högskolan, Jad El-Khoury in i bilden. Han har hjälpt Saab Aeronautics att skapa en integration mellan IBMs utvecklingsmiljö, Jazz, och Siemens Digital Industries ALM-miljö, Polarion.
– Det stämmer. I ett mindre experiment testade vi de tekniska bitarna i fyra-fem olika scenarios som vi fick från Saab och lyckades göra det ”out-of-the-box” och få komponenterna att ”prata med varandra”. Det gick bra; som alltid blir det lite initialt ”strul”, men det gick snabbt att åtgärda, säger El Khoury. Krav- och ändringsscenarierna var kort sagt relativt lätta att realisera.
– Däremot kunde vi i inte göra produktstrukturen i detta läge för att Polarion saknade koncept för detta, fyller Erik Herzog i och fortsätter: ”Men det som kunde funka funkade. Vi hade ju inte mycket pengar till detta projekt, men det tog hur som helst bara ca 40 timmar att etablera integrationen, där större delen av problemet var en webbrowser-inställning.”
– Precis, tillägger Jad El-Khoury, det handlade om säkerhetsaspekterna för att få de här maskinerna och webbläsarna att s a s godkänna varandra. Mycket i de här sammanhangen har med just säkerhetsaspekterna att göra i kommunikationen mellan två olika system. I detta fall jobbade vi med IBMs molnsystem för Norden å ena sidan och KTHs egna system å andra sidan. I båda fallen finns en hel del säkerhetsspärrar inbyggda, vilka kan vara lite knepiga att ta sig runt.
VÄGEN FRAMÅT OCH OSLC-STANDARDEN
Men den goda nyheten är i alla fall att möjligheten fanns att länka två olika system ”out-of-the-box” beroende på att de, i alla fall till vissa nivåer, följer OSLC-standarden. Detta är bra och något av kärnan i hur man nu tänker sig att gå vidare. Herzog exemplifierar det hela:
– Bara för att ta exempel, typiskt då i en mjukvarumiljö – det skulle kunna vara t ex Siemens ALM-lösning, Polarion – så skulle vi på en produkt, eller produktelement, kunna ha ett antal krav. Det viktiga är att vi då från software engineering-sidan skulle kunna spåra dem upp till de relaterade kraven på system engineering-sidan och förstå varifrån de kommer i en systemmiljö. Vi behöver kunna etablera en produktstruktur mellan verktygsgränserna. Plus att ändringsärenden också måste kunna flöda fram och tillbaka i detta. Likväl som att vi när något skapats måste kunna hålla koll på vad vi realiserat.
INTERAKTION VIA STANDARDS
Tittar vi sedan framåt i resans riktning har vi nästa del att väga in: leverantörskedjans roll och kontaktpunkter. Johan Tingström:
– Just det, och här har vi t ex Eurostep med sin ShareAspace-lösning. Vi ser allmänt kring detta samverkansområde att vi vill digitalisera oss mer och då är detta med att kunna ta in fingranulär data, oberoende av källformat, väldigt viktigt för oss.
De stora leverantörerna av t ex flygplan, menar han, kan ju s a s ”diktera” för sina leverantörer i kedjan vilka verktyg man vill att de ska använda.
– Men vi kommer ju aldrig att vara i en sådan position, utan för oss gäller att vi vill att vår interaktion ska ske vi standardformat. STEP t ex. Och om vi då tittar på vår ”collaboration environment”, som skulle kunna vara ShareAspace, så kan ju vi göra vår produktutveckling i vår interna miljö; och så kan vi för en komponent, t ex en ADC, ”Air Data Computer”, ta fram intressentkrav som vi skickar ut till ett flertal olika leverantörer. Vi får förstås se till att vi spårar dom till våra överliggande krav, samtidigt som vi kan flytta ut kravspecen till en kollaborationsplattform och tillgängliggöra den för våra leverantörer. De skulle sedan kunna svara med sin egen kravspec, design, verifikation och deklaration. Samtidigt skulle vi i denna samverkansmiljö kunna skapa spårbarhet mot de krav vi skickat ut, men även in mot vår egen miljö.
HELIPLE-PROJEKTET – EN VÄG IN I FRAMTIDEN?
Detta är alltså ett användningsfall man vill göra inom ramen för Heliple-projektet. Dels för att säkerställa om det är ekonomiskt försvarbart att be en leverantör att satsa på OSLC-gränssnitt, dels också frågan om vad man kan förvänta sig:
– Precis, kommer detta att fungera i en storskalig miljö, undrar Erik Herzog. Detta är två av målsättningarna med Heliple-projektet.
– Sen har vi ju, om vi tittar på bilden av utvecklingsmodellen ovan, sånt som att vi kommer att behöva göra ändringsärenden från den övergripande systemnivån ner till den mer ändringsdrivna utvecklingen. Och den kommer ju att gå från överliggande systemnivå ner till mjukvara, där vi f ö kommer att hitta mindre ärenden. Här kommer då i konsekvens med det tidigare resonemanget denna länk att vara en OSLC-länk (länken är markerad i rött på bilden ovan).
I det 18 månader långa Heliple-projektet avser man nu att undersöka möjligheterna att stödja kunskapen om och att använda OSLC. Deltagare är Saab Aeronautics, KTH och Eurostep.
Johan Tingström summerar i kortform omfattningen:
• Man ska promota Genesis-arkitekturens mönster, som redogjorts för ovan
• Skaffa sig erfarenheter av att skapa OSLC-gränssnitt
• Förbättra generering av verktyg i OSLC-gränssnittet
• Demonstrera kraften i OSLC
– Som en bonus skulle resultatet av detta projekt kunna bli att det blir enklare för mindre aktörer på systemmarkanden att komma in, säger han och tillägger: ”Idag kan det vara svårt för mindre företag att, trots innovativa lösningar, komma in hos större företag eller organisationer då dessa ofta har höga krav på sina leverantörer i form av långsiktig stabilitet. Naturligtvis är detta något vi också måste ha med i våra utvärderingar. De företag vi väljer att samarbeta med behöver vara tillräckligt stora för att kunna fortsätta att utveckla sitt system och ha tillräckligt med pengar för att inte försvinna.
UTMANINGAR MAN INTE ÄR ENSAMMA OM INOM AEROSPACE & DEFENSE
Detta är summeringsvis vad man vill åstadkomma och det hela är illustrativt för komplexiteten man möter ifråga om att utveckla stridsflygplan. Det ska också sägas att Saab Aeronautics långt ifrån är ensamma om den problematik man pekar på. I en kommande artikel har PLM&ERP News tittat närmare också på de utmaningar man har inom en av världens ledande aktörer inom industrisegmentet Aerospace & Defense och när det gäller utveckling av stridsflygplan, amerikanska Lockheed Martin, som bl a lett utvecklingen av F-35 Lightning II eller Joint Strike Fighter (JSF). Detta projekt är en av Lockheed Martins stora satsningar. Med tiden – projektet startade 2006 – är ett typiskt problem för alla modellprogram, till exempel F-35, tendensen att man hamnar i en situation med ett antal ofta något okopplade lösningar. Specifik programvara för specifika domäner resulterar ofta i behov av manuella ingrepp vid överföring av resultat från en ände till en annan.
Inget är lätt, men med Heliple-projektet har Saab Aeronautics angett en plausibel väg att möta de krav och interaktionsmöjligheter man behöver för att rationalisera, skapa den mer flexibla struktur som krävs för att klara komplexitet, kombinerat med spårbarhet, säkerhetsaspekter och förmåga att hålla dataintegritet över tid, som är en kärnproblematik när man talar om 30 till 50-åriga livcyklar.
Som sagt, en grannlaga uppgift som det ska bli mycket spännande att följa.
