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”.1 Mer specifikt ska följande genomföras:
- start staff training
- make system support procedures available
- establish spare parts provision
- 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