Beágyazott információs rendszerek - Órai jegyzet 2009
Ez az oldal a korábbi SCH wikiről lett áthozva.
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.
1. előadás
A tárgy adatai
- Előadó: Péceli Gábor peceli@mit.bme.hu
- A tárgy: VIMA359 ( VIMM3244 az elődtárgy )
- Követelmény: 5 HF ( kb. 2 hetente) + ZH + vizsga
- Tárgy honlapon megvannak, papíron kell beadni őket
- 5 HF * 10 pont, ennek szumma 30%-a kell, vagyis 15pont
- Ehhez jön még a ZH, amin 40% a követelmény ( márc. 26, csütörtök 10-12h)
- Vizsga: 05.20, 05.27, 06.10, 06.17 (szerda), 100 perc
Bevezető
A Beágyazott Információs Rendszer ( továbbiakban BIR ) a fizikai/kémiai/biológiai környezetével intenzív (valós idejű) információ kapcsolatban lévő számítógépes rendszer.
- Autonóm: képes alkalmazkodni a környezet változásaihoz
- pl. akkor is le kell szállnia a repülőnek, ha az egyik motorja megsérül, nem írhatja ki, hogy please reinstall...
- szolgáltatás biztos
- ember élet múlhat rajta
- láthatatlan: beépül a mindennapokba, nem mint számítógép kerülünk vele interakcióba
- hanem pl. mint fék pedál és ABS
Gyakori, hogy elosztott a rendszer, azaz lokálisan szerény, de globálisan bőséges erőforrások állnak rendelkezésre. Ez jelentős redundanciát, sok elemi egységet jelent.
Követelmények
A BIR két fő feladatköre:
- A környezet identifikálása: mérése, észlelése
- A környezet befolyásolása
Fontos plusz feladat még, ami az autonómiához és szolgáltatásbiztonsághoz tartozik, hogy a rendszer elemei figyeljék a rendszer állapotát is, ismerjék fel a változásokat (pl. meghibásodott alkatrészeket), és befolyásolják a rendszert, hogy az továbbra is el tudja látni a feladatát. Pl. a repülőgép processzorai nem csak a légörvényeket figyelik, hanem azt is, hogy mikor száll el egy motor vezérlő processzor, ekkor ugye őt ki kell kapcsolni és át kell térni másik vezérlőre, vagy ha nincs, az egész motort leállítani és újraszámolni a tolóerőket.
Környezettől függően kétféle válaszidő kritériumot fogalmazhatunk meg a rendszerünkkel szemben. A kemény valósidejű rendszernek (Hard Real Time - HRT) ms-os nagyságrendben kell választ adnia. Itt úgy tekintjük, hogy a késett válasz egyenértékű a rossz válasszal, mindkettő egyformán tragédiához vezethet. Pl. Késő bánat, ha akkor jön meg a szelep kinyitó parancs, amikor a tartály már felrobbant. Itt a WorstCase esetre tervezünk, minden körülmények között időben válaszolnia kell a rendszernek.
A másik válaszidő kritérium a puha valósidejű rendszer (Soft Real Time - SRT), ahol álltalában másodperces nagyságrendűek az elvárt válaszidők. Ha itt nincs adott időn belül válasz az baj, de nem tragédia. Itt átlagos értékre tervezünk, költséghatékonysági okokból. Pl. Egy ATM ( pénzfelvevő) automata soft realtime, mert az ügyfél szomorú lesz, ha sokat kell várnia, de nem hal meg! Worst-case-re tervezni egy ATM rendszert horribilis költségű lenne, úgy nem is érné meg megvalósítani. Inkább néha kicsit többet kell várni, meg lehal a rendszer, de legalább általában van.
Kétféle megközelítéssel lehet rendszert tervezni: eseményvezérelt és idővezérelt. Az előbbi esetben a rendszer alapból nem csinál semmit, és bizonyos külvilágbeli események válthatnak ki reakciót. Az utóbbi esetben a rendszer adott időközönként ellenőrzi, történt-e valami. Az eseményvezérelt azért nem alkalmazható hard realtime-ot megkövetelő feladat esetén, mert ha időegység alatt több esemény történik, mint amit a rendszer kezelni tud, akkor a torlódás miatt leromlik a válaszidő, nem lehet garantálni, hogy adott időn belül reagál pl. egy vészjelzésre. Ezért ilyenkor mindig idővezérelt rendszert kell használni.
- esemény- és idővezérelt rendszerek összehasonlítása:
Az autóipar 70-80% költséget tesz az elektronikára, AUDI A8-ban 2000 jel van, amit 50-100 mikroprocesszor dolgoz fel. Itt fontos követelmény, hogy az eszközök PlugAndPlay legyenek, a különböző komponensek azonosítsák magukat, ne kelljen minden esetben össze-konfigurálni őket, legyen elég összedugni. A repülőgépeknél is fontos a PlugAndPlay, de ott van forrás az együttes rendszer tesztelésére.
Egyre fontosabb szempont a bir-ekkel szemben a komponálhatóság, azaz, hogy plusz egység hozzáadása a rendszerhez ne befolyásolja az eredeti egységek működését, azok továbbra is képesek legyenek ellátni a feladatukat.
Az elnevezésről
Több angol elnevezés van (minden szakterület előállt a saját nevével). A triviálisan visszafordított Embedded Information System rossz, mert az Information System angolban nem elektronikai, hanem információfeldolgozó rendszert jelent. Az Embedded System magában mikroelektronikát jelöl. Az elterjedt elnevezések:
- Pervasive Computing
- Ubiquitous computing
- Ambient Intelligence
Egy népszerű alkalmazási terület, ami most nagy EU-s támogatást is élvez az az Ambient Assisted Living ( AAL wikipedia cikk ).
-- Cassus - 2009.02.25.
-- Cassus - 2009.03.01.
2. előadás
Esemény és idővezérelt rendszer példa
Legyen egy példa, nézzünk egy CAN buszt! Legyen 10 db mérő egységünk, amik a technológiai valamit figyelik. Szenzoronként 40 jellel, amik egy 100kbit/sec -es buszon van összekötve egy vészjelző egységgel.
Eseményvezérelt esetben (CAN/ET): 44bit overhead + 1byte (egy bit lenne, de csak byteot lehet átvinni) + 4 bit intermessage gap = 56bit egyetlen vészjelzés.
100kbit/s esetén 100.000/56 csomag/sec. Nekünk 100ms-on belül riasztani kell, azon belül be kell érkeznie a jelzésnek => 180 vészjelzés érhet max be, de nekünk 400 is lehet egyszerre!
Idővezérelt esetben (CAN/TT): 44bit overhead + 4byte + 4bit gap : 88 bit alatt 40 jel kommunikációja zajlik le, 100ms időlimittel 10.000/88 = 110 szenzort tudnánk így időben kiszolgálni.
példa 2.
Ugyanez a példa másként leírva. TODO összefésülni.
Legyen 10 egységünk, mindegyik 40 független egybites jelet kap (pl. egy rendszerben lehetséges 400 esemény bekövetkeztét figyelik). Egy közös 100kbps buszra rá van kötve a 10 egység és egy ALARM egység. A 400 jelből ez utóbbi dönti el, hogy kell-e riasztani, és előírás, hogy ezt 100ms-on belül eljusson hozzá a releváns információ. Feltesszük, hogy a CAN nevű protokollal kommunikálnak a buszon: ennek üzenetei 44 bit fejlécet és legalább 8 bit adatot tartalmaznak, az üzenetek közt pedig 4 bit intermessage gap van.
Eseményvezérelt esetben, ha egy egység egyik jele megváltozik, azonnal küld egy üzenetet. Mivel 8 bitnél nem lehet kevesebb az adat (akkor sem, ha 1 bites eseményt akarunk küldeni), ezért (az intermessage gap-et is beleszámolva) 56 bitesek lesznek az üzenetek. Ha a 400 jel közel azonos időpontban megváltozik, ez 400 esemény, ami 400*56=22400 bit forgalom. Ezt kellene 0.1s-en belül elküldeni, de ennyi idő alatt csak 10000 bit fér rá a csatornára, tehát szerencsétlen esetben több, mint kétszeres idő alatt jutna csak el a riasztást kiváltó információ az ALERT-hez.
Idővezérelt esetben mindegyik egység mind a 40 jelét elküldi 0.1s-onként. Ez 44+40+4=88 bites üzeneteket jelent, ilyen üzenetből a 0.1s-os ütem alatt 100000*0.1/88=113-mat el lehetne küldeni, nekünk pedig már 10 is elég. Tehát idővezérelt rendszerrel bőven teljesíthető a követelmény.
Elosztott rendszerek
Elosztott rendszer estén minden node-nak eltérő órája van, mindegyiknek csak lokális ismeretei vannak a világról, eltérő ideig tart az üzenet átvitel közöttük is.
Pl. lehet olyan, hogy az A és B szerveren az E1 és E2 események ebben a sorrendben következnek be, de az eltérő késleltetések miatt az egyik kliensnél fordított sorrendben érkeznek meg.
TODO KÉP
A leggyakrabban használt megoldás az időbélyegzés, vagyis hogy minden üzenethez hozzácsatoljuk az elküldési idejét.
Lehetetlenségi tétel
Fontos ezért kölcsönösen szinkronizálni az órákat. Veszteséges csatornán nem lehet tökéletesen szinkronizálni, erre példa a két hadsereg problémája: Egy völgy két oldalán van a kék hadsereg két része, a völgyben a pirosak
A kék hadsereg bármelyik része támad, elveszti a csatát, ha ugyanakkor nem támad a másik oldal is.
Az "A" jelű kék hadsereg üzenetet küld a "B" jelű oldalnak, hogy reggel 9-kor támadnak.
Ekkor "A" nem tudja, hogy az üzenetet "B" megkapta vagy sem, tehát nem támadhat. "B" miután megkapta az üzenetet, nyugtázza, és visszaküld egy futárt "A"-hoz. Ha a futár megérkezett, "A" tudja, hogy az üzenete megérkezett. "B" azonban nem tudja, hogy a visszaigazolása megérkezett-e "A"-hoz, így nem támadhat biztonságosan. Ez a játék a végtelenségig folytatható. Az utolsó üzenet megérkezését soha nem tudjuk ellenőrizni. ( http://e-oktat.pmmf.hu/szallitasi_reteg )
Bizánci hiba
Bizánci hiba jelensége az, amikor elosztott rendszerben egy node attól függően eltérő választ ad, hogy ki kérdezi (hazudós akár szándékosan akár hiba következtében). Például ha 3 szereplő akarja összeegyeztetni az óráit, és az egyik hazudós, akkor furcsa dolgot tapasztalunk. Mutasson A órája 4:00-t, B-é 4:05-t, C pedig hazudós, ha A kérdezi, akkor 3:55-t mond, ha B, akkor 4:10-et. Amikor A szinkronizálni akarja az óráját, megkérdezi a másik kettőt, mit mutatnak az ő óráik, és ennek az átlagára áll be. (4:05 + 3:55) / 2 = 4:00, azaz úgy látja pontos az órája. B-vel hasonlóképp. Mindketten azt hiszik, hogy jól jár az órájuk, holott egyiké sem.
A bizánci általánosítható több szereplőre is, akkor oldható meg, ha 3k+1 egységből legfeljebb k db hibás.
TODO wikipediáról link
Akciókésleltetés
Nézzünk egy példát. Legyen egy ipari folyamat, ahol van egy A jelzésű riasztó egység, egy B beavatkozó, egy C érzékelő és egy D operátor. Az operátor képes vezérelni a beavatkozót és a riasztót, a beavatkozó által vezérlet folyamat eredményét az érzékelő érzékeli, és riasztást kérhet az A egységtől.
Az operátor kiad egy utasítást a beavatkozónak és ezzel egyidejűleg letiltja a riasztást. (Lásd Csernobil). Az a kérdés, hogy melyik úton gyorsabb a jel, a DBCA vagy a DA úton. Ha nem ér oda időben a riasztást letiltó jel, akkor riaszt az A pedig nem kellene.
TODO kép
A probléma megoldásához megjelöljük, hogy mennyi az üzenetek minimális (dmin) és maximális (dmax) beérkezési ideje. Az üzenet D-ből küldése után az A alarm egység még dmax ideig kellene, hogy várjon, de nem tudja, hogy a D mikor küldte el az üzenetet, ezért a küldés időpontját fel kell tüntetni.
Ha viszont nincs időbélyeg, akkor is ki kell várni a dmax időt a küldéstől számítva. Az A azonban nem tudja, hogy mennyi időt utazott az üzenet, ezért az érkezés után dmax-dmin időt vár még, így biztosítva azt, hogy az egyszerre küldött üzenetek biztos mind megérkeztek, mielőtt feldolgozná őket.
Ha esetleg dmax ideig tartott volna az üzenet megérkezése és még dmax-dmin időt várunk, akkor ezzel 2*dmax - dmin idő telik el az üzenet feladása és a reakció között, ezzel kell számolni a válaszidőnél, mint legrosszabb eset. Kommunikációs protokolltól függően a dmin és dmax széles skálán változhat.
A hard és soft real-time összehasonlítása
| hard real-time | soft real-time | |
| válaszidő | ms nagyságrendű | s nagyságrendű |
| csúcsterhelésre hogyan reagál | mindig működik | befolyásolja a környezetét (a terhelést csökkentendő), átlagterhelésre van tervezve |
| munka, vezérlés ütemezése | a fizikai környezettel szinkron | |
| biztonság | autonóm hibadetektálás, javítás | offline javítás (pl. pénzkiadóból elfogy a pénz) |
| adatfájlok | kisméretű, rövid ideig tárolt adatok | nagyméretű, sokáig tárolt adatok |
| redundancia | többszörözött, párhuzamosan működő rendszerek (példa: vadászrepülőben 7 független vezérlőrendszer, fizikailag különböző helyen a gépben) | időbeni (logok, mentett adatok alapján utólag helyreállítható a konzisztencia) |
Nem mindegy még, hogy meghibásodás esetén teljesen leáll a rendszer vagy van vészforgatókönyv, vészrendszer. Például levegőben lévő repülőnél ciki, ha valami hibánál kék halált dob a rendszer és leállítja a motorokat.
3. előadás
Ha a BIR-ben hiba esetén minden leáll, akkor a rendszer Fail-Safe. Ha hibakezelés van hiba esetén, akkor FailOperational.
Bevezetés az ütemezésbe, jelölések
Az időpontokat kisbetűvel, az időtartamokat nagybetűvel jelöljük.
- a - arrival time
- s - start time
- f - finishing time
- d - deadline time
- C - computation time (amennyi konkrétan számolja)
- R - response time (beérkezéstől válaszig)
- D - deadline time (beérkezéstől a határidőig)
- T - period time (két kérés között)
D-C = L : laxity (lazaság, mennyire flexibilis a végrehajtás indítása)
Ütemezés
Három féle taszkot különböztetünk meg ütemezési szempontból.
- Periodikus
- Aperiodikus
- Sporadikus
Az első kettővel foglalkozunk. A sporadikus összevissza érkező kérések, de tudunk adni olyan T-t, amin belül nem érkezik új kérés. A sporadikus kezelése olyan, mint a periodikusé, ha worst-case feltételezéssel élünk.
Periodikus - ciklikus végrahajtás.
TODO digitális spektrumanalizátor példát kidolgozni
Egyéb
random linkek:
http://en.wikipedia.org/wiki/Rate-monotonic_scheduling http://www.netrino.com/Embedded-Systems/How-To/RMA-Rate-Monotonic-Algorithm
