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

Modifying the Heliophysics Data Policy to Better Enable Heliophysics Research

The Heliophysics (HP) Science Data Management Policy, adopted by HP in June 2007, has helped to provide a structure for the HP data lifecycle. It provides guidelines for Project Data Management Plans and related documents, initiates Resident Archives to maintain data services after a mission ends, and outlines a route to the unification of data finding, access, and distribution through Virtual observatories. Recently we have filled in missing pieces that assure more coherence and a home for the VxOs (through the 'Heliophsyics Data and Model Consortium'), and provide greater clarity with respect to long term archiving. In particular, the new policy which has been vetted with many community members, details the 'Final Archives' that are to provide long-term data access. These are distinguished from RAs in that they provide little additional service beyond servicing data, but critical to their success is that the final archival materials include calibrated data in useful formats such as one finds in CDAWeb and various ASCII or FITS archives. Having a clear goal for legacy products, to be detailed as part of the Mission Archives Plans presented at Senior Reviews, will help to avoid the situation so common in the past of having archival products that preserve bits well but not readily usable information. We hope to avoid the need for the large numbers of 'data upgrade' projects that have been necessary in recent years.

Hayes, Jeffrey↗
NASA NTRS2009

Probabilistic Risk Assessment for Decision Making During Spacecraft Operations

Decisions made during the operational phase of a space mission often have significant and immediate consequences. Without the explicit consideration of the risks involved and their representation in a solid model, it is very likely that these risks are not considered systematically in trade studies. Wrong decisions during the operational phase of a space mission can lead to immediate system failure whereas correct decisions can help recover the system even from faulty conditions. A problem of special interest is the determination of the system fault protection strategies upon the occurrence of faults within the system. Decisions regarding the fault protection strategy also heavily rely on a correct understanding of the state of the system and an integrated risk model that represents the various possible scenarios and their respective likelihoods. Probabilistic Risk Assessment (PRA) modeling is applicable to the full lifecycle of a space mission project, from concept development to preliminary design, detailed design, development and operations. The benefits and utilities of the model, however, depend on the phase of the mission for which it is used. This is because of the difference in the key strategic decisions that support each mission phase. The focus of this paper is on describing the particular methods used for PRA modeling during the operational phase of a spacecraft by gleaning insight from recently conducted case studies on two operational Mars orbiters. During operations, the key decisions relate to the commands sent to the spacecraft for any kind of diagnostics, anomaly resolution, trajectory changes, or planning. Often, faults and failures occur in the parts of the spacecraft but are contained or mitigated before they can cause serious damage. The failure behavior of the system during operations provides valuable data for updating and adjusting the related PRA models that are built primarily based on historical failure data. The PRA models, in turn, provide insight into the effect of various faults or failures on the risk and failure drivers of the system and the likelihood of possible end case scenarios, thereby facilitating the decision making process during operations. This paper describes the process of adjusting PRA models based on observed spacecraft data, on one hand, and utilizing the models for insight into the future system behavior on the other hand. While PRA models are typically used as a decision aid during the design phase of a space mission, we advocate adjusting them based on the observed behavior of the spacecraft and utilizing them for decision support during the operations phase.

dynamic fault trees↗
NASA NTRS2006

Deep impact sequence planning using multi-mission adaptable planning tools with integrated spacecraft models

The Deep Impact mission was ambitious and challenging. JPL's well proven, easily adaptable multi-mission sequence planning tools combined with integrated spacecraft subsystem models enabled a small operations team to develop, validate, and execute extremely complex sequence-based activities within very short development times. This paper focuses on the core planning tool used in the mission, APGEN. It shows how the multi-mission design and adaptability of APGEN made it possible to model spacecraft subsystems as well as ground assets throughout the lifecycle of the Deep Impact project, starting with models of initial, high-level mission objectives, and culminating in detailed predictions of spacecraft behavior during mission-critical activities.

Seybold, Calina C.↗
NASA NTRS2008

Problem Reporting System

The Problem Reporting System (PRS) is a Web application, running on two Web servers (load-balanced) and two database servers (RAID-5), which establishes a system for submission, editing, and sharing of reports to manage risk assessment of anomalies identified in NASA's flight projects. PRS consolidates diverse anomaly-reporting systems, maintains a rich database set, and incorporates a robust engine, which allows tracking of any hardware, software, or paper process by configuring an appropriate life cycle. Global and specific project administration and setup tools allow lifecycle tailoring, along with customizable controls for user, e-mail, notifications, and more. PRS is accessible via the World Wide Web for authorized user at most any location. Upon successful log-in, the user receives a customizable window, which displays time-critical 'To Do' items (anomalies requiring the user s input before the system moves the anomaly to the next phase of the lifecycle), anomalies originated by the user, anomalies the user has addressed, and custom queries that can be saved for future use. Access controls exist depending on a user's role as system administrator, project administrator, user, or developer, and then, further by association with user, project, subsystem, company, or item with provisions for business-to-business exclusions, limitations on access according to the covert or overt nature of a given project, all with multiple layers of filtration, as needed. Reporting of metrics is built in. There is a provision for proxy access (in which the user may choose to grant one or more other users to view screens and perform actions as though they were the user, during any part of a tracking life cycle - especially useful during tight build schedules and vacations to keep things moving). The system also provides users the ability to have an anomaly link to or notify other systems, including QA Inspection Reports, Safety, GIDEP (Government-Industry Data Exchange Program) Alert, Corrective Actions, and Lessons Learned. The PRS tracking engine was designed as a very extensible and scalable system, able to support additional applications, with future development possibilities already discussed, including Incident Surprise Anomalies (for anomalies occurring during Operations phases of NASA Flight projects), GIDEP and NASA Alerts, and others.

Potter, Don↗
NASA NTRS2011

Morpheus Lander Testing Campaign

NASA s Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing designed to serve as a testbed for advanced spacecraft technologies. The Morpheus vehicle has successfully performed a set of integrated vehicle test flights including hot-fire and tether tests, ultimately culminating in an un-tethered "free-flight" This development and testing campaign was conducted on-site at the Johnson Space Center (JSC), less than one year after project start. Designed, developed, manufactured and operated in-house by engineers at JSC, the Morpheus Project represents an unprecedented departure from recent NASA programs and projects that traditionally require longer development lifecycles and testing at remote, dedicated testing facilities. This paper documents the integrated testing campaign, including descriptions of test types (hot-fire, tether, and free-flight), test objectives, and the infrastructure of JSC testing facilities. A major focus of the paper will be the fast pace of the project, rapid prototyping, frequent testing, and lessons learned from this departure from the traditional engineering development process at NASA s Johnson Space Center.

Hart, Jeremy J.↗
NASA NTRS2012

Key Decision Record Creation and Approval Module

Retaining good key decision records is critical to ensuring the success of a project or operation. Having adequately documented decisions with supporting documents and rationale can greatly reduce the amount of rework or reinvention over a project's, vehicle's, or facility's lifecycle. Stennis Space Center developed and uses a software tool that automates the Key Decision Record (KDR) process for its engineering and test projects. It provides the ability for a user to log key decisions that are made during the course of a project. By customizing Parametric Technology Corporation's (PTC) Windchill product, the team was able to log all information about a decision, and electronically route that information for approval. Customizing the Windchill product allowed the team to directly connect these decisions to the engineering data that it might affect and notify data owners of the decision. The user interface was created in JSP and Javascript, within the OOTB (Out of the Box) Windchill product, allowing users to create KDRs. Not only does this interface allow users to create and track KDRs, but it also plugs directly into the OOTB ability to associate these decision records with other relevant engineering data such as drawings, designs, models, requirements, or specifications

Hebert, Barrt↗
NASA NTRS2004

A Method for Calculating the Probability of Successfully Completing a Rocket Propulsion Ground Test

Propulsion ground test facilities face the daily challenges of scheduling multiple customers into limited facility space and successfully completing their propulsion test projects. Due to budgetary and schedule constraints, NASA and industry customers are pushing to test more components, for less money, in a shorter period of time. As these new rocket engine component test programs are undertaken, the lack of technology maturity in the test articles, combined with pushing the test facilities capabilities to their limits, tends to lead to an increase in facility breakdowns and unsuccessful tests. Over the last five years Stennis Space Center's propulsion test facilities have performed hundreds of tests, collected thousands of seconds of test data, and broken numerous test facility and test article parts. While various initiatives have been implemented to provide better propulsion test techniques and improve the quality, reliability, and maintainability of goods and parts used in the propulsion test facilities, unexpected failures during testing still occur quite regularly due to the harsh environment in which the propulsion test facilities operate. Previous attempts at modeling the lifecycle of a propulsion component test project have met with little success. Each of the attempts suffered form incomplete or inconsistent data on which to base the models. By focusing on the actual test phase of the tests project rather than the formulation, design or construction phases of the test project, the quality and quantity of available data increases dramatically. A logistic regression model has been developed form the data collected over the last five years, allowing the probability of successfully completing a rocket propulsion component test to be calculated. A logistic regression model is a mathematical modeling approach that can be used to describe the relationship of several independent predictor variables X(sub 1), X(sub 2),..,X(sub k) to a binary or dichotomous dependent variable Y, where Y can only be one of two possible outcomes, in this case Success or Failure. Logistic regression has primarily been used in the fields of epidemiology and biomedical research, but lends itself to many other applications. As indicated the use of logistic regression is not new, however, modeling propulsion ground test facilities using logistic regression is both a new and unique application of the statistical technique. Results from the models provide project managers with insight and confidence into the affectivity of rocket engine component ground test projects. The initial success in modeling rocket propulsion ground test projects clears the way for more complex models to be developed in this area.

Messer, Bradley P.↗
NASA NTRS2006

Human Factors Engineering as a System in the Vision for Exploration

In order to accomplish NASA's Vision for Exploration, while assuring crew safety and productivity, human performance issues must be well integrated into system design from mission conception. To that end, a two-year Technology Development Project (TDP) was funded by NASA Headquarters to develop a systematic method for including the human as a system in NASA's Vision for Exploration. The specific goals of this project are to review current Human Systems Integration (HSI) standards (i.e., industry, military, NASA) and tailor them to selected NASA Exploration activities. Once the methods are proven in the selected domains, a plan will be developed to expand the effort to a wider scope of Exploration activities. The methods will be documented for inclusion in NASA-specific documents (such as the Human Systems Integration Standards, NASA-STD-3000) to be used in future space systems. The current project builds on a previous TDP dealing with Human Factors Engineering processes. That project identified the key phases of the current NASA design lifecycle, and outlined the recommended HFE activities that should be incorporated at each phase. The project also resulted in a prototype of a webbased HFE process tool that could be used to support an ideal HFE development process at NASA. This will help to augment the limited human factors resources available by providing a web-based tool that explains the importance of human factors, teaches a recommended process, and then provides the instructions, templates and examples to carry out the process steps. The HFE activities identified by the previous TDP are being tested in situ for the current effort through support to a specific NASA Exploration activity. Currently, HFE personnel are working with systems engineering personnel to identify HSI impacts for lunar exploration by facilitating the generation of system-level Concepts of Operations (ConOps). For example, medical operations scenarios have been generated for lunar habitation in order to identify HSI requirements for the lunar communications architecture. Throughout these ConOps exercises, HFE personnel are testing various tools and methodologies that have been identified in the literature. A key part of the effort is the identification of optimal processes, methods, and tools for these early development phase activities, such as ConOps, requirements development, and early conceptual design. An overview of the activities completed thus far, as well as the tools and methods investigated will be presented.

Mihriban Whitmore↗
NASA NTRS2006

NASA Software Estimating Tool (N-SET)

The goals of this project are to: Develop an early lifecycle software cost estimation tool leveraging existing data and capabilities Collect additional software data from: a) Jet Propulsion Laboratory; b) Goddard Space Flight Center; and c) Marshall Space Flight Center. Analyze, normalize, evaluate, stratify, and validate data. Create a calibrated, validated, and documented tool initially using available data and subsequently using newly collected data.

cost estimating tools↗
NASA NTRS2019

A Validation Study of the Performance Prediction Methodology of the Early Warning Metrics

Complex projects frequently experience delays and develop backlogs of their project control milestones during the acquisition and development lifecycles. In response, the National Aeronautics and Space Administration (NASA) Goddard Space Flight Center (GSFC) formed an independent group of Subject Matter Experts (SMEs) to monitor the execution performance of GSFC Flight projects and instruments that are under development. The SME team’s objective is to generate data driven performance-based indicators that quantify the degree to which projects are meeting their respective schedule and budget commitments. One of these performance-based indicators, the Early Warning Metrics, provides performance forecasts and insight to project performance relative to historical successful projects. Herein this paper describes the purpose and utility of the Early Warning Metrics. Additionally, the initial prediction method used in the creation of the metrics is described along with its validity and the validity of comparable prediction methods.

Holloman, Sherrica↗
NASA NTRS2004

Autonomous Propulsion System Technology Being Developed to Optimize Engine Performance Throughout the Lifecycle

The goal of the Autonomous Propulsion System Technology (APST) project is to reduce pilot workload under both normal and anomalous conditions. Ongoing work under APST develops and leverages technologies that provide autonomous engine monitoring, diagnosing, and controller adaptation functions, resulting in an integrated suite of algorithms that maintain the propulsion system's performance and safety throughout its life. Engine-to-engine performance variation occurs among new engines because of manufacturing tolerances and assembly practices. As an engine wears, the performance changes as operability limits are reached. In addition to these normal phenomena, other unanticipated events such as sensor failures, bird ingestion, or component faults may occur, affecting pilot workload as well as compromising safety. APST will adapt the controller as necessary to achieve optimal performance for a normal aging engine, and the safety net of APST algorithms will examine and interpret data from a variety of onboard sources to detect, isolate, and if possible, accommodate faults. Situations that cannot be accommodated within the faulted engine itself will be referred to a higher level vehicle management system. This system will have the authority to redistribute the faulted engine's functionality among other engines, or to replan the mission based on this new engine health information. Work is currently underway in the areas of adaptive control to compensate for engine degradation due to aging, data fusion for diagnostics and prognostics of specific sensor and component faults, and foreign object ingestion detection. In addition, a framework is being defined for integrating all the components of APST into a unified system. A multivariable, adaptive, multimode control algorithm has been developed that accommodates degradation-induced thrust disturbances during throttle transients. The baseline controller of the engine model currently being investigated has multiple control modes that are selected according to some performance or operational criteria. As the engine degrades, parameters shift from their nominal values. Thus, when a new control mode is swapped in, a variable that is being brought under control might have an excessive initial error. The new adaptive algorithm adjusts the controller gains on the basis of the level of degradation to minimize the disruptive influence of the large error on other variables and to recover the desired thrust response.

Litt, Jonathan S.↗
NASA NTRS2012

Multi-Mission Power Analysis Tool (MMPAT) Version 3

The Multi-Mission Power Analysis Tool (MMPAT) simulates a spacecraft power subsystem including the power source (solar array and/or radioisotope thermoelectric generator), bus-voltage control, secondary battery (lithium-ion or nickel-hydrogen), thermostatic heaters, and power-consuming equipment. It handles multiple mission types including heliocentric orbiters, planetary orbiters, and surface operations. Being parametrically driven along with its user-programmable features can reduce or even eliminate any need for software modifications when configuring it for a particular spacecraft. It provides multiple levels of fidelity, thereby fulfilling the vast majority of a project s power simulation needs throughout the lifecycle. It can operate in a stand-alone mode with a graphical user interface, in batch mode, or as a library linked with other tools. This software can simulate all major aspects of a spacecraft power subsystem. It is parametrically driven to reduce or eliminate the need for a programmer. Added flexibility is provided through user-designed state models and table-driven parameters. MMPAT is designed to be used by a variety of users, such as power subsystem engineers for sizing power subsystem components; mission planners for adjusting mission scenarios using power profiles generated by the model; system engineers for performing system- level trade studies using the results of the model during the early design phases of a spacecraft; and operations personnel for high-fidelity modeling of the essential power aspect of the planning picture.

Wood, Eric G.↗
DOE OSTI2025

Early Stages in the Lifecycle of Polar Liquid-Bearing Clouds

Stratiform liquid-bearing clouds are ubiquitous over the polar regions, where they are predominantly mixed-phase. These polar clouds induce substantial radiative forcing on the surface and continuously modify the atmospheric thermodynamic budget, with direct implications for the polar ice pack resilience. However, the physical representation of these clouds is still a major challenge for climate models. A significant part of polar liquid-bearing cloud lifecycle is often manifested in a quasi-steady self-sustaining, persistent, and turbulent state, which is driven by longwave cloud radiative cooling and can last for multiple days. This self-sustaining cloud lifecycle stage has been thoroughly investigated in numerous studies, though some of its aspects such as precipitation still lack robust quantification and evaluation. The preceding cloud lifecycle stages, which may last up to several hours, have nonetheless remained widely overlooked. These preceding stages initiate at cloud formation, often in a stable and non-turbulent atmospheric layer and serve as a key junction between cloud persistence and cloud dissipation. These two contrasting cloud lifecycle trajectories pose the question if general circulation models (GCMs) can capture the full lifecycle accurately for the real physical reasons, a necessary condition to improve our confidence in climate projections given the changing polar climate. The purpose of this project was to improve the characterization and understanding of these early stages in the lifecycle of polar stratiform liquid-bearing cloud and to aid their representation in GCMs. This research relied on measurements from the Multidisciplinary drifting Observatory for the Study of Arctic Climate (MOSAiC) field campaign, as well as the observations from the ARM West Antarctic Radiation Experiment (AWARE) and the permanent ARM site at Utqiagvik, North Slope of Alaska (NSA).

58 GEOSCIENCES↗
NASA NTRSDate not supplied

Contracting Quality Early in the Lifecycle Using AS9145 Data Deliverables

Development schedules and a highly dynamic supply chain are a challenge to developers of complex systems produced at low volume. Flaws in designs, parts and materials availability problems, poor manufacturability, and a lack of knowledge about critical items and key process attributes can be realized well before traditional second-party quality assurance activities begin. Supplier audits and product inspections may have little mitigating effect once these foundational problems have been realized. Their impacts can be significant lifecycle disruption, cost overruns, inability to deliver to plan, and even project cancellation. AS9145, Requirements for Advanced Product Quality Planning and Production Part Approval Process, can be used to drive quality engineering practices into early development lifecycles to significantly reduce this late-cycle risk and to reduce the cost of quality overall. Since its initial publication in 2016, it has had very limited adoption by the DoD, no adoption by NASA, and sparse adoption in the aerospace and defense supply chain. A task group within the Aerospace Industries Association's (AIA) Joint Strategic Quality Council (JSQC) identified that both acquirers and suppliers see as AS9145 as a cost-adder and are hesitant to use it as an alternative to late-stage-heavy quality assurance approaches. A lack of prior use creates large capability gaps in request-for-proposal (RFP) teams, proposal teams, suppliers’ quality management systems (QMS), and in experienced personnel executing the early lifecycle approach. To create a more realizable on-ramp for using AS9145 in the space and defense sectors, the AIA JSQC task team created five deliverable requirements descriptions (DRDs) that can be used in a contract to begin to engage both parties in early lifecycle quality engineering and quality assurance activities, that reduce exposure to late-stage cost and schedule collapse due to unidentified risks in design, supply chain, and manufacturability. These DRDs drive the parties to engage in planning and analysis discussions early on to understand what production risks can be known and how they will focus resources based on safety criticality and the key elements of design and construction. The suppliers and acquirers who will produce the data and information required by the DRD will be able to incrementally evolve their QMS and the acquirer will incrementally be able to track and understand the benefits of cost shifting from late to early development phases. A white paper describing this approach and the five recommended DRDs will be published by the AIA in late 2024 or early 2025.

Jeannette Plante↗
NASA NTRS1994

Experience with a Technology Transfer Lifecycle and Implementation of Formal Inspections

In an organization with diverse project support and focus, a technology transfer program will be most successful with support from an advocate who can work to implement new technologies on multiple projects across organizational boundaries. In addition, a strong, ongoing technology transfer program needs to be in place to support training, implementation, metrics analysis, and project and organizational feedback of the new technology.

software technology transfer adoption support orga↗
NASA NTRS1993

Software metrics: The key to quality software on the NCC project

Network Control Center (NCC) Project metrics are captured during the implementation and testing phases of the NCCDS software development lifecycle. The metrics data collection and reporting function has interfaces with all elements of the NCC project. Close collaboration with all project elements has resulted in the development of a defined and repeatable set of metrics processes. The resulting data are used to plan and monitor release activities on a weekly basis. The use of graphical outputs facilitates the interpretation of progress and status. The successful application of metrics throughout the NCC project has been instrumental in the delivery of quality software. The use of metrics on the NCC Project supports the needs of the technical and managerial staff. This paper describes the project, the functions supported by metrics, the data that are collected and reported, how the data are used, and the improvements in the quality of deliverable software since the metrics processes and products have been in use.

Burns, Patricia J.↗
NASA NTRS2006

Advancing the practice of systems engineering at JPL

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

process improvement↗