LIN-Bus-Technologie wird optimiert – Teil 1 Die neue LIN-Spezifikation 2.1

Die LIN-Technologie setzt sich im Automobil immer weiter durch. Die Erfahrungen mit der drei Jahre alten Spezifikation 2.0 führten zur neuen Version 2.1. Der erste Teil dieses zweiteiligen Beitrags geht auf die Neuerungen der Kapitel 2 bis 4 der LIN 2.1 ein. Der zweite Teil wird die Neuerungen in den Kapiteln 5 bis 9 der Spezifikation vorstellen.

LIN-Bus-Technologie wird optimiert – Teil 1

Die LIN-Technologie setzt sich im Automobil immer weiter durch. Die Erfahrungen mit der drei Jahre alten Spezifikation 2.0 führten zur neuen Version 2.1. Der erste Teil dieses zweiteiligen Beitrags geht auf die Neuerungen der Kapitel 2 bis 4 der LIN 2.1 ein. Der zweite Teil wird die Neuerungen in den Kapiteln 5 bis 9 der Spezifikation vorstellen.

INHALT:
Protokoll-Spezifikation

  • Signal-Management
  • Frame-Struktur
  • Frame-Typen
  • Schedule-Tabelle
  • Netzwerk-Management
  • Status-Management

Transport-Layer-Spezifikation
Konfiguration und Identifikation der Knoten

  • Knoten-Modell eines Slaves und dessen Konfigurationstypen
  • Vergabe der Knoten-Adresse NAD
  • Zuweisung einer PID zu einem Frame

Literatur
Autor

Gliederung der neuen LIN-Spezifikation [1]
1. Specification Package
2. Protocol Specification
3. Transport Layer Specification
4. Node Configuration and Identification Specification
5. Diagnostic Specification
6. Physical Layer Specification
7. Application Program Interface Specification
8. Node Capability Language Specification
9. Configuration Language Specification

Protokoll-Spezifikation

  • Signal-Management

Das Signal-Management hat sich nicht geändert, es wurden nur einige Präzisierungen vorgenommen. So wurde klargestellt, dass ein Signal immer nur eine Quelle besitzen kann, aber beliebig viele Empfänger. Es kann gleichzeitig in mehreren Frames übertragen werden. Das Verhalten von gleichen Signalen in unterschiedlichen LIN-Clustern wurde dagegen nicht spezifiziert.

Es wurde auch explizit darauf verwiesen, dass 8-bit- bzw. 16-bit-Signale sowie Byte-Arrays immer genau auf die Bytes eines Frames abgebildet werden, wobei die „Big Endian“-Byte-Reihenfolge für die Initialisierung eingehalten werden muss (siehe auch „Configuration Language Specification“ im 2. Teil des Beitrags).

Im Abschnitt „Signal Reception and Transmission“ wird das Zeitverhalten der Signalübertragung bezogen auf die Zeitbasis des Masters genauer spezifiziert. Bild 1 zeigt dies für das Senden, Bild 2 für das Empfangen eines Frames.

Es ist zu erkennen, dass das Zeitverhalten des Masters und des Slaves unterschiedlich ist, weil der Header immer vom Master erzeugt wird. Während das Signal im Master spätestens bis zum Sendebeginn in den Frame eingetragen sein muss, kann es im Slave noch bis zum Übertragungsbeginn des Response-Teils eingefügt werden (Bild 1). Unterschiede gibt es auch beim Empfang eines Signals. Während im Slave das Signal im günstigsten Fall bereits nach dem Empfang des Response-Teils verfügbar ist, stellt der LIN-Stack des Masters das Signal erst mit dem Aufruf der API-Funktion l_sch_tick() beim nächsten Timer-Impuls bereit (Bild 2).