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

• 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

• 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

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

• 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

• Dynamic, varying configurations of vehicles and personnel carrying SDRs

Unit Level

Unit-level Hardware Configuration

• Varying unit-level hardware configurations– Multi-unit, 4 boards-per-

unit, redundant, large form factor

– Single unit, 2 boards, small form factorBackplane

SB

C /

1 C

hannel

SB

C /

1 C

hannel

SB

C /

1 C

hannel

SB

C /

1 C

hannel

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

DSP

FPGABlackSideGPP

Crypto

RedSideGPP

AudioControl

Software Level

• 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

Black Side GPP

Crypto

Red Side GPP

Proc1 Proc2

Crypto Alg 1

AudioProc

VideoProc METAC

Proc

PacketProc

Our approach

SDRDeploymentDescriptor

XMLs

xADL 2.0ArchitectureDescriptions

• 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

xADL 2.0Data

BindingLibrary

Translator

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

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

• 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

• 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