\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{# }. 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.