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 217 records · Page 12

Modal Testing of Seven Shuttle Cargo Elements for Space Station

From December 1996 to May 2001, the Modal and Control Dynamics Team at NASA's Marshall Space Flight Center (MSFC) conducted modal tests on seven large elements of the International Space Station. Each of these elements has been or will be launched as a Space Shuttle payload for transport to the International Space Station (ISS). Like other Shuttle payloads, modal testing of these elements was required for verification of the finite element models used in coupled loads analyses for launch and landing. The seven modal tests included three modules - Node, Laboratory, and Airlock, and four truss segments - P6, P3/P4, S1/P1, and P5. Each element was installed and tested in the Shuttle Payload Modal Test Bed at MSFC. This unique facility can accommodate any Shuttle cargo element for modal test qualification. Flexure assemblies were utilized at each Shuttle-to-payload interface to simulate a constrained boundary in the load carrying degrees of freedom. For each element, multiple-input, multiple-output burst random modal testing was the primary approach with controlled input sine sweeps for linearity assessments. The accelerometer channel counts ranged from 252 channels to 1251 channels. An overview of these tests, as well as some lessons learned, will be provided in this paper.

Kappus, Kathy O.↗

Seal Analysis for the Ares-I Upper Stage Fuel Tank Manhole Covers

Naflex seals have long history of use in launch vehicle components, including Saturn stages and Space Shuttle External Tank. Ares-I Upper Stage tank pressures are higher than ET pressures, requiring performance verification of heritage seal design in new manhole cover configurations. Heritage external tank analyses are reviewed for potential application to Upper Stage.

Phillips, Dawn R.↗

Distributed Observer Network

The Distributed Observer network (DON) is a NASA-collaborative environment that leverages game technology to bring three-dimensional simulations to conventional desktop and laptop computers in order to allow teams of engineers working on design and operations, either individually or in groups, to view and collaborate on 3D representations of data generated by authoritative tools such as Delmia Envision, Pro/Engineer, or Maya. The DON takes models and telemetry from these sources and, using commercial game engine technology, displays the simulation results in a 3D visual environment. DON has been designed to enhance accessibility and user ability to observe and analyze visual simulations in real time. A variety of NASA mission segment simulations [Synergistic Engineering Environment (SEE) data, NASA Enterprise Visualization Analysis (NEVA) ground processing simulations, the DSS simulation for lunar operations, and the Johnson Space Center (JSC) TRICK tool for guidance, navigation, and control analysis] were experimented with. Desired functionalities, [i.e. Tivo-like functions, the capability to communicate textually or via Voice-over-Internet Protocol (VoIP) among team members, and the ability to write and save notes to be accessed later] were targeted. The resulting DON application was slated for early 2008 release to support simulation use for the Constellation Program and its teams. Those using the DON connect through a client that runs on their PC or Mac. This enables them to observe and analyze the simulation data as their schedule allows, and to review it as frequently as desired. DON team members can move freely within the virtual world. Preset camera points can be established, enabling team members to jump to specific views. This improves opportunities for shared analysis of options, design reviews, tests, operations, training, and evaluations, and improves prospects for verification of requirements, issues, and approaches among dispersed teams.

Conroy, Michael↗

Mending the Gap, An Effort to Aid the Transfer of Formal Methods Technology

Formal methods can be applied to many of the development and verification activities required for civil avionics software. RTCA/DO-178B, Software Considerations in Airborne Systems and Equipment Certification, gives a brief description of using formal methods as an alternate method of compliance with the objectives of that standard. Despite this, the avionics industry at large has been hesitant to adopt formal methods, with few developers have actually used formal methods for certification credit. Why is this so, given the volume of evidence of the benefits of formal methods? This presentation will explore some of the challenges to using formal methods in a certification context and describe the effort by the Formal Methods Subgroup of RTCA SC-205/EUROCAE WG-71 to develop guidance to make the use of formal methods a recognized approach.

Hayhurst, Kelly↗

Internal NASA Study: NASAs Protoflight Research Initiative

The NASA Protoflight Research Initiative is an internal NASA study conducted within the Office of the Chief Engineer to better understand the use of Protoflight within NASA. Extensive literature reviews and interviews with key NASA members with experience in both robotic and human spaceflight missions has resulted in three main conclusions and two observations. The first conclusion is that NASA's Protoflight method is not considered to be "prescriptive." The current policies and guidance allows each Program/Project to tailor the Protoflight approach to better meet their needs, goals and objectives. Second, Risk Management plays a key role in implementation of the Protoflight approach. Any deviations from full qualification will be based on the level of acceptable risk with guidance found in NPR 8705.4. Finally, over the past decade (2004 - 2014) only 6% of NASA's Protoflight missions and 6% of NASA's Full qualification missions experienced a publicly disclosed mission failure. In other words, the data indicates that the Protoflight approach, in and of it itself, does not increase the mission risk of in-flight failure. The first observation is that it would be beneficial to document the decision making process on the implementation and use of Protoflight. The second observation is that If a Project/Program chooses to use the Protoflight approach with relevant heritage, it is extremely important that the Program/Project Manager ensures that the current project's requirements falls within the heritage design, component, instrument and/or subsystem's requirements for both the planned and operational use, and that the documentation of the relevant heritage is comprehensive, sufficient and the decision well documented. To further benefit/inform this study, a recommendation to perform a deep dive into 30 missions with accessible data on their testing/verification methodology and decision process to research the differences between Protoflight and Full Qualification missions' Design Requirements and Verification & Validation (V&V) (without any impact or special request directly to the project).

Protoflight↗

Formal Methods in Air Traffic Management: The Case of Unmanned Aircraft Systems

As the technological and operational capabilities of unmanned aircraft systems (UAS) continue to grow, so too does the need to introduce these systems into civil airspace. Unmanned Aircraft Systems Integration in the National Airspace System is a NASA research project that addresses the integration of civil UAS into non-segregated airspace operations. One of the major challenges of this integration is the lack of an onboard pilot to comply with the legal requirement that pilots see and avoid other aircraft. The need to provide an equivalent to this requirement for UAS has motivated the development of a detect and avoid (DAA) capability to provide the appropriate situational awareness and maneuver guidance in avoiding and remaining well clear of traffic aircraft. Formal methods has played a fundamental role in the development of this capability. This talk reports on the formal methods work conducted under NASA's Safe Autonomous System Operations project in support of the development of DAA for UAS. This work includes specification of low-level and high-level functional requirements, formal verification of algorithms, and rigorous validation of software implementations. The talk also discusses technical challenges in formal methods research in the context of the development and safety analysis of advanced air traffic management concepts.

Munoz, Cesar A.↗

Unmanned Aircraft Systems in the National Airspace System: A Formal Methods Perspective

As the technological and operational capabilities of unmanned aircraft systems (UAS) have grown, so too have international efforts to integrate UAS into civil airspace. However, one of the major concerns that must be addressed in realizing this integration is that of safety. For example, UAS lack an on-board pilot to comply with the legal requirement that pilots see and avoid other aircraft. This requirement has motivated the development of a detect and avoid (DAA) capability for UAS that provides situational awareness and maneuver guidance to UAS operators to aid them in avoiding and remaining well clear of other aircraft in the airspace. The NASA Langley Research Center Formal Methods group has played a fundamental role in the development of this capability. This article gives a selected survey of the formal methods work conducted in support of the development of a DAA concept for UAS. This work includes specification of low-level and high-level functional requirements, formal verification of algorithms, and rigorous validation of software implementations.

Munoz, Cesar A.↗

MARGInS Model-Based Analysis of Realizable Goals in Systems

The high complexity of modern aircraft and spacecraft requires elaborate Verification and Validation (V&V) approaches to make sure that such complex systems work properly and reliably. MARGInS is a framework for the analysis, understanding, and prediction of the behavior of a complex, hybrid system. MARGInS contains a set of machine learning and statistical algorithms for multivariate clustering, treatment learning, critical factor determination, time-series analysis, event prediction, and safety-boundary detection and characterization. The framework supports system testing and can be configured to find novel features in test suites, determine classes of behavior, propose new experiments that can efficiently explore and characterize the boundaries between classes of system behavior, and to create visualizations and reports.

He, Yuning↗

Integrating Human System Information with the Systems Platform for Aggregating and Relating Capabilities (SPARC)

Within Human Health and Performance, there exists a wealth of human system information that’s used a regular basis in support of NASA human exploration objectives, but the challenge is that all of this information was stored in multiple different locations and organized for specific uses, limiting its effectiveness and straining communication across multiple groups. To address this challenge, our project, the Systems Platform for Aggregating and Relating Capabilities (SPARC) was tasked with developing a new NASA internal web application that aggregates and relates multiple programs’ human system products, such as technical standards, program requirements and verifications, human system risks, research and evidence, and exploration capabilities, into one centralized platform that addresses the needs of human health and performance from multiple different perspectives. Using agile development methodologies, user-experience (UX) driven design principles, data visualization, and a strong emphasis on continuous improvement though consistent stakeholder engagement, the SPARC project released a beta version in less than 4 months, broadly launched version 1.0.0 Agency-wide three months after the beta, and has over 180 users in the first year of development. Our second year of development will see us moving from our initial capabilities to increasingly robust and complex integrations and visualizations, including Directed Acyclical Graphs (DAGs), natural language processing (NLP) for dynamic generation of relationships between the sources of truth, and an expansion into hierarchical levels of system design in support of the human exploration programs.

Data science↗

Credible Computations: Standard and Uncertainty

The discipline of computational fluid dynamics (CFD) is at a crossroad. Most of the significant advances related to computational methods have taken place. The emphasis is now shifting from methods to results. Significant efforts are made in applying CFD to solve design problems. The value of CFD results in design depends on the credibility of computed results for the intended use. The process of establishing credibility requires a standard so that there is a consistency and uniformity in this process and in the interpretation of its outcome. The key element for establishing the credibility is the quantification of uncertainty. This paper presents salient features of a proposed standard and a procedure for determining the uncertainty. A customer of CFD products - computer codes and computed results - expects the following: A computer code in terms of its logic, numerics, and fluid dynamics and the results generated by this code are in compliance with specified requirements. This expectation is fulfilling by verification and validation of these requirements. The verification process assesses whether the problem is solved correctly and the validation process determines whether the right problem is solved. Standards for these processes are recommended. There is always some uncertainty, even if one uses validated models and verified computed results. The value of this uncertainty is important in the design process. This value is obtained by conducting a sensitivity-uncertainty analysis. Sensitivity analysis is generally defined as the procedure for determining the sensitivities of output parameters to input parameters. This analysis is a necessary step in the uncertainty analysis, and the results of this analysis highlight which computed quantities and integrated quantities in computations need to be determined accurately and which quantities do not require such attention. Uncertainty analysis is generally defined as the analysis of the effect of the uncertainties involved in all stages of a process on the final responses. There are two approaches for conducting the uncertainty analysis: experimental and computational. These analyses and approaches are briefly described.

Mehta, Unmeel B.↗

Scatterometer-Calibrated Stability Verification Method

The requirement for scatterometer-combined transmit-receive gain variation knowledge is typically addressed by sampling a portion of the transmit signal, attenuating it with a known-stable attenuation, and coupling it into the receiver chain. This way, the gain variations of the transmit and receive chains are represented by this loop-back calibration signal, and can be subtracted from the received remote radar echo. Certain challenges are presented by this process, such as transmit and receive components that are outside of this loop-back path and are not included in this calibration, as well as the impracticality for measuring the transmit and receive chains stability and post fabrication separately, without the resulting measurement errors from the test set up exceeding the requirement for the flight instrument. To cover the RF stability design challenge, the portions of the scatterometer that are not calibrated by the loop-back, (e.g., attenuators, switches, diplexers, couplers, and coaxial cables) are tightly thermally controlled, and have been characterized over temperature to contribute less than 0.05 dB of calibration error over worst-case thermal variation. To address the verification challenge, including the components that are not calibrated by the loop-back, a stable fiber optic delay line (FODL) was used to delay the transmitted pulse, and to route it into the receiver. In this way, the internal loopback signal amplitude variations can be compared to the full transmit/receive external path, while the flight hardware is in the worst-case thermal environment. The practical delay for implementing the FODL is 100 s. The scatterometer pulse width is 1 ms so a test mode was incorporated early in the design phase to scale the 1 ms pulse at 100-Hz pulse repetition interval (PRI), by a factor of 18, to be a 55 s pulse with 556 s PRI. This scaling maintains the duty cycle, thus maintaining a representative thermal state for the RF components. The FODL consists of an RF-modulated fiber-optic transmitter, 20 km SMF- 28 standard single-mode fiber, and a photodetector. Thermoelectric cooling and insulating packaging are used to achieve high thermal stability of the FODL components. The chassis was insulated with 1-in. (.2.5-cm) thermal isolation foam. Nylon rods support the Micarta plate, onto which are mounted four 5-km fiber spool boxes. A copper plate heat sink was mounted on top of the fiber boxes (with thermal grease layer) and screwed onto the thermoelectric cooler plate. Another thermal isolation layer in the middle separates the fiberoptics chamber from the RF electronics components, which are also mounted on a copper plate that is screwed onto another thermoelectric cooler. The scatterometer subsystem fs overall stability was successfully verified to be calibratable to within 0.1 dB error in thermal vacuum (TVAC) testing with the fiber-optic delay line, while the scatterometer temperature was ramped from 10 to 30 C, which is a much larger temperature range than the worst-case expected seasonal variations.

McWatters, Dalia A.↗

Expert system verification and validation study. Phase 2: Requirements identification. Delivery 1: Updated survey report

The purpose is to report the state-of-the-practice in Verification and Validation (V and V) of Expert Systems (ESs) on current NASA and Industry applications. This is the first task of a series which has the ultimate purpose of ensuring that adequate ES V and V tools and techniques are available for Space Station Knowledge Based Systems development. The strategy for determining the state-of-the-practice is to check how well each of the known ES V and V issues are being addressed and to what extent they have impacted the development of Expert Systems.

Source record↗

Pointing Error Budget Development and Methodology on the Psyche Project

The Psyche mission was selected by NASA as the 14th mission in the Discovery Program in 2017. The Psyche spacecraft utilizes solar electric propulsion, and will journey to the asteroid (16) Psyche during a 3.5 year trajectory after its planned 2022 launch. The spacecraft instrument suite includes a magnetometer, a multispectral imager, a gamma ray neutron spectrometer, and an X-band radio telecommunications system. It also includes the Deep Space Optical Communication technical demonstration. These instruments along with other spacecraft components require pointing accuracy to meet their scientific and engineering performance requirements. Early on in the project development, the team established a methodology by which pointing accuracy (knowledge and control) is analyzed against the system requirements by means of pointing error budgets and requirement allocations. A margin policy was implemented to ensure the instrument and engineering component pointing accuracy requirements will be met during verification and in flight. Psyche’s pointing management framework defines detailed rationales for the system and subsystem error allocations of the top level pointing accuracy requirements, with sufficient project level pointing margin, and supports end-to-end pointing requirement verification. This paper will present an overview of the Psyche project’s pointing error budget development process, and discuss the rationale behind the methodology. Psyche’s pointing budget methodology integrates best practices and lessons learned from heritage missions, while focusing on the specific needs of the Psyche spacecraft and its science instruments. Key challenges in the pointing error budget development will be reviewed, and a deep dive into two key Psyche pointing budgets are presented. The systems engineering of Psyche’s pointing budget methodology outlined in this paper will serve as a resource for future deep space missions.

Lai, Peter↗

Expert system verification and validation study. Phase 2: Requirements Identification. Delivery 2: Current requirements applicability

The second phase of a task is described which has the ultimate purpose of ensuring that adequate Expert Systems (ESs) Verification and Validation (V and V) tools and techniques are available for Space Station Freedom Program Knowledge Based Systems development. The purpose of this phase is to recommend modifications to current software V and V requirements which will extend the applicability of the requirements to NASA ESs.

Source record↗

Verification of the REBUS Software

Ongoing design activities at Argonne National Laboratory are requiring a thorough verification of the Argonne Reactor Computation codes be performed. REBUS is central to this system. The driver for this effort requires the Triangular-Z and hexagonal-Z core geometry options of REBUS to be verified. Previous work identified the REBUS features required to be verified to support current design activities, features of which are generally applicable to hexagonal-Z fast reactor designs. The scope of this verification effort includes verifying REBUS’s ability to correctly intepret the user input model, verifying that the features identified yield the intended results, and verifying the correctness of the REBUS output tables. The REBUS software verification relies heavily upon the accuracy of the embedded DIF3D software, the verification of which was completed and documented elsewhere. Given that DIF3D produces an accurate solution, the primary focus of the verification in the REBUS software is to ensure that it properly uses the DIF3D solution and that the depletion system (Bateman equations) are correctly implemented. This manuscript reiterates the verification tasks and displays results with respect to the features needed for current design activities. Analytic solutions of the Batemen equations are displayed and the results calculated with REBUS are displayed demonstrating the accuracy. Since coupled Bateman and neutron diffusion/transport solutions are extremely difficult to obtain, much of the focus is placed on how REBUS uses a given DIF3D solution assuming the accuracy of the DIF3D solution. The verification effort identified no issues that are debilitating or otherwise impactful to the design usage of REBUS, and thus REBUS version 11.0, release 3012 is considered verified. It is important to note that several outputs of REBUS are identified to be inaccurate, such as burnup in MWD/MT. Most of the relevant ones for VTR are generally accurate with 10-20% errors which is not impactful as all regular REBUS users are aware of this issue and know how to hand calculate the results. The REBUS manual further makes it clear that these values are consistent with the methodology being used by REBUS and thus the “errors” are more of an inconsistent definition with respect to what a user would expect given a definition in literature. Other issues that were identified included unclear documentation and software bugs all of which were inconsequential to the final results.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗

Automated Verification of Programmable Logic Controller Programs Against Structured Natural Language Requirements

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.

formal methods↗

Garbage collection can be made real-time and verifiable

An efficient means of memory reclamation (also known as Garbage Collection) is essential for Machine Intelligence applications where dynamic storage allocation is desired or required. Solutions for real-time systems must introduce very small processing overhead and must also provide for the verification of the software in order to meet the application time budgets and to verify the correctness of the software. Garbage Collection (GC) techniques are proposed for symbolic processing systems which may simultaneously meet both real-time requirements and verification requirements. The proposed memory reclamation technique takes advantage of the strong points of both the earlier Mark and Sweep technique and the more recent Copy Collection approaches. At least one practical implementation of these new GC techniques has already been developed and tested on a very-high performance symbolic computing system. Complete GC processing of all generated garbage has been demonstrated to require as little as a few milliseconds to perform. This speed enables the effective operation of the GC function as either a background task or as an actual part of the application task itself.

Hino, James H.↗

Simplifying Requirements Formalization for Resource-Constrained Mission-Critical Software

Developing critical software requires adherence to rigorous software development practices, such as formal requirement specification and verification. Despite their importance, such practices are often considered as complex and challenging tasks that require a strong formal methods background. In this paper, we present our work on simplifying the formal requirements specification experience for resource-constrained mission critical software through the use of structured natural language. To this end, we connect NASA’s FRET, a formal requirement elicitation and authoring tool with the Shelley model checking framework for MicroPython code. We report our experience on using these tools to specify requirements and analyze code from the NASA Ames PHALANX exploration concept.

PHALANX exploration concept↗