Search NASA⌕ Search

SEARCH · Search NASA

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 289 records · Page 16
All sourcesNASA NTRSDOE OSTI
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 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 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↗
NASA NTRS2014

LADEE Multi-Domain Simulation

The Lunar Atmosphere Dust Environment Explorer (LADEE) was a small explorer class spacecraft that was launched on Sept 7, 2013 and that was de-orbited and successfully impacted the Moons surface on April 17, 2014 after completing all of the mission objectives. The low-cost rapidly prototyped hardware design used for the spacecraft was extend to the development of the software base. To achieve this goal, a Model Based Design approach was utilized to develop the onboard flight software, and out of this development a model based multipurpose simulator was created of the LADEE spacecraft and its mission environment. This simulator extended the traditional function of propagating the vehicle's kinematic and rotational states and included the electrical and thermal states propagation. Traditionally, these domains are handled by domain specific high fidelity simulations that use the states histories from other domains as input. By reducing the fidelity and abstracting the relevant features being monitored and controlled by the flight software, it was possible to model the coupling across these domains resulting in more accurate overall system behavior. A faster than real-time workstation (WSIM) version of the LADEE simulator was used to develop and test the software control algorithms in the Simulink environment. To maximize the performance of the simulation, modeling knobs were introduced to reduce the resolution of the some of the domains models when the effects of that domain were not significant for the scope of that simulation. The automatic code generation feature in Simulink was used to port the simulation to several real-time environments to support Processor-in-the-Loop (PIL) and Hardware-in-the-Loop (HIL) testing, verification and validation. The real-time environment required that the design of each of the domain models be deterministic as possible in the time required to perform all of the calculations to update its states. The simulation interface was designed to be compatible with the command interface employed by the LADEE mission operation team. The WSIM, PIL, and HIL simulators thus used a common interface and thus were used for flight software testing, for mission operations personnel training (nominal and off-nominal operations) prior to the mission and to perform command sequence verification during the mission. This presentation will look at the modeling strategies used to create a common interface to the simulator and to model and couple multiple domains within the simulation, the results of those strategies, and the lessons learned.

Multi-Domain↗
NASA NTRS1986

Ultraviolet spectrometer and polarimeter (UVSP) software development and hardware tests for the solar maximum mission

The Ultraviolet Spectrometer/Polarimeter Instrument (UVSP) for the Solar Maximum Mission (SMM) was based on the re-use of the engineering model of the high resolution ultraviolet spectrometer developed for the OSO-8 mission. Lockheed assumed four distinct responsibilities in the UVSP program: technical evaluation of the OSO-8 engineering model; technical consulting on the electronic, optical, and mechanical modifications to the OSO-8 engineering model hardware; design and development of the UVSP software system; and scientific participation in the operations and analysis phase of the mission. Lockheed also provided technical consulting and assistance with instrument hardware performance anomalies encountered during the post launch operation of the SMM observatory. An index to the quarterly reports delivered under the contract are contained, and serves as a useful capsule history of the program activity.

Bruner, M. E.↗
NASA NTRS1989

Strain energy release rate as a function of temperature and preloading history utilizing the edge delamination fatique test method

Static laminate and tension-tension fatigue tests of IM7/8551-7 composite materials was performed. The Edge Delamination Test (EDT) was utilized to evaluate the temperature and preloading history effect on the critical strain energy release rate. Static and fatigue testing was performed at room temperature and 180 F (82 C). Three preloading schemes were used to precondition fatigue test specimens prior to performing the normal tension-tension fatigue EDT testing. Computer software was written to perform all fatigue testing while monitoring the dynamic modulus to detect the onset of delamination and record the test information for later retrieval and reduction.

Zimmerman, Richard S.↗
NASA NTRS2012

Nemesis Autonomous Test System

A generalized framework has been developed for systems validation that can be applied to both traditional and autonomous systems. The framework consists of an automated test case generation and execution system called Nemesis that rapidly and thoroughly identifies flaws or vulnerabilities within a system. By applying genetic optimization and goal-seeking algorithms on the test equipment side, a "war game" is conducted between a system and its complementary nemesis. The end result of the war games is a collection of scenarios that reveals any undesirable behaviors of the system under test. The software provides a reusable framework to evolve test scenarios using genetic algorithms using an operation model of the system under test. It can automatically generate and execute test cases that reveal flaws in behaviorally complex systems. Genetic algorithms focus the exploration of tests on the set of test cases that most effectively reveals the flaws and vulnerabilities of the system under test. It leverages advances in state- and model-based engineering, which are essential in defining the behavior of autonomous systems. It also uses goal networks to describe test scenarios.

Barltrop, Kevin J.↗
NASA NTRS2013

Direct-to-Earth Communications with Mars Science Laboratory During Entry, Descent, and Landing

Mars Science Laboratory (MSL) undergoes extreme heating and acceleration during Entry, Descent, and Landing (EDL) on Mars. Unknown dynamics lead to large Doppler shifts, making communication challenging. During EDL, a special form of Multiple Frequency Shift Keying (MFSK) communication is used for Direct-To-Earth (DTE) communication. The X-band signal is received by the Deep Space Network (DSN) at the Canberra Deep Space Communication complex, then down-converted, digitized, and recorded by open-loop Radio Science Receivers (RSR), and decoded in real-time by the EDL Data Analysis (EDA) System. The EDA uses lock states with configurable Fast Fourier Transforms to acquire and track the signal. RSR configuration and channel allocation is shown. Testing prior to EDL is discussed including software simulations, test bed runs with MSL flight hardware, and the in-flight end-to-end test. EDA configuration parameters and signal dynamics during pre-entry, entry, and parachute deployment are analyzed. RSR and EDA performance during MSL EDL is evaluated, including performance using a single 70-meter DSN antenna and an array of two 34-meter DSN antennas as a back up to the 70-meter antenna.

Direct-to-Earth (DTE)↗
NASA NTRS1988

Simulation test beds for the space station electrical power system

NASA Lewis Research Center and its prime contractor are responsible for developing the electrical power system on the space station. The power system will be controlled by a network of distributed processors. Control software will be verified, validated, and tested in hardware and software test beds. Current plans for the software test bed involve using real time and nonreal time simulations of the power system. This paper will discuss the general simulation objectives and configurations, control architecture, interfaces between simulator and controls, types of tests, and facility configurations.

Sadler, Gerald G.↗
NASA NTRS1988

Simulation test beds for the Space Station electrical power system

NASA Lewis Research Center and its prime contractor are respnsible for developing the electrical power system on the Space Station. The power system will be controlled by a network of distributed processors. Control software will be verified, validated, and tested in hardware and software test beds. Current plans for the software test bed involve using real time and nonreal time simulations of the power system. This paper will discuss the general simulation objectives and configurations, control architecture, interfaces between simulator and controls, types of tests, and facility configurations.

Sadler, Gerald G.↗