[IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating Specialized Hardware to JTRS/SCA Software Defined Radios

Download [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating Specialized Hardware to JTRS/SCA Software Defined Radios

Post on 27-Mar-2017

212 views

Category:

Documents

0 download

Embed Size (px)

TRANSCRIPT

  • INTEGRATING SPECIALIZED HARDWARE TOJTRS/SCA SOFTWARE DEFINED RADIOS

    James Kulp, Murat BicerMercury Computer Systems, Inc

    Chelmsford, MA

    ABSTRACT

    The Joint Tactical Radio System (JTRS) is a family ofmodular, multi-band, networked software defined radiosthat are compliant with an international open standardcalled the Software Communications Architecture (SCA)[1]. In 2004, the JTRS Joint Program Office (JPO) organ-ized an effort to develop a Specialized Hardware Supple-ment (SHS) to the SCA to enable JTRS tactical radios tosupport high-speed data links and satellite communica-tions (SATCOM). The waveforms for these systems typi-cally operate over 2 GHz. The SHS defines portability re-quirements for the components of these waveforms thattarget more specialized and resource-constrained envi-ronments commonly represented by digital signal proces-sor (DSP), field programmable gate array (FPGA) andASIC environments. At the time of the writing of this pa-per, change proposals are under review by JPO to replacethe SHS.

    This paper presents one of these proposals. The Compo-nent Portability Specification [2]. The paper analyzes theprinciples that this specification is built on to extend theSCA waveform component portability. It examines thethree goals the specification intended to achieve. portabil-ity, interoperability and replaceability. The paper con-cludes by articulating the impact of the SHS on existingwaveforms and JTR sets.

    INTRODUCTION

    The goal of the JTRS program is to replace the existinghardware-intensive radios of the United States militarywith software-centric communications systems that can beupdated with low cost through reprogramming. The JTRSJPO is planning to achieve this objective by building thenew software radios compliant to the SCA.

    The purpose of the SCA is to provide a common standardfor waveform development such that waveforms can easilybe ported from one radio platform to another. SCA-compliant waveform applications consist of source codeand metadata. The waveform metadata is used to describethe properties of each waveform component as well ashow these components are assembled to constitute the

    waveform. The metadata is represented by a set of XMLfiles called the SCA Domain Profile [3].SCA was designed primarily for radios with CORBA-enabled [4] general purpose processors (GPPs). Unfortu-nately, today's high-bandwidth waveforms have demand-ing processing and power requirements that cannot be metwith the state-of-the-art GPPs. Such waveforms can onlybe executed on radio platforms that employ more special-ized hardware such as FPGAs or DSPs. Acknowledgingthis problem, JTRS JPO organized a workshop in 2004 todevelop the SHS followed by a second workshop in Janu-ary 2005.

    Proposals have emerged as a result of these workshops,offering solutions to the SHS problem that differ in scope.This paper presents Change Proposal (CP) 289: The Com-ponent Portability Specification (CPS).

    CPS defines source code portability requirements forwaveform components targeting specialized and resource-constrained environments. Through a careful separation ofconcerns, each SCA waveform component's functionalityis isolated from the class of processor used for its imple-mentation. With the help of containers that provide theimmediate runtime environment to the component in-stances, waveform components that execute on non-GPPprocessors can be ported to other processors of the sameclass.

    This paper assumes the reader has a basic understanding ofthe SCA specification and its domain profile.

    KEY TERMS AND CONCEPTS

    This section defines the key terms and concepts usedthroughout the paper to facilitate the discussion.

    Component: The SCA uses the term "component" in thegeneral sense of any part of the application, infrastructure,environment, or hardware system. The term "resource" isused as the general term for infrastructure or applicationsoftware modules (i.e. a source of functionality rather thana source of supply or capacity). The CPS uses the term"component" more narrowly, as an independently definedunit offunctionality of an application or waveform, sepa-

    1 of 6

  • rate from the operating environment or any other infra-structure elements. "Component" applies here equally tounits of functionality implemented for ASICs, FPGAs,DSPs, or GPPs.

    Application: CPS uses the term narrowly to designate aconfigured and interconnected set of components as indi-cated by the SCA Assembly (i.e. SAD), but not includingany infrastructure (Core Framework, devices or services).

    Class: This term is used to indicate the general category ofthe processing device, container, or component: GPP, Re-source-constrained C-programmable Component (RCC),or RTL-programmable Logic (RPL). A simple DSP canserve as a good example for a RCC. FPGAs and ASICs areexamples for RPLs. The RCC and RPL classes are collec-tively termed the Specialized Hardware Processing (SHP)class.

    Container: A container is the immediate runtime envi-ronment in which a component instance executes. Con-tainers provide to component instances the execution envi-ronment, and a standardized set of local ApplicationProgramming Interface (API)-based services. This defini-tion is as used in literature for most component softwaresystems, including the CORBA component model onwhich the SCA was partially and loosely based. In sum-mary, applications consisting of components are executedby instantiating the components for execution in appropri-ate containers executing on processing devices (GPP orSHP). Component source code is authored for a givenclass of container and processing device. Componentsource code is compiled and linked for a specific containerimplementation (e.g. for a specific operating system, com-piler, ORB).

    Platform: A platform is a collection of (GPP and SHP)processing devices and associated containers that togethersupport the execution of component-based applications. Inparticular, a set of containers is enabled to communicatewith each other such that components running in differentcontainers can communicate with each other withoutknowledge of the type or class of container housing the"other component". An SCA Core Framework (CF) Do-main Manager manages the platform. The supplier andintegrator of a platform must assemble, install and config-ure the collection of processors, Logical Devices and asso-ciated containers such that they support interoperation ofcomponents. The components (source code, compiledcode, or metadata) have no knowledge of the class of thecontainer or component at the "other end" of inter-component communication.

    Figure 1 depicts the simple hierarchy of execution envi-ronment relationships without showing the control infra-structure (core framework elements) or non-programmable

    devices. The components shown are, strictly speaking, in-stances of component implementations for componentsindicated in the application's assembly descriptor (SAD).

    Platform

    Processing Device X

    ContainerAComponentinstance 1

    Componentinstance2

    ContainerBComponentinstance3

    Processing Device Y

    ContainerCComponentinstance4

    Componentinstance5

    Componentinstance6

    Figure 1. General architecture of platform.

    GOALS

    The Component Portability Specification is written toachieve the goals listed below. Therefore, the specificnormative sections in the specification should be seen andevaluated against these goals.

    Portability: This goal is to make the source code of wave-form components targeting SHP environments to be simi-lar to the level of portability achieved in the core specifica-tion for GPP components. Portability is within the sameclass "like-for-like".

    Consistency: SHP components should be treated as con-sistently as possible with GPP components to simplifylearning curves, CF implementations, tools, documenta-tion, metadata, and technology migration.

    Replace-ability: Different component implementations,for diferent classes, for the same component interface andfunctionality, should be possible as alternative implemen-tations under the implementation element of the SoftwarePackage Descriptor (SPD), so that the application may bedeployed using any class of processor supported by com-ponent implementations. This enables one deployablewaveform, as defined by one SAD, to target different sce-narios of hardware presence and availability, or to be usedin radios with different hardware configurations, furtherincreasing reusability. Replaceability implies transparencywith respect to other components of the waveform to en-able rapid technology insertion or upgrade.

    2 of 6

  • Separation of Concerns: Component functionality, andthe role a component plays in an application, should be aseparate concern from how the component is implemented;including for which class of processor the component im-plementation is created. Component implementation au-thorship should be concerned with the class of containerbeing targeted and not the class of other containers thathouse other components that may communicate with it.Writing the container and associated logical device soft-ware to prepare a processor to house components shouldbe separated from waveform component authorship.

    Resource Efriciency and Performance: Since SHP exe-cution environments are generally small, lean, and re-source-constrained, the other goals should not compromisethe typical resource efficiency of SHPs. The "portabilitytax" should not be more than necessary. When componentscommunicate within or between SHP containers, the la-tency and throughput characteristics should not be signifi-cantly different than using non-portable approaches.

    Minimal Impact to SCA: The above goals are achievedwith design choices that minimize the necessity to changethe SCA Core Specification.

    ARCHITECTURAL FOUNDATION

    In CPS terminology, the concept of a worker represents theinstantiated code that implements the business logic of acomponent running on a SHP. Each worker is instantiatedwithin a container that provides its execution context.Workers are represented to the SCA CF by generic proxiesthat realize the SCA CF::Resource CORBA interface onbehalf of the worker. Each generic proxy is instantiated bya logical device that represents the SHP hardware device.The generic proxy and the container are provided as a partof the platform and have no knowledge of the worker'sdetails.

    Container Behavior: SCA covers the container conceptby referring to "Executable Devices" and "Resource Fac-tories" as places in which software components may beinstantiated and run. The CPS container concept is nar-rower and more precise: it refers to the immediately sur-rounding execution environment that 1) invokes and con-trols the component and 2) provides the local services andAPIs the component invokes during execution. "Contain-ment" means that the component interacts only directlywith the container, and interacts with external entities onlyindirectly, via its container. Containers are sometimesprocesses, sometimes threads, and sometimes use a pool orgroup of threads. These are all implementation variationsthat support the container concept. Containment is logical,not physical, meaning that it may be "optimized away" incases when multiple component implementations are lo-

    cated in the same container. Thus containment does notalways imply any overhead. There is no particular rela-tionship between thread, process and container.

    The SCA concept of a device is hardware, and the SCAconcept of a Logical Device is a software proxy for hard-ware. Containers exist (execute) on the hardware process-ing device, and thus have a "runs on" relationship withhardware devices, and an "is controlled by" relationshipwith Logical Devices. There can be multiple containers perSCA device, since components deployed on devices mightrequire different execution environment attributes (e.g.security or priority), which would require them to run indifferent containers on the same processing device. TheLogical Device for a processing device must be a GPPsoftware infrastructure module that executes on a GPP. AGPP processing device may host its own Logical Deviceproxy. Since functionality can be flexibly divided betweenthe Logical Device and the container, there is no standardinterface between them for any class. Logically, the SHPcontainer performs functions analogous to GPP containers.The main difference is in the local (inside the container)interfaces between components and containers. These in-terfaces do not use CORBA, and they are more constrainedand simplified than those for GPP components. They arespecialized differently for both RCC and RPL classes.

    Component Behavior: SCA components are defined tohave a specific control interface (e.g. CF::Resource) and anumber of port interfaces, and to use local ApplicationEnvironment Profile (AEP) [5] services.

    The term "worker" is used for the instantiated SHP com-ponent implementation that runs directly on the SHP de-vices. Since workers do not use CORBA, and SCA appli-cation components for GPPs are required to use CORBA,SHP components are implemented in two parts: the workerand the generic proxy. Generic proxy acts as the bridgebetween the worker and the SCA CF.

    SHP component implementations are the functional codeswritten in the source language of the SHP class. The com-piled binary code executes directly on the SHP device in-side the SHP container. Its control interface (controlled viathe generic proxy's implementation of the CF..Resourceinterface) uses a fixed API which is a rough functionalsubset of the Resource interface. CP 289 defines specificAPIs per SHP class.

    Worker ports operate according to interfaces defined by apure IDL [6] subset as indicated in the Software Compo-nent Descriptor (SCD), and use a fixed container API tosend and receive interoperable messages whose structure isderived from the IDL. The worker does not know anythingabout any communication mechanisms used on the plat-form or between any containers, or even inside a container.

    3 of 6

  • It knows only how to interact locally and directly with itscontainer. It does not need or use CORBA.

    When multiple workers are collocated in the same con-tainer, the container may arrange for them to communicatedirectly with each other, as an optimization.

    The generic proxy is a specialization of the SCA adapterconcept. When the SHP Logical Device is asked to instan-tiate an SHP component, using the load and execute opera-tions, it creates the generic proxy as a local CORBA objectto represent that instantiation in the SHP container on theSHP device.

    The generic proxy is responsible for establishing connec-tions with its worker. Since each worker running on theSHP device has its own ports, the per-worker genericproxy implements the CF. .PortSupplier interface, createsCF::Port objects, and implements the connectPort opera-tions for its worker. Since there may be multiple workersbased on a single implementation, or multiple workerswith common port names running on an SHP device, thegeneric proxy also provides the appropriate scope f...

Recommended

View more >