Digital Heating: Multi-Scale Thermal Control

• Digital heating is a unified framework for digitally managing thermal behavior using sensor data, reduced-order models, and software-defined actuation.
• It integrates layered data handling and physical modeling across diverse applications, including building energy optimization, district heating, droplet microfluidics, and digital glass forming.
• These systems enhance energy efficiency, process control, and precision thermal patterning while addressing the limitations of conventional black-box models.

Digital heating, in the cited literature, denotes digitally mediated production, modulation, forecasting, or control of thermal behavior across markedly different scales: multistory residential buildings, district heating networks, historic buildings, droplet-based microfluidics, programmable microheater arrays, and laser-based glass fabrication. Despite these differences, the reported systems share a common structure: thermal-state acquisition through sensors or imaging, software-based integration of heterogeneous data streams, reduced-order or data-driven models, and digitally specified actuation through valves, heaters, pumps, or laser power. The term therefore spans both heat-supply infrastructures and finely localized thermal patterning, with applications ranging from energy optimization and conservation diagnostics to thermocapillary transport and process control (Morkunaite et al., 2024, Stock et al., 2024, Yakhshi-Tafti et al., 2010, Goyal et al., 25 Feb 2026, Tiwari et al., 31 Mar 2026).

1. Scope and technical domains

The available literature uses digital-heating methods in at least five distinct technical settings. At building scale, a modular digital twin integrates IoT data, weather feeds, 3D geometry, and grey-box RC-network models for on-line heating optimization in multistory residential buildings. At district scale, open-source geospatial and statistical data are assembled into digital representations of district-heating systems for simulation, optimization, and scenario analysis. At microscale, thermal gradients generated by embedded microheaters actuate droplets on liquid platforms, while dense programmable Pt microheater arrays create binary or grayscale heat images and pattern liquid metal. In manufacturing, a real-time controller regulates work-zone temperature in Digital Glass Forming by adjusting commanded laser power from synchronized thermal-camera measurements (Morkunaite et al., 2024, Stock et al., 2024, Yakhshi-Tafti et al., 2010, Goyal et al., 25 Feb 2026, Tiwari et al., 31 Mar 2026).

Domain	Digital substrate	Thermal objective
Multistory residential buildings	IoT streams, 3D representation, grey-box modeling	heating energy optimization
Historic buildings	cloud-connected sensor boxes, ontology, parametric digital twin	heating and ventilation strategies
District heating systems	open-source data and tools	sustainable heat integration and operational improvements
Droplet microfluidics	embedded Titanium micro heaters and GUI	droplet transport on predetermined pathways
Programmable microheater arrays	32 × 32 row-column addressed Pt elements	spatiotemporal thermal modulation and patterning
Digital Glass Forming	synchronized imaging, data-driven model, closed-loop controller	work-zone temperature regulation

This breadth matters because it prevents a narrow identification of digital heating with only smart thermostats or only process control. A plausible implication is that the unifying object is not a specific device class, but the coupling of thermal physics to digital sensing, model updating, and software-defined actuation.

2. Building-scale digital twins and interpretable heating models

A detailed building-scale formulation is given by a modular, five-layer digital-twin framework for grey-box modeling of multistory residential-building thermal dynamics and on-line heating optimization. The layers are: Physical Layer (IoT Data Acquisition), Integration Layer, Data Storage & 3D Representation Layer, Simulation (Grey-Box Modeling) Layer, and User-Interface Layer. Smart meters and indoor-air-quality sensors continuously stream heating-energy consumption, indoor temperature, humidity, VOC, flow-rate, and valve-position data, while an external weather API supplies outdoor ambient temperature and solar-irradiance time series. Zabbix brokers incoming JSON feeds; custom REST APIs built with Swagger/Plumber in R and Node-based services harmonize timestamps, including disaggregating hourly meter readings into 15-minute bins; Bentley iTwin stores both a photogrammetry-derived 3D mesh and linked time series; and CTSMR in R implements a continuous-time stochastic RC-network model (Morkunaite et al., 2024).

The state-space model is given as

$C\,\frac{dT}{dt} = A\,T + B\,u + E\,w,$

with thermal states $T = [T_i,T_m,T_h,T_e,T_s]^T$, inputs $u = [P_h,P_s,T_a]$, diagonal lumped capacitances $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$, and Wiener-process variances in $E$ for unmodeled disturbances. For the principal thermal-mass model $(T_i\!-\!T_m\!-\!T_h)$, the balance equations include conductive couplings, solar gains $G\cdot A_w\cdot P_s$, and stochastic terms, while the measurement equation is

$$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$

Model selection begins with a first-order RC model and proceeds by forward-selection via likelihood-ratio tests, accepting a candidate SDE only if $p<0.05$. Parameter identification uses maximum-likelihood estimation on continuous-time SDEs with user-configurable lower and upper bounds for each $R$ and $T = [T_i,T_m,T_h,T_e,T_s]^T$0. In the Kaunas case study, a seven-day winter week of 764 points at 15-minute resolution fit the $T = [T_i,T_m,T_h,T_e,T_s]^T$1 model in 1 min 22 s. The best model, TiThTm, yielded $T = [T_i,T_m,T_h,T_e,T_s]^T$2, $T = [T_i,T_m,T_h,T_e,T_s]^T$3, $T = [T_i,T_m,T_h,T_e,T_s]^T$4, $T = [T_i,T_m,T_h,T_e,T_s]^T$5, $T = [T_i,T_m,T_h,T_e,T_s]^T$6, $T = [T_i,T_m,T_h,T_e,T_s]^T$7, and $T = [T_i,T_m,T_h,T_e,T_s]^T$8 leading to $T = [T_i,T_m,T_h,T_e,T_s]^T$9. Residuals passed the whiteness test with $u = [P_h,P_s,T_a]$0, the cumulated periodogram remained within 95% bounds, and overlaid $u = [P_h,P_s,T_a]$1 predictions tracked measurements with $u = [P_h,P_s,T_a]$2 (Morkunaite et al., 2024).

The user interface is equally central to the concept. Built in React/TypeScript atop iTwin.js, it displays tabular and charted time series, interactive 3D markers, historical-window selection for model fitting, optimized $u = [P_h,P_s,T_a]$3, $u = [P_h,P_s,T_a]$4, $u = [P_h,P_s,T_a]$5, derived HTC, correlation heatmaps, and overlaid measured-versus-predicted curves. The reported purpose is decision support for facility managers, energy providers, and governing bodies, including what-if sliders on thermostat setpoints and pre-heating schedules, multi-building comparison of HTC and thermal capacitance, and forecasting of aggregated district-heating load under varying outdoor conditions (Morkunaite et al., 2024).

A second building-scale strand appears in the preservation of historic buildings. At Löfstad Castle, thirteen cloud-connected sensor boxes equipped with 84 sensors were installed from basement to attic, sampling at 2 samples/minute. The edge platform used Raspberry Pi 3 B+ hardware with a Grove Base Hat and Huawei 4G USB modem; the cloud stack used Azure IoT Hub, Azure Functions, Azure SQL Database, and an extended Brick ontology (v1.3.0) accessed via SPARQL. The ontology encoded rooms, floors, sensor locations, building hierarchy, material properties such as 1.1 m thick masonry walls, and links from sensor UUIDs to physical assets. Hygrothermal analysis employed humidity mixing ratio under EN 16242:2012 and the WUFI-Bio substrate-category-I mold-risk isopleth

$u = [P_h,P_s,T_a]$6

The results showed basement and ground-floor moisture problems, with indoor MR exceeding outdoor MR 75% of the time and basement RH within 95–100%; Rooms 3 and 5 exceeded $u = [P_h,P_s,T_a]$7 for 20–35% of the year; and first-floor Room 103 remained within the $u = [P_h,P_s,T_a]$8 safe band 95% of the time except during extended occupancy. Reported recommendations included vapor-barrier installation, intermittent or zoned heating based on occupancy indicated by CO$u = [P_h,P_s,T_a]$9 spikes, and natural ventilation when CO$C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$0 ppm (Ni et al., 2024).

Together, these two building cases show that digital heating at building scale is not restricted to energy minimization. It also includes interpretable thermal identification, hygrothermal risk diagnosis, and the derivation of conservation-compatible control rules.

3. District heating as a digital modeling workflow

At network scale, digital heating is framed as the generation of district-heating models using publicly available data and open-source tools. Stock et al. decompose the workflow into four architectural layers: data acquisition, network generation, demand estimation, and model assembly. The workflow gathers kml files from local district-heating operator websites, image-based PDF or supply-area maps georeferenced and vectorized in QGIS, OpenStreetMap street centerlines where no network drawing exists, building information from Energieatlas NRW and OSM, Zensus 2011 grid data for year of construction, InWIS building-block district-heating connection rate, and local heating-plant and cogeneration-unit data. The resulting model supports simulation, optimization, tool benchmarking, and scenario-based analyses of sustainable heat integration, reduced supply temperatures, and infrastructure adaptations (Stock et al., 2024).

The computational core is explicitly hydraulic and thermal. The nominal mass flow at each building substation is

$C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$1

with $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$2. Pipe diameter design assumes a maximum flow velocity, giving

$C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$3

Hydraulic head loss follows Darcy–Weisbach,

$C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$4

and thermal heat loss per pipe segment is

$C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$5

When buildings are clustered, nodal demands aggregate as sums over constituent buildings. The open-source software stack includes QGIS, geopandas, shapely, fiona, rasterio, osmnx, uesgraphs, demandlib, scikit-learn’s KMeans, numpy, and pandas, with optional export to Modelica or Dymola for dynamic simulation (Stock et al., 2024).

Two case studies illustrate scale. In Bottrop, the input comprised a kml file of the existing network with 1,200 edges, 1 central CHP node, and 4,458 connected buildings. Outputs included a graph with 4,458 consumer nodes, 1 supply node, 1,250 network forks, total pipe length of approximately 45 km, mean diameter of approximately 150 mm, annual demand of approximately 60 GWh, and typical supply/return 90/50 °C profiles. Data-preparation time was about 2 h on a standard PC, and memory footprint about 200 MB for the full unclustered model. In Essen, the model used the same data sources, started from 8,066 buildings and 4 heat plants, and applied KMeans clustering to 4,000 aggregated consumer nodes. The reduced graph had 4 supply nodes, 4,000 consumers, and approximately 2,500 edges; total annual energy was about 110 GWh; simulation runtime was reduced by more than 50%; and clustering reduced solver iterations by about 40% in a transient simulation (Stock et al., 2024).

The paper also states its own limits. Supply-area maps may not match true pipe routing; random selection of connected buildings may misrepresent actual clustering; $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$6 is fixed at 30 K; measured temperature and pressure data are absent; standardized demand profiles neglect occupant behavior; and the Zensus 2011 building-age grid may be outdated. Nonetheless, the workflow explicitly recommends extension toward a real-time digital twin by integrating SCADA or IoT telemetry, using co-simulation environments such as mosaik or HELICS, and embedding optimization engines such as Pyomo, PyPSA, or JuMP (Stock et al., 2024).

4. Microscale thermal actuation and programmable heat fields

In droplet-based microfluidics, digital heating refers to the software-controlled creation of spatio-temporal thermal gradients that move droplets on a liquid platform. Yakhshi-Tafti, Cho, and Kumar demonstrated a silicon-based droplet transportation platform with embedded Titanium micro heaters covered by a shallow pool of inert liquid FC-43. Heaters were interfaced with control electronics and driven through a computer graphical user interface. By creating appropriate spatio-temporal thermal gradient maps, transport of droplets on predetermined pathways was demonstrated with high level of robustness, speed, and reliability. The report emphasizes advantages over solid substrates, including avoidance of evaporation, contamination, pinning, hysteresis, and irreversibility of droplet motion, as well as minimal thermal loading for biochemical microsystems and lab-on-chip applications (Yakhshi-Tafti et al., 2010).

The accompanying technical summary explicitly notes that the published paper is very brief and does not specify many detailed dimensions, electrical-driving parameters, graphs, or tables. It associates the system with standard thermocapillary or Marangoni relations, while noting that the original article does not present those formulas explicitly. In that standard description, temperature-dependent surface tension $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$7 produces an interfacial Marangoni stress $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$8, which drives droplet motion toward warmer regions. The same summary lists representative ranges from comparable literature: thermal gradients of $C = \operatorname{diag}(C_i,C_m,C_h,C_e,C_s)$9–$E$0, heater power of order $E$1–$E$2 per active element, droplet speeds up to order $E$3–$E$4, response times of approximately $E$5–$E$6 for each element, and overall droplet repositioning in $E$7–$E$8; it simultaneously states that these ranges are not supplied by the short published report itself (Yakhshi-Tafti et al., 2010).

A more fully specified microscale implementation is the programmable $E$9 microheater array consisting of 1,024 individually addressable Pt-based Joule-heating elements. Each pixel is a $(T_i\!-\!T_m\!-\!T_h)$0 double-spiral Pt resistor with 40 turns, 2 $(T_i\!-\!T_m\!-\!T_h)$1m minimum line width, center-to-center pitch 500 $(T_i\!-\!T_m\!-\!T_h)$2m, and total array footprint $(T_i\!-\!T_m\!-\!T_h)$3. The system uses row-column multiplexing, a demultiplexer selecting one of 32 row or column bus-lines, a TMUX9616 high-voltage channel switch, and an Arduino Mega providing bit-streams and clock up to 25 kHz. Addressing one pixel takes 18 clock pulses, or approximately 0.72 ms at 25 kHz. Sequential addressing uses a fixed period $(T_i\!-\!T_m\!-\!T_h)$4 with duty cycle controlling pixel temperature; a typical driving signal with CLK = 25 kHz and $(T_i\!-\!T_m\!-\!T_h)$5 at 20% duty cycle yields intermediate temperatures of approximately 30–45 °C (Goyal et al., 25 Feb 2026).

Thermally, each pixel has $(T_i\!-\!T_m\!-\!T_h)$6 and is purely resistive in the operating range. Under a lumped model,

$(T_i\!-\!T_m\!-\!T_h)$7

with steady-state rise $(T_i\!-\!T_m\!-\!T_h)$8. Experimentally, $(T_i\!-\!T_m\!-\!T_h)$9 yields temperatures up to 150 °C in DC operation. Rise time to 90% of $G\cdot A_w\cdot P_s$0 is approximately 2 s at 75 V DC, fall time to 10% is approximately 3 s, and thermal cross-talk has full width at half-max of approximately 4 pixels or 2 mm. Binary patterns such as a checkerboard and smiley face were generated by setting 20% duty cycle for ON pixels and 0% for OFF pixels; grayscale used 4 duty-cycle levels, 25, 50, 75, and 100%, to achieve intermediate temperatures from 25 °C to 45 °C. The same platform patterned gallium by heating selected pixels to $G\cdot A_w\cdot P_s$1 °C for $G\cdot A_w\cdot P_s$2 s above a Peltier plate set to $G\cdot A_w\cdot P_s$3 °C, yielding 500 $G\cdot A_w\cdot P_s$4m feature size and line-edge roughness of approximately 50 $G\cdot A_w\cdot P_s$5m. Reported reliability exceeded $G\cdot A_w\cdot P_s$6 on/off cycles at 75 V and 100 Hz with less than 5% drift in resistance or $G\cdot A_w\cdot P_s$7, and device lifetime exceeded 100 h continuous operation at 45 °C (Goyal et al., 25 Feb 2026).

These microscale systems demonstrate two complementary meanings of digital heating: thermal gradients as actuation fields for moving matter, and densely programmable heat fields as pixelated thermal outputs. A plausible implication is that the distinction between “heating” and “thermal microactuation” becomes primarily architectural rather than categorical when the temperature field itself is digitally rendered.

5. Real-time thermal control in Digital Glass Forming

In Digital Glass Forming, digital heating is realized as closed-loop regulation of the work-zone temperature to keep the process within the glass’s working range. The reported real-time control system synchronizes process parameter, thermal camera, and visual camera data. The RT-Linux controller interfaces with an Optris PI 640i thermal camera at 125 Hz and 640×480 px in the 8–14 μm band via GigE Vision, a FLIR Oryx ORX-10G visual camera at up to 417 fps via 10 GigE Vision, Aerotech Automation1 iXC4 and PRO115SLE motion hardware via Ethernet/IP, and laser-power setpoint plus analog and digital I/O for the heater plate. Emissivity is set to $G\cdot A_w\cdot P_s$8, and work-zone temperature $G\cdot A_w\cdot P_s$9 is computed as the average of the 200 hottest pixels within the field of view, approximately $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$0. All streams are timestamped and buffered at 0.1 s periods (Tiwari et al., 31 Mar 2026).

The process model is first-order and incremental about the nominal operating point $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$1:

$$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$2

where $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$3 and $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$4. System identification yields the continuous-time transfer function

$$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$5

and a zero-order-hold discrete-time model at $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$6. The controller is a 2-degree-of-freedom polynomial tracking controller with desired closed-loop poles corresponding to time constants 0.1 s and 0.5356 s. Its practical role is direct: when the build heats up, such as at higher layers or corners, commanded laser power is automatically reduced; when heat is lost, commanded power is increased (Tiwari et al., 31 Mar 2026).

The experiments distinguish open-loop process maps from closed-loop regulation. For mapping at scan speed $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$7, filament diameter $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$8, and bed temperature 550 °C, the parameter grid spans $$Y_t = T_s(t) + \epsilon_t,\qquad \epsilon_t \sim N(0,\sigma_\epsilon^2).$$9 and distance from focus $p<0.05$0. The resulting map identifies under-heated and over-heated regions and a viable intermediate window, but the paper states that the map is static and does not account for changing thermal sinks such as wall building or filament deflection. In single-track tests at $p<0.05$1, open-loop $p<0.05$2 produced periodic filament detachment, whereas closed-loop control at $p<0.05$3 produced a continuous, uniform track with automatic power modulation of $p<0.05$4 around 70 W nominal. At $p<0.05$5, open-loop powers 10, 20, and 30 W all lay outside the static viable window, while closed-loop control at $p<0.05$6 gave stable deposition at average $p<0.05$7. In a 20 mm × 16-layer wall build with $p<0.05$8, $p<0.05$9, and interlayer $R$0, open-loop $R$1 failed at the 9th corner because corner temperatures climbed, whereas closed-loop control at $R$2 completed all 16 layers and progressively lowered average power from approximately 40 W to approximately 23 W (Tiwari et al., 31 Mar 2026).

This use case places digital heating in a manufacturing-control lineage rather than an energy-management lineage. Yet the architecture remains homologous to building and district cases: synchronized sensing, reduced-order modeling, and digitally updated control inputs.

6. Recurrent architectural patterns, limitations, and points of clarification

Across scales, digital-heating systems repeatedly combine layered data handling with physically grounded abstraction. The residential-building twin uses five layers from IoT acquisition to user interface, with grey-box SDEs and likelihood-ratio-based model selection. The district-heating workflow uses four layers from data acquisition to model assembly, with graph construction and hydraulic-thermal calculations. The microheater array uses row-column addressing, high-voltage switching, and time-division multiplexing to realize individually addressable thermal pixels. Digital Glass Forming synchronizes imaging and process variables under a closed-loop tracking controller (Morkunaite et al., 2024, Stock et al., 2024, Goyal et al., 25 Feb 2026, Tiwari et al., 31 Mar 2026).

Several misconceptions are directly contradicted by the cited work. First, digital heating is not synonymous with purely data-driven black-box prediction. The residential-building study explicitly argues that black-box forecasting models lack fundamental insights and hinder re-use, whereas the reported grey-box twin yields physically meaningful $R$3 parameters from only one week of high-frequency data. The district-heating workflow similarly embeds explicit hydraulic and thermal relations rather than treating the network as an opaque predictor. The Digital Glass Forming controller is also based on an identified transfer function and pole placement rather than on an unconstrained black-box learner (Morkunaite et al., 2024, Stock et al., 2024, Tiwari et al., 31 Mar 2026).

Second, digital heating does not imply unlimited spatial or temporal precision. In the Pt microheater array, full-array refresh rate is approximately 0.33 Hz, thermal diffusion limits resolution to approximately 4 pixels, and power distribution across shared rows can cause voltage droop. In district-heating modeling, absence of measured temperature and pressure data means that pipe roughness, insulation condition, and dynamic losses remain estimates. In heritage monitoring, the reported twin focuses on data-driven diagnosis rather than full finite-element or finite-difference thermal simulation. In droplet transport, the short original article does not provide the full quantitative characterization that would be needed for exact reproduction of heater geometry, waveforms, or calibrated thermal-stress maps (Goyal et al., 25 Feb 2026, Stock et al., 2024, Ni et al., 2024, Yakhshi-Tafti et al., 2010).

Third, digital heating is not confined to end-use heating in buildings. The term encompasses district-scale heat-supply infrastructures, microfluidic thermocapillary transport, high-density microheater arrays, and laser-driven glass processing. This suggests that the concept is best understood as a digitally organized thermal regime in which sensing, modeling, and actuation are co-designed around heat as the controlled variable.

The literature also indicates a common developmental trajectory. Building and district papers point toward real-time digital twins by adding SCADA or IoT telemetry, co-simulation environments, and optimization engines. The microheater-array paper points toward novel heat-controlled microactuation systems. The glass-forming paper extends static process maps into dynamically regulated operation. Taken together, these works define digital heating less as a single technology than as a research program: the systematic digitization of thermal state estimation, thermal decision support, and thermal actuation over domains where conventional white-box model tediousness or black-box opacity are both limiting factors (Morkunaite et al., 2024, Stock et al., 2024, Goyal et al., 25 Feb 2026).