dragREPORT software was developed in parallel with abmREPORT, which is described in the preceding article. Both programs were built on the capabilities created during that process. This tool generates a drag_pass report that summarizes vital information from the MRO aerobreaking drag_pass build process to facilitate both sequence reviews and provide a high-level summarization of the sequence for mission management. The script extracts information from the ENV, SSF, FRF, SCMFmax, and OPTG files, presenting them in a single, easy-to-check report providing the majority of parameters needed for cross check and verification as part of the sequence review process. Prior to dragReport, all the needed information was spread across a number of different files, each in a different format. This software is a Perl script that extracts vital summarization information and build-process details from a number of source files into a single, concise report format used to aid the MPST sequence review process and to provide a high-level summarization of the sequence for mission management reference. This software could be adapted for future aerobraking missions to provide similar reports, review and summarization information.
This software provides a new capability for landed Mars assets to perform forward link relay through the Mars Express (MEX) European Union orbital spacecraft. It solves the problem of standardizing the relay interface between lander missions and MEX. The Mars Operations Relay Service (MaROS) is intended as a central point for relay planning and post-pass analysis for all Mars landed and orbital assets. Through the first two phases of implementation, MaROS supports relay coordination through the Odyssey orbiter and the Mars Reconnaissance Orbiter (MRO). With this new software, MaROS now fully integrates the Mars Express spacecraft into the relay picture. This new software generates and manages a new set of file formats that allows for relay request to MEX for forward and return link relay, including the parameters specific to MEX. Existing MEX relay planning interactions were performed via email exchanges and point-to-point file transfers. By integrating MEX into MaROS, all transactions are managed by a centralized service for tracking and analysis. Additionally, all lander missions have a single, shared interface with MEX and do not have to integrate on a mission-by mission basis. Relay is a critical element of Mars lander data management. Landed assets depend largely upon orbital relay for data delivery, which can be impacted by the availability and health of each orbiter in the network. At any time, an issue may occur to prevent relay. For this reason, it is imperative that all possible orbital assets be integrated into the overall relay picture.
The Mars Science Laboratory (MSL) mission landed the Curiosity Rover on the surface of Mars on August 6, 2012, beginning a one-Martian-year primary science mission. An international network of Mars relay orbiters, including NASA's 2001 Mars Odyssey Orbiter (ODY) and Mars Reconnaissance Orbiter (MRO), and ESA's Mars Express Orbiter (MEX), were positioned to provide critical event coverage of MSL's Entry, Descent, and Landing (EDL). The EDL communication plan took advantage of unique and complementary capabilities of each orbiter to provide robust information capture during this critical event while also providing low-latency information during the landing. Once on the surface, ODY and MRO have provided effectively all of Curiosity's data return from the Martian surface. The link from Curiosity to MRO incorporates a number of new features enabled by the Electra and Electra-Lite software-defined radios on MRO and Curiosity, respectively. Specifically, the Curiosity-MRO link has for the first time on Mars relay links utilized frequency-agile operations, data rates up to 2.048 Mb/s, suppressed carrier modulation, and a new Adaptive Data Rate algorithm in which the return link data rate is optimally varied throughout the relay pass based on the actual observed link channel characteristics. In addition to the baseline surface relay support by ODY and MRO, the MEX relay service has been verified in several successful surface relay passes, and MEX now stands ready to provide backup relay support should NASA's orbiters become unavailable for some period of time.
The Phoenix Lander, first of NASA's Mars Scout missions, arrived at the Red Planet on May 25, 2008. From the moment the lander separated from its interplanetary cruise stage shortly before entry, the spacecraft could no longer communicate directly with Earth, and was instead entirely dependent on UHF relay communications via an international network of orbiting Mars spacecraft, including NASA's 2001 Mars Odyssey (ODY) and Mars Reconnaissance Orbiter (MRO) spacecraft, as well as ESA's Mars Express (MEX) spacecraft. All three orbiters captured critical event telemetry and/or tracking data during Phoenix entry, descent and landing. During the Phoenix surface mission, ODY and MRO provided command and telemetry services, far surpassing the original data return requirements. The availability of MEX as a backup relay asset enhanced the robustness of the overall relay plan. In addition to telecommunications services, Doppler tracking observables acquired on the UHF link yielded a highly accurate position for the Phoenix landing site.
The Mission Management Office at the Jet Propulsion Laboratory was tasked with coordinating the relay of data between multiple spacecraft at Mars in support of the Mars exploration rover missions in early 2004. The confluence of three orbiters (Mars Global Surveyor, Mars Odyssey, and Mars Express), two rovers (Spirit and Opportunity), and one lander (Beagle 2) has provided a challenging operational scenario that required careful coordination between missions to provide the necessary support and to avoid potential interference during simultaneous relay sessions. As these coordination efforts progressed, several important lessons were learned that should be applied to future Mars relay activities.
Version 5.0 of the AutoGen software has been released. Previous versions, variously denoted Autogen and autogen, were reported in two articles: Automated Sequence Generation Process and Software (NPO-30746), Software Tech Briefs (Special Supplement to NASA Tech Briefs), September 2007, page 30, and Autogen Version 2.0 (NPO- 41501), NASA Tech Briefs, Vol. 31, No. 10 (October 2007), page 58. To recapitulate: AutoGen (now signifying automatic sequence generation ) automates the generation of sequences of commands in a standard format for uplink to spacecraft. AutoGen requires fewer workers than are needed for older manual sequence-generation processes, and greatly reduces sequence-generation times. The sequences are embodied in spacecraft activity sequence files (SASFs). AutoGen automates generation of SASFs by use of another previously reported program called APGEN. AutoGen encodes knowledge of different mission phases and of how the resultant commands must differ among the phases. AutoGen also provides means for customizing sequences through use of configuration files. The approach followed in developing AutoGen has involved encoding the behaviors of a system into a model and encoding algorithms for context-sensitive customizations of the modeled behaviors. This version of AutoGen addressed the MRO (Mars Reconnaissance Orbiter) primary science phase (PSP) mission phase. On previous Mars missions this phase has more commonly been referred to as mapping phase. This version addressed the unique aspects of sequencing orbital operations and specifically the mission specific adaptation of orbital operations for MRO. This version also includes capabilities for MRO s role in Mars relay support for UHF relay communications with the MER rovers and the Phoenix lander.
A computer program called dsn config converter automates what had been a manual process for updating the multimission adaptation file (multi.aaf) used by a multiple-mission-command-sequence-generating process comprised of a combination of the AUTOGEN and APGEN programs mentioned in the immediately preceding article. The program converts the dsn_config.cvf file that provides DSN (Deep Space Network) antenna configuration code mappings from a context variable file (CVF) format used in another part of the command generation process to an APGEN activity file (AAF) format used by AUTOGEN and APGEN. Whereas previously, the information in the dsn_config.cvf file was manually encoded into the multi.aaf file, now the program automatically generates a dsn_config.aaf file from the dsn_config.cvf file. As part of this development effort the multi.aaf file was adapted to use the new dsn_config.aaf representations. Through this automation a tedious error-prone step has now been replaced by a quick and robust step.
The Mars Phoenix Lander arrived at Mars in May of 2008. Relying exclusively upon the Mars 2001 Odyssey spacecraft and the Mars Reconnaissance Orbiter to transmit operations data to and from Earth, the Phoenix project recently concluded a highly successful mission, having confirm ed the presence of water ice on the surface of Mars . Al most al l of the scientific and operational data acquired by the vehicle was relayed to Earth by the two orbiting assets. This report outlines some of the experiences of the Mars Reconnaissance Orbiter project in pr eparing for the arrival of Phoenix at Mars and the support provided to the lander after arrival. Strategies and lessons for successfully operating a relay network are iterated w ith discussion on the successes and failure s of the Mars Reconnaissance Orbite r project and the remainder of the “Mars Network” to implement them. Finally, results of the operational experience are tabulated and discussed. I. The 2008 Mars Relay Network URING the middle of 2008 , there w ere six spacecraft at Mars that could communica te with each other in a “relay network,” as in Fig . 1. The twin Mars Exploration Rovers ( MERs ), Spirit and Opportunity, arrived at Mars in January 2004, and they have been relaying data to Earth via the Mars 2001 Odyssey orbiter since that time. The Mars Express Orbiter has been in orbit at Mars since just before the arrival of the rovers and has performed several relay tests with the m, but has not served as a primary relay asset. The Mars Reconnaissance Orbiter (MRO) arrived at Mars in 2005 and has rece ntly concluded its primary science mission , but it has not to date been providing primary relay support for either of the rovers . Most recently, the Phoenix lander arrived in May of 2008 and utilized both Odyssey and MRO for primary relay operations durin g its five month mission . This paper outlines the experience of the MRO project as it relates to preparing for the arrival of the Phoenix lander at Mars, recording data as transmitted from the lander during its entry, descent, and landing (EDL) on Mars; an d serving as a relay asset to Phoenix throughout its surface mission. The challenges of clearly defining the interface s between the projects, the test strategy and schedule for ensuring these interfaces, and the actual support plans will be outlined. In addition, the as -flown experience of supporting the Phoenix lander during its mission, along with technical issues that were encountered and addressed will be discussed. Interspersed throughout this paper are lessons that were initially documented shortly after Spirit and Opportunity landed on Mars about ways to improve relay operations. The reader is encouraged to review that earlier report (see Ref. 2) to learn more about the context in which the lessons were generated. This paper will comment on those lessons with an eye towards further improvement for future Mars relay network activities. Finally, several new lessons that were learned from the 2008 experience will be outlined.
This software analyzes Mars Reconnaissance Orbiter (MRO) orbital geometry with respect to Mars Exploration Rover (MER) contact windows, and is the first tool of its kind designed specifically to support MRO-MER interface coordination. Prior to this automated tool, this analysis was done manually with Excel and the UNIX command line. In total, the process would take approximately 30 minutes for each analysis. The current automated analysis takes less than 30 seconds. This tool resides on the flight machine and uses a PHP interface that does the entire analysis of the input files and takes into account one-way light time from another input file. Input flies are copied over to the proper directories and are dynamically read into the tool s interface. The user can then choose the corresponding input files based on the time frame desired for analysis. After submission of the Web form, the tool merges the two files into a single, time-ordered listing of events for both spacecraft. The times are converted to the same reference time (Earth Transmit Time) by reading in a light time file and performing the calculations necessary to shift the time formats. The program also has the ability to vary the size of the keep-out window on the main page of the analysis tool by inputting a custom time for padding each MRO event time. The parameters on the form are read in and passed to the second page for analysis. Everything is fully coded in PHP and can be accessed by anyone with access to the machine via Web page. This uplink tool will continue to be used for the duration of the MER mission's needs for X-band uplinks. Future missions also can use the tools to check overflight times as well as potential site observation times. Adaptation of the input files to the proper format, and the window keep-out times, would allow for other analyses. Any operations task that uses the idea of keep-out windows will have a use for this program.
The Mars Reconnaissance Orbiter (MRO) and other JPL -operated deep space missions have achieved a reduction of operations complexity through the use of a non -interactive payload commanding paradigm. Traditionally, science p ayload commanding has been integrated with the commanding required to perform the engineering functions of the spacecraft. By operating the spacecraft such that much of the science commanding is performed independent of the rest of the vehicle, the science teams are empowered to freely operate their instruments and acquire their science data. Similarly, routine vehicle management, such as communication s, attitude control, and health and safety diagnostics; are performed by the engineering teams indep endently of the science teams. Non -Interactive Payload Commands (NIPCs) are command products that have been predetermined to be benign in nature with respect to the health and safety of the spacecraft . This paper present s pros and cons of using such an operating paradigm, identify up -front mission and spacecraft design implications, and demonstrate how MRO has benefited from t his design decision. I. Introduction N an era of heavily constrained budgets, N ational Aeronautics and Space Administration (N ASA ) has looked for ways to reduce mission cost through a reduction in operations complexity. With many recent missions over - ac hieving their mission objectives and mission life span, the se savings can be fur ther realized during commonly occurring extended missions . One approach many deep space missions operated by the Jet Propulsion Laboratory (JPL ) have pursued is the use of a no n-interactive payload commanding paradigm. This paradigm assumes that much of the science commanding may be performed independent of the rest of the vehicle, and th at th e management of routine vehicle functions , such as communications, attitude control, an d health and safety diagnostics ; may be performed independently of the science commanding . By partitioning the problem in this way and removing much of the interaction between these two spacecraft functions, a significant reduction of operational complexit y is achieved. A large part of this paradigm is the use of Non -Interactive Payload Commands (NIPCs), which are command products that have been predetermined to be benign in nature, with respect to the health and safety of the spacecraft . In operations, the y may be used without being subject to the same rigorous test and approval process to which typical engineering commands are exposed. By confining the NIPCs to a strict operational envelope, the science teams are given significantly freedom to operate thei r own instruments without risking the remainder of the flight system; as part of this functionality the science teams take responsibility for the correctness and safety of their commands. When this division is performed effectively, both the engineering an d the science teams can complete their objectives with minimal impacts to each other, thus reducing the necessary interaction between the teams and the overall cost and complexity of mission operations. The NIPC paradigm itself may not be applicable to all mission types. In the remainder of this paper, we will compare and contrast the operations concepts of several operating deep space missions and detail the NIPC concept. We will also present pros and cons of using such an operating paradigm, identify up -front mission and spacecraft design implications, and specify how the Mars Reconnaissance Orbiter ( MRO ) has embraced this concept. Finally, we will suggest how the NIPC concept might further evolve to offer a greater reduction of operations cost and comple xity, while potentially increasing a mission's capability to perform its objectives.
