[ieee milcom 2005 - 2005 ieee military communications conference - atlantic city, nj, usa (17-20...

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




0 download

Embed Size (px)



    James Kulp, Murat BicerMercury Computer Systems, Inc

    Chelmsford, MA


    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.


    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.


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


    Processing Device X

    ContainerAComponentinstance 1



    Processing Device Y




    Figure 1. General architecture of platform.


    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.



View more >