Ugrás a tartalomhoz

Autóipari beágyazott rendszerek

Dr. Fodor Dénes, Speiser Ferenc (2014)

Pannon Egyetem

4. fejezet - Kommunikáció

4. fejezet - Kommunikáció

Egy beágyazott rendszernek adatcserét kell folytatnia több más részegységgel illetve eszközzel. A különböző beágyazott rendszerek különböző kommunikációs interfészekkel tartják egymással vagy más rendszerekkel a kapcsolatot. Gyakran megkülönböztetik a rövid távolságon belül - például egy közös NYÁK-on (Nyomtatott ÁramKör) - elhelyezkedő kontrollerek közötti kommunikációról (ilyenre szokták tipikusan alkalmazni az SPI és az I2C protokollokat), valamint nagyobb távolságon (több méter vagy még nagyobb távolságon) történő kommunikációt (ilyenre szokták tipikusan alkalmazni a CAN, FlexRay, MOST, stb. protokollokat).

A különböző kommunikációs protokollokat többféleképpen is szokták kategorizálni. Az egyik ilyen csoportosítás a kommunikáció irányára vonatkozó kategorizálás. Ezek szerint lehet beszélni a szimplex kommunikációról, melynél minden jel illetve jelzés, információ csak és kizárólag egy irányba áramlik. A kétirányú kommunikációnál lehet fél-duplex (half-duplex) valamint teljes-duplex (full-duplex) kommunikációról beszélni. Előbbinél egy időben csak egy irányba használható a kommunikációs csatorna, azaz a két átviteli irány azonos időben szimultán nem használható. Az utóbbinál megengedett az egy időben mindkét irányba történő kommunikáció.

Egy másik kategorizálási lehetőség, hogy a kommunikáció során van-e összehangoló órajel, vagy nincs. Az előbbi a szinkron (pl.: SPI, I2C), míg az utóbbi az aszinkron (pl.: RS-232, CAN) kommunikáció. Aszinkron kommunikáció esetén nincs közös órajel, ami az adást és a vételt összehangolja. Ezért a kommunikáció csak előre meghatározott sebességeken történhet, ezért adó és vevő közötti „szinkronizációhoz” nagyon pontos időzítés kell, valamint a buszon levő összes eszköz esetén ugyanazokat a beállításokat kell alkalmazni.

Az autóiparban leggyakrabban alkalmazott kommunikációs protokollok

Az autóiparban számos különböző protokollt alkalmaznak az eltérő igények kielégítésére. Ezek közül talán a legismertebbek és legelterjedtebbek az SPI, I2C, UART/RS-232, CAN, LIN, FlexRay, CANopen és a MOST.

UART és RS-232

A mikrokontrollerek között az egyik legelterjedtebb kommunikációs protokoll az UART (Universal Asynchronous Receiver Transmitter), mely soros, aszinkron átvitelt tesz lehetővé. Alapértelmezetten három vezeték szükséges a működéséhez: egy fogadó (RXD), egy küldő (TXD), valamint egy földelés (GND) vezeték. A vonalak feszültségszintjei a szabványos TTL (Tranzisztor - Tranzisztor Logika) jelszinteknek felelnek meg, azaz a logikai 0, vagyis az alacsony jelszint: 0 V – 0,8 V közötti tartománynak, míg a logikai 1, azaz a magas jelszint a 2,4 V – 5 V közötti feszültségtartománynak felel meg.

Az RS-232 (Recommended Standard 232) nagyon hasonlít az UART-hoz, ezért gyakran együtt tárgyalják őket. Ugyanakkor lényeges különbségek is vannak, elsősorban a feszültségszintekben. A hagyományok szerint a két kommunikációs felet DTE-nek (Data Terminal Equipment) valamint DCE-nek (Data Communication Equipment) szokták nevezni, mely elsősorban a lábkiosztásnál lényeges. Az RS-232 esetén minimum három vezeték szükséges - akárcsak az UART esetében - , ugyanakkor definiál több kiegészítő vezetéket is, melyek elsősorban a kifejlesztés eredeti céljára utalnak, vagyis a modemek, terminálok összekapcsolására:

  • DCD (Data Carrier Detected): A DCE kapcsolódik a külső kommunikációs (telefon) vonalhoz.

  • RXD (Receive Data): A DCE felől a DTE felé adatok küldésére szolgáló vonal.

  • TXD (Transmit Data): A DTE felől a DCE felé adatok küldésére szolgáló vonal.

  • DTR (Data Terminal Ready): Azt jelzi, hogy a DTE jelen van-e.

  • GND (Ground): Földelés.

  • DSR (Data Set Ready): Azt jelzi, hogy a DCE készen áll az adatok illetve parancsok fogadására.

  • RTS (Request To Send): Azt jelzi, hogy a DTE adatot szeretne küldeni a DCE felé.

  • CTS (Clear To Send): Azt jelzi, hogy a DCE kész az adatok fogadására.

  • RI (Ring Indicator): A DCE hívó jelet észlelt a bejövő kommunikációs (telefon) vonalon.

A fenti vonalak közül manapság inkább már csak a fogadó (RXD), egy küldő (TXD), valamint a földelés (GND) vezetékeket szokták használni, illetve még DTR, DSR, CTS, RTS abban az esetben, ha hardver alapú kézfogásra van szükség a kommunikáció során.

Az RS-232 esetén a vonalak jelszintjei jelentősen eltérnek az UART jelszintektől, mivel itt nem TTL jelszintek vannak, hanem a logikai 0, azaz alacsony jelszintnek a 3 V – 15 V közötti, míg a logikai 1, azaz magas szintnek a -3 V – -15 V feszültség tartomány felel meg.

Mivel az UART és az RS-232 is aszinkron protokoll, vagyis nincsen közös szinkronizáló órajel a felek között a kommunikáció alatt, így rendkívül fontos a kommunikációban résztvevő két fél megfelelő beállítása, máskülönben nem tudják megfelelően értelmezni az egymásnak küldött adatokat illetve vezérlő jeleket. Alapvetően a kommunikáció paraméterei a következőkkel jellemezhetőek:

  • Adatátviteli sebesség, amely azt határozza meg, hogy a bitek milyen gyorsan követik egymást, azaz egy bit időegységben milyen „hosszú”. A szabványos értékek a következők szoktak lenni: 150, 300, 600, 1200, 2400, 4800, 9600, 14400, 19200, 38400, 57600, 115200 bit/s.

  • Adatbitek száma, azaz egy üzenetben hány darab adatbit található. A szabványos értékek a következők szoktak lenni: 5, 6, 7, 8, 9.

  • Paritásbit, azaz páros, páratlan vagy semmilyen paritás bit alkalmazandó.

  • Stop bitek száma, azaz milyen „hosszú” legyen egy stop bit. A szabványos értékek a következők szoktak lenni: 1 bit, 1,5 bit, 2 bit.

Az UART illetve az RS-232 üzenetformátumot is definiál, melyet komolyan befolyásolnak a kommunikációra vonatkozó fentebb leírt beállítási lehetőségek [UART/RS232 protokoll által definiált üzenetformátum]

4.1. ábra - UART/RS232 protokoll által definiált üzenetformátum

UART/RS232 protokoll által definiált üzenetformátum


Amikor nincs adatküldés, az adatvezetéken logikai 1 szint van a vonalon. Ha az eszköz adatot akar küldeni, akkor azt egy logikai 0 szinten levő start bit segítségével jelzi. A start bitet folyamatosan, sorban egymás után követik az adatbitek. Az adatbitek végén pedig paritásbit is állhat. Az adatküldés befejeztével az átvitel végét egy stop bit jelzi, ami mindig logikai 1 szinten van. A stop bit után azonnal következhet egy újabb átvitel.

Az üzenet fogadás esetén a fogadó készülék várakozik az adatátvitel megkezdésére. Amikor lefutó élt detektál, akkor vár fél bit időtartamig és újra beolvassa az RXD vonalat, hogy meggyőződjön arról, hogy biztosan start bit, és nem zaj érkezett. Ezután minden bitidő közepén mintát vesz a vevő a jelvezeték logikai szintjéből, így olvasva le minden bit értékét a stop bitig bezárólag.

Az RS-232 esetén hardveres kézfogás is lehetséges, melynek két fajtája van. Ez egyik a kapcsolat létrehozásáért felelős (DTR/DSR), míg a másik az adatátvitelt vezérli. Természetesen külön-külön, valamint együtt is alkalmazható a két eljárás. Abban az esetben, ha mindkét kézfogás használandó, a következők szerint néz ki a kommunikáció:

  • Az adó jelzi DTR (Data Terminal Ready) vonalon a vevő felé, hogy készen áll a forgalmazásra.

  • Az adó jelzésére a vevő a DSR (Data Set Ready) vonalon visszaigazolja, hogy szintén készen áll a kommunikációra.

  • Az adó az RTS (Request To Send) vonalon jelzi, hogy adatot kíván küldeni.

  • A vevő a CTS (Clear To Send) vonalon visszaigazolja, hogy készen áll az adat fogadására, illetve a kommunikációra.

  • Megkezdődik a kétirányú adatforgalmazás a RXD (Receive Data) illetve a TXD (Transmit Data) vonalakon

  • A vevő a kommunikáció alatt visszavonhatja a CTS jelet abban az esetben, ha nem tud adatokat fogadni (pl. megtelt a puffere).

  • A CTS jel ismételt kiadásával a forgalmazás újraindul.

  • Az adó az RTS jel megvonásával szintén jelezheti, hogy szüneteltetni akarja a kommunikációt.

Az UART esetében fontos megjegyezni, hogy sokszor, mint gyűjtőfogalmat használják a soros és párhuzamos interfészek közötti átalakításra, azaz például a belső buszrendszer, valamint egy soros kimenet között.

SPI

Az SPI (Serial Peripheral Interface Bus) egy szinkron, teljes-duplex, soros átviteli protokoll. Mester-szolga (Master-Slave) architektúrájú kommunikációt tesz lehetővé, azaz van egy kitüntetett eszköz a kommunikációban, amely vezérli a kommunikációt, azaz megadja, hogy melyik szolga eszköz kommunikálhat, valamint mivel szinkron kommunikációról van szó, ezért az órajelet is ez az eszköz szolgáltatja.

Az SPI-t esetenként szokták négy vonalas soros busznak (4 wire serial bus) is nevezni, ezzel megkülönböztetik a kettő, három, sőt az egy vonalon történő soros adatátviteltől. Nagy előnye ennek a kommunikációs protokollnak, hogy nagy sávszélességet biztosít: az órajel frekvenciájától függően akár 10 MBit/s is lehet. Viszonylag elterjedt, emiatt gyakran a legegyszerűbb kontrollerek is támogatják hardveresen. További jó tulajdonság, hogy az adatátvitelkor kiválasztható az átviteli formátum, ami azt jelenti, hogy nem csak 8 bites egységeket, azaz bájtokat, hanem akár 4 vagy 24 bites adategységeket is lehet küldeni. Hátránya viszont, hogy több vezetősávot igényel a nyomtatott áramköri panelokon, illetve relatíve kis hatótávolsággal működik összehasonlítva az RS-232-es vagy a CAN protokollokkal.

A négy vonalas soros busz elnevezés néha félrevezető is lehet, mivel az SPI-nak létezik 3 illetve 5 vezetékes változata is, azonban az alap változatához 4 vezeték szokott tartozni:

  • Az SCLK vezetéken szolgáltatja a mester az órajelet, mely tipikusan 1-70 MHz szokott lenni.

  • A MISO (master-in-slave-out) vagy más néven SOMI a mester felé menő kommunikációs vezeték, amelyen a szolga tud a mesternek adatot küldeni.

  • A MOSI (master-out-slave-in) vagy más néven SIMO a szolga felé menő kommunikációs vezeték, amelyen a mester tud a szolgának adatot küldeni.

  • A CS (chip select) vagy más néven SS (slave select) vezetéken tudja a mester engedélyezni az egyes szolga eszközöket, azaz ezzel tudja meghatározni kivel szeretne kommunikálni. A kiválasztó vonalak száma szab határt annak, hogy hány szolga eszköz csatlakozhat a hálózathoz, valamint ha csak egy szolga eszköz van rácsatlakoztatva a hálózatra, akkor nem kötelező a használata.

4.2. ábra - Az SPI hálózat elrendezése két szolga esetén

Az SPI hálózat elrendezése két szolga esetén


Mivel mester-szolga jellegű, ezért a mester az aktív elem a rendszerben, vagyis ő kezdeményezi a kommunikációt, biztosítja a kommunikációs órajelet, valamint bekonfigurálja úgy a kommunikációt, hogy az a szolga eszköznek is megfelelő legyen. Ez elsősorban az órajel frekvenciát jelenti. Vagyis, hogy ne legyen túl magas frekvenciájú az órajel az adott szolga eszköz számára valamint, hogy le- vagy felfutó élre történjen az írás illetve olvasás.

Maga a kommunikáció „buffer-csere” jellegű, vagyis a mester és a szolga közötti adatcsere folyamán egyszerre, egy órajel ciklus alatt tolódik egy-egy adatbit a mestertől a szolga felé illetve a szolgától a mester felé [Az SPI kommunikáció elve]. Tehát gyakorlatilag az ábrán látható két 8 bites shift regiszter úgy vehető, mint egy egyetlen 16 bitből álló körkörös shift regiszter, vagyis 8 órajel impulzus után az adat a mester és a szolga között kicserélődik

4.3. ábra - Az SPI kommunikáció elve

Az SPI kommunikáció elve


A kommunikáció az alábbi lépések szerint történik:

  1. A mester a megfelelő szolga eszközhöz tartozó CS lábat aktívra állítja.

  2. A mester és a szolga eszköz előkészíti a saját shift regiszterében a küldeni kívánt adatokat (az adat a mestertől a szolga felé mindig a MOSI vezetéken, a szolgától a mester felé pedig a MISO vezetéken áramlik)

  3. A mester egy adatbitet ír a MOSI vezetékre, ezzel egy időben a szolga is egy adatbitet ír a MISO vezetékre.

  4. Amikor a mester az SCLK vezetéken elküldi az adatcseréhez szükséges órajel impulzust, akkor beolvassa a MISO vezetéken lévő értéket (amit előzőleg a szolga írt rá), ugyanekkor a szolga is beolvassa a MOSI vezetéken lévő értéket (amit előzőleg a mester írt rá).

  5. Adatbeolvasáskor a shift regiszter automatikusan továbblépteti a korábban beérkezett adatokat, helyet csinálva ezzel a bejövő adatnak (az SPI működési módtól függ, hogy adatbeolvasás az órajel impulzus felfutó vagy lefutó élére történik).

  6. A 2-es ponttól ismételve a lépéseket az órajel minden egyes impulzusára az adatok bitenként elküldhetők.

  7. Minden adatcsomag után a mester a CS vonalat magasra állítja, ezzel szinkronizálva a szolga eszközt.

Az átvitel során lehetőség van egyszerre több egységnyi adatot küldeni anélkül, hogy a szolga eszközzel meg kellene szakítanunk a kommunikációt. Ilyen esetben az órajel generálás tovább folyik, illetve a mester és a szolga küldheti a következő adatot.

I2C

Az I2C (Inter Integrated Circuit) egy soros, szinkron, fél-duplex kommunikációs protokoll. Ez a protokoll az SPI-hoz hasonlóan szintén megtalálható a legtöbb mikrokontrollerben. Noha több különböző gyártó által létrehozott protokoll is alapjául vette az I2C specifikációját, ezek azonban minimális átkonfigurálást igényelnek az I2C protokollhoz képest, és általánosságban elmondható, hogy kompatibilisek is egymással (SMBus, SCCB). Az I2C egy több mester és több szolga egységet is kezelni tudó protokoll, vagyis több mester és több szolga is lehet a hálózaton. A kommunikációhoz jellemzően két vezeték szükséges, egy szinkron órajel vezeték (SCL), valamint egy adatjel vezeték (SDA) [Egy példa az I2C hálózat elrendezésére], melyeken többnyire 10 kbit/s és 3,4 Mbit/s közötti átviteli sebesség érhető el (minden egyes órajel impulzusnál egy bit továbbítódik). A részvevők a két vezetékre nyitott draines illetve nyitott kollektoros kimenettel csatlakoznak és a vezetékek elengedett állapotban történő magas logikai szintre történő beállását a felhúzó ellenállások biztosítják.

4.4. ábra - Egy példa az I2C hálózat elrendezésére

Egy példa az I2C hálózat elrendezésére


Az I2C busz legfőbb előnye a cím alapú kommunikáció. Minden egyes buszra kötött eszköz rendelkezik egy 7 (vagy 10) bites címmel, amellyel azonosítani lehet a hálózaton, tehát az SPI-jal ellentétben nem kell külön engedélyező vezetéket kötni az egyes eszközökhöz. A kommunikáció során a mester vezérli a kommunikációt illetve szolgáltatja az órajelet, ugyanakkor mind a mester, mind a szolga eszközök lehetnek adók illetve vevők is. Az órajel generálásnál lényeges, hogy a szolga eszközök nem generálhatnak órajelet, ugyanakkor a szolga is befolyásolhatja azt, mivel ha nem kész a kommunikációra, akkor lent tarthatja az órajelet, késleltetve ezzel a mestert.

Az SDA adatvezetéket az adatbitek átvitele alatt mindig az aktuális küldő (adatkivitelnél a mester, adatbeolvasásnál a szolga), a nyugtázás ideje alatt pedig a fogadó egység vezérli. Maga az átvitel keretek segítségével történik, melyeket a start illetve a stop fázisok határolnak. Ezen fázisok különlegessége, hogy ekkor az SDA adatvonal az SCL órajel magas értéke alatt vált állapotot. Minden más esetben az SDA adatvonal az órajel magas értéke alatt stabil, és az új értéket az SCL alacsony állapota állítja be. Egy átvitel során előfordulhat ún. ismételt start fázis is, tehát a start-start-stop fázis sorozat is érvényes kereteket jelöl.

Az I2C esetén lényegében háromféle kommunikáció típusról beszélhetünk. Az egyik esetben mester szeretne adatot küldeni az egyik szolga eszköznek. Ekkor a mester megcímzi a céleszközt majd adatokat küld, és végül lezárja az átvitelt. Egy másik eset, amikor a mester olvasni szeretne a szolga eszköztől. Ekkor a mester megcímzi a céleszközt, majd adatokat fogad a szolga felől, és végül lezárja az átvitelt. Azt, hogy a mester írni vagy olvasni szeretne, a cím utáni első bittel jelzi. A harmadik lehetőség, amikor a mester egy általános hívási címet címez meg, ekkor az üzenet minden szolgának szól.

Az I2C esetében szükség lehet szinkronizációs folyamatra is, mivel az egyes mesterek saját órajelet generálnak. Mivel több mester is lehet, ezért előfordulhat, hogy egyszerre kezdeményeznének kommunikációt. Ilyenkor el kell dönteni, hogy ki fogja vezérelni a kommunikációt, azaz ki nyeri el a kommunikációs jogot. Ez az arbitráció. Ahhoz, hogy az arbitrációs folyamatot le lehessen folytatni, szinkronizálni kell az órajeleket. A szinkronizáció során az SCL vezetéken egy magas-alacsony átmenet az érintett eszközöknél az alacsony periódusuk időzítésének megkezdését eredményezi. Ha egy eszköz órajele alacsonyra váltott, egészen addig alacsony állapotban tartja az SCL vezetéket, amíg az órajele magas periódusához nem ér. Ennek az órajelnek egy alacsony-magas átmenete nem változtathatja meg az SCL vezeték állapotát, ha egy másik eszköz órajele még mindig az alacsony periódusában van, azaz az SCL vezetéket a leghosszabb alacsony periódusú eszköz tartja alacsonyan. Erre az időre a rövidebb alacsony periódussal rendelkező eszközök magas várakozó állapotba kerülnek. Amikor minden érintett eszköz az alacsony periódusa végére ért, az órajel vezeték felszabadul, és magas logikai állapotba kerül. Ekkor nincs különbség az eszközök órajelei és az SCL vezeték állapota között, és minden eszköz elkezdi kiszámolni a magas periódusát. Az első eszköz, amely végzett a magas periódusával, ismét alacsonyra húzza az SCL vezetéket. A fenti eljárásnak köszönhetően az SCL vezetéken egy szinkronizált órajel áll elő, melynek az alacsony periódusát a leghosszabb alacsony periódusú órajel, a magas periódusát az egyik legrövidebb magas periódusú órajel határozza meg.

Ahogy korábban is megemlítésre került, a több mesteres felépítés miatt szükség lehet arbitrációra, akkor, ha kettő vagy több mester próbál információt küldeni, azaz több mester generál egy start feltételt, a start feltétel minimális tartási idején belül. Az arbitráció úgy zajlik, hogy az első olyan mester elveszti az arbitrációt, amelyik logikai 1-et akar küldeni, miközben a többiek 0-át. Ha a címbitek összehasonlításánál nincs különbség, akkor az arbitráció az adatbitekkel folytatódik a további részeken, így az arbitráció során nincs információvesztés.

Összefoglalva, a kommunikáció az alábbi lépések szerint történik [Egy példa az I2C kommunikációra]:

  1. A mester kezdeményezi az adatátvitelt a start fázissal.

  2. Kiírja a címet az adatvonalra.

  3. A cím utáni egy bites vezérlő jellel megadja, hogy olvasni vagy írni szeretne-e az adott szolgától.

  4. A szolga nyugtázza a címének vételét (ACK ,Acknowledge).

  5. Ezután következik az írási vagy olvasási ciklus.

  6. A mester jelzi az adattranszfer végét a stop fázissal.

4.5. ábra - Egy példa az I2C kommunikációra

Egy példa az I2C kommunikációra


CAN

A CAN egy soros, aszinkron kommunikációs protokoll. A buszra felfűzött összes eszköz (csomópont) egyenrangú, és tetszőleges időpontban kezdhet adni, éppen ezért a protokollnak az I2C-hez hasonlóan veszteségmentes arbitrációt kell biztosítania. Üzenetszórásos jelleggel működik, azaz minden, a hálózathoz csatlakozó eszköz lát minden üzenetet. Fizikai szinten két vezeték használata a kötelező, mivel differenciális feszültségmérésen alapul, és NRZ (nullára nem visszatérő, non-return to zero) kódolást használ. A fizikai jelvezetékek a magas (CAN High), és az alacsony (CAN Low). Ezek mellett többször szoktak még földelést, és néha tápvezetéket is alkalmazni [Példa egy nagysebességű CAN hálózat felépítésére 3 csomópont esetén] és [Példa egy alacsony CAN hálózat felépítésére 3 csomópont esetén].

Kétféle CAN szabványt szoktak használni a nagy (high speed) illetve az alacsony (low speed) sebességű hálózatokat. A nagy sebességű hálózatok 125 kbps - 1 Mbps átviteli sebességet, míg az alacsony sebességű hálózatok 10 kbps - 125 kbps sebességet biztosítanak. Ugyanakkor nem csak a sebességben van köztük különbség. Elsődleges szempont, amiért elkülönítik ezen hálózatokat, hogy az alacsony sebességű hálózatok nagy hibatűrő képességgel rendelkeznek, valamint a nagy sebességű CAN hálózatok esetén többnyire megkövetelik a 120Ω-os lezáró ellenállásokat a megfelelő impedancia elérése miatt.

4.6. ábra - Példa egy nagysebességű CAN hálózat felépítésére 3 csomópont esetén

Példa egy nagysebességű CAN hálózat felépítésére 3 csomópont esetén


4.7. ábra - Példa egy alacsony CAN hálózat felépítésére 3 csomópont esetén

Példa egy alacsony CAN hálózat felépítésére 3 csomópont esetén


Mivel jelen esetben aszinkron hálózatról van szó, ezért itt is fontos, hogy minden egyes csomópont a megfelelő módon legyen beállítva, azaz ugyanarra a hálózati sebességre (azonos bitidőkre) legyen bekonfigurálva.

A CAN hálózatok összetettsége miatt (mivel nagyon sok csomópont küldhet nagyon sokféle üzenetet) adatbázisokat szoktak létrehozni annak a leírására, hogy melyik csomópont mikor milyen üzeneteket küld és ezeket az üzeneteket ki fogja értelmezni. Ezen adatbázisok többnyire az üzenetekben található adatmező felosztását is tartalmazzák, ugyanis az adatmezők értelmezéskor azok tetszőlegesen feloszthatóak kisebb részekre, mint például a négy keréksebességet el lehet küldeni egy üzenet adatmezőjében egyszerre.

Az adatküldésre szolgáló üzenetek felépítése

A CAN esetében az üzenetek már összetettebbek, mint az eddig ismertetett kommunikációs protokollok esetén. Alapvetően kétféle üzenet típust kell megkülönböztetni: a hagyományos és kiterjesztett üzeneteket. A hagyományos üzenetek esetében 11 bit, míg a kiterjesztett üzeneteknél 29 bit áll rendelkezésre az üzenet azonosítókhoz.

4.8. ábra - Az adat típusú CAN üzenetek felépítése

Az adat típusú CAN üzenetek felépítése


A hagyományos üzenet esetében a következők szerint épül fel egy üzenet:

  • Minden egyes üzenet egy start bittel (SOF (start-of-frame)) indul, mely egy domináns bit, amit minimum 11 recesszív bit előz meg.

  • Ezután következik 11 bit, ami az üzenet azonosítóját tartalmazza (ID, identifier). A CAN esetében lényeges, hogy nem a hálózathoz csatlakozó eszközöknek, hanem az üzeneteknek van azonosítója, ami meghatározza az eszközök számára annak tartalmát, valamint a prioritását is. Ugyanis a CAN esetén, ha két eszköz, más néven csomópont egyszerre próbál meg adni, akkor az I2C-hez hasonló arbitráció kezdődik. Mindkét csomópont elkezdi kiküldeni a saját üzenetét. Minden egyes bit után, amit kiküldenek vissza is olvassák a hálózaton kint levő értéket. Amint az egyik csomópont azt detektálja, hogy ő recesszív bitet helyezett ki a hálózatra, de domináns bitet olvasott vissza, abbahagyja az üzenetküldését. Ebből következik, hogy az a csomópont nyeri el az adás jogát, aki alacsonyabb azonosítóval rendelkező üzenetet szeretne küldeni, mivel a CAN esetében a domináns szint a logikai 0-nak felel meg. Egy jól megtervezett hálózat esetén elegendő az azonosító mező az arbitrációhoz, mivel egy adott azonosítóval rendelkező üzenetet nem küldhet két csomópont, ám ha ilyen előfordulna, akkor az arbitráció folytatódik az üzenet további részén.

  • Az azonosító mezőt követi a RTR (remote transmission request) bit, mely azt hivatott jelezni, hogy adatkérést tartalmaz-e az üzenet. A legtöbb esetben a CAN hálózaton adatszórás jellegű kommunikáció zajlik, tehát egy bizonyos időközönként az adott csomópont megpróbálja kiküldeni az adott információt, mondjuk egy vagy több szenzornak a jelét. Ugyanakkor lehetőség van adat kérésére is. Ez az adatkérő üzenetek segítségével történik. Felépítésben az adat üzenet illetve adatkérő üzenetek szinte teljesen megegyeznek egy fontos kivétellel, hogy az adatkérő üzeneteknek nincs adatmezőjük.

  • Az RTR bitet követi a kiterjesztett üzenetet jelző bit (IDE, identifier extension). Hagyományos üzenetek esetében ez mindig 0, mivel nem tartalmaz kiterjesztett azonosítót.

  • Az ezeket követő bit egy helyfenntartó bit, melynek mindig nullának kell lennie.

  • Ezután következik négy bit (DLC, data length code), mely azt tartalmazza, hogy hány bájtnyi adatot tartalmaz az üzenet. A CAN üzenetekben alapértelmezetten 0-tól 8 bájtig terjedő adatmennyiséget lehet továbbítani.

  • A DLC-t követi maga az adat. Az adat tetszőleges információkat tartalmazhat, ezeket már csak a csomópontok értelmezik.

  • Az adatot egy 15 bites CRC (cyclic redundancy check) ellenőrző összeg követ, illetve még egy 1 bites CRC lezáró, ami mindig 1-es értéket tartalmaz.

  • Ezután egy nyugta mező következik, mely két bitből áll. Az első bitnek az a feladata, hogy jelezze az adó felé, hogy valaki vette az üzenetet, ugyanis bármelyik csomópont, amelyik veszi az üzenet korábbi részét az domináns állapotba, azaz nullára állítja a hálózaton levő jelszintet. Ennek azért van szerepe, hogy az adó tudja, hogy vette-e valaki az üzenetet. A második bitje a mezőnek egy recesszív elválasztó bit.

  • Ezeket követi az üzenetet lezáró hét recesszív bit (EOF (end-of-frame)), majd ezt legalább három további recesszív bit, ami az üzenetek elválasztására szolgál (IFS (interframe space)). Ezeket összeadva valamint hozzászámolva a nyugta elválasztó bitet, megkapható a start bitnél említett 11 recesszív bit.

A kiterjesztett üzenetek nagyon hasonlítanak a hagyományos üzenetekhez, a lényegi eltérés az azonosító mező kiterjesztésében van. A kiterjesztett üzenetek esetében a 29 bites azonosító első 11 bitjét a hagyományos címnek fenntartott azonosító mező tartalmazza. Ezt követően az RTR mező eredeti helyén egy SRR (substitute RTR bit) bit található, melynek recesszív értékűnek kell lenni, amelyet az IDE bit követ, ami ebben az esetben egyes értéket fog felvenni. Az IDE mezőt az azonosító fennmaradó 18 bitje követi. Ezt követően következik az RTR bit, majd egy 1 bites helyfenntartó. Innentől kezdve már megegyezik a hagyományos és kiterjesztett üzenetek felépítése.

Az üzenetek felépítésénél megemlítésre került, hogy 11 recesszív bitet követ egy start bit, így minden eszköz pontosan tudja, hogy új üzenet kezdődött. Belegondolva, hogy a 11 recesszív bit a nullás azonosítóval rendelkező üzenet esetén is kijöhet. Ezt azonban a CAN protokoll orvosolja a bitbeszúrás (bit stuffing) nevezetű eljárással. A módszer lényege, hogy minden öt azonos bit után (beleértve a beszúrt biteket is) beszúr egy ellentétes bitet. Természetesen ez az eljárás csak abban az esetben működőképes, ha a csomópontok megfelelően vannak beállítva (bit idők, stb.). Maga az eljárás nem csak az üzenetek felismerését, hanem az üzenetek közbeni szinkronizációt is elősegíti.

Hibakezelés

A CAN protokoll a hibakezelésre vonatkozóan is tartalmaz leírást. Három hibaállapotot definiál minden egyes csomóponthoz:

  • Aktív hibaállapot (error active): Ebben az állapotban, ha hiba történik, akkor a csomópont azt feltételezi, hogy azt nem ő okozta.

  • Passzív hibaállapot (error passive): Ebben az állapotban, ha hiba történik, akkor a csomópont azt feltételezi, hogy valószínűleg helyi meghibásodás történt, de még nem olyan súlyos a helyzet, hogy le kelljen válnia a buszról.

  • Leválasztott hibaállapot (bus off): Ebben az állapotban a csomópont feltételezi a hibás működést, melyet kellően súlyosnak gondol ahhoz, hogy leválassza magát a buszról.

A különböző állapotok között minden egyes csomópont a saját hibaszámlálója segítségével képes lépkedni. Ahogy növekszik az egymást követő vételi illetve küldési hibák száma, úgy lépteti át magát az adott csomópont az egyik állapotból a másikba [CAN csomópont hibaállapotok közötti átmenete].

4.9. ábra - CAN csomópont hibaállapotok közötti átmenete

CAN csomópont hibaállapotok közötti átmenete


A hibakezeléshez további három üzenet típus tartozik. Bármilyen küldés vagy fogadás során fellépő hiba egy hibaüzenetet generál, ami szándékosan megsérti a bitbeszúrás szabályait, ezzel kényszerítve az adó csomópontot az újraküldésre. Az aktív és a passzív hibaállapotokhoz különböző üzenetek tartoznak, ugyanakkor mindkettő két tagból áll: egy hibajelző (Error Flag) és egy hibahatároló (Error Delimiter) mezőből.

  • Az aktív hibaüzenet a kezdeti hiba észlelésekor kerül kiküldésre úgy, hogy egy vagy több aktív hibaállapotban levő csomópont azonnal megszakítja a kommunikációt (kivéve CRC hiba esetén). Ezt úgy teszik, hogy domináns biteket helyeznek a buszra. Az első 6 domináns bit alkotja az aktív hibajelző részt, vagyis az aktív hibaüzenet első mezejét. Ezt követően recesszív bitet kezd el adni a csomópont.

Minden olyan aktív hibaállapotban lévő csomópont, amely a kezdeti hibát nem érzékelte, legkésőbb az aktív hibajelző mező 6. domináns bitjénél hibát fog generálni, ugyanis ezen a ponton a bitbeszúrás szabálya sérül. Így legrosszabb esetben újabb 6 domináns bit fog a CAN buszon megjelenni, ezért ez a szakasz az aktív hibajelzők szuperpozíciója. E szakasz hossza ismeretlen, 0-6 bit hosszúságú lehet. Ha 0 bit hosszúságú, akkor a kezdeti hibát egyszerre észlelte az összes aktív hiba állapotú csomópont.

Ahogy a CAN buszt figyelik a csomópontok, az aktív hibajelző 6 domináns bitet követően - egy idő után - recesszív bitet fog visszaolvasni minden csomópont, melyet követően még 7 recesszív bitet sugároznak a csomópontok. Az aktív hibaüzenet záró része tehát a 8 recesszív bitből álló hibahatároló mező. Ezzel a módszerrel lehetségessé válik egy csomópont számára, hogy érzékelje, hogy vajon ő volt-e az első, aki hibajelzést küldött, azaz elsőként észlelte a hibát. A hibás csomópontok elszigetelésénél fontos ez a mechanizmus.

Az aktív hibaüzenet végén a busz ismét kész adathordozó üzenet továbbítására. Így az a csomópont, amelyiknek adása meg lett szakítva, megkísérelheti az el nem küldött üzenet újraküldését.

  • A passzív hibaüzenetek esetén egy csomópont passzív hibaállapotban van, melyben passzív hibaüzenet küldésére képes. A Passzív hibaüzenet első fele a Passzív hibajelző, amely 6 recesszív bitből áll. Ennek csak akkor van hatása, ha a passzív hibaállapotú csomópont a megfelelő helyen kezdi el a passzív hibaüzenet küldését. Azt a passzív hibajelzőt, amely arbitrációs mezőben, valamint kevesebb, mint hat bittel a CRC sorozat vége előtt kezdett adni, nem érzékeli a többi csomópont.

Tehát ha egy nem buszbirtokló csomópont próbál Passzív hibajelzést adni, akkor annak nem lesz hatása a hálózat többi csomópontjára.

A „Hiba passzív” állapotú csomópontoknak mindig ki kell várni a 6 azonos értékű recesszív passzív hibajelző bitet a hiba detektálása után, hogy befejezettnek tekinthessék a hibajelzésüket, melyet a hibahatároló 8 recesszív bit zár le, megegyezően az aktív hibaüzenettel.

  • A túlcsordulás üzenetnek ugyanolyan formátuma van, mint az aktív hibaüzenetnek, ugyanakkor hatására nem szükséges az előző üzenet újraküldése. Egy csomópont több különböző esetben is küldhet túlcsordulás üzenetet. Ilyen például, ha a fogadó csomópont késleltetni akarja a következő üzenet fogadását, ha a fogadó csomópont az üzenetek közötti mező első két bitjén domináns bitet érzékelt, illetve ha a hiba-, vagy túlcsordulás-határoló mező utolsó bitjén domináns bitet érzékelt.

Túlcsordulás üzenetet csakis „Hiba aktív” állapotú fogadó csomópont küldhet, abban az esetben, ha nem kész a következő üzenet fogadására. Egymás után maximum kettő küldhető, és csupán az üzenet utáni szünetben fordulhat elő.

A CAN működési diagramja

A CAN csomópontok alapvető működése felrajzolható egy diagram segítségével [A CAN csomópontok működési diagramja]. Az ábrán az egyes számozott pontok bizonyos műveletek elvégzését jelentik:

  1. Inicializálás, hibaszámlálók és működési paraméterek alapértelmezett állapotba állítása.

  2. Vételi hibák számának rögzítésére szolgáló számláló növelése eggyel.

  3. Vételi hibák számának rögzítésére szolgáló számláló növelése nyolccal, hogy ha a vevő elsőnek állítja be a hiba jelzésére szolgáló jelzést.

  4. Vételi hibák számának rögzítésére szolgáló számláló csökkentés eggyel az üzenet sikeres vételekor.

  5. Küldési hibák számának rögzítésére szolgáló számláló növelése nyolccal, hogy ha hiba történt az átvitelkor.

  6. Küldési hibák számának rögzítésére szolgáló számláló csökkentés eggyel az üzenet sikeres átvitelekor.

  7. Küldési hibák számának rögzítésére szolgáló számláló növelése nyolccal. Abban az esetben, ha a küldési hibákhoz tartozó számláló nagyobb, mint 127, valamint ha a passzív hibák jelzésére szolgáló jelzés recesszív maradt, akkor nem kell növelni az értéket.

  8. Ha a küldési hibák számának rögzítésére szolgáló számláló nagyobb, mint 255, akkor a csomópontot le kell választani a buszról.

A helyes működési elvhez feltételezni kell, hogy a vételi hibák számát rögzítő számláló nem növekedhet 128 fölé, valamint sem ez, sem a küldési hibák rögzítésére szolgáló számláló nem csökkenhet 0 alá.

4.10. ábra - A CAN csomópontok működési diagramja

A CAN csomópontok működési diagramja


CANOpen

A CAN specifikációja a bitek fizikai továbbításával, azok keretezésével, valamint alapvető, általános kérdésekkel foglalkozik, tekintve, hogy a fizikai és az adatkapcsolati réteg definíciójára összpontosít. Ugyanakkor ipari felhasználási területeken szükséges volt az alapvető specifikációban foglaltakat meghaladó szolgáltatások szabványosítására is, mint például az alkalmazás-specifikus finomításokra és bővítményekre. Ennek érdekében definiálta a CiA a CAN alkalmazási rétegét (CAL). Ez az új réteg tulajdonképpen a kommunikációt végrehajtó rendszer és az applikáció közötti interfésznek tekinthető [Az alkalmazási réteggel kibővített CAN modell].

4.11. ábra - Az alkalmazási réteggel kibővített CAN modell

Az alkalmazási réteggel kibővített CAN modell


A CAN alkalmazási rétege számos szolgáltatást nyújt, többek között saját üzenetformátumokat és üzenetobjektumokat definiál, megadva ezek segítségével az egyes eszközök nyújtotta funkciók elérésének módját. Az üzenetekbe kerülő adatok kódolására is definiál megkötéseket, saját adattípusokat alkalmaz, egységesebbé téve ezzel a szállítást.

A CAL számos általános szolgáltatás definiál, ugyanakkor sokszor még mindig nehezen kezelhető. A könnyebb kezelhetőség elérése érdekében kezdődött meg a CANopen fejlesztése, mely a CAL-re épül, s annak szolgáltatásait használva jól kezelhető, egységes felületet nyújt az ipari alkalmazásokhoz, lefedve a lehetséges eszközök túlnyomó részét. Alkalmas mind elosztott, mind központosított szabályozási architektúra megvalósítására, paraméter fel- és letöltésre. A buszra fűzött eszközökhöz funkció alapján standard kapcsolódási, kezelési felületet kaptak, a rendszer a legtöbb mikrokontroller esetében működőképes, és megőrizte a CAN összes jellemzőjét.

A CANopen valamennyi csomópontja tekinthető egy összetett, sokcélú eszköznek, melynek feladata a kapcsolat fenntartása a CAN busz és az adott eszköz által végzett művelet között. A modellben interfészként szereplő objektumkönyvtár (Object Library) az adott eszköz összes adatát, paraméterét tartalmazza indexelt formában. Ezt a táblázatot a kommunikációs objektumokon (Communication Object) keresztül írni és olvasni lehet a busz felől, így fejtve ki hatását az adott alkalmazásra az alkalmazási objektumokon (Application Object) keresztül. A kommunikációs objektumok mindegyike egy-egy specifikus kommunikációs feladatért felelős, azaz egy-egy meghatározott üzenet küldéséért vagy fogadásáért. Ezek között adatszállítók és a rendszer általános működését irányítók is megtalálhatók. Ez utóbbiak irányíthatják az eszközök állapotváltásait is, a belső állapotgépnek adva parancsokat (Network Management = NMT). Vannak olyan adatszállító üzenetek is, melyek közvetlenül az objektumkönyvtár érintése nélkül érik el az alkalmazási objektumokat (Process Data Object = PDO).

Kihasználva a CAN által biztosított nagy rugalmasságot, a CANopen három alapvető kommunikációs módot definiál:

  • Mester-szolga (Master-Slave)

  • Kliens-szerver (Client-Server)

  • Gyártó-fogyasztó (Producer-Consumer)

A mester-szolga kommunikációs modellben egy kitüntetett csomópont, a mester lép interakcióba a hálózat összes többi csomópontjával, a szolgákkal. A szolgáltatás lehet nyugtázott és nyugtázatlan, általában hálózatvezérlésre használják (NMT objektumok) [A Mester-szolga kommunikációs modell].

4.12. ábra - A Mester-szolga kommunikációs modell

A Mester-szolga kommunikációs modell


A kliens-szerver kommunikációs modellben egy csomópont, a kliens lép kapcsolatba egy másik csomóponttal, a szerverrel, ahol adatot ír vagy olvas. Eszközkonfiguráláshoz használják, s ennek megfelelően csak nyugtázott formája létezik, ahol a válasz a művelet eredményét jelzi a kliensnek (Service Data Object = SDO objektumok) [A Kliens-szerver kommunikációs modell].

4.13. ábra - A Kliens-szerver kommunikációs modell

A Kliens-szerver kommunikációs modell


A gyártó-fogyasztó modell hasonlít a mester-szolga megoldáshoz, mivel itt is egy kitüntetett csomópont, a gyártó küld adatot több más csomópontnak. Ám azok száma nem kötött, illetve az is előfordulhat, hogy elküldött csomagjainak nincs vevője. Tipikus felhasználása a műveleti adatok valósidejű (real-time) cseréje. A CANopen terminológia ennek a kommunikációs modellnek megfelelő objektumokat műveleti objektumoknak (PDO-nak) nevezi. Ha a gyártó kérés nélkül küldi az adatot a fogyasztóknak, azt nevezik push (toló) modellnek. Azonban a protokoll lehetőséget biztosít arra, hogy bármely fogyasztó bármely időpillanatban üzenetek segítségével kérje az adatot a gyártótól. Ez esetben pull (húzó) modellről lehet beszélni. A nyugtázás szempontjából az előbbi a nyugtázatlan, az utóbbi a nyugtázott üzenetcsere osztályába tartozik [A gyártó-fogyasztó kommunikációs modell].

4.14. ábra - A gyártó-fogyasztó kommunikációs modell

A gyártó-fogyasztó kommunikációs modell


További speciális objektumok:

  • A szinkronizáló objektum (Synchronisation Object - Sync) a CANopen hálózatra kötött eszközök szinkronizálását végzi.

  • A vészhelyzet objektum (Emergency Object) a hibakezelés során alkalmazzák a vészhelyzet jelzésére.

  • Az időbélyeg objektum (Time Stamp Object) a teljes hálózat egységes időzítésére használható.

A szolgáltatási objektumok (SDO)

A szolgáltatási objektumok elsősorban az eszközök konfigurálásához használhatók. Az eszközök objektumainak teljes skálájához hozzáférhető, mely objektumok egymástól nagymértékben különbözőek lehetnek. Emiatt nagyobb rugalmasságot mutatnak, s akár 8 byte-nál hosszabb üzenet továbbítását is lehetővé teszik CAN üzenetek láncával. Ennek megfelelően több átviteli módot ajánl a CANopen az SDO-átvitel számára:

  • Gyorsátvitel (Expedited Transfer): kis adatok szállítására kiélezett átviteli mód, melynek implementálását a CANopen specifikációja kötelezővé teszi valamennyi eszköz számára. Használatára is kötelezi őket minden, 4 byte-ot meg nem haladó adat esetén.

  • Szegmentált átvitel (Segmented Transfer): az átvitel általánosan alkalmazott módja, mely minden esetben alkalmazható. Implementálása akkor kötelező, ha az eszközben lehetőség van 4 byte-nál hoszabb objektumok implementálására is.

  • Blokkátvitel (Block Transfer): a hosszú üzenetek átvitelére optimalizált átviteli forma, melynek implementálása teljes mértékben opcionális.

Mivel a kliens célja kétféle lehet, írás vagy olvasás, a kliens-szerver kapcsolat két különböző szolgáltatás nyújt: feltöltést (Upload) és letöltést (Download). Az átviteli módok bármelyike esetén a kliens a kapcsolat létesítője, viszont a kapcsolat lebontását mind a szerver, mind a kliens kezdeményezheti.

A műveleti objektumok (PDO)

A szolgáltatási adatobjektumokkal ellentétben a műveleti adatobjektumok rövid blokkjai direkt módon férnek hozzá az alkalmazási objektumokhoz, az objektumkönyvtár megkerülésével. Erre a lehetőséget az adja meg, hogy előre rögzített PDO-leképezési szabályok alapján a PDO bitjeinek jelentése ismert mind a küldő, mind a fogadó számára. Emiatt a műveleti adatobjektumok alkalmasak valós idejű feladatok végrehajtására, gyors kommunikációra, melyet erős prioritású azonosítókkal támogat meg a rendszer. A CANopen azonban itt is flexibilis: az arra alkalmas eszközök esetén a PDO-k bitjeinek leképezése SDO-kon keresztül módosíthatók. Ugyanez igaz a bennük foglalt adatok kódolására, adattípusaira is. A gyártó oldalán az úgynevezett továbbítási PDO-t (Transmit PDO) implementálják, míg a fogyasztó oldalán a vételi PDO-t (Receive PDO). Minden egyes PDO számára ki kell osztani egy azonosítót, melyhez a CANopen előre definiált sémát nyújt. Ez alapján négy vételi és négy továbbítási PDO-val rendelkezhet egy CANopen eszköz.

Mivel a PDO-k az alkalmazás saját adataihoz vannak rendelve, mely adatok állandó feldolgozás alatt állnak, több módot ajánl a CANopen ezen adatok megszerzésére.

  • Adatkérő (Remotely Requested): Ez az a mód, melyet az olvasási szolgáltatás használ, ahogy azt már tárgyaltuk. Egy adatkérő keret vétele váltja ki a PDO elküldését.

  • Időzített (Timer Driven): A PDO elküldése egy bizonyos idő elteltével következik be. Az írási szolgáltatás használja ezt a módot.

  • Eseményvezérelt (Event Driven): Egy, az adott eszközön belüli meghatározott esemény bekövetkezte indítja útjára a PDO-t. Az írás használja ezt a módot. Ez a gyakorlatban leginkább alkalmazott mód, ám nem kötelező egymagában használni: egy PDO egyszerre lehet erre a módra, s az időzített, vagy az adatkérő mód valamelyikére konfigurálva.

A CANopen több módot kínál a PDO-átvitel kezdeményezésére, valamint magára az átvitelre is több lehetőséget definiál:

  • Szinkron átvitel (Synchronous Transmission) során a PDO-k küldése periodikus, mivel az egy periodikusan generált szinkronizáló objektum (Synchronisation Object) vételének hatására történik. Ezt egy másik eszköz állítja elő, s általában több eszköz veszi, melyek így egyszerre küldik el adataikat, ill. kezdik el feldolgozni az egy periódussal korábban kapottakat. Értelemszerűen ez a típusú átvitel eseményvezérelten működik.

Ugyanakkor nem kötelező egyszerűen csak a szinkronizáló objektumhoz hangolni a PDO átvitelt, ezt lehet tovább finomítani. Ciklikus szinkron az átvitel, ha csak egy bizonyos számú vett szinkronizáló objektum után történik meg a PDO elküldése. Ciklikus pedig abban az esetben, ha a szinkronizáló üzenet megérkezte után, csak egy bizonyos esemény bekövetkeztekor történik meg a PDO átvitele.

  • Aszinkron átvitel (Asynchronous Transfer) esetén a PDO küldését egy adott esemény váltja ki, mely természetesen a szinkronizáló objektumtól független. Ha ezt az eseményt egy alkalmazási objektum generálja, a kezdeményezés egyértelműen eseményvezérelt; míg ha azt egy kommunikációs objektum generálja, időzített és adatkérő módban is működhet az átvitel.

Mivel a CANopen a CAL rétegre épül, ami az alkalmazás rétegnek felel meg az OSI modellben, így a CANopen-t az erre épülő felhasználói rétegként szokták emlegetni.

LIN

A LIN (Local Interconnection Network) lényegében a CAN hálózatok kiegészítőjeként jött létre, annak érdekében, hogy ahol lehet, ott csökkenteni lehessen a hálózat összetettségét valamint költségeit. Elsősorban a nagyobb központi számítógépek, valamint a szenzorok illetve aktuátorok közötti kommunikációra lett megtervezve, ahol nincs szükség nagy sávszélességre.

LIN szabványnak több egymást követő verziója van, melyeket a mai napig használnak. Ezek a LIN 1.x és a LIN 2.x fő verziók közé sorolhatóak.

Általánosságban elmondható, hogy a LIN egy aszinkron soros protokoll, mely egy mester több szolga (maximum 15 szolga illeszthető egy vonalra) kapcsolatot definiál, alacsony sebességű kommunikációhoz (általában 1 és 20 kbit/s közötti átviteli sebesség érhető el). A kommunikációhoz egy vezetékre van szükség, ugyanakkor ezen vezeték mellett sokszor szoktak még földelés és tápvezetéket is biztosítani.

Fontos megjegyezni, hogy a CAN-hez hasonlóan a LIN esetében is szoktak hálózat-, illetve kommunikációt leíró adatbázist alkalmazni, mely leírja az üzenetek tartamát valamint, hogy mely üzenethez kinek és mikor kell biztosítania az adatot. Itt a fő különbség a hagyományos CAN adatbázisokhoz képest, hogy egy adatbázis többféle ütemezést (schedule) is tartalmazhat, melyek között működés közben váltani lehet. Ez lehetővé teszi, hogy eltérő körülmények esetén eltérő időközönként más-más üzenetek jelenjenek meg a hálózaton. A különböző ütemezések között a mester tud váltani, mivel ő vezérli az adatok küldését.

A LIN üzenetek felépítése

A LIN üzenetek több részre bonthatóak, melyeknek szinte mindegyike érvényes UART üzenetek formájában továbbítódik [A LIN üzenetek fő részei].

4.15. ábra - A LIN üzenetek fő részei

A LIN üzenetek fő részei


Ez alól az egyetlen kivétel az üzenet kezdetének jelzésére szolgáló elválasztó mező (break field). Ez a mező szándékosan megsérti az UART protokollnál leírt üzenetformátumot, így jelezve az üzenet küldésének a kezdetét. Magának a protokollnak a megsértése abból áll, hogy a mester előbb 13 - 26 darab domináns, majd 1 - 14 darab recesszív bitet küld. A leglényegesebb a domináns bitek magas száma. Erre azért van szükség, mert a LIN létrehozásakor az olcsóság volt az egyik elsődleges szempont, így nem követel meg nagy pontosságú időzítést (órajelet) a szolgák oldalán, ezért biztosítani kell, hogy a szabványban megengedett az ideális órajeltől akár 14%-kal is eltérő órajelet alkalmazó szolga egységek is megfelelően detektálják a protokoll megsértését.

Az elválasztó mező után kezdődik meg a szinkronizáció (sync field). Ahogy már korábban is említésre került, a szolga egységek órajelei között nagy eltérések lehetnek, ezért szükséges, hogy a nagy pontosságú órajel generátorral rendelkező mester egységhez, pontosabban annak bitidejéhez szinkronizáljanak. Erre szolgál a szinkronizációs mező. Ebben a részben a mester egy 0x55-öt tartalmazó UART üzenetet küld ki a hálózatra, ami 01010101b értéknek felel meg binárisan, azaz egymást követik egyesek és nullák felváltva. A szolga egységek a lefutó éleket figyelve meg tudják határozni a mesterhez tartozó bitidőt.

A szinkronizációt követően következik az üzenetazonosító, mely egy 6 bites üzenetazonosítót valamint 2 paritás bitet tartalmaz, ahol a paritás bitek az azonosítóból számíthatóak a következőek szerint:

  • P0 = ID0 XOR ID1 XOR ID2 XOR ID4

  • P1 = INV(ID1 XOR ID3 XOR ID4 XOR ID5)

Az azonosítót és a hozzá tartozó két paritás bitet együtt védett azonosítónak (PID (protected ID)) szokás nevezni.

Az eddigi mezőket, azaz az elválasztó mezőt, a szinkronizációs részt valamint a védett azonosítót mindig a mester küldi és ezeket együtt fejlécnek szokás nevezni. Ezután következik a válasz szakasz, melyet mind a mester, mind a szolgák küldhetnek.

A válasz szakasz első fele az 1-8 UART üzenetből álló adatmező, melyből látható, hogy a LIN esetében maximum 8 bájtnyi adatot tartalmazhat egy üzenet.

Az adatokat a hozzájuk tartozó ellenőrző összeg követi. Az ellenőrző összeg számítására kétféle módszer létezik: egy hagyományos illetve egy kiterjesztett számítási mód. Az előbbit a LIN 1.x valamint a 60-63-as azonosítóval rendelkező LIN 2.x verziójú üzenetek esetében szokták alkalmazni, míg az utóbbit 0-59-es azonosítóval rendelkező LIN 2.x verziójú üzenetek esetében használatos.

Az ellenőrző összeg úgy számítandó, hogy a számításban résztvevő értékeket egymás után össze kell adni 8 biten, figyelembe véve az átvitt értéket is, majd a végösszeget invertálni kell. A hagyományos módszernél csak az adatbájtok vesznek részt a számításban, míg a kiterjesztett esetében a védett azonosító is. Példaképpen egy 2 bájt adatot tartalmazó üzenet ellenőrző összege a következő féleképpen számítandó a hagyományos módszerrel [Hagyományos ellenőrző összeg számítása két adatbájt esetén].

4.16. ábra - Hagyományos ellenőrző összeg számítása két adatbájt esetén

Hagyományos ellenőrző összeg számítása két adatbájt esetén


A hagyományos ellenőrző összeg számításánál alkalmazott adatokon elvégezhető a kiterjesztett módszerhez kapcsolódó számítások is [Kiterjesztett ellenőrző összeg számítása két adatbájt esetén].

4.17. ábra - Kiterjesztett ellenőrző összeg számítása két adatbájt esetén

Kiterjesztett ellenőrző összeg számítása két adatbájt esetén


Ezek alapján látszik, hogy a kommunikációt teljes egészében a mester vezérli, tehát ő mondja meg, hogy mikor milyen adatot vár, amelyre a szolgák válaszképpen elküldhetik a várt adatot a hozzá tartozó ellenőrző összeggel együtt, illetve a mester is küldhet adatot a szolgák felé, ekkor a válasz szakaszt is a mester tölti ki. Ugyanakkor az is megfigyelhető, hogy a védett azonosító, valamint az ellenőrző összeg segítségével hibadetektálás is elvégezhető.

Fontos megjegyezni, hogy a LIN specifikáció az időzítésekre nagyon komoly hangsúlyt fektet a korábban már említett költséghatékonysági okokból eredő órajel eltérések miatt. Ezeket a névleges vagy nominális, illetve a maximális értékek megadásával teszi. Mind a teljes üzenetre (az elválasztó mező elejétől az ellenőrző összeg végéig eltelt időre: Tkeret), mind pedig a fejléc (Tfejléc) illetve a válasz (Tválasz) mezők időbeli hosszára ad megkötéseket, a bitidő függvényében (TBit):

  • A névleges, azaz nominális időzítések:

  • Tfejléc_nom = 34 * TBit

  • Tválasz_nom = 10 * (Nadat + 1) * TBit

  • Tkeret_nom = Tfejléc_nom + Tválasz_nom

  • Maximális határ az időzítéseknél:

  • Tfejléc_max = 1,4 * Tfejléc_nom

  • Tválasz_max = 1,4 * Tválasz_nom

  • Tkeret_max = Tfejléc_max + Tválasz_max

LIN üzenetek típusai

A LIN 2.x szabvány alapvetően öt üzenettípust definiál:

  • Az általános üzenetek (unconditional frame) a 0-tól 59-ig terjedő tartományt használhatják az azonosítókból. Egy adott azonosítóval rendelkező üzenetre csak egy csomópont válaszolhat, mely lehet egy szolga vagy a mester is. Ugyan válaszolni csak egy csomópont válaszolhat az adott azonosítóra, de venni több csomópont is veheti a LIN üzenetszórásos jellegéből adódóan. Tulajdonképpen az azonosító határozza meg, hogy az adott üzenetnek milyen adatot kell tartalmaznia. Ciklikus, azaz adott időközönként történő kommunikációra szolgál a LIN buszon levő eszközök között, vagyis a mester periodikusan tud adatot lekérni a szolgáktól, illetve küldeni a szolgák felé.

  • Az eseményvezérelt üzenetek (event triggered frame) az általános üzenetekhez hasonlóan a 0-tól 59-ig terjedő tartományt használhatják az azonosítókból. Ezek a LIN 2.x verziójú protokollban alkalmazott keretek elsősorban a ritkán előforduló események kezelésére szolgálnak. Alapvetően úgy működnek, hogy a mester a fejlécbe egy eseményvezérelt keret azonosítóját írja, melyre az érintett szolga eszközök csak akkor válaszolnak, ha új adat áll rendelkezésre (az utolsó lekérdezés óta megváltozott az érték). Az adat első bájtja mindig az adott szolga eszköz azonosítója (PID), így a mester tudja, hogy kitől jött a válasz, mivel az általános üzenetekkel ellentétben egy eseményvezérelt üzenetre több csomópont is válaszolhat. Előfordulhat ütközés, azaz hogy egyszerre több szolga is válaszolni akar az adott fejlécre, ekkor a mester feladata ezt lekezelni többszöri lekéréssel.

  • A jelhordozó üzeneteknek azon csoportját, melynek tagjai ugyanazt az üzenethelyet használják, sporadikus (sporadic frame) üzeneteknek hívják. A sporadikus üzenetek lényege, hogy egy bizonyos fokú dinamikus viselkedést engednek meg egy determinisztikus viselkedésre tervezett hálózat, illetve ütemezés esetén úgy, hogy a látszólagos determinisztikusság fennmarad a tervezés szempontjából. Amikor a sporadikus üzenet küldése esedékes, az általános üzenetek frissítés igénylés szempontjából ellenőrzésen esnek át. Ha nincs frissítendő jel, akkor a sporadikus üzenetre szánt üzenethely üresen marad. Ha viszont van egy üzeneten belül egy, vagy több frissítendő jel, akkor ezen üzenet továbbítása meg fog történni. Ha több mint egy jel frissítése esedékes különböző üzeneteken belül, akkor a legmagasabb prioritású üzenet frissítése fog megtörténni. A fennmaradó alacsonyabb prioritású üzenetek nem fognak elveszni, hiszen az elkövetkező sporadikus üzenetekre szánt üzenethelyeknél a továbbításuk megtörténik. Egy frissítendő jeleket tartalmazó üzenet továbbítása addig tolódik, amíg nem ő lesz a legmagasabb prioritású.

Általánosságban a többszörös sporadikus üzenetekhez ugyanaz az üzenethely van hozzárendelve, és ezen üzenetekből a legmagasabb prioritású kerülhet továbbításra az adott üzenethelyen. Ha egyetlen általános üzenet továbbítása sincs függőben, akkor az üzenethely üresen marad (a csomópontok adásmentesen figyelik a buszt).

  • A diagnosztikai keretek (diagnostic frame) mindig a 60-as illetve 61-es azonosítóval rendelkeznek. Ezek az adott LIN klaszterhez tartozó szolga egységek diagnosztikájához és konfigurálásához használt üzenetek, melyek adatmezője mindig 8 bájt hosszú. A 60-as azonosítóval rendelkező keretek a mester kérései a szolga felé. Ezen keretek első adatbájtja többnyire a szolga eszköz azonosítóját tartalmazza, és többek között alkalmazható például arra, hogy felszólítsa a szolga eszközt, hogy aludjon el. A kérésre a szolga eszköz általában egy 61-es azonosítóval rendelkező üzenettel válaszol.

  • Léteznek még fenntartott keretek (reserved frame), melyek a 62-es és 63-as azonosítókat hivatottak későbbi felhasználásra fenntartani (LIN 2.x protokollt alkalmazó rendszereknél alapértelmezetten nem használják).

MOST

A MOST egy speciálisan a gépjárművek számára kifejlesztett kommunikációs technológia, a multimédiás adatok továbbítására. Magának a MOST névnek a jelentése (Media Oriented System Transport) is erre utal. Két fő követelmény fogalmazódott meg a gyártók részéről a MOST-al szemben, amelyeket hiánytalanul teljesít is:

  • A MOST buszon video-, és audio jelek, navigációs adatok, és más szolgáltatások mellett vezérlő jelek is átvihetőek legyenek

  • Maga a MOST technológia logikai felépítése alkalmas legyen arra, hogy a járműben található sokféle, és komplex adatokat egyszerre kezelje. Ezen kívül a teljes rendszernek a funkcióit és feladatait is rendszerezi azáltal, hogy az alapjaitól fogva úgynevezett függvényblokkokból (Function Block) épül fel.

MOST fizikai rétege

A jelek továbbítását nagy sebességű illetve sávszélességű MOST hálózatok esetén, az esetek többségében műanyag optikai szállal valósítják meg ezzel biztosítva azt, hogy a működés közbeni elektromágneses interferencia ne jöjjön létre. Ahhoz, hogy az adatok továbbíthatóak legyenek optikai kábelen keresztül, egy 1mm átmérőjű műanyag optikai szálra és vörös hullámhossz-tartományba eső fényt kibocsátó LED-re van szükség.

A MOST protokoll megvalósításához azért alkalmaznak optikai kábelt, mert rendkívül gyors adatátvitelt tesz lehetővé, fizikailag könnyebb és rugalmasabb, mint más kábelszabványok, továbbá megfelel a szigorú elektromágneses kompatibilitási követelményeknek. A MOST busz feladata, hogy a küldő oldali MOST eszköz által létrehozott elektromos jelből konvertált optikai jelet továbbítsa a fogadó oldali MOST eszköz optikai-elektromos átalakító egysége felé [A MOST buszrendszer működése].

4.18. ábra - A MOST buszrendszer működése

A MOST buszrendszer működése


MOST szabványok

A MOST hálózatokra csatlakoztatott eszközök egy folytonos alapjelhez szinkronizálódnak. Nincs szükség puffer tárolók használatára, sem mintavételezett konverzióra, így a hálózat hardverfelépítése meglehetősen költséghatékony.

A szinkronizációs órajelre azért van szükség, hogy a különböző adatfolyam-átviteli csatornák és a vezérlőjel csatorna ütemezetten tudjon működni. A vezérlőjel csatorna feladata, hogy megállapítsa, hogy melyik csomópont melyik átviteli csatornát használja. Amint a kapcsolat kiépült, azonnal megindulhat a felek közötti kommunikáció anélkül, hogy újabb címzésre vagy csomagcímkézésre lenne szükség.

A kommunikációban részt vevő adatfolyam egy előre lefoglalt sávszélességgel rendelkezik, amelyből következik, hogy nincs megszakításkezelés, sem adatütközés, és az átviteli sebesség állandónak tekinthető.

A szabvány definiálja a MOST hálózat fizikai jellemzőt, így megadva a kommunikációs csatorna (kábel) típusát, továbbá a kommunikációs protokollt és a szoftveres keretrendszert. A fizikai réteg megvalósítható műanyag optikai szálas (POF), üvegszálas (PCS), árnyékolt csavart érpárral (STP), árnyékolatlan csavart érpárral (UTP) és koaxiális (COAX) kábellel egyaránt. A kábel kiválasztásával befolyásolható az elérhető maximális adatküldési sebesség, valamint a sávszélesség is korlátozódhat.

A MOST hálózat akár 64 különböző eszköz egyidejű kezelését is lehetővé teszi csillag topológiában. A csillag topológia sérülékeny volta miatt biztonságkritikus esetekben a meghibásodás elkerülésének érdekében applikáció-redundáns duplagyűrűs konfigurációt építenek ki. A gyűrű topológiára jellemző, hogy ha a gyűrű bármely részén meghibásodás lép fel, akkor az adatátvitel leáll, ezért célszerű alkalmazni az előzőekben említett duplagyűrűs konfigurációt.

Mivel a MOST kommunikációs protokoll elsősorban a vezető és az utasok kényelméért felelős eszközök vezérlésére szolgál, ezért a hálózati eszközök csatlakoztatásának egyszerűnek kell lennie, amelynek megvalósítására felhasználják a Plug&Play alapú technológiát, melynek során a saját eszközök automatikusan inicializálásra kerülnek. A MOST fejlődése során több MOST szabvány is piacra került:

  • A legelső szabvány a MOST 25 volt. Ezen szabvány körülbelül 23 MBaudos sávszélességet kínál szinkron és csomag alapú, optikai szálon történő adatátvitelhez. 60 fizikai csatornát definiál, amelyből a felhasználó 4 bájtos csoportokat alakíthat ki. Támogat 15 tömörítetlen sztereó hangcsatornát CD minőségben, vagy akár 15 MPEG-1 csatornát audio-video átvitelhez, melyek mindegyike 4-4 fizikai csatornát igényel. Továbbá a MOST 25 biztosítja az adatfolyam felügyelésére alkalmas vezérjel csatornát, amely egyben a referencia adatok küldését is elvégzi. A vezérjel üzenetek konfigurálják a MOST eszközöket, tehát irányítják a szinkron-aszinkron adatátvitelt.

A MOST 25 protokollban alkalmazott keretek hossza 64 bittől egészen 512 bitig terjedhet. Az adatátvitel legkisebb részét (2 bájt) a vezérlőjel üzenetek adják, valamint 32 bájt van fenntartva az adminisztrációs hálózatok és eszközök számára. Az első és utolsó bájt ellenőrző információkat tartalmaz.

Az adatfolyam-átviteli és a csomagkapcsolt adatátviteli csatorna quadletekre bontva osztozik a sávszélességen. A quadlet szó jelentése: 4 bájtos szóhossz. Az adatfolyam csatorna esetén a hálózati interfész-vezérlőhöz tartozó időzítés 6-15 quadletes felosztásban van konfigurálva, míg az aszinkron csomagkapcsolat adatátvitel esetén ez jóval kevesebb (0-36 bájt). A quadletek felosztásának megváltoztatásával a mesternek azonnali újraszinkronizálást kell végrehajtania. A protokollban alkalmazott mintavételi frekvencia 44,1 kHz [A MOST 25 esetében alkalmazott átviteli protokoll].

4.19. ábra - A MOST 25 esetében alkalmazott átviteli protokoll

A MOST 25 esetében alkalmazott átviteli protokoll


  • A MOST 50 megduplázza a MOST 25 által biztosított sávszélességet, valamint támogatja az 1024 bites kerethosszúságot. Fizikai réteg tekintetében lehetővé teszi az elektromos és az optikai megoldásokat egyaránt. A MOST 50 elsősorban optikai és elektromos fizikai rétegek támogatására szolgál, de léteznek a MOST 50 Intelligens hálózati interfész vezérlők (INIC), amelyek csak UTP kábelen keresztül támogatják az adatátvitelt.

Ugyan a MOST 50 megnövelt sávszélességet biztosít, bár ennek ellenére az audio jelfolyam mintavételi frekvencia nem változott meg (44,1 kHz), de a keretek hossza növelhető 1024 bitre. Ezen protokollban a 4 bájtos vezérlőjel adat már bekerült a 11 bájtos fejlécbe, ahol többek között megtalálhatóak a lezárási flagek és a quadlet felosztási adatok is. A rendelkezésre álló sávszélesség dinamikusan igazítható az igények szerint, hiszen az adatfolyamok és csomagkapcsolt adatátvitelek egyenként maximum 29 quadletből állhatnak [A MOST 50 esetében alkalmazott átviteli protokoll].

4.20. ábra - A MOST 50 esetében alkalmazott átviteli protokoll

A MOST 50 esetében alkalmazott átviteli protokoll


  • A jelenleg legfejlettebbnek tartott MOST szabvány a MOST 150, amelynél a keret maximális hossza 3072 bit értékűre növekedett, így lehetővé téve a közel 6-szoros sávszélességet a legelső szabványhoz képest.

A MOST 150 magában foglal egy Ethernet csatornát (állítható sávszélességgel), az eredetileg kialakított csatornák mellett. A fejlett funkciói és megnövelt sávszélessége lehetővé teszi multiplex hálózati infrastruktúrák kialakítását, így a legmodernebb információs- és szórakoztató rendszerek probléma nélkül beépíthetőek.

Ezen protokoll esetén szintén 44,1 kHz-es mintavételi frekvencia alkalmazott, de már háromszoros sebességgel képes működni. A keretek hossza 3072 bit, amelyből 12 bájt a fejléc, a maradék 372 bájt pedig dinamikusan oszlik el az adatfolyamok és csomagkapcsolt adatátvitelek között. A szinkron adatfolyamok alkalmasak arra, hogy multimédiás adatokat valós időben továbbítsanak [A MOST 150 esetében alkalmazott átviteli protokoll].

Az adatokat ciklikusan továbbítjuk a hálózaton keresztül. Amennyiben kommunikációs hiba került észlelésre a hálózaton, akkor az adat továbbítása megszakad.

4.21. ábra - A MOST 150 esetében alkalmazott átviteli protokoll

A MOST 150 esetében alkalmazott átviteli protokoll


FlexRay

A FlexRay nem titkolt kezdeti célja a CAN bizonyos mértékű kiváltása, valamint az ún. x-by-wire „vezeték általi” (elektromos vezérlés, hagyományos mechanikus helyett) technológiák alkalmazási lehetőségeinek megteremtése volt. Már itt fontos megjegyezni, hogy a FlexRay protokoll viszonylag nagyteljesítményű és bonyolult felépítésű vezérlőt igényel. Ennek köszönhetően lassú az elterjedése, és többnyire ott alkalmazzák, ahol a CAN teljesítményét tekintve nem megfelelő.

A FlexRay esetében támogatott mind a nagy sebességű szinkron, mind az aszinkron átviteli mód is, melyekkel akár 10Mb/s-os vagy még magasabb sávszélesség is elérhető. A FlexRay-nek több verziója is elérhető, melyek közül a legelterjedtebb a 2.1-es és az afeletti verziók, melyek főbb jellemzői, illetve eltérései a korábbi verzióktól:

  • 2x10Mb/s sávszélesség a két, egyenként 10Mb/s sávszélességgel rendelkező kommunikációs csatorna támogatásával, így akár hússzor nagyobb sávszélesség is elérhető, mint a CAN rendszer esetében.

  • Idő szinkronizáltság, azaz az adathozzáférést idő szinkronizációhoz köti, melyet a protokoll végez automatikusan, hogy elérhetővé váljon az adat az alkalmazások részére. Az időalap (macrotick) pontossága 0.5-10 μs között van, általában 1-2 μs.

  • Ismert üzenetkésleltetés garantált szórással, vagyis a kommunikáció periodikusan ismétlődő körökből áll. Minden körben van egy speciális fix helyen lévő üzenet, melyből a vevő tudja mikor érkezett meg az adat, ezáltal a beérkezési idő igen jól becsülhető, és garantált a kis szórás.

  • Redundáns és nem redundáns kommunikáció támogatása. A FlexRay redundánsan továbbítja az egyes üzeneteket, hogy további rétegek számára is biztosítsa a hálózat megbízhatóságát. A programozható átviteli redundancia megengedi a tervezőnek, hogy redundáns továbbítást használjon, a lehető legjobb sávszélesség kihasználás érdekében.

  • Tervezéskor a fő hangsúly a rugalmasságra összpontosult. Szabadon választható meg, hogy redundánsan vagy nem redundánsan továbbítódnak az üzenetek. A rendszer optimalizálható használhatóságra, vagy teljesítményre mindezt úgy, hogy a rendszer kiterjeszthető a csomópont (node) beállításainak változtatása nélkül. Továbbá különböző busztopológiákat is támogat (busz, csillag…), valamint változtathatóak a beállítási paraméterei (üzenethossz, kommunikációs ciklus hossza, stb.), így beállítható a kommunikációs rendszer, hogy megfeleljen az alkalmazás követelményeinek.

A FlexRay arra lett tervezve, hogy kiszolgálja az új technológiákat és alkalmazásokat, de köszönhetően a nagy sávszélességnek és hálózati rugalmasságnak, teljesíti több jelenlegi, autoiparban használt alkalmazás szükségleteit is:

  • A CAN felváltása azokban az alkalmazásokban, ahol nagyobb sávszélességre van szükség, mint amit a CAN biztosítani tud, vagy ahol kettőnél több CAN buszt használnak párhuzamosan.

  • A nagy sávszélességnek köszönhetően, alkalmas az autók gerinchálózatának kialakításhoz, biztosítva a kapcsolatot a sok, különálló független hálózat között.

  • Valós idejű alkalmazásokra, és elosztott rendszerirányításra is alkalmas. A garantált időtartamú kommunikációs ciklusoknak és alacsony szórásnak köszönhetően, a FlexRay rendszer megfelel az elosztott rendszerek szigorú, valós idejű követelményeinek.

  • A FlexRay egymaga nem teszi a rendszert biztonságossá, de a variációk sokfélesége, amit a rendszer nyújt, teszi lehetővé a FlexRay alapú biztonság-orientált rendszerek fejlesztését, mint pl. a x-by-wire rendszerek.

Sok különböző módja van, hogy kialakítsunk egy FlexRay clustert (csomópontokból álló busz vagy csillag topológiájú kommunikációs rendszert). Lehet egy-, illetve kétcsatornás busz, csillag elrendezésű vagy hibrid megoldásokat is tartalmazó rendszer [Egy FlexRay hibrid topológiájú hálózat felépítése].

4.22. ábra - Egy FlexRay hibrid topológiájú hálózat felépítése

Egy FlexRay hibrid topológiájú hálózat felépítése


A protokoll rétegeinek szempontjából a FlexRay három réteget definiál: az alkalmazási, adatkapcsolati és fizikai réteget. Az átvitel során tipikusan minden egyes csatorna egy csavart érpárból áll, ahol a CAN-hez hasonlóan differenciális feszültségmérésen alapul a bitek átvitele.

Busz meghajtó (driver)

Az elektronikus busz meghajtó (BD) realizálja a fizikai kapcsolatot a FlexRay csomópont (node) és a csatorna között. A meghajtó biztosítja a küldést és fogadást a buszon a csomópont modulnak, kétirányú időmultiplexelt bináris adatfolyam továbbításához. A továbbítás és fogadás mellett a meghajtó szolgáltatja az eszközt az alacsony energiaszintű működéshez, a tápfeszültség figyeléséhez valamint a buszhiba detektálásához, továbbá védelmet nyújt az elektronikus vezérlőegység és a busz közötti elektromos kisülésekkel szemben.

4.23. ábra - A busz meghajtó belső logikai felépítése

A busz meghajtó belső logikai felépítése


A busz meghajtónak két fő működési módja van: a BD_Normal és BD_Standby, amelyeket kötelező implementálni. A fentieken kívül két további opcionális állapotot vehet fel a busz meghajtó, még pedig a BD_Sleep és a BD_Receive_Only módokat. Ugyanakkor ezek még tovább bővülhetnek egyéb termék-specifikus módokkal.

  • A BD_Normal módban a meghajtó normál módban fogadhat vagy küldhet adatfolyamot a buszon.

  • A BD_Standby mód egy alacsony energia felvételű készenléti állapot, melyben a meghajtó nem képes adatot küldeni és fogadni a buszról, de detektálni tudja az úgynevezett Wake-Up (ébresztési) eseményeket.

  • A BD_Sleep mód megegyezik az előbb leírt készenléti móddal, de itt a meghajtó kimenetén Sleep jelzés jelenik meg.

  • A BD_Receive_Only állapotban csak fogadni tudunk adatot, továbbítani nem.

A protokoll irányítása

A protokoll alapvető viselkedését négy fő mechanizmus szabályozza:

  • Kódolás és dekódolás (Coding and Decoding): Ha két csatornával rendelkezik minden csomópont, akkor szükség lesz két független halmazra a kódoló/dekódoló folyamatokhoz az A és B csatorna számára. A kódolás/dekódolás három folyamatból épül fel: egy fő kódolásból illetve dekódolásból (CODEC), és két alfolyamatból: bitválasztó folyamatból (BITSTRB), valamint felébresztési (Wake-Up) minta dekódolásból (WUPDEC). A bitválasztó folyamat dönti el, hogy mely csatornára kell továbbítani az adott jelsorozatot. A felébredési minta dekódolás feladata a speciális ébredési szimbólumok érzékelése, és a csomópont felébresztésének a megkezdése.

  • Közegelérés (Media Access Control): A FlexRay időosztásos multiplexelést használ a közegeléréséhez, ezzel megakadályozva a keretek ütközését. Ugyanakkor eseményvezéreltnek is kell lennie az igények szerint, amit úgy érnek el, hogy apróbb logikai egységekre bontják a rendelkezésre álló időt (statikus időosztásos mód (statikus szegmens), dinamikus mód (dinamikus szegmens), mely az eseményvezérelt rész, valamint a szimbólum ablak a hálózat vezérléshez), amely egységeknek viszont továbbra is az időosztásos multiplexelés elvét kell követniük. Így egy jól becsülhető késleltetésű rendszer kapható.

  • Keret és szimbólum feldolgozás (Frame and Symbol Processing)

  • Órajel szinkronizálás (Clock Synchronization)

Ezeket összefogva, a Control Host Interface (CHI) biztosítja a lehetőséget, hogy megszerkesztett formában férjen hozzá a csomópont a 4 fő protokoll mechanizmushoz, beleértve a protokollirányítást (POC, protocol control), ami visszacsatolást biztosít a csomópont (host) felé. A különböző mechanizmusokból néhány a későbbiek során részletesen is ismertetésre kerül.

Hibakezelés

A POC kétféleképpen reagálhat egy hibára. Súlyos/lényeges hiba esetén a POC egyből felfüggesztett (halt) állapotba kerül:

  • Termék specifikus hibák

  • Freeze parancs hatására hibához vezető feltételeket detektál a csomópont

  • Végzetes hibához vezető feltételek kerültek detektálásra a POC, vagy a fő folyamatban

A CAN-hez valamelyest hasonlóan a POC is tartalmaz egy 3 állapotú hibatűrő degradációs modellt, amely elvisel adott számú hibát egy időperiódusban. Ebben az esetben a POC nem kerül egyből felfüggesztett állapotba. Ez a modell annak érdekében lett kitalálva, hogy reagáljon bizonyos hibafeltételekre, amelyeket az óraszinkronizációs folyamat során érzékel, de nem igényel azonnali beavatkozást. Így hibatűrést lehet biztosítani a szinkronizáció során. Ezzel el lehet kerülni az azonnali felfüggesztést, így lehetőség nyílik a hiba nagyságának és természetének becslésére. Magát a modellt a következő három POC állapot alkotja:

  • Normál aktív állapotban a csomópont hibamentesen, vagy egy minimális hibahatáron belül működik. Ekkor megengedhető, hogy normál tartományban maradjon a POC. Vagyis ha a csomópont megfelelően van szinkronizálva egy kommunikációs rendszerhez, akkor folytathatja az átvitelt anélkül, hogy a többi csomópont átvitelét megszakítaná.

  • A normál passzív állapot esetén feltételezzük, hogy a szinkronizáció a klaszter többi részéhez képest alacsony. Ekkor a keret továbbítása nem folytatható, mivel az ütközéseket okozhatna a többi csomópont kereteinek átvitelében. A keretek fogadását tovább folytathatja a csomópont ebben az állapotban, hogy a csomópont elvégezze az újraszinkronizálást és ebből az átmeneti állapotból újra normál aktív állapotba kerüljön.

  • A felfüggesztett állapotba akkor lehet átlépni, ha további hibák kerültek detektálásra a passzív állapotban, vagy sok hiba fordult már elő. Ebből az állapotból már nem lehet visszakerülni egyből a normál aktív tartományba, ugyanis a POC leállítja a fő mechanizmusokat, hogy előkészítse és újrainicializálja a csomópontot.

Keretezés és keret felépítés

A FlexRay protokoll egyszerre idő- és eseményvezérelt. Ezt úgy lehet elérni, hogy a kommunikáció ciklusokra van osztva [FlexRay kommunikációs ciklus szerkezete], melyben van egy fix időosztásos szegmens (statikus szegmens) [Egy statikus szegmens felépítése], egy dinamikusan allokálható időosztásos rekeszeket (slot) tartalmazó szegmens (dinamikus szegmens) [Egy dinamikus szegmens felépítése] és egy szimbólum ablak [Egy szimbólum ablak felépítése], mely különböző hálózat irányítási feladatokat lát el. Ezenkívül a ki nem használt időt a kommunikációs ciklusban hálózati üres járásnak (NIT-nek) nevezik.

A statikus és a dinamikus szegmens valamint még a szimbólumablak is tovább bontható kisebb logikai egységekre. A statikus szegmens statikus rekeszekre (slot-okra) bontható, melyek meghatározott ütemhosszúságú logikai egységek, melyek előre meghatározott üzenetet tartalmazhatnak.

Dinamikus esetben minislotokról lehet beszélni, melyek meghatározott ütemhosszúságú logikai egységek. A statikus szegmens statikus rekeszeivel ellentétben nem előre rögzített, hogy melyik csomópont melyik rekeszt, milyen üzenet továbbítására használja, hanem igény szerinti dinamikus kiosztásúak is lehetnek.

A szimbólumablakon belül egyedülálló szimbólumot lehet küldeni. Választást különböző küldők között nem biztosít a protokoll a szimbólumablak számára, ha mégis szüksége lenne erre, akkor azt egy magasabb szintű protokoll fogja biztosítani számára.

4.24. ábra - FlexRay kommunikációs ciklus szerkezete

FlexRay kommunikációs ciklus szerkezete


4.25. ábra - Egy statikus szegmens felépítése

Egy statikus szegmens felépítése


4.26. ábra - Egy dinamikus szegmens felépítése

Egy dinamikus szegmens felépítése


4.27. ábra - Egy szimbólum ablak felépítése

Egy szimbólum ablak felépítése


A keretek küldése több különböző szekvenciára bontható szét:

  • Az átvitel kezdetét jelzi a TSS, azaz a Transmission Start Sequence. Arra szolgál, hogy kiépítse a megfelelő kapcsolatot a hálózaton keresztül. Egy küldő csomópont generál egy TSS-t, ami folytonos alacsony szintet generál meghatározott ideig.

  • A TSS követi a keret kezdetét jelző FSS-t, azaz a Frame Start Sequence, melynek a feladata, hogy kompenzálja a lehetséges kvantálási hibát az első BSS-ben az FSS után. Az FSS egy magas értéket fog tartalmazni meghatározott, névleges bit ideig. A csomópont hozzáfűzi az FSS-t a bitfolyamhoz, közvetlenül a küldendő keret TSS-e után.

  • A bájtok kezdetét jelöli a BSS, azaz a Byte Start Sequence, mely biztosítja az időzítési információkat a fogadó eszközöknek. A BSS tartalmaz egymás után egy magas és egy alacsony bitet, mindegyiket egyaránt a névleges bitidő idejéig. A keretben található adat minden bájtja egy kiterjesztett sorozatként továbbítódik, ami tartalmazza a BSS-t és az azt követő 8 adat bitet.

  • A FES, azaz Frame End Sequence jelöli meg az utolsó bájtsorozatot az adott keretben. Az FES tartalmaz egymás után egy alacsony és egy magas bitet, melyeket névleges bitideig tart fenn. A csomópont a lezárás jelzésére beszúr egy FES-t a bitfolyamba, közvetlenül a keret utolsó kiterjesztett bájtsorozata után.

  • Dinamikus keretek továbbítása esetén létezik csak a dinamikus nyomkövetésre szolgáló szekvencia, a DTS (Dynamic Trailing Sequence). A feladata, hogy jelezze a minislot akciópont (AP) (az akciópont egy pillanat az időben, melyben a csomópont végrehajt egy speciális akciót, hogy beállítsa a saját lokális időegységét) pontos helyét az időben, és megelőzze, hogy a csatornán a fogadó idő előtt detektáljon üresjáratot. Mikor dinamikus szegmensben történik egy keret elküldése, akkor a csomópont a DTS-t közvetlenül a keret FES sorozata után küldi el. A DTS két részből áll: egy változó hosszúságú periódus a TxD (a TxD - Transmit Data - jel feladata, hogy továbbítsa az aktuális jelsorozatot a buszmeghajtó felé, mely a kommunikációs csatornára helyezi a továbbítandó adatot) kimenet alacsony szintjéhez, ezt követi egy fix hosszúságú periódus a TxD kimenet magas szintjéhez. Az alacsony szintű periódus minimális hossza egy nominális bitidőnyi időtartam. Ezután a minimális hossz után a csomópont a TxD kimenetet alacsony szinten hagyja a következő minislot akciópontig, ahol is a csomópont a TxD kimenetet magas szintre állítja és egy névleges bitidőnyi késleltetés után a TxEN (a TxEN - Transmit Data Enable Not - jelzi a buszmeghajtó felé, hogy a megfelelő csatorna TxD vonalát engedélyezze, hogy adatot küldhessen rajta) kimenetet is magas szintre állítja. A DTS hossza változó: két névleges bitidőnyi időtartamtól egészen két névleges bitidőnyi időtartamig, egy minislot időtartamáig terjedhet.

Maga a FlexRay keret több részből épül fel [FlexRay keret]:

  • A fenntartott (Reserved) bit egy 1 bites mező, mely a jövőbeni protokoll bővítésére van fenntartva. Ha az alkalmazás nem használja, akkor a küldő csomópont 0-ra állítja és a fogadó csomópont pedig figyelmen kívül hagyja a fenntartott bitet.

  • A fenntartott bitet az adatbevezető indikátor (Payload preamble indicator) követi, mely szintén 1 bit hosszúságú. Azt jelzi, hogy a továbbítandó keret tartalmaz-e egy opcionális vektort az adatszegmensben.

  • Az üres keret indikátor (Null frame indicator) 1 biten jelzi, hogy a továbbítandó keretünk tartalmaz-e hasznos adatot, vagy sem. Egy üres keretet fogadó csomópont mégis információt kaphat a keretet illetően.

  • Szinkronizációs keret indikátor (Sync frame indicator) szintén egy 1 bites jelző flag, melyet a szinkronizációs folyamatokhoz használ a protokoll.

  • Az indító keret indikátor (Startup frame indicator) 1 biten megadja, hogy indító keret érkezett-e vagy sem. Ezeknek a kereteknek speciális feladatuk van az indító mechanizmus folyamán.

  • A keretazonosító (Frame ID) egy 11 bites mező, mely definiálja, hogy az adott keret melyik slot-ba kerül továbbításra. Minden egyes keretazonosító csak egyszer használható egy csatornán egy kommunikációs ciklus alatt, valamint minden egyes keret amely továbbítódik, kell hogy kapjon egy azonosító számot.

  • Az adathossz (Payload length) mező 7 biten adja meg az adatszegmens hosszát. A benne kódolt információ az adatszegmens hosszának a felét adja meg bájtban, de nem tartalmazza a fejléc, illetve a záró szegmens hosszát.

  • A fejlécre vonatkozóan van egy 11 bites ellenőrző összeg, azaz CRC mező, mely a kiszámításakor figyelembe veszi a szinkronizációs keret és indító keret indikátor, keretazonosító és adathossz mezőket.

  • A ciklusszámláló (Cycle count) 6 biten jelzi a küldő csomópont számára a ciklusszámláló értékét (0 – 63) a küldés pillanatában. A továbbítása pedig a legmagasabb helyi értékkel kezdődik.

  • Az adatszegmensben (Payload segment) továbbítódik a tényleges információ, mely 0 – 127 db kétbájtos szót tartalmaz. Ezért mindig páros számúnak kell lennie a továbbított bájtoknak, mivel a fejrészben tárolt Adathossz mező is a továbbított adat hosszának felét tárolja.

  • A zárószegmens (Trailer segment) vagy hibaellenőrző tag egy 24 bites CRC ellenőrző összeget tartalmaz az egész keret számára, amit a fejléc és adat szegmensekből számol, figyelembe véve minden értéküket.

4.28. ábra - FlexRay keret

FlexRay keret


Mintavételezés és többségi szavazás (Majority voting)

A fizikai jellegű hibák kiküszöbölésére szolgál a többségi szavazás, többszöri mintavételezés segítségével. A csomópont mintavételezi az RxD (a buszmeghajtó használja az RxD - Receive Data - jelet, hogy továbbítsa az aktuálisan fogadott adatokat) bemenetet úgy, hogy az egyes mintavételezési periódusokban a csomópont mintát vesz és tárolja az RxD bemenet értékét.

A csomópont a mintavételezett RxD jelen hajtja végre a többségi szavazást. Az eljárás célja, hogy szűrje a bemeneti jelet, azaz a zajokból származó téves értékek számát csökkentse. Itt a zaj alatt olyan esemény értendő, ami megváltoztatja az aktuális állapotát a fizikai rétegnek oly módon, hogy az észlelt logikai állapotot átmenetileg megváltozatta egy érték, ami különbözött a küldöttől.

A dekóder folyamatosan értékeli az utolsó eltárolt mintát, és számolja a magas szintű minták számát. Ha a minták többsége magas szintű volt, akkor az ún. szavazó egység kimenet magas szintet fog adni, egyébként alacsony szintet küld [A FlexRay többségi szavazás algoritmusának a szemléltetése].

4.29. ábra - A FlexRay többségi szavazás algoritmusának a szemléltetése

A FlexRay többségi szavazás algoritmusának a szemléltetése


Óra szinkronizáció

Mivel a FlexRay protokoll időosztásra épít és nem központi időt használ, így fontos, hogy minden csomópont (host) szinkronizálja a belső óráját. Ezt a feladatot két párhuzamosan futó folyamat, a macrotick ütemgeneráló (Macro Tick Generator = MTG), és az óra szinkronizációs folyamat (Clock Synchronization Process = CSP) látja el [A FlexRay óra szinkronizáció mente].

4.30. ábra - A FlexRay óra szinkronizáció mente

A FlexRay óra szinkronizáció mente


Az idő felépítése egy csomóponton belül ciklusokon, macrotick és microtick ütemeken alapszik. Egy makroticket egész számú mikrotick alkot és egy ciklus egész számú makroticket tartalmaz [A macro- és microtickek felépítése]:

  • A microtickek (mikró ütemek) olyan kontrollerspecifikus időegységek, melyeket a kontrollerhez tartozó oszcillátor állít elő. Időtartamuk kontrollertől függően változik. A csomópontok belső idejének finomságát adják.

  • A macrotickek (makró ütemek) szinkronizálása klaszter alapú. Toleranciahatáron belül, egy makrotick időtartama azonos minden szinkronizált csomópontra a klaszteren belül. A macrotickek hossza a microtickek egész számú többszöröse, ahol a microtickek száma minden macrotickben más és más egy csomóponton belül. A microtickek száma egy macrotickben minden csomópontra más, és ezt a számot az oszcillátorok frekvenciája határozza meg. Annak ellenére, hogy bármely macrotick egész számú microticket tartalmaz, az átlagos hossza a makro ütemnek egy cikluson belül nem egész számú lesz.

  • A ciklus egész számú macroticket tartalmaz, melyek száma azonos minden csomópontban egy cikluson belül, és ugyanaz marad ciklusról ciklusra. Bármely időpillanatban a csomópontoknak ugyanaz a ciklusszámuk.

4.31. ábra - A macro- és microtickek felépítése

A macro- és microtickek felépítése


Az ismert eljárások, melyek az időszinkronizációt végzik, a csomópontok között fázis vagy frekvencia korrekciót használnak. A FlexRay ezen műveletek kombinációját használja. A következő feltételeknek kell teljesülnie:

  • A frekvencia-, és fáziskorrekciónak hasonló módon kell zajlania minden csomópont esetén. A frekvenciakorrekciót az egész ciklus alatt kell végezni.

  • A fáziskorrekciót a NIT alatt kell végrehajtani, mindig csak a páratlan ciklusokban, és be kell fejezni, mielőtt a következő ciklus kezdődne.

  • A fázisváltozást a microtickek száma jelzi, melyeket hozzá kell adni a NIT fáziskorrekciós szegmenséhez, mely akár negatív is lehet. A kiszámítása minden ciklusban időt igényel, de a korrekciót csak minden páratlan ciklus végéhez kell hozzáadni. A fáziskorrekció kiszámítása egy ciklusban értékek mérésén alapul. Ezt a számítást nem lehet befejezni a NIT előtt, de elkezdeni már a dinamikus szegmensen vagy szimbólumablakon belül is lehet addig, ameddig a számítás visszacsatolása késleltetve van a NIT-ig. A számítást be kell fejezni, mielőtt a fáziskorrekciós fázis folytatódna.

  • A frekvencia (rate) megváltozását microtickek száma jelzi, melyeket hozzá kell adni a kommunikációs ciklusban definiált microtickek számához, mely akár negatív is lehet. Értékét az óraszinkronizációs folyamat határozza meg, és csak egyszer kell kiszámolni dupla ciklusonként. Számítása időt igényel, páratlan ciklusokban a statikus szegmenset követően. A számítás páros és páratlan dupla ciklusokban történő értékek mérésén alapul. Ezt a számítást nem lehet befejezni a NIT előtt, de elkezdeni el lehet már a dinamikus szegmensen vagy szimbólumablakon belül addig, ameddig a számítás visszacsatolása késleltetve van a NIT-ig. A számítást be kell fejezni, mielőtt a következő páros ciklus elkezdődne.