% $Id: casestudy.tex 16889 2009-02-21 03:51:46Z gokhale $
\subsection{Representative Case Study}
\label{sec:casestudy}

The Basic Single Processor (BasicSP) scenario shown in
Figure~\ref{fig:basicsp} is a reusable component assembly available in
the Boeing Bold Stroke~\cite{Sharp:98} component avionics computing
product line.  BasicSP uses a publish/subscribe service for event-based
communication among its components, and has been  developed using a
component middleware platform, such as LwCCM.  

\begin{figure}[htb]
  \centering  
    \includegraphics[width=0.75\textwidth,keepaspectratio]{BasicSP}  
    \bfcaption{Basic Single Processor Component Assembly}
\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{Timer} 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 LwCCM) must ensure
that these application-level QoS requirements are satisfied.  For
achieving the goal of reducing the latency between \emph{Timer} and
\emph{NavDisplay} components, it is crucial to carefully analyze the QoS
options chosen for each component in BasicSP, and exploit opportunities
to either reuse or combine them such that this goal can be met.  

The system is deployed on two physical nodes.  Application developers
of our case study choose a modeling environment to model the BasicSP
component assembly and annotate its real-time requirements as shown in
Figure~\ref{fig:basicsp_model}.  We have used the Generic Modeling
Environment (GME)~\cite{GME:01} for modeling the DRE system.  GME
provides a graphical user interface that can be used to define both
modeling language semantics and system models that conform to the
languages defined in it.  \emph{Model interpreters} can be developed
using the generative capabilities in GME that parse and can be used to
generate deployment, and configuration artifacts for the modeled
application. 

\begin{figure}[htb]
  \centering  
    \includegraphics[width=0.75\textwidth,keepaspectratio]{BasicSP_Model}  
    \bfcaption{BasicSP Model}
\label{fig:basicsp_model}
\end{figure} 

The developers use the model interpreter plugins shown in the figure to
automatically synthesize deployment and configuration metadata that
describes how the components are assigned to nodes of the operating
environment, and what configuration options of the component middleware
are to be used for each component.  These model interpreters encapsulate
the bin packing and schedulability analyses algorithms alluded to
earlier. 

The generated metadata is usually in the form of XML, which is then
parsed by the underlying middleware's deployment and configuration tool
to deploy and configure the DRE system before operationalizing it.  As
mentioned earlier, due to a lack of finer-grained decisions, the
generated XML metadata will often result in DRE system software
architectures that perform suboptimally.

