Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Open source”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 775 records · Page 43

Software-Only Key Management and Cryptography (KMC) for Spacecraft Command Encryption

The Jet Propulsion Laboratory (JPL) Advanced Multi-Mission Operations System (AMMOS) in partnership with NASA’s Katherine Johnson Independent Verification and Validation (NASA IV&V) Jon McBride Software Testing and Research (JSTAR) laboratory have jointly developed a command encryption capability that provides a software-only encryption solution utilizing the CCSDS Space Data Link Security Protocol. This solution, named Key Management and Cryptography (KMC), incorporates JPL’s encryption service with the JSTAR open-source CryptoLib library, providing a solution for spacecraft command encryption, which is required per NASA standard NASA-STD-1006-A. This paper will focus on its design, usage, and operation for two SmallSat missions, along with its future expanded functionality of end-to-end spacecraft encryption.

command encryption↗

Porosity Area Fraction Analysis of Bonded Borosilicate Specimens From in-Situ Optical Imagery

Image segmentation methods are routinely used to analyze data derived in nondestructive testing scenarios. A typical problem in this area is to estimate porosity from X-ray Computed Tomography (CT) inspections. This investigation aims to understand the effectiveness of open-source image segmentation methods for porosity estimation from optical images in the context of strength analysis of bonded materials and provides a benchmark of performance against a standard commercial software package. The rank ordering of the specimens by porosity area fraction is consistent across both methods.

Porosity area fraction↗

The Core Flight System (cFS): NASA Quality Flight Software to Power Science and Exploration Available to the World

The presentation is planned to be a continuation of two previous discussions completed at the FSW Workshop regarding the cFS Test Framework (CTF) and Engineering Data Sheets (EDS). The presentation will also cover the latest advancements in cFS, including: 1. Quick into to cFS 2. An overview of our software release process + Git repo 3. Release of EDS files for the cFE + open-source apps 4. Overview of how to independently verify EDS files using CTF + what they can be used for. 5. Future plans for cFS. This presentation complements the talk on configuration management of distributed cFS repos, to be presented by Tam Ngo from Johnson Space Center.

Dan Knutsen↗

Observing System Simulations for the AOS Mission

The Earth System Observatory (ESO) is NASA’s response to the recommendations of the 2017 Earth Sciences Decadal Survey conducted by the US National Academy of Sciences, Engineering and Medicine. The ESO is being conceived as a set of fully integrated missions addressing 4 main Earth science focus areas including aerosols, clouds, convection and precipitation (jointly re-ferred to as AOS, the Atmosphere Observing System). ESO ground breaking observations will provide critical measurements to address societally relevant problems in climate change, natural hazard mitiga-tion, fighting forest fires, and improving real-time agricultural processes. A critical element of the AOS observing strategy is to make extensive use of new passive and active sen-sors as well as of the so-called Program-of-Record (PoR), complemented by a fully integrated sub-orbital component. In order to achieve maximum benefit, all these observations need to be integrated into comprehensive observing and modeling/data assimilation systems. Such an approach requires compre-hensive model-data synthesis capabilities that needs to be conceived in conjunction with the space-based and suborbital components of AOS. In this presentation we will summarize the major science goals of AOS including cloud feedbacks, at-mospheric convection, emphasizing aerosol processes and aerosol radiative effects, and the synergistic aspects of clouds-precipitation-aerosol interactions. We will describe examples of the observing system simulation capabilities being developed for AOS, including global storm resolving nature runs, detailed instrument and retrieval simulators, as well as fast retrieval emulators for instrumenting climate models. This simulation environment, being developed under NASA’s open-source science initiative, will permit us to explore how AOS data will be used across space and time to better initialize forecasts and train modeling systems, and to infuse models and data assimilation systems with AOS data, well before launch.

Arlindo da Silva↗

ExEP: Initial super-Nyquist wavefront control experiments in the Decadal Survey Testbed

In order to characterize exoplanets around nearby stars, upcoming and proposed space telescopes are being designed with high contrast coronagraph instruments. Coronagraphs are generally designed to suppress only a single, on-axis star, but there are numerous binary star systems within our observational range. Multi-star wavefront correction (MSWC) is a technique that uses deformable mirror(s) to simultaneously suppress light from more than one star to create a high contrast dark zone in the image. MSWC has already been well demonstrated in simulation and in air-based testbeds. In this paper, we describe our prepatory vacuum experiments in the Decadal Survey Testbed (DST) at the Jet Propulsion Laboratory. First we implemented super-Nyquist wavefront control (SNWC, a critical component of MSWC), and then we proceeded to simultaneous sub- and super-Nyquist control. With our existing calibration methods, SNWC reached a contrast of $8.6{\times}10^{-9}$ in a 10\% bandpass around a first-order diffraction spot; calibration improvements are needed to improve model agreement for higher-order spots. We have also implemented changes to our software (the open-source package FALCO) required for MSWC, and identified the necessary changes in hardware. Here we report our best SNWC lab results and our plans for implementing MSWC during a future set of experiments.

Bendek, Eduardo↗

MIKA: Manager for Intelligent Knowledge Access Toolkit for Engineering Knowledge Discovery and Information Retrieval

Repositories of safety reports are often underutilized and only analyzed manually by trained experts, despite safety management systems requiring reports. These collections of documents contain a wealth of information from past projects and operations that could improve system safety and design. Advances in natural language processing techniques have improved information extraction and retrieval in consumer technology, biomedicine, and finance, for instance, but have not been applied to engineering documents on the same scale. To this end, the Manager for Intelligent Knowledge Access (MIKA) open-source toolkit has been developed for rapid knowledge discovery and information retrieval in safety engineering applications. The MIKA toolkit uses state-of-the-art natural language processing algorithms and allows a user to apply these methods to their own dataset. This paper describes the MIKA toolkit and its two primary capabilities, knowledge discovery and information retrieval, and demonstrates the toolkit via a case study on National Transportation Safety Board (NTSB) reports.

Systems Engineering↗

Cloud-Based Demodulation and Data Distribution of a Satellite Downlink

Ground station networks connected to the cloud allow space missions to have global communications coverage without operating their own infrastructure. In this work, we describe the communications architecture for the TechEdSat-13 mission, which performed the first in-space characterization of a neuromorphic processor. The mission utilizes a commercial provider for S-band downlinks. A suite of cloud services and open-source software such as GNU Radio are leveraged to demodulate signals received by an AWS ground station during passes with TechEdSat-13 and store recovered data. Once a pass is scheduled, the entire process takes place without human intervention. On-orbit results the past year of operations are presented, demonstrating the advantages of this approach over traditional operator-owned ground stations. Use of software-defined radio makes possible custom signal processing. The homogeneity of apertures and their interfaces to the cloud simplifies scaling across many sites. This abundance of candidate links lays the groundwork for intelligent scheduling agents to optimize pass selection across several factors, automatically recover from failed contacts, and gather metrics to learn from past performance.

cloud demodulation↗

Trajectory Optimization Methods and Applications at NASA Goddard

The process of spacecraft trajectory design frequently incorporates an optimization step in which one or more objectives, such as propellant consumption or time of flight, is minimized. Optimization is especially crucial for low-thrust mission design, due to the need to specify a thrust vector at every instant in time along a trajectory. At NASA's Goddard Space Flight Center (GSFC) a number of open-source tools have been developed for spacecraft trajectory optimization that utilize direct shooting and collocation methods. These tools have been effectively applied to cislunar, libration point, and interplanetary mission design for the Lunar IceCube, SWFO, and DAVINCI missions, among others. This presentation outlines the theory underlying these optimization tools along with the details of their application to several trajectory design problems, with a focus on the Lunar IceCube (LIC) mission. The LIC mission required a low-thrust trajectory from a high-energy deployment state to a lunar orbit, and its limited control authority necessitated the use of optimization tools and low-energy trajectory design techniques. The tools discussed demonstrate how the use of optimization methods expands mission capabilities and enables transformational science.

Robert Pritchett↗

Astrobee: Completed, Current, and Future Research using Free Flying Robots on the International Space Station

After four years on the International Space Station (ISS), the Astrobee Research Facility, has completed over 130 Test Sessions logging over 1000 hours of operations. Managed by the NASA ISS Program OZ office and supported by NASA Ames Research Center (ARC) in California, the Astrobee Team maintains three identical free-flying Astrobee robots for research on the ISS. As a technology demonstration platform, the Astrobee Robots are available for Guest Scientists to use for a spectrum of research capabilities. Astrobee, propelled by battery-operated fans, is designed to autonomously operate throughout most of the USOS (US Orbital Segment), with the objective of minimizing astronaut support. Astrobee carries a suite of six cameras, a two degree-of-freedom (DOF) arm with a gripper that can grasp ISS handrails and other objects, and three payload bays that provide power and data for guest science hardware. Astrobee can autonomously execute hours-long flight plans or be teleoperated from the ground or by astronauts. While the Astrobee Team continues to improve mapping and autonomous flight capabilities, one of the main goals of Astrobee Robots is to provide research opportunities for Guest Scientists. The Astrobee Robot Software (ARS) makes extensive use of the open-source Robot Operating System (ROS). The ARS can be used interchangeably with an Astrobee Simulator or as Astrobee’s onboard software. ARS features include autonomous docking and perching, real-time teleoperations from the ground, plan based autonomous tasks, multi Astrobee communication, among other capabilities. Through simulation software and ground testing laboratories, the Astrobee Team is available to support Guest Scientists during development and testing and lead real-time ISS operations. Guest Scientists can participate in this research opportunity following the Guest Science Lifecycle (GSL) shown in Figure 1: Guest Science Lifecycle below. The Astrobee Team and Guest Scientists have complete research including Gecko materials studies, RFID and sound sensing capabilities, student Robotics Programming Challenges, and Free Flyer formation flight investigations. Current science with the Astrobee Robots includes Free Flyer self-toss studies, new docking capabilities, advanced mapping resolution capabilities, and high resolution panoramic imagery. Future Guest scientists and Astrobee Team research will focus on robotics applications for future NASA missions such as Gateway and Artemis and potential experiments involving human-robot interactions. This presentation will focus on four main subjects, 1) completed, current, and future planned research using the Astrobee robots, 2) how Guest Scientist get from conception to the ISS, 3) Astrobee Facility resources available for Guest Science ground testing and real-time ISS operations support, and 4) lessons learned from four years of ISS operations.

Astrobee↗

3D Cloud Tomography and Droplet Size Retrieval from Multi-Angle Polarimetric Imaging of Scattered Sunlight from Above

Tomography aims to recover a three-dimensional (3D) density map of a medium or an object. In medical imaging,it is extensively used for diagnostics via X-ray computed tomography (CT). We define and derive a tomographyof cloud droplet distributions via passive remote sensing. We use multi-view polarimetric images to fit a 3Dpolarized radiative transfer (RT) forward model. Our motivation is 3D volumetric probing of vertically-developedconvectively-driven clouds that are ill-served by current methods in operational passive remote sensing. Currenttechniques are indeed based on strictly 1D RT modeling and applied to a single cloudy pixel, where cloud geometrydefaults to that of a plane-parallel slab. Incident unpolarized sunlight, once scattered by cloud droplets, changesits polarization state according to droplet size. Therefore, polarimetric measurements in the rainbow and gloryangular regions can be used to infer the droplet size distribution. This work defines and derives a framework for afull 3D tomography of cloud droplets for both their mass concentration in space and their distribution across arange of sizes. This gridded 3D retrieval of key microphysical properties is made tractable by our novel approachthat involves a restructuring and partial linearization of an open-source polarized 3D RT code to accommodate aspecial two-step iterative optimization technique. Physically-realistic synthetic clouds are used to demonstrate themethodology with rigorous uncertainty quantification, while a real-world cloud imaged by AirMSPI is processedto illustrate the new remote sensing capability

Schechner, Yoav Y.↗

Making or Breaking a Rover: System Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Making or Breaking a Rover- Systems Engineering Parameters On-Board the Mars 2020 Perseverance Rover

On February 18, 2021, Perseverance, NASA’s Jet Propulsion Laboratory’s (JPL’s) Mars 2020 Rover, successfully landed on Mars with all systems nominal, despite the risk surrounding the over 200,000 internal flight parameters that had to be properly configured. The Perseverance team defines these parameters as software variables that are configurable, commandable and retrievable from Earth. In 2015, the Mars 2020 project leaders focused on improving systems engineering of parameters based on their experiences from parameter management on previous Mars rovers (Curiosity, Opportunity, Spirit, and Pathfinder) and parameter failures of past missions, such as the mission-ending parameter of the Mars Climate Orbiter. The new rigorous development process allowed for efficient certification and effective implementation of the parameters, allowing the rover to approach and land on the red planet (the most challenging phase of the mission) with zero parameter issues. Although successful, the Perseverance team learned many lessons for how to better manage parameters for the continued surface operations of the Mars 2020 mission and future missions. This paper will discuss eight parameter-management topics for the Perseverance Mission. The first is parameter definition: how we define parameters on our mission, where they are physically located on the vehicle, and why we have so many of them. The second topic is the updated parameter flight software module from Curiosity, including details on the 99% reduction in parameter commands, new bulk configuration capabilities, and improved parameter traceability. The third topic is parameter selection for different mission phases; this includes improving and tweaking our preferred parameter settings until they become certification candidates and managing parameter configurations based on test venue throughout the mission life cycle. The fourth topic is our flight certification process; this includes certification of flight values for four different epochs in the mission: Launch, Entry Decent and Landing (EDL) - 6days, Landing + 5 Sols (Martian Days, still on Cruise Flight Software), and once are on Surface Flight Software (FSW). The fifth topic covers in-flight command implementation, along with details on testing, validation, and verification of those commands. In the sixth section, we will explain our use of open-source management tools, including how we used GitHub for version control and management approvals. The seventh topic will describe the ground tools used in operations, including capabilities of the in-house built tool called Parasol. The eighth and final topic will dig into lessons learned for improving parameter management in the future of this mission and others.

Roth, Brian↗

Europa Clipper Payload Verification and Validation: Avionics-Instrument Interface Test Campaign

NASA's Europa Clipper mission will investigate Jupiter's icy moon Europa using a payload suite consisting of nine instruments to address a range of scientific objectives concerning Europa's habitability. As the project proceeds past its Critical Design Review, confidence is being built in the system's ability to achieve mission objectives through the implementation of a rigorous payload verification and validation (V&V) program. As part of this payload V&V program, instrument box-level testing was performed by the payload team to verify select instrument-avionics interface requirements. This testing was performed at JPL using the avionics testbed's Bulk Data Storage Emulator (BDSEM) with visiting instrument Test Models. This paper summarizes the Data Link test campaign involving roughly four days of functional testing per instrument, including planning, testing methods, types of issues found, and the requirement closure process. Detail is also provided on the development, deployment, and validation of a standardized analysis tool used in data reviews. This testing verified requirements related to commanding rates, loss of link, packet format, clock counters, loopback test capability, and SpaceWire jitter and skew margins. Additional risk reduction testing of basic commanding, counter behavior, science data collection and transfer, and interface swapping was also performed. Because the BDSEM venue was not originally designed to be a run for record venue, the process of characterizing venue fidelity and establishing suitability for requirement closure using data collected in this venue will also be addressed.In order to close requirements, an extensible tool was developed to post-process instrument command and telemetry data from their original binary to a human-readable format and give visibility to errors detected within the data, such as packets with Cyclic Redundancy Check errors. This tool, called payload-packet-parser, is a Python 3.9 command line tool built using a variety of open-source Python libraries. Payload-packet-parser was designed to support parsing command and telemetry packets for all Europa Clipper instruments and additional analysis tools were developed for verification of specific information interface requirements. This test campaign, including post-processing using a single parsing and verification toolset, allowed for early interface testing, alleviating testing burdens on instrument teams and buying down risk on the instrument-avionics interface by finding hardware and software issues and idiosyncrasies prior to integration with system test venues. Over twenty issues were discovered across the payload, resulting in software updates and instrument rework well in advance of any system impacts. This paper concludes with an assessment of benefits and costs of this type of testing and lessons learned.

Montanez, Leticia↗

Habitability Assessments And Lessons-learned From 3-day And 11-day Enriched Oxygen Hypobaric Chamber Tests At NASA Johnson Space Center

INTRODUCTION: Decompression sickness (DCS) is a risk to the health and performance of astronauts and high-altitude aircrew. Tolerance to flammability, hypoxia, prebreathe duration, and DCS risk varies across different organizations, vehicles, suits, and destinations, necessitating a variety of DCS risk mitigation approaches. Existing models of altitude DCS risk are often insufficient to enable accurate risk-informed decisions during hardware development, mission planning, and flight operations. METHODS: NASA completed outfitting of a dedicated facility at Johnson Space Center to support testing of up to eight human subjects for multiple days in hypobaric and enriched oxygen atmospheres. The primary purpose of the testing capability is validation of DCS risk mitigation protocols for Artemis missions to the Moon; however, it will also support development and validation of a generalizable altitude DCS risk estimation tool. A 3-day and an 11-day prebreathe validation test were completed in 2022, each with 8 human subjects living at 56.5 kPa (8.2 psia), 34% O2, 66% N2, with 5 simulated EVAs performed on masks at 29.6 kPa (4.3 psi), 85% O2, 15% N2. Facility and organizational lessons-learned and process improvements were recorded during and following the tests, and subjective habitability ratings were recorded daily during the 11-day test. Hypoxia and DCS-related physiological and cognitive outcome measures were recorded during both tests and are reported in companion presentations. RESULTS & DISCUSSION: All subjects completed each of the tests. Primary habitability issues related to mask discomfort during simulated EVAs and poor sleep quality due to thin mattresses. Polybenzimidazole (PBI) clothing was worn by all subjects due to the increased fire risk and may be required for Artemis missions; clothing was found to be acceptable overall with the worst ratings being due to poor fit and inelasticity. Chamber O2 and CO2 sensor inconsistency was observed that did not result in test termination but required post-test follow-up. Forward plans include additional hypobaric testing and integration of existing and future physiological outcome data into an open-source Aerospace Estimation Tool for Hypobaric Exposure Risk (AETHER). NASA is also working to make the testing capability available to commercial companies.

Andrew Abercromby↗

Data Sharing in Radiation Biology: Towards FAIR

The value of scientific data depends on their findability, accessibility, integrability and reusability according to the FAIR principles. Together with the sustainability of data preservation and access, these principles underpin the long term benefits of scientific research. Within the domain of radiobiology we have a huge array of data types, themes and complexities which make standardisation of metadata, data structure and data integration very challenging. Moreover, it is clear that, for example, in the area of disaster preparedness, the ready discovery and availability of multiple types of data, for example on biological effects of exposure, climatology, ecology, human behavioural and attitudinal studies, is important for an integrated scientific approach. Because these data are spread over many databases, journal supplementary information resources and even the computers of the investigators, their discovery and reuse can be challenging. Despite exhortations from funding agencies and scientific institutions over the past two decades there is still a serious deficit in the willingness and in some cases the ability of investigators to share data, and although much may not be formally "Public domain“, information about the existence of the data, their metadata, and how to obtain them should always be available. We report the progress of work on three databases, the STORE and the NASA GeneLab and LSDA repositories to leverage the Radiation Biology Ontology (RBO), a structured terminology for metadata that can be used by all radiation biology-relevant databases to unite federated and automated data searches across multiple databases, for example using web services, and through semantic web technologies supporting data discovery. The initial primary use-cases for RBO were archiving data in the STORE database (https://www.storedb.org/), the repository used for the RadoNorm and Pianoforte Projects among others, and in the NASA Open Science Data Repository (https://osdr.nasa.gov/bio). The scope of radiobiology research ranges from basic physics to radiation oncology to sociolegal studies; no existing ontology had the necessary breadth or depth to fulfill this need. In addition, a formal ontology has the advantage of being usable for machine learning and, importantly, for tasks like data integration, knowledge extraction from the scientific literature and for query extension and data classification. Standardisation of metadata is one of the primary objectives of the FAIR principles for open data; RBO is an important landmark for FAIR-compliant radiation biology data sharing. The RBO is developed using the open-source tools of GitHub and the OBO Foundry-led Ontology Development Kit, and published through GitHub and the NIH/NCBI BioPortal website. This initial phase of concept modeling has yielded an ontology that has more than 300 declared concepts, with more than 3500 additional concepts imported from other OBO Foundry ontologies with relevance to radiation biology (for example, concepts from the ISO standard Basic Formal Ontology, the Environment Ontology and the Gene Ontology). We welcome input into the development of RBO and encourage its adoption.

ontologies↗

VEDA Visualization Exploration & Data Analysis

Why? - Interdisciplinary science depends on large amount of Earth science data and computational resources - Working with these datasets is non-trivial - Big data science requires advanced distributed computing knowledge What? VEDA is an open platform that brings key Earth science datasets next to open source tools for data processing, analysis, visualization, and exploration in a managed and more accessible computing environment.

Manil Maskey↗

Pypromice: A Python Package for Processing Automated Weather Station Data

The pypromice Python package is for processing and handling observation datasets from automated weather stations (AWS). It is primarily aimed at users of AWS data from the Geological Survey of Denmark and Greenland (GEUS), which collects and distributes in situ weather station observations to the cryospheric science research community. Functionality in pypromice is primarily handled using two key open-source Python packages, xarray (Hoyer & Hamman, 2017) and pandas (The pandas development team, 2020). A defined processing workflow is included in pypromice for transforming original AWS observations (Level 0, L0) to a usable, CF-convention-compliant dataset (Level 3, L3) (Figure 1). Intermediary processing levels (L1,L2) refer to key stages in the workflow, namely the conversion of variables to physical measurements and variable filtering (L1), cross-variable corrections and user-defined data flagging and fixing (L2), and derived variables (L3). Information regarding the station configuration is needed to perform the processing, such as instrument calibration coefficients and station type (one-boom tripod or two-boom mast station design, for example), which are held in a toml configuration file. Two example configuration files are provided with pypromice , which are also used in the package’s unit tests. More detailed documentation of the AWS design, instrumentation, and processing steps are described in Fausto et al. (2021).

pypromice↗

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↗