Results for “autonomous platforms” — Page 38

DOE OSTI2021

Autonomous Tools for Attack Surface Reduction (Final Report)

The electric power grid is a complex critical infrastructure that forms the lifeline of modern society, and its secure and reliable operation is of paramount importance to national security and economic wellbeing. However, recent findings documented in authoritative sources indicate the threat of cyber-based attacks growing in numbers and sophistication. However, securing the grid against stealthy cyberattacks is a challenging task due to legacy nature of the infrastructure coupled with dynamic nature of threat landscape and ever-growing sophistication of the adversaries. Additionally, the grid’s attack surface continues to grow with the increased dependence on digital communications and control that now extends to each consumer through smart meters and distributed energy resources. Unfortunately, this expansive surface increases the grid’s vulnerability and further exposes critical control systems in both substations and control centers. To respond to this emerging need, we had successfully assembled an interdisciplinary team with academic- industry partnership to successfully conduct research, development, evaluation, demonstration, and commercialization of attack surface reduction tools, whose goal was to significantly reduce the cyber attack surface in the North American power grid. Our proposed project was a synergistic collaborative effort leveraging the synergistic expertise of the team members across power systems, cyber security and CPS security, testbeds, field deployments and demonstration, and successful commercialization. The following are the specific tasks that have been successfully completed two phases (2016-2020). Phase I: Task 1: Developed and implemented a robust Project Management and Data Management Plan, coupled with a well thought out Risk Mitigation Plan. Task 2.1: Developed a comprehensive framework that continually assesses and autonomously reduces the attack surface for the power grid control environment spanning across substations, control center and the SCADA network to significantly reduce the risks of cyber attacks. Task 2.2: Developed attack surface analysis techniques, metrics, and tools that assess the attack surface at multiple levels including the control center, substations, and the SCADA network. Task 2.3: Developed attack surface reduction techniques and tools that dynamically reduce attack surface and hence increase attacker’s cost without interfering in the critical functions of the system. Task 2.4: Prototyped, implemented, and quantitatively evaluated/validated the techniques and tools on a realistic industrial CPS security testbed environment by leveraging the unique resources of the team. Task 3: Developed Commercialization plan to transition the developed tools into power system industry stakeholders for a broader adoption by leveraging the expertise of our industrial members. Phase II: Task 4: Successfully completed field demonstration, verification, and evaluation of the effectiveness of the attack surface analysis and reduction techniques on a realistic utility testbed environment. This also involved the development of realistic scenarios, sound metrics, data sets, evaluation criteria, and documentation. Technology integration & Field demonstration: The project had significantly advanced the state-of-the-art research and practice in improving the cybersecurity of our nation’s power grid infrastructure against cyber threats. In particular, the proposed, designed, and deployed attack surface analysis and reduction algorithms and tools have contributed to significantly reducing the exposure and risk of the devices, substations, and the integrated SCADA/EMS/ DMS grid environment to cyber threat. Strong demonstration and evaluation techniques have verified the feasibility of the developed techniques on realistic cyber-physical testbeds and utility partner's real grid environment, and collaborative research and evaluation of attack surface reduction techniques (for wide-are monitoring and control) within a vendor (GE) EMS platform. The Attack Host Analyzer (AHA) tool that was developed through this project was made available through GitHub.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS2013

Cloud Absorption Radiometer Autonomous Navigation System - CANS

CAR (cloud absorption radiometer) acquires spatial reference data from host aircraft navigation systems. This poses various problems during CAR data reduction, including navigation data format, accuracy of position data, accuracy of airframe inertial data, and navigation data rate. Incorporating its own navigation system, which included GPS (Global Positioning System), roll axis inertia and rates, and three axis acceleration, CANS expedites data reduction and increases the accuracy of the CAR end data product. CANS provides a self-contained navigation system for the CAR, using inertial reference and GPS positional information. The intent of the software application was to correct the sensor with respect to aircraft roll in real time based upon inputs from a precision navigation sensor. In addition, the navigation information (including GPS position), attitude data, and sensor position details are all streamed to a remote system for recording and later analysis. CANS comprises a commercially available inertial navigation system with integral GPS capability (Attitude Heading Reference System AHRS) integrated into the CAR support structure and data system. The unit is attached to the bottom of the tripod support structure. The related GPS antenna is located on the P-3 radome immediately above the CAR. The AHRS unit provides a RS-232 data stream containing global position and inertial attitude and velocity data to the CAR, which is recorded concurrently with the CAR data. This independence from aircraft navigation input provides for position and inertial state data that accounts for very small changes in aircraft attitude and position, sensed at the CAR location as opposed to aircraft state sensors typically installed close to the aircraft center of gravity. More accurate positional data enables quicker CAR data reduction with better resolution. The CANS software operates in two modes: initialization/calibration and operational. In the initialization/calibration mode, the software aligns the precision navigation sensors and initializes the communications interfaces with the sensor and the remote computing system. It also monitors the navigation data state for quality and ensures that the system maintains the required fidelity for attitude and positional information. In the operational mode, the software runs at 12.5 Hz and gathers the required navigation/attitude data, computes the required sensor correction values, and then commands the sensor to the required roll correction. In this manner, the sensor will stay very near to vertical at all times, greatly improving the resulting collected data and imagery. CANS greatly improves quality of resulting imagery and data collected. In addition, the software component of the system outputs a concisely formatted, high-speed data stream that can be used for further science data processing. This precision, time-stamped data also can benefit other instruments on the same aircraft platform by providing extra information from the mission flight.

Kahle, Duncan↗

NASA NTRSDate not supplied

CLINICAL DECISION SUPPORT: PATH TO FUNCTIONAL REQUIREMENTS

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

clinical decision support↗

NASA NTRSDate not supplied

Clinical Decision Support: Path to Functional Requirements

Long-duration, deep-space exploration missions present significant challenges to crew health and performance. These challenges include the individual and combined effects of microgravity, radiation exposure, isolation, limited resources (mass, volume, power, data and crew time), limited options for evacuation and those associated with delayed or constrained communications, all of which demand greater crew autonomy. Specifically, as the communication delays intensify the further we explore space, the unqualified need for Earth-independent medical operations focused on autonomous diagnosis, treatment and prevention will be key to mission continuation and success. To augment the requisite knowledge, skills and abilities (KSAs) of a time-constrained crew operating under stressful conditions, combatting fatigue, and facing a potential medical crisis, a robust clinical decision support system (CDSS) is a probable solution that would facilitate, guide and inform Earth-independent medical operations, while assisting crewmembers through various clinical presentations. The Exploration Medical Capability (ExMC) Element of the Human Research Program (HRP) is expanding the boundaries of space medical systems to advance the care of astronauts on future exploration missions beyond low Earth orbit. ExMC is actively identifying and testing next-generation medical care and crew health maintenance technologies. The Clinical Decision Support (CDS) project addresses gap Medical-701 within the Inflight Medical Conditions risk: “Enhance medical capabilities within an exploration medical system.” Though mass, volume, and power will face increasing constraints, the projected computational capabilities of spacecraft systems will increase exponentially as information technology continues to advance this decade and beyond. Hence, data, software and computational resources will play an essential and synergistic role in maintaining crew health, wellness and performance in deep space missions. The focus of the CDS project is to develop recommended requirements for an in-vehicle CDSS that acts as a ‘virtual assistant’ for delivering optimal health, performance and medical care during exploration missions. The CDSS is envisioned as an integrated, software-based tool deployed on a laptop computer or handheld device. The CDSS will assist the crew and ground support when interacting with knowledge/databases (e.g. records, pharmacy, schedule), instrumentation (e.g. imaging, physiological monitoring devices), and habitat (e.g. wellness system, task performance system) and vehicle systems (e.g. environmental system, communication system). In addition, the human interface will employ a context-based approach that accounts for the crew’s situation. Thus, extraneous and clinically/operationally non-relevant information are reduced to avoid an increase in cognitive load. The framework of an ideal spaceflight CDSS is to include core and advanced analytical features that incorporate work from collaborators yet maintain a flexible platform for integrating new technology in the future. In fiscal year 2021 (FY21), the CDS project identified requirements through two primary mechanisms: (i) the development of software implementation prototypes and (ii) the application of systems engineering processes. The CDS project developed and tested a series of increasingly complex system prototypes that were based on use cases derived from the CDSS concept of operations (ConOps). These software implementations yielded insights on CDSS functionality as well as lessons learned that provided the initial requirements for CDSS capability. By applying a systems engineering (SE) approach, medical scenarios provided in the ConOps and the use cases for software implementation underwent functional decomposition to identify CDSS functionality. Also, systems-based modeling language (SysML) tools such as activity diagrams were developed from the same ConOps and use cases to identify CDSS functionality. The lessons learned from software implementation defined both specific requirements and broad areas of requirements. Within these defined broad requirement areas, further analysis of the SE products identified specific capability that resulted in the final functional requirements. In summary, the software prototypes, functional decomposition of the ConOps and use cases, and SysML diagrams provided the basis for the CDSS requirements developed in FY21. In the upcoming year, these requirements will be refined for their final ExMC baseline review in latter FY22.

Clinical decision support↗

NASA NTRSDate not supplied

Spaceflight Biospecimen and Data Sharing in Support of Science Discovery and Exploration

For decades, NASA and international partners have conducted biological experiments in space to understand effects of spaceflight and address potential hazards. To enable spaceflight back to the Moon, and then to Mars and beyond, it is imperative to further understand basic science and health risks associated with spaceflight, along with developing countermeasures. The sending of experiments and organisms into space is a costly endeavor. To maximize scientific return, sharing with the scientific community both space-flown biospecimens and data from completed experiments is essential. New fundamental, applied, and bioinformatic science insights can be gained from specimen and data sharing efforts. Data reuse enables spaceflight health risk modeling, analyzing adverse outcomes across spaceflight hazards, and deep space autonomous support for the flight medical officer. Space-flown biospecimens not required by mission Principal Investigators are regularly archived and made available for scientific request. The largest biorepository of these samples are found within NASA’s Institutional Scientific Collection at Ames Research Center (ISC-ARC), which stores over 32,000 specimens mostly from Shuttle and International Space Station (ISS) missions, but also some ground-based analog samples. The Ames Life Sciences Data Archive manages the ISC-ARC. Tissues are predominantly from mice and rats, though samples are also available from bacteria and quail. Only a handful of other similar collections exist worldwide. Rodent biospecimens exposed to simulated space radiation at Brookhaven National Laboratory are archived under the purview of NASA HRP Space Radiation Element. Microbial collection and analyses from 20 years of routine environmental monitoring of air, surfaces, and water systems of the ISS were performed to ensure a safe environment for astronauts. Samples from the ISC-ARC, space radiation and microbial collections are searchable and requestable through the NASA Life Sciences Data Archive (LSDA). Decades of planetary protection microbial isolates derived from spacecraft bioburden are archived in JPL’s microbial collection. Rodent biospecimens from spaceflight investigations conducted by the Japan Aerospace Exploration Agency (JAXA) are archived and available at the JAXA Biorepository at Tsukuba Space Center. The Russian Institute of Biomedical Problems also has a collection of animal, microbial, cellular, and fungi available for research from ground analog experiments. Several data repositories exist for scientists to utilize. The LSDA is the primary NASA source of life sciences research data and information. It contains decades of spaceflight and ground-analog research involving human, microbial, cellular, plant, and animal subjects. Data is collected from NASA-funded investigations through the Human Research Program and the Space Biology Program. The NASA Lifetime Surveillance of Astronaut Health collects and grants access to clinical and occupational health monitoring data from astronauts, with a list and description of data collected available for request through the LSDA. NASA GeneLab at ARC collects genomic, transcriptomic, proteomic, and metabolomic data from any species. It is a repository and platform for collaborative open-science bioinformatic approaches. JAXA is establishing an ‘omics-based repository in collaboration with the Tohoku Medical Megabank (ToMMo), called the JAXA-ToMMo Integrated Biobank for Space Life Science. Overall, the sharing of these biospecimen and data resources can assist researchers worldwide in understanding spaceflight effects on biology, along with enabling next generation data science applications for space exploration platforms. Websites: https://lsda.jsc.nasa.gov/ ; https://www.nasa.gov/ames/research/space-biosciences/isc-bsp ; https://www.nasa.gov/ames/research/space-biosciences/alsda

Ryan T. Scott↗

DOE OSTI2023

Small Reactors in Microgrids: Technology Modeling and Selection (Net-Zero Microgrid Program Project Report)

This report demonstrates the capabilities of the net-zero microgrid (NZM) Xendee platform for modeling an SR module with electricity, heat extraction and thermal storage in microgrids configurations. The model effectively captures the most important technical and economic considerations for SR technology specific analysis: cost and operational characteristics of SR technology and financial costs and incentives. The model can analyze multiple scenarios to establish metrics for cost-competitive and zero-carbon microgrids connected to the grid or completely isolated. The model is fully integrated within the Xendee platform for modeling and analysis of clean energy microgrids with storage and generation from renewable energy sources. The model captures the capabilities, constraints, and nuances of SR by incorporating parameters related to plant economics, design efficiency and performance, plant operation and component and fuel lifespan. The cost and operational parameters modeled in the SR module are specific to the technology selected for integration in the microgrid. Cost parameters recognize advanced nuclear technology for modular production and installation based on economies of scale from factory manufacture and related commissioning, and cost reduction through technology maturation—first-of-a-kind (FOAK) and nth-of-a-Kind (NOAK). The cost parameters include installation, operations and maintenance (O&M), fuel refueling cycle, and reactor life. Installation cost reflects economies of scale due to unit sizing at scale and colocation. O&M economies of scale for both fixed- and variable-cost fuel life-cycle costs are incurred at every refueling interval, with separate front- and back-end fuel costs, as well as waste-handling and disposition costs. This report investigates key characteristics of different SR technologies suitable for microgrid applications, including design principles, sizing, coolant properties, temperature ratings, fuel structures, and life-cycle considerations. This also includes fuel technologies applicable to these SR systems, alongside strategies for nuclear-waste and spent-fuel management and approaches to address safety, security, and proliferation challenges. Four primary groups of SR technologies are examined: water-cooled, liquid-metal-cooled, high-temperature gas-cooled, and molten-salt-cooled systems. In this report, an initial guideline for technology selection is established, aligning the characteristics of the technologies with the requirements of microgrids. The selection of technology in a microgrid is influenced by various factors, including financial capacity, location and accessibility, demand type and characteristics, reliability and resilience requirements, area constraints, and the lifespan of the microgrid. The types of electrical and non-electrical applications within the microgrid also play a significant role in technology selection. The characteristics of SRs, such as their smaller size, modularity, transportability, long refueling interval, improved safety features, ability to operate in autonomous or semi-autonomous mode, and provision of high-grade heat, are particularly appealing for microgrids. Furthermore, a list of considerations for implementing SRs in microgrids is outlined. The SR model is created to be continuously improved with the acquisition of actual data on investment and operational costs, experience with supply chains, production at scale, and field deployments. In the near term, performance data on applications in microgrids will become available from lessons learned from laboratory tests, such as those planned for the Microreactor Applications Research Validation and Evaluation Project (MARVEL), led by Idaho National Laboratory (INL). The SR model incorporates scenario data and known SR design specifications, enabling technoeconomic analysis for SR deployment in microgrids. It specifically considers the distinctive attributes of SRs as generators in technoeconomic studies. SRs can be modeled and analyzed with generation from renewable-energy sources, energy storage, and flexible loads over a range of functionality and applications. This offers a comprehensive tool for feasibility studies, scenario development, and sensitivity analysis for “what-if” consideration of any range of assumptions about SRs in microgrids and other aggregations of distributed-energy resources, including virtual power plants.

21 SPECIFIC NUCLEAR REACTORS AND ASSOCIATED PLANTS↗

DOE OSTI2025

Comparing Control Performance Between Simulation and Experiment using the Microreactor Automated Control System Testbed

In the advanced reactor domain, a flexible and scalable software/hardware infrastructure is crucial for integrating and validating various control technologies. This study used the Microreactor Automated Control System (MACS) hardware platform as a testbed. MACS was originally designed to mirror Idaho National Laboratory (INL)'s Microreactor Applications Research Validation and Evaluation (MARVEL), a 85-kW thermal fission microreactor. It features control drums for simulated reactivity control; lights that function as a surrogate reactor core, with the brightness being proportional to the reactor power; and light sensors that emulate neutron detectors. To transform MACS into a physical twin of MARVEL for evaluating control methods, the Control and Optimization Modular Modeling Application for Nuclear Deployment (COMMAND) software was employed. This software integrated the hardware with two models of the MARVEL core, based on Reactor Excursion and Leak Analysis Program (RELAP5-3D) and Monte Carlo N-Particle (MCNP) models. The study aimed to demonstrate the gap between control theory and actual practice—a gap that often necessitates empirical adjustments such as control gain retuning, filters, time discretization, and integrator anti-windup measures. Controllers were developed based on increasingly complex simulations without hardware, starting from the base MARVEL model and then introducing actuator saturation constraints and sensor noise. The final control strategy was then tested using MACS, and a comparative performance analysis was conducted.

46 - INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AN↗

NASA NTRS2011

Tracking Object Existence From an Autonomous Patrol Vehicle

An autonomous vehicle patrols a large region, during which an algorithm receives measurements of detected potential objects within its sensor range. The goal of the algorithm is to track all objects in the region over time. This problem differs from traditional multi-target tracking scenarios because the region of interest is much larger than the sensor range and relies on the movement of the sensor through this region for coverage. The goal is to know whether anything has changed between visits to the same location. In particular, two kinds of alert conditions must be detected: (1) a previously detected object has disappeared and (2) a new object has appeared in a location already checked. For the time an object is within sensor range, the object can be assumed to remain stationary, changing position only between visits. The problem is difficult because the upstream object detection processing is likely to make many errors, resulting in heavy clutter (false positives) and missed detections (false negatives), and because only noisy, bearings-only measurements are available. This work has three main goals: (1) Associate incoming measurements with known objects or mark them as new objects or false positives, as appropriate. For this, a multiple hypothesis tracker was adapted to this scenario. (2) Localize the objects using multiple bearings-only measurements to provide estimates of global position (e.g., latitude and longitude). A nonlinear Kalman filter extension provides these 2D position estimates using the 1D measurements. (3) Calculate the probability that a suspected object truly exists (in the estimated position), and determine whether alert conditions have been triggered (for new objects or disappeared objects). The concept of a probability of existence was created, and a new Bayesian method for updating this probability at each time step was developed. A probabilistic multiple hypothesis approach is chosen because of its superiority in handling the uncertainty arising from errors in sensors and upstream processes. However, traditional target tracking methods typically assume a stationary detection volume of interest, whereas in this case, one must make adjustments for being able to see only a small portion of the region of interest and understand when an alert situation has occurred. To track object existence inside and outside the vehicle's sensor range, a probability of existence was defined for each hypothesized object, and this value was updated at every time step in a Bayesian manner based on expected characteristics of the sensor and object and whether that object has been detected in the most recent time step. Then, this value feeds into a sequential probability ratio test (SPRT) to determine the status of the object (suspected, confirmed, or deleted). Alerts are sent upon selected status transitions. Additionally, in order to track objects that move in and out of sensor range and update the probability of existence appropriately a variable probability detection has been defined and the hypothesis probability equations have been re-derived to accommodate this change. Unsupervised object tracking is a pervasive issue in automated perception systems. This work could apply to any mobile platform (ground vehicle, sea vessel, air vehicle, or orbiter) that intermittently revisits regions of interest and needs to determine whether anything interesting has changed.

Wolf, Michael↗

NASA NTRS2017

The Iodine Satellite (iSat) Propellant Feed System - Design and Demonstration

CUBESATS are relatively new spacecraft platforms that are typically deployed from a launch vehicle as a secondary payload, providing low-cost access to space for a wide range of end-users. These satellites are comprised of building blocks having dimensions of 10x10x10 cm3 and a mass of 1.33 kg (a 1-U size). While providing low-cost access to space, a major operational limitation is the lack of a propulsion system that can fit within a CubeSat and is capable of executing high Delta V maneuvers. This makes it difficult to use CubeSats on missions requiring certain types of maneuvers (i.e. formation flying, spacecraft rendezvous). Work has been performed investigating the use of iodine as a propellant for Hall-effect thrusters (HETs) that could subsequently be used to provide a high specific impulse path to CubeSat propulsion. One of the systems under development to support such a technology is the propellant feed system, which must be capable of storing solid iodine propellant, applying heat to sublime the stored solid into the vapor phase, and then control the flow of low-pressure gaseous iodine to both the thruster and cathode. In a test conducted in 2016, a first-generation iodine propellant feed system was integrated with a cathode and Hall thruster. While this test had to be terminated, the feed system in this first test was able to support both cathode and integrated cathode and thruster operation prior to the termination of the test. In the present paper, we describe work performed since that initial integrated test. The effort uses lessons learned from the previous integrated test, retiring risk associated with the iodine propellant feed system, answering open design-space questions, and demonstrating iodine flow control in an integrated system. The work is undertaken at both the component level and then at the integrated subsystem level to systematically improve the feed system design, improving the hardware fidelity so the appearance and operation of the system are as flight-like as possible. At the component level, the work focuses on the propellant tank, the feed system tubing, the valves used to control the flow to the cathode and thruster, and the heaters that maintain the temperature of the flowpaths and keep iodine from redepositing and clogging the system. Work on the propellant reservoir focuses on fabricating a tank that matches the geometry of the flight design, which allows for the identification of flight tank fabrication issues that may arise and permits thermal testing of a tank possessing the same size and thermal mass as the flight design, which can be used to anchor thermal modeling of the component. This is critical for finalizing the tank heater power requirements that feed into the heater design. All metallic materials in the feed system are hastelloy or Inconel, as these materials are resistant to chemical attack by the highly-reactive iodine vapor. The tubing in the iodine feed system must possess ports to permit a neutral gas purge of the system that clear impurities after iodine is loaded into the propellant tank. A procedure is discussed whereby these ports are crimped and sealed after the purge process is completed so as to not re-expose the iodine system to air. The valves are a critical component for control of the flow to the thruster and the cathode. Significant effort has gone into upgrading the materials of the valves to make them more resistant to chemical attack and into developing an understanding of the use of these valves during the startup and operation of the cathode and thruster. The heaters that line the entire feed system are designed to draw minimal power from the power processing unit (PPU) while still having the capacity to maintain all the feed system components at the temperatures required to discourage iodine deposition inside components downstream of the propellant tank exit. The heaters possess two separate resistive traces, giving the design redundancy should a failure occur in the primary heater circuit of one of the heater zones. The task of operating a feed system in conjunction with a thruster and cathode is undertaken in a series of sub-steps. The system is first assembled and operated on xenon gas, using the valves for cathode startup and thruster control based on measurement of the discharge current. After startup and control on xenon are demonstrated, the thruster will be transitioned to iodine operation, demonstrating thruster startup and feed system control while using a xenon-fed cathode. Finally, the last step is to integrate an iodine-compatible cathode with the system, demonstrate autonomous cathode start-up with open-loop control and thruster start-up with closed-loop control for multiple cycles.

Polzin, Kurt A.↗

NASA NTRSDate not supplied

A Notional Artemis Lunar Surface Exploration Package (ArLSEP) based on the Gandalf Staff Platform

Introduction: The Artemis program is planning to deliver crew and cargo to the lunar surface, but there is no current package for supporting lunar in-struments and experiments similar to the Apollo Lunar Surface Exploration Package (ALSEP). This abstract provides a possible concept for such a package using the Gandalf Staff Platform as a common core. Gandalf Staff: The Gandalf Staff is an early prototype system developed over FY’21/FY’22 using NASA Science Technology Mission Directorate (STMD) Center Information Fund (CIF) grants to de-sign, build and test “proof-of-concept” components. These components include a 24v battery powered monopole that powers a suite of subsystems, including a Graphical User Interface (GUI) for crew, surface voice and data communications, Lunar Search and Rescue (LunaSAR) navigation and communications, LiDAR, field site external lighting, 360-degree camera, and a geothermal instrument for measuring sub-surface temperature gradient. The staff can be carried independently by an Extra-Vehicular Activity (EVA) astronaut, or can be mounted into a tripod for “hands free” support at a surface site being investigated. The staff can be attached to an external solar array and power storage system for long-duration operations. [1,2] ALSEP: An ASLEP flew on each mission Apollo 12 to Apollo 17. For Apollo 11, a simplified packaged called the Early Apollo Scientific Experiments Pack-age (EASEP) was flown. Each package included a “Central Station” that provided the power and communications connected to a variety of instruments and sensors. The power was provided by a Radioisotope Thermoelectric Generator (RTG) fueled by Plutoni-um-238 generating 70 watts of power (initially, decayed over time) [3]. The communications system provide for direct to Earth data transfer from the lunar surface. Each pack-age was stowed externally in the Lunar Module (LM) Scientific Equipment (SEQ) bay with a mass up to 163 kg (Apollo 17). The crew unloaded the ALSEP from the LM and deployed the instruments on the lunar surface. Although designed to operate for only 1 year, many sites operated for up to 8 years successfully [4]. The Active Seismic Experiment (ASE) included 3 geophones for detecting seismic waves created by mortars and thumpers deployed by the crew. Other active experiments measured the lunar atmosphere, the heat flow in the subsurface, the lunar gravity and potential gravity waves, the lunar magnetic field, the solar wind and plasma interactions in cislunar space. Passive experiments included collectors for dust and cosmic rays, and retroreflectors for precise measurements of distance using a laser from Earth. The ALSEP program continues to generate insights into lunar formation and evolution. ArLSEP Concepts: The lunar surface science package for the Artemis program will hopefully exceed the capability of the ALSEP. There are multiple issues for discussion leading to the design of a new ArLSEP, needing requirements definition from the science community, NASA mission architecture, and NASA budget planners. 1. Delivery Mechanism Two possible projects currently provide capability to deliver scientific cargo to the lunar surface: 1) the Commercial Lunar Payload Services (CLPS) [5] and the Human Landing System (HLS) [6, 7]. Each project is controlled by a different organization within NASA and budgeted with different criteria although both support lunar exploration. The HLS system delivers crew (and potentially cargo) to human landing sites. If an ArLSEP is “predeployed” to such a site, the design must include power (either from the vehicle or independently) to keep the electronics functioning until deployed by the crew. If an ArLSEP is delivered on a vehicle after the crew is present on the lunar surface, safety protocols require adequate distance from the humans for impact from descent propelled sur-face regolith ejecta. This distance can not exceed the capability of the crew to walk (if no rover) to the vehicle for ArLSEP deployment. 2. Overall Guidelines The general design of ArLSEP will likely follow the ALSEP with a common system for communications and power; however, significant architecture differences between Apollo and Artemis exist. Power: The RTG will not be available for early Artemis missions nor likely follow-on Lunar Exploration Transportation Services (LETS) missions [8]. Thus, ArLSEP power must be supplied by solar arrays with sufficient battery capability to “keep alive” necessary electronics during any lunar surface eclipse period. Communication: The Artemis program is developing a series of communications satellites for lunar orbit to provide surface transmission of data and voice to Earth. Called “LunaNET”, this network is component useful for ArLSEP since south polar locations may not always have direct “line-of-sight” to Earth [9]. 3. Concept of Operations (ConOps) The general ConOps for ArLSEP is to deliver the package to lunar surface before the crew arrives, and then have the crew deploy the package after some period of time. This requires coordinated design (for power systems) and launch window (for schedule) on both the cargo and crew missions. Once the ArLSEP is deployed, it will operate autonomously for a number of years. It should be designed to be EVA compatible for crew maintenance and upgrade. 4. Notional Design (for discussion purpose only) The landing site near the South Pole is expected to have no eclipse cycle exceeding 5 days, so the “keep alive” power is 144 hours (6 days to include margin). A 12v ArLSEP will use rechargeable LiFePO4 cells, which are common in the Electric Vehicle (EV) industry. With a current of 5 amps and a 125 watt system, the mass is about 90kg. The comm. system and structure adds another 10kg, thus the “Central Station” is approximately 100kg. The solar power is collected on four arrays (each 2m above the surface), and the entire ArLSEP is designed to stow in a 2m x 1m x 1m volume. The experiment and instrument design will vary for each installation and add mass to the total (although they are expected to fit within the 2m3 volume). Seismic wave generation will likely not be provided with mortars, thus an electric “thumper” will be required. Active instruments such as imaging systems and sensing instruments will benefit from the additional power and communication capability provided by ArLSEP. Passive systems such as retroreflectors, witness plates, and cosmic dust collectors can be added to either the landing vehicle and/or the ArLSEP. With repeated HLS missions to the same human site, the ArLSEP can be expanded and easily maintained for long duration science collection on the lunar surface.

ALSEP↗