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.
This paper discusses the knowledge acquisition issues involved in transitioning their novel technology in to space flight software, developing the planer in the context of a large software projet and completing the work under a compressed development schedule.
With a revived focus to create a permeant presence on the moon and in preparation for future Mars exploration, it is imperative that all re-sources are utilized to their fullest potential. In-Situ Resource Utilization (ISRU) will be critical for future mission success as it would enable independent operation of missions while minimally relying on the complex supply chain created between the Earth, moon and Mars. One of the most critical resources that have been identified for ISRU is the creation of liquid oxygen (O2) for not only breathable air, but also for rocket fuel. On the moon and potentially Mars, one of the most O2 rich resources is in the presence of regolith. Although there are numerous minerals within regolith and various processes to extract O2, this is not the scope of this paper. Since the O2 extraction method can vary, a critical standardized analytical method is needed to verify O2 (or oxygenated precursor compounds) for extraction efficiency and purity. Our group utilizes a modified consumer off-the-shelf (COTS), Residual Gas Analyzer (RGA) Single Quadrupole Mass Spectrometer (QMS). Due to the current field mission requirements, the gas analysis module will need to rely only on mass-to-charge ratios (m/z) and peak intensities to differentiate and quantitate targeted gas-phase reactants or products, i.e. carbon monoxide (CO), carbon dioxide (CO2), methane (CH4) and hydrogen (H2). However, due to solar wind implanted volatiles and various other compounds present in lunar regolith, such as nitrogen (N2), helium (He), and deuterium (D2), deconvolution and quantification of isobaric compounds becomes quite difficult. Specifically, the presence of N2 makes quantification of CO, an oxygenated precursor, difficult due to both compounds having a peak at m/z 28. Approaches to differentiate isobaric components: Initially, the solution to overcome isobaric overlap was to use isotopic ratios, particularly be-tween carbon-13 and nitrogen-15. Although limited literature discuss isotopic composition and attempt to quantify the ratios, variation is particularly high and limited to a few lunar regolith samples. The following were identified as potential approaches to quantify isobaric species, N2 and CO, using our RGA. Threshold Ionization. CO and N2 both have peaks at m/z 28, but only N2 is capable of producing a peak at m/z 7. While a N2 peak at m/z 7 is generally rare, instrument parameters can be optimized in order to maximize the peak intensity. Typically a standard ionization energy of 70 eV is used to monitor a batch process and would produce reliable results for a majority of the reactants or products that we are interested in quantifying. However, to analyze the rare molecular fragment of N2 (N2+ at m/z 7), a different ionization energy may be beneficial. Threshold Ionization Mass Spectrometry (TIMS) will be explored to optimize the N2+ peak at m/z 7 by varying parameters such as ionization energy and pressure. Therefore, a quantitative value at m/z 7 will be used to determine the product gas concentration of N2, which will be subtracted from the total concentration determined at m/z 28 enabling us to approximate the amount of CO. Secondary Detector (infrared gas detector, IR). Another approach to quantitate and differentiate be-tween isobaric components is to leverage alternative modes of detection. Unlike mass spectrometry, which generally uses a separation step prior to analysis (i.e. gas chromatography), IR produces energy that is specifically absorbed depending on the bond and configuration of the molecule. This technique could be leveraged since it is generally only active on non-symmetric molecules, i.e. CO. Utilizing concentrations of CO determined from another detector could help correct concentrations of CO obtained from the QMS. However, the inclusion of another detector adds additional mission requirements, such as power, software changes and avionics updates that add additional cost and schedule requirements.
The Mars 2020 Mission, scheduled to land on Mars February 18, 2021, has developed an onboard scheduling system [1]. The rationale for the onboard scheduler is to enable the Perseverance rover to adjust its activities in response to activities taking longer or shorter than planned, or using more or less resources than expected, as effectively using these resources could significantly improve rover productivity [2]. If deployed, the onboard scheduler would be an unprecedented use of Artificial Intelligence/Autonomy onboard software in a key role for a major mission.
The international character of future manned space missions will compel the involvement of several international space agencies in mission planning tasks. Additionally, the community of users requires a higher degree of freedom for experiment planning. Both of these problems can be solved by a decentralized mission planning concept using the so-called 'envelope method,' by which resources are allocated to users by distributing resource profiles ('envelopes') which define resource availabilities at specified times. The users are essentially free to plan their activities independently of each other, provided that they stay within their envelopes. The new developments were aimed at refining the existing vague envelope concept into a practical method for decentralized planning. Selected critical functions were exercised by planning an example, founded on experience acquired by the MSCC during the Spacelab missions D-1 and D-2. The main activity regarding future mission planning tasks was to improve the existing MSCC mission planning system, using new techniques. An electronic interface was developed to collect all formalized user inputs more effectively, along with an 'envelope generator' for generation and manipulation of the resource envelopes. The existing scheduler and its data base were successfully replaced by an artificial intelligence scheduler. This scheduler is not only capable of handling resource envelopes, but also uses a new technology based on neuronal networks. Therefore, it is very well suited to solve the future scheduling problems more efficiently. This prototype mission planning system was used to gain new practical experience with decentralized mission planning, using the envelope method. In future steps, software tools will be optimized, and all data management planning activities will be embedded into the scheduler.
The diversity of accelerators in computer systems poses significant challenges for software developers, such as managing vendor-specific compiler toolchains, code fragmentation requiring different kernel implementations, and performance portability issues. To address these, the Intelligent Runtime System (IRIS) was developed. IRIS works across various systems, from smartphones to supercomputers, enabling automatic performance scaling based on available accelerators. It introduces abstract tasks for seamless execution transitions between accelerators while ensuring memory consistency and task dependencies. Although IRIS simplifies system details, optimal dynamic scheduling still requires user input to understand workload structures. To address this, we introduce a new scheduling policy for IRIS, termed IRIS-GNN, which is the first IRIS hybrid policy that operates in conjunction with the dynamic policies. This policy employs a Graph-Neural Network (GNN) to conduct Graph Classification of any task graphs submitted to IRIS. This GNN analyzes the structure and attributes of the task graph, categorizing it as either locality, concurrency, or mixed. This classification subsequently guides the selection of the dynamic policy used by IRIS. We provide a comparison of the performance of IRIS-GNN against the complete spectrum of IRIS’s dynamic policies, assess the overhead introduced by the GNN within this scheduling framework, and ultimately explore its practical application in real-world scenarios.
A system of software implements an extended version of an approach, denoted shared activity coordination (SHAC), to the interleaving of planning and the exchange of plan information among organizations devoted to different missions that normally communicate infrequently except that they need to collaborate on joint activities and/or the use of shared resources. SHAC enables the planning and scheduling systems of the organizations to coordinate by resolving conflicts while optimizing local planning solutions. The present software provides a framework for modeling and executing communication protocols for SHAC. Shared activities are represented in each interacting planning system to establish consensus on joint activities or to inform the other systems of consumption of a common resource or a change in a shared state. The representations of shared activities are extended to include information on (1) the role(s) of each participant, (2) permissions (defined as specifications of which participant controls what aspects of shared activities and scheduling thereof), and (3) constraints on the parameters of shared activities. Also defined in the software are protocols for changing roles, permissions, and constraints during the course of coordination and execution.
This document summarizes the software releases and capabilities delivered to CLT and/or DFW during the ATD-2 Phase 2 field evaluation.
The Automated Scheduling and Planning Environment (ASPEN) computer program has been updated to version 3.0. ASPEN is a modular, reconfigurable, application software framework for solving batch problems that involve reasoning about time, activities, states, and resources. Applications of ASPEN can include planning spacecraft missions, scheduling of personnel, and managing supply chains, inventories, and production lines. ASPEN 3.0 can be customized for a wide range of applications and for a variety of computing environments that include various central processing units and random access memories.
Future exploration missions to Mars will have increased need for crew autonomy. Crew Health & Performance (CHP) related data on the ISS is currently, manually downlinked and in disparate locations, which limits crew autonomy for future missions. The CHP-IDA project is developing a backend data system platform that grants the ability to seamlessly collect, store, process, and display CHP-related data for exploration missions. This platform allows for integration of data and advanced analytics that offer crew and ground teams better insight into the crew’s health and performance. It also enables applications that can improve the crew’s ability to provide more autonomous medical care during exploration missions. Data will be collected automatically to reduce crew and ground team time and effort and will synchronize across all in-mission vehicles, habitats, and ground as communication delay permits. The Human Research Program’s (HRP) Medical Data Architecture (MDA) project focused on this backend data architecture but for medical data only. The CHP-IDA project, a joint effort between HRP’s Exploration Medical Capability (ExMC) element and the Exploration Medical Integrated Product Team (XMIPT), expands this capability to all relevant CHP-related data. The additional inputs from nutrition, environment, exercise, radiation, and any other relevant sources will give more insight into crew’s health and performance. Currently, the Human Systems Engineering and Integration Division at Johnson Space Center (JSC) is designing the system. The team completed a system requirements review (SRR) in FY22 and now the focus is on core software development, testbed buildup, and use case scenario demonstration. An end-to-end demonstration with multiple data sources across CHP domains is schedule for the end of FY24 where all three focus areas will be displayed. Following this ground demo, the software will be completed, tested, and validated for flight.
The main effort in October 1992 was for the development and of the Astrophysics Data System (ADS) 3.1 graphical interface (GUI) and the preparation for its release. The beta-release for the GUI was made available to the nodes for testing. Development of the Abstract Server progressed satisfactorily. A test version was prepared for the ADASS meeting. Another major effort was the preparation for the user and nodes meetings on 5 and 6 November and for the ADASS conference on 2-4 November. February 1993 was highlighted by the preparation for the update release and its associated problems. We have the okay from the Commerce Department to export ADS. Foreign users can now sign on and receive the software. The main event during June was the AAS meeting. In the summer, the project decided on a new release schedule. The next major release is scheduled for January 1994 and will include major architectural improvements. In late spring 1994, a major release will include the new networking software.
The High-Luminosity Large Hadron Collider (HL-LHC), scheduled to start operating in 2030, aims to increase the instantaneous luminosity by a factor of 10 compared to the LHC. To match this increase, the ATLAS experiment has been implementing a major upgrade program divided into two phases. The first phase (Phase-I), completed in 2022, introduced new trigger and detector systems that have been used during the Run 3 data taking period which began in July 2022. These systems have been used in conjunction with the new Data Acquisition (DAQ) Readout system, based on a software application called Software Readout Driver (SW ROD). SW ROD receives and aggregates data from the front-end electronics via the Front-End Link eXchange (FELIX) system and passes aggregated data fragments to the High-Level Trigger (HLT) system. During Run 3, SW ROD operates in parallel with the legacy Readout System (ROS) at an input rate of 100 kHz. For the Phase-II, the legacy ROS will be completely replaced with a new system based on the next generation of FELIX and an evolution of the SW ROD application called Data Handler. Data Handler has the same functional requirements as SW ROD but must be able to operate at an input rate of 1 MHz. To facilitate this evolution the SW ROD has been implemented using plugin architecture. This contribution presents the design and implementation of the SW ROD application for Run 3, along with the strategy for its evolution to the Phase-II Readout system. It discusses the lessons learned during Run 3 and describes the challenges that have been addressed to accomplish the demanding performance requirements of HL-LHC.
By combining the best of automated and human decision-making in scheduling many advantages can accrue. The joint performance of the user and system is potentially much better than either alone. Features of the MAESTRO scheduling system serve to illustrate concepts of user/software cooperation. MAESTRO may be operated at a user-determinable and dynamic level of autonomy. Because the system allows so much flexibility in the allocation of decision-making responsibilities, and provides users with a wealth of information and other support for their own decision-making, better overall schedules may result.
Dielectrophoresis-Based Particle Sensor Using Nanoelectrode Arrays; Multi-Dimensional Damage Detection for Surfaces and Structures; ULTRA: Underwater Localization for Transit and Reconnaissance Autonomy; Autonomous Cryogenic Leak Detector for Improving Launch Site Operations; Submillimeter Planetary Atmospheric Chemistry Exploration Sounder; Method for Reduction of Silver Biocide Plating on Metal Surfaces; Silicon Micromachined Microlens Array for THz Antennas; Forward-Looking IED Detector Ground Penetrating Radar; Fully Printed, Flexible, Phased Array Antenna for Lunar Surface Communication, Battery Charge Equalizer with Transformer Array; An Efficient, Highly Flexible Multi-Channel Digital Downconverter Architecture; Dimmable Electronic Ballast for a Gas Discharge Lamp; Conductive Carbon Nanotube Inks for Use with Desktop Inkjet Printing Technology; Enhanced Schapery Theory Software Development for Modeling Failure of Fiber-Reinforced Laminates; High-Performance, Low-Temperature-Operating, Long-Lifetime Aerospace Lubricants; Carbon Nanotube Microarrays Grown on Nanoflake Substrates; Differential Muon Tomography to Continuously Monitor Changes in the Composition of Subsurface Fluids; Microgravity Drill and Anchor System; 20 Granular Media-Based Tunable Passive Vibration Suppressor; 21 Miga Aero Actuator and 2D Machined Mechanical Binary Latch; Micro-XRF for In Situ Geological Exploration of Other Planets; Hydrogen-Enhanced Lunar Oxygen Extraction and Storage Using Only Solar Power; Uplift of Ionospheric Oxygen Ions During Extreme Magnetic Storms; Miniaturized, High-Speed, Modulated X-Ray Source; Hollow-Fiber Spacesuit Water Membrane Evaporator 25 High-Power Single-Mode 2.65-micrometers InGaAsSb/AlInGaAsSb Diode Lasers; Optical Device for Converting a Laser Beam Into Two Co-aligned but Oppositely Directed Beams; A Hybrid Fiber/Solid-State Regenerative Amplifier with Tunable Pulse Widths for Satellite Laser Ranging; X-Ray Diffractive Optics; SynGenics Optimization System (SynOptSys); 29 CFD Script for Rapid TPS Damage Assessment; radEq Add-On Module for CFD Solver Loci-CHEM; Science Opportunity Analyzer (SOA) Version 8; 30 Autonomous Byte Stream Randomizer; Distributed Engine Control Empirical/Analytical Verification Tools; Dynamic Server-Based KML Code Generator Method for Level-of-Detail Traversal of Geospatial Data; Automated Planning of Science Products Based on Nadir Overflights and Alerts for Onboard and Ground Processing; Linked Autonomous Interplanetary Satellite Orbit Navigation; Risk-Constrained Dynamic Programming for Optimal Mars Entry, Descent, and Landing; Scheduling Operations for Massive Heterogeneous Clusters; Deepak Condenser Model (DeCoM); Flight Software Math Library; Recirculating 1-K-Pot for Pulse-Tube Cryostats; 35 Method for Processing Lunar Regolith Using Microwaves; Wells for In Situ Extraction of Volatiles from Regolith (WIEVR); and Estimating the Backup Reaction Wheel Orientation Using Reaction Wheel Spin Rates Flight Telemetry from a Spacecraft.
The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.
This paper describes the application of an automated planning and scheduling system to the NASA Earth Orbiting 1 (EO-1) mission. The planning system, ASPEN, is used to autonomously schedule the daily activites of the satellite. The satellite and operations constraints are encoded within a software model used by the planner.
Agile development methods, which have gone from outlier to mainstream in software development, are poised to expand into all aspects of space mission development. Modern software development operates on a principle of continuous deployment, where progress is verified not with conventional metrics, but with a continuous build, available to key stakeholders, enabling direct examination of the state of the code base, and assessment of progress through demonstration of capability. Delivery times are measured in weeks, not months. Stakeholders are part of the process on an ongoing basis. The cost of change is comparatively low and requirements, which often are not precisely defined at the start of a project, may be iteratively refined in a series of agile development cycles. Agile methods are compatible with traditional system engineering methods and may be tailored to the space operations environment. The low cost of change and iterative development cycles of agile enable requirements to be defined as outcomes and constraints, with design details to be refined during the development cycle. We are now at a point where agile methods may be extended beyond software, to Mission Systems, including the Mission Operations System and the Ground Data System. For NASA’s VIPER Lunar Rover Mission, scheduled to land at a lunar pole in late 2023, we are developing the Mission System using agile methods. As in agile software, where the measure of progress is working code, in agile mission system development, the measure of capability is what we can demonstrate. Demonstrations over presentations. We demonstrate mission system capability using simulations. The concept of operations, from commanding, to driving the rover, to how we downlink images for evaluation for a near-real time command cycle, will be tested and proven in simulation, years before we begin the traditional simulation cycle for training. “Say it then simulate it.” We develop and refine our designs using simulations, with an emphasis on new components of the system that are not well known early. For example, the required duration of a mission planning cycle for a lunar surface asset such as VIPER, that operates twenty-four hours a day, seven days a week, with continuous communications and a unique set of constraints based on the physics of the lunar poles and the line of site to Earth, is a unique problem in mission planning that is unlikely to be solved in a series of meetings. A small number of requirements specifying the outcomes may serve as the jumping off point to an agile development cycle, with demonstration in simulations. We have already demonstrated this process with simulations of rover driver decision time. VIPER is driven using near-real time command and control to waypoints. The driver decision time between waypoints is a fundamental enabling unit of productivity to accomplish the mission timeline. We have validated driver decision time in simulations of rover driving at the lunar South Pole, using the prototype mission tools for driving, command and control. The capability to develop and refine designs using simulations as part of agile Mission System development cycle changes the nature of team interactions, creating a focus on doing, rather than analyzing and documenting. Waterfall development cycles were, in part, a product of the significant cost of change in the early days of spaceflight. When the cost of change is high, it is vital to get your requirements right at the outset, because the system will be built to those specifications, and, when change is expensive, you better get it right early. However, modern technology has greatly lowered the cost of change, enabling iterative, rapid development cycles, in which key operations concepts may be tested and refined during development. Extending agile development to the Mission System for VIPER is a significant step in moving agile development methods for space operations beyond software, to the Mission System.
Software has been developed to perform a number of functions essential to autonomous operation in the Autonomous Sciencecraft Experiment (ASE), which is scheduled to be demonstrated aboard a constellation of three spacecraft, denoted TechSat 21, to be launched by the Air Force into orbit around the Earth in January 2006. A prior version of this software was reported in Software for an Autonomous Constellation of Satellites (NPO-30355), NASA Tech Briefs, Vol. 26, No. 11 (November 2002), page 44. The software includes the following components: Algorithms to analyze image data, generate scientific data products, and detect conditions, features, and events of potential scientific interest; A program that uses component-based computational models of hardware to analyze anomalous situations and to generate novel command sequences, including (when possible) commands to repair components diagnosed as faulty; A robust-execution-management component that uses the Spacecraft Command Language (SCL) software to enable event-driven processing and low-level autonomy; and The Continuous Activity Scheduling, Planning, Execution, and Replanning (CASPER) program for replanning activities, including downlink sessions, on the basis of scientific observations performed during previous orbit cycles.