Richard taylor uci eric dashofy uci haig f krikorian boeing michael j marich boeing
Download
1 / 19

Joint Research: UCI ISR-Boeing Anaheim Engineering - PowerPoint PPT Presentation


  • 388 Views
  • Uploaded on

Joint Research: UCI ISR-Boeing Anaheim Engineering Software Architecture-Based Development of Product Lines for the Software-Defined Radio Domain. Richard Taylor (UCI) Eric Dashofy (UCI) Haig F. Krikorian (Boeing) Michael J. Marich (Boeing). Topics. Overview

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Joint Research: UCI ISR-Boeing Anaheim Engineering' - arleen


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Richard taylor uci eric dashofy uci haig f krikorian boeing michael j marich boeing l.jpg

Joint Research: UCI ISR-Boeing Anaheim EngineeringSoftware Architecture-Based Development of Product Lines for the Software-Defined Radio Domain

Richard Taylor (UCI)

Eric Dashofy (UCI)

Haig F. Krikorian (Boeing)

Michael J. Marich (Boeing)


Topics l.jpg
Topics

  • Overview

    • What is this joint research project all about?

    • Who is doing it?

    • Why are we doing it?

  • Software Defined Radio Background

  • Experience

    • What are we doing?

    • What are our goals/plans for the future?

  • Lessons Learned


Joint research project l.jpg
Joint Research Project

  • What is UCI’s role in this project?

    • Development/maturation of an architecture description language (ADL) and environment to capture product line variants

  • What is Boeing’s role in this project?

    • To determine if an ADL and its environment adds value to the development of a Software Defined Radio (SDR) architecture and its variants


Research participants l.jpg
Research Participants

  • UCI Team:

    • Richard Taylor – Principal Investigator

    • Research Associates (led by Eric Dashofy)

  • Boeing Team:

    • Peter Heckman – Project Manager

    • Haig F. Krikorian – Associate Technical Fellow

    • Michael J. Marich – Software Systems Engineer


Background l.jpg
Background

  • ADLs funded by DARPA (circa 1996) attracted attention as a way to capture and show consistency across software systems

  • ADL advances included the ability to enforce h/w and s/w cross-component typing

  • Recent ADL advances attracted attention as a way to define, develop, and generate product lines architectures and variants


Software defined radio l.jpg
Software Defined Radio*

  • Software Defined Radio is a collection of hardware and software technologies that enable reconfigurable system architectures for wireless networks and user terminals.

  • SDR provides an efficient and comparatively inexpensive solution to the problem of building multi-band, multifunctional wireless devices that can be adapted, updated, or enhanced by using software upgrades.

  • Radios built using SDR concepts can allow standard, open, and flexible architectures for a wide range of communications products.

  • The information provided on this page is taken from the open source, public domain: http://www.sdrforum.org/sitemap.html


Sdr as a problem domain l.jpg
SDR as a Problem Domain

  • Software Defined Radios are radio devices that can be software-configured to perform many different tasks (“waveforms”), e.g.:

    • Video over VHF (Television)

    • Audio over FM (In-your-car radio)

    • VoIP over Wideband Network Waveform

  • SDR is a system-of-systems with many levels, each of which contains different kinds of variation

  • Architecture can provide value at each of these levels


Network level l.jpg
Network Level

  • Dynamic, varying configurations of vehicles and personnel carrying SDRs


Unit level l.jpg
Unit Level

  • Varying unit-level hardware configurations

    • Multi-unit, 4 boards-per-unit, redundant, large form factor

    • Single unit, 2 boards, small form factor

SBC / 1 Channel

SBC / 1 Channel

SBC / 1 Channel

SBC / 1 Channel

Backplane

Unit-level Hardware Configuration


Board level l.jpg

Crypto

Board Level

  • Varying board-level hardware configurations

    • Number of processors, speed/capability of each, red-side/black-side

    • Other resources: RAM, cache, etc.

SBC / 1 Channel

BlackSide

GPP

FPGA

DSP

RedSide

GPP

AudioControl


Software level l.jpg
Software Level

Black Side GPP

  • Varying software configurations

    • Waveforms define set of components and capabilities

      • With many potential deployments depending on board/hardware config

    • Many waveforms deployed on unit/hardware configs

    • Logical connections over physical connections

Proc1

Proc2

Crypto

Crypto Alg 1

Red Side GPP

PacketProc

AudioProc

VideoProc

METACProc


Our approach l.jpg
Our approach

SDRDeploymentDescriptor

XMLs

xADL 2.0ArchitectureDescriptions

Translator

xADL 2.0

DataBindingLibrary

  • Translate deployment descriptors to xADL 2.0

  • Extend translated models with new data using additional xADL 2.0 schemas

  • Apply xADL 2.0 tools to translated descriptors


Joint research experience l.jpg
Joint Research Experience

  • 2003: Developed a teaming relationship between UCI and Boeing

  • 2004: Applied UCI ArchStudio* and xADL to the Open Source SCARI** SDR Architecture

    • Identified architecture holes & inconsistencies

    • Captured complex hierarchical dependencies

    • Plans to generate initial product line variants

  • www.isr.uci.edu/projects/archstudio/

    ** Software Communications Architecture Reference Implementation: http://www.crc.ca/scari/


Lessons learned l.jpg
Lessons Learned

  • Partnership Lessons

    • Pushed research partner from software architecture to system architecture

    • Research partner responsiveness to questions and comments

    • Industry partner exposed to product family architecture capture and variant generation

  • Product Lessons

    • Leap to new technology (cost/benefit analysis)

    • Integrating technology with current process/procedures and tool sets

    • Product engineering (migration from research tool to industry use)


Lessons learned17 l.jpg
Lessons Learned

  • Domain

    • SCARI model maturity prior to public release

    • “build me a consistent product variant”

    • “build me a broken product” (ad hoc, adaptable architecture)

    • Better (different) way to express deployment views (software and hardware configurations)


2005 research focus l.jpg
2005 Research Focus

  • ArchStudio refinement:

    • Usability, learn-ability, productivity

    • Better depict product line variants

  • xADL refinement:

    • Capture heterogeneous architecture/styles

  • Architecture definition process development:

    • Augments the current UML tools to include an ADL for architecture capture and refinement


Future directions l.jpg
Future Directions

  • ArchStudio / xADL refinements to:

    • Capture the multi-dimensional hardware and software relationships in dynamic, ad-hoc system architectures and their variants

    • Improve the representation of system deployment views of hierarchical assembly architectures

  • Track other (e.g., π-ADL) progress:

    • Identify potential xADL advancements

    • Identify architecture definition process improvements


ad