Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “software testing”

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 361 records · Page 20
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

Single-Bar SMT Creep-Fatigue Testing on Alloy 617 with Software Controls on elastic Follow-Up Feedback in Support of New Creep-Fatigue Design Methodology

The Simplified Model Test (SMT) is one of the alternative ways to calculate the creep-fatigue damage of elevated temperature components. The SMT approach unifies the creep and fatigue damage, simplifying the damage calculation process with improved accuracy. Traditionally, SMT tests has have been conducted through the two bars: first is the driver bar and second is the test bar. The driver bar stays elastic and imposes the confinement to the second bar. This experimental procedure requires two test frames and a large test specimen, which limits the test parameter range and accessibility of this testing procedures. Hence, a single-bar SMT (SB-SMT) tests has been developed to simplify complexity in SMT experiment setup. The software-controlled SB-SMT test process has been introduced which completely replaces the driver bar. This paper discusses the single-bar SMT (SB-SMT) test procedure with software controls. The challenges and critical parameters in the software-controlled SB-SMT procedure are addresses addressed and recommendations are provided. A scoping test with a set of wider strain range, elastic follow-ups and dwell time validated the proposed test procedure.

11 NUCLEAR FUEL CYCLE AND FUEL MATERIALS↗
NASA NTRS1999

When is Testing Sufficient

The Software Assurance Technology Center (SATC) at NASA Goddard Space Flight Center has been investigating how projects can determine when sufficient testing has been completed. For most projects, schedules are underestimated, and the last phase of the software development, testing, must be decreased. Two questions are frequently asked: "To what extent is the software error-free? " and "How much time and effort is required to detect and remove the remaining errors? " Clearly, neither question can be answered with absolute certainty. Nonetheless, the ability to answer these questions with some acceptable level of confidence is highly desirable. First, knowing the extent to which a product is error-free, we can judge when it is time to terminate testing. Secondly, if errors are judged to be present, we can perform a cost/benefit trade-off analysis to estimate when the software will be ready for use and at what cost. This paper explains the efforts of the SATC to help projects determine what is sufficient testing and when is the most cost-effective time to stop testing.

Rosenberg, Linda H.↗
DOE OSTI2015

A Software Developer’s Guide to Informal Evaluation of Visual Analytics Environments Using VAST Challenge Information

The VAST Challenge has been a popular venue for academic and industry participants for over ten years. Many participants comment that the majority of their time in preparing VAST Challenge entries is discovering elements in their software environments that need to be redesigned in order to solve the given task. Fortunately, there is no need to wait until the VAST Challenge is announced to test out software systems. The Visual Analytics Benchmark Repository contains all past VAST Challenge tasks, data, solutions and submissions. This paper details the various types of evaluations that may be conducted using the Repository information. In this paper we describe how developers can do informal evaluations of various aspects of their visual analytics environments using VAST Challenge information. Aspects that can be evaluated include the appropriateness of the software for various tasks, the various data types and formats that can be accommodated, the effectiveness and efficiency of the process supported by the software, and the intuitiveness of the visualizations and interactions. Researchers can compare their visualizations and interactions to those submitted to determine novelty. In addition, the paper provides pointers to various guidelines that software teams can use to evaluate the usability of their software. While these evaluations are not a replacement for formal evaluation methods, this information can be extremely useful during the development of visual analytics environments.

evaluation↗
DOE OSTI2016

SU-F-P-54: Guidelines to Check Image Registration QA of a Clinical Deformation Registration Software: A Single Institution Preliminary Study

Purpose: The objective of this study is to verify and analyze the accuracy of a clinical deformable image registration (DIR) software. Methods: To test clinical DIR software qualitatively and quantitatively, we focused on lung radiotherapy and analyzed a single (Lung) patient CT scan. Artificial anatomical changes were applied to account for daily variations during the course of treatment including the planning target volume (PTV) and organs at risk (OAR). The primary CT (pCT) and the structure set (pST) was deformed with commercial tool (ImSimQA-Oncology Systems Limited) and after artificial deformation (dCT and dST) sent to another commercial tool (VelocityAI-Varian Medical Systems). In Velocity, the deformed CT and structures (dCT and dST) were inversely deformed back to original primary CT (dbpCT and dbpST). We compared the dbpST and pST structure sets using similarity metrics. Furthermore, a binary deformation field vector (BDF) was created and sent to ImSimQA software for comparison with known “ground truth” deformation vector fields (DVF). Results: An image similarity comparison was made by using “ground truth” DVF and “deformed output” BDF with an output of normalized “cross correlation (CC)” and “mutual information (MI)” in ImSimQA software. Results for the lung case were MI=0.66 and CC=0.99. The artificial structure deformation in both pST and dbpST was analyzed using DICE coefficient, mean distance to conformity (MDC) and deformation field error volume histogram (DFEVH) by comparing them before and after inverse deformation. We have noticed inadequate structure match for CTV, ITV and PTV due to close proximity of heart and overall affected by lung expansion. Conclusion: We have seen similarity between pCT and dbpCT but not so well between pST and dbpST, because of inadequate structure deformation in clinical DIR system. This system based quality assurance test will prepare us for adopting the guidelines of upcoming AAPM task group 132 protocol.

60 APPLIED LIFE SCIENCES↗
DOE OSTI2025

Creation of a Weather Drivers Test Suite for Inclusion in ASHRAE Standard 140

Weather conditions are an important boundary condition for building performance simulation (BPS) calculations. For existing test cases in ASHRAE Standard 140 "Method of Test for Evaluating Building Performance Simulation Software" (ANSI/ASHRAE 2020), it was assumed that the software being tested could adequately read and interpret the weather data in the provided standard weather files. As differences between the programs have been reduced and as more programs have shifted to sub-hourly time steps this assumption has become more stretched. To address these concerns a new test suite testing a program's ability to read and interpret the data from a standard weather file was developed. The purpose of the test suite is to test the use of the typical data used from standard weather files.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2001

Testing Linear Temporal Logic Formulae on Finite Execution Traces

We present an algorithm for efficiently testing Linear Temporal Logic (LTL) formulae on finite execution traces. The standard models of LTL are infinite traces, reflecting the behavior of reactive and concurrent systems which conceptually may be continuously alive. In most past applications of LTL. theorem provers and model checkers have been used to formally prove that down-scaled models satisfy such LTL specifications. Our goal is instead to use LTL for up-scaled testing of real software applications. Such tests correspond to analyzing the conformance of finite traces against LTL formulae. We first describe what it means for a finite trace to satisfy an LTL property. We then suggest an optimized algorithm based on transforming LTL formulae. The work is done using the Maude rewriting system. which turns out to provide a perfect notation and an efficient rewriting engine for performing these experiments.

Havelund, Klaus↗
NASA NTRS2011

The Space Operations Simulation Center (SOSC) and Closed-loop Hardware Testing for Orion Rendezvous System Design

The Space Operations Simulation Center (SOSC) at the Lockheed Martin (LM) Waterton Campus in Littleton, Colorado is a dynamic test environment focused on Autonomous Rendezvous and Docking (AR&D) development testing and risk reduction activities. The SOSC supports multiple program pursuits and accommodates testing Guidance, Navigation, and Control (GN&C) algorithms for relative navigation, hardware testing and characterization, as well as software and test process development. The SOSC consists of a high bay (60 meters long by 15.2 meters wide by 15.2 meters tall) with dual six degree-of-freedom (6DOF) motion simulators and a single fixed base 6DOF robot. The large testing area (maximum sensor-to-target effective range of 60 meters) allows for large-scale, flight-like simulations of proximity maneuvers and docking events. The facility also has two apertures for access to external extended-range outdoor target test operations. In addition, the facility contains four Mission Operations Centers (MOCs) with connectivity to dual high bay control rooms and a data/video interface room. The high bay is rated at Class 300,000 (. 0.5 m maximum particles/m3) cleanliness and includes orbital lighting simulation capabilities.

D'Souza, Christopher↗
NASA NTRS2018

Software Defined Wireless Avionics for Flight Test

Wireless avionics could revolutionize current flight systems by reducing nonrecurring engineering, providing a means to rapidly develop and implement flight systems, and providing unprecedented insight into vehicle health, maintenance, and performance. Despite these benefits, there is still a relatively high level of cost and complexity associated with flight testing wireless systems.

Flight Test↗
NASA NTRS1992

Modifications to Langley 0.3-m TCT adaptive wall software for heavy gas test medium, phase 1 studies

The scheme for two-dimensional wall adaptation with sulfur hexafluoride (SF6) as test gas in the NASA Langley Research Center 0.3-m Transonic Cryogenic Tunnel (0.3-m TCT) is presented. A unified version of the wall adaptation software has been developed to function in a dual gas operation mode (nitrogen or SF6). The feature of ideal gas calculations for nitrogen operation is retained. For SF6 operation, real gas properties have been computed using the departure function technique. Installation of the software on the 0.3-m TCT ModComp-A computer and preliminary validation with nitrogen operation were found to be satisfactory. Further validation and improvements to the software will be undertaken when the 0.3-m TCT is ready for operation with SF6 gas.

Murthy, A. V.↗
NASA NTRS2014

Developing Avionics Hardware and Software for Rocket Engine Testing

My summer was spent working as an intern at Kennedy Space Center in the Propulsion Avionics Branch of the NASA Engineering Directorate Avionics Division. The work that I was involved with was part of Rocket University's Project Neo, a small scale liquid rocket engine test bed. I began by learning about the layout of Neo in order to more fully understand what was required of me. I then developed software in LabView to gather and scale data from two flowmeters and integrated that code into the main control software. Next, I developed more LabView code to control an igniter circuit and integrated that into the main software, as well. Throughout the internship, I performed work that mechanics and technicians would do in order to maintain and assemble the engine.

liquid rocket↗
NASA NTRS1994

Implementing Software Safety in the NASA Environment

Until recently, NASA did not consider allowing computers total control of flight systems. Human operators, via hardware, have constituted the ultimate safety control. In an attempt to reduce costs, NASA has come to rely more and more heavily on computers and software to control space missions. (For example. software is now planned to control most of the operational functions of the International Space Station.) Thus the need for systematic software safety programs has become crucial for mission success. Concurrent engineering principles dictate that safety should be designed into software up front, not tested into the software after the fact. 'Cost of Quality' studies have statistics and metrics to prove the value of building quality and safety into the development cycle. Unfortunately, most software engineers are not familiar with designing for safety, and most safety engineers are not software experts. Software written to specifications which have not been safety analyzed is a major source of computer related accidents. Safer software is achieved step by step throughout the system and software life cycle. It is a process that includes requirements definition, hazard analyses, formal software inspections, safety analyses, testing, and maintenance. The greatest emphasis is placed on clearly and completely defining system and software requirements, including safety and reliability requirements. Unfortunately, development and review of requirements are the weakest link in the process. While some of the more academic methods, e.g. mathematical models, may help bring about safer software, this paper proposes the use of currently approved software methodologies, and sound software and assurance practices to show how, to a large degree, safety can be designed into software from the start. NASA's approach today is to first conduct a preliminary system hazard analysis (PHA) during the concept and planning phase of a project. This determines the overall hazard potential of the system to be built. Shortly thereafter, as the system requirements are being defined, the second iteration of hazard analyses takes place, the systems hazard analysis (SHA). During the systems requirements phase, decisions are made as to what functions of the system will be the responsibility of software. This is the most critical time to affect the safety of the software. From this point, software safety analyses as well as software engineering practices are the main focus for assuring safe software. While many of the steps proposed in this paper seem like just sound engineering practices, they are the best technical and most cost effective means to assure safe software within a safe system.

Wetherholt, Martha S.↗
DOE OSTI2019

Prototyping the BOPTEST Framework for Simulation-Based Testing of Advanced Control Strategies in Buildings

Advanced control strategies are becoming increasingly necessary in buildings in order to meet and balance requirements for energy efficiency, demand flexibility, and occupant comfort. Additional development and widespread adoption of emerging control strategies, however, ultimately require low implementation costs to reduce payback period and verified performance to gain control vendor, building owner, and operator trust. This is difficult in an already first-cost driven and risk-averse industry. Recent innovations in building simulation can significantly aid in meeting these requirements and spurring innovation at early stages of development by evaluating performance, comparing state-of-the-art to new strategies, providing installation experience, and testing controller implementations. This paper presents the development of a simulation framework consisting of test cases and software platform for the testing of advanced control strategies (BOPTEST - Building Optimization Performance Test). The objectives and requirements of the framework, components of a test case, and proposed software platform architecture are described, and the framework is demonstrated with a prototype implementation and example test case.

Blum, David↗
DOE OSTI2025

Package Testing Program Process for Validation and Verification of Software

The purpose of this document is to define the process for validation and verification (V&V) of software used to test the thermal data acquisition equipment in the Oak Ridge National Laboratory (ORNL) Package Testing Program (PTP) as part of the testing configuration(s). This process adheres to all applicable ORNL Standards Based Management System requirements and correlates with the PTP Quality Management System and the Software Quality Assurance Plan.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2014

RELAP-7 Software Verification and Validation Plan

This INL plan comprehensively describes the software for RELAP-7 and documents the software, interface, and software design requirements for the application. The plan also describes the testing-based software verification and validation (SV&V) process—a set of specially designed software models used to test RELAP-7. The RELAP-7 (Reactor Excursion and Leak Analysis Program) code is a nuclear reactor system safety analysis code being developed at Idaho National Laboratory (INL). The code is based on the INL’s modern scientific software development framework – MOOSE (Multi-Physics Object-Oriented Simulation Environment). The overall design goal of RELAP-7 is to take advantage of the previous thirty years of advancements in computer architecture, software design, numerical integration methods, and physical models. The end result will be a reactor systems analysis capability that retains and improves upon RELAP5’s capability and extends the analysis capability for all reactor system simulation scenarios.

97 MATHEMATICS AND COMPUTING↗