Projekt 76: LIN Demonstrator: Unterschied zwischen den Versionen

Aus HSHL Mechatronik
Zur Navigation springen Zur Suche springen
Zeile 292: Zeile 292:


== Ergebnis ==
== Ergebnis ==
<gallery class="center" widths="600" heights="500">
File:Finaler Versuchsaufbau.png|Abb. 27: Funktionstest der Platinen
</gallery>
Das Ergebnis ist am besten in dem folgenden Video zu sehen


== Zusammenfassung ==
== Zusammenfassung ==

Version vom 10. Januar 2019, 20:35 Uhr


→ 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 nachfolgenden Kapitel dargestellt. Als Aktor wird ein Xenon Scheinwerfer eines Audi Q7 verwendet. Der Xenon Scheinwerfer kann über einen Schrittmotor in horizontaler und vertikaler Richtung verstellt werden. Als Kommunikationsprotokoll wird das LIN-Protokoll verwendet, um Nachrichten zwischen zwei Mikrocontroller zu versenden. Die Mikrocontroller (Arduino Uno) dienen dabei stellvertretend als Steuergeräte.

Grundlagen LIN - Protokoll

In diesem Kapitel werden einige Grundlagen zum Verständnis dieses Projektes erläutert. Für dieses Projekt muss die Funktionsweise und der Aufbau des LIN-Bus bekannt sein. Hinzu muss für diese Kommunikation die Zweidrahtkommunikation des Arduinos auf eine 1-Draht kommunikation umgewandelt werden, wofür der LIN-Transceiver benötigt wird.

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

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 des Arduino Unos genutzt.

Der LIN-Transceiver MCP2004 hat folgende Eigenschaften:

  • Kompatibel mit LIN-Bus-Spezifikationen 1.3, 2.0, 2.1, SAE J2602
  • Unterstützung von Baudraten bis zu 20Kbaud
  • Schutz gegen 43V Spannungsspitzen (bspw. Lastabwurf bei der Lichtmaschine)
  • ESD & EMI geschützt
  • Versorgungsspannung: 6.0V bis 27.0V
  • Temperaturbereich: -40°C bis +125°C

Aufbau

Abb. 4: Blockschaltbild des LIN-Transceivers
Abb. 4: Blockschaltbild des LIN-Transceivers

Das Blockschaltbild visualisiert den inneren Aufbau des Transceivers. Dabei fällt auf, dass diverse Absicherungen, wie ein Kurzschluss-Schutz und ein Abschaltmechanismus, beim Erreichen von zu hohen Temperaturen, verbaut sind. Der LIN-Bus Pin ist gegen Kurzschlüsse und Verlust des Erdpotentials (Ground) gesichert. Intern ist dieser mit einer Diode und einem Pull-Up-Widerstand versehen.

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

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

Abb. 6: Zustandsdiagramm der Betriebsarten
Abb. 6: Zustandsdiagramm der Betriebsarten

Damit der Transceiver Daten zwischen Mikrocontroller und dem LIN-Bus vermitteln kann, ist es notwendig den PIN 2 (Chip Select / CS) auf "High" zu setzen. Dafür kann ein digitaler Pin oder die 5V Spannung vom Arduino eingesetzt werden. Der Tranceiver bleibt dadurch im Modus "Operation Mode" und lässt den Transmitter durchgängig aktiv. Dieser Vorgang wird jedoch nur für dieses Projekt angewandt und sollte für andere Anwendungen entsprechend angepasst werden.

Anwendung

Um mit Hilfe des Transceivers Daten senden zu können, wird dieser wie in der Schaltung aus Abb. 7 mit einem Mikrocontroller verbunden. Die Abb. 8 zeigt das LIN-Netzwerk, welches einen Master und mehrere Slaves enthält. Dabei ist jedoch darauf zu achten, dass nach der LIN-Spezifikation 2.1 die Transceiver aller Geräte im Netzwerk durch den LIN-Pin und das Erdpotential (Ground) miteinander verbunden sind. Insgesamt sollte das Netzwerk einen maximalen Abschlusswiderstand zwischen Lin-Bus und Batteriespannungsversorgung von 510 Ohm aufweisen. Die 510 Ohm entsprechen einem Netzwerk von einem Master und 15 Slaves.

Projektdurchführung

In diesem Kapitel wird die eigentliche Projektdurchführung des Projekts beschrieben. Nach und nach werden die einzelnen Testergebniss bis zum fertigen Endergebnis dargestellt.

Projektplan

Der für unser Projekt verwendete Projektplan ist in der Abbildung 9 dargestellt und wird nun erläutert.

Die als Raute dargestellten Ereignisse sind Meilensteine, wie zum Beispiel die Abschlussmesse oder der Erhalt der Bauteile. Hinzu war es uns sehr wichtig während des gesamten Semesters kontinuierlich zu arbeiten, was zum Beispiel an der Dokumentation oder der Recherche zu sehen ist. Es kann gesagt werden, dass wir anhand des Projektplans unser Projekt zeitlich passend fertigstellen konnten. Unsere Einteilung des Projektes zu Beginn konnte kontinuierlich abgearbeitet werden.

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

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.

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


In diesem Kaptitel wird die Kommunikation über einen LIN-Bus mit 2 Arduinos (Master und Slave) getestet. Zu Beginn wird der Programmablaufplan mithilfe eines PAP-Designs grafisch dargestellt und anschließend wird dargestellt, wie die Kommunikation Programmtechnisch umgesetzt ist. Anschließend wird der Versuchsaufbau mit der Versuchsdurchführung erläutert. Abschließend werden zwei LIN-Shields entwickelt, auf denen die Schaltungen des Masters und des Slaves platziert werden sollen.

Versuchsaufbau

In den Abbildungen 10 bis 12 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 11 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.

Test der Kommunikation

Zuerst wurde lediglich der Master(Arduino in Abbildung 10) getestet. Von dem Master werden die Werte 99 und 123 mithilfe der ersten beiden Datenbytes auf den LIN Bus gelegt. Das Ergebnis lässt sich in der Abbildung 11 sehen. Das gemessene Signal am Oszilloskop zeigt das typische Muster eines LIN-Protokolls. Zuerst werden in unserem Beispiel 16 dominante Bits (logisch 0 - ca. 1V) gesendet. Die rezessiven Bits (1) entsprechen ca. 12V, die an dem Bord und somit an den LIN-Transceivern angelegt werden. Mithilfe des in der Abbildung 12 dargestellten Versuchsaufbaus ist es nun möglich ziwschen dem rechten Arduino (Master) und dem linken Arduino (Slave) zu kommunizieren. Der LIN-Bus ist das grüne Kabel. Mit diesem Ergebnis wird nun in dem nächsten Kapitel der Audi Q7 Scheinwerfer mithilfe des LIN Protokolls angesteuert.

Ansteuerung des Kurvenlichts über LIN-Bus


In diesem Kapitel wird die eigentliche Aufgabe dieses Projektes durchgeführt. Mithilfe des LIN-Protokolls wird der Schrittmotor des Xenon Brenners angesteuert und die Kommunikation zwischen dem Master und Slave des LIN-Bus mithilfe von CANoe überwacht.

Programmablaufplan Master und Slave

In diesem Kapitel sind jeweils die beiden Programmablaufpläne des Masters und des Slaves dargestellt. Zuerst sendet der Master ein festgelegtes Datenpaket an den Slave. Der Slave überprüft das Datenpaket mithilfe der Checksumme auf Richtigkeit. War die Datenübertagung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beipiel wird der Scheinwerfer nacheinander um 100 Einhieten nach links, um 100 nach unten, um 100 einheiten nach rechts und um 100 einheiten nach oben angesteuert. Somit bewegt sich der Scheinwerfer in einem Quadrat.

Software Programm

Das Programm, dass auf dem Master und auf dem Slave ausgeführt wird, kann unter dem nachfolgenden SVN-Link eingesehen werden:

SVN-LINK Arduino Programm

Versuchsaufbau

Abb. 19: Versuchsaufbau Ansteuerung Kurvenlicht LIN Demonstrator





























Versuchsdurchführung

Überwachen des Datenverkehrs mit CANoe

Entwicklung eines LIN-Shields

In diesem Kapitel werden 2 LIN-Shields entworfen, eins für den Master des Stechbretts aus der Abbildung 12 und eins für Slave aus der Abbildung 12. Zu Beginn wird der Versuchsaufbau dargestellt und der die Durchführung des Versuchs erläutert.

Platinenlayout
  • Beschreibung
  • Beschreibung
Funktionstest der Platinen
  • Beschreibung

Ergebnis

Das Ergebnis ist am besten in dem folgenden Video zu sehen

Zusammenfassung

Lessons Learned

Ausblick

Projektunterlagen

Sämtliche in diesem Projekt verwendeten Unterlagen und Dokumente sind im SVN unter dem nachfolgenden Link einzusehen:

SVN-Link LIN-Demonstrator

YouTube Video

Weblinks

Datenblatt LIN-Transceiver MCP2004

Aufbau LIN Nachricht

Literatur

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