Automated Hardware
Testing Using Docker
for Space

Double Asteroid Redirection Test
DART

NASA Planetary Defense Coordination
Office
• DART is a tech demonstration to hit
a representative asteroid
• Mission managed by Johns
Hopkins Applied Physics Lab
• The PDCO is responsible for:
• Finding and tracking near-Earth objects
that pose of hazard of impacting Earth;
• Characterizing those objects
• Planning and implementation of
measures to deflect or disrupt an object
on an impact course with Earth

Step 1: Build the Spacecraft
Roll Out Solar Arrays
NEXT-C Ion Thruster
High Gain AntennaDRACO Imager

1. Launch 2. Cruise / Calibration 3. Target Detection
/ Coarse Acquisition
4. Scene Classification
5. Target Selection 6. Deploy
Selfie-Sat
8. Impact Assessment
Flyby of PHA allows sensor
calibration and control-gain
tuning
Seeker counts and classifies closely
spaced objects
With sufficient confidence, seeker selects
target and locks on
Earth tracking & Selfie-Sat images quantify
intercept success
Selfie-Sat releases and executes a separation
maneuver to trail DART
Weeks prior to impact, seeker
detects primary<7 months until impact>
<108 km from target>
<30 days until impact>
<107 km from target>
<3 hours until impact>
<65,000 km from target>
<1.5 hours until impact>
<32,000 km from target>
<~1.4 hour until impact>
<~30,000 km from target>
<Up to 3 months>
7. Homing Until Intercept
Pro-Nav executes precision engagement and is robust
to target uncertainties
<Executed until final 2 minutes>
<6.0 km/s Impact>
Low Energy Escape
With Rideshare
<Jun 15 – Oct 15 2021>
<108 km from target>
Rideshare
Orbit
* 16 months total flight time
Step 2: Hit the Target

Goddard Space Flight Center
Johnson Space Center
Langley Research Center
Glenn Research Center
Marshall Space Flight Center
Planetary Defense Coordination Office
Step 3: Save the World
(by validating the kinetic impact technique)

Why DockerCon?

Space is Hard!
All factors drive:
• Cost
• Reliability
• Low Memory (~16MB)
• No virtual memory
• 32 bit CPU (~100MHz)
• Process
• Testing. And more testing
Vacuum
Radiation
Extreme distances
(and timelines)
Power
Mass
Single shot
New Horizons - JHUAPL
There are no space mechanics (yet) and turning it off and on again is NOT cool
Infrequent Communication
Thermal

What Are We Trying to Solve?
Hardware Scarcity
• Testbeds cost > $300K
• Configuration management
is painful
• Every
developer/subsystem
wants one
What is the holy grail?
• Hardware emulation!
• Develop in software land
• Test on real hardware
• CD to other teams/real spacecraft

Enablers for DART
• NASA Core Flight Executive (Hardware/OS Abstraction)
• Atlassian Bamboo (CI/CD)
• Network architecture (SpaceWire)
• COSMOS (Ground System)
• Docker (Containers!)

Development Setup

Container Setup
• 4 repos - Flight SW, Testbed SW, COSMOS, Docker_Env
• 4 containers – Flight SW, Testbed SW, COSMOS, VNC
• Run-time voluming of source code, containers are stateless
• Provides outside dev environment with docker build capabilities
• Keeps cross-compile toolchains standardized

Docker Compose
Network Setup
• One instance comprises 4
containers (docker-compose)
• UDP SpaceWire abstraction
between FSW and TBSW
• TCP radio abstraction between
Ground and TBSW
• Xforwarding Ground to X11
Server to VNC
Flight Software
Container
VNC Container COSMOS Container
Testbed Container

VNC Window
• Shameless plug for the creator – thanks Jan!
• https://github.com/suchja/x11client
• https://github.com/suchja/x11server
• X11Server focuses on VNC and X setup
• X11Client focuses on the application (COSMOS)
• Brought up with compose, share xauth cookie through voluming
• Runs X virtual frame buffer with Openbox
• Contains the X security issues to the containers (we think)
X11Server
(container)
COSMOS
(container)
VNC Viewer
(dev machine)
Xauth

Demo

Recap
• DART
• Why is space hard?
• Voluming source code can be super helpful in development
• VNC finally provides an easy window into containers

The Final Moments…