Search NASA⌕ Search

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.

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

At least 145 records · Page 8

Trajectory Operations of the Artemis I Mission

This paper describes the operational design and execution of the Artemis I trajectory. It was an operationally complex trajectory with powered lunar flybys and insertion into a Distant Retrograde Orbit (DRO). A joint team of trajectory analysts at the NASA Johnson Space Center (JSC) were responsible for the design and operation of nominal and off-nominal in-space trajectories. A process was developed to convert optimized reference trajectories into Orion burn plans that could be uplinked to the vehicle. During the mission, the joint flight controller and engineering team continuously evaluated upcoming translational burns using actual vehicle conditions, monitored the trajectory for opportunities to re-optimize the trajectory in order to reduce propellant usage, and prepared for potential off-nominal scenarios. Overall Orion in-space trajectory performance is compared tomission designs to demonstrate the success of the design and operations work-flows.

Artemis I↗

CAP – NASA DRF Wildfire Mitigation Partnership

The California Wing of CAP and the DRF Team came together during Fall of 2020. NASA DRF Team gathered an understanding of CAP’s operational process flow for their wildfire reconnaissance missions and, in collaboration with CAP, has been able to identify a preliminary set of technology areas that can be enabled/enhanced by DRF to potentially bring forth improved accuracy and reduced latency in the data used by CAP in mission critical decision making. This content is expected to be hosted on the NARA NASA public websites: https://nari.arc.nasa.gov/tfrsac-wildfire

Kenneth Freeman↗

The Integration of COTS/GOTS within NASA's HST Command and Control System

NASA's mission critical Hubble Space Telescope (HST) command and control system has been re-engineered with COTS/GOTS and minimal custom code. This paper focuses on the design of this new HST Control Center System (CCS) and the lessons learned throughout its development. CCS currently utilizes 31 COTS/GOTS products with an additional 12 million lines of custom glueware code; the new CCS exceeds the capabilities of the original system while significantly reducing the lines of custom code by more than 50%. The lifecycle of COTS/GOTS products will be examined including the pack-age selection process, evaluation process, and integration process. The advantages, disadvantages, issues, concerns, and lessons teamed for integrating COTS/GOTS into the NASA's mission critical HST CCS will be examined in detail. Command and control systems designed with traditional custom code development efforts will be compared with command and control systems designed with new development techniques relying heavily on COTS/COTS integration. This paper will reveal the many hidden costs of COTS/GOTS solutions when compared to traditional custom code development efforts; this paper will show the high cost of COTS/GOTS solutions including training expenses, consulting fees, and long-term maintenance expenses.

Pfarr, Thomas↗

Spacecraft Block Scheduling for NASA’s Deep Space Network

Currently, NASA’s Deep Space Network (DSN) is responsible for uplink to, downlink from, and/or tracking of dozens of missions for space agencies across the world. The DSN scheduling process starts about four months prior to the start of the schedule week, a process in which requirements are defined and then the schedule is created, de-conflicted, and negotiated over the next 2–3 weeks with a team of mission representatives. Now scheduled for late 2019, Exploration Mission1 (EM-1) will deploy upwards of 12 SmallSat missions that will be served by the DSN. This will increase the DSN’s actively serviced spacecraft by up to 30%, further increasing the difficulty of meeting all mission needs via the over subscribed network. To mitigate their impact on DSN scheduling, a block scheduling process is proposed for scheduling the SmallSats. Block scheduling consists of aggregating spacecraft together into larger “pseudo-spacecraft” based on geometric alignment that then follow the same process as any other DSN mission to receive segments of track time. These tracks are then decomposed into tracks for individual users based on their specific requirements. This paper describes a full novel scheduling tool set for building candidate blocks, evaluating the efficacy of these blocks, and optimal and suboptimal de-blocking schemes. To demonstrate these developed tools, results from three simulations are presented: a blocking example with lunar SmallSats, blocking potential in the greater DSN spacecraft catalog, and opportunistic multiple spacecraft per aperture potential for the DSN spacecraft catalog. Block scheduling has the potential to reduce overhead and scheduling resources for the EM-1 SmallSats while also providing them with a better means to meet their mission requirements.

Bilén, Sven G.↗

Long Duration Medical System Foundation for Lunar Orbital and Lunar Surface Exploration Missions

For long-duration lunar orbital and lunar surface (LDLOS) exploration missions, the NASA Human Research Program (HRP) Exploration Medical Capability (ExMC) Element has developed a medical system foundation through which clinical considerations may be represented via a systems engineering-based model. Components of the Long Duration Medical System Foundation model include a concept of operations (ConOps), functional decomposition, medical conditions to be addressed, clinical capabilities and resources, technical requirements, and traces of requirements to NASA standards documents and parent-level (Program- and Vehicle habitat system-level) requirements. The Foundation model offers the means to present information in a readily accessible format that is understandable across all clinical, engineering, scientific, and managerial disciplines. Collectively, these components constitute a foundation that serves future programs with similar long duration mission profiles as a starting point for medical system design. The Foundation was developed by a multidisciplinary team of systems engineers, scientists, and clinicians across NASA. The process started with ConOps development, subsequently decomposed into the functionalities needed to diagnose, treat, and prevent medical conditions. The clinical team identified medical conditions most likely needed to be diagnosed and treated during a long-duration lunar exploration mission. Through these approaches, requirements were codified for the LDLOS medical system. These requirements were then traced to NASA standards, medical conditions, medical capabilities, and medical resources, facilitating stakeholders’ use of the Foundation model to analyze traces and to identify medical system interfaces with other vehicle systems or subsystems. In addition, the Foundation may be used as a basis for performing risk trades on medical system mass and volume allocation. This discussion will focus on the processes through which the LDLOS Medical System Foundation was developed, how the Foundation builds a bridge between the medical and engineering domains, and how these processes may be applied more broadly to a crew health and performance system and other system domains.

Jay Lemery↗

Prelaunch processing scientific payloads since Challenger - Lessons learned exercise

The 'lessons learned' process that follows each NASA payload-processing operation is described with attention given to the development of a knowledge base from the results. The process is based on the subjective evaluation of operations problems by test-team members following a mission. The lessons learned from four Space Shuttle missions - STS-26R, -29R, -30R, and -30 - are examined with categorizations of incidents which is based on operational, documentation, hardware, and software categories. Recommendations for ways to address the incidents are categorized similarly, with operational categories such as admonitory, documentation modifications, and support changes. A basic numerical dataset is developed based on the results, and the data show that STS-26R had the highest number of incidents. The process is found to be an effective educational tool in payload-processing operations because it disseminates key individual experiences.

Schuiling, R. L.↗

Identification and Classification of Common Risks in Space Science Missions

Due to the highly constrained schedules and budgets that NASA missions must contend with, the identification and management of cost, schedule and risks in the earliest stages of the lifecycle is critical. At the Jet Propulsion Laboratory (JPL) it is the concurrent engineering teams that first address these items in a systematic manner. Foremost of these concurrent engineering teams is Team X. Started in 1995, Team X has carried out over 1000 studies, dramatically reducing the time and cost involved, and has been the model for other concurrent engineering teams both within NASA and throughout the larger aerospace community. The ability to do integrated risk identification and assessment was first introduced into Team X in 2001. Since that time the mission risks identified in each study have been kept in a database. In this paper we will describe how the Team X risk process is evolving highlighting the strengths and weaknesses of the different approaches. The paper will especially focus on the identification and classification of common risks that have arisen during Team X studies of space based science missions.

Risk Identification↗

Quality Interaction Between Mission Assurance and Project Team Members

Mission Assurance independent assessments started during the development cycle and continued through post launch operations. In operations, Health and Safety of the Observatory is of utmost importance. Therefore, Mission Assurance must ensure requirements compliance and focus on process improvements required across the operational systems including new/modified products, tools, and procedures. The deployment of the interactive model involves three objectives: Team member Interaction, Good Root Cause Analysis Practices, and Risk Assessment to avoid reoccurrences. In applying this model, we use a metric based measurement process and was found to have the most significant effect, which points to the importance of focuses on a combination of root cause analysis and risk approaches allowing the engineers the ability to prioritize and quantify their corrective actions based on a well-defined set of root cause definitions (i.e. closure criteria for problem reports), success criteria and risk rating definitions.

quality↗

Introduction of an Agile Systems Engineering Process to the NASA Armstrong Flight Research Center

This paper will provide background on the National Aeronautics and Space Administration (NASA) Aeronautics Research Mission Directorate (ARMD) ARMD Test Data Portal (ATDP) effort along with the rationale that motivated the ATDP team to consider implementing an agile systems engineering (SE) process. The primary motivation for using this new SE process was based on the desire to mitigate a major risk to project success. Since the agile SE process had never been used before at the NASA Armstrong Flight Research Center (AFRC), utilizing this new SE process required a trailblazing effort to introduce it to NASA AFRC leadership. As a result, the ATDP team chose to adhere to the agile SE process in addition to the trusted classical waterfall SE process on ATDP. Through successful execution of this hybrid SE process during Phase I, along with demonstrating the value and rigor of the agile SE process, NASA AFRC leadership ultimately permitted the ATDP project to solely use the agile SE process for developments beyond Phase I. While it is the opinion of the authors that the classical SE process is more effective for most projects at NASA AFRC, some projects may deem that the agile SE process is more advantageous. Although this paper is focused on introducing the agile SE process to NASA AFRC, lessons learned will be valuable to other organizations as well. Details of how the ATDP team implemented the agile SE process during Phase I will be summarized, along with how the team met all required classical SE milestones. Lessons learned throughout Phase I of this effort will also be highlighted.

Daniel S. Jones↗

Cassini Information Management System in Distributed Operations Collaboration and Cassini Science Planning

Launched on October 15, 1997, the Cassini-Huygens spacecraft began its ambitious journey to the Saturnian system with a complex suite of 12 scientific instruments, and another 6 instruments aboard the European Space Agencies Huygens Probe. Over the next 6 1/2 years, Cassini would continue its relatively simplistic cruise phase operations, flying past Venus, Earth, and Jupiter. However, following Saturn Orbit Insertion (SOI), Cassini would become involved in a complex series of tasks that required detailed resource management, distributed operations collaboration, and a data base for capturing science objectives. Collectively, these needs were met through a web-based software tool designed to help with the Cassini uplink process and ultimately used to generate more robust sequences for spacecraft operations. In 2001, in conjunction with the Southwest Research Institute (SwRI) and later Venustar Software and Engineering Inc., the Cassini Information Management System (CIMS) was released which enabled the Cassini spacecraft and science planning teams to perform complex information management and team collaboration between scientists and engineers in 17 countries. Originally tailored to help manage the science planning uplink process, CIMS has been actively evolving since its inception to meet the changing and growing needs of the Cassini uplink team and effectively reduce mission risk through a series of resource management validation algorithms. These algorithms have been implemented in the web-based software tool to identify potential sequence conflicts early in the science planning process. CIMS mitigates these sequence conflicts through identification of timing incongruities, pointing inconsistencies, flight rule violations, data volume issues, and by assisting in Deep Space Network (DSN) coverage analysis. In preparation for extended mission operations, CIMS has also evolved further to assist in the planning and coordination of the dual playback redundancy of highvalue data from targets such as Titan and Enceladus. This paper will outline the critical role that CIMS has played for Cassini in the distributed ops paradigm throughout operations. This paper will also examine the evolution that CIMS has undergone in the face of new science discoveries and fluctuating operational needs. And finally, this paper will conclude with theoretical adaptation of CIMS for other projects and the potential savings in cost and risk reduction that could potentially be tapped into by future missions.

Equils, Douglas J.↗

Resource Prospector Instrumentation for Lunar Volatiles Prospecting, Sample Acquisition and Processing

Data gathered from lunar missions within the last two decades have significantly enhanced our understanding of the volatile resources available on the lunar surface, specifically focusing on the polar regions. Several orbiting missions such as Clementine and Lunar Prospector have suggested the presence of volatile ices and enhanced hydrogen concentrations in the permanently shadowed regions of the moon. The Lunar Crater Observation and Sensing Satellite (LCROSS) mission was the first to provide direct measurement of water ice in a permanently shadowed region. These missions with other orbiting assets have laid the groundwork for the next step in the exploration of the lunar surface; providing ground truth data of the volatiles by mapping the distribution and processing lunar regolith for resource extraction. This next step is the robotic mission Resource Prospector (RP). Resource Prospector is a lunar mission to investigate 'strategic knowledge gaps' (SKGs) for in-situ resource utilization (ISRU). The mission is proposed to land in the lunar south pole near a permanently shadowed crater. The landing site will be determined by the science team with input from broader international community as being near traversable landscape that has a high potential of containing elevated concentrations of volatiles such as water while maximizing mission duration. A rover will host the Regolith & Environment Science and Oxygen & Lunar Volatile Extraction (RESOLVE) payload for resource mapping and processing. The science instruments on the payload include a 1-meter drill, neutron spectrometer, a near infrared spectrometer, an operations camera, and a reactor with a gas chromatograph-mass spectrometer for volatile analysis. After the RP lander safely delivers the rover to the lunar surface, the science team will guide the rover team on the first traverse plan. The neutron spectrometer (NS) and near infrared (NIR) spectrometer instruments will be used as prospecting tools to guide the traverse path. The NS will map the water-equivalent hydrogen concentration as low as 0.5% by weight to an 80 centimeter depth as the rover traverses the lunar landscape. The NIR spectrometer will measure surficial H2O/OH as well as general mineralogy. When the prospecting instruments identify a potential volatile-rich area during the course of a traverse, the prospect is then mapped out and the most promising location identified. An augering drill capable of sampling to a depth of 100 centimeters will excavate regolith for analysis. A quick assay of the drill cuttings will be made using an operations camera and NIR spectrometer. With the water depth confirmed by this first auguring activity, a regolith sample may be extracted for processing. The drill will deliver the regolith sample to a crucible that will be sealed and heated. Evolved volatiles will be measured by a gas chromatograph-mass spectrometer and the water will be captured and photographed. RP is a solar powered mission, which given the polar location translates to a relatively short mission duration on the order of 4-15 days. This short mission duration drives the concept of operations, instrumentation, and data analysis towards critical real time analysis and decision support. Previous payload field tests have increased the fidelity of the hardware, software, and mission operations. Current activities include a mission level field test to optimize interfaces between the payload and rover as well as better understand the interaction of the science and rover teams during the mission timeline. This paper will include the current status of the science instruments on the payload as well as the integrated field test occurring in fall of 2015. The concept of operations will be discussed, including the real time science and engineering decision-making process based on the critical data from the instrumentation. The path to flight will be discussed with the approach to this ambitious low cost mission.

ISRU↗

Development of a Human Systems Integration Plan

NASA defines Human Systems Integration (HSI) as part of the overall systems engineering and acquisition strategy for space systems. The HSI Plan defines how HSI activities will be implemented across the lifecycle of the mission, as required by NPR 7123.1C, NASA Systems Engineering Processes and Requirements, and NPR 8705.2C Human-Rating Requirements for Space Systems. The goal of this presentation is to share with government and industry how an HSI Plan can be implemented. The presentation will cover HSI implementation for flight systems, vehicle processing, and interfaces. These are divided into six NASA HSI Domains: human factors engineering, operations resources, safety, training, maintainability and supportability, habitability and environment. HSI activities go across the mission’s lifecycle from pre-formulation and acquisition through design, development, operations, maintenance, and decommissioning. The HSI Plan includes a description of the HSI activities and products that are essential for human rating, operability, maintainability, supportability, and affordability of the mission systems. It also describes the role of the HSI Team required as part of the Human Rating process. The HSI Plan utilizes the operational expertise within NASA to ensure designs and testing are successful, leading to acceptable human spaceflight vehicles.

Jackelynne Silva-Martinez↗

The Virtual Mission Operations Center

Spacecraft management is becoming more human intensive as spacecraft become more complex and as operations costs are growing accordingly. Several automation approaches have been proposed to lower these costs. However, most of these approaches are not flexible enough in the operations processes and levels of automation that they support. This paper presents a concept called the Virtual Mission Operations Center (VMOC) that provides highly flexible support for dynamic spacecraft management processes and automation. In a VMOC, operations personnel can be shared among missions, the operations team can change personnel and their locations, and automation can be added and removed as appropriate. The VMOC employs a form of on-demand supervisory control called management by exception to free operators from having to actively monitor their system. The VMOC extends management by exception, however, so that distributed, dynamic teams can work together. The VMOC uses work-group computing concepts and groupware tools to provide a team infrastructure, and it employs user agents to allow operators to define and control system automation.

Moore, Mike↗

The PMDP Roadmap

NASA's complex and highly technical missions rely on effective project teams and managers. Since 1993, through its Project Management Development Process (PMDP), the Academy of Program and Project Leadership (APPL) has offered direction to the Agency's project practitioners as they advance in their careers. PMDP helps identify and sequence professional experiences, courses, and other project-based learning experiences that support individual career goals and center activities by outlining competencies at four levels of development. The result is that PMDP provides NASA project practitioners with a road map to the knowledge and competencies appropriate for their job and the jobs to which they aspire. Plus, new this year, APPL has rolled out its electronic Project Management Development Process (ePMDP) tool, a learning management system that includes a dynamic presentation of the PMDP levels, competency areas, competency organizational structures, Individual Development Plans (IDP), and online PMDP enrollment. APPL's website, www.appl.nasa.gov, provides access to ePMDP as well as other online resources for NASA practitioners enrolled in the Project Management Development Process.

Source record↗

Overview of NASA Behavioral Health and Performance Standard Measures

NASA’s Human Research Program (HRP) is developing a set of “Standard Measures” for use in spaceflight and spaceflight analog environments to monitor the risks of long-duration missions on human health and performance, including behavioral health, individual and team performance, and social processes. Based on measures selected, developed, and tested under the NASA-funded Behavioral Core Measures project (PI: D.F. Dinges) as well as other projects from NASA’s Human Factors & Behavioral Performance research portfolio, NASA’s Behavioral Health & Performance (BHP) Laboratory is further evaluating the operational feasibility, acceptability, and validity of a multidisciplinary suite of objective, subjective, behavioral, and biological measures for monitoring monitor behavioral health, individual and team performance, and social processes over time. The inaugural generation of the NASA Behavioral Health & Performance (BHP) Standard Measures includes a neurocognitive test battery, actigraphy, physical proximity sensors, cardiovascular monitors, and subjective self-reports of mood, depression, and various team and social processes and performance outcomes.

Roma, P. G.↗

Planetary Boundary Layer Height from AIRS and MERRA-2 Products at NASA GES DISC, and Insights from Data Intercomparison

The Atmospheric Infrared Sounder (AIRS) is the hyperspectral infrared sounder onboard NASA's Aqua satellite, launched in 2002. The NASA Goddard Earth Sciences Data and Information Services Center (GES DISC), in collaboration with NASA Sounder Team at JPL, provides processing, archiving, and distribution services for NASA sounders: the Aqua AIRS mission and the subsequent Suomi-National Polar-orbiting Partnership Cross-track Infrared Sounder (CrIS) mission. The Planetary Boundary Layer (PBL) Height is a new variable added in the AIRS Version 6 support product. It is derived based on gradients of the retrieved atmospheric thermodynamic profile, and gives the pressure at the top of PBL over the ocean. The GES DISC also provides services for the second Modern-Era Retrospective analysis for Research and Applications (MERRA-2) product generated by the Goddard Earth Observing System Model, Version 5 (GEOS-5) data assimilation system. The monthly PBL Height variable has been available in the Giovanni system, which is a Web-based application developed by the GES DISC providing a simple and intuitive way to visualize, analyze, and access vast amounts of Earth science remote sensing data. In this work, we will present the monthly PBL Height data from AIRS and MERRA-2 and the services to support data intercomparison, such as access, plotting, subsetting, re-gridding, and generation of a multi-year monthly mean. We will also show intercomparison results, and evaluate whether (over the ocean) AIRS can observe PBL features similar to the reanalysis product at monthly and longer-term scales.

AIRS↗

MarCO: Interplanetary Mission Development on a CubeSat Scale

Shortly after JPL’s Interior Exploration using Seismic Investigations, Geodesy and Heat Transport (InSight) mission launches, separates, and commences its cruise phase, two CubeSats will deploy from the launch vehicle’s upper stage and begin independent flight to Mars (Fig. 1). During InSight’s entry, descent, and landing (EDL) sequence, these twin Mars Cube One (MarCO) spacecraft will fly 3,500 km above the Martian surface, recording and relaying InSight UHF radio data to the Deep Space Network (DSN) on Earth1. MarCO is a twin CubeSat mission developed by the NASA Jet Propulsion Laboratory (JPL) to accompany the InSight (Interior Exploration using Seismic Investigations, Geodesy and Heat Transport) Mars mission lander. MarCO's primary mission objective is to launch with InSight and independently fly to Mars to serve as a communications relay during InSight's entry, descent, and landing (EDL) phase. MarCO represents a new type of deep space mission: CubeSats at Mars. Building on the development of JPL's first interplanetary CubeSat project, the Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment (INSPIRE), MarCO further refined the approach to hardware, software, and ground architecture development to solve the challenges of quickly building low-budget spacecraft to fly to Mars. The greatest constraint, beyond others typical of CubeSat missions, was time. The duration between MarCO's conception to completion of spacecraft assembly was less than two years - an unprecedented schedule for any planetary mission to date. Through necessity, MarCO has built on previous experience, procedures, systems, and development methodologies, defining a new niche for supporting larger primary missions. The MarCO spacecraft are poised to write a new chapter in deep space exploration. Originally slated to launch and reach Mars in 2016, the InSight mission schedule subsequently slipped to 2018. During the original landing of InSight, Earth would not be in view, and no orbiter around Mars would have been in position to both receive UHF EDL data and simultaneously relay it back to Earth. It was from this obstacle that MarCO was conceived. Regardless of any changes to InSight’s 2018 EDL configuration geometry, MarCO is still expected to fly and serve in the same capacity as originally designed: the first CubeSat mission to Mars. CubeSats have historically been firmly in the domain of universities and small companies. As first conceived, they served as a platform upon which to teach all aspects of the space mission lifecycle. JPL took on this mission type with Interplanetary Nano-Spacecraft Pathfinder in Relevant Environment2 (INSPIRE), moving the concept into a new domain: deep space. Building from the INSPIRE platform and lessons learned, MarCO addressed new challenges in the domain of planetary missions: independent interplanetary flight and navigation, integration with a large-scale mission, long-distance and long-delay communication, short development time, and a small development team. Of these, the greatest constraint was schedule: only 18 months passed from conception of mission concept until delivery of fully assembled and tested flight hardware. Careful selection of mission team, along with extensive use of off-the-shelf equipment, and streamlining automated processes, was essential. This achievement represents the next step in the evolution of CubeSats beyond low-Earth orbit.

Werne, Thomas↗