„Valós idejű és biztonságkritikus rendszerek - MEGSZŰNT” változatai közötti eltérés
aNincs szerkesztési összefoglaló |
|||
(11 közbenső módosítás, amit 4 másik szerkesztő végzett, nincs mutatva) | |||
1. sor: | 1. sor: | ||
{{Tantárgy | {{Tantárgy | ||
| név = Valós idejű és biztonságkritikus rendszerek | | név = Valós idejű és<br>biztonságkritikus rendszerek | ||
| tárgykód = VIMIM151 | | tárgykód = VIMIM151 | ||
| szak = villany MSc | | szak = villany MSc | ||
21. sor: | 19. sor: | ||
}} | }} | ||
=Ismertető= | |||
==2010== | |||
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 [http://ecos.sourceware.org/ecos/docs.html eCos operációs rendszer] alatt az [http://bri.mit.bme.hu/?l=mitmot&p=modules&typ=0&id=27&ord=0&ordd=0&ipp=5&pg=0 ARM-os mitmóttal] és a hozzá adott [http://bri.mit.bme.hu/?l=mitmot&p=modules&typ=0&id=29&ord=0&ordd=0&ipp=5&pg=0 rádiós kártyával] kellett megoldani: | 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 [http://ecos.sourceware.org/ecos/docs.html eCos operációs rendszer] alatt az [http://bri.mit.bme.hu/?l=mitmot&p=modules&typ=0&id=27&ord=0&ordd=0&ipp=5&pg=0 ARM-os mitmóttal] és a hozzá adott [http://bri.mit.bme.hu/?l=mitmot&p=modules&typ=0&id=29&ord=0&ordd=0&ipp=5&pg=0 rádiós kártyával] kellett megoldani: | ||
* PAR protokoll megvalósítása rádiós linken | * PAR protokoll megvalósítása rádiós linken | ||
32. sor: | 32. sor: | ||
Gyakorlatok a félév során (2010-ben): | 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. ([[ | * 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ógia_(MIT)|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. | * 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 | * 2*fél alkalom biztonságkritikus témakörből feladatmegoldás gyakorlás | ||
[http:// | [http://static2.docstoccdn.com/docs/89342792/Deadline-monotonic-analysis Az órán is elhangzó Deadline Monotonic Analysis a diánál bővebben] | ||
[http://www.alldatasheet.com/datasheet-pdf/pdf/134654/ETC/IA4420.html A kommunikációs IC adatlapja] | [http://www.alldatasheet.com/datasheet-pdf/pdf/134654/ETC/IA4420.html A kommunikációs IC adatlapja] | ||
=Vizsgák= | =Vizsgák= | ||
==2010.06.07 | |||
{{Rejtett | mutatott='''2013.06.07''' | szöveg= | |||
Valósidejű részből (összesen 15 pont): | |||
# DMA feladat, rekurzív képlet (3 pont) | |||
# szemafor műveletek (2 pont) | |||
# flexray - mintavételezés, többségi szavazás (2 pont) | |||
# earliest deadline first ütemező (2 pont) | |||
#* algoritmus | |||
#* Milyen paramétereket kell ismerni az ütemezéshez? | |||
#* preemptív? | |||
# óraszinkronizáció - Master-slave algoritmus (2 pont) | |||
# stack méretét hogyan határozzuk meg (2 pont) | |||
# OS és RTOS indulás összehasonlítása (2 pont) | |||
Biztonságkritikus részből (összesen 15 pont): | |||
# megbízhatósági tényező, elektronikus eszközöknél ábra -> kádgörbe (2 pont) | |||
# szoftvertervezési hibák kijavítása | |||
#* N-verziós programozás, javítóblokkok tulajdonságai (4 pont) | |||
# ok-következmény analízis (2 pont) | |||
# megbízhatósági blokkdiagram - párhuzamos esetre, megbízhatóság kiszámítása (2 pont) | |||
# egy C nyelvű függvényt teszteljük táblázatban lévő bemenetekkel … (kicsit más, mint a mintapélda) (5 pont) | |||
#* hány független út van? | |||
#* döntési ág, utasítás fedettség | |||
#* ha szükséges, akkor kiegészítés | |||
}} | |||
{{Rejtett | mutatott= '''2010.06.14'''|szöveg= | |||
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. | |||
}} | |||
{{Rejtett|mutatott='''2010.06.07'''|szöveg= | |||
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) | # Deadline Monotonic Analysis nem blokkoló taszkokkal és oprendszer időigényét nem figyelembe véve.(3 pont) | ||
77. sor: | 128. sor: | ||
A vizsga ideje 60 perc volt. | A vizsga ideje 60 perc volt. | ||
}} | |||
[[Kategória:Villamosmérnök MSc]] | |||
[[ |
A lap jelenlegi, 2015. február 21., 16:28-kori változata
Ismertető
2010
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
Valósidejű részből (összesen 15 pont):
- DMA feladat, rekurzív képlet (3 pont)
- szemafor műveletek (2 pont)
- flexray - mintavételezés, többségi szavazás (2 pont)
- earliest deadline first ütemező (2 pont)
- algoritmus
- Milyen paramétereket kell ismerni az ütemezéshez?
- preemptív?
- óraszinkronizáció - Master-slave algoritmus (2 pont)
- stack méretét hogyan határozzuk meg (2 pont)
- OS és RTOS indulás összehasonlítása (2 pont)
Biztonságkritikus részből (összesen 15 pont):
- megbízhatósági tényező, elektronikus eszközöknél ábra -> kádgörbe (2 pont)
- szoftvertervezési hibák kijavítása
- N-verziós programozás, javítóblokkok tulajdonságai (4 pont)
- ok-következmény analízis (2 pont)
- megbízhatósági blokkdiagram - párhuzamos esetre, megbízhatóság kiszámítása (2 pont)
- egy C nyelvű függvényt teszteljük táblázatban lévő bemenetekkel … (kicsit más, mint a mintapélda) (5 pont)
- hány független út van?
- döntési ág, utasítás fedettség
- ha szükséges, akkor kiegészítés
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.
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 , amiből )
- 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