Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “NASA Process Requirements”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
NASA NTRS2016

Expanded Guidance for NASA Systems Engineering. Volume 2: Crosscutting Topics, Special Topics, and Appendices

Historically, most successful NASA projects have depended on effectively blending project management, systems engineering, and technical expertise among NASA, contractors, and third parties. Underlying these successes are a variety of agreements (e.g., contract, memorandum of understanding, grant, cooperative agreement) between NASA organizations or between NASA and other Government agencies, Government organizations, companies, universities, research laboratories, and so on. To simplify the discussions, the term "contract" is used to encompass these agreements. This section focuses on the NASA systems engineering activities pertinent to awarding a contract, managing contract performance, and completing a contract. In particular, NASA systems engineering interfaces to the procurement process are covered, since the NASA engineering technical team plays a key role in the development and evaluation of contract documentation. Contractors and third parties perform activities that supplement (or substitute for) the NASA project technical team accomplishment of the NASA common systems engineering technical process activities and requirements outlined in this guide. Since contractors might be involved in any part of the systems engineering life cycle, the NASA project technical team needs to know how to prepare for, allocate or perform, and implement surveillance of technical activities that are allocated to contractors.

Steven R Hirshorn↗
NASA NTRS2017

Refining the GPS Space Service Volume (SSV) and Building a Multi-GNSS SSV

The GPS (Global Positioning System) Space Service Volume (SSV) was first defined to protect the GPS main lobe signals from changes from block to block. First developed as a concept by NASA in 2000, it has been adopted for the GPS III block of satellites, and is being used well beyond the current specification to enable increased navigation performance for key missions like GOES-R. NASA has engaged the US IFOR (Interagency Forum Operational Requirements) process to adopt a revised requirement to protect this increased and emerging use. Also, NASA is working through the UN International Committee on GNSS (Global Navigation Satellite System) to develop an interoperable multi-GNSS SSV in partnership with all of the foreign GNSS providers.

Parker, Joel J. K.↗
NASA NTRS2014

Application of Fault Management Theory to the Quantitive Selection of a Launch Vehicle Abort Trigger Suite

SHM/FM theory has been successfully applied to the selection of the baseline set Abort Triggers for the NASA SLS center dot Quantitative assessment played a useful role in the decision process  M&FM, which is new within NASA MSFC, required the most "new" work, as this quantitative analysis had never been done before center dot Required development of the methodology and tool to mechanize the process center dot Established new relationships to the other groups  The process is now an accepted part of the SLS design process, and will likely be applied to similar programs in the future at NASA MSFC  Future improvements center dot Improve technical accuracy ‒Differentiate crew survivability due to an abort, vs. survivability even no immediate abort occurs (small explosion with little debris) ‒Account for contingent dependence of secondary triggers on primary triggers ‒Allocate "Δ LOC Benefit" of each trigger when added to the previously selected triggers. center dot Reduce future costs through the development of a specialized tool  Methodology can be applied to any manned/unmanned vehicle, in space or terrestrial

Lo, Yunnhon↗
NASA NTRS1993

HP upgrade operational streamlining

New computer technology and resources must be successfully integrated into CDSLR station operations to manage new complex operational tracking requirements, support the on site production of new data products, support ongoing station performance improvements, and to support new station communication requirements. The NASA CDSLR Network is in the process of upgrading station computer resources with HP UNIX workstations, designed to automate a wide range of operational station requirements. The primary HP upgrade objective was to relocate computer intensive data system tasks from the controller computer to a new advanced computer environment designed to meet the new data system requirements. The HP UNIX environment supports fully automated real time data communications, data management, data processing, and data quality control. Automated data compression procedures are used to improve the efficiency of station data communications. In addition, the UNIX environment supports a number of semi-automated technical and administrative operational station tasks. The x window user interface generates multiple simultaneous color graphics displays, providing direct operator visibility and control over a wide range of operational station functions.

Edge, David R.↗
NASA NTRSDate not supplied

Adopting an Objectives-Driven Assurance Case Approach for Achieving Space Flight Mission Planetary Protection Objectives

Traditionally, NASA has utilized prescriptive technical and process requirements to ensure safety and mission assurance performance objectives for space flight missions are achieved. While prescriptive re-quirements may be easier to communicate and manage throughout the systems engineering process, the highly-constrained nature of prescriptive requirements can limit the ability to take advantage of cost-saving opportunities and offer limited ability to explore other options or alternative designs, processes, and methods. It can also be difficult to develop prescriptive requirements for objectives that are prob-abilistic in nature or that cannot be satisfied by direct verification. In contrast, the development of an assurance case allows for a compelling, comprehensible, and valid argument to be developed with support-ing evidence that shows safety and mission assurance objectives have been satisfied. Analogous to how patent applications are constructed for inventions, an assurance case has a high-level claim of meeting a safety and mission assurance objective, followed by a more specific set of sub-claims and technical evidence which supports the claims. The objectives-driven assurance case approach allows for a better understand-ing and exploration of the trade space, more flexibility to balance trades, and the ability to realize and implement technical and process innovations for resource, time, and cost savings. The assurance case is a living case that evolves over the entire program life cycle. Recently, NASA’s Office of Planetary Pro-tection (OPP) has adopted the assurance case approach as an acceptable methodology for demonstrating avoidance of contamination of target solar system bodies explored by NASA space flight missions. This methodology has been incorporated into NASA’s new technical standard for planetary protection and is currently being utilized by the Mars Sample Return campaign for safe sample containment during sample return. This presentation will explore the development and implementation of an assurance case approach in the context of planetary protection, the shift from prescriptive requirements and the ongoing culture change in the technical community, and the support and guidance from NASA’s OPP in adopting the assurance case approach for achieving planetary protection objectives on NASA’s space flight missions.

Elaine Seasly↗
NASA NTRSDate not supplied

Adopting an Objectives-Driven Assurance Case Approach for Achieving Space Flight Mission Planetary Protection Objectives

Traditionally, the National Aeronautics and Space Administration (NASA) has utilized prescriptive technical and process requirements to ensure safety and mission assurance performance objectives for planetary protection are achieved during space flight missions. While prescriptive requirements may be easier to communicate and manage throughout the systems engineering process, the highly constrained nature of prescriptive requirements can limit the ability to take advantage of cost-saving opportunities and offer limited ability to explore other options or alternative designs, processes, and methods. It can also be difficult to develop prescriptive requirements for objectives that are probabilistic in nature or that cannot be satisfied by direct verification. In contrast, the development of an assurance case allows for a compelling, comprehensible, and valid argument to be developed with supporting evidence that shows safety and mission assurance objectives have been satisfied. Analogous to how patent applications are constructed for inventions, an assurance case has a high-level claim of meeting a safety and mission assurance objective, followed by a more specific set of sub-claims and technical evidence which supports the claims. The objectives-driven assurance case approach allows for a better understanding and exploration of the trade space, more flexibility to balance trades, and the ability to realize and implement technical and process innovations for resource, time, and cost savings. The assurance case is a living case that evolves over the entire program life cycle. Recently, NASA’s Office of Planetary Protection (OPP) has adopted the assurance case approach as an acceptable methodology for demonstrating avoidance of contamination of target solar system bodies explored by NASA space flight missions. This methodology has been incorporated into NASA’s new technical standard for planetary protection and is currently being utilized by the Mars Sample Return campaign for safe sample containment during sample return.

Assurance Case↗
NASA NTRS2011

ELaNa - Educational Launch of Nanosatellite Enhance Education Through Space Flight

One of NASA's missions is to attract and retain students in the science, technology, engineering and mathematics (STEM) disciplines. Creating missions or programs to achieve this important goal helps strengthen NASA and the nation's future work force as well as engage and inspire Americans and the rest of the world. During the last three years, in an attempt to revitalize educational space flight, NASA generated a new and exciting initiative. This initiative, NASA's Educational Launch of Nanosatellite (ELaNa), is now fully operational and producing exciting results. Nanosatellites are small secondary satellite payloads called CubeSats. One of the challenges that the CubeSat community faced over the past few years was the lack of rides into space. Students were building CubeSats but they just sat on the shelf until an opportunity arose. In some cases, these opportunities never developed and so the CubeSat never made it to orbit. The ELaNa initiative is changing this by providing sustainable launch opportunities for educational CubeSats. Across America, these CubeSats are currently being built by students in high school all the way through graduate school. Now students know that if they build their CubeSat, submit their proposal and are selected for an ELaNa mission, they will have the opportunity to fly their satellite. ELaNa missions are the first educational cargo to be carried on expendable launch vehicles (ELY) for NASA's Launch Services Program (LSP). The first ELaNa CubeSats were slated to begin their journey to orbit in February 2011 with NASA's Glory mission. Due to an anomaly with the launch vehicle, ELaNa II and Glory failed to reach orbit. This first ELaNa mission was comprised of three IU CubeSats built by students at Montana State University (Explorer Prime Flight 1), the University of Colorado (HERMES), and Kentucky Space, a consortium of state universities (KySat). The interface between the launch vehicle and the CubeSat, the Poly-Picosatellite Orbital Deployer (P-POD), was developed and built by students at California Polytechnic State University (Cal Poly). Integrating a P-POD on a NASA ELV was not an easy task. The creation of new processes and requirements as well as numerous reviews and approvals were necessary within NASA before the first ELaNa mission could be attached to a NASA launch vehicle (LV). One of the key objectives placed on an ELaNa mission is that the CubeSat and PPOD does not increase the baseline risk to the primary mission and launch vehicle. The ELaNa missions achieve this objective by placing a rigorous management and engineering process on both the LV and CubeSat teams. So, what is the future of ELaNa? Currently there are 16 P-POD missions manifested across four launch vehicles to support educational CubeSats selected under the NASA CubeSat Initiative. From this initiative, a rigorous selection process produced 22-student CubeSat missions that are scheduled to fly before the end of 2012. For the initiative to continue, organizations need to submit proposals to the annual CubeSat initiative call so they have the opportunity to be manifested and launched.

Skrobot, Garrett Lee↗
NASA NTRS2020

Apollo Next Generation Sample Analysis (ANGSA): A Segue to the Next Era of Lunar Exploration and Sample Return Activities

In the fifty years since the first lunar samples were collected on Apollo 11, significant advancements have taken place in laboratory analysis, planetary science, and astromaterials curation. These advances are now being leveraged for the Apollo Next Generation Sample Analysis (ANGSA) Program, which aims to study specially curated Apollo samples that have never been studied before. Since Apollo 17 in 1972, a great deal has been learned about the Moon, including the unique environments of the poles. Building upon Apollo and remote sensing studies since then, the Artemis Program aims to explore the cold environments near the lunar south pole while achieving the concurrent goals of landing the first woman and the next man on the Moon by 2024. Recent developments for ANGSA have significantly accelerated our readiness for Artemis sample return, particularly in the area of cold sample studies. Four science teams were selected to study cold and/or volatile-bearing samples collected during the Apollo program. These samples have special storage and handling requirements that necessitate their processing in a -20°C environment that meets the Apollo materials and cleanliness requirements. NASA has recently undertaken the development and implementation of a cold sample processing facility to support ANGSA. A similar facility will be needed to process the cold, volatile-bearing samples planned to be returned by Artemis missions; therefore, ANGSA provides excellent preparation for Artemis’ future cold sample processing efforts. We will outline the goals of the ANGSA and Artemis programs, illustrating the complementary nature of the work for both. We will describe the efforts to date in designing, testing, and implementing a cold curation facility that meets the requirements of ANGSA and Apollo curation. We will then outline future work for that facility to reach operational readiness. Finally, we will present the sample collection and curation strategies for Artemis, showing how they overlap and build on ANGSA efforts. The development of cold curation at NASA represents a significant leap in the knowledge, experience, and technologies used in astromaterials curation, opening the door for new investigations of lunar volatiles, impacts, formation processes, prebiotic chemistry, and resource utilization, among many others.

Julie Mitchell↗
NASA NTRS2007

NASA'S Simulant Development Program Evolution and Overview

Since its origination under NASA's previous Human System Research and Technology program, the Lunar Simulant Development Program has undergone several changes. NASA recognized as early as the Apollo Program, and even more so as a result of the Apollo missions, that a viable dust and lunar simulant program is critical to the success of its space exploration goals. Unfortunately, this program has suffered the same problems that all programs share from time to time including uncertain budgets, shifting of priorities, and schedule fluctuations. To compound the problem, the process for developing simulants is being redefined and is not a trivial pursuit. Before now, NASA had not attempted to develop a suitable standard simulant since the 1990s when JSC-1 was produced. Although several other simulants have been developed by various groups both before and after the production of JSC-1, JSC-1 had become the de facto standard even though it has some limitations. The development and production of new simulants will address some of these limitations by starting with an assessment of NASA's needs and understanding the required processing in order to make these simulants.

McLemore, Carole↗
NASA NTRS2016

Secondary Payload Opportunities on NASA's Space Launch System (SLS) Enable Science and Deep Space Exploration

For the first time in almost 40 years, a NASA human-rated launch vehicle has completed its Critical Design Review (CDR). With this milestone, NASA's Space Launch System (SLS) and Orion spacecraft are on the path to launch a new era of deep space exploration. This first launch of SLS and the Orion Spacecraft is planned no later than November 2018 and will fly along a trans-lunar trajectory, testing the performance of the SLS and Orion systems for future missions. NASA is making investments to expand the science and exploration capability of the SLS by developing the capability to deploy small satellites during the trans-lunar phase of the mission trajectory. Exploration Mission 1 (EM-1) will include thirteen 6U Cubesat small satellites to be deployed beyond low earth orbit. By providing an earth-escape trajectory, opportunities are created for the advancement of small satellite subsystems, including deep space communications and in-space propulsion. This SLS capability also creates low-cost options for addressing existing Agency strategic knowledge gaps and affordable science missions. A new approach to payload integration and mission assurance is needed to ensure safety of the vehicle, while also maintaining reasonable costs for the small payload developer teams. SLS EM-1 will provide the framework and serve as a test flight, not only for vehicle systems, but also payload accommodations, ground processing, and on-orbit operations. Through developing the requirements and integration processes for EM-1, NASA is outlining the framework for the evolved configuration of secondary payloads on SLS Block upgrades. The lessons learned from the EM-1 mission will be applied to processes and products developed for future block upgrades. In the heavy-lift configuration of SLS, payload accommodations will increase for secondary opportunities including small satellites larger than the traditional Cubesat class payload. The payload mission concept of operations, proposed payload capacity of SLS, and the payload requirements for launch and deployment will be described to provide potential payload users an understanding of this unique exploration capability.

Singer, Jody↗
NASA NTRS2016

Enabling Science and Deep Space Exploration through Space Launch System (LSL) Secondary Payload Opportunities

For the first time in almost 40 years, a NASA human-rated launch vehicle has completed its Critical Design Review (CDR). By reaching this milestone, NASA's Space Launch System (SLS) and Orion spacecraft are on the path to launch a new era of deep space exploration. NASA is making investments to expand science and exploration capability of the SLS by developing the capability to deploy small satellites during the trans-lunar phase of the mission trajectory. Exploration Mission 1 (EM-1), currently planned for launch no earlier than July 2018, will be the first mission to carry such payloads on the SLS. The EM-1 launch will include thirteen 6U Cubesat small satellites that will be deployed beyond low earth orbit. By providing an earth-escape trajectory, opportunities are created for advancement of small satellite subsystems, including deep space communications and in-space propulsion. This SLS capability also creates low-cost options for addressing existing Agency strategic knowledge gaps and affordable science missions. A new approach to payload integration and mission assurance is needed to ensure safety of the vehicle, while also maintaining reasonable costs for the small payload developer teams. SLS EM-1 will provide the framework and serve as a test flight, not only for vehicle systems, but also payload accommodations, ground processing, and on-orbit operations. Through developing the requirements and integration processes for EM-1, NASA is outlining the framework for the evolved configuration of secondary payloads on SLS Block upgrades. The lessons learned from the EM-1 mission will be applied to processes and products developed for future block upgrades. In the heavy-lift configuration of SLS, payload accommodations will increase for secondary opportunities including small satellites larger than the traditional Cubesat class payload. The payload mission concept of operations, proposed payload capacity of SLS, and the payload requirements for launch and deployment will be described to provide potential payload users an understanding of this unique exploration capability.

Singer, Jody↗
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 NTRS1994

Use of a multimission system for cost effective support of planetary science data processing

JPL's Multimission Operations Systems Office (MOSO) provides a multimission facility at JPL for processing science instrument data from NASA's planetary missions. This facility, the Multimission Image Processing System (MIPS), is developed and maintained by MOSO to meet requirements that span the NASA family of planetary missions. Although the word 'image' appears in the title, MIPS is used to process instrument data from a variety of science instruments. This paper describes the design of a new system architecture now being implemented within the MIPS to support future planetary mission activities at significantly reduced operations and maintenance cost.

Green, William B.↗
NASA NTRS2007

Program Management Tool

The Program Management Tool (PMT) is a comprehensive, Web-enabled business intelligence software tool for assisting program and project managers within NASA enterprises in gathering, comprehending, and disseminating information on the progress of their programs and projects. The PMT provides planning and management support for implementing NASA programmatic and project management processes and requirements. It provides an online environment for program and line management to develop, communicate, and manage their programs, projects, and tasks in a comprehensive tool suite. The information managed by use of the PMT can include monthly reports as well as data on goals, deliverables, milestones, business processes, personnel, task plans, monthly reports, and budgetary allocations. The PMT provides an intuitive and enhanced Web interface to automate the tedious process of gathering and sharing monthly progress reports, task plans, financial data, and other information on project resources based on technical, schedule, budget, and management criteria and merits. The PMT is consistent with the latest Web standards and software practices, including the use of Extensible Markup Language (XML) for exchanging data and the WebDAV (Web Distributed Authoring and Versioning) protocol for collaborative management of documents. The PMT provides graphical displays of resource allocations in the form of bar and pie charts using Microsoft Excel Visual Basic for Application (VBA) libraries. The PMT has an extensible architecture that enables integration of PMT with other strategic-information software systems, including, for example, the Erasmus reporting system, now part of the NASA Integrated Enterprise Management Program (IEMP) tool suite, at NASA Marshall Space Flight Center (MSFC). The PMT data architecture provides automated and extensive software interfaces and reports to various strategic information systems to eliminate duplicative human entries and minimize data integrity issues among various NASA systems that impact schedules and planning.

Gawadiak, Yuri↗
NASA NTRSDate not supplied

INSPiRE – An Approach to Mission Quality Management using Network Slicing for Space Applications

Managing traffic between the Earth-Moon and Earth-Mars is a complex process requiring significant investment in resources and expertise at NASA. INSPiRE improves the performance of space networks by enabling a dynamic re-configuration process that works for any mixed topology over a heterogeneous and multi-vendor network. To achieve the desired functionality, INSPiRE incorporates a set of algorithms, machine learning processes, and policy inference to handle unpredictable, disruptive events. INSPiRE draws parallels from the current notion of the 3GPP (5G and beyond) Network Slicing approach, where the same physical network divides into several virtual networks, and for each of these virtual networks, there is a guaranteed Quality of Service for the missions that they serve.

cognitive communications↗
NASA NTRS1993

Material requirements for the High Speed Civil Transport

Under NASA-sponsored High Speed Research (HSR) programs, the materials and processing requirements have been identified for overcoming the environmental and economic barriers of the next generation High Speed Civil Transport (HSCT) propulsion system. The long (2 to 5 hours) supersonic cruise portion of the HSCT cycle will place additional durability requirements on all hot section engine components. Low emissions combustor designs will require high temperature ceramic matrix composite liners to meet an emission goal of less than 5g NO(x) per Kg fuel burned. Large axisymmetric and two-dimensional exhaust nozzle designs are now under development to meet or exceed FAR 36 Stage III noise requirements, and will require lightweight, high temperature metallic, intermetallic, and ceramic matrix composites to reduce nozzle weight and meet structural and acoustic component performance goals. This paper describes and discusses the turbomachinery, combustor, and exhaust nozzle requirements of the High Speed Civil Transport propulsion system.

Stephens, Joseph R.↗
NASA NTRS2008

Concept of Operations Visualization in Support of Ares I Production

Boeing was selected in 2007 to manufacture Ares I Upper Stage and Instrument Unit according to NASA's design which would require the use of the latest manufacturing and integration processes to meet NASA budget and schedule targets. Past production experience has established that the majority of the life cycle cost is established during the initial design process. Concept of Operations (CONOPs) visualizations/simulations help to reduce life cycle cost during the early design stage. Production and operation visualizations can reduce tooling, factory capacity, safety, and build process risks while spreading program support across government, academic, media and public constituencies. The NASA/Boeing production visualization (DELMIA; Digital Enterprise Lean Manufacturing Interactive Application) promotes timely, concurrent and collaborative producibility analysis (Boeing)while supporting Upper Stage Design Cycles (NASA). The DELMIA CONOPs visualization reduced overall Upper Stage production flow time at the manufacturing facility by over 100 man-days to 312.5 man-days and helped to identify technical access issues. The NASA/Boeing Interactive Concept of Operations (ICON) provides interactive access to Ares using real mission parameters, allows users to configure the mission which encourages ownership and identifies areas for improvement, allows mission operations or spacecraft detail to be added as needed, and provides an effective, low coast advocacy, outreach and education tool.

Chilton, James H.↗
NASA NTRS2019

Modeling of a Modern Aircraft Through Calibration Techniques

NASA is seeking a new baseline aircraft model to assess the state-of-the-art technology for aircraft noise, emissions, and fuel/energy consumption as an update to a 2005 baseline. The process of modeling engine and airframe models as a system has historically required many iterations at NASA between the airframe and engine models. A new internal process presented in this paper contains a method that simultaneously calibrates an airframe and engine model to known data to create an aircraft system model. The work presented in this paper proposes a new framework in creating new aircraft models for future NASA research. This approach is presented as a general outline applicable to any chosen commercial aircraft. As an applied example, the B737 MAX 8 aircraft is chosen as the integrated engine and airframe model subjected to calibration. Initial results show a close match to available data but further refinement in the process is necessary for this ongoing work.

Thacker, Robert↗