Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “automated experiments”

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,225 records · Page 68

Navigating Team Dynamics: Automated Detection of Micro-Behaviors Between Team Members Through Longitudinal Interaction Data

The success in future long term space exploration missions will depend on the cooperation, coordination, and mutual understanding among the crew members. Micro-behaviors are momentary, subtle linguistic and paralinguistic indicators of thinking and feeling toward another member of the team (Cortina et al., 2001; Smith & Griffiths, 2022) that can significantly impact team dynamics and influence the overall team performance (Paromita & Chaspari, 2024). Due to their interactive nature, micro-behaviors have a sender (i.e., the team member expressing the micro-behavior) and a target (the team member impacted by the micro-behavior). Detection of these behaviors can assist in avoiding possible conflict among crew members and promoting the overall team success. Our prior research focused on an initial proof of concept of machine learning (ML) models and natural language processing (NLP) techniques that were used for automatically detect micro-behaviors among crew members of the US National Aeronautics and Space Administration’s (NASA) Human Exploration Research Analog (HERA) Campaigns 4 and 5 missions (Paromita et al., 2023). Results underscored the importance of incorporating contextual information in the ML models in the form of sentiment analysis, type of task, and dyadic interaction among team members. Here, we expand the scope of our prior work in two ways. First, we assess ML/NLP methods on new behavioral annotations coded using an adapted version of Smith & Griffins (2022) theoretical framework in terms of Violation (i.e., presence of valenced behavior, uplifting/positive or discouraging/negative), Intensity (i.e., force of behavior in terms of how uplifting or discouraging is the behavior), and Intent (i.e., motive of the behavior in terms of whether it was deliberate or unintentional). Second, we expand the design of the ML model to preserve information about the role of each team member within the occurrence of the micro-behavior (in contrast to the previous model that only considered the sender and the target without determining the team member role). This allows to consider all team members' contributions in the conversation and model long-term dependencies in the dialogue. Our experiments for this study are conducted on data from 5 teams of the NASA HERA C4 (NASA grant NNX16AQ48G (PI: Bell)). Conversations were extracted from the 1.5 hour Team Interaction Battery (TIB) task that occurred 5 times in-mission per crew. This resulted in a total of 13,058 conversational turns (i.e., 17.8% uplifting, 3.3% discouraging, 75.76% neutral, 3.14% nulls). Our findings with the revised behavioral coding and ML/NLP models indicate a 43.66% macro F1-score (i.e., 38.29% precision (P), 50.8% recall (R)) for a dialog state-tracking model that includes information from the sender only, and a 40.9% F1-score (i.e., 38.7% P, 43.36% R) for the same model that includes information from both the sender and the target of the micro-behavior. These are significantly higher compared to simple random forest models that classify behaviors strictly based on speech content and do not consider iterative team dynamics, achieving a 36.07% F1-score (i.e., 39.04% R, 33.53% P). Our findings demonstrate potential ways to leverage large conversational datasets to better capture complex team dynamics. We will discuss future directions including proposed models that can incorporate additional mission days and tasks beyond the TIB for objectively quantifying team behavior at high temporal resolution in space exploration missions.

Projna Paromita↗

Reuse: A knowledge-based approach

This paper describes our research in automating the reuse process through the use of application domain models. Application domain models are explicit formal representations of the application knowledge necessary to understand, specify, and generate application programs. Furthermore, they provide a unified repository for the operational structure, rules, policies, and constraints of a specific application area. In our approach, domain models are expressed in terms of a transaction-based meta-modeling language. This paper has described in detail the creation and maintenance of hierarchical structures. These structures are created through a process that includes reverse engineering of data models with supplementary enhancement from application experts. Source code is also reverse engineered but is not a major source of domain model instantiation at this time. In the second phase of the software synthesis process, program specifications are interactively synthesized from an instantiated domain model. These specifications are currently integrated into a manual programming process but will eventually be used to derive executable code with mechanically assisted transformations. This research is performed within the context of programming-in-the-large types of systems. Although our goals are ambitious, we are implementing the synthesis system in an incremental manner through which we can realize tangible results. The client/server architecture is capable of supporting 16 simultaneous X/Motif users and tens of thousands of attributes and classes. Domain models have been partially synthesized from five different application areas. As additional domain models are synthesized and additional knowledge is gathered, we will inevitably add to and modify our representation. However, our current experience indicates that it will scale and expand to meet our modeling needs.

Iscoe, Neil↗

SAGE III/ISS v5.3 Level 2 Data Product Changes and Improvements

The Stratospheric Aerosol and Gas Experiment on the International Space Station (SAGE III/ISS) is an occultation instrument that acquires measurements of aerosols and gases within the Earth’s stratosphere and upper troposphere. SAGE III/ISS provides level 2 solar species products for aerosol extinction (9 channels), nitrogen dioxide (NO2), ozone (O3), and water vapor (H2O). The level 2 products currently provide three O3 profiles based on differing retrievals. The first O3 profile is based on measurements at short wavelengths within the Hartley-Huggins band (MesO3), the second O3 profile is based on measurements made at visible wavelengths within the Chappius band (MLR O3), and the final profile is found using a more SAGE II like approach (AO3). The SAGE III/ISS also provides level 2 lunar species products for ozone (O3), nitrogen dioxide (NO2), and nitrogen trioxide (NO3). Version 5.3 of the SAGE III/ISS retrieval algorithm introduces improvements that affect the level 2 data products. The largest change to the solar algorithm is the implementation of disturbance monitoring package (DMP) corrections to improve pointing accuracy. The DMP is comprised of a miniature inertial measurement unit that measures rotation in inertial space using ring laser gyroscopes oriented about three orthogonal axes which can be used to correct pointing errors caused by mechanical disturbances. A major change common to solar and lunar algorithms is meteorological input from the coarser 42 level Modern-Era Retrospective analysis for Research and Applications, Version 2 (MERRA-2) model data to the 72 level MERRA-2 model data. The final major change involves improving the automated quality assurance (QA) algorithm to recover events that were withheld from the public release because differences between the AO3 and MLR O3 for some events after the eruption of Tonga–Hunga Haʻapai. Other changes for v5.3 include minor bug fixes as well as restoration of some data quality flags that were removed in v5.21. This presentation presents the impacts of these changes as well as overall observations of interest from v5.3 level 2 data products.

Carter Hulsey↗

SAGE III/ISS v5.3 Level 2 Data Product Changes and Improvements

The Stratospheric Aerosol and Gas Experiment on the International Space Station (SAGE III/ISS) is an occultation instrument that acquires measurements of aerosols and gases within the Earth’s stratosphere and upper troposphere. SAGE III/ISS provides level 2 solar species products for aerosol extinction (9 channels), nitrogen dioxide (NO2), ozone (O3), and water vapor (H2O). The level 2 products currently provide three O3 profiles based on differing retrievals. The first O3 profile is based on measurements at short wavelengths within the Hartley-Huggins band (MesO3), the second O3 profile is based on measurements made at visible wavelengths within the Chappius band (MLR O3), and the final profile is found using a more SAGE II like approach (AO3). The SAGE III/ISS also provides level 2 lunar species products for ozone (O3), nitrogen dioxide (NO2), and nitrogen trioxide (NO3). Version 5.3 of the SAGE III/ISS retrieval algorithm introduces improvements that affect the level 2 data products. The largest change to the solar algorithm is the implementation of disturbance monitoring package (DMP) corrections to improve pointing accuracy. The DMP is comprised of a miniature inertial measurement unit that measures rotation in inertial space using ring laser gyroscopes oriented about three orthogonal axes which can be used to correct pointing errors caused by mechanical disturbances. A major change common to solar and lunar algorithms is meteorological input from the coarser 42 level Modern-Era Retrospective analysis for Research and Applications, Version 2 (MERRA-2) model data to the 72 level MERRA-2 model data. The final major change involves improving the automated quality assurance (QA) algorithm to recover events that were withheld from the public release because differences between the AO3 and MLR O3 for some events after the eruption of Tonga–Hunga Haʻapai. Other changes for v5.3 include minor bug fixes as well as restoration of some data quality flags that were removed in v5.21. This presentation presents the impacts of these changes as well as overall observations of interest from v5.3 level 2 data products.

Carter Hulsey↗

Rheoencephalographic (REG) Assessment of Head and Neck Cooling for use with Multiple Sclerosis Patients

We have prepared a computer program (RHEOSYS:RHEOencephalographic impedance trace scanning SyStem) that can be used to automate the analysis of segmental impedance blood flow waveforms. This program was developed to assist in the post test analysis of recorded impedance traces from multiple segments of the body. It incorporates many of the blood flow, segmental volume, and vascular state indices reported in the world literature. As it is currently programmed, seven points are selected from each blood flow pulse and associated ECG waveforrn: 1. peak of the first ECG QRS complex, 2. start of systolic slope on the blood flow trace, 3. maximum amplitude of the impedance pulse, 4. position of the dicrotic notch, 5. maximum amplitude of the postdicrotic segment, 6. peak of the second ECG QRS complex, and 7. start of the next blood flow pulse. These points we used to calculate various geometric, area, and time-related values associated with the impedance pulse morphology. RHEOSYS then calculates a series of 34 impedance and cardiac cycle parameters which include pulse amplitudes; areas; pulse propagation times; cardiac cycle times; and various measures of arterial and various tone, contractility, and pulse volume. We used this program to calculate the scalp and intracranial blood flow responses to head and neck cooling as it may be applied to lower the body temperatures of multiple sclerosis patients. Twelve women and twelve men were tested using a commercially available head and neck cooling system operated at its maximum cooling capacity for a period of 30 minutes. Head and neck cooling produced a transient change in scalp blood flow and a significant, (P<0.05) decrease of approx. 30% in intracranial blood flow. Results of this experiment will illustrate how REG and RHEOSYS can be used in biomedical applications.

Montogomery, Leslie D.↗

Instrumentation for Examining Microbial Response to Changes In Environmental Pressures

The Automated Adaptive Directed Evolution Chamber (AADEC) is a device that allows operators to generate a micro-scale analog of real world systems that can be used to model the local-scale effects of climate change on microbial ecosystems. The AADEC uses an artificial environment to expose cultures of micro-organisms to environmental pressures, such as UV-C radiation, chemical toxins, and temperature. The AADEC autonomously exposes micro-organisms to selection pressures. This improves upon standard manual laboratory techniques: the process can take place over a longer period of time, involve more stressors, implement real-time adjustments based on the state of the population, and minimize the risk of contamination. We currently use UV-C radiation as the main selection pressure, UV-C is well studied both for its cell and DNA damaging effects as a type of selection pressure and for its related effectiveness as a mutagen; having these functions united makes it a good choice for a proof of concept. The AADEC roadmap includes expansion to different selection pressures, including heavy metal toxicity, temperature, and other forms of radiation.The AADEC uses closed-loop control to feedback the current state of the culture to the AADEC controller that modifies selection pressure intensity during experimentation, in this case culture density and growth rate. Culture density and growth rate are determined by measuring the optical density of the culture using 600 nm light. An array of 600 nm LEDs illuminate the culture and photodiodes are used to measure the shadow on the opposite side of the chamber.Previous experiments showed that we can produce a million fold increase to UV-C radiation over seven iterations. The most recent implements a microfluidic system that can expose cultures to multiple different selection pressures, perform non-survival based selection, and autonomously perform hundreds of exposure cycles. A scalable pump system gives the ability to pump in various different growth media to individual cultures and introduce chemical toxins during experimentation; AADEC can perform freeze and thaw cycles. We improved our baseline characterization by building a custom UV-C exposure hood, a shutter operates on a preset timer allowing the user to set exposure intensity consistently for multiple iterations.

Environment↗

MarCO: Interplanetary Mission Development on a CubeSat Scale

Shortly after JPL’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission launches, separates, and commences its cruise phase, two CubeSats will deploy from the launch vehicle’s upper stage and begin independent flight to Mars (Fig. 1). During InSight’s entry, descent, and landing (EDL) sequence, these twin Mars Cube One (MarCO) spacecraft will fly 3,500 km above the Martian surface, recording and relaying InSight UHF radio data to the Deep Space Network (DSN) on Earth1. MarCO is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration. Originally slated to launch and reach Mars in 2016, the InSight mission schedule subsequently slipped to 2018. During the original landing of InSight, Earth would not be in view, and no orbiter around Mars would have been in position to both receive UHF EDL data and simultaneously relay it back to Earth. It was from this obstacle that MarCO was conceived. Regardless of any changes to InSight’s 2018 EDL configuration geometry, MarCO is still expected to fly and serve in the same capacity as originally designed: the first CubeSat mission to Mars. CubeSats have historically been firmly in the domain of universities and small companies. As first conceived, they served as a platform upon which to teach all aspects of the space mission lifecycle. JPL took on this mission type with Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment2 (INSPIRE), moving the concept into a new domain: deep space. Building from the INSPIRE platform and lessons learned, MarCO addressed new challenges in the domain of planetary missions: independent interplanetary flight and navigation, integration with a large-scale mission, long-distance and long-delay communication, short development time, and a small development team. Of these, the greatest constraint was schedule: only 18 months passed from conception of mission concept until delivery of fully assembled and tested flight hardware. Careful selection of mission team, along with extensive use of off-the-shelf equipment, and streamlining automated processes, was essential. This achievement represents the next step in the evolution of CubeSats beyond low-Earth orbit.

Werne, Thomas↗

Finding Atmospheric Composition (AC) Metadata

The Atmospheric Composition Portal (ACP) is an aggregator and curator of information related to remotely sensed atmospheric composition data and analysis. It uses existing tools and technologies and, where needed, enhances those capabilities to provide interoperable access, tools, and contextual guidance for scientists and value-adding organizations using remotely sensed atmospheric composition data. The initial focus is on Essential Climate Variables identified by the Global Climate Observing System CH4, CO, CO2, NO2, O3, SO2 and aerosols. This poster addresses our efforts in building the ACP Data Table, an interface to help discover and understand remotely sensed data that are related to atmospheric composition science and applications. We harvested GCMD, CWIC, GEOSS metadata catalogs using machine to machine technologies - OpenSearch, Web Services. We also manually investigated the plethora of CEOS data providers portals and other catalogs where that data might be aggregated. This poster is our experience of the excellence, variety, and challenges we encountered.Conclusions:1.The significant benefits that the major catalogs provide are their machine to machine tools like OpenSearch and Web Services rather than any GUI usability improvements due to the large amount of data in their catalog.2.There is a trend at the large catalogs towards simulating small data provider portals through advanced services. 3.Populating metadata catalogs using ISO19115 is too complex for users to do in a consistent way, difficult to parse visually or with XML libraries, and too complex for Java XML binders like CASTOR.4.The ability to search for Ids first and then for data (GCMD and ECHO) is better for machine to machine operations rather than the timeouts experienced when returning the entire metadata entry at once. 5.Metadata harvest and export activities between the major catalogs has led to a significant amount of duplication. (This is currently being addressed) 6.Most (if not all) Earth science atmospheric composition data providers store a reference to their data at GCMD.

metadata search↗

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↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospace's command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for users to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS "App Store".. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

Computer Programming and Software↗

Pilot Critical Incident Reports as a Means to Identify Human Factors of Remotely Piloted Aircraft

It has been estimated that aviation accidents are typically preceded by numerous minor incidents arising from the same causal factors that ultimately produced the accident. Accident databases provide in-depth information on a relatively small number of occurrences, however incident databases have the potential to provide insights into the human factors of Remotely Piloted Aircraft System (RPAS) operations based on a larger volume of less-detailed reports. Currently, there is a lack of incident data dealing with the human factors of unmanned aircraft systems. An exploratory study is being conducted to examine the feasibility of collecting voluntary critical incident reports from RPAS pilots. Twenty-three experienced RPAS pilots volunteered to participate in focus groups in which they described critical incidents from their own experience. Participants were asked to recall (1) incidents that revealed a system flaw, or (2) highlighted a case where the human operator contributed to system resilience or mission success. Participants were asked to only report incidents that could be included in a public document. During each focus group session, a note taker produced a de-identified written record of the incident narratives. At the end of the session, participants reviewed each written incident report, and made edits and corrections as necessary. The incidents were later analyzed to identify contributing factors, with a focus on design issues that either hindered or assisted the pilot during the events. A total of 90 incidents were reported. Human factor issues included the impact of reduced sensory cues, traffic separation in the absence of an out-the-window view, control latencies, vigilance during monotonous and ultra-long endurance flights, control station design considerations, transfer of control between control stations, the management of lost link procedures, and decision-making during emergencies. Pilots participated willingly and enthusiastically in the study, and generally had little difficulty recalling critical incidents. The results suggest that pilot interviews can be a productive method of gathering information on incidents that might not otherwise be reported. Some of the issues described in the reports have received significant attention in the literature, or are analogous to human factors of manned aircraft. In other cases, incident reports involved human factors that are poorly understood, and have not yet been the subject of extensive study. Although many of the reported incidents were related to pilot error, the participants also provided examples of the positive contribution that humans make to the operation of highly-automated systems.

unmanned aircraft systems↗

Increasing Flight Software Reuse with OpenSatKit

In January 2015 the NASA Goddard Space Flight Center (GSFC) released the Core Flight System (cFS) as open source under the NASA Open Source Agreement (NOSA) license. The cFS is based on flight software (FSW) developed for 12 spacecraft spanning nearly two decades of effort and it can provide about a third of the FSW functionality for a low-earth orbiting scientific spacecraft. The cFS is a FSW framework that is portable, configurable, and extendable using a product line deployment model. However, the components are maintained separately so the user must configure, integrate, and deploy them as a cohesive functional system. This can be very challenging especially for organizations such as universities building cubesats that have minimal experience developing FSW. Supporting universities was one of the primary motivators for releasing the cFS under NOSA. This paper describes the OpenSatKit that was developed to address the cFS deployment challenges and to serve as a cFS training platform for new users. It provides a fully functional out-of-the box software system that includes NASA's cFS, Ball Aerospaceâ€"TM"s command and control system COSMOS, and a NASA dynamic simulator called 42. The kit is freely available since all of the components have been released as open source. The kit runs on a Linux platform, includes 8 cFS applications, several kit-specific applications, and built in demos illustrating how to use key application features. It also includes the software necessary to port the cFS to a Raspberry Pi and instructions for configuring COSMOS to communicate with the target. All of the demos and test scripts can be rerun unchanged with the cFS running on the Raspberry Pi. The cFS uses a 3-tiered layered architecture including a platform abstraction layer, a Core Flight Executive (cFE) middle layer, and an application layer. Similar to smart phones, the cFS application layer is the key architectural feature for userâ€"TM"s to extend the FSW functionality to meet their mission-specific requirements. The platform abstraction layer and the cFE layers go a step further than smart phones by providing a platform-agnostic Application Programmer Interface (API) that allows applications to run unchanged on different platforms. OpenSatKit can serve two significant architectural roles that will further help the adoption of the cFS and help create a community of users that can share assets. First, the kit is being enhanced to automate the integration of applications with the goal of creating a virtual cFS 'App Store'. Second, a platform certification test suite can be developed that would allow users to verify the port of the cFS to a new platform. This paper will describe the current state of these efforts and future plans.

McComas, David↗

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗

An Approach to Identifying Aspects of Positive Pilot Behavior within the Aviation Safety Reporting System

The National Airspace System (NAS) is constantly evolving as air traffic continues to ramp up to pre-pandemic numbers and projected to grow to unprecedented levels in the coming years. As well as increasing demand to the current system, emerging operations such as Unmanned Autonomous Systems are also expected to add to complexity in the airspace. To address these issues, the industry and government agencies supporting the NAS will need to rely upon additional automation and new technologies to address future operational requirements, while continuing to be a world-leading safe transportation system. As these new technologies are implemented, the system continues to rely on human pilots and controllers in the loop to monitor the system and intervene in situations the automation cannot handle. The goal of proactively addressing safety is of foremost concern to ensure passenger confidence. The industry has implemented various Safety Monitoring Systems to identify safety risks and proactively address them before they result in a serious incident or accident. One such program is the Aviation Safety Reporting System (ASRS). ASRS is a long-established system where pilots and controllers voluntarily and anonymously report safety incidents they experienced and observed during line operations by providing rich text narratives describing the events, the environment, and conditions leading to the safety event of concern. These narratives provide insight and context around events of interest and can be used to identify emerging problems. They can trigger investigations within Flight Operational Quality Assurance or Flight Data Monitoring programs. However, this process typically focuses on the adverse events and the unsafe aspects of the operations surrounding the reported or detected events. This perspective of investigating factors that went wrong around an adverse event is commonly referred to as Safety I. Alternatively, characterizing successful actions that operators perform every day under varying conditions that keep the system within safe operating bounds is a concept referred to as Safety II. The benefit of the Safety II view is that the scope is much larger than that of Safety I since a vast majority of the operations result in successful flights. Many of the successful techniques used to manage operational threats are not documented in standard operating procedures or taught during training. They are typically acquired over time by working with experienced pilots during line operations or in many cases after experiencing a problem for the first time and reacting to it in situ, drawing from years of experience to manage the threat. In an attempt to quantify these positive actions, we are proposing an approach to extracting key behaviors within ASRS reports that can support the Safety II concept. Our analysis assumes that ASRS reports contain some descriptions of corrective actions that operators performed to prevent a situation from leading to an accident. Leveraging recent advances in Natural Language Process modeling, we have developed an approach to extract positive sentiment from reports, embed these positive statements in a vector space where they can be numerically analyzed, and clustering these statements into similar contextual categories. From these contextualized categories we can attempt to summarized and distilled aspects of the positive behavior. The goal is to identify categories of behavior that describe consistent operator techniques that supports the Safety II concept. With this information, airlines may enable learning from these positive actions, or address procedures that need to be changed to avoid having pilots implement a workaround. These insights can provide a lens into what is “going right” in the operations that may otherwise not be known widely within the community. It is envisioned that this approach can be extended to other narrative programs such as Line Operation Safety Audit or Learning Improvement Team reports where similar observed behavior can be analyzed to extract positive actions and inform the overall operations.

NLP↗

Flexible Microsensor Array for the Monitoring and Control of Plant Growth System

Testing for plant experiments in space has begun to explore active nutrient delivery concepts in which water and nutrients are replenished on a continuous basis for long-term growth. The goal of this study is to develop a novel microsensor array to provide information on the dissolved oxygen environment in the plant root zone for the optimum control of hydroponics and solid substrate plant cultivation systems in the space environment. Miniaturized polarographic dissolved oxygen sensors have been designed and fabricated on a flexible Kapton (trademark) (polyimide) substrate. Two capabilities of the new microsensor array were explored. First, measurements of dissolved oxygen in the plant root zone in hydroponics and solid substrate culture systems were made. The microsensor array was fabricated on a flexible substrate, and then cut out into a mesh type to make a suspended array that could be placed either in a hydroponics system or in a solid substrate cultivation system to measure the oxygen environments. Second, the in situ self-diagnostic and self-calibration capability (two-point for oxygen) was adopted by dynamically controlling the microenvironment in close proximity to the microsensors. With a built-in generating electrode that surrounds the microsensor, two kinds of microenvironments (oxygen-saturated and oxygen-depleted phases) could be established by water electrolysis depending on the polarity of the generating electrode. The unique features of the new microsensor array (small size, multiple sensors, flexibility and self-diagnosis) can have exceptional benefits for the study and optimization of plant cultivation systems in both terrestrial and microgravity environments. The in situ self-diagnostic and self-calibration features of the microsensor array will also enable continuous verification of the operability during entire plant growth cycles. This concept of automated control of a novel chemical monitoring system will minimize crew time required for maintenance, as well as reduce volume, mass, and power consumption by eliminating bulky diagnosis systems including calibrant (fluid and gas) reservoir and flow system hardware.

Kim, Chang-Soo↗

Challenges of Integrating NASAs Space Communication Networks

The transition to new technology, innovative ideas, and resistance to change is something that every industry experiences. Recent examples of this shift are changing to using robots in the assembly line construction of automobiles or the increasing use of robotics for medical procedures. Most often this is done with cost-reduction in mind, though ease of use for the customer is also a driver. All industries experience the push to increase efficiency of their systems; National Aeronautics and Space Administration (NASA) and the commercial space industry are no different. NASA space communication services are provided by three separately designed, developed, maintained, and operated communications networks known as the Deep Space Network (DSN), Near Earth Network (NEN) and Space Network (SN). The Space Communications and Navigation (SCaN) Program is pursuing integration of these networks and has performed a variety of architecture trade studies to determine what integration options would be the most effective in achieving a unified user mission support organization, and increase the use of common operational equipment and processes. The integration of multiple, legacy organizations and existing systems has challenges ranging from technical to cultural. The existing networks are the progeny of the very first communication and tracking capabilities implemented by NASA and the Jet Propulsion Laboratory (JPL) more than 50 years ago and have been customized to the needs of their respective user mission base. The technical challenges to integrating the networks are many, though not impossible to overcome. The three distinct networks provide the same types of services, with customizable data rates, bandwidth, frequencies, and so forth. The differences across the networks have occurred in effort to satisfy their user missions' needs. Each new requirement has made the networks more unique and harder to integrate. The cultural challenges, however, have proven to be a significant obstacle for integration. Over the past few decades of use, user missions and network personnel alike have grown accustomed to the processes by which services are provided by the NASA communications and navigation networks. The culture established by each network has created several challenges that need to be overcome in order to effectively integrate the networks. As with any change, there has been resistance, an apprehension to explore automation of existing processes, and a working environment that attempts to indirectly influence change without mandating compliance. Overcoming technical and cultural challenges is essential to successfully integrating the networks and although the challenges are numerous, the integration of the networks promises a more efficient space communications network for NASA and its customers, as well as potential long-term cost savings to the agency. This paper, Challenges of Integrating NASA Legacy Communications Networks, will provide a brief overview of the current NASA space communications networks as well as the an overview of the process implemented while performing the SCaN Trade Studies and an introduction to the requirements driving integration of the SCaN Networks. This paper will describe in detail the challenges experienced, both technical and cultural, while working with NASA space communications network-specific personnel. The paper will also cover lessons learned during the performance of architecture trade studies and provide recommendations for ways to improve the process.

Reinert, Jessica M.↗

Challenges of Integrating NASA's Space Communications Networks

The transition to new technology, innovative ideas, and resistance to change is something that every industry experiences. Recent examples of this shift are changing to using robots in the assembly line construction of automobiles or the increasing use of robotics for medical procedures. Most often this is done with cost-reduction in mind, though ease of use for the customer is also a driver. All industries experience the push to increase efficiency of their systems; National Aeronautics and Space Administration (NASA) and the commercial space industry are no different. NASA space communication services are provided by three separately designed, developed, maintained, and operated communications networks known as the Deep Space Network (DSN), Near Earth Network (NEN) and Space Network (SN). The Space Communications and Navigation (SCaN) Program is pursuing integration of these networks and has performed a variety of architecture trade studies to determine what integration options would be the most effective in achieving a unified user mission support organization, and increase the use of common operational equipment and processes. The integration of multiple, legacy organizations and existing systems has challenges ranging from technical to cultural. The existing networks are the progeny of the very first communication and tracking capabilities implemented by NASA and the Jet Propulsion Laboratory (JPL) more than 50 years ago and have been customized to the needs of their respective user mission base. The technical challenges to integrating the networks are many, though not impossible to overcome. The three distinct networks provide the same types of services, with customizable data rates, bandwidth, frequencies, and so forth. The differences across the networks have occurred in effort to satisfy their user missions' needs. Each new requirement has made the networks more unique and harder to integrate. The cultural challenges, however, have proven to be a significant obstacle for integration. Over the past few decades of use, user missions and network personnel alike have grown accustomed to the processes by which services are provided by the NASA communications and navigation networks. The culture established by each network has created several challenges that need to be overcome in order to effectively integrate the networks. As with any change, there has been resistance, an apprehension to explore automation of existing processes, and a working environment that attempts to indirectly influence change without mandating compliance. Overcoming technical and cultural challenges is essential to successfully integrating the networks and although the challenges are numerous, the integration of the networks promises a more efficient space communications network for NASA and its customers, as well as potential long-term cost savings to the agency. This paper, Challenges of Integrating NASA Legacy Communications Networks, will provide a brief overview of the current NASA space communications networks as well as the an overview of the process implemented while performing the SCaN Trade Studies and an introduction to the requirements driving integration of the SCaN Networks. This paper will describe in detail the challenges experienced, both technical and cultural, while working with NASA space communications network-specific personnel. The paper will also cover lessons learned during the performance of architecture trade studies and provide recommendations for ways to improve the process.

Systems Integration↗