Local Interconnect Network (LIN)

Transkript

1 Ausarbeitung Local Interconnect Network (LIN) Denis Müller (761422) Dirk Sommer (760422) Sebastian Stegemann (760391) 13. November 2009

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einführung Motivation Geschichtliche Entwicklung LIN Specification Kommunikationsprinzip Aufbau eines LIN-Knotens Physical Layer Allgemein Grundstruktur eines LIN-Transceiver Protocol Specification Frameaufbau Zeitsteuerung Frametypen Network Management Fehlererkennung Fehlerbehandlung Transport Layer Allgemein PDU Structure Konfiguration und Diagnose Node Configuration and Identification Specification Diagnostic Specification Work-Flow-Konzept Node Capability Language Specification Configuration Language Specification Application Programm Interface Specification LIN-Cluster-Design-Prozess Zusammenfassung und Ausblick LIN-Bus in der Zusammenfassung Zukünftige Entwicklung Literaturverzeichnis 28 Müller, Sommer, Stegemann 2

3 Inhaltsverzeichnis Abkürzungsverzeichnis CAN Controller Area Network CF Consecutive Frames ECU Elektronic Controll Unit FF First Frame ID Identifier Kfz Kraftfahrzeug LDF LIN Description File LIN Local Interconnect Network LSB Least Significant Bit NAD Node Address for Diagnose NCF Node Configuration File PCI Protocol Control Information PDU Packet Data Unit PID Protected Identifier RSID Response Service Identifier SAE Society of Automotive Engineers SF Single Frame SID Service Identifier UART Universal Asynchronous Receiver Transmitter Müller, Sommer, Stegemann 3

4 1 Einführung 1 Einführung 1.1 Motivation Der Mensch versucht zunehmend sein Leben so einfach und angenehm wie nur möglich zu gestalten. Diese Entwicklung zeichnet sich sehr deutlich im Bereich des Automobils ab. Durch die ständig wachsenden Anforderungen stiegen im Laufe der Zeit die Zahl der verbauten Sensoren und Aktoren. Lange war es üblich, die immer größere Zahl dieser Komfortkomponenten direkt an ein zentrales Steuergerät (Elektronic Controll Unit (ECU)) anzuschließen und es z. B. mit einem Controller Area Network (CAN)-Bus zu verbinden (siehe Abb. 1.1a). (a) Konventionelle Vernetzung (b) LIN-Vernetzung Abb. 1.1: Von der klassischen zur hierarchischen Architektur (Quelle: [VEC09]) Dadurch, dass die Kosten, der Platzbedarf und das Gewicht mit der Elektronifizierung stetig zunahmen, die Zuverlässigkeit gleichzeitig aber abnahm, erkannten die Entwickler schnell die Vorzüge einer Vernetzung der Sensoren und Aktoren über ein serielles Bussystem. Aber auch, weil die zunehmende Individualisierung viele unterschiedliche Kabelbaum- und Steckervarianten erforderlich macht, was wiederum Müller, Sommer, Stegemann 4

5 1.2 Geschichtliche Entwicklung die Produktion, Installation und Wartung erheblich erschwerte. 1 Aus Kostengründen war der CAN-Bus nicht für den Subbusbereich geeignet. Deshalb setzten seit Mitte der 90er Jahre viele Kraftfahrzeug (Kfz)-Hersteller und -Zulieferer ihre eigens entwickelten Busprotokolle ein. Im Jahr 1998 wurde duch den Local Interconnect Network (LIN)-Bus ein einheitlicher Standard vorgegeben, welcher den entstandenen Wildwuchs der Subbusprotokolle eindämmen sollte. Mit der Entwicklung des LIN-Busses wurde eine einfache und kostengünstige Ergänzung hierarchischer Kfz-Netzwerke für sicherheitsunkritische Anwendungen konzipiert. Inzwischen wird er weltweit in sehr vielen Fahrzeugen eingesetzt. Typische Anwendungen sind bisher im Komfortbereich des Kfz: Klima-, Sitz-, Tür- und Spiegelsteuerung. Die typische LIN-Vernetzung ist in Abbildung 1.1b am Beispiel einer Türsteuerung zu sehen. Die Sensoren und Aktoren sind mit einer LIN-Busschnittstelle ausgestattet und über den LIN-Bus an das Türsteuergeräte (CAN-LIN-Gateways) angeschlossen. Diese hierarchische Architektur ermöglicht die Mehrfachnutzung von Sensorsignalen. Des Weiteren kann die Elektronik flexibel an die entsprechende Plattform und Ausstattungsvariante angepasst werden. 1.2 Geschichtliche Entwicklung Am Rande der VDI-Tagung Elektronik im Kraftfahrzeug im Jahre 1998 entstand die Idee eines einheitlichen Kommunikationsstandards für mechatronische Systeme. Dies führte daraufhin zur Gründung einer Arbeitsgruppe, dem LIN-Konsortium durch die Firmen DaimlerChrysler, BMW, Audi, Volkswagen, Volcano Communication Technologies und Motorola. Bereits in der ersten Sitzung der Arbeitsgruppe im November 1998 wurden die Grundanforderungen an ein solches Netzwerk definiert. Und darauf hin das neue Subbussystem LIN entwickelt. Um die Kosten gering zu halten, wurde das Universal Asynchronous Receiver Transmitter (UART)-Protokoll verwendet. Im Sommer 1999 (siehe Abb. 1.2) stand die erste Version des LIN-Protokolls (Version 0.9) zu Verfügung. Sie bestand aus den Teilen Protokoll, Bitübertragungsschicht und dem Anwendungsschicht. Im März 2000 wurde auf einem Kongress der Society of Automotive Engineers (SAE) in Detroit die erste Version der Öffentlichkeit vorgestellt. Im selben Jahr erschienen die Folgeversionen V1.1 und V1.2 in denen einige Verbesserungen integriert waren. Der erste Serieneinsatz erfolgte durch das Unternehmen DaimlerChrysler im Jahr 2001 in der SL-Klasse. Seit dem wurde LIN in allen Kfz-Klassen eingesetzt. 1 aus: [VEC09] Müller, Sommer, Stegemann 5

6 1.2 Geschichtliche Entwicklung Abb. 1.2: Zeitstrahl der LIN-Entwicklung In den Folgejahren bekannten sich die wichtigsten europäischen Automobilhersteller eindeutig zum LIN-Bus als Subbus für mechatronische Applikationen. Die Spezifikation 1.3 erschien im Jahre Bei dieser wurde die Bitübertragungsschicht überarbeitet und die Datensicherungsschicht hinzugefügt. Im September 2003 erschien die LIN-Spezifikation 2.0. Das Ziel der Überarbeitung bestand vor allem darin, sämtliche Voraussetzungen für die schnelle, einfache und sichere Entwicklung von LIN-Netzwerken bereitzustellen. Der Einsatz von sogenannten Off-The-Shelf-Knoten brachte dieses Vorhaben zum Ausdruck. Dabei handelt es sich um Knoten die von der Stange genommen und dann entsprechend für die spezifischen Bedingungen eines LIN-Clusters konfiguriert werden können. Die LIN- Spezifikation 2.1 wurde 2006 veröffentlicht. Im Vergleich zur Vorgängerversion wird für eine bessere Verständlichkeit im Umgang mit LIN gesorgt. Müller, Sommer, Stegemann 6

7 2 LIN Specification 2 LIN Specification 2.1 Kommunikationsprinzip Die Kommunikation in einem LIN-Netzwerk (LIN-Cluster), basiert auf dem Master- Slave-Prinzip. Es gibt einen Master-Task, der die Kommunikation initiiert und mehrere Slave-Tasks, die die Nachricht übermitteln. Dabei besteht der Master-Knoten sowohl aus dem Master-Task, als auch aus einem Slave-Task, um auch Daten an die Slave-Knoten zu übermitteln (Siehe Abb. 2.1). Der Master-Knoten ist außerdem in der Regel gleichzeitig Gateway zum CAN-Bus. Die Kommunikation beruht darauf, dass alle Slave-Tasks auf dem Bus mithören können. Der Master-Task beginnt jeden Frame mit dem Senden eines (Frame-) CAN-Bus Empfangsroutine Senderoutine Senderoutine (Header) Slave-Task Master Master Master-Task LIN-Bus Empfangsroutine Senderoutine Empfangsroutine Senderoutine Slave-Task A Slave A Slave-Task B Slave B Abb. 2.1: Schematische Darstellung des Kommunikationsprinzips Headers, der u. a. einen (Frame-)Identifier (ID) enthält. Abhängig von diesem ID schaut nun jeder Slave-Task in einer ihm bekannten Liste, wie er zu reagieren hat. Der Slave-Task antwortet indem er seine (Frame-)Response sendet oder er wartet auf die (Frame-)Response eines anderen Slave-Tasks und übernimmt Müller, Sommer, Stegemann 7

8 2.2 Aufbau eines LIN-Knotens diese oder er antwortet nicht und übernimmt auch keine Response. Im Anschluss beginnt der Master-Task den nächsten Frame, indem er einen neuen Header sendet. Diese Kommunkationsbeziehungen und das Verhalten des ganzen LIN-Netzwerks werden während der Entwicklungszeit festgelegt. 2.2 Aufbau eines LIN-Knotens Der Aufbau eines LIN-Knoten lässt sich wie bei anderen Bustypen, z. B. dem CAN- Bus, in drei Blöcke aufteilen (siehe Abb. 2.2). Die einzelnen Blöcke müssen dabei nicht unbedingt als Einzelchips ausgeführt sein, sondern können auch in ei- Input Microcontroller Output (Application) nem Chip integriert werden. Die Halbleiterhersteller bieten verschieden Lösungen mit unterschiedlichen Integrati- LIN-Controller (Protocol) onsstufen an. Die Aufgabe des LIN-Transceivers ist LIN-Transceiver unter Anderem die Wandlung von logischen Pegeln auf die physikalischen Pe- (Physical Layer) gel und entspricht demnach dem Physical Layer (Bitübertragungsschicht). LIN Abb. 2.2: Schematischer Aufbau eines Der LIN-Controller kümmert sich um LIN-Knotens die Umsetzung des LIN-Protokoll, so dass der darüber liegende Block nur anwendungsbezogene Aufgaben erledigen muss. Dazu könnte z. B. das Abfragen von Sensoren oder das Steuern von Aktoren gehören. 2.3 Physical Layer Allgemein Das Ziel ein möglichst kostengünstiges Bussystem zu entwickeln, wird auch in dem Physical Layer deutlich. Beim LIN-Bus verwendet man nicht wie beim CAN-Bus eine differenzielle Signalübertragung, sondern einen Eindrahtleitung, die topologisch als Müller, Sommer, Stegemann 8

9 2.3 Physical Layer Linie realisiert ist. 1 Die Fahrzeugmasse dient dabei als Rückleiter. Um dennoch ausreichend Störfestigkeit sicher zu stellen, wird für den High-Pegel, die Versorgungsspannung und für den Low-Pegel die Masse verwendet. Die Schwellen des Senders und des Empfängers werden dementsprechend festgesetzt. Der Sender muss den Bus für einen Low-Pegel mindestens unter 20% der Versorgungsspannung(V SUP ) ziehen. Der High-Pegel muss mindestens bei 80% der Versorgungsspannung auf der Senderseite liegen. Die Schwellen des Empfängers, bis zu denen er aus den physikalischen Pegel die logischen Pegel interpretieren muss, sind toleranter. Ein Pegel unterhalb von 40% der Versorgungsspannung wird vom Empfänger als eine logische Null und oberhalb von 60% der Versorgungsspannung als logische Eins interpretiert (Siehe Abb. 2.3). Eine Versorgungsspannung zwischen 8 V bis 18 V ist dabei zuläßig. Außerdem beschränkt die LIN-Spezifikation die maximale Buslänge auf 40 m. Abb. 2.3: Signalpegel des LIN-Bus (Quelle: [LIN06], bearbeitet, S. 116) Grundstruktur eines LIN-Transceiver Abb. 2.4: Grundprinzip des LIN- Transceiver (Quelle: [GRZ05], S. 107) Die Grundstruktur eines LIN-Transceiver ist die Open-Collector-Schaltung, so dass der Low-Pegel der dominante Pegel ist. Der Pull-Up-Widerstand beträgt bei den LIN-Slaves 30 kω und beim LIN-Master 1 kω. Da diese Widerstände alle parallel am Bus liegen, wird die maximale Anzahl an Teilnehmer auf 16 begrenzt. Da es sich beim LIN-Bus um eine ungeschirmte Eindrahtleitung handelt, wurde die Baudrate auf maximal 20 khz begrenzt und die minimale Anstiegs- und Abfallzeit der Flanken vorgeschrieben. Dadurch wird unter anderem verhindert, dass die Leitung abstrahlt. Die Baudrate kann ab 1 khz eingestellt werden, wobei in Eurpoa 9,6 khz und 19,2 khz und in Amerika 10,4 khz 1 Vgl. [VEC09] Müller, Sommer, Stegemann 9

10 2.4 Protocol Specification üblich sind. 1 Darüber hinaus werden in der LIN-Spezifikation noch weitere Vorgaben, Eigenschaften und Grenzen bezüglich des Physical Layers festgelegt, auf die für weitere Details an dieser Stelle verwiesen wird. In vielen Fällen können fertig Transceiver verwendet werden, bei denen man dann davon ausgehen kann, dass sie den Physical Layer spezifikationsgerechte umzusetzen. 2.4 Protocol Specification In der Protocol Specification wird das Verhalten auf dem Bus, wie z. B. die Übermittlung und der Aufbau der Frames sowie das Verhalten der Knoten wie z. B. das Network Management beschrieben Frameaufbau Wie im Abschnitt 2.1 erläutert, besteht ein Frame aus dem vom Master-Tasks gesendeten Header und der Response eines Slave-Tasks. Der Header besteht aus dem Break Field, dem Sync Field und dem Protected Identifier Field. Die Response setzt sich zusammen aus dem Datenfeld mit 1 bis 8 Datenbytes und der Checksumme. Die Abbildung 2.5 verdeutlicht dies. Frame Header Response space Response Break Sync Protected Data 1 Data 2 Data N Checksum field field identifier field Inter-byte space Inter-byte spaces Abb. 2.5: Aufbau eines Frames (Quelle: [LIN06], S. 28) Ein Frame beim LIN-Bus ist so gewählt, dass er bis auf das Break Field UARTkompatibel. Jedes Byte wird von der seriellen Schnittstelle mit dem Least Significant Bit (LSB) zuerst übertragen und von einem Start- und einem Stopp-Bit eingerahmt. 1 Nach: [GRZ05], S. 107 Müller, Sommer, Stegemann 10

11 2.4 Protocol Specification Zum Erzeugen des Break Fields wird in der Regel die Baudrate temporär heruntergesetzt und ein 0x00 Datenbyte ausgegeben. Nach dem das Startbit und die 8 Datenbits gesendet wurden, wird die Baudrate wieder erhöht und mit der Ausgabe des Sync Field begonnen. Im Nachfolgenden werden die einzelnen Frame-Abschnitte erläutert. Break Field Die Aufgabe des Break Fields ist es, den Beginn eines neuen Frames zu signalisieren. Dazu sendet der Master-Task mindestens 13 Low-Bits. Der Slave muss mindestens 11 davon erkennen. Nur durch das Übertragen von mindestens 13 dominanten Bits ist gewährleistet, dass jeder LIN-Slave den Start einer Datenübertragung mitbekommt. Denn die LIN-Slaves dürfen aufgrund der Kostenreduzierung Break Break delimiter Abb. 2.6: Aufbau des Break Fields (Quelle: [LIN06], S. 29) On-Chip-Resonatoren mit einer Frequenz-Toleranz von bis zu 14% verwenden. 1 Der nachfolgende Sync-Break-Delimiter, der aus mindestens einem 1 High-Bit besteht, trennt das Sync-Break vom nachfolgenden Sync Field, das aufgrund der Verwendung der seriellen Schnittstelle mit einem dominanten Startbit beginnt. Sync Field Das Sync Field dient den LIN-Slaves zur Einstellung eines netzwerkweit einheitlichen Bittaktes, so dass alle LIN-Slaves mit demselben Takt senden bzw. empfangen. Der Master-Task sendet dazu das Datenbyte 0x55 (Vg. Abb. 2.7). Zur Ableitung des Taktes messen die LIN-Slaves die Zeit zwischen der fallenden Flanke des Startbits und die des 7. Datenbits. Sie teilen anschließend den Wert durch 8, zum Beispiel durch Verschieben von drei Bits nach rechts. Die Messung über die fallenden Flanken ist deutlich genauer, da der Pegel für das Low-Bit aktiv über den Transistor auf Masse gezogen wird. Der High-Pegel hingegen ergibt sich über den Pull-up- Widerstand. Der synchronisierte Slaves muss dabei sicher stellen, dass er während der Übertragung der Frames die Synchronisation mit einer maximalen Abweichung von 2% halten kann. 2 Aufgrund der Verwendung der Start- und Stopp-Bits pro Byte, kön- 1 Vgl. [VEC09] 2 Vgl. [VEC09] Müller, Sommer, Stegemann 11

12 2.4 Protocol Specification 8 T bit Sync field 2 T bit 2 T bit 2 T bit 2 T bit start bit stop bit Abb. 2.7: Aufbau des Sync Fields (Quelle: [LIN06], S. 111) nen sich die empfangenden Slaves auch innerhalb eines LIN-Frames nachzusynchronisieren. Protected Indentifier Die Aufgabe des Protected Identifier (PID) ist es, den Inhalt der Nachricht und nicht wie bei anderen Protokollen üblich einen Knoten zu adressieren. Der PID setzt sich aus dem eigentlichen ID mit sechs Bits und aus zwei Paritätsbits zusammen. Es sind damit bis zu 64 verschiedene Identifier (ID) möglich, von denen einige für spezielle Zwecke reserviert sind und in der Tabelle 2.1 aufgeführt werden. ID Bedeutung 0-59 Übertragung von Daten 60 Anfrage zum Slave vom Master 61 Antwort des Slaves zum Master 62 reserviert für herstellerspezifische Kommunikation 63 reserviert für zukünftige Entwicklungen Tab. 2.1: Aufteilung der Identifier Die Berechnung der Paritätsbits P0 und P1 basiert auf der Exklusiv-Oder-Verknüpfung der ID-Bits. Die beiden Paritätsbits ergeben sich wie folgt: Data Bytes P 0 = ID0 ID1 ID2 ID4 P 1 = (ID1 ID3 ID4 ID5) Die Response kann als Antwort auf einen Header verstanden werden und wird von einem über den ID angesprochenen Slave-Task gesendet. Die Response enthält Müller, Sommer, Stegemann 12

13 2.4 Protocol Specification zwischen ein bis acht Bytes, die jeweils mit einem Start- und einem Stopp-Bit eingerahmt werden (Siehe Abb. 2.8). Die Anzahl der Datenbytes bei den ID ist Start bit ID0 ID1 ID2 ID3 ID4 ID5 P0 P1 Stop bit Abb. 2.8: Aufbau eines Datenbytes (Quelle[LIN06], S. 29) jedem Teilnehmer bekannt. Bei der Übertragung eines Words wird das Low-Byte zu erst übermittelt (little-endian-übertragung)(siehe Abb. 2.9). Data 1 Data 2 Data 3 Data 4 Data 5 Data 6 Data 7 Data 8 Abb. 2.9: Reihenfolge der Datenbytes (Quelle[LIN06], S. 30) Checksumme Die Datenbytes werden mit Hilfe einer Checksumme gesichert. Dabei wird zwischen zwei Checksummentypen unterschieden. Zum Einen die Classic Checksum, bei denen nur die Datenbytes in die Checksummenberechnung verwendet werden und zum Anderen die Enhanced Checksum, bei der neben den Datenbytes auch der PID berücksichtigt wird. Für die Checksummenberechnung wird die invertierte Modulo-256-Summe eingesetzt, das heißt der Übertrag der 8-Bit-Addierung wird zum LSB des Zwischenergebnisses hinzuaddiert. Die Gesamtsumme wird anschließend invertiert. Das nachfolgende Beispiel in Tabelle 2.2 soll dies verdeutlichen. Als Bytes wurden 0x4A, 0x55, 0x93 und 0xE5 gewählt. Vorgang hex Carry D7 D6 D5 D4 D3 D2 D1 D0 Sender: 0x4A 0x4A x55 = 0x9F (Übertrag addieren) 0x9F x93 = 0x Übertrag addieren 0x xE5 = 0x Übertrag addieren 0x invertieren 0xE Empfänger: 0x19+0xE6 = 0xFF Tab. 2.2: Beispiel der Checksummenberechnung (Vgl. [LIN06], S. 52) Müller, Sommer, Stegemann 13

14 2.4 Protocol Specification Um zu überprüfen, ob die Übertragung fehlerfrei war, addiert der Empfänger die empfangenen Datenbytes und ggf. den PID und addiert das Ergebnis zu der empfangenen Checksumme. Wenn das Ergebnis nicht 0xFF ist, trat während der Übertragung ein Fehler auf Zeitsteuerung Eine der wichtigsten Eigenschaften des LIN-Busses ist es, dass die Übertragung der Nachrichten im Zeitschlitz-verfahren (Time-Slot-Verfahren) erfolgt. Das heißt, jeder Frame hat eine festgelegte Zeit zur Verfügung in der er übersendet werden muss. Dadurch wird das System deterministisch. Der Master-Task hat dazu eine sogenannte Time-Schedule-Tabelle, die er zyklisch abarbeitet. Diese Time-Schedule- Tabelle ist Teil des LIN Description File (LDF)s und wird während der Entwicklung des LIN-Netzwerks festgelegt. Sie enthält, die ID und deren Reihenfolge, sowie die Länge der Datenbytes, aus der sich die Länge der Time-Slots ergibt. In der Regel hat der Master-Task mehrere Time-Schedule-Tabelle zwischen denen er im Betrieb wechseln kann. Ein Beispiel einer einfachen Anwendung einer Time-Schedule-Tabelle mit Time- Slots zeigt die Abbildung 2.10 im nachfolgenden Abschnitt Frametypen Nachfolgend werden die verschiedenen Frametypen vorgestellt. Dabei muss ein LIN- Knoten nicht alle Typen unterstützen, sondern nur die die für die Anwendung notwendig sind. Unconditional Frame Der Unconditional Frame ist der Standard Frame in einem LIN-Netzwerk. Bei einem ID antwortet immer nur ein Slave-Task auf den vom Master-Task gesendeten ID. Dabei sind Kommunikationen zwischen Master und Slave, Slave und Master und Slave zu Slave möglich, aber wie bereits beschrieben, wird jeder Frame vom Master initiiert. Für Unconditional Frames, sowie die davon abgeleiteten Sporadic Frames und Event Triggered Frames, sind die ID 0-59 reserviert. Anhand der Abbildung 2.10 wird das zyklische Abarbeiten einer Time-Schedule- Tabelle mit Unconditional Frames verdeutlicht. Müller, Sommer, Stegemann 14

15 2.4 Protocol Specification Abb. 2.10: Prinzip des Unconditional Frames (Quelle:[GRZ05], bearbeitet, S. 98) Sporadic Frame Das Grundprinzip beim Sporadic Frame ist in einer sonst festen Time-Schedule- Tabelle einen Platzhalter für verschiedene Frames zu schaffen. Innerhalb eines Time- Slots kann so zwischen verschiedenen IDs gewechselt werden. Dabei muss darauf geachtet werden, dass die Länge und damit die Anzahl an Datenbytes in den Time- Slots fest ist. Der Master kann diesen Time-Slot aber auch leer lassen. Ein Sporadic Frame schafft somit mehr Dynamik innerhalb einer festen Time-Schedule-Tabelle, die aber insgesamt vorhersagbar bleibt. Die Abbildung 2.11 zeigt ein mögliches Beispiel. Im Time-Slot drei kann der Master entweder den Unconditional Frame Gas Tank Gauge oder Outside Temperature senden. Darüber hinaus kann der Time-Slot auch leer gelassen werden. Abb. 2.11: Prinzip des Sporadic Frames (Quelle:[GRZ05], S. 98) Event Triggered Frame Eine weitere Möglichkeit das Zeitverhalten zu verbessern ist der Event Triggered Frame. Mit einem ID werden mehrere Slaves-Tasks zusammen angesprochen. Es Müller, Sommer, Stegemann 15

16 2.4 Protocol Specification können darauf alle angesprochenen Slave-Task reagieren, indem sie ihre Response aussenden. Damit der Master weiß, von wem die Antwort kam, sendet jeder von ihnen im ersten Datenbyte den ID seines dazugehörigen Unconditional Frames. Alle angesprochene Slaves müssen für die Response die gleiche Länge und den gleichen Checksummentyp verwenden. Da auch mehrere Slave-Task gleichzeitig antworten können, muss der Master diese Kollision über die Checksumme erkennen. Er muss dann alle ID der Unconditional Frames nacheinander abfragen, die mit dem ID des Event Triggered Frames zusammengefassten wurden. Es soll durch den Event Triggered Frame verhindert werden, dass bei seltenen Ereignissen zu viel Bandbreite notwendig ist bzw. dass nicht schnell genug reagiert werden kann, wenn die Ereignisse selten abgefragt werden. 1 Ein Beispiel ist das Abfragen von Schaltern, die alle den gleichen Zweck haben, wie beispielsweise das Fenster-Heben. Sobald ein Schalter gedrückt wird, antwortet dieser mit seiner Response, andernfalls nicht. Dieses Ereignis ist relativ selten, so dass es hier sinnvoll ist nicht alle nacheinander abzufragen, sondern die Schalter gemeinsam abzufragen. Diagnostic Frames Mit den Diagnostic Frames wird die Konfiguration und Diagnose der Slaves durchgeführt. Für die Diagnostic Frames sind die ID 60 und 61 reserviert. Mit dem ID 60 sendet der Master ein Requenst zum Slave und mit dem ID 61 wird die Response des Slaves abgefragt. Es sind die einzigen Nachrichten, die der Slave bestätigt. Da dies in den Standardnachrichten nicht vorgesehen ist, wird ein weiteres Protokoll in die Datenbytes integriert. Dieses aufgesetzte Protokoll wird im Abschnitt 2.5 erläutert. User-defined Frames Der ID 62 ist reserviert für herstellerspezifische Kommunikation und kundenspezifische Erweiterungen. Bei diesen User-defined Frames gibt es keine definierte Framelänge. Die LIN-Knoten müssen also auch mit mehr als acht Datenbytes rechnen. Reserved Frames Der ID 63 ist reserviert für zukünftige Erweiterung des Protokolls. Wie bei den User-defined Frames muss ein LIN-Knoten mit mehr als acht Datenbytes umgehen können. 1 Vgl. [GRZ05], S. 96 Müller, Sommer, Stegemann 16

17 2.4 Protocol Specification Network Management Das Network Management ist beim LIN-Bus für einen Slave einfach ausgelegt. Es gibt nur die folgenden vier Zustände: Power-Off Initializing Operational (Normaler Betriebszustand) Sleep-Mode Abbildung 2.12 verdeutlicht den Zusammenhang der Zustände, die in den anschließenden Abschnitten beschrieben werden. Power on Initializing Wake-up Befehl Initialisierung beendet [< 100 ms] Bus Sleep Mode Got-to-Sleep-Befehl oder Bus 4-10 s inaktiv Operational Abb. 2.12: Zustandsdiagramm eines Slave-Knotens (nach: [LIN06], S. 44) Initializing Während der Initialisierung werden alle für die LIN-Kommunikation notwendigen Komponenten eingerichtet. Dieser Zustand wird nach dem Einschalten und nach dem Wake-Up-Befehl erreicht, wobei die Initialisierung jeweils verschieden sein kann. Im Anschluss wechselt der Slave in den normalen Betriebszustand. Alle weiteren Ergänzungen wie Fehlerbehandlung und Konfiguration der Slaves sind Aufgabe der Anwendung und nicht festgelegt. Operational Im normale Betriebszustand sendet und empfängt der Slave die LIN-Frames. Er wechselt in den Sleep-Modus, wenn er den Go-to-Sleep-Befehl vom Master erhält oder der Bus für 4 bis 10 s inaktiv ist. Müller, Sommer, Stegemann 17

18 2.4 Protocol Specification Sleep-Mode Im Sleep-Mode ist der Bus auf High, da kein Teilnehmer sendet. Es ist jedoch der Anwendung überlassen, ob der LIN-Knoten auch in einen energiesparenden Modus wechselt. Jeder LIN-Knoten wechselt vom Sleep-Modus zur Initialisierung, wenn er den Wake-Up-Befehl erhält. Go-to-Sleep-Befehl Der Go-to-Sleep-Befehl kann nur vom Master ausgesendet werden, in dem er einen Frame mit dem ID 60 (Master-Request) und acht Datenbytes sendet. Das erste Datenbyte ist dabei 0x00 und die restlichen sieben sind 0xFF. data1 data2 data3 data4 data5 data6 data7 data8 0 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF Tab. 2.3: Go-to-Sleep-Befehl Wake-Up-Befehl Den Wake-Up-Befehl kann jeder Slave-Task senden, in dem er den Bus für mindestens 250 µs auf Low zieht. Wenn der Master-Task daraufhin nicht innerhalb von 150 ms bis 250 ms in den normalen Betriebszustand wechselt und mit dem Senden eines ID beginnt, wiederholt der Slave-Task den Wake-Up-Befehl (Siehe Abb. 2.13). 250 µs - 5 ms 150 ms ms 250 µs - 5 ms 150 ms ms 250 µs - 5 ms Abb. 2.13: Ein Block von Wake-Up-Bfehlen (Quelle: [LIN06], S. 45) Fehlererkennung Beim LIN-Knoten können sechs verschiedene Fehlerarten erkannt werden: 1 Bit-Fehler Checksummenfehler 1 Nach: [GRZ05], S. 99 Müller, Sommer, Stegemann 18

19 2.4 Protocol Specification Identifier-Parity-Fehler Slave-Not-Responding-Fehler Inconsistent-Synch-Field-Fehler Physical-Bus-Fehler Bit-Fehler Ein Bit-Fehler kann nur durch den Sender erkannt werden, indem er beim Senden den Bus überprüft. Wenn er nicht das zurückliest, was er gesendet hat, ist ein Bit- Fehler aufgetreten. Das Senden muss dann spätestens nach einem kompletten Byte abgebrochen werden. Checksummenfehler Ein Checksummenfehler kann jeder Slave-Task ermitteln, indem er die empfangene mit der selbst berechneten Checksumme vergleicht. Identifier-Parity-Fehler Einen Identifier-Parity-Fehler kann jeder Slave-Task ermitteln, in dem er die empfangen Parität mit der selbst berechneten Parität vergleicht. Slave-Not-Responding-Fehler Einen Slave-Not-Responding-Fehler kann nur ein Slave-Task erkennen, der auf eine Nachricht eines anderen Slave-Task wartet und wenn dieser nicht innerhalb der festgesetzten Zeit diese sendet. In der Regel ist das der Slave-Task im Master, aber der Fehler kann auch bei einer Slave-zu-Slave-Kommunikation von einem Slave erkannt werden. Inconsistent-Synch-Field-Fehler Ein Inconsistent-Synch-Field-Fehler tritt auf, wenn sich ein Slave nicht auf den Mastertakt synchronisieren kann. Eine Ursache dafür kann sein, dass die Flanken des Sync Fields außerhalb der Toleranzen liegen. Physical-Bus-Fehler Ein Physical-Bus-Fehler kann durch Kurzschluss zur Masse oder zur Versorgungsspannung verursacht werden, sowie durch parasitäre Impedanzen. Der Buspegel ist dadurch dauerhaft auf einem Low- bzw. High-Pegel. Müller, Sommer, Stegemann 19

20 2.5 Transport Layer Fehlerbehandlung Die Fehlerbehandlung ist nicht Teil der Spezifikation, um diese einfach zu halten. Es ist Aufgabe der Anwendung auf die Fehler zu reagieren. Dabei ist hervorzuheben, dass eine direkte Mitteilung von Kommunikationsstörungen vom Empfänger an den Sender nicht möglich ist. Jedoch muss jeder Slave innerhalb einer Time-Schedule- Tabelle auf Fehler abgefragt werden. 2.5 Transport Layer Allgemein Der Transport Layer wird für die Diagnose und Konfiguration der Slaves benötigt. Er ermöglicht auch, dass Daten, die größer als acht Byte sind, übertragen werden können PDU Structure Die Einheiten, die im Transport Layer übertragen werden, sind die sogenannten Packet Data Unit (PDU). Die Abbildung 2.14 zeigt den Aufbau von den PDUs, die wie bereits beschrieben innerhalb der acht Datenbytes gesendet werden. Dabei NAD PCI SID D1 D2 D3 D4 D5 PCI-type = SF Request NAD PCI LEN SID D1 D2 D3 D4 PCI-type = FF NAD PCI D1 D2 D3 D4 D5 D6 PCI-type = CF Response NAD PCI RSID D1 D2 D3 D4 D5 NAD PCI LEN RSID D1 D2 D3 D4 PCI-type = SF PCI-type = FF Abb. 2.14: Zusammensätzung eines PDU-Structur-Frames (Quelle: [LIN06], S. 57) unterscheidet man zunächst drei Arten, die als Request vom Master zum Slave mit dem ID 60 gesendet werden und drei Arten die vom Slave zum Master mit dem ID 61 als Response gesendet werden. Der erste Typ ist der Single Frame (SF) bei dem die Nachricht in einen einzigen Frame passt. Sollen längere Nachrichten übertragen werden, wird für den ersten Teil der Nachricht der First Frame (FF) und für die weiteren Teile werden die Consecutive Frames (CF)s verwendet. Die einzelnen Bytes der PDU-Struktur werden im Nachfolgenden beschrieben. Müller, Sommer, Stegemann 20

21 2.5 Transport Layer NAD Die Node Address for Diagnose (NAD) ist eine vom Hersteller vergebene Knotenadresse, die aber während der Startphase verändert werden kann. Für weitere Vertiefungen wird an dieser Stelle auf [LIN06] verwiesen. PCI Die Protocol Control Information (PCI) kennzeichnet, um welchen Protokolltyp es sich handelt. Die unteren vier Bytes enthalten einen Framecounter oder die Anzahl an Bytes plus SID/RSID-Byte, die übertragen werden. Type PCI type Additional information B7 B6 B5 B4 B3 B2 B1 B0 SF Length FF Length/256 CF Frame counter Abb. 2.15: Aufbau des PCI-Bytes (Quelle: [LIN06], S. 57) LEN Das Längenbyte LEN wird nur beim First Frame (FF) verwendet. Da im LEN-Byte die unteren acht Bits und ihm PCI-Byte die vier oberen Bits übertragen werden, kann eine Nachricht maximal 4095 (0xFFF) Bytes lang sein. SID/RSID Der Service Identifier (SID) kennzeichnet den Nachrichteninhalt vom Master zum Slave (Request), der vom Slave-Knoten ausgeführt werden soll. Der Response Service Identifier (RSID) kennzeichnet den Nachrichteninhalt vom Slave zum Master (Response). D1 bis D6 Die bis zu sechs Datenbytes sind abhängig vom SID bzw. vom RSID im LIN-Knoten zu interpretieren und zu verarbeiten. Müller, Sommer, Stegemann 21

22 2.6 Konfiguration und Diagnose 2.6 Konfiguration und Diagnose Node Configuration and Identification Specification Um innerhalb eines LIN-Clusters Konflikte zwischen einzelnen Slave-Knoten zu verhindern, wird in der Node Configuration and Identification Specification festgelegt wie ein Slave-Knoten ausgelegt werden muss und wie er identifiziert werden kann. Jeder Knoten hat eine LIN Product Identification, eine initiale NAD und optional eine Seriennummer in seinem Speicher (siehe (Abb. 2.16)) hinterlegt, dadurch kann innerhalb eines Clusters jeder Slave-Knoten identifiziert werden. Für die einzelnen Nachrichten jedes Slave-Knotens kann ein Identifier definiert werden. So dass zum Ansprechen mehrerer Slaves Multicast-Identifier eingerichtet werden können sowie auch jede einzelne Funktion jedes Slaves seperat über Identifier ansprechbar ist. ROM Serial number Supplier ID Function ID Variant ROM or NVRAM NAD PIDs ld_set_configuration e.g. pin configuration Initial NAD Instance generation VRAM NAD PIDs Configuration from master node, over the bus Abb. 2.16: Speichermodel eines Slave-Knotens (Quelle[LIN06], S. 66) Die LIN Product Identification besteht aus 5 Bytes: 2 Bytes Supplier ID: Dem Hersteller vom LIN-Konsortium zugewiesen 2 Bytes Function ID: Vom Supplier für das Produkt zugewiesen 1 Byte Variant ID: Diese wird geändert wenn das Produkt ohne Änderung der Funktion verändert wird. Die optionale Seriennummer besteht aus 4 Bytes und wird zum Unterscheiden von mehreren gleichen Knoten innerhalb eines Clusters benötigt. Für jeder Knoten ist im Node Capability File eine initiale NAD-Liste hinterlegt. Die initiale NAD wird bei der Instanz-Generierung gesetzt. Bei Knoten die keine Instanzgenerierung haben, hat die Liste nur einen Eintrag. Wenn mehrere gleiche Müller, Sommer, Stegemann 22

23 2.6 Konfiguration und Diagnose Knoten (z. B. intelligente Sensoren gleichen Typs) innerhalb eines Clusters vorhanden sind, wird durch Konfigurierung ein Eintrag der NAD-Liste (1-125) als NAD zugewiesen. Die beschriebenen Dienste werden durch den Master-Knoten unter Verwendung des Transportlayer genutzt. Dafür wird die single frame PDU-Struktur genutzt. Zum Identifizieren und Konfigurieren der Slave-Knoten sind verschiedene Service Identifier (SID) spezifiziert z.b. Assign NAD, Read by Identifier, Save Configuration usw Diagnostic Specification Die Diagnose eines Bussystems ist ein wichtiges Hilfsmittel zur manuellen und automatischen Lokalisierung von Fehlern innerhalb der Bordelektronik eines Fahrzeugs. In der Diagnostic Specification sind Methoden zum Übertragen von Diagnosedaten zwischen Master-Knoten bzw. Tester und Slave-Knoten unter Verwendung des Transportlayer spezifiziert. Die Diagnosedienste werden beim LIN-Bus immer von einem externen oder internen (Steuergerät welches den Master-Knoten enthält) Test-Tool ausgelöst. Dies bedeutet, dass die Verwendung der Diagnosefunktionalität nicht spezifiziert sind und in der Anwendungsschicht (meist in einem übergeordneten Bussystem z. B. CAN) realisiert werden müssen. Prinzipiell existieren zwei Möglichkeiten für die Diagnosekommunikation: 1. LIN-Master übertragt eine Anfrage des Testers zum LIN-Slave 2. LIN-Master übertragt eine Antwort eines LIN-Slave zum Tester Für die Diagnosekommunikation verwendet der Master-Knoten die NAD als Quelladresse für die angeforderte Information. Jedem Slave-Knoten wird eine von drei möglichen Diagnoseklassen mit unterschiedlich komplexer Diagnosefunktionalität zugewiesen: Class I Einfache Geräte ohne oder mit nur geringer Diagnosefunktionalität (z. B. intelligente Sensoren). Es wird nur die Knoten-Konfiguration unterstützt. Die Knotenidentifikation ist auf read by identifier begrenzt. Der Master benötigt nur die Unterstützung für minimale geforderte LIN Configuration Class II Ist gleich Class I, unterstützt jedoch auch Knotenidentifikation. Hierfür benötigt der Master die Unterstützung des kompletten Diagnoseprotokolls. Class III Slave-Knoten die wesentlich mehr als die normale Sensor/Aktor-Funktionalität haben. Dies liegt vor wenn z. B. Sensordaten ausgewertet und daraufhin Aktoren angesteuert werden. Der Slave-Knoten benötigt einen internen Fehlerspeicher und kann optional auch Firmwar-Update-Funktionalität haben Müller, Sommer, Stegemann 23

24 2.7 Work-Flow-Konzept (Bootloader) und sollten alle Konfigurations- und Diagnosedienste unterstützen. Der Master-Knoten benötigt die Unterstützung des kompletten Diagnose Protokolls. Weiterhin wird das Transport-Protokoll-Handling (Scheduling der Diagnosekommunikation) für Master- und Slave-Knoten definiert. 2.7 Work-Flow-Konzept Eine Besonderheit gegenüber anderen Bussystemen für automobile Anwendungen ist die Spezifizierung eines Work-Flow-Konzeptes und damit die Beschreibung des Designprozessablaufes durch das LIN-Konsortium. Dadurch sollte das Entstehen von herstellerspeziefischen unterschiedlichen Einzellösungen verhindert werden. Das Work-Flow-Konzept wird durch die folgenden drei Teil-Spezifikation beschrieben Node Capability Language Specification Standardisiert eine Syntax zum Beschreiben der Eigenschaften von Slave-Knoten auf Basis der Node Configuration and Identification Specification. Sie stellt die Grundlage zum automatischen Erzeugen eines LDF durch ein Design-Tool dar Configuration Language Specification Beschreibt eine Sprache zum Erstellen des LDF. Das LDF enthält die Konfiguration des kompletten Clusters mit Informationen über die Knoten, die zu Transportierenden Signale (Daten) sowie die Anzahl der Frames innerhalb von Messages und den Aufbau der Scheduling-Tabellen. Die Spezifikation bietet eine Schnittstelle zwischen Entwickler und dem Zulieferer einzelner Knoten und stellt die Grundlage für die Eingabe in Entwicklungs- und Analyse-Tools dar Application Programm Interface Specification Definiert verschiedene Softwareschnittstellen zum vereinfachten Erstellen von Anwendungsprogrammen für LIN-Teilnehmer ohne sich mit den LIN-spezifischen Details beschäftigen zu müssen. Dazu wird ein Satz von C-Funktionen als Schnittstelle definiert. Das Application Programm Interface ist unterteilt in 3 Teile. LIN core API Initialisierung, Steuerung und Wechselwirkung zwischen Anwendung und LIN-Core Müller, Sommer, Stegemann 24

25 2.7 Work-Flow-Konzept LIN node configuration and identification API Stellt Funkionen zum Konfigurieren und Identifizieren der Slave-Knoten durch den Master bereit LIN transport layer API Stellt Funktionen für die Implementierung der Diagnosefunktionalität bereit und steuert die Kommunikation mit einem externen Diagnose-Tool (Tester) LIN-Cluster-Design-Prozess Der spezifizierte Design-Prozess ist in Abb dargestellt und läuft wie folgt ab. In die Node Capability Files Node Configuration File (NCF) werden alle wichtigen Informationen über die einzelnen Knoten des Clusters eingetragen. Abb. 2.17: LIN-Cluster-Design-Prozess (Quelle[LIN06], S. 162) Abb. 2.18: Verarbeitung des Programm- und LIN-Codes zum fertigen Maschinencode Diese sind die Konfiguration des Knotens, die Beziehungen zu anderen Knoten und der Logische Signalverlauf. Das Design Tool erstellt aus den NCF ein LDF und aus diesem generiert das Node Configuration Tool automatisch die benötigten LIN-Funktionen für die einzelnen Knoten. Diesen Sourcecode nennt man LIN node application code. Das LDF wird zusätzlich noch zum Debuggen und Analysieren des Clusters durch einen Bus- Analyzer und -Emulator genutzt (z.b. Timing Analysis). Der LIN node application code wird zusammen mit dem Anwendungscode compiled und gelinkt. Der dabei entstandene Maschinencode wird im entsprechenden Format in den Programmspeicher der einzelnen Busteilnehmer geschrieben (siehe Abb. 2.18). Müller, Sommer, Stegemann 25

26 3 Zusammenfassung und Ausblick 3 Zusammenfassung und Ausblick 3.1 LIN-Bus in der Zusammenfassung Der LIN-Bus wurde für Sicherheitsunkritische Anwendungen konzipiert und dient als Ergänzung zum CAN-Bus (Subbussystem). Da keine Spezial-Hardware notwendig ist, zeichnet sich der LIN-Bus durch geringen Kosten und Implementierungsaufwand aus. Das LIN-Protokoll ist als offener Standard definiert wodurch keine Lizenzgebühren anfallen. Die wichtigsten Eigenschaften der LIN-Technologie werden im Folgenden kurz zusammengefasst. Beim LIN erfolgt die Buszugriffssteuerung nach dem Master/Slave-Prinzip. Jede Kommunikation eines Slave-Knotens wird von einem Master-Knoten initiiert. Das hat den Vorteil, dass die Slaves kostengünstig realisiert werden können. Die Masterfunktionalität übernimmt die Steuereinrichtung, welches meist ein Gateway zum CAN-Bus ist. Als Übertragungsmedium wird eine einfache ungeschirmte Eindrahtverbindung eingesetzt. Elektrische Parameter wie Transceiverkapazität und Spannungspegel werden hingegen vorgeschrieben. Durch diese Kenngrößen wird die Anzahl der Knoten in einem Cluster auf 16 begrenzt. Die Übertragungsrate darf zwischen 1 kbit/s und 20 kbits/s liegen. Das LIN-Protokoll ist byteorientiert und die Datenübertragung erfolgt asynchron. Eine einfache Implementierung des Protokolls auf der in den meisten Mikrocontrollern existierenden seriellen Schnittstelle (UART) ist möglich. In einer Nachricht können 1 bis 8 Datenbyte übertragen werden. Da der LIN-Standard keine Knoten-Adressen, sondern Nachrichten-Identifier (ID), ist neben Punkt-zu-Punkt- auch Broadcast- und Multicastkommunikation möglich. Die Datenübertragung über LIN erfolgt zeitgesteuert. Im Master sind zu diesem Zweck Time-Schedule-Tabellen hinterlegt. In diesen wird definiert, in welchem Zeitschlitz (Time-Slot) welches Datenpaket mit welchem ID übertragen werden muss. Dadurch ist das Systemverhalten deterministisch. Für die Diagnose und Konfiguration bietet der LIN-Bus die Möglichkeit ein weiteres Protokoll auf die Datenbytes aufzusetzen, so dass Nachrichten mit bis zu 4095 Bytes erlaubt. Darüber hinaus ist es damit möglich Nachrichten vom Empfänger zu bestätigen. Müller, Sommer, Stegemann 26

27 3.2 Zukünftige Entwicklung 3.2 Zukünftige Entwicklung Für einfache Komfortanwendungen mit geringen Datenmengen und ohne Sicherheitsrelevanz ist LIN wesentlich günstiger als CAN (vgl. hierzu Abb. 3.1). Hinzu kommt, dass durch Spezifizierung bis hinein in den Design-Prozess der Einsatz von Off-The-Shelf-Knoten möglich und praktikabel ist und dadurch auch die Vergabe von Entwicklungsarbeit an Zulieferer deutlich vereinfacht wird. Dies war auch einer der Gründe für eine sehr schnelle Markteinführung. Weiterhin ist für komplexere Anwendungen mit hohen Datenmengen und Sicherheitsrelevanz der neue Standard Flexray besser geeignet als CAN. Durch die Vielfalt von CAN-Ablegern die in den letzten Jahren entstanden, entwickelte sich in der Automobilindustrie der Bedarf nach einem einheitlichen Standard für einfache mechatronische Anwendungen. Aus diesen Gründen wird erwartet, des sich LIN als Subbus in Zukunft durchsetzt und in diesem Segment Marktanteile vom CAN-Bus abgreift. Doch auch im Zusammenspiel mit Flexray und MOST wird der etablierte CAN-Bus in naher Zukunft nicht vollständig vom Markt verdrängt werden, da er ein erprobtes System mit sehr vielen Anwendungen darstellt und in ihn sehr viel Geld investiert worden ist. Abb. 3.1: Vergleich der Kosten pro Netzwerkknoten von verschiedenen Bussystemen aus dem Automobilbereich (Quelle: [BAD06]) Müller, Sommer, Stegemann 27

28 Literaturverzeichnis Literaturverzeichnis [BAD06] Badstübner, J.: Ende einer Dienstzeit?. In: Automilindustrie : ( ), S. 68f [GRZ05] Grzemba, A.; von der Wense, H.: LIN-Bus - Systeme Protokolle Tests von LIN-Systemen Tools Hardware Applikation. Poing : Franzis Verlag, 2005 [LIN06] LIN Consortium: LIN Specification Package - Revision 2.1, 2006 [VEC09] Vector Informatik GmbH: Einführung in LIN. URL html - Aktualisierungsdatum: Müller, Sommer, Stegemann 28