ES52_Waite_Riley_Poster
1
BARCoMmS: iSat Ground Station Testing System A ground station test software for the iSat project was written with the intent of replicating a mission-viable ground station with the Consultative Committee for Space Data Systems’ (CCSDS) File Delivery Protocol (CFDP) capability and a modular user interface with packet transfer visualization, a satellite command issuer, CFDP command-line integration, and satellite event history displays. Named BARCoMmS (Ben, Alissa, and Riley’s Communication Management System) after the intern group, the software will be capable of interfacing with the closed-loop iSat data pipeline, and, as such, will be integral to the simulation of satellite operations. The system will send and receive CCSDS space packets through specified UDP ports to a Programmable Telemetry Processor (PTP) with certain ports representing specific virtual channels through which telemetry and satellite commands will run. ES52 Mentors: Scott Akridge Jim Cecil Jamie Moyers Ben Kingen Alissa Smith Riley Waite The CFDP module is a GUI-wrapped implementation of CCSDS’s CFDP library. At its core, the CFDP module enables the reliable and unreliable (for test purposes) delivery of space packets. In addition to this, however, the module supports a variety of functions helpful during communication passes. The ability to freeze and thaw the engine, suspend or cancel transactions, and change the file chunk sizes are just a few. The module is also fully capable of fault injection testing with built-in faults provided in the link simulator. The Day-In-The-Life (DITL) module consists of two primary viewports: the graphical timeline, and the event tree display. The graphical timeline, which itself consists of three graphic viewports, paints events in real- or non-real- time to its grid. The event tree display nests these events under their respective severity (Advisory, Caution, or Warning). The DITL module provides a ground station technician with instant and critical information, allowing them to make quick decisions during a short communication pass. The Command module is a naïve implementation of what will become a fully equipped satellite control and command interface. The Bulletin module provides a real-time packet-transfer display consisting of two main trees. The leftmost tree displays the current status of all CFDP file transfers. The rightmost tree displays all commands sent to the flight software from the command window, as well as their status according to the Health and Status telemetry sent from the flight software. The information is color-coded such that errors are made instantly known to the ground station technician, providing them with the capability to retransmit information or commands during a communications pass. Future Work: • Implement satellite control and command interface • Graphically create and upload communication schedule through DITL module • Implement an improved top-level application framework • Implement customizable user interface themes, layouts, and preferences Abstract: Upon initialization, the four modules (green), along with two packet listener threads (blue), are instantiated. During this instantiation, listener threads open and listen to their respective UDP ports (yellow). The modules are connected to each other and the listener threads via signals and slots, a subscription- publication system native to the Qt framework that BARCoMmS was developed in. Connections are as follows: • Bulletin listens to CFDP for CFDP transaction information • Bulletin listens to Command for command PDUs • Bulletin listens to the Telemetry Packet Listener for Health and Status PDUs and command acknowledgments • DITL listens to the Telemetry Packet Listener for Event PDUs • Telemetry Packet Listener listens on incoming FSW telemetry UDP port • Command Packet Listener listens on incoming external command UDP port • CFDP module connects to the FSW’s CFDP client through UDP port for CCSDS space packet PDU transfers • Command sends command PDUs to FSW Full arrows represent serial process flow. Diamonds represent slots; lines connecting to them represent signals. Dashed lines represent UDP port connections. Acknowledgements: The intern group would like to thank mentors Scott Akridge, Jim Cecil, and especially Jamie Moyers for their support, guidance, and patience. We thank Tina Atchley for her support as our intern coordinator, and Daniel Heater for his generosity in selecting us for these positions.
-
Upload
riley-waite -
Category
Documents
-
view
7 -
download
0
Transcript of ES52_Waite_Riley_Poster
BARCoMmS:
iSat Ground Station Testing System
A ground station test software for the iSat project was written with the intent of replicating a mission-viable ground station with the Consultative Committee for Space DataSystems’ (CCSDS) File Delivery Protocol (CFDP) capability and a modular user interface with packet transfer visualization, a satellite command issuer, CFDP command-lineintegration, and satellite event history displays. Named BARCoMmS (Ben, Alissa, and Riley’s Communication Management System) after the intern group, the software will becapable of interfacing with the closed-loop iSat data pipeline, and, as such, will be integral to the simulation of satellite operations. The system will send and receive CCSDS spacepackets through specified UDP ports to a Programmable Telemetry Processor (PTP) with certain ports representing specific virtual channels through which telemetry and satellitecommands will run.
ES52 Mentors:Scott Akridge Jim CecilJamie Moyers
Ben KingenAlissa SmithRiley Waite
The CFDP module is a GUI-wrapped implementation ofCCSDS’s CFDP library. At its core, the CFDP module enables the reliable andunreliable (for test purposes) delivery of space packets. In addition to this,however, the module supports a variety of functions helpful during communicationpasses. The ability to freeze and thaw the engine, suspend or cancel transactions,and change the file chunk sizes are just a few. The module is also fully capable offault injection testing with built-in faults provided in the link simulator.
The Day-In-The-Life (DITL) module consists of two primary viewports: the graphicaltimeline, and the event tree display. The graphical timeline, which itself consists of threegraphic viewports, paints events in real- or non-real- time to its grid. The event tree displaynests these events under their respective severity (Advisory, Caution, or Warning). The DITLmodule provides a ground station technician with instant and critical information, allowingthem to make quick decisions during a short communication pass.
The Command module isa naïve implementationof what will become afully equipped satellite control and command interface. The Bulletin module provides areal-time packet-transfer display consisting of two main trees. The leftmost tree displaysthe current status of all CFDP file transfers. The rightmost tree displays all commands sentto the flight software from the command window, as well as their status according to theHealth and Status telemetry sent from the flight software. The information is color-codedsuch that errors are made instantly known to the ground station technician, providing themwith the capability to retransmit information or commands during a communications pass.
Future Work:
• Implement satellite control and command interface• Graphically create and upload communication schedule through DITL module• Implement an improved top-level application framework• Implement customizable user interface themes, layouts, and preferences
Abstract:
Upon initialization, the four modules (green), along with two packet listenerthreads (blue), are instantiated. During this instantiation, listener threads openand listen to their respective UDP ports (yellow). The modules are connected toeach other and the listener threads via signals and slots, a subscription-publication system native to the Qt framework that BARCoMmS was developed in.Connections are as follows:• Bulletin listens to CFDP for CFDP transaction information• Bulletin listens to Command for command PDUs• Bulletin listens to the Telemetry Packet Listener for Health and Status PDUs
and command acknowledgments• DITL listens to the Telemetry Packet Listener for Event PDUs• Telemetry Packet Listener listens on incoming FSW telemetry UDP port• Command Packet Listener listens on incoming external command UDP port• CFDP module connects to the FSW’s CFDP client through UDP port for CCSDS
space packet PDU transfers• Command sends command PDUs to FSW
Full arrows represent serial process flow. Diamonds represent slots; lines connecting to them represent signals.Dashed lines represent UDP port connections.
Acknowledgements:The intern group would like to thank mentors Scott Akridge, Jim Cecil, and especially Jamie Moyers for their support, guidance, and patience. We thank Tina Atchley for her support as our intern coordinator, and Daniel Heater for his generosity in selecting us for these positions.
