Onboard Data Summarization and Long-term Onboard Archives for Long-Duration Missions
This paper describes how onboard data summarization will be used as part of an overall knowledge management approach for long duration JPL missions.
SEARCH · Engineering Papers
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.
This paper describes how onboard data summarization will be used as part of an overall knowledge management approach for long duration JPL missions.
Autonomy is required for manned spacecraft missions distant enough that light-time communication delays make ground-based mission control infeasible. Presently, ground controllers develop a complete schedule of power modes for all spacecraft components based on a large number of factors. The proposed architecture is an early attempt to formalize and automate this process using on-vehicle computation resources. In order to demonstrate this architecture, an autonomous electrical power system controller and vehicle Mission Manager are constructed. These two components are designed to work together in order to plan upcoming load use as well as respond to unanticipated deviations from the plan. The communication protocol was developed using "paper" simulations prior to formally encoding the messages and developing software to implement the required functionality. These software routines exchange data via TCP/IP sockets with the Mission Manager operating at NASA Ames Research Center and the autonomous power controller running at NASA Glenn Research Center. The interconnected systems are tested and shown to be effective at planning the operation of a simulated quasi-steady state spacecraft power system and responding to unexpected disturbances.
This document contains all relevant code and descriptions of working components of CCPDVANALYSIS software toolkit.
Research into complexities of software systems Fault Management (FM) and how architectural design decisions affect safety, preservation of assets, and maintenance of desired system functionality has coalesced into a technical reference (TR) suite that advances the provision of safety and mission assurance. The NASA Independent Verification and Validation (IVV) Program, with Software Assurance Research Program support, extracted FM architectures across the IVV portfolio to evaluate robustness, assess visibility for validation and test, and define software assurance methods applied to the architectures and designs. This investigation spanned IVV projects with seven different primary developers, a wide range of sizes and complexities, and encompassed Deep Space Robotic, Human Spaceflight, and Earth Orbiter mission FM architectures. The initiative continues with an expansion of the TR suite to include Launch Vehicles, adding the benefit of investigating differences intrinsic to model-based FM architectures and insight into complexities of FM within an Agile software development environment, in order to improve awareness of how nontraditional processes affect FM architectural design and system health management.
The DSN Simulator (wherein DSN signifies NASA's Deep Space Network) is an updated version of the software described in DSN Array Simulator (NPO-44506), Software Tech Briefs (Special supplement to NASA Tech Briefs), Vol. 32, No. 9 (September 2008), page 26. To recapitulate: This software is used for computational modeling of proposed DSN facilities comprising arrays of antennas and transmitting and receiving equipment for microwave communication with spacecraft on interplanetary missions. Such modeling is performed to estimate facility performance, evaluate requirements that govern facility design, and evaluate proposed improvements in hardware and/or software. The software includes a Monte Carlo simulation component that enables rapid generation of key mission-set metrics (e.g., numbers of links, data rates, and data volumes), and statistical distributions thereof as functions of time. The prior version of the software could model only one DSN facility at a time and included hard-coded, unconfigurable metrics. The present updated version is capable of modeling the entire DSN and provides for configurable metrics, making it possible to perform loading analyses for alternative future DSN architectures and mission-set scenarios. The present version also features an improved user interface and interfaces for exchange of data with other DSN software and with a DSN mission model database.
The Microwave Anisotropy Probe (MAP) is a follow-on mission to the Cosmic Background Explorer (COBE), and is currently collecting data from its orbit near the second Sun-Earth libration point. Due to limited mass, power, and financial resources, a traditional reliability concept including fully redundant components was not feasible for MAP. Instead, the MAP design employs selective hardware redundancy in tandem with contingency software modes and algorithms to improve the odds of mission success. One direction for such improvement has been the development of a two-wheel backup control strategy. This strategy would allow MAP to position itself for maneuvers and collect science data should one of its three reaction wheels fail. Along with operational considerations, the strategy includes three new control algorithms. These algorithms would use the remaining attitude control actuators-thrusters and two reaction wheels-in ways that achieve control goals while minimizing adverse impacts on the functionality of other subsystems and software.
Early in 1993, a servo motor within one of three Fine Guidance Sensors (FGS) aboard the Hubble Space Telescope (HST) reached stall torque levels on several occasions. Little time was left to plan replacement during the first servicing mission, scheduled at the end of '93. Accelerated bearing life tests confirmed that a small angle rocking motion, known as Coarse Track (CT), accelerated bearing degradation. Saturation torque levels were reached after approximately 20 million test cycles, similar to the flight bearings. Reduction in CT operation, implemented in flight software, extended FGS life well beyond the first servicing mission. However in recent years, bearing torques have resumed upward trends and together with a second, recent bearing torque anomaly has necessitated a scheduled FGS replacement during the upcoming second servicing mission in '97. The results from two series of life tests to quantify FGS bearing remaining life, discussion of bearing on-orbit performance, and future plans to service the FGS servos are presented in this paper.
Autonomy is a key enabling factor in the advancement of the remote robotic exploration. There is currently a large gap between autonomy software at the research level and software that is ready for insertion into near-term space missions. The Mission Simulation Facility (MST) will bridge this gap by providing a simulation framework and suite of simulation tools to support research in autonomy for remote exploration. This system will allow developers of autonomy software to test their models in a high-fidelity simulation and evaluate their system's performance against a set of integrated, standardized simulations. The Mission Simulation ToolKit (MST) uses a distributed architecture with a communication layer that is built on top of the standardized High Level Architecture (HLA). This architecture enables the use of existing high fidelity models, allows mixing simulation components from various computing platforms and enforces the use of a standardized high-level interface among components. The components needed to achieve a realistic simulation can be grouped into four categories: environment generation (terrain, environmental features), robotic platform behavior (robot dynamics), instrument models (camera/spectrometer/etc.), and data analysis. The MST will provide basic components in these areas but allows users to plug-in easily any refined model by means of a communication protocol. Finally, a description file defines the robot and environment parameters for easy configuration and ensures that all the simulation models share the same information.
Congratulation on being awarded a grant to conduct research in a spaceflight analog! NASA funded research in a Human Research Program (HRP) managed analog environment is very different from research in a traditional laboratory. This presentation will provide a guide to help investigators successfully plan studies for integration and implementation in an HRP analog platform. There are many things to consider when planning a study for implementation in an analog facility and campaign or mission. How do you get from grant approval to data analysis? This is where HRP’s Research Operations and Integration (ROI) team comes in. The ROI team works with sponsoring HRP elements and PI teams to capture requirements and help the PI teams through the phases of research complement development, integration and implementation. A complement is comprised of a group of studies requiring a common platform and/or scenario that are able to be integrated on a noninterference basis for implementation. Properly defining and documenting requirements and study needs is crucial in successful integration and implementation. This presentation will outline and provide the information needed for PI teams to understand the integration process and the role of the ROI team in the successful integration and implementation of their study. Topics to be discussed will include but not be limited to science requirement definition and documentation, NASA IRB submissions, subject recruitment, screening and selection, study integration process, efficiency in data collection and data sharing, daily crew schedules, hardware and software shipping, receipt and checkout, biological sample collection, mission support, data management and receipt of data.
In order to assess the needs in computational mechanics over the next decade, we formulated a questionnaire and contacted computational mechanics researchers and users in industry, government, and academia. As expected, we found a wide variety of computational mechanics usage and research. This report outlines the activity discussed with those contacts, as well as that in our own organizations. It should be noted that most of the contacts were made before the recent decline of the defense industry. Therefore, areas which are strongly defense-oriented may decrease in relative importance. In order to facilitate updating of this study, names of a few key researchers in each area are included as starting points for future literature surveys. These lists of names are not intended to represent those persons doing the best research in that area, nor are they intended to be comprehensive. They are, as previously stated, offered as starting points for future literature searches. Overall, there is currently a broad activity in computational mechanics in this country, with the breadth and depth increasing as more sophisticated software and faster computers become more available. The needs and desires of the workers in this field are as diverse as their background and organizational products. There seems to be some degree of software development in any organization (although the level of activity is highly variable from one organization to another) which has any research component in its mission. It seems, however, that there is considerable use of commercial software in almost all organizations. In most industrial research organizations, it appears that very little actual software development is contracted out, but that most is done in-house, using a mixture of funding sources. Government agencies vary widely in the ratio of in-house to out-house ratio. There is a considerable amount of experimental verification in most, but not all, organizations. Generally, the amount of experimental verification is more than we expected. Of all the survey contacts, one or two believe that the resources they are allocated are sufficient, but most do not. Some believe they have only half the resources they need. Some see their resource deficits as short-term, while others see it as a trend which will continue or perhaps worsen. The pessimism is stronger in the defense and aerospace industry. When considering only the nonlinear development efforts, there appears to be an even mix of geometric and material nonlinearity. There is not much particular emphasis in linear analysis unless it is in extension of current analysis capabilities to larger problems. The primary exception is concern about modeling of composites, where proven methodologies have trailed element and computer hardware development. Most of the people we spoke to use finite element techniques, but there is some finite difference and boundary element work ongoing. There is also some interest in multiple methods. Coupling of finite elements and boundary elements appears to be of high interest, since the two analysis types are complementary.
An Autonomous Science Agent has been flying onboard the Earth Observing One Spacecraft since 2003. This software enables the spacecraft to autonomously detect and responds to science events occurring on the Earth such as volcanoes, flooding, and snow melt. The package includes AI-based software systems that perform science data analysis, deliberative planning, and run-time robust execution. This software is in routine use to fly the EO-l mission. In this paper we briefly review the agent architecture and discuss lessons learned from this multi-year flight effort pertinent to deployment of software agents to critical applications.
This paper proposes a cyber security modeling and simulation roadmap to enhance mission assurance governance and establish risk reduction processes within constrained budgets. The term mission assurance stems from risk management work by Carnegie Mellon's Software Engineering Institute in the late 19905. By 2010, the Defense Information Systems Agency revised its cyber strategy and established the Program Executive Officer-Mission Assurance. This highlights a shift from simply protecting data to balancing risk and begins a necessary dialogue to establish a cyber security roadmap. The Military Operations Research Society has recommended a cyber community of practice, recognizing there are too few professionals having both cyber and analytic experience. The authors characterize the limited body of knowledge in this symbiotic relationship. This paper identifies operational and research requirements for mission assurance M&S supporting defense and homeland security. M&S techniques are needed for enterprise oversight of cyber investments, test and evaluation, policy, training, and analysis.
The development and application of the Spacecraft Health Automated Reasoning Prototype (SHARP) for the operations of the telecommunications systems and link analysis functions in Voyager mission operations are presented. An overview is provided of the design and functional description of the SHARP system as it was applied to Voyager. Some of the current problems and motivations for automation in real-time mission operations are discussed, as are the specific solutions that SHARP provides. The application of SHARP to Voyager telecommunications had the goal of being a proof-of-capability demonstration of artificial intelligence as applied to the problem of real-time monitoring functions in planetary mission operations. AS part of achieving this central goal, the SHARP application effort was also required to address the issue of the design of an appropriate software system architecture for a ground-based, highly automated spacecraft monitoring system for mission operations, including methods for: (1) embedding a knowledge-based expert system for fault detection, isolation, and recovery within this architecture; (2) acquiring, managing, and fusing the multiple sources of information used by operations personnel; and (3) providing information-rich displays to human operators who need to exercise the capabilities of the automated system. In this regard, SHARP has provided an excellent example of how advanced artificial intelligence techniques can be smoothly integrated with a variety of conventionally programmed software modules, as well as guidance and solutions for many questions about automation in mission operations.
The most common means of remote scientific collaboration today includes the trio of e-mail for electronic communication, FTP for file sharing, and personalized Web sites for dissemination of papers and research results. With the growth of broadband Internet, there has been a desire to share large files (movies, files, scientific data files) over the Internet. Email has limits on the size of files that can be attached and transmitted. FTP is often used to share large files, but this requires the user to set up an FTP site for which it is hard to set group privileges, it is not straightforward for everyone, and the content is not searchable. Peer-to-peer technology (P2P), which has been overwhelmingly successful in popular content distribution, is the basis for development of a scientific collaboratory called Scientific Peer Network (SciPerNet). This technology combines social networking with P2P file sharing. SciPerNet will be a standalone application, written in Java and Swing, thus insuring portability to a number of different platforms. Some of the features include user authentication, search capability, seamless integration with a data center, the ability to create groups and social networks, and on-line chat. In contrast to P2P networks such as Gnutella, Bit Torrent, and others, SciPerNet incorporates three design elements that are critical to application of P2P for scientific purposes: User authentication, Data integrity validation, Reliable searching SciPerNet also provides a complementary solution to virtual observatories by enabling distributed collaboration and sharing of downloaded and/or processed data among scientists. This will, in turn, increase scientific returns from NASA missions. As such, SciPerNet can serve a two-fold purpose for NASA: a cost-savings software as well as a productivity tool for scientists working with data from NASA missions.
As NASA’s role in spaceflight operations change, so too does its design priorities. NASA’s flagship venture, the Space Launch System (SLS), is being created primarily to explore deep space. While commercial partners conduct low Earth orbit resupplies, tests, and even transportation of astronauts, NASA can divert more resources to more exciting projects - going back to the moon, or onwards to Mars. In the short term, this goal manifests in the upcoming Exploration Mission-1 (EM-1) test of the SLS, slated for as early as 2019. SLS, with the Orion capsule, will travel farther than any human-rated spacecraft has gone before. As the most powerful launch vehicle ever created, SLS requires many new innovations to ensure mission success. One such technology is the launch control software, which is the focus of this internship. The SLS launch control software is composed of many functions, all of which require rigorous testing to meet the standard of life-critical code. To facilitate easier testing, the first project I undertook was to customize the open-source tool Wireshark to the software team’s needs. Wireshark is a network protocol analyzer that can take in information about custom information packets. The launch control software will have several protocols that are custom to NASA. I ensured that all necessary component files were the correct file type and in the correct structure for Wireshark to compile. Having allowed Wireshark access to understand custom NASA data packets, testers of the launch control software will be able to find anomalies easier.
The current status of the Kronos Medium Class Explorer (MIDEX) mission concept is reviewed with particular emphasis on instrument performance and mission design with respect to observations of stellar systems. In addition, key mission and science instrument trades, issues, and concerns will be present for discussion.
The Attitude Control System for the IUE spacecraft is described. The basic mission objectives are stated and a sequential discussion of the mission is presented. Desired accuracy for each mission phase is noted and where applicable the onboard control mechanization is shown. Sensors and actuator systems utilized by the control algorithms are described. Finally, onboard software is discussed to a level necessary to understand the prime mission mode operation.
The Analysis Criteria Evaluation System (ACES) is a knowledge based expert system that automates the final certification of the Space Shuttle onboard flight software. Guidance, navigation and control of the Space Shuttle through all its flight phases are accomplished by a complex onboard flight software system. This software is reconfigured for each flight to allow thousands of mission-specific parameters to be introduced and must therefore be thoroughly certified prior to each flight. This certification is performed in ground simulations by executing the software in the flight computers. Flight trajectories from liftoff to landing, including abort scenarios, are simulated and the results are stored for analysis. The current methodology of performing this analysis is repetitive and requires many man-hours. The ultimate goals of ACES are to capture the knowledge of the current experts and improve the quality and reduce the manpower required to certify the Space Shuttle onboard flight software.