Add final version of master thesis.

content/future.tex

@@ -0,0 +1,85 @@
+\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.