1. 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)

2. 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

3. 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

4. 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

5. 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

6. 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

8. 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

9. Network Level • Dynamic, varying configurations of vehicles and personnel carrying SDRs

10. 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

11. 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

12. 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

13. 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

15. 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/

16. 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)

17. 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)

18. 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

19. 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