Search NASA⌕ Search

SEARCH · Search NASA

Results for “Project Lifecycles”

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 235 records · Page 13
All sourcesNASA NTRSDOE OSTI
DOE OSTI2025

Impact of a dynamic grid mix and climate on operational carbon emissions modeling for different building typologies and climate zones

Calculating operational carbon emissions through a building’s lifecycle is complex due to the dynamic nature of influencing factors such as climate and energy grid mix. This paper introduces a novel methodology for modeling 30-year operational carbon impacts of buildings and applies this method to mid-rise office and residential typologies across various US climate zones. The method accounts for these temporal variabilities using new and scarcely cited data sources. Key findings indicate that future changes in the climate, while impactful, play a relatively modest role in operational carbon emissions compared to significant reductions with modeling scenarios using the projected decarbonization of the electricity grid. Here, the study also finds that using annual, month-hourly, or hourly grid emission factors have a minimal impact on carbon accounting, except in certain climates and program types where emission patterns do not align with a building’s energy consumption. Warmer climates like Miami, Florida and Tucson, Arizona, which rely heavily on cooling, demonstrate larger variations in carbon emissions when using higher temporal resolution emission factors. Ultimately, this study underscores the critical role of grid decarbonization in reducing long-term emissions and the importance of incorporating this variable in life cycle assessment (LCA) modeling.

32 ENERGY CONSERVATION, CONSUMPTION, AND UTILIZATI↗
DOE OSTI2025

CEC Quest: Long Duration Energy Storage Impact Analysis Tool

SAND2025-14389O CEC Quest is a Python tool with a user interface designed to analyze the greenhouse gas impacts of long-duration energy storage projects in California. The tool automates data collection from public sources and uses an Application Programming Interface (API) to enable users to download photovoltaic resource availability, marginal operating emissions rate, and utility rate data. It guides users in inputting parameters for a battery energy storage model and uploading site electrical load data, while also prompting for relevant analysis parameters like timestep and grid limits. CEC Quest performs monthly optimization of one year of data to assess impacts on the site’s electrical bill and the grid’s greenhouse gas emissions. Finally, it conducts a lifecycle analysis to evaluate changes over a defined quantification period, with results aggregated through automated report generation. Sandia National Laboratories is a multimission laboratory managed and operated by National Technology & Engineering Solutions of Sandia, LLC, a wholly owned subsidiary of Honeywell International Inc., for the U.S. Department of Energy’s National Nuclear Security Administration under contract DE-NA0003525.

Rosewater, David [Sandia National Lab. (SNL-CA), L↗
DOE OSTI2024

Leveraging NREL's ResStock & ComStock Dataset to Evaluate Building Stock Electrification: Preprint

Residential and commercial buildings accounted for 40% of U.S. energy consumption in 2022 and represent a significant opportunity for decarbonization through energy efficiency and electrification, and for grid planning. Building stock energy modeling is a powerful tool that can evaluate what-if scenarios as utilities, municipalities, policymakers, building owners and others work towards equitable building decarbonization and climate goals. This presentation will highlight several high-impact use cases of the National Renewable Energy Laboratory (NREL)'s highly granular, bottom-up building stock energy modeling tools, ResStock and ComStock. These use cases cover a wide range of project scale, from neighborhood electrification analysis and municipality long-term energy planning, to state energy code development and national policy evaluation. This presentation will showcase specific real-world applications for which ResStock and ComStock have been utilized across the country, including California codes and standards cost-effectiveness analysis, New York City affordable housing electrification cost gap analysis, and California targeted electrification and gas decommissioning analysis. For each use case, this presentation will illustrate how ResStock and ComStock played a crucial role in accurately characterizing regional building stocks, providing discrete and aggregated end-use load shapes, and calculating lifecycle consumption, emissions, and costs for a variety of building electrification strategies and scenarios. Finally, this presentation will demonstrate how the data provided by ResStock and ComStock can help unlock significant outcomes for these use cases, including but not limited to, customer bill impact, incentive and program design, and energy equity analyses.

building stock modeling↗
NASA NTRS2017

Applying Standard Independent Verification and Validation (IVV) Techniques Within an Agile Framework: Is There a Compatibility Issue?

Agile methods have gained wide acceptance over the past several years, to the point that they are now a standard management and execution approach for small-scale software development projects. While conventional Agile methods are not generally applicable to large multi-year and mission-critical systems, Agile hybrids are now being developed (such as SAFe) to exploit the productivity improvements of Agile while retaining the necessary process rigor and coordination needs of these projects. From the perspective of Independent Verification and Validation (IVV), however, the adoption of these hybrid Agile frameworks is becoming somewhat problematic. Hence, we find it prudent to question the compatibility of conventional IVV techniques with (hybrid) Agile practices.This paper documents our investigation of (a) relevant literature, (b) the modification and adoption of Agile frameworks to accommodate the development of large scale, mission critical systems, and (c) the compatibility of standard IVV techniques within hybrid Agile development frameworks. Specific to the latter, we found that the IVV methods employed within a hybrid Agile process can be divided into three groups: (1) early lifecycle IVV techniques that are fully compatible with the hybrid lifecycles, (2) IVV techniques that focus on tracing requirements, test objectives, etc. are somewhat incompatible, but can be tailored with a modest effort, and (3) IVV techniques involving an assessment requiring artifact completeness that are simply not compatible with hybrid Agile processes, e.g., those that assume complete requirement specification early in the development lifecycle.

Agile↗
NASA NTRS2022

NASA System-Wide Safety Wildland Firefighting Operations Workshop Report

On March 9-11, 2022, NASA’s System-Wide Safety Wildland Firefighting Operations Workshop engaged the broader wildland firefighting management ecosystem in a safety-oriented discussion via a virtual platform. This enabled a better understanding of how NASA and community expertise can be leveraged in the safe development of current and future firefighting systems and operations. The goals of the workshop were to: (1) identify and prioritize the top safety-oriented risks, gaps in capabilities, and emerging technologies to enhance wildland firefighting for both near-term and far-term concepts, with a specific focus on aviation operations and (2) engage the stakeholder community in defining emergent safety-oriented scope, roles, responsibilities, and procedures for agents undergoing increasingly complex wildland firefighting operations in information-rich, but uncertain environments. Workshop participants were solicited from wildland firefighting stakeholders across government, industry, and academia. All levels of government were engaged, as NASA sought attendees from federal, state, local, and tribal government agencies. Industry participants from traditional wildland firefighting domains such as data visualization and equipment manufacturers were invited, and corporate attendees from novel application domains such as aerial robotics and autonomous systems were present as well. The top three findings were as follows: (1) Enhancing situation awareness is a safety priority, especially in the use of aerial assets; (2) Timely access to information along with data fusion and integrated displays will enhance safety-critical decision-making both inside and outside aviation contexts; and (3) Tailorable standards and common operating pictures in the field will enhance inter-agency cooperation in the wildland firefighting lifecycle and enable the optimal use of limited resources such as aerial assets. The workshop helped inform NASA of the relevant safety-related wildland firefighting concerns and aided the broader ecosystem in understanding the potential safety-oriented role NASA might play in this community. Increased engagement with crucial governmental stakeholders (e.g., U.S. Forest Service, CAL FIRE, etc.) along with industry partners in cutting- edge information -centric domains is a fundamental next step. Additionally, the workshop findings will help define the first of a series of operationally challenging demonstrations, held in concert with strategic ecosystem partners, known as the Safety Demonstrator Series for NASA’s System-Wide Safety project. The first demonstration is set in the wildland firefighting application domain and will: (1) examine high risk operational scenarios to reduce their overall risk via services, functions or capabilities that act as risk mitigators (or transfer that risk to automated systems better able to tolerate it) and (2) explore novel tools and technologies that will enhance safety margins by enabling non-traditional or neoteric operational paradigms.

wildland firefighting↗
NASA NTRS1991

Ada and the rapid development lifecycle

JPL is under contract, through NASA, with the US Army to develop a state-of-the-art Command Center System for the US European Command (USEUCOM). The Command Center System will receive, process, and integrate force status information from various sources and provide this integrated information to staff officers and decision makers in a format designed to enhance user comprehension and utility. The system is based on distributed workstation class microcomputers, VAX- and SUN-based data servers, and interfaces to existing military mainframe systems and communication networks. JPL is developing the Command Center System utilizing an incremental delivery methodology called the Rapid Development Methodology with adherence to government and industry standards including the UNIX operating system, X Windows, OSF/Motif, and the Ada programming language. Through a combination of software engineering techniques specific to the Ada programming language and the Rapid Development Approach, JPL was able to deliver capability to the military user incrementally, with comparable quality and improved economies of projects developed under more traditional software intensive system implementation methodologies.

Deforrest, Lloyd↗
NASA NTRS1990

The Environmental Control and Life Support System (ECLSS) advanced automation project

The objective of the environmental control and life support system (ECLSS) Advanced Automation Project is to influence the design of the initial and evolutionary Space Station Freedom Program (SSFP) ECLSS toward a man-made closed environment in which minimal flight and ground manpower is needed. Another objective includes capturing ECLSS design and development knowledge future missions. Our approach has been to (1) analyze the SSFP ECLSS, (2) envision as our goal a fully automated evolutionary environmental control system - an augmentation of the baseline, and (3) document the advanced software systems, hooks, and scars which will be necessary to achieve this goal. From this analysis, prototype software is being developed, and will be tested using air and water recovery simulations and hardware subsystems. In addition, the advanced software is being designed, developed, and tested using automation software management plan and lifecycle tools. Automated knowledge acquisition, engineering, verification and testing tools are being used to develop the software. In this way, we can capture ECLSS development knowledge for future use develop more robust and complex software, provide feedback to the knowledge based system tool community, and ensure proper visibility of our efforts.

Dewberry, Brandon S.↗
DOE OSTI2026

Development of Composite Photocatalyst Materials that are Highly Selective for Solar Hydrogen Production and their Evaluation in Z-Scheme Reactor Designs

The key technology gap preventing a vertically stacked dual-bed particle suspension reactor from achieving the DOE MYRD&D ultimate cost target for H 2 production remains the lack of materials in particle form factor that exhibit ≥10% solar-to-H 2 energy conversion (STH) efficiency as a suspension. Therefore, our project goals centered around strategies to increase the STH efficiency by enhancing photophysical properties of perovskite oxide particles including increased visible-light absorption, increased selectivity for electrocatalysis of the H 2 evolution reaction (HER) and the O 2 evolution reaction (OER) through development of ultrathin oxide coatings, correlating composition and structure to function, and improving understanding of multiscale transport and kinetic processes.

08 HYDROGEN↗
DOE OSTI2025

A Data Processing Pipeline To Extract A Knowledge Graph From Heterogeneous Data For Socio-technical Analysis Of Critical Infrastructure Influence

The code is written in Python and consists of the following pipeline that is implemented in Apache Airflow. This pipeline intends to understand the companies that are directly or indirectly involved with a type of critical infrastructure system at some point in that system's lifecycle. The pipeline takes a configuration file that specifies a list of initial companies to consider, a geographic region of interest, and a set of SEC form types as well as other data sources (e.g. CrunchBase) from which to extract entities and relations. There are four main components to this pipeline as currently implemented: Entity Extraction, Network Construction, Analysis, and Visualization. First, Entity Extraction, is implemented as the `topear-extract_organizations` Apache Airflow workflow. Given an initial query that specifies a geographic region of interest and a time interval, the software will extract CI facilities of interest and organizations that have a direct influence relationship to those facilities (e.g. ownership). During the course of the LDRD, we focused on Electric Vehicle charging stations and this information is available via the Department of Energy (DOE) database on fueling stations maintained by NREL. Within the context of the DOE CESER project, we have focused on Battery Energy Storage Systems (BESS). Second, the Network Extraction component will iteratively construct a social network graph given the set of organizations and people extracted in the previous step. Organizations (and eventually People if desired) are then fed as a query to the `topgear-construct_social_network` Apache Airflow workflow which given a set of initial companies and data sets (e.g. SEC EDGAR form types, OpenCorporates, Crunchbase). This Airflow workflow will iteratively query such data sources to discover relationships with new organizations and people. For example, this module can iteratively query SEC EDGAR for metadata that documents the number of each type of form for the given set of companies and their location. This forms metadata represents a catalog of data sources from SEC EDGAR for the extracted social network knowledge graph. The pipeline then downloads these forms from the website and saves them in a build directory for further processing. These documents are then parsed for entities and relations. Again, we note that in additional to SEC data sources, this step can also pull in information on organizations via API services such as CrunchBase and OpenCorporates or bulk data sources. At the end of this step, the resultant social network, the Critical Infrastructure network, and the edges that encode relationships between organizations and CI facilities, form the Adversarial Socio-Technical Network (ASTN) that informs the analysis. Third, the Analysis component processes these generated ASTN. Previously, that has included the ability to compare prevalence of different vendors for a given infrastructure component type across different regions as well as identify common public and private investors across those vendors. This was demonstrated for EV Charging Stations across several different metropolitan areas within an IEEE PES GridEdge publication. More recently, we have looked at ways to identify infrastructure owners and operators of BESS with the most nameplate capacity across different states as well as other indictors of risk resulting from changes in ownership over time. Finally, the Visualization component consists of an HTML/CSS/JS framework by which users can interact geospatial, operational, and organizational relationships across a given portfolio of Critical Infrastructure facilities. The objective is to provide a library of UI/UX modules that can be repurposed for stakeholder-specific dashboards. All of the modules are related via a common event model that enables UI actions in one view to percolate across the other views.

Weaver, Gabriel [Idaho National Laboratory (INL), ↗
NASA NTRS2011

Ground Processing Affordability for Space Vehicles

Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.

Ingalls, John↗
NASA NTRS2013

Integrated Ground Operations Demonstration for Responsive Space Access

Integrated Ground Operations Demonstration Units (IGODU) project developed to mature, integrate and demonstrate advancements in cryogenics, system health management and command and control technologies. Two Distinct Testing Environments: a) GODU Integrated Refrigeration and Storage - GODU LH2; b) GODU Autonomous Control - GODU LO2. Scope: I. GODU LH2: a) Investigate alternative storage and distribution architecture for future cryogenic propellant operations. b) Demonstrate advanced cryogenic propellant handling operations (liquefaction, storage and distribution) of normal boiling point and sub-cooled cryogenic propellants. II. GODU L02: a) Develop and demonstrate advanced control and health management technologies and techniques to autonomously control cryogenic propellant servicing operations. b) Investigate modern COTS hardware and control systems in an effort to reduce the "standing army" of engineers associated with maintaining and operating ground systems through the use of health management and autonomous control technologies. Goals: a) Raise Technology Readiness Levels (TRL) and Integration Readiness Levels (IRL) of several key technology development areas. b) Reduce operations lifecycle costs of future test programs and launch complexes. c) Demonstrate technologies for future exploration beyond low earth orbit. d) Serve as test environments for extraterrestrial surface operations.

Johnson, Robert G.↗
NASA NTRS2018

Preventing Premature Death in the M&S Lifecycle: Lessons Learned from Resurrection and Modernization of a Space System Contamination Model

Models and simulations (M&S) are often developed to meet specific needs and unique requirements for a particular situation. Once the M&S is implemented for a specific case and questions are answered, the M&S may go dormant until a similar need arises again at a later time, perhaps months to years later. Possible modification of the M&S may be required, and issues may arise if the M&S is not well documented, captured, or available. This can severely limit the useful life of the M&S and hinder future development or enhancements. This situation occurred with an M&S tool that had been developed to determine the impact to space system performance due to the presence of molecular contaminant films accumulating on key spacecraft surfaces. The challenges and issues encountered when resurrecting, executing, and modernizing the tool will be presented as a case study. To stay ahead of tomorrow’s challenges, resources to create M&S tools must be utilized efficiently. Lessons learned from this case study will aid M&S developers and users in planning for proper maintenance, transfer, and capture of key M&S tools and knowledge to avoid increased cost, increased development time, and wasted resources for projects relying on M&S.

Seasly, Elaine↗
NASA NTRS2006

Mission Control Technologies: A New Way of Designing and Evolving Mission Systems

Current mission operations systems are built as a collection of monolithic software applications. Each application serves the needs of a specific user base associated with a discipline or functional role. Built to accomplish specific tasks, each application embodies specialized functional knowledge and has its own data storage, data models, programmatic interfaces, user interfaces, and customized business logic. In effect, each application creates its own walled-off environment. While individual applications are sometimes reused across multiple missions, it is expensive and time consuming to maintain these systems, and both costly and risky to upgrade them in the light of new requirements or modify them for new purposes. It is even more expensive to achieve new integrated activities across a set of monolithic applications. These problems impact the lifecycle cost (especially design, development, testing, training, maintenance, and integration) of each new mission operations system. They also inhibit system innovation and evolution. This in turn hinders NASA's ability to adopt new operations paradigms, including increasingly automated space systems, such as autonomous rovers, autonomous onboard crew systems, and integrated control of human and robotic missions. Hence, in order to achieve NASA's vision affordably and reliably, we need to consider and mature new ways to build mission control systems that overcome the problems inherent in systems of monolithic applications. The keys to the solution are modularity and interoperability. Modularity will increase extensibility (evolution), reusability, and maintainability. Interoperability will enable composition of larger systems out of smaller parts, and enable the construction of new integrated activities that tie together, at a deep level, the capabilities of many of the components. Modularity and interoperability together contribute to flexibility. The Mission Control Technologies (MCT) Project, a collaboration of multiple NASA Centers, led by NASA Ames Research Center, is building a framework to enable software to be assembled from flexible collections of components and services.

Trimble, Jay↗
DOE OSTI2026

A Reverse Logistics Tool For Ev Battery Recycling And Repurposing,

The demand for electric vehicles (EVs) in the United States is projected to rise significantly, with sales expected to reach approximately 4.1 million units by 2030. However, the U.S. remains heavily reliant on imports for the batteries and critical raw materials—such as lithium, cobalt, and nickel—that power these vehicles. As of 2024, around 70% of these imports originate from China. This dependency has become even more precarious following China’s imposition of export restrictions in April 2025, a retaliatory move against U.S. tariffs. These developments highlight the strategic vulnerabilities posed by China’s dominant position in the critical materials market. Compounding the issue, decades of intensive extraction have severely depleted global reserves of critical materials, widening the gap between supply and growing demand. This situation underscores the urgent need for the U.S. and other nations to diversify their sources of critical materials and enhance domestic capabilities to secure these resources—an essential step toward ensuring long-term energy security. At the end of their lifecycle—whether due to the battery’s degradation or the retirement of the vehicle—EV batteries are often improperly disposed of or sent to landfills. However, many of these batteries still retain usable capacity and can follow one of three alternative pathways: (a) Re-used: deployed in another vehicle with a shorter driving range, (b) Re-purposed: utilized act as a backup storage/power for data centers, solar panels, and e-scotters or (c) Recycled: broken down to recover the critical materials. To that end, the proposed tool (REBORN) is designed to optimize the reverse logistics network for battery repurposing and recycling. Its goal is to minimize associated costs while identifying optimal locations for battery collection and processing. Ultimately, REBORN ensures that each battery is used to its fullest potential.

Srinivas, SrikarV. [Idaho National Laboratory (INL↗
DOE OSTI2024

Abstract for CRADA between NETL and the AZ Board of Regents on behalf of Arizona State University

Arizona State University (ASU) and the National Energy Technology Laboratory (NETL) will collaborate on the development and scale up of sorbent composites that efficiently capture carbon dioxide (CO 2 ) directly from air under an awarded project from the Department of Energy’s Direct Air Capture (DAC) Pre-Commercialization Technology Prize. For DAC to be considered a viable technology for decarbonization, the cost of carbon removal needs to decrease below the proposed carbon tax incentive outlined in the recent Inflation Reduction Act (IRA) (Section 45 Q), which is set at $\$$180 per ton of CO 2 . Achieving this goal requires the development of a cost-effective, environmentally friendly sorbent with high CO 2 sorption capacity and efficient kinetics under DAC conditions as the overall cost of CO 2 captured is highly sensitive to factors such as sorbent cost and sorbent lifetime. ASU has developed a sorbent technology that can potentially reduce CO 2 removal costs by DAC. NETL has expertise in DAC TEA and LCA development and DAC sorbent testing. The collaboration between ASU and NETL aims to accelerate development and deployment of ASU’s technology by quantifying the performance, cost and lifecycle impacts of ASU’s technology and validating sorbent performance.

54 ENVIRONMENTAL SCIENCES↗
NASA NTRS2005

Failure Assessment

Three questions to which software developers want accurate, precise answers are "How can the software system fail?", "mat bad things will happen if the software fails?t', and "How many failures will the software experience?". Numerous techniques have been devised to answer these questions; three of the best known are: 1) Software Fault Tree Analysis (SFTA) 2) Software Failure Modes, Effects, and Criticality Analysis (SFMECA 3) Software Fault/Failure Modeling. SFTA and SFMECA have been successfully used to analyze the flight software for a number of robotic planetary exploration missions, including Galileo, Cassini, and Deep Space 1. Given the increasing interest in reusing software components from mission to mission, one of us has developed techniques for reusing the corresponding portions of the SFTA and SFMECA, reducing the effort required to conduct these analyses. SFTA has also been shown to be effective in analyzing the security aspects of software systems; intrusion mechanisms and effects can easily be modeled using these techniques. The Bi- Directional Safety Analysis (BDSA) method combines a forward search (similar to SFMECA) from potential failure modes to their effects, with a backward search (similar to SFTA) from feasible hazards to the contributing causes of each hazard. BDSA offers an efficient way to identify latent failures. Recent work has extended BDSA to product-line applications such as flight-instrumentation displays and developed tool support for the reuse of the failure-analysis artifacts within a product line. BDSA has also been streamlined to support those projects having tight cost and/or schedule constraints for their failure analysis efforts. We discuss lessons learned from practice, describe available tools, and identi@ some future directions for the topic. A substantial amount of research has been devoted to estimating the number of failures that a software system will experience during test and operations, as well as the number of faults that have been inserted into that system during its development. One of us has found that the amount of structural change to a system during its development is strongly related to the number of faults inserted into it. Using techniques requiring no additional effort on the part of the development organization, the required measurements of structural evolution can be easily obtained from a development effort's configuration management system and readily transformed into an estimate of fault content. So far, structure-fault relationships have been identified for source code; current work seeks to examine artifacts available earlier in the lifecycle to determine if similar relationships between structure and fault content can be found. In particular, relationships between requirements change requests and the number of faults inserted into the implemented system would provide a significant improvement in our ability to control software quality during the early development phases.

fault tree↗
NASA NTRS2008

Enabling and Enhancing Space Mission Success and Reduction of Risk through the Application of an Integrated Data Architecture

The engineering phases of design, development, test, and evaluation (DDT and E) and subsequent planning, preparation, and operation (Ops) of space vehicles in a complex and distributed environment requires massive and continuous flows of information across the enterprise and across temporal stages of the vehicle lifecycle. The resulting capabilities at each subsequent stage depend in part on the capture, preparation, storage, and subsequent provision of information from prior stages. The United States National Aeronautics and Space Administration (NASA) is currently designing a fleet of new vehicles that will replace the Space Shuttle and expand space operations and exploration capabilities. This includes the 2 stage human rated lift vehicle Ares 1 and its associated crew vehicle the Orion, and a service module; the heavy lift cargo vehicle, Ares 5, and an associated cargo stage known as the Earth Departure Stage; and a Lunar Lander vehicle that contains a descent stage, and ascent stage, and a habitation module. A variety of concurrent assorted ground operations infrastructure including software and facilities are also being developed, assorted technology and assembly designs and development for equipment such as EVA suits, life support systems, command and control technologies are also in the pipeline. The development is occurring in a distributed manner, with project deliverables being contributed by a large and diverse assortment of vendors and most space faring nations. Critical information about all of the components, software, and procedures must be shared during the DDT and E phases and then made readily available to the mission operations staff for access during the planning, preparation, and operations phases, and also need to be readily available for system to system interactions. The Constellation Data Systems Project (CxDS) is identifying the needs, and designing and deploying systems and processes to support these needs. This paper details the steps and processes that NASA is applying within the Constellation Program to manage this data and information, and to insure that the correct information is available, correctly annotated, and can be provisioned digitally to enhance response times, and support engineering analysis and anomaly resolution.

Brummett, Robert C.↗
NASA NTRS2005

Development of the Architectural Simulation Model for Future Launch Systems and its Application to an Existing Launch Fleet

A significant portion of lifecycle costs for launch vehicles are generated during the operations phase. Research indicates that operations costs can account for a large percentage of the total life-cycle costs of reusable space transportation systems. These costs are largely determined by decisions made early during conceptual design. Therefore, operational considerations are an important part of vehicle design and concept analysis process that needs to be modeled and studied early in the design phase. However, this is a difficult and challenging task due to uncertainties of operations definitions, the dynamic and combinatorial nature of the processes, and lack of analytical models and the scarcity of historical data during the conceptual design phase. Ultimately, NASA would like to know the best mix of launch vehicle concepts that would meet the missions launch dates at the minimum cost. To answer this question, we first need to develop a model to estimate the total cost, including the operational cost, to accomplish this set of missions. In this project, we have developed and implemented a discrete-event simulation model using ARENA (a simulation modeling environment) to determine this cost assessment. Discrete-event simulation is widely used in modeling complex systems, including transportation systems, due to its flexibility, and ability to capture the dynamics of the system. The simulation model accepts manifest inputs including the set of missions that need to be accomplished over a period of time, the clients (e.g., NASA or DoD) who wish to transport the payload to space, the payload weights, and their destinations (e.g., International Space Station, LEO, or GEO). A user of the simulation model can define an architecture of reusable or expendable launch vehicles to achieve these missions. Launch vehicles may belong to different families where each family may have it own set of resources, processing times, and cost factors. The goal is to capture the required resource levels of the major launch elements and their required facilities. The model s output can show whether or not a certain architecture of vehicles can meet the launch dates, and if not, how much the delay cost would be. It will also produce aggregate figures of missions cost based on element procurement cost, processing cost, cargo integration cost, delay cost, and mission support cost. One of the most useful features of this model is that it is stochastic where it accepts statistical distributions to represent the processing times mimicking the stochastic nature of real systems.

Rabadi, Ghaith↗