II. Development Backdrop A. The Olden Days: One-offs and Cul-de-sacs Back in the time of large, unfriendly computers, commanding a spacecraft was a large and cumbersome process. One set of tools was needed to design science observations and another set created the commands to carry out those designs. Separately, flight software was developed to operate each spacecraft. Since each spacecraft was unique, its flight software was also unique. In some cases, flight software could be reprogrammed in flight, but it was an esoteric and risky process, usually reserved for extreme cases such as when the Galileo mission's high gain antenna became stuck in a partially opened position. Ground software and flight software were developed in parallel pre-launch but the development processes were decoupled, with separate teams, sets of requirements, and mindsets. Ground had no influence on flight, and flight had a tendency to overlook operations needs. The assembly and test phase of development often used a third set of tools until close to launch, leaving operators with little or no hands-on experience in using the flight system they would be responsible for keeping safe. Voyager, Galileo, Cassini, Mars Observer, and Magellan all were developed under this paradigm, with small advances from mission to mission. What heritage could be maintained was transmitted by personnel rather than by software reuse, and therefore was subject to loss by reassignment or retirement of personnel. In operations, those who moved among missions brought with them an understanding of what could be the same and what must be different from spacecraft to spacecraft. A consensus grew that rather than only bringing personnel experience forward, tools and systems should also be reused. During this period, space exploration budgets became tighter as well, and a shift from large flagship missions to smaller more agile missions began. B. Sea Change: The Multimission Mindset With the advent of the Pathfinder mission, JPL developed a wide range of new technologies for spaceflight: a base station / rover combination, airbags, use of a radiation-hardened processor similar to commercial PowerPC chips, and modularized flight code intended for easy reuse on future missions. Far from creating a one-off implementation, Pathfinder showed the multimission mindset taking hold.

No abstract

No abstract

Space flight missions are inherently risky. The mission operations assurance discipline grew out of strategies to control error and evolved into what today is an independent technical authority dedicated to achieving mission success. After the Mars Climate Orbiter loss, NASA made a set of recommendations for missions. Two of those recommendations led to the creation of today's Mission Operations Assurance Manager role: (1) require an independent Mission Assurance representative during the operational phase of every flight project, and (2) require all flight projects to report and track post-launch anomalies. Since then, the MOAM role has been continually refined by lessons learned from its practice on more than 20 concurrent missions. The MOAM role requires significant operations experience as well as an additional set of skills. In the interests of developing a cadre of potential MOAMs, the MOAM training program was developed. It is a 14-unit set of presentations/discussions covering the 11 categories of MOAM tasks. It is offered to new MOAMs and interested systems engineers with an eye to preparing both types of personnel for present and future assignments, as well as building relationships among personnel of different organizations. MOAM training sessions include presentations on the various tools and processes employed by MOAMs, interspersed with mindset lessons illustrated via "war story" discussions of previous missions.

The interface between a spacecraft and its ground operations segment includes the flow of commands, configuration, and sequencing elements to the spacecraft, and the flow of telemetry and data products from the spacecraft. Creating and implementing a complete definition of this interface simplifies and standardizes mission operations, allowing easy sharing of operations personnel across missions. Early spacecraft featured a simple flight / ground interface (FGI) using hardware command decoding in the radio, driven by technological limitations of the time. Modern spacecraft use command and data handling (CDH) avionics on which flight software executes, which in turn controls and configures the mission, executes subsystem and instrument instructions, and implements critical fault protection actions. Deep space missions feature advanced operations software for running sequenced activities over a period of weeks, which allows them to function with only infrequent ground contact. This approach comes at the cost of increased complexity in the FGI, requiring expensive modifications to heritage flight software and ground systems. By hosting the interface in the radio instead of the CDH avionics, modern missions can approximate the FGI design simplicity of early spacecraft, with significant advantages for vendor competition, lowered costs, standardization of operations, and reduction of implementation risk. I. Mission Operations Domainission operations for spacecraft involves both the uplink of products to the spacecraft and the return of mission data. Deep space mission operations may be viewed as a function of the mission objectives, and consists of three items, in priority order:1. Collect science data to achieve the mission objectives.