Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “File System”

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 1,765 records · Page 98
All sourcesNASA NTRSDOE OSTI
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, attitude control, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on previous missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the perceived benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS2010

Momentum Management Tool for Low-Thrust Missions

A momentum management tool was designed for the Dawn low-thrust interplanetary spacecraft en route to the asteroids Vesta and Ceres, in an effort to better understand the early creation of the solar system. Momentum must be managed to ensure the spacecraft has enough control authority to perform necessary turns and hold a fixed inertial attitude against external torques. Along with torques from solar pressure and gravity-gradients, ion-propulsion engines produce a torque about the thrust axis that must be countered by the four reaction wheel assemblies (RWA). MomProf is a ground operations tool built to address these concerns. The momentum management tool was developed during initial checkout and early cruise, and has been refined to accommodate a wide range of momentum-management issues. With every activity or sequence, wheel speeds and momentum state must be checked to avoid undesirable conditions and use of consumables. MomProf was developed to operate in the MATLAB environment. All data are loaded into MATLAB as a structure to provide consistent access to all inputs by individual functions within the tool. Used in its most basic application, the Dawn momentum tool uses the basic principle of angular momentum conservation, computing momentum in the body frame, and RWA wheel speeds, for all given orientations in the input file. MomProf was designed specifically to be able to handle the changing external torques and frequent de - saturations. Incorporating significant external torques adds complexity since there are various external torques that act under different operational modes.

Swenka, Edward R.↗
NASA NTRS2017

Collaborative Data Publication Utilizing the Open Data Repository's (ODR) Data Publisher

Introduction: For small communities in diverse fields such as astrobiology, publishing and sharing data can be a difficult challenge. While large, homogenous fields often have repositories and existing data standards, small groups of independent researchers have few options for publishing standards and data that can be utilized within their community. In conjunction with teams at NASA Ames and the University of Arizona, the Open Data Repository's (ODR) Data Publisher has been conducting ongoing pilots to assess the needs of diverse research groups and to develop software to allow them to publish and share their data collaboratively. Objectives: The ODR's Data Publisher aims to provide an easy-to-use and implement software tool that will allow researchers to create and publish database templates and related data. The end product will facilitate both human-readable interfaces (web-based with embedded images, files, and charts) and machine-readable interfaces utilizing semantic standards. Characteristics: The Data Publisher software runs on the standard LAMP (Linux, Apache, MySQL, PHP) stack to provide the widest server base available. The software is based on Symfony (www.symfony.com) which provides a robust framework for creating extensible, object-oriented software in PHP. The software interface consists of a template designer where individual or master database templates can be created. A master database template can be shared by many researchers to provide a common metadata standard that will set a compatibility standard for all derivative databases. Individual researchers can then extend their instance of the template with custom fields, file storage, or visualizations that may be unique to their studies. This allows groups to create compatible databases for data discovery and sharing purposes while still providing the flexibility needed to meet the needs of scientists in rapidly evolving areas of research. Research: As part of this effort, a number of ongoing pilot and test projects are currently in progress. The Astrobiology Habitable Environments Database Working Group is developing a shared database standard using the ODR's Data Publisher and has a number of example databases where astrobiology data are shared. Soon these databases will be integrated via the template-based standard. Work with this group helps determine what data researchers in these diverse fields need to share and archive. Additionally, this pilot helps determine what standards are viable for sharing these types of data from internally developed standards to existing open standards such as the Dublin Core (http://dublincore.org) and Darwin Core (http://rs.twdg.org) metadata standards. Further studies are ongoing with the University of Arizona Department of Geosciences where a number of mineralogy databases are being constructed within the ODR Data Publisher system. Conclusions: Through the ongoing pilots and discussions with individual researchers and small research teams, a definition of the tools desired by these groups is coming into focus. As the software development moves forward, the goal is to meet the publication and collaboration needs of these scientists in an unobtrusive and functional way.

easy to use and implement software tool↗
NASA NTRSDate not supplied

Increasing Discovery and Usability of Earth Science Satellite Data with My NASA Data

For 20 years, the My NASA Data project at NASA Langley Research Center has developed innovative approaches to increase the use of NASA’s satellite data by learners. My NASA Data offers a variety of authentic Earth Science datasets and a data visualization tool, eliminating the need for educators and/or learners to obtain specialized knowledge of GIS data formats and software to access and use authentic Earth Science data. While there is no shortage of available data, as federal government agencies such as NASA house petabytes of freely accessible Earth Science datasets, much of the data are only available for download and visualization in specialized formats and software, limiting their accessibility to educators and learners, especially those in primary and secondary school. Using the Google Earth Engine platform, the My NASA Data team has recently reinvented their data visualization tool, called the Earth System Data Explorer (ESDE). The ESDE gives users the capability to explore over 60 Earth Science satellite datasets in a multitude of formats such as maps, graphs, and data table Its new and improved user interface design was developed based on the preferences of educators, whom the My NASA Data project has over 20 years’ experience working with. Earth Science and GIS Subject Matter Experts (SMEs) structured the data in a professional and scientific manner. During Fiscal Year 2023, the My NASA Data website received over 1 million digital engagements, with over one-third being visitors to the data visualization tool. These metrics highlight the interest in a visualization tool that is simple and free to use with reliable and trusted datasets. The ESDE empowers users to readily relate and analyze NASA Earth Science data within their area of interest. The team used a user-centered design (UCD) framework to receive and incorporate feedback into the application’s design. Core requested features include the ability to create time series graphs, comparative analysis of maps, and download the data as CSV file. Responses indicate that advances in data visualization tools such as the ESDE make authentic Earth Science data more accessible. This presentation will cover how the My NASA Data project develops tools to enhance data discovery and accessibility, as well as how SME and user suggestions are incorporated.

Desiray Wilson↗
NASA NTRS2000

Structural Modeling Using "Scanning and Mapping" Technique

Supported by NASA Glenn Center, we are in the process developing a structural damage diagnostic and monitoring system for rocket engines, which consists of five modules: Structural Modeling, Measurement Data Pre-Processor, Structural System Identification, Damage Detection Criterion, and Computer Visualization. The function of the system is to detect damage as it is incurred by the engine structures. The scientific principle to identify damage is to utilize the changes in the vibrational properties between the pre-damaged and post-damaged structures. The vibrational properties of the pre-damaged structure can be obtained based on an analytic computer model of the structure. Thus, as the first stage of the whole research plan, we currently focus on the first module - Structural Modeling. Three computer software packages are selected, and will be integrated for this purpose. They are PhotoModeler-Pro, AutoCAD-R14, and MSC/NASTRAN. AutoCAD is the most popular PC-CAD system currently available in the market. For our purpose, it plays like an interface to generate structural models of any particular engine parts or assembly, which is then passed to MSC/NASTRAN for extracting structural dynamic properties. Although AutoCAD is a powerful structural modeling tool, the complexity of engine components requires a further improvement in structural modeling techniques. We are working on a so-called "scanning and mapping" technique, which is a relatively new technique. The basic idea is to producing a full and accurate 3D structural model by tracing on multiple overlapping photographs taken from different angles. There is no need to input point positions, angles, distances or axes. Photographs can be taken by any types of cameras with different lenses. With the integration of such a modeling technique, the capability of structural modeling will be enhanced. The prototypes of any complex structural components will be produced by PhotoModeler first based on existing similar components, then passed to AutoCAD for modification and correction of any discrepancies seen in the Photomodeler version of the 3Dmodel. These three software packages are fully compatible. The DXF file can be used to transfer drawings among those packages. To begin this entire process, we are using a small replica of an actual engine blade as a test object. This paper introduces the accomplishment of our recent work.

Amos, Courtney L.↗
NASA NTRS2019

Benefits and Challenges of Model-based Software Engineering: Lessons Learned based on Qualitative and Quantitative Findings

Even though Model-based Software Engineering (MBSwE) techniques and Autogenerated Code (AGC) have been increasingly used to produce complex software systems, there is only anecdotal knowledge about the state-of-thepractice. Furthermore, there is a lack of empirical studies that explore the potential quality improvements due to the use of these techniques. This paper presents in-depth qualitative findings about development and Software Assurance (SWA) practices and detailed quantitative analysis of software bug reports of a NASA mission that used MBSwE and AGC. The mission’s flight software is a combination of handwritten code and AGC developed by two different approaches: one based on state chart models (AGC-M) and another on specification dictionaries (AGC-D). The empirical analysis of fault proneness is based on 380 closed bug reports created by software developers. Our main findings include: (1) MBSwE and AGC provide some benefits, but also impose challenges. (2) SWA done only at a model level is not sufficient. AGC code should also be tested and the models and AGC should always be kept in-sync. AGC must not be changed manually. (3) Fixes made to address an individual bug report were spread both across multiple modules and across multiple files. On average, for each bug report 1.4 modules, that is, 3.4 files were fixed. (4) Most bug reports led to changes in more than one type of file. The majority of changes to auto-generated source code files were made in conjunction to changes in either file with state chart models or XML files derived from dictionaries. (5) For newly developed files, AGC-M and handwritten code were of similar quality, while AGC-D files were the least fault prone.

Goseva-Popstojanova, Katerina↗
NASA NTRS2001

Using Automation to Improve the Flight Software Testing Process

One of the critical phases in the development of a spacecraft attitude control system (ACS) is the testing of its flight software. The testing (and test verification) of ACS flight software requires a mix of skills involving software, knowledge of attitude control, and attitude control hardware, data manipulation, and analysis. The process of analyzing and verifying flight software test results often creates a bottleneck which dictates the speed at which flight software verification can be conducted. In the development of the Microwave Anisotropy Probe (MAP) spacecraft ACS subsystem, an integrated design environment was used that included a MAP high fidelity (HiFi) simulation, a central database of spacecraft parameters, a script language for numeric and string processing, and plotting capability. In this integrated environment, it was possible to automate many of the steps involved in flight software testing, making the entire process more efficient and thorough than on previous missions. In this paper, we will compare the testing process used on MAP to that used on other missions. The software tools that were developed to automate testing and test verification will be discussed, including the ability to import and process test data, synchronize test data and automatically generate HiFi script files used for test verification, and an automated capability for generating comparison plots. A summary of the benefits of applying these test methods on MAP will be given. Finally, the paper will conclude with a discussion of re-use of the tools and techniques presented, and the ongoing effort to apply them to flight software testing of the Triana spacecraft ACS subsystem.

ODonnell, James R., Jr.↗
NASA NTRS2003

Functional Flight Test Report for Positive Systems' ADAR System 5500 Sensor SN8 Linear

This report describes results of the functional flight test conducted with the Positive Systems' ADAR 5500 sensor system (serial number 8, linear configuration) near Winslow, Arizona on June 30 and July 1, 1999. The in-flight test is one component of the NASA Scientific Data Purchase (SDP) Validation and Verification (V&V) process. It allows to measure characteristics of the entire sensor system affected by both performance of the sensor during a flight and post-flight image processing. The following characteristics were analyzed: changes of dark digital numbers (DN's), radiometric linearity, signal-to-noise ratio (SNR), spatial resolution, and geolocation accuracy. The measured characteristics were compared with the image product specifications defined in the Positive Systems' SDP contract. Dependence of the dark DN's on several factors was analyzed, but no significant correlation was found. However, the observed changes in dark DN's were relatively small, which justifies usage of a constant value in the dark DN subtraction procedure during post-processing. Dependence of measured at-sensor, in-band radiance (in arbitrary units) on measured in-band ground reflectance is very well described by a linear function - The sensor fulfills the linearity requirement. Measured SNR values lower than the contract specifications, but accuracy of that test was possibly affected by non-uniformity of the employed gray-scale panels. The SNR values are generally sufficiently high for most applications. SNR can also be improved during standard flights by using longer exposure times. Full width at half maximum (FWHM) of an edge response derived line spread function was used as a measure of spatial resolution. FWHM was generally smaller than twice the ground sample distance (GSD), in agreement with the contract specifications. Accuracy of the geolocation information, which is provided for the particular images in a metadata file, was found to meet contract requirements as well.

Stanley, Tom↗
NASA NTRS2009

The Transition of High-Resolution NASA MODIS Sea Surface Temperatures into the WRF Environmental Modeling System

The NASA Short-term Prediction Research and Transition (SPoRT) Center has developed a Moderate Resolution Imaging Spectroradiometer (MODIS) sea surface temperature (SST) composite at 2-km resolution that has been implemented in version 3 of the National Weather Service (NWS) Weather Research and Forecasting (WRF) Environmental Modeling System (EMS). The WRF EMS is a complete, full physics numerical weather prediction package that incorporates dynamical cores from both the Advanced Research WRF (ARW) and the Non-hydrostatic Mesoscale Model (NMM). The installation, configuration, and execution of either the ARW or NMM models is greatly simplified by the WRF EMS to encourage its use by NWS Weather Forecast Offices (WFOs) and the university community. The WRF EMS is easy to run on most Linux workstations and clusters without the need for compilers. Version 3 of the WRF EMS contains the most recent public release of the WRF-NMM and ARW modeling system (version 3 of the ARW is described in Skamarock et al. 2008), the WRF Pre-processing System (WPS) utilities, and the WRF Post-Processing program. The system is developed and maintained by the NWS National Science Operations Officer Science and Training Resource Coordinator. To initialize the WRF EMS with high-resolution MODIS SSTs, SPoRT developed the composite product consisting of MODIS SSTs over oceans and large lakes with the NCEP Real-Time Global (RTG) filling data over land points. Filling the land points is required due to minor inconsistencies between the WRF land-sea mask and that used to generate the MODIS SST composites. This methodology ensures a continuous field that adequately initializes all appropriate arrays in WRF. MODIS composites covering the Gulf of Mexico, western Atlantic Ocean and the Caribbean are generated daily at 0400, 0700, 1600, and 1900 UTC corresponding to overpass times of the NASA Aqua and Terra polar orbiting satellites. The MODIS SST product is output in gridded binary-1 (GRIB-1) data format for a seamless incorporation into WRF via the WPS utilities. The full-resolution, 1-km MODIS product is sub-sampled to 2-km grid spacing due to limitations in handling very large dimensions in the GRIB-1 data format. The GRIB-1 files are posted online at ftp://ftp.nsstc.org/sstcomp/WRF/, which is directly accessed by the WRF EMS scripts. The MODIS SST composites are also downloaded to the EMS data server, which is accessible by the WRF EMS users and NWS WFOs. The SPoRT MODIS SST composite provides the model with superior detail of the ocean gradients around Florida and surrounding waters, whereas the operational RTG SST typically depicts a relatively smooth field and is not able to capture sharp horizontal gradients in SST. Differences of 2-3 C are common over small horizontal distances, leading to enhanced SST gradients on either side of the Gulf Stream and along the edges of the cooler shelf waters. These sharper gradients can in turn produce atmospheric responses in simulated temperature and wind fields as depicted in LaCasse et al. Differences in atmospheric verification statistics over a several month study were generally small in the vicinity of south Florida; however, the validation of SSTs at specific buoy locations revealed important improvements in the biases and RMS errors, especially in the vicinity of the cooler shelf waters off the east-central Florida coast. A current weakness in the MODIS SST product is the occurrence of occasional discontinuities caused by high latency in SST coverage due to persistent cloud cover. An enhanced method developed by Jedlovec et al. (2009, GHRSST User Symposium) reduces the occurrence of these problems by adding Advanced Microwave Scanning Radiometer -- EOS (AMSR-E) SST data to the compositing process. Enhanced SST composites are produced over the ocean regions surrounding the Continental U.S. at four times each day corresponding to Terra and Aqua equator crossing times. For a given day and overpass time, both MODInd AMSR-E data from the previous seven days form a collection used in the compositing. At each MODIS pixel, cloud-free SST values from the collection are used to form a weighted average based on their latency (number of days from the current day). In this way, recent SST data are given more weight than older data. One of the primary issues involved in incorporating the AMSR-E microwave data in the composites is the tradeoff between the decreased spatial resolution of the AMSR-E data (25 km) and the increased coverage due to its near all-weather capability. Currently, the AMSR-E is given a weight of 20% compared to MODIS data, thereby preserving the spatial structure observed in the MODIS data. Day-time (night-time) AMSR-E SST data from Aqua are used with both Terra and Aqua MODIS day-time (night-time) SST data sets.

Case, Jonathan L.↗
NASA NTRS2005

Generic Kalman Filter Software

The Generic Kalman Filter (GKF) software provides a standard basis for the development of application-specific Kalman-filter programs. Historically, Kalman filters have been implemented by customized programs that must be written, coded, and debugged anew for each unique application, then tested and tuned with simulated or actual measurement data. Total development times for typical Kalman-filter application programs have ranged from months to weeks. The GKF software can simplify the development process and reduce the development time by eliminating the need to re-create the fundamental implementation of the Kalman filter for each new application. The GKF software is written in the ANSI C programming language. It contains a generic Kalman-filter-development directory that, in turn, contains a code for a generic Kalman filter function; more specifically, it contains a generically designed and generically coded implementation of linear, linearized, and extended Kalman filtering algorithms, including algorithms for state- and covariance-update and -propagation functions. The mathematical theory that underlies the algorithms is well known and has been reported extensively in the open technical literature. Also contained in the directory are a header file that defines generic Kalman-filter data structures and prototype functions and template versions of application-specific subfunction and calling navigation/estimation routine code and headers. Once the user has provided a calling routine and the required application-specific subfunctions, the application-specific Kalman-filter software can be compiled and executed immediately. During execution, the generic Kalman-filter function is called from a higher-level navigation or estimation routine that preprocesses measurement data and post-processes output data. The generic Kalman-filter function uses the aforementioned data structures and five implementation- specific subfunctions, which have been developed by the user on the basis of the aforementioned templates. The GKF software can be used to develop many different types of unfactorized Kalman filters. A developer can choose to implement either a linearized or an extended Kalman filter algorithm, without having to modify the GKF software. Control dynamics can be taken into account or neglected in the filter-dynamics model. Filter programs developed by use of the GKF software can be made to propagate equations of motion for linear or nonlinear dynamical systems that are deterministic or stochastic. In addition, filter programs can be made to operate in user-selectable "covariance analysis" and "propagation-only" modes that are useful in design and development stages.

Lisano, Michael E., II↗
NASA NTRS2005

Integration of Launch Vehicle Simulation/Analysis Tools and Lunar Cargo Lander Design

Simulation and analysis of vehicle performance is essential for design of a new launch vehicle system. It is more and more demand to have an integrated, highly efficient, robust simulation tool with graphical user interface (GUI) for vehicle performance and simulations. The objectives of this project are to integrate and develop launch vehicle simulation and analysis tools in MATLAB/Simulink under PC Platform, to develop a vehicle capable of being launched on a Delta-IV Heavy Launch Vehicle which can land on the moon with the goal of pre-implanting cargo for a new lunar mission, also with the capability of selecting other launch vehicles that are capable of inserting a payload into Trans-Lunar Injection (TLI). The vehicle flight simulation software, MAVERIC-II (Marshall Aerospace VEhicle Representation In 'C'), developed by Marshall Space Flight Center was selected as a starting point for integration of simulation/analysis tools. The goals are to convert MAVERIC-II from UNIX to PC platform and build input/output GUI s in the MATLAB environment, and then integrate them under MATLAB/Simulink with other modules. Currently, MAVERIC-II has been successfully converted from UNIX to PC using Microsoft Services for UNIX subsystem on PC. Input/Output GUI's have been done for some key input/output files. Calling MAVERIC-II from Simulink has been tested. Details regarding Lunar Cargo Lander Design are described in Part 2/2 of the paper on page X-1.

Shiue, Yeu-Sheng Paul↗
NASA NTRSDate not supplied

MISR Level 2 Aerosol parameters (MIL2ASAE_V1)

The Aerosol data contain aerosol optical depth, aerosol physical model, ancillary meteorological data, and related parameters. The aerosol data include tropospheric aerosol optical depth, Angstrom exponent and single scattering albedo on 17.6 km centers, aerosol mixture identifier and retrieval residuals, and ancillary data including assumed ozone optical depth and retrieval flags. For complete information about the aerosol mixtures, the user will need to order the MISR Aerosol Climatology Product (MIANACP) to obtain Aerosol Physical and Optical Properties (APOP) and the Mixture files. The Mixture files list up to 3 component models used in each mixture, with their relative compositional fractions, and includes ancillary information such as single scattering albedo. The APOP gives detailed information for the component particle models. [Location=GLOBAL] [Temporal_Coverage: Start_Date=2000-02-24; Stop_Date=] [Spatial_Coverage: Southernmost_Latitude=-90; Northernmost_Latitude=90; Westernmost_Longitude=-180; Easternmost_Longitude=180] [Data_Resolution: Latitude_Resolution=1.1 km - 17.6 km; Longitude_Resolution=1.1 km - 17.6 km; Horizontal_Resolution_Range=1 km - < 10 km or approximately .01 degree - < .09 degree; Temporal_Resolution=about 15 orbits/day].

CIRRUS OPTICAL DEPTH↗
NASA NTRS1992

Ultrasoft x ray bursts: A clue to the origin of gamma ray bursts?

A search was conducted for short timescale (less than or approx. 10 s) faint X ray bursts in the complete 201,000,000 photon Einstein Observatory imaging proportional counter (IPC) data base. Some 73,000,000 events were extracted which were distributed among 11,230 observing intervals with an average observing time of approx. 1400 seconds. To exclude all sources, only those spatial pixels were searched with a count rate less than 6 x 10(exp -4) counts/sec sq arcmin. The mean count rate was much less. All files with less than 400 secs of observing time were excluded. The data was then binned into overlapping cells 4'.3 by 4'.3 by 10 secs in volume, and all the space-time cells were searched to locate cells with more than 5 counts in a 10 sec interval; i.e., a minimum flux enhancement of 50 over the mean rate for that point in space. Some 52 such events were found. An annulus was inspected around the event to see if it coincided with a general rise in the counter's event rate. Ten events did coincide with counter phenomena; these were associated with sunrise, sunset, or the approach of the South Atlantic Anomaly and were excluded. The remaining 42 events were then examined in an attempt to associate them with instrumental or environmental artifacts. The event occurrence times are uniformly distributed over the course of the mission and show no correlation with local solar time; their positions are randomly distributed in geographic, Galactic, and celestial coordinates. Their summed radial distribution is consistent with the point response function of the IPC for a soft source, indicating that the events are focused by the Observatory's mirror system. The integrated spectrum is, indeed, quite soft and is very similar to that of the cataclysmic variable star U Gem in outburst. Most of the events have risetimes of less than or approx. 1 sec and decay times ranging from 1 to 20 sec. Their positions are not associated with any class of catalogued objects. Several possible origins are discussed for the events; if they are associated with gamma ray bursters, they provide interesting constraints on the space density and repetition rate of the underlying source population.

Helfand, D. J.↗
NASA NTRSDate not supplied

Quality Control Methods of Tower Data at Kennedy Space Center’s Launch Complex 39-B and the USAF Cape Canaveral 500 Foot Tower

The National Aeronautics and Space Administration (NASA) has long used meteorological data from weather towers located at Kennedy Space Center (KSC) and the United States Air Force’s Eastern Range(ER) in support of their various launch vehicles and climate studies. Some of the most valuable data is gathered at the Launch Complex 39-B (LC39-B) and the 500 foot tower located approximately two miles west of LC39-B and three miles north of the Vehicle Assembly Building (VAB). The data from LC39-B gives NASA Space Launch System (SLS) engineers valuable insight into the weather the vehicle can expect at the pad, while the 500 foot tower has a longer period of record and has been used by the Shuttle and SLS programs. However, numerous data quality (DQ) control issues have arisen when utilizing this data for analysis. In addition, instrumentation tends to deteriorate faster than normal due to the corrosive nature of the high salt content in the air. NASA’s Natural Environments branch has developed several QC databases of these towers, but these studies were for fixed periods of records. EV44 identified a need for a continually updated and QC’ed database of tower data not only to provide along term QC’ed database for vehicle and climate analyses, but also to provide the capability to investigate recent weather events such as downbursts and other high wind events. This study follows the methods developed in prior Natural Environment QC tower databases, which includes variable specific QC thresholds and checks used to generate QC flags. However, this study developed new techniques such as the development and design of the graphical user interface (GUI) for manual verification, and the creation of the final monthly QC files.

Quality Control↗
NASA NTRS2018

Command and Control Software Development

As NASA’s role in spaceflight operations change, so too does its design priorities. NASA’s flagship venture, the Space Launch System (SLS), is being created primarily to explore deep space. While commercial partners conduct low Earth orbit resupplies, tests, and even transportation of astronauts, NASA can divert more resources to more exciting projects - going back to the moon, or onwards to Mars. In the short term, this goal manifests in the upcoming Exploration Mission-1 (EM-1) test of the SLS, slated for as early as 2019. SLS, with the Orion capsule, will travel farther than any human-rated spacecraft has gone before. As the most powerful launch vehicle ever created, SLS requires many new innovations to ensure mission success. One such technology is the launch control software, which is the focus of this internship. The SLS launch control software is composed of many functions, all of which require rigorous testing to meet the standard of life-critical code. To facilitate easier testing, the first project I undertook was to customize the open-source tool Wireshark to the software team’s needs. Wireshark is a network protocol analyzer that can take in information about custom information packets. The launch control software will have several protocols that are custom to NASA. I ensured that all necessary component files were the correct file type and in the correct structure for Wireshark to compile. Having allowed Wireshark access to understand custom NASA data packets, testers of the launch control software will be able to find anomalies easier.

Wang, Zhengdong↗
NASA NTRSDate not supplied

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗
NASA NTRS2005

Java-based Graphical User Interface for MAVERIC-II

A computer program entitled "Marshall Aerospace Vehicle Representation in C II, (MAVERIC-II)" is a vehicle flight simulation program written primarily in the C programming language. It is written by James W. McCarter at NASA/Marshall Space Flight Center. The goal of the MAVERIC-II development effort is to provide a simulation tool that facilitates the rapid development of high-fidelity flight simulations for launch, orbital, and reentry vehicles of any user-defined configuration for all phases of flight. MAVERIC-II has been found invaluable in performing flight simulations for various Space Transportation Systems. The flexibility provided by MAVERIC-II has allowed several different launch vehicles, including the Saturn V, a Space Launch Initiative Two-Stage-to-Orbit concept and a Shuttle-derived launch vehicle, to be simulated during ascent and portions of on-orbit flight in an extremely efficient manner. It was found that MAVERIC-II provided the high fidelity vehicle and flight environment models as well as the program modularity to allow efficient integration, modification and testing of advanced guidance and control algorithms. In addition to serving as an analysis tool for techno logy development, many researchers have found MAVERIC-II to be an efficient, powerful analysis tool that evaluates guidance, navigation, and control designs, vehicle robustness, and requirements. MAVERIC-II is currently designed to execute in a UNIX environment. The input to the program is composed of three segments: 1) the vehicle models such as propulsion, aerodynamics, and guidance, navigation, and control 2) the environment models such as atmosphere and gravity, and 3) a simulation framework which is responsible for executing the vehicle and environment models and propagating the vehicle s states forward in time and handling user input/output. MAVERIC users prepare data files for the above models and run the simulation program. They can see the output on screen and/or store in files and examine the output data later. Users can also view the output stored in output files by calling a plotting program such as gnuplot. A typical scenario of the use of MAVERIC consists of three-steps; editing existing input data files, running MAVERIC, and plotting output results.

Seo, Suk Jai↗
NASA NTRS2023

Aero-Engines AI - A Machine-Learning App for Aircraft Engine Concepts Assessment

Effective deployment of machine-learning (ML) models could drive a high level of efficiency in aircraft engine conceptual design. Aero-Engines AI is a user-friendly app that has been created to deploy trained machine-learning (ML) models to assess aircraft engine concepts. It was created using tkinter, a GUI (graphical user interface) module that is built into the standard Python library. Employing tkinter greatly facilitates the sharing of ML application as an executable file which can be run on Windows machines (without the need to have Python or any library installed). The app gets user input for a turbofan design, preprocesses the input data, and deploys trained ML models to predict turbofan thrust specific fuel consumption (TSFC), engine weight, core size, and turbomachinery stage-counts. The ML predictive models were built by employing supervised deep-learning and K-nearest neighbor regression algorithms to study patterns in an existing open-source database of production and research turbofan engines. They were trained, cross-validated, and tested in Keras, an open-source neural networks API (application programming interface) written in Python, with TensorFlow (Google open-source artificial intelligence library) serving as the backend engine. The smooth deployment of these ML models using the app shows that Aero-Engines AI is an easy-touse and a time-saving tool for aircraft engine design-space exploration during the conceptual design stage. Current version of the app focuses on the performance prediction of conventional turbofans. However, the scope of the app can easily be easily expanded to include other engine types (such as turboshaft and hybrid-electric systems) after their ML models are developed. Overall, the use of a machine-learning app for aircraft engine concept assessment represents a promising area of development in aircraft engine conceptual design.

machine learning↗