Projekt 76: LIN Demonstrator

→ zurück zur Übersicht: WS 18/19: Fachpraktikum Elektrotechnik (BSE)

Autoren: Blunck, Schaffer
Betreuer: Prof. Schneider

Aufgabe

Sensoren und Aktoren eines Kfz sollen über einen LIN BUS angesteuert werden. Visualisieren Sie die Daten mit CANoe.

Erwartungen an die Projektlösung

• Recherche zum LIN BUS
• Beschaffen Sie kostenlos LIN fähige Sensoren und Aktoren aus dem Kraftfahrzeug (Sponsoring, Schrottplatz)
• Ein Arduino mit LIN Shield soll einen Sensor auslesen und einen Aktor ansteuern.
• Überwachen Sie den Datenverkehr mit CANoe.
• Test und wiss. Dokumentation
• Live Vorführung der Kommunikation

Hinweise:

• Dieses Projekt ist nur mit viel Kreativität und Eigeninitiative zu lösen. Sie sollten Spaß an Bussystemen im Kraftfahrzeug haben.
• Dieses Projekt wurde zweifach vergeben. Stimmen Sie sich mit dem anderen Team ab, damit zwei unterschiedliche Demonstratoren entstehen.

Einleitung

In diesem Projekt wird ein LIN - Demonstrator entwickelt und ein Aktor mithilfe des LIN-Protokolls angesteuert. Der LIN - Demonstrator wird mithilfe von ausgewählten Bauteilen aufgebaut. Die verwendeten Bauteile sind in einem nchfolgenden Kapitel dargestellt. Als Aktor wird ein Xenon Scheinwerfer eines Audi Q7 verwendet. Der Xenon Scheinwerfer kann über eine Servomotor in horizontaler und vertikaler Richtung verstellt werden. Als Kommunikatiosnprotokoll wird das LIN-Protokoll verwendet.

Grundlagen LIN - Protokoll

Funktionsweise LIN-Bus

LIN (Local Interconnect Network) ist ein junges Bussystem, das ende der 90er Jahre entwickelt wurde. Es wird für einfache Sensor-Aktor-Anwendungen mit relativ geringen Echtzeitanforderungen verwendet, wie zum Beispiel der Tür-, Sitz- oder Schiebedach-Elektronik oder der Ansteuerung des Scheinwerfers eines Autos. Der LIN-Bus ist die kostengünstige Alternative zu dem Low-Speed-CAN Bussystemen. Auf der Bitübertragungsschicht kommt eine UART-Übertragung(8 Datenbits, 1 Startbit, 1 Stoppbit) zum Einsatz. Mögliche Bitraten liegen im Bereich von 1 bis 20 kbit/s. Das LIN-Bussystem besteht aus einem Master-Knoten, der i.d.R gleichzeitig Gateway zu einem übergeordneten CAN-Netzwerk ist. Alle restlichen Knoten sind Slave-Knoten, die nach Anforderungen des Masters ihre Datenpakete verschicken können. Jeder LIN-Knoten beherbergt in der Software eine Slave Task und der Master Knoten besitzt ebenfalls eine Slave-Task und zusätzlich den Master-Task. Zusätzlich besitzt der Master-Knoten ein LIN-Schedule, was ein hinterlegter Zeitplan ist, in dem festgelegt ist, welcher Slave wann abgefragt werden soll, die sogenannten Frame Slots. Zu Beginn eines Frame Slots sendet der Master den Frame Header, der von dem passenden Slave Task zu einem LIN Frame komplettiert wird.

In der Abbildung 1 ist das LIN-Kommunikationsprinzip dargestellt. Der Master-Knoten sendet den Header auf den Bus. Die Slaves hören den Bus ab und erkennen anhand des Headers, ob sie antowrten müssen oder nicht. Muss ein Slave antworten, fügt seine Response hinter den Header. Zwischen Header und Response befindet sich jeweils ein Response Space und zwischen einer Response und einem Header befindet sich ein Interframe Space. Das sind jeweils willkürliche Bits, die nicht direkt zum LIN-Protokoll gehören.

Der Aufbau eines LIN-Frames ist in der Abbildung 2 dargestellt. Einzuteilen ist das Frame in einen Header und eine Response. Der Header wird von dem Master und die Response von dem Slave erstellt. Im Folgenden wird der genaue Aufbau des LIN-Frames dargestellt.

• Kommunikationsprinzip LIN-Bus
• 

  Abb. 1: LIN Kommunikationsprinzip

• 

  Abb. 2: LIN Frame Struktur

Header

Der Header besteht aus dem Break-Field, dem SYNC-Field und dem Protected-Identifier-Field. Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante-Bits (logisch 0) und anschließen 1 Delimeter-Bit (logisch 1) gesendet. Auf das Break-Field folgt das SYNC-Field. Sync wird definiert als das hexadezimale Zeichen x55. Das Sync-Feld ermöglicht Slave-Geräten, die eine automatische Baudratenerkennung durchführen, die Periode der Baudrate zu messen und ihre interne Baudrate mit dem Bus zu synchronisieren. Das Protected-Identifier-Field ist das letzte, das vom Master-Task im Header übertragen wird. Es identifiziert jede Nachricht im Netzwerk und bestimmt letztendlich, welche Knoten im Netzwerk welche Übertragung empfangen und welche darauf antworten. Alle Slave-Tasks warten ständig auf Identifikatoren, verifizieren ihre Parität und stellen fest, ob sie diesen bestimmten Identifikator ausgeben oder abfragen.

Response

Die Response besteht aus dem Response Space, den data-fields und der checksum. Der Response Space ist wie oben erklärt eine zufällige Bitfolge, die aufgrund des zeitlichen versatzes zwischen dem Header und der Response befindet. Auf den Response Space folgt das data-field. Das Data field besteht aus einem Startbit, 8 Datenbits und einem Stoppbit. Die Übertagung des Datenbits erfolgt über das Little-Endian Prinzip, d.h das LSB(least significant Bit) wird als erstes eingefügt. Es könne bis zu 8 Nutzdatenbytes eingefügt werden. An letzter Stelle der Response befindet sich die Checksum. Die Checksum dient zur Überprüfung der erfolgreichen Übertragung. Mittels Modulo-256-arithmetik wird die Checksum gebildet. Die einzelnen Datenbytes werden per Modulo-256-Arithmetik addiert wobei jedes überlaufende Bit zum jeweiligen Zwischenergebnis addiert wird. Schließlich wird das Gesamtergebnis inverteirt und als Checksum in die Response eingefügt. Ein Empfänger führt denselben Algorithmus bis auf die Invertierung mit den empfangenen Datenbytes durch. Falls die Summe aus den Datenbytes und der Checksum nicht 0xFF ist, hat ein Übertragungsfehler stattgefunden und die Kommunikation muss erneut durchgeführt werden.

http://www.ni.com/white-paper/9733/de/

Funktionsweise LIN-Transceiver

Abb. 3: LIN-Transceiver MCP2004

Beschreibung

Für das Projekt wird der LIN-Transceiver MCP2004 der Firma Microchip verwendet. Dieser Transceiver stellt eine physikalische Schnittstelle zwischen einem Mikrocontroller und einem LIN-Bus dar. Dafür wandelt er die CMOS/TTL-Logik des Mikrocontrollers in die passende LIN-Bus-Logik um und umgekehrt. Für die Kommunikation zwischen Mikrocontroller und Transceiver wird die USART-Schnittstelle genutzt.

Aufbau

Abb. 4: Blockschaltbild des LIN-Transceivers

Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschlussschutz und ein Abschaltmechanismus beim Erreichen von zu hohen Temperaturen verbaut sind.

Weiterführend zeigt die Abb. 5 die Belegung der Anschlusspins am PDIP-Gehäuses.

Abb. 5: Anschlusspins des LIN-Transceivers

• Pin 1: Receive Data Output
• Pin 2: Chip Select
• Pin 3: Fault reporting/TXD Dominant Time-out
• Pin 4: Transmit Data Input
• Pin 5: Ground
• Pin 6: LIN Bus
• Pin 7: Battery Positive
• Pin 8: Voltage Regulator Enable Output

Betriebsarten

Der LIN-Transceiver unterstützt folgende Betriebsarten:

• POWER-DOWN MODE
• READY MODE
• OPERATION MODE
• TRANSMITTER OFF MODE

Projektdurchführung

Verwendete Bauteile

Anzahl	Bauteil
2	12 V DC Netzteil
2	Arduino Uno
1	Audi Q7 Scheinwerfer
1	Steckbrett
1	Steckbrücken-Drahtbrücken Set
1	Motor Stepper Servo Shield
2	LIN-Transceiver
2	220 kOhm Widerstände
2	4.7 kOhm Widerstände
2	50 Ohm Widerstände
2	1 kOhm Widerstände
2	100 nF Kondensator
2	220 pF Kondensator
2	1 µF Kondensator
4	Standarddiode 1N4148

Scheinwerfer als LIN fähigen Aktor

---

Im Folgendem Abschnitt wird ein Versuchsaufbau erläutert, um den Scheinwerfer für das Projekt als LIN fähigen Aktor verwenden zu können. Dafür wird zunächst der Aufbau des Scheinwerfers beschrieben und ein Versuch für die Ansteuerung erklärt.

Anschlussplan

• Anschlussplan des Scheinwerfers
• 

  Abb. 6: LIN Kommunikationsprinzip

• 

  Abb. 7: Stecker für die Schrittmotoren

Versuchsaufbau "Erste Inbetriebnahme"

In diesem Kapitel ist der Versuchsaufbau zum Ansteuern des Audi Q7 Scheinwerfers dargestellt. Die Abbildung 8 enthält hinzu die Beschriftung der einzelnen Bauteile.

• Anschlussplan des Scheinwerfers
• 

  Abb. 8: Versuchsaufbau Scheinwerfer

• 

  Abb. 9: Schaltplan Versuchsaufbau

Damit der Scheinwerfer als Aktor eingesetzt werden kann, wurde dieser zunächst in Betrieb genommen. Dafür wurden die Anschlüsse (Abb. 6 u. 7) für die Spannungsversorgung und die Schrittmotoren identifiziert. Anschließend folgte der Aufbau der ersten Inbetriebnahme nach dem Schaltplan aus Abb. 9.

Versuchsdurchführung

Zu Beginn des Versuchs wurde der Xenon-Brenner an die Spannungsversorgung angeschlossen. Damit der Xenon-Brenner jedoch korrekt betrieben werden kann, wird ein Netzteil mit 12 V DC und 10 A benötigt, da beim Einschaltvorgang eine höhere Stromaufnahme (etwa 8 A) vorliegt als im weiteren Betrieb (etwa 3,5 A). Nachdem die Funktionsfähigkeit des Xenon-Brenners bestätigt werden konnte, wurden die Anschlüsse für das Fernlicht und für den Blinker an die Spannungsversorgung angeschlossen. Auch hier konnte eine erfolgreiche Inbetriebnahme festgehalten werden. Im nächsten Schritt wurde die Verstellung des Kurvenlichts getestet. Dafür kam ein Arduino Uno mit Motor-Shield zum Einsatz, weil die Schrittmotoren für die vertikale und horizontale Verstellung angesteuert werden mussten. Das Motor-Shield hat die Möglichkeit zwei verschiedene Schrittmotoren anzusteuern und diese bei Bedarf mit einer externen Spannungsquelle zu versorgen. Der Schaltplann in Abb. 9 zeigt die Verkabelung für die jeweiligen Schrittmotoren.

Kommunikation zweier Arduinos über LIN-Bus

---

• Einfügen: Arduino Programm
• PAP

Versuchsaufbau

• Versuchsaubau Test LIN-Nachricht
• 

  Abb. 10: Versuchsaufbau Kommunikation Schaltungsaufbau

• 

  Abb. 11: Versuchsaufbau Kommunikation Oszilloskop

• 

  Abb. 12: Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt

Ansteuerung des Kurvenlichts über LIN-Bus

---

Versuchsaufbau

Abb. 13: Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator

Projektunterlagen

SVN Link einfügen

Weblinks

Datenblatt LIN-Transceiver MCP2004

Literatur

--- → zurück zur Übersicht: WS 18/19: Fachpraktikum Elektrotechnik (MTR)