Search NASA⌕ Search

SEARCH · Search NASA

Results for “Automated Functional 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.

419 records · Page 24
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Less-Complex Method of Classifying MPSK

An alternative to an optimal method of automated classification of signals modulated with M-ary phase-shift-keying (M-ary PSK or MPSK) has been derived. The alternative method is approximate, but it offers nearly optimal performance and entails much less complexity, which translates to much less computation time. Modulation classification is becoming increasingly important in radio-communication systems that utilize multiple data modulation schemes and include software-defined or software-controlled receivers. Such a receiver may "know" little a priori about an incoming signal but may be required to correctly classify its data rate, modulation type, and forward error-correction code before properly configuring itself to acquire and track the symbol timing, carrier frequency, and phase, and ultimately produce decoded bits. Modulation classification has long been an important component of military interception of initially unknown radio signals transmitted by adversaries. Modulation classification may also be useful for enabling cellular telephones to automatically recognize different signal types and configure themselves accordingly. The concept of modulation classification as outlined in the preceding paragraph is quite general. However, at the present early stage of development, and for the purpose of describing the present alternative method, the term "modulation classification" or simply "classification" signifies, more specifically, a distinction between M-ary and M'-ary PSK, where M and M' represent two different integer multiples of 2. Both the prior optimal method and the present alternative method require the acquisition of magnitude and phase values of a number (N) of consecutive baseband samples of the incoming signal + noise. The prior optimal method is based on a maximum- likelihood (ML) classification rule that requires a calculation of likelihood functions for the M and M' hypotheses: Each likelihood function is an integral, over a full cycle of carrier phase, of a complicated sum of functions of the baseband sample values, the carrier phase, the carrier-signal and noise magnitudes, and M or M'. Then the likelihood ratio, defined as the ratio between the likelihood functions, is computed, leading to the choice of whichever hypothesis - M or M'- is more likely. In the alternative method, the integral in each likelihood function is approximated by a sum over values of the integrand sampled at a number, 1, of equally spaced values of carrier phase. Used in this way, 1 is a parameter that can be adjusted to trade computational complexity against the probability of misclassification. In the limit as 1 approaches infinity, one obtains the integral form of the likelihood function and thus recovers the ML classification. The present approximate method has been tested in comparison with the ML method by means of computational simulations. The results of the simulations have shown that the performance (as quantified by probability of misclassification) of the approximate method is nearly indistinguishable from that of the ML method (see figure).

Hamkins, Jon↗
NASA NTRSDate not supplied

CFD 2030 Grand Challenge: CFD-in-the-Loop Monte Carlo Flight Simulation for Space Vehicle Design

Flight qualification of space vehicles is markedly different from those typically employed for aircraft. The concept of an extensive flight test campaign for a space vehicle does not exist, and vehicle designers must look to alternative techniques for demonstrating robust and reliable performance of their vehicles prior to operational flight. A space vehicle may undergo only a handful of flight tests in its development cycle, with each flight representing a drastically different flight phase or flight configuration. For instance, NASA’s Space Launch System (SLS) launch vehicle and Orion spacecraft will only see a total of four flight demonstrations before flying a crew on its first operational mission, and each flight demonstrates a unique vehicle configuration and/or set of flight conditions. The SLS will be flown only one time before it becomes operational (Artemis 1). The Orion spacecraft Crew Module (CM) will have been tested twice, once on a Delta IV launch vehicle (Exploration Flight Test 1) and once as a fully integrated system with the SLS launch vehicle (Artemis 1). The Orion Launch abort system will have been tested twice, once in a pad abort scenario (Pad Abort 1) and once in an inflight abort scenario (Ascent Abort 2) on a modified Peacekeeper booster. Both of these latter tests involve only a boiler plate CM, not a functional Orion spacecraft. Thus, unlike aircraft, there is very little opportunity for engineers to assess and evaluate their preflight predictions. Instead, space vehicle designers rely on Monte Carlo flight simulations with detailed dispersions of predicted nominal flight behavior to determine how robust their design is to errors and uncertainties in the flight conditions their vehicle may encounter. These Monte Carlo analyses entail thousands of trajectory simulations to demonstrate that the vehicle can meet design requirements at a specified level of reliability. From an aerodynamics and aerothermodynamics perspective, these trajectory simulations are fueled by an extensive aerodynamic database that covers the complete range of expected flight conditions, vehicle configurations, and flight attitudes expected in a given mission. Today, these databases amount to a table of engineering parameters that can be quickly interrogated by the trajectory simulator. The aerodynamic and aerothermodynamic databases are assembled via a series of ground tests, empirical and analytical analysis, physics-based computational analysis, applicable past flight performance data, and in some cases, engineering judgment. These databases generally take years to assemble for a new space vehicle system and in the case of SLS/Orion, over a decade of test and analysis have been expended to develop the extensive databases required to cover the myriad of configurations and potential flight conditions required for the system. Recently, it has been proposed that Computational Fluid Dynamic (CFD) and computing capability may be reaching a point where it is foreseeable that CFD could be integrated directly into the production trajectory simulation tools used to design NASA’s space vehicles. To demonstrate this, NASA has embarked on two demonstrations of this type of capability, one where six degree of freedom flight trajectory simulation equations are embedded in an existing CFD solver and another where a production CFD solver is loosely coupled with a production trajectory simulation tool. These efforts represent an initial demonstration of a future approach to flight trajectory simulation, but they are a far cry from the capability required to perform a full-up CFD-in-the-loop Monte Carlo trajectory simulation. Therefore, this represents a viable grand challenge for computational methods addressing space vehicle design and development. The final paper/presentation will discuss the many hurdles, beyond simply raw computational power, to realizing this grand challenge and how they map directly to the CFD Vision 2030 ojectives. Among these are the wide range of flight conditions, including accelerating/decelerating flight, encountered by a space vehicle during launch and/or entry. The vehicle can also encounter numerous configuration changes, some of which can be quite drastic, during the course of its flight, so robust, automated geometry modeling, grid generation, and adaptation will play a huge role in reaching this goal. Multiply this by 1000’s of trajectory simulations occurring simultaneously in a given Monte Carlo analysis, and the problem readily scales to absorb virtually any size of supercomputer envisioned today. The concept of CFD-in-the-loop Monte Carlo trajectory simulation poses a formidable challenge for emerging and future computing systems, and it has the potential to shave years off the development cycle for aerodynamic and aerothermodynamic performance predictions as compared to today’s space vehicle design approach.

CFD 2030↗
NASA NTRS2016

Automated ISS Flight Utilities

During my internship at NASA Johnson Space Center, I worked in the Space Radiation Analysis Group (SRAG), where I was tasked with a number of projects focused on the automation of tasks and activities related to the operation of the International Space Station (ISS). As I worked on a number of projects, I have written short sections below to give a description for each, followed by more general remarks on the internship experience. My first project is titled "General Exposure Representation EVADOSE", also known as "GEnEVADOSE". This project involved the design and development of a C++/ ROOT framework focused on radiation exposure for extravehicular activity (EVA) planning for the ISS. The utility helps mission managers plan EVAs by displaying information on the cumulative radiation doses that crew will receive during an EVA as a function of the egress time and duration of the activity. SRAG uses a utility called EVADOSE, employing a model of the space radiation environment in low Earth orbit to predict these doses, as while outside the ISS the astronauts will have less shielding from charged particles such as electrons and protons. However, EVADOSE output is cumbersome to work with, and prior to GEnEVADOSE, querying data and producing graphs of ISS trajectories and cumulative doses versus egress time required manual work in Microsoft Excel. GEnEVADOSE automates all this work, reading in EVADOSE output file(s) along with a plaintext file input by the user providing input parameters. GEnEVADOSE will output a text file containing all the necessary dosimetry for each proposed EVA egress time, for each specified EVADOSE file. It also plots cumulative dose versus egress time and the ISS trajectory, and displays all of this information in an auto-generated presentation made in LaTeX. New features have also been added, such as best-case scenarios (egress times corresponding to the least dose), interpolated curves for trajectories, and the ability to query any time in the EVADES output. As mentioned above, GEnEVADOSE makes extensive use of ROOT version 6, the data analysis framework developed at the European Organization for Nuclear Research (CERN), and the code is written to the C++11 standard (as are the other projects). My second project is the Automated Mission Reference Exposure Utility (AMREU).Unlike GEnEVADOSE, AMREU is a combination of three frameworks written in both Python and C++, also making use of ROOT (and PyROOT). Run as a combination of daily and weekly cron jobs, these macros query the SRAG database system to determine the active ISS missions, and query minute-by-minute radiation dose information from ISS-TEPC (Tissue Equivalent Proportional Counter), one of the radiation detectors onboard the ISS. Using this information, AMREU creates a corrected data set of daily radiation doses, addressing situations where TEPC may be offline or locked up by correcting doses for days with less than 95% live time (the total amount time the instrument acquires data) by averaging the past 7 days. As not all errors may be automatically detectable, AMREU also allows for manual corrections, checking an updated plaintext file each time it runs. With the corrected data, AMREU generates cumulative dose plots for each mission, and uses a Python script to generate a flight note file (.docx format) containing these plots, as well as information sections to be filled in and modified by the space weather environment officers with information specific to the week. AMREU is set up to run without requiring any user input, and it automatically archives old flight notes and information files for missions that are no longer active. My other projects involve cleaning up a large data set from the Charged Particle Directional Spectrometer (CPDS), joining together many different data sets in order to clean up information in SRAG SQL databases, and developing other automated utilities for displaying information on active solar regions, that may be used by the space weather environment officers to monitor solar activity. I consulted my mentor Dr. Ryan Rios and Dr. Kerry Lee for project requirements and added features, and ROOT developer Edmond Offermann for advice on using the ROOT library. I also received advice and feedback from Dr. Janet Barzilla of SRAG, who tested my code. Besides these inputs, I worked independently, writing all of the code by myself. The code for all these projects is documented throughout, and I have attempted to write it in a modular format. Assuming that ROOT is updated accordingly, these codes are also Y2038-compliant (and Y10K-compliant). This allows the code to be easily referenced, modified and possibly repurposed for non-ISS missions in the future, should the necessary inputs exist. These projects have taught me a lot about coding and software design - I have become a much more skilled C++ programmer and ROOT user, and I also learned to code in Python and PyROOT (and its advantages and disadvantages compared to C++/ ROOT). Furthermore, I have learned about space radiation and radiation modeling, topics that greatly interest me as I pursue a degree in physics. Working alongside experimental physicists like Dr. Rios, I have developed a greater understanding and appreciation for experimental science, something I have always leaned towards but to which I lacked significant exposure. My work in SRAG has also given me the invaluable opportunity to witness the work environment for physicists at NASA, and what a career in academia may look like at a government laboratory such as NASA Johnson Space Center. As I continue my studies and look forward to graduate school and a future career, this experience at NASA has given me a meaningful and enjoyable opportunity to put my skills to use and see what my future career path might hold.

Offermann, Jan Tuzlic↗
NASA NTRS2013

Planetary Protection Bioburden Analysis Program

This program is a Microsoft Access program that performed statistical analysis of the colony counts from assays performed on the Mars Science Laboratory (MSL) spacecraft to determine the bioburden density, 3-sigma biodensity, and the total bioburdens required for the MSL prelaunch reports. It also contains numerous tools that report the data in various ways to simplify the reports required. The program performs all the calculations directly in the MS Access program. Prior to this development, the data was exported to large Excel files that had to be cut and pasted to provide the desired results. The program contains a main menu and a number of submenus. Analyses can be performed by using either all the assays, or only the accountable assays that will be used in the final analysis. There are three options on the first menu: either calculate using (1) the old MER (Mars Exploration Rover) statistics, (2) the MSL statistics for all the assays, or This software implements penetration limit equations for common micrometeoroid and orbital debris (MMOD) shield configurations, windows, and thermal protection systems. Allowable MMOD risk is formulated in terms of the probability of penetration (PNP) of the spacecraft pressure hull. For calculating the risk, spacecraft geometry models, mission profiles, debris environment models, and penetration limit equations for installed shielding configurations are required. Risk assessment software such as NASA's BUMPERII is used to calculate mission PNP; however, they are unsuitable for use in shield design and preliminary analysis studies. The software defines a single equation for the design and performance evaluation of common MMOD shielding configurations, windows, and thermal protection systems, along with a description of their validity range and guidelines for their application. Recommendations are based on preliminary reviews of fundamental assumptions, and accuracy in predicting experimental impact test results. The software is programmed in Visual Basic for Applications for installation as a simple add-in for Microsoft Excel. The user is directed to a graphical user interface (GUI) that requires user inputs and provides solutions directly in Microsoft Excel workbooks. This work was done by Shannon Ryan of the USRA Lunar and Planetary Institute for Johnson Space Center. Further information is contained in a TSP (see page 1). MSC- 24582-1 Micrometeoroid and Orbital Debris (MMOD) Shield Ballistic Limit Analysis Program Lyndon B. Johnson Space Center, Houston, Texas Commercially, because it is so generic, Enigma can be used for almost any project that requires engineering visualization, model building, or animation. Models in Enigma can be exported to many other formats for use in other applications as well. Educationally, Enigma is being used to allow university students to visualize robotic algorithms in a simulation mode before using them with actual hardware. This work was done by David Shores and Sharon P. Goza of Johnson Space Center; Cheyenne McKeegan, Rick Easley, Janet Way, and Shonn Everett of MEI Technologies; Mark Manning of PTI; and Mark Guerra, Ray Kraesig, and William Leu of Tietronix Software, Inc. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24211-1 Spitzer Telemetry Processing System NASA's Jet Propulsion Laboratory, Pasadena, California The Spitzer Telemetry Processing System (SirtfTlmProc) was designed to address objectives of JPL's Multi-mission Image Processing Lab (MIPL) in processing spacecraft telemetry and distributing the resulting data to the science community. To minimize costs and maximize operability, the software design focused on automated error recovery, performance, and information management. The system processes telemetry from the Spitzer spacecraft and delivers Level 0 products to the Spitzer Science Center. SirtfTlmProc is a unique system with automated error notification and recovery, with a real-time continuous service that can go quiescent after periods of inactivity. The software can process 2 GB of telemetry and deliver Level 0 science products to the end user in four hours. It provides analysis tools so the operator can manage the system and troubleshoot problems. It automates telemetry processing in order to reduce staffing costs. This work was done by Alice Stanboli, Elmain M. Martinez, and James M. McAuley of Caltech for NASA's Jet Propulsion Laboratory. For more information, contact iaoffice @jpl.nasa.gov. This software is available for commercial licensing. Please contact Dan Broderick at Daniel.F. Broderick@jpl.nasa.gov. Refer to NPO-47803. NASA Tech Briefs, September 2013 29 This rapid response computer program predicts Orbiter Wing Leading Edge (WLE) damage caused by ice or foam impact during a Space Shuttle launch (Program "IMPACT2"). The program was developed after the Columbia accident in order to assess quickly WLE damage due to ice, foam, or metal impact (if any) during a Shuttle launch. IMPACT2 simulates an impact event in a few minutes for foam impactors, and in seconds for ice and metal impactors. The damage criterion is derived from results obtained from one sophisticated commercial program, which requires hours to carry out simulations of the same impact events. The program was designed to run much faster than the commercial program with prediction of projectile threshold velocities within 10 to 15% of commercial-program values. The mathematical model involves coupling of Orbiter wing normal modes of vibration to nonlinear or linear springmass models. IMPACT2 solves nonlinear or linear impact problems using classical normal modes of vibration of a target, and nonlinear/ linear time-domain equations for the projectile. Impact loads and stresses developed in the target are computed as functions of time. This model is novel because of its speed of execution. A typical model of foam, or other projectile characterized by material nonlinearities, impacting an RCC panel is executed in minutes instead of hours needed by the commercial programs. Target damage due to impact can be assessed quickly, provided that target vibration modes and allowable stress are known. This work was done by Robert Clark, Jr., Paul Cotter, and Constantine Michalopoulos of The Boeing Company for Johnson Space Center. For further information, contact the JSC Innovation Partnerships Office at (281) 483-3809. MSC-24988-1 Wing Leading Edge RCC Rapid Response Damage Prediction Tool (IMPACT2) Lyndon B. Johnson Space Center, Houston, Texas (3) the MSL statistics for only the accountable assays. Other options on the main menu include a data editing form and utility programs that produce various reports requested by the microbiologists and the project, and tools to generate the groupings for the final analyses. The analyses can be carried out in three ways: Each assay can be treated separately, the assays can be collectively treated for the whole zone as a group, or the assays can be collected in groups designated by the JPL Planetary Protection Manager. The latter approach was used to generate the final report because assays on the same equipment or similar equipment can be assumed to have been exposed to the same environment and cleaning. Thus, the statistics are improved by having a larger population, thereby reducing the standard deviation by the square root of N. For each method mentioned above, three reports are available. The first is a detailed report including all the data. This version was very useful in verifying the calculations. The second is a brief report that is similar to the full detailed report, but does not print out the data. The third is a grand total and summary report in which each assay requires only one line. For the first and second reports, most of the calculations are performed in the report section itself. For the third, all the calculations are performed directly in the query bound to the report. All the numerical results were verified by comparing them with Excel templates, then exporting the data from the Planetary Protection Analysis program to Excel.

Beaudet, Robert A.↗
NASA NTRSDate not supplied

Manual Crew Override of Vehicle Landings Following G-Transitions

BACKGROUND Manual control during exploration spaceflight consists of both planned automated supervisory control and unplanned crew override. This crew override capability is critical to enable overall mission success during landing contingencies. However, the introduction of manual override capabilities must be implemented to enable crews to mitigate risks introduced by human error. Adaptive changes in the sensorimotor system can manifest during g-transitions as spatial disorientation. While training and landing aids enable successful landing through disorientation, these adaptive changes may increase cognitive demand that needs to be accounted for in the manual control strategy. It is important to characterize these effects as soon as possible following the G-transition to develop appropriate countermeasures. METHODS In this study, we will examine operational piloting tasks following International Space Station (ISS) missions in a simulated lunar landing using a six-degree-of-freedom (6DOF) motion base. The motion-based simulation will be implemented in our laboratory at the Johnson Space Center (JSC) and will be available within hours following the return from commercial crew landings. The primary goals of this study are (1) to understand the impact of spaceflight on crew ability to perform manual crew override tasks, (2) to examine how adaptive changes in vestibular and cognitive function relate to changes in manual crew override proficiency, and (3) compare performance during late “just-in-time” on-board training with early post-flight crew performance. The impact of spaceflight on piloting capability will be assessed from pre- versus post-flight changes in crewmembers assigned to either short duration (< 30 day) or long duration (~6- month) missions to the International Space Station (ISS). Individual differences in post-flight vestibular and cognitive changes include motion sickness reports, measures of tilt motion perception accuracy and precision, and dual-task tracking. During the 6DOF lunar simulation, the crew will manually takeover attitude and rate-of-descent to the nominal or re-designated landing aim point during the approach phase. The outcome measures for the lunar crew override tasks will be the percent time maintaining actual vehicle states, e.g., attitude and rate-of-descent, within recommended guidance during the landing approach, number and maximum deviation outside limits, and root mean square error (RMSE). Given that “just-in-time” (JIT) training is an operational expectation for the Human Landing System (HLS) program, all participants will perform late inflight JIT training for each manual crew override task in which they will participate. Crew proficiency will be captured inflight during JIT training that will be implemented on a laptop with hand controllers to allow the crewmember to practice the landing task procedures like the approach implemented for JIT training with Shuttle landing and ISS telerobotic tasks. COUNTERMEASURE UPDATES The lunar lander simulation has been implemented onto a two-laptop display system where subjects select from alternative landing points, based upon avoiding hazards that the on-board system identifies during the landing. The subject makes inputs using a rotational hand controller (i.e., joystick) and a translational hand controller, which are processed by simulated vehicle dynamics to update the vehicle attitude and rate of descent. Subjects will utilize a combination of flight, situation, and status displays to monitor the state of the simulated vehicle. The simulation exports tilt and translation movements to a 6DOF motion base synced to visual movements and provides representative vestibular cues to the subject while performing the task inside an enclosed cabin featuring a simulated lunar out-the-window view and a heads-down lander cockpit view. RELEVANCE This project will deliver an operational demonstration of crew override capability following spaceflight and identify potential deficits that may require remediation. Comparison of individual vestibular and cognitive changes with crew override performance will help better characterize the manual control risks associated with sensorimotor alterations. The inclusion of “just-in-time” on-board training will ensure we are characterizing changes in override proficiency with this expected countermeasure in place. ACKNOWLEDGEMENTS: The authors acknowledge contributions from Draper, HLS Joint Test Panel, Crew HLS Interfaces for Piloting Working Group, and Dynamic Skills Trainer (DST) Lab toward the development of the lunar landing simulation. This project is funded by the Human Health Countermeasures Element.

Austin M Bollinger↗