Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoalap|BeagyRendEllTechnika}} Felhasznált irodalom: [http://www.mit.bme.hu/oktatas/targyak/vimm3244/jegyzet/2006/majzik_vazlat2006.pdf majzik_vazl…”

2012-10-21T19:53:08Z

Új oldal, tartalma: „{{GlobalTemplate|Infoalap|BeagyRendEllTechnika}} Felhasznált irodalom: [http://www.mit.bme.hu/oktatas/targyak/vimm3244/jegyzet/2006/majzik_vazlat2006.pdf majzik_vazl…”

Új lap

{{GlobalTemplate|Infoalap|BeagyRendEllTechnika}}

Felhasznált irodalom: [http://www.mit.bme.hu/oktatas/targyak/vimm3244/jegyzet/2006/majzik_vazlat2006.pdf majzik_vazlat2006.pdf előadásvázlat]

__TOC__

NYOMTATHATÓ:
[http://info.sch.bme.hu/document.php?cmd=download_proc&tmp_page=&doc_id=12262 [[InfoSite]] - pdf]

==1. Kérdés==
'''Mi a szolgáltatásbiztonság, mik ennek a jellemzői?''' 
Meghatározza, hogy milyen biztonsággal képes ellátni feladatait a rendszer. Igazoltan, azaz elemzésekkel, mérésekkel bizonyítottan, meg lehet bízni a szolgáltatásban, hogy a tőle elvárt követelményeket kielégíti. Jellemzői:
* megbízhatóság
* rendelkezésre állás
* biztonság
* bizalmasság
* integritás
* karbantarthatóság

'''Mik a szolgáltatásbiztonság befolyásoló tényezői?''' 
* hibajelenség: a specifikációnak nem megfelelő szolgáltatás
* hiba: hibajelenséghez vezető rendszerállapot
* meghibásodás: a hiba feltételezett oka

'''Hogyan lesz a meghibásodásból hibajelenség?''' 
Hatásláncot alkotnak: Meghibásodás -> Hiba -> Hibajelenség
 
'''Milyen eszközök ismeretesek a szolgáltatásbiztonság növelésére?''' 
* megelőzés
* megszüntetés
* hibatűrés
* előrejelzés
==2. Kérdés==
'''Mi a verifikáció és a validáció?''' 
* '''Verifikáció''' (igazolás) ''"Jól tervezem-e a rendszer?"''
** formális verifikáció
** statikus analízis
** tesztelés
** szimuláció
* '''Validáció''' (érvényesítés) ''"Jó rendszert terveztem?"''
** validációs tesztelés: prototípus alapján
** szimuláció valós környezetben, mérések 
'''Milyen tipikus ellenőrzési technikák vannak a szoftver fejlesztési folyamat egyes fázisaiban?'''
* Specifikálás - statikus analízis
* Architektúra tervezés - veszély és kockázati analízis
* Modulok tervezése - statikus analízis
* Modulok megvalósítása - kódolási szabványok
* Modul verifikáció - tesztelés (monitorozás)
* Modul integrálás - integrációs tesztelés
* Rendszer verifikáció - rendszertesztelés
* Rendszer validáció - validációs tesztelés

==3. Kérdés==
'''Mi a statikus átvizsgálás célja és módszere?''' 
Célja a hiányosságok felderítése, módszere a sorról sorra történő átolvasás, automatizálható, például a C nyelv esetén a =lint= program használható. 
'''Milyen szervezeti rend szerint valósul ez meg?''' 
?? szerző - átvizsgáló - teszttervező - moderátor ??
 
'''Mi az ellenőrző listák használatának előnye illetve veszélye?''' 
A tipikus hibák esetén a detektálást megkönnyíti, azonban a teljessége nem garantálható, hamis biztonságérzetet adhat.
 '''Milyen szempontjai vannak a specifikáció teljesség és ellentmondás-mentesség ellenőrzésének?''' 
* '''Állapotdefiníció teljessége''' kezdőállapot biztonságos + a belső modell aktualizálása
* '''bemenetek teljessége''' minden bemenetre van reakció, a bemenet helyességének ellenőrzése, megszakítások gyakorisága megfelelő
* '''kimenetek teljessége''' hihetőség vizsgálat, fel nem használt kimenetek, környezet túlterhelésének elkerülése
* '''kimenet és bemenet kapcsolata''' hatások ellenőrzése érzékelőkkel, stabilitás
* '''állapotátmenetek teljessége''' elérhető állapotok, visszafordítható állapotátmenetek, veszélyes állapotból kivezető átmenet (ne ragadjon be), biztonságos->veszélyes állapotátmenet teljes felügyelete, katasztrofális állapot nem elérhető
* '''ember-gép interfész teljessége''' kimenő események frissítése és időbelisége megfelelő legyen

==4. Kérdés==
'''Mikor nevezünk egy rendszert biztonságkritikusnak?''' 
A specifikáció nem teljesítése balesethez, káresethez vezethet.
 
'''Mit jelent a baleset, veszély, kockázat fogalma?''' 
* '''baleset''' Nem kívánatos, be nem tervezett kár, veszteség
* '''veszély''' olyan állapot mely adott környezeti feltételek mellett balesethez vezet.
* '''kockázat''' veszély szintje + időtartama + baleset valószínűsége
'''Mit tartalmaz a kockázati mátrix, hogyan jelenik meg ebben a védelmi szint?''' 
A veszély analízis során
* a '''veszély szint''' lehet katasztrofális, kritikus mérsékelt és elhanyagolható
* '''bekövetkezési gyakoriság''' lehet gyakori, valószínű, esetenkénti ritka, valószínűtlen és lehetetlen.

A kockázati mátrix oszlopait a veszélyszint adja, sorait pedig a gyakoriság. A mátrixon belül a védelmi szint egy terület, mely minden szinthez egy még elfogadható gyakoriságot rendel. Lásd '''ÁBRA''' .
 
'''Mik a kockázatcsökkentés általános módszerei? Mondjon ezekre egy-egy példát!''' 
* veszély kiküszöbölés: helyettesítés (kevésbé veszélyes eszközök), egyszerűsítés (determinisztikus struktúra), szétcsatolás (moduláris felépítés, jogosultság kezelés)
* veszély csökkentés: vezérelhetőség, határolók, hiba minimalizálás
* veszély kézbentartás: időtartam csökkentése, elszigetelés
* kár csökkentés: menekülési, riadó terv

==5. Kérdés==
'''Hogyan konstruálható egy hibafa?''' 
Kiindulva egy rendszerszintű veszélyből (fentről lefelé haladó analízis) a közbenső eseményeket logikai AND/OR kapuk kötik össze, a fa leveleiben tovább nem vizsgált események vagy elsődleges események találhatók. Ezen kívül találhatunk még hiba/veszély nélküli normál eseményeket jelképező csomópontokat illetve összetett események bekövetkezéséhez szükséges feltételeket jelképező szimbólumokat.
 
'''Milyen elemei lehetnek a hibafának, mi ezek grafikus jelölése?''' 
{{InLineImageLink|Infoalap|BeagyRendEllTechnika|hibafa.PNG}}
* téglalap
* kör
* rombusz
* házikó :)
* ellipszis
* AND/OR kapu
'''Mit jelent a kvalitatív analízis egy hibafa esetén?''' 
A hibafa redukcióját, a közbenső események feloldását.
 
'''Hogyan ismerhető fel az egyszeres hibapont (SPOF)?''' 
Önmagában is elég a rendszerszintű veszély kialakulásához, tehát a fa gyökéreméhez kizárólag OR kapukkal is el lehet jutni hozzá... ~gondolom szebben is meg lehet fogalmazni...
 
'''Hogyan végezzük a rendszerszintű veszély valószínűségének kiszámítását?''' 
A levélelemtől a gyökérig vezető úton az egyes események szorzata(AND) és összege(OR), feltéve, ha független eseményekről van szó.
 
'''Mi a hibafa legfőbb hátránya?''' 
Egy esemény több vágatban is szerepelhet, a hibák korrelálhatnak, hanyagul kezeli az időbeli hibaszekvenciákat.
Vágat: Egy AND kapuval összefogott elsődleges események
Minimális vágathalmaz: Nem redukálható tovább
 
'''Mit ad meg egy eseményfa?''' 
Baleset forgatókönyvek vizsgálata az egyes gyökér-levél utak valószínűsége, elágazásokat az eseményeket bekövetkezései alkotják.
 
'''Milyen elemekből épül fel?''' 
események bekövetkezése szerint ágazik el. Gyökérben a kiváltó esemény levelekben az összesített valószínűség.
 
'''Hogyan számíthatók az egyes forgatókönyvek (eseményszekvenciák) valószínűségei?''' 
A gyökér-levél út mentén összeszorzódnak a P_{i} alakú valószínűségek, ugyanekkor az 1-P_{i} alakok nem játszanak szerepet.
 
'''Mi az ok-hatás analízis?''' 
Az eseményfa és a hibafa összekapcsolása, minden kritikus eseményhez külön diagrammot épít.
 
'''Hogyan számíthatók ki az egyes forgatókönyvek (eseményszekvenciák) valószínűségei?''' 
A nem teljesülő események valószínűségei jelentkeznek az alsó "leveleken".
==6. Kérdés==
'''Mit jelent a funkcionális tesztelés?''' 
A rendszer funkciói ismertek, a belső felépítése nem (fekete doboz), a teszt a specifikált funkciók meglétére irányul.
 
'''Milyen módszerekkel generálhatunk funkcionális teszteket?''' 
* ekvivalencia particionálás
* határérték analízis
* ok-hatás analízis
* a módszerek együttes alkalmazása
'''Mi az ekvivalencia particionálás alapötlete?''' 
Kezeljük egységesen azon bemenő adatokat, melyek ugyanazon hibát fedik le. Célunk, hogy minden így alkotott ekvivalencia osztályból egyetlen teszt futtatása elegendő legyen.
 
'''Hogyan célszerű meghatározni a teszteket érvénytelen ekvivalencia osztályok esetén?''' 
Érvényes esetben egy teszt minél több osztályt fedjen le. Ezzel szemben az érvénytelen osztályok esetén minden osztályhoz külön teszt kell (egymás hatását ki ne oltsák)
 
'''Hogyan lehet teszteket generálni határérték analízissel?''' 
A bemeneti és kimeneti tartomány alsó és felső határára generál tesztesetet, a határértékeknél 2-3 teszteset a tartomány közepén külön egy. Ezáltal egyetlen tartományhoz 5-7 tesztesetet generál.
 
'''Mi az ok-hatás analízis alapötlete?''' 
A bemeneti feltételek kombinációját vizsgálja, ok: bemeneti ekvivalencia osztály, hatás: kimeneti ekvivalencia osztály. Ezekből egy bool-gráfot alkotunk.
 
'''Milyen esetekben alkalmazható?''' 
?? AND/OR kapcsolatok illetve tiltó kombinációk esetén ??
 
'''Mikor érdemes véletlen teszteket alkalmazni?''' 
Hatékonyság szempontjából a tesztelés végső fázisában célszerű alkalmazni, hiszen hibafedése elég kicsi, előnye viszont az alacsony számítási idény.
 
'''Milyen teszteket célszerű előbb elvégezni a tesztelési folyamatban?''' 
A várhatóan nagyobb hibafedésű teszteket célszerű először végrehajtani.

==7. Kérdés==
'''Milyen információra alapoznak a strukturális tesztek?''' 
A vezérlési szerkezet ismeretét feltételezzük, minden ágát meg kellene vizsgálnia (ha lenne hozzá kapacitás) 
'''Milyen teszt minőségi mértékszámok rendelhetők a strukturális tesztekhez?''' 
* utasítás lefedettség
* döntési ág lefedettség
* feltétel lefedettség
* út lefedettség
'''Mi az utasítás, döntési ág, feltétel, és útvonal fedettség definíciója?''' 
* tesztelés során végrehajtott utasítások száma/összes utasítás száma
* tesztelés során végrehajtott döntési ágak száma/összes lehetséges döntési ág száma
* feltételekben a tesztelt bemeneti kombinációk száma/feltételekben az összes bemeneti kombinációk száma
* bejárt független utak száma/összes független út száma
'''Miért nem elég a 100% utasításfedettség egy modul alapos teszteléséhez?''' 
mert nem veszi figyelembe a kihagyási feltételeket.
 
'''Hogyan állapítható meg egy vezérlési gráfban a független utak maximális száma?''' 
E(Élek száma) - N(pontok száma a vezérlési gráfban) + 2
 
'''Milyen nehézségek adódnak a független utak tesztelésekor?''' 
a független utak halmaza nem egyedi, nem minden út bejárható, ciklikus működés korlátozása, a belső változók beállítása érzékeny lehet.
 
'''Mi a regressziós tesztelés?''' 
Egy modul változtatása utána teszteseteket újra le kell futtatni, hiszen nem tudhatjuk, hogy a változtatásoknak milyen hatásai lettek. ([http://hu.wikipedia.org/wiki/Regresszi%C3%B3s_tesztel%C3%A9s Wikipedia - Regressziós tesztelés]) -- [[PaleszA|Pálesz]] - 2007.06.04.

==8. Kérdés==
'''Mi jellemző a modulok izolációs tesztelésére? Mi a teszt végrehajtó és a teszt csonk szerepe?''' 
A modulokat egyenként, elszigetelten tesztelik, ehhez egy tesztvégrehajtót(a vezérlés és megfigyelés biztosítója) és egy teszt csonkot (hívott modul egyszerű helyettesítése). Integrációt nem biztosít, módosítás esetén egyetlen modult kell újratesztelni.

==9. Kérdés==
'''Mi az integrációs tesztelés célja?''' 
A kapcsolódási interfészek tesztelése kerül sorra, hiszen annak ellenére a rendszer hibás lehet, hogy minden modul egyébként hibamentes.
 
'''Milyen tesztelési stratégiákat ismer integrációs teszteléshez?''' 
Az együttműködés tesztelése során vagy egyenként összerakjuk a modulokat, vagy az ún. "Big bang" megközelítéssel egyszerre mindenkit integrálni a rendszerbe. Előbbi esetben a Top-down és a bottom-up tesztelés a jellemző.
 
'''Miért nem célszerű a "big bang" tesztelés nagyobb rendszerek esetén?''' 
Nagy a hibavalószínűség nagy rendszereknél, a hiba okát ebben az esetben nehéz lokalizálni.
 
'''Mi a különbség a felülről lefelé és az alulról felfelé történő integrációs tesztelés között a teszt csonkok és végrehajtók használata, valamint a modul módosítás hatásainak szempontjából?''' 
* '''Top-down''' új modult csak a már tesztelt '''hívó''' modulokból tesztelhetők. A később tesztelendő "alsó" modulok helyettesítésre csonkok szükségesek. Módosítás esetén csak az alatta lévők tesztelését módosítja.
* '''Bottom-up''' a már letesztelt modulokat használhatja hívásra, a modult meghívó tesztvégrehajtó szükséges. Módosítás esetén csak a fölötte lévő később tesztelt modulok változása lehet szükséges.
 
'''Hogyan végezhető a futtató rendszerrel való integráció tesztelése?''' 
Három lépésben:
# az alkalmazás modulok integrációja felülről lefelé - a futtató rendszer szintjéig
# a futtató rendszer alulról felfelé történő tesztelése
# az alkalmazás és a futtató rendszer integrációja

==10. Kérdés==
'''Mi a rendszertesztelés célja? Milyen rendszertesztelési technikákat ismer?''' 
A rendszerszintű specifikáció teljesítésének ellenőrzése.
A rendszer szolgáltatásait, használhatóságát, biztonságosságát, teljesítményét, megbízhatóságát teszteli. Külön kitér a a stressztűrésre(löket), a dokumentáltságra, és a konfiguráció helyességére.
 
'''Mi a validációs tesztelés célja?''' 
A valóságos környezet ''hatásainak'' tesztelése, váratlan eseményekre való reagálás, kis valószínűségű események, túl-/alulterhelés vizsgálata.
 
'''Miben különbözik ez a rendszerteszteléstől?''' 
?Rendszertesztelésnél a környezet egy modellel van szimulálva, validációnál meg a valós környezetben vizsgálódunk?

==11. Kérdés==
'''Mi a monitorozás célja?''' 
Futásidőbeli információk gyűjtése, az előírások teljesítésének ellenőrzése, a teljesítmény valós környezetben vizsgálható, biztonsági ellenőrzés.
 
'''Mik az alapműveletei?'''
* Felműszerezés - az információ hozzáférhetőségét biztosítja
** SW - a kódban külön utasítások
** HW - rendszerbusz, processzor közvetlen letapogatása
* Triggerelés - az információ szűrése
** SW - ugyancsak extra utasítások
** HW - busz forgalom figyelése
* Regisztrálás - a beszerzett információ tárolása
** SW - naplózás
** HW - jel-mintavételezés
'''Hogyan végezhető el a felműszerezés, a triggerelés és az információ tárolás?''' 
lásd előbb...
 
'''Mik az alapproblémák a monitorozás során, és hogyan kezelhetők ezek (beavatkozás, szemantikai hézag, globális információk szerzése)?''' 
A '''beavatkozás''' során a rendszer erőforrásait használjuk, ezáltal megváltoztatjuk a rendszer viselkedését: megváltoznak az időviszonyok az eseménysorrend. Ennek elkerülésére érdemesebb HW monitorozást alkalmazni, illetve a időzítéseket korrigálni, esetleg a monitorozó kód benthagyása a végleges rendszerben. 
'''Szemantikai hézag''' elkerülése érdekében a számunkra érdekes információk kinyerése komoly feladat HW-es tesztelésnél. 
'''Globális jellemzők''' meghatározása a lokálisan gyűjtött információkból komoly nehézségekbe ütközhet.
 
'''Mit jelent a szoftver, hardver és hibrid monitorozás (milyen megoldások vannak a felműszerezésre, triggerelésre, regisztrálásra)?''' 
* '''szoftver''' monitorozás esetében a megfigyelt rendszerbe építjük bele a megfigyelő kódot, felműszerezés alatt a trigger utasítások beszúrása lehet kézi (külön figyelmet érdemlő eseményekkor) illetve automatikus (eseményosztályok vizsgálata). A Trigger utasítások javasolt helye a kernel (ütemezés megfigyelhető, alkalmazás független) vagy az alkalmazás (magasabb absztrakció érhető el)
* '''hardver''' monitorozás során viszont lényegében a megfigyelt rendszertől teljesen függetlenül tudunk információt gyűjteni és feldolgozni, ez alkalmassá teszi szigorú RealTime rendszerek esetén az alkalmazhatóságát.
* '''hibrid''' monitorozás ötvözi a két technika előnyeit, minimális beavatkozással kíván a lehető legnagyobb rugalmasságot biztosítani.
 
'''Melyik megoldásnak mi az előnye?''' 
* '''szoftver''' könnyen implementálható, rugalmas
* '''hardver''' nem avatkozik be
* '''hibrid''' minimális beavatkozás, rugalmas

 
'''Milyen hibakeresési technikákat támogathatnak az egyes fejlesztői rendszerek?''' 
* végrehajtási időkorlátok (time-out)
* kommunikációs hibák (üzenet-vesztés/többszörözés)
* szinkronizációs hiba (globális szinkronizáció, kiéheztetés
* ütemezési hibák (nagy késleltetés)
* holtpont helyzetek (folyamat, üzenet, erőforrás)
'''Hogyan jeleníthetők meg egy elosztott rendszerben a rendszerszintű monitorozott jellemzők (milyen a felépítésük)?''' 
* '''processz együttműködési gráf''' szülő-gyermek folyamatok nyomkövetése, függőleges tengelyen az idő, a folyamatok születése, futása, várakozási ideje, és terminálása figyelhető meg.
* '''processz státusz gráf''' fa alakban a szülő-gyermek kapcsolatok és futási állapotuk.
* '''szemafor allokációs mátrix''' szemaforok és processzek kapcsolata
* '''üzenet-szekvencia diagram''' időben ábrázolja a küldés, fogadás eseményeket.

==12. Kérdés==
'''Mi a hibatűrés alapfeladata?''' 
Az ellenőrzés után fennmaradó zavarok időleges hardverhibák, tesztelésből kimaradt szoftver hibák/komplex interakciók ellenére a hibatűrésnek garantálni kell a szolgáltatást hiba esetén is, ez autonóm hibakezeléssel, beavatkozással garantálható.
 
'''Hogyan jelenik meg a redundancia egy rendszerben?''' 
* '''hardver''' többlet erőforrások biztosítása, már eleve a rendszerbe beleépítve vagy hiba esetén bekapcsolódó tartalék HW
* '''szoftver''' kiegészítő szoftvermodulok
* '''információ''' hibajavító kódolás
* '''idő''' ismételt végrehajtás, hibakezelés többletideje
'''Milyen jellegzetes hibákra készülhetünk fel a hibatűrés technikáival? Milyen ezeknek a hibáknak a tipikus előfordulási aránya?''' 
HW tervezési (<1%), állandósult működési(10%), időleges működési hibák(70-80%), illetve szoftver tervezési (10-20%) hibák.
==13. Kérdés==
'''Milyen technikákat javasol állandósult hardver működési hibák kezelésére?''' 
* Kettőzés - diagnosztikai támogatás + átkapcsolás
* TMR (Triple-modular redundancy) - szavazás (kritikus elem a szavazó)
* NMR (N-modular redundancy) - többségi szavazás, MTFF ??
 
'''Milyen szinten valósulhat meg egy hardverben a többszörözés (mondjon példákat is)?''' 

* számítógép (Szerver) szint - lazán csatolt, pl. ''SUN HA cluster'' / ''HA Linux''
* kártya szint - futás idejű átkonfigurálás, pl. ''compctPCI'' / ''HDD''
* alkatrész szint - szorosan csatolt, pl. ''TMR'' / ''önellenőrző áramkör''
==14. Kérdés==
'''Milyen technikákat javasol szoftver tervezési hibák kezelésére?''' 
Az állandósult hibáknál az ismételt végrehajtás nem segít, ezért a redundáns modulok eltérő tervezést igényelnek, azonos specifikációjú variánsok beépítése szükséges.
 
'''Mit értünk variánsok alatt?''' 
Eltérő algoritmussal, adatstruktúrával rendelkeznek. Más fejlesztői környezetet, programnyelvet érdemes használni. A fejlesztési fázist elszigetelten végrehajtani.
 
'''Milyen módszerek ismeretesek a variánsok végrehajtásának koordinálására?''' 
N-verziós programozás, javító blokkok
 
'''Hogyan működik az N-verziós programozás (NVP) technika?''' 
Aktív redundanciát biztosít, ugyanazon bemenettel indítja el a variánsokat és szavazással döntik el a kimenetet. {{InLineImageLink|Infoalap|BeagyRendEllTechnika|NVP.PNG}}
 
'''Hogyan működik a javító blokkok (RB) technikája?''' 
Passzív redundanciát biztosít, csak hiba esetén aktiválódik a variánsok elfogadhatósági ellenőrzése, hiba esetén kerül végrehajtásra a tartalék variáns. 
{{InLineImageLink|Infoalap|BeagyRendEllTechnika|JB.PNG}}
 
'''Miért szükséges állapotmentés az RB végrehajtása során?''' 
Az éppen aktuálisan futtatandó variánst tárolja (ha már az első két redundánst megvizsgáltuk és mindkettő megbukott az elfogadhatósági ellenőrzésen, akkor a következő variánst kell futtatni - vagy hibajelzést adni, ha elfogytak az indítható variánsok)
 
'''Hasonlítsa össze az NVP és az RB technikát a hibadetektálás módja, a tolerálható hibák száma, a hibakezelés módja és a legrosszabb esetben érvényes végrehajtási idő szempontjából!''' 

{| border="1"
|*tulajdonság*||*NVP*||*RB*
|-
|hibadetektálás módja||szavazással,relatív||elfogadhatósággal, abszolút
|-
|tolerálható hibák #||N/2-1||N-1
|-
|hibakezelés módja||maszkolás||helyreállítás
|-
|legrosszabb végrehajtási idő||leglassabb variáns/timeout||hibák számától függ
|}

==15. Kérdés==
'''Milyen fázisai (feladatai) vannak az időleges hardver működési hibák kezelésének?''' 
* hibadetektálás
* hibahatások felismerése
* helyreállítás
* meghibásodás (hibaok) kezelése
 
'''Milyen alkalmazásfüggetlen hibadetektálási technikákat ismer?''' 
operációs rendszer szintjén: illegális utasítások felismerése, védelmi szintek
//alkalmazásfüggő: időzítés ellenőrzése, visszahelyettesítés az algoritmusba, hihetőségvizsgálat
 
'''Hogyan mérhető fel a hibahatások terjedése?''' 
A detektálás ideje alatt a hibák terjedhetnek, ennek behatárolása az interakciók követésével érhető el: a bemenetek ellenőrzése, naplózás, atomi jellegű műveletek használata.
 
'''Milyen technikákat ismer a hiba utáni helyreállításra?''' 
előrelépő helyreállítás (előre figyelembe vett hibák esetén használható - a hiba és a hatás függvénye szerint veszi fel az új állapotot) és visszalépő helyreállítás(korábban hibamentes állapot visszaállítása, független a hibától, állapotmentés szükséges) minden ábrázolható állapottérben.
 
'''Hasonlítsa össze az előrelépő és a visszalépő helyreállítást a hibaazonosítás megkívánt pontossága, a hibaállapot javításának módszere és a megvalósítás alapfeltétele szempontjából! Melyik helyreállítási technika kedvezőbb szigorúan valósidejű rendszerekben?''' <br

{| border="1"
|*tulajdonság*||*előrelépő*||*visszalépő*
|-
|hibaazonosítás megkívánt pontossága|| a hiba és hibahatás függvénye dönt || minimális - független a hibától
|-
|hibaállapot javításának módszere|| hiba és hibahatás kezelése || visszatérés hibamentes állapotba
|-
|megvalósítás alapfeltétele|| előre ismert hiba || állapotmentés
|}
==16. Kérdés==
'''Mondjon példákat az információ és az idő redundanciára!''' 
* '''információ''' hibajavító kódolás ''Hamming kód, Reed-Solomon''
* '''idő''' utasítás újrapróbálás (retry)
 
'''Hasonlítsa össze a tanult hibatűrő technikák tipikus időigényét!''' 

{| border="1"
| TMR ||<|| NVP ||<|| javító blokkok
|-
|hibajavító kód||<||állapotmentés+helyreállítás||<||elosztott állapot mentés+helyreállítás
|-
|újrapróbálás ||<|| újratöltés ||<|| újraindítás
|}
 
'''Milyen költségtényezők befolyásolják egy hibatűrő technika kidolgozását?''' 
kialakítási költség + üzemeltetési költség
 
'''Hogyan tesztelhető a hibatűrés?''' 
* '''szoftver''' állapot megváltoztatása, regiszterek manipulálása
* '''hardver''' meghibásodás létrehozása - buszjel kényszerítés, nehézion besugárzás
* '''hibrid''' ??

-- [[AdamO|adamo]] - 2006.06.25.

[[Category:Infoalap]]

Ellenőrző kérdések - Ellenőrzéstechnika - Laptörténet

Unknown user: Új oldal, tartalma: „{{GlobalTemplate|Infoalap|BeagyRendEllTechnika}} Felhasznált irodalom: [http://www.mit.bme.hu/oktatas/targyak/vimm3244/jegyzet/2006/majzik_vazlat2006.pdf majzik_vazl…”