SEARCH · Search NASA

Results for “product lifecycle management”

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 55 records · Page 3

All sources NASA NTRS DOE OSTI

NASA NTRS2005

Design Methods and Practices for Fault Prevention and Management in Spacecraft

Integrated Systems Health Management (ISHM) is intended to become a critical capability for all space, lunar and planetary exploration vehicles and systems at NASA. Monitoring and managing the health state of diverse components, subsystems, and systems is a difficult task that will become more challenging when implemented for long-term, evolving deployments. A key technical challenge will be to ensure that the ISHM technologies are reliable, effective, and low cost, resulting in turn in safe, reliable, and affordable missions. To ensure safety and reliability, ISHM functionality, decisions and knowledge have to be incorporated into the product lifecycle as early as possible, and ISHM must be considered as an essential element of models developed and used in various stages during system design. During early stage design, many decisions and tasks are still open, including sensor and measurement point selection, modeling and model-checking, diagnosis, signature and data fusion schemes, presenting the best opportunity to catch and prevent potential failures and anomalies in a cost-effective way. Using appropriate formal methods during early design, the design teams can systematically explore risks without committing to design decisions too early. However, the nature of ISHM knowledge and data is detailed, relying on high-fidelity, detailed models, whereas the earlier stages of the product lifecycle utilize low-fidelity, high-level models of systems and their functionality. We currently lack the tools and processes necessary for integrating ISHM into the vehicle system/subsystem design. As a result, most existing ISHM-like technologies are retrofits that were done after the system design was completed. It is very expensive, and sometimes futile, to retrofit a system health management capability into existing systems. Last-minute retrofits result in unreliable systems, ineffective solutions, and excessive costs (e.g., Space Shuttle TPS monitoring which was considered only after 110 flights and the Columbia disaster). High false alarm or false negative rates due to substandard implementations hurt the credibility of the ISHM discipline. This paper presents an overview of the current state of ISHM design,and a review of formal design methods to make recommendations about possible approaches to enable the ISHM capabilities to be designed-in at the system-level, from the very beginning of the vehicle design process.

Tumer, Irem Y.↗

NASA NTRS2002

A Virtual Mission Operations Center: Collaborative Environment

The Virtual Mission Operations Center - Collaborative Environment (VMOC-CE) intent is to have a central access point for all the resources used in a collaborative mission operations environment to assist mission operators in communicating on-site and off-site in the investigation and resolution of anomalies. It is a framework that as a minimum incorporates online chat, realtime file sharing and remote application sharing components in one central location. The use of a collaborative environment in mission operations opens up the possibilities for a central framework for other project members to access and interact with mission operations staff remotely. The goal of the Virtual Mission Operations Center (VMOC) Project is to identify, develop, and infuse technology to enable mission control by on-call personnel in geographically dispersed locations. In order to achieve this goal, the following capabilities are needed: Autonomous mission control systems Automated systems to contact on-call personnel Synthesis and presentation of mission control status and history information Desktop tools for data and situation analysis Secure mechanism for remote collaboration commanding Collaborative environment for remote cooperative work The VMOC-CE is a collaborative environment that facilitates remote cooperative work. It is an application instance of the Virtual System Design Environment (VSDE), developed by NASA Goddard Space Flight Center's (GSFC) Systems Engineering Services & Advanced Concepts (SESAC) Branch. The VSDE is a web-based portal that includes a knowledge repository and collaborative environment to serve science and engineering teams in product development. It is a "one stop shop" for product design, providing users real-time access to product development data, engineering and management tools, and relevant design specifications and resources through the Internet. The initial focus of the VSDE has been to serve teams working in the early portion of the system/product lifecycle - concept development, proposal preparation, and formulation. The VMOC-CE expands the application of the VSDE into the operations portion of the system lifecycle. It will enable meaningful and real-time collaboration regardless of the geographical distribution of project team members. Team members will be able to interact in satellite operations, specifically for resolving anomalies, through access to a desktop computer and the Internet. Mission Operations Management will be able to participate and monitor up to the minute status of anomalies or other mission operations issues. In this paper we present the VMOC-CE project, system capabilities, and technologies.

Medina, Barbara↗

NASA NTRS2011

Framework for Integrating Science Data Processing Algorithms Into Process Control Systems

A software framework called PCS Task Wrapper is responsible for standardizing the setup, process initiation, execution, and file management tasks surrounding the execution of science data algorithms, which are referred to by NASA as Product Generation Executives (PGEs). PGEs codify a scientific algorithm, some step in the overall scientific process involved in a mission science workflow. The PCS Task Wrapper provides a stable operating environment to the underlying PGE during its execution lifecycle. If the PGE requires a file, or metadata regarding the file, the PCS Task Wrapper is responsible for delivering that information to the PGE in a manner that meets its requirements. If the PGE requires knowledge of upstream or downstream PGEs in a sequence of executions, that information is also made available. Finally, if information regarding disk space, or node information such as CPU availability, etc., is required, the PCS Task Wrapper provides this information to the underlying PGE. After this information is collected, the PGE is executed, and its output Product file and Metadata generation is managed via the PCS Task Wrapper framework. The innovation is responsible for marshalling output Products and Metadata back to a PCS File Management component for use in downstream data processing and pedigree. In support of this, the PCS Task Wrapper leverages the PCS Crawler Framework to ingest (during pipeline processing) the output Product files and Metadata produced by the PGE. The architectural components of the PCS Task Wrapper framework include PGE Task Instance, PGE Config File Builder, Config File Property Adder, Science PGE Config File Writer, and PCS Met file Writer. This innovative framework is really the unifying bridge between the execution of a step in the overall processing pipeline, and the available PCS component services as well as the information that they collectively manage.

Mattmann, Chris A.↗

NASA NTRSDate not supplied

The Dark Target aerosol retrieval algorithm applied to Low Earth Orbit and GEOstationary imagers: progress towards an integrated LEO-GEO view of global aerosol

The relatively simple dark-target (DT) aerosol retrieval algorithm provides products of spectral aerosol optical depth (AOD) from measurements of multi-spectral reflectance in visible, near-infrared and shortwave infrared wavelength bands. Originally developed for Moderate-resolution Imaging Spectroradiometer (MODIS aboard Terra and Aqua) in Low-Earth Orbit (LEO), DT has been ported to Visible Infrared Imaging Suite (VIIRS aboard Suomi-NPP and NOAA-20, also in LEO), to enhanced-MODIS Airborne Simulator (eMAS, on an airborne platform), and now to sensors in GEOstationary orbit (Advanced Himawari Imager - AHI aboard Himawari-8 and Advanced Baseline Imagers – ABI aboard GOES-16 and 17). Together, these new datasets not only extend upon the 20+ year MODIS aerosol record, but also expand the temporal sampling and/or spatial resolution. Between July and October of 2019, NASA participated in two field experiments on opposite sides of the globe. These included FIREX-AQ which focused on fire and smoke in the Western U.S., and then CAMP2EX which targeted aerosol/cloud interactions around the Philippines. We have performed DT aerosol retrievals on all images from all sensors during these three months, validated against ground observations from stationary and mobile sunphotometer sites, and have begun to develop a synergy that represents semi-global observations every half hour. The resulting aerosol products are being used as context and for model assimilation, thus providing the framework for more complete characterization of global aerosol transport and lifecycle. Here, we report on progress, as well as remaining challenges such as data management, computer processing, and accounting for differences between GEO and LEO observation geometry and surface reflectance parameterization.

dark target↗

NASA NTRSDate not supplied

Surface Systems Capability Gaps for Enabling NASA’s Sustainable Lunar Operations

This paper discusses the NASA Ground, Test, and Surface Systems Taxonomy (TX-13) related capability gaps, including details of architecture, technology, engineering, and policy gaps for enabling sustainable lunar surface operations and subsequent Mars missions. Architecture gaps include standardized architectures and interfaces, multi-element systems engineering and integration, design for supportability, and nuclear payload processing and launch approach. Technology gaps, primarily focused on uncrewed surface operations, include automated/autonomous cryogenic loading, transfer, servicing, and storage of commodities; health determination and fault management; automated/autonomous planning and scheduling; automated/autonomous inspection, maintenance and repair; logistics management and reliability; launch and landing site preparation; commodity management; and advanced umbilicals and dust tolerant interfaces. Engineering gaps include high-purity propellant production for ground and surface applications and large-scale xenon servicing capabilities. The policy gap includes nuclear propulsion acceptance testing and qualification approach. Strategically identifying human/automation roles and tasks and infusing automation and autonomy practices early in a system’s lifecycle is essential for achieving the mission objectives for a sustainable human lunar presence, improving performance and mission effectiveness, reducing operations costs and reliance on humans to perform tasks, and accommodating ground communication delays.

Surface Systems↗

NASA NTRSDate not supplied

Contracting Quality Early in the Lifecycle Using AS9145 Data Deliverables

Development schedules and a highly dynamic supply chain are a challenge to developers of complex systems produced at low volume. Flaws in designs, parts and materials availability problems, poor manufacturability, and a lack of knowledge about critical items and key process attributes can be realized well before traditional second-party quality assurance activities begin. Supplier audits and product inspections may have little mitigating effect once these foundational problems have been realized. Their impacts can be significant lifecycle disruption, cost overruns, inability to deliver to plan, and even project cancellation. AS9145, Requirements for Advanced Product Quality Planning and Production Part Approval Process, can be used to drive quality engineering practices into early development lifecycles to significantly reduce this late-cycle risk and to reduce the cost of quality overall. Since its initial publication in 2016, it has had very limited adoption by the DoD, no adoption by NASA, and sparse adoption in the aerospace and defense supply chain. A task group within the Aerospace Industries Association's (AIA) Joint Strategic Quality Council (JSQC) identified that both acquirers and suppliers see as AS9145 as a cost-adder and are hesitant to use it as an alternative to late-stage-heavy quality assurance approaches. A lack of prior use creates large capability gaps in request-for-proposal (RFP) teams, proposal teams, suppliers’ quality management systems (QMS), and in experienced personnel executing the early lifecycle approach. To create a more realizable on-ramp for using AS9145 in the space and defense sectors, the AIA JSQC task team created five deliverable requirements descriptions (DRDs) that can be used in a contract to begin to engage both parties in early lifecycle quality engineering and quality assurance activities, that reduce exposure to late-stage cost and schedule collapse due to unidentified risks in design, supply chain, and manufacturability. These DRDs drive the parties to engage in planning and analysis discussions early on to understand what production risks can be known and how they will focus resources based on safety criticality and the key elements of design and construction. The suppliers and acquirers who will produce the data and information required by the DRD will be able to incrementally evolve their QMS and the acquirer will incrementally be able to track and understand the benefits of cost shifting from late to early development phases. A white paper describing this approach and the five recommended DRDs will be published by the AIA in late 2024 or early 2025.

Jeannette Plante↗

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 NTRS2010

Model Based Definition

In September 2007, the Engineering Directorate at the Marshall Space Flight Center (MSFC) created the Design System Focus Team (DSFT). MSFC was responsible for the in-house design and development of the Ares 1 Upper Stage and the Engineering Directorate was preparing to deploy a new electronic Configuration Management and Data Management System with the Design Data Management System (DDMS) based upon a Commercial Off The Shelf (COTS) Product Data Management (PDM) System. The DSFT was to establish standardized CAD practices and a new data life cycle for design data. Of special interest here, the design teams were to implement Model Based Definition (MBD) in support of the Upper Stage manufacturing contract. It is noted that this MBD does use partially dimensioned drawings for auxiliary information to the model. The design data lifecycle implemented several new release states to be used prior to formal release that allowed the models to move through a flow of progressive maturity. The DSFT identified some 17 Lessons Learned as outcomes of the standards development, pathfinder deployments and initial application to the Upper Stage design completion. Some of the high value examples are reviewed.

Rowe, Sidney E.↗

NASA NTRS2008

Human Factors in Human-Systems Integration

Any large organization whose mission is to design and develop systems for humans, and train humans needs a well-developed integration and process plan to deal with the challenges that arise from managing multiple subsystems. Human capabilities, skills, and needs must be considered early in the design and development process, and must be continuously considered throughout the development lifecycle. This integration of human needs within system design is typically formalized through a Human-Systems Integration (HSI) program. By having an HSI program, an institution or organization can reduce lifecycle costs and increase the efficiency, usability, and quality of its products because human needs have been considered from the beginning.

Fitts, David J.↗

NASA NTRSDate not supplied

The Interplay of Humor and Team Cohesion Over Time

Team bonding and interpersonal relationships are increasingly important as we continue understanding the effects of the pandemic on team dynamics. Specifically, team cohesion, defined as having a sense of belonging and commitment towards the group, has been found to be important for key team outcomes such as performance, relationships, and productivity (Beal, Cohen, Burke, & McLendon, 2003; Bell & Marentette, 2011). Research has stressed the benefits of positive humor on cohesion, with humor creating positive emotions and decreasing social distance (e.g., Robert & Wilbanks, 2012; Robinson & Smith-Lovin, 2001; Romero & Pescosolido, 2008). However, research around the impact of negative humor on cohesion is scarce. This study aims to examine the impact of both positive and negative humor on cohesion for teams over time. The longitudinal design allows us to examine the interplay of humor and cohesion throughout a team’s lifecycle to guide relationship development and management (Romero & Pescosolido, 2008). Humor is defined as remarks recognized as amusing or funny (Martin, 2007). Positive humor can be categorized as good-natured aimed to create mutual agreement, while negative humor is defined as aggressive, hostile, and unreciprocated (Coan & Gottman, 2007). Research has concluded the many benefits of positive humor, showing it can increase open communication, social support, and create a pleasant environment (Martineau, 1972; Robinson & Smith-Lovin, 2001; Romero & Pescosolido, 2008). The Humor Wheel model suggests that positive humor is contagious due to the positive affect produced and mimicked (Lehmann-Willenbrock & Allen 2014). Research has suggested positive humor would increase over time based on the norm of reciprocity; those treated positively are likely to respond similarly (Gouldner, 1960). Multiple parties’ involvement in humor exchanges highlights the interpersonal nature of humor. Thus, long-term consequences on relationships should be considered, such as cohesion (Robert & Wilbanks, 2012). It would be instrumental to understand how humor interactions could weaken or strengthen group cohesion through relational and emotional bonds over time (Martineau, 1972; Romero & Pescosolido, 2008). Positive humor should fundamentally increase team cohesion (Mesmer-Magnus, Glew, & Viswesvaran, 2012; Walter & Baruch, 2008) by promoting group harmony, team member attractiveness, and ingroup identity (Holmes, 2006). Thus, it is expected there is a positive relationship between positive humor and team cohesion over time (hypothesis 1). Humor is not always beneficial, especially when it elicits negative emotions (Dikkers, Doosje, & de Lange, 2011). Negative humor can be used to humiliate, tease, or insult (Coan & Gottman, 2007; Collinson, 1988; Romero & Cruthirds, 2006). It tends to cause distress and damage relationships, and in turn, decrease organizational performance and production (Avolio, Howell, & Sosik, 1999; Janes & Olson, 2000; Yerkes, 2001). Research concludes negative humor may create subgroups and decrease cooperation (Romero & Arendt, 2011). Research has also indicated positive implications for negative humor under specific circumstances. Negative humor could help to solidify ingroup identity and strengthen bonds when directed outside the team (Terrion & Ashforth, 2002; Thomae & Pina, 2015). For example, sport teams may use negative humor towards their opponent before a game, which emphasizes their differences and lowers the status and power of their opponent, ultimately promoting solidarity and cohesion inside the group. For this study, it is anticipated that negative humor toward other teammates will decrease team cohesion over time due to the damage to relationships and negative affect produced (Duncan, Smeltzer, & Leap, 1990; Maples, Dupey, Torres‐Rivera, Phan, Vereen, & Garrett, 2001). We also predicted that negative humor focused on something or someone outside the team will increase cohesion by enhancing ingroup ties and creating a common identity (Thomae & Pina, 2015). Thus, the relationship between negative humor and cohesion will be moderated by the target of the humor. The relationship will be negative when the target is within the team and positive when the target is outside (hypothesis 2).

Melissa M. Vazquez↗

NASA NTRS1994

SCOS 2: An object oriented software development approach

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

Symonds, Martin↗

NASA NTRSDate not supplied

End-user Assessment of the NASA SPoRT GLM Stoplight Product

National Weather Service (NWS) offices monitor and forecast the threat for lightning within their County Warning Areas for various impact-based decision support services (IDSS). These forecasts are provided routinely for aviation operations, but irregularly for large-scale, outdoor events, which typically have varying safety requirements with regards to lightning. Lightning monitoring and forecasting can require synthesizing a plethora of data, so products that make this process more efficient and effective are sought by the operational community. The NASA Short-term Prediction Research and Transition (SPoRT) Center has begun to develop several products to address these operational challenges during the lifecycle of lightning activity, and conduct evaluations in concentrated (Research-to-Operations/Operations-to-Research) efforts. The product evaluated for this study is the Geostationary Lightning Mapper (GLM) Stoplight product, which addresses lightning safety specifically with regards to lightning recency and cessation. The GLM Stoplight product displays the spatial extent of lightning and uses color-coded pixels to show the recency of lightning in 10-minute increments. This presentation highlights results from an assessment of the GLM Stoplight product by select NWS offices, as well as emergency managers, that took place over a 5-week period from May 1st to June 2nd. Feedback was collected on the GLM Stoplight product and on a new and interactive lightning viewer, which allowed participants to tailor visualization of the product based on their location and desired application. Results will help NASA SPoRT gain a better understanding of how forecasters and emergency managers use lightning data for safety applications. In addition, the assessment will inform research on any necessary modifications to this and future lightning products to assist end users.

Kelley Murphy↗

NASA NTRS2016

The Core Flight System (cFS) Community: Providing Low Cost Solutions for Small Spacecraft

In February 2015 the NASA Goddard Space Flight Center (GSFC) completed the open source release of the entire Core Flight Software (cFS) suite. After the open source release a multi-NASA center Configuration Control Board (CCB) was established that has managed multiple cFS product releases. The cFS was developed and is being maintained in compliance with the NASA Class B software development process requirements and the open source release includes all Class B artifacts. The cFS is currently running on three operational science spacecraft and is being used on multiple spacecraft and instrument development efforts. While the cFS itself is a viable flight software (FSW) solution, we have discovered that the cFS community is a continuous source of innovation and growth that provides products and tools that serve the entire FSW lifecycle and future mission needs. This paper summarizes the current state of the cFS community, the key FSW technologies being pursued, the development/verification tools and opportunities for the small satellite community to become engaged. The cFS is a proven high quality and cost-effective solution for small satellites with constrained budgets.

System↗

NASA NTRS2019

Requirements Development and Management on the Psyche Project

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

Elkins-Tanton, Linda T.↗

NASA NTRS2008

Juno Mission Simulation

The Juno spacecraft is planned to launch in August of 2012 and would arrive at Jupiter four years later. The spacecraft would spend more than one year orbiting the planet and investigating the existence of an ice-rock core; determining the amount of global water and ammonia present in the atmosphere, studying convection and deep- wind profiles in the atmosphere; investigating the origin of the Jovian magnetic field, and exploring the polar magnetosphere. Juno mission management is responsible for mission and navigation design, mission operation planning, and ground-data-system development. In order to ensure successful mission management from initial checkout to final de-orbit, it is critical to share a common vision of the entire mission operation phases with the rest of the project teams. Two major challenges are 1) how to develop a shared vision that can be appreciated by all of the project teams of diverse disciplines and expertise, and 2) how to continuously evolve a shared vision as the project lifecycle progresses from formulation phase to operation phase. The Juno mission simulation team addresses these challenges by developing agile and progressive mission models, operation simulations, and real-time visualization products. This paper presents mission simulation visualization network (MSVN) technology that has enabled a comprehensive mission simulation suite (MSVN-Juno) for the Juno project.

space vehicles↗

NASA NTRSDate not supplied

End-User Assessment of the NASA SPoRT Lightning AI Product

The NASA Short-term Prediction Research and Transition (SPoRT) Center has begun to develop products to address operational challenges and enhance safety during the lifecycle of lightning activity, and conduct evaluations in concentrated R2O/O2R efforts. The product evaluated for this study is Lightning Artificial Intelligence (A.I.), which predicts the probability of lightning out to 15 minutes in advance and spatially maps it using filled color contours. Lightning A.I. uses reflectivity, differential reflectivity, and correlation coefficient data from a subset of radars within the NEXRAD network to generate lightning probabilities at approximately 2 km resolution. The domains, spanning 145 x 145 km are centered over NASA-affiliated centers across the CONUS and use radar data which are closest in proximity. Lightning A.I. was developed with intended use by emergency managers at NASA centers. However, National Weather Service (NWS) offices are also often tasked with monitoring and forecasting the threat for lightning within their County Warning Areas for various impact-based decision support services. These forecasts are typically provided for aviation operations and large-scale, outdoor events, which may have varying safety requirements for decision-making based on lightning proximity and recency. The NASA SPoRT center conducted an assessment of the operational uses of Lightning A.I by various collaborative NWS Offices from late July into early September. This assessment included feedback from participants on both the product itself as well as its accessibility within the new, interactive NASA SPoRT Lightning Viewer. This presentation will include background information about Lightning A.I. and highlight results from this assessment. The feedback from the assessment will be used to inform research on any necessary modifications to this and future lightning products to assist end users.

Kelley Murphy↗

NASA NTRS2016

State of the Carbon Cycle - Consequences of Rising Atmospheric CO2

The rise of atmospheric CO2, largely attributable to human activity through fossil fuel emissions and land-use change, has been dampened by carbon uptake by the ocean and terrestrial biosphere. We outline the consequences of this carbon uptake as direct and indirect effects on terrestrial and oceanic systems and processes for different regions of North America and the globe. We assess the capacity of these systems to continue to act as carbon sinks. Rising CO2 has decreased seawater pH; this process of ocean acidification has impacted some marine species and altered fundamental ecosystem processes with further effects likely. In terrestrial ecosystems, increased atmospheric CO2 causes enhanced photosynthesis, net primary production, and increased water-use efficiency. Rising CO2 may change vegetation composition and carbon storage, and widespread increases in water use efficiency likely influence terrestrial hydrology and biogeochemical cycling. Consequences for human populations include changes to ecosystem services including cultural activities surrounding land use, agricultural or harvesting practices. Commercial fish stocks have been impacted and crop production yields have been changed as a result of rising CO2. Ocean and terrestrial effects are contingent on, and feedback to, global climate change. Warming and modified precipitation regimes impact a variety of ecosystem processes, and the combination of climate change and rising CO2 contributes considerable uncertainty to forecasting carbon sink capacity in the ocean and on land. Disturbance regime (fire and insects) are modified with increased temperatures. Fire frequency and intensity increase, and insect lifecycles are disrupted as temperatures move out of historical norms. Changes in disturbance patterns modulate the effects of rising CO2 depending on ecosystem type, disturbance frequency, and magnitude of events. We discuss management strategies designed to limit the rise of atmospheric CO2 and reduce uncertainty in forecasts of decadal and centennial feedbacks of rising atmospheric CO2 on carbon storage.

Carbon Cycle↗

NASA NTRS2020

Integrated Concurrent Engineering Teams for Increased Efficiency in Flight Projects

A highly integrated Concurrent Engineering Team (CET) within a flight project evolves in its function and has the potential to provide many benefits through the project lifecycle. The benefits include superior systems-oriented design products, as well as overall improved project efficiency and higher-performing interpersonal relationships within the project. If physically integrated, this can manifest as a Concurrent Engineering Center (CEC) centrally located within a project’s physical office space. Here we discuss the process to establish and maintain a tightly integrated engineering and design team for providing highly streamlined service to the project, including a cost/benefits analysis discussion.

Flight Project↗