Projekt 76: LIN Demonstrator: Unterschied zwischen den Versionen

Version vom 17. Januar 2019, 16:23 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-Busses 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, welches 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 Schiebedachelektronik 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, 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 antworten müssen oder nicht. Muss ein Slave antworten, fügt er 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. Das Break-Field besteht aus mindestens 13 Bits und signalisiert den Start des LIN-Frames. Es werden 13 dominante Bits (logisch 0) und anschließend 1 Delimeter-Bit (logisch 1) gesendet. Auf das Break-Field folgt das SYNC-Field. Das SYNC-Field wird definiert als das hexadezimale Zeichen x55. Das Sync-Field 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 Datenpaket, 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, dem 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 Übertragung der Datenbytes erfolgt über das Little-Endian Prinzip, d. h das LSB (least significant Bit) wird als Erstes eingefügt. Es können 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

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

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

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

Abb. 7: Schaltplan zur Anwendung
Abb. 8: Aufbau eines LIN-Netzwerks

Um mithilfe 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 Testergebnis bis zum fertigen Endergebnis dargestellt.

Projektplan

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

Abb. 9: Projektplan

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 Scheinwerfer

In diesem Kapitel ist der Anschlussplan des Scheinwerfers dargestellt. Die verschiedenen Pins für die Spannungsversorgung sind in der Abbildung 10 und die Zuweisungen der verschiedenen Spulenpaare des Motortreibers zum Ansteuern des Servomotors sind in der Abbildung 11 dargestellt.

Anschlussplan des Scheinwerfers
Abb. 10: Buchse für Spannungsversorgung
Abb. 11: Stecker für die Schrittmotoren

Anschlussplan Schrittmotor-Shield

Phillip

Versuchsaufbau "Erste Inbetriebnahme"

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

Anschlussplan des Scheinwerfers
Abb. 12: Versuchsaufbau Scheinwerfer
Abb. 13: Schaltplan Versuchsaufbau

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

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 Schaltplan in Abb. 13 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 14 bis 16 sind der Versuchsaufbau für das Testen der Kommunikation zwischen dem Master und dem Slave dargestellt. In der Abbildung 15 ist die LIN-Nachricht mit einem Osilloskop aufgenommen worden.

Versuchsaubau Test LIN-Nachricht
Abb. 14: Versuchsaufbau Kommunikation Schaltungsaufbau
Abb. 15: Versuchsaufbau Kommunikation Oszilloskop
Abb. 16: Versuchsaufbau Kommunikation zwischen Master und Slave Zuschnitt

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 ist in der Abbildung 11 zu 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 zwischen 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übertragung ohne Fehler, so steuert der Slave das Kurvenlicht des Scheinweifers in Abhängigkiet des gesendetem Datenpakets an. In unserem Beispiel wird der Scheinwerfer nacheinander um 100 Einheiten 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.

Programmablaufpläne
Abb. 17: Programmablaufplan Master
Abb. 18: Programmablaufplan Slave

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 und Versuchsdurchführung

Der Versuchsaufbau zum Ansteuern des Kurvenlichts wird in diesem Kapitel erklärt und ist in der Abbildung 19 zu sehen. An dem Scheinwerfer und an den Anschlüssen des Steckbretts werden 12V angelegt. Die Spannung von 12V wird an dem Steckbrett angelegt, da die LIN-Transceiver bzw. der LIN-Bus mit dieser Spannung betrieben werden muss. Die Arduinos erhalten die Betreibsspannung über den USB-Anschluss des angeschlossen PCs. Der Master-Arduino sendet die einestellte Nachricht auf den LIN-Bus und der Slave setzt diese Nachricht um. Der Scheinwerfer wird nun über einen Motortreiber von dem Slave angesteuert. Als weiteres Vorgehen steht nur noch die Entwicklung der LIN-Shields aus. Nach Fertigung der Shields müssen sie nur noch final getestet werden.

Überwachen des Datenverkehrs mit CANoe

In diesem Kapitel ist die Inbetriebnahme der Vector Software zum Überwachen des Datenverkehrs dargestellt. Hierzu muss der LIN-Bus mithilfe des in der Abbildung 20 dargestellten Steckers an den PC mit der installierten Software angeschlossen werden. Die Pinbelegung des Steckers kann unter dem folgenden Link eingesehen werden: https://assets.vector.com/cms/content/products/VN16xx/docs/VN1600_Interface_Family_Manual_DE.pdf

CANoe
Abb. 20: Anschlussstecker CANoe
Abb. 21: Ergebnis Überwachung mit CANoe

Die Datenverkehrüberwachung konnte nicht vollständig durchgeführt werden, da wie in der Abbildung 21 dargestellt ein Fehler beim Auslesen auftrat. Der beschriebene Fehler besagt, dass das Delimeter Feld eine inkorrekte Länge hat. Da wir die Baudrate beim Arduino gesenkt haben, um mindestens 13 dominante Bits als Break zu senden ist das Delimeter Feld folglich zwei rezessive Bits anstatt einem rezessiven Bits. Somit kann die Software keine zu 100% exakte LIN-Nachricht erkennen und zeigt deswegen Fehler an. Dieses Problem zu lösen erfordert weitere Änderungen an dem Protokoll, was den Aufwand überschreiten würde.

Entwicklung eines LIN-Shields

In diesem Kapitel werden die, für das Projekt geforderten, Platinen beschrieben. Eine Platine dient dabei als Arduino-Shield für den Master, welches der Schaltung auf dem Steckbrett aus der Abbildung 16 entspricht. Die andere Platine wird für den Slave verwendet und die entsprechende Schaltung kann aus der Abbildung 16 entnommen werden. Um das Vorgehen zu erläutern wird zu Beginn der Versuchsaufbau dargestellt und die Durchführung des Versuchs erklärt.

Platinenlayout

Master LIN-Shield
Abb. 22: 3D-Ansicht Master Shield-Entwurf
Abb. 23: Master Shield-Entwurf Unterseite
Abb. 24: Fertig bestücktes Master Shield

Da eine Anforderung, die Entwicklung eines LIN-Shields für den Arduino, war, wurde für den "Arduino Uno Rev 3" ein passendes Shield mit Hilfe der Software "Ultiboard" entworfen und im Anschluss mittels Fräsmaschine die Platine gefertigt. Die Schaltung entspricht dabei der gleichen, wie aus der Abbildung 16, sodass sichergestellt werden konnte, dass die Schaltung funktionsfähig ist. Die Bauteile wurden vom Steckbrett auf die Platine gelötet und der Transceiver auf einen Sockel gesteckt. Dies hat den Vorteil, dass bei fehlerhafter Bedienung der Transceiver gewechselt werden kann. Außerdem wurden Stiftleisten verbaut, damit das Shield auf den Arduino gesteckt werden kann. Das Shield besitzt des Weiteren Pin-Anschlüsse für die externe Verkabelung (Spannungsversorgung, LIN-Bus).

Slave LIN-Shield
Abb. 25: 3D-Ansicht Slave Shield-Entwurf
Abb. 26: Slave Shield-Entwurf Unterseite
Abb. 27: Fertig bestücktes Slave Shield

Im Gegensatz zu den Master konnte für den Slave jedoch kein Shield entworfen werden, da auf dem Arduino Uno bereits ein Shield für die Ansteuerung der Schrittmotoren befestigt ist. Um dennoch eine saubere Schaltung für das Projekt verwenden zu können, wurde stattdessen eine einfache Platine entworfen, welche alle notwendigen Pin-Anschlüsse für die entsprechenden Schnittstellen des Arduinos usw. aufweist. Ebenfalls wurde auch auf dieser Platine ein Sockel für den Transceiver verbaut, um diesen bei Beschädigungen wechseln zu können.

LINK: Mithilfe dieses Links können die Schaltpläne der Platinen im SVN eingesehen werden

Funktionstest der Platinen

Nachdem alle Platinen fertigt bestückt wurden, mussten diese schließlich in Betrieb genommen werden, um beispielsweise Beschädigungen durch den Lötvorgang festzustellen. Dafür wurden mit einem Durchgangsprüfer eines digitalen Multimeters zunächst alle Pins durchgetestet, ob diese eventuelle störende Masseverbindungen (außer Erdpotentialanschluss -> Ground) aufweisen. Nach der erfolgreichen Prüfung, wurden die Platinen anschließend nach entsprechender Vorgabe an die Mikrocontroller usw. angeschlossen. Auch dieser Vorgang verlief fehlerfrei, sodass die Platinen mit dem LIN-Bus verbunden wurden. Nach dem Einschalten aller Geräte, konnte der Funktionstest als erfolgreich festgehalten werden. Die Arduinos kommunizierten einwandfrei miteinander und das Kurvenlicht des Scheinwerfers bewegte sich wie gewünscht.

Abb. 28: Funktionstest der Platinen

Ergebnis

Unser Projektergebnis wird in diesem Kapitel dargestellt. Auf der linken Seite befindet sich der Master, der ein erstelltes Datenpaket auf den Bus legt. Das Signal auf dem LIN-Bus ist mit dem Oszilloskop dargestellt. In der Mitte befindet sich ein Netzteil an dem wir 12V einstellen, um den Scheinwerfer anzusteuern und den LIN-Bus mit Spannung zu versorgen. Auf der rechten Seite befindet sich der Slave, der die gesendeten Daten auf dem LIN-Bus. Bei passender, gesendeter ID steuert der Slave den Motortreiber an, der den Schrittmotor nacheinander nach links, runter, rechts und hoch ansteuert (die Richtigen sind in Fahrtrichtung angegeben).

Abb. 29: Ergebnis LIN-Bus

Das Ergebnis ist am besten in dem nachfolgenden Video zu sehen

Zusammenfassung

Abschließend zum Projekt wird im Folgendem eine Zusammenfassung in Form der gesammelten Erfahrung und eines Ausblicks gegeben.

Lessons Learned

Rückblickend kann festgehalten werden, dass die Wahl der Arbeitsreihenfolge vorteilhaft für das Projekt war. Die Recherche half dabei, um sich zunächst einen Überblick über das gesamte Thema zu verschaffen. Auch das bestehende Wissen zu Bussystemen aus dem Bachelorstudium stellte eine gute Basis dar und konnte bei der Programmierung erstmals verwendet werden. Beim Sichten der benötigten Bauteile konnten weitere vertiefende Erfahrungen im Bereich der Elektrotechnik gesammelt werden und das Erstellen eines Anschlussplans für den Aktor stellte sich als Herausforderung dar, da keine öffentlichen zugänglichen Quellen zum Aufbau des Scheinwerfer existieren. Diese Herausforderung konnte aber durch bestehende Erfahrungen in der Elektrotechnik und in der Antriebstechnik schnell gelöst werden. Das Designen eines Schaltplans und Anfertigen der Platinen konnten als ergänzende Vertiefungen gesehen werden. Das Bestücken der Bauteile entsprach einer guten Praxisnahen Übung im Bereich der Löttechnik. Weiterführend wurde beim Programmieren der Schnittstelle zwischen Mikrocontroller und LIN-Bus das Wissen im Bereich der hardwarenahen Programierung in der Hochsprache C/C++ vertieft.

Ausblick

Weiterführend gesehen, sollte das LIN-Protokoll weiter angepasst werden, damit eine einwandfreie Überwachung mit CANoe sichergestellt werden kann. Außerdem könnten neue Platinen für neue Anwendungen angefertigt werden, da die im Projekt verwendeten Platinen nur für die beschriebene Demonstration angefertigt wurden. Vorstellbar wäre auch ein komplexeres LIN-Netzwerk aufzubauen, um damit verschiedene Sensoren und Aktoren anzusteuern.

Projektunterlagen

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

SVN-Link LIN-Demonstrator

YouTube Video

Das Ergebnis dieses Projekts kann unter folgendem YouTube Video entnommen werden:

Projektvideo

Weblinks

Datenblatt LIN-Transceiver MCP2004

Aufbau LIN Nachricht

LIN-Protokoll

CANoe-Adapter

Literatur

[1] Reif, Konrad: Bosch Autoelektrik und Autoelektronik. Boardnetze, Sensoren und elektronische Systeme, 6. Auflage, Vieweg+Teubner Verlag, Wiesbaden 2011

[2] Zimmermann, Werner; Schmidgall, Ralf: Bussysteme in der Fahrzeugtechnik. Protokolle, Standards und Softwarearchitektur, 5., aktualisierte und erweiterte Auflage, Springer Vieweg Verlag, Wiesbaden 2014