1 files changed, 58 insertions, 0 deletions
diff --git a/Master/Masterarbeit/thesis/tex/introduction.tex b/Master/Masterarbeit/thesis/tex/introduction.tex
new file mode 100644
index 0000000..52ffb01
--- /dev/null
+++ b/Master/Masterarbeit/thesis/tex/introduction.tex
@@ -0,0 +1,58 @@
+\setchapterpreamble[u]{%
+	\dictum[Antoine de Saint-Exupery]{Ein Text ist nicht dann vollkommen, wenn man nichts mehr hinzufügen kann, sondern dann, wenn man nichts mehr weglassen kann.}\bigskip}
+\chapter{Einleitung}
+\label{chp:introduction}
+Dieses Kapitel beschreibt zuerst die Motivation zur Erstellung dieser Arbeit. Der anschließende Abschnitt formuliert die Problemstellung, um die sich die Arbeit dreht. Abschließend liefert dieses Kapitel eine Übersicht über die nachfolgenden Kapitel und deren Inhalt. 
+
+\section{Motivation}
+\label{sec:motivation}
+
+Leistungsfähige Fahrerassistenzsysteme und komplexe Anzeigeinstrumente prägen den technischen Fortschritt im Automobilbereich. Viele Hersteller sehen in diesen Systeme eine Möglichkeit, sich von der Konkurrenz ab zu heben und Alleinstellungsmerkmale zu entwickeln. Hiervon hängt der Erfolg ihrer Produkte am Markt ab.
+
+Den Kern solcher Systeme bildet komplexe Software, die auf leistungsfähiger Hardware läuft. Hierbei handelt es sich um Mikrocontroller mit entsprechender Rechenleistung, um die komplexe Software auszuführen. Eine solche Einheit aus Hardware und Software bezeichnet man in diesem Kontext als Steuergerät. Einem Steuergerät kommt dabei die Regelung einer oder weniger Funktionen im Fahrzeug zu. Klassische Beispiele hierfür stellen die Regelung der Motoreinspritzung oder des Antiblockiersystems dar. Ebenso erfolgt die Steuerung des Kombiinstruments in modernen Fahrzeugen durch ein Steuergerät. Dabei berechnet das Steuergerät den Drehwinkel eines Schrittmotors zur Darstellung der aktuellen Geschwindigkeit auf einem Tachometer mit mechanischem Zeiger. Daneben existieren Anzeigesysteme ohne mechanische Zeiger. Diese zeigen dem Fahrer die Nachbildung eines klassischen Zeigerinstruments auf einem Bildschirm, zum Teil in dreidimensionaler Darstellung. Ebenso sind sog. Head-Up Displays erhältlich, die ihre Informationen direkt ins Blickfeld des Fahrers auf die Innenseite der Windschutzscheibe projizieren. Da die meisten Windschutzscheiben gekrümmt sind, muss diese Krümmung bei der Berechnung der Darstellung berücksichtigt werden.
+
+Diese Beispiele zeigen, welche Aufgaben Steuerungssoftware im Auto heute bewältigen muss. Hinzu kommt eine vielfältige Kommunikation der Steuergeräte untereinander. So benötigt die Geschwindigkeitsanzeige eben dieses Datum von dem Steuergerät, das dafür zuständig ist. Kaum ein Steuergerät im Fahrzeug kann seine Aufgabe autark erfüllen, woraus sich die Notwendigkeit von Kommunikationsmedien zwischen den Steuergeräten ergibt.
+
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{\linewidth}
+\includegraphics[width=\linewidth]{can-ecu-network}
+\linebreak
+\tiny \centering Quelle: Volkswagen
+\end{minipage}
+\caption{Beispiel vernetzter Steuergeräte}
+\label{fig:canecunetwork}
+\end{figure}
+
+Die Abbildung \ref{fig:canecunetwork} zeigt ein Beispiel für die komplexe Vernetzung von Steuergeräten in modernen Fahrzeugen. \cite{SSH11} sprechen von 70 Steuergeräten in Fahrzeugen der Premiumklasse und einem Datenaufkommen von etwa 15000 Botschaften pro Sekunde. Dieses hohe Datenaufkommen stellt die Hersteller vor neue Herausforderungen bei der Analyse und Fehlersuche. Wie \cite{SSH11} darstellen, besteht hierbei beispielsweise der Bedarf an einer grafischen Darstellung der Änderungen eines Wertes aus der Datengesamtheit über die Zeit. 
+
+Aus der vorgestellten Komplexität der Systeme lässt sich erkennen, dass die Entwicklung und der Test dieser Systeme sehr aufwändig ist. Besonders bei sicherheitsrelevanten Funktionen kommen sehr detailliert ausgearbeitete Softwareentwicklungsprozesse zum Einsatz, um die Zuverlässigkeit der Systeme sicher zu stellen. Dazu gehören ausgiebige Tests, vom Test einzelner Softwaremodule über Integrationstests bestimmter Komponenten bis hin zu Systemtests des gesamten Systems.
+
+Unter Berücksichtigung der oben dargestellten Vernetzung der Steuergeräte lässt sich erkennen, dass der Test eines Steuergeräts in Isolation kaum möglich ist. Sein Verhalten hängt sehr stark vom Verhalten anderer Systeme ab. D. h. um ein Steuergerät in vollem Umfang testen zu können, besteht der Bedarf an allen anderen Steuergeräten, mit denen das zu testenden Gerät kommuniziert. In der Entwicklungspraxis lässt sich dieser Bedarf allerdings nicht decken, da sich die benötigten Geräte oft selbst noch in der Entwicklung befinden und ihrerseits das zu testende Steuergerät benötigen, um getestet zu werden. Erschwerend kommt die Verteilung der Entwicklung über mehrere Standort hinzu. 
+Abhilfe schafft hier die Tatsache, dass für Entwicklung und Test nicht das physische Gerät benötigt wird, sondern nur sein Verhalten und die Daten, die es versendet. Beides ist aus umfangreichen Spezifikationsdokumenten der jeweiligen Komponenten bekannt und lässt sich somit simulieren. Eine solche Simulation befreit die Entwicklung und die frühen Testphasen vom Bedarf an realen Steuergeräten. Diese Simulation von Steuergeräten erfolgt durch entsprechende Programme, sog. Restbussimulationen.
+
+Zur Simulation vernetzter Steuergerät hat die Schleißheimer GmbH die Software CanEasy \index{CanEasy} entwickelt. Dabei handelt es sich um eine Software für PCs mit dem Betriebssystem Microsoft Windows. Die Bedienung der Software erfolgt über eine grafischer Benutzungsschnittstelle zur Definition der Busse mit Steuergeräten. Jedes Steuergerät versendet einzelne Nachrichten mit bestimmten Daten, sog. Signalen. CanEasy versendet dabei Nachrichten von Steuergeräten, die es simuliert, und zeichnet Nachrichten von real existierenden Steuergeräten auf. Ebenso bietet es die Möglichkeit der grafischen Darstellung aufgezeichneter Daten, beispielsweise in Graphen, wie in \cite{SSH11} beschrieben. Bei Tests und der Fehleranalyse ist die zeitlich exakte Abfolge von bestimmten Ereignissen auf dem Bus besonders wichtig, um bestimmte Situationen her zu stellen. Zur Kommunikation mit den realen Steuergeräten benötigt CanEasy immer separate Hardware für die verwendete Bus-Technologie.
+
+Die Firma X2E stellt die Hardware \myxc \index{\myxc}, im Folgenden kurz Xoraya genannt, her, die über vielfältige Hardwareschnittstellen für alle heute in Fahrzeugen gängigen Bus-Technologien verfügt. X2E stellt dem Benutzer daneben eine Umgebung zur Entwicklung eigener Software für die Xoraya bereit. Auf diese Weise erhält der Benutzer die Möglichkeit, die vielfältigen Hardwareschnittstellen der \myxc~mit eigener Software zu bedienen und beliebige Applikationen zu entwickeln, die auf der \myxc~ausgeführt werden. Allerdings verfügt die Xoraya über keine grafische Benutzerschnittstelle.
+
+\section{Problemstellung und Zielsetzung}
+\label{sec:goal}
+Aus den vorherigen Abschnitten ergeben sich einige Schwachstellen von CanEasy und \myxc. CanEasy läuft auf einem Betriebssystems, das für die pseudoparallele Ausführung mehrerer Anwendungen konzipiert ist. Dabei versucht es, alle Anwendungen gleich zu behandeln. Diese Eigenschaft kann unter Umständen die Ausführung einer Anwendung um wenige Millisekunden verzögern. Für den Bediener einer GUI ist dies in den meisten Fällen ohne Bedeutung. Geht es allerdings um eine zeitlich präzise Steuerung im Millisekundenbereich, kann diese Verzögerung gravierende Auswirkungen haben. Aus diesem Grund lassen sich nur sehr ungenaue Aussagen über das zeitliche Verhalten von CanEasy machen, da dieses immer von der Belastung des Rechners durch andere Anwendungen abhängt.
+
+Im Gegensatz dazu befähigen Hardware und Betriebssystem die \myxc~zu einem zeitlich sehr präzisen Verhalten. Allerdings benötigt der Benutzer umfangreiche Kenntnisse in der Softwareentwicklung, um auch nur eine einzige Botschaft mit der \myxc~auf einem Bus zu versenden oder zu empfangen. Die Entwicklung dieser Software verursacht zusätzliche Aufwände, die Ressourcen binden, Zeit benötigen und somit Geld kosten.
+
+Das Ziel dieser Arbeit besteht darin, einen Synergieeffekt aus den beiden oben genannten Systemen zu schaffen. Dieser soll aus einem neuen Gesamtsystem bestehen, das sich über eine GUI bedienen lässt und gleichzeitig ein  präzises zeitliches Verhalten beim Versand und Empfang von Botschaften auf Kommunikationsbussen zeigt.
+
+Da der CAN-Bus heute und in absehbarer Zukunft die in der Praxis verwendete Bus-Technologie zur Anbindung von Kombiinstrumenten darstellt und die Schleißheimer GmbH hauptsächlich Software für Kombiinstrumente entwickelt, liegt der Fokus der Arbeit auf der Nutzung der CAN-Schnittstellen der \myxc.
+
+\section{Übersicht}
+\label{sec:overview}
+Kapitel~\ref{chp:fundamentals} geht auf die Grundlagen, auf denen diese Arbeit basiert, ein. Die Schwerpunkte bilden hierbei die Themen Echzeit-Systeme, Repräsentation von Objekten und ein Schedulability-Test für den CAN-Bus.
+
+Kapitel~\ref{chp:concept} beschreibt zuerst CanEasy und \myxc~als technische Ausgangspunkte und geht auf die spezifischen Eigenschaften beider Komponenten ein. Danach beschreibt es das im Rahmen dieser Arbeit erstellte Konzept zur Erreichung des vorgenannten Ziels. Es berücksichtigt dabei die spezifischen Eigenschaften der jeweiligen Systeme. An manchen Stellen bieten sich mehrere Alternativen zur Lösung einer konzeptionellen Problemstellung. Hier erfolgt eine Abwägung der Optionen, falls sich auf konzeptioneller Ebene schon eine bestimmte Entscheidung begründen lässt. Andernfalls verlagert sich die Entscheidung in spätere Kapitel. Weiterhin stellt dieses Kapitel ein Konzept zur Bewertung der Ergebnisse der prototypischen Implementierung vor.
+
+Darauf erfolgt in Kapitel~\ref{chp:prototype} eine Beschreibung der Softwarekomponenten, die für die verschiedenen Systeme im Rahmen der prototypischen Implementierung entwickelt wurden. Neben einer Beschreibung des Gesamtsystems geht dieses Kapitel auf bestimmte Details der Implementierung ein.  Es läutert deren besondere Bedeutung für das Gesamtsystem und verdeutlicht die Design- und Implementierungsentscheidungen.
+
+Kapitel~\ref{chp:results} bietet eine Auswertung der Ergebnisse des in Kapitel~\ref{chp:prototype} beschriebenen Prototyps. Ebenso beschreibt es die Metriken, anhand derer die Bewertung der Ergebnisse erfolgt und vergleicht sie mit alternativen Produktkombinationen.
+
+Kapitel~\ref{chp:summarization} fasst die Erkenntnisse der Arbeit zusammen und liefert eine kritische Betrachtung. Es analysiert, welche Teile der Zielsetzung diese Arbeit erreichen konnte und welche nicht. Es listet weiterhin Fragen auf, die im Rahmen dieser Arbeit nicht geklärt werden konnten oder sich erst im Verlauf der Arbeit ergaben. Abschließend betrachtet es verschiedene Richtungen, in die, basierend auf dieser Arbeit, in Zukunft weiter gearbeitet werden kann.
+\ No newline at end of file