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 --- .../Projekt Systementwicklung/obd-ausarbeitung.lyx | 536 +++++++++++++++++++++ 1 file changed, 536 insertions(+) create mode 100644 Master/Projekt Systementwicklung/obd-ausarbeitung.lyx (limited to 'Master/Projekt Systementwicklung/obd-ausarbeitung.lyx') diff --git a/Master/Projekt Systementwicklung/obd-ausarbeitung.lyx b/Master/Projekt Systementwicklung/obd-ausarbeitung.lyx new file mode 100644 index 0000000..75d2fac --- /dev/null +++ b/Master/Projekt Systementwicklung/obd-ausarbeitung.lyx @@ -0,0 +1,536 @@ +#LyX 1.6.7 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 - Komponente für das ICM Framework +\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 SS2010 +\end_layout + +\begin_layout Publishers +betreut von Prof. + Dr. + Wietzke und Prof. + Dr. + Hergenröther +\end_layout + +\begin_layout Section +Zielsetzung +\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 Section +Fahrzeug-Schnittstelle +\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 Section +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 Subsection +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 Subsection +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 Subsection +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 Subsubsection +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 Subsubsection +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 Subsection +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