Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “distributed resources”

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 451 records · Page 25

VEDA Visualization Exploration & Data Analysis

Why? - Interdisciplinary science depends on large amount of Earth science data and computational resources - Working with these datasets is non-trivial - Big data science requires advanced distributed computing knowledge What? VEDA is an open platform that brings key Earth science datasets next to open source tools for data processing, analysis, visualization, and exploration in a managed and more accessible computing environment.

Manil Maskey↗

Volatiles Investigating Polar Exploration Rover

The Volatiles Investigating Polar Exploration Rover (VIPER) will land in the southern polar region of the Moon and spend approximately 100-days prospecting for water ice. The information returned by VIPER will help determine how we can harvest the Moon's resources for future human space exploration. This information will also provide insight into the distribution and origin of water and other volatiles across the solar system. In this short talk, I will provide a brief overview of the VIPER mission, discuss some of the unique design features of the VIPER rover, and summarize VIPER's multi-modal operations approach.

lunar robotics↗

Rover Traverse Planning to Support a Lunar Polar Volatiles Mission

Studies of lunar polar volatile depositsare of interest for scientific purposes to understandthe nature and evolution of the volatiles, and alsofor exploration reasons as a possible in situ resource toenable long term exploration and settlement of theMoon. Both theoretical and observational studies havesuggested that significant quantities of volatiles exist inthe polar regions, although the lateral and horizontaldistribution remains unknown at the km scale and finerresolution. A lunar polar rover mission is required tofurther characterize the distribution, quantity, andcharacter of lunar polar volatile deposits at thesehigher spatial resolutions. Here we present two casestudies for NASA’s Resource Prospector (RP) missionconcept for a lunar polar rover and utilize this missionarchitecture and associated constraints to evaluatewhether a suitable landing site exists to support an RPflight mission.

NASAaEuro(TM)s Resource Prospector (RP) mission↗

The Suomi National Polar-Orbiting Partnership (SNPP): Continuing NASA Research and Applications

The Suomi National Polar-orbiting Partnership (SNPP) satellite was successfully launched into a polar orbit on October 28, 2011 carrying 5 remote sensing instruments designed to provide data to improve weather forecasts and to increase understanding of long-term climate change. SNPP provides operational continuity of satellite-based observations for NOAA's Polar-orbiting Operational Environmental Satellites (POES) and continues the long-term record of climate quality observations established by NASA's Earth Observing System (EOS) satellites. In the 2003 to 2011 pre-launch timeframe, NASA's SNPP Science Team assessed the adequacy of the operational Raw Data Records (RDRs), Sensor Data Records (SDRs), and Environmental Data Records (EDRs) from the SNPP instruments for use in NASA Earth Science research, examined the operational algorithms used to produce those data records, and proposed a path forward for the production of climate quality products from SNPP. In order to perform these tasks, a distributed data system, the NASA Science Data Segment (SDS), ingested RDRs, SDRs, and EDRs from the NOAA Archive and Distribution and Interface Data Processing Segments, ADS and IDPS, respectively. The SDS also obtained operational algorithms for evaluation purposes from the NOAA Government Resource for Algorithm Verification, Independent Testing and Evaluation (GRAVITE). Within the NASA SDS, five Product Evaluation and Test Elements (PEATEs) received, ingested, and stored data and performed NASA's data processing, evaluation, and analysis activities. The distributed nature of this data distribution system was established by physically housing each PEATE within one of five Climate Analysis Research Systems (CARS) located at either at a NASA or a university institution. The CARS were organized around 5 key EDRs directly in support of the following NASA Earth Science focus areas: atmospheric sounding, ocean, land, ozone, and atmospheric composition products. The PEATES provided the system level interface with members of the NASA SNPP Science Team and other science investigators within each CARS. A sixth Earth Radiation Budget CARS was established at NASA Langley Research Center (NASA LaRC) to support instrument performance, data evaluation, and analysis for the SNPP Clouds and the Earth's Radiant Budget Energy System (CERES) instrument. Following the 2011 launch of SNPP, spacecraft commissioning, and instrument activation, the NASA SNPP Science Team evaluated the operational RDRs, SDRs, and EDRs produced by the NOAA ADS and IDPS. A key part in that evaluation was the NASA Science Team's independent processing of operational RDRs and SDRs to EDRs using the latest NASA science algorithms. The NASA science evaluation was completed in the December 2012 to April 2014 timeframe with the release of a series of NASA Science Team Discipline Reports. In summary, these reports indicated that the RDRs produced by the SNPP instruments were of sufficiently high quality to be used to create data products suitable for NASA Earth System science and applications. However, the quality of the SDRs and EDRs were found to vary greatly when considering suitability for NASA science. The need for improvements in operational algorithms, adoption of different algorithmic approaches, greater monitoring of on-orbit instrument calibration, greater attention to data product validation, and data reprocessing were prominent findings in the reports. In response to these findings, NASA, in late 2013, directed the NASA SNPP Science Team to use SNPP instrument data to develop data products of sufficiently high quality to enable the continuation of EOS time series data records and to develop innovative, practical applications of SNPP data. This direction necessitated a transition of the SDS data system from its pre-launch assessment mode to one of full data processing and production. To do this, the PEATES, which served as NASA's data product testing environment during the prelaunch and early on-orbit periods, were transitioned to Science Investigator-led Processing Systems (SIPS). The distributed data architecture was maintained in this new system by locating the SIPS at the same institutions at which the CARS and PEATES were located. The SIPS acquire raw SNPP instrument Level 0 (i.e. RDR) data over the full SNPP mission from the NOAA ADS and IDPS through the NASA SDS Data Distribution and Depository Element (SD3E). The SIPS process those data into NASA Level 1, Level 2, and global, gridded Level 3 standard products using peer-reviewed algorithms provided by members of the NASA Science Team. The SIPS work with the NASA SNPP Science Team in obtaining enhanced, refined, or alternate real-time algorithms to support the capabilities of the Direct Readout Laboratory (DRL). All data products, algorithm source codes, coefficients, and auxiliary data used in product generation are archived in an assigned NASA Distributed Active Archive Center (DAAC).

remote sensing↗

Collecting and Processing Earth Science Data Metrics at NASA ESDIS

Since the launch of Terra satellite in 1999, the number of Earth Science remote sensing data products created and distributed by NASA's Earth Observing System (EOS) Data and Information System (EOSDIS) has increased from a few hundred to nearly ten thousand. NASA's Earth Science Data and Information System (ESDIS) Metrics System (EMS) collects metrics on data ingest, archive, and distribution by its Distributed Active Archive Centers (DAACs) and the Science Investigator-led Systems (SIPS), known as Data Providers. These metrics are critical in helping NASA management as well as data producers in resource planning and gaining a wide range of knowledge of data users and data usage.EMS receives flat files, or log files of data archive, ingest, and distribution either in their raw format, such as Apache web logs, or text files of log records formatted by the Data Providers. Tens of millions of records are processed each day to extract metrics on data products, user information, distribution protocols and services, and so on. The metrics are then made available to designated parties.This presentation provides an overview of the EMS processing workflow and improvement efforts made in recent years to handle ever-increasing number of data records and new metrics requirements, discusses several key steps including mapping log records to data products and identifying user communities along with geo-distribution, and demonstrates typical metrics capabilities produced by the EMS system. Challenges and potential approaches to improve the system are also discussed.

Pan, Jianfu↗

An Innovative Approach to Modeling VIPER Rover Software Life Cycle Cost

NASA’s “Volatiles Investigating Polar Exploration Rover” (VIPER) will be the first robotic mission to prospect for water ice near the south pole of the Moon in late 2023 on a 100-Earth-day mission. The information that the VIPER rover provides will help improve understanding of the composition, distribution, and accessibility of Lunar polar volatiles and will help determine how the Moon’s resources can support future human space exploration. VIPER, however, represents a radical departure from the way that NASA has traditionally developed planetary robotic missions. A key consequence of these differences is that estimating the cost of VIPER’s rover software is challenging and complex.For example, VIPER is being developed using management procedures typically applied to NASA research and technology projects, rather than space flight programs. In addition, key portions of the rover’s software are being designed as ground software to run on mission control computers (rather than on-board the rover as flight software as with prior planetary missions) taking advantage of continuous, interactive data communications between the Moon and Earth and higher performance computing available on the ground. Moreover, the rover’s software is being engineered using Agile software development practices and incorporates a significant amount of open-source, rather than following traditional (spiral, waterfall, etc.) development methods and in-house code. In this paper, we present an innovative process to estimate the life cycle cost of VIPER’s rover software. We first describe how we modeled the architecture and code counts for three software elements: Rover Flight Software (RFSW), Rover Ground Software (RGSW), and Rover Simulation Software (RSIM). We then discuss key challenges and unique aspects of our approach, such as the lack of Lunar rover analogies, the need to integrate and test large open source software, and the strategies developed to account for use of non-space flight management practices and the impact of the COVID-19 pandemic. We conclude with a summary of our results, including cumulative distribution, nearest neighbors and cluster analysis, as well as heuristics used to confirm the reasonableness of the cost estimate.

Utz, Hans↗

Localization of Ad-Hoc Lunar Constellations in Communication Failure Modes for Distributed Spacecraft Autonomy

As Lunar missions increase in complexity, inspired by NASA’s Artemis Program, they will require reliable and sufficient Position, Navigation, and Timing (PNT) capability to support the upcoming Lunar users. The navigation service should also be compatible with the smaller platforms, like CubeSats, being sent by the public and private sectors. A non-dedicated, ad-hoc Lunar navigation constellation can provide PNT services on-demand using the non-dedicated swarm assets. Swarm members cooperatively and autonomously localize themselves with minimal interaction from Earth, freeing up valuable bandwidth and ground segment resources. The autonomous localization of Lunar constellations utilizes neighbor two-way intersatellite link (ISL) measurements in a distributed extended Kalman filter (DEKF) system to minimize operating costs. Because the decentralized Lunar PNT system relies on relay communication amongst the agents, network failures or loss of assets among ad-hoc Lunar constellations may impact localization performance. This study presents an evaluation of localization performance under increasing levels of network degradation. A simulation of an ad-hoc Lunar PNT swarm is augmented to include system faults and the impacts of intermittent and permanent failures on localization performance are evaluated. We investigate three potential causes of network degradation: single spacecraft loss, multiple spacecraft loss, and antenna failure. The numerical assessments from the simulation show that the LPNT system under study, based on an autonomous decentralized concept of operation, is highly robust and resilient to communication failures. Minor faults, such as single spacecraft loss, solar interference, technical malfunctions, message delays, and antenna outages, have minimal impact on state estimation, with only a 4.47% and 3.75% degradation in median position error for assets and a representative ground user, respectively, compared to an ideal communication scenario. However, major faults, such as hardware failures or meteor strikes leading to the loss of multiple spacecrafts, are more concerning. The permanent loss of three spacecraft results in a more severe performance degradation, with median position error increasing by 23.3% for assets and 11.7% for a representative ground user, despite the Lunar PNT system remaining functional.

Yeji Kim↗

A global distributed storage architecture

NSA architects and planners have come to realize that to gain the maximum benefit from, and keep pace with, emerging technologies, we must move to a radically different computing architecture. The compute complex of the future will be a distributed heterogeneous environment, where, to a much greater extent than today, network-based services are invoked to obtain resources. Among the rewards of implementing the services-based view are that it insulates the user from much of the complexity of our multi-platform, networked, computer and storage environment and hides its diverse underlying implementation details. In this paper, we will describe one of the fundamental services being built in our envisioned infrastructure; a global, distributed archive with near-real-time access characteristics. Our approach for adapting mass storage services to this infrastructure will become clear as the service is discussed.

Lionikis, Nemo M.↗

Job Management Requirements for NAS Parallel Systems and Clusters

A job management system is a critical component of a production supercomputing environment, permitting oversubscribed resources to be shared fairly and efficiently. Job management systems that were originally designed for traditional vector supercomputers are not appropriate for the distributed-memory parallel supercomputers that are becoming increasingly important in the high performance computing industry. Newer job management systems offer new functionality but do not solve fundamental problems. We address some of the main issues in resource allocation and job scheduling we have encountered on two parallel computers - a 160-node IBM SP2 and a cluster of 20 high performance workstations located at the Numerical Aerodynamic Simulation facility. We describe the requirements for resource allocation and job management that are necessary to provide a production supercomputing environment on these machines, prioritizing according to difficulty and importance, and advocating a return to fundamental issues.

Saphir, William↗

Estimating Water Ice Abundance from Short-Wave Infrared Spectra of Drill Cuttings at Cryogenic Temperatures

NASA's Resource Prospector (RP) mission intends to visit a lunar polar region to characterize the volatile distribution. Part of the RP payload, the Near-infrared Volatile Spectrometer System (NIRVSS) is a spectrometer operating from 1600-3400 nm that provides sensitivity to water ice, and other volatiles. For multiple years, the NIRVSS system has been incorporated into on-going RP payload testing in a cryogenic vacuum facility at Glenn Research Center. Soil tubes of lunar simulants, prepared with known amounts of water, are placed in the vacuum chamber and cooled to cryogenic temperatures (soil temperatures of 110-170 K) and placed under low vacuum (a few x 10(exp -6) Torr). During these tests NIRVSS continuously measures spectra of soil cuttings emplaced onto the surface by a drill. Real time processing of NIRVSS spectra produces two spectral parameters associated with water ice absorption features near 2000 and 3000 nm that can be used to inform decision making activities such as delivery of the soil to a sealable container. Post-test collection and analyses of the soils permit characterization the water content as a function of depth. These water content profiles exhibit the characteristics of a vacuum desiccation zone to depths of about 40 cm. Subsequent to completion of the tests, NIRVSS spectra are processed to produce two spectral parameters associated with water ice absorption features near 2000 and 3000 nm. These features can be evaluated as a function of time, and correlated with drill depth, and other measurements, throughout the drilling activities. Until now no effort was attempted to quantitatively relate these parameters to water abundance. This is the focus of our efforts to be presented.

NASA's Resource Prospector (RP)↗

A distributed microprocessor system for spacecraft control and data handling

The specific requirements for spacecraft computing systems are considered. These requirements are partly related to the constraints of limited resources of power, weight, and volume. Another important factor is the requirement of extremely high reliability. These reliability requirements have led to introduction of automated redundancy techniques on board the spacecraft. The various redundant computers check each other and provide recovery procedures when a computer is found to have failed. Past and future capabilities are considered along with distributed processing requirements. System considerations are discussed, taking into account suboptimum computer throughput, sensitivity to software modifications, hierarchic timing, I/O granularity, restricted communications, synchronous functions, hierarchic control, and concurrent error detection. A description is presented of the Unified Data System (UDS), which consists of a set of standard microcomputers connected by several buses. Attention is also given to synchronization and timing, the executive control structure, the programming language, and the executive program.

Rennels, D. A.↗

Health-Enabled Smart Sensor Fusion Technology

A process was designed to fuse data from multiple sensors in order to make a more accurate estimation of the environment and overall health in an intelligent rocket test facility (IRTF), to provide reliable, high-confidence measurements for a variety of propulsion test articles. The object of the technology is to provide sensor fusion based on a distributed architecture. Specifically, the fusion technology is intended to succeed in providing health condition monitoring capability at the intelligent transceiver, such as RF signal strength, battery reading, computing resource monitoring, and sensor data reading. The technology also provides analytic and diagnostic intelligence at the intelligent transceiver, enhancing the IEEE 1451.x-based standard for sensor data management and distributions, as well as providing appropriate communications protocols to enable complex interactions to support timely and high-quality flow of information among the system elements.

Wang, Ray↗

A domain segmentation approach to modeling distributed parameter systems

Existing modeling methods in distributed parameter systems are directed to field problems for which a single equation gives an adequate representation. As a result, the techniques are severely taxed when coefficients of the governing partial differential equation (PDE) have relatively complex functional forms. The field is postulated to consist of contiguous regions that are easily modeled. During the modeling process itself, the regional boundaries are identified using a method based on pattern recognition (PR) techniques. The method was tested on computer simulations of a water quality resource system. Quantitative measures are developed and used to demonstrate the feasibility of applying the methodology to realistic distributed parameter systems (DPS's).

Apenyo, K.↗

SCDM in a Distributed Environment

The Software Configuration Management (SCM) of the Space Launch Initiative (SLI) Advanced Engineering Environment (AEE) products is performed in a distributed environment-meaning the activities performed during the project lifecycle are across numerous NASA Centers, facilities, organizations, colleges and industry. SCM is the glue that holds the project and products together-especially in a distributed environment. It identifies, controls, accounts, and verified the details of the products; the schedule of activities; the assigned responsibilities; and the required resources, including staff, tools, and computer facilities. Data/document management (DM) captures and conveys the SCM and project efforts. SCM and DM are integrally linked; hence, Software Configuration and Data Management (SCDM). This paper discusses one team's challenges in implementing SCDM in a distributed environment. The distributed nature of the project introduces new opportunities for moving SCDM to the next level of usefulness in today's high-tech development arena. The lessons learned from the implementation of distributed SCDM in support of the SLI AEE Project provide valuable information for future implementations of SCM and DM.

Crowley, Sandra L.↗

Detailed requirements document for the Interactive Financial Management System (IFMS), volume 1

The detailed requirements for phase 1 (online fund control, subauthorization accounting, and accounts receivable functional capabilities) of the Interactive Financial Management System (IFMS) are described. This includes information on the following: systems requirements, performance requirements, test requirements, and production implementation. Most of the work is centered on systems requirements, and includes discussions on the following processes: resources authority, allotment, primary work authorization, reimbursable order acceptance, purchase request, obligation, cost accrual, cost distribution, disbursement, subauthorization performance, travel, accounts receivable, payroll, property, edit table maintenance, end-of-year, backup input. Other subjects covered include: external systems interfaces, general inquiries, general report requirements, communication requirements, and miscellaneous. Subjects covered under performance requirements include: response time, processing volumes, system reliability, and accuracy. Under test requirements come test data sources, general test approach, and acceptance criteria. Under production implementation come data base establishment, operational stages, and operational requirements.

Dodson, D. B.↗

Real-time contingency handling in MAESTRO

A scheduling and resource management system named MAESTRO was interfaced with a Space Station Module Power Management and Distribution (SSM/PMAD) breadboard at MSFC. The combined system serves to illustrate the integration of planning, scheduling, and control in a realistic, complex domain. This paper briefly describes the functional elements of the combined system, including normal and contingency operational scenarios, then focusses on the method used by the scheduler to handle real-time contingencies.

Britt, Daniel L.↗

The Global File System

The global file system (GFS) is a prototype design for a distributed file system in which cluster nodes physically share storage devices connected via a network-like fiber channel. Networks and network-attached storage devices have advanced to a level of performance and extensibility so that the previous disadvantages of shared disk architectures are no longer valid. This shared storage architecture attempts to exploit the sophistication of storage device technologies whereas a server architecture diminishes a device's role to that of a simple component. GFS distributes the file system responsibilities across processing nodes, storage across the devices, and file system resources across the entire storage pool. GFS caches data on the storage devices instead of the main memories of the machines. Consistency is established by using a locking mechanism maintained by the storage devices to facilitate atomic read-modify-write operations. The locking mechanism is being prototyped in the Silicon Graphics IRIX operating system and is accessed using standard Unix commands and modules.

Soltis, Steven R.↗

Trans-Global Mission Architectures

Mission operations include the utilization of both space and ground resources to achieve mission objectives. Future architectures will make the spacecraft a node on a distributed system, thus expanding the scope of missions beyond the global scale. The history and evolution of planetary mission operations are outlined, together with the current global involvement in planetary missions. The modular nature and reuse of the supporting ground data systems, and the inclusion of automation and dedicated software in space missions, are discussed. A trans-global mission architecture is presented, and consists of an extension of a layered reusable mission operations architecture to create an open ground/space operations system. Concurrent mission engineering with such trans-global structures is discussed.

Anderson, Barbara V.↗