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:

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 factor Backplane SBC / 1 Channel

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 FPGA Black Side GPP Crypto Red Side GPP Audio Control

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 Proc1Proc2 Crypto Alg 1 Audio Proc Video Proc METAC Proc Packet Proc

Our approach SDR Deployment Descriptor XMLs xADL 2.0 Architecture Descriptions 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.0 Data Binding Library 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 ** Software Communications Architecture Reference Implementation:

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