Einführung in das LIN-Busprotokoll

Das Local Interconnect Network (LIN)-Bus und Controller Area Network (CAN)-Bus sind Kommunikationsprotokolle, die häufig in Automobil- und Industriesystemen verwendet werden. Obwohl LIN und CAN ähnlichen Zwecken dienen, gibt es erhebliche Unterschiede in ihrer Architektur und Leistungsfähigkeit. 

LIN wurde entwickelt, um einen Standard für kostengünstige Low-End-Multiplexkommunikation in Automobilnetzwerken zu schaffen. Obwohl CAN dem Bedarf an hochbandbreiten, fortgeschrittenen Fehlerbehandlungsnetzwerken gerecht wird, sind die Hardware- und Softwarekosten der CAN-Implementierung für leistungsschwächere Geräte wie Fensterheber und Sitzregler unerschwinglich geworden. LIN ermöglicht eine kosteneffiziente Kommunikation in nicht kritischen Anwendungen, bei denen die Bandbreite und Vielseitigkeit von CAN nicht erforderlich sind. LIN kann relativ kostengünstig mit dem Standard-seriellen universellen asynchronen Empfänger/Sender (UART) implementiert werden, der in die meisten modernen kostengünstigen 8-Bit-Mikrocontroller eingebettet ist.

Moderne Automobilnetzwerke verwenden eine Kombination aus LIN für kostengünstige Anwendungen vor allem in der Karosserieelektronik, CAN für die Mainstream-Antriebsstrang- und Karosseriekommunikation und den neu entstehenden FlexRay-Bus für Hochgeschwindigkeits-Synchronisationsdatenkommunikation in fortgeschrittenen Systemen wie der aktiven Federung.  

Der LIN-Bus verwendet einen Master/Slave-Ansatz mit einem LIN-Master und einem oder mehreren LIN-Slaves.

 
^{Abbildung 1: LIN-Nachrichten-Frame}

Der Nachrichten-Header besteht aus einem Break, das den Beginn des Frames kennzeichnet, und einem Sync-Feld, das vom Slave-Knoten zur Taktsynchronisation verwendet wird. Die Kennung (ID) besteht aus einer 6 Bit großen Nachrichtenkennung und einem 2 Bit großen Paritätsfeld. Mit der Kennung wird eine bestimmte Nachrichtenadresse angezeigt, jedoch nicht das Ziel der Nachricht. Nach Empfang und Interpretation der ID beginnt ein Slave mit der Nachrichtenantwort, die aus einem bis acht Byte Daten und einer 8-Bit-Prüfsumme besteht. 

Der Master steuert die Reihenfolge der Nachrichten-Frames, die in einem Zeitplan festgelegt ist. Sie können den Zeitplan nach Bedarf ändern. 

Es gibt verschiedene Versionen des LIN-Standards. Version 1.3 hat die Byte-Layer-Kommunikation abgeschlossen. Die Versionen 2.0 und 2.1 enthalten weitere Nachrichtenspezifikationen und Dienste, sind aber auf Byte-Ebene mit LIN 1.3 kompatibel. 

¹Diese Funktion wird von der API nicht nativ unterstützt. Sie können den Funktionsumfang jedoch implementieren. 

^{Tabelle 1: Vergleich der LIN-Versionen 1.3, 2.0 und 2.1}

Der LIN-Bus ist ein abgefragter Bus mit einem einzelnen Master-Gerät und einem oder mehreren Slave-Geräten. Das Master-Gerät enthält sowohl einen Master-Task als auch einen Slave-Task. Jedes Slave-Gerät enthält nur einen Slave-Task. Die Kommunikation über den LIN-Bus wird nur von der Master-Task im Master-Gerät gesteuert. Die Grundeinheit der Übertragung auf dem LIN-Bus ist der Frame, der in einen Header und eine Antwort unterteilt ist. Der Header wird immer vom Master-Knoten übertragen und besteht aus drei verschiedenen Feldern: der Unterbrechung, Synchronisation (Sync) und Kennung (ID). Die Antwort, die von einem Slave-Task gesendet wird und sich entweder im Master-Knoten oder in einem Slave-Knoten befinden kann, besteht aus einer Nutzdatenlast und einer Prüfsumme. 

Normalerweise fragt der Master-Task jeden Slave-Task in einer Schleife ab, indem er einen Header sendet, der aus einer Break-Sync-ID-Sequenz besteht. Vor dem Start des LIN wird jeder Slave-Task so konfiguriert, dass er entweder Daten auf dem Bus veröffentlicht oder Daten als Antwort auf jede empfangene Header-ID abonniert. Nach Empfang des Headers überprüft jeder Slave-Task die ID-Parität und prüft dann die ID, um zu bestimmen, ob er veröffentlichen oder abonnieren muss. Wenn der Slave-Task eine Antwort veröffentlichen muss, überträgt er ein bis acht Datenbytes an den Bus gefolgt von einem Prüfsummenbyte. Wenn der Slave-Task abonnieren muss, liest er die Nutzdaten und das Prüfsummenbyte aus dem Bus und unternimmt entsprechende interne Maßnahmen. 

Bei der Standard-Slave-zu-Master-Kommunikation sendet der Master die Kennung an das Netzwerk und nur ein Slave antwortet mit einer Nutzdaten.

Die Kommunikation zwischen Master und Slave erfolgt durch einen separaten Slave-Task im Master-Knoten. Dieser Task empfängt alle am Bus veröffentlichten Daten selbst und reagiert, als wäre er ein unabhängiger Slave-Knoten. Zur Übertragung von Datenbytes muss der Master zuerst die Antwort seines internen Slave-Tasks mit den zu übertragenden Datenwerten aktualisieren. Der Master veröffentlicht dann den entsprechenden Frame-Header und der interne Slave-Task überträgt seine Nutzdaten an den Bus.

^{Abbildung 2: LIN-Nachrichten-Frame}

1. Untbr

Jeder LIN-Frame beginnt mit der Unterbrechung, die 13 dominante Bits (nominal) gefolgt von einem Unterbrechungstrennzeichen von einem Bit (nominal) rezessiv umfasst. Dies dient als Starthinweis für alle Knoten auf dem Bus.

2. Sync

Das Sync-Feld ist das zweite Feld, das vom Master-Task im Header übertragen wird. Sync ist definiert als das Zeichen x55. Mit dem Sync-Feld können Slave-Geräte, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate messen und ihre internen Baudraten an den Bus anpassen.

3. ID

Das ID-Feld ist das letzte Feld, das vom Master-Task im Header übertragen wird. Dieses Feld identifiziert jede Nachricht im Netzwerk und bestimmt letztlich, welche Knoten im Netzwerk jede Übertragung empfangen oder beantworten. Alle Slave-Tasks warten kontinuierlich auf ID-Felder, überprüfen deren Paritäten und bestimmen, ob sie Herausgeber oder Abonnenten für diese bestimmte Kennung sind. Der LIN-Bus bietet insgesamt 64 IDs. Die IDs 0 bis 59 werden für signalführende (Daten-)Frames, 60 und 61 für Diagnosedaten, 62 für benutzerdefinierte Erweiterungen und 63 für zukünftige Protokollerweiterungen verwendet. Die ID wird als ein geschütztes ID-Byte über den Bus übertragen, wobei die unteren sechs Bits die Roh-ID und die oberen beiden Bits die Parität enthalten.

^{Tabelle 2: Paritätsberechnungsmethode}

4. Datenbytes

Das Datenbyte-Feld wird vom Slave-Task in der Antwort übertragen. Dieses Feld enthält ein bis acht Nutzdatenbytes. 

5. Prüfsumme

Das Prüfsummenfeld wird vom Slave-Task in der Antwort übertragen. Der LIN-Bus definiert die Verwendung eines von zwei Prüfsummenalgorithmen zur Berechnung des Werts im 8-Bit-Prüfsummenfeld. Die klassische Prüfsumme wird allein durch Summieren der Datenbytes und die erweiterte Prüfsumme durch Summieren der Datenbytes und der geschützten ID berechnet.

Die LIN 2.0-Spezifikation definiert den Prüfsummenberechnungsprozess als Summe aller Werte und Subtraktion von 255 jedes Mal, wenn die Summe größer oder gleich 256 ist (im Gegensatz zu Modulo-255 oder Modulo-256). Gemäß der LIN 2.0-Spezifikation gilt die klassische Prüfsumme für LIN-1.3-Slave-Knoten und die erweiterte Prüfsumme für LIN-2.0-Slave-Knoten. Ferner wird festgelegt, dass die IDs 60 bis 63 immer die klassische Prüfsumme verwenden. Die NI-LIN-Schnittstelle bietet ein Attribut zum Festlegen des Prüfsummentyps auf "Klassisch" oder "Erweitert". Die Standardeinstellung lautet "Klassisch". Gemäß der LIN 2.0-Spezifikation verwenden die IDs 60 bis 63 unabhängig von der Einstellung des Prüfsummenattributs immer die klassische Prüfsumme.

Abbildung 3 zeigt, wie ein Master-Task-Header und eine Slave-Task-Antwort zu einem LIN-Vollbild kombiniert werden. 

^{Abbildung 3: Erstellen von LIN-Frames}

Da der LIN-Bus ein abgefragter Bus ist, wird der Verarbeitung jedes Rahmens ein nominaler Zeitschlitz wie folgt zugewiesen:

Theader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NDaten + 1) * TBit
TFrame_Nominal = Theader_Nominal + TResponse_Nominal
Der Verarbeitung jedes Rahmens wird ein maximaler Zeitschlitz wie folgt zugewiesen:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1,4 * TResponse_Nominal
TFrame_Maximum = Theader_Maximum + TResponse_Maximum

Der LIN-Bus verbindet ein Master-Gerät (Knoten) und ein oder mehrere Slave-Geräte (Knoten) in einem LIN-Cluster miteinander. Die Funktionsweise jedes Knotens wird durch seine eigene Knotenfunktionsdatei beschrieben. Die Knotenfunktionsdateien sind Eingaben an ein systemdefinierendes Tool, das eine LIN-Beschreibungsdatei (LDF) erzeugt, die das Verhalten des gesamten Clusters beschreibt. Der LDF wird von einem Systemgenerator analysiert, um automatisch das angegebene Verhalten in den gewünschten Knoten zu erzeugen. An diesem Punkt beginnt der Master-Task des Master-Knotens mit der Übertragung von Headern auf dem Bus und alle Slave-Tasks im Cluster (einschließlich des eigenen Slave-Tasks des Master-Knotens) reagieren, wie im LDF angegeben.

Im Allgemeinen wird der LDF zum Konfigurieren und Erstellen des Scheduling-Verhaltens des LIN-Clusters verwendet. So werden z. B. die Baudrate, die Reihenfolge und Zeitverzögerungen für die Übertragung von Headern durch den Master-Task und das Verhalten jedes Slave-Tasks als Reaktion definiert. NI-LIN-Hardware und die NI-CAN Frame API für LIN bieten keine volle Unterstützung für LDFs, was bedeutet, dass Sie das Scheduling-Verhalten nicht auf die Hardware herunterladen können. Die Low-Level-Unterstützung des Zugriffs auf den Bus (Schreiben von Headern und Veröffentlichen oder Abonnieren von Antworten) ist jedoch vorgesehen, so dass der Benutzer dieses Scheduling-Verhalten auf Anwendungsebene erstellen kann. Wie in der Beschreibung für den NI-LIN-Response-Entry-Frame-Typ erwähnt, verfügt NI-LIN-Hardware über eine Antwort-Queue zum Speichern von Slave-Task-Antworten. Die Antwort-Queue enthält 64 Antworten, eine für jede der maximal 64 für LIN angegebenen IDs. Dadurch wird sichergestellt, dass der LIN-Schnittstellen-Slave-Task innerhalb der in der LIN-Spezifikation festgelegten Reaktionszeit auf Header reagieren kann.

Die NI-CAN Frame API für LIN bietet eine robuste Möglichkeit der vollständigen Low-Level-Interaktion mit dem LIN-Bus. Dies bietet dem Endnutzer die grundlegenden Funktionen zur Entwicklung komplexer Anwendungen für die Analyse und das Prototyping von LIN-Netzwerken. Die NI-CAN Frame API für LIN unterstützt keine LIN-Diagnose oder -Konfiguration, LDFs oder Schedule-Tabellen. Sie können diese Tasks jedoch in Anwendungen implementieren, die die NI-CAN Frame API für LIN verwenden.

Die LIN 2.0-Spezifikation besagt, dass die Fehlererkennung von den Slave-Tasks übernommen werden sollte und dass keine Fehlerüberwachung durch den Master-Task erforderlich ist. Die LIN 2.0-Spezifikation erfordert keine Behandlung mehrerer Fehler innerhalb eines LIN-Frames oder die Verwendung von Fehlerzählern. Bei Auftreten des ersten Fehlers in einem Frame bricht der Slave-Task die Verarbeitung des Frames ab, bis die nächste Break-Sync-Sequenz erkannt wird (im nächsten vom Master gesendeten Header). Wenn das Attribut "Log Bus Errors" auf TRUE gesetzt ist, wird ein Busfehler-Frame in die Lese-Queue aufgenommen. Wenn das Attribut "Log Bus Errors" auf FALSE gesetzt ist, wird ein Fehler von ncWriteNet oder ncWriteNetMult ausgegeben. 

LIN bietet auch Fehlerprotokolle an das Netzwerk. Die LIN 2.0-Spezifikation definiert ein Statusbit Response_Error, das der Slave in einem seiner übertragenen Frames an den Master melden muss. Dieses Bit wird immer dann gesetzt, wenn ein von einem Slave-Knoten empfangener oder gesendeter Frame einen Fehler im Antwortfeld enthält. Das Bit wird gelöscht, nachdem es in einer der veröffentlichten Antworten des Slaves übertragen wurde. Die NI-CAN Frame API für LIN unterstützt das Statusbit "Response_Error" nicht nativ, sondern bietet dem Endnutzer eine Möglichkeit, diese Funktionalität einfach auf Anwendungsebene zu implementieren. Die Prozedur setzt das Attribut "Log Bus Errors" auf 1, um die Protokollierung von Busfehler-Frames in der Lese-Queue zu aktivieren. Die Anwendung kann dann auf ein Lesen eines Busfehler-Frames überwachen, wobei der Fehlercode auf einen Fehler in der Antwort hinweist. Unter dieser Bedingung kann die Anwendung ein Statusbit "Response_Error" in einer lokalen Variablen setzen. Die Anwendung kann dann den Frame-Typ "NI LIN response entry" verwenden, um die Slave-Antwort-Queue mit Daten zu aktualisieren, die das Statusbit Response_Error enthalten, und dann das Bit in der lokalen Variablen löschen.

LIN verfügt über einen Mechanismus, der es Geräten ermöglicht, in den Ruhezustand zu wechseln und potenziell Strom zu sparen. Gemäß der LIN 2.0-Spezifikation können alle Slaves in den Ruhezustand versetzt werden, indem der Master einen Diagnose-Master-Anfrage-Frame (ID=60) sendet, wobei das erste Datenbyte 0 ist. Dieser spezielle Rahmen wird Schlafbefehl genannt. Slaves wechseln automatisch in den Ruhemodus, wenn das LIN länger als vier Sekunden inaktiv ist. Die NI-CAN Frame API für LIN bietet große Flexibilität, da der Benutzer die LIN-Schnittstelle auf Anwendungsebene wie gewünscht in den Ruhezustand versetzen kann. Nach Empfang eines Voll-Frames mit einer Sleep-Anfragenachricht oder eines Bus-Inaktiv-Frames, der vier Sekunden Businaktivität anzeigt, kann der Benutzer die LIN-Schnittstelle in den Ruhezustand versetzen, indem er das Attribut LIN Sleep auf TRUE setzt.

LIN bietet auch einen Mechanismus zum Wecken von Geräten am Bus. Wakeup ist ein Task, der von jedem Knoten auf dem Bus (einem Slave und dem Master) initiiert werden kann. Gemäß der LIN 2.0-Spezifikation wird die Wakeup-Anfrage ausgegeben, indem der Bus 250 μs bis 5 ms lang dominant ist. Jeder Slave sollte die Wakeup-Anfrage erkennen und bereit sein, Header innerhalb von 100 ms zu verarbeiten. Der Master sollte auch die Wakeup-Anfrage erkennen und mit dem Senden von Headern beginnen, wenn die Slave-Knoten bereit sind (innerhalb von 100 ms bis 150 ms nach Empfang der Wakeup-Anfrage). Wenn der Master nicht innerhalb von 150 ms nach Empfang der ersten Wakeup-Anfrage Header ausgibt, kann der Slave, der Wakeup anfordert, versuchen, eine zweite Wakeup-Anfrage zu senden (und auf weitere 150 ms warten). Wenn der Master immer noch nicht antwortet, kann der Slave die Wakeup-Anfrage stellen und 150 ms ein drittes Mal warten. Wenn immer noch keine Antwort vorliegt, muss der Slave 1,5 Sekunden warten, bevor eine vierte Wakeup-Anfrage gestellt wird. Die NI-CAN Frame API für LIN ermöglicht das Wakeup gemäß der LIN 2.0-Spezifikation, unabhängig davon, ob die LIN-Schnittstelle als Master oder Slave arbeitet.

In der LIN 2.0-Spezifikation werden LIN-Frames in sechs Arten unterteilt:

1. Nicht an Bedingung gebunden
2. Ereignis ausgelöst
3. Sporadisch
4. Diagnose
5. Benutzerdefiniert
6. Reserviert

Es ist wichtig zu beachten, dass die Unterschiede in diesen Frame-Typen entweder auf das Timing der Übertragung oder den Inhalt der Datenbytes zurückzuführen sind. Unabhängig von der Frame-Klassifizierung besteht ein vollständiger LIN-Frame immer aus einem vom Master-Task gesendeten Header und einer von einem Slave-Task gesendeten Antwort. Die NI-CAN Frame API für LIN kann auf die Anforderungen der einzelnen LIN-spezifischen Frame-Typen eingehen. Der bedingungslose Rahmentyp wird am häufigsten verwendet. Bedingungslose Frames übertragen Signale (Daten) und ihre Bezeichner liegen im Bereich von 0 bis 59.

Der ereignisgetriggerte Frame-Typ versucht, die Busbandbreite zu sparen, indem er von mehreren Slaves innerhalb einer Frame-Slot-Zeit eine bedingungslose Frame-Antwort anfordert.

Der ereignisgetriggerte Frame kann eine ID im Bereich von 0 bis 59 haben. Jedes Slave-Gerät, das potenziell auf die ereignisgetriggerte Header-ID reagieren könnte, hat sein erstes Datenbyte mit der geschützten ID geladen, auf die es reagieren würde, wenn der Master es nach einem bedingungslosen Frame abfragen würde. Der ereignisgetriggerte Frame funktioniert wie folgt. Der Master schreibt eine ereignisgetriggerte ID in einen Header. Die Slaves können nur auf die ereignisgetriggerte ID reagieren, wenn ihre Daten aktualisiert wurden.

Wenn nur ein Slave eine Antwort veröffentlicht, empfängt der Master diese und weiß anhand des ersten Datenbytes, von welchem Slave (durch die geschützte ID) sie empfangen wurde. Wenn mehrere Slaves eine Antwort veröffentlichen, kommt es zu einer Kollision, die der Master-Device-Slave-Task als Busfehler meldet. Das Master-Gerät fragt dann eine Antwort von jedem Slave unter Verwendung bedingungsloser Frames ab. 

Sporadische Rahmen versuchen, dem LIN dynamisches Verhalten zu verleihen. Sie übertragen immer Signale (Daten) und ihre IDs reichen von 0 bis 59. Der Header eines sporadischen Frames sollte nur in seinem Frame-Slot gesendet werden, wenn der Master-Task weiß, dass ein Datenwert (Signal) innerhalb des Frames aktualisiert wurde. Diese Anforderung macht den Master-Device-Slave-Task zum normalen Herausgeber von sporadischen Frame-Antworten.

Diagnose-Frames sind immer acht Datenbytes lang und enthalten immer Diagnose- oder Konfigurationsdaten. Die IDs lauten entweder 60 für einen Master-Anfrage-Frame oder 61 für einen Slave-Antwort-Frame. Benutzerdefinierte Frames mit der ID 62 können jede Art von Information enthalten. Reservierte Frames haben die ID 63 und dürfen nicht in einem LIN 2.0-Cluster verwendet werden.

NI-XNET LIN

Bei der NI-XNET Produktreihe handelt es sich um eine Kombination aus CAN-, LIN- und FlexRay-Schnittstellen mit einem optimierten Treiber, einfach bedienbaren APIs sowie Konfigurations- und Fehlerbehebungsprogrammen. Mit NI-XNET-Schnittstellen lassen sich Anwendungen für die schnelle und einfache Prototypenerstellung, Simulation und Prüfung von CAN-, LIN- und FlexRay-Netzwerken unter NI LabVIEW, LabVIEW Real-Time und C/C++ entwickeln.

Die LIN-Schnittstellen NI-XNET PCI/PXI und C-Serie verfügen außerdem über integrierte LDF-Unterstützung, hardwaregetaktete Zeitplanung für Master-Tasks sowie Frame- und Signalkommunikation. 

^{Abbildung 4: NI-XNET-Plattform für CAN, LIN und FlexRay}

NI USB LIN

^{Abbildung 5: LIN-Schnittstelle NI USB-8506}

Mit einem USB-LIN-Schnittstellengerät können Sie auch mit LIN-Geräten kommunizieren. Dies ist eine kostengünstigere mobile Lösung für die Kommunikation mit LIN-Netzwerken.