#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 \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 \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 \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