LIN-Bus

Joshua B. Knobloch
SS 2014

1 Einführung
1.1 Motivation
Seit den 80er Jahre ist es notwendig, dass sich mikroprozessorgesteuerte Sys-
teme in einem Fahrzeug untereinander austauschen können. Dies geschah
zunächst mit einfachen Punkt-zu-Punkt-Verbindungen, was zu einer Zunah-
me an Gewicht und Komplexität im Kabelbaum führte. Durch den Siegeszug
der Elektrik und Elektrotechnik in der Automobilindustrie wurden die Ka-
belbäume jedoch so schwer und komplex, dass schon bald eine andere Lösung
zur Kommunikation gefunden werden musste.
Anfang der 90er Jahre wurde mit dem CAN der erste herstellerübergreifende
Bus eingeführt. Der CAN ist ein von Bosch entwickelter und später durch
die ISO11898 und SAEJ1939 standardisierter Klasse B bis Klasse C Bus (
Abbildung 1). Er dient hauptsächlich zur Vernetzung von Steuergeräten.

Aus Kostengründen wurde zur Datenübertragung im Sensor/Aktor-Bereich

jedoch entweder weiterhin die konventionelle Verdrahtung eingesetzt oder
jeder Hersteller entwickelte seinen eigenen Low-Speed-Bus. Um die Komple-
xität im Kabelbaum und die Herstellungskosten noch weiter zu senken wur-
de ende der 90er Jahre der herstellerübergreifende LIN(Local Interconnec-
tet Network)-Standard etabliert. Heute ist das LIN-System der De-facto-
Standard für Übertragungen im Low-Speed Bereich und in so gut wie jedem
Fahrzeug zu finden.
Typische Aufgaben sind u.a. das Übertragen von Daten in Türmodulen, Re-
gensensoren, Sitzsteuerung oder Stellmotoren z.B. bei Klimasystemen.
 Abbildung 1: SAE Klassifizierung von Bussystemen [1, S. 41]

1.2 Technische Daten

Der LIN-Bus ist ein von der Society of Automotive Engineers (SAE) als
Klasse A (Abbildung 1) definierter Low-Speed-Bus. Es wird eine bidirektio-
nale Ein-Draht-Leitung mit einer maximalen Übertragungsrate von 20kbit/s
betrieben. Die in der Praxis üblichen Raten liegen jedoch bei 2.4kbit/s,
9.6kbit/s oder 19.2kbit/s. Der dominante Wert ist die Null.
Es können bis zu 16 Teilnehmer zu einem Cluster zusammengeschlossen wer-
den, wobei die maximale Entfernung zwischen zwei Knoten nicht mehr als
40 m betragen darf ohne zusätzlich einen Repeater mit einzubinden.
Ein LIN-Cluster besteht aus einem Master Task und mehreren Slave Tasks.
Im Gegensatz zu den Slave Knoten, welche nur den Slave Task enthalten,
besitzt der Master Knoten zusätzlich einen Master Task (Abbildung 2). Der
Master legt fest wann welches Frame auf dem Bus gesendet wird. Dazu wird
eine Time-Schedule-Tabelle (Kapitel 3) abgearbeitet, was das System deter-
ministisch macht.
LIN basiert auf der weit verbreiteten UART-Schnittstelle, womit die Kosten
für die Anschaffung der elektrischen Schaltung gering gehalten werden kön-
nen.
Im Fahrzeug ist ein LIN-Cluster oftmals ein Subsystem eines CAN-Busses
 Abbildung 2: LIN-Cluster [1, S. 87]

(Abbildung 2), was es erforderlich macht, eine Schnittstelle bereit zu stellen,

welche die beiden Systeme verbindet. Diese Aufgabe übernimmt ebenfalls
der Masterknoten indem er als Gateway fungiert und so die Kommunikation
zwischen den beiden Bussystemen sicherstellt.

2 Bitübertragungsschicht
Zur Übertragung der Bits nutzt LIN eine nach ISO 9141 genormte, bidirek-
tionale Eindrahtleitung. Die Bitübertragungsschicht agiert unabhängig von
höher gelegenen Schichten wie z.B. der Protokollschicht, weshalb Knoten pro-
blemlos versionsübergreifend miteinander kooperieren können. Das System
ist auf eine Bordnetzspannung von 8 bis 18 V und eine Bietriebstemperatur
von -40 bis zu 125°C ausgelegt.

2.1 Transceiver
Die elektrischen Hauptbestandteile des Transceivers sind ein Pull-Up-Wiederstand,
der mit der Versorgungsspannung verbunden ist, und ein Transistor, welcher
über die Masse gekoppelt wird. Die Diode verhindert dass über die LIN-
Signalleitung Strom in den Knoten fliest. (Abbildung 3)

Durch die parallele Schaltung aller Transistoren mit der Masse ist der Low-
Pegel dominant. D.h. es reicht dass ein ein Transistor eine Null sendet und
die komplette Leitung nimmt den dominanten Wert an. Nur wenn alle Kno-
ten die Transistoren sperren liegt auf der Leitung der rezessive Wert (die 1
wird gesendet) an.
 Abbildung 3: Teilausschnitt eines LIN-Transceivers [1, S.107]

2.2 Signalspezifikation
Um einen rezessiven Wert, also eine logische 1, zu senden, muss ein Kno-
ten mindestens 60% der Versorgungsspannung auf die Leitung legen. Ein
Wert unter 40% wird als dominanter Wert, also als eine logische 0, er-
kannt.(Abbildung 4)

Abbildung 4: Signalpegel von LIN [2, S. 119]

3 Protokolle
Im LIN-Bus wird die Kommunikation zwischen Master-Slave und Slave-Slave
Knoten ausschließlich vom Master, mit Hilfe sogenannter Frames (siehe Ka-
pitel 2.1), gesteuert. Wann welcher Frame gesendet wird, steht in der Time-
Schedule-Tabelle des Master Tasks. Ein Master kann mehrere Tabellen haben
und z.B. bei eine Kollision von seiner normalen Tabelle auf eine Andere über
gehen, damit die Kollision gelöst werden kann. Danach wird er wieder auf
die normale Tabelle wechseln und diese periodisch abarbeiten.
Grundsätzlich gibt es drei verschiedene Arten des Informationsaustausches
(Abbildung 6):

• der Master fordert Daten von Slaves an

 • der Master liefert den Slaves Daten

• Slaves tauschen Daten untereinander aus

3.1 Frames
Ein Frame besteht, wie in Abbildung 5 dargestellt, aus einem Header und
einem Response. Der Header wiederum beinhaltet das Breakfield, das Sync-
field und den Identifier und initialisiert einen Datenaustausch. Im Response
findet dann der eigentliche Datenaustausch statt. Er wird immer, auch im
Masterknoten, vom Slave Task erzeugt und ist die Antwort auf den Header.

Abbildung 5: Aufbau eines Frames [2, S. 29])

3.1.1 Breakfield
Das Breakfield wird immer vom Masterknoten initialisiert und signalsiert den
Slaveknoten den Begin eines neuen Frames. Es ist mindestens 13 Bitzeiten auf
dem dominanten Wert und dann mindestens eine Bitzeit auf dem rezessiven
Wert.

3.1.2 Syncfield
Zur Synchronisation der Slaves sendet der Master nach dem Breakfield ein
0x55 Datenbyte. Die Slaves messen die Zeit, die sie benötigen um das Byte zu
empfangen und teilen sie durch 8. Für die Messung wird die fallende Flanke
verwendet, da diese steiler als die steigende ist.
3.1.3 Identifier
Das Identifierbyte lässt sich nochmals in den Frameidentifier und die Parity
aufgliedern. Um das Frame zu identifizieren werden die Bits 0 bis 5 benutzt,
was insgesamt 64 Codierungen möglich macht, welche wie folgt verteilt sind:

• 0-59: Signalübertragung

• 60 und 61: Diagnose und Konfiguration

• 62 und 63: für zukünftige Anwendungen reserviert

Die Bits 6 und 7 sind Paritybits und werden durch folgende Formel berechnet:

P 0 = ID0 ⊕ ID1 ⊕ ID2 ⊕ ID4

P 1 = ID1 ⊕ ID3 ⊕ ID4 ⊕ ID5

Wegen diese Paritybits spricht man auch oft vom „Protected Identifier“. [1,
S. 93]

3.1.4 Datenfeld
Das Datenfeld ist der erste Teil der durch einen Slave Task erzeugten Ant-
wort. Seine Länge ist vom Identifier abhängig, jedoch maximal 8 Bytes lang.
Jedes Byte beginnt mit dem LSB (little-endian).

3.1.5 Checksumme
Die Checksumme komplettiert jeden Frame und ist eine der wenigen Mög-
lichkeiten einen Übertragungsfehler festzustellen.
Die Kommunikation mit Slaves der Version 1.x, das „master request frame“
und das „slave response frame“, benutzen die classic Checksumme. Sie wird
über die Bytes des Datenfeldes gebildet.
Zur Kommunikation mit Slaves der Version 2.x wird die enhanced Checks-
umme verwendet. Diese bezieht den „Protected Identifier“ zusätzlich mit ein.
Im „Protected Identifier“ werden die Bits 0 bis 5 zur Identifikation des Fra-
mes benutzt und die Bits 6 und 7 dienen als Parity-Bits um eventuelle Fehler
zu erkennen. Für das „master request frame“ und das „slave response frame“
wird jedoch weiterhin die classic Checksumme verwendet.
3.2 Frametypen
Es gibt insgesamt drei Frametypen, welche im Folgenden vorgestellt werden.
Wichtig ist, dass ein LIN-Cluster nicht unbedingt alle Typen unterstützen
muss, sondern nur die für die Anwendung wichtigen.

3.2.1 Unconditional Frame

Mit dem unconditional Frame werden standardmäßig Signale ausgetauscht.
Die zulässigen Identifier gehen von 0 bis 59. Der Header wird immer aus-
schließlich vom Master Task versendet und kann von einem oder mehreren
Slaves beantwortet werden (Abbildung 6). Bei fehlerfreier Übertragung sollte
ein Slave immer antworten. Unconditional Frames werden periodisch wieder-
holt.

Abbildung 6: Drei Arten des Signalaustausches [2, S. 34]

3.2.2 Event Triggered Frame

Das Event Triggered Frame soll verhindern, dass selten auftretende Ereignisse
zu viel Bandbreite beanspruchen. Dazu werden mehrere Unconditional Fra-
mes von mehreren Slaves zu einem Event Triggered Frame zusammengefasst.
Das bedeutet, dass ein Event Triggered Frame mehrere Antworten erhalten
kann. Der Identifier liegt zwischen 0 und 59, er darf aber nicht gleichzeitig von
einem Unconditional Frame belegt sein. Außerdem müssen die Datenfeldgrö-
ße und das Checksummenmodell bei allen Unconditional Frames gleich sein.
Ein Mix aus classic und der enhanced Checksumme ist also nicht möglich.

Um Bandbreite zu sparen antworten nur die Slaves, bei denen sich ein Wert
seit der letzten Abfrage geändert hat. Ist das jedoch bei keinem der Fall,
so bleibt die Leitung nach dem Senden des Headers leer. Umgekehrt kann
es aber auch passieren, dass mehrere Slaves eine Änderung mitteilen wollen.
Damit der Master weiß, welcher Slave ihm antwortet, wird in das erste Byte
des Datenfeldes der Identifier eingetragen. Es bleiben also nur 7 Bytes zur
Datenübertragung übrig.
Wollen mehrere Slaves auf das Event Triggered Frame antworten, kommt es
zu einer Kollision auf der Leitung. In diesem Fall gibt es zwei Möglichkeiten,
wie die Kollision verlaufen kann.

1. Fall:
Allgemein ist jeder Slavetask dazu verpflichtet, das Gesendete zurückzule-
sen und bei einem Fehler das Senden des nächsten Bytes einzustellen. Der
Master bekommt diese Kollision aber nur mit, wenn alle Slaves das Senden
einstellen. Abbildung 5 soll hierzu ein Beispiel liefern.

Abbildung 7: Beide Slaves bemerken die Kollision und stoppen die Übertra-
gung [1, S. 97]

Beim Zurücklesen haben beide Slaves bemerkt, dass ein Fehler aufgetreten
ist und stellen das Senden des zweiten Datenbytes ein. Nun bemerkt auch
der Master die Kollision und wechselt von seiner normalen Time-Scheduling-
Tabelle auf eine andere. Er sendet nun einmalig jedes Unconditional Frame,
welches im Time Triggered Frame zusammengefasst wurden, und wechselt
danach wieder zu seiner gewohnten Time-Scheduling-Tabelle.

2. Fall:
Wie in Abbildung 6 beispielhaft dargestellt kann es auch passieren, dass ein
Slave, und somit auch der Master, die Kollision nicht bemerkt.

Abbildung 8: Nur ein Slave bemerkt die Kollision [1, S. 97]

Durch die dominante Null wird das Byte von ID0 korrekt übertragen, so dass
der Master keine Möglichkeit hat, zu erkennen, dass auch ID1 einen geän-
derten Wert übermitteln wollte. ID1 muss nun auf die nächste planmäßige
Abfrage des Masters warten, um den Wert übermitteln zu können.

3.2.3 Sporadic Frame

In der Time-Scheduling-Tabelle des Masters dienen die Sporadic Frames als
Platzhalter. Der Master hat hier die Möglichkeit, zwischen mehreren Un-
conditional Frames zu wählen. Benötigt er jedoch keine Daten, sendet er
keinen Header und der Zeitslot bleibt leer. Tritt der Fall ein, dass er mehre-
re Unconditional Frames senden möchte, muss er sich für den mit höchster
Priorisierung entscheiden.

3.2.4 Diagnostic Frame

Für die Diagnostic Frames sind die Identifier 60 und 61 vorgesehen. Der
Master nutzt den Identifier 60, um eine Konfiguration oder Diagnose durch-
zuführen und die 61, um eine Bestätigung der erfolgreichen Änderung vom
Slave zu erhalten.

3.2.5 User-Defined und Extendet Frame

Der User-Defined Frame ist für eine kundenspezifische und der Extendet
Frame für eine zukünftige Erweiterung reserviert. Beide Frames sind im Da-
tenfeld nicht auf 8 Bytes beschränkt, weshalb darauf zu achten ist, dass die
LIN-Knoten keinen Slave-Not-Responding-Fehler anzeigen, wenn die maxi-
male Übertragungszeit überschritten wird.

3.3 Fehlererkennung
Da der LIN-Bus für einfache Aktor-Sensor Anwendungen entwickelt wurde
und keine sicherheitskritischen Systeme vernetzt, gibt es nur wenige Mecha-
nismen, um Fehler zu erkennen. In den folgenden Abschnitten werden die
Wichtigsten beschrieben.

3.3.1 Bitfehler
Der Bitfehler wird vom sendenden Slave-Task selbst erkannt. Wenn beim
Rücklesen der gesendeten Daten ein Fehler festgestellt wird, muss das Senden
sofort, spätestens aber nach dem Senden des Bytes, abgebrochen werden.
3.3.2 Identifier-Parity-Fehler
Jeder Slave-Task überprüft die beiden Paritätsbits beim Empfang eines Hea-
ders. Stimmen die Bits nicht, handelt der Slave wie bei einem unbekannten
Identifier und verwirft die Nachricht.

3.4 Checksum Error

Jeder übertragene Frame enthält eine Checksumme, welche nach dem Emp-
fangen einer Nachricht überprüft wird. Jeder Slave-Task, sowohl vom Slave
als auch vom Master-Knoten, ist in der Lage einen Checksum Error festzu-
stellen. Eine Korrektur oder Mitteilung des Fehlers ist jedoch nicht möglich.

Gründe für die angesprochenen Fehler können Schwankungen in der Span-

nung oder Magnetfelder sein.

3.5 Netzwerkmanagement
Wie in Abbildung 9 zu sehen ist, kennt LIN drei Zustände im Netzwerkma-
nagement.

Abbildung 9: Netzwerkmanagement [2, S. 45]

Sobald ein Knoten an eine Stromquelle angeschlossen wird, geht er in den

Initialisierungszustand über. In diesem Zustand darf er maximal 100ms ver-
bleiben, bevor er in den Betriebsmodus wechselt und bereit ist, den ersten
Header zu empfangen. Um nun in den Sleep Mode zu gelangen, muss entwe-
der vom Master ein Sleep Request kommen oder der Bus muss für mindestens
4, aber höchstens 10, Sekunden inaktiv gewesen sein. Im Sleep Mode wird
der Bus auf den rezessiven Wert gesetzt. Er kann nur durch ein Wake-Up
Signal, welches von jedem Slave Task gesendet werden kann, wieder in den
Initialisierungszustand springen.

3.5.1 Go-To-Sleep Signal

Nur der Master ist in der Lage, das Go-To-Sleep Kommando zu erteilen.
Dazu sendet er einen Master-Request-Frame mit dem Identifier 60. Im Da-
tenfeld wird das erste Byte auf 0 (0x00) und die restlichen sieben auf 0xFF
gesetzt. Das Go-To-Sleep Signal bedeutet nicht automatisch, dass in einen
Stromsparmodus gewechselt wird. Dies ist von der Application abhängig.

3.5.2 Wake-Up Signal

Im Gegensatz zu dem Go-To-Sleep Signal, welches nur vom Master gesendet
werden kann, hat jeder Slave Task die Möglichkeit, den Bus zu wecken. Das
Signal besteht aus einem Wake-Up-Request und einem Wait.
Im Wake-Up-Request wird ein dominantes Signal für 250 µs bis maximal 5 ms
gesendet. Danach folgt eine Wartezeit von 100 ms, in der die Knoten Zeit ha-
ben, in den Betriebsmodus zu gelangen. Es werden bereits Wake-Up-Requests
ab einer Länge von 150 µs akzeptiert, um eventuelle Laufzeitunterschiede aus-
zugleichen. Folgt nach spätestens 150 ms kein Synchronisiationsbreak wird
das Wake-Up-Signal erneut versendet. Dies kann bis zu drei mal wiederholt
werden. Anschließend muss eine Pause von 1,5 s eingelegt werden bevor ein
viertes Signal verschickt werden darf.

4 Konfiguration von Knoten

Die Möglichkeit Knoten zu konfigurieren wurde mit Version 2.0 eingeführt
und ermöglicht die dynamische Vergabe von Identifiern. Mit dieser Neuerung
ist es fortan möglich sogenannte Of-The-Shelf-Knoten (Kapitel 4.1) herzu-
stellen und in jeden beliebigen LIN-Cluster zu integrieren, ohne vorher Än-
derungen an der Software vorzunehmen.

Der Master nutzt den Identifier 60 um einen Master-Request-Frame zu sen-

den und überprüft anschließend ob die Änderung erfolgreich durchgeführt
wurde, indem er mit dem Identifiere 61 einen Slave-Response-Frame ver-
schickt.
Bei jedem Aufstart des System muss der Master diese Prozedur mithilfe ei-
ne Time-Scheduling-Tabelle durchführen um jedem Slave einen Identifier für
die Frames zuzuweisen. Danach wechselt der Master auf die normale Time-
Scheduling-Tabelle.

4.1 Off-The-Shelf-Knoten
Um die Kosten für einen einzelnen Knoten noch weiter zu senken, wurde der
Off-The-Shelf-Knoten eingeführt. Das bedeutet, der Hersteller des Knotens
liefert alle wichtigen Daten, wie z.B. Protokollversion, Herstellercode, imple-
mentierte Frames oder Bitübertragungsrate, in einem Node Capability File
(NCF) mit aus. Anhand dieser Informationen kann der Master im normalen
Netzwerkbetrieb jeden Knoten leicht in den Cluster integrieren. Dazu konfi-
guriert er die Identifier des Knotens neu.

5 Zusammenfassung
Nach über 15 Jahren Entwicklung und Verbesserung findet man heute aus
gutem Grund in fast jedem Fahrzeug einen LIN-Bus. Durch seine weltweite
Standardisierung und leichte Konfigurierbarkeit ist er billig in der Anschaf-
fung und schnell in jeden Cluster integriert. Durch die Nutzung einer Ein-
drahtleitung werden zusätzliche Kabel im Kabelbaum eingespart, was das
Gewicht des Fahrzeugs weiter reduziert. Durch die Master-Slave Hierarchie
und die Kommunikation über Frames wird das System einfach gehalten und
gleichzeitig werden Kollisionen reduziert.
Da der LIN-Bus meist als Sub-Bus eines CAN eingesetzt wird und nur sicher-
heitsunkritische Aufgaben zugeteilt bekommt, sind Schwachstellen wie man-
gelnde Fehlererkennung und Behandlung oder eine maximale Datenübertra-
gung von gerade einmal 20 kbit/s im Vergleich zu den Vorteilen hinnehmbar.

Literatur
[1] Hans-Christian von der Wense Andreas Grzemba. LIN-Bus. Franzis,
2005.
[2] LIN Consortium. Lin specification package revision 2.2a. 2010.
[3] Sebastian Stegemann Denis Müller, Dirk Sommer. Local interconnect
network (lin), Oktober 2009.
[4] Matthias Meier. Lin bus, Oktober 2007.

[5] Ralf Schmidgall Werner Zimmermann. Bussysteme in der Fahrzeugtech-

nik. Vieweg + Teubner, 2011.

[1, 2, 3, 4, 5]