SEARCH · Search NASA
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.
Qualification tests of the electron-proton spectrometer test unit are presented. The tests conducted were: (1) functional, (2) thermal/vacuum, (3) electromagnetic interference, (4) acoustic, (5) shock, (6) vibration, and (7) humidity. Results of each type of test are presented in the form of data sheets.
The Alternator Test Unit (ATU) in the Lunar Power System Facility (LPSF) located at the NASA Glenn Research Center (GRC) in Cleveland, OH was used to simulate the operating conditions and evaluate the performance of the ATU and it s interaction with various LPSF components in accordance with the JIMO AC Power System Requirements. The testing was carried out at the breadboard development level. Results of these tests will be used for the development and validation of analytical models for performance and lifetime prediction.
In the software development process, code needs to be tested before it can be packaged for release in order to make sure the program actually does what it says is supposed to happen as well as to check how the program deals with errors and edge cases (such as negative or very large numbers). One of the major parts of the testing process is unit testing, where you test specific units of the code to make sure each individual part of the code works. This project is about unit testing many different components of the ACL software and fixing any errors encountered. To do this, mocks of other objects need to be created and every line of code needs to be exercised to make sure every case is accounted for. Mocks are important to make because it gives direct control of the environment the unit lives in instead of attempting to work with the entire program. This makes it easier to achieve the second goal of exercising every line of code.
The structural test unit of the electron-proton spectrometer was tested to a random vibration spectra and to a sinusoidal resonant search to comply with the requirements of a verification plan for the spectrometer. The test item consisted of mass simulated electronic and printed circuit boards mounted in a flight type electronic housing. The arrangement, center of gravity, and weight were as proposed for flight units.
A shock test of the electron-proton spectrometer structural test unit was conducted. The purpose of the shock test was to verify the structural integrity of the electron-spectrometer design and to obtain data on the shock response of the electronics and electronic housing. The test equipment is described and typical shock response data are provided.
The engineering test unit of the electron-proton spectrometer was thermal/vacuum tested. The tests confirmed the thermal analysis, and verified that the thermal design would control the temperatures of the instrument.
Unit tests were created to evaluate the functionality of a Data Generation and Publication tool for a command and control system. These unit tests are developed to constantly evaluate the tool and ensure it functions properly as the command and control system grows in size and scope. Unit tests are a crucial part of testing any software project and are especially instrumental in the development of a command and control system. They save resources, time and costs associated with testing, and catch issues before they become increasingly difficult and costly. The unit tests produced for the Data Generation and Publication tool to be used in a command and control system assure the users and stakeholders of its functionality and offer assurances which are vital in the launching of spacecraft safely.
An overview of my experiences writing unit tests for various projects with a specific focus on my work unit testing core Flight System (cFS) applications. I recount some of the direct personal experiences I have had that showed me the utility of having done unit testing for my projects. Many of the tips, tricks and pitfalls encountered during my time writing unit tests for the cFS app, CF, are examined. I also compare and contrast my cFS unit testing development with that of a parallel project, in which I write unit tests using RSpec, a testing framework for the Ruby programming language. I impart my complete methodology behind the CF app unit testing effort and the rationale for why I did it that way. Then I give some ideas for how you can do your own unit testing for cFS applications. You will also learn about my hopes for how unit testing cFS applications can be done going forward from where we are now.
This paper presents an analysis of the unit testing approach developed and used by the Core Flight Software (CFS) product line team at the NASA GSFC. The goal of the analysis is to understand, review, and reconunend strategies for improving the existing unit testing infrastructure as well as to capture lessons learned and best practices that can be used by other product line teams for their unit testing. The CFS unit testing framework is designed and implemented as a set of variation points, and thus testing support is built into the product line architecture. The analysis found that the CFS unit testing approach has many practical and good solutions that are worth considering when deciding how to design the testing architecture for a product line, which are documented in this paper along with some suggested innprovennents.
The mini system test unit (STU) for the Trace Gas Analyzer (TGA) is defined. The interface signals of the components used to implement the STU are also defined. The mini STU is used to support pre-flight ground test operations. The STU indications of TGA operation (organic and carbon monoxide analyses) and its ability to monitor gas chromatograph and mass spectrometer test signals are included.
The Kennedy Space Center is currently undergoing an extremely interesting transitional phase. The final Space Shuttle mission, STS-135, was completed in July of 2011. NASA is now approaching a new era of space exploration. The development of the Orion Multi- Purpose Crew Vehicle (MPCV) and the Space Launch System (SLS) launch vehicle that will launch the Orion are currently in progress. An important part of this transition involves replacing the Launch Processing System (LPS) which was previously used to process and launch Space Shuttles and their associated hardware. NASA is creating the Spaceport Command and Control System (SCCS) to replace the LPS. The SCCS will be much simpler to maintain and improve during the lifetime of the spaceflight program that it will support. The Launch Control System (LCS) is a portion of the SCCS that will be responsible for launching the rockets and spacecraft. The Integrated Launch Operations Applications (ILOA) group of SCCS is responsible for creating displays and scripts, both remote and local, that will be used to monitor and control hardware and systems needed to launch a spacecraft. It is crucial that the software contained within be thoroughly tested to ensure that it functions as intended. Unit tests must be written in Application Control Language (ACL), the scripting language used by LCS. These unit tests must ensure complete code coverage to safely guarantee there are no bugs or any kind of issue with the software.
Use of thermoelectric test unit to determine applicability of silicon-germanium power modules to space power systems requirements
Although methods in the design-build-test life cycle of the synthetic biology field have grown rapidly, the expansion has been non-uniform. The design and build stages in development have seen innovations in the form of biological CAD and more efficient means for building DNA, RNA, and other biological constructs. The testing phase of the cycle remains in need of innovation. Presented will be both a theoretical abstraction of biological measurement and a practical demonstration of a microfluidics-based platform for characterizing synthetic biological phenomena. Such a platform demonstrates a design of additive manufacturing (3D printing) for construction of a microbial fuel cell (MFC) to be used in experiments carried out in space. First, the biocompatibility of the polypropylene chassis will be demonstrated. The novel MFCs will be cheaper, and faster to make and iterate through designs. The novel design will contain a manifold switchingdistribution system and an integrated in-chip set of reagent reservoirs fabricated via 3D printing. The automated nature of the 3D printing yields itself to higher resolution switching valves and leads to smaller sized payloads, lower cost, reduced power and a standardized platform for synthetic biology unit tests on Earth and in space. It will be demonstrated that the application of unit testing in synthetic biology will lead to the automatic construction and validation of desired constructs. Unit testing methodologies offer benefits of preemptive problem identification, change of facility, simplicity of integration, ease of documentation, and separation of interface from implementation, and automated design.
This report summarizes the results obtained from an analysis of the NASA Marshall Spaceflight Center (MSFC) cryostat testing unit. A finite element model was generated to determine both temperature distribution and stress distribution in the cryostat testing unit for load conditions supplied by MSFC. This report contains the results of that analysis.
This work presents a summary of the performance test campaign of the 12.5 kW Advanced Electric Propulsion System (AEPS) Engineering Test Unit 2 (ETU-2) thruster produced by Aerojet Rocketdyne. This test campaign had three major goals: to assess design compliance with thruster requirements, provide a comparison to the previously-tested NASA Hall Effect Rocket with Magnet Shielding (HERMeS) Technology Demonstration Units (TDUs) from which the AEPS ETU design was derived, and support AEPS application on the Power and Propulsion Element (PPE). Assessments of ETU-2 performance were conducted at discharge powers of 2.6 to 13.1 kW, which encompasses the original AEPS throttle conditions as well as those most relevant for AEPS application on PPE. The results from the test campaign indicate that ETU-2 performance meets or exceeds all AEPS thruster performance requirements and matches the values and trends previously measured with the HERMeS TDUs. In addition, similar to the HERMeS TDUs, ETU-2 performance showed minimal variation over approximately 1636 h of operating time due to the incorporation of magnetic shielding. Taken together, these results show that the AEPS design is successfully replicating the performance of the HERMeS TDUs to within the empirical uncertainty and meeting its performance requirements as the design progresses to its Critical Design Review.
This work presents a summary of the performance test campaign of the 12.5 kW Advanced Electric Propulsion System (AEPS) Engineering Test Unit 2 (ETU-2) thruster produced by Aerojet Rocketdyne. This test campaign had three major goals: to assess design compliance with thruster requirements, provide a comparison to the previously-tested NASA Hall Effect Rocket with Magnet Shielding (HERMeS) Technology Demonstration Units (TDUs) from which the AEPS ETU design was derived, and support AEPS application on the Power and Propulsion Element (PPE). Assessments of ETU-2 performance were conducted at discharge powers of 2.6 to 13.1 kW, which encompasses the original AEPS throttle conditions as well as those most relevant for AEPS application on PPE. The results from the test campaign indicate that ETU-2 performance meets or exceeds all AEPS thruster performance requirements and matches the values and trends previously measured with the HERMeS TDUs. In addition, similar to the HERMeS TDUs, ETU-2 performance showed minimal variation over approximately 1636 h of operating time due to the incorporation of magnetic shielding. Taken together, these results show that the AEPS design is successfully replicating the performance of the HERMeS TDUs to within the empirical uncertainty and meeting its performance requirements as the design progresses to its Critical Design Review.
The COR1 Engineering Test Unit (ETU), which had been previously tested at the NCAR/HAO and NRL test facilities, was modified into an instrument capable of observing the Sun. It was then taken to the Mauna Loa Solar Observatory to observe the corona. The changes made to observe the Sun were as follows: 1. The plate scale was changed to accommodate the smaller Apogee camera. This change had already been made for the NRL tests. 2. The previous Oriel polarizer was replaced with a commercial Polarcor polarizer from Newport to be more flight-like. However, because of cost and availability considerations, this polarizer was smaller than those which will be used for flight. 3. A structure was placed around the back section of the instrument, to protect it from stray light. 4. A pointing spar borrowed from HAO was used to track the Sun. A few days into the test, it became evident that some artifacts were appearing in the data, and these artifacts were changing as the polarizer was rotated. It was decided to test two other polarizers, the Oriel polarizer which had been used in the previous tests at HAO and NRL, and a Nikon polarizer which was borrowed from a camera belonging to one of the observatory staff members. These three polarizers had much different qualities are shown.
The Optical Test Unit (OTU) for the NASA Direct Detection Laser Tranceiver (DDLT) Experiment was designed to perform a wide variety of electrical and optical tests with minimum cost and risk. Choosing instruments that could do their own processing and carefully examining each step of the integration and test sequence helped reduce the cost and complexity of the system, allowing us to meet a very ambitious schedule. For some tests, less elegant schemes can be used than the traditional system test methods, while still maintaining the integrity of the test system. This paper explores the problems encountered and options that were available in designing the system test equipment for this optical communication system.