Development and Software-in-the-Loop Validation of a Digital Twin Architecture for District Heating Networks

2026

Full text Open access: Gold Metadata (CSL-JSON)
DOI 10.3390/app162010206
Data confidence 70 medium
How this score is calculated

It is built from checkable properties of the record itself: whether the article has a DOI, how many independent sources confirmed its data, whether the required fields are filled in, and how recent the latest confirmation is. Disagreement between sources and a missing identifier lower it. A value of 80 or above means the record was published without further checking; 60 to 79 means it is published at reduced confidence, with a manual check advisable. A record verified by an editor by hand is never pushed below 90 by a recalculation. This scores our data about the article, not the article itself.

Abstract

In this study, a digital-twin-oriented integration architecture was developed for district heating networks in a laboratory Software-in-the-Loop (SIL) environment and evaluated. The implemented testbed combined a virtual SIMATIC S7-1500 controller executed in S7-PLCSIM Advanced V8.0, WinCC Runtime Advanced, OPC UA communication, a Python-based integration layer, and a Fluidit Heat thermohydraulic model. The physical district heating network, field sensors, pumps, actuators, and an operational field PLC were not connected to the experimental loop. Field-derived heat load and pressure values for five monitored consumers were stored in PLC data blocks. Python validated and mapped the tags, initiated predefined Fluidit Heat scenarios, processed the model outputs, and returned the results to the PLC for SCADA visualization. Six operating scenarios were evaluated. In the combined baseline and 120% demand scenarios, the delivered heat increased from 2369.84 to 2843.79 kW, plant thermal output from 2377.14 to 2850.80 kW, and plant flow from 12.288 to 14.737 L/s. The maximum supply velocity increased from 1.192 to 1.430 m/s, and the maximum unit pressure loss increased from 1.338 to 1.912 bar/km (+42.92%). The minimum consumer differential pressure remained at approximately 4.000 bar, above the adopted 3.5 bar criterion, and no heat deficit was calculated. The experiment demonstrated functional software interoperability, event-driven scenario execution, and bidirectional simulation data exchange. Because the baseline values contributed to model parameterization and the physical network was not connected, the comparison was a consistency assessment rather than independent field validation. Automatic optimization, autonomous preferred-mode selection, and actuator-level control were not implemented.