Real-Time Digital Twins for Building Energy Optimization Through Blind Control: Functional Mock-Up Units, Docker Container-Based Simulation, and Surrogate Models

Abstract

The transition toward energy-efficient and smart buildings requires Digital Twins (DTs) that can couple real-time data with physics-based Building Energy Models (BEMs) for predictive and adaptive operation. Yet, despite rapid digitalisation, there remains a lack of practical guidance and real-world implementations demonstrating how calibrated BEMs can be effectively integrated into Building Management Systems (BMSs). This study addresses that gap by presenting a complete and reproducible end-to-end framework for embedding physics-based BEMs into operational DTs using two setups: (i) encapsulation as Functional Mock-up Units (FMUs) and (ii) containerisation via Docker. Both approaches were deployed and tested in a real educational building in Cáceres (Spain), equipped with a LoRaWAN-based sensing and actuation infrastructure. A systematic comparison highlights their respective trade-offs: FMUs offer faster execution but limited weather inputs and higher implementation effort, whereas Docker-based workflows provide full portability, scalability, and native interoperability with Internet of Things (IoT) and BMS architectures. To enable real-time operation, a surrogate modelling framework was embedded within the Docker architecture to replicate the optimisation logic of the calibrated BEM and generate predictive blind control schedules in milliseconds—bypassing simulation overhead and enabling continuous actuation. The combined Docker + surrogate setup achieved 10–15% heating energy savings during winter operation without any HVAC retrofit. Beyond the case study, this work provides a step-by-step, in-depth guideline for practitioners to integrate calibrated BEMs into real-time control loops using existing toolchains. The proposed approach demonstrates how hybrid physics- and data-driven DTs can transform building management into a scalable, energy-efficient, and operationally deployable reality.

1. Introduction

As concern over climate change and energy scarcity grows, the building sector—responsible for roughly 30–40% of global energy use and 26–36% of energy-related greenhouse gas emissions [1,2], largely from heating, ventilation and air conditioning (HVAC), lighting, and hot water [3]—must improve efficiency. In response, policies such as Directive (EU) 2024/1275 [1] set stricter frameworks to cut consumption and emissions, requiring all new buildings to reach nearly zero energy building (nZEB) standards by 2025 through high efficiency and renewable energy integration.

To achieve sustainable buildings, energy modelling has become a standard practice for optimising performance throughout the design phase [4]. Building Energy Models (BEMs) enable prediction of consumption, system optimisation, and evaluation of energy management strategies, reducing operational costs. According to IPMVP, ASHRAE, and CIBSE, BEMs are categorised as white-, black-, or grey-box models depending on the degree of physical principles they incorporate [5,6,7,8].

A major advancement in this field is the integration of BEMs with their physical counterparts through Digital Twins (DTs)—virtual replicas that mirror the building’s geometry, systems, and real-time operating conditions [9,10]. By linking BEMs to actual sensor data, DTs enable continuous monitoring, predictive analytics, and the optimisation of energy performance [11]. To achieve this, models must be encapsulated for seamless simulation and feedback with the operational building. The Functional Mock-up Interface (FMI) standard enables such interoperability via Functional Mock-up Units (FMUs), while Docker-based containerisation provides an alternative solution offering portability, scalability, and simplified integration across diverse computing environments.

A review of the literature reveals the use of FMUs in the packaging of partial or total models of buildings. In this context, partial models are utilised to simulate specific parts or systems of a building, with the simulation being conducted in co-simulation mode in conjunction with another program. Examples of partial simulation of HVAC systems can be found in [12,13], where Modelica and Dymola, respectively, were employed for system modelling. Other works encapsulate BEMs generated from EnergyPlus for co-simulation in software such as Dymola or CONTAM [14,15]. In contrast, other studies propose different approaches by generating FMUs from EnergyPlus BEMs to implement hardware-in-the-loop strategies with a laboratory heat pump, simulating through Python libraries [16].

In parallel with FMU-based encapsulation, Docker has become a lightweight and portable solution for deploying energy simulation tools such as EnergyPlus or OpenStudio within isolated containers [17,18]. This ensures consistent execution across local, cloud, and edge platforms, enabling scalable and reproducible DT architectures for parametric analysis, predictive control, and performance monitoring. Its modular design also allows independent deployment of services such as data ingestion or visualisation.

However, both FMU- and Docker-based approaches still rely on running full EnergyPlus simulations, which introduces non-negligible computational overhead and complicates their continuous use in real building operation. This limitation is especially relevant when DTs are expected to provide rapid responses to short-term weather fluctuations or to operate in resource-constrained environments, such as Building Management Systems (BMS) with limited hardware. To address this bottleneck, data-driven models can be employed to enable faster, real-time responsiveness [19]. Machine-learning (ML) methods such as Random Forests, gradient-boosted models or—computationally heavier—multilayer perceptrons have been widely applied in building prediction tasks. In this work, however, we train data-driven models on a highly calibrated BEM rather than directly on measured data, yielding physics-informed surrogate models that enhance robustness and interpretability for DT integration [20,21].

In recent years, the use of surrogate models has emerged as a prominent trend in the application of ML models to BEMs, enabling fast and accurate approximations of complex simulation results while drastically reducing computational demand. Reviews of the literature emphasise that these models are essential when DTs must react to rapid environmental changes or operate within hardware-constrained systems, thus supporting real-time control, scalability, and reduced operational costs [22,23,24]. Several studies have shown that surrogate models, once trained, can produce accurate predictions in seconds, as opposed to the minutes or hours required for full EnergyPlus simulations, maintaining errors below 5% across multiple relevant outputs [25]. Furthermore, surrogate models such as Random Forest, XGBoost, and multilayer perceptrons have achieved values of the coefficient of determination (R²) above 0.9 while offering 200–340 times faster inference speeds compared to physical simulations [26,27,28,29].

Establishing a connection between buildings and DTs involves the coordinated interaction of several layers. BIM models provide the geometric and semantic description of the built asset, serving as the foundation upon which physics-based BEMs are constructed. IoT sensors and actuators, orchestrated through a BMS, supply the real-time and historical thermal and occupancy data required for accurate DT simulations [30,31]. However, integrating these heterogeneous components presents significant challenges: BEM–BMS communication often suffers from system failures, software incompatibilities, and manufacturer-driven fragmentation leading to non-interoperable systems [11,32,33]. These issues are compounded by data discrepancies arising from sensor noise, asynchronous sampling rates, packet loss, and inconsistencies between BIM metadata and the measurements captured by IoT devices [34,35]. Such misalignments can propagate into the DT and compromise the reliability of real-time optimisation under dynamic building conditions [36,37].

In this context, this work aims to bridge this gap by proposing and comparing two alternative approaches for integrating BEMs into BMS to implement energy-saving strategies. To achieve this, two DTs were developed using different technologies. The first is an FMU, created from an EnergyPlus BEM and augmented with an External Interface to enable data exchange. The second is a containerised EnergyPlus simulation, employing Docker to run simulations within an isolated environment. The paper details the real-time implementation of both approaches within an educational building, highlighting the differences observed in their implementation, simulation behaviour, and results. In both cases, the DTs were supplied with data from LoRa environmental sensors installed within the building, in conjunction with meteorological data downloaded from an external provider. Furthermore, the simulations were complemented by the incorporation of predictive meteorological data for the subsequent days. It should be noted that the experiments and tests were conducted during the winter months.

In particular, the study focuses on optimising blind operation during non-operational periods as an energy-saving strategy, supported by data-driven surrogate models that enable fast, containerised, end-to-end computation of optimal set-points. Dynamic control of blinds allows the building to harness passive solar gains when beneficial—such as pre-heating indoor spaces in winter—while avoiding excessive heat losses or overheating. This approach reduces heating demand without requiring any physical intervention in HVAC systems and can therefore be readily implemented in existing buildings. Although the analysis of the results and its effectiveness is beyond the scope of the present work and has been elaborated in another study [38], a brief discussion is provided in this paper.

Beyond the case study, this paper contributes a practical, reproducible guide to the containerisation of EnergyPlus BEMs for direct DT–to–BMS integration, addressing a frequently noted but weakly documented step in the DT pipeline: packaging, orchestrating, and operating BEM simulations as portable services suitable for building control. In addition, the proposed workflow incorporates a lightweight yet robust data-handling layer that ensures temporal alignment and data consistency prior to simulation. Furthermore, the surrogate models employed in this study introduce an additional operational advantage: by executing directly on the project host and relying solely on the most recent validated sensor inputs, they reduce sensitivity to short-term data irregularities and enable robust, low-latency decision-making within the DT architecture.

This document is organised as follows. Section 2 presents the general motivation of the present investigation and the materials used in this work, which involve the case study building, its IoT architecture, and data processing steps. Section 3 describes the methodology followed in this work, encompassing the development of FMU- and Docker-based DTs, the surrogate modelling framework for blind control optimisation, and the implementation workflow. Section 4 shows a comparison between implementation approaches together with the results obtained from surrogate modelling and the energy-saving strategy. Finally, Section 5 provides a comparative discussion of the different methods and results, and the main findings are summarised in Section 6.

2. Materials

This section provides a comprehensive overview that sets the foundation for the present work. It begins by outlining the motivation behind the study, followed by a detailed description of the building for which the DTs were designed, and an explanation of the data processing steps that were taken to prepare the necessary data for simulation.

2.1. General Motivation

The objective of the case study presented in this work was the application of a blind raising/lowering schedule during non-operational days of a building to take advantage of solar energy gains. This approach aimed to prevent excessive temperature decline in specific rooms, thereby reducing heating energy demand on the following working day.

To achieve this objective, two DTs were developed and implemented in a real case scenario, incorporating simulations of both open and closed blinds. The simulation outcomes were compared, resulting in the creation of an optimised schedule that was subsequently applied during the non-operational periods of the building, that is, when it was unoccupied. Consequently, visual comfort aspects, such as daylight availability, glare risk, or electric lighting needs, did not constrain blind operation during the experiments, as the building was unoccupied and no lighting requirements had to be met. More details regarding the energy-saving strategy and the assessment of its performance can be found in [38].

Consequently, the DTs had to be simulated using both historical and predictive data. Initially, historical data established the building’s thermal history, aiding the pre-heating process. Conversely, weather forecast data for non-operational days were employed to evaluate the optimised blind schedule under predicted conditions. A crucial requirement was also maintaining the real-time connectivity between the DTs and the building, enabling them to read both indoor and outdoor environmental sensors’ data as well as the blind schedules of the selected test rooms.

As already mentioned, two deployment approaches and, consequently, two different DT implementations were compared: (1) an FMU-based model and (2) a containerised simulation using Docker. Beyond these physics-based setups, a surrogate model was also introduced as a lightweight, data-driven alternative built upon the same calibrated BEM and designed to support the same energy-saving strategy.

2.2. Pilot Building

This section describes the pilot building for which the DTs were developed, an educational building at the University of Extremadura, providing a detailed description that encompasses its BEM modelling and the IoT architecture of its sensor systems and databases.

2.2.1. Building Description, Energy Modelling and Calibration

The Computer Science Pavilion at the School of Technology of Cáceres (EPCC), one of three similar buildings within the six-building campus (marked with red colour in Figure 1), is the focus of this study. Although the figure depicts several buildings on the campus, the case study concerns exclusively the pavilion where all experiments were conducted. This building operates independently from the others and has no physical or operational connection with them. The pavilion features a central hall with classrooms, laboratories, and offices on two floors, many of which are equipped with controllable blinds that allow dynamic daylight and solar gain management—an aspect that constitutes the main focus of this work. The HVAC system uses boilers for heating via radiators, while cooling is limited to individual air conditioning (AC) units in some rooms. Similarly to the study developed by Guerrero et al. [38], the present work focuses on four upper-floor rooms—PA:023, PA:024, PA:029, and PA:031—which share similar size, orientation, and blind control capabilities.

For this work, an existing “as-built” Building Information Model (BIM) provided the basis for defining the building’s architecture, materials, and construction details. This information was used to develop a BEM in accordance with Option D of the IPMVP [5], which corresponds to a white-box modelling approach. The building volume was modelled using DesignBuilder and then exported to the EnergyPlus format for further adjustment.

Recognising previous findings that highlight the discrepancy between BEM outputs and actual building performance [40], the model was calibrated by tuning model parameters based on measured indoor temperature data from two datasets collected in 2024, each with 10-min intervals, encompassing both the training and checking periods [41]. The calibrated parameters and sub-parameters were the same as Model A indicated in [38], which are: Zone Capacitance Multiplier (temperature capacity multiplier), Window Material (U-Factor), Internal Mass (surface area, thickness, conductivity, density, specific heat, and thermal and solar absorptance), Envelope properties (conductivity, density, specific heat, and thermal and solar absorptance), Zone Infiltration (effective air leakage area, stack coefficient, and wind coefficient), and Zone Mixing (design flow rate). The calibration metrics obtained for rooms PA:023, PA:024, PA:029, and PA:031 during training (May to July 2024) and checking (December 2024) periods were as follows: the Mean Absolute Error (MAE) ranged from 0.42 to 0.70 during the training period and from 0.59 to 0.69 during the checking period; the Root Mean Square Error (RMSE) ranged from 0.52 to 1.01 during the training period and from 0.65 to 0.73 during the checking period; and R² varied between 95.26% and 98.96% in the training period and between 95.41% and 99.20% in the checking period. Further details on the calibration procedure can be found in [38,42], as this process is not the primary focus of the present study.

2.2.2. IoT Architecture

The IT infrastructure at the EPCC, detailed in [43] and depicted in Figure 2, employs a three-tiered architecture: a front-end for data acquisition (comprising various sensors across the building), a service bus for overseeing service execution and managing communication protocols, and a back-end dedicated to data reception and storage.

The EPCC hosts two virtual machines (VMs). One VM manages core system services, including ChirpStack [44], Docker [45], and Message Queuing Telemetry Transport (MQTT), which is the communication protocol utilised by all sensor types. Docker containers on this VM execute scripts for receiving, processing, and storing sensor data within the database, making its operational status critical for the entire BMS. The second VM hosts an InfluxDB database [46], serving as the repository for the dynamic sensor measurements. Secure access to both the Microservices and Database VMs is provided via SecureShell (SSH) connections through a terminal.

Since 2013, the EPCC building has been progressively equipped with various sensors and actuators, initially as part of the SmartPolitech project [47]. This instrumentation includes environmental, electricity consumption, window opening, and gas consumption sensors, alongside radiator and blind actuators [43,48]. Among these, the environmental sensors and blind actuators are of particular relevance, as they are the ones employed in the present study. Concerning communication protocols, the data from these devices is transmitted using either WiFi or LoRaWAN.

This study utilised LoRaWAN indoor environmental sensors to capture the building’s thermal history. Located across various thermal zones within the Computer Science Pavilion, these sensors record temperature, relative humidity, and CO₂ measurements. Additionally, historical opening/closing schedules of the blinds, communicated via WiFi, were incorporated to further define the thermal history. Technical information regarding the sensors and actuators used in this work is displayed in

Table 1. Technical specifications of the sensors/actuators installed in the EPCC and used in this work. Based on [43,48].

Type of Sensor	Parameter	Communication	Sampling Interval	Actuation
Environmental sensor	Temperature	LoRaWAN	15′	–
	Humidity
	CO2
Blind actuator	Blind state opening	WiFi	5′	Mosquitto (MQTT)

.

It should be noted that, while the environmental sensor provides measurements of temperature, humidity, and CO₂, only temperature readings are utilised in the present work. The accuracy and precision of these sensors are inherently limited; CO₂ sensors, in particular, can exhibit drift over time and require periodic calibration to maintain reliability. Humidity measurements may also be influenced by environmental conditions such as condensation or rapid fluctuations in temperature, potentially introducing noise into the data. Additionally, the sampling intervals (15 min for environmental parameters and 5 min for blind actuation) may limit the temporal resolution of dynamic changes, especially for rapidly varying conditions. These factors should be considered when interpreting the sensor data and its potential impact on system performance.

2.3. Data Processing

To perform the DT simulation, it was essential to integrate environmental data from both indoor and outdoor conditions, including the test and adjacent rooms. Schedules for blind operation, HVAC ideal loads, and air infiltration were also included. Historical data from the preceding 15 days were used to define the building’s thermal history, whereas forecast data covered the simulation period during which the optimised blind schedule was applied. As an example, when the simulation commenced on a Friday to account for a weekend schedule, the forecast extended over the subsequent three days, resulting in a total simulation period of 18 days.

In summary, the input data supplied to the DTs, along with their forecast estimations, were as follows:

• Outdoor environmental data included all relevant weather variables from a nearby station, with emphasis on solar radiation to improve simulation accuracy, though some limitations remained and the variables differed between the two DT approaches, as discussed later in this work. Both historical and forecast data at hourly resolution were retrieved from Open-Meteo’s Historical Weather and Weather Forecast application programming interfaces (APIs) [49] using a Python (version 3.11) command provided in their website, with the download parameters summarised in

  Table 2. Request parameters to download weather data from Open-Meteo APIs.

  Historical Weather Data		Forecast Weather Data
  Start date	14 days before	Past days	1
  End date	2 days before	Forecast days	4 *
  Common parameters
  Latitude	39.4765	Wind speed unit	m/s
  Longitude	−6.3722	Time zone	GMT+1

  * When sending the request to the API, the present day is included in this counter.

  . To complete the weather data, the “Horizontal Infrared Radiation Intensity” ($I{R}_H$) variable was calculated as detailed in the EnergyPlus documentation [50] and in Appendix A, as it could not be downloaded from the API.
• Indoor environmental data included temperature measurements from the test and adjacent rooms obtained through indoor sensors. The historical data was downloaded in CSV format from the building’s BMS through an SSH connection to the VM database accessing the “sensors” database within InfluxDB. Concerning the forecast data, it was estimated as an average of the preceding five days.
• Blind opening/closing schedules of the test rooms were determined by blinds actuators. Historical blind schedules were retrieved following the same procedure used for the indoor environmental data. For the forecast schedules, two scenarios were simulated to assess the energy-saving strategy: blinds fully open and blinds fully closed.
• Activation schedules of ideal loads were defined based on the experiments. The system was activated continuously during the historical days, allowing the model to adapt to the environmental conditions and follow as closely as possible the thermal history of the real building. During the test period, corresponding to forecasted unoccupied days, the Ideal Loads were switched off enabling the model to enter a free oscillation state.
• Schedules of infiltrations were modelled using the Effective Leakage Area (ELA) method.

Concerning the output data, the indoor simulated environmental data (temperature and humidity) as well as the heating/cooling and solar gain/loss consumptions of each of the test rooms were extracted as outputs of the DTs.

Historical outdoor and indoor environmental data were processed using a two-step methodology. First, the data were resampled with linear interpolation to align with the simulation timestep. Next, they were checked and cleaned by removing out-of-range values and filling gaps resulting from sensor failures or the resampling process, following the criteria described below:

• Gap shorter than 18 timesteps: filled by linear interpolation.
• Gap longer than 18 timesteps: filled using the arithmetic mean of the corresponding time points over the previous five days.

Finally, the processing of historical open/close schedules of the blinds was done similarly to the indoor environmental data; however, the gap-filling approach differed slightly, as missing values were replaced with the previous blind state, regardless of the gap length.

It should be pointed out that, although these gap-filling rules were defined to ensure consistent data preprocessing, experiments containing extensive or prolonged gaps were discarded from the analysis. The final simulations were performed only with datasets that did not require filling long missing periods.

3. Methods

This section describes the methodological workflow followed to develop, deploy, and test the DTs used in this study. The process begins with the generation of a calibrated BEM and its encapsulation through two complementary integration approaches: FMUs and Docker-based containerisation. Both methods enable direct coupling of the BEM with real building data for simulation and control. In addition, a ML–based surrogate framework was implemented to reproduce the behaviour of the calibrated model and a rule-based (RB) optimisation module with significantly lower computational effort. These surrogates were specifically applied to optimise blind operation during non-operational periods, aiming to maximise passive solar gains and reduce heating demand. The following subsections detail the procedures for FMU creation, containerised simulation, surrogate model training, and the practical implementation of each DT in the case study building.

3.1. Generating an FMU from EnergyPlus

In order to create an FMU from an EnergyPlus (version 8.7) model, the “EnergyPlusToFMU” toolbox must be used. Developed in Python (version 3.11), this software package enables users to export building simulations from EnergyPlus (version 8.0 or higher) as FMUs for co-simulation, compliant with FMI standards 1.0 and 2.0. These FMUs can then be imported into various simulation programs supporting FMI co-simulation [51]. An External Interface object must be added to the EnergyPlus IDF (Input Data File) file in order to be able to create the FMU.

The steps undertaken in this work to create an FMU using this tool and to prepare the corresponding files, as illustrated in Figure 3, were as follows (further details are provided in Appendix B).

• BEM file: a BEM in EnergyPlus, taken as a basis what is indicated in Section 3.1, was prepared for “EnergyPlusToFMU” toolbox. This involved implementing the FunctionalMockupUnitExport External Interface and defining inputs and outputs (I/O) in the IDF file.
• Input Data Dictionary (IDD) file: this file specifies the syntax and data structure of all input objects used in EnergyPlus simulations. It defines object classes, fields, measurement units, and descriptive comments specific to each EnergyPlus version, serving as a reference for creating and validating IDF models. In this study, the file was obtained from EnergyPlus version 9.4.
• Weather file in EPW format (optional): it involved preparing the weather data file for a whole year in hourly sampling. All variables may be included in the file, however, this step is optional and the FMU can be created without specifying it. It is important to note that the use of a weather file in this step may affect the FMU simulation results to some extent. In this work, an EPW file of 2023 weather data was used to create the FMU.

Once all the necessary files are prepared, the FMU can be generated using a Python command specified in Appendix B [51].

Concerning the FMU’s I/O, the variables that can be defined as such are detailed in the EnergyPlus documentation [50]. Regarding outputs, EnergyPlus allows a wide range of model variables to be defined and selected as FMU outputs, depending on the intended purpose of the FMU. The External Interface provides one object for defining outputs, called From:Variable. In contrast, FMU inputs are more limited, restricted to EnergyPlus actuators, schedules, or variables. An important note is that only seven weather variables from the EPW file can be overridden and thus defined as actuators and FMU inputs: outdoor dry bulb temperature, outdoor relative humidity, outdoor dew point, wind speed and direction, and direct and diffuse solar radiation. This limitation in weather actuators can affect the BEM’s results and represents a disadvantage of the FMU approach. To define FMU inputs, the External Interface provides three objects, named as To:Schedule, To:Actuator, and To:Variable, corresponding to schedules, actuators, and variables, respectively.

Table 3. Inputs and outputs of the DTs.

Inputs
Schedules 1	Weather Data 2
	Docker-Based DT (EPW File)	FMU-Based DT (Actuators)
Sensor indoor temperature	Dry Bulb Temperature	Outdoor Dry Bulb
Blinds schedules	Relative Humidity	Outdoor Relative Humidity
Ideal loads schedules	Dew Point Temperature	Outdoor Dew Point
ELA infiltration schedules	Precipitable Water
	Wind Speed	Wind Speed
	Wind Direction	Wind Direction
	Global Horizontal Radiation
	Direct Normal Radiation	Direct Solar
	Diffuse Horizontal Radiation	Diffuse Solar
	Horizontal Infrared Radiation Intensity
	Atmospheric Station Pressure
	Liquid Precipitation Depth
Outputs 3
Zone Mean Air Temperature	Zone Ideal Loads Supply Air Total Heating Energy	Zone Windows Total Heat Gain Energy
Zone Air Relative Humidity	Zone Ideal Loads Supply Air Total Cooling Energy	Zone Windows Total Heat Loss Energy

¹ FMU: To:Schedule object from External Interface; Container: Schedule input in IDF. Schedules are similar for both  DTs. ² FMU: To:Actuator object from External Interface; Container: EPW file. Weather data differs for both DTs. ³ FMU: From:Variable object from External Interface; Container: Variable output in IDF. Outputs are similar for both DTs.

summarises the FMU’s I/O considered for this case study. The FMU inputs were limited to schedules and actuators; therefore, only the To:Schedule and To:Actuator objects of the External Interface were used. The outputs, in turn, were defined using the dedicated From:Variable object.

3.2. DT Based on Docker Container

A Docker container not only allows for the launch of EnergyPlus simulations within an isolated environment but also creates a highly portable, consistent, and reproducible simulation platform. Because the container packages EnergyPlus and all its dependencies, it ensures simulations run identically across different systems, from development to deployment. This isolation also simplifies setup and prevents conflicts with other software on the host machine. Furthermore, the container’s lightweight nature means it can be easily shared, scaled, and integrated into automated workflows, enabling efficient and reliable energy modelling at scale.

It is possible to launch an EnergyPlus simulation within a container by utilising the EnergyPlus Python API, which requires the same files as for simulating with EnergyPlus: (1) a BEM model in IDF format; (2) weather data in EPW format; and (3) other files needed for the simulation, such as historical environmental data or machine schedules, which can be saved in any format read by EnergyPlus. These files are accessed via Python code, which reads them and runs the EnergyPlus simulation in the container.

In this work, two Docker containers have been developed to perform two interconnected services to manage EnergyPlus simulations, as seen in Figure 4. The main features of this architecture include:

• Simulation management, enabling job creation, deletion, and general oversight.
• Real-time display of simulation results, with the capability to retrieve data for selected output variables and simulation zones.
• Download of results as a ZIP file upon simulation completion.

On the one hand, the FRONTEND service exposes a JavaScript-based frontend along with a REDIS REDIS: https://redis.io/docs/latest/ (accessed on 16 April 2025) queue for launching and managing simulation jobs. On the other hand, the WORKER is responsible for executing the simulations as it integrates EnergyPlus in the container. Both services and their submodules are interconnected using REDIS as a database and Python with RQ RQ: https://python-rq.org/docs/ (accessed on 16 April 2025) to manage the job queue, as seen in Figure 4.

Finally, the user interacts with the services via either a Rest API or a web interface. This is performed using the required simulation files and transmitting all data to a local server via a HyperText Transfer Protocol (HTTP) POST request. Subsequently, a Python script automates the process of downloading and unzipping the simulation results to a local folder, then deleting the simulation from the server to optimise resource allocation.

For this work, the BEM used as a basis for containerised EnergyPlus simulations was that detailed in Section 2.2.1. The inputs pertaining to indoor temperatures, blinds, HVAC, and infiltrations were designated as schedules in the IDF, while the outputs of the DT were defined as variables in the IDF. The weather data was incorporated into the simulation by means of the EPW file; therefore, it was not necessary to add these variables as inputs inside the IDF. In summary, the BEM I/O are listed in Table 3.

While Docker supports explicit memory and CPU limits for container isolation, these options were deliberately left unused to maintain methodological symmetry with the FMU-based setup. Applying resource throttling would have biased runtime measurements and hindered a like-for-like comparison. By running both DT implementations under identical, unrestricted hardware conditions, the analysis captures intrinsic differences in execution behaviour rather than artefacts of container-level resource management.

3.3. Integration of Online Rule-Based Blind Control

Beyond the FMU- and Docker-based implementations described above, we introduce a ML-based approach creating a surrogate model to accelerate the decision process for blind operation within the DT structure. Unlike prior work by the authors (where surrogate models directly generated optimal HVAC temperature set-points [24]), the objective here is to predict binary blind states (0 = closed, 1 = open) at each timestep. These schedules are designed to maximise passive solar heat gains during non-operational periods while avoiding excessive losses, following a RB control strategy previously implemented with a calibrated physics-based BEM [38]. Training data are obtained by coupling the BEM with the RB optimiser to produce an optimised blind schedule. Inputs include exogenous weather variables (dry-bulb temperature, relative humidity, atmospheric pressure, direct and diffuse solar radiation, wind direction and speed, and precipitation), timestamp encodings, and actual monitored indoor air temperature. The output comprises the optimised 0/1 position per thermal zone and timestep.

Building on this formulation, we compare two surrogate schemes that trade off simplicity, interpretability, and robustness. The stand-alone (end-to-end) method learns the direct mapping from inputs to the zone-wise binary schedule, yielding 0/1 trajectories in a single inference step with minimal latency and implementation effort. The two-step regression method first approximates key BEM-derived results that drive the RB logic (e.g., window heat gains/losses), and then feeds these estimated physical features into a surrogate optimiser to obtain the final 0/1 schedule. While the stand-alone model prioritises computational efficiency, the two-step scheme preserves physical interpretability and may be more robust under distribution shifts.

From an implementation standpoint, previous to this study, the pure Docker-based workflow for blind optimisation required downloading simulation outputs (e.g., CSV results files) from the container to a client, post-processing them to derive the schedule, and then uploading the resulting timetable back to the platform for actuation. In contrast, the surrogates can be serialised as a lightweight .pkl file and executed in situ within the same Docker worker that runs the DT, computing the optimised 0/1 schedules directly without intermediate transfers or manual interference required. This eliminates I/O overhead and round-trips, reduces end-to-end latency, simplifies operations, and enables (near) real-time BMS/MQTT actuation while retaining the robust control intent of the physics-based strategy at a fraction of the computational cost.

3.3.1. Original Blind Control Optimisation (Physics-Based, Rule-Based)

The original RB optimisation method computes optimal open/close schedules for window blinds to harvest passive solar gains during non-operational periods (e.g., weekends), thereby reducing heating demand at the next start-up (e.g., Monday morning). The strategy relies on a calibrated physics-based BEM that reproduces the building’s thermal response with high fidelity, using recent indoor measurements to reconstruct the thermal history and short-term weather forecasts to project conditions over the optimisation horizon. Blind position also affects modelled infiltration (different leakage states when blinds are open/closed), so both radiative and infiltration-related effects are consistently captured within the same simulation framework.

At each timestep, the BEM predicts zone temperatures and window heat gains/losses for alternative blind states. A transparent RB controller selects the action according to:

• Gain-seeking rule: open when the predicted net window heat gain is positive and the zone temperature remains below an upper comfort/operational bound.
• Loss-avoidance rule: close otherwise to limit nocturnal/overcast losses or to mitigate excessive temperature rise.
• Stability safeguards: enforce minimum dwell time, apply hysteresis bands on temperature and gains, and impose time-of-day constraints to avoid chattering and ensure compliance with occupancy policies.

Facade orientation, external shading from surrounding buildings, and inter-zone interactions are implicitly accounted for by the BEM geometry and radiative model; the rules act on predicted gains/losses and temperature trajectories rather than raw irradiance alone.

The end-to-end procedure is:

• Thermal history: ingest recent indoor measurements (and baseline blind operation) to initialise the BEM state.
• Forecast-driven simulation: run the calibrated BEM forward over the non-operational horizon under the rule set, evaluating candidate blind actions.
• Schedule synthesis: assemble a binary timetable per zone and timestep ($0=\mathrm{closed}$, $1=\mathrm{open}$), enforcing dwell-time and policy constraints.
• Export and actuation: write the final schedule (e.g., CSV) and dispatch it to the BMS (e.g., via MQTT) for automated execution.

This physics-based, rule-driven optimisation provides interpretable decisions, leverages the calibrated model to account for site-specific phenomena (shading, envelope, infiltration), and yields measurable reductions in start-up heating demand. By exploiting weekend solar gains where beneficial and preventing excessive losses otherwise, the method reduces grid demand and improves operational efficiency without modifying the HVAC plant. The resulting zone-wise 0/1 schedules are directly actionable within the DT workflow and compatible with both FMU- and Docker-based deployments.

3.3.2. Stand-Alone vs. Two-Step Methods for Optimisation Surrogation

Building on our previous study on ensemble surrogate modelling, the general procedure for creating surrogates followed the same pipeline: coupling the calibrated BEM with the RB controller to generate labelled schedules, assembling features from weather, timestamps, and recent indoor conditions, and adopting temporally robust splits to avoid leakage and ensure operational validity [24]. Within this framework, we consider two complementary variants—stand-alone and two-step—summarised below.

Let ${\mathbf{x}}_t$ denote the input feature vector at timestep t (weather, timestamp, recent indoor air conditions), and let ${\mathbf{w}}_t\in {\{0,1\}}^Z$ be the zone-wise blind state (0 = closed, 1 = open) for Z zones. The goal is to produce a daily sequence ${\left\{{\mathbf{w}}_t\right\}}_{t=0}^T$ that maximises passive solar gains during non-operational periods while avoiding excessive losses, following the same control intent as the physics-based rule set.

The stand-alone approach learns a direct mapping

$$\begin{array}{c}\hfill f_{\theta }:{\mathbf{x}}_t\mapsto {\widehat{\mathbf{w}}}_t\end{array}$$

using a multi-output regressor. It outputs the 0/1 schedule per zone in a single inference (see schematic in Figure 5). This design minimises latency and engineering complexity, and is therefore suitable for real-time deployment and edge computing scenarios. Inference is fast (sub-second for a full day on commodity CPUs), and the model can be serialised as a compact .pkl file.

The two-step approach first emulates key BEM-derived quantities that drive the RB logic,

$$\begin{array}{cc}\hfill g_{\varphi }:{\mathbf{x}}_t& \mapsto {\widehat{\mathbf{z}}}_t,\hfill \end{array}$$

$$\begin{array}{cc}\hfill {\widehat{\mathbf{z}}}_t& =\{\widehat{\mathrm{Open}\mathrm{Window}\mathrm{Heat}\mathrm{Gain}},\widehat{\mathrm{Open}\mathrm{Window}\mathrm{Heat}\mathrm{Loss}},\hfill \\ & \widehat{\mathrm{Closed}\mathrm{Window}\mathrm{Heat}\mathrm{Gain}},\widehat{\mathrm{Closed}\mathrm{Window}\mathrm{Heat}\mathrm{Loss}}\}\hfill \end{array}$$

Secondly in the two-step approach, the original RB optimiser described in Section 3.3.1 is replaced with a light regressor $h_{\psi }\left({\widehat{\mathbf{z}}}_t\right)$ trained to mimic the rules, which removes the rules engine from the online path while retaining the physics-informed features. See schematic of the two-step approach in Figure 6.

$$\begin{array}{cc}\hfill h_{\psi }:{\mathbf{x}}_t& \mapsto {\widehat{\mathbf{z}}}_t,\hfill \end{array}$$

This preserves physical interpretability and direct compatibility with the existing control logic; updates to rules or thresholds are immediately reflected without retraining $g_{\varphi }$.

Both schemes are trained on labels generated by the calibrated BEM coupled to the RB optimiser (Section 3.3.1): $\{{\mathbf{x}}_t,{\mathbf{w}}_t\}$. To avoid leakage, we adopt time-series splits (e.g., expanding-window CV). We report accuracy together with training and inference runtimes. For the two-step method we additionally report regression errors for ${\widehat{\mathbf{z}}}_t$, such as RMSE or MAE, to ensure that intermediate physics proxies remain within acceptable error bands.

In the current Docker workflow, blind optimisation requires downloading simulation outputs from the container, post-processing them client-side to derive the schedule, and uploading the final timetable back to the platform for actuation. With either surrogate, the model can be shipped as a .pkl and executed in situ within the same Docker worker that runs the DT, computing the zone-wise 0/1 schedules directly and eliminating intermediate transfers.

3.4. Implementation Workflow of the DTs

The steps taken to implement the DTs in the case study are shown in Figure 7. The initial step entailed the download and processing of the input data required for the models, as already detailed in Section 2.3. Then, the DTs were simulated and, once the results were obtained, the energy-saving strategy was evaluated, obtaining optimised blinds schedules that were sent to the BMS to act on the blinds. The subsequent sections provide a detailed description of these last three steps.

3.4.1. Simulation of the DTs

FMUs can be executed by a variety of software as long as they comply with the FMI standard [52], acting as the master to orchestrate the simulation and run EnergyPlus as a slave. While Modelica and Dymola are common choices in the literature for modelling partial building systems [12,13], Python libraries also exist for simulating EnergyPlus FMUs [16]. However, at the time of this work, these Python libraries were outdated and no longer in use. Moreover, compatibility issues with other Python libraries prevented the simulations from running in this software.

Therefore, in the search for more robust alternatives, the simulations were carried out in MATLAB^®/Simulink^® (version 2025b). This platform offers a dedicated FMI block that supports FMI versions 1.0, 2.0, and 3.0 [53], which automatically detects whether an FMU is for co-simulation or model exchange and configures the corresponding I/O ports. MATLAB^®/Simulink^® was selected for FMU simulation due to its stability, active support, and ability to handle both input and output processing within a single environment, ensuring a reliable and reproducible workflow for EnergyPlus integration.

On another note, the Docker-based DT was simulated within a Python environment specifically designed to orchestrate EnergyPlus executions inside isolated containers, as detailed in Section 3.2. This setup ensured a consistent and reproducible runtime across systems, while simplifying dependency management and avoiding compatibility issues typical of local installations. The containerised structure also facilitated real-time interaction with input data and automated export of simulation outputs, providing a scalable and lightweight alternative for implementing the DT workflow.

3.4.2. Actuation to the Building

Following the completion of simulations, the energy-saving strategy was evaluated by processing the results. The final output of this evaluation was an optimised blinds schedule, specifying the daily times for raising and lowering blinds to optimise solar energy utilisation. These schedules were stored in comma-separated CSV files, specifying the date and time (dd/mm/yyyy HH:MM:SS) and a binary code (0 for blinds down, 1 for blinds up).

The CSV files were then sent to the BMS’ Microservices VM, which hosts the MQTT broker, using the SCP (Secure Copy Protocol) command via Python and previously establishing an SSH connection between the computer and the VM. A Python script running on the Microservices VM continuously monitored the CSV files for updates, read the designated times for raising or lowering the blinds, and subsequently sent the corresponding commands to the blind actuators.

Once the CSVs were received in the VM, they were read to identify the date and time of each blind raise/lower and acted upon by Mosquitto. The command used for the action is as follows:

f’mosquitto_pub -t “{BlindCode}” -m “A”

where BlindCode is the code assigned to each blind in the database and A is the binary code to raise or lower the blind.

3.4.3. Simulation Setup

The simulations of the DTs were performed in a computer equipped with an 11th Gen^® Core™ i7-1165G7 processor running at 2.80 GHz, 16.0 GB of installed RAM, and a 64-bit OS on an x64-based architecture. This computer was connected to the same network as the VMs of the BMS.

Simulation models for both DTs were developed with EnergyPlus in its 9.4 version. The FMU was simulated within MATLAB^® R2024b version, and the EnergyPlus containerised simulation was employed with Python 3.11.9 version.

Concerning the simulation interval, it was set to 10 min as a compromise between the different sensor resolutions and the computational demands of the co-simulation. Given that blind actuation was measured at 5-min intervals and environmental sensors at 15-min intervals (see Table 1), a 10-min timestep was selected to represent both processes with sufficient accuracy while maintaining a manageable simulation time. In addition to these considerations, the choice of timestep was further informed by the characteristics of the key variable used for model calibration: the indoor air temperature, which is recorded at a fixed 15-min sampling interval. Employing a significantly finer timestep would increase missing observational data, requiring additional interpolation that would introduce artificial uncertainty without improving the model’s ability to represent building thermal dynamics. Consequently, this 10-min timestep ensured stable solver performance without sacrificing system fidelity.

This timestep choice is further supported by previous calibration efforts, in which a 10-min interval has consistently yielded stable and reliable outcomes. Earlier studies [54,55], as well as the calibration of the BEM employed in the present work, were likewise conducted using temperature datasets sampled at this same temporal resolution. Collectively, these experiences offer empirical evidence that a 10-min timestep is appropriate for capturing the building’s thermodynamic behaviour.

Finally, an important note concerning FMU simulation is that the sampling period must match the timestep indicated in the IDF file, converted to seconds. In this case, a 10-min timestep in the IDF translates to a 600-s sampling period in MATLAB. The simulation time frame was specified as a one-dimensional array in seconds, starting at zero, incrementing by 600 s, and concluding with the total seconds corresponding to the full simulation duration. In this specific case, simulating 18 days resulted in the array’s final element being 1,555,200 s.

4. Results

This section presents the main results obtained from the implementation and testing of the proposed DTs. First, the performance of the FMU- and Docker-based approaches is compared in terms of simulation behaviour, computational efficiency, and practical applicability. The analysis highlights their respective advantages and limitations when integrating calibrated BEMs into real-time building operation. Subsequently, the outcomes of the surrogate models are evaluated, focusing on their ability to replicate the physics-based blind control strategy and to generate optimal schedules with minimal computational cost. Finally, the energy savings achieved under different modelling approaches are compared, demonstrating the potential of surrogate-assisted optimisation for efficient and scalable building operation.

4.1. General Comparison Between FMU- and Docker-Based DTs

The comparison between the EnergyPlus models for the FMU and the container shows that, in both cases, an IDF must be used where I/O such as schedules, actuators, or variables have already been defined. While it is possible to start from the same IDF in both cases, the FMU requires additional preparation to add the External Interface and the FMU I/O with the objects indicated in

Table A1. Objects to define the inputs and outputs of the FMU and EnergyPlus in the IDF file.

I/O of FMU	Object of External Interface	Object/Variable of EnergyPlus
Input	* To:Schedule	EnergyPlus schedules
	* To:Actuator	EMS actuators
	* To:Variable	EMS variables
Output	* From:Variable	Output:Variable
		EnergyManagementSystem:OutputVariable

* ExternalInterface: FunctionalMockupUnitExport.

of the Appendix B. For simple BEM models with a small number of thermal zones (as is the case in this paper), the creation of the FMU is not a time-intensive process. However, this could take much longer for more complex models with a large number of thermal zones, which could be the case when implementing these strategies for a whole building.

Comparing inputs and outputs of both approaches, presented in Table 3, it can be extracted that schedule I/O coincided in both cases, while the main difference was found in weather variables. As stated before, weather inputs are restricted in the FMU, while the EnergyPlus container allows to use all variables included in the EPW file. Thus, given that the FMU accepts a maximum of seven weather inputs, the influence of other variables cannot be accounted for in the simulations. Advantages and disadvantages of both methods are presented in Figure 8. Green checkmarks indicate the aspects where one method outperforms the other, inversely for red crosses.

Moreover, it has been determined that the variables incorporated into the EPW which were not defined as FMU inputs significantly impact the outcomes, since the simulation retrieves these values directly from the EPW file used to generate the FMU. Similarly, the values of other EPW variables during the initial days of the year can also impact results. This occurs because the FMU does not allow simulation dates to be specified, with its time vector inherently starting at zero. Consequently, the simulation incorrectly assumes the initial days of the year for its time frame, incorporating variable values from this period. For example, rainfall from the EPW’s initial days can affect results, particularly if precipitation occurred then. Therefore, when creating the FMU, this should be addressed by modifying the EPW to zero out these variables for the initial days, by generating the FMU without an EPW entirely, or by rebuilding the FMU for each simulation, which implies a substantial workload.

With regard to the simulation, it has been determined that a one-timestep temporal discrepancy exists between the outcomes of the FMU and the containerised EnergyPlus simulation. This delay is attributable to the discrepancy between the FMU solver and the Simulink solver in this instance. Since the FMU was generated for co-simulation, the simulation is primarily governed by the internal solver of the EnergyPlus FMU, which is embedded within the FMU binary, while MATLAB^®/Simulink^® functions solely as the master, providing inputs and receiving outputs at each timestep. To ensure proper synchronisation, a fixed-step solver must be employed in Simulink to match the timestep of the EnergyPlus solver. Although several fixed-step solvers were evaluated, the observed one-timestep discrepancy could not be eliminated, since the FMU’s internal solver ultimately determines the simulation results. Consequently, the step size cannot be modified independently and must remain identical to that of the original EnergyPlus model. Likewise, tolerance settings in Simulink are only relevant for variable-step solvers and do not apply to fixed-step configurations; similarly, while the FMU may include internal tolerance settings, these have no effect in co-simulation mode, since the FMU advances its states according to its own solver logic and numerical precision.

The temporal discrepancy can, theoretically, be resolved by generating the FMU with FMI version 3.0 and adjusting certain simulation options. However, it should be noted that this is not a possibility in the case of FMUs created with the EnergyPlusToFMU tool, which only supports FMI versions 1.0 and 2.0. Therefore, the influence of this delay on the simulation results and their application to the real building should be evaluated prior to real implementation. In particular, although a one-timestep delay may appear negligible, it could affect the performance of real-time control strategies, such as blind actuation or HVAC regulation, where timely responses are critical. To mitigate this limitation, several strategies can be considered:

• Conducting sensitivity analyses to quantify the impact of the delay on control performance;
• Incorporating predictive control schemes that anticipate system dynamics and compensate for the lag; and
• Post-processing the simulation results to align signals for off-line analyses.

These measures help ensure that the temporal discrepancy does not compromise the reliability of the proposed strategies when transitioning from simulation to real implementation.

Furthermore, a notable difference between both approaches is their reliance on different software for simulating each approach. In order to simulate the FMU, a master software—MATLAB (version 2025b) in this study—and EnergyPlus are required, whereas for containerised EnergyPlus simulations only EnergyPlus and Docker are needed. In the first case, it will also be necessary to have the corresponding licence for the master programme, if necessary, and ensure that it can be installed on the computer or VM used for the simulation.

A further advantage of the containerised approach is its inherent OS independence. FMUs are generated for a specific OS, necessitating checking compatibility before simulating an FMU on a different machine. Otherwise, re-creation and installation of Python libraries are required. For these reasons, the installation and implementation of containerised EnergyPlus appears to be more straightforward and replicable in principle, as well as being a portable solution for different systems and buildings.

Regarding execution times, the FMU-based simulation ran approximately twice as fast as the Docker-based approach in our tests—4.5–6.5 min of FMU approach versus 10–11 min of Docker—. However, this difference must not be interpreted as an intrinsic advantage of FMU encapsulation. In our implementation, the FMU was executed in MATLAB^®/Simulink^®, which benefits from an optimised co-simulation engine, whereas the Docker workflow relied on native EnergyPlus invoked through a Python microservice using Redis and RQ for job management. The measured runtime differences therefore reflect the combined effects of these environments, including solver implementation and orchestration overhead, rather than encapsulation alone.

Moreover, the adoption of MATLAB^®/Simulink^® as the FMU master was not a design preference but a practical consequence of current tool support: at the time of the study, we were unable to execute EnergyPlus-generated FMUs reliably using the available Python libraries, which were outdated or incompatible with recent dependencies. As a result, FMU-based and Docker-based DTs were implemented through different software stacks, and the conclusion that “FMUs execute faster” should be understood as specific to these stacks and not generalised to all possible configurations.

Despite this limitation, reporting the end-to-end execution times remains relevant. Operational DTs must consider not only the simulation engine but also the surrounding integration layers, and our results provide a realistic picture of the practical overhead imposed by each workflow under currently available toolchains. This practice-oriented comparison is particularly valuable in a context where fully operational FMU- and container-based DTs in buildings are still emerging, and concrete implementation experiences remain scarce.

4.2. Surrogate Modelling for Blind Control Optimisation

The surrogate modelling framework was adopted not only as an alternative to the physics-based, rule-driven optimisation previously implemented with calibrated BEMs, but also to remove the I/O bottleneck of the original pipeline. In the FMU/Docker workflows, deriving blind schedules required running full EnergyPlus simulations, exporting CSV results, downloading them to a client for post-processing, and re-uploading the optimal timetables for actuation. By contrast, the surrogate models learn the mapping from environmental inputs to optimal blind states and is executed in situ inside the Docker worker, emitting the final open/close schedule directly—without exporting simulation outputs, transferring files, or performing any local post-processing. This design collapses the “download–process–upload” loop, cuts end-to-end latency to milliseconds, and streamlines MQTT integration with the BMS.

Results showed that different surrogate strategies offered complementary benefits. The stand-alone models ($f_{\theta }$) directly predicted the binary trajectory from weather and indoor variables; ensemble methods such as Extra Trees and LightGBM consistently outperformed linear baselines, achieving MAE $< 0.07$ and R² in the 0.84–0.86 range (

Table 4. ML model comparison for $f_{\theta }$.

Model	MAE	RMSE	R2	MAPE	Training Time (s)
Extra Trees Regressor	0.0650	0.1643	0.8573	0.0377	0.2063
Light Gradient Boosting Machine	0.0664	0.1775	0.8376	0.0322	0.4848
Random Forest Regressor	0.0711	0.1893	0.8177	0.0439	0.9970
Gradient Boosting Regressor	0.0813	0.1935	0.8140	0.0384	1.0433
AdaBoost Regressor	0.0882	0.1977	0.8021	0.0448	0.2300
Elastic Net	0.1478	0.2339	0.7354	0.0726	0.0420
Lasso Regression	0.1533	0.2351	0.7331	0.0822	0.0272
Lasso Least Angle Regression	0.1533	0.2351	0.7331	0.0822	0.0240
K Neighbors Regressor	0.0763	0.2342	0.7178	0.0453	0.0638
Decision Tree Regressor	0.0673	0.2410	0.7022	0.0427	0.0612

). These figures confirm that comparatively simple regressors can replicate the BEM-based controller’s logic at negligible computational cost, yielding daily schedules in real time within the worker and with no ancillary data handling.

The two-step surrogation method ($g_{\varphi }$ + $h_{\psi }$) is designed to emulate intermediate BEM outputs—namely, window heat gains and losses—through $g_{\varphi }$ and then pass these proxies to a surrogate optimiser. Because $g_{\varphi }$ predicts raw energy magnitudes (with ranges orders of magnitude larger than the binary targets in $f_{\theta }$ and $h_{\psi }$), absolute error metrics such as MAE/RMSE appear numerically higher in

Table 5. ML model comparison for $g_{\varphi }$.

Model	MAE	RMSE	R2	MAPE	Training Time (s)
Extra Trees Regressor	34,606	63,359	0.7957	1.2742	0.5757
Gradient Boosting Regressor	39,889	67,637	0.7842	1.5489	0.9071
Light Gradient Boosting Machine	36,515	67,510	0.7554	1.2994	0.1498
Random Forest Regressor	37,666	69,622	0.6872	1.2832	1.7492
Elastic Net	60,580	85,295	0.5703	3.9309	0.0932
AdaBoost Regressor	75,452	90,735	0.5603	3.1472	0.3791
Decision Tree Regressor	45,628	89,992	0.5459	1.2356	0.0550
Lasso Regression	64,005	91,826	0.4838	3.5827	0.0799
Ridge Regression	66,731	95,551	0.4172	3.4598	0.0243
Bayesian Ridge	67,326	96,684	0.4030	3.4975	0.0248

. This difference reflects the scale of the predicted variables, not a loss of relative fidelity. When assessed with scale-independent measures (e.g., ${\mathrm{R}}^2$) or normalised error criteria, $g_{\varphi }$ attains competitive accuracy (Table 5), and the resulting schedules capture the intended open/close dynamics with sufficient precision. A key advantage of this design is traceability: by exposing interpretable physical features, $g_{\varphi }$ preserves a direct link to the original rule set and accommodates changes in thresholds or constraints without re-engineering the whole data pipeline.

By contrast, $g_{\varphi }$ exhibited lower accuracy, with numerically higher MAE and RMSE values. This behaviour is expected, since $g_{\varphi }$ is designed to replicate raw physical outputs of the BEM (e.g., window heat gains and losses), which span larger numerical ranges and depend on a greater number of interacting and non-linear variables. In this sense, predicting intermediate physical quantities is inherently more challenging than directly estimating the final blind states, which involve a more compact and less complex mapping. As a result, although $g_{\varphi }$ retains valuable physical interpretability, its predictive performance remains below that of the other two surrogates ($f_{\theta }$ and $g_{\varphi }$).

The $h_{\psi }$ surrogate configuration yielded the best overall results, achieving ${\mathrm{R}}^2 > 0.96$ and MAE $\approx 0.01$ with models such as K-Nearest Neighbours, Extra Trees, and Random Forest (

Table 6. ML model comparison for $h_{\psi }$.

Model	MAE	RMSE	R2	MAPE	Training Time (s)
K Neighbors Regressor	0.0124	0.0790	0.9688	0.0083	0.0278
Extra Trees Regressor	0.0226	0.0829	0.9647	0.0169	0.0813
Random Forest Regressor	0.0192	0.0863	0.9630	0.0138	0.5308
Light Gradient Boosting Machine	0.0241	0.0877	0.9627	0.0190	0.1042
Gradient Boosting Regressor	0.0230	0.0922	0.9590	0.0165	0.7000
AdaBoost Regressor	0.0372	0.1185	0.9321	0.0341	0.0790
Decision Tree Regressor	0.0198	0.1269	0.9121	0.0164	0.0245
Lasso Regression	0.1564	0.1999	0.8124	0.1257	0.0435
Elastic Net	0.1564	0.1999	0.8124	0.1257	0.0473
Lasso Least Angle Regression	0.1520	0.2005	0.8114	0.1151	0.0165

).

A comparative summary (

Table 7. Stand-alone vs. two-step surrogate methods: practical trade-offs.

	Stand-Alone	Two-Step
Online latency	Very low (single pass)	Low (two passes: $g_{\varphi }$ + $h_{\psi }$)
Interpretability	Lower (direct mapping)	Higher (physics proxies ${\widehat{\mathbf{z}}}_t$)
Engineering effort	Minimal (.pkl only)	Moderate (model + rules or $h_{\psi }$)
Portability (Docker)	Single .pkl in worker	.pkl + rules (or two .pkl)

) highlights that: stand-alone surrogates maximise speed and simplicity for ultra-low-latency or edge scenarios; and two-step surrogates favour interpretability and policy robustness, while assuring sub-second execution.

Overall, the surrogates reproduce the operational schedules of the physics-based pipeline while eliminating the need to download, post-process, and re-upload simulation results. This materially reduces computational and network overheads, simplifies operations, and enables near real-time responsiveness in the DT framework, with seamless hand-off to the building’s BMS via MQTT.

Note that cross-model comparisons of absolute error magnitudes (MAE/MSE/RMSE) between surrogate models are not directly meaningful due to the very different target scales; scale-independent metrics (e.g., ${\mathrm{R}}^2$) provide a fair basis for comparison.

If the priority is minimal latency and operational simplicity (e.g., tight actuation windows, edge compute), the stand-alone model is preferable. If traceability, auditability and robustness are paramount (e.g., heterogeneous facades, evolving policies, regulatory contexts), the two-step scheme is advantageous. Both options drastically reduce computational cost vs. looping full BEM simulations, enabling (near) real-time scheduling and streamlined Docker-based operation without download/upload round-trips.

4.3. Comparison of Energy-Saving Results

In order to facilitate a comparative analysis of the various methods examined in this study, simulations were conducted over the course of two weekends in February 2025 (specifically, on the 8th–9th and 22nd–23rd, henceforth designated as periods 1 and 2, respectively). The simulations were conducted on the Friday preceding each weekend, thereby ensuring optimal blind schedules for energy savings. These schedules were then applied to the blinds during the two-day period. In reality, the schedules that were applied were those of the EnergyPlus container and the FMU, with the aim of comparing both implementations in a real application. The surrogate models $f_{\theta }$ and $h_{\psi }$ were compared with the previous ones using the simulation results only. Furthermore, simulations were conducted with the blinds closed throughout the weekend in order to calculate the energy savings of the other models in comparison to the typical situation when the building is unoccupied, i.e., closed enclosures.

In this section, the optimal blind schedules obtained from each model are firstly compared, followed by the analysis of energy demand and energy savings when applying each optimal schedule.

4.3.1. Optimal Blind Schedules

Table 8. Optimal blind schedules. Those applied to the real building are marked in red colour.

Period	Date	Room	Opening				Closing
			E+C	FMU	${\mathit{f}}_{\theta }$	${\mathit{h}}_{\psi }$	E+C	FMU	${\mathit{f}}_{\theta }$	${\mathit{h}}_{\psi }$
1	08/02	PA:023	9:20	8:30	9:30	9:40	17:30	17:30	16:30	16:10
		PA:024	9:20	8:30	9:30	9:30	17:30	17:20	17:00	17:10
		PA:029	9:20	8:20	9:30	9:30	18:10	17:20	17:40	17:40
		PA:031	9:20	8:30	9:30	9:30	18:00	17:20	17:40	17:40
1	09/02	PA:023	9:20	8:30	9:20	9:30	17:50	17:20	18:00	17:30
		PA:024	9:20	8:30	9:10	9:20	17:30	17:20	18:00	17:30
		PA:029	9:10	8:20	9:10	9:10	18:10	17:20	18:00	18:10
		PA:031	9:20	8:30	9:10	9:20	18:10	17:20	18:00	18:00
2	22/02	PA:023	9:00	8:30	9:30	9:40	17:30	18:00	17:20	16:40
		PA:024	8:50	8:30	9:10	9:30	17:30	17:50	17:30	17:20
		PA:029	9:00	8:20	8:50	9:00	18:20	18:00	18:00	18:00
		PA:031	9:00	8:30	8:50	9:10	18:30	18:00	18:00	18:00
2	23/02	PA:023	8:50	8:40	9:20	9:50	17:40	18:00	17:40	17:20
		PA:024	8:50	8:40	9:10	9:30	17:40	18:00	17:50	17:40
		PA:029	8:50	8:20	8:50	9:00	18:30	18:00	18:20	18:20
		PA:031	8:50	8:30	8:50	9:10	18:30	18:00	18:20	18:20

E⁺C: EnergyPlus Container. Dates in dd/mm format (year 2025) and times in HH:MM format.

presents the optimal blinds schedules obtained by each model for each room and day. On initial observation, it becomes evident that the opening times for the blinds exhibit a high degree of similarity across all models and rooms. However, a more pronounced variation is observed in the closing times. It is evident that as the date and season of the year progress, the opening of the blinds is brought forward, with differences of up to half an hour between one weekend and another. Conversely, closing times are progressively delayed, presumably to take advantage of the increased daylight hours as the year progresses.

A closer analysis of the opening of blinds reveals that the EnergyPlus container schedules are consistently later, while the FMU opens 10–20 min earlier. In terms of closure, the EnergyPlus container has been found to maintain the blinds in an open position for a greater duration, whilst the FMU has been observed to close them earlier. With regard to $f_{\theta }$ and $h_{\psi }$, their closing times deviate from those of the EnergyPlus container (the model used for their training) by up to one hour in some cases. These discrepancies arise from the simplified nature of the surrogate models, which approximate the control logic of the physics-based simulations rather than reproducing their exact dynamics.

It is evident that the FMU exhibits more consistent opening-closing patterns, while the EnergyPlus container, $f_{\theta }$, and $h_{\psi }$ demonstrate greater variability in their schedules. This finding suggests that these models may be better adapted to the climatic and interior conditions of the building, resulting in more variable and adapted schedules. However, the FMU has been observed to underperform in accurately capturing meteorological phenomena and indoor environmental conditions, thereby producing more stable but less responsive schedules in most cases.

4.3.2. Expected Energy Demand and Savings from Simulations

In this section, the results of the simulations carried out with predictive climate data, performed on Fridays, are firstly compared to ascertain the energy savings obtained with each optimal blind schedule proposed in Section 4.3.1. Secondly, the savings that would be obtained with each optimal blind schedule are assessed and compared among models.

As demonstrated in

Table 9. Simulated energy demand with each model using predicted weather.

Period	Room	Closed Blinds	Container	FMU	${\mathit{f}}_{\mathit{\theta }}$	${\mathit{h}}_{\mathit{\psi }}$
1	PA:023	82.85	79.83	78.37	77.95	77.79
	PA:024	107.07	94.08	93.87	94.14	94.28
	PA:029	78.85	81.11	81.14	80.75	80.81
	PA:031	69.04	63.75	63.87	63.78	63.80
2	PA:023	90.70	82.60	83.01	82.30	81.98
	PA:024	118.42	99.93	99.48	100.24	100.38
	PA:029	88.02	92.28	92.83	92.18	91.94
	PA:031	67.88	62.33	62.41	62.39	62.45

  Period 1: 8–9 February 2025. Period 2: 22–23 February 2025.

, where the energy consumption of all models is shown for both periods, it is evident that, with the exception of room PA:029, all models exhibit a reduced energy consumption than in the case with the blinds closed. However, in room PA:029, the converse is observed: all models exhibit marginally higher consumption. Consequently, with the exception of this particular room, all models obtain an optimal blinds schedule that facilitates energy savings. Notably, room PA:024 exhibits the most substantial reduction in consumption when compared to the scenario where the blinds are fully lowered.

In order to facilitate a more precise evaluation of the energy savings for each room, these have been calculated based on the simulation with the blinds closed as follows:

$$E{S}_i(\%)={\displaystyle \frac{E{D}_{closedblinds}-E{D}_i}{E{D}_{closedblinds}}}\times 100$$

(1)

where $E{D}_{closedblinds}$ is the energy demand for the closed blinds case, and $E{S}_i$ and $E{D}_i$ are the energy saving and demand, respectively, for model i, which can be EnergyPlus container, FMU, $f_{\theta }$, or $h_{\psi }$.

The energy savings for each model and room during periods 1 and 2 are tabulated in

Table 10. Simulated energy savings (%) of each model compared to the closed blinds case, using predicted weather. The cases offering the greatest savings for a room are marked in red colour.

Period	Room	Container	FMU	${\mathit{f}}_{\mathit{\theta }}$	${\mathit{h}}_{\mathit{\psi }}$
1	PA:023	3.64	5.40	5.91	6.11
	PA:024	12.13	12.33	12.08	11.95
	PA:029	$-2.87$	$-2.90$	$-2.41$	$-2.48$
	PA:031	7.67	7.49	7.62	7.60
2	PA:023	8.94	8.49	9.27	9.61
	PA:024	15.61	15.99	15.35	15.23
	PA:029	$-4.83$	$-5.47$	$-4.72$	$-4.45$
	PA:031	8.16	8.06	8.09	7.99

  Period 1: 8–9 February 2025. Period 2: 22–23 February 2025.

. As also depicted in Table 9, the room designated as PA:024 demonstrates the highest savings across both periods, while PA:029 exhibits a contrasting scenario, characterised by a decline in energy efficiency and an increase in energy consumption, as evident in Table 9.

A comparison of the four models reveals that the one offering the greatest energy savings does not coincide between the rooms, although it does match for each room and both periods. For PA:023, the $f_{\theta }$ model offers superior energy savings, while for the PA:024 and PA:031 rooms, the optimal choices are determined to be the FMU and EnergyPlus container, respectively. Furthermore, the second model for which savings are greatest coincides for rooms PA:023 and PA:031 and for both periods, being model $f_{\theta }$. In relation to room PA:029, the model yielding the lowest possible energy demand should be selected, i.e., the savings (although negative) should be as close to zero as possible. Consequently, the models that demonstrate the highest level of savings are $f_{\theta }$ for period 1 and $h_{\psi }$ for period 2, both of which are surrogate models. From this analysis, it can be concluded that the $h_{\psi }$ surrogate model provides superior energy savings on three occasions, outperforming the other models.

However, it should be pointed out that there are no significant discrepancies in energy savings above 1% between the models. Specifically, for rooms PA:024, PA:029, and PA:031, the only discrepancies observed are of a decimal nature; as such, the results obtained are highly likely to be comparable among all models. Nevertheless, PA:023 constitutes an exception, with a disparity of 2.47% between the maximum and minimum energy savings (models $h_{\psi }$ and EnergyPlus container, respectively), which represents a considerable difference that should be taken into account for this room.

4.3.3. Comparison of Obtained Energy Savings in Simulated and Actual Scenarios

As previously mentioned, the implementations proposed in this study, specifically the EnergyPlus container and the FMU, were applied in reality and the optimal schedules obtained were sent to the blinds to be executed over the weekend. In order to compare these implementations, the models were simulated using real temperature data from the weekend, taking into account the optimal schedules applied to the blinds. This facilitated the estimation of simulated energy demand using real data, as well as the calculation of estimated energy savings. The schedules that were determined to be optimal were applied to various rooms: the optimal FMU schedule was implemented in rooms PA:023 and PA:031, while the EnergyPlus container schedule was applied to rooms PA:024 and PA:029, as they are symmetrical to each other within the building.

The results of the aforementioned simulations are displayed in

Table 11. Simulated energy demand ($ED$) and energy savings ($ES$) using real temperature, weather, and blinds schedule data. Only those cases in which the optimal schedule has been applied in reality to the building are included.

Period	Room	$\mathit{ED}$ (kWh)			ES * (%)
		Closed Blinds	Container	FMU	Container	FMU
1	PA:023	82.85	–	40.86	–	50.68
	PA:024	107.07	27.66	–	74.17	–
	PA:029	78.85	13.43	–	82.97	–
	PA:031	69.04	–	15.81	–	77.10
2	PA:023	90.70	–	36.83	–	59.39
	PA:024	118.42	31.63	–	73.29	–
	PA:029	88.02	15.83	–	82.02	–
	PA:031	67.88	–	14.26	–	79.00

  * Compared to the closed blinds case. Period 1: 8–9 February 2025. Period 2: 22–23 February 2025.

, where energy consumption and savings have been calculated solely for those rooms in which the optimal blind schedule has been implemented. Furthermore, the energy savings have been calculated according to Equation (1) based on consumption with the blinds closed, which is also shown in Table 11. In an initial analysis, it is evident that the EnergyPlus container offers greater savings for each facade in comparison to the FMU. The EnergyPlus container demonstrated significant energy savings of 74.17% and 73.29% for the east facade during periods 1 and 2, respectively, while the FMU offered savings of 50.68% and 59.39% for the same periods. Furthermore, savings for the west facade were 82.97% and 82.02% from the EnergyPlus container during periods 1 and 2, respectively, and 77.10% and 79.00% from the FMU.

Beyond the quantitative results, it is instructive to compare the behaviour of the surrogate-driven schedules with those derived from the physics-based simulations (FMU and Docker). As shown in Table 11, the energy savings obtained by the surrogate models were generally within the same range as those produced by the calibrated BEMs, with discrepancies typically below 1–2%. This confirms that the surrogate approach preserves the control intent of the physics-based optimisation while offering much faster computation.

In practical terms, the FMU and Docker simulations required full EnergyPlus executions lasting several minutes per scenario, whereas the surrogates produced equivalent 0/1 blind schedules in a few milliseconds within the same Docker worker. This reduction in end-to-end latency enables near real-time schedule generation and immediate actuation through MQTT without manual post-processing.

From an operational perspective, the FMU and Docker workflows remain indispensable for model calibration and physics validation, ensuring traceability and physical consistency. However, once these models are validated, surrogate inference can replace repetitive optimisation loops during daily operation, maintaining accuracy while significantly reducing computational and data-transfer overheads. Together, these complementary methods establish a practical balance between fidelity and responsiveness, allowing DTs to operate efficiently at both design and operational stages.

5. Discussion

In this section, the results obtained across all experiments are synthesised and interpreted by comparing FMU, Docker and surrogates, along with the main limitations of the study and the extent to which the findings can be generalised.

5.1. Evaluation and Comparison of DT Architectures

The results obtained in this study allow for a critical assessment of the practical applicability, advantages, and limitations of the different approaches proposed for the implementation of DTs based on BEMs. The comparison between FMU- and Docker-based strategies (Section 4) shows that, although both enable direct coupling of the BEM with the BMS, they exhibit complementary characteristics in terms of portability, scalability, and implementation effort.

The FMU-based approach demonstrated higher computational efficiency, with simulation times approximately twice as fast as those obtained with the Docker implementation, prior to surrogation. This performance gain may be particularly relevant in contexts where short response times are required, such as closed-loop control or predictive operation with limited computational resources. However, this gain in speed comes at the cost of greater technical complexity during model preparation and reduced flexibility during deployment. The need to generate an FMU specific to each OS, together with the limitation of only seven weather input variables, restricts its scalability and complicates replication across different buildings or computing infrastructures. In contrast, the Docker-based implementation simplifies deployment and ensures reproducibility, allowing simulations to run identically across any environment without software conflicts. This aligns with recent research that highlights containerisation as a core enabler of scalable and cloud-based DT architectures [17,18,19].

Although Docker simulations required approximately twice the execution time of the FMU, this difference is not operationally limiting, particularly considering the gain in robustness, maintainability, and the ease of integration with auxiliary services such as automated data ingestion or visualisation modules. Consequently, the Docker-based DT stands out as a portable and practical alternative, enabling reproducible simulations and facilitating real-time communication with IoT and BMS infrastructures. These properties are especially valuable for scaling the methodology to multi-building environments or for integration into cloud services.

Experimental results confirmed that both implementations produced highly consistent blind opening and closing schedules (Section 4.3.2). Temporal differences between the models were below one hour, indicating coherent representations of the building’s thermal response. Although a one-timestep (10-min) offset was identified between FMU and Docker simulations, its impact on predicted heating demand and overall savings was negligible. The simulated energy reductions ranged from 10% to 15% compared with the static closed-blind configuration, confirming that the proposed control strategy effectively harnesses passive solar gains during unoccupied periods without requiring physical HVAC retrofits. These findings are consistent with prior research on predictive blind control and energy-aware management in buildings [24,38], validating the robustness of the implemented strategy.

The comparison between simulated and real-world applications also showed strong agreement, confirming the reliability of both DTs for predictive and operational use. Some deviations were observed, mainly related to sensor limitations, variations in local climatic conditions, and the limited temporal resolution of the BMS datasets. These discrepancies emphasise the importance of continuous calibration and periodic validation, as recommended in recent DT literature [10], to sustain long-term accuracy and adaptability under changing boundary conditions.

The incorporation of surrogate models within the Docker workflow represents a significant methodological improvement in terms of computational scalability and operational efficiency. In addition to replicating the optimisation logic of the physics-based controller with negligible computational cost (MAE $< 0.07$ when predicting binary blind states), the surrogates simplified the overall workflow. In the original Docker-based pipeline, blind optimisation required downloading simulation outputs from the container, post-processing them externally to generate the schedule, and uploading the resulting timetable back for actuation. In contrast, the surrogate models can be serialised as lightweight .pkl files and executed in situ within the same Docker worker that hosts the DT, computing the optimised 0/1 schedules directly without intermediate data transfers or manual steps. This integration effectively mitigates the I/O bottleneck of the original process, reduces end-to-end latency to milliseconds, and enables near real-time actuation through MQTT, while maintaining the control intent of the calibrated BEM. Ensemble methods such as Extra Trees, LightGBM, and Random Forest consistently outperformed linear baselines, corroborating findings from previous surrogate-based optimisation frameworks [22,24].

The comparison between surrogate strategies revealed complementary advantages. The stand-alone model ($f_{\theta }$) maximises inference speed and implementation simplicity, making it suitable for low-latency or edge-computing applications. Conversely, the two-step approach ($g_{\varphi }+h_{\psi }$) enhances interpretability by predicting intermediate physical quantities such as window heat gains and losses before deriving the final blind states. This structure provides direct traceability to the original RB controller and allows for straightforward updates to operational thresholds without retraining. Depending on the application domain, either strategy can be prioritised: the former for computationally constrained environments, and the latter for regulatory or auditability contexts where interpretability is essential. In both cases, the surrogates preserved the control intent of the calibrated BEM while drastically reducing computational and data-handling overhead.

Overall, the results highlight the value of combining calibrated models, containerised simulation, and surrogate-based acceleration as complementary pillars for operational DTs. This integration balances physical fidelity and responsiveness, bridging the gap between high-fidelity simulation and real-time building operation. Nonetheless, certain limitations should be acknowledged: the restricted number of thermal zones analysed, the winter-specific conditions of the case study, and the absence of occupant comfort and multi-system coupling analyses (e.g., lighting, ventilation).

In summary, the proposed combination of FMUs, Docker containers, and surrogate models demonstrates that hybrid DT workflows can effectively transition from theoretical modelling to operational decision-making. The presented methodology preserves physical consistency while enabling scalable, low-latency, and data-driven control—paving the way toward adaptive, efficient, and deployable DTs for the building sector.

5.2. Limitations & Generalisability of This Study

The findings of this study must be interpreted within the scope and constraints of the case study. The experiments were carried out in a educational building and focused on four thermal zones operating during winter weekends, when the building is unused. While suitable for demonstrating the feasibility of the proposed workflows, this configuration does not capture the full diversity of multi-zone, seasonally variable buildings. In larger buildings, the number of actuators, internal gains and interacting thermal masses increases substantially, which may amplify modelling uncertainties and computational demands.

The limitations of the FMU-based workflow are expected to become more pronounced in more complex buildings. The EnergyPlus-to-FMU export restricts the set of weather variables that can be overridden, which may be problematic in scenarios requiring dynamic inputs such as natural ventilation, humidity control or detailed solar–thermal interactions. By contrast, the Docker-based workflow does not suffer from weather-input limitations, but its scalability is conditioned by hardware allocation, parallel execution capabilities and container orchestration. Whole-building or high-frequency simulations may increase execution times or require more advanced resource management.

An important methodological implication arising from this study concerns the role of surrogate modelling. Although the present work does not evaluate large-scale building models, the extremely low computational cost of surrogate-based optimisation offers a promising pathway towards scalability. Surrogate inference operates in milliseconds and can evaluate thousands of candidate control actions without invoking full-physics simulations. This lightweight computational behaviour can mitigate the increasing simulation burden of large, detailed BEMs, and therefore represents a viable strategy for deploying operational DTs in more complex buildings or under higher temporal resolutions.

On another note, the results discussed here correspond to winter conditions characterised by heating demand and the absence of occupancy during the experimental periods. Other seasons may exhibit different sensitivities, particularly when cooling loads or solar gains dominate. To address these limitations and build upon the demonstrated feasibility of both workflows, future work will extend the proposed approach to whole-building simulations and multi-season scenarios in order to more comprehensively assess robustness and scalability across diverse operating conditions.

Moreover, several methodological refinements warrant further investigation. Sensitivity analyses comparing alternative imputation approaches for filling data gaps will help identify the most robust strategies for handling missing or faulty sensor data. Additionally, timestep sensitivity studies are needed to determine the most suitable temporal resolution for real-time control and simulation, balancing computational efficiency with control accuracy.

Beyond these technical considerations, incorporating occupant-driven interactions and fallback strategies will be essential to ensure resilient operation under communication failures and other uncertainties typical of real-world deployments. These enhancements would address practical operational concerns that were not evaluated in the current unoccupied, weekend-only experimental setup.

Overall, these considerations underline that the present study provides a practice-oriented demonstration of two viable digital-twin deployment pathways, while its conclusions should be interpreted in light of building size, system complexity and seasonal variability.

6. Conclusions

This work presented a unified methodological framework for developing and deploying Digital Twins (DTs) based on calibrated Building Energy Models (BEMs), demonstrating their capacity to support predictive, energy-saving strategies in real buildings. Two alternative encapsulation pathways were compared: a Functional Mock-up Unit (FMU) simulated in MATLAB^®/Simulink^® and a containerised EnergyPlus deployment using Docker. Both implementations were validated through real-time coupling with an educational building’s Building Management System (BMS), enabling automatic actuation of optimised blind schedules derived from model-based predictions. The results confirmed that both approaches can accurately reproduce indoor environmental dynamics and deliver measurable heating energy reductions without physical heating, ventilation, and air conditioning (HVAC) interventions.

The FMU-based approach offered faster simulation runtimes and tighter integration with engineering tools, making it suitable for co-simulation or hardware-in-the-loop applications. In contrast, the Docker-based workflow prioritised portability, reproducibility, and ease of deployment, allowing identical simulations across diverse computing environments while simplifying integration with internet of things (IoT) services and cloud infrastructures. Despite slightly higher runtimes, the containerised DT proved to be the most flexible and scalable option for continuous operation.

Beyond the comparison of FMU and Docker deployments, this study demonstrated the integration of machine-learning-based surrogate models within the Docker workflow to accelerate optimisation and actuation processes. These surrogates replicated the rule-based (RB) logic of the calibrated BEM while removing the input/output (I/O) bottlenecks of traditional simulation pipelines. Their in-situ execution inside the Docker worker reduced latency from minutes to milliseconds and enabled near real-time communication with the BMS through Message Queuing Telemetry Transport (MQTT). The findings show that surrogate models can complement physics-based simulations as lightweight accelerators, maintaining the operational intent and physical consistency of the original models while drastically reducing computational cost.

Taken together, the proposed methodology establishes a reproducible route toward deployable DTs that combine physical rigour, operational robustness, and computational scalability. By embedding calibrated simulations, containerised execution, and surrogate-assisted optimisation within a single framework, the work bridges the gap between high-fidelity modelling and day-to-day building operation. The approach enhances energy efficiency, reduces grid demand, and enables data-driven decision-making in existing buildings without requiring invasive retrofits.

Future work should extend the framework to other seasons, building typologies, and control objectives, incorporating continuous calibration routines and multi-objective optimisation strategies to further enhance robustness and generalisability. Additional research should include a sensitivity analysis comparing alternative imputation approaches for addressing data gaps, as well as a timestep sensitivity assessment to identify the temporal resolution most suitable for real-time control and simulation. Furthermore, integrating occupant-driven interactions and implementing fallback strategies to handle communication failures will be essential to ensure reliable and resilient operation in real-world DT–BMS deployments.