# root/ossiedev/branches/jsnyder/STTT_paper/elsarticle-seeralan-snyder-submitted.tex@10458

Revision 10458, 47.5 KB (checked in by cdietric, 3 years ago)

replaced figure 1, added authors, other minor edits

Line
1%%
2%% This is file elsarticle-template-num.tex',
3%% generated with the docstrip utility.
4%%
5%% The original source files were:
6%%
7%% elsarticle.dtx  (with options: numtemplate')
8%%
9%% Copyright 2007, 2008 Elsevier Ltd.
10%%
11%% This file is part of the 'Elsarticle Bundle'.
12%% -------------------------------------------
13%%
14%% It may be distributed under the conditions of the LaTeX Project Public
17%%    http://www.latex-project.org/lppl.txt
18%% and version 1.2 or later is part of all distributions of LaTeX
19%% version 1999/12/01 or later.
20%%
21%% The list of all files belonging to the 'Elsarticle Bundle' is
22%% given in the file manifest.txt'.
23%%
24
25%% Template article for Elsevier's document class elsarticle'
26%% with numbered style bibliographic references
27%% SP 2008/03/01
28
29\documentclass[preprint,12pt]{elsarticle} %% uncomment for single-column format
30%%\documentclass[5p, pdftex]{elsarticle} %% uncomment for two-column format
31
32%% Use the option review to obtain double line spacing
33%%\documentclass[authoryear,preprint,review,12pt,pdftex]{elsarticle}
34
35%% Use the options 1p,twocolumn; 3p; 3p,twocolumn; 5p; or 5p,twocolumn
36%% for a journal layout:
37%% \documentclass[final,1p,times]{elsarticle}
38%% \documentclass[final,1p,times,twocolumn]{elsarticle}
39%% \documentclass[final,3p,times]{elsarticle}
40%% \documentclass[final,3p,times,twocolumn]{elsarticle}
41%% \documentclass[final,5p,times]{elsarticle}
42%% \documentclass[final,5p,times,twocolumn]{elsarticle}
43
44%% if you use PostScript figures in your article
45%% use the graphics package for simple commands
46%% \usepackage{graphics}
47%% or use the graphicx package for more complicated commands
48%% \usepackage{graphicx}
49%% or use the epsfig package if you prefer to use the old commands
50%% \usepackage{epsfig}
51
52%% The amssymb package provides various useful mathematical symbols
53\usepackage{amssymb}
54%% The amsthm package provides extended theorem environments
55%% \usepackage{amsthm}
56
57%% The lineno packages adds line numbers. Start line numbering with
58%% \begin{linenumbers}, end it with \end{linenumbers}. Or switch it on
59%% for the whole article with \linenumbers.
60%% \usepackage{lineno}
61
62\journal{MCM}
63
64\begin{document}
65
66\begin{frontmatter}
67
69
70%% use the tnoteref command within \title for footnotes;
71%% use the tnotetext command for theassociated footnote;
72%% use the fnref command within \author or \address for footnotes;
73%% use the fntext command for theassociated footnote;
74%% use the corref command within \author for corresponding author footnotes;
75%% use the cortext command for theassociated footnote;
78%% \title{Title\tnoteref{label1}}
79%% \tnotetext[label1]{}
80%% \author{Name\corref{cor1}\fnref{label2}}
83%% \fntext[label2]{}
84%% \cortext[cor1]{}
86%% \fntext[label3]{}
87
88\title{Open Source Software Defined Radio Tools for Education, Research, and
89Rapid Prototyping}
90
92%% \author[label1,label2]{}
95
96\author{Deepan~Seeralan, Jason~Snyder, Shereef~Sayed, Jeffery~Wilson, Carl~B.~Dietrich, Stephen~H.~Edwards, Jeffrey~H.~Reed}
97
99
100\begin{abstract}
101%% Text of abstract
102A set of rapid development, control, and monitoring tools have been developed as part
103of the OSSIE open source Software Defined Radio (SDR) project, which is based on the
104U.S. Department of Defense Software Communications Architecture (SCA).  SDR is an
105emerging area of wireless communications in which radio functionality that was previously
106implemented in analog hardware or digital application specific integrated circuits
107(ASICs) is instead implemented in programmable and reconfigurable processing devices.
108By moving this functionality into software, radios can be made more flexible to support
109a wide range of communications standards or waveforms, limited only by the capabilities
110of the software developers and the hardware on which the applications will run.
111Open source SDR software such as that supplied by the OSSIE project provides an important resource
112for education, research, and rapid prototyping in this interdisciplinary field that
113integrates several areas within Electrical Engineering, Computer Engineering, and
114Computer Science.  Rapid development tools are needed to abstract the complexities
115of the SCA from developers and speed application development.  The Waveform Workshop,
116a collection of tools for use with the OSSIE software, enables rapid development,
117observation, and debugging of OSSIE SDR waveform applications.  We describe the
118functionality and implementation of these tools as well as their use in an SDR
119application development work flow, and outline planned enhancements.
120\end{abstract}
121
122\begin{keyword}
123Software Defined Radio \sep Software Communications Architecture
124%% keywords here, in the form: keyword \sep keyword
125
126%% PACS codes here, in the form: \PACS code \sep code
127
128%% MSC codes here, in the form: \MSC code \sep code
129%% or \MSC[2008] code \sep code (2000 is the default)
130
131\end{keyword}
132
133\end{frontmatter}
134
135%% \linenumbers
136
137%% main text
138\section{Introduction}
139\label{introduction}
140The Waveform Workshop is  a set of software tools that have been developed as
141part of the OSSIE open source Software Defined Radio (SDR) project
142$\cite{Aguayo2009b}$, $\cite{ossieweb}$, which is based on the U.S. Defense
143Department's Software Communications Architecture (SCA) $\cite{sca}$,
144$\cite{bard}$, $\cite{Aguayo2009a}$.  These tools allow SDR students,
145researchers, and developers to create signal processing components and
146waveform applications for radio communications and to run, configure, control,
147and monitor operation of these applications in real time.
148
150\label{introduction:sdr}
152functionality that is traditionally performed by analog hardware and digital
153application specific integrated circuits (ASICs).  SDR employs general purpose processors (GPPs), digital signal processors (DSPs), and field programmable gate arrays (FPGAs) that can be programmed or configured to provide great flexibility and support for multiple radio communications standards or waveforms.  Within limits of its hardware, a well designed SDR can support standards that were not conceived at the time the radio was designed $\cite{Reed2002}$.  SDR is of interest for both commercial $\cite{Vanu}$ and military $\cite{JTRS}$ applications.
154
155\subsection{The Software Communications Architecture}
156\label{introduction:sca}
157The SCA is an open standard associated with the U.S. Department of Defense Joint Tactical Radio System (JTRS) $\cite{JTRS}$.  The SCA is a component and service based architecture that delineates and provides guidance for implementation of SDR infrastructure (e.g., the SCA core framework) and application software (e.g., waveform applications and signal processing components).  The SCA makes extensive use of software design patterns $\cite{Gamma}$, and of other standards that include POSIX $\cite{POSIX}$, CORBA $\cite{CORBA}$, and XML $\cite{XML}$.  Components in the SCA communicate using Common Object Resource Broker Architecture (CORBA) middleware, which provides interprocess communication and remote procedure call capability, allowing methods associated with remote components implemented in a variety of languages to appear as local function calls.  XML is used to store profile or configuration information.
158
159\subsection{OSSIE}
160\label{introduction:ossie}
161The Open Source SCA Implementation - Embedded (OSSIE) project was started in 2003 by postdoctoral fellow Max Robert and a team of students at Virginia Tech $\cite{Robert2004}$.  OSSIE software consists of a core framework, rapid prototyping tools, and a library of application software (signal processing components and waveform applications).  The project also provides materials for SDR education, training, and self study.  The set of rapid prototyping tools for OSSIE, known as the Waveform Workshop, is key to all aspects of the project.  The Waveform Workshop includes tools for developing signal processing components and waveform applications, running, visualizing, and debugging waveform applications, and controlling and configuring waveform applications at run time.
162
163\subsection{Direct Manipulation Tools}
164\label{introduction:directmanipulationtools}
165OSSIE existed before the Waveform Workshop, but was much more difficult to use.
166Component and waveform XML descriptors had to written and installed by hand.
167Controlling waveforms was limited to starting and stopping them, and there was
168no way to monitor or manipulate running waveforms. The Waveform Workshop
169addresses this by providing a direct manipulation interface when creating and
170running waveforms and components. For example, a user might want to create a
171waveform that consists of two components called A and B with a connection from
172A's output port to B's input port. Before the Waveform Workshop, the user would
173have to hand edit the XML descriptors for the waveform, adding elements for each
174component, as well as for the ports and the connection itself. With the Waveform
175Workshop, waveforms are created by simply dragging together icons
176that represent components. The component ports are automatically displayed, and
177connections can be made by dragging one port onto another. The Waveform Workshop then takes care of generating the correct XML descriptors. The Waveform Workshop also provides a direct manipulation interface for running and monitoring waveforms. The user can see a block diagram of a waveform showing each component, and can plot the output of any port. Finally, the user can view and update component property values in realtime, allowing him or her to observe the effects of changing properties.
178
179\subsection{Motivation for SCA-Based SDR Tools}
180\label{introduction:toolmotivation}
181
182The extensive nature of the SCA and its use of CORBA and XML both motivate and facilitate development of tools for SCA-based SDR development.  In most cases it is desirable to abstract the interface code required by CORBA from communciations engineers who develop signal processing compnents and waveform applications.  Fortunately, use of CORBA also allows SCA-based SDR software tools to interact with SCA core frameworks and applications that are running either locally or remotely, while tools can parse XML files to obtain information needed to perform a variety of functions.  Commercial tools for SCA-based SDR development are available $\cite{SpectraCX}$, but open source tools that work with OSSIE are needed for educational and research purposes.  The Waveform Workshop provides these capabilities to researchers, students, and other SDR developers who use the OSSIE SDR software.  Section $\ref{waveformworkshoptools}$ introduces the tools, and Sections $\ref{sdrapplicationdevelopment-oef}$ - $\ref{sdrapplicationdevelopment-alf}$ describe their use in developing, configuring, and monitoring a waveform application.
183
184%-------------------- FIGURE: EMPTY WORKSPACE IN OEF --------------------
185\begin{figure}[ht]
186\centering
187%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
188\includegraphics[width=\textwidth]{figure1_SDR_Development_using_Waveform_Workshop.pdf}
189% trim = left bottom right top
190\caption{SDR application development using the OSSIE Waveform Workshop tools}
191\label{fig:oef:emptyworkspace}
192\end{figure}
193
194\section{The Waveform Workshop Tools}
195\label{waveformworkshoptools}
196
197Currently, three tools make up the Waveform Workshop.  These tools can be used in an iterative process of creating, testing, and improving OSSIE signal processing components and waveform applications.  The tools are:
198\begin{enumerate}
199\item The OSSIE Eclipse Feature (OEF), a plug-in for the Eclipse open-source integrated development environment that provides capability for creation of both waveform applications and individual signal processing components.
200
201\item The Waveform Dashboard (WaveDash), a tool that uses information and capabilities available through the SCA to provide an easily reconfigurable graphical interface for interacting with OSSIE waveform applications.
202
203\item A waveform application visualization and debugging environment known as ALF (not an acronym).
204
205\end{enumerate}
206\subsection{The OSSIE Eclipse Feature (OEF)}
207\label{toolsdescription:oef}
208
209OEF is a port of the OSSIE Waveform Developer (OWD), an open source python tool for rapid component and waveform prototyping.  OWD generated the necessary XML descriptors and CORBA-enabled skeleton implementations for SCA-based signal processing components and XML files that specify instantiation, interconnection, and deployment of these components to form waveform applications that implement end-to-end communications waveforms. In the case of signal processing components, the SDR developer who used OWD then had to fill in the implementation using his or her editor of choice. Finally, the component or waveform files had to be built and installed from the command line using automake tools. The motivation behind OEF was to duplicate the automatic generation functionality of OWD, while adding support for the rest of the development process. To do so, OEF was developed as a plug-in for the Eclipse IDE.
210
211\subsection{The Waveform Dashboard (WaveDash)}
212\label{toolsdescription:wavedash}
213
214The Waveform Dashboard (WaveDash) is an interactive and configurable graphical user interface (GUI) tool that acts as a control panel for working with multiple SDR waveform applications and their components. This tool abstracts the SCA interfaces and the implementation of the OSSIE core framework. It provides a direct manipulation interface to control and configure SDR waveforms interactively. Users can install, start, stop and uninstall a waveform application, and also can configure the properties of its components in real time. Further, this tool allows the user to customize the interface on a per-waveform and per-component basis. Users can choose the type of widget they prefer to represent a particular property of a component and can also hide or unhide specific components or properties.
215
216\subsubsection{WaveDash Architecture}
217\label{toolsdescription:wavedasharchitecture}
218
219WaveDash was written using a Model-View-Controller (MVC) architecture. The model keeps track of the currently running waveforms along with waveforms on the system available to install. The controller maintains a connection with CORBA and the naming service and can query and configure components running on waveforms in real time. Finally, the view displays information from both the model and the controller. The WaveDash GUI front end was the first view written to work with the model and controller, but two others are currently under development. The first is a server to enable control of an OSSIE radio over http. The second is a command line interface to allow a user to control an OSSIE radio over an ssh session or via scripts. Both of these applications are simply alternative views that use the same model and controller as WaveDash. This allows them to easily connect to and manipulate an OSSIE Radio.
220
221\subsection{The ALF Waveform Application Visualization and Debugging Environment}
222\label{toolsdescription:alf}
223
224The initial ALF tool was contributed to the project by SAIC in 2007, and Virginia Tech has maintained and enhanced the tool since that time.  Implemented in Python, ALF interacts with a local or remote OSSIE Domain Manager via CORBA, and allows users to install, start, stop, and uninstall OSSIE waveforms, and to display the waveforms in block-diagram form.  ALF includes plug-in tools that can be used to inject signals into signal processing components and to monitor signals at various points in a waveform application, and users can develop their own plug-in tools using code from the supplied plug-ins as an example.  Additional features allow building ad-hoc applications from individual components at run time.
225
226\section{SDR Application Development Work FlowPart I:  Creating Components and Waveform Applications using the OSSIE Eclipse Feature}
227\label{sdrapplicationdevelopment-oef}
228
229
230
231
232
233\subsection{Creating a Component}
234\label{sdrapplicationdevelopment-oef:creatingcomponent}
235
236OEF helps developers to create signal processing components.  The developer specifies characteristics of the component such as ports and reconfigurable properties, and generates CORBA-enabled skeletal code for OSSIE.  The developer then provides or links to signal processing code that implements the desired functionality.  While more complex components can be developed using the same approach, the following example describes creation of a simple signal processing component, an amplifier that scales the incoming signal by a constant gain factor.
237%-------------------- FIGURE: GENERATING NEW COMPONENT --------------------
238\begin{figure}[ht]
239\centering
240%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
241\includegraphics[width=\textwidth]{figure2_oef_generating_new_component.pdf}
242% trim = left bottom right top
243\caption{Generating a new component in OEF}
244\label{fig:oef:generatenewcomponent}
245\end{figure}
246To create a signal processing component, the user first opens Eclipse and selects Window $\rightarrow$ Open Perspective $\rightarrow$ Other.  The user then chooses OSSIE from the list. This opens the OSSIE perspective, as shown in Fig. $\ref{fig:oef:emptyworkspace}$. Next, the user chooses File $\rightarrow$ New $\rightarrow$ OSSIE Component to open the New OSSIE Component Project wizard. The user then fills in the name for the project, in this case "amplifierIQ" and clicks on finish. This creates a new component project called amplifierIQ with a makefile and a .ocd file which is opened in the Component Editor (CE) as seen in Fig. $\ref{fig:oef:generatenewcomponent}$.
247The CE has the following four sections:
248\begin{enumerate}
249\item Description - for giving the component a textual description
250\item Generation Options - to specify what type of component to generate
251\item Ports - to specify the ports the component will have
252\item Properties - to specify which properties with component will have
253\end{enumerate}
254The user enters the following descriptions for the component, in this case, "Amplifier with independently adjustable gains for in- phase and quadrature signal components." Under generation options, the user selects basic\_ports from the template drop-down menu and leaves both ACE Support and Timing Port Support unchecked. Selecting basic\_ports will create a C++ component. The other options in the template drop-down, custom\_ports and py-comp, are for components that use an alternative set of interfaces and for python components, respectively. Checking ACE support would let the component use certain features of ACE $\cite{ACE}$ such as ACE threads, and checking Timing Port Support adds profiling support when using the custom ports or python component options.
255
256%-------------------- FIGURE: ADD PORT PORT DIALOG --------------------
257\begin{figure}[ht]
258\centering
259%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
261% trim = left bottom right top
264\end{figure}
265
268
269The next step is to add ports to the component. Ports allow components to communicate with one another. The user clicks on the Add button to bring up the Add Port dialog, as shown in Fig $\ref{fig:oef:addport}$. Next, the user enters "amp\_output" for the port name and selects. As defined by the SCA, a uses port is an output port while a provides port is an input port. Since this port will be an output port, the user selects uses from the type drop-down menu. To choose the type of interface, the user clicks the arrow next to Standard Interfaces and selects complexShort from the choices that appear. Finally, the user clicks ok and sees the new port in the Ports table. All three fields in the Ports table are editable in place, so the user can change the name, interface, or type of any port after it has been added. Selecting any port and clicking the Remove button will delete the port from the component. This component also requires an input port called amp\_input that is also a complexShort, so the user adds another port using the same process
270
271%-------------------- FIGURE: ADD PROPERTY DIALOG --------------------
272\begin{figure}[ht]
273\centering
274%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
276% trim = left bottom right top
279\end{figure}
280
283
284The final step to configure a component is to add any reconfigurable properties it will need. Our amplifier needs two properties: I\_gain and Q\_gain, which multiply in-phase and quadrature components of the signal, respectively. The user clicks the Add button in the Properties section of the CE to bring up the Add Property dialog as shown in Fig. $\ref{fig:oef:addproperty}$. The user enters "I\_gain" for the name and 1 for the value. The rest of the attributes are left as the defaults, so the user clicks Add Property. The process is repeated for a Q\_gain property.
285
286%-------------------- FIGURE: GENERATED PROJECT --------------------
287\begin{figure}[ht]
288\centering
289%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
290\includegraphics[width=\textwidth]{figure5_oef_newly_generated_component_project.pdf}
291% trim = left bottom right top
292\caption{Newly generated component project in OEF}
293\label{fig:oef:generatedproject}
294\end{figure}
295
296\subsection{Generating Skeleton Implementation}
297\label{sdrapplicationdevelopment-oef:skeletonimplementation}
298
299        At this point, all of the configuration for the component is complete.  The next step is to generate the XML descriptors and skeleton implementation files. The user selects Generate Component from the OSSIE menu to start the generation. OEF will run the necessary make commands and show the output in the console view. After generation is complete, the new files will appear in the project explorer, as seen in Fig. $\ref{fig:oef:generatedproject}$.
300
301
302%-------------------- FIGURE: EDITING CODE IN OEF --------------------
303\begin{figure}[ht]
304\centering
305%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
306\includegraphics[width=\textwidth]{figure6_oef_editing_code.pdf}
307% trim = left bottom right top
308\caption{Editing code in OEF}
309\label{fig:oef:editingcode}
310\end{figure}
311
312
313\subsection{Filling in Implementation Code}
314\label{sdrapplicationdevelopment-oef:implementation}
315
316Once the component has been generated, the user has to fill in the skeleton with implementation code. The user double-clicks on amplifierIQ.cpp in the Project Explorer to open the file in a C++ editor as shown in Fig $\ref{fig:oef:editingcode}$. After filling in the custom implementation that operates on the input signal using the specified property (gain) values, and sends the processed signal to the output port, he saves the file. As long as there are no errors, OEF automatically builds and installs the component to the filesystem.
317
318%-------------------- FIGURE: OEF WAVEFORM EDITOR --------------------
319\begin{figure}[ht]
320\centering
321%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
322\includegraphics[width=\textwidth]{figure7_oef_waveform_editor.pdf}
323% trim = left bottom right top
324\caption{Waveform editor}
325\label{fig:oef:waveformeditor}
326\end{figure}
327
328%-------------------- FIGURE: PORTS ON COMPONENTS --------------------
329\begin{figure}[ht]
330\centering
331%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
332% trim = left bottom right top
333\caption{Ports on Components}
334\label{fig:oef:portsoncomponents}
335\end{figure}
336
337\subsection{Creating and Configuring a Waveform}
338\label{sdrapplicationdevelopment-oef:waveform}
339Now that the user has successfully created and built a component, that component can be used in a new waveform. The example waveform will be a simulated QPSK communications link that runs entirely on a single computer, but essentially the same approach is used to develop a radio communication waveform application that interfaces with RF hardware.  To get started, the user selects File $\rightarrow$ New $\rightarrow$ OSSIE Waveform to open the New OSSIE Waveform Project wizard. The user names the project SimpleWaveform and clicks on Finish. When the wizard finishes, the user is presented with the main Waveform Editor (WE), as seen in Fig $\ref{fig:oef:waveformeditor}$. The WE contains 3 main trees:
340\begin{enumerate}
341\item Available Resources - lists all of the components, devices, and nodes currently installed on the system and available for use
342\item Waveform - shows all of the components to be used in the current waveform
343\item Platform - shows the processing and input/output devices and nodes (collections of devices) and components allocated to each processing device in the current waveform.
344\end{enumerate}
345
346Note that the component that the user just built, amplifierIQ, is listed under components in the Available Resources tree. To begin assembling the waveform, the user drags the TxDemo, amplifierIQ, ChannelDemo, and RxDemo components he will be using to the Waveform tree. The user then drags a default\_GPP\_node (which corresponds to a set of XML files for a Device Manager that manages a single x86 GPP) from nodes in the Available Resources tree to the Platform tree. The components are not yet allocated to any nodes, so the user expands default\_GPP\_node to show the device on it, GPP1. To allocate the components to this device, the user drags each component from the Waveform tree to GPP1 in the Platform tree. When a component is allocated to GPP1, the component appears under the GPP1 in the Platform tree, and the label on the component in the Waveform tree also changes to reflect where it has been allocated.
347
348Next, the user has to connect the ports on the components to one another. The user expands each component in the Waveform tree to show their ports, as seen in Fig. $\ref{fig:oef:portsoncomponents}$. To connect the ports, the user drags a uses port (orange puzzle piece) on top of a provides port (blue puzzle piece). Each port then changes to a combined puzzle piece and its label changes to show which port it is connected to. Once all of the ports have been connected, the final step is to choose an Assembly Controller. To do so, the user right clicks on TxDemo1 in the Waveform tree and chooses Set Assembly Controller.  Once this is done, the waveform is fully configured and ready to be generated. The user saves the project and OEF automatically generates all of the necessary XML descriptors for the waveform and installs them to the filesystem.
349
350%-------------------- FIGURE: WAVEDASH - INSTALL A WAVEFORM APPLICATION --------------------
351\begin{figure}[ht]
352\centering
353%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
355% trim = left bottom right top
356\caption{Installing a waveform application using WaveDash}
357\label{fig:wavedash:install}
358\end{figure}
359
360\section{SDR Application Development Work Flow Part 2:  Configuring and Controlling Waveform Applications using the Waveform Dashboard}
361\label{sdrapplicationdevelopment-wavedash}
362
363WaveDash allows users to control and configure waveform applications in real time.  WaveDash can be used to install/uninstall and configure component properties of the waveform application that was developed in OEF in Section $\ref{sdrapplicationdevelopment-oef:waveform}$. The Waveforms menu in WaveDash lists the currently available waveforms on the system. The user pulls down the menu and selects 'SimpleWaveform' that was just created (Fig $\ref{fig:wavedash:install}$). The sub-menu allows the user to either install a new application instance of the waveform or to preview the component and their properties present in the waveform. The user clicks on Install to install a new instance of SimpleWaveform. WaveDash displays the waveform applications in a tabbed fashion to allow users to work with multiple waveforms at one time. New waveform application tabs are appended to the right of the most recently installed waveform application.
364
365\subsection{Install a new waveform application}
366\label{sdrapplicationdevelopment-wavedash:installingwaveformapplication}
367
368The WaveDash toolbar provides controls to start, stop or uninstall the waveform application denoted by the active tab.  The user has to click on the appropriate buttons on the toolbar to start, stop or uninstall a waveform application.
369
370%-------------------- FIGURE: WAVEDASH - SELECT AND DESELECT COMPONENTS --------------------
371\begin{figure}[ht]
372\centering
373%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
375% trim = left bottom right top
376\caption{Select/Deselect Components in WaveDash}
377\label{fig:wavedash:selectdeselectcomponents}
378\end{figure}
379
380\subsection{Show/Hide Components}
381\label{sdrapplicationdevelopment-wavedash:showhidecomponents}
382
383        The Component menu lists the components present in the waveform application denoted by the active tab. The user deselects the component RxDemo from the Component menu (Fig. $\ref{fig:wavedash:selectdeselectcomponents}$) to hide it as it does not have any properties to configure. This feature is particularly useful when the waveform comprises a large number of components and only few of them are required to be configured often.
384
385\subsection{Configure Component Properties of a Waveform}
386\label{sdrapplicationdevelopment-wavedash:configurecomponentproperties}
387
388The ability to configure component properties at runtime was urgently needed and was one of the prime motivations to develop WaveDash. Prior to development of WaveDash, OSSIE users had to either modify property values in OEF and rebuild the waveform or hand-edit the property values in the component or waveform XML files and restart the waveform to configure the component property values.
389
390WaveDash enables users to modify component properties at runtime thus making SDR waveform development more live and interactive.  Each property has a GUI widget (e.g. text box, slider) associated with by default based on its data type (e.g. integer, string). The user can change the value of a component property by changing the value of the widget. By default, the property will be updated immediately after the user presses TAB or ENTER. Changes can be immediately seen with the ALF Plot tool (see Section $\ref{sdrapplicationdevelopment-alf:relationwithwavedash}$). In this example, the user changes the value of noise\_std\_dev of ChannelDemo from default value of 1000 to a 1500 and presses ENTER for the change to take effect.
391
392While the user will normally want component properties to update immediately once the value of the widget has changed, there are times where it is better to be able to change multiple property values and have them all update simultaneously. Wavedash makes this easy to do. Under the Options menu, the user can select 'Update Properties on Refresh'. This will enable the refresh buttons on each component and the waveform, as shown in figure~\ref{fig:wavedash_update_properties_on_refresh}. When used this way, WaveDash only updates the component property values when one of the refresh buttons is clicked. Clicking the refresh button for a single component updates only that component's properties. Clicking the refresh button at the bottom updates all properties on all components in the waveform.
393
394%-------------------- FIGURE: WAVEDASH - Update on Refresh --------------------
395\begin{figure}[ht]
396\centering
397%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
398\includegraphics[width=8.5cm]{figure13_wavedash_update_properties_on_refresh.png}
399% trim = left bottom right top
400\caption{WaveDash with Update Properties on Refresh enabled}
401\label{fig:wavedash_update_properties_on_refresh}
402\end{figure}
403
404
405
406%-------------------- FIGURE: WAVEDASH - CHANGE PROPERTY CONTROL WIDGETS --------------------
407\begin{figure}[ht]
408\centering
409%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
411% trim = left bottom right top
412\caption{Change property control widgets in WaveDash}
413\label{fig:wavedash:changepropertywidgets}
414\end{figure}
415
416\subsection{Change Property Configuration Control Widgets}
417\label{sdrapplicationdevelopment-wavedash:configurewidgets}
418
419       The component PRF files determine the data type for each property of the component. WaveDash does a default mapping of data type (mentioned in PRF files) to a GUI widget (control) and also provides an optional list of widgets which users can customize to their preferences. In this example, packet\_delay\_ms of TxDemo is mapped to a spin box by default. User right clicks on the spin box that brings a context menu with the list of optional widgets configurable for packet\_delay. The user selects slider (Fig $\ref{fig:wavedash:changepropertywidgets}$) and that changes the widget on the application GUI also. The configure option in the context menu is used to set minimum and maximum values for spin box and slider controls.
420
421%-------------------- FIGURE: WAVEDASH - SELECT/DESELECT COMPONENT PROPERTIES --------------------
422\begin{figure}[ht]
423\centering
424%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
426% trim = left bottom right top
427\caption{Change property control widgets in WaveDash}
428\label{fig:wavedash:selectdeselectproperties}
429\end{figure}
430
431\subsection{Show/Hide Component Properties}
432\label{sdrapplicationdevelopment-wavedash:showhidecomponentproperties}
433
434       It is highly possible that a component may have so many properties that it is not convenient to display all of the properties at the same time. Users may wish to hide unwanted properties and keep only the frequently used properties on screen. In this example (Fig $\ref{fig:wavedash:selectdeselectproperties}$), the user right clicks on a component and deselects phase\_offset from the pop-up menu.
435
436%-------------------- FIGURE: ALF - BLOCK DIAGRAM WITH PLUG-IN MENU --------------------
437\begin{figure}[ht]
438\centering
439%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
441% trim = left bottom right top
442\caption{ALF tool showing SimpleWaveform block diagram and plug-in tool menu}
444\end{figure}
445
446\section{SDR Application Development Work Flow Part III:  Use of ALF Waveform Application Visualization and Debugging Environment}
447\label{sdrapplicationdevelopment-alf}
448
449The ALF environment provides several capabilities that are helpful for troubleshooting and debugging waveform applications.  Like WaveDash, ALF allows users to install/uninstall and start/stop waveform applications.  ALF also lets users display running applications in block diagram form as shown in Fig. $\ref{fig:alf:block_diagram_plugin_menu}$, and inject and monitor signals at various component ports in the application using provided or user-developed plug-in tools by right clicking on the port (small rectangle on either side of the component) and selecting from a menu as shwon in Fig. $\ref{fig:alf:block_diagram_plugin_menu}$.  Additional features enable creation and installation of single-component waveform applications, and connections between ports on components in the same or different waveforms at run time.
450
451\subsection {ALF Plug-In Tools}
452\label{sdrapplicationdevelopment-alf:plugins}
453
454Several plug-in tools for ALF are provided as part of the OSSIE distribution.  These tools are used to inject signals into component provides ports, and to display, record, or otherwise process the signals coming out of component uses ports.  The plugins are implemented in Python, and users can modify the plug-ins or develop their own based on those provided.
455
456%-------------------- FIGURE: ALF - SPEAKER TOOL --------------------
457\begin{figure}[ht]
458\centering
459%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
460\includegraphics[width=\textwidth]{figure14_ALF_Speaker_Tool.pdf}
461% trim = left bottom right top
462\caption{The ALF Speaker tool}
463\label{fig:alf:plugins:speaker}
464\end{figure}
465
466\subsubsection{Speaker Tool}
467\label{sdrapplicationdevelopment-alf:plugins:soundtool}
468
469The speaker tool, shown in Fig. $\ref{fig:alf:plugins:speaker}$, accepts signals in OSSIE's complexShort (2-channel, short integer) interface format and plays the signals through a computer's sound card.  It allows the user to set the sampling rate at which the signal will be converted to audio.
470
471%-------------------- FIGURE: ALF - PLOT TOOL --------------------
472\begin{figure}[ht]
473\centering
474%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
475\includegraphics[width=8.5cm]{figure15_ALF_Plot_Tool_QPSK.pdf}
476% trim = left bottom right top
477\caption{The ALF Plot tool displaying a quadrature phase-shift keying (QPSK) signal constellation}
478\label{fig:alf:plugins:plot}
479\end{figure}
480
481\subsubsection{Plot Tool}
482\label{sdrapplicationdevelopment-alf:plugins:plottool}
483
484The plot tool (Fig. $\ref{fig:alf:plugins:plot}$) also accepts signals from uses ports that employ the complexShort interface.  This tool displays the signal's spectrum on a normalized frequency scale or displays the quadrature vs. in-phase components of the signal in order to render the constellations of received digital signals.  In this mode, several symbols are shown that under ideal conditions would typically map to regularly spaced points, e.g. in a circle (phase-shift keying) or in a grid pattern (quadrature amplitude modulation).  In a realistic simulation or an operational radio, the symbols appear scattered about the nominal symbol points due to noise, fading, imperfect synchronization, or other anomolies.
485
486
487%-------------------- FIGURE: ALF - AWG TOOL --------------------
488\begin{figure}[ht]
489\centering
490%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
491\includegraphics[width=8.5cm]{figure17_ALF_AWG_Tool.pdf}
492% trim = left bottom right top
493\caption{The ALF AWG tool}
494\label{fig:alf:plugins:awg}
495\end{figure}
496
497\subsubsection{Arbitrary Waveform Generator (AWG) Tool}
498\label{sdrapplicationdevelopment-alf:plugins:AWGtool}
499
500Using this tool, shown in Fig. $\ref{fig:alf:plugins:awg}$, users can select from among available signal functions, or read signals that are stored in data files.  This allows generation of signals off-line using software such as MATLAB or replaying signals that are captured over the air.
501
502\subsection{Launching Individual Components as Waveform Applications}
503\label{sdrapplicationdevelopment-alf:compform}
504
505ALF includes a "compform" capability that packages individual components as self-contained waveform applications and deploys them to the default GPP device.  This is accessed by clicking on a component in the middle left panel of ALF (see Fig. $\ref{fig:alf:block_diagram_plugin_menu}$).  The compform feature allows a user to test individual components by using the plug-in tools to inject and monitor signals into and out of each component as the component runs in a stand-alone application.
506
507%-------------------- FIGURE: ALF - CONNECT TOOL --------------------
508\begin{figure}[ht]
509\centering
510%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
511\includegraphics[width=8.5cm]{figure18_ALF_Connect_Tool_2.pdf}
512% trim = left bottom right top
513\caption{ALF Connect Tool}
514\label{fig:alf:connect}
515\end{figure}
516
517\subsection{Connect Tool}
518\label{sdrapplicationdevelopment-alf:connecttool}
519
520The Connect Tool, shown in Fig. $\ref{fig:alf:connect}$, provides the capability to connect ports on components that are in the same or different waveform applications.  This capability, provided with the ability to create and run single-component applications, allows users to build ad-hoc applications by launching components as waveforms and connecting them at run time to form a temporary, larger composite application.  The composite application can be configured by configuring properties of its constituent applications using the WaveDash tool.  Further, the Connect Tool provides for automatic instantiation and tear-down of applications, and automated connections and routing of data among standard applications, single-component applications, and plug-in tools, by specifying the applications/components/plug-ins and behavior in an XML file.  This enables dynamic reconfiguration of SDR applications at run time, a capability that can be very useful in cognitive radio implementations $\cite{Cormier2009}$.
521
522%-------------------- FIGURE: ALF AND WAVEDASH --------------------
523\begin{figure}[ht]
524\centering
525%\includegraphics[trim = 10mm 130mm 50mm 20mm, clip, width=10cm]{figure1.pdf}
526\includegraphics[width=\textwidth]{figure19_ALF_QPSK_Controlled_Wavedash.pdf}
527% trim = left bottom right top
528\caption{ALF and WaveDash used together to monitor and control a waveform}
529\label{fig:alf:alfwavedash}
530\end{figure}
531
532\subsection{Relation of ALF with WaveDash}
533\label{sdrapplicationdevelopment-alf:relationwithwavedash}
534
535When used together, ALF and WaveDash allow the user to observe effects of parameter values on waveform operation interactively and in real time, as shown in Fig. $\ref{fig:alf:alfwavedash}$.  This is very useful for education, experimentation, and debugging of waveform applications.  ALF currently provides some of the same functionality as WaveDash, specifically the ability to install/uninstall and start/stop applications.  This functionality is included in both tools so that WaveDash can be used to run applications without the full ALF environment.  WaveDash can be launched from within ALF, and further integration is planned.  Planned changes include encapsulating all common functionality of the two tools in a python module or library.
536
537\section{User Base}
538\label{userbase}
539The OSSIE software, including the Waveform Workshop, is a widely used and distributed software package. There have been over 20,000 downloads of the OSSIE source code, ready-to-run live DVDs, and VMware images. We have confirmed that students and engineers at over 20 different universities, companies, nonprofit research centers, and government laboratories have used OSSIE. In addition, over US\$3 million in funding for OSSIE projects has supported over 20 graduate and undergraduate students, and more than 10 graduate theses at Virginia Tech, the Naval Postgraduate School, and elsewhere have used the software. OSSIE has served as the basis for three peer-reviewed journal articles, four online articles, and more than 20 conference papers, along with approximately 10 short courses and tutorials serving over 200 participants. 540 541\section{Future Work} 542\label{futurework} 543 544The current state of the tools allows for the work flow shown in the preceding sections, and also allows applications such as SimpleWaveform to be prototyped as ad-hoc applications and then recreated in OEF. Additional development of the tools will enhance this capability by providing the option to display multiple application block diagrams in the same window, make connections by dragging lines between component ports, and formalize ad-hoc applications by saving connection and deployment information in waveform XML files. 545 546Additional developments to the OSSIE tools are planned as part of current and pending projects. These include the following tasks: 547\begin{itemize} 548\item Integrate ALF and WaveDash capabilities into Eclipse 549 550\item Enable interactive block-diagram based waveform development 551 552\item Move to full Java implementations of the tools 553 554\item Load waveform and component descriptions by parsing the SCA XML files rather than using dedicated file formats (.ocd and .owd) 555 556\item Add features for collaborative development 557 558\item Add model-based development capability for greater flexibility 559 560\item Provide HTTP and command line interfaces to the OSSIE backend 561\end{itemize} 562\section{Conclusion} 563\label{conclusion} 564 565This paper has described a set of open source SCA-based SDR development tools suitable for education, research, and rapid prototyping. These tools hide some of the complexity of the SCA while exploiting the features provided by the SCA to enable an interactive development process. The development process includes creation of signal processing comoponents and waveform applications as well as execution, visualization, monitoring, testing, and run time reconfiguration of waveform applications. 566 567\section{Acknowledgements} 568\label{acknowledgements} 569 570This work was supported by the National Science Foundation under Grant No. 0520418, by Science Applications International Corporation, and by U.S. ARMY CERDEC. 571 572%% The Appendices part is started with the command \appendix; 573%% appendix sections are then done as normal sections 574%% \appendix 575 576%% \section{} 577%% \label{} 578 579\begin{thebibliography}{00} 580 581%% \bibitem{label} 582%% Text of bibliographic item 583 584\bibitem{Aguayo2009b} 585C. R. Aguayo Gonz$\acute{a}$lez, et al., Open\-Source SCA\-Based Core Framework and Rapid Development Tools Enable Software\-Defined Radio Education and Research, IEEE Communications Magazine, vol 47, no. 10, October 2009. 586 587\bibitem{ossieweb} 588OSSIE project web site. \\Available: http://www.ossie.wireless.vt.edu 589 590\bibitem{sca} 591Software Communications Architecture Specification, 2nd ed., Joint Tactical Radio System (JTRS) Joint Program Office, April 2004. 592 593\bibitem{bard} 594J. Bard and V.J. Kovarik Jr., Software Defined Radio: The Software Communications Architecture, Wiley, Chichester, West Sussex, England, 2007. 595 596\bibitem{Aguayo2009a} 597C. R. Aguayo Gonz$\acute{a}$lez , C. B. Dietrich, and J. H. Reed, Understanding the software communications architecture, IEEE Communications Magazine, vol. 47, no. 9, September 2009. 598 599 600\bibitem{Reed2002} 601J.H. Reed, Software radio: a modern approach to radio engineering, Prentice Hall PTR, 2002. 602 603\bibitem{Vanu} 604Vanu$^{\textregistered}$Introduces the Anywave$^{\textregistered}\$ MultiRAN - Wireless Industry's First Software Radio Shared Active Infrastructure Solution, \\Available:  http://www.vanu.com/media/Web%20Site%20Press%20Releases/vanu-multiran-final.pdf
605
606\bibitem{JTRS}
607JPEO JTRS, Joint Tactical Radio System\\
608Available: http://jpeojtrs.mil
609
610\bibitem{Gamma}
611E. Gamma, R. Helm, R. Johnson, J.M. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1994.
612
613\bibitem{POSIX}
614IEEE Std 1003.1, 2004 Edition\\
615Available: http://www.unix.org/version3/ieee\_std.html
616
617\bibitem{CORBA}
618OMG's CORBA website\\
619Available:  http://www.corba.org
620
621\bibitem{XML}
622Extensible Markup Language (XML) 1.1 (Second Edition)\\
623Available:  http://www.w3.org/TR/2006/REC-xml11-20060816/
624
625\bibitem{Robert2004}
626M. Robert, et al., "OSSIE: Open Source SCA for Researchers,"' SDR Forum Technical Conference, 2004.
627
628\bibitem{SpectraCX}
629PrismTech and Zeligsoft partner to deliver Spectra CX - a third-generation modeling tool for Software-Defined Radio (SDR/SCA) developers\\
630Available:  http://www.mil-embedded.com/news/Technology+Partnerships/18395
631
632\bibitem{ACE}