LIN-Bus. Joshua B. Knobloch SS 2014

Transkript

1 LIN-Bus Joshua B. Knobloch SS Einführung 1.1 Motivation Seit den 80er Jahre ist es notwendig, dass sich mikroprozessorgesteuerte Systeme in einem Fahrzeug untereinander austauschen können. Dies geschah zunächst mit einfachen Punkt-zu-Punkt-Verbindungen, was zu einer Zunahme an Gewicht und Komplexität im Kabelbaum führte. Durch den Siegeszug der Elektrik und Elektrotechnik in der Automobilindustrie wurden die Kabelbäume jedoch so schwer und komplex, dass schon bald eine andere Lösung zur Kommunikation gefunden werden musste. Anfang der 90er Jahre wurde mit dem CAN der erste herstellerübergreifende Bus eingeführt. Der CAN ist ein von Bosch entwickelter und später durch die ISO11898 und SAEJ1939 standardisierter Klasse B bis Klasse C Bus ( Abbildung 1). Er dient hauptsächlich zur Vernetzung von Steuergeräten. Aus Kostengründen wurde zur Datenübertragung im Sensor/Aktor-Bereich jedoch entweder weiterhin die konventionelle Verdrahtung eingesetzt oder jeder Hersteller entwickelte seinen eigenen Low-Speed-Bus. Um die Komplexität im Kabelbaum und die Herstellungskosten noch weiter zu senken wurde ende der 90er Jahre der herstellerübergreifende LIN(Local Interconnectet Network)-Standard etabliert. Heute ist das LIN-System der De-facto- Standard für Übertragungen im Low-Speed Bereich und in so gut wie jedem Fahrzeug zu finden. Typische Aufgaben sind u.a. das Übertragen von Daten in Türmodulen, Regensensoren, Sitzsteuerung oder Stellmotoren z.b. bei Klimasystemen.

2 Abbildung 1: SAE Klassifizierung von Bussystemen [1, S. 41] 1.2 Technische Daten Der LIN-Bus ist ein von der Society of Automotive Engineers (SAE) als Klasse A (Abbildung 1) definierter Low-Speed-Bus. Es wird eine bidirektionale Ein-Draht-Leitung mit einer maximalen Übertragungsrate von 20kbit/s betrieben. Die in der Praxis üblichen Raten liegen jedoch bei 2.4kbit/s, 9.6kbit/s oder 19.2kbit/s. Der dominante Wert ist die Null. Es können bis zu 16 Teilnehmer zu einem Cluster zusammengeschlossen werden, wobei die maximale Entfernung zwischen zwei Knoten nicht mehr als 40 m betragen darf ohne zusätzlich einen Repeater mit einzubinden. Ein LIN-Cluster besteht aus einem Master Task und mehreren Slave Tasks. Im Gegensatz zu den Slave Knoten, welche nur den Slave Task enthalten, besitzt der Master Knoten zusätzlich einen Master Task (Abbildung 2). Der Master legt fest wann welches Frame auf dem Bus gesendet wird. Dazu wird eine Time-Schedule-Tabelle (Kapitel 3) abgearbeitet, was das System deterministisch macht. LIN basiert auf der weit verbreiteten UART-Schnittstelle, womit die Kosten für die Anschaffung der elektrischen Schaltung gering gehalten werden können. Im Fahrzeug ist ein LIN-Cluster oftmals ein Subsystem eines CAN-Busses

3 Abbildung 2: LIN-Cluster [1, S. 87] (Abbildung 2), was es erforderlich macht, eine Schnittstelle bereit zu stellen, welche die beiden Systeme verbindet. Diese Aufgabe übernimmt ebenfalls der Masterknoten indem er als Gateway fungiert und so die Kommunikation zwischen den beiden Bussystemen sicherstellt. 2 Bitübertragungsschicht Zur Übertragung der Bits nutzt LIN eine nach ISO 9141 genormte, bidirektionale Eindrahtleitung. Die Bitübertragungsschicht agiert unabhängig von höher gelegenen Schichten wie z.b. der Protokollschicht, weshalb Knoten problemlos versionsübergreifend miteinander kooperieren können. Das System ist auf eine Bordnetzspannung von 8 bis 18 V und eine Bietriebstemperatur von -40 bis zu 125 C ausgelegt. 2.1 Transceiver Die elektrischen Hauptbestandteile des Transceivers sind ein Pull-Up-Wiederstand, der mit der Versorgungsspannung verbunden ist, und ein Transistor, welcher über die Masse gekoppelt wird. Die Diode verhindert dass über die LIN- Signalleitung Strom in den Knoten fliest. (Abbildung 3) Durch die parallele Schaltung aller Transistoren mit der Masse ist der Low- Pegel dominant. D.h. es reicht dass ein ein Transistor eine Null sendet und die komplette Leitung nimmt den dominanten Wert an. Nur wenn alle Knoten die Transistoren sperren liegt auf der Leitung der rezessive Wert (die 1 wird gesendet) an.

4 Abbildung 3: Teilausschnitt eines LIN-Transceivers [1, S.107] 2.2 Signalspezifikation Um einen rezessiven Wert, also eine logische 1, zu senden, muss ein Knoten mindestens 60% der Versorgungsspannung auf die Leitung legen. Ein Wert unter 40% wird als dominanter Wert, also als eine logische 0, erkannt.(abbildung 4) Abbildung 4: Signalpegel von LIN [2, S. 119] 3 Protokolle Im LIN-Bus wird die Kommunikation zwischen Master-Slave und Slave-Slave Knoten ausschließlich vom Master, mit Hilfe sogenannter Frames (siehe Kapitel 2.1), gesteuert. Wann welcher Frame gesendet wird, steht in der Time- Schedule-Tabelle des Master Tasks. Ein Master kann mehrere Tabellen haben und z.b. bei eine Kollision von seiner normalen Tabelle auf eine Andere über gehen, damit die Kollision gelöst werden kann. Danach wird er wieder auf die normale Tabelle wechseln und diese periodisch abarbeiten. Grundsätzlich gibt es drei verschiedene Arten des Informationsaustausches (Abbildung 6): der Master fordert Daten von Slaves an

5 der Master liefert den Slaves Daten Slaves tauschen Daten untereinander aus 3.1 Frames Ein Frame besteht, wie in Abbildung 5 dargestellt, aus einem Header und einem Response. Der Header wiederum beinhaltet das Breakfield, das Syncfield und den Identifier und initialisiert einen Datenaustausch. Im Response findet dann der eigentliche Datenaustausch statt. Er wird immer, auch im Masterknoten, vom Slave Task erzeugt und ist die Antwort auf den Header. Abbildung 5: Aufbau eines Frames [2, S. 29]) Breakfield Das Breakfield wird immer vom Masterknoten initialisiert und signalsiert den Slaveknoten den Begin eines neuen Frames. Es ist mindestens 13 Bitzeiten auf dem dominanten Wert und dann mindestens eine Bitzeit auf dem rezessiven Wert Syncfield Zur Synchronisation der Slaves sendet der Master nach dem Breakfield ein 0x55 Datenbyte. Die Slaves messen die Zeit, die sie benötigen um das Byte zu empfangen und teilen sie durch 8. Für die Messung wird die fallende Flanke verwendet, da diese steiler als die steigende ist.

6 3.1.3 Identifier Das Identifierbyte lässt sich nochmals in den Frameidentifier und die Parity aufgliedern. Um das Frame zu identifizieren werden die Bits 0 bis 5 benutzt, was insgesamt 64 Codierungen möglich macht, welche wie folgt verteilt sind: 0-59: Signalübertragung 60 und 61: Diagnose und Konfiguration 62 und 63: für zukünftige Anwendungen reserviert Die Bits 6 und 7 sind Paritybits und werden durch folgende Formel berechnet: P 0 = ID0 ID1 ID2 ID4 P 1 = ID1 ID3 ID4 ID5 Wegen diese Paritybits spricht man auch oft vom Protected Identifier. [1, S. 93] Datenfeld Das Datenfeld ist der erste Teil der durch einen Slave Task erzeugten Antwort. Seine Länge ist vom Identifier abhängig, jedoch maximal 8 Bytes lang. Jedes Byte beginnt mit dem LSB (little-endian) Checksumme Die Checksumme komplettiert jeden Frame und ist eine der wenigen Möglichkeiten einen Übertragungsfehler festzustellen. Die Kommunikation mit Slaves der Version 1.x, das master request frame und das slave response frame, benutzen die classic Checksumme. Sie wird über die Bytes des Datenfeldes gebildet. Zur Kommunikation mit Slaves der Version 2.x wird die enhanced Checksumme verwendet. Diese bezieht den Protected Identifier zusätzlich mit ein. Im Protected Identifier werden die Bits 0 bis 5 zur Identifikation des Frames benutzt und die Bits 6 und 7 dienen als Parity-Bits um eventuelle Fehler zu erkennen. Für das master request frame und das slave response frame wird jedoch weiterhin die classic Checksumme verwendet.

7 3.2 Frametypen Es gibt insgesamt drei Frametypen, welche im Folgenden vorgestellt werden. Wichtig ist, dass ein LIN-Cluster nicht unbedingt alle Typen unterstützen muss, sondern nur die für die Anwendung wichtigen Unconditional Frame Mit dem unconditional Frame werden standardmäßig Signale ausgetauscht. Die zulässigen Identifier gehen von 0 bis 59. Der Header wird immer ausschließlich vom Master Task versendet und kann von einem oder mehreren Slaves beantwortet werden (Abbildung 6). Bei fehlerfreier Übertragung sollte ein Slave immer antworten. Unconditional Frames werden periodisch wiederholt. Abbildung 6: Drei Arten des Signalaustausches [2, S. 34] Event Triggered Frame Das Event Triggered Frame soll verhindern, dass selten auftretende Ereignisse zu viel Bandbreite beanspruchen. Dazu werden mehrere Unconditional Frames von mehreren Slaves zu einem Event Triggered Frame zusammengefasst. Das bedeutet, dass ein Event Triggered Frame mehrere Antworten erhalten kann. Der Identifier liegt zwischen 0 und 59, er darf aber nicht gleichzeitig von einem Unconditional Frame belegt sein. Außerdem müssen die Datenfeldgröße und das Checksummenmodell bei allen Unconditional Frames gleich sein. Ein Mix aus classic und der enhanced Checksumme ist also nicht möglich. Um Bandbreite zu sparen antworten nur die Slaves, bei denen sich ein Wert seit der letzten Abfrage geändert hat. Ist das jedoch bei keinem der Fall, so bleibt die Leitung nach dem Senden des Headers leer. Umgekehrt kann es aber auch passieren, dass mehrere Slaves eine Änderung mitteilen wollen.

8 Damit der Master weiß, welcher Slave ihm antwortet, wird in das erste Byte des Datenfeldes der Identifier eingetragen. Es bleiben also nur 7 Bytes zur Datenübertragung übrig. Wollen mehrere Slaves auf das Event Triggered Frame antworten, kommt es zu einer Kollision auf der Leitung. In diesem Fall gibt es zwei Möglichkeiten, wie die Kollision verlaufen kann. 1. Fall: Allgemein ist jeder Slavetask dazu verpflichtet, das Gesendete zurückzulesen und bei einem Fehler das Senden des nächsten Bytes einzustellen. Der Master bekommt diese Kollision aber nur mit, wenn alle Slaves das Senden einstellen. Abbildung 5 soll hierzu ein Beispiel liefern. Abbildung 7: Beide Slaves bemerken die Kollision und stoppen die Übertragung [1, S. 97] Beim Zurücklesen haben beide Slaves bemerkt, dass ein Fehler aufgetreten ist und stellen das Senden des zweiten Datenbytes ein. Nun bemerkt auch der Master die Kollision und wechselt von seiner normalen Time-Scheduling- Tabelle auf eine andere. Er sendet nun einmalig jedes Unconditional Frame, welches im Time Triggered Frame zusammengefasst wurden, und wechselt danach wieder zu seiner gewohnten Time-Scheduling-Tabelle. 2. Fall: Wie in Abbildung 6 beispielhaft dargestellt kann es auch passieren, dass ein Slave, und somit auch der Master, die Kollision nicht bemerkt. Abbildung 8: Nur ein Slave bemerkt die Kollision [1, S. 97] Durch die dominante Null wird das Byte von ID0 korrekt übertragen, so dass

9 der Master keine Möglichkeit hat, zu erkennen, dass auch ID1 einen geänderten Wert übermitteln wollte. ID1 muss nun auf die nächste planmäßige Abfrage des Masters warten, um den Wert übermitteln zu können Sporadic Frame In der Time-Scheduling-Tabelle des Masters dienen die Sporadic Frames als Platzhalter. Der Master hat hier die Möglichkeit, zwischen mehreren Unconditional Frames zu wählen. Benötigt er jedoch keine Daten, sendet er keinen Header und der Zeitslot bleibt leer. Tritt der Fall ein, dass er mehrere Unconditional Frames senden möchte, muss er sich für den mit höchster Priorisierung entscheiden Diagnostic Frame Für die Diagnostic Frames sind die Identifier 60 und 61 vorgesehen. Der Master nutzt den Identifier 60, um eine Konfiguration oder Diagnose durchzuführen und die 61, um eine Bestätigung der erfolgreichen Änderung vom Slave zu erhalten User-Defined und Extendet Frame Der User-Defined Frame ist für eine kundenspezifische und der Extendet Frame für eine zukünftige Erweiterung reserviert. Beide Frames sind im Datenfeld nicht auf 8 Bytes beschränkt, weshalb darauf zu achten ist, dass die LIN-Knoten keinen Slave-Not-Responding-Fehler anzeigen, wenn die maximale Übertragungszeit überschritten wird. 3.3 Fehlererkennung Da der LIN-Bus für einfache Aktor-Sensor Anwendungen entwickelt wurde und keine sicherheitskritischen Systeme vernetzt, gibt es nur wenige Mechanismen, um Fehler zu erkennen. In den folgenden Abschnitten werden die Wichtigsten beschrieben Bitfehler Der Bitfehler wird vom sendenden Slave-Task selbst erkannt. Wenn beim Rücklesen der gesendeten Daten ein Fehler festgestellt wird, muss das Senden sofort, spätestens aber nach dem Senden des Bytes, abgebrochen werden.

10 3.3.2 Identifier-Parity-Fehler Jeder Slave-Task überprüft die beiden Paritätsbits beim Empfang eines Headers. Stimmen die Bits nicht, handelt der Slave wie bei einem unbekannten Identifier und verwirft die Nachricht. 3.4 Checksum Error Jeder übertragene Frame enthält eine Checksumme, welche nach dem Empfangen einer Nachricht überprüft wird. Jeder Slave-Task, sowohl vom Slave als auch vom Master-Knoten, ist in der Lage einen Checksum Error festzustellen. Eine Korrektur oder Mitteilung des Fehlers ist jedoch nicht möglich. Gründe für die angesprochenen Fehler können Schwankungen in der Spannung oder Magnetfelder sein. 3.5 Netzwerkmanagement Wie in Abbildung 9 zu sehen ist, kennt LIN drei Zustände im Netzwerkmanagement. Abbildung 9: Netzwerkmanagement [2, S. 45] Sobald ein Knoten an eine Stromquelle angeschlossen wird, geht er in den Initialisierungszustand über. In diesem Zustand darf er maximal 100ms verbleiben, bevor er in den Betriebsmodus wechselt und bereit ist, den ersten Header zu empfangen. Um nun in den Sleep Mode zu gelangen, muss entweder vom Master ein Sleep Request kommen oder der Bus muss für mindestens

11 4, aber höchstens 10, Sekunden inaktiv gewesen sein. Im Sleep Mode wird der Bus auf den rezessiven Wert gesetzt. Er kann nur durch ein Wake-Up Signal, welches von jedem Slave Task gesendet werden kann, wieder in den Initialisierungszustand springen Go-To-Sleep Signal Nur der Master ist in der Lage, das Go-To-Sleep Kommando zu erteilen. Dazu sendet er einen Master-Request-Frame mit dem Identifier 60. Im Datenfeld wird das erste Byte auf 0 (0x00) und die restlichen sieben auf 0xFF gesetzt. Das Go-To-Sleep Signal bedeutet nicht automatisch, dass in einen Stromsparmodus gewechselt wird. Dies ist von der Application abhängig Wake-Up Signal Im Gegensatz zu dem Go-To-Sleep Signal, welches nur vom Master gesendet werden kann, hat jeder Slave Task die Möglichkeit, den Bus zu wecken. Das Signal besteht aus einem Wake-Up-Request und einem Wait. Im Wake-Up-Request wird ein dominantes Signal für 250 µs bis maximal 5 ms gesendet. Danach folgt eine Wartezeit von 100 ms, in der die Knoten Zeit haben, in den Betriebsmodus zu gelangen. Es werden bereits Wake-Up-Requests ab einer Länge von 150 µs akzeptiert, um eventuelle Laufzeitunterschiede auszugleichen. Folgt nach spätestens 150 ms kein Synchronisiationsbreak wird das Wake-Up-Signal erneut versendet. Dies kann bis zu drei mal wiederholt werden. Anschließend muss eine Pause von 1,5 s eingelegt werden bevor ein viertes Signal verschickt werden darf. 4 Konfiguration von Knoten Die Möglichkeit Knoten zu konfigurieren wurde mit Version 2.0 eingeführt und ermöglicht die dynamische Vergabe von Identifiern. Mit dieser Neuerung ist es fortan möglich sogenannte Of-The-Shelf-Knoten (Kapitel 4.1) herzustellen und in jeden beliebigen LIN-Cluster zu integrieren, ohne vorher Änderungen an der Software vorzunehmen. Der Master nutzt den Identifier 60 um einen Master-Request-Frame zu senden und überprüft anschließend ob die Änderung erfolgreich durchgeführt wurde, indem er mit dem Identifiere 61 einen Slave-Response-Frame verschickt.

12 Bei jedem Aufstart des System muss der Master diese Prozedur mithilfe eine Time-Scheduling-Tabelle durchführen um jedem Slave einen Identifier für die Frames zuzuweisen. Danach wechselt der Master auf die normale Time- Scheduling-Tabelle. 4.1 Off-The-Shelf-Knoten Um die Kosten für einen einzelnen Knoten noch weiter zu senken, wurde der Off-The-Shelf-Knoten eingeführt. Das bedeutet, der Hersteller des Knotens liefert alle wichtigen Daten, wie z.b. Protokollversion, Herstellercode, implementierte Frames oder Bitübertragungsrate, in einem Node Capability File (NCF) mit aus. Anhand dieser Informationen kann der Master im normalen Netzwerkbetrieb jeden Knoten leicht in den Cluster integrieren. Dazu konfiguriert er die Identifier des Knotens neu. 5 Zusammenfassung Nach über 15 Jahren Entwicklung und Verbesserung findet man heute aus gutem Grund in fast jedem Fahrzeug einen LIN-Bus. Durch seine weltweite Standardisierung und leichte Konfigurierbarkeit ist er billig in der Anschaffung und schnell in jeden Cluster integriert. Durch die Nutzung einer Eindrahtleitung werden zusätzliche Kabel im Kabelbaum eingespart, was das Gewicht des Fahrzeugs weiter reduziert. Durch die Master-Slave Hierarchie und die Kommunikation über Frames wird das System einfach gehalten und gleichzeitig werden Kollisionen reduziert. Da der LIN-Bus meist als Sub-Bus eines CAN eingesetzt wird und nur sicherheitsunkritische Aufgaben zugeteilt bekommt, sind Schwachstellen wie mangelnde Fehlererkennung und Behandlung oder eine maximale Datenübertragung von gerade einmal 20 kbit/s im Vergleich zu den Vorteilen hinnehmbar. Literatur [1] Hans-Christian von der Wense Andreas Grzemba. LIN-Bus. Franzis, [2] LIN Consortium. Lin specification package revision 2.2a [3] Sebastian Stegemann Denis Müller, Dirk Sommer. Local interconnect network (lin), Oktober 2009.

13 [4] Matthias Meier. Lin bus, Oktober [5] Ralf Schmidgall Werner Zimmermann. Bussysteme in der Fahrzeugtechnik. Vieweg + Teubner, [1, 2, 3, 4, 5]