Einführung zum Bussystem Local Interconnect Network (LIN)

Überblick

LIN (Local Interconnect Network) ist ein kostengünstiger Embedded-Netzwerkstandard für die Verbindung intelligenter Geräte. Besonders beliebt ist LIN derzeit in der Automobilindustrie.

Inhaltsverzeichnis

  1. Übersicht über LIN
  2. LIN Frame Format
  3. Timing des LIN-Busses
  4. Topologie und Verhalten von LIN
  5. Fehlererkennung und Schadensbegrenzung bei LIN
  6. Sleep- und Wakeup-Modus bei LIN
  7. Erweiterte Frame-Arten
  8. Empfohlene PC-LIN-Schnittstellen
  9. Weitere Informationen über LIN

Übersicht über LIN

LIN (Local Interconnect Network) wurde entwickelt, um einen Standard für einfache und kostengünstige gemultiplexte Kommunikation in Automobilnetzwerken bereitzustellen. Während CAN die Nachfrage nach hoher Bandbreite und anspruchsvollen Netzwerken für die Fehlerbehebung abdeckte, wurden die Hardware- und Softwarekosten für die CAN-Implementierung für Geräte mit weniger Leistung, wie etwa Fensterheber oder Sitzversteller, zu hoch. LIN ermöglicht kosteneffiziente Kommunikation in Anwendungen, für die die Bandbreite und Vielseitigkeit von CAN nicht benötigt werden. So kann LIN mit dem heute standardmäßig in den meisten kostengünstigen 8-bit-Mikrocontrollern integrierten seriellen UART (Universal Asynchronous Receiver Transmitter) relativ preiswert implementiert werden.

Moderne Automobilnetzwerke bedienen sich einer Kombination aus LIN für kostengünstige Anwendungen v. a. in der Karosserieelektronik, CAN für Antriebselektronik und Karosseriekommunikation und dem relativ neuen FlexRay-Bus für die synchronisierte Hochgeschwindigkeits-Datenkommunikation in anspruchsvollen Systemen wie der aktiven Aufhängung.

Der LIN-Bus nutzt eine Master/Slave-Architektur, bestehend aus einem LIN-Master und einem oder mehreren LIN-Slaves.


Frame einer LIN-Nachricht

Der Nachrichten-Header besteht aus einer Unterbrechung, um den Beginn des Frames zu identifizieren und einem Synchronisationsfeld, das der Slave-Knoten für die Taktsynchronisation nutzt. Der Identifikator (ID) besteht aus einer Nachrichten-ID mit 6 bit und einem Paritätsfeld mit 2 bit. Die ID kennzeichnet eine spezifische Nachrichtenadresse, nicht jedoch das Ziel. Nach Empfang und Interpretation der ID beginnt ein Slave auf die Nachricht zu antworten. Die Antwort besteht aus 1 bis 8 Daten-Bytes und einer 8-bit-Quersumme.

Die Reihenfolge der Nachrichten-Frames wird vom Master gesteuert und in einem Ablaufplan festgelegt. Dieser kann bei Bedarf geändert werden.

Den LIN-Standard gibt es in mehreren Versionen: Die Version 1.3 schloss die Kommunikation auf Byte-Ebene ab. Die Versionen 2.0 und 2.1 ergänzten zusätzliche Nachrichtenspezifikationen und -dienste, sind aber auf Byte-Ebene mit LIN 1.3 kompatibel.

Vergleich der LIN-Versionen 1.3, 2.0 und 2.1

Funktion Unterstützt von NI USB-LIN
LIN 1.3 Ja
LIN 2.0 Ja*

Erweiterte Quersumme

Ja

Standardkonzept für Slave-Knoten

Ja*

NCF-Format

Ja*

Diagnostik und Konfiguration der Slave-Knoten

Ja*

Byte-Arrays

Ja
LIN 2.1 Ja*

Neue Konfigurationsdienste für Slave-Knoten

Ja*

Slave-Diagnostik Klasse I-III

Ja*

Funktionale Adressierung

Ja*

Auflösungstabelle

Ja*


Hinweis: * Diese Funktion wird von der API nicht nativ unterstützt, kann jedoch vom Anwender implementiert werden.

Nach oben

LIN Frame Format

LIN ist ein gepollter Bus mit einem einzigen Master-Gerät und einem oder mehreren Slave-Geräten. Der Master verfügt sowohl über einen Master-Task als auch einen Slave-Task. Jedes Slave-Gerät verfügt nur über einen Slave-Task. Die Kommunikation über LIN wird vollständig durch den Master-Task im Master-Gerät gesteuert. Die zugrundeliegende Übertragungseinheit auf dem LIN-Bus ist der Frame, der dann in einen Header und eine Antwort aufgeteilt wird. Der Header wird immer vom Master-Knoten übertragen und besteht aus drei unterschiedlichen Feldern: der Unterbrechung (Break), dem Synchronisationsfeld (Sync) und dem Identifikatorfeld (ID). Die Antwort wird von einem Slave-Task übertragen (der sich entweder im Master- oder im Slave-Knoten befindet) und besteht aus den Daten und einer Quersumme.

Normalerweise ruft der Master-Task jeden Slave-Task in einer Schleife auf, indem ein Header, der aus einer Break-Sync-ID-Sequenz besteht, übertragen wird. Bevor die LIN-Kommunikation gestartet wird, wird jeder Slave-Task so konfiguriert, dass er entweder Daten auf den Bus schreibt oder als Reaktion auf jede empfangene Header-ID Daten liest. Nach Erhalt des Headers verifiziert jeder Slave-Task die ID-Parität und überprüft dann die ID, um festzulegen, ob Daten ausgegeben oder abgefragt werden müssen. Muss der Slave-Task eine Antwort ausgeben, überträgt er 1 – 8 Daten-Bytes gefolgt von einem Quersummen-Byte, an den Bus. Muss der Slave Daten abfragen, liest er die Daten und das Quersummen-Byte vom Bus und ergreift entsprechende interne Maßnahmen.

Für die Standardkommunikation vom Slave zum Master überträgt der Master den Identifikator ans Netzwerk und nur ein einziger Slave antwortet mit seinen Daten.
Die Kommunikation vom Master zum Slave erfolgt durch einen separaten Slave-Task, der durch den Master-Knoten bereitgestellt wird. Dieser Task erhält alle auf den Bus ausgegebenen Daten und antwortet wie ein unabhängiger Slave-Knoten. Um Daten-Bytes zu übertragen, muss der Master zunächst die Antwort seines internen Slave-Tasks mit den Datenwerten, die übertragen werden sollen, aktualisieren. Der Master gibt dann den passenden Frame-Header aus und der interne Slave-Task überträgt seine Daten an den Bus.


Frame einer LIN-Nachricht

1. Break

Jeder LIN-Frame beginnt mit dem Break, der aus 13 dominanten Bits (nominal), gefolgt von einem Delimiter (Begrenzungszeichen) von einem rezessiven Bit (nominal). Damit werden alle Knoten am Bus über den Beginn eines Frames informiert.

2. Sync

Das Synchronisationsfeld ist das zweite, das vom Master-Task im Header übertragen wird. Sync wird definiert als das hexadezimale Zeichen x55. Das Sync-Feld ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren.

3. ID

Das ID-Feld ist das letzte, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen. LIN stellt insgesamt 64 IDs bereit. Die IDs 0 – 59 werden für signalübertragende (Daten-)Frames benutzt, 60 – 61 zur Übertragung diagnostischer Daten, 62 ist für anwenderdefinierte Erweiterungen reserviert und 63 für künftige Protokolloptimierungen. Die ID wird als ein geschütztes Daten-Byte über den Bus übertragen. Dabei enthalten die ersten 6 Bits die Roh-ID und die letzten zwei Bits die Parität.

 

Geschützte ID (7:6) Geschützte
ID (5:0)
P(1) P(0) ID(5:0)
ID(1) ^ ID(3) ^ ID(4) ^ ID(5) ID(0) ^ ID(1) ^ ID(2) ^ ID(4) 0–63

Methode zur Paritätsberechnung

 

4. Daten-Bytes

Das Feld Data-Bytes wird vom Slave-Task in der Antwort übertragen. Es enthält zwischen 1 und 8 Daten-Bytes.

5. Quersumme

Das Feld Checksum (Quersumme) wird vom Slave-Task in der Antwort übertragen. LIN definiert die Anwendung eines von zwei Quersummenalgorithmen, um den Wert im 8-bit-Quersummenfeld zu berechnen. Die klassische Quersumme ist nur die Summe der Daten-Bytes, während sich die erweiterte Quersumme aus der Summe der Daten-Bytes plus der geschützten ID zusammensetzt.

Die Spezifikation LIN 2.0 definiert den Prozess der Quersummenberechnung als die Addition aller Werte und Subtraktion von 255 jedes Mal, wenn die Summe größer oder gleich 256 ist (anders als modulo-255 oder modulo-256). Bei der Spezifikation LIN 2.0 ist die klassische Quersumme für die Anwendung mit LIN-1.3-Slave-Knoten und die erweiterte Quersumme für LIN-2.0-Slave-Knoten gedacht. Sie spezifiziert außerdem, dass die IDs 60 – 63 immer die klassische Quersumme verwenden. Die NI-LIN-Schnittstelle bietet ein Attribut, mit dem die Quersumme auf klassisch oder erweitert eingestellt werden kann. Standardmäßig ist die klassische eingestellt. Nach der LIN-2.0.-Spezifikation nutzen die IDs 60 – 63 immer die klassische Quersumme, gleichgültig wie das Quersummenattribut eingestellt ist.

Folgendes Diagramm illustriert wie ein Master-Task-Header und eine Slave-Task-Antwort zusammen einen kompletten LIN-Frame ergeben.

Erstellung der LIN-Frames

Nach oben

Timing des LIN-Busses

Da LIN ein gepollter Bus ist, wird der Verarbeitung jedes Frames ein nominaler Zeitslot
wie folgt zugewiesen:

THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Der Verarbeitung jedes Frames wird ein maximaler Zeitslot wie folgt zugewiesen:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

 

Nach oben

Topologie und Verhalten von LIN

Der LIN-Bus verbindet ein einzelnes Master-Gerät (Knoten) und einen oder mehrere Slave-Geräte (Knoten) in einem sogenannten LIN-Cluster. Das Verhalten jedes Knotens wird von dessen jeweiliger Eigenschaftsdatei beschrieben. Dabei handelt es sich um Eingänge zu einem Systemdefinitionswerkzeug, das ein LIN Description File (LDF) erzeugt, welches das Verhalten des gesamten Clusters beschreibt. Das LDF wird von einem Systemgenerator geparst, um das spezifizierte Verhalten in den gewünschten Knoten automatisch zu generieren. Zu diesem Zeitpunkt beginnt der Master-Task im Master-Knoten mit der Übertragung der Header an den Bus und alle Slave-Tasks im Cluster (einschließlich des Slave-Tasks im Master-Knoten) antworten wie im LDF spezifiziert.

Allgemein ausgedrückt wird der LDF genutzt, um das Planungsverhalten des LIN-Clusters zu konfigurieren und festzulegen. So definiert er z. B. die Baudrate, die Reihenfolge und die Zeitverzögerungen bei der Übertragung der Header durch den Master-Task sowie das Verhalten jedes Slave-Tasks als Antwort darauf. Die Frame-API NI-CAN für LIN und LIN-Hardware von NI bieten keine volle native Unterstützung für LDFs, so dass das geplante Verhalten nicht auf die Hardware geladen werden kann. Jedoch steht eine Low-Level-Unterstützung für den Buszugriff (Schreiben der Header und Veröffentlichung oder Abfragen der Antworten) so zur Verfügung, dass der Nutzer das geplante Verhalten auf der Anwendungsebene erstellen kann. Wie bei der Beschreibung für den NI LIN response entry frame type, bietet die NI-LIN-Hardware eine Antwort-Queue für das Ablegen der Antworten der Slave-Tasks. Die Antwort-Queue kann bis zu 64 Antworten enthalten, eine für jede der maximal 64 spezifizierten LIN-IDs. So wird sichergestellt, dass der Slave-Task der LIN-Schnittstelle den Headern innerhalb der durch die LIN-Spezifikation definierten Reaktionszeit antworten kann.

Die NI-CAN Frame API für LIN ist eine robuste Methode für umfassende Low-Level-Interaktion mit dem LIN-Bus. Dadurch steht dem Endanwender die grundlegende Funktionalität zur Verfügung, mit der er komplexe Anwendungen im Bereich der Analyse und Prototypenerstellung von LIN-Netzwerken entwickeln kann. Die NI-CAN Frame API für LIN bietet keine native Unterstützung für die LIN-Diagnostik und -Konfiguration, LIN Description Files oder Plantabellen. Allerdings können diese Tasks mit der NI-CAN Frame API für LIN implementiert werden.

Nach oben

Fehlererkennung und Schadensbegrenzung bei LIN

Die Spezifikation LIN 2.0 gibt an, dass die Fehlerbehandlung der Slave-Tasks ausgeführt werden sollte und die Fehlerüberwachung durch den Master-Task nicht notwendig ist. In dieser Spezifikation müssen mehrere Fehler nicht innerhalb eines LIN-Frames oder mit Fehlerzählern behandelt werden. Wird der erste Fehler in einem Frame gefunden, stoppt der Slave-Task die Verarbeitung des Frames, bis die nächste Break-Sync-Sequenz (im nächsten von Master übertragenen Header) erkannt wird. Wird das Attribut für die Protokollierung von Busfehlern aktiviert, schaltet sich ein Frame für Busfehler in die Lese-Queue ein. Ist das Attribut nicht aktiviert, wird ein Fehler von ncWriteNet oder ncWriteNetMult ausgegeben.

LIN sorgt auch für entsprechende Fehlerberichte im Netzwerk. Die Spezifikation LIN 2.0 definiert ein Statusbit Response_Error, das der Slave in einem der übertragenen Frames an den Master berichten muss. Das Bit wird gesetzt, wenn ein Frame, der von einem Slave-Knoten empfangen oder übertragen wird, im Antwortfeld einen Fehler enthält. Das Bit wird zurückgesetzt, nachdem es in einer der vom Slave veröffentlichten Antworten übertragen wurde. Die NI-CAN Frame API für LIN bietet keine native Unterstützung des Statusbit Response_Error, doch sie bietet dem Endanwender eine einfache Methode, diese Funktionalität auf Anwendungsebene zu implementieren. Dazu wird das Attribut für die Protokollierung der Busfehler auf eins gesetzt, um die Protokollierung der Frames mit Busfehlern in der Lese-Queue zu aktivieren. Die Anwendung erkennt dann, wenn ein Frame mit einem Busfehler gelesen wird, wobei der Fehlercode auf einen Fehler in der Antwort hinweist. Liegt diese Bedingung vor, kann die Anwendung ein Statusbit Response_Error in einer lokalen Variable setzen. Die Anwendung kann dann den NI LIN response entry frame type nutzen, um die Queue der Slave-Antwort mit Daten zu aktualisieren, die das Statusbit Response_Error enthalten, und das Bit dann in der lokalen Variable zurückzusetzen.

Nach oben

Sleep- und Wakeup-Modus bei LIN

LIN bietet einen Mechanismus, damit Geräte in einen Ruhezustand versetzt werden und damit Energie sparen. Bei der Spezifikation LIN 2.0 können alle Slaves in einen Sleep-Modus versetzt werden, indem der Master einen diagnostischen Master-Frame (ID=60) mit dem ersten Daten-Byte gleich Null sendet. Dieser spezielle Frame bildet den Befehl für den Eintritt in den Ruhezustand. Slaves werden auch automatisch in den Sleep-Modus versetzt, wenn die LIN-Kommunikation länger als 4 Sekunden inaktiv ist. Die NI-CAN Frame API für LIN ist hierbei sehr flexibel, denn sie ermöglicht es Anwendern, die LIN-Schnittstelle auf Anwendungsebene wie gewünscht in den Ruhezustand zu versetzen. Wird ein vollständiger Frame mit der Nachricht zur Anfrage für den Sleep-Modus oder ein Frame, der eine länger als 4 Sekunden dauernde Businaktivität nachweist, erhalten, kann der Anwender die LIN-Schnittstelle durch das Einstellen des Attributs für den Sleep-Modus auf TRUE in den Ruhezustand versetzen.

LIN verfügt auch über einen Wakeup-Modus für Geräte am Bus. Der Wakeup-Modus kann von jedem Knoten, Slave oder Master, initiiert werden. Nach der Spezifikation LIN 2.0 wird der Wakeup-Modus initiiert, indem der Bus für 250 Mikrosekunden bis zu 5 Millisekunden dominant gemacht wird. Jeder Slave sollte die Wakeup-Anfrage erkennen und bereit sein, Header innerhalb von 100 Millisekunden zu verarbeiten. Auch der Master sollte die Wakeup-Anfrage erkennen und Header senden, sobald die Slave-Knoten bereit sind (innerhalb von 100 bis 150 Millisekunden nach dem Empfang der Wakeup-Anforderung). Gibt der Master innerhalb von 150 Millisekunden nach Erhalt der ersten Wakeup-Anfrage keine Header aus, kann der Slave, der in den Wakeup-Modus versetzt werden soll, versuchen, eine zweite Wakeup-Anfrage zu senden (und nochmal 150 Millisekunden warten). Reagiert der Master noch immer nicht, wird eine dritte Wakeup-Anfrage gestartet und wieder 150 Millisekunden gewartet. Erfolgt immer noch keine Reaktion, muss der Slave 1,5 Sekunden warten, bevor eine vierte Wakeup-Anfrage gestellt wird. Die NI-CAN Frame API für LIN ermöglicht die Durchführung des Wakeup-Prozesses entsprechend der Spezifikation LIN 2.0, gleichgültig ob die LIN-Schnittstelle als Master oder Slave fungiert.

Nach oben

Erweiterte Frame-Arten

Die Spezifikation LIN 2.0 unterteilt LIN-Frames in sechs Typen:

  1. Bedingungslos
  2. Durch Ereignis getriggert
  3. Sporadisch
  4. Diagnostisch
  5. Anwenderdefiniert
  6. Reserviert

Hierbei ist zu beachten, dass die Unterschiede bei diesen Frame-Typen entweder im Timing der Übertragung oder im Inhalt der Daten-Bytes liegen. Unabhängig von der Klassifizierung des Frames besteht ein vollständiger LIN-Frame immer aus einem Header, der vom Master-Task und einer Antwort, die vom Slave-Task übertragen wird. Die NI-CAN Frame API für LIN erfüllt die Ansprüche für den Umgang mit all diesen LIN-spezifizierten Frame-Typen. Der bedingungslose Frame wird am häufigsten eingesetzt. Er überträgt Signale (Daten) und deren Identifikatoren bewegen sich im Bereich von 0 – 59.
Der durch ein Ereignis getriggerte Frame versucht die Busbandbreite zu erhalten, indem eine bedingungslose Frame-Antwort von mehreren Slaves innerhalb eines Frame-Zeitfensters angefragt wird.
Dieser durch ein Ereignis getriggerte Frame hat eine ID im Bereich von 0 – 59. Bei jedem Slave, der potenziell auf die entsprechende Header-ID reagieren könnte, wird das erste Daten-Byte mit der geschützten ID geladen, auf die er antworten würde, wenn der Master einen bedingungslosen Frame abfragen würde. Der durch ein Ereignis getriggerte Frame funktioniert wie folgt: Der Master schreibt eine durch ein Ereignis getriggerte ID in einen Header. Die Slaves reagieren nur auf diese ID, wenn ihre Daten aktualisiert wurden.

Gibt nur ein Slave eine Antwort aus, empfängt der Master diese und kann aus dem ersten Daten-Byte (durch die geschützte ID) schließen, von welchem Slave sie empfangen wurde. Geben mehrere Slaves eine Antwort aus, kommt es zu einer Kollision, die der Slave-Task des Master-Geräts als Busfehler meldet. Das Master-Gerät fordert dann mittels bedingungsloser Frames eine Antwort eines jeden Slaves an.

Sporadische Frames versuchen dem LIN etwas dynamisches Verhalten zur Verfügung zu stellen. Sporadische Frames übertragen immer Signale (Daten) und ihre IDs bewegen sich zwischen 0 und 59. Der Header eines sporadischen Frames sollte nur in seinem Zeitfenster gesendet werden, wenn der Master-Task weiß, dass ein Datenwert (Signal) innerhalb des Frames aktualisiert wurde. Diese Anforderung macht den Slave-Task des Master-Geräts zum normalen "Ausgeber" sporadischer Frame-Antworten.

Diagnostische Frames sind immer acht Daten-Bytes lang und übertragen immer diagnostische oder Konfigurationsdaten. Ihre ID ist im Falle eines Master-Anfrage-Frames 60 oder, bei einem Slave-Antwort-Frame, 61. Anwenderdefinierte Frames haben eine ID von 62 und können jede Art von Informationen übertragen. Reservierte Frames haben eine ID von 63 und dürfen nicht in einem LIN-2.0-Cluster verwendet werden.

Nach oben

Empfohlene PC-LIN-Schnittstellen

Die Kommunikation mit LIN-Geräten ist mit der LIN-Schnittstelle USB-8476 möglich

Nach oben

Weitere Informationen über LIN

Details zur LIN-Spezifikation bietet das LIN-Konsortium unter www.lin-subbus.org.

Nach oben