SEARCH · Engineering Papers

Results for “gui”

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.

SourceResearch connectionFrom yearThrough year

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

At least 649 records · Page 36

All sources NASA NTRS DOE OSTI

NASA NTRS2019

2018 NISAR Applications Workshop: Forest and Disturbance; Workshop Report

Forest lands cover the globe and are important sources for providing ecosystem services including: carbon sequestration, biodiversity, timber, air and water quality. As such, counties around the world have dedicated programs for managing them. Accurate and timely information concerning the status of these forests (moisture, biomass, disturbance type, etc.) is essential to those Nations’ human and ecological health as well as economy. The joint NASA/US Forest Service workshop focused on arming forest land managers with observations and remote sensing information from the upcoming NASA-ISRO (Indian Space Research Organization) SAR (Synthetic Aperture Radar) (NISAR) satellite mission (expected to launch early 2022). Participants included representatives from different US Federal Agencies, private sector, and non-governmental organizations (NGO) that are key players in facilitating integration of Earth Observations (EO) into forest management and decision support workflows. They included scientists, technicians, and program managers with a responsibility for data acquisition and exploitation such as product development, delivery, and use, and capacity building. Discussions were held over two days to convey the broader forest and disturbance community information needs for various representative participants and programs and to facilitate the delivery of NISAR mission geospatial products and observational capabilities. Case studies were presented to demonstrate the current state of practice in the use of SAR remote sensing for applications of direct importance to forest and disturbance land management community. Eleven organizations presented their information requirements in response to a set of questions provided by the NASA team, then the NASA team responded by describing the degree to which NISAR could meet these requirements. Discussion ensued about needed data product specifications to increase utility (e.g., projection, latency, etc.), tools and capacity building. The general findings of this workshop were that (a) NISAR observations will be particularly useful to the global forest carbon and disturbance monitoring applications, but that certain data product design decisions (projections and radiometric and terrain corrections) need to be considered to increase utility; b) the biomass and disturbance detection algorithms meet many of the community needs, however there are other information products of value (e.g., soil moisture or disturbance classification, not just detection) and all products should be compliant with existing community standards for reporting uncertainty; c) providing SAR education to the community will be key specifically thinking about putting the information first and the SAR theory second, providing a simple guide of standard data processing steps (e.g., dB (decibel) to power conversion and speckle filtering); d) the community needs a user-friendly interface for finding free, archived data over their geographic regions of interest; e) user-friendly tools that connect to open-sources GIS (Global Information System) software (e.g., QGIS (Quantum GIS)) that include a graphical user interface (GUI) for SAR processing that enables both download and cloud processing. To integrate these findings and prepare the community before NISAR launches, it was suggested that there be a dedicated NISAR Forest and Disturbance Applications Working Group (as per the specifications in the NISAR Utilization Plan). After launch, it was decided that the community continue capacity building activities.

Stavros, Natasha↗

NASA NTRS2016

WebGeocalc: Web Interface to SPICE

The WebGeocalc tool (WGC) provides a web-based graphical user interface to many of the observation geometry calculations available from the “SPICE” system. WGC is based on client-server architecture. A user selects calculation parameters using GUI widgets in a Web browser. The request is sent to a WGC geometry server that performs the calculation and sends results back to the client. WGC can compute various geometric parameters such as positions, orientations, and surface intercept coordinates for a series of times; perform geometric event searches for time intervals when a geometric condition is met; and perform time conversions. WGC offers many features such as plotting and downloading results. Currently only the NAIF group at JPL operates a WGC server that has access to all data on the NAIF web site but WGC can be deployed on any computer that has Java, Apache Tomcat server, MySQL Community Server, and SPICE data.

Semenov, Boris↗

NASA NTRS2018

ATD-2 Integrated Arrival/Departure/Surface (IADS) System Software Version 3.1.x Releases and Notes

This document summarizes the change reports for the ATD-2 V3.1.x series of software releases to Charlotte-Douglas International Airport (CLT). These list all the changes since the previous release. The Release Notes for Distribution are meant to be more readable by stakeholders. [Includes updates to changes for RTC (Ramp Traffic Console), Scheduler, STBO (Surface Trajectory-Based Operations), and Surface Metering Display (graphical-user interface, GUI) clients.]

RTC↗

NASA NTRS2016

WebGeocalc: Web Interface to SPICE

Semenov, Boris↗

NASA NTRS2019

Heatshield Entry Modeling Using a Design, Analysis, and Optimization Toolbox

The Mars Science Laboratory (MSL) was protected during its Mars atmospheric entry by an instrumented heatshield that used NASA's Phenolic Impregnated Carbon Ablator (PICA). PICA is a lightweight carbon fiber/polymeric resin material that offers excellent performances for protecting probes during planetary entry. The Mars Entry Descent and Landing Instrument (MEDLI) suite on MSL offers unique in-flight validation data for models of atmospheric entry and material response. MEDLI recorded, among others, time-resolved in-depth temperature data of PICA using thermocouple sensors assembled in the MEDLI Integrated Sensor Plugs (MISP). The objective of this work is to showcase the capability of the Design, Analysis, and Optimization of Thermal Protection Materials (DAOTPM) software. DAO-TPM is a Python based framework that works as a link between mission design, aerothermal and radiative environment computation, Thermal Protection Systems (TPS) microstructure analysis, material response and optimization tools. The toolbox has a Graphical User Interface (GUI) that allows the user to build as well as run the various software and utilities used to design, analyze and optimize a heatshield during atmospheric entry.

Meurisse, Jeremie B. E.↗

NASA NTRS2018

Columbus IFHX Ammonia Leak Analysis

After the Columbus Moderate Temperature Loop (MTL) InterFace Heat eXchanger (IFHX) low temperature event of GMT 345-2013, NASA investigated relevant transient scenarios involving IFHX rupture after water freezing and subsequent thawing. NASA recommended development of a Fault Detection Isolation and Recovery (FDIR) plan that would, in the event of a heat exchanger freeze event, close the Water On/Off Valves (WOOVs) to isolate the heat exchanger and prevent ammonia from the external flow loops from spreading into the cabin. NASA performed a preliminary simplified analysis for the reference case of IFHX rupture, but for a deeper understanding TAS developed detailed SINDA-FLUINT models of the Columbus ITCS that were built and run through the SINAPS GUI. This allowed simulation of the ammonia leakage physics including the variation of environmental parameters, thus providing more accurate and specific input to the FDIR under development. The result was finalization of the IFHX WOOVs closure sequence and wait times to contain the ammonia propagation to Columbus and allow identification of the leaking IFHX. In addition, the analysis results provided reference pressure profiles to be used on console and by the Engineering as support for the telemetry data assessment in case of failure.This paper gives an overview on the issue and focuses on the analytical aspects of the multiphase fluid dynamics involved.

Tilloca, A.↗

NASA NTRS2020

Medics: Medical Decision Support System for Long-Duration Space Exploration

The Autonomous Medical Operations (AMO) group at NASA Ames is developing a “medical decision support system” to enable astronauts on long-duration exploration missions to operate autonomously. The system will support clinical actions by providing medical interpretation advice and procedural recommendations during emergent care and clinical work performed by crew. The current state of development of the system, called MedICS (Medical Interpretation Classification and Segmentation) includes two separate aspects: a set of machine learning diagnostic models trained to analyze organ images and patient health records, and an interface to ultrasound diagnostic hardware and to medical repositories. Three sets of images of different organs and medical records were utilized for training machine learning models for various analyses, as follows: 1. Pneumothorax condition (collapsed lung). The trained model provides a positive or negative diagnosis of the condition. 2. Carotid artery occlusion. The trained model produces a diagnosis of 5 different occlusion levels (including “normal”). 3. Ocular retinal images. The model extracts optic disc pixels (image segmentation). This is a precursor step for advanced autonomous fundus clinical evaluation algorithms to be implemented in FY20. 4. Medical health records. The model produces a differential diagnosis for any particular individual, based on symptoms and other health and demographic information. A probability is calculated for each of 25 most common conditions. The same model provides the likelihood of survival. All results are provided with a confidence level. Item 1 images were provided by the US Army and were part of a data set for the clinical treatment of injured battlefield soldiers. This condition is relevant to possible space mishaps, due to pressure management issues. Item 2 images were provided by Houston Methodist Hospital, and item 3 health records were acquired from the MIT laboratory of computational physiology. The machine learning technology utilized is deep multilayer networks (Deep Learning), and new models will continue to be produced, as relevant data is made available and specific health needs of astronaut crews are identified. The interfacing aspects of the system include a GUI for running the different models, and retrieving and storing data, as well as support for integration with an augmented reality (AR) system deployed at JSC by Tietronix Software Inc. (HoloLens). The AR system provides guidance for the placement of an ultrasound transducer that captures images to be sent to the MedICS system for diagnosis. The image captured and the associated diagnosis appear in the technician’s AR visual display.

Colombano, Silvano↗

NASA NTRS2020

Antenna and Flight Control Software for Conformal Phased Array Antenna Design (CPAAD)

The National Aeronautics and Space Administration (NASA) is developing lightweight conformal phased array antenna designs (CPAAD) for beyond line of sight communications [1]. The CPAAD system is developed to address reliable and affordable autonomous next generation aviation systems. The technology takes advantage of newly assigned provisional Ku-bands for UAVs. The antenna design is unique to avoid interference with the ground and the unconventional substrate reduces weight. The surface mounted conformal design allows for reduced drag during flight. The software developed for the CPAAD system operates the antenna hardware and provides a graphic user interface (GUI) for ground testing and flight operations.

phased array antenna control software↗

NASA NTRSDate not supplied

Quality Control Methods of Tower Data at Kennedy Space Center’s Launch Complex 39-B and the USAF Cape Canaveral 500 Foot Tower

The National Aeronautics and Space Administration (NASA) has long used meteorological data from weather towers located at Kennedy Space Center (KSC) and the United States Air Force’s Eastern Range(ER) in support of their various launch vehicles and climate studies. Some of the most valuable data is gathered at the Launch Complex 39-B (LC39-B) and the 500 foot tower located approximately two miles west of LC39-B and three miles north of the Vehicle Assembly Building (VAB). The data from LC39-B gives NASA Space Launch System (SLS) engineers valuable insight into the weather the vehicle can expect at the pad, while the 500 foot tower has a longer period of record and has been used by the Shuttle and SLS programs. However, numerous data quality (DQ) control issues have arisen when utilizing this data for analysis. In addition, instrumentation tends to deteriorate faster than normal due to the corrosive nature of the high salt content in the air. NASA’s Natural Environments branch has developed several QC databases of these towers, but these studies were for fixed periods of records. EV44 identified a need for a continually updated and QC’ed database of tower data not only to provide along term QC’ed database for vehicle and climate analyses, but also to provide the capability to investigate recent weather events such as downbursts and other high wind events. This study follows the methods developed in prior Natural Environment QC tower databases, which includes variable specific QC thresholds and checks used to generate QC flags. However, this study developed new techniques such as the development and design of the graphical user interface (GUI) for manual verification, and the creation of the final monthly QC files.

Quality Control↗

NASA NTRS2020

Control System Software Development: Fall 2020 Internship Final Report

The Launch Control System (LCS) is an integral part of the Space Launch System (SLS) as it responds and sends instructions to both the vehicle and ground systems. This semester, the focus has been on the development of assurance tests for the Graphical User Interface (GUI) software components of the LCS. This will help ensure that the system software functions as intended. This paper describes the goals, procedures, and results of this process as well as lessons learned that may be useful for future interns working on similar projects.

software↗

NASA NTRSDate not supplied

An Interactive MATLAB Program for Fitting Transfer Functions to Frequency Responses

A computer program called FRFit (Frequency Response Fitting) for matching single-input single-output (SISO) transfer function models to empirical frequency response data is described. The program was written in MATLAB and has a graphical user interface (GUI). It is interactive in that the user manually builds the transfer function model using ``elementary factors'' (gain, delay, differentiators and integrators, and first- and second-order poles and zeros) and adjusts their values with sliders or entry fields. A nonlinear optimization can also be used to determine maximum-likelihood estimates of the transfer function parameters and their associated uncertainties. The program has some usefulness as a teaching aid, and can be applied to model structure determination, reduced-order modeling, preliminary analysis, and other system identification problems. FRFit is demonstrated using example problems, including the identification of aircraft transfer functions and rational function approximations of Theodorsen's function.

Frequency response↗

NASA NTRS2021

Characterization Study of TestBed Infrastructure Performance in a Distributed Simulation Environment: Baseline Analysis

Characterization of the performance of Air Traffic Management Exploration (ATM-X) TestBed integration environment has been investigated and documented for one system configuration for progressively increasing traffic. Several statistical parameters were used to assess the performance of the TestBed distributed system such as mean, standard deviation, skewness, and kurtosis of latency, and update rate for aircraft state messages that are transmitted through the simulated system under investigation. It is necessary to assess the performance characteristics of distributed systems in terms of the indicated statistical parameters mentioned above. It is critical to verify the system performance with respect to a researcher’s required system performance. Computer host specifications are documented in terms of Central Processing Unit (CPU) clock speed and core count. Transmission Control Protocol/ Internet Protocol (TCP/IP) message protocol was used for data transmission. The system network topology also contributes to the latency and update rate variations from the one imposed by the data source. The motivation for selecting the TestBed infrastructure as the focus of this study can be attributed to the number of services and capabilities it provides that help simplify the process of preparing and conducting a simulation. These capabilities include an easy to use GUI for simulation configuration, access to TestBed library by the end-user of other simulation software components, a modular adapter paradigm that allows simple connectivity of external software to TestBed, connectivity with other simulation laboratories, and a Software Development Kit (SDK) for quicker development. Two types of traffic generators, Air Traffic Generator (ATG) and Multi Aircraft Control System (MACS) were used to generate messages that were injected into the TestBed distributed environment. Eight different air traffic scenarios with progressively increasing loads were generated for each air traffic simulator. The corresponding air traffic loads between the two simulators had an identical number of aircraft per scenario, but different flight plans. It was observed that the performance of MACS degraded for air traffic scenarios containing more than 200 aircraft (37.5 KB/s nominal throughput). However, ATG performed adequately under all tested air traffic loads up to 1200 aircraft (225. KB/s nominal throughput). The tests show that MACS exhibits better latency performance with smaller aircraft loads when compared to ATG. The tests also show that the TestBed infrastructure successfully transmits 1200 aircraft without significant degradation of its performance. From the latency trends for both MACS and ATG, it is clear that as aircraft load increases, the latency in the system increases as well as its standard deviation. Likewise, the trends for the update data rate for both MACS and ATG show that as the aircraft load increases, so does the standard deviation and mean of the update rates which can be attributed to the performance of MACS and ATG applications. The analysis of the results of this study have proven that the overall system performance is dependent on the individual performance of each system component that is connected to TestBed, which subsequently propagates into the system. All TestBed characterization tests were conducted in SimLabs at NASA Ames Research Center in November 2019. This study addresses the need for a baseline TestBed characterization, and the results will serve as a reference for more complex simulation systems.

Air Traffic Management simulations↗

NASA NTRS2021

Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC)

With the rapid growth in the capabilities of smaller satellites, satellite architectures that replace a single, extremely capable spacecraft with multiple, cheaper ones are gaining in popularity. Unfortunately, the orbit design process for constellations can be significantly more involved, especiallywhen the relative placement of the individual spacecraft within the constellation is not constrained by mission and/or science objectives. Optimizing a satellite constellation in the presence of multiple, competing objectives is a highly complex problem to which many traditional mathematical optimization methods cannot be applied and few tools exist to help mission designers search for promising candidate mission designs. The Generation-based Evolutionary Tool for the Optimization of Constellations (GenETOC) has been created to search for near-optimal constellation design options. GenETOC combines a modified version of the Non-dominated Sorting Genetic Algorithm II (NSGA II) with STK Components libraries (a 3rdparty .NET package created by Analytical Graphics Inc.) to create a framework that enables a mission designer to generate a simulation that models the design problem and obtain a family of potential, near-optimal solutions that can be investigated more in detail. GenETOC was developed in C# using the .NET framework with Windows Presentation Foundation (WPF) serving as the framework from which to create the graphical user interface (GUI). GenETOC user inputs can be categorized into three major data components: definition of the problem (areas of interest, satellite decision parameters, and sensor configurations), definition of performance objectives, and specification of the genetic algorithm (GA) parameters. In the problem definition component, the user is prompted to define the areas of interest against which the performance metrics will be computed, define the sensor parameters and attach them to specific spacecraft, select which satellite orbital parameters will be added to the decision space of the GA, and specify the range of desired values for each optimization parameter. For performance objectives, the user is presented with a list of available coverage and revisit performance based calculation options from which two metrics are chosen to serve as the objective functions that the GA will use to evaluate solutions during the optimization process. Finally, the definition of the GA parameters provides user control over the number of generations (number of optimization iterations), the population size (number of candidate constellations created in each generation), and the adaptive mutation and crossover threshold values (control parameters for how frequently each process occurs during the optimization). GenETOC has been extensively tested to verify the individual components of the optimization process. The GA has been tested against a suite of GA test problems to confirm convergence to the known two and three-dimensional Pareto fronts. The coverage and revisit performance metrics obtained in GenETOC are compared with STK desktop scenarios, confirming the constellations are being appropriately modeled within GenETOC simulations. A walkthrough of a simple, example problem is provided to illustrate the workings of GenETOC and to demonstrate the output available to the mission designer.

mission design↗

NASA NTRSDate not supplied

Software for Optical (Laser) Ground Station Monitor and Control

Previous NASA laser communication missions have been supported by ground terminals specific to the mission. The Low-Cost Optical Terminal project (LCOT) aims to serve as a commercial off-the-shelf (COTS), reusable, and modular optical ground terminal prototype, provide a blueprint for future optical ground terminals, and enable optical communication experiments with a variety of spacecraft from Low Earth Orbit to lunar orbit. The goal of the internship was the development of LCOT’s Gimbal Monitor and Control (GMC) application, within the LCOT Monitor and Control Subsystem (MCS). Mount control software PWI4 was provided by mount and gimbal vendor Planewave Instruments; developed in Python, GMC integrates and interfaces with PWI4 using third party libraries such as Protobuf and RabbitMQ. As a stand in for the Monitor and Control Subsystem (MCS), a test Graphical User Interface (GUI) was created to send commands to and receive telemetry from the GMC application; these commands and telemetry are sent through the RabbitMQ message bus as Protobuf encoded messages. GMC then interfaces with PWI4 which passes along desired commands and telemetry to and from a vendor provided mount and gimbal simulator. The GMC software developed allows LCOT’s Monitor and Control Subsystem (MCS) to take advantage of the existing mount control software, advancing LCOT’s efforts in the development of the MCS. The MCS and GMC software developed will contribute to LCOT’s goal as a flexible and modular optical ground terminal prototype and blueprint, which supports development towards a potential optical ground terminal network.

space communications↗

NASA NTRSDate not supplied

Enabling a Voice Management System for Space Applications

The sustainable missions beyond Low Earth Orbit (LEO) envisioned for NASA’s Artemis program will require autonomous capabilities. Moreover, Artemis mission crews will need a means to efficiently interact with a spacecraft’s autonomous systems. This interaction can be facilitated by voice and speech communications because voice-based controls enable users to interact hands- and eyes-free, allowing the user to better focus on critical tasks. The goal of our project was to explore the knowledge and technology needed to successfully design effective Voice User Interfaces (VUIs) for autonomous systems utilizing Human Centered Design (HCD) principles. The focus of the human factors’ aspect of engineering, pays close attention to psychological and physiological principles in the development of autonomous crew operation systems. A main objective was to understand how a crew member, through voice interaction, could efficiently and intuitively communicate with a notional autonomous vehicle system manager. This project was a part of the NASA Moon to Mars eXploration Systems and Habitation (M2M X-Hab) 2020 Academic Innovation Challenge. The work from the BLiSS Team, at the University of Michigan, resulted in the design of a system persona, Diego, to which an astronaut may quickly build trust with autonomous systems, to alleviate known stressors on mental health expected during long duration space missions. Optimal software to facilitate integration of the system persona into a reference Lunar orbiting Gateway station was defined. Additionally, a Speech to Text (STT) system and a Graphical User Interface (GUI) that could be implemented in future missions was developed on an Internet of Things (IOT) platform. The Voice User Interface (VUI) design for the M2M X-Hab 2020 project leveraged previous technology developed by the BLiSS team to incorporate a voice-based interface into NASA’s Platform for Autonomous Systems (NPAS) software. This required technologies to convert voice to text, conduct semantic interpretations, and convert responses from the autonomous system to text and to speech; additionally, the spacecraft background noise environment was assessed, a noise mitigation technique was developed, and a relatable personality for the autonomous system was developed in order to facilitate human-like conversations. The success of our effort was largely due to the diversity of the team that included expertise in Space Systems Engineering, Human Computer Interaction, Aerospace Engineering, Computer Science, Biomedical Engineering, and Applied Physics. The diverse perspectives fostered elaborate discussions, resulting in the conception of three main subsystems: (1) User-System, (2) NPAS-System, and (3) Environment-System. The VUI was unique and had to be efficient and intuitive. For this project, 5 subteams were formed, each with a separate objective, Voice Design team, Background Noise Mitigation team, Software Integration team and Graphical User Interface team. The BLiSS team crafted a personality for the VUI to enable human-like conversation and drive user adoption and trust. User surveys were completed and used to help determine the required VUI system personality traits by capturing perspectives and expectations of prospective “Artemis Generation Astronauts”. To further simulate human-like conversations, the system had to be able to quickly interpret user speech and be able to integrate with NASA’s NPAS platform for quick and reliable information transfer. The outcomes of our research were: (1) a working prototype user interface, that is compatible with NASA’s NPAS platform; (2) software that demonstrates the ability of the VUI system to interpret user requests and respond appropriately; (3) the capability to implement fully expanded conversations between user and system using intuitive communication in four request categories; and (4) software and hardware recommendations that optimize the system’s ability to operate in a noisy environment. Our research has laid the foundation for the development of VUI’s for autonomy, and provides a baseline for future VUI developments.

Voice user interface↗

NASA NTRSDate not supplied

Tool CREOL: Using Earth Observations to Monitor Ecosystem Health for the Preservation of Coastal Louisiana

Submerged aquatic vegetation (SAV) in Louisiana’s Breton National Wildlife Refuge (BNWR) has been steadily declining due to anthropogenic and climate induced changes, contributing to the degradation of the barrier island system. In the Chandeleur Islands region, events such as Hurricane Katrina and the Deepwater Horizon Oil Spill have reduced the barrier islands’ ability to control storm surge and have decreased seagrass extent. Seagrasses promote aquatic biodiversity, absorb excess nutrients, and reduce the rate of shoreline erosion by trapping suspended sediment. The tool for Coastal Remote Ecological Observations in Louisiana (Tool CREOL), a novel GUI, was developed using Google Earth Engine to assess historical changes to and present conditions of the Chandeleur Islands’ land cover, water quality, and seagrass extent. Developed in collaboration with the Louisiana Coastal Protection and Restoration Authority and the Louisiana Department of Natural Resources, the tool uses Earth observations acquired from NASA’s Landsat 5 TM, Landsat 7 ETM+ and Landsat 8 OLI to analyze land cover, turbidity, chlorophyll-a, and seagrass extent from 1984 to today. Tool CREOL enables continuous monitoring of the Chandeleur Islands and will aid in the identification of ideal areas for island restoration and seagrass revegetation.

Taryn Waite↗

NASA NTRS2021

PuMA V3 Video Tutorials

Session recordings of the PuMA Workshop 2021, in which we present the theory behind several of the software capabilities, alongside code and GUI examples. The link to the videos in the External Source(s).

Joseph Ferguson↗

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↗