From 33613a85afc4b1481367fbe92a17ee59c240250b Mon Sep 17 00:00:00 2001 From: Sven Eisenhauer Date: Fri, 10 Nov 2023 15:11:48 +0100 Subject: add new repo --- .../mpse1-ausarbeitung.lyx | 822 +++++++++++++++++++++ 1 file changed, 822 insertions(+) create mode 100644 Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx (limited to 'Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx') diff --git a/Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx b/Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx new file mode 100644 index 0000000..d0e370b --- /dev/null +++ b/Master/Projekt Systementwicklung/mpse1-ausarbeitung.lyx @@ -0,0 +1,822 @@ +#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 -- cgit v1.2.3