Utifrån den bredare systemsyn som beskrivits i tidigare blogginlägg blir LSA-arbetet centralt i det övergripande designarbetet. Utifrån driftprofil och underhållskoncept kan man med en strukturerad metodik göra rätt avvägning mellan det tekniska systemets inbyggda egenskaper och underhållslösningens utformande.
Över åren har det utvecklats ett antal standarder och metoder för ILS (Integrated Logistics Support) och LSA (Logistic Support Analysis)1.
I samband med att det europeiska stridsflygplanet Eurofighter skulle utvecklas gjordes ett större arbete med att ta fram gemensamma ILS-standarder, inklusive en gemensam informationsmodell, så att många olika leverantörer skulle kunna jobba gemensamt med olika delar av systemet. Det resulterade i vad som kallas S-Series Integrated Logistics Support (ILS) specifications som förvaltas av AeroSpace and Defense Industries Association of Europe – ASD2. Den del som handlar om LSA kallas S3000L3.
Vilka är då de analyser som utgör LSA-arbetet? En viss variation förekommer mellan olika standarder och behoven kan se olika ut mellan olika organisationer. Behoven varierar också mellan olika typer av projekt, beroende bl.a. på hur känd den tekniska lösningen är sen tidigare (behovet av nyutveckling). Några typiska analyser som bör övervägas är:
- Human factors analysis
- FME(C)A – Failure Modes Effects (and Criticality) Analysis
- Damage and special events analysis
- Logistic related operations analysis
- Level of repair analysis (LORA)
- Maintenance task analysis
- Software support analysis
- Obsolescence analysis
- Life cycle cost (LCC) analysis
Human factors analysis handlar kortfattat om att titta på dels hur underhållet är organiserat (underhållskonceptet), ex.vis storlek på underhållsgruppen (vi kan tänka oss ett depåstopp under ett F1-lopp eller ett militärt förband som har begränsningar i hur stor reparationsenhet man kan ha). Dels handlar det också om att titta på fysiska begränsningar hos människan och vilka uppgifter som är rimliga att lägga på brukaren av materielen eller på underhållspersonalen.
FME(C)A används i produktutvecklingen för att förstå hur produkten går sönder och därigenom kan man beräkna tillförlitlighetssiffror (reliability) och se om man behöver förändra konstruktionen för att möta de tekniska kraven på produkten. Ur ett underhållsperspektiv kan felmoder som leder till samma underhållsåtgärd grupperas ihop och resultatet (LSA-FMEA) användas för att analysera behovet av förebyggande och avhjälpande underhåll.
Damage and special events analysis tittar på skador på systemet som kan uppkomma under användningen av detsamma. Har vi en ballasterad bana som kan orsaka stensprut på känsliga delar på undersidan av korgen eller i boggin? Hur skyddat är systemet vid olyckor? Vid åsknedslag? För sabotage?
Logistic related operations analysis belyser underhållsåtgärder som ofta utförs av brukaren. På en personbil kan det handla om att fylla på luft i däcken, tanka, fylla på spolarvätska etc. Åtgärder som inte har direkt med användningen av produkten att göra men som inte utförs av dedikerad underhållspersonal.
Level of repair analysis används för att ta fram en optimerad underhållslösning utifrån det givna underhållskonceptet. På vilken nivå ska en viss underhållsåtgärd utföras? Är det brukaren, en mobil enhet, verkstaden för det trafiknära underhållet eller en specialiserad underhållsverkstad som ska utföra underhållet? Detta beror bl.a. på hur frekvent underhållsåtgärden förväntas utföras, hur komplex den är, vilken kompetens som behövs och om det behövs speciell testutrustning eller specialverktyg för att utföra åtgärden. När underhållsnivå har valts kan man planera utbildning, reservdelsförsörjning, dokumentation och placering av verktyg för att möjliggöra detta.
I Maintenance task analysis analyseras underhållsåtgärderna och bryts ned i sina delsteg (subtasks). Här måste även förberedelsearbete, som till exempel friläggning av den komponent som ska underhållas, analyseras. Beslutsträd kan tas fram för att förenkla felsökning. Underhållsåtgärderna, inklusive förberedelseåtgärder, dokumenteras och tidsätts. Behov av reservdelar, förbrukningsartiklar, testutrustning, verktyg och faciliteter dokumenteras, personella resurser och kompetensnivå för åtgärden likaså.
Software support analysis är en relativt ny typ av analys som hänger samman med att moderna produkter innehåller alltmer programvara. Denna programvara tenderar att uppdateras mer frekvent än hårdvarukomponenterna i systemet. Det levereras ”patchar” och uppdateringar mer eller mindre regelbundet, uppdateringar som kanske dessutom använder mer processorkraft eller minne. Programvaran genererar dessutom otaliga felkoder med mer eller mindre kryptiska benämningar. Vikten av ett effektivt sätt att underhålla programvaran under systemets livslängd blir därigenom allt större.
Obsolescence analysis handlar om att ta fram en plan för att hantera att komponenter (inklusive programvara) kommer att bli obsoleta under systemets livslängd och att övervaka systemet med avseende på detta. Denna analys blir därför av repetitiv karaktär. Beslut om att ersätta en komponent som snart slutar produceras, att göra ett s.k. ”last time buy” för det förväntade livslängdsbehovet eller att hitta en ny leverantör som kan ta över produktionen kommer att behöva fattas så länge systemet är i drift.
Life cycle cost analysis (LCC-analys) görs kontinuerligt och vid varje vägval behöver beslutet understödjas av en LCC-analys. Det övergripande syftet är att maximera den operationella tillgängligheten till optimal (lägst möjliga) livscykelkostnad.
Detta är som sagt några av de analyser som kan vara relevanta att genomföra för att ta fram underhållslösningen, utöver de RAM-analyser som mer berör det tekniska systemets egenskaper och som är väl beskrivna i RAMS-litteratur för järnvägssystem4.
[1] Se https://en.wikipedia.org/wiki/Logistics_support_analysis
[4] Se t.ex. Handbook of RAMS in Railway Systems, Theory and Practice, av Qamar Mahboob och Enrico Zio.