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.
AUTOTEST is a large scale real-time computer program designed to automatically test spacecraft and experiments. Resident portions of the program collect and store incoming real-time data and process test control instructions which control experiment turn-on, select tests to be performed, and select data to be displayed.
A summary is given of the data base collected for nine weeks of Deep Space Station II. Life cycle cost parameters on efficiency and productivity ratios, costs, and telemetry were calculated from this data base.
The James Webb Space Telescope, scheduled to replace the Hubble in 2013, must simultaneously observe hundreds of faint galaxies. This requirement has led to the development of a programmable transmission mask which can be adapted to admit light with arbitrary pattern of galaxies into its spectrograph. This programmable mask will contain a large array of micro-electromechanical (MEMs) devices called MicroShutters. These microscopic shutters physically open and close like the shutter on a camera, except each shutter is microscopic in size and an array 365 by 171 is used to select the objects under spectroscopic observation at a given time, and to block the unwanted background light from other areas. NASA developed and is currently refining the exceptionally difficult process of manufacturing these shutters. This paper describes how the authors used LabVIEW FPGA and a reconfigurable I/O board to control the shutters in a test chamber and how the flexibility of the system allows us to continue to modify the control algorithms as NASA optimizes the performance of the MicroShutter arrays.
The James Webb Space Telescope, scheduled to replace the Hubble in 2013, must simultaneously observe hundreds of faint galaxies. This requirement has led to the development of a programmable transmission mask which can be adapted to admit light from an arbitrary pattern of galaxies into its spectrograph. This programmable mask will contain a large array of micro-electromechanical (MEMs) devices called MicroShutters. These microscopic shutters physically open and close like the shutter on a camera, except each shutter is microscopic in size and an array 365 by 171 is used to select the objects under spectroscopic observation at a given time, and to block the unwanted background light from other areas. NASA developed and is currently refining the exceptionally difficult process of manufacturing these shutters. This paper describes how the authors used LabVIEW FPGA and a reconfigurable I/O board to control the shutters in a test chamber and how the flexibility of the system allows us to continue to modify the control algorithms as NASA optimizes the performance of the MicroShutter arrays.
America's electrical grid is currently undergoing a multi-billion dollar modernization effort aimed at producing a highly reliable critical national infrastructure for power - a Smart Grid. While the goals for the Smart Grid include upgrades to accommodate large quantities of clean, but transient, renewable energy and upgrades to provide customers with real-time pricing information, perhaps the most important objective is to create an electrical grid with a greatly increased robustness.
The core Flight System (cFS) is a flight software (FSW) product line developed by the Flight Software Systems Branch (FSSB) at NASA's Goddard Space Flight Center (GSFC). The cFS uses compile-time configuration parameters to implement variable requirements to enable portability across embedded computing platforms and to implement different end-user functional needs. The verification and validation of these requirements is proving to be a significant challenge. This paper describes the challenges facing the cFS and the results of a pilot effort to apply EXB Solution's testing approach to the cFS applications.
To support the National Aeronautics and Space Administration’s (NASA) Space Launch System (SLS) rocket, Kennedy Space Center (KSC) has developed the Spaceport Command and Control System (SCCS) to monitor and control the pre-launch and launch operations. 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 display software of the LCS is responsible for visualizing the various data that can be received from the hardware and software components of the LCS. Since this system is providing critical information to engineers in the firing room, the visualization of data across the system must be easy to understand, but also reliable and accurate.
Creating and controlling incredibly complex vehicles such as a rocket requires an unfathomable number of tests. Such tests are necessary to ensure a successful mission and that any issues are caught immediately. Once human lives become involved, the importance of such tests cannot be understated. Often times, however, tests may not be written in a consistent manner and such inconsistencies can lead to slowing down the test-writing process and may even create concerns with the test itself. Because of this, NASA has standards that should be followed by all test writers, but the list of standards is quite long and ensuring that tests follow this perfectly can be challenging. Older tests or tests written by individuals who are unfamiliar with this guide may not be following it which can lead to inconsistencies. To fix this issue, I have taken these human-readable rules and implemented them into an open-source linting program. Linting software is used to automatically check the style of code, and in this case, the tests. In doing so, any rules that the test developer may not have followed will be flagged upon running the software and they can quickly and accurately keep their test consistent with the rules that they are expected to follow.
The Automated Flight Test Management System (ATMS) is being developed as part of the NASA Aircraft Automation Program. This program focuses on the application of interdisciplinary state-of-the-art technology in artificial intelligence, control theory, and systems methodology to problems of operating and flight testing high-performance aircraft. The development of a Flight Test Engineer's Workstation (FTEWS) is presented, with a detailed description of the system, technical details, and future planned developments. The goal of the FTEWS is to provide flight test engineers and project officers with an automated computer environment for planning, scheduling, and performing flight test programs. The FTEWS system is an outgrowth of the development of ATMS and is an implementation of a component of ATMS on SUN workstations.
The Rocket Propulsion Test-Automated Management System provides a central location for managing activities associated with Rocket Propulsion Test Management Board, National Rocket Propulsion Test Alliance, and the Senior Steering Group business management activities. A set of authorized users, both on-site and off-site with regard to Stennis Space Center (SSC), can access the system through a Web interface. Web-based forms are used for user input with generation and electronic distribution of reports easily accessible. Major functions managed by this software include meeting agenda management, meeting minutes, action requests, action items, directives, and recommendations. Additional functions include electronic review, approval, and signatures. A repository/library of documents is available for users, and all items are tracked in the system by unique identification numbers and status (open, closed, percent complete, etc.). The system also provides queries and version control for input of all items.
The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success of the Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-loop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of"pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS. The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (1) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multi-sensor series of trajectories.
The Exploration Systems Architecture defines missions that require rendezvous, proximity operations, and docking (RPOD) of two spacecraft both in Low Earth Orbit (LEO) and in Low Lunar Orbit (LLO). Uncrewed spacecraft must perform automated and/or autonomous rendezvous, proximity operations and docking operations (commonly known as AR&D). The crewed missions may also perform rendezvous and docking operations and may require different levels of automation and/or autonomy, and must provide the crew with relative navigation information for manual piloting. The capabilities of the RPOD sensors are critical to the success ofthe Exploration Program. NASA has the responsibility to determine whether the Crew Exploration Vehicle (CEV) contractor-proposed relative navigation sensor suite will meet the requirements. The relatively low technology readiness level of AR&D relative navigation sensors has been carried as one of the CEV Project's top risks. The AR&D Sensor Technology Project seeks to reduce the risk by the testing and analysis of selected relative navigation sensor technologies through hardware-in-the-Ioop testing and simulation. These activities will provide the CEV Project information to assess the relative navigation sensors maturity as well as demonstrate test methods and capabilities. The first year of this project focused on a series of "pathfinder" testing tasks to develop the test plans, test facility requirements, trajectories, math model architecture, simulation platform, and processes that will be used to evaluate the Contractor-proposed sensors. Four candidate sensors were used in the first phase of the testing. The second phase of testing used four sensors simultaneously: two Marshall Space Flight Center (MSFC) Advanced Video Guidance Sensors (AVGS), a laser-based video sensor that uses retroreflectors attached to the target vehicle, and two commercial laser range finders. The multi-sensor testing was conducted at MSFC's Flight Robotics Laboratory (FRL) using the FRL's 6-DOF gantry system, called the Dynamic Overhead Target System (DOTS). The target vehicle for "docking" in the laboratory was a mockup that was representative of the proposed CEV docking system, with added retroreflectors for the AVGS.' The multi-sensor test configuration used 35 open-loop test trajectories covering three major objectives: (l) sensor characterization trajectories designed to test a wide range of performance parameters; (2) CEV-specific trajectories designed to test performance during CEV-like approach and departure profiles; and (3) sensor characterization tests designed for evaluating sensor performance under more extreme conditions as might be induced during a spacecraft failure or during contingency situations. This paper describes the test development, test facility, test preparations, test execution, and test results of the multisensor series oftrajectories
A programmable, automated transistor test system was built to supply experimental data on new and advanced power semiconductors. The data will be used for analytical models and by engineers in designing space and aircraft electric power systems. A pulsed power technique was used at low duty cycles in a nondestructive test to examine the dynamic switching characteristic curves of power transistors in the 500 to 1000 V, 10 to 100 A range. Data collection, manipulation, storage, and output are operator interactive but are guided and controlled by the system software.
A Test/Score/Report capability is currently being developed for the Transportable Payload Operations Control Center (TPOCC) Advanced Spacecraft Simulator (TASS) system which will automate testing of the Goddard Space Flight Center (GSFC) Payload Operations Control Center (POCC) and Mission Operations Center (MOC) software in three areas: telemetry decommutation, spacecraft command processing, and spacecraft memory load and dump processing. Automated computer control of the acceptance test process is one of the primary goals of a test team. With the proper simulation tools and user interface, the task of acceptance testing, regression testing, and repeatability of specific test procedures of a ground data system can be a simpler task. Ideally, the goal for complete automation would be to plug the operational deliverable into the simulator, press the start button, execute the test procedure, accumulate and analyze the data, score the results, and report the results to the test team along with a go/no recommendation to the test team. In practice, this may not be possible because of inadequate test tools, pressures of schedules, limited resources, etc. Most tests are accomplished using a certain degree of automation and test procedures that are labor intensive. This paper discusses some simulation techniques that can improve the automation of the test process. The TASS system tests the POCC/MOC software and provides a score based on the test results. The TASS system displays statistics on the success of the POCC/MOC system processing in each of the three areas as well as event messages pertaining to the Test/Score/Report processing. The TASS system also provides formatted reports documenting each step performed during the tests and the results of each step. A prototype of the Test/Score/Report capability is available and currently being used to test some POCC/MOC software deliveries. When this capability is fully operational it should greatly reduce the time necessary to test a POCC/MOC software delivery, as well as improve the quality of the test process.
NASA is developing the Space Launch System (SLS) to be a heavy lift launch vehicle supporting human and scientific exploration beyond earth orbit. SLS will have a common core stage, an upper stage, and different permutations of boosters and fairings to perform various crewed or cargo missions. Marshall Space Flight Center (MSFC) is writing the Flight Software (FSW) that will operate the SLS launch vehicle. The FSW is developed in an incremental manner based on "Agile" software techniques. As the FSW is incrementally developed, testing the functionality of the code needs to be performed continually to ensure that the integrity of the software is maintained. Manually testing the functionality on an ever-growing set of requirements and features is not an efficient solution and therefore needs to be done automatically to ensure testing is comprehensive. To support test automation, a framework for a regression test harness has been developed and used on SLS FSW. The test harness provides a modular design approach that can compile or read in the required information specified by the developer of the test. The modularity provides independence between groups of tests and the ability to add and remove tests without disturbing others. This provides the SLS FSW team a time saving feature that is essential to meeting SLS Program technical and programmatic requirements. During development of SLS FSW, this technique has proved to be a useful tool to ensure all requirements have been tested, and that desired functionality is maintained, as changes occur. It also provides a mechanism for developers to check functionality of the code that they have developed. With this system, automation of regression testing is accomplished through a scheduling tool and/or commit hooks. Key advantages of this test harness capability includes execution support for multiple independent test cases, the ability for developers to specify precisely what they are testing and how, the ability to add automation, and the ability of the harness and cases to be executed continually. This test concept is an approach that can be adapted to support other projects.
The hardware and software configuration of a Test Matrix Sequencer, a general purpose test matrix profiler that was developed for research test facility automation at the NASA Lewis Research Center, is described. The system provides set points to controllers and contact closures to data systems during the course of a test. The Test Matrix Sequencer consists of a microprocessor controlled system which is operated from a personal computer. The software program, which is the main element of the overall system is interactive and menu driven with pop-up windows and help screens. Analog and digital input/output channels can be controlled from a personal computer using the software program. The Test Matrix Sequencer provides more efficient use of aeronautics test facilities by automating repetitive tasks that were once done manually.
The hardware and software configuration of a Test Matrix Sequencer, a general purpose test matrix profiler that was developed for research test facility automation at the NASA Lewis Research Center, is described. The system provides set points to controllers and contact closures to data systems during the course of a test. The Test Matrix Sequencer consists of a microprocessor controlled system which is operated from a personal computer. The software program, which is the main element of the overall system is interactive and menu driven with pop-up windows and help screens. Analog and digital input/output channels can be controlled from a personal computer using the software program. The Test Matrix Sequencer provides more efficient use of aeronautics test facilities by automating repetitive tasks that were once done manually.
The Automated Portable Test (APT) System is a notebook-sized, computer-based, human-performance and subjective-status assessment system. It is now being used in a wide range of environmental studies (e.g., simulator aftereffects, flight tests, drug effects, and hypoxia). Three questionnaires and 15 performance tests have been implemented, and the adaptation of 30 more tests is underway or is planned. The APT System is easily transportable, is inexpensive, and has the breadth of expansion options required for field and laboratory applications. The APT System is a powerful and expandable tool for human assessment in remote and unusual environments.