Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer

 
Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer
Ausarbeitung

Local Interconnect Network
           (LIN)

       Denis Müller (761422)
      Dirk Sommer (760422)
   Sebastian Stegemann (760391)

        13. November 2009
Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer
LIN-BUS                                                                  Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einführung                                                                                     4
  1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                 4
  1.2 Geschichtliche Entwicklung . . . . . . . . . . . . . . . . . . . . . . .                   5

2 LIN     Specification                                                                           7
  2.1     Kommunikationsprinzip . . . . . . . . . . . . . . . . . . .        .   .   .   .   .    7
  2.2     Aufbau eines LIN-Knotens . . . . . . . . . . . . . . . . . .       .   .   .   .   .    8
  2.3     Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . .   .   .   .   .   .    8
          2.3.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .    8
          2.3.2 Grundstruktur eines LIN-Transceiver . . . . . . . .          .   .   .   .   .    9
   2.4    Protocol Specification . . . . . . . . . . . . . . . . . . . . .   .   .   .   .   .   10
          2.4.1 Frameaufbau . . . . . . . . . . . . . . . . . . . . .        .   .   .   .   .   10
          2.4.2 Zeitsteuerung . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   14
          2.4.3 Frametypen . . . . . . . . . . . . . . . . . . . . . .       .   .   .   .   .   14
          2.4.4 Network Management . . . . . . . . . . . . . . . .           .   .   .   .   .   17
          2.4.5 Fehlererkennung . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   18
          2.4.6 Fehlerbehandlung . . . . . . . . . . . . . . . . . . .       .   .   .   .   .   20
   2.5    Transport Layer . . . . . . . . . . . . . . . . . . . . . . . .    .   .   .   .   .   20
          2.5.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   20
          2.5.2 PDU Structure . . . . . . . . . . . . . . . . . . . .        .   .   .   .   .   20
   2.6    Konfiguration und Diagnose . . . . . . . . . . . . . . . . .       .   .   .   .   .   22
          2.6.1 Node Configuration and Identification Specification          .   .   .   .   .   22
          2.6.2 Diagnostic Specification . . . . . . . . . . . . . . .       .   .   .   .   .   23
   2.7    Work-Flow-Konzept . . . . . . . . . . . . . . . . . . . . . .      .   .   .   .   .   24
          2.7.1 Node Capability Language Specification . . . . . .           .   .   .   .   .   24
          2.7.2 Configuration Language Specification . . . . . . . .         .   .   .   .   .   24
          2.7.3 Application Programm Interface Specification . . .           .   .   .   .   .   24
          2.7.4 LIN-Cluster-Design-Prozess . . . . . . . . . . . . .         .   .   .   .   .   25

3 Zusammenfassung und Ausblick                                                                   26
  3.1 LIN-Bus in der Zusammenfassung . . . . . . . . . . . . . . . . . . .                       26
  3.2 Zukünftige Entwicklung . . . . . . . . . . . . . . . . . . . . . . . .                     27

Literaturverzeichnis                                                                             28

Müller, Sommer, Stegemann                                                                         2
Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer
LIN-BUS                                                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
Local Interconnect Network - Ausarbeitung Denis Müller (761422) Dirk Sommer
LIN-BUS                                                                 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 Elektroni-
fizierung 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 un-
terschiedliche Kabelbaum- und Steckervarianten erforderlich macht, was wiederum

Müller, Sommer, Stegemann                                                           4
LIN-BUS                                                 1.2 Geschichtliche Entwicklung

die Produktion, Installation und Wartung erheblich erschwerte.“1 Aus Kostengrün-
den 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 einheit-
licher Standard vorgegeben, welcher den entstandenen „Wildwuchs“ der Subbuspro-
tokolle eindämmen sollte. Mit der Entwicklung des LIN-Busses wurde eine einfache
und kostengünstige Ergänzung hierarchischer Kfz-Netzwerke für sicherheitsunkriti-
sche Anwendungen konzipiert.
   Inzwischen wird er weltweit in sehr vielen Fahrzeugen eingesetzt. Typische An-
wendungen sind bisher im Komfortbereich des Kfz: Klima-, Sitz-, Tür- und Spiegel-
steuerung. Die typische LIN-Vernetzung ist in Abbildung 1.1b am Beispiel einer Tür-
steuerung 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 Sensorsi-
gnalen. 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 Syste-
me. Dies führte daraufhin zur Gründung einer Arbeitsgruppe, dem LIN-Konsortium
durch die Firmen DaimlerChrysler, BMW, Audi, Volkswagen, Volcano Communica-
tion 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 er-
schienen 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
LIN-BUS                                               1.2 Geschichtliche Entwicklung

                     Abb. 1.2: Zeitstrahl der LIN-Entwicklung

   In den Folgejahren bekannten sich die wichtigsten europäischen Automobilher-
steller eindeutig zum LIN-Bus als Subbus für mechatronische Applikationen. Die
Spezifikation 1.3 erschien im Jahre 2001. Bei dieser wurde die Bitübertragungs-
schicht ü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 sogenann-
ten 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
LIN-BUS                                                                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 meh-
rere 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

                Empfangs-     Sende-               Senderoutine
                 routine      routine                (Header)

                Slave-Task Master                 Master-Task
              Master
                                                              LIN-Bus

                Empfangs-     Sende-          Empfangs-      Sende-
                 routine      routine          routine       routine

               Slave-Task A                   Slave-Task B
              Slave A                        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
LIN-BUS                                                 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 ausge-
      Input     Microcontroller    Output   führt sein, sondern können auch in ei-
                   (Application)
                                            nem Chip integriert werden. Die Halb-
                                            leiterhersteller bieten verschieden Lö-
                LIN-Controller              sungen mit unterschiedlichen Integrati-
                    (Protocol)
                                            onsstufen an.
                                               Die Aufgabe des LIN-Transceivers ist
               LIN-Transceiver              unter Anderem die Wandlung von logi-
                 (Physical Layer)
                                            schen Pegeln auf die physikalischen Pe-
                                            gel und entspricht demnach dem Physi-
                                  LIN       cal Layer (Bitübertragungsschicht).
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 an-
wendungsbezogene Aufgaben erledigen muss. Dazu könnte z. B. das Abfragen von
Sensoren oder das Steuern von Aktoren gehören.

2.3 Physical Layer
2.3.1 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
LIN-BUS                                                              2.3 Physical Layer

Linie realisiert ist.1 Die Fahrzeugmasse dient dabei als Rückleiter. Um dennoch aus-
reichend Störfestigkeit sicher zu stellen, wird für den High-Pegel, die Versorgungs-
spannung 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(VSU P ) ziehen.
Der High-Pegel muss mindestens bei 80% der Versorgungsspannung auf der Sender-
seite 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)

2.3.2 Grundstruktur eines LIN-Transceiver
                                      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 lie-
                                      gen, wird die maximale Anzahl an Teilnehmer
                                      auf 16 begrenzt.
                                        Da es sich beim LIN-Bus um eine unge-
                                      schirmte Eindrahtleitung handelt, wurde die
Abb. 2.4: Grundprinzip des LIN-       Baudrate auf maximal 20 kHz begrenzt und
Transceiver (Quelle: [GRZ05], S. 107) die minimale Anstiegs- und Abfallzeit der
                                      Flanken vorgeschrieben. Dadurch wird unter
anderem verhindert, dass die Leitung abstrahlt. Die Baudrate kann ab 1 kHz ein-
gestellt 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
LIN-BUS                                                               2.4 Protocol Specification

üblich sind.1
  Darüber hinaus werden in der LIN-Spezifikation noch weitere Vorgaben, Eigen-
schaften 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 umzuset-
zen.

2.4 Protocol Specification
In der Protocol Specification wird das Verhalten auf dem Bus, wie z. B. die Über-
mittlung und der Aufbau der Frames sowie das Verhalten der Knoten wie z. B. das
Network Management beschrieben.

2.4.1 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
                                                 Response space

            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 UART-
kompatibel. 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
LIN-BUS                                                      2.4 Protocol Specification

  Zum Erzeugen des Break Fields wird in der Regel die Baudrate temporär herun-
tergesetzt 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 signa-
lisieren. Dazu sendet der Master-Task mindestens 13 Low-Bits. Der Slave muss
mindestens 11 davon erkennen. Nur durch das Übertragen von mindestens 13 do-
minanten Bits ist gewährleistet, dass jeder LIN-Slave den Start einer Datenüber-
tragung 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 Verwen-
dung der seriellen Schnittstelle mit einem dominanten Startbit beginnt.

Sync Field
Das Sync Field dient den LIN-Slaves zur Einstellung eines netzwerkweit einheitli-
chen 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 Flan-
ken 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 Über-
tragung 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
LIN-BUS                                                                  2.4 Protocol Specification

                                            Sync field
                                         8 Tbit

                 2 Tbit         2 Tbit            2 Tbit   2 T bit

              start   0     1        2       3         4   5         6   7    stop
               bit                                                            bit

              Abb. 2.7: Aufbau des Sync Fields (Quelle: [LIN06], S. 111)

nen sich die empfangenden Slaves auch innerhalb eines LIN-Frames nachzusynchro-
nisieren.

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-Ver-
knüpfung der ID-Bits. Die beiden Paritätsbits ergeben sich wie folgt:

     P 0 = ID0 ⊗ ID1 ⊗ ID2 ⊗ ID4

     P 1 = ¬(ID1 ⊗ ID3 ⊗ ID4 ⊗ ID5)

Data Bytes
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
LIN-BUS                                                                           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                                                                         Stop
                          ID0     ID1    ID2     ID3    ID4      ID5        P0        P1
                 bit                                                                           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 de-
nen 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 einge-
setzt, das heißt der Übertrag der 8-Bit-Addierung wird zum LSB des Zwischenergeb-
nisses hinzuaddiert. Die Gesamtsumme wird anschließend invertiert. Das nachfol-
gende 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              0     1        0      0        1         0      1      0

            +0x55 =             0x9F      0       1     0        0      1        1         1      1      1
       (Übertrag addieren)      0x9F              1     0        0      1        1         1      1      1
            +0x93 =             0x132     1       0     0        1      1        0         0      1      0
        Übertrag addieren       0x33              0     0        1      1        0         0      1      1
            +0xE5 =             0x118     1       0     0        0      1        1         0      0      0
        Übertrag addieren       0x19              0     0        0      1        1         0      0      1
           invertieren          0xE6              1     1        1      0        0         1      1      0

           Empfänger:
           0x19+0xE6 =          0xFF              1     1        1      1        1         1      1      1

          Tab. 2.2: Beispiel der Checksummenberechnung (Vgl. [LIN06], S. 52)

Müller, Sommer, Stegemann                                                                                     13
LIN-BUS                                                   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.

2.4.2 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.

2.4.3 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 not-
wendig 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
LIN-BUS                                                     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
LIN-BUS                                                       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 Unconditio-
nal 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 Re-
sponse, 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 durch-
gefü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 kundenspezi-
fische Erweiterungen. Bei diesen User-defined Frames gibt es keine definierte Fra-
melä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
LIN-BUS                                                             2.4 Protocol Specification

2.4.4 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

                                                          Initialisierung beendet
                Wake-up Befehl                                    [< 100 ms]

                                   Got-to-Sleep-Befehl
                                          oder
                                   Bus 4 - 10 s inaktiv
                 Bus Sleep Mode                              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
LIN-BUS                                                                            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 mindes-
tens 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 - 250 ms   250 µs - 5 ms   150 ms - 250 ms    250 µs - 5 ms

          Abb. 2.13: Ein Block von Wake-Up-Bfehlen (Quelle: [LIN06], S. 45)

2.4.5 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
LIN-BUS                                                    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 emp-
fangen 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 Versorgungs-
spannung verursacht werden, sowie durch parasitäre Impedanzen. Der Buspegel ist
dadurch dauerhaft auf einem Low- bzw. High-Pegel.

Müller, Sommer, Stegemann                                                         19
LIN-BUS                                                             2.5 Transport Layer

2.4.6 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
2.5.1 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.

2.5.2 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

                     NAD    PCI RSID    D1    D2   D3   D4   D5   PCI-type = SF
          Response

                     NAD    PCI   LEN RSID    D1   D2   D3   D4   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
LIN-BUS                                                           2.5 Transport Layer

NAD
Die Node Address for Diagnose (NAD) ist eine vom Hersteller vergebene Knote-
nadresse, 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      0     0      0      0              Length
              FF      0     0      0      1            Length/256
              CF      0     0      1      0         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 Ser-
vice 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
LIN-BUS                                                      2.6 Konfiguration und Diagnose

2.6 Konfiguration und Diagnose
2.6.1 Node Configuration and Identification Specification
Um innerhalb eines LIN-Clusters Konflikte zwischen einzelnen Slave-Knoten zu ver-
hindern, 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                     ROM or NVRAM
                       Serial number
                                                              NAD       PIDs
                  Supplier ID Function ID     Variant

                                                            ld_set_configuration
            e.g. pin configuration                            VRAM
                Initial NAD           Instance generation
                                                              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
LIN-BUS                                               2.6 Konfiguration und Diagnose

Knoten (z. B. intelligente Sensoren gleichen Typs) innerhalb eines Clusters vorhan-
den 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 Iden-
tifier (SID) spezifiziert z.B. Assign NAD, Read by Identifier, Save Configuration
usw.

2.6.2 Diagnostic Specification
Die Diagnose eines Bussystems ist ein wichtiges Hilfsmittel zur manuellen und auto-
matischen Lokalisierung von Fehlern innerhalb der Bordelektronik eines Fahrzeugs.
In der Diagnostic Specification sind Methoden zum Übertragen von Diagnoseda-
ten 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 Diagnosefunktiona-
lität nicht spezifiziert sind und in der Anwendungsschicht (meist in einem überge-
ordneten 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 Quel-
ladresse 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-Funktio-
      nalität haben. Dies liegt vor wenn z. B. Sensordaten ausgewertet und darauf-
      hin 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
LIN-BUS                                                       2.7 Work-Flow-Konzept

     (Bootloader) und sollten alle Konfigurations- und Diagnosedienste unterstüt-
     zen. Der Master-Knoten benötigt die Unterstützung des kompletten Diagnose
     Protokolls.

 Weiterhin wird das Transport-Protokoll-Handling (Scheduling der Diagnosekom-
munikation) 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 be-
schrieben.

2.7.1 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.

2.7.2 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 Transportie-
renden Signale (Daten) sowie die Anzahl der Frames innerhalb von Messages und
den Aufbau der Scheduling-Tabellen. Die Spezifikation bietet eine Schnittstelle zwi-
schen Entwickler und dem Zulieferer einzelner Knoten und stellt die Grundlage für
die Eingabe in Entwicklungs- und Analyse-Tools dar.

2.7.3 Application Programm Interface Specification
Definiert verschiedene Softwareschnittstellen zum vereinfachten Erstellen von An-
wendungsprogrammen für LIN-Teilnehmer ohne sich mit den LIN-spezifischen De-
tails 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
LIN-BUS                                                       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 Diagno-
        sefunktionalität bereit und steuert die Kommunikation mit einem externen
        Diagnose-Tool (Tester)

2.7.4 LIN-Cluster-Design-Prozess
Der spezifizierte Design-Prozess ist in Abb. 2.17 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)

                                    Diese sind die Konfiguration des Knotens, die
                                 Beziehungen zu anderen Knoten und der Logi-
                                 sche 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 applica-
                                 tion code.
                                    Das LDF wird zusätzlich noch zum Debuggen
                                 und Analysieren des Clusters durch einen Bus-
Abb. 2.18: Verarbeitung des
                                 Analyzer und -Emulator genutzt (z.B. Timing
Programm- und LIN-Codes zum      Analysis).
fertigen Maschinencode              Der LIN node application code wird zusam-
                                 men 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
LIN-BUS                                              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 Lizenzge-
bü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 Mas-
terfunktionalitä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 Kno-
ten 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 Mikrocon-
trollern 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 Zeit-
schlitz (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 wei-
teres 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
LIN-BUS                                                  3.2 Zukünftige Entwicklung

3.2 Zukünftige Entwicklung
Für einfache Komfortanwendungen mit geringen Datenmengen und ohne Sicher-
heitsrelevanz 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 Si-
cherheitsrelevanz 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 Zusam-
menspiel 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 Bussyste-
 men aus dem Automobilbereich (Quelle: [BAD06])

Müller, Sommer, Stegemann                                                        27
LIN-BUS                                                         Literaturverzeichnis

Literaturverzeichnis
[BAD06] Badstübner, J.: Ende einer Dienstzeit?. In: Automilindustrie : (2006-03),
   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 http://www.vector-elearning.com/vl_einfuehrunglin_de„376493.html -
   Aktualisierungsdatum: 05.11.2009

Müller, Sommer, Stegemann                                                        28
Sie können auch lesen
NÄCHSTE FOLIEN ... Stornieren