Supporting SCA Applications in a Lightweight CCM Environment

Supporting SCA Applications in a Lightweight CCM Environment Frank Pilhofer fp@mc. com © 2004 Mercury Computer Systems, Inc.

Contents l SCA Evolution w Current state of the SCA w Leveraging commercial technologies w A scenario for a future SCA l Migrating Waveforms w Metadata w Resources l Summary © 2004 Mercury Computer Systems, Inc. 2

SCA Evolution 3

SCA History l SCA pioneered component-based development in embedded systems w Branched from CCM during finalization w Added important concepts of its own l OMG specifications are catching up, exceeding SCA functionality w Lightweight CCM, Streams for CCM, Lightweight Log, Lightweight Services, D+C l Combine OMG and JTRS efforts in component-based embedded system development © 2004 Mercury Computer Systems, Inc. 4

SCA, OMG Timeline l Leverage OMG standardization efforts SCA CCM Lightweight Logging CORBA Lightweight Services © 2004 Mercury Computer Systems, Inc. D+C 5 OMG adopted Specifications

COTS SCA Personality Lightweight Services Deployment and Configuration Waveform Interfaces Lightweight CCM Lightweight Logging COTS Content Future SCA Leverage existing specifications l Increase COTS Content in SCA l w Commercial, not DOD or SDR specific l Focus on Software Radio domainspecific aspects © 2004 Mercury Computer Systems, Inc. 6

SCA Evolution l Future SCA Assumptions: w SCA Resources become CCM Components • Commercially available Component Model • Make use of future extensions, e. g. , Streams for CCM w Use of D+C metadata and infrastructure for the deployment of applications • More powerful assembly and deployment model w No changes to Core Framework interfaces l Future SCA Impact: w Container/Component API changes w Metadata (SCA Domain Profile) changes © 2004 Mercury Computer Systems, Inc. 7

SCA Evolution Study l Premise w SCA Evolution by embracing commercial standards is beneficial for both JTRS and OMG l Adressing Evolution Issues w Mercury project to study and resolve evolution and migration issues w Idea: study migration now, so that it will be feasible and not troublesome later w Resulted in whitepapers and this presentation © 2004 Mercury Computer Systems, Inc. 8

SCA Evolution Issues l Investments into SCA-based infrastructure must be protected w w l Core Framework implementations Applications (Waveforms) Clients (HCIs) Devices Application and HCI investments most critical w Limited set of “off the shelf” Core Framework implementations and Devices © 2004 Mercury Computer Systems, Inc. 9

Migrating Waveforms 10

Migrating Waveforms l Goal: w Run existing SCA waveforms, unmodified, in a (Lightweight) CCM- and D+C-based environment l Approach: w Automatic transformation of application metadata, so that application can be deployed by COTS (not SCA or SDR specific) D+C based infrastructure w Automatic generation of implementation wrappers, so that resources can be executed as components in a CCM Container © 2004 Mercury Computer Systems, Inc. 11

Application Metadata Transformation 12

Metadata Transformation l Strong correlation between SCA Domain Profile and D+C meta-data w Transformation is well-defined (by design) © 2004 Mercury Computer Systems, Inc. 13

Assembly Metadata l SCA Software Assembly Descriptor is transformed to a D+C Component Package, containing a single assembly-based implementation © 2004 Mercury Computer Systems, Inc. 14

Assembly Metadata Detail © 2004 Mercury Computer Systems, Inc. 15

Metadata Comparison l Mercury whitepaper compared SCA vs. D+C metadata: w D+C metadata is superset of SCA w In the process, discovered and resolved a few issues • E. g. , “devicethatloadedthiscomponentref” resolved via a port delegation mechanism l All SCA application metadata can be converted to D+C application metadata © 2004 Mercury Computer Systems, Inc. 16

Application Implementation Wrappers 17

SCA Resource Wrapper l Wrap SCA Resources as a CCM Component w So that they can be deployed in a CCM Container w Wrapper acts as CCM component, delegating all behavior to Resource implementation l SCA Resource Component Wrapper No performance impact w Involved in connection setup, not in data transport l Can be generated automatically w Using port and property names from Software Component Descriptor (CCD) © 2004 Mercury Computer Systems, Inc. 18

“Device” Alternative l Alternative: “Executable Device” compatible Node Managers w SCA Executable Device implementing D+C Node Manager interfaces w Capable of running Resources “natively” (in addition to CCM components) w Disadvantage: requires modification of many Node Managers, becoming SCA specific © 2004 Mercury Computer Systems, Inc. 19

Summary 20

Summary l Adopting OMG specifications within the SCA has benefits w Greater standards base and implementation choice w More powerful assembly and deployment model w Combined efforts for future evolution of component-based development w Make SCA software radio specific -- no need to define a generic infrastructure l Migration issues can be overcome w SCA Applications can be migrated to D+C using a one-time, automated process © 2004 Mercury Computer Systems, Inc. 21