Automating the Deep Space Network: Testing the Way to Saturn

I have to confess, this is a convergence of my interests. I am a huge fan of space travel and the challenges that space travel and exploration face fascinate me. Thus, I had to make a point to attend Andrea Connell’s talk “Testing Through Time and Space: NASA’s Twenty Year Mission to Saturn”. 

Twenty years of Cassini mission.

I must admit that I listened wistfully to learn that Cassini is running out of fuel and is scheduled to do its final maneuvers in the next couple of months. It will do its final orbit and enter Saturn’s atmosphere and be incinerated.

Cassini launched in 1997 and thus all of the tech on Cassini was developed prior to and up to 1997. In addition, there is a lot of inheritance from previous missions and limits to interacting with the systems, so developing software for this environment has some unique constraints that more modern development wouldn’t have. An example of unique environmental testing was Thermal Modeling. By the virtue of the spacecraft and its location, solar radiation can affect the components of the Cassini spacecraft, so interactions with the spacecraft need to take thermal modeling into account. Where the spacecraft is located in its orbit, there are variations to how much solar energy will be provided, and the way that the spacecraft’s controls and instruments will respond based on the variation of that solar radiation.

Andrea Connell
Software Engineer, Jet Propulsion Laboratory

One question I’m sure you all must be asking is “how does one actually test this stuff?” This is definitely an environment where “testing in production” is not encouraged, rather there are a variety of integration and staging environments to perform tests on. Additionally, testing has to be very carefully calibrated to make sure that the systems will work as expected. Bugs in the production code could have disastrous results.

One interesting approach that was modified was to create a test harness that focused on component level tests, rather than trying to test the entire system comprehensively. They used ground systems to simulate the transactions and try out the maneuvers. This is especially important since instructions sent to Cassini takes about 90 minutes to get there, and then another 90 minutes to receive a response/confirmation. Also, if something goes wrong, it’s very hard to correct issues, especially if issues change orbit trajectories, but local testing helps to minimize errors.

Andrea highlighted some gains they have made in their testing over the past few years that have accelerated their work. Tests used to take two weeks, but they have now brought that time down to about one day, due to hardware and software advances. they also developed new ways to test and try out scenarios that previously would have been difficult to impossible. Even if unit tests were not feasible, they could still do automated tests. Additionally, they realized that seeking perfection was not going to be an option, but any ways to improve were good, even if those gains were small.