By Jan Chodas
Dr. Scott Bolton, Juno’s principal investigator from the Southwest Research Institute, and the Juno team had been working toward this milestone for several years. A mission of this length and complexity required careful planning and testing to increase its chances of success. Everyone felt a great sense of accomplishment when, shortly after separating from the Centaur upper stage, the spacecraft deployed its large solar arrays as planned and began its journey to Jupiter.
The second mission in NASA’s New Frontiers Program, Juno experienced an unusually long definition and planning phase—described by Juno’s first project manager, Rick Grammier, in ASK Magazine’s Spring 2008 issue—that gave us several advantages, including more time to talk. This proved beneficial for a distributed team that included members from the Jet Propulsion Laboratory (JPL), Lockheed Martin, Goddard Space Flight Center, Southwest Research Institute, the Applied Physics Laboratory, University of Iowa, Malin Space Science Systems, the Italian Space Agency (ASI), and others. We were able to establish strong working relationships and excellent communication by having regular status telecons, workshops, and frequent in-person meetings.
These relationships helped tremendously during our risk-mitigation planning efforts, which included integrating instruments early on; working through issues such as the impact the L’Aquila, Italy, earthquake had on the Ka-band translator development; developing fallback options for Juno’s system-level environmental tests; and using an innovative tool to track our schedule margin.
Integrating Instruments Early
Early in the implementation phase, the Juno team performed interface tests at the Lockheed Martin facility between the engineering models (early versions of hardware) of each instrument’s electronics and the spacecrafts flight-like hardware. These early integrations helped find and fix hardware and software bugs in the interfaces, increasing the likelihood that flight-instrument integrations would proceed more smoothly.
Concerned about the possible late deliveries of the avionics and solar arrays, we also prepared a set of fallback options that gave us some flexibility for completing the tests successfully.
The first set of tests in spring 2009 between the instruments engineering models and the Data, Telemetry, and Command Interface (DTCI) Engineering Development Unit (EDU) board focused on confirming the compatibility of the commanding, engineering telemetry, low-speed science data, and high-speed science data hardware interfaces. These tests uncovered some issues early—such as the clock polarity coming out of the DTCI being inverted—and gave us confidence to move forward with the spacecraft and instrument flight builds. A side benefit was the establishment of an excellent working relationship between the instrument teams and the Lockheed Martin software, simulation, and instrument-integration team members, which was helpful throughout the implementation phase.
During the first part of 2010, instrument engineering models were sent to the Lockheed Martin facility’s System Test Lab for a second round of tests that focused on confirming higher-level functionality in the flight-software interface. Greg Bollendonk, the flight software lead, accelerated the development of the instrument-interface portions of the spacecraft flight software in order to deliver beta versions for these tests. Another goal was to flow data to each instrument’s ground-support equipment—as would be done during the assembly, test, and launch operations (ATLO) phase—to enable the instrument teams to become familiar with the data formats and ATLO processes. At the time, the spacecraft field-programmable gate arrays that controlled the instrument interfaces were not yet mature, so they benefited from this early testing as well.
More issues were uncovered and corrected, including significant ones in the high-speed data interface that required several months to resolve. One issue in this interface involved the spacecraft’s memory-management software. This spacecraft flight software wasn’t saving the highest-quality data for the ultraviolet spectrograph (UVS) instrument. The flight software team took advantage of the UVS engineering model in the System Test Lab to iterate code changes with remote support from the instrument team (located at Southwest Research Institute) until the problem was resolved. All in all, this risk mitigation program paid off in smoother flight-instrument integrations during ATLO.
New Frontiers Program Office Insight and Participation
By Brian Key
Juno benefited greatly from an extended definition and planning phase that gave the project team more time to talk.” This additional time also allowed the New Frontiers Program office to become more familiar with the mission definition and to independently assess the project’s planning activities. Understanding schedule and technical risks prior to confirmation also allowed the program office to develop a representative cost risk that could be carried as an unallocated future expense (UFE) by the Science Mission Directorate (SMD), and could be included in the overall life-cycle cost for the project at confirmation. This cost risk was established not only through understanding risks but also by examining previous mission performance histories to determine the soundness of the mission cost and schedule profiles.
Upon confirmation, NASA established a principal investigator cost cap and an overall project cost cap. Throughout implementation, the principal investigator (PI) and project manager managed to the tighter PI cost cap. allocations from the SMD-held UFE were controlled through a process established by the program office, which required the project to formally request a UFE allocation and provide a rationale for the request. The program office would evaluate this request and provide the Planetary Science Division (PSD) New Frontiers program executive with an assessment and recommendation.
Essential to this process was the well-established communication among the project, program office, and PSD. Open and candid communication and information flow between the project and program office mission manager gave all levels of NASA management a good understanding of the project’s status. This communication and information came in many forms, from monthly status meetings to weekly tag-ups to daily test status e-mails, intertwined with frequent, impromptu teleconferences.
As the project developed and implemented early risk mitigations, worked around impacts from natural disasters, and developed and executed alternate test flows and configurations due to component, instrument, or subsystem delays, these developments were communicated effectively and efficiently to the program office mission manager and PSD New Frontiers program executive.
Recovering from a Natural Disaster
ASI contributed two instruments to Juno’s payload: the Jovian infrared auroral mapper (JIRAM) and the Ka-band translator for the gravity science investigation. These contributions, added during the definition and planning phase, were not part of the original mission proposal. The ASI contribution gave us an alternate supplier for the Ka-band translator in the original proposal while the JIRAM instrument was completely new. One key feature of this arrangement was that neither of these contributions were required in order for Juno to satisfy its mission success criteria.
This decoupling helped when a magnitude 5.8 earthquake in L’Aquila, Italy, in April 2009 severely damaged the Thales Alenia Space plant where the Ka-band translators engineering model was being built. This natural disaster threw its development into disarray. Initially, the team had no idea what the impact would be on the model’s delivery, scheduled to happen by June 2009, or on the flight units delivery scheduled for December 2009.
Rick Nybakken, Juno’s deputy project manager and the prime project interface with ASI, led the development of a recovery plan that upgraded the engineering model to a flight quality unit (called the flyable engineering model, or FEM), enabling one unit to meet both delivery requirements. This higher-risk approach was acceptable because full performance from the Ka-band translator was not required for Juno to meet its success criteria. A flight unit would still be built and tested, and if it became available soon enough, we would consider it for flight. The FEM was delivered and installed in April 2010. When the flight unit became available in August 2010, we replaced the FEM with the flight unit due to its higher reliability and because we could still accommodate a swap at that late date.
Working through this difficult situation was helped by the excellent rapport that Scott, Rick, Dorothy Lewis (Ka-band translator cognizant engineer), and the project team had with ASI and Thales Alenia Space. Quarterly meetings helped foster this relationship. Rick had seen this model used successfully on the Cassini mission and set up a rotation of a core set of Juno personnel, both management and technical, that would travel to Italy every three months for management and technical discussions. The ASI/Thales Alenia team traveled to JPL occasionally for the same purpose.
The relationships established proved to be very useful when we worked with ASI and Thales Alenia to recover from the earthquake. The team worked closely with Roberto Formaro, ASI program manager for Juno, to align the project and ASI strategies for revised delivery requirements and tactical interactions with Thales Alenia. All Thales Alenia customers who had been affected by the earthquake were claiming priority in the recovery planning, but Junos only option to receive a flyable Ka-band translator in time for launch was to develop and implement a coordinated strategy among Juno, ASI, and Thales Alenia. Establishing a successful path forward might not have been possible without the meetings and resulting relationships established during the early part of development.
Having Preapproved Fallback Options
The system-level environmental test suite is a major test activity every spacecraft experiences during the ATLO phase. Its purpose is to subject the spacecraft to the environments it will experience during its mission. These environments include the vibration of launch (simulated by an acoustic test), the shock of separation from the launch vehicle, the spacecraft’s electromagnetic self-compatibility at launch and during science-data gathering, and the temperature in the vacuum of deep space that the spacecraft will experience on its trajectory to Jupiter. The Juno team planned a traditional set of tests involving the flight hardware and flight software and presented that baseline at the environmental test readiness review (ETRR).
Concerned about possible late deliveries of the avionics and solar arrays, we also prepared a set of fallback options that gave us some flexibility for completing the tests successfully. These options outlined the minimum set of hardware required for each test, including the required pedigree (flight or non-flight). For example, flight-like engineering models could be used for the self-compatibility tests if the flight avionics were not available, and the solar-array qualification model could be used for the shock test if the solar arrays had not yet been delivered. We also outlined specific vibration-level and thermal-cycle tests that would need to be executed to ensure the complete environmental qualification of the spacecraft if a flight-hardware component had to be reworked post-test. Preparing these fallback options ahead of time helped clarify and align our thinking for these anomalous situations.
These options were also presented at the ETRR and discussed openly with the review board. This up-front review minimized the management coordination the project needed later on when some of the options had to be implemented to complete the environmental tests within schedule.
“Stay in the Corridor”
Tim Halbrook, the Lockheed Martin ATLO manager, used typical schedule tools to track Juno’s progress: a sixteen-month ATLO flow updated monthly, a thirty-day Gantt chart updated weekly, and a seven-day Gantt chart updated daily. To plan and track the use of Juno’s sixty days of ATLO schedule margin, however, Tim also developed a Corridor plot (see figure at top of page). On the Corridor plot, the curve of schedule margin burndown—the rate at which margin is used up—corresponded with the margin days sprinkled strategically throughout the ATLO flow. Tim also included a second curve on the plot that was offset by 20 percent below the nominal curve. Juno’s actual schedule margin use was plotted weekly on the same figure.
If our actual margin burndown remained between these two curves, we did not need to take action. But if it dropped below the 20 percent margin erosion curve, Tim would schedule second shifts and/or weekend shifts to bring the actual burndown back within the corridor. Shortly after ATLO started, unplanned troubleshooting and rework with both the avionics and telecom hardware dropped the schedule margin close to the 20 percent margin erosion curve. We recovered schedule margin by using additional shifts once the issues had been worked through successfully.
This graphic became a handy visual tool for the whole team to monitor the schedule margin and to make decisions regarding resource control. It also enabled Juno managers and external managers to tell at a glance how ATLO was progressing.
An Excellent Beginning
Throughout Juno’s implementation phase, management teams at all levels looked for ways to help development proceed more smoothly and with lower risk, and the team as a whole worked through many challenges successfully. This was possible due to our strong working relationships and excellent communication, enhanced by the close communicative style of our project leaders. The result meant completing Juno on time and on budget, and its excellent flight performance so far shows the benefits of our efforts.
Note: This work was carried out at the Jet Propulsion Laboratory, California Institute of Technology, under a contract with the National Aeronautics and Space Administration. © California Institute of Technology. Government sponsorship acknowledged.
About the Author
 |
Jan Chodas is currently the project manager for the Juno mission in the New Frontiers Program. Prior to this position, she served at the Jet Propulsion Laboratory in numerous roles, including manager of the Systems and Software Division, assistant flight system manager for the Mars Exploration Rover project, flight system manager for the Space Interferometry Mission, project element manager for the Cassini attitude and articulation control subsystem, and technical manager for the Galileo attitude and articulation control subsystem. |
