SIMLOX får bättre möjligheter att analysera operativ förmåga

Högre krav på resultat - leder till nya krav på Opus Suite. Reliability Block Diagram i SIMLOX ger en möjlighet att simulera mycket komplexa system eller system av system under olika driftförutsättningar och uppdrag.

Den nya funktionaliteten finns nu i form av Reliability Block Diagram eller RBD i SIMLOX och ger en möjlighet att simulera mycket komplexa system eller system av system under olika driftförutsättningar och uppdrag. Den möjliggör mer precisa analyser av såväl förmågan att genomföra föreskrivna uppdrag som belastningen på underhållsorganisationen.

Att bygga en modell innebär att förenkla verkligheten på ett sätt så att den går att förstå och förklara utan att för den skull ta bort viktiga aspekter. Den modell som ligger till grund för Opus Suite består av tre huvudsakliga delar; det tekniska systemet, dess supportlösning och driften. Fokus för Opus Suite har traditionellt framförallt varit att dimensionera och analysera supportlösningen. Därför har den delen av modellen också varit mest detaljerad. Att kunna beräkna vilken belastningen som uppstår på supportlösningen har varit utgångspunkten för beskrivningen av det tekniska systemet och dess drift. Det har i sin tur inneburit att det som varit viktigast att ta hänsyn när det gäller det tekniska systemet har varit hur driften genererar denna belastning i form av felutfall och underhållsbehov. I OPUS10 är det t ex viktigt att kunna modellera hur många felaktiga enheter som kan behöva repareras under ett år. Det har inte varit lika centralt att kunna beskriva hur fel i dessa enheter och väntan på enheter har påverkat möjligheterna för det tekniska systemet att utföra sina uppdrag. Den grundläggande ansatsen har varit att ett fel i någon del i systemet leder till att systemet blir otillgängligt. Att ett fel motsvarar ett otillgängligt system har varit en tillräckligt god approximation.

När ett ökat fokus läggs på att studera de tekniska systemens operativa förmåga att utföra olika typer av uppdrag så blir det också nödvändigt att förfina den del av modellen som beskriver det tekniska systemet. Att ett fel motsvarar ett otillgängligt system blir då en alltför grov approximation. Istället krävs det en möjlighet att i detalj beskriva vad en viss typ av fel innebär för möjligheten att genomföra ett specifikt uppdrag under specifika förhållanden. Föreställ dig till exempel en helikopter som transporterar passagarare från land till en oljeplattform. Under dagtid med bra väder kan man kanske acceptera att endast ha klocka och kompass medan det nattetid eller vid dåligt väderförhållande ställs helt andra krav på stödsystem för att få flyga. För fartyg som ska utföra en stor spännvidd av uppgifter under längre perioder och som egentligen är en plattform med en mängd olika system med olika grad av redundanser blir dessa samband ännu mer komplexa och viktiga att kunna beskriva, simulera och studera.

Reliability Block Diagram eller RBD ger Opus Suite-användarna möjligheten att beskriva redundanser och hur ett systems tillgänglighet påverkas då en enskild enhet går sönder. Dessa diagram består av alla i systemet ingående enheter sammankopplade i olika kombinationer av seriella och parallella block. Diagrammens parallella och seriella block kan även vara nästlade så att ett parallellt block kan byggas upp av seriella block som i sin tur kan vara uppbyggd av parallella block, osv. För de parallella blocken sätts ett villkor för hur många av de ingående blocken som behöver fungera för att hela det parallella blocket ska betraktas som att det fungerar.

I tillägg till denna beskrivning av hur ett fel påverkar tillgängligheten finns också behov av att ange hur mycket varje ingående enhet eller block utnyttjas eftersom detta kommer att bestämma hur många fel som kan förväntas att falla ut. I vår nya modell så går även detta att göra.

Även underhållet av ett system påverkas av om ett system är tillgänglig trots att det finns fel i systemet. För att hantera detta har stor möda lagts på att utveckla ny funktionalitet för att tillåta att underhåll av systemet, till exempel i form av utbyte av en enhet, ska gå att pausa för att kunna gå ut på uppdrag med en enhet som visserligen är trasig men som inte behövs för det uppdrag som ska utföras. Detta behov blir extra tydligt när det rör sig om stora komplexa system som ett fartyg där det i princip alltid är något som är trasigt men där det trots dessa fel oftast ändå går att använda systemet.

Ett exempel på hur denna funktionalitet går att använda för att undersöka och utvärdera kostnadseffektiviteten av designbeslut för det tekniska systemet, dess redundanser och dimensionering av underhållslösningen presenterades under The Annual Reliability and Maintainability Symposium (RAMS®), i januari 2015. I detta paper från konferensen går det att läsa mer om detta.