Search NASA⌕ Search

SEARCH · Search NASA

Results for “cloud-based”

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 127 records · Page 7

Enhanced Preparation for Intelligent Cybermanufacturing Systems (EPICS)

Opportunities exist for realizing transformative advances in productivity and reductions in energy footprint through ubiquitous sensing in manufacturing environments. Enhanced Preparation for Intelligent Cybermanufacturing Systems (EPICS) is a 21-month (4 academic semesters, plus one summer) experience for graduate students that focuses on scaling the knowledge, understanding and leadership skills in the cyber manufacturing area. Masters students (8/year, 32 total) complete 2-year projects on industrially-driven project topics, rotating to internships in summer semester to work on scoping and implementation at project partners. Students complete academic training in embedded systems, process modeling, data science, and cloud-based systems design. Their projects are targeted toward sensor retrofit, process monitoring, root cause analysis, and sensor fusion.

Advanced Manufacturing↗

Generalizable Web User Interface for Scalable and Streamlined Deployment of Building Energy Management Systems in Small and Medium-Sized Commercial Buildings

Small and medium-sized commercial buildings (SMCBs) comprise 94% of US commercial buildings yet face significant barriers to implementing building energy management systems despite advances in smart device technology. Existing solutions present critical limitations: cloud-based API solutions simplify deployment but create vendor lock-in constraints; commercial integrated software solutions ensure compatibility via standardized protocols but require substantial cost and technical expertise; open-source IoT platforms offer cost-effective vendor independence but provide insufficient standardized protocol support for commercial building automation. This research presents a generalizable web user interface framework that bridges the gap between evolving smart device capabilities and lagging software infrastructure for SMCBs. The proposed system integrates VOLTTRON open-source middleware with an automated configuration converter that transforms unified specifications written in YAML, a human-readable data-serialization format, into system-specific files, streamlining manual setup processes. The vendor-agnostic architecture supports industry-standard protocols (BACnet and Modbus) and semantic building models while providing adaptive web interfaces that dynamically adjust to various building configurations. Demonstrations through simulation-based testing and a field deployment show automatic interface adaptation across heterogeneous HVAC systems and multizone monitoring. The automated configuration converter also substantially reduces labor-intensive setup.

Chung, Jihoon [ORNL] (ORCID:0000000184880815)↗

The Concept of a Quantum Edge Simulator: Edge Computing and Sensing in the Quantum Era

Sensors, enabling observations across vast spatial, spectral, and temporal scales, are major data generators for information technology (IT). Processing, storing, and communicating this ever-growing amount of data pose challenges for the current IT infrastructure. Edge computing—an emerging paradigm to overcome the shortcomings of cloud-based computing—could address these challenges. Furthermore, emerging technologies such as quantum computing, quantum sensing, and quantum communications have the potential to fill the performance gaps left by their classical counterparts. Here, we present the concept of an edge quantum computing (EQC) simulator—a platform for designing the next generation of edge computing applications. An EQC simulator is envisioned to integrate elements from both quantum technologies and edge computing to allow studies of quantum edge applications. The presented concept is motivated by the increasing demand for more sensitive and precise sensors that can operate faster at lower power consumption, generating both larger and denser datasets. These demands may be fulfilled with edge quantum sensor networks. Envisioning the EQC era, we present our view on how such a scenario may be amenable to quantification and design. Given the cost and complexity of quantum systems, constructing physical prototypes to explore design and optimization spaces is not sustainable, necessitating EQC infrastructure and component simulators to aid in co-design. We discuss what such a simulator may entail and possible use cases that invoke quantum computing at the edge integrated with new sensor infrastructures.

47 OTHER INSTRUMENTATION↗

The Vera C. Rubin Observatory Data Preview 1

We present Rubin Data Preview 1 (DP1), the first data from the National Science Foundation–Department of Energy Vera C. Rubin Observatory, comprising raw and calibrated single-epoch images, coadds, difference images, detection catalogs, and ancillary data products. DP1 is based on 1792 optical–near-infrared exposures acquired over 48 distinct nights by the Rubin Commissioning Camera (LSSTComCam) on the Simonyi Survey Telescope at the Summit Facility on Cerro Pachón, Chile in late 2024. DP1 covers ∼15 deg 2 distributed across seven roughly equal-sized noncontiguous fields, each independently observed in six broad photometric bands, ugrizy. The median FWHM of the point-spread function across all bands is approximately 1"14, with the sharpest images reaching about 0." 58. The 5σ point-source depths for coadded images in the deepest field, the Extended Chandra Deep Field South, are u = 24.55, g = 26.18, r = 25.96, i = 25.71, z = 25.07, and y = 23.1. Other fields are no more than 2.2 mag shallower in any band, where they have nonzero coverage. DP1 contains approximately 2.3 million distinct astrophysical objects, of which 1.6 million are extended in at least one band in coadds, and 431 solar system objects, of which 93 are new discoveries. DP1 is approximately 3.5 TB in size and is available to Vera C. Rubin Observatory data rights holders via the Rubin Science Platform, a cloud-based environment for the analysis of petascale astronomical data. While small compared to future LSST releases, its high quality and diversity of data support a broad range of early science investigations ahead of full operations in 2026.

Ground-based astronomy↗

Sensitivity of thermodynamic profiles retrieved from ground-based microwave and infrared observations to additional input data from active remote sensing instruments and numerical weather prediction models

Accurate and continuous estimates of the thermodynamic structure of the lower atmosphere are highly beneficial to meteorological process understanding and its applications, such as weather forecasting. In this study, the Tropospheric Remotely Observed Profiling via Optimal Estimation (TROPoe) physical retrieval is used to retrieve temperature and humidity profiles from various combinations of input data collected by passive and active remote sensing instruments, in situ surface platforms, and numerical weather prediction models. Among the employed instruments are microwave radiometers (MWRs), infrared spectrometers (IRSs), radio acoustic sounding systems (RASSs), ceilometers, and surface sensors. TROPoe uses brightness temperatures and/or radiances from MWRs and IRSs, as well as other observational inputs (virtual temperature from the RASS, cloud-base height from the ceilometer, pressure, temperature, and humidity from the surface sensors) in a physical iterative retrieval approach. This starts from a climatologically reasonable profile of temperature and water vapor, with the radiative transfer model iteratively adjusting the assumed temperature and humidity profiles until the derived brightness temperatures and radiances match those observed by the MWR and/or IRS instruments within a specified uncertainty, as well as within the uncertainties of the other observations, if used as input. In this study, due to the uniqueness of the dataset that includes all the above-mentioned sensors, TROPoe is tested with different observational input combinations, some of which also include information higher than 4 km above ground level (a.g.l.) from the operational Rapid Refresh numerical weather prediction model. These temperature and humidity retrievals are assessed against independent collocated radiosonde profiles under non-cloudy conditions to assess the sensitivity of the TROPoe retrievals to different input combinations.

54 ENVIRONMENTAL SCIENCES↗

Tansey_MICRE_AAD_lidar_cloud_and_precip_phase_V2.0_20160406_201601120

This data file contains retrievals of cloud-base and below-cloud precipitation phase base for the MICRE campaign. The retrieved base is largely based on AAD depolarization lidar measurements. BOM cloud radar (BASTA), ARM ceilometer, and U. Canterbury ceilometer data are used to locate cloud base and below-cloud precipitation. Details on the algorithm and analysis of results are given in Tansey et al. 2023 (submitted DOI: 10.22541/essoar.168394768.89694625/v1). The data is limited to the period 20160406 to 201601120 during which both AAD lidar data and BoM radar data was collected.

54 ENVIRONMENTAL SCIENCES↗

Arctic Mixed-Phase Cloud Base Ice Precipitation Properties During the M-PACE Field Campaign

Cloud-climate feedbacks are still the greatest source of uncertainty in current climate projections. Arctic clouds, which are predominantly stratiform and supercooled, often long-lived, and nearly-continuously precipitate ice particles, contribute roughly 10% of the uncertainty attributed to the global cloud feedback. This Arctic cloud uncertainty is driven by incomplete observational and theoretical knowledge required to estimate and explain the state and active processes occurring in those clouds. A focus on ice precipitation properties at Arctic cloud base rather than the surface deconfounds the product of cloud condensate sink processes from the influence of the atmospheric thermodynamic state below cloud base, rendering cloud-base properties a more appealing target for inference and evaluation of model simulations. This dataset provides a set of 25 samples from the M-PACE field campaign, all of which were retrieved using the synthesis of ARM radar and lidar measurements. The retrieved ice precipitation variables in this dataset include, among others, the ice number concentration, water content, PSD parameters, precipitation rate, mass-weighted fall velocity, vertical air motion, and effective radius, all of which are highly valuable for model evaluation and a general understanding of polar cloud sink processes. Each variable sample includes its mean value and associated uncertainty. Additional variables based on ARM measurements (liquid layer statistics, etc.) are included in this dataset as well. The retrieval algorithm and analysis of this dataset are described in Silber (JGR, 2023, https://doi.org/10.1029/2022JD038202).

54 ENVIRONMENTAL SCIENCES↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on ~30 m range gates, stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, below range, ran out of signal, cloud-topped). Cloud Base Height (Haar-gradient detection): 15 min estimates of cloud-base height (m) with a cloud-detection quality flag (0–3: none, low, moderate, high). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (2.0.0), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution, with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on 30 m range gates (and 3 m range gates), stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, ran out of signal, below range, cloud-topped). Cloud Base Height (Haar-gradient detection): 10 min estimates of cloud-base height (m). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (3.0.0), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution (and 3 m for the year of 2025), with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min (10 min for Cloud Heights) summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

MSD CoP Webinar: "Advances in MSD-LIVE to Support the MSD Community of Practice"

Context: This webinar was hosted by the MultiSector Dynamics Community of Practice (MSD CoP; https://multisectordynamics.org). Advances in MSD-LIVE to Support the MSD Community of Practice Presenters: Casey Burleyson and Zoe Guillen (Pacific Northwest National Laboratory) Abstract: The MultiSector Dynamics Living, Intuitive, Value-adding, Environment (MSD-LIVE; msdlive.org) is a cloud-based data management system and advanced computing platform that enables MSD researchers to document and archive their data, run their models and analysis tools, and share their data, software, and workflows within the MSD Community of Practice. Recently, several high-profile datasets have attracted many new users to MSD-LIVE. This webinar has two goals: 1) To refamiliarize the MSD community and new users with the components of the platform (e.g., the data repository, model training notebooks, and data dashboards) and to highlight examples of how these components are advancing MSD science and 2) To demonstrate new features in v3 of the platform, released in late 2025. The main new feature in v3 is the ability to interactively explore data in MSD-LIVE without downloading it. MSD-LIVE users can now click a button in our data repository and launch a blank Jupyter notebook with access to the underlying data on AWS. Users can use the notebook to write analysis, visualization, or subsetting routines that process the data directly on the AWS cloud. We also added a GitHub integration feature that allows users to share analysis or visualization code they develop with the community of MSD-LIVE users. The webinar will wrap up with a look at what's coming next for MSD-LIVE in 2026. Moderator: Patrick M. Reed (MSD CoP Facilitation Team) This webinar was held on: May 12th, 2026 from 1-2 PM EST.

Open Science↗

Baltimore Social-Environmental Collaborative (BSEC) Doppler Lidar & Derived Products

This repository contains all processed Doppler‐lidar outputs from the PSU lidar deployed for the Baltimore Social‐Environmental Collaborative (BSEC) project. Vertical Stare Scans (fixed‐beam, vertical profiling): 1 Hz backscatter intensity (m⁻¹ sr⁻¹), signal‐to‐noise ratio (unitless), and Doppler vertical‐velocity (m s⁻¹) on 30 m range gates (and 3 m range gates), stored as CF-compliant NetCDF. Wind Profiles (horizontal‐wind retrieval): daily NetCDF outputs of retrieved horizontal wind speed (m s⁻¹) and direction (degrees), computed from the angled‐scan returns. Profile Statistics (summary statistics on the vertical velocity): 15 min windows (default) of mean, variance, skewness, kurtosis, high-frequency variance, etc., as a function of height; saved as CF-compliant NetCDF files. Boundary Layer Height (BLH) (fuzzy-logic output): 15 min BLH estimates (m), with lower/upper fuzzy bounds (m) and a quality flag (0–4) indicating data status (e.g., no data, good, ran out of signal, below range, cloud-topped). Cloud Base Height (Haar-gradient detection): 10 min estimates of cloud-base height (m). All five product streams are organized by year and date under their own top-level folders (01_Vertical_Stare_Scans/ through 05_Cloud_Height/). Each folder contains a data_ /YYYY/ subdirectory with daily CF-compliant NetCDF outputs (96 windows per day at 15 min intervals). Global attributes in each file include creation history, version (3.0.1), institution, and source. Instrument & MeasurementsThe PSU Doppler Lidar samples aerosol backscatter (m⁻¹ sr⁻¹), signal-to-noise ratio, and radial velocity at ~1 Hz. Vertical stare scans point the beam straight up; after collecting angled scans through multiple elevation angles, the "Wind Profiles" product contains the fully retrieved horizontal wind speed and direction. Data were collected continuously at ~30 m range resolution (and 3 m for the year of 2025), with a typical height ceiling of ~12 km. How to Use Open any NetCDF with Python's xarray, MATLAB, or similar CF-compliant tools. Stare scans and angled-scan retrievals (Wind Profiles) are CF-compliant daily NetCDF files. Profile-Statistics, BLH, and Cloud Height files are daily 15 min (10 min for Cloud Heights) summaries (96 time steps per file). Inspect the included variables (e.g., vertical_velocity_variance, wind_speed, BLH, cloud_base_height) for your analyses. Use the quality flags (BLH_flag, cloud_flag) to filter out poor-quality retrievals. For more information or questions about processing methods, please contact:Nicholas E. Prince ⟨nec5299@psu.edu⟩Penn State Department of Meteorology & Atmospheric Science

Air Quality↗

RTN-095: The Vera C. Rubin Observatory Data Preview 1

We present Rubin Data Preview 1 (DP1), the first release of data from the NSF-DOE Vera C. Rubin Observatory, consisting of raw and calibrated single-epoch images, coadds, difference images, detection catalogs, and other derived data products. DP1 is based on 1792 science-grade optical/near-infrared exposures acquired over 48 distinct nights by the Rubin Commissioning Camera, LSSTComCam, on the Simonyi Survey Telescope at the Summit Facility on Cerro Pachón, Chile during the first on-sky commissioning campaign in late 2024. DP1 covers a total of ~15 sq. deg. over seven roughly equally-sized non-contiguous fields, each independently observed in six broad photometric bands, ugrizy, spanning a range of stellar densities and latitudes and overlapping with external reference datasets. The median image quality across all bands, measured by the FWHM of the point-spread function, is approximately 1.13 arcseconds, with the sharpest images reaching about 0.65 arcseconds. DP1 contains approximately 2.3 million distinct astrophysical objects, of which 1.6 million are extended in at least one band, and 431 solar system objects, of which 93 are new discoveries. DP1 is approximately 3.5 TB in size and available to Rubin data rights holders via the Rubin Science Platform, a cloud-based environment for the analysis of petascale astronomical data. While small compared to future LSST releases, its high quality and diversity of data support a broad range of early science investigations across all four LSST themes, providing a valuable opportunity to engage with Rubin data ahead of the start of full operations in late 2025.

79 ASTRONOMY AND ASTROPHYSICS↗

Integrated Risk-Informed Condition Based Maintenance Capability and Automated Platform: Technical Report 3

This project is a collaborative research effort between PKMJ Technical Services LLC, Idaho National Laboratory, and Public Service Enterprise Group (PSEG) Nuclear, LLC. The collaboration, led by PKMJ Technical Services LLC, is part of the industry Funding Opportunity Announcement (FOA) award under Advanced Nuclear Technology Development FOA #DE-FOA-0001817. The pilot demonstration focuses on the Circulating Water System (CWS), an important non-safety-related system that impacts the power generation capability of the plant site. Achieving riskinformed condition-based Predictive Maintenance (PdM) on the CWS will result in significant economic benefits, and the developed methodologies can also be applied to other plant systems. This approach supports an industry goal of ensuring that nuclear power generation remains a viable, economically competitive option in the energy market. Operation and Maintenance (O&M) costs include labor-intensive Preventive Maintenance (PM) programs that involve manually performed inspection, calibration, testing, and maintenance of plant assets at periodic frequencies as well as time-based replacement of assets, irrespective of condition. This project offers an alternative by focusing on riskinformed condition-based maintenance to reduce O&M costs while still maintaining plant health and safety. This report summarizes the progress made toward achieving a risk-informed condition-based maintenance approach. The research and development (R&D) activities presented in this report are associated with development of a nuclear digital platform application, integration of fault signature models, and automated work management processes. The fault signatures and Machine Learning (ML) models are key components in predictive analytics and are heavily leveraged to improve the insights received by existing plant process data sources. Availability of the analysis results within a centralized digital platform enhances efficiency by enabling automation of activities otherwise performed manually. Personnel are presented with enhanced information that can be used to evaluate plant status and risks. Utilizing the enhancements to data analytics supports automated responses, (i.e. issuance of work orders) to address developing equipment faults and thus preventing forced, unplanned shutdowns of components or systems. The R&D activities described within this report lay the foundation for developing and demonstrating a digital automated platform to centralize the implementation of condition monitoring and response to equipment faults. The digital automated platform is cloud-based and designed to enable improved efficiency of plant processes. The digital platform includes content related to maintenance optimization, fault signature analysis, and plant records, which can all be used to support efficiencies when located within a centralized digital platform. These efficiencies could be further enhanced when deployed through industry-wide deployment of the technology to improve insights and processes based upon economies of scale.

46 INSTRUMENTATION RELATED TO NUCLEAR SCIENCE AND ↗

Framework for Optimization, Quantification of Uncertainty and Surrogates – Updated Capabilities

This poster presents updated capabilities within the FOQUS Toolset, covering core features as well as project-based applications. Specifically, the poster highlights advancements in FOQUS integration with cloud-based clients, plugin support for machine learning tools and external simulations, sequential design of experiments, and advanced support for dynamic process models. The applications demonstrate the breadth of FOQUS predictive capabilities for chemical, energy and economic system analysis.

Paul, Brandon↗

Disrupting EV Charging Sessions and Gaining Remote Code Execution with DoS, MITM, and Code Injection Exploits using OCPP 1.6

Open Charge Point Protocol (OCPP) 1.6 is widely used in the electric vehicle (EV) charging industry to communicate between Charging System Management Services (CSMSs) and Electric Vehicle Supply Equipment (EVSE). Unlike OCPP 2.0.1, OCPP 1.6 uses unencrypted websocket communications to exchange information between EVSE devices and an onpremise or cloud-based CSMS. In this work, we demonstrate two machine-in-the-middle (MITM) attacks on OCPP sessions to terminate charging sessions and gain root access to the EVSE equipment via remote code execution (RCE). Second, we demonstrate a malicious firmware update with a code injection payload to compromise an EVSE. Lastly, we demonstrate two methods to prevent availability of the EVSE or CSMS. One of these, originally reported by SaiFlow, prevents traffic to legitimate EVSE equipment using a DoS-like attack on CSMSs by repeatedly connecting and authenticating several CPs with the same identities as the legitimate CP. These vulnerabilities were demonstrated with proof-of-concept exploits in a virtualized Cyber Range at Wright State University and/or with a 350 kW Direct Current Fast Charger (DCFC) at Idaho National Laboratory. The team found that OCPP 1.6 could be protected from these attacks by adding secure shell (SSH) tunnels to the protocol, if upgrading to OCPP 2.0.1 was not an option. Index Terms—Electric vehicle charging, cybersecurity, OCPP, cyberattack, cyber-resilience. INSPEC Accession Number: 23981565

99 GENERAL AND MISCELLANEOUS↗

Secure hierarchical processing using a secure ledger

Disclosed is a system and method for processing data using blockchain technology. The system includes a memory having programmable instructions stored thereon that, when executed by a processor, cause the system to: authenticate one or more sensors in anticipation of receiving component data; receive component data, upon successful authentication; store the component data locally or to a cloud-based server and/or calculate a root value for the component data; store or embed the root value with the stored component data; condense the component data and link the condensed component data to the stored component data via the root value. The system further includes instructions to log the condensed data, including the root value, to a ledger, and to identify a tag or transaction id corresponding to the logging event for subsequent retrieval of the condensed data using the tag or transaction id.

Zhao, Wenbing↗

Advanced Transmission Technologies – GETs and HPCs Session 1: ATT Foundations and Dynamic Line Ratings (DLRs)

The INL TADA GETs Cohort Session 1, held on November 4, 2025, convened experts to address the integration of advanced transmission technologies, including Grid-Enhancing Technologies (GETs) and High Performance Conductors (HPCs), with a focus on digital assurance challenges. The session highlighted the growing importance of cybersecurity, supply chain transparency, reliability, and business risk management in deploying GETs, especially Dynamic Line Ratings (DLRs). Participants examined how expanded attack surfaces, limited vendor pools, and new regulatory requirements—such as FERC Orders 881, 2023, and 1920—are influencing utilities and technology providers. The workshop underscored the need for cyber-informed engineering, secure-by-design principles, and practical risk management strategies, while fostering collaboration and knowledge sharing among industry peers. Technical discussions covered the evolution from static to dynamic line ratings, complexities of cloud-based architectures, and NERC CIP compliance challenges. The session concluded with a collaborative risk exercise and a preview of future workshops on advanced power flow control and transmission topology optimization, reinforcing the cohort’s commitment to advancing digital assurance in the energy sector.

24 - POWER TRANSMISSION AND DISTRIBUTION↗

Latency Analysis of the Nexus Digital Twin Framework

Real-time digital catalogs are increasingly relied upon to track metadata and connect disparate data sources for cloud-based data integration efforts. One such tool, Deeplynx Nexus is supporting real-time digital twin efforts through event-driven data integration and time-series queries. Nexus’s usefulness for these applications depends critically on how quickly individual records can be uploaded and downloaded, since delays directly affect the responsiveness of any system built on top of it. However, the actual latency a user should expect from Nexus has not been systematically measured before, particularly for the small, frequent transactions typical of live sensor feeds. Here we show that single-record round-trip latency is 61.1 ms on a local Nexus instance and 391.7 ms on the hosted production infrastructure, a roughly 6.4x difference driven primarily by fixed per-request overhead rather than data volume. This overhead dominates at small scale: comparing single-record and ten-record trials suggests approximately 56 ms of each single-record request is fixed connection and authentication cost rather than data-transfer time, meaning batching even a handful of records is substantially more efficient than transmitting them individually. At large batch sizes, this pattern reverses for uploads, which converge to near parity between local and hosted environments by 25,000-50,000 records, while download latency remains persistently 5.7-6.4x slower on hosted infrastructure even at scale. These results suggest that Nexus deployments intended for real-time digital twin applications should prioritize record batching over single-record transactions, and that download-path optimization on hosted infrastructure offers the largest remaining opportunity to reduce latency at scale. We anticipate these baseline measurements will serve as a reference point for future digital twin projects evaluating whether Nexus’s latency profile meets their real-time requirements, and as a benchmark for tracking the effect of future infrastructure or API changes.

99 - GENERAL AND MISCELLANEOUS↗