SEARCH · Search NASA

Results for “Project Schedule”

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.

SourceResearch connectionFrom yearThrough year

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 325 records · Page 18

All sources NASA NTRS DOE OSTI

NASA NTRS2012

An Analysis of Shuttle Crew Scheduling Violations

From the early years of the Space Shuttle program, National Aeronautics and Space Administration (NASA) Shuttle crews have had a timeline of activities to guide them through their time on-orbit. Planners used scheduling constraints to build timelines that ensured the health and safety of the crews. If a constraint could not be met it resulted in a violation. Other agencies of the federal government also have scheduling constraints to ensure the safety of personnel and the public. This project examined the history of Space Shuttle scheduling constraints, constraints from Federal agencies and branches of the military and how these constraints may be used as a guide for future NASA and private spacecraft. This was conducted by reviewing rules and violations with regard to human aerospace scheduling constraints, environmental, political, social and technological factors, operating environment and relevant human factors. This study includes a statistical analysis of Shuttle Extra Vehicular Activity (EVA) related violations to determine if these were a significant producer of constraint violations. It was hypothesized that the number of SCSC violations caused by EVA activities were a significant contributor to the total number of violations for Shuttle/ISS missions. Data was taken from NASA data archives at the Johnson Space Center from Space Shuttle/ISS missions prior to the STS-107 accident. The results of the analysis rejected the null hypothesis and found that EVA violations were a significant contributor to the total number of violations. This analysis could help NASA and commercial space companies understand the main source of constraint violations and allow them to create constraint rules that ensure the safe operation of future human private and exploration missions. Additional studies could be performed to evaluate other variables that could have influenced the scheduling violations that were analyzed.

Bristol, Douglas↗

NASA NTRS1993

Hypertext-Based Design of a User Interface for Scheduling

Operations Mission Planner (OMP) is an ongoing research project at JPL that utilizes Artificial Intelligence techniques to create an intelligent, automated planning and scheduling system. The challenge with a user interface is to 1) present as much information as possible at a given moment and 2) allow the user to quickly navigate through the various types of displays. This paper describes a design which applies the hypertext model to solve user interface problems. The general paradigm is to provide maps and search queries to allow the user to quickly find an interesting conflict or problem. Then allow the user to navigate through the displays in a hypertext fashion.

hypertext↗

NASA NTRS2012

EPOXI and Stardust NExT: The Management Challenges of Two Comet Flybys in Three Months

The EPOXI and Stardust NExT missions were missions of opportunity utilizing the Deep Impact and Stardust spacecraft, respectively. These new missions took advantage of the cost savings of utilizing spacecraft that were already flying for new science investigations. Both were retargeted to fly by an additional comet. EPOXI visited Hartley 2, significantly smaller than the other Jupiter family comets visited previously. Stardust NExT flew by Tempel 1, providing a second look at the comet previously studied by Deep Impact in 2005. Both projects were part of NASA's Discovery Program. In order to further save costs, the projects were combined into a single project office at JPL. This provided some efficiencies due to the similarity of the missions, but having the flybys space only three months apart posed challenges for the project management team to ensure each project was ready for its critical event and ensuring each received the proper support from the management team. The project office relied on an integrated calendar for tracking and scheduling meetings, reviews, and other key events. The project management team also coordinated their availability for both projects to maintain involvement with each team to ensure effective risk identification and management.

NExT (New Exploration of Tempel 1)↗

NASA NTRSDate not supplied

NICS (NASA Instrument Capabilities Study) Instrument Schedule and Cost Study

This paper summarizes work performed on the Flight Projects Directorate Planetary Science Projects Division (PSPD, Code 430) NICS (NASA Instrument Capabilities study) instrument schedule and cost study. Included are a short summary of the original NICS (NASA, 2008), and the design and approach, data collection, analysis, preliminary findings and recommendations from select areas of the current study. The NICS (2008) was chartered by then NASA Chief Engineer Michael Ryschkewitsch and chaired by Goddard Space Flight Center (GSFC) engineer, John Leon. The focus was to identify problem areas in instrument development and, if possible, to offer solutions. In the area of instrument developments, the NICS (2008) identified a lack of resources and authority to successfully manage to instrument cost and schedule requirements; and a lack of critical skills, expertise, and leadership to successfully implement unique (one-of-a-kind) high technology developments (NASA, 2008, pp. 51, 52). Additionally, the NICS (2008) found problems in requirements formulation, reviews and management; unrealistic caps and overly optimistic estimates; and externally directed changes which increased the likelihood of overrunning cost and schedule (NASA, 2008, pp.53, 54). It is noteworthy that NICS findings are consistent with previous studies at the mission level (Robbins, Schmidt & White, 2020). Five years later in 2013, the Instrument Projects Division (IPD) was established to implement and manage instrument projects greater than $20M. The IPD was known as Code 490. Its structure incorporated several of the NICS (2008) recommendations. To see if these incorporated recommendations made a difference, and to identify other potential challenges in instrument developments, two parallel studies were initiated. Originally led by the IPD, now led by the PSPD, and the Instrument and Payload Systems Engineering Branch (IPSE, Code 592), respectively, the instrument schedule and cost study and the instrument technical complexity study began in 2017. Data collection was initiated in 2020 and is on-going. This paper is limited to the IPD/PSPD study. Among other findings, preliminary data indicate IPD/PSPD project management support positively influenced instrument development as related to providing a dedicated level of support staff, including a deputy Instrument Project Manager (dIPM), reducing IPM leadership changes, and providing other project support. Next steps include continued data collection and analysis, and mapping to technical complexity data.

NICS implementation↗

NASA NTRS2015

Effective Schedule and Cost Management as a Product Development Lead

The presentation will be given at the 26th Annual Thermal Fluids Analysis Workshop (TFAWS 2015) hosted by the Goddard SpaceFlight Center (GSFC) Thermal Engineering Branch (Code 545). This course provides best practices, helpful tools and lessons learned for staying on plan and day-to-day management of Subsystem flight development after getting Project approval for your Subsystem schedule and budget baseline.

Schedule↗

DOE OSTI2025

DeepLynx Ecosystem 2025

Poor data integration and governance continue to plague complex engineering projects, resulting in missed cost, schedule, and performance targets. Departments operate in isolated systems with manual data exchange, creating fragmented information that compounds errors and leads to significant delays and cost overruns. The DeepLynx ecosystem addresses these challenges through an open-source, modular data management platform that transforms fragmented project data into an integrated digital thread. Built on a federated microservice architecture, the ecosystem comprises seven specialized tools centered around DeepLynx Nexus, a unified data catalog with hierarchical organization and graph-based navigation capabilities. The ecosystem includes: DeepLynx Stream for real-time timeseries data ingestion from industrial sources; DeepLynx Ingest for governed data uploads with formal review workflows; DeepLynx Lattice for ontology-based entity and relationship extraction; DeepLynx Run for workflow orchestration and secure AI/ML compute; DeepLynx Visualize for 3D digital twin visualization; and DeepLynx Insight for AI-assisted document analysis with traceable, grounded responses. Deployable in cloud, on-premise, or hybrid environments using containerized Docker applications and Helm charts, the DeepLynx ecosystem provides flexible infrastructure that adapts to organizational requirements. By consolidating project data into a unified data lake with role-based access controls and OAuth2 authentication, DeepLynx enables digital thread and digital twin capabilities that improve decision-making, reduce risk, and support complex engineering workflows throughout the project lifecycle.

42 - ENGINEERING↗

NASA NTRS2004

Software for Analyzing Laminar-to-Turbulent Flow Transitions

Software assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures. Examples of such activities are the following: code inspections, unit tests, design reviews, performance analyses, construction of traceability matrices, etc. In practice, software development projects have only limited resources (e.g., schedule, budget, and availability of personnel) to cover the entire development effort, of which assurance is but a part. Projects must therefore select judiciously from among the possible assurance activities. At its heart, this can be viewed as an optimization problem; namely, to determine the allocation of limited resources (time, money, and personnel) to minimize risk or, alternatively, to minimize the resources needed to reduce risk to an acceptable level. The end result of the work reported here is a means to optimize quality-assurance processes used in developing software. This is achieved by combining two prior programs in an innovative manner

Chang, Chau-Lyan↗

NASA NTRS2004

Software for Optimizing Quality Assurance of Other Software

Feather, Martin↗

NASA NTRS2011

NASA Schedule Management Handbook

The purpose of schedule management is to provide the framework for time-phasing, resource planning, coordination, and communicating the necessary tasks within a work effort. The intent is to improve schedule management by providing recommended concepts, processes, and techniques used within the Agency and private industry. The intended function of this handbook is two-fold: first, to provide guidance for meeting the scheduling requirements contained in NPR 7120.5, NASA Space Flight Program and Project Management Requirements, NPR 7120.7, NASA Information Technology and Institutional Infrastructure Program and Project Requirements, NPR 7120.8, NASA Research and Technology Program and Project Management Requirements, and NPD 1000.5, Policy for NASA Acquisition. The second function is to describe the schedule management approach and the recommended best practices for carrying out this project control function. With regards to the above project management requirements documents, it should be noted that those space flight projects previously established and approved under the guidance of prior versions of NPR 7120.5 will continue to comply with those requirements until project completion has been achieved. This handbook will be updated as needed, to enhance efficient and effective schedule management across the Agency. It is acknowledged that most, if not all, external organizations participating in NASA programs/projects will have their own internal schedule management documents. Issues that arise from conflicting schedule guidance will be resolved on a case by case basis as contracts and partnering relationships are established. It is also acknowledged and understood that all projects are not the same and may require different levels of schedule visibility, scrutiny and control. Project type, value, and complexity are factors that typically dictate which schedule management practices should be employed.

Source record↗

NASA NTRS1998

Designing for Change: Minimizing the Impact of Changing Requirements in the Later Stages of a Spaceflight Software Project

In the traditional 'waterfall' model of the software project life cycle, the Requirements Phase ends and flows into the Design Phase, which ends and flows into the Development Phase. Unfortunately, the process rarely, if ever, works so smoothly in practice. Instead, software developers often receive new requirements, or modifications to the original requirements, well after the earlier project phases have been completed. In particular, projects with shorter than ideal schedules are highly susceptible to frequent requirements changes, as the software requirements analysis phase is often forced to begin before the overall system requirements and top-level design are complete. This results in later modifications to the software requirements, even though the software design and development phases may be complete. Requirements changes received in the later stages of a software project inevitably lead to modification of existing developed software. Presented here is a series of software design techniques that can greatly reduce the impact of last-minute requirements changes. These techniques were successfully used to add built-in flexibility to two complex software systems in which the requirements were expected to (and did) change frequently. These large, real-time systems were developed at NASA Langley Research Center (LaRC) to test and control the Lidar In-Space Technology Experiment (LITE) instrument which flew aboard the space shuttle Discovery as the primary payload on the STS-64 mission.

Allen, B. Danette↗

NASA NTRS1992

Scheduling lessons learned from the Autonomous Power System

The Autonomous Power System (APS) project at NASA LeRC is designed to demonstrate the applications of integrated intelligent diagnosis, control, and scheduling techniques to space power distribution systems. The project consists of three elements: the Autonomous Power Expert System (APEX) for Fault Diagnosis, Isolation, and Recovery (FDIR); the Autonomous Intelligent Power Scheduler (AIPS) to efficiently assign activities start times and resources; and power hardware (Brassboard) to emulate a space-based power system. The AIPS scheduler was tested within the APS system. This scheduler is able to efficiently assign available power to the requesting activities and share this information with other software agents within the APS system in order to implement the generated schedule. The AIPS scheduler is also able to cooperatively recover from fault situations by rescheduling the affected loads on the Brassboard in conjunction with the APEX FDIR system. AIPS served as a learning tool and an initial scheduling testbed for the integration of FDIR and automated scheduling systems. Many lessons were learned from the AIPS scheduler and are now being integrated into a new scheduler called SCRAP (Scheduler for Continuous Resource Allocation and Planning). This paper will service three purposes: an overview of the AIPS implementation, lessons learned from the AIPS scheduler, and a brief section on how these lessons are being applied to the new SCRAP scheduler.

Ringer, Mark J.↗

DOE OSTI2025

Powernet in Farms Project

Coordinating behind-the-meter (BTM) distributed energy resources (DERs) is critical to ensuring efficiency and reliability for consumers facing an increasingly variable grid supply. Outside of very controlled environments, however, such coordination of heterogeneous resources at scale has remained a challenge due to harsh field conditions, the lack of adequate communication infrastructure, and the difficulty of modeling the system. The intent of this research was to refine the Powernet system deployed in a California dairy farm to achieve the following objectives: a) validate the results of the previous deployment and b) validate new hypothesis about system performance based on the simulation of the new system. The new system design would reduce the overall system cost, and achieve a payback period of less than 3 years, demonstrating the feasibility of such system and its relevance for a segment not well known for technology advancements in power systems. The new proposed system was significantly cheaper than the original design, which would enable the solution to be cost effective and likely economically viable. However, due to significant delays in project start date which affected funding availability, overlap with prior scheduled mandatory military leave from key members of the project team, and customer drop-out, due to the significant delays, which could not be replaced in time, caused the project to be ended prior to completion.

24 POWER TRANSMISSION AND DISTRIBUTION↗

NASA NTRS2006

Collaborative Scheduling Using JMS in a Mixed Java and .NET Environment

A collaborative framework/environment was proto-typed to prove the feasibility of scheduling space flight missions on NASA's Deep Space Network (DSN) in a distributed fashion. In this environment, effective collaboration relies on efficient communications among all flight mission and DSN scheduling users. There-fore, messaging becomes critical to timely event notification and data synchronization. In the prototype, a rapid messaging system using Java Message Service (JMS) in a mixed Java and .NET environment is established. This scheme allows both Java and .NET applications to communicate with each other for data synchronization and schedule negotiation. The JMS approach we used is based on a centralized messaging scheme. With proper use of a high speed messaging system, all users in this collaborative framework can communicate with each other to generate a schedule collaboratively to meet DSN and projects tracking needs.

scheduling↗

NASA NTRS1975

The Langley Research Center NASA/PERT TIME III

Program provides practical system for total project management in areas of planning, scheduling, resource control, and reporting. It allows use of existing management and administrative tools and processes and is applicable to many types of projects.

Source record↗

NASA NTRS2010

Heritage and Advanced Technology Systems Engineering Lessons Learned from NASA Deep Space Missions

In the design and development of complex spacecraft missions, project teams frequently assume the use of advanced technology systems or heritage systems to enable a mission or reduce the overall mission risk and cost. As projects proceed through the development life cycle, increasingly detailed knowledge of the advanced and heritage systems within the spacecraft and mission environment identifies unanticipated technical issues. Resolving these issues often results in cost overruns and schedule impacts. The National Aeronautics and Space Administration (NASA) Discovery & New Frontiers (D&NF) Program Office at Marshall Space Flight Center (MSFC) recently studied cost overruns and schedule delays for 5 missions. The goal was to identify the underlying causes for the overruns and delays, and to develop practical mitigations to assist the D&NF projects in identifying potential risks and controlling the associated impacts to proposed mission costs and schedules. The study found that optimistic hardware/software inheritance and technology readiness assumptions caused cost and schedule growth for four of the five missions studied. The cost and schedule growth was not found to result from technical hurdles requiring significant technology development. The projects institutional inheritance and technology readiness processes appear to adequately assess technology viability and prevent technical issues from impacting the final mission success. However, the processes do not appear to identify critical issues early enough in the design cycle to ensure project schedules and estimated costs address the inherent risks. In general, the overruns were traceable to: an inadequate understanding of the heritage system s behavior within the proposed spacecraft design and mission environment; an insufficient level of development experience with the heritage system; or an inadequate scoping of the system-wide impacts necessary to implement an advanced technology for space flight applications. The paper summarizes the study's lessons learned in more detail and offers suggestions for improving the project's ability to identify and manage the technology and heritage risks inherent in the design solution.

Barley, Bryan↗

NASA NTRS1998

Distribution of a Generic Mission Planning and Scheduling Toolkit for Astronomical Spacecraft

This 2-year report describes the progress made to date on the project to package and distribute the planning and scheduling toolkit for the SWAS astronomical spacecraft. SWAS was scheduled to be launched on a Pegasus XL vehicle in fall 1995. Three separate failures in the launch vehicle have delayed the SWAS launch. The researchers have used this time to continue developing scheduling algorithms and GUI design. SWAS is expected to be launched this year.

Kleiner, Steven C.↗

NASA NTRS2002

An Evaluation of the ROSE System

A request-oriented scheduling engine, better known as ROSE, is under development within the Flight Projects Directorate for the purpose of planning and scheduling of the activities and resources associated with the science experiments to be performed aboard the International Space Station (ISS). ROSE is being designed to incrementally process requests from payload developers (PDs) to model and schedule the execution of their science experiments on the ISS. The novelty of the approach comes from its web-based interface permitting the PDs to define their request via the construction of a graphical model to represent their requirements. Based on an examination of the current ROSE implementation, this paper proposes several recommendations for changes to the modeling component and makes mention of other potential applications of the ROSE system.

John M. Usher↗

NASA NTRS2016

Contribution of Schedule Delays to Cost Growth: How to Make Peace with a Marching Army

Numerous research papers have shown that cost and schedule growth are interrelated for NASA space science missions. Although there has shown to be a strong correlation of cost growth with schedule growth, it is unclear what percentage of cost growth is caused by schedule growth and how schedule growth can be controlled. This paper attempts to quantify this percentage by looking at historical data and show detailed examples of how schedule growth influences cost growth. The paper also addresses a methodology to show an alternate approach for assessing and setting a robust baseline schedule and use schedule performance metrics to help assess if the project is performing to plan. Finally, recommendations are presented to help control schedule growth in order to minimize cost growth for NASA space science missions.

schedule↗