Steuerungssysteme für Elektrofahrzeuge am Beispiel des Projekts AICC

Inhaltsverzeichnis

Kurzfassung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

Vorwort

1 Aufgabenstellung

2 Erstellung eines Steuerungskonzeptes
2.1 Stromversorgung
2.2 Busse
2.3 Komponenten schalten
2.4 Notstopp
2.5 sonstige Steuer-, Regelungs- und Kontrollaufgaben

3 Erstellung eines Pflichtenhefts

4 Evaluierung eines geeigneten Rechensystems
4.1 Vergleich verschiedener Rechensysteme
4.2 Auswahl eines geeigneten Rechensystems

5 Aufbau und Entwicklung der Hardware
5.1 Beschreibung der einzelnen Funktionsblöcke
5.1.1 Ethernet Schnittstelle
5.1.2 Strom- und Spannungsmessung
5.1.3 Lenkabgleich
5.1.4 ISO–K–Line Tranciever & RS232 Schnittstelle für Kompassauswertung
5.1.5 Inkrementalgeberauswertung
5.1.6 USB – Controlleranbindung und EIOS
5.1.7 Softwareemulierte RS232 Schnittstelle für Debugging
5.1.8 LIDAR Schalt- und Fehlerausgangauswertung
5.1.9 Front- und Bremslichter
5.1.10 Temperatursensoren
5.1.11 Sensorbordanbindung
5.1.12 Auswertung der Infrarotsensoren
5.1.13 Stromversorgung Mainbord
5.2 Implementierung der Funktionsblöcke

6 Entwicklung der Steuerungssoftware
6.1 Allgemeiner Überblick
6.2 Realisierung der Software
6.2.1 Maincontroller
6.2.2 USB - Controller
6.2.3 Notstoppcontroller

7 Kommunikationsprotokolle
7.1 Ethernetkommunikation
7.2 MBC – NBC
7.3 MBC – EECUSB

8 Ergebnisse und Zusammenfassung

Literatur- und Quellenverzeichnis

Anhang

Kurzfassung

Steuerungssysteme für Elektrofahrzeuge am Beispiel des Projekts AICC

Diese Bachelorarbeit behandelt die Konzeptionierung und Realisierung eines Steuerungssystems für Elektrofahrzeuge anhand des Beispiels des Projektfahrzeuges AICC. Die Plattform von AICC basiert auf einem früheren Projekt, dem „TTCAR – NEXT“. Das „TTCAR“ wurde zur Demonstration des „drive – by – wire“ Konzepts entwickelt.

Zuerst werden in dieser Arbeit die Abgrenzung des Funktionsumfangs des Steuerungssystems und die darauf folgende Konzepterstellung beschrieben. Die Arbeit beinhaltet deshalb Informationen zu verschiedenen Rechensystemen bezüglich ihrer Einsetzbarkeit in mobilen Systemen.

Nach der Festlegung des Funktionsumfanges und Auswahl des Rechensystems folgt die konkrete Umsetzung am Projektfahrzeug AICC. Um den Überblick zu behalten wird das Konzept in Funktionsblöcke zerlegt, die separat betrachtet und beschrieben werden. Dabei wird sowohl auf die Implementierung der Hardware und der Software im Detail eingegangen.

Das letzte Kapitel enthält sowohl eine Zusammenfassung als auch Ergebnisse der Entwicklungsarbeit. Weiters werden Verbesserungsmöglichkeiten aufgezeigt, die sich während der Umsetzung des Konzeptes herauskristallisierten.

Suchbegriffe: (Steuerungssysteme, Elektrofahrzeuge, PIC, Ethernet, USB)

Summary

Control systems for electric traction using the example of the project AICC

This bachelor thesis deals with the conceptual design and implementation of a control system for electric traction on the basis of the project AICC. The platform of AICC is based on the “TTCAR” which was the development of an earlier project at the FH – Kaernten. The main focus of the “TTCAR” project was the demonstration of the drive – by – wire concept.

At the beginning of this thesis the limitation of the functionality of the control system and the following conceptual design are described. For that reason this paper contains information about many various computing systems concerning their usability in mobile systems.

After the fixing of the range of supported functions and the choice of the most adequate computing system, the concrete implementation on AICC is explained. To keep the general idea the concept is split in small function blocks which are described individually. Both hardware- and software- implementation are specified.

The last chapter of this paper is dealing with the results of the development work. In addition some improvement opportunities, which came out during the construction of AICC are highlighted.

Key words: (control systems, electric traction, PIC, Ethernet, USB)

Abbildungsverzeichnis

Abb. 2-1-1 Schema Stromversorgung

Abb. 2-1-2 Schema des ISO-K-Line Bus

Abb. 2-1-3 Schema Ethernet Kommunikation

Abb. 2-1-4 Schema USB - Diagnose

Abb. 2-1-5 Schema Komponentenschalten

Abb. 2-1-6 Schema Notstoppsensorik

Abb. 2-1-7 Schema Lenkabgleich

Abb. 2-1-8 Kompassauswertung

Abb. 2-2-1 Schema Steuerungssystem

Abb. 2-3-1 Rechensystem

Abb. 2-4-1 Blockdiagramm Ethernetmodul; Microchip Technology 2007

Abb. 2-4-2 Ethernetmodulbeschaltung

Abb. 2-4-3 Spannungsmessung

Abb. 2-4-4 Beschaltung Strommessung

Abb. 2-4-5 Beschaltung Lenkabgleich

Abb. 2-4-6 Beschaltung ISO-K-Line & Kompass

Abb. 2-4-7 Blockdiagramm USB – Modul; Microchip Technology 2007

Abb. 2-4-8 USB - Controller Anbindung (Schaltplan)

Abb. 2-4-9 Beschaltung Software USART

Abb. 2-4-10 Sensorbordanbindung

Abb. 2-4-11 Stromversorgung des Mainbords (Schaltplan)

Abb. 2-4-12 Leitungsführung Ethernet

Abb. 2-4-13 Anbindung USB – Controller (Layout)

Abb. 2-4-14 Stromversorgung des Mainbords (Layout)

Abb. 2-5-1 Flussdiagramm Maincontrollersoftware

Abb. 2-5-2 Flussdiagramm USB – Controller Software

Abb. 2-5-3 Flussdiagramm Sensorbordsoftware

Abb. 8-1 TTCAR vs. AICC

Tabellenverzeichnis

Tab. 2-6-1 Kontrollbyte Ethernet

Tab. 2-6-2 SFR Datenbyte Bedeutung

Tab. 2-6-3 Diagnosemodus des Notstoppcontrollers

Tab. 2-6-4 Steuerbefehle für den USB – Controller

Vorwort

Die Motivation für das Projekt „AICC“ (artificial intelligence concept car) basiert ursprünglich auf der DARPA – Challenge, welche alle paar Jahre vom amerikanischen Verteidigungsministerium ausgeschrieben wird. Dabei handelt es sich um einen Wettbewerb mit autonomen Fahrzeugen die selbstständig einen Hindernisparcours bewältigen müssen. Am Projektfahrzeug AICC wurde großteils die gleiche Sensorik verbaut, die auch bei den DARPA – Autos verwendet wurde. Dadurch mussten ähnliche Probleme und Herausforderungen, wie die Teams, die an der Challenge teilnahmen, bewältigt werden. Aufgrund der begrenzten Zeit und finanziellen Mittel wurde deshalb entschieden, ein verkleinertes Modell eines solchen Fahrzeuges zu entwickeln, welches ebenfalls in der Lage sein sollte, selbstständig seine Ziele zu finden. Als Basis wurde das „TTCAR“ verwendet, das an der FH – Kärnten entwickelt wurde. Da das „TTCAR“ nicht für den Einsatz im Freien gedacht ist, wurde das Einsatzgebiet von AICC ausschließlich auf den Indoor – Betrieb beschränkt. Diese Beschränkung zog jedoch eine Reihe von Problemen nach sich, wie zum Beispiel die Positionierung in geschlossen Räumen ohne GPS. Es mussten aufwendige Algorithmen in die „autonomous driving software“ implementiert werden um eine zuverlässig funktionierende Positionsermittlung in Gebäuden zu realisieren.

Aufgrund der Verwendung des „TTCARs“ war dieses auch der Ausgangspunkt für die Entwicklung des Steuerungssystems unseres Fahrzeuges AICC. Das „TTCAR“ wurde für die Demonstration des „drive-by-wire“ Konzeptes entwickelt und besitzt jeweils vier unabhängige Lenk- und Antriebsmotoren. Dadurch ist es möglich, jedes Rad sowohl separat zu lenken als auch zu drehen. Jeder Motor wird über einen eigenen Steuerungsknoten angesteuert, welcher wiederum an den ISO – K – Line Bus angeschlossen ist. Über diesen erhält der Knoten seine Anweisungen.

Beim ISO – K – Line Bus handelt es sich um einen seriellen „one wire“ Bus, der vor allem in der Automobilindustrie, bei VW und Opel zu Diagnosezwecken eingesetzt wurde. Dabei wird der Bus auch als OBD 1 oder ALDL bezeichnet. Mit OBD 1 versuchte man erstmals herstellerübergreifend eine standardisierte Diagnoseschnittstelle zu schaffen. Dies wurde aber erst mit der Einführung der OBD 2 Schnittstelle und des CAN – Busses teilweise erreicht. Der Bus nach ISO 9141 Standard ist zeichenbasiert und bietet eine bi – direktionelle Halbduplex Kommunikation mit einer typischen Übertragungsrate von 9600 – 10400 BAUD. Die verwendeten Übertragungsraten sind herstellerspezifisch und können auch 160 oder 8192BAUD betragen. Mitte der 1990er Jahre wurde dieser Bus aufgrund seiner begrenzten Bandbreite vom CAN – Bus größtenteils abgelöst. Bei US amerikanischen Fahrzeugen wird er teilweise heute noch zur Diagnose kleiner Steuergeräte eingesetzt. Für weitere Informationen zum ISO – K – Line Bus verweise ich auf [1].

Aufbauend auf die bestehende Motorsteuerung und des damit verbundenen Bussystems, wurde ein Steuerungssystem entwickelt, das den Anforderungen des AICC – Projektes genügt. Damit inbegriffen ist die Schaffung einer standardisierten Schnittstelle über die das Auto gesteuert und überwacht werden kann.

1 Aufgabenstellung

Nach einigen Funktionstests mit dem bestehenden „TTCAR“ kristallisierten sich die wichtigsten Aufgaben für das neue Steuerungssystem sehr schnell heraus.

Die primäre Aufgabe dieses Systems besteht darin, einen zentralen Zugriffspunkt zu schaffen um mit einer standardisierten PC – Schnittstelle alle Knoten ansteuern zu können. In diesem zentralen Zugriffspunkt sollte aber auch bereits eine Vorauswertung der Hardwaredaten implementiert sein, damit der eigentliche Steuerungscomputer entlastet wird. Er muss dadurch keine Hardwaremanagement Tasks abarbeiten.

Ein weiterer wichtiger Punkt war die Realisierung verschiedener Fahralgorithmen auf dem Steuerungssystem. Die Algorithmen sollten die Ansteuerung über den Steuerungscomputer vereinfachen. Der Steuerungscomputer ist für die Navigation und die Wegfindung verantwortlich und beinhaltet sozusagen die eigentliche „Intelligenz“ des Gesamtsystems. Das Steuerungssystem stellt dem Steuerungscomputer eine, im Konzept festgelegte Anzahl von Fahrmodi zu Verfügung, welche über einfache Befehle aufgerufen werden können. Ein in die Steuerung implementiertes Kontroll- und Regelungssystem berechnet selbstständig die unterschiedlichen Winkel für geometrisch korrektes Lenken und sendet diese an die vier Lenkknoten. Weiters ist auch das für die Kurvenfahrt notwendige Differential in das Steuerungssystem integriert. Während einer Kurvenfahrt drehen sich die kurvenäußeren Räder schneller als die Kurveninneren. Dieser Drehzahlunterschied der Räder wird bei herkömmlichen Antriebskonzepten mit einem mechanischen Differential ausgeglichen. Da bei AICC jedes Rad separat angetrieben wird, war der Einsatz eines mechanischen Differentials nicht möglich. Der Drehzahlausgleich musste mit der unterschiedlichen Ansteuerung der Fahrmotoren erfolgen und daher über die Software realisiert werden. In das Steuerungssystem wurde deshalb eine Differentialfunktion integriert, die die Drehzahlen für die jeweiligen Räder berechnet und die entsprechenden Befehle an die Antriebsknoten über den ISO – K – Line Bus sendet.

Die dritte Aufgabe war die Implementierung einer Steuerungs- und Überwachungsfunktion für die am Auto verbaute Hardware. Diese Funktionen führen die Bootsequenz, das Powermanagement, die Strom- und Temperaturüberwachung und die Funktionsüberwachung der Lenk- und Fahrknoten aus. Diese Funktionen verhindern die Beschädigung der Hardware durch etwaige Fehlfunktionen.

Für die Realisierung dieser Funktionen muss das Steuerungssystem eine hohe Zuverlässigkeit aufweisen, denn ein Ausfall des Steuerungssystems könnte die angeschlossene Hardware beschädigen.

Eine weitere Aufgabe war die Realisierung einer Selbst- und Peripheriediagnose in das Steuerungssystem. Die Selbstdiagnose soll in der Lage sein Fehler in der Steuerung eigenständig zu erkennen und das System wieder in einen sicheren Zustand zu bringen. Die Peripheriediagnose überwacht die gesamte, an das Steuerungssystem angeschlossene; Hardware und sollte das System im Falle eines Fehlers ebenfalls in einen sicheren Zustand bringen. Tritt ein Fehler auf, so muss das Diagnosesystem selbstständig entscheiden können ob eine Weiterfahrt noch gefahrlos möglich ist. Der Steuerungscomputer erhält über ein regelmäßig gesendetes Statusbyte Informationen, ob das Steuerungssystem das Auto freigibt oder nicht.

Weiters muss das Steuerungssystem auch die am Auto verbauten Inkrementalgeber auswerten und daraus die absolute Geschwindigkeit und die zurückgelegte Wegstrecke berechnen. Diese Daten müssen dem Steuerungscomputer in Echtzeit zur Verfügung gestellt werden, denn dieser benötigt sie für die Dead – Reckoning Funktionen. Dead – Reconing ist ein wesentlicher Bestandteil der Navigation unseres Fahrzeuges die auf dem SLAM Konzept basiert. Weitere Informationen zur Navigation bzw. SLAM unter [2].

2 Erstellung eines Steuerungskonzeptes

Als erstes wurden im Steuerungskonzept die zu steuernde Hardware und die dafür benötigten Schnittstellen festgelegt. Weiters wurde evaluiert, an welchen Stellen die Steuerung eingreifen können soll und auf welche Parameter sich die Regelungen des Steuersystems stützen. Dabei war immer auf die Realisierbarkeit der Layouts zu achten die aufgrund der beengten Platzverhältnisse zur Herausforderung wurde. Für die Erstellung des Steuerungskonzeptes wurde die Steuerung in mehrere Teile geteilt. Der erste Teil bzw. das erste Unterkapitel behandelt die Steuerung und die Schnittstellen zur Stromversorgung. Der zweite Teil spezifiziert die am Fahrzeug verwendeten Bussysteme für die Kommunikation mit dem PC, der dritte Teil betrifft das Schalten der einzelnen Komponenten, der vierte Teil erklärt das Konzept des Notstopps und der fünfte Teil beschreibt kurz die restlichen Steuer-, Regelungs- und Kontrollaufgaben

2.1 Stromversorgung

Die Stromversorgung besteht aus fünf DC/DC Convertern, die die benötigten Spannungen am Fahrzeug erzeugen. Die Converter können jeweils über eine Steuerleitung ein- und ausgeschaltet werden, um bei Überhitzung oder bei einem Defekt den Converter abschalten zu können. Die Temperatur der Converter wird mit Temperatursensoren gemessen die jeweils unter den Convertern verbaut sind. Die Spannungen zur Spannungsüberwachung werden am zentralen Maincon 3 Stecker abgegriffen.

Die Temperatursensoren sind an einen I2C Bus angebunden, um die Anzahl der Leitungen möglichst klein zu halten. Außerdem liefern diese Sensoren bereits einen absoluten digitalen Wert, der direkt verwendet werden kann. Dadurch entfallen zeitraubende Berechnungen des Steuerungssystems.

Weiters wurden zwei Punkte zur Strommessung implementiert, um eine Überstromabschaltung realisieren zu können. Diese beiden Messpunkte sind am Power Control 2 Stecker ausgeführt und messen den Strom der vorderen und hinteren Antriebs-und Lenkmotoren getrennt. Damit soll ein Überlasten der H – Brücken, die jeweils nur ca. 6A aushalten, vor Überlast geschützt werden. Weiters wird dadurch auch die gesamte Stromversorgungsplatine abgesichert, denn diese ist in Summe für einen konstanten Spitzenstrom von 30A ausgelegt.

Zusätzlich können bei Fehlern im Steuerungssystem die Antriebs- und Lenkmotoren abgeschaltet werden, um unkontrollierte Fahrmanöver zu verhindern. Diese Funktion wird ebenfalls zur Realisierung der Überstromabschaltung verwendet. Durch das Übereinanderstapeln der DC/DC – Converter kommt es bei höheren Belastungen zu Hitzestaus im Fahrzeug. Dabei könnte die Temperatur so hoch werden, dass die Converter abgeschaltet werden müssen und somit das ganze Fahrzeug zum Stillstand käme. Aus diesem Grund wurden zusätzlich drei Lüfter in das Fahrzeugchassis eingebaut, die über das Steuerungssystem geschaltet werden können. Sie werden bei Bedarf ein- oder abgeschaltet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-1: Schema Stromversorgung

In Abbildung 2-1-1 stellt die Stromversorgung schematisch dar. Über Power Control 1 und Power Control 2 werden die DC/DC – Converter gesteuert, die Spannungen und die Ströme von der Steuerung gemessen. Der I2C Bus der Temperatursensoren ist ebenfalls über diese Stecker geführt. Die Ansteuerung der Lüfter erfolgt leistungslos über zwei Signalleitungen.

2.2 Busse

Der ISO – K – Line Bus wird, wie in der Abbildung 2-1-2 zu sehen, wie bisher beim TTCAR zur Ansteuerung der Motorsteuerungsknoten verwendet. Mittels geeigneter Tranciever kann der Bus über eine Standard – USART Schnittstelle betrieben werden. Diese Variante wurde gewählt, weil fast jeder Mikrocontroller eine solche Schnittstelle auf Hardwareebene implementiert hat und sie auch auf einem FPGA relativ einfach zu realisieren ist. Da die Knoten nur Daten empfangen aber nicht senden können, konnte der komplette Bus unidirektional ausgelegt werden, was das Hardwaredesign wesentlich vereinfachte.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-2: Schema des ISO-K-Line Bus

Für die physikalische Verbindung wurden ebenfalls die bereits vorhandenen Kabel weiterverwendet. Dabei handelt es sich um Flachbandkabel mit einem Western RJ11 Stecker.

Um eine maximale Flexibilität für die zentrale Kommunikationsschnittstelle zu gewährleisten wurde entschieden das Ethernetprotokoll für die Kommunikation zwischen der Steuerung und dem Steuerungscomputer einzusetzen. Ethernet auf einem Mikrocontroller, FPGA o.ä. zu implementieren ist eine relativ komplexe Aufgabe, aber dadurch kann nahezu jeder beliebige PC oder jedes Embedded System zur Steuerung des Fahrzeuges verwendet werden. Weiters ist es problemlos möglich das Fahrzeug per WLAN fernzusteuern und auch eine Ferndiagnose ist einfach realisierbar. Ethernet schränkt jedoch die Auswahlmöglichkeiten für das Rechnersystem der Steuerung etwas ein, denn ein kleiner Ethernetstack, der nur das UDP – Protokoll beinhaltet, benötigt auf Mikrocontrollern mit 16bit Befehlssatz bereits ca. 10kB. Ein grobes Schema der am Fahrzeug verwendeten Ethernetkomponenten stellt Abbildung 2-1-3 dar.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-3: Schema Ethernet Kommunikation

Wie aus Abbildung 2-1-3 ersichtlich, wurde mit dem Router ein eigenes kleines Netzwerk am Fahrzeug aufgebaut. Auf dem Router läuft ein DHCP – Server, der den einzelnen Geräten IP – Adressen zuteilt. Wie oben schon erwähnt, erfolgt die Kontrolle Steuerungssystems direkt über Ethernet. Für das Steuerungssystem und den Steuerungscomputer wird ein so genanntes statisches DHCP verwendet, um eine einwandfreie Kommunikation zwischen Steuerungscomputer und Steuerungssystem sicherzustellen. Sonst könnte es nämlich während des Betriebs passieren, dass eines der Geräte eine neue IP zugewiesen bekäme und in Folge die Verbindung abreißen würde. Für diesen Fall sind zwar Sicherheitsmechanismen integriert, damit das Fahrzeug nicht außer Kontrolle gerät, trotzdem ist dann ein Neustart des Systems erforderlich.

Der Accesspoint ermöglicht die Steuerung und Fernwartung über WLAN und die Webcam dient zu Verfolgung der Fahrbewegungen des Fahrzeuges. Die Webcam ist natürlich ebenfalls über WLAN erreichbar. Für die physikalische Verbindung wurden Standard CAT5 – Kabel mit RJ45 Westernstecker verwendet. Detaillierte Informationen zu Ethernet und dessen Eigenschaften bei der Vernetzung von Computersystemen unter [16] Kapitel 15.

Für die Umsetzung des „Haupt“ – Diagnoseinterface fiel die Wahl des Kommunikationsbusses auf USB, um, ebenso wie bei Ethernet, möglichst flexibel zu sein. Da Laptops heutzutage kaum mehr eine RS232 Schnittstelle haben, jedoch das Diagnoseinterface eine schnelle Diagnose des Fahrzeuges ermöglichen soll, stellte USB die beste Alternative dar. Um dem Benutzer die umständliche Installation von Treibern zu ersparen, verwendet das Diagnoseinterface den integrierten Windowstreiber für virtuelle COM – Ports und ist dadurch sofort an jedem Laptop einsatzbereit. Nur eine *.inf Datei ist nötig um Windows bekannt zu geben, dass es sich um einen virtuellen COM – Port handelt. Um die Diagnosedaten lesen zu können wird eine Diagnosesoftware benötigt, die die gesendeten Daten aufbereitet und darstellt. USB stellt jedoch, wie Ethernet, besondere Anforderungen an die Software des Diagnoseinterface bzw. an die Hardware des Steuerungssystems. Zusätzlich zu dem USB – Diagnoseinterface verfügt das Steuerungssystem noch über eine „Sub“ – Diagnosefunktion für Ethernet. Diese inkludiert aber nicht die volle Funktionalität der USB – Diagnose und ist daher nur für einen schnellen Statuscheck gedacht. Bei einer, durch einen Fehler verursachten, Notabschaltung des Systems funktioniert ohnehin nur mehr das USB – Diagnoseinterface. Ein grobes Schema des ausgearbeiteten Konzeptes zum USB – Diagnoseinterface ist in Abbildung 2­1-4 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-4: Schema USB - Diagnose

Das Konzept sieht vor, dass ein eigener Controller die Kommunikation über USB übernimmt. Je nach Rechensystem wird dieser Controller direkt ins Steuerungssystem integriert oder als eigener IC ausgelagert. Ähnliches gilt für den Speicher. Abhängig vom eingesetzten Rechensystem sind der Fehlerspeicher und der Konfigurationsspeicher in das Steuerungssystem bzw. in den USB – Controller integriert oder ebenfalls als eigener IC separat ausgeführt. Weiters sind der Fehlerspeicher und der Konfigurationsspeicher nur über das Steuerungssystem auslesbar und veränderbar, d.h. sämtliche Anforderungen müssen an das Steuerungssystem geschickt werden. Diese Einschränkung ist notwendig um die Konsistenz der Daten zu gewährleisten. Das Konzept sieht jedoch als Ausnahme die „startup“ – Konfiguration vor. Vor dem ersten Start muss eine Standardkonfiguration in den leeren Konfigurationsspeicher geladen werden. Da das Steuerungssystem zu diesem Zeitpunkt noch nicht betriebsfähig ist, muss auf den Konfigurationsspeicher direkt zugegriffen werden können, um die Startup – Konfiguration in den Konfigurationsspeicher zu laden.

Im Zuge der Realisierung des Steuerungssystems wurden noch weitere Busse verwendet, der hauptsächlich zur Kommunikation zwischen den einzelnen Komponenten auf den Platinen dienen. Diese, z.t. selbst entwickelten Busstrukturen, werden bei den Kapiteln zur Hard- und Softwareimplementierung genauer beschrieben.

2.3 Komponenten schalten

Das Fahrzeug AICC besitzt neben dem Steuerungssystem und der dazugehörigen Hardware eine Vielzahl weiterer Komponenten. Darunter fallen das LAN – Equipment, der LIDAR Sensor, der Kompass und der Steuerungscomputer. Diese Komponenten werden über die, in Teil 1 dieses Kapitel beschriebenen Stromversorgung, mit Strom versorgt. Beim Einschalten des Fahrzeuges werden die Spannungen bzw. die DC/DC Converter nach einer fest vorgegeben und exakt getimten Reihenfolge aktiviert. Das ist notwendig, um alle der Hardwarekomponenten von AICC richtig initialisieren zu können. Darunter fällt zum Beispiel auch das Initialisieren der Antriebs- und Lenkknoten. Auch der darauf folgende Abgleich der Lenkung für jedes Rad muss exakt zur richtigen Zeit ausgeführt werden und es müssen genau die richtigen Spannungen aktiv sein. Würden die Versorgungsspannungen der Lenkknoten zeitlich gesehen in der falschen Reihenfolge an den Knoten anliegen, dann würden die Knoten abstürzen und der Abgleich müsste neu gestartet werden. Weiters musste beim Erstellen der Bootsequenz von AICC darauf geachtet werden, dass die Summe der Stromspitzen beim Einschalten nicht zu hoch wird. Sonst könnte es passieren, dass sich ein DC/DC Converter wegen Überlastung abschalten würde. Die genannten Gründe erforderten eine Möglichkeit zu finden, die es schafft, dass die einzelnen Komponenten bzw. Geräte separat von der Spannungsversorgung eingeschaltet werden können. Der LIDAR – Sensor, das LAN – Equipment, der Kompass und der Steuerungscomputer müssen nicht zu einem bestimmten Zeitpunkt des Bootvorganges aktiviert werden, da sie erst fürs autonome Fahren benötigt werden. Deswegen werden sie vom Steuerungssystem erst eingeschaltet, wenn die restliche Hardware initialisiert ist. Um die Stromspitzen beim Einschalten zu minimieren, werden die schaltbaren Komponenten nicht gleichzeitig sondern sequentiell zugeschaltet. Zwischen den einzelnen Schaltereignissen wird eine Verzögerung eingefügt, die durch die Initialisierungsdauer der einzelnen Komponenten bestimmt wird. Weiters ergibt sich durch das separate Schalten die Möglichkeit, dass bei Fehlfunktion einer Komponente bzw. eines Geräts diese gezielt weggeschaltet werden können. So wird verhindert, dass das Steuerungssystem wegen dem Ausfall eines einzigen Geräts eine Notabschaltung initiieren muss. Bei Fehlern wird nur die entsprechende Komponente abgeschaltet und über das, im ersten Kapitel erwähnten Statusbyte, erhält der Steuerungscomputer Informationen, welches Gerät ausgefallen ist. Dadurch ist eventuell die Möglichkeit zur Weiterfahrt, wenigstens jedoch zum definierten Beenden und Fehlersuchen gegeben. Insgesamt können fünf Komponenten separat über entsprechende Steuerleitungen leistungslos vom Steuerungssystem geschaltet werden. Das Schalten ermöglicht ein Teil der Stromversorgung, die Powerrail. Sie hat die nötigen Schaltelemente integriert und ist so flexibel angelegt, dass jede gewünschte Spannung verfügbar und schaltbar ist. Die nachfolgende Grafik (Abbildung 2-1-5) stellt das Konzept des Komponentenschaltens dar.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-5: Schema Komponentenschalten

2.4 Notstopp

Die Umsetzung der Notstoppfunktionalität ist ein wichtiger Bestandteil des Steuerungssystems. Der Notstopp hält AICC kurz vor Hindernissen an, wenn der Steuerungscomputer fehlerhafte Fahrbefehle sendet oder abgestürzt ist. Das ist ein weiterer Grund, weshalb das Steuerungssystem so zuverlässig wie möglich funktionieren muss, denn der Notstopp ist die letzte Instanz der einen Crash des Fahrzeuges verhindern kann.

Für den Notstopp wurden mehrere verschiedene Sensortypen evaluiert, denn es gibt eine Vielzahl von unterschiedlichen Hindernissen, die durch einen Sensortyp erkannt werden können, durch den Anderen aber nicht und umgekehrt. Aufgrund der vielen Sonderkonstellationen, die im normalen Fahrbetrieb auftreten könnten und für die eigene Sensoren benötig werden würden, musste, um die Anzahl der Sensoren überschaubar zu halten, die Art der Hindernisse eingeschränkt werden. Die meisten zugelassenen Hindernisse werden gut vom LIDAR – Sensor durch die Laserabtastung erkannt. Der Vorteil dabei ist, dass sich beim verwendeten LIDAR – Sensor über ein einfaches serielles Konfigurationsinterface Warn- und Schutzfelder definieren lassen, die über Schaltausgänge einfach ausgewertet werden können. Für die Realisierung der Notstoppfunktionalität ist dieses Feature des Sensors ideal. Leider reichen die Warn- und Schutzfelder dieses Sensors allein nicht aus. Da der LIDAR – Sensor nur ein Zeilenscanner ist, d.h. man erfasst seine Umgebung in nur einer Ebene, können keine Stiegen o.Ä. erkannt werden. Außerdem sind glänzende und transparente Objekte durch die Laserabtastung des LIDAR – Scanners nur schwer bis gar nicht zu erkennen. Außerdem kann der Sensor aufgrund seiner Montage an der Fahrzeugfront nur den Bereich vor dem Fahrzeug abdecken, nach hinten wäre AICC ohne zusätzliche Sensorik blind. Für den hinteren Bereich und wegen der vorhin beschriebenen Problematik der reflektierenden Gegenstände, kommen Infrarotsensoren zum Einsatz, die in einem leichten Winkel Richtung Boden montiert werden. Diese Sensoren können fast alle anderen, mit dem LIDAR – Sensor nicht erkennbaren Hindernisse detektieren. Die Infrarotsensoren sind außerdem sehr einfach auszuwerten, denn sie generieren eine analoge Spannung, die proportional zur Entfernung zu einem Hindernis ist. Allerdings muss das Steuerungssystem nun genug Analogeingänge zur Verfügung stellen, um neben den Spannungen der Spannungsversorgung auch die benötigte Anzahl von Sensoren auswerten zu können. Für weitere Informationen bezüglich der verwendeten Sensorik und deren Anbindung am AICC verweise ich auf [3].

Die erwähnten Warn- und Schutzfelder müssen so konfiguriert sein, dass AICC nach dem Auslösen innerhalb der verbleibenden Strecke bis zum Hindernis anhalten kann. Neben der richtigen Positionierung der Infrarotsensoren muss darauf geachtet werden, dass das Steuerungssystem so schnell wie möglich nach Eintreten einen Notstoppsituation den Notstopp auslöst. Das wiederum ist wichtig, damit die Sensorik so konfiguriert werden kann, dass der Notstopp nicht vorzeitig, sondern erst unmittelbar vor dem Hindernis ausgelöst wird. Wird ein Notstopp ausgelöst so sieht das Konzept vor, dass der letzte Fahrbefehl des Steuerungscomputers vom Steuerungssystem ungültig gemacht, dieser dadurch nicht mehr ausgeführt wird und in weiterer Folge so AICC angehalten wird. Die Grafik Abbildung 2-1-6 stellt die Notstoppsensorik und die Anbindung an das Steuerungssystem dar. Die Art der benötigten Komponenten, die die Anbindung der Sensorik ermöglichen, hängt von der Evaluierung des Rechensystems ab.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-6: Schema Notstoppsensorik

Die auf Abbildung 2-1-6 zusätzlich dargestellte Ethernetverbindung zwischen Steuerungssystem und Steuerungscomputer symbolisiert den im Konzept vorgesehenen Informationsfluss bezüglich der Notstoppfunktion. Das Steuerungssystem sendet zum Steuerungscomputer über Ethernet auf einem eigenen Port ständig die Auswertungsergebnisse der Notstoppsensorik. Dadurch erkennt der Steuerungscomputer sofort eine Auslösung des Notstopps und den Grund. Mit diesen Daten kann er dann entsprechend reagieren und neue Fahrbefehle an das Steuerungssystem senden.

2.5 sonstige Steuer-, Regelungs- und Kontrollaufgaben

Neben den bisher erwähnten gibt es im Konzept noch einige Aufgaben, die das Steuerungssystem bewältigen muss.

Der Abgleich der Lenkung für jedes Rad ist eine der Aufgaben die das Steuerungssystem noch zusätzlich bewältigen muss. Der Lenkabgleich ist wegen der Eigenschaften der übernommenen Hardware vom TTCAR nötig. Beim TTCAR sind für die Feststellung der aktuellen Lenkposition keine Absolutwertgeber, sondern nur einfache Inkrementalencoder verwendet worden. Mit diesen Inkrementalencodern kann man nur eine Differenz zur jeweils vorigen Position anhand der Anzahl der zurückgelegten Schritte und der Drehrichtung feststellen. Eine absolute Position ist daher nur dann feststellbar wenn es irgendeinen Synchronisierungspunkt gibt, der angefahren werden kann und von dem die Position bekannt ist. Absolutwertgeber bzw. Absolutgeber liefern zu jeder Zeit eine absolute Position der Achse in einer entsprechenden Codierung. Es gibt verschiedene Codierungsarten für Absolutgeber, häufig jedoch wird der Graycode, BCD – Code oder Binärcode eingesetzt. Weitere Informationen zu Inkrementalencoder und Absolutgeber finden sich unter [4].

Um die absolute Position der Lenkmotoren zu erhalten, wurde mittels Potentiometer eine Analogspannung generiert, die durch die Verbindung zwischen Lenkachse und Potentiometerachse proportional zum Lenkwinkel ist, mit der die Lenkknoten abgeglichen wurden. Das Problem war, dass die Lenkknoten diesen Abgleich nur einmal am Anfang durchführen und wenn man die Einstellungen verändern wollte, musste man das Fahrzeug neu starten bzw. die Lenkknoten zurücksetzen. Im Konzept für AICC wurde zwar die Methode der Positionsfeststellung mittels Potentiometers prinzipiell beibehalten, der eigentliche Abgleich sollte jedoch vom Steuerungssystem durchgeführt werden. Dadurch ist ein schneller Abgleich während des Betriebs möglich und weiters können Ausfälle bzw. Abstürze der Lenkknoten detektiert werden. Außerdem müssen die Lenkknoten nicht mehr von außen zugänglich sein, um das Reset – Signal zu generieren, denn das soll nun durch das Steuerungssystem erzeugt werden.

Ist die Lenkung einmal abgeglichen, rechnen die Lenkknoten, wie bisher am TTCAR, selbstständig von der 0 – Position weiter. In der nachfolgenden Abbildung (Abbildung 2-1­7) ist das Schema des neuen Lenkabgleichs vom AICC dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-7: Schema Lenkabgleich

Die Hohlwellenpotentiometer werden direkt auf die Lenkachse aufgesteckt und sind nicht wie bisher über ein eigenes Gestänge mit der Lenkachse verbunden. Dadurch sollte der Abgleich genauer sein, denn die Toleranzen des Gestänges werden dadurch eliminiert.

Ein weiterer wesentlicher Punkt ist die Auswertung der Inkrementalgeber der Antriebsmotoren. Wie bei der Lenkung wurden auch hier beim TTCAR Inkrementalgeber und keine Absolutwertgeber eingesetzt. In diesem Fall erwies sich das jedoch als Vorteil, denn bei der Geschwindigkeits- bzw. bei der Wegstreckenermittlung ist nur die Differenz zum letzten Messpunkt interessant. Außerdem sind simple Inkrementalgeber einfacher auszuwerten als Absolutwertgeber.

Die Motorsteuerungsknoten benötigen die Inkrementalgeber zur Sicherstellung einer konstanten Raddrehzahl. Leider können die ausgewerteten Daten nicht über den ISO – K – Line Bus abgefragt werden, denn die Knoten können nur Daten empfangen aber nicht senden. Deshalb müssen die Inkrementalgeber vom Steuerungssystem separat ausgewertet werden. Die Inkrementalgeber generieren Impulse, deren Frequenz abhängig von der Wellendrehzahl ist, auf der sie befestigt sind. Diese Impulse generieren bei denen am TTCAR verbauten Inkrementalgeber 5V Pegel und können daher in der Regel von den meisten FPGAs und Mikrokontrollern o.Ä. ohne Zusatzbeschaltung ausgewertet werden. Aufgrund der vorerst einfachen Auswertung der Inkrementalgeber erhöht sich der Konzeptaufwand nicht wesentlich, einzig auf die Frequenz ist zu achten. Das Steuerungssystem muss die Impulsfrequenz der Inkrementalgeber, in diesem Fall bis zu 40kHz, verarbeiten können. Zu beachten ist außerdem, dass vier Inkrementalgeber Impulse mit dieser Frequenz gleichzeitig generieren.

Der nächste Punkt betrifft die Diagnosefunktionalität. Das Hardwareinterface wurde ja schon im Teil zwei bei den Bussen beschrieben. Hier geht es darum, dass beim Konzept ein besonderes Augenmerk auf die Implementierung der Diagnosefunktion gelegt wird. Die Diagnosefunktion sollte eigentlich keine eigene Funktion sein, sondern es geht darum, die anfallenden Daten direkt bei der Verarbeitung zu bewerten, um eventuelle Auffälligkeiten sofort zu erkennen. Dadurch können auch nachfolgende Schritte sehr schnell eingeleitet werden, wie etwa die Umschaltung auf einen sogenannten Notbetrieb. Das Konzept für das Fahrzeug AICC sieht sowohl einen Notbetrieb als auch eine Notabschaltung vor. Bei gewissen Fehlern funktioniert das Fahrzeug weiterhin, wenn auch eingeschränkt. Tritt ein kritischer Fehler auf, so muss eine Notabschaltung eingeleitet werden, um Schäden an der Hardware zu vermeiden. Dem Konzept nach sollte die Datenbewertung kontinuierlich und sofort erfolgen und nur im Falle einer auffälligen Abweichung eine explizite Fehlerfunktion aufgerufen werden, die entscheidet ob der gefahrlose Betrieb weiterhin gewährleistet ist oder eine Notabschaltung eingeleitet werden muss. In welchem Modus sich das Steuerungssystem gerade befindet, soll mittels Indikator Leds von außen sofort erkennbar sein. Weiters sollte das Diagnosesystem in der Lage sein jede Hardwarekomponente explizit testen zu können.

Ein weiterer Abschnitt im Konzept behandelt die Kompassauswertung. Fast alle digitalen Kompassmodule besitzen ein serielles Interface. Da jedoch kaum mehr Laptops mit einer RS232 Schnittstelle erhältlich sind und ein Laptop aber eine mögliche Alternative für den Steuerungscomputer darstellt, muss die Kompassauswertung und Datenaufbereitung das Steuerungssystem übernehmen. Das Steuerungssystem muss daher die entsprechende, zur Auswertung der gängigsten Kompassmodule nötige Hardware integriert haben. Die Kompassdaten sollen dann über Ethernet dem Steuerungscomputer regelmäßig zur Verfügung stehen. Für die Implementierung eines Kompassmoduls in das Steuerungssystem ist ein weiteres serielles Interface nötig, das sowohl mit Standard RS232, als auch mit TTL Pegeln arbeiten können muss. Aus Kosten- und Platzgründen verzichten einige Hersteller nämlich auf die, für Erreichung der laut RS232 – Standard geforderten Pegel, benötigen Pegelwandler. Außerdem muss auch sichergestellt werden, dass genug Rechenzeit am Steuerungssystem zur Verfügung steht, um den Kompass auszuwerten und die Daten über Ethernet an den Steuerungscomputer zu senden. Die Einbindung des Kompasses ist in Abbildung 2-1-8 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-1-8: Kompassauswertung

Der letzte Punkt betrifft die Brems- und die Frontlichter. Die Bremslichter sollen bei einer Geschwindigkeitsreduktion leuchten und die Frontlichter sollen über Ethernet und über die Diagnose ein- und ausschaltbar sein. Da ohnehin laufend Daten vom Steuerungscomputer zum Steuerungssystem gesendet werden, stellen die Lampenbefehle kaum einen zusätzlichen Aufwand dar. Der einfache Zähler, der für das Leuchten der Bremslichter nötig ist, benötigt ebenfalls kaum Rechenleistung und ist auf jedem Rechensystem ohne großen Zeitaufwand umzusetzen.

Als Leuchtmittel sollen laut Konzept superhelle LEDs verwendet werden, denn sie verbrauchen, gemessen an ihrer Leuchtkraft, wenig Strom im Gegensatz zu Glühlampen mit ähnlicher Leuchtkraft. LEDs können außerdem ohne großen Aufwand an eine der Versorgungsspannungen am Auto angeschlossen werden.

3 Erstellung eines Pflichtenhefts

Das Pflichtenheft wurde anhand des Steuerungskonzeptes erstellt und fasst die wichtigsten Punkte des Steuerungssystems zusammen. Dafür wurden alle im Steuerungskonzept erwähnten Punkte bewertet und nach Priorität gereiht. Das Pflichtenheft für das Steuerungssystem von AICC umfasst folgende Punkte:

- Schaffung eines zentralen Zugriffspunktes zur Hardware des Fahrzeuges für den Steuerungscomputer über Ethernet.
- Einbindung verschiedener Sicherheitsmechanismen zur Erkennung eines etwaigen Verbindungsabrisses zum Steuerungscomputer.
- Realisierung eines Notstoppsystems, das unabhängig vom Steuerungscomputer arbeitet. Trotz des unabhängigen Systems sollen alle Sensordaten dem Steuerungscomputer zur Verfügung gestellt werden.
- Implementierung des kompletten Powermanagements mit Fehlererkennung
- Integration des Lenkabgleichs und aller übrigen Steuer- und Regelaufgaben.
- Integration eines Diagnose- und Fehlererkennungssystems, welches Probleme erkennt und selbstständig entscheidet, ob der weitere Betrieb möglich ist.
- Implementierung eines Diagnoseinterface per USB über das sämtliche Diagnosedaten abgerufen und Testroutinen für einzelne Hardwarekomponenten aufgerufen werden können. Weiters sollen über dasselbe Interface die Konfigurationsdaten abrufbar und veränderbar sein.
- Überwachung der Sensorik und Überprüfung der Daten auf Plausibilität.

Anhand des Pflichtenhefts wurde das Rechensystem evaluiert und ausgewählt. Weiters basiert auch die Entwicklung der Hard- und Software darauf.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2-2-1: Schema Steuerungssystem

Auf der Abbildung 2-2-1 ist das anhand des Steuerungskonzeptes und Pflichtenhefts erarbeitete Schema für das gesamte Steuerungssystem dargestellt. Um die Übersichtlichkeit zu wahren sind mehrere Komponenten, wie zum Beispiel der Steuerungscomputer, doppelt eingezeichnet.

[...]