Search NASA⌕ Search

SEARCH · Search NASA

Results for “data lifecycle”

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 181 records · Page 10
All sourcesNASA NTRSDOE OSTI
NASA NTRSDate not supplied

Firesense: Supporting Operational Partners Through Co-Development

Fire is a natural disturbance and fundamental to many ecosystems, but, across the United States and many areas globally, fires have become more common, larger and more likely to occur at the same time. This has the potential to challenge resource allocation and response and requires coordinated integration of technology and tools at the spatial and temporal scales required by practitioners who make wildland fire management decisions. In the US wildfire is currently managed across state, federal, and tribal agencies who leverage various datasets to guide management decisions. FireSense, a NASA Science Mission Directorate project, aims to develop and deliver trailblazing technology and tools for use before, during, and after wildland fires by working together with land managers and practitioners. FireSense is focused on turning information into solutions by expanding partnerships and collaborations with operational agencies to inform and deliver data and technology to support decisions for wildland fire management. Through implementation across the US and with campaign activities in a variety of landscapes, coordinated research and development work will build upon adaptive and use-inspired approaches that can be put into operation. By leveraging and complementing partner activities through coordinated investment, we support a more comprehensive and cohesive response that can advance fire science to better understand fire behavior and effects through integrated measurement, monitoring and modeling. We present updates from in-progress technology development and field campaigns within the US which include sampling and application across scales with information from multiple sensors collocated with field measurements and highlighting the importance of cross-scale observations during the fire lifecycle. Coordinated investment in new science and technology for the complete fire lifecycle supports a comprehensive and cohesive fire response that help to overcome barriers and anticipate and manage the new reality of extreme fires in a warming world.

Jacquelyn Shuman↗
NASA NTRS2020

Maintenance-optimized Modular Robotic Concepts for Planetary Surface ISRU Excavators

Modular robotic concepts are identified and evaluatedover the design and operations/maintenance lifecycle forautonomous Lunar, Mars, and partial gravity planetary surfaceexcavation and in-situ earthworks equipment. In-Situ ResourceUtilization (ISRU) is the exploitation of available resources at thesite of a landed spacecraft on the surface of another planetary body.It is intended that this ISRU excavator concept be capable ofmaterial extraction from native regolith, and will be able to operatein a variety of planetary surface environments after initial shakedownon the moon. Using heritage from highly multi-functional,reconfigurable robotic systems like the All-Terrain Hex-LimbedExtra-Terrestrial Explorer (ATHLETE), Regolith AdvancedSurface Systems Operations Robot (RASSOR), and Marsexploration rovers, we propose a flexible maintenance-optimizedmobility platform concept with quick-connect/disconnect featuresfor robotically swappable excavation implements. Dust toleranttorque transmission, power & data docking, thermal fluidconnectors, and modular avionics and instrumentation will allow forautonomous swapping of tools, replacement of spares, and longtermmaintenance of robotic excavators. The architecture includesmodular tools for conventional excavate / scoop / haul / dump /process functions of a terrestrial mining operation on Earth, but alsowill have the capability to operate and robotically maintain itselfwithout human intervention. The concepts described in this studywill provide a suite of technologies, configurations, and operationsready for inclusion into a final flight-ready excavator system.

Schuler, Jason↗
NASA NTRS2004

Transitioning to Intel-based Linux Servers in the Payload Operations Integration Center

The MSFC Payload Operations Integration Center (POIC) is the focal point for International Space Station (ISS) payload operations. The POIC contains the facilities, hardware, software and communication interface necessary to support payload operations. ISS ground system support for processing and display of real-time spacecraft and telemetry and command data has been operational for several years. The hardware components were reaching end of life and vendor costs were increasing while ISS budgets were becoming severely constrained. Therefore it has been necessary to migrate the Unix portions of our ground systems to commodity priced Intel-based Linux servers. hardware architecture including networks, data storage, and highly available resources. This paper will concentrate on the Linux migration implementation for the software portion of our ground system. The migration began with 3.5 million lines of code running on Unix platforms with separate servers for telemetry, command, Payload information management systems, web, system control, remote server interface and databases. The Intel-based system is scheduled to be available for initial operational use by August 2004 The overall migration to Intel-based Linux servers in the control center involves changes to the This paper will address the Linux migration study approach including the proof of concept, criticality of customer buy-in and importance of beginning with POSlX compliant code. It will focus on the development approach explaining the software lifecycle. Other aspects of development will be covered including phased implementation, interim milestones and metrics measurements and reporting mechanisms. This paper will also address the testing approach covering all levels of testing including development, development integration, IV&V, user beta testing and acceptance testing. Test results including performance numbers compared with Unix servers will be included. need for a smooth transition while maintaining real-time support. An important aspect of the paper will involve challenges and lessons learned. product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support. This paper will also address the deployment approach including user involvement in testing and the , This includes COTS product compatibility, implications of phasing decisions and tracking of dependencies, particularly non- software dependencies. The paper will also discuss scheduling challenges providing real-time flight support during the migration and the requirement to incorporate in the migration changes being made simultaneously for flight support.

Guillebeau, P. L.↗
NASA NTRS2016

Towards a Methodology and Tooling for Model-Based Probabilistic Risk Assessment (PRA)

A Probabilistic Risk Assessment (PRA) aims to identify and assess potential risks to system technical performance requirements for the purpose of furnishing risk insights into project decisions. PRAs have traditionally been conducted manually using software with an isolated data model. As system complexity rises it becomes difficult to ensure consistency between a PRA, the evolving system design, and other engineering analyses; the techniques for conducting PRAs must evolve to meet this challenge. This work presents progress towards a methodology and tooling for conducting a PRA by leveraging data in the system model, embedded for other purposes and analyses, to conduct a PRA. An approach for identifying the appropriate probabilistic equation for each risk scenario from a standard library is presented, which is a significant step towards the quantification of the likelihood of a risk scenario occurrence. The final calculation of the likelihood of occurrence is left as an item of future work. We also present the development of preliminary tooling to carry out the methodology on a well-formed system model. The information needed to conduct the PRA is embedded in a consistent manner in a system model, so the model-based PRA can be regularly executed as the system model changes. The ability to modify the PRA in concert with lifecycle evolution affords a project the opportunity to track the extent to which system modification impacts compliance with requirements. These aspects of this model-based PRA methodology make it capable of managing risk in increasingly complex technical systems.

Schreiner, Samuel S.↗
NASA NTRS1984

Lightning Observations above and below clouds

The quantitative optical characteristics of cloud to ground (CG) and intracloud (IC) lightning above clouds were studied. A data base of a number of pulse paramaters such as energy, rise times, pulse widths and pulse intervals was complied and categorized for first return strokes, subsequent strokes, the intracloud part of CG flashes and IC flashes. It is found that: (1) single stroke CG's are more readily distinguishable from IC flashes than multiple stroke CG's; (2) there is no significant difference between the energy of first and subsequent return stroke pulses; and (3) the pulse rise times and pulse widths are time broadened. Lightning activity in a mesoscale convective weather system (MCS) was examined. The CG flash rates average almost 50 per minute for 7 hours. It is shown that lightning above storms embedded within the MCS IC lightning activity can be much greater than CG activity at certain times in the MCS lifecycle.

Goodman, S. J.↗
NASA NTRS2024

Analyzing EOSDIS Dataset Research Outputs using Knowledge Graphs and Large Language Models

Datasets, unlike publications, can be updated over time, with each new version receiving a DOI but not always being linked to previous ones. This complicates tracking citations across a dataset’s lifecycle. We address this by integrating dataset versions and citations into a knowledge graph (KG), which helps trace dataset citations and analyze dataset usage in applied research. To categorize publications from various journals, we fine-tuned NASA IMPACT INDUS Large Language Model (LLM) on a labeled publication set, assigning publications to one of twenty applied research areas. By linking datasets to these research areas, we improved dataset searchability and discovery through these domains.

open-source↗
NASA NTRS2009

Probabilistic Risk Assessment for Decision Making During Spacecraft Operations

Decisions made during the operational phase of a space mission often have significant and immediate consequences. Without the explicit consideration of the risks involved and their representation in a solid model, it is very likely that these risks are not considered systematically in trade studies. Wrong decisions during the operational phase of a space mission can lead to immediate system failure whereas correct decisions can help recover the system even from faulty conditions. A problem of special interest is the determination of the system fault protection strategies upon the occurrence of faults within the system. Decisions regarding the fault protection strategy also heavily rely on a correct understanding of the state of the system and an integrated risk model that represents the various possible scenarios and their respective likelihoods. Probabilistic Risk Assessment (PRA) modeling is applicable to the full lifecycle of a space mission project, from concept development to preliminary design, detailed design, development and operations. The benefits and utilities of the model, however, depend on the phase of the mission for which it is used. This is because of the difference in the key strategic decisions that support each mission phase. The focus of this paper is on describing the particular methods used for PRA modeling during the operational phase of a spacecraft by gleaning insight from recently conducted case studies on two operational Mars orbiters. During operations, the key decisions relate to the commands sent to the spacecraft for any kind of diagnostics, anomaly resolution, trajectory changes, or planning. Often, faults and failures occur in the parts of the spacecraft but are contained or mitigated before they can cause serious damage. The failure behavior of the system during operations provides valuable data for updating and adjusting the related PRA models that are built primarily based on historical failure data. The PRA models, in turn, provide insight into the effect of various faults or failures on the risk and failure drivers of the system and the likelihood of possible end case scenarios, thereby facilitating the decision making process during operations. This paper describes the process of adjusting PRA models based on observed spacecraft data, on one hand, and utilizing the models for insight into the future system behavior on the other hand. While PRA models are typically used as a decision aid during the design phase of a space mission, we advocate adjusting them based on the observed behavior of the spacecraft and utilizing them for decision support during the operations phase.

dynamic fault trees↗
NASA NTRS2018

Overview of the NASA TROPICS CubeSat Constellation Mission

Recent technology advances in miniature microwave radiometers that can be hosted on very small satellites has made possible a new class of affordable constellation missions that provide very high revisit rates of tropical cyclones and other severe weather. The Time-Resolved Observations of Precipitation structure and storm Intensity with a Constellation of Smallsats (TROPICS) mission was selected by NASA as part of the Earth Venture–Instrument (EVI-3) program and is now in development with planned launch readiness in late 2019. The overarching goal for TROPICS is to provide nearly all-weather observations of 3-D temperature and humidity, as well as cloud ice and precipitation horizontal structure, at high temporal resolution to conduct high-value science investigations of tropical cyclones (TCs). TROPICS will provide rapid-refresh microwave measurements (median refresh rate better than 60 minutes for the baseline mission) over the tropics that can be used to observe the thermodynamics of the troposphere and precipitation structure for storm systems at the mesoscale and synoptic scale over the entire storm lifecycle. TROPICS will comprise a constellation of at least six CubeSats in three low-Earth orbital planes. Each CubeSat will host a high performance radiometer to provide temperature profiles using seven channels near the 118.75 GHz oxygen absorption line, water vapor profiles using three channels near the 183 GHz water vapor absorption line, imagery in a single channel near 90 GHz for precipitation measurements (when combined with higher resolution water vapor channels), and a single channel at 205 GHz that is more sensitive to precipitation-sized ice particles and low-level moisture. This observing system offers an unprecedented combination of horizontal and temporal resolution in the microwave spectrum to measure environmental and inner-core conditions for TCs on a nearly global scale and is a major leap forward in the temporal resolution of several key parameters needed for assimilation into advanced data assimilation systems capable of utilizing rapid-update radiance or retrieval data. Here, we provide an overview of the mission and an update on current status, with a focus on unique characteristics of the Cubesat system, recent performance simulations on a range of observables to be provided by the constellation, and a summary of science applications.

Blackwell, W. J.↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service.Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations.The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-to-station handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an in-orbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRSDate not supplied

Astrobee: Completed, Current, and Future Research using Free Flying Robots on the International Space Station

After four years on the International Space Station (ISS), the Astrobee Research Facility, has completed over 130 Test Sessions logging over 1000 hours of operations. Managed by the NASA ISS Program OZ office and supported by NASA Ames Research Center (ARC) in California, the Astrobee Team maintains three identical free-flying Astrobee robots for research on the ISS. As a technology demonstration platform, the Astrobee Robots are available for Guest Scientists to use for a spectrum of research capabilities. Astrobee, propelled by battery-operated fans, is designed to autonomously operate throughout most of the USOS (US Orbital Segment), with the objective of minimizing astronaut support. Astrobee carries a suite of six cameras, a two degree-of-freedom (DOF) arm with a gripper that can grasp ISS handrails and other objects, and three payload bays that provide power and data for guest science hardware. Astrobee can autonomously execute hours-long flight plans or be teleoperated from the ground or by astronauts. While the Astrobee Team continues to improve mapping and autonomous flight capabilities, one of the main goals of Astrobee Robots is to provide research opportunities for Guest Scientists. The Astrobee Robot Software (ARS) makes extensive use of the open-source Robot Operating System (ROS). The ARS can be used interchangeably with an Astrobee Simulator or as Astrobee’s onboard software. ARS features include autonomous docking and perching, real-time teleoperations from the ground, plan based autonomous tasks, multi Astrobee communication, among other capabilities. Through simulation software and ground testing laboratories, the Astrobee Team is available to support Guest Scientists during development and testing and lead real-time ISS operations. Guest Scientists can participate in this research opportunity following the Guest Science Lifecycle (GSL) shown in Figure 1: Guest Science Lifecycle below. The Astrobee Team and Guest Scientists have complete research including Gecko materials studies, RFID and sound sensing capabilities, student Robotics Programming Challenges, and Free Flyer formation flight investigations. Current science with the Astrobee Robots includes Free Flyer self-toss studies, new docking capabilities, advanced mapping resolution capabilities, and high resolution panoramic imagery. Future Guest scientists and Astrobee Team research will focus on robotics applications for future NASA missions such as Gateway and Artemis and potential experiments involving human-robot interactions. This presentation will focus on four main subjects, 1) completed, current, and future planned research using the Astrobee robots, 2) how Guest Scientist get from conception to the ISS, 3) Astrobee Facility resources available for Guest Science ground testing and real-time ISS operations support, and 4) lessons learned from four years of ISS operations.

Astrobee↗
NASA NTRS2021

On-demand Command and Control of ASTERIA with Cloud-based Ground Station Services

ASTERIA (Arcsecond Space Telescope Enabling Research in Astrophysics) was a 6-unit CubeSat technology demonstration mission that deployed from the International Space Station on November 20th, 2017. After successfully completing its 90-day primary mission that demonstrated arcsecond-level line-of-sight pointing and focal plane thermal stability for exoplanet detection, it entered an extended mission performing onboard software demonstrations to mature technology both in space and on the ground. One of the technologies was a completely cloud-based ground system leveraging Amazon Web Services (AWS) Ground Station service. Announced in December 2018 and launched in May 2019, AWS Ground Station is a fully managed ground station service that aims to reduce the overhead associated with developing and maintaining ground system infrastructure throughout the mission lifecycle. AWS Ground Station makes available the suite of features required for any ground system in support of low-Earth orbit (LEO) and medium-Earth Orbit (MEO) satellite operations on-demand and without setting up or maintaining long-term contracts. Charges are incurred on a per-minute basis for antenna usage during scheduled tracks. Support is available for S-band uplink and downlink, along with X-band narrowband and wideband downlink. Missions that use the service may reserve tracks with any licensed AWS Ground Station antennas located across each service region and have direct access to any AWS services in support of mission operations. The cloud-based architecture built around the AWS Ground Station service greatly enhanced ASTERIA mission operations by enabling end-to-end pass automation, on-demand contact scheduling and contingency planning, along with more efficient data downlink through station availability and station-tostation handovers. It incorporated open-source software, particularly NASA's AMMOS Instrument Toolkit (AIT) and Open Mission Control Technologies (OpenMCT), along with the AWS application programming interfaces (API) to the Ground Station, Elastic Compute Cloud (EC2) and Simple Storage Service (S3) services. After showcasing operability in August 2019, the team continued using and improving this novel ground system architecture until the end of mission in December 2019. This paper describes the cloud-based ground system, how it was designed, tested, and evaluated with an inorbit spacecraft, the operational capabilities that it enabled, along with lessons learned and recommendations for future missions.

Fesq, Lorraine↗
NASA NTRSDate not supplied

Run Time Improvement Efforts for the Roman Space Telescope Thermal Analysis

"Observatory thermal models for large, complex missions, such as the Wide Field InfraRed Survey Telescope (WFIRST) mission, produce an immense amount of data to be processed. Configuration management of the model throughout the project life cycle has mainly focused on which versions of the subsystem models form the current observatory level configuration. However, the results produced by the model are not nearly as well The Roman Space Telescope (RST), formerly known as the Wide Field InfraRed Survey Telescope, is the next great astrophysics observatory mission to follow the James Webb Space Telescope with a planned launch in 2026. As a large scale, flagship mission for NASA with challenging wave front error stability requirements, a single model approach for both thermal discipline analysis and thermo-optical distortion analysis has been used since the early days of the project. In alleviating the need to maintain two separate models for different analysis types, it imposes run time penalties on the thermal analysis with a large model with significant radiation heat exchange. Throughout the lifecycle of the project, the component models have steadily grown in size, resulting in a continuous growth of the overall observatory model with each update and consequently a considerable increase in the model run time. While ongoing efforts to reduce run time are continuously investigated, previous efforts had primarily focused on timestep size and total simulation time to reach quasi-equilibrium. More recently, studies were performed on the total number of radiation couplings (radks) included in the model, which has a nearly linear impact on run time, but increases exponentially with node count. As standard practice for spacecraft analysis, small radks were excluded from the temperature solution based on the assumption that their interchange/view factors have a negligible impact on heat flow. Four approaches were investigated to reduce the model run time while minimizing the impact on accuracy: (1) the Equivalent Radiation Network node, (2) Progressive Radk Inclusion as solution proceeds, (3) Targeted Radk Filtering for critical/non critical areas, and lastly (4) Representation of culled radks with Backloads. Furthermore, the investigation of model run time also revealed that cold cases took noticeably longer to run than hot cases; the root computational inefficiencies were explored along with the computation penalty of linearization of the external radks and recalculation of temperature dependent linear couplings at each timestep. This paper outlines the details of each of the above approaches and their impact on run time and model accuracy.

Thermal Analysis↗
NASA NTRSDate not supplied

Run Time Improvement Efforts for the Roman Space Telescope Thermal Analysis

Observatory thermal models for large, complex missions, such as the Wide Field InfraRed Survey Telescope (WFIRST) mission, produce an immense amount of data to be processed. Configuration management of the model throughout the project life cycle has mainly focused on which versions of the subsystem models form the current observatory level configuration. However, the results produced by the model are not nearly as well The Roman Space Telescope (RST), formerly known as the Wide Field InfraRed Survey Telescope, is the next great astrophysics observatory mission to follow the James Webb Space Telescope with a planned launch in 2026. As a large scale, flagship mission for NASA with challenging wave front error stability requirements, a single model approach for both thermal discipline analysis and thermo-optical distortion analysis has been used since the early days of the project. In alleviating the need to maintain two separate models for different analysis types, it imposes run time penalties on the thermal analysis with a large model with significant radiation heat exchange. Throughout the lifecycle of the project, the component models have steadily grown in size, resulting in a continuous growth of the overall observatory model with each update and consequently a considerable increase in the model run time. While ongoing efforts to reduce run time are continuously investigated, previous efforts had primarily focused on timestep size and total simulation time to reach quasi-equilibrium. More recently, studies were performed on the total number of radiation couplings (radks) included in the model, which has a nearly linear impact on run time, but increases exponentially with node count. As standard practice for spacecraft analysis, small radks were excluded from the temperature solution based on the assumption that their interchange/view factors have a negligible impact on heat flow. Four approaches were investigated to reduce the model run time while minimizing the impact on accuracy: (1) the Equivalent Radiation Network node, (2) Progressive Radk Inclusion as solution proceeds, (3) Targeted Radk Filtering for critical/non critical areas, and lastly (4) Representation of culled radks with Backloads. Furthermore, the investigation of model run time also revealed that cold cases took noticeably longer to run than hot cases; the root computational inefficiencies were explored along with the computation penalty of linearization of the external radks and recalculation of temperature dependent linear couplings at each timestep. This paper outlines the details of each of the above approaches and their impact on run time and model accuracy.

Thermal Analysis↗
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 NTRS2008

Problem Reporting System

The Problem Reporting System (PRS) is a Web application, running on two Web servers (load-balanced) and two database servers (RAID-5), which establishes a system for submission, editing, and sharing of reports to manage risk assessment of anomalies identified in NASA's flight projects. PRS consolidates diverse anomaly-reporting systems, maintains a rich database set, and incorporates a robust engine, which allows tracking of any hardware, software, or paper process by configuring an appropriate life cycle. Global and specific project administration and setup tools allow lifecycle tailoring, along with customizable controls for user, e-mail, notifications, and more. PRS is accessible via the World Wide Web for authorized user at most any location. Upon successful log-in, the user receives a customizable window, which displays time-critical 'To Do' items (anomalies requiring the user s input before the system moves the anomaly to the next phase of the lifecycle), anomalies originated by the user, anomalies the user has addressed, and custom queries that can be saved for future use. Access controls exist depending on a user's role as system administrator, project administrator, user, or developer, and then, further by association with user, project, subsystem, company, or item with provisions for business-to-business exclusions, limitations on access according to the covert or overt nature of a given project, all with multiple layers of filtration, as needed. Reporting of metrics is built in. There is a provision for proxy access (in which the user may choose to grant one or more other users to view screens and perform actions as though they were the user, during any part of a tracking life cycle - especially useful during tight build schedules and vacations to keep things moving). The system also provides users the ability to have an anomaly link to or notify other systems, including QA Inspection Reports, Safety, GIDEP (Government-Industry Data Exchange Program) Alert, Corrective Actions, and Lessons Learned. The PRS tracking engine was designed as a very extensible and scalable system, able to support additional applications, with future development possibilities already discussed, including Incident Surprise Anomalies (for anomalies occurring during Operations phases of NASA Flight projects), GIDEP and NASA Alerts, and others.

Potter, Don↗
NASA NTRS2013

Identity Federation and Its Importance for NASA's Future: The SharePoint Extranet Pilot

My project at Kennedy Space Center (KSC) during the spring 2013 Project Management and Systems Engineering Internship was to functionalJy test and deploy the SharePoint Extranet system and ensure successful completion of the project's various lifecycle milestones as described by NASA Procedural Requirement (NPR) 7 120.7. I worked alongside NASA Project Managers, Systems Integration Engineers, and Information Technology (IT) Professionals to pilot this collaboration capability between NASA and its External Partners. The use of identity federation allows NASA to leverage externally-issued credentials of other federal agencies and private aerospace and defense companies, versus the traditional process of granting and maintaining full NASA identities for these individuals. This is the first system of its kind at NASA and it will serve as a pilot for the Federal Government. Recognizing the novelty of this service, NASA's initial approach for deployment included a pilot period where nearby employees of Patrick Air Force Base would assist in testing and deployment. By utilizing a credential registration process, Air Force users mapped their Air Force-issued Common Access Cards (CAC) to a NASA identity for access to the External SharePoint. Once the Air Force stands up an Active Directory Federation Services (ADFS) instance within their Data Center and establishes a direct trust with NASA, true identity federation can be established. The next partner NASA is targeting for collaboration is Lockheed Martin (LMCO), since they collaborate frequently for the ORION Program. Through the use of Exostar as an identity hub, LMCO employees will be able to access NASA data on a need to know basis, with NASA ultimately managing access. In a time when every dollar and resource is being scrutinized, this capability is an exciting new way for NASA to continue its collaboration efforts in a cost and resource effective manner.

Baturin, Rebecca R.↗
NASA NTRS2008

Automated and Adaptive Mission Planning for Orbital Express

The Orbital Express space mission was a Defense Advanced Research Projects Agency (DARPA) lead demonstration of on-orbit satellite servicing scenarios, autonomous rendezvous, fluid transfers of hydrazine propellant, and robotic arm transfers of Orbital Replacement Unit (ORU) components. Boeing's Autonomous Space Transport Robotic Operations (ASTRO) vehicle provided the servicing to the Ball Aerospace's Next Generation Serviceable Satellite (NextSat) client. For communication opportunities, operations used the high-bandwidth ground-based Air Force Satellite Control Network (AFSCN) along with the relatively low-bandwidth GEO-Synchronous space-borne Tracking and Data Relay Satellite System (TDRSS) network. Mission operations were conducted out of the RDT&E Support Complex (RSC) at the Kirtland Air Force Base in New Mexico. All mission objectives were met successfully: The first of several autonomous rendezvous was demonstrated on May 5, 2007; autonomous free-flyer capture was demonstrated on June 22, 2007; the fluid and ORU transfers throughout the mission were successful. Planning operations for the mission were conducted by a team of personnel including Flight Directors, who were responsible for verifying the steps and contacts within the procedures, the Rendezvous Planners who would compute the locations and visibilities of the spacecraft, the Scenario Resource Planners (SRPs), who were concerned with assignment of communications windows, monitoring of resources, and sending commands to the ASTRO spacecraft, and the Mission planners who would interface with the real-time operations environment, process planning products and coordinate activities with the SRP. The SRP position was staffed by JPL personnel who used the Automated Scheduling and Planning ENvironment (ASPEN) to model and enforce mission and satellite constraints. The lifecycle of a plan began three weeks outside its execution on-board. During the planning timeframe, many aspects could change the plan, causing the need for re-planning. These variable factors, ranging from shifting contact times to ground-station closures and required maintenance times, are discussed along with the flexibility of the ASPEN tool to accommodate changes to procedures and the daily or long-range plan, which contributed to the success of the mission. This paper will present an introduction to ASPEN, a more in-depth discussion on its use on the Orbital Express mission, and other relative work. A description of ground operations after the SRP deliveries were made is included, and we briefly discuss lessons learned from the planning perspective and future work.

scheduling↗
NASA NTRS2016

Aerosol Complexity and Implications for Predictability and Short-Term Forecasting

There are clear NWP and climate impacts from including aerosol radiative and cloud interactions. Changes in dynamics and cloud fields affect aerosol lifecycle, plume height, long-range transport, overall forcing of the climate system, etc. Inclusion of aerosols in NWP systems has benefit to surface field biases (e.g., T2m, U10m). Including aerosol affects has impact on analysis increments and can have statistically significant impacts on, e.g., tropical cyclogenesis. Above points are made especially with respect to aerosol radiative interactions, but aerosol-cloud interaction is a bigger signal on the global system. Many of these impacts are realized even in models with relatively simple (bulk) aerosol schemes (approx.10 -20 tracers). Simple schemes though imply simple representation of aerosol absorption and importantly for aerosol-cloud interaction particle-size distribution. Even so, more complex schemes exhibit a lot of diversity between different models, with issues such as size selection both for emitted particles and for modes. Prospects for complex sectional schemes to tune modal (and even bulk) schemes toward better selection of size representation. I think this is a ripe topic for more research -Systematic documentation of benefits of no vs. climatological vs. interactive (direct and then direct+indirect) aerosols. Document aerosol impact on analysis increments, inclusion in NWP data assimilation operator -Further refinement of baseline assumptions in model design (e.g., absorption, particle size distribution). Did not get into model resolution and interplay of other physical processes with aerosols (e.g., moist physics, obviously important), chemistry

Predictability↗