Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “flight software testing”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 1,639 records · Page 91

Spinoff 2013

Topics covered include: Innovative Software Tools Measure Behavioral Alertness; Miniaturized, Portable Sensors Monitor Metabolic Health; Patient Simulators Train Emergency Caregivers; Solar Refrigerators Store Life-Saving Vaccines; Monitors Enable Medication Management in Patients' Homes; Handheld Diagnostic Device Delivers Quick Medical Readings; Experiments Result in Safer, Spin-Resistant Aircraft; Interfaces Visualize Data for Airline Safety, Efficiency; Data Mining Tools Make Flights Safer, More Efficient; NASA Standards Inform Comfortable Car Seats; Heat Shield Paves the Way for Commercial Space; Air Systems Provide Life Support to Miners; Coatings Preserve Metal, Stone, Tile, and Concrete; Robots Spur Software That Lends a Hand; Cloud-Based Data Sharing Connects Emergency Managers; Catalytic Converters Maintain Air Quality in Mines; NASA-Enhanced Water Bottles Filter Water on the Go; Brainwave Monitoring Software Improves Distracted Minds; Thermal Materials Protect Priceless, Personal Keepsakes; Home Air Purifiers Eradicate Harmful Pathogens; Thermal Materials Drive Professional Apparel Line; Radiant Barriers Save Energy in Buildings; Open Source Initiative Powers Real-Time Data Streams; Shuttle Engine Designs Revolutionize Solar Power; Procedure-Authoring Tool Improves Safety on Oil Rigs; Satellite Data Aid Monitoring of Nation's Forests; Mars Technologies Spawn Durable Wind Turbines; Programs Visualize Earth and Space for Interactive Education; Processor Units Reduce Satellite Construction Costs; Software Accelerates Computing Time for Complex Math; Simulation Tools Prevent Signal Interference on Spacecraft; Software Simplifies the Sharing of Numerical Models; Virtual Machine Language Controls Remote Devices; Micro-Accelerometers Monitor Equipment Health; Reactors Save Energy, Costs for Hydrogen Production; Cameras Monitor Spacecraft Integrity to Prevent Failures; Testing Devices Garner Data on Insulation Performance; Smart Sensors Gather Information for Machine Diagnostics; Oxygen Sensors Monitor Bioreactors and Ensure Health and Safety; Vision Algorithms Catch Defects in Screen Displays; and Deformable Mirrors Capture Exoplanet Data, Reflect Lasers.

Source record↗

NASA's spacecraft data system

The NASA Small Explorer Data System (SEDS), a space flight data system developed to support the Small Explorer (SMEX) project, is addressed. The system was flown on the Solar Anomalous Magnetospheric Particle Explorer (SAMPEX) SMEX mission, and with reconfiguration for different requirements will fly on the X-ray Timing Explorer (XTE) and the Tropical Rainfall Measuring Mission (TRMM). SEDS is also foreseen for the Hubble repair mission. Its name was changed to Spacecraft Data System (SDS) in view of expansions. Objectives, SDS hardware, and software are described. Each SDS box contains two computers, data storage memory, uplink (command) reception circuitry, downlink (telemetry) encoding circuitry, Instrument Telemetry Controller (ITC), and spacecraft timing circuitry. The SDS communicates with other subsystems over the MIL-STD-1773 data bus. The SDS software uses a real time Operating System (OS) and the C language. The OS layer, communications and scheduling layer, application task layer, and diagnostic software, are described. Decisions on the use of advanced technologies, such as ASIC's (Application Specific Integrated Circuits) and fiber optics, led to technical improvements, such as lower power and weight, without increasing the risk associated with the data system. The result was a successful SAMPEX development, integration and test, and mission using SEDS, and the upgrading of that system to SDS for TRMM and XTE.

Cudmore, Alan↗

Orbital flight simulation utility software unit specifications, revision 1

The HP PASCAL source code defines the specifications for a Utility Software Unit (USU) designed to support orbital flight simulators such as MANHANDLE and GREAS (General Research and Engineering Analysis Simulator). Besides providing basic input/output, mathematical, matrix, quaternion, and statistical routines for such simulators, one of the primary functions of the USU is to isolate all system-dependent codes in one well-defined compartment, thereby facilitating transportation of the simulations from one computer to another. Directives are given for the PASCAL compilers of the HP-9000 Series 200 Pascal 3.0 and the HP-9000 Series 500 HP-UX 5.0 operating systems that produce a single file of relocatable code from four separate files of source code. Three of the source code files are common to both operating systems. The fourth source code file (utilspif.I) contains all of the system-dependent PASCAL code for the USU. A fifth file of source code written in C is required to interface utilspif.I with the HP-UX I/O package. The Pascal 3.0 compiler directives and the driver source code for a unit rest program and counterparts for the HP-UX 5.0 operating system are given. The major portion of the unit test program source code is common to both operating systems. Unit test results from the Pascal 3.0 operating system and results from the HP-UX operating system are given.

Wilson, S. W.↗

An Introduction to Flight Software Development: FSW Today, FSW 2010

Experience and knowledge gained from ongoing maintenance of Space Shuttle Flight Software and new development projects including Cockpit Avionics Upgrade are applied to projected needs of the National Space Exploration Vision through Spiral 2. Lessons learned from these current activities are applied to create a sustainable, reliable model for development of critical software to support Project Constellation. This presentation introduces the technologies, methodologies, and infrastructure needed to produce and sustain high quality software. It will propose what is needed to support a Vision for Space Exploration that places demands on the innovation and productivity needed to support future space exploration. The technologies in use today within FSW development include tools that provide requirements tracking, integrated change management, modeling and simulation software. Specific challenges that have been met include the introduction and integration of Commercial Off the Shelf (COTS) Real Time Operating System for critical functions. Though technology prediction has proved to be imprecise, Project Constellation requirements will need continued integration of new technology with evolving methodologies and changing project infrastructure. Targets for continued technology investment are integrated health monitoring and management, self healing software, standard payload interfaces, autonomous operation, and improvements in training. Emulation of the target hardware will also allow significant streamlining of development and testing. The methodologies in use today for FSW development are object oriented UML design, iterative development using independent components, as well as rapid prototyping . In addition, Lean Six Sigma and CMMI play a critical role in the quality and efficiency of the workforce processes. Over the next six years, we expect these methodologies to merge with other improvements into a consolidated office culture with all processes being guided by automated office assistants. The infrastructure in use today includes strict software development and configuration management procedures, including strong control of resource management and critical skills coverage. This will evolve to a fully integrated staff organization with efficient and effective communication throughout all levels guided by a Mission-Systems Architecture framework with focus on risk management and attention toward inevitable product obsolescence. This infrastructure of computing equipment, software and processes will itself be subject to technological change and need for management of change and improvement,

Gouvela, John↗

Mobile Router Developed and Tested

The NASA Glenn Research Center, under a NASA Space Act Agreement with Cisco Systems, has been performing joint networking research to apply Internet-based technologies and protocols to space-based communications. As a result of this research, NASA performed stringent performance testing of the mobile router, including the interaction of routing and the transport-level protocol. In addition, Cisco Systems developed the mobile router for both commercial and Government markets. The code has become part of the Cisco Systems Internetworking Operating System (IOS) as of release 12.2 (4) T--which will make this capability available to the community at large. The mobile router is software code that resides in a network router and enables entire networks to roam while maintaining connectivity to the Internet. This router code is pertinent to a myriad of applications for both Government and commercial sectors, including the "wireless battlefield." NASA and the Department of Defense will utilize this technology for near-planetary observation and sensing spacecraft. It is also a key enabling technology for aviation-based information applications. Mobile routing will make it possible for information such as weather, air traffic control, voice, and video to be transmitted to aircraft using Internet-based protocols. This technology shows great promise in reducing congested airways and mitigating aviation disasters due to bad weather. The mobile router can also be incorporated into emergency vehicles (such as ambulances and life-flight aircraft) to provide real-time connectivity back to the hospital and health-care experts, enabling the timely application of emergency care. Commercial applications include entertainment services, Internet protocol (IP) telephone, and Internet connectivity for cruise ships, commercial shipping, tour buses, aircraft, and eventually cars. A mobile router, which is based on mobile IP, allows hosts (mobile nodes) to seamlessly "roam" among various IP subnetworks. This is essential in many wireless networks. A mobile router, unlike a mobile IP node, allows entire networks to roam. Hence, a device connected to the mobile router does not need to be a mobile node because the mobile router provides the roaming capabilities. There are three basic elements in the mobile IP: the home agent, the foreign agent, and the mobile node. The home agent is a router on a mobile node's home network that tunnels datagrams for delivery to the mobile node when it is away from home. The foreign agent is a router on a remote network that provides routing services to a registered mobile node. The mobile node is a host or router that changes its point of attachment from one network or subnetwork to another. In mobile routing, virtual communications are maintained by the home agent, which forwards all packets for the mobile networks to the foreign agent. The foreign agent passes the packets to the mobile router, which then forwards the packets to the devices on its networks. As the mobile router moves, it will register with its home agent on its whereabouts via the foreign agent to assure continuous connectivity.

Ivancic, William D.↗

STRS SpaceWire FPGA Module

An FPGA module leverages the previous work from Goddard Space Flight Center (GSFC) relating to NASA s Space Telecommunications Radio System (STRS) project. The STRS SpaceWire FPGA Module is written in the Verilog Register Transfer Level (RTL) language, and it encapsulates an unmodified GSFC core (which is written in VHDL). The module has the necessary inputs/outputs (I/Os) and parameters to integrate seamlessly with the SPARC I/O FPGA Interface module (also developed for the STRS operating environment, OE). Software running on the SPARC processor can access the configuration and status registers within the SpaceWire module. This allows software to control and monitor the SpaceWire functions, but it is also used to give software direct access to what is transmitted and received through the link. SpaceWire data characters can be sent/received through the software interface, as well as through the dedicated interface on the GSFC core. Similarly, SpaceWire time codes can be sent/received through the software interface or through a dedicated interface on the core. This innovation is designed for plug-and-play integration in the STRS OE. The SpaceWire module simplifies the interfaces to the GSFC core, and synchronizes all I/O to a single clock. An interrupt output (with optional masking) identifies time-sensitive events within the module. Test modes were added to allow internal loopback of the SpaceWire link and internal loopback of the client-side data interface.

Lux, James P.↗

NASA Center for Climate Simulation (NCCS) Presentation

The NASA Center for Climate Simulation (NCCS) offers integrated supercomputing, visualization, and data interaction technologies to enhance NASA's weather and climate prediction capabilities. It serves hundreds of users at NASA Goddard Space Flight Center, as well as other NASA centers, laboratories, and universities across the US. Over the past year, NCCS has continued expanding its data-centric computing environment to meet the increasingly data-intensive challenges of climate science. We doubled our Discover supercomputer's peak performance to more than 800 teraflops by adding 7,680 Intel Xeon Sandy Bridge processor-cores and most recently 240 Intel Xeon Phi Many Integrated Core (MIG) co-processors. A supercomputing-class analysis system named Dali gives users rapid access to their data on Discover and high-performance software including the Ultra-scale Visualization Climate Data Analysis Tools (UV-CDAT), with interfaces from user desktops and a 17- by 6-foot visualization wall. NCCS also is exploring highly efficient climate data services and management with a new MapReduce/Hadoop cluster while augmenting its data distribution to the science community. Using NCCS resources, NASA completed its modeling contributions to the Intergovernmental Panel on Climate Change (IPCG) Fifth Assessment Report this summer as part of the ongoing Coupled Modellntercomparison Project Phase 5 (CMIP5). Ensembles of simulations run on Discover reached back to the year 1000 to test model accuracy and projected climate change through the year 2300 based on four different scenarios of greenhouse gases, aerosols, and land use. The data resulting from several thousand IPCC/CMIP5 simulations, as well as a variety of other simulation, reanalysis, and observationdatasets, are available to scientists and decision makers through an enhanced NCCS Earth System Grid Federation Gateway. Worldwide downloads have totaled over 110 terabytes of data.

Webster, William P.↗

NASA Tech Briefs, May 2013

Topics include: Test Waveform Applications for JPL STRS Operating Environment; Pneumatic Proboscis Heat-Flow Probe; Method to Measure Total Noise Temperature of a Wireless Receiver During Operation; Cursor Control Device Test Battery; Functional Near-Infrared Spectroscopy Signals Measure Neuronal Activity in the Cortex; ESD Test Apparatus for Soldering Irons; FPGA-Based X-Ray Detection and Measurement for an X-Ray Polarimeter; Sequential Probability Ratio Test for Spacecraft Collision Avoidance Maneuver Decisions; Silicon/Carbon Nanotube Photocathode for Splitting Water; Advanced Materials and Fabrication Techniques for the Orion Attitude Control Motor; Flight Hardware Packaging Design for Stringent EMC Radiated Emission Requirements; RF Reference Switch for Spaceflight Radiometer Calibration; An Offload NIC for NASA, NLR, and Grid Computing; Multi-Scale CNT-Based Reinforcing Polymer Matrix Composites for Lightweight Structures; Ceramic Adhesive and Methods for On-Orbit Repair of Re-Entry Vehicles; Self-Healing Nanocomposites for Reusable Composite Cryotanks; Pt-Ni and Pt-Co Catalyst Synthesis Route for Fuel Cell Applications; Aerogel-Based Multilayer Insulation with Micrometeoroid Protection; Manufacturing of Nanocomposite Carbon Fibers and Composite Cylinders; Optimized Radiator Geometries for Hot Lunar Thermal Environments; A Mission Concept: Re-Entry Hopper-Aero-Space-Craft System on-Mars (REARM-Mars); New Class of Flow Batteries for Terrestrial and Aerospace Energy Storage Applications; Reliability of CCGA 1152 and CCGA 1272 Interconnect Packages for Extreme Thermal Environments; Using a Blender to Assess the Microbial Density of Encapsulated Organisms; Mixed Integer Programming and Heuristic Scheduling for Space Communication; Video Altimeter and Obstruction Detector for an Aircraft; Control Software for Piezo Stepping Actuators; Galactic Cosmic Ray Event-Based Risk Model (GERM) Code; Sasquatch Footprint Tool; and Multi-User Space Link Extension (SLE) System.

Source record↗

Ares I-X Range Safety Simulation Verification and Analysis IV and V

NASA s ARES I-X vehicle launched on a suborbital test flight from the Eastern Range in Florida on October 28, 2009. NASA generated a Range Safety (RS) flight data package to meet the RS trajectory data requirements defined in the Air Force Space Command Manual 91-710. Some products included in the flight data package were a nominal ascent trajectory, ascent flight envelope trajectories, and malfunction turn trajectories. These data are used by the Air Force s 45th Space Wing (45SW) to ensure Eastern Range public safety and to make flight termination decisions on launch day. Due to the criticality of the RS data in regards to public safety and mission success, an independent validation and verification (IV&V) effort was undertaken to accompany the data generation analyses to ensure utmost data quality and correct adherence to requirements. Multiple NASA centers and contractor organizations were assigned specific products to IV&V. The data generation and IV&V work was coordinated through the Launch Constellation Range Safety Panel s Trajectory Working Group, which included members from the prime and IV&V organizations as well as the 45SW. As a result of the IV&V efforts, the RS product package was delivered with confidence that two independent organizations using separate simulation software generated data to meet the range requirements and yielded similar results. This document captures ARES I-X RS product IV&V analysis, including the methodology used to verify inputs, simulation, and output data for an RS product. Additionally a discussion of lessons learned is presented to capture advantages and disadvantages to the IV&V processes used.

Tarpley, Ashley↗

Constellation Program Lessons Learned: Detailed Lessons Learned - Volume 2

These lessons learned are part of a suite of hardware, software, test results, designs, knowledge base, and documentation that comprises the legacy of the Constellation Program. The context, summary information, and lessons learned are presented in a factual format, as known and described at the time. While our opinions might be discernable in the context, we have avoided all but factually sustainable statements. Statements should not be viewed as being either positive or negative; their value lies in what we did and what we learned that is worthy of passing on. The lessons include both "dos" and "don ts." In many cases, one person s "do" can be viewed as another person s "don t"; therefore, we have attempted to capture both perspectives when applicable and useful. While Volume I summarizes the views of those who managed the program, this Volume II encompasses the views at the working level, describing how the program challenges manifested in day-to-day activities. Here we see themes that were perhaps hinted at, but not completely addressed, in Volume I: unintended consequences of policies that worked well at higher levels but lacked proper implementation at the working level; long-term effects of the "generation gap" in human space flight development, the need to demonstrate early successes at the expense of thorough planning, and the consequences of problems and challenges not yet addressed because other problems and challenges were more immediate or manifest. Not all lessons learned have the benefit of being operationally vetted, since the program was cancelled shortly after Preliminary Design Review. We avoid making statements about operational consequences (with the exception of testing and test flights that did occur), but we do attempt to provide insight into how operational thinking influenced design and testing. The lessons have been formatted with a description, along with supporting information, a succinct statement of the lesson learned, and recommendations for future programs and projects that may be placed in similar circumstances.

Jennifer Rhatigan↗

Biomechanical Modeling of Split-leg Squat and Heel Raise on the Hybrid Ultimate Lifting Kit (HULK)

Long duration space travel will expose astronauts to extended periods of reduced gravity. Since gravity is not present to aid loading, astronauts will use resistive and aerobic exercise regimes for the duration of the space flight to minimize the loss of bone density, muscle mass and aerobic capacity that occurs during exposure to a reduced gravity environment. Unlike the International Space Station (ISS), the area available for an exercise device in the next generation of spacecraft is limited and therefore compact resistance exercise device prototypes are being developed. The Advanced Resistive Exercise Device (ARED) currently on the ISS is being used as a benchmark for the functional performance of these new devices. Biomechanical data collection and computational modeling aid the device design process by quantifying the joint torques and musculoskeletal forces that occur during exercises performed on the prototype devices. Computational models currently use OpenSim software, an open source code for musculoskeletal modeling, with biomechanical input data from subjects for estimation of muscle and joint loads. Subjects are instrumented with reflective markers for motion capture data collection while exercising on the Hybrid Ultimate Lifting Kit (HULK) prototype device. Ground reaction force data is collected with force plates under the feet and device loading is recorded through load cells internal to the HULK. This data is input into the OpenSim biomechanical model, which has been scaled to match the anthropometrics of the test subject, to calculate the loads on the body. Multiple exercises are performed and evaluated during a test session such as a full squat, single leg squat, heel raise and dead lift. Variables for these exercises include applied device load, narrow or wide foot stance, slow or fast cadence and the harness or long bar interface between the test subject and the device. Data from free weights are compared to the resistively loaded exercise device. The focus of this presentation is to summarize the results from the single-leg squat and heel raise exercises performed during three sessions occurring in 2015. Differences in loading configuration, cadence and stance produce differences in kinematics, joint toques and force and muscle forces.

computational modeling↗

NASA Goddard Space Flight Center

The NASA SLR Operational Center is responsible for: 1) NASA SLR network control, sustaining engineering, and logistics; 2) ILRS mission operations; and 3) ILRS and NASA SLR data operations. NASA SLR network control and sustaining engineering tasks include technical support, daily system performance monitoring, system scheduling, operator training, station status reporting, system relocation, logistics and support of the ILRS Networks and Engineering Working Group. These activities ensure the NASA SLR systems are meeting ILRS and NASA mission support requirements. ILRS mission operations tasks include mission planning, mission analysis, mission coordination, development of mission support plans, and support of the ILRS Missions Working Group. These activities ensure than new mission and campaign requirements are coordinated with the ILRS. Global Normal Points (NP) data, NASA SLR FullRate (FR) data, and satellite predictions are managed as part of data operations. Part of this operation includes supporting the ILRS Data Formats and Procedures Working Group. Global NP data operations consist of receipt, format and data integrity verification, archiving and merging. This activity culminates in the daily electronic transmission of NP files to the CDDIS. Currently of all these functions are automated. However, to ensure the timely and accurate flow of data, regular monitoring and maintenance of the operational software systems, computer systems and computer networking are performed. Tracking statistics between the stations and the data centers are compared periodically to eliminate lost data. Future activities in this area include sub-daily (i.e., hourly) NP data management, more stringent data integrity tests, and automatic station notification of format and data integrity issues.

Carter, David↗

Aeroelasticity Benchmark Assessment: Subsonic Fixed Wing Program

The fundamental technical challenge in computational aeroelasticity is the accurate prediction of unsteady aerodynamic phenomena and the effect on the aeroelastic response of a vehicle. Currently, a benchmarking standard for use in validating the accuracy of computational aeroelasticity codes does not exist. Many aeroelastic data sets have been obtained in wind-tunnel and flight testing throughout the world; however, none have been globally presented or accepted as an ideal data set. There are numerous reasons for this. One reason is that often, such aeroelastic data sets focus on the aeroelastic phenomena alone (flutter, for example) and do not contain associated information such as unsteady pressures and time-correlated structural dynamic deflections. Other available data sets focus solely on the unsteady pressures and do not address the aeroelastic phenomena. Other discrepancies can include omission of relevant data, such as flutter frequency and / or the acquisition of only qualitative deflection data. In addition to these content deficiencies, all of the available data sets present both experimental and computational technical challenges. Experimental issues include facility influences, nonlinearities beyond those being modeled, and data processing. From the computational perspective, technical challenges include modeling geometric complexities, coupling between the flow and the structure, grid issues, and boundary conditions. The Aeroelasticity Benchmark Assessment task seeks to examine the existing potential experimental data sets and ultimately choose the one that is viewed as the most suitable for computational benchmarking. An initial computational evaluation of that configuration will then be performed using the Langley-developed computational fluid dynamics (CFD) software FUN3D1 as part of its code validation process. In addition to the benchmarking activity, this task also includes an examination of future research directions. Researchers within the Aeroelasticity Branch will examine other experimental efforts within the Subsonic Fixed Wing (SFW) program (such as testing of the NASA Common Research Model (CRM)) and other NASA programs and assess aeroelasticity issues and research topics.

Florance, Jennifer P.↗

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↗

Comparison of Two Digital Stethoscopes with the Traditional Stethoscope Used on International Space Station

A traditional stethoscope is currently flown on the International Space Station (ISS). The background noise on the ISS is much higher than a normal exam room, and the literature shows that traditional stethoscopes are unable to function effectively in high noise environments. Digital stethoscopes provide amplification which improves the audibility in a quiet environment. This study is designed to determine if digital stethoscopes offer any advantage over traditional stethoscopes in being able to identify normal and abnormal sounds in the ISS noise environment. Methods: An ISS noise simulation facility was created to reproduce ISS noise profiles by modifying pink noise with a software-based graphic equalizer. The files were played in a continuous loop on a computer, amplified through a high-end stereo system and adjusted using a sound level meter. Nine caregiver analogues were given the same auscultation lesson received by astronauts. They began testing by becoming familiar with normal and abnormal sounds on a Student Auscultation Manikin . They then used two digital stethoscopes and a traditional stethoscope identical to the one flown on the ISS to auscultate the manikin sounds in the noise facility. They identified the sounds on a questionnaire and picked which of the three stethoscopes they preferred. Results: Evaluators displayed equivalent accuracy in sound identification when using either the 3M model 4000 digital stethoscope or traditional stethoscope. However, the 3M was preferred 2 to 1 by the evaluators, primarily because of additional amplification of the sounds. Discussion: Although our results show that the current ISS stethoscope and the "best-of-breed" digital stethoscope provide essentially the same auscultation utility, the latter has the advantage of recording and transmitting sounds to a remote physician. Since the astronaut caregivers are non-physiCians, this capability may be worth the additional expense and effort needed to certify the digital stethoscope for flight.

Rasbury, Jack↗

Developing Methods for Exercise System Kinematics Tracking

BACKGROUND How to quantify the load and forces produced by exercise equipment and their Vibration Isolation and Stabilization (VIS) platforms in-flight is an active area of investigation. Kinematic tracking paired with system modeling can provide insights as well as verification and validation of simulations used for system design and development. Traditional motion capture methods can require significant cost in equipment procurement and crew-time, but newer lessons learned can be leveraged [1]. The VIS systems of current and future exercise hardware on the International Space Station (ISS) such as the Cycle Ergometer with Vibration Isolation System (CEVIS) and the European Enhanced Exploration Exercise Device (E4D) are not currently outfitted with IMUs or similar measurement devices. Video-based methods would enable use of multi-purpose, crew-familiar flight equipment. An initial exploration of video-based solutions was performed utilizing 2-camera video from crew cycling on Teal-CEVIS on the ISS. METHODS AND RESULTS Our group has scoped a variety of video-based object tracking methods. To date, we have primarily investigated computer vision toolkits such as openCV. Techniques explored include key-point detection, background subtraction, region-of interest tracking, color-based tracking, tag masking and tracking, and corner detection. Although object-tracking and 6D pose estimation is a rich field, space applications are a unique problem that are challenging for existing software and toolkits. The majority of the existing object-tracking applications involve vehicles/pedestrians and household objects with simple backgrounds. We have identified the following features which pose particular challenges for on-station exercise equipment tracking: Busy and visually cluttered background Low-textured tracking object with relatively small motions Occlusions and motion by human subject and loose, floating objects Limited number of video cameras with no fixed global references Limited ability to add tags, markers, or visual references to the tracking object Lack of training data for Machine Learning (ML) algorithms CONCLUSION We will summarize the efficacy of techniques tested for a ground mock-trial and the on-station exercise trial. It is likely that human-in-loop feedback or a conglomerate of methods is required. ML-based methods, like those implemented for human body tracking [2], may still be a viable option, but more training data and validation is needed.

L B Nilsson↗

UTM UAS Service Supplier Development: Sprint 2 Toward Technical Capability Level 4

NASA's UAS Traffic Management (UTM) Project has been tasked with developing concepts and initial implementations for integrating and managing small unmanned aircraft systems (UAS) into the low altitude airspace. To accomplish this task, the UTM Project planned a phased approach based on four Technical Capability Levels (TCLs). As of this writing, TCL4 is currently in development for a late Spring 2019 flight demonstration. This TCL is focused on operations in an urban environment and includes the handling of high density environments, large-scale off-nominal conditions, vehicle-to-vehicle communications, detect-and-avoid technologies, communication requirements, public safety operations, airspace restrictions, and other related goals. Through research and testing to date, NASA has developed an architecture for UTM that depends on commercial entities collaboratively providing services that are traditionally provided by the Air Navigation Service Provider (ANSP) in manned aviation. A key component of this architecture is the UAS Service Supplier (USS), which acts as a communications bridge between UAS operators and the ANSP when necessary. In addition, the collection of USSs form a USS Network to collaboratively manage the airspace through the sharing of data and the adherence to a standard or set of standards required to participate in this USS Network. This document provides a record of the second of four planned steps in the development of interoperable USSs that will ultimately support TCL4 flight testing and formalization of the overall UTM concept. To develop these USSs and their underlying specifications, NASA has planned a series of "Sprints" to work with industry partners in implementing the features and develop proposed specifications for USSs in order to to participate in TCL4. This report describes Sprint Two. In this Sprint, there was a major theme with four goals. The theme was the development and testing of a new USS discovery system, to better enable USSs to find and communicate with each other. The goals supporting this theme were: participants needed to implement and exercise the discovery service for USS-USS communications; USSs needed to demonstrate strategic deconfliction through operation sharing; the systems were to use discovery to aid in handling off-nominal operations; and finally, there was an investigation of an initial off-nominal reporting capability.

software engineering↗

Predictive Modeling of Carbon Ablators

Efforts to build a Predictive Material Modeling (PMM) framework from the micro-scale to the macro-scale are presented in this abstract. To reduce the need for extensive testing, accelerate the design cycle process, and reduce uncertainty margins applied to final designs, NASA is developing simulation and modeling tools that enable characterization of material properties and response to high-enthalpy environments. The Porous Microstructure Analysis (PuMA) code has been developed for computing macroscale (volume averaged) properties of porous materials using microscale images from micro-computed tomography (micro-CT). Microscale modeling requires a realistic representation of a material microstructure; these are obtained either synthetically during the design of the material or through X-ray micro-CT. Volume averaged properties are then used to inform macroscale material response models, such as those implemented in the Porous-material Analysis Toolbox based on OpenFOAM (PATO) software, also actively developed by NASA. The computational model in PATO is a generic heat and mass transfer model for porous reactive materials containing several solid phases and a single gas phase. The detailed chemical interactions occurring between the solid phases and the gas phase are modeled at the pore scale assuming local thermal equilibrium. These tools were developed to efficiently interface with other pre-existing codes such as SPARTA (direct simulation Monte Carlo), DPLR (hypersonic CFD), NEQAIR (radiative transport) and DAKOTA (uncertainty quantification and optimization). Detailed flight data (Mars Science Laboratory [MSL] Entry Descent and Landing Instrument [MEDLI]) is critical for validating these computational tools for NASA applications. Examples of modeling ablative material response using these codes will be presented including 3D simulations of the full-scale heatshield of the MSL capsule. The simulations demonstrate the ability of the modern material response code, PATO, to handle the material response of geometrically complex and large domains, through the use of massively parallel computations.

Thermal Protection Systems↗