Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “data logging”

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

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

At least 37 records · Page 2

Vortex boundary-layer interactions

Parametric studies to identify a vortex generator were completed. Data acquisition in the first chosen configuration, in which a longitudinal vortex pair generated by an isolated delta wing starts to merge with a turbulent boundary layer on a flat plate fairly close to the leading edge is nearly completed. Work on a delta-wing/flat-plate combination, consisting of a flow visualization and hot wire measurements taken with a computer controlled traverse gear and data logging system were completed. Data taking and analysis have continued, and sample results for another cross stream plane are presented. Available data include all mean velocity components, second order mean products of turbulent fluctuations, and third order mean products. Implementation of a faster data logging system was accomplished.

Bradshaw, P.↗

Monitoring Airspace Complexity and Determining Contributing Factors

The national airspace has evolved over many years to accommodate increased traffic demand [1] while simultaneously maintaining one of the safest forms of transportation [2], [3]. One of the reasons for this success is the ability of the system and the operators to adapt and accommodate to situations that routinely disrupt optimal operations. These situations may include: adverse weather, delays, early arrivals, equipment outages, and other factors that are outside the operators ability to control. These factors can lead to states where automation is unable to properly handle these issues and therefore air traffic controllers and pilots have to intervene, ultimately increasing communication between operators resulting in higher workload. As controller workload increases to handle sub-optimal operating conditions this can be viewed as an increase in complexity. The reasoning for this is because humans are now required to make tactical decisions in response to external factors, resulting in a departure from the strategic plan where operations would be more efficiently managed. Human operators control airspace complexity under rigid regulations that are constantly changing. The airspace is divided into sectors and the number of aircraft assigned to each controller is limited for safe handling. There has been past work that devised airspace complexity metrics in commercial aviation and related these metrics to controller workload (e.g., [4],[5]). The upper bounds on the system load are pre-determined. Such bounds on complexity make for a safe system, but the system cannot scale and adapt to autonomous, dense, and heterogeneous traffic, including the many types of Unmanned Aerial Vehicles (UAVs) envisioned to be added to the operations. We hypothesize that, as traffic density and heterogeneity grow, and other key metrics change, there will be phase transitions at which the way traffic should be managed changes significantly [6]. We offer a method for in-time detection of contributing factors that lead to phase transitions, characterized by increased complexity. To the best of our knowledge, there is no tool similar to our proposed effort that identifies such contributing factors or precursor patterns. To define the scope we are proposing to measure complexity from the viewpoint of the Terminal Radar Approach Control Facilities (TRACON) controller’s perspective. In particular we are analyzing arrivals into KSFO. With safety as the top concern for airspace operators, it is important to recognize that as density and heterogeneity grow, the focus of the system will change. Times of the day when the airspace has low density and heterogeneity, the flights will follow more efficient paths where the aircraft move on established routes that are more or less directly to the destination. However, when density and heterogeneity increases, the system will begin changing focus to avoiding conflicts and collisions and route the flights in a more flexible way. Higher flexibility requires more communication and coordination between controllers and pilots which the current automation is unable to handle. This paper proposes a novel approach that monitors airspace complexity at multiple scales, uses a Machine Learning-based tool that predicts when operations will transition to a regime of greater complexity, and identifies actions that can reduce the complexity while still maintaining efficient and safe operations. We demonstrate our proposed approach using data from multiple complementary sources. This includes, but is not limited to: historical aircraft surveillance data from NASA’s Sherlock Data Warehouse [7], METAR weather data, and airport configuration data from Aviation System Performance Metrics (ASPM). The surveillance data flight paths are sampled at a variable sample rate — increasing as the aircraft approaches the airport. This is due to how Sherlock manages flight track stitching between different radar facilities which have different sampling rates. The weather and performance data are logged at defined intervals throughout the day at a courser refresh rate. In addition to the logged data and metrics, we leverage pre-defined Standard Terminal Arrival Routes (STARs) procedures to characterize the path of each flight. Each flight files for one of these routes in the flight plan well before entering the terminal airspace, and approximately follows the route until it leaves the STAR, typically on the final fix of a runway transition. However, most flights do not always fly the full STAR procedure to completion [8], but the majority do adhere to the fixes within the common route of the procedure. Our approach leverages fixes in the common route of each of the STARs to build a reference path to the airport. This allows us to characterize the flight paths in what we are defining as the “maneuvering area” (the airspace between the STAR and before the flight is lined up on the runway’s final approach) to determine how off nominal the flights are to calculate its complexity score. Determining airspace complexity is a concept that does not have a concrete answer. In designing this metric, we consider what increases the workload for the air traffic controllers. Consequently more specialized vectoring maneuvers results in higher workload. Accordingly, we start with a theory: each flight has a direct path it takes from the STAR’s common route to the final approach’s outer marker fix for the flight’s landing runway. It is important to note that the direct path is only used as a reference. If the majority of the flights have a large consistent offset as compared to other routes it does not necessarily mean that those flights have higher complexity. We are merely building a distribution based on this direct path for that particular STAR and runway pair to determine the normal mode of operations for that route. Flights that are in the upper tail of these distributions will result in higher complexity scores and flights that fly in the median will represent the normal mode of operations and therefore will have lower complexity scores. Since flights following each STAR route take different paths to the airport, we have a different distribution for each STAR route and therefore can model these distributions to compute a complexity score from their respective normalized distributions. To evaluate the effectiveness of our proposed airspace complexity metric we will compare against an established approach based on trajectory clustering [9]. This unsupervised learning technique consists of the following steps: (1) identify the general maneuvering areas (waypoints) by performing $\kappa$-means or DBSCAN clustering on locations where aircraft frequently turn based on the surveillance radar track data, (2) map flight trajectories onto sequences of waypoints, and (3) cluster the sequences based on their common subsequences. From a high-level perspective, this baseline model learns nominal operations in the airspace through the sequence of waypoints that are representative of where aircraft change direction and defines deviations from the nominal operations as “complex.” Therefore, more deviations from the nominal operations correspond to higher complexity values. For our validation, we re-implemented this technique and tune model hyper-parameters to correctly detect waypoints for the arrival traffic into the San Francisco bay area. We will compute the complexity measure over a one-year period using our proposed technique as well as the baseline. Our validation will be based on each technique’s ability to detect a set of undesirable outcomes (e.g., go-arounds, holding patterns, average time in the airspace, etc.). Since our current complexity metric is derived from the offset from the direct reference path, it’s important to understand what causes these offsets. In many of the flights with high offset distance, flights performing holding patterns and S turns can be observed. These maneuvering tactics are utilized to add distance between the aircraft and the destination runway to prevent multiple flights from having conflicting arrival times. In order to predict a rise in complexity (or the precursor to complexity), it’s necessary to be able to identify these potential conflicts (which in turn, result in higher offsets). To do this, we define a “representative flight” for each STAR route and runway pair. This flight is approximately the path the flight would take if there was a clear path with no other flights in the airspace — including the time remaining to the airport. We first identify the flights for a given STAR runway pair using the offset to the reference path distributions that fall between the 44-55 percentiles. This yields the flights that conform to the most normal mode of operation. Each of these flights is partitioned based on the percent complete from the entry point into the maneuvering areas from 0\% – 100\% complete. Then for each percent “bin”, we take the median value of the flight’s latitude/longitude coordinates, airspeed, and (non causal) time remaining to the airport to construct a lookup table for each percent complete bin on a given route. As a flight enters the maneuvering area, we can find the estimated arrival time of a flight to the airport by finding the closest point to the representative path’s percent complete bin (relative to the flight’s current position at any snapshot in the airspace) and therefore retrieve the corresponding remaining time left on the “representative path”. We assume that the flight will follow the representative path to completion when deriving these estimates. We can then compare these estimated arrival times against other flights for the same snapshot in time to identify potential conflicts. If more flights are estimated to arrive within a tolerance window than there are runways available, then we have a potential conflict. We can use this derived measure along with other factors expected to add disruption to the operation such as weather and runway configuration changes as an input to machine learning tools to detect precursors that increases in our complexity measure. This novel method will assist in uncovering insights into the contributing factors that lead to increased complexity that may allow for in-time responses to avoid reaching a high complexity state in the airspace.

complexity↗

Site H - Event Log / Derived Data

This dataset contains the event log table that provides 10-minute wind statistics from the scanning lidar at AWAKEN's site H. This is a good dataset to start from for people unfamiliar with the AWAKEN project.

17 WIND ENERGY↗

Site A1 - Event Log / Derived Data

This dataset contains the event log table with 10-minute wind statistics from the scanning lidar at AWAKEN's site A1. This is a good dataset to start from for people unfamiliar with the AWAKEN project.

17 WIND ENERGY↗

Site A2 - Event Log / Derived Data

This dataset contains the event log table with 10-minute wind statistics from the scanning lidar at AWAKEN's site A2. This is a good dataset to start from for people unfamiliar with the AWAKEN project.

17 WIND ENERGY↗

Sites A1, A2, & H - Event Log / Derived Data

This dataset contains the event log table that provides 10-minute wind statistics from the scanning lidars at AWAKEN's sites A1, A2, and H. This is a good dataset to start from for people unfamiliar with the AWAKEN project.

17 WIND ENERGY↗

Malicious Cyber Activity Detection using Zigzag Persistence

In this study we synthesize zigzag persistence from topological data analysis with autoencoder-based approaches to detect malicious cyber activity, and derive analytic insights. Cybersecurity aims to safeguard computers, networks, and servers from various forms of malicious attacks, including network damage, data theft, and activity monitoring. We focus on the cybersecurity domain and investigate the detection of malicious activity using log data. We consider the dynamics of the log data and explore the changing topology of a hypergraph representation of this data to gain insights into the underlying activity. These hypergraphs capture complex interactions between processes, together with their temporal information. To study the changing topology we use zigzag persistence, which captures how topological features persist at multiple dimensions over time. We observe that this detects malicious activity in a cyber data set. To automate this detection we implement an autoencoder trained on a vectorization of the resulting zigzag persistence barcodes. Our experimental results demonstrate the effectiveness of the autoencoder in detecting malicious activity. Overall, this study highlights the potential of zigzag persistence and its combination with temporal hypergraphs for analyzing cybersecurity log data and detecting malicious behavior.

hypergraphs, temporal hypergraph, topological data↗

Using Splunk® Enterprise Search Commands for Advanced Analysis of Ivanti Connect Secure© Logs

Analyzing the logs of even the smallest Information Technology (IT) system can be a challenge considering they can generate millions of lines of log data in a very short time. Splunk® Enterprise is an industry leading tool that allows analysis of log data, which can enhance troubleshooting capabilities, improve system performance, and improve the security posture of an IT system. Ivanti Connect Secure© (ICS) is a market-leading platform powered by the Ivanti Secure Socket Layer Virtual Private Network (SSL VPN) appliance, providing an architecture for secure access to and protection of network resources. This paper describes an approach for using Splunk Enterprise search capabilities to perform advanced data analysis of ICS logs.

97 MATHEMATICS AND COMPUTING↗

The CCD/Transit Instrument (CTI) data-analysis system

The automated software system for archiving, analyzing, and interrogating data from the CCD/Transit Instrument (CTI) is described. The CTI collects up to 450 Mbytes of image-data each clear night in the form of a narrow strip of sky observed in two colors. The large data-volumes and the scientific aims of the project make it imperative that the data are analyzed within the 24-hour period following the observations. To this end a fully automatic and self evaluating software system has been developed. The data are collected from the telescope in real-time and then transported to Tucson for analysis. Verification is performed by visual inspection of random subsets of the data and obvious cosmic rays are detected and removed before permanent archival is made to the optical disc. The analysis phase is performed by a pair of linked algorithms, one operating on the absolute pixel-values and the other on the spatial derivative of the data. In this way both isolated and merged images are reliably detected in a single pass. In order to isolate the latter algorithm from the effects of noise spikes a 3x3 Hanning filter is applied to the raw data before the analysis is run. The algorithms reduce the input pixel-data to a database of measured parameters for each image which has been found. A contrast filter is applied in order to assign a detection-probability to each image and then x-y calibration and intensity calibration are performed using known reference stars in the strip. These are added to as necessary by secondary standards boot-strapped from the CTI data itself. The final stages involve merging the new data into the CTI Master-list and History-list and the automatic comparison of each new detection with a set of pre-defined templates in parameter-space to find interesting objects such as supernovae, quasars and variable stars. Each stage of the processing from verification to interesting image selection is performed under a data-logging system which both controls the pipe-lining of data through the system and records key performance monitor parameters which are built into the software. Furthermore, the data from each stage are stored in databases to facilitate evaluation, and all stages offer the facility to enter keyword-indexed free-format text into the data-logging system. In this way a large measure of certification is built into the system to provide the necessary confidence in the end results.

Cawson, M. G. M.↗

Automated pH Control of Nutrient Solution in a Hydroponic Plant Growth System

Over, the years, NASA has played an important role in providing to and the development of automated nutrient delivery and monitoring, systems for growing crops hydroponically for long term space missions. One example are the systems used in the Biomass Production Chamber (BPC) at Kennedy Space Center (KSC). The current KSC monitoring system is based on an engineering workstation using standard analog/digital input/output hardware and custom written software. The monitoring system uses completely separate sensors to provide a check of control sensor accuracy and has the ability to graphically display and store data form past experiment so that they are available for data analysis [Fortson, 1992]. In many cases, growing systems have not been fitted with the kind of automated control systems as used at KSC. The Center for Food and Environmental Systems for Human Exploration of Space (CFESH) located on the campus of Tuskegee University, has effectively grown sweetpotatoes and peanuts hydroponically for the past five years. However they have adjusted the pH electrical conductivity and volume of the hydroponic nutrient solution only manually at times when the solution was to be replenished or changed out according to its protocol (e.g. one-week, two-week, or two-day cycle). But the pH of the nutrient solution flowing through the channel is neither known nor controlled between the update, change out, or replenishment period. Thus, the pH of the nutrient solution is not held at an optimum level over the span of the plant's growth cycle. To solve this dilemma, an automated system for the control and data logging of pH data relative to sweetpotato production using the nutrient film technique (NFT) has been developed, This paper discusses a microprocessor-based system, which was designed to monitor, control, and record the pH of a nutrient solution used for growing sweetpotatoes using NFT.

Smith, B.↗

Electricity Baseline 2021 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2021 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2021 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2021 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗

Electricity Baseline 2020 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2020 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilizes the appdirs Python dependency (https://pypi.org/project/appdirs/). An overview of the ElectricityLCI data stores may be found on the README (https://github.com/USEPA/ElectricityLCI/blob/v2.0/README.md#data-store). This submission includes the background data used to generate the 2020 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: python -c "import appdirs; print(appdirs.user_data_dir())"). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2020 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; LCI; Life Cycle; data inventory↗

Electricity Baseline 2022 Background Data and Log File

The ElectricityLCI v2 Python package (https://github.com/USEPA/ElectricityLCI/tree/v2.0) was used to generate the 2022 electricity baseline: a regionalized life cycle inventory model of U.S. electricity generation, consumption, and distribution using standardized facility and generation data. ElectricityLCI implements a local data store for downloading and accessing public data on an individual's computer. The data store follows the folder definition provided by USEPA's esupy Python package (https://github.com/USEPA/esupy), which utilized the appdirs Python dependency (https://pypi.org/project/appdirs/). This submission includes the background data used to generate the 2022 electricity baseline inventory. Each zip archive stores the source files as found in their data stores. Sub-folders in each of the data stores are archived separately. For example, stewi.zip contains the JSON files, while stewi.facility.zip is the 'facility' sub-folder of stewi data store that stores the parquet files. To reproduce the data store, extract each zip file and drag-and-drop sub-folders in to their appropriate root folders to recreate the data stores, then copy the root folders to your data store folder (as returned by running the following on the command line: `python -c "import appdirs; print(appdirs.user_data_dir())"`). The main five data stores include: 'electricitylci', 'facilitymatcher', 'fedelemflowlist', 'stewi', and 'stewicombo'. The log file generated by the 2022 model run is also included, which contains the statements at the DEBUG level and above.

Electricity; LCA; data inventory↗

MCPC Friction Stir Welding (FSW) Process Data

Processing parameters and machine log data for the MCPC LDRD Agile investment is collected material samples processed. This dataset captures the selected processing parameters, machine logs captured during material processing, and descriptions of how characterization samples were extracted from processed plates of material. The collect characterization data is captured in other datasets.

316 Stainless Steel↗

Integration of an Autopilot for a Micro Air Vehicle

Two autopilots providing autonomous flight capabilities are presented herein. The first is the Pico-Pilot, demonstrated for the 12-inch size class of micro air vehicles. The second is the MicroPilot MP2028(sup g), where its integration into a 36-inch Zagi airframe (tailless, elevons only configuration) is investigated and is the main focus of the report. Analytical methods, which include the use of the Advanced Aircraft Analysis software from DARCorp, were used to determine the stability and control derivatives, which were then validated through wind tunnel experiments. From the aerodynamic data, the linear, perturbed equations of motion from steady-state flight conditions may be cast in terms of these derivatives. Using these linear equations, transfer functions for the control and navigation systems were developed and feedback control laws based on Proportional, Integral, and Derivative (PID) control design were developed to control the aircraft. The PID gains may then be programmed into the autopilot software and uploaded to the microprocessor of the autopilot. The Pico-Pilot system was flight tested and shown to be successful in navigating a 12-inch MAV through a course defined by a number of waypoints with a high degree of accuracy, and in 20 mph winds. The system, though, showed problems with control authority in the roll and pitch motion of the aircraft: causing oscillations in these directions, but the aircraft maintained its heading while following the prescribed course. Flight tests were performed in remote control mode to evaluate handling, adjust trim, and test data logging for the Zagi with integrated MP2028(sup g). Ground testing was performed to test GPS acquisition, data logging, and control response in autonomous mode. Technical difficulties and integration limitations with the autopilot prevented fully autonomous flight from taking place, but the integration methodologies developed for this autopilot are, in general, applicable for unmanned air vehicles within the 36-inch size class or larger that use a PID control based autopilot.

Platanitis, George↗

Characterization of Most Promising Sequestration Formations in the Rocky Mountain Region

The project Characterization of Most Promising Sequestration Formations in the Rocky Mountain Region is one of 9 site characterization projects that were implemented as part of ARRA (American Recovery and Reinvestment Act). Data from this project was used to improve resolution of data in NATCARB in the area of study. Data related to this study has already been incorporated in NATCARB Atlas. The Rocky Mountain Carbon Capture and Storage (RMCCS) project investigated multiple geologic formations and characterized a local site on the Colorado Plateau for future CCS opportunities. The RMCCS project focused on the Cretaceous Dakota, Jurassic Entrada, and Pennsylvanian Weber Sandstones, the three largest regional formations. All formations in this project are potential CO2 storage resources for future power plants, natural gas processing plants, cement plants, and oil shale development projects. The area adjacent to Craig, Colorado, (Sand Wash Basin) was the area selected for detailed geologic characterization on the RMCCS project. The basin was selected in part because the geology can be extrapolated to other sites on the Colorado Plateau. Field mapping and seismic surveys were conducted to identify and evaluate the basin's structural configuration. A 9,745-foot deep characterization well was drilled to collect 131 feet of core and a suite of geophysical well log data. Petrophysical tests on samples of core were used to calibrate geophysical log data, which can be used to obtain storage resource estimates and evaluate associated uncertainty as well as simulate the hydrologic behavior of injected CO2. A detailed analysis of the primary formations (Dakota, Entrada and Weber sandstones) yielded a more accurate CO2 storage resource assessment for these formations within the Colorado Plateau; RMCCS estimates indicate a total CO2 storage resource of more than 38,000 million metric tons. The characterization of the Sand Wash Basin (2-D seismic surveys, multiple well logs and lithological, petrophysical and geochemical analyses) allowed for a detailed 3-D model to be constructed. The model served as the framework for analyses ranging from CO2 storage resource, injectivity, and subsurface flow to uncertainty estimates to evaluation of risk.

2-D seismic↗

A Model of the Chicxulub Impact Basin Based on Evaluation of Geophysical Data, Well Logs, and Drill Core Samples

Abundant evidence now shows that the buried Chicxulub structure in northern Yucatan, Mexico, is indeed the intensely sought-after source of the ejecta found world-wide at the Cretaceous-Tertiary (K/T) boundary. In addition to large-scale concentric patterns in gravity and magnetic data over the structure, recent analyses of drill-core samples reveal a lithological assemblage similar to that observed at other terrestrial craters. This assemblage comprises suevite breccias, ejecta deposit breccias (Bunte Breccia equivalents), fine-grained impact melt rocks, and melt-matrix breccias. All these impact-produced lithologies contain diagnostic evidence of shock metamorphism, including planar deformation features in quartz, feldspar, and zircons; diaplectic glasses of quartz and feldspar; and fused mineral melts and whole-rock melts. In addition, elevated concentrations of Ir, Re, and Os, in meteoritic relative proportions, have been detected in some melt-rock samples from the center of the structure. Isotopic analyses, magnetization of melt-rock samples, and local stratigraphic constraints identify this crater as the source of K/T boundary deposits.

Sharpton, Virgil L.↗

Residual Dose and Environmental Monitoring for the Fermilab Main Injector Tunnel Using the Data Acquisition Logging Engine (Dale)

The Recycler and the Main Injector are part of the Fermilab Accelerator complex used to deliver proton beam to the different experiments. It is very important to control and minimize losses in both machines during operation, to reduce personnel dose from residual activation and to preserve component lifetime. To minimize losses, we need to identify the loss points and adjust the components accordingly. The Data Acquisition Loss Engine (DALE) platform has been developed within the Main Injector department and upgraded throughout the years. DALE is used to survey the entire enclosure for residual dose rates and environmental readings when unrestricted access to the enclosure is possible. Currently DALE has two radiation meters, which are aligned along each machine, so loss points can be identified for both at the same time. DALE attaches to the enclosure carts and is continuously in motion monitoring dose rates and other environmental readings. In this paper we will describe how DALE is used to provide radiation maps of the residual dose rates in the enclosure. We will also compare the loss points with the Beam Loss monitor data.

43 PARTICLE ACCELERATORS↗