„Valós idejű és biztonságkritikus rendszerek - MEGSZŰNT” változatai közötti eltérés
Ugrás a navigációhoz
Ugrás a kereséshez
a (Gmate átnevezte a(z) Linkek lapot a következő névre: Valós idejű és biztonságkritikus rendszerek) |
|||
| 42. sor: | 42. sor: | ||
==2010.06.07== | ==2010.06.07== | ||
Valósidejű részből (összesen 15 pont): | Valósidejű részből (összesen 15 pont): | ||
| − | + | * Deadline Monotonic Analysis nem blokkoló taszkokkal és oprendszer időigényét nem figyelembe véve.(3 pont) | |
** Worst case válaszidő képlet | ** Worst case válaszidő képlet | ||
** Példa taszkokra (egyik "interrupt"-nak elnevezve) válaszidő számítás | ** Példa taszkokra (egyik "interrupt"-nak elnevezve) válaszidő számítás | ||
** Annak eldöntése, hogy a határidők tarthatók-e | ** Annak eldöntése, hogy a határidők tarthatók-e | ||
| − | + | * Intervallum metszéses elosztott óraszinkronizáció ismertetése (3 pont) | |
| − | + | * Futókhoz időmérőt vizsgálunk. Adott két rádiós node, amelyek időt mérnek, egyik a startnál, másik a célnál. A startnál lévő a "mester", ő mondja meg a célnál lévőnek, hogy mennyi az idő. Ezt a célban lévő node változtatás nélkül elfogadja és beállítja az óráját. Az órák driftje δ = 10<sup>-5</sup>, a kommunikáció késleltetése 0,5 ms, ennek szoftverre visszavezethető jittere +/-0,2 ms. | |
** Mekkora a szinkronizáció után maradó óra bizonytalanság? (h = 0,5+0,2 = 0,7 ms) | ** Mekkora a szinkronizáció után maradó óra bizonytalanság? (h = 0,5+0,2 = 0,7 ms) | ||
** Milyen gyakran kell szinkronizálni, hogy az együttfutás 2 ms-on belül maradjon? (a két órában a drift ellenkező előjelű lehet, ezért <math> h + 2{\delta}T_{sync} < 2 ms </math>, amiből <math> T_{sync} < 65 s</math>) | ** Milyen gyakran kell szinkronizálni, hogy az együttfutás 2 ms-on belül maradjon? (a két órában a drift ellenkező előjelű lehet, ezért <math> h + 2{\delta}T_{sync} < 2 ms </math>, amiből <math> T_{sync} < 65 s</math>) | ||
| − | + | * Earliest deadline first ütemező. | |
** Algoritmus ismertetése. | ** Algoritmus ismertetése. | ||
** Milyen paramétereket kell ismerni az ütemezéshez? | ** Milyen paramétereket kell ismerni az ütemezéshez? | ||
** preemptív-e? | ** preemptív-e? | ||
| − | + | * Hard RT és soft RT összehasonlítása csúcsterhelés alatti viselkedés szempontjából (2 pont) | |
| − | + | * szemafor műveletek | |
Biztonságkritikus részből (összesen 15 pont): | Biztonságkritikus részből (összesen 15 pont): | ||
| − | + | * Meghibásodási ráta | |
** definíció | ** definíció | ||
** ábra elektronikus alkatrészeknél | ** ábra elektronikus alkatrészeknél | ||
** megbízhatósági fv. meghibásodási rátával felírva | ** megbízhatósági fv. meghibásodási rátával felírva | ||
| − | + | * Integrációs teszt: alulról felfele ill. fentről lefele összehasonlítás | |
** Melyiknél kell teszt csonkot írni és miért? | ** Melyiknél kell teszt csonkot írni és miért? | ||
** Melyiknél kell végrehajtót írni és miért? | ** Melyiknél kell végrehajtót írni és miért? | ||
** Egy blok megváltoztatása esetén mit kell újratesztelni? | ** Egy blok megváltoztatása esetén mit kell újratesztelni? | ||
** Hogyan kombináljuk a kettőt futtató rendszer integrációjánál? | ** Hogyan kombináljuk a kettőt futtató rendszer integrációjánál? | ||
| − | + | * Tranziens HW Hiba kezelése | |
** Az órán tárgyalt hibakezelési módok ismertetése (Előrelépő/visszalépő) | ** Az órán tárgyalt hibakezelési módok ismertetése (Előrelépő/visszalépő) | ||
** Melyik mód esetén fontosabb a hiba pontos detektálása? (Előrelépőnél, mert abból következtet a helyesre) | ** Melyik mód esetén fontosabb a hiba pontos detektálása? (Előrelépőnél, mert abból következtet a helyesre) | ||
| − | + | * Helyreállító blokkok | |
** Blokkvázlat | ** Blokkvázlat | ||
** Mikor használható a módszer? (A modul eredményének helyességére meghatározható egy vizsgálati kritérium) | ** Mikor használható a módszer? (A modul eredményének helyességére meghatározható egy vizsgálati kritérium) | ||
** Példa: 2 variáns, első p1, második p2 valószínűséggel hibáz, a hihetőség vizsgálat a jó eredményt pe valószínűséggel hibásnak ítéli, rosszat nem téveszt jónak. Felrajzolandó az eseményfa. | ** Példa: 2 variáns, első p1, második p2 valószínűséggel hibáz, a hihetőség vizsgálat a jó eredményt pe valószínűséggel hibásnak ítéli, rosszat nem téveszt jónak. Felrajzolandó az eseményfa. | ||
** Mi azoknak a forgatókönyveknek a valószínűsége, amiknél nem elérhető a szolgáltatás? | ** Mi azoknak a forgatókönyveknek a valószínűsége, amiknél nem elérhető a szolgáltatás? | ||
| − | + | * volt még egy feladat | |
A vizsga ideje 60 perc volt. | A vizsga ideje 60 perc volt. | ||
| − | |||
==2010.06.14== | ==2010.06.14== | ||
A lap 2013. június 1., 17:31-kori változata
Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.
Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.
Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót
Első féléves tárgy, az elejéből sokminden ismerős lesz azoknak, akik BSc-n is beágyazott rendszerekkel foglalkoztak. A félév közepe táján adják ki a valósidejű részhez kapcsolódó csoportos (2-6 fő) nagyházit. 2010 tavaszán a következő témák voltak meghirdetve, amiket eCos operációs rendszer alatt az ARM-os mitmóttal és a hozzá adott rádiós kártyával kellett megoldani:
- PAR protokoll megvalósítása rádiós linken
- Megszakításos API írása a rádiós kártyához
- CSMA-CA protokoll megvalósítása a rádiós kártyával, a chipen található DQD státusz bit felhasználásával
- Elosztott óraszinkronizáció "Maximális hiba minimalizálása" algoritmussal
- Elosztott óraszinkronizáció "intervallummetszés" algoritmussal
- Bizánci típusú hibákat kiküszöbölő elosztott óraszinkronizáció
- Futó fény
A működő házikat be kell mutatni, és egy kb. 4 oldalas doksit kell hozzá készíteni.
Gyakorlatok a félév során (2010-ben):
- 4 alkalom ARM-os gyakorlat, ahol az eCos-szal, valamint a kommunikációs API-val és az ARM-os panellel ismerkedés a cél. (Szoftvertechnológiával közösen)
- 1 alkalom demonstrációs mérés, ahol az ARM-os panelre írt egyszerű programot vizsgáltunk, egyrészt objektumorientált megvalósítás, SW állapot lekódolása szempontjából, másrészt a végén egy teszt fedettség monitorozó program demonstrációjára került sor.
- 2*fél alkalom biztonságkritikus témakörből feladatmegoldás gyakorlás
Az órán is elhangzó Deadline Monotonic Analysis a diánál bővebben
Vizsgák
2010.06.07
Valósidejű részből (összesen 15 pont):
- Deadline Monotonic Analysis nem blokkoló taszkokkal és oprendszer időigényét nem figyelembe véve.(3 pont)
- Worst case válaszidő képlet
- Példa taszkokra (egyik "interrupt"-nak elnevezve) válaszidő számítás
- Annak eldöntése, hogy a határidők tarthatók-e
- Intervallum metszéses elosztott óraszinkronizáció ismertetése (3 pont)
- Futókhoz időmérőt vizsgálunk. Adott két rádiós node, amelyek időt mérnek, egyik a startnál, másik a célnál. A startnál lévő a "mester", ő mondja meg a célnál lévőnek, hogy mennyi az idő. Ezt a célban lévő node változtatás nélkül elfogadja és beállítja az óráját. Az órák driftje δ = 10-5, a kommunikáció késleltetése 0,5 ms, ennek szoftverre visszavezethető jittere +/-0,2 ms.
- Mekkora a szinkronizáció után maradó óra bizonytalanság? (h = 0,5+0,2 = 0,7 ms)
- Milyen gyakran kell szinkronizálni, hogy az együttfutás 2 ms-on belül maradjon? (a két órában a drift ellenkező előjelű lehet, ezért [math] h + 2{\delta}T_{sync} \lt 2 ms [/math], amiből [math] T_{sync} \lt 65 s[/math])
- Earliest deadline first ütemező.
- Algoritmus ismertetése.
- Milyen paramétereket kell ismerni az ütemezéshez?
- preemptív-e?
- Hard RT és soft RT összehasonlítása csúcsterhelés alatti viselkedés szempontjából (2 pont)
- szemafor műveletek
Biztonságkritikus részből (összesen 15 pont):
- Meghibásodási ráta
- definíció
- ábra elektronikus alkatrészeknél
- megbízhatósági fv. meghibásodási rátával felírva
- Integrációs teszt: alulról felfele ill. fentről lefele összehasonlítás
- Melyiknél kell teszt csonkot írni és miért?
- Melyiknél kell végrehajtót írni és miért?
- Egy blok megváltoztatása esetén mit kell újratesztelni?
- Hogyan kombináljuk a kettőt futtató rendszer integrációjánál?
- Tranziens HW Hiba kezelése
- Az órán tárgyalt hibakezelési módok ismertetése (Előrelépő/visszalépő)
- Melyik mód esetén fontosabb a hiba pontos detektálása? (Előrelépőnél, mert abból következtet a helyesre)
- Helyreállító blokkok
- Blokkvázlat
- Mikor használható a módszer? (A modul eredményének helyességére meghatározható egy vizsgálati kritérium)
- Példa: 2 variáns, első p1, második p2 valószínűséggel hibáz, a hihetőség vizsgálat a jó eredményt pe valószínűséggel hibásnak ítéli, rosszat nem téveszt jónak. Felrajzolandó az eseményfa.
- Mi azoknak a forgatókönyveknek a valószínűsége, amiknél nem elérhető a szolgáltatás?
- volt még egy feladat
A vizsga ideje 60 perc volt.
2010.06.14
Valósidejű részből (összesen 15 pont):
- DMA-s feladat
- Worst case válaszidő képlete
- Példa taszkokra (egyik "interrupt"-nak elnevezve), ki kellett számítani a worst-case válaszidőt
- Annak eldöntése, hogy a határidők tarthatók-e
- Mi a bizánci típusú hiba? Milyen algoritmussal védekezünk ellene?
- Hasonlítsa össze az RTOS és ált. OS-t rendszer indulása szempontjából!
- Mi a deadlock? Rajz! Hogy védekezünk ellene a pillanatnyi öröklés algoritmussal?
- Mennyire jó RT a stack memória foglalás? A fgv-ek újrahívhatóak-e? Memória kezelés szempontjából biztonságos?
- Mailbox küldésnél mi az előnye és hátránya, ha csak az üzenet tartalmának pointerét küldjük, és magát a tartalmat nem? (előny: kevesebb memóriafoglalás, hátrány: tartalom elveszhet, ha a memóriaterület valamiért felülíródik a másik task általi kiolvasás előtt)
- Előnyös-e egy RT rendszerben, ha a proci kihasználtsága 100%? Miért? (Nem, mert egyrészt a tápforrás szűk keresztmetszet lehet, másrészt a proci élettartalma csökken.)
Biztonságkritikus részből (összesen 15 pont):
- Szoftver tervezési hibák kezelése:
- típusai, ezek rövid leírása (N-verziós progr., javító blokkok)
- melyiknél mennyi a tolerált hiba
- Hardver, szoftver, hibrid monitorozás összehasonlítása
- melyiknél hogy történik a triggerelés, felműszerezés, regisztrálás
- melyiknél jelentkezik az ún. szemantikai hézag
- Az ok-következmény analízis rövid leírása, mi az előnye az eseményfa analízishez képest?
- Add meg a megbízhatóság képletét, ha TMR-rel kezelt hardver hibáról van szó. Meg volt adva r a modulokra, és r a szavazóra.
- Adva volt egy C nyelvű programkód (szinte ugyanaz, mint a példában, csak az if-en belül volt a switch, továbbá a feltétel ÉS feltétel volt), és pár futtatott teszt. Mekkora a teszt fedettség (útra, döntési ágra, feltétel kombinációra), hány független út bejárásával tesztelhető a kódrészlet, ha szükséges, egészítsd ki a teszt sorozatot.
A vizsga ideje 60 perc, sietni kell.
