SEARCH · Search NASA

Results for “requirements verification”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 307 records · Page 17

All sources NASA NTRS DOE OSTI

NASA NTRS2012

CO2 Washout Testing of NASA Space Suits

During the presentation "CO2 Washout Testing of NASA Spacesuits," Jason Norcross discussed the results of recent carbon dioxide CO2 washout testing of NASA spacesuits including the Rear Entry I-suit (REI), Enhanced Mobility Advanced Crew Escape Suit (EM-ACES), and possibly the ACES and Z-1 EVA prototype. When a spacesuit is used during ground testing, adequate CO2 washout must be provided for the suited subject. Symptoms of acute CO2 exposure depend on the partial pressure of CO2 (ppCO2) available to enter the lungs during respiration. The primary factors during ground-based testing that influence the ppCO2 level in the oronasal area include the metabolic rate of the subject and air flow through the suit. These tests were done to characterize inspired oronasal ppCO2 for a range of workloads and flow rates for which ground testing is nominally performed. During this presentation, Norcross provided descriptions of the spacesuits, test hardware, methodology, and results, as well as implications for future ground testing and verification of flight requirements.

Norcross, Jason↗

NASA NTRS2017

Designing to Sample the Unknown: Lessons from OSIRIS-REx Project Systems Engineering

On September 8, 2016, the third NASA New Frontiers mission launched on an Atlas V 411. The Origins, Spectral Interpretation, Resource Identification, Security-Regolith Explorer (OSIRIS-REx) will rendezvous with asteroid Bennu in 2018, collect a sample in 2020, and return that sample to Earth in September 2023. The development team has overcome a number of challenges in order to design and build a system that will make contact with an unexplored, airless, low-gravity body. This paper will provide an overview of the mission, then focus in on the system-level challenges and some of the key system-level processes. Some of the lessons here are unique to the type of mission, like discussion of operating at a largely-unknown, low-gravity object. Other lessons, particularly from the build phase, have broad implications. The OSIRIS-REx risk management process was particularly effective in achieving an on-time and under-budget development effort. The systematic requirements management and verification and the system validation also helped identify numerous potential problems. The final assessment of the OSIRIS-REx performance will need to wait until the sample is returned in 2023, but this post-launch assessment will capture some of the key systems-engineering lessons from the development team.

Asteroid↗

NASA NTRS2011

Monte Carlo Simulations of the Formation Flying Dynamics for the Magnetospheric Multiscale (MMS) Mission

The MMS mission is an ambitious space physics mission that will fly 4 spacecraft in a tetrahedron formation in a series of highly elliptical orbits in order to study magnetic reconnection in the Earth's magnetosphere. The mission design is comprised of a combination of deterministic orbit adjust and random maintenance maneuvers distributed over the 2.5 year mission life. Formal verification of the requirements is achieved by analysis through the use of the End-to-End (ETE) code, which is a modular simulation of the maneuver operations over the entire mission duration. Error models for navigation accuracy (knowledge) and maneuver execution (control) are incorporated to realistically simulate the possible maneuver scenarios that might be realized These error models, coupled with the complex formation flying physics, lead to non-trivial effects that must be taken into account by the ETE automation. Using the ETE code, the MMS Flight Dynamics team was able to demonstrate that the current mission design satisfies the mission requirements.

Schiff, Conrad↗

NASA NTRS2018

Using Maxwell's Demon to Tame the "Devil in the Details" that are Encountered During System Development

Model-Based Systems Engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases . This presentation will discuss the value proposition that MBSE has for Systems Engineering, and the associated culture change needed to adopt it.

Model Based Systems Engineering↗

NASA NTRS2020

ROMAN CGI Testbed WFSC Modeling and Validation

Optical diffraction and wavefront sensing and control (WFSC) models validated against the high-fidelity Roman Space Telescope Coronagraph Instrument (CGI) testbed play a key role in mask design selection and the verification of many requirements that cannot be accomplished until the observatory is in orbit. We have been steadily improving our model fidelity for the as-built CGI testbed system, demonstrating recently good agreement between measurements and model predictions while validating the Hybrid Lyot Coronagraph’s (HLC) performance using the in-orbit high order wavefront sensing and control (HOWFSC) operational scenario. We present modeling and testbed validation results that explain the reason many testbed WFSC iterations were needed for HLC in the past. A new, direct application of model-generated deformable mirror (DM) solutions has since been successfully demonstrated on the testbed with significant speed and performance improvement. The benefit of using such a solution opens up new model-based WFSC approaches for CGI. This can greatly reduce flight risk from potentially insufficient ground solution generation due to schedule or cost constraints or from unexpected post-delivery changes.

Poberezhskiy, Ilya↗

NASA NTRSDate not supplied

A Data Analysis Approach for Simulations of Urban Air Mobility Operations

For the Urban Air Mobility (UAM) industry, NASA has defined a series of UAM Maturity Levels (UML) corresponding to increasingly more complex and operationally dense UAM operations. In support of the gradual progression towards higher UML levels, NASA is currently conducting a set of UAM air traffic simulations—collectively referred to as X4. This paper describes a set of system effectiveness measures, and their associated metrics, for data analysis of X4 simulations. The descriptions, rationales, and calculation procedures for two metrics to be used in data analysis of simulation results, the number of predicted demand-capacity imbalances and the pre-departure delays, are described. Results from data analysis of one set of simulation runs are presented to demonstrate how these metrics support the assessment of performance of the system architecture for X4 simulations and the verification of experiment requirements.

Urban Air Mobility↗

NASA NTRSDate not supplied

A Data Analysis and Simulation Study of Urban Air Mobility

Urban Air Mobility↗

NASA NTRSDate not supplied

A PPE Use Case on Configuration Management Approach for MBSE

Systems engineers worldwide have been working to implement Model-based Systems Engineering (MBSE) environments, tools, and methodologies. MBSE is a formalized application of modeling to support systems engineering, including requirements, design, analysis, verification, and validation activities over the project’s lifecycle[1]; MBSE captures the system data into a digital environment. Significant benefits of MBSE includes a reduction in the time in performing systems engineering activities and an improvement higher fidelity data production. As more Systems Engineers are using MBSE, the models it produces are becoming the source of truth for Systems Engineering artifacts. As we move towards using these models as the source of truth, a more rigorous Configuration Management (CM) infrastructure is needed. Many of the MBSE tools provide CM options but utilizing them efficiently and effectively can be challenging. More rigorous methods and tools are needed to assist with keeping track of changes in the model, making sure inadvertent changes to baseline data did not occur, visibility of changes in the different model versions, and the impacts of changes to the models. System engineers and configuration management personnel from the Power and Propulsion Element (PPE) project at NASA Glenn Research Center have been working to develop a modeling construct that allows models to be the source of truth and maintain a configuration managed baseline. This paper presents a process that leverages the existing CM tools and describes how PPE used this process to manage changes more rigorously. It will describe the process behind building the model architecture that utilizes the MBSE tool capabilities and the configuration management process. It will contain some of the advantages and disadvantages of the architecture that the PPE project had settled upon utilizing, as well as some enhanced capabilities that the PPE MBSE team has developed.

MBSE↗

NASA NTRS2022

Perseverance Rover’s Robotic Arm and Turret Mounted Instruments’ Surface Commissioning

The Robotic Arm (RA) on the Perseverance rover is an integral component of the Sampling and Caching System necessary for completing the science goals of the Mars 2020 mission. While the Perseverance rover was based on the Curiosity rover which landed in 2012, the Robotic Arm was redesigned to carry a much larger turret with a new suite of payloads. Shortly after Perseverance landed in Jezero Crater, a series of checkouts was completed with the RA during the first 100 sols of the mission in order to ensure proper functionality of the RA and the instruments mounted on the turret. This period of time in the mission was called Surface Operations Transition (SOX). The objective of SOX was to systematically execute checkout activities for all the basic functionality so that the RA and instruments, as well as other rover components, could be released for scientific exploration.RA activities during SOX can be divided into a few different categories: Mechanism Checkouts, Rover Visual Inspections, Performance Characterization, and Instrument Functional Checkouts. Many of these checkouts built off of each other such that each subsequent activity would verify incrementally complex functionality. Many of the defined activities were executed several times throughout the development of the rover and served as a check that the RA’s performance is consistent with testing on Earth. Other activities were developed uniquely for SOX to respond to challenges discovered during development. They were designed to be verifiable without the help of ground support equipment or previous executions on the flight hardware to compare against.This paper discusses the formulation and conception of the various RA SOX checkout activities, verification and testing required to certify them for flight, execution of the activities on Mars, issues encountered, and finally results and findings as the mission transitioned to nominal science operations. We will be presenting the results and analysis using downlinked imaging and data from the flight vehicle to show how we verified the performance of the Robotic Arm and the turret mounted instruments in order to transition to science operations with a clean bill of health.

Edgett, Kenneth↗

NASA NTRS2022

Integrating FRET with Copilot: Automated Translation of Natural Language Requirements to Runtime Monitors

Runtime verification (RV) enables monitoring systems at runtime, to detect property violations early and limit their potential consequences. To provide the level of assurance required for ultra-critical systems, monitor specifications must faithfully reflect the original mission requirements, which are often written in ambiguous natural language. This paper presents an end-to-end framework to capture requirements in structured natural language and generate monitors that capture their semantics faithfully. We leverage NASA’s Formal Requirement Elicitation Tool (FRET), and the RV system Copilot. We extend FRET with mechanisms to capture additional information needed to generate monitors, and introduce OGMA, a new tool to bridge the gap between FRET and Copilot. With this framework, users can write requirements in an intuitive format and obtain real-time C monitors suitable for use in embedded systems. Our tool chain is available as open source.

FRET↗

NASA NTRS2020

Bridging the Gap Between Requirements and Model Analysis : Evaluation on Ten Cyber-Physical Challenge Problems

Formal verfication and simulation are powerful tools to validate requirements against complex systems. [Problem] Requirements are developed in early stages of the software lifecycle and are typically written in ambiguous natural language. There is a gap between such requirements and formal notations that can be used by verification tools, and lack of support for proper association of requirements with software artifacts for verification. [Principal idea] We propose to write requirements in an intuitive, structured natural language with formal semantics, and to support formalization and model/code verification as a smooth, well-integrated process. [Contribution] We have developed an end-to-end, open source requirements analysis framework that checks Simulink models against requirements written in structured natural language. Our framework is built in the Formal Requirements Elicitation Tool (fret); we use fret's requirements language named fretish, and formalization of fretish requirements in temporal logics. Our proposed framework contributes the following features: 1) automatic extraction of Simulink model information and association of fretish requirements with target model signals and components; 2) translation of temporal logic formulas into synchronous dataflow cocospec specifications as well as Simulink monitors, to be used by verification tools; we establish correctness of our translation through extensive automated testing; 3) interpretation of counterexamples produced by verification tools back at requirements level. These features support a tight integration and feedback loop between high level requirements and their analysis. We demonstrate our approach on a major case study: the Ten Lockheed Martin Cyber-Physical, aerospace-inspired challenge problems.

Mavridou, Anastasia↗

NASA NTRS2010

Aerospace Payloads Leak Test Methodology

Pressurized and sealed aerospace payloads can leak on orbit. When dealing with toxic or hazardous materials, requirements for fluid and gas leakage rates have to be properly established, and most importantly, reliably verified using the best Nondestructive Test (NDT) method available. Such verification can be implemented through application of various leak test methods that will be the subject of this paper, with a purpose to show what approach to payload leakage rate requirement verification is taken by the National Aeronautics and Space Administration (NASA). The scope of this paper will be mostly a detailed description of 14 leak test methods recommended.

Lvovsky, Oleg↗

NASA NTRS2010

Analysis, Simulation, and Verification of Knowledge-Based, Rule-Based, and Expert Systems

Mathematically sound techniques are used to view a knowledge-based system (KBS) as a set of processes executing in parallel and being enabled in response to specific rules being fired. The set of processes can be manipulated, examined, analyzed, and used in a simulation. The tool that embodies this technology may warn developers of errors in their rules, but may also highlight rules (or sets of rules) in the system that are underspecified (or overspecified) and need to be corrected for the KBS to operate as intended. The rules embodied in a KBS specify the allowed situations, events, and/or results of the system they describe. In that sense, they provide a very abstract specification of a system. The system is implemented through the combination of the system specification together with an appropriate inference engine, independent of the algorithm used in that inference engine. Viewing the rule base as a major component of the specification, and choosing an appropriate specification notation to represent it, reveals how additional power can be derived from an approach to the knowledge-base system that involves analysis, simulation, and verification. This innovative approach requires no special knowledge of the rules, and allows a general approach where standardized analysis, verification, simulation, and model checking techniques can be applied to the KBS.

Hinchey, Mike↗

NASA NTRS2013

Application Program Interface for the Orion Aerodynamics Database

The Application Programming Interface (API) for the Crew Exploration Vehicle (CEV) Aerodynamic Database has been developed to provide the developers of software an easily implemented, fully self-contained method of accessing the CEV Aerodynamic Database for use in their analysis and simulation tools. The API is programmed in C and provides a series of functions to interact with the database, such as initialization, selecting various options, and calculating the aerodynamic data. No special functions (file read/write, table lookup) are required on the host system other than those included with a standard ANSI C installation. It reads one or more files of aero data tables. Previous releases of aerodynamic databases for space vehicles have only included data tables and a document of the algorithm and equations to combine them for the total aerodynamic forces and moments. This process required each software tool to have a unique implementation of the database code. Errors or omissions in the documentation, or errors in the implementation, led to a lengthy and burdensome process of having to debug each instance of the code. Additionally, input file formats differ for each space vehicle simulation tool, requiring the aero database tables to be reformatted to meet the tool s input file structure requirements. Finally, the capabilities for built-in table lookup routines vary for each simulation tool. Implementation of a new database may require an update to and verification of the table lookup routines. This may be required if the number of dimensions of a data table exceeds the capability of the simulation tools built-in lookup routines. A single software solution was created to provide an aerodynamics software model that could be integrated into other simulation and analysis tools. The highly complex Orion aerodynamics model can then be quickly included in a wide variety of tools. The API code is written in ANSI C for ease of portability to a wide variety of systems. The input data files are in standard formatted ASCII, also for improved portability. The API contains its own implementation of multidimensional table reading and lookup routines. The same aerodynamics input file can be used without modification on all implementations. The turnaround time from aerodynamics model release to a working implementation is significantly reduced

Robinson, Philip E.↗

NASA NTRS2018

External Contamination Integration of Visiting Vehicles on the International Space Station

The International Space Station (ISS) is an on-orbit platform for science utilization in low Earth orbit. The induced contamination environment can impact performance, mission success, and science utilization. Cargo and crew vehicles visiting the ISS represent significant sources of contamination. The Space Environments Team of the ISS Program Office has developed visiting vehicle requirements and methodologies to address the increasingly complex challenge of integrating multiple visiting vehicles while maintaining overall ISS contamination control requirements. The external contamination control requirements are summarized and the integration and verification process is described along with required data deliverables. Contamination characterization data deliverables address vacuum-exposed materials, thrusters, vacuum venting, and particulate releases. Visiting vehicle external contamination analyses are conducted by the ISS Space Environments Team to certify compliance with external contamination control requirements. Unpressurized cargo contamination analyses are also performed to characterize induced contamination to payloads while in transit to ISS. Efforts to confirm the visiting vehicle contamination modeling and analysis process based on on-orbit data are discussed.

outgassing↗

NASA NTRS2024

High-Rate Delay Tolerant Networking (HDTN) Software Requirements Analysis

This document serves as a detailed analysis of the main networking protocols implemented by HDTN. Sources of the protocol specifications include Internet Engineering Task Force (IETF) Request for Comments (RFC) and Consultative Committee for Space Data Systems (CCSDS) standards. The focus of this report is to derive software requirements suitable for NASA Procedural Requirements 7150.2D Class B compliance, including requirements traceability and software verification and validation, from the source specifications. This analysis will be incorporated into the finalized HDTN Software Requirements Specification (SRS) but does not encompass the full scope of the HDTN SRS. Requirements in this document are considered draft. The complete requirements will include bundle application requirements, interface requirements, computer resource requirements, software quality factors, and additional requirements as determined by the project. This document is publicly released to the greater community to receive feedback and foster collaboration opportunities.

Rachel Dudukovich↗

NASA NTRS1982

Geometric verification

Present LANDSAT data formats are reviewed to clarify how the geodetic location and registration capabilities were defined for P-tape products and RBV data. Since there is only one geometric model used in the master data processor, geometric location accuracy of P-tape products depends on the absolute accuracy of the model and registration accuracy is determined by the stability of the model. Due primarily to inaccuracies in data provided by the LANDSAT attitude management system, desired accuracies are obtained only by using ground control points and a correlation process. The verification of system performance with regards to geodetic location requires the capability to determine pixel positions of map points in a P-tape array. Verification of registration performance requires the capability to determine pixel positions of common points (not necessarily map points) in 2 or more P-tape arrays for a given world reference system scene. Techniques for registration verification can be more varied and automated since map data are not required. The verification of LACIE extractions is used as an example.

Grebowsky, G. J.↗

NASA NTRS1988

Thermal/structural design verification strategies for large space structures

Requirements for space structures of increasing size, complexity, and precision have engendered a search for thermal design verification methods that do not impose unreasonable costs, that fit within the capabilities of existing facilities, and that still adequately reduce technical risk. This requires a combination of analytical and testing methods. This requires two approaches. The first is to limit thermal testing to sub-elements of the total system only in a compact configuration (i.e., not fully deployed). The second approach is to use a simplified environment to correlate analytical models with test results. These models can then be used to predict flight performance. In practice, a combination of these approaches is needed to verify the thermal/structural design of future very large space systems.

Benton, David↗