richard taylor uci eric dashofy uci haig f krikorian boeing michael j marich boeing l.
Skip this Video
Download Presentation
Richard Taylor (UCI) Eric Dashofy (UCI) Haig F. Krikorian (Boeing) Michael J. Marich (Boeing)

Loading in 2 Seconds...

play fullscreen
1 / 19

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

  • 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

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

PowerPoint Slideshow about 'Richard Taylor (UCI) Eric Dashofy (UCI) Haig F. Krikorian (Boeing) Michael J. Marich (Boeing)' - arleen

Download Now 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

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)

  • 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
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
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
  • 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
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:
sdr as a problem domain
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
Network Level
  • Dynamic, varying configurations of vehicles and personnel carrying SDRs
unit level
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


Unit-level Hardware Configuration

board level


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








software level
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




Crypto Alg 1

Red Side GPP





our approach
Our approach



xADL 2.0ArchitectureDescriptions


xADL 2.0


  • 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
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

** Software Communications Architecture Reference Implementation:

lessons learned
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
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
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
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