\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.