Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Ausarbeitung
Local Interconnect Network
(LIN)
Denis Müller (761422)
Dirk Sommer (760422)
Sebastian Stegemann (760391)
13. November 2009
LIN-BUS Inhaltsverzeichnis
Inhaltsverzeichnis
1 Einführung 4
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Geschichtliche Entwicklung . . . . . . . . . . . . . . . . . . . . . . . 5
2 LIN Specification 7
2.1 Kommunikationsprinzip . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Aufbau eines LIN-Knotens . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Grundstruktur eines LIN-Transceiver . . . . . . . . . . . . . 9
2.4 Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.1 Frameaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4.2 Zeitsteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.3 Frametypen . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.4 Network Management . . . . . . . . . . . . . . . . . . . . . 17
2.4.5 Fehlererkennung . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.6 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.2 PDU Structure . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6 Konfiguration und Diagnose . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1 Node Configuration and Identification Specification . . . . . 22
2.6.2 Diagnostic Specification . . . . . . . . . . . . . . . . . . . . 23
2.7 Work-Flow-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7.1 Node Capability Language Specification . . . . . . . . . . . 24
2.7.2 Configuration Language Specification . . . . . . . . . . . . . 24
2.7.3 Application Programm Interface Specification . . . . . . . . 24
2.7.4 LIN-Cluster-Design-Prozess . . . . . . . . . . . . . . . . . . 25
3 Zusammenfassung und Ausblick 26
3.1 LIN-Bus in der Zusammenfassung . . . . . . . . . . . . . . . . . . . 26
3.2 Zukünftige Entwicklung . . . . . . . . . . . . . . . . . . . . . . . . 27
Literaturverzeichnis 28
Müller, Sommer, Stegemann 2
LIN-BUS Inhaltsverzeichnis Abkürzungsverzeichnis CAN Controller Area Network CF Consecutive Frames ECU Elektronic Controll Unit FF First Frame ID Identifier Kfz Kraftfahrzeug LDF LIN Description File LIN Local Interconnect Network LSB Least Significant Bit NAD Node Address for Diagnose NCF Node Configuration File PCI Protocol Control Information PDU Packet Data Unit PID Protected Identifier RSID Response Service Identifier SAE Society of Automotive Engineers SF Single Frame SID Service Identifier UART Universal Asynchronous Receiver Transmitter Müller, Sommer, Stegemann 3
LIN-BUS 1 Einführung
1 Einführung
1.1 Motivation
Der Mensch versucht zunehmend sein Leben so einfach und angenehm wie nur
möglich zu gestalten. Diese Entwicklung zeichnet sich sehr deutlich im Bereich des
Automobils ab. Durch die ständig wachsenden Anforderungen stiegen im Laufe der
Zeit die Zahl der verbauten Sensoren und Aktoren.
Lange war es üblich, die immer größere Zahl dieser Komfortkomponenten direkt
an ein zentrales Steuergerät (Elektronic Controll Unit (ECU)) anzuschließen und
es z. B. mit einem Controller Area Network (CAN)-Bus zu verbinden (siehe Abb.
1.1a).
(a) Konventionelle Vernetzung (b) LIN-Vernetzung
Abb. 1.1: Von der klassischen zur hierarchischen Architektur (Quelle: [VEC09])
„Dadurch, dass die Kosten, der Platzbedarf und das Gewicht mit der Elektroni-
fizierung stetig zunahmen, die Zuverlässigkeit gleichzeitig aber abnahm, erkannten
die Entwickler schnell die Vorzüge einer Vernetzung der Sensoren und Aktoren über
ein serielles Bussystem. Aber auch, weil die zunehmende Individualisierung viele un-
terschiedliche Kabelbaum- und Steckervarianten erforderlich macht, was wiederum
Müller, Sommer, Stegemann 4LIN-BUS 1.2 Geschichtliche Entwicklung die Produktion, Installation und Wartung erheblich erschwerte.“1 Aus Kostengrün- den war der CAN-Bus nicht für den Subbusbereich geeignet. Deshalb setzten seit Mitte der 90er Jahre viele Kraftfahrzeug (Kfz)-Hersteller und -Zulieferer ihre eigens entwickelten Busprotokolle ein. Im Jahr 1998 wurde duch den Local Interconnect Network (LIN)-Bus ein einheit- licher Standard vorgegeben, welcher den entstandenen „Wildwuchs“ der Subbuspro- tokolle eindämmen sollte. Mit der Entwicklung des LIN-Busses wurde eine einfache und kostengünstige Ergänzung hierarchischer Kfz-Netzwerke für sicherheitsunkriti- sche Anwendungen konzipiert. Inzwischen wird er weltweit in sehr vielen Fahrzeugen eingesetzt. Typische An- wendungen sind bisher im Komfortbereich des Kfz: Klima-, Sitz-, Tür- und Spiegel- steuerung. Die typische LIN-Vernetzung ist in Abbildung 1.1b am Beispiel einer Tür- steuerung zu sehen. Die Sensoren und Aktoren sind mit einer LIN-Busschnittstelle ausgestattet und über den LIN-Bus an das Türsteuergeräte (CAN-LIN-Gateways) angeschlossen. Diese hierarchische Architektur ermöglicht die Mehrfachnutzung von Sensorsi- gnalen. Des Weiteren kann die Elektronik flexibel an die entsprechende Plattform und Ausstattungsvariante angepasst werden. 1.2 Geschichtliche Entwicklung Am Rande der VDI-Tagung Elektronik im Kraftfahrzeug im Jahre 1998 entstand die Idee eines einheitlichen Kommunikationsstandards für mechatronische Syste- me. Dies führte daraufhin zur Gründung einer Arbeitsgruppe, dem LIN-Konsortium durch die Firmen DaimlerChrysler, BMW, Audi, Volkswagen, Volcano Communica- tion Technologies und Motorola. Bereits in der ersten Sitzung der Arbeitsgruppe im November 1998 wurden die Grundanforderungen an ein solches Netzwerk definiert. Und darauf hin das neue Subbussystem LIN entwickelt. Um die Kosten gering zu halten, wurde das Universal Asynchronous Receiver Transmitter (UART)-Protokoll verwendet. Im Sommer 1999 (siehe Abb. 1.2) stand die erste Version des LIN-Protokolls (Version 0.9) zu Verfügung. Sie bestand aus den Teilen Protokoll, Bitübertragungsschicht und dem Anwendungsschicht. Im März 2000 wurde auf einem Kongress der Society of Automotive Engineers (SAE) in Detroit die erste Version der Öffentlichkeit vorgestellt. Im selben Jahr er- schienen die Folgeversionen V1.1 und V1.2 in denen einige Verbesserungen integriert waren. Der erste Serieneinsatz erfolgte durch das Unternehmen DaimlerChrysler im Jahr 2001 in der SL-Klasse. Seit dem wurde LIN in allen Kfz-Klassen eingesetzt. 1 aus: [VEC09] Müller, Sommer, Stegemann 5
LIN-BUS 1.2 Geschichtliche Entwicklung
Abb. 1.2: Zeitstrahl der LIN-Entwicklung
In den Folgejahren bekannten sich die wichtigsten europäischen Automobilher-
steller eindeutig zum LIN-Bus als Subbus für mechatronische Applikationen. Die
Spezifikation 1.3 erschien im Jahre 2001. Bei dieser wurde die Bitübertragungs-
schicht überarbeitet und die Datensicherungsschicht hinzugefügt.
Im September 2003 erschien die LIN-Spezifikation 2.0. Das Ziel der Überarbeitung
bestand vor allem darin, sämtliche Voraussetzungen für die schnelle, einfache und
sichere Entwicklung von LIN-Netzwerken bereitzustellen. Der Einsatz von sogenann-
ten Off-The-Shelf-Knoten brachte dieses Vorhaben zum Ausdruck. Dabei handelt
es sich um Knoten die „von der Stange“ genommen und dann entsprechend für die
spezifischen Bedingungen eines LIN-Clusters konfiguriert werden können. Die LIN-
Spezifikation 2.1 wurde 2006 veröffentlicht. Im Vergleich zur Vorgängerversion wird
für eine bessere Verständlichkeit im Umgang mit LIN gesorgt.
Müller, Sommer, Stegemann 6LIN-BUS 2 LIN Specification
2 LIN Specification
2.1 Kommunikationsprinzip
Die Kommunikation in einem LIN-Netzwerk (LIN-Cluster), basiert auf dem Master-
Slave-Prinzip. Es gibt einen Master-Task, der die Kommunikation initiiert und meh-
rere Slave-Tasks, die die Nachricht übermitteln. Dabei besteht der Master-Knoten
sowohl aus dem Master-Task, als auch aus einem Slave-Task, um auch Daten an die
Slave-Knoten zu übermitteln (Siehe Abb. 2.1). Der Master-Knoten ist außerdem in
der Regel gleichzeitig Gateway zum CAN-Bus.
Die Kommunikation beruht darauf, dass alle Slave-Tasks auf dem Bus mithören
können. Der Master-Task beginnt jeden Frame mit dem Senden eines (Frame-)
CAN-Bus
Empfangs- Sende- Senderoutine
routine routine (Header)
Slave-Task Master Master-Task
Master
LIN-Bus
Empfangs- Sende- Empfangs- Sende-
routine routine routine routine
Slave-Task A Slave-Task B
Slave A Slave B
Abb. 2.1: Schematische Darstellung des Kommunikationsprinzips
Headers, der u. a. einen (Frame-)Identifier (ID) enthält. Abhängig von diesem ID
schaut nun jeder Slave-Task in einer ihm bekannten Liste, wie er zu reagieren hat.
• Der Slave-Task antwortet indem er seine (Frame-)Response sendet oder
• er wartet auf die (Frame-)Response eines anderen Slave-Tasks und übernimmt
Müller, Sommer, Stegemann 7LIN-BUS 2.2 Aufbau eines LIN-Knotens
diese oder
• er antwortet nicht und übernimmt auch keine Response.
Im Anschluss beginnt der Master-Task den nächsten Frame, indem er einen neuen
Header sendet.
Diese Kommunkationsbeziehungen und das Verhalten des ganzen LIN-Netzwerks
werden während der Entwicklungszeit festgelegt.
2.2 Aufbau eines LIN-Knotens
Der Aufbau eines LIN-Knoten lässt sich wie bei anderen Bustypen, z. B. dem CAN-
Bus, in drei Blöcke aufteilen (siehe Abb. 2.2).
Die einzelnen Blöcke müssen dabei
nicht unbedingt als Einzelchips ausge-
Input Microcontroller Output führt sein, sondern können auch in ei-
(Application)
nem Chip integriert werden. Die Halb-
leiterhersteller bieten verschieden Lö-
LIN-Controller sungen mit unterschiedlichen Integrati-
(Protocol)
onsstufen an.
Die Aufgabe des LIN-Transceivers ist
LIN-Transceiver unter Anderem die Wandlung von logi-
(Physical Layer)
schen Pegeln auf die physikalischen Pe-
gel und entspricht demnach dem Physi-
LIN cal Layer (Bitübertragungsschicht).
Abb. 2.2: Schematischer Aufbau eines Der LIN-Controller kümmert sich um
LIN-Knotens die Umsetzung des LIN-Protokoll, so
dass der darüber liegende Block nur an-
wendungsbezogene Aufgaben erledigen muss. Dazu könnte z. B. das Abfragen von
Sensoren oder das Steuern von Aktoren gehören.
2.3 Physical Layer
2.3.1 Allgemein
Das Ziel ein möglichst kostengünstiges Bussystem zu entwickeln, wird auch in dem
Physical Layer deutlich. Beim LIN-Bus verwendet man nicht wie beim CAN-Bus eine
differenzielle Signalübertragung, sondern einen Eindrahtleitung, die topologisch als
Müller, Sommer, Stegemann 8LIN-BUS 2.3 Physical Layer
Linie realisiert ist.1 Die Fahrzeugmasse dient dabei als Rückleiter. Um dennoch aus-
reichend Störfestigkeit sicher zu stellen, wird für den High-Pegel, die Versorgungs-
spannung und für den Low-Pegel die Masse verwendet. Die Schwellen des Senders
und des Empfängers werden dementsprechend festgesetzt. Der Sender muss den Bus
für einen Low-Pegel mindestens unter 20% der Versorgungsspannung(VSU P ) ziehen.
Der High-Pegel muss mindestens bei 80% der Versorgungsspannung auf der Sender-
seite liegen. Die Schwellen des Empfängers, bis zu denen er aus den physikalischen
Pegel die logischen Pegel interpretieren muss, sind toleranter. Ein Pegel unterhalb
von 40% der Versorgungsspannung wird vom Empfänger als eine logische Null und
oberhalb von 60% der Versorgungsspannung als logische Eins interpretiert (Siehe
Abb. 2.3). Eine Versorgungsspannung zwischen 8 V bis 18 V ist dabei zuläßig.
Außerdem beschränkt die LIN-Spezifikation die maximale Buslänge auf 40 m.
Abb. 2.3: Signalpegel des LIN-Bus (Quelle: [LIN06], bearbeitet, S. 116)
2.3.2 Grundstruktur eines LIN-Transceiver
Die Grundstruktur eines LIN-Transceiver ist
die Open-Collector-Schaltung, so dass der
Low-Pegel der dominante Pegel ist.
Der Pull-Up-Widerstand beträgt bei den
LIN-Slaves 30 kΩ und beim LIN-Master 1 kΩ.
Da diese Widerstände alle parallel am Bus lie-
gen, wird die maximale Anzahl an Teilnehmer
auf 16 begrenzt.
Da es sich beim LIN-Bus um eine unge-
schirmte Eindrahtleitung handelt, wurde die
Abb. 2.4: Grundprinzip des LIN- Baudrate auf maximal 20 kHz begrenzt und
Transceiver (Quelle: [GRZ05], S. 107) die minimale Anstiegs- und Abfallzeit der
Flanken vorgeschrieben. Dadurch wird unter
anderem verhindert, dass die Leitung abstrahlt. Die Baudrate kann ab 1 kHz ein-
gestellt werden, wobei in Eurpoa 9,6 kHz und 19,2 kHz und in Amerika 10,4 kHz
1 Vgl. [VEC09]
Müller, Sommer, Stegemann 9LIN-BUS 2.4 Protocol Specification
üblich sind.1
Darüber hinaus werden in der LIN-Spezifikation noch weitere Vorgaben, Eigen-
schaften und Grenzen bezüglich des Physical Layers festgelegt, auf die für weitere
Details an dieser Stelle verwiesen wird.
In vielen Fällen können fertig Transceiver verwendet werden, bei denen man dann
davon ausgehen kann, dass sie den Physical Layer spezifikationsgerechte umzuset-
zen.
2.4 Protocol Specification
In der Protocol Specification wird das Verhalten auf dem Bus, wie z. B. die Über-
mittlung und der Aufbau der Frames sowie das Verhalten der Knoten wie z. B. das
Network Management beschrieben.
2.4.1 Frameaufbau
Wie im Abschnitt 2.1 erläutert, besteht ein Frame aus dem vom Master-Tasks
gesendeten Header und der Response eines Slave-Tasks. Der Header besteht aus dem
Break Field, dem Sync Field und dem Protected Identifier Field. Die Response setzt
sich zusammen aus dem Datenfeld mit 1 bis 8 Datenbytes und der Checksumme.
Die Abbildung 2.5 verdeutlicht dies.
Frame
Header Response
Response space
Break Sync Protected Data 1 Data 2 Data N Checksum
field field identifier
field
Inter-byte space Inter-byte spaces
Abb. 2.5: Aufbau eines Frames (Quelle: [LIN06], S. 28)
Ein Frame beim LIN-Bus ist so gewählt, dass er bis auf das Break Field UART-
kompatibel. Jedes Byte wird von der seriellen Schnittstelle mit dem Least Significant
Bit (LSB) zuerst übertragen und von einem Start- und einem Stopp-Bit eingerahmt.
1 Nach: [GRZ05], S. 107
Müller, Sommer, Stegemann 10LIN-BUS 2.4 Protocol Specification
Zum Erzeugen des Break Fields wird in der Regel die Baudrate temporär herun-
tergesetzt und ein 0x00 Datenbyte ausgegeben. Nach dem das Startbit und die 8
Datenbits gesendet wurden, wird die Baudrate wieder erhöht und mit der Ausgabe
des Sync Field begonnen.
Im Nachfolgenden werden die einzelnen Frame-Abschnitte erläutert.
Break Field
Die Aufgabe des Break Fields ist es, den Beginn eines neuen Frames zu signa-
lisieren. Dazu sendet der Master-Task mindestens 13 Low-Bits. Der Slave muss
mindestens 11 davon erkennen. Nur durch das Übertragen von mindestens 13 do-
minanten Bits ist gewährleistet, dass jeder LIN-Slave den Start einer Datenüber-
tragung mitbekommt. Denn die LIN-Slaves dürfen aufgrund der Kostenreduzierung
Break
Break
delimiter
Abb. 2.6: Aufbau des Break Fields (Quelle: [LIN06], S. 29)
On-Chip-Resonatoren mit einer Frequenz-Toleranz von bis zu 14% verwenden.1 Der
nachfolgende Sync-Break-Delimiter, der aus mindestens einem 1 High-Bit besteht,
trennt das Sync-Break vom nachfolgenden Sync Field, das aufgrund der Verwen-
dung der seriellen Schnittstelle mit einem dominanten Startbit beginnt.
Sync Field
Das Sync Field dient den LIN-Slaves zur Einstellung eines netzwerkweit einheitli-
chen Bittaktes, so dass alle LIN-Slaves mit demselben Takt senden bzw. empfangen.
Der Master-Task sendet dazu das Datenbyte 0x55 (Vg. Abb. 2.7). Zur Ableitung des
Taktes messen die LIN-Slaves die Zeit zwischen der fallenden Flanke des Startbits
und die des 7. Datenbits. Sie teilen anschließend den Wert durch 8, zum Beispiel
durch Verschieben von drei Bits nach rechts. Die Messung über die fallenden Flan-
ken ist deutlich genauer, da der Pegel für das Low-Bit aktiv über den Transistor
auf Masse gezogen wird. Der High-Pegel hingegen ergibt sich über den Pull-up-
Widerstand.
Der synchronisierte Slaves muss dabei sicher stellen, dass er während der Über-
tragung der Frames die Synchronisation mit einer maximalen Abweichung von 2%
halten kann.2 Aufgrund der Verwendung der Start- und Stopp-Bits pro Byte, kön-
1 Vgl. [VEC09]
2 Vgl. [VEC09]
Müller, Sommer, Stegemann 11LIN-BUS 2.4 Protocol Specification
Sync field
8 Tbit
2 Tbit 2 Tbit 2 Tbit 2 T bit
start 0 1 2 3 4 5 6 7 stop
bit bit
Abb. 2.7: Aufbau des Sync Fields (Quelle: [LIN06], S. 111)
nen sich die empfangenden Slaves auch innerhalb eines LIN-Frames nachzusynchro-
nisieren.
Protected Indentifier
Die Aufgabe des Protected Identifier (PID) ist es, den Inhalt der Nachricht und nicht
wie bei anderen Protokollen üblich einen Knoten zu adressieren. Der PID setzt sich
aus dem eigentlichen ID mit sechs Bits und aus zwei Paritätsbits zusammen. Es sind
damit bis zu 64 verschiedene Identifier (ID) möglich, von denen einige für spezielle
Zwecke reserviert sind und in der Tabelle 2.1 aufgeführt werden.
ID Bedeutung
0 - 59 Übertragung von Daten
60 Anfrage zum Slave vom Master
61 Antwort des Slaves zum Master
62 reserviert für herstellerspezifische Kommunikation
63 reserviert für zukünftige Entwicklungen
Tab. 2.1: Aufteilung der Identifier
Die Berechnung der Paritätsbits P0 und P1 basiert auf der Exklusiv-Oder-Ver-
knüpfung der ID-Bits. Die beiden Paritätsbits ergeben sich wie folgt:
P 0 = ID0 ⊗ ID1 ⊗ ID2 ⊗ ID4
P 1 = ¬(ID1 ⊗ ID3 ⊗ ID4 ⊗ ID5)
Data Bytes
Die Response kann als Antwort auf einen Header verstanden werden und wird
von einem über den ID angesprochenen Slave-Task gesendet. Die Response enthält
Müller, Sommer, Stegemann 12LIN-BUS 2.4 Protocol Specification
zwischen ein bis acht Bytes, die jeweils mit einem Start- und einem Stopp-Bit
eingerahmt werden (Siehe Abb. 2.8). Die Anzahl der Datenbytes bei den ID ist
Start Stop
ID0 ID1 ID2 ID3 ID4 ID5 P0 P1
bit bit
Abb. 2.8: Aufbau eines Datenbytes (Quelle[LIN06], S. 29)
jedem Teilnehmer bekannt. Bei der Übertragung eines Words wird das Low-Byte
zu erst übermittelt (little-endian-Übertragung)(Siehe Abb. 2.9).
Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8
Abb. 2.9: Reihenfolge der Datenbytes (Quelle[LIN06], S. 30)
Checksumme
Die Datenbytes werden mit Hilfe einer Checksumme gesichert. Dabei wird zwischen
zwei Checksummentypen unterschieden. Zum Einen die Classic Checksum, bei de-
nen nur die Datenbytes in die Checksummenberechnung verwendet werden und
zum Anderen die Enhanced Checksum, bei der neben den Datenbytes auch der PID
berücksichtigt wird.
Für die Checksummenberechnung wird die invertierte Modulo-256-Summe einge-
setzt, das heißt der Übertrag der 8-Bit-Addierung wird zum LSB des Zwischenergeb-
nisses hinzuaddiert. Die Gesamtsumme wird anschließend invertiert. Das nachfol-
gende Beispiel in Tabelle 2.2 soll dies verdeutlichen. Als Bytes wurden 0x4A, 0x55,
0x93 und 0xE5 gewählt.
Vorgang hex Carry D7 D6 D5 D4 D3 D2 D1 D0
Sender:
0x4A 0x4A 0 1 0 0 1 0 1 0
+0x55 = 0x9F 0 1 0 0 1 1 1 1 1
(Übertrag addieren) 0x9F 1 0 0 1 1 1 1 1
+0x93 = 0x132 1 0 0 1 1 0 0 1 0
Übertrag addieren 0x33 0 0 1 1 0 0 1 1
+0xE5 = 0x118 1 0 0 0 1 1 0 0 0
Übertrag addieren 0x19 0 0 0 1 1 0 0 1
invertieren 0xE6 1 1 1 0 0 1 1 0
Empfänger:
0x19+0xE6 = 0xFF 1 1 1 1 1 1 1 1
Tab. 2.2: Beispiel der Checksummenberechnung (Vgl. [LIN06], S. 52)
Müller, Sommer, Stegemann 13LIN-BUS 2.4 Protocol Specification Um zu überprüfen, ob die Übertragung fehlerfrei war, addiert der Empfänger die empfangenen Datenbytes und ggf. den PID und addiert das Ergebnis zu der empfangenen Checksumme. Wenn das Ergebnis nicht 0xFF ist, trat während der Übertragung ein Fehler auf. 2.4.2 Zeitsteuerung Eine der wichtigsten Eigenschaften des LIN-Busses ist es, dass die Übertragung der Nachrichten im Zeitschlitz-verfahren (Time-Slot-Verfahren) erfolgt. Das heißt, jeder Frame hat eine festgelegte Zeit zur Verfügung in der er übersendet werden muss. Dadurch wird das System deterministisch. Der Master-Task hat dazu eine sogenannte Time-Schedule-Tabelle, die er zyklisch abarbeitet. Diese Time-Schedule- Tabelle ist Teil des LIN Description File (LDF)s und wird während der Entwicklung des LIN-Netzwerks festgelegt. Sie enthält, die ID und deren Reihenfolge, sowie die Länge der Datenbytes, aus der sich die Länge der Time-Slots ergibt. In der Regel hat der Master-Task mehrere Time-Schedule-Tabelle zwischen denen er im Betrieb wechseln kann. Ein Beispiel einer einfachen Anwendung einer Time-Schedule-Tabelle mit Time- Slots zeigt die Abbildung 2.10 im nachfolgenden Abschnitt. 2.4.3 Frametypen Nachfolgend werden die verschiedenen Frametypen vorgestellt. Dabei muss ein LIN- Knoten nicht alle Typen unterstützen, sondern nur die die für die Anwendung not- wendig sind. Unconditional Frame Der Unconditional Frame ist der Standard Frame in einem LIN-Netzwerk. Bei einem ID antwortet immer nur ein Slave-Task auf den vom Master-Task gesendeten ID. Dabei sind Kommunikationen zwischen Master und Slave, Slave und Master und Slave zu Slave möglich, aber wie bereits beschrieben, wird jeder Frame vom Master initiiert. Für Unconditional Frames, sowie die davon abgeleiteten Sporadic Frames und Event Triggered Frames, sind die ID 0 - 59 reserviert. Anhand der Abbildung 2.10 wird das zyklische Abarbeiten einer Time-Schedule- Tabelle mit Unconditional Frames verdeutlicht. Müller, Sommer, Stegemann 14
LIN-BUS 2.4 Protocol Specification
Abb. 2.10: Prinzip des Unconditional Frames (Quelle:[GRZ05], bearbeitet, S. 98)
Sporadic Frame
Das Grundprinzip beim Sporadic Frame ist in einer sonst festen Time-Schedule-
Tabelle einen Platzhalter für verschiedene Frames zu schaffen. Innerhalb eines Time-
Slots kann so zwischen verschiedenen IDs gewechselt werden. Dabei muss darauf
geachtet werden, dass die Länge und damit die Anzahl an Datenbytes in den Time-
Slots fest ist. Der Master kann diesen Time-Slot aber auch leer lassen. Ein Sporadic
Frame schafft somit mehr Dynamik innerhalb einer festen Time-Schedule-Tabelle,
die aber insgesamt vorhersagbar bleibt. Die Abbildung 2.11 zeigt ein mögliches
Beispiel. Im Time-Slot drei kann der Master entweder den Unconditional Frame
„Gas Tank Gauge“ oder „Outside Temperature“ senden. Darüber hinaus kann der
Time-Slot auch leer gelassen werden.
Abb. 2.11: Prinzip des Sporadic Frames (Quelle:[GRZ05], S. 98)
Event Triggered Frame
Eine weitere Möglichkeit das Zeitverhalten zu verbessern ist der Event Triggered
Frame. Mit einem ID werden mehrere Slaves-Tasks zusammen angesprochen. Es
Müller, Sommer, Stegemann 15LIN-BUS 2.4 Protocol Specification können darauf alle angesprochenen Slave-Task reagieren, indem sie ihre Response aussenden. Damit der Master weiß, von wem die Antwort kam, sendet jeder von ihnen im ersten Datenbyte den ID seines dazugehörigen Unconditional Frames. Alle angesprochene Slaves müssen für die Response die gleiche Länge und den gleichen Checksummentyp verwenden. Da auch mehrere Slave-Task gleichzeitig antworten können, muss der Master diese Kollision über die Checksumme erkennen. Er muss dann alle ID der Unconditio- nal Frames nacheinander abfragen, die mit dem ID des Event Triggered Frames zusammengefassten wurden. Es soll durch den Event Triggered Frame verhindert werden, dass bei seltenen Ereignissen zu viel Bandbreite notwendig ist bzw. dass nicht schnell genug reagiert werden kann, wenn die Ereignisse selten abgefragt werden.1 Ein Beispiel ist das Abfragen von Schaltern, die alle den gleichen Zweck haben, wie beispielsweise das Fenster-Heben. Sobald ein Schalter gedrückt wird, antwortet dieser mit seiner Re- sponse, andernfalls nicht. Dieses Ereignis ist relativ selten, so dass es hier sinnvoll ist nicht alle nacheinander abzufragen, sondern die Schalter gemeinsam abzufragen. Diagnostic Frames Mit den Diagnostic Frames wird die Konfiguration und Diagnose der Slaves durch- geführt. Für die Diagnostic Frames sind die ID 60 und 61 reserviert. Mit dem ID 60 sendet der Master ein Requenst zum Slave und mit dem ID 61 wird die Response des Slaves abgefragt. Es sind die einzigen Nachrichten, die der Slave bestätigt. Da dies in den Standardnachrichten nicht vorgesehen ist, wird ein weiteres Protokoll in die Datenbytes integriert. Dieses aufgesetzte Protokoll wird im Abschnitt 2.5 erläutert. User-defined Frames Der ID 62 ist reserviert für herstellerspezifische Kommunikation und kundenspezi- fische Erweiterungen. Bei diesen User-defined Frames gibt es keine definierte Fra- melänge. Die LIN-Knoten müssen also auch mit mehr als acht Datenbytes rechnen. Reserved Frames Der ID 63 ist reserviert für zukünftige Erweiterung des Protokolls. Wie bei den User-defined Frames muss ein LIN-Knoten mit mehr als acht Datenbytes umgehen können. 1 Vgl. [GRZ05], S. 96 Müller, Sommer, Stegemann 16
LIN-BUS 2.4 Protocol Specification
2.4.4 Network Management
Das Network Management ist beim LIN-Bus für einen Slave einfach ausgelegt. Es
gibt nur die folgenden vier Zustände:
• Power-Off
• Initializing
• Operational (Normaler Betriebszustand)
• Sleep-Mode
Abbildung 2.12 verdeutlicht den Zusammenhang der Zustände, die in den anschlie-
ßenden Abschnitten beschrieben werden.
Power on
Initializing
Initialisierung beendet
Wake-up Befehl [< 100 ms]
Got-to-Sleep-Befehl
oder
Bus 4 - 10 s inaktiv
Bus Sleep Mode Operational
Abb. 2.12: Zustandsdiagramm eines Slave-Knotens (nach: [LIN06], S. 44)
Initializing
Während der Initialisierung werden alle für die LIN-Kommunikation notwendigen
Komponenten eingerichtet. Dieser Zustand wird nach dem Einschalten und nach
dem Wake-Up-Befehl erreicht, wobei die Initialisierung jeweils verschieden sein
kann. Im Anschluss wechselt der Slave in den normalen Betriebszustand.
Alle weiteren Ergänzungen wie Fehlerbehandlung und Konfiguration der Slaves
sind Aufgabe der Anwendung und nicht festgelegt.
Operational
Im normale Betriebszustand sendet und empfängt der Slave die LIN-Frames. Er
wechselt in den Sleep-Modus, wenn er den Go-to-Sleep-Befehl vom Master erhält
oder der Bus für 4 bis 10 s inaktiv ist.
Müller, Sommer, Stegemann 17LIN-BUS 2.4 Protocol Specification
Sleep-Mode
Im Sleep-Mode ist der Bus auf High, da kein Teilnehmer sendet. Es ist jedoch der
Anwendung überlassen, ob der LIN-Knoten auch in einen energiesparenden Modus
wechselt. Jeder LIN-Knoten wechselt vom Sleep-Modus zur Initialisierung, wenn er
den Wake-Up-Befehl erhält.
Go-to-Sleep-Befehl
Der Go-to-Sleep-Befehl kann nur vom Master ausgesendet werden, in dem er einen
Frame mit dem ID 60 (Master-Request) und acht Datenbytes sendet. Das erste
Datenbyte ist dabei 0x00 und die restlichen sieben sind 0xFF.
data1 data2 data3 data4 data5 data6 data7 data8
0 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
Tab. 2.3: Go-to-Sleep-Befehl
Wake-Up-Befehl
Den Wake-Up-Befehl kann jeder Slave-Task senden, in dem er den Bus für mindes-
tens 250 µs auf Low zieht. Wenn der Master-Task daraufhin nicht innerhalb von
150 ms bis 250 ms in den normalen Betriebszustand wechselt und mit dem Senden
eines ID beginnt, wiederholt der Slave-Task den Wake-Up-Befehl (Siehe Abb. 2.13).
250 µs - 5 ms 150 ms - 250 ms 250 µs - 5 ms 150 ms - 250 ms 250 µs - 5 ms
Abb. 2.13: Ein Block von Wake-Up-Bfehlen (Quelle: [LIN06], S. 45)
2.4.5 Fehlererkennung
Beim LIN-Knoten können sechs verschiedene Fehlerarten erkannt werden:1
• Bit-Fehler
• Checksummenfehler
1 Nach: [GRZ05], S. 99
Müller, Sommer, Stegemann 18LIN-BUS 2.4 Protocol Specification • Identifier-Parity-Fehler • Slave-Not-Responding-Fehler • Inconsistent-Synch-Field-Fehler • Physical-Bus-Fehler Bit-Fehler Ein Bit-Fehler kann nur durch den Sender erkannt werden, indem er beim Senden den Bus überprüft. Wenn er nicht das zurückliest, was er gesendet hat, ist ein Bit- Fehler aufgetreten. Das Senden muss dann spätestens nach einem kompletten Byte abgebrochen werden. Checksummenfehler Ein Checksummenfehler kann jeder Slave-Task ermitteln, indem er die empfangene mit der selbst berechneten Checksumme vergleicht. Identifier-Parity-Fehler Einen Identifier-Parity-Fehler kann jeder Slave-Task ermitteln, in dem er die emp- fangen Parität mit der selbst berechneten Parität vergleicht. Slave-Not-Responding-Fehler Einen Slave-Not-Responding-Fehler kann nur ein Slave-Task erkennen, der auf eine Nachricht eines anderen Slave-Task wartet und wenn dieser nicht innerhalb der festgesetzten Zeit diese sendet. In der Regel ist das der Slave-Task im Master, aber der Fehler kann auch bei einer Slave-zu-Slave-Kommunikation von einem Slave erkannt werden. Inconsistent-Synch-Field-Fehler Ein Inconsistent-Synch-Field-Fehler tritt auf, wenn sich ein Slave nicht auf den Mastertakt synchronisieren kann. Eine Ursache dafür kann sein, dass die Flanken des Sync Fields außerhalb der Toleranzen liegen. Physical-Bus-Fehler Ein Physical-Bus-Fehler kann durch Kurzschluss zur Masse oder zur Versorgungs- spannung verursacht werden, sowie durch parasitäre Impedanzen. Der Buspegel ist dadurch dauerhaft auf einem Low- bzw. High-Pegel. Müller, Sommer, Stegemann 19
LIN-BUS 2.5 Transport Layer
2.4.6 Fehlerbehandlung
Die Fehlerbehandlung ist nicht Teil der Spezifikation, um diese einfach zu halten. Es
ist Aufgabe der Anwendung auf die Fehler zu reagieren. Dabei ist hervorzuheben,
dass eine direkte Mitteilung von Kommunikationsstörungen vom Empfänger an den
Sender nicht möglich ist. Jedoch muss jeder Slave innerhalb einer Time-Schedule-
Tabelle auf Fehler abgefragt werden.
2.5 Transport Layer
2.5.1 Allgemein
Der Transport Layer wird für die Diagnose und Konfiguration der Slaves benötigt.
Er ermöglicht auch, dass Daten, die größer als acht Byte sind, übertragen werden
können.
2.5.2 PDU Structure
Die Einheiten, die im Transport Layer übertragen werden, sind die sogenannten
Packet Data Unit (PDU). Die Abbildung 2.14 zeigt den Aufbau von den PDUs,
die wie bereits beschrieben innerhalb der acht Datenbytes gesendet werden. Dabei
NAD PCI SID D1 D2 D3 D4 D5 PCI-type = SF
Request
NAD PCI LEN SID D1 D2 D3 D4 PCI-type = FF
NAD PCI D1 D2 D3 D4 D5 D6 PCI-type = CF
NAD PCI RSID D1 D2 D3 D4 D5 PCI-type = SF
Response
NAD PCI LEN RSID D1 D2 D3 D4 PCI-type = FF
Abb. 2.14: Zusammensätzung eines PDU-Structur-Frames (Quelle: [LIN06], S. 57)
unterscheidet man zunächst drei Arten, die als Request vom Master zum Slave mit
dem ID 60 gesendet werden und drei Arten die vom Slave zum Master mit dem ID
61 als Response gesendet werden.
Der erste Typ ist der Single Frame (SF) bei dem die Nachricht in einen einzigen
Frame passt. Sollen längere Nachrichten übertragen werden, wird für den ersten
Teil der Nachricht der First Frame (FF) und für die weiteren Teile werden die
Consecutive Frames (CF)s verwendet. Die einzelnen Bytes der PDU-Struktur werden
im Nachfolgenden beschrieben.
Müller, Sommer, Stegemann 20LIN-BUS 2.5 Transport Layer
NAD
Die Node Address for Diagnose (NAD) ist eine vom Hersteller vergebene Knote-
nadresse, die aber während der Startphase verändert werden kann. Für weitere
Vertiefungen wird an dieser Stelle auf [LIN06] verwiesen.
PCI
Die Protocol Control Information (PCI) kennzeichnet, um welchen Protokolltyp es
sich handelt. Die unteren vier Bytes enthalten einen Framecounter oder die Anzahl
an Bytes plus SID/RSID-Byte, die übertragen werden.
Type PCI type Additional information
B7 B6 B5 B4 B3 B2 B1 B0
SF 0 0 0 0 Length
FF 0 0 0 1 Length/256
CF 0 0 1 0 Frame counter
Abb. 2.15: Aufbau des PCI-Bytes (Quelle: [LIN06], S. 57)
LEN
Das Längenbyte LEN wird nur beim First Frame (FF) verwendet. Da im LEN-Byte
die unteren acht Bits und ihm PCI-Byte die vier oberen Bits übertragen werden,
kann eine Nachricht maximal 4095 (0xFFF) Bytes lang sein.
SID/RSID
Der Service Identifier (SID) kennzeichnet den Nachrichteninhalt vom Master zum
Slave (Request), der vom Slave-Knoten ausgeführt werden soll. Der Response Ser-
vice Identifier (RSID) kennzeichnet den Nachrichteninhalt vom Slave zum Master
(Response).
D1 bis D6
Die bis zu sechs Datenbytes sind abhängig vom SID bzw. vom RSID im LIN-Knoten
zu interpretieren und zu verarbeiten.
Müller, Sommer, Stegemann 21LIN-BUS 2.6 Konfiguration und Diagnose
2.6 Konfiguration und Diagnose
2.6.1 Node Configuration and Identification Specification
Um innerhalb eines LIN-Clusters Konflikte zwischen einzelnen Slave-Knoten zu ver-
hindern, wird in der Node Configuration and Identification Specification festgelegt
wie ein Slave-Knoten ausgelegt werden muss und wie er identifiziert werden kann.
Jeder Knoten hat eine LIN Product Identification, eine initiale NAD und optional
eine Seriennummer in seinem Speicher (siehe (Abb. 2.16)) hinterlegt, dadurch kann
innerhalb eines Clusters jeder Slave-Knoten identifiziert werden. Für die einzelnen
Nachrichten jedes Slave-Knotens kann ein Identifier definiert werden. So dass zum
Ansprechen mehrerer Slaves Multicast-Identifier eingerichtet werden können sowie
auch jede einzelne Funktion jedes Slaves seperat über Identifier ansprechbar ist.
ROM ROM or NVRAM
Serial number
NAD PIDs
Supplier ID Function ID Variant
ld_set_configuration
e.g. pin configuration VRAM
Initial NAD Instance generation
NAD PIDs
Configuration from
master node, over the bus
Abb. 2.16: Speichermodel eines Slave-Knotens (Quelle[LIN06], S. 66)
Die LIN Product Identification besteht aus 5 Bytes:
• 2 Bytes Supplier ID: Dem Hersteller vom LIN-Konsortium zugewiesen
• 2 Bytes Function ID: Vom Supplier für das Produkt zugewiesen
• 1 Byte Variant ID: Diese wird geändert wenn das Produkt ohne Änderung
der Funktion verändert wird.
Die optionale Seriennummer besteht aus 4 Bytes und wird zum Unterscheiden von
mehreren gleichen Knoten innerhalb eines Clusters benötigt.
Für jeder Knoten ist im Node Capability File eine initiale NAD-Liste hinterlegt.
Die initiale NAD wird bei der Instanz-Generierung gesetzt. Bei Knoten die keine
Instanzgenerierung haben, hat die Liste nur einen Eintrag. Wenn mehrere gleiche
Müller, Sommer, Stegemann 22LIN-BUS 2.6 Konfiguration und Diagnose
Knoten (z. B. intelligente Sensoren gleichen Typs) innerhalb eines Clusters vorhan-
den sind, wird durch Konfigurierung ein Eintrag der NAD-Liste (1-125) als NAD
zugewiesen.
Die beschriebenen Dienste werden durch den Master-Knoten unter Verwendung
des Transportlayer genutzt. Dafür wird die single frame PDU-Struktur genutzt. Zum
Identifizieren und Konfigurieren der Slave-Knoten sind verschiedene Service Iden-
tifier (SID) spezifiziert z.B. Assign NAD, Read by Identifier, Save Configuration
usw.
2.6.2 Diagnostic Specification
Die Diagnose eines Bussystems ist ein wichtiges Hilfsmittel zur manuellen und auto-
matischen Lokalisierung von Fehlern innerhalb der Bordelektronik eines Fahrzeugs.
In der Diagnostic Specification sind Methoden zum Übertragen von Diagnoseda-
ten zwischen Master-Knoten bzw. Tester und Slave-Knoten unter Verwendung des
Transportlayer spezifiziert. Die Diagnosedienste werden beim LIN-Bus immer von
einem externen oder internen (Steuergerät welches den Master-Knoten enthält)
Test-Tool ausgelöst. Dies bedeutet, dass die Verwendung der Diagnosefunktiona-
lität nicht spezifiziert sind und in der Anwendungsschicht (meist in einem überge-
ordneten Bussystem z. B. CAN) realisiert werden müssen.
Prinzipiell existieren zwei Möglichkeiten für die Diagnosekommunikation:
1. LIN-Master übertragt eine Anfrage des Testers zum LIN-Slave
2. LIN-Master übertragt eine Antwort eines LIN-Slave zum Tester
Für die Diagnosekommunikation verwendet der Master-Knoten die NAD als Quel-
ladresse für die angeforderte Information. Jedem Slave-Knoten wird eine von drei
möglichen Diagnoseklassen mit unterschiedlich komplexer Diagnosefunktionalität
zugewiesen:
Class I Einfache Geräte ohne oder mit nur geringer Diagnosefunktionalität (z. B.
intelligente Sensoren). Es wird nur die Knoten-Konfiguration unterstützt. Die
Knotenidentifikation ist auf read by identifier begrenzt. Der Master benötigt
nur die Unterstützung für minimale geforderte LIN Configuration
Class II Ist gleich Class I, unterstützt jedoch auch Knotenidentifikation. Hierfür
benötigt der Master die Unterstützung des kompletten Diagnoseprotokolls.
Class III Slave-Knoten die wesentlich mehr als die normale Sensor/Aktor-Funktio-
nalität haben. Dies liegt vor wenn z. B. Sensordaten ausgewertet und darauf-
hin Aktoren angesteuert werden. Der Slave-Knoten benötigt einen internen
Fehlerspeicher und kann optional auch Firmwar-Update-Funktionalität haben
Müller, Sommer, Stegemann 23LIN-BUS 2.7 Work-Flow-Konzept
(Bootloader) und sollten alle Konfigurations- und Diagnosedienste unterstüt-
zen. Der Master-Knoten benötigt die Unterstützung des kompletten Diagnose
Protokolls.
Weiterhin wird das Transport-Protokoll-Handling (Scheduling der Diagnosekom-
munikation) für Master- und Slave-Knoten definiert.
2.7 Work-Flow-Konzept
Eine Besonderheit gegenüber anderen Bussystemen für automobile Anwendungen
ist die Spezifizierung eines Work-Flow-Konzeptes und damit die Beschreibung des
Designprozessablaufes durch das LIN-Konsortium. Dadurch sollte das Entstehen von
herstellerspeziefischen unterschiedlichen Einzellösungen verhindert werden.
Das Work-Flow-Konzept wird durch die folgenden drei Teil-Spezifikation be-
schrieben.
2.7.1 Node Capability Language Specification
Standardisiert eine Syntax zum Beschreiben der Eigenschaften von Slave-Knoten
auf Basis der Node Configuration and Identification Specification. Sie stellt die
Grundlage zum automatischen Erzeugen eines LDF durch ein Design-Tool dar.
2.7.2 Configuration Language Specification
Beschreibt eine Sprache zum Erstellen des LDF. Das LDF enthält die Konfiguration
des kompletten Clusters mit Informationen über die Knoten, die zu Transportie-
renden Signale (Daten) sowie die Anzahl der Frames innerhalb von Messages und
den Aufbau der Scheduling-Tabellen. Die Spezifikation bietet eine Schnittstelle zwi-
schen Entwickler und dem Zulieferer einzelner Knoten und stellt die Grundlage für
die Eingabe in Entwicklungs- und Analyse-Tools dar.
2.7.3 Application Programm Interface Specification
Definiert verschiedene Softwareschnittstellen zum vereinfachten Erstellen von An-
wendungsprogrammen für LIN-Teilnehmer ohne sich mit den LIN-spezifischen De-
tails beschäftigen zu müssen. Dazu wird ein Satz von C-Funktionen als Schnittstelle
definiert. Das Application Programm Interface ist unterteilt in 3 Teile.
LIN core API Initialisierung, Steuerung und Wechselwirkung zwischen Anwendung
und LIN-Core
Müller, Sommer, Stegemann 24LIN-BUS 2.7 Work-Flow-Konzept
LIN node configuration and identification API Stellt Funkionen zum Konfigurieren
und Identifizieren der Slave-Knoten durch den Master bereit
LIN transport layer API Stellt Funktionen für die Implementierung der Diagno-
sefunktionalität bereit und steuert die Kommunikation mit einem externen
Diagnose-Tool (Tester)
2.7.4 LIN-Cluster-Design-Prozess
Der spezifizierte Design-Prozess ist in Abb. 2.17 dargestellt und läuft wie folgt ab.
In die Node Capability Files Node Configuration File (NCF) werden alle wichtigen
Informationen über die einzelnen Knoten des Clusters eingetragen.
Abb. 2.17: LIN-Cluster-Design-Prozess (Quelle[LIN06], S. 162)
Diese sind die Konfiguration des Knotens, die
Beziehungen zu anderen Knoten und der Logi-
sche Signalverlauf. Das Design Tool erstellt aus
den NCF ein LDF und aus diesem generiert das
Node Configuration Tool automatisch die benö-
tigten LIN-Funktionen für die einzelnen Knoten.
Diesen Sourcecode nennt man LIN node applica-
tion code.
Das LDF wird zusätzlich noch zum Debuggen
und Analysieren des Clusters durch einen Bus-
Abb. 2.18: Verarbeitung des
Analyzer und -Emulator genutzt (z.B. Timing
Programm- und LIN-Codes zum Analysis).
fertigen Maschinencode Der LIN node application code wird zusam-
men mit dem Anwendungscode compiled und
gelinkt. Der dabei entstandene Maschinencode wird im entsprechenden Format in
den Programmspeicher der einzelnen Busteilnehmer geschrieben (siehe Abb. 2.18).
Müller, Sommer, Stegemann 25LIN-BUS 3 Zusammenfassung und Ausblick 3 Zusammenfassung und Ausblick 3.1 LIN-Bus in der Zusammenfassung Der LIN-Bus wurde für Sicherheitsunkritische Anwendungen konzipiert und dient als Ergänzung zum CAN-Bus (Subbussystem). Da keine Spezial-Hardware notwendig ist, zeichnet sich der LIN-Bus durch geringen Kosten und Implementierungsaufwand aus. Das LIN-Protokoll ist als offener Standard definiert wodurch keine Lizenzge- bühren anfallen. Die wichtigsten Eigenschaften der LIN-Technologie werden im Folgenden kurz zusammengefasst. Beim LIN erfolgt die Buszugriffssteuerung nach dem Master/Slave-Prinzip. Jede Kommunikation eines Slave-Knotens wird von einem Master-Knoten initiiert. Das hat den Vorteil, dass die Slaves kostengünstig realisiert werden können. Die Mas- terfunktionalität übernimmt die Steuereinrichtung, welches meist ein Gateway zum CAN-Bus ist. Als Übertragungsmedium wird eine einfache ungeschirmte Eindrahtverbindung eingesetzt. Elektrische Parameter wie Transceiverkapazität und Spannungspegel werden hingegen vorgeschrieben. Durch diese Kenngrößen wird die Anzahl der Kno- ten in einem Cluster auf 16 begrenzt. Die Übertragungsrate darf zwischen 1 kBit/s und 20 kBits/s liegen. Das LIN-Protokoll ist byteorientiert und die Datenübertragung erfolgt asynchron. Eine einfache Implementierung des Protokolls auf der in den meisten Mikrocon- trollern existierenden seriellen Schnittstelle (UART) ist möglich. In einer Nachricht können 1 bis 8 Datenbyte übertragen werden. Da der LIN-Standard keine Knoten-Adressen, sondern Nachrichten-Identifier (ID), ist neben Punkt-zu-Punkt- auch Broadcast- und Multicastkommunikation möglich. Die Datenübertragung über LIN erfolgt zeitgesteuert. Im Master sind zu diesem Zweck Time-Schedule-Tabellen hinterlegt. In diesen wird definiert, in welchem Zeit- schlitz (Time-Slot) welches Datenpaket mit welchem ID übertragen werden muss. Dadurch ist das Systemverhalten deterministisch. Für die Diagnose und Konfiguration bietet der LIN-Bus die Möglichkeit ein wei- teres Protokoll auf die Datenbytes aufzusetzen, so dass Nachrichten mit bis zu 4095 Bytes erlaubt. Darüber hinaus ist es damit möglich Nachrichten vom Empfänger zu bestätigen. Müller, Sommer, Stegemann 26
LIN-BUS 3.2 Zukünftige Entwicklung 3.2 Zukünftige Entwicklung Für einfache Komfortanwendungen mit geringen Datenmengen und ohne Sicher- heitsrelevanz ist LIN wesentlich günstiger als CAN (vgl. hierzu Abb. 3.1). Hinzu kommt, dass durch Spezifizierung bis hinein in den Design-Prozess der Einsatz von Off-The-Shelf-Knoten möglich und praktikabel ist und dadurch auch die Vergabe von Entwicklungsarbeit an Zulieferer deutlich vereinfacht wird. Dies war auch einer der Gründe für eine sehr schnelle Markteinführung. Weiterhin ist für komplexere Anwendungen mit hohen Datenmengen und Si- cherheitsrelevanz der neue Standard Flexray besser geeignet als CAN. Durch die Vielfalt von CAN-Ablegern die in den letzten Jahren entstanden, entwickelte sich in der Automobilindustrie der Bedarf nach einem einheitlichen Standard für einfache mechatronische Anwendungen. Aus diesen Gründen wird erwartet, des sich LIN als Subbus in Zukunft durchsetzt und in diesem Segment Marktanteile vom CAN-Bus abgreift. Doch auch im Zusam- menspiel mit Flexray und MOST wird der etablierte CAN-Bus in naher Zukunft nicht vollständig vom Markt verdrängt werden, da er ein erprobtes System mit sehr vielen Anwendungen darstellt und in ihn sehr viel Geld investiert worden ist. Abb. 3.1: Vergleich der Kosten pro Netzwerkknoten von verschiedenen Bussyste- men aus dem Automobilbereich (Quelle: [BAD06]) Müller, Sommer, Stegemann 27
LIN-BUS Literaturverzeichnis Literaturverzeichnis [BAD06] Badstübner, J.: Ende einer Dienstzeit?. In: Automilindustrie : (2006-03), S. 68f [GRZ05] Grzemba, A.; von der Wense, H.: LIN-Bus - Systeme Protokolle Tests von LIN-Systemen Tools Hardware Applikation. Poing : Franzis Verlag, 2005 [LIN06] LIN Consortium: LIN Specification Package - Revision 2.1, 2006 [VEC09] Vector Informatik GmbH: Einführung in LIN. URL http://www.vector-elearning.com/vl_einfuehrunglin_de„376493.html - Aktualisierungsdatum: 05.11.2009 Müller, Sommer, Stegemann 28
Sie können auch lesen
