Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Data Sources”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

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

At least 145 records · Page 8

Energetic Phenomena on the Sun: The Solar Maximum Mission Flare Workshop. Proceedings

The general objectives of the conference were as follows: (1) Synthesize flare studies after three years of Solar Maximum Mission (SSM) data analysis. Encourage a broader participation in the SMM data analysis and combine this more fully with theory and other data sources-data obtained with other spacecraft such as the HINOTORI, p78-1, and ISEE-3 spacecrafts, and with the Very Large Array (VLA) and many other ground-based instruments. Many coordinated data sets, unprecedented in their breadth of coverage and multiplicity of sources, had been obtained within the structure of the Solar Maximum Year (SMY). (2) Stimulate joint studies, and publication in the general scientific literature. The intended primary benefit was for informal collaborations to be started or broadened at the Workshops with subsequent publications. (3) Provide a special publication resulting from the Workshop.

Kundu, Mukul↗

Long-term cycles in cosmic X-ray sources

Data on long-term cycles in galactic X-ray sources are reviewed, and classes of variations are identified including precessional activity, recurrent outbursts in Population II sources, and Be/neutron star flare cycles. Cycles of 30-300 days have been found in LMC X-4, Her X-1, SS433, and Cyg X-1 which represent cyclic variations in both the inner and outer parts of the accretion disk. Quasi-periodic cycles with periods ranging from 1/2 to 2 years have been noted in several low-mass X-ray binaries. It is suggested that periodic outbursts in the Be/neutron star systems may result from variable mass transfer in a wide eccentric orbit.

Priedhorsky, W. C.↗

Are System Baselines within OT Environments Feasible?

Critical infrastructure stakeholders need to baseline their systems to understand expected protocol communications.Baseline behaviors may vary based on operational context.Expected operations during a maintenance window, for example, may be different from normal operations.Furthermore, constructing system baselines for Industrial Control Systems (ICS) is difficult and time-consuming.ICS processes generate artifacts expressed across heterogeneous data sources such as network and device logs. There needs to be a corpus of data in order to develop and compare methods that evaluate the feasibility, performance, and generality of approaches to construct baselines for ICS events. Standalone repositories of network packet captures are insufficient to develop methods to classify or recognize operational events expressed across multiple data sources. Moreover, static data corpora do not enable researchers to compare the impact of changing the underlying system for which a baseline is being constructed and this limits the ability to evaluate the performance of system baselines given system changes (e.g. patches, configuration, maintenance events). In order to address these limitations within the community, this talk intends to promote discussion about the state of the practice of constructing baselines. In this manner, we can continue to understand requirements within industry that are not being met by current approaches to baseline construction. This talk builds on two previous talks on the topic of system baselines for OT environments. First, Weaver co-presented at the RSA Conference ICS Sandbox with Dan Gunter. The talk confirmed the need within industry to construct baselines across multiple types of data sources relative to the semantics of specific business processes. Second, Weaver presented at IEEE Security and Privacy Workshop on Language-Theoretic Security.

02 PETROLEUM↗

Overview of the NASA Terrestrial Environments Support Role: Data and Applications

This presentation focuses on the terrestrial environment component of the Natural Environments Branch’s (NEB’s) support role and highlights the instrumentation and data sources used, how the data are quality controlled and archived, and the analyses and use-cases of these datasets. A detailed overview is provided about some individual data sources that are used by the branch, which includes a network of instruments (e.g., wind towers, balloons, and profilers) and models, such as the Earth Global Reference Atmospheric Model (Earth-GRAM). Additionally, the data archival and quality control processes that maintain the high-quality climatological datasets from these sources are discussed, as are the implemented and pending updates to this process. Examples of the different applications for these datasets are presented to showcase the analytical and operational capabilities of the NEB and demonstrate the culmination of the entire process. This includes the Range Reference Atmospheres created and maintained by the NEB, sea-state analyses for crewed return, certification of observation systems for space flight, and the day-of-launch support process. The NEB at NASA Marshall Space Flight Center (MSFC) supports the NASA Engineering Directorate (ED) and Exploration Systems Development Mission Directorate (ESDMD) by providing the necessary environmental constraints to facilitate the safe design and operation of assets required for space travel. This includes, but is not limited to, the environmental considerations for assets residing at the launch sites, temporarily stationed at a launch site, traversing the [extra-]terrestrial atmosphere and open space, and arriving at their destination. As such, the Terrestrial and Planetary Environments Team within the NEB is but a part of the whole, delegated to quantify the environment that assets may encounter whilst on Earth and within its atmosphere. However, nearly all ESDMD assets are subjected to terrestrial conditions, which cover a diverse range of meteorological regimes and extremes. The team also supports day-of-launch operations for the Space Launch System (SLS), providing real-time monitoring of the winds and thermodynamics along the launch path using an amalgamation of observed, remotely sensed, and modeled output.

Systems Engineering↗

Medical Data Architecture (MDA) Project Status

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically-relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm. The medical system requirements are being developed in parallel with the exploration mission architecture and vehicle design. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products supported by current prototype development will directly inform exploration medical system requirements.In fiscal year 2018, the MDA project developed Test Bed 2, the second iteration in a series of prototypes with functionality focused on data security through role-based access control and encryption, integration with One Portal exercise software and ingestion of an ultrasound Digital Imaging and Communications in Medicine (DICOM) file and image display. Test Bed 2 advances the medical data system architecture framework by providing these functionalities in a scalable system that maintained a layered, modular design. The architecture framework uses a data services approach with role-based access to data in a customized medical record system suitable for space exploration. These functionalities were demonstrated as part of the Next Space Technologies for Exploration Partnerships (NextSTEP) ground test demonstrated at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Interfacing to a Core Flight Software (CFS) system, the MDA system, using Consultative Committee for Space Data Systems (CCSDS) protocol, transferred an exercise file from the simulated flight MDA system to a mirrored MDA system on the ground through the CFS system. The selection of data sources and demonstrations enabled the team to address stakeholder concerns throughout the development process. In the next iteration, the MDA team will work with stakeholders to identify additional relevant functionalities to further advance system data models, standards and principles that will inform the medical system requirements development.

medical data architecture↗

Medical Data Architecture Platform and Recommended Requirements for a Medical Data System for Exploration Missions

The Medical Data Architecture (MDA) project supports the Exploration Medical Capability (ExMC) risk to minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically- relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions. In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗

Medical Data Architecture Platform and Recommended Requirements for A Medical Data System for Exploration Missions

Minimize or reduce the risk of adverse health outcomes and decrements in performance due to in-flight medical capabilities on human exploration missions. To mitigate this risk, the ExMC MDA project addresses the technical limitations identified in ExMC Gap Med 07: We do not have the capability to comprehensively process medically relevant information to support medical operations during exploration missions. This gap identifies that the current in-flight medical data management includes a combination of data collection and distribution methods that are minimally integrated with on-board medical devices and systems. Furthermore, there are a variety of data sources and methods of data collection. For an exploration mission, the seamless management of such data will enable a more medically autonomous crew than the current paradigm of medical data management on the International Space Station. ExMC has recognized that in order to make informed decisions about a medical data architecture framework, current methods for medical data management must not only be understood, but an architecture must also be identified that provides the crew with actionable insight to medical conditions. This medical data architecture will provide the necessary functionality to address the challenges of executing a self-contained medical system that approaches crew health care delivery without assistance from ground support. Hence, the products derived from the third MDA prototype development will directly inform exploration medical system requirements for Level of Care IV in Gateway missions.In fiscal year 2019, the MDA project developed Test Bed 3, the third iteration in a series of prototypes, that featured integrations with cognition tool data, ultrasound image analytics and core Flight Software (cFS). Maintaining a layered architecture design, the framework implemented a plug-in, modular approach in the integration of these external data sources. An early version of MDA Test Bed 3 software was deployed and operated in a simulated analog environment that was part of the Next Space Technologies for Exploration Partnerships (NextSTEP) Gateway tests of multiple habitat prototypes. In addition, the MDA team participated in the Gateway Test and Verification Demonstration, where the MDA cFS applications was integrated with Gateway-in-a-Box software to send and receive medically relevant data over a simulated vehicle network. This software demonstration was given to ExMC and Gateway Program stakeholders at the NASA Johnson Space Center Integrated Power, Avionics and Software (iPAS) facility. Also, the integrated prototypes served as a vehicle to provide Level 5 requirements for the Crew Health and Performance Habitat Data System for Gateway Missions (Medical Level of Care IV). In the upcoming fiscal year, the MDA project will continue to provide systems engineering and vertical prototypes to refine requirements for medical Level of Care IV and inform requirements for Level of Care V.

Krihak, M.↗

Investigation of Timing Properties for an Event Driven with Access and Reset Decoder Readout Architecture for a Pixel Array

The large number of data generating sources (data channels) on a single chip requires appropriate techniques to manage a readout from these channels. One of the main methods is sharing a medium of transmission, which requires arbitration to avoid collisions or deadlocks. Existing solutions face several problems such as a dead time, unintended prioritization or metastability. That is why we decided to create a new readout architecture named EDWARD i.e., Event Driven with Access and Reset Decoder. The EDWARD architecture gets rid of the earlier mentioned problems and mitigates the other ones. However, due to the use of logic circuits outside a standard cell library, which are hard to characterize, we were challenged to perform an additional transient analysis to validate the architecture. Here we show a methodology and the results of the simulations. Based on the results obtained we can confirm the functional correctness of the system and plan the optimization of operating conditions in order to achieve better performance. Our goal is to use the EDWARD architecture in the future radiation detectors to be built at Brookhaven National Laboratory.

47 OTHER INSTRUMENTATION↗

Artificial Intelligence for Smart Transportation

There are more than 7,000 public transit agencies in the U.S. (and many more private agencies), and together, they are responsible for serving 60 billion passenger miles each year. A well-functioning transit system fosters the growth and expansion of businesses, distributes social and economic benefits, and links the capabilities of community members, thereby enhancing what they can accomplish as a society. Since affordable public transit services are the backbones of many communities, this work investigates ways in which Artificial Intelligence (AI) can improve efficiency and increase utilization from the perspective of transit agencies. This book chapter discusses the primary requirements, objectives, and challenges related to the design of AI-driven smart transportation systems. We focus on three major topics. First, we discuss data sources and data. Second, we provide an overview of how AI can aid decision-making with a focus on transportation. Lastly, we discuss computational problems in the transportation domain and AI approaches to these problems.

Wilbur, Michael↗

Solar heating and cooling: Technical data and systems analysis

The solar energy research is reported including climatic data, architectural data, heating and cooling equipment, thermal loads, and economic data. Lists of data sources presented include: selected data sources for solar energy heating and cooling; bibliography of solar energy, and other energy sources; sources for manufacturing and sales, solar energy collectors; and solar energy heating and cooling projects.

Christensen, D. L.↗

Laboratory

Definition of laboratory data; sources of data and data volume, required support documentation for lab data; urgency of building a computerized archieve; software needed for management of lab data; analysis of data; and location and access to the data archive are discussed.

Source record↗

A multiprocessor airborne lidar data system

A new multiprocessor data acquisition system was developed for the existing Airborne Oceanographic Lidar (AOL). This implementation simultaneously utilizes five single board 68010 microcomputers, the UNIX system V operating system, and the real time executive VRTX. The original data acquisition system was implemented on a Hewlett Packard HP 21-MX 16 bit minicomputer using a multi-tasking real time operating system and a mixture of assembly and FORTRAN languages. The present collection of data sources produce data at widely varied rates and require varied amounts of burdensome real time processing and formatting. It was decided to replace the aging HP 21-MX minicomputer with a multiprocessor system. A new and flexible recording format was devised and implemented to accommodate the constantly changing sensor configuration. A central feature of this data system is the minimization of non-remote sensing bus traffic. Therefore, it is highly desirable that each micro be capable of functioning as much as possible on-card or via private peripherals. The bus is used primarily for the transfer of remote sensing data to or from the buffer queue.

Wright, C. W.↗

MODIS Technical Report Series. Volume 4: MODIS data access user's guide: Scan cube format

The software described in this document provides I/O functions to be used with Moderate Resolution Spectroradiometer (MODIS) level 1 and 2 data, and could be easily extended to other data sources. This data is in a scan cube data format: a 3-dimensional ragged array containing multiple bands which have resolutions ranging from 250 to 1000 meters. The complexity of the data structure is handled internally by the library. The I/O calls allow the user to access any pixel in any band through 'C' structure syntax. The high MODIS data volume (approaching half a terabyte per day) has been a driving factor in the library design. To avoid recopying data for user access, all I/O is performed through dynamic 'C' pointer manipulation. This manual contains background material on MODIS, several coding examples of library usage, in-depth discussions of each function, reference 'man' type pages, and several appendices with details of the included files used to customize a user's data product for use with the library.

Kalb, Virginia L.↗

Implementation of a state of the art automated system for the production of cloud/water vapor motion winds from geostationary satellites

The research objectives in this proposal were part of a continuing program at UW-CIMSS to develop and refine an automated geostationary satellite winds processing system which can be utilized in both research and operational environments. The majority of the originally proposed tasks were successfully accomplished, and in some cases the progress exceeded the original goals. Much of the research and development supported by this grant resulted in upgrades and modifications to the existing automated satellite winds tracking algorithm. These modifications were put to the test through case study demonstrations and numerical model impact studies. After being successfully demonstrated, the modifications and upgrades were implemented into the NESDIS algorithms in Washington DC, and have become part of the operational support. A major focus of the research supported under this grant attended to the continued development of water vapor tracked winds from geostationary observations. The fully automated UW-CIMSS tracking algorithm has been tuned to provide complete upper-tropospheric coverage from this data source, with data set quality close to that of operational cloud motion winds. Multispectral water vapor observations were collected and processed from several different geostationary satellites. The tracking and quality control algorithms were tuned and refined based on ground-truth comparisons and case studies involving impact on numerical model analyses and forecasts. The results have shown the water vapor motion winds are of good quality, complement the cloud motion wind data, and can have a positive impact in NWP on many meteorological scales.

Velden, Christopher↗

Exploration Medical System Demonstration Project

A near-Earth Asteroid (NEA) mission will present significant new challenges including hazards to crew health created by exploring a beyond low earth orbit destination, traversing the terrain of asteroid surfaces, and the effects of variable gravity environments. Limited communications with ground-based personnel for diagnosis and consultation of medical events require increased crew autonomy when diagnosing conditions, creating treatment plans, and executing procedures. Scope: The Exploration Medical System Demonstration (EMSD) project will be a test bed on the International Space Station (ISS) to show an end-to-end medical system assisting the Crew Medical Officers (CMO) in optimizing medical care delivery and medical data management during a mission. NEA medical care challenges include resource and resupply constraints limiting the extent to which medical conditions can be treated, inability to evacuate to Earth during many mission phases, and rendering of medical care by a non-clinician. The system demonstrates the integration of medical technologies and medical informatics tools for managing evidence and decision making. Project Objectives: The objectives of the EMSD project are to: a) Reduce and possibly eliminate the time required for a crewmember and ground personnel to manage medical data from one application to another. b) Demonstrate crewmember's ability to access medical data/information via a software solution to assist/aid in the treatment of a medical condition. c) Develop a common data management architecture that can be ubiquitously used to automate repetitive data collection, management, and communications tasks for all crew health and life sciences activities. d) Develop a common data management architecture that allows for scalability, extensibility, and interoperability of data sources and data users. e) Lower total cost of ownership for development and sustainment of peripheral hardware and software that use EMSD for data management f) Provide better crew health via the reduction in crew errors, crew time, and ground time.

Chin, D. A.↗

Exploration Medical System Demonstration

BACKGROUND: Exploration class missions will present significant new challenges and hazards to the health of the astronauts. Regardless of the intended destination, beyond low Earth orbit a greater degree of crew autonomy will be required to diagnose medical conditions, develop treatment plans, and implement procedures due to limited communications with ground-based personnel. SCOPE: The Exploration Medical System Demonstration (EMSD) project will act as a test bed on the International Space Station (ISS) to demonstrate to crew and ground personnel that an end-to-end medical system can assist clinician and non-clinician crew members in optimizing medical care delivery and data management during an exploration mission. Challenges facing exploration mission medical care include limited resources, inability to evacuate to Earth during many mission phases, and potential rendering of medical care by non-clinicians. This system demonstrates the integration of medical devices and informatics tools for managing evidence and decision making and can be designed to assist crewmembers in nominal, non-emergent situations and in emergent situations when they may be suffering from performance decrements due to environmental, physiological or other factors. PROJECT OBJECTIVES: The objectives of the EMSD project are to: a. Reduce or eliminate the time required of an on-orbit crew and ground personnel to access, transfer, and manipulate medical data. b. Demonstrate that the on-orbit crew has the ability to access medical data/information via an intuitive and crew-friendly solution to aid in the treatment of a medical condition. c. Develop a common data management framework that can be ubiquitously used to automate repetitive data collection, management, and communications tasks for all activities pertaining to crew health and life sciences. d. Ensure crew access to medical data during periods of restricted ground communication. e. Develop a common data management framework that allows for scalability, extensibility, and interoperability of data sources and data users. f. Lower total cost of ownership for development and sustainment of peripheral hardware and software that use EMSD for data management. g. Provide a better standard of healthcare for crew members through reductions in the time required by crew and ground personnel to provide medical treatment and the number of crew errors experienced during treatment.

Rubin, D. A.↗

Initial Demonstration of the Real-Time Safety Monitoring Framework for the National Airspace System Using Flight Data

As new operational paradigms and additional aircraft are being introduced into the National Airspace System (NAS), maintaining safety in such a rapidly growing environment becomes more challenging. It is therefore desirable to have an automated framework to provide an overview of the current safety of the airspace at different levels of granularity, as well an understanding of how the state of the safety will evolve into the future given the anticipated flight plans, weather forecast, predicted health of assets in the airspace, and so on. Towards this end, as part of our earlier work, we formulated the Real-Time Safety Monitoring (RTSM) framework for monitoring and predicting the state of safety and to predict unsafe events. In our previous work, the RTSM framework was demonstrated in simulation on three different constructed scenarios. In this paper, we further develop the framework and demonstrate it on real flight data from multiple data sources. Specifically, the flight data is obtained through the Shadow Mode Assessment using Realistic Technologies for the National Airspace System (SMART-NAS) Testbed that serves as a central point of collection, integration, and access of information from these different data sources. By testing and evaluating using real-world scenarios, we may accelerate the acceptance of the RTSM framework towards deployment. In this paper we demonstrate the framework's capability to not only estimate the state of safety in the NAS, but predict the time and location of unsafe events such as a loss of separation between two aircraft, or an aircraft encountering convective weather. The experimental results highlight the capability of the approach, and the kind of information that can be provided to operators to improve their situational awareness in the context of safety.

Real-time Safety Monitoring↗

Sherlock Data Warehouse

This slide deck provides an overview of the data and resources available in the Sherlock Data Warehouse. Sherlock was developed and is currently maintained by the Aviation Systems Division at NASA Ames Research Center. Sherlock contains a valuable collection of flight, air traffic management, and weather data. But Sherlock is not just a data archive. Sherlock also includes tools and resources to access, download, and visualize data, as well as resources to process the data. This overview summarizes Sherlock data sources, demonstrates data analytics and visualization with MicroStrategy, illustrates disparate data integration using the ATM Knowledge graph, and presents a machine learning use case using the Big Data system.

data warehouse↗