Search NASA⌕ Search

SEARCH · Search NASA

Results for “scope”

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 145 records · Page 8
All sourcesNASA NTRSDOE OSTI
NASA NTRS2006

Manned Spacecraft Requirements for Materials and Processes

A major cause of project failure can be attributed to an emphasized focus on end products and inadequate attention to resolving development risks during the initial phases of a project. The initial phases of a project, which we will call the "study period", are critical to determining project scope and costs, and can make or break most projects. If the requirements are not defined adequately, how can the scope be adequately determined, also how can the costs of the entire project be effectively estimated, and how can the risk of project success be accurately assessed? Using the proper material specifications and standards and incorporating these specifications and standards in the design process should be considered inherently crucial to the technical success of a project as just as importantly, crucial to the cost and schedule success. This paper will intertwine several important aspects or considerations for project success: 1) Characteristics of a "Good Material Requirement"; 2) Linking material requirements to the implementation of "Design for Manufacturing"; techniques and 3) The importance of decomposing materials requirements during the study phase/development phase to mitigate project risk for the maturation of technologies before the building of hardware.

Vaughn, Timothy P.↗
NASA NTRS2004

"GSFC FSB Application of Perspective-Based Inspections"

The scope of work described in our proposal consisted of developing inspection standards targeted to Branch-specific types of defects (gained from analysis of Branch project defect histories), and including Branch-relevant perspectives and questions to guide defect detection. The tailored inspection guidelines were to be applied on real Branch projects with support as needed from the technology infusion team. This still accurately describes the scope of work performed. It was originally proposed that the Perspective-Based inspection standard would be applied on three projects within the Branch: GPM, JWST, and SDO. Rather than apply the proposed standard to all three, we inserted a new step, in which the standard was instead applied on a single pilot project, cFE (described above). This decision was a good match for the Branch goals since, due to the "design for reuse" nature of cFE, inspections played an even more crucial than usual role in that development process. Also, since cFE is being designed to provide general-purpose functionality, key representatives fiom our target projects were involved in inspections of cFE to provide perspectives from different missions. In this way, they could get some exposure to and the chance to provide feedback on the proposed standards before applying them on their own projects. The Branch-baselined standards will still be applied on GPM, JWST, and SDO, although outside the time frame of this funding. Finally, we originally proposed using the analysis of Branch defect sources to indicate in which phases Perspective-Based inspections could provide the best potential for future improvement, although experience on previous Branch projects suggested that our efforts would likely be focused on requirements and code inspections. In the actual work, we focused exclusively on requirements inspections, as this was the highest-priority work currently being done on our cFE pilot project.

Shell, Elaine↗
NASA NTRS2006

Fracture Control Requirements for Composite and Bonded Vehicle and Payload Structures

The document presents a minimum set of fracture control requirements to be used across MSFC programs in designing and assessing composite and bonded structures. The scope includes manned launch, retrieval, transfer, and landing vehicles, space habitats, and payloads or experiments that are launched, retrieved, stored, or operated during any portion of a manned spaceflight mission. It is applicable to in-house and contract activities. The requirements apply to fiber reinforced polymer matrix composites, sandwich construction (bonded metallic and nonmetallic), and bonds between metallic or composite parts fall within the scope of this document.

McGill, Preston↗
NASA NTRS2007

Abort Flight Test Project Overview

A general overview of the Orion abort flight test is presented. The contents include: 1) Abort Flight Test Project Overview; 2) DFRC Exploration Mission Directorate; 3) Abort Flight Test; 4) Flight Test Configurations; 5) Flight Test Vehicle Engineering Office; 6) DFRC FTA Scope; 7) Flight Test Operations; 8) DFRC Ops Support; 9) Launch Facilities; and 10) Scope of Launch Abort Flight Test

Sitz, Joel↗
NASA NTRS2006

Advancing the practice of systems engineering at JPL

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the Systems Engineering Advancement (SEA) Project in order to "significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks." The scope of the SEA Project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1. the full life-cycle, i.e., concept through end of operations 2. the full depth, i.e., Program, Project, System, Subsystem, Element (SE Levels 1 to 5) 3. the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management, They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA Project is developing products, services, and training to support managers and practitioners throughout the entire system lifecycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA Project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA Project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper'3 describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

process improvement↗
NASA NTRS2008

International Space Station Human Behavior and Performance Competency Model: Volume I

This document defines Human Behavior and Performance (HBP) competencies that are recommended to be included as requirements to participate in international long duration missions. They were developed in response to the Multilateral Crew Operations Panel (MMOP) request to develop HBP training requirements for the International Space Station (ISS). The competency model presented here was developed by the ITCB HBPT WG and forms the basis for determining the HBP training curriculum for long duration crewmembers. This document lists specific HBP competencies and behaviors required of astronauts/cosmonauts who participate in ISS expedition and other international longduration missions. Please note that this model does not encompass all competencies required. For example, outside the scope of this document are cognitive skills and abilities, including but not limited to concentration, memorization, perception, imagination, and thinking. It is assumed that these skills, which are crucial in terms of human behavior and performance, are considered during selection phase since such professionally significant qualities of the operator should be taken into consideration in order to ensure sufficient baseline levels that can be further improved during general astronaut training. Also, technical competencies, even though critical for crewmembers, are beyond the scope of this document. It should also be noted that the competencies in this model (and subsequent objectives) are not intended to limit the internal activities or training programs of any international partner.

Schmidt, Lacey↗
NASA NTRS2008

NASA's In Space Propulsion Technology Program Accomplishments and Lessons Learned

NASA's In-Space Propulsion Technology (ISPT) Program was managed for 5 years at the NASA MSFC and significant strides were made in the advancement of key transportation technologies that will enable or enhance future robotic science and deep space exploration missions. At the program's inception, a set of technology investment priorities were established using an NASA-wide, mission-driven prioritization process and, for the most part, these priorities changed little - thus allowing a consistent framework in which to fund and manage technology development. Technologies in the portfolio included aerocapture, advanced chemical propulsion, solar electric propulsion, solar sail propulsion, electrodynamic and momentum transfer tethers, and various very advanced propulsion technologies with significantly lower technology readiness. The program invested in technologies that have the potential to revolutionize the robotic exploration of deep space. For robotic exploration and science missions, increased efficiencies of future propulsion systems are critical to reduce overall life-cycle costs and, in some cases, enable missions previously considered impossible. Continued reliance on conventional chemical propulsion alone will not enable the robust exploration of deep space - the maximum theoretical efficiencies have almost been reached and they are insufficient to meet needs for many ambitious science missions currently being considered. By developing the capability to support mid-term robotic mission needs, the program was to lay the technological foundation for travel to nearby interstellar space. The ambitious goals of the program at its inception included supporting the development of technologies that could support all of NASA's missions, both human and robotic. As time went on and budgets were never as high as planned, the scope of the program was reduced almost every year, forcing the elimination of not only the broader goals of the initial program, but also of funding for over half of the technologies in the original portfolio. In addition, the frequency at which the application requirements for the program changed exceeded the development time required to mature technologies: forcing sometimes radical rescoping of research efforts already halfway (or more) to completion. At the end of its fifth year, both the scope and funding of the program were at a minimum despite the program successfully meeting all of it's initial high priority objectives. This paper will describe the program, its requirements, technology portfolio, and technology maturation processes. Also discussed will be the major technology milestones achieved and the lessons learned from managing a $100M+ technology program.

Johnson, Les C.↗
NASA NTRS2010

2009 Space Shuttle Probabilistic Risk Assessment Overview

Loss of a Space Shuttle during flight has severe consequences, including loss of a significant national asset; loss of national confidence and pride; and, most importantly, loss of human life. The Shuttle Probabilistic Risk Assessment (SPRA) is used to identify risk contributors and their significance; thus, assisting management in determining how to reduce risk. In 2006, an overview of the SPRA Iteration 2.1 was presented at PSAM 8 [1]. Like all successful PRAs, the SPRA is a living PRA and has undergone revisions since PSAM 8. The latest revision to the SPRA is Iteration 3. 1, and it will not be the last as the Shuttle program progresses and more is learned. This paper discusses the SPRA scope, overall methodology, and results, as well as provides risk insights. The scope, assumptions, uncertainties, and limitations of this assessment provide risk-informed perspective to aid management s decision-making process. In addition, this paper compares the Iteration 3.1 analysis and results to the Iteration 2.1 analysis and results presented at PSAM 8.

Hamlin, Teri L.↗
NASA NTRS2011

US Spacesuit Knowledge Capture

The ability to learn from both the mistakes and successes of the past is vital to assuring success in the future. Due to the close physical interaction between spacesuit systems and human beings as users, spacesuit technology and usage lends itself rather uniquely to the benefits realized from the skillful organization of historical information; its dissemination; the collection and identification of artifacts; and the education of those in the field. The National Aeronautics and Space Administration (NASA), other organizations and individuals have been performing United States (U.S.) Spacesuit Knowledge Capture since the beginning of space exploration. Avenues used to capture the knowledge have included publication of reports; conference presentations; specialized seminars; and classes usually given by veterans in the field. More recently the effort has been more concentrated and formalized whereby a new avenue of spacesuit knowledge capture has been added to the archives in which videotaping occurs engaging both current and retired specialists in the field presenting technical scope specifically for education and preservation of knowledge. With video archiving, all these avenues of learning can now be brought to life with the real experts presenting their wealth of knowledge on screen for future learners to enjoy. Scope and topics of U.S. spacesuit knowledge capture have included lessons learned in spacesuit technology, experience from the Gemini, Apollo, Skylab and Shuttle programs, hardware certification, design, development and other program components, spacesuit evolution and experience, failure analysis and resolution, and aspects of program management. Concurrently, U.S. spacesuit knowledge capture activities have progressed to a level where NASA, the National Air and Space Museum (NASM), Hamilton Sundstrand (HS) and the spacesuit community are now working together to provide a comprehensive closed-looped spacesuit knowledge capture system which includes

Chullen, Cinda↗
NASA NTRS2010

Modeling Flight: The Role of Dynamically Scaled Free-Flight Models in Support of NASA's Aerospace Programs

The state of the art in aeronautical engineering has been continually accelerated by the development of advanced analysis and design tools. Used in the early design stages for aircraft and spacecraft, these methods have provided a fundamental understanding of physical phenomena and enabled designers to predict and analyze critical characteristics of new vehicles, including the capability to control or modify unsatisfactory behavior. For example, the relatively recent emergence and routine use of extremely powerful digital computer hardware and software has had a major impact on design capabilities and procedures. Sophisticated new airflow measurement and visualization systems permit the analyst to conduct micro- and macro-studies of properties within flow fields on and off the surfaces of models in advanced wind tunnels. Trade studies of the most efficient geometrical shapes for aircraft can be conducted with blazing speed within a broad scope of integrated technical disciplines, and the use of sophisticated piloted simulators in the vehicle development process permits the most important segment of operations the human pilot to make early assessments of the acceptability of the vehicle for its intended mission. Knowledgeable applications of these tools of the trade dramatically reduce risk and redesign, and increase the marketability and safety of new aerospace vehicles. Arguably, one of the more viable and valuable design tools since the advent of flight has been testing of subscale models. As used herein, the term "model" refers to a physical article used in experimental analyses of a larger full-scale vehicle. The reader is probably aware that many other forms of mathematical and computer-based models are also used in aerospace design; however, such topics are beyond the intended scope of this document. Model aircraft have always been a source of fascination, inspiration, and recreation for humans since the earliest days of flight. Within the scientific community, Leonardo da Vinci, George Cayley, and the Wright brothers are examples of early aviation pioneers who frequently used models during their scientific efforts to understand and develop flying machines. Progress in the technology associated with model testing in worldwide applications has firmly established model aircraft as a key element in new aerospace research and development programs. Models are now routinely used in many applications and roles, including aerodynamic data gathering in wind tunnel investigations for the analysis of full-scale aircraft designs, proof-of-concept demonstrators for radical aeronautical concepts, and problem-solving exercises for vehicles already in production. The most critical contributions of aerospace models are to provide confidence and risk reduction for new designs and to enhance the safety and efficiency of existing configurations.

Chambers, Joseph↗
NASA NTRS2011

Using Distributed Operations to Enable Science Research on the International Space Station

In the early days of the International Space Station (ISS) program, and as the organization structure was being internationally agreed upon and documented, one of the principal tenets of the science program was to allow customer-friendly operations. One important aspect of this was to allow payload developers and principle investigators the flexibility to operate their experiments from either their home sites or distributed telescience centers. This telescience concept was developed such that investigators had several options for ISS utilization support. They could operate from their home site, the closest telescience center, or use the payload operations facilities at the Marshall Space Flight Center in Huntsville, Alabama. The Payload Operations Integration Center (POIC) processes and structures were put into place to allow these different options to its customers, while at the same time maintain its centralized authority over NASA payload operations and integration. For a long duration space program with many scientists, researchers, and universities expected to participate, it was imperative that the program structure be in place to successfully facilitate this concept of telescience support. From a payload control center perspective, payload science operations require two major elements in order to make telescience successful within the scope of the ISS program. The first element is decentralized control which allows the remote participants the freedom and flexibility to operate their payloads within their scope of authority. The second element is a strong ground infrastructure, which includes voice communications, video, telemetry, and commanding between the POIC and the payload remote site. Both of these elements are important to telescience success, and both must be balanced by the ISS program s documented requirements for POIC to maintain its authority as an integration and control center. This paper describes both elements of distributed payload operations and discusses the benefits and drawbacks.

Bathew, Ann S.↗
NASA NTRS2004

RAT Requisition Approval Team - A L6S Initiative

L6S Project Description - Problem: The current cycle time for generating and approving Requisitions does not meet "Best-In-Class." . Scope: Only looking at the Florida Requisition Approval process for Orbiter (ORBF & ORBG) and Ground (GFAC) stocked items. This includes the time from when a requirement is generated by Logistics Planning and Supportability in Florida until it is approved and received by Procurement. Requisitions generated at other sites or for non stocked items will be out of scope of this Project

Hall, Valerie↗
NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014. The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such a comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass, ground operations can still reduce mission costs through smaller staffing of operators and limiting their working hours. The challenge, then, for the SMAP GDS engineering team, is to formulate an automated operations strategy--and corresponding system architecture -- to minimize operator intervention during routine operations, while balancing the development costs associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS -- NASA's AMMOS Mission Data Processing and Control System (AMPCS) -- provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

soil moisture↗
NASA NTRS2012

Cost-Effective Telemetry and Command Ground Systems Automation Strategy for the Soil Moisture Active Passive (SMAP) Mission

Soil Moisture Active Passive (SMAP) is an Earth-orbiting, remote-sensing NASA mission slated for launch in 2014.[double dagger] The ground data system (GDS) being developed for SMAP is composed of many heterogeneous subsystems, ranging from those that support planning and sequencing to those used for real-time operations, and even further to those that enable science data exchange. A full end-to-end automation of the GDS may result in cost savings during mission operations, but it would require a significant upfront investment to develop such comprehensive automation. As demonstrated by the Jason-1 and Wide-field Infrared Survey Explorer (WISE) missions, a measure of "lights-out" automation for routine, orbital pass ground operations can still reduce mission cost through smaller staffing of operators and limited work hours. The challenge, then, for the SMAP GDS engineering team is to formulate an automated operations strategy--and corresponding system architecture--to minimize operator intervention during operations, while balancing the development cost associated with the scope and complexity of automation. This paper discusses the automated operations approach being developed for the SMAP GDS. The focus is on automating the activities involved in routine passes, which limits the scope to real-time operations. A key subsystem of the SMAP GDS--NASA's AMMOS Mission Data Processing and Control System (AMPCS)--provides a set of capabilities that enable such automation. Also discussed are the lights-out pass automations of the Jason-1 and WISE missions and how they informed the automation strategy for SMAP. The paper aims to provide insights into what is necessary in automating the GDS operations for Earth satellite missions.

remote-sensing↗
NASA NTRS2013

A Wind-powered Rover for a Low-Cost Venus Mission

Venus, with a surface temperature of 450 C and an atmospheric pressure 90 times higher than that of the Earth, is a difficult target for exploration. However, high-temperature electronics and power systems now being developed make it possible that future missions may be able to operate in the Venus environment. Powering such a rover within the scope of a Discovery class mission will be difficult, but harnessing Venus' surface winds provides a possible way to keep a powered rover small and light. This project scopes out the feasibility of a wind-powered rover for Venus surface missions. Two rover concepts, a land-sailing rover and a wind-turbine-powered rover, were considered. The turbine-powered rover design is selected as being a low-risk and low-cost strategy. Turbine detailed analysis and design shows that the turbine can meet mission requirements across the desired range of wind speeds by utilizing three constant voltage generators at fixed gear ratios.

Benigno, Gina↗
NASA NTRS2013

NASA Software Engineering Benchmarking Study

To identify best practices for the improvement of software engineering on projects, NASA's Offices of Chief Engineer (OCE) and Safety and Mission Assurance (OSMA) formed a team led by Heather Rarick and Sally Godfrey to conduct this benchmarking study. The primary goals of the study are to identify best practices that: Improve the management and technical development of software intensive systems; Have a track record of successful deployment by aerospace industries, universities [including research and development (R&D) laboratories], and defense services, as well as NASA's own component Centers; and Identify candidate solutions for NASA's software issues. Beginning in the late fall of 2010, focus topics were chosen and interview questions were developed, based on the NASA top software challenges. Between February 2011 and November 2011, the Benchmark Team interviewed a total of 18 organizations, consisting of five NASA Centers, five industry organizations, four defense services organizations, and four university or university R and D laboratory organizations. A software assurance representative also participated in each of the interviews to focus on assurance and software safety best practices. Interviewees provided a wealth of information on each topic area that included: software policy, software acquisition, software assurance, testing, training, maintaining rigor in small projects, metrics, and use of the Capability Maturity Model Integration (CMMI) framework, as well as a number of special topics that came up in the discussions. NASA's software engineering practices compared favorably with the external organizations in most benchmark areas, but in every topic, there were ways in which NASA could improve its practices. Compared to defense services organizations and some of the industry organizations, one of NASA's notable weaknesses involved communication with contractors regarding its policies and requirements for acquired software. One of NASA's strengths was its software assurance practices, which seemed to rate well in comparison to the other organizational groups and also seemed to include a larger scope of activities. An unexpected benefit of the software benchmarking study was the identification of many opportunities for collaboration in areas including metrics, training, sharing of CMMI experiences and resources such as instructors and CMMI Lead Appraisers, and even sharing of assets such as documented processes. A further unexpected benefit of the study was the feedback on NASA practices that was received from some of the organizations interviewed. From that feedback, other potential areas where NASA could improve were highlighted, such as accuracy of software cost estimation and budgetary practices. The detailed report contains discussion of the practices noted in each of the topic areas, as well as a summary of observations and recommendations from each of the topic areas. The resulting 24 recommendations from the topic areas were then consolidated to eliminate duplication and culled into a set of 14 suggested actionable recommendations. This final set of actionable recommendations, listed below, are items that can be implemented to improve NASA's software engineering practices and to help address many of the items that were listed in the NASA top software engineering issues. 1. Develop and implement standard contract language for software procurements. 2. Advance accurate and trusted software cost estimates for both procured and in-house software and improve the capture of actual cost data to facilitate further improvements. 3. Establish a consistent set of objectives and expectations, specifically types of metrics at the Agency level, so key trends and models can be identified and used to continuously improve software processes and each software development effort. 4. Maintain the CMMI Maturity Level requirement for critical NASA projects and use CMMI to measure organizations developing software for NASA. 5.onsolidate, collect and, if needed, develop common processes principles and other assets across the Agency in order to provide more consistency in software development and acquisition practices and to reduce the overall cost of maintaining or increasing current NASA CMMI maturity levels. 6. Provide additional support for small projects that includes: (a) guidance for appropriate tailoring of requirements for small projects, (b) availability of suitable tools, including support tool set-up and training, and (c) training for small project personnel, assurance personnel and technical authorities on the acceptable options for tailoring requirements and performing assurance on small projects. 7. Develop software training classes for the more experienced software engineers using on-line training, videos, or small separate modules of training that can be accommodated as needed throughout a project. 8. Create guidelines to structure non-classroom training opportunities such as mentoring, peer reviews, lessons learned sessions, and on-the-job training. 9. Develop a set of predictive software defect data and a process for assessing software testing metric data against it. 10. Assess Agency-wide licenses for commonly used software tools. 11. Fill the knowledge gap in common software engineering practices for new hires and co-ops.12. Work through the Science, Technology, Engineering and Mathematics (STEM) program with universities in strengthening education in the use of common software engineering practices and standards. 13. Follow up this benchmark study with a deeper look into what both internal and external organizations perceive as the scope of software assurance, the value they expect to obtain from it, and the shortcomings they experience in the current practice. 14. Continue interactions with external software engineering environment through collaborations, knowledge sharing, and benchmarking.

Rarick, Heather L.↗
NASA NTRS2012

U.S. Spacesuit Knowledge Capture Series Catalog

The National Aeronautics and Space Administration (NASA) and other organizations have been performing U.S. Spacesuit Knowledge Capture (USSKC) since the beginning of space exploration through published reports, conference presentations, specialized seminars, and classes instructed by veterans in the field. The close physical interaction between spacesuit systems and human beings makes them among the most personally evocative pieces of space hardware. Consequently, spacesuit systems have required nearly constant engineering refinements to do their jobs without impinging on human activity. Since 2008, spacesuit knowledge capture has occurred through video recording, engaging both current and former specialists presenting technical scope specifically to educate individuals and preserve knowledge. These archives of spacesuit legacy reflect its rich history and will provide knowledge that will enhance the chances for the success of future and more ambitious spacesuit system programs. The scope and topics of USSKC have included lessons learned in spacesuit technology; experience from the Gemini, Apollo, Skylab, and Shuttle Programs; the process of hardware certification, design, development, and other program components; spacesuit evolution and experience; failure analysis and resolution; and aspects of program management. USSKC activities have progressed to a level where NASA, the National Air and Space Museum (NASM), Hamilton Sundstrand (HS) and the spacesuit community are now working together to provide a comprehensive way to organize and archive intra-agency information related to the development of spacesuit systems. These video recordings are currently being reviewed for public release using NASA export control processes. After a decision is made for either public or non-public release (internal NASA only), the videos and presentations will be available through the NASA Johnson Space Center Engineering Directorate (EA) Engineering Academy, the NASA Technical Reports Server (NTRS), the NASA Aeronautics & Space Database (NA&SD), or NASA YouTube. Event availability is duly noted in this catalog.

Bitterly, Rose↗
NASA NTRS2013

Consolidated Development Objectives Document (CDOD) For MB-60

This document defines the objectives related to liquid rocket engine system development to be undertaken by JAXA in support of the Space Launch System (SLS) Program managed out of the NASA Marshall Space Flight Center (MSFC). These objectives include furnishing the necessary management, labor, facilities, tools, equipment, and materials required to execute the specified activities. 1.1 Project Scope: The scope of this effort is to develop a rocket engine and associated products per the objectives and technical requirements established in this document. This engine, minus the engine controller, designated here as MB ]60, is to be developed through to a prequalification point of maturity. It is assumed that should JCNE ]1 development proceed beyond this maturity point towards actual flight qualification, the engine controller will be supplied and integrated by NASA. 1.2 Document Structure: The structure of this Consolidated Development Objectives Document (CDOD) includes a traditional description of objectives in a SOO, plus the associated Data Products Document (DPD) in an attached appendix, and then Engine Requirements Document (ERD) as another attached appendix. It is the intent that this document, in conjunction with the cited applicable documents, should constitute a complete programmatic and technical description of the development effort to be pursued.

Greene, William D.↗