IEC 61508 är en internationell standard som är grundläggande för säkerhetskritiska system inom olika industrier, från automotiv till processindustri och medicinteknik. Standarden fokuserar på funktionell säkerhet och definierar riktlinjer för att säkerställa att systemen fungerar korrekt, även vid fel eller oväntade situationer. Den är uppdelad i olika delar som täcker alla aspekter av säkerhet, från riskbedömning till design och drift av systemet.
Funktionell säkerhet handlar om att säkerställa att alla säkerhetskritiska funktioner fungerar på ett sätt som minimerar risken för skador på människor eller miljö. En av de viktigaste delarna i IEC 61508 är användningen av säkerhetsintegritetsnivåer (SIL), som används för att klassificera systemens säkerhetsgrad. SIL-definieringen innebär att olika system får en nivå mellan SIL 1 (minst strikt) och SIL 4 (mest strikt), beroende på hur kritiska deras funktioner är och hur ofta de används. System som är avsedda att operera kontinuerligt, eller som måste svara på säkerhetskritiska händelser snabbt, behöver ofta en högre SIL-nivå.
För att tillämpa IEC 61508 på ett effektivt sätt, krävs detaljerad planering och utveckling av system, där alla risker identifieras och hanteras genom hela systemets livscykel. Viktigt att förstå är att det inte bara handlar om att implementera tekniska lösningar, utan även om att skapa en säkerhetskultur där alla involverade parter är medvetna om risker och arbetar aktivt för att minimera dessa.
När det gäller programmering och mjukvaruutveckling är det också centralt att följa riktlinjer för säker utveckling av kod och algoritmer som påverkar systemets säkerhet. IEC 61508 rekommenderar användning av metoder och verktyg som säkerställer att mjukvaran inte innehåller några dolda fel som kan leda till farliga situationer.
ISO 26262 är en standard som är specifikt anpassad för fordonsindustrin och kan betraktas som en specialisering av IEC 61508 för automotive tillämpningar. Den ersätter begreppet SIL med ASIL (Automotive Safety Integrity Levels), som används för att definiera säkerhetsnivåer för fordonskomponenter och system. Även här används en skala från ASIL A (lägre risk) till ASIL D (högsta risk), beroende på hur allvarlig en möjlig systemfel kan vara, och hur ofta systemet kan förväntas aktiveras under normala omständigheter.
För att bestämma säkerhetsnivåerna för ett fordonssystem, genomförs en detaljerad riskbedömning där potentiella risker för både passagerare och förare analyseras. Det innefattar att identifiera vilka typer av skador som kan uppstå vid ett systemfel (t.ex. allvarliga skador som benbrott eller dödsfall) samt att uppskatta sannolikheten för att dessa skador inträffar under normala driftförhållanden.
För att säkerställa korrekt tillämpning av ISO 26262 eller IEC 61508 är det viktigt att tillämpa formella metoder för systemdesign och programvaruutveckling, inklusive simuleringar och testning, för att förutsäga systemets beteende under extrema förhållanden. Vidare ska systemdesignen omfatta redundans och fail-safe mekanismer, för att kunna hantera eventuella fel utan att skapa farliga situationer.
En viktig aspekt av dessa standarder är att de inte bara gäller för nyutvecklade system, utan även för system som redan är i drift. Genom att regelbundet genomföra riskbedömningar och systematiska analyser av säkerhetsåtgärder, kan företag se till att även äldre system fortsätter att uppfylla säkerhetskraven, vilket kan innebära att de måste uppgradera vissa komponenter eller system för att säkerställa att de fortsätter att vara funktionellt säkra.
När det gäller att tillämpa dessa säkerhetsstandarder i praktiken, är det också avgörande att ha en systematisk process för att hantera och dokumentera alla säkerhetsrelaterade beslut och åtgärder. Detta kan innefatta att skapa säkerhetsrapporter, protokoll och riskhanteringsplaner som gör det möjligt att följa och utvärdera säkerhetsarbetet genom hela systemets livscykel.
Det är också viktigt att poängtera att även om IEC 61508 och ISO 26262 tillhandahåller detaljerade riktlinjer för att uppnå säkerhet i tekniska system, finns det alltid en inneboende osäkerhet i alla tekniska lösningar. Därför måste säkerhetsprocesserna ständigt uppdateras och förbättras, särskilt i takt med att ny teknik och nya metoder utvecklas.
Hur kan systemdesign förbättras genom redundans och diversifiering?
För att öka tillförlitligheten och tillgängligheten i ett system kan olika typer av replikering användas, såsom aktiv-passiv replikering, där ett "kallt standby"-system väntar på att ta över om det aktiva systemet misslyckas. Det är vanligt att man använder ett selector-system, som har till uppgift att byta från det aktiva till det passiva systemet vid ett misslyckande. Detta ger en högre tillförlitlighet än system utan replikering, men medför också vissa utmaningar som måste beaktas för att systemet ska vara stabilt och effektivt.
I en replikationslösning som innebär att data och processer dupliceras, behöver ofta en form av statstransfer implementeras. Om systemet lagrar tillstånd (state) måste det säkerställas att detta tillstånd synkroniseras korrekt mellan de olika systemen för att undvika att det ena systemet opererar med föråldrad eller felaktig information. En annan viktig aspekt av att upprätthålla tillförlitligheten är synkronisering, särskilt när flera subsystem är inblandade. Detta kan kräva samordning av replikeringen för att säkerställa att alla delar av systemet är i synk med varandra och att det inte uppstår konflikt mellan olika instanser.
För system som använder kall standby (cold standby) kan det vara komplicerat att detektera ett misslyckande i det aktiva systemet. Vid ett fel är det avgörande att ett selector-system snabbt kan känna av att det aktiva systemet har misslyckats och övergå till standby-systemet utan avbrott i tjänsten. Detta innebär att systemet behöver kunna detektera och reagera på en bred variation av potentiella problem, inklusive hårdvarufel, programvarufel eller externa störningar.
Vidare kan selektor-systemet själv vara en potentiell svag länk i hela kedjan. Om selektorn misslyckas kan hela replikationssystemet bli utsatt för risk. Därför måste även selektorn vara redundanta och robusta, särskilt i komplexa system där många olika komponenter samverkar.
Ett intressant sätt att förbättra redundans och tillförlitlighet är genom diversifiering, både på hårdvaru- och mjukvarunivå. Hårdvarudiversifiering innebär att subsystemen i ett system körs på olika hårdvaruplattformar eller på olika processormodeller. Detta gör systemet mindre känsligt för enskilda komponenters fel eller avvikelser. Mjukvarudiversifiering innebär att olika versioner av samma programvara används för att undvika att fel i en specifik kodversion påverkar hela systemet. Detta kan exempelvis innebära att olika kompilatorer används eller att olika kodalgoritmer implementeras för att lösa samma problem.
Mjukvarudiversifiering kan också inkludera användning av "kodade processorer" där olika processorer kör olika programkod för att förhindra att ett fel i en processor sprider sig till hela systemet. Detta gör systemet mer robust mot fel i enskilda processorer, vilket är särskilt viktigt i miljöer där kritisk data behandlas.
För att säkerställa systemets långsiktiga pålitlighet är det också viktigt att överväga möjliga fenomen som kan påverka systemets drift, såsom Heisenbugs, som är oförutsägbara fel orsakade av små förändringar i miljön, som temperatur eller elektromagnetisk interferens. Dessa problem är ofta svåra att upptäcka och åtgärda, men genom att använda olika typer av redundans och diversifiering kan man minska risken för att de påverkar systemets drift negativt.
Ett exempel på ett säkerhetslager mot dessa problem är användningen av felkorrigerande minne (ECC), som kan upptäcka och korrigera fel i minnesmoduler, men även här är det viktigt att förstå att inga lösningar är helt immuna mot alla typer av fel.
Att implementera redundans och diversifiering innebär en balans mellan kostnader, prestanda och tillförlitlighet. För att verkligen optimera systemets pålitlighet behöver alla nivåer av systemdesign beaktas, från hårdvara till mjukvara och från externa faktorer som elektromagnetiska störningar till interna faktorer som selektorers funktion.
Hur upptäcker vi avvikelser vid systemtestning?
Systemtestning genererar en enorm mängd data, särskilt när man samlar spår av händelser. Denna data kan ge insikter om hur systemet beter sig under olika förhållanden, men den största utmaningen är att korrekt tolka dessa data för att upptäcka avvikelser. Vanligtvis är ett system så pass komplext att även små förändringar i dess beteende kan vara tecken på underliggande problem.
Avvikelser i systemtestning kan vara svåra att identifiera utan en tydlig förståelse för systemets normala beteende. Detta innebär att det är viktigt att ha definierade beteendemodeller för systemet. Genom att analysera systemets svar på olika stimuli kan man skapa en referenspunkt för vad som anses vara "normalt". Det är först när beteendet avviker från denna norm som det kan betraktas som en avvikelse.
I vissa fall är systemet designat för att kunna hantera förändringar och anpassa sig. Detta kan göra det svårare att upptäcka avvikelser, eftersom vad som kan verka vara en förändring i systemets beteende egentligen kan vara en önskad och inbyggd funktion. Till exempel kan vissa system vara konfigurerade att dynamiskt justera sina processer baserat på externa faktorer som belastning eller användarbeteende. Därför krävs det en noggrann granskning av både systemets design och hur det faktiskt presterar i realtid.
Ett annat viktigt verktyg vid upptäckt av avvikelser är användning av ISO 29119, som är en internationell standard för programvarutestning. Denna standard rekommenderar en systematisk ansats för att verifiera att krav och specifikationer är korrekta. Även om detta kan verka som en strikt metod, är det ibland nödvändigt för att hantera komplexiteten i stora system. ISO 29119 understryker vikten av att säkerställa att de testade systemkraven är både fullständiga och realistiska.
I praktiken innebär kravbaserad testning att man identifierar vilka funktioner som är mest kritiska för systemet, och prioriterar testningen därefter. Genom att använda riskbaserade metoder kan man säkerställa att de mest kritiska delarna av systemet testas först, vilket minskar risken för att missade fel får stora konsekvenser.
Men även om en grundlig testning kan minimera risker, går det inte att garantera att alla potentiella avvikelser fångas upp. De största riskerna för att förbises avvikelser ligger ofta i de mänskliga faktorerna. Systemdesigners och testare gör ibland antaganden om hur systemet kommer att reagera i specifika situationer, och dessa antaganden kan vara felaktiga. Mänsklig felbedömning, bristande förståelse av användarinteraktion eller brist på tillräcklig testdata är alla faktorer som kan bidra till att en avvikelse missas.
Vid systemtestning är det därför av yttersta vikt att se till att testdata inte bara speglar teoretiska användarscenarier, utan också täcker en bred variation av praktiska situationer där systemet kan behöva agera under extrema förhållanden. Testare måste vara medvetna om att verkliga användare ofta inte följer de förutbestämda vägarna i systemet, vilket kan skapa nya och oväntade problem.
För att effektivt upptäcka avvikelser är det också viktigt att ha ett robust system för realtidsövervakning och analys. Medan manuella tester kan ge en viss insikt, är det genom automatiserade system och övervakning som man kan få en mer komplett bild av systemets beteende under hela testperioden. Detta gör det möjligt att omedelbart fånga upp avvikelser som kan ha gått obemärkt förbi vid en enkel visuell inspektion eller ett punktförtest.
Slutligen, medan tekniska och metodologiska förbättringar är avgörande, måste testare och utvecklare också ha en kultur som uppmuntrar till öppenhet och lärande. Det är när en avvikelse inträffar som möjligheten att lära sig och förbättra systemen verkligen manifesteras. Det handlar inte bara om att fixa fel, utan också om att förstå varför de inträffade och hur man kan förhindra att liknande problem uppstår i framtiden.

Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский