Biztonsági szempontok
A biztonság szempontjából kritikus rendszereknek rendelkezniük kell olyan mechanizmusokkal, amik detektálják, lokalizálják és megfelelő módon kijavítják az üzemzavarokat. Abban az esetben, ha egy hardver vagy szoftver nem tudja ellátni a funkcióját, az adott elemet izolálni kell, elkerülendő a hiba tovagyűrűzését a többi rendszerre. Számos reakció elképzelhető ezekben az esetekben, még menet közben is. Jelenleg az automatizált rendszerekben általában lehetséges egy „biztonsági üzemmód (safe state)” elérése a hibás rész leállításával a probléma észlelésekor. Például, ha a fékszenzorok működésében hiba lép fel, akkor az kezelhető a fékerővel megfelelő adagolásán kívül a kerekek pozíciójának figyelembevételével, esetlegesen módosításával a csúszás elkerülése végett. Tehát egy mechanikus, sokkal közvetlenebb jellegű intervenció történik a fékezés közben. Habár hatalmas előrelépések zajlanak az automatizált vezetési funkciókban, a kritikus elemeknek folyamatosan el kell látniuk a feladatukat. Az előző példánál maradva; a fékrendszer egyes komponensének hibája esetén a teljes fékrendszer nem kapcsolható ki, így a probléma sem izolálható rendesen. Az ilyen rendszereket nevezik üzemzavaros helyett „fail-operational”-nek (hiba esetén is tovább működőnek), mivel zavarosan is üzemben maradnak és maradéktalanul el kell látniuk így vagy úgy a funkciójukat a hiba ellenére is.
Biztonság-kritikus rendszerek
A mérnöki biztonság-kritikus rendszereknél ezért megkülönböztetünk funkcionális biztonságot (functional safety, ISO 26262) és biztosított célt (safety of the intended functionality, SOTIF, ISO PAS 21448). A funkcionális biztonság azt jelenti, hogy nincs emberi hibából fakadó veszély. Az ISO 26262 első része szerint, a funkcionális biztonság arra utal, hogy nem származik biztonsági kockázat üzemzavar esetén. Másszóval teljeskörű a biztonság akármilyen üzemzavar esetén is. Ezek a hibák úgy vannak definiálva, hogy „a rendszer egyik eleme elvesztette azt a képességét, amivel ellátta a kijelölt funkcióját”. Ebben a kategóriába kétféle hiba elképzelhető: váratlan hibák (random failures) és szisztematikus hibák (systematic failures).
Váratlan hibák
Váratlan hibák kiszámíthatatlanul felléphetnek a hardver teljes élettartama alatt, illet azok előfordulása statisztikailag egyenletes eloszlást mutat. Ezzel szemben a szisztematikus hibák eredője, elémletben, biztosan behatárolható. Ilyen ok lehet a fejlesztés és használat közben fellépő emberi hiba. Ezek szintén jelentkezhetnek a rendszer teljes élettartama alatt, ideértve a specifikációt, tervezést, gyártást, használatot, karbantartást és leszerelést is. Miután egy szisztematikus hiba „elkészül”, a megfigyelhető üzemzavar mindig jelentkezni fog, amikor az azt előidéző körülmények fellépnek, egészen addig, amíg a hibát ki nem javítják. Hogy a szisztematikus hiba előfordulása hogyan befolyásolja a biztonságot vagy a működést, azt nagyon nehéz kiszámítani. Ez abból következik, hogy (1) nehéz kideríteni pontosan mely körülmények esetén jelentkezik a hiba és (2) az adott körülmények közötti egyedi viselkedést tulajdonképpen mi is okozza.
Hardverhibák
Egyszerű hardverhibák váratlanul jelentkeznek, míg a rendszerszintűek kiszámíthatóbbak. Viszont az lehetséges, hogy egy szisztematikus hiba egy hardveres probléma formájában manifesztálódik; a hardverek komplexitásából fakadóan egy szisztematikus hiba több hardver működésére is kihathat, tehát lehetséges, hogy más-más természetű hardveres üzemzavart okoz ugyanazon rendszerhiba. Tehát a két kategória ilyen szempontból összetéveszthető. A növekvő interdependencia enyhítésére szolgálnak az alkalmazás-specifikus integrált áramkörök (application-specific integrated circuits, ASICS). Sőt, minden szoftveres hiba tulajdonképpen rendszerszintű, és a rengeteg, összetett fedélzeti elektronika miatt a hibák előfordulásának kockázata is sokat nőt az utóbbi évtizedekben. A váratlan hibákkal ellentétben, a szisztematikus hibák elfordulását (statisztikai eloszlását) nem lehet megjósolni (kiszámítani). Amit tenni lehet az az, hogy a jelentkező kockázatra, veszélyre előre felkészülünk. E célból az ISO 26262 konkrét fejlesztési procedúrákat javasol (process-based). Lehetséges még úgynevezett konstruktív módszerek (például hiba-toleráns rendszerek vagy szoftver architektúrák) vagy analitikai megközelítések (statikus és dinamikus verifikációk) alkalmazása is a minőségbiztosításban.