So#wareDefinedRadio(SDR)ArchitectureandSystemsIssues

WorkshoponSpacecra#FlightSo#ware(FSW‐09)

2009‐11‐6

KennethJ.PetersJetPropulsionLaboratory,CaliforniaIns9tuteofTechnology

Introduc9on•  Speaker•  NASASTRS– SpaceTelecommunica9onsRadioSystem

•  JPLImplementa9on

•  SystemsIssues

2WorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6KenPeters

ThisresearchwascarriedoutattheJetPropulsionLaboratory,CaliforniaIns9tuteofTechnology,underacontractwiththeNa9onalAeronau9csandSpaceAdministra9on.

Referencehereintoanyspecificcommercialproduct,process,orservicebytradename,trademark,manufacturer,orotherwise,doesnotcons9tuteorimplyitsendorsementbytheUnitedStatesGovernmentortheJetPropulsionLaboratory,CaliforniaIns9tuteofTechnology.

©2009CaliforniaIns9tuteofTechnology.Governmentsponsorshipacknowledged.

Speaker•  JPLsoFwareengineerfor15+years– SoFwareleadforElectraradiosoFwareforMROandMSL

•  HelpeddraFandreviewNASASTRSspecifica9on– Specisreleased,butimprovementisongoing

•  OneofseveralsoFwareengineersdevelopingtheJPLimplementa9on–  JPLimplementa9onisoneofseveraltohelpshakeoutthespecifica9on

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 3

NASASTRS•  CombinedeffortbyseveralNASAcenterswithinputfromindustry

•  Released(v1.02)hardware,FPGA,andsoFwarearchitecturestandard–  Intendedtoallowcross‐pla]ormportabilityofcommunica9onimplementa9ons

– Alllayersandsignalprocessing•  Leanstowardrequiringinterfacedocuments,ratherthanspecificinterfaces– ExceptforsoFware

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 4

ConceptualBlockDiagram

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 5

BasicSTRSSWBlockDiagram•  STRSAPI– Controlandinterac9on– Similarto•  OMG/SWRADIO•  OMG/SCA(JTRS)

– Generallylighterweight•  POSIXRTOS– orcompa9bilitylayer

•  Devicedrivers– POSIXand/orSTRS

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 6

STRSApplica9ons•  TheCPUandFPGAsoFwarethatmakesthebox“bearadio”

•  Intendedtobeportableacrosscompa9blepla]orms– UseSTRSandPOSIXAPIs– Useservicesprovidedbypla]ormvendorthroughSTRSAPIs•  SuchasspacecraFinterfacehandlers(commandsandtelemetry)

– Accesshardwareviadevicedrivers•  Mayneedtodevelopcompa9bledriversondifferentpla]orms

– UsedefinedandflexibleinterfacestoandwithinFPGAs

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 7

JPLImplementa9on•  BasicarchitecturalfeaturesrunonLinuxpla]orm– Allowseasierdevelopment– Demonstratesbasicopera9ngsystemportability

•  Targetedtocustomradiohardwareforfullimplementa9on– AtmelAT697SparcCPU– UsingtheRTEMSPOSIXcompliantRTOS

•  Opensource•  SupportsAT697CPU

– DevelopingcustomRTEMSPOSIXdevicedrivers– DevelopingcustomFPGAmodulesforabstrac9on

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 8

JPLImplementa9on

•  S9ckingto“plainC”exceptwherenecessarytointeractwithC++STRSapplica9ons– Nodtohighlyconserva9vespacecodingenvironment– WanttosupportC++applica9onsdevelopedbyothers

•  Applica9onssta9callylinkedwithenvironment– Registra9onfunc9onsforC++objectorCentrypoints– Applica9onstartupandcontrolviaSTRSAPIfunc9oncommands

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 9

JPLImplementa9on

•  DevelopingasimplemodularFPGAmethodology– AssignmoduleIDcodesfordifferentmodulesthatmaybecombinedintoanFPGAbi]ile•  ModuleIDimpliesfunc9onalityandinterfacespecifica9on

•  Alsohaveversioncodesforupdates– DefineregisterbaseaddressesforFPGAmodules•  Definedwhenmodulesarebroughttogetherintoabi]ile•  Eachmoduleinternallydefineswhateverregistersitwants

– MakebaseaddressesandmoduleIDcodesavailabletosoFwareinregistersattheknownbaseaddressoftheen9reFPGA

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 10

SystemsIssues

•  ThechangeablenatureofthesoFwaredefinedradiomayleadtochangingconceptsofhowthelocalspacecraF,theground,andremotespacecraFinteractwithradios

•  Possibleapplicabilitytosystemsissueswithmorecomplexinstrumentsingeneral

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 11

RequirementsSpecifica9on•  Boundaries/interfaceslikelytobeindifferentplacesthanintradi9onalradios–  Conceptualblockdiagramdivisionsmaynotmatchphysicaldivisions

–  Differentdesignersatdifferentlayerstendtosharephysicalresources

•  Performancespecifica9onsalsobreakapartindifferentways–  Needtoclearlydefineperformanceateachconceptuallayer,whichmaybedevelopedindependently

–  Ratherthanend‐to‐endwithassump9onofsinglecoordinateddecomposi9on

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 12

CPU/FPGAInterac9on

•  ItisexpectedthatboththeCPUsoFwareandtheFPGAbi]ilemaychangetoprovidedifferentradiofunc9ons

•  Clearandflexibleinterfacedefini9onsareneeded–  BothbetweenandwithinCPUandFPGAcode–  Sothatmul9pleprogrammersofbothCPUandFPGAcodecanworkindependentlyandportably

•  Clearandflexibleversioniden9fica9onandcontrolareneeded–  SothatmismatchedsoFwareandbi]ilescanbeavoided

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 13

Command/ControlComplexity

•  SDRstendtohavemorecommandsandmodesthantradi9onalradios

•  Commandset,andtelemetryformats,mayvarydependingonwhatsoFwareisloaded–  Andmaydifferfromradio“safemode”ifany

•  Thismaybeaproblemfortradi9onalspacecraFandgroundcommand/controlmethods– Mayneedcoordinated“soFwaredefined”interfacesthroughoutthesystem,ormorestandardizedinterfaces

–  OrSDRsmayneedtohavemoreinternalautonomyKenPeters

WorkshoponSpacecraFFlightSoFware(FSW‐09)2009‐11‐6 14

“Iwantaradio,notarela9onship”–GlennReeves

Con9nua9on•  Notaconclusion,anongoingexplora9on•  MayneednewmodelsforthespacecraFbusprotocol¿Morelike“plugandplay”,withdriverdiscoveryasinPCI?¿Morelikemanagingnetworkhosts,withautoconfigura9onasinSNMP?

¿Morelikenetservicesorserviceorientedarchitecture,withdiscoverableinterfacesasinWSDL?(WebServicesDescrip9on

Language)

¿?

KenPetersWorkshoponSpacecraFFlightSoFware

(FSW‐09)2009‐11‐6 15