• Like
SCA Next Part 1 - Software Defined Radio (SDR) Webcast Slides
Upcoming SlideShare
Loading in...5
×

SCA Next Part 1 - Software Defined Radio (SDR) Webcast Slides

  • 1,888 views
Uploaded on

SCA To Date and Motivation for Change. These slides will discuss why the JTRS Program Executive Office (JPEO) is aggressively procuring Software Defined Radio (SDR) consortium and industry assistance …

SCA To Date and Motivation for Change. These slides will discuss why the JTRS Program Executive Office (JPEO) is aggressively procuring Software Defined Radio (SDR) consortium and industry assistance to spearhead a high impact evolution of the Software Communications Architecture (SCA) intended to deliver better radio performance along with a smaller footprint for waveforms and radio software. The webcast audience will learn about innovative SCA change proposal details and identified opportunities for near term radio performance impact with rapid market availability of these new capabilities via highly motivated COTS SDR software and development tool vendors.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,888
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
59
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)
  • Chronicles of Narnia – Can only see to the beginning of time – See before time. Rumbaugh/Booch – Origins of OO date back to late 60’s Simula and mid 80’s Smalltalk OMG formed to develop standard for distributed applications – CORBA (Common Object Request Broker)

Transcript

  • 1. The Evolution of the SCA SCA Next November 10, 2010
  • 2. Outline
    • Personal Introduction
    • Objectives
    • Background and History
    • SCA Next Overview
    • Overview of SCA Next Changes
    • Summary
    • PrismTech Products
    • References and Resources
    • Contact Information
  • 3. Vince Kovarik
    • Academic and Publications:
      • B.S & M.S. Computer Science, Ph.D. Computer Engineering
      • Co-author with John Bard “Software Defined Radio: The Software Communications Architecture”, Wiley and Sons
      • Chapter author for “Cognitive Radio Technology”, by Dr. Bruce Fette
      • Awarded three patents
    • 1980s: Harris and Software Productivity Solutions
      • Experience in Natural Language Understanding, Knowledge Representation and Acquisition and Temporal Reasoning.
      • Initial OO design with Rumbaugh OMT, Booch OOD, and Jacobsen Use Cases.
      • Development work in Smalltalk, LISP Flavors, and C/C++
    • 1990s: STI/Exigent
      • Initial CORBA work as Chief SW Architect for the Ground Segment of Satellite Command and Control System for IRIDIUM, a large-scale distributed system.
      • Started work in SDR in late 90’s as a member of the MSRC.
      • Domain Management ToolKit (dmTK) product manager, the first commercially available implementation of the SCA.
    • 2001: Harris purchases Exigent
      • dmTK used as initial reference implementation by JTeL and Aeronix for JTAP development.
      • SW Architect for the insertion of the DARPA XG DSA software into the Falcon III Tactical Radio and demonstration.
      • Member of the Government Reference Architecture (GRA) team developing a SysML/UML reference model for SATCOM terminal systems.
    • Member of the SDR Forum  Wireless Innovation Forum since 2000.
      • Currently chair of the Technical Committee on Advanced Wireless Networking and Infrastructure.
  • 4. Objectives
    • This is the first of a series of technology-oriented presentations on the SCA and SDR.
    • The objective of this presentation is to provide:
      • a historical overview of the SCA and
      • an overview of the SCA Next initiative
    • Presentations on PrismTech’s products in support of the SCA Next and other technology topics will be forthcoming.
  • 5. Background
    • Despite rumors of its demise, SCA is alive and well.
    • SCA has been applied successfully to a variety of radio systems including:
      • JTRS programs of record
      • International radio systems
      • Independently developed products
    • The international community has been moving forward with SCA, e.g. ESSOR and other programs.
  • 6. However…
    • The successes have not been without some problems.
      • Limited portability of waveforms
      • Inadequate abstraction of DSP and FPGA
      • Non-standard Device interfaces for common radio devices, e.g. AudioPort
      • Footprint and performance
  • 7. A (partial) SCA/SDR History Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and NCOSE SCA 2.2.1 ??? 1990 2000 2010
  • 8. A (partial) SCA/SDR History – Enablers Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and NCOSE SCA 2.2.1 ??? Early SDR work. Early OO Modeling and Design Methodologies. Enabling standards and organizations. 1990 2000 2010
  • 9. A (partial) SCA/SDR History – Critical Mass Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and NCOSE SCA 2.2.1 ??? Modular Software Radio Consortium: Circa late 1990s Initial origins of the SCA Early work on waveform and OO SDR architectures and design. Stable design formalism. 1990 2000 2010
  • 10. A (partial) SCA/SDR History – Initial Projects Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and INCOSE SCA 2.2.1 ??? Circa 2002 JTRS Program initial award of Cluster 1 – Ground Mobile Radios (GMR) Stable release of SCA released in November 2001 Development of Meta-Object Facility Collaboration initiated with International Council on Systems Engineering to develop Systems Modeling Language (SysML) 1990 2000 2010
  • 11. A (partial) SCA/SDR History - Maturation Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and NCOSE SCA 2.2.1 ???
    • SCA 2.2 refined and stable.
    • JTRS APIs developed.
    • Initial field testing of JTRS radios.
    • Development of SCA compliant and JTRS certified radios not developed independently of JTRS program.
    Development of SysML to bridge gap between System and Software Engineering. UML Profiles extend capabilities to capture more domain-specific modeling. 1990 2000 2010
  • 12. A (partial) SCA/SDR History – Now Booch ‘91 Rumbaugh OMT-1 OOPSLA Unified Method 0.8 Unified Method 0.9 OMT-2 Booch ‘93 Jacobson OOSE UML 1.0 OO SDR Arch SpeakEasy-1 SpeakEasy-2 MSRC JCIT SCA 2.2 CORBA CCM CORBA Svcs UML 2.0 MDA MOF SysML 1.0 SysML 1.1 CORBA IIOP GNU Radio USRP UML 2.3 WDL SoC MARTE LW Log FM3TR Impl FM3TR OMG SDR Forum CORBA 2 JTRS SCA 2.2.2 SCA CF Impl Cognitive Radio DSA OCL OMG and NCOSE SCA 2.2.1 SCA Next
    • Initiation of SCA Next activity in Wireless Innovation Forum.
    • Participants represent a cross section of the SCA community.
    • Collaboration with the JTRS Joint Program Executive Office (JPEO)
    • Initial joint meeting of JTRS JPEO and WInF held August 2010 in Washington, DC
    • Initial SCA Next rollout at the WInF SDR10 conference
    Lessons Learned 1990 2000 2010
  • 13. SCA Next Goals and Objectives
    • Reduce Development Resources
      • Modification to support more reusability
    • Reduce Test and Certification Time
      • The cost of certification is substantial and labor intensive.
    • Improve Performance
      • Streamline initialization and deployment
    • Incorporate Lessons Learned
      • Apply knowledge gained through experience on existing programs
  • 14. Independent Effort
    • SCA Next is not a formal project
    • Strong support within the community
      • JTRS participants
      • Wireless Innovation Forum
      • Independent contributors
    • Approximately 60 changes were submitted
      • 23 selected for resolution
  • 15. Focus Areas
    • Platform Independent Specification
    • Increase Compliance Points
    • Better Component / Interface Separation
    • Better Integration of Systems and Software
    • Address Recurring Issues in Design and Deployment
  • 16. Active Change Requests
    • Requirements Revision
    • Enhance Automated Testing
    • Deployment Optimization
    • Lightweight Components
    • CORBA Neutral / Evolution
    • Architecture Consistency
    • Application Enhancements – Nested Apps
  • 17. Active Change Requests
    • Application Enhancements – Interconnected Applications
    • Recommended C++ Features
    • Interface Definition Language (IDL) Refactoring
    • Lightweight AEP
    • Service Deployment and Initialization
    • Component Model
    • Developer’s User Guide
  • 18. Requirements Revisions
    • Enhanced Automated Testing
    • Reviewed 123 of 484 OE requirements that do not have an automated test in JTAP and assigned to one of three categories:
      • Automatable (29 w/ 1 approved)
      • Consider for re-write (58 may not be possible)
      • Consider for removal (27 w/ 3 approved)
  • 19. Automated Testing Issues
    • Some requirements are difficult if not impossible to force the test condition, e.g.
      • Raise FileException error on remove operation when a file-related error occurs.
    • Early versions of JTAP attempted to induce a file-related error by removing the file through a O/S command after opening through the CF::FileSystem.
    • File is not removed until all processes that have an active handle to the file exit.
  • 20. Push Registration and Static Ports
    • One of the more significant areas of proposed changes.
    • Basic concept is to provide all necessary data with the registration call rather than utilize “pull” calls from the component receiving the registration call.
    • Provides Ports may be defined as “static”, i.e. the lifecycle of the Port is tied to the lifecycle of the component and registered with the CF on instantiation.
  • 21. Static Deployment
    • Optimize deployment for “known” radio systems and waveforms.
    • Generate a static IOR for the Provides Port as part of the build process that maps to the target platform.
    • The static IOR provides a priori knowledge during system boot and waveform instantiation eliminating lookup in the Name Service or other repository.
    • Application instantiation time is streamlined by directly connecting the components through the static IORs.
    • Impact to tools, build process and core framework.
  • 22. CORBA Neutral Representation
    • Remove CORBA specific wording
    • Modify SCA interface representation (UML) to one that can be mapped to other technologies
    • Define mapping rules to create existing SCA equivalent.
    • Define mapping rules for a alternate technology.
  • 23. CORBA Neutral Challenges
    • Refactor the current specification into a well-formed UML model.
    • Developed the initial transformation of the UML-based model into the equivalent CORBA model (PIM  PSM)
    • Develop second transformation that accurately maps into an alternate technology
  • 24. CORBA Evolution
    • Objectives are to define profiles that:
      • Reduce resources,
      • Allow more freedom to platform designers while still promoting portability
      • Include widely used features
    • The profiles would apply to applications
      • The CF, Devices and Services may use (and may require) additional features.
    • Starting point is Minimum CORBA and CORBA/e
  • 25. Full and Lightweight Profiles
    • Two profiles planned.
    • Full – Provides features for general platforms and applications
    • Lightweight – Provides minimal features for highly constrained resources.
  • 26. Summary of Features
    • Allow additional ORB_init parameters to create a rootPOA with static, non-default policy settings.
    • Any type only allowed in Full profile
      • Deprecate use of Any and other complex types
  • 27. Full Profile
    • Similar to CORBA/e with some minor features removed
    • Some features added such as:
      • Thread Pools
      • Sever Security Model
      • Server and Client ProtocolPolicy
    • Many of the added features are supported by current ORB vendors including PrismTech
  • 28. Lightweight Profile
    • Eliminates the Any type and, consequently, does not support the Resource or PropertySet interfaces
    • Only CORBA/e Basic types are recommended – intended to enhance compatibility with FPGAs.
    • Minimum management calls supported.
  • 29. Lightweight Components
    • Basic concept is to support only those interfaces required for a particular object implementation.
    • Considered optional Realization and Inheritance relations.
    • Preferred approach was to use optional inheritance to a common base interface, e.g. Resource.
    • The waveform component would Realize the Resource interface which would have optional inheritance of other interfaces.
  • 30. Resource Interfaces
    • Lightweight components provide an optional cardinality [0..1] to the generalization/specialization association.
    • Additional interface changes and refactoring of IDL is proposed within this area.
    • Potential impact may be significant.
    Optional inheritance
  • 31. IDL Refactorization – Current IDL
  • 32. IDL Refactorization
    • The OMG SW RADIO specification used as a starting point
    • Develop separate IDL files for various elements, e.g. Device, LoadableDevice, etc.
    • Minimize the amount of CORBA stub code generated and thereby reduce footprint
    • Retain backward compatibility with the current IDL by incorporating the individual files in a “CF” module
  • 33. Summary
    • SCA Next represents a significant shift in the SCA community.
    • It has been initiated and performed largely by individuals and companies involved with the SCA or the JTRS program.
    • It has been a collaborative effort between the industry participants and the JTRS JPEO.
    • It is intended to be an open, international standard.
    • More work is required to bridge the gap between a recommendation and incorporation into the standard
  • 34. Spectra Support for SCA Next
    • ORB
      • CORBA/e Profile
      • Enhanced performance through zero copy
      • High-Performance transport
      • C and C++ ORB support
    • Core Framework
      • Static deployment and device assignment sequence
      • IDL refactorization
      • Static deployment
      • Push registration
    • Spectra CX Development Tool
      • CORBA neutral representation
      • C/C++ code generation
      • Testing automation
  • 35. Spectra CX Tool
  • 36. Spectra OE Studio
  • 37. DTP4500 Architecture
  • 38. DTP4500 Hardware Mistral Board with OMAP 35xx Transceiver RF Front End
  • 39. References and Resources
    • SCA: http://sca.jpeojtrs.mil/sca.asp
    • SCA Next: http://sca.jpeojtrs.mil/scanext.asp
    • JTRS APIs: http://sca.jpeojtrs.mil/api.asp
    • JTRS Portability Guidelines: http://sca.jpeojtrs.mil/_downloads/20091228_1.2.1_NEDTE_PORT_GUIDE.pdf
      • Note: This is a single, large PDF file.
  • 40. Next Technology Webcast
    • When: January 2011
    • Objective: Explore one or two SCA Next topics in more detail.
      • Discuss impact and interaction with tooling, development and deployment
    • Your input is appreciated
      • Forward questions and topic suggestions to:
        • [email_address]
        • With “SCA Next Webcast” in the subject
  • 41. For Information on Products and Services:
    • E-mail:
      • [email_address]
    • www:
      • www.prismtech.com/spectra
    • Your PrismTech account manager
  • 42. Thank You Any Questions?