Ugrás a tartalomhoz

Autóipari kommunikációs rendszerek

Dr. Fodor Dénes, Dr. Szalay Zsolt (2014)

Pannon Egyetem

2. fejezet - LIN: Local Interconnect Network

2. fejezet - LIN: Local Interconnect Network

Az 1999-es évben néhány VLITE buszt használó autóipari vállalat hatására került sor a LIN (Local Interconnect Network) első változatának (LIN 1.0) kidolgozására. A LIN kommunikációs protokoll szabványosításával az akkor választékosan sokrétű megoldást alkalmazó autóipari kishálózatoknál a fejlesztés, a termék előállítás, a javítás és a logisztika erőforrásigényei kisebbek lettek. A LIN alkalmazása a mai napig az autóiparban leginkább a hierarchikusan felépülő elektronikai eszközök rendszerében alul elhelyezkedő, kis csomópontszámmal rendelkező elemi (al)hálózatokra terjed ki.

A LIN protokoll jellemzői és felépítése

A szabványosítási folyamattal a specifikációk kibővültek, és a legfrissebb (2010 decemberében kiadott) formájában az alábbiakat tartalmazza:

  • Átviteli protokoll (Transmission protocol)

  • Átviteli/kommunikációs közeg

  • Fejlesztői eszközök közti interfész

  • Interfészek a szoftverfejlesztéshez

A LIN protokoll jellemzői

A LIN egy olyan soros kommunikációs protokoll, mely hatékonyan támogatja az elosztott autóipari alkalmazások területén alkalmazott mechatronikai egységekből álló csomópontokat. A LIN protokoll részletes leírását a következő fejezetek tartalmazzák, azonban főbb jellemzői pontokba szedve az alábbiakban olvasható:

Egy mester több szolga koncepció

Egy LIN hálózaton – más néven klaszteren (cluster) – egy mester csomópont és egy, vagy több szolga csomópont engedélyezett úgy, hogy a maximális csomópontszám nem lépheti túl a 16 darabot. A mester csomópont egy mester folyamattal (master task) és egy szolga folyamattal (slave task), míg a szolga csomópontok csupán egy-egy szolga folyamattal (slave task) rendelkeznek. A mester folyamat látja el az üzenetek időzítését (ütemező táblázatok) és a fejlécek küldését (üzenet első része), valamint a válaszrészek fogadását. A szolga folyamatok feladata a fejlécek fogadása, értelmezése és a szinkronizáció elvégzése, aztán a válaszrészek küldése (ha ő a kért jelnek a közzétevője), vagy fogadása (ha eleme a jelhez tartozó feliratkozó csomópontoknak). Egy mester csomópont egyszerre több klaszter tagja is lehet, például diagnosztikai teszter egység kapcsolódhat hozzá CAN hálózaton ([Diagnosztika a LIN hálózaton] fejezet).

Alacsony költség

Az autóiparban használatos kommunikációs protokollok közül a legalacsonyabb kiépítési/fenntartási költséggel a LIN rendelkezik, melyet a [Jelentősebb autóipari kommunikációs protokollok összehasonlító táblázata] is szemléltet. A LIN protokoll e tulajdonsága főként az egyszerű, és így olcsó áramköreinek köszönhető, hiszen ezen elemek az UART/SCI (Universal Asynchronous Receiver-Transmitter/Serial Communication Interface) interfész hardverét valósítják meg; a szoftver pedig egy viszonylag egyszerű állapotgéppel leírható. A LIN hálózat a busz topológiát támogatja, melynél egyetlen vezetékre van felfűzve az összes csomópont. Ezzel a kábelhossz is kisebb, más topológiákhoz képest. A maximális kábelhossz 40 méter.

Önszinkronizációs képesség

A LIN koncepciójának egyik sajátossága, hogy a hálózat szolga csomópontjai kvarc, vagy kerámia rezonátor használata nélkül képesek önmagukat szinkronizálni a mester órájához.

Minden üzenet (frame) két fő részből: fejlécből (header) – melyet a mester csomópont küld – és válaszrészből (response) – melyet egy a fejlécben definiált szolga csomópont küld – áll.

A fejléc többek között tartalmazza a szinkronizációs mezőt (sync field), melynek segítségével minden szolga csomópont elvégzi saját maga szinkronizálását ([Szinkronizációs folyamat] fejezet).

Flexibilitás

A LIN klaszter csomópontokkal bővíthető, vagy csomópontok vehetők ki a hálózatból, bármilyen hardveres vagy szoftveres változtatás nélkül. Az üzenetek címzése csomópontalapú, ezért a bővítés/ritkítás csak úgy tehető meg, hogy az újonnan kapcsolódó csomópontot a mester csomópont azonosítja, és hozzárendel egy csomópontcímet (NAD értéket); csomópont konfigurációs szolgáltatások ([Szolgáltatás azonosító] fejezet).

Determinisztikusság

A LIN támogatja a hálózat csomópontjainak működését a hardver és a szoftver EMC (Electro Magnetic Compatibility) viselkedésének előre megjósolhatósága szempontjából. Így a jelterjedési viszonyok és a jelek késleltetése időben előre számíthatók, modellezhetők.

Multicast

A LIN hálózathoz kapcsolódó összes csomópont azonos időben fogadja a buszon közvetített adatot. Ha a mester csomópont teszi ezt egy fejléc küldésével, minden szolga csomópont hallgat, és értelmezi a fogadott adatot. Ezt követően egyetlen (ez alól kivételt képezhetnek az eseményvezérelt üzenetek, [Eseményvezérelt üzenet] fejezet), a fejlécben megadott szolga elküldi a válaszrészt, mely közben az összes többi csomópont figyel, és olvassák a buszról az adatokat. Ha üzenetfogadás közben új üzenet elejét jelző megszakítási mezőt (mester küldi) érzékelnek a szolga csomópontok, akkor a korábbi üzenet fogadása/küldése megszakításra/eldobásra kerül.

Megjósolható viselkedés ütemező táblázatok alkalmazásával

A LIN hálózat vezetője a mester csomópont, mely a vezérlést ütemező táblázatok (schedule table) megfelelő időzítésével végezi. A mester kibocsát egy fejlécet (header) – amely az üzenet első szakasza, – az ütemező táblázatban való aktuális helyzet alapján, amely előre definiálja az üzenet (frame) jellegét, és annak kommunikációs időigényét. Előfordulhat, hogy egy mester csomópontnál több ütemező táblázat is definiálásra kerül, és köztük az éppen futó alkalmazás át tud váltani ([Ütemező táblázatok] fejezet, [Ütemező táblázatok] oldaltól).

Szállítási réteg és diagnosztikai funkciók elérhetősége

Az adatok továbbítása üzenetek („keretek” (frames)[2]) segítségével történik a LIN hálózaton, melyeknek két fajtája van[3]: jelhordozó és diagnosztikai üzenet. A továbbiakban az „üzenet” szó önmagában jelhordozó üzenetre utal.

A jelhordozó üzenetek adatmezejét alkotják a jelek, melyek lehetnek skalár értékek, vagy bájttömbök (ha a jel hossza nagyobb, mint 8 bit). Bármely két megegyező azonosítójú jelhordozó üzeneten belül az adatmezők szerkezete azonos.

A diagnosztikai üzenetek továbbítása két, előre lefoglalt azonosítóval történhet: a 60-as a mester diagnosztikai kérőüzenete, míg a 61-es a szolga diagnosztikai válaszüzenete. Az így továbbított adatok pontos jelentése függ az adatmezőktől és a kommunikáló csomópontok állapotától ([A LIN protokoll Szállítási rétege] és [Diagnosztika a LIN hálózaton] fejezetek).

Kötött üzenetszerkezet és adatbájtok

A LIN buszon megjeleníthető információegységek formátuma kötött, melyet az üzenetszerkezet definiál ([Az üzenet felépítése]). Ezen az üzenetek adatmezejét 1-8 adatbájt alkothatja, egyenként fix, 10 bites hosszal. Az adatbájtok első bitje a start bit, az utolsója pedig a stop bit. A köztes 8 bit maga az információ. Így ilyen kis „egységekbe” van szerkesztve a jelek (signals), melyek magát az információt hordozzák.

Hálózattervezés támogatása

A LIN folyamatkoncepciója ([A LIN klaszter tervezési folyamatát szemléltető ábra]) egy résmentes láncot ír elő a fejlesztő eszközöknél a tervezés során, mellyel meggyorsítja a fejlesztést és megbízhatóbbá teszi a kialakítandó LIN klasztert (cluster).

A Csomópontjellemző Nyelv Specifikációja (Node Capability Language Specification) – mely e jegyzetnek nem része – szabványosított szintaktikát biztosít a „közvetlenül a polcról” (off-the-shelf) elérhető szolga csomópontok kezelésére, automatizált klaszterek létrehozásához. E specifikációval a csomópontokra definiálható egy-egy NCF, azaz Csomópontjellemző Fájl (Node Capability File), melyek leírják a szolga csomópontok szerepköreit a LIN busz szemszögéből. E fájlok képezik továbbá a LIN klasztertervező eszköz bemenetét.

A Kiépítési Nyelv Specifikációja (Configuration Language Specification) – mely e jegyzetnek szintén nem része – megadja, hogy az NCF-k felhasználásával a LIN klasztertervező eszközzel hogyan érdemes kialakítani az LDF, azaz a LIN Leíró Fájlt (LIN Description). E fájl tartalmazza a teljes klaszter leírását és a klaszter megfigyeléséhez szükséges összes információt. Ez azért fontos, mert így tesztelhető a kiépítendő LIN klaszter úgy, hogy egy vagy több csomópont fizikailag nincs jelen (nem elérhető, például: még nincs megvásárolva). Tehát az LDF alkalmazásával úgy végezhetők emulációk, hogy például: a LIN rendszer szerepe nincs meghiúsítva üzenet inkompatibilitással, vagy a hálózat nincs veszélyeztetve túlterheléssel.

2.1. ábra - A LIN klaszter tervezési folyamatát szemléltető ábra

A LIN klaszter tervezési folyamatát szemléltető ábra


A LIN Leíró Fájl szerepköre kettős. Hibakeresés: az említett emulációkhoz az ipar a szabványban jól definiált hibakereső (debugging) eszközöket biztosít, melyet a buszelemző és emulátor blokk képvisel ([A LIN klaszter tervezési folyamatát szemléltető ábra]). Klaszter létrehozása: az LDF képezi a bemenetét a LIN klaszter létrehozónak/generátornak, mely már automatikusan létrehozza a LIN függvényeket a kívánt csomópontoknál ([A LIN klaszter tervezési folyamatát szemléltető ábra]: három szolga és egy mester csomóponttal).

A LIN alkalmazási területei

Ahogy az [ Elosztott szabályozó rendszer] fejezetben bemutatásra került, a járművekben található elektronikai eszközök elosztott rendszeren belül, különféle szinteken töltik be szerepüket. A LIN szempontjából a Kényelmi/Komfort elektronika a legfontosabb felhasználási terület. Ennek két fő oka, hogy e szinten lévő eszközöknél megengedhető az emberi reakcióidővel összemérhető válaszidő, működési tartomány, valamint ezen eszközök meghibásodása, vagy egy-egy – vagy akár az összes – alhálózat teljes kiesése sem veszélyezteti a jármű menetbiztonságát, nem eredményezi a jármű mozgásképességének megszűnését. Így a Kényelmi/Komfort elektronika területén alkalmazható olyan – a többi kommunikációs protokollhoz képest – alacsony költségű hálózat, mint például a LIN. Ezen alhálózatokon áramló információ mennyisége szintén nem nagy, sőt, a terhelésük sem időben állandó (például az elektromos ablakemelő használata „alkalomszerű”). Ilyen kisebb alhálózatra felfűzve egy-egy csoport elektronikus eszközt, nagy mennyiségű kábelér és csatlakozási pont spórolható meg

A LIN jellemzően az alábbi funkcióknál kerül alkalmazásra:

  • Elektromos ablakemelő

  • Ajtózár, központi zár

  • Fűtésrendszer vezérlés

  • Elektronikusan állítható visszapillantó tükör

Szabványosítás

Az 1999-es megjelenése után a LIN szabványon a 2000-es évben kétszer is módosítottak, így a LIN 1.2 2000 Novemberében látott napvilágot. Két évvel később, 2002-ben a LIN Konzorcium megjelentette a LIN 1.3 szabványt, melyben a változtatások a LIN Fizikai rétegét célozták meg a csomópontok összeférhetősége érdekében.

A LIN 2.0 elnevezése a kiemelkedő változtatásokra utal az őt megelőző, LIN 1.3-hoz képest, hiszen a LIN 2.0 szabványban teljesen átdolgozásra kerültek egyes problémás területek, hozzáigazítva a specifikációt az akkori elvárásoknak, mellyel a LIN kereskedelmi forgalomban könnyen hozzáférhetővé vált. A hatást az előző 3 év tapasztalata és a LIN SAE (Society of Automotive Engineers) J2602 szabványa váltotta ki. A változtatásokkal a konfiguráció és diagnosztika támogatottsága megnőtt valamint specifikálásra kerültek a csomópontleíró fájlok.

A gyakorlati tapasztalatok vezettek a következő lépéshez, melyet a 2006-os LIN 2.1 jelentett, ahol a korábbi verziókkal való kompatibilitás érdekében az egyes alkotórészek pontos funkcionalitása került letisztázásra, megkötéseket vezettek be és egyes elemeket kivettek a specifikációból.

Az elkövetkező években egy hibalista (errata) összeállítására került sor, amellyel 2010-ben a LIN elnyerte legfrissebb alakját, a LIN 2.2 szabványt.

A legújabb, LIN 2.2 szabvány

A LIN 2.2 szabványban megfogalmazott mester csomópont képes kezelni mind a LIN 1.3 szolgákat és a LIN 2.2 szolgákat. A LIN 2.2 mester így a LIN 1.3 szabvány szerint működő szolga csomópontoknál bizonyos funkciókat nem vár el:

  • Ellenőrző összeg (checksum) megnövelése,

  • Újrakonfigurálás és diagnosztika,

  • Automatikus átviteli sebesség (baud rate) felismerése,

  • „Hiba a válaszrésznél” állapot megfigyelése.

A LIN 2.2 szabvány szerint működő szolga csomópont azonban nem képes a LIN 1.3 szolga csomópont kezelésére (mivel a LIN 2.2-nél a LIN 1.3-hoz képest megnövelték az ellenőrzőösszeg nagyságát).

2.1. táblázat - LIN szabványok összefoglalása.

Specifikáció

Megjelenés

ideje

Leírás

LIN 1.0

1999-07-01

A specifikáció kezdeti verziója.

LIN 1.1

2000-03-06

 

LIN 1.2

2000-11-17

 

LIN 1.3

2002-12-13

 

LIN 2.0

2003-09-16

Fő áttekintő lépés

LIN 2.1

2006-11-24

Funkcionális tisztázás, konfigurációs módosítások, Szállítási réteg növelése és diagnosztikai funkciók bevétele

LIN 2.2

2010-12-31

Frissítve a LIN 2.1 hibajegyzéke (errata) alapján, bit mintavételezésének megkötésein lazítások

LIN 2.2A

2010-12-31

A felébresztő jel javítása (LIN 2.2 2.6.2-es fejezetében)


A LIN 2.2 szabványban definiált Fizikai réteg visszamenőleg kompatibilis a LIN 1.3 Fizikai rétegével, azonban ez fordítva nem feltétlenül teljesül, hiszen a LIN 2.2 szabvány szigorúbb követelményeket támaszt. Mindazonáltal a LIN 2.2 Fizikai rétege működőképes egy LIN 1.3 klaszterben (cluster).

A LIN 2.2 mester csomópont kompatibilis a LIN 2.0 szolga csomópontokkal akkor, ha bizonyos „elavult” funkciókkal (például: Assign frame Id) fel van ruházva a LIN 2.2-es mester csomópont. Egy LIN 2.2 szolga csomópont működőképes egy LIN 2.0 klaszteren belül egy előzetes konfigurálás után, mivel a LIN 2.0 csomópontoknál a ’0x7E’ csomópontcím (NAD – Node Address) más, diagnosztikai funkcióval rendelkezik. A LIN 2.2 szabvány alapján definiált csomópontok teljesen kompatibilisek a LIN 2.1 csomópontokkal.

A LIN protokoll felépítése

A LIN klasztert alkotó eszközök közötti információcserét bemutató LIN kommunikációs modell ([A LIN kommunikációs modellje, rétegei, párhuzamba állítva az OSI modellel]) létrehozásánál az alkotók szem előtt tartották az ISO/OSI referencia modellt, így a LIN esetében is egymásra épülő rétegek definiálása történt meg. E rétegek feladatkörei kellő részletességgel kerültek specifikálásra úgy, hogy közöttük ne legyenek átfedések. Így a küldő csomópont esetén a legfelső rétegtől indulva a küldendő információ becsomagolása történik, mely a LIN buszon fizikai jelek formájában megjelenik, majd a fogadó oldalon ugyanezen rétegeken – a legalsótól a legfelsőig – végig haladva az információ kinyerése, és a megfelelő alkalmazáshoz irányítása zajlik.

A LIN kommunikációs modellje ([A LIN kommunikációs modellje, rétegei, párhuzamba állítva az OSI modellel]) által definiált rétegek jellegre többnyire igen, de feladatkörei teljesen mértékben nem egyeznek meg az OSI modell esetében definiáltakkal. A LIN kommunikációs modelljét négy réteg alkotja

Fizikai réteg specifikációja

A Fizikai réteg az egyedüli olyan réteg, amely a LIN busszal közvetlen összeköttetésben van, így a specifikációja olyan kérdéseket válaszol meg, hogy konkrétan milyen áramköri elemekből épüljön fel egy csomópont annak érdekében, hogy a buszról érkező jeleket fogadja, illetve a küldendő jeleket meg tudja jeleníteni a buszon. Továbbá a busz viselkedésének részletezése is e réteg feladata, hogy azt hogyan érdemes mintavételezni. Néhány pontban összegezve a Fizikai réteg leírja/megvalósítja:

  • A bitek mintavételezésének kritériumait, a szinkronizációs folyamatot

  • A buszmeghajtó és fogadó egységek felépítését, viselkedését

  • Jelspecifikációt (mikor számít egy jel dominánsnak és mikor recesszívnek)

  • Feszültségszinteket, és áramértékeket illetve áramköri elemek paramétereit, valamint ezek határértékeinek definiálását.

2.2. ábra - A LIN kommunikációs modellje, rétegei, párhuzamba állítva az OSI modellel

A LIN kommunikációs modellje, rétegei, párhuzamba állítva az OSI modellel


Protokoll specifikáció (Adatkapcsolati réteg)

Az Adatkapcsolati és Hálózati réteg szintjét együttesen képviselő réteg a Protokoll Specifikáció, mely lényegében a LIN klaszteren küldhető információegységeket, az üzeneteket szerkezetét és a küldhető üzenetek típusát írja le. Emellett e réteg kezeli az ütemező táblázatokat, és részletezi a hálózati menedzsmentet.

Szállítási réteg és Diagnosztikai specifikáció

A LIN hálózaton lévő eszközeinek protokoll-implementációjának mélysége (mely osztályba tartoznak) függvényében van lehetőség olyan üzenetek küldésére, melyek prioritás szempontjából a normál (jelhordozó) üzenetek „felett” állnak. Ezek a diagnosztikai üzenetek. A diagnosztikai szerep magába foglalja többek között a csomópont konfigurációs, és csomópont identifikációs szolgáltatásokat.

A diagnosztikai üzenetek (csomagok) szerkezetét és fajtáit részletesen leírja a Szállítási réteg, például hogy hogyan lehet megvalósítani olyan üzenetek küldését, melyek nem férnek bele a nyolc adatbájtba (összetett üzenetek).

A Diagnosztikai specifikáció az eszközök diagnosztikai osztályokba való besorolását részletezi, hogy mely elemek implementációja elengedhetetlen a mester vagy a szolga csomópontoknál az egyes diagnosztikai funkciók megvalósításához. Emellett kitér Diagnosztikai módokra, az ezekhez szükséges ütemezésekre és bizonyos követelményeket is megfogalmaz.

Alkalmazási Program Interfész, Konfigurációs és Identifikációs specifikáció

A legfelső réteg, azaz az API (Alkalmazási Program Interfész) célja a felhasználói alkalmazás elől elrejteni a LIN hálózat konfigurációs részleteit, mely mellett egységes felületet biztosít a különféle alkalmazási programoknak a LIN klaszterek elérésére. Továbbá a szabvány API specifikációja megadja a szoftverfejlesztés menetét, a szükséges beépítendő interfészeket (mintakódokkal kiegészítve C nyelvben).

A fennmaradó Konfigurációs és Identifikációs specifikáció célja a szoftverek közti eltérésekből adódó konfliktusok elkerülése, csökkentése, és szintén programozási tanácsokkal látja el a klaszter tervezőjét.



[2] A LIN szabvány keretként hivatkozik magukra az üzenetekre, azonban a keret kifejezés – az OSI modell szerint – csupán az Adatkapcsoalti réteg szintjén létezik. Ezért a továbbiakban üzenetként hivatkozik rá a szöveg.

[3] Léteznek még foglalt üzenetek, későbbi felhasználásra lefoglalva, de ezek használata nem engedélyezett.