\setchapterpreamble[u]{%
	\dictum[Johann Wolfgang von Goethe, Faust I]{Ein jeder lernt nur, was er lernen kann;\\
	Doch der den Augenblick ergreift, das ist der rechte Mann.}\bigskip}
\chapter{Ergebnisse}
\label{chp:results}
In diesem Kapitel erfolgt eine Überprüfung der in Kapitel \ref{chp:prototype} implementierten Konzepte aus Kapitel \ref{chp:concept} im Hinblick auf ihre erwarteten Eigenschaften. Jeder Abschnitt dieses Kapitels beschreibt ein Szenario zur Überprüfung einer Eigenschaft, die verwendete Metrik, das erwartete Verhalten des Systems und das gemessene Verhalten mittels der Metrik.

Bei allen Messungen treten außer den im Szenario beschriebenen Lasten keine Bus- oder Systemlasten auf.
\section{Genauigkeit der Zeitstempel beim Empfang}\label{sec:rxaccuracity}
Zur Beurteilung der Genauigkeit der Empfangszeitstempel des Prototyps im Vergleich zu anderen Hardware-/Software-Kombinationen wird untersucht, inwieweit tatsächlich empfangene Zeitstempel von erwarteten abweichen. Als Referenz dient hierbei das in Abschnitt \ref{sec:con:verification} konzipierte Werkzeug im zyklischen Sendemodus. Die folgenden Unterabschnitte untersuchen jeweils die Differenz zweier aufeinander folgend empfangener Nachrichten. Die Differenz zwischen dieser Zeitspanne und der erwartete Differenz dient als Metrik für die Genauigkeit der Empfangsstempel, wobei ein kleiner Wert eine hohe Genauigkeit darstellt.

\subsection{CanEasy mit Softwarezeitstempel}
Für Hardware-Adapter, die über keine Möglichkeit verfügen, einen Zeitstempel in der Hardware zu generieren, bietet CanEasy die Möglichkeit, einen Zeitstempel zu generieren. Da dies auf der CPU des PCs passiert, unterliegt dieser Zeitstempel dem ungenauen Scheduling auf dem PC.

Die Abbildung \ref{fig:diag_rx_ts_ce_sw} zeigt die Abweichungen der Zeitstempel über der Anzahl der empfangenen Nachrichten. Wie erwartet treten hier starke Schwankungen auf. Der Mittelwert der Abweichung liegt bei 1,58 ms, die maximale Abweichung bei 2,00 ms.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{caneasy_sw_timestamp.eps}
\end{minipage}
\caption{Abweichung der RX-Timestamps CanEasy Software}
\label{fig:diag_rx_ts_ce_sw}
\end{figure}

\subsection{CanEasy mit Hardwarezeitstempel}
Dass Unerschiede zwischen CAN-Hardware-Adaptern bestehen zeigen die nächsten beiden Auswertungen.
\subsubsection*{MHS Tiny-CAN II}
Die Abbildung \ref{fig:diag_rx_ts_ce_hw_mhs} zeigt die Ergebnisse unter Verwendung des Adapter Tiny-CAN II des Herstellers MHS. Der Mittelwert der Abweichung liegt hier bei 0,78 ms, bei einer maximalen Abweichung 2,00 ms.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{caneasy_hw_mhs_timestamp.eps}
\end{minipage}
\caption{Abweichung der RX-Timestamps CanEasy Hardware, MHS Tiny-CAN II}
\label{fig:diag_rx_ts_ce_hw_mhs}
\end{figure}

\subsubsection*{Vector CANcaseXL}
Deutlich bessere Ergebnisse liefert das deutlich teurere CANcaseXL des Herstellers vector. Wie in Abbildung \ref{fig:diag_rx_ts_ce_hw_cancasexl} zu erkennen, treten hier keine messbaren Abweichungen auf. Der Mittelwert der Abweichung liegt bei 0,00 ms, die maximale Abweichung ebenfalls bei 0,00 ms.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{caneasy_hw_cancasexl_timestamp.eps}
\end{minipage}
\caption{Abweichung der RX-Timestamps CanEasy Hardware, Vector CANcaseXL}
\label{fig:diag_rx_ts_ce_hw_cancasexl}
\end{figure}

\subsection{\myxc}
Aus Abbildung \ref{fig:diag_rx_ts_xc} lässt sich entnehmen, dass die Empfangszeitstempel des Prototyps ebenfalls keine messbaren Abweichungen aufweisen. Der Mittelwert der Abweichung liegt bei 0,00 ms, die maximale Abweichung beträgt 0,00 ms.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{xoraya_timestamp.eps}
\end{minipage}
\caption{Abweichung der RX-Timestamps \myxc}
\label{fig:diag_rx_ts_xc}
\end{figure}

\section{RX Message Burst}
Hier kommt das Verifikationswerkzeug im Burst-Modus zum Einsatz. Die Messung erfolgt anhand einer grafischen Darstellung des empfangenen Werte über die Zeit. Jeder Punkt des Graphen repräsentiert eine aufgezeichnete Botschaft. Der Zeitstempel der Nachricht bildet den x-Wert und der Signalwert die y-Koordinate. Bei korrekt empfangenen Nachrichten ergibt sich hieraus eine Gerade. Nicht oder in falscher Reihenfolge empfangene Nachrichten ändern die Steigung des Graphen, so dass es sich nicht mehr um eine Gerade handelt.
\subsection{MHS Tiny-CAN II}
In Abbildung \ref{fig:burst_rx_tinycan} lassen sich Unterschiede in der Steigung des Graphen erkennen. Vermutlich konnte CanEasy nicht alle Nachrichten auslesen, bevor sie in der Hardware überschrieben wurden.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{\linewidth}
\includegraphics[width=\linewidth]{tinycan_burst_rx}
\end{minipage}
\caption{Message-Burst Tiny-CAN II}
\label{fig:burst_rx_tinycan}
\end{figure}

\subsection{vector CANcaseXL}
Der Graph in Abbildung \ref{fig:burst_rx_cancase} zeigt keine erkennbaren Steigungsänderungen, was der Erwartung einer korrekten Aufzeichnung entspricht.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{\linewidth}
\includegraphics[width=\linewidth]{cancasexl_burst_rx}
\end{minipage}
\caption{Message-Burst CANcaseXL}
\label{fig:burst_rx_cancase}
\end{figure}

\subsection{\myxc}
Auch hier entspricht der Graph in Abbildung \ref{fig:burst_rx_xc} der erwarteten Geraden. Die Anzahl der vom Verifikationswerkzeug versendeten Nachrichten übersteigt die Größe des Ringpuffers des Aufzeichnungsplugins um ein Vielfaches. Dass trotzdem alle Nachrichten in der richtigen Reihenfolge aufgezeichnet wurden, zeigt die Leistungsfähigkeit der Lösung.

Auch unter hoher System mit Hilfe von \ref{lst:cpuload} zeigt sich das gleiche Bild (siehe Abbildung \ref{fig:burst_rx_xc_cpuload}).
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{\linewidth}
\includegraphics[width=\linewidth]{xc_burst_rx}
\end{minipage}
\caption{Message-Burst \myxc}
\label{fig:burst_rx_xc}
\end{figure}
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{\linewidth}
\includegraphics[width=\linewidth]{xc_burst_rx_cpuload}
\end{minipage}
\caption{Message-Burst \myxc~unter Last}
\label{fig:burst_rx_xc_cpuload}
\end{figure}

\section{Genauigkeit der Sendesteuerung der \myxc}
\label{sec:txaccuracity}
Dieser Abschnitt zeigt, wie exakt der Prototyp in der Datenbasis definierte Sendezyklen einhält. Dazu verschickt die \myxc~eine Botschaft mit einer Zykluszeit von 100 ms aus einem entsprechenden Targetplugin.

Zur Verifikation wird CanEasy mit angeschlossenem Vector CANcaseXL und dessen Hardwarezeitstempeln verwendet.

Wie Abbildung \ref{fig:diag_tx_ts_xc} zeigt, liegen auch hier nur äußerst geringe Abweichungen vor. Der Mittelwert der Abweichung beträgt 0,002816901 ms, bei einer maximalen Abweichung 0,1 ms.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{xoraya_tx_timestamp.eps}
\end{minipage}
\caption{Abweichung der TX-Timestamps der \myxc}
\label{fig:diag_tx_ts_xc}
\end{figure}

\section{Einhaltung der Antwortzeiten}
\label{sec:res:wcet}
Die Ausgangsbasis für dieses Szenario bildet die Definition von 7 Sendebotschaften mit den IDs 0x001 bis 0x007 in der Datenbasis mit einem Sendeintervall von 1 ms entsprechend der konzeptionellen Überlegungen zu den Antwortzeiten in Abschnitt \ref{sec:fun:rta}. Jede Botschaft enthält 8 Byte Daten und somit den DLC-Wert 8. Um möglichst die maximale Übertragungsdauer zu erreichen, erfolgt die Auswahl der Werte für die Datenbytes dahingehend, dass möglichst viele Stopbits entstehen. Ausgehend von einem DLC-Wert 8, in binärer Darstellung 1000, ergibt sich ein binärer Wert von 0011 1100 für das erste Datenbyte. Demnach entsteht das erste Stopfbit nach dem zweiten Bit des ersten Datenbytes und erzeugt einen Wechsel von 0 nach 1. Gefolgt von vier weiteren Bits mit dem Wert 1 entsteht ein weiteres Stopfbit, diesmal von 1 nach 0. Nun müssen 4 weitere Bits mit 0 folgen, um das nächste Stopfbit zu erzeugen. Ab hier wiederholt sich das Muster. Das Bitmuster 0011 1100 für die Datenbytes entspricht dem dezimalen Wert 60. Die Abbildung \ref{fig:res:bitstuffing} veranschaulicht diese Überlegungen.

\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{bitstuffing.eps}
\end{minipage}
\caption{Bitstopfen}
\label{fig:res:bitstuffing}
\end{figure}

\paragraph*{Schedulability Test}
\label{sec:res:rtaexample}\index{Schedulability Test}
Vor der praktischen Ermittlung des Ergebnisses erfolgt eine theoretische Überprüfung, ob der definierte Satz an Nachrichten nach dem Schedulability Test aus \ref{sec:fun:rta} unter Einhaltung aller Deadlines überhaupt übertragen werden kann. Aus der Definition ergeben sich die in Tabelle \ref{tab:res:startvalues} angegebenen Ausgangswerte.

\begin{table}[htb]
\begin{center}
\footnotesize
\begin{tabular}{|l|l|l|l|l|l|l|l|}
\hline $m$ & 1 & 2 & 3 & 4 & 5 & 6 & 7 \\ 
\hline $T_m$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ \\ 
\hline $B_m$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 0$\mu s$ \\ 
\hline $t^0_m$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ \\ 
\hline $D_m$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ & 1000$\mu s$ \\ 
\hline $J_m$ & 0$\mu s$ & 0$\mu s$ & 0$\mu s$ & 0$\mu s$ & 0$\mu s$ & 0$\mu s$ & 0$\mu s$ \\ 
\hline $hep\left( m\right)$ & $\{1\}$ & $\{1;2\}$ & $\{1;2;3\}$ & $\{1;2;3;4\}$ & $\{1;2;3;4;5\}$ & $\{1;2;3;4;5;6\}$ & $\{1;2;3;4;5;6;7\}$ \\ 
\hline $hp\left( m\right)$ & $\{\}$ & $\{1\}$ & $\{1;2\}$ & $\{1;2;3\}$ & $\{1;2;3;4\}$ & $\{1;2;3;4;5\}$ & $\{1;2;3;4;5;6\}$ \\ 
\hline $C_m$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ & 135$\mu s$ \\ 
\hline 
\end{tabular}
\caption{Ausgangswerte des Schedulability Tests für $m_{1}\dots m_7$}\label{tab:res:startvalues}
\end{center}
\end{table}

Für den verwendeten CAN-Bus mit einer Übertragungsrate von 1 MBit/s gilt die Übertragungsdauer $\tau_{bit}=1\mu s$.

Die ausführlichen Berechnungen der hier gezeigten Werte sind in Anhang \ref{app:calc} aufgeführt. Tabelle \ref{tab:res:m1} zeigt die berechneten Werte des Schedulability Tests für ersten sechs Nachrichten. Die Werte für $U_m$ sind alle kleiner als $1$, was garantiert, dass die Berechnung der busy periods konvergiert. Ebenso sind alle Werte für $Q_m$ gleich $1$, so dass nur jeweils eine Instanz der Nachricht betrachtet werden muss. Für alle Nachrichten liegen die WCRT-Werte $R_m$ unterhalb ihrer Deadline, so dass sie den Schedulability Test bestehen.
\begin{table}[htb]
\begin{center}
\footnotesize
\begin{tabular}{|l|l|l|l|l|l|l|l|l|l|l|l|}
\hline $m$ & $U_m$ & $t^1_m$ & $t^2_m$ & $t_m$ & $Q_m$ & $\omega^0_m\left( 0\right)$ & $\omega^1_m\left( 0\right)$ & $\omega^2_m\left( 0\right)$ & $\omega_m\left( 0\right)$ & $R_m\left( 0\right)$ & $R_m$ \\ 
\hline $1$ & $0,135<1$ & $270\mu s$ & $270\mu s$ & $270\mu s$ & $1$ & $135\mu s$ & $135\mu s$ &  & $135\mu s$ & $270\mu s$ & $270\mu s \leq D_1$ \\ 
\hline $2$ & $0,270<1$ & $405\mu s$ & $405\mu s$ & $405\mu s$ & $1$ & $135\mu s$ & $270\mu s$ & $270\mu s$ & $270\mu s$ & $405\mu s$ & $405\mu s \leq D_2$ \\ 
\hline $3$ & $0,405<1$ & $540\mu s$ & $540\mu s$ & $540\mu s$ & $1$ & $135\mu s$ & $405\mu s$ & $405\mu s$ & $405\mu s$ & $540\mu s$ & $540\mu s \leq D_3$ \\ 
\hline $4$ & $0,540<1$ & $675\mu s$ & $675\mu s$ & $675\mu s$ & $1$ & $135\mu s$ & $540\mu s$ & $540\mu s$ & $540\mu s$ & $675\mu s$ & $675\mu s \leq D_4$ \\ 
\hline $5$ & $0,675<1$ & $810\mu s$ & $810\mu s$ & $810\mu s$ & $1$ & $135\mu s$ & $675\mu s$ & $675\mu s$ & $675\mu s$ & $810\mu s$ & $810\mu s \leq D_5$ \\ 
\hline $6$ & $0,810<1$ & $945\mu s$ & $945\mu s$ & $945\mu s$ & $1$ & $135\mu s$ & $810\mu s$ & $810\mu s$ & $810\mu s$ & $945\mu s$ & $945\mu s \leq D_6$ \\ 
\hline 
\end{tabular} 
\caption{Schedulability Test für $m_{1}\dots m_6$}\label{tab:res:m1}
\end{center}
\end{table}

Die Berechnung des Schedulability Tests für $m=7$ gestattet sich etwas aufwendiger und wird gesondert betrachtet. 

\begin{table}[htb]
\begin{center}
\footnotesize
\begin{tabular}{|l|l|l|l|l|l|l|}
\hline $U_7$ & $t^1_7$ & $t^2_7$ & $t^3_7$ & $t^4_7$ & $t_m$ & $Q_7$ \\ 
\hline $0,945<1$ & $1080\mu s$ & $2025\mu s$ & $2970\mu s$ & $2970\mu s$ & $2970\mu s$ & $3$ \\ 
\hline 
\end{tabular} 
\caption{Schedulability Test für $m_7$, 1. Teil}\label{tab:res:m7a}
\end{center}
\end{table}

Der erste Teil der Ergebnisse der Berechnungen ist in Tabelle \ref{tab:res:m7a} dargestellt. Die Berechnung der Länge der busy period konvergiert hier erst nach der vierten Iteration. Der Wert von $Q_7=3$ gibt an, dass im folgenden drei Instanzen von Nachricht $7$ überprüft werden müssen, um ihre tatsächliche WCRT zu bestimmen. Die Ergebnisse der Berechnungen für die Instanzen $q$ der Nachricht $7$ zeigt Tabelle \ref{tab:res:m7b}. Nach diesen Werten ergibt sich $R_7=\max\limits_{q=0\dots 2}\left(\{945;80;25\}\right)=945\mu s \leq D_7$. Somit besteht auch Nachricht $7$ den Schedulability Test. Da alle Nachrichten $m_{1}\dots m_7$ den Schedulability Test bestehen, besteht auch die Gesamtmenge der Nachrichten den Test.

\begin{table}[htb]
\begin{center}
\footnotesize
\begin{tabular}{|l|l|l|l|l|l|}
\hline $q$ & $\omega^0_7\left( q\right)$ & $\omega^1_7\left( q\right)$ & $\omega^2_7\left( q\right)$ & $\omega_7\left( q\right)$ & $R_7\left( q\right)$ \\ 
\hline $0$ & $0\mu s$ & $810\mu s$ & $810\mu s$ & $810\mu s$ & $945\mu s$ \\ 
\hline $1$ & $945\mu s$ & $945\mu s$ &  & $945\mu s$ & $80\mu s$ \\ 
\hline $2$ & $1080\mu s$ & $1890\mu s$ & $1890\mu s$ & $1890\mu s$ & $25\mu s$ \\ 
\hline 
\end{tabular} 
\caption{Schedulability Test für $m_7$, 2. Teil}\label{tab:res:m7b}
\end{center}
\end{table}

\label{sec:res:wcrttest}Der praktische Test soll nun überprüfen, ob die Annahme von $J_m=0$ zu optimistisch war oder auch in der Realität gerechtfertigt ist. Dazu versendet die \myxc~die Botschaften $m_{1}\dots m_7$ aus einem entsprechend generierten SO. Als Empfänger dient CanEasy mit einem angeschlossenen CANcaseXL.

Basierend auf dem vorhergehenden Schedulability Test besteht die Erwartung, dass jede Botschaft innerhalb einer Millisekunde genau einmal in der Aufzeichnung erscheint. Ebenso steht zu erwarten, dass die Differenz der Zeitstempel zweier aufeinander folgender Instanzen einer Botschaft $m_n$ eine Millisekunde nicht übersteigt.

Nach den Überlegungen in Abschnitt \ref{sec:fun:rta} sollte ein CAN Bus mit 1 MBit/s Bitrate 15 Botschaften mit einem DLC von 1 innerhalb einer Millisekunde übertragen können. Somit ergibt sich im schlechtesten Fall eine Anzahl von $N=55+10=65$ Bits für pro Nachricht. Innerhalb 1000 $\mu s$ sollte der Bus demnach $n=\lfloor \frac{1000}{65} \rfloor=15$ Nachrichten übertragen können, da $t_{n}=\sum\limits_{1}^{15} 65\mu s = 15 * 65 \mu s = 975 \mu s \leq 1000 \mu s$.

Ein Wert von 240 für das Datenbyte erzeugt ein Stopfbit im Datenbyte. Da der DLC in binärer Darstellung 0001 beträgt, erzeugt das Bitmuster 1111 0000 im ersten Datenbyte ein Stopfbit nach dem vierten Datenbit. Dieses Bitmuster entspricht 240 in dezimaler Darstellung.

\myxc~versendet die Botschaften der Busse WCRT (8 Datenbytes) und WCRT\_2 (1 Datenbyte) auf jeweils einem Interface. CanEasy empfängt die Botschaften beider Busse, die jeweils an einen Kanal eines CANcaseXL angeschlossen sind.

Obige Überlegung führen zu der Erwartung, dass im praktischen Test jede Botschaft innerhalb einer Millisekunde genau einmal in der Aufzeichnung erscheint.

\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.49\linewidth}
\includegraphics[width=\linewidth]{wcrt_trace}
\end{minipage}
%
\begin{minipage}[b]{.49\linewidth}
\includegraphics[width=\linewidth]{wcrt_2_trace}
\end{minipage}
\caption{Resultat WCRT-Test}
\label{fig:res:wcrt}
\end{figure}

Die Traces in Abbildung \ref{fig:res:wcrt} erfüllen diese Erwartung exakt, CanEasy zeigt für WCRT\_2 100 \% Buslast. Rechnerisch bleibt der Bus zwar noch 25 $\mu s$ ohne Last, was einer Last von 97,5 \% entspricht. Allerdings passt in diese 25 $\mu s$ keine Nachricht mehr, womit die maximale Anzahl Nachrichten auf dem Bus erreicht ist, was sich auch als 100 \% Buslast interpretieren lässt.

Dieser Test zeigt auch, dass der Prototyp zwei Highspeed CAN-Busse parallel maximal auslasten kann und dabei das gewünschte zeitliche Verhalten exakt einhält.

\section{Verhalten der \myxc ~unter hoher Prozessorlast}
\label{sec:cpuload}
Die folgenden Unterabschnitte sollen zeigen, wie sich der Prototyp unter hoher Systemlast verhält, abhängig davon, ob die Maintask auf Echtzeit-Priorität läuft oder nicht.

Zur Erzeugung der Systemlast wird das Skript \ref{lst:cpuload} als separater Prozess gestartet.

In diesem Test verschickt die \myxc~eine Botschaft mit Zykluszeit 20 ms aus einem entsprechend generierten Targetplugin. Anschließend wird der Burst-Test noch einmal durchgeführt, um festzustellen, welchen Einfluss die Priorität der Maintask auf den Empfang hat.

Die Verifikation erfolgt wieder mittels CanEasy und Vector CANcaseXL mit Hardwarezeitstempeln.

\subsection{Steuerthread auf RT-Priorität}
Die Abbildung \ref{fig:cpuload_tx_ts_xc_rt} zeigt, dass eine hohe Systemlast keinen Einfluss auf das Sendeverhalten der \myxc~hat, wenn die Maintask auf Echtzeitpriorität läuft.
Der Mittelwert der Abweichung liegt bei 0,00 ms, die maximale Abweichung beträgt 0,1 ms.
Im Burst-Test hat der Prototyp alle 65535 Nachrichten korrekt empfangen.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{xoraya_tx_cpuload_rt.eps}
\end{minipage}
\caption{Abweichung der Sendezeitstempel der \myxc~mit hoher Systemlast auf Real-Time Priorität}
\label{fig:cpuload_tx_ts_xc_rt}
\end{figure}

\subsection{Steuerthread auf normaler Priorität}
Die Abbildung \ref{fig:cpuload_tx_ts_xc_norm} zeigt, dass die Systemlast deutlichen Einfluss auf das Sendeverhalten der \myxc~hat, wenn die Maintask mit normaler Priorität läuft.
Der Mittelwert der Abweichung steigt auf 0,03 ms, bei einer maximalen Abweichung von 2 ms.
Noch gravierender wirkt sich die Systemlast auf den Burst-Test aus, den die Maintask nicht auf Echtzeit-Priorität läuft: nur 576 von 66535 Nachrichten wurden korrekt empfangen.
\begin{figure}[hbtp]
\centering
\begin{minipage}[b]{.5\linewidth}
\includegraphics[width=\linewidth]{xoraya_tx_cpuload_norm.eps}
\end{minipage}
\caption{Abweichung der Sendezeitstempel der \myxc~mit hoher Systemlast auf normaler Priorität}
\label{fig:cpuload_tx_ts_xc_norm}
\end{figure}

\section{Bewertung der Ergebnisse}
\label{sec:resultanalysis}
Zusammenfassend lassen sich die Ergebnisse wie folgt beurteilen:
\begin{itemize}
\item Die Empfangszeitstempel der \myxc~sind präzise, vergleichbar mit dem CANcaseXL von Vector
\item Läuft die Maintask auf höchster Priorität, weist die Aufzeichnung auch bei hoher Systemlast keine Verluste auf.
\item Durch die Hardware-Timer der \myxc~werden Sendeinterval exakt eingehalten
\item Der Schedulability Test lässt Konfigurationen zu, die sehr nahe an der maximalen Busauslastung liegen, obwohl er als pessimistisch gilt. Der praktische Test zeigt, dass der Schedulability Test diese Konfiguration zurecht zulässt. Somit stellt er ein geeignetes Werkzeug zur Überprüfung von Nachrichtenkonfigurationen auf ihre Lauffähigkeit dar.
\end{itemize}