Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “Runtime monitoring”

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 109 records · Page 6
All sourcesNASA NTRSDOE OSTI
DOE OSTI2016

Reducing Waste in Extreme Scale Systems through Introspective Analysis

Resilience is an important challenge for extreme- scale supercomputers. Today, failures in supercomputers are assumed to be uniformly distributed in time. However, recent studies show that failures in high-performance computing systems are partially correlated in time, generating periods of higher failure density. Our study of the failure logs of multiple supercomputers show that periods of higher failure density occur with up to three times more than the average. We design a monitoring system that listens to hardware events and forwards important events to the runtime to detect those regime changes. We implement a runtime capable of receiving notifications and adapt dynamically. In addition, we build an analytical model to predict the gains that such dynamic approach could achieve. We demonstrate that in some systems, our approach can reduce the wasted time by over 30%.

Bautista-Gomez, Leonardo↗
DOE OSTI2013

Coordinated Fault Tolerance for High-Performance Computing

Our work to meet our goal of end-to-end fault tolerance has focused on two areas: (1) improving fault tolerance in various software currently available and widely used throughout the HEC domain and (2) using fault information exchange and coordination to achieve holistic, systemwide fault tolerance and understanding how to design and implement interfaces for integrating fault tolerance features for multiple layers of the software stack—from the application, math libraries, and programming language runtime to other common system software such as jobs schedulers, resource managers, and monitoring tools.

97 MATHEMATICS AND COMPUTING↗
NASA NTRSDate not supplied

Satellite-assisted Evaluation of Irrigation Application Efficiency for Lettuce in the Salinas Valley

The Salinas Valley region of California’s Central Coast is a majorU.S. vegetable producer. Lettuce is a leading commodity, grown on about 100,000 acres with annual value near $1.4B (2022 Monterey County Ag Report). Vegetables crops in the area aretypically well watered and fertilized in pursuit of commercial yield and quality standards. Information on irrigation application efficiency, meanwhile, can enhance waterresource sustainability and mitigate impacts of nitrate infiltrationon groundwater quality. The Crop Consumptive Use Fraction (CCUF), previously recommended by the California Department of Water Resources, is a metric that expresses evapotranspiration (ET) of applied water relative to total applied water. More recently under Assembly Bill 1668 addressing water conservation and drought planning, the metric can be used to help quantify application efficiency to support preparation of agricultural water management plans in the state. This study will report CCUF evaluations from several commercial lettuce plantings in the Salinas Valley during the 2022 dry season (late spring-early fall). The evaluations were derived from satellite-based observations of cropET from the OpenETcloud application, and applied water monitored by in-line flowmetersand supplemented by grower reports of irrigation system runtime. The study will also compare observed (satellite-based) ET with modeled ET from the CropManage irrigationand nutrient management decision-support system operated by Cooperative Extension. Additional study in cool-season vegetables is ongoing in 2023.

Satellite-assisted↗
NASA NTRSDate not supplied

MESA: Scalable Runtime Verification Tool Using Actors

This work presents our runtime verification approach implemented by the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in linear temporal logic and finite state machines.We employ the actor programing model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper also presents a case study where MESA is used to monitor flights in National Airspace System of United States using live air traffic data stream. The case study which motivated this work in the first place shows that our approach is effective.We also perform empirical study by conducting experiments using monitoring systems with different numbers of concurrent monitors and different layers of indexing.This paper describes our experiments, evaluates our results,and discusses challenges faced during the study. The evaluation shows our approach is scalable.

runtime verification, concurrency, actor programin↗
NASA NTRS2022

Chile Disasters: Automating Wildfire Risk and Occurrence Mapping in Google Earth Engine to Improve Wildfire Detection and Response Time Efforts

Wildfires in Chile in the last decade were the worst on record, destroying homes and livelihoods, polluting the air, and displacing whole towns. To predict locations where wildfires were likely to start, the Corporación Nacional Forestal (CONAF) created a wildfire risk model within ArcGIS Pro and Google Earth Engine (GEE) that utilized the NOAA Global Forecast System (GFS) and the NASA Shuttle Radar Topography Mission (STRM) 90-meter datasets. The previous CONAF model was very resource-heavy and time-intensive to run. NASA DEVELOP, in partnership with CONAF, automated the previous model and transferred it fully into GEE where all Earth observation datasets could be used without downloading. The new model substantially reduced the runtime. The final model was used to create a near real-time wildfire monitoring application as well as fire severity maps. The end products will be used by CONAF for wildfire prediction and management to prevent more destruction in the future.

Maria De Los Santos↗
NASA NTRSDate not supplied

Actor-based Runtime Verification with MESA

This work presents a runtime verification approach implemented in the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in data parameterized temporal logic and state machines. The tool is implemented as an internal Scala DSL. We employ the actor programming model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper presents a case study in which MESA is used to effectively monitor a large number of flights from live US airspace data streams. We also perform an empirical study by conducting experiments using monitoring systems with different numbers of concurrent monitors and different layers of indexing on the data contained in events. The paper describes the experiments, evaluates the results, and discusses challenges faced during the study. The evaluation shows the value of combining concurrency with indexing to handle data rich events.

runtime verification↗
NASA NTRS2024

Launch Complex 39B, SWMU 009, 2023 Performance Monitoring and Air Sparge Expansion Construction Completion Report, Kennedy Space Center, Florida

The 2023 Performance Monitoring and Construction Completion Report (PM-CCR) presents the findings, observations, and results for Air Sparging (AS) operations and expansion activities, as well as sitewide groundwater monitoring for Launch Complex 39B (LC39B), Solid Waste Management Unit (SWMU) 009, at Kennedy Space Center (KSC), Florida. The reporting period for activities covered under this PM-CCR is from January 1, 2023, to December 31, 2023. At LC39B, AS operations began in 2017 in the area west of the launch pad, in the liquid oxygen (LOX) tank area located northwest of the launch pad, and in an area outside of the perimeter fence to protect nearby Outstanding Florida Waters (OFW). The LC39B AS system was installed with 279 AS wells to depths ranging from 23 to 60 feet below land surface (bls), including the sump, correlating to top of screen depths ranging from 20 to 57 feet bls. In December 2022, a total of 22 AS wells were abandoned to support launch pad crane operations, and in November 2023, the system was expanded with five additional AS wells installed to 13 or 17 feet bls near the LOX tank. The remedial objective of the LC39B AS Interim Measure (IM) is to actively decrease concentrations of contaminants of concern (COCs) in groundwater, specifically trichloroethene (TCE), cis-1,2-Dichloroethene (cDCE), and vinyl chloride (VC), to less than their respective Natural Attenuation Default Concentrations (NADCs), so LC39B can transition into a Long-Term Monitoring (LTM) program. This PM-CCR presents the following information for LC39B: • AS system operations and maintenance (O&M) (Year 7 of operation) from January 2023 to December 2023, to include AS trailer relocation in March 2023 and subsequent replacement and re-start in June 2023. • Construction completion details for AS system expansion, which included installation of five new AS wells and one new monitoring well in November 2023. As part of expansion activities, soil samples were also collected for petroleum analysis; no exceedances were identified, and no further investigation for petroleum is warranted. • Performance monitoring results for groundwater sampling events conducted in May/June 2023 (30 wells) and November 2023 (31 wells) in the AS IM area and in the Low Concentration Plume (LCP) areas located north and east of the launch pad for volatile organic compound (VOC) analysis. • Sampling results for one monitoring well, LOX-IW0012S, which is sampled for aluminum on an annual basis (May/June 2023). This well was resampled in November 2023 for both total and dissolved aluminum. Due to a communication error with the laboratory, the May/June 2023 sample was analyzed for total aluminum only. • Groundwater sampling results for per- and polyfluoroalkyl substances (PFAS) collected from seven monitoring wells during the May/June 2023 event to further investigate the Former Sewage Treatment Plant #6 and Percolation Pond area, west of the launch pad. O&M and performance monitoring results show that the AS system at LC39B is operating as designed and meeting performance criteria. Overall runtime was 45 percent (%) during the reporting period (January to December), but the operational runtime was 78% during the timeframe when the system could run (June to December). The most significant downtime contributor was post-launch crane operations following the Artemis launch on November 16, 2022, which lasted until June 2023. During that timeframe, the AS trailer at LC39B was relocated to another KSC remediation site (Wilson Corners) and was subsequently replaced with the AS trailer from the Paint & Oil Locker (POL) remediation site at KSC to resume AS system operations. Performance monitoring results in the AS IM and LCP areas continue to show reduction in COC concentrations over time when compared to baseline levels. In 2023, only one monitoring well (MW0048) detected a COC exceeding its NADC (VC at 740 micrograms per liter [µg/L]), which marks the baseline result for this new well installed during system expansion. Across the rest of the site, VC concentrations have declined or remained stable during the 2023 sampling events. Excluding MW0048, the highest VC result in 2023 was during the May/June sampling event with a concentration of 63 µg/L at MW0032, which is located near MW0048 and the AS expansion area by the LOX tank. TCE was detected in select monitoring wells in the IM area in 2023, but only two locations exceeded the State of Florida Groundwater Cleanup Target Level (GCTL): MW0032 (21 µg/L in May/June 2023 and 9.1 µg/L in November 2023) and MW0036 (5.0 µg/L in November 2023). MW0036 is also located near the LOX tank, on the north side, where the AS system is still operational (Zone Z4). cDCE and trans-1,2-dichloroethene concentrations were less than laboratory method detection limits or their respective GCTLs in all wells sampled in 2023. Near the OFW located northwest of the launch complex, all COC concentrations were less than laboratory method detection limits from monitoring wells (MW0039, MW0040, and LOXTA0002S) sampled in 2023. Aluminum results from LOX-IW0012S, which has been sampled routinely since 2006, detected a total aluminum concentration of 3,900 µg/L during the May/June 2023 sampling event. Results from the November 2023 event detected 5,700 µg/L for total aluminum and 5,500 µg/L for dissolved aluminum. These concentrations slightly decreased from the previous year but remain relatively consistent with historical detections. Aluminum will continue to be sampled on an annual basis at this well as results still exceed the GCTL of 200 µg/L and the Upper Limit of the KSC Background Concentration of 280 µg/L. PFAS results detected nine different PFAS compounds (out of 32 analyzed) from seven wells sampled. Two PFAS compounds, perfluorooctanesulfonic acid (PFOS) and perfluorooctanoic acid (PFOA), currently have FDEP Provisional GCTLs of 70 nanograms per liter (ng/L). All seven samples collected resulted in concentrations less than the FDEP Provisional GCTLs for both PFAS compounds; no exceedances were observed. PFOS and PFOA also have assigned United States Environmental Protection Agency (USEPA) Maximum Contaminant Levels (MCLs) of 4 nanograms per liter (ng/L). None of the PFOS results exceeded the USEPA MCLs. PFOA was detected in two samples above the USEPA MCL at concentrations of 5.8 ng/L (ECS-IW0009I) and 5.5 ng/L (ECS-IW0009S). Three other PFAS compounds, perfluorohexanesulfonic acid (PFHxS), perfluoro-n-nonanoic acid (PFNA), and hexafluoropropylene oxide dimer acid (GenX), currently have USEPA MCLs of 10 ng/L. PFHxS, PFNA, and GenX were not detected at concentrations greater than their respective USEPA MCLs in any of the seven wells. PFAS compounds without FDEP Provisional GCTLs or USEPA MCLs were screened against USEPA RSLs. No other detections exceeded their respective USEPA RSLs. Additional PFAS sampling will be conducted as part of a future PFAS Site Assessment. Based on O&M activities and performance monitoring, the following is recommended for LC39B: • Continue with Year 8 AS system operation within Zone Z4, which includes the AS expansion area. Zone Z3, which has been off since 2018, should remain off as no rebound has been observed. Zones Z1 and Z2, which were turned off at the end of 2022, will remain shut down as monitoring well results have consistently been below GCTLs or have low-level detections with stable or decreasing trends (Meeting Minute 2402-M10, Decision 2402-D30). • Continue with performance monitoring in 2024 with the same monitoring well network as 2023, except with the addition of MW0048 in both semi-annual events. Baseline concentrations for this well were collected during the November 2023 performance monitoring event. Semi-annual sampling should be planned for the May 2024 and November 2024 timeframes (Meeting Minute 2402-M10, Decision 2402-D31). • Continue sampling monitoring well, LOX-IW0012S, for aluminum (total and dissolved) on an annual basis in May 2024. It is also recommended to re-develop this well prior to the next sampling event (Meeting Minute 2402-M10, Decision 2402-D32). The above recommendations for LC39B were presented at the February 2024 KSCRT Meeting, with Team consensus reached on the path forward. The contents of this PM-CCR were also presented at this meeting.

Deborah M Wilson↗
NASA NTRS1998

A Discussion of Issues in Integrity Constraint Monitoring

In the development of large-scale software systems, analysts, designers, and programmers identify properties of data objects in the system. The ability to check those assertions during runtime is desirable as a means of verifying the integrity of the program. Typically, programmers ensure the satisfaction of such properties through the use of some form of manually embedded assertion check. The disadvantage to this approach is that these assertions become entangled within the program code. The goal of the research is to develop an integrity constraint monitoring mechanism whereby a repository of software system properties (called integrity constraints) are automatically inserted into the program by the mechanism to check for incorrect program behaviors. Such a mechanism would overcome many of the deficiencies of manually embedded assertion checks. This paper gives an overview of the preliminary work performed toward this goal. The manual instrumentation of constraint checking on a series of test programs is discussed, This review then is used as the basis for a discussion of issues to be considered in developing an automated integrity constraint monitor.

Fernandez, Francisco G.↗
DOE OSTI2018

Lightweight Detection of Cache Conflicts

In memory hierarchies, caches perform an important role in reducing average memory access latency. Minimizing cache misses can yield significant performance gains. As set-associative caches are widely used in modern architectures, capacity and conflict cache misses co-exist. These two types of cache misses require different optimization strategies. While cache misses are commonly studied using cache simulators, state-of-the-art simulators usually incur hundreds to thousands of times a program’s execution runtime. Moreover, a simulator has difficulty in simulating complex real hardware. To overcome these limitations, measurement methods are proposed to directly monitor program execution on real hardware via performance monitoring units. However, existing measurement-based tools either focus on capacity cache misses or do not distinguish capacity and conflict cache misses. In this paper, we design and implement CCProf, a lightweight measurement-based profiler that identifies conflict cache misses and associates them with program source code and data structures. CCProf incurs moderate runtime overhead that is at least an order of magnitude lower than simulators. With the evaluation on a number of representative programs, CCProf is able to guide optimizations on cache conflict misses and obtain nontrivial speedups.

Roy, Probir↗
NASA NTRSDate not supplied

Swarm Mentality: Toward Automatic Swarm State Awareness with Runtime Verification

Cyber-Physical Systems (CPSs) already exhibit impressive performance in all areas of human life, and swarms of CPSs promise to increase their capabilities even further. However, to effectively utilize CPS swarms their complexity of operation has to scale sub-linearly with the number of swarm members. Presenting the swarm to an operator as a single entity almost eliminates the additional per-member overhead entirely. To operate a swarm as one entity, and/or to increase the swarm’s autonomy, the operator and the swarm members need to reason and communicate at the same level of abstraction, i.e. the swarm needs a sense of “self.” Therefore, we require the ability to specify whole swarm properties yet monitor them at the member level. We examine one architecture for achieving this awareness by: 1) Defining a taxonomy for comparing techniques that synthesize this belief-state 2) Propose use of the Runtime Verification formal method to fill this role 3) Present preliminary designs for extending and embedding such a system in the Distributed Spacecraft Autonomy architecture to generate per-member monitors from swarm level specification.

Runtime Verification↗
NASA NTRS2015

A Flexible and Non-instrusive Approach for Computing Complex Structural Coverage Metrics

Software analysis tools and techniques often leverage structural code coverage information to reason about the dynamic behavior of software. Existing techniques instrument the code with the required structural obligations and then monitor the execution of the compiled code to report coverage. Instrumentation based approaches often incur considerable runtime overhead for complex structural coverage metrics such as Modified Condition/Decision (MC/DC). Code instrumentation, in general, has to be approached with great care to ensure it does not modify the behavior of the original code. Furthermore, instrumented code cannot be used in conjunction with other analyses that reason about the structure and semantics of the code under test. In this work, we introduce a non-intrusive preprocessing approach for computing structural coverage information. It uses a static partial evaluation of the decisions in the source code and a source-to-bytecode mapping to generate the information necessary to efficiently track structural coverage metrics during execution. Our technique is flexible; the results of the preprocessing can be used by a variety of coverage-driven software analysis tasks, including automated analyses that are not possible for instrumented code. Experimental results in the context of symbolic execution show the efficiency and flexibility of our nonintrusive approach for computing code coverage information

DO-178C↗
NASA NTRS2018

Runtime Verification: From Propositional to First-Order Temporal Logic

Runtime Verification is a branch of formal methods concerned with analysis of execution traces for the purpose of determining the state or general quality of the executing system. The field covers numerous approaches, one of which is specification-based runtime verification, where execution traces are checked against formal specifications. The paper presents syntax, semantics, and monitoring algorithms for respectively propositional and first-order temporal logics. In propositional logics the observed events in the execution trace are represented using atomic propositions, while first-order logic allows universal and existential quantification over data occurring as arguments in events. Monitoring of the first-order case is drastically more challenging than the propositional case, and we present a solution for this problem based on BDDs. We furthermore discuss monitorability of temporal properties by dividing them into different classes representing different degrees of monitorability.

Peled, Doron↗
DOE OSTI2018

Online Diagnosis of Performance Variation in HPC Systems Using Machine Learning

As the size and complexity of HPC systems grow in line with advancements in hardware and software technology, HPC systems increasingly suffer from performance variation due to shared resource contention as well as software- and hardware-related problems. Such performance variations can lead to failures and inefficiencies, and are among the main challenges in system resiliency. To minimize the impact of performance variation, one must quickly and accurately detect and diagnose the anomalies that cause the variation and take mitigating actions. However, it is difficult to identify anomalies based on the voluminous, high-dimensional, and noisy data collected by system monitoring infrastructures. This paper presents a novel machine learning based framework to automatically diagnose performance anomalies at runtime. Our framework leverages historical resource usage data to extract signatures of previously-observed anomalies. We first convert the collected time series data into easy-to-compute statistical features. We then identify the features that are required to detect anomalies, and extract the signatures of these anomalies. At runtime, we use these signatures to diagnose anomalies with negligible overhead. Here, we evaluate our framework using experiments on a real-world HPC supercomputer and demonstrate that our approach successfully identifies 98% of injected anomalies and consistently outperforms existing anomaly diagnosis techniques.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2025

Benchmark Tracking System for Performance Monitoring

Benchmarking is essential for high-performance software development, particularly for monitoring performance across code iterations. This project focused on enhancing the benchmarking process for Lamellar, an asynchronous runtime for High-Performance Computing (HPC) systems developed at Pacific Northwest National Laboratory. Prior to this work, benchmark results were difficult to track and compare across code versions, presenting significant challenges in identifying performance regressions and long-term trends. The primary objective was to establish a systematic, reproducible approach for measuring performance and detecting regressions following code commits. Our methodology involved three key components: standardizing benchmark outputs, implementing data versioning, and developing analysis tools. We standardized the benchmark output format to JSON Line records containing specific fields (execution time, hardware specifications, and environmental variables). To address data management challenges, we evaluated several options and eventually chose a git repository dedicated to benchmark data. We developed a suite of Python tools that processed benchmark results, enriched them with metadata, and facilitated search in the repository. The resulting system enables more efficient filtering and comparison of performance metrics across commit histories, hardware configurations, and benchmark variants through a unified query interface. Our implementation reduces computational overhead by first checking for existing results through configuration matching before initiating new benchmark runs, thereby conserving resources. The system has been validated by Lamellar developers. It organizes results by benchmark type and build configurations for efficient retrieval. Future developments include a planned Large Language Model interface for predicting benchmark performance, incorporating the criterion package for statistical analysis, which will enable automated detection of statistically significant performance changes, and integration with continuous integration pipelines. Despite these enhancements being reserved for future work, this project has successfully provided the Lamellar development team with a framework for maintaining consistent performance standards and identifying optimization opportunities across workloads and hardware environments.

97 MATHEMATICS AND COMPUTING↗
NASA NTRS2020

Actor-based Runtime Verification with MESA

This work presents a runtime verification approach implemented in the tool MESA (MEssage-based System Analysis) which allows for using concurrent monitors to check for properties specified in data parameterized temporal logic and state machines. The tool is implemented as an internal Scala DSL. We employ the actor programming model to implement MESA where monitors are captured by concurrent actors that communicate via messaging. The paper presents a case study in which MESA is used to effectively monitor a large number of flights from live US airspace data streams. We also perform an empirical study by conducting experiments using monitoring systems with different num- bers of concurrent monitors and different layers of indexing on the data contained in events. The paper describes the experiments, evaluates the results, and discusses challenges faced during the study. The evaluation shows the value of combining concurrency with indexing to handle data rich events.

Mehlitz, Peter↗
NASA NTRS2018

BDDs on the Run

Runtime verification (RV) of first-order temporal logic must handle a potentially large amount of data, accumulated during the monitoring of an execution. The DEJAVU RV system represents data elements and relations using BDDs. This achieves a compact representation, which allows monitoring long executions. However, the potentially unbounded, and frequently very large amounts of data value scan,ultimately, limit the executions that can be monitored. We present an automatic method for “forgetting” data values when they no longer affect the RV verdict on an observed execution.We describe the algorithm and illustrate its operation through an example.

Peled, Doron↗
DOE OSTI2019

LibPowerMon: A vendor-neutral system monitoring library

As power becomes an important resource to provision for modern HPC systems it becomes crucial to obtain deeper insights into application's power and thermal characteristics and to correlate application context with important system-level measurements. Existing profiling tools to monitor power and thermal measurements either operate at a granularity that is not fine enough to correlate with application-level events that describe application context or are not equipped to sample application-level events transparently. We introduce LibPowerMon, a lightweight, vendor-neutral user-level profiling framework to simultaneously sample user-specified application events and system-level metrics at up to 1 kHz sampling intervals. At the application level, LibPowerMon provides a source-level phase markup interface to capture application context. At runtime level, LibPowerMon records MPI and OpenMP events and can be extended to include other runtimes. At the system level, LibPowerMon samples power, thermal and relevant metrics, and provides an extensible interface to system's control capabilities. In this release, LibPowerMon supports monitoring and control functionalities on the Intel, IBM Power9 and Nvidia Volta architectures.

MARATHE, ANIRUDDHAP↗
DOE OSTI2020

Greggd

greg(g)d - Global runtime for eBPF-enabled gathering (w/ gumption) daemon Recently the linux kernel has added support for low-level kernel monitoring and profiling through a in-kernel virtual machine. The tooling around these new features (the extended Berkley Packet Filter or eBPF for short) is not mature and is difficult to use. Benefits from eBPF are especially hard to realize while trying to do large scale deployments and integrate with existing metric analysis stacks. A tool was needed to enable loading and collecting data from eBPF programs on large scale HPC systems. Given the problems above it was obvious we needed some wrapper program to compile, load, and collect data from eBPF programs running in the kernel. This tool needed to be lightweight without a heavy set of dependencies, relatively stable between different kernel versions, and integrate nicely with existing widely used metric collection tools. We wrote a program that wraps the eBPF tooling and sends data to our metric gathering tool. eBPF programs are either compiled using the host compiler stack, or loaded in the kernel directly from an object file. These programs are then attached to the system calls that we want to profile. Whenever these system calls are run, the eBPF program collects information of interest and writes that to memory. Our wrapper program polls these memory locations, reads and formats the data, then sends the information to a local unix socket. Our other monitoring tools are configured to read from that socket and send it to the rest of our metric monitoring stack for analysis.

Voss, Joseph [Oak Ridge National Lab. (ORNL), Oak ↗