Search NASA⌕ Search

SEARCH · Search NASA

Results for “Process Knowledge Summary Report”

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.

25 records · Page 2

Systems engineering studies of on-orbit assembly operation

While the practice of construction has a long history, the underlying theory of construction is relatively young. Very little has been documented as to techniques of logistic support, construction planning, construction scheduling, construction testing, and inspection. The lack of 'systems approaches' to construction processes is certainly one of the most serious roadblocks to the construction of space structures. System engineering research efforts at CSC are aimed at developing concepts and tools which contribute to a systems theory of space construction. The research is also aimed at providing means for trade-offs of design parameters for other research areas in CSC. Systems engineering activity at CSC has divided space construction into the areas of orbital assembly, lunar base construction, interplanetary transport vehicle construction, and Mars base construction. A brief summary of recent results is given. Several models for 'launch-on-time' were developed. Launch-on-time is a critical concept to the assembly of such Earth-orbiting structures as the Space Station Freedom, and to planetary orbiters such as the Mars transfer vehicle. CSC has developed a launch vehicle selection model which uses linear programming to find optimal combinations of launch vehicles of various sizes (Atlas, Titan, Shuttles, HLLV's) to support SEI missions. Recently, the Center developed a cost trade-off model for studying on orbit assembly logistics. With this model it was determined that the most effective size of the HLLV would be in the range of 120 to 200 metric tons to LEO, which is consistent with the choices of General Stafford's Synthesis Group Report. A second-generation Dynamic Construction Activities Model ('DYCAM') process model has been under development, based on our past results in interruptability and our initial DYCAM model. This second-generation model is built on the paradigm of knowledge-based expert systems. It is aimed at providing answers to two questions: (1) what are some necessary or sufficient conditions for judging conceptual designs of spacecraft?, and (2) can a methodology be formulated such that these conditions may be used to provide computer-aided tools for evaluating conceptual designs and planning for space assembly sequences? Early simulation results indicate that the DYCAM model has a clear ability to emulate and simulate human orbital construction processes.

Morgenthaler, George W.↗

ISHM Anomaly Lexicon for Rocket Test

Integrated Systems Health Management (ISHM) is a comprehensive capability. An ISHM system must detect anomalies, identify causes of such anomalies, predict future anomalies, help identify consequences of anomalies for example, suggested mitigation steps. The system should also provide users with appropriate navigation tools to facilitate the flow of information into and out of the ISHM system. Central to the ability of the ISHM to detect anomalies is a clearly defined catalog of anomalies. Further, this lexicon of anomalies must be organized in ways that make it accessible to a suite of tools used to manage the data, information and knowledge (DIaK) associated with a system. In particular, it is critical to ensure that there is optimal mapping between target anomalies and the algorithms associated with their detection. During the early development of our ISHM architecture and approach, it became clear that a lexicon of anomalies would be important to the development of critical anomaly detection algorithms. In our work in the rocket engine test environment at John C. Stennis Space Center, we have access to a repository of discrepancy reports (DRs) that are generated in response to squawks identified during post-test data analysis. The DR is the tool used to document anomalies and the methods used to resolve the issue. These DRs have been generated for many different tests and for all test stands. The result is that they represent a comprehensive summary of the anomalies associated with rocket engine testing. Fig. 1 illustrates some of the data that can be extracted from a DR. Such information includes affected transducer channels, narrative description of the observed anomaly, and the steps used to correct the problem. The primary goal of the anomaly lexicon development efforts we have undertaken is to create a lexicon that could be used in support of an associated health assessment database system (HADS) co-development effort. There are a number of significant byproducts of the anomaly lexicon compilation effort. For example, (1) Allows determination of the frequency distribution of anomalies to help identify those with the potential for high return on investment if included in automated detection as part of an ISHM system, (2) Availability of a regular lexicon could provide the base anomaly name choices to help maintain consistency in the DR collection process, and (3) Although developed for the rocket engine test environment, most of the anomalies are not specific to rocket testing, and thus can be reused in other applications.

Schmalzel, John L.↗

Private Astronaut Post-Mission Debrief Interviews Study

BACKGROUND The commercialization of space will increasingly include individuals that are not rigorously-selected, highly-trained professional astronauts. Private astronaut missions (PAMs), such as Axiom-1 in 2022, will continue to travel to the International Space Station in the coming years, but the risk of integrating private astronauts with NASA astronauts has not been clearly quantified nor mitigated. An earlier internal NASA operations assessment, which consisted of a comprehensive literature review and interviews of current NASA experts, found that PAMs are likely to increase the risk to NASA astronauts during integrated missions (Landon, Whiting, Russell, Schorn, Passmore, & Roma, 2022). There are ongoing efforts at NASA to mitigate concerns from a medical, psychological, and technical perspective. NASA experts are working closely with PAM providers to offer recommendations and best practices beyond the limits of requirements to ensure crew health and safety. However, efforts are siloed between groups to some extent, and with the rate of PAMs likely to increase, a more comprehensive and integrated process is needed to reduce the burden on NASA resources. AIMS The purpose of this project is to understand private astronauts’ motivations for journeying to space, their pre-mission preparation period, and their experiences in space. Data will be collected via private astronaut post-mission debrief interviews. This data will inform training needs and in-mission support needed for missions that include private astronauts; the preparation NASA astronauts and mission support personnel will need to work with these integrated crews; and gaps in knowledge to guide research and countermeasure development. Our study aims to (1) Characterize risks posed by commercialization and private astronaut crew integration in spaceflight operations, as it relates to Team, Human Systems Integration Architecture (HSIA), and Behavioral Medicine (BMed) Risks, (2) Recommend potential countermeasures and identify gaps in current research. Countermeasures may be related to crew selection and composition, training, crew support systems (e.g., medical/psychological support, support from Mission Control, on-board resources), and habitability and human factors design. METHOD The BHP Lab will conduct 30-minute interviews with up to eight (8) private astronaut mission (PAM) astronauts (e.g., Axiom) and spaceflight participants (e.g., SFPs or “free flyers” on Polaris Dawn) per year from 2024-2030 to discuss knowledge gaps and needs related to selection and assessment, crew composition, training, crew support systems (e.g., medical/psychological support, support from Mission Control, onboard resources), and habitability and human factors design, which may influence the risk to NASA astronauts. Interviews will then be coded using thematic analysis and interpreted with the assistance of lexical analysis software (e.g., LIWC). As of the end of 2024, we have collected data from one PAM crew. At the conclusion of data collection in 2030, a final report will be prepared integrating all data collected by 2031. SUMMARY Post-return interviews of private astronauts are being conducted to understand their experiences and inform training and countermeasures to ensure the safety of all who journey to the ISS.

Private Astronaut Missions↗

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗

Analytical, Experimental, and Modelling Studies of Lunar and Terrestrial Rocks

The goal of our research has been to understand the paths and the processes of planetary evolution that produced planetary surface materials as we find them. Most of our work has been on lunar materials and processes. We have done studies that obtain geological knowledge from detailed examination of regolith materials and we have reported implications for future sample-collecting and on-surface robotic sensing missions. Our approach has been to study a suite of materials that we have chosen in order to answer specific geologic questions. We continue this work under NAG5-4172. The foundation of our work has been the study of materials with precise chemical and petrographic analyses, emphasizing analysis for trace chemical elements. We have used quantitative models as tests to account for the chemical compositions and mineralogical properties of the materials in terms of regolith processes and igneous processes. We have done experiments as needed to provide values for geochemical parameters used in the models. Our models take explicitly into account the physical as well as the chemical processes that produced or modified the materials. Our approach to planetary geoscience owes much to our experience in terrestrial geoscience, where samples can be collected in field context and sampling sites revisited if necessary. Through studies of terrestrial analog materials, we have tested our ideas about the origins of lunar materials. We have been mainly concerned with the materials of the lunar highland regolith, their properties, their modes of origin, their provenance, and how to extrapolate from their characteristics to learn about the origin and evolution of the Moon's early igneous crust. From this work a modified model for the Moon's structure and evolution is emerging, one of globally asymmetric differentiation of the crust and mantle to produce a crust consisting mainly of ferroan and magnesian igneous rocks containing on average 70-80% plagioclase, with a large, mafic, trace-element-rich geochemical province, and a regolith that globally contains trace-element-rich material distributed from this province by the Imbrium basin-forming impact. This contrasts with earlier models of a concentrically zoned Moon with a crust of ferroan anorthosite overlying a layer of urKREEP overlying ultramafic cumulates. From this work, we have learned lessons useful for developing strategies for studying regolith materials that help to maximize the information available about both the evolution of the regolith and the igneous differentiation of the planet. We believe these lessons are useful in developing strategies for on-surface geological, mineralogical, and geochemical studies, as well. The main results of our work are given in the following brief summaries of major tasks. Detailed accounts of these results have been submitted in the annual progress reports.

Haskin, Larry A.↗

State-of-the-Art: Small Spacecraft Technology

When the first edition of NASA’s Small Spacecraft Technology State-of-the-art report was published in 2013, 247 CubeSats and 105 other non-CubeSat small spacecraft under 50 kilograms (kg) had been launched worldwide, representing less than 2% of launched mass into orbit over multiple years. In 2013 alone, around 60% of the total spacecraft launched had a mass under 600 kg, and of those under 600 kg, 83% were under 200 kg and 37% were nanosatellites (1). Of the total 1,849 spacecraft launched in 2021, 94% were small spacecraft with an overall mass under 600 kg, and of those under 600 kg, 40% were under 200 kg, and 11% were nanosatellites (1). Since 2013, the fight heritage for small spacecraft has increased by over 30% and has become the primary source to space access for commercial, government, private, and academic institutions. The total number of spacecraft launched in the past 10 years is 5,681 and 45% of those had a mass. As with all previous editions of this report, the 2022 edition captures and distills a wealth of new information available on small spacecraft systems from NASA and other publicly available sources. This report is limited to publicly available information and cannot reflect major advances in development that are not publicly disclosed. We encourage any opportunity to publish mission outcomes and technology development milestones (e.g., via conference papers, press releases, company website) so they can be reflected in this report. Overall, this report is a survey of small spacecraft technologies sourced from open literature; it does not endeavor to be an original source, and only considers literature in the public domain to identify and classify devices. Commonly used sources for data include manufacturer datasheets, press releases, conference papers, journal papers, public filings with government agencies, news articles, presentations, the compendium of databases accessed via NASA’s Small Spacecraft Systems Virtual Institute (S3VI) Information Search, and engagement with companies. Data not appropriate for public dissemination, such as proprietary, export controlled, or otherwise restricted data, are not considered. As a result, this report includes many dedicated hours of desk research performed by subject matter experts reviewing resources noted above. Content in this 2022 edition is based on data available by October 2022. This report should not be considered as a comprehensive overview of all the technologies but a great reference for the current state-of-the-art SmallSat technologies. The organizational approach for each chapter is relatively consistent with previous editions and includes an introduction of the technology, current development status of the technology’s procurable systems, and summary tables of technologies surveyed. The content in each chapter is uniquely organized to present a mini-stand-alone report on spacecraft subsystems. As in previous years, chapters include information from previous editions but are updated with new and maturating technologies and reference missions. Tables in each section provide a convenient summary of the technologies discussed, with explanations and references in the body text. The authors have attempted to isolate trends in the small spacecraft industry to point out which technologies have been adopted after successful demonstration missions. Lastly, the authors tried to use the terms “SmallSat,” “microsatellite,” “nanosatellite,” and “CubeSat” in a consistent manner, even as these terms are often used interchangeably in the space industry. Every subsystem chapter contains updated information to reflect the growth in the small spacecraft market. Significant changes are included in several chapters. The “Complete Spacecraft Platforms” chapter now includes information on the two main market options, hosted payload services and dedicated buses. The “Power” chapter provides information on the development of solid-state batteries with significantly higher energy than the current state-of-theart lithium-ion batteries. A large effort was made to update the “Communications” chapter to appropriately capture the recent technology maturation of optical communications for SmallSats. The “Ground Data Systems and Mission Operations” chapter was updated to reflect the recent establishment of the Near Space Network and influx of SmallSat Optical Ground Stations. The “Guidance, Navigation and Control” chapter was updated to include Lidar sensor technology. The “Deorbit Systems” chapter includes a discussion of recently proposed changes by the Federal Communications Commission (FCC) to limit a spacecraft’s lifetime to no longer than 5 years after end-of-mission. The “Identification and Tracking” Chapter includes updated information on the progress of SmallSat tracking. Finally, this report now encompasses technology funded by NASA’s Small Spacecraft Technology (SST) program’s SmallSat Technology Partnerships (STP) initiative which is described further in this Introduction. The reader can find the included SST technology in the “On the Horizon” section of the “Thermal Systems”, “Communications”, and “Guidance, Navigation, and Control” chapters. A central element of this report is to list state-of-the-art technologies by NASA standard Technology Readiness Level (TRL) as defined by the 2020 NASA Engineering Handbook, found in NASA NPR 7123.1C NASA Systems Engineering Processes and Requirements. The authors have endeavored to independently verify the TRL value of each technology by reviewing and citing published test results or publicly available data to the best of their ability. Where test results and data disagree with vendors’ own advertised TRL, the authors have attempted to engage the vendors to discuss the discrepancy. Readers are strongly encouraged to follow the references cited in the literature describing the full performance range and capabilities of each technology. Readers of this report should reach out to individual companies to further clarify information. It is important to note that this report takes a broad system-level view. To attain a high TRL, the subsystem must be in a flight-ready configuration with all supporting infrastructure—such as mounting points, power conversion, and control algorithms—in an integrated unit. An accurate TRL assessment requires a high degree of technical knowledge on a subject device, and an in-depth understanding of the mission (including interfaces and environment) on which the device was flown. There is variability in TRL values depending on design factors for a specific technology. For example, differences in TRL assessment based on the operating environment may result from the thermal environment, mechanical loads, mission duration, or radiation exposure. If a technology has flown on a mission without success, or without providing valid confirmation to the operator, such claimed “flight heritage” was discounted. The authors believe TRLs are most accurately determined when assessed within the context of a program’s unique requirements. While the overall capability of small spacecraft has matured since the 2021 edition of this report, technologies are still being developed to make deep space SmallSat missions more routine and more cost effective. Future editions of this report may include content dedicated to the rapidly growing fields of assembly, integration, and testing services, and mission modeling and simulation–all of which are now extensively represented at small spacecraft conferences. Many of these subsystems and services are still in their infancy, but as they evolve and reliable conventions and standards emerge, the next iteration of this report may also evolve to include additional chapters.

Bruce Yost↗

X-HAB 2020: AR Field Treks Summary and Conclusions

As part of the FY20 X-Hab Challenge, BLiSS sought to create an Augmented Reality (AR) toolkit to help with analog field trek operations under the supervision of the Solar System Exploration Research Virtual Institute (SSERVI). These treks are operational and technical demonstrations at space-like destinations on Earth to test current extra-vehicular activity (EVA) techniques. While BLiSS as an organization has experience studying operational tasks such as this, it has never developed AR software at this scale. For that reason, another team at the University was brought on to work in parallel. The Collaborative Lab for Advancing Work in Space (CLAWS) is a veteran group of the NASA Spacesuit User Interface Technologies for Students (SUITS) challenge in which Hololens displays for astronauts are created within a year. The operational and technological pairing was ideally suited for tackling this problem. The team divided its responsibilities so that BLiSS would handle the research required to shape the project. As this deliverable had an end user, it was decided that interviewing these field geologists and operations specialists would provide the best insight. These interviews paired with literature review would reveal niche applications for AR that remained within feasible bounds. These science-driven EVAs in unknown terrain require more flexible tools than the current generation of EVA assistants. Rather than focus on sequential instructions, there instead needs to be a broad toolkit that's only called upon in specific instances. This AR Toolkit for Lunar Astronauts and Scientists (ATLAS) became the development goal of the project: create a non-intrusive assembly of tools that could be accessed in AR on the field. The current ATLAS design makes use of a geospatially and temporally annotated eld note system called GeoNotes. This allows for data to be collected and coordinated in a way that's synchronized across time, space, and different users. A Mission Control Center (MCC) and Mobile Support Equipment (MSE) were all needed to transport the AR headset into the field with the user. A network infrastructure was designed and set up within the University to enable this functionality. The software is based on a Protocol-Module structure that allows for modular development of each capability. A Protocol Manager coordinates different protocols that make use of modules. Each module tackles a different individual task while the protocol puts each one to use. The protocol manager coordinates when these are called to be used. This software is hosted on a head-mounted display (HMD) with the MCC acting as support from afar. While the software would be unit-tested at each level and each hardware component verified, a final demonstration would serve to prove the system's capabilities: an analog field trek. The team would prepare to support a user in a remote location from the MCC back at the University. A local area near campus would be tested before going out to do sample field geology further away. This unfortunately became impossible with the arrival of COVID-19. Access to all of the facilities to complete the project as planned were shut down. Our team was scattered across the globe and forced to complete the rest virtually. Adjustments were made to produce a small virtual concept in Adobe XD in the meantime. Even digital surveys were created based on the NASA task-load index (TLX) originally intended for testing actual users. The goal shifted towards completing software and getting feedback on the user interfaces (UI) and user experiences (UX). This team has reformed in response to COVID and its focus has shifted to what can be done remotely. There is still an intention to finish the original deliverable described in this report. The work has been expanded beyond the original X-Hab challenge and has instead become its own research e ort to be continued afterwards. This report collects the processes and knowledge gained from a year of studying and working at this problem with two teams. It should preserve it for the time until the world returns to normal and work can resume. CLAWS will be taking over full responsibility from that point forward, eventually surpassing the original needs of the project. While this document captures the work done towards an eventual end, the CLAWS team has written their own proposal alongside it. It outlines a new future for ATLAS beyond X-Hab, BLiSS, and hopefully beyond COVID-19. This project began as a vague goal hoping to place a new technology into the unique setting of exploration science. The project has since comfortably taken root and will hopefully bloom over the next year.

Alex Sena↗