Add final version of master thesis.

content/conclusion.tex

@@ -0,0 +1,83 @@
+\chapter{Conclusion}
+\label{chapter:conclusion}
+
+\subsubsection{Cycle Accurate Tracing}
+
+Hypothesis~\ref{hyp:1} asks whether there is a trace technique capable of
+recording cycle accurate traces with a duration of at least one second.  There
+exists three general measurement techniques.  Hybrid and software based trace
+tools rely on instrumentation.  Thus, they change the runtime behavior of
+an application and do not allow cycle accurate trace recording.
+
+Additionally, an on-chip memory to buffer the recorded trace events is
+required.  Hence, the trace duration is strongly limited by the available
+memory.  An application with 28 tasks can only be traced for \unit[350]{ms}
+using the Gliwa T1 hybrid trace tool \cite{kastner2011integrated} providing
+events solely on task level.  Runnables were not even considered.
+
+Hardware tracing is the only trace technique that allows cycle accurate traces
+with a duration of at least one second.  Actually, durations of over ten
+seconds are possible with the correct hardware configuration.
+
+However, there are certain limitations for the hardware platform used in this
+thesis.  Depending on the clock configuration not all data events are recorded.
+This can be avoided by using a CPU core clock frequency smaller or equal than
+\unit[160]{MHz}.  Therefore, Hypothesis~\ref{hyp:1} is true.
+
+
+\subsubsection{ORTI Based Software to System Mapping}
+
+Hardware trace tools create traces on software level.  This level is not
+sufficient for the real-time analysis of embedded systems.  A transformation
+from software to system level is therefore required.  \gls{orti} was designed
+to give third party tools additional information for the trace recording of
+applications that use an \gls{osek} compliant \gls{os}.  Hypothesis~\ref{hyp:2}
+asks if \gls{orti} is sufficient to create a complete mapping from software to
+system level.
+
+It has been shown that \gls{orti} can be used to cover only a subset of the
+\gls{os} entity types specified in the \gls{btf} standard.  Even for those
+entities covered by \gls{orti} no complete mapping is feasible.  For example,
+information about task entities is included in the \gls{orti} file, but it is
+not feasible to determine the source entity for a \emph{mtalimitexceeded}
+event.  Consequently, Hypothesis~\ref{hyp:2} does not hold.
+
+However, it should be noted that \gls{orti} allows it to specify \gls{os}
+vendor specific attributes.  This means in case a mapping is basically possible
+as claimed by Hypothesis~\ref{hyp:3} then it would be possible to include the
+required information in the \gls{orti} file.
+
+Nevertheless, to the best of my knowledge this thesis is the first work to show
+that \gls{btf} \emph{trigger} actions and all process actions except
+\emph{mtalimitexceeded} can be created based on the \gls{orti} sections
+specified by \gls{osek}.
+
+
+\subsubsection{Software to System Mapping}
+
+No complete mapping from software to system entities is feasible by relying
+solely on the information in the \gls{orti} file.  Additional information is
+required to achieve a complete mapping.  On the one hand a detailed
+understanding of the \gls{os} internals is required, on the other hand meta
+information must be provided to the transformation algorithm.
+
+The concept of runnables and signals is not specified by \gls{osek}.
+Basically, runnables are functions and signals are variables.  It is possible
+to create runnable and signal events via function and data tracing.  A list of
+all entities is required to distinguish regular functions from runnables and
+regular variables from signals.
+
+To create \gls{btf} events for the event entity type it is necessary to
+understand the respective code of the \gls{os}.  By parsing the statically
+created C header files the event \glspl{id} can be retrieved and the correct
+events can be created.
+
+Semaphore events are the most complex entity types to reconstruct via
+hardware tracing.  \gls{btf} supports all possible types of semaphore like
+synchronization mechanisms.  Hence, a variety of different actions are
+specified.  A possible mapping for \gls{osek} resource entities is nevertheless
+provided in this thesis.
+
+To the best of my knowledge this is the first work to show that all \gls{btf}
+signal, runnable, event, and semaphore actions can be recreated from an
+\gls{osek} compliant \gls{os}.  Therefore, Hypothesis~\ref{hyp:3} is true.