Search NASA⌕ Search

SEARCH · Search NASA

Results for “operations spacecraft 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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2009

CCSDS Spacecraft Monitor and Control Mission Operations Interoperability Prototype

We are entering a new era in space exploration. Reduced operating budgets require innovative solutions to leverage existing systems to implement the capabilities of future missions. Custom solutions to fulfill mission objectives are no longer viable. Can NASA adopt international standards to reduce costs and increase interoperability with other space agencies? Can legacy systems be leveraged in a service oriented architecture (SOA) to further reduce operations costs? The Operations Technology Facility (OTF) at the Johnson Space Center (JSC) is collaborating with Deutsches Zentrum fur Luft- und Raumfahrt (DLR) to answer these very questions. The Mission Operations and Information Management Services Area (MOIMS) Spacecraft Monitor and Control (SM&C) Working Group within the Consultative Committee for Space Data Systems (CCSDS) is developing the Mission Operations standards to address this problem space. The set of proposed standards presents a service oriented architecture to increase the level of interoperability among space agencies. The OTF and DLR are developing independent implementations of the standards as part of an interoperability prototype. This prototype will address three key components: validation of the SM&C Mission Operations protocol, exploration of the Object Management Group (OMG) Data Distribution Service (DDS), and the incorporation of legacy systems in a SOA. The OTF will implement the service providers described in the SM&C Mission Operation standards to create a portal for interaction with a spacecraft simulator. DLR will implement the service consumers to perform the monitor and control of the spacecraft. The specifications insulate the applications from the underlying transport layer. We will gain experience with a DDS transport layer as we delegate responsibility to the middleware and explore transport bridges to connect disparate middleware products. A SOA facilitates the reuse of software components. The prototype will leverage the capabilities of existing legacy systems. Various custom applications and middleware solutions will be combined into one system providing the illusion of a set of homogenous services. This paper will document our journey as we implement the interoperability prototype. The team consists of software engineers with experience on the current command, telemetry and messaging systems that support the International Space Station (ISS) and Space Shuttle programs. Emphasis will be on the objectives, results and potential cost saving benefits.

Lucord, Steve↗
NASA NTRS1993

Activities of the Center for Space Construction

The Center for Space Construction (CSC) at the University of Colorado at Boulder is one of eight University Space Engineering Research Centers established by NASA in 1988. The mission of the center is to conduct research into space technology and to directly contribute to space engineering education. The center reports to the Department of Aerospace Engineering Sciences and resides in the College of Engineering and Applied Science. The college has a long and successful track record of cultivating multi-disciplinary research and education programs. The Center for Space Construction is prominent evidence of this record. At the inception of CSC, the center was primarily founded on the need for research on in-space construction of large space systems like space stations and interplanetary space vehicles. The scope of CSC's research has now evolved to include the design and construction of all spacecraft, large and small. Within this broadened scope, our research projects seek to impact the underlying technological basis for such spacecraft as remote sensing satellites, communication satellites, and other special purpose spacecraft, as well as the technological basis for large space platforms. The center's research focuses on three areas: spacecraft structures, spacecraft operations and control, and regolith and surface systems. In the area of spacecraft structures, our current emphasis is on concepts and modeling of deployable structures, analysis of inflatable structures, structural damage detection algorithms, and composite materials for lightweight structures. In the area of spacecraft operations and control, we are continuing our previous efforts in process control of in-orbit structural assembly. In addition, we have begun two new efforts in formal approach to spacecraft flight software systems design and adaptive attitude control systems. In the area of regolith and surface systems, we are continuing the work of characterizing the physical properties of lunar regolith, and we are at work on a project on path planning for planetary surface rovers.

Source record↗
NASA NTRS1989

Cooperative control of two active spacecraft during proximity operations

A cooperative autopilot is developed for the control of the relative attitude, relative position and absolute attitude of two maneuvering spacecraft during on orbit proximity operations. The autopilot consists of an open-loop trajectory solver which computes a nine dimensional linearized nominal state trajectory at the beginning of each maneuver and a phase space regulator which maintains the two spacecraft on the nominal trajectory during coast phases of the maneuver. A linear programming algorithm is used to perform jet selection. Simulation tests using a system of two space shuttle vehicles are performed to verify the performance of the cooperative controller and comparisons are made to a traditional passive target/active pursuit vehicle approach to proximity operations. The cooperative autopilot is shown to be able to control the two vehicle system when both the would be pursuit vehicle and the target vehicle are not completely controllable in six degrees of freedom. The cooperative controller is also shown to use as much as 37 percent less fuel and 57 percent fewer jet firings than a single pursuit vehicle during a simple docking approach maneuver.

Polutchko, Robert J.↗
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 NTRS2001

Chandra Space Flight Software: Using Software to Autonomously Operation the Largest and Most Sensitive X-Ray Telescope in the World

Chandra is the world's largest and most sensitive X-ray telescope. The Chandra X-ray Observatory is the third in NASA's family of "Great Observatories." The Chandra X-ray Observatory, launched by Space Shuttle Columbia on July 23, 1999, is NASA's newest Great Observatory. The Chandra space flight software is the operational software, which controls and directs the Chandra X-ray Observatory. The Chandra flight software has executed faultlessly for over 13,000 hours on-orbit. The Chandra flight software directly controls the Pointing, Aspect Determination, Electrical Power Subsystem, Propulsion system, and the Command, Communications, and Data Management subsystems. The software controls the spacecraft operations during all phases of the mission. The software also performs thermal control of the telescope to maintain pointing accuracy and monitors radiation levels throughout the orbit so that the Science Instruments can be safed if radiation thresholds are exceeded. The efficient operation of Chandra flight software has enabled the gathering of crucial science data. The Chandra flight software fault protection is the key to early detection and prevention of science instrument or spacecraft damage in an operating platform/environment, which is completely unforgiving. Permanently open Sun Shade Door and ACIS focal plane radiator sensitivity exposes science instruments and mirrors to damage for pointing anomalies causing an attitude excursion. The Chandra flight software must prevent these attitude excursions from occurring for ANY failure. Another example is that the power system has an unregulated bus, which imposes severe operating requirements on Chandra flight software to control array pointing and battery connection/disconnect using a unique algorithmic and logic approach. The Chandra flight software has enabled a truly autonomous vehicle with greater than 99% of all mission data collected as planned. Less than 15% of spacecraft operations are conducted in view (1 hour out of 8) leading to very extended periods without ground contact. The Chandra flight software implements the flexible mission plan during this out of view period, manages the solid state recorder capacity, controls all pointing and maneuvers, provides fault detection for all satellite subsystems, and initiates communications with the ground at the appropriate time. This paper will describe the software architecture features, key design elements and software testing techniques that have facilitated Chandra's success.

Crumbley, Tim↗
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↗
NASA NTRS1973

Dynamics and control of detumbling a disabled spacecraft during rescue operations

Results of a two-year research effort on dynamics and control of detumbling a disabled spacecraft during rescue operations are summarized. Answers to several basic questions about associated techniques and hardware requirements were obtained. Specifically, efforts have included development of operational procedures, conceptual design of remotely controlled modules, feasibility of internal moving mass for stabilization, and optimal techniques for minimum-time detumbling. Results have been documented in several reports and publications.

Kaplan, M. H.↗
NASA NTRS2006

Autonomic Management of Space Missions

With NASA s renewed commitment to outer space exploration, greater emphasis is being placed on both human and robotic exploration. Even when humans are involved in the exploration, human tending of assets becomes cost-prohibitive or in many cases is simply not feasible. In addition, certain exploration missions will require spacecraft that will be capable of venturing where humans cannot be sent. Early space missions were operated manually from ground control centers with little or no automated operations. In the mid-l980s, the high costs of satellite operations prompted NASA, and others, to begin automating as many functions as possible. In our context, a system is autonomous if it can achieve its goals without human intervention. A number of more-or-less automated ground systems exist today, but work continues with the goal being to reduce operations costs to even lower levels. Cost reductions can be achieved in a number of areas. Ground control and spacecraft operations are two such areas where greater autonomy can reduce costs. As a consequence, autonomy is increasingly seen as a critical approach for robotic missions and for some aspects of manned missions. Although autonomy will be critical for the success of future missions (and indeed will enable certain kinds of science data gathering approaches), missions imbued with autonomy must also exhibit autonomic properties. Exploitation of autonomy alone, without emphasis on autonomic properties, will leave spacecraft vulnerable to the dangerous environments in which they must operate. Without autonomic properties, a spacecraft may be unable to recognize negative environmental effects on its components and subsystems, or may be unable to take any action to ameliorate the effects. The spacecraft, though operating autonomously, may then sustain a degradation of performance of components or subsystems, and consequently may have a reduced potential for achieving mission objectives. In extreme cases, lack of autonomic properties could leave the spacecraft unable to recover from faults. Ensuring that exploration spacecraft have autonomic properties will increase the survivability and therefore the likelihood of success of these missions. In fact, over time, as mission requirements increased demands on spacecraft capabilities and longevity, designers have gradually built more autonomicity into spacecraft. For example, a spacecraft in low-earth orbit may experience an out-of-bounds perturbation of its attitude (orientation) due to increased drag caused by increased atmospheric density at its altitude as a result of a sufficiently large solar flare. If the spacecraft was designed to recognize the excessive attitude perturbation, it could decide to protect itself by going into a safe-hold mode where its internal configuration and operation are altered to conserve power and its coarse attitude is adjusted to point its solar panels toward the Sun to maximize power generation. This is an example of a simple type of autonomic behavior that has actually occurred. Future mission concepts will be increasingly dependent on space system survivability enabled by more advanced types of autonomic behaviors

Hinchey, Michael G.↗
NASA NTRS2011

Cassini Orbit Trim Maneuvers at Saturn - Overview of Attitude Control Flight Operations

The Cassini spacecraft has been in orbit around Saturn since July 1, 2004. To remain on the planned trajectory which maximizes science data return, Cassini must perform orbit trim maneuvers using either its main engine or its reaction control system thrusters. Over 200 maneuvers have been executed on the spacecraft since arrival at Saturn. To improve performance and maintain spacecraft health, changes have been made in maneuver design command placement, in accelerometer scale factor, and in the pre-aim vector used to align the engine gimbal actuator prior to main engine burn ignition. These and other changes have improved maneuver performance execution errors significantly since 2004. A strategy has been developed to decide whether a main engine maneuver should be performed, or whether the maneuver can be executed using the reaction control system.

spacecraft configuration↗
NASA NTRS1994

SCL: An off-the-shelf system for spacecraft control

In this age of shrinking military, civil, and commercial space budgets, an off-the-shelf solution is needed to provide a multimission approach to spacecraft control. A standard operational interface which can be applied to multiple spacecraft allows a common approach to ground and space operations. A trend for many space programs has been to reduce operational staff by applying autonomy to the spacecraft and to the ground stations. The Spacecraft Command Language (SCL) system developed by Interface and Control Systems, Inc. (ICS) provides an off-the-shelf solution for spacecraft operations. The SCL system is designed to provide a hyper-scripting interface which remains standard from program to program. The spacecraft and ground station hardware specifics are isolated to provide the maximum amount of portability from system to system. Uplink and downlink interfaces are also isolated to allow the system to perform independent of the communications protocols chosen. The SCL system can be used for both the ground stations and the spacecraft, or as a value added package for existing ground station environments. The SCL system provides an expanded stored commanding capability as well as a rule-based expert system on-board. The expert system allows reactive control on-board the spacecraft for functions such as electrical power systems (EPS), thermal control, etc. which have traditionally been performed on the ground. The SCL rule and scripting capability share a common syntax allowing control of scripts from rules and rules from scripts. Rather than telemeter over sampled data to the ground, the SCL system maintains a database on-board which is available for interrogation by the scripts and rules. The SCL knowledge base is constructed on the ground and uploaded to the spacecraft. The SCL system follows an open-systems approach allowing other tasks to communicate with SCL on the ground and in space. The SCL system was used on the Clementine program (launched January 25, 1994) and is required to have bidirectional communications with the guidance, navigation, and control (GNC) algorithms which were written as another task. Sequencing of the spacecraft maneuvers are handled by SCL, but the low-level thruster pulse commands are handled by the GNC software. Attitude information is reported back as telemetry, allowing the SCL expert system to inference on the changing data. The Clementine SCL flight software was largely reused from another Naval Center for Space Technology (NCST) satellite program. This paper details the SCL architecture and how an off-the-shelf solution makes sense for multimission spacecraft programs. The Clementine mission will be used as a case study in the application of the SCL to a 'fast track' program. The benefits of such a system in a 'better, cheaper, faster' climate will be discussed.

Buckley, Brian↗
NASA NTRS2000

Ground Data System Risk Mitigation Techniques for Faster, Better, Cheaper Missions

With the advent of faster, cheaper, and better missions, NASA Projects acknowledged that a higher level of risk was inherent and accepted with this approach. It was incumbent however upon each component of the Project whether spacecraft, payload, launch vehicle, or ground data system to ensure that the mission would nevertheless be an unqualified success. The Small Explorer (SMEX) program's ground data system (GDS) team developed risk mitigation techniques to achieve these goals starting in 1989. These techniques have evolved through the SMEX series of missions and are practiced today under the Triana program. These techniques are: (1) Mission Team Organization--empowerment of a closeknit ground data system team comprising system engineering, software engineering, testing, and flight operations personnel; (2) Common Spacecraft Test and Operational Control System--utilization of the pre-launch spacecraft integration system as the post-launch ground data system on-orbit command and control system; (3) Utilization of operations personnel in pre-launch testing--making the flight operations team an integrated member of the spacecraft testing activities at the beginning of the spacecraft fabrication phase; (4) Consolidated Test Team--combined system, mission readiness and operations testing to optimize test opportunities with the ground system and spacecraft; and (5). Reuse of Spacecraft, Systems and People--reuse of people, software and on-orbit spacecraft throughout the SMEX mission series. The SMEX ground system development approach for faster, cheaper, better missions has been very successful. This paper will discuss these risk management techniques in the areas of ground data system design, implementation, test, and operational readiness.

Catena, John J.↗
NASA NTRS1995

A High Efficiency System for Science Instrument Commanding for the Mars Global Surveyor Mission

The Mars Global Surveyor (MGS) mission will return to Mars to re- cover most of the science lost when the ill fated Mars Observer space- craft suffered a catastrophic anomaly in its propulsion system and did not go into orbit. Described in detail are the methods employed by the MGS Sequence Team to accelerate science command processing by using standard command generation process and standard UNIX control scripts.

mars global surveyor mission science instrument co↗
NASA NTRS1994

SCOS 2: An object oriented software development approach

The Spacecraft Control and Operations System 2 (SCOS 2), is intended to provide the generic mission control system infrastructure for future ESA missions. It represents a bold step forward in order to take advantage of state-of-the-art technology and current practices in the area of software engineering. Key features include: (1) use of object oriented analysis and design techniques; (2) use of UNIX, C++ and a distributed architecture as the enabling implementation technology; (3) goal of re-use for development, maintenance and mission specific software implementation; and (4) introduction of the concept of a spacecraft control model. This paper touches upon some of the traditional beliefs surrounding Object Oriented development and describes their relevance to SCOS 2. It gives rationale for why particular approaches were adopted and others not, and describes the impact of these decisions. The development approach followed is discussed, highlighting the evolutionary nature of the overall process and the iterative nature of the various tasks carried out. The emphasis of this paper is on the process of the development with the following being covered: (1) the three phases of the SCOS 2 project - prototyping & analysis, design & implementation and configuration / delivery of mission specific systems; (2) the close cooperation and continual interaction with the users during the development; (3) the management approach - the split between client staff, industry and some of the required project management activities; (4) the lifecycle adopted being an enhancement of the ESA PSS-05 standard with SCOS 2 specific activities and approaches defined; and (5) an examination of some of the difficulties encountered and the solutions adopted. Finally, the lessons learned from the SCOS 2 experience are highlighted, identifying those issues to be used as feedback into future developments of this nature. This paper does not intend to describe the finished product and its operation, but focusing on the journey to arrive there, concentrating therefore on the process and not the products of the SCOS 2 software development.

Symonds, Martin↗
NASA NTRS1994

Test/score/report: Simulation techniques for automating the test process

A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.

Hageman, Barbara H.↗
NASA NTRS1975

On-board data management study for EOPAP

The requirements, implementation techniques, and mission analysis associated with on-board data management for EOPAP were studied. SEASAT-A was used as a baseline, and the storage requirements, data rates, and information extraction requirements were investigated for each of the following proposed SEASAT sensors: a short pulse 13.9 GHz radar, a long pulse 13.9 GHz radar, a synthetic aperture radar, a multispectral passive microwave radiometer facility, and an infrared/visible very high resolution radiometer (VHRR). Rate distortion theory was applied to determine theoretical minimum data rates and compared with the rates required by practical techniques. It was concluded that practical techniques can be used which approach the theoretically optimum based upon an empirically determined source random process model. The results of the preceding investigations were used to recommend an on-board data management system for (1) data compression through information extraction, optimal noiseless coding, source coding with distortion, data buffering, and data selection under command or as a function of data activity, (2) for command handling, (3) for spacecraft operation and control, and (4) for experiment operation and monitoring.

Davisson, L. D.↗