SEARCH · Engineering Papers

Results for “modularization framework”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

186 records · Page 11

All sources NASA NTRS DOE OSTI

NASA NTRSDate not supplied

Classification of Notices to Airmen using Natural Language Processing

This paper establishes the feasibility of using Natural Language Processing (NLP) to classify NOTAMs or Notices to Airmen – a pilot messaging framework to gather real-time situational awareness. Present day air mobility operations heavily rely on NOTAMs. However, pilots often have difficulty interpreting NOTAMs due to the sheer volume of inapplicable messages and unclear abbreviations. Using NLP, the presented study analyzes the accuracy of classifying NOTAMs and, thereby, the efficiency of generating actionable interpretations in real time. To this effect, efficacies of four NLP neural network architectures were analyzed, including three Recurrent Neural Networks (RNNs) with GloVe, Word2Vec, and FastText word embeddings, and one trained Bi-Directional Encoder Representations from Transformers (BERT) model. The four neural networks were trained and evaluated on three open-source datasets of varying text lengths, vocabularies, and grammars, taken from e-commerce product descriptions, social media tweets, and unstructured descriptions for data and analytics services on open data marketplaces such as NASA’s Data and Reasoning Fabric (DRF) platform. This provided cross-analysis of each neural network architecture’s performance per text type. The best performing architecture, BERT, was then fine-tuned on a collection of open-source NOTAM data. Post-training, a real-time NOTAM classification service was implemented to draw inference on new NOTAMs using the trained model, which demonstrated close to 99% accuracy in classification. This modular classification service is envisioned to be integrated with a data and analytics delivery platform, such as the DRF, thus availing real-time contextualization of NOTAMs to air mobility clients, humans, and machines for enhanced decision making.

Aiden C. Szeto↗

NASA NTRSDate not supplied

Classification of Notices to Airmen using Natural Language Processing

Aiden Szeto↗

NASA NTRS1996

An Open Computing Infrastructure that Facilitates Integrated Product and Process Development from a Decision-Based Perspective

Computer applications for design have evolved rapidly over the past several decades, and significant payoffs are being achieved by organizations through reductions in design cycle times. These applications are overwhelmed by the requirements imposed during complex, open engineering systems design. Organizations are faced with a number of different methodologies, numerous legacy disciplinary tools, and a very large amount of data. Yet they are also faced with few interdisciplinary tools for design collaboration or methods for achieving the revolutionary product designs required to maintain a competitive advantage in the future. These organizations are looking for a software infrastructure that integrates current corporate design practices with newer simulation and solution techniques. Such an infrastructure must be robust to changes in both corporate needs and enabling technologies. In addition, this infrastructure must be user-friendly, modular and scalable. This need is the motivation for the research described in this dissertation. The research is focused on the development of an open computing infrastructure that facilitates product and process design. In addition, this research explicitly deals with human interactions during design through a model that focuses on the role of a designer as that of decision-maker. The research perspective here is taken from that of design as a discipline with a focus on Decision-Based Design, Theory of Languages, Information Science, and Integration Technology. Given this background, a Model of IPPD is developed and implemented along the lines of a traditional experimental procedure: with the steps of establishing context, formalizing a theory, building an apparatus, conducting an experiment, reviewing results, and providing recommendations. Based on this Model, Design Processes and Specification can be explored in a structured and implementable architecture. An architecture for exploring design called DREAMS (Developing Robust Engineering Analysis Models and Specifications) has been developed which supports the activities of both meta-design and actual design execution. This is accomplished through a systematic process which is comprised of the stages of Formulation, Translation, and Evaluation. During this process, elements from a Design Specification are integrated into Design Processes. In addition, a software infrastructure was developed and is called IMAGE (Intelligent Multidisciplinary Aircraft Generation Environment). This represents a virtual apparatus in the Design Experiment conducted in this research. IMAGE is an innovative architecture because it explicitly supports design-related activities. This is accomplished through a GUI driven and Agent-based implementation of DREAMS. A HSCT design has been adopted from the Framework for Interdisciplinary Design Optimization (FIDO) and is implemented in IMAGE. This problem shows how Design Processes and Specification interact in a design system. In addition, the problem utilizes two different solution models concurrently: optimal and satisfying. The satisfying model allows for more design flexibility and allows a designer to maintain design freedom. As a result of following this experimental procedure, this infrastructure is an open system that it is robust to changes in both corporate needs and computer technologies. The development of this infrastructure leads to a number of significant intellectual contributions: 1) A new approach to implementing IPPD with the aid of a computer; 2) A formal Design Experiment; 3) A combined Process and Specification architecture that is language-based; 4) An infrastructure for exploring design; 5) An integration strategy for implementing computer resources; and 6) A seamless modeling language. The need for these contributions is emphasized by the demand by industry and government agencies for the development of these technologies.

Hale, Mark A.↗

NASA NTRS2007

Reducing the Risk of Human Missions to Mars Through Testing

During the summer of 2002 the NASA Deputy Administrator charted an internal NASA planning group to develop the rationale for exploration beyond low-Earth orbit. This team, termed the Exploration Blueprint, performed architecture analyses to develop roadmaps for how to accomplish the first steps beyond Low-Earth Orbit through the human exploration of Mars. The previous NASA Exploration Team (NEXT) activities laid the foundation and framework for development of NASA s Integrated Space Plan. The reference missions resulting from the analysis performed by the Exploration Blueprint team formed the basis for requirement definition, systems development, technology roadmapping, and risk assessments for future human exploration beyond low-Earth orbit. Emphasis was placed on developing recommendations on what could be done now to effect future exploration activities. The Exploration Blueprint team embraced the Stepping Stone approach to exploration where human and robotic activities are conducted through progressive expansion outward beyond low- Earth orbit. Results from this study produced a long-term strategy for exploration with near-term implementation plans, program recommendations, and technology investments. Specific results included the development of a common exploration crew vehicle concept, a unified space nuclear strategy, focused bioastronautics research objectives, and an integrated human and robotic exploration strategy. Recommendations from the Exploration Blueprint included the endorsement of the Nuclear Systems Initiative, augmentation of the bioastronautics research, a focused space transportation program including heavy-lift launch and a common exploration vehicle design for ISS and exploration missions, as well as an integrated human and robotic exploration strategy for Mars. Following the results of the Exploration Blueprint study, the NASA Administrator has asked for a recommendation by June, 2003 on the next steps in human and robotic exploration in order to put into context an updated Integrated Space Transportation Plan (post- Columbia) and guide Agency planning. NASA was on the verge of committing significant funding in programs that would be better served if longer term goals were better known including the Orbital Space Plane, research on the ISS, National Aerospace Initiative, Shuttle Life Extension Program, Project Prometheus, as well as a wide range of technology development throughout the Agency. Much of the focus during this period was on integrating the results from the previous studies into more concrete implementation strategies in order to understand the relationship between NASA programs, timing, and resulting budgetary implications. This resulted in an integrated approach including lunar surface operations to retire risk of human Mars missions, maximum use of common and modular systems including what was termed the exploration transfer vehicle, Earth orbit and lunar surface demonstrations of long-life systems, collaboration of human and robotic missions to vastly increase mission return, and high-efficiency transportation systems (nuclear) for deep-space transportation and power. The data provided in this summary viewgraph presentation was developed to begin to address one of the key elements of the emerging implementation strategy, namely how lunar missions help retire risk of human missions to Mars. During this process the scope of the activity broadened into the issue of how testing in general, in various venues including the Moon, can help reduce the risk for Mars missions.

Drake, Bret G.↗

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 NTRS2009

The Functional Breakdown Structure (FBS) and Its Relationship to Life Cycle Cost

The Functional Breakdown Structure (FBS) is a structured, modular breakdown of every function that must be addressed to perform a generic mission. It is also usable for any subset of the mission. Unlike a Work Breakdown Structure (WBS), the FBS is a function-oriented tree, not a product-oriented tree. The FBS details not products, but operations or activities that should be performed. The FBS is not tied to any particular architectural implementation because it is a listing of the needed functions, not the elements, of the architecture. The FBS for Space Transportation Systems provides a universal hierarchy of required functions, which include ground and space operations as well as infrastructure - it provides total visibility of the entire mission. By approaching the systems engineering problem from the functional view, instead of the element or hardware view, the SPST has created an exhaustive list of potential requirements which the architecture designers can use to evaluate the completeness of their designs. This is a new approach that will provide full accountability of all functions required to perform the planned mission. It serves as a giant check list to be sure that no functions are omitted, especially in the early architectural design phase. A significant characteristic of a FBS is that if architecture options are compared using this approach, then any missing or redundant elements of each option will be ' identified. Consequently, valid Life Cycle Costs (LCC) comparisons can be made. For example, one architecture option might not need a particular function while another option does. One option may have individual elements to perform each of three functions while another option needs only one element to perform the three functions. Once an architecture has been selected, the FBS will serve as a guide in development of the work breakdown structure, provide visibility of those technologies that need to be further developed to perform required functions, and help identify the personnel skills required to develop and operate the architecture. It also wifi allow the systems engineering activities to totally integrate each discipline to the maximum extent possible and optimize at the total system level, thus avoiding optimizing at the element level (stove-piping). In addition, it furnishes a framework that wifi help prevent over or under specifying requirements because all functions are identified and all elements are aligned to functions.

DeHoff, Bryan↗