path: root/Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx

#LyX 1.6.6.1 created this file. For more info see http://www.lyx.org/
\lyxformat 345
\begin_document
\begin_header
\textclass scrartcl
\use_default_options true
\language ngerman
\inputencoding auto
\font_roman default
\font_sans default
\font_typewriter default
\font_default_family default
\font_sc false
\font_osf false
\font_sf_scale 100
\font_tt_scale 100

\graphics default
\paperfontsize default
\spacing single
\use_hyperref false
\papersize a4paper
\use_geometry false
\use_amsmath 1
\use_esint 1
\cite_engine basic
\use_bibtopic false
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language german
\papercolumns 1
\papersides 1
\paperpagestyle plain
\tracking_changes false
\output_changes false
\author "" 
\author "" 
\end_header

\begin_body

\begin_layout Title

\lang english
OBD-II und GPS Komponente, Einsatz im Auto
\end_layout

\begin_layout Author
Martin Dederer, Sven Eisenhauer
\end_layout

\begin_layout Date
Juli 2010
\end_layout

\begin_layout Titlehead
Hochschule Darmstadt
\begin_inset Newline newline
\end_inset

Fachbereich Informatik
\end_layout

\begin_layout Subject
Master Projekt Systementwicklung SS 2010
\end_layout

\begin_layout Publishers
betreut von Prof.
 Dr.
 Wietzke und Prof.
 Dr.
 Hergenröther
\end_layout

\begin_layout Standard
\begin_inset Newpage newpage
\end_inset


\end_layout

\begin_layout Standard
\begin_inset CommandInset toc
LatexCommand tableofcontents

\end_inset


\end_layout

\begin_layout Standard
\begin_inset Newpage newpage
\end_inset


\end_layout

\begin_layout Section
Zielsetzung
\end_layout

\begin_layout Subsection
Betrieb des ICM-Frameworks im Auto
\end_layout

\begin_layout Standard
Bei der Entwicklung eines Software-Frameworks für den Einsatz im Auto ist
 ein wichtiger limitierender Faktor die verfügbare Rechenleistung.
 Typischerweise werden in Autos, speziell für die harscheren Umweltbedingungen
 ausgelegte, Emdedded-Systeme verbaut.
 Die höhere Robustheit und niedrigere Leistungsaufnahme von Embedded-Systemen
 hat ein geringere Rechenleistung zur Folge.
 Als Faustregel gilt, dass die Rechenleistung der Embedded-Systeme den aktuellen
 Desktop-Systemen um ca.
 ein Jahrzehnt hinterherhinkt.
\end_layout

\begin_layout Standard
Um das ICM-Framework unter vergleichsweise realistischen Bedingungen testen
 zu können wurde der Betrieb des ICM-Frameworks auf einem auf Linux basierendem
 Embedded-System als Ziel definiert.
\end_layout

\begin_layout Subsection
Anbindung des ICM-Frameworks an GPS-Empfänger
\end_layout

\begin_layout Standard
Die jüngere Entwicklung im Bereich des mobile computing hat gezeigt, dass
 der Zugriff auf Positionsdaten eine enorme Vielfalt an hilfreichen Diensten
 für den Anwender mit sich bringt.
 Dienste auf Basis des GPS sind heutzutage im Auto allgegenwärtig.
 Immer mehr Fahrzeugsubsysteme verwenden GPS-Positions- und Bewegungsdaten
 als zusätzliche oder einzige Datenquelle um ihre Funktion zu erfüllen.
 Fahrzugelokalisierung, Verkehrsflussüberwachung oder 
\begin_inset Quotes gld
\end_inset

einfach nur
\begin_inset Quotes grd
\end_inset

 Wegfindung sind einige Beispiele hierfür.
\end_layout

\begin_layout Standard
Damit das ICM-Framework auch in diesem Bereich weiterentwickelt werden kann
 wurde die Anbindung von GPS-Empfängern an das Framework als Ziel festgehalten.
\end_layout

\begin_layout Subsection
Anbindung des ICM-Frameworks an eine Fahrzeug-Schnittstelle
\end_layout

\begin_layout Standard
Aktuelle Kraftfahrzeuge verfügen über eine sog.
 On-Board-Diagnose-(OBD)-Schnittstelle, mittels derer der Zugriff auf Daten
 des Fahrzeugs möglich ist.
 Die Hauptanwendung dieser Schnittstelle liegt in der Auswertung von Diagnoseinf
ormationen bei der Fehlersuche und Reparatur am Fahrzeug.
 Zusätzlich lassen sich über diese Schnittstelle auch einige Daten über
 den aktuellen Zustand des Fahrzeugs, wie beispielsweise die Motordrehzahl,
 abfragen.
\end_layout

\begin_layout Standard
Bei der Verbindung eines Fahrzeugs mit einem Rechnersystem kommt in den
 meisten Fällen ein Adapter zum Einsatz, der zum Rechner hin eine serielle
 Datenschnittstelle aufweist.
 Über diese Verbindung lassen sich Fahrzeugdaten von einem Rechnersystem
 auslesen.
\end_layout

\begin_layout Standard
Die Zielsetzung dieses Projekts besteht in der Anbindung eines Fahrzeugs
 an einen Rechner.
 Zum Auslesen der Fahrzeugdaten soll eine Komponente für das ICM-Framework
 geschrieben werden, das auf dem Rechner laufen soll.
 Die Anzeige der Daten soll mittels eines digitalen Instrumentes auf dem
 Bildschirm des Rechners erfolgen.
 Auch diese Anzeige soll in das Framework integriert sein.
 In dieser Version beschränken wir uns auf die Darstellung der Motordrehzahl
 mit einem digitalen Drehzahlmesser.
\end_layout

\begin_layout Standard
\begin_inset Newpage newpage
\end_inset


\end_layout

\begin_layout Section
Inbetriebnahme des Atom-Testsystems
\end_layout

\begin_layout Standard
Die Atom-Plattform ist eine von Intel entwickelte Mikroarchitektur mit dem
 Schwerpunkt auf niedrigem Energierverbrauch und mobilem Einsatz.
 Sie wird vor allem bei Netbooks und stromsparenden Desktopsystemen eingesetzt.
 Aufgrund des geringen Platz- und Stromverbrauchs wurde für die Verwendung
 im Auto ein Atom-Testsystem bereitgestellt.
\end_layout

\begin_layout Subsection
Linux Installation
\end_layout

\begin_layout Standard
Da das ICM-Framework sowohl auf QNX als auch auf Linux lauffähig ist und
 die Linux-Treiberunterstützung der Atom-Plattform ausgesprochen gut ist,
 wurde als Betriebssystem Ubuntu Linux 9.10 in der 64 Bit Version eingesetzt.
 Die Standard-Installation war problemlos durchzuführen und das installierte
 System unterstützte die verfügbare Peripherie vollständig.
 Hardware-beschleunigte Grafik (OpenGL) konnte einfach mittels der offiziellen
 Ubuntu-Pakete für Nvidia-Grafikkarten nachgerüstet werden.
\end_layout

\begin_layout Subsection
Touchscreen
\end_layout

\begin_layout Standard
Die Ansteuerung der Touchscreen-Fähigkeit des am Atom-Testsystem ange\SpecialChar \-
schlossenen
 Flachbildschirm ist unter Linux grundsätzlich möglich.
 Hierfür muss\SpecialChar \-
ten ebenfalls zu\SpecialChar \-
sätzliche Treiber aus dem Ubuntu-Paket-Repository
 installiert werden.
 Bei der von uns durchgeführten Evaluation gelang es uns nicht den Touchscreen
 korrekt zu kalibrieren, was auf die schlechte Qualität des verwendeten
 Kalibrierungsprogramms zurückzuführen ist.
 Um den Touchscreen sinnvoll einsetzen zu können muss eine alternative Lösung
 zur Kalibrierung gefunden werden.
\end_layout

\begin_layout Subsection
ICM-Framework
\end_layout

\begin_layout Standard
Um das ICM-Framework auf dem Atom-Testsystem auszuführen ergab sich folgender
 Workflow.
 Zunächst muss das Framwork auf einem Laborrechner mit Hilfe der Momentics
 IDE für das Target LINUX_X86 kompiliert werden.
 Im Anschluss wird die erzeugte ausführbare Datei auf das Zielsystem übertragen
 und dort ausgeführt.
\end_layout

\begin_layout Standard
\begin_inset Newpage newpage
\end_inset


\end_layout

\begin_layout Section
GPS-Komponente
\end_layout

\begin_layout Standard
Die GPS-Komponente stellt dem Entwickler eine abstrakte Sicht auf das GPS-Subsys
tem bereit.
 Da sich die verfügbare GPS-Hardware je nach Plattform in ihrer Ansteuerung
 und dem Umfang der bereitgestellten GPS-Daten unterscheidet verbirgt die
 Komponente diese Details vor dem Entwickler.
\begin_inset Newline newline
\end_inset

Die Implementierung der Komponente orientiert sich am Facade Entwurfsmuster
 und nutzt frühe Bindung, d.h.
 Delegation zum Zeitpunkt der Kompilierung des Frameworks, um eine Trennung
 zwischen der öffentlichen Schnittstelle der Komponente und der kon\SpecialChar \-
kre\SpecialChar \-
ten
 Implementierung für die jeweiligen GPS-Empfänger zu erreichen.
\begin_inset Newline newline
\end_inset

Die GPS-Nutzdaten werden mit Hilfe der Nachrichtenverteilung des Frameworks
 an re\SpecialChar \-
gistrierte Beobachter versendet.
 Hierbei wird lediglich eine Nachricht an den Beobachter verschickt, die
 signalisiert, dass neue GPS-Daten anliegen.
 Die eigentliche Übermittlung der Nutzdaten an den Beobachter geschieht
 durch lesenden Zugriff auf einen Shared-Memory-Bereich, der vom Beobachter
 initiiert wird.
\end_layout

\begin_layout Subsection
SH4-Plattform
\end_layout

\begin_layout Standard
Der GPS-Empfänger, der auf der SH4-Plattform verfügbar ist, liefert die
 GPS-Daten in Form einer im Dateisystem eingeblendeten Gerätedatei.
 Diese Gerätedatei hat eine feste Größe und ein fest vorgegebenes Binärformat
 in dem die Daten bereitgestellt werden.
 Der Inhalt der Datei wird periodisch mit neuen Daten aktualisiert.
\begin_inset Newline newline
\end_inset


\begin_inset Newline newline
\end_inset

Da das Format der Binärdaten dem eines C-style Structs entspricht kann der
 Dateiinhalt einfach in einen Puffer geladen und dieser wiederum in ein
 passendes Struct gecastet werden.
 Ein Parsing der Binärdaten ist nicht notwendig.
\end_layout

\begin_layout Subsection
x86-Plattform
\end_layout

\begin_layout Standard
Auf den x86-kompatiblen Plattformen (die Entwicklungsrechner im Labor sowie
 das Atom-Testsystem) kann das ICM-Framework sowohl unter QNX als auch unter
 Linux betrieben werden.
 Der verwendete GPS-Empfänger liefert die GPS-Daten in Form eines ASCII
 Datenstroms, der über eine über USB gekapselte serielle Verbindung ausgelesen
 werden kann.
 Der Datenstrom setzt sich aus unterschiedlichen Sätzen im NMEA-Format zusammen.
 Ein NMEA-kompatibler Satz sieht zum Beispiel so aus:
\begin_inset Newline newline
\end_inset


\begin_inset Newline newline
\end_inset


\size footnotesize
$GPRMC,191410,A,4735.5634,N,00739.3538,E,0.0,0.0,181102,0.4,E,A*19
\size default

\begin_inset Newline newline
\end_inset


\begin_inset Newline newline
\end_inset

In diesem Satz enthalten sind die Uhrzeit, nördliche Breite, östliche Länge,
 Geschwindigkeit über Grund, Bewegungsrichtung in Grad, das Datum sowie
 eine Checksumme.
 Handelsübliche GPS-Empfänger unterstützen in der Regel diverse verschiedene
 NMEA-Sätze, deren Länge, laut Spezifikation, 82 Zeichen nicht überschreiten
 darf.
\begin_inset Newline newline
\end_inset


\begin_inset Newline newline
\end_inset

Die Implementierung der Komponente ist für QNX und Linux nahezu identisch,
 da auf eine durchgehende Posix-kompatibilität Wert gelegt wurde.
 Der einzige Unterschied liegt im Namen der Gerätedatei über die auf die
 serielle Schnittstelle zugegriffen wird.
 Dies lässt sich nicht vermeiden, da QNX und Linux Gerätedateien nach einem
 anderen Schema benennen.
 Der Zugriff auf die serielle Schnittstelle wird durch nicht blockierendes
 Lesen unter zu Hilfenahme der Posix-Funktion 
\begin_inset Quotes gld
\end_inset

select
\begin_inset Quotes grd
\end_inset

 realisiert.
 Sobald neue Daten an der seriellen Schnittstelle anliegen werden sie satzweise
 geparst, im Shared-Memory hinterlegt und entsprechende Aktualisierungsnachricht
en an registrierte Beobachter im Framework versendet.
\end_layout

\begin_layout Standard
\begin_inset Newpage newpage
\end_inset


\end_layout

\begin_layout Section
Fahrzeug-Schnittstelle
\end_layout

\begin_layout Standard
Dieser Abschnitt beschreibt zuerst die notwendige Hardware, um ein Rechnersystem
 mit einem Fahrzeug zwecks Datenübertragung zu verbinden.
 Anschließend erfolgt die Vorstellung des Protokolls, um einen bestimmten
 Wert vom Fahrzeug an das Rechnersystem zu übertragen.
 Zuletzt wird die Implementierung einer Komponente für das ICM-Framework
 zum Auslesen und Anzeigen der Motordrehzahl beschrieben.
\end_layout

\begin_layout Subsection
Hardware
\end_layout

\begin_layout Standard
Die mechanische Verbindung des Diagnoseadapters erfolgt über eine genormte
 16-polige Schnittstelle.
 Neben einer Spannungs- und Masseleitung verfügt diese Schnittstelle je
 nach Fahrzeugtyp über unterschiedliche Datenleitungen.
\end_layout

\begin_layout Standard
Am Markt sind unterschiedliche sog.
 Multiprotokoll-Adapter erhältlich, die diese Unterschiede abstrahieren.
 Vor der Anschaffung eines Adapters empfiehlt sich eine Recherche, ob der
 gewünschte Adapter mit dem Fahrzeug kompatibel ist.
 Für dieses Projekt fand ein Adapter vom Typ AGV4000 der Firma OBD-DIAG
 Verwendung.
 Damit konnten erfolgreich Verbindungen zu einem Forst Fiesta MK6 und einem
 Skoda Roomster aufgebaut werden.
 Der Adapter verfügt über eine USB-Schnittstelle, die unter Linux und Windows
 funktioniert.
\end_layout

\begin_layout Subsection
Protokolle
\end_layout

\begin_layout Standard
Ebenso wie bei der mechanischen Schnittstelle existieren modellabhängige
 Unterschiede bei den Protokollen für die Datenübertragung.
 Auch diese Unterschiede abstrahiert ein Multiprotokoll-Adapter mittels
 eines Interpreter-Chips.
 Dieser setzt das fahrzeugspezifische Kommunikationsprotokoll auf einheitliches
 um.
 Beim AGV4000 kommt ein Chip der Firma ELM zum Einsatz, deren Chips auch
 in vielen anderen Adaptern Verwendung finden.
\end_layout

\begin_layout Standard
Das Protokoll zur Kommunikation zwischen Adapter und dem Rechner gliedert
 sich grob in zwei Kategorien.
 Zum einen existieren sog.
 AT-Befehle zur Konfiguration des Adapters selbst, zum anderen Befehle zur
 Kommunikation mit dem Fahrzeug.
 Der AGV4000 verfügt über eine automatische Erkennung des Fahrzeugprotokolls,
 die bei den getesteten Fahrzeugen die richtigen Einstellungen vornahm.
 Alternativ lassen sich die Konfigurationsparameter mittels der entsprechenden
 AT-Befehle einstellen und auslesen.
\end_layout

\begin_layout Standard
Die Abfrage von Fahrzeugdaten erfolgt über sog.
 OBD-II Parameter-IDs, kurz PIDs oder P-Codes.
 Diese sind im Standard SAE J/1979 definiert.
 Nicht alle Fahrzeuge unterstützen alle im Standard definierten PIDs, umgekehrt
 implementieren viele Hersteller zusätzliche PIDs.
 Der Standard ist leider nicht frei verfügbar, allerdings sind die wichtigsten
 PIDs bekannt.
 Allgemein erfolgt die Abfrage eines Fahrzeugdatums durch das Versenden
 des entsprechenden P-Codes an den Adapter.
 Dieser setzt die Anfrage auf das fahrzeugspezifische Protokoll um und versendet
 es an dessen Schnittstelle.
 Von dort wird die Anfrage über den Fahrzeug-Bus, z.
 B.
 CAN, an das zuständige Steuergerät weitergeleitet.
 Dieses verarbeitet die Anfrage und schickt das Resultat über den Fahrzeug-Bus
 zurück an die OBD-Schnittstelle.
 Dort empfängt der Adapter das Resultat, setzt es ggf.
 um und leitet es über die serielle Schnittstelle zum Rechner weiter.
\end_layout

\begin_layout Standard
Eine Anfrage setzt sich aus 4 Zeichen zusammen, wovon jeweils 2 Zeichen
 die hexadezimale Darstellung des Modes und des PIDs bilden.
 Ein abschließendes Carriage-Return-Zeichen führt die Anfrage aus.
 Somit lassen sich OBD-II-Anfragen auch mittels eines Terminal-Programms
 wie HyperTerminal unter Windows ausführen.
 Das Format einer OBD-II-Anfrage folgt dementsprechend der Beschreibung
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

<Mode><PID>
\backslash
r
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Der Mode legt die Art der Anfrage fest, beispielsweise erfolgt die Abfrage
 von aktuellen Daten über den Mode 01 und die Abfrage von Fehlercodes über
 den Mode 03.
 Für das Projekt benötigen wir ausschließlich aktuelle Daten, weshalb wir
 uns auf den Mode 01 beschränken.
\end_layout

\begin_layout Standard
Die PID zur Abfrage der Motordrehzahl lautet 0C.
 Somit ergibt sich die Zeichenkette 
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

100C
\backslash
r
\end_layout

\end_inset


\end_layout

\begin_layout Standard
zur Abfrage der Motordrehzahl.
 Diese ist vom Programm über die serielle Schnittstelle an den Adapter zu
 Versenden.
\end_layout

\begin_layout Standard
Die Antwort erfolgt ebenfalls in Form von hexadezimalen Werten.
 Je nach angefragtem Wert unterscheidet sich die Länge der Antwort.
 Sollte eine Anfrage mehrere Einzelwerte zurück liefern, so sind diese jeweils
 mittels eines Zeilenumbruchs getrennt.
 Dies kann der Fall sein, wenn mehrere Fehlercodes vorliegen.
 In diesem Fall wird jeder Fehlercode in einer eigenen Zeile übertragen.
 Im Normalfall schickt der Adapter nachdem er o.
 g.
 Anfrage erhalten hat nach 20 Millisekunden alle Daten, die er bis zu diesem
 Zeitpunkt vom Fahrzeug empfangen hat, weiter.
 Daraus ergibt sich eine Latenz von 20 Millisekunden zwischen Anfrage und
 Antwort im anfragenden Programm.
\end_layout

\begin_layout Standard
Eine Besonderheit der ELM-Chips liegt in der Möglichkeit durch Angabe der
 erwarteten Zeile in der Antwort die Wartezeit auf die Antwort des Adapters
 zu verkürzen.
 Dazu verstehen ELM-Chips einen zusätzlichen Wert im Anfrage-String:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

<Mode><PID><No of Lines>
\backslash
r
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Der dritte Wert gibt an, nach wie vielen Zeilen der Adapter sofort den Wert
 weiterreichen soll und nicht auf weitere Daten warten soll.
\end_layout

\begin_layout Standard
Da ein Datum für die Motordrehzahl immer aus einer Zeile mit 4 Bytes besteht,
 lässt sich durch diesen Anfrage-String die Antwortzeit deutlich verkürzen:
\end_layout

\begin_layout Standard
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

100C1
\backslash
r
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Das Format einer entsprechenden Antwort lautet 
\begin_inset listings
inline false
status open

\begin_layout Plain Layout

<Mode><PID><A><B>
\backslash
r
\end_layout

\end_inset


\end_layout

\begin_layout Standard
Wobei Mode sich hier aus dem Mode der Anfrage plus 40 hex berechnet, für
 Anfragemode 01 also 41.
 Der PID entspricht dem der Anfrage.
 A und B stellen zwei hexadezimale Zahlen dar, aus denen sich die Motordrehzahl
 nach der Formel 
\end_layout

\begin_layout Standard
\begin_inset Formula $rpm=((A*0x100)+B)/4$
\end_inset

 
\end_layout

\begin_layout Standard
berechnet.
\end_layout

\begin_layout Subsection
Implementierung
\end_layout

\begin_layout Standard
Dieser Abschnitt beschreibt die wichtigsten Aspekte der Implementierung
 der Komponenten für das ICM-Framework zur Abfrage und grafischen Darstellung
 von OBD-II-Daten.
 Die Komponenten sollen auf Linux x86 und QNX x86 lauffähig sein, weshalb
 sich die Implementierung am POSIX-Standard orientiert und nur entsprechende
 System-Routinen verwendet.
 Die grafische Darstellung richtet sich nach dem OpenGL ES Standard.
 Eine Implementierung für QNX auf SH4 Prozessoren erfolgt nicht, da diese
 Zielplattform über keine USB-Schnittstelle zum Anschluss eines OBD-Adapters
 bietet.
\end_layout

\begin_layout Subsubsection
Simulator
\end_layout

\begin_layout Standard
Bei der Entwicklung von OBD-Software erweist sich der Einsatz eines Simulators
 als sehr hilfreich.
 OBD-Simulatoren sind zum Einen am Markt als Hardware-Lösung verfügbar.
 Diese werden mittels OBD-Adapter mit dem Entwicklungsrechner verbunden
 und liefern einstellbare Werte über die OBD-II-Schnittstelle.
 Die Beschaffung eines solchen Simulators befindet sich in der Planung.
 Zum Anderen existiert ein reiner Software-Simulator als Bestandteil des
 Open-Source-Projekts obdgpslogger (http://icculus.org/obdgpslogger/).
 Dieser simuliert auf einem Pseudo-Terminal einen OBD-II-Adapter nach dem
 ELM-Befehlssatz.
 Über eine optionale grafische Oberfläche lassen sich bestimmte Werte einstellen
, die der Simulator über das Pseudo-Terminal an das anfragende Programm
 zurück gibt.
 Die Software ist im Quellcode verfügbar und lässt sich mittels cmake übersetzen.
 Dies war leider auf den Laborrechnern nicht möglich, da einige Bibliotheken,
 von denen obdgpslogger abhängt nicht installiert waren.
 Das cmake Buildsystem liefert eine Liste der fehlenden Bibliotheken, unter
 anderem FLTK für die GUI und FFT.
 Somit erfolgte die Entwicklung auf privaten Rechnern, auf denen die notwendigen
 Bibliotheken installiert werden konnten, um den Simulator von obdgpslogger
 einsetzen zu können.
\end_layout

\begin_layout Subsubsection
Komponente
\end_layout

\begin_layout Standard
Für die Kommunikation mit dem OBD-II-Adapter über die serielle Schnittstelle
 des Rechners erfolgt über ein logisches Device im ICM-Framework.
 Dieses stellt eine eigenständige Komponente dar, die in einer separaten
 Ablaufeinheit ausgeführt wird.
 Die Implementierung erfolgt in einer C++-Klasse, die den Vorgaben des ICM-Frame
works folgt.
 Maßgeblich hierbei sind neben anderen Methoden die init- und run-Methode.
 
\end_layout

\begin_layout Standard
Die init-Methode jeder Komponente wird einmalig beim Start des Frameworks
 ausgeführt.
 Die OBD-Komponente öffnet hier die entsprechende serielle Schnittstelle
 über einen einfachen Mechanismus zur automatischen Erkennung.
 Dieser erleichtert die Entwicklung mit dem Simulator, da dieser bei jedem
 Start das nächste freie Pseudo-Terminal auf einem Linux-System verwendet.
 Deshalb lässt sich nicht von vornherein festlegen, welche Schnittstelle
 von der Komponente zu verwenden ist.
 Ohne diesen Mechanismus müsste nach jedem Start des Simulators der Quellcode
 der Komponente angepasst und neu übersetzt werden.
 Außerdem verbirgt dieser Mechanismus die unterschiedlichen Pfade zur seriellen
 Schnittstelle unter Linux und QNX.
 Nach dem Öffnen der Schnittstelle konfiguriert die init-Methode diese entsprech
end.
 Wichtig ist hierbei die Verwendung der Schnittstelle im Rohdaten-Modus.
 Nach unseren Erfahrungen betreibt Linux eine serielle Schnittstelle standardmäß
ig im kanonischen Modus, was zu einem Problem mit der select-Systemfunktion
 führt.
 Dies wird später genauer erläutert.
\end_layout

\begin_layout Standard
Die run-Methode wird nach der Initialisierung einer Komponente aufgerufen.
 In ihr findet sich die Implementierung der Funktionalität der Komponente.
 Hierbei handelt es sich um eine Endlos-Schleife, die nur unter bestimmten
 Bedingungen verlassen wird.
 In dieser Schleife führt die Komponente drei Aktionen aus.
 Sie schreibt den Anfrage-String auf die serielle Schnittstelle.
 Danach wartet sie ohne CPU-Zeit zu verbrauchen auf die Antwort-Daten.
 Im dritten Schritt verarbeitet sie die empfangenen Daten, legt sie im Datencont
ainer ab und schickt eine entsprechende Nachricht über den Main Dispatcher
 des Frameworks.
\end_layout

\begin_layout Standard
Für das Warten ohne CPU-Zeit bietet sich auf POSIX-Systemen die Systemfunktion
 select an.
 Diese blockiert den aufrufenden Thread und kehrt entweder nach einem konfigurie
rbaren Timeout oder bei empfangenen Daten zurück.
 Hierbei trat das oben erwähnte Problem auf.
 Im kanonischen Modus erkennt das System nicht, dass neue Daten an der Schnittst
elle anliegen und kehrt erst nach Ablauf des Timeouts zurück.
 Je nach Höhe des Timeouts führt dieses Verhalten zu einer sehr ruckeligen
 Darstellung des Drehzahlmessers.
 Erst bei Betrieb der seriellen Schnittstelle im Rohdaten-Modus arbeitet
 die select-Funktion wie erwartet.
 Dieses Problem tritt bei der GPS-Komponente nicht auf, dort arbeitet die
 serielle Schnittstelle im kanonischen Modus korrekt.
\end_layout

\begin_layout Subsubsection
Datencontainer
\end_layout

\begin_layout Standard
Gemäß den Vorgaben des ICM-Frameworks handelt es sich bei einem Datencontainer
 um einen Bereich im Shared-Memory, auf den mehrere Komponente zugreifen
 und so Daten austauschen.
 Hierbei ist besonders darauf zu achten, dass die Zugriffe auf das Shared
 Memory über einen Mutex geschützt werden.
 Dies erfolgt in der Implementierung des Datencontainers, so dass dieser
 Synchronisierungsmechanismus vor dem Benutzer des Datencontainers verborgen
 wird.
 Die Motordrehzahl wird als Fließkommazahl im Shared Memory abgelegt.
 Der Zugriff auf den Datencontainer erfolgt über zwei Zugriffsklassen, die
 in den folgenden Abschnitten beschrieben werden.
\end_layout

\begin_layout Paragraph
Accessor-Klasse
\end_layout

\begin_layout Standard
Diese Klasse kapselt den schreibenden Zugriff durch Komponenten auf den
 Datencontainer.
 Die OBD-Komponente verwendet diese Klasse, um die aktuell empfangene Drehzahl
 im Datencontainer speichern.
\end_layout

\begin_layout Paragraph
Adapter-Klasse
\end_layout

\begin_layout Standard
Für den lesenden Zugriff auf den Datencontainer stellt die Adapter-Klasse
 eine Methode für jeden Wert im Datencontainer bereit.
 Somit bleibt Client-Komponenten der innere Aufbau des Datencontainers verborgen.
\end_layout

\begin_layout Subsubsection
Digitaler Drehzahlmesser
\end_layout

\begin_layout Standard
Eine weitere Komponente übernimmt die Darstellung der Motordrehzahl auf
 dem Bildschirm.
 Die Darstellung orientiert sich an einem analogen Drehzahlmesser, wie er
 aus Fahrzeugen bekannt ist.
 Dabei kommen meist Kreisinstrumente mit Drehzeiger zum Einsatz.
 Der Drehwinkel des Zeiger veranschaulicht die Motordrehzahl.
\end_layout

\begin_layout Standard
Um auch hier CPU-Zeit ein zu sparen, zeichnet die Komponente nicht ständig
 die Anzeige neu, sondern nur wenn neue Daten vorhanden sind.
 Der Einfachheit halber erfolgt diese Synchronisation über den Nachrichten-Dispa
tcher der Komponente.
 Dieser blockiert auf einem binären Semaphore im Kontext der Komponente.
 Die Update-Nachrichten der OBD-Komponente sind an diese Komponente adressiert.
 Somit der Dispatcher der Komponente bei jeder neuen OBD-Update-Nachricht
 geweckt.
 Diese Nachrichten treffen nur ein, wenn neue OBD-Daten im Datencontainer
 vorliegen.
 Nach dem Verarbeiten einer OBD-Update-Nachricht, was sich auf den Empfang
 beschränkt, liest die Komponente die neue Motordrehzahl über die Adapter-Klasse
 aus dem Datencontainer.
\end_layout

\begin_layout Standard
Mit diesem Wert berechnet sie den Drehwinkel des OpenGL-Zeigers neu und
 rendert den Anzeigebildschirm.
 Jetzt blockiert die Komponente bis zum Eintreffen einer neuen OBD-Update-Nachri
cht.
\end_layout

\end_body
\end_document