Search NASA⌕ Search

SEARCH · Search NASA

Results for “enabling documents”

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 577 records · Page 32
All sourcesNASA NTRSDOE OSTI
DOE OSTI2022

ACES: Infrastructure As Code. Model Optimization and Performance Capability

Infrastructure as Code (IaC) refers to managing infrastructure (networks, physical/virtual machines, storage, and connection topology) in a descriptive model/language, rather than configuring it manually or using interactive configuration tools. Just like source code can be compiled to generate the same binary code, IaC enables generating the same environment every time it is applied. IaC is a key DevOps practice and is generally used in conjunction with continuous integration (CI) and continuous delivery (CD). In CI, all code changes are merged into a mainline branch and validated multiple times a day as developers check in their changes to the source code. In CD on the other hand, code changes are automatically packaged for a new release-to-production on a regular basis. This typically enables teams to deliver software changes much more quickly and often. Developing and managing the ACES platform using (IaC) is vital for the robust deployment and continued sustainment of this foundational computing capability. IaC and DevOps practices will help us solve many of the common challenges often encountered in developing and maintaining compute infrastructure. First, it will make the provisioning, deployment, and maintenance of the compute infrastructure across multiple environments much more efficient. Second, these processes help make the overall system much more stable by continuously testing new changes as they are introduced to the system. Third, it allows us to be much more confident of the security controls in place since they can be tested as part of the CI process and all new changes can be audited and tracked. Finally, IaC enables the ACES Platform to be adaptable to the emerging technologies due to its ability to spin up different test beds to evaluate and incorporate these technologies. This document addresses common infrastructure-management challenges, describes what happens if they are not addressed, and highlights the value of utilizing IaC to tackle them. Finally, we will provide a high-level overview of the IaC and DevOps practices being utilized by the ACES Platform team.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

A High-level Design for Bidirectional Data Streaming to High-Performance Computing Systems from External Science Facilities

Cutting-edge science is increasingly data-driven due to the emergence of scientific machine learning models that can guide scientists toward fruitful areas of exploration. Experimental science facilities such as light and neutron sources, particle colliders, and radio astronomy telescopes are also producing raw measurement data at rates that exceed available data storage and computing capacity at those facilities. As a result, scientific workflows are being developed that concurrently couple experiments at science facilities with high-performance computing (HPC) facilities to enable analysis of experimental data while the experiment is ongoing, and where analysis results are potentially fed back to the experiment for use in experimental control and/or steering in a time-sensitive manner. Our goal is to design, prototype, and deploy a new capability for the Oak Ridge Leadership Computing Facility (OLCF) that enables such workflows through support for bidirectional, memory-based streaming of data from external experiments into and out of OLCF HPC systems. This high-level design document describes the related work and motivating use cases that inform our understanding of the technical requirements for this capability, and describes a proposed architectural solution that meets these requirements and our plans for demonstrating the capability.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

SOFAST CAD Layout Tool Overview and User Guide (Document Version 1.0)

Concentrating solar mirrors need to have correct geometry to accurately focus sunlight onto a receiver. SOFAST is a tool created at Sandia National Laboratories which measures a mirror’s surface normal at a dense sampling of points, enabling evaluation of a given mirror’s expected performance. SOFAST supports general mirrors, including concentrating solar heliostats, troughs, and dishes. The examples presented in this report predominantly focus on heliostats.

14 SOLAR ENERGY↗
DOE OSTI2017

Forward Modeling of Large-scale Structure: An Open-source Approach with Halotools

Here, we present the first stable release of Halotools (v0.2), a community-driven Python package designed to build and test models of the galaxy-halo connection. Halotools provides a modular platform for creating mock universes of galaxies starting from a catalog of dark matter halos obtained from a cosmological simulation. The package supports many of the common forms used to describe galaxy-halo models: the halo occupation distribution (HOD), the conditional luminosity function (CLF), abundance matching, and alternatives to these models that include effects such as environmental quenching or variable galaxy assembly bias. Satellite galaxies can be modeled to live in subhalos, or to follow custom number density profiles within their halos, including spatial and/or velocity bias with respect to the dark matter profile. Here, the package has an optimized toolkit to make mock observations on a synthetic galaxy population, including galaxy clustering, galaxy-galaxy lensing, galaxy group identification, RSD multipoles, void statistics, pairwise velocities and others, allowing direct comparison to observations. Halotools is object-oriented, enabling complex models to be built from a set of simple, interchangeable components, including those of your own creation.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗
NASA NTRS1977

Capabilities and applications of the Program to Optimize Simulated Trajectories (POST). Program summary document

The capabilities and applications of the three-degree-of-freedom (3DOF) version and the six-degree-of-freedom (6DOF) version of the Program to Optimize Simulated Trajectories (POST) are summarized. The document supplements the detailed program manuals by providing additional information that motivates and clarifies basic capabilities, input procedures, applications and computer requirements of these programs. The information will enable prospective users to evaluate the programs, and to determine if they are applicable to their problems. Enough information is given to enable managerial personnel to evaluate the capabilities of the programs and describes the POST structure, formulation, input and output procedures, sample cases, and computer requirements. The report also provides answers to basic questions concerning planet and vehicle modeling, simulation accuracy, optimization capabilities, and general input rules. Several sample cases are presented.

Brauer, G. L.↗
NASA NTRS1999

Field Encapsulation Library The FEL 2.2 User Guide

This document describes version 2.2 of the Field Encapsulation Library (FEL), a library of mesh and field classes. FEL is a library for programmers - it is a "building block" enabling the rapid development of applications by a user. Since FEL is a library intended for code development, it is essential that enough technical detail be provided so that one can make full use of the code. Providing such detail requires some assumptions with respect to the reader's familiarity with the library implementation language, C++, particularly C++ with templates. We have done our best to make the explanations accessible to those who may not be completely C++ literate. Nevertheless, familiarity with the language will certainly help one's understanding of how and why things work the way they do. One consolation is that the level of understanding essential for using the library is significantly less than the level that one should have in order to modify or extend the library. One more remark on C++ templates: Templates have been a source of both joy and frustration for us. The frustration stems from the lack of mature or complete implementations that one has to work with. Template problems rear their ugly head particularly when porting. When porting C code, successfully compiling to a set of object files typically means that one is almost done. With templated C++ and the current state of the compilers and linkers, generating the object files is often only the beginning of the fun. On the other hand, templates are quite powerful. Used judiciously, templates enable more succinct designs and more efficient code. Templates also help with code maintenance. Designers can avoid creating objects that are the same in many respects, but not exactly the same. For example, FEL fields are templated by node type, thus the code for scalar fields and vector fields is shared. Furthermore, node type templating allows the library user to instantiate fields with data types not provided by the FEL authors. This type of flexibility would be difficult to offer without the support of the language. For users who may be having template-related problems, we offer the consolation that support for C++ templates is destined to improve with time. Efforts such as the Standard Template Library (STL) will inevitably drive vendors to provide more thorough, optimized tools for template code development. Furthermore, the benefits will become harder to resist for those who currently subscribe to the least-common-denominator "code it all in C" strategy. May FEL bring you both increased productivity and aesthetic satisfaction.

Moran, Patrick J.↗
NASA NTRS2006

Cassini-Huygens maneuver automation for navigation

Many times during the Cassini-Huygens mission to Saturn, propulsive maneuvers must be spaced so closely together that there isn't enough time or workforce to execute the maneuver-related software manually, one subsystem at a time. Automation is required. Automating the maneuver design process has involved close cooperation between teams. We present the contribution from the Navigation system. In scope, this includes trajectory propagation and search, generation of ephemerides, general tasks such as email notification and file transfer, and presentation materials. The software has been used to help understand maneuver optimization results, Huygens probe delivery statistics, and Saturn ring-plane crossing geometry. The Maneuver Automation Software (MAS), developed for the Cassini-Huygens program enables frequent maneuvers by handling mundane tasks such as creation of deliverable files, file delivery, generation and transmission of email announcements, generation of presentation material and other supporting documentation. By hand, these tasks took up hours, if not days, of work for each maneuver. Automated, these tasks may be completed in under an hour. During the cruise trajectory the spacing of maneuvers was such that development of a maneuver design could span about a month, involving several other processes in addition to that described, above. Often, about the last five days of this process covered the generation of a final design using an updated orbit-determination estimate. To support the tour trajectory, the orbit determination data cut-off of five days before the maneuver needed to be reduced to approximately one day and the whole maneuver development process needed to be reduced to less than a week..

propulsion maneuvers↗
NASA NTRS2023

X-57 Cockpit Interface Control Document (ICD-CEPT-006)

The Cockpit Interface Control Document defines the hardware interfaces between the X-57 cockpit and subsystems. It provides locational and operational information in support of ground and flight operations with details on controls and displays that include Modes of Operation, Start-Up and Shut- Down Sequence diagrams and captures the current state of the MOD II Avionics Power Architecture. There is also preliminary information of the MOD III and MOD IV configurations. Microsoft PowerPoint was chosen for the document as early development required frequent meetings with multiple customers including aircraft operators (pilots), ground operations, support contractors and power, instrumentation, and human systems integration engineers and PowerPoint enabled presentations that could be quickly modified based on customer and developer interaction. One of the driving requirements for the cockpit design was to keep the left side panel as close the stock Tecnam panel as possible to reduce the failure risk of flight critical indicators. The original annunciator panel in the left side panel was modified to alert the pilot to failures in critical X-57 subsystems and an operator audio alert capability was added for these subsystems. Power-Up switches for the aircraft low voltage 13.8 VDC systems are located at the bottom of the left side panel and center panel, the same location as the stock Tecnam 13.8 VDC switches. The switches for energizing the high voltage system were located in the overhead panel to reduce the risk of inadvertently energizing the high voltage system during the low voltage power-up sequence. The Cruise Motor ARM switches were also located in the overhead panel and correspond to the same location as the stock Tecnam ignition switches. The stock Tecnam throttle levers and prop pitch levers were retained for the X-57. The throttle levers were renamed torque levers since they controlled the commanded torque to the cruise motors. The prop pitch levers provide a commanded RPM signal to an electronic prop pitch controller. X-57 specific displays, located in the right-side panel, are driven by dedicated sensors that monitor right and left side cruise motor RPM, right and left high voltage “Traction Bus” A and B (voltage, current and power) and the Avionics Bus DC converters (A and B) voltage and current. An X-57 Multi-Function Display (MFD) located in the center panel displays CAN Bus parameters. CAN Bus architecture is not certified for flight so these displays could not be used for safety critical information but were designed to be used for test point information only.

Laura Kushner↗
DOE OSTI2025

Privacy-Aware RAG-Enabled LLMs for Collaborative AI in Organizations

Recent advancements in Large Language Models (LLMs) based on Transformer architectures have significantly improved capabilities in natural language processing and generation. However, deploying LLMs for inter-organizational communication poses challenges, in ensuring privacy and facilitating effective collaboration. This paper introduces a novel decentralized inference meta-agent chatbot that leverages privacy-aware Retrieval-Augmented Generation (RAG)-enabled LLMs for collaborative AI communication across organizations. Built on Microsoft’s Autogen, the platform enables LLMs to autonomously refine responses, enhancing accuracy and relevance. It incorporates advanced hallucination mitigation techniques using Uptrain and a privacy-focused RAG framework that employs synthetic document generation to protect sensitive information. Comprehensive evaluations demonstrate the platform’s effectiveness in maintaining contextual relevance and stringent privacy standards, effectively addressing critical challenges in LLM-enhanced collaborative AI communication. This work represents a significant step toward secure and efficient inter-organizational collaboration using advanced generative AI technologies.

97 - MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Design Initiative for a 10 TeV pCM Wakefield Collider

This document outlines a community-driven Design Study for a 10 TeV pCM Wakefield Accelerator Collider. The 2020 ESPP Report emphasized the need for Advanced Accelerator R&D, and the 2023 P5 Report calls for the ``delivery of an end-to-end design concept, including cost scales, with self-consistent parameters throughout." This Design Study leverages recent experimental and theoretical progress resulting from a global R&D program in order to deliver a unified, 10 TeV Wakefield Collider concept. Wakefield Accelerators provide ultra-high accelerating gradients which enables an upgrade path that will extend the reach of Linear Colliders beyond the electroweak scale. Here, we describe the organization of the Design Study including timeline and deliverables, and we detail the requirements and challenges on the path to a 10 TeV Wakefield Collider.

43 PARTICLE ACCELERATORS↗
DOE OSTI2025

Environmental Impacts of Closed-Loop Pumped Storage Hydropower

The goal of this report is to help license applicants, resource agencies, and other members of the hydropower community involved in closed-loop pumped storage hydropower permitting and licensing process, focus the scope of environmental reviews, and more quickly identify impacts with project nexus and potential mitigation measures for these impacts. Pumped storage hydropower (PSH) is an energy storage technology that uses energy to pump water up from a lower reservoir to an upper reservoir where water is stored until electricity is needed and the water is released to a lower reservoir passing through turbines. Closed-loop PSH—PSH that is not continuously connected to a naturally flowing water feature—is one of the lowest greenhouse gas emitting energy storage technologies and is therefore a critical part of the transition to renewable energy (Simon et al. 2023). Proposals for closed-loop PSH facilities in the United States currently account for more than 40% of original licenses and 99% of potential generation capacity in the Federal Energy Regulatory Commission (FERC) hydropower licensing pipeline (Johnson et al. 2023). While closed-loop PSH facilities can have lower environmental impacts than open-loop PSH facilities, no closed-loop facilities have been constructed in the United States to enable direct accounting of project impacts and efficacy of mitigations. Many proposals for closed-loop PSH submitted to FERC are abandoned early in the permitting and licensing process prior to license applications and environmental assessments, so there is little documentation describing potential project impacts and proposed mitigations. The newness of closed-loop PSH proposals in the United States may mean that tribal, federal, and state agencies with authorities for cultural and natural resources protection and management involved in the FERC licensing process may not have experience with closed-loop PSH regulation. Moreover, many proposed closed-loop PSH facilities are in areas that do not have high concentrations of conventional hydropower, so these agencies may also be unfamiliar with the FERC hydropower licensing process. The goal of this report is to help license applicants, resource agencies, and other members of the hydropower community focus the scope of environmental review for the closed-loop PSH development, licensing, and federal authorization process enabling quicker identification of potential impacts, mitigations, and situations where mitigation may not be possible. We found that environmental impacts of closed-loop PSH are highly site-specific, and generalizations about the types of environmental impacts across closed-loop PSH projects are difficult to make. Environmental impacts of closed-loop PSH are like those for open-loop PSH with a few exceptions including water sourcing, which can lead to delays and contention due to potential complexities with water rights, impacts to aquatic resources, and greenhouse gas emission potential. Cultural resource impacts were commonly reported in National Environmental Policy Act (NEPA) documents reviewed and discussed in interviews, but in many cases such impacts cannot be mitigated.

13 HYDRO ENERGY↗
NASA NTRS1991

High-spatial-resolution passive microwave sounding systems

During this period the emphasis was on the following: (1) further design, construction, and testing of the improved 54-GHz portion of the 54-118 GHz microwave temperature sounder (MTS) aircraft radiometer system in preparation for ER-2 observations in July 1991; and (2) final analysis and documentation of procedures for detecting and analyzing thermal waves in our 118-GHz MTS imagery. In addition, we have new unpublished measurements of dry-air attenuation at frequencies of 54 to 66 GHz and over a temperature range of 280K to 326K; these measurements should enable us to improve further our atmospheric transmittance models. It was further noted that the proposed SSMIS conical-scanning microwave spectrometer on the military DMSP Block 5D-3 spacecraft designed to measure stratospheric and mesospheric temperature profiles will be observing the Zeeman-split oxygen lines with sufficient spectral resolution that the changing Doppler shifts with view angle will substantially degrade the potential system performance unless remedied; this was briefly studied and documented.

Staelin, David H.↗
DOE OSTI2025

The Dual-Axis Radiographic Hydrodynamic Test Facility Capability eXpansion (DCX) Strategy

This document details the strategy proposed to meet the National Nuclear Security Administration (NNSA) requirement for the Dual-Axis Radiographic Hydrodynamic Test (DARHT) Facility Sustainment and Modernization projects identified in multiple NNSA Stockpile Stewardship and Management Plan (SSMP) reports to Congress [NNSA, 2020; 2021; 2022; 2023; 2024]. DARHT has become indispensable for the certification of the primaries of U.S. nuclear weapons since the current U.S. moratorium halted underground nuclear testing more than 30 years ago. However, aging facilities, evolving technology, and other issues are limiting or threatening the capability of DARHT to meet NNSA’s expanding mission needs now and into the future. This DARHT Capability eXpansion (DCX) strategy was developed to address NNSA needs by extending DARHT’s reliability and resilience, increasing the quality and quantity of DARHT data, and enabling hydrodynamic measurements in complex environments. The strategy can be implemented through integration of line-item projects, acquisition of major items of equipment, and other actions coordinated with the execution of the SSMP. This strategy document is intended for U.S. Government officials, particularly authorizers, appropriators, and program leaders. It may also be furnished to DARHT users, customers, collaborators, stakeholders, and visitors as needed

45 MILITARY TECHNOLOGY, WEAPONRY, AND NATIONAL DEF↗
DOE OSTI2016

SU-F-T-241: Reduction in Planning Errors Via a Process Control Developed Using the Eclipse Scripting API

Purpose: Errors found during initial physics plan checks frequently require replanning and reprinting, resulting decreased departmental efficiency. Additionally, errors may be missed during physics checks, resulting in potential treatment errors or interruption. This work presents a process control created using the Eclipse Scripting API (ESAPI) enabling dosimetrists and physicists to detect potential errors in the Eclipse treatment planning system prior to performing any plan approvals or printing. Methods: Potential failure modes for five categories were generated based on available ESAPI (v11) patient object properties: Images, Contours, Plans, Beams, and Dose. An Eclipse script plugin (PlanCheck) was written in C# to check errors most frequently observed clinically in each of the categories. The PlanCheck algorithms were devised to check technical aspects of plans, such as deliverability (e.g. minimum EDW MUs), in addition to ensuring that policy and procedures relating to planning were being followed. The effect on clinical workflow efficiency was measured by tracking the plan document error rate and plan revision/retirement rates in the Aria database over monthly intervals. Results: The number of potential failure modes the PlanCheck script is currently capable of checking for in the following categories: Images (6), Contours (7), Plans (8), Beams (17), and Dose (4). Prior to implementation of the PlanCheck plugin, the observed error rates in errored plan documents and revised/retired plans in the Aria database was 20% and 22%, respectively. Error rates were seen to decrease gradually over time as adoption of the script improved. Conclusion: A process control created using the Eclipse scripting API enabled plan checks to occur within the planning system, resulting in reduction in error rates and improved efficiency. Future work includes: initiating full FMEA for planning workflow, extending categories to include additional checks outside of ESAPI via Aria database queries, and eventual automated plan checks.

60 APPLIED LIFE SCIENCES↗
NASA NTRS1993

Space Electrochemical Research and Technology

This document contains the proceedings of NASA's fourth Space Electrochemical Research and Technology (SERT) Conference, held at the NASA Lewis Research Center on April 14-15, 1993. The objective of the conference was to assess the present status and general thrust of research and development in those areas of electrochemical technology required to enable NASA missions into the next century. The conference provided a forum for the exchange of ideas and opinions of those actively involved in the field, in order to define new opportunities for the application of electrochemical processes in future NASA missions. Papers were presented in three technical areas: advanced secondary batteries, fuel cells, and advanced concepts for space power. This document contains the papers presented.

Source record↗
DOE OSTI2026

Elevating SolTrace's Capabilities for the Next Generation of Concentrating Solar Analysis

SolTrace is an open-source Monte Carlo ray tracing software developed at NREL. SolTrace can characterize concentrating solar thermal (CST) collector optical performance and is CST technology agnostic. Shown in Fig. 1, SolTrace is a foundational tool in NREL's CST system and component modeling suite. SolTrace's generic surface elements can flexibly model novel collector and receiver designs to predict spatial and temporal flux distributions - critical to understand for CST component design, performance prediction, and system integration. Since its initial development, SolTrace has over 1,650 references on Google Scholar, over 9,800 downloads since 2017, and has served the CST research and development community as a benchmark of 3rd party verification. SolTrace provides users with many options for defining surface shape and boundaries. However, SolTrace provides limited documentation which can result in a steep learning curve for new users. Additionally, SolTrace lacks the computational performance required to evaluate optical performance of a CST system over the course of a year and/or iteratively over design parameters in a timely manner. To address this, we are working towards a new release of SolTrace that enables increased computational throughput by implementing ray tracing acceleration structures and enabling GPU parallelization. Additionally, we are working to improve SolTrace's usability, accessibility, and maintainability by (1) automating solar position time-dependent simulation processes, (2) creating general CST collector templates of grouped elements, (3) updating the user interface to better visualize model inputs and outputs, and (4) creating a user support network through forums, "how to" videos, and documentation.

14 SOLAR ENERGY↗
NASA NTRS2016

Investigating the Simulink Auto-Coding Process

Model based program design is the most clear and direct way to develop algorithms and programs for interfacing with hardware. While coding "by hand" results in a more tailored product, the ever-growing size and complexity of modern-day applications can cause the project work load to quickly become unreasonable for one programmer. This has generally been addressed by splitting the product into separate modules to allow multiple developers to work in parallel on the same project, however this introduces new potentials for errors in the process. The fluidity, reliability and robustness of the code relies on the abilities of the programmers to communicate their methods to one another; furthermore, multiple programmers invites multiple potentially differing coding styles into the same product, which can cause a loss of readability or even module incompatibility. Fortunately, Mathworks has implemented an auto-coding feature that allows programmers to design their algorithms through the use of models and diagrams in the graphical programming environment Simulink, allowing the designer to visually determine what the hardware is to do. From here, the auto-coding feature handles converting the project into another programming language. This type of approach allows the designer to clearly see how the software will be directing the hardware without the need to try and interpret large amounts of code. In addition, it speeds up the programming process, minimizing the amount of man-hours spent on a single project, thus reducing the chance of human error as well as project turnover time. One such project that has benefited from the auto-coding procedure is Ramses, a portion of the GNC flight software on-board Orion that has been implemented primarily in Simulink. Currently, however, auto-coding Ramses into C++ requires 5 hours of code generation time. This causes issues if the tool ever needs to be debugged, as this code generation will need to occur with each edit to any part of the program; additionally, this is lost time that could be spent testing and analyzing the code. This is one of the more prominent issues with the auto-coding process, and while much information is available with regard to optimizing Simulink designs to produce efficient and reliable C++ code, not much research has been made public on how to reduce the code generation time. It is of interest to develop some insight as to what causes code generation times to be so significant, and determine if there are architecture guidelines or a desirable auto-coding configuration set to assist in streamlining this step of the design process for particular applications. To address the issue at hand, the Simulink coder was studied at a foundational level. For each different component type made available by the software, the features, auto-code generation time, and the format of the generated code were analyzed and documented. Tools were developed and documented to expedite these studies, particularly in the area of automating sequential builds to ensure accurate data was obtained. Next, the Ramses model was examined in an attempt to determine the composition and the types of technologies used in the model. This enabled the development of a model that uses similar technologies, but takes a fraction of the time to auto-code to reduce the turnaround time for experimentation. Lastly, the model was used to run a wide array of experiments and collect data to obtain knowledge about where to search for bottlenecks in the Ramses model. The resulting contributions of the overall effort consist of an experimental model for further investigation into the subject, as well as several automation tools to assist in analyzing the model, and a reference document offering insight to the auto-coding process, including documentation of the tools used in the model analysis, data illustrating some potential problem areas in the auto-coding process, and recommendations on areas or practices in the current Ramses model that should be further investigated. Several skills were required to be built up over the course of the internship project. First and foremost, my Simulink skills have improved drastically, as much of my experience had been modeling electronic circuits as opposed to software models. Furthermore, I am now comfortable working with the Simulink Auto-coder, a tool I had never used until this summer; this tool also tested my critical thinking and C++ knowledge as I had to interpret the C++ code it was generating and attempt to understand how the Simulink model affected the generated code. I had come into the internship with a solid understanding of Matlab code, but had done very little in using it to automate tasks, particularly Simulink tasks; along the same lines, I had rarely used shell script to automate and interface with programs, which I gained a fair amount of experience with this summer, including how to use regular expression. Lastly, soft-skills are an area everyone can continuously improve on; having never worked with NASA engineers, which to me seem to be a completely different breed than what I am used to (commercial electronic engineers), I learned to utilize the wealth of knowledge present at JSC. I wish I had come into the internship knowing exactly how helpful everyone in my branch would be, as I would have picked up on this sooner. I hope that having gained such a strong foundation in Simulink over this summer will open the opportunity to return to work on this project, or potentially other opportunities within the division. The idea of leaving a project I devoted ten weeks to is a hard one to cope with, so having the chance to pick up where I left off sounds appealing; alternatively, I am interested to see if there are any opening in the future that would allow me to work on a project that is more in-line with my research in estimation algorithms. Regardless, this summer has been a milestone in my professional career, and I hope this has started a long-term relationship between JSC and myself. I really enjoy the thought of building on my experience here over future summers while I work to complete my PhD at Missouri University of Science and Technology.

Gualdoni, Matthew J.↗
NASA NTRS2016

Promoting a Culture of Tailoring for Systems Engineering Policy Expectations

NASA's Marshall Space Flight Center (MSFC) has developed an integrated systems engineering approach to promote a culture of tailoring for program and project policy requirements. MSFC's culture encourages and supports tailoring, with an emphasis on risk-based decision making, for enhanced affordability and efficiency. MSFC's policy structure integrates the various Agency requirements into a single, streamlined implementation approach which serves as a "one-stop-shop" for our programs and projects to follow. The engineers gain an enhanced understanding of policy and technical expectations, as well as lesson's learned from MSFC's history of spaceflight and science missions, to enable them to make appropriate, risk-based tailoring recommendations. The tailoring approach utilizes a standard methodology to classify projects into predefined levels using selected mission and programmatic scaling factors related to risk tolerance. Policy requirements are then selectively applied and tailored, with appropriate rationale, and approved by the governing authorities, to support risk-informed decisions to achieve the desired cost and schedule efficiencies. The policy is further augmented by implementation tools and lifecycle planning aids which help promote and support the cultural shift toward more tailoring. The MSFC Customization Tool is an integrated spreadsheet that ties together everything that projects need to understand, navigate, and tailor the policy. It helps them classify their project, understand the intent of the requirements, determine their tailoring approach, and document the necessary governance approvals. It also helps them plan for and conduct technical reviews throughout the lifecycle. Policy tailoring is thus established as a normal part of project execution, with the tools provided to facilitate and enable the tailoring process. MSFC's approach to changing the culture emphasizes risk-based tailoring of policy to achieve increased flexibility, efficiency, and effectiveness in project execution, while maintaining appropriate rigor to ensure mission success.

Blankenship, Van A.↗