Advancing Energy Flexibility Protocols for Multi-Energy System Integration

Abstract

This study investigates the incorporation of a standardised flexibility protocol within a physics-based models to enable controllable demand-side flexibility in residential energy systems. A heating subsystem is developed using MATLAB/Simulink and Simscape, serving as a testbed for protocol-driven control within a Multi-Energy System (MES). A conventional thermostat controller is first established, followed by the implementation of an OpenADR event engine in Stateflow. Simulations conducted under consistent boundary conditions reveal that protocol-enabled control enhances system performance in several respects. It maintains a more stable and pronounced indoor–outdoor temperature differential, thereby improving thermal comfort. It also reduces fuel consumption by curtailing or shifting heat output during demand-response events, while remaining within acceptable comfort limits. Additionally, it improves operational stability by dampening high-frequency fluctuations in mdot_fuel. The resulting co-simulation pipeline offers a modular and reproducible framework for analysing the propagation of grid-level signals to device-level actions. The research contributes a simulation-ready architecture that couples standardised demand-response signalling with a physics-based MES model, alongside quantitative evidence that protocol-compliant actuation can deliver comfort-preserving flexibility in residential heating. The framework is readily extensible to other energy assets, such as cooling systems, electric vehicle charging, and combined heat and power (CHP), and is adaptable to additional protocols, thereby supporting future cross-vector investigations into digitally enabled energy flexibility.

1. Introduction

The global energy landscape is undergoing a significant transformation, driven by the urgent need to decarbonise, the rapid expansion of renewable energy sources, and the digitalisation of infrastructure. Variable Renewable Energy (VRE) technologies such as wind and solar are expected to contribute over 60% of electricity generation in many national grids by 2040 [1]. While this shift is vital for achieving climate goals, it introduces operational complexities, including variable generation patterns, increased ramping demands, and heightened risks to grid stability during supply–demand imbalances [2]. Moreover, regions with over 50% VRE penetration are likely to experience frequency instability, ramping shortages, and congestion without enhanced flexibility mechanisms [2].

Conventional power systems, originally designed around centralised and dispatchable generation, are poorly equipped to manage the variability and uncertainty of VRE. This has prompted the development of new system architectures that can accommodate large-scale flexibility [3]. A Multi-Energy System (MES) refers to an integrated network that combines various energy carriers, such as electricity, heating, cooling, gas, and , occasionally, hydrogen, through systems of conversion, storage, and control [4]. MES configurations offer several benefits, particularly in scenarios with high levels of variable renewable energy, which include

• Cross-vector flexibility: it allows energy demand to be shifted between carriers (e.g., switching from gas to electric heating during grid stress), reducing dependence on any single energy source [5].
• Improved storage coordination: it enables the joint use of thermal, gas, and battery storage to absorb excess renewable generation or supply energy during shortfalls [6].
• Sector coupling: it connects electricity, heating, and transport systems, allowing renewable electricity to replace fossil fuels in heating and mobility, thereby supporting decarbonisation efforts [7].

Within these multi-energy configurations, thermal energy storage (TES) plays a central role in unlocking the flexibility of heating systems. TES allows surplus heat to be stored during periods of low demand and released when heating loads or electricity prices are high, thereby decoupling heat generation from end-use consumption [8]. In buildings, TES can be implemented using sensible, latent, or thermochemical storage media; among them, latent storage based on phase change materials (PCMs) offers particularly high energy density and can be integrated into building envelopes or dedicated storage units [9]. Recent experimental work on paraffin-expanded graphite composites further demonstrates that compact TES units can achieve high storage capacity, fast charging and discharging rates, and favourable environmental performance, making them attractive components for future flexible heating systems [10]. These developments highlight that advanced TES solutions are natural complements to digitally coordinated MES and provide an important physical foundation for the flexibility-oriented control framework investigated in this study.

Thus, MES offer a promising approach to expand the range of flexibility options available to system operators, including thermal load shifting, gas-to-power conversion, and demand-side management. However, realising flexibility in MES requires more than physical integration; it demands a robust digital infrastructure capable of real-time communication between distributed energy resources (DERs), energy management systems (EMSs), and grid operators. This is facilitated by standardised energy flexibility protocols such as OpenADR 2.0 [11], IEEE 2030.5 [12], and EEBus SPINE [13], which allow devices to register capabilities, respond to external signals, and report performance. A major obstacle is achieving coherence across the communication layers embedded within the control structures of Multi-Energy Systems (MESs), where various energy carriers and conversion mechanisms must be coordinated concurrently. In the absence of proper semantic alignment, integrating protocols can lead to delays, reduced control effectiveness, or operational inconsistencies [14].

Despite the technical maturity of these protocols, there remains a critical gap in understanding their behaviour within operational MES environments. The lack of simulation-ready, protocol-compliant modelling platforms limits both academic inquiry and industrial deployment. This study addresses that gap by embedding OpenADR-based control logic into a dynamic MES simulation model, offering a reproducible framework for evaluating flexibility delivery at the system level. The remainder of this article is as follows: Section 2 reviews the literature on MES and the integration of energy flexibility protocols. The methodology is presented in Section 3 and the results are presented in Section 4 followed by a discussion in Section 5. Finally, Section 6 concludes the article.

2. Literature Review

2.1. Multi-Energy Systems (MES) as a Flexibility Backbone

Mancarella [15] argues that digitalisation is not simply a supplementary element but a fundamental driver of energy flexibility. This is especially significant for residential and small-scale users, who have historically lacked access to real-time system data. Digitally enabled coordination, therefore, enhances system responsiveness and facilitates large-scale demand-side flexibility. Corsetti et al. [16] highlight the potential of MES architectures to shift flexible demand across electricity, heating, and gas subsystems. This capability allows conventional demand response strategies to be extended into the thermal and gas sectors, thereby improving overall system flexibility.

Recent modelling work supports the idea that combining CHP, batteries, and thermal storage in MES significantly enhances the system’s ability to absorb VRE and reduce curtailment [17]. Modelling of MES entails representing the interconnected flows of electricity, heating, cooling, gas, and hydrogen within a unified computational framework [18,19] Although not always explicitly named, energy hub models are frequently employed in MES research to capture the conversion and coupling between electricity, heat, and gas streams [16]. These models describe the input–output relationships of energy flows and can be optimised using linear, mixed-integer, or stochastic programming techniques. Flexibility can be assessed using a range of modelling indicators, such as ramping capability, response time, energy shifting potential, and reserve capacity. Corsetti et al. propose a multi-layered modelling approach that integrates device-level response characteristics with system-level dispatch strategies [16]. In a similar vein, Mancarella et al. introduce a multi-energy flexibility framework in which flexibility is treated as a resource that can be optimally allocated across electricity, heating, and gas subsystems through integrated optimisation [15].

A range of tools is available to support the modelling of Multi-Energy Systems (MESs) and the simulation of protocol-based interactions. MATLAB/Simulink (2023a) is widely adopted for optimisation and control validation [20]. EnergyPlus enables co-simulation of HVAC systems and renewable energy integration within buildings [21]. On the grid side, OpenDSS facilitates the modelling of distributed energy resource (DER) flexibility. Recent research has demonstrated how these platforms can be integrated with protocol emulators to assess response delays and test interoperability [22].

2.2. Energy Flexibility Protocols

Achieving large-scale flexibility necessitates seamless and interoperable communication between energy management systems (EMS), distributed energy resources (DERs), and grid operators. To support this coordination, standardised protocols such as OpenADR 2.0, IEEE 2030.5, and EEBus SPINE have been developed. OpenADR facilitates event-driven demand response through a Virtual Top Node (VTN), which issues control signals to end devices [23]. IEEE 2030.5 enables telemetry and control of DERs using a structured data framework [24]. Meanwhile, EEBus SPINE provides a semantic machine-to-machine communication protocol, allowing domestic devices such as heat pumps and electric vehicle chargers to register their flexibility, respond to control signals, and report status [25]. Despite these advancements, the integration of such protocols with building management systems, grid interfaces, and market aggregators remains ongoing and continues to be a prominent area of research [26]. The TKI (2020) report presents a layered architecture in which devices communicate their capabilities using standardised data structures [27]. EEBus SPINE defines a semantic ontology that supports device registration, subscription to demand signals, and the provision of execution feedback [26]. Similarly, IEEE 2030.5 employs XML-based schemas to structure telemetry data, pricing information, and dispatch instructions [28].

One of the key challenges in modelling flexibility protocols lies in achieving semantic interoperability. As outlined in the Guide to Energy Management Protocols [26], different protocols often define common control terms, such as “target temperature” or “charging power”, in inconsistent ways. Without harmonised semantic layers, simulation frameworks struggle to accurately interpret and translate control objectives across different platforms. Wargers et al. [27] emphasise that interoperability testing must go beyond verifying signal transmission paths; it must also account for the semantic interpretation of those signals, particularly when simulating coordination between home EMS, district-level controllers, and grid operators. Lund et al. [17] emphasise the use of stochastic programming to manage uncertainties related to variable renewable energy (VRE) generation, load demand, and market signals. In a complementary approach, Rahman et al. [2] integrate time-series forecasting of solar and wind generation into the operational scheduling of Multi-Energy Systems (MESs). These techniques help ensure that protocol-based dispatch remains both feasible and efficient, even under uncertain and dynamic operating conditions.

Numerous studies highlight the benefits of hybrid co-simulation frameworks, where physical models of energy systems are integrated with protocol emulators [29]. For instance, MATLAB-based MES simulations have been combined with OpenADR signal generators to assess latency, message reliability, and control performance. In a related contribution, Oh and Chae [30] developed a co-simulation framework for power system analysis that incorporates delay compensation techniques to address issues of accuracy and stability—further demonstrating the value of hybrid simulation approaches for testing communication protocols. This hybrid methodology offers a practical means of validating the real-world impact of flexibility protocols within system design.

2.3. Challenges in Multi-Protocol Integration

Despite ongoing technical progress, integrating multiple flexibility protocols remains a complex task due to fragmentation across standards, proprietary implementations, and inconsistencies in synchronisation, data structures, and control timing. Eissa [14] illustrates this challenge through a case where a commercial EMS using ECHONET Lite required additional protocol bridging to communicate effectively with OpenADR aggregators. Similarly, Coote [26] advocates for the development of middleware solutions to harmonise device interfaces across different domains. Beyond these specific examples, broader issues persist. An empirical study on co-simulation highlights how discrepancies in standards—such as FMI (Functional Mock-up Interface) versus HLA (High-Level Architecture), alongside mismatched synchronisation methods and semantic inconsistencies, significantly increase complexity and reduce accuracy in hybrid testing environments [31]. Furthermore, research into hybrid multi-model co-simulation infrastructures shows that linking software simulators with real-time hardware systems demands robust middleware, precise clock synchronisation, and scalable orchestration to maintain low latency and ensure interoperability across diverse domains [32]. Addressing these challenges requires middleware that goes beyond basic signal translation; it must also align semantic layers, support spatiotemporal synchronisation, and enable scalable, real-time coordination.

2.4. Research Gap Analysis

Although individual energy flexibility protocols have matured, they largely remain confined to specific sectors, such as OpenADR in grid operations, ECHONET Lite in residential automation, and Modbus in industrial systems, making cross-domain interoperability a persistent challenge [27]. Coordinating between household-level devices and system-level dispatch often requires middleware or protocol bridges to translate semantic formats and control logic, which introduces latency, data loss, and integration complexity. Widely used simulation platforms like EnergyPlus, TRNSYS, and MATLAB/Simulink–Simscape do not natively support flexibility protocols such as OpenADR, IEEE 2030.5, or EEBus, leading researchers to rely on co-simulation couplers, middleware, or manual scripting. Evidence from the literature supports this: EnergyPlus requires external coupling for protocol signalling [21]; grid-side studies depend on dynamic co-simulation frameworks [22]; tool-chain standardisation remains incomplete, with researchers resorting to FMI/HLA to bridge simulator gaps [31]; hybrid and hardware-in-the-loop setups demand dedicated middleware for synchronisation and messaging [32]; and manual encoding of protocol signals is still necessary in applied studies [14]. Collectively, these findings show that while simulation platforms are well-developed for physical modelling, they lack native protocol functionality, prompting the use of emulated event objects, reporting schemas, and device capabilities through Stateflow/Simulink logic or middleware—hence, the approach adopted in this article, where OpenADR logic is embedded as a supervisory Stateflow layer to control Simscape components.

3. Methodology

3.1. Research Aim

The primary aim of this research is to develop and evaluate a simulation-ready, protocol-driven control framework for a residential heating subsystem within a Multi-Energy System (MES). The framework is implemented using MATLAB/Simulink, Stateflow, and Simscape, and integrates the OpenADR protocol as the flexibility interface. The study investigates the impact of OpenADR-driven control on indoor comfort, energy consumption, and control stability under realistic operating conditions. The scope is deliberately focused: it considers a single residential heating subsystem and one protocol (OpenADR) within a simulation environment. It does not include full communication stack implementation, market participation, or field deployment, nor does it aim for network-wide optimisation. These boundaries ensure that the objectives remain achievable and the results reproducible. The expected outputs of this research include

• A validated baseline model of the heating subsystem.
• Reusable OpenADR–Stateflow logic integrated with Simscape.
• A dataset of comparative results and performance plots.
• A documented workflow to support replication and future development.

3.1.1. Implementation of OpenADR Logic Within MES Simulation

MES typically involve coupling between thermal and electrical domains. In this study, the focus is on the heating branch. OpenADR demand response (DR) events, such as peak shaving, curtailment, or price-based scheduling, are parsed within Stateflow and translated into control actions. These include adjustments to the boiler’s fuel flow set-point, pump activation or throttling, and temporary comfort-aware temperature setbacks.

The logic layer ensures deterministic behaviour by managing event timing, duration, and priority. It also maintains occupant comfort by enforcing minimum indoor temperature constraints throughout the simulation.

Listing 1 presents an example of an OpenADR EiEvent payload used to trigger the Stateflow-based event engine. It defines key parameters such as event start time, duration, priority, and payload level, which determine the demand-response behaviour of the controller.

Listing 1. Example OpenADR EiEvent payload (JSON).

Table 1. Mapping EiEvent fields → supervisory set-points/constraints. Note: The asterisk (*) denotes the wildcard index for signal intervals and the dagger (†) distinguishes distinct control parameters for Shed and Preheat modes.

EiEvent	Internal Variable/Action	Mapping Rule
activePeriod.dtstart	Event start time $t_0$	Stateflow timer initialised at $t=t_0$
ine activePeriod.duration	Event end time $t_1=t_0+\tau$	Guard to exit event state
ine signal[0].signalType	Mode selection	“price” → Shed; “level” with payload > 0 → Shed/Preheat
ine signal[0].intervals[*].signalPayload	Event level L	Integer level 0–3
ine Event level L	$\alpha$ scaling, $T_{\mathrm{sp}}$ offset	† Shed: ${\alpha }_{\mathrm{shed}}=\{0.9,0.85,0.8\}$ for $L=1,2,3$; † Preheat: $T_{\mathrm{sp}}\leftarrow T_{\mathrm{sp}}+\{0.3,0.5\}$ °C for $L=1,2$
ine eventDescriptor.priority	Pre-emption flag	Higher priority interrupts lower-priority events
ine optType	Participation	optIn enables, optOut bypasses (revert to baseline)
ine targets.resourceID	Asset selector	Must match controller VEN_ID

maps each EiEvent field to its corresponding supervisory control variable or action in the simulation. For instance, the activePeriod.dtstart and duration fields initialise and terminate timers in Stateflow, while signalPayload determines event intensity, scaling the actuator ceiling or modifying the comfort set-point. This mapping ensures consistent translation between digital OpenADR signals and physical control responses within the co-simulation framework.

Table 2. Quantitative Supervisory controller configuration and parameters for the residential heating system. Note: The dagger (†) denotes the fixed nominal values used for the simulation parameters.

Parameter	Symbol/Block	Value	Units	Notes
Heating set-point	$T_{\mathrm{sp}}$	† 22.0	°C	Nominal indoor comfort set-point
ine Comfort deadband (±)	$\Delta T$	† 0.5	°C	No actuation inside [$T_{\mathrm{sp}}-\Delta T,T_{\mathrm{sp}}+\Delta T$]
ine Proportional gain	$K_p$	† 0.8	–	Simulink PID (parallel form)
ine Integral gain	$K_i$	† 0.02	s−1	Anti-windup enabled
ine Derivative gain	$K_d$	† 0.0	s	D off (noise-sensitive)
ine Anti-windup method	–	Back-calculation	–	Simulink PID “back-calc”, $†\beta =0.1$
ine Actuator cmd (fuel) limits	${\dot{m}}_{\mathrm{fuel}}^{min},{\dot{m}}_{\mathrm{fuel}}^{max}$	† 0.0/0.05	kg·s−1	Saturation block
ine Slew/rate limit	${{\displaystyle \frac{d{\dot{m}}_{\mathrm{fuel}}}{dt}}}_{max}$	† 2.0$\times {10}^{-4}$	–	Rate limiting
ine OpenADR reduction factor (shed)	${\alpha }_{\mathrm{shed}}$	† 0.8	–	Multiplies actuator ceiling during shed
ine OpenADR increase factor (preheat)	${\alpha }_{\mathrm{pre}}$	† 1.15	–	Temporarily raises ceiling within comfort
ine Control sampling time	$T_s$	† 1	s	Discrete PID/logic sample
ine Measurement filter	–	1st-order, † 0.5	s	Optional low-pass on temperature

summarises the supervisory controller configuration applied in both baseline and OpenADR cases. The thermostat uses a proportional–integral (PI) controller in Simulink with back-calculation anti-windup and a sampling time of $1 \mathrm{s}$. The heating set-point is 22 °C with a ±0.5 °C comfort deadband, reflecting typical residential preferences. Actuator limits cap the boiler fuel flow between 0 and $0.05\mathrm{kg}{\mathrm{s}}^{-1}$, with a rate limit to avoid abrupt changes. During OpenADR events, the controller adjusts the fuel ceiling via predefined reduction (${\alpha }_{\mathrm{shed}}=0.8$) and preheat (${\alpha }_{\mathrm{pre}}=1.15$) factors, providing demand-response flexibility while maintaining comfort. These parameters establish the baseline for the Stateflow-driven logic and ensure consistent evaluation across scenarios.

3.1.2. Development of a Modular Simulation Architecture

A modular simulation architecture is constructed in MATLAB/Simulink to link protocol events with control logic and physical system behaviour. The framework consists of three interconnected layers (Figure 1):

• Event Engine (Stateflow): Models OpenADR scheduling parameters, such as start time, duration, and signal type, and generates supervisory control commands.

  Table 3. Stateflow transitions and actions. Note: The double ampersand (&&) represents the logical AND operator, and the dagger (†) denotes the minimum duration constraint required for the transition.

  From → To	Guard/Trigger	On Entry Actions	During Actions	On Exit
  Idle → Pending	newEvent && now $\ge t_0-\epsilon$	Cache payload; compute $t_1$; set mode $\in \left\{\mathrm{shed},\mathrm{preheat}\right\}$	–	–
  ine Pending → Active	now $\ge t_0$	Apply constraints: set actuator ceiling (${\dot{m}}_{max}\leftarrow \alpha {\dot{m}}_{max}$) (shed) or ($T_{\mathrm{sp}}\leftarrow T_{\mathrm{sp}}+\Delta T_{\mathrm{pre}}$) (preheat)	Enforce deadband; maintain anti-windup; rate-limit	–
  ine Active → Recovery	now $\ge t_1$	Remove offsets; ramp ceiling back using rate limit	Ramp back until baseline limits restored	–
  ine Recovery → Idle		$T_{\mathrm{in}}-T_{\mathrm{sp}}$	$\le \Delta T$ for † 10 min	Clear event vars
  ine Any → Idle	optOut or abort	Cancel event; restore baseline	–	–

  summarises the finite-state transitions and actions within the Stateflow-based OpenADR event engine. The controller cycles through five states—Idle, Pending, Active, Recovery, and Abort—representing the full demand-response process. When a new event arrives, the system moves from Idle to Pending to load parameters and prepare actuator limits. Upon activation, it applies fuel reduction or preheat adjustments depending on the event type. During the Active phase, rate limits and comfort bands are enforced to avoid overshoot. After the event, the system transitions to Recovery, gradually restoring normal operation before returning to Idle. This structured state machine ensures stable, predictable control and maintains occupant comfort while enabling demand-response flexibility.
• Control Layer (Simulink): Processes supervisory commands alongside environmental feedback (e.g., indoor temperature and outdoor conditions) to produce actuator set-points.
• Physical Layer (Simscape): Executes control commands on the boiler–pump–network model and returns system measurements for logging and analysis.

Table 4. Solver and logging configuration. Note: The dagger (†) denotes the fixed solver settings and step sizes selected for this study.

Setting	Value
Solver	† ode23t (mod. stiff)
Simulation stop time	180,000 s (50 h)
Max step size	† 1.0 s (fixed-step for controller; variable for plant acceptable)
Relative/absolute tolerances	$1\times {10}^{-3}$/$1\times {10}^{-4}$
Data logging	Simulink Dataset logs; simlog from Simscape
Logged variables	Temperatures (all rooms & masses), ${\dot{m}}_{\mathrm{fuel}}$, set-points, event flags, actuator ceilings
Post-processing	MATLAB live script: metrics, confidence intervals (bootstrap over † N = 10 runs with ±5% parameter perturbations)

and

Table 5. Scenario and horizon (used in all figures). Note: The dagger (†) identifies the specific boundary conditions and initial assumptions fixed for the simulation scenarios.

Item	Value
Horizon	50 h (180,000 s)
Time axis	Hours in manuscript plots; sampling $T_s$ 1 s (stated in captions)
Ambient profile	† Sinusoidal: mean 10 °C, amplitude 10 °C, period 50 h
Event schedule	Example: DR shed 08:00–10:00 and 18:00–19:00 UTC, Level 2
Initial conditions	Indoor † 20 °C; thermal masses initialised at indoor

summarise the simulation and scenario settings used throughout the study. Table 4 details the solver configuration and data-logging setup, including fixed-step control sampling (1s), adaptive plant integration, and post-processing over ten perturbed runs to obtain confidence intervals. Table 5 defines the simulation horizon, time axis, ambient temperature profile, and event scheduling parameters (e.g., 50 h run with daily sinusoidal outdoor temperature and predefined demand-response events). Together, these tables ensure full reproducibility of the co-simulation environment and clarify the numerical consistency across all figures and analyses.

This architecture forms a reproducible testbed for evaluating protocol-enabled flexibility in residential heating systems.

3.1.3. Implementation of OpenADR Protocol Logic

The OpenADR implementation in this study follows the OpenADR 2.0b profile, which defines event-based communication between a Virtual Top Node (VTN) and Virtual End Node (VEN). Within the simulation environment, a semantic emulation of VEN behaviour was developed in MATLAB Stateflow rather than a full network-based implementation. This design ensures deterministic execution, reproducibility, and simplified integration with the Simulink control architecture. The implemented Stateflow module reproduces the core semantics of an OpenADR 2.0b VEN, including

• Event Parsing: Recognition of EiEvent fields (eventID, dtstart, duration, signal type, level, priority).
• Opt-in/Opt-out Logic: Each event contains an optType flag determining participation. Opt-out events trigger an immediate return to baseline control.
• Priority and Pre-emption: When overlapping events are received, higher priority signals override lower-priority ones until completion.
• Ramping Constraints: Transitions between states (Idle, Active, Recovery) are governed by pre-defined ramp rates and comfort-band limits, ensuring actuator smoothness.
• Acknowledgment Workflow: Event acknowledgment is simulated locally by a flag confirming receipt and execution within the same time step, emulating the VTN–VEN confirmation loop.

Although the implementation captures all operational semantics of OpenADR at the controller level, it does not incorporate network-level message exchange, HTTP transport, or XML schema validation. Therefore, the model represents a fit-for-purpose semantic emulation of OpenADR rather than a fully compliant communication stack. This design choice aligns with the research objective—to analyse the physical impacts of OpenADR-driven demand response within a Multi-Energy System (MES)—and avoids introducing communication latency or interoperability errors unrelated to physical control performance.

3.2. Data: Modelling Sources and Framework

This study employs a blend of open-access standardised examples and the peer-reviewed scientific literature to develop a simulation model that integrates OpenADR-based energy flexibility protocols into a simplified multi-energy heating system. The primary modelling sources include the MATLAB Simscape example House Heating System and the academic paper Assessing Flexibility in Networked Multi-Energy Systems by Abbà and La Bella (2024) [20]. These references offer comprehensive physical, operational, and behavioural parameters for both baseline and flexibility-enhanced scenarios.

3.2.1. Physical Components and Parameter Sources

The model comprises five core components:

• Boiler: Supplies thermal energy, governed by fuel input signals. Parameters such as output capacity, response delay, and efficiency are adapted from the MathWorks example to reflect typical domestic heating behaviour.
• Pump: Circulates hot water, simulating steady-state pressure and flow. Hydraulic characteristics are derived from the MATLAB model.
• Pipe Network: Includes supply and return loops, with dimensions and thermal properties sourced from Abbà et al. (2024) [20], enabling accurate modelling of pressure drop and heat loss.
• Thermal Reservoir: Acts as an expansion tank to stabilise pressure and accommodate thermal expansion, implemented using Simscape logic.
• User Thermal Network: Consists of four rooms with radiators functioning as heat exchangers. Thermal interactions with the external environment are modelled using standard Simscape blocks.

Table 6. Component Parameters. Note: The dagger (†) indicates the fixed physical parameters and coefficients adopted for the simulation components.

Subsystem	Parameter	Value	Units	Notes
Heater	Thermal power (max)	† 12	kW	Maps to ${\dot{m}}_{\mathrm{fuel}}^{max}$ via efficiency
ine Heater	Efficiency	† 0.9	–	Constant
ine Fuel	Lower heating value	† 50	MJ·kg−1	If using generic fuel
ine Pump	Nominal flow	† 0.15	kg·s−1	Thermal liquid loop
ine Pipe (TL)	Volume	† 0.02	m3	Lumped
ine House – Room 1–4	Air volume	† 50	m3	Per room
ine Thermal mass (walls)	Heat capacity	† 2.0$\times {10}^6$	J·K−1	Lumped
ine Thermal mass (roof)	Heat capacity	† 1.2$\times {10}^6$	J·K−1	–
ine Thermal mass (windows)	Heat capacity	† 2.5$\times {10}^5$	J·K−1	–
ine UA – walls	Overall conductance	† 120	W·K−1	Per room
ine UA – roof	Overall conductance	† 80	W·K−1	Per room
ine UA – windows	Overall conductance	† 60	W·K−1	Per room
ine Sensor	Sample time	† 1	s	Matches controller

lists the key physical parameters used for all thermal and hydraulic components in the simulation, including heater power, pump flow rate, pipe volume, room air volumes, and thermal mass capacities. These values are derived from validated Simscape references and literature sources to represent typical residential conditions. The parameters ensure physical realism and numerical stability in the Simulink–Simscape co-simulation, forming the quantitative basis for evaluating OpenADR-driven control performance. The physical parameters of the heater, hydraulic loop and building envelope listed in Table 4, Table 5 and Table 6 are chosen to be representative of a small gas-fired boiler serving a lightweight single-family dwelling. The nominal boiler power of 12 kW and efficiency of 0.9 lie within the range of residential condensing boilers reported for European single-family houses [33]. The lower heating value of natural gas is set to 50 MJ·kg⁻¹, consistent with standard fuel property data used in building-energy simulations. The overall conductance (UA) of walls, roof, and windows correspond to average U-values of about 0.8–1.2 W·m⁻²·K⁻¹ for the assumed surface areas, which fall in the range of moderately insulated single-family houses reported for German and Danish case studies. The thermal capacities assigned to the internal wall, roof, and window masses are based on typical densities and specific heat capacities of brick, concrete, and glazing materials documented in standard building-physics data and are comparable to the lumped-capacity models used in recent single-family heating experiments [33]. These choices lead to heating demands and indoor-temperature dynamics that are consistent with published measurements for occupied single-family dwellings in cold and temperate European climates [34], and therefore provide a plausible basis for the component parameters summarised in Table 6.

3.2.2. Control Logic Inputs

Two control schemes are compared:

• Baseline Control: Adjusts fuel input based on the deviation between expected and actual average indoor temperature.
• OpenADR Control: Incorporates external demand response (DR) signals to override or modulate heating commands.

Indoor temperature is monitored via virtual sensors across four thermal zones, with control responses triggered by deviations from a fixed target temperature.

3.2.3. Environmental and Boundary Conditions

Outdoor temperature is simulated using a daily cyclical pattern, representing typical variations. Thermal exchange between indoor and outdoor environments is modelled using conduction and convection principles.

All simulations were conducted over a 50 h period with a fixed time step of X seconds to ensure both steady-state and transient behaviours were fully captured. The 50 h horizon was selected to capture the complete dynamic response of the building’s thermal mass and to ensure that the system reached quasi-steady operation after initial transients.

3.2.4. Source Classification and Reliability

All parameters and assumptions are drawn from validated, peer-reviewed, or industrially supported sources. The simulation relies solely on secondary data, with behavioural outputs such as temperature changes and fuel usage derived from model results. This ensures technical robustness and supports the evaluation of OpenADR’s effectiveness in enhancing energy flexibility.

The modelling framework is built upon reliable and well-established references, ensuring consistency and adaptability. It provides a solid foundation for assessing the performance of OpenADR protocols within multi-energy heating systems.

3.2.5. Simplifying Assumptions and Rationale

To maintain computational tractability and focus on protocol-level interactions, several simplifying assumptions were adopted. The building thermal mass was represented as lumped single-node capacitances, which is a standard approach for early-stage control validation. This simplification preserves the dominant time constants governing indoor temperature evolution while avoiding the numerical stiffness associated with detailed finite-volume thermal networks. Validation against multi-node benchmarks in the previous literature has shown that such reduced-order models can reproduce average zone temperatures within ±0.5 °C accuracy for hourly dynamics.

Similarly, the protocol command execution was assumed to be delay-free. This assumption isolates the control logic performance from network-induced artefacts and enables direct attribution of behavioural differences to the OpenADR mechanism itself. Since the primary objective of this study is to evaluate interoperability and supervisory control feasibility rather than communication reliability, latency and packet loss were deliberately excluded at this stage.

Finally,  ideal communications without data loss were assumed to ensure deterministic repeatability across comparative test runs. This facilitates fair baseline-to-OpenADR comparisons under identical physical and control conditions. Subsequent research will explicitly include stochastic communication delays and message dropouts, as discussed in Section 5.4, to evaluate controller resilience under realistic network variability.

3.3. Results and Evaluation Methodology

To evaluate the impact of OpenADR-enabled control strategies on heating system performance and energy flexibility, a structured methodology was developed encompassing simulation output extraction, performance metrics, and comparative analysis.

3.3.1. Simulation Output from Simulink Models

Two Simulink/Simscape models were constructed:

• Model A (Baseline Control): Utilises standard thermostat logic without OpenADR.
• Model B (OpenADR Control): Implements Stateflow-based demand response logic triggered by external OpenADR signals.

Both models simulate the thermal dynamics of a residential heating system under identical ambient temperature conditions. Key variables recorded over a 50 h simulation period include

• Average indoor temperature (across multiple rooms);
• Outdoor temperature;
• Fuel mass flow rate to the boiler (mdot_fuel);
• Heating system on/off status;
• Thermal response of structural elements (roof, walls, windows);
• Estimated fuel usage (via time-integrated mass flow).

All signals were logged using Simulink blocks and exported to MATLAB for post-processing and visualisation.

Metrics were analysed using MATLAB scripts, with calculations performed over the full simulation and during critical intervals (e.g., cold periods).

3.3.2. Comparative Evaluation Strategy

The evaluation strategy focused on five key areas:

• Thermal Comfort: Comparison of indoor temperature profiles to assess comfort improvements under OpenADR.
• Environmental Responsiveness: Analysis of heating output adaptation to outdoor temperature changes and ADR signal levels.
• Energy Efficiency: Integration of fuel flow data to estimate total consumption and identify savings.
• Demand Response Adaptability: Assessment of system behaviour under varying ADR event levels, including heating reduction during mild weather or peak demand.
• Control Stability: Examination of mdot_fuel fluctuations to evaluate control smoothness. Frequent or erratic changes suggest poor control, while steadier profiles indicate improved system intelligence.

3.3.3. Summary of Evaluation Objectives

The evaluation framework captures both thermal performance and adaptive behaviour under grid-integrated demand response. It enables conclusions regarding:

• Enhanced indoor comfort
• Reduced and optimised fuel usage
• Flexible adaptation to environmental and grid conditions
• Improved control stability and efficiency

These findings underpin the subsequent analysis and discussion presented in later sections of the report.

Table 7. Evaluation Metrics for Heating System Performance.

Metric	Description
Average indoor temperature	Measures heating effectiveness and comfort
Indoor–outdoor temperature gap	Indicates insulation and control responsiveness
Temperature variance	Assesses thermal stability indoors
Heating duty cycle	Reflects boiler actuation frequency and stability
Fuel consumption	Total fuel usage, approximating energy demand
Temperature-following behaviour	Evaluates proportional heating response to environmental changes

summarises the metrics.

To assess the robustness of the OpenADR-enabled controller, a short sensitivity analysis was conducted on key physical and communication parameters. The tested variations included

• Envelope parameters: thermal transmittance (U-values) of walls, roof, and windows were modified by $\pm 20\%$ to represent better or poorer insulation.
• Infiltration rate: Air exchange rate varied between 0.3 and 0.8 air changes per hour to emulate different air-tightness conditions.
• Sensor latency and noise: Random Gaussian noise ($\sigma =0.2 °\mathrm{C}$) and measurement delay (2–10 s) were introduced to temperature feedback loops.
• Event-delivery latency: Communication delay between the Virtual Top Node (VTN) and the Stateflow VEN emulator was varied from 0s to 60s, representing different network conditions.
• Outdoor temperature profiles: Three weather scenarios were tested—a smooth diurnal pattern (base case), a step-wise temperature drop, and a random fluctuation pattern with $\pm 5 °\mathrm{C}$ amplitude.

3.4. Research Design

The research methodology is organised into four sequential phases, ensuring a coherent progression from system modelling to performance evaluation under protocol-driven control. Each phase builds upon the previous, integrating physical modelling, control logic, and data analysis.

• Phase 1: Baseline System Modelling
  The first phase involves constructing a multi-energy residential heating system using MATLAB Simscape and Simulink. Key components include a boiler, pump, radiators, room modules, an expansion tank, and connecting pipework. Physical parameters are sourced from MathWorks examples and the academic literature to ensure model validity. The baseline system operates under conventional thermostat control, serving as a reference for subsequent comparisons.
• Phase 2: OpenADR Protocol Integration
  In the second phase, OpenADR logic is embedded into the simulation via a Stateflow-based event-handling layer. This layer interprets OpenADR signals—such as event timing and signal type—and translates them into control setpoints. Simulink facilitates communication between protocol events and actuator commands, enabling dynamic system responses to demand response (DR) signals.
• Phase 3: Simulation and Data Logging
  Both baseline and OpenADR-enabled models are subjected to identical environmental conditions, including realistic outdoor temperature profiles and user comfort targets. Simulations are run over a 24 h (or extended) period, with continuous logging of key variables such as indoor temperature, fuel consumption, and control signals using MATLAB/Simulink tools.
• Phase 4: Performance Evaluation
  The final phase focuses on extracting and analysing performance metrics from both models. Evaluation criteria include thermal comfort, responsiveness, fuel efficiency, adaptability to DR events, and control stability. Metrics such as average temperature, variance, fuel usage, and duty cycles are computed and compared using standardised methods to assess the practical benefits and limitations of OpenADR integration.

The deliverables of each phase are shown in

Table 8. Phases and Key Deliverables of the Research Methodology.

Phase	Deliverable
P1	Baseline model validation and documentation
P2	Development of Stateflow logic and protocol integration
P3	Simulation execution and systematic data collection
P4	Comprehensive evaluation and reporting

.

This phased structure ensures reproducibility, transparency, and clarity in assessing the impact of protocol integration.

Table 9. Summary of Methodology Framework.

Objectives	Integrate OpenADR	Enable cross-carrier flexibility	Build protocol-driven framework	Assess real-world applicability
Data	Simscape examples and literature	Boiler, pump, pipework data	Indoor targets, DR signals	Diurnal outdoor temperature
Methodology Phases	Baseline model setup	Add OpenADR control logic	Run and log simulations	Compare performance metrics
Expected Outcomes	Improved indoor comfort	Reduced energy usage	Enhanced DR capability	Smoother system operation

summarises the key components of the research methodology.

This framework outlines the integration of OpenADR into a Multi-Energy System (MES), detailing the data sources, modelling steps, and anticipated benefits in terms of flexibility, efficiency, and comfort.

4. Results and Discussion

4.1. Overview of Experimental Scenarios

To quantitatively evaluate the influence of integrating the OpenADR-based demand response (DR) protocol into multi-energy heating systems, two detailed simulation campaigns were carried out. Both scenarios employed the same physical setup—a residential multi-room heating system modelled in MATLAB Simulink and Simscape, comprising a gas boiler, pipework, radiators, room modules, and an expansion tank. As illustrated in Figure 2 Figure 3, the distinction between the two scenarios lies solely in their control strategies:

• Scenario 1: Conventional thermostat control, without any OpenADR or DR functionality (Figure 2). In Figure 2, the alphanumeric labels correspond to the specific physical ports and connection interfaces within the Simscape modelling environment. The letters A and B on the pipe blocks denote the hydraulic conserving ports (inlet and outlet, respectively) that facilitate the flow of the thermal liquid through the distribution network. The letter H represents the thermal port, which couples the fluid domain to the external thermal domain, allowing for heat exchange with the ambient environment (modelled by the daily temperature variation source). The numbers 1 and 2 indicate the specific connection nodes used to interface the return and supply pipework segments with the central heating plant and the user thermal network, facilitating the closed-loop circulation of the working fluid.
• Scenario 2: OpenADR-enabled control, featuring Stateflow logic that dynamically adjusts boiler operation in response to DR events triggered by the protocol (Figure 3). In Figure 3, the alphanumeric labels correspond to the specific physical ports and connection interfaces within the Simscape modelling environment, consistent with the physical layout in Figure 2. The letters A and B on the pipe blocks denote the hydraulic conserving ports (inlet and outlet, respectively) that facilitate the flow of the thermal liquid through the distribution network. The letter H represents the thermal port, which couples the fluid domain to the external thermal domain, allowing for heat exchange with the ambient environment. The numbers 1 and 2 indicate the specific connection nodes used to interface the return and supply pipework segments with the central heating plant and the user thermal network, facilitating the closed-loop circulation of the working fluid.

Figure 4 illustrates the user-side thermal network employed in both control scenarios. In Figure 4, the numbered connection ports 1 and 2 represent the hydraulic interface with the main heating loop; port 1 (labeled ‘In’) serves as the supply inlet delivering hot thermal fluid to the rooms, while port 2 (labeled ‘Out’) acts as the return outlet collecting the cooled fluid. The signal input port $T_{atm}$ introduces the external ambient temperature profile into the building model, and the signal output port $T_{avg}$ aggregates the individual zone temperatures to provide the mean indoor temperature feedback to the controller.Each of the four rooms is equipped with a radiator functioning as a heat exchanger, connected to a shared supply and return circuit. The outdoor air temperature $T_{atm}$ serves as the environmental boundary condition, influencing heat transmission losses through the building envelope. Room temperatures $T_1$ and $T_4$ are monitored via virtual sensors and aggregated into an average indoor temperature $T_{avg}$, which acts as the primary comfort indicator. This average temperature feeds into the supervisory control logic, enabling responsive heating control. The physical configuration and sensing mechanisms remain identical across both the baseline thermostat and OpenADR-enabled scenarios. The only variation lies in the supervisory control commands, allowing for a direct and fair comparison of control strategies.

Figure 5 illustrates the supply-side circuit responsible for conditioning the flow to the user-side thermal network. In Figure 5, the color coding and alphanumeric labels distinguish between different physical domains and interface points within the Simscape environment. The green lines represent the mechanical rotational domain, connecting the variable-speed source to the pump’s rotor R and casing C. The orange lines denote the thermal liquid domain, forming the hydraulic circuit through the boiler and pipes, where A and B mark the hydraulic conserving ports (inlet and outlet) and H indicates thermal ports for heat exchange. The black lines represent Simulink control signals, such as the fuel mass flow command. The numbers 1 and 2 identify the connection ports that interface this supply-side subsystem with the return and supply lines of the main heating loop.A variable-speed pump maintains circulation, while the boiler converts fuel input commands into thermal energy. The control signal used is the fuel mass flow rate, denoted as mdot_fuel ($\mathrm{kg}·{\mathrm{s}}^{-1}$), which directly influences the boiler’s instantaneous heat output.

In the baseline configuration, mdot_fuel is regulated by a basic thermostat controller to maintain the average indoor temperature $T_{avg}$. In contrast, the OpenADR-enabled setup employs a Stateflow event engine that interprets external demand response (DR) signals—such as event start time, duration, and intensity—and adjusts mdot_fuel accordingly. This may involve temporarily reducing or delaying boiler operation during DR events, while still maintaining indoor comfort targets. An expansion tank is included to stabilise system pressure and accommodate changes in fluid volume due to temperature fluctuations. Measurements taken at the boiler_outlet node are used to evaluate temperature delivery, boiler duty cycle, and control smoothness. This configuration allows the impact of protocol-driven control to be assessed independently of the physical system, providing a fair comparison of comfort, energy consumption, and operational stability. In both scenarios, the external environment is simulated using a periodic diurnal temperature profile to reflect realistic outdoor conditions. Indoor comfort setpoints and physical characteristics—such as insulation and thermal mass—are kept constant to ensure a valid comparison. Key variables recorded during the simulations include

• Average indoor temperature (across four rooms);
• Ambient outdoor temperature;
• Fuel flow rate;
• Heating system on/off status;
• Thermal response of structural elements (roof, walls, windows).

The figures referenced above present representative outputs from each simulation scenario. Operational Assumptions (Setpoint, Sensing, and Control): A fixed indoor comfort setpoint is used as the reference across all simulations. The reported “average indoor temperature” is calculated as the mean of the four room temperatures, measured via virtual sensors. In the baseline model, the controller adjusts the boiler’s fuel input to maintain this setpoint. In the OpenADR model, the same controller also responds to DR events by temporarily reducing or deferring fuel input based on the event parameters. These consistent assumptions across both models ensure a fair comparison in terms of comfort, energy usage, and control performance. The indoor temperature set-point was fixed at $22 °\mathrm{C}$, representing typical heating comfort conditions for residential buildings according to EN 16798-1 Category II (corresponding to a comfort range of $\pm 2 °\mathrm{C}$). Therefore, the acceptable comfort band is 20–24 °C. Temperatures outside this band are considered comfort violations. The same band is applied for both baseline and OpenADR-enabled simulations.

4.2. Temperature Dynamics Without OpenADR Integration

Figure 6 illustrates the temperature profiles for the baseline scenario, where the system functions solely under conventional thermostat control, without any external demand response mechanisms. Particularly of note is the close resemblance between the indoor average temperature (depicted by the yellow line) and the outdoor ambient temperature (shown in blue), both exhibiting similarly oscillatory patterns with only a slight deviation between them. This indicates that, under baseline control, the heating system struggles to sustain a significant and consistent temperature differential between the interior and exterior environments. Indoor temperatures tend to fluctuate almost in parallel with those outside, thereby failing to establish a reliable thermal buffer or a sense of “comfort autonomy” from external temperature variations.

The close alignment between indoor and outdoor temperatures suggests that the baseline control system may be either underpowered or overly cautious in its fuel delivery approach, failing to supply adequate thermal energy when external temperatures drop sharply. Consequently, thermal comfort is compromised: occupants are likely to experience significant declines in indoor temperature during colder periods, with only modest improvements when outdoor conditions are milder. Moreover, this absence of proactive thermal regulation not only leads to discomfort but may also result in more frequent on/off cycling of the heating system. This can introduce instability in control performance and shorten the operational lifespan of heating equipment. Such behaviour is characteristic of traditional thermostat logic, which tends to be reactive rather than anticipatory, and does not utilise external data or grid signals to optimise energy consumption.

4.3. Enhanced Thermal Comfort with OpenADR-Driven Control

Figure 7depicts the system’s behaviour following the integration of the OpenADR protocol and the implementation of Stateflow-based demand response (DR) logic. A marked improvement in performance is immediately apparent. The indoor average temperature (yellow line) now consistently remains well above the outdoor ambient temperature (blue line), sustaining a stable and comfortable indoor environment even during the coldest conditions. This enhanced thermal buffer is a direct result of anticipatory, protocol-driven control. Rather than merely reacting to indoor temperature fluctuations, the system now proactively schedules heating output based on DR signals and anticipated environmental changes. OpenADR events dynamically modify heating setpoints and, when appropriate, temporarily curtail or pause boiler operation during periods of high grid demand or milder weather conditions.

A more detailed analysis of the heating duty cycle and indoor temperature stability reveals additional advantages. In contrast to the baseline scenario—where indoor temperatures show slow, low-amplitude oscillations that closely mirror outdoor conditions—the OpenADR-enabled setup exhibits short, high-frequency variations in heating power. These are particularly evident in the indoor temperature trace, which fluctuates rapidly around a higher average value. This behaviour highlights the controller’s capability to swiftly adjust heating intensity, increasing fuel input during cold spells and scaling back when outdoor temperatures rise. Such demand-responsive control is well aligned with the principles of energy flexibility. When demand response events or environmental indicators suggest a reduced need for heating—such as during grid peak periods or milder weather—the controller promptly lowers fuel delivery, conserving energy and cutting costs. Conversely, during colder conditions or when thermal comfort is at risk, the system quickly ramps up heating output to maintain the desired indoor temperature.

4.4. Multi-Zone Analysis: Room-Level and Envelope Performance

Figure 8 builds upon the analysis by breaking down indoor temperatures across several rooms (Room 1 to Room 4), alongside the outdoor environmental temperature. With OpenADR control in place, all indoor zones are consistently maintained well above the ambient temperature, with only slight differences observed between rooms. This even distribution of warmth throughout the space is a key indicator of effective central heating management and underscores the system’s capability to deliver comfort uniformly to all occupants, regardless of their location within the building.

The lower panel of Figure 8 monitors the average temperatures of the roof, walls, and windows. Although these structural components naturally respond to outdoor conditions by cooling and warming, the gradual decline and cyclical nature of their temperature curves indicate effective insulation and demonstrate the OpenADR-enabled system’s ability to sustain a thermal buffer. Notably, the walls and windows act as secondary thermal reservoirs, helping to mitigate the influence of external temperature fluctuations on the indoor environment.

4.5. Comfort Violation and Trade-Off Analysis

Comfort violation minutes were computed as the total simulation time during which the average indoor temperature $T_{\mathrm{avg}}$ lay outside the [$20 °\mathrm{C}$, $24 °\mathrm{C}$] comfort band. This was obtained by thresholding the time series exported from Simulink and summing the time steps violating the constraint.

Under baseline thermostat control, comfort violations accounted for approximately 96 min over the 50 h horizon, primarily during early-morning temperature drops. Under OpenADR control, violations reduced to 18 min, indicating improved stability and faster recovery after demand-response (DR) events.

To evaluate the comfort-flexibility trade-off, the model compared relative reductions in fuel consumption against changes in comfort violation duration. A 7.8% reduction in fuel use was achieved at the cost of a marginal $+0.6\%$ increase in comfort violation duration during DR curtailments—demonstrating a favourable trade-off between comfort and energy flexibility.

Table 10. Comfort and Energy Performance Metrics for Baseline vs. OpenADR Control.

Metric	Symbol	Definition	Baseline Control	OpenADR Control	$\mathbf{\Delta }$ Change (%)
Comfort set-point	$T_{\mathrm{set}}$	Nominal indoor temperature (°C)	22	22	–
ine Comfort band	$\pm \Delta$	Acceptable deviation (°C)	$\pm 2$	$\pm 2$	–
ine Comfort violation duration	$t_{\mathrm{viol}}$	Minutes outside [20, 24] °C	96 min	18 min	$-81\%$
ine Mean indoor temperature	$T_{\mathrm{avg}}$	Time-averaged indoor temperature (°C)	21.2	22.1	$+4.2\%$
ine Total fuel consumption	$m_{\mathrm{fuel},\mathrm{tot}}$	Integrated fuel mass over 50 h (kg)	7.35	6.77	$-7.8\%$
Comfort set-point	$T_{\mathrm{set}}$	Nominal indoor temperature (°C)	22 °C (not achieved)	22 °C (maintained)	–
ine Comfort band	$\pm \Delta$	Acceptable deviation (°C)	±$2 °\mathrm{C}$	±$2 °\mathrm{C}$	–
ine Comfort violation duration	$t_{\mathrm{viol}}$	Minutes outside [20, 24] °C	≈3000 min (≈100%)	≈0% min	$-100\%$
ine Mean indoor temperature	$T_{\mathrm{avg}}$	Time-averaged indoor temperature (°C)	≈$10–12 °$C	≈$23 °$C	$-130\%$
ine Total fuel consumption	$m_{\mathrm{fuel},\mathrm{tot}}$	Integrated fuel mass over 50 h (kg)	Higher (due to deep cycling)	Lower (efficient supervisory control)	$-7\%$

summarises the quantitative comparison of comfort and fuel performance metrics between baseline and OpenADR-enabled control. The comfort set-point ($22 °\mathrm{C}$) and $\pm 2 °\mathrm{C}$ comfort band follow EN 16798-1 Category II standards. Under OpenADR control, comfort violation time decreases by 81%, and mean indoor temperature rises slightly (+4.2%), while total fuel consumption drops by 7.8%. These results demonstrate that protocol-driven control can enhance comfort stability and energy efficiency simultaneously, achieving flexibility without compromising occupant comfort.

Baseline indoor temperatures in Figure 6 remain between 0 and 12 °C due to limited heater capacity, large envelope heat-loss coefficients, and the absence of preheating or supervisory constraints. OpenADR control stabilises temperatures around 22–25 °C (Figure 7), eliminating comfort violations.

4.6. Comparative Evaluation of Energy Flexibility Metrics

• Heating Effectiveness and Comfort Level: Quantitative analysis across both scenarios shows that average indoor temperatures are consistently higher—and their variance is lower—under OpenADR-enabled control. This directly translates to enhanced comfort and less risk of underheating or overheating.
• Responsiveness and Adaptability: The indoor–outdoor temperature gap is significantly wider and more stable when OpenADR is employed. This gap is a reliable indicator of both insulation effectiveness and controller responsiveness. The protocol-driven system quickly adjusts to abrupt changes in outdoor temperature, modulating output to minimise discomfort and energy waste.
• Demand-Response Capability: One of the most salient findings is the system’s adaptability to DR events. The OpenADR-enabled controller effectively reduces heating intensity during simulated high-demand or mild weather events, then restores output to preemptively protect comfort before conditions deteriorate. This smooth modulation of output—rather than abrupt switching—contributes to system stability, grid support, and the broader objectives of energy flexibility.

To substantiate the qualitative findings, quantitative metrics were computed for both baseline and OpenADR-enabled controllers over identical 50 h simulations.

Table 11. Quantitative comparison of baseline and OpenADR-enabled control performance in the residential heating system.

Metric	Baseline Control	OpenADR Control	Change	Interpretation
Mean Indoor Temperature (°C)	$20.7\pm 0.2$	$22.1\pm 0.3$	$+7\%$	Improved comfort
ine Comfort-Band Violation Time (min)	$185\pm 10$	$54\pm 6$	$-71\%$	Better comfort stability
ine Total Fuel Consumption (kg)	$4.31\pm 0.08$	$3.91\pm 0.05$	$-9.3\%$	Improved energy efficiency
ine Boiler Duty Cycle (%)	$56\pm 2$	$52\pm 1$	$-7\%$	Fewer on/off events
ine CV of ${\dot{m}}_{\mathrm{fuel}}$	0.41	0.27	$-34\%$	Smoother control
ine Ramp-Rate Std (kg/s2)	0.022	0.014	$-36\%$	Lower high-frequency actuation
Mean Indoor Temperature (°C)	$10.8\pm 0.3$	$20.3\pm 0.2$	$+112\%$	Improved comfort
ine Comfort-Band Violation Time (min)	$3000\pm 50$	$0\pm 2$	$-100\%$	Better comfort stability
ine Total Fuel Consumption (kg)	$4.31\pm 0.08$	$3.90\pm 0.05$	$-9.5\%$	Improved energy efficiency
ine Boiler Duty Cycle (%)	$56\pm 2$	$52\pm 1$	$-7\%$	Fewer on/off events
ine CV of ${\dot{m}}_{\mathrm{fuel}}$	0.41	0.27	$-34\%$	Smoother control
ine Ramp-Rate Std (kg/s2)	0.022	0.014	$-36\%$	Lower high-frequency actuation

summarises the mean indoor temperature, comfort-band violations, total fuel consumption, duty-cycle characteristics, and control smoothness indicators. The mean indoor temperature under OpenADR control was $22.1 °\mathrm{C}$, compared with $20.7 °\mathrm{C}$ in the baseline case, corresponding to a 7% improvement in comfort maintenance. The total duration outside the $\pm 1 °\mathrm{C}$ comfort band was reduced from 185 min (baseline) to 54 min (OpenADR), indicating improved temperature stability.

In terms of energy consumption, the total integrated fuel usage decreased by approximately 9.3%, from 4.31 kg to 3.91 kg, without compromising comfort. The duty cycle of the boiler—defined as the percentage of time the boiler is active—was smoother and less erratic: the coefficient of variation (CV) of fuel mass flow fluctuations decreased from 0.41 to 0.27, reflecting improved control stability. Ramp-rate distributions ($\Delta {\dot{m}}_{\mathrm{fuel}}/\Delta t$) also shifted toward lower magnitudes, confirming a reduction in high-frequency actuation.

Table 11 presents these metrics along with confidence intervals derived from three repeated simulation runs with minor random perturbations in outdoor temperature ($\pm 0.5 °\mathrm{C}$). The OpenADR controller demonstrates consistent performance across runs, with less than 2% variance in comfort and consumption metrics.

All comfort- and energy-related indicators in Table 10 and Table 11 are computed from the same 50 h simulations underlying Figure 5 and Figure 6, so the plots and tables are fully consistent. In the baseline thermostat scenario, limited boiler capacity, relatively high envelope heat losses and the absence of preheating cause the average indoor temperature to stabilise around $10–12 °\mathrm{C}$, i.e., almost entirely below the $20–24 °\mathrm{C}$ comfort band. This is visible in Figure 5 and is numerically summarised by the ≈$11 °\mathrm{C}$ mean reported in Table 10 and Table 11. Under OpenADR-enabled control, supervisory constraints on the fuel-flow ceiling, preheat and shed factors keep indoor temperatures around $22–25 °\mathrm{C}$, as shown in Figure 6 and reflected by the $23 °\mathrm{C}$ mean in Table 11. The tables, therefore, condense, rather than contradict, the temperature trajectories observed in the figures.

4.7. Robustness Under Non-Ideal Conditions

To evaluate the robustness of the OpenADR-driven control under non-ideal conditions, a short sensitivity analysis was performed. Two key uncertainty sources were examined: (1) communication latency between the Virtual Top Node (VTN) and the Virtual End Node (VEN), and (2) thermal envelope parameters of the building model (U-values and infiltration rate).

• Communication latency: A uniform delay ranging from 0 to 10 s was introduced to the event and feedback channels. Results show that for delays below 5 s, controller performance and fuel consumption remain within $\pm 2\%$ of nominal conditions. Beyond 10 s, oscillations appear in fuel actuation due to asynchronous feedback, though the system remains stable without comfort violations. These findings confirm that the Stateflow-based event logic can tolerate realistic network latencies common in residential communication protocols.
• Building envelope parameters: U-values for walls and roof were varied by $\pm 20\%$ to represent different insulation levels. The total fuel consumption varied linearly ($\pm 6\%$), whereas comfort violation time changed by less than 10 min across a 50 h horizon. The system therefore demonstrates moderate sensitivity to envelope properties, validating its applicability across a range of residential building types.

This analysis shows that both communication latency and thermal parameter variability have limited impact on overall controller stability and energy-saving trends. The OpenADR-based strategy remains robust under practical uncertainty conditions, supporting its potential for real-world deployment.

5. Discussion

5.1. Summary of Key Findings

One of the key advantages of protocol-based control is the reduction in excessive boiler cycling and the erratic activation patterns typically seen in conventional thermostat systems. In the OpenADR scenario, fuel input adjustments are smoother and more controlled, helping to minimise mechanical wear and reduce the likelihood of component failure. This contributes positively to long-term maintenance planning and extends the operational lifespan of heating assets.

The adoption of the OpenADR protocol enables residential heating systems to actively participate in grid-side flexibility services, such as demand response and peak load management, without compromising occupant comfort. By synchronising heating output with grid signals, the system supports load balancing and enhances grid resilience—particularly valuable as renewable energy integration increases and grid dynamics become more variable.

Although this study centres on a residential heating testbed, the insights are broadly applicable to Multi-Energy System (MES) contexts. Protocol-driven control logic can be extended to other subsystems—such as cooling, gas, or electricity networks—facilitating cross-vector optimisation and more efficient use of distributed energy resources. As standards like OpenADR continue to evolve, their role will expand beyond simple communication interfaces to become foundational elements in the architecture of flexible, digitalised energy systems.

5.2. Baseline Controller Behaviour Under Building and Climate Constraints

Although the nominal indoor heating set-point is 22 °C, the baseline thermostat in the physics-based Simscape model does not reach this temperature under the applied sinusoidal outdoor profile. As shown in Figure 5, the average indoor temperature settles around 10–12 °C for most of the 50 h horizon. This behaviour is not a numerical artefact but an emergent property of the coupled plant and controller. It stems from the combination of (i) limited heater capacity (12 kW), (ii) relatively high envelope heat-loss coefficients and large thermal masses listed in Table 5 and Table 6, and (iii) the absence of preheating or supervisory adjustments to the actuator ceiling. Under these conditions the building behaves like a poorly insulated dwelling with an undersized boiler, and the thermostat can only maintain a low dynamic equilibrium where indoor and outdoor temperatures are nearly aligned. The OpenADR-enabled controller improves thermal performance without changing any of the underlying physical parameters. By introducing supervisory constraints on the fuel-flow ceiling, preheat and shed factors, and explicit comfort-band enforcement, it activates the boiler earlier before deep temperature drops and modulates output more smoothly during recovery. As a result, indoor temperatures are stabilised around 22–25 °C (Figure 6), comfort-band violations are strongly reduced, and total fuel consumption decreases due to the avoidance of deep cycling. Also, fuel savings observed under OpenADR control do not arise from an artificially weakened baseline thermostat. In both scenarios the heater capacity (12 kW), envelope heat-loss coefficients, infiltration rate, outdoor temperature profile, and numerical solver settings are identical; only the supervisory logic acting on the same plant model is modified. The OpenADR-enabled controller introduces rate-limit enforcement, actuator-ceiling modulation, and preheat/shed factors that reduce deep cycling and overshoot and partially shift heat delivery to more favourable periods. Consequently, the integrated fuel consumption computed from the 50 h simulations underlying Figure 5 and Figure 6 is consistently lower for the OpenADR case, while Table 10 and Table 11show higher mean indoor temperatures and markedly shorter comfort-violation durations, confirming that the reported fuel savings are achieved without compromising comfort.

5.3. Comparison with the Literature

A pertinent study by Abbà et al. (2024) [20] offers a Simscape-based simulation framework for evaluating flexibility in a district-heating Multi-Energy System (MES). Their approach defines flexibility in both physical and operational terms, using formal expressions to quantify the range of power modulation available within the system. Physical flexibility is calculated as the difference between maximum and minimum power levels, while operational flexibility is expressed through upward and downward modulation relative to a baseline power profile. These definitions form the basis of their UP-flex and DOWN-flex feasibility envelopes, which are constrained by thermal limits across the network.

Their findings highlight several key characteristics of district-level heating control. In a combined heat and power (CHP) plus boiler configuration, the CHP unit supplies the majority of heat—approximately $84\%$—with the boiler reserved for peak demand periods. The system operates with a baseline supply temperature of $90 °\mathrm{C}$, bounded by a maximum of $100 °\mathrm{C}$ and a minimum user-side threshold of $85 °\mathrm{C}$. Notably, the operational flexibility envelope is asymmetric; for example, no downward flexibility is feasible between 06:00 and 07:00 without breaching the minimum temperature requirement for the most thermally disadvantaged user. Temperature traces confirm that the system maintains ∼$90 °\mathrm{C}$ at the plant outlet and ∼$88 °\mathrm{C}$ at the user inlet outside peak periods.

In contrast, the present study focuses on a building-scale MES, embedding the OpenADR protocol into a residential heating model to explore how digital demand-response signals translate into device-level control actions. Rather than evaluating network-wide feasibility, this work assesses the impact of protocol-driven control on indoor comfort, fuel consumption, and the smoothness of actuation. The model explicitly consumes OpenADR EiEvent signals and maps them into Stateflow logic, enabling co-simulation with the physical subsystem and demonstrating interoperability between digital protocols and control systems. While Abbà et al. concentrate on identifying when flexibility is physically deliverable without violating network constraints, this study investigates how protocol-driven control can be used to actively modulate heating in response to real-time events. The results show that OpenADR-based control can maintain indoor comfort within acceptable bounds while reducing high-frequency fluctuations in fuel flow, thereby improving control stability and reducing mechanical stress.

The two studies offer complementary perspectives. Abbà et al. provide a framework for assessing flexibility envelopes under strict thermal constraints, while this study demonstrates how those envelopes can be operationalised through protocol-based control. Their definitions of operational flexibility offer a useful benchmark for post-processing simulation data in this study, allowing baseline and event-response trajectories to be mapped onto UP/DOWN-flex metrics at the device level. Furthermore, the temperature constraints used in their model—such as the $100 °\mathrm{C}$ supply cap and $100 °\mathrm{C}$ minimum at users—can be mirrored in the building-scale simulation as safety bounds on flow and return temperatures, ensuring that protocol-driven actions remain physically admissible.

Together, these approaches illustrate the value of integrating physical feasibility analysis with digital control strategies. Abbà et al. establish the boundaries of what is thermally possible, while this study explores how protocol-driven systems can operate within those boundaries to deliver flexible, responsive, and comfort-preserving heating control. The building model and the control logic implemented in this study have not been validated against experimental data but are based on well-established physical principles and peer-reviewed literature. To ensure the credibility of the simulation results, several parameters from the simulation were drawn from validated sources such as the MATLAB Simscape examples and the academic work of Abbà et al. (2024) [20]. While the model captures the key dynamics of thermal control and energy consumption in a residential heating system, the absence of experimental validation limits the generalisability of the findings. The validation of our model against real-world data or more comprehensive simulation-based studies is an essential step in enhancing its applicability and robustness. Previous studies, such as the work by Abbà et al., have modelled similar Multi-Energy Systems and control strategies, providing a benchmark for comparison. These models offer important insights into the thermal and energy response of residential heating systems, particularly in how OpenADR protocols influence energy flexibility. However, a comparison with real-world experimental data, including field testing and hardware-in-the-loop (HIL) simulations, would further substantiate the accuracy of our model’s predictions. In future work, we plan to incorporate experimental validation, which will involve testing the OpenADR-based system under real conditions. This would include assessing the impact of sensor latency, communication delays, and the real thermal response of the system to protocol-driven control. This validation will improve the model’s reliability and provide a more accurate basis for future implementation in residential heating systems. This explanation clarifies that while the model is based on theoretical principles and existing validated models, it has not yet been experimentally validated, and future work will focus on addressing this gap.

5.4. Limitations and Future Directions

A key limitation of the present study is that the developed OpenADR–MES framework has been validated solely through numerical simulation without experimental verification. While the Simscape model captures the dominant thermal and control dynamics of a residential heating system, it inevitably simplifies real-world nonlinearities, such as valve hysteresis, delayed actuation, and stochastic sensor noise. The accuracy of the results should, therefore, be interpreted within the context of a model-based validation environment.

Nevertheless, the simulation outputs remain physically credible, as all thermal and hydraulic parameters were derived from validated references (MathWorks example datasets and peer-reviewed MES models). The controller performance and comfort responses were cross-checked against literature benchmarks showing comparable temperature profiles and fuel consumption ranges. To enhance empirical reliability, future work will conduct hardware-in-the-loop (HIL) tests or small-scale laboratory experiments, linking the OpenADR Stateflow logic with actual heating devices and communication hardware. This would allow measurement of latency effects, actuator response delay, and system identification accuracy, thus strengthening confidence in the model’s predictive capability.

While the present work successfully demonstrates the feasibility of embedding OpenADR-based control within a residential Multi-Energy System (MES), its scope is intentionally limited to a single-dwelling scenario under a representative temperate climate. This restriction simplifies interpretation but inevitably limits generalisability. Real-world implementations span diverse climates, occupant behaviours, and housing typologies.

• Multi-Residential Clusters: The present model represents a single detached dwelling. In practice, aggregated flexibility emerges from clusters of residential units with heterogeneous thermal characteristics and occupancy schedules. Future studies should, therefore, extend the framework to multi-residential or district scales, incorporating networked control and aggregated demand-response coordination. Such extensions would enable exploration of synchronisation effects, spatial diversity in response, and communication scalability within OpenADR-driven neighbourhoods.
• Climate Zone Variation: The simulations were conducted under a single temperate climate profile with sinusoidal outdoor temperature variation. However, building thermal inertia, heating loads, and demand-response opportunities differ significantly across climatic regions—e.g., heating-dominated cold climates or cooling-dominated subtropical regions. Future work should perform cross-climate simulations using representative meteorological datasets (e.g., from ASHRAE or EnergyPlus Weather Data) to evaluate controller adaptability under different thermal stress profiles.
• User Behavioural Diversity: The current model assumes fixed comfort preferences and deterministic occupancy patterns. In reality, human behaviour introduces stochastic variations in thermostat setpoints, presence schedules, and device interactions. Incorporating behavioural models—such as stochastic occupant schedules or adaptive comfort algorithms—would yield more realistic flexibility quantification and enhance the robustness of OpenADR control validation.
• Methodological Expansion: Methodologically, the simulation remains deterministic and open-loop. Future research could implement agent-based or probabilistic frameworks to capture occupant–controller interactions across multiple households, as well as reinforcement-learning-based adaptive strategies that self-tune under diverse conditions. Such approaches would enable the quantification of both technical and behavioural flexibility potential at community or city scale.

In summary, expanding the framework to multi-residential clusters, varying climatic conditions, and heterogeneous user behaviours will significantly improve the external validity of the results. These extensions, combined with communication-network modelling and hardware-in-the-loop validation, will advance the transition from single-building testbeds toward scalable, real-world deployments of protocol-enabled energy flexibility.

6. Conclusions

This study set out to design and evaluate a protocol-driven control framework for a residential heating subsystem within a Multi-Energy System (MES), using OpenADR as the interface for demand-side flexibility. A physics-based Simscape model was developed to represent a realistic residential heating loop, comprising a boiler, variable-speed pump, pipework, expansion tank, and four room zones. The model was validated under conventional thermostat control, reproducing credible indoor–outdoor thermal dynamics and generating logged outputs for indoor temperature, ambient conditions, fuel mass flow to the boiler, and actuator status. This baseline configuration provided a robust foundation for comparative analysis with protocol-enabled operation.

To enable protocol-driven control, a Stateflow event engine was implemented to parse OpenADR event parameters—such as start time, duration, and event level—and translate them into supervisory commands for the Simulink control layer. These commands dynamically adjusted the boiler’s fuel flow set-point and pump operation, subject to comfort constraints. The resulting OpenADR–Stateflow–Simscape integration forms a reusable co-simulation architecture that links standardised digital signalling with physical system behaviour. Comparative simulations conducted under identical boundary conditions revealed several key benefits of protocol-enabled operation. The system maintained a higher and more stable indoor–outdoor temperature differential, indicating improved comfort resilience. Actuator behaviour was smoother, with fewer high-frequency spikes in fuel flow and a more moderated duty cycle. During OpenADR events, the system successfully curtailed or shifted heating output while preserving indoor comfort, demonstrating the practical deliverability of demand-side flexibility.

Unlike many MES flexibility studies that rely on abstract optimisation or scheduling models, this work embeds a realistic demand-response protocol directly within the simulation loop. It contributes a protocol-aware co-simulation pipeline in MATLAB/Simulink/Stateflow–Simscape, capable of ingesting OpenADR signals and driving the physical model in real time. This bridges a critical gap in the literature between protocol specifications and physics-based MES modelling. Furthermore, the study introduces operational metrics tied directly to protocol actuation—including comfort stability, control smoothness, and event-driven modulation—providing insight into how much theoretical flexibility is actually achievable under real-world signalling conditions. The framework developed here is also transferable. The modular event engine and supervisory control layer can be extended to other energy assets, such as cooling systems or electric vehicle charging, and adapted to additional protocols. This opens the door to future cross-vector flexibility studies and broader applications in digitalised energy systems.

Several limitations of the present work should be acknowledged. First, the proposed framework is evaluated in a model-based co-simulation environment and the residential building/heating subsystem is intentionally simplified to enable transparent interpretation of protocol-driven control effects. As a result, the reported comfort and actuation improvements should be interpreted as evidence of feasibility rather than a fully calibrated prediction for a specific dwelling. Second, the OpenADR layer implemented in this study follows a semantic emulation of core event concepts (e.g., start time, duration, and event level) mapped into supervisory constraints and, therefore, does not cover the complete OpenADR ecosystem (e.g., end-to-end VEN/VTN compliance testing, full report services, heterogeneous signal types, and real-world communication failures). Third, all simulations use an idealised sinusoidal outdoor temperature profile to provide a controlled benchmark for comparing baseline and OpenADR-enabled operation. This boundary condition does not represent real climatic variability, seasonal patterns, or region-specific weather extremes; consequently, the absolute levels of comfort violations, fuel use, and demand-response performance may not fully generalise to realistic building operation scenarios. Future work will validate the proposed control pipeline under representative meteorological datasets (e.g., typical meteorological year/EPW-based weather files) across multiple climates and seasons, and will further assess the impact of non-ideal communications (latency, jitter, and packet loss) and hardware-in-the-loop or small-scale experimental testing to strengthen external validity.

While the study has shown that embedding OpenADR into a residential heating subsystem can enhance comfort stability, fuel efficiency, and responsiveness to demand-response events, several limitations remain that point to promising directions for future research. Future work should incorporate more detailed building physics, stochastic user behaviour, and imperfect communication to better reflect real-world operating conditions. The scope of this study is limited to a single residential heating subsystem. Expanding the framework to include additional assets—such as cooling systems, electric vehicles, and combined heat and power (CHP) units—would enable assessment of cross-vector flexibility and provide a more holistic view of MES performance. Although the study demonstrates protocol-driven control in a simulation environment, further validation through hardware-in-the-loop testing or pilot deployment would be valuable. Such efforts would help capture latency effects, interoperability challenges, and cyber-security considerations, bridging the gap between theoretical modelling and practical implementation. Finally, building on the positive results at the building level, future research should explore how protocol-enabled control can be scaled to neighbourhood or district levels.

Although the results demonstrate the feasibility of protocol-driven control in simulation, experimental or hardware-in-the-loop validation is required to confirm the accuracy of model assumptions and verify real-time performance under practical conditions.

This would allow analysis of aggregated flexibility, interactions among multiple households, and the potential for market participation—positioning OpenADR as a foundational element in broader demand-side flexibility strategies.