3. Biztonságkritikus rendszerek Ebben a fejezetben az informatikai rendszerek azon csoportjával – a biztonságkritikus rendszerekkel – foglakozunk, ahol kiemelt jelentősége van a biztonságnak. A legnagyobb mértékben itt jelentkezik a fejlesztési és tesztelési eljárások esetén a szigorú szabályozás. A biztonságkritikus rendszerek kategóriájába tartozó szoftverekre vonatkozó előírások nem mindegyike vonatkozik a nem biztonságkritikus szoftverekre, viszont a biztonságkritikus alapelvek figyelembe vétele a nem biztonságkritikus szoftverek minőségi javulását eredményezheti.
3.1. Alapfogalmak, követelmények A biztonságkritikus rendszerek olyan informatikai rendszerek, amelyek azzal az elsődleges követelménnyel üzemeltethetők, hogy ne veszélyeztessenek emberi életet, egészséget, ne okozzanak gazdasági vagy környezeti károkat. Példák biztonságkritikus rendszerekre:
közlekedés (szárazföldi, vízi, légi) irányítása, vezérlése,
egészségügyi informatika rendszerek,
hadászatban használt informatikai rendszerek,
gazdasági folyamatokat kezelő rendszerek (bankok, tőzsde).
Az említett példákban jól látható, hogy az adott informatikai rendszer hibás működése esetén milyen jellegű károk jelentkezhetnek. Az első három pontban (közlekedés, egészségügy, hadászat) az emberi élet veszélyeztetésének, illetve például a környezeti károk kockázata merülhet fel, míg a gazdasági folyamatok esetén a gazdásági károk kockázata. A példákban is említett informatikai rendszerek esetén azonban nem elégséges, hogy az informatikai rendszer biztonságkritikus módon működjön. Az ilyen rendszerek esetén alapvetően elvárt tulajdonság a megbízhatóság, a folyamatos működés is. A megfelelő megbízhatósági szint eléréséhez hibatűrő rendszerek alkalmazására van szükség. A hibatűrő rendszerek olyan informatikai rendszerek, amelyek képesek elvégezni, ill. tovább folytatni előírt feladatainak helyes végrehajtását a hardver meghibásodásakor, illetve szoftver-hibák esetén is. A hibatűrés nem jelenti azonban azt, hogy az informatikai rendszer ugyanazzal a képességgel, illetve teljesítménnyel működik a különböző (hardver, szoftver hibák) esetén is, csupán azt, hogy a működése nem áll le. Előfordulhat persze, hogy a teljesítménye lecsökken, esetleg nem mindegyik funkcióját képes ellátni, viszont az alapvető feladatait még végre tudja hajtani. A hibatűrő rendszerek tervezésekor olyan tervezési célokat kell elérni, amelyek előre megadott követelmények teljesítését célozzák meg. 10
Minőségi és megbízhatósági követelmények Megbízhatóság (Reliability): Annak a feltételes valószínűsége, hogy a rendszer hibátlanul működik a [t1, t2] időintervallumban, feltéve, hogy a t ≤ t1 időpontban hibátlanul működött. A megbízhatósági érték tehát annak a valószínűségét fejezi ki, hogy a rendszer a [t1, t2] időintervallumban végig hibátlanul működik. Ez az érték az intervallum hosszának a növekedésével nyilvánvalóan csökken, hiszen a hosszabb intervallum működési feltételének a teljesülése nyílván magában tartalmazza a rövidebb intervallumra vonatkozó működési teljesülést. Ezt a paramétert elsősorban olyan rendszerek jellemzésére használják, ahol egy rövid időre sincs megengedve a hibás működés, vagy pedig nincs mód a javításra. Például egy repülőgép esetén a megbízhatóságra vonatkozó működési idő a repülési idő, illetve egy nem javítható űrszondánál a működési idő többéves nagyságrendű is lehet. A megbízhatóság és a hibatűrés nem ugyanazt jelenti. A hibatűrés olyan technika, amely javítja a megbízhatóságot, de ettől még nem biztos, hogy valóban magas lesz a megbízhatóság. Ha egy rendszer ki tud védeni hardver hibákat, de azok nagy gyakorisággal jelentkeznek, akkor megbízhatóság értéke még alacsony is lehet. Másrészről pedig, ha egy nagy megbízhatóságú rendszerbe nincs beépítve hibatűrés, akkor az első hiba fellépésétől kezdve rosszul fog működni Rendelkezésre állás (Availability): Annak a valószínűsége, hogy a rendszer helyesen működik a t időpontban, vagyis a t időpontban rendelkezésre áll. A megbízhatóság és a rendelkezésre állás között az a lényeges különbség, hogy az előbbi egy időintervallumban az eszköz működésének folyamatos helyességet fejezi ki, míg az utóbbi csak azt, hogy a egy időpillanatban legyen a működés helyes. Az rendelkezésre állás mérőszáma azért fontos, mert az informatikai rendszert nem állandóan használják egy feladatra, hanem gyakori megszakításokkal és ilyen esetekben megnövekszik a közbenső karbantartás és javítás szerepe, amely a rendelkezésre állás magas szinten tartását szolgálja. Biztonságosság (Safety): Annak a valószínűsége, hogy a rendszer helyesen vagy hibásan működik egy adott időpillanatban, de oly módon, hogy nem veszélyeztet emberi életet, nem okoz anyagi vagy környezeti kárt, és nem befolyásolja károsan más rendszerek működését, azaz annak valószínűsége, hogy a rendszer az adott időpillanatban biztonságosan működik. A biztonságosság igen szorosan összefügg a hibatűréssel. Például ha egy informatikai rendszerben valamilyen meghibásodás lép fel, aminek következtében már nem lesz képes a rendszer az előírt funkcióit ellátni. Ebben az esetben a biztonságosság fenntartása úgy oldható meg, hogy a rendszer olyan sorrendben hagy fel, egymás után, a funkciók ellátásával, ami a katasztrófa elkerülését teszi lehetővé. Ez a fokozatos leépülés (graceful degradation) módszere. A fokozatos leépülés egy rendszer azon képessége, hogy automatikusan képes csökkenteni teljesítőképességét, a hardver- és szoftver-hibák biztonságosságra vonatkozó hatásának ellensúlyozására. További lehetséges vészmegoldási módszer, hogy a rendszer utolsó intézkedéseként mindent úgy állít le, hogy a katasztrófa semmiképpen ne tudjon bekövetkezni. Például egy közlekedésirányítási rendszer olyan utasításokat ad, hogy semmilyen jármű 11
sem mozoghat, vagy egy közlekedési jelzőlámpa vezérlő rendszer minden irányban a villogó sárga jelzést állítja be. Teljesítőképesség (Performability): Annak a valószínűsége, hogy a rendszer teljesítőképessége egy adott időpillanatban eléri vagy meghaladja a megadott szintet. A teljesítőképesség azt fejezi ki, hogy a hiba esetén milyen csökkent szinten képes még a rendszer megfelelően működni. A korábban említett fokozatos leépülés megvalósítása nem más, mint a teljesítőképesség előre megtervezett módon való fokozatos csökkentése, a biztonság fenntartása érdekében. Karbantarthatóság (Maintainability): Annak a valószínűsége, hogy a meghibásodott rendszer újra működőképessé tehető egy bizonyos időtartam alatt, beleértve a hiba helyének meghatározását, a fizikai javítást, a csere esetleges elvégzését, illetve az újraindítást. A karbantarthatóság magas szinten tartása feltétlenül megköveteli a rendszer beépített öntesztelését (built-in self-testing, BIST), valamint az automatizált diagnózis elvégzését, amely a hiba helyének meghatározására irányul. A tesztelési és hibakeresési feladatok végrehajtásához külön hardver és/vagy szoftver egységek felhasználására lehet szükség, amelyek a hibatűrő rendszer részét képezik. A hibatűrésre vonatkozóan négy fő alkalmazási területet különböztethetünk meg: 1. Hosszú élettartamú alkalmazások: Az ide tartozó rendszerek rendszerint több éves időtartamban működnek, általában a javításra kevés lehetőséggel. Például: Ember nélküli repülés, űrrepülés, műholdak, űrszondák. Egy-egy űrszonda akár tíz éven túl is teljesíti küldetését, amikor távoli bolygók közelébe kell jutnia, a megbízhatósági értékének 95% felett kell lenni. Az űrszondákon a biztonságos működés elérése érdekében mindegyik egységnek, blokknak van másodlagos tartaléka. Ez nemcsak az informatikai egységekre, hanem a különböző navigációs, távmérő, rádiós, stb. blokkokra is fennáll. 2. Kritikus számítások: Ez a felhasználási terület az előbbinek az ellenkezője. A hibatűrés szempontjából itt az a fontos, hogy a viszonylag rövid működési időtartam alatt, amíg egy kritikus működési, számítási szakaszban üzemel a rendszer, a megbízhatósága garantáltan magas legyen. Például: Repülőgépeknél, űreszközöknél a felszállás és a leszállás legkritikusabb ideje alatt nem szabad hibának történnie. Vegyi üzemek vezérlő rendszereiben kiemelt fontosságú lehet egy-egy kritikus munkafolyamat esetén a helyes működés. 3. Elhalasztott karbantartás: Ebben a felhasználási területben olyan esetekről van szó, ahol a karbantartási műveleteket igen nehéz, vagy igen költséges elvégezni. Például a távoli helyeken üzemeltetett feldolgozó állomások, vagy az űrbeli alkalmazások. Egy-egy ilyen rendszer karbantartása egy későbbi, megfelelő időpontban történik meg, és a két karbantartási procedúra között kiemelten szükséges a hibatűrő működés. 4. Magas szintű rendelkezésre állás: Ez a terület a változó mértékben igénybe vett rendszerekre vonatkozik. Ide sorolhatók például az on-line tranzakció-feldolgozást végző rendszerek (banki alkalmazások), ahol a felhasználói igények véletlenszerűen jelentkeznek, és ezekre azonnali reagálás (feldolgozás, kiszolgálás) a követelmény. 12
3.2. Redundancia megoldások (hardver, szoftver) Annak érdekében, hogy a hibatűrő informatikai rendszer a normál funkcióikon kívül a saját hibás működés felismerésére és az ilyenkor megvalósítandó feladatokra is képesek legyenek, a hibatűrés megvalósítása mindenképpen előre betervezett redundanciával kell, hogy történjen. A redundancia jelen lehet mind a hardverben, mindpedig a szoftverben is. Azonban egyedül egyik fő komponens sem képes a másik hibáját felismerni és funkcióját ellátni. Természetesen a szoftver és a hardver egymással összhangban üzemel, amibe az is beletartozik, hogy a hibafelismerésben és az ilyenkor szükséges feladatokban is kiegészítik, vagy átfedik egymás tevékenységét. A hibatűrő rendszerek felépítése sok esetben olyan, hogy a hardver is hozzájárul a szoftver-hibák felismeréséhez, és viszont, a szoftver is részt vehet a hardver-hibák észlelésében. A redundancia megvalósítására négy terület vált alkalmassá. 1. Hardver redundancia: A hibatűrés elérése érdekében kiegészítő hardver elemeket alkalmaznak, különböző funkciókkal. A funkciók egyrészt a működéshez kapcsolódó tesztelést (beépített öntesztelést), másrészt pedig egyes elemek ismétlését (tartalékként) jelentik általában. 2. Szoftver redundancia: A hibatűrés elérése érdekében kiegészítő szoftverelemeket, ill. szoftverrel megvalósított módszereket alkalmaznak. Itt is számításba kell vennünk a szoftvert az öntesztelés megvalósításában, valamint az ismétlődő funkciók ellátásában. 3. Információs redundancia: A működési biztonság növelése érdekében többletinformációt, többletbiteket használnak fel. Ezáltal a hibák detektálására és javítására kerülhet sor. Ilyen elterjedt megoldások például a paritásbitek, hibadetektáló kódok, hibajavító kódok, ellenőrzőösszegek használata. A hibajavító kódok nemcsak detektálásra, hanem javításra, vagyis a hiba elfedésére, hatásának megszüntetésére is alkalmasak. Az ilyen megoldások a kommunikációs folyamatokban, továbbá a memóriákban, illetve a központi feldolgozó egységekben (CPU) terjedtek el elsősorban. Megvalósításuk egyaránt történhet hardveres és szoftveres úton is. 4. Idő redundancia: A szükségesnél hosszabb feldolgozási idő igénybevétele. A cél itt is a hibák detektálása és javítása. A legelterjedtebb megoldás a feldolgozás, a számítások ismételt lefolytatása, az eredmények összehasonlításával egybekötve. Ezzel elérhető az, hogy a rendszerben fellépő átmeneti hibát, amely az egyik végrehajtás alatt érvényesült, egy újabb végrehajtással ki lehessen küszöbölni. Az időtöbblet tehát így a hiba detektálását és javítását is lehetővé teszi. A megvalósítás egyaránt történhet hardverrel és szoftverrel is. A gyakorlatban a fenti négy elv kombinációját alkalmazzák. Igen sok esetben mind a négy redundanciát beépítik a biztonságkritikus rendszerekbe.
13
A hardver redundancia megvalósítása A következőkben három jellegzetes megoldást ismertetünk a hardver redundancia megvalósítására: a párhuzamos duplikálást, a tartalékelemes üzemeltetést és a hárommodulos redundanciát.
Párhuzamos duplikálás A párhuzamos duplikálás az egyik legrégebbi megoldás az a kézenfekvő struktúra ugyanazon hardver egységnek a megkettőzése és párhuzamos működtetése. Ebben az esetben mindkét egység ugyanazokat a bemenő jeleket kapja, és helyes működés esetén ugyanazokat az eredményeket is kell produkálniuk. Az eredmények megfigyelése és összevetése egy külön beiktatott összehasonlító egység feladata. Abban az esetben, ha a két modul eredménye egyezik, akkor az egyik egység jelei jutnak tovább a feldolgozási folyamatban. Abban az esetben viszont, ha a két eredmény nem egyezik, akkor az az egyik egység hibás működését jelenti. A párhuzamos duplikálás struktúrája tehát a hibát csak detektálni tudja, annak javítását viszont nem képes megoldani. Ilyenkor célszerű megoldás lehet a további működés biztonságot nem sértő leállítása. A párhuzamos duplikálás struktúrája a 3.1. ábrán látható. A duplikált egységek bármilyen bonyolultságú modulok lehetnek, tetszőleges számú különböző típusú egységpárost lehet egy rendszeren belül kialakítani, például aritmetikai logikai egységet, vagy háttértárolókat, hálózati összeköttetést. A legmagasabb szintű megoldás az, amikor egy teljes számítógép megkettőzése valósul meg.
Tartalékelemes üzemeltetés A tartalékelemes üzemeltetés struktúrájában is két azonos egység vesz részt, de csak az egyik, a normál egység végez üzemszerű tevékenységet, a másik tartalékként szerepel (3.2. ábra). Azt, hogy melyik egység jelei jutnak a kimenetre, az átkapcsoló modul intézi el, a hibadetektor modul utasítása alapján. A hibadetektor rendelkezik azzal a képességgel, hogy meg tudja állapítani a helyes-hibás működést az általa ellenőrzött modulról. Ha a normál modult hibásnak ítéli, akkor a tartalékmodul használatára kerül sor. Ha az is meghibásodna, a működést felfüggesztheti, akár oly módon, hogy az a további működés biztonságát nem befolyásolja. A tartalékmodult kétféle állapotban használhatjuk a normál üzemelés folyamán. Az egyikben nincs bekapcsolva (hideg tartalék), a másikban állandóan be van kapcsolva, és működést fejt ki (meleg tartalék). A hideg tartalék alkalmazása egyrészt energia-takarékossági okokból, másrészt pedig az élettartam meghosszabbítása érdekében célszerű.
14
Hárommodulos redundancia (TMR) A párhuzamos duplikálás és tartalékelemes üzemeltetés struktúrájában láthattuk, hogy a hibatűrés megvalósítására nem elegendő két egység. A cél elérése legalább három egység beiktatását igényli. Egy ilyen struktúra, a hárommodulos redundancia (Triple Modular Redundancy, TMR.) látható a 3.3. ábrán. A TMR-struktúrában a három megismételt modul kimenetei egy úgynevezett szavazóegységre (voting unit) kerülnek, amely a többségi szavazás elvén működik. Ez azt jelenti, hogy a kimenetre az a jel megy tovább, amely legalább két modulnál azonos. Ha tehát egy modul meghibásodik, akkor a másik kettő azonosan működése érvényesül (függetlenül attól, hogy az helyes vagy azonosan helytelen). A TMR struktúra tehát képes egyrészt a hibás modul hibáját detektálni, mivel az megállapítható, hogy melyik tért el a másik kettőtől, másrészt pedig javítani is képes azt, mivel a hiba hatása nem jut érvényre a teljes működésben, feltéve persze, hogy csak egy modul hibázik. Ha két vagy három modul hibásodna meg, akkor várhatóan három különböző jel jutna a szavazóra, amely ilyenkor detektálná a hibás működést, aminek alapján egy biztonságra törekvő leállítás, vagy tartalékegység beléptetése következhet. Feltételezzük persze, de nem zárhatjuk azonban ki, hogy a modulok hibás működése nem eredményez azonosan helytelen kimenete. Ennek a valószínűsége azonban elhanyagolhatóan csekély.
15
A TMR struktúra egyetlen hibás modul esetén alkalmas a hibajavításra. Az eltűrt hibás modulok száma úgy növelhető, hogy növeljük a párhuzamosan dolgozó modulok számát, de mindig úgy, hogy ez a szám páratlan legyen a többségi szavazással összhangban. Ekkor ugyanis a szavazásnál nem fordulhat elő “holtverseny”. Ha egy rendszerben N db modult használunk (n ≥ 3), akkor a többségi szavazáson alapuló redundancia (n – 1) / 2 db modul hibás működését képes tolerálni. Ez a szám öt modulnál kettő, hét modulnál három. A modulok számának növelése egyrészt nem jár arányosan egyértelmű javulással, mivel a meghibásodások valószínűsége is növekszik, másrészt viszont az (n – 1) / 2 db modul együttes meghibásodásának a valószínűsége nagyobb n esetén jóval kisebb. A gyakorlatban alkalmazott informatikai rendszerekben a többmodulos redundancia esetén, a gazdaságossági szempontokat is figyelembe véve, a hárommodulos TMR konstrukció terjedt el és vált be leginkább.
A szoftver redundancia megvalósítása Egy rendszer hibatűrő képességét szeretnénk a legmagasabb szinten tartani. Ez nem csupán a hardver hibák, hanem a szoftver hibák kezelését is megköveteli. Ez nyílván plusz szoftvert, vagy esetleg szoftverkomponenst igényel. Ugyanakkor a hardverhibák menedzselése is többlet-szoftver alkalmazásokat igényelhet. Informatikai rendszerek hibatűrésének szoftveres kezelése két céllal valósulhat meg. Egyrészt a rendszer szoftver komponenseire vonatkozó hibák detektálása, illetve korrigálása céljából, másrészt a szoftver hibák mellett a hardver hibáinak a kezelése céljából is. A második eset magában foglalja az elsőt is, ezért követendő megoldásként ezt érdemes használni.
A hardveres párhuzamos duplikálás struktúrájából kiindulva vizsgáljuk meg azt a lehetőséget, amelyben a hardver megkettőzése szerepel (3.4. ábra). Tegyük fel, hogy mindkét csatornában ugyanazt a szoftvert telepítettük, és a csatornák CPU-ja is megegyezik, vagyis SW1 ≡ SW2, valamint CPU1 ≡ CPU2.
16
Ebben az esetben a szoftverben előforduló hibák detektálására semmilyen további lehetőség nincs, mivel mindkét csatorna azonosan működik, függetlenül attól, hogy az eredmény helyes vagy helytelen. Így viszont az összehasonlító helyes működésnek érzékeli a hibás, de azonos kimeneteket is. A hárommodulos redundanciát alkalmazó rendszerben sem lesz jobb a helyzet. Ha a szoftverkomponens hibás az egyik ágon, helytelen eredményt fog adni a másik ágon is. Szoftveres hibák felderítését csak úgy végezhetjük el, ha nem ugyanazt a szoftvert használjuk, azaz a különböző csatornák szoftverje nem lesz azonos, viszont ugyanazt a működést kell végezniük. Ezt az elvet szoftver diverzitásnak nevezzük. A következőkben két olyan megoldást mutatunk be, amely a szoftver hibatűrést szolgálja a szoftver diverzitási elv érvényesítésével.
N-verziós programozás Az N-verziós programozásban a teljes szoftvert több (N) db példányban készítjük el. Feltételezzük, hogy a különböző verziókban a bennük lévő hibák is különböznek és elenyészően kicsi annak a valószínűsége, hogy ugyanaz a hiba több verzióban is előforduljon. Ennek a célnak az elérése érdekében célszerű, ha egymástól független, különböző fejlesztő csoportok készítik el a különböző. Természetesen sokkal praktikusabb, ha az egymástól független, különböző fejlesztő csoportok eltérő programozási nyelveket alkalmazva oldják meg a programozási feladatukat. A fejlesztő csoportok ugyanazt a specifikációt valósítják meg. Eltérő nyelvek esetén az egymástól való függetlenségük azt a célt szolgálja, hogy nehogy ugyanazokat a hibákat kövessék el és vigyék bele a szoftverbe. Az N-verziós programozást használó rendszer a következők szerint működik: 1. Az N program ugyanazt a bemenetet használva lefut és szolgáltatja a kimenetet. Ez a számítógépes szervezéstől függően történhet akár párhuzamosan, akár sorosan is. Párhuzamos 17
esetben mindegyik programhoz egy dedikált CPU-t használunk, azaz N db CPU vesz részt a feldolgozásban. Soros esetben viszont csak egyetlen CPU végzi el a különböző programverziók végrehajtását egymás után. Természetesen, ha N-nél kevesebb (de 1-nél több) CPU áll rendelkezésre, akkor bizonyos programverziók párhuzamosan, bizonyosak pedig sorosan futhatnak. Így kombinálhatjuk a párhuzamos és a soros megoldást is. 2. Egy erre a célra készített összehasonlító program elvégzi az N db programverzió kimeneteinek az összehasonlítását. N = 2 esetén csak a hibadetektálás ténye derül ki. A hibás szoftver-komponensre, vagy a hibás hardverre nem tudunk következtetni, az összehasonlító program csupán két különböző kimenetet lát, nem tudja eldönteni melyik a helyes és melyik a helytelen. Hatékonyabb megoldást érhetünk el az N = 3 esetén, ahol mód nyílik a hárommodulos redundanciánál megismert többségi szavazás alkalmazására, egy a szavazást megvalósító programkomponens segítségével. Ez a megoldás lehetővé teszi a hibás szoftver meghatározását, és hibájának eltűrését is. A számítógépes megoldás meglehetősen költséges, hiszen ugyanazt a szoftvert egyrészt többszörösen kell kifejleszteni, másrészt a végrehajtás szervezése is további költségeket jelent. Párhuzamos feldolgozás esetén több processzorra, soros feldolgozás esetén több időre van szükség, illetve a futási eredmények eltárolásáról és összehasonlításáról is külön kell gondoskodni.
A javító blokkok módszere A szoftverhibák kezelésének egy másik módszere az ún. javító blokkok (recovery blocks) alkalmazása. A javító blokkok módszere szerint a teljes szoftvert több modulra, komponensre bontják, és az egyes modulokat többverziós módon valósítják meg, majd a modulok önteszteléssel egybekötött újrafuttatásával érhetjük el a megfelelő színtű hibatűrést. Egy-egy modul azonos funkciójú verziói alkotnak egy blokkot. Mindegyik blokkhoz tartozik egy öntesztelést végző úgynevezett elfogadási teszt (acceptance test), ami egy külön program az esetleges hibás működés detektálására. A feldolgozásban a modulok egymás utáni futtatására kerül sor, ahol minden futást az elfogadási teszt végrehajtása követ. Ha egy modulverziót elfogad az elfogadási teszt, az adott blokk újabb programverziójának futtatására már nem kerül sor, a következő blokk első programverziójával folytatódik a végrehajtás. Ha egy modulverzió hibásnak bizonyul a teszt alapján, akkor a soron következő tartalékmodul futtatására kerül sor, a blokkon belül. Ha ez is hibás az elfogadási teszt szerint, újabb modulra kerül sor, mindaddig, amíg csak van futtatható modulverzió. A javítás (felépülés, recovery) elve akkor érvényesül egy blokkban, ha egy hibás modult egy jó modul futása követ. Ha egy blokkban mindegyik modulverzió hibásnak bizonyul, akkor a teljes futás véget ér, ekkor a hiba javítása ugyan nem, de annak detektálása megtörtént. A javító blokkok módszerének egy lényeges szervezési kérdése, hogy egy új blokk futtatása előtt mindig el kell menteni az addig előállt összes adatot egy független tárba. Ha hibát talál az ellenőrzés, az új programverzió futtatása ebből az elmentett állapotból kell hogy történjen.
18
Az elfogadási tesztek elkészítés nem egy egyszerű feladat, a programmodul és a működési környezet alapos ismeretét igényli. Az elfogadási tesztek készítésének néhány követendő irányelve a következő:
Annak ellenőrzése, hogy egy kiszámított érték az elfogadható normális fizikai tartományba esik-e (például, hőmérséklet vagy nyomás).
Nem történt 0-val való osztás.
Nem történt címtartományon kívüli címzés, a tömbdeklarációk figyelembevételével.
Egy-egy fontos számérték meghatározása alternatív algoritmussal is megtörténhet.
A javító blokkok módszerét előszeretettel használják az elosztott számítógépes rendszerekben is. Az ilyen rendszerekben több különböző számítógép (csomópont) vesz részt egy-egy feladat megoldásában, az erőforrások összehangolt, automatizált elosztásával. Ilyen szervezésben előfordulhat az is, hogy egy modul ismételt végrehajtására egy másik csomóponton kerül sor, ha az előző csomópont hibásnak bizonyult. Ezzel így nem csupán a szoftveres, hanem a hardveres hibák kezelését (detektálás, javítás) is el lehet végezni.
19
