MT/content/future.tex

\chapter{Future Work}
\label{chapter:future_work}

\subsubsection{Improve Trace Interface Standard}

It has been shown that a complete software to system mapping is possible for an
\gls{osekos} and should accordingly also be possible for an \gls{autosaros}.
However, detailed knowledge of the \gls{os} is required to understand and
implement this mapping.  \gls{osek} tries to minimize this effort via the
\gls{orti} trace interface.  Unfortunately, this interface is only regulated
for a subset of all \gls{os} entity types.

Some entities like spinlocks, semaphores, and inter-process communication
techniques like \gls{autosar} sender-receiver-communication are not covered at
all.  In theory \gls{osek} allows it to add additional attributes to the
\gls{orti} file, but this option is currently not comprehensively used by the
\gls{os} vendors.  To solve this problem further efforts to reach a common
trace interface standard for all \gls{autosar} system entities should be made.

\subsubsection{Evaluate Different Hardware Platforms}

In this thesis the feasibility of recording cycle accurate hardware traces was
validated for the Infineon Aurix TriCore processor family using the Infineon
Multi-Core Debug System.  As described in \autoref{subsection:hardware_tracing}
there exists different trace standards for other processor families.

In order to achieve a better understanding of the trace capabilities of various
hardware platforms different other processor families should be tested in the
future.  It has been shown that cycle accurate recording of data events on the
Infineon TC298TF processor is only feasible for certain clock settings.  It
would be interesting to know if similar constraints also exist for other
platforms.

\subsubsection{Evaluate Different Operating Systems}

\glsdesc{ee} is used as a representative for an \gls{osek} compliant \gls{os}
in this thesis.  It is a sufficient choice because of the available source code
and the permissive license.  For \gls{ee}, it could be shown that a mapping
from software to system entities is feasible.

However, \gls{osek} has been taken over from \gls{autosar}.  Since
\gls{autosar} is a superset of \gls{osek} the reasoning for most system
entities is legitimate for both \gls{os} standards. Nevertheless, \gls{autosar}
introduces new synchronization patterns (of which some have been adopted by
\gls{ee}) and it would be interesting to know if a mapping is possible for
those new techniques as well.

Additionally, a complete mapping could only be created because the source code
of \gls{ee} is freely available.  It would be interesting to know if the same
approach is feasible for a commercial \gls{os} that does not make its source
code available.  This is an important question to answer since the automotive
industry relies predominantly on commercial \glspl{os}.

\subsubsection{Validate Mapping With Real World Applications}

Finally, the feasibility of the software to system mapping has been shown and
validated for several test applications.  One part of those applications was
created manually to cover specific test cases, the other part was created
randomly.   However, all test applications have in common that they do not
execute real functionality.  Instead, dummy instructions are used to simulate
runtime that would emerge on real hardware due the computation of algorithms
and feedback loops.

It may be possible that the trace capability of the tested hardware is limited
for real applications.  If this is the case the mapping introduced in this
thesis may not be completely applied in the real world for example because
the bandwidth for recording \gls{os} data events is limited.  To investigate
this question industrial case studies should be conducted based on the
approaches discussed in this thesis.

\subsubsection{Trace a Multi-ECU Setup}

In many environments microcontrollers operate in big networks.  For example, in
modern cars up to 70 ECUs are installed and connected via at least five
different field bus systems \cite{maxmaster}.  In such systems correct system
performance is not only dependent on the behavior of a single controller, but
also on the interaction of the system as a whole.  The ability to trace
multiple ECUs in parallel would provided enormous benefits in the analysis and
validation of multi-ECU systems.

In order to get meaningful results from the analysis of a multi-ECU trace it is
mandatory that the timestamps from all ECUs are synchronous. Otherwise, the
delay between different processor would result in wrong evaluation metrics and
no valid conclusions could be drawn.  Therefore, the feasibility of a multi-ECU
trace environment is an interesting and important topic for future work.