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.

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.

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

Funktionsweise LIN-Transceiver

Abb. X: LIN-Transceiver MCP2004

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. Es wandelt die TTL-Logik des Mikrocontrollers in die passende LIN-Bus-Logik um und umgekehrt. Dabei wird für die Kommunikation zwischen Mikrocontroller und Transceiver die USART-Schnittstelle genutzt.

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.

---

---

Projektunterlagen

SVN Link einfügen

Literatur

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