Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Mission Control”

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.

At least 865 records · Page 48
All sourcesNASA NTRSDOE OSTI
NASA NTRS1975

Apollo experience report: Guidance and control systems; lunar module mission programer

A review of the concept, operational requirements, design, and development of the lunar module mission programer is presented, followed by a review of component and subsystem performance during design-feasibility, design-verification, and qualification tests performed in the laboratory. The system was further proved on the unmanned Apollo 5 mission. Several anomalies were detected, and satisfactory solutions were found. These problems are defined and examined, and the corrective action taken is discussed. Suggestions are given for procedural changes to be used if future guidance and control systems of this type are to be developed.

Vernon, J. A.↗
NASA NTRS1986

Applications software supporting the Spartan Attitude Control System

The native software supporting a single mission for the Spartan Attitude Control System can require up to 40,000 lines of code. Most of this must be rewritten for each mission. Control system engineers use an array of Applications Software Packages residing in ground computers to write each mission's flight software. These Applications Packages are written in the 'C' programming language and run under the UNIX Operating System. This paper discusses each of the Attitude Control Applications Software Packages, and describes the purpose and design of each.

Stone, R. W.↗
NASA NTRS2007

Determining Desirable Cursor Control Device Characteristics for NASA Exploration Missions

A test battery was developed for cursor control device evaluation: four tasks were taken from ISO 9241-9, and three from previous studies conducted at NASA. The tasks focused on basic movements such as pointing, clicking, and dragging. Four cursor control devices were evaluated with and without Extravehicular Activity (EVA) gloves to identify desirable cursor control device characteristics for NASA missions: 1) the Kensington Expert Mouse, 2) the Hulapoint mouse, 3) the Logitech Marble Mouse, and 4) the Honeywell trackball. Results showed that: 1) the test battery is an efficient tool for differentiating among input devices, 2) gloved operations were about 1 second slower and had at least 15% more errors; 3) devices used with gloves have to be larger, and should allow good hand positioning to counteract the lack of tactile feedback, 4) none of the devices, as designed, were ideal for operation with EVA gloves.

Sandor, Aniko↗
NASA NTRS2010

Command, Control and Communications Capabilities Enabling 21st Century Missions, a Historical Perspective

Command, Control and Communications (CCC) has evolved through the years from simple switches, dials, analogue hardwire networks and lights to a modern computer based digital network. However there are two closely coupled pillars upon which a CCC system is built. The first, is that technology drives the pace of advancement. The second is that a culture that fosters resistance to change can limit technological advancements in the CCC system. While technology has advanced at a tremendous rate throughout the years, the change in culture has moved slowly. This paper will attempt to show through a historical perspective where specific design decisions for early CCC systems have erroneously evolved into general requirements being imposed on later systems. Finally this paper will provide a glimpse into the future directions envisioned for CCC capabilities that will enable 21st century missions.

Waterman, Robert D.↗
NASA NTRS1965

LEM piloted control considerations.

LEM mission and pilot role in spacecraft control including guidance and control systems, retromaneuvering, landing-site inspection, etc

GUIDANCE AND CONTROL↗
NASA NTRSDate not supplied

Genesis Solar Wind – Capture, Return, Curate and Analyze: Looking Backward and Creating a Timeline

Introduction: In 1997 NASA’S Discovery Program selected the Genesis mission proposal to return solar wind samples to Earth for laboratory analyses. Principal Investigator Donald S. Burnett and the science team defined the purity of collector materials and ability to analyze solar wind composition to the precision required for planetary science. As a small mission, focused on a well-defined science goal, yet needing careful attention to engineering details, the communication among scientists and engineers, nurtured by Don Burnett, was exceptional. Genesis Mission and Curation Legacy: Genesis, as the first U. S. spacecraft to return astromaterial samples since Apollo, not only integrated the mission planning and flight teams, but also the science and sample curation teams during the mission development period. Since Genesis is a sample return mission, the Science Team was essential in certifying the collectors (sample containers for solar atoms). From inception, Genesis established mission funding for returned sample curation. JSC was lead in contamination control during mission preparation, including establishment of an ISO 4 cleanroom facility and use of ultrapure water (UPW) for cleaning flight hardware (and, as it turned out, for cleaning collectors after the mishap). Reliable, fast communication among scientists, engineers and curators at the hands-on level established deep respect among team members and efficient decision-making. JSC’s 50-years of astromaterial sample curation provided experienced sample processors onsite during recovery in Utah (a deep bench for emergency response). Post-recovery curation included iterative collaboration with science sample users to clean or verify cleanliness of samples. The science legacy from Genesis is addressed by Burnett and Jurewicz, this volume. In The Beginning: After Apollo sample return, Burnett and Marcia Neugebauer at JPL began discussing a solar wind sample return, with Neugebauer arguing that separate collection of solar wind regimes was essential science. By 1992 a solar wind sample return mission was presented at a workshop, and by 1994 a mission was proposed named Suess-Urey. The mission was re-proposed under a new name GENESIS and selected in 1997. Susan Niebur captured the Genesis mission history and stories, from high level management documents and from many interviews with participants [2]. Her account lets readers glimpse personality of participants in quotations from interviews. Need and Scope for Detailed Technical Timeline: A timeline constructed from lower level task documents has been initiated to document the resources and skills actually used, as well as task sequence or concurrency. Timelines for high level mission events are captured in two documents [1] [2] and for detailed re-entry events in [3]. A detailed technical timeline for Genesis mission and curation activities will provide data points for lower level tasks, such as ISO 4 curation facility construction time, preparation for nominal sample field recovery, mishap recovery, and UPW expansion. Changes in technology context 1990-2024: Semiconductor technologies were easily accessible in the U.S.A. (1990-1999), and the Genesis team used those resources for cleanroom design and UPW system expansion. Image documentation was changing from film to digital during cleanroom construction and payload cleaning (1997-2001). Engineering design was done using computer aided design proprietary software, making more difficult the archiving of payload configuration and materials. Email of documents, tracked delivery service and virtual meeting capability greatly improved communication efficiency. Information sources – Pre-launch mission preparation: Examples of mission science, engineering and contamination control are collector purity testing, payload design/fabrication and ISO 4 cleanroom construction. Information on timing of these activities comes from facility readiness reviews, management reviews, shipping documents, procurement documents, test reports, travel documents, laboratory logs, Quality Assurance documents, dates on images, participant notebooks and emails. Information sources – Sample return re-entry and field recovery activities: Information comes from event timelines produced by Mid-Air Recovery team, Lockheed team lead notes and from chase video, JPL Quality Assurance. Information also comes from images and logbooks from UTTR cleanroom operations and from curatorial documents. Information sources – Resulting science and sample cleaning processes: Agendas from the annual gatherings of the science team initially trace testing for collector purity/cleanliness, and after sample recovery, include collector cleaning and cleanliness assessment. Post-recovery documents include curatorial orders and procedures, sample allocation documents and LPSC abstracts. Timeline Objectives: A simple spreadsheet timeline with headers DATE, EVENT, PEOPLE, COMMENT, INFORMATION SOURCE has been initiated and currently has over 90 entries. While this is not definitive historical research, it is a quick look at the evolution of Genesis curation with pointers to documents or people with information. Engineers for future missions may find useful points of comparison for development of facilities. References:[1] Genesis Mission Reference Document, (2011) JPL D-62382.[2] Niebur S. M., edited by Brown D. W. (2023) NASA’s Discovery Program: The First 20 Years of Competitive Planetary Exploration, NASA-SP-2023-4238.[3] Genesis Mishap Investigation Board Report, Vol. 1 (July 2005).

solar wind↗
NASA NTRSDate not supplied

Attitude Control System for the Solar Cruiser and Future Solar Sail Missions

NASA’s Marshall Space Flight Center (MSFC) is developing the Solar Cruiser solar sail mission to continue to mature solar sail propulsion. Solar Cruiser is a 95kg spacecraft capable of deploying a 1654 square meter solar sail. Solar Cruiser will demonstrate science observation capabilities and navigation in sub Lagrange Point (L1) halo-orbits. Solar Cruiser sail technology can be scaled to larger solar sail missions, including attitude control system and sail membrane and boom technology. Larger solar sails could be used to image the solar poles, enabling Solar Polar Imager (SPI) missions currently prohibitively expensive for propellant-based propulsion methods. Similarly, solar sails can be used to create artificial equilibria and indefinite station-keeping at locations sunward of Lagrange Point one, L1, along the Sun-Earth line (SEL), which can provide space-weather monitor and prediction and reveal discoveries about our Sun and solar system. To achieve the high characteristic acceleration required for larger solar sail missions such as SPI, a solar sail area of approximately 7000 square-meters would be needed. In comparison, the largest solar sail flown to date is the JAXA’s IKAROS mission with a 196 square-meters sail. Attitude control an SPI-size sail poses challenges, including station keeping under solar sail induced torques and thrust vector pointing. In this study, the scalability of the Solar Cruiser sail attitude control architecture to larger sails is studied, such as pointing control performance, mass and power requirements. Solar Cruiser attitude control actuators include propellant-based, such as ion engines, and propellantless options which create differential solar pressures to generate spacecraft torques. Propellantless attitude control includes active translation of the center of mass, Reflectivity Control Devices (RCDs), and tip vanes. The study summarizes the scalability characteristics of the different attitude control architectures for larger solar sail missions.

Solar Sail Propulsion↗
NASA NTRS2017

Environmental Control Systems for Exploration Missions One and Two

In preparing for Exploration Missions One and Two (EM-1 & EM-2), the Ground Systems Development and Operations Program has significant updates to be made to nearly all facilities. This is all being done to accommodate the Space Launch System, which will be the world’s largest rocket in history upon fruition. Facilitating the launch of such a rocket requires an updated Vehicle Assembly Building, an upgraded Launchpad, Payload Processing Facility, and more. In this project, Environmental Control Systems across several facilities were involved, though there is a focus around the Mobile Launcher and Launchpad. Parts were ordered, analysis models were updated, design drawings were updated, and more.

EM-2↗
NASA NTRS2006

Pointing Control System Architecture for the Eclipse Mission

This paper describes the high performance pointing control system used to point the Eclipse telescope. Eclipse is a new mission under study at Jet Propulsion Laboratory for a proposal as a discovery mission. Eclipse is a space telescope for high-contrast optical astronomy. It will be used to investigate the planetary bodies and environments. The main objective of the Eclipse mission is to study planets around nearby stars. Eclipse is designed to reveal planets or dust structures by reducing the scattered and diffracted light within a few arcseconds of a star to a level three orders of magnitude lower than any instrument on the Hubble Space Telescope (HST). Eclipse achieves this high contrast using a 1.8 meter diameter telescope, a coronagraphic system for control of diffracted light, and active wavefront correction using a Precision Deformable Mirror (DM) for the suppression of scattered light. The observatory will be launched into a Sun-synchronous 690 Km, 98.2(deg) Earth Orbit in 2012.

architecture↗
NASA NTRS1997

STS-85 Day 09 Highlights

On this ninth day of the STS-85 mission, the flight crew, Cmdr. Curtis L. Brown, Jr., Pilot Kent V. Rominger, Payload Cmdr. N. Jan Davis (Ph.D.), Mission Specialists Robert L. Curbeam, Jr. and Stephen K. Robinson (Ph.D.), and Payload Specialist Bjarni V. Tryggvason watch over the Manipulator Flight Demonstration (MFD) experiment while Japanese investigators again maneuvere the Small Fine Arm remotely from a control room near Mission Control. It is the final planned work with the arm during this mission. While MFD operations are ongoing, Robinson again uses the Southwest Ultraviolet Imaging System's ultraviolet imaging telescope to observe Comet Hale-Bopp and Curbeam continue his work with the Bioreactor Demonstration System designed to perform cell biology experiments under controlled conditions. Tryggvason spends his day supporting data gathering with the Microgravity Vibration Isolation Mount experiment. Before the crew's workday began, they discussed the mission's progress with reporters in the U.S. and Canada as part of the traditional crew news conference. Questions ranged from life in space for the first time space travelers to providing a report card on the more than 24 experiments being conducted throughout the mission.

Source record↗
NASA NTRS1981

A spacecraft attitude and articulation control system design for the Comet Halley intercept mission

An attitude and articulation control system design for the Comet Halley 1986 intercept mission is presented. A spacecraft dynamics model consisting of five hinge-connected rigid bodies is used to analyze the spacecraft attitude and articulation control system performance. Inertial and optical information are combined to generate scan platform pointing commands. The comprehensive spacecraft model has been developed into a digital computer simulation program, which provides performance characteristics and insight pertaining to the control and dynamics of a Halley Intercept spacecraft. It is shown that scan platform pointing error has a maximum value of 1.8 milliradians during the four minute closest approach interval. It is also shown that the jitter or scan platform pointing rate error would have a maximum value of 2.5 milliradians/second for the nominal 1000 km closest approach distance trajectory and associated environment model.

Key, R. W.↗
NASA NTRS1994

Implementing Software Safety in the NASA Environment

Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.

Wetherholt, Martha S.↗
NASA NTRS2005

Development of a Modeling Framework to Support Control Investigations of Sailcraft Missions A First Cut: ABLE Sailcraft Dynamics Model

Solar Sailcraft, the stuff of dreams of the H.G. Wells generation, is now a rapidly maturing reality. The promise of unlimited propulsive power by harnessing stellar radiation is close to realization. Currently, efforts are underway to build, prototype and test two configurations. These sails are designed to meet a 20m sail requirement, under guidance of the In-Space Propulsion (ISP) technology program office at MSFC. While these sails will not fly , they are the first steps in improving our understanding of the processes and phenomena at work. As part of the New Millennium Program (NMP) the ST9 technology validation mission hopes to launch and fly a solar sail by 2010 or sooner. Though the Solar Sail community has been studying and validating various concepts over two decades, it was not until recent breakthroughs in structural and material technology, has made possible to build sails that could be launched. With real sails that can be tested (albeit under earth conditions), the real task of engineering a viable spacecraft has finally commenced. Since it is not possible to accurately or practically recreate the actual operating conditions of the sailcraft (zero-G, vacuum and extremely low temperatures), much of the work has focused on developing accurate models that can be used to predict behavior in space, and for sails that are 6-10 times the size of currently existing sails. Since these models can be validated only with real test data under "earth" conditions, the process of modeling and the identification of uncertainty due to model assumptions and scope need to be closely considered. Sailcraft models that exist currently, are primarily focused on detailed physical representations at the component level, these are intended to support prototyping efforts. System level models that cut across different sail configurations and control concepts while maintaining a consistent approach are non-existent. Much effort has been focused on the areas of thrust performance, solar radiation prediction, and sail membrane behavior vis-a-vis their reflective geometry, such as wrinkling/folding/furling as it pertains to thrust prediction. A parallel effort has been conducted on developing usable models for developing attitude control systems (ACS), for different sail configurations in different regimes. There has been very little by way of a system wide exploration of the impact of the various control schemes, thrust prediction models for different sail configurations being considered.

Sarathy, Sriprakash↗
NASA NTRS1990

Attitude control requirements for various solar sail missions

The differences are summarized between the attitude control requirements for various types of proposed solar sail missions (Earth orbiting; heliocentric; asteroid rendezvous). In particular, it is pointed out that the most demanding type of mission is the Earth orbiting one, with the solar orbit case quite benign and asteroid station keeping only slightly more difficult. It is then shown, using numerical results derived for the British Solar Sail Group Earth orbiting design, that the disturbance torques acting on a realistic sail can completely dominate the torques required for nominal maneuvering of an 'ideal' sail. This is obviously an important consideration when sizing control actuators; not so obvious is the fact that it makes the standard rotating vane actuator unsatisfactory in practice. The reason for this is given, and a set of new actuators described which avoids the difficulty.

Williams, Trevor↗
NASA NTRS2014

Cost Analysis In A Multi-Mission Operations Environment

Spacecraft control centers have evolved from dedicated, single-mission or single missiontype support to multi-mission, service-oriented support for operating a variety of mission types. At the same time, available money for projects is shrinking and competition for new missions is increasing. These factors drive the need for an accurate and flexible model to support estimating service costs for new or extended missions; the cost model in turn drives the need for an accurate and efficient approach to service cost analysis. The National Aeronautics and Space Administration (NASA) Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center (MSFC) provides operations services to a variety of customers around the world. HOSC customers range from launch vehicle test flights; to International Space Station (ISS) payloads; to small, short duration missions; and has included long duration flagship missions. The HOSC recently completed a detailed analysis of service costs as part of the development of a complete service cost model. The cost analysis process required the team to address a number of issues. One of the primary issues involves the difficulty of reverse engineering individual mission costs in a highly efficient multimission environment, along with a related issue of the value of detailed metrics or data to the cost model versus the cost of obtaining accurate data. Another concern is the difficulty of balancing costs between missions of different types and size and extrapolating costs to different mission types. The cost analysis also had to address issues relating to providing shared, cloud-like services in a government environment, and then assigning an uncertainty or risk factor to cost estimates that are based on current technology, but will be executed using future technology. Finally the cost analysis needed to consider how to validate the resulting cost models taking into account the non-homogeneous nature of the available cost data and the decreasing flight rate. This paper presents the issues encountered during the HOSC cost analysis process, and the associated lessons learned. These lessons can be used when planning for a new multi-mission operations center or in the transformation from a dedicated control center to multi-center operations, as an aid in defining processes that support future cost analysis and estimation. The lessons can also be used by mature serviceoriented, multi-mission control centers to streamline or refine their cost analysis process.

Newhouse, M.↗
NASA NTRS2014

Cost Analysis in a Multi-Mission Operations Environment

Spacecraft control centers have evolved from dedicated, single-mission or single mission-type support to multi-mission, service-oriented support for operating a variety of mission types. At the same time, available money for projects is shrinking and competition for new missions is increasing. These factors drive the need for an accurate and flexible model to support estimating service costs for new or extended missions; the cost model in turn drives the need for an accurate and efficient approach to service cost analysis. The National Aeronautics and Space Administration (NASA) Huntsville Operations Support Center (HOSC) at Marshall Space Flight Center (MSFC) provides operations services to a variety of customers around the world. HOSC customers range from launch vehicle test flights; to International Space Station (ISS) payloads; to small, short duration missions; and has included long duration flagship missions. The HOSC recently completed a detailed analysis of service costs as part of the development of a complete service cost model. The cost analysis process required the team to address a number of issues. One of the primary issues involves the difficulty of reverse engineering individual mission costs in a highly efficient multi-mission environment, along with a related issue of the value of detailed metrics or data to the cost model versus the cost of obtaining accurate data. Another concern is the difficulty of balancing costs between missions of different types and size and extrapolating costs to different mission types. The cost analysis also had to address issues relating to providing shared, cloud-like services in a government environment, and then assigning an uncertainty or risk factor to cost estimates that are based on current technology, but will be executed using future technology. Finally the cost analysis needed to consider how to validate the resulting cost models taking into account the non-homogeneous nature of the available cost data and the decreasing flight rate. This paper presents the issues encountered during the HOSC cost analysis process, and the associated lessons learned. These lessons can be used when planning for a new multi-mission operations center or in the transformation from a dedicated control center to multi-center operations, as an aid in defining processes that support future cost analysis and estimation. The lessons can also be used by mature service-oriented, multi-mission control centers to streamline or refine their cost analysis process.

Felton, Larry↗