Autóipari hálózatok A gépjárművek fedélzeti rendszereiben a vezérlőegységek megjelenésével felmerült az igény ezek összekötésére valamely kommunikációs hálózatok segítségével. Az elmúlt évtizedekben több hálózati protokollt is kidolgoztak kifejezetten autóipari felhasználásra. A továbbiakban a kommunikációs rendszerek alapfogalmait tárgyaljuk, majd a legelterjedtebb protokollokat mutatjuk be.
A kommunikáció alapjai A beágyazott komponensek közötti kommunikáció megértéséhez segítséget nyújtanak az alábbi alapfogalmak.
Alapfogalmak A kommunikáció alatt több szoftver vagy hardver elem közötti interakciót értünk. A hálózati kommunikáció alatt olyan kommunikációt értünk, mely vezérlőegységek között valósul meg. A kommunikáció csatornákon keresztül történik. Egy-egy csatorna egy hálózatnak felel meg, melyre a vezérlőegységek (hálózati terminológiában csomópontok) kapcsolódnak. A kommunikáció során általában valamilyen információt osztanak meg az alrendszerek. Az autóiparban ezeket jeleknek nevezzük (utalva arra, amikor az egyes jeleket dedikált vezetéken továbbították). A jelek aktuális értékét visszük át a hálózaton. Mivel az egyes jelek általában kis bitszámon ábrázolhatóak, a sávszélesség jobb kihasználása érdekében a logikailag összetartozó (vagy közösen használt) jeleket úgynevezett PDU-kba (protocol data unit – protokoll adategység) szervezik. Ezek mérete már jobban illeszkedik a hálózati protokollok csomagméretéhez, ezért hatékonyabban lehet kihasználni a rendelkezésre álló hálózatot. A hálózaton küldött üzeneteket kereteknek (frame) is hívjuk. Ezek egy vagy több PDU-ból (nagy keretméret esetén) állnak. A keret adat része kiegészül a protokoll specifikus fejrésszel és farok résszel is.
Kommunikációs minták Az autóipari rendszerekben (és általában minden beágyazott rendszerben) néhány jellemző kommunikációs mintával találkozhatunk.
7. ábra Üzenet alapú kommunikáció
A legegyszerűbb kommunikációs minta az egyirányú üzenetküldés. Ebben az esetben egy küldő üzeneteket (lásd 7. ábra) küld egy vagy több vevőnek. Az üzenet tartalma tetszőleges, de a felek által egyformán értelmezett kell legyen. Fontos, hogy ebben az esetben információ mindig csak a küldőtől folyik a vevő felé, nincs ellentétes irányú forgalom. A távoli eljáráshívás (lásd 8. ábra) során egy vagy több hívó (kliens) veszi igénybe egy hívott (szerver) szolgáltatását. Ez a forma hasonló a normál függvényhíváshoz, de hálózaton keresztüli megvalósítással. A kliens egy hálózati üzenetbe kódolja a híváshoz szükséges információt (függvény és kliens azonosító, bemenő argumentumok), majd elküldi ezt a szervernek. A szerver végrehajtja a kiválasztott függvényt a megadott argumentumokkal, majd egy üzenetben visszaküldi a visszatérési értéket és a kimenő argumentumok értékét.
8. ábra Távoli eljáráshívás Az adatfolyam kommunikáció (lásd 9. ábra) során egy folyamatos információ folyamot valósítunk meg a küldő és a fogadó között. A kommunikáció során általában nem az egyes üzenetek mérete vagy periódusa lényeges, hanem a folyam sávszélessége és késleltetése. A vevő gyakran képes a folyam szabályozására annak megfelelően, hogy a puffere milyen állapotban van. Ezt a kommunikációs módot általában video és audio jelfolyamok továbbítására használják.
9. ábra Adatfolyam kommunikáció
Üzenet szemantika A hálózaton küldött üzeneteknek kétféle szemantikájuk lehet. Az állapot szemantika szerint az üzenet mindig a hozzá tartozó változó (jel) aktuális értékét közvetíti. Ebben az esetben a vevő a legutolsó üzenet alapján mindig a lehető legfrissebb értéket használhatja, és az előző értékeket nem kell figyelembe vennie. Esemény szemantika esetén az üzenetek a hozzá tartozó változó (jel) változását közvetítik, azaz azt, hogy az előző üzenet óta mennyivel változott az érték. A vevőnek ebben az esetben minden üzenetre szüksége van, hogy a jel aktuális értékét ki tudja számolni (és az üzenetek elvesztése kritikus).
Az 2. Táblázat egy elképzelt sebességjel változását mutatja, valamint a folyamat során küldött állapot és esemény üzeneteket. Érdemes megjegyezni, hogy az állapot üzenetek fő előnye a) a kisebb számítási igény (nem szükséges az egymás utáni értékeket összeadni, és b) az üzenet vesztés tolerálása. Az esemény üzenet előnye, hogy ha a jelváltozás viszonylag lassú, kevesebb bit kell a különbség átviteléhez, mint az érték átviteléhez. Jel (km/h) Állapot üzenet Esemény üzenet
0
2
4
7
10
12
8
5
0
2
4
7
10
12
8
5
0
2
2
3
3
2
-4
-3
2. táblázat Állapot és esemény üzenetek
Üzenet átvitel Az egyes üzenetek átvitele többféleképpen szervezhető. Idővezérelt ütemezésről beszélünk, ha az üzenetek átvitele periodikusan, (általában) előre meghatározott időközönként történik. Esemény-vezérelt ütemezés esetén az üzenetek átvitele valamilyen esemény hatására indul. Tipikusan ilyen a tartalmazott jel(ek) megváltozása. Idővezérelt ütemezés esetén a kommunikációs csatorna terhelése egyenletes, sok esetben elkerülhetőek az ütközések (amikor egyszerre több csomópont használná egyszerre a csatornát), egyszerűen számíthatóak az üzenet késleltetések. Hátránya az, hogy akkor is átvisszük az egyes jeleket, ha nem változtak, illetve a minimális késleltetési idő hosszú (a periódusidővel egyenlő). Eseményvezérelt ütemezés esetén a kommunikációs csatorna kihasználtsága dinamikusan változik (az éppen bekövetkezett események függvényében), előfordulnak ütközések is. Emiatt nehezebb a maximális késleltetés kiszámítása, a rendszer működése nehezebben jósolható. Előnye viszont, hogy a jeleket csak szükség esetén továbbítjuk, és a minimális késleltetés alacsony (a jel megváltozása után rögtön küldhetjük az üzenetet).
Topológia A hálózatok többféle fizikai elrendezésben is megvalósíthatóak (11. Ábra).
11. ábra Hálózati topológiák. a) busz, b) gyűrű, c) csillag, d) vegyes (csillag + busz) A busz topológia esetén az átviteli közeget megosztottan használják a hálózatra kapcsolódó csomópontok. Ha egy csomópont üzenetet küld, akkor senki más nem küldhet, és az üzenetet minden csomópont veszi. A gyűrű topológia esetén minden csomópont két másikhoz kapcsolódik, ezáltal egy logikai gyűrűt valósítanak meg. Az üzeneteket a csomópontok a szomszédjuknak továbbítják, amíg az a címzetthez nem ér. Mivel a csomópontok terhelése ebben az esetben jelentős, nem alkalmazzák széleskörűen. A csillag topológia esetén minden csomópont egy központi elemhez (kapcsoló, csillag csatoló, stb.) kapcsolódik, egy-egy dedikált kapcsolaton keresztül. A központi elem vagy csak egyszerű ismétlő (repeater), azaz közvetlenül megismétli a bemenetén érkező jelsorozatot, vagy intelligens kapcsoló (switch). Utóbbi esetben képes az egyes üzenetek szelektív továbbítására (csak bizonyos csomópontok kapják meg), és átmeneti tárolására is (amennyiben a cél csomópont csatornája foglalt). Természetesen elképzelhető vegyes (mixed) topológia is, ahol a csillag egy-egy ágára több csomópont kapcsolódik. Összességében elmondható, hogy míg a busz megvalósítása alacsony költségű (a vezetékezés minimális, nincs külön elem), ez az elrendezés érzékeny a meghibásodásokra (egy zárlat esetén minden kommunikáció leáll), és a sávszélessége is kisebb (egy üzenet vihető át egy időben). A csillag megvalósítása egy dedikált központi elemet és több vezetékezést igényel, de a meghibásodásoknak kevésbé kitett, és összességében (intelligens kapcsoló esetén) nagyobb sávszélességű kapcsolatot biztosít. A topológia kiválasztásakor az is fontos szempont, hogy míg rézvezetőkkel minden topológia megvalósítható, az egyre inkább terjedő optikai kábelek segítségével csak a gyűrű és csillag topológiák építhetőek fel. Amennyiben több hálózatot kell összekapcsolni, úgynevezett átjárókat (gateway) alkalmazunk. Ezek előre meghatározott szabályok alapján végzik a csomagok szelektív továbbítását (routing).
Controller Area Network (CAN) A CAN protokollt a Robert Bosch Gmbh dolgozta ki. Jelenleg a 2.0-s változatát [4] használják széles körben. A protokoll egy soros, busz topológiájú adatkommunikációs csatornát definiál, melyre több (vezérlőegység csatlakozhat. A busz maximális sebessége 1Mbps. Fontos fejlesztési cél volt, hogy jól skálázódjon és kis költséggel megvalósítható legyen.
Alapvető koncepciók A CAN protokoll az alábbi fő elvekre épül: • Üzenetek priorizálása – minden üzenethez egy prioritást rendelünk. A nagyobb prioritású üzenet elsőbbséget élvez a buszon • Késleltetési idők garantálása – minden üzenethez meghatározható a legnagyobb kommunikációs késleltetés (hibamentes esetben) • Rugalmas konfiguráció • Multicast vétel időszinkronizációval • Multimaster – több olyan csomópont lehet a buszon, mely kommunikációt kezdeményezhet • Hibadetektálás és –jelzés • A sérült üzenetek automatikus újraküldése, amint a busz szabaddá válik • Az átmeneti és állandósult hibák megkülönböztetése, a hibás csomópontok leválasztása
Csomópont modell A CAN szabvány az ISO/OSI rétegzett modellnek megfelelően specifikálja egy CAN csomópont szerkezetét. A fizikai réteg (physical layer) felelős a bitek konkrét küldéséért és fogadásáért, valamint az alacsony szintű szinkronizációért. A CAN specifikáció nem határozza meg a fizikai meghajtó és vevő eszközök tulajdonságait, hogy a későbbiekben többféle fizikai réteget is használhassanak. Az adatkapcsolati réteg (data link layer) két alrétegre osztható. A közeg-hozzáférési réteg (media access control – MAC) valósítja meg a CAN protokoll magját. A fogadott üzeneteket továbbítja a felsőbb rétegek számára, illetve elküldi a kimenő üzeneteket. Ez a réteg felelős az üzenet keretezéséért, a hibadetektálásért és – kezelésért, valamint a fogadás nyugtázásáért is. A MAC réteget egy hibakezelő felügyeli, mely képes a tranziens és állandósult hibák megkülönböztetésére, és szükség esetén leállítja a csomópont működését.
12. ábra CAN csomópont modellje A logikai kapcsolat kontroll (Logical Link Control – LLC) alréteg felelős a bejövő üzenetek szűréséért, a túlterhelés jelzéséért, és a hiba utáni helyreállításért. A CAN üzenetek kötött formátumúak, de változó hosszúságúak (lásd később). Ha a busz szabad, bármely csomópont indíthat adást. A CAN hálózatok nem tartalmaznak csomópont azonosítókat vagy címeket, ehelyett az üzeneteket azonosítják. Ez jelentősen növeli a rendszer rugalmasságát, mivel egyes csomópontokat elvehetünk, hozzáadhatunk, vagy lecserélhetünk a teljes rendszer újrakonfigurálása nélkül is. Az üzenetek szűrése szintén az azonosító alapján történik. A CAN protokoll alapvetően multicast (többes) üzenetküldésre épül. Egy elküldött üzenetet több csomópont is fogadhat és felhasználhat egy időben. A megosztott buszra épülő hálózat az adatkonzisztenciát is biztosítja: egy üzenetet vagy senki sem fogad, vagy mindenki. Ezáltal a többes küldés során alkalmazandó hibakezelés nagyban egyszerűsödik.
Üzenetek A CAN 2.0b protokoll kétféle keretformátumot támogat, melyek az üzenet azonosító hosszában különböznek. A standard keretek azonosítója 11 bit, a kiterjesztett (extended) kereteké pedig 29. Az kommunikáció mindkét formátum esetében négyféle keret segítségével történik. Az adat keretek (data frame) adatátvitelt valósítanak meg a küldő és a fogadók között. A távoli keret (remote frame) segítségével egy fogadó kérheti az adott azonosítójú adat keret küldését. Hibakereteket (error frame) azon csomópontok továbbítanak, melyek hibát érzékelnek a buszon. Túlterhelési keretek (overload frame) segítségével lehet plusz késleltetést beszúrni a normál keretek közé, ezzel csökkenteni a busz terhelését.
Adat keretek A CAN adatkeretek hét részből állnak (lásd 13. Ábra).
13. ábra: CAN adat keret részei [4] A keret kezdete (Start of Frame) rész, mely az adat vagy távoli keretek kezdetét jelzi, egyetlen domináns bitből áll. Egy csomópont akkor kezdhet el adni, ha a busz tétlen (interframe space – keretek közötti hely). Az összes vevő a keret kezdet bit lefutó élére szinkronizálódik. Az arbitrációs mező (arbitration field) különbözik standard és kiterjesztett keretek esetén. Standard formátum esetén ez a mező a 11 bites azonosítót és az RTR bitet tartalmazza, míg kiterjesztett formátum esetén a 29 bites azonosítót, az RTR, az IDE, és az SRR biteket is. Ezek jelentése a következő: • RTR: remote transmit request. Azt jelzi, hogy a keret egy távoli keret, vagy egy normál keret. • IDE: Azt jelzi, hogy a keret standar vagy kiterjesztett formátumú-e. • SRR: Kiterjesztett keret esetén az RTR bit helyén áll, mindig recesszív értékű, így a sztenderd keretek mindig magasabb priotitásúak, mint a kiterjesztettek.
A CAN üzeneteknek jól meghatározott felépítésük van. Egy normál (adat) üzenet az alábbi elemekből épül fel: • Azonosító (ID) 11 vagy 29 bit (sztenderd vagy kiterjesztett formátum) • Adathossz kód (0-8) • Adatbyte-ok (0..8 darab) • CRC kód • ACK (üzenet fogadója állítja) Az üzenetek azonosítója egyben a prioritást is meghatározza. Minél kisebb az azonosító, annál nagyobb az üzenet prioritása. Az úgynevezett távoli keretek (remote frames) arra szolgálnak, hogy egy bizonyos üzenet vevője kezdeményezze az üzenet átvitelét. A küldő a távoli keret vétele után elküldi a kért üzenetet. A hiba keret (error frame) átviteli hiba jelzésére szolgál.
Local Interconnection Network (LIN) A LIN protokoll [5], egy egyszerű, egyvezetékes soros kommunikációs csatornát definiál, ami a szabvány soros UART (Universal Asynchronous Receiver/Transmitter) megoldásra épül Ezen egységes majd minden mikrokontrollerben megtalálhatóak, vagy szoftveresen is könnyen megvalósíthatóak. FPGA és ASIC technológiák esetén pedig egyszerűen, kis helyigénnyel integrálhatóak. A közeghozzáférést a hálózatban a dedikált mester (master) csomópont vezérli, ezért a többi – szolga (slave) – csomópontban nincs szükség arbitráció vagy ütközés menedzsmentre, így lehetővé válik garantált válaszidők és jel-késleltetés számítására. A LIN protokoll egyik egyedülálló tulajdonsága egy speciális szinkronizációs megoldás, melynek segítségével el lehet hagyni a költséges kvarc vagy kerámia rezonátorokat a szolga csomópontokból. Ebből, és az elektromágneses követelményekből adódóan a busz sebessége alacsony, maximum 20 kbit/s. A sebesség és alacsony implementációs költség meghatározza a tipikus felhasználási területeket: intelligens beavatkozók (ajtózár, ülésfűtés, -mozgatás) szenzorok (hőmérséklet, mozgás), és kezelőszervek (kormány gombok, klíma kezelőpanel). Mivel a szolga csomópontok nem tárolnak semmiféle információt a hálózat struktúrájáról, könnyen integrálhatóak már meglevő rendszerbe, a többi csomópont változtatása nélkül (kivéve a mestert).
Kommunikációs koncepció A LIN hálózat minden csomópontján található egy szolga taszk, mely küldő és fogadó részre osztható fel. Emellett a mester csomóponton található egy mester küldő taszk is. Ahogy az alábbi ábrán is látható, a kommunikációt mindig a mester taszk kezdeményezi. A mester egy üzenet fejlécet küld ki, mely a szinkronizációs szünetből, a szinkronizációs mezőből, és az azonosítóból áll. Pontosan egy szolga aktiválódik a fogadás és az azonosító szűrése után, és megkezdi a válaszüzenet küldését. Ez 1-8 adat byte-ból és egy ellenőrző összegből áll. A teljes LIN üzenet keret a fejlécből és a válaszból áll.
14. ábra LIN keret átvitele A LIN üzenetek azonosítóval rendelkeznek, melyek (hasonlóan a CAN azonosítókhoz), nem a csomópontot, hanem az üzenetet azonosítják, így többféle kommunikációs minta is megvalósítható. A mester küldhet információt egy vagy több szolgának (a saját szolga taszkjának segítségével), a szolgák is küldhetnek a mesternek, vagy szolga-szolga kommunikáció is kialakítható, anélkül, hogy az üzeneteket a mesternek kellene átjátszania.
A kommunikáció ütemezése Az üzenetváltás ütemét a mester taszk szabályozza. A LIN hálózatok idővezérelt módon működnek, amit egy ütemező tábla vezérel. A tábla időzítését a bázis idő (Tbase) adja meg. Ennek értéke jellemzően 5 vagy 10ms. Az üzenet szlotok ennyi időnként kezdődhetnek. A csúszás (jitter) az az időtartam, mely a bázis időponttól a szinkronizációs mező kezdetéig tart. Hasonlóan a keretek közötti idő (inter-frame space) a keret végétől a következő keret kezdetéig tartó idő. Az ütemező tábla meghatározza a keretek küldésének idejét. A hálózatban egy időben egy aktív ütemező tábla van, de ezt lehet váltani (igazodva például a gépjármű állapot-változásához). A LIN protokoll többféle kerettípust definiál, a továbbiakban ezeket vizsgáljuk meg részletesebben. A normál (unconditional) keretek adatértékeket hordoznak, azonosítójuk pedig a 0..59 tartományba esik. Ezeket a kereteket mindig továbbítják, amikor ahhoz a szlothoz ér az ütemező tábla feldolgozása, amelyikhez az adott keret hozzá lett rendelve. A mester taszk tehát mindig elküldi a keret fejlécet, amire a küldő szolga taszk minden esetben válaszol az adat és ellenőrző összeg mezőkkel. Minden vevő feldolgozza a keretet, és a benne foglalt értékeket az alkalmazás rendelkezésére bocsátja. Az eseményvezérelt (event-triggered) kereteket ritkán változó jelek átvitelére használjuk, hogy ezzel busz sávszélességet takarítsunk meg, mivel egy szlotban több szolga is küldhet adatot (nyilván egyszerre csak egy). A mester ugyanúgy elküldi a keret fejlécet, mint a normál esetben, de a küldő szolgák csak abban az esetben válaszolnak, ha legalább egy, a keretükben levő jel változott. A válaszoló szolgák száma szerint több esetet is megkülönböztethetünk:
•
•
•
Egyetlen szolga sem küld adatot: a keret nem kerül elküldésre, a vevők nem kapnak új adatot. Ez azt jelzi, hogy egyetlen jel sem változott, amit el kellett volna küldeni Egy szolga küldött adatot: a keret megjelenik a buszon, a vevők ugyanúgy dolgozzák fel, mint a normál keretek esetén. A küldő pedig megjelölheti elküldöttként az összes, a keret által tartalmazott jelet. Több szolga küldött adatot: a buszon ütközés történik. A mester ezt észleli, és egy speciális ütközésfeloldó ütemező tábla végrehajtását kezdeményezi. Ennek során az össze küldő dedikált szlotban elküldheti a keretét, majd az eredeti ütemező tábla végrehajtása folytatódik.
15. ábra Ütközésfeloldás esemény-vezérelt keretek küldésekor A sporadikus (sporadic) keretek segítségével szintén sávszélességet lehet megtakarítani. Egy szlothoz több keretet lehet rendelni, és mindig az kerül elküldésre, melyben legalább egy jel változott (ha több ilyen keret van, akkor a legnagyobb prioritású). Mivel sporadikus kereteket csak a mester küldhet, mindig tudja, mely keret kerül majd elküldésre, és ennek megfelelő fejlécet fog küldeni. A diagnosztikai (diagnostics) keretek a transzport protokoll részei (azonosítójuk: 60, 61). Az üzenetek tartalmát a protokoll leírása adja meg. A mester az általa küldendő keretek fejlécének küldése előtt lekérdezi az aktuális diagnosztikai módot a saját diagnosztikai moduljától, és ennek értékétől függően küldi a keretet, vagy marad csendes. A szolga keret fejlécét minden esetben elküldi. A 62-es és 63-as azonosítók fenntartott (reserved) kereteket jelölnek, melyeket tilos a buszon átküldeni.
FlexRay A FlexRay protokoll létrehozásakor a fő cél az volt, hogy egy gyors és megbízható autóipai kommunikációs rendszert hozzanak létre. A már elterjedt CAN elérte határait sávszélesség tekintetében, illetve a különböző kiegészítések (például az idővezérelt TT-CAN), nem kínált megfelelő megoldást a megbízható, determinisztikus üzenetküldésre, ami az integrált rendszerek kialakítását gátolta, illetve bizonyos biztonság-kritikus funkciók megvalósítását nehézkessé tette.
Főbb jellemzők A FlexRay protokoll [6] fő jellemzői a következőek • 10Mbps maximális sebesség • egy vagy két csatorna (sávszélesség vagy megbízhatóság) • idővezérelt üzenetek átvitele • eseményvezérelt üzenetek átvitele • ütközés elkerülő protokoll
Hálózati topológia A FlexRay szabvány többféle topológiát támogat, melyek közül szabadon kiválaszthatjuk a konkrét alkalmazáshoz optimális megoldást.
Passzív busz
16. ábra Passzív busz topológia A legegyszerűbb elrendezés a passzív busz, melyben minden csomópont egy közös buszra kapcsolódik. A csomópontok lehetnek egy vagy két csatornásak, az adott alkalmazástól függően. A busz csak egy egyszerű kábel, nem tartalmaz semmilyen aktív eszközt.
Aktív csillag
17. ábra Aktív csillag topológia Az aktív csillag topológiában két központban fut össze a két csatorna. A központi egység (csillag), aktív elem, melynek segítségével az ágak közötti kommunikáció során helyre lehet állítani a jelalakokat és a jelszintet, valamint (a kisebb ágak, és
áganként egy csomópont miatt) a rendszer zavarérzékenysége is növekszik. Hátránya a nagyobb kábeligény és a csillagok költsége.
Kaszkád csillag topológia
18. ábra Kaszkád csillag elrendezés A szabvány támogatja a kaszkád csillag elrendezést is, amennyiben bármely csatornán bármely két csomópont között maximum két csillag helyezkedik el. Ezzel az elrendezéssel optimalizálni lehet a kábeligényt, két újabb aktív eszköz bevezetése árán.
Hibrid topológia A szabvány lehetővé teszi a fenti topológiák keverését is, például a csillag egy ágára több csomópont elhelyezését, vagy a két csatorna eltérő topológiával való megvalósítását. Fontos azonban megjegyezni, hogy a konkrét elrendezést ellenőrizni kell a szabvány elektromos specifikációjában leírtaknak megfelelően, ugyanis például a kábelhosszakból és átjátszókból adódó késleltetésekre szigorú határértékek vannak.
Egy csomópont felépítése
19. ábra. Egy FlexRay csomópont felépítése A csomópont a kommunikációs csatornához a buszmeghajtókon (bus driver) kapcsolódik. Ezekből csatornánként egy található a csomópontban. A meghajtók a jelszintek illesztését végzik a csomópont és a busz között. A protokoll kezelését és az adatok küldését-fogadását a kommunikációs kontroller (communication controller) végzi, valamint vezérli a meghajtókat. A gazdagép (host) jelképezi a hálózat felhasználóját, azt a processzort, mely az adatokat állítja elő, illetve fogyasztja. Ezen kívül vezérli a kommunikációs kontrollert és a buszmeghajtókat is. A tápegység is kitüntetett szerepet kaphat, mivel az alvó üzemmódban a tápegység általában megszakítja a csomópont tápellátását a buszmeghajtó kivételével. A buszmeghajtó képes érzékelni a hálózaton a speciális ébresztő jeleket (wakeup pattern), és utasítja a tápegységet a normál üzemmódra való átkapcsolásra. Ezután a gazdagép feladata, hogy vezérelje a különböző egységek bekapcsolását, inicializálását, beállítását.
A protokoll működése A FlexRay kommunikációs hálózat alapvetően egy periodikus kommunikációs mintára épül. Ennek alapegysége a TDMA (Time Division Multiple Access) kör. 64 ilyen kört definiálhatunk, ami után a kommunikációs minta ismétlődik.
20. ábra Egy TDMA kör felépítése Egy TDMA kör négy részből tevődik össze. A statikus szegmensben (static segment) statikus, időalapú közeghozzáférést biztosít a protokoll. Itt tipikusan periodikus üzeneteket forgalmaznak, melyek késleltetése is determinisztikus. A dinamikus szegmensben (dynamic segment) úgynevezett miniszlot alapú közeghozzáférést
használ a protokoll, mely lehetővé teszi a sávszélesség jobb kihasználását azáltal, hogy az éppen nem küldött üzenetek ablakait dinamikusan lerövidíti, így a kisebb prioritású üzenetek számára sávszélesség szabadul fel. A szimbólum ablak (symbol window) egyetlen szimbólum átvitelére szolgál. Az üresjárati idő (network idle time) alatt a kommunikációs csatornát nem használják. Ezen idő alatt lehet végrehajtani például az egyes vezérlőegységek helyi órájának korrekcióját a hálózati időhöz.
A statikus szegmens
21. Ábra a Statikus szegmens felépítése A statikus szegmens előre meghatározott számú (gNumberOfStaticSlots) és méretű (gdStaticSlot) szlotra van felosztva. Minden szlotban 1-1 keretet lehet küldeni (csatornánként ez lehet ugyanaz, vagy különböző keret). Minden szlot egy vezérlőegységhez van rendelve, tehát mindkét csatornán ugyanaz az adó forgalmazhat. A két csatornán a szlotok egyformák, és szinkronban vannak. Minden vezérlőegységhez ki lehet jelölni egy úgynevezett kulcs szlotot (key slot), melyben a keret szinkronizációs keretként kerül elküldésre. Ezen kereteket az óraszinkronizáció során használják a csomópontok. A kulcs szlotban küldött keretet ezen kívül meg lehet jelölni indító (startup) keretként is, mely a hálózati kommunikáció felélesztésében kap szerepet. A szlotokat folyamatos sorszámmal, 1-es értéktől kezdve számozzuk. A sávszélesség jobb kihasználása érdekében a statikus szlotokhoz nem feltétlenül kell minden körben ugyanazt az üzenetet rendelni. Minden keret, melyet itt akarunk elküldeni, rendelkezik egy periódusidő és ofszet attribútummal (message period, base cycle), ami megadja, hogy hány körönként és mely körtől számítva kell elküldeni. Tehát a TDMA kör sorszámától függően más kommunikációs mintát figyelhetünk meg a buszon, de 64 körönként ez ismétlődik. A statikus szegmensben átvitt üzenetek általában periodikus állapot üzenetek, ezért minden alkalommal el lehet őket küldeni, amikor az ütemezés a hozzájuk rendelt szlothoz ér. Amennyiben a keretet a csomópont szoftvere mégsem állítja elő, a keretet üresen (egy speciális null-keret jelzéssel) küldi el a hálózaton. Ezáltal a statikus szegmens forgalma nem változik.
A dinamikus szegmens
22. Ábra a Dinamikus szegmens felépítése A dinamikus szegmensben a szlotok mérete változó, ezáltal lehetővé válik változó hosszúságú keretek küldése. Ahogy az ábrán látható, egy körben maximum gNumberOfMinislots számú miniszlot található. A miniszlotok hosszát az éppen átküldött keret határozza meg. Ha az adott szlotban nem küldenek keretet, akkor a hossz a gdMinislot paraméter által meghatározott minimális hossz lesz. Ez csak arra szolgál, hogy minden csomópont érzékelhesse, hogy üres szlot van, és léptesse a saját szlot számlálóját. Ha egy keretet küldenek, akkor a szlot meghosszabbodik a keret hosszával, plusz egy gdDynamicSlotIdlePhase hosszúságú késleltetéssel. Erre azért van szükség, hogy az összes csomópont észlelje a keret végét, és léptethesse a szlot számlálóját. Ha egyetlen keretet sem küldenek, akkor minden miniszlot a lehető legrövidebb lesz, így gNumberOfMinislots számú – üres – keret lesz a TDMA körben. Ha küldenek kereteket, akkor néhány miniszlot kimarad. Ebből következik, hogy a dinamikus szegmens üzeneteinek prioritása annál nagyobb, minél kisebb sorszámú szlothoz rendeljük őket. A kisebb prioritású keretek nagyobb valószínűséggel maradnak ki, ha a busz terhelése növekszik. Fontos megjegyezni, hogy a dinamikus szegmensben a két csatorna egymástól függetlenül működik, a miniszlotok nincsenek szinkronban. Az üzeneteket tehát nem lehet duplikáltan – mindkét csatornán – küldeni. A statikus szegmenshez hasonlóan itt is lehetőség van egy alapciklus és periódus beállítására, amivel korlátozhatjuk az üzenetek elküldését bizonyos ciklusokra. Mivel a dinamikus szegmensben lehetnek üres szlotok, a nem frissített keretek helyett itt nem kell null-kereteket küldeni. Mindkét csatornán külön tartjuk nyilván az aktuális szlot sorszámát, ami a statikus szlotok száma+1-től indul.
Keretformátum
23. Ábra FlexRay keretformátum A FlexRay keret három fő részből áll. A fejléc (header segment) tartalmazza az azonosításhoz szükséges információkat. Az adat szegmens (payload segment) tartalmazza a felhasználói adatokat, végül a farokrész (trailer segment) tartalmazza a hibadetektáláshoz szükséges CRC kódot. A fejlécben többféle információt is átvisz a protokoll. A státuszbitek jelentése a következő: • reserved bit: Fenntartott bit, későbbi protokoll kiegészítésekhez. Értéke mindig 0. • payload preamble indicator: Azt jelzi, hogy az adatrész elején van-e kiegészítő információ. Statikus szegmens esetén a kiegészítő információ egy 2 byte hosszúságú hálózat menedzsment vektor (network management vector) lehet, dinamikus szegmens esetén egy kiegészítő (szintén két byte-os) üzenet azonosító. Ha értéke 1, akkor a keretben van kiegészítő információ, egyébként nincs. • Null frame indicator: Ha értéke 0, akkor a keret adatrésze nem tartalmaz valós információt, hanem csupa 0 byte-ból áll. • Sync frame indicator: Ha értéke 1, akkor a keret szinkronizáló keret, a fogadók felhasználhatják az óraszinkronizáció során • Startup frame indicator: Ha értéke 1, akkor a keret egy startup keret, ami a protokoll indításához szükséges. Csak az úgynevezett coldstart csomópontok küldhetnek ilyen keretet, és csak a saját szinkron keretük lehet startup keret is. Ebből következik, hogy ha ez a bit 1, akkor a sync frame indicator bit is az. A Frame id a keret azonosítója. Megegyezik annak a szlotnak a számával, melyben elküldésre kerül. Értéke 1 és 2047 közötti lehet. A payload length mező a keret hosszáról ad információt. Az itt található szám a keret adatrészének hossza osztva 2vel. (tehát egy 60 byte-os adathosszal rendelkező keret esetén például 30). Fontos, hogy a statikus szegmensben a kerethossz előre meghatározott és statikus, míg a dinamikus szegmensben változhat keretek között, sőt egy keret esetén is TDMA körök és csatornák között.
A klaszter felébresztése A klaszter alvó állapotban van, ha a csomópontok gazdagépei és kommunikációs vezérlői le vannak állítva (áramtalanítva vannak, vagy alvó üzemmódban vannak), és a buszmeghajtók alvó állapotban vannak. Ahhoz, hogy a klaszter felébredhessen, csak a buszmeghajtókra van szükség, illetve legalább egy csomópontnak valamilyen külső jelre kell felébrednie. A már működő csomópont a kommunikációs kontroller beállítása után képes speciális, úgynevezett ébresztő szimbólumokat küldeni a buszra. Ezt az alvó csomópontok buszmeghajtói érzékelik, és bekapcsolják a saját gazdagépeiket a tápegységek segítségével. Fontos, hogy egy kommunikációs vezérlő egyszerre csak az egyik csatornán küldhet ébresztő szimbólumokat, hogy egy hibás csomópont ne akadályozhassa egyszerre mindkét csatorna forgalmát. A második csatornát egy másik kommunikációs vezérlő fogja felébreszteni, miután detektálta, hogy csak az egyik csatorna ébredt fel. A felébresztés során minden hibamentes csomópont felébred, de az ébresztést kezdeményező csomópont nem kap erről semmilyen visszajelzést. Összességében tehát fel kell készülnie arra, hogy bizonyos csomópontok (hibák jelenléte miatt) alvó állapotban maradnak. Abban az esetben, ha kétcsatornás rendszerben egy olyan csomópont kezdeményezi az ébresztést, mely csak egy csatornához csatlakozik, az úgynevezett cold start (hidegindító) csomópontok az ébresztés után detektálják, hogy a másik csatorna még nem éledt fel, ezért azon is megkezdik az ébresztő minta küldését. Ez a szabály azért működőképes minden rendszerben, mert a hidegindító csomópontok mindig mindkét csatornára csatlakoznak. Miután a csomópontok felébredtek, a kommunikációs kontrollerek készen állnak a kommunikáció indítására (startup).
A kommunikáció indítása, újra-integráció A TDMA kör alapú kommunikáció feltételezi, hogy a csomópontok szinkron módon működnek. Ennek elérésére a szabvány egy hibatűrő, elosztott indítási és szinkronizációs algoritmust határoz meg. Az egyik hidegindító (cold start) csomópont kezdeményezi a kommunikáció indítását (ezt nevezzük vezető hidegindítónak – leading cold start node). Először bizonyos ideig figyeli a buszt. Ha nincs kommunikáció, akkor egy CAS (Collision Avoidance Symbol) szimbólumot küld, majd a 0. TDMA ciklustól elkezdi a saját startup keretének küldését. Előfordulhat, hogy egyszerre több csomópont kezdeményezi az indítást. Ez az első négy ciklus alatt feloldásra kerül, ugyanis minden csomópont, mely CAS szimbólumot, vagy más által küldött keret fejlécet érzékel az első négy ciklusban, leállítja az indítási kísérletét, és csendes módba kapcsol. Végül mindig csak egy csomópont marad, így a hálózat elindul. Ha egy hidegindító csomópont kommunikációt érzékel a buszon, megpróbál szinkronizálódni és bekapcsolódni a TDMA kommunikációba (ezeket a csomópontokat nevezzük követő hidegindítóknak – following coldstart nodes). Először megvár egy pár szinkronizációs keretet, amik segítségével ofszet és ráta korrekciót tud végezni a saját óráján a következő két ciklusban. Ha a korrekció sikeres, és továbbra is érkeznek a keretek, akkor ez a csomópont is megkezdi az indító keretének a küldését, különben visszatér csendes módba. Ha még három kör után sem jelentkezik probléma, a csomópont normál üzemmódba kapcsol. A nem-hidegindító csomópontok a kommunikáció érzékelése után (a követő csomópontokhoz hasonlóan) integrálódni próbálnak az indító keretek időzítésének
felhasználásával. Ezután legalább két különböző csomóponttól érkező indító keretet próbálnak detektálni. Miután ez két egymást követő körben sikeres, a csomópont normál üzemmódba vált. A szabvány által ajánlott hidegindító csomópont szám 3, hiszen ebben az esetben a) egy csomópont hibája esetén még elindul a klaszter, b) mivel a nem-hidegindító csomópontok két különböző, egymással szinkronban levő hidegindítóra várnak, így a többséggel tartanak, ha a hidegindítás során klikkek alakulnának ki. A követő hidegindító csomópontokra és nem-hidegindító csomópontokra leírt algoritmusok természetesen újra-integráció során is érvényesek. Ebben az esetben a csomópont valamilyen okból újraindul (vagy később indul), tehát a már működő kommunikációba kapcsolódik be.
Óraszinkronizáció Ahogy korábban már tárgyaltuk, egy integrált elosztott rendszerben az egyik alapszolgáltatás a globális idő fenntartása. A FlexRay kommunikáció ezt szintén megköveteli, ezért a szabvány tartalmaz egy robosztus, elosztott szinkronizációs algoritmust.
Időzítési hierarchia
24. Ábra. Időzítési hierarchia A FlexRay időzítési hierarchiáját szemlélteti a fenti ábra. A legdurvább felbontást a ciklus adja. Egy ciklus meghatározott számű macrotick-ből áll. Ezen a szinten történik a szinkronizáció, tehát adott időben (minimális hibával) minden csomópont órája azonos macrotick-et mutat, a macrotickek hossza (bizonyos toleranciával) az egész rendszerben azonos. A microtick a helyi fizikai óra ütéséből közvetlenül származtatott érték, mely kontroller-specifikus granularitású. A macrotick a microtick egész számú többszöröse.
Óraszinkronizálás A FlexRay óraszinkronizáció két párhuzamos folyamatból áll. Az óra szinkronizáció korrekciójáért a macrotick generáló folyamat (macrotick generation process) felelős, a
korrekciós értékek előállításáért pedig az óra szinkronizáló processz (clock synchronization process).
25. Ábra A FlexRay óraszinkronizáció A korrekció két részből áll, a ráta és az ofszet korrekcióból. Az egész hálózatban ugyanazzal a módszerrel történik a szinkronizáció. A ráta korrekció az egész kommunikációs ciklusban elosztva történik, a vRateCorrection korrekciós érték alapján. Ezt az értéket két ciklusonként egyszer (a páratlan ciklus statikus szegmense után) számítjuk. A vRateCorrection érték adja meg azon mikrotickek számát, amit a nominálishoz még hozzá kell adni, hogy egy ciklust kapjunk. A kommunikációs kontroller ezen tickek beszúrását/elhagyását a ciklus során elosztva végzi. Az ofszet korrekció értékét a vOffsetCorrection érték adja meg, melyet minden ciklusokban kiszámítunk. De csak a páratlan ciklus végén, a NIT alatt alkalmazzuk. Egyszerűen adott számú mikroticket beszúr vagy elhagy a kontroller. A számítás alapja az, hogy minden csomópont méri a szinkronizációs keretek fogadásának nominális és tényleges ideje közötti különbséget (minkrotickben). Az értékekből a hibatűrő átlagolás (fault-tolerand midpont) algoritmus segítségével számítjuk a korrekciós értékeket. Az algoritmus lényege, hogy a legkisebb és legnaogybb értékeket eldobva számít átlagot (azt feltételezve, hogy a hibás csomópontok által küldött keretek jelentősen előbb vagy később érkeznek, mint a helyes időpont). A vOffsetCorrection értéket a fenti algoritmussal számítjuk az aktuális körben fogadott szinkron keretek értékeinek felhasználásával. A számított értéket a kontroller ellenőrzi, hogy nem lép-e túl bizonyos határértékeket, illetve, ha a rendszerbeállítások megkövetelik, egy külső (a gazdagéptől jövő) korrekciós értéket is hozzáad. A vRateCorrection értéket a szinkron keretek két azonos körben megállapított eltérési értéke alapján számítjuk. Ha az adott keretet mindkét csatornán vette a csomópont, a két értékét átlagát használja. A fenti algoritmussal számoljuk a korrekciós értéket, ha szükséges külső értékkel korrigálva. A kontroller az értéket ellenőrzi, majd ha érvényesnek találja, alkalmazza az órakorrekció során.
