SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
The paper will then propose extending this multi-mission philosophy to skeleton timeline development, science sequencing, and spacecraft sequencing. Finally, the paper will investigate a multi-mission approach to MOS development.
Automatic Sequence Generator (Autogen) Version 3.0 software automatically generates command sequences for the Mars Reconnaissance Orbiter (MRO) and several other JPL spacecraft operated by the multi-mission support team. Autogen uses standard JPL sequencing tools like APGEN, ASP, SEQGEN, and the DOM database to automate the generation of uplink command products, Spacecraft Command Message Format (SCMF) files, and the corresponding ground command products, DSN Keywords Files (DKF). Autogen supports all the major multi-mission mission phases including the cruise, aerobraking, mapping/science, and relay mission phases. Autogen is a Perl script, which functions within the mission operations UNIX environment. It consists of two parts: a set of model files and the autogen Perl script. Autogen encodes the behaviors of the system into a model and encodes algorithms for context sensitive customizations of the modeled behaviors. The model includes knowledge of different mission phases and how the resultant command products must differ for these phases. The executable software portion of Autogen, automates the setup and use of APGEN for constructing a spacecraft activity sequence file (SASF). The setup includes file retrieval through the DOM (Distributed Object Manager), an object database used to store project files. This step retrieves all the needed input files for generating the command products. Depending on the mission phase, Autogen also uses the ASP (Automated Sequence Processor) and SEQGEN to generate the command product sent to the spacecraft. Autogen also provides the means for customizing sequences through the use of configuration files. By automating the majority of the sequencing generation process, Autogen eliminates many sequence generation errors commonly introduced by manually constructing spacecraft command sequences. Through the layering of commands into the sequence by a series of scheduling algorithms, users are able to rapidly and reliably construct the desired uplink command products. With the aid of Autogen, sequences may be produced in a matter of hours instead of weeks, with a significant reduction in the number of people on the sequence team. As a result, the uplink product generation process is significantly streamlined and mission risk is significantly reduced. Autogen is used for operations of MRO, Mars Global Surveyor (MGS), Mars Exploration Rover (MER), Mars Odyssey, and will be used for operations of Phoenix. Autogen Version 3.0 is the operational version of Autogen including the MRO adaptation for the cruise mission phase, and was also used for development of the aerobraking and mapping mission phases for MRO.
Tbe Vision for Space Exploration calls for an aggressive sequence of robotic missions beginning in 2008 to prepare for a human return to the Moon by 2020, with the goal of establishing a sustained human presence beyond low Earth orbit. A key enabler of exploration is reliable, available communication and navigation capabilities to support both human and robotic missions. An adaptable, sustainable communication and navigation architecture has been developed by Goddard Space Flight Center and the Jet Propulsion Laboratory to support human and robotic lunar exploration through the next two decades. A key component of the architecture is scalable deployment, with the infrastructure evolving as needs emerge, allowing NASA and its partner agencies to deploy an interoperable communication and navigation system in an evolutionary way, enabling cost effective, highly adaptable systems throughout the lunar exploration program.
The Space Infrared Telescope Facility (SIRTF) was launched in August, 2003, and renamed to the Spitzer Space Telescope in 2004. Two years of observing the universe in the wavelength range from 3 to 180 microns has yielded enormous scientific discoveries. Since this magnificent observatory has a limited lifetime, maximizing science viewing efficiency (ie, maximizing time spent executing activities directly related to science observations) was the key operational objective. The strategy employed for maximizing science viewing efficiency was to optimize spacecraft flexibility, adaptability, and use of observation time. The selected approach involved implementation of a multi-engine sequencing architecture coupled with nondeterministic spacecraft and science execution times. This approach, though effective, added much complexity to uplink operations and sequence development. The Jet Propulsion Laboratory (JPL) manages Spitzer s operations. As part of the uplink process, Spitzer s Mission Sequence Team (MST) was tasked with processing observatory inputs from the Spitzer Science Center (SSC) into efficiently integrated, constraint-checked, and modeled review and command products which accommodated the complexity of non-deterministic spacecraft and science event executions without increasing operations costs. The MST developed processes, scripts, and participated in the adaptation of multi-mission core software to enable rapid processing of complex sequences. The MST was also tasked with developing a Downlink Keyword File (DKF) which could instruct Deep Space Network (DSN) stations on how and when to configure themselves to receive Spitzer science data. As MST and uplink operations developed, important lessons were learned that should be applied to future missions, especially those missions which employ command-intensive operations via a multi-engine sequence architecture.
Jet Propulsion Laboratory uses multi-mission software produced by the Mission Planning and Sequencing (MPS) team to process, simulate, translate, and package the commands that are sent to a spacecraft. MPS works under the auspices of the Multi-Mission Ground Systems and Services (MGSS). This software consists of nineteen applications that are in maintenance. The MPS software is classified as either class B (mission critical) or class C (mission important). The scheduling of tasks is difficult because mission needs must be addressed prior to performing any other tasks and those needs often spring up unexpectedly. Keeping track of the tasks that everyone is working on is also difficult because each person is working on a different software component. Recently the group adopted the Scrum methodology for planning and scheduling tasks. Scrum is one of the newer methodologies typically used in agile development. In the Scrum development environment, teams pick their tasks that are to be completed within a sprint based on priority. The team specifies the sprint length usually a month or less. Scrum is typically used for new development of one application. In the Scrum methodology there is a scrum master who is a facilitator who tries to make sure that everything moves smoothly, a product owner who represents the user(s) of the software and the team. MPS is not the traditional environment for the Scrum methodology. MPS has many software applications in maintenance, team members who are working on disparate applications, many users, and is interruptible based on mission needs, issues and requirements. In order to use scrum, the methodology needed adaptation to MPS. Scrum was chosen because it is adaptable. This paper is about the development of the process for using scrum, a new development methodology, with a team that works on disparate interruptible tasks on multiple software applications.
The traditional form of spacecraft commanding is with sequences that specify when commands should execute based on a schedule generated on the ground. Some sequences have control logic and event driven responses to increase flexibility, but it is limited. An approach to increase autonomy is to use goal-based planning and commanding. Using this paradigm, intention and behavior is modeled on board the spacecraft. In this paper we describe MEXEC (Multi-mission EXECutive), a multi-mission, task-based, onboard planning and execution software designed specifically to be used as flight software. As a path to infusion for future flight projects, we describe two experiments performed on the ASTERIA CubeSat and testbed that demonstrate that MEXEC can be integrated and used for spacecraft operations and increase robustness and science return compared to the standard sequences that were being used.
The Standard Power Regulator Unit (SPRU) which forms the central building block of the Modular Power Subsystem (MPS) for the Multi-mission Modular Spacecraft (MMS) is described. A functional description of the SPRU is presented, detailing key design features, operational characteristics, and internal redundancy as well as giving block and schematic diagrams for all major subassemblies. The description of a qualification test program consisting of ten sequences ranging from a physical examination of the unit to calculating vibration and sine sweep of power on shock tests is presented. The results showed that some significant anomalies were encountered but no catastrophic failures were indicated, although several power module failures were found due to overvoltage malfunctions of the solar array stimulator.
A multi-mission approach to solving the same problems for various projects is enticing. However, the multi-mission approach leads to the need to develop a configurable, adaptable and distributed system to meet unique project requirements. That, in turn, leads to a set of challenges varying from handling synchronization issues to coming up with a smart design that allows the "unknowns" to be decided later. This paper discusses the challenges that the Multi-mission Automated Task Invocation Subsystem (MATIS) team has come up against while designing the distributed workflow system, as well as elaborates on the solutions that were implemented. The first is to design an easily adaptable system that requires no code changes as a result of configuration changes. The number of formal deliveries is often limited because each delivery costs time and money. Changes such as the sequence of programs being called, a change of a parameter value in the program that is being automated should not result in code changes or redelivery.
Mission operations are presented for comet rendezvous and outer planet exploration NEP spacecraft employing in-core thermionic reactors for electric power generation. The selected reference missions are the Comet Halley rendezvous and a Jupiter orbiter at 5.9 planet radii, the orbit of the moon Io. The characteristics of the baseline multi-mission NEP spacecraft are presented and its performance in other outer planet missions, such as Saturn and Uranus orbiters and a Neptune flyby, are discussed. Candidate mission operations are defined from spacecraft assembly to mission completion. Pre-launch operations are identified. Shuttle launch and subsequent injection to earth escape by the Centaur D-1T are discussed, as well as power plant startup and the heliocentric mission phases. The sequence and type of operations are basically identical for all missions investigated.
Since Mariner, NASA-JPL planetary missions have been supported by ground software to plan and design remote sensing science observations. The software used by the science and sequence designers to plan and design observations has evolved with mission and technological advances. The original program, PEGASIS (Mariners 4, 6, and 7), was re-engineered as POGASIS (Mariner 9, Viking, and Mariner 10), and again later as POINTER (Voyager and Galileo). Each of these programs were developed under technological, political, and fiscal constraints which limited their adaptability to other missions and spacecraft designs. Implementation of a multi-mission tool, SEQ POINTER, under the auspices of the JPL Multimission Operations Systems Office (MOSO) is in progress. This version has been designed to address the limitations experienced on previous versions as they were being adapted to a new mission and spacecraft. The tool has been modularly designed with subroutine interface structures to support interchangeable celestial body and spacecraft definition models. The computational and graphics modules have also been designed to interface with data collected from previous spacecraft, or on-going observations, which describe the surface of each target body. These enhancements make SEQ POINTER a candidate for low-cost mission usage, when a remote sensing science observation design capability is required. The current and planned capabilities of the tool will be discussed. The presentation will also include a 5-10 minute video presentation demonstrating the capabilities of a proto-Cassini Project version that was adapted to test the tool. The work described in this abstract was performed by the Jet Propulsion Laboratory, California Institute of Technology, under contract to the National Aeronautics and Space Administration.
A key component of JPL's strategy to make space missions faster, better and cheaper is the Advanced Multi-Mission Operations System (AMMOS), a ground software intensive system currently in use and in further development. AMMOS intends to eliminate the cost of re-engineering a ground system for each new JPL mission. This paper discusses SEQ-REVIEW, a component of AMMOS that was designed to facilitate and automate the task of reviewing and checking spacecraft sequences. SEQ-REVIEW is a smart browser for inspecting files created by other sequence generation tools in the AMMOS system. It can parse sequence-related files according to a computer-readable version of a 'Software Interface Specification' (SIS), which is a standard document for defining file formats. It lets users display one or several linked files and check simple constraints using a Basic-like 'Little Language'. SEQ-REVIEW represents the first application of the Quality Function Development (QFD) method to sequence software development at JPL. The paper will show how the requirements for SEQ-REVIEW were defined and converted into a design based on object-oriented principles. The process starts with interviews of potential users, a small but diverse group that spans multiple disciplines and 'cultures'. It continues with the development of QFD matrices that related product functions and characteristics to user-demanded qualities. These matrices are then turned into a formal Software Requirements Document (SRD). The process concludes with the design phase, in which the CRC (Class, Responsibility, Collaboration) approach was used to convert requirements into a blueprint for the final product.
Japan's Institute of Space and Astronautical Science (ISAS) launched Nozomi, its first mission to the planet Mars using the newly developed M-V launch vehicle on July 3, 1998. Scientific objectives of the mission are to study the structure and dynamics of the Martian upper atmosphere and its interaction with the solar wind. Nozomi is a cooperative mission between ISAS and the National Aeronautics and Space Administration (NASA). The NASA contribution includes navigation and tracking services provided by the Jet Propulsion Laboratory (JPL). The spacecraft also serves as an engineering demonstration of basic technology for planetary exploration. One of the new technologies was a unique trajectory, developed by ISAS, which used solar gravitational perturbations at the weak stability boundary as an aid to achieve an Earth-Mars transfer orbit. This trajectory saves approximately 120 m/s of Delta V compared to direct hyperbolic insertion and is considered an enabling technology for the mission. Nozomi was the first spacecraft to employ this trajectory and provided on-orbit validation of the technique. The trajectory was achieved by initially placing the spacecraft in a highly elliptical cis-lunar phasing orbit. Six maneuvers were performed during this period to correct injection errors and target an outbound lunar swingby in September 1998. The gravity assist from the lunar swingby raised apogee to the vicinity of the weak stability boundary. After three more targeting maneuvers, Nozomi performed an inbound lunar swingby followed immediately by a powered Earth swingby in late December 1998. A 420 m/s Trans Mars Insertion (TMI) burn at the final Earth periapsis was intended to place the spacecraft on a heliocentric trajectory leading to Mars orbit insertion in October 1999. Orbit determination for Nozomi is performed in parallel by both ISAS and the Multi-Mission Navigation (MMNAV) group at JPL. This was an advantage for the mission because each group would generate solutions based on data collected from their respective tracking networks. Spacecraft events, such as sequence uplinks and maneuvers, were generally scheduled during passes at the Usuda tracking station in Japan. As a result, maneuver design and reconstruction was derived from MMNAV solutions based on JPL tracking data obtained immediately prior to or following maneuvers. Data was also exchanged between ISAS and MMNAV so orbit determination could be performed on joint data sets in support of critical targeting late in the cis-lunar phase. In this paper, information regarding the MMNAV orbit determination effort for the first six months of the mission is presented. The spacecraft trajectory is characterized first, followed by a discussion of the orbit determination estimation procedure and models. Results from selected orbit solutions are presented and compared against reconstructed trajectories. One area of emphasis in this paper is orbit determination in the vicinity of the weak stability boundary. Precise navigation was necessary to target the second lunar swingby and the powered Earth swingby. Delivery accuracy of 150 m was required for these critical encounters, but a number of factors contributed to the general degradation of orbit determination accuracy. This included the fact that the spacecraft was at apogee, at a range of 1.7 million km and moving at less than I km/sec perpendicular to the line of sight. Nozomi was also close to zero degrees declination where there are known limitations on orbit determination performance. Finally, S-band tracking data was acquired through the Nozomi backup low gain antenna. This antenna is offset from the axis of this spin stabilized spacecraft and superimposed large signatures in the Doppler and range data. These difficulties were overcome by combining long data arcs, spanning several maneuvers, with a high fidelity solar pressure model. The model included a physically accurate representation of the spacecraft structure and a high time resolution orientation model. Observation modeling included the removal of the spin induced Doppler bias, spin signature and per pass correction of range calibration errors applied for data leading up to critical events. As a result, all orbit determination goals were met. A second area of emphasis in this paper is the JPL tracking and orbit determination effort in support of the TMI maneuver. TMI occurred out of contact with ground stations and the JPL Goldstone tracking complex had the first pass following the bum. As a result, MMNAV had the responsibility to make a rapid assessment of the maneuver performance. MMNAV made the determination that a 100 m/s under bum had occurred and promptly informed ISAS via voice lines. ISAS immediately began preparations for a correction maneuver (TMIc), which had to be performed during the next Usuda pass. The near real time assessment by MMNAV provided accurate antenna frequency and pointing updates for the spacecraft acquisition at Usuda and the close coordination between the two agencies enabled the design and successful execution of the TMc maneuver. Propellant consumption during the correction burn dictated that the mission be redesigned. ISAS developed a new plan which adds 3 full solar orbits, two Earth swingbys and one lunar swingby with arrival at Mars in January 2004. The final Mars orbit will still enable the mission to achieve all of its science objectives.
In the past Science Planning for space missions has been comprised of using ad-hoc software toolscollected or reconstructed from previous missions, tools used by other groups who often speak a different 'technical' language or even 'the backs of envelopes'. In addition to the tools being rough, the work done with these tools often has had to be redone or at least re-entered when it came time to determine actual observations. Science Opportunity Analyzer (SOA), a Java-based application, has been built for scientists to enable them to identify/analyze observation opportunities and then, to create corresponding observation designs.
In order to minimize the cost of developing sequences of commands for small, low cost missions, a cost effective set of uplink tools used in conjunction with an appropriate ground system architecture (including a multi-mission operations facility) must be utilized.
For many years the diverse scientific community that supports JPL's wide variety ofinterplanetary space missions has needed a tool in order to plan and develop their experiments. The tool needs to be easily adapted to various mission types and portable to the user community. The Science Opportunity Analyzer, SOA, now in its third year of development, is intended to meet this need. SOA is a java-based application that is designed to enable scientists to identify and analyze opportunities for science observations from spacecraft. It differs from other planning tools in that it does not require an in-depth knowledge of the spacecraft command system or operation modes to begin high level planning. Users can, however, develop increasingly detailed levels of design. SOA consists of six major functions: Opportunity Search, Visualization, Observation Design, Constraint Checking, Data Output and Communications. Opportunity Search is a GUI driven interface to existing search engines that can be used to identify times when a spacecraft is in a specific geometrical relationship with other bodies in the solar system. This function can be used for advanced mission planning as well as for making last minute adjustments to mission sequences in response to trajectory modifications. Visualization is a key aspect of SOA. The user can view observation opportunities in either a 3D representation or as a 2D map projection. The user is given extensive flexibility to customize what is displayed in the view. Observation Design allows the user to orient the spacecraft and visualize the projection of the instrument field of view for that orientation using the same views as Opportunity Search. Constraint Checking is provided to validate various geometrical and physical aspects of an observation design. The user has the ability to easily create custom rules or to use official project-generated flight rules. This capability may also allow scientists to easily impact the cost to science if flight rule changes occur. Data Output generates information based on the spacecraft's trajectory, opportunity search results or based on a created observation. The data can be viewed either in tabular format or as a graph. Finally, SOA is unique in that it is designed to be able to communicate with a variety of existing planning and sequencing tools. From the very beginning SOA was designed with the user in mind. Extensive surveys of the potential user community were conducted in order to develop the software requirements. Throughout the development period, close ties have been maintained with the science community to insure that the tool maintains its user focus. Although development is still in its early stages, SOA is already developing a user community on the Cassini project, which is depending on this tool for their science planning. There are other tools at JPL that do various pieces of what SOA can do; however, there is no other tool which combines all these functions and presents them to the user in such a convenient, cohesive, and easy to use fashion.
Explore the source record for details and available documents.
The daily preparation of uplink products (commands and files) for Deep Impact was as problematic as the final encounter images were spectacular. The operations team was faced with many challenges during the six-month mission to comet Tempel One of the biggest difficulties was that the Deep Impact Flyby and Impactor vehicles necessitated a high volume of uplink products while also utilizing a new uplink file transfer capability. The Jet Propulsion Laboratory (JPL) Multi-Mission Ground Systems and Services (MGSS) Mission Planning and Sequence Team (MPST) had the responsibility of preparing the uplink products for use on the two spacecraft. These responsibilities included processing nearly 15,000 flight products, modeling the states of the spacecraft during all activities for subsystem review, and ensuring that the proper commands and files were uplinked to the spacecraft. To guarantee this transpired and the health and safety of the two spacecraft were not jeopardized several new ground scripts and procedures were developed while the Deep Impact Flyby and Impactor spacecraft were en route to their encounter with Tempel-1. These scripts underwent several adaptations throughout the entire mission up until three days before the separation of the Flyby and Impactor vehicles. The problems presented by Deep Impact's daily operations and the development of scripts and procedures to ease those challenges resulted in several valuable lessons learned. These lessons are now being integrated into the design of current and future MGSS missions at JPL.
In this paper, we discuss the scheduling capability of APGEN (Activity Plan Generator), a multi-mission planning application that is part of the NASA AMMOS (Advanced Multi- Mission Operations System), and how APGEN scheduling evolved over its applications to specific Space Missions. Our analysis identifies two major reasons for the successful application of APGEN scheduling to real problems: an expressive DSL (Domain-Specific Language) for formulating scheduling algorithms, and a well-defined process for enlisting the help of auxiliary modeling tools in providing high-fidelity, system-level simulations of the combined spacecraft and ground support system.