Quality assurance requirements manual for planetary spacecraft to be sterilized by heating
Information and guidelines on quality assurance requirements for production, assembly, and checkout of spacecraft to be sterilized by heating
Source record↗
SEARCH · Search NASA
Results for “INFORMATION ASSURANCE”
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.
Software Requirements Analysis as Fault Predictor
Waiting until the integration and system test phase to discover errors leads to more costly rework than resolving those same errors earlier in the lifecycle. Costs increase even more significantly once a software system has become operational. WE can assess the quality of system requirements, but do little to correlate this information either to system assurance activities or long-term reliability projections - both of which remain unclear and anecdotal. Extending earlier work on requirements accomplished by the ARM tool, measuring requirements quality information against code complexity and test data for the same system may be used to predict specific software modules containing high impact or deeply embedded faults now escaping in operational systems. Such knowledge would lead to more effective and efficient test programs. It may enable insight into whether a program should be maintained or started over.
Wallace, Dolores↗
NASA Astronauts on Soyuz: Experience and Lessons for the Future
The U. S., Russia, and, China have each addressed the question of human-rating spacecraft. NASA's operational experience with human-rating primarily resides with Mercury, Gemini, Apollo, Space Shuttle, and International Space Station. NASA s latest developmental experience includes Constellation, X38, X33, and the Orbital Space Plane. If domestic commercial crew vehicles are used to transport astronauts to and from space, Soyuz is another example of methods that could be used to human-rate a spacecraft and to work with commercial spacecraft providers. For Soyuz, NASA's normal assurance practices were adapted. Building on NASA's Soyuz experience, this report contends all past, present, and future vehicles rely on a range of methods and techniques for human-rating assurance, the components of which include: requirements, conceptual development, prototype evaluations, configuration management, formal development reviews (safety, design, operations), component/system ground-testing, integrated flight tests, independent assessments, and launch readiness reviews. When constraints (cost, schedule, international) limit the depth/breadth of one or more preferred assurance means, ways are found to bolster the remaining areas. This report provides information exemplifying the above safety assurance model for consideration with commercial or foreign-government-designed spacecraft. Topics addressed include: U.S./Soviet-Russian government/agency agreements and engineering/safety assessments performed with lessons learned in historic U.S./Russian joint space ventures
Source record↗
Supplier Assessment System (SAS)
Background: Sponsored by NASA Headquarters; Charter - provide information to assist the quality assurance community in evaluating and determining supplier risk; Comprehensive on-line repository of supplier information; Available to approved civil service personnel from all NASA Centers, other U.S. Government Agencies, Prime Contractors, and NASA direct support contractors; User access to specific data types or documents is controlled as needed.
Dietrich, Kristen↗
NASA software documentation standard software engineering program
The NASA Software Documentation Standard (hereinafter referred to as Standard) can be applied to the documentation of all NASA software. This Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. This basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
Source record↗
Robotic and Crewed Mars Missions Increasing the Demand for Planetary Protection Technology Needs
Planetary protection (PP) policy seeks to avoid harmful contamination by limiting biological and relevant organic contamination from spacecraft as well as preventing adverse changes to Earth’s biosphere when extraterrestial samples are brought back to Earth. The PP policy at NASA was updated in 2021 (NPR 8715.24) and 2022 (NASA-STD-8719.27) to enable missions by expanding the decades old prescriptive requirements to allow for an option of adopting performance-based requirements that are objectivesdriven, risk-informed and case-assured. In parallel, the final PP knowledge gap workshop was completed representing the international consensus on the key areas to be considered in developing crew PP policy. These knowledge gaps focused on key technology development areas in 1) microbial and human health monitoring, 2) technical and operations needed for contamination control and 3) natural transport of contamination on Mars. As robotic missions start to implement performance-based approaches and research and technology efforts commence to inform crew policy the demand for data quality driven verification and validation in relevant space environments. Examples of the types of testing that is envisioned includes test as you fly validation and verification of decontamination systems in a relevant on-orbit and Mars environment, developing lethality curves of terrestrial organisms to further our understanding of the biocidal impacts of Mars and the space environment, and particle transport model validation and verification. Thus, the PP discipline has identified the need for groundbased space environments to perform preliminary testing as validation and verification of flight systems and to advance the technology readiness level prior to further testing on-orbit or lunar environments to prepare for Mars.
J. Nick Benardini↗
Robotic and Crewed Mars Missions Increasing the Demand for Planetary Protection Technology Needs
Planetary protection (PP) policy seeks to avoid harmful contamination by limiting biological and relevant organic contamination from spacecraft as well as preventing adverse changes to Earth’s biosphere when extraterrestrial samples are brought back to Earth. The PP policy at NASA was updated in 2021 (NPR 8715.24) and 2022 (NASA-STD-8719.27) to enable missions by expanding the decades old prescriptive requirements to allow for an option of adopting performance-based requirements that are objectives-driven, risk-informed and case-assured. In parallel, the final PP knowledge gap workshop was completed representing the international consensus on the key areas to be considered in developing crew PP policy. These knowledge gaps focused on key technology development areas in 1) microbial and human health monitoring, 2) technical and operations needed for contamination control and 3) natural transport of contamination on Mars. As robotic missions start to implement performance-based approaches and research and technology efforts commence to inform crew policy the demand for data quality driven verification and validation in relevant space environments. Examples of the types of testing that is envisioned includes test as you fly validation and verification of decontamination systems in a relevant on-orbit and Mars environment, developing lethality curves of terrestrial organisms to further our understanding of the biocidal impacts of Mars and the space environment, and particle transport model validation and verification. Thus, the PP discipline has identified the need for ground-based space environments to perform preliminary testing as validation and verification of flight systems and to advance the technology readiness level prior to further testing on-orbit or lunar environments to prepare for Mars.
J Nick Benardini↗
From BERTopic to SysML: Informing Model-Based Failure Analysis With Natural Language Processing for Complex Aerospace Systems
The development of emerging complex aerospace systems will require new approaches for capturing safety incident scenarios as early as possible in the design phase. However, for novel systems, relevant data available is limited. In this work, we propose a framework informing model-based mission assurance activities with historical incident reports, lessons learned, or other relevant engineering documents using natural language processing. In doing so, we investigate whether there is useful information in data sets that are relevant, if not identical, to the system under design and whether, through rigorous systems engineering practice, this information can be effectively leveraged through model-based failure analysis. In a worked case study, we apply state-of-the-art topic modeling techniques to two data sets, a mission relevant data set and a system relevant data set. The sets of topics are merged and interpreted to form a preliminary list of failure topics that can be used to inform the identification of off-nominal modes in the model-based failure modes and effects analysis development. Once data from the system in operation is available, it can be used to update the topics identified. By extracting information about likely failures from relevant historical data sets and utilizing model-based mission assurance to ensure relevance and rigor, unanticipated failures can be reduced, and projects can more effectively learn from past missions.
Failure Analysis↗
From BERTopic to SysML: Informing Model-Based Failure Analysis With Natural Language Processing for Complex Aerospace Systems
The development of emerging complex aerospace systems will require new approaches for capturing safety incident scenarios as early as possible in the design phase. However, for novel systems, relevant data available is limited. In this work, we propose a framework informing model-based mission assurance activities with historical incident reports, lessons learned, or other relevant engineering documents using natural language processing. In doing so, we investigate whether there is useful information in data sets that are relevant, if not identical, to the system under design and whether, through rigorous systems engineering practice, this information can be effectively leveraged through model-based failure analysis. In a worked case study, we apply state-of-the-art topic modeling techniques to two data sets, a mission relevant data set and a system relevant data set. The sets of topics are merged and interpreted to form a preliminary list of failure topics that can be used to inform the identification of off-nominal modes in the model-based failure modes and effects analysis development. Once data from the system in operation is available, it can be used to update the topics identified. By extracting information about likely failures from relevant historical data sets and utilizing model-based mission assurance to ensure relevance and rigor, unanticipated failures can be reduced, and projects can more effectively learn from past missions.
Failure Analysis↗
The new Space Shuttle Transportation System (STS) - Problem, performance, supportability, and programmatic trending program
This paper describes the NASA Space Shuttle Trend Analysis program. The four main areas of the program - problem/reliability, performance, supportability, and programmatic trending - are defined, along with motivation for these areas, the statistical methods used, and illustrative Space Shuttle applications. Also described is the NASA Safety, Reliability, Maintainability and Quality Assurance (SRM&QA) Management Information Center, used to focus management attention on key near-term launch concerns and long-range mission trend issues. Finally, the computer data bases used to support the program and future program enhancements are discussed.
Crawford, J. L.↗
NASA Aerospace Flight Battery Systems Program Update
The objectives of NASA's Aerospace Flight Battery Systems Program is to: develop, maintain and provide tools for the validation and assessment of aerospace battery technologies; accelerate the readiness of technology advances and provide infusion paths for emerging technologies; provide NASA projects with the required database and validation guidelines for technology selection of hardware and processes relating to aerospace batteries; disseminate validation and assessment tools, quality assurance, reliability, and availability information to the NASA and aerospace battery communities; and ensure that safe, reliable batteries are available for NASA's future missions.
Manzo, Michelle↗
On The Computational Capabilities of Physical Systems: Relationship With Conventional Computer Science - Part 2
In the first of this pair of papers, it was proven that there cannot be a physical computer to which one can properly pose any and all computational tasks concerning the physical universe. It was then further proven that no physical computer C can correctly carry out all computational tasks that can be posed to C. As a particular example, this result means that no physical computer that can, for any physical system external to that computer, take the specification of that external system's state as input and then correctly predict its future state before that future state actually occurs; one cannot build a physical computer that can be assured of correctly "processing information faster than the universe does". These results do not rely on systems that are infinite, and/or non-classical, and/or obey chaotic dynamics. They also hold even if one uses an infinitely fast, infinitely dense computer, with computational powers greater than that of a Turing Machine. This generality is a direct consequence of the fact that a novel definition of computation - "physical computation" - is needed to address the issues considered in these papers, which concern real physical computers. While this novel definition does not fit into the traditional Chomsky hierarchy, the mathematical structure and impossibility results associated with it have parallels in the mathematics of the Chomsky hierarchy. This second paper of the pair presents a preliminary exploration of some of this mathematical structure. Analogues of Chomskian results concerning universal Turing Machines and the Halting theorem are derived, as are results concerning the (im)possibility of certain kinds of error-correcting codes. In addition, an analogue of algorithmic information complexity, "prediction complexity", is elaborated. A task-independent bound is derived on how much the prediction complexity of a computational task can differ for two different reference universal physical computers used to solve that task, a bound similar to the "encoding" bound governing how much the algorithm information complexity of a Turing machine calculation can differ for two reference universal Turing machines. Finally, it is proven that either the Hamiltonian of our universe proscribes a certain type of computation, or prediction complexity is unique (unlike algorithmic information complexity), in that there is one and only version of it that can be applicable throughout our universe.
Wolpert, David H.↗
On the Computational Capabilities of Physical Systems: The Impossibility of Infallible Computation - Part 1
In this first of two papers, strong limits on the accuracy of physical computation are established. First it is proven that there cannot be a physical computer C to which one can pose any and all computational tasks concerning the physical universe. Next it is proven that no physical computer C can correctly carry out any computational task in the subset of such tasks that can be posed to C. This result holds whether the computational tasks concern a system that is physically isolated from C, or instead concern a system that is coupled to C. As a particular example, this result means that there cannot be a physical computer that can, for any physical system external to that computer, take the specification of that external system's state as input and then correctly predict its future state before that future state actually occurs; one cannot build a physical computer that can be assured of correctly 'processing information faster than the universe does'. The results also mean that there cannot exist an infallible, general-purpose observation apparatus, and that there cannot be an infallible, general-purpose control apparatus. These results do not rely on systems that are infinite, and/or non-classical, and/or obey chaotic dynamics. They also hold even if one uses an infinitely fast, infinitely dense computer, with computational powers greater than that of a Turing Machine. This generality is a direct consequence of the fact that a novel definition of computation - a definition of 'physical computation' - is needed to address the issues considered in these papers. While this definition does not fit into the traditional Chomsky hierarchy, the mathematical structure and impossibility results associated with it have parallels in the mathematics of the Chomsky hierarchy. The second in this pair of papers presents a preliminary exploration of some of this mathematical structure, including in particular that of prediction complexity, which is a 'physical computation analogue' of algorithmic information complexity. It is proven in that second paper that either the Hamiltonian of our universe proscribes a certain type of computation, or prediction complexity is unique (unlike algorithmic information complexity), in that there is one and only version of it that can be applicable throughout our universe.
Wolpert, David H.↗
Software Quality Assurance Audits Guidebooks
The growth in cost and importance of software to NASA has caused NASA to address the improvement of software development across the agency. One of the products of this program is a series of guidebooks that define a NASA concept of the assurance processes that are used in software development. The Software Assurance Guidebook, NASA-GB-A201, issued in September, 1989, provides an overall picture of the NASA concepts and practices in software assurance. Second level guidebooks focus on specific activities that fall within the software assurance discipline, and provide more detailed information for the manager and/or practitioner. This is the second level Software Quality Assurance Audits Guidebook that describes software quality assurance audits in a way that is compatible with practices at NASA Centers.
Source record↗
NASA Software Documentation Standard
The NASA Software Documentation Standard (hereinafter referred to as "Standard") is designed to support the documentation of all software developed for NASA; its goal is to provide a framework and model for recording the essential information needed throughout the development life cycle and maintenance of a software system. The NASA Software Documentation Standard can be applied to the documentation of all NASA software. The Standard is limited to documentation format and content requirements. It does not mandate specific management, engineering, or assurance standards or techniques. This Standard defines the format and content of documentation for software acquisition, development, and sustaining engineering. Format requirements address where information shall be recorded and content requirements address what information shall be recorded. This Standard provides a framework to allow consistency of documentation across NASA and visibility into the completeness of project documentation. The basic framework consists of four major sections (or volumes). The Management Plan contains all planning and business aspects of a software project, including engineering and assurance planning. The Product Specification contains all technical engineering information, including software requirements and design. The Assurance and Test Procedures contains all technical assurance information, including Test, Quality Assurance (QA), and Verification and Validation (V&V). The Management, Engineering, and Assurance Reports is the library and/or listing of all project reports.
Source record↗
Managing systems faults on the commercial flight deck: Analysis of pilots' organization and prioritization of fault management information
In rare instances, flight crews of commercial aircraft must manage complex systems faults in addition to all their normal flight tasks. Pilot errors in fault management have been attributed, at least in part, to an incomplete or inaccurate awareness of the fault situation. The current study is part of a program aimed at assuring that the types of information potentially available from an intelligent fault management aiding concept developed at NASA Langley called 'Faultfinde' (see Abbott, Schutte, Palmer, and Ricks, 1987) are an asset rather than a liability: additional information should improve pilot performance and aircraft safety, but it should not confuse, distract, overload, mislead, or generally exacerbate already difficult circumstances.
Rogers, William H.↗
Product Assurance for Spaceflight Hardware
This report contains information about the tasks I have completed and the valuable experience I have gained at NASA. The report is divided into two different sections followed by a program summary sheet. The first section describes the two reports I have completed for the Office of Mission Assurance (OMA). I describe the approach and the resources and facilities used to complete each report. The second section describes my experience working in the Receipt Inspection/Quality Assurance Lab (RI/QA). The first report described is a Product Assurance Plan for the Gas Permeable Polymer Materials (GPPM) mission. The purpose of the Product Assurance Plan is to define the various requirements which are to be met through completion of the GPPM mission. The GPPM experiment is a space payload which will be flown in the shuttle's SPACEHAB module. The experiment will use microgravity to enable production of complex polymeric gas permeable materials. The second report described in the first section is a Fracture Analysis for the Mir Environmental Effects Payload (MEEP). The Fracture Analysis report is a summary of the fracture control classifications for all structural elements of the MEEP. The MEEP hardware consists of four experiment carriers, each of which contains an experiment container holding a passive experiment. The MEEP hardware will be attached to the cargo bay of the space shuttle. It will be transferred by Extravehicular Activity and mounted on the Mir space station. The second section of this report describes my experiences in the RVQA lab. I listed the different equipment I used at the lab and their functions. I described the extensive inspection process that must be completed for spaceflight hardware. Included, at the end of this section, are pictures of most of the equipment used in the lab. There is a summary sheet located at the end of this report. It briefly describes the valuable experience I have gained at NASA this summer and what I will be able to take with me as I return to college. I briefly discuss the experiences I mentioned in the previous three paragraphs along with training classes I attended and courses I completed at the Learning Lab.
Monroe, Mike↗
An Assurance Case with a Model at its Core
We describe our pilot study development of an Assurance Case arguing the robustness of a spacecraft demonstration of optical communication. Our Assurance Case addresses the concern that optical communication may be interrupted by the presence of cloud cover, threatening the success of the demonstration. Central to our Assurance Case is its use of a model of atmospheric attenuation to support a key portion of the robustness argument. The conclusion for the demonstration is that its schedule slack plus ability to store data for transmission later accommodates occasional weather-caused atmospheric attenuation.We indicate how the overall structure of the Assurance Case derives from the Objectives Hierarchy set forth in the NASA Reliability and Maintainability standard. We then present the portions of the Assurance Case that argue (1) the atmospheric attenuation model is sufficiently accurate, (2) application of the model shows the desired robustness of the demonstration, and (3) all the model assumptions are satisfied in its application. Lastly, we suggest how an engineering model of the demonstration system and its use could inform the development of the Assurance Case encompassing additional plausible hazards.
DiVenti, Anthony↗