Search NASA⌕ Search

SEARCH · Search NASA

Results for “HLS data”

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.

64 records · Page 4
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Design, Development, and Use of a Lunar Lander Simulation for NASA's Artemis Program

This paper describes the design, development, and initial use of a generalized and configurable lunar lander simulation to support NASA’s Artemis Program. This simulation is being developed for the Crew Compartment Office (CrewCo) in the Human Landing Systems (HLS) program and is called the HLS CrewCo Lander Simulation (HCLS). The HCLS provides insight into the challenges associated with returning humans to the Moon and the particular difficulties of operating at the Lunar South Pole. The simulation models a generalized integrated lunar landing spacecraft based on a government reference design but can and has been adapted to model vendor specific designs as well. The simulation architecture and tool sets provide a flexible framework that allows for quickly prototyping and evaluating various aspects of a piloted lunar landing system. This includes the modeling of all principal human controlled flight phases: rendezvous and docking with crew transfer systems; docked orbital outpost operations; undocking and lunar transfer; lunar orbital operations; lunar deorbit, descent, and landing (DDL); lunar surface operations; lunar ascent; and return to the orbital outpost. The flexibility of the simulation allows for the integrated evaluation of potential vehicle subsystems, crew displays, guidance and control modes, and trajectory designs. The purpose of the HCLS is not to design the ideal lunar lander, but rather to understand and the strengths and weaknesses of vehicle design choices. This paper describes the basic simulation architecture and discusses the tool sets used to develop the HCLS. This includes a number of open source tool sets and publicly available data sets. This paper also describes some of the early use cases and findings. The primary focus of early HCLS use has been on the manual piloting task to safely get the crew to the desired landing site in case of a failure in the automated guidance system. Several guidance modes and cues have been implemented which allow a pilot to manually fly the vehicle to the targeted landing site starting anywhere from powered descent initiation. It has been a valuable tool for understanding what is required to manually fly a lunar lander as well as giving a sense of the vehicle dynamics, which are much different than anything that is flown on Earth. A number of experienced test pilots have participated in manual piloting evaluations using the HCLS and provided valuable feedback on the piloting task which has been very beneficial to NASA and the HLS program.

James Michael Gentile↗
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↗
NASA NTRS2018

Toward Landsat and Sentinel-2 BRDF Normalization and Albedo Estimation: A Case Study in the Peruvian Amazon Forest

The Amazon forest has been the focus of study by the science community during the last few decades. Remote sensing data analysis is the only way to study such a large geographical extent during an extended period of time. Since the launch in 2015 of Sentinel 2 and its increase in temporal resolution through the combination with Landsat sensors, a strong emphasis has been put on exploiting these data. Though these satellites provide near nadir observations, surface reflectance time series are affected by illumination variability throughout the year. These effects can be corrected using a Bidirectional Reflectance Distribution Function (BRDF) model. Franch et al. (2014a) developed a methodology to derive Landsat surface albedo and BRDF. It is based on the BRDF parameters from the MODerate Resolution Imaging Spectroradiometer (MODIS) which are disaggregated at Landsat spatial resolution (30 m). In this work, we apply the Franch et al. (2014a) method to normalize the surface reflectance for BRDF effects using the NASA's Harmonized Landsat Sentinel-2 (HLS) product. We apply this method to the Tambopata region in Peru from 2013 to 2017 and validate it using ground-based albedometer measurements. The results show that the near infrared reflectance can increase up to 0.06 (20%) for low solar angles while the impact on the red range and the NDVI is minor (<0.01). The evaluation of the surface albedo against field measurements shows an error of 0.01.

Landsat 8↗
NASA NTRS2024

Bumper Implementation of LMEEM

The Hypervelocity Impact Technology (HVIT) group at the NASA Johnson Space Center (JSC) maintains the Bumper 3 computer program (referred to as “Bumper”) to perform Micrometeoroid and Orbital Debris (MMOD) risk assessments for spacecraft. To perform its calculations, this program requires detailed mathematical models of the space environments and can include those models representing orbital debris, micrometeoroids, and lunar ejecta. The lunar ejecta environment is a projectile environment specific to the lunar surface. Due to the Moon’s lack of an atmosphere, meteoroids frequently strike the lunar surface. When this happens, the impact ejects material radially away from the impact point, which can pose a potential impact hazard to surface-based hardware. This lunar ejecta environment was previously described in 1969, in NASA Special Publication SP-8013, which was used as the basis for a model that will be referred to in this document as the “SP-8013 environment model,” or simply, “SP-8013.” Since around 2020, this model has been used in MMOD risk assessments for the Human Landing System (HLS) program and other lunar surface programs. A new lunar meteoroid ejecta environment was developed via a computer code named Lunar Meteoroid Ejecta Engineering Model (LMEEM), produced by the Natural Environments Branch (NEB) at Marshall Space Flight Center (MSFC). A global lunar surface environment definition using LMEEM is to be provided in the Cross-Program Design Specification for Natural Environments (DSNE) Revision J in 2024. Contact the NASA MSFC Natural Environments Branch for an in-depth discussion of the LMEEM environment model and its derivation. This environment model will supersede SP-8013 for MMOD risk assessments. To perform such assessments, Bumper must read data from text files output by LMEEM and use that data in risk calculations. The purpose of this document is to: •Demonstrate verification that the Bumper code has properly implemented the LMEEM environment model (Section 3) •Discuss the LMEEM environment as understood through an initial environment file (Section 4) •Compare the calculated risk due to the SP-8013 and LMEEM models (Section 5)

Bumper↗
DOE OSTI2022

The SODA Approach: Leveraging High-Level Synthesis for Hardware/Software Co-design and Hardware Specialization: Invited

Novel "converged" applications combine phases of scientific simulation with data analysis and machine learning. Each computational phase can benefit from specialized accelerators. However, algorithms evolve so quickly that mapping them on existing accelerators is suboptimal or even impossible. This paper presents the SODA (Software Defined Accelerators) framework, a modular, multi-level, open-source, no-human-in-the-loop, hardware synthesizer that enables end-to-end generation of specialized accelerators. SODA is composed of SODA-Opt, a high-level frontend developed in MLIR that interfaces with domain-specific programming frameworks and allows performing system level design, and Bambu, a state-of-the-art high-level synthesis engine that can target different device technologies. The framework implements design space exploration as compiler optimization passes. We show how the modular, yet tight, integration of the high-level optimizer and lower-level HLS tools enables the generation of accelerators optimized for the computational patterns of converged applications. We then discuss some of the research opportunities that such a framework allows, including system-level design, profile driven optimization, and supporting new optimization metrics.

Bohm Agostini, Nicolas↗
NASA NTRSDate not supplied

ExMC Digital Engineering

Future missions beyond Artemis II will become increasingly complex as multiple vehicles (e.g., Gateway, Human Landing System (HLS), and Extravehicular Activity and Human Surface Mobility Program (EHP)), each having their own Program requirements and other associated documentation, which will need to be integrated into a single mission. Currently, the Human Health and Performance Directorate (HHPD)Program Support Teams mostly use documents to manage, perform, and archive their analyses. Identifying an opportunity for efficiency, ExMC demonstrated the ability to utilize MagicDraw, a Model-Based Systems Engineering (MBSE) tool, as a requirements database with traceability, dependencies, and relationships in one place. Rather than existing in documents, emails, and historical knowledge, ExMC pursued a Digital Engineering (DE) effort in coordination with HHPD by combining MBSE tools with other digital platforms to manage and develop user-defined databases and interfaces. This DE approach is aimed to simplify processes and reduce risk through the unification of requirements into a centralized digital network, improving collaboration, decision-making, and transparency compared to isolated documents and knowledge. However, manipulating data views and content in MagicDraw requires a steep learning curve not needed by all users and even the user-friendly web view comes with downsides due to the static views. To provide a more dynamic user interface, ExMC investigated the use of Microsoft Power Platform which does not require as steep of a learning curve to become proficient. This introduces analytics to the DE infrastructure, offering customizable and dynamic data dashboards. ExMC continues developing these dashboards and tailoring the DE infrastructure in alignment with HHPD workforce needs.

M Krihak↗
DOE OSTI2020

Thermal Management for FPGA Nodes in HPC Systems

The integration of FPGAs into large-scale computing systems is gaining attention. In these systems, real-time data handling for networking, tasks for scientific computing, and machine learning can be executed with customized datapaths on reconfigurable fabric within heterogeneous compute nodes. At the same time, thermal management, particularly battling the cooling cost and guaranteeing the reliability, is a continuing concern. The introduction of new heterogeneous components into HPC nodes only adds further complexities to thermal modeling and management. The thermal behavior of multi-FPGA systems deployed within large compute clusters is less explored. Here, we first show that the thermal behaviors of different FPGAs of the same generation can vary due to their physical locations in a rack and process variation, even though they are running the same tasks. We present a machine learning–based model to capture the thermal behavior of each individual FPGA in the cluster. We then propose two thermal management strategies guided by our thermal model. First, we mitigate thermal variation and hotspots across the cluster by proactive thermal-aware task placement. Under the tested system and benchmarks, we achieve up to 26.4° C and on average 13.3° C system temperature reduction with no performance penalty. Second, we utilize this thermal model to guide HLS parameter tuning at the task design stage to achieve improved thermal response after deployment.

97 MATHEMATICS AND COMPUTING↗
NASA NTRSDate not supplied

Analysis of Alternative Architectures for Cargo Lunar Landers

NASA’s Human Landing System (HLS) program has been working with commercial partners to develop human-class lunar landers to return the first American woman and next American man to the lunar surface in the mid 2020’s. In an effort to expand human presence beyond low Earth orbit, NASA’s Artemis program aims to facilitate a sustainable, long-term human presence in cis-lunar space. A component of this will require significant infrastructure to be delivered to the lunar surface. Delivering this infrastructure will require a significant lander capability that has yet to be developed. A thorough understanding of cargo lunar lander architectures is required such that select alternatives can be identified that best support the Artemis program’s objective of sustainability. The goal of this study is to aid NASA and its partners in the understanding of the cargo lunar lander trades space, as well as identify potential robust alternatives. The results will support NASA as it moves forward with key activities such as requirements formulation, agency strategic planning, and potential cargo lunar lander procurements. The study builds off of recent work performed by the Human Landing System program’s Architecture and Systems Analysis group to encompass a broad trade space of cargo lunar lander architecture alternatives. The current trade space as depicted by the morphological matrix and mission graph in Fig. 1 and Fig. 2, respectively, includes key alternative options that have become highly relevant due to current HLS activities and include on-orbit refueling, active cryogenic fluid management, Earth orbit aggregation, and global lunar access. The authors believe that there is also a statistically relevant impact of lander-payload configuration on the primary structure of the vehicle that could greatly impact alternative selection. Because of this, several conceptual lander-payload configurations will be evaluated to determine the level of impact. The current set of conceptual configurations are shown in Fig. 3 and Fig. 4. To aid the conceptual evaluation of these configurations, a catalogue of notional payloads has been developed that represent a wide range of masses and volumes that are expected to be delivered in support of a sustained human lunar presence, including pressurized and unpressurized rovers, surface habitats, power systems, and other support infrastructure. In order to execute this study in a timely fashion, a similar approach to that utilized in a similar 2019 study focused on 2024 human lunar sorties will be employed [1]. The team utilized a novel architecture synthesis framework currently being developed by NASA/MSFC to evaluate over 600,000 lunar lander architectures over a two month time frame [2]. From this large data set, varying ground rules and assumptions were applied as filters to explore the trade space to identify alternatives which exhibited robustness, as measured by launch vehicle payload margin, to absorb the natural growth that occurs during design maturation. The set of Earth-Moon system Delta-Vs assumed from the 2019 study, shown in Fig. 5, will be repurposed to accelerate model formulation for this effort. Additionally, current efforts in collaboration with the Georgia Institute of Technology’s Aerospace System Design Lab will be integrated to provide probabilistic modeling of the cargo lunar lander architectures to aid in identifying robust design alternatives [3]. The approach will help minimize potential impacts due to large levels of uncertainty inherent to pre phase-A conceptual design. By leveraging these past and present studies and partnerships, a highly detailed set of data can be generated in a short time period to aid NASA in the coming years to support the goal of a sustained human lunar presence.

Architectures↗
DOE OSTI2021

A Reconfigurable Neural Network ASIC for Detector Front-End Data Compression at the HL-LHC

Despite advances in the programmable logic capabilities of modern trigger systems, a significant bottleneck remains in the amount of data to be transported from the detector to off-detector logic where trigger decisions are made. We demonstrate that a neural network (NN) autoencoder model can be implemented in a radiation-tolerant application-specific integrated circuit (ASIC) to perform lossy data compression alleviating the data transmission problem while preserving critical information of the detector energy profile. For our application, we consider the high-granularity calorimeter from the Compact Muon Solenoid (CMS) experiment at the CERN Large Hadron Collider. The advantage of the machine learning approach is in the flexibility and configurability of the algorithm. By changing the NN weights, a unique data compression algorithm can be deployed for each sensor in different detector regions and changing detector or collider conditions. To meet area, performance, and power constraints, we perform quantization-aware training to create an optimized NN hardware implementation. The design is achieved through the use of high-level synthesis tools and the hls4ml framework and was processed through synthesis and physical layout flows based on a low-power (LP)-CMOS 65-nm technology node. The flow anticipates 200 Mrad of ionizing radiation to select gates and reports a total area of 3.6 mm 2 and consumes 95 mW of power. The simulated energy consumption per inference is 2.4 nJ. Furthermore, this is the first radiation-tolerant on-detector ASIC implementation of an NN that has been designed for particle physics applications.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
NASA NTRSDate not supplied

Supervisory Control with Dual Tasking in Post G-Transition Vehicle Landings

BACKGROUND Landing during exploration spaceflight may consist of both planned automated supervisory control and unplanned crew override. Supervisory control, particularly when performed under cognitive load with additional monitoring tasks, is essential for ensuring overall mission success during landing contingencies. Evaluating performance in a relevant Human Landing System (HLS) supervisory landing task after long-duration microgravity exposure can help identify potential risks from human error and sensorimotor alterations. Adaptive changes in the sensorimotor system can manifest during g-transitions as spatial disorientation. Although training and landing aids facilitate successful landings despite disorientation, these adaptive changes may heighten cognitive demand, which must be considered in the landing strategy. It is important to characterize these effects as soon as possible following the G-transition while the sensorimotor system remains in a state of adaptive flux to inform appropriate countermeasures. METHODS A Multi-attribute Lunar Table Battery (MALTB) task was developed for an iOS tablet device to provide flexible crew testing and training capabilities in-flight and on the ground. Elements of the tablet task were derived from the Multi-Attribute Task Battery (MATB, Cegarra et al. 2020). The task requires crew members to study a map of a planned landing site and memorizing the terrain and surface landmarks to inform potential divert maneuvers during landing. The user will oversee a series of approaches through touchdown simulations on the tablet with an external camera view of the Lunar surface. The primary responsibility of the crew member will be to execute a divert if the guidance recommended site is erroneous (e.g., the guidance projected landing target is not within 10m of the planned landing site center), or the projected landing site is no longer suitable due to surface obstacles. Considering vehicle maneuverability and fuel reserves, the divert capabilities will diminish as the task progresses. In cases where a divert is initiated, a new landing target will need to be designated by the user and will be evaluated for the proximity to the original pre-planned site. A secondary operational monitoring task will challenge the user's cognitive reserve by requiring the user to maintain several gauges within acceptable limits and respond to a visual indicator while completing the landing approach. Outcome measures include distance from the planned landing site to the user-initiate divert landing location, ground slope at the new landing site, time to divert, the ability to accomplish the secondary monitoring tasks, and perceived workload. The tablet task is being evaluated in a ground-based study to determine the learning effect of first-time users. The tablet task will be utilized in a flight study to test performance multiple times postflight. Future potential testing in-flight have been identified for capsules with iOS tablet devices. Multi-attribute Lunar Table Battery Task MALTB comprises video footage of thirty distinct landing conditions. The landing scenarios feature various landing sites (n = 3), hazardous object sizes (n = 6), sun azimuth degrees (n = 4), camera modes (i.e., fixed or gimbaled), and navigation bias (i.e., true or false). Each seventy second trial uses a sixty-degree constant glideslope trajectory. The application architecture and layout include user identification setup and data storing, a guided walkthrough of the task and interface components, practice mode for task familiarization, and a modified Bedford workload scale administered following task completion. The time-based dependent measures are saved locally to the iOS Files application and post-processing scripts have been developed to evaluate the remaining measures of performance. RELEVANCE This project will deliver an operational demonstration of crew monitoring capability following spaceflight and identify potential deficits that may require remediation. Comparison of individual vestibular and cognitive changes with crew performance will help better characterize the landing risks associated with sensorimotor alterations. ACKNOWLEDGEMENTS: This project is funded by NASA’s Human Research Program Human Health Countermeasures Element. REFERENCES Cegarra J, Valery B, Avril E, Calmettes C, Navarro J (2020) OpenMATB: A Multi-Attribute Task Battery promoting task customization, software extensibility and experiment replicability. Behav Res Methods 52:1980-1990 doi: 10.3758/s13428-020-01364-w

Matthew McDonnell↗