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 91 records · Page 5
All sourcesNASA NTRSDOE OSTI
NASA NTRS2017

Early Warning Look Ahead Metrics: The Percent Milestone Backlog Metric

All complex development projects experience delays and corresponding backlogs of their project control milestones during their acquisition lifecycles. NASA Goddard Space Flight Center (GSFC) Flight Projects Directorate (FPD) teamed with The Aerospace Corporation (Aerospace) to develop a collection of Early Warning Look Ahead metrics that would provide GSFC leadership with some independent indication of the programmatic health of GSFC flight projects. As part of the collection of Early Warning Look Ahead metrics, the Percent Milestone Backlog metric is particularly revealing, and has utility as a stand-alone execution performance monitoring tool. This paper describes the purpose, development methodology, and utility of the Percent Milestone Backlog metric. The other four Early Warning Look Ahead metrics are also briefly discussed. Finally, an example of the use of the Percent Milestone Backlog metric in providing actionable insight is described, along with examples of its potential use in other commodities.

acquisition lifecycles↗
NASA NTRSDate not supplied

Lean Model-Based Systems Engineering on the NASA High-Density Vertiplex Subproject

The High Density Vertiplex (HDV) subproject of NASA’s Advanced Air Mobility (AAM) project adopted Model-Based Systems Engineering (MBSE)in July of 2020, prior to subproject formulation. A small and lean team of HDV Systems Engineers(SE) are utilizing MagicDraw to execute NASA SE processes via MBSE. The SEs learned how to use MagicDraw from scratch and HDV is the first project for which the SEs have utilized MagicDraw. This paper will demonstrate project technical execution via MBSE, utilizing the digital elements built into the SysML (Systems Modeling Language). SysML provides a model-centric means of carrying out the NASA SE common technical processes by providing tools for complete system modeling, including requirements and interface management and design capture. The authors also leverage and extend SysML to perform other SE tasks, such as Verification and Validation (V&V)tracking. MBSE has two main purposes for HDV: 1) documenting the subproject’s logical architecture for distribution outside of the subproject, 2) capturing the subproject’s physical architecture in a single-source-of-truth for use by the subproject’s members. This paper details the challenges, lessons learned, and solutions that were encountered in implementing MBSE in the first iteration on a multi-iteration, full-lifecycle design, build, fly project.

Demetrios Katsaduros↗
NASA NTRSDate not supplied

Lean Model-Based Systems Engineering on the NASA High-Density Vertiplex Subproject

The High Density Vertiplex (HDV) subproject of NASA’s Advanced Air Mobility (AAM) project adopted Model-Based Systems Engineering (MBSE) in July of 2020, prior to subproject formulation. A small and lean team of HDV Systems Engineers (SE) are utilizing MagicDraw to execute NASA SE processes via MBSE. The SEs learned how to use MagicDraw from scratch and HDV is the first project for which the SEs have utilized MagicDraw. This presentation will demonstrate project technical execution via MBSE, utilizing the digital elements built into the SysML (Systems Modeling Language). SysML provides a model-centric means of carrying out the NASA SE common technical processes by providing tools for complete system modeling, including requirements and interface management and design capture. The authors also leverage and extend SysML to perform other SE tasks, such as Verification and Validation (V&V) tracking. MBSE has two main purposes for HDV: 1) documenting the subproject’s logical architecture for distribution outside of the subproject, 2) capturing the subproject’s physical architecture in a single-source-of-truth for use by the subproject’s members. This presentation details the challenges, lessons learned, and solutions that were encountered in implementing MBSE in the first iteration on a multi-iteration, full-lifecycle design, build, fly project.

systems engineering↗
NASA NTRS2016

Towards a Methodology and Tooling for Model-Based Probabilistic Risk Assessment (PRA)

A Probabilistic Risk Assessment (PRA) aims to identify and assess potential risks to system technical performance requirements for the purpose of furnishing risk insights into project decisions. PRAs have traditionally been conducted manually using software with an isolated data model. As system complexity rises it becomes difficult to ensure consistency between a PRA, the evolving system design, and other engineering analyses; the techniques for conducting PRAs must evolve to meet this challenge. This work presents progress towards a methodology and tooling for conducting a PRA by leveraging data in the system model, embedded for other purposes and analyses, to conduct a PRA. An approach for identifying the appropriate probabilistic equation for each risk scenario from a standard library is presented, which is a significant step towards the quantification of the likelihood of a risk scenario occurrence. The final calculation of the likelihood of occurrence is left as an item of future work. We also present the development of preliminary tooling to carry out the methodology on a well-formed system model. The information needed to conduct the PRA is embedded in a consistent manner in a system model, so the model-based PRA can be regularly executed as the system model changes. The ability to modify the PRA in concert with lifecycle evolution affords a project the opportunity to track the extent to which system modification impacts compliance with requirements. These aspects of this model-based PRA methodology make it capable of managing risk in increasingly complex technical systems.

Schreiner, Samuel S.↗
DOE OSTI2025

Driving Economics and Reducing Risks: The Business Case for Security-by-Design in Nuclear Power

This report provides an analysis of the financial, operational, and strategic advantages of incorporating Security-by-Design (SeBD) early in the lifecycle of nuclear power plant projects. By framing security as a foundational design element rather than a late-stage add-on, owners, vendors, and operators can reduce budget overruns, strengthen regulatory compliance, and increase revenue opportunities. The report details key lifecycle phases, highlighting the strategic imperative for organizations (including project developers, investors, vendors, and regulators) to adopt SeBD. Drawing on industry estimates, real-world case studies, and comparative cost analyses, the findings underscore that even a modest upfront investment in SeBD can yield substantial long-term returns by preventing costly retrofit activities, minimizing regulatory delays, and positioning nuclear vendors for the ability to adapt in the evolving security market. By avoiding excessive retrofit expenses and positioning security as a built-in feature rather than an afterthought, nuclear projects can protect their financial performance, enhance public trust, and secure a competitive edge in an increasingly complex global energy market. The authors advocate for SeBD’s strategic implementation, supported by established quality management methodologies, thereby promoting continuous improvement and defect avoidance. Ultimately, early SeBD integration represents a strategic investment, yielding significant returns by preventing costly retrofits and positioning nuclear projects for enhanced competitiveness and public trust.

22 GENERAL STUDIES OF NUCLEAR REACTORS↗
NASA NTRS2003

Case for Deploying Complex Systems Utilizing Commodity Components

When the International Space Station (ISS) finally reached an operational state, many of the Payload Operations and Integration Facility (POIF) hardware components were reaching end of life, COTS product costs were soaring, and the ISS budget was becoming severely constrained. However, most requirement development was complete. In addition, the ISS program is a fully functioning program with at least fifteen years of operational life remaining. Therefore it is critical that any upgrades, refurbishments, or enhancements be accomplished in realtime with minimal disruptions to service. For these and other reasons, it was necessary to ensure the viability of the POIF. Due to the to the breadth of capability of the POIF (a NASA ground station), it is believed that the lessons to be learned by other complex systems are applicable and any solutions garnered by the POIF are applicable to other complex systems as well. With that in mind, a number of new approaches have been investigated to increase the portability of the POIF and reduce the cost of refurbishment, operations, and maintenance. These new approaches were directed at the Total Cost of Ownership (TCO); not only the refurbishment but also current operational difficulties, licensing, and anticipation of the next refurbishment. Our basic premise is that technology had evolved dramatically since the concept of the POIF ground system and we should leverage our experience on this new technological landscape. Fortunately, Moore's law and market forces have changed the landscape considerably. These changes are manifest in five (5) ways that are particularly relevant to POIF: 1. Complex Instruction Set Computing (CISC) processors have advanced to unprecedented levels of compute capacity with a dramatic cost break, 2. Linux has become a major operating system supported by most vendors on a broad range of platforms, 3. Windows(TradeMark) based desktops are pervasive in the office environment, 4. Stable and affordable WindowsTM development environments and tools are available and offer a rich set of capabilities, 5. The WindowsTM 2000 provides a stable client platform, Therefore, five studies were proposed, developed, and are in the current process of deployment which dramatically reduces the cost of operations, maintenance, refurbishment, and deployment of a ground system. Restating and refining the basic premise stated earlier, it is possible to enhance operations through the replacement of hardware and software components with commodity based items wherever applicable. This will dramatically reduce the overall lifecycle cost of the project. The first study leveraged the POIF S secure, three-tier, web architecture to replace the client workstations with lower cost PC platforms. A second study initiated a review of COTS products to examine the level of added value of each product. This study included replacement of some COTS products with custom code, deletions, substitutions, and consolidation of COTS products. Studies three and four reviewed the server architectures of the data distribution systems and Enhanced HOSC System (EHS) command and telemetry system to propose migration to new platforms, both software and hardware. The final study reviewed current IP communication technologies, developed an operational model for flight operations, and demonstrated that voice over IP was practical and could be integrated into operations.

Bryant, Barry S.↗
NASA NTRS2018

Developing a Standard for Earth Observation Data Preservation Content - A Path to Future Usability

For datasets to be usable, many pieces of information in addition to the data themselves are essential. During the active parts of the lifecycle of dataset generating projects, the needed information is usually accessible through individuals familiar with the various aspects of the projects. However, the utility of datasets tends to outlive the lives of projects, by several decades in many cases. Thus it is essential to capture all the relevant information about the datasets, data, metadata and associate knowledge that is sufficient to read, understand, interpret and reuse the datasets, while the projects are still active. The capture and preservation should be such that the data are usable when no consultation is available from the original project participants. Identification of specific categories of content through an international standard is beneficial to the user communities of the future, so that projects involving Earth observations and generating data products can consistently plan for preservation and future usability of the project outcomes. While there are existing standards that address archival and preservation in general, there are no existing international standards or specifications today to address what content should be preserved. The standard, ISO 19165-1, titled "Geographic Information - Preservation of digital data and metadata Part 1: Fundamentals" considers geographic information preservation in general. It acknowledges that "specific content items needed to preserve the full provenance and context of the data and associated metadata depend on the needs of the designated community and types of datasets (e.g., maps, remotely sensed data from satellites and airborne instruments, physical samples). Follow-up parts to this standard may be developed detailing content items appropriate to individual disciplines." NASA proposed an extension to this standard, titled "Geographic information -- Preservation of digital data and metadata -- Part 2: Content specifications for Earth observation data and derived digital products." The development of this extension is in progress with participation by an international team representing nine countries. The purpose of this paper is to introduce this standard and report on its status.

Remote Sensing; Data Systems; Open Data;↗
NASA NTRS2013

Project Morpheus: Lessons Learned in Lander Technology Development

NASA's Morpheus Project has developed and tested a prototype planetary lander capable of vertical takeoff and landing, that is designed to serve as a testbed for advanced spacecraft technologies. The lander vehicle, propelled by a LOX/Methane engine and sized to carry a 500kg payload to the lunar surface, provides a platform for bringing technologies from the laboratory into an integrated flight system at relatively low cost. Designed, developed, manufactured and operated in-house by engineers at Johnson Space Center, the initial flight test campaign began on-site at JSC less than one year after project start. After two years of testing, including two major upgrade periods, and recovery from a test crash that caused the loss of a vehicle, flight testing will evolve to executing autonomous flights simulating a 500m lunar approach trajectory, hazard avoidance maneuvers, and precision landing, incorporating the Autonomous Landing and Hazard Avoidance (ALHAT) sensor suite. These free-flights are conducted at a simulated planetary landscape built at Kennedy Space Center's Shuttle Landing Facility. The Morpheus Project represents a departure from recent NASA programs and projects that traditionally require longer development lifecycles and testing at remote, dedicated testing facilities. This paper expands on the project perspective that technologies offer promise, but capabilities offer solutions. It documents the integrated testing campaign, the infrastructure and testing facilities, and the technologies being evaluated in this testbed. The paper also describes the fast pace of the project, rapid prototyping, frequent testing, and lessons learned during this departure from the traditional engineering development process at NASA's Johnson Space Center.

Olansen, Jon B.↗
NASA NTRS2001

ASK Magazine

Not everyone looks forward to reviews. Dog and pony shows I've heard them called. Exercises in putting together Power Point charts. Other less tasteful descriptions abound, but I won't bother to summarize these. This is a tasteful magazine after all. In this issue, we've assembled a number of articles on the subject of reviews, particularly as they occur in the NASA project world (although we cover the subject from other perspectives too). Veteran NASA Project Manager Marty Davis, in his article Tangled Up in Reviews, writes, "Many people regard reviews as something onerous, but if we can tailor them so that they're not as bad as they have to be, it can be a great benefit to a project manager." Great benefits to the project manager is what you'll find in Marty's story as he describes not only tailoring a single review but the entire lifecycle of reviews in his project. In Jo Gunderson's story, Calling Down the Fire on Yourself, she describes a young NASA Project Manager who does just that because, as he tells her, I needed to know if there was anything that I had overlooked." How he brings fire down on himself at his project review will inspire other young Project Managers, seasoned managers, and anyone else who reads this powerful story. Leave Your Ego at the Door, by Jenny Baer-Reidhart and Ray Morgan, uses reviews to highlight the creative collaboration that existed between NASA and one of its industry partners. The protagonist of this story is a company who took advantage of NASAs expert advice during reviews and accomplished amazing feats as a result. The story also examines how disasters might well have been avoided by two other NASA partners had they been as open-minded as the first company during their reviews. In Roy Malone's story, Standing Offer, a NASA Project Manager describes how he used a crack review team to help him pass a critical certification inspection while he was a Combat Systems Officer in the Navy. Malone invited the reviewers to come back several times so that they would be able to focus in detail on the many areas of the program that would be scrutinized during the certification inspection. These are just a sampling of some of the articles you'll find in this issue of ASK. We believe this issue offers ample evidence that talented Project Managers know how to use reviews to the great benefit of their projects. A talented Project Manager will typically figure out a way to turn any onerous task into a useful learning exercise. These Project Managers demonstrate that the real value of reviews is that they provide a chance to learn something. No dog and pony shows here.

Laufer, Alexander↗
NASA NTRS2019

Requirements Development and Management on the Psyche Project

In January 2017, Psyche was one of two mission concepts selected by NASA for flight as part of the 14th Discovery mission competition. The project has been staffing up and maturing the spacecraft, instrument and mission system baseline designs on the path towards a 2022 launch. During much of 2018, the Project has been executing the lifecycle stage called Phase B, “Preliminary Design and Technology Completion,” one key element of which is the development and management of requirements at various levels. In the case of the Psyche project, this process has been particularly unique for several reasons. The project utilizes a Solar Electric Propulsion (SEP) Chassis from Space Systems Loral (SSL), a high volume manufacturer of commercial geostationary (GEO) telecom spacecraft based on the 1300 satellite bus. While SSL has an extensive, well-vetted set of requirements based on their very successful Earth-orbiting product line, translating that heritage to a deep space science mission required special care. In addition to the differences associated with the deep space environment and longer communication times, new interfaces had to be incorporated. While a substantial portion of the Flight System consists of the SEP Chassis, there were several new interfaces within various subsystems between SSL components and those provided by JPL and other contractors. Managing these interfaces through requirements at a relatively higher level than normally seen on internal or external builds proved challenging. Finally, the Psyche spacecraft plans to host the flight terminal of the Deep Space Optical Communications (DSOC) technology demonstration, which is itself a separate project with its own requirements that must be flowed down and managed. This paper will present an overview of the requirement development and management process for the Psyche project. It will discuss in detail the various challenges summarized above, the methods and decisions chosen to address them, and evaluate their overall effectiveness at this stage in the project.

Elkins-Tanton, Linda T.↗
NASA NTRS2011

Cost Model Comparison: A Study of Internally and Commercially Developed Cost Models in Use by NASA

NASA makes use of numerous cost models to accurately estimate the cost of various components of a mission - hardware, software, mission/ground operations - during the different stages of a mission's lifecycle. The purpose of this project was to survey these models and determine in which respects they are similar and in which they are different. The initial survey included a study of the cost drivers for each model, the form of each model (linear/exponential/other CER, range/point output, capable of risk/sensitivity analysis), and for what types of missions and for what phases of a mission lifecycle each model is capable of estimating cost. The models taken into consideration consisted of both those that were developed by NASA and those that were commercially developed: GSECT, NAFCOM, SCAT, QuickCost, PRICE, and SEER. Once the initial survey was completed, the next step in the project was to compare the cost models' capabilities in terms of Work Breakdown Structure (WBS) elements. This final comparison was then portrayed in a visual manner with Venn diagrams. All of the materials produced in the process of this study were then posted on the Ground Segment Team (GST) Wiki.

cost models↗
NASA NTRS2013

Workflow-Based Software Development Environment

The Software Developer's Assistant (SDA) helps software teams more efficiently and accurately conduct or execute software processes associated with NASA mission-critical software. SDA is a process enactment platform that guides software teams through project-specific standards, processes, and procedures. Software projects are decomposed into all of their required process steps or tasks, and each task is assigned to project personnel. SDA orchestrates the performance of work required to complete all process tasks in the correct sequence. The software then notifies team members when they may begin work on their assigned tasks and provides the tools, instructions, reference materials, and supportive artifacts that allow users to compliantly perform the work. A combination of technology components captures and enacts any software process use to support the software lifecycle. It creates an adaptive workflow environment that can be modified as needed. SDA achieves software process automation through a Business Process Management (BPM) approach to managing the software lifecycle for mission-critical projects. It contains five main parts: TieFlow (workflow engine), Business Rules (rules to alter process flow), Common Repository (storage for project artifacts, versions, history, schedules, etc.), SOA (interface to allow internal, GFE, or COTS tools integration), and the Web Portal Interface (collaborative web environment

Izygon, Michel E.↗
NASA NTRSDate not supplied

Developing and Validating Measurement Scales During Pandemic Conditions: A Case Study with the Scale for Habitat Usability

At NASA, habitat evaluations often employ subjective measures. Some measures are frequently used, well established tools, whereas others are homegrown measures tailored to specific projects. The variety of measures used makes evaluation comparisons across projects difficult. Additionally, some of these measures are burdensome, may be too specialized, or may require an expert to use and interpret, limiting their utility. Taken together, these drawbacks suggest the need for a new measurement tool. To that purpose, a team at NASA worked on developing a new scale for measuring habitat usability, the Scale for Habitat Usability (SHU). The SHU is intended to be a quick, multi-faceted measure for evaluating habitat usability across the development lifecycle. However, like many research projects, the development of the SHU faced setbacks due to the COVID-19 pandemic. Pandemic prevention protocols precluded in-person data collection, forcing the team to take some non-traditional approaches to scale development. This paper reports the steps the team took to complete the project.

Ian Robertson↗
NASA NTRS2014

The OSIRIS-Rex Asteroid Sample Return: Mission Operations Design

The OSIRIS-REx mission employs a methodical, phased approach to ensure success in meeting the missions science requirements. OSIRIS-REx launches in September 2016, with a backup launch period occurring one year later. Sampling occurs in 2019. The departure burn from Bennu occurs in March 2021. On September 24, 2023, the SRC lands at the Utah Test and Training Range (UTTR). Stardust heritage procedures are followed to transport the SRC to Johnson Space Center, where the samples are removed and delivered to the OSIRIS-REx curation facility. After a six-month preliminary examination period the mission will produce a catalog of the returned sample, allowing the worldwide community to request samples for detailed analysis.Traveling and returning a sample from an Asteroid that has not been explored before requires unique operations consideration. The Design Reference Mission (DRM) ties together space craft, instrument and operations scenarios. The project implemented lessons learned from other small body missions: APLNEAR, JPLDAWN and ESARosetta. The key lesson learned was expected the unexpected and implement planning tools early in the lifecycle. In preparation to PDR, the project changed the asteroid arrival date, to arrive one year earlier and provided additional time margin. STK is used for Mission Design and STKScheduler for instrument coverage analysis.

0↗
DOE OSTI2026

JGI Archive and Metadata Organizer (JAMO) v2.0.0

JAMO (JGI Archive and Metadata Organizer) helps researchers keep large collections of scientific files organized, findable, and safe. It lets you submit files with consistent, template-driven metadata, bundle related files into sets, and track them as a group instead of one by one. As data ages, JAMO automatically moves it from fast disk to cost-saving tape and can bring it back when needed, keeping storage lean without losing access. A simple web/CLI workflow supports submitting, checking status, retrying, and updating metadata. Compared with generic storage, JAMO's strengths are: clear, searchable metadata tuned for science; set-level organization that mirrors real projects; and built-in lifecycle care (archive, purge, restore) so you don't have to manage those steps yourself.

Cassol, Daniela [Lawrence Berkeley National Labora↗
NASA NTRS1994

SCOS 2: An object oriented software development approach

The Spacecraft Control and Operations System 2 (SCOS 2), is intended to provide the generic mission control system infrastructure for future ESA missions. It represents a bold step forward in order to take advantage of state-of-the-art technology and current practices in the area of software engineering. Key features include: (1) use of object oriented analysis and design techniques; (2) use of UNIX, C++ and a distributed architecture as the enabling implementation technology; (3) goal of re-use for development, maintenance and mission specific software implementation; and (4) introduction of the concept of a spacecraft control model. This paper touches upon some of the traditional beliefs surrounding Object Oriented development and describes their relevance to SCOS 2. It gives rationale for why particular approaches were adopted and others not, and describes the impact of these decisions. The development approach followed is discussed, highlighting the evolutionary nature of the overall process and the iterative nature of the various tasks carried out. The emphasis of this paper is on the process of the development with the following being covered: (1) the three phases of the SCOS 2 project - prototyping & analysis, design & implementation and configuration / delivery of mission specific systems; (2) the close cooperation and continual interaction with the users during the development; (3) the management approach - the split between client staff, industry and some of the required project management activities; (4) the lifecycle adopted being an enhancement of the ESA PSS-05 standard with SCOS 2 specific activities and approaches defined; and (5) an examination of some of the difficulties encountered and the solutions adopted. Finally, the lessons learned from the SCOS 2 experience are highlighted, identifying those issues to be used as feedback into future developments of this nature. This paper does not intend to describe the finished product and its operation, but focusing on the journey to arrive there, concentrating therefore on the process and not the products of the SCOS 2 software development.

Symonds, Martin↗
NASA NTRS2001

Evaluation of Cirrus Cloud Simulations Using ARM Data - Development of a Case Study Data Set

Cloud-resolving models (CRMs) provide an effective linkage in terms of parameters and scales between observations and the parametric treatments of clouds in global climate models (GCMs). They also represent the best understanding of the physical processes acting to determine cloud system lifecycle. The goal of this project is to improve state-of-the-art CRMs used for studies of cirrus clouds and to establish a relative calibration with GCMs through comparisons among CRMs, single column model (SCM) versions of the GCMs, and observations. This project will compare and evaluate a variety of CRMs and SCMs, under the auspices of the GEWEX Cloud Systems Study (GCSS) Working Group on Cirrus Cloud Systems (WG2), using ARM data acquired at the Southern Great Plains (SGP) site. This poster will report on progress in developing a suitable WG2 case study data set based on the September 26, 1996 ARM IOP case - the Hurricane Nora outflow case. The environmental data (input) will be described as well as the wealth of validating cloud observations. We plan to also show results of preliminary simulations. The science questions to be addressed derive significantly from results of the GCSS WG2 cloud model comparison projects, which will be briefly summarized.

O'C.Starr, David↗
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.

Deep Impact Mission↗