Search NASA⌕ Search

SEARCH · Search NASA

Results for “lessons learned information system process improvement”

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 37 records · Page 2
All sourcesNASA NTRSDOE OSTI
NASA NTRS2015

Reliability and Probabilistic Risk Assessment - How They Play Together

Since the Space Shuttle Challenger accident in 1986, NASA has extensively used probabilistic analysis methods to assess, understand, and communicate the risk of space launch vehicles. Probabilistic Risk Assessment (PRA), used in the nuclear industry, is one of the probabilistic analysis methods NASA utilizes to assess Loss of Mission (LOM) and Loss of Crew (LOC) risk for launch vehicles. PRA is a system scenario based risk assessment that uses a combination of fault trees, event trees, event sequence diagrams, and probability distributions to analyze the risk of a system, a process, or an activity. It is a process designed to answer three basic questions: 1) what can go wrong that would lead to loss or degraded performance (i.e., scenarios involving undesired consequences of interest), 2) how likely is it (probabilities), and 3) what is the severity of the degradation (consequences). Since the Challenger accident, PRA has been used in supporting decisions regarding safety upgrades for launch vehicles. Another area that was given a lot of emphasis at NASA after the Challenger accident is reliability engineering. Reliability engineering has been a critical design function at NASA since the early Apollo days. However, after the Challenger accident, quantitative reliability analysis and reliability predictions were given more scrutiny because of their importance in understanding failure mechanism and quantifying the probability of failure, which are key elements in resolving technical issues, performing design trades, and implementing design improvements. Although PRA and reliability are both probabilistic in nature and, in some cases, use the same tools, they are two different activities. Specifically, reliability engineering is a broad design discipline that deals with loss of function and helps understand failure mechanism and improve component and system design. PRA is a system scenario based risk assessment process intended to assess the risk scenarios that could lead to a major/top undesirable system event, and to identify those scenarios that are high-risk drivers. PRA output is critical to support risk informed decisions concerning system design. This paper describes the PRA process and the reliability engineering discipline in detail. It discusses their differences and similarities and how they work together as complementary analyses to support the design and risk assessment processes. Lessons learned, applications, and case studies in both areas are also discussed in the paper to demonstrate and explain these differences and similarities.

Safie, Fayssal↗
NASA NTRS2016

A Cognitive Systems Engineering Approach to Developing HMI Requirements for New Technologies

This document examines the challenges inherent in designing and regulating to support human-automation interaction for new technologies that will deployed into complex systems. A key question for new technologies, is how work will be accomplished by the human and machine agents. This question has traditionally been framed as how functions should be allocated between humans and machines. Such framing misses the coordination and synchronization that is needed for the different human and machine roles in the system to accomplish their goals. Coordination and synchronization demands are driven by the underlying human-automation architecture of the new technology, which are typically not specified explicitly by the designers. The human machine interface (HMI) which is intended to facilitate human-machine interaction and cooperation, however, typically is defined explicitly and therefore serves as a proxy for human-automation cooperation requirements with respect to technical standards for technologies. Unfortunately, mismatches between the HMI and the coordination and synchronization demands of the underlying human-automation architecture, can lead to system breakdowns. A methodology is needed that both designers and regulators can utilize to evaluate the expected performance of a new technology given potential human-automation architectures. Three experiments were conducted to inform the minimum HMI requirements a detect and avoid system for unmanned aircraft systems (UAS). The results of the experiments provided empirical input to specific minimum operational performance standards that UAS manufacturers will have to meet in order to operate UAS in the National Airspace System (NAS). These studies represent a success story for how to objectively and systematically evaluate prototype technologies as part of the process for developing regulatory requirements. They also provide an opportunity to reflect on the lessons learned from a recent research effort in order to improve the methodology for defining technology requirements for regulators in the future. The biggest shortcoming of the presented research program was the absence of the explicit definition, generation and analysis of potential human-automation architectures. Failure to execute this step in the research process resulted in less efficient evaluation of the candidate prototypes technologies in addition to the complete absence of different approaches to human-automation cooperation. For example, all of the prototype technologies that were evaluated in the research program assumed a human-automation architecture that relied on serial processing from the automation to the human. While this type of human-automation architecture is typical across many different technologies and in many different domains, it ignores different architectures where humans and automation work in parallel. Defining potential human-automation architectures a priori also allows regulators to develop scenarios that will stress the performance boundaries of the technology during the evaluation phase. The importance of adding this step of generating and evaluating candidate human-automation architectures prior to formal empirical evaluation is discussed.

human systems integration↗
NASA NTRS2003

An On-line Technology Information System (OTIS) for Advanced Life Support

OTIS is an on-line communication platform designed for smooth flow of technology information between advanced life support (ALS) technology developers, researchers, system analysts, and managers. With pathways for efficient transfer of information, several improvements in the ALS Program will result. With OTIS, it will be possible to provide programmatic information for technology developers and researchers, technical information for analysts, and managerial decision support. OTIS is a platform that enables the effective research, development, and delivery of complex systems for life support. An electronic data collection form has been developed for the solid waste element, drafted by the Solid Waste Working Group. Forms for other elements (air revitalization, water recovery, food processing, biomass production and thermal control) will also be developed, based on lessons learned from the development of the solid waste form. All forms will be developed by consultation with other working groups, comprised of experts in the area of interest. Forms will be converted to an on-line data collection interface that technology developers will use to transfer information into OTIS. Funded technology developers will log in to OTIS annually to complete the element- specific forms for their technology. The type and amount of information requested expands as the technology readiness level (TRL) increases. The completed forms will feed into a regularly updated and maintained database that will store technology information and allow for database searching. To ensure confidentiality of proprietary information, security permissions will be customized for each user. Principal investigators of a project will be able to designate certain data as proprietary and only technical monitors of a task, ALS Management, and the principal investigator will have the ability to view this information. The typical OTIS user will be able to read all non-proprietary information about all projects.Interaction with the database will occur over encrypted connections, and data will be stored on the server in an encrypted form. Implementation of OTIS will initiate a community-accessible repository of technology development information. With OTIS, ALS element leads and managers will be able to carry out informed technology selection for programmatic decisions. OTIS will also allow analysts to make accurate evaluations of technology options. Additionally, the range and specificity of information solicited will help educate technology developers of program needs. With augmentation, OTIS reporting is capable of replacing the current fiscal year-end reporting process. Overall, the system will enable more informed R&TD decisions and more rapid attainment of ALS Program goals.

Levri, Julie A.↗
NASA NTRS2006

Communal Cooperation in Sensor Networks for Situation Management

Situation management is a rapidly evolving science where managed sources are processed as realtime streams of events and fused in a way that maximizes comprehension, thus enabling better decisions for action. Sensor networks provide a new technology that promises ubiquitous input and action throughout an environment, which can substantially improve information available to the process. Here we describe a NASA program that requires improvements in sensor networks and situation management. We present an approach for massively deployed sensor networks that does not rely on centralized control but is founded in lessons learned from the way biological ecosystems are organized. In this approach, fully distributed data aggregation and integration can be performed in a scalable fashion where individual motes operate based on local information, making local decisions that achieve globally-meaningful results. This exemplifies the robust, fault-tolerant infrastructure required for successful situation management systems.

Jones, Kennie H.↗
NASA NTRSDate not supplied

Semantic Search with Sentence-BERT for Design Information Retrieval

Managing and referencing design knowledge is a critical activity in the design process. However, reliably retrieving useful knowledge can be a frustrating experience for users of knowledge management systems due to inherent limitations of standard keyword-based searches. In this research, we consider the task of retrieving relevant lessons learned from the NASA Lessons Learned Information System (LLIS). To this end, we apply a state-of-the-art natural language processing (NLP) technique for information retrieval (IR): semantic search with sentence-BERT, which is a modification of a Bidirectional Encoder Representations from Transformers (BERT) model that uses siamese and triplet network architectures to obtain semantically meaningful sentence embeddings. While the pre-trained sBERT model performs well out-of-the-box, we further fine-tune the model on data from the LLIS so that it learns on design engineering-relevant vocabulary. We quantify the improvement in query results using both standard sBERT and fine-tuned sBERT over a keyword search. Our use case throughout the paper is to use queries related to specific requirements from a NASA project. Fine tuning the sBERT model on LLIS data yields a mean average precision (MAP) of 0.807 on queries based on information needs from a real NASA project. Results indicate that applying state-of-the-art natural language processing techniques, especially when finetuned using engineering data, to design information retrieval tasks shows significant promise in modernizing design knowledge management systems.

Hannah S. Walsh↗
NASA NTRSDate not supplied

Lessons Learned from NASA Goddard Space Flight Center’s Product Development Lead Training Schedule and Cost Development Workshop: Continuous Improvement

This presentation provides a status of the Goddard Space Flight Center (GSFC) effort to increase foundational knowledge of Product Development Leads (PDLs) in schedule and cost management including earned value management (EVM). In 2012, GSFC’s Engineering and Technology Directorate (ETD) implemented an in-house training program to prepare PDLs for managing the technical, cost, schedule, and risk aspects of spaceflight systems to meet their subsystem commitments. Developed in-house, the PDL training program provides an integrated approach to requirements development, risk, schedule and cost management, EVM, performance tracking, and other areas. The program has been held twice yearly since its inception with 531 participating and 451 completing the curriculum. In 2017, the program won the Robert H. Goddard award for Quality and Process Improvement. Program development and evolution were presented in the 2018 NASA Schedule and Cost Symposium. The presentation was so well received that this year we focus on one workshop within the program: Schedule and Cost Development, including EVM. We examine the on-going logic modeling process and how participant and stakeholder data influence workshop content and design, and how the disciplines of schedule and cost contribute to mission success. In this presentation we refresh you on how the approach integrates lecture, small group discussion, estimating, case study exercises, and problem solving. We update you on the data collected from participants and stakeholders, and we discuss how we use these data to measure training effectiveness. Specific topics include: • How the logic model is used as the backbone for continuous program improvement, • How feedback influences implementation and curriculum updates, • How data collection and analysis inform workshop content and development, including participant discoveries of EVM data, • How including the resource analyst and planner in the product development team supports project success.

Lessons Learned↗
NASA NTRS2013

Lessons Learned for Improving Spacecraft Ground Operations

NASA policy requires each Program or Project to develop a plan for how they will address Lessons Learned. Projects have the flexibility to determine how best to promote and implement lessons learned. A large project might budget for a lessons learned position to coordinate elicitation, documentation and archival of the project lessons. The lessons learned process crosses all NASA Centers and includes the contactor community. o The Office of The Chief Engineer at NASA Headquarters in Washington D.C., is the overall process owner, and field locations manage the local implementation. One tool used to transfer knowledge between program and projects is the Lessons Learned Information System (LLIS). Most lessons come from NASA in partnership with support contractors. A search for lessons that might impact a new design is often performed by a contractor team member. Knowledge is not found with only one person, one project team, or one organization. Sometimes, another project team, or person, knows something that can help your project or your task. Knowledge sharing is an everyday activity at the Kennedy Space Center through storytelling, Kennedy Engineering Academy presentations and through searching the Lessons Learned Information system. o Project teams search the lessons repository to ensure the best possible results are delivered. o The ideas from the past are not always directly applicable but usually spark new ideas and innovations. Teams have a great responsibility to collect and disseminate these lessons so that they are shared with future generations of space systems designers. o Leaders should set a goal for themselves to host a set numbers of lesson learned events each year and do more to promote multiple methods of lessons learned activities. o High performing employees are expected to share their lessons, however formal knowledge sharing presentation are not the norm for many employees.

Bell, Michael↗
NASA NTRS2017

Lessons Learned While Exploring Cloud-Native Architectures for NASA EOSDIS Applications and Systems

NASA's Earth Observing System (EOS) is a coordinated series of satellites for long term global observations. NASA's Earth Observing System Data and Information System (EOSDIS) is a multi-petabyte-scale archive of environmental data that supports global climate change research by providing end-to-end services from EOS instrument data collection to science data processing to full access to EOS and other earth science data. On a daily basis, the EOSDIS ingests, processes, archives and distributes over 3 terabytes of data from NASA's Earth Science missions representing over 6000 data products ranging from various types of science disciplines. EOSDIS has continually evolved to improve the discoverability, accessibility, and usability of high-impact NASA data spanning the multi-petabyte-scale archive of Earth science data products. Reviewed and approved by Chris Lynnes.

Cumulus↗
NASA NTRSDate not supplied

Informing Disaster Response: An Introduction to the NASA Disaster Response Coordination System

Satellite observations provide information about the Earth that can be critical to building situational awareness and filling in data gaps during disaster response. The National Aeronautics and Space Administration (NASA) Earth Science Division’s Disasters Program aims to advance Earth science data and information to support management decisions that prevent or mitigate the impacts of disasters. In support of this goal, NASA’s Disaster Response Coordination System (DRCS) manages a One-NASA approach to coordinate and mobilize the Agency’s assets and expertise to provide geospatial information during disasters. The purpose of the DRCS is to advance the utility of Earth observation information for supporting disaster response decision support, build skilled and effective response communities through improved coordination, engagement, and learning, and reduce impact to lives and livelihoods by empowering communities to respond to disasters more effectively. The DRCS employs a user-centered, activation framework that begins with direct requests from responders and ends with after-action assessments that feed lessons learned and process improvements. This poster will introduce the DRCS model and approach to expanding the use of Earth observations and geospatial information to support disaster response, share use cases for recent event activations, and highlight initial lessons learned.

Disaster Response↗
NASA NTRS2007

The MSFC Systems Engineering Guide: An Overview and Plan

As systems and subsystems requirements become more complex in the pursuit of the exploration of space, advanced technology will demand and require an integrated approach to the design and development of safe and successful space vehicles and there products. System engineers play a vital and key role in transforming mission needs into vehicle requirements that can be verified and validated. This will result in a safe and cost effective design that will satisfy the mission schedule. A key to successful vehicle design within systems engineering is communication. Communication, through a systems engineering infrastructure, will not only ensure that customers and stakeholders are satisfied but will also assist in identifying vehicle requirements; i.e. identification, integration and management. This vehicle design will produce a system that is verifiable, traceable, and effectively satisfies cost, schedule, performance, and risk throughout the life-cycle of the product. A communication infrastructure will bring about the integration of different engineering disciplines within vehicle design. A system utilizing these aspects will enhance system engineering performance and improve upon required activities such as Development of Requirements, Requirements Management, Functional Analysis, Test, Synthesis, Trade Studies, Documentation, and Lessons Learned to produce a successful final product. This paper will describe the guiding vision, progress to date and the plan forward for development of the Marshall Space Flight Center (MSFC) Systems Engineering Guide (SEG), a virtual systems engineering handbook and archive that will describe the system engineering processes that are used by MSFC in the development of complex systems such as the Ares launch vehicle. It is the intent of this website to be a "One Stop Shop" for our systems engineers that will provide tutorial information, an overview of processes and procedures and links to assist system engineering with guidance and references, and provide an archive of systems engineering artifacts produced by the many NASA projects developed and managed by MSFC over the years.

Shelby, Jerry A.↗
NASA NTRS2020

Broadening JPL’s Mission Formulation Paradigm with Human Centered Design

Within NASA’s highly competitive environment for funding, Human Centered Design (HCD) and cybernetics could provide advantages to proposers during the mission formulation phase. Opportunities are limited when it comes to funding new science missions. Proposers are challenged to make a compelling case about the scientific desirability, technical feasibility, and resource viability of their concepts. Organizations follow established processes for proposal development using teams that typically include scientists, engineers, and managers. These team members are highly experienced subject matter experts (SME) in their own disciplines, and can respond to requirements from the solicitation. However, they are typically not trained as designers and communicators. Their approach is rooted within NASA’s science and technology paradigm. How can we improve the proposal development process, refine workflow between team members, and deliver clear and appealing offerings to the stakeholders and evaluators? These questions have been addressed by today’s most innovative companies (e.g., Apple, Google, 3M, Dyson), where the design process is not limited simply to engineering and management, but involves an all-encompassing approach drawing from fields such as social sciences, design, and the arts. Like these commercial enterprises, NASA currently employs systems thinking and integrated design, but can benefit further by moving beyond its current practices, which are mostly driven by rigid engineering, technology, science, and project management considerations. At JPL’s Innovation Foundry and through the Solar System Mission Formulation Office, we broadened this paradigm by including HCD in the mission formulation workflow. Our goal was to create a proposal with improved clarity and appeal, thus helping our team to communicate its message and aid evaluators with their work. In this paper we provide examples and lessons learned from our recent proposal development effort using HCD. We discuss touch points where we infused non-linear designerly approaches and cybernetic circularity into the workflow. Implemented design topics include operational design for team building; process design throughout distinct phases of the proposal development and writing process; communication design for streamlined exchange of information within the team and to stakeholders; interaction design; graphic design; and creating boundary objects. While these approaches may feel new or foreign to SMEs and managers in the aerospace community, they produced significant benefits in this mission formulation effort. We will describe how such approaches can be used to broaden NASA’s technology-driven paradigm through design, thus creating an environment which fosters innovation, improved communication, and strategic advantage for proposers and their organizations.

Turner, Neal↗
NASA NTRS2019

"Sensor Web Evolution - Webs of Webs for NASA Science - Focus on small Uninhabited Aerial Systems (sUAS)"

This paper will describe the evolution of information collection, derivation and delivery mechanisms in webs of NASA sensor webs, with a focus on recent advancements in small Uninhabited Aerial Systems (sUAS). I will discuss the movement to "Fog Computing", also known as Edge Computing. Fog Computing facilitates the distribution of common operations and networking between edge devices and cloud computing facilities, optimizing the production of actionable intelligence. Initially, sUASs utilized onboard data collection as standard, with minimal data downloaded directly. Information products were derived in conventional computational environments, generally desk top computers, and information products made available to the Science Community in weeks or months. With the increased availability, and increasingly lower costs, of beyond line of sight (BLOS) satellite based communication, transmission rates and data volumes increased, and processing migrated to Cloud based services. Contemporary sUASs are moving some of that information product derivation to on vehicle services, and are creating a distributed Cloud/Fog environment. I will describe the technological advances that have made this possible, including low power multi-core Central Processing Units (CPU), and, more recently, the availability of high end Graphical Processing Units (GPU) that consume only a few watts. Intelligent system software, leveraging these hardware advances, finally allows for information product generation on-board, rather than simple data collection. Additionally, intelligent flight control systems now support mutual vehicle to vehicle collaboration, allowing sUASs to create ad-hoc sensor webs on demand, as required. Also discussed will be the lessons learned by the Authors' development of data systems for NASA's large High Altitude Long Endurance (HALE) UASs like Predator and Global Hawk, and how those lessons are being applied to sUAS development. This paper will focus on application, rather a deep dive into the technology, and will highlight improving data management through these new technologies.

Sensor Web↗
NASA NTRSDate not supplied

UASs in the VOG/Edge/FOG Sensor Web Environment

This paper will describe the evolution of information collection, derivation and delivery mechanisms in sensor webs utilizing Uninhabited Aerial Systems (UAS).We will discuss the movement to "Fog Computing", also known as Edge Computing. Fog Computing facilitates the distribution of common operations and networking between edge devices and cloud computing facilities, optimizing the production of actionable intelligence. Initially, UASs utilized onboard data collection as standard, with minimal data downloaded directly. Information products were derived in conventional computational environments, generally desk top computers, and information products made available to the Science Community in weeks or months. With the increased availability, and increasingly lower costs, of beyond line of sight (BLOS) satellite based communication, transmission rates and data volumes increased, and processing migrated to Cloud based services. Contemporary UASs are moving some of that information product derivation to on vehicle services, and are creating a distributed Cloud/Fog environment. The Author will describe the technological advances that have made this possible, including low power multi-core Central Processing Units (CPU), and, more recently, the availability of high end Graphical Processing Units (GPU) that consume only a few watts. Intelligent system software, leveraging these hardware advances, finally allows for information product generation on-board, rather than simple data collection. Additionally, intelligent flight control systems now support mutual vehicle to vehicle collaboration, allowing UASs to create ad-hoc sensor webs on demand, as required. Also discussed will be the lessons learned by the Authors' development of data systems for NASA's large High Altitude Long Endurance (HALE) UASs like Predator and Global Hawk, and how those lessons are being applied to other UAS development This paper will focus on applications, rather a deep dive into the technology, and will highlight improving data management through these new technologies.

UAS↗
NASA NTRS2003

The X-38 Spacecraft Fault-Tolerant Avionics System

In 1995 NASA began an experimental program to develop a reusable crew return vehicle (CRV) for the International Space Station. The purpose of the CRV was threefold: (i) to bring home an injured or ill crewmember; (ii) to bring home the entire crew if the Shuttle fleet was grounded; and (iii) to evacuate the crew in the case of an imminent Station threat (i.e., fire, decompression, etc). Built at the Johnson Space Center, were two approach and landing prototypes and one spacecraft demonstrator (called V201). A series of increasingly complex ground subsystem tests were completed, and eight successful high-altitude drop tests were achieved to prove the design concept. In this program, an unprecedented amount of commercial-off-the-shelf technology was utilized in this first crewed spacecraft NASA has built since the Shuttle program. Unfortunately, in 2002 the program was canceled due to changing Agency priorities. The vehicle was 80% complete and the program was shut down in such a manner as to preserve design, development, test and engineering data. This paper describes the X-38 V201 fault-tolerant avionics system. Based on Draper Laboratory's Byzantine-resilient fault-tolerant parallel processing system and their "network element" hardware, each flight computer exchanges information on a strict timescale to process input data, compare results, and issue voted vehicle output commands. Major accomplishments achieved in this development include: (i) a space qualified two-fault tolerant design using mostly COTS (hardware and operating system); (ii) a single event upset tolerant network element board, (iii) on-the-fly recovery of a failed processor; (iv) use of synched cache; (v) realignment of memory to bring back a failed channel; (vi) flight code automatically generated from the master measurement list; and (vii) built in-house by a team of civil servants and support contractors. This paper will present an overview of the avionics system and the hardware implementation, as well as the system software and vehicle command & telemetry functions. Potential improvements and lessons learned on this program are also discussed.

Kouba,Coy↗
NASA NTRS2010

Utilization of Hydrologic Remote Sensing Data in Land Surface Modeling and Data Assimilation: Current Status and Challenges

Recent advances in remote sensing technologies have enabled the monitoring and measurement of the Earth's land surface at an unprecedented scale and frequency. The myriad of these land surface observations must be integrated with the state-of-the-art land surface model forecasts using data assimilation to generate spatially and temporally coherent estimates of environmental conditions. These analyses are of critical importance to real-world applications such as agricultural production, water resources management and flood, drought, weather and climate prediction. This need motivated the development of NASA Land Information System (LIS), which is an expert system encapsulating a suite of modeling, computational and data assimilation tools required to address challenging hydrological problems. LIS integrates the use of several community land surface models, use of ground and satellite based observations, data assimilation and uncertainty estimation techniques and high performance computing and data management tools to enable the assessment and prediction of hydrologic conditions at various spatial and temporal scales of interest. This presentation will focus on describing the results, challenges and lessons learned from the use of remote sensing data for improving land surface modeling, within LIS. More specifically, studies related to the improved estimation of soil moisture, snow and land surface temperature conditions through data assimilation will be discussed. The presentation will also address the characterization of uncertainty in the modeling process through Bayesian remote sensing and computational methods.

Kumar, Sujay V.↗
NASA NTRS2011

Ground Processing Affordability for Space Vehicles

Launch vehicles and most of their payloads spend the majority of their time on the ground. The cost of ground operations is very high. So, why so often is so little attention given to ground processing during development? The current global space industry and economic environment are driving more need for efficiencies to save time and money. Affordability and sustainability are more important now than ever. We can not continue to treat space vehicles as mere science projects. More RLV's (Reusable Launch Vehicles) are being developed for the gains of reusability which are not available for ELV's (Expendable Launch Vehicles). More human-rated vehicles are being developed, with the retirement of the Space Shuttles, and for a new global space race, yet these cost more than the many unmanned vehicles of today. We can learn many lessons on affordability from RLV's. DFO (Design for Operations) considers ground operations during design, development, and manufacturing-before the first flight. This is often minimized for space vehicles, but is very important. Vehicles are designed for launch and mission operations. You will not be able to do it again if it is too slow or costly to get there. Many times, technology changes faster than space products such that what is launched includes outdated features, thus reducing competitiveness. Ground operations must be considered for the full product Lifecycle, from concept to retirement. Once manufactured, launch vehicles along with their payloads and launch systems require a long path of processing before launch. Initial assembly and testing always discover problems to address. A solid integration program is essential to minimize these impacts, as was seen in the Constellation Ares I-X test rocket. For RLV's, landing/recovery and post-flight turnaround activities are performed. Multi-use vehicles require reconfiguration. MRO (Maintenance, Repair, and Overhaul) must be well-planned--- even for the unplanned problems. Defect limits and standard repairs need to be in-place as well as easily added. Many routine inspections and maintenance can be like an aircraft overhaul. Modifications and technology upgrades should be expected. Another factor affecting ground operations efficiency is trending. It is essential for RLV's, and also useful for ELV's which fly the same or similar models again. Good data analysis of technical and processing performance will determine fixes and improvements needed for safety, design, and future processing. Collecting such data on new or low-frequency vehicles is a challenge. Lessons can be learned from the Space Shuttle, or even the Concorde aircraft. For all of the above topics, efficient business systems must be established for comprehensive program management and good throughput. Drawings, specifications, and manuals for an entire launch vehicle are often in different formats from multiple vendors, plus they have proprietary constraints. Nonetheless, the integration team must ensure that all data needed is compatible and visible to each appropriate team member. Ground processing systems for scheduling, tracking, problem resolution, etc. must be well laid-out. The balance between COTS (commercial off the shelf) and custom software is difficult. Multiple customers, vendors, launch sites, and landing sites add to the complexity of efficient IT (Information Technology) tools.

Ingalls, John↗
NASA NTRSDate not supplied

Informing Disaster Response through Earth Observation: A User-Centric Model for Enhancing Disaster Response Using Geospatial Assets

Satellite observations can provide critical insights to building situational awareness and filling data gaps during disaster response. The National Aeronautics and Space Administration (NASA) Earth Science Division’s Disasters Program aims to advance Earth science data and information to support management decisions that prevent or mitigate the impacts of disasters. In support of this goal, NASA’s Disasters Response Coordination System (DRCS) employs a “One NASA” approach to coordinate and mobilize the Agency’s assets and expertise to provide geospatial information during disasters. The DRCS advances the utility of Earth observation information for supporting disaster response needs and builds skills in the emergency management and disaster response communities through improved coordination, engagement, and learning. The DRCS aims to support reduction of impact to lives and livelihoods by empowering communities to more effectively respond to disasters. The DRCS is organized across six NASA centers and managed by a project office located at NASA Langley, working in alignment with NASA Headquarters. The DRCS employs a user-centered framework that begins with requests from disaster responders (state, local, federal government and non-profits working at a national scale) and ends with after-action assessments that feed lessons learned and process improvements. This poster introduces the DRCS model and approach to expanding the use of Earth observations and geospatial information to support disaster response, share use cases for recent event activations working with decision-making organizations, and highlight initial lessons learned.

Remote Sensing↗
NASA NTRS1995

Workshop on Discovery Lessons-Learned

As part of the Discovery Program's continuous improvement effort, a Discovery Program Lessons-Learned workshop was designed to review how well the Discovery Program is moving toward its goal of providing low-cost research opportunities to the planetary science community while ensuring continued U.S. leadership in solar system exploration. The principal focus of the workshop was on the recently completed Announcement of Opportunity (AO) cycle, but the program direction and program management were also open to comment. The objective of the workshop was to identify both the strengths and weaknesses of the process up to this point, with the goal of improving the process for the next AO cycle. The process for initializing the workshop was to solicit comments from the communities involved in the program and to use the feedback as the basis for establishing the workshop agenda. The following four sessions were developed after reviewing and synthesizing both the formal feedback received and informal feedback obtained during discussions with various participants: (1) Science and Return on Investment; (2) Technology vs. Risk; Mission Success and Other Factors; (3) Cost; and (4) AO.AO Process Changes and Program Management.

Saunders, M.↗