SEARCH · Search NASA

Results for “Process Mission Teams”

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 289 records · Page 16

All sources NASA NTRS DOE OSTI

NASA NTRS2015

Integrating Safety and Mission Assurance into Systems Engineering Modeling Practices

During the early development of products, flight, or experimental hardware, emphasis is often given to the identification of technical requirements, utilizing such tools as use case and activity diagrams. Designers and project teams focus on understanding physical and performance demands and challenges. It is typically only later, during the evaluation of preliminary designs that a first pass, if performed, is made to determine the process, safety, and mission quality assurance requirements. Evaluation early in the life cycle, though, can yield requirements that force a fundamental change in design. This paper discusses an alternate paradigm for using the concepts of use case or activity diagrams to identify safety hazard and mission quality assurance risks and concerns using the same systems engineering modeling tools being used to identify technical requirements. It contains two examples of how this process might be used in the development of a space flight experiment, and the design of a Human Powered Pizza Delivery Vehicle, along with the potential benefits to decrease development time, and provide stronger budget estimates.

Requirements↗

NASA NTRSDate not supplied

Managing HRP's External Deliverables: The Process and the Customers

The Human Research Program’s (HRP) external deliverables (EDs) are the final outcomes of the research that the HRP Elements develop and execute. The NASA Human Health and Performance directorate’s primary stakeholders, i.e., the customers for the EDs, include the Office of the Chief Health and Medical Officer (OCHMO) (Standards Team, Chief Health and Performance Officers and Chief Medical Officers, Human System Risk Board), and the agency’s System Capability Leadership Teams. The EDs may address the need of a specific customer, a specific design reference mission, or a vehicle lifecycle milestone. HRP’s Maturation and Integration Office External Programs facilitates the process of delivering the EDs to the targeted customers according to the customer’s expectations. This presentation describes this coordinated process and provides an overview of the nature of different types of EDs and how they impact the customers’ products. Successful transfer of the EDs to the customers will help mitigate the health and performance risks that crewmembers will face during NASA’s future exploration missions.

research↗

NASA NTRSDate not supplied

Root Cause Analysis of the Data Refinement Process – Medical Conditions Capability Resource Tables

The medical system for spaceflight thus far has been designed to support missions in low earth orbit (LEO). Crew capabilities are limited and heavily dependent on the team of medical support staff at Mission Control Center (MCC) to guide diagnosis and management. However, missions to the Moon and Mars will suffer from several constraints that will make this ground support focused approach to care ineffective. In order to update and modify medical system design, NASA has relied on Probabilistic Risk Assessment (PRA) modeling to mitigate medical risk through trade space analysis. Specifically, capability resource tables (CRT’s) were developed to create a dataset of resources required to manage a list of accepted medical conditions significant in exploration spaceflight. With 120 conditions, this dataset contained hundreds of capabilities and thousands of resources with tens of thousands of cells of data. Initially these tables were built in excel for high throughput during development, but ultimately had to be transferred, managed, and modified into the Evidence Library database for modeling purposes. The process of collating and reviewing the Evidence Library revealed numerous errors in the dataset that had to be corrected through iterative changes. Several error types emerged during this process and can be broken into specific classifications defined as “input”, “transcription”, “structural”, “branching”, and “information”. In reviewing these error types through the root cause analysis (RCA) approach, we were able to identify the contributors to these errors which included single data review points, changing product end goals, limited software selection, time constraints and several others. By reviewing and evaluating the underlying causes we can provide possible system improvements that can be implemented for current and future data management in PRA model inputs.

A. Anderson↗

NASA NTRS2004

An Overview of the James Webb Space Telescope Project

The JWST project at the GSFC is responsible for the development, launch, operations and science data processing for the James Webb Space Telescope. The JWST project is currently in phase B with its launch scheduled for August 2011. The project is a partnership between NASA, ESA and CSA. The U.S. JWST team is in place with the selection of Northrop Grumman Space Technology (NGST) as the prime contractor for the telescope and the Space Telescope Science Institute (STScI) as the mission operations and science data processing lead. This paper will provide an overview of the current JWST architecture and mission status including technology developments and risks.

Sabelhaus, Phillip A.↗

NASA NTRS2011

The Ganymede Interior Structure, and Magnetosphere Observer (GISMO) Mission Concept

The NASA Planetary Science Summer School (PSSS) at JPL offers graduate students and young professionals a unique opportunity to learn about the mission design process. Program participants select and design a mission based on a recent NASA Science Mission Directorate Announcement of Opportunity (AO). Starting with the AO, in this case the 2009 New Frontiers AO, participants generate a set of science goals and develop a early mission concept to accomplish those goals within the constraints provided. As part of the 2010 NASA PSSS, the Ganymede Interior, Surface, and Magnetosphere Observer (GISMO) team developed a preliminary satellite design for a science mission to Jupiter's moon Ganymede. The science goals for this design focused on studying the icy moon's magnetosphere, internal structure, surface composition, geological processes, and atmosphere. By the completion of the summer school an instrument payload was selected and the necessary mission requirements were developed to deliver a spacecraft to Ganymede that would accomplish the defined science goals. This poster will discuss those science goals, the proposed spacecraft and the proposed mission design of this New Frontiers class Ganymede observer.

radar sounder↗

NASA NTRS1991

Representing cockpit crew decision making

A theoretical framework has been synthesized for the use of cognitive processes to understand team functions. Three different pilot-copilot-flight engineer cockpit crews were observed over the course of a set of mission conducted in a B 727 simulator at NASA-Ames. Only experienced commercial aviators were used in positions for which they were officially qualified; one of the flights involved a generator malfunction, and another was marked by a serious fuel leak. All flights were videotaped and shown to the crews immediately after each session. Transcripts prepared from these videotapes logged the person uttering each comment and the exact time of the comment.

Klein, Gary A.↗

NASA NTRS1993

Functional categories for future flight deck designs

With the addition of each new system on the flight deck, the danger of increasing overall operator workload while reducing crew understanding of critical mission information exists. The introduction of more powerful onboard computers, larger databases, and the increased use of electronic display media may lead to a situation of flight deck 'sophistication' at the expense of losses in flight crew capabilities and situational awareness. To counter this potentially negative impact of new technology, research activities are underway to reassess the flight deck design process. The fundamental premise of these activities is that a human-centered, systems-oriented approach to the development of advanced civil aircraft flight decks will be required for future designs to remain ergonomically sound and economically competitive. One of the initial steps in an integrated flight deck process is to define the primary flight deck functions needed to support the mission goals of the vehicle. This would allow the design team to evaluate candidate concepts in relation to their effectiveness in meeting the functional requirements. In addition, this would provide a framework to aid in categorizing and bookkeeping all of the activities that are required to be performed on the flight deck, not just activities of the crew or of a specific system. This could then allow for a better understanding and allocation of activities in the design, an understanding of the impact of a specific system on overall system performance, and an awareness of the total crew performance requirements for the design. One candidate set of functional categories that could be used to guide an advanced flight deck design are described.

Abbott, Terence S.↗

NASA NTRS1994

A new systems engineering approach to streamlined science and mission operations for the Far Ultraviolet Spectroscopic Explorer (FUSE)

The Mission Operations and Data Systems Directorate (MO&DSD, Code 500), the Space Sciences Directorate (Code 600), and the Flight Projects Directorate (Code 400) have developed a new approach to combine the science and mission operations for the FUSE mission. FUSE, the last of the Delta-class Explorer missions, will obtain high resolution far ultraviolet spectra (910 - 1220 A) of stellar and extragalactic sources to study the evolution of galaxies and conditions in the early universe. FUSE will be launched in 2000 into a 24-hour highly eccentric orbit. Science operations will be conducted in real time for 16-18 hours per day, in a manner similar to the operations performed today for the International Ultraviolet Explorer. In a radical departure from previous missions, the operations concept combines spacecraft and science operations and data processing functions in a single facility to be housed in the Laboratory for Astronomy and Solar Physics (Code 680). A small missions operations team will provide the spacecraft control, telescope operations and data handling functions in a facility designated as the Science and Mission Operations Center (SMOC). This approach will utilize the Transportable Payload Operations Control Center (TPOCC) architecture for both spacecraft and instrument commanding. Other concepts of integrated operations being developed by the Code 500 Renaissance Project will also be employed for the FUSE SMOC. The primary objective of this approach is to reduce development and mission operations costs. The operations concept, integration of mission and science operations, and extensive use of existing hardware and software tools will decrease both development and operations costs extensively. This paper describes the FUSE operations concept, discusses the systems engineering approach used for its development, and the software, hardware and management tools that will make its implementation feasible.

Butler, Madeline J.↗

NASA NTRS2004

How Systems Engineering and Risk Management Defend Against Murphy's Law and Human Error

Systems Engineering and Risk Management processes can work synergistically to defend against the causes of many mission ending failures. Defending against mission ending failures is facilitated by fostering a team that has a healthy respect for Murphy's Law and a team with a of curiosity for how things work, how they can fail, and what they need to know. This curiosity is channeled into making the unknowns known or what is uncertain more certain. Efforts to assure mission success require the expenditure of energy in the following areas: 1. Understanding what defines Mission Success as guided by the customer's needs, objectives and constraints. 2. Understanding how the system is supposed to work and how the system is to be produced, fueled by the curiosity of how the system should work and how it should be produced. 3. Understanding how the system can fail and how the system might not be produced on time and within cost, fueled by the curiosity of how the system might fail and how production might be difficult. 4. Understanding what we need to know and what we need learn for proper completion of the above three items, fueled by the curiosity of what we might not know in order to make the best decisions.

Bay, Michael↗

NASA NTRS2011

Space Missions Trade Space Generation and Assessment Using JPL Rapid Mission Architecture (RMA) Team Approach

The JPL Rapid Mission Architecture (RMA) capability is a novel collaborative team-based approach to generate new mission architectures, explore broad trade space options, and conduct architecture-level analyses. RMA studies address feasibility and identify best candidates to proceed to further detailed design studies. Development of RMA first began at JPL in 2007 and has evolved to address the need for rapid, effective early mission architectural development and trade space exploration as a precursor to traditional point design evaluations. The RMA approach integrates a small team of architecture-level experts (typically 6-10 people) to generate and explore a wide-ranging trade space of mission architectures driven by the mission science (or technology) objectives. Group brainstorming and trade space analyses are conducted at a higher level of assessment across multiple mission architectures and systems to enable rapid assessment of a set of diverse, innovative concepts. This paper describes the overall JPL RMA team, process, and high-level approach. Some illustrative results from previous JPL RMA studies are discussed.

real time systems↗

NASA NTRS2001

Coronal Thermal Structure and Abundance of Super-Metal-Rich Late-Type Stars

This observation is for grating spectroscopy of 30 Ari, a late-type star with very high metallicity. The goal is to use extreme cases to help understand how abundances change from the photosphere to the corona. The only progress is to report to date is preparation for the analysis of the data. The SAO team has produced spectral model predictions for comparison with the observed spectra. The target was obtained by X-ray Multimirror Mission (XMM)-Newton on 2001 January 16 for 28000 sec. Pipeline processing is difficult and the data have not yet been available. Furthermore, we have been cautioned that the data cannot be correctly processed until at least September of this year, as there are problems with the RGS software to extract the spectrum. We have attended two workshops this summer in which results from XMM on late-type stellar coronae were presented including SMM results from GT team members. We noted that only members of the instrument teams are in a position to analyze XMM data.

Brickhouse, N.↗

NASA NTRS2008

Web Based Tool for Mission Operations Scenarios

A conventional practice for spaceflight projects is to document scenarios in a monolithic Operations Concept document. Such documents can be hundreds of pages long and may require laborious updates. Software development practice utilizes scenarios in the form of smaller, individual use cases, which are often structured and managed using UML. We have developed a process and a web-based scenario tool that utilizes a similar philosophy of smaller, more compact scenarios (but avoids the formality of UML). The need for a scenario process and tool became apparent during the authors' work on a large astrophysics mission. It was noted that every phase of the Mission (e.g., formulation, design, verification and validation, and operations) looked back to scenarios to assess completeness of requirements and design. It was also noted that terminology needed to be clarified and structured to assure communication across all levels of the project. Attempts to manage, communicate, and evolve scenarios at all levels of a project using conventional tools (e.g., Excel) and methods (Scenario Working Group meetings) were not effective given limitations on budget and staffing. The objective of this paper is to document the scenario process and tool created to offer projects a low-cost capability to create, communicate, manage, and evolve scenarios throughout project development. The process and tool have the further benefit of allowing the association of requirements with particular scenarios, establishing and viewing relationships between higher- and lower-level scenarios, and the ability to place all scenarios in a shared context. The resulting structured set of scenarios is widely visible (using a web browser), easily updated, and can be searched according to various criteria including the level (e.g., Project, System, and Team) and Mission Phase. Scenarios are maintained in a web-accessible environment that provides a structured set of scenario fields and allows for maximum visibility across the project. One key aspect is that the tool was built for a scenario process that accounts for stakeholder input, review, comment, and concurrence. By creating well-designed opportunities for stakeholder input and concurrence and by making the scenario content easily accessible to all project personnel, we maximize the opportunities for stakeholders to both understand and agree on the concepts for how their mission is to be carried out.

Boyles, Carole A.↗

NASA NTRS2015

Comparative Analysis of Static and Dynamic Probabilistic Risk Assessment

This study examines three different methodologies for producing loss-of-mission (LOM) and loss-of-crew (LOC) risks estimates for probabilistic risk assessments (PRA) of crewed spacecraft. The three bottom-up, component-based PRA approaches examined are a traditional static fault tree, a dynamic Monte Carlo simulation, and a fault tree hybrid that incorporates some dynamic elements. These approaches were used to model the reaction control system thruster pod of a generic crewed spacecraft and mission, and a comparative analysis of the methods is presented. The methodologies are assessed in terms of the process of modeling a system, the actionable information produced for the design team, and the overall fidelity of the quantitative risk evaluation generated. The system modeling process is compared in terms of the effort required to generate the initial model, update the model in response to design changes, and support mass-versus-risk trade studies. The results are compared by examining the top-level LOM/LOC estimates and the relative risk driver rankings at the failure mode level. The fidelity of each modeling methodology is discussed in terms of its capability to handle real-world system dynamics such as cold-sparing, changes in mission operations due to loss of redundancy, and common cause failure modes. The paper also discusses the applicability of each methodology to different phases of system development and shows that a single methodology may not be suitable for all of the many purposes of a spacecraft PRA. The fault tree hybrid approach is shown to be best suited to the needs of early assessments during conceptual design phases. As the design begins to mature, the level of detail represented in the risk model must go beyond redundancy and nominal mission operations to include dynamic, time- and state-dependent system responses as well as diverse system capabilities. This is best accomplished using the dynamic simulation approach, since these phenomena are not easily captured by static methods. Ultimately, once the design has been finalized and the goal of the PRA is to provide design validation and requirement verification, more traditional, static fault tree approaches may become as appropriate as the simulation method.

Mattenberger, Christopher J.↗

NASA NTRS2012

The Kepler End-to-End Data Pipeline: From Photons to Far Away Worlds

The Kepler mission is described in overview and the Kepler technique for discovering exoplanets is discussed. The design and implementation of the Kepler spacecraft, tracing the data path from photons entering the telescope aperture through raw observation data transmitted to the ground operations team is described. The technical challenges of operating a large aperture photometer with an unprecedented 95 million pixel detector are addressed as well as the onboard technique for processing and reducing the large volume of data produced by the Kepler photometer. The technique and challenge of day-to-day mission operations that result in a very high percentage of time on target is discussed. This includes the day to day process for monitoring and managing the health of the spacecraft, the annual process for maintaining sun on the solar arrays while still keeping the telescope pointed at the fixed science target, the process for safely but rapidly returning to science operations after a spacecraft initiated safing event and the long term anomaly resolution process.The ground data processing pipeline, from the point that science data is received on the ground to the presentation of preliminary planetary candidates and supporting data to the science team for further evaluation is discussed. Ground management, control, exchange and storage of Kepler's large and growing data set is discussed as well as the process and techniques for removing noise sources and applying calibrations to intermediate data products.

data archiving↗

NASA NTRS1994

Re-engineering NASA's space communications to remain viable in a constrained fiscal environment

Along with the Red and Blue Teams commissioned by the NASA Administrator in 1992, NASA's Associate Administrator for Space Communications commissioned a Blue Team to review the Office of Space Communications (Code O) Core Program and determine how the program could be conducted faster, better, and cheaper. Since there was no corresponding Red Team for the Code O Blue Team, the Blue Team assumed a Red Team independent attitude and challenged the status quo, including current work processes, functional distinctions, interfaces, and information flow, as well as traditional management and system development practices. The Blue Team's unconstrained, non-parochial, and imaginative look at NASA's space communications program produced a simplified representation of the space communications infrastructure that transcends organizational and functional boundaries, in addition to existing systems and facilities. Further, the Blue Team adapted the 'faster, better, cheaper' charter to be relevant to the multi-mission, continuous nature of the space communications program and to serve as a gauge for improving customer services concurrent with achieving more efficient operations and infrastructure life cycle economies. This simplified representation, together with the adapted metrics, offers a future view and process model for reengineering NASA's space communications to remain viable in a constrained fiscal environment. Code O remains firm in its commitment to improve productivity, effectiveness, and efficiency. In October 1992, the Associate Administrator reconstituted the Blue Team as the Code O Success Team (COST) to serve as a catalyst for change. In this paper, the COST presents the chronicle and significance of the simplified representation and adapted metrics, and their application during the FY 1993-1994 activities.

Hornstein, Rhoda Shaller↗

NASA NTRSDate not supplied

Managing HRP’S External Deliverables: The Process and the Customers

The Human Research Program’s (HRP) external deliverables (EDs) are the final outcomes of the research that the HRP Elements develop and execute. Four categories of HRP EDs exist: standards, requirements, countermeasures, and tools/technology. The NASA Human Health and Performance directorate’s primary stakeholders, i.e., the customers for the EDs, include the Office of the Chief Health and Medical Officer (OCHMO) (Standards Team, Chief Health and Performance Officers and Chief Medical Officers, Human System Risk Board), and the agency’s System Capability Leadership Teams. The EDs may address the need of a specific customer, a specific design reference mission, or a vehicle lifecycle milestone. HRP’s Maturation and Integration Office External Programs facilitates the process of delivering the EDs to the targeted customers according to the customer’s expectations. This presentation describes this coordinated process and provides an overview of the nature of different types of EDs and how they impact the customers’ products. Successful transfer of the EDs to the customers will help mitigate the health and performance risks that crewmembers will face during NASA’s future exploration missions.

HRP research external deliverables↗

NASA NTRS2010

Flight Team Development in Support of LCROSS - A Class D Mission

The LCROSS (Lunar Crater Observation and Sensing Satellite) project presented a number of challenges to the preparation for mission operations. A class D mission under NASA s risk tolerance scale, LCROSS was governed by a $79 million cost cap and a 29 month schedule from "authority to proceed" to flight readiness. LCROSS was NASA Ames Research Center s flagship mission in its return to spacecraft flight operations after many years of pursuing other strategic goals. As such, ARC needed to restore and update its mission support infrastructure, and in parallel, the LCROSS project had to newly define operational practices and to select and train a flight team combining experienced operators and staff from other arenas of ARC research. This paper describes the LCROSS flight team development process, which deeply involved team members in spacecraft and ground system design, implementation and test; leveraged collaborations with strategic partners; and conducted extensive testing and rehearsals that scaled in realism and complexity in coordination with ground system and spacecraft development. As a testament to the approach, LCROSS successfully met its full mission objectives, despite many in-flight challenges, with its impact on the lunar south pole on October 9, 2009.

Tompkins, Paul D.↗

NASA NTRS2022

Automating Surface Attitude Positioning and Pointing Operations for Mars 2020

The Surface Attitude Positioning and Pointing (SAPP) subsystem of the Mars Perseverance rover keeps track of the rover’s position and attitude on the surface of Mars. The SAPP Downlink Engineering Operations team members receive data from the rover on a daily basis. They must interpret the data to make sure the rover is staying safe and to support uplink planning. The SAPP team keeps track of the error growth in the rover’s attitude estimate due to noise in the Rover Inertial Measurement Unit’s (RIMU) gyroscopes used to propagate that attitude estimate whenever the rover is moving. Whenever this error grows to a particular threshold, SAPP is responsible for updating the onboard attitude knowledge using the RIMU’s accelerometers to estimate rover roll and pitch and sun imaging to estimate rover yaw, thereby reducing this attitude estimation error. Accurate attitude estimation is required so that the rover can successfully point its High Gain Antenna (HGA) to receive information from Earth and as a backup to the Mars orbiters used for sending data from the rover to Earth, point instruments on its Remote Sensing Mast (RSM), and support safe movement and placement of instruments by the rover’s ARM relative to the Martian surface. The Mars 2020 Engineering Operations team has been working to increase the operational efficiency of the mission and eventually move to a five-hour timeline for daily operations. In pursuit of this goal, the SAPP Engineering Operations team has automated their downlink process by developing a centralized Jupyter notebook to analyze the data received daily from the rover. The SAPP downlink Jupyter notebook automatically collects the data relevant to the SAPP subsystem and visualizes this information in plots and tables that can be easily read by downlink operators to aid them in assessing the status of the subsystem. Various Application Programming Interfaces (APIs) have been incorporated into the downlink daily notebook to automate the collection and posting of data, such as gathering and posting data products to the cloud. The SAPP team has also developed a SAPP downlink software library that includes functions to aid the notebook in processing data. In addition to assessing the SAPP subsystem on a daily basis, operators need to assess the long-term trending behavior of the subsystem over time. An automated trending process has been developed to collect information from the daily notebooks in order to plot and analyze that data in a centralized place. These daily and trending processes have expedited the SAPP downlink assessment and laid the groundwork to completely automate the SAPP downlink process so that SAPP operators are unnecessary unless something unexpected occurs. This paper will provide an overview of the functions that the SAPP subsystem carries out on a daily basis, and will then dive into the automations that have been developed for daily and trending downlink assessment. An assessment of the downlink efficiency will be provided, along with a summary of lessons learned and work to go. Finally, the authors will discuss how these types of automated spacecraft health assessments could be more broadly used within mission operations.

Zarifian, Anais↗