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.
Project management and payload integration requirements definition activities are reported. Mission peculiar equipment; systems integration; ground operations analysis and requirement definition; safety and quality assurance; and support systems development are examined for payloads planned for the following missions: EOM-1; SL-2; Sl-3 Astro-1; MSL-2; EASE/ACCESS; MPESS; and the middeck ADSF flight.
The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), responsible for project management and flight operations; Orbital Sciences Corporation (OSC), spacecraft builder and responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), responsible for science planning and operations. As a cost-capped mission, one of Dawn s implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL s ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL s GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project s commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to an overall systems engineering process and fundamental systems engineering practices: decomposition of the project request into manageable requirements; definition of a structured yet flexible development process; integration of multiple ground disciplines and experts into a focused team effort; in-process risk management; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.
The Mission Design and Navigation (MDNAV) Section at the Jet Propulsion Laboratory (JPL) supports many deep space and earth orbiting missions from formulation to end of mission operations. The requirements of these missions are met with a multimission approach to MDNAV ground data system (GDS) infrastructure capable of being shared and allocated in a seamless and consistent manner across missions. The MDNAV computing infrastructure consists of compute clusters, network attached storage, mission support area facilities, and desktop hardware. The multimission architecture allows these assets, and even personnel, to be leveraged effectively across the project lifecycle and across multiple missions simultaneously. It provides a more robust and capable infrastructure to each mission than might be possible if each constructed its own. It also enables a consistent interface and environment within which teams can conduct all mission analysis and navigation functions including: trajectory design; ephemeris generation; orbit determination; maneuver design; and entry, descent, and landing analysis. The savings of these efficiencies more than offset the costs of increased complexity and other challenges that had to be addressed: configuration management, scheduling conflicts, and competition for resources. This paper examines the benefits of the multimission MDNAV ground data system infrastructure, focusing on the hardware and software architecture. The result is an efficient, robust, scalable MDNAV ground data system capable of supporting more than a dozen active missions at once.
The Dawn Project has presented the Ground Data System (GDS) with technical challenges driven by cost and schedule constraints commonly associated with National Aeronautics and Space Administration (NASA) Discovery Projects. The Dawn mission consists of a new and exciting Deep Space partnership among: the Jet Propulsion Laboratory (JPL), manages the project and is responsible for flight operation; Orbital Sciences Corporation (OSC), is the spacecraft builder and is responsible for flight system test and integration; and the University of California, at Los Angeles (UCLA), is responsible for science planning and operations. As a cost-capped mission, one of Dawn's implementation strategies is to leverage from both flight and ground heritage. OSC's ground data system is used for flight system test and integration as part of the flight heritage strategy. Mission operations, however, are to be conducted with JPL's ground system. The system engineering challenge of dealing with two heterogeneous ground systems emerged immediately. During the first technical interchange meeting between the JPL's GDS Team and OSC's Flight Software Team, August 2003, the need to integrate the ground system with the flight software was brought to the table. This need was driven by the project's commitment to enable instrument engineering model integration in a spacecraft simulator environment, for both demonstration and risk mitigation purposes, by April 2004. This paper will describe the system engineering approach that was undertaken by JPL's GDS Team in order to meet the technical challenge within a non-negotiable eight-month schedule. Key to the success was adherence to fundamental systems engineering practices: decomposition of the project request into manageable requirements; integration of multiple ground disciplines and experts into a focused team effort; definition of a structured yet flexible development process; definition of an in-process risk reduction plan; and aggregation of the intermediate products to an integrated final product. In addition, this paper will highlight the role of lessons learned from the integration experience. The lessons learned from an early GDS deployment have served as the foundation for the design and implementation of the Dawn Ground Data System.
This paper addresses the efforts undertaken and the technology deployed to aggregate and distribute the metadata characterizing the real-time operations associated with NASA Earth Observing Systems (EOS) high-rate front-end systems and the science data collected at multiple ground stations and forwarded to the Goddard Space Flight Center for level 0 processing. Station operators, mission project management personnel, spacecraft flight operations personnel and data end-users for various EOS missions can retrieve the information at any time from any location having access to the internet. The users are distributed and the EOS systems are distributed but the centralized metadata accessed via an external web server provide an effective global and detailed view of the enterprise-wide events as they are happening. The data-driven architecture and the implementation of applied middleware technology, open source database, open source monitoring tools, and external web server converge nicely to fulfill the various needs of the enterprise. The timeliness and content of the information provided are key to making timely and correct decisions which reduce project risk and enhance overall customer satisfaction. The authors discuss security measures employed to limit access of data to authorized users only.
Integrated Vehicle Health Management (IVHM) systems have been pursued as highly integrated systems that include smart sensors, diagnostic and prognostics software for assessments of real-time and life-cycle vehicle health information. Inclusive to such a system is the requirement to monitor the environmental health within the vehicle and the occupants of the vehicle. In this regard an enterprise approach to informatics is used to develop a methodology entitled, Comprehensive Environmental Informatics System (CEIS). The hardware and software technologies integrated into this system will be embedded in the vehicle subsystems, and maintenance operations, to provide both real-time and life-cycle health information of the environment within the vehicle cabin and of its occupants. This comprehensive information database will enable informed decision making and logistics management. One key element of the CEIS is interoperability for data acquisition and archive between environment and human system monitoring. With comprehensive components the data acquired in this system will use model based reasoning systems for subsystem and system level managers, advanced on-board and ground-based mission and maintenance planners to assess system functionality. Knowledge databases of the vehicle health state will be continuously updated and reported for critical failure modes, and routinely updated and reported for life cycle condition trending. Sufficient intelligence, including evidence-based engineering practices which are analogous to evidencebased medicine practices, will be included in the CEIS to result in more rapid recognition of off-nominal operation to enable quicker corrective actions. This will result from better information (rather than just data) for improved crew/operator situational awareness, which will produce significant vehicle and crew safety improvements, as well as increasing the chance for mission success, future mission planning as well as training. Other benefits include improved reliability, increase safety in operations and cost of operations. The cost benefits stem from significantly reduced processing and operations manpower, predictive maintenance for systems and subjects. The improvements in vehicle functionality and cost will result from increased prognostic and diagnostic capability due to the detailed total human exploration system health knowledge from CEIS. A collateral benefit is that there will be closer observations of the vehicle occupants as wrist watch sized devices are worn for continuous health monitoring. Additional database acquisition will stem from activities in countermeasure practices to ensure peak performance capability by occupants of the vehicle. The CEIS will provide data from advanced sensing technologies and informatics modeling which will be useful in problem troubleshooting, and improving NASA s awareness of systems during operation.
The purpose of the shuttle system is to permit us to do more useful and necessary things in space at minimum cost. The flight operation subsystem must be consistent with these goals. This review of the predicted payload and mission types reveals a ground facility functionally similar to the Skylab Control Center is needed to provide trajectory control and system management services for the spacecraft and payloads and to provide rapid, effective payload data acquisition and distribution to the user. An automated mission management system must be added to translate user requirements into specific missions, directives, schedules, and plans.
Data Management for the Mars Exploration Rovers (MER) project is a comprehensive system addressing the needs of development, test, and operations phases of the mission. During development of flight software, including the science software, the data management system can be simulated using any POSIX file system. During testing, the on-board file system can be bit compared with files on the ground to verify proper behavior and end-to-end data flows. During mission operations, end-to-end accountability of data products is supported, from science observation concept to data products within the permanent ground repository. Automated and human-in-the-loop ground tools allow decisions regarding retransmitting, re-prioritizing, and deleting data products to be made using higher level information than is available to a protocol-stack approach such as the CCSDS File Delivery Protocol (CFDP).
The NASA Autonomous Mission Operations (AMO) project conducted an experiment to turn over operation and management of selected International Space Station (ISS) sys- tems to the on-board crew. ISS crews managed two different spacecraft systems: the Total Organic Carbon Analyzer (TOCA), a water quality analyzer, and Station Support Com- puters (SSC) laptops, which are non-critical crew computer systems. These systems were selected because they are representative of systems a future crew may need to operate au- tonomously during a deep space mission. The crew autonomously operated these systems, taking on mission operations functions traditionally performed by support teams on the ground, using new software tools that provide decision support algorithms for planning, monitoring and fault management, hardware schematics, system briefs, and data displays that are normally unavailable to the crew. The experiment lasted seven months, during which ISS crews managed TOCA and SSCs on 22 occasions. The AMO software processed data from TOCA and SSCs continuously during this seven month period. The combined performance of the software and crew achieved a 88 success rate on managing TOCA activity, the system for which ground-truth was available.
A near-Earth Asteroid (NEA) mission will present significant new challenges including hazards to crew health created by exploring a beyond low earth orbit destination, traversing the terrain of asteroid surfaces, and the effects of variable gravity environments. Limited communications with ground-based personnel for diagnosis and consultation of medical events require increased crew autonomy when diagnosing conditions, creating treatment plans, and executing procedures. Scope: The Exploration Medical System Demonstration (EMSD) project will be a test bed on the International Space Station (ISS) to show an end-to-end medical system assisting the Crew Medical Officers (CMO) in optimizing medical care delivery and medical data management during a mission. NEA medical care challenges include resource and resupply constraints limiting the extent to which medical conditions can be treated, inability to evacuate to Earth during many mission phases, and rendering of medical care by a non-clinician. The system demonstrates the integration of medical technologies and medical informatics tools for managing evidence and decision making. Project Objectives: The objectives of the EMSD project are to: a) Reduce and possibly eliminate the time required for a crewmember and ground personnel to manage medical data from one application to another. b) Demonstrate crewmember's ability to access medical data/information via a software solution to assist/aid in the treatment of a medical condition. c) Develop a common data management architecture that can be ubiquitously used to automate repetitive data collection, management, and communications tasks for all crew health and life sciences activities. d) Develop a common data management architecture that allows for scalability, extensibility, and interoperability of data sources and data users. e) Lower total cost of ownership for development and sustainment of peripheral hardware and software that use EMSD for data management f) Provide better crew health via the reduction in crew errors, crew time, and ground time.
An end-to-end data system to support a Shuttle-based Multispectral Linear Array (MLA) mission in the mid-1980's was defined. The experimental Land Observing System (ELOS) is discussed. A ground system that exploits extensive assets from the LANDSAT-D Program to effectively meet the objectives of the ELOS Mission was defined. The goal of 10 meter pixel precision, the variety of data acquisition capabilities, and the use of Shuttle are key to the mission requirements, Ground mission management functions are met through the use of GSFC's Multi-Satellite Operations Control Center (MSOCC). The MLA Image Generation Facility (MIGF) combines major hardware elements from the Applications Development Data System (ADDS) facility and LANDSAT Assessment System (LAS) with a special purpose MLA interface unit. LANDSAT-D image processing techniques, adapted to MLA characteristics, form the basis for the use of existing software and the definition of new software required.
Shortage of log-based data in a ground system they have traditionally been the under achievers in a satellite ground system. This is due to several factors: Once log messages scroll out of view on the TTC event console window they are soon forgotten. Application and system log files are scattered across directories within a system, across a multitude of servers, and across one or more databases making access cumbersome. Typical tools to perform log file content searching are generally crude and typically only employed as part of trouble-shooting exercises.As we move towards satellite constellations and fleets and add even more status information, the number of messages keeps growing. One mission now estimates that they could generate 3,000,000 messages per day 1 billion per year - for the life of their mission. What to do with those 1 billion messages? That is the challenge. With the recent technological advances in the management of large data sets, text-based processing, and data analytics, there are now capabilities that we can provide to the ground system engineers and satellite operators to address what we postulate are missed opportunities. Advanced real-time log analysis can allow us to be less reactionary in favor of being more proactive. Analytics goals include the ability to: Identify root cause of unexpected events, failures or error conditions enabled by correlating disparate data. Detect security breaches attempts before they are successful. Help admins ensure IT resources continue running optimally. Identify trends and patterns that may indicate impending failures or error conditions for valuable assets before they happen. Compare satellites in a fleet or constellation in terms of number of alarms, number of command sent to them, etc.. Answer questions like "Are the operations support needs increasing over the past year?" or "Have we seen this combination of alarm conditions before?" But really, once the tools are readily available the users will start realizing what can be done with their new powers. In this presentation we will show the results of analyzing millions of actual mission operations log messages, how the results can be displayed to the user, and how new products now available as open source can be applied to the challenges of large scale time-tagged text-based mission operations messages. Flight operations team members believe that this is a powerful new option for how they assess overall system and space asset health. Technical descriptions of the design, tools, and storage will be provided. One billion messages? Bring'em on!
MRO project is a system of systems requiring system engineering team to architect, design, integrate, test, and operate these systems at each level of the project. The challenge of system engineering mission objectives into a single mission architecture that can be integrated tested, launched, and operated. Systems engineering must translate high-level requirements into integrated mission design. Systems engineering challenges were overcome utilizing a combination by creative designs built into MRO's flight and ground systems: a) Design of sophisticated spacecraft targeting and data management capabilities b) Establishment of a strong operations team organization; c) Implementation of robust operational processes; and d) Development of strategic ground tools. The MRO system has met the challenge of its driving requirements: a) MRO began its two-year primary science phase on November 7, 2006, and by July 2007, met it minimum requirement to collect 15 Tbits of data after only eight months of operations. Currently we have collected 22 Tbits. b) Based on current performance, mission data return could return 70 Tbits of data by the end of the primary science phase in 2008.
Development of a permanent data system for SMD tests was studied that would simulate all elements of the shuttle onboard, telemetry, and ground data systems that are involved with spacelab operations. The onboard data system (ODS) and the ground data system (GDS) were utilized. The air-to-ground link was simulated by a hardwired computer-to-computer interface. A patch board system was used on board to select experiment inputs, and the downlink configuration from the ODS was changed by a crew keyboard entry to support each experiment. The ODS provided a CRT display of experiment parameters to enable the crew to monitor experiment performance. An onboard analog system, with recording capability, was installed to handle high rate data and to provide a backup to the digital system. The GDS accomplished engineering unit conversion and limit sensing, and provided realtime parameter display on CRT's in the science monitoring area and the test control area.
In the past, flight and ground systems have been developed largely-independently, with the flight system taking the lead, and dominating the development process. Operability issues have been addressed poorly in planning, requirements, design, I&T, and system-contracting activities. In many cases, as documented in lessons-learned, this has resulted in significant avoidable increases in cost and risk. With complex missions and systems, operability is being recognized as an important end-to-end design issue. Never-the-less, lessons-learned and operability concepts remain, in many cases, poorly understood and sporadically applied. A key to effective application of operability concepts is adopting a 'mission system' paradigm. In this paradigm, flight and ground systems are treated, from an engineering and management perspective, as inter-related elements of a larger mission system. The mission system consists of flight hardware, flight software, telecom services, ground data system, testbeds, flight teams, science teams, flight operations processes, procedures, and facilities. The system is designed in functional layers, which span flight and ground. It is designed in response to project-level requirements, mission design and an operations concept, and is developed incrementally, with early and frequent integration of flight and ground components.
The Ares I-X flight test, scheduled for 2009, is the first opportunity for the Constellation Program and Ares Projects to obtain important data on the in-flight loads, first stage recovery, and ground-handling characteristics of the Ares I crew launch vehicle. The flight test vehicle will incorporate a mix of flight and mockup hardware, reflecting an acceptable representation of the mass and outer mold line characteristics of the operational Ares I vehicle. It will be powered by a four-segment solid rocket motor from the Space Shuttle inventory and will include a fifth, inert spacer segment and new forward structures to make it the same shape as the Ares I first stage. The vehicle also includes mass simulators for the upper stage, Orion crew module, and launch abort system to match the outer mold line of Ares I; an active roll control system; and avionics derived from Shuttle and Atlas hardware. This suborbital mission will take the flight test vehicle from stacking in the Vehicle Assembly Building (VAB) at Kennedy Space Center (KSC) through liftoff, maximum dynamic pressure, first stage separation, and recovery. Ares I-X presented NASA with unique project management challenges. This presentation will address those unique challenges, including managing a virtual nationwide team under a constrained timeline; designing and building the launch vehicle and ground systems; working concurrently with Space Shuttle activities; and integrating technical and management functions. It also will identify key data collected and lessons learned from the flight that will be applied to future exploration missions.
The Operating Missions as Nodes on the Internet (OMNI) project at NASA's Goddard Space flight Center (GSFC), is demonstrating the use of standard Internet protocols for spacecraft communication systems. This year, demonstrations of Internet access to a flying spacecraft have been performed with the UoSAT-12 spacecraft owned and operated by Surrey Satellite Technology Ltd. (SSTL). Previously, demonstrations were performed using a ground satellite simulator and NASA's Tracking and Data Relay Satellite System (TDRSS). These activities are part of NASA's Space Operations Management Office (SOMO) Technology Program, The work is focused on defining the communication architecture for future NASA missions to support both NASA's "faster, better, cheaper" concept and to enable new types of collaborative science. The use of standard Internet communication technology for spacecraft simplifies design, supports initial integration and test across an IP based network, and enables direct communication between scientists and instruments as well as between different spacecraft, The most recent demonstrations consisted of uploading an Internet Protocol (IP) software stack to the UoSAT- 12 spacecraft, simple modifications to the SSTL ground station, and a series of tests to measure performance of various Internet applications. The spacecraft was reconfigured on orbit at very low cost. The total period between concept and the first tests was only 3 months. The tests included basic network connectivity (PING), automated clock synchronization (NTP), and reliable file transfers (FTP). Future tests are planned to include additional protocols such as Mobile IP, e-mail, and virtual private networks (VPN) to enable automated, operational spacecraft communication networks. The work performed and results of the initial phase of tests are summarized in this paper. This work is funded and directed by NASA/GSFC with technical leadership by CSC in arrangement with SSTL, and Vytek Wireless.
An initial design for a ground-based data management system which includes intelligent data abstraction and cataloging is described. The large quantity of data on some current and future NASA missions leads to significant problems in providing scientists with quick access to relevant data. Human screening of data for potential relevance to a particular study is time-consuming and costly. Intelligent databases can provide automatic screening when given relevent scientific parameters and constraints. The data management system would provide, at a minimum, information of availability of the range of data, the type available, specific time periods covered together with data quality information, and related sources of data. The system would inform the user about the primary types of screening, analysis, and methods of presentation available to the user. The system would then aid the user with performing the desired tasks, in such a way that the user need only specify the scientific parameters and objectives, and not worry about specific details for running a particular program. The design contains modules for data abstraction, catalog plan abstraction, a user-friendly interface, and expert systems for data handling, data evaluation, and application analysis. The emphasis is on developing general facilities for data representation, description, analysis, and presentation that will be easily used by scientists directly, thus bypassing the knowledge acquisition bottleneck. Expert system technology is used for many different aspects of the data management system, including the direct user interface, the interface to the data analysis routines, and the analysis of instrument status.