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.
The Ground Resource Allocation and Planning Environment (GRAPE 1.0) is a Web-based, collaborative team environment based on the Microsoft SharePoint platform, which provides Deep Space Network (DSN) resource planners tools and services for sharing information and performing analysis.
Most NASA projects and work activities are accomplished by teams of people. These teams are often geographically distributed - across NASA centers and NASA external partners, both domestic and international. NASA "virtual" teams are stressed by the challenge of getting team work done - across geographic boundaries and time zones. To get distributed work done, teams rely on established methods - travel, telephones, Video Teleconferencing (NASA VITS), and email. Time is our most critical resource - and team members are hindered by the overhead of travel and the difficulties of coordinating work across their virtual teams. Modern, Internet based team collaboration tools offer the potential to dramatically improve the ability of virtual teams to get distributed work done.
An Agency team collaboration pilot was conducted from July 2002 until June 2003 and then extended for an additional year. The objective of the pilot was to assess the value of collaboration tools and adoption processes as applied to NASA teams. In an effort to share knowledge and experiences, the lessons that have been learned thus far are documented in this report. Overall, the pilot has been successful. An entire system has been piloted - tools, adoption, and support. The pilot consisted of two collaboration tools, a team space and a virtual team meeting capability. Of the two tools that were evaluated, the team meeting tool has been more widely accepted. Though the team space tool has been met with a lesser degree of acceptance, the need for such a tool in the NASA environment has been evidenced. Both adoption techniques and support were carefully developed and implemented in a way that has been well received by the pilot participant community.
This paper describes a measurement methodology developed for assessing the readiness, and identifying opportunities for improving the effectiveness, of distributed collaborative design teams preparing to conduct a coccurent design session.
The Interagency Arctic Research Policy Committee (IARPC) is tasked with implementation of the Arctic Research Plan (ARP) by coordinating representatives from federal and state agencies, academic, industry, and Indigenous partners with interests in Arctic research. IARPC is organized into several collaboration teams and discipline-specific communities of practice that interface on the IARPC Collaborations website. The Early Career Community of Practice (ECCoP) is one such community that was established to promote the research of early career researchers (ECR) and increase ECR engagement with the ARP, program managers, collaboration teams, and communities of practice. The ECCoP has grown to develop regular newsletters promoting recent ECR research publications ad sharing training, job, funding, and collaboration opportunities relevant to community members at all life stages that self-identify as ECRs. Within IARPC, the ECCoP continues to promote ECR participation in monthly community of practice meetings and webinars and to report on ECR efforts that contribute to deliverables of the ARP Biennial Implementation Plan. Recent activity of the ECCoP includes developing an annual survey of the ECR cohort on IARPC to follow change in demographics over time and to identify community needs to improve diversity and inclusion in the polar research space and to address gaps in training needs for ECRs.
Human teams collaborate by establishing roles, changing functional authorities, maintaining team cognition, coordinating, and mutually helping one another close control loops. These complex inter-actions are inspiring novel concepts to improve human-machine and multi-machine collaboration. However, these new systems face engineering gaps in modeling, analysis, design, and assurance. As such, few have been fielded in safety-critical domains like aerospace. To analyze safety, this paper introduces a system-theoretic framework to describe interactions that are—or are planned to be—used in multi-controller systems. It outlines a taxonomy of seven structural dimensions that influence controller interactions and nine dynamics observed in collaborative control that are defined using Systems Theory. An analyzed set of 101 controller interactions in aerospace systems demonstrates how to apply the framework and that designers are trying to create more sophisticated systems. This framework provides the foundation to extend system-theoretic hazard analysis techniques to systematically find collabora-tive-control causal factors.
Explore the source record for details and available documents.
Over the past year few years, an international collaboration has developed a pilot project under the auspices of Committee on Earth Observation Satellite (CEOS) Disasters team. The overall team consists of civilian satellite agencies. For this pilot effort, the development team consists of NASA, Canadian Space Agency, Univ. of Maryland, Univ. of Colorado, Univ. of Oklahoma, Ukraine Space Research Institute and Joint Research Center(JRC) for European Commission. This development team collaborates with regional , national and international agencies to deliver end-to-end disaster coverage. In particular, the team in collaborating on this effort with the Namibia Department of Hydrology to begin in Namibia . However, the ultimate goal is to expand the functionality to provide early warning over the South Africa region. The initial collaboration was initiated by United Nations Office of Outer Space Affairs and CEOS Working Group for Information Systems and Services (WGISS). The initial driver was to demonstrate international interoperability using various space agency sensors and models along with regional in-situ ground sensors. In 2010, the team created a preliminary semi-manual system to demonstrate moving and combining key data streams and delivering the data to the Namibia Department of Hydrology during their flood season which typically is January through April. In this pilot, a variety of moderate resolution and high resolution satellite flood imagery was rapidly delivered and used in conjunction with flood predictive models in Namibia. This was collected in conjunction with ground measurements and was used to examine how to create a customized flood early warning system. During the first year, the team made use of SensorWeb technology to gather various sensor data which was used to monitor flood waves traveling down basins originating in Angola, but eventually flooding villages in Namibia. The team made use of standardized interfaces such as those articulated under the Open Cloud Consortium (OGC) Sensor Web Enablement (SWE) set of web services was good [1][2]. However, it was discovered that in order to make a system like this functional, there were many performance issues. Data sets were large and located in a variety of location behind firewalls and had to be accessed across open networks, so security was an issue. Furthermore, the network access acted as bottleneck to transfer map products to where they are needed. Finally, during disasters, many users and computer processes act in parallel and thus it was very easy to overload the single string of computers stitched together in a virtual system that was initially developed. To address some of these performance issues, the team partnered with the Open Cloud Consortium (OCC) who supplied a Computation Cloud located at the University of Illinois at Chicago and some manpower to administer this Cloud. The Flood SensorWeb [3] system was interfaced to the Cloud to provide a high performance user interface and product development engine. Figure 1 shows the functional diagram of the Flood SensorWeb. Figure 2 shows some of the functionality of the Computation Cloud that was integrated. A significant portion of the original system was ported to the Cloud and during the past year, technical issues were resolved which included web access to the Cloud, security over the open Internet, beginning experiments on how to handle surge capacity by using the virtual machines in the cloud in parallel, using tiling techniques to render large data sets as layers on map, interfaces to allow user to customize the data processing/product chain and other performance enhancing techniques. The conclusion reached from the effort and this presentation is that defining the interoperability standards in a small fraction of the work. For example, once open web service standards were defined, many users could not make use of the standards due to security restrictions. Furthermore, once an interoperable sysm is functional, then a surge of users can render a system unusable, especially in the disaster domain.
The Florida State University (FSU) team participated extensively in the pre-mission planning for TRACE-P through meetings, telephone calls, and e-mails. During Spring 2001, Prof. Fuelberg served as DC-8 Mission Meteorologist during the field campaign. He prepared meteorological guidance for each flight of the DC-8 and flew on each mission. After the field phase, FSU prepared various meteorological products, included backward air trajectories, for each flight of the DC-8 and P-3B. These were posted on the FSU and NASA-GTE web sites for use by all the Science Team. During the two-year post mission period, FSU conducted research relating meteorology to atmospheric chemistry during TRACE-P. This led to three journal articles in the Journal of Geophysical Research. FSU personnel were the lead authors on each of these articles. Abstracts of these articles are attached. In addition, the FSU team collaborated with other members of the TRACE-P Science Team to incorporate meteorological factors into their research. A list of publications resulting from these interactions is included.
There have been significant recent efforts in addressing mitigation approaches to neutralize Potentially Hazardous Asteroids (PHA). One such research effort was performed in 2015 by an integrated, inter-disciplinary team of asteroid scientists, energy deposition modeling scientists, payload engineers, orbital dynamist engineers, spacecraft discipline engineers, and systems architecture engineer from NASAs Goddard Space Flight Center (GSFC) and the Department of Energy (DoE) National Nuclear Security Administration (NNSA) laboratories (Los Alamos National Laboratory (LANL), Lawrence Livermore National Laboratories (LLNL) and Sandia National Laboratories). The study team collaborated with GSFCs Integrated Design Centers Mission Design Lab (MDL) which engaged a team of GSFC flight hardware discipline engineers to work with GSFC, LANL, and LLNL NEA-related subject matter experts during a one-week intensive concept formulation study in an integrated concurrent engineering environment. This team has analyzed the first of several distinct study cases for a multi-year NASA research grant. This Case 1 study references the Near-Earth Asteroid (NEA) named Bennu as the notional target due to the availability of a very detailed Design Reference Asteroid (DRA) model for its orbit and physical characteristics (courtesy of the Spectral Interpretation, Resource Identification, Security-Regolith Explorer (OSIRIS-REx) mission team). The research involved the formulation and optimization of spacecraft trajectories to intercept Bennu, overall mission and architecture concepts, and high-fidelity modeling of both kinetic impact (spacecraft collision to change a NEAs momentum and orbit) and nuclear detonation effects on Bennu, for purposes of deflecting Bennu.
Presented is a design tool and process that connects several disciplines which are needed in the complex and integrated design of high performance reusable single stage to orbit (SSTO) vehicles. Every system is linked to every other system and in the case of SSTO vehicles with air breathing propulsion, which is currently being studied by the National Aeronautics and Space Administration (NASA); the thermal protection system (TPS) is linked directly to almost every major system. The propulsion system pushes the vehicle to velocities on the order of 15 times the speed of sound in the atmosphere before pulling up to go to orbit which results high temperatures on the external surfaces of the vehicle. Thermal protection systems to maintain the structural integrity of the vehicle must be able to mitigate the heat transfer to the structure and be lightweight. Herein lies the interdependency, in that as the vehicle's speed increases, the TPS requirements are increased. And as TPS masses increase the effect on the propulsion system and all other systems is compounded. To adequately determine insulation masses for a vehicle such as the one described above, the aeroheating loads must be calculated and the TPS thicknesses must be calculated for the entire vehicle. To accomplish this an ascent or reentry trajectory is obtained using the computer code Program to Optimize Simulated Trajectories (POST). The trajectory is then used to calculate the convective heat rates on several locations on the vehicles using the Miniature Version of the JA70 Aerodynamic Heating Computer Program (MINIVER). Once the heat rates are defined for each body point on the vehicle, then insulation thicknesses that are required to maintain the vehicle within structural limits are calculated using Systems Improved Numerical Differencing Analyzer (SINDA) models. If the TPS masses are too heavy for the performance of the vehicle the process may be repeated altering the trajectory or some other input to reduce the TPS mass. The problem described is an example of the need for collaborative design and analysis. Analysis tools are being developed to facilitate these collaborative efforts. RECIPE is a cross-platform application capable of hosting a number of engineers and designers across the Internet for distributed and collaborative engineering environments. Such integrated system design environments allow for collaborative team design analysis for performing individual or reduced team studies. The analysis tools mentioned earlier are commonly run on different platforms and are usually run by different people. To facilitate the larger number of potential runs that may need to be made, RECIPE connects the computer codes that calculate the trajectory data, heat rate data, and TPS masses so that the output from each tool is easily transferred to the model input files that need it. This methodology is being applied to solve launch vehicle thermal design problems to shorten the design cycle, and enable the project team to evaluate design options. Results will be presented indicating the effectiveness of this as a collaborative design tool.
Scientific computing is at an inflection point. Artificial intelligence (AI) is reshaping how scientific software is developed, how teams collaborate, how projects are governed, and how the next generation is trained. Drawing on insights from a 2025 workshop report, this article argues that the future of discovery will depend on agile, robust ecosystems built through socio-technical co-design—the intentional integration of technical and human systems. This perspective is essential for ensuring that future scientific computing remains trustworthy, sustainable, and scalable. It combines advances in AI, high-performance computing, and software with new models for cross-disciplinary collaboration, education, and workforce development. Key recommendations include building modular, trustworthy AI-enabled software ecosystems; enabling teams to integrate AI into scientific workflows while preserving human creativity, integrity, and rigor; and developing adaptive training pathways that keep pace with rapid technological change. By sharing these perspectives, we hope to stimulate broader community dialogue and encourage coordinated action.
An important aspect of mission planning for NASA s operation of the International Space Station is the allocation and management of space for supplies and equipment. The Stowage, Configuration Analysis, and Operations Planning teams collaborate to perform the bulk of that planning. A Geometric Reasoning Engine is developed in a way that can be shared by the teams to optimize item placement in the context of crew planning. The ISS crew spends (at the time of this writing) a third or more of their time moving supplies and equipment around. Better logistical support and optimized packing could make a significant impact on operational efficiency of the ISS. Currently, computational geometry and motion planning do not focus specifically on the optimized orientation and placement of 3D objects based on multiple distance and containment preferences and constraints. The software performs reasoning about the manipulation of 3D solid models in order to maximize an objective function based on distance. It optimizes for 3D orientation and placement. Spatial placement optimization is a general problem and can be applied to object packing or asset relocation.
To paraphrase a famous quote, "No plan survives contact with the reality." Software (SW) development is often a classic example of this: whatever the plan was for a particular development, it often does not survive contact with technical realities, budget realities, program realities and schedule realities. Traditionally, SW development has followed a waterfall methodology with requirements being rigorously specified before the design, which was completed before the coding and unit testing started, which were in turn finished before validation and verification started. This model of SW engineering derives much from the HW engineering of large systems, and has been the standard methodology used in US government software acquisitions and systems for decades, with highly variable results. US Government SW requirements are built around Waterfall concepts, which assume that the plan will survive contact with reality, or at least that modifications to the plan are relatively small, and relatively few.Because of the inefficiencies and difficulties inherent in Waterfall, the commercial SW world started using a different SW development methodology called Agile more than 20 years ago. Agile believes that a plan should evolve and learn rapidly in response to the realities encountered. At its core, there are a few key elements of Agile:- A small team of people which is highly flexible and adaptive. The team collaborates and interoperates through sophisticated development architectures and release environments- An iterative, incremental development and release approach which is based upon the concept that knowledge comes from experience within the team, and that the team makes decisions based upon what it knows- A team culture which prizes transparency, inspection and adaptation. These values are necessary so that the team experience and decision making is transparent and responsive to the realities encountered during development and testingSo, how to use Agile in a US Government environment? GMSEC (Goddard Mission Services Evolution Center) develops satellite ground system software for NASA and other US Government agencies. The SW developed by the team contains a large code base of many applications used within satellite mission operations centers. It spans the full gamut of SW development types: from SW which is in a classic maintenance and sustainment mode, to new developments with a fairly well understood scope and approach, to new developments whose scope and approach are quite unclear and which require significant research and prototyping. Team members move between all of these different types of SW development. Waterfall was inadequate to the programmatic and technical needs of the team, as well as the various types of SW development being done. The software plan was not surviving contact with the technical and programmatic realities experienced by the team. To address this, the team started a small pilot project in 2016 to test the use of Agile within a small subset of the team for a new web services application. In early 2018, the use of Agile was expanded to the whole team and all the software, but we had to fulfill the NASA SW development requirements. And we needed to do this while still remaining true to the key Agile elements of transparency, inspection and adaption. In order to do this, the team worked very closely with the Software Process Improvement (SPI) team at NASA Goddard, as well as NASA engineering manageme
The Republic of the Maldives is a low-lying island nation in the Indian Ocean which has experienced rapid urbanization, landcover changes, and sea level rise over recent years. The growth of tourism, coastal erosion, and urbanization have all driven land reclamation efforts across many islands. As in-situ landcover change monitoring has proven difficult across the vast archipelago, the NASA DEVELOP team collaborated with the Maldives Ministry of Environment, Climate Change, and Technology; USAID; and the U.S. Department of State, to utilize Earth observations to predict sea level rise impacts on coastal infrastructure. The team used a supervised classification algorithm within Google Earth Engine to create land use maps and time series analyses of nine islands and atolls using imagery from Landsat 7 Enhanced Thematic Mapper Plus, Landsat 8 Operational Land Imager, Sentinel-2 Multispectral Instrument, and PlanetScope, covering a combined period of 2000 through 2023. Additionally, the team projected coastal inundation with a modified deterministic Bathtub model utilizing elevation data from CoastalDEM and 2050-2100 Shared Socioeconomic Pathway scenarios identified in the NASA Sea Level Rise Projection Tool. The team found that islands undergoing urban growth experienced a 23% decrease in vegetation between 2014 and 2022. Furthermore, the model predicted that 51–57% of the study area’s-built environment has a chance of inundation by 2100 under the low and high sea level scenarios. These analyses demonstrate how remote sensing can be used to both track land use changes over time and project how coastlines will be affected by sea level rise.
Simulations are essential for engineering design. These virtual realities provide characteristic data to scientists and engineers in order to understand the details and complications of the desired mission. A standard development simulation package known as Trick is used in developing a source code to model a component (federate in HLA terms). The runtime executive is integrated into an HLA based distributed simulation. TrickHLA is used to extend a Trick simulation for a federation execution, develop a source code for communication between federates, as well as foster data input and output. The project incorporates international cooperation along with team collaboration. Interactions among federates occur throughout the simulation, thereby relying on simulation interoperability. Communication through the semester went on between participants to figure out how to create this data exchange. The NASA intern team is designing a Lunar Rover federate and a Lunar Shuttle federate. The Lunar Rover federate supports transportation across the lunar surface and is essential for fostering interactions with other federates on the lunar surface (Lunar Shuttle, Lunar Base Supply Depot and Mobile ISRU Plant) as well as transporting materials to the desired locations. The Lunar Shuttle federate transports materials to and from lunar orbit. Materials that it takes to the supply depot include fuel and cargo necessary to continue moon-base operations. This project analyzes modeling and simulation technologies as well as simulation interoperability. Each team from participating universities will work on and engineer their own federate(s) to participate in the SISO Spring 2011 Workshop SIW Smackdown in Boston, Massachusetts. This paper will focus on the Lunar Rover federate.
Launched on October 15, 1997, the Cassini-Huygens spacecraft began its ambitious journey to the Saturnian system with a complex suite of 12 scientific instruments, and another 6 instruments aboard the European Space Agencies Huygens Probe. Over the next 6 1/2 years, Cassini would continue its relatively simplistic cruise phase operations, flying past Venus, Earth, and Jupiter. However, following Saturn Orbit Insertion (SOI), Cassini would become involved in a complex series of tasks that required detailed resource management, distributed operations collaboration, and a data base for capturing science objectives. Collectively, these needs were met through a web-based software tool designed to help with the Cassini uplink process and ultimately used to generate more robust sequences for spacecraft operations. In 2001, in conjunction with the Southwest Research Institute (SwRI) and later Venustar Software and Engineering Inc., the Cassini Information Management System (CIMS) was released which enabled the Cassini spacecraft and science planning teams to perform complex information management and team collaboration between scientists and engineers in 17 countries. Originally tailored to help manage the science planning uplink process, CIMS has been actively evolving since its inception to meet the changing and growing needs of the Cassini uplink team and effectively reduce mission risk through a series of resource management validation algorithms. These algorithms have been implemented in the web-based software tool to identify potential sequence conflicts early in the science planning process. CIMS mitigates these sequence conflicts through identification of timing incongruities, pointing inconsistencies, flight rule violations, data volume issues, and by assisting in Deep Space Network (DSN) coverage analysis. In preparation for extended mission operations, CIMS has also evolved further to assist in the planning and coordination of the dual playback redundancy of highvalue data from targets such as Titan and Enceladus. This paper will outline the critical role that CIMS has played for Cassini in the distributed ops paradigm throughout operations. This paper will also examine the evolution that CIMS has undergone in the face of new science discoveries and fluctuating operational needs. And finally, this paper will conclude with theoretical adaptation of CIMS for other projects and the potential savings in cost and risk reduction that could potentially be tapped into by future missions.
In January 2004, President George W. Bush unveiled his vision for NASA to advance U.S. scientific, security, and economic interests through a robust space exploration program. This vision includes the goal to extend human presence across the solar system, starting with a human return to the Moon no later than 2020, in preparation for human exploration of Mars and other destinations. In response to this vision, NASA has created the Office of Exploration Systems (OExS) to develop the innovative technologies, knowledge, and infrastructures to explore and support decisions about human exploration destinations, including the development of a new Crew Exploration Vehicle (CEV). Within the OExS organization, NASA is implementing Simulation Based Acquisition (SBA), a robust Modeling & Simulation (M&S) environment integrated across all acquisition phases and programs/teams, to make the realization of the President s vision more certain. Executed properly, SBA will foster better informed, timelier, and more defensible decisions throughout the acquisition life cycle. By doing so, SBA will improve the quality of NASA systems and speed their development, at less cost and risk than would otherwise be the case. SBA is a comprehensive, Enterprise-wide endeavor that necessitates an evolved culture, a revised spiral acquisition process, and an infrastructure of advanced Information Technology (IT) capabilities. SBA encompasses all project phases (from requirements analysis and concept formulation through design, manufacture, training, and operations), professional disciplines, and activities that can benefit from employing SBA capabilities. SBA capabilities include: developing and assessing system concepts and designs; planning manufacturing, assembly, transport, and launch; training crews, maintainers, launch personnel, and controllers; planning and monitoring missions; responding to emergencies by evaluating effects and exploring solutions; and communicating across the OExS enterprise, within the Government, and with the general public. The SBA process features empowered collaborative teams (including industry partners) to integrate requirements, acquisition, training, operations, and sustainment. The SBA process also utilizes an increased reliance on and investment in M&S to reduce design risk. SBA originated as a joint Industry and Department of Defense (DoD) initiative to define and integrate an acquisition process that employs robust, collaborative use of M&S technology across acquisition phases and programs. The SBA process was successfully implemented in the Air Force s Joint Strike Fighter (JSF) Program.