VIK Wiki

„Valós idejű és biztonságkritikus rendszerek - MEGSZŰNT” változatai közötti eltérés

← Régebbi szerkesztés
VizuálisWikiszöveges
Szikszayl (vitalap | szerkesztései)
4 274 szerkesztés
aNincs szerkesztési összefoglaló
 
(12 közbenső módosítás, amit 4 másik szerkesztő végzett, nincs mutatva)
1. sor: 1. sor:
{{GlobalTemplate|Villanyszak|MSCValosIdBiztKritR}}
{{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. ([[MSCSWTech|Szoftvertechnológiával]] közösen)
* 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://www.embedded.com/2000/0006/0006feat1.htm Az órán is elhangzó Deadline Monotonic Analysis a diánál bővebben]
[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):
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)
# DMA feladat, rekurzív képlet (3 pont)
** Worst case válaszidő képlet
# szemafor műveletek (2 pont)
** Példa taszkokra (egyik "interrupt"-nak elnevezve) válaszidő számítás
# flexray - mintavételezés, többségi szavazás (2 pont)
** Annak eldöntése, hogy a határidők tarthatók-e
# earliest deadline first ütemező (2 pont)
* Intervallum metszéses elosztott óraszinkronizáció ismertetése (3 pont)
#* algoritmus
* 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 &delta; = 10<sup>-5</sup>, a kommunikáció késleltetése 0,5 ms, ennek szoftverre visszavezethető jittere +/-0,2 ms.
#* Milyen paramétereket kell ismerni az ütemezéshez?
** Mekkora a szinkronizáció után maradó óra bizonytalanság? (h = 0,5+0,2 = 0,7 ms)
#* preemptív?
** 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>)
# óraszinkronizáció - Master-slave algoritmus (2 pont)
* Earliest deadline first ütemező.
# stack méretét hogyan határozzuk meg (2 pont)
** Algoritmus ismertetése.
# OS és RTOS indulás összehasonlítása (2 pont)
** 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):
Biztonságkritikus részből (összesen 15 pont):
* Meghibásodási ráta
# megbízhatósági tényező, elektronikus eszközöknél ábra -> kádgörbe (2 pont)
** definíció
# szoftvertervezési hibák kijavítása
** ábra elektronikus alkatrészeknél
#* N-verziós programozás, javítóblokkok tulajdonságai (4 pont)
** megbízhatósági fv. meghibásodási rátával felírva
# ok-következmény analízis (2 pont)
* Integrációs teszt: alulról felfele ill. fentről lefele összehasonlítás
# megbízhatósági blokkdiagram - párhuzamos esetre, megbízhatóság kiszámítása (2 pont)
** Melyiknél kell teszt csonkot írni és miért?
# egy C nyelvű függvényt teszteljük táblázatban lévő bemenetekkel … (kicsit más, mint a mintapélda) (5 pont)
** Melyiknél kell végrehajtót írni és miért?
#* hány független út van?
** Egy blok megváltoztatása esetén mit kell újratesztelni?
#* döntési ág, utasítás fedettség
** Hogyan kombináljuk a kettőt futtató rendszer integrációjánál?
#* ha szükséges, akkor kiegészítés
* Tranziens HW Hiba kezelése
}}
** Az órán tárgyalt hibakezelési módok ismertetése (Előrelépő/visszalépő)
{{Rejtett | mutatott= '''2010.06.14'''|szöveg=
** 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):
Valósidejű részből (összesen 15 pont):
# DMA-s feladat
# DMA-s feladat
104. sor: 90. sor:


A vizsga ideje 60 perc, sietni kell.
A vizsga ideje 60 perc, sietni kell.
}}
{{Rejtett|mutatott='''2010.06.07'''|szöveg=
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 &delta; = 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)
#* 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.
#* 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.
}}


[[Category:Villanyszak]]
[[Kategória:Villamosmérnök MSc]]
A lap eredeti címe: „https://vik.wiki/Valós_idejű_és_biztonságkritikus_rendszerek_-_MEGSZŰNT”