Einfacher und kostengünstiger Datenaustausch mit LIN Serielle Bussysteme im Automobil III

Sporadic, Event Triggered und Diagnostic Frames

Die LIN-Spezifikation ermöglicht es, den durch die LIN-Schedule vorgegebenen starren Kommunikationszyklus zu flexibilisieren beziehungsweise zu vereinfachen. Dazu stehen die beiden Frame-Typen „Sporadic Frame“ und „Event Triggered Frame“ zur Verfügung. Im Zuge der Einführung der zusätzlichen Frame-Typen bezeichnet man den herkömmlichen LIN-Frame fortan als „Unconditional Frame“.

Unter einem Sporadic Frame versteht man einen Unconditional Frame, der sich mit anderen Unconditional Frames denselben Frame Slot teilt. Sporadic Frames werden vom LIN-Master bedarfsabhängig komplett übertragen, so dass Kollisionen ausgeschlossen sind. Wenn kein Bedarf seitens des LIN-Masters vorliegt, bleibt der entsprechende Frame Slot einfach leer.

Der Event Triggered Frame wurde eingeführt, um sporadische Veränderungen oder Ereignisse auf Seiten der LIN-Slaves zu kommunizieren. Er entspricht prinzipiell einem Unconditional Frame, nur mit dem Unterschied, dass dem Frame-Header mehrere Frame-Responses von unterschiedlichen LIN-Slaves zugeordnet sind. Mit welcher Frame-Response der Event Triggered Frame Header komplettiert wird, hängt vom Bedarf der entsprechenden LIN-Slaves ab. Ein Bedarf liegt dann vor, wenn neue Daten zu übertragen sind. Die Frame-Response des Event Triggered Frame wird im ersten Byte durch den PID des assoziierten Unconditional Frame identifiziert.

Im Gegensatz zum Sporadic Frame lassen sich beim Event Triggered Frame jedoch Kollisionen nicht ausschließen. Im Fall einer Kollision ist der LIN-Master für die Übertragung aller dem Event Triggered Frame zugeordneten Unconditional Frames verantwortlich. Dies erreicht er durch die Aktivierung und Abarbeitung einer Collision Resolving Schedule.

Zur Diagnose von LIN-Slaves eignen sich sowohl gewöhnliche Unconditional Frames als auch spezielle Diagnostic Frames. Unconditional Frames werden für die einfache signalbasierte Diagnose eingesetzt, während man Diagnostic Frames entweder zur benutzerdefinierten Diagnose oder zur Diagnose auf Basis eines standardisierten Transportprotokolls [3] und einheitlicher Diagnosedienste einsetzt [4, 5].

Die LIN-Spezifikation definiert zwei Diagnostic Frames: Master Request Frame und Slave Response Frame. Der Master Request Frame (ID = 0x60) entspricht dem Diagnose-Request. In diesem Fall überträgt der LIN-Master sowohl den Frame-Header als auch den Frame-Response. Ein Master Request Frame wird beispielsweise dann übertragen, wenn ein Diagnose-Request über CAN anliegt. Der Slave Response Frame (ID = 0x61) entspricht der Diagnose-Response. In diesem Fall überträgt der LIN-Master den Header, der entsprechende LIN-Slave die Response.

Die serielle Datenübertragung in einem LIN-Cluster wird wegen des fehlenden Kommunikationscontrollers über die serielle Schnittstelle (Serial Communication Interface, SCI) des Mikrocontrollers abgewickelt und erfolgt byteorientiert. Jedes Byte wird vom SCI mit dem LSB (Least Significant Bit) zuerst übertragen und von einem Start- und einem Stopp-Bit eingerahmt (SCI Frame). Ein LIN-Frame setzt sich folglich aus einer Anzahl von SCI Frames zusammen, aufgeteilt auf Frame-Header und Frame-Response (Bild 4).

Mit der Übertragung des Frame-Headers erledigt der LIN-Master zwei zentrale Kommunikationsaufgaben: Er synchronisiert die LIN-Slaves und delegiert die Kommunikation, indem er einen Sender beziehungsweise einen oder mehrere Empfänger für die Frame-Response bestimmt. Die LIN- Slaves dürfen aufgrund der Kostensensibilität On-Chip-Resonatoren mit einer Frequenz-Toleranz von bis zu 14 % benutzen. Deshalb überträgt der LIN-Master zunächst einen Sync-Break, um alle LIN-Slaves davon in Kenntnis zu setzen, dass die Übertragung eines LIN-Frames beginnt. Der Sync-Break setzt sich aus mindestens 13 dominanten Bits zusammen und ruft bei allen LIN-Slaves einen SCI-Fehler hervor. Er wird vom Sync-Break-Delimiter terminiert (mindestens ein rezessives Bit). Mit dem folgenden Sync-Byte (SCI Frame mit dem Wert 0x55) überträgt der LIN-Master den Kommunikationstakt.

Zur Delegierung der Kommunikation dient ein sechs Bit langer ID, der durch zwei Paritätsbits mit Even Parity und Odd Parity gesichert ist. Der ID und die beiden Paritätsbits werden zusammen als PID (Protected Identifier) bezeichnet. Die ersten 60 IDs stehen für die Nutzdatenkommunikation zur Verfügung. Die letzten vier Identifier, ID 60 bis ID 63, sind reserviert, ID 60 und ID 61 davon für Diagnosezwecke.

Die Frame-Response setzt sich aus bis zu acht Datenbytes und einer Checksumme für die Fehlererkennung zusammen. Man unterscheidet die klassische von der erweiterten Checksumme. Die klassische Checksumme entspricht der invertierten Modulo-256-Summe aller Datenbytes. Ein Übertragungsfehler liegt vor, wenn sich die Modulo-256-Summe mit den ankommenden Datenbytes nicht zu 0xFF addiert. Die erweiterte Checksumme berücksichtigt zusätzlich den PID bei der Bildung der invertierten Modulo-256-Summe.

Weil die LIN-Slaves meistens mit sehr einfachen und kostengünstigen Mikrocontrollern ausgestattet sind, ist ihnen nicht nur erlaubt, die Übertragung der Frame-Response ein wenig zu verzögern (Response Space), sondern auch Sendepausen zwischen der Übertragung der SCI Frames (Interbyte Spaces) einzulegen. Insgesamt darf sich die Frame-Response so um 40 % verlängern. Dasselbe gilt für den Frame-Header, vor allem, weil es unterschiedliche Methoden gibt, den Sync-Break zu erzeugen. Die Zeitreserve von 40 % muss man beim Design der LIN-Schedule unbedingt berücksichtigen.

Das Ziel, ein kostengünstiges Kommunikationsprotokoll für den seriellen Datenaustausch im sicherheitsunkritischen Sensor-/Aktor-Bereich zu schaffen, wirkte sich vor allem auf das Design des Physical Layer aus. So nutzt man für die physikalische Signalübertragung in einem LIN-Cluster nicht die von CAN bekannte Differenzsignalübertragung, sondern verwendet eine gewöhnliche Eindrahtleitung (Single Wire). Um trotzdem eine ausreichende Störfestigkeit zu gewährleisten, verwendet man als Bezugspotential für die Buspegel die Versorgungsspannung der Steuergeräte-Elektronik und die Fahrzeug-Masse. Ein LIN-Transceiver sorgt für die physikalische Busankopplung. Ein Pegel unterhalb 40 % der Versorgungsspannung wird vom Empfänger als eine logische Null interpretiert. Als logische Eins interpretieren Empfänger Pegel oberhalb von 60 % der Versorgungsspannung.

Die maximale Datenrate ist auf 20 Kbit/s begrenzt, damit sich die Abstrahlungen in Grenzen halten. Bei Leitungslängen bis 40 Meter ergibt sich unter Berücksichtigung der Knoten- und Leitungskapazitäten sowie der maximal zulässigen Zeitkonstante eines LIN-Clusters, welche die LIN-Spezifikation vorgibt, eine maximal empfohlene Knotenanzahl von 16.

Schaltungstechnisch entspricht ein LIN-Cluster einer Open-Collector-Schaltung. Ein Pull-up-Widerstand sorgt dafür, dass der Buspegel nahezu der Versorgungsspannung (High-Pegel) entspricht, wenn die Sendetransistoren aller LIN-Knoten sperren. Der Buspegel wird auf nahezu Masse (Low-Pegel) gezogen, sobald ein Sendetransistor öffnet. Entsprechend werden der Low-Zustand als dominanter Pegel und der High-Zustand als rezessiver Pegel bezeichnet.

Der Kommunikation in einem LIN-Cluster liegt eine Master-Slave-Architektur zugrunde. Ein Cluster besteht aus einem Master-Knoten (LIN-Master) und mindestens einem oder mehreren Slave-Knoten (LIN-Slaves). Man verzichtet aus Kostengründen auf explizite Kommunikationscontroller und realisiert statt dessen die LIN-Kommunikation über Software-Tasks, die so genannten Slave-Tasks, in jedem Knoten. Der LIN-Master besitzt zusätzlich eine Master-Task, mit deren Hilfe er die Cluster-Kommunikation koordiniert (Bild 2).

Die Koordination erfolgt mittels der zyklischen Abarbeitung der in Frame Slots organisierten LIN-Schedule (Bild 3). Jeweils zu Beginn eines Frame Slots überträgt die Master-Task einen Frame-Header mit einer Frame-Kennung (Identifier, ID), die alle LIN-Slaves über ihre Slave-Task auswerten. Ein LIN-Slave überträgt im Anschluss an den Frame-Header die mit der ID assoziierte Frame Response. Der LIN-Frame, gebildet aus Frame-Header und Frame-Response, steht wegen der Nachrichtenadressierung mittels ID jedem LIN-Knoten zum Empfang zur Verfügung (Broadcast).