Search NASA⌕ Search

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.

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

At least 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS2023

From Natural Language Requirements to the Verification of Programmable Logic Controllers: Integrating FRET into PLCverif

PLCverif is an actively developed project at CERN, enabling the formal verification of Programmable Logic Controller (PLC) programs in critical systems. In this paper, we present our work on improving the formal requirements specification experience in PLCverif through the use of natural language. To this end, we integrate NASA’s FRET, a formal requirement elicitation and authoring tool, into PLCverif. FRET is used to specify formal requirements in structured natural language, which automatically translates into temporal logic formulae. FRET’s output is then directly used by PLCverif for verification purposes. We discuss practical challenges that PLCverif users face when authoring requirements and the FRET features that help alleviate these problems. We present the new requirement formalization workflow and report our experience using it on two critical CERN case studies.

FRET↗
NASA NTRSDate not supplied

From Natural Language Requirements to the Verification of Programmable Logic Controllers: Integrating FRET into PLCverif

PLCverif is an actively developed project at CERN, enabling the formal verification of Programmable Logic Controller (PLC) programs in critical systems. In this paper, we present our work on improving the formal requirements specification experience in PLCverif through the use of natural language. To this end, we integrate NASA’s FRET, a formal requirement elicitation and authoring tool, into PLCverif. FRET is used to specify formal requirements in structured natural language, which automatically translates into temporal logic formulae. FRET’s output is then directly used by PLCverif for verification purposes. We discuss practical challenges that PLCverif users face when authoring requirements and the FRET features that help alleviate these problems. We present the new requirement formalization workflow and report our experience using it on two critical CERN case studies.

FRET↗
NASA NTRS2017

The NASA Space Launch System Program Systems Engineering Approach for Affordability

The National Aeronautics and Space Administration is currently developing the Space Launch System to provide the United States with a capability to launch large Payloads into Low Earth orbit and deep space. One of the development tenets of the SLS Program is affordability. One initiative to enhance affordability is the SLS approach to requirements definition, verification and system certification. The key aspects of this initiative include: 1) Minimizing the number of requirements, 2) Elimination of explicit verification requirements, 3) Use of certified models of subsystem capability in lieu of requirements when appropriate and 4) Certification of capability beyond minimum required capability. Implementation of each aspect is described and compared to a "typical" systems engineering implementation, including a discussion of relative risk. Examples of each implementation within the SLS Program are provided.

Hutt, John J.↗
NASA NTRS1972

ASRDI Oxygen Technology Survey. Volume 2: Cleaning Requirements, Procedures, and Verification Techniques

The oxygen system cleaning specifications drawn from 23 industrial and government sources are presented along with cleaning processes employed for meeting these specifications, and recommended postcleaning inspection procedures for establishing the cleanliness achieved. Areas of agreement and difference in the specifications, procedures, and inspection are examined. Also, the lack of clarity or specificity will be discussed. This absence of clarity represents potential safety hazards due to misinterpretation. It can result in exorbitant expenditures of time and money in satisfying unnecessary requirements.

Bankaitis, H.↗
NASA NTRS2019

Spacecraft Requirements Development and Tailoring

Spacecraft design is managed through the use of design requirements. Requirements are flowed from the highest level, the overall spacecraft, to systems, subsystems and ultimately individual components. Through the use of requirements, each part of the spacecraft will perform the functions that are required of it and will interface to the rest of the spacecraft. Functional requirements are used to make sure every component performs as expected and interface requirements ensure that each component works within the larger design environment where it operates. Writing good requirements is difficult and the verification of requirements can be expensive and time consuming. Because of this difficulty and expense, it is important that each requirement truly be “required” and critical to the overall performance of the vehicle. It is also important that requirements can be changed or eliminated as the system matures to minimize verification cost and schedule. The Capsule Parachute Assembly System (CPAS) Project is developing the parachute system for the NASA Multi-Purpose Crew Vehicle (MPCV) Orion Spacecraft. Throughout the development and qualification cycle for CPAS, requirements have been evaluated, added, eliminated, or more generically, “tailored”, to ensure that the system performs as required while minimizing the verification cost to the Program. One facet of this tailoring has been to delete requirements that do not add value to the overall spacecraft or are not needed. A second approach to minimize the cost of requirement verification has been to evaluate requirements based on the actual design as it has matured. As the design of the parachute system has become better understood, requirements that are not applicable have been eliminated. This paper will outline the evolution of CPAS requirements over time and will show how careful and considered changes to requirements can benefit the technical solution for the overall system design while allowing a Project to control costs.

Mcmichael, James H.↗
NASA NTRS2011

Formal Verification Toolkit for Requirements and Early Design Stages

Efficient flight software development from natural language requirements needs an effective way to test designs earlier in the software design cycle. A method to automatically derive logical safety constraints and the design state space from natural language requirements is described. The constraints can then be checked using a logical consistency checker and also be used in a symbolic model checker to verify the early design of the system. This method was used to verify a hybrid control design for the suit ports on NASA Johnson Space Center's Space Exploration Vehicle against safety requirements.

Badger, Julia M.↗
NASA NTRS2015

Alternative Nonvolatile Residue Analysis with Contaminant Identification Project

Cleanliness verification is required in numerous industries including spaceflight ground support, electronics, medical and aerospace. Currently at KSC requirement for cleanliness verification use solvents that environmentally unfriendly. This goal of this project is to produce an alternative cleanliness verification technique that is both environmentally friendly and more cost effective.

Technology Portfolio System↗
NASA NTRS1972

Ground truth data requirements for altimeter performance verification

The amount and type of ground truth required for an altimeter experiment is a function of the uncertainty in the satellite orbit, the altimeter error budget and the type of operation being performed. Ground truth requirements will be discussed with reference to three areas of operation: the global mode, the high intensity mode and calibration.

Walsh, E. J.↗
NASA NTRS2010

Applying Monte Carlo Simulation to Launch Vehicle Design and Requirements Analysis

This Technical Publication (TP) is meant to address a number of topics related to the application of Monte Carlo simulation to launch vehicle design and requirements analysis. Although the focus is on a launch vehicle application, the methods may be applied to other complex systems as well. The TP is organized so that all the important topics are covered in the main text, and detailed derivations are in the appendices. The TP first introduces Monte Carlo simulation and the major topics to be discussed, including discussion of the input distributions for Monte Carlo runs, testing the simulation, how many runs are necessary for verification of requirements, what to do if results are desired for events that happen only rarely, and postprocessing, including analyzing any failed runs, examples of useful output products, and statistical information for generating desired results from the output data. Topics in the appendices include some tables for requirements verification, derivation of the number of runs required and generation of output probabilistic data with consumer risk included, derivation of launch vehicle models to include possible variations of assembled vehicles, minimization of a consumable to achieve a two-dimensional statistical result, recontact probability during staging, ensuring duplicated Monte Carlo random variations, and importance sampling.

Hanson, J. M.↗
NASA NTRS2018

6DOF Testing of the SLS Inertial Navigation Unit

The Navigation System on the NASA Space Launch System (SLS) Block 1 vehicle performs initial alignment of the Inertial Navigation System (INS) navigation frame through gyrocompass alignment (GCA). Because the navigation architecture for the SLS Block 1 vehicle is a purely inertial system, the accuracy of the achieved orbit relative to mission requirements is very sensitive to initial alignment accuracy. The assessment of this sensitivity and many others via simulation is a part of the SLS Model-Based Design and Model-Based Requirements approach. As a part of the aforementioned, 6DOF Monte Carlo simulation is used in large part to develop and demonstrate verification of program requirements. To facilitate this and the GN&C flight software design process, an SLS-Program-controlled Design Math Model (DMM) of the SLS INS was developed by the SLS Navigation Team. The SLS INS model implements all of the key functions of the hardware-namely, GCA, inertial navigation, and FDIR (Fault Detection, Isolation, and Recovery)-in support of SLS GN&C design requirements verification. Despite the strong sensitivity to initial alignment, GCA accuracy requirements were not verified by test due to program cost and schedule constraints. Instead, the system relies upon assessments performed using the SLS INS model. In order to verify SLS program requirements by analysis, the SLS INS model is verified and validated against flight hardware. In lieu of direct testing of GCA accuracy in support of requirement verification, the SLS Navigation Team proposed and conducted an engineering test to, among other things, validate the GCA performance and overall behavior of the SLS INS model through comparison with test data. This paper will detail dynamic hardware testing of the SLS INS, conducted by the SLS Navigation Team at Marshall Space Flight Center's 6DOF Table Facility, in support of GCA performance characterization and INS model validation. A 6-DOF motion platform was used to produce 6DOF pad twist and sway dynamics while a simulated SLS flight computer communicated with the INS. Tests conducted include an evaluation of GCA algorithm robustness to increasingly dynamic pad environments, an examination of GCA algorithm stability and accuracy over long durations, and a long-duration static test to gather enough data for Allan Variance analysis. Test setup, execution, and data analysis will be discussed, including analysis performed in support of SLS INS model validation.

Geohagan, Kevin↗
NASA NTRS2020

Bridging the Gap Between Requirements and Simulink Model Analysis

Formal verification and simulation are powerful tools for the verification of requirements against complex systems. Requirements are developed in early stages of the software lifecycle and are typically expressed in natural language. There is a gap between such requirements and their software implementations.We present a framework that bridges this gap by supporting a tight integration and feedback loop between high-level requirements and their analysis against software artifacts. Our framework implements an analysis portal within the fret requirements elicitation tool, thus forming an end-to-end, open-source environment where requirements are written in an intuitive, structured natural language, and are verified automatically against Simulink models.

Mavridou, Anastasia↗
NASA NTRS1994

The PLAID graphics analysis impact on the space program

An ongoing project design often requires visual verification at various stages. These requirements are critically important because the subsequent phases of that project might depend on the complete verification of a particular stage. Currently, there are several software packages at JSC that provide such simulation capabilities. We present the simulation capabilities of the PLAID modeling system used in the Flight Crew Support Division for human factors analyses. We summarize some ongoing studies in kinematics, lighting, EVA activities, and discuss various applications in the mission planning of the current Space Shuttle flights and the assembly sequence of the Space Station Freedom with emphasis on the redesign effort.

Nguyen, Jennifer P.↗
NASA NTRS2015

Closed Loop Requirements and Analysis Management

Effective systems engineering involves the use of analysis in the derivation of requirements and verification of designs against those requirements. The initial development of requirements often depends on analysis for the technical definition of specific aspects of a product. Following the allocation of system-level requirements to a product's components, the closure of those requirements often involves analytical approaches to verify that the requirement criteria have been satisfied. Meanwhile, changes that occur in between these two processes need to be managed in order to achieve a closed-loop requirement derivation/verification process. Herein are presented concepts for employing emerging Team center capabilities to jointly manage requirements and analysis data such that analytical techniques are utilized to effectively derive and allocate requirements, analyses are consulted and updated during the change evaluation processes, and analyses are leveraged during the design verification process. Recommendations on concept validation case studies are also discussed.

Lamoreaux, Michael↗