Scribd
Upload
14 views15 pages

FSW09 Peters

Uploaded by

Syed Saud Ur Rehman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
14 views15 pages

FSW09 Peters

Uploaded by

Syed Saud Ur Rehman
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 15

So#ware Defined Radio (SDR)

Architecture and Systems Issues


Workshop on
Spacecra# Flight So#ware (FSW‐09)
2009‐11‐6

Kenneth J. Peters
Jet Propulsion Laboratory, California Ins9tute of Technology
Introduc9on
• Speaker
• NASA STRS
– 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.
© 2009 California Ins9tute of Technology. Government sponsorship acknowledged.
Workshop on SpacecraF Flight SoFware
Ken Peters 2
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 3
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 4
(FSW‐09) 2009‐11‐6
Conceptual Block Diagram

Workshop on SpacecraF Flight SoFware


Ken Peters 5
(FSW‐09) 2009‐11‐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
Workshop on SpacecraF Flight SoFware
Ken Peters 6
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 7
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 8
(FSW‐09) 2009‐11‐6
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

Workshop on SpacecraF Flight SoFware


Ken Peters 9
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 10
(FSW‐09) 2009‐11‐6
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

Workshop on SpacecraF Flight SoFware


Ken Peters 11
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 12
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 13
(FSW‐09) 2009‐11‐6
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
Workshop on SpacecraF Flight SoFware
Ken Peters 14
(FSW‐09) 2009‐11‐6
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)
¿?

Workshop on SpacecraF Flight SoFware


Ken Peters 15
(FSW‐09) 2009‐11‐6

You might also like