84 lines
4.3 KiB
TeX
84 lines
4.3 KiB
TeX
|
\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.
|