% $Id: scenario.tex 19213 2009-08-17 10:06:43Z gokhale $
\subsection{DRE system case study}
\label{sec:basicsp}

Determining which RTCORBA mechanisms and their configurations will
provide the most effective approach to realize domain-specific QoS
policies is a hard problem faced by DRE developers.  We use a simple
DRE use case to highlight these challenges.

The Basic Single Processor (BasicSP) shown in Figure~\ref{fig:basicsp}
is a scenario from the Boeing Bold Stroke component avionics computing
product line~\cite{Sharp:98}.  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=\columnwidth,keepaspectratio]{BasicSP}    
    \caption{Basic single processor}
\label{fig:basicsp}
\end{figure} 

As shown in Figure~\ref{fig:basicsp}, 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 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
RTCORBA-based) 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.
