Datenaustausch mit LIN1

Was ist LIN?

LIN steht für Local Interconnect Network. LIN ist ein serielles Kommunikationssystem, auch LIN-Bus genannt. Die kostengünstige Kommunikation von Sensoren und Aktoren (innerhalb eines Kraftfahrzeuges) stand im Vordergrund bei der Entwicklung dieses Netzwerkes. Weiterer Grund für die Entwicklung des LIN war, dass das veraltete System (alle Aktoren, Sensoren und Motoren an eine zentrale Steuereinheit zu schließen) langsam an seine Grenzen stieß. Heutzutage findet man LIN in fast jedem KFZ, zum Beispiel in der Klima- oder Spiegelsteuerung. LIN kommt dort zum Einsatz, wo die Bandbreite und die Flexibilität des wesentlich teureren CAN nicht benötigt wird. Ein LIN besteht aus einer „Master-Einheit“ und einer oder mehreren „Slave-Einheiten“. Wenn der Master auffordert, Daten zu senden, werden diese dann von den Slaves gesendet. Der Master kennt die Reihenfolge aller zu übertragenen Daten.

Das LIN-Konsortium

Verantwortlich für die schnelle Durchsetzung des LIN war die Gründung des LIN-Konsortiums. Dieses Konsortium entwickelte die LIN-Spezifikation, welches das LIN-Protokoll umfasst. Dieses Protokoll ist ein einheitliches Format, das zum einen das ganze LIN und zum anderen die Schnittstelle zwischen LIN und Anwendersoftware beschreibt. Im Rahmen des Konsortiums schlossen sich bekannte KFZ-Hersteller, Halbleiter- und Toolhersteller zusammen, um so einen einheitlichen Kommunikationsstand, den Sensor-/Aktor-Bereich zu schaffen. Ebenfalls wurde eine einheitliche Entwicklungsmethode (LIN Work Flow) erschaffen und so wurde es im Bussystembereich sehr beliebt. Dank des LIN Work Flow kann man die Entwicklung von LINs automatisieren, was sich positiv auf Zeit und Kosten auswirkt.

LIN-Cluster

Die einheitliche Syntax (eine Art Konfigurationssprache) und das LIN-Descreption-File (LDF) beschreiben einen sogenannten „LIN-Cluster“. Die Kommunikationsbeziehung zwischen Master und Slaves ist im LDF klar definiert. Die LIN-Slaves (auch Knoten) werden über die einheitliche Node Capability Language (NFC) beschrieben. Diese legt die Leistungsmerkmale (wie: Bitraten, Diagnosefunktionen) der Slaves fest. Ein LIN-Slave ist, dank der zwei Datenaustauschformate, auch mehrmals in einem LIN-Cluster oder in zwei verschiedenen Clustern einsetzbar.

Eindraht-Kommunikation bis zu 20 Kbit/s

Die vom CAN bekannte Differenzialsignalübertragung wird in einem LIN nicht verwendet. Stattdessen wird eine herkömmliche Eindrahtleitung (Single Wire) verwendet. Die Versorgungsspannung der Steuerelektronik und die gesamte Masse des Fahrzeugs dienen als Bezugspotential für die Buspegel. Die Busse werden durch einen LIN-Tranceiver angekoppelt. 40 % der Spannung wird vom Empfänger als eine logische „Null“ aufgefasst, 60 % und mehr werden als logische „Eins“ deklariert. Damit es keine allzu großen Abstrahlungen gibt, ist die Datenrate auf 20 Kbit/s beschränkt. Die maximal empfohlene Knotenzahl (bei einer Leitungslänge von 40 Metern) beträgt 16. Betrachtet man den LIN-Cluster von der technischen Seite her als Schaltbild, so entspricht er einer Open-Collector-Schaltung.

Master-Slave-Kommunikation

Die Master-Slave-Architektur ist Ausgangspunkt für die Kommunikation mit einem LIN-Cluster. Wie schon erwähnt besteht ein solcher Cluster aus einem Master- und einem oder mehreren Slaveknoten. Über einen Master-Task koordiniert der Master-Knoten die Kommunikation im Cluster. Slave-Knoten verfügen dementsprechend über Slave-Tasks (Master-Knoten verfügen ebenfalls über Slave-Tasks). Um Kosten zu sparen, wird auf extra Kommunikationscontroller verzichtet. Die Kommunikation im LIN erfolgt ausschließlich durch den Master-Task im Master-Gerät. Die dazu erforderliche Übertragungseinheit auf dem LIN-Bus ist das sogenannte Frame, welcher dann in einen Header und eine Antwort aufgeteilt wird. Der vom Master-Knoten übertragene Header, besteht aus drei unterschiedlichen Feldern:

  • der Unterbrechung (Break)
  • dem Synchronisationsfeld (Sync)
  • dem Identifikatorfeld (ID)

Slave-Tasks (entweder die im Master oder im Slave) übertragen die Antwort, die aus den Daten (ist zu acht Datenbytes) und einer Quersumme (auch Checksumme; dient zur Fehlererkennung) besteht. Der LIN-Frame steht dank der Nachrichtenadressierung jedem LIN-Knoten zum Empfang zur Verfügung (sog. Broadcast).

Datenübertragung durch LIN-Frames

Die Datenübertragung wird durch den Microcontroller abgehalten und erfolgt byteorientiert. Dem Master kommen zwei zentrale Aufgaben bezüglich der Kommunikation zu:

Zum einen synchronisiert er die Slaves und zum anderen ordnet er die Kommunikation, indem er einen Sender und mindestens einen Empfänger für die Nachricht bestimmt. Bevor der Master jedoch mit der Übertragung des Frames beginnt, sendet er eine Sync-Break. Diese Synchronisationspause soll die Slaves darauf hinweisen, dass ein LIN-Frame übertragen wird. Der Sync-Break ruft bei allen Slaves einen Fehler hervor. Ein sechs Bit langer ID dient zur Abordnung der Kommunikation. Dieser ist durch zwei Paritärbits gesichert, einem geraden Paritärbit (Even Paritary) und einem ungeraden Paritärbit (Odd Parity). Zusammen bezeichnet man dies als Protect Identifier (PID). Ein Fehler bei der Übertragung liegt dann vor, wenn sich die Quersumme mit den ankommenden Datenbytes nicht zu 0xFF addiert. Eine Verzögerung der Antwort sowie kurze Sendepause zwischen der Übertragung sind den Slave-Knoten aufgrund der einfachen und kostengünstigen Technik erlaubt (Response Space). Die Antwort darf sich aufgrund dessen um ca. 40 % verzögern. Diese Tatsache muss jedoch unbedingt beim Gestalten des LIN miteinkalkuliert werden.

Erweiterte Frame-Arten (Unconditional Frame)

Um den Kommunikationszyklus zu vereinfachen stehen weitere Frame-Typen zur Verfügung. Unter Sporadic Frames versteht man einen Frame, der sich einen Slot mit anderen Unconditional Frames teilt. Sie werden bei Bedarf vom Master komplett übertragen und dienen dazu Kollisionen zu vermeiden. Falls kein Bedarf vorhanden ist, bleibt der Slot dementsprechend leer. Der Event Triggered Frame wird dann eingesetzt, wenn neue Daten zu übertragen sind. Bei Event Triggered Frames lassen sich jedoch Kollisionen nicht ganz ausschließen.