Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “stakeholder expectations”

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 19 records
All sourcesNASA NTRSDOE OSTI
NASA NTRS2012

Managing Small Spacecraft Projects: Less is Not Easier

Managing small, low cost missions (class C or D) is not necessarily easier than managing a full flagship mission. Yet, small missions are typically considered easier to manage and used as a training ground for developing the next generation of project managers. While limited resources can be a problem for small missions, in reality most of the issues inherent in managing small projects are not the direct result of limited resources. Instead, problems encountered by managers of small spacecraft missions often derive from 1) the perception that managing small projects is easier if something is easier it needs less rigor and formality in execution, 2) the perception that limited resources necessitate or validate omitting standard management practices, 3) less stringent or unclear guidelines or policies for small projects, and 4) stakeholder expectations that are not consistent with the size and nature of the project. For example, the size of a project is sometimes used to justify not building a full, detailed integrated master schedule. However, while a small schedule slip may not be a problem for a large mission, it can indicate a serious problem for a small mission with a short development phase, highlighting the importance of the schedule for early identification of potential issues. Likewise, stakeholders may accept a higher risk posture early in the definition of a low-cost mission, but as launch approaches this acceptance may change. This presentation discusses these common misconceptions about managing small, low cost missions, the problems that can result, and possible solutions.

Barley, Bryan↗
NASA NTRS2011

Crew Survivability After a Rapid Cabin Depressurization Event

Anecdotal evidence acquired through historic failure investigations involving rapid cabin decompression (e.g. Challenger, Columbia and Soyuz 11) show that full evacuation of the cabin atmosphere may occur within seconds. During such an event, the delta-pressure between the sealed suit ventilation system and the cabin will rise at the rate of the cabin depressurization; potentially at a rate exceeding the capability of the suit relief valve. It is possible that permanent damage to the suit pressure enclosure and ventilation loop components may occur as the integrated system may be subjected to delta pressures in excess of the design to pressures. Additionally, as the total pressure of the suit ventilation system decreases, so does the oxygen available to the crew. The crew may be subjected to a temporary incapacitating, but non-lethal, hypoxic environment. It is expected that the suit will maintain a survivable atmosphere on the crew until the vehicle pressure control system recovers or the cabin has otherwise attained a habitable environment. A common finding from the aforementioned reports indicates that the crew would have had a better chance at surviving the event had they been in a protective configuration, that is, in a survival suit. Making use of these lessons learned, the Constellation Program implemented a suit loop in the spacecraft design and required that the crew be in a protective configuration, that is suited with gloves on and visors down, during dynamic phases of flight that pose the greatest risk for a rapid and uncontrolled cabin depressurization event: ascent, entry, and docking. This paper details the evaluation performed to derive suit pressure garment and ventilation system performance parameters that would lead to the highest probability of crew survivability after an uncontrolled crew cabin depressurization event while remaining in the realm of practicality for suit design. This evaluation involved: (1) assessment of stakeholder expectations to validate the functionality being imposed; (2) review/refinement of concept of operations to establish the potential triggers for such an event and define the response of the spacecraft and suit ventilation loop pressure control systems; and (3) assessment of system capabilities with respect to structural capability and pressure control. 1 Crew and Thermal Systems Division, NASA Johnson Space Center, Mail Code: AES29, 2101 NASA Parkway, Houston,

Sargusingh, Miriam J.↗
NASA NTRS2012

Crew Survivability After a Rapid Cabin Depressurization Event

Anecdotal evidence acquired through historic failure investigations involving rapid cabin decompression (e.g. Challenger, Columbia and Soyuz 11) show that full evacuation of the cabin atmosphere may occur within seconds. During such an event, the delta-pressure between the sealed suit ventilation system and the cabin will rise at the rate of the cabin depressurization; potentially at a rate exceeding the capability of the suit relief valve. It is possible that permanent damage to the suit pressure enclosure and ventilation loop components may occur as the integrated system may be subjected to delta pressures in excess of the design-to pressures. Additionally, as the total pressure of the suit ventilation system decreases, so does the oxygen available to the crew. The crew may be subjected to a temporarily incapacitating, but non-lethal, hypoxic environment. It is expected that the suit will maintain a survivable atmosphere on the crew until the vehicle pressure control system recovers or the cabin has otherwise attained a habitable environment. A common finding from the aforementioned reports indicates that the crew would have had a better chance at surviving the event had they been in a protective configuration, that is, in a survival suit. Making use of these lessons learned, the Constellation Program implemented a suit loop in the spacecraft design and required that the crew be in a protective configuration, that is suited with gloves on and visors down, during dynamic phases of flight that pose the greatest risk for a rapid and uncontrolled cabin depressurization event: ascent, entry, and docking. This paper details the evaluation performed to derive suit pressure garment and ventilation system performance parameters that would lead to the highest probability of crew survivability after an uncontrolled crew cabin depressurization event while remaining in the realm of practicality for suit design. This evaluation involved: (1) assessment of stakeholder expectations to validate the functionality being imposed; (2) review/refinement of concept of operations to establish the potential triggers for such an event and define the response of the spacecraft and suit ventilation loop pressure control systems; and (3) assessment of system capabilities with respect to structural capability and pressure control.

Sargusingh, Miriam J.↗
NASA NTRS1994

Office of Space Science: Integrated technology strategy

This document outlines the strategy by which the Office of Space Science, in collaboration with the Office of Advanced Concepts and Technology and the Office of Space Communications, will meet the challenge of the national technology thrust. The document: highlights the legislative framework within which OSS must operate; evaluates the relationship between OSS and its principal stakeholders; outlines a vision of a successful OSS integrated technology strategy; establishes four goals in support of this vision; provides an assessment of how OSS is currently positioned to respond to the goals; formulates strategic objectives to meet the goals; introduces policies for implementing the strategy; and identifies metrics for measuring success. The OSS Integrated Technology Strategy establishes the framework through which OSS will satisfy stakeholder expectations by teaming with partners in NASA and industry to develop the critical technologies required to: enhance space exploration, expand our knowledge of the universe, and ensure continued national scientific, technical and economic leadership.

Huntress, Wesley T., Jr.↗
NASA NTRS2011

NASA Risk Management Handbook

The purpose of this handbook is to provide guidance for implementing the Risk Management (RM) requirements of NASA Procedural Requirements (NPR) document NPR 8000.4A, Agency Risk Management Procedural Requirements [1], with a specific focus on programs and projects, and applying to each level of the NASA organizational hierarchy as requirements flow down. This handbook supports RM application within the NASA systems engineering process, and is a complement to the guidance contained in NASA/SP-2007-6105, NASA Systems Engineering Handbook [2]. Specifically, this handbook provides guidance that is applicable to the common technical processes of Technical Risk Management and Decision Analysis established by NPR 7123.1A, NASA Systems Engineering Process and Requirements [3]. These processes are part of the \Systems Engineering Engine. (Figure 1) that is used to drive the development of the system and associated work products to satisfy stakeholder expectations in all mission execution domains, including safety, technical, cost, and schedule. Like NPR 7123.1A, NPR 8000.4A is a discipline-oriented NPR that intersects with product-oriented NPRs such as NPR 7120.5D, NASA Space Flight Program and Project Management Requirements [4]; NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Management Requirements [5]; and NPR 7120.8, NASA Research and Technology Program and Project Management Requirements [6]. In much the same way that the NASA Systems Engineering Handbook is intended to provide guidance on the implementation of NPR 7123.1A, this handbook is intended to provide guidance on the implementation of NPR 8000.4A. 1.2 Scope and Depth This handbook provides guidance for conducting RM in the context of NASA program and project life cycles, which produce derived requirements in accordance with existing systems engineering practices that flow down through the NASA organizational hierarchy. The guidance in this handbook is not meant to be prescriptive. Instead, it is meant to be general enough, and contain a sufficient diversity of examples, to enable the reader to adapt the methods as needed to the particular risk management issues that he or she faces. The handbook highlights major issues to consider when managing programs and projects in the presence of potentially significant uncertainty, so that the user is better able to recognize and avoid pitfalls that might otherwise be experienced.

Dezfuli, Homayoon↗
NASA NTRS2014

A Systems Engineering Approach to Quality Assurance for Aerospace Testing

On the surface, it appears that AS9100 has little to say about how to apply a Quality Management System (QMS) to major aerospace test programs (or even smaller ones). It also appears that there is little in the quality engineering Body of Knowledge (BOK) that applies to testing, unless it is nondestructive examination (NDE), or some type of lab or bench testing associated with the manufacturing process. However, if one examines: a) how the systems engineering (SE) processes are implemented throughout a test program; and b) how these SE processes can be mapped to the requirements of AS9100, a number of areas for involvement of the quality professional are revealed. What often happens is that quality assurance during a test program is limited to inspections of the test article; what could be considered a manufacturing al fresco approach. This limits the quality professional and is a disservice to the programs and projects, since there are a number of ways that quality can enhance critical processes, and support efforts to improve risk reduction, efficiency and effectiveness. The Systems Engineering (SE) discipline is widely used in aerospace to ensure the progress from Stakeholder Expectations (the President, Congress, the taxpayers) to a successful, delivered product or service. Although this is well known, what is not well known is that these same SE processes are implemented in varying complexity, to prepare for and implement test projects that support research, development, verification and validation, qualification, and acceptance test projects. Although the test organization's terminology may vary from the SE terminology, and from one test service provider to another, the basic process is followed by successful, reliable testing organizations. For this analysis, NASA Procedural Requirements (NPR) 7123.1, NASA Systems Engineering Processes and Requirements is used to illustrate the SE processes that are used for major aerospace testing. Many of these processes are also implemented for smaller test projects, and this set of processes will also look familiar to those who have participated in launch site activation and flight demonstrations.

Shepherd, Christena C.↗
NASA NTRS2016

Systems Engineering and Management Applications of ISO 9001:2015 for Government

The manufacturing segment of the business world is busy assessing the impact of ISO 9001:2015, and updating their management systems to meet the required compliance date. What does the new revision mean for government agencies that deliver large engineering projects rather than mass production? In fact, the standard, especially the new revision, can be used quite readily for government agencies, or applied to specific projects, once it is understood in terms of the similarities with systems engineering and project management. From there it can be extrapolated to "mission realization" systems, and a Quality Management System (QMS) is a logical result that can bring order to processes and systems that likely already exist in some fashion. ISO 9001:2015 is less product-oriented than previous versions. It can be more broadly applied to public organizations as well as private; and to services (missions) as well as products. The emphasis on risk management in the revised standard provides the needed balance for weighing decisions with respect to cost, schedule, technical, safety, and regulatory compliance; so if this is not part of agency governance already, this is a good place to start, especially for large engineering projects. The Systems Engineering standard used for this analysis is from NASA's NPR 7123.1 NASA Systems Engineering Processes and Requirements; however, those who are more familiar with ISO/IEC 26702 Systems Engineering-application and management of the systems engineering process, or SAE/EIA 632 Processes for Engineering a System will also recognize the similarities. In reality, the QMS outlined by ISO 9001 reinforces the systems engineering processes, and serves to ensure that they are adequately implemented, although most of the ISO 9001 literature emphasizes the production and process aspects of the standard. Rather than beginning with ISO 9001and getting lost in the vocabulary, it is useful to begin with the systems engineering lifecycle. Identification of stakeholder expectations, identifying solutions, creating specific product or service designs, production of the product or service, delivery to the public, and the associated management, planning, and control processes, are a familiar place to begin thinking of the overall system of identifying, designing, and competing a project or mission. Lining up this lifecycle with the ISO requirements (see Figure 1) illustrates how a quality management system is concerned with the same processes, and provides a governance and assurance function. If implemented properly, there are cost savings resulting from less rework, repair, reprocessing, failures, misplaced documents, and similar types of deficiencies1. Starting with an organization's systems engineering processes allows the organization to use their own terminology for a QMS plan, and tailor the plan to their own project or organization, so that it is more easily developed, understood, and implemented.

Shepherd, Christena C.↗
NASA NTRS2017

Systems Engineering for Space Exploration Medical Capabilities

Human exploration missions to beyond low Earth orbit destinations such as Mars will present significant new challenges to crew health management during a mission compared to current low Earth orbit operations. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element's approach to enabling the necessary autonomy. The Element's work must integrate with the overall exploration mission and vehicle design efforts to successfully provide exploration medical capabilities. ExMC is applying systems engineering principles and practices to accomplish its integrative goals. This paper discusses the structured and integrative approach that is guiding the medical system technical development. Assumptions for the required levels of care on exploration missions, medical system guiding principles, and a Concept of Operations are early products that capture and clarify stakeholder expectations. Mobel-Based Systems Engineering techniques are then applied to define medical system behavior and architecture. Interfaces to other flight and ground systems, and within the medical system are identified and defined. Initial requirements and traceability are established, which sets the stage for identification of future technology development needs. An early approach for verification and validation, taking advantage of terrestrial and near-Earth exploration system analogs, is also defined to further guide system planning and development.

Mindock, Jennifer↗
NASA NTRS2017

Systems Engineering for Space Exploration Medical Capabilities

Human exploration missions that reach destinations beyond low Earth orbit, such as Mars, will present significant new challenges to crew health management. For the medical system, lack of consumable resupply, evacuation opportunities, and real-time ground support are key drivers toward greater autonomy. Recognition of the limited mission and vehicle resources available to carry out exploration missions motivates the Exploration Medical Capability (ExMC) Element's approach to enabling the necessary autonomy. The Element's work must integrate with the overall exploration mission and vehicle design efforts to successfully provide exploration medical capabilities. ExMC is applying systems engineering principles and practices to accomplish its goals. This paper discusses the structured and integrative approach that is guiding the medical system technical development. Assumptions for the required levels of care on exploration missions, medical system goals, and a Concept of Operations are early products that capture and clarify stakeholder expectations. Model-Based Systems Engineering techniques are then applied to define medical system behavior and architecture. Interfaces to other flight and ground systems, and within the medical system are identified and defined. Initial requirements and traceability are established, which sets the stage for identification of future technology development needs. An early approach for verification and validation, taking advantage of terrestrial and near-Earth exploration system analogs, is also defined to further guide system planning and development.

Mindock, Jennifer↗
NASA NTRS2015

The Use of UML for Software Requirements Expression and Management

It is common practice to write English-language "shall" statements to embody detailed software requirements in aerospace software applications. This paper explores the use of the UML language as a replacement for the English language for this purpose. Among the advantages offered by the Unified Modeling Language (UML) is a high degree of clarity and precision in the expression of domain concepts as well as architecture and design. Can this quality of UML be exploited for the definition of software requirements? While expressing logical behavior, interface characteristics, timeliness constraints, and other constraints on software using UML is commonly done and relatively straight-forward, achieving the additional aspects of the expression and management of software requirements that stakeholders expect, especially traceability, is far less so. These other characteristics, concerned with auditing and quality control, include the ability to trace a requirement to a parent requirement (which may well be an English "shall" statement), to trace a requirement to verification activities or scenarios which verify that requirement, and to trace a requirement to elements of the software design which implement that requirement. UML Use Cases, designed for capturing requirements, have not always been satisfactory. Some applications of them simply use the Use Case model element as a repository for English requirement statements. Other applications of Use Cases, in which Use Cases are incorporated into behavioral diagrams that successfully communicate the behaviors and constraints required of the software, do indeed take advantage of UML's clarity, but not in ways that support the traceability features mentioned above. Our approach uses the Stereotype construct of UML to precisely identify elements of UML constructs, especially behaviors such as State Machines and Activities, as requirements, and also to achieve the necessary mapping capabilities. We describe this approach in the context of a space-based software application currently under development at the Jet Propulsion Laboratory.

model-based engineering↗
NASA NTRS2017

Augmenting Space Technology Program Management with Secure Cloud & Mobile Services

The National Aeronautics and Space Administration (NASA) Game Changing Development (GCD) program manages technology projects across all NASA centers and reports to NASA headquarters regularly on progress. Program stakeholders expect an up-to-date, accurate status and often have questions about the program's portfolio that requires a timely response. Historically, reporting, data collection, and analysis were done with manual processes that were inefficient and prone to error. To address these issues, GCD set out to develop a new business automation solution. In doing this, the program wanted to leverage the latest information technology platforms and decided to utilize traditional systems along with new cloud-based web services and gaming technology for a novel and interactive user environment. The team also set out to develop a mobile solution for anytime information access. This paper discusses a solution to these challenging goals and how the GCD team succeeded in developing and deploying such a system. The architecture and approach taken has proven to be effective and robust and can serve as a model for others looking to develop secure interactive mobile business solutions for government or enterprise business automation.

Hodson, Robert F.↗
NASA NTRSDate not supplied

Recommended Crew Systems Capabilities for a 30 to 90 Day Four-Crew Lunar Surface Mission

For any given surface mission duration, there exists a set of surface capabilities necessary to sustain a four-person crew for the length of time the crew is on the surface. Identifying these capabilities is important to mission planners and spacecraft design engineers responsible for lunar surface habitation elements, who need to know which systems and capabilities must be prioritized for the vehicles they are designing. However, simply identifying the surface capabilities does not necessarily equal a viable surface configuration. These capabilities may or may not satisfy stakeholder expectations or even permit completion of mission objectives. Lunar lander cargo mass constraints are a powerful forcing function that requires significant efforts to reduce the mass of all surface elements, including those supporting crew habitation. The required capabilities do increase as a function of mission duration, but it is a nonlinear growth. There are key points in mission duration, beyond which certain additional capabilities are needed. This forms bands of capability between each point. Within a given band, the same functional capabilities are needed, and the only scaling is that associated with daily consumables. The next higher band requires additional capabilities. This paper will focus on those capabilities needed for missions of 30-90 days. It should be noted that there are some uncertainties interpreting NASA requirements that require capabilities after a certain number of days, as typically this refers to number of days in space, not number of days on the lunar surface. Depending on transportation architecture, the number of days between Earth launch and lunar surface landing may vary, therefore impacting when certain required capabilities are implemented. However, activities to prepare humans for missions to Mars and commercial interest in lunar development may drive progressive increases in surface duration. Missions up to 30 days are expected to follow the initial 6.5-day surface missions and there may be commercial interest in extending to even greater durations. This paper will examine the potential case of a 30-90-day surface mission duration with respect to the systems necessary to support crew living and working on the lunar surface.

Habitat↗
NASA NTRS2020

Exploration EVA System Concept of Operations

The Exploration Extravehicular Activity (xEVA) System concept of operations (con ops) captures the National Aeronautics and Space Administration’s (NASA’s) current aims future missions to all potential Exploration destinations. This document captures the mission architectures, stakeholder expectations, and high level definitions of the capabilities and interfaces associated with the xEVA System. This includes missions to Gateway in cislunar space, the lunar surface, a redirected asteroid in cislunar space, Near Earth Asteroids (NEA), Mars’ orbit, the moons of Mars (Phobos and Deimos), and the surface of Mars. These missions, which include microgravity, milli-gravity, and partial-gravity surface EVAs, will involve a variety of engineering (maintenance, contingency, pioneering, construction) and science tasks. This document also captures information concerning vehicles and habitats with which the xEVA System will interface. The concepts of operations (con ops) detailed in this document are informed by the Artemis Program and a multitude of Exploration studies, and are also influenced by various integrated operational analog testing.

David Coan↗
NASA NTRS2018

Using Board Games as Subject Matter for Developing Expertise in Model-Based Systems Engineering

As more organizations transition from traditional document-centric systems engineering to a model-based approach, many are challenged to train their staff in new languages, tools, and methodologies, while managing the expectations of stakeholders and their expected model outcomes. In particular, challenges associated with learning a new modeling language and developing skills in the 'art' of modeling present organizations with formidable obstacles to realizing this transition. This paper hypothesizes that systems engineers may more readily learn how to correctly model with SysML, and develop intuition about the art of modeling and using patterns, if their learning references a commonly and thoroughly-understood subject, such as a board game. This paper presents a case for the use of board games as subject matter for new modelers. It demonstrates the concept with a sample model of Hasbro's popular board game, Monopoly, and discusses the limitations of this approach and potential adaptations that may broaden the applicability of the learned skills to projects. Finally, results from a small feasibility assessment and concepts for more formal study to evaluate the hypothesis are presented.

Model-Based Systems Engineering↗
NASA NTRS2018

Using Board Games as Subject Matter for Developing Expertise in Model-Based Systems Engineering

As more organizations transition from traditional document-centric systems engineering to a model-based approach, many are challenged to train their staff in new languages, tools, and methodologies, and manage the expectations of stakeholders and their expected model outcomes. In particular, challenges associated with learning a new modeling language and developing skills in the 'art' of modeling present organizations with formidable obstacles to realizing this transition. This paper hypothesizes that systems engineers may more readily learn how to correctly model with SysML, and develop intuition about the art of modeling and using patterns, if their learning references a commonly and thoroughly-understood subject matter, such as a board game. This paper presents a case for the use of board games as subject matter for new modelers, demonstrates the concept with a sample model of Hasbro's popular board game, Monopoly, and discusses the limitations of this approach and potential adaptations that may broaden the applicability of the learned skills to projects.

Systems Engineering↗
NASA NTRS2005

Communicating Risk to Program Managers

Program Managers (PM) can protect program resources and improve chances of success by anticipating, understanding and managing risks. Understanding the range of potential risks helps one to avoid or manage the risks. A PM must choose which risks to accept to reduce fire fighting, must meet the expectations of stakeholders consistently, and avoid falling into costly "black holes" that may open. A good risk management process provides the PM more confidence to seize opportunities save money, meet schedule, even improve relationships with people important to the program. Evidence of managing risk and sound internal controls can mean better support from superiors for the program by building a trust and reputation from being on top of issues. Risk managers have an obligation to provide the PM with the best information possible to allow the benefits to be realized (Small Business Consortium, 2004). The Institute for Chartered Accountants in England and Wales sees very important benefits for companies in providing better information about what they do to assess and manage key business risks. Such information will: a) provide practical forward-looking information; b) reduce the cost of capital; c) encourage better risk management; and d) improve accountability for stewardship, investor protection and the usefulness of financial reporting. We are particularly convinced that enhanced risk reporting will help listed companies obtain capital at the lowest possible cost (The Institute of Chartered Accountants in England &Wales, June 2002). Risk managers can take a significant role in quantifying the success of their department and communicating those figures to executive (program) management levels while pushing for a broader risk management role. Overall, risk managers must show that risk management work matters in the most crucial place-the bottom line- as they prove risk management can be a profit center (Sullivan, 2004).

Shivers, C. Herbert↗
NASA NTRS2019

The Value of Being a Trustworthy Repository

Today, NASA's Earth Observing System Data and Information System (EOSDIS), a system ofactive archives is attaching the CoreTrustSeal to its websites signifying that it merits theconfidence of its user community. But what value does being a trustworthy repository impart to auser? What does it mean to the owners and operators of repositories? What will it mean in thefuture? EOSDIS was started in the 1990s based on a framework of discipline-oriented, geographicallydistributed centers of expertise, named Distributed Active Archive Centers (DAACs). The functionof EOSDIS is to collect Earth Science data sensor measurements (principally those created andneeded by NASA) and manage the data and many derived digital products. EOSDIS providesmany services, including processing, curating, documenting, disseminating, and enabling datadiscovery as well as efficient use of the data. The EOSDIS has been operational over 25 years andmany lessons have been learned relative to the TRUST principles. During the tenure of EOSDIS,many changes have occurred as we have increased the size of the collection from gigabytes totens of petabytes and the distribution of the data to millions of users. We have had severalstages of system evolution that have improved EOSDIS in order to meet both stakeholder andcustomer expectations. This type of evolution is an on-going process to ensure that ourrepositories remain trustworthy. It is also important that our own community of data managersand system engineers add value in being trustworthy. This paper will discuss approaches to change within a large system of Earth Science data and services, while remaining a trustworthyrepository.

Behnke, Jeanne↗
NASA NTRSDate not supplied

Arc Jet Testing of 3D Mid-Density Carbon Phenolic (3MDCP) for Mars Sample Return

When accounting for the highest-heating trajectory with margin, dispersion, and greatest system mass, MSR-EES is predicted to experience the highest heat flux and pressure (approximately 3300 W/cm2 hot-wall, 200 kPa) of any earth entry vehicle todate. To verify performance requirements are met by the forebody TPS, the material must be tested to validate model predictions and give confidence to stakeholder’s expectation of performance. 3D Mid-Density Carbon Phenolic (3MDCP) is NASA’s baseline material for the forebody heatshield of the MSR-EES. As part of the arc jet campaign to evaluate material performance, recent testing has completed in the Interaction Heating Facility (IHF) using a new facility setting to achieve the necessary environments.

arcjet↗