Results for “workarounds,” — Page 3

NASA NTRS2011

The Evolution of Utilizing Manual Throttles to Avoid Excessively Low LH2 NPSP at the SSME Inlet

In the late 1970s, years before the Space Shuttle flew its maiden voyage, it was understood low liquid hydrogen (LH2) Net Positive Suction Pressure (NPSP) at the inlet to the Space Shuttle Main Engine (SSME) could have adverse effects on engine operation. A number of failures within both the External Tank (ET) and the Orbiter Main Propulsion System (MPS) could result in a low LH2 NPSP condition, which at extremely low levels can result in cavitation of SSME turbomachinery. Operational workarounds were developed to take advantage of the onboard crew s ability to manually throttle down the SSMEs (via the Pilot s Speedbrake/Throttle Controller), which alleviated the low LH2 NPSP condition. Manually throttling the SSME to a lower power level resulted in an increase in NPSP, mainly due to the reduction in frictional flow losses while at the lower throttle setting. Early in the Space Shuttle Program s history, the relevant Flight Rule for the Booster flight controllers in Mission Control did not distinguish between ET and Orbiter MPS failures and the same crew action was taken for both. However, after a review of all Booster operational techniques following the Challenger disaster in the late 1980s, it was determined manually throttling the SSME to a lower power was only effective for Orbiter MPS failures and the Flight Rule was updated to reflect this change. The Flight Rule and associated crew actions initially called for a single throttle step to minimum power level when a low threshold for NPSP was met. As engineers refined their understanding of the NPSP requirements for the SSME (through a robust testing program), the operational techniques evolved to take advantage of the additional capabilities. This paper will examine the evolution of the Flight rule and associated procedure and how increases in knowledge about the SSME and the Space Shuttle vehicle as a whole have helped shape their development. What once was a single throttle step when NPSP decreased to a certain threshold has now become three throttle steps, each occurring at a lower NPSP threshold. Additionally the procedure, which for early Space Shuttle missions required a Return-to-Launch-Site abort, now results in a nominal Main Engine Cut Off and no loss of mission objectives.

Henfling, Rick↗

NASA NTRS2007

United Space Alliance LLC Parachute Refurbishment Facility Model

The Parachute Refurbishment Facility Model was created to reflect the flow of hardware through the facility using anticipated start and delivery times from a project level IV schedule. Distributions for task times were built using historical build data for SFOC work and new data generated for CLV/ARES task times. The model currently processes 633 line items from 14 SFOC builds for flight readiness, 16 SFOC builds returning from flight for defoul, wash, and dry operations, 12 builds for CLV manufacturing operations, and 1 ARES 1X build. Modeling the planned workflow through the PRF is providing a reliable way to predict the capability of the facility as well as the manpower resource need. Creating a real world process allows for real world problems to be identified and potential workarounds to be implemented in a safe, simulated world before taking it to the next step, implementation in the real world.

Esser, Valerie↗

NASA NTRS2008

The Application of the Human Engineering Modeling and Performance Laboratory for Space Vehicle Ground Processing Tasks at Kennedy Space Center

The introduction of United Space Alliance's Human Engineering Modeling and Performance Laboratory began in early 2007 in an attempt to address the problematic workspace design issues that the Space Shuttle has imposed on technicians performing maintenance and inspection operations. The Space Shuttle was not expected to require the extensive maintenance it undergoes between flights. As a result, extensive, costly resources have been expended on workarounds and modifications to accommodate ground processing personnel. Consideration of basic human factors principles for design of maintenance is essential during the design phase of future space vehicles, facilities, and equipment. Simulation will be needed to test and validate designs before implementation.

Woodbury, Sarah K.↗

NASA NTRS2015

ISS Regenerative Life Support: Challenges and Success in the Quest for Long-Term Habitability in Space

The International Space Station's (ISS) Regenerative Environmental Control and Life Support System (ECLSS) was launched in 2008 to continuously recycle urine and crew sweat into drinking water and oxygen using brand new technologies. This functionality was highly important to the ability of the ISS to transition to the long-term goal of 6-crew operations as well as being critical tests for long-term space habitability. Through the initial activation and long-term operations of these systems, important lessons were learned about the importance of system redundancy and operational workarounds that allow Systems Engineers to maintain functionality with limited on-orbit spares. This presentation will share some of these lessons learned including how to balance water through the different systems, store and use water for use in system failures and creating procedures to operate the systems in ways that they were not initially designed to do.

Bazley, Jesse↗

NASA NTRS2016

Development of a Prototype Model-Form Uncertainty Knowledge Base

Uncertainties are generally classified as either aleatory or epistemic. Aleatory uncertainties are those attributed to random variation, either naturally or through manufacturing processes. Epistemic uncertainties are generally attributed to a lack of knowledge. One type of epistemic uncertainty is called model-form uncertainty. The term model-form means that among the choices to be made during a design process within an analysis, there are different forms of the analysis process, which each give different results for the same configuration at the same flight conditions. Examples of model-form uncertainties include the grid density, grid type, and solver type used within a computational fluid dynamics code, or the choice of the number and type of model elements within a structures analysis. The objectives of this work are to identify and quantify a representative set of model-form uncertainties and to make this information available to designers through an interactive knowledge base (KB). The KB can then be used during probabilistic design sessions, so as to enable the possible reduction of uncertainties in the design process through resource investment. An extensive literature search has been conducted to identify and quantify typical model-form uncertainties present within aerospace design. An initial attempt has been made to assemble the results of this literature search into a searchable KB, usable in real time during probabilistic design sessions. A concept of operations and the basic structure of a model-form uncertainty KB are described. Key operations within the KB are illustrated. Current limitations in the KB, and possible workarounds are explained.

Green, Lawrence L.↗

NASA NTRS2015

Precise Pointing for Radio Science Occultations and Radar Mapping During the Cassini Mission at Saturn

This paper discusses the implementation challenges and lessons learned from radar and radio science pointing observations during the Cassini mission at Saturn. Implementation of the precise desired pointing reveals key issues in the ground system, the flight system, and the pointing paradigm itself. To achieve accurate pointing on some observations, specific workarounds had to be implemented and folded into the sequence development process. Underlying Cassini's pointing system is a remarkable construct known as Inertial Vector Propagation.

Burk, Thomas A.↗

NASA NTRS2016

Thomas Leps Internship Abstract

An optical navigation system is being flown as the backup system to the primary Deep Space Network telemetry for navigation and guidance purposes on Orion. This is required to ensure Orion can recover from a loss of communication, which would simultaneously cause a loss of DSN telemetry. Images taken of the Moon and Earth are used to give range and position information to the navigation computer for trajectory calculations and maneuver execution. To get telemetry data from these images, the size and location of the moon need to be calculated with high accuracy and precision. The reentry envelope for the Orion EM-1 mission requires the centroid and radius of the moon images to be determined within 1/3 of a pixel 3 sigma. In order to ensure this accuracy and precision can be attained, I was tasked with building precise dot grid images for camera calibration as well as building a hardware in the loop test stand for flight software and hardware proofing. To calibrate the Op-Nav camera a dot grid is imaged with the camera, the error between the image dot location and the actual dot location can be used to build a distortion map of the camera and lens system so that images can be fixed to display truth locations. To build the dot grid images I used the Electro Optics Lab optical bench Bright Object Simulator System, and gimbal. The gimbal was slewed to a series of elevations and azimuths. An image of the collimated single point light source was then taken at each position. After a series of 99 images were taken at different locations the single light spots were extracted from each image and added to a composite image containing all 99 points. During the development of these grids it was noticed that an intermittent error in the artificial "star" locations occurred. Prior to the summer this error was attributed to the gimbal having glitches in it's pointing direction and was going to be replaced, however after further examining the issue I determined it to be a software issue. I have since narrowed the likely source of the error down to a Software Development Kit released by the camera supplier PixeLink. I have since developed a workaround in order to build star grids for calibration until the software bug can be isolated and fixed. I was also tasked with building a Hardware in the Loop test stand in order to test the full Op-Nav system. A 4k screen displays simulated Lunar and Terrestrial images from a possible Orion trajectory. These images are then projected through a collimator and then captured with an Op-Nav camera controlled by an Intel NUC computer running flight software. The flight software then analyzes the images to determine attitude and position, this data is then reconstructed into a trajectory and matched to the simulated trajectory in order to determine the accuracy of the attitude and position estimates. In order for the system to work it needs to be precisely and accurately aligned. I developed an alignment procedure that allows the screen, collimator and camera to be squared, centered and collinear with each other within a micron spatially and 5 arcseconds in rotation. I also designed a rigid mount for the screen that was machined on site in Building 10 by another intern. While I was working in the EOL we received a $500k Orion startracker for alignment procedure testing. Due to my prior experience in electronics development, as an ancillary duty, I was tasked with building the cables required to operate and power the startracker. If any errors are made building these cables the startracker would be destroyed, I was honored that the director of the lab entrusted such a critical component with me. This internship has cemented my view on public space exploration. I always preferred public sector to privatization because, as a scientist, the most interesting aspects of space for me are not necessarily the most profitable. I was concerned that the public sector was faltering however, and that in order to improve human space exploration I would be forced into private sector. I now know that, at least at JSC, human spaceflight is still progressing, and exciting work is still being done. I am now actively seeking employment at JSC after I complete my Ph.D and have met with my branch chiefs and mentor to discuss transitioning to a grad Co-op position.

Leps, Thomas↗

NASA NTRS2016

Essential SpaceWire Hardware Capabilities for a Robust Network

The Geostationary Operational Environmental Satellite R-Series Program (GOES-R) mission is a joint program between National Oceanic & Atmospheric Administration (NOAA) and National Aeronautics & Space Administration (NASA) Goddard Space Flight Center (GSFC). GOES-R project selected SpaceWire as the best solution to satisfy the desire for simple and flexible instrument to spacecraft command and telemetry communications. GOES-R development and integration is complete and the observatory is scheduled for launch October 2016. The spacecraft design was required to support redundant SpaceWire links for each instrument side, as well as to route the fewest number of connections through a Slip Ring Assembly necessary to support Solar pointing instruments. The final design utilized two different router designs. The SpaceWire standard alone does not ensure the most practical or reliable network. On GOES-R a few key hardware capabilities were identified that merit serious consideration for future designs. Primarily these capabilities address persistent port stalls and the prevention of receive buffer overflows. Workarounds were necessary to overcome shortcomings that could be avoided in future designs if they utilize the capabilities, discussed in this paper, above and beyond the requirements of the SpaceWire standard.

SpaceWire↗

NASA NTRS2018

Considerations When Building Thermal Models that Require Conversion Between Formats

At times, it is inevitable to require conversion of thermal models from one software format to another. This most often occurs for missions with international partners where not all parties utilize the same software packages for thermal analysis. Mandating a single tool for all parties is one possible solution, but this approach can introduce problems if significant effort is required to overcome inexperience with the designated tool and may result in difficulty meeting analysis schedule requirements. Alternatively, allowing all parties to use their own familiar tools minimizes the impact to analysis schedules but does introduce the need to convert the models later to a common format for analysis at a higher level of assembly. External conversion tools and formats have been developed through the years to aid in this process, but have had limited success in fully converting models seamlessly. Having a basic familiarity with tool capabilities on both sides of the conversion process allows for models to be built in a manner to better facilitate conversion by avoiding features and capabilities which are unsupported by the destination tool or for which no workarounds exist. Also, the effort to convert a model is often neglected when developing the schedules for analysis at the higher assembly levels; delivery of models preconditioned for convertibility minimizes the schedule risk. This paper seeks to provide some guidance on modeling techniques to avoid when developing Geometrical Math Models (GMM) and Thermal Math Models (TMM) when conversion is required. The recommendations are based on GMM conversion experiences between TSS/ThermalDesktop/ESARAD and TMM conversions between SINDA-FLUINT/ESATAN.

Modeling↗

NASA NTRS2019

SCREAM: Space-based Cognitive Reliability Error Analysis Method

Given both ground-based performance shaping factors (PSFs) collected by the U.S. Nuclear Regulatory Commission (USNRC) and potential space-based PSFs collected by JSC's HH&P, this year's task is to determine how to combine them for future human reliability analysis (HRA) of space missions. All HRA to date for space missions have been based on ground data (i.e. 1-G environment). There is no space-based HRA approach. The target of this project to produce a "first of its kind" HRA approach for space missions. As humans go beyond Earth orbit and missions become longer, human performance and reliability is expected to degrade. The questions become by how much, when, and what, leading to defining the overall effect on crew risk. Knowing this information earlier rather than later will help us mitigate this risk by vehicle design, crew training, and operational workarounds.

Boyer, Roger L.↗

NASA NTRS2019

Challenges Using Linux as a Real-Time Operating System

Human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab have been using Linux as a real-time operating system (RTOS) for over a decade. More recently, SpaceX has revealed that it is using Linux as an RTOS for its Falcon launch vehicles and Dragon capsules. As Linux makes its way from ground facilities to flight critical systems, it is necessary to recognize that the real-time capabilities in Linux are cobbled onto a kernel architecture designed for general purpose computing. The Linux kernel contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the kernel to restore a high probability that Linux will achieve deadlines.

Madden, Michael M.↗

NASA NTRS2019

Challenges Using the Linux Network Stack for Real-Time Communication

Starting in the early 2000s, human-in-the-loop (HITL) simulation groups at NASA and the Air Force Research Lab began using the Linux network stack for some real-time communication. More recently, SpaceX has adopted Ethernet as the primary bus technology for its Falcon launch vehicles and Dragon capsules. As the Linux network stack makes its way from ground facilities to flight critical systems, it is necessary to recognize that the network stack is optimized for communication over the open Internet, which cannot provide latency guarantees. The Internet protocols and their implementation in the Linux network stack contain numerous design decisions that favor throughput over determinism and latency. These decisions often require workarounds in the application or customization of the stack to maintain a high probability of low latency on closed networks, especially if the network must be fault tolerant to single event upsets.

Madden, Michael M.↗

NASA NTRSDate not supplied

Space Shuttle Cargo Integration Coupled Loads Analysis Lessons Learned

When a system experiences a loading environment characterized by rapidly varying forces, such as a rocket launch, a transient analysis is used to analyze the response of the system. The most common transient analysis methodology is the Coupled Loads Analysis (CLA). CLAs are used by the automotive and aerospace industry to analyze cars, trucks, planes, helicopters, spacecraft, etc. The Space Shuttle program used the CLA methodology to assess the compatibility of the payload with the Orbiter and the flight environment. The Space Shuttle Verification Loads Analysis (VLA) was a standardized CLA process that started between ten and thirteen months prior to launch, and included several meetings as well as analysis by both the Space Shuttle Program and the payload developers to verify that the payloads were compatible with the flight loads environment and would not interact negatively with the vehicle. Over the course of the Space Shuttle Program, many improvements were made to the process, which reduced cycle time and improved manifest flexibility. There were several issues which were never fully addressed, but workarounds were developed to keep the process flowing. The lessons learned included automation of some processes and standardization of others, early assessments, improved documentation and better coordination with all stakeholders in the process. Lessons learned also included the limitations in the current process, and what to do to avoid the same issues in the future.

Erica E. Bruno↗

NASA NTRSDate not supplied

Goes-16 On-Station Custom Maneuver Generation with Focussuite

This paper discusses the process of the NOAA GOES Mission Operations Support Team (MOST) in mitigating the effects of inconsistently performing ArcJet Thrusters (AJTs) aboard the GOES-16 spacecraft in geostationary orbit. These AJTs are hot-gas thrusters which augment the gas flow using an electric arc to increase the exit velocity of the gases. Fuel flow problems have led to GOES-16 being unable to safely use its AJTs for maneuvers at times. This primarily affects North/South Station-Keeping (NSSK) maneuvers, which control inclination and use a majority of the station-keeping fuel budget. As a result, GOES-16 has had to occasionally resort to using non-AJT hot-gas thrusters. These thrusters are not placed as close to GOES-16's centerline, have lower thrust, and have lower specific impulse when compared to AJTs. In addition, MOST’s ground systems do not officially support using these non-AJT thrusters for NSSK maneuvers. MOST had to quickly develop workaround solutions using the FocusSuite Autofocus programming environment to compute the maneuvers. This paper outlines the mixture of commercial off-the-shelf (COTS) and MOST-developed products which have allowed GOES-16 to continue station-keeping even with inconsistently-per-forming AJTs, showing that script-based automation systems like Autofocus can simplify complex solutions to a few scripted user inputs.

Henry Heim↗

NASA NTRSDate not supplied

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↗

NASA NTRS2022

Mars 2020 Entry, Descent, and Landing System Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗

NASA NTRS2022

Mars 2020 Entry, Descent, and Landing Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. In addition to performing the critical function of landing the rover on the Martian surface, the EDL timeline behavior must co-exist in a non-partitioned software and system environment with other high-level functions that accomplish the goals for the rest of the mission. Due to the criticality of EDL, the potential for loss of mission, and a need for complete system autonomy, the standard for how the EDL Timeline interacts with other functions in the system is highly constrained. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗

NASA NTRSDate not supplied

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↗