Irányítási szoftverek tervezése KMAIS11TNK Tematika Beágyazott rendszerek felépítése Beágyazott rendszerek szoftver vonatkozásai Beágyazott rendszerek hardver vonatkozásai Beágyazott rendszerek tervezése Beágyazott rendszerek Olyan számítógépes eszközök, amelyek alkalmazás orientált célberendezésekkel, ill. komplex alkalmazói rendszerekkel szervesen egybeépülve azok autonóm működését biztosítják, vagy segítik. [IEE Guidelines]. A beágyazott rendszerek szerteágazó monitorozási, vezérlési, ill. szabályozási feladatokat látnak el. Közös jellemzőjük a fizikai környezettel való intenzív információs kapcsolat. A beágyazott rendszer, mint alkalmazás orientált célberendezés egy chip es rendszerek (systems on a chip) újrahasználható részegységek (design re use, IP) integrált érzékelők és beavatkozók mikrovezérlők és programozható logikai eszközök FPGA és DSP processzoros részegységek/kártyák hardver szoftver együttes tervezés a tervezést és a tesztelést segítő technológiák Beágyazott információs rendszerek integrált alkalmazói rendszerek új minőség, újszerű szolgáltatások autonóm viselkedés: flexibilitás és adaptáció mérések beágyazott rendszerekben intelligens működési mechanizmusok új rendszertervezési elvek új rendszerfejlesztési technológiák Új felfogás és interpretáció műszerek, mint beágyazott információs rendszerek CALIN műszerek (kész kalibráló laboratórium) 1 / 32
az oszcilloszkóp ma (univerzális jelanalizátor) beágyazott információs rendszerek, mint műszerek monitorozási funkciók: működési jellemzők,... diagnosztika: állapotfelmérés, hibadetektálás,.. Tervezés, gyártás és üzemeltetés a szolgáltatások komplexitásának kezelése a szolgáltatások minőségi kérdései hardver szoftver együttes tervezés építkezés komponensekből konfigurálhatóság (tervezéskor: at design time) tesztelhetőség szolgáltatásbiztonság újrakonfigurálhatóság (üzem közben: at runtime) A hierarchikus és több aspektusú modellezések szerepe komplexitás kezelés a specifikáció teljesítése, mint kényszer kielégítés kvantitatív és kvalitatív jellemzések válaszidő követelmények teljesítése hibadetektálás és lokalizálás támogatása aktív modellek létrehozása Minőségbiztosítás a tervezés fázisában hardver és szoftver együttes tervezés a szolgáltatásbiztonság, mint tervezési szempont biztonsági és hibatűrési képességek kialakítása szoftver biztonság és hibatűrés elosztott rendszerek biztonsága és hibatűrése adatbázisok biztonsága és hibatűrése időkezelés biztonsága és hibatűrése Termékminősítés Általában ún. teljesítmény (performance) jellemzők alapján Országh szerint: Performance: megtétel, végrehajtás, véghezvitel, teljesítés, elvégzés; előadás, eljátszás; 2 / 32
teljesítmény; teljesítőképesség; beágyazott rendszerek méréstechnikája 3 / 32
Valós idejű rendszerek Az operációs rendszerek egy speciális fajtája, amelyben minden egyes rendszerhívás egy előre meghatározott időn belül garantáltan végrehajtásra kerül, a konkrét körülményektől függetlenül. A nem valós idejű operációs rendszerek esetében ilyen korlát nem létezik, és a rendszerhívások a körülményektől függően elméletileg rendkívül sok ideig is eltarthatnak, ami azonban problémát jelenthet bizonyos szigorú időzítést és azonnali rendelkezésre állást igénylő feladatok esetében. A valós idejű operációs rendszereket általában beágyazott eszközökben alkalmazzák, amelyek a helyes és megbízható működéséhez elengedhetetlenül szükségesek speciális jellemzői. Beágyazott rendszerek felépítése A beágyazott rendszerekkel szemben támasztott főbb követelmények: funkcionális, időzítési, megbízhatósági. Ezen követelmények hatása a tervezésre. Funkcionális követelmények Berendezéssel szembeni követelmények Környezeti feltételek Statikus követelmények Villamos követelmények Mechanikai követelmények Időzítési követelmények Real time rendszerek követelményei Eseménykezelés Szinkron események Aszinkron események Belső időzítők Külső időzítőkhöz történő szinkronozálás Megbízhatósági követelménynek Forrasztások száma Elemek száma Csatlakozása száma Pergésmentesítése 4 / 32
Áramkör típus TTL, CMOS Beágyazott rendszerek szoftver vonatkozásai I. Időkezelés. Időkezelés főbb feladatai. Idő és sorrend. Kemény és puha valós idejű rendszerek. Hibás állapot kezelés. Vezérlési módok. Időmérés eszközei és módszerei, időnormáliák. Idő reprezentálása. Időkényszerek. Szinkronizálás, órarendszerek. Master slave algoritmusok. Elosztott szinkronizációs algoritmusok. Valós idejű rendszerek modellezése. Időkezelés Időkezelés főbb feladatai. Idő és sorrend. Kemény és puha valós idejű rendszerek. Hibás állapot kezelés. Időkezelés Példa: a relativisztikus hatás bemutatására: elosztott rendszerekben az időben egymást követő eseményekről érkező híradások érkezési sorrendje megváltozhat. Megjegyzés: Egy esemény a rendszer állapot detektálható, pillanatszerű változása. Az időkezelés főbb feladatai: az idő reprezentációja (time representation) következtetés idővel (temporal reasoning) az idő információ kinyerése (how to gain knowledge of time) az időbeni tulajdonságok menedzselése (management of temporal properties) Az idő és sorrend/rendezés kérdése: Az időbeni sorrend (temporal order): a folytonos, valós idő modellezhető időpillanatok végtelen [T] halmazaként, amely a következő tulajdonságokkal jellemezhető: (1) [T] rendezett halmaz, azaz ha p és q két időpillanat, akkor vagy egybeesnek, vagy p megelőzi q t, vagy q megelőzi p t, és ezek a lehetőségek egymást kizárják. (2) [T] sűrű halmaz, azaz van legalább egy q időpillanat p és r között, ha p és r nem esik egybe. A kauzális (oksági) sorrend (causal order): többet fejez ki, mint az időbeni sorrend. Egy lehetséges definíció: Ha egy e1 esemény egy e2 esemény oka, akkor e1 kis megváltozása együtt jár e2 kis megváltozásával, de e2 kis megváltozása nem szükségképpen jár e1 kis 5 / 32
megváltozásával. továbbítási sorrend (delivery order): gyengébb az előzőekhez képest; azt garantálja, hogy az egyes csomópontok számítógépei az események sorozatát ugyanabban a továbbítási sorrendben látják. Kemény és puha valós idejű rendszerek: kemény valós idejű rendszer (hard real time system (HRT)): katasztrofális következményekkel jár, ha nem tartjuk az időkorlátot (pl. járművek vezérlése). puha valós idejű rendszer (soft real time system (SRT), on line system): az eredmény értékes az időkorláton túl is, de az idővel degradálódik (pl. tranzakciós rendszerek). HRT és SRT jellemzése különböző szempontok szerint: válaszidő (response time): HRT esetében ms, vagy annál kevesebb (pl. légzsák), az emberi beavatkozás lehetősége kizárt, a rendszer autonóm működésű és biztonságos kell, hogy legyen. SRT esetén a válaszidő másodperc nagyságrendű, az időkorlát túllépése nem okoz katasztrófát. viselkedés csúcsterhelés esetén (peak load performance): HRT esetén jól definiált kell, hogy legyen. Tervezéskor biztosítani kell, hogy a számítógépes rendszer minden szituációban az időkorláton belül teljesítse feladatát, hiszen a HRT rendszerek éppen azáltal valósítják meg a velük szemben megfogalmazott elvárásokat, hogy még a ritkán előforduló csúcsterhelések idején is jósolható módon viselkednek. Az SRT rendszereket átlagos teljesítmény jellemzőkre tervezzük, a ritkán előforduló csúcsterhelések következményeit gazdaságossági megfontolásból elviseljük. az ütem vezérlése (control of pace): A HRT rendszernek minden körülmények között szinkronban kell lennie környezetének (irányított objektum, ill. az emberi operátor) állapotával. Az SRT rendszerek befolyásolják környezetüket, ha nem képesek eleget tenni feladatuknak (egy tranzakciós rendszer például megnöveli a válaszidejét). biztonság (safety): A biztonság kritikusságának mértékétől függően sokféle feladat merülhet fel tervezési időben. Autonóm hibadetektálási mechanizmusokat kell kidolgozni, amelyek valamilyen talpra állítási (recovery) akciót indítanak az adott alkalmazás által diktált időviszonyok mellett. az adatfájlok mérete (size of data files): HRT rendszerek kisméretű adatfájlokon dolgoznak, amelyek valós idejű adatbázist alkotnak. Ezek jellemzője az adatintegritás rövid idejűsége, mert az idő múlásával az adatok jelentős része aktualitását veszíti. Az SRT rendszerekben éppen ellenkezőleg a hosszú idejű adatintegritás fontos. 6 / 32
a redundancia típusa (redundancy type): SRT rendszerekben (pl. tranzakciós rendszerek) hiba esetén a számításokat visszagörgetik a legutolsó ellenőrzési ponthoz, amikor még biztosan helyes volt a működés és onnan kezdik a talpra állítást. HRT rendszerek esetén ez a stratégia csak korlátozottan használható mert: (1) az időkorlát tartása nehéz, mert a visszagörgetéshez szükséges idő nem, vagy nehezen jósolható, (2) a környezetet befolyásoló utasítás nem tehető meg nem történtté, (3) az ellenőrzési pontnál érvényes adatok az idő múlásával érvényüket veszítik. adat integritás (data integrity): HRT: rövid idejű, SRT: hosszú idejű. hibadetektálás (error detection): HRT: autonóm, SRT: felhasználó által segített. Hibás állapot kezelése: (1) katasztrófa megakadályozás bénítással (fail safe). Pl. vonatok jelzőlámpa rendszere: minden lámpa piros. (2) katasztrófa elhárítás extra eszközökkel (fail operational). Pl. repülőgép: muszáj valahogy leszállni. 7 / 32
Időkezelés II. Vezérlési módok. Időmérés eszközei és módszerei, időnormáliák. Idő reprezentálása. Időkényszerek. Szinkronizálás, órarendszerek. Master slave algoritmusok. Elosztott szinkronizációs algoritmusok. Vezérlési mód: (1) esemény vezérelt (event triggered): aszinkron módon érkező megszakítások kiszolgálása, ill. ebből adódóan dinamikus ütemezés szükséges. (2) idő vezérelt (time triggered): minden kommunikáció, ill. feldolgozás központi időzítéshez (órához) szinkronizált módon történik. Időmérés eszközei és módszerei: (1) Időmérés elektronikus számlálóval: Precíz óragenerátor jelének számlálása a megmérendő ideig: Tx = N/fo, ahol N a számláló tartalma, fo pedig az órajel frekvencia. Az időmérés relatív hibája : Tx / Tx = 1/N + fo / fo, azaz a kis mérési bizonytalanságú méréshez pontos és a mérendő időhöz képest nagy frekvenciájú óra szükséges, hogy N értéke kellően nagy legyen. (2) Kettős nóniuszos időmérés: A mérendő időtartam kezdete és vége egy egy T0(1+δ) periódusidejű, kvarcpontosságú órát indít. Ezek jelét egy szabadon futó T0 periódusidejű, kvarcpontosságú óra jelével hasonlítjuk össze, figyelve a felfutó élek egybeesését. A mérendő időtartam kezdetétől az első koincidenciáig eltelt idő N1T0(1+δ), a mérendő időtartam végétől az első koincidenciáig eltelt idő N2T0(1+δ), a két koincidencia között eltelt idő, pedig N0T0. Mindezek alapján Tx = T0[± N0 + (N1 N2) (1+δ)], ahol az N0 előtti előjelet a két koincidencia időbeni sorrendje határozza meg. Az idő reprezentálása Két elmélet : (1) időpont alapú (time point based), (2) idő intervallum alapú (time interval based). Valós idejű rendszerekben mindkét megközelítés kell, mert egyrészt az egyes események által kiváltott aktivitások végrehajtási idejével kalkulálni kell, másrészt ha csak (minden szituációban elegendően hosszú) intervallumokkal operálunk, akkor a végrehajtás indokolatlanul hosszú lesz. 8 / 32
Időkényszerek Lehetséges megadásuk: (Id, Taft(cond1), cid, fid, Tbef(cond2)) ahol: Id a folyamat (végrehajtható objektum) azonosítója, Taft(cond1) annak az eseménynek a megadása, amely után az Id folyamatnak a végrehajtását meg kell kezdeni, cid a számítási idő korlát az Id folyamat minden egyes végrehajtására, fid a számítás végrehajtásának gyakorisága/frekvenciája, Tbef(cond2) annak az eseménynek a megadása, amely előtt be kell fejezni az Id folyamat futtatását. Előfordulási intervallum: Off line számítás: On line számítás: [Taft(cond1), Tbef(cond2)] cond2 = CId = cond2 = CId < Időszolgáltatás és óraszinkronizáció: Az idő forrását órának nevezzük. Az i edik óra a valós idő egy Ci (t) függvénye. Referencia óra: Ci (t) = t; t Helyes óra: az i edik óra helyes (correct) t0 ban, ha Ci (t0) = t0 Pontos óra: az i edik óra pontos (accurate) t0 ban, ha δci (t)/δt = 1; t= t0 Ha egy óra pontatlan egy adott időpillanatban, akkor azt mondjuk, hogy csúszik abban az időpontban. Óra szinkronizálás: Miért van rá szükség? (1) a rendezés támogatására, (2) az idő pontosabb ismerete érdekében A szinkronizálás egy óra frissítés (update): Ci (ti) F(Ci1 (ti1), Ci2 (ti2),..., Cik (tik)) ahol F jelképezi a frissítési mechanizmust k órára alapozva. A frissítési függvénynek monotonnak kell lenni, hogy a lokális rendezések egyértelműek maradjanak. 9 / 32
Óra rendszerek típusai: Központi óra rendszerek (central clock systems): egy pontos óra szolgáltatja az időt a teljes rendszer számára, a többi órát a rendszer a normális működés alatt figyelmen kívül hagyja, hibatűréshez készenléti (standby) redundanciát alkalmaznak, pontos módszer (ns en, ms en belül), költséges speciális, a processzorba integrált hardvert igényel; a központi óra állítja ezt a hardvert a megfelelő értékre; ezt minden végrehajtó folyamat olvasni tudja, a kommunikációs igény alacsony (egy üzenet frissítésenként), a GPS (global Positioning System) jó példa erre (4 órajelet sugárzó műhold, amellyel néhány ns pontossággal lehet szinkronizálni). Központilag felügyelt óra rendszerek (centrally controlled clock systems) egy (pontosnak elfogadott) master óra lekérdezi a slave órákat, megmérik az óra eltéréseket és a master korrekciót ír elő a slave számára, ha a master óra meghibásodik, akkor valamilyen választási algoritmussal új master t választanak, az átviteli időket és a késleltetéseket becsülni kell, mert lényegesen befolyásolják a mért óra eltéréseket, a kommunikációs terhelés erősebb, mint előbb. Elosztott óra rendszerek (distributed clock systems) az óra szempontjából az összes csomópont homogén, ugyanazt az algoritmust futtatja, minden csomópont frissíti az óráját, miután megkapta, és helyesség szempontjából ellenőrizte/becsülte a más órák által kapott időt, a hibatűrés protokoll alapú. Ha egy csomópont kiesik, az nem befolyásolja a többi csomópont működését; észlelik a hibát, és figyelmen kívül hagyják a meghibásodott csomópontot, A kommunikációs igény viszonylag nagy, különösen akkor, ha alattomos hibák esetén is a robusztusság követelmény. 10 / 32
Idő normáliák (standardok) Elosztott, valós idejű rendszerekben kettőt használnak elterjedten: Nemzetközi Atomi Idő (Temps Atomique Internationale, TAI) Alapja egy ún. atomóra: Cesium 133 atom által (specifikált módon) kisugárzott frekvencia 9 192 631 770 ed része 1 sec. A TAI által biztosított időskála kronoszkópikus, azaz folytonos. Univerzális idő (Universal Time Coordinated, UTC) A Föld és a Nap mozgásából, azaz asztronómiai megfigyelésekből vezették le. 1972 be lépett a GMT (Greenwich Mean Time) helyébe azzal, hogy a másodperc a TAI szerint értendő. A Föld mozgása enyhén szabálytalan, ezért alkalmanként beszúrnak egy szökő másodpercet. 1958 január elsején a TAI és az UTC (egy megegyezés alapján) ugyanazt mutatta. Azóta az UTC mintegy 30 másodperccel eltérést szedett fel. Mivel ezeket a Bureau Internationale de l Heure szükség szerint szökő másodpercekkel korrigálja, a tényleges eltérés mindig ismert és kis mértékű. Megjegyzés: a szökő másodperc beillesztése a naptári év váltás pillanatában veszélyes: az 1996. január 1 én 00:00:00 kor egy másodperccel visszaállított óra még egyszer léptette a napot megadó számlálót és ezért a következő másodpercben az óra január 2 át mutatott. Idő formátum legelterjedtebb: Network Time Protocol (NTP). Ez a formátum 8 bájtot használ, amelyből 4 az UTC másodperceket, 4 pedig a másodperc törtrészét tárolja, az utóbbit 232 psec felbontásban. 1972 január elsején 00:00:00 kor 2 272 060 800.0 került a 8 bájtos számlálóba, ami az 1900. január elseje 00:00:00 tól eltelt másodpercek száma volt. Ez az ábrázolási mód 2036 ig jó (136 év a körülfordulási ciklusa). 11 / 32
Beágyazott rendszerek szoftver vonatkozásai II. Ütemezés. Periodikus, statikus, ciklikus ütemezés. Prioritás alapú ütemezés. Operációs rendszer overhead je. Memória management. Valós idejű kommunikáció. Követelmények, flow control. Kommunikációs közeg elérési protokollok. Beágyazott rendszerek szoftver vonatkozásai III. Valós idejű operációs rendszerek. Task management. Processzek közötti kommunikáció. Idő management. Hiba detektálás. Esettanulmány. Nyelvi támogatás és korlátozások. Real time programozási nyelvek. A programozási nyelvek beágyazott rendszerekben. Beágyazott rendszerek tipikus szoftver architektúrái. Beágyazott rendszerek szoftver vonatkozásai IV. A programozási nyelvek beágyazott rendszerekben. Beágyazott rendszerek tipikus szoftver architektúrái. 12 / 32
Beágyazott rendszerek hardver vonatkozásai I. Beágyazott rendszerek tipikus hardver struktúrája. Perifériák (AD/DA, kijelzők, billentyűzet, kommunikációs csatornák). Beágyazott rendszerek hardver vonatkozásai II. Periféria illesztés HW szempontjai. Regiszter, memóriába ágyazott, IO. Periféria szinkronizálása. Beágyazott rendszerek feldolgozó egységei (controller, DSP, FPGA). Integrált perifériák. PERIFÉRIAKEZELÉSI MÓDSZEREK ESZKÖZSZINTŰ KEZELÉS: a perifériális eszköz fizikai sajátosságainak megfelelő illesztési felületet és utasításkészletet biztosítunk. Kis rendszerek, beépített rendszerek esetén előnyös. Jól kihasználhatók a processzor és a periféria sajátosságai. LOGIKAI KEZELÉS: általánosított illesztési felületeket és beviteli/kiviteli eljárásokat alkalmazunk. ESZKÖZSZINTŰ PERIFÉRIAKEZELÉS FELTÉTEL NÉLKÜLI BEVITEL/KIVITEL A processzor és a periféria nincs szinkronizálva. (A processzornak és a perifériának mindig rendelkezésre kell állnia.) Egyszerű IN és OUT utasítások. JELZŐBITES (FELTÉTELES) BEVITEL/KIVITEL Az együttműködésért kizárólag a processzor felelős. (A processzornak mindig rendelkezésre kell állnia.) ESZKÖZSZINTŰ PERIFÉRIAKEZELÉS 2 SZEMAFOROS (FELTÉTELES) BEVITEL/KIVITEL Kölcsönös szinkronizálás (kézfogásos üzemmód). (Mindkét fél képes a másikat bevárni, illetve a másikat várakozásra kényszeríteni.) Nem minden periféria sebessége befolyásolható. 13 / 32
ESZKÖZSZINTŰ PERIFÉRIAKEZELÉS 3 JELZŐBITES BEVITEL/KIVITEL ESZKÖZSZINTŰ PERIFÉRIAKEZELÉS 4 SZEMAFOROS BEVITEL/KIVITEL ESZKÖZSZINTŰ PERIFÉRIAKEZELÉS 5 SZEMAFOROS BEVITEL/KIVITEL 2 14 / 32
15 / 32
LOGIKAI PERIFÉRIAKEZELÉS Sokféle perifériális eszköz: általánosított beviteli/kiviteli eljárások és illesztési felület. I/O PROCESSZORra, ill. CSATORNÁra alapozott kezelés: rögzített feladatú autonóm modulok, felszabadítják a processzort a periféria részletes kezelése alól; I/O processzor: átviteli műveletekre optimalizált + általános adatfeldolgozási képesség. LOGIKAI PERIFÉRIAKEZELÉS 2 16 / 32
LOGIKAI PERIFÉRIAKEZELÉS 3 KÖZVETLEN TÁROLÓ HOZZÁFÉRÉS (Direct Memory Access, DMA) TÁRSPROCESSZOROS RENDSZEREK 17 / 32
MULTIPROCESSZOROS RENDSZEREK 1 A mikroprocesszorok árának jelentős csökkenése lehetővé teszi, hogy azokat egy bonyolult rendszerben univerzális építőelemekként használjuk. MULTIPROCESSZOROS RENDSZER: RENDSZER egymástól független (rész)feladatok konkurens feldolgozását végző többprocesszoros rendszer. Két esemény konkurens, ha egyik sem tudja kauzálisan befolyásolni a másikat. MULTIPROCESSZOROS RENDSZEREK 2 MULTIPROCESSZOROS RENDSZEREK 3 18 / 32
19 / 32
MULTIPROCESSZOROS RENDSZEREK 4 MULTIPROCESSZOROS RENDSZEREK 5 LAZÁN CSATOLT RENDSZER: üzenet kommunikáció, minden processzornak saját operációs rendszere van. Egyszerű, lassú. SZOROSAN CSATOLT RENDSZER: kommunikáció közös erőforráson keresztül, egyetlen operációs rendszer van. Bonyolult, gyors. LAZÁN CSATOLT RENDSZEREK KOMMUNIKÁCIÓS ALRENDSZEReken keresztül megvalósított, logikailag pont pont összeköttetés 20 / 32
LAZÁN CSATOLT RENDSZEREK 2 LAZÁN CSATOLT RENDSZEREK 3 LAZÁN CSATOLT RENDSZEREK 4 A kommunikációs alrendszer a logikai pont pont összeköttetést leképzi a fizikai átviteli közegre. A fizikai átviteli közeg korlátozott átviteli kapacitást biztosít, így TORLÓDÁSVEZÉRLÉS TORLÓDÁSVEZÉRLÉS kell. Minden processzor kap egy hitelértéket és akkor küldhet ki üzenetet, ha hitelértéke > 0. Probléma: hitel elveszésének kezelése elvileg megoldhatatlan nagy rendszerekben. 21 / 32
MULTIPROCESSZOROS RENDSZEREK SZOROSAN CSATOLT RENDSZER: kommunikáció közös erőforráson keresztül, egyetlen operációs rendszer van. Bonyolult, gyors. Alapvető változatai: crossbar szervezés, multiport memóriára alapozott szervezés, rendszersínre alapozott szervezés. SZOROSAN CSATOLT RENDSZEREK 1 Előnyök: egyszerű felépítés, könnyen átkonfigurálható. Hátrányok: csak kis rendszerek esetén használható (problémát jelent a szabadút keresés), bonyolult kapcsolókat igényel. 22 / 32
SZOROSAN CSATOLT RENDSZEREK 2 Ha a két oldalról azonos címhez kívánunk fordulni, akkor a beépített vezérlőáramkör a később jövő felé foglalt jelet ad ki. Ezt csak íráskor kell figyelembe venni, várakozásra késztetve a megfelelő oldali processzort. Az utolsó regiszterbe a jobboldali processzor valamit beír. Ezt a baloldali felé egy INT B jelzi. A baloldali processzor kiolvasva a regisztert törli a jelzést (hardver SZEMAFOR). ELŐNY: egyszerű. HÁTRÁNYOK: csak kevés (2 4) port valósítható meg a bonyolult kapurendszer miatt; csak kis rendszer építhető ki; kis memóriakapacitás valósítható meg a bonyolult kapurendszer miatt; nehéz átkonfigurálni. 23 / 32
SZOROSAN CSATOLT RENDSZEREK 3 RENDSZERSÍNRE ALAPOZOTT SZERVEZÉS Master modul: magához ragadhatja a rendszersín vezérlését. Slave modul: nem ragadhatja magához a rendszersín vezérlését; közös erőforrás(oka)t tartalmaz. A rendszer (elvben) tetszőlegesen bővíthető és átkonfigurálható. Az egyes processzorokon futó folyamatok (a slave modulban lévő) közös erőforráson keresztül kívánnak kommunikálni egymással. Fel kell oldani a közös erőforrás használatáért folyó versengést. DE: a folyamatokat futtató master moduloknak előbb hozzá kell férniük a rendszersínhez. A master modulok versenyeznek a rendszersínhez való hozzáférés jogáért: SOROS (daisy chain), vagy PÁRHUZAMOS hozzáférés vezérlés. 24 / 32
SZOROSAN CSATOLT RENDSZEREK 4 SOROS HOZZÁFÉRÉS VEZÉRLÉS Aki hozzá akar férni a rendszersínhez, az PKI := 1 et állít be (az ÓRA felfutó élekor), egyébként megismétli a PBE bemenetén vett értéket. ELŐNYE: nagyon egyszerű. HÁTRÁNYAI: A terjedési késleltetés miatt csak nagyon kis rendszerekben alkalmazható (meg kell várni, hogy baloldalról indulva az igény végigfusson a láncon). Nehéz átkonfigurálni (vezetéket kell elvágni és összekötni), de a kis rendszerek (nagy megbízhatóság) miatt erre menetközben nincs szükség. A rögzített prioritás miatt éhezés léphet fel. SZOROSAN CSATOLT RENDSZEREK 5 PÁRHUZAMOS HOZZÁFÉRÉS VEZÉRLÉS A prioritás lehet rögzített (a prioritás eldöntő egyszerű kombinációs áramkör), vagy változó (pl. körbenforgó round robin ekkor hosszabb idő alatt egyenlő esélyt kap minden modul). 25 / 32
A prioritás eldöntőt nagyobb rendszereknél elosztott módon valósítjuk meg (ellenkező esetben a rendszer kritikus része lenne). SZOROSAN CSATOLT RENDSZEREK 6 POSTAFIÓK ELV A termelőfolyamat (pl. az MM1 master modulon) adatokat ír be a feladathoz rendelt területre (postafiókba). Az adatot termelő folyamat számára közömbös, hogy ki veszi ki az adatot a postafiókból (átkonfigurálhatóság). Az adatot fogyasztó folyamat kiolvassa a postafiókot. A fogyasztó számára közömbös, hogy ki tette be az adatot a postafiókba (átkonfigurálhatóság). Egyszerre csak egyetlen folyamat férhet hozzá a postafiókhoz (kölcsönös kizárás). A postafiók használatát (KRITIKUS SZEKCIÓ) megfelelő szemafor(ok) kezelésével biztosítjuk. A szemafor vizsgálatának és átállításának oszthatatlan műveletnek kell lennie (egyébként egy másik folyamat is úgy érezhetné, hogy hozzáférhet a postafiókhoz). Ezt a P és V primitívekkel oldjuk meg (sok processzor rendelkezik ilyen hardver utasításokkal). Foglalt postafiók esetén egy ahhoz hozzáférni kívánó folyamat állandóan vizsgálja a szemafort (és használja a rendszersínt). Célszerű lehet elaltatni a várakozó folyamatot és felébreszteni, ha felszabadul a postafiók. Általános esetben egy postafiókba több folyamat tehet be adatokat, és több folyamat vehet ki adatokat. A termelési és a fogyasztási sebesség eltérése miatt torlódás léphet fel. Újabb (nem bináris) szemaforokat vezetünk be. A postafiókban leveleket helyezünk el borítékokban. A levelet tartalmazó borítékok száma TELE, az üreseké ÜRES. 26 / 32
Perifériakezelés RS 232 RS 485 CAN ISO 11898 (HIGH SPEED), ISO 11519 (LOW SPEED), CAN busz általánosan A CAN (Controller Area Network, hálózat vezérlők számára) busz egy soros adatátviteli lehetőség valós idejű alkalmazások számára. Egészen 1 Mbps (Mega Bit Per Secundum, millió jelzés másodpercenként) sebességig alkalmazható, kifinomult hibaészlelési módszereket használ, és kiemelkedő a hibatűrése. Tehát alkalmas a B és C osztályú kommunikáció bonyolítására is. Eredetileg a Bosch GmBH fejlesztette ki az 1980 as évek közepén az autóiparban jelentkező kábelezési problémák költségtakarékos megoldására, de ma már nemzetközi szabvánnyá vált az ISO 11898 (nagysebességű alkalmazások) és az ISO 11519 (kissebességű alkalmazások) számokon. Számos alacsony árú berendezés vásárolható a vezető elektronika alkatrész gyártóktól, így a járműfejlesztés sokkal olcsóbb lehet. A piacon az elektronikai alkatrészeken kívül teljes fejlesztő eszközök állnak a mérnökök rendelkezésére. Nem csak a járműveken, de az ipari irányítástechnikában, sőt megbízhatósága miatt a gyógyászati műszerek között is terjed. Alkalmazásának terjedésére jellemző, hogy 1995 ben 5,5 millió CAN chipet adtak el, 1996 ban több mint 10 milliót, 1999 ben 140 milliót. 1995 ban már több mint 3 millió CAN busz működött a járműveken, és további 6 millió ezeken kívül. Megbízhatóságára jellemző, hogy a gyógyászatban például röntgengépek vezérlésénél is használják. Hogyan működik A CAN hálózat a kétvezetékes buszból és a hozzá kapcsolódó úgynevezett csomópontokból áll. Az adatokat leíró bináris információk bitenként sorban haladnak a vezetéken. A csomóponttól származó üzenet nem tartalmazza sem a forrás, sem a cél csomópont címét, csak egy azonosítót. Ez az azonosító tehát nem a cél vagy forrás állomás, hanem az üzenet adattartalmának (például fordulatszám, járműsebesség) azonosítására szolgál. A CAN szabvány (ISO 11898) csak az ISO modell szerinti alsó két réteget írja le. A CAN 27 / 32
vezérlőkben az adatkapcsolati réteget általában a hardverben valósítják meg, így kevésbé terhelik a vezérlő számítógépet. Gyakorlati okokból ezt a réteget kétfelé választják, a logikai kapcsolat vezérlésre (Logical Link Control, LLC) és a közeg hozzáférési vezérlésre (Media Access Control, MAC). A fizikai réteg természeténél fogva mindig fizikailag megvalósított, a többi réteg lehet hardveres (azaz chipben megvalósított), vagy szoftveres (programban megvalósított). A logikai adatkapcsolat vezérlése Az adatkapcsolati réteg a felsőbb rétegtől kapott adatot ellátja egy kerettel, és így továbbítja a fizikai rétegnek. A CAN szabványnak ma két változata van használatban, amelyek az adatkeret formátumában különböznek. A 2.0A szabvány szerinti adatkeret hét mezőből áll: SOF: Start Of the Frame, keret kezdet jelző 0 bit. Ha valamely egység küldeni akar, ezt a bitet 0 ra állítja, ezzel a többi egység szinkronizálni tudja az óráját. Arbitration: Döntési mező, több részből áll. Ez szabályozza a közeghozzáférést. ID: Identifier, azonosító mezőből, ez 11 bit hosszú RTR Remote Transmission Request. Amenyiben ez a bit 1, az adatkérést jelent más egységtől, ha 0, akkor a kért adat küldését. Control: Vezérlő mező, ez is több részből áll: r0, r1: későbbi felhasználásra fenntartott két bitből és a DLC: (Data Length Code) mezőből, amely a 4 bites adathossz kód, az adatmező hosszát adja meg. Data: Adatmező, 0 8 byte ( 0 64 bit) adat, ami köré a keret épül. CAN 2.0A adatkeret formátum 28 / 32
CRC: Cyclic Redundacy Check code, 15 bites hibaellenőrző és javító kód, 1 határoló bit ACK: ACKnowledge, 2 bites nyugtamező. Az első biten tetszőleges csomópont jelezheti az adatok hibás vételét, a második bit a határoló bit. EOF: End OF Frame, 7 bites keret vége jelzés INT: INTermission, keretek közti mező, 3 db 1 es értékű bit következik, majd a busz szabaddá válik, ha nincs újabb küldendő keret. CAN 2.0B adatkeret formátum A 2.0B szabványban megváltoztatták a döntési mezőt, de ez kompatíbilis maradt a 2.0A szabvánnyal. Az első rész ugyan úgy 11 bites azonosító (ID), ezt követi az SRR (Substitute Remote Request, behelyettesítés távoli kérés) bit, egy IDE bit (ID extended, azonosító kibővítve), majd a 18 bites EID (Extended Identifier, kibővített azonosító), ezt követő rész változatlan maradt, tehát az RTR bit következik. A 2.0A szabvány szerinti CAN vezérlő nem képes a 2.0B keretek fogadására, ilyenkor hibát jelez. A 2.0B vezérlőkből két fajta létezik. passzív 2.0B vezérlők felismerik a 2.0B kereteket, nem jeleznek hibát, de nem is tudják fogadni ezeket. Ilyen esetben a buszon vegyesen mehetnek 2.0A és 2.0B keretek, de a passzív 2.0B vezérlőt tartalmazó csomópontok csak a 2.0A formájú keretekben lévő adatokat tudják elérni. A közeghozzáférés vezérlése Előfordulhat, hogy egyszerre több csomópont kíván adatot küldeni. Ezt azonban a busz kialakítása miatt egyszerre csak egy csomópont teheti meg, különben az adatok összekeverednek. Tehát a csomópontoknak valamilyen módon el kell döntenie, hogy ki férjen hozzá a kommunikációs közeghez. A CAN protokoll ehhez a döntési mezőt használja fel. Az adat legkisebb része a bit, amely 0 vagy 1 lehet. A CAN esetében a 0 a domináns, míg az 1 a receszív. A csomópontok akkor is figyelik a 29 / 32
hálózatot, amikor küldenek. Ha egyszerre két csomópont küld, azt addig nem lehet észlelni, amíg egyforma adatokat küldenek. Azonban ha az egyik 0 át, a másik 1 et küld, akkor mindkettő 0 át fog olvasni (a 0 a domináns bit). Ekkor az az állomás, amelyik 1 et küldött, észleli a különbséget, és abbahagyja a forgalmazást. Ez a vetélkedés természetesen csakis a döntési mezőben működik, a keret többi részében nem engedélyezett. Eredménye képen a kisebb azonosítóval rendelkező adat elsőbbséget élvez. Elvileg még egy probléma adódhat! Amikor az egyik egység egy adatkérési keretet küld, és pontosan ekkor a másik egység küldi is a választ. Ekkor a két keret összekeveredne, mivel az azonosítójuk azonos. Azonban az adatkérésnél az RTR bit 1, a válaszkeretben viszont 0, ebből tudja az adatot kérő egység, hogy a válasz pont most érkezik, és abbahagyja a kérés keret forgalmazását. A hozzáférés szabályozásában tehát nem csak az azonosító, de az RTR és a 2.0B hálózatoknál az SRR bit is részt vesz. A döntési mező utolsó bitje az RTR bit. Ennek értéke 1, ha adatkérésre vonatkozik, és 0, ha az adatkérésre válasz. Mivel a 0 a domináns bit, így a válasz csomagok előnyt élveznek a kérésekkel szemben. A 2.0B keretek SRR bitje mindig 1, és azon a helyen áll, ahol a 2.0A keretek nem használt 0 értékű bitjei vannak. Ebből következik, hogy azonos alap azonosítóval (első 11 bit) rendelkező adatok közül a 2.0A típusú keret előnyt élvez a 2.0B típusúval szemben. Most már csak egy probléma maradt megoldatlan! Bizonyos CAN csomópontok alvó üzemmódba léphetnek. Akkor ébrednek csak fel, amikor adatot akarnak küldeni vagy fogadni, de ehhez meg kell találniuk, hogy mikor történik a döntési mező forgalmazása. A megoldás A megoldást a keret vége jelzés és a bitbeszúrás technikája adja. A keret vége jelzés 7 db 1 es értékű bit. Azért, hogy ez egyértelműen felismerhető legyen, a CAN szabvány előírja, hogy az adatmezőben minden 5 db egyforma értékű bit után be kell szúrni egy ellenkező értékűt, kivéve a keretvég jelzésben. A fogadó csomópontok minden 5. egyforma bit utáni bitet automatikusan kiszedik a folyamból, így az már nem is látható a fentebbi rétegek számára. Beszúrt bit Hibát jelző keret: Error Frame 30 / 32
Ha egy vevő felismeri a továbbított üzenet hibás voltát, (és mivel az adó egyben vevő is legalább ő észlelni fogja ezt), akkor leadja ezt az üzenetet. Ez 6 egymás utáni domináns bit kiküldésével teszi. Ez normál adatkeretben nem fordulhat elő, így minden résztvevő értesül arról, hogy hibás a busz. Ha más egység is egyetért ezzel, akkor még egy hibajelzést beültet, végül 8 receszív bittel zárul az üzenet. error passive Előfordulhat, hogy a hibaüzenet egyetlen vevő részéről állandóan ismétlődik, ami kiváltja az adó automatikus üzenetismétlését is. Ha ez az állapot 30 bitidőre állandósul, akkor ez a vevő letiltja a saját hibajelzések küldését (error passive), így lehetővé teszi a busz (esetleg még nem sérült) részén az adatforgalmazást Túlterhelést jelző keret Amennyiben valamelyik vevő központi egységének nem áll módjában az érkezett adatok feldolgozása, akkor ezzel az üzenettel megakadályozhatja, hogy a következő, neki szóló üzenet felülírja az előzőleg vett, de még feldolgozatlant. Ehhez 6 domináns és 8 receszív bitet küld ki, de a keretek közötti időzítés más, mint a hibajelzésnél, így a többi résztvevő meg tudja különböztetni. A fizikai kialakítás A kétvezetékest buszt általában árnyékolt vagy árnyékolatlan csavar érpáras (shielded /unshielded twisted pair) vezetékből készítik. Lapos kétvezetékes kábel (telefon kábel) is használható, de ez nagyobb rádiófrekvenciás zavart bocsát ki, és érzékenyebb is arra. Szélsőséges körülmények A szabvány szerint javasolt, hogy a CAN chipek képesek legyenek forgalmazni akkor is, ha a két kábel közül az egyik elszakad vagy zárlatos lesz. Általában olyan a CAN busz kialakítása, hogy ha a mindkét kábel egy ponton sérül, akkor a két különálló CAN busz működőképes lesz. Az ISO 11898 szabvány nem korlátozza a kábelhosszat, de ez függ a busz sebességétől. Az ajánlott kábelhosszak a sebesség függvényében a következők: 1000 kbps 40 m, 500 kbps 100 m, 250 kbps 200 m, 125 kbps 500 m. Rugalmasság és bővíthetőség Mivel a keretek nem tartalmaznak címeket, csak adat azonosítókat, az egész rendszer rendkívül rugalmas. A tisztán adatfogadó csomópontok minden további nélkül csatlakoztathatók a rendszerhez. Új jeladóval vagy funkcióval könnyen bővíthető a rendszer, de ha a meglévő csomópontokon ezeket az adatokat fel kívánják használni, akkor azon a szoftver cseréje szükséges. A rendszer rendkívül előnyös abban az esetben, ha egy jeladó által mért adatot több, esetleg opcionális vezérlőegység kívánja felhasználni. Az egyszer elküldött adatot egyszerre tetszőleges számú csomópont vehetni. A CAN re épülő magasabb szintű hálózati protokollok 31 / 32
A CAN busz előnyei akkor használhatók ki igazán, ha az alkalmazók megegyeznek olyan dolgokban is, amelyet az ISO 11898 nem ír elő. Egyik legfontosabb dolog a különböző azonosítók jelentése. Az ISO 11898 csak annyit biztosít, hogy a kisebb azonosítóval rendelkező adat nagyobb prioritást élvez. Ha a járműgyártók megegyeznek egy állandó azonosító adat összerendelésben, akkor a beszállítók nagyobb darabszámban, tehát olcsóbban tudnak előállítani alkatrészeket, és ezek akkor is csereszabatosak lehetnek, ha más gyártótól származnak. Viszont a rendszereik nyitottabbak, így nehezebben tudják biztosítani a márkaszervizeik előnyét. Gyártói előírások A gyártók néhány ilyen előírást létrehoztak már. Az elsők között volt a BMW gyár CAN11 nevű rendszere, amely a 2.0A s 11 bites azonosítókon alapult. A 11 bit összesen 2048 lehetséges kombinációt engedélyez, ami egy egy járművön elegendő, de általános esetben már kevésnek bizonyul. Ezért hozták létre a 2.0B s változatot 29 bites azonosítóval, amely már több mint 536 millió kombinációt tesz lehetővé. Ezt kihasználva az európai járműgyártók egy OSEK nevű szabványon dolgoznak, a USA ban a SAE pedig létrehozta a SAE J1939 es számú, úgynevezett "Big Red Book" ot, azaz a nagy piros könyvet. Céljuk a CAN azonosítók logikus és egységes kiosztása. A CAN buszt nem csak a járműtechnikában, de az iparban is használják. Ott is alakultak ki magasabb szintű protokollok, mint például a DeviceNet. 32 / 32