Search NASA⌕ Search

SEARCH · Search NASA

Results for “Automated 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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2011

Payload and Components Real-Time Automated Test System (PACRATS), Data Acquisition of Leak Rate and Pressure Data Test Procedure

The purpose of this activity is to provide the Mechanical Components Test Facility (MCTF) with the capability to obtain electronic leak test and proof pressure data, Payload and Components Real-time Automated Test System (PACRATS) data acquisition software will be utilized to display real-time data. It will record leak rates and pressure/vacuum level(s) simultaneously. This added functionality will provide electronic leak test and pressure data at specified sampling frequencies. Electronically stored data will provide ES61 with increased data security, analysis, and accuracy. The tasks performed in this procedure are to verify PACRATS only, and are not intended to provide verifications for MCTF equipment.

Rinehart, Maegan L.↗
NASA NTRS2004

Software for Automated Testing of Mission-Control Displays

MCC Display Cert Tool is a set of software tools for automated testing of computerterminal displays in spacecraft mission-control centers, including those of the space shuttle and the International Space Station. This software makes it possible to perform tests that are more thorough, take less time, and are less likely to lead to erroneous results, relative to tests performed manually. This software enables comparison of two sets of displays to report command and telemetry differences, generates test scripts for verifying telemetry and commands, and generates a documentary record containing display information, including version and corrective-maintenance data. At the time of reporting the information for this article, work was continuing to add a capability for validation of display parameters against a reconfiguration file.

OHagan, Brian↗
NASA NTRS2018

Automating Test Procedures Using Robot Software

This paper will discuss the project I was assigned during the 2018 Spring semester NIFS internship, what the project does for NASA, and what I contributed to the project. It will begin with a broad analysis of the types of software I worked on and how they were used to complete the project. Then, it will narrow in scope to concentrate on the group and parts of NASA assigned the project. Next, it will pay attention to the project itself and how it worked. After that, it will focus on my direct contributions to the project. Lastly, a few personal experiences I encountered to make my internship relatable. The initial points discussed will be an introduction to the basics of automated testing and the types of software used. Next, I will briefly discuss why these tools were chosen and whether or not they can be improved. Then, a look at where my group fits into the hierarchy of NASA, what the group working on my project did for NASA, and who were the entities working together for this project. Afterwards, a review of my involvement in the program, my development as an individual, and my new skills and abilities. Finally, a sense of involvement with the community through personal development will be demonstrated using unique experiences only available to me through this internship..

SikuliX↗
NASA NTRS1985

Automated testing of developmental satellite communications systems and subsystems

Lower frequency bands allocated for satellite communications use are becoming saturated due to steadily increasing demand. An ongoing program to develop the new technologies required to meet the demands of future systems is described. Higher frequency components and more efficient system techniques are developed. In order to accurately evaluate the performance of these technologies, an automated test system was designed and built. The automated system's design an capabilities are discussed.

Shalkhauser, K. A.↗
NASA NTRS2020

Command and Control System Automated Testing

To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket and the Orion capsule, designed to take humans back to the moon in 2024, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the launch. Within SCCS, the Launch Control System (LCS) is designed to allow console engineers to control and monitor the status of the launch and flight hardware, as well as issue commands to ground control systems and launch vehicles. The messaging software of LCS is responsible for handling the various data types that can be sent between the hardware and software components of the LCS. Since this system is interacting with numerous devices, controllers, and viewports in real time, the distribution of data across the system must be fast, but also reliable and accurate. To verify the accuracy and reliability of the system, developers on the project have created a set of tests to be performed that covers all operations allowed by the system. Given the extensive Application Programming Interface(API) provided by the messaging software, these unit tests are rather time-consuming and costly (in terms of man-hours) to perform. Therefore, an automated testing framework is used to perform supplemental tests automatically when updates are made to the code base.

Rebecca McFadden↗
NASA NTRS1972

Automated testing data reduction computer program.

The capability of a computer program which can be part of a larger computer program for a fully automated multiaxial testing facility is described. This computer program is designed to process test data from tubular or flat specimens made from isotropic or anisotropic materials including high modulus fiber composites. The program can receive data from a large number of strain gages and combinations of applied loads. Options are provided for single element, 90-degree, rectangular or Delta rosettes, or any combinations of these types of strain gages. Options are provided for strain gage transverse sensitivities. The program outputs include: structural axes strains and stresses, initial and strain dependent elastic constants, shift of principal strain direction with load, and local curvatures from back-to-back strain gages, and either calcomp or microfilm plots. The computer program is described with respect to its flow chart, input/output, embedment or linking with other programs and its possible utility in a fully automated testing system.

Chamis, C. C.↗
NASA NTRS1999

Automated Testing Experience of the Linear Aerospike SR-71 Experiment (LASRE) Controller

System controllers must be fail-safe, low cost, flexible to software changes, able to output health and status words, and permit rapid retest qualification. The system controller designed and tested for the aerospike engine program was an attempt to meet these requirements. This paper describes (1) the aerospike controller design, (2) the automated simulation testing techniques, and (3) the real time monitoring data visualization structure. Controller cost was minimized by design of a single-string system that used an off-the-shelf 486 central processing unit (CPU). A linked-list architecture, with states (nodes) defined in a user-friendly state table, accomplished software changes to the controller. Proven to be fail-safe, this system reported the abort cause and automatically reverted to a safe condition for any first failure. A real time simulation and test system automated the software checkout and retest requirements. A program requirement to decode all abort causes in real time during all ground and flight tests assured the safety of flight decisions and the proper execution of mission rules. The design also included health and status words, and provided a real time analysis interpretation for all health and status data.

Larson, Richard R.↗
NASA NTRS1997

Automated Test Systems for Toxic Vapor Detectors

The NASA Toxic Vapor Detection Laboratory (TVDL) at the Kennedy Space Center (KSC), Florida, has been using Personal Computer based Data Acquisition and Control Systems (PCDAS) for about nine years. These systems control the generation of toxic vapors of known concentrations under controlled conditions of temperature and humidity. The PCDAS also logs the test conditions and the test article responses in data files for analysis by standard spreadsheets or custom programs. The PCDAS was originally developed to perform standardized qualification and acceptance tests in a search for a commercial off-the-shelf (COTS) toxic vapor detector to replace the hydrazine detectors for the Space Shuttle launch pad. It has since become standard test equipment for the TVDL and is indispensable in producing calibration standards for the new hydrazine monitors at the 10 part per billion (ppb) level. The standard TVDL PCDAS can control two toxic vapor generators (TVG's) with three channels each and two flow/temperature/humidity (FIFH) controllers and it can record data from up to six toxic vapor detectors (TVD's) under test and can deliver flows from 5 to 50 liters per minute (L/m) at temperatures from near zero to 50 degrees Celsius (C) using an environmental chamber to maintain the sample temperature. The concentration range for toxic vapors depends on the permeation source installed in the TVG. The PCDAS can provide closed loop control of temperature and humidity to two sample vessels, typically one for zero gas and one for the standard gas. This is required at very low toxic vapor concentrations to minimize the time required to passivate the sample delivery system. Recently, there have been several requests for information about the PCDAS by other laboratories with similar needs, both on and off KSC. The purpose of this paper is to inform the toxic vapor detection community of the current status and planned upgrades to the automated testing of toxic vapor detectors at the Kennedy Space Center.

Mattson, C. B.↗
NASA NTRS1997

Automated Test Systems for Toxic Vapor Detectors

The NASA Toxic Vapor Detection Laboratory (TVDL) at the Kennedy Space Center (KSC), Florida, has been using Personal Computer based Data Acquisition and Control Systems (PCDAS) for about nine years. These systems control the generation of toxic vapors of known concentrations under controlled conditions of temperature and humidity. The PCDAS also logs the test conditions and the test article responses in data files for analysis by standard spreadsheets or custom programs. The PCDAS was originally developed to perform standardized qualification and acceptance tests in a search for a commercial off-the-shelf (COTS) toxic vapor detector to replace the hydrazine detectors for the Space Shuttle launch pad. It has since become standard test equipment for the TVDL and is indispensable in producing calibration standards for the new hydrazine monitors at the 10 part per billion (ppb) level. The standard TVDL PCDAS can control two toxic vapor generators (TVG's) with three channels each and two flow/ temperature / humidity (FTH) controllers and it can record data from up to six toxic vapor detectors (TVD's) under test and can deliver flows from 5 to 50 liters per minute (L/m) at temperatures from near zero to 50 degrees Celsius (C) using an environmental chamber to maintain the sample temperature. The concentration range for toxic vapors depends on the permeation source installed in the TVG. The PCDAS can provide closed loop control of temperature and humidity to two sample vessels, typically one for zero gas and one for the standard gas. This is required at very low toxic vapor concentrations to minimize the time required to passivate the sample delivery system. Recently, there have been several requests for information about the PCDAS by other laboratories with similar needs, both on and off KSC. The purpose of this paper is to inform the toxic vapor detection community of the current status and planned upgrades to the automated testing of toxic vapor detectors at the Kennedy Space Center.

Mattson, C. B.↗
NASA NTRS2019

Writing a New Automated Testing Method for Custom Display Components

During the launch process of the Space Launch System (SLS), engineers in the Firing Room of the Launch Control Center (LCC) will be analyzing displays that show data and statistics about the vehicle and launch. These displays are subject to a battery of tests, but the custom components they use are not currently supported by any testing framework. My project is to modify a testing framework so that the custom components on these displays can be tested similarly to how a user would interact with them.

Automated Testing↗
NASA NTRS1972

Automated testing data reduction computer program

The capability of a computer program which can be part of a larger computer program for a fully automated multiaxial testing facility is described. The program was designed to process test data from tubular or flat specimens made from isotropic or anistropic materials, including high modulus fiber composites. Data from a large number of strain gages and combinations of applied loads can be used. Options are provided for single element, 90-degree, rectangular or Delta rosettes, or any combinations of these types of strain gages. Options are provided for strain gage transverse sensitivities. The program outputs include: structural axes strains and stresses, initial and strain-dependent elastic constants, shift of principal strain direction with load, and local curvatures from back-to-back strain gages, and either Calcomp or microfilm plots. The computer program is described with respect to its flow chart, input/output, embedding or linking with other programs.

Chamis, C. C.↗
NASA NTRS1994

Automated Test Environment for a Real-Time Control System

An automated environment with hardware-in-the-loop has been developed by Rocketdyne Huntsville for test of a real-time control system. The target system of application is the man-rated real-time system which controls the Space Shuttle Main Engines (SSME). The primary use of the environment is software verification and validation, but it is also useful for evaluation and analysis of SSME avionics hardware and mathematical engine models. It provides a test bed for the integration of software and hardware. The principles and skills upon which it operates may be applied to other target systems, such as those requiring hardware-in-the-loop simulation and control system development. Potential applications are in problem domains demanding highly reliable software systems requiring testing to formal requirements and verifying successful transition to/from off-nominal system states.

Hall, Ronald O.↗
NASA NTRS2011

Automated Test Case Generation for an Autopilot Requirement Prototype

Designing safety-critical automation with robust human interaction is a difficult task that is susceptible to a number of known Human-Automation Interaction (HAI) vulnerabilities. It is therefore essential to develop automated tools that provide support both in the design and rapid evaluation of such automation. The Automation Design and Evaluation Prototyping Toolset (ADEPT) enables the rapid development of an executable specification for automation behavior and user interaction. ADEPT supports a number of analysis capabilities, thus enabling the detection of HAI vulnerabilities early in the design process, when modifications are less costly. In this paper, we advocate the introduction of a new capability to model-based prototyping tools such as ADEPT. The new capability is based on symbolic execution that allows us to automatically generate quality test suites based on the system design. Symbolic execution is used to generate both user input and test oracles user input drives the testing of the system implementation, and test oracles ensure that the system behaves as designed. We present early results in the context of a component in the Autopilot system modeled in ADEPT, and discuss the challenges of test case generation in the HAI domain.

Giannakopoulou, Dimitra↗
NASA NTRS1987

Development of a facility using robotics for testing automation of inertial instruments

The Integrated Robotics System Simulation (ROBSIM) was used to evaluate the performance of the PUMA 560 arm as applied to testing of inertial sensors. Results of this effort were used in the design and development of a feasibility test environment using a PUMA 560 arm. The implemented facility demonstrated the ability to perform conventional static inertial instrument tests (rotation and tumble). The facility included an efficient data acquisitions capability along with a precision test servomechanism function resulting in various data presentations which are included in the paper. Analysis of inertial instrument testing accuracy, repeatability and noise characteristics are provided for the PUMA 560 as well as for other possible commercial arm configurations. Another integral aspect of the effort was an in-depth economic analysis and comparison of robot arm testing versus use of contemporary precision test equipment.

Greig, Joy Y.↗
NASA NTRS2006

Drilling Automation Tests At A Lunar/Mars Analog Site

Future in-situ lunar/martian resource utilization and characterization, as well as the scientific search for life on Mars, will require access to the subsurface and hence drilling. Drilling on Earth is hard - an art form more than an engineering discipline. The limited mass, energy and manpower in planetary drilling situations makes application of terrestrial drilling techniques problematic. The Drilling Automation for Mars Exploration (DAME) project is developing drilling automation and robotics for projected use in missions to the Moon and Mars in the 2011-15 period. This has been tested recently, drilling in permafrost at a lunar/martian analog site (Haughton Crater, Devon Island, Canada).

Glass, B.↗
NASA NTRS1993

Automating test case generation for coverages required by FAA standard DO-178B

Coverage testing techniques are required by the FAA for various levels of subsystem criticality at the unit testing level. Higher levels of criticality require coverage schemes that frequently require more and more test cases, particularly when the number of conditions in a decision grows. For example, if we have a decision with n conditions of the form: if (/ci/ or /c2/ or .... or /cn/) then there are 2(n) possible combinations of condition outcomes. Given the enormous number of inputs that may be required to satisfy different coverages, and given that there are no automated tools for determining these inputs (to our knowledge), we will show how one alternative testing technique, mutation testing, can be coerced into generating inputs that satisfy a code coverage scheme X, i.e., if we modify the rules for mutant generation during mutation testing, this technique will provide test cases that satisfy X.

Voas, Jeffrey M.↗
NASA NTRS1975

Development of automated test procedures and techniques for LSI circuits

Testing of large scale integrated (LSI) logic circuits was considered from the point of view of automatic test pattern generation. A system for automatic test pattern generation is described. A test generation algorithm is presented that can be applied to both combinational and sequential logic circuits. Also included is a programmed implementation of the algorithm and sample results from the program.

Carroll, B. D.↗