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.
Spacecraft engineers often rely on specialized simulation tools to facilitate the analysis, design and operation of space systems. Unfortunately these tools are often designed for one phase of a single mission and cannot be easily adapted to other phases or other misions. The Multi-Mission Pace Vehicle Susbsystem Analysis Tools are designed to provide a solution to this problem.
Explore the source record for details and available documents.
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.
The Deep Impact mission was ambitious and challenging. JPL's well proven, easily adaptable multi-mission sequence planning tools combined with integrated spacecraft subsystem models enabled a small operations team to develop, validate, and execute extremely complex sequence-based activities within very short development times. This paper focuses on the core planning tool used in the mission, APGEN. It shows how the multi-mission design and adaptability of APGEN made it possible to model spacecraft subsystems as well as ground assets throughout the lifecycle of the Deep Impact project, starting with models of initial, high-level mission objectives, and culminating in detailed predictions of spacecraft behavior during mission-critical activities.
The needs are defined for future geosynchronous orbit spacecraft power subsystem components, including power generation, energy storage, and power processing. A review of the rapid expansion of the satellite communications field provides a basis for projection into the future. Three projected models, a mission model, an orbit transfer vehicle model, and a mass model for power subsystem components are used to define power requirements and mass limitations for future spacecraft. Based upon these three models, the power subsystems for a 10 kw, 10 year life, dedicated spacecraft and for a 20 kw, 20 year life, multi-mission platform are analyzed in further detail to establish power density requirements for the generation, storage and processing components of power subsystems as related to orbit transfer vehicle capabilities. Comparison of these requirements to state of the art design values shows that major improvements, by a factor of 2 or more, are needed to accomplish the near term missions. However, with the advent of large transfer vehicles, these requirements are significantly reduced, leaving the long lifetime requirement, associated with reliability and/or refurbishment, as the primary development need. A few technology advances, currently under development, are noted with regard to their impacts on future capability.
JPL has developed a small(<5 kg) spacecraft capable of visual inspection of a host vehicle with support from NASA's Exploration Systems Mission Directorate (ESMD). This paper describes the multi-mission utility of the Micro-Inspector and presents an overview of the spacecraft system and subsystem designs, description of a typical inspection mission scenario, and initial hardware demonstrations of key subsystems, partially integrated with each other in a Micro-Inspector testbed at JPL.
This project focuses on the testing of the telecommunications interface subsystem of the Multi-Mission System Architecture Platform to ensure proper functionality. The Multi-Mission System Architecture Platform is a set of basic tools designed to be used in future spacecraft. The responsibilities of the telecommunications interface include communication between the spacecraft and ground teams as well as acting as the bus controller for the system. The tests completed include bit wise read\write tests to each register, testing of status bits, and verifying various bus controller activities. Testing is accomplished through the use of software-based simulations run on an electronic design of the system. The tests are written in Verilog Hardware Definition Language and they simulate specific states and conditions in telecommunication interfaces. Upon successful completion, the output is examined to verify that the system responded appropriately.
The operation of interplanetary spacecraft at JPL has become an increasingly complex activity. This complexity is due to advanced spacecraft designs and ambitious mission objectives which lead to operations requirements that are more demanding than those of any previous mission. For this reason, several productivity enhancement measures are underway at JPL within mission operations, particularly in the spacecraft analysis area. These measures aimed at spacecraft analysis include: the development of a multi-mission, multi-subsystem operations environment; the introduction of automated tools into this environment; and the development of an expert diagnostics system. This paper discusses an effort to integrate the above mentioned productivity enhancement measures. A prototype was developed that integrates an expert diagnostics system into a multi-mission, multi-subsystem operations environment using the Galileo Power / Pyro Subsystem as a testbed. This prototype will be discussed in addition to background information associated with it.
The LANDSAT Follow-On satellite consists of two major systems: the instrument module and the Multi-Mission Modular Spacecraft (MMS). The instrument module contains the thematic mapper and the five-band multispectral scanner instruments. The instrument module also includes the solar array, the tracking and data relay satellite (TDRS) antenna, and the wideband data module. The MMS contains the modularized and standardized power, propulsion, attitude control, and command and data handling subsystems. The Shuttle will be supporting the LANDSAT Follow-On system. The LANDSAT Follow-On Project plans two Delta 3910 launches. The first is scheduled for 1981; the second Delta launch will occur as needed to keep one satellite operational on orbit. The second satellite will be ready six months after the first. It could be launched any time after that. Shuttle support of the system could begin in early 1983 but would be scheduled to start after the second Delta launch.
This paper presents preliminary design of a multimission spacecraft bus for meteorological and communications payloads. The meteorological payload uses sun-synchronous circular orbit and the communications payload uses Molniya type orbit to provide communications for areas not covered by geosynchronous communications satellites. The launch vehicles are Pegasus for the meteorological payload and Taurus for the communications payload. The spacecraft bus uses three-axis stabilization consisting of a three reaction wheel system. The electric power system consists of single-axis tracking silicon solar array and Ni2 H2 batteries. The propulsion subsystem consists of six hydrazine thrusters and one propellant tank.
The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager 2 spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.
The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager II spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real-time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real-time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.
The Spacecraft Health Automated Reasoning Prototype (SHARP) is a system designed to demonstrate automated health and status analysis for multi-mission spacecraft and ground data systems operations. Telecommunications link analysis of the Voyager II spacecraft is the initial focus for the SHARP system demonstration which will occur during Voyager's encounter with the planet Neptune in August, 1989, in parallel with real-time Voyager operations. The SHARP system combines conventional computer science methodologies with artificial intelligence techniques to produce an effective method for detecting and analyzing potential spacecraft and ground systems problems. The system performs real-time analysis of spacecraft and other related telemetry, and is also capable of examining data in historical context. A brief introduction is given to the spacecraft and ground systems monitoring process at the Jet Propulsion Laboratory. The current method of operation for monitoring the Voyager Telecommunications subsystem is described, and the difficulties associated with the existing technology are highlighted. The approach taken in the SHARP system to overcome the current limitations is also described, as well as both the conventional and artificial intelligence solutions developed in SHARP.
In the early days of JPL's solar system exploration, each spacecraft mission required its own dedicated data system with all software applications written in the mainframe's native assembly language. Although these early telemetry processing systems were a triumph of engineering in their day, since that time the computer industry has advanced to the point where it is now advantageous to replace these systems with more modern technology. The Space Flight Operations Center (SFOC) Prototype group was established in 1985 as a workstation and software laboratory. The charter of the lab was to determine if it was possible to construct a multimission telemetry processing system using commercial, off-the-shelf computers that communicated via networks. The staff of the lab mirrored that of a typical skunk works operation -- a small, multi-disciplinary team with a great deal of autonomy that could get complex tasks done quickly. In an effort to determine which approaches would be useful, the prototype group experimented with all types of operating systems, inter-process communication mechanisms, network protocols, packet size parameters. Out of that pioneering work came the confidence that a multi-mission telemetry processing system could be built using high-level languages running in a heterogeneous, networked workstation environment. Experience revealed that the operating systems on all nodes should be similar (i.e., all VMS or all PC-DOS or all UNIX), and that a unique Data Transport Subsystem tool needed to be built to address the incompatibilities of network standards, byte ordering, and socket buffering. The advantages of building a telemetry processing system based on emerging industry standards were numerous: by employing these standards, we would no longer be locked into a single vendor. When new technology came to market which offered ten times the performance at one eighth the cost, it would be possible to attach the new machine to the network, re-compile the application code, and run. In addition, we would no longer be plagued with lack of manufacturer support when we encountered obscure bugs. And maybe, hopefully, the eternal elusive goal of software portability across different vendors' platforms would finally be available. Some highlights of our prototyping efforts are described.
In order to execute the Vision for Space Exploration, we must find ways to reduce cost, system complexity, design, build, and test times, and at the same time increase flexibility to satisfy multiple functions. Modular, Adaptive, Reconfigurable System (MARS) technologies promise to set the stage for the delivery of system elements that form the building blocks of increasingly ambitious missions involving humans and robots. Today, space systems are largely specialized and built on a case-by-case basis. The notion of modularity however, is nothing new to NASA. The 1970's saw the development of the Multi-Mission Modular spacecraft (MMS). From 1980 to 1992 at least six satellites were built under this paradigm, and included such Goddard Space Flight Center missions as SSM, EUVE, UARS, and Landsat 4 and 5. Earlier versions consisted of standard subsystem "module" or "box" components that could be replaced within a structure based on predefined form factors. Although the primary motivation for MMS was faster/cheaper integration and test, standardization of interfaces, and ease of incorporating new subsystem technology, it lacked the technology maturity and programmatic "upgrade infrastructure" needed to satisfy varied mission requirements, and ultimately it lacked user buy-in. Consequently, it never evolved and was phased out. Such concepts as the Rapid Spacecraft Development Office (RSDO) with its regularly updated catalogue of prequalified busses became the preferred method for acquiring satellites. Notwithstanding, over the past 30 years since MMS inception, technology has advanced considerably and now modularity can be extended beyond the traditional MMS module or box to cover levels of integration, from the chip, card, box, subsystem, to the space system and to the system-of-systems. This paper will present the MARS architecture, cast within the historical context of MMS. Its application will be highlighted by comparing a state-of-the-art point design vs. a MARS-enabled lunar mission, as a representative robotic case design.
The Multi-Mission System Architecture Platform (MSAP) represents an effort to bolster efficiency in the spacecraft design process. By incorporating essential spacecraft functionality into a modular, expandable system, the MSAP provides a foundation on which future spacecraft missions can be developed. Once completed, the MSAP will provide support for missions with varying objectives, while maintaining a level of standardization that will minimize redesign of general system components. One subsystem of the MSAP, the Remote Engineering Unit (REU), functions by gathering engineering telemetry from strategic points on the spacecraft and providing these measurements to the spacecraft's Command and Data Handling (C&DH) subsystem. Before the MSAP Project reaches completion, all hardware, including the REU, must be verified. However, the speed and complexity of the REU circuitry rules out the possibility of physical prototyping. Instead, the MSAP hardware is designed and verified using the Verilog Hardware Definition Language (HDL). An increasingly popular means of digital design, HDL programming provides a level of abstraction, which allows the designer to focus on functionality while logic synthesis tools take care of gate-level design and optimization. As verification of the REU proceeds, errors are quickly remedied, preventing costly changes during hardware validation. After undergoing the careful, iterative processes of verification and validation, the REU and MSAP will prove their readiness for use in a multitude of spacecraft missions.
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.
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.