Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “System 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 541 records · Page 30
All sourcesNASA NTRSDOE OSTI
NASA NTRS1996

Windowing System For Test And Simulation

Windowing System for Test and Simulation (WFI) computer program is Turbo-Pascal-class library enabling easy and flexible writing of data to window-type displays. Application programmer's interface simple, small, and powerful, eliminating steep learning curve of other window programming systems. Each routine specifically designed to operate in real-time testing and measurement environments or as part of simulation process. Written in Turbo Pascal v6.0 for IBM PC-series and compatible computers running MS-DOS. Turbo Pascal v6.0 or v7.0 (Borland) required to compile source code.

Katz, R.↗
NASA NTRS2004

Positioning System Accuracy Assessment for the Runway Incursion Prevention System Flight Test at the Dallas/Ft. Worth International Airport

NASA/Langley Research Center collaborated with the Federal Aviation Administration (FAA) to test a Runway Incursion Prevention System (RIPS) at the Dallas Fort Worth International Airport (DFW) in October 2000. The RIPS combines airborne and ground sensor data with various cockpit displays to improve pilots' awareness of traffic conditions on the airport surface. The systems tested at DFW involved surface radar and data systems that gather and send surface traffic information to a research aircraft outfitted with the RIPS software, cockpit displays, and data link transceivers. The data sent to the airborne systems contained identification and GPS location of traffic. This information was compared with the own-ship location from airborne GPS receivers to generate incursion alerts. A total of 93 test tracks were flown while operating RIPS. This report compares the accuracy of the airborne GPS systems that gave the own-ship position of the research aircraft for the 93 test tracks.

Quach, Cuong C.↗
DOE OSTI2021

Molten salt environment creep testing extensometry system

Disclosed herein are systems, devices and methods for creep testing selected materials within a high-temperature molten salt environment. Exemplary creep testing systems include a load train for holding a test specimen under a load within a heated inert gas vessel. An extensometry system can be included to measure elongation of the test specimen while under load. The extensometry system can include fixed members and axially translating member that move along with the elongation of the test specimen, and the system can include a sensor to measure the relative axial motion between such components to measure elongation of the test specimen over time. The test specimen can include a cylindrical gage portion having an internal void filled with a molten salt during creep testing to simulate the corrosive effect of the molten salt on the specimen material during testing.

Ren, Wenlin↗
DOE OSTI2024

Two-terminator RF adapter for background/environment noise measurement

A two-terminator RF adapter for background noise measurement in a test environment comprises a system test port comprising a system test port termination and a system test port connector to connect to a system under test; and a data acquisition port, comprising a data acquisition port termination and a data acquisition port connector to connect to a data acquisition system.

Kolski, Jeffrey↗
NASA NTRS2016

Tethered Space Satellite-1 (TSS-1): Technical Roundabouts

In the early 1990's US and Italian scientists collaborated to study the electrodynamics of dragging a satellite on a tether through the electrically charged portion of Earth's atmosphere called the ionosphere. An electrical current induced in the long wire could be used for power and thrust generation for a satellite. Other tether uses include momentum exchange, artificial gravity, deployment of sensors or antennas, and gravity-gradient stabilization for satellites. Before the Tethered Space Satellite (TSS-1), no long tether had ever been flown, so many questions existed on how it would actually behave. The TSS consisted of a satellite with science experiments attached to a 12.5 mile long, very thin (0.10 inch diameter) copper wire assembly wound around a spool in the deployer reel mechanism. With the Space Shuttle at an altitude of 160 nautical miles above earth, the satellite was to be deployed by raising it from the Shuttle bay on a boom facing away from Earth. Once cleared of the bay, the deployer mechanism was to slowly feed out the 12-plus miles of tether. Scientific data would be collected throughout the operation, after which the satellite would be reeled back in. Pre-flight testing system level tests involved setting up a tether receiver to catch the 12.5 mile tether onto another reel as it was being unwound by the deployer reel mechanism. Testing only the reel mechanism is straightforward. This test becomes more complicated when the TSS is mounted on the flight pallet at Kennedy Space Center (KSC). The system level tests must be passed before the pallet can be installed into the Space Shuttle cargo bay. A few months before flight, the TSS payload had been integrated onto the Spacelab pallet and system level tests, including unreeling and reeling the tether, had been successfully completed. Some of this testing equipment was then shipped back to the contractor Martin Marietta. Systems-level load analyses, which cannot be run until all information about each payload is finalized, was run in parallel with the physical integration of the hardware into the Shuttle payload bay. The coupled loads analysis, as it is called, incorporates any updates to the model due to system level tests, and any changes that were found during integration. The coupled loads analysis revealed that a single bolt attaching the deployer reel mechanism to the support structure had a "negative margin" - which is an indication that it might fail during operation. Hardware certification rules do not allow for hardware to fly with negative margins, so this issue had to be resolved before the flight. Since there is conservatism in engineering analysis, there is an option to "waive" the margin requirement, and fly the experiment as is. On the other hand, a structural failure of one payload could have serious or catastrophic consequences to other payloads and possibly the mission. Minor design changes or fixes might be feasible within the payload bay prior to launch. Any major design changes that required the spooling test to validate the hardware, or for the pallet to be removed, would cause TSS not to be ready for the Shuttle launch.

O'Connor, Brian↗
NASA NTRS1985

Integrated Application of Active Controls (IAAC) technology to an advanced subsonic transport project: Test act system validation

The primary objective of the Test Active Control Technology (ACT) System laboratory tests was to verify and validate the system concept, hardware, and software. The initial lab tests were open loop hardware tests of the Test ACT System as designed and built. During the course of the testing, minor problems were uncovered and corrected. Major software tests were run. The initial software testing was also open loop. These tests examined pitch control laws, wing load alleviation, signal selection/fault detection (SSFD), and output management. The Test ACT System was modified to interface with the direct drive valve (DDV) modules. The initial testing identified problem areas with DDV nonlinearities, valve friction induced limit cycling, DDV control loop instability, and channel command mismatch. The other DDV issue investigated was the ability to detect and isolate failures. Some simple schemes for failure detection were tested but were not completely satisfactory. The Test ACT System architecture continues to appear promising for ACT/FBW applications in systems that must be immune to worst case generic digital faults, and be able to tolerate two sequential nongeneric faults with no reduction in performance. The challenge in such an implementation would be to keep the analog element sufficiently simple to achieve the necessary reliability.

Source record↗
NASA NTRS1989

HST battery test expert systems

During the testing of nickel-cadmium and nickel-hydrogen batteries for the Hubble Space Telescope, an urgent need for data management was recognized. Testing of these batteries generates much needed data that is used for vital decision making, such as when to recondition, change the charging scheme, or adjust the workload of the batteries. To solve this problem, an expert system called NICBES was developed. NICBES can recognize a testbed anomaly, identify the malfunctioning component, recommend a course of action, evaluate battery status, and provide decision support. A description of NICBES and some of its enhancements are given.

Johnson, Yvette B.↗
NASA NTRS1990

Flight control system design factors for applying automated testing techniques

The principal design features and operational experiences of the X-29 forward-swept-wing aircraft and F-18 high alpha research vehicle (HARV) automated test systems are discussed. It is noted that operational experiences in developing and using these automated testing techniques have highlighted the need for incorporating target system features to improve testability. Improved target system testability can be accomplished with the addition of nonreal-time and real-time features. Online access to target system implementation details, unobtrusive real-time access to internal user-selectable variables, and proper software instrumentation are all desirable features of the target system. Also, test system and target system design issues must be addressed during the early stages of the target system development. Processing speeds of up to 20 million instructions/s and the development of high-bandwidth reflective memory systems have improved the ability to integrate the target system and test system for the application of automated testing techniques. It is concluded that new methods of designing testability into the target systems are required.

Sitz, Joel R.↗
NASA NTRSDate not supplied

Wear Test of the 12.5-kW Advanced Electric Propulsion System Engineering Test Unit Hall Thruster

This work presents a summary of the first wear test of the 12.5 kW Advanced Electric Propulsion System Engineering Test Unit 2 (AEPS ETU-2) thruster produced by Aerojet Rocketdyne. The ETU-2 Wear Test accumulated approximately 730 hours of operation split between the nominal 600 V/12.5 kW condition and the 300 V/6.25 kW condition previously identified as the worst-case erosion condition.

Jason D. Frieman↗
NASA NTRS2017

Launch Control System Software Development System Automation Testing

The Spaceport Command and Control System (SCCS) is the National Aeronautics and Space Administration's (NASA) launch control system for the Orion capsule and Space Launch System, the next generation manned rocket currently in development. This system requires high quality testing that will measure and test the capabilities of the system. For the past two years, the Exploration and Operations Division at Kennedy Space Center (KSC) has assigned a group including interns and full-time engineers to develop automated tests to save the project time and money. The team worked on automating the testing process for the SCCS GUI that would use streamed simulated data from the testing servers to produce data, plots, statuses, etc. to the GUI. The software used to develop automated tests included an automated testing framework and an automation library. The automated testing framework has a tabular-style syntax, which means the functionality of a line of code must have the appropriate number of tabs for the line to function as intended. The header section contains either paths to custom resources or the names of libraries being used. The automation library contains functionality to automate anything that appears on a desired screen with the use of image recognition software to detect and control GUI components. The data section contains any data values strictly created for the current testing file. The body section holds the tests that are being run. The function section can include any number of functions that may be used by the current testing file or any other file that resources it. The resources and body section are required for all test files; the data and function sections can be left empty if the data values and functions being used are from a resourced library or another file. To help equip the automation team with better tools, the Project Lead of the Automated Testing Team, Jason Kapusta, assigned the task to install and train an optical character recognition (OCR) tool to Brandon Echols, a fellow intern, and I. The purpose of the OCR tool is to analyze an image and find the coordinates of any group of text. Some issues that arose while installing the OCR tool included the absence of certain libraries needed to train the tool and an outdated software version. We eventually resolved the issues and successfully installed the OCR tool. Training the tool required many images and different fonts and sizes, but in the end the tool learned to accurately decipher the text in the images and their coordinates. The OCR tool produced a file that contained significant metadata for each section of text, but only the text and coordinates of the text was required for our purpose. The team made a script to parse the information we wanted from the OCR file to a different file that would be used by automation functions within the automated framework. Since a majority of development and testing for the automated test cases for the GUI in question has been done using live simulated data on the workstations at the Launch Control Center (LCC), a large amount of progress has been made. As of this writing, about 60% of all of automated testing has been implemented. Additionally, the OCR tool will help make our automated tests more robust due to the tool's text recognition being highly scalable to different text fonts and text sizes. Soon we will have the whole test system automated, allowing for more full-time engineers working on development projects.

Automation↗
NASA NTRS1991

Propulsion system ground testing

The objective is to provide management visibility relative to the roles of simulation and propulsion system testing for future development programs through assessment of current propulsion related simulation capabilities and review of contributions from propulsion system test programs. The presentation is represented by viewgraphs.

Wood, Charles C.↗
NASA NTRS1992

Summary: Experimental validation of real-time fault-tolerant systems

Testing and validation of real-time systems is always difficult to perform since neither the error generation process nor the fault propagation problem is easy to comprehend. There is no better substitute to results based on actual measurements and experimentation. Such results are essential for developing a rational basis for evaluation and validation of real-time systems. However, with physical experimentation, controllability and observability are limited to external instrumentation that can be hooked-up to the system under test. And this process is quite a difficult, if not impossible, task for a complex system. Also, to set up such experiments for measurements, physical hardware must exist. On the other hand, a simulation approach allows flexibility that is unequaled by any other existing method for system evaluation. A simulation methodology for system evaluation was successfully developed and implemented and the environment was demonstrated using existing real-time avionic systems. The research was oriented toward evaluating the impact of permanent and transient faults in aircraft control computers. Results were obtained for the Bendix BDX 930 system and Hamilton Standard EEC131 jet engine controller. The studies showed that simulated fault injection is valuable, in the design stage, to evaluate the susceptibility of computing sytems to different types of failures.

Iyer, R. K.↗
NASA NTRS1977

The data systems test-dress rehearsal for FGGE

A series of Data Systems Tests conducted by NASA as a precursor to the First GARP Global Experiment is described. Included is a description of the global data sets acquired and the influence the tests had on the observing system, the data processing plans and research activities of the Global Experiment itself.

Greaves, J. R.↗
NASA NTRS2010

Testing to Transition the J-2X from Paper to Hardware

The J-2X Upper Stage Engine (USE) will be the first new human-rated upper stage engine since the Apollo program of the 1960s. It is designed to carry the Ares I and Ares V into orbit and send the Ares V to the Moon as part of NASA's Constellation Program. This paper will provide an overview of progress on the design, testing, and manufacturing of this new engine in 2009 and 2010. The J-2X embodies the program goals of basing the design on proven technology and experience and seeking commonality between the Ares vehicles as a way to minimize risk, shorten development times, and live within current budget constraints. It is based on the proven J-2 engine used on the Saturn IB and Saturn V launch vehicles. The prime contractor for the J-2X is Pratt & Whitney Rocketdyne (PWR), which is under a design, development, test, and engineering (DDT&E) contract covering the period from June 2006 through September 2014. For Ares I, the J-2X will provide engine start at approximately 190,000 feet, operate roughly 500 seconds, and shut down. For Ares V, the J-2X will start at roughly 190,000 feet to place the Earth departure stage (EDS) in orbit, shut down and loiter for up to five days, re-start on command and operate for roughly 300 seconds at its secondary power level to perform trans lunar injection (TLI), followed by final engine shutdown. The J-2X development effort focuses on four key areas: early risk mitigation, design risk mitigation, component and subassembly testing, and engine system testing. Following that plan, the J-2X successfully completed its critical design review (CDR) in 2008, and it has made significant progress in 2009 and 2010 in moving from the drawing board to the machine shop and test stand. Post-CDR manufacturing is well under way, including PWR in-house and vendor hardware. In addition, a wide range of component and sub-component tests have been completed, and more component tests are planned. Testing includes heritage powerpack, turbopump inducer water flow, turbine air flow, turbopump seal testing, main injector and gas generator, injector testing, augmented spark igniter testing, nozzle side loads cold flow testing, nozzle extension film cooling flow testing, control system testing with hardware in the loop, and nozzle extension emissivity coating tests. In parallel with hardware manufacturing, work is progressing on the new A-3 test stand to support full duration altitude testing. The Stennis A-2 test stand is scheduled to be turned over to the Constellation Program in September 2010 to be modified for J-2X testing also. As the structural steel was rising on the A-3 stand, work was under way in the nearby E complex on the chemical steam generator and subscale diffuser concepts to be used to evacuate the A-3 test cell and simulate altitude conditions.

Byrd, Tom↗
NASA NTRS2015

Integrated Test Approach

This paper describes a testing methodology undertaken on the Facilities Development and Operations Contract (FDOC) by Lockheed Martin. The methodology was defined with the intent of reducing project schedule time to enable NASA's Johnson Space Center (JSC) to be able to deliver the Mission Control Center (MCC) 21 project as quickly as possible. 21 represents the 21st century where NASA JSC is updating its control center with new technology and operational concepts in order to support NASA customers wanting to use control center assets to support space vehicle operations. In collaboration with the NASA customer, a new test concept was conceived early during MCC21 project planning with the goal of reducing project delivery time. One enabler that could help reduce delivery time was testing. Within the project, testing was performed by two entities, software development responsible for subsystem testing and system test responsible for system integration testing. The MCC21 project took a deliberate review of testing to determine how it could be performed differently to realize an overall reduction in test time to support the goal of a more rapid project delivery.

Cotton, Will↗
NASA NTRSDate not supplied

Characterization Test of the 12.5-kW Advanced Electric Propulsion System Engineering Test Unit Hall Thruster

This work presents a summary of the detailed characterization testof the 12.5 kW Advanced Electric Propulsion System Engineering Test Unit 2 (AEPS ETU-2) thruster produced by Aerojet Rocketdyne. This test campaign had two major goals: to assessthe risk of design compliance with thruster requirements and providea comparison to the previously-tested NASA Hall Effect Rocket with Magnet Shielding Technology Demonstration Units (HERMeS TDUs) from which the AEPS ETU design was derived.

AEPS↗
NASA NTRS2014

Low-cost, Risk-Reduction Testing of Class D Spacecraft Photovoltaic Systems

The end-to-end verification of a spacecraft photovoltaic power generation system requires light! A low-cost, portable, and end-to-end photovoltaic-system test appropriate for NASAs new generation of Class D missions is presented. High risk, low-cost, and quick-turn satellites rarely have the resources to execute the traditional approaches from higher-class (A-C) missions. The Class D approach, as demonstrated on the Lunar Atmospheric and Dust Environment Explorer (LADEE), utilizes a portable, metal-halide, theatre lamp for an end-to-end photovoltaic system test. While not as precise and comprehensive as the traditional Large Area Pulsed Solar Simulator (LAPSS) test, the LADEE method leverages minimal resources into an ongoing assessment program that can be applied through numerous stages of the mission. The project takes a true Class D approach in assessing the technical value of a costly, high-fidelity performance test versus a simpler approach with less programmatic risk. The resources required are a fraction of that for a LAPSS test, and is easy to repeat due to its portability. Further, the test equipment can be handed down to future projects without building an on-site facility.At the vanguard of Class D missions, the LADEE team frequently wrestled with and challenged the status quo. The philosophy of risk avoidance at all cost, typical to Class A-C missions, simply could not be executed. This innovative and simple testing solution is contextualized to NASA Class D programs and a specific risk encountered during development of the LADEE Electrical Power System (EPS). Selection of the appropriate lamp and safety concerns are discussed, with examples of test results. Combined with the vendors panel-level data and periodic inspection, the method ensures system integrity from Integration and Test (IT) through launch. Following launch, mission operations tools are utilized to assess system performance based on a scant amount of available data.

photovoltaic↗