LIN

Das Local Inter­connect Net­work (LIN) Bus­sys­tem wur­de als Low-Cost Bus­sys­tem von einem Her­stel­ler­kon­sor­ti­um mit Moto­ro­la und Frees­ca­le als Halblei­ter­her­stel­lern und einer Rei­he von Auto­mo­bil­her­stel­lern ent­wor­fen. Sei­ne Ziel­set­zung war: Ein Sub-Bus­sys­tem für CAN zu schaf­fen, das für Sen­sor/Aktor-Net­ze kos­ten­güns­ti­ger als CAN sein soll­te.

LIN – Local Inter­connect Net­work

LIN ver­wen­det als Bus­zu­griffs­ver­fah­ren das Mas­ter-Sla­ve-Prin­zip. Ein Mas­ter­steu­er­ge­rät, das in der Regel gleich­zei­tig als Gate­way zwi­schen LIN und CAN funk­tio­niert, teilt den ein­zel­nen Sla­ve-Steu­er­ge­rä­ten durch eine Mas­ter-Request-Bot­schaft jeweils die Sen­de­be­rech­ti­gung zu. Die Sla­ve-Kno­ten selbst benö­ti­gen kei­ne Kon­fi­gu­ra­ti­ons­in­for­ma­tio­nen und haben gerin­ge Anfor­de­run­gen an die Takt­ge­nau­ig­keit. Sie kön­nen so kos­ten­güns­tig evtl. sogar ohne Quarz aus­ge­führt wer­den. Das Bus­sys­tem ent­hält rela­tiv weni­ge Mecha­nis­men zur Erken­nung von Über­tra­gungs­feh­lern und kaum Mecha­nis­men zur Feh­ler­kor­rek­tur. Dies muss alles inner­halb der Soft­wa­re umge­setzt wer­den.

LIN Ver­si­ons­ge­schich­te

LIN hat trotz sei­ner rela­tiv jun­gen Geschich­te bereits eine gan­ze Rei­he von Ver­sio­nen durch­lau­fen: Spe­zi­fi­ka­ti­ons­ver­sio­nen, die immer umfang­rei­cher wur­den. Die Ver­sion 1.3 wur­de als ers­te Ver­sion rich­tig ein­ge­setzt. Kurz danach kam jedoch schon 2.0 und im Jahr 2006 die Ver­sion 2.1. Zu den Erwei­te­run­gen, die nicht alle auf­wärts­kom­pa­ti­bel sind, gehört unter ande­rem die Fähig­keit, dass Dia­gno­se­bot­schaf­ten von KWP 2000 oder UDS über LIN getun­nelt wer­den kön­nen.

Das LIN-Bus­sys­tem selbst hat einen sehr ein­fa­chen phy­si­ka­li­schen Layer. Auch die Anfor­de­run­gen an die Mikro­kon­trol­ler zur Imple­men­tie­rung von LIN sind gering. Man braucht kei­nen Kom­mu­ni­ka­ti­ons­con­trol­ler – ein ein­fa­cher UART genügt. Der Rest des Pro­to­kolls kann in Soft­wa­re abge­wi­ckelt wer­den. Den­noch soll­te man bei LIN Sub-Bus­sys­te­men nicht unter­schät­zen, dass ins­be­son­de­re die Gate­way-Funk­tio­na­li­tä­ten zwi­schen CAN und LIN, sowie das Anpas­sen unter­schied­li­cher Timings, die­se Gesamt­fahr­zeug­net­ze rela­tiv kom­plex machen.

Physical Layer und Bus-Topologie

Die Über­tra­gung arbei­tet zei­chen­ba­siert mit UART-ähn­li­chen Zei­chen. Der Phy­si­cal-Layer ent­spricht im Wesent­li­chen der K-Line. Das heißt, es han­delt sich um einen Ein-Draht-Bus mit Bat­te­rie­span­nungs­pe­gel. Es ist kein Kom­mu­ni­ka­ti­ons­con­trol­ler not­wen­dig. Das Pro­to­koll ist so ein­fach, dass es mit jedem UART bzw. der ent­spre­chen­den Soft­wa­re imple­men­tiert wer­den kann. Die Anfor­de­run­gen an das Timing sind, wie schon gesagt, rela­tiv gering. Ein Mas­ter kann eine gan­ze Rei­he von Sla­ves steu­ern. Die Bitra­te ist im Hin­blick auf den ein­fa­chen Phy­si­cal-Layer maxi­mal 20 kbit/s. Real im Ein­satz sind Bitra­ten von 9,6 kbit/s, 10,4 kbit/s oder 19,2 kbit/s.

Phy­si­cal Layer und Bus-Topo­lo­gie

Data Link Layer

Das Bus­sys­tem ver­wen­det das in der Abbil­dung dar­ge­stell­te Bot­schafts­for­mat. Der Hea­der wird grund­sätz­lich vom Mas­ter aus gesen­det. Dann folgt eine kur­ze Pau­se und dar­auf folgt eine Respon­se. Die­se kommt ent­we­der auch vom Mas­ter­steu­er­ge­rät, wenn der Mas­ter etwas an die Sla­ves zu sen­den hat oder von einem Sla­ve-Steu­er­ge­rät, wenn eine Ant­wort erwar­tet wird.

LIN Bot­schafts­for­mat

Der Hea­der beginnt mit einer 13 bis 26 Bit lan­gen Null- und einer 1 bis 14 Bit lan­gen High-Bit­fol­ge. Danach kommt ein Byte mit abwech­selnd Nul­len und Ein­sen, das so genann­te Sync-Byte. Das Sync-Byte der Syn­chro­ni­sa­tion der Emp­fän­ger auf die Bitra­te des Mas­ter­steu­er­ge­rä­tes. Danach folgt der so genann­te Pro­tec­ted-Iden­ti­fier (PID) – eine Art Mes­sa­ge-Iden­ti­fier mit einer ganz ähn­li­chen Funk­tion wie bei CAN. Er kenn­zeich­net ein­deu­tig den Inhalt der Bot­schaft und auch den Sen­der der fol­gen­den Respon­se. Denn bei der Ent­wick­lung wur­de bereits ein­deu­tig fest­ge­legt, wel­ches Steu­er­ge­rät auf wel­che PID eine Respon­se zu sen­den hat. Die PID ent­hält nur 6 Bit für die eigent­li­che PID. Das heißt, es gibt maxi­mal 64 ver­schie­de­ne Bot­schaf­ten. Zwei wei­te­re Bits wer­den für die Feh­ler­er­ken­nung als Pari­täts-Bits ver­wen­det. Im Karos­se­rie­be­reich sind das sehr häu­fig Auf­ga­ben, bei denen das Steu­er­ge­rät auch bei aus­ge­schal­te­ter Zün­dung noch funk­tio­nie­ren muss.

Dort ist aller­dings der Strom­ver­brauch wich­tig. Des­we­gen ver­setzt man Bus­sys­te­me und Steu­er­ge­rä­te in die­sem Fall häu­fig in einen Schlaf-Modus, um Ener­gie zu spa­ren. Um die­sen Schlaf-Modus kon­trol­liert ein­lei­ten und auch wie­der been­den zu kön­nen, hat man in der LIN-Spe­zi­fi­ka­tion vor­ge­se­hen, dass das Bus­sys­tem nach 4 Sekun­den Busi­n­ak­ti­vi­tät, also wenn der Bus mehr als vier Sekun­den in Ruhe war, auto­ma­tisch in den Sleep-Zustand über­geht. Durch eine vom Mas­ter ver­sen­de­te Bot­schaft mit dem PID 0x3C kann der Bus auch aktiv in den Schlaf-Modus ver­setzt wer­den. Umge­kehrt kann jedes Steu­er­ge­rät am LIN-Bus das Bus­sys­tem durch einen so genann­ten Wake-Up-Pat­tern (WUP) wie­der auf­we­cken. Das Mas­ter­steu­er­ge­rät muss nach einem Auf­weck­vor­gang inner­halb von 100 ms wie­der die regu­lä­re Kom­mu­ni­ka­tion begin­nen.

Der Mas­ter des LIN-Bus­sys­tems arbei­tet zeit­syn­chron. Die­ser ent­hält in der Regel eine so genann­te Sce­du­ling-Table, in der fest­ge­legt ist, zu wel­chem Zeit­punkt wel­che PID ver­sen­det wird. Die Kon­fi­gu­ra­tion des Net­zes erfolgt typi­scher­wei­se mit Hil­fe einer so genann­ten LDF-Datei (LIN-Des­crip­tion-For­mat).

Ange­sichts der nied­ri­gen Bitra­te ist die Nutz­da­ten­ra­te mit 1,2 kBy­te/s rela­tiv beschei­den. Es ist somit ca. 25 Mal lang­sa­mer als High-Speed-CAN.

Botschaftstypen

Obwohl bei LIN alle Bot­schaf­ten immer das­sel­be Bot­schafts­for­mat ver­wen­den, unter­schei­det die Spe­zi­fi­ka­tion fol­gen­de unter­schied­li­che Bot­schaft­s­ty­pen:

• Uncon­di­tio­nal-Fra­mes (Stan­dard­f­ra­mes)
  • Nor­ma­le zyklisch über­tra­ge­ne Stan­dard­f­ra­mes
    
    
• Event-Trig­ge­red-Fra­mes
  • Für Daten, sie sich sel­ten ändern
  • Meh­re­re Sla­ves kön­nen auf einen Request ant­wor­ten
  • Es ant­wor­ten nur die Sla­ves, bei denen sich Daten geän­dert haben
  • Mas­ter erkennt Sla­ve am ers­ten Daten­by­te der Respon­se → PID des Stan­dard­f­ra­mes
  • Erkennt der Mas­ter Kol­li­sion, fragt er die Stan­dard­f­ra­mes ab bevor er wie­der Event Trig­ge­red Fra­mes sen­det
  • Nicht deter­mi­nis­tisch
    
    
• Spo­ra­dic-Fra­mes
  • Platz­hal­ter in der Sche­du­ling-Table für dyna­mi­sches Ver­hal­ten des Mas­ters
  • Sonst bleibt der Bus in die­sem Slot in Ruhe
  • Mas­ter kann einen von meh­re­ren mög­li­chen PIDs ver­wen­den
  • Aus­wahl der Bot­schaft über sta­ti­sche Prio­ri­tät → Sche­du­ling-Table
  • Ereig­nis­ge­steu­ert, nicht deter­mi­nis­tisch
  • Dann, wenn sich Daten im Mas­ter geän­dert haben oder vom Mas­ter Ant­wor­ten gefor­dert wer­den (Mas­ter als Sla­ve)
    
    
• Dia­gno­stic-Fra­mes PID (0x3C und 0x3D)
  • Immer mit 8 Daten­by­tes
  • Für Kon­fi­gu­ra­tion und Dia­gno­se der Sla­ves
  • Dia­gno­se über ISOTP oder UDS ohne Fluss­steue­rung
  • Mas­ter sen­det Dia­gno­se-Request über 0x3C und holt die Respon­se vom Sla­ve über 0x3D ab
    
    
• User­de­fi­ned-Fra­mes (PID 0x3E)
  • Daten­feld darf län­ger als 8 Byte sein
    
    
• Reser­ved-Fra­mes (PID 0x3F)
  • Für zukünf­ti­ge Erwei­te­run­gen
  • Darf z.Z. nicht ver­wen­det wer­den

Uncon­di­tio­nal-Fra­mes sind die Stan­dard-Fra­mes, die in jedem Kom­mu­ni­ka­ti­ons­zy­klus in den ent­spre­chen­den Zeit­schlit­zen ver­sen­det wer­den müs­sen. Der wesent­li­che Unter­schied von Event-Trig­ge­red-Fra­mes gegen­über Stan­dard-Fra­mes besteht darin, dass bei einem Stan­dard-Fra­me grund­sätz­lich jedem PID genau ein Steu­er­ge­rät für die Respon­se zuge­ord­net ist. Auf die PID eines Event-Trig­ge­red-Fra­mes ant­wor­ten jedoch meh­re­re Steu­er­ge­rä­te. Sie kön­nen das natür­lich nicht gleich­zei­tig. Soll­ten sie das den­noch tun, kommt es zu einer Kol­li­sion. Hier beschreibt die Spe­zi­fi­ka­tion wie sol­che Kol­li­sio­nen auf­zu­lö­sen sind. Ganz ähn­lich sind die Spo­ra­dic Fra­mes. Die­se stel­len Platz­hal­ter für Bot­schaf­ten dar, die nicht in jedem Zeit­schlitz ver­sen­det wer­den müs­sen. Für das Ver­sen­den von Dia­gno­se­bot­schaf­ten hat die Norm zwei PIDs reser­viert, eine für den Dia­gno­se-Request (0x3C), die ande­re für die Dia­gno­se-Respon­se (0x3D). Zwei wei­te­re PIDs (0x3E und 0x3F) sind für zukünf­ti­ge bzw. her­stel­ler­spe­zi­fi­sche Erwei­te­run­gen reser­viert.

Siehe auch

CAN - Con­trol­ler Area Net­work

FlexRay

MOST - Media Oriented System Transport

K-Line

SAE J1850

SAE J1708