Jonathon Smith, Cassini Orbit Determination Analyst
JPL is widely regarded as the world leader in the field of Deep Space Navigation. Much of the spacecraft tracking technology and orbit estimation mathematics that are industry standard today were developed by JPL engineers the 1960s and 70s to support NASA’s early exploration of the solar system. Navigating through the solar system is a tricky business, and it is a field in continuous evolution.
At the heart of JPL’s navigation legacy is its navigation software suite, which is the embodiment of 50 years of know-how, developed for and tested by actual deep space missions. There is an iterative relationship between the engineers who build the navigation software tools and those of us on the frontline actually flying missions. Obviously, an operational navigator like me needs navigation software to fly a mission. Perhaps less apparent, the software engineers need us navigators to take their software through the ropes of a real mission, to ferret out the bugs, to stretch the software to its limits, and to request new features when it breaks. The end result of this loop is a robust software suite that has withstood the rigors of real space missions.
Cassini launched using what is now a legacy software set called the Double Precision Trajectory and Orbit Determination Program (DPTRAJ/ODP). However, beginning in 2008, Cassini Navigation started transitioning from that older software set to the next-generation software set, called the Mission-analysis, Operations, and Navigation Toolkit Environment, or MONTE. Since it is largely written in the popular programming language Python, it is often referred to as MONTE Python, a play on words to honor the hilarious British humor troupe Monty Python. MONTE was developed not as an incremental improvement to the JPL navigation software, but as a complete modernization and architectural paradigm shift in the way the navigation software works. The underlying software language and design was updated to bring it in sync with current industry standards. It is written in C++ and Python, updated from the legacy’s Fortran and C-Shell, and it is structured using an Object Oriented design for increased extensibility and easier maintenance. It was also an opportunity to refactor the legacy codebase, by looking at all the subroutines with 20/20 hindsight, and rearranging and updating them so that the software is more cohesive, logical and useful to the navigators.
This transition on Cassini from the legacy software to MONTE was challenging for several reasons. To appreciate the complexity, it is important to understand what JPL’s navigators actually do, and where the navigation software fits into this.
The first step to navigating in deep space is to solve the orbit determination problem. Radio signals from a spacecraft are received by NASA’s Deep Space Network and transformed into tracking data. Given this tracking data and our current best estimate for where the spacecraft is, we need to produce an updated best estimate.
The next step is maneuver design. Given our new estimate of where the spacecraft is from the OD solution, we have to design a maneuver to keep the spacecraft "on tour" and flying the designed reference trajectory. Due to limitations inherent in modeling spacecraft dynamics and implementing maneuvers, our knowledge of the spacecraft location deteriorates over time. Thus we need to close the loop by collecting additional tracking data and repeating this process as long as the mission is flying.
At the most basic level, the navigation software is meant to help a navigator go through this loop of solving the orbit determination problem and designing maneuvers. The JPL navigation software has evolved many more capabilities that allow it to be used in mission design, gravity science studies and much more.
Now, back to the specific difficulties we faced with the implementation on Cassini.
The first challenge in the Cassini navigation software transition was to configure and deploy MONTE and confirm that it had all the capabilities we needed to fly. As previously mentioned, it’s often impossible to build perfectly capable software from scratch; the developers depend on input from the navigators to tell them what additional capabilities are required. We also worked hard throughout this deployment process to uncover and fix bugs in the system that had not yet been caught. Every deep space mission is unique and stretches the navigation software in a slightly different way, and because of this, every mission is liable to encounter bugs that had previously been hidden.
Finally, once MONTE was deployed and functioning correctly, we had to perform detailed comparisons with the tried and true legacy software, and confirm that MONTE was producing consistent results.
What made this transition truly challenging was that all this deployment and comparison work was being performed while simultaneously flying an extremely aggressive operational flight profile. During the transition period, Cassini performed 38 fly-bys of Saturn’s largest moon, Titan, and 16 fly-bys of a smaller moon, icy Enceladus. In the final two years of the transition, when most of the software deployment work was happening, the navigation team concurrently designed more than 100 trajectory correction maneuvers! Also during the last two years of the transition, the navigation team was running in dual-operations mode, producing both legacy and MONTE solutions, essentially doubling the normal workload.
Finally, in January 2012, we stopped dual-operations and transitioned entirely to the MONTE Python navigation suite. So far, it has exceeded expectations. The transition was a challenging experience, but well worth it. It has not only been an opportunity to test and improve JPL’s next-generation navigation software, but it ensures that Cassini will have a state-of-the-art navigation toolkit to bring us all the way to mission end in 2017.