% $Id: scenario.tex 16638 2009-01-29 19:00:10Z gokhale $
\sqzlarge
\subsection{DRE system case study}
\label{sec:basicsp}
\sqztiny
The Basic Single Processor (BasicSP) is a scenario from the 
Boeing Bold Stroke component avionics 
computing product line.  BasicSP uses a publish/subscribe service 
for event-based communication among its components, and has been 
developed using a QoS-enabled component middleware 
platform. The application is deployed using a single deployment 
plan on two physical nodes.

\begin{figure}[htb]
  \centering
  %\vspace{-0.85in}
    \includegraphics[width=0.5\columnwidth,keepaspectratio]{BasicSP}    
    \caption{Basic single processor}
\label{fig:basicsp}
\end{figure} 

A GPS device sends out periodic position updates to
a GUI display that presents these updates to a pilot.  The desired
data request and the display frequencies are at
20 Hz. The scenario shown in Figure~\ref{fig:basicsp} begins 
with the \emph{GPS} component being invoked by the 
\emph{Timer} component. On receiving a pulse event from 
the \emph{Timer}, the \emph{GPS} component generates 
its data and issues a data available event.  The \emph{Airframe} component 
retrieves the data from the \emph{GPS} component, updates its 
state, and issues a data available event.  Finally, the 
\emph{NavDisplay} component retrieves the data from the 
\emph{Airframe} and updates its state and displays it to the pilot. In its
normal mode of operation, the \emph{Timer} component generates pulse 
events at a fixed priority level, although its real-time configuration
can be easily changed such that it can potentially support multiple 
priority levels.

It is necessary to carefully examine the end-to-end application critical 
path and configure the system components correctly such that the display
refresh rate of 20 Hz may be satisfied.  In particular, the latency between 
\emph{Airframe} and \emph{NavDisplay} components needs to be minimized to 
achieve the desired end goal. To this end, several characteristics of the 
BasicSP components are important and must be taken into account in determining 
the most appropriate QoS configuration space. For example, the \emph{NavDisplay} 
component receives update events only from the \emph{Airframe} component and 
does not send messages back to the sender \emph{i.e.}, it just plays the role of a 
client. The \emph{Airframe} component on the other hand communicates with both 
the \emph{GPS} and \emph{NavDisplay} components thereby playing the role of 
a client as well as a server. Various QoS options provided by the target middleware 
platform (in case of BasicSP, it is RT-CCM) ensure that these application level
QoS requirements are satisfied. In the remainder of the paper, we focus on
verification and validation of the QoS options generated using our
approach.
