Systemacceptansfasen i EN 50126 kan, liksom riskanalysfasen, inte beskrivas som en livscykelfas. Standarden beskriver att man ska bedöma resultaten från verifierings- och valideringsaktiviteterna och jämföra dem med de definierade riskacceptanskriterierna.¹ Därefter ska man godkänna systemet för att tas i drift. Detta är rimligtvis att betrakta som två aktiviteter som genomförs innan man låter systemet gå vidare från systemvalideringsfasen till driftsfasen, och inte som en egen livscykelfas!

EN 50126 har här enbart fokus på säkerhetskraven (riskacceptanskriterier är relaterade till säkerhet). Men, som diskuterats i tidigare blogginlägg, det är hela systemet som befinner sig i en viss livscykelfas, så när systemet ska godkännas för idrifttagning är det hela systemet som ska godkännas, inte enbart säkerhetsaspekterna av systemet! Självklart kan man inte ta ett system i drift innan uppfyllnad av säkerhetskraven har påvisats, men dessa utgör endast en delmängd av alla systemkrav.

De långa ledtiderna som krävs för demonstration av felintensitet leder ofta till att tiden för systemvalidering behöver sträckas ut till efter att systemet tagits i kommersiell drift. EN 50126 har en förenklad syn där systemvalideringen är fullt avklarad innan systemet tas i drift. Pratar vi fordonssystem tas ofta enskilda fordon i drift efterhand som de levereras och först därefter kan fullständig systemvalidering genomföras. Det är inte ekonomiskt hållbart att genomföra demonstration av felintensitet utan att köra i kommersiell drift, då detta kan kräva flera års drift. Och med tanke på hur hårt belastat järnvägsnätet är skulle det i princip vara omöjligt att få tåglägen för att det antal körmil som behövs för att genomföra demonstration av felintensitet utan att köra i kommersiell trafik.

Allt detta sammantaget gör att man i varje enskilt projekt måste definiera vilka krav som ska vara uppfyllda och validerade innan systemet tas i drift. Säkerhetskraven är självskrivna, men utöver dessa blir det unikt för varje projekt. Som exempel kan man tänka sig ett projekt som ska byta ut tågskyddssystemet på en flotta av fordon för att kunna köra på såväl ETCS-bana som på befintlig nationell infrastruktur. Där kanske man genomför projektet i två faser, där man först tar systemet i drift med enbart STM-drift för den nationella infrastrukturen, för att i en andra fas driftsätta systemet för ETCS-bana. I respektive fas tas enskilda fordon i drift i den takt de uppgraderas. I detta exempel är inte systemets fulla funktionalitet uppfylld innan man tar systemet i drift efter den första fasen.

På samma sätt måste man vara tydlig med vilka delar av underhållslösningen som måste finnas på plats innan systemet tas i drift. Det är inte ovanligt att man vill ta ett tekniskt system i drift så tidigt som möjligt för att börja tjäna pengar på investeringen eller för att det är politiskt viktigt att visa upp den nya transportlösningen. Tyvärr händer det att man gör det trots att delar av underhållslösningen inte finns på plats och så drabbas man av problem, som ex.vis var fallet med Lunds spårväg som vi belyst tidigare.

Återigen ser vi att det är nödvändigt att göra en projektanpassning av livscykelmodellen i EN 50126 utifrån projektets unika förutsättningar. Systemacceptans kan ske i ett antal steg, där systemet först accepteras med en delmängd av funktionaliteten (och relaterade riskacceptanskriterier) varefter stegvis utökning av funktionalitet införs. Slutlig systemacceptans sker först när RAM-egenskaperna har validerats, vilket kan vara flera år efter att systemet tagits i drift.

---

[1] EN 50126-1:2017, kapitel 7.11

Järnvägar.nu rapporterade igår om att den nyinvigda spårvägen i Lund nu dras med stora problem.¹ Man skriver att inget tyder på att trafiken kommer att gå normalt på flera månader. Orsaken sägs vara programvaruproblem med fastbromsningsfunktionen i kombination med brist på reservboggier och ingen tillgång till hjulsvarv. Detta tjänar som ett bra, men förskräckande, exempel som väl illustrerar det som denna blogg behandlar. Jag kommer i detta inlägg att, utgående från artikeln på järnvägar.nu att ge exempel på hur man kunde gjort det annorlunda och därmed, med stor sannolikhet, undvikit dessa problem. Jag vill dock tydliggöra att jag inte har någon förstahandsinformation utan enbart baserar denna text på innehållet i artikeln.

Problemet tycks i grunden bero på en bristande funktion i spårvagnens bromsstyrning. Funktionen ska förhindra att hjulen låser sig, och därmed riskerar skapa hjulplattor, vid så kallad farobroms. Denna funktion verkar alltså vara kravställd och ska finnas i de fordon som man beställt. Intressant nog skyller den regionala kollektivtrafikmyndigheten istället på bilisterna som inte är vana vid spårvagnstrafik och därigenom tvingar förarna till hårda inbromsningar. Detta är naturligtvis rent nonsens eftersom man samtidigt erkänner att det är brister i fordonens funktion som orsakar problemen. Men även om bilisternas beteende hade varit grundorsaken till problemet skulle detta ha upptäckts om man hade gjort en grundlig konceptstudie, där man tittat på hur detta nya system ska fungera. Hade man gjort en riskanalys enligt CSM-RA och tittat på vilken förändring i trafiksystemet man planerar att göra hade man identifierat ett antal risker med denna förändring och därmed vidtagit åtgärder för att undvika dem. Informationskampanjer och tydligare signaler i trafiken hade kunnat vara åtgärder man vidtagit för att undvika denna risk. Det man gör i de tidiga faserna (konceptfasen, systemdefinitionsfasen och riskanalysfasen i EN 50126) av systemets livscykel är av stor vikt för hur väl systemet kommer att fungera!

Men, som sagt, risken för hjulplattor vid farobroms tycks redan ha varit identifierad. Därför har man kravställt (eller fått på köpet) en funktion för fastbromsningsskydd som dock inte fungerar som tänkt. Vad det beror på får väl framtiden utvisa. Man kan tänka sig allt ifrån att kravspecifikationen inte är korrekt eller komplett till fel i implementeringen av funktionen i mjukvaran till prestandafel i givare eller bromsstyrningsmekanik eller att integrationen av mjukvara, givare och bromsstyrning inte fungerar som tänkt. Man kanske inte har gjort en ordentlig kravnedbrytning och allokerat krav på de olika delsystem som är berörda. Kanske har man inte tagit hänsyn till miljökrav på givare och styrdon så att de ska klara den svenska vintern eller elmiljön i dessa fordon. Kravspecifikations-, arkitektur- och designfaserna är kritiska för att både bygga rätt system och för att bygga systemet rätt.

Märkligt nog tycks det som att den först levererade vagnen har klarat sig utan hjulplattor medan de efterföljande alla har fått detta problem. Man kan då misstänka att det är någon skillnad mellan verifieringsfordonet och övriga fordon. Konfigurationsstyrning och kvalitetskontroll är kritiska processer för att säkerställa att produktionen blir rätt. Då vi här pratar om serieproduktion måste livscykelmodellen anpassas från den rent linjära modell som EN 50126 beskriver till en där tillverknings-, integrations- och systemvalideringsfaserna inte är sekventiella. Tillverkningsfasen kommer att pågå under en längre period, även efter att verifieringsfordonet har integrerats och systemets funktionalitet har validerats. Om produktionen pågår under en längre period kan vissa komponenter vara så svåra att få tag på att det första och det sista fordonet inte ser likadana ut. Vissa elektronikkomponenter finns på marknaden i bara några månader!

Ur ett RAM-/ILS-perspektiv börjar vi redan i konceptfasen med att identifiera ett underhållskoncept. Enligt vad som beskrivs i artikeln finns en depå i Lund som dock saknar hjulsvarv. Initialt hade man planerat för en hjulsvarv i Malmö som skulle delas med tänkta spårvägar i Malmö och i Helsingborg, men när dessa planer rann ut i sanden ändrade man planerna till att i stället att använda den nya tågverkstaden i Hässleholm. Svarven där är dock byggd för tåg och inte för spårvagnar så den kommer inte att kunna användas förrän om ett par månader när den har anpassats till att även klara spårvagnarnas boggier. Ett underhållskoncept tycks därmed finnas – dock ej fullt ut realiserat i tid!

Baserat på driftprofilen, underhållskonceptet och en kravställd operationell tillgänglighet ska vi sen ta fram kraven på det tekniska systemets RAM-egenskaper såväl som på underhållssystemets förmågor. Något som tyvärr är alltför vanligt inom järnvägsbranschen är att man inte kravställer operationell tillgänglighet. Vad som beskrivs i artikeln är att man har ett kontraktuellt krav med leverantören att det ska finnas sex körklara vagnar i depån varje morgon. Momentan tillgänglighet vid en viss tidpunkt är inte något bra tillgänglighetsmått! Och fel tillgänglighetsmått leder till felaktig kravställning.

Med hjälp av felträdsanalys och FMECA borde fastbromsningsfunktionen analyserats ordentligt och den funktionen (tillsammans med fordonens övriga funktioner) borde ha verifierats och validerats innan man tog fordonen i trafik för att säkerställa att den fungerar som den ska. Genom att utföra en fullständig underhållberedning (bl.a. Damage and Special Events Analysis) hade man kunnat identifiera behovet av reservboggier och hjulsvarv som kritiska innan man tog fordonen i trafik, just för att konsekvenserna blir så stora om man får hjulplattor. Nu har man tydligen litat på leverantörens påstående att några reservboggier inte ska vara nödvändiga.

En annan faktor som lyfts fram i artikeln är att förarna ursprungligen är bussförare som har getts en tilläggsutbildning för att köra spårvagn. En väl genomförd Training Needs Analysis hade identifierat vilka utbildningsmoment som måste finnas med i utbildningen och kanske särskilt fokuserat på att öva in ett förarbeteende som inte riskerar att leda till denna typ av problem.

Artikeln beskriver också väl den organisatoriska komplexitet som finns i dagens spårburna trafiksystem. Skånetrafiken ansvarar för och upphandlar trafiken, Lunds kommun äger spårvägen, CAF är leverantör av vagnarna, Vy kör dem och Euromaint sköter depån i Lund medan Infranord sköter underhållet av spårvägen. Det är ett antal olika aktörer och ett antal olika avtal som ska fungera bra tillsammans för att helheten ska bli bra. En stor risk är att det saknas en helhetsbild och att någon del faller mellan stolarna. Ofta är det inte tekniken som är den egentliga utmaningen, utan istället att få alla dessa olika aktörer med sina olika avtal att samverka på ett effektivt sätt.

Med ett vidare systemperspektiv, som omfattar både det tekniska systemet och underhållslösningen, säkerställer man att hela systemet fungerar innan man tar det i drift! Nu har vi istället genomfört en miljardinvestering i ett nytt trafiksystem i Lund som inte fungerar som tänkt och förtroendet för spårburen trafik har återigen fått sig en törn.

---

[1] https://jarnvagar.nu/ingen-svarv-och-inga-reserver-i-lund/

Validering definieras i 50126 som ”confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled”¹. Det handlar alltså om att svara på frågan “har vi byggt rätt system?”. Det är också så standarden förklarar syftet med systemvalidering när den beskriver verifiering och validering: ”to assure that the system under consideration meets the specified requirements for the intended use or application”².

I beskrivningen av systemvalideringsfasen beskriver man att syftet med denna fas är att ”confirm by examination and provision of objective evidence that the system under consideration in combination with its Safety-Related Application Conditions complies with the RAMS requirements”³. Denna nyansskillnad bör förstås genom att man redan i kravspecifikationsfasen genomförde kravvalidering, d.v.s. man säkerställde att systemkraven möter behoven för ”intended use or application”. Återstår då att påvisa att systemet uppfyller kraven.

Som nämnts i tidigare blogginlägg är man i standarden inte konsekvent i hur man använder begreppet ”RAMS-krav”. I kravspecifikationsfasen omfattar RAMS-kraven systemets kompletta kravspecifikation, här begränsar man sig till de specifika kraven på just RAMS-egenskaperna. Även när man utvecklar resonemanget om verifiering och validering i kapitel 6.7, står det att EN 50126 (endast) berör V&V avseende RAMS men att det ska vara en integrerad del av övrig V&V-verksamhet. Vi bör därför betrakta den validering som beskrivs i EN 50126 i kontexten av systemets hela validering, vilket stämmer med det jag skrivit tidigare om att det är hela systemet som befinner sig i en viss livscykelfas, det är inte en RAMS-livscykel frikopplad från resten av systemet.

Till definitionen av termen validering i EN 50126 finns en not som säger att ”the use conditions for validation can be real or simulated”. Defintionen är hämtad från IEC 60050-192:2015 som i sin tur hämtat den från ISO 9000. I vissa fall stämmer det nog att användningsbetingelserna kan vara simulerade. Om man exempelvis tänker sig programvara som valideras i sin hårdvara så behöver inte nödvändigtvis användningsbetingelserna för hela systemet vara desamma som där det så småningom skall installeras. Man kan också tänka sig att man bygger en mock-up av ett fordon och provinstallerar ett delsystem för att validera underhållsåtgärderna. I normalfallet krävs dock att systemet är installerat i sin avsedda användningsmiljö för att fullständig validering skall kunna genomföras.

Med den bredare systemsyn (tekniskt system samt underhållssystem) som beskrivs i denna blogg, är det viktigt att systemvalideringen inte enbart begränsas till det tekniska systemet. Om systemkravspecifikationen gjorts korrekt så omfattar den även krav på underhållssystemet och då faller detta sig naturligt. I S-Series Integrated Logistics Support (ILS) specifications beskrivs validering på följande sätt, där vi kan se att det inte enbart är det tekniska systemet som ingår utan även underhållslösningen:

“The validation process guarantees that the stakeholder requirements are met and provides the total Product including the related services the right solution to the customer’s problem.”⁴

EN 50126 del 2 har ett särskilt fokus på säkerhet, och då det som på engelska benämns functional safety, ett begrepp som inte helt enkelt låter sig översättas då den svenska termen ”funktionssäkerhet” normalt avser den engelskan termen reliability. Jag väljer att använda termen ”säkerhet” som också används i EN 50126.

I del 2 av EN 50126, som berör systeminriktad säkerhetsmetodik, inför man krav på oberoende mellan olika roller. Begreppet validering ges där i mångt och mycket en alltför snäv innebörd med enbart fokus på säkerhet. Över huvud taget har EN 50126 ett särskilt fokus på säkerhet, samtidigt som standarden beskriver att den omfattar även RAM. Det är dock viktigt att ha i åtanke att det enbart är inom säkerhetsområdet som kraven på oberoende mellan olika roller finns! Därför är det också lämpligt att särskilja säkerhetsvalidering från övrig validering.

Hanteringen blir lite olika ifall valideringen genomförs i syfte att demonstrera konstruktionen och dess kravuppfyllnad inför serieproduktion eller om syftet är att validera en komplett anläggning. Detta måste tydliggöras i valideringsplanen utifrån projektets anpassning av livscykelmodellen.

Ur ett RAM-perspektiv gäller det dels att validera det tekniska systemets RAM-krav och dels att visa på att underhållslösningen fungerar.

För validering av felintensitet (reliability) är det vanligt förekommande att kontrakt innehåller en provperiod som ska omfatta ett visst antal drifttimmar eller körmil. Som vi diskuterade i förra blogginlägget krävs lång tid för att bevisa kravuppfyllnad för felintensitet och ibland krävs att systemet går i kommersiell drift en viss tid innan detta kan uppnås. Tyvärr kan detta ibland leda till att systemkomponenter behöver bytas ut efter att systemet har tagits i kommersiell drift för att valideringen visar att kraven inte uppfylls. Men ofta finns inte möjligheten att uppnå tillräcklig drifttid på annat sätt.

Validering av teknisk tillgänglighet (availability) måste ta hänsyn till om systemet innehåller tekniska lösningar som gör att det bibehåller sin funktionalitet även om fel inträffar, ex.vis redundans. Här kan man behöva injicera fel i systemet för att påvisa att denna typ av mekanismer fungerar som de ska i den avsedda användningsmiljön.

Validering av underhållsbarhet (maintainability) görs normalt på ett urval av underhållsåtgärderna. Mekanikerutbildning och underhållsdokumentation är två nyckelkomponenter i underhållslösningen för att underhållsbarheten ska kunna valideras.

När det gäller validering av att underhållslösningen fungerar som avsett har man stor nytta av att ha tagit fram en kravspecifikation för denna. Lämpliga aspekter att säkerställa vid valideringen är:

• Finns den tekniska dokumentationen (såväl användardokumentation som underhållsdokumentation) tillgänglig för dem som ska ha tillgång till den?
• Finns alla utbildningsmoduler framme, inklusive utbildningsmaterial och e-learning-moduler? Har utbildningarna rätt innehåll?
• Finns alla reservdelar och förbrukningsvaror upplagda i därför avsedda system så att de går att beställa?
• Finns underhållspersonal eller kontrakt med underhållsleverantörer? Har de genomgått utbildning?
• Finns nödvändiga datorsystem (ex.vis underhållsmoduler i CRM-system) och fungerar informationsutbytet mellan olika aktörers datorsystem?
• Finns nödvändiga faciliteter såsom verkstäder?
• Finns den hanteringsutrustning som krävs för reservdelar och för systemet självt?
• Finns alla specialverktyg och testutrustning på verkstäderna och upplagda i system så att de går att beställa?

EN 50126 ställer även krav på att en process ska etableras i denna fas för att senare inhämta och utvärdera drift- och underhållsdata. Denna process och eventuella system som behövs för detta behöver definieras tidigt (redan i konceptfasen), det kan ju till exempel krävas att det tekniska systemet måste ha specifik funktionalitet för att stödja en sådan process.

---

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

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

[3] EN 50126-1:2017, kap. 7.10.1

[4] International guide for the use of the S-series Integrated Logistics support (ILS) specifications (SX000i), chapter 2, section 3.2.7

Enligt EN 50126 är syftet med denna fas att bygga ihop och installera det integrerade systemet samt demonstrera att det integrerade systemet fungerar såsom definierat av sina gränssnitt. Man ska också demonstrera att det integrerade systemet uppfyller RAMS-kraven. Här är det tydligt att standarden med ”det integrerade systemet” avser det tekniska systemet för parallellt ska man initiera ”system support arrangements”.¹  Mer specifikt ska följande genomföras:

1. start staff training
2. make system support procedures available
3. establish spare parts provision
4. establish tool provision

Problemet med detta synsätt är dock att det överordnade RAM-kravet avseende operationell tillgänglighet ju kräver att även underhållslösningen möter sina krav och detta måste också demonstreras – inte bara ”initieras”!

Här är det också tydligt att författarna av EN 50126 inte är konsekventa i hur de använder begrepp i standarden. I Kravspecifikationsfasen skriver man att RAMS-kraven omfattar såväl funktionskrav och prestandakrav som säkerhetsmål för säkerhetsfunktionerna, underhållskrav, gränsytekrav, krav från användningsmiljön och driftprofilen, etc. Här skiljer man nu på dessa.

Oavsett om underhållslösningen ska initieras eller demonstreras (verifieras) måste den ha realiserats innan denna fas påbörjas. Teknisk dokumentation (förar- och underhållsmanualer, reservdelsdata, m.m.) ska finnas framme, utbildningsmaterial likaså (inkl. eventuella riggar som kan behövas för att öva användning, felsökning eller reparationer), försörjningskedjan för reservdelar och förbrukningsvaror ska ha trimmats in, faciliteter ha anskaffats (byggts eller förhyrts), hanterings- och förpackningslösningar ska ha tagits fram (både för hantering av reservdelar och om det behövs någon sådan lösning för driften), likaså support- och testutrustning (verktyg, datorprogram, m.m.). Personal, både för drift och underhåll, ska vara anställda eller ha kontrakterats och olika datorsystem ska ha integrerats (ex.vis underhållsplaneringssystem hos både kunden och underhållsleverantören). Detta kan vara komplext, då det ofta är olika aktörer inblandade i olika delar av underhållslösningen.

EN 50126 ställer också krav på att alla SRAC:ar (Safety-Related Application Conditions, villkor som måste vara uppfyllda för att systemet ska anses säkert) är uppfyllda vid integrationen.

(Konceptet med SRAC:ar förtjänar en viss utvikning, även om det egentligen inte är en RAM-fråga. SRAC:ar har blivit en mer eller mindre accepterad metod att hantera brister i systemet eller att friskriva sig från fullt ansvar. Och också ett tecken på att man inte har den bredare systemsyn (tekniskt system samt underhållssystem) som beskrivs i denna blogg. Har man bara formulerat en tillräckligt heltäckande uppsättning SRAC:ar kan man alltid lämna över ansvaret för systemets säkerhet på någon annan. I stället bör attityden till SRAC:ar vara att se dem som ett misslyckande i att leverera ett system som uppfyller de ställda kraven. Sen kan det vara så att det exempelvis krävs att en viss underhållsåtgärd genomförs med viss regelbundenhet för att systemet ska vara säkert, men då bör det vara ett resultat av ett designval där denna lösning är det bästa sättet att uppfylla kraven ur ett LCC-perspektiv. Därigenom blir det en del av systemarkitekturen och ett krav på underhållssystemet.)

Standarden beskriver integration i två steg, där steg 1 är att integrera systemets delar och steg 2 är att integrera systemet i dess överordnade system och därmed förbereda för systemvalidering. I Kravspecifika-tionsfasen gör man ingen åtskillnad på kund-/intressentkrav och systemkrav. I de flesta standarder om system- och produktutveckling definieras verifiering som att man visar att systemet uppfyller de tekniska systemkraven medan validering visar att systemet möter kundens behov i dess tänkta användningsmiljö (vilket också är definitionen i EN 50126). Med denna åtskillnad hade man i stället kunnat använda begreppet verifiering där EN 50126 använder demonstration. EN 50126 gör heller ingen definition av begreppet demonstration. (Demonstration brukar anges som en av flera verifieringsmetoder, av mer kvalitativ natur. Andra vanligt förekommande metoder är inspektion, analys, test och certifiering.) Validering hade inte gjorts mot systemkraven utan mot kund- eller intressentkraven. Nu blir det otydligt vad man demonstrerar respektive – i nästa fas – validerar.

Demonstration av det tekniska systemets felintensitet (reliability) kräver väldigt många timmars drifttid. IEC 61124 och MIL-HDBK-781 är två standarder som behandlar detta. Tabellen nedan, tagen ur MIL-HDBK-781, visar att, beroende på vilken risk för felaktigt testutfall som kund respektive leverantör (kolumn α resp. β) är beredd att ta och vilken designmarginal systemet har (kolumn Discrimination ratio) behöver man ha en testlängd som är mellan ca 5 och 45 ggr det MTBF-värde man har kravställt för att kunna säga om MTBF-kravet är uppfyllt eller inte (kolumn Accept resp. Reject). Ett system som har ett MTBF-krav på 10 000 timmar (något som inte är helt orimligt för ett delsystem i ett fordon) behöver alltså testas i 450 000 timmar om det teoretiska MTBF-värdet för systemet är 15 000 timmar (designmarginal 1,5) och både kund och leverantör accepterar en ~10%-ig risk (12% resp. 9,9%) att resultatet av testet är fel (dvs att man godkänner eller underkänner ett system på felaktiga grunder). Här ser vi då vikten av att både ställa rimliga krav och att göra en ordentlig plan för hur RAM-kraven ska demonstreras. Vad ska bevisas som en del av verifieringen i denna fas och vad ska bevisas i systemvalideringen i nästa fas?

Om denna fas syftar till att integrera hela systemet inför systemvalidering i nästa fas eller om den syftar till att integrera för senare validering av konstruktionen kan man välja lite olika upplägg för att demonstrera RAM-kraven. Man kanske bör titta på olika typer av forcerad testning (s.k. ALT – accelerated life test), använda tillgängliga driftdata från andra installationer av liknande system för att visa på kravuppfyllnad. Kritiska komponenter kan tidigt sättas i långtidstester i labbmiljö.

Vissa aspekter av underhållslösningen kan inte verifieras i samband med att de utvecklas utan måste verifieras tillsammans med det integrerade tekniska systemet. Det gäller bland annat underhållsinstruktioner som kan behöva ha det tekniska systemet installerat i sin användningsmiljö för att kunna verifieras. (I vissa fall kan inte underhållsdokumentationen ens färdigställas förrän systemet är installerat om del av dokumentationen behöver innehålla bilder på detta.)

En tydlig plan för integration, verifiering och validering (IV&V), baserad på projektets process- och livscykelanpassning, är nödvändig för att säkerställa att ett lyckat genomförande.

---

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

Den livscykelmodell som används i EN 50126 bygger på att hela systemet produceras i denna fas, integreras i fas 8 och valideras i fas 9. Detta kan vara korrekt för exempelvis en fast anläggning, men knappast när det handlar om ett system som består av flera serieproducerade instanser, ex.vis hela fordon eller vid uppgraderingar av signalsystem till fordon. Där är det snarare så att verifiering och validering av själva konstruktionen genomförs innan man påbörjar serieproduktionen. Därefter sker kvalitetskontroller som säkerställer att serieproduktionen lever upp till de krav som verifierats och validerats tidigare. På systemnivå kan ytterligare verifiering och validering ske, t.ex. i form av s.k. RAM demonstration som sker över längre tid. Likaså kan underhållslösningen verifieras och valideras efter att serieproduktion påbörjats men innan systemacceptans uppnås.

Oavsett hur produktionen genomförs blir kvalitetssäkringsåtgärderna och -kontrollerna en del av RAM-bevisningen. Och det är egentligen de enda RAM-relaterade uppgifter som EN 50126 tar upp för produktionsfasen.¹

Men, som jag tog upp i förra veckans blogginlägg så måste även underhållslösningen produceras. Den tumregel jag beskrev där var att man ska ha definierat sin underhållslösning när designfasen är över men inte nödvändigtvis behöver ha realiserat den. Återstår då själva realiseringen. I nästa fas, Integrationsfasen, ingår det att man ska påvisa att systemet möter sina RAM-krav, och om vi ska kunna göra det måste vi ha underhållslösningens komponenter framme.

I produktionsfasen (senast!) ska därför även dessa komponenter produceras. Teknisk dokumentation (förar- och underhållsmanualer, reservdelsdata, m.m.) ska tas fram, utbildningsmaterial ska produceras (inkl. eventuella riggar som kan behövas för att öva användning, felsökning eller reparationer), försörjningskedjan för reservdelar och förbrukningsvaror ska trimmas in, faciliteter ska anskaffas (byggas eller hyras), hanterings- och förpackningslösningar ska tas fram (både för hantering av reservdelar och om det behövs någon sådan lösning för driften), likaså support- och testutrustning (verktyg, datorprogram, m.m.). Personal, både för drift och underhåll, måste anställas eller kontrakteras och utbildas och olika datorsystem ska integreras (ex.vis underhållsplaneringssystem hos både kunden och underhållsleverantören).

Här kan många olika aktörer vara inblandade. Den som köper in fordon kanske inte äger eller driftar depåerna. Underhållstjänsterna läggs ofta ut på entreprenad. IT-driften är ofta outsourcad hos såväl operatören/infrastrukturägaren som hos underhållsleverantören. Vi ser en ökad komplexitet såväl i de tekniska systemen som i de organisatoriska uppläggen. Underhållstjänster ska upphandlas och om det är en offentlig aktör som ska upphandla dessa tjänster finns risk för överklagande som kan leda till att dessa kontrakt inte finns på plats när de behövs. Befintliga avtal kan behöva utökas med nya delar för att täcka även det nya tekniska systemet.

Men utan alla dessa komponenter på plats får vi inte den tillgänglighet som vi vill uppnå, och som är målet för hela RAM-arbetet! Och tyvärr ser vi ofta att det är här det fallerar. Det där felsökningsverktyget som behövdes var något som mjukvaruutvecklarna tog fram för sina egna behov men det är inte anpassat för en underhållare som använder det några få gånger om året. Reservdelar finns inte framme när man behöver dem, för man hade inte gjort tillräckliga analyser av vilka som behövdes. Felsökningsmetoden är så avancerad att en utvecklingsingenjör måste flygas in för att reda ut vad som egentligen är felet. Exemplen kan göras många men pekar alla på vikten av ett ordentligt utfört RAM-/ILS-arbete.

---

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

EN 50126 är inte särskilt detaljerad när det gäller arbetet i denna fas. Man ska skapa delsystem och komponenter som möter systemkraven (eller RAMS-kraven, som de ju kallar dem) och bevisa att delsystemen och komponenterna möter sina krav. Slutligen ska man förfina planerna för efterföljande livscykelfaser.¹ Det står också att drift- och underhållsprocedurer skall förberedas och att utbildningsinsatser för drift- och underhållspersonal ska definieras.²

Här skulle man önska att EN 50126 stannade upp och verkligen utvecklade resonemanget. Att förbereda drift- och underhållsprocedurer och att ta fram utbildningar är ju det helt centrala i att ta fram underhållslösningen! Att balansera det tekniska systemets egenskaper med förmågor i underhållslösningen är som jag skrivit tidigare nyckeln för att uppnå den operationella tillgänglighet vi vill ha. ILS-standarder, som S-Series Integrated Logistics Support (ILS) specifications, ägnar mycket stort utrymme åt just detta.

Så vad är det som behöver göras? Ja, helt kortfattat är det (se tidigare blogginlägg) tre processer som behövs; task identification, maintenance planning och support solution development. Först genomför vi ett antal analyser för att identifiera drifts- och underhållsåtgärderna; förebyggande uh, avhjälpande uh, mjukvaruuppgraderingar, åtgärder vid olyckor eller andra ”special events” (kan ju vara allt från åska till klotter och annat sabotage). Därefter utvecklas underhållsplanen. Genom att analysera underhållsåtgärderna – hur lång tid tar de, vilka reservdelar, verktyg och faciliteter behövs för att utföra dem, vilken underhållsnivå hör de hemma på, vilken kompetens behövs, vilka utbildningsbehov finns – så får vi fram underlaget för att sedan utveckla alla delar som ingår i underhållslösningen.

Hur långt ska man då ha kommit i detta arbete när designfasen är avslutad? Vad innebär det att ”Operation and maintenance procedures shall be prepared”? Som i så många andra fall får man nog säga ”det beror på”. Man måste alltid skräddarsy processen utifrån respektive projekts förutsättningar, det som på engelska brukar kallas för tailoring. EN 50126 gör ingen skillnad på projekt med olika karaktär. Hur skiljer sig ex.vis förutsättningarna mellan ett projekt som utvecklar ett system som ska serieproduceras från ett som tar fram en specifik lösning för en fast anläggning? Vi kommer att belysa det mer i senare faser. Som en generell tumregel skulle jag dock säga att man ska ha definierat sin underhållslösning när designfasen är över men inte nödvändigtvis behöver ha realiserat den. Man behöver veta hur underhållslösningen ska se ut innan man fryser det tekniska systemets design!

Ett sätt att göra det kan vara att betrakta underhållslösningen som ett eget delsystem och ta fram en kravspecifikation för detta system baserat på samtliga analyser som genomförts.

I takt med att det tekniska systemet utvecklas, realiseras även dess inneboende RAMT-egenskaper (reliability, availability, maintainability, testability), och här kravställer EN 50126 att en RAM-analys genomförs.³ Detta behöver självfallet också följas upp, så att eventuell påverkan på underhållssystemet tas omhand. Om ex.vis redundans används som ett sätt att öka den tekniska tillgängligheten, så innebär det också att felintensiteten ökar eftersom systemet innehåller fler komponenter. Därigenom påverkas även underhållsplanen.

EN 50126 beskriver även att produktionssystemet ska förberedas i denna fas.⁴ I många fall är det lämpligt att betrakta produktionssystemet som ett eget system med en egen livscykel, där vårt system är en stark intressent. Kravinsamlingen för detta system påbörjas när systemlösningen börjar ta form i systemdefinitionsfasen eller tidigare. RAM-krav från vårt system-i-fokus, som påverkar produktionssystemet, tas om hand i denna kravinsamling och vi blir med i valideringen av produktionssystemet. En viktig RAM-aspekt på produktionssystemet är självklart att reservdelar ska kunna produceras även efter att det tekniska systemet har tagits i drift. Åtgärder och metoder för kvalitetssäkring av produktionen måste förberedas.

När man ”förfinar” planerna för efterföljande livscykelfaser så kan det se lite olika ut beroende på hur man har anpassat sin livscykelmodell till just det aktuella projektets förutsättningar. Man kan tänka sig några olika scenarier:

– Om vi bygger en anläggning så kan man tänka sig att designfasen och efterföljande faser i stort sett är sekventiella. Vi designar systemet, sen producerar vi det, integrerar och validerar det innan det slutligen lämnas över till kunden.

– Om vi däremot utvecklar ett system för serieproduktion kan man i stället tänka sig att designfasen och efterföljande faser har ett stort överlapp i tid. Vi designar systemet, bygger ett eller flera exemplar som används för verifiering och validering av konstruktionen innan vi slutligen får systemet godkänt för serieproduktion. Det blir som att varje instans av systemet går igenom livscykeln på ”egen hand”. Men man kan också betrakta det som att valideringen av systemets konstruktion, likväl som valideringen av produktionssystemet, ingår i designfasen, och att produktionsfasen tar vid först vid serieproduktionsstarten.

Vikten av att göra en tydlig projektplan, inklusive process- och livscykelanpassning, innan man påbörjar sitt projekt kan inte nog understrykas!

---

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

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

[3] EN 50126-1:2017, kap. 7.7.2

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

I arkitekturfasen i EN 50126 ska man fördela systemets RAMS-krav till delsystem och komponenter samt designa ett system med delsystem och komponenter som fungerar tillsammans som ett system.¹ Här är det återigen olyckligt att man använder begreppet RAMS-krav, när det man beskriver är en systemarkitektur – termen borde har varit ”systemkrav”. För självklart är det ingen mening med att ta fram en arkitektur för enbart RAMS-krav – det är ju systemets funktionalitet som ska realiseras med hög tillgänglighet och utan att orsaka fara för omgivningen!

För att uppnå tillgänglighetskraven är det som nämnts i tidigare blogginlägg samspelet mellan det tekniska systemets egenskaper och underhållssystemets förmågor som samverkar. När man allokerar krav till delsystem och komponenter behöver man därför titta på bägge dessa och göra avvägningar ur ett livscykelkostnadsperspektiv. Vilken lösning ger bäst livscykelkostnad – ett robustare tekniskt system eller en modifierad underhållslösning?

EN 50126 har ingen beskrivning över huvud taget av hur underhållslösningen kommer fram, utan helt plötsligt – i fas 8 – ska vi etablera underhållslösningen genom att utbilda personal, ha underhållsprocesser och rutiner för försörjning av reservdelar och verktyg på plats.² Men, som vi diskuterat tidigare är utvecklingen av underhållssystemet en aktivitet som måste pågå parallellt med framtagningen av det tekniska systemet – den materialiserar sig inte ur tomma intet! Det fortsatta RAM-arbetet baseras på det tekniska systemets nedbrytning. I denna fas behöver vi därför ta fram kandidater för det fortsatta analysarbetet och genom ett antal iterationer uppnår vi en systemarkitektur för hela systemet (tekniskt system + underhållssystem) som möter alla systemkraven, såväl funktionskrav som tillgänglighetskrav. Först då kan vi frysa systemarkitekturen.

EN 50126 har ett ensidigt fokus på det tekniska systemets egenskaper och tittar inte på hur underhållslösningen bidrar till att nå tillgänglighetskraven. Detta är en fundamental skillnad mellan säkerhetsarbete och arbetet med RAM/ILS (integrerat logistikstöd, eng. integrated logistics support). När man tänker säkerhet så vill man i första hand hitta tekniska barriärer mot farorna och först när det inte är realistiskt att införa en teknisk barriär överför man risken från det tekniska systemet till något omgivande system (ofta underhållssystemet eller driftorganisationen) via s.k. SRAC:ar (safety-related application conditions) där man helt enkelt säger att om inte vissa säkerhetsrelaterade villkor är uppfyllda tar leverantören inget ansvar för systemets säkerhet. När det gäller ILS, så är det däremot samspelet mellan dels egenskaper hos det tekniska systemet, dels förmågorna i underhållssystemet som ger oss den operationella tillgängligheten. Här kanske vi rent av vill lägga över visst ansvar på underhållssystemet för att det helt enkelt är den totallösning som ger bäst livscykelkostnad.

RAM- (eller ILS-) -arbetet och säkerhetsarbetet skiljer sig därmed åt. Men det finns också väldigt tydliga beröringspunkter i och med att det är samma tekniska system med samma felmoder som kan leda till såväl farliga situationer som till otillgänglighet. Dessutom, med ett MTO-perspektiv (människa, teknik, organisation), så kan otillgänglighet leda till att operatören vidtar åtgärder som i sin tur kan bli trafikfarliga. Det gäller därför att ha med säkerhetsperspektivet när man balanserar egenskaperna i det tekniska systemet mot underhållssystemets förmågor.

---

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

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

Syftet med kravspecifikationsfasen i EN 50126 är definierat i fyra delar:

• Att specificera de samlade RAMS-kraven
• Att specificera processen och kriterierna för hur bevisning av kravuppfyllnad av RAMS-kraven ska genomföras
• Att tillhandahålla en komplett kravmängd för efterföljande livscykelfaser
• Att specificera de krav som behövs för uppföljning av drift och underhåll i driftsfasen (här hänvisar man till en process som ska definieras i säkerhetsplanen, som vi inte berör närmare i denna blogg)

Kraven man ställer på vad ”de samlade RAMS-kraven” ska innehålla är omfattande; funktionskrav, prestandakrav, säkerhetsmål för säkerhetsfunktionerna, underhållskrav, gränsytekrav, krav från användningsmiljön och driftprofilen, etc. Det är tydligt att detta är långt ifrån rena RAMS-krav, utan det är systemets kompletta kravspecifikation som avses. Och detta stämmer ju bra med vad vi noterat tidigare – att det är hela systemet som befinner sig i en viss livscykelfas. Därigenom är det också olyckligt att man använder benämningen RAMS-krav – ”systemkrav” hade varit mycket bättre!

Om vi följer stegen i EN 50126 har vi hittills i konceptfasen analyserat problemdomänen genom att ta fram konceptbeskrivningar, ex.vis underhållskonceptet och RAM-mål i form av krav på operationell tillgänglighet. Vi har också börjat titta på lösningsdomänen genom att påbörja framtagandet av systemdefinitionen och gjort en initial riskanalys för att identifiera ytterligare krav ur ett säkerhetsperspektiv. I riskanalys-fasen har vi också tittat på tillgänglighetskrav för de olika funktionerna som definierats i systemdefinitionen. Nu ska lösningen bli mer detaljerad i form av formella krav.

Låt oss ta ett steg tillbaka och titta på den RAM-process som presenterades i ett tidigare blogginlägg:

I bilden på RAM-processen finns såväl kundkrav som systemkrav. I en typisk kund-leverantörsrelation finns båda dessa kravmängder och, som jag ser det, hör båda hemma i kravspecifikationsfasen i EN 50126. Standarden tar dock ingen hänsyn till att dessa två perspektiv finns. Men högst sannolikt är inte kundkravspecifikationen så detaljerad och komplett att den kan användas som underlag för realisering av systemet. Och därför kan inte en leverantör komma undan sin roll i att ta fram den systemkravspecifikation som denne ska använda för att realisera systemet.

EN 50126 ställer också krav på att en valideringsrapport ska tas fram i denna fas. Det står att valideringen ska täcka fas 1-4 och handlar om att validera kraven på systemet och processen för att ta fram dem. Validering svarar ju på frågan om systemet man byggt möter kundens behov (”har vi byggt rätt system?”) och kravvalidering handlar, som EN 50126 skriver, om att förvissa sig om att systemkraven har blivit ordentligt specificerade.¹ Valideringsrapporten som tas fram ska både titta på processen som har använts för att ta fram kraven (fas 1-4) men också på kraven i sig; den ska innehålla ”confirmation that all system requirements (including RAMS, functional, and external legal requirements) are adequately analysed and specified in order to allow the system under consideration to serve the intended use”.²

Kravvalidering svarar alltså på frågan “om vi bygger ett system baserat på dessa krav, får vi då ett system som möter kundens behov?”.

EN 50126 beskriver att ansvaret för att genomföra kravvalideringen generellt sett är kundens ansvar.³ Detta är vanskligt för det kan ge intrycket av att leverantören inte har någon roll i framtagningen av systemkraven eller i kravvalideringen. I stället bör man se det som att kravvalideringen är en avstämningspunkt mellan kund och leverantör när kunden bekräftar att det system som definieras av systemkravspecifikationen möter kundens behov. Kundens ansvar är alltså att godkänna systemkravspecifikationen som leverantören har tagit fram!

---

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

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

[3] EN 50126-1:2017, kap. 6.7.3

Nästa ”fas” i EN 50126 är den s.k. ”Riskanalysfasen”. Här är standarden dock tydlig med att det inte är någon egentlig livscykelfas då det t.o.m. står att ”av förenklingsskäl visar livscykelbeskrivningen i denna standard riskanalys som en engångsaktivitet i en tidig fas av projektet” (min översättning).¹ Syftet med den tidiga riskanalysen beskrivs som en utgångspunkt för att definiera de riskbaserade RAMS-systemkraven och därefter ska riskhantering, inklusive förnyad riskanalys, vara en ständigt pågående aktivitet.

Huvudfokus för riskhanteringen i EN 50126 är säkerhetsrisker, men även RAM-relaterade risker ska analyseras. De använder termen “RAM equivalent” för att göra en jämförelse med säkerhetstermen fara (eng. hazard). ”RAM equivalent” definieras i EN 50126 som ”a condition that could lead to commercial loss related to RAM”².

I Annex C i standarden ger man exempel på klassificeringar av RAM-riskerna och här menar jag att man har styrt branschen fel. Det man beskriver är tre felkategorier (significant, major, minor) och även om Annex C endast är av informativ karaktär så påverkar det hur man tänker. Det leder till att man ställer krav på det tekniska systemet i form av felkategorier, vilket i och för sig inte är fel men enbart det ger ett alltför snävt perspektiv på RAM-området. Som beskrivits i tidigare blogginlägg är det kombinationen av det tekniska systemet och underhållssystemet som ger den operationella tillgängligheten.

Låt mig ge ett exempel. Om man kravställer t.ex. max 0,5 stoppande fel per miljon kilometer för ett fordon, där stoppande fel definieras som ett fel som försenar trafiken mer än 15 minuter, så gör man ju ingen åtskillnad mellan ett fel som försenar trafiken i 16 minuter och ett som försenar trafiken i 16 timmar – men det är ju en avsevärd skillnad! Och då hjälper det ju inte att man även har kravställt en maximal reparationstid, för den börjar räknas först när fordonet har kommit in till verkstaden och arbetet påbörjas. Och finns det inte reservdelar framme, verkstäder med rätt infrastruktur och utrustning, personal med rätt utbildning, etc. så kan fordonet bli taget ur trafik väldigt länge.

Det är därför inte tillräckligt att ställa krav på hur ofta olika typer av fel får inträffa, utan man måste kravställa egenskaper och förmågor i hela systemet (tekniskt system och underhållssystem).

Riskanalys definieras i standarden som en metod att systematiskt använda all tillgänglig information för att identifiera faror eller ”RAM equivalents”.³ (Notera dock att det är en utvidgning av definitionen i jämförelse med den vedertagna som man refererar till i kapitel 3 i standarden.) Jag vill hävda att de LSA-analyser som beskrivits i tidigare blogginlägg är den metod som bör användas för att analysera systemets ”RAM equivalents”. Tidigt i livscykeln ska driftprofil och underhållskoncept definieras och krav på operationell tillgänglighet tas fram. Man kan ställa olika tillgänglighetskrav på olika funktioner i systemet utifrån den funktionsbeskrivning som gjorts i systemdefinitionen och det görs utifrån de operativa behoven! Därefter jobbar vi systematiskt med såväl analyser av det tekniska systemets egenskaper som analyser som syftar till att ta fram underhållslösningens förmågor så att kraven på operationell tillgänglighet kan uppnås.

Jag har skrivit det förut och det tål att upprepas: Synen på RAM-arbetet inom järnvägen måste förändras från att undvika risk eller problem till att söka lösningar. Från att undvika att förlora till att vilja vinna.

Sluta tänka risk vad gäller RAM, tänk i stället ”hur skapar vi tillgänglighet” genom egenskaper hos det tekniska systemet och förmågor hos underhållssystemet.

---

[1] EN 50126, kap. 7.4.1

[2] EN 50126, kap. 6.3, 7.4.1

[3] EN 50126, kap. 6.3

Om konceptfasen beskriver problemdomänen (eng. problem domain), syftar systemdefinitionsfasen till att påbörja beskrivningen av lösningsdomänen (eng. solution domain). Men EN 50126 ställer också krav på att man i denna fas definierar RAM- och säkerhetsorganisationen för systemet och tar fram RAM- och säkerhetsplanerna. (Säkerhetsplanen går vi inte in närmare på här, då fokus ligger på RAM-arbetet.)

Egentligen är systemdefinitionsfasen ingen distinkt livscykelfas utan det standarden beskriver här är tre leverabler som ska tas fram och vad de ska innehålla. För RAM-plan och säkerhetsplan skriver man uttryckligen att om vissa delar av innehållet inte finns tillgängligt så tidigt i livscykeln så kan man fylla på med den informationen senare.¹ Motsvarande skrivning finns inte för systemdefinitionen. Men i standarden står det att man ska välja en livscykelmodell för sitt ”system under consideration” och att den modellen ska ta höjd för möjligheten till iterationer i och mellan faser.² Det betyder de facto att systemdefinitionen, liksom alla leverabler som kravställs i EN 50126, är levande dokument – inte bara de som explicit beskrivs som sådana i standarden! Vi tar helt enkelt fram en systemdefinition baserat på för stunden tillgänglig information och uppdaterar den efterhand som ny information blir tillgänglig.

Skillnaden mellan livscykelfaser och processer/aktiviteter är att indelning i livscykelfaser syftar till att leda verksamheten på ett effektivt sätt. Fasövergångar syftar till att fatta beslut; ex.vis beslut om att påbörja utveckling, beslut om att sätta igång produktion, beslut att driftsätta ett system och beslut att avveckla systemet. De är beslutspunkter då man fastställer att tillräcklig information finns framme för att ta nästa steg, som ofta handlar om att göra en investering, etablera en organisation eller att tillsätta mer personal. Processer och aktiviteter, däremot, kan löpa över flera (alla) livscykelfaser men med olika tyngd i olika faser.³ En klassisk bild – den s.k. ”sega råtta-bilden” – av detta, som illustrerar väl hur olika aktiviteter löper med olika tyngd över flera faser, finns i Rational Unified Process (RUP).⁴ Man itererar alltså inte mellan olika faser. Endast i undantagsfall kan man tvingas göra om och gå tillbaka till en tidigare fas. Däremot kan man uppdatera leverabler och då måste man hålla koll på vilka andra (senare) leverabler som påverkas av en sådan uppdatering.

Olika livscykelmodeller (faser) och utvecklingsmodeller (processer/aktiviteter) passar bra för olika typer av system. För ett mjukvarusystem, där utvecklings- och produktionsmiljö är samma sak, kan en agil process vara lämplig och en livscykelmodell med stegvis införande av mer och mer funktionalitet, likt RUP. För ett mekaniksystem, där utvecklingen sker i en cad-miljö och där det krävs en stor investering i produktionsanläggning kanske en sådan livscykelmodell inte är den lämpligaste.

EN 50126 beskriver enbart en systemdefinition, en RAM-plan och en säkerhetsplan per system. Man har perspektivet ”ett system, ett projekt, en livscykel”. Men system och projekt har olika livscykler. Och över systemets livscykel är flera aktörer inblandade; en projektorganisation hos kunden ansvarar för upphandling av en systemleverantör som i sin tur utvecklar och installerar systemet, när systemet är levererat ansvarar kundens driftorganisation för den dagliga driften och underhållsplaneringen, en upphandlad underhållsleverantör sköter det trafiknära fordonsunderhållet, andra gör större revisioner, underhållsleverantörerna byts ut under systemets livslängd, osv. Det måste finnas en tydlighet i vem som gör vad av de olika aktörerna, respektive aktör måste planera sina respektive åtaganden under systemets livscykel. Enligt EN 50126 ska RAM-planen överenskommas mellan kund och leverantör. För säkerhetsplanen står det att den ska leva över systemets hela livscykel och att det därför är nödvändigt att definiera relationerna mellan de olika inblandade intressenterna.

Om man inte tänker till finns det en uppenbar risk för att ansvaret för olika aktiviteter och leverabler blir otydligt definierat eller missas i kontrakt mellan olika parter. Risken för otydlighet gäller framförallt fram till dess att systemet har gått in i driftfasen. Fram till dess kan det finnas väldigt olika uppfattning om i vilken fas man befinner sig. Kunden kanske uppfattar att man skriver kontrakt med leverantören medan man är i konceptfasen, medan leverantören tycker att man i princip redan är framme i tillverkningsfasen och endast ska sätta lite parametrar. Eller tvärtom, kunden tycker att man är i designfasen fastän kontraktskraven är alltför fluffiga för att kunna utgöra underlag för designarbetet.

Det gäller därför att tänka till hur man lägger upp arbetet och fördelar ansvaret.

Systemdefinition
Systemdefinitionen i EN 50126 beskrivs huvudsakligen ur ett ”black box”-perspektiv, den beskriver systemet utifrån dess funktioner och gränsytor utan att gå in på systemets realisering. Den ska även beskriva driftprofil, förutsättningar och villkor för drift och underhåll samt överväganden som behöver göras ur livslängds- och logistikperspektiv. Det kan ex.vis röra sig om att man behöver ta hänsyn till kringliggande/överordnade systems underhållsintervall, möjligheter till framtida (eventuellt redan kända behov av) systemuppgraderingar, behov av byggnation av nya underhållsfaciliteter eller reservdelslager, etc.

Vad gäller driftprofil så är det värt att notera att det inte räcker att referera till en driftprofil i en standard. Om vi t.ex. tittar på driftprofilen som beskrivs i ERTMS Subset 091, så står det tydligt att om driftförutsättningarna för systemet skiljer sig signifikant ifrån de antaganden som gjorts i Subset 091 så finns det en risk att systemets säkerhetsmål inte nås även om utrustningen uppfyller alla säkerhetskrav i standarden.⁵ Driftprofilen måste i detta fall i sin slutliga utgåva därmed analyseras till samma detaljnivå som man gjort i Subset 091.

Vidare ska systemdefinitionen innehålla beskrivning av systemets gränsytor; miljö (klimat, höjdnivå, elmiljö, etc.), gränsytor mot andra tekniska system, mot människor (användare, underhållspersonal, m.fl.), gränsytor mot andra aktörer, t.ex. utbyte av information mellan fordon och infrastruktur. Här kan användningsfall (use cases), aktivitetsdiagram, sekvensdiagram och tillståndsdiagram vara användbara beskrivningsmetoder.

CSM-RA ställer ju också krav på en systemdefinition. Är det då samma systemdefinition som EN 50126 beskriver? Ja, om vi håller oss till tekniska system är de två systemdefinitionerna åtminstone väldigt nära. Men CSM-RA har enbart fokus på risker, så för att systemdefinitionen vi pratar om här ska vara användbar för att även kunna titta på tillgänglighetsaspekten gäller det att inte glömma bort de så viktiga drift- och underhållsaspekterna som beskrivits ovan.

Här gäller det också att tänka till hur man lägger upp ansvaret. Kanhända att systemdefinitionen som kunden initialt tar fram inte ger den detaljinformation som leverantören behöver? Det är bra om det klargörs i kontraktet hur samarbetet ska gå till och vem som i så fall ska ansvara för att uppdatera systemdefinitionen, likväl som andra systemdokument.

RAM-plan
RAM-planen syftar till att planera de RAM-aktiviteter som ska genomföras. Som för alla planer är de knutna till en viss organisation och dess åtagande. En upphandlande organisation kan inte detaljplanera leverantörens arbete och på motsvarande sätt kan inte en leverantör ta ansvar för aktiviteter utanför dennes åtagande. Idén om en enda RAM-plan för systemet är därmed felaktig. Ett lämpligt upplägg kan vara att kunden har den överordnade RAM-planen och att respektive leverantör tar fram planer för sina respektive åtaganden.

I RAM-planen beskriver vi hur den generella RAM-processen beskriven i tidigare blogginlägg anpassas för detta specifika projekt. Mängden nya analyser som behöver göras beror bland annat på hur mycket nyutveckling projektet innehåller, hur mycket befintliga data som finns att tillgå och hur mycket av underhållslösningen som redan existerar. RAM-planen fylls sedan på med mer information efterhand som systemlösningen växer fram.

EN 50126 anger fyra huvudområden som RAM-planen ska innehålla: ledning av RAM-arbetet (management), samt de tre egenskaperna tillförlitlighet (R), tillgänglighet (A) och underhållsbarhet (M). Man har inte med framtagningen av underhållslösningen i beskrivningen av RAM-planens innehåll. RAM-planen bör därför utökas så att hela processen för RAM-arbetet täcks in.

Slutsats: Denna “livscykelfas” i EN 50126 beskriver kraven på tre leverabler (systemdefinition, RAM-plan och säkerhetsplan) som börjar tas fram tidigt i systemets livscykel men uppdateras efterhand. Ur ett RAM-perspektiv är driftprofilen och systemets interaktion med omliggande system (inklusive människor) samt de överväganden som behöver göras ur livslängds- och logistikperspektiv viktiga delar i systemdefinitionen för det fortsatta arbetet.

---

[1] EN 50126, kap. 7.3.2.2 och 7.3.2.3

[2] EN 50126, kap. 6.5.1

[3] Se t.ex. http://trevorknelson.com/2014/12/08/project-life-cycle-vs-process-groups/

[4] Se t.ex.  https://en.wikipedia.org/wiki/Rational_Unified_Process#/media/File:Development-iterative.png

[5] Se ETCS B3 R2, Subset 091, paragraf 10.1.1.2 (https://www.era.europa.eu/content/set-specifications-3-etcs-b3-r2-gsm-r-b1_en)