Search NASA⌕ Search

SEARCH · Search NASA

Results for “Autonomous Mitigation”

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 253 records · Page 14

Human Factors in Training

Future space missions will be significantly longer than current shuttle missions and new systems will be more complex than current systems. Increasing communication delays between crews and Earth-based support means that astronauts need to be prepared to handle the unexpected on their own. As crews become more autonomous, their potential span of control and required expertise must grow to match their autonomy. It is not possible to train for every eventuality ahead of time on the ground, or to maintain trained skills across long intervals of disuse. To adequately prepare NASA personnel for these challenges, new training approaches, methodologies, and tools are required. This research project aims at developing these training capabilities. By researching established training principles, examining future needs, and by using current practices in space flight training as test beds, both in Flight Controller and Crew Medical domains, this research project is mitigating program risks and generating templates and requirements to meet future training needs. Training efforts in Fiscal Year 09 (FY09) strongly focused on crew medical training, but also began exploring how Space Flight Resource Management training for Mission Operations Directorate (MOD) Flight Controllers could be integrated with systems training for optimal Mission Control Center (MCC) operations. The Training Task addresses Program risks that lie at the intersection of the following three risks identified by the Project: 1) Risk associated with poor task design; 2) Risk of error due to inadequate information; and 3) Risk associated with reduced safety and efficiency due to poor human factors design.

Barshi, Immanuel↗

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Data management↗

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current International Space Station (ISS) medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable an increasingly autonomous crew than the current ISS paradigm. The MDA will develop capabilities that support automated data collection, and the necessary functionality and challenges in executing a self-contained medical system that approaches crew health care delivery without assistance from ground support.To attain this goal, the first year of the MDA project focused on reducing technical risk, developing documentation and instituting iterative development processes that established the basis for the first version of MDA software (or Test Bed 1). Test Bed 1 is based on a nominal operations scenario authored by the ExMC Element Scientist. This narrative was decomposed into a Concept of Operations that formed the basis for Test Bed 1 requirements. These requirements were successfully vetted through the MDA Test Bed 1 System Requirements Review, which permitted the MDA project to begin software code development and component integration. This paper highlights the MDA objectives, development processes, and accomplishments, and identifies the fiscal year 2017 milestones and deliverables in the upcoming year.

Exploration medical system↗

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗

Medical Data Architecture Platform and Recommended Requirements for A Medical Data System for Exploration Missions

Minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions.In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗

An Approach for Defining IASMS Services, Functions, and Capabilities

Assuring safety in the NAS with the inclusion of new entrants, such as Advanced Air Mobility (AAM), will require overcoming unique safety challenges that result from combining innovative technologies with novel airspace concepts for moving people and cargo using autonomous vehicles. The focus of the In-time Aviation Safety Management System (IASMS) is to overcome AAM’s safety assurance challenges. The IASMS Concept of Operations (ConOps) describes an interconnected set of services, functions, and capabilities (SFCs) designed to manage operational risks, identify unknown risks, and inform system designs. This paper describes an approach for defining SFCs based on technology trends in research, assessment of known and unknown risks in voluntary safety reports, and causal and contributing factors in aviation accidents and incidents. This approach would identify potential SFCs that further expand the Monitor, Assess, and Mitigate (M-A-M) functionality that represents the enabling framework of the IASMS. Safety implications that will result from integration of AAM in the transformation of the National Airspace System (NAS) were addressed in National Academies committees reports on AAM and IASMS. Development of a ConOps for IASMS was a top recommendation and can be represented as a reframing of safety assurance that builds on real-time alerting such as the Traffic Alert and Collision Avoidance System, and adds the more encompassing in-time temporal parameter in recognition of the different timelines for collecting and assessing safety data for risk mitigations. For example, mining for safety trends from data sources such as the Aviation Safety Information Analysis and Sharing system occurs over a longer time period. Research on AAM operations poses that SFCs can be designed to monitor the safety margin appropriate for AAM including with regards to the distance between current flight parameters and nominal ideal conditions. These in-time comparisons will become more complex as the density of operations increases at least in certain areas and can include planned and actual 4D trajectory, and in-time comparisons having implications on conflict modeling and prediction including expected and actual departure time, fix/waypoint crossing times, and arrival time. These comparisons would be integrated as part of SFCs that redefine and inform new safety margin. An increased safety margin improves management of operational risks while reducing the potential for anomalies. An increased safety margin also has implications for operator confidence in the certainty of its operations and trust in automation. Technology trends in research could be used to refine existing SFCs and define needs for additional SFCs that provide safety improvements to the design and operation of vehicles, airspace design, and operator performance requirements. NASA is developing innovative approaches to safeguard against major accidents and incidents that have occurred in the NAS and those anticipated with the inclusion of envisioned AAM operations. The innovations use operational performance data to monitor, detect, and predict flight variations exceeding safe nominal patterns, such as would be caused by navigational error, severe weather complications, or hijacking of UAS controls. These innovative approaches have high potential to prevent accidents and incidents in the new AAM era. It is anticipated that elements of the innovations will evolve into SFCs for the IASMS. Voluntary safety reports can be monitored to identify anomalies related to design or operational performance risks. Reports could be periodically monitored and assessed for specific topics. Reports might serve as weak signals or precursors indicative of emergent risk such as when combined with other safety information. The architecture could include SFCs that are based on voluntary safety reports recognizing the periodic temporal nature of data analysis. As previously mentioned, aviation accidents with their causal and contributing precursors can inform the need for SFCs in the IASMS. Accidents and incidents at San Francisco International Airport such as Asiana 214 and Air Canada 759 illustrate how combinations of different factors lead to increased risk. These types of precursors and different factors have implications on the types of SFCs that could be needed to monitor and manage different sources and types of design and operational risk. Continuing to assure the safety of AAM as designs and operations gain in complexity can be accompanied by defining SFCs that also increase in complexity. These SFCs can leverage information from findings and recommendations synthesized across on-going research, voluntary safety reports, and accident and incident reports. These SFCs can serve to refine accuracy of algorithms and resolve limitations with current practices. The IASMS architecture represents the framework for the SFCs and their critical role in safety assurance.

In-Time Aviation Safety Management System↗

Ground Demonstration on the Autonomous Docking of Two 3U CubeSats Using a Novel Permanent-Magnet Docking Mechanism

Small spacecraft autonomous rendezvous and docking is an essential technology for future space structure assembly missions. A novel magnetic capture and latching mechanism is analyzed that allows for docking of two CubeSats without precise sensors and actuators. The proposed magnetic docking hardware not only provides the means to latch the CubeSats but it also significantly increases the likelihood of successful docking in the presence of relative attitude and position errors. The simplicity of the design allows it to be implemented on many CubeSat rendezvous missions. A CubeSat 3-DOF ground demonstration effort is on-going at NASA Langley Research Center that enables hardware-in-the loop testing of the autonomous approach and docking of a follower CubeSat to an identical leader CubeSat. The test setup consists of a 3 meter by 4 meter granite table and two nearly frictionless air bearing systems that support the two CubeSats. Four cold-gas on-off thrusters are used to translate the follower towards the leader, while a single reaction wheel is used to control the attitude of each CubeSat. An innovative modified pseudo inverse control allocation scheme was developed to address interactions between control effectors. The docking procedure requires relatively high actuator precision, a novel minimal impulse bit mitigation algorithm was developed to minimize the undesirable deadzone effects of the thrusters. Simulation of the ground demonstration shows that the Guidance, Navigation, and Control system along with the docking subsystem leads to successful docking under 3-sigma dispersions for all key system parameters. Extensive simulation and ground testing will provide sufficient confidence that the proposed docking mechanism along with the choosen suite of sensors and actuators will perform successful docking in the space environment.

Pei, Jing↗

Medical Data Architecture Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.

medical data architecture↗

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.

medical data architecture↗

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

Cognitive IoT and Edge Computing for Intrusion Detection with Federated TinyML

Internet of Things (IoT) and Edge Computing (EC) are rapidly becoming an integral part of the modern society. By 2030, there is estimated to be over 40 billion active and connected IoT devices [1]. This rapid progress also comes with a significant implication on cybersecurity. Back-end infrastructure and systems have a much broader attack than they did previously due to vulnerable IoT/EC devices being connected to wireless networks. This expanding attack surface is a growing concern because IoT/EC are increasingly being used in critical systems such as power grids, health care, and smart homes. To effectively address a problem of this scale, cognitive cyber methods—which can autonomously detect and react to cyber attacks as they develop—are needed. To address this, we bring Artificial Intelligence (AI) and Machine Learning (ML) to IoT/EC devices, using tinyML to monitor voluminous IoT data against cyber threats, and using Federated Learning (FL) to share local detection knowledge across the system while preserving privacy. We propose a novel three-layer architecture: (1) an IoT layer for tinyML-based inference, (2) an edge layer for ML model training, and (3) a cloud layer for FL operations. Using the publicly available 11-class N-BaIoT dataset [2], we demonstrate that this architecture mitigates resource constraints at the IoT layer while improving detection accuracy over standard two-layer designs. An outlier-resistant scaler, feature reduction, and quantization enable the tinyML model to maintain detection accuracy with a reduced model size. Additionally, federated learning that only utilizes the intersection (across heterogenous devices) of the reduced feature set achieves superior detection accuracy compared to locally trained models.

Li, Mingyan [ORNL] (ORCID:0009000569532640)↗

An Augmentation of G-Guidance Algorithms

The original G-Guidance algorithm provided an autonomous guidance and control policy for small-body proximity operations that took into account uncertainty and dynamics disturbances. However, there was a lack of robustness in regards to object proximity while in autonomous mode. The modified GGuidance algorithm was augmented with a second operational mode that allows switching into a safety hover mode. This will cause a spacecraft to hover in place until a mission-planning algorithm can compute a safe new trajectory. No state or control constraints are violated. When a new, feasible state trajectory is calculated, the spacecraft will return to standard mode and maneuver toward the target. The main goal of this augmentation is to protect the spacecraft in the event that a landing surface or obstacle is closer or further than anticipated. The algorithm can be used for the mitigation of any unexpected trajectory or state changes that occur during standard mode operations

Carson, John M. III↗

Collaborative Communications Between A Human and A Resilient Safety Support System

Successful introductory UAM integration into the NAS will be contingent on resilient safety systems that support reduced-crew flight operations. In this paper, we present a system that performs three functions: 1) monitors an operator’s physiological state; 2) assesses when the operator is experiencing anomalous states; and 3) mitigates risks by a combination of dynamic, context-based unilateral or collaborative dynamic function allocation of operational tasks. The monitoring process receives high data-rate sensor values from eye-tracking and electrocardiogram sensors. The assessment process takes these values and performs a classification that was developed using machine learning algorithms. The mitigation process invokes a collaboration protocol called DFACCto which, based on context, performs vehicle operations that the operator would otherwise routinely execute. This system has been demonstrated in a UAM flight simulator for an operator incapacitation scenario. The methods and initial results as well as relevant UAM and AAM scenarios will be described.

Advanced air mobility↗

Harness Thermal Heat Loss Measurement for a Lunar Surface-Deployed LEMS Artemis III Payload

The Lunar Environment Monitoring Station (LEMS) is an autonomous, survive-the-lunar-night seismic suite to be deployed on the Lunar surface by the Artemis III crew and designed to operate continuously for two years. It will see the extremes of the Lunar south pole thermal environment where surface temperatures range from -200°C to +20°C and where nighttime duration is at least 354 hours. Given power and mass constraints, the thermal system is limited to 2.5 Watts of heat during the lunar night. The electrical harnessing named the Signal and Power Passthrough (SAPP) was designed to minimize heat loss while meeting power and signal integrity requirements. To mitigate risk due to uncertainty associated with the harnessing materials, routing, and tie-downs, a flight-like thermal conductance test was performed to measure the heat loss. The test methodology, results, and model correlation are presented.

TVAC↗

Harness Thermal Heat Loss Measurement for A Lunar Surface-Deployed LEMS Artemis III Payload

The Lunar Environment Monitoring Station (LEMS) is an autonomous, survive-the-lunar-night seismic suite to be deployed on the Lunar surface by the Artemis III crew and designed to operate continuously for two years. It will see the extremes of the Lunar south pole thermal environment where surface temperatures range from -200°C to +20°C and where nighttime duration is at least 354 hours. Given power and mass constraints, the thermal system is limited to 2.5 Watts of heat during the lunar night. The electrical harnessing named the Signal and Power Passthrough (SAPP) was designed to minimize heat loss while meeting power and signal integrity requirements. To mitigate risk due to uncertainty associated with the harnessing materials, routing, and tie-downs, a flight-like thermal conductance test was performed to measure the heat loss. The test methodology, results, and model correlation are presented.

Thermal↗

Harness Thermal Heat Loss Measurement for A Lunar Surface-Deployed LEMS Artemis III Payload

The Lunar Environment Monitoring Station (LEMS) is an autonomous, survive-the-lunar-night seismic suite to be deployed on the Lunar surface by the Artemis III crew and designed to operate continuously for two years. It will see the extremes of the Lunar south pole thermal environment where surface temperatures range from -200°C to +20°C and where nighttime duration is at least 354 hours. Given power and mass constraints, the thermal system is limited to 2.5 Watts of heat during the lunar night. The electrical harnessing named the Signal and Power Passthrough (SAPP) was designed to minimize heat loss while meeting power and signal integrity requirements. To mitigate risk due to uncertainty associated with the harnessing materials, routing, and tie-downs, a flight-like thermal conductance test was performed to measure the heat loss. The test methodology, results, and model correlation are presented.

TVAC↗

Collaborative Communications Between a Human and a Resilient Safety Support System

Successful introductory UAM integration into the NAS will be contingent on resilient safety systems that support reduced-crew flight operations. In this paper, we present a system that performs three functions: 1) monitors an operator’s physiological state; 2) assesses when the operator is experiencing anomalous states; and 3) mitigates risks by a combination of dynamic, context-based unilateral or collaborative dynamic function allocation of operational tasks. The monitoring process receives high data-rate sensor values from eye-tracking and electrocardiogram sensors. The assessment process takes these values and performs a classification that was developed using machine learning algorithms. The mitigation process invokes a collaboration protocol called DFACC to which, based on context, performs vehicle operations that the operator would otherwise routinely execute. This system has been demonstrated in a UAM flight simulator for an operator incapacitation scenario. The methods and initial results as well as relevant UAM and AAM scenarios will be described.

Advanced Air Mobility,↗

NGSLR Safety Handbook

NASA's Next Generation Satellite Laser Ranging (NGSLR) station is the prototype for NASA's Satellite Laser Ranging (SLR) systems which will be deployed around the world in the coming decade. The NGSLR system will be an autonomous, photon-counting SLR station with an expected absolute range accuracy of better than one centimeter and a normal point (time-averaged) range precision better than one millimeter. The system provides continuous (weather permitting), 24 hour tracking coverage to an existing constellation of approximately two dozen artificial satellites equipped with passive retroreflector arrays, using pulsed, 532 nm, class IV laser systems. Current details on the approved laser systems can be found in the Appendix 1 of this document. This safety plan addresses the potential hazards to emitted laser radiation, which can occur both inside and outside the shelter. Hazards within the shelter are mitigated through posted warning signs, activated warning lights, procedural controls, personal protective equipment (PPE), laser curtains, beam blocking systems, interlock controls, pre-configured laser control settings, and other controls discussed in this document. Since the NGSLR is a satellite tracking system, laser hazards exist outside the shelter to personnel on the shelter roof and to passing aircraft. Potential exposure to personnel outside the system is mitigated through the use of posted warning signs, access control, procedural controls, a stairwell interlock, beam attenuation/blocking devices, and a radar based aircraft detection system.

satellite laser ranging↗