U-båten A26 byggs i fem sektioner. Man har 140 system ombord, alltifrån lednings- och sensorsystem till vapensystem, energiomvandlare, luftreningslösningar, o s v. Normalt omfattar U-båt A26 runt 600 000 komponenter på installationsnivå, men bryter man ner det i mindre delar blir det oerhört mycket mer. Annat är att 100 kilometer kabel går år, liksom 10 000 unika rör, o s v. Allt som ingår i denna tajt integrerade farkost andas komplexitet och tät systempackning inom ramen för en tämligen liten yta, som dessutom ska föda en besättning på 25 man.
U-båtarna designas på Saab Kockums i Helsingborg, Karlskrona och Malmö; här finns också testlabb och utveckling av Stirling-motorerna till U-båtarna. Underhåll görs bl a på Muskö, men även de andra U-båtsrelaterade anläggningarna kan vara inblandade i detta. Detta emedan ytfartygsbitarna är lokaliserade till Karlskrona.
Delarna som bygger ett U-båtssystem
9 000 krav, 20 000 funktions- och systemdrivande lösningar, ca 100 000 ritningar/3D-modeller och dryg 600 000 övriga komponenter är den övergripande mängden delar som konstituerar ett U-båtssystem av A26-typen. Plus det som tillkommer för varje modell under livscykeln, som beräknas till minst 30 år, konstaterar Saab Kockums Pål Almén.
– Ska U-båten behålla sin operativa effekt i ett högteknologiskt föränderligt landskap och över tid gäller det ju att uppdatera och uppgradera vartefter nya teknologier når mogna applikationsnivåer. Vilket i sin tur innebär moderniseringstillägg, utbildningsinsatser, utbyten av slitna delar i samband med underhåll och liknande växer till omfattande insatser att administrera.
Men det finns mer som ökar komplexiteten:
– Nya modeller börjar ofta med ett par systerfartyg. Men nya kunder som satsar på modellen vill ha egna varianter av U-båtarna, vilket ställer stora krav på förmågan till effektiv varianthantering. Vi går alltså från start med en ”enkel” konfiguration till att över tid, säg 30, 40 eller t o m 50 år ha väldigt många varianter och variabler i en modellserie. Lägg till detta underhåll och till detta kopplade bitar. Även om inte alla är aktuella samtidigt så ligger en viss spretighet i sakens natur.
– Sen handlar det om att ha koll på kostnader och ledtider och liknande. Vi ska ju t ex i det senare fallet gärna vara snabbare än våra konkurrenter.
Almén tillägger att det också är en komplicerande utmaning i att under de 7-8 år U-båten tar att bygga kan det ju hända en hel del på teknologi-sidan som riskerar att lösningar blir obsoleta redan innan den är klar.
– Dels måste vi ju behålla alla s a s gamla versioner av saker som finns ombord, parallellt med att teknologiska nyheter måste implementeras under utvecklings- och byggresans gång. Detta är tufft att matcha, ja, men vi har metodik för att lösa saken.
Satsning på att etablera MBD, Modell-Baserad Definition
Gigantiska volymer data och komplexa produktframtagnings- och relaterade administrativa processer alltså. Hur håller man reda på detta? Klart är att PLM-verktygen spelar en viktig roll. Så här ser arsenalen ut:
De kommersiella huvudverktygen på PLM-sidan är:
* IBM Doors för kravhantering
* PTCs CREO för CAD-design
* PTCs Windchill för cPDm (collaborative Product Definition management)
* AVEVA ERM på ERP-sidan
* BAE Systems/Eurosteps ShareAspace som en ryggrad i det digitala tråden-koncept där denna PCLS-baserade (Product Lifecycle Support-standarden) plattform knyter ihop mjukvaror och data från de andra ovan nämnda applikationerna. Hur då? Vi ska titta på saken längre ner i artikeln.
För att förstå komplexiteten i hur informationsströmmarna mellan dessa komponenter måste fungera för att stödja smidiga flöden och Alméns tankar om MBD (Model-Based Definition), concurrent engineering (parallellt utvecklingsarbete i alla delar), digitala tvillingar och tråden-konceptet man tagit sikte på krävs att vi går lite närmare in på de enorma datavolymerna som U-båtsutvecklingen handlar om och hur detta sedan ska omsättas i ett över 30-årigt underhålls- och moderniseringsarbete.
MBD, digital tvillingar och trådar tar hand om livscykeln för A26
Hur ser livscykeln för en U-båt ut? Efter ett till två år har man ett första obligatoriskt underhåll, som sedan återkommer vartannat år.
– Detta tar ca tio veckor och omfattar alltså 500 till 2 000 nya parter. Sedan blir det mer omfattande underhåll vart 8:e år med 10 000 till 50 000 nya parter och nya mjukvaror beroende på vilken typ av teknologisk modernisering vi talar om. Ska man klara att ha både djupunderhåll parallellt med modifieringar på i det första fallet tio veckor måste saker och ting vara väl förberedda, det som ska bytas ut eller adderas måste s a s vara tillverkat och klart att montera in. Underhållsdelarna givetvis inkluderade i detta.
Här är sånt som digitala tvilling- och tråden koncept A och O.
– Vi har hela tiden produkten, eller ännu noggrannare, produkt-individen, snurrandes i olika stadier i den digitala tråden. Design av det som tillhör nästa modifiering, eller därpå kommande uppgraderingar, nästa underhåll, eller sånt som tillverkas ”just nu” är exempel på detta. Parallellt håller vi på marknadssidan reda på och kommunicerar in i organisationen vad som ska ske vi nästa uppgradering.
Precis som noterades i ingressen speglas detta principiellt i tre parallella digitala tvillingar:
- En för U-båten under utveckling och tillverkning
- En för U-båten under drift, ”segling”
- En för U-båtens underhåll
Att klara detta med manuell pappershantering fungerar knappast, här blir alltså PLM-apparaten en viktig del i hela värdekedjan.
– Sedan kan man konstatera att detta med digital tvilling betyder lite olika saker på och för olika individer. För designen och det interna utvecklingsarbetet är det som sagt en variant, för kunden är det en helt annan, den seglande tvillingen, kommenterar Saab Kockums IT-ledare.
Parallella processer i utvecklingsarbetet trycker ihop utvecklingscykeln
En allmän strävan i produktframtagningsarbetet är att utveckla en modell för integrerad produktframtagning, säger Pål Almén.
Poängen är att s a s ”trycka ihop och in” dessa flöden under varandra. Förändringarna på tidslinjen är stor. Från att ha varit linjära händelser, med ett flöde där åtgärderna på tidslinjen följer i svit efter varandra, till att dras igång parallellt, med bara en minimal förskjutning på tidslinjen. På så vis vinner man en hel del tid i slutänden.
– Precis, det är ’concurrent engineering’ som gäller. Vi har i detta gått från en ”vattenfalls-liknande” modell till utveckling i parallella spår. Detta kräver sin man och tar tid att utveckla, där man kontinuerligt tittar på vad som behöver ändras i metodik eller justeras processuellt, och hur ansvarsområden och kompetens behöver utvecklas, se ut, vässas och anpassas till effektiva informationsflöden, säger Pål Almén och fortsätter:
– Ett annat sätt att uttrycka detta är att man ska ha ett samarbete och PLM-systemet är en förutsättning, inte lösningen, för att detta ska löpa smidigt. Istället för att tänka ”när jag är färdig kan du börja,” ska man tänka: ”När jag är färdig kan du bli färdig.” Samsyn krävs alltså i detta. Men det kräver också att man bryter upp produkten, eller i vårt fall vad som ska levereras ut på golvet.
Han pekar också på att man på utvecklingssidan gjort mycket för att etablera detta med MBD, alltså Model-Based Definition, t ex för att automatisera rörtillverkningen, från specifikation till färdigtillverkat rör. Inget rör är någonsin likt det andra, så detta är en viktig rationalitet att sträva efter, menar Almén.
Till saken hör att modellbaserad definition grovt tillyxat handlar om att utveckla en praxis att använda 3D-modeller (3D CAD) för att definiera enskilda komponenter och produktsammansättningar. Hur kommer Saab Kockums digitala verktygsuppsättning – med IBM Doors (kravhantering), PTCs Creo (design av 3D-modeller), Windchill (PDM), AVEVA ERM (ERP), och BAE Systems/Eurosteps ShareAspace – in i detta på ett övergripande plan?
En söker informationshub
En särskilt intressant uppgift i flödet har ShareAspace. Lösningen integrerar informationen/data från de andra olika engineering-domänerna; sånt som vanlig yt- och mekanik-design, el-design, etc, för att bereda informationen från de olika källorna för tillverkning, ERP osv. Integrationerna mellan systemen är baserade på det ”neutrala” STEP-formatet och PLCS, vilket gör att en mer ”universell” kompatibilitet skapas. Alla kan utan större problem tillgängliggöra sig, läsa och hantera all i de olika designerna ingående data. I nästa steg kan man tänka sig att informationen associerad till de olika 3D-modellerna och kopplade hanteringsprocesser kan användas också i underhålls- och uppgraderingsarbetet, allt relaterat till vem som får ha tillgång till vad. ShareAspace-hubben blir alltså en säker informationscentral.
Ska man ta en parallell från automotive-industrin, så fungerar en ShareAspace-baserad hub som länk mellan Renault och Nissan i de bitar där bolagen samarbetar för att dela parter i produktutvecklingsarbetet.
Arbetet med att bygga alla de processer som ingår i Saab Kockums MBD-modell började med att Almén och hans medarbetare bröt ned upplägget till frågor om vilka förmågor som behövdes.
– Vi talar allmänt här om ”front loading”, säger Almén. Men syftet med detta är inte att stoppa in informationen tidigt, utan snarare att samarbeta tidigt för att bli färdiga tidigt enligt den plan man har.
Så här ser det schematiskt ut:
M&S/koncept
<— System
<— Konstruktion
<— Inköp
<— Produktion
<— ILS/underhåll
Ju mer man kan skjuta in de här olika processerna ”under” varandra med tidigare starter, desto snabbare blir man klar med helheten. Alla kan påbörja sin relaterade process tidigare, vilket illustrerades i den process-karta som togs fram.
Den MBD-processkarta som togs fram illustrerade detta tydligt med sånt som produktmodeller, rätt vy i rätt sammanhang och liknande.
– Egentligen handlar detta flöde om att medarbetare i processen ska få den information eller data man alltid behövt, men nu kan det ske tidigare i processen. Ofta följer nu processkartan det som. redan funnits på plats på nominell nivå. Utmaningen är lite att etablera en bredare syn bland alla medarbetare på helheten i utvecklingsprocessen. Folk har ju alltid sett sina delar, men nu måste de titta ”lite åt sidorna” också. Men process-kartan talar vi egentligen om en ’kustomisering’ av hur den tidigare nominella nivån nu ska tillämpas, kommenterar Pål Almén.
Från processplan till CAD, eBOM, mBOM och serviceBOM
Så, hur har man byggt upp detta? Processuellt ser strukturen ut så här, Pål Almén igen:
- ”Processplanen håller ihop det hela på verkstadsgolvet och är i något avseende utgående från samma objekt i varje enskild BOM-lista. Ofta handlar det om samma objekt i databasen; det är bara att den har flera egenskaper samtidigt. Det finns ofta alltså ett släktskap mellan objekten. Detta måste de olika domäningenjörerna känna till för att dels kunna söka efter dem och dels blir det dyrt och ineffektivt om man ska skapa sånt som redan s a s finns en gång till.”
- ”Vi har en system BOM (Bill of Material) med de 20 000 funktionskomponenterna, eller de logiska objekt som sedan realiseras som komponenter i mBOMen (”manufacturing BOM”, tillverknings-BOM). Detta handlar om sånt som pumpar, ventiler, datorer och annat. I och med att vi har 140 integrerade system så blir det egen disciplin i sig.”
- ”Sen har vi CAD-biten som definierar hur saker ser ut och var de sitter placerade.”
- Vidare: ”eBOM, alltså ”engineering BOM” – en är en artikellista skapad i CADen och har till uppgift att spegla hur produkten är konstruerad och den tjänar också som underlag till mBOMen. ”Den är lite av hjärtat i vår produktmodell,” tillägger Almén och fortsätter: ”Den är då en ’överladdad’ eBOM, vilket betyder att vartefter varianter och nya optioner tillkommer har vi också ett options- och variantfilter.” En och samma eBOM alltså, där man kan filtera fram hur olika individer av U-båtsmodellen ser ut.
- ”Därefter har vi mBOMen, som egentligen är eBOMen omsorterad till arbetspaket mot produktionsaktiviteter, vilket i U-båtsfallet handlar om ca 600 000 delar in i 3 000 aktiviteter.”
- Service-BOMen är nästa huvudkategori och här talar vi om underhållsaspekterna, eller i U-båt A26, ILS-data, på svenska, integrerat underhållsstöd. Förkortningen står för ”Integrated Logistics Support”, vilket innefattar alla åtgärder för ett effektivt underhåll.
Integrerat underhållsarbete (ILS) kopplar till hela produkthistoriken
Med denna utvecklingsprocess mer definierad ska vi slutligen titta till kopplingarna till underhållsbitarna, som i en komplex produkt som A26 U-båten och i skenet av en 30-årig, eller t o m längre livscykel, måste vara tätt sammanlänkad med data om hur fartyget är uppbyggt, uppdaterat, och underhållet. I detta är alltså ILS, Integrerat underhållsstöd, en nyckel.
Allmänt och innehållsligt är ILS en ledningsprocess som främst används inom försvarsindustrin, till exempel av Försvarets Materielverk (FMV) för att säkerställa att ett system eller en produkt kan brukas, underhållas och förvaras till låga kostnader, samt uppfylla höga krav på tillförlitlighet, driftsäkerhet och underhållsmässighet.
På Wikipedia förklaras det närmare så här: ”Integrated” avser samspelet mellan olika underhållselement såsom verktyg, manualer och reservdelar, ”Logistics” syftar på själva underhållsprocessen och ”Support” syftar på stöd från processer och hjälpmedel (underhållselement). Resultatet av ett lyckat ILS-arbete är att reservdelar, specialverktyg, dokumentation och utbildning finns tillgänglig vid leverans, samt att reservdelsförsörjningen och erforderlig expertkompetens finns tillgänglig under hela produktcykeln.
Till denna position strävar alltså Saab Kockums, Pål Almén och hans medarbetare.
– Ja, vårt upplägg handlar om just detta; att planera för att kunna följa upp på ett så effektivt sätt som möjligt. Vad menar jag med det? Om man inte kan definiera leveranserna så att folk förstår vad deras leverans är blir det svårt. Det gäller att semantik och beteckningar på saker och ting är samma som återkommer inom ramen för systemen som bygger upp produkten. Inte minst för att andra ska kunna spåra dem vid t ex underhållet.
Grundläggande pusselbitar på U-båtområdet är komponentbibliotek, där man i möjligaste mån ska kunna plocka de som behövs, inte minst gällande underhållsbitarna.
– ServiceBOMen spelar en huvudroll i detta. Vi gör underhållsanalys på runt 20 000 objekt som relaterar till denna. Eller mellan 5 000 och 10 000 reservdelar som s a s tillhör katalogen, säger Almén och tillägger:
– Det mesta som kräver service sitter oftast från början i systemBOMen. Men sen tittar man förstås också i detaljkonstruktionen och sånt som finns i komponentbiblioteket. Det här är ett sätt att ge underhållsanalysen ett konfigurationsstyrt underlag att jobba med. Så vår serviceBOM är systemorienterad, men det finns förstås många aspekter på service, men detta är några av ingredienserna
– Vi gör också något vi kallar för service-parter och då väljer vi sånt som går i analys och visar sig vara värda att titta på och utifrån detta genererar vi behövliga reservdelar. Ofta finns dessa reservdelar redan i eBOMen, men ibland måste de skapas för att de är på en annan nivå vid underhållsläget. Egenproducerat tas direkt från eBOM till serviceBOM. Vi betraktar f ö också installerad mjukvara som en underhållsaspekt.
– Service-part avseende inköpt komponent är en annan aspekt. Den går till något som heter SICS, vilket är vårt LSAR-verktyg för underhållsanalys, vår underhålls databas, där vi lagrar data kring underhåll och föreslaget underhåll från våra leverantörer.
Underlag till reservdelskatalogen bygger på att man tar strukturer etc från eBOM, eller om det kommer från leverantörer kan man ta det som STEP-filer. Man genererar en representation av service-parten i Creo Illustrator som exporteras till rätt ställe.
PLCer och uppdatering av programvaror
Programvaror och uppdateringar är ett eget kapitel, men de kopplas ofta till en komponent.
– Så är det, ta t ex en PLC (Programmable Logic Coontroller). Vill man ha den som en standardkomponent och de dessutom finns på flera olika ställen med varierade kontrollfunktioner har PLCn ofta många möjliga godkända programvaror. I detta läge vill man använda den korrekta service-part som behövs, alltså med korrekt programvara för ändamålet också med information om var de exakt sitter i båten. Här måste man då veta vilka unika programinstallationer som gjorts på denna PLC. Alltså får man här information som säger: ”Ska du byta denna PLC ska den vara laddad med denna mjukvara.” Sålunda får man här underhållsinformation som har kopplat exakt vilken programvara en särskild PLC ska vara laddad med.
På sista raden kan konstateras att Saab Kockums ILS-ingenjörer har en hel del att fundera på och ta hänsyn till när man lägger upp koncepten.
Framtiden då? Pål Almén:
– Ja, vi har ju som sagt några ILS-databaser, men man ser ju också att det finns datoriserade ”maintenance management-system”, både ombord och vid kaj. Detta gör att vi vill komma i ett läge där man automatiserat och proaktivt kan kommunicera underhållsbehov. Inte minst då t ex relaterat till sånt som vi gjort upp för redan i tidigare faser i produktframtagningsarbetet. Våra kunder vill kort sagt också köra mer tillstånds-baserat underhåll, de vill mäta mer och logga mer. Detta måste vi samla på oss och datorisera för att kunna göra. Vi har inte längre så många medarbetare som stannar i 20-30 år och som vet när det exempelvis är dags att byta den pumpen och den ventilen, etc. Här har vi en del att göra…
