Category Archives: RAMS

Syftet med konceptfasen beskrivs i EN 50126 som att skapa förståelse för systemet¹. Här finns det skäl att stanna upp en stund. Hur definierar vi systemet? Hur kommer vi fram till vilket system det är som ska betraktas när vi applicerar EN 50126?

Standarden är giltig för tekniska system i järnvägsbranschen inom områdena Trafikstyrning och signalering, Rullande materiel samt Fasta installationer. EN 50126 använder begreppet ”system under consideration” för det system som de olika aktiviteterna ska appliceras på. Man beskriver ett ganska väldefinierat ”system under consideration” som ingår i ett överordnat system, interagerar med sidoordnade system via sina gränssnitt och i sin tur består av delsystem². Någon (beställaren) – en kund, en produktledningsfunktion eller liknande – har redan här definierat vilket system det är som ska betraktas; ”system under consideration”.

Detta är viktigt, för det betyder att det i ett tidigare skede – innan EN 50126 kommer in i bilden – har gjorts vissa konceptval. Som exempel kan vi tänka oss en tågoperatör som vill konvertera sina gamla diesellok till att bli mer miljövänliga. Ett antal olika tekniska lösningar är möjliga för detta. Man har kanske studerat konvertering till eldrift, elhybrid, biodiesel och bränsleceller och fastnat för det senare alternativet. På motsvarande sätt kan ett system definieras genom ett arkitekturarbete, där olika konceptval genomförts, på överordnad systemnivå. Först när man väl ska realisera den tekniska lösningen blir EN 50126 aktuell.

”System under consideration” är det system som vi i slutändan kommer att ta fram en säkerhetsakt (eng. safety case) för. Om utvecklingen syftar till att bli en generisk produkt (eng. Generic Product, GP) eller en generisk tillämpning (eng. Generic Application, GA) tas systemet fram i syfte att ingå i ett överordnat system. Om utvecklingen däremot syftar till att bli en specifik tillämpning (eng. Specific Application, SA) är det ett system som ska produceras och installeras (och där kan naturligtvis GP:n och GA:n ingå, men det är inget krav).³

Ur ett RAM-perspektiv blir diskussionen om underhållssystem mer konkret först när det gäller system som utgör en SA; det är först när vi har den fysiska realiseringen (eng. physical implementation) som man tar med produktions-, installations-, drift- och underhållsaspekterna i säkerhetsakten. För de produkter och delsystem (GP och GA) som bygger upp SA:n innebär det att vi ställer krav på deras RAM-egenskaper men inte kan gå in i detalj på underhållssystemet, för det är alltid beroende av kundens underhållskoncept. Därmed inte sagt att man inte kan eller ska ta fram användar- och underhållsinstruktioner, utbildningar, reservdelar etc. även för GP och GA. De är ju utvecklade just för att vara generiska och då måste man använda sin domänkunskap för att ställa även den typen av krav på utvecklingen.

Som utgångspunkt för arbetet inom ramen för EN 50126 finns alltså någon form av formulerade behov eller kundkrav – detta gäller oavsett om ”kunden” är extern eller intern i form av företagets produktledning.

EN 50126 berör det faktum att det finns olika aktörer (kund – leverantör) men är inte särskilt utförlig på detta område. Olika kunder är dessutom olika. Tidigare var det vanligt att kunder tog fram väldigt detaljerade krav (eller rentav konstruktioner) medan det idag blir allt vanligare med funktionsupphandlingar. Att skapa förståelse för systemet innebär att förstå problemdomänen och att förstå i vilken kontext systemet ska realiseras. För att skapa denna förståelse kan det innebära att leverantören kan tvingas göra vissa analyser i konceptfasen som man normalt kanske skulle förvänta sig att kunden hade gjort. EN 50126 anger ett antal områden som ska analyseras⁴:

• omfattningen, kontexten och syftet med systemet
• systemets omgivning, inklusive fysiska begränsningar, begränsningar i gränssnitt samt lagmässiga och ekonomiska begränsningar
• tidigare RAMS-krav och RAMS-prestanda hos liknande och/eller relaterade system
• nuvarande RAMS-policy och -mål hos kunden (eller produktdomänen om vi pratar generisk utveckling)
• säkerhetslagstiftning

För att göra denna analys och skapa denna förståelse för systemet kan konceptbeskrivningar med fördel tas fram. INCOSE Systems Engineering Handbook⁵ beskriver ett antal tänkbara konceptdokument, som alla har ett tydligt kundperspektiv:

• Concept of Operations
• Operational Concept
• Acquisition Concept
• Deployment Concept
• Support Concept
• Retirement Concept

Genom denna typ av konceptbeskrivningar, där problemdomänen (eng. problem domain) och intressentbehoven (eng. stakeholder needs) beskrivs, fås en väldigt bra och tydlig bild av vilket system det är som ska tas fram. De påbörjas i denna fas och byggs på senare under systemets livscykel.

Två nycklar för det fortsatta RAM-arbetet kommer fram i denna fas; dels RAM-mål som om möjligt bör uttryckas i form av krav på operationell tillgänglighet och dels en beskrivning av underhållskonceptet.

Denna livscykelfas är avslutad när vi uppnått ”tillräcklig förståelse”⁶ för systemet. Vad som är ”tillräcklig förståelse” kan förstås diskuteras, men samtliga områden som anges i standarden bör vara analyserade. Analyserna i denna fas leder vidare till nästa fas – Systemdefinitionsfasen.

---

[1] EN 50126-1:2017, kap. 7.2.1

[2] EN 50126-1:2017, kap. 5.2.1

[3] Se EN 50126-2:2017, kap. 6 för en utförlig diskussion om säkerhetsaktsstruktur

[4] EN 50126-1:2017, kap. 7.2.2

[5] INCOSE Systems Engineering Handbook: a guide for system life cycle processes and activities, Fourth Edition

[6] EN 50126-1:2017, kap. 7.2.1

Inom järnvägssektorn i Europa är EN 50126¹ den centrala RAMS-standarden. Det går liksom inte att komma runt den. Så hur väl stämmer det resonemang om tekniskt system och underhållssystem som vi fört i tidigare blogginlägg med innehållet i den standarden?

Vi återkommer till det. Men, först och främst, som för alla standarder gäller att den är resultatet av ett kommittéarbete där delegaterna har fått förhandla och kompromissa utifrån sina respektive ståndpunkter. En processtandard som denna kan ses som en modell av hur man bör arbeta. Modeller och verkligheten stämmer som bekant inte helt överens. Modeller är därmed per definition felaktiga, men vissa modeller är användbara. EN 50126 är definitivt inte perfekt men lika definitivt användbar. Och den behöver alltid anpassas (eng. tailoring) till förutsättningarna för just det specifika projektet, vilket också tas upp i standarden.

EN 50126 beskriver ett systems olika livscykelfaser och ställer krav på aktiviteter som ska genomföras i respektive livscykelfas, såväl generella krav som inte är RAMS-relaterade som specifika RAMS-krav. Man använder ibland begreppet ”system life cycle” och ibland ”RAMS life cycle” vilket kan förvirra något. Det är olyckligt att man använder det senare, då det är hela systemet som befinner sig i en viss livscykelfas, något som också framgår med all tydlighet i standarden. Begreppet ”RAMS life cycle” kan leda till att man betraktar EN 50126 och dess livscykelfaser som något som enbart angår dem som jobbar med RAMS, när det de facto är något som alla som jobbar med systemet måste förhålla sig till.

De livscykelfaser som EN 50126 definierar är:

1. Konceptfasen (eng. Concept)
2. Systemdefinitionsfasen (eng. System definition and operational context)
3. Riskanalysfasen (eng. Risk analysis and evaluation)
4. Kravspecifikationsfasen (eng. Specification of system requirements)
5. Arkitekturfasen (eng. Architecture and apportionment of system requirements)
6. Designfasen (eng. Design and implementation)
7. Tillverkningsfasen (eng. Manufacture)
8. Integrationsfasen (eng. Integration)
9. Systemvalideringsfasen (eng. System validation)
10. Systemacceptansfasen (eng. System acceptance)
11. Driftfasen (eng. Operation, maintenance and performance monitoring)
12. Avvecklingsfasen (eng. Decommissioning)

EN 50126 beskriver dessa livscykler sekventiellt men gör även en V-modellsbeskrivning. Standarden är inte normativ avseende hur livscykeln ska beskrivas utan möjliggör olika modeller. På så vis finns det ingen motsättning mellan EN 50126 och ex.vis ett agilt arbetssätt.

En sak man kan säga om livscykelfaserna i EN 50126 är att dessa inte fullt ut utgör distinkta livscykelfaser utan man blandar faser och aktiviteter. Inte minst gäller detta riskanalysfasen, som dessutom i standarden beskrivs som en över tiden pågående aktivitet. Det hade alltså gått att välja en annan och tydligare fasindelning. Men å andra sidan ställer man krav på ganska många aktiviteter i varje fas, så denna fasindelning har sina fördelar; respektive fas blir hanterbar. Och det är alltså den fasindelning alla som jobbar med systemet ska följa.

Vidare så grupperar EN 50126 dessa livscykelfaser i tre olika block, en gruppering som i första hand är gjord utifrån ett krav på oberoende för vissa roller:

• Riskbedömning (eng. Risk assessment): fas 1, 2, 3, 4 och delar av 5
• Implementering (eng. Implementation and demonstration of compliance with requirements): delar av fas 5 samt fas 6, 7, 8, 9 och 10
• Drift, underhåll, avveckling (eng. Operation, maintenance and decommissioning): fas 11 och 12

Det fokus på risk som syns här genomsyrar EN 50126. Medan den approach vi beskriver i denna blogg är att RAM-arbetet är ett verktyg som kravställer det tekniska systemet och analyserar och utvecklar underhållssystemet i syfte att maximera tillgängligheten har EN 50126 synen att vi ska undvika riskerna för ”loss of value of the service”. Man går så långt att man till och med säger att det är ett av syftena med standarden (min kursivering):

“The objective of the RAMS process described in this standard is to ensure
that all aspects of RAMS are covered in order to make provision for the
safety of railway applications and for the avoidance of loss of their value.²”

Det är förvisso olika sidor av samma mynt men resultatet blir en attitydskillnad som kan få väldigt negativa konsekvenser. I stället för att söka lösningar försöker vi undvika problem. I stället för att försöka vinna undviker vi att förlora. En idrottsman som vill vinna kommer att göra fler mål än en som försöker undvika att förlora!

Åter till frågan om hur väl resonemanget om tekniskt system och underhållssystem stämmer med standarden. Svaret är att EN 50126 beskriver enskilda komponenter av underhållssystemet, ex.vis utbildning av drift- och underhållspersonal, men saknar systemtänket. I kommande blogginlägg kommer vi därför att titta närmare på de olika faserna i EN 50126 och föreslå vissa förändringar för att föra in detta systemtänk. Förändringar som inte går emot kraven i standarden men som förändrar synsättet från att undvika att förlora till att vilja vinna. Detta krävs för att skapa ett järnvägssystem man kan lita på. En järnväg där tåget går när det ska och kommer fram på utsatt tid!

---

[1] EN 50126-1:2017, Järnvägstillämpningar – Specifikation och demonstration av tillförlitlighet, tillgänglighet, underhållsmässighet och säkerhet (RAMS) – Del 1: Generell RAMS-process

[2] EN 50126-1:2017, kap 5.1

För att skapa ett system med hög operationell tillgänglighet behöver vi, som beskrivits i tidigare blogginlägg, både ha ett tekniskt system och ett underhållssystem som tillsammans kan åstadkomma den önskade operationella tillgängligheten. Det ställer krav på det tekniska systemets inneboende tillgänglighet (A_i) men också på underhållssystemets förmågor. Vi behöver då ta hänsyn till såväl det tekniska systemets driftprofil som befintligt underhållskoncept. Genom ett antal analyser kan vi få fram kraven på underhållslösningens olika komponenter och påverka den tekniska lösningens RAM-egenskaper så att tillgänglighetskravet kan mötas. Med målet att uppnå denna tillgänglighet på ett så kostnadseffektivt sätt som möjligt behöver vi hitta den lösning som ger lägst livscykelkostnad.

I takt med att fler och fler system blir uppkopplade kan vissa analyser ersättas av erfarenhetsdata. Framförallt gäller det RAM-egenskaperna hos det tekniska systemet, men det finns även möjligheter att registrera och analysera ex.vis verkstadsdata, hanteringstider för reservdelar m.m. Det viktiga här är inte hur, utan att, informationen tas fram och används för att utveckla underhållslösningen.

Utifrån beskrivningarna av ILS, LSA och underhållslösning som gjorts i tidigare blogginlägg kan nedanstående övergripande RAM-processbild formas. Även om beskrivningen är linjär sker en kontinuerlig feed-back och förfining av såväl den tekniska lösningen som underhållslösningen efterhand som dessa utvecklas.

Design Influence
Baserat på kontraktuella krav och givna förutsättningar som driftprofil och underhållskoncept görs analyser av existerande systemlösningar för att se hur de övergripande tillgänglighetskraven möts. Dessa analyser omfattar, utöver funktions- och andra egenskapskrav, såväl RAM-egenskaperna hos det tekniska systemet som befintlig underhållslösning. Behov av nyutveckling dokumenteras. Alternativa lösningar analyseras. När analyserna ger vid handen att det finns en möjlig systemlösning som tillgodoser kraven kan systemkravspecifikationen frysas.

Viktigt här är att ta med kraven för hela systemet och inte bara för det tekniska systemet. Det är ju, som vi diskuterat tidigare, genom en kombination av det tekniska systemets egenskaper och underhållslösningens dito som den operationella tillgängligheten uppnås. Den vanligaste typen av produktutveckling handlar om att vidareutveckla redan befintliga system. Att lägga till ytterligare funktionalitet eller ett nytt gränssnitt. Att förbättra ett befintligt systems prestanda. Därmed kan produkt- och systemutveckling också handla om att förbättra underhållslösningen. Alltifrån bättre inbyggd felutpekning (testability) i det tekniska systemet till bättre underhållsmetoder.

Candidate Identification
Det fortsatta RAM-arbetet baseras på det tekniska systemets nedbrytning. Möjligheterna att utföra underhållsåtgärder på systemet kommer ju att se helt olika ut om hela systemet är en monolit eller om det är modulärt uppbyggt. Vi tar fram kandidater för det fortsatta analysarbetet baserat på urvalskriterier; hur djupt ska analysen gå för att kunna identifiera alla reservdelar, vilka analyser behöver göras på respektive komponent, är någon komponent extra kritisk ur tillgänglighetssynpunkt, är någon komponent extra utsatt för potentiell skada, etc.
Tidigast här kan systemarkitekturen frysas.

Task Identification
Genom analyser (Scheduled maintenance analysis, Damage & special event analysis, Operations analysis, Software support analysis) identifieras de underhållsåtgärder som finns för det tekniska systemet – såväl förebyggande som avhjälpande. En LSA-FMEA kan utföras som skiljer sig från design-FMECA i det att olika felmoder kan grupperas ihop om de leder till samma underhållsåtgärd.

Maintenance Planning
Efter att underhållsåtgärderna har identifierats utvecklas underhållsplanen genom Maintenance task analysis och Level of repair analysis (LORA). Behovet av utbildning analyseras genom en Training needs analysis.

Support Solution Development
Slutligen tas alla komponenter som utgör underhållslösningen fram; teknisk dokumentation, utbildning, försörjning av reservdelar och förbrukningsvaror, personal, datorresurser, faciliteter, hanterings- och förpackningslösningar, support- och testutrustning. Här kan olika aktörer vara inblandade: systemleverantören kanske ansvarar för att ta fram teknisk dokumentation, utbildning, o.s.v. medan kunden upphandlar en underhållsleverantör som har personal och faciliteter. Datorresurser finns ofta hos flera aktörer; övergripande underhållsplanering sker i kundens system, leverantören har sitt uppföljningssystem och underhållsleverantören jobbar i sitt eget system mot flera kunder. Ofta knyts dessa system ihop på något sätt, genom mer eller mindre sofistikerad dataöverföring.

Vill man jobba riktigt strukturerat kan man med fördel ta fram en kravspecifikation för underhållslösningen baserat på samtliga analyser som genomförts.

Livscykelkostnad
Under systemets hela livslängd byggs livscykelkostnadsmodellen på med data. Analyser görs på alternativa lösningar för att minimera livscykelkostnaden. Är det bättre, ur ett livscykelkostnadsperspektiv, att konstruera det tekniska systemet så att färre underhållsåtgärder behövs? Kan vi öka intervallet mellan förebyggande underhållsåtgärder eller riskerar vi då dyra stoppande fel? (Stoppande fel kan i LCC-modellen ansättas kostnader i form av förlorade intäkter, hyra av ersättningslok för att klara produktionen, etc. Traditionellt räknas dock enbart direkta kostnader i form av reparationskostnader. Detta riskerar dock därigenom att underskatta kostnaden för avhjälpande underhåll.)

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)¹.
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 – ASD². Den del som handlar om LSA kallas S3000L³.

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ägssystem⁴.

---

[1] Se https://en.wikipedia.org/wiki/Logistics_support_analysis

[2] Se http://www.sx000i.org/

[3] Se http://www.s3000l.org/

[4] Se t.ex. Handbook of RAMS in Railway Systems, Theory and Practice, av Qamar Mahboob och Enrico Zio.

För att uppnå den operationella tillgängligheten för ett tekniskt system räcker det inte att titta på det tekniska systemets inneboende egenskaper utan vi måste också ha ett underhållssystem som balanserar det tekniska systemets egenskaper (se tidigare blogginlägg). Under konstruktionsarbetet görs avvägningar mellan egenskaper hos det tekniska systemet och förmågor i underhållssystemet. Vilken lösning ger bäst livscykelkostnad – ett robustare tekniskt system eller en modifierad underhållslösning? Lösningsrymden blir avsevärt mycket större när vi kan ändra fler parametrar!

De egenskaper i det tekniska systemet som vi är primärt intresserade av är tillförlitlighet (eng. reliability), tillgänglighet (eng. availability), underhållsbarhet (eng. maintainability) – RAM. Tillgänglighet definieras i sin grundläggande form som A_i=MTBF/(MTBF+M_CT), d.v.s. som en funktion av tillförlitlighet och underhållsbarhet. Är det då inte tillräckligt att fokusera på dessa två egenskaper? Nej, systemet kan konstrueras med ex.vis redundans, som gör att systemets funktion kan bibehållas även om en komponent går sönder.

Dessa egenskaper är väl beskrivna i befintlig litteratur och standarder inom RAM-området relaterat till järnväg¹ och kommer därför inte att behandlas i någon djupare detalj här.

I viss litteratur används även förkortningen RAMT, där T står för testability. Med det avses systemets förmåga till felutpekning (ex.vis genom BIT – built in test).

Vilka är då förmågorna i underhållssystemet? EN 50126 och tillgänglig litteratur inom RAMS för järnvägsbranschen har inte strukturerat detta på ett systematiskt sätt. Inom flyg- och försvarsindustrin har det däremot över åren utvecklats ett antal standarder och metoder inom detta område, som benämns integrerat logistikstöd (eng. Integrated Logistics Support – ILS)². Ett antal ILS-standarder finns men de har en i huvudsakligen likartad beskrivning av underhållssystemet. Typiskt delas det in i följande områden, som brukar kallas ILS-element:

• Maintenance Planning and Management
• Technical publications
• Training
• Supply support
• Manpower and personnel
• Computer resources
• Facilities
• Packaging, Handling, Storage & Transportation
• Support & Test Equipment

Maintenance Planning and Management är den funktion inom drift och förvaltning av järnvägssystemet som styr underhållet. Till grund för detta ligger den underhållsplan som tas fram för det tekniska systemet.

Technical publications utgörs av all den dokumentation som hör till systemet. Alltifrån ren underhållsdokumentation och användarinstruktioner till ritningar, reservdelsdata, etc. som behöver finnas tillgängliga under systemets hela livslängd. Tätt kopplat till detta är naturligtvis även disciplinen konfigurationsledning (eng. configuration management) som säkerställer tillgången till rätt information över tiden.

Training är all typ av utbildning för användare, underhållspersonal och andra som kan komma i kontakt med systemet.

Supply support omfattar försörjning av reservdelar och förbrukningsvaror.

I Manpower and personnel ingår alla typer av personal som är inblandade i underhållet av systemet.

Computer resources omfattar olika typer av datorstödsystem, ex.vis underhållsmoduler i CRM-system, FRACAS-system eller andra uppföljningssystem som behövs som driftstöd eller för underhåll av det tekniska systemet.

Facilities är de anläggningar som behövs för underhåll, ex.vis verkstäder eller renrum.

Packaging, Handling, Storage & Transportation (PHS&T) omfattar de lösningar som behövs för hantering av främst reservdelar och förbrukningsmaterial men även om det behövs hanteringsresurser för systemets drift, ex.vis om systemet utgörs av känsliga instrument som flyttas mellan de platser där de används.

Support & Test Equipment är de specialverktyg och mätinstrument som behövs för drift och underhåll av systemet.

Till ILS-elementen brukar också Design Influence räknas. Det är dock inte en del av underhållssystemet, utan består av de aktiviteter som utförs under utvecklingen av det tekniska systemet för att säkerställa att systemets inbyggda egenskaper blir de rätta.

För att ta fram ett system som möter kraven på operationell tillgänglighet vill vi alltså ha rätt avvägning mellan det tekniska systemets inbyggda egenskaper (RAMT) och underhållssystemets förmågor. ”Motorn” i detta utgörs av de analyser som genomförs under utvecklingen – Logistics Support Analysis, LSA.

---

[1] Se t.ex. Handbook of RAMS in Railway Systems, Theory and Practice, av Qamar Mahboob och Enrico Zio.

[2] Se t.ex. https://en.wikipedia.org/wiki/Integrated_logistics_support för en översikt.

Som vi berört i tidigare blogginlägg behöver järnvägen öka fokuset på de tekniska systemens tillgänglighet. Att göra rätt från början! Idag ser vi initiativ som TTT (Tillsammans för Tåg i Tid) på den svenska järnvägen. Att den typen av initiativ behövs idag är det ingen tvekan om. Men att det behövs är ett bevis på att järnvägssystemet, såsom det definieras i järnvägslagen, inte fungerar som det borde. Vi har idag inte ett järnvägssystem där underhållslösningen balanserar egenskaperna hos de tekniska delarna. Där rätt underhållsresurser finns på rätt plats vid rätt tid. Då tvingas vi till slut till omfattande åtgärder för att återställa systemets funktionalitet i stället för att med förebyggande underhållsåtgärder undvika fel i systemet.

För att kunna ställa relevanta krav på leverantörerna av de tekniska systemen liksom på leverantörerna av underhållstjänster måste vi förstå begreppet tillgänglighet. Vi behöver också ha bra processer för att över tiden följa upp tillgängligheten samt agera snabbt för att återställa systemet vid avvikelser.

Den operationella tillgängligheten är det som är intressant att titta på ur ett operatörsperspektiv. Den är ett mått på hur stor del av tiden ett system är tillgängligt och kan användas till vad det är avsett för. Operationell tillgänglighet brukar betecknas A_O och definieras som A_O=Uptime/(Uptime+Downtime), d.v.s. hur stor del av den totala tiden som systemet fungerar och kan användas. Den operationella tillgängligheten beror dels av det tekniska systemets inneboende tillgänglighet (A_i) men också av andra faktorer såsom förberedelsetid, reservdelstillgänglighet, hanteringstid, placering av och tillgänglighet på verkstadsresurser eller mobila reparatörer. Till exempel leder ett underhållskoncept där det tekniska systemet alltid, oavsett åtgärd, måste skickas till en central, specialiserad verkstad för reparation till sämre operationell tillgänglighet än om vissa enklare underhållsåtgärder kan utföras av operatören direkt på plats. Det senare ställer dock högre krav på operatörens kompetens och, beroende på underhållsåtgärdens karaktär, kan det kräva att reservdelar och verktyg placeras ut i anslutning till det tekniska systemet.

Det tekniska systemets inneboende tillgänglighet definieras i sin grundläggande form som A_i=MTBF/(MTBF+M_CT) där MTBF är medeltid mellan fel (Mean Time Between Failures) och M_CT är medeltid för avhjälpande underhåll (Mean Corrective Maintenance Time). MTBF och M_CT är inbyggda egenskaper¹ i det tekniska systemet. MTBF är dock inte statiskt utan påverkas även av systemets driftprofil – hur systemet används. Till exempel kommer en bil som kör på en helt plan väg vid havsnivå att hålla längre än samma bil som kör på dåliga vägar i kuperad terräng på hög höjd. MTBF är alltså olika för olika driftprofiler!

Driftprofilen kan således beskrivas utifrån parametrar som antal kilometer körsträcka per år, fördelning i körsträcka mellan olika typer av klimat, mängd dragen last, fördelning av banans lutningsprofil i förhållande till årlig körsträcka, antal start och stopp, vilotider mellan körningar etc.

Ett tekniskt system anskaffas i normalfallet inom ramen för en befintlig kontext som man måste ta hänsyn till. Såväl driftprofil som underhållskoncept är i normalfallet givna parametrar när det nya eller uppgraderade tekniska systemet designas. En anskaffning kan exempelvis göras i syfte att möta en ökad efterfrågan på tågresor eller för att ersätta befintlig flotta. Givet mängden fordon som anskaffas för detta, turtäthet, bansträckning m.m. ges driftprofilen. Underhållsverkstäder för fordonens trafiknära underhåll läggs ofta i anslutning till ändstationerna och det finns en begränsad möjlighet att bygga nya för att optimera underhållet. En uppgradering av ett tekniskt system behöver ta hänsyn till befintliga underhållsintervall. Endast i undantagsfall har vi möjlighet att ändra dessa parametrar.

Vi kan sammanfatta detta resonemang i nedanstående bild. Den operationella tillgängligheten är ett resultat av systemets driftsprofil, organisationens underhållskoncept, det tekniska systemets egenskaper och förmågorna hos underhållssystemet.

---

Givet en kravställd operationell tillgänglighet måste vi därför konstruera såväl det tekniska systemet som underhållssystemet så att detta tillgänglighetskrav möts utifrån driftprofil och underhållskoncept.

---

[1] Begreppen varierar mellan olika litteratur. Se ex.vis Logistics Engineering and Management av Benjamin S. Blanchard för en utförlig genomgång. I SS-EN 50126-1:2017 motsvaras M_CT av MRT (Mean Repair Time).

När vi pratar om järnvägen som ett system är den vanliga bilden som kommer upp en av järnvägsfordon, räls, broar, traktionssystem, växlar, signalsystem, byggnader, plattformar, biljettsystem etc. Det är det tekniska systemet som är i fokus. Tillgänglig litteratur och standarder inom RAMS-området för järnvägen har likaså ett övervägande fokus på det tekniska systemets inneboende egenskaper och analyser av dessa. Men den centrala RAMS-standarden EN 50126 beskriver dock att ett system inte enbart består av dess tekniska delar utan även dess samverkan med människorna som utvecklar, använder och underhåller det¹. Detta stämmer även överens med den syn som presenteras i gällande EU-direktiv och svensk lagstiftning, där man beskriver att järnvägssystemet består av tre delsystem: järnvägsfordon, infrastruktur samt drift och förvaltning av fordon och infrastruktur².

Det tekniska systemets inbyggda egenskaper är långt ifrån det enda som krävs för att bygga ett tillförlitligt system med hög tillgänglighet. Reservdelar, verktyg, dokumentation, utbildning, underhållsplaner och personal är bara några av de komponenter som behöver finnas på plats över systemets livslängd för att dess tillgänglighet skall möjliggöras. Underhållslösningen behöver tas fram tillsammans med det tekniska systemet, inte i efterhand. Ett tydligt exempel på hur det kan gå om detta inte görs på rätt sätt, var i samband med de trasiga rulltrapporna i Stockholms pendeltågsstationer vid Stockholm City och Odenplan under 2018 då det saknades reservdelar³. Dessa blev stillastående i över ett år.

Denna bredare systemsyn (tekniskt system samt underhållssystem) måste finnas med redan från början när systemet designas, så att rätt avvägningar görs mellan egenskaper hos det tekniska systemet och förmågor hos underhållssystemet. Ska vi göra det tekniska systemet lite bättre eller är det bättre att lägga in ett extra underhållstillfälle? Om konsekvenserna av att systemet går sönder är väldigt stora och möjligheterna att förebygga eller avhjälpa felen är små när systemet väl är i drift, som för t.ex. rymdfarkoster, läggs ofta mycket tid och pengar på att säkerställa att fel inte inträffar. I många andra fall finns inte den tid och budget som krävs för detta. Och om konsekvenserna av fel i systemet inte är av den magnituden, är det ofta inte heller ekonomiskt försvarbart.

I varje enskilt fall gäller det att hitta rätt avvägning mellan egenskaperna hos det tekniska systemet och de krav vi ska ställa på underhållssystemet. Denna avvägning ska göras ur ett livscykelkostnadsperspektiv där även kostnader för risker värderas.

Det är helt enkelt hög tid att vidga systemperspektivet!

---

[1] SS-EN 50126-1:2017, kapitel 5.2.3

[2] Se t.ex. TS JV 2009:002, Transportstyrelsens vägledning för TSFS 2010:116 – Godkännande, ver. 06, sid. 9

[3] https://www.svd.se/star-stilla-sedan-sedan-i-somras–ingen-prognos

Järnvägen är ett tekniskt system som ända sedan sin födelse har varit omgivet av ett stort säkerhetstänkande. En av de inbyggda egenskaperna i järnvägssystemet är den låga friktionen mellan räl och hjul som ger systemet såväl stora konkurrensfördelar i form av hög energieffektivitet som inbyggda risker genom att bromssträckorna blir väldigt långa. På grund av detta har järnvägen utrustats med alltmer sofistikerade säkerhetssystem allt eftersom hastigheterna har höjts och acceptansen för skador och dödsfall har sänkts. I modern tid, inte minst genom införandet av datorstyrda system, har standarder utvecklats inom området.

Ytterligare en av de inbyggda egenskaperna i järnvägssystemet är att man i händelse av detektion av händelser som skulle kunna leda till en farlig situation i de flesta fall har möjlighet att sätta systemet i ett säkert tillstånd genom att tvinga tåget att stanna. (Denna möjlighet saknas exempelvis inom flyget.) Genom detta har järnvägsbranschens fokus vad gäller RAMS fått en tyngdpunkt mot säkerhetsfunktionerna. Säkerhet har ansetts som viktigare än tillgänglighet och de har stundtals betraktats som varandras motpoler – ett stillastående tåg är ett säkert tåg. I takt med att järnvägen får en allt ökad popularitet och utgör en av de viktiga lösningarna i omställningen mot ett mer hållbart samhälle är det hög tid att skifta fokus. Säkerhet inom järnvägen bör betraktas som en sanitetsfaktor, en grundläggande egenskap hos systemet, och ett allt större fokus bör nu läggas på att skapa ett system som kan möta den ökande efterfrågan på inte enbart säkra utan, inte minst, tillförlitliga järnvägstransporter.

Vi kommer i ett antal blogginlägg belysa olika aspekter av RAM-arbetet inom järnväg och titta på hur det kan användas för att skapa både säkra och tillförlitliga system.