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 343 records · Page 19

All sources NASA NTRS DOE OSTI

NASA NTRS1991

Using adaptive structures to enable future missions by relaxing ground test requirements

Future NASA missions will require large space structures that must maintain accurate surface tolerances for up to 20 years; most flight programs require a ground test verification of the hardware. Because of the influence of gravity, the current state-of-the-art ground test technology cannot accurately determine whether the hardware complies with the requirements. The incorporation of adaptive structures into the spacecraft will enable a relaxation of the ground test requirements necessary to validate the hardware for flight. This paper describes the challenges in testing large precision structures, adaptive structures, the data establishing the current state of the art in ground testing, and the utilization of adaptive structures to alleviate the ground test requirements.

Wada, Ben K.↗

NASA NTRS2007

Implementation of Leak Test Methods for the International Space Station (ISS) Elements, Systems and Components

The International Space Station (ISS has Qualification and Acceptance Environmental Test Requirements document, SSP 41172 that includes many environmental tests such as Thermal vacuum & Cycling, Depress/Repress, Sinusoidal, Random, and Acoustic Vibration, Pyro Shock, Acceleration, Humidity, Pressure, Electromatic Interference (EMI)/Electromagnetic Compatibility (EMCO), etc. This document also includes (13) leak test methods for Pressure Integrity Verification of the ISS Elements, Systems, and Components. These leak test methods are well known, however, the test procedure for specific leak test method shall be written and implemented paying attention to the important procedural steps/details that, if omitted or deviated, could impact the quality of the final product and affect the crew safety. Such procedural steps/details for different methods include, but not limited to: - Sequence of testing, f or example, pressurization and submersion steps for Method I (Immersion); - Stabilization of the mass spectrometer leak detector outputs fo r Method II (vacuum Chamber or Bell jar); - Proper data processing an d taking a conservative approach while making predictions for on-orbit leakage rate for Method III(Pressure Change); - Proper Calibration o f the mass spectrometer leak detector for all the tracer gas (mostly Helium) Methods such as Method V (Detector Probe), Method VI (Hood), Method VII (Tracer Probe), Method VIII(Accumulation); - Usage of visibl ility aides for Method I (Immersion), Method IV (Chemical Indicator), Method XII (Foam/Liquid Application), and Method XIII (Hydrostatic/Visual Inspection); While some methods could be used for the total leaka ge (either internal-to-external or external-to-internal) rate requirement verification (Vacuum Chamber, Pressure Decay, Hood, Accumulation), other methods shall be used only as a pass/fail test for individual joints (e.g., welds, fittings, and plugs) or for troubleshooting purposes (Chemical Indicator, Detector Probe, Tracer Probe, Local Vacuum Chamber, Foam/Liquid Application, and Hydrostatic/Visual Inspection). Any isolation of SSP 41172 requirements have led to either retesting of hardware or accepting a risk associated with the potential system or component pressure integrity problem during flight.

Underwood, Steve↗

NASA NTRS1985

A review of dynamic inflow and its effect on experimental correlations

A review is given of the relationship between experimental data and the development of modern dynamic-inflow theory. Some of the most interesting data, first presented 10 years ago at the Dynamic Specialist's Meeting, is now reviewed in light of the newer theories. These pure blade-flapping data correlate very well with analyses that include the new dynamic inflow theory, thus verifying the theory. Experimental data are also presented for damping with coupled inplane and body motions. Although inclusion of dynamic inflow is often required to correlate this coupled data, the data cannot be used to verify any particular dynamic inflow theory due to the uncertainties in modeling the inplane degree of freedom. For verification, pure flapping is required. However, the coupled data do show that inflow is often important in such computations.

Gaonkar, G. H.↗

NASA NTRS1993

Formal methods for life-critical software

The use of computer software in life-critical applications, such as for civil air transports, demands the use of rigorous formal mathematical verification procedures. This paper demonstrates how to apply formal methods to the development and verification of software by leading the reader step-by-step through requirements analysis, design, implementation, and verification of an electronic phone book application. The current maturity and limitations of formal methods tools and techniques are then discussed, and a number of examples of the successful use of formal methods by industry are cited.

Butler, Ricky W.↗

NASA NTRS1993

Formal Methods for Life-Critical Software

Butler, Ricky W.↗

NASA NTRS2015

Verification of Functional Fault Models and the Use of Resource Efficient Verification Tools

Functional fault models (FFMs) are a directed graph representation of the failure effect propagation paths within a system's physical architecture and are used to support development and real-time diagnostics of complex systems. Verification of these models is required to confirm that the FFMs are correctly built and accurately represent the underlying physical system. However, a manual, comprehensive verification process applied to the FFMs was found to be error prone due to the intensive and customized process necessary to verify each individual component model and to require a burdensome level of resources. To address this problem, automated verification tools have been developed and utilized to mitigate these key pitfalls. This paper discusses the verification of the FFMs and presents the tools that were developed to make the verification process more efficient and effective.

reliability↗

NASA NTRS1972

Monopropellant hydrazine resistojet preliminary design task

The design effort for the electrothermal hydrazine thruster (ETH) is summarized. The EHT decomposes hydrazine thermally and expands the decomposition products through a nozzle to provide the impulse necessary to fulfill spacecraft propulsive requirements. The thruster is capable of operation at pulse widths from 0.050 second to steady state and delivers specific impulse values from 175 to greater than 225 seconds, depending upon the duty cycle. The design of the EHT is the result of an analytical effort combined with a series of design verification tests. The design requirements, design philosophy and detailed design methods are outlined. A discussion of the rationale behind the selection of materials for the EHT is included. The results of the design verification tests are also presented.

Murch, C. K.↗

NASA NTRS2005

A Tool for Requirements-Based Programming

Absent a general method for mathematically sound, automated transformation of customer requirements into a formal model of the desired system, developers must resort to either manual application of formal methods or to system testing (either manual or automated). While formal methods have afforded numerous successes, they present serious issues, e.g., costs to gear up to apply them (time, expensive staff), and scalability and reproducibility when standards in the field are not settled. The testing path cannot be walked to the ultimate goal, because exhaustive testing is infeasible for all but trivial systems. So system verification remains problematic. System or requirements validation is similarly problematic. The alternatives available today depend on either having a formal model or pursuing enough testing to enable the customer to be certain that system behavior meets requirements. The testing alternative for non-trivial systems always have some system behaviors unconfirmed and therefore is not the answer. To ensure that a formal model is equivalent to the customer s requirements necessitates that the customer somehow fully understands the formal model, which is not realistic. The predominant view that provably correct system development depends on having a formal model of the system leads to a desire for a mathematically sound method to automate the transformation of customer requirements into a formal model. Such a method, an augmentation of requirements-based programming, will be briefly described in this paper, and a prototype tool to support it will be described. The method and tool enable both requirements validation and system verification for the class of systems whose behavior can be described as scenarios. An application of the tool to a prototype automated ground control system for NASA mission is presented.

Rash, James L.↗

NASA NTRS2007

Integrating Human Factors into Crew Exploration Vehicle Design

With NASA's new Vision for Exploration to send humans beyond Earth orbit, it is critical to consider the human as a system that demands early and continuous user involvement, and an iterative prototype/test/redesign process. Addressing human-system interface issues early on can be very cost effective even cost reducing when performed early in the design and development cycle. To achieve this goal within Crew Exploration Vehicle (CEV) Project Office, human engineering (HE) team is formed. Key tasks are to apply HE requirements and guidelines to hardware/software, and provide HE design, analysis and evaluation of crew interfaces. Initial activities included many practice-orientated evaluations using low-fidelity CEV mock-ups. What follows is a description of such evaluations that focused on a HE requirement regarding Net Habitable Volume (NHV). NHV is defined as the total remaining pressurized volume available to on-orbit crew after accounting for the loss of volume due to deployed hardware and structural inefficiencies which decrease functional volume. The goal of the NHV evaluations was to develop requirements providing sufficient CEV NHV for crewmembers to live and perform tasks in support of mission goals. Efforts included development of a standard NHV calculation method using computer models and physical mockups, and crew/ stakeholder evaluations. Nine stakeholders and ten crewmembers participated in the unsuited evaluations. Six crewmembers also participated in a suited evaluation. The mock-up was outfitted with volumetric representation of sub-systems such as seats, and stowage bags. Thirteen scenarios were developed to represent mission/crew tasks and considered to be primary volume drivers (e.g., suit donning) for the CEV. Unsuited evaluations included a structured walkthrough of these tasks. Suited evaluations included timed donning of the existing launch and entry suit to simulate a contingency scenario followed by doffing/ stowing of the suits. All mockup evaluations were videotaped. Structured questionnaires were used to document user interface issues and volume impacts of layout configuration. Computer model and physical measures of the NHV agreed within 1 percent. This included measurement of the gross habitable volume, subtraction of intrusive volumes, and other non-habitable spaces. Calculation method developed was validated as a standard means of measuring NHV, and was recommended as a verification method for the NHV requirements. Evaluations confirmed that there was adequate volume for unsuited scenarios and suit donning/ doffing activity. Seats, suit design stowage and waste hygiene system noted to be critical volume drivers. The low-fidelity mock-up evaluations along with human modeling analysis generated discussions that will lead to high-level systems requirements and human-centered design decisions. This approach allowed HE requirements and operational concepts to evolve in parallel with engineering system concepts and design requirements. As the CEV design matures, these evaluations will continue and help with design decisions, and assessment, verification and validation of HE requirements.

Whitmore, Mihriban↗

NASA NTRS2006

Partial Automation of Requirements Tracing

Requirements Tracing on Target (RETRO) is software for after-the-fact tracing of textual requirements to support independent verification and validation of software. RETRO applies one of three user-selectable information-retrieval techniques: (1) term frequency/inverse document frequency (TF/IDF) vector retrieval, (2) TF/IDF vector retrieval with simple thesaurus, or (3) keyword extraction. One component of RETRO is the graphical user interface (GUI) for use in initiating a requirements-tracing project (a pair of artifacts to be traced to each other, such as a requirements spec and a design spec). Once the artifacts have been specified and the IR technique chosen, another component constructs a representation of the artifact elements and stores it on disk. Next, the IR technique is used to produce a first list of candidate links (potential matches between the two artifact levels). This list, encoded in Extensible Markup Language (XML), is optionally processed by a filtering component designed to make the list somewhat smaller without sacrificing accuracy. Through the GUI, the user examines a number of links and returns decisions (yes, these are links; no, these are not links). Coded in XML, these decisions are provided to a "feedback processor" component that prepares the data for the next application of the IR technique. The feedback reduces the incidence of erroneous candidate links. Unlike related prior software, RETRO does not require the user to assign keywords, and automatically builds a document index.

Hayes, Jane↗

NASA NTRSDate not supplied

From Requirements to Autonomous Flight: An Overview of the Monitoring ICAROUS Project

The Independent Configurable Architecture for Reliable Operations of Unmanned Systems(ICAROUS) is a software architecture incorporating a set of algorithms to enable autonomous operations of unmanned aircraft applications. This paper provides an overview of Monitoring ICAROUS, a project whose objective is to provide a formal approach to generating runtime monitors for autonomous systems from requirements written in a structured natural language. This approach integrates FRET, a formal requirement elicitation and authoring tool, and Copilot, a runtime verification framework. FRET is used to specify formal requirements in structured natural language. These requirements are translated into temporal logic formulae. Copilot is then used to generate executable runtime monitors from these temporal logic specifications. The generated monitors are directly integrated into ICAROUS to perform runtime verification during flight.

Formal Methods↗

NASA NTRSDate not supplied

Monitoring ICAROUS: From Requirements to Autonomous Flight

The Independent Configurable Architecture for Reliable Operations of Unmanned Systems (ICAROUS) is a software architecture incorporating a set of algorithms to enable autonomous operations of unmanned aircraft applications. This paper provides an overview of Monitoring ICAROUS, a project whose objective is to provide a formal approach to generating runtime monitors for autonomous systems from requirements written in a structured natural language. This approach integrates FRET, a formal requirement elicitation and authoring tool, and Copilot, a runtime verification framework. FRET is used to specify formal requirements in structured natural language. These requirements are translated into temporal logic formulae. Copilot is then used to generate executable runtime monitors from these temporal logic specifications. The generated monitors are directly integrated into ICAROUS to perform runtime verification during flight.

Formal Methods↗

NASA NTRS2016

Space Suit Portable Life Support System (PLSS) 2.0 Pre-Installation Acceptance (PIA) Testing

Following successful completion of the space suit Portable Life Support System (PLSS) 1.0 development and testing in 2011, the second system-level prototype, PLSS 2.0, was developed in 2012 to continue the maturation of the advanced PLSS design which is intended to reduce consumables, improve reliability and robustness, and incorporate additional sensing and functional capabilities over the current Space Shuttle/International Space Station Extravehicular Mobility Unit (EMU) PLSS. PLSS 2.0 represents the first attempt at a packaged design comprising first generation or later component prototypes and medium fidelity interfaces within a flight-like representative volume. Pre-Installation Acceptance (PIA) is carryover terminology from the Space Shuttle Program referring to the series of test sequences used to verify functionality of the EMU PLSS prior to installation into the Space Shuttle airlock for launch. As applied to the PLSS 2.0 development and testing effort, PIA testing designated the series of 27 independent test sequences devised to verify component and subsystem functionality, perform in situ instrument calibrations, generate mapping data to define set-points for control algorithms, evaluate hardware performance against advanced PLSS design requirements, and provide quantitative and qualitative feedback on evolving design requirements and performance specifications. PLSS 2.0 PIA testing was carried out from 3/20/13 - 3/15/14 using a variety of test configurations to perform test sequences that ranged from stand-alone component testing to system-level testing, with evaluations becoming increasingly integrated as the test series progressed. Each of the 27 test sequences was vetted independently, with verification of basic functionality required before completion. Because PLSS 2.0 design requirements were evolving concurrently with PLSS 2.0 PIA testing, the requirements were used as guidelines to assess performance during the tests; after the completion of PIA testing, test data served to improve the fidelity and maturity of design requirements as well as plans for future advanced PLSS functional testing.

Watts, Carly↗

NASA NTRS2016

Space Suit Portable Life Support System (PLSS) 2.0 Pre-Installation Acceptance (PIA) Testing

Following successful completion of the space suit Portable Life Support System (PLSS) 1.0 development and testing in 2011, the second system-level prototype, PLSS 2.0, was developed in 2012 to continue the maturation of the advanced PLSS design. This advanced PLSS is intended to reduce consumables, improve reliability and robustness, and incorporate additional sensing and functional capabilities over the current Space Shuttle/International Space Station Extravehicular Mobility Unit (EMU) PLSS. PLSS 2.0 represents the first attempt at a packaged design comprising first generation or later component prototypes and medium fidelity interfaces within a flight-like representative volume. Pre-Installation Acceptance (PIA) is carryover terminology from the Space Shuttle Program referring to the series of test sequences used to verify functionality of the EMU PLSS prior to installation into the Space Shuttle airlock for launch. As applied to the PLSS 2.0 development and testing effort, PIA testing designated the series of 27 independent test sequences devised to verify component and subsystem functionality, perform in situ instrument calibrations, generate mapping data, define set-points, evaluate control algorithms, evaluate hardware performance against advanced PLSS design requirements, and provide quantitative and qualitative feedback on evolving design requirements and performance specifications. PLSS 2.0 PIA testing was carried out in 2013 and 2014 using a variety of test configurations to perform test sequences that ranged from stand-alone component testing to system-level testing, with evaluations becoming increasingly integrated as the test series progressed. Each of the 27 test sequences was vetted independently, with verification of basic functionality required before completion. Because PLSS 2.0 design requirements were evolving concurrently with PLSS 2.0 PIA testing, the requirements were used as guidelines to assess performance during the tests; after the completion of PIA testing, test data served to improve the fidelity and maturity of design requirements as well as plans for future advanced PLSS functional testing.

Anchondo, Ian↗

NASA NTRS2018

Guidelines for Verification Strategies to Minimize RISK Based on Mission Environment, -Application and -Lifetime (MEAL)

There is a trend of compromising verification testing to address the cost and schedule constraints, which poses a high-risk posture for programs/projects. Current and emerging aerospace scientific and/or human exploration programs continue to pose new technological challenges. These technological challenges combined with finite budgets and truncated schedules are forcing designers, scientists, engineers, and managers to push technologies to their physical limits. In addition, budget and schedule pressures challenge how those technologies/missions are verified. A clear understanding of the different verification processes is needed to ensure the proper verification of the technology within the mission (i.e., capabilities, advantages, and limitations). The goal of verification is to prove through test, analysis, inspection, and/or demonstration that a product provides its required function while meeting the performance requirements. It is important that verification yield understanding of representative performance under worst-case conditions so that margins to failure can be evaluated for proposed applications. The capabilities, advantages, and limitations of the testing and inspection performed at each level are different, and the risk incurred by omitting a verification step depends on the level of integration as well as Mission, Environment, Application and Lifetime (MEAL). This paper focuses on verification processes. The goal of the verification process is to ensure the given avionics technology could be safely implemented on the given MEAL consistent with the program/project risk posture.

Gonzalez, Oscar↗

NASA NTRS2000

Timing analysis by model checking

The safety of modern avionics relies on high integrity software that can be verified to meet hard real-time requirements. The limits of verification technology therefore determine acceptable engineering practice. To simplify verification problems, safety-critical systems are commonly implemented under the severe constraints of a cyclic executive, which make design an expensive trial-and-error process highly intolerant of change. Important advances in analysis techniques, such as rate monotonic analysis (RMA), have provided a theoretical and practical basis for easing these onerous restrictions. But RMA and its kindred have two limitations: they apply only to verifying the requirement of schedulability (that tasks meet their deadlines) and they cannot be applied to many common programming paradigms. We address both these limitations by applying model checking, a technique with successful industrial applications in hardware design. Model checking algorithms analyze finite state machines, either by explicit state enumeration or by symbolic manipulation. Since quantitative timing properties involve a potentially unbounded state variable (a clock), our first problem is to construct a finite approximation that is conservative for the properties being analyzed-if the approximation satisfies the properties of interest, so does the infinite model. To reduce the potential for state space explosion we must further optimize this finite model. Experiments with some simple optimizations have yielded a hundred-fold efficiency improvement over published techniques.

Naydich, Dimitri↗

NASA NTRS2015

Attitude Design for the LADEE Mission

The Lunar Atmosphere and Dust Environment Explorer (LADEE) satellite successfully completed its 148-day science investigation in a low-altitude, near-equatorial lunar orbit on April 18, 2014. The LADEE spacecraft was built, managed and operated by NASA's Ames Research Center (ARC). The Mission Operations Center (MOC) was located at Ames and was responsible for activity planning, command sequencing, trajectory and attitude design, orbit determination, and spacecraft operations. The Science Operations Center (SOC) was located at Goddard Space Flight Center and was responsible for science planning, data archiving and distribution. This paper details attitude design and operations support for the LADEE mission. LADEE's attitude design was shaped by a wide range of instrument pointing requirements that necessitated regular excursions from the baseline one revolution per orbit "Ram" attitude. Such attitude excursions were constrained by a number of flight rules levied to protect instruments from the Sun, avoid geometries that would result in simultaneous occlusion of LADEE's two star tracker heads, and maintain the spacecraft within its thermal and power operating limits. To satisfy LADEE's many attitude requirements and constraints, a set of rules and conventions was adopted to manage the complexity of this design challenge and facilitate the automation of ground software that generated pointing commands spanning multiple days of operations at a time. The resulting LADEE Flight Dynamics System (FDS) that was developed used Visual Basic scripts that generated instructions to AGI's Satellite Tool Kit (STK) in order to derive quaternion commands at regular intervals that satisfied LADEE's pointing requirements. These scripts relied heavily on the powerful "align and constrain" capability of STK's attitude module to construct LADEE's attitude profiles and the slews to get there. A description of the scripts and the attitude modeling they embodied is provided. One particular challenge analysts faced was in the design of LADEE maneuver attitudes. A flight rule requiring pre-maneuver verification of in-flight maneuver conditions by ground operators prior to burn execution resulted in the need to accommodate long periods in the maneuver attitude. This in turn complicated efforts to satisfy star tracker interference and communication constraints in lunar orbit. In response to this challenge, a graphical method was developed and used to survey candidate rotation angles about the thrust vector. This survey method is described and an example of its use on a particular LADEE maneuver is discussed. Finally, the software and methodology used to satisfy LADEE's attitude requirements are also discussed in the context of LADEE's overall activity planning effort. In particular, the way in which strategic schedules of instrument and engineering activities were translated into actual attitude profiles at the tactical level, then converted into precise quaternion commands to achieve those pointing goals is explained. In order to reduce the risk of time-consuming re-planning efforts, this process included the generation of long-term projections of constraint violation predictions for individual attitude profiles that could be used to establish keep-out time-frames for particular attitude profiles. The challenges experienced and overall efficacy of both the overall LADEE ground system and the attitude components of the Flight Dynamics System in meeting LADEE's varied pointing requirements are discussed.

LADEE↗

DOE OSTI2025

An Open-Source Python Package for CFD Solution Verification

Informed decision-making using computational fluid dynamics (CFD) results requires quantifying the errors and uncertainties of a simulation. Verification, validation, and uncertainty quantification (VVUQ) methods were developed to address this need and have matured. However, these VVUQ analyses are often non-trivial and require CFD analysts and practitioners to have specific skill sets. This has led to the uneven adoption of VVUQ analyses, in part, based on the availability of software tools to aid CFD analysts and practitioners. Solution verification, a procedure to evaluate the accuracy of a simulation by estimating potential errors arising from the computational model and computing the uncertainties without comparing to results from a physical system, is one of the lagging VVUQ analyses as the absence of software has forced CFD analysts and practitioners to develop their own codes or piece together incomplete software from across the internet. This work presents an opensource Python package, CFDverify, to lower the barrier of entry and fill in the technological gap in solution verification. CFDverify also provides a streamlined framework to remove some potential errors in post-processing CFD results. The hope is that CFDverify can improve the quality and quantity of CFD solution verification in scientific and research studies and attract interest in developing a communal tool. This paper describes the design, features, and an example use of CFDverify.

Weinmeister, Justin [ORNL] (ORCID:0000000160090237↗