Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “verification and validation”

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 865 records · Page 48

Lean Model-Based Systems Engineering on the NASA High-Density Vertiplex Subproject

The High Density Vertiplex (HDV) subproject of NASA’s Advanced Air Mobility (AAM) project adopted Model-Based Systems Engineering (MBSE) in July of 2020, prior to subproject formulation. A small and lean team of HDV Systems Engineers (SE) are utilizing MagicDraw to execute NASA SE processes via MBSE. The SEs learned how to use MagicDraw from scratch and HDV is the first project for which the SEs have utilized MagicDraw. This presentation will demonstrate project technical execution via MBSE, utilizing the digital elements built into the SysML (Systems Modeling Language). SysML provides a model-centric means of carrying out the NASA SE common technical processes by providing tools for complete system modeling, including requirements and interface management and design capture. The authors also leverage and extend SysML to perform other SE tasks, such as Verification and Validation (V&V) tracking. MBSE has two main purposes for HDV: 1) documenting the subproject’s logical architecture for distribution outside of the subproject, 2) capturing the subproject’s physical architecture in a single-source-of-truth for use by the subproject’s members. This presentation details the challenges, lessons learned, and solutions that were encountered in implementing MBSE in the first iteration on a multi-iteration, full-lifecycle design, build, fly project.

systems engineering↗

Research and Technology Challenges for Human Data Analysts in Future Safety Management Systems

Enabling new and novel concepts of operations for Advanced Air Mobility poses an important need to evolve current safety management systems (SMS) and is posited to be realized through advances in Machine Learning (ML) Data Sciences and Artificial Intelligence. The “In-time Aviation Safety Management System” (IASMS) concept of operations supports the need to evolve today’s SMS to become more tailorable, scalable, and interoperable in response to forecasted changes expected for the future airspace system. Key to IASMS is integration of proactive and predictive ML algorithms trained to provide “in time” detection and mitigation of hazards and emergent risks through new methods and novel data types. IASMS research and technology development includes human factors design considerations for these systems to include human-system teaming, innovations in human interfaces and management of complex digital data information, human-system interaction/model-based system engineering, and verification and validation for data assurance and trust.

Chad L Stephens↗

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

A model using the Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink® model block library of electrical components, was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The goal of the model was to demonstrate the utility of the library by comparing the accuracy of the library models to the performance of real hardware, with the primary metrics being the simulation outputs matching physical test hardware data within 5% of full scale.The objective of this paper is to present the background, setup, testing and results of this comparison. It describes some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation. The outputs of the model were compared to the results of several tests in HyPER, and in the process captured an additional torque loss that is still being analyzed for the root cause but has been confirmed in the hardware. Across all the test series, only one key model parameter was outside the target 5% full scale matching, and nearly 70% were within 1%.

Mark E Bell↗

Comparing the Electrical Modeling and Thermal Analysis Toolbox Simulation Data to Electrified Aircraft Propulsion Test Hardware Data

The Electrical Modeling and Thermal Analysis Toolbox (EMTAT), a National Aeronautics and Space Administration (NASA)-developed Simulink™ model block library of electrical components developed with the goal of facilitating system-level control design and analysis, has two levels of fidelity depending on the test needs. The Physics Based model blocks are designed to use physical component characteristics to more accurately model real hardware, including power losses, efficiency, thermal effects, electromagnetic losses, voltage drops and current requirements. These blocks model electrical dynamics that occur at the millisecond turbomachinery time scale which allows for faster-than-real-time electrified turbomachinery simulations. A model was developed to mirror the Hybrid Propulsion Emulation Rig (HyPER) hardware, a laboratory focused on Electrified Aircraft Propulsion (EAP) hardware tests. The present hardware setup supports Turbine Electrified Energy Management (TEEM) testing. The outputs of the model were compared to the results of several tests on the HyPER laboratory motor-generator setup with the goal of matching the steady state simulation data to steady state hardware data within 5% of full scale. The objective of this paper is to present the background, setup, testing and results of this comparison. It will describe some of the adjustments that were necessary to match the system hardware, as well as next steps in verification and validation.

Hyper↗

Mars 2020 Entry, Descent, and Landing System Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗

Actuator and Motor Control End-to-End V&V on the Mars 2020 Rover

The Mars 2020 Perseverance rover is the most advanced robotic exploration system ever sent to another planet. To support the complex scientific and mobility needs of the mission, the rover utilizes 33 actuators, three multi-degree-of-freedom force-torque sensors, fifteen single or dual-speed resolvers, two solenoid valves, and twelve contact switches. The control for these actuators and sensors is achieved by several levels of flight software, coordinated between two computers with varying bandwidth control loops. Furthermore, the actuators and sensors were integrated into multiple larger robotic mechanisms that were delivered by different organizations at various points in the Integration and Test (I&T) timeline. All of this created a very complex Verification and Validation (V&V) scenario involving multiple subsystems and teams, several hardware and software testbeds with varying levels of fidelity, and significant systems engineering to ensure the overall I&T schedule could be maintained while ensuring system hardware safety.This paper details the integrated V&V effort across multiple teams and venues to provide full coverage of all necessary functionality, performance, and fault protection. First, it provides an overview of how the V&V campaign was subdivided among teams and venues and provides descriptions of the various hardware configurations used to support the testing. The Mars 2020 implementation of the plan incorporates many of the lessons learned from Mars Science Laboratory’s test campaign, and these value-added modifications are discussed here. Also included in this section is the system-level environmental testing approach used for mechanisms. Second, the paper describes the phased approach used by the teams to support new hardware and software deliveries to testbed and Systems I&T. In this approach the test campaign was built upon higher-level mechanism needs for performance, functionality, and safety at specific times in the campaign. Finally, the paper discusses lessons learned from the V&V campaign that should be applied to future large-scale motion control testing efforts.

Borne, Davis↗

Mars 2020 Entry, Descent, and Landing Software Implementation

On February 18th, 2021, the Mars 2020 project's Perseverance Rover successfully touched down on the Martian surface after nearly eight years of development. The Mars 2020 Entry, Descent, and Landing (EDL) System largely leveraged heritage from the Mars Science Laboratory (MSL) EDL System while employing targeted technological advancements. The landing process is autonomously directed by a software behavior implemented in the rover's primary flight computer called the EDL Timeline that assumes control of the vehicle six days before atmospheric entry. In addition to performing the critical function of landing the rover on the Martian surface, the EDL timeline behavior must co-exist in a non-partitioned software and system environment with other high-level functions that accomplish the goals for the rest of the mission. Due to the criticality of EDL, the potential for loss of mission, and a need for complete system autonomy, the standard for how the EDL Timeline interacts with other functions in the system is highly constrained. This paper first walks through the basics of the EDL Timeline mechanics and how the behavior is designed to account for internal system variations and environmental unknowns. It then summarizes the interactions between the EDL timeline and other high-level system behaviors like spacecraft mode transitions and system fault protection, focusing on the complications that arise when passing spacecraft control between executive functions. Although the MSL-inherited EDL System is reliable and capable, targeted updates and a thorough verification and validation program were required for Mars 2020. This paper discusses changes made to close vulnerabilities discovered during both MSL and Mars 2020 development cycles, landing system capability enhancements that were enabling for Mars 2020's mission, and how these updates were integrated with the heritage system. It then describes how both analysis and testing campaigns were utilized to verify and validate all aspects of EDL and system behaviors that run during the six days before landing, as well as the operational workarounds that were needed to address problems found during the development and commissioning process. Finally, this paper imparts lessons learned from Mars 2020 EDL development, implementation, and operations, emphasizing how systems designed to conduct time-critical mission events with low margin of error can be improved in the future.

Stehura, Aaron↗

Flight Software Dictionary Development for the Mars2020 Rover

The Mars2020 project, developed and operated by the Jet Propulsion Laboratory (JPL), successfully landed the Perseverance rover and its flying companion Ingenuity on the surface of Mars on February 18th 2021. Perseverance combines heritage and cutting-edge flight software and hardware to accomplish crucial mission requirements related to Martian surface sampling. The design, development, and operation of NASA’s large strategic science missions require the ability to communicate spacecraft capabilities to hundreds of engineers across multiple disciplines. The interaction between flight and ground software development, Verification and Validation (V&V), Assembly, Test, and Launch Operations (ATLO), and management each demand quick understanding of unique slices of information for each discipline. This information includes the current capabilities of the flight system as well as future capabilities and their status as they are developed and tested. Despite the fundamental and critical nature of this information, the flight software dictionaries used to track it are a stumbling block for many projects. These dictionaries provide the cornerstone for the interpretation of data sent from the spacecraft, allowing for quick comprehension by engineers on the ground. During both spacecraft development and operations, flight software dictionary management includes significant challenges due to the large number of interfacing systems and the subtle yet distinct needs of each.The engineering of flight software dictionaries for Mars2020 had numerous challenges, most-notably: parallel dictionary development to support simultaneous separate flight software build campaigns for each mission phase (cruise and surface), managing requests for operations-enabling information without perturbing the heritage interface with the rover, and the introduction of new tools by the dictionary stakeholders that forced the dictionary team to innovate and redesign the heritage tool chain. These challenges generated guiding principles for the dictionary development effort: emphasize coding best practices and unit testing in the dictionary code development tool chain, use institutionally provided COTS (commercial-off-the-shelf) tools whenever possible, and maintain the heritage flight-ground interface all while advancing operations-enabling information via a loosely coupled interface.Throughout development and operations, the Mars2020 dictionary toolchain included IBM DOORS Next Generation, GitHub, Microsoft Excel, Docker, Jenkins, and a significant custom-built Python codebase. Significant interfaces included JPL’s command and control software, heritage flight software team tools and processes, and the many cloud-based ground tools developed for the mission.This paper will discuss the requirements for the Mars2020 dictionary development, the development team’s response to those requirements, lessons learned throughout the process, steps taken towards automated deliveries and continuous integration of stakeholder inputs, potential toolchain improvements for Mars2020, and key takeaways that could be applied to future missions.

Pyrzak, Guy↗

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↗

Assessment of M2020 Terrain Relative Landing Accuracy: Flight Performance vs Predicts

Terrain Relative Navigation (TRN) was a critical enabling Entry, Descent, and Landing (EDL) technology that enabled Mars 2020 mission Perseverance rover to land at Jezero crater. TRN pro-vides real-time, autonomous, map-relative position determination and generates a landing target based on a priori knowledge of hazards. The required performance for TRN was to land within 60m of the selected target. The required 60m was sub-allocated to various error sources in three major categories: targeting error, knowledge error, and control error. The targeting error is the error in selecting an appropriate landing target and the knowledge of the target on the surface. It includes the Lander Vision System (LVS) position localization with respect the ground, the synchronization between the Lander Vision System measurement and the main Navigation filter, and errors associated with the LVS Reference Map and Safe Target Selec-tion (STS). The knowledge error is the contribution of knowledge growth from the synchronization with LVS to touchdown. The control error encompasses how accurately the system could stay on the desired reference trajectory. The TRN error budget uses a combination of analysis, simulation, and hardware test-ing results to bound the various error contributions obtained during the verification and validation process. This paper first presents a description the TRN system, focusing on the architecture of LVS and STS. The paper then gives detailed overview of the TRN error budget, with a description of the major error contribu-tions in each of the three categories. Next, the paper gives the results for three versions of the error budget, pre-launch, in-flight pre-landing, and post-landing. The paper compares the pre-flight analysis, the pre-landing analysis using in-flight data during cruise, to the post-landing analysis of the TRN performance. Pre-landing analysis best estimate of the landing performance was 33m, compared to the 60m require-ment. Post-landing analysis estimated a landing accuracy of 8.53m or better, much better than the 33m pre-landing estimate. The actual post-landing imagery calculated the distance of the rover to the targeted location to be 5m. The post-landing analysis closely bounds the image-based assessment of landing accu-racy, indicating the success of the error budget architecture in bounding the landing accuracy, as well as the fidelity of the simulations used to model and predict performance.

Chen, Allen↗

Simulating Mars: Enabling Testing of the Perseverance Rover Sampling and Caching Subsystem on Earth

The development of the Sampling and Caching Subsystem (SCS) on the JPL Perseverance Rover lies at the intersection of testing, robotics, and geology. The SCS team established three primary system test campaigns and venues to aid in the development of SCS through verification and validation testing – Qualification Model Dirty Testing (QMDT) to provide a venue for testing in a Martian environment, Vehicle System Testbed (VSTB) for testing while integrated with the mobility subsystem on Martian-like terrain, and the Flight Software Testbed (FSWTB) for conducting tests using the flight motor controllers and software system on a hexapod which had the ability to simulate rover tilt. Each venue contributed a vital piece to the SCS building blocks. However, the QMDT venue operating within a 10-ft diameter Thermal Vacuum chamber to simulate Martian environment provided a sui generis opportunity to fine tune the entire sampling and caching process while building the team’s knowledge base about rock drillability, system life, and target selection. On Earth, because Martian rocks are not readily available, the development team must utilize geoanalogs to the rocks and regolith on Mars. Geologists on the team helped establish a set of standard rock types to use for Mars missions, like Basalt, Sandstone, Mudstone, Gypsum, and other related geoanalogs. These geoanalogs are characterized with a standard suite of tests for density, compressibility, and other characteristics to categorize potential drillability. This concept of drillability is what links the geoanalogs on Earth to the samples we collect on Mars. With the simulant characteristics defined, these geoanalog rocks are ready to be drilled into as we do on the Martian surface. A key aspect of interacting with the surface on Mars is rock target identification and selection. The Perseverance robotic system uses the on-board cameras, instrumentation, and software to collect enough information to identify potential scientific targets. With the targets identified, SCS can place the Corer and abrade the surface or collect a sample. For a ground test activity like QMDT, the test team did not have all of the camera and instrumentation systems that the rover does, so the team developed ground test equivalents to process a rock, build a target map, and define the target. The team constructed a Rock Scanning Station to build a 3D point cloud of the rock. This point cloud was then processed and evaluated with predefined and programmed criteria in a Target Downselect Tool. A primary output of the Target Downselect Tool is a defined target that can be uploaded directly to the robotic software system to simulate and build the robotic sequences used in tests. With these insights and programmatic definition of targets, the QMDT test team was able to make the same decisions that the Perseverance surface operations team does. In addition, valuable lessons learned from developing the target selection ground tools and using them were implemented into the tools used for surface operations.

Kim, Junggon↗

Establishing Standardized Test Methods for Evaluating Space Suit Gloves

The Artemis space suit glove environmental protection garment (EPG) will be the first line of protection used to shield the crewmember’s hands from the environments encountered during extravehicular activity (EVA). As the Artemis missions will include more extreme environments than those experienced on the International Space Station, development, verification, and validation of gloves poses three key challenges. First, there are no standardized tests defined to evaluate the durability of space suit gloves for the extreme lunar environments, particularly the permanently shadowed regions. Second, there is insufficient data on state-of-the-art glove performance in a lunar environment from which to compare new designs. Third, current ISS glove Thermal Micrometeoroid Garment (TMG) fabrics are unlikely to be sufficient to meet Lunar requirements. It is therefore necessary to define tests to evaluate if gloves can meet new, challenging requirements. This paper focuses on the development of a test procedure to characterize lunar EVA glove fabrics using ASTM standardized test methods and the design and validation of a new standardized test procedure for comparing abrasion resistance between fabrics in lunar-like conditions. The results of testing on twelve candidate EVA glove fabrics are presented.

Robert J. Jones↗

Discovery and Analysis of Rare High-Impact Failure Modes using Adversarial RL-Informed Sampling

Adaptive learning agents have tremendous potential to handle critical tasks currently performed by humans. Unfortunately, due to their complexity, it can be difficult to verify that these learning agents do not have critical failure modes. Standard verification and validation methods often do not apply directly to learning agents and Monte Carlo methods have difficulty covering even a small fraction of the state space, especially in multiagent systems or over long time horizons. To overcome this difficulty, we demonstrate an adaptive stress-testing method based on reinforcement learning of correlations that raise the probability of failure. This approach has three key properties: (1) it is able to find rare failure modes with far greater sample efficiency than Monte Carlo methods, (2) it can estimate the true probability of a failure mode despite the inherent bias in the learning method, and (3) it is capable of learning and resampling compact representations of multimodal failure spaces. These properties are important in practice as we need to find disparate failure modes while accounting for their actual relevance. This is a significant advantage over traditional adaptive stress testing methods that give abstract likelihoods of particular failure instances, but cannot estimate the probability of a broader failure mode. We test our algorithm on a simple problem from the aviation domain where an autonomous aircraft lands in gusty wind conditions. The results suggest that we can find failure modes with far fewer samples than the Monte Carlo approach and simultaneously estimate the probability of failure.

Validation↗

Discovery and Analysis of Rare High-Impact Failure Modes using Adversarial RL-Informed Sampling

Adaptive learning agents have tremendous potential to handle critical tasks currently performed by humans. Unfortunately, due to their complexity, it can be difficult to verify that these learning agents do not have critical failure modes. Standard verification and validation methods often do not apply directly to learning agents and Monte Carlo methods have difficulty covering even a small fraction of the state space, especially in multiagent systems or over long time horizons. To overcome this difficulty, we demonstrate an adaptive stress-testing method based on reinforcement learning of correlations that raise the probability of failure. This approach has three key properties: (1) it is able to find rare failure modes with far greater sample efficiency than Monte Carlo methods, (2) it can estimate the true probability of a failure mode despite the inherent bias in the learning method, and (3) it is capable of learning and resampling compact representations of multimodal failure spaces. These properties are important in practice as we need to find disparate failure modes while accounting for their actual relevance. This is a significant advantage over traditional adaptive stress testing methods that give abstract likelihoods of particular failure instances, but cannot estimate the probability of a broader failure mode. We test our algorithm on a simple problem from the aviation domain where an autonomous aircraft lands in gusty wind conditions. The results suggest that we can find failure modes with far fewer samples than the Monte Carlo approach and simultaneously estimate the probability of failure.

Validation↗

Critical Progressive Damage Analysis Model Features for Low-Velocity Impact on Thermoset and Thermoplastic Panels

A previous verification and validation framework evaluated the ability of various progressive damage analysis (PDA) tools to predict the mechanical response and damage state in post-buckled stiffened aerospace structures composed of fiber-reinforced thermoset composite materials. Herein, the ability of PDA tools to predict damage in thermoplastic composite materials subject to low-velocity impact (LVI) loading has been assessed. LVI tests and analyses have been conducted for similar panels, comprising thermoset or thermoplastic composite materials. Preliminary test/analysis correlations revealed that using the same combination of PDA model features and finite element model-building guidelines for the thermoset and thermoplastic LVI specimens resulted in underprediction of matrix crack lengths and delaminated area in the thermoplastic analyses despite yielding good correlations for the thermoset specimens. In this paper, the quality of the test/analysis correlations for analyses of thermoplastic LVI specimens performed with different combinations of PDA model features using the NASA CompDam material model are presented. Model features that were assessed in terms of effect on the quality of the test/analysis correlation include the representation of damageable interfaces, residual thermal stresses, and fiber damage.

Frank Leone↗

Polymeric Materials Application and Testing for Space Missions

The EM41 Non-metallics polymers team performs polymeric materials screening, characterization, development, qualification, verification and validation testing for flight hardware and in-space applications. They perform insight, testing and application of polymeric materials for launch vehicles and space environments. Personnel have a deep understanding of the technologies associated with cryogenic insulation, high temperature thermal protection materials, paints, primers, coatings, and adhesive materials. Numerous TPS material characterization tests can also be performed by the Lab. The team has both internal and partner test capabilities to subject polymeric materials to Aerospace and Space environments Material properties, response and performance are tested within environments from the launch pad, through the launch environment and into space. A primary role of the team is to select materials and organize test regimen then analyze test results. Test regiment are established to confirm the materials meet the performance requirements levied by customers within the environments that are expected for the mission.

Thermal↗

Lunar Proving Grounds Definition

The Lunar Surface Innovation Consortium (LSIC) is hosting a hybrid Lunar Proving Grounds Definition Workshop, July 12-13,2023, at the Johns Hopkins University Applied Physics Laboratory in Laurel, Maryland, and on Zoom. The topic of facilities needed for testing hardware destined for the Moon and the need for Earth-based ‘Lunar Proving Grounds’ for testing systems has come up across all six Focus Areas of LSIC. While facilities exist for component- and instrument- level technology maturation (e.g., up to system/subsystem demo in relevant environments), and there are potential flight opportunities for component maturation to flight-qualified and even flight-proved systems, the Artemis Program vision for a sustained presence and transition to industry (e.g., the Moon to Mars Objectives and the LSIC “Path to an Enduring Lunar Presence” white paper) suggests an architecture of integrated systems and systems of systems more complex than Apollo or the International Space Station. Some questions we aim to address through this workshop include: (1) How will validation and verification of these systems and interactions, including human-robotic operations, be accomplished? (2) What metrics need to be tested, and thus what capabilities will such a facility or facilities need? (3) Which functionalities can be tested separately and which need to synergize? What can be the role of digital engineering?

Proving Grounds↗