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.1 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.2 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