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”1. 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”2.
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”3. 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.”4
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