WIXLIB

Software tsRFApplicationsCore Framework (CF)Commercial icalAPIModemModemComponents AdapterMAC APIACSLink, NetworkComponentsSecuritySecuritySecurityAdapter Components AdapterLLC/Network APISecurity APICore Framework IDLCORBA ORB &Services(Middleware)CFServices &ApplicationsOperating SystemNetwork Stacks & Serial Interface ServicesBoard Support Package (Bus Layer)Black Hardware BusNon-CORBAI/OComponentsLink, NetworkComponentsI/OI/OAdapter ComponentsLLC/Network APII/O API(“Logical Software Bus” via CORBA)CORBA ORB &Services(Middleware)CFServices &ApplicationsOperating SystemNetwork Stacks & Serial Interface ServicesBoard Support Package (Bus Layer)Red Hardware BusNeli HayesPrincipal Software ArchitectSCA Core Framework TeamJTRS Cluster 1 ProgramThe Boeing Company, Anaheim, CApersnaz.n.hayes@boeing.com(714) 762-9266OMG Workshop on Distributed Object Computing forReal-Time and Embedded SystemsJuly 2003

ObjectivesTo provide an overview of reasons for creation of the SCA.To describe what the SCA is, what it is not (i.e. where itfits into a communications systems procurement), andits goals.To introduce all SCA specifications, supplements, andavailable formal training.To provide a comprehensive overview of the SCA corearchitecture rule set.To provide some general design guidelines regardingdevelopment of SCA-compliant components.Page 2

OutlineWhy was the SCA Created?–––––––Tactical Communication Systems LimitationsThe JTRS ProgramJTRS Vision & MissionJTRS RequirementsWhat is a Software Defined Radio?JTRS Target – A Software Defined RadioInception of the SCA89101112131415Page 3

Outline(cont.)What is the SCA?––––The SCA Is The SCA Is Not SCA ObjectivesHow the SCA Achieves its ObjectivesSCA Specifications––––––SCA SpecificationSCA Support & Rationale DocumentSCA API SupplementSCA Security SupplementSCA Developer’s GuideSubject of This Briefing161719222324262829303132Page 4

Outline(cont.)SW Architecture Overview––––JTR Set Components Integrated through the SCAAny Domain’s Component’s Integrated through the SCASW Architecture Birds Eye ViewSW Architecture Detailed View– SW Architecture Major Divisions (Infrastructure & Application Layers)– Infrastructure Layer–––––Bus LayerNetwork & Serial Interface ServicesOperating System LayerCORBA MiddlewareCore Framework (CF)– Application Layer– CORBA-Capable Components– Adapters Allowing Use of Non-CORBA-Capable Components– SW Architecture Benefits33343536373839394041444647474849Page 5

Outline(cont.)SW Architecture Infrastructure Layer– Operating Environment (OE)– Operating System & CORBA Middleware– Core Framework (CF)– Base Application Interfaces– Framework Control Interfaces––––––Base Device InterfacesNode Component Deployment & Removal InterfaceDomain Component Deployment & Removal InterfaceApplication Installation/Un-installation InterfaceApplication Creation InterfaceApplication Configuration/Control/Termination Interface– File Service Interfaces– Log Service– Domain Profile – Component Packaging & age 6

Outline(cont.)Application Development Using the SCA (CF)191– Component Development– Interconnection of Components Via Ports– General Design/Implementation Considerations193195204– Application Installation– Application Instantiation210212How CF Interacts with Application Components– Creation of a Single Application Component– Connecting Application Components Together– Invoking Operations on a Single Application Component– Application Tear-DownSCA IDL ModulesReferences208213215217218219225Page 7

Why was the SCACreated?

Tactical CommunicationSystems LimitationsCurrent tactical communications systems evolvedto meet service-specific and mission-specificrequirements.Specialized functionality resulted in majorlimitations in communicating from one system toanother, due to current radio-specific design.Real-time information exchange and effectivecommunication among joint forces, all the wayto the war fighter in the field, are critical toassure combatant effectiveness and safety.Page 9

The Joint Tactical RadioSystem (JTRS) ProgramA series of related joint acquisition activities, conducted bythe JTRS Joint Program Office (JPO), designatedServices' cluster Program Management Offices,and other DoD agencies.The JPO was established to pursue the development offuture communications systems, capturing the benefitsof technology advances in the recent years, to greatlyenhance interoperability of communications systems andreduce development and deployment costs.Page 10

JTRS Vision & MissionProvide optimal communications support for jointoperations, by enabling coordination and integration ofmilitary communications through a cohesive joint tacticalradio infrastructure, that provides the means of digitalinformation exchanges, among joint war fightingelements, while enabling connectivity to civil andnational authorities.Acquire a family of affordable, high-capacity, tactical radiosystems to provide interoperable and upgradeable lineof-sight, beyond line-of-sight, and wireless mobilenetwork Control, Communications, Computers, andIntelligence (C4I) capabilities to the war fighters in thefield.Page 11

JTRS RequirementsTo realize the JTRS Program Mission, the JTRS must be Modular, enabling additional capabilities and features tobe added to JTR sets, Scaleable, enabling additional capacity (bandwidth andchannels) to be added to JTR sets, and Backwards-compatible, allowing JTRS to communicatewith the legacy radios it will eventually replace, allowingdynamic intra-network and inter-network routing fordata transport that is transparent to the radio operator.Hence, the JTRS target became a family of SoftwareDefined Radios.Page 12

What is a Software DefinedRadio (SDR)?Radio functionality is provided through software ratherthan hardware. Software applications provide waveform generation andprocessing, encryption, signal processing, and other majorcommunications functions. Programmable and able to accommodate various physical layerformats and protocols. Multiple software modules allow implementation of differentstandards in the same radio system. Flexibility of incorporation of new functionality, without need toupgrade or replace hardware components. Decreased maintenance costs, due to radio receivers being reconfigurable over-the-air.Page 13

JTRS Target – A SoftwareDefined RadioIts characteristics can be altered allowing it tooperate with any legacy waveform. A single unit can accommodate multi-service andmulti-national capabilities.It can be upgraded or reprogrammed usingstandardized APIs. New or improved capabilities can be incorporatedeasily.Hence, the Software Communications Architecturewas conceived.Page 14

Inception of the SCATo realize the JTRS Goals and Mission, the familyof JTRS software-defined radios will bedesigned around a SoftwareCommunications Architecture (SCA) thatcan support the needed functionality andexpandability of the JTRS.Page 15

What is the SCA?

The SCA Is Is an open architecture framework that tellscommunications systems designers how elements ofhardware and software are to operate in harmony withinan SCA-compliant system.Enables communication platforms (e.g. software definedradios) to load applications (e.g. waveforms), run theseapplications, and be networked into an integratedsystem.Is used by communication platform (e.g. radios, etc.)hardware and software design engineers just as abuilding architect or planner uses a local building codeto design and build homes.Page 17

The SCA Is (cont.)Is based on CORBACORBAservicesCORBA Component ModelPOSIXIs expressed in CORBA IDL UML XMLNot only is the SCAmeant to be anopen andcommerciallyadopted standard,but, it is based onand uses manyopen commercialstandards.Page 18

The SCA Is Not Is not a system specification. It is a set of rules that constrain the design ofsystems, to achieve SCA objectives. SCA objectives, originally conceived to meet JTRS objectives,are applicable to any communications system with the goalsof component portability, interchangeability, andinteroperability. Comprised of interface and behavioral specifications, generalrules, waveform APIs, and security requirements.Page 19

The SCA Is Not (cont.)Does not tell hardware and software designers how todesign their equipment and programs. SCA requirements limited to those necessary to meet SCAcompliant system criteria, w/o restricting innovation or domainspecific requirements. Through adherence to standards detailed in the SCA definitiondocument, both hardware and software designers know whatequipment and programs to design. SCA-compliant networked systems (e.g. JTRS compliant radios,other communications systems, etc.), when designed incompliance with the SCA, will meet SCA-compliancy standardsfor interoperability, just as properly designed plumbing orelectrical systems meet local codes for construction and safety.Page 20

The SCA Is Not (cont.)Is not an implementation architecture. It is an implementation-independent framework fordevelopment of SCA-compliant systems (e.g. JTRSSDRs). There are many valid definitions of the SCAarchitecture. Both at a high system level, and at a low software andhardware level. A particular SCA implementation architecture is aresult of joining between the SCA, the particulardomain and project technical specifications, andother procurement requirements.Page 21

SCA Objectives Alignedwith JTRS GoalsJTRS: Greatly increased operational flexibility and interoperability ofglobally deployed communications systems,SCA: Provide for portability of applications software between differentSCA implementations,JTRS: Reduced supportability costs,SCA: Leverage commercial standards to reduce development costs,JTRS: Upgradeability in terms of easy technology insertion andcapability upgrades, andSCA: Reduce development time of new waveforms or other SCAcompliant applications through the ability to reuse design modules,andJTRS: Reduced system acquisition and operation cost.SCA: Build on evolving commercial frameworks and architectures.Page 22

The SCA Achieves itsObjectives by Defining an open, distributed, component-based,object-oriented architectureSeparating applications from the operatingenvironmentSegmenting application functionalityDefining common interfaces for Managing &Deploying Software ComponentsDefining common services & APIs to supportdevice and application portabilityPage 23

SCA Specifications

SCA SpecificationsSCASpecificationV2.2Rationale behindarchitectural ruleset decisionsaccompaniedwith supportingmaterial.Basicarchitecturedefinition & rulesets governingSCA-complianthw & pplicationProgramInterfaceSupplementV1.1Design guidelinesfor developingSCA-compliantwaveformapplications anddevices. militaryuniquerequirements areprovided in pplementV1.1To maximizeSCA’scommercialapplication andresultingbenefits Available at http://jtrs.army.mil/Page 25

SCA SpecificationSCASpecificationV2.2Software Architecture Definition and Rule Sets The SCA “operating environment” (OE). Services and interfaces that applications use from theOE. Use of OO concepts to define partitions of OE andpartitions of applications built on top of the OE. Design constraints imposed on applications built ontop of and running on the OE, in order to maximizeapplication portability from one SCA-compliantplatform to another.Page 26