MT/content/result.tex

\chapter{System Trace}
\label{chapter:btf}

In \autoref{section:trace_measurement} a trace has been defined as a
sequence of chronological ordered events.  An event is a system state change an
evaluator is interested in.  Various trace tools exist to record events.  They
can be classified into hardware, hybrid and software tools.

The same event can be represented on different levels as shown in
\autoref{fig:trace_event_levels}.  An event within the respective level
shall be called hardware, software or system event.  An event can be moved
from one level into another via transformation.  For example a voltage level
change in memory is a hardware event.  The corresponding software event could
be a value change of a certain variable.

Different representation levels do not relate to measurement tools with the
same name.  A hardware event can be measured directly via hardware tracing.
But it is also possible to detect the change of a variable via software
tracing.  Based on the software event the occurrence of the respective hardware
event can be deduced.  This means hardware event detection is not limited to
hardware tracing and the same is true for software events.

A well-defined format for events is required for further processing of recorded
traces.  Tools that analyze or visualize a trace must be able to interpret the
recorded data.  For example the hardware trace host software must be able to
understand the hardware events that are generated by the on-chip trace device.
Otherwise it is not possible to transform the hardware events into higher level
software events.

Depending on the measurement goal a different event level may be required:  A
hardware designer is not interested in the timing behavior of an engine control
unit, rather the correct functionality of a certain hardware register is of
interest.  On the other hand, an application architect relies on the correct
functionality of the hardware, but the timing behavior of an application on
architecture level must be analyzable.

\section{BTF}

A system level trace can be used to analyze timing, performance and reliability
of an embedded system.  \gls{btf} (\glsdesc{btf}) \cite{btf} was specified to
support these use cases.  It assumes a signal processing system, where one
entity influences another entity in the system.  This means an event does not
only contain the information about which system state changed, but also the
source for the change.  For example, a regular system event could be the
activation of a task with the corresponding timestamp.  A \gls{btf} event
additionally contains the information that the task activation was triggered by
a certain alarm.

A \gls{btf} event is defined as an octuple

\begin{equation}
  \label{eq:btf_trace}
  b_{k} = (t_k,\, \Psi_k,\, \psi_k,\, \iota_k,\, T_k,\, \tau_k,\, \alpha_k,\,
  \nu_k),\, k \in \mathbb{N},
\end{equation}

where each element represents a certain \gls{btf} field: $t_k$ is the
\emph{timestamp}, $\Psi_k$ is the \emph{source}, $\psi_k$ is the \emph{source
instance}, $\iota_k$ is the \emph{target type}, $T_k$ is the \emph{target},
$\tau_k$ is the \emph{target instance}, $\alpha$ is the event \emph{action} and
$\nu_k$ is an optional note.  A \gls{btf} trace can now be defined as

\begin{equation}
  B = \{b_k | t_{k} \leq t_{k+1} \wedge k \leq n\},\, n \in \mathbb{N},
\end{equation}

where $k$ is the index of a certain event and $n$ is the number of elements in
the trace.

The timestamp field is an integer value $t_k \in \mathbb{N}_{0}$.  All
timestamps within the same trace must be specified relative to a certain point
in time, which is usually the start of trace measurement.  System and trace
start can occur at different points in time. Consequently, neither trace nor
system start must occur at $t = 0$.  The time period between two events $b_{k}$
and $b_{k+1}$ can be calculated as $\Delta t = t_{k+1} - t_{k}$.  If not
specified otherwise, the time unit for $t_k$ is nanoseconds.

A \gls{btf} event represents the notification of one entity by another.  There
exist different entity types corresponding to the software and hardware objects
of an application.  Each entity of a certain type has an unique name that must
not be shared by entities of other types.  Certain entity types have a life
cycle.  This means multiple instances of the same entity can occur within the
same trace.  Instance counters are required to distinguish between different
instances of the same entity.  This is important for multicore systems where an
entity can run on two processor cores in parallel.
\autoref{fig:entity_inheritance} depicts the relationship between entity type,
entity and entity instance.

\begin{figure}[]
 \centering
 \includegraphics[width=0.7\textwidth]{./media/btf/entity_inheritance.pdf}
 \caption[\gls{btf} entity inheritance]{A \gls{btf} event represents the
 impact of one entity by another.  Entities have different types and multiple
 entities can exist for one type, identified by an unique name.  Entities that
 have a life cycle, such as runnables, can be instantiated multiple times.  An
 instance counter is required to distinguish multiple instantiations.}
 \label{fig:entity_inheritance}
\end{figure}

A basic entity type is a runnable, which is essentially a simple function.  A
system may contain of multiple runnable entities called \emph{Runnable\_1},
\emph{Runnable\_2} and \emph{Runnable\_3}.  The life cycle of a runnable starts
with the execution of this runnable and ends when it terminates.  A runnable
can execute different actions such as calling another runnable or writing a
variable.  In a multicore system the same runnable entity \emph{Runnable\_2}
may be executed by two other runnables that are running in parallel on
different cores.  If \emph{Runnable\_2} writes to a variable, it is not known
from which core that write occurred.  With the information about which instance
executed the write this problem is solved.

The \emph{source} and \emph{target} fields are strings that represent entities
which are part of the system.  The target entity is influenced by the source
entity.  \emph{Source instance} and \emph{target instance} are positive integer
values that identify the instance of the respective entity.  \emph{Target type}
is the type of the target entity.  Types are represented by their corresponding
type \gls{id}.  A source type field is not part of a \gls{btf} event even
though it would make sense in certain cases.

The \emph{action} field indicates the way in which way one entity is influenced
by another.  Depending on the source and target entity types, different actions
are possible and allowed by the specification.  The last field \emph{note} is
optional even though it can be used to carry additional information for certain
events.  \autoref{tab:btf_fields} summarizes the meaning of the different
\gls{btf} fields.

\begin{table}[]
  \centering
  \begin{tabular}{r|l}
    Field & Meaning \\
    \hline
    time            & Timestamp relative to a certain point in time.  \\
    source          & Name of the entity that caused an event.  \\
    source instance & Instance number of the entity that caused an event. \\
    target type     & Type of the entity that is influenced by an event.  \\
    target          & Name of the entity that is influenced by an event.  \\
    target instance & Instance of the entity that is influenced by an event. \\
    action          & The way in which target is influenced by source.  \\
    note            & An optional field that is used for certain events. \\
  \end{tabular}
  \caption[\gls{btf} event fields]{A \gls{btf} event contains of eight fields.
  An event describes the way in which one system entity is influenced by
  another one.}
  \label{tab:btf_fields}
\end{table}

A \gls{btf} trace can be persisted in a \gls{btf} trace file.  This file
contains of two sections: a meta and a data section.  The meta section stands
at the beginning of the file.  It contains information such as \gls{btf}
version, creator of the trace file, creation date and time unit used by the
time field.  Each meta attribute stands in a separate line in the form
\lstinline{#<attribute name> <attribute definition>}.  The data section
contains one \gls{btf} event per line in chronological order.  The first event
comes at the beginning of the data section and the last event stands at the end
of the file.  Comments are denoted by a \lstinline{#} followed by a space.
\autoref{listing:btf_example} shows an example trace file.

\begin{code}
\begin{lstlisting}[caption={[An example \gls{btf} trace file]A \gls{btf} trace
file contains of two sections. A meta section at the beginning of a file
includes information such as creator, creation date and time unit.  It is
followed by a data section that contains one event per line. Comments are
denoted by a number sign followed by a space.},
label={listing:btf_example}]
#version 2.1.4
#creator BTF-Writer (15.01.0.537)
#creationDate 2015-02-18T14:18:20Z
#timeScale ns
     0,     Sim,  0, STI,       S_1MS, 0, trigger
     0,   S_1MS,  0,   T,     T_1MS_0, 0, activate
   100,  Core_0,  0,   T,     T_1MS_0, 0, start
   100, T_1MS_1,  0,   R,  Runnable_0, 0, start
 25000, T_1MS_1,  0,   R,  Runnable_0, 0, terminate
 25100,  Core_1,  0,   T,     T_1MS_0, 0, terminate
#    |        |   |    |            |  |  |
# time   source   |    |       target  |  action
#  source instance     | target instance
#            target type
#
# Note that a number sign followed by a space denotes
# a comment. Whitespaces in the data section are ignored.
\end{lstlisting}
\end{code}


\section{BTF Entity Types}

\begin{table}[]
  \centering
  \begin{tabular}{c|c c }
    Category & Entity Type & Type \gls{id} \\
    \hline
                  & Task      & T \\
    Software      & \gls{isr} & I \\
                  & Runnable  & R \\
    \hline
                  & Signal    & SIG   \\
    \gls{os}      & Semaphore & SEM   \\
                  & Event     & EVENT \\
    \hline
                  & Simulation & SIM  \\
    Other         & Core       & Core \\
                  & Stimulus   & STI  \\
    \hline
                  & Instruction Block       & IB \\
                  & Electronic Control Unit & ECU \\
    Not discussed & Processor               & Processor \\
                  & Memory Module           & M \\
                  & Scheduler               & SCHED \\
  \end{tabular}
  \caption[\gls{btf} entity types]{\gls{btf} entity types can be divided into
  three categories: software, \gls{os} and other types.  Entity types are
  represented by their type \gls{id}.  Some types are not relevant for this
  thesis and are therefore not discussed.}
  \label{tab:entity_overview}
\end{table}

\gls{btf} specifies the entity types that can be used for \gls{btf} events.
Each entity type can be influenced by certain other types and vice versa.  The
actions or in other words, the way in which one entity can be influenced by
another, are also defined.  Different actions are possible for different entity
types.  Entity types can be categorized into software, \gls{os} and other
entity types.

Not all entity types specified by \gls{btf} are discussed in detail as shown in
\autoref{tab:entity_overview}.  The entity type instruction block (\emph{IB})
represents a sub fraction of a runnable.  This concept is used by simulation
but does not translate to a concept used by a real application.

An electronic control unit (\emph{ECU}) consist of a at least one processor
(\emph{Processor}).  This concept allows it to represent a system containing of
multiple processors that communicate with each other.  The recording of a multi
system aware hardware trace would required a measurement configuration with
multiple trace tools that are synchronized to each other.  The design of such a
setup was not in the scope of this thesis which is why ECU and processor
entities are not discussed.

Memory modules (\emph{M}) can be used to represent different memory sections of
a CPU\@.  The \gls{btf} specification does not provide further information
about memory modules.  Via hardware tracing the information about which memory
sections are accessed by certain data events becomes available.  Since the
specification does not provide further details about how to use memory modules,
no further discussion is possible.

The scheduler (\emph{SCHED}) entity type is used to represent actions executed
by the \gls{os} that relate to the scheduling of task and process instances.
Scheduler events become available implicitly via the respective process
actions.


\subsection{Software Entity Types}

\gls{btf} distinguishes three kinds of software entity types: tasks,
\glspl{isr} and runnables, with the respective type \glspl{id} \emph{T},
\emph{I} and \emph{R}.  Tasks and \glspl{isr} are collected under the umbrella
term process.  Accordingly, they share the same state and transition model as
shown in \autoref{fig:process_state_chart}.

\begin{figure}[]
 \centering
 \centerline{\includegraphics[width=1.3\textwidth]{./media/btf/process_state_chart.png}}
 \caption[Process state figure]{\gls{btf} specifies more process states than
 \gls{osek} (see \autoref{fig:extended_task_state_model}).  The additional
 states polling and parking are required to represent active waiting.  Not
 initialized and terminated indicate the beginning and end of a process
 lifecycle.  The green boxes between the states show the name of the \gls{btf}
 action for the respective transition.}
 \label{fig:process_state_chart}
\end{figure}

\textbf{Process} instances start in the \emph{not initialized} state.  From
there they can be \emph{activated} in order to switch into the \emph{active}
state by a stimulus (\emph{STI}) entity.  All state transitions except
\emph{activate} are executed by core (\emph{C}) entities.  An active process
can be changed into the \emph{running} state by the core on which the process
is scheduled.

A running process can \emph{preempt}, \emph{terminate}, \emph{poll} and
\emph{wait}.  Preemption occurs if another process is scheduled to be executed
on the core.  In this case, the process can no longer be executed and changes
into the \emph{ready} state.  A ready process \emph{resumes} running once the
core becomes available again.  If a process has finished execution it
terminates and switches into the \emph{terminated} state.  This finishes the
lifecycle of a process instance.

A process that \emph{polls} a resource switches into the active waiting state
\emph{polling}.  A process that \emph{waits} for an event switches into the
passive waiting state \emph{waiting}.  A \emph{waiting} process is
\emph{released} into the ready state if one of the requested events becomes
available.  If a polled resource becomes available, the task continues running
which is indicated by the \emph{run} action.

A polling process that is removed from the core is \emph{parked} and switched
into the \emph{parking} state.  If the polled resource becomes available while
the process is parking it is switched into the ready state.  This transition is
called \emph{release\_parking}.  Otherwise the process continues polling, once
it is reallocated to the core, which is called \emph{poll\_parking}.
\autoref{tab:process_overview} summarizes process state transitions.


\begin{table}[]
  \centering
  \begin{tabular}{c c c c}
     Current state & Next state & Action &  Source Entity Types\\
    \hline
    not initialized & active     & activate         & STI \\
    active          & running    & start            & C \\
    ready           & running    & resume           & C \\
    running         & ready      & preempt          & C \\
    running         & terminated & terminate        & C \\
    running         & polling    & poll             & C \\
    running         & waiting    & wait             & C \\
    waiting         & ready      & release          & C \\
    polling         & running    & run              & C \\
    polling         & parking    & park             & C \\
    parking         & ready      & release\_parking & C \\
    parking         & polling    & poll\_parking    & C \\
  \end{tabular}
  \caption[Process state table]{Process entities can be in different states.  A
  process instance starts in the not initialized state and finishes in the
  terminate state.  Each state transition has an unique action name.  The
  activate action can only be triggered by a stimulus entity.  All other
  actions can only be triggered by a core entity.}
  \label{tab:process_overview}
\end{table}

In addition to state transition actions, \gls{btf} specifies process
notification actions.  This actions do not trigger a process state change, but
indicate other events related to a process entity.  The \emph{mtalimitexceeded}
action is triggered if more task instances than the allowed maximal value are
activated.  If this happens, no new task instance is created.  Therefore, a
notification event is necessary to make the event available in the trace.

All other process notification actions are related to migration, the
reallocation of a process from one core to another.  \gls{osekos} does not
support process migration since a separate kernel is executed on each core.
Thus migration notifications are not relevant for an \gls{osek} compliant
\gls{os}.  Additionally migration actions become available implicitly via the
respective process transition actions.  If a process instance is preempted on
one core and resumed on another, the resume event will have a different source
core than the preempt event.  Consequently, the related migration event is
known.


\textbf{Runnable} instances start in the not initialized state.
Runnables can be \emph{started} by \glspl{isr} and tasks in order to switch
into the \emph{running} state.  A runnable that \emph{terminates} switches into
the \emph{terminated} stated and therefore finishes its lifecycle according to
\autoref{tab:runnable_overview}.

Since a runnable can only be executed from a process context it can not
continue running if the respective process is preempted.  For this case the
runnable must be \emph{suspended} and switches into \emph{suspended} state.
Once the process resumes execution the runnable can also \emph{resume}.

\begin{table}[]
  \centering
  \begin{tabular}{c c c c}
     Current state & Next state & Action &  Source Entity Types\\
    \hline
    not initialized & running    & start         & T, I \\
    running         & terminated & terminate     & T, I \\
    running         & suspended  & suspend       & T, I \\
    suspended       & running    & resume        & T, I \\
  \end{tabular}
  \caption[Runnable state table]{All runnable actions can be triggered by task
  and \gls{isr} entity types.  A runnable lifecycle starts when the runnable
  first starts execution and ends when the runnable is terminated.  A runnable
  is suspended and resumed depending on the process context in which it is
  executed.}
  \label{tab:runnable_overview}
\end{table}

\subsection{OS Entity Types}

\begin{table}[]
  \centering
  \begin{tabular}{c c c}
    Action & Source Entity Types \\
    \hline
    read   & P \\
    write  & P, STI \\
  \end{tabular}
  \caption[Signal actions]{Signals can be read or written.  For a write event
  the new value is provided via the note field.}
  \label{tab:signal_overview}
\end{table}

\gls{os} event types are categorized into signal, semaphore and event types.
Signals are identified by \emph{SIG}, semaphores by \emph{SEM} and events by
\emph{EVENT}.

\textbf{Signal} entities represent variables that are relevant for the analysis
of an application.  There are only two signal actions: \emph{read} and
\emph{write} as shown in \autoref{tab:signal_overview}.  A signal can be read
by a process entity.  This means that the value of a variable is retrieved from
memory.  A signal entity does not have a lifecycle, thus the instance counter
value for signals can remain constant.

Write actions can be executed by process and stimulus entities.  A write action
means that a new value is assigned to a variable.  If this assignment is done
from process context, the respective process entity is the source for the write
event.  Otherwise a stimulus entity can be used to represent the source, for
example if a signal is changed by the \gls{os} or a hardware module.

For signal writes, the \gls{btf} note field must be used to denote the value
that was assigned to a variable,  usually represented by an integer value in
decimal representation.  However, \gls{btf} does not specify in which form the
value must be provided.  For read events the note field can optionally be used
to indicate the value of the variable that was accessed.

\textbf{Semaphores} can be used to control access to a common resource in
parallel systems.  The basic idea is that a process can request a semaphore,
before it enters a critical section, for example a section that contains access
to shared variables.  If the semaphore is free, the request is accepted and the
semaphore will be locked.  All requests to a locked semaphore fail, thus no
other process can access the shared variables.  When the process leaves the
critical section, it releases the semaphore, which then becomes free for other
resources.

There exist different types of semaphores.  A counting semaphore may be
requested multiple times.  Every time a counting semaphore is requested, a
counter is incremented and every time a counting semaphore is released, the
same counter is decremented.  A counting semaphore is locked once the counter
has reached a predefined value and the initial counter value is zero.

\begin{table}[]
  \centering
  \begin{tabular}{r l}
    Action & Meaning \\
    \hline
    requestsemaphore   & Process requests a semaphore                        \\
    exclusivesemaphore & Process requests a semaphore exclusively            \\
    assigned           & Process is assigned as the owner of a semaphore     \\
    waiting            & Process is assigned as waiting to a locked semaphore\\
    released           & Assignment from process to semaphore is removed     \\
    increment          & Semaphore counter is incremented                    \\
    decrement          & Semaphore counter is decremented                    \\
  \end{tabular}
  \caption[Semaphore process actions]{Processes can interact with semaphores
  in different ways.  If a process requests a semaphore successfully, it is
  assigned to the semaphore and the counter is incremented, otherwise a waiting
  event is triggered.  Once a semaphore is released, the assignment is removed
  and the counter is decremented.}
  \label{tab:semaphore_process}
\end{table}

A binary semaphore is a specialization of a counting semaphore for which the
maximum counter value is one.  A mutex is a binary semaphore that supports an
ownership concept.  This means a mutex knows all processes that may request it.
This information allows the implementation of priority ceiling protocols in
order to avoid deadlocks and priority inversion.  The \gls{osek} term for mutex
is \emph{resource} as described in \autoref{subsection:osek_architecture}.

\gls{btf} semaphore events can be used to represent the different semaphore
types mentioned above.  Semaphore actions can be divided into two categories:
Actions triggered by process instances as shown in
\autoref{tab:semaphore_process} and actions executed by a semaphore entity
itself.

A process request to a semaphore is indicated by \emph{requestsemaphore}.  If a
request is successful (the semaphore is not locked), the semaphore counter is
\emph{incremented} and the process is \emph{assigned} to the semaphore.  The
\emph{exclusivesemaphore} action represents a semaphore request that only
succeeds, if the semaphore is currently not requested by any other process,
i.e.\ the counter value is zero.  If a process fails to request a semaphore and
switches into polling mode, in order to wait for this semaphore, this is
indicated by the \emph{waiting} action.  A process that releases a semaphore
\emph{decrements} the semaphore counter and the respective semaphore is
\emph{released}, the process is no longer assigned to it.

\begin{figure}[]
 \centering
 \centerline{\includegraphics[width=1.2\textwidth]{./media/btf/semaphore_state_chart.png}}
 \caption[Semaphore states and actions]{Semaphore entities do not have a
 lifecycle.  Nevertheless, they must be initialized before they are ready for
 the first time.  A semaphore can be unlocked or locked.  A counting semaphore
 can be requested multiple times in which cases it changes into the used state.
 If there are no requests the semaphore is free.  A semaphore that has at least
 as many requests as allowed if full and changes into the locked state.
 Further requests in the locked stated result in an overfull action.}
 \label{fig:semaphore_state_chart}
\end{figure}

Semaphores do not have a lifecycle, which is why their instant counter remains
constant.  Nevertheless, a semaphore must be moved from the \emph{not
initialized} to the \emph{free} state by the \emph{ready} action before it is
requested for the first time as shown in figure
\autoref{fig:semaphore_state_chart}.

A free semaphore is not requested by any processes.  Once it is requested for
the first time, the behavior is dependent on the semaphore type.  A mutex or
binary semaphore is \emph{locked} and moved into the \emph{full} state.  A
counting semaphored is changed into the \emph{used} state which is indicated by
the \emph{used} action.  The used action is repeated for a counting semaphore
for each further request and release of the semaphore, as long as the counter
value stays greater than zero and smaller than the maximum value.  If the
counter value of a used semaphore becomes zero this semaphore is \emph{freed}.
If the maximum counter value is reached the semaphore state becomes \emph{full}
which is indicated by the \emph{lock\_used} action.

When a full binary semaphore or mutex is released, it is \emph{unlocked} and
becomes free again, while a counting semaphore is changed back to the used
state, indicated by the \emph{unlock\_full} action.  A request to a full
semaphore entity results in an \emph{overfull} action and the state is changed
to \emph{overfull}.  The overfull state indicates that there is at least one
process polling a semaphore.  Each additional request also results in an
overfull action.  Once there are no more processes waiting for a semaphore,
this semaphore becomes full again which is indicated by the \emph{full} action.
\autoref{tab:semaphore_semaphore} summarizes semaphore states and their
meaning.

\begin{table}[]
  \centering
  \begin{tabular}{r|l}
    State        & Meaning \\
    \hline
    not initialized & Semaphore is not ready     \\
    free            & No process is assigned to the semaphore \\
    used            & At least one process is assigned \\
    full            & Maximum number of processes are assigned   \\
    overfull        & Semaphore is full and there are further requests \\
  \end{tabular}
  \caption[Semaphore state overview]{Semaphores can be in five different
  states.  Before a semaphore entity can be used, it must be moved into the
  free state.  No process is assigned to a free semaphore.  A counting
  semaphore that has not yet reached its maximum request value, is in used
  state. Once no further requests are accepted, a semaphore is full.  A full
  semaphore that is requested by another process is said to be overfull.}
  \label{tab:semaphore_semaphore}
\end{table}

\textbf{Events} are objects used for inter process communication, provided by
the \gls{os}.  One process can use an event to notify another one, for example
when a computation finishes or a resource becomes available.  Consequently, the
source entity for an event action must be a task or \gls{isr}.  Event entities
do not have a lifecycle, therefore, no instance counter value is required.

There exist three event actions: \emph{wait\_event}, \emph{clear\_event} and
\emph{set\_event}.  A process, that waits for an event, changes into passive
waiting mode, until the respective event is set.  An event can be set by
another process.  For the \emph{set\_event} action it is necessary to specify
for which process entity the respective event is set.  This information is
provided via the \gls{btf} note field.  An event can be cleared by the process
for which the event was set.


\subsection{Other Entity Types}

There are three other entity types: simulation, core and stimulus entities.
The type \gls{id} for simulation is \emph{SIM}, for core \emph{C} and for
stimulus \emph{STI}.

\textbf{Stimul} are used to depict application behavior that cannot be
represented by other entity types.  The only stimulus action is \emph{trigger}.
A stimulus can be triggered by process and simulation entities,  Once a
stimulus is triggered, it can be used for the actual event, i.e.\ the
activation of a task instance.  Multiple stimulus instances can exist in a
system at a certain point in time.  Thus the instance counter field must be
used for stimulus events.

\begin{table}[]
  \centering
  \begin{tabular}{r|l}
    Action      & Meaning \\
    \hline
    finalize    & Initialization of system environment completed \\
    error       & An error record during trace recording \\
    tag         & Transmit meta information about the source entity \\
    description & Provide a description for the source entity   \\
  \end{tabular}
  \caption[Simulation actions]{The simulation entity can be used to provide
  meta information about the trace environment.  Simulation is misleading since
  it must also be used in a \gls{btf} trace recorded on hardware.  That is why
  the term \emph{system} is more appropriate.  The system entity can be used to
  trigger stimulus instances.  For tag and description events the note field
  is used to provide meta information.}
  \label{tab:simulation_actions}
\end{table}

\textbf{Simulation} entities are used to provide meta information in a
simulated \gls{btf} trace as shown in \autoref{tab:simulation_actions}.
Nevertheless, it can, and must, also be used in a hardware trace.  For example,
a stimulus entity that activates a task can be triggered by a process or
simulation entity.  In the first case, the resulting \gls{btf} events represent
an inter-process activation.  However, in the case that a process gets
activated by an alarm, process is not the correct source type and simulation
must be used instead.  Since a simulation entity does not make too much sense
in a hardware trace, \emph{system} is a more appropriate term to denote the
concept represented by the simulation entity type.

\textbf{Core} entities are used to provide an execution context for process
entities.  Only one process can be allocated to a core at the same time.  Core
entities do not have a lifecycle.