add new repoHEADmaster

1 files changed, 415 insertions, 0 deletions

diff --git a/Master/Masterarbeit/thesis/tex/concept.tex b/Master/Masterarbeit/thesis/tex/concept.tex
new file mode 100644
index 0000000..360dba4
--- /dev/null
+++ b/Master/Masterarbeit/thesis/tex/concept.tex
@@ -0,0 +1,415 @@
+\setchapterpreamble[u]{%
+	\dictum[Linus Torvalds]{Controlling a laser with Linux is crazy, but everyone in this room is crazy in his own way. So if you want to use Linux to control an industrial welding laser, I have no problem with your using PREEMPT\_RT.}\bigskip}
+\chapter{Konzept}\label{chp:concept}
+Dieses Kapitel beschreibt den konzeptionellen Entwurf zur Integration von CanEasy und \myxc. Dazu stellt der erste Abschnitt die beteiligten Systeme vor, da deren Eigenschaften Einfluss auf den konzeptionellen Entwurf haben. Der folgende Abschnitt formuliert weitere Forderungen, die den Entwurf beeinflussen. Danach wird die Architektur des Gesamtsystems skizziert. Die detaillierte Beschreibung der Entwürfe der einzelnen Komponenten folgt in den weiteren Abschnitten. Der letzte Abschnitt zeigt das Konzept zur Überprüfung der einzelnen Komponenten hinsichtlich ihrer Leistungsfähigkeit und Erfüllung der Anforderungen.
+%=========================================================================
+\section{Technische Ausgangsbasis}
+\label{sec:con:techbase}
+Um einen Überblick über das technische Umfeld, in dem sich dieses Konzept befindet, zu verschaffen, stellt dieser Abschnitt nacheinander die beteiligten Komponenten vor. Merkmale, die für das Verständnis nicht relevant sind und keinen Einfluss auf das Konzept haben, werden nicht berücksichtigt. Vollständige Beschreibungen der Produkte liefern die jeweiligen Dokumentationen.
+\subsection{CanEasy}
+\label{sec:caneasy}\index{CanEasy}
+Wie schon in Kapitel \ref{chp:introduction} erwähnt, handelt es sich bei CanEasy um eine Restbus-Simulations-Software für PCs mit dem Betriebssystem Microsoft Windows der Firma Schleißheimer GmbH. Es ist in C/C++ geschrieben und verwendet die Microsoft MFC als GUI-Framework. Zur Kommunikation mit Bus-Systemen verfügt es über Treiber für vielfältige Hardware-Adapter. Über diese Schnittstellen sendet und empfängt es Daten, die es auf vielfältige Weise anzeigen und weiterverarbeiten kann. Der Begriff \textit{Host} bezeichnet im Folgenden einen PC mit CanEasy.
+\subsubsection{Datenmodell - Die Datenbasis}
+Eine zentrale Komponente von CanEasy bildet die sog. Datenbasis. Hierin ist die komplette Topologie der definierten Busse hinterlegt. Dabei spielen folgenden Klassen eine wichtige Rolle:
+\begin{description}
+\item [Bus] Einem Bus ist ein Hardware-Adapter zugeordnet, womit Busse die obersten Knoten in der Objekthierarchie unterhalb der Wurzel darstellen.
+\item [Steuergerät] Ein Steuergerät gehört zu einem Bus. Steuergeräte können als real oder simuliert definiert werden. Bei simulierten Steuergeräten versendet CanEasy die Nachrichten dieser Steuergeräte auf dem zugehörigen Bus. Bei realen empfängt es Nachrichten auf dem entsprechenden Bus und ordnet sie dem entsprechenden Steuergerät in der Datenbasis zu.
+\item [Nachrichten] repräsentieren CAN-Frames mit ID, Daten und der Sendesteuerung. Diese definiert, ob die Nachricht zyklisch oder nur auf Benutzerwunsch gesendet werden soll.
+\item [Signale] stellen eine Sicht auf die Daten einer Nachricht dar. Jedes Signal bezeichnet einen bestimmten Bereich von Datenbits der zugehörigen Nachricht und wie diese zu interpretieren sind.
+\end{description}
+Darüber hinaus lassen sich für jedes Objekt benutzerspezifische Attribute definieren. CanEasy bietet eine breite Palette an Möglichkeiten zur Integration. Es liefert einen Assistenten zur Einrichtung von Visual Studio Projekten, mit denen benutzerspezifische Plugins (siehe \ref{sec:con:caneasyplugins}) in C/C++ erstellt werden können. Weiterhin verfügt es über eine VBA-Schnittstelle mit der ebenfalls benutzerspezifische Funktionalität intergrieren lässt. Darüber hinaus bietet es Import- und Exportfunktionen verschiedener Dateiformate für Aufzeichnungen und Datenbasen.
+
+\subsubsection{GUI}
+Die Abbildung \ref{fig:caneasy_mainscreen} zeigt den Hauptbildschirm von CanEasy mit der hierarchischen Gliederung der Elemente der Datenbasis.
+
+Hieran lässt sich deutlich die oben beschriebene Baumstruktur der Datenbasis erkennen. Ebenso verfügt CanEasy über die Möglichkeit Signalverläufe über die Zeit grafisch darzustellen. Sog. Plots dienen zur Analyse des zeitlichen Verlaufs von Signalwerten, wie in \cite{SSH11} gefordert (siehe Abbildung \ref{fig:burst_rx_xc}). Sog. Traces stellen die Aufzeichnung tabellarisch dar, wobei über Filter einstellbar ist, welche Daten angezeigt werden.
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{\linewidth}
+\includegraphics[width=\linewidth]{caneasy_mainscreen}
+\end{minipage}
+\caption{CanEasy Hauptbildschirm}
+\label{fig:caneasy_mainscreen}
+\end{figure}
+
+\subsubsection{Plugin-Konzept}\label{sec:con:caneasyplugins}
+Wie oben erwähnt, bietet CanEasy flexible Erweiterungsmöglichkeiten durch Plugins. Dabei handelt es sich um zur Laufzeit nachladbare Module, die dem Benutzer gewisse Funktionen bereitstellen. CanEasy unterscheidet dabei zwei Arten von Plugins:
+\begin{description}
+\item [System-Plugins] Teile der Grundfunktionalität von CanEasy sind in sog. Systemplugins ausgelagert. Diese werden beim Start automatisch geladen.
+\item [User-Plugins] Hierbei handelt es sich um benutzerspezifische Erweiterungen für CanEasy, die separat geladen werden müssen. CanEasy bietet zur Erstellung solcher User-Plugins einen Assistenten und eine API für den Zugriff auf CanEasy durch das User-Plugin. Dabei liegen allerdings nicht alle Funktionen von CanEasy offen.
+\end{description}
+%=========================================================================
+\subsection{\myxc}
+\label{sec:con:xoraya}\index{\myxc}
+Die Firma X2E GmbH bietet mit dem Produkt \myxc~eine flexible und leistungsfähige Plattform zur Anbindung von Datenbussen im Fahrzeug an. In dieser Arbeit wird der Begriff \textit{Target} als Synonym für \myxc~verwendet.
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{.5\linewidth}
+\includegraphics[width=\linewidth]{xoraya_connect_foto}
+\includegraphics[width=\linewidth]{xoraya_connect_front}
+\includegraphics[width=\linewidth]{xoraya_connect_rear}
+\end{minipage}
+\caption{Ansichten der \myxc}
+\label{fig:xoraya}
+\end{figure}
+
+Die Abbildung \ref{fig:xoraya} aus \cite{Sch11a} zeigt verschiedene Ansichten der \myxc~und deren Anschlüsse.
+%=========================================================================
+\subsubsection{CPU}
+Den Kern der \myxc~bildet ein FPGA, in dem die Hardwarezellen für die einzelnen Bussysteme sowie ein Hauptprozessor integriert sind. Die CPU weist folgende Eigenschaften auf:
+\begin{description}
+\item[Architktur] PowerPC
+\item[Taktfrequenz] 500 MHz
+\end{description}
+Außerdem verfügt das System über 256 MB RAM, Hardware-Timer und stellt global Zeitstempel mit einer Auflösung von 100 Nanosekunden bereit.
+%=========================================================================
+\subsubsection{Hardware-Schnittstellen}
+Das Angebot an unterstützten Schnittstellen der \myxc~umfasst zum Zeitpunkt der Erstellung der Arbeit
+\begin{itemize}
+\item Ethernet
+\item CAN (Highspeed und Lowspeed)
+\item LIN
+\item FlexRay
+\item MOST25
+\item MOST150
+\end{itemize}
+Durch den modularen Aufbau lassen sich die Schnittstellen nahezu frei zusammenstellen. Das von der Firma X2E zur Erstellung dieser Arbeit bereit gestellte Exemplar verfügt über eine CAN Lowspeed Schnittstelle und fünf CAN Highspeed Schnittstellen.
+%=========================================================================
+\subsubsection{Betriebssystem}
+Auf der \myxc~findet ein modifiziertes Ubuntu Linux mit Kernel 3.0 und \nameref{sec:fun:PREEMPTRT}
+als Betriebssystem Verwendung.
+%=========================================================================
+\subsubsection{SDK}
+\label{sec:con:X2Esdk}
+Zur Entwicklung eigener Software stellt X2E ein SDK bereit. Es basiert auf der freien Entwicklungsumgebung Eclipse. Neben der Entwicklungsumgebung enthält es u. a. Bibliotheken für den Zugriff auf die spezielle Hardware der \myxc~mit C/C++. Darüber hinaus enthält es die C++-Bibiliothek boost in der Version 1.46.0 \cite{Boo11}. Die Toolchain des SDK umfasst alle nötigen Programme, Bibliotheken und Debugger, um Programme für die \myxc~zu erstellen und zu debuggen. Die Toolchain erfordert einen PC mit dem Betriebssystem Windows der Firma Microsoft. Die Erstellung von Programmen oder Bibliotheken auf dem Windows PC für die \myxc~trägt ab hier auch die Bezeichnung \textit{cross-compile}.
+%=========================================================================
+\subsection{Atmel AT32UC3C-EK}
+\label{sec:con:at32uc3c}
+\index{AT32UC3C}
+Die Firma Atmel bietet mit dem Produkt AT32UC3C-EK eine Evaluationsplatine für ihren Mikrocontroller AT32UC3C0512C an. Dabei handelt es sich um einen 32-Bit RISC Prozessor, der unter anderem über Highspeed CAN-Schnittstellen verfügbar. Der Kern des Prozessors erlaubt gemäß Datenblatt (\cite{AT32UC3C:datasheet}) eine Taktrate bis zu 66 Mhz. Die Evaluationsplatine verfügt weiterhin u. a. über 4 LEDs und 2 Taster.
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{.5\linewidth}
+\includegraphics[width=\linewidth]{at32uc3c-ek}
+\linebreak
+\tiny \centering Quelle: Atmel Corporation
+\end{minipage}
+\caption{Atmel AT32UC3C-EK}
+\label{fig:at32uc3c-ek}
+\end{figure}
+%==========================================================
+\section{Anforderungen}
+Von Seiten der Firmen Schleißheimer GmbH und X2E GmbH bestehen folgende Forderungen, die der in Kapitel \ref{chp:prototype} vorgestellte Prototyp erfüllen soll:
+\begin{itemize}
+\item Die \myxc~soll autark, d. h. ohne Verbindung zu einer CanEasy-Instanz, beispielsweise im Fahrzeug, arbeiten können. Dazu soll die Definition einer Datenbasis am PC erfolgen, die \myxc~entsprechend konfiguriert und ins Fahrzeug eingebaut werden. Die \myxc~versendet alle definierten Nachrichten in ihrem jeweiligen Intervall und zeichnet alle empfangenen Botschaften zur späteren Auswertung in CanEasy auf.
+\item Die kleinste definierbare Zeiteinheit in der Datenbasis von CanEasy beträgt eine Millisekunde. Alle Teile dieser Arbeit sollen mindestens diese zeitlich Genauigkeit einhalten.
+\item Beim Senden und Empfangen auf dem CAN Bus darf es nicht zum Verlust von Botschaften kommen.
+\item Besteht eine Verbindung zwischen CanEasy und der \myxc, sollen Änderungen an den Datenbytes einer Botschaft durch den Benutzer ohne weitere Interaktion übertragen und verarbeitet werden.
+\end{itemize}
+Das hier vorgestellte Konzept muss diese Anforderungen ebenfalls berücksichtigen.
+%==========================================================
+\section{Anwendungsfälle}
+Aus Sicht des Anwenders ergeben sich die in Abbildung \ref{fig:con:usecases} gezeigten Anwendungsfälle.
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{.75\linewidth}
+\includegraphics[width=\linewidth]{usecases}
+\end{minipage}
+\caption{Anwendungsfälle}
+\label{fig:con:usecases}
+\end{figure}
+Die nachfolgende Liste erläutert die einzelnen Anwendungsfälle.
+\begin{description}
+\item[Connect] Dieser Anwendungsfall baut eine Netzwerkverbindung zur \myxc~auf. Alle weiteren Anwendungsfälle setzen direkt oder indirekt eine bestehende Netzwerkverbindung voraus.
+\item[Disconnect] Dieser Anwendungsfall trennt die bestehende Verbindung zur \myxc. Er setzt eine bestehende Netzwerkverbindung zur \myxc~voraus.
+\item[Shutdown] Dieser Anwendungsfall sendet eine Netzwerkanfrage zum Beenden zur \myxc~und trennt anschließend die Verbindung. Er setzt eine bestehende Netzwerkverbindung zur \myxc~voraus.
+\item[Enumerate Interfaces] Dieser Anwendungsfall ruft eine Liste mit verfügbaren CAN-Hardwareschnittstellen der \myxc~ab. Er setzt eine bestehende Netzwerkverbindung zur \myxc~voraus.
+\item[Map Bus] Dieser Anwendungsfall verknüpft einen Bus der CanEasy-Datenbasis mit einer Hardwareschnittstelle der \myxc. Er setzt eine Liste der Hardwareschnittstellen der \myxc~voraus und führt den Anwendungsfall \texttt{Stop Bus} für die neu verknüpfte Hardwareschnittstelle und den neu verknüpften Bus aus.
+\item[Unmap Bus] Dieser Anwendungsfall hebt eine Verknüpfung zwischen einem Bus der CanEasy-Datenbasis und einer Hardware-Schnittstelle der \myxc~auf. Vor der Aufhebung der Verknüpfung stoppt dieser Anwendungsfall die entsprechende Hardware-Schnittstelle der \myxc.
+\item[Start Bus] Dieser Anwendungsfall startet die Simulation eines Busses aus der CanEasy-Datenbasis auf der verknüpften Hardware-Schnittstelle der \myxc. Zuvor stoppt er die entsprechende Hardware-Schnittstelle der \myxc. Dieser Anwendungsfall setzt eine bestehende Netzwerkverbindung zur \myxc~voraus.
+\item[Stop Bus] Dieser Anwendungsfall stoppt die Simulation eines Busses aus der CanEasy-Datenbasis auf der verknüpften Hardware-Schnittstelle der \myxc~und setzt eine bestehende Netzwerkverbindung zur \myxc~voraus.
+\item[Update Message Data] Dieser Anwendungsfall überträgt geänderte Nachrichtendaten für simulierte Busse auf die \myxc. Dieser Anwendungsfall setzt eine gestartete Simulation voraus.
+\item[View Log] In diesem Anwendungsfall lädt der Benutzer eine bestehende Aufzeichnungsdatei in CanEasy. Dieser Anwendungsfall setzt eine konvertierte Aufzeichnungsdatei des Anwendungsfall \texttt{Import Log} voraus.
+\item[Enumerate Logs] Dieser Anwendungsfall ruft die Liste der auf der \myxc~verfügbaren Aufzeichnungsdateien ab. Dazu setzt er eine bestehende Verbindung zur \myxc~voraus.
+\item[Import Log] Dieser Anwendungsfall ruft die ausgewählte Aufzeichnung der \myxc~ab und konvertiert sie in das interne Aufzeichnungsformat von CanEasy. Dazu setzt er eine bestehende Verbindung zur \myxc~und eine abgerufene Liste von verfügbaren Aufzeichnungsdateien voraus.
+\end{description}
+%=========================================================================
+\section{Architektur des Gesamtsystems}
+\label{sec:architecture}
+Ausgehend von den o. g. Anforderungen und den technischen Voraussetzungen liefert eine erste Analyse eine grobe Architektur des Gesamtsystems. Die Architektur der Gesamtsystems lässt sich Abbildung \ref{fig:architecture} entnehmen.
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{\linewidth}
+\includegraphics[width=\linewidth]{architecture}
+\end{minipage}
+\caption{Systemarchitektur}
+\label{fig:architecture}
+\end{figure}
+Die Architektur umfasst dabei zwei Hauptkomponenten:
+\begin{description}
+\item[CanEasy--seitig] Zur Definition der Datenbasis und Darstellung der empfangenen Daten verwendet das Konzept die bestehenden Komponenten von CanEasy. Zur Steuerung der \myxc~muss neue Software entwickelt werden.
+\item[\myxc--seitig] Für den Versand und Empfang von CAN Botschaften auf dem Target muss ebenfalls neue Software entwickelt werden. Ebenso bedarf es Komponenten zur Steuerung und Kommunikation.
+\end{description}
+Der Benutzer ordnet dabei einem Bus in der CanEasy--Datenbasis eine Schnittstelle der \myxc~zu. Zwischen diesen beiden Entitäten besteht eine Eins--zu--Eins--Beziehung.
+
+Der Datenaustausch zwischen \myxc~und CanEasy erfolgt über Ethernet mittels TCP/IP-Protokoll, Version 4.
+%=========================================================================
+\section{Repräsentation der Datenbasis}
+\label{sec:databasetransfer}
+Dieser Abschnitt beschreibt das gewählte Konzept zur Übertragung der CanEasy-Datenbasis auf die \myxc. Das Konzept beschreibt an dieser Stelle die Repräsentationsform für Objekte der CanEasy-Datenbasis zwecks der Übertragung auf die \myxc~und des Ladens ins RAM der \myxc. Der Abschnitt \ref{sec:fund:objrepr} beschreibt mehrere mögliche Repräsentationsformen, die alle prinzipiell diesen Zweck erfüllen.
+
+Diese Arbeit verfolgt ab hier den Ansatz \ref{sec:elf}. Diese Entscheidung basiert auf der Abwägung der Eigenschaften des Systems, den Zielen der Arbeit und den Eigenschaften der verschiedenen Objektrepräsentationen. Auf der \myxc~steht kein Webservice-Server zur Verfügung. Da es sich um ein System mit eingeschränkten Ressourcen handelt, wird auf die Installation zusätzlicher Software verzichtet. Weiterhin umfasst das Gesamtsystem nur zwei Systeme, die beide bekannt sind. Es besteht demnach kein Bedarf an einer plattformunabhängigen Objektrepräsentation und loser Kopplung. Weiterhin benötigt die hier konzipierte Lösung eine Objektrepräsentation, die neben den Daten eines Objekts auch dessen Funktionen abbilden kann.
+
+Das embedded SDK für die \myxc~liefert eine Toolchain für C/C++ Quellcode mit. Diese Sprache verfügt über keine integrierte Lösung zur Objektserialierung wie beispielsweise Java mit dem Serializable-Interface. Zwar bietet boost eine Bibliothek zur Objektserialisierung, allerdings fällt die Einschätzung des Implementierungsaufwands zugunsten der binären Repräsentation als shared object, im Folgenden auch Targetplugin genannt, aus. Weiterhin verursacht die Deserialisierung Rechenaufwand, da der serialisiert Bytestrom interpretiert und eine Objektinstanz mit den entsprechenden Daten erzeugt werden muss.
+
+Aufgrund der direkten Zuordnung eines Busobjekts der Datenbasis zu einer Hardwareschnittstelle der \myxc~ergibt sich der Ansatz, pro Busobjekt ein shared object zu erzeugen. Jedes shared object enthält alle notwendigen Informationen, um den Bus korrekt zu simulieren. Alle shared objects stellen einen Satz von Software-Schnittstellen, ein API, bereit, über die der Zugriff auf alle Daten und Funktionen durch die targetseitige Integrationskomponente auf der \myxc~erfolgt. Diese Schnittstellen kapseln die konkrete Implementierung von der Verwendung ab. Die targetseitige Integrationskomponente auf der \myxc~verwendet ausschließlich die Methoden dieser definierten Software-Schnittstellen für den Zugriff auf shared objects.
+
+Jedes shared object stellt eine globale Funktion zur Erzeugung eines spezifischen Targetplugin-Objekts für den Bus bereit. Diese Fabrikmethode gibt einen Schnittstellen-Zeiger auf die konkrete Instanz zurück. Über diesen Schnittstellen-Zeiger erfolgt der weitere Zugriff auf das shared object.
+
+\begin{figure}[hbtp]
+\centering
+\begin{minipage}[b]{.9\linewidth}
+\includegraphics[width=\linewidth]{factorypattern}
+\end{minipage}
+\caption{Objektfabrik für Targetplugins}
+\label{fig:con:factory}
+\end{figure}
+
+Dieser Ansatz entspricht dem gängigen Fabrikentwurfsmuster, engl. factory pattern, wie in Abbildung \ref{fig:con:factory} skizziert. Weiterhin enthält die API eine globale Funktion, die vor dem Entladen eines shared objects aufgerufen wird. Die Verwendung globaler Funktionen anstatt einer Klasse liegt in der Implementierung begründet. Wie Listing \ref{lst:pluginapi} zeigt, ist die Fabrik-Funktion als \texttt{extern "C"} deklariert, wodurch jeweils ein Symbol mit genau dem Namen der Funktion vom Linker im shared object erzeugt wird. Beim dynamischen Laden können die beiden Funktionen anhand dieser definierten Symbolnamen gefunden werden. Diese beiden Symbolnamen und die Definition der Schnittstelle reicht als gemeinsames Wissen von CanEasy-- und \myxc--Seite aus. Ohne die Deklaration \texttt{extern "C"} erstellt der Linker Symbolnamen, die u. U. zusätzliche Zeichen enthalten und somit nicht unter einem festen Namen gefundenen werden können. Dies würde den Aufwand zum Auffinden der gewünschten Funktionen erhöhen.
+
+Die Umwandlung der Datenbasis in ein shared object erfolgt in mehreren Schritten.
+\begin{enumerate}
+\item Das Verfahren beginnt mit der Generierung einer C++-Quellcodedatei pro Bus in der Datenbasis. Dieser Schritt generiert Teile des Quellcodes, der für alle shared objects ähnlich ist. Diese enthalten die Definition einer Klasse, die von der Schnittstellen-Klasse erbt und die globalen Funktionen.
+\item Auf oberster Ebene erfolgt eine Iteration über alle Steuergeräte des Busses. Pro simuliertem Steuergerät iteriert das Verfahren über alle Nachrichten. Dabei erzeugt es eine Objektdefinition pro Nachricht mit der ID, den Datenbytes und dem Sendezyklus der Nachricht.
+\item Aus dieser Quellcode-Datei wird anschließend mithilfe des embedded SDK ein shared object erzeugt. Beim cross-compile ist es wichtig, dass der Compiler positionsunabhängigen Code (PIC\index{PIC}) generiert, da nicht bekannt, an welche Adresse im RAM das shared object geladen werden wird. Die besondere Eigenschaft von PIC besteht darin, dass keine absoluten Adressen verwendet werden. Der Compiler arbeitet stattdessen mit relativen Adressen.
+\item Das shared object wird über das Netzwerk auf die \myxc~übertragen.
+\item Nach der Übertragung wird der Start des shared objects mittels eines Signals initiiert.
+\end{enumerate}
+%=========================================================================
+\section{Netzwerkprotokolle} \label{sec:con:networkprotocol}
+Die Netzwerkkommunikation zwischen CanEasy und \myxc~verwendet zwei Protokolle. Zum einen das FTP-Protokoll zur Übertragung von Targetplugins und Aufzeichnungsdateien, da auf der \myxc~bereits ein FTP-Server vorhanden ist. Zur Übermittlung der Steuerkommandos und der entsprechenden Antworten dient ein spezielles Protokoll, das die Tabellen \ref{tab:con:networkprotocol} genauer beschreiben. Es basiert soweit möglich auf binären Daten und erspart somit aufwendige Zeichenkettenverarbeitungen auf dem Target. Es basiert auf dem Request-Response-Prinzip. Jede Kommunikation beginnt mit einer Anfrage, die je nach Typ bestimmte Parameter enthält und endet mit der Antwort, die ebenfalls je nach Typ bestimmte Parameter enthält. Eine Nachricht besteht aus einem Kopf, der den Typ der Nachricht und die Gesamtlänge der Nachricht enthält. An den Kopf schließt sich der Datenteil der Nachricht an, der ggf. die entsprechenden Parameter enthält.
+
+Die Netzwerkübertragungen erfolgen in Bigendian-Byteorder, da dies die native Byteorder des Targets ist.
+
+Eine Verbindung bleibt über mehrere Request-Response-Zyklen erhalten, so dass nicht für jede Anfrage eine neue Verbindung geöffnet werden muss.
+
+\footnotesize
+\begin{center}
+\begin{longtable}{|l|l|l|l|l|l|}
+
+\hline \textbf{Nachrichtentyp} & \textbf{Wert} & \textbf{Byte} & \textbf{Parameter} & \textbf{Parametertyp} & \textbf{Parameterlänge}  \\
+\endhead
+
+\hline \multicolumn{6}{c}{Fortsetzung auf nächster Seite} \\ \hline
+\endfoot
+
+%
+\endlastfoot
+
+%=============================================================
+\hline ReqStartPlugin & 0 & 0 & & Enumaration & 4 \\ 
+\hline  & 512 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+\hline  &  & 8 & Interface & Integer & 4 \\ 
+%\hline  & max. 496  & 12 & Länge des Pfads der Shared Object Datei & Integer & 4 \\ 
+\hline  &  & 16 & Pfad der Shared Object Datei & Zeichenkette & 500\\ 
+%=============================================================
+\hline ReqStopPlugin & 1 & 0 & & Enumaration & 4 \\ 
+\hline  & 12 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+\hline  &  & 8 & Interface & Integer & 4 \\ 
+%=============================================================
+\hline ReqReqShutdown & 2 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge& Integer & 4 \\ 
+%=============================================================
+\hline ReqImportLog & 3 & 0 & & Enumaration & 4 \\ 
+\hline  & 512 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%\hline  & max. 500 & 8 & Länge des nachfolgenden Strings & Integer & 4 \\ 
+\hline  &  & 12 & Pfad der Aufzeichnungsdatei & Zeichenkette & 500\\ 
+%=============================================================
+\hline ReqEnumerateLogs & 4 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge& Integer & 4 \\ 
+%=============================================================
+\hline ReqGetInterfaces  & 5 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline ReqChangeMsgData  & 6 & 0 & & Enumaration & 4 \\ 
+\hline  & 24 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+\hline  &  & 8 & ID & Integer & 4 \\ 
+\hline  &  & 12 & Interface & Integer & 4 \\ 
+\hline  &  & 16 & Data 0 & Byte & 1 \\ 
+\hline  &  & 17 & Data 1 & Byte & 1 \\ 
+\hline  &  & 18 & Data 2 & Byte & 1 \\ 
+\hline  &  & 19 & Data 3 & Byte & 1 \\ 
+\hline  &  & 20 & Data 4 & Byte & 1 \\ 
+\hline  &  & 21 & Data 5 & Byte & 1 \\ 
+\hline  &  & 22 & Data 6 & Byte & 1 \\ 
+\hline  &  & 23 & Data 7 & Byte & 1 \\ 
+%=============================================================
+\hline ReqUploadLogMsg & 7 & 0 & & Enumaration & 4 \\ 
+\hline  & 33 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+\hline  &  & 8 & Timestamp High & Integer & 4 \\ 
+\hline  &  & 12 & Timestamp Low & Integer & 4 \\ 
+\hline  &  & 16 & Interface & Integer & 4 \\ 
+\hline  &  & 20 & ID & Integer & 4 \\ 
+\hline  &  & 24 & Data 0 & Byte & 1 \\ 
+\hline  &  & 25 & Data 1 & Byte & 1 \\ 
+\hline  &  & 26 & Data 2 & Byte & 1 \\ 
+\hline  &  & 27 & Data 3 & Byte & 1 \\ 
+\hline  &  & 28 & Data 4 & Byte & 1 \\ 
+\hline  &  & 29 & Data 5 & Byte & 1 \\ 
+\hline  &  & 30 & Data 6 & Byte & 1 \\ 
+\hline  &  & 31 & Data 7 & Byte & 1 \\ 
+\hline  &  & 32 & Direction \textless RX $|$ TX\textgreater & Byte & 1 \\ 
+%=============================================================
+\hline RespStartPlugin & 8 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespStopPlugin & 9 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespShutdown & 10 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespImportLog & 11 & 0 & & Enumaration & 4 \\ 
+\hline  & 512 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%\hline  & max. 500 & 8 & Länge des nachfolgenden Strings & Integer & 4 \\ 
+\hline  &  & 12 & Pfad der Aufzeichnungsdatei & Zeichenkette & 504 \\ 
+%=============================================================
+\hline RespEnumerateLog & 12 & 0 & & Enumaration & 4 \\ 
+\hline  & 512 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%\hline  & max. 500 & 8 & Länge des nachfolgenden Strings & Integer & 4 \\ 
+\hline  &  & 12 & Pfade der Aufzeichnungsdateien & Zeichenkette & 504 \\ 
+%=============================================================
+\hline RespInterfaces & 13 & 0 & & Enumaration & 4 \\ 
+\hline  & 512 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%\hline  & max. 500 & 8 & Länge des nachfolgenden Strings & Integer & 4 \\ 
+\hline  &  & 12 & Interfaces & Zeichenkette & 504 \\ 
+%=============================================================
+\hline RespChangeMsgData & 14 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespUploadLogMsg & 15 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespUnknownReq & 16 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline RespInvalidArg & 17 & 0 & & Enumaration & 4 \\ 
+\hline  & 8 & 4 & Nachrichtenlänge & Integer & 4 \\ 
+%=============================================================
+\hline 
+\caption{Format der Netzwerknachrichten}\label{tab:con:networkprotocol} \\
+
+\end{longtable} 
+\end{center}
+%=========================================================================
+\section{Targetseitige Integration}
+\label{sec:targetintegration}
+An dieser Stelle erfolgt eine Verfeinerung des Entwurfs der Komponenten auf der \myxc.
+
+\subsection{Zentrale Steuerung}
+Diese Komponente verarbeitet die Steuerkommandos, die CanEasy über das Netzwerk an die \myxc~sendet. Diese umfassen
+\begin{itemize}
+\item das Starten eines Targetplugins
+\item das Stoppen eines Targetplugins
+\item die Enumeration der Highspeed CAN-Schnittstellen der \myxc
+\item das Enumeration der verfügbaren Aufzeichnungsdateien
+\item das Abrufen einer Aufzeichnungsdatei
+\item die Änderung der Daten einer Botschaft
+\item das Stoppen der targetseitigen Komponenten
+\end{itemize}
+
+\subsection{Sendesteuerung}
+Die Aufgabe dieser Komponente besteht im Versand aller Nachrichten aller Targetplugins nach ihrem jeweiligen Sendeintervall auf der entsprechenden Hardware-Schnittstelle.
+
+Ebenso generiert sie einen Eintrag in der Aufzeichnung für jedes Versandereignis.
+
+\subsection{Aufzeichnung}
+Diese Komponente zeichnet alle empfangenen Botschaften auf allen Hardware-Schnittstellen der \myxc~auf. Dabei sind neben der ID, den Daten, der Richtung (gesendet oder empfangen) und dem Zeitstempel auch die Hardware-Schnittstelle, auf der die Botschaft empfangen wurde, von Interesse. Die Aufzeichnung wird als separates Targetplugin realisiert, das keine Sendebotschaften enthält. Zusätzlich stellt es eine Methode bereit, die in der \nameref{sec:con:maintask} aufgerufen wird. Diese Methode liest die Empfangswarteschlange der \myxc~aus und speichert die empfangenen Nachrichten in einem internen Ringpuffer zwischen. Diesen Ringpuffer liest eine weitere Methode in der \nameref{sec:con:logtask} aus und speichert die empfangenen Nachrichten in einer Aufzeichnungsdatei. Jede Aufzeichnungsdatei beginnt mit einem absoluten Zeitstempel, wann sie begonnen wurde. Besteht eine Netzwerkverbindung zu einer CanEasy-Instanz, schickt die Aufzeichnungskomponente in der Logtask aufgezeichnete Nachrichten an diese CanEasy-Instanz.
+
+\subsection{Taskmodell}
+Aus den vorgenannten Komponenten und ihren Aufgaben gibt sich eine Menge an Tasks, in denen die Komponenten ihre Aufgaben abarbeiten. Dabei gilt zu beachten, dass das System nur über eine CPU verfügt. Dadurch kann zu einem Zeitpunkt nur eine Task aktiv sein und jeder Taskwechsel verursacht eine Verzögerung durch den Kontextwechsel. Ebenso kann ein Taskwechsel zu cache faults führen, da sich die Speicherseiten der neuen Task u. U. nicht im Cache befinden. Diese cache faults führen zu einer größeren Ausführungszeit. Deshalb beschränkt sich dieses Konzept auf die minimal notwendige Anzahl an Tasks.
+
+Diese minimale Taskmenge umfasst folgende Elemente:
+\begin{description}
+\item[Maintask\phantomsection\label{sec:con:maintask}] Die Maintask wird zyklisch in einem Intervall von einer Millisekunde ausgeführt. Pro Zyklus liest sie die empfangenen Botschaften und versendet alle Botschaften, deren Sendeintervall in diesem Zyklus abgelaufen ist. Sie besitzt die höchste Priorität. Pro Sendezyklus ordnet die Maintask die zu versendenden Nachrichten nach deren Priorität, die der ID entspricht. Sie speichert eine Liste mit allen aktiven Targetplugins.
+\item[Netzwerktask\phantomsection\label{sec:con:networktask}] Die Netzwerktask dient zur Kommunikation über das Netzwerk. Da es hier zu Verzögerungen kommen kann, dürfen diese Aktionen nicht in der Maintask ausgeführt werden. Die Priorität der Netzwerktask liegt unterhalb der Priorität der Maintask.
+\item[Logtask\phantomsection\label{sec:con:logtask}] Die Logtask besitzt die niedrigste Priorität der Taskmenge. Ihre Aufgabe besteht im Auslesen des Ringpuffers der Aufzeichnung und dem Kopieren der Daten in einen eigenen Pufferspeicher. Ist dieser Puffer voll, schreibt die Logtask den Puffer in eine Datei auf der Festplatte. Diese erneute Zwischenspeicherung der empfangenen Nachrichten soll die Anzahl langsamer Festplattenzugriffe minimieren. Die Logtask bildet einen Teil der Aufzeichnungskomponente.
+\end{description}
+
+\subsection{Kritische Abschnitte}
+Aus dem Taskkonzept lässt sich erkennen, dass die einzelnen Tasks Daten miteinander austauschen. Dieser Austausch erfolgt über gemeinsam verwendete Speicherbereiche. Diese Speicher müssen mittels Mutexen vor gleichzeitigem Zugriff geschützt werden. Ein Programmteil, in dem eine Task auf einen gemeinsamen Speicher zugreift, wird im Folgenden \textit{kritischer Abschnitt} genannt. Grundsätzlich gilt zu beachten, dass kritische Abschnitte möglichst kurz sind. Folgende kritische Abschnitte ergeben sich aus dem bisherigen Konzept:
+\begin{description}
+\item[Ringpuffer] Die Zugriffe auf den Ringpuffer der Aufzeichnung von der Maintask und der Logtask aus müssen geschützt werden.
+\item[Targetpluginliste] Die Zugriffe auf die Liste der aktiven Targetplugins von der Maintask und der Netzwerktask aus müssen geschützt werden.
+\item[Aufzeichnungsdatei] Die Zugriffe auf die Aufzeichnungsdatei von der Logtask und der Netzwerktask aus müssen geschützt werden.
+\item[Uploadpuffer] Zum Versenden aufgezeichneter Busnachrichten von der \myxc~an CanEasy kommt ein Puffer für diese Nachrichten zum Einsatz. Die Zugriffe auf diesen Puffer erfolgen aus der Logtask und der Netzwerktask. Die Logtask fügt Nachrichten in den Puffer ein und startet die Übertragung, falls noch keine Übertragung stattfindet.
+
+Findet schon eine Übertragung statt, wird die Schreibhandler-Funktion nach Abschluß einer Übertragung aus dem Kontext der Netzwerktask aufgerufen. Dieser Handler startet die Übertragung der nächsten Nachricht im Puffer.
+
+Aufgrund dieser Zugriffe aus zwei Tasks muss ein Schutz dieser Ressource erfolgen. 
+\end{description}
+
+\subsection{Laufzeitabschätzung der Maintask}
+\label{sec:con:wcet}
+\index{WCET}
+Dieser Abschnitt greift die grundlegenden Gedanken aus Abschnitt \ref{sec:fun:rta} auf und transferiert sie auf das hier vorgestellte Konzept. Die WCET bezeichnet die maximale Ausführungsdauer einer Task im schlechtesten Fall. Der schlechteste Fall bezeichnet hierbei den längsten möglichen Pfad durch den Programmcode der Task, also die maximale Ausführungszeit. Diese ergibt sich beispielsweise bei Schleifen mit einer variablen Anzahl an Durchläufen , dadurch dass die maximal möglichen Schleifendurchläufen angenommen werden. Entlang dieses längsten Pfads addieren sich die benötigten Prozessorzyklen der einzelnen Befehle des Pfads. Ist die Taktfrequenz des Prozessors bekannt lässt sich die benötigte Ausführungszeit berechnen. Allerdings verfälschen Pipelining oder Cache misses dieses Ergebnis. Aus diesem Grund verzichtet diese Arbeit auf eine genaue WCET, sondern beschränkt sich auf eine grobe Aussage zum erwarteten Laufzeitverhalten der hier entworfenen Maintask. Die Betrachtung der WCET innerhalb des Konzepts beschränkt sich auf die Maintask, da nur hier Echtzeitanforderungen bestehen.
+
+Die WCET der Maintask in einem Zyklus setzt sich aus der Zeit für das Auslesen der Empfangswarteschlange, falls die Aufzeichnungskomponente aktiv ist, und der benötigten Zeitspanne zum Versenden aller Nachrichten in einem Zyklus zusammen. Die Deadline entspricht dem Beginn des nächsten Zyklus, also 1 ms.
+
+Die benötigte Zeit zum Auslesen der Empfangswarteschlange hängt von der Anzahl der empfangenen Nachrichten seit dem vorherigen Zyklus ab. Diese Anzahl hängt von externen Systemen ab und lässt sich somit nicht allgemeingültig bestimmen. Durch die Verlagerung des Auslesens der Empfangswarteschlange in einen separaten Thread ließe sich dieses Problem umgehen. Der hohe Aufwand eines Threadwechsels, der hier auch noch sehr häufig stattfände, rechtfertigt den Verzicht darauf und die Beschränkung der WCET auf das Versenden von CAN Botschaften.
+
+Zur Bestimmung der Menge der in einem Zyklus zu versendenden Nachrichten iteriert die Maintask durch eine einfach verkettete Liste von aktiven Targetplugins. Als Datencontainer für die Nachrichten, die in einem Zyklus zu versenden sind, soll eine assoziative Datenstruktur dienen. Diese Datenstruktur basiert auf einem sog. Rot-Schwarz-Baum \phantomsection\label{sec:con:rbt}, engl. red-black-tree. Den Aufbau solcher Datenstrukturen zeigt \cite{springerlink:10.1007/BF00289509}. Der Vorteil einer solchen Datenstruktur liegt in der oberen Schranke $O(\log n)$ für die Operationen \textit{Einfügen}, \textit{Suchen} und \textit{Löschen}. Als Schlüssel für diese Datenstruktur dient die ID der Nachricht. Da die Datenstruktur die enthaltenen Elemente aufsteigend nach dem Schlüssel sortiert, enthält die Datenstruktur nach Abschluss der Iteration die in diesem Zyklus zu versendenden Nachrichten in der Reihenfolge ihrer Priorität. Abschließend iteriert die Maintask über diese Datenstruktur vom Anfang zum Ende, versendet jedes Element und leer die Datenstruktur nach dem Versand aller Nachrichten.
+
+Somit bleibt festzuhalten, dass innerhalb der Maintask nur Operationen mit linearen oder logarithmischen oberen Schranken stattfinden. Dadurch wird sich die Laufzeit der Maintask auch bei größeren Datenmengen nicht überproportional verschlechtern.
+%=========================================================================
+\section{Hostseitige Integration}
+\label{sec:hostintegration}
+\subsection{CanEasy-Plugin}
+Diese Komponente stellt die Schnittstelle des Systems zum Benutzer dar. Sie orientiert sich deshalb an den in Abbildung \ref{fig:con:usecases} definierten Anwendungsfällen und stellt für diese entsprechende grafische Steuerelemente bereit:
+\begin{itemize}
+\item ein Feld zur Eingabe der IP-Adresse der \myxc
+\item Schaltflächen zum Herstellen und Trennen der Netzwerkverbindung zur \myxc
+\item eine Schaltfläche zum Abfragen der Hardware-Schnittstellen der \myxc
+\item eine Auswahlliste mit den Schnittstellen der \myxc
+\item eine Auswahlliste mit Busobjekten der Datenbasis
+\item Schaltflächen zu Verknüpfen oder Trennen einer Busobjekt-Schnittstellen-Beziehung
+\item eine Auswahlliste mit verknüpften Busobjekten
+\item Schaltflächen vom Starten und Stoppen eines verknüpften Busobjekts
+\item eine Schaltfläche zum Beenden der targetseitigen Komponenten
+\item eine Checkbox, um ein Targetplugin automatisch beim Start der targetseitigen Komponenten zu starten
+\item eine Schaltfläche zum Abrufen der Liste der verfügbaren Aufzeichnungsdateien auf der \myxc
+\item eine Auswahlliste mit den verfügbaren Aufzeichnungsdateien
+\item eine Schaltfläche um die ausgewählte Aufzeichnung der \myxc~zu übertragen
+\end{itemize}
+Zur Kommunikation mit der \myxc~über das Netzwerk startet das CanEasy-Plugin einen separaten Thread.
+\subsection{Code-Generierung}
+Die Generierung der Quellcode-Dateien erfolgt in Form von Zeichenketten im RAM. Nach Abschluss der Generierung werden diese Zeichenketten in einer Datei auf der Festplatte gespeichert.
+\subsection{Anzeige der Aufzeichnung}
+Die Anzeige der Aufzeichnung erfolgt in mehreren Schritten
+\begin{enumerate}
+\item Auflistung der verfügbaren Aufzeichnungsdateien auf der \myxc.
+\item Auswahl einer Aufzeichnungsdatei durch den Benutzer.
+\item Anforderung der ausgewählten Aufzeichnungsdatei von der \myxc. Im Falle der aktuell verwendeten Aufzeichnungsdatei, leert die targetseitige Aufzeichnungskomponente zuerst ihre Puffer und schreibt die Datei vollständig auf die Festplatte. Sie rotiert nun die Aufzeichnungsdatei, so dass ab diesem Zeitpunkt eine neue Aufzeichnung erfasst wird. Die \myxc~gibt den Namen der rotierten Datei mit der bis zu diesem Zeitpunkt erfassten Aufzeichnung über das Netzwerk zurück.
+\item Das CanEasy-Plugin lädt die Datei mit dem empfangenen Namen per FTP von der \myxc.
+\item Das CanEasy-Plugin konvertiert die heruntergeladene Datei aus dem Binärformat in ein Textformat, für das CanEasy Konvertierungsfunktionalität in das eigene Aufzeichnungsformat besitzt.
+\item Das CanEasy-Plugin startet die CanEasy-eigenen Mechanismen zur Konvertierung der Textdatei in das CanEasy-eigene Aufzeichnungsformat. Dabei muss der Benutzer manuell die Hardware-Schnittstellen den Bussen der Datenbasis zuordnen.
+\item Der Benutzer lädt die konvertierte Aufzeichnungsdatei.
+\end{enumerate}
+\subsection{Aktualisierung von Nachrichtendaten}
+CanEasy bietet dem Benutzer verschiedene Möglichkeiten zur Änderung der Datenbytes einer Nachricht über die grafische Oberfläche. Bei einer solchen Änderung von Datenbytes einer Nachricht, die auf dem Target simuliert wird, sollen diese Änderungen auf dem Target übernommen werden.
+Dazu versendet die hostseitige Integrationskomponente eine entsprechende Nachricht über das Netzwerk. Diese Nachricht enthält die Nummer der betreffenden Hardware-Schnittstelle des betroffenen Busses, die ID der Nachricht und die geänderten Werte der Datenbytes der Nachricht.
+%=========================================================================
+\section{Verifikation}
+\label{sec:con:verification}
+Das Gesamtkonzept bezieht eine Möglichkeit zur Verifikation der konzeptionellen Entscheidungen und Implementierung des Prototyps mit ein. Dies erst ermöglicht eine Bewertung der Messergebnisse in Kapitel \ref{chp:results}.
+
+Als technische Basis für die Verifikation dient das \nameref{sec:con:at32uc3c} mit entsprechender Software. Diese Software besteht aus Basismodulen zum Betrieb des \nameref{sec:con:at32uc3c} und für den Zugriff auf die Hardware, die von der Schleissheimer GmbH für diese Arbeit zur Verfügung gestellt wurden, und aus einem Modul, das die Verifikationsapplikation darstellt.
+
+Das Ziel der Verifikation besteht darin, CAN-Botschaften in einem möglichst genauen zeitlichen Kontext zu senden. Zur Beurteilung einer zeitlichen Empfangsgenauigkeit muss zuerst eine zeitliche Sendegenauigkeit sichergestellt werden. Dies leistet die Verifikation mit dem \nameref{sec:con:at32uc3c}, da es immer nur einen von zwei möglichen Sendemodi ausführt. D. h. hier findet keine parallele Abarbeitung mehrerer Tasks statt, die sich gegenseitig beeinflussen können.
+
+Die Verifikation benötigt zwei Sendemodi
+\begin{description}
+	\item[Cycle] Hier verschickt das \nameref{sec:con:at32uc3c} 100 Nachrichten in einem Interval von 100 ms basierend auf einem Hardware-Timer. Der Versand einer Nachricht erfolgt dabei direkt in der ISR\index{ISR} des Timer-Interrupts.
+	\item[Burst] Hier verschickt das \nameref{sec:con:at32uc3c} 65535 Nachrichten so schnell wie möglich. Bei jedem Versenden wird ein 16-Bit Zähler inkrementiert und als Signal in der Nachricht verschickt. Dabei kommt aktives Polling auf den Sendestatus zum Einsatz, um die Interrupt-Latenz zu sparen. Sobald die CAN-Schnittstelle eine Nachricht verschickt hat, wird der Versand der nächsten gestartet.
+\end{description}
+Die Auswahl des Sendemodus erfolgt über die beiden Taster des \nameref{sec:con:at32uc3c}, wobei jeder Taster einen Sendemodus repräsentiert. Jeweils eine LED zeigt die Aktivität eines Sendemodus an. Solange ein Sendemodus aktiv ist, werden weitere Tastenereignisse ignoriert. Dieses Konzept widerspricht zwar vielen Designprinzipien, erzeugt aber ein zeitlich möglichst genaues Verhalten des Systems, was in diesem Fall die Verstöße rechtfertigt.
\ No newline at end of file