An End-To-End CubeSat Data-Processing Chain

The development and validation of an end-to-end data-processing chain for CubeSat modules. It explores the motivation behind different options for payload launch, a CubeSat flatsat testbed, the system overview of a standard CubeSat platform, and the end-to-end data processing chain.

• data processing
• module development
• validation
• payload launch
• testbed
• system overview
• on-board data handling

aristotle Follow

Uploaded on Dec 21, 2023 | 1 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. An End-To-End CubeSat Data-Processing Chain for Module Development and Validation Malte Bargholz & Ric Dengel 04/10/2023 1 ESA UNCLASSIFIED For ESA Official Use Only

2. Motivation Customers wanting to launch a payload currently have two options: 1. Pay a Cubesat Platform Provider to build and integrate a satellite with their payload + Relatively low-risk, due to one vendor + Good integration less testing Costly Limited flexibility 2. Procure required subsystems from different vendors + Cheaper (mostly) + Maximum flexibility High risk (no standard interfaces/protocols, electrical..) Poor integration requires lots of integration testing However, Risk can be reduced by understanding the different vendor options and their compatibility/integration effort 3

3. Cubesat Flatsat Testbed Testbed contains small Cubesat, based on Space Inventor 3U platform However, all subsystems are exchangeable Testing Flatsat Configuration No harness, instead dedicated PCB for mounting Breakout area (right) allows easy access to all power-channels solar inputs External and internal data interfaces Extension area (left) allows connection of up-to 6 extension modules Communication either directly or via UHF through Raspberry Pi Ground Station 4

4. Cubesat Flatsat System overview Standard Cubesat platform subsystems: 1. 12-Channel PCDU 2. 7-channel MPPT 3. Dual-redundant TT&C (VHF/UHF) 4. Battery module (4S) 5. Dual OBC (non-redundant by default) 6. AOCS controller + Reaction wheel Additionally: 1. GPS receiver 2. Payload computer with Zynq FPGA SoC 3. Payload S-Band Radio 4. Raspberry Pi Ground Station Up to 6 additional extension modules can be connected (PC104 form factor), w/ configurable power supply All platform subsystems are connected to main CAN bus with Cubesat Space Protocol, secondary payload CAN bus MPPT AOCS RWEL PCDU GPS Platform CAN Bus RS422 OBC TTC BAT PDHU Payload CAN Bus Extension Module Module Extension Module S-BAND Extension 5

5. End-to-End Data Processing Chain 6

6. E2E Data Processing Payload Processing Payload Module Payload CAN BUS Zynq SoC Instrument (Simulator) FPGA CPU Data Transmitter AXI Slave XLA-HLS Neural Network Hardware Accelerator eMMC Parser Database RAM Data Generator 7

7. E2E Data processing On-board Data-Handling (House-Keeping) Telemetry Collection and Commanding is handling by OBSW on platform OBC eMMC FreeRTOS-based operating systems, extended by a set of tasks to manage TM/TC writes TM QUERY Packet Ring Buffer reads/writes updates Telemetry Processing/Commanding: Collection by set of independent task, one per node Collation by TM Manager, which paketizes and stores in file-backed packet ring buffer Retrieval through Command Server, which instructs TM manager to send packets in certain range TM TM CMD SERVER updates reads commands QUERY MANAGER Global Telemetry Data Structure updates TM receives packets sends packets QUERY CAN-BUS Compile-time configurable Easy extension for new subsystems 8

8. E2E Data Processing Ground Support Equipment Yet Another Mission Control Software (YAMCS) handles TM/TC on ground station computer Bidirectionally bridged from CAN to TCP/IP via helper application TM/TC format specified in XTCE (XML) mission database format TM viewing/TC via web-interface and/or desktop application (YAMCS Studio) 9

9. E2E Data Processing - Downlink CSP simplify the downlink step by connecting every subsystems through a node address system, the TT&C modules are then network routers We can allocate ranges of node addresses for specific segments (Ground, Radio and Flatsat), therefore isolate nodes from one segment from the others, except for the TT&C modules The downlink through UHF/VHF implements some CCSDS compliant features (FEC, Scrambling, ) 10

10. Current Status On-board data-handling Implementation functionally complete, however no science data handling is implemented Custom protocol Not CCSDS compliant Payload processing Can receive data from host computer and processes it with the FPGA Simplified communication interfaces such as AXI-Lite, RS422, etc. Downlink Can receive and transmit data through UHF/VHF connecting any of the Flatsat subsystems with the ground station Still no use of (S-Band) TT&C module for payload science data downlink EGSE YAMCS successfully integrated, all features available. CSP/CAN bridging is rudimentary (no reliable transport, encryption) 11

11. Conclusion Integration of heterogeneous Cubesats presents significant challenge Different protocols Different interfaces How-to test and validate? (and end-to-end?) Cubesat Flatsat as testbed for understanding this challenge Modular architecture allows exchange of different sub-systems (different vendors, ) Easy access at any place in the data-handling chain Fully meshed network for maximum flexibility Succesfully implemented a representative end-to-end data-handling chain to characterize capabilities of the system and maximize representativeness of the testbed (also: enable payload testing) However: Not fully validated yet (end-to-end), various improvements possible 12

12. Future Work Overall Goal Emulate realistic end-to-end data-handling chain for Cubesats, with built-in flexibility to accomodate a wide-range of payloads and be able to validate them in a realistic mission scenario. EGSE Data-Handling Payload Downlink YAMCS direct CSP over CAN Science Data Handling with standardized interface Instrument Simulator (HW- in-the-loop) Science Data Downlink Channel Commercial Equivalent Flight Software Standardised interface to payload boards Graphical User Interface CCSDS Support Standard software approach for instrument simulator High-speed downlink (S- Band based) Mission Scenario 13

13. Thank you for your attention! For questions related to the Cubesat Flatsat, feel free to reach out to us at, Malte Bargholz: malte.bargholz@esa.int, Tomasz Szewczyk: tomasz.szweczyk@esa.int We are open to discuss ideas and possible collaboration! 14 14