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.

SourceResearch connectionFrom yearThrough year

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

At least 109 records · Page 6

All sources NASA NTRS DOE OSTI

NASA NTRS2012

Autonomous Cryogenics Loading Operations Simulation Software: Knowledgebase Autonomous Test Engineer

The Simulation Software, KATE (Knowledgebase Autonomous Test Engineer), is used to demonstrate the automatic identification of faults in a system. The ACLO (Autonomous Cryogenics Loading Operation) project uses KATE to monitor and find faults in the loading of the cryogenics int o a vehicle fuel tank. The KATE software interfaces with the IHM (Integrated Health Management) systems bus to communicate with other systems that are part of ACLO. One system that KATE uses the IHM bus to communicate with is AIS (Advanced Inspection System). KATE will send messages to AIS when there is a detected anomaly. These messages include visual inspection of specific valves, pressure gauges and control messages to have AIS open or close manual valves. My goals include implementing the connection to the IHM bus within KATE and for the AIS project. I will also be working on implementing changes to KATE's Ul and implementing the physics objects in KATE that will model portions of the cryogenics loading operation.

Wehner, Walter S.↗

NASA NTRS1997

Pre-Flight Dark Forward Electrical Testing of the Mir Cooperative Solar Array

The Mir Cooperative Solar Array (MCSA) was developed jointly by the United States (US) and Russia to provide approximately 6 kW of photovoltaic power to the Russian space station Mir. After final assembly in Russia, the MCSA was shipped to the NASA Kennedy Space Center (KSC) in the summer of 1995 and launched to Mir in November 1995. Program managers were concerned of the potential for MCSA damage during the transatlantic shipment and the associated handling operations. To address this concern, NASA Lewis Research Center (LERC) developed an innovative dark-forward electrical test program to assess the gross electrical condition of each generator following shipment from Russia. The use of dark test techniques, which allow the array to remain in the stowed configuration, greatly simplifies the checkout of large area solar arrays. MCSA dark electrical testing was successfully performed at KSC in July 1995 following transatlantic shipment. Data from this testing enabled engineers to quantify the effects of potential MCSA physical damage that would degrade on-orbit electrical performance. In this paper, an overview of the principles and heritage of photovoltaic array dark testing is given. The specific MCSA dark test program is also described including the hardware, software, testing procedures and test results. The current-voltage (4) response of both solar cell circuitry and by-pass diode circuitry was obtained. To guide the development of dark test hardware, software and procedures, a dedicated FORTRAN computer code was developed to predict the dark 4 responses of generators with a variety of feasible damage modes. By comparing the actual test data with the predictions, the physical condition of the generator could be inferred. Based on this data analysis, no electrical short-circuits or open-circuits were detected. This suggested the MCSA did not sustain physical damage that affected electrical performance during handling and shipment from Russia to the US. Good agreement between the test data and computational predictions indicated MCSA electrical performance was amenable to accurate analysis and was well understood.

Kerslake, Thomas W.↗

NASA NTRS2017

Upgrades to Common Data Acquisition System Software Development for NASA's Rocket Propulsion Test Facilities and Software Reuse

Approximately five years ago, the National Aeronautics and Space Administration (NASA) Stennis Space Center (SSC) resumed operation of its large rocket engine test facilities after thirty years of contractor control. During this period, contactors used their own proprietary Data Acquisition System (DAS) to record and process rocket propulsion test data. The transition from a contractor managed facility to a NASA managed facility posed a difficult challenge. In order to support the commercial space launch initiative, SSC needed to develop a software replacement for the contractor proprietary DAS. This replacement software would enable SSC to operate propulsion test facilities more cost effectively and to be more readily able to adapt software for reuse, while at the same time provide internal and external customers with reliable population test data. Therefore, SSC developed in-house, a non-proprietary software suite of applications to replace the previously used proprietary DAS. The requirements for the DAS suite included recording and processing propulsion test data. This capability eliminates the necessity for customers to provide a DAS or rely on a competitor's DAS. An additional benefit of owning the software suite included enabling the ability to add additional features and functionality at a lower cost. The Rocket Propulsion Test (RPT) Program Office reviewed consideration for funding this project with the caveat that development of the software included availability for use with minimal modifications to all SSC test facilities and RPT centers: Marshall Space Flight Center (MSFC), White Sands Test Facility (WSTF), and Glenn Research Center (GRC) Plum Brook Station. Based upon this guideline, SSC created the NASA Data Acquisition System (NDAS) software suite. The ability to use the software at multiple centers, even though each field center uses differing DAS hardware with different capabilities, drove a requirement that the software design be portable with minimal modifications to the software. Then, with software release requirements, evaluations, and approvals completed, the NDAS software suite could also become available to other government agencies, corporations, universities, and the general United States public.

Herbert, Phillip W., Sr.↗

NASA NTRS1985

Software verification and testing

General procedures for software verification and validation are provided as a guide for managers, programmers, and analysts involved in software development. The verification and validation procedures described are based primarily on testing techniques. Testing refers to the execution of all or part of a software system for the purpose of detecting errors. Planning, execution, and analysis of tests are outlined in this document. Code reading and static analysis techniques for software verification are also described.

Source record↗

NASA NTRS1975

Project space shuttle. Data bus evaluation laboratory test report

A Data Bus Evaluation Laboratory (DBEL) facility has been established to test and evaluate space shuttle data bus hardware. Performance testing conducted on an in-house developed multiplex interface adapter for the purpose of evaluating DBEL test procedures, test hardware, and test software in a realistic test environment is described. Results are presented.

Dennis, G. R.↗

NASA NTRS1983

Proceedings of the Eighth Annual Software Engineering Workshop

The four major topics of discussion included: the NASA Software Engineering Laboratory, software testing, human factors in software engineering and software quality assessment. As in the past years, there were 12 position papers presented (3 for each topic) followed by questions and very heavy participation by the general audience.

Source record↗

NASA NTRS1990

Markov Chains For Testing Redundant Software

Preliminary design developed for validation experiment that addresses problems unique to assuring extremely high quality of multiple-version programs in process-control software. Approach takes into account inertia of controlled system in sense it takes more than one failure of control program to cause controlled system to fail. Verification procedure consists of two steps: experimentation (numerical simulation) and computation, with Markov model for each step.

White, Allan L.↗

NASA NTRS2015

A Description of the Development, Capabilities, and Operational Status of the Test SLATE Data Acquisition System at the National Transonic Facility

The paper will present a brief background of the previous data acquisition system at the National Transonic Facility (NTF) and the reasoning and goals behind the upgrade to the current Test SLATE (Test Software Laboratory and Automated Testing Environments) data acquisition system. The components, performance characteristics, and layout of the Test SLATE system within the NTF control room will be discussed. The development, testing, and integration of Test SLATE within NTF operations will be detailed. The operational capabilities of the system will be outlined including: test setup, instrumentation calibration, automatic test sequencer setup, data recording, communication between data and facility control systems, real time display monitoring, and data reduction. The current operational status of the Test SLATE system and its performance during recent NTF testing will be highlighted including high-speed, frame-by-frame data acquisition with conditional sampling post-processing applied. The paper concludes with current development work on the system including the capability for real-time conditional sampling during data acquisition and further efficiency enhancements to the wind tunnel testing process.

Cramer, Christopher J.↗

NASA NTRSDate not supplied

Remotely Administered Psychoacoustic Test for sUAS Noise to Gauge Feasibility of Remote UAM Noise Study

The National Aeronautics and Space Administration (NASA) remotely administered a psychoacoustic test in fall of 2022 as the first of two phases of a cooperative Urban Air Mobility (UAM) vehicle noise human response study. The first phase, the Feasibility Test, described in this paper, determined the feasibility of the remote test method, in contrast to a previous in-person psychoacoustic test that found an annoyance response difference between small unmanned aerial system (sUAS) noise and ground vehicle noise. This paper discusses the Feasibility Test online layout, sound calibration method, remote test software development, stimuli selection, test subject recruitment, and test administration. Test performance is measured through comparison of annoyance response data with the previous in-person test results. The paper also investigates if providing a contextual cue to test subjects influenced their annoyance response. Response differences between test subjects in geographically distinct areas are analyzed. Administrative challenges that were encountered during the test are discussed. The second phase of this study, the implementation phase, will use a remote (web-based) test method and leverage the cooperation of multiple government agencies, academia, and industry to gain human response insights from a wide range of UAM vehicle sounds that would be challenging for a single organization to acquire. Improvements to administering a remote test for the implementation phase of the UAM vehicle noise human response study are recommended.

Remote Psychoacoustic Test↗

NASA NTRSDate not supplied

Remotely Administered Psychoacoustic Test for sUAS Noise to Gauge Feasibility of Remote UAM Noise Study

Remote Psychoacoustic Test↗

NASA NTRS1980

Online assessment of a distributed processor

ORT (Operational Readiness Test) software allows one engineer to test readiness of 64 minicomputers and their peripherals from single console. Software makes roll call of computers and peripherals via common data buffer to check readiness of system in morning "wake up" or at other important times. Subsystems are tested in parallel to save time. "Watchdog" terminates test of any system that does not respond in time, so one failed system does not halt test sequence. Entire rollcall is complete in about 15 minutes. Software is designed for Space Shuttle prelaunch checkout, but approach should interest users of similar equipment.

Ehrlich, L. F.↗

NASA NTRS2003

Experiments with Test Case Generation and Runtime Analysis

Software testing is typically an ad hoc process where human testers manually write many test inputs and expected test results, perhaps automating their execution in a regression suite. This process is cumbersome and costly. This paper reports preliminary results on an approach to further automate this process. The approach consists of combining automated test case generation based on systematically exploring the program's input domain, with runtime analysis, where execution traces are monitored and verified against temporal logic specifications, or analyzed using advanced algorithms for detecting concurrency errors such as data races and deadlocks. The approach suggests to generate specifications dynamically per input instance rather than statically once-and-for-all. The paper describes experiments with variants of this approach in the context of two examples, a planetary rover controller and a space craft fault protection system.

Artho, Cyrille↗

NASA NTRS1981

A high order approach to flight software development and testing

The use of a software development facility is discussed as a means of producing a reliable and maintainable ECS software system, and as a means of providing efficient use of the ECS hardware test facility. Principles applied to software design are given, including modularity, abstraction, hiding, and uniformity. The general objectives of each phase of the software life cycle are also given, including testing, maintenance, code development, and requirement specifications. Software development facility tools are summarized, and tool deficiencies recognized in the code development and testing phases are considered. Due to limited lab resources, the functional simulation capabilities may be indispensable in the testing phase.

Steinbacher, J.↗

NASA NTRS1992

Providing an empirical basis for optimizing the verification and testing phases of software development

Applying equal testing and verification effort to all parts of a software system is not very efficient, especially when resources are limited and scheduling is tight. Therefore, one needs to be able to differentiate low/high fault density components so that the testing/verification effort can be concentrated where needed. Such a strategy is expected to detect more faults and thus improve the resulting reliability of the overall system. This paper presents an alternative approach for constructing such models that is intended to fulfill specific software engineering needs (i.e. dealing with partial/incomplete information and creating models that are easy to interpret). Our approach to classification is as follows: (1) to measure the software system to be considered; and (2) to build multivariate stochastic models for prediction. We present experimental results obtained by classifying FORTRAN components developed at the NASA/GSFC into two fault density classes: low and high. Also we evaluate the accuracy of the model and the insights it provides into the software process.

Briand, Lionel C.↗

NASA NTRS1978

X-ray enhancement software development and test

A repertoire of software to optimally analyze various X-ray imagery was successfully developed. Computer techniques are presented to solve many common problems involved in nondestructive testing X-ray analysis.

Butterfield, R. L.↗

NASA NTRS1979

To the first Shuttle launch

The major Shuttle-related testing currently in progress includes: static testing of all major elements, full scale ground vibration testing, main propulsion system testing, software verification and validation, qualification testing of many components and subsystems, and SSME verification testing. This paper reviews the current status of the Shuttle program and gives attention to the transition to operations, near-term traffic plans, user-charge policies, and payload integration. It is concluded that the transition from individual space-research projects to a fully integrated Space Transportation System, providing low-cost routine access to space for many users, involves a complete rethinking of the role NASA and the user will play.

Yardley, J. F.↗

NASA NTRS1994

Program Helps Design Tests Of Developmental Software

Computer program called "A Formal Test Representation Language and Tool for Functional Test Designs" (TRL) provides automatic software tool and formal language used to implement category-partition method and produce specification of test cases in testing phase of development of software. Category-partition method useful in defining input, outputs, and purpose of test-design phase of development and combines benefits of choosing normal cases having error-exposing properties. Traceability maintained quite easily by creating test design for each objective in test plan. Effort to transform test cases into procedures simplified by use of automatic software tool to create cases based on test design. Method enables rapid elimination of undesired test cases from consideration and facilitates review of test designs by peer groups. Written in C language.

Hops, Jonathan↗

NASA NTRS1985

A methodology for testing fault-tolerant software

A methodology for testing fault tolerant software is presented. There are problems associated with testing fault tolerant software because many errors are masked or corrected by voters, limiter, or automatic channel synchronization. This methodology illustrates how the same strategies used for testing fault tolerant hardware can be applied to testing fault tolerant software. For example, one strategy used in testing fault tolerant hardware is to disable the redundancy during testing. A similar testing strategy is proposed for software, namely, to move the major emphasis on testing earlier in the development cycle (before the redundancy is in place) thus reducing the possibility that undetected errors will be masked when limiters and voters are added.

Andrews, D. M.↗