1 / 19

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

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

arleen
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

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

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

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

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

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

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

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

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

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

More Related