86 lines
4.6 KiB
TeX
86 lines
4.6 KiB
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.
|