Projekt 76: LIN Demonstrator

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

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

---

Versuchsaufbau "Erste Inbetriebnahme"

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

Abb.5: Versuchsaufbau Scheinwerfer

<br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\> <br\>

---

---

Projektunterlagen

SVN Link einfügen

Weblinks

Datenblatt LIN-Transceiver MCP2004

Literatur

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