Richard taylor uci eric dashofy uci haig f krikorian boeing michael j marich boeing l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 19

Richard Taylor (UCI) Eric Dashofy (UCI) Haig F. Krikorian (Boeing) Michael J. Marich (Boeing) PowerPoint PPT Presentation


  • 332 Views
  • Uploaded on
  • Presentation posted in: Industry

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

Download Presentation

Richard Taylor (UCI) Eric Dashofy (UCI) Haig F. Krikorian (Boeing) Michael J. Marich (Boeing)

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


  • Login