LIN Nachrichtenformat und Fehlererkennung

LIN Realisierung

Das im Jahr 1999 eingeführte LIN-Netzwerk ist in der Lage, mechatronische Komponenten mit geringen Datenmengen preisgünstig zu vernetzen. Der Standard wird heutzutage in vielen Bereichen des Kraftfahrzeugs genutzt, um eine Kommunikation intelligenter Sensoren und Aktoren herzustellen. Das LIN-Netzwerk findet besonders dort Anwendung, wo die hohe Bandbreite und die Vielseitigkeit von CAN nicht unbedingt benötigt werden.

Die LIN-Spezifikation umfasst das LIN-Protokoll, welches ein einheitliches Format zur Beschreibung der gesamten LIN und den Schnittstellen bietet. In dem Protokoll sind auch die verschiedenen Nachrichtenformate spezifiziert. Neben einer Standard-Botschaft können im LIN-Netzwerk auch andere Typen, wie ereignisorientierte Nachrichten oder Diagnosen zur Fehlererkennung, versendet werden.

Die verschiedenen Nachrichtenformate und die Mechanismen zur Fehlererkennung, werden in diesem Beitrag genauer beschrieben. Außerdem sollen einige Hinweise zur Realisierung eines LIN-Netzwerks gegeben werden.

Nachrichtenformate im LIN-Netzwerk

Der Standard-Botschaftstyp im LIN-Netzwerk wird zeitgesteuert übertragen. Neben der Standardnachricht sieht das LIN-Protokoll allerdings noch weitere Nachrichtenformate vor. Diese können entweder ereignisorientierte Nachrichten oder Informationen zur Diagnose sein.

Das Botschaftsformat im LIN-Protokoll besteht im Grunde aus einem Header und einer Response, die beide zusammen in den Frame eingebunden sind. Der erste Teil im Header ist das Break-Field, welches den Botschaftsbeginn einleitet. Darauf folgend werden die Synchronisations-Bits und der Nachrichten-Identifier gesendet. Der Nachrichten-Identifier setzt sich aus dem eigentlichen Identifier und zwei Parity-Bits zusammen, weshalb dieser auch als Protected Identifier bezeichnet wird.

Um den Header und die Response zu trennen, wird ein Zwischenraum (Response Space) eingefügt. Nach diesem werden dann die Nutzerdaten übermittelt, die maximal 8 Byte an Daten enthalten dürfen. Die Response überprüft im letzten Abschnitt die Nutzdaten mit Hilfe einer Prüfsumme, wodurch die Korrektheit der Botschaft gesichert wird.

Botschaftskopf (Header)

Um das oben erwähnte Botschaftsformat noch etwas detaillierter auszuführen, wird gesondert auf den Header der Botschaft im LIN-Netzwerk eingegangen. Der Header, der vom Master gesendet wird, verlangt eine Synchronisierung aller Teilnehmer, bevor die zentrale Sendung übertragen werden kann.

Sobald alle Teilnehmer synchron laufen, kann die Botschaft mit einer Kennung versehen werden, indem ein Identifier gesendet wird. Durch diese Botschaftskennung sind die angeschlossenen Slaves in der Lage, relevante Botschaften herausfiltern und diese auf mögliche Übertragungsfehler hin zu überprüfen.

Fehlererkennung im LIN Netzwerk

Um Fehler frühzeitig zu entdecken, sind in das LIN-Botschaftsformat mehrere Mechanismen zur Fehlererkennung eingebaut. Der Master ist für die zentrale Fehlerüberwachung der Slaves verantwortlich, was durch definierte Status-Bits funktioniert. Diese Status-Bits werden durch die Slaves selbst generiert. Die einzelnen Mechanismen zur Erkennung von Fehlern, sind im Folgenden kurz erklärt:

  • Bitmonitoring:
    Der Knoten, der die Botschaft gesendet hat, überprüft, ob der beabsichtigte Pegel auch tatsächlich auf dem Bus ankommt. Die Übertragung wird im Falle eines Fehlers abgebrochen.
  • Prüfsumme: 
    Wie bereits erwähnt, kann der Slave-Task durch die Auswertung der Prüfsumme, Fehler in der Datenübertragung erkennen.
  • Identifier-Parity: 
    Durch die Auswertung der Parity-Bits kann der Slave-Task Fehler im Identifier ausfindig machen.
  • Überwachung der Antwortzeit: 
    Wenn die maximal zulässige Übertragungszeit ohne eine Antwort abgelaufen ist, erkennt der Slave-Task dies und sendet Diagnose-Informationen.
  • Überwachung der Synchronisationsflanken: 
    Inkonsistenzen innerhalb des Synchronisationsfeldes werden durch den Slave auch erkannt.
  • Überwachung des Buspegels: 
    Physikalische Fehler im Buspegel, wie der Kurzschluss nach Masse, werden erkannt.

In der Spezifikation des LIN-Botschaftsformats wird die Reaktion auf Fehler nicht definiert. Die Fehlerbehandlung bei einer fehlerhaften Kommunikation ist abhängig von den Systemanforderungen und muss separat in der Anwendungsschicht festgelegt werden.

Physikalische Schicht des LIN-Netzwerks

Zur Datenübertragung nutzt der LIN-Bus eine Eindrahtleitung nach ISO 9141. Die Verwendung dieses Mediums führt zu einem Kostenvorteil des LIN-Netzwerks, bei der Übertragung von geringen Datenmengen von bis zu 20 kBit/s.

Der Buspegel leitet sich direkt aus dem Bordnetz des Fahrzeugs ab. Als Ausgangsstufe bietet sich die Verwendung von Standard-Schnittstellen (SCI) an, mit der Datenraten von bis zu 19.200 Bit/s zu empfehlen sind. Die Darstellung der Pegel differenziert analog zu den dominanten und rezessiven Pegeln im CAN.

Realisierungen im LIN-Netzwerk

Die Kernfunktionen müssen, ähnlich wie dies beim CAN-Netzwerk der Fall ist, in jeder Realisierung implementiert werden. Dabei handelt es sich um das Sensor- bzw. Aktor-Interface, Spannungsregler, Mikrokontroller und den LIN-Transceiver. Zu den einzelnen Funktionen folgen kurze Erläuterungen:

  • Sensor- bzw. Aktor-Interface: 
    Das Interface bildet eine Schnittstelle, die für die Anbindung an die Peripherie verantwortlich ist.
  • Spannungsregler:
    Dieser Baustein sorgt für die Bereitstellung der Versorgungsspannung.
  • Mikrokontroller: 
    Sämtliche Funktionen der Schichten 1 und 2 des LIN-Protokolls, können durch den Protokollkontroller realisiert werden. Dies kann sowohl Master als auch Slaves betreffen und Anwendungen beinhalten.
  • LIN-Transceiver: 
    Die Ankopplung an das physikalische Medium und die Zustandssteuerung wird durch den Transceiver vorgenommen.

Bezüglich des Grades der Integration gibt es singuläre Lösungen oder Möglichkeiten zur Realisierung, die den LIN-Transceiver, die Peripherie und den Spannungsregler zusammenfassen. Wenn alle vier der genannten Kernfunktionen integriert werden, entsteht ein kompletter LIN-Slave auf einem Chip.