DASHER: Execution Software for Distributed Space Mission

AutonomyDr. Timothy Woodbury

Senior Aerospace Engineer

Acknowledgements

• DASHER was originally funded by NASA Goddard Space Flight Center as a Small Business Technology Transfer (STTR) contract

• Work on the STTR was performed in conjunction with the University of Pittsburgh at the National Science Foundation’s Center for Space, High-Performance, and Resilient Computing (SHREC); the Earth observing mission was generated by SHREC students Antony Gillette and Rachel Misbin

Outline

• Motivation

• Core software discussion

• Software implementation

• Cislunar mission example

• Distributed Earth observing mission example

• Summary

Motivation

Motivation: autonomy for distributed space missions

• Commercial small satellite (SmallSat) missions in low Earth orbit (LEO) increasingly common for communications & Earth observation [1]• SpaceX• OneWeb• BlackSky Global• Planet Labs

• Several recent and upcoming government missions involve coordinating spacecraft above LEO or in proximity operations• NASA: LunaNet• AFRL: CHPS

• Traditional operational paradigms do not scale well to these new missions• Transmission lag & expense• Human operator overload• Encoding commands by hand is tedious and error prone as fleet size increases

• Autonomy addresses/remedies some problems

[1] G. Curzi, D. Modenini, and P. Tortora, “Large constellations of small satellites: A survey of near future challenges and missions,” Aerospace, vol. 7, no. 9, 2020, doi: 10.3390/AEROSPACE7090133.

DASHER overview

• DASHER: Distributed Automation Suite for Heuristic Execution and Response• Software applications for event-driven,

distributed execution of a plan

• Hierarchical execution model with a centralized execution coordinator and distributed executors on each platform

• Core executors are finite-state machines with transitions triggered by telemetry

• Plans are provided from other apps before or during execution

1. Mission coordinator [Plan 1]2. Platform executor [Plan 2]3. Task queueing application

1. Platform executor [Plan 3]2. Task queueing application

1. Platform executor [Plan 4]2. Task queueing application

Core Software Discussion

Core applications and hierarchy

• Three core applications• Mission Manager – mission coordinator

• Interfaces with ground commands• Tasking/retasking platforms dynamically

• Execution Manager – platform executor• Timeline Manager – task queueing and

conflict management

• Supervision from central coordinator

• Platforms queue actions/commands locally• Each platform runs Execution and Timeline

Manager• One platform has an active Mission

Manager

Core Executor Software

• Mission Manager and Execution Manager use a common core software loop

• Each Executor follows a Plan that allows for customization between different missions

• Telemetry Processor is mission-specific and buffers messages that satisfy criteria of interest

Timeline Manager

• Timeline Manager (TM) implements a timeline of tasks to execute

• Manages based on resources, priority, and execution state

• Two types of external apps• Planners: generate tasks that need to be

executed• Workers: accept tasks to be done and

update their progress

• Timeline Manager publishes TaskResponse messages at the start of their time windows, deconflicts using priority and resource needs

Functional breakdown of Timeline Manager scheduling

Timeline Manager priority diagram

Plan

• A Plan specifies a finite state machine that defines agent response to telemetry from other apps

• Mission Manager and Execution Manager use Plans

• Three primitives• States indicate the current status of the system• Events triggered by telemetry of a certain type and

values • Commands are sent by the agent in response to an

Event or State change

• A Plan is an object that associates States, Events, and Commands• Each State and Event have associated Commands• Transitions define a switch from one State to

another in response to the occurrence of an Event

Software Implementation

Original design (STTR development)

• Initial DASHER software written as applications in NASA’s Core Flight System (cFS)

• 3 “layers” to code• Application: interfaces with the cFS

system directly, handles message pub/sub, etc

• Adaptor: receives cFS messages from application, removes metadata and sends “core” message to Service

• Service: primary functionality, e.g. state machine logic or task queueing engine

GEAR retrofit (present)

• GEAR: Generalized Environment for Architecture Reuse

• GEAR is Emergent’s solution to the existence of competing middlewares (ROS, cFS, Aspire, etc)

• GEAR defines a generic set of interfaces related to middleware functions (e.g. message pub/sub), with implementations for specific middleware

• The developer writes a GEAR app without worrying about glue code

• GEAR provides a backend that interfaces with the chosen middleware

• For a new middleware → write a GEAR interface, all core flight software apps are available!

Cislunar Mission Example

Scenario

• Single autonomous spacecraft on approach to the Moon

• Spacecraft simulation (and visualization) using Emergent’sASCENT simulation

• Two helper cFS applications interface ASCENT with DASHER apps

• DASHER Plan is pre-programmed with target coordinates and associated delta-V to circularize the orbit

DASHER mission design

• MM monitors the navigation state and sends a command to EM if the desired circular polar orbit is achieved

• EM monitors the navigation state and performs a pre-programmed delta-V to circularize the orbit when target coordinates are reached

• TM receives a Task from EM and puts its associated data on the software bus as a message; it is received and sent to the ASCENT simulation

Execution ManagerMission Manager

Video

Distributed Earth Observing Mission Example

Scenario

• Cluster of four Earth observing satellites

• Ten arbitrarily chosen targets that should be imaged

• MM assigns targets to spacecraft based on proximity, and reassigns targets to second-closest, third-closest, etc. if there’s no response from initial assignee

• Simulation is conducted in 42

• DASHER executes on ARM PYNQ-Z2 boards on a shared network

PYNQ board cluster

42 simulation image

DASHER mission design

• Helper app knows the target locations and tracks satellite positions

• Helper app notifies MM when a target is in range

• MM sends a message commanding the closest SV to image the target• If the SV is online, its EM receives the

message, takes the image, and sends a response

• If MM does not receive a response, it sends a message commanding the second-closest SV, and so on

• About 30% through the mission, spacecraft 2 drops out just before capturing target• MM assigns different spacecraft (3) to

capture target

• About 60% through the mission, spacecraft 3 drops out just before capturing target• Again, MM assigns different spacecraft

(1) to capture target

Video

Summary

Summary

• DASHER: flight software for autonomous execution of a plan

• Originally a suite of cFS apps; currently exists as a GEAR application with support for multiple MOSAs

• Demonstrated DASHER in the loop for simple missions in ASCENT and 42

Backup

Mission Manager

• Mission Manager (MM) coordinates fleet activities• Platform status updates

• Ground commands

• Mission Manager follows a Plan that allows for customization between different missions

• Telemetry Processor is mission-specific and buffers messages that satisfy criteria of interest

Execution Manager

• Execution Manager (EM) oversees activities of a single platform

• Shared core software with Mission Manager• Plan binary

• Telemetry Processor

Telemetry processing

• Telemetry Processor receives messages sent to an EM or MM instance and buffers messages that satisfy conditions of interest

• Buffered telemetry keys trigger Events in the state machine logic

• Telemetry Processor is hand-coded

• A telemetry buffer stores messages based on their message ID with an attached key

• An Event is associated with the occurrence of one or more instances of a key in the telemetry buffer