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.
This article discusses the application of the Category-Partition Method to the test design phase. The method provides a formal framework for reducing the total number of possible test cases to a minimum logical subset for effective testing. An automatic tool and a formal language have been developed to implement the method and produce the specification of test cases
This paper details the various I&C considerations and design decisions made throughout the MARVEL (Micro-reactor Applications Research Validation and Evaluation) project, including sensor and actuator selection, safety-related functionality, digital control hardware and software, and testing methodologies. Key challenges such as managing radiation, temperature, and space constraints are discussed, along with the trade-offs between using standard equipment and custom solutions. The successful integration of off-the-shelf components, the emphasis on minimizing safety-related instrumentation, and the lessons learned from prototyping and testing are highlighted. The authors aim to provide insights that can benefit future micro-reactor designs and emphasize the importance of real-world testing in advancing reactor technology.
This paper describes the hardware, software, and test procedures implemented at a ground station for the automated testing of a polar-orbiting satellite in a low orbit. The satellite passes during the testing were characterized by short visibility times of no more than 18 min and by high rates of change of the link parameters as seen by the ground station. The advantages of automated testing became apparent for these dynamic conditions. Under computer control throughout the pass, programmable test instruments were commanded and data was collected and stored. Data reduction was performed after the pass.
This paper describes the role of requirements discovery during the testing of a safety-critical sofiware system.
This is a technical report from the lead institution – University of Utah, Kahlert School of Computing – funded under the Department of Energy, Office of Science, Office of Advanced Scientific Computing Research under award number DE-SC0022252. We summarize our work done over the three years of funding received. The relevant papers and software have already been uploaded at the DOE site.
Final report for Comport grant.
An analysis of UVSP wavelength drive hardware, problems, and recovery procedures; radiative power loss from solar plasmas; and correlations between observed UV brightness and inferred photospheric currents are given.
Simulation-Based Cost Model (SiCM) is a computer program that simulates pertinent aspects of the testing of rocket engines for the purpose of estimating the costs of such testing during time intervals specified by its users. A user enters input data for control of simulations; information on the nature of, and activity in, a given testing project; and information on resources. Simulation objects are created on the basis of this input. Costs of the engineering-design, construction, and testing phases of a given project are estimated from numbers and labor rates of engineers and technicians employed in each phase, the duration of each phase; costs of materials used in each phase; and, for the testing phase, the rate of maintenance of the testing facility. The three main outputs of SiCM are (1) a curve, updated at each iteration of the simulation, that shows overall expenditures vs. time during the interval specified by the user; (2) a histogram of the total costs from all iterations of the simulation; and (3) table displaying means and variances of cumulative costs for each phase from all iterations. Other outputs include spending curves for each phase.
Online data validation is a performance-enhancing component of modern control and health management systems. It is essential that performance of the data validation system be verified prior to its use in a control and health management system. A new Data Qualification and Validation (DQV) Test-bed application was developed to provide a systematic test environment for this performance verification. The DQV Test-bed was used to evaluate a model-based data validation package known as the Data Quality Validation Studio (DQVS). DQVS was employed as the primary data validation component of a rocket engine health management (EHM) system developed under NASA's NGLT (Next Generation Launch Technology) program. In this paper, the DQVS and DQV Test-bed software applications are described, and the DQV Test-bed verification procedure for this EHM system application is presented. Test-bed results are summarized and implications for EHM system performance improvements are discussed.
NASA scientists in MDRS Crew 49 (April 23-May 7, 2006) field tested and significantly extended a prototype monitoring and advising system that integrates power system telemetry with a voice commanding interface. A distributed, wireless network of functionally specialized agents interacted with the crew to provide alerts (e.g., impending shut-down of inverter due to low battery voltage), access md interpret historical data, and display troubleshooting procedures. In practical application during two weeks, the system generated speech over loudspeakers and headsets lo alert the crew about the need to investigate power system problems. The prototype system adapts the Brahms/Mobile Agents toolkit to receive data from the OneMeter (Brand Electronics) electric metering system deployed by Crew 47. A computer on the upper deck was connected to loudspeakers, four others were paired with wireless (Bluetooth) headsets that enabled crew members to interact with their personal agents from anywhere in the hab. Voice commands and inquiries included: 1. What is the {battery | generator} {volts | amps | volts and amps}? 2. What is the status of the {generator | inverter | battery | solar panel}? 3. What is the hab{itat} {power usage | volts | voltage | amps | volts and amps}? 4. What was the average hab{itat} {amps | volts | voltage} since <#> {AM | PM)? 5. When did the {generator | batteries} change status? 6. Tell {me I | everyone} when{ ever} the generator goes offline. 7. Tell {me | | everyone} when the hab{itat} {amps | volts | voltage} {exceeds | drops brelow} <#>. 8. {Send | Take | Record} {a} voice note {(for | to} } {at }. This research demonstrates the principles of design in the context of use, investigating requirements through experimental use of prototype systems in an analog setting, and use of MDRS as a research facility for designing and implementing new systems.
Payload Operations Support Team Tools is a software system that assists in (1) development and testing of software for payloads to be flown aboard the space shuttles and (2) training of payload customers, flight controllers, and flight crews in payload operations
Simulation-Based Cost Model (SiCM), a discrete event simulation developed in Extend , simulates pertinent aspects of the testing of rocket propulsion test articles for the purpose of estimating the costs of such testing during time intervals specified by its users. A user enters input data for control of simulations; information on the nature of, and activity in, a given testing project; and information on resources. Simulation objects are created on the basis of this input. Costs of the engineering-design, construction, and testing phases of a given project are estimated from numbers and labor rates of engineers and technicians employed in each phase, the duration of each phase; costs of materials used in each phase; and, for the testing phase, the rate of maintenance of the testing facility. The three main outputs of SiCM are (1) a curve, updated at each iteration of the simulation, that shows overall expenditures vs. time during the interval specified by the user; (2) a histogram of the total costs from all iterations of the simulation; and (3) table displaying means and variances of cumulative costs for each phase from all iterations. Other outputs include spending curves for each phase.
As missions extend further into space, the modeling and simulation of their every action and instruction becomes critical. The greater the distance between Earth and the spacecraft, the smaller the window for communication becomes. Therefore, through modeling and simulating the planned operations, the most efficient sequence of commands can be sent to the spacecraft. The Space Mission Sequencing Software is being developed as the next generation of sequencing software to ensure the most efficient communication to interplanetary and deep space mission spacecraft. Aside from efficiency, the software also checks to make sure that communication during a specified time is even possible, meaning that there is not a planet or moon preventing reception of a signal from Earth or that two opposing commands are being given simultaneously. In this way, the software not only models the proposed instructions to the spacecraft, but also validates the commands as well.To ensure that all spacecraft communications are sequenced properly, a timeline is used to structure the data. The created timelines are immutable and once data is as-signed to a timeline, it shall never be deleted nor renamed. This is to prevent the need for storing and filing the timelines for use by other programs. Several types of timelines can be created to accommodate different types of communications (activities, measurements, commands, states, events). Each of these timeline types requires specific parameters and all have options for additional parameters if needed. With so many combinations of parameters available, the robustness and stability of the software is a necessity. Therefore a baseline must be established to ensure the full functionality of the software and it is here where the irreducible tests come into use.
A study was conducted to define the complexity and magnitude of the Spacelab software challenge. The study was based on current Spacelab program concepts, anticipated flight schedules, and ground operation plans. The study was primarily directed toward identifying and solving problems related to the experiment flight application and tests and checkout software executing in the Spacelab onboard command and data management subsystem (CDMS) computers and electrical ground support equipment (EGSE). The study provides a conceptual base from which it is possible to proceed into the development phase of the Software Test and Integration Laboratory (STIL) and establishes guidelines for the definition of standards which will ensure that the total Spacelab software is understood prior to entering development.
The development history of the data acquisition and data analysis software is discussed. The software development occurred between 1978 and 1984 in support of solar energy module testing at the Jet Propulsion Laboratory's Parabolic Dish Test Site, located within Edwards Test Station. The development went through incremental stages, starting with a simple single-user BASIC set of programs, and progressing to the relative complex multi-user FORTRAN system that was used until the termination of the project. Additional software in support of testing is discussed including software in support of a meteorological subsystem and the Test Bed Concentrator Control Console interface. Conclusions and recommendations for further development are discussed.
What is a "good" visualization? How can the quality of a visualization be measured? How can one tell whether one visualization is "better" than another? I claim that the true quality of a visualization can only be measured in the context of a particular purpose. The same image generated from the same data may be excellent for one purpose and abysmal for another. A good measure of visualization quality will correspond to the performance of users in accomplishing the intended purpose, so the "gold standard" is user testing. As a user of visualization software (or at least a consultant to such users) I don't expect visualization software to have been tested in this way for every possible use. In fact, scientific visualization (as distinct from more "production oriented" uses of visualization) will continually encounter new data, new questions and new purposes; user testing can never keep up. User need software they can trust, and advice on appropriate visualizations of particular purposes. Considering the following four processes, and their impact on visualization trustworthiness, reveals important work needed to create worthwhile metrics and benchmarks for visualization. These four processes are (1) complete system testing (user-in-loop), (2) software testing, (3) software design and (4) information dissemination. Additional information is contained in the original extended abstract.
We describe and test a software approach to overcoming radiation-induced errors in spaceborne applications running on commercial off-the-shelf components.
As part of the Artemis program to return humans to the lunar surface, the National Aeronautics and Space Administration is planning to use the Orion Multi- Purpose Crew Vehicle to transport crew to a small orbital platform called Gate- way in cislunar space. To facilitate this activity, Orion is required to perform Rendezvous, Proximity Operations, and Docking (RPOD) with both the Gate- way and the launch vehicle upper stage. The Orion spacecraft uses sequencing in the form of Phases, Segments, Activities, and Modes (PSAM) to configure Guidance, Navigation, & Control (GN&C) software during each portion of the mission. Significant updates to Orion PSAM definitions are required for RPOD. This paper describes the process of defining these new sequencing elements, implementing them in prototype flight software, and testing them in an integrated simulation environment. First, requirements are specified to determine the nominal and off-nominal sequencing behavior necessary to complete the mission. These requirements also specify which software functions should be fully autonomous and which functions require manual interactions from crew or ground operators. Next, the RPOD concept of operations is defined with detailed events listed in a mission timeline. Third, a state machine diagram is developed to show all PSAM states, including all possible transitions between them. After this, the PSAM states and transitions are entered into a sequencing software emulator and parameter values and modes are defined for GN&C software elements. Finally, the PSAM architecture is tested within an integrated simulation environment by connecting it with prototypes of relevant GN&C flight software elements and with detailed vehicle models. After the sequencing design has been finalized and tested, it is implemented in flight software.