A LIN-busz

Az egy rendszerhez tartozó (pl.: hajtáslánc) ECU-k közötti adatcsere ettől kezdve az említett buszrendszeren bonyolódott, lényegesen csökkentve a kábelerek, valamint a csatlakozó pontok számát, ugyanakkor növelve az üzembiztonságot. A rendszer alkalmazása a jeladók számának csökkentését is eredményezte, hiszen a buszvonalról minden ECU hozzájuthatott a kérdéses érzékelő információjához. Az említett és egyéb előnyei miatt, nem tekinthető véletlennek a CAN robbanásszerű elterjedése.

Tudjuk, hogy eredetileg két, különböző átviteli sebességtartományban üzemeltethető változatot (ISO 11519 alacsonysebességű karosszéria és komfort oldali, míg az ISO 11898 nagysebességű hajtáslánci alkalmazásokhoz) alakítottak ki, melyeket később közös szabványszám (ISO 11898-x) alatt összevontak, és ma már csupán kötőjellel kapcsolódó számok jelzik az egyes változatok felhasználási területét.

A gondosan kidolgozott, rendkívül megbízható, sőt az alacsonysebességű változatnál hibatoleranciával is rendelkező CAN buszrendszer elviekben nem csak a vezérlőkészülékek, hanem a megfelelő csatolófelülettel kialakított érzékelők és végrehajtók adatcseréjét is képes biztosítani. Ez a lehetőség a gyakorlati alkalmazásoknál – több ok miatt - kihasználatlan maradt.
Az elutasítás indokai között egyrészt szerepelt az autonóm vezérlők működésének, -ezzel a jármű mozgásképességének- fenntartása totális buszkiesés esetén is (mivel saját érzékelőikkel és végrehajtóikkal ekkor is kapcsolatban maradnak), másrészt – és ez sem elhanyagolható szempont -, hogy az érzékelők és végrehajtók CAN csatolófelülettel történő ellátása, meglehetősen költséges. Ezért aztán a CAN rendszert mind a mai napig olyan kiépítésben alkalmazzák, legyen ez a karosszéria vagy a hajtáslánc területe, hogy az egy-egy részterületért felelős vezérlők továbbra is közvetlen kapcsolatban vannak saját érzékelőikkel és végrehajtóikkal, de adataikat egymás között cserélgetik, még akkor is, ha ezt a feladatot –Gateway segítségével- a különböző sebességű rendszerek között kell végrehajtani.

Belátható, hogy az előbb felsorolt indokok közül a karosszéria-komfort oldalon csupán a második (tehát a jelentős költség) áll meg, hiszen itt a jármű mozgásképességének megszűnésével nem kell számolni, ugyanakkor jelentős számú kábeleret és csatlakozó pontot lehetne megtakarítani egy (akár a CAN alárendeltjeként működő), de olcsó, sebességét tekintve az emberi reakció idő tartományába eső, tehát erősen csökkentett átviteli képességekkel rendelkező, buszrendszer kialakításával.

Feltehetőleg hasonlóan értékelték a kialakult helyzetet azok a neves járműgyártó és elektronikai cégek is (Audi, BMW, DaimlerChrysler, Motorola, Volcano, Volkswagen és Volvo Cars), akik 1998-ben arra szövetkeztek, hogy az adott területen és feladatokra használható - LIN elnevezésű rendszert – megalkossák.
A fejlesztés elképesztő sebességgel haladt és két év múlva a konzorcium már ünnepelhette az első LIN Sub (alárendelt) busszal (v.1.1) kiépített Mercedes SL forgalomba kerülését. A LIN rendszer folyamatos fejlesztése 2002-re azt eredményezte, hogy nem csak európai, hanem már japán cégek is (pl. Toyota) szériában (v.1.3) alkalmazták. 2003-ban jelent meg a jelentős változásokat hozó v. 2.0, de ma már a v.2.1 módosítás tekinthető a legfejlettebb verziónak.

A rövid bevezető után megvizsgáljuk a LIN busz kialakítását és kapcsolódását a CAN hálózathoz. Érdemes leszögezni, hogy a LIN nem kihívója vagy versenytársa a CAN rendszernek, - nem is lehetne, hiszen paraméterei miatt ez eleve lehetetlen -, hanem kiegészítője, mert igyekszik azt a hézagot kitölteni, ami a CAN hálózat klasszikus felépítése miatt – a karosszéria és komfort oldalon – keletkezett.

Az ábra bal oldali ábrarésze egy klasszikus felépítésű buszrendszert mutat (mint pl.: a CAN), ahol az érzékelők és a végrehajtók közvetlenül az adott területért felelős vezérlő egységekhez csatlakoznak és csak az ECU-k tudnak a buszon keresztül egymás között adatcserét folytatni. A jobboldali ábrarész ellenben egy hierarchikus rendszerkialakítást ábrázol, ahol az egyes vezérlő készülékekhez már az érzékelők és a végrehajtók is buszvonalon csatlakoznak (pl.: a LIN), ezzel tetemes vezetékmennyiséget és csatlakozó pontot megspórolva. Ismert, hogy jelentősebb spórolás elsősorban a karosszéria-komfort oldalon érhető el, tehát a LIN busz paraméterei is (átviteli sebesség, hibafelismerés, stb.) az itteni követelményekhez igazodnak.

Érdemes megjegyezni, hogy a gyártók körében, a jelzett terület buszhálózatának hierarchikus kialakítása egyre kedveltebb, annak ellenére, hogy az utóbbi megoldásnál úgy a szenzorok, mint a végrehajtók intelligens kivitelben, azaz belső processzorral, valamint busz-illesztő felülettel, építendők ki.
Az autóipar beszállítói is régen álmodoznak arról, hogy lényegesen leegyszerűsödne a szenzorok, aktorok korszerűsítése, ha fejlesztésnél csupán a mechanikai (csereszabatosság!) adatokat kellene tartani és a villamos, elektronikus oldal „szabadon” változtathatóvá válna. Az ilyen álmok megvalósulása a LIN rendszerben rövidesen várható, aminek szép példája az ablakemelő motoregység, ahol a villamos oldalhoz már buszfelületen lehet kapcsolódni, tehát úgy a motor, mint az áttétel valamint a végállások és az elakadás érzékelése szabadon módosítható.

Rögtön felmerült a kérdés, hogy nem olcsóbb e a klasszikus változat, hiszen az intelligens kivitelhez megkövetelt kialakítás (pl. egy NTC-s hőmérséklet jeladó processzoros, buszképes átalakítása) túlzottan költségesnek tűnik. Az aggályokat – a konzorcium tagjai - igyekeztek hatásos érvekkel eloszlatni, amikor meghatározták a LIN rendszer kialakításának legfontosabb ismérveit. Ezeket a gépkocsikban már korábban (a CAN előtt is) meglévő ISO 9141 buszrendszerre (az ismert K vonal) és a hozzá tartozó UART protokollra alapozták. A főbb ismérvek a következők:

•Költségkímélés szempontjából a busz egyvonalas (ISO 9141) kialakítású, ahol az átviteli jelszintek a mindenkori tápfeszültség és a viszonyítási alapot biztosító testpotenciál között változik. A definíció burkoltan még azt is lehetővé teszi, hogy a jeleket ne külön buszvezetéken, hanem a szenzorok és végrehajtók tápvezetékén vigyük át, amivel valóban drasztikus érszám csökkenést lehetne elérni!

•Az üzenetátvitelre használt feszültségváltozások meredeksége olyan mértékűre korlátozandó, ami az EMC előírásoknak megfelel. Ez a kitétel gyakorlatilag behatárolja a bitátviteli sebesség felső határát (max 20 kBit/sec), a teljes buszvonal hosszát (max 40 m) és a vonalra csatlakoztatható állomások számát (max 16) is.

•Az egyes állomások Controllereit, a drága és körülményesen szinkronizálható kvarc oszcillátoros helyett, olcsó, nagyszámban rendelkezésre álló, egyszerű RC oszcillátoros processzorok alkossák.

•Az új rendszer protokollja az UART (Universal Asynchronous Receiver Transmitter) megoldáshoz hasonló, melyhez a szinte minden processzorban megtalálható soros kommunikációs interface (SCI) használható. Ez egyben azt is jelenti, hogy a rendszer nem a CAN-nél megismert eseményvezérelt, egyenjogú állomások (Multi Master elv) prioritás alapján rangsorolt üzenetváltásán, hanem a mester-szolga (Master-Slaves elv) viszonyon alapul, ahol mester által megszabott, időrendi sorrendben ütemezett módon zajlik a kommunikáció.

•Végezetül, de nem utolsó sorban lényegesen olcsóbbá teszi az eleve nyitott, az alkalmazók számára szabad hozzáférésűként definiált LIN rendszert az a tény is, hogy a felhasználóknak – szemben a CAN használatával – nem kell licensz díjat fizetni.

A LIN rendszer kifejlesztése óta eltelt idő fényesen igazolta az elképzelések gazdasági megfontolásait, hiszen egy állomás buszképessé alakítása kb. fele költséggel jár, mintha ugyanezt a CAN rendszerben kellene megvalósítani.

Az alapelvek vázlatos összefoglalása után megkezdjük a rendszer működésének és felépítésének ismertetését. Érdemes a rendszer működését a kialakított protokoll, vagyis az üzenetkeret, ismertetésével kezdeni.

A teljes üzenetkeret két részből áll, ahol az első rész az üzenet fej (ezt mindig a mester küldi a buszra), míg a második rész a válasz (ahol az üzenetet vagy a mester, vagy valamelyik megszólított szolga állomás folytatja és fejezi be).

Az üzenet fej első mezője, mint szinkronfék (Syncron break), az állomások „figyelmeztetésére” szolgál, tekintettel arra, hogy az olcsó RC oszcillátorok meglehetősen pontatlanok, akár 15%-os frekvencia eltérést is produkálhatnak (egymástól, illetve a mestertől), amikor is az üzenetek olvasása, értelmezése kritikussá vagy lehetetlenné válik. A szinkronfék mező – mely a busz minimált idejű passzív állapota után következhet - legalább 13 domináns bitből áll, amit 1 domináns (start) nyit és 1 recesszív (stop) zár. Erre az üzenetmezőre minden állomás „felkapja a fejét” érzékelve, hogy egy új üzenet következik, aminek üteméhez feltétlenül szinkronizálódnia kell.

Az állomások ütemfrekvenciájának szinkronizálását az üzenet fej második mezője biztosítja. Az 1 bájt hosszúságú, váltakozva domináns és recesszív biteket tartalmazó (HEX 0x55), mező is egy startbittel kezdődik (ez mindig domináns), majd egy stopbittel zárul (ez mindig recesszív). Ebben a rendszerben tehát (8-N-1 UART bitkódolás) az 1 bájt (8 bit) hosszúságúnak jelzett mezők valójában 10 bitből állnak, hiszen a start és stopbit is a mezőbe számít. A mester állomás tehát a kiadott szinkronmezővel, minden (olcsó RC oszcillátoros) szolga állomást a saját ütemfrekvenciájához szinkronizál. Éppen azért, mert a mester állapítja meg az üzenetek ütemezését, általában megfelelően stabil frekvenciájú kvarc oszcillátorral rendelkezik.

Az üzenet fej harmadik mezője (azonosító mező) nagyon fontos adatokat tartalmaz. Ebben a mezőben közli a mester állomás az üzenet azonosítóját (ez a megoldás hasonló a CAN rendszeréhez), valamint a hibafelismeréshez szükséges két paritásbitet is. A korábbi verzióknál még az üzenet második részében küldendő adatbájtok számát is beírták az azonosító mezőbe, ez a 2.0-s verziótól már nem kötelező. Az azonosító mező olvasásakor tudják meg az állomások, hogy melyiküknek kell és milyen adatokat szolgáltatni, illetve azt is, ha a mestertől érkezik valamilyen utasítás. Az azonosító mező ismeretében döntenek arról is, hogy a később érkező adatokra szükségük van e, vagy nincs.

Az üzenetkeret második része egy meghatározott szünet után következik, mert időt kell biztosítani az azonosító mező kiértékeléséhez (a járművekben alkalmazott leglassúbb buszrendszerről van szó!), és hibátlan voltának (paritásbitek!) megállapításához.

Az üzenetet vagy a megszólított szolga vagy maga a mester állomás folytatatja a megfelelő számú (2, 4 ill. 8) adatbájt buszra helyezésével, végül a teljes üzenet egy vizsgáló összeggel zárul, mely az átküldött adatok hibátlan voltának ellenőrzésére szolgál. Ez a vizsgáló összeg „messziről” és céljában is hasonlít a CAN rendszernél használt CRC mezőhöz, de alacsonyabb hiba-felismerési szintet biztosít. Korábban ez a vizsgáló összeg csupán az adatbájtok ellenőrzésére szolgált, a mai verzióknál (v. 2.0-tól) már egy kiterjesztett (Extended) vizsgáló összeg szerepel, mellyel az adatmezőn kívül az azonosító mező is ellenőrizhető.

A leírt protokoll szerint átvitt üzenet adatait úgy a mester, mint a szolga állomások igény szerint hasznosíthatják. Hiba észlelésekor az üzenetet figyelmen kívül hagyják (ignorálják).

A működés rövid összefoglalását célszerű azzal zárni, hogy a 2.0 verziótól a szigorú üzenetütemezés (tehát, hogy minden állomás üzenetének átvitelére sor kerül egy előre pontosan definiált ismétlődési cikluson belül) megváltozott és a cikluson belül bekövetkező események (változások) adatai is átvitelre kerülnek egy külön erre beiktatott, un. esemény (event) lekérdező üzenet indításával. Ez a megoldás szintén hasonlít a CAN rendszer eseményvezérlési elvéhez, de itt nem a prioritáson alapul a buszhozzáférés és az üzenetátvitel elsőbbségének eldöntése.
Az egyes állomások szigorú szabályok szerint kialakított választ küldhetnek az event lekérdezésre. A válasz első adatbájtjának tartalmaznia kell „feladó” állomás azonosítóját és csak a további bájtok tartalmazhatják a tényleges adatokat. Minden event lekérdezésre válaszoló állomás csak pontosan azonos hosszúságú választ adhat, és azonos elven kell a vizsgálóösszeget (vagy mind Extended vagy egyik sem) is képezni.
Amennyiben nincs válasz (mert nem volt esemény a legutóbbi lekérdezés óta), vagy csak egy állomás válaszol, a folyamat rendben zajlik. Előfordulhat azonban (mivel az event kérés nem tartalmaz azonosítót!), hogy egyszerre két állomás kezd válaszolni. Ilyenkor kétféle eset képzelhető el:
•A válasz első bájtjában szereplő állomásazonosítókat a válaszolók felülírják (a domináns bit itt is mindig felülírja a recesszívet) és az eredmény egy értelmetlen azonosító, ezért mindkét állomás – mivel ellenőrzi (monitorozza) saját kiadott adatait – leáll, amiből a mester tudja, hogy adatütközés (Collisio) történt.
•Az állomások közül a felülírás valamelyik állomás érvényes azonosítóját eredményezi, ezért ennek üzenete teljes egészében a buszra kerül és feldolgozható, míg a másik átmenetileg eltárolja event válaszát és a legközelebbi lekérdezésnél (ami akár a cikluson belül is előfordulhat) újra próbálkozik a válasszal.

A LIN folyamatos fejlesztésével olyan rugalmas rendszert sikerült kialakítani, mely már ma is megbízható, költségkímélő és intelligens vezérlést képes megvalósítani a karosszéria és komfort oldal legtöbb egységénél. Az alaprendszerrel együtt fejlesztett programozó és tesztelő berendezések garanciát adnak a LIN széleskörű, sikeres elterjedéséhez.

A következőkben áttekintjük a LIN rendszer fizikai felépítésének legfontosabb megoldásait. Ebben a rendszerben – hasonlóan a CAN felépítéséhez - a csatolófelület két egységből áll. A közvetlen vonali csatlakozást – tehát az üzenetek küldését és fogadását a Transceiver végzi, bár kiépítése lényegesen egyszerűbb, mint a CAN esetében, ahol szimmetrikus meghajtót kell használni. A másik szokásos egység a LIN Controller, ami hasonló feladatokat lát el, mint a CAN Controller, vagyis értékeli, illetve összeállítja a vonali üzeneteket.

Az ábrán a LIN buszon átvitt feszültségjellel és vonalmeghajtójának (Transceiver) elvi kialakításával ismerkedhetünk meg.

A vonalra jutó domináns (0V), valamint recesszív (Utáp) szintnek megfelelő feszültségek (a névleges értékekhez viszonyított) tolarenciája meglehetősen tág.
A rendszer vonalfeszültsége recesszívnek tekintendő (Utáp = 12V esetén) a vételi oldalon 7,2 – 12V között, de adáskor legalább 9,6 – 12V közötti értékeket kell biztosítani. Hasonló tűréssel domináns szintnek fogadja el a vételi oldal a 0 – 4,8V közötti értékeket, míg adáskor 0 – 2,4V értéktartomány a megengedett. A megadott tűrésmezők nagyfokú zavarérzéketlenséget biztosítanak a rendszernek, hiszen ahhoz, hogy egy külső elektromágneses tér több Volt-os feszültséget indukáljon a buszvonalon és meghamisítsa a pillanatnyi állapotot, rendkívül komoly energiaváltozás szükségeltetne.

A másik feltűnő érték (bár a bevezetőben már utaltunk rá), hogy a vonalfeszültség emelkedési és csökkenési meredeksége meglehetősen korlátozott. Eredetileg a fejlesztők 1-3V/s értéktartományt határoztak meg, de a mindennapi gyakorlatban igyekeznek az ábrán megadott 2V/s értéket tartani. Ez azért fontos, mert minél meredekebb a fel vagy lefutási meredekség, annál nagyobb a buszvonal által kisugározott elektromágneses tér energiatartalma, mely gyorsan elérheti a még megengedett EMC értéket. Ennél magasabb sugárzási szintek esetén a rendszer használatra alkalmatlan, elsősorban a környezetében üzemelő egyéb elektronikus rendszerek zavarása miatt, hiszen egy árnyékolatlan, egyvezetékes buszvonal kiváló antenna!
A lényegesen költségesebb CAN rendszernél alkalmazott megoldással szemben nem véletlen tehát, a LIN rendszer szigorúan behatárolt meredekség (V/s) értékválasztása.

A villamos körökben csak szabad-kollektoros tranzisztorként emlegetett vonalmeghajtó kollektora egy „felhúzó ellenálláson” és egy soros diódán keresztül csatlakozik a tápfeszültségre. Az ellenállás értéke egy mester állomás vonalmeghajtójánál 1 kOhm, míg a szolgáknál 30 kOhm nagyságrendű. A dióda csupán a veszélyes vonalfeszültségek káros visszahatását akadályozza, egyéb szerepe nincs.

A másik lényeges összetevő a vonallal párhuzamos kapacitás értéke, ami mester esetében ~2,2-2,5 nF, míg a szolgáknál ~220-250 pF. Miután a buszvonal által képviselt kapacitás legfeljebb 4-10 nF között lehet (ez az érték a feszültségváltozás meredekségét befolyásolja), könnyen kiszámolható hogy az egy mester mellett hány szolga állomás képzelhető el és az is, hogy legfeljebb mekkora lehet a buszvonal teljes hossza, ha annak méterenkénti kapacitása ~100-150 pF.

A vonalmeghajtó az azonos vagy különálló chip-en elhelyezkedő processzorhoz (LIN Controller) csatlakozik (UART) SCI porton keresztül és adatátvitelt (Tx), vagy adatbeolvasást (Rx) hajt végre. Természetesen a modern vonalmeghajtók további egységekkel is kiépítettek és egyéb funkciókat (szundi üzemmód, ébresztés a vonalról, stb.) is teljesítenek. Egy ilyen modern, egychipes kialakítást a 6. ábrán láthatunk.

Érdemes megjegyezni a Transceiverek felépítésével kapcsolatban, hogy a buszvonal testhez vagy táphoz záródását ugyan meghibásodás nélkül képesek elviselni, de az említett zárlatok esetén a helyi rendszer működésképtelenné válik.

A „szundi” és az „ébresztés” állapotok bekövetkezéséhez érdemes néhány megjegyzést fűzni. A járművekben használt vezérlők összességének működése jelentős áramfelvétellel jár, ezért a leállított járműnél szinte kényszer a vezérlők kikapcsolása. A karosszéria és komfort oldal rendszereinek teljes kikapcsolása sokszor lehetetlen, gondoljunk csak a működő riasztóra, a távirányító vevőjére, az állójármű fűtésre és így tovább. A karosszéria és komfort oldali állomások magas áramfelvételének csökkentésére kidolgozták a nem teljes leállítás módszerét. Az említett rendszereknél, amennyiben egy előre definiált ideig (a LIN esetében ez ~1sec.) nincs adatforgalom, akkor az egységek - a Time-out szabály figyelembe vételével - önmagukat „szundi” állapotba helyezik, így áramfelvételük minimumra korlátozódik.

Az „ébresztés” funkciót, mikor is a rendszer visszatér normál üzemi állapotába, egy a buszvonalra helyezett, megadott időtartamú (a LIN-busz mindenkori sebességétől függően: 250 us – 5ms tartamú) domináns szint, vagy a processzor felül érkező „Wake-up” parancs váltja ki. Korábbi verzióknál a leírt folyamat 3 szintű volt (teljes kikapcsolás is létezett), de a 2.0 változat óta csak a leírt két állapot egzisztál.

Az ábrán a LIN rendszer - alrendszerként történő - kapcsolódását látjuk a CAN rendszerhez, ahol a GW1 és GW2 feliratok a két rendszer közötti átjárókat (Gateway) jelzik. A K-CAN jelzés a karosszéria-komfort CAN buszvonalra vonatkozik.

Érdemes megjegyezni, hogy a LIN alrendszerek száma attól függ, hogy egy-egy feladat végrehajtásához hány szenzor illetve aktor együttműködését kell biztosítani. A rendszerek dolgozhatnak önállóan, de az átjárókon keresztül egymással, vagy éppen a K-CAN busszal együttműködve is. A rendszer semmilyen megkötést nem tartalmaz a busztopológiát illetően, mindez tovább növeli rugalmasságát és bővíti felhasználási területét.

A LIN rendszer ismertetésének befejezéseként tekintsük át lehetséges felhasználási területeit, és egy alappéldán keresztül a gyakorlatban történő alkalmazását is bemutatjuk.

Gyakorlati alkalmazásként a vezető oldali ajtó egységeinek LIN rendszerről történő vezérlésének elvi sémáját mutatjuk be.

Az ábrából világosan kitűnik, hogy egy-egy különálló egységként kezelt az ablakmozgatás, a külső visszapillantó tükör, a központi zár és a kezelőfelület. Magyarázatra tulajdonképpen csupán a LIN-CAN átjáró bejelölése szorul, miután az egyes LIN rendszerek feladataik zömét képesek önállóan megoldani. Egy LIN-CAN átjáró (GW) kiépítése akkor válik szükségessé, ha valamilyen csatolást (kölcsönös együttműködést) kell kialakítani a CAN rendszer felügyelete alatt dolgozó egyéb egységekkel. Példaként a külső tükörpozíció, és a felső kategóriában ezzel összefüggő üléspozíció állítást, vagy az elektrokrómikus sötétítésű külső és belső visszapillantó tükör közös vezérlésének esetét említhetjük. Az említett esetekben ugyanis az adatok az utastér, az ajtó, valamint a memória egységek között CAN buszon cserélődnek.

A LIN rendszerismertetőt azzal szeretnénk zárni, hogy a megbízható, olcsó de intelligens szenzor-aktor együttműködést biztosító buszkialakítás elterjedésével, a folyamatos, komplett rendszerfejlesztésnek köszönhetően, elsősorban a járműelektronika területén, de hasonlóan a CAN rendszerhez (CANopen) az automatika területén is számolni kell.