Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Task Graph”

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 109 records · Page 6

Generic POCC architecture: Revised recommended refinements and object-oriented interfaces

This document is a sequel to the report entitled Generic POCC Architectures, dated April 5, 1989, prepared by CTA under Contract NAS5-31500, Task 28-11600. That document presented a generic architecture based upon current technology, and a series of three refinements based on object-oriented analysis principles and expectations for POCC evolution. The current document revisits the object-oriented analysis of POCC's. We have reassessed the functional groupings that best adhere to object-oriented principles and have revised the recommended architecture accordingly. We present an updated view of the recommended generic POCC architecture using the same graphical models as the previous document: entity-relationship diagrams, dataflow diagrams, and composition graphs. In addition, we present another view in the form of entity-interface diagrams (EID's). EID's may be viewed as a precursor to object diagrams which are the basic construct of the general object-oriented design (GOOD) methodology. The entity-interface diagrams, together with their textual annotations, constitute our specification of object-oriented interfaces in the generic architecture.

Source record↗

Geographic Information Systems and Web Page Development

The Facilities Engineering and Architectural Branch is responsible for the design and maintenance of buildings, laboratories, and civil structures. In order to improve efficiency and quality, the FEAB has dedicated itself to establishing a data infrastructure based on Geographic Information Systems, GIs. The value of GIS was explained in an article dating back to 1980 entitled "Need for a Multipurpose Cadastre which stated, "There is a critical need for a better land-information system in the United States to improve land-conveyance procedures, furnish a basis for equitable taxation, and provide much-needed information for resource management and environmental planning." Scientists and engineers both point to GIS as the solution. What is GIS? According to most text books, Geographic Information Systems is a class of software that stores, manages, and analyzes mapable features on, above, or below the surface of the earth. GIS software is basically database management software to the management of spatial data and information. Simply put, Geographic Information Systems manage, analyze, chart, graph, and map spatial information. At the outset, I was given goals and expectations from my branch and from my mentor with regards to the further implementation of GIs. Those goals are as follows: (1) Continue the development of GIS for the underground structures. (2) Extract and export annotated data from AutoCAD drawing files and construct a database (to serve as a prototype for future work). (3) Examine existing underground record drawings to determine existing and non-existing underground tanks. Once this data was collected and analyzed, I set out on the task of creating a user-friendly database that could be assessed by all members of the branch. It was important that the database be built using programs that most employees already possess, ruling out most AutoCAD-based viewers. Therefore, I set out to create an Access database that translated onto the web using Internet Explorer as the foundation. After some programming, it was possible to view AutoCAD files and other GIS-related applications on Internet Explorer, while providing the user with a variety of editing commands and setting options. I was also given the task of launching a divisional website using Macromedia Flash and other web- development programs.

Reynolds, Justin↗

Real-Time MENTAT programming language and architecture

Real-time MENTAT, a programming environment designed to simplify the task of programming real-time applications in distributed and parallel environments, is described. It is based on the same data-driven computation model and object-oriented programming paradigm as MENTAT. It provides an easy-to-use mechanism to exploit parallelism, language constructs for the expression and enforcement of timing constraints, and run-time support for scheduling and exciting real-time programs. The real-time MENTAT programming language is an extended C++. The extensions are added to facilitate automatic detection of data flow and generation of data flow graphs, to express the timing constraints of individual granules of computation, and to provide scheduling directives for the runtime system. A high-level view of the real-time MENTAT system architecture and programming language constructs is provided.

Grimshaw, Andrew S.↗

The Process of the Development of an Operator

On the job training is where new employees called operators can start gaining knowledge on what they will be working on during their time in JSC. In these lessons I learned different things that are important ranging from thermal systems to electrical systems. While doing OJT classes the student will learn how to use a portable computer system which has displays that I also helped edit and clean up. The way you can also learn is by reading system briefs which describes the different systems. Due to the fact of a possible change in the ISS I updated a systems brief so that it can be relevant to what is actually on the space station. I was given a task that will help develop my skills and make myself better prepared for my future in the work field. The project that I worked on had me pulling real time data from the International Space Station. The Data I obtained from the space station will be correlated to battery performance. The group I will be working which is called REBA and we will take the telemetry and evaluate the data. I will be working with my mentor Ben Chislom and co-op Tyler along with the Pro team. They then will put this data into a graph so that they can get the discrepancies and find a way to improve the battery performance. The first weeks I read familiarization books that informed me how the ISS works, how it was built, and the systems that are used to keep the station working. This project is going to benefit NASA by finding out how electricity is being used on the ISS and enabling us to see how it can be used more efficiently. This way we can operate the ISS without wasting power. While conducting research that goes on inside the space station knowing all electricity is being used efficiently.

Banks, Terrence↗

Data Analysis with Graphical Models: Software Tools

Probabilistic graphical models (directed and undirected Markov fields, and combined in chain graphs) are used widely in expert systems, image processing and other areas as a framework for representing and reasoning with probabilities. They come with corresponding algorithms for performing probabilistic inference. This paper discusses an extension to these models by Spiegelhalter and Gilks, plates, used to graphically model the notion of a sample. This offers a graphical specification language for representing data analysis problems. When combined with general methods for statistical inference, this also offers a unifying framework for prototyping and/or generating data analysis algorithms from graphical specifications. This paper outlines the framework and then presents some basic tools for the task: a graphical version of the Pitman-Koopman Theorem for the exponential family, problem decomposition, and the calculation of exact Bayes factors. Other tools already developed, such as automatic differentiation, Gibbs sampling, and use of the EM algorithm, make this a broad basis for the generation of data analysis software.

Buntine, Wray L.↗

Orbital Debris Ontology, Terminology, and Knowledge Modeling

The looming threat orbital debris poses to assets in orbit demands solutions. As the orbital population grows, so does this hazard, but so does the sea of data. The problem is also an opportunity for interdisciplinary innovation and cooperation. This paper focuses on the data and information management aspect of developing solutions for a sustainable and safe orbital space environment. The corresponding author’s in-progress work to develop an orbital debris domain ontology is summarized in order to discuss knowledge modeling for this domain. Methodological approaches of this effort can also contribute to standards efforts and address terminological and policy questions. Leveraging the growing volumes of orbital debris and space situational awareness (SSA) data will create a more complete picture of the orbital space environment. Part of the solution will be: consistent and correct data interpretation, sharing orbital debris and SSA data in one form or another, terminology development & harmonization, and knowledge or domain modeling. To facilitate this, [Rovetto, 2015/16] discussed ontology development for the orbital debris domain. This paper lists concepts from that paper, and subsequently developed concepts [2-9]. Ontology engineering is an interdisciplinary field related to knowledge representation and reasoning in artificial intelligence, semantic technologies and the so-called semantic web. An ontology is effectively a computable and semantically rich terminology that presents a knowledge or domain model for a topic area. Expressions of knowledge or assertions are stored using formally defined term. This knowledge base is reasoned over to yield answers to queries, among other things. Ontologies have been developed in knowledge-based projects across various disciplines, and used for such things as search engines, chatbots, enterprise knowledge graphs, etc. Ontologies support: interoperability, automated reasoning, data sharing and integration, data search and retrieval, and communicating the meaning of data. The Orbital Debris Ontology (ODO), and related ontologies [Rovetto & Kelso 2016] [Rovetto 2016, 2017], were proposed to help achieve this. ODO, for instance, is intended as a domain ontology that can be used across federated databases, offering an explicitly specified set of concepts describing the orbital debris domain. Its meaning-rich taxonomy will provide a sharable semantics for orbital debris data to, in part, consistently communicate the meaning of data to both humans and machines, and tag data elements in space object catalogs to help afford inference tasks, decision support, knowledge discovery, and information integration. ODO and the SSA ontology (SSAO) is part of the overall Orbital Space Domain Ontology concept, which is conceived as a broader domain reference ontology. It aims to provide a knowledge representation structure of the orbital space environment, a common semantic model, and develop a sharable terminology. Collectively this will provide common meaning for datasets, a high-level taxonomy or classification for orbital space objects, and thus means to characterize space objects. Ongoing efforts have included using visualizations, R, JSON-LD, and contemporary semantic technologies. Potential applications and interdisciplinary partnerships include web-based platforms, web apps, visualizations, and academia projects. Community input and participation may yield a more widely understood domain model as well as facilitate terminological standards. For example, the proposed conceptual, terminological and ontological analysis may contribute to such efforts as the Space Debris Mitigation Requirements in the International Standards Organization by developing more precise, consistent and coherent terms and definitions. Projects that seek to develop in-house ontologies can use ODO and related ontologies as domain reference ontologies. This paper was developed independent of author affiliations. Readers are encouraged to contact corresponding author(1) with general interest and potential opportunities to support or realize the described project.

Robert J. Rovetto↗

Wavelet Methods Developed to Detect and Control Compressor Stall

A "wavelet" is, by definition, an amplitude-varying, short waveform with a finite bandwidth (e.g., that shown in the first two graphs). Naturally, wavelets are more effective than the sinusoids of Fourier analysis for matching and reconstructing signal features. In wavelet transformation and inversion, all transient or periodic data features (as in compressor-inlet pressures) can be detected and reconstructed by stretching or contracting a single wavelet to generate the matching building blocks. Consequently, wavelet analysis provides many flexible and effective ways to reduce noise and extract signals which surpass classical techniques - making it very attractive for data analysis, modeling, and active control of stall and surge in high-speed turbojet compressors. Therefore, fast and practical wavelet methods are being developed in-house at the NASA Lewis Research Center to assist in these tasks. This includes establishing user-friendly links between some fundamental wavelet analysis ideas and the classical theories (or practices) of system identification, data analysis, and processing.

Le, Dzu K.↗

Contingency Planning for Planetary Rovers

There has been considerable work in AI on planning under uncertainty. But this work generally assumes an extremely simple model of action that does not consider continuous time and resources. These assumptions are not reasonable for a Mars rover, which must cope with uncertainty about the duration of tasks, the power required, the data storage necessary, along with its position and orientation. In this paper, we outline an approach to generating contingency plans when the sources of uncertainty involve continuous quantities such as time and resources. The approach involves first constructing a "seed" plan, and then incrementally adding contingent branches to this plan in order to improve utility. The challenge is to figure out the best places to insert contingency branches. This requires an estimate of how much utility could be gained by building a contingent branch at any given place in the seed plan. Computing this utility exactly is intractable, but we outline an approximation method that back propagates utility distributions through a graph structure similar to that of a plan graph.

Dearden, Richard↗

Incremental Contingency Planning

There has been considerable work in AI on planning under uncertainty. However, this work generally assumes an extremely simple model of action that does not consider continuous time and resources. These assumptions are not reasonable for a Mars rover, which must cope with uncertainty about the duration of tasks, the energy required, the data storage necessary, and its current position and orientation. In this paper, we outline an approach to generating contingency plans when the sources of uncertainty involve continuous quantities such as time and resources. The approach involves first constructing a "seed" plan, and then incrementally adding contingent branches to this plan in order to improve utility. The challenge is to figure out the best places to insert contingency branches. This requires an estimate of how much utility could be gained by building a contingent branch at any given place in the seed plan. Computing this utility exactly is intractable, but we outline an approximation method that back propagates utility distributions through a graph structure similar to that of a plan graph.

Dearden, Richard↗

Software Development: 3D Animations and Creating User Interfaces for Realistic Simulations

My fall 2015 semester was spent at the Lyndon B. Johnson Space Center working in the Integrated Graphics, Operations, and Analysis Laboratory (IGOAL). My first project was to create a video animation that could tell the story of OMICS. OMICS is a term being used in the field of biomedical science to describe the collective technologies that study biological systems, such as what makes up a cell and how it functions with other systems. In the IGOAL I used a large 23 inch Wacom monitor to draw storyboards, graphics, and line art animations. I used Blender as the 3D environment to sculpt, shape, cut or modify the several scenes and models for the video. A challenge creating this video was to take a term used in biomedical science and describe it in such a way that an 8th grade student can understand. I used a line art style because it would visually set the tone for what we thought was an educational style. In order to get a handle on the perspective and overall feel for the animation without overloading my workspace, I split up the 2 minute animation into several scenes. I used Blender's python scripting capabilities which allowed for the addition of plugins to add or modify tools. The scripts can also directly interact with the objects to create naturalistic patterns or movements. After collecting the rendered scenes, I used Blender's built-in video editing workspace to output the animation. My second project was to write software that emulates a physical system's interface. The interface was to simulate a boat, ROV, and winch system. Simulations are a time and cost effective way to test complicated data and provide training for operators without having to use expensive hardware. We created the virtual controls with 3-D Blender models and 2-D graphics, and then add functionality in C# using the Unity game engine. The Unity engine provides several essential behaviors of a simulator, such as the start and update functions. A framework for Unity, which was developed in the lab, provided a way to place the different widgets on the virtual console dock and have them resize correctly based on the window dimensions.. My task in this project was to create the controls and visualizations for the data coming in from the simulator for the boat portion of the project. I wrote a class for each control window to handle the functionality of that widget. I implemented 11 widgets that make up the ship portion of the simulator. The members of the lab were each masters of their craft and I'm glad I had the opportunity to learn from them. I learned to plan strategically so I could finish this project on time. I allotted time for storyboarding, development, and refinement. In regards to animating I learned to use modifiers like lattice, boolean and build deformers. I also learned how to animate with drivers, how to use the dope sheet, and how to use the graph editor. In coding I learned to limit the chances for bugs by privatizing functions that should be exclusive to their class. I learned how to use the GIT repository to commit, stash and pull the latest build. I learned a bit of everything because I had the chance to see the entire application development process from the artwork, to the implementation.

Gordillo, Orlando Enrique↗

Integrating Human System Information with the Systems Platform for Aggregating and Relating Capabilities (SPARC)

Within Human Health and Performance, there exists a wealth of human system information that’s used a regular basis in support of NASA human exploration objectives, but the challenge is that all of this information was stored in multiple different locations and organized for specific uses, limiting its effectiveness and straining communication across multiple groups. To address this challenge, our project, the Systems Platform for Aggregating and Relating Capabilities (SPARC) was tasked with developing a new NASA internal web application that aggregates and relates multiple programs’ human system products, such as technical standards, program requirements and verifications, human system risks, research and evidence, and exploration capabilities, into one centralized platform that addresses the needs of human health and performance from multiple different perspectives. Using agile development methodologies, user-experience (UX) driven design principles, data visualization, and a strong emphasis on continuous improvement though consistent stakeholder engagement, the SPARC project released a beta version in less than 4 months, broadly launched version 1.0.0 Agency-wide three months after the beta, and has over 180 users in the first year of development. Our second year of development will see us moving from our initial capabilities to increasingly robust and complex integrations and visualizations, including Directed Acyclical Graphs (DAGs), natural language processing (NLP) for dynamic generation of relationships between the sources of truth, and an expansion into hierarchical levels of system design in support of the human exploration programs.

Data science↗

Evaluation of force-torque displays for use with space station telerobotic activities

Recent experiments which addressed Space Station remote manipulation tasks found that tactile force feedback (reflecting forces and torques encountered at the end-effector through the manipulator hand controller) does not improve performance significantly. Subjective response from astronaut and non-astronaut test subjects indicated that force information, provided visually, could be useful. No research exists which specifically investigates methods of presenting force-torque information visually. This experiment was designed to evaluate seven different visual force-torque displays which were found in an informal telephone survey. The displays were prototyped in the HyperCard programming environment. In a within-subjects experiment, 14 subjects nullified forces and torques presented statically, using response buttons located at the bottom of the screen. Dependent measures included questionnaire data, errors, and response time. Subjective data generally demonstrate that subjects rated variations of pseudo-perspective displays consistently better than bar graph and digital displays. Subjects commented that the bar graph and digital displays could be used, but were not compatible with using hand controllers. Quantitative data show similar trends to the subjective data, except that the bar graph and digital displays both provided good performance, perhaps do to the mapping of response buttons to display elements. Results indicate that for this set of displays, the pseudo-perspective displays generally represent a more intuitive format for presenting force-torque information.

Hendrich, Robert C.↗

MoSi2-Base Hybrid Composite Passed Engine Test

The intermetallics compound molybdenum disilicide (MoSi2) is an attractive high-temperature structural material for advanced engine applications. It has excellent oxidation resistance, a high melting point, relatively low density, and high thermal conductivity, and it is easily machined. Past research'at the NASA Lewis Research Center has resulted in the development of a hybrid composite consisting of a MoSi2 matrix reinforced with silicon nitride (Si3N4) Particulate and silicon carbide (SiC) fibers. This composite has demonstrated attractive strength, toughness, thermal fatigue, and oxidation resistance, including resistance to "pest" oxidation. These properties attracted the interest of the Office of Naval Research and Pratt & Whitney, and a joint NASA/Navy/Pratt & Whitney effort was developed to continue to mature the MoSi2 Composite technology. A turbine blade outer air seal, which was part of the Integrated High Performance Turbine Engine Technology (IHPTET) program, was chosen as a first component on which to focus. The first tasks of the materials development effort were to develop improved processing methods to reduce costs and to use fine-diameter fibers that enable the manufacturing of complex shapes. Tape-casting methods were developed to fully infiltrate the fine SiC fibers with matrix powders. The resulting composites were hot pressed to 100-percent density. Composites with cross-plied fiber architectures with 30 vol. % hi-nicalon SiC fibers and 30 vol. % nitride particles are now made routinely and demonstrate a good balance of properties. The next task entailed the measurement of a wide variety of mechanical properties to confirm the suitability of this composite in engines. In particular, participants in this effort demonstrated that composites made with Hi-Nicalon fibers had strength and toughness properties equal to or better than those of the composites made with the large-diameter fibers that had been used previously. Another critically important property measured was impact resistance. Aircraft engine components require sufficient toughness to resist manufacturing defects, assembly damage, stress concentrations at notches, and foreign object damage. Engine company designers indicated that impact resistance would have to be measured before they would seriously consider these types of composites. The Charpy V-notch test was chosen to assess impact resistance, and both monolithic and composite versions Of MOSi2 were tested from -300 to 1400 C. The results (see the following graphs) show that nitride-particulate-reinforced MoSi2 exhibited impact resistance higher than that of many monolithic ceramics and intermetallics, and that the fiber-reinforced composites had even higher values, approaching that of cast superalloys.

Keith, Theo G., Jr.↗

Software Testbed for Developing and Evaluating Integrated Autonomous Subsystems

To implement fault tolerant autonomy in future space systems, it will be necessary to integrate planning, adaptive control, and state estimation subsystems. However, integrating these subsystems is difficult, time-consuming, and error-prone. This paper describes Intelliface/ADAPT, a software testbed that helps researchers develop and test alternative strategies for integrating planning, execution, and diagnosis subsystems more quickly and easily. The testbed's architecture, graphical data displays, and implementations of the integrated subsystems support easy plug and play of alternate components to support research and development in fault-tolerant control of autonomous vehicles and operations support systems. Intelliface/ADAPT controls NASA's Advanced Diagnostics and Prognostics Testbed (ADAPT), which comprises batteries, electrical loads (fans, pumps, and lights), relays, circuit breakers, invertors, and sensors. During plan execution, an experimentor can inject faults into the ADAPT testbed by tripping circuit breakers, changing fan speed settings, and closing valves to restrict fluid flow. The diagnostic subsystem, based on NASA's Hybrid Diagnosis Engine (HyDE), detects and isolates these faults to determine the new state of the plant, ADAPT. Intelliface/ADAPT then updates its model of the ADAPT system's resources and determines whether the current plan can be executed using the reduced resources. If not, the planning subsystem generates a new plan that reschedules tasks, reconfigures ADAPT, and reassigns the use of ADAPT resources as needed to work around the fault. The resource model, planning domain model, and planning goals are expressed using NASA's Action Notation Modeling Language (ANML). Parts of the ANML model are generated automatically, and other parts are constructed by hand using the Planning Model Integrated Development Environment, a visual Eclipse-based IDE that accelerates ANML model development. Because native ANML planners are currently under development and not yet sufficiently capable, the ANML model is translated into the New Domain Definition Language (NDDL) and sent to NASA's EUROPA planning system for plan generation. The adaptive controller executes the new plan, using augmented, hierarchical finite state machines to select and sequence actions based on the state of the ADAPT system. Real-time sensor data, commands, and plans are displayed in information-dense arrays of timelines and graphs that zoom and scroll in unison. A dynamic schematic display uses color to show the real-time fault state and utilization of the system components and resources. An execution manager coordinates the activities of the other subsystems. The subsystems are integrated using the Internet Communications Engine (ICE). an object-oriented toolkit for building distributed applications.

Testbed↗

NASA's Identified Risk of Adverse Outcomes due to Inadequate Human Systems Integration Architecture

The NASA Human System Risk Board (HSRB) is responsible for tracking the evolution of the top ~30 human system risks identified to be associated with human spaceflight. As part of this process, the Board is charged with maintaining a consistent, integrated process to evaluate those risks and developing evidence-based risk posture recommendations. Risks are ranked by likelihood and consequence. Intermediate causal relationships between risk contributing factors and countermeasures that link hazards to outcomes are described using Directed Acyclic Graphs (DAGs). The DAGs are also useful for identifying common factors and countermeasures across the top 30 risks as well as communicating how astronaut exposure to spaceflight hazards leads to meaningful mission-level health and performance outcomes. One of the top risks tracked by the HSRB is The Risk of Adverse Outcomes Due to Inadequate Human-Systems Integration Architecture (HSIA). This risk captures the possibility that due to decreasing real-time ground support during missions beyond LEO, crew will be unable to adequately respond to unanticipated critical malfunctions or detect safety-critical procedural errors. The HSIA risk is ranked red (high) for Lunar surface and Mars missions due to the probability of Loss of Crew and Loss of Mission consequences. This paper describes the evidence that supports the HSIA risk ranking and presents the central narrative of the HSIA risk DAG-- i.e., anomaly detection, diagnosis, intervention, and task performance. Characterizations of the current state of practice for each of the DAG’s central nodes and the future tools needed for successful anomaly response are provided.

human-systems integration architecture↗

A Fast Goal Recognition Technique Based on Interaction Estimates

Goal Recognition is the task of inferring an actor's goals given some or all of the actor's observed actions. There is considerable interest in Goal Recognition for use in intelligent personal assistants, smart environments, intelligent tutoring systems, and monitoring user's needs. In much of this work, the actor's observed actions are compared against a generated library of plans. Recent work by Ramirez and Geffner makes use of AI planning to determine how closely a sequence of observed actions matches plans for each possible goal. For each goal, this is done by comparing the cost of a plan for that goal with the cost of a plan for that goal that includes the observed actions. This approach yields useful rankings, but is impractical for real-time goal recognition in large domains because of the computational expense of constructing plans for each possible goal. In this paper, we introduce an approach that propagates cost and interaction information in a plan graph, and uses this information to estimate goal probabilities. We show that this approach is much faster, but still yields high quality results.

gola recognition↗

Augmenting Parametric Optimal Ascent Trajectory Modeling with Graph Theory

It has been well documented that decisions made in the early stages of Conceptual and Pre-Conceptual design commit up to 80% of total Life-Cycle Cost (LCC) while engineers know the least about the product they are designing [1]. Once within Preliminary and Detailed design however, making changes to the design becomes far more difficult to enact in both cost and schedule. Primarily this has been due to a lack of detailed data usually uncovered later during the Preliminary and Detailed design phases. In our current budget-constrained environment, making decisions within Conceptual and Pre-Conceptual design which minimize LCC while meeting requirements is paramount to a program's success. Within the arena of launch vehicle design, optimizing the ascent trajectory is critical for minimizing the costs present within such concerns as propellant, aerodynamic, aeroheating, and acceleration loads while meeting requirements such as payload delivered to a desired orbit. In order to optimize the vehicle design its constraints and requirements must be known, however as the design cycle proceeds it is all but inevitable that the conditions will change. Upon that change, the previously optimized trajectory may no longer be optimal, or meet design requirements. The current paradigm for adjusting to these updates is generating point solutions for every change in the design's requirements [2]. This can be a tedious, time-consuming task as changes in virtually any piece of a launch vehicle's design can have a disproportionately large effect on the ascent trajectory, as the solution space of the trajectory optimization problem is both non-linear and multimodal [3]. In addition, an industry standard tool, Program to Optimize Simulated Trajectories (POST), requires an expert analyst to produce simulated trajectories that are feasible and optimal [4]. In a previous publication the authors presented a method for combatting these challenges [5]. In order to bring more detailed information into Conceptual and Pre-Conceptual design, knowledge of the effects originating from changes to the vehicle must be calculated. In order to do this, a model capable of quantitatively describing any vehicle within the entire design space under consideration must be constructed. This model must be based upon analysis of acceptable fidelity, which in this work comes from POST. Design space interrogation can be achieved with surrogate modeling, a parametric, polynomial equation representing a tool. A surrogate model must be informed by data from the tool with enough points to represent the solution space for the chosen number of variables with an acceptable level of error. Therefore, Design Of Experiments (DOE) is used to select points within the design space to maximize information gained on the design space while minimizing number of data points required. To represent a design space with a non-trivial number of variable parameters the number of points required still represent an amount of work which would take an inordinate amount of time via the current paradigm of manual analysis, and so an automated method was developed. The best practices of expert trajectory analysts working within NASA Marshall's Advanced Concepts Office (ACO) were implemented within a tool called multiPOST. These practices include how to use the output data from a previous run of POST to inform the next, determining whether a trajectory solution is feasible from a real-world perspective, and how to handle program execution errors. The tool was then augmented with multiprocessing capability to enable analysis on multiple trajectories simultaneously, allowing throughput to scale with available computational resources. In this update to the previous work the authors discuss issues with the method and solutions.

Patrick D Dees↗

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↗