A szerkesztő bizottság elnöke: HORVÁTH I M R E Szerkesztő: A N G Y A L LÁSZLÓ SZERKESZTŐ BIZOTTSÁG BHG
ORION
TERTA
Laczkó Endre Bernhardt Richárd Dr. Eisler Péter Dr. Gosztony Géza Honti Ottó Klug Miklós Tölgyest László
Jakubik Béla Csernoch János Froemel Károly Sass Károly Szabó Károly Szász Gerő
Bánsághi Pál Baján Tibor Benedek Elek Halmi Gábor Hutter Mihály
BHG O R I O N
MŰSZAKI KÖZLEMÉNYEK XXVIII. évfolyam
A hibatűrő rendszerek elvi kérdései BEVEZETÉS A mikroprocesszorok megjelenése és elterjedése ko r á b b a n elképzelhetetlen intelligenciájú és teljesít m é n y ű vezérlő egységek építését tette lehetővé. A mik roprocesszorok nagy bonyolultságú, igen összetett rendszerek vezérlésére is alkalmasak, ezáltal mind technológiailag, mind gazdaságilag elérhetővé vált nagy megbízhatóságú, h i b a t ű r ő rendszerek építése, ami új t á v l a t o k a t n y i t a híradástechnikában. Egyes területeken m á r ma is elsődleges szempont a hiba mentes m ű k ö d é s . Természetes, hogy a különböző felhasználási terü leteken a nagyobb megbízhatóság különböző igénye ket t á m a s z t a berendezésekkel szemben. Az alábbiak ban azokról a szempontokról lesz szó, amelyek bár mely felhasználási területen hasznosíthatók. Ezzel elérkeztünk ahhoz a nagyon fontos kérdés hez, hogy lehet-e — s ha igen, hogyan — meghibásodható elemekből h i b á t l a n u l m ű k ö d ő rendszert lét rehozni. Elsőként Neumann J á n o s foglalkozott ezzel a problémával. Az élő szervezeteket vizsgálva arra a megállapításra j u t o t t , hogy azok a jelentéktelen hibára utaló jelzést egyszerűen figyelmen kívül hagy j á k , lényeges hiba esetén pedig a hibás „részegységet t a r t a l é k r a kapcsolják", s funkcióit az elegendően sokoldalú részeknek adják á t . Amennyiben a k i i k t a t o t t rész regenerálása sikertelen, a rendszer nem foglalkozik t o v á b b vele. I l y m ó d o n a rendszer élet t a r t a m á t a kijavítatlan h i b á k száma és súlyossága h a t á r o z z a meg [ 1 ] . Hogy a h i b a t ű r ő számítás napjainkra realitássá v á l t , annak egy t o v á b b i oka a V L S I á r a m k ö r ö k árá nak rohamos csökkenése. H i b a t ű r ő tulajdonságokat ugyanis csak a b e é p í t e t t elemek s z á m á n a k — k ö v e t kezésképp a berendezés á r á n a k — növelésével ér h e t ü n k el.
1. A megbízhatóság növelésének lehetőségei A megbízható számítás legáltalánosabb megfogalma z á s a : az algoritmus korrekt végrehajtása. Ez az — Avizienistől számazó [2] — t ö m ö r megfogalmazás azt jelenti, hog}^ a m ű k ö d é s eredménye nem t é r h e t el Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
TERTA
1982
VERESS
8. szám
TIBOR BHG
a gép szoftver és hardver által m e g h a t á r o z o t t ó l . Hogy ezt elérhessük, a k ö v e t k e z ő elemekről kell gon doskodnunk : — a szoftver-specifikáció korrektsége és komplett sége; — a programok tesztelése és ellenőrzése; — a hardver h i b á i n a k kiküszöbölése; — folyamatos, korrekt programvégrehajtás és a d a t v é d e l e m esetleges hardver-hiba esetén; — a rendszer védelme a hiba által okozott szét eséssel vagy szándékos behatással szemben. A huzamosabb idejű megszakítás nélküli m ű k ö dés biztosítására — különösen k a r b a n t a r t ó személy zet nélkül — alapvetően k é t lehetőség kínálkozik: — h i b a t ű r é s (fault-tolerance), — h i b a - n e m t ű r é s (fault-intolerance). A h i b a - n e m t ű r é s alkalmazása eleve megköveteli a m e g b í z h a t a t l a n elemek kiküszöbölését. A rendszer m e g b í z h a t ó s á g á n a k növekedését nagy megbízható ságú alkatrészek biztosítják. Ebben az esetben az üzemeltetési á r a t növeli a k a r b a n t a r t á s és program megszakadás á r a . H i b a t ű r ő tervezés esetén a szá m í t á s megbízhatóságát védő redundancia biztosítja. Az ötvenes, hatvanas években a h i b a - n e m t ű r é s t a l k a l m a z t á k elsősorban, aminek a redundancia m i a t t i árnövekedés volt az oka. Az u t ó b b i években a hardver-tervezésben előtérbe k e r ü l t a hibatűrés, amit a technológia fejlődése és a megbízhatósági köve t e l m é n y e k növekedése t e t t elkerülhetetlenné. L á t h a t ó , hogy a k é t lehetőség kiegészíti e g y m á s t (komplemensek), és hogy a megbízhatósági követel m é n y e k e t a k e t t ő valamelyikével lehet kielégíteni. A gyakorlat és az analízis azt mutatja, hogy a leg m e g b í z h a t ó b b számítás a k e t t ő kiegyensúlyozott al k a l m a z á s á v a l érhető el [3, 4]. 1.1. Megbízható
rendszerek tervezése
Egy számítógép vagy vezérlő m e g b í z h a t a t l a n s á g á t a logikai s t r u k t ú r a fizikai megépítésének tökéletlen sége okozza. A megbízhatóság-elmélet a rendszer R(T) megbízhatóságát annak a valószínűségeként de finiálja, hogy az a t — T időpontig kifogástalanul m ű -
361
ködik, ha az indulási idő f = 0 . Számítógépek esetén a h i b á t l a n m ű k ö d é s azonban m á s , mint egyéb beren dezéseknél. Célszerűbb egy program korrekt végre hajtásáról beszélnünk, mint a rendszer komponen seinek h i b á t l a n voltáról. A program h i b á t l a n végrehajtása a következő fel tételek kielégítését jelenti:
— komponensek (hardver) és programok (szoftver) sorát t a r t a l m a z z á k ; — kezdetben hibamentesek és a program végre hajtása alatt védettek a hibák megszakító ha tása ellen; — működési hiba esetén is korrektül végrehajtják a programot.
— a programok és adataik nem változnak vagy akadoznak hiba esetén; — a programok eredményei nem tartalmaznak zavar okozta h i b á t ; — a programok végrehajtási ideje nem lép t ú l egy specifikált h a t á r t ; — a programok számára rendelkezésre álló tároló k a p a c i t á s egy m e g h a t á r o z o t t minimum fölött marad.
A k é t megoldás — h i b a t ű r ő és nem hibatűrő ter vezés — t e h á t alapvetően különbözik egymástól. Az előbbinél a rendszer megbízhatóságát elsősorban az architektúra határozza meg, az utóbbinál a techno lógia.
Ezeket a specifikációkat (pl. végrehajtási idő, t á rolókapacitás stb.) a rendszer architektúrája, i l l . fel használója h a t á r o z z a meg. Az előzőekben l á t t u k a megbízható rendszerek megvalósításának k é t szélsőséges m ó d j á t : a nem hiba t ű r ő és a h i b a t ű r ő tervezést. Mivel az előbbit t ö r t é nelmileg is előbb a l k a l m a z t á k , t e k i n t s ü k előbb á t en nek a jellemzőit. A nem h i b a t ű r ő tervezés elemei a k ö vetkezők : — a legmegbízhatóbb elemeket kell kiválasztani; — kipróbált eljárást kell alkalmazni a komponen sek csatlakoztatására és az alrendszerek kivá lasztására; — a rendszer összeállításakor gondosan k i kell szűrni az előre l á t h a t ó külső zavarokat; — a rendszer megbízhatósága az ismert vagy előírt komponens- és csatlakozóhibák alapján szá mítható. A fentiek alapján k ö n n y e n b e l á t h a t ó , hogy a nem h i b a t ű r ő rendszerek esetén a program korrekt végre h a j t á s á n a k valószínűsége megegyezik a hardver hiba mentességének valószínűségével. Nagy megbízható ságú rendszerek építéséhez a nem h i b a t ű r ő tervezés emiatt igen k o r l á t o z o t t lehetőségeket nyújt, hiszen a megbízhatósági követelmények kielégítése t o v á b b r a is a technológia és nem az a r c h i t e k t ú r a függvénye. Ez azonban nem jelentheti ennek az eljárásnak a mel lőzését, i l l . figyelmen kívül h a g y á s á t , hiszen — mint majd a későbbiekben még látni fogjuk — számos területen előnyösen a l k a l m a z h a t ó . Egy rendszer megbízhatóságának számottevő ja vulása redundancia alkalmazásával érhető el, amely nek megvalósítási módjai a k ö v e t k e z ő k : — hardver eszközök t o v á b b i beépítése (hardver redundancia); — t o v á b b i programok, programszegmensek hasz n á l a t a (szoftver redundancia); — a m ű k ö d é s megismétlése (idő redundancia). Ezek a h i b a t ű r ő tervezés eszközei. Az így tervezett rendszerek esetén egy program k o n k r é t végrehajtá s á n a k valószínűsége nem egyezik meg a hardver hiba mentességének valószínűségével, hanem annál — a re dundancia mértékétől függően — nagyobb. A h i b a t ű r ő rendszerek az alábbi h á r o m jellemzővel rendelkeznek:
362
1.2. A működési hibák
osztályozása
A redundancia beépítésének célja az esetleges hibák maszkolása. Nyilvánvaló, hogy a megvalósítás módja a hiba jellegétől függően m á s és más. Célszerű ezért röviden á t t e k i n t e n i az előforduló h i b á k a t . A működési hiba definíciója: egy vagy t ö b b logikai változó értékének eltérése a hardver által m e g h a t á rozottól. A h i b á k a t az alábbi m ó d o n osztályozhatjuk: i d ő t a r t a m szerint: — tranziens — állandó, kiterjedés szerint: — lokális (egy változó) — elosztott ( t ö b b változó), érték szerint: — m e g h a t á r o z o t t (fix érték) — nem m e g h a t á r o z o t t (változó érték). A hibák i d ő t a r t a m szerinti osztályozása alapvető fontosságú, hiszen a tranziens és állandó hibák merő ben eltérő helyreállítási eljárást k í v á n n a k . Tranziens hiba pl. a program újrafuttatásával j a v í t h a t ó , míg állandó hiba esetén a korrekt m ű k ö d é s a hibás egység kiváltásával biztosítható. A kiterjedés és érték szerinti osztályozás hasonló okokból szintén fontos. A hibadetektálás, hibalokali zálás, a megfelelő elhárító eljárás tervezéséhez, i l l . a rendszer a r c h i t e k t ú r á j á n a k tervezéséhez adnak támpontot. 2. A védő redundancia megvalósítási lehetőségei H i b a t ű r ő tervezés esetén a megbízhatóság növeke dését redundancia segítségével érjük el. Ennek sikere az alábbi h á r o m forma szisztematikus és kiegyensú lyozott alkalmazásával b i z t o s í t h a t ó : — hardver redundancia: járulékos elemek (alrend szerek, modulok) beépítése, — szoftver redundancia: speciális programok fut tatása, — idő redundancia: a m ű k ö d é s megismétlése. Az alkalmazott hardver és szoftver redundanciát a modulok időbeni működésének alapján t o v á b b i k é t csoportra oszthatjuk: sztatikus és dinamikus redun danciára. Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
2.1. Sztatikus hardver redundancia A hardver r e d u n d a n c i á n a k ez a fajtája „ m a s z k o l ó " redundancia néven is ismert, mivel a járulékos kompo nens a hardver hibájának h a t á s á t maszkolja. (Pl. az 1. ábrán l á t h a t ó kapcsolás bármely elem hibája — sza-
dásával számolunk. Ez azzal a követelménnyel j á r , hogy egy hiba bekövetkezése és észlelése k ö z ö t t m á s egység nem romolhat el, i l l . a helyreállításnak olyan gyorsnak kell lennie, hogy közben ú j a b b hiba ne következhessen be. Ezen követelmények kielégítése speciális á r a m k ö r ö k k e l és programokkal valósítható meg.
ffe 240-11
1. ábra. A sztatikus (maszkoló) hardver redundancia alkalmazása k a d á s vagy rövidzár — esetén is dióda marad. Sőt, szerencsés esetben k é t vagy a k á r h á r o m elem is meghibásodhat.) L á t h a t ó , hogy a sztatikus hardver redundancia al kalmazása esetén a komponens h i b á j á t a rendszer nem észleli, az nem okoz késleltetést sem a program futása során. E m i a t t azonban a hiba észrevétlen ma rad, ami a rendszer állagának fokozatos r o m l á s á t eredményezi, megteremtve ezzel egy későbbi szét esés lehetőségét. A sztatikus hardver redundancia — maszkoló t u lajdonságánál fogva — e g y a r á n t védelmet n y ú j t tranziens és permanens hibák ellen, alkalmazása azonban költséges. A gyakorlatban k é t eljárás ter jedt e l :
Dinamikus hardver redundancia alkalmazása esetén a rendszer önellenőrző és önjavító képességgel rendel kezik (pl. hibajavító kódok). A dinamikusan redun dáns rendszer t e h á t képes a hiba észlelésére, majd annak h a t á s á r a helyreállító akció végrehajtására. Hibajelzés alkalmazása esetén k a r b a n t a r t ó személy zet segítségével elérhető, hogy a rendszer állaga az idő folyamán elvileg nem romlik.
— egyedi alkatrészek duplikálása (1. fenti példa), — triplikálás szavazással ( T M R = T r i p l e Modular Redundancy).
A dinamikus redundancia eszközei, amelyekkel min den dinamikusan r e d u n d á n s rendszernek rendelkez nie k e l l :
A szavazásos ( T M R ) eljárás szintén maszkoló t u lajdonsággal rendelkezik. Ez az oka annak, hogy sztatikus r e d u n d a n c i a k é n t ismert. Lényeges eltérés azonban a sztatikus duplikálással szemben, hogy a szavazó elem képes a hibás egység felismerésére. A triplikált modul ezáltal j a v í t h a t ó v á válik, azaz a rendszer állagának fokozatos romlása megakadályoz h a t ó . A szavazó elem megbízhatósága azonban dön tően befolyásolja a m ű k ö d é s t , annak különösen meg bízhatónak kell lennie. Hogy ezt hogyan oldják meg, azt a későbbiekben még látni fogjuk. A 2. ábrán a T M R elvi blokksémája l á t h a t ó . A z M mel jelölt modulok azonos funkciót l á t n a k el, szink ron m ű k ö d n e k . H a k ö z ö t t ü k eltérés mutatkozik, a szavazó elem a k é t megegyező e r e d m é n y t fogadja el az eltérő harmadikkal szemben. (Az eltérő ered ményből állapíthatja meg a modul hibás voltát.) F e l t ű n ő , hogy ha egyszerre k é t modul hibázik, akkor a kimenet is hibás lesz. E n n é l is nagyobb gond azonban, hogy ilyenkor a jó modul minősül hibásnak. Ez a probléma a h i b a t ű r ő tervezés sarkalatos pontja, amiről a dinamikus redundancia ismertetésekor még bővebben szó lesz. Egy lehetséges megoldás, hogy öt, h é t stb. ( p á r a t l a n számú) elemet kapcsolnak p á r h u z a m o s a n . Ebben az esetben azonban jelentős az árnövekedés. Csupán h á r o m modul alkalmazása is elegendő lehet, ha az ú n . egyszeres hiba feltételezésével élünk. Ez azt jelenti, hogy egyszerre csak egy elem meghibáso Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
B240-2
2. ábra. Triplikálás szavazással 2.2 Dinamikus hardver redundancia
a)
Modularitás
A rendszert modulokra (alrendszerekre) bontjuk, amelyek összekapcsolása v á l t o z t a t h a t ó lehet. H a a modulok egymás feladatait is képesek ellátni, akkor feladatátcsoportosítással megvalósítható a helyreállí t á s . Nagyon fontos a hibák modulok közti terjedésé nek megakadályozása az egyszeres hiba feltételezhetősége szempontjából. A modularitás a hibabeha tárolásnál is nagy segítséget n y ú j t . b)
Hibadetektálás
A rendszernek képesnek kell lennie a hiba észlelésére. Ez a tulajdonság a következő eszközökkel érhető e l : hibakód, státusjel használata, önellenőrző á r a m körök, duplikáció, triplikáció stb. alkalmazása, vala mint a kritikus egységek belső figyelése (monitoring). Hogy a sok lehetőség közül melyiket választjuk, azt az illető modul működése, i l l . működésének kritikus volta határozza meg. c)
Hibalokalizálás
A helyreállítás sikere érdekében a h i b á t nemcsak észlelni kell tudnunk, hanem bekövetkezésének a he lyét is ismernünk kell. Lényeges elvi különbség van t e h á t a h i b a d e t e k t á l á s és -lokalizálás k ö z ö t t . A hely reállító programmal vagy a k a r b a n t a r t ó személyzet tel közölnünk kell azt is, melyik modul szorul javí tásra.
363
d) Helyreállítási
akció
Az akciónak a hiba észlelése, i l l . bekövetkezési helyé nek meghatározása u t á n kell indulnia. H a a prog ram nem tudja kijavítani a hibát, permanens hiba keletkezik. Permanens hibából valói helyreállítási el járások: — a hibás modul kicserélése egy t a r t a l é k k a l , — hibajavító modul alkalmazása, — a hibás modul üzemen kívül helyezése, majd a működőképes modulok közti feladat-átcso portosítás. A hibajavító k ó d o t á l t a l á b a n memória-modulok ban, i l l . buszok figyelésére használják, a m ű k ö d ő képes (aktív) modulok közötti feladat-átcsoporto sítást pedig abban az esetben, ha nem áll rendelke zésre működőképes t a r t a l é k . e) „Hard core" védelem A dinamikus redundancia lényege, hogy a rendszer önellenőrző és önjavító tulajdonsággal rendelkezik. Az ezen feladatokat ellátó egységek megbízhatósága különösen fontos, azok meghibásodása nem enged hető meg. Ezeket az egységeket a rendszer „ h a r d core" részének nevezzük. Védelmüket a d r á g á b b el járások (pl. sztatikus redundancia) közül kell meg választanunk : — duplikálás kiegészítő felügyelettel, — triplikálás és szavazás (TMR), — hibrid redundancia, azaz T M R a hibás modulok cseréjének lehetőségével, — komponens (esetleg alkatrész) szintű redundan cia, — permanens, huzalozott (wired-in) hibajavító kód. f) Modulok közötti kapcsolat A modulok közti kapcsolat megvalósításának kivá lasztása döntő jelentőségű a dinamikus r e d u n d á n s rendszerek esetén. A következő k é t lehetőség áll ren delkezésünkre : — busz segítségével való kommunikáció, — minden modul mindegyikkel külön-külön öszszekötve (point-to-point). Az előbbi megoldás vonzóbb lehet, mivel kevésbé bonyolult, viszont a busz is hard core elem. Az u t ó b b i ezzel szemben költségesebb, és a rendkívül sok csat lakozás esetleg megoldhatatlan feladat elé állíthatja a tervezőket. g) A bemenet érvényesítése A bemenő jelek és adatok érvényesítése és/vagy hiba kódos átkódolása minden r e d u n d á n s rendszer számá ra fontos. E n é l k ü l ugyanis hibás adatokat olvasha t u n k be, ami a belső redundancia ellenére is hibás m ű k ö d é s t okozhat. 2.3. A sztatikus és dinamikus redundancia összehasonlítása Már az eddigiek alapján is l á t h a t ó , hogy egy hiba t ű r ő rendszer tervezőjének rendkívül sok lehetőség
364
áll rendelkezésére (eddig csupán a hardverről esett szó), ugyanakkor azonban nagyon nehéz feladat az optimális megoldás kiválasztása. Célszerű ezért rövi den áttekinteni a sztatikus és dinamikus redundancia jellemző tulajdonságait. A dinamikus redundancia előnyei a sztatikussal szemben: — A modulok nagyobb elszigeteltsége, ami a füg getlen hiba feltételének teljesülése szempontjá ból fontos. — A rendszer életben marad mindaddig, amíg egy modultípusból minden t a r t a l é k k i nem fogy. — A tartalékelemek s z á m á n a k és típusának sza bályozhatósága. — A tápfeszültséggel el nem l á t o t t tartalékok po tenciálisan kis hibavalószínűségének kihaszná lása. — A sztatikus redundancia á r a m k ö r i problémái nak elkerülése (ezek p l . : k i - és bemeneti ter helések, a tápfeszültség teljesítményének n ö vekedése). — A tartalékelemek ellenőrzésének könyebbsége az állandó diagnosztizáló program segítségével. — A rendszer hibatűrő képességének elvileg állan dó szinten t a r t h a t ó s á g a . A sztatikus redundancia előnyei a dinamikussal szemben: — E g y s z e r ű b b a l k a l m a z á s : a nem r e d u n d á n s ter vezés egyszerű, szisztematikus konverziója. — Azonnali h i b a m a s z k o l á s : nincs késleltetés, i l l . működésmegszakítás a helyreállítás számára. — A rendszer minden részének egyforma védelme: a hard core és a kapcsoló áramkörök védelmére nincs külön követelmény. Ez u t ó b b i tulajdonság csak a tervezés szempontjá ból előnyös, egyes modulokkal, alkatelemekkel szem ben viszont esetleg t ú l szigorú követelményeket t á masztunk. A felsorolt tulajdonságok alapján jól látható, hogy egy h i b a t ű r ő rendszer tervezésekor nem szorítkoz hatunk csupán a dinamikus vagy a sztatikus redun dancia által n y ú j t o t t lehetőségek kihasználására. A k e t t ő kiegyensúlyozott alkalmazása biztosítja a hibatűrő tulajdonságok lehető legoptimálisabb meg valósítását. 2.4. Szoftver redundancia A szoftver redundancia t o v á b b i programok, prog ramszegmensek, utasítások és mikroprogramlépések alkalmazása, melyekre h i b á t l a n hardver esetén nem lenne szükség. A szoftver redundancia h á r o m fő formája: a) A kritikus programok és adatok többszörös tárolása A hiba u t á n i helyreállítás csak akkor lehet sikeres, ha a kritikus programok és adatok a hiba által oko zott megszakítást, i l l . zavart „túlélik". A legtöbb általános célú rendszer duplikált h á t t é r t á r a k a t hasz nál másodlagos m e m ó r i a k é n t : diszk, mágnesdob, mágnesszalag. Ezek lehetővé teszik, hogy a hiba k ö v e t k e z t é b e n k á r o s o d o t t programok és adatok az Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
újrafuttatáshoz eredeti á l l a p o t u k b a n rendelkezésre álljanak. A h á t t é r t á r adatbázisa periodikusan újra töltődik, és a kezdeti é r t é k e t szolgáltatja, ha az adat elvész a memóriából. A kritikus programok védelmére á l t a l á b a n duplikált ROM-okat használnak, mivel a nem v á l t o z t a t h a t ó tárolás és a n e m d e s t r u k t í v k i o l vasás j ó lehetőség a kritikus programok és adatok tárolására [5, 6, 7\. b) Tesztelő és diagnosztizáló programok program és mikroprogram szinten Ezeknek a programoknak vagy mikroprogramoknak a célja — a hiba detektálása, lokalizálása, terjedelmének meghatározása; — a hardver ( t a r t a l é k is) periodikus tesztelése; — a tárolók adatai állandóságának és teljességé nek ellenőrzése; — a szoftver ellenőrzésének végrehajtása. Kiváló példája a programok hierarchiája alkalma zásának az ESS No. 1. t á r o l t programvezérlésű tele fonközpont [8]. Ez is és á l t a l á b a n minden számítógé pes rendszer tartalmazza a tesztelő, ellenőrző vagy •diagnosztizáló programok valamelyik formáját. A mikrodiagnosztizáló program a számítógép hard verének tesztelésére szolgáló speciális mikroprogram. Előnyei a k ö v e t k e z ő k : — a rendszer egy kis részének kell csak hibamen tesnek maradnia a mikrodiagnózis kezdeménye zéséhez; — a tesztek nagyobb felbontása érhető el a mikrom ű k ö d é s vizsgálatával, ezért r e d u k á l ó d n a k a t á roló- és időkövetelmények. A mikro diagnosztikák rezidens és nem rezidens ré szeket tartalmazhatnak. A nem rezidens rész a peri fériális tárolóból olvasható be, m i u t á n a viszonylag kis rezidens rész leellenőrizte a működéshez szükséges egységeket. A mikroprogramozott vezérlés használata a modern rendszerekben lehetővé tette a diagnosz tizáló programok mikrodiagnózissal való egyre na gyobb m é r e t ű pótlását. c) A programvégrehajtás
hibatűrő
képessége
A h i b a t ű r ő m ű k ö d é s legmagasabb szintű vezérlése az operációs rendszer felügyelő programjában (supervisor) t a l á l h a t ó . Ez alól csak az olyan rendszerekben van kivétel, amelyek egyszerű sztatikus hibatűréssel rendelkeznek ( T M R , komponens-redundancia stb.). A modern rendszerekben a h a r d v e r - h i b a d e t e k t á l á s t és -helyreállítást specális egységek vezérlik (Test and Repair Processor, Recovery Control U n i t stb.). Ezek az egységek tájékoztatják és/vagy vezérlik a felügyelő programot a helyreállítási folyamat alatt, melynek megvalósítása nagyon változó; a helyreállítás hard ver ú t o n való végrehajtásától kezdve egészen a na gyon erős szoftver-függésig. A h i b a t ű r ő funkciók vég rehajtásához a következők szükségesek: — — — — —
hibakollekció, a diagnózis végrehajtása, hibaanalízis és -jegyzék, hibastatisztika készítése, újjászervezés (rekonfiguráció),
Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
— — — — — nálói
ellenőrzőpont- (checkpoint-) hálózat, csatorna- és I / O - m ű v e l e t e k helyreállítása, memóriamásolás, az á l l a p o t v e k t o r tárolása, az újrakezdési (restart) pont vezérlése a felhasz program számára stb.
2.5. Idő redundancia A r e d u n d a n c i á n a k ez a formája a különböző szintű utasítások (mikroutasítások, gépi utasítások, prog ramszegmensek vagy egész programok) ismétlését vagy elfogadását tartalmazza. Á l t a l á b a n a dinamikus hardver és szoftver r e d u n d a n c i á v a l e g y ü t t alkalmaz zák. K é t külön célja van az idő r e d u n d a n c i á n a k : — h i b a d e t e k t á l á s a végrehajtás megismétlésének vagy elfogadásának segítségével, — helyreállítás programrestarttal vagy a m ű v e l e t visszahívása h i b a d e t e k t á l á s , i l l . rekonfiguráció után. a)
Hibadetektálás
A program végrehajtásának megismétlése valószínű leg a legrégibb formája a h i b a d e t e k t á l á s n a k . B á r al kalmas a tranziens h i b á k detektálására, h a t é k o n y ságát korlátozza az a t é n y , hogy permanens hiba esetén következetesen h i b á t p r o d u k á l , ezért össze hasonlításkor elmarad a hibajelzés. Ezt a p r o b l é m á t az utasítások részben m á s sorrendjével vagy a hard ver ismétlés alatti átszervezésével lehet áthidalni. Az a d a t t o v á b b í t á s és -elfogadás különböző formáinak h a s z n á l a t á t (handshaking) kiterjedten alkalmazzák az általános célú rendszerekben, különösen a másod lagos (háttér-) tárolók, csatornák, I / O eszközök hiba detektálására. b)
Újraindítás
Az idő r e d u n d a n c i á t e g y a r á n t használják tranziens hiba okozta zavarok felismerésére és j a v í t á s á r a , vala mint a hardver-rekonfiguráció u t á n i programrestart esetén. Ez az utasítások, programszegmensek vagy teljes programok h i b a d e t e k t á l á s u t á n i megismétlését jelenti. E h á r o m ismétlési eljárás tervezése a k ö v e t kező tényezők függvénye: — Milyen messze lehet vagy kell a programot restartolni? — Milyen költséges (idő, hardver, programozási kényszer) az ismétlés? — Milyen valószínű a zavar sikeres javítása, ha azt tranziens hiba okozta? Egyszeres utasítások ismétlése esetén minden uta sítás e r e d m é n y é t v é d e t t t á r o l ó b a n kell őrizni a követ kező u t a s í t á s végrehajtásáig. A másik k é t esetben járulékos programozási követelmények lépnek fel: — a program szegmentálása, — az ismétlési pont meghatározása, — az ismétlési cím felülírása előtti állapotvektor tárolása stb. A járulékos hardver tartalmazza a v é d e t t t á r o l ó k a t az ismétlési cím és az állapotvektor s z á m á r a .
365
'A. A megbízhatóság modellezése és becslése
R egy specifikált megbízhatóság, T és T pedig azok az idők, mialatt R és R (rendszermegbíz hatóság) v á r h a t ó a n R - r e csökken. M I N
ü j
üj
Hogy a tervezés során a r e d u n d á n s módszerek k ö z ö t t választani tudjunk, az egyes módszerek h i b a t ű r ő t u lajdonságainak bizonyítása szükséges. E bizonyítás számszerű mennyiségek becslésével, számításával va lósítható meg. A megbízhatóság meghatározása kimutathatja az eredeti tervezés elégtelenségeit, ilyenkor t o v á b b i hiba t ű r ő képességek hozzáadásával érhető el javulás. Az eljárást természetesen addig kell ismételni, míg telje sen kielégítő konstrukciót nem kapunk. K é t elvi mennyiségi jellemzőt szoktak m e g h a t á rozni : — a megbízhatóságot (az állandó hibák figyelem bevételével) és — a túlélést (tranziens hibák esetén). A h i b a t ű r ő képességek becslésének k é t módja ter jedt el. Az analitikus megközelítés során a rendszer h i b a t ű r ő képességének p a r a m é t e r e i t annak matema t i k a i modellezésével kapjuk. A kísérleti megközelítés esetén h i b á t okozunk a rendszer hardver-prototípu sában vagy annak szimulált modelljében, és a hiba t ű r ő képességeket a statisztikai adatokból határoz zuk meg. 3.1. Az analízis
alapmennyiségei
Egy rendszer hibatűrésének legáltalánosabban hasz n á l t m é r t é k e az M T B F (mean time between failures = = h i b á k közti átlagos idő), amely az alábbi módon származtatható: M T B F = j R ( t ) dt. A nem r e d u n d á n s rendszerek vagy azok elemeinek megbízhatósága a jólismert R ( t ) = e~ függvénnyel írható le, ahol A = meghibásodási tényező (failure rate) és R ( 0 ) = 1. ,at
H a R ( t ) = e - , akkor , f
MTBF=4.
Á Az MTBF-ek összehasonlítása t e h á t a rendszerek A-inak összehasonlítását jelenti. Redundancia esetén R(t) polinomiális e~ -re és a különböző rendszerek R(t) görbéi t ö b b helyen metszik egymást, ezért nem d ö n t h e t ő el egyértelműen, melyik a jobb. E m i a t t t o v á b b i , speciális jellemzők bevezetése szükséges. H a adott egy állandó T (mission time = működési idő), akkor k é t vagy t ö b b rendszer összehasonlításá hoz csak az R ( T ) értékekre van szükség. A megbízhatóság-javulási faktor ( R I F = reliability improvement factor) egy új rendszer megbízhatósá g á n a k j a v u l á s á t mutatja a régiéhez képest. M
M
M
R I F = 1 ~ ^régi(Tjw) 1 — új( Aí) R
T
Abban az esetben, ha nem a d h a t ó meg a T ál landó, az M T I F (mission time improvement factor = = működési idő növekedési faktor) szolgál összeha sonlításul : T, ahol MTIF==~ M
L
366
régi
RMIN "
r é g i
régi
MIN
3.2. Sztatikus megbízhatósági modellek A megbízhatóság modellezésének ez az osztálya a sztatikus hardver-redundáns rendszerek megbíz h a t ó s á g á n a k becslésére szolgál. E redundancia jelle génél fogva az elemek állandó csatolásúak, saját meg hibásodási tényezőjük van, azonnal végrehajtják a hiba maszkolását, amely sikerességének valószínű ségét egységnyinek, a h i b á k a t pedig függetleneknek feltételezzük. Ilyen feltételek mellett a sztatikusan r e d u n d á n s rendszerek megbízhatósága a nem redun dáns rendszerekéből számítható. Ha a szimplex rend szer megbízhatósága R, akkor R
d u p l e x
=
R 2
+2R(l-R),
íW=[R +3R (l-R)]Rv, 3
2
R = a szavazó elem megbízhatósága. v
Ez utóbbi kifejezésből nagyon jól látható, hogy szavazásos eljárás esetén a rendszer megbízhatóságát döntően befolyásolja a szavazó elem megbízhatósága. Annak hibája nem engedhető meg, ezért hard core. 3.3. Dinamikus megbízhatósági modellek A dinamikus redundanciához hibadetektálás és hely reállítás kell. A sztatikus megbízhatósági modellek dinamikus esetben való alkalmazása m i n d k e t t ő sike rességét egységnyi valószínűségűnek feltételezi. Ennek megfelelően nagyon nagy megbízhatóságot lehet el érni a t a r t a l é k o k s z á m á n a k növelésével. Általános követelmény, hogy a dinamikus modellnek reprezen tálnia kell a teljes h i b a t ű r ő rendszert, azaz — különböző meghibásodási tényezőket m ű k ö d ő és t a r t a l é k modulokhoz, — minden modul t a r t a l é k a i n a k számát, — a nem tökéletes h i b a d e t e k t á l á s t és helyreállí tást, — a hard core védelem megvalósítását, — a modulokon belüli hibatűrést, — a v á r h a t ó h i b á k kiterjedését és értékét, — a v á r h a t ó tranziens hibák i d ő t a r t a m á t és el oszlását. L á t h a t ó , hogy a dinamikusan redundáns rendsze rek analitikus modellezése viszonylag bonyolult a kü lönböző paraméterek nagy száma miatt, amelyek az optimális t e r m é k kiválasztásakor változhatnak. Nagyon jó eszköz a megbízhatóság becslésére egy i n t e r a k t í v számítógépprogram, amely on-line végre hajtja a dinamikusan r e d u n d á n s rendszer fontosabb paramétereinek finomítását. Az ú t t ö r ő a R E L program volt* melyet A P L nyel ven í r t a k . Ha egy rendszer paramétereit specifikáljuk, adott T -hez megadja a megbízhatóságot. A szá m í t á s során figyelembe vehető a tökéletlen hibadetek tálás és -javítás h a t á s a is [9]. Egy másik korai kísérlet a C A R E program, ame lyet a JPL—STAR komputer-tervezettel kapcsolat ban fejlesztettek k i [10]. Ujabban erőfeszítéseket teszM
Híradástechnika
XXXIII.
évfolyam 1982. 8. szám
nek általános és s z á m í t h a t ó h a t é k o n y modellek el érésére t o v á b b i APL-programok segítségével [11, 12]. A dinamikusan r e d u n d á n s rendszerek h i b a t ű r ő k é pességeinek k v a l i t a t í v vizsgálatához nagyon jól hasz nálható azok gráfokkal t ö r t é n ő leírása. A különböző modulokat a gráfok csomópontjai, a modulok közti kapcsolatokat pedig ágai reprezentálják [13, 14]. Ü j a b b a n az önellenőrző és helyreállító programokat is gráfos leírással elemzik, tervezik [15, 16]. 3.4. A megbízhatóság kísérleti
becslése
Az analitikus becslés bonyolultsága, i l l . eredményei nek ellenőrzése szükségessé teszi a megbízhatóság kísérleti becslését, amelynek k é t m ó d j a : — kísérlet a prototípussal, — szimuláció. B á r alkalmazása költségesebb és időigényesebb, a kísérlet mégis előnyösebb, ha az analitikus modell nem képes helyesen leírni a rendszer s t r u k t ú r á j á n a k k o m p l e x i t á s á t vagy a v á r h a t ó hibák természetét. A prototípussal való kísérlet jó példája az ESS No. 1 rendszer, melyhez hibakatalógust készítettek a pro totípus felhasználásával [8]. A kísérlet azonban időigényes és nem mindig áll rendelkezésre a prototípus. Erre az esetre fejlesztet ték k i a különböző szimulációs nyelveket ( S I M U L A 67, GPSS), amelyeket elterjedten használnak a hiba tűrő képesség és megbízhatóság vizsgálatához. IRODALOM [1] Neumann János élete és munkássága (A különböző tudományterületeken elért eredményeinek össze foglaló áttekintése.) Szerk.: Szentiványi Tibor Bp. 1979. [2] A. Avizienis: Architecture of Fault-Tolerant Computing Systems. FTC—5, International Symposium on Fault-Tolerant Computing, Paris, Francé, June 1975. pp. 3 - 1 6 . [3] A. Avizienis: Fault-Tolerance: The Survival Attribute of Digital Systems. Proc. of the I E E E , Vol. 66, No. 10, Oct. 1978, pp. 1109-1125.
Híradástechnika
XXXIII.
évfolgam 1982. 8. szám
[4] A. Aviziens: Fault-Tolerant Computing — Progress, Problems and Procpects. Proc. of I F I P Congress '77, Toronto, Aug. 1977, pp. 405 — 420. [5] S. B. Akers: Partitioning for Testability. F T C S - 6 , Int. Symp. on F T C , Pittsburgh, Pennsylvania, June 1976, pp. 121-126. [6] C. J. Jenny: Process Partitioning in Distributed Systems. NationalTelecommunieations Conference, Vol. 2, New York, 1977, pp. 31:1-1-31:1-10. [7] R. D. Roger, F. E. Fromm: Quantification and Measurement of Fault Recovery Pcrformancc F T C S — 7, The 7th Ann. Int. Conf. on F T C , Los Angeles, California, June 1977, pp. 209-210. [8] R. W. Downing, .1. S. Nowak, L . S. Tuomenoksa : No. 1 E S S Maintenance Plan. The Bell System Technical Journal, Vol. 43, No. 5, Part 1, Sept 1964, pp. 1961-2019. [9] W. B. Bouricius, W. C. Carter, D. C. Jessep, P. R. Schneider, A. B. Wadia: Reliability Modeling for Fault-Tolerant Computers. I E E E Transactions on Computers, Vol. C - 2 0 , No. 11, Nov. 1971, pp. 1306-1311. [10] F. P. Mathur: Automation of Reliability Evaluation Procedures through C A R E — The Computer-Aided Reliability-Estimation Program. A F I P S Conference Proceedings, Vol. 41, Anaheim, Cali fornia, Dec. 1972, pp. 67-77. [11] X . W. Ng, A. Avizienis: A Unifying Reliability Model for Closed Fault-Tolerant Systems. Digest of the 5th Int. Symp. on F T C , Francé, June 1975. [12] D. A. Rennels, A. Avizienis: RMS: A Reliability Modeling System for Self-Repairing Computers Digest of the 3rd Int. Symp. on F T C , Palo Alto, California, June 1973, pp. 131-135. [13] J. P. Hages: A Graph Model for Fault-Tolerant Computing Systems. I E E E Transactions on Com puters, Vol. C - 2 5 , No. 9, Sept. 1976. [14] J . P. Hages, R. Yenneg: Fault Recovery in Multiprocessor Networks. F T C S —8, The 8th Ann. Int. Conf. on F T C , Toulouse, Francé, June 1978, pp. 123-128. [15] Harmat László: Multi-mikroprocesszoros struktú rák önellenőrzése és öndiagnosztikája. Kandidá tusi értekezés, 1980. [16] A. D. Friedman, L . Simoncini: System-Level Fault Diagnosis Computer, Marcfi 1980, pp. 47-53. [17] Veress Tibor: Hibatűrő irányító rendszerek a kap csolástechnikában. Szakmérnöki diplomaterv, B M E - H E I , 1981.
367
