Search NASA⌕ Search

SEARCH · Search NASA

Results for “script”

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,585 records · Page 88

Measurements of Integration Gain for the Cospas-Sarsat System from Geosynchronous Satellites

The GOES-R satellite is the first satellite to use a standard straight bent pipe transponder with no on-board re-modulation to support Search and Rescue (SAR) operations. Here, we report on the link measurements with a high fidelity satellite transponder simulator made up of satellite EDU (Engineering Design Units) components using an uplink from a beacon simulator and received by a GEOLUT (GEOsynchronous satellite Local User Terminal). We also report on the first ever measurements showing the performance gain obtained by the signal integration performed by the GEOLUT. In addition, a simulator made of commercially available off-the-shelf components assembled to develop the test plan was found to perform very close to the high fidelity simulator. In this paper, we describe what message integration is, how it is implemented in the particular satellite receiving station model used for this tests, and show the measured improvement in message decoding due to this integration process. These are the first tests to quantify the integration gain and are the first tests on the new SARSAT standard for the bent pipe (no onboard re-modulation) repeater used in GOES-R. An inexpensive satellite simulator to run test scripts built from off the shelf components was also found to have the same performance as a high fidelity simulator using actual satellite EDUs.

Klein-Lebbink, Elizabeth↗

Measurements of Integration Gain for the Cospas-Sarsat System from Geosynchronous Satellites

The GOES-R satellite is the first satellite to use a standard straight bent pipe transponder with no on-board re-modulation to support Search and Rescue (SAR) operations. Here, we report on the link measurements with a high fidelity satellite transponder simulator made up of satellite EDU (Engineering Design Units) components using an uplink from a beacon simulator and received by a GEOLUT (GEOsynchronous satellite Local User Terminal). We also report on the first ever measurements showing the performance gain obtained by the signal integration performed by the GEOLUT. In addition, a simulator made of commercially available off-the-shelf components assembled to develop the test plan was found to perform very close to the high fidelity simulator. In this paper, we describe what message integration is, how it is implemented in the particular satellite receiving station model used for this tests, and show the measured improvement in message decoding due to this integration process. These are the first tests to quantify the integration gain and are the first tests on the new SARSAT standard for the bent pipe (no onboard re-modulation) repeater used in GOES-R. An inexpensive satellite simulator to run test scripts built from off the shelf components was also found to have the same performance as a high fidelity simulator using actual satellite EDUs.

Klein-Lebbink, Elizabeth↗

Addressing Software Security

Historically security within organizations was thought of as an IT function (web sites/servers, email, workstation patching, etc.) Threat landscape has evolved (Script Kiddies, Hackers, Advanced Persistent Threat (APT), Nation States, etc.) Attack surface has expanded -Networks interconnected!! Some security posture factors Network Layer (Routers, Firewalls, etc.) Computer Network Defense (IPS/IDS, Sensors, Continuous Monitoring, etc.) Industrial Control Systems (ICS) Software Security (COTS, FOSS, Custom, etc.)

software↗

The Impact of Suggestive Maneuver Guidance on UAS Pilots Performing the Detect and Avoid Function

This presentation discusses the results of a recent UAS Integration into the NAS human-in-the-loop simulation. In the study, 16 active UAS pilots flew a UAS through civil airspace and were tasked with maintaining well clear from other aircraft in the area. Pilots performed the task with four different detect and avoid (DAA) traffic displays, each of which varied in the form of guidance it provided to pilots The present findings focus on how the different displays impacted pilots' measured response to scripted conflicts with their aircraft. Measured response is made up of several components, each of which help inform our understanding of the pilots' role in the overall detect and avoid task.

detect and avoid↗

Transitioning Enhanced Land Surface Initialization and Model Verification Capabilities to the Kenya Meteorological Department (KMD)

Flooding, severe weather, and drought are key forecasting challenges for the Kenya Meteorological Department (KMD), based in Nairobi, Kenya. Atmospheric processes leading to convection, excessive precipitation and/or prolonged drought can be strongly influenced by land cover, vegetation, and soil moisture content, especially during anomalous conditions and dry/wet seasonal transitions. It is thus important to represent accurately land surface state variables (green vegetation fraction, soil moisture, and soil temperature) in Numerical Weather Prediction (NWP) models. The NASA SERVIR and the Short-term Prediction Research and Transition (SPoRT) programs in Huntsville, AL have established a working partnership with KMD to enhance its regional modeling capabilities. SPoRT and SERVIR are providing experimental land surface initialization datasets and model verification capabilities for capacity building at KMD. To support its forecasting operations, KMD is running experimental configurations of the Weather Research and Forecasting (WRF; Skamarock et al. 2008) model on a 12-km/4-km nested regional domain over eastern Africa, incorporating the land surface datasets provided by NASA SPoRT and SERVIR. SPoRT, SERVIR, and KMD participated in two training sessions in March 2014 and June 2015 to foster the collaboration and use of unique land surface datasets and model verification capabilities. Enhanced regional modeling capabilities have the potential to improve guidance in support of daily operations and high-impact weather and climate outlooks over Eastern Africa. For enhanced land-surface initialization, the NASA Land Information System (LIS) is run over Eastern Africa at ~3-km resolution, providing real-time land surface initialization data in place of interpolated global model soil moisture and temperature data available at coarser resolutions. Additionally, real-time green vegetation fraction (GVF) composites from the Suomi-NPP VIIRS instrument is being incorporated into the KMD-WRF runs, using the product generated by NOAA/NESDIS. Model verification capabilities are also being transitioned to KMD using NCAR's Model *Corresponding author address: Jonathan Case, ENSCO, Inc., 320 Sparkman Dr., Room 3008, Huntsville, AL, 35805. Email: Jonathan.Case-1@nasa.gov Evaluation Tools (MET; Brown et al. 2009) software in conjunction with a SPoRT-developed scripting package, in order to quantify and compare errors in simulated temperature, moisture and precipitation in the experimental WRF model simulations. This extended abstract and accompanying presentation summarizes the efforts and training done to date to support this unique regional modeling initiative at KMD. To honor the memory of Dr. Peter J. Lamb and his extensive efforts in bolstering weather and climate science and capacity-building in Africa, we offer this contribution to the special Peter J. Lamb symposium. The remainder of this extended abstract is organized as follows. The collaborating international organizations involved in the project are presented in Section 2. Background information on the unique land surface input datasets is presented in Section 3. The hands-on training sessions from March 2014 and June 2015 are described in Section 4. Sample experimental WRF output and verification from the June 2015 training are given in Section 5. A summary is given in Section 6, followed by Acknowledgements and References.

land surface modeling↗

Aircraft High-Lift Aerodynamic Analysis Using a Surface-Vorticity Solver

This study extends an existing semi-empirical approach to high-lift analysis by examining its effectiveness for use with a three-dimensional aerodynamic analysis method. The aircraft high-lift geometry is modeled in Vehicle Sketch Pad (OpenVSP) using a newly-developed set of techniques for building a three-dimensional model of the high-lift geometry, and for controlling flap deflections using scripted parameter linking. Analysis of the low-speed aerodynamics is performed in FlightStream, a novel surface-vorticity solver that is expected to be substantially more robust and stable compared to pressure-based potential-flow solvers and less sensitive to surface perturbations. The calculated lift curve and drag polar are modified by an empirical lift-effectiveness factor that takes into account the effects of viscosity that are not captured in the potential-flow solution. Analysis results are validated against wind-tunnel data for The Energy-Efficient Transport AR12 low-speed wind-tunnel model, a 12-foot, full-span aircraft configuration with a supercritical wing, full-span slats, and part-span double-slotted flaps.

Olson, Erik D.↗

Status of the JWST Science Instrument Payload

The James Webb Space Telescope (JWST) Integrated Science Instrument Module (ISIM) system consists of five sensors (4 science): Mid-Infrared Instrument (MIRI), Near Infrared Imager and Slitless Spectrograph (NIRISS), Fine Guidance Sensor (FGS), Near InfraRed Camera (NIRCam), Near InfraRed Spectrograph (NIRSpec); and nine instrument support systems: Optical metering structure system, Electrical Harness System; Harness Radiator System, ISIM Electronics Compartment, ISIM Remote Services Unit, Cryogenic Thermal Control System, Command and Data Handling System, Flight Software System, Operations Scripts System.

JWST Payload↗

TASAR Flight Trial 2: Assessment of Air Traffic Controller Acceptability of TASAR Requests

In support of the Flight Trial (FT-2) of NASA's prototype of the Traffic Aware Strategic Aircrew Requests (TASAR) concept, observations were conducted at the air traffic facilities to identify and assess the main factors that affect the acceptability of pilot requests by air traffic controllers. Two observers shadowed air traffic controllers at the Atlanta (ZTL) and Jacksonville (ZJX) air traffic control centers as the test flight pilot made pre-scripted requests to invoke acceptability issues and then they interviewed the observed and other controllers voluntarily. Fifty controllers were interviewed with experience ranging from one to thirty-five years. All interviewed controllers were enthusiastic about the technology and accounting for sector boundaries in pilot requests, particularly if pilots can be made aware of high workload situations. All interviewed controllers accept more than fifty percent of pilot requests; forty percent of them reject less than ten percent of requests. The most common reason for rejecting requests is conflicting with traffic followed by violating letters of agreement (LOAs) and negatively impacting neighboring sector workload, major arrival and departure flows and flow restrictions. Thirty-six requests were made during the test, eight of which were rejected due to: the aircraft already handed off to another sector, violating LOA, opposing traffic, intruding into an active special use airspace (SUA), intruding into another center, weather, and unfamiliarity with the requested waypoint. Nine requests were accepted with delay mostly because the controller needed to locate unfamiliar waypoints or to coordinate with other controllers.

Idris, Husni↗

ROS Hexapod

As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome will convert existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate and to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code. Conversion of C++ codes to ROS will enable existing code to be compatible with ROS, and will be controlled using existing PS3 controller. Furthermore, my job description is to design ROS messages and script programs which will enable assets to participate in the ROS ecosystem. In addition, an open source software (IDE) Arduino board will be integrated in the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module digital clock that will run off 22 satellites to show accurate real time using a GPS signal and internal patch antenna to communicate with satellites.

Davis, Kirsch↗

Simulation Development and Analysis of Crew Vehicle Ascent Abort

NASA's Commercial Crew Program is an integral step in its journey to Mars as it would expedite development of space technologies and open up partnership with U.S. commercial companies. NASA reviews and independent assessment of Commercial Crew Program is fundamental to its success, and being able to model a commercial crew vehicle in a simulation rather than conduct a live test would be a safer, faster, and less expensive way to assess and certify the capabilities of the vehicle. To this end, my project was to determine the feasibility of using a simulation tool named SOMBAT version 2.0 to model a multiple parachute system for Commercial Crew Program simulation. The main tasks assigned to me were to debug and test the main parachute system model, (capable of simulating one to four main parachute bodies), and to utilize a graphical program to animate the simulation results. To begin tackling the first task, I learned how to use SOMBAT by familiarizing myself with its mechanics and by understanding the methods used to tweak its various parameters and outputs. I then used this new knowledge to set up, run, and analyze many different situations within SOMBAT in order to explore the limitations of the parachute model. Some examples of parameters that I varied include the initial velocity and orientation of the falling capsule, the number of main parachutes, and the location where the parachutes were attached to the capsule. Each parameter changed would give a different output, and in some cases, would expose a bug or limitation in the model. A major bug that I discovered was the inability of the model to handle any number of parachutes other than three. I spent quite some time trying to debug the code logically, but was unable to figure it out until my mentor taught me that digital simulation limitations can occur when some approximations are mistakenly assumed for certain in a physical system. This led me to the realization that unlike in all of the programming classes I have taken thus far that focus on pure logic, simulation code focuses on mimicking the physical world with some approximation and can have inaccuracies or numerical instabilities. Learning from my mistake, I adopted new methods to analyze these different simulations. One method the student used was to numerically plot various physical parameters using MATLAB to confirm the mechanical behavior of the system in addition to comparing the data to the output from a separate simulation tool called FAST. By having full control over what was being outputted from the simulation, I could choose which parameters to change and to plot as well as how to plot them, allowing for an in depth analysis of the data. Another method of analysis was to convert the output data into a graphical animation. Unlike the numerical plots, where all of the physical components were displayed separately, this graphical display allows for a combined look at the simulation output that makes it much easier for one to see the physical behavior of the model. The process for converting SOMBAT output for EDGE graphical display had to be developed. With some guidance from other EDGE users, I developed a process and created a script that would easily allow one to display simulations graphically. Another limitation with the SOMBAT model was the inability for the capsule to have the main parachutes instantly deployed with a large angle between the air speed vector and the chutes drag vector. To explore this problem, I had to learn about different coordinate frames used in Guidance, Navigation & Control (J2000, ECEF, ENU, etc.) to describe the motion of a vehicle and about Euler angles (e.g. Roll, Pitch, Yaw) to describe the orientation of the vehicle. With a thorough explanation from my mentor about the description of each coordinate frame, as well as how to use a directional cosine matrix to transform one frame to another, I investigated the problem by simulating different capsule orientations. In the end, I was able to show that this limitation could be avoided if the capsule is initially oriented antiparallel to its velocity vector.

Wong, Chi S.↗

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗

Optical Testing and Verification Methods for the James Webb Space Telescope Integrated Science Instrument Module Element

NASA's James Webb Space Telescope (JWST) is a 6.6m diameter, segmented, deployable telescope for cryogenic IR space astronomy (~40K). The JWST Observatory includes the Optical Telescope Element (OTE) and the Integrated Science Instrument Module (ISIM) that contains four science instruments (SI) and the fine guider. The SIs are mounted to a composite metering structure. The SI and guider units were integrated to the ISIM structure and optically tested at the NASA Goddard Space Flight Center as a suite using the Optical Telescope Element SIMulator (OSIM). OSIM is a full field, cryogenic JWST telescope simulator. SI performance, including alignment and wave front error, were evaluated using OSIM. We describe test and analysis methods for optical performance verification of the ISIM Element, with an emphasis on the processes used to plan and execute the test. The complexity of ISIM and OSIM drove us to develop a software tool for test planning that allows for configuration control of observations, associated scripts, and management of hardware and software limits and constraints, as well as tools for rapid data evaluation, and flexible re-planning in response to the unexpected. As examples of our test and analysis approach, we discuss how factors such as the ground test thermal environment are compensated in alignment. We describe how these innovative methods for test planning and execution and post-test analysis were instrumental in the verification program for the ISIM element, with enough information to allow the reader to consider these innovations and lessons learned in this successful effort in their future testing for other programs.

spaceborne telescopes↗

ROS Hexapod

As an intern project for NASA Johnson Space Center (JSC), my job was to familiarize myself and operate a Robotics Operating System (ROS). The project outcome converted existing software assets into ROS using nodes, enabling a robotic Hexapod to communicate to be functional and controlled by an existing PlayStation 3 (PS3) controller. Existing control algorithms and current libraries have no ROS capabilities within the Hexapod C++ source code when the internship started, but that has changed throughout my internship. Conversion of C++ codes to ROS enabled existing code to be compatible with ROS, and is now controlled using an existing PS3 controller. Furthermore, my job description was to design ROS messages and script programs that enabled assets to participate in the ROS ecosystem by subscribing and publishing messages. Software programming source code is written in directories using C++. Testing of software assets included compiling code within the Linux environment using a terminal. The terminal ran the code from a directory. Several problems occurred while compiling code and the code would not compile. So modifying code to where C++ can read the source code were made. Once the code was compiled and ran, the code was uploaded to Hexapod and then controlled by a PS3 controller. The project outcome has the Hexapod fully functional and compatible with ROS and operates using the PlayStation 3 controller. In addition, an open source software (IDE) Arduino board will be integrated into the ecosystem with designing circuitry on a breadboard to add additional behavior with push buttons, potentiometers and other simple elements in the electrical circuitry. Other projects with the Arduino will be a GPS module, digital clock that will run off 22 satellites to show accurate real time using a GPS signal and an internal patch antenna to communicate with satellites. In addition, this internship experience has led me to pursue myself to learn coding more efficiently and effectively to write, subscribe and publish my own source code in different programming languages. With some familiarity with software programming, it will enhance my skills in the electrical engineering field. In contrast, my experience here at JSC with the Simulation and Graphics Branch (ER7) has led me to take my coding skill to be more proficient to increase my knowledge in software programming, and also enhancing my skills in ROS. This knowledge will be taken back to my university to implement coding in a school project that will use source coding and ROS to work on the PR2 robot which is controlled by ROS software. My skills learned here will be used to integrate messages to subscribe and publish ROS messages to a PR2 robot. The PR2 robot will be controlled by an existing PS3 controller by changing C++ coding to subscribe and publish messages to ROS. Overall the skills that were obtained here will not be lost, but increased.

Davis, Kirsch↗

US Navy Submarine Sea Trial of the NASA Air Quality Monitor

For the past four years, the Air Quality Monitor (AQM) has been the operational instrument for measuring trace volatile organic compounds on the International Space Station (ISS). The key components of the AQM are the inlet preconcentrator, the gas chromatograph (GC), and the differential mobility spectrometer. Most importantly, the AQM operates at atmospheric pressure and uses air as the GC carrier gas, which translates into a small reliable instrument. Onboard ISS there are two AQMs, with different GC columns that detect and quantify 22 compounds. The AQM data contributes valuable information to the assessment of air quality aboard ISS for each crew increment. The U.S. Navy is looking to update its submarine air monitoring suite of instruments, and the success of the AQM on ISS has led to a jointly planned submarine sea trial of a NASA AQM. In addition to the AQM, the Navy is also interested in the Multi-Gas Monitor (MGM), which was successfully flown on ISS as a technology demonstration to measure major constituent gases (oxygen, carbon dioxide, water vapor, and ammonia). A separate paper will present the MGM sea trial results. A prototype AQM, which is virtually identical to the operational AQM, has been readied for the sea trial. Only one AQM will be deployed during the sea trial, but it is sufficient to detect the compounds of interest to the Navy for the purposes of this trial. A significant benefit of the AQM is that runs can be scripted for pre-determined intervals and no crew intervention is required. The data from the sea trial will be compared to archival samples collected prior to and during the trial period. This paper will give a brief overview of the AQM technology and protocols for the submarine trial. After a quick review of the AQM preparation, the main focus of the paper will be on the results of the submarine trial. Of particular interest will be the comparison of the contaminants found in the ISS and submarine atmospheres, as both represent closed environments. In U.K. submarine trials in the early 2000s, the submarine and ISS atmospheres were found to be remarkably similar.

Limero, Thomas↗

PISCES High Contrast Integral Field Spectrograph Simulations and Data Reduction Pipeline

The PISCES (Prototype Imaging Spectrograph for Coronagraphic Exoplanet Studies) is a lenslet array based integral field spectrograph (IFS) designed to advance the technology readiness of the WFIRST (Wide Field Infrared Survey Telescope)-AFTA (Astrophysics Focused Telescope Assets) high contrast Coronagraph Instrument. We present the end to end optical simulator and plans for the data reduction pipeline (DRP). The optical simulator was created with a combination of the IDL (Interactive Data Language)-based PROPER (optical propagation) library and Zemax (a MatLab script), while the data reduction pipeline is a modified version of the Gemini Planet Imager's (GPI) IDL pipeline. The simulations of the propagation of light through the instrument are based on Fourier transform algorithms. The DRP enables transformation of the PISCES IFS data to calibrated spectral data cubes.

The PISCES (Prototype Imaging Spectrograph for Cor↗

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↗

DAIDALUS Observations From UAS Integration in the NAS Project Flight Test 4

In order to validate the Unmanned Aerial System (UAS) Detect-and-Avoid (DAA) solution proposed by standards body RTCA Inc., the National Aeronautics and Space Administration (NASA) UAS Integration in the NAS project, alongside industry members General Atomics and Honeywell, conducted the fourth flight test in a series at Armstrong Flight Research Center in Edwards, California. Flight Test 4 (FT4) investigated problems of interoperability with the TCAS collision avoidance system with a DAA system as well as problems associated with sensor uncertainty. A series of scripted flight encounters between the NASA Ikhana UAS and various "intruder" aircraft were flown while alerting and guidance from the DAA algorithm were recorded to investigate the timeliness of the alerts and correctness of the guidance triggered by the DAA system. The results found that alerts were triggered in a timely manner in most instances. Cases where the alerting and guidance was incorrect were investigated further.

Vincent, Michael J.↗

Optimization Routine for Generating Medical Kits for Spaceflight Using the Integrated Medical Model

The Integrated Medical Model (IMM) is a MATLAB model that provides probabilistic assessment of the medical risk associated with human spaceflight missions.Different simulations or profiles can be run in which input conditions regarding both mission characteristics and crew characteristics may vary. For each simulation, the IMM records the total medical events that occur and “treats” each event with resources drawn from import scripts. IMM outputs include Total Medical Events (TME), Crew Health Index (CHI), probability of Evacuation (pEVAC), and probability of Loss of Crew Life (pLOCL).The Crew Health Index is determined by the amount of quality time lost (QTL). Previously, an optimization code was implemented in order to efficiently generate medical kits. The kits were optimized to have the greatest benefit possible, given amass and/or volume constraint. A 6-crew, 14-day lunar mission was chosen for the simulation and run through the IMM for 100,000 trials. A built-in MATLAB solver, mixed-integer linear programming, was used for the optimization routine. Kits were generated in 10% increments ranging from 10%-100% of the benefit constraints. Conditions wheremass alone was minimized, volume alone was minimized, and where mass and volume were minimizedjointly were tested.

Medical Kit↗