So#ware Defined Radio (SDR) Architecture and Systems Issues

Transcription

1 So#ware Defined Radio (SDR) Architecture and Systems Issues Workshop on Spacecra# Flight So#ware (FSW 09) Kenneth J. Peters Jet Propulsion Laboratory, California Ins9tute of Technology

2 Speaker NASA STRS Introduc9on Space Telecommunica9ons Radio System JPL Implementa9on Systems Issues This research was carried out at the Jet Propulsion Laboratory, California Ins9tute of Technology, under a contract with the Na9onal Aeronau9cs and Space Administra9on. Reference herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not cons9tute or imply its endorsement by the United States Government or the Jet Propulsion Laboratory, California Ins9tute of Technology California Ins9tute of Technology. Government sponsorship acknowledged. 2

3 Speaker JPL sofware engineer for 15+ years SoFware lead for Electra radio sofware for MRO and MSL Helped draf and review NASA STRS specifica9on Spec is released, but improvement is ongoing One of several sofware engineers developing the JPL implementa9on JPL implementa9on is one of several to help shake out the specifica9on 3

4 NASA STRS Combined effort by several NASA centers with input from industry Released (v1.02) hardware, FPGA, and sofware architecture standard Intended to allow cross pla]orm portability of communica9on implementa9ons All layers and signal processing Leans toward requiring interface documents, rather than specific interfaces Except for sofware 4

5 Conceptual Block Diagram 5

6 Basic STRS SW Block Diagram STRS API Control and interac9on Similar to OMG/SWRADIO OMG/SCA (JTRS) Generally lighter weight POSIX RTOS or compa9bility layer Device drivers POSIX and/or STRS 6

7 STRS Applica9ons The CPU and FPGA sofware that makes the box be a radio Intended to be portable across compa9ble pla]orms Use STRS and POSIX APIs Use services provided by pla]orm vendor through STRS APIs Such as spacecraf interface handlers (commands and telemetry) Access hardware via device drivers May need to develop compa9ble drivers on different pla]orms Use defined and flexible interfaces to and within FPGAs 7

8 JPL Implementa9on Basic architectural features run on Linux pla]orm Allows easier development Demonstrates basic opera9ng system portability Targeted to custom radio hardware for full implementa9on Atmel AT697 Sparc CPU Using the RTEMS POSIX compliant RTOS Open source Supports AT697 CPU Developing custom RTEMS POSIX device drivers Developing custom FPGA modules for abstrac9on 8

9 JPL Implementa9on S9cking to plain C except where necessary to interact with C++ STRS applica9ons Nod to highly conserva9ve space coding environment Want to support C++ applica9ons developed by others Applica9ons sta9cally linked with environment Registra9on func9ons for C++ object or C entry points Applica9on startup and control via STRS API func9on commands 9

10 JPL Implementa9on Developing a simple modular FPGA methodology Assign module ID codes for different modules that may be combined into an FPGA bi]ile Module ID implies func9onality and interface specifica9on Also have version codes for updates Define register base addresses for FPGA modules Defined when modules are brought together into a bi]ile Each module internally defines whatever registers it wants Make base addresses and module ID codes available to sofware in registers at the known base address of the en9re FPGA 10

11 Systems Issues The changeable nature of the sofware defined radio may lead to changing concepts of how the local spacecraf, the ground, and remote spacecraf interact with radios Possible applicability to systems issues with more complex instruments in general 11

12 Requirements Specifica9on Boundaries/interfaces likely to be in different places than in tradi9onal radios Conceptual block diagram divisions may not match physical divisions Different designers at different layers tend to share physical resources Performance specifica9ons also break apart in different ways Need to clearly define performance at each conceptual layer, which may be developed independently Rather than end to end with assump9on of single coordinated decomposi9on 12

13 CPU/FPGA Interac9on It is expected that both the CPU sofware and the FPGA bi]ile may change to provide different radio func9ons Clear and flexible interface defini9ons are needed Both between and within CPU and FPGA code So that mul9ple programmers of both CPU and FPGA code can work independently and portably Clear and flexible version iden9fica9on and control are needed So that mismatched sofware and bi]iles can be avoided 13

14 Command/Control Complexity I want a radio, not a rela9onship Glenn Reeves SDRs tend to have more commands and modes than tradi9onal radios Command set, and telemetry formats, may vary depending on what sofware is loaded And may differ from radio safe mode if any This may be a problem for tradi9onal spacecraf and ground command/control methods May need coordinated sofware defined interfaces throughout the system, or more standardized interfaces Or SDRs may need to have more internal autonomy 14

15 Con9nua9on Not a conclusion, an ongoing explora9on May need new models for the spacecraf bus protocol More like plug and play, with driver discovery as in PCI? More like managing network hosts, with auto configura9on as in SNMP? More like net services or service oriented architecture, with discoverable interfaces as in WSDL? (Web Services Descrip9on Language)? 15